测试同学绕不开的难题：什么是“好的”测试用例，如何写“好”测试用例？

测试工程师这一岗位发展到今天，自动化测试呈现越来越重的份量，不会自动化测试都不好意思说自己是做测试工作的了。那是不是说，点点点的功能测试将会逐渐退出历史舞台，我们以后无需设计功能用例了？

事实上，无论是点点点的功能测试，还是各种工具框架实现的自动化测试，功能用例的设计都是基础。自动化测试，也只是把功能用例用自动化的方式实现了。所以我们在学习和工作中时，千万不要只顾着自动化，而忽略了基本的功能用例设计的能力！

上一篇文章介绍了“什么是测试思维 – 测试工程师的核心技能”，是为了提高功能用例设计能力。那什么样的用例是好的用例呢，本文带你一探究竟！

一. 测试点和测试用例的区别

我们经常说，这个需求有哪些点需要考虑？这里说的点，即point，测试点。很多人分不清测试点和测试用例的区别，这里我们先来说说。

测试点是说明某个点需要测试。测试用例是测试点的详细说明，它还包括预置条件、测试步骤及预期结果。

更准确来说，一个完整的测试用例包含以下几个要素：

这里仍以微信支付功能里的零钱支付为例，对比下二者的区别。

【示例】测试点

 

 

 【示例】测试用例

 

注意：这里和实际的用例还是有区别的，因为我们只是针对零钱支付的金额进行设计的，实际用例中会先对业务流程做详细的步骤说明，针对某个点进行用例设计时步骤可能会简单一些，这里只是说明用例和测试点的不同。

二. 什么是好的测试用例？

在回答这个问题之前，先看看为什么要写测试用例，即没有测试用例行不行？答案是行，我们完全按照自己的想法对系统进行“随机性”测试。但同时也存在一些问题：

1. 执行了哪些用例，有没有遗漏？（覆盖性）
2. 执行了哪些用例，有没有重复执行？（效率）
3. 回归用例每次都需要重新写吗？（效率）
4. 做回归时凭记忆能够回归全面吗？（覆盖性）
5. 迭代开发的需要，业务变化不大，但以前的业务细节记不清了，怎么办？（效率）

针对这些问题，我们在做测试执行前要先写用例。如此，可以解决问题1）和问题2），当迭代次数少（2、3次）且相隔不太久时，可以找到之前的用例复用或回归，解决问题3）4）5）。但当迭代次数很多，且以前的数据不好追溯时，很难找到之前的用例，即使能够找到也会由于跟当前的功能有太多差异而无法复用，因此我们还需要做用例的沉淀，来维护一份和当前系统功能一致的用例库。显然，沉淀到用例库中的用例需满足以下特征：

1. 覆盖性——覆盖全面
2. 逻辑性——保证可复用性、可维护性，避免重复造轮子
3. 可读性——各要素如前置条件、步骤、预期结果等清晰、易理解

参考茹炳晟在《测试工程师 全栈技术进阶与实现》里对“好的”测试用例特征的定义（P6）：

1. 整体完备性
2. 等价类划分的准确性
3. 等价类集合的完备性

其实表达的意思是相通的，我这里加上了“可读性”，因为一份“可读性”差的用例直接影响到其使用价值！下文会有示例。

覆盖性、逻辑性、可读性，这三者并不是完全独立的，而是相辅相成的。

如果用例逻辑混乱，你很难保证它是覆盖全面的：

 

 如果用例可读性差，即使逻辑划分清晰，但理解起来就有困难，也就失去了维护的意义了！

 

 如果用例逻辑清晰，可读性好，也就很容易发现覆盖不全的地方而进行改进：

 

 

三. 如何写好测试用例？

知道了什么是“好的测试用例”，那如何写呢？其实有三个原则可以遵循：

1. 分析因素：逐个拆解用例需要考虑的因素（或维度）
2. 划分等价类：一定使用MECE分析法
3. 注意描述：描述要简明扼要

