如何设计一个测试用例

  前言👀~

上一章我们介绍了什么是软件测试以及软件测试的一些基础概念，今天来聊聊如何设计一个测试用例，涉及到黑盒测试的测试方法

基于需求进行测试用例的设计

基于需求的具体设计方法

等价类

边界值

判定表法

正交表法

场景设计法

错误猜测法

如何模拟弱网？

测试用例设计万能公式

---

如果各位对文章的内容感兴趣的话，请点点小赞，关注一手不迷路，讲解的内容我会搭配我的理解用我自己的话去解释如果有什么问题的话，欢迎各位评论纠正 🤞🤞🤞

个人主页：N_0050-CSDN博客

相关专栏：java SE_N_0050的博客-CSDN博客  java数据结构_N_0050的博客-CSDN博客  java EE_N_0050的博客-CSDN博客

---

基于需求进行测试用例的设计

首先回顾一下之前说的，需求是测试人员进行测试的依据，首先对需求进行分析是否合理是否完整，然后细化需求，从需求中提取出测试项，然后从每一个测试项从提取出测试点，然后根据测试点设计测试用例。基于需求设计测试用例属于大概的设计，而且是针对有需求文档的时候来设计测试用例，所以是针对需求进行了大概的测试，可能会出现大量的问题

功能需求测试分析：

从界面考虑：列出测试点，例如页面是否美观、页面布局是否合理、文字大小、文字格式必须正确、界面中各组件是否都正常等

从业务流程相关（需求规格说明书）考虑：列出对应的测试点，例如一个登录模块，首先手机号是否正确长度和格式是否符合要求，密码的格式等，如果没有需求规格说明书就对功能进行分析

非功能需求测试分析：

兼容性（操作系统）、性能（接口相关）、安全性（SQL注入等）、可移植性、易用性等

注意不同的项目类型对各个非功能需求是不一样的！

客户端软件：对功能要求简单，对兼容性和稳定性较低，可移植性有一定的要求

企业软件：对功能要求有一定的要求，但是整体上看，对性能，安全性，兼容性要求不高

商业软件：对功能，安全性，兼容性，可靠性等都有很高的要求

---

基于需求的具体设计方法

以下的内容涉及的是黑盒测试用例的设计方法！

等价类

根据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例/从每个类中抽取一个测试点，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题

例子：例如图书馆中的书籍分为几个大类，历史、人文、政治、经济、计算机等，我们去到历史这个区域挑选书的时候，随便挑一本书然后看看这本书属于什么类型的，如果是属于历史我们则可以等价认为这里的书都是属于历史类型的

等价类分为有效等价类和无效等价类：

有效等价类：根据需求说明书，满足需求的集合，例如账号的输入要求6-18位的数字，输入8位输入10位满足用户需求

无效等价类：根据需求说明书，不满足需求的集合，例如账号的输入要求6-18位的数字，输入20位不满足用户需求

总结：等价类就是根据需求将输入区域分为若干个等价类，然后从等价类中选出一个测试用例进行测试，测试通过则可认为是有效等价类反之无效，这也解决了不能穷举测试的问题。但是等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充

等价类思想设计测试用例步骤：大前提一定是充分理解需求，然后划分有效等价类和无效等价类，然后各从中抽取一个数据设计测试用例

---

边界值

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

例子：还是账号的输入要求大于6-小于等于18位的数字，输入7位-18位满足用户需求，但是输入6位呢18位呢（上点），输入7位呢输入19位呢（离点），所以引入边界值来补充等价类测试的健全

边界值设计测试用例步骤：大前提一定是充分理解需求，然后找边界点分为上点（上面的6和18）和离点（上面的7和19），然后针对上、离、内点三者各设计一个测试用例。可以看出会将等价类和边界值结合起来使用，在实际的测试设计中就是这样

---

判定表法

其实判定表是来源于因果图法，首先画出因果图将其转换为判定表，我觉得画因果图没什么必要所以直接叫判定表法，因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关 系。因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、 程序的输出又依赖于输入条件的各种情况

逻辑关系：其实就是&、|、==、!

与：所有条件必须满足，一个条件为假，结果就为假

或：一个条件为真结果就为真，条件都假则全假

恒等：条件为真，结果一定真

非：条件为假，结果为真

判定表法设计测试用例步骤：大前提一定是充分理解需求，确定输入条件和输出条件，找出输入条件和输出条件之间的关系，然后画判定表，根据判断表设计测试用例

使用判定表法设计测试用例可以帮助测试人员理清输入和输出的关系，但是对于比较复杂的输入和输出，会耗费大量时间

---

正交表法

由于判定表法设计出来的用例太多了，引出正交表法，目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合

正交表的构成：

正交表的行表示要做试验的次数，可以理解为测试用例的个数

正交表的列表示最多允许安排的因素的个数

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

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

因素：在一项试验中，凡欲考察的变量称为因素（变量），也就是需求中的变量，也可以看作是输入条件

水平：在试验范围内，因素被考察的值称为水平（变量的取值），也就是变量的取值，也可以看作是输入条件的可选项

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

正交表的性质：

每一列中，不同数字出现的次数相等，下图中的111，222，333

任意两列中数字的排列方式齐全且出现的次数相等，下图中的11，12，13、21，22，23等

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

充分理解需求->确定因素水平->画正交表->补充正交表->将正交表转为测试用例

如何设计正交表以及如何生成正交表？

使用allpairs工具生成正交表，类似工具也可以使用微软的PICT

详细步骤：首先先在excel中把因素和水平都写出来（也可以选择直接在记事本中写），然后把这些内容拷贝到记事本中，然后把这个记事本放到你安装allpairs的路径下。接着使用cmd定位到allpairs的路径下，然后输入allpairs.exe 输入文件名 > 新的文件名（不会覆盖掉之前的）

其中~表示此时这个取值可填写也可以是不填写，并且你会发现没有生成都不填写的情况，这种情况一般不常见也没意义
 

使用allpairs工具生成正交表流程：

1.找出因素和水平

2.设计正交表和生成正交表

3.根据正交表设计测试用例

4.补充其他测试用例

---

场景设计法

同一事件不同的触 发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者 设计测试用例，使测试用例更容易理解和执行。通常情况需要 把用户常用的功能模块串起来进行测试的时候使用场景设计法

针对一个完整的操作流程我们可以分为主事件流和次事件流去设计测试用例

主事件流：简单理解为按主事件去执行的所有步骤

次事件流：简单理解为从主事件中任意一个步骤分支出来的一个新事件流

例子：你去ATM机取款，完整流程应该是插卡、输入密码、选择业务、输入取款金额、等待返回、取卡，然后在插卡的时候可能用户插入的卡是老人卡或者饭卡以及非本行卡等，接下来输入密码又可能输入密码错误、输入次数上限等，选择业务选择存款、查询、流水等，输入取款金额的时候非整数或ATM没这么多等，等待返回的时候出现故障，取卡出现故障，对于这些从主事件中分支出来的情况我们可以看作次事件流，我们要针对这些情况设计测试用例，保证覆盖到这些情况

---

错误猜测法

错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉

---

如何模拟弱网？

这里我使用fidder工具演示

接着下一步

进入后往下找，一个表示上传的速度和下载的速度

测试用例设计万能公式

针对没有需求的案例设计测试用例：功能测试+界面测试+兼容性测试+性能测试+易用性测试+安全测试

以上便是本章内容关于如何设计一个测试用例，在有需求或没有需求的情况下我们该如何进行设计，下一章我们对测试进行分类讨论💕