测试人世纪难题：如何写“好”测试用例？

比眉伴天荒 2023-09-24 16:34 22阅读 0赞

对于软件测试人员来说，有几大核心能力：

*  测试策略设计能力
 *  测试用例设计能力
 *  分析问题能力
 *  沟通协调能力
 *  自动化技术能力

这6大核心能力中，**最基本的一个核心能力就是测试设计能力**。所以我们今天先来谈谈怎么去培养我们的测试设计能力，从而去提升我们的测试思维。

测试用例设计能力指的是一种通用的放之四海而皆准的能力，拥有这个能力后，不仅在你熟悉的业务领域，而且在面对任何系统时都能熟练地把测试设计方法和具体业务有机结合，从而输出优秀的测试用例。

当然在这个过程中还考验你的总结归纳能力，因为很多用例场景或者说一些真正容易漏掉的场景是通过多积累，多归纳才能整理出来的。

有了这个总结归纳，你才能慢慢由点到线到面地形成体系化的用例设计思维。

## **1 什么是好的测试用例** ##

借用茹炳晟老师“池塘捕鱼”的一个例子来给大家分享一下。

如果把被测试软件看作一个池塘，软件缺陷是池塘中的鱼。“好的”测试用例集就是一张能够覆盖整个池塘的大渔网，只要池塘里有鱼，这个大渔网就一定能够把鱼给捞出来。

如果渔网本身质量是合格的话，那么捞不到鱼，就证明池塘中没有鱼，而渔网的好坏与池塘中是否有鱼无关。如果渔网过小，就可能会产生“漏网之鱼”。

对于测试用例其实也是同样的道理，**“好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷无关。**

希望借这个例子来帮大家理解一下什么是好的测试用例。

那一个“好的”测试用例必须具备哪些特征？

**首先它肯定是完备的集合，能够完全覆盖测试需求。**

这个完备性，就可以用MECE分析法来做，通过把一个整体划分成多个区域，这些区域是相互独立的，且是能够完全穷尽这个整体的。也就是说每块区域不要有交集，相当于减少了测试用例的冗余，同时区域间又不能有裂缝（也就是术语中的漏测）。

另外，根据项目的情况，好的测试用例还有一些扩展的特性，有些项目这个测试用例并不仅仅是自己来看的，还需要接下来的验收测试。

*  可执行性：别人拿着你的用例能够很通畅地把你的用例验证出来。
 *  可维护性：可维护性其实就是在说测试用例管理相关的，有些项目组的用例是放在线上的，那这份用例就可能需要别人来维护你的用例。
 *  兼容性：这条用例最好是兼容不同环境的，就比如不同的环境下可能测试步骤有一些细微的差别，或者说由于一些数据和配置的差别，实际的业务结果可能不太一样，但是又是可以找出一些共同的地方的，那就需要总结一下，或者加些字段进行区分来做到用例兼容性，避免维护多份用例。

## **2 如何写好测试用例** ##

我认为主要是分为几大块，这里总结了几个词来代表不同的级别：做得到、做到好、做到妙，层层递进。

**掌握测试用例常用的设计方法**

如果想做得到设计好测试用例的能力，那最基本的条件是你得掌握测试用例设计方法，通过技术手段、理论知识来武装自己。

常用的测试用例设计的方法有很多，如果你去看一些公众号或者书籍，会发现一堆让人眼花缭乱的测试方法，比如等价类划分法、边界值分析法、错误推测方法、因果图方法、正交实验设计方法、状态图分析方法、场景设计方法等等。

**但对大多数的软件测试而言，综合使用等价类划分、边界值分析和错误推测这三大类方法就足够了。**

当然，对于那些对质量要求很高的软件，比如航空、医疗、金融等直接关系到人的生命或者财产安全的，则是再多的方法都不为过。

接下来，我会结合实际的例子，给你解释一下这三类方法的核心概念以及在使用时需要注意的问题。

**1）等价类划分方法**

**等价类划分法是黑盒测试用例设计中最重要也是最常用的，**它将程序所有可能的输入数据划分成若干等价类，只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。一般分为有效等价类和无效等价类。

在规定范围内的是有效等价类，范围外的为无效等价类，测试的时候需要把两类都覆盖到。

比如，测试一个支持0~100数字的输入框：

*  有效类：0～100内的数字
 *  无效类：小于0，大于100，非数字类型

**2）边界值分析方法**

边界值分析法是对等价类划分法的一个补充，一般大家会选择等价类边界值分析的组合方式。

