感觉测试用例好难写怎么办?

写在前面：测试用例是最基础，但是却非常重要，是支撑我们在测试道路上进一步学习其他测试技能的基本功。报了软件测试培训在线班后，报班的同学却还不知道怎么写测试用例，还要到知乎上求助，真是令人心痛。可见培训机构水很深，选择培训机构要睁大眼睛，不知道选择方法。

测试用例，是指导测试人员进行测试执行的重要文档，是测试人员的一项非常核心工作。作为测试培训机构，我来解答下。为了能彻底解答题主的疑惑，我将文章的结构先公布下：

1、明确动力，了解“测试用例”重要性

2、清晰样式，讲解“测试用例”格式八大要素

3、提前排雷，告知“测试用例”编写注意事项

4、案例巩固，手把手教“测试用例”如何撰写

5、拓宽眼界，有关测试用例学习资源分享

一、明确动力，了解“测试用例”重要性

什么是用例？

用例，就是用户使用软件的案例。

那什么是测试用例呢？

测试用例，是将用户使用软件的案例，做一个科学化的组织归纳，形成文档，以指导测试执行。

所以测试用例也可简单的阐述为：为特定测试目的，设计的测试执行文档。

测试用例有多么重要，只要我们从宏观上去看“软件的测试流程”就能知道。

完整的测试流程

完整的测试流程中，与用例有关的就有两个环节。所以测试用例的撰写工作非常重要，堪称是核心工作。因为重要，测试人员日常工作中，会花费大量时间来撰写测试用例。正如下图所示：

测试用例之所以如此重要？有3个原因：

原因1、测试用例可以防止漏测

测试用例是对测试工作提前进行编写和梳理。如果不把测试用例提前写成文档，测试人员会很容易遗漏测试场景。

原因2、测试用例是实施测试的标准

测试用例写清楚了测试什么，怎么测，测试人员按照测试用例的编写去执行，会非常明确，执行的过程和结果都是可控的，杜绝不同的人对测试场景认识的偏差。

原因3、测试用例是测试工作评估的重要依据

测试是否全面，通过测试用例也能直观的反应出来。也是测试人员工作量的一个评估

二、清晰样式，讲解“测试用例”格式八大要素

测试用例如此重要，那如何撰写测试用例呢？

先展示完整的测试用例格式给大家看。从用例格式可以看出，测试用例含有八大要素。

1、为集中注意力，先来掌握4大核心要素

我们先看红色字体的标明的4个要素，这4个要素是核心要素（以下介绍文字建议一个字一个字看）：

1）用例标题：用户书写测试目的和测试点，这是最重要的。格式建议采用“测试目的-测试点（概括，无概括文字可不写）”。比如图片中的“登录成功-正确的账号和密码”

2）测试步骤：为了达到测试目的，你需要通过哪些步骤，使用编号描述操作步骤，不显得混乱。

3）测试数据：操作步骤涉及的数据。如果操作步骤不需要数据，比如就是点击各类按钮，则可以为空。

4）预期结果：期望达到的结果。结果不是自己主观想象，而是来自可见的产品需求文档（产品经理提供，简称PRD）。

以上4个要素，需要测试人员重点要掌握。

2、讲完核心要素，再来了解非核心要素

另外4个就是非核心要素，我们也来了解一下：

1）用例编号：如果是软件来写用例，就无需关注该项。但如果是自己通过excel文档手写，那就需要按照格式“项目_模块_编号”来撰写，这种格式撰写，不容易重号。

2）前置条件：要执行此用例的前提条件。
举例上方截图案例，测试登录的前提是要先进入到登录页面，且qq号已经注册好了。

3）模块/项目：所属的项目或模块。以截图为例，我们现在测试登录模块，所以此处填写登录即可。
实际工作中，我们无需思考，因为产品需求文档（产品经理提供，简称PRD）都会规划清楚，只需要按照要求填写即可。

