测试需求和测试用例、缺陷报告的关系

测试的基本流程：
获取测试需求–编写测试计划–制定测试方案–设计和开发测试用例–执行测试--提交缺陷–测试分析和评审–测试总结–准备下一版本的测试

一、获取测试需求是测试工作的重点，也是第一步。通过需求的分析，了解和掌握测试的方向和内容，例如：
（1）分析出系统的模块和组织结构
（2）分析出软件的基本功能和运行流程。（业务分析）包括可能会有哪些人或者哪些角色要用。
（3）识别出软件的重要功能和次要功能
获取测试需求的过程中，测试人员就要有相应的分析成果。一般用xmind这样的思维导图工具进行分析，或者使用需求跟踪矩阵来完成测试需求的获取和分析。

二、设定测试中需求的正、反向和优先级。
当有了测试需求之后，就开始对每一个需求点进行测试用例的设计。也就是，每一个需求点，都要被测试。
因此测试的过程中，衡量需求的覆盖程度，就非常的重要。使用：

需求的覆盖程度=被测试用例覆盖的需求数/需求点总数

进行计算和说明。
如果需求覆盖度＜100%，那一定说明了测试的覆盖度不够。

三、测试中，最能体现测试人员工作量的指标就是缺陷的数量和用例的数量。
（1）设计的测试用例总量 TC
（2）执行的测试用例数量 EC
（3）未执行的测试用例总量 WC
（4）执行通过的测试用例总量 SC
（5）执行失败的测试用例总量 FC
（6）提交的缺陷的总量 BC(Bug Counts)
以上5个数据，他们要符合如下的数量关系。

• TC≥EC
• TC=EC+WC
• EC=SC+FC
• BC≥FC 提交的bug数量，多于执行未通过的用例数。一条用例的预期结果数量是固定（甚至是唯一的）。说明了测试过程中发现的缺陷，除一部分是用例执行失败带来的，还有一部分应该是测试人员自身的经验和直觉（其他知识）带来的。
• 通过 SC/EC 可以表现出系统的质量是否合格
• 通过 EC/TC 可以表现出系统的需求是否得到满足