前言

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

如何写好测试用例

做好需求分析

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

总结

前言

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

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

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

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

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

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

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

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

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

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

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

如何写好测试用例

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

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

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

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

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

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

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

1）等价类划分方法

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

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

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

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

2）边界值分析方法

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

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

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

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

3）错误推测法

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

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

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

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

做好需求分析

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

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

1）获得原始需求

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

根据项目组的特点

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

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

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

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

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

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

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

控制用例的粒度

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

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

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

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

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

用例间要解耦

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

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

预期一定要明确

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

标题要清晰

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

拒绝冗余

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

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

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

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

总结

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

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

一个好的测试用例怎么写？我来告诉你相关推荐

初入测试如何编写测试用例？从3个方面带你写一个合格的测试用例
前言作为一个测试新人,刚开始接触测试,对于怎么写测试用例很头疼,无法接触需求,只能根据站在用户的角度去做测试,但是这样情况会导致不能全方位的测试APP,这种情况就需要一份测试用例了,但是不会写,求指 ...
软件测试 | 测试用例——如何写好一个用例
测试用例(Test Case)是为某个测试目标而编制的一组测试输入.执行步骤以及预期结果的集合,以便测试某个程序的路径或验证软件是否满足某个特定需求,那么怎么写好一个用例呢? 1.什么叫测试用例测 ...
新手必看：怎么写一个合格的测试用例？
摘要前段时间有很多小可爱给我们留言,想知道怎么写一个合格的测试用例. 来一起学习怎么写一个合格的测试用例吧! 1.测试用例是什么? 测试用例是指对一项特定的软件产品进行测试任务的描述,体现测试方案. ...
测试用例怎么写？这里提供一个测试用例小模板
文章目录模板怎么写用例? 模板用例编号测试模块用例名称(测试项目) 前置条件操作步骤预期结果测试结果重要程度更新时间测试人员能否接口自动化能否 UI 自动化备注信息项目代 ...
uat测试用例怎么写_你会写测试用例吗
作为一名测试工程师,写测试用例作为一项最最基本的技能谁不会啊!但就是这最基本的技能也会存在很多问题,今天就跟大家分享下写测试用例这件事情上存在的的一些问题和对应的思考: 为什么要写测试用例啊,测试用例 ...
怎么的测试用例是一个好的测试用例?
怎么的测试用例是一个好的测试用例? 每次一说要对比或者评价的时候,我都很担心,怕评价的方面或者结果是"我以为的就是我以为的"这种结果.因此我都查了很多的资料,然后才敢写点东西,我尽 ...
医疗系统流程软件测试用例,如何写全流程的测试用例 - rose8561900的个人空间 - 51Testing软件测试网 51Testing软件测试网-软件测试人的精神家园...
最近参与了一个小项目,需要写全流程的测试用例,有一些自己的心得.总结如下两种方法给大家参考: 1.写全流程测试用例之前可以先把系统的整体业务流程用Visio画一下,流程图中需要画全涉及到的所有的模块 ...
[转]一个纸杯的测试用例
一个带广告图案的花纸杯,我们能想出多少个测试用例呢?想必很多人都在网上看过微软公司面试软件测试职位的这个考试题,由于当时对软件测试理论和测试用例的设计知之甚少,看到这个题目的时候不知所措,我试着以开 ...
02.如何设计一个“好的”测试用例？
文章目录什么才算是"好的"测试用例? "好的"测试用例必须具备哪些特征? 三种最常用的测试用例设计方法第一,等价类划分方法第二,边界值分析方法第三,错误 ...

一个好的测试用例怎么写？我来告诉你

前言

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

如何写好测试用例

做好需求分析

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

总结

一个好的测试用例怎么写？我来告诉你相关推荐

最新文章

热门文章