4）优先级：表示用例的重要程度或者影响力。这个要素比较重要。原则是对用户越重要的功能，优先级越高。

三、提前排雷，告知易犯错元素注意事项

测试用例8大要素介绍完成之后，为后面项目实践更加顺利，我们先来介绍6大易犯错元素，编写注意事项，先来提前排雷。

1、“用例标题”编写注意事项

用例标题，是用来表名测试目的。

合格的用例标题，可通过两个方面进行评判：

1）要清晰：团队其他人，通过用例标题，能清楚你要测试什么场景，无需看后面的测试步骤。

2）不能太繁琐：不要为清晰写一大串，其实只需要将核心的点标识清楚就可以。

2、“测试步骤”编写注意事项

合格的测试步骤编写，需要把握：

1. 一定要参考产品提供的原型页面和原型图。

2. 不要跳过某些步骤：原型图里的步骤和环节，在测试步骤中也要一步步写清楚。

3. 不要多步骤糅杂在一起：每一步表示一个动作，阅读起来才会清晰。

3、“测试数据”编写注意事项

怎么判定“测试数据”书写合理呢？

1. 内容前的标识（举例截图，是指“QQ号”、“密码”）一定要写清楚。这样团队的其他人执行用例时，也能清楚数据代表的意思，能够清晰执行。

2. 一定是把和测试步骤相关联的核心数据，单独构造出来，不要给团队其他人带来困惑。

3. 写死的数据，不需要填入测试数据，只需要在“前置条件”中写明即可。举例验证码，如果就是8888，那我就不需要在测试数据中说明。

4、“预期结果”编写注意事项

合格的“预期结果”，需要注意下面2点：

1. 要把预期结果写清楚。不要只写成功和失败。不然测试用例了执行者还要去查看产品需求文档，不然无法判断什么是成功，什么是失败。

2. 需求文档是怎么定义成功，怎么定义失败的，就怎么写，不可以省略。

5、“前置条件”编写注意事项

合格的“前置条件”，可注意下面这2点：

1）前置条件的前提是你的测试步骤是啥。所以先写测试步骤，再写前置条件。

2）绝大部分前置条件都需要满足的条件，就是默认条件，可以不写。比如网络正常（除非要做弱网测试，需要网络不正常）。

6、“优先级”编写注意事项

优先级，不要只写P0（最高级），那是不合理的。根据项目要求定即可。

普及下优先级编写，一般是P0~P3进行命名，为了大家更好理解，我加入“商城app"案例进行说明：

P0：最高优先级，验证业务流程，占比10-15%。
业务流程，代表用户使用你软件的最高商业价值
比如商城app里的，用户登录->搜索商品->加购物车->下单->支付->查看订单，这条核心业务线上的功能，就属于P0级。

P1: 高优先级，验证核心功能，占比20-30%。
比如商城app里的，使用账户余额支付订单，或注册账号，就都属于P1级别。

P2: 中优先级，验证一般功能，占比50%-60%。
比如商城app里，用户修改个人头像为png格式，就属于P2级别。

P3: 低优先级，验证特殊的预置条件和数据设置，占比10-15%。

比如3分钟在商城app上随机操作1万次，就属于P3级别。

具体填入什么，参考项目的划分即可。

结合“测试用例”8大要素简介+6大易犯错元素注意事项，总结下来，合格的测试用例，关键把握这个原则：

“不仅自己能执行，团队其他人也能执行才是过关的”。

四、案例巩固，手把手教“测试用例”如何撰写

经过上述两部分的阐述，现在再来编写测试用例是不是就容易了呢？接下来我们来案例验证下。

TP商城-产品需求文档（产品经理提供，简称PRD）

如上图产品需求文档PRD所示，我们需要针对“注册成功”和“手机号存在”设计两条测试用例，应该怎么撰写呢？

结合“测试用例”8大要素简介+6大易犯错元素注意事项，我们来试试：

Step1：先写模块+用例编号

需要按照格式“项目_模块_编号”来撰写，这种格式撰写，不容易重号。

