测试用例，写不写？

文源 微信公众号：老张的求知思考世界

测试用例及其作用

我们先从测试用例本身说起，测试用例（Test Case)：为了特定的目的（证明软件存在某问题）而设计的一组由测试输入、执行条件、预期结果构成的文档。它通常包含测试用例编号、测试项目、测试标题、重要级别、预置条件、输入、操作步骤、预期输出等八个要素。

结合自己多年的测试经验，个人认为：测试用例是自己测试思维的一个载体，它指导着测试活动的进行，是测试执行的最低保障。至于以什么形式来承载，其实并不重要。

思考测试设计的过程，其实就是自己测试思维的体现。通过合理的测试用例设计策略和模型，能够让我们更好地去设计用例，通过更少的用例，去覆盖测试更多的测试场景。测试用例的好坏，能直接体现测试人员的基本素养（现在反而很多人都忽略了这些，而单纯的去追求技术）。

同时，测试用例将指导测试执行过程。因为人都会犯懒，可能是心情不好了，可能是想不起来了，也可能是单纯地遗漏了。如果没有测试用例来兜底，很多场景可能在执行的过程中就会被忽略掉了。我们可以在测试过程中去扩展测试场景，但已思考过的测试场景一定要得到执行和反馈。

至于说测试用例是否一定要满足八大要素“？个人认为并不重要，只要团队形成共识就可以了，不管是Excel，还是Xmind，更或者是用例管理系统管理，都是可行的。

有效的测试用例设计

那么如何进行高效的测试用例设计呢？常见例如等价类、边界类及错误推测法等等，在这里不展来说啦，网上有太多的资料。文章底部还会推荐一篇关于测试用例设计的“兵器谱”。个人在这里主要说两点想法，仅供参考：

目标导向：再好的测试设计方法论，都无法完全覆盖所有场景，所以我们要清楚地知识当前迭代或者版本的核心问题是什么，我们需要提供什么样的价值，用户在哪些场景下会去使用什么功能，需要思考和调研清楚，把自己当成用户来设计用例。再适当辅以异常场景验证系统的健壮性和可靠性。

清晰的结果验证：对于每个场景的预期输出，需要有合理的、科学的验证手段，不能仅限于页面的返回或者提示，需要深入验证每个环节的输出是否符合预期。

不同阶段的选择

当团队成员经验较浅或者项目比较重要，那我们可以编写更详细的测试用例，来培养团队或者个人的测试思维，来验证版本或者迭代中的核心功能。

如果团队成员的能力较强时，我们只需要罗列出测试点即可，依托于个人的测试经验，来节约编写测试用例的时间成本，但不可以不写用例，它能在你疏忽的时候提醒到你还有哪些测试需要执行。

对于敏捷研发团队来而言，因为团队相对固定，而且全程都参与了需求的梳理和确认，并编写AC确认。所以对需求有了较为深刻的理解，对于测试用例的内容和形式要求并不是那么高，但是要写好回归测试用例。

由于不同的团队和不同的项目情况不同，所以没有一种最佳方法适合于所有团队。测试用例需要根据自己团队和项目的特点和情况，选择适合并且实用的测试用例编写方法，从而更好的维护和执行测试。

测试用例可以简单，但不能没有。

对测试用例的其他理解

1. 测试用例不是测试人员的安全绳

对于评审过的测试用例，测试人员可能会有一种莫名的“安全感”，感觉只要执行完这些测试用例就可以了，产品的质量就可以得到有效地保障，最后出了问题，也不是测试的问题，因为测试用例得到团队的评审，如果有遗漏，那是大家都忽略的，我的责任也轻点，是大家都没想到，而不仅仅是我一个人没想到。这种想法非常不可取。

2. 测试用例是逐步完善的

随着测试人员对需求的理解不断加深，会有更多的场景涌现出来，需要我们不断地去补充和完善自己的测试用例。同时，伴随着系统的实现，我们对技术的了解也会更深，常见框架和中间件等一些技术问题也会逐渐浮现出来（例如一致性，时效性，可靠性等问题），需要我们通过更多的场景来验证。

3. 用例“前置条件”不一定能轻易实现

我们在写用例时，一般都会写前置条件，在用例中写起来可能只是一句话，但这些前置条件其实并不是那么容易构建出来的，比如一些支付场景、审批流、第三方回传数据，甚至于异常场景等等，需要测试人员有一定的技术能力去实现出来。

4. 用例越来越多，需要适当做减法

随着版本的迭代，我们的测试用例会逐步增加，如果不适合做减法，那最终的结果就是用例无法维护，慢慢失去作用。有一种比较好的方法就是把已经相对稳定的功能自动化（不管是UI还是接口），从而减少功能测试用例，让自动化替代人工做一些事。

小结

本文结合个人的经验，对于测试用例，给出了自己的看法：测试用例是自己测试思维的一个载体，它指导着测试活动的进行，是测试执行的最低保障。至于以什么形式来承载，并不重要。处于不同阶段的团队对于测试用例的颗粒度也有不同的要求，可以从不同的目标来确认用例的颗粒度，只要团队形成统一的共识即可。同时，对于测试用例，会有一些额外的思考，大家也可以一起探讨。