软件测试（用例Ⅰ）· 测试用例的基本概念 · 万能公式 · 设计测试用例的方法(等价类、边界值、判定表法、正交法、场景设计法、错误猜测法)

一、测试用例

基本要素

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试。

评价好的测试用例的标准：

• 用例表达清楚，无二义性。
• 用例可操作性强。
• 用例的输入与输出明确。一个用例只有一个预期结果。
• 用例的可维护性好。
• 用例对需求的覆盖率高。

好处

• 测试执行者的依据；

• 使得工作可重复，自动化测试的基础；

• 评估需求覆盖率；

• 用例复用，提高效率；

• 积累测试的方法思路以供后续借鉴。

解决了不知道是否较全面的测试了所有功能，测试的覆盖率无法衡量，对新版本的重复测试很难实施，存在大量冗余测试影响测试效率。

设计方法 - 万能公式

设计测试用例的万能公式：
功能测试 + 界面测试 + 性能测试 + 兼容性测试 + 易用性测试 + 安全测试

举个常见的例子，下面我们将对水杯进行设计测试用例，套上我们的公式~

水杯的测试用例

从万能公式中列出六项，然后从这六项分别去想我们需要对水杯进行的测试。

功能测试：
	水杯装满水；
	水杯装一半的水；
	水杯不装水；
	水杯能否折叠；
	水杯盖子是否盖的稳；
	水杯装水超过刻度线是否会溢出。
	水杯能否装开水、冰水；
	水杯是否漏水；

界面测试：
	水杯的形状；
	水杯的大小；
	水杯的颜色；
	水杯的图案花纹；
	水杯的美观度，完整度。
	水杯的材质；

性能测试：
	水杯的耐热性；
	水杯的抗冻性；
	水杯的抗压性；
	水杯的抗腐蚀性；
	水杯的抗辐射性；
	水杯的抗摔性；
	水杯的密闭性；
	水杯的保温性；
	水杯的使用寿命。
	水杯材质的稳定性；

易用性测试
	水杯是否防滑；
	水杯是否符合人体工学；
	水杯是否易清洗；
	水杯是否重手；
	水杯盖子能否轻易拧开。
	倒水是否方便；
	喝水是否方便；

兼容性测试
	水杯能否装水、碳酸饮料、茶、咖啡、汤药、特殊液体（酒精、汽油）。
	
安全测试
	水杯材质高温环境下是否有毒；
	水杯是否易变形，变形后是否存在危险；
	水杯材质是否容易爆炸。
	低温环境下是否有毒；
	遇到特殊液体是否产生化学反应，产生毒性；

一下子就设计出四五十个测试用例，为什么要套用公式呢？
虽然我们一个一个想，确实可以想出一些，但是这样脑海中的思路是没有条理的，想到什么说什么。
套用公式就可以有思路，条理清晰的把测试用例设计出来，覆盖率也比较大。

我们通常是使用脑图来进行设计测试用例的。

小结

我们从 具体的事物 和 软件功能 两个方面来看。

• 功能测试
  水杯：水杯的功能无非就装水、喝水。
  软件注册登录功能：注册 + 登录。想象日常使用中的注册场景有哪些功能，来针对这些功能发散性的设计测试用例。

• 界面测试
  水杯：外形能看到的东西，颜色 + 材质 + 大小 + 形状 + 整体美观程度。
  软件：能看到的东西都需要进行测试，文字 / 输入框 / 图片 / 下拉框等控件；对于这些控件的颜色、大小、形状、布局也能够进行测试；再细化对于文字是否存在错别字、病句、缩放页面折行折叠重叠等等问题进行测试。

• 性能测试
  水杯：常用的耐热性、抗冻性、抗压性、耐摔性。
  软件：页面访问的响应时间；千万人同时访问页面的性能测试；页面跳转的速度等。

• 兼容性测试
  水杯：水杯可以装液体，针对液体来设计兼容性。
  软件：系统（Linux、Windows、Mac）；终端（PC、移动端）；浏览器（chrome、Firefox…）。

• 易用性测试
  具体的事物：是否具备便捷、简单易上手的属性。
  软件：界面是否有用户引导、新手引导、符合用户使用的习惯。

• 安全测试
  水杯：水杯的材质是否安全；特殊情况下（高温、低温）材质是否会释放毒性。
  软件：SQL 注入、XSS 漏洞、越权（垂直越权，下级能看到上级的隐私数据；水平越权（平级之间不允许访问的数据））。

