软件平台遗留缺陷发布标准

版次：2021年11月9日 第3版
类型：技术文件
作者：祁彩云
上海维宏电子科技股份有限公司 版权所有

背景

平台迭代发布前仍有 Bug 未修改的情况，是否可以作为遗留 Bug 发布，没有比较文档化的标准可参考，不同角色对于发布标准不够一致，引起内部发现的问题，由于概率低、赶时间等各种原因发布，后续产品线或者在客户端重现类似问题，造成比较低的客户满意度。

明确软件发布的标准并且文档化，即什么样的缺陷可以作为遗留缺陷，迭代可以允许暂不修改发布，统一标准，避免无效沟通和不合理的决议。

迭代负责人需在第一个集成版本测试完毕后对未修改缺陷进行收集整理，沟通跟踪缺陷修复的进度及计划组织遗留缺陷评审。评审人必须包括测试主管、开发总工、其它小组开发&测试负责人。

进行遗留缺陷需要从以下几个角度进行分析：

1）缺陷风险程度

缺陷的风险程度高低是决定缺陷是否修改的先决条件，受三个因素影响。

一是缺陷的严重程度，即缺陷在用户环境出现后对于客户的影响程度。严重程度根据当前TFS定义的等级，分为致命、严重、一般、轻微/建议。

二是缺陷产生的概率。缺陷产生概率分为：有条件必现，有条件概率必现，无规律复现，无法重现。

三是缺陷相应功能的使用频率。功能使用频率分为：每天使用多次，每周使用多次，较少使用，基本不使用。

综合三个因素，缺陷的风险评估按照以下优先级考虑。严重程度>功能使用频率>重现概率。基本原则如下：

风险程度	严重程度	重现概率	功能使用频率
中	严重	无法重现	较少使用
低	严重	无法重现	基本不使用
中	一般	有条件概率必现	每周使用多次
中	一般	无规律复现	每天使用多次
中	一般	无法重现	每天使用多次
中	一般	无法重现	每周使用多次

2）缺陷发生概率

缺陷发生概率，也叫缺陷重现概率，是指缺陷在测试环境或者模拟真实用户的环境中发生的概率。可以分为以下几类。

缺陷发生概率	定义和描述
有条件必然重现	缺陷在相应的环境，符合相应的条件必然重现。
有条件概率重现	缺陷在测试环境中不会每次都出现，但按照一些特定的操作出现的概率很大。
无规律重现	不知道可以复现这些缺陷的条件，但是这个缺陷却可以在测试环境中无规律地出现。
无法重现	不知道可以复现这些缺陷的条件，并且这个缺陷无法出现。

3）缺陷暂不修改原因

缺陷可能由于项目的时间进度、人员能力和技术经验以及修改成本和风险等原因暂不修改，该原因将会影响缺陷是否会在本次发布修复。

4）缺陷规避措施

对于有一定风险的缺陷，以及存在合理的暂不修改的原因，需要制定缺陷的规避措施，以降低因不修改造成的影响程度。比如，提供了可以代替的功能可以规避此问题；在系统配置上做了限制，避免用户触发或者小概率触发；系统给出友好明确的提示降低不好的用户体验感诸如此类。

5）缺陷过往出现情况

缺陷在不同版本以类似形态出现的情况，如在以往版本出现过，后续版本不能够复现，再后续又有版本复现过，此类问题需要重视，对于定位风险程度有一定程度的影响。

在确定遗留缺陷的过程中，不同人对于缺陷遗留的标准因为认知、角度、角色的不同存在很大的偏差，明确以下标准供发布作为参考，如存在冲突，则提升到上级进行评审决议。

风险程度	规避措施	暂不修改原因（总工评审后）	发布/处理方法
高	无	人员能力和技术经验不足	不可发布，提交上级评审
高	无	时间成本高	不可发布，提交上级评审
高	无	修改风险高	不可发布，提交上级评审
高	有	时间成本高	可临时方案发布，需跟踪新方案
高	有	修改风险高	可临时方案发布，需跟踪新方案
中	无	人员能力和技术经验不足	不可发布，提交上级评审
中	无	时间成本高	不可发布，提交上级评审
中	无	修改风险高	不可发布，提交上级评审
中	有	时间成本高	可临时方案发布，需跟踪新方案
中	有	修改风险高	可临时方案发布，需跟踪新方案
低	无/有	合理原因	可遗留发布

遗留 Bug 需要通过相关人员的评审，总工，责任开发，责任测试，质量主管必须参与评审，针对产品线的需求或者新增问题评估到可能会影响到其他产品线的情况，还需要邀请产品线责任人参与，团队评审通过方可进行遗留。