项目是“TP商城”，模块是“注册”，编号定位001,002

所以用例编号和模块可以一并完成，如截图所示：

Step2: 用例标题

用户书写测试目的和测试点，这是最重要的。格式是“测试目的-测试点（概括）”

1）要清晰：团队其他人，通过用例标题，能清楚你要测试什么场景，无需看后面的测试步骤。2）不能太繁琐：不要为清晰写一大串，其实只需要将核心的点标识清楚就可以。

测试场景1）目的：注册成功，场景是：手机号不存在，也就是手机号未注册，

测试场景2）目的：注册失败，场景是：手机号已经存在，也就是手机号已注册

目的和测试点以“-”隔开，同时要满足清晰和不繁琐的要求，所以用例标题撰写如下：

Step3：优先级

优先级：一般是P0~P3进行命名
P0：最高优先级，验证业务流程，占比10-15%。
业务流程，代表用户使用你软件的最高商业价值
比如商城app里的，用户登录->搜索商品->加购物车->下单->支付->查看订单，这条核心业务线上的功能，就属于P0级。

P1: 高优先级，验证核心功能，占比20-30%。比如商城app里的，使用账户余额支付订单，或注册账号，就都属于P1级别。

P2: 中优先级，验证一般功能，占比50%-60%。比如商城app里，用户修改个人头像为png格式，就属于P2级别。

P3: 低优先级，验证特殊的预置条件和数据设置，占比10-15%。比如3分钟在商城app上随机操作1万次，就属于P3级别。

手机注册功能不属于业务流程上的功能，但属于核心功能（注册不成功，无法实现业务功能），所以定P1较为合适。

提示手机注册失败，不属于业务流程上的功能，相对而言，属于一般功能，所以定P2较为合适。

若拿不准，可根据项目要求来定即可。

Step4：测试步骤->前置条件->测试数据

“前置条件”2个注意点：

1）前置条件的前提是你的测试步骤是啥。所以先写测试步骤，再写前置条件。

2）绝大部分前置条件都需要满足的条件，就是默认条件，可以不写。比如网络

“测试步骤”3个注意点：

1. 一定要参考产品提供的原型页面和原型图。

2. 不要跳过某些步骤：原型图里的步骤和环节，在测试步骤中也要一步步写清楚。

3. 不要多步骤糅杂在一起：每一步表示一个动作，阅读起来才会清晰。

“测试数据”3个注意点：

1. 内容前的标识（举例截图，是指“QQ号”、“密码”）一定要写清楚。这样团队的其他人执行用例时，也能清楚数据代表的意思，能够清晰执行。

2. 一定是把和测试步骤相关联的核心数据，单独构造出来，不要给团队其他人带来困惑。

3. 写死的数据，不需要填入测试数据，只需要在“前置条件”中写明即可。举例验证码，如果就是8888，那我就不需要在测试数据中说明。

所以，先写测试步骤，一定要参考产品提供的原型页面和原型图，一步步写清楚：

原型图

结合原型图撰写测试步骤：

结合测试步骤撰写前置条件：

结合前置条件撰写测试步骤：

相同三步骤，我们也得到了注册失败时，3要素的填写：

Step5:预期结果

1. 要把预期结果写清楚。不要只写成功和失败。

2. 需求文档是怎么定义成功，怎么定义失败的，就怎么写，不可以省略。

需求文档定义的成功和失败

跟着我，手把手写完两个测试点的测试用例后，还感觉难吗？

希望听到你们说：不难。

特别说明：

因为本文是重点讲解测试用例如何写，所以选取了比较简单的登录功能作为案例。

但真实情况中，当我们拿到软件到撰写完测试用例，这中间大概有4个环节：1）分析软件需求 2）梳理软件规则 3）拆解软件测试点 4）转换成测试用例。

总结：

感谢每一个认真阅读我文章的人！！！

作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。

 

          视频文档获取方式：
这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片即可自行领取。