假设经过上一步工作 ， 分析出这个系统有5个模块 ， 50个大的功能点 ， 500个具体需求点 ， 最后生成了5000个测试点 。那么 ok ， 我们就要写5000个测试用例 。还是那句话 ， 一个测试用例只能对应一个测试点 ， 测试点和用例是1对1的关系；一个需求点可以对应多个用例 ， 需求点和用例是1对多的关系 。这样做的目的在统计中讲 。
第二：目的明确
用例都有个测试目的 ， 这就是要目的明确 ， 并且也只能有一个目的 。前面无论多少步骤 ， 都是为了找到这个目的途径 。功能从大到小有层次的划分 ， 我们做测试用例也是有层次的 ， 不然你怎么定义用例的优先级呢？等到测试最小的功能点是 ， 支持这个功能点的其他上层功能点 ， 我们都默认正确就可以了 ， 这就是我们的预期 ， 所以在测试步骤中不用对上层的功能专门考虑测试数据 ， 只把他当成一个正确的找到目前的功能点的途径就行 。换句话说 ， 你要测试的功能点需要点10个连接才能找到 ， 那么前9个连接我们再以前就应该设计了用例 ， 在第10个连接中默认他们正确就ok ， 这个用例的前9步 ， 只是告诉你如何找到第10步 。就是这样 。
第三：便于统计
测试用例对整个测试过程的质量控制和评估有很重要的意义 。
一 ， 可以做测试需求覆盖分析 。这样如果一个用例写几个测试点 ， 那么就无法完成需求覆盖分析工作 ， 至少是不符合规则的 。
你还可以通过模块划分 ， 来分析哪个模块存在的问题较多 ， 还有可能存在更多的问题（应为程序员不同 ， 能力就不同 ， 缺陷喜欢扎堆分布 ， 这个大家都知道） ， 存在问题较多的模块需要做进一步的测试或者下一次作为测试重点 。如果你统计的数据不准确 ， 会误导结果的 。
三 ， 做缺陷分析 。用例失败了 ， 就生成一个缺陷 。
文章插图