边界值一般都是从等价类的边缘值去寻找，从大量的实践经验看，往往大量的软件错误是发生在输入或输出范围的边界上，所以需要对边界值进行重点测试。

**边界值的基本思想是：应选取正好等于、刚刚大于、刚刚小于边界的值做为测试数据。**

比如上面我们已经分好了等价类，它的边界值就是比0，-1，1， 100，99，101。

**3）错误推测法**

错误推测法和目前非常流行的“探索式测试方法”的基本理念是非常相似的，特别适合于测试时间比较紧张的项目中，但是，这个方法的缺点也显而易见，过度依赖测试人员自身的能力。

**它的核心思想是在测试程序时，测试人员可以根据经验或直觉推测程序中可能存在的各种错误。**

总之，就是对程序进行错误的操作，从而验证程序是否对出错的场景有应对能力。

比如用户登录时，如果密码输入错误，就会有登录失败的相关提示。这个就是一个比较典型的错误推测法的例子。

我们可以来看一下通过这三种方法，关于用户登录这个最常用的场景能设计哪些用例。

![8a044f9acd9e41d2b8610241a358f71d.png][]

**做好需求分析**

俗话说，技术不能脱离业务而单独存在。只靠技术是远远不够的，更重要的是站在用户的视角，深度挖掘需求，多问问为什么，找到真正核心的场景，再辅于第一步掌握的技术手段，把场景考虑的更全、更细，从而去做好用例设计。

可以说，如果做到了这一步，基本上就是一个很厉害的测试工程师了。

![bec05d6f80af4530a7846dc4c25a0f41.png][]

**1）获得原始需求**

大家都知道，需求文档是设计测试用例的依据，当拿到需求文档甚至于在需求评审的时候，测试人员就可以从需求文档中找出用户最原始的需求，比如：用户可以成功登录系统。

**2）从原始需求拆出需求点**

这一部分往往在需求书中是有说明的，比如对于一个用户登录涉及到需求点至少会包括用户注册、用户登录、用户管理等。

**3）从需求点进一步拆分出测试点**

**主要从单一功能测试+功能交互测试+隐性需求验证三大方面来拆分出测试点。**

比如我们可以先测用户注册、用户登录、用户管理这三个单一功能模块，然后我们可以再把用户注册和用户登录用户管理之间交互的功能串成一个场景。

比如用户注册后才能登录，未注册不能登录，编辑用户的权限后重新登录可以权限生效，修改密码后能成功登录等，这些都是功能模块间的交互的场景。

单一功能测试和功能交互测试主要还是侧重于显性需求验证，在这之后，我们可以继续列出隐性需求测试点，比如易用性、兼容性、安全性、性能等。

当然有的时候根据项目的轻重缓急以及项目的实际情况，并不是所有的隐性需求都需求验证的，比如上线初期，其实并不会考虑兼容性、安全性、性能等问题。主要还是功能相关。

**4）从测试点细化到测试用例**

对于识别出的测试点，再去综合运用已经掌握的测试设计方法进行用例设计。

**所以写好写全用例最重要的一步是如何从需求点拆分出测试点，这将直接关系到用例的测试覆盖率。**

假如你没有识别出用户登录功能的性能测试需求，那么后续设计的测试用例就完全不会涉及性能相关的场景，上线后就有可能会造成性能相关的故障。

下面我们以一张图来看一下这个解析过程。

![6ea22d32853348a5b713fce05df90ef0.png][]

当然在实际的操作过程中，从需求点分解到测试点的过程并不是那么容易的，一方面你需要对系统的业务有较好的理解，另一方面你必须对内部的架构有清楚的认识，比如系统内各个组件的通信和交互、数据库连接方式、redis读写分离、缓存机制等。

只有这样你才能设计出除了表面的用例外的更深一层次的测试场景。

在这里，**我们可以通过引入需求覆盖率和代码覆盖率等相关的工具来衡量测试执行的完备性，并以此来找出遗漏的测试点。**

**根据项目组的特点**

**提前制定好对应的测试用例模板**

第3步其实是一个辅助的步骤，有了比较全的用例场景，如何让别人更舒服更方便的去用你的用例，有条理的去展示你的用例。这里我用了一个词——更美妙。

一般来说，大家经常听到测试用例模板会包含以下要素：

