测试用例编写的流程和方法大全!

本文主要对测试用例的流程和方法做一个相对全面的总结。

一.测试用例的编写流程

需求分析->提取测试点->测试用例编写->测试用例评审

二.测试用例设计方法

大多数设计时有限等价类，边界值补充，错误猜测及场景优化，非大型复杂项目不考虑因果图判定表。核心是根据需求和产品的需要，确认需要测试的重点，然后对重点测试项进行针对的分析，进而给出合适的方法。

1.等价类
因材施教的例子:

原则上讲, 老师应该依据每个学生自身的情况, 指定符合的学习方案. 但是实际上学生太多老湿管不过来, 只能分成几类: 优等生强调知识面的扩展和综合能力的提升; 中等生强调夯实基础, 查缺补漏; 差等生强调优先掌握重点, 暂时跳过难点，思路：输入的集合是无穷的, 不能全都覆盖到依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能

无效等价类：根据需求说明书，不满足需求的集合。

超市买水果

有效等价类：苹果、桃子、梨

无效等价类：青菜、米、饮料，…

等价类只考虑输入域的分类，没有考虑输入域的组合。

2.边界值
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

3.因果图
因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。

（1）恒等：如果原因为真，那么结果必定为真。 例如：动物园运来大熊猫，动物园一定有大熊猫

（2）与：只有2个原因都为真，那么结果为真

（3）或：2个原因中有一个为真时，结果就为真

（4）非：只有原因为假，结果才为真

4.正交排列
因果法设计用例太多怎么办？

正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。

正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的试验。

因素（Factor）：在一项试验中，凡欲考察的变量称为因素（变量）

水平（位级）（Level）：在试验范围内，因素被考察的值称为水平（变量的取值）

正交表的构成：

行数(Runs)：正交表中的行的个数，即试验的次数,用N代表。

因素数(Factors)：正交表中列的个数，用C代表。

水平数(Levels)：任何单个因素能够取得的值的最大个数。正交表中的包含的值为从0到数“水平数-1”或从1到“水平数”，用T代表。

正交表的表示形式： L=行数(水平数*因素数) L=N(TC)

正交表的两条性质：

每一列中各数字出现的次数都一样多。

任何两列所构成的各有序数对出现的次数都一样多，

正交法设计测试用例的步骤：

1、有哪些因素（变量）

2、每个因素有哪几个水平（变量的取值）

3、选择一个合适的正交表

4、把变量的值映射到表中

5、把每一行的各因素水平的组合作为一个测试用例

6、加上你认为可疑且没有在表中出现的用例组合

正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。

5.场景设计法
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。

典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。

想象注册的场景来设计用例，这与根据需求的业务流来设计差不多。主要是想象各种业务流来设计用例。例如我们可以再想象以下场景：

1、用户激活后再次点击邮件激活链接？

2、已注册用户再次注册？

6.错误猜测法
错误猜测法是经验丰富的测试人员喜欢使用的一种测试方法。

基于经验和直觉，找出程序中你认为可能出现的错误，有针对性地设计测试用例。经验可能来自于在对某项业务的

测试较多，也可以来自于售后用户的反馈意见，或者从故障管理库中整理bug。梳理出产品以往哪些地方容易出现问题，问题越多的地方，潜在的bug也就越多。

1.测试人员对项目测试时间久，对功能，模块的复杂度了解，对研发人员的代码能力了解

2.用户反馈（线上，线下）

3.缺陷库故障库

缺陷：上线前 故障：上线后，生产环境
————————————————
版权声明：本文为CSDN博主「啊Sei」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_46658581/article/details/123582893