一个测试老兵眼里的测试用例-CSDN博客

本文链接：https://blog.csdn.net/kk_lzvvkpj/article/details/142522533

A公司面试官：

你认为测试用例的作用是什么？

B公司面试官：

你怎么看待测试用例评审的必要性？

C公司面试官：

编写测试用例的方法有哪些？

D公司面试官：

你们用什么工具编写测试用例？

······

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

作为一名有着几年面试经验的测试老兵，其中我最喜欢问的是第一项“你认为测试用例的作用是什么？”就是想考察你对基础的理解和认知。我们一起来看看下面这些回答：

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

在这里如果只是简单的罗列答案，想必大家看完后，很快就又忘到了九霄云外。因此，带着大家一起分析下，遇到类似的问题该如何回答：

古语云：”三思而后行”、”凡事预则立，不预则废”。应用在我们测试中，在测试执行前我们也要三思，一定不能鲁莽、不能操之过急；要做到有目标、有计划、有步骤。其中的目标、计划、步骤不单单要在“测试计划书”中体现，在测试用例中同样要体现。而测试用例的目标正是与它的作用紧密契合的。那么它都有哪些目标呢？我们不妨从以下三个方面考虑。

01 测什么？

02 怎么测？

03 给谁看？

测什么？

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

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

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

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

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

怎么测？

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

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

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

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