软件测试 -- 缺陷报告

缺陷报告是描述软件缺陷现象和重现步骤地集合。软件缺陷报告 Software Bug Report（SBR）或软件问题报告 Software Problem Report（SPR）

作用：缺陷报告是软件测试人员的工作成果之一，体现软件测试的价值缺陷报告可以把软件存在的缺陷准确的描述出来，当测试人员发现一个缺陷，需要填写一份“缺陷报告”来记录这个缺陷，并通过这个缺陷报告告知开发人员所发生的问题–缺陷报告是测试人员和开发人员交流沟通的重要工具。便于开发人员修正缺陷报告可以反映项目产品当前的质量状态，便于项目整体进度和质量控制软件测试缺陷报告是软件测试的输出成果之一，可以衡量测试人员的工作能力。

一、缺陷报告的要点

1）标题

2）描述：简洁、准确、完整、反映缺陷本质

3）重现步骤

4）严重程度

5）优先级

6）截图

7）编号

8）指派人

二、“5C”原则

内容准确（Correct）：每个组成部分的描述准确，不会引起误解

步骤简洁（Concise）：只包含必不可少的信息，不包括任何多余的内容

内容清晰（Clear）：每个组成部分的描述清晰，易于理解

结构完整（Complete）：包含复现该缺陷的完整步骤和其他本质信息

风格一致（Consistent）：按照一致的格式书写全部缺陷报告

三、二八定理

在分析、设计、实现阶段的复审和测试工作能够发现和避免 80%的缺陷，而系统测试又能找出 其余缺陷中的 80%，最后的 4%的缺陷可能只有在用户大范围、长时间使用后才会暴露出来。

四、缺陷报告的组成

1、缺陷编号（Defect ID）：提交缺陷的顺序

2、缺陷的标题（summary）：简明扼要的描述缺陷

3、缺陷的发现者（Defected By）：测试人员

4、缺陷发现的日期（date）：一般为当天

5、缺陷所属的模块（subject）：在测试那个功能模块时发现的 bug

6、发现缺陷的版本（Defected in release）：开发的软件的版本

7、指派给谁处理（Assigned to）：测试人员指派给开发经理，开发经理根据缺陷所在的模块，需要再次指派具体的开发人员

8、缺陷的状态（status）：缺陷此时所处的处理阶段或处理情况

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

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

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

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

五、缺陷报告的深度理解

1、缺陷的严重程度和优先级是不是成正比关系？

界面问题的严重程度一般比较低，担优先级可能很高————立即修复

某些重大的功能问题可能暂时解决不了，但不影响其他功能的使用，这时优先级可能定义的比较低————在发布之前修复

2、缺陷的严重程度和优先级确定好后，还能修改吗？

严重成度不允许改，优先级可能修复。

测试人员确定一个缺陷“立即修复”，但开发组认为这个缺陷不好解决，而这个缺陷又不影响其他功能，这时可能要求在“下一个版本修改”或“发布之前修改”

3、是不是所有一发现的缺陷都会被修复？

有些缺陷修复的成本太高或者由于进度压力可能在发布前得不到修复，这样的缺陷一定要经过项目组的讨论，权衡成本和风险，要确保不会对用户在成重大的影响及法律纠纷。后面再通过升级软件或者打补丁的方式修复缺陷或弥补漏洞

六、缺陷报告的作用

1、记录 bug

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

3、跟踪 bug

4、对 bug 进行分析、统计

接口测试工具可以使用国产的接口测试和接口文档生成工具：apipost