测试流程

1、流程说明

BUG流程如下：

 

状态说明：

open:新提交的BUG

fixed：已修复待测试的BUG

closed：已经关闭的BUG

从open到fixed的解决方案有如下8种：

 

流程流转说明：

1. 测试人员将新提交的BUG并将状态置为：open，同时为BUG分配经办人；

测试人员需求注意以下几点：

阻塞流程的及时看，其他情况尽量少打断开发的工作

确定的BUG及时提库

不确定的BUG，自行验证后直接提BUG

偶现BUG，资料收集齐全（资源占用情况、日志、程序图片、配置、操作及现象描述、数据库DATA文件夹、版本说明）

早会时记得提醒一下开发，开发自行找时间看一下

 

1. 当经办人收到BUG后：
   1. 无异议，问题修复后，提交解决方案为：已解决；
   2. 有异议，和相关人员确认不是BUG的，提交解决方案为：不是BUG；
   3. 暂时无需修改，以后有时间再修改，提交解决方案为：延期处理；
   4. 需求设计如此，不是BUG，提交解决方案为：设计如此；
   5. 经过分析后无法定位重现，无法解决，提交解决方案为：无法重现；
   6. 经PO确认不需要修改的，提交解决方案为：不予解决；
   7. 如果已经有相同的其他BUG，提交解决方案为：重复BUG；
   8. 非BUG范围，需要进行需求评审的，提交解决方案为：转为需求；
   9. 需要其他人修改时，指派给相应的开发人员（不能是测试人员）
2. 当测试人员收到状态为FIXED的问题时，发布测试版本后，验收BUG：
   1. 测试通过，测试人员关闭问题；
   2. 测试未通过，测试人员将问题指派给开发人员；

4、BUG重复出现时，将以前的BUG重新指派给相应的开发人员（即重新打开BUG）；

 

2、管理规范：

1. 任何状态的流转一定要写备注，包括测试关闭的时候。

开发解决问题时需要写清修改说明，格式如下：

【BUG出现原因】：

【BUG修改范围】：

【测试重点】：

1. 测试人员测试到BUG后及时提交到BUG管理库，所有问题都必须提交。
2. 开发修改后及时更新BUG状态，并发布版本测试。
3. 总部反馈的BUG，测试部及时跟踪并提交BUG库。
4. 解决方案为延期处理、不是BUG的需要经过相关人员（主要是PO）确认。
5. 对问题有分歧时可通过评审的方式解决。
6. BUG分配的经办人不正确时，当前经办人将问题指派给合适的人员（非测试人员），如不清楚谁是责任人，指派给对应的组长(软件问题、算法问题)。
7. 测试人员提交BUG时，优先级、严重程度、BUG类型、模块须按照要求填写，不能为空；描述应当清晰明白，有重现步骤（要求：可执行、可重现）、预期结果和实际结果（无二义性）。
8. FIXED状态的问题版本发布后测试人员需及时测试，并更新BUG状态，切忌测试不通过时不更新BUG状态。
9. 优化建议类BUG提给PO