测试工程师在入行时，都会接触到一个名词——测试用例，都知道测试用例是干什么用的，提到设计测试用例的方法，大部分测试工程师都会侃侃而谈：等价类法、边界值法、判定表法、正交分解法……这些方法说起来都如数家珍，但是似乎在实际工作中，应用起来还不是那么得心应手，甚至还会有测试用例覆盖度不足的问题。
每当遇到这样的问题时，测试工程师多少都会有些无奈。测试用例写的已经尽可能详细了，但是评审时候，参与评审的角色，要么是因为用例太繁复而草草浏览一下，要么是说完后面忘了前面。而测试工程师的思路从思维导图转化为测试用例的时候，也往往达不到测试用例最初的目的——哪怕让小白来遵照执行，也应该可以看得懂。
那么作为测试工程师基本功的测试用例编写，应该怎样上手呢？遵循着设计方法的测试用例，为什么写出来会那么晦涩难懂，让人很难理清思路呢？
一般说来，测试用例的覆盖设计和思路，同操作流程和开发思维是有极大不同的，除了实现验证这样的正向思路方向外，还需要针对异常情况进行逆向验证，而这里往往是很容易出现遗漏的地方。因为场景实现是有明确的操作流程的，而异常处理的场景，则是需要测试工程师自己进行分析的。
测试用例一般来说，分几大模块组成，主要的有操作步骤，输入数据，期望结果。需要注意的是，操作步骤是必须的，但输入数据允许留空，因为在很多时候，步骤仅仅只是一个动作，比如检视页面。对于测试用例的理解来说，操作步骤应该是非常细致的。以如下一个界面为例，详细了解一下测试用例到底该怎么写。
这是Slackflow的官网页面，选取了最常见的“注册”模块来进行UI的测试用例设计。首先按照场景分析，要先分为正常和异常两种情形，异常情况则是分析如下：
那么按照测试用例编写思路，需要形成如下表格：
在表格中体现的则是测试用例书写的一些规范和注意点：
1）操作步骤叙述必须足够简练明确，不得出现断层或无法执行的操作；
2）操作步骤必须具有由上至下的连贯性；
3）输入数据必须有具体示例，如字符串等等，如果没有具体示例，则需要说明输入的规范；
4）期望结果是需要一目了然的结果，而不是需要进行其他操作之后才能查看的内容，不可以包括多余的动作，也不可包括含混不清的判断，如仅注明“显示正常”，没有进一步的描述，或“顺利登录”这样的描述。
5）每一步都要进行的操作步骤，可以提炼为前置条件，写在“Pre-Condition“栏内
6）每一步骤和结果的描述必须精准洗练，不可以冗余和重复
7）每一个测试用例只覆盖一个检查点，如果多个用例都需要覆盖中间某一个检查点，则需将该检查点作为一个独立的测试用例，其余测试用例将该检查点的结果作为前置条件。
测试用例作为测试的输入文档，以及自动化测试的基础依据，应该是简洁优美的，它体现了测试工程师思维的逻辑性和递进性，它的质量直接关系到测试执行的质量，而执行时所能够达到的覆盖度则往往是测试工程师基本功的体现。
所以，在不断将眼光投向自动化代码能力和其他测试领域扩展的时候，还是需要先夯实自己的业务基础，先编写出简洁、全面的测试用例。
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
