如何编写优秀的测试用例，建议收藏和转发

Posted 2023-04-05 测试界的飘柔

1、测试点与测试用例

测试点不等于测试用例，这是我们首先需要认识到的。

问题1：这些测试点在内容上有重复，存在冗余。

问题2：一些测试点的测试输入不明确，不知道测试时要测试哪些。

问题3：总是在搭相似的环境，做类似的操作。

问题4：测试点描述得太粗，不知道是不是测对了。

测试点是测试者在测试时需要关注的地方。虽然我们在分析测试点时，会使用各种测试方法，但这些方法在思路和操作上都是不同的，一些方法得到的测试点要细一些、具体一些，一些方法得到的测试点粗一些、泛一些是非常正常的。另外，谁也不能保证这些测试点之间不会重复或是相互包含。如果我们的测试就是按照这样一份粗细不一、深浅不明、关系不清的说明书来进行的，又怎么不会陷入既冗余又不足的困境中呢？

而测试用例是在测试点“加工”的基础上得到的。首先把测试点“去重”（去掉重复的内容）、“合并”（把太细的测试点合并起来）、“细化”（把太泛的测试点说清楚、说具体），然后再确定各个测试点的测试条件、测试数据和输出结果。如果说测试点还只是一些散乱的测试思路的集合，那么测试用例就是一份真正能够指导测试的测试说明书。

2、测试用例设计流程

1、创建测试用例模板

2、设计基础测试用例

3、测试用例评审（内审+外审）

4、补充测试用例

5、扩展（探索性等）

3、编写测试用例

1、首先确定一个标准的模板

一般包含以下几项（可根据公司需要做裁剪或添加）：

用例编号 所属模块 用例标题 优先级 适用阶段 前置条件 测试数据 操作步骤 预期结果 执行结果 备注

2、测试用例标题要是一个完整易懂的句子

能够清晰表达测试用例的测试目的和关键测试要素，只有当测试用例标题是一个完整的句子时，读者才能完整地了解这个测试用例的意图。

用例标题要求一句话简单描述（在/当。。。时候/之后/页面，主语+谓语+宾语）

3、用条件而不是参数来描述测试用例标题

如果你有对比就会发现，使用条件来作为测试用例标题，和使用参数相比，前者更能突出设计这个测试用例的目标，也易于读者理解测试用例的设计意图，也更易于维护。可见，在描述测试用例标题时，更适合用条件，而不是参数。参数更适合在测试用例模板中的测试数据部分体现，不要把它们罗列在测试用例标题中。

4、如果一个用例中包含有多个参数，用例中应该是每个参数的取值

我们在写测试用例的时候，应该对涉及的每个参数给出确定的值。

5、不要在测试用例中引用别的测试用例

引用测试用例会给后期用例的修改、维护和移植带来麻烦。

我们会在测试用例中引用另外一个测试用例，在很大程度上是因为用例在执行中存在先后关系，即测试用例2一定会在测试用例1之后执行。这时我们可以考虑这样来编写测试用例：把测试用例1和测试用例2合并成一个大的测试用例。可以把测试用例1的主要内容放到测试用例2的预置条件中。

6、避免测试用例中包含过多的用户接口细节

用例执行者应该是专业人士，测试用例不必写得面面俱到。

7、明确测试步骤和预期结果的对应关系

一个测试用例通常会包含好几个测试步骤和多个预期结果。有时候不同的测试步骤可能会有相同的预期结果，为了描述简便，很多测试用例作者会省略相同的预期结果。另外，也不是所有的测试步骤都有预期结果，一般是重要、关键的测试步骤才会有预期结果。这时我们可以在测试用例中，增加简单的标记来明确测试步骤和预期结果之间的对应关系，让测试执行人员一目了然。

8、避免在测试步骤中使用笼统的词

我们在描述测试步骤时，需要尽量避免那些笼统的表述方式，如“反复”、“长时间”、“大量”等。因为这样描述，不同的测试执行者的理解会有所不同。比如“反复”，有人会认为执行两次就是反复了，有人可能会认为要执行至少10次，这样就会造成测试执行上的差异，很可能会达不到测试的效果。

例1：明确次数

问题：反复执行接口up/down的操作

解决方法1：在测试用例中确定反复的具体次数。

修改1：反复执行接口up/down操作100次。

解决方法2：也可以为测试用例确定一个反复的范围。

修改2：反复执行接口up/down操作至少100次。

解决方法3：如果反复多次执行某个操作多次后，会出现某种特定的效果（例如内存会升高到某个特别值），但是需要反复执行多少次这样的操作确并不确定，可以这样描述。

修改3：反复执行接口up/down操作，直至系统内存值达到最大值的45%。

例2：明确时间

