测试基本功——测试用例的编写

lsekfe

测试工程师在入行时，都会接触到一个名词——测试用例，都知道测试用例是干什么用的，提到设计测试用例的方法，大部分测试工程师都会侃侃而谈：等价类法、边界值法、判定表法、正交分解法……这些方法说起来都如数家珍，但是似乎在实际工作中，应用起来还不是那么得心应手，甚至还会有测试用例覆盖度不足的问题。

每当遇到这样的问题时，测试工程师多少都会有些无奈。测试用例写的已经尽可能详细了，但是评审时候，参与评审的角色，要么是因为用例太繁复而草草浏览一下，要么是说完后面忘了前面。而测试工程师的思路从思维导图转化为测试用例的时候，也往往达不到测试用例最初的目的——哪怕让小白来遵照执行，也应该可以看得懂。

那么作为测试工程师基本功的测试用例编写，应该怎样上手呢？遵循着设计方法的测试用例，为什么写出来会那么晦涩难懂，让人很难理清思路呢？

一般说来，测试用例的覆盖设计和思路，同操作流程和开发思维是有极大不同的，除了实现验证这样的正向思路方向外，还需要针对异常情况进行逆向验证，而这里往往是很容易出现遗漏的地方。因为场景实现是有明确的操作流程的，而异常处理的场景，则是需要测试工程师自己进行分析的。

测试用例一般来说，分几大模块组成，主要的有操作步骤，输入数据，期望结果。需要注意的是，操作步骤是必须的，但输入数据允许留空，因为在很多时候，步骤仅仅只是一个动作，比如检视页面。对于测试用例的理解来说，操作步骤应该是非常细致的。以如下一个界面为例，详细了解一下测试用例到底该怎么写。

这是Slackflow的官网页面，选取了最常见的“注册”模块来进行UI的测试用例设计。首先按照场景分析，要先分为正常和异常两种情形，异常情况则是分析如下：

那么按照测试用例编写思路，需要形成如下表格：

序号	操作步骤	输入数据	期望结果
1	鼠标单击“Display Name”		文本框被选中，光标闪烁
	输入不足6位	abcde	文本框显示“abcde”
	光标失去焦点，单击下一对话框或按“Tab“键		-文本框变为红色    -文本框下方显示“用户名不符合要求，请重新输入“
2	鼠标单击“Display Name”		文本框被选中，光标闪烁
	输入33位长度内容		文本框显示输入的前32位内容（注：长度限制有若干种形式，需要在需求澄清时予以确认，并在测试用例编写中进行覆盖：    1.      输入至最大长度后，多余字符无法再输入    2.      输入至最大长度后，再输入的内容会被自动删除，始终只显示32位    3.      输入至最大长度后，再输入的内容仍然能正常显示，但系统只截取前32位）
	光标失去焦点，单击下一对话框或按“Tab“键		-文本框变为红色    -文本框下方显示“用户名不符合要求，请重新输入“

在表格中体现的则是测试用例书写的一些规范和注意点：

1）操作步骤叙述必须足够简练明确，不得出现断层或无法执行的操作；

2）操作步骤必须具有由上至下的连贯性；

3）输入数据必须有具体示例，如字符串等等，如果没有具体示例，则需要说明输入的规范；

4）期望结果是需要一目了然的结果，而不是需要进行其他操作之后才能查看的内容，不可以包括多余的动作，也不可包括含混不清的判断，如仅注明“显示正常”，没有进一步的描述，或“顺利登录”这样的描述。

5）每一步都要进行的操作步骤，可以提炼为前置条件，写在“Pre-Condition“栏内

6）每一步骤和结果的描述必须精准洗练，不可以冗余和重复

7）每一个测试用例只覆盖一个检查点，如果多个用例都需要覆盖中间某一个检查点，则需将该检查点作为一个独立的测试用例，其余测试用例将该检查点的结果作为前置条件。

测试用例作为测试的输入文档，以及自动化测试的基础依据，应该是简洁优美的，它体现了测试工程师思维的逻辑性和递进性，它的质量直接关系到测试执行的质量，而执行时所能够达到的覆盖度则往往是测试工程师基本功的体现。

所以，在不断将眼光投向自动化代码能力和其他测试领域扩展的时候，还是需要先夯实自己的业务基础，先编写出简洁、全面的测试用例。