研发体系问题单处理流程

研发体系问题单处理流程

A：当前责任人要做的事情

S：问题单的状态

线上的文字，中文：判断结果；英文：在TRAC上对问题单的操作

1. 问题定位确认

测试人员发现问题后，如果是必现、确定的问题，直接提单；如果是无规律重现问题，或者不确定是否是问题，可以找相关开发人员进行测试现场定位分析，排除误操作等原因，确定问题现象及初步分析结论，由测试人员提单给定位责任人进一步跟踪；

2. 问题单提交

问题单严重程度有四个等级：致命、严重、一般、提示；

问题严重程度级别判定原则：问题级别判定应该就重不就轻，当问题现象可能符合多个问题级别定义的描述时，应该选择级别最严重的作为最终的问题级别。

致命

定义：产品的关键功能和性能不能符合用户要求，或由于产品质量原因造成业务中断、频繁瞬断或服务质量严重下降等可能给用户收益或声誉造成较大损失的问题。

举例：（包括但不限于下列情况）

（1）整机或关键部件异常重新启动或瘫机；

（2）由于产品质量原因造成的基本业务失效、部分失效及不能稳定提供；

（3）可能影响用户收益或声誉的；

（4）重要操作维护功能完全失效，例如用户无法对系统进行操作维护或操作维护经常被打断，无法对系统进行维护，告警功能完全丧失等；

（5）系统性能基于上一个版本下降10%以上并可能影响用户收益或声誉的；

（6）按照版本升级指导书操作导致系统升级失败；

（7）其他可能造成业务中断、频繁瞬断或服务质量严重下降等可能给用户收益或声誉造成较大损失的问题，例如资源大量吊死、大量消息丢失、时钟丢失无法恢复等。

（8）产品不符合行业规范或目标客户群所在地区的相关标准，如果不解决将导致无法在该地区销售；

（9）不符合安全规范，在遵守安全规程进行操作维护的情况下可能造成重大人身伤亡的问题；

严重

定义：在产品规格书或行业标准规定的条件范围内，系统的主要功能和业务性能不符合用户要求，或不能稳定运行，但仍然可以向用户提供基本的业务。

举例：（包括但不限于下列情况）

（1）非基本业务功能失效或部分失效；

（2）基本业务功能在特定的不常见的条件下的失效，例如在某异常情况下的处理不符合协议；

（3）非关键性部件故障，这些部件的故障不会影响用户使用基本业务；

（4）系统数据丢失或出现不一致但不会给用户带来损失；

（5）系统未达到要求或设计的性能指标、系统或模块性能下降但不影响基本业务；

（6）用户资料存在严重的技术错误或缺少重要技术内容；

（7）其他各种可能对客户造成影响但尚未影响基本业务的问题；

（8）部分主要功能操作很不方便，多数用户会认为这些操作方式显著影响工作效率；

（9）不符合安全规范，在遵守安全规程进行操作维护的情况下可能造成轻微人身伤害或设备损坏的问题；

●一般

定义：部分次要功能失效或性能略有降低，但不会造成用户收益或荣誉受损失；

举例：（包括但不限于下列情况）

（1）非基本业务功能的一个特例失效；

（2）出现异常告警/断言等但没有影响系统的正常运转；

（3）部分次要功能操作不方便；

（4）在某些罕见或外界强烈干扰情况下（不包括外部灾难情况）会出现短暂的次要功能失效，且能够自动恢复；

●提示

定义：系统功能可以正常运行，但存在不影响功能正常完成的操作、理解上不合理的的问题。

举例：（包括但不限于下列情况）

（1）用户界面文字排版风格问题；

问题单提交时注意填写如下说明：

(1)问题摘要-概要描述问题涉及的主要场景和产品特性；

(2)问题说明：应包含：产品信息，版本信息，特性版本信息，测试环境，操作步骤、期望输出，问题现象等内容；可以参考如下格式：

【摘要】：简要概括描述问题的出现现象

【问题出现版本号】：xxx

【系统环境】：

【浏览器】：xxx

【出现概率】：测试10次，出现3次，必现问题不必写

【问题复现步骤】：XXXX

【测试结果】：XXXX

【期望结果】XXXX

【问题定位】xxx

【修改建议】xxx

(3)附上一切对问题定位有价值的内容，例如：前后台日志、截图等；

3.问题单定位分析、修改验证、代码上库、归档

1）填写《问题单xxxx定位分析及修改说明报告.doc》作为附件上传到bug上。

2）如果有周边影响，需要通知相关人员。

3）提交问题修改代码比较报告，压缩上传到bug上。

4) 代码上SVN库时，SVN日志填写应遵循格式：【问题单号】问题描述。

5）如果不是自己的问题，可以返回给项目经理（不知道谁来定位时），也可以直接转给对应的开发人员（知道是谁的问题时）。

4. 问题单解决、审核

将解决后的问题转给项目经理，由项目经理审阅相应定位分析、验证、修改报告、待回归测试版本号等信息填写是否完全；

5. 问题单回归、关闭

(1)新版本软件包制作完毕，进行开发自测试时，要求问题单修改责任人使用该新软件包进行问题场景的自测试，验证在新版本中问题是否得到解决；

(2)自验证完毕后，知会项目经理将归档在案的问题单转交给测试负责人组织回归测试；

(3)测试负责人将问题单转给相应的测试人员进行回归测试；

(4)测试人员按照问题场景进行回归测试，确认问题已经得到解决后，关闭该问题；

6. 注意事项

(1)不允许从开发人员定位直接关闭问题单;

(2)修改人和审核人不能是同一个人;

(3)修改人必须填写问题定位分析、问题修改验证等必要信息；无原因走单将由审核人直接驳回；

(4)根据项目情况，测试负责人审核和项目经理审核两个环节可以裁剪掉；

(5)项目经理的角色可以由资深开发人员担任；

7. 附录