问题：系统长时间转发HTTP业务

解决方法1：在测试用例中确定长时间的测试时长。

修改1：系统持续转发HTTP业务24小时。

解决方法2：也可以为测试用例确定一个长时间的测试时间范围。

修改2：系统持续转发HTTP业务至少24小时。

例3：明确数量

问题：大量用户同时连接服务器

解决方法1：需要确定大量的具体数量，如1000、2000。

修改1：2000个用户同时连接服务器。

解决方法2：可以以产品规格作为大量的参照值，如满规格、系统支持数的50%。

修改2：满规格用户同时连接服务器。

4、测试用例评估

测试过程评估分析的对象是测试用例、测试方法和测试投入。

为什么进行产品质量评估还需要对测试过程进行分析呢？试想对一个产品测试来说：

1、有充分完备的测试用例和没有测试用例进行随机测试相比，哪一种测试的结果更可靠？

2、使用了多种测试方法与测试方法单一相比，哪一种测试结果更有助于进行产品质量评估？

3、有经验的测试人员、充足的测试投入与没有经验的测试人员、测试投入不足相比，哪种测试情况更有利于测试目标的实现呢？

可见，对测试过程进行评估，对产品质量评估而言十分重要。不仅如此，如果我们能够在测试之前就对测试过程进行计划，还能帮助我们更好地进行测试，更好地完成产品的测试目标。

我们可以通过如下3个指标来对“测试用例”进行评估：

1、测试用例执行率

（1）测试阻塞 - 试用例因为产品开发（一般是指缺陷）、测试（如测试环境不具备）等原因，无法被执行的测试用例。

（2）未执行 - 可以执行，但是因为进度、人力或其他原因等还没有被执行的测试用例。

2、测试用例执行通过率

（1）首次执行通过率 - 测试用例首次执行通过率可以帮助我们评估开发版本的质量，测试用例首次执行通过率越高，说明开发的版本质量不错；相反，如果开发需要多次修复，最后才能使得测试用例执行通过，说明版本质量可能不高，产品在设计、编码方面可能存在一些问题，即便是修复bug，在修复时引入新bug的风险也会更大一些。

（2）累积通过率 - 测试用例累积执行通过率可以帮助我们评估产品在发布时的质量，一般说来，测试用例累积执行通过率越高，说明当前的版本质量可能已经达到了基本要求，可以考虑发布。

3、测试用例和非测试用例发现缺陷比

测试人员在按照测试用例执行测试的时候，也会抛开测试用例，自我发挥，做些随机测试。显然，随机测试也能发现缺陷，有时候甚至比测试用例更能发现产品缺陷，而且“突然一个灵感来了，然后去测试，并且真的发现了产品缺陷”的过程，会让人很有成就感。因此在团队中，我们往往会鼓励大家在执行测试用例的时候适当进行一些探索性测试，挖掘bug，找找感觉。

我们希望“通过测试用例发现的缺陷”和“探索性测试，也就是非测试用例发现的缺陷”的比值能够在一个合理的范围内。

5、跟踪测试用例执行情况

跟踪测试执行的目的有3个：

1、确保测试团队是按照测试策略来执行测试的。

2、实时关注缺陷，通过缺陷分析来确认测试策略是否合适，是否需要调整。

3、关注项目中的实时风险，基于风险来调整测试策略。

需要特别注意的是，按照优先级来执行测试用例，不是说我们一开始就只执行高优先级的测试用例，而不去执行中、低优先级的测试用例。

我们需要在测试刚开始的时候，对每个功能都执行一些基础性的测试用例，以确认这些功能基本可用，不会阻塞后续的测试。

配置测试→功能测试→功能交互→业务流程测试。

---

资源分享

下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码，朋友们如果需要可以自行免费领取 【保证100%免费】

面字节跳动Python软件测试用例编写面试建议收藏

　    黑盒-判定表

　　判定表：分析和表达多逻辑条件下执行不同操作的情况的工具 ；略过因果图的绘制，直接列出所有组合进行筛选；

　　分析思路：判定表通常有四个部分组成：条件桩、动作桩、条件项、动作项；

　　判定表的建立步骤：（根据软件规格说明）

　　确定规则个数；列出所有条件桩和动作桩；填入条件项；填入动作项，得到初始判定表；简化合并相似规则；

　　==使用场景：控制类和游戏。优点是能把复杂的问题按各种可能的情况一一列举出来，简明而易于理解，也可避免遗漏。缺点是不能表达重复执行的动作，例如循环结构。

　　黑盒-正交试验法

　　正交实验法：利用因果图来设计测试用例时, 输入原因与输出结果之间的因果关系,有时很难从软件需求规格说明中得到；往往因果关系非常庞大,以至于测试用例数目巨大，为了有效地、合理地减少测试的工时与费用,可利用正交实验设计方法进行测试用例的设计。