二、设计测试用例的方法

问题引入

我们在基于需求进行测试用例的设计的时候，会遇到一个问题~

例如：
软件需求是提示输入的个人ID是 6~15 位

我们针对有需求的案例来设计测试用例是这样的：需求分析 → 需求有哪些功能 → 设计测试点 → 设计测试用例

这时候我们可以使用穷举法来设计测试用例，
用户输入 6 位长度测试，
用户输入 7 位长度测试，
用户输入 8 位长度测试，
…，
用户输入 15 位长度测试。
若测试用例通过，则认为功能符合需求要求。

但是，如果需求是个人 ID 是 6~200 位呢？还能用穷举法设计测试用例吗？6 至 500 位呢？
所以通过穷举法来设计测试用例不太合理！我们需要学习更加系统科学的设计测试用例的方法，来应对复杂的详细的需求。

等价类

概念
针对需求，把输入范围划分成若干个等价类，从其中一个等价类里取出一个用例，若该测试用例通过，则认为该测试用例所在的等价类是通过的。

• 生活中的等价类
  我们经常去饭堂吃饭，饭堂有粤式小炒、松湖美食、第九菜系、西式扒饭四个档口，各色菜系都是划分开的。
  我去吃粤菜，若要证明这个档口都是粤菜，我需要把档口的菜都各来一份吗？不需要！我只需要去划分好的粤式小炒档口就好了。

有效等价类和无效等价类
等价类又划分为有效等价类和无效等价类。

• 有效等价类：针对需求所构成的有效有意义的数据集合。
• 无效等价类：针对需求所构成的无效无意义的数据集合。

根据等价类划分测试用例的步骤

1. 确定有效等价类和无效等价类。
2. 编写测试用例。

需求案例
用户 ID 长度是 6~200 位，应该如何来设计测试用例？

1、确定有效等价类和无效等价类
有效等价类：6~200
无效等价类：小于 6，大于 200

2、编写测试用例

边界值

边界值法通常是对等价类的补充。

生活情景

需求：年中 618 活动截止至 6 月 18 日。

关于截止日期的边界值，有：
if(acEndtime < 6.19 00:00:00)
if(acEndtime <= 6.18 23:59:59)

这时候就体现了边界值的重要性，
边界值：23:59:59
在其两侧的数据，称为次边界值：23:59:58 | 00:00:00

设计边界值的测试用例时需要加上：边界值 + 次边界值

判定表法

这是一种表达逻辑判断的工具。

判定表设计测试用例的步骤

1. 确认输入条件和输出条件。
2. 找出输入条件和输出条件之间的关系。
3. 画判定表。
4. 根据判定表填写测试用例。

案例

我们还是根据需求来用判定表设计测试用例~

需求：订单已提交，订单合计金额大于 300 元或者订单有红包，则认为该订单属于有优惠的订单，否则属于没有优惠的订单。

1. 确认输入条件和输出条件。
   输入条件：订单已提交（A）；金额大于 300 元（B）；有红包（C）。
   输出条件：有优惠（1）；没有优惠（2）。

2. 找出输入条件和输出条件之间的关系。
   AB → 1
   AC → 1
   ABC → 1
   BC → 2
   A → 2
   B → 2
   C → 2
   非ABC → 2

3. 画判定表。
   

4. 根据判定表填写测试用例。
   1）订单已提交，金额大于 300，没有红包，结果为有优惠。
   2）订单已提交，金额不大于 300，有红包，结果为有优惠。
   3）订单已提交，金额大于 300，有红包，结果为有优惠。
   4）订单未提交，金额大于 300，有红包，结果为没有优惠。
   5）订单已提交，金额不大于 300，没有红包，结果为没有优惠。
   6）订单未提交，金额大于 300，没有红包，结果为没有优惠。
   7）订单未提交，金额不大于 300，有红包，结果为没有优惠。
   8）订单未提交，金额不大于 300，没有红包，结果为没有优惠。

over. 可以看出还是比较系统的设计出了测试用例。

判定表法的适用场景：需要考虑输入之间的组合关系，不同的组合关系对应的输出结果不同。

与之前的等价类、边界值还是有区别的。
判定表是需要考虑到输入数据之间的组合关系；等价类、边界值则是一组同类型的数据。