仍然以微信零钱支付金额为例。我们都知道，具体需求是：支付金额不能超过零钱的余额，且支持小数点后2位有效数字。

第一步，分析因素。支付金额需要是数字，那如果输入非数字例如字母a，会怎样？这里有了第一个因素（或维度），即是否是数字；数字有正有负，是否支持0和负数？这是第二个因素，即数字类型（考虑有理数）；支持小数，就有了整数和小数之分，于是第三个因素是小数点位数。

需要说明的是，划分并不是唯一的。譬如第三个因素，可以从“是否是整数”的角度来划分，也可以从“小数点位数”来划分，是等价的。

第二步，划分等价类。首先，分析完因素设计用例时，要保证每一个层级只考虑一个唯一的因素，也是为了保证MECE。例如，上图中的“正数”包含在“数字”中，而不能和它并列： 

 

接下来对“整数”和“小数”进行等价类划分。每个分支都根据MECE分析法划分有效等价类和无效等价类，例如针对“小数”的划分，支持小数点后2位有效数字，即1位和2位都可以，那输入3位系统会如何提示？都要设计出来。

第三步，注意描述。来对比描述不清的例子

 

失败：是怎样失败？我们在上一篇有提到，无效类有三种情况，所以具体是“无法输入”，是“可以输入但无法确认”，还是“可以输入并确认但提示报错”以及报什么错，都要明确写出来。因为有些面向最终用户的关键系统，用户体验很重要，不明确写出来在测试时很难注意到细节。

同样，成功了会怎样？扣款是否正确，收款方能否收到，这些都是关键的验证点。

正向示例如下：

当然，写好一个完整项目的测试用例，离不开深入的需求分析。本节内容是在需求分析的基础上，教你如何写出覆盖全面、逻辑清晰、可读性好的用例，这也是复用和维护测试用例的基础。如何衡量你的用例是否符合这些特征，这里提供三个tips：

1. 和开发、产品、及资深测试对齐，看他们在覆盖度上是否有补充；
2. 请资深测试人员审核你的用例，看是否有觉得不清晰不理解的地方；
3. 不定期回顾自己之前的用例，看是否有不清晰的地方。

总之一句话，多回顾多思考多总结。

四. 测试用例如何管理？

在说测试用例管理之前，首先要明确背景，即为什么要管理测试用例，我们在第二小节已经提到了，这里再详细总结一下：

1. 首先，一个测试用例可能既用于冒烟测试，又用于回归测试，以及不同级别的回归，需要一个方便的方法将其筛选出来
2. 业务系统会越来越复杂，有已经管理好的用例做参考，可以直观了解到某个模块涉及到的业务逻辑，有效避免漏测
3. 迭代开发时，要了解之前的逻辑。复用已有的测试用例，便于理解之前的业务逻辑，也避免了重复造轮子
4. 系统的重构，利用现有的用例，可以大大提升工作效率和质量

总体来说，管理测试用例是为了复用，复用的目的是为了提高测试效率和质量。

接下来看测试用例管理的目标：

1. 易读性：如果复用的用例表达不清，会失去复用的意义
2. 易维护性：即需要增删改查时要容易执行
3. 可复用性：需要回归或修改时可以很方便地拿来用

那有哪些工具可以管理测试用例呢？传统的excel现在已经弃用了，有一些开源的工具例如Jira、Bugzilla等，有些大公司会开发自己的管理平台。总之目的都是为了管理维护用例。

这些工具使用都不复杂，就不介绍了。也没必要去了解熟悉每一种工具的使用，用好当前的，其他的工具使用道理都是想通的。

五. 思考与总结

为了保证质量，提升效率，需要写“好”测试用例，并做测试用例的沉淀。“好的”测试用例满足以下特征：

a. 覆盖性

b. 逻辑性

c. 可读性

写“好”测试用例需要在深入分析需求的基础上，遵循以下三个原则：

a. 分析因素

b. 划分等价类

c. 注意描述

 

 

学习安排上

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

视频文档获取方式：

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