　　分析思路：

　　（1）提取功能说明,构造因子–状态表 ；

　　（2）加权筛选,生成因素分析表 ；

　　（3）利用正交表构造测试数据集 ；

　　使用场景：必须考虑输入条件的各种组合（从大量的数据中挑取适量、有代表性的点，合理有效的测试）。

　　黑盒-场景实验法

　　场景实验法：软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果形成事件流；生动的描绘出事件触发时的情景，有利于设计用例，同时测试用例也更容易的得到理解和执行。

　　分析思路：

　　每条路径都反映了基本流和备选流；基本流是最简单的路径；备选流自基本流开始，会有特定条件下加入并执行，可能有多种情况；

　　使用场景（0代表基本流）：0；0+1；0+1+2；0+3；0+3+1；0+3+1+2；0+4；0+3+4；…

 

 

　　7、错误推断法

　　错误推断法：基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法；更多的与用户的使用习惯及测试程序中的常见问题为主。

　　分析思路：

　　（1）列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据这些情况选择测试用例；

　　（2）注意积累与分享；

　　使用场景：任何测试、任何情景下都会用到的方法。

　　有常用的测试用例集，可以参照。

　　举例：数字输入验证，分别输入数字(正数、负数、零值、单精度、双精度)、字符串、空白值、空值、临界数值；不合法的输入，系统给出必要的判断提示信息；

　　8、黑盒-需求转换法

　　需求转换法：根据需求，执行需求分析，并编写测试用例。

　　分析思路：

　　（1）将需求转换为思维导图；

　　（2）仔细推敲每一个字的含义；

　　（3）与用户的使用场景和目的结合；

　　（4）严格设计每一个用例；

　　（5）可以建立一种模型，进行需求转换；

　　使用场景：任何测试、任何情景下都会用到的方法。

　　注意：需求的变更带来的影响；需求理解偏差带来的影响；需求含糊不清带来的影响等；

　　9、黑盒-设计文档

　　设计文档：参照设计文档，可以理解软件系统内部设计流程及处理机制，对比写好的测试用例，可以在对应功能及模块处新增；

　　分析思路：

　　（1）仔细阅读设计文档；

　　（2）与相关人员沟通实现机制；

　　（3）结合测试用例编写方法，对比之前写好的用例；

　　使用场景：任何测试、任何情景下都会用到的方法。

　　注意：设计文档的编写正确性；设计文档的理解偏差；

　　10、黑盒-探索式测试法

　　探索式测试法：无限创意的测试点，永无止境的探索测试；我们要在测试的最前沿发挥洞察力、技术及应变措施，找出产品的缺陷；

　　分析思路：

　　局部探索式测试；全局探索式测试；混合探索式测试；

　　使用场景：任何测试、任何情景下都会用到的方法。像漫游一样，自由地寻找软件中的缺陷，软件测试的未来必然有探索式测试。

　　第二部分：白盒用例编写

　　基本思路：

　　第一步需要绘制流程图；

　　第二步根据路径分析法确定测试用例；

　　第三步使用等价类/边界值的方法确定测试用例的数据

　　第四步根据实际情况补充（如默认流程、特殊流程等）

　　基本策略：

　　1、语句覆盖准则基本上没啥用，比较强的逻辑覆盖准则是判定覆盖或者条件覆盖；通常判定覆盖可以满足语句覆盖；语句覆盖<判定覆盖<条件覆盖；

　　2、循环覆盖来说，完全的路径测试并不符合实际。

最后为方便大家学习测试，特意给大家准备了一份13G的超实用干货学习资源，涉及的内容非常全面。

包括，软件学习路线图，50多天的上课视频、16个突击实战项目，80余个软件测试用软件，37份测试文档，70个软件测试相关问题，40篇测试经验级文章，上千份测试真题分享，还有2021软件测试面试宝典，还有软件测试求职的各类精选简历，希望对大家有所帮助……

关注我公众号：【程序员小濠】即可获取这份资料了！

如果你不想再体验一次自学时找不到资料，没人解答问题，坚持几天便放弃的感受的话，可以加入我们的群：175317069 大家一起讨论交流，里面也有各种软件测试资料和技术交流。
 

好文推荐

5年经验之谈：月薪3000到30000，测试工程师的变“行”记！

测试工程师，自动化测试工程师，测试开发工程师，这三个岗位分别需要掌握哪些能力和技术栈？

不要让毒鸡汤毁了你，35岁的测试员没有那么可怕，保持专注更重要

如果对你有帮助的话，点个赞收个藏，给作者一个鼓励。也方便你下次能够快速查找。