ps. 因果图
应该有不少读者知道因果图，我在文中省略了因果图。因为因果图设计测试用例中，有一步骤是 根据因果图来画判定表 ，因果图不能直出测试用例，还需要依赖判定表，所以我认为因果图有点多余，而且因果图实际在设计成测试用例的时候并没有多大意义。。。

正交法

这个正交法需要用到正交表。相较于前面的方法难一些。

涉及到的概念：
因素数：表示输入的条件。
水平数：表示输入条件对应的结果（不是输出条件）或选项。

正交表：数学公式.

正交表的特性：
（1）每一列中，不同的数字出现的次数相同。（表 1-1 中的每一列的不同数字都是出现三次）

（2）任意两列中的数字的排列方式齐全而且均衡。（任意两列中的数字组合，都是唯一的，不会重复也不会遗漏。这就是齐全而且均衡）

要使用正交法来设计测试用例，需要有正交表。
正交表因为两大特性，非数学专业很难手写出一个正交表…

这时候我们就需要一个工具了—— allparis（专门生成正交表的工具）.

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

1. 找到因素数和水平数。
2. 用 allparis 工具来生成正交表。
3. 根据正交表来编写测试用例。
4. 补充测试用例。

接下来我们实操演练一下~

案例

需求：用户注册信息填写，姓名、电子邮箱、密码、确认密码、验证码。

① 找到因素数和水平数.
因素数：5（有五个信息需要填写）
水平数：2（用户可以填写也可以空着）

② 使用 allparis 工具生成正交表.
先在 excel 表格中，把因素数和水平数写好.

直接复制到 allparis 工具的目录下自行创建的 txt 文件中，然后保存（因为 allparis 有着非常严格的路径检测）.

打开 cmd 窗口，进入到该目录下，输入命令 allpairs.exe 0204.txt>0204_result.txt

不出意外的话，就…报错了…

错误码：Can't open 0204.txt; at release\allpairs.pl line 368.

百度了发现有几种原因导致的，因为 allparis 工具的路径审查太严格。
（1）复制过去的因素数和水平数不要动它，直接保存到记事本里即可；
（2）保存数据的记事本需要和 allparis 工具在同目录下；
（3）allparis 直接解压就能用，但是避免放在过深的目录里（是我了…）和带有中文的目录里。

2023-02-07.ps.（4）太捞了这个工具，又不行了，这次建议把保存数据的记事本命名改复杂一些，简单的111，222找不到…

~再试一遍.
打开 cmd 窗口，进入到该目录下，输入命令 allpairs.exe 0204.txt>0204_result.txt

成了，文件生成，打开有数据。

③ 根据正交表来编写测试用例
从生成的文件中，根据 TEST CASES 数据，我们来编写测试用例。
（1）全部填写姓名，电子邮箱，密码，确认密码，验证码。
（2）填写姓名；不填写电子邮箱，密码，确认密码，验证码。
（3）不填写姓名，密码，验证码；填写电子邮箱，确认密码。
（4）不填写姓名，电子邮箱，确认密码；填写密码，验证码。
（5）填写姓名，电子邮箱，密码；不填写确认密码，验证码。
（6）填写姓名，密码，验证码；不填写电子邮箱，确认密码。

④ 补充其它测试用例
使用 allparis 生成的正交表和实际的正交表有出入，不影响我们使用 allparis 来设计测试用例。
需要最后补充上 allparis 遗漏的测试用例。
（7）不填写姓名，电子邮箱，密码，确认密码，验证码。

场景设计法

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

该设计法主要分为基本事件流和多个备用事件流。

案例
区分基本事件流、备用事件流。

编写测试用例：

1. 基本事件流
   插入银行卡，输入正确密码，选择小于 5 万 且金额是 50 倍数的钞票，等待出钞，最终退卡成功。
2. 备用事件流
   1）插入银行卡，第一次输入密码错误，第二次输入密码成功。选择小于 5 万 且金额是 50 倍数的钞票，等待出钞，最终退卡成功。
   2）插入银行卡，第一次输入密码错误，第二次输入密码错误，第三次输入密码成功。选择小于 5 万 且金额是 50 倍数的钞票，等待出钞，最终退卡成功。
   …

错误猜测法

错误猜测法是对软件测试设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。

这个方法强调是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验直觉。

所以该方法的缺点是难以被系统化，过度依赖个人能力…