好的测试用例应该具备哪些特质

星球群里，大家聊起了测试用例管理工具的话题。

有说 A 工具开源免费好用的，也有说 B 工具功能强大支持定制化和各种报表输出的，也有直接用 Excel 管理测试用例的，形式多样，各有各的道理，也各有各的痛点。

讨论间隙里，有同学问了这样一个问题：什么样的测试用例比较好呢？

这是一个好问题，也是很值得测试同学思考的问题。

这篇文章，我说说自己的理解。

在聊好的测试用例该具备哪些特质之前，不妨先看看测试用例的作用。

我们都知道，随着业务和系统复杂性的提升，以及团队人员变动、需求迭代和各种配置的变更，软件本身可能会出现各种问题。在这个不断墒增的过程中，软件研发交付已经变成了一个特别复杂的需要团队精诚协作才能完成的巨大工程。

为了控制复杂性不断墒增，降低软件可能出问题的风险和影响，为了保证复杂的团队协作可以朝着同一个方向前进，促进软件研发交付过程的每个环节都达成预期目标，我们做了哪些事情？

• kickoff：项目启动会，宣讲项目目标、关键里程碑、各角色职责范围。

• 流程规范：约定在项目研发交付过程中，要遵守的原则，即划定边界。让不同职业背景、技术栈不同的各个角色可以不跑偏，始终朝着同一个方向前进。

• 质量门禁：在软件研发交付的整个过程中，每个环节设定指标。保证从无到有的过程中，每个环节的交付产出物都满足标准(即风险尽可能被降低和接受)。

• 质量度量：通过各种不同维度的数据采集和分析评估，判断最终的交付产出物满足业务预期目标。

其中测试用例的作用是什么？

测试用例是为了保证本次交付范围内的所有需求和带来的变更尽可能被覆盖验证，交付部分不出问题或者问题已知风险可接受。简单来说，测试用例是一种在有限的已知范围内，尽可能 cover 风险的手段。

同样，需求设计环节会有大量的讨论和评审，研发编码阶段的 code diff、code review、单元测试，也是这个目的。甚至我们常见的产品验收测试、线上灰度发布的作用也是如此。

回到本文主题：好的测试用例应该具备哪些特质？

从我个人的角度理解，好的测试用例只需要具备如下几个特质即可：

1、看得懂

即你的测试用例，自己要能看懂，其他人也要能看懂。

所谓看得懂，并不是说你用一长串文字记录流水账似的写出来就行。而是：无论你还是其他人，都可以通过你的测试用例描述快速了解这条用例对应哪个需求哪个功能点哪个业务场景要验证什么。

2、能继承

所谓能继承，简单理解就是换个人来照着你的测试用例执行，也不会出错，且测试用例要与业务场景和需求点相匹配。这点特质要求测试用例需要时常维护更新，除非是一次性项目或者需求有大的变更或者迭代。

这点特质还有一点作用，在回归测试阶段特别明显，这也是为什么较为成熟的测试团队，都会提倡建立和维护测试用例库和用例集合的原因。

3、能兜底

所谓的能兜底，即测试用例需要对预期内可能出现的风险或者问题负责，简单来说就是需要覆盖各种异常和可能导致资损或者影响服务稳定性的场景。

假如预设的风险或者问题发生，测试用例也可以通过快速验证来确认问题，并在问题修复后可以验证。这也是测试用例设计方法中，边界值和场景法的指导价值所在。

至于用哪个测试用例管理工具，用 Excel 或者 XMind 编写测试用例，更多的是管理手段和个人习惯问题，而非测试用例本身的特质。