A 公司面试官：你认为测试用例的作用是什么？
B 公司面试官：你怎么看待测试用例评审的必要性？
C 公司面试官：编写测试用例的方法有哪些？
D 公司面试官：你们用什么工具编写测试用例？
……

身为一名 QA，尤其是作为初中级工程师的你，想必在你过去求职的过程中，如上关于测试用例的问题，或多或少都被问到过。还记得当初你是怎么回答的么？你觉得面试官对你的回答满意么？

作为一名有着几年面试经验的测试老兵，其中我最喜欢问的是第一项 “你认为测试用例的作用是什么？” 就是想考察你对基础的理解和认知。我们一起来看看下面这些回答：
A 同学：测试用例是测试执行的依据
B 同学：测试用例是为了防止漏测
C 同学：测试用例是对需求的细化、拆分
D 同学：对于需求不了解的 QA 可以按照测试用例执行
…..

对于有点测试基础的同学都能看出来，以上回答都没错。但当把这些回答放在一起时，大家不难发现，单个回答都比较片面，很难突出你个人的能力。那么，下次再有面试官问到时，我们该怎样回答呢？

在这里如果只是简单的罗列答案，想必大家看完后，很快就又忘到了九霄云外。因此，带着大家一起分析下，遇到类似的问题该如何回答：
古语云：” 三思而后行”、” 凡事预则立，不预则废”。应用在我们测试中，在测试执行前我们也要三思，一定不能鲁莽、不能操之过急；要做到有目标、有计划、有步骤。其中的目标、计划、步骤不单单要在 “测试计划书” 中体现，在测试用例中同样要体现。而测试用例的目标正是与它的作用紧密契合的。那么它都有哪些目标呢？我们不妨从以下三个方面考虑。
1.测什么？
2.怎么测？
3.给谁看？

测什么？

被测对象显然是我们的需求。这里，相信个别同学就有疑问了，那直接依据需求测试不就完事儿了？我们来看个简单的例子：

有这么个一句话需求，输入整数 A 和 B，返回 A 和 B 的和。

单纯的依据需求测试，可能会考虑到 A 和 B 分别为正整数、0、负整数等情况。可以说，这样测只是验证了 “功能实现性”。并未验证到容错性、健壮性、稳定性等软件特性的其它方面。例如：我们要确认 A 和 B 需要支持的范围（代码中变量定义可能为 int,long,BigInteger），不同的支持范围，CASE 输入边界就要有所调整;同时我们要确认 A 和 B 输入非正整数（小数、非数字）时的一些容错可接受；甚至针对系统的特点，我们还需要考虑性能等其它问题。

由此，我们不难看出，即使这么一句话的需求，我们依然有很多需要考虑的点。如果不在测试用例中按照软件质量特性进行 “拆分”，有谁能确保在测试执行时可考虑到所有点？对于复杂的需求，我们不仅要根据软件特性进行拆分，还要对需求本身进行拆分，例如对于一个微信发红包功能，我们可能需要拆分的点就要包含，发送方支付方式、红包额度、红包有效时长、发送目标等等，其中的每一个点可能又要拆分成很多的 CASE 进行验证。

通过以上分析，我们了解到。测试用例其中一个作用就是 “完成对需求的拆分”。

怎么测？

我们都知道 “做什么” 通常要比 “怎么做” 难得多。同样，如果你已经搞清楚 “测什么”，那么对于 “怎么测”，难度就小了许多,甚至可以不写复杂的前置条件、测试步骤、测试优先级，按照自己组织的 CASE 去执行就好了。但建议不要这么做，原因在于可能在写 CASE 的时候搞清楚了 “测什么”，过一段时间后就又淡忘了。更主要的是你写的 CASE 可能是别人去执行。

我以往经历的项目中，也确实是有不少团队把测试用例编写和执行分开的，经验丰富的工程师通常负责编写测试用例，而很多刚入门的只是测试执行。众所周知，我们的汉语文化是博大精深的，同样的一句话，放在不同的场合可能就有几种甚至很多种不同的含义。例如我们用 Xmind 的写了这样一条转账的 CASE“转出 100”,对于执行的人来说，他可能对需求设计并不完全了解，遇到这种情况，就需要找你确认 “转出前账户余额是多少”。如果的 CASE 都是这么写的，恐怕需要额外增加大量的沟通成本。

另外，在我们实际的项目中，需求文档很少能做到详尽、更新及时的。尤其现在多数互联网团队都采用敏捷研发模式。需求细节、需求变更的传递更多的是通过口头沟通、零散的邮件沟通等方式。在这种情况下，再没有一份完善的测试用例，那么我们的软件质量恐怕是难以想象的；对于执行的同学来说，就更无从下手了。

通过如上的分析，我们可以看出，测试用例另外一个很重要的作用就是 “测试执行的依据”。无论是编写人自己执行还是他人执行，在时间允许的范围内，我们都应该写的尽量详细。

给谁看？

我们编写所有的文档时，肯定都会有预期的读者。而对于测试用例，除了上文中提到的测试执行人员外，通常还包括产品、开发、测试 Leader、项目 Leader 等相关干系人。大家有没有想过为什么要给他们看？

通常在测试执行前，我们的测试用例都要通知开发、产品及相关测试人员一起评审下，尤其对于较大型或较复杂的需求。通过评审，其实我们完成了两件事儿：
1.让产品、开发、设计等人员分别站在自己的角度评估下，测试覆盖是否全面
2.完成需求再次确认。这样的一个确认过程，也起到了产品设计到技术设计的桥梁作用，因为通常技术设计不会写这么细致。而产品可通过测试用例了解测试人员理解是否正确，开发可通过测试用例回顾下自己的设计/编码是否与测试用例一致。

由此，我们又能看出测试用例另外一个作用就是 “确保相关人员需求理解一致”。当然评审中需要纠错的内容我们需要记录下来，最后要发一份确认的测试用例给相关人员。这样的一个过程通常可以有效减少 QA 的 “背锅” 量。

结束语

测试用例除了上面分析提到的作用外，通常我们还会提取部分冒烟用例给开发人员做提测前的自测、给业务人员/第三方进行验收测试；同时测试用例作为测试最主要的交付文档，需进行整理归档，以备后续迭代复用。

关于测试用例的作用，以上仅是个人实际工作经验的一点心得，希望对你能有所启发。同时，建议大家在应对面试题目时，应多思考 “面试官要考察什么”。有关测试用例设计方法、管理工具的问题，文中并没有进行分析，通用的方法和工具通过实践比较容易掌握。