10年测试人竟不会写测试用例，简直无地自容

而测试工程师的思路从思维导图转化为测试用例的时候，也往往达不到测试用例最初的目的——哪怕让小白来遵照执行，也应该可以看得懂。

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

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

因为场景实现是有明确的操作流程的，而异常处理的场景，则是需要测试工程师自己进行分析的。

测试用例一般来说，分几大模块组成，主要的有操作步骤，输入数据，期望结果。

需要注意的是，操作步骤是必须的，但输入数据允许留空，因为在很多时候，步骤仅仅只是一个动作，比如检视页面。

对于测试用例的理解来说，操作步骤应该是非常细致的。

以如下一个界面为例，详细了解一下测试用例到底该怎么写。

这是Slackflow的官网页面，选取了最常见的“注册”模块来进行UI的测试用例设计。

首先按照场景分析，要先分为正常和异常两种情形，异常情况则是分析如下：

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

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

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

• 1） 操作步骤叙述必须足够简练明确，不得出现断层或无法执行的操作；
• 2） 操作步骤必须具有由上至下的连贯性；
• 3） 输入数据必须有具体示例，如字符串等等，如果没有具体示例，则需要说明输入的规范；
• 4） 期望结果是需要一目了然的结果，而不是需要进行其他操作之后才能查看的内容，不可以包括多余的动作，也不可包括含混不清的判断，如仅注明“显示正常”，没有进一步的描述，或“顺利登录”这样的描述；
• 5） 每一步都要进行的操作步骤，可以提炼为前置条件，写在“Pre-Condition“栏内；
• 6） 每一步骤和结果的描述必须精准洗练，不可以冗余和重复；
• 7） 每一个测试用例只覆盖一个检查点，如果多个用例都需要覆盖中间某一个检查点，则需将该检查点作为一个独立的测试用例，其余测试用例将该检查点的结果作为前置条件。

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