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

关注

发布于: 刚刚

“可工作的软件高于面面俱到的文档，这是敏捷的价值观之一，测试也不需要那么重的文档，测试用例可以不写。”这是甲方观点。
“没有测试用例怎么知道要测啥？没有测试用例怎么证明你测了啥？编写测试用例是保护 QA 自己的手段之一，应该要写测试用例。”乙方可不这么认为。

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

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

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

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

1. 真正的敏捷团队

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

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

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

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

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

用户故事测试用例

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

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

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

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

回归测试用例

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

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

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

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

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

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

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