关于测试用例的话题，我之前已经写了 12 篇相关文章了，没看过的同学建议先回顾下（后台回复「测试用例」获取）。

今天想说说「什么是好的测试用例」。

这个话题的争议很多，每个人的理解千差万别，比如我用搜索引擎搜索关键词「什么是好的测试用例」，百度返回 1960 万条结果，Google 返回 574 万条结果。

在给出我的结论前，我先列一下现有的一些有代表性的答复。

答复一（百度经验：https://jingyan.baidu.com/article/aa6a2c14ae7ff20d4c19c4b7.html）：

1、好的测试用例应该是容易发现软件的错误（或者是能够发现以往还没有发现过的软件错误）；
2、好的测试用例要有重复性；
3、好的测试用例必须清晰地定义一个或者多个期望的结果以及测试通过和失败的标准；
4、好的测试用例是没有冗余；
5、好的测试用例能覆盖更多的测试需求

答复二（百度知道：https://zhidao.baidu.com/question/2265681673450038028.html）：

1、用例覆盖程度；
2、用例是否已经达到工作量最小化；
3、用例的分类以及描述是否足够清晰；
4、用例是否表明了测试目的；
5、测试用例的易于维护性；

答复三（51 博客：http://www.51testing.com/html/81/22381-228241.html）：

1、能否高效地发现软件中存在的缺陷；
2、是否是可仿效的 (exemplary)；
3、是否够经济；
4、是否有足够的扩展性；

答复四（360doc：http://www.360doc.com/content/11/1102/15/5633521_161097549.shtml）：

1、依据分明；
2、目的明确；
3、便于统计；

答复五（茹老师《测试 52 讲》第二讲：https://time.geekbang.org/column/article/10150）

“好的” 测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷无关」

答复六（《软件测试技术概论》第 3 页）

一个好的测试用例在于发现从前未发现的错误；

我的答复：从质量保证的角度看，我赞成茹老师的观点，好的测试用例应该是一个完备的全集，覆盖所有需要测试的地方；从迭代测试的角度看，我更同意能发现 Bug 的用例就是好用例。

所谓的质量保证，一般是从项目整体来看，或者持续维护一个项目的用例全集，这时候用例的覆盖度就显得尤为重要。

一个项目经过多次迭代，早先的需求实现可能已经被改的面目全非，如果没有一个好的用例全集进行回归的保证，也就很难保证迭代的正确性，也就没法保证迭代的速度。

当然，至于这个用例全集是自动化用例，还是手工用例，还是其他的方式并没有特殊要求，需要的是有这个一个集合，在需要的时候可以用上，并且能保证执行后达到的效果。

所谓的迭代的角度，我指的是迭代过程中的修改，这时候设计的用例如果能针对迭代的具体修改点，以及修改点的影响范围去设计针对性用例，效果会更好，效果最直接的体现当然是能否发现 Bug 了。

有同学可能会问，那如果没发现 Bug，难道就不是好用例了？从这个角度看，确实是这样的。

那没发现 Bug 的用例是不是都可以删掉了？当然不是，虽然没发现 Bug，但我们证明了需求实现的实际结果和预期结果是一致的，达到了测试目的，所以还是要保留。

再者说，并不是说我们要保证所有的测试用例都是好的测试用例，这里面的「好」可以理解为更有效，所以可以酌情降低这部分必须执行，但是又没有发现 Bug 的用例的优先级。

如果把这两个方面做个汇总，那么结论就是：用例集的覆盖度越全越「好」，迭代过程的用例针对性越强越「好」，所有用例都要划分明确的优先级。

至于其他答复中提到的某些关注点，有一些算是用例格式的要求，我在之前的 12 篇文章中多有提及，其他没有提及的，后面会有专门的文章进行说明，敬请期待。

以上，我说明了自己对「什么是好的测试用例」对理解，不知道你是否有相同或不同的看法，欢迎你给我留言。

当然，如果你认可我的观点，欢迎分享文章到朋友圈 + 点个「在看」让更多人看到，谢谢。