*  测试用例编号：测试用例的唯一标记
 *  用例标题：测试用例的主要内容，通过标题，能清楚知道该测试用例的意图
 *  前置条件：测试用例顺利执行的前提条件，如一些基本的配置，基础的步骤，比如登录到某一系统
 *  测试数据：测试时使用的测试数据
 *  测试步骤：如何执行这个测试用例，每步的操作是什么，只需要写和测试目的密切相关的步骤，一些基础的步骤可以放在前置条件中
 *  预期结果：和测试步骤对应起来，操作后希望系统的返回，预期结果是清楚准确，没有歧义的
 *  优先级、备注等

**测试用例其实就是在某种场景下，执行一定的动作，达到什么样的结果。**所以最不可缺少的是前置条件、测试步骤和预期结果，其他的一些元素，都是根据各自项目组的要求和特点来添加的。

没有好坏和对错，适合自己的就是最好的，不要盲目的把所有的字段都加上。编写测试用例前，要考虑到谁会用到测试用例以及用法。

![fc9bc35e1f5b421481c65962ade862dd.png][]

除此之外，还有一些日常注意事项：

*  **控制用例的粒度**

用例的粒度，就是用例包含的测试内容。从测试执行者的角度来说，过细的测试用例会让执行者感觉烦琐、疲惫；过粗的测试用例又容易遗漏检查点。

下述经验值可以作为大家在控制用例粒度时的参考：

1、测试用例标题不要超过30个字

2、测试用例步骤不多于7步，不少于2步

3、预期结果不要多于5个，不少于1个

*  **用例间要解耦**

我们经常遇到几个用例有先后顺序的情况，比如我们有一个页面，上面有新增、编辑的功能。

当我们在测试编辑的功能的时候，肯定是需要事先存在一条数据的，那最好的就是你把新增功能放在编辑功能的前置条件中，还有一种方式就是把新增用例和编辑用例放在一条大用例里面。但是我推荐第一种方法。

*  **预期一定要明确**

测试步骤和预期结果要能对应起来，要指明每一个预期结果是对应哪一步的。同时，步骤和预期中不要出现多次、反复、一定时间等模糊字眼。

*  **标题要清晰**

标题建议采用场景+预期结果的描述，比如用户输入正确的用户名和密码后能成功登录系统。

*  **拒绝冗余**

用例可以多，但是一定不要冗余，一定要尽可能以最小的场景覆盖最全的范围，比如同一个等价类你只需要测一条数据即可。

当然，因为测试的不可穷尽性，测试场景肯定不会最全面。同时往往受限于时间成本和资源，是很难执行这么详尽的用例的。

而这个时候就需要在有限的资源下，寻求质量和效率之间的平衡点，这就又引申到了测试策略，所以测试再往深了做就是测试策略了。

总体是采用基于风险驱动的模式，有侧重地去验证一些测试场景，优先核心功能。或者说增加资源或者延长上线时间，同时去寻求自动化相关技术去提升整体的效率。

## **3 总结** ##

总结一下，写好测试用例需要三步走：

*  第一步掌握常用的测试用例设计方法，尤其是等价类划分、边界值、错误推测法；
 *  第二步，学会需求分析，不仅要挖掘功能需求，还要挖掘一些隐式的需求；
 *  第三，选择适合的测试用例模板让你的用例更美妙地呈现出来。

最后再送给大家一句话：久久为功，善作善成。质量不是一蹴而就的，需要各方相互协助，逐步去优化流程，提升相关的技术，持之以恒，总会有攀上质量高峰的一天。

**最后：**在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。**`【保证100%免费】`**

![eacd6b72c45944d297f8bee39f56d0a3.png][]

![4ecb01dd12174b998f5f1b083b6da08f.png][]

[8a044f9acd9e41d2b8610241a358f71d.png]: https://img-blog.csdnimg.cn/8a044f9acd9e41d2b8610241a358f71d.png
[bec05d6f80af4530a7846dc4c25a0f41.png]: https://img-blog.csdnimg.cn/bec05d6f80af4530a7846dc4c25a0f41.png
[6ea22d32853348a5b713fce05df90ef0.png]: https://img-blog.csdnimg.cn/6ea22d32853348a5b713fce05df90ef0.png
[fc9bc35e1f5b421481c65962ade862dd.png]: https://img-blog.csdnimg.cn/fc9bc35e1f5b421481c65962ade862dd.png
[eacd6b72c45944d297f8bee39f56d0a3.png]: https://img-blog.csdnimg.cn/eacd6b72c45944d297f8bee39f56d0a3.png
[4ecb01dd12174b998f5f1b083b6da08f.png]: https://img-blog.csdnimg.cn/4ecb01dd12174b998f5f1b083b6da08f.png