测试工程师都是怎么写测试用例的？

看到这个主题的时候，想起了我前某篇文章下面，有位同学留言“测试除了自动化框架和安全测试，其他的真的有难度吗?”。
这位同学的总结让我有些惊吓。

个人总结是：

测试工作中除了高级技术（比如自动化测试、性能测试、测试开发）有一定的难度，另外一个比较难的就是手工测试。

看似手工测试比较简单，其实要想做好手工测试还是比较难的，有没有真正的理解业务，有没有测试的思维，能不能测试的更全面。

总结：手工测试是整个测试工作的基础和核心。
手工测试执行比较简单，可能更多的是点点点，但比较难的是测试设计。
测试设计简单的可以理解成测试用例。

---

---

一. 为什么要写测试用例

1. 测试用例场景引入

比如，开发人员做了页面登录功能，然后给用户使用，用户使用过程中发现如下问题：
a、用户发现用户名只能输入字母数字，无法使用中文；
b、输入的密码长度没有限制，可以输一位长度密码，也可以输入很长的密码；
c、输错时，页面给出的错误提示信息不明确；
d、更换某个浏览器之后，发现输入密码的框输入不了任何字符； …
基于上述各种各样的问题，开发人员开发完毕后会做基本的测试么？肯定会，但是能全面的考虑测试全部么？不会，因为基于测试的专业性和时间等方面因素，无法全面的进行验证测试。

2、如何解决上述问题呢？

需要有专门的测试人员来进行全面的设计思考，并进行全面的测试，如何做到精准全面的测试呢？就需要设计编写测试实施的过程文档，这个文档就是常说的测试用例。

总结写测试用例主要目的，主要以下四个方面：
a、精准全面验证产品质量是否满足需求
b、避免测试过程出现遗漏
c、有助于测试工作进度的跟踪确认
d、方便上线验证和交付

二、总结什么是测试用例

1、名词解释

通俗来说，就是进行模拟用户使用，验证产品能否满足要求的例子 ；专业的说，就是为了特定目的而设计的由一组测试输入、执行条件、预期结果构成的文档 ；简单的说，就是将产品的需求梳理为一个个可验证的功能点，然后去验证其正确性。

2、用例形式

文本形式：Excel文档（最常见）、word文档、其他
思维导图形式：类似于xmind形式罗列测试大纲即可（适用于时间紧迫的场景）
代码形式：针对于自动化测试而言，也叫测试脚本（本篇章暂不展开，属于自动化范畴）

三、 怎么写测试用例

1、原则：

用最少的用例覆盖最多的测试范围
覆盖需求（需求明确描述的全面覆盖）
站在用户使用角度补充完善

2、用啥工具

• Excel文档：这种是最常见的，内容比较细化，方便管理跟踪验证，但是需要耗费一定的时间去设计编写。

  Xmind导图：这种也会出现，尤其对于一些项目时间比较紧迫的时候可以以思维导图形式梳理并跟踪验证。

  项目管理工具：这种需要相关的管理工具支持，与项目相关的产品、用例、bug都在一套工具中管理。（比如：禅道、QC等）

3、写什么？

结合编写测试用例的目的，个人在这儿提炼一下测试用例包含的核心要素是什么？下面以某网站的登录功能为例举例说明：

用例编号(ID)
作用：必填，区分不同用例，描述用例的唯一性，类似于学生的学号
构成：一般有三部分：项目简称-模块名-序号，项目简称和模块名建议英文简称，序号三位数字
示例：xxx-login-001

用例标题
作用：必填，描述测试人员要干什么？或者叫测试的目的
构成：期望的结果（构成的条件）
示例：验证登录成功（正确的账号和密码）

所属项目/模块
作用：选填，描述测试用例范围，如果不清楚可以不写构成：业务流程用例写项目简称；如果是单功能模块，写模块简称示例：登录

优先级
作用：必填，描述用例的重要程度（结合产品需求描述确定重要程度高低）
构成：一般有字母和数字组合描述（priority单词简写），如P0表示最高、P4表示最低，中间以此类推
示例：P0

预置条件
作用：选填，描述用例执行的前提条件，如果没有就不写
示例：账号已注册（要登录成功需要账号密码，前提是账号已注册）

测试数据
作用：选填，测试过程中用到的输入数据
示例：账号：admin 密码：123456

执行步骤
作用：必填，描述执行用例的先后步骤，建议别超过6步骤，否则太繁琐不便阅读。
构成：步骤序号+文字描述示例：
1.打开登录页面
2.对应输入测试数据
3.点击登录

预期结果
作用：必填，根据需求描述你希望达成的结果
构成：结果描述+现象构成（可以写多个现象）
示例：登录成功，1.页面提示登录成功的消息 2.页面跳转到xxx首页

4、怎么写？

从测试的内容和范围可以划分为2方面测试

产品业务流程的测试用例，简称业务流程
单功能模块的测试用例，简称单模块

4.1业务流程:

业务流程的测试设计是一个项目中最重要的功能测试，也是用户使用最频繁的功能。
业务流程，为了达成特定的目的而进行的一系列活动的统称。

比如：电商系统其中一个核心业务流程就是线上用户可以通过该平台完成下单购买商品的活动，这样的活动可以叫做下单业务流程。

业务流程用例的编写需要借助于流程图，流程图一般是由产品设计画出的，当然测试人员可以画，但是需要对整体的项目比较熟悉，也需要清楚流程之间的关联关系才能画出。

作为测试人员需要掌握一个基本技能，就是根据产品提供的业务流程图能找出对应的路径，并按照上述提供的模板编写出用例接口。

当然要直接能编写出业务流程用例还需要通过xmind梳理一下异常业务的测试点，这样设计更加全面。
例如：某下单业务流程图及测试点整理

4.2 单模块

首先，单功能先覆盖需求这种是最基本的测试用例编写可以直接按照需求整理出来即可，不需要太多思考主要是单功能的显示操作和规则入手，通过xmind整理测试点，然后通过测试用例模板编写用例。

例如，某商城的拼团功能单功能测试点
：

其次，单功能本身的业务

这种比较难以梳理，需要结合产品需求文档描述业务及产品介绍，和自身的测试经验及对项目的熟悉程度，从使用者角度出发，更多的思考与当前功能紧密相关的场景也就是从用户使用角度入手，从使用前，使用中，使用后三个角度入手，然后覆盖正向的业务测试点，还需要覆盖异向的业务测试点。
例如，拼团业务功能测试点：

最后，非功能测试点这种直接可以借助于质量模型的特性直接梳理即可非功能测试点的整理，对于不同类型架构方向设计基本是固定的。B/S 架构和 C/S 架构基本一致，C/S架构的还需要关注一些专项类的测试。