是时候抛弃传统的软件测试用例了！

先给一个传统的测试用例的例子，作为讨论的上下文。

先抛出本文的观点：是时候，抛弃传统的测试用例，即抛弃上述规范描写的测试用例（含有具体操作步骤等）。

抛弃传统的测试用例，不意味着抛弃测试设计。测试设计是需要的，但可以用思维导图、矩阵、测试模型、测试场景、用户故事的验收标准等不同形式来描述测试设计，只是不用上述传统方式来描述。

我也不是无视传统软件测试用例的价值，但在今天来看，这种价值已经很小了。虽然在我的教材中，可能还包含 “如何书写规范的测试用例”，让大学生来练习也许还有价值，至少先让他们了解传统的测试用例是如何写的。就像讲《软件工程》中敏捷开发模式之前，还是先要让同学们了解瀑布模型、V模型，这样才能更好理解敏捷模型。

• 测试的依据，包括测试执行、评审、管理的基础；
• 作为测试的主要文档，传递测试知识；
• 测试设计、测试执行由不同的人执行；
• 更容易通过CMMI/TMMI 认证；

一、详细的测试用例能不能成为测试的依据？

但是，许多项目很难写出明确的期望标准，因为需求的标准就不明确，而是需要测试人员的综合判断，这时依赖测试用例很困难。基于用例来执行测试，容易限制测试人员的思维，甚至让许多测试人员不去思考，而测试用例自身又很难写得完整，需要不断完善。

当测试用例写得越详细，其维护的工作量越大，人们就更不愿意去维护，时间长了，许多用例失效了，也没有得到修改。把大量时间花在写测试用例、维护测试用例上，投入产出比（RoI）低，不合算，测试人员有更重要的事情去做。

如果评审几千条用自然语言写的详细测试用例，不仅工作量大，而且也不容易发现问题，因为不容易看到全局。如果把测试点、测试场景、测试数据很好地整理归纳在一张思维导图上，即使分解为几张思维导图，任何遗漏、不足之处倒是很容易发现。基于思维导图的测试设计评审更容易。

二、测试用例能很好传递测试知识吗？

测试用例可以传递测试知识，但靠测试用例来传递，效率偏低。如果用单位时间能吸取多少知识来衡量，可以感觉出来，读了大量的测试用例获得的知识有限，还不如看几十页的图书。

三、测试设计、测试执行该不该由不同的人执行？

把测试设计和测试执行分开，是错误的做法，不仅增加了沟通成本，而且不能保证测试设计和执行的质量。一方面，测试人员通过测试执行可以更好地理解功能、产品、业务等，从而进一步完善测试设计。另方面，测试设计长期脱离测试的执行，对产品、特性的理解也会退化，自然对测试设计有不良影响。

有人说，我们有大量外包人员，他们流动快，主人翁意识不强，只能执行。你希望把他们当作测试工具、按部就班地执行测试用例吗？作为外包人员也乐意成为测试工具吗？如果是这样，为什么不直接写成自动化测试脚本？让工具执行还更靠谱、更快、成本更低。

至于认证，你懂，一般只是一种政绩工程，或者是为了项目投标用。如果你要投标，要做外包，为了证明自己，写出规范的测试用例来交差，那就继续下去。

今天，你如果是用敏捷开发模式，有了用户故事就是有了用户行为，只要追加“场景”，列出需要验证的测试场景，类似BDD的GWT描述。虽然测试场景还不是测试用例，不能执行，但离测试用例也就差一步，即加上测试数据，而这时测试数据可以自动生成。所以，在敏捷开发模式中，主要为每个用户故事给出场景列表，这个也容易评审，越简单的东西，一旦有问题，就越容易发现。越简单的东西，维护的成本也就越低。

如果你不是用敏捷开发模式，而是用传统的开发模式，我倒是希望你画一张业务流程图，标上业务规则、业务角色，针对这个进行测试，更能保证业务覆盖，而业务覆盖才是最根本的。咱们一切工作都是为了业务，测试就是为了会更好地保障业务的质量。当我们谈覆盖率，实际包含了三个层次的覆盖率：代码、功能/非功能特性、业务。单元测试侧重代码覆盖率，而系统测试侧重功能/非功能特性覆盖。非功能特性，性能、安全性、可靠性等会单独去考虑，即我们常说的专项测试，而功能测试，完全可以被业务覆盖而覆盖，即E2E业务覆盖更彻底。

今天来做测试，依旧建议新功能用探索式测试，就根本不写测试用例。而回归测试彻底实现自动化，也根本不写测试用例（千万不要先写测试用例，再翻译成测试脚本，这样更浪费时间！），直接写测试脚本。

所以，今天可以彻底抛弃传统的测试用例，甚至连自动化测试都要抛弃传统的测试脚本，推行codeless自动化测试。