[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FKNYw06B-1625815979063)(/Users/acetian/Library/Application Support/typora-user-images/image-20210706103941129.png)]
四、缺陷报告
- 缺陷编号。Bug_项目名称 _功能名称 _0001。
- 所属模块。一级模块/二级模块/三级模块。例如：上课所用的直播软件，如果想要查看签到历史记录，需要进入直播界面——互动应用——签到——签到历史记录。
- 优先级。缺陷的修复紧急程度。P1>P2>P3>P4。
- 严重程度。S1>S2>S3>S4。
- 缺陷概述。用一句话描述缺陷的基本情况。
- 缺陷的描述。缺陷的复现步骤、预期结果和实际结果列出来。
- 提交人。是谁就写谁的名
- 备注。一般写产生该缺陷的特殊情况。将bug的截图作为备注信息。
缺陷报告的编写目的
1）展现缺陷的详细信息
2）展现缺陷的影响程度和方式
由于缺陷报告的读者很多：开发、质量管理、市场人员、运维人员，所以缺陷报告要写的很直白、清晰、明了。
报告编写的准则：准确、清晰、一致、简洁、完整。
缺陷描述的规则：
- 可以再现。针对绝大多数的缺陷都是如此。但是有一些小部分的缺陷是难以做到（类似闪退、崩溃这种不可再现缺陷，无需做的。针对一些可以重复出现的闪退缺陷，也要进行步骤的详细描述）
- 不做评价。不对缺陷的出现的严重程度和缺陷表现出来的效果进行主观臆断。
缺陷报告本身要保证没有任何表述性的错误。
测试需求和测试用例、缺陷报告的关系？
测试的基本流程：获取测试需求——编写测试计划——制定测试方案——设计和开发测试用例——执行测试——提交缺陷——测试分析和评审——测试总结——准备下一版本的测试。
获取测试需求是测试工作的重点，也是第一步。通过需求的分析，了解和掌握测试的方向和内容。例如：
1）分析出系统的模块和组织结构
2）分析出软件的基本功能和运行流程。（业务分析）包括可能会有哪些人或者哪些角色要用。
3）识别出软件的重要功能和次要功能。获取测试需求的过程中，测试人员就要有相应的分析成果。一般用Xmind这样的思维导图工具进行分析，或者使用需求跟踪矩阵来完成测试需求的获取和分析。
设定测试中需求的正、反向，和优先级。
当有了测试需求之后，就开始针对每一个需求点进行测试用例的设计。也就是，每一个需求点，都要被测试。
因此测试的过程中，衡量需求的覆盖程度，就非常的重要。使用： 需求的覆盖程度=被测试用例覆盖的需求数/需求点总数 进行计算和说明。
如果需求覆盖度<100%,那一定说明了测试的覆盖度不够。
测试中，最能体现测试人员工作量的指标就是缺陷的数量和用例的数量。
1）设计的测试用例总量 TC。
2）自信的测试用例数量 EC。
3）为执行的测试用例数量 WC。
4）执行通过的测试用例总量 SC。
5）执行失败的测试用例总量 FC。
6）提交的缺陷的总量 BC（Bug Counts）。
以上几个数据，他们要符合如下的数量关系。
1）TC大于等于EC。
2）TC=EC+WC。
3）EC=SC+FC。
4）BC大于等于FC。提交的bug数量，多于执行未通过的用例数。一条用例的预期结果数量是固定（甚至是唯一的）。说明了，测试过程中发现的缺陷，除一部分是用例执行失败带来的，还有一部分应该是测试人员自身经验和直觉（其他知识）带来的。
5）通过 SC/EC 可以表现出系统的质量是否合格。
6）通过 EC/TC 可以表现出系统的需求是否得到满足。