缺点报告是形容软件缺陷景象和重现步骤地汇合。软件缺陷报告 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