缺陷 告是描述软件缺陷现象和重现步骤地集合。软件缺陷 告Software Bug Report（SBR）或软件问题 告Software Problem Report（SPR）
作用：缺陷 告是软件测试人员的工作成果之一，体现软件测试的价值缺陷 告可以把软件存在的缺陷准确的描述出来，当测试人员发现一个缺陷，需要填写一份“缺陷 告”来记录这个缺陷，并通过这个缺陷 告告知开发人员所发生的问题–缺陷 告是测试人员和开发人员交流沟通的重要工具。便于开发人员修正缺陷 告可以反映项目产品当前的质量状态，便于项目整体进度和质量控制软件测试缺陷 告是软件测试的输出成果之一，可以衡量测试人员的工作能力。
一、缺陷 告的要点
1）标题
- 描述：简洁、准确、完整、反映缺陷本质
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、缺陷的严重程度和优先级是不是成正比关系/p>
界面问题的严重程度一般比较低，担优先级可能很高————立即修复
某些重大的功能问题可能暂时解决不了，但不影响其他功能的使用，这时优先级可能定义的比较低————在发布之前修复
2、缺陷的严重程度和优先级确定好后，还能修改吗/p>
严重成度不允许改，优先级可能修复。
测试人员确定一个缺陷“立即修复”，但开发组认为这个缺陷不好解决，而这个缺陷又不影响其他功能，这时可能要求在“下一个版本修改”或“发布之前修改”
3、是不是所有一发现的缺陷都会被修复/p>
有些缺陷修复的成本太高或者由于进度压力可能在发布前得不到修复，这样的缺陷一定要经过项目组的讨论，权衡成本和风险，要确保不会对用户在成重大的影响及法律纠纷。后面再通过升级软件或者打补丁的方式修复缺陷或弥补漏洞
六、缺陷 告的作用
1、记录bug
2、对bug进行分类（模块、bug状态、严重程度、版本）
3、跟踪bug
4、对bug进行分析、统计
接口测试工具可以使用国产的接口测试和接口文档生成工具：apipost
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！