敏捷QA需要写测试用例吗？

本文首发于【林子的空间】

---

“可工作的软件高于面面俱到的文档，这是敏捷的价值观之一，测试也不需要那么重的文档，测试用例可以不写。”这是甲方观点。

“没有测试用例怎么知道要测啥？没有测试用例怎么证明你测了啥？编写测试用例是保护QA自己的手段之一，应该要写测试用例。”乙方可不这么认为。

这里说的测试用例，我理解主要是指手动测试的用例。

01 真正的敏捷团队不需要详细的测试用例

总有人纠结或讨论测试用例该以什么形式写、要写到什么粒度，不同的团队、不同的公司对测试用例的要求也是不同，有的要求特别严格的格式、详细描述的步骤和期望结果等，有的则是可以简单的列出检查点即可。

那么，敏捷QA到底是否需要写测试用例呢？

1. 真正的敏捷团队

我是赞同甲方观点的，我认为真正敏捷的团队是不需要严格要求编写手动测试用例的。这是因为：

• 敏捷团队的QA需要参与测试左移的相关实践，包括从需求分析阶段开始介入，测试分析、设计和执行都会是同一个人，通过一系列的实践活动，QA在不断理解和澄清需求的过程中已经清楚了在测试时候需要关注的点，这些点不用以严格的测试用例的形式呈现出来。
• 真正的敏捷团队要求做好自动化测试工作，应该有足够的自动化测试来保障功能的回归，这些测试可能是单元测试、API测试或者端到端功能测试。对于用户故事开发完成之后，不会需要大量的手动测试工作，更多的应该是探索式测试，而探索式测试是不需要提前设计测试用例的。

2. 目标驱动测试用例的编写

当然，现实情况下能够称得上真正敏捷团队的少之又少，测试用例是不是真的完全不需要呢？对于自动化测试覆盖率不是那么高的团队，还是会需要比较大量手工测试的话，测试用例还是可能需要的。不过，不建议对测试用例的步骤和细节提出明确要求，要写成什么样，应该按照需求来，也就是说这个用例要用来干什么，以及它的生命周期有多长。测试用例的设计也需要遵循“目标（需求）驱动”的原则。

根据目标需求，可以将测试用例分成两个大类来看：

• 用户故事测试用例

用户故事级别的测试用例主要是为了帮助验证用户故事的实现，可以在用户故事启动、开发、验收以及测试阶段使用，生命周期也就是到用户故事完成测试即可，后续不需要重用了。

如果用户故事的验收条件是以实例化的方式写的，基本可以用来直接当测试用例用，请参考之前讨论验收条件是否可以当测试用例的文章《业务需求与系统功能》。如果验收条件写的不够，还需要增加一些边角情况，只需增加一些检查点即可，一般不需要列出详细操作步骤。

因此，用户故事级别的测试用例不用写太细，可以通过列出一些检查点的方式实现，直接附在用户故事后面即可。这样省时省力，能够简介清晰的表述需要关注的点有哪些，更方便跟不同角色达成一致认识。

有一个特例是对于新加入的毕业生，一般建议刚开始可以详细的写一下用户故事的测试用例，这主要是为了练手和熟悉业务。当熟悉到一定程度，就可以不用再写非常详细的用例了。

• 回归测试用例

回归测试用例通常不是用户故事级别，而是以特性级别考虑。回归测试用例是需要重用的，而且通常还需要给设计用例以外的其他同事用。这就要求设计出来的用例可读性很好，能够特别清晰表达出真实的业务信息。

回归测试用例建议从业务的视角、以用户场景的形式来描述，不要描述系统的操作步骤、页面跳转等，需要有一定的抽象层次。

回归测试用例不管是用于自动化，还是手动的回归测试，都可以以相同的形式描述，而且最好一起管理，并且能够标注出哪些是已经实现了自动化测试的，哪些还是需要手动测试的用例。基于业务的用例编写形式可以参考文章《说起BDD，你会想到什么？》中关于用例场景描述的内容。另外，我的同事刘冉有文章《测试用例的管理》详细介绍测试用例的，推荐关注。

3. 测试指南可以作为测试用例的补充

测试用例是用来验证业务需求的满足情况以及系统功能的正确性，而某些复杂的功能、特性可能还需要一些指导性的文档来告知该具体如何去执行相应的测试用例。比如，一些定时执行的任务都是有特定的触发条件，测试的时候可能需要修改某些数据来让其触发，对于这样的特性，在没有详细测试用例的情况下，可以采用测试指南来指导测试的开展。

这里的测试指南可能是特性相关业务流程文档介绍，也可能是系统配置要求等相关内容，或者是一些风险点、需要特别关注的薄弱环节、关联业务等。

因此，我们团队会对复杂的特性、需要进行特殊配置才能测试的功能编写相应的测试指南文档，作为测试用例文档的补充说明，结合测试用例一起使用，以帮助不熟悉上下文的同事更加顺畅的执行测试。

02 敏捷QA不需要保护

对于乙方观点，其实挺可笑的。我们敏捷QA为什么要通过测试用例来保护自己？难道说，我设计了足够的测试用例，并且都执行通过了，质量好不好都跟我QA没关系了？

但凡有点测试常识的人都会知道，这是个谬论。

• 测试无法穷尽，质量的好坏也不是通过测试来保障的。这就是我们为什么要推荐质量内建、要采用测试左移和右移实践的原因。

如果你还不是很了解这方面的内容，请参考下面几篇文章：

《敏捷测试宣言与原则解读》
《敏捷测试的核心》
《生产环境下的QA》

• 另一方面，在敏捷团队，我们始终强调团队为质量负责，出现问题不应该去追责某个角色或某个人，而是应该把团队作为一个整体去复盘、回顾，一起分析问题根因，一起讨论团队的薄弱环节和可行的改进行动项。

如果你还不是很清楚团队怎么为质量负责，欢迎参考下列文章：

《敏捷测试的指导性原则》
《团队对质量负责，“我”可以不负责？》
《说好的团队为质量负责呢？》

• 真正的敏捷QA应该是质量倡导者。敏捷QA想的不应该是如何保护自己，而是应该以价值目标为方向，引领团队一起为高质量交付承担各自的职责，做到真正的团队为质量负责。

如果你还不太了解敏捷QA到底该怎么做，请参考下列文章：
《敏捷团队的质量保障赋能》
《再谈敏捷QA》
《敏捷中的QA》

03 小结

测试用例到底要不要写？

我前面已经给出了敏捷团队的正确做法，但你的团队是否需要测试用例，我不能给你一个定论，因为这取决于很多的因素，每个团队有各自不同的特点，团队一起商讨适合自己的方案，大家能够达成共识就好。

当然，我还是要再次强调我的建议：

• 测试用例的编写要以目标驱动，有价值才有存在的必要；
• 测试用例的编写和执行，都不应该作为QA的绩效考核指标，一旦作为考核指标，必然带来副作用，跟其他任何考核一样；
• 敏捷团队应该追求尽量少的（手动）测试用例。

最后，我的同事朱平有篇文章透露了测试用例相关的真相与事实，非常推荐，欢迎关注：《测试用例的一些“真相”与“事实”》。