测试策略及缺陷识别

一、测试策略

1、编写测试计划

2、编写测试用例

3、执行测试，发现缺陷提交缺陷报告

4、验证所发现的缺陷是否得到修改

5、编写测试总结报告

二、缺陷报告的组成

     即缺陷的处理流程，是一个缺陷的生命周期

1、缺陷编号（Defect ID）

     提交缺陷的顺序

2、缺陷标题（summary）

     简明扼要的描述缺陷

3、缺陷的发现者（Detected By）

     测试人员

4、发现缺陷的日期（Detected on date）

     一般为当天

5、缺陷所属的模块（subject）

     在测试哪个功能模块的时候发现的bug（开发组可以据此决定由谁负责修改该bug）

6、发现缺陷版本（Detected in release）

     在测试哪个版本时候发现的bug

7、指派给谁处理（Assigned to）

     测试人员指派给开发经理，开发经理根据缺陷所在的模块，需要再次指派具体的开发人员

8、缺陷的状态（status）

     缺陷此时所处的处理阶段或处理情况

   （1）测试人员发现缺陷，提交缺陷报告，把缺陷的状态置为：new（新发现的bug）

   （2）开发经理验证新提交的bug，如果是bug，把状态改为open（打开的bug，开发组接受的bug），指派给具体的开发人员解决；如果不是bug，把状态改为rejected（拒绝的bug）

   （3）开发人员看到指派给自己解决的bug，进行bug修复，修改完后，把bug状态改为：fixed（已经修复的bug，可以返测的bug）

   （4）测试人员对修复的bug进行反侧，返测成功，把状态改为closed（关闭的缺陷，归档的bug）；如果返测不成功，把状态改为：reopen（重新打开的bug）

9、缺陷的严重程度（severity）

     bug对软件的影响程度有多大

     Urgent：造成系统死机、重启、崩溃的缺陷

     Veryhigh：非常严重的缺陷

     High：严重的缺陷

     Medium：中等程度的缺陷

     Low：小的缺陷

     每一个等级包括哪些缺陷，需要在文档中进行详细说明，这样可以使开发和测试人员达成共识

10、缺陷的优先级（priority）

     测试人员希望该缺陷程序员在什么时间内或者在哪个版本解决

     Urgent：立刻修改（影响开发或测试的进度）

     Veryhigh：本版本修改

     High：下版本修改

     Medium：发布前修改

     Low：允许在发布当中存在的缺陷

11、缺陷描述（description）*

     把发现bug的步骤，使用的数据等记录下来，使程序员通过该描述就清楚所发生的事情

     要求：描述清晰，并可以重现缺陷

三、缺陷报告的用途

     1、记录bug

     2、对bug进行分类（模块、bug状态、严重程度、版本）

     3、跟踪bug

     4、对bug进行分析统计

四、如何识别bug

     1、通过测试用例的预期结果判断-实际结果与预期结果不一致，就是bug

     2、看需求（通过缺陷的5点定义识别）

     3、沟通