软件测试--缺陷报告.pdfVIP

软件测试--缺陷报告

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

作⽤：缺陷报告是软件测试⼈员的⼯作成果之⼀，体现软件测试的价值缺陷报告可以把软件存在的缺陷准确的描述出来，当测试⼈员发现⼀个缺陷，需要填写⼀份“缺陷报告”来

记录这个缺陷，并通过这个缺陷报告告知开发⼈员所发⽣的问题–缺陷报告是测试⼈员和开发⼈员交流沟通的重要⼯具。便于开发⼈员修正缺陷报告可以反映项⽬产品当前的质

量状态，便于项⽬整体进度和质量控制软件测试缺陷报告是软件测试的输出成果之⼀，可以衡量测试⼈员的⼯作能⼒。

⼀、缺陷报告的要点

1）标题

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

3）重现步骤

4）严重程度

5）优先级

6）截图

7）编号

8）指派

⼆、“5C”原则

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

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

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

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

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

三、⼆⼋定理

在分析、设计、实现阶段的复审和测试⼯作能够发现和避免80%的缺陷，⽽系统测试⼜能找出其余缺陷中的80%，最后的4%的缺陷可能只有在⽤户⼤范围、长时间使⽤后才会

暴露出来。

四、缺陷报告的组成

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

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

3、缺陷的发现者（DefectedBy）：测试⼈员

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

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

6、发现缺陷的版本（Defectedinrelease）：开发的软件的版本

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

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进⾏分析、统计

接⼝测试⼯具可以使⽤国产的接⼝测试和接⼝⽂档⽣成⼯具：