测试设计

2020年测试部新人入职培训---测试基础

参考资料

《http://172.16.111.6:8081/pages/viewpage.action?pageId=3280267》

《海盗派测试分析MFQ&PPDCS》

# 课前活动

# 回顾答疑

《测试分析》作业完成情况总结分析，进行答疑

# 课程引入

一道开发面试题

需求描述

商店里进行购物结算时会使用收银机系统，这台收银机会在结算时根据客户的购物车中的商品和商店正在进行的优惠活动进行结算和打印购物小小票。

已知商品信息包含：名称、数量单位、单价、类别和条形码(伪)。

已知我们可以对收银机进行设置，使之支持各种优惠。

我们需要实现一个名为打印小票的小模块，收银机会将输入的数据转换成一个JSON数据然后一次性传给我们这个小模块，我们将从控制台中输出结算清单的文本。

输入格式(样例)：

[
    'ITEM000001',
    'ITEM000001',
    'ITEM000001',
    'ITEM000001',
    'ITEM000001',
    'ITEM000003-2',
    'ITEM000005',
    'ITEM000005',
    'ITEM000005'
]

1
2
3
4
5
6
7
8
9
10
11

其中对'ITEM000003-2'来说，“-”之前的是标准的条形码，“_”之后的是数量。当我们购买需要称量的物品的时候，由称量的机器生成此类条形码，收银机负责识别生成小票。该商店正在对部分商品进行“买二赠一”的优惠活动和对部分商品进行95折的优惠活动。其中：

“买二赠一”是指，每当买进两个商品，就可以免费再买一个相同商品;
“95折”是指，在计算小计的时候按单价的95%计算每个商品;
每一种优惠都详细标记了哪些条形码对应的商品可以享受此优惠;
店员设置，当 “95折”和“买二赠一”发生冲突的时候，也就是一种商品既符合享受“买二赠一”优惠的条件，又符合享受“95折”优息的条件时，只享受“买二赠一”优惠。

要求写代码支持上述的功能，并根据输入和设置的不同，输出下列小票。小票内容及格式(样例)：

当购买的商品中，有符合“买二赠一”优惠条件的商品时：

***<没钱赚商店>购物清单***
名称：可口可乐，数量：3瓶，单价：3.00(元)，小计： 6.00(元)
名称：羽毛球，数量：5个，单价： 1.00(元)，小计： 4.00(元)
名称：苹果，数量：2斤，单价：5.50(元)，小计： 11.00(元)
买二赠一商品：
名称：可口可乐，数量：1瓶
名称：羽毛球，数量：1个
总计： 21.00(元)
节省：4.00(元)
**********************

1
2
3
4
5
6
7
8
9
10

当购买的商品中，没有符合“买二赠一”优惠条件的商品时：

***<没钱赚商店>购物清单***
名称：可口可乐，数量：3瓶，单价：3.00(元)， 小计：9.00(元)
名称：羽毛球，数量：5个，单价：1.00(元)， 小计：5.00(元)
名称：苹果，数量：2斤，单价：5.50(元)， 小计：11.00(元)
总计： 25.00(元)
**********************

1
2
3
4
5
6

当购买的商品中，有符合“95折"优惠条件的商品时：

***<没钱赚商店>购物清单***
名称：可口可乐，数量：3瓶，单价：3.00(元)， 小计：9.00(元)
名称：羽毛球，数量：5个，单价：1.00(元)， 小计：5.00(元)
名称：苹果，数量：2斤，单价：5.50(元)，小计：10.45(元)，节省0.55(元)
总计： 24.45 (元)
节省：0.55(元)
**********************

1
2
3
4
5
6
7

当购买的商品中，有符合“95折”优惠条件的商品，又有符合“买二赠一”优惠条件的商品时：

***<没钱赚商店>购物清单**** 
名称：可口可乐，数量：3瓶，单价：3.00(元)， 小计：6.00(元)
名称：羽毛球，数量：6个，单价：1.00(元)， 小计：4.00(元)
名称：苹果，数量：2斤， 单价5.50(元)，小计：10.45(元). 节省0.55(元)
买二赠一商品：
名称：可口可乐，数量：1瓶
名称：羽毛球，数量：2个
总计：20.45 (元)
节省：5.55 (元)
**********************

1
2
3
4
5
6
7
8
9
10

# 课程内容

# 一、什么是测试设计

这些目标和标准如何达成

测试分析是确定目标的过程，而测试设计是得出具体的测试实例以达到完成这个测试目标的过程。

具体来说，测试设计首先识别测试条件中可变化的部分，即变量；然后为每个变量确定具体的取值，最后得出可以直接拿来执行的测试实例。因为真正要做测试执行的时候，无论是手工测试还是自动化测试，每个系统的输入数据都得是确定的。

根据产品测试类型的不同，测试设计方法分为以下几类：

功能测试测试设计方法（又分为单功能/单运行和多功能交互/多运行）
质量属性测试设计方法（性能测试方法、可靠性测试方法、易用性测试方法等）

我们接下来着重讲解功能测试设计方法

# 二、功能测试设计方法

功能测试也称黑盒测试。在测试过程中，测试人员不需考虑程序内部结构和内部特性，只需检查程序功能是否按照需求文档的规定实现。从理论上来讲，黑盒测试只有采用穷举法，把所有可能的输入都作为情况考虑，才能查出程序中的所有缺陷。实际上情况有无穷多个，测试无法做到穷尽，所以我们要进行有针对性的测试，通过合理的设计的测试来开展工作。通常运用一种测试用例设计方法并不能获得理想的测试用例集，在设计测试用例时，综合运用几种设计技术，取长补短。黑盒测试设计方法的主要依据是软件系统需求规格说明书、详细设计文档等，因此，在进行黑盒测试设计之前需要确保这些文档是经过评审的，其质量达到了既定的要求。

等价类划分
边界值分析
场景法
错误推测法
决策表驱动
正交实验设计

# 1 等价类划分法

干垃圾、湿垃圾、可回收垃圾、有害垃圾对于一般人来说是不容易理解的，为了更形象的区分，我们以小猪佩奇的饮食做区分：猪可以吃的、猪都不吃的、猪吃了会死的、卖了可以买猪的四类。

等价类划分法是一种典型的、重要的黑盒测试方法，它将程序所有可能的输入数据包括有效的和无效的划分成若干个等价类子集，然后从每个子集中选取具有代表性的数据当做测试用例进行合理的分类，测试用例由有效等价类和无效等价类的代表组成，通过降低测试数据的数目去实现合理的覆盖，以发现更多的软件缺陷，从而保证测试用例具有完整性和代表性。

这种方法可以减少设计一些不必要的测试用例，因为这种测试用例一般使用相同的等价类数据，从而使测试对象得到同样的反映行为，如果其中一个不会导致问题发生，那么集合中其它输入条件进行测试也不可能发现错误。

# 1.1 等价类划分准则

# 1.1.1 各子集相互独立

各个子集就像磁铁的两个S极一样，始终互斥。

如果出现某一个元素同时出现在两个不同的子集A和B中，那么是否说明A里的所有元素和B里的所有元素具有相同的特征，那A集合和B集合是否可以合并？

如果集合A和B合并之后，是否又与其他子集互斥？

所以我们进行等价类划分时，务必保证各个子集间的互斥。

# 1.1.2 各个子集的并集是全集

当我们对某一类事物按照某一规则进行划分后，就会像七巧板一样，有多个集合出来，把各个集合重新组装起来，仍然能够恢复七巧板原来的模板，否则就是对某一个集合的遗漏分析。

# 1.1.3 同一子集内所有元素具备相同的处理逻辑

物以类聚人以群分，在一个集合里的元素，都应该具备一样的特征。在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。

# 1.2 等价类分类

经过分析，我们对测试对象输入数据进行了划分，所得到的若干个子集合可以归纳为有意义的输入和无意义的输入两部分，我们分别称之为有效等价类和无效等价类。在设计测试用例时，需要同时考虑这两种等价类，因为软件不仅要能接收合理的数据，也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。

# 1.2.1 有效等价类

有效等价类指对于程序规格说明来说，是合理的、有意义的输入数据构成的集合。利用有效等价类可以检验程序是否实现了规格说明预先规定的功能和性能。有效等价类可以是一个，也可以是多个，根据系统的输入域划分若干部分，然后从每个部分中选取少数有代表性数据当做测试用例，等价类是输入域的集合。

# 1.2.2 无效等价类

无效等价类和有效等价类相反，无效等价类是指对于软件规格说明而言，没有意义的、不合理的输入数据集合。利用无效等价类，可以找出程序异常说明情况，检查程序的功能和性能的实现是否有不符合规格说明要求的地方。

# 1.3 等价类划分的技巧和方法

在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类
在输入条件规定了输入值的集合或者规定了必须如何的条件的情况下，可确立一个有效等价类和一个无效等价类
在输入条件是一个布尔变量的情况下，可确定一个有效等价类和一个无效等价类
在规定了输入数据的一组值假定n个，且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类
在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类符合规则和若干个无效等价类从不同角度违反规则

# 1.3.1 按区间划分

当输入数据是一段连续的取值时，我们可以通过区间的方式来对输入数据进行划分。比如，当我们对学生的成绩进行划分，可以得出其有效值为[0, 100]。

# 1.3.2 按数值（集）划分

当输入数据是离散的数据集时，我们可以通过指定的数据或集合来进行划分。比如，在使用现金购买地铁票时，我们能输入的数值有：5元、10元、20元，这是我们的有效等价类。

# 1.3.3 按限制条件或规则划分

我们输入数据依赖于产品规格要求或限制，使得我们只能再特定范围内进行输入。比如，当我们注册微信的时候，需要输入手机号码。手机号码有相应的规则约束。规则内的手机号码就是合法的，否则都是非法输入。

# 1.4 等价类划分实例

# 1.4.1 微信发送红包的金额

a. 有效等价类：

0<x<=200（发送金额为100元的微信红包成功）

b. 无效等价类：

x<0或者x>200（输入金额为0元的微信红包，发送按钮不可用，输入金额为201元的微信红包，发送按钮不用）

在对区间相关的等价类分析时，要结合边界值考虑，我们会在下节展开讲解。

# 1.4.2 输入一个城市，且该城市属于一线城市

a. 有效等价类：

北京、上海、广州、深圳（输入深圳后提示输入正确）

b. 无效等价类：

北上广深以外的城市（输入南京后提示错误）

# 1.4.3 注册邮箱，对用户名进行校验

在对电子邮箱地址进行校验时，对用户名有以下约束：

字母a~zA~Z、数字0~9、英文点、减号、下划线组成
必须由数字或字母开头或结尾
长度4~18个字符

分别对上述3个约束条件划分有效等价类和无效等价类：

字符组合约束：

a. 有效等价类：用户名仅包含字母a~zA~Z、数字0~9、英文点、减号、下划线这些元素（new_tester-1.0）

b. 无效等价类：用户名包含字母a~zA~Z、数字0~9、英文点、减号、下划线以外的元素（new+test）
开头结尾约束必须是数字或字母：

a. 有效等价类：以数字或者字母开头或结尾的字符串（1tester，tester1）

b. 无效等价类：不以数字或者字母开头或结尾的字符串（@tester，tester_）
长度约束（4~18）：

a. 有效等价类：字符串长度为[4, 18]（newtester）

b. 无效等价类：字符串长度为[0, 3]，[19, +∞]（new、newnewnewnewnewnewnewnewtester）

# 2 边界值分析

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。区别：边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。为检验边界附近的处理专门设计测试用例，常常可以取得良好的测试效果。

# 2.1 边界值分析原则

如果输入条件规定了值的范围，则应该取刚达到这个范围的边界值，以及刚刚超过这个范围边界的值作为测试输入数据
如果输入条件规定了值的个数，则用最大个数、最小个数、比最大个数多1个、比最小个数少1 个的数作为测试数据
根据规格说明的每一个输出条件，使用规则1
根据规格说明的每一个输出条件，使用规则2
如果程序的规格说明给出的输入域或输出域是有序集合（如有序表、顺序文件等），则应选取集合的第一个和最后一个元素作为测试用例
如果程序用了一个内部结构，应该选取这个内部数据结构的边界值作为测试用例
分析规格说明，找出其他可能的边界条件

# 2.3 边界值分析实例

有效等价类边界值：0, 1, 99, 100

无效等价类边界值：-1，101

# 3 错误推测法

错误推测法是指在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。

# 3.1 前提

深度熟悉被测系统的业务、需求，对被测系统或类似系统之前的缺陷分布情况进行过系统的分析，包括功能缺陷、数据缺陷、接口缺陷和界面缺陷等等。

# 3.2 思想

列举出程序中所有可能有的错误和容易发生错误的特殊情况，例如在单元测试时曾列出的许多在模块中常见的错误，以前产品测试中曾经发现的错误等，这些就是经验的总结。还有输入数据和输出数据为0的情况，输入表格为空格或输出表格为空，这些都是容易发生错误的情况，可选择这些情况下的例子作为测试用例。总之，就是进行错误的操作。

# 3.3 优缺点

优点：充分发挥个人的经验和潜能，命中率高

缺点：覆盖率难以保证，过多的依赖于个人的经验

# 3.4 错误推测法实例

测试手机终端的通话功能，可以设计各种通话失败的情况来补充测试用例

无SIM 卡插入时进行呼出（非紧急呼叫）
插入已欠费SIM卡进行呼出
射频器件损坏或无信号区域插入有效SIM卡呼出
网络正常，插入有效SIM卡，呼出无效号码如111111、888888、不输入任何号码等
网络正常，插入有效SIM卡，使用快速拨号功能呼出设置无效号码的数字

# 4 判定表法

判定表也称决策表，在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，针对不同逻辑条件的组合值，分别执行不同的操作，决策表就是分析和表达多逻辑条件下执行不同操作情况的工具，它可以把复杂的逻辑关系和多种条件组合的情况表达的具体明确。

这里需要提一下，还有一种测试设计方法是“因果图法“，通常”因果图法“需要结合”判定表法“使用，我们不再单独讲解了：

因果图得到的“原因”就是判定表的“条件”；
因果图得到的”结果“就是判定表的”动作“；

# 4.1 判定表组成

判定表通常由条件桩、条件项、动作桩、动作项组成。

条件桩：被测对象的所有输入；
条件项：被测对象的输入取值；
动作桩：被测对象可能采取的操作/表现；
动作项：在各个条件项的组合下，被测对象所采取的动作/表现；

# 4.2 优缺点以及适用范围

# 4.2.1 优点

能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏，利用决策表能够设计出较为完整的测试用例集合，适用针对不同逻辑条件的组合值，分别执行不同的操作，便于分析。

# 4.2.2 缺点

无法对循环体结构类型进行分析，随着条件的变多，判定表会变得异常庞大（规则数为条件的可选数量乘积），实战性较弱。

# 4.2.3 适用范围

条件的排列顺序不影响执行操作；
规则的排列顺序不影响执行操作；
当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则；
如果某一规则得到满足需要执行多个操作，这些操作的顺序无关紧要。

# 4.3 步骤

决策表测试用例设计主要由以下步骤组成：

确定规则的个数。在判定表里的规则是指，条件桩进行组合后的集合，对应判定表右侧的所有列。如果有3个条件，每个条件有2个取值，则有2X2X2=8种规则，判定表中有8列。
列出所有的条件桩、动作桩
将条件和动作分别填入条件桩和动作桩中得到初始决策表
简化相似的规则、删除冗余的规则得到优化的决策表
为每列规则设计一个测试用例

# 4.4 判定表实例

例：某程序要求输入的第一个字符必须是“#”或者“*”，输入的第二个字符必须是一个数字，满足这两种情况下才进行文件的修改，如果第一个字符不是“#”或者“*”，给出提示信息N，如果第二个字符不是数字，给出提示信息M。

实际工作中，由于编写判定表编写较为复杂，使用频率并不高，但其中的思想值得我们学习和领悟。

# 5 正交试验设计法

从大量的测试用例中挑选出适量的、有代表性的测试用例，通过建立合适的正交表，合理地安排测试实验的一种科学的设计方法。

# 5.1 优点

能够有效的节省测试工作耗时
能够有效的控制生成的测试用例数量
测试用例具有一定的合理覆盖度

# 6 结对测试

结对测试又称两两组合测试，结对测试设计的测试用例可以覆盖测试对象的每个参数的两两组合。

# 6.1 结对测试实例

某网站系统需要支持在如下不同环境中运行：

不同的浏览器：IE5.0、IE5.5、IE6.0、Netscape6.0、Netscape6.1、Netscape7.0、Mozilla1.1和Opera7
不同的插件：RealPlayer、MediaPlayer、None(无插件)
不同的客户端OS：Windows95、Windows98、Windows ME、Windows NT、Windows2000和WindowsXP
不同的Web服务器软件：IIS、Apache和WebLogic
不同的服务端OS：WindowsNT、Windows2000和Linux

需要针对如下不同组合进行测试，8种浏览器、3种插件、6种客户端OS、3种Web服务器软件和3种服务端OS，如果考虑所有参数不同取值的组合，那么需要设计和执行的测试用例的数目是：8×3×6×3×3=1296种

那么多，怎么办？？？

# 6.2 PICT工具

PICT，全称是Pairwise Independent Combinatorial Testing tool，是一个由微软开发免费小工具。PICT接收一个纯文本的Model文件作为输入，然后输出测试用例集合。

Model文件的格式如下：

<ParamName> : <Value1>, <Value2>, <Value3>, ...

每行输入一个参数以及此参数对应的取值，用英文半角冒号隔开输入参数和取值，参数取值之间用英文半角逗号隔开，那么上述例子中参数与取值的对应关系设计如下：

将设计好的纯文本Model文件放在PICT工具的安装目录下，执行命令：

pict case001.txt > output.txt

生成的测试用例文件如下：

# 7 场景法

分析软件应用的场景，从用户的角度触发，去探索不同场景下用户会如何使用该软件，依此进行测试设计，场景设计是一种面向用户的设计方法。

场景法时一种通过使用”场景“对软件系统的功能或业务流程进行描述，即针对需求模拟出不同的场景进行所有功能和业务流程的覆盖，从而提高测试效率并达到良好效果的方法。简而言之：

场景法是一种尽可能真实模拟用户操作的一种测试设计方法。

场景法主要从两个层面开展：

**业务层面（业务理解更重要）：**测试人员要熟悉所测试软件系统的重要功能、业务逻辑（系统要实现什么、如何实现的？）、行业背景深入理解，成为该行业的”业务专家“

**技术层面：**基于等价类划分中的有效等价类---模拟用户的正确操作，无效等价类---模拟用户的错误操作

核心概念：

基本流：也叫有效流或正确流，模拟用户正确的业务操作流程
备选流：也叫无效流或错误流，模拟用户错误的业务操作流程

为什么要使用场景法？

现在的软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果形成事件流。这种在软件设计方面的思想也可以被引入到软件测试中，生动的描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时测试用例也更容易得到理解和执行。

举个例子：用户在京东购物后申请退货，需要提交退货申请和凭证信息，经过客服审核确认后，预约上门取件时间和地点，快递员取件后确认已取件，触发退款流程，钱款按照支付路径返回，用户确认退款收到后点击此退货单已解决，完成整个退货流程。这中间还有很多其他流程，比如取消退货，修改预约的取货时间和地点，由于包装不完整或商品损坏取件验收不通过等各种情况。

每个事件触发时的情况便形成了场景。而同一事件不同的触发顺序和处理结果形成事件流。终端用户，期望软件能够实现业务需求，而不是简单的功能组合。对单功能点来说，利用等价类划分、边界值分析、判定表等测试设计方法就能够解决大部分问题。而设计业务流程的软件系统，采用场景法比较合适。

# 7.1 场景业务流组成

基本流 + 备选流

途中经过用例的每条路径都用基本流和备选流来表示，绿色主线表示基本流，是经过用例的最简单的路径，即无任何差错，程序从开始直接执行到结束的流程。通常一个业务仅存在一个基本流，且基本流仅有一个起点和一个终点。

备选流表示通过业务流程时输入错误（或者操作错误）导致流程存在反复，但是经过纠正后仍能达到目标的流程。备选流等价于除了基本流之外的各支流，包含多种不同情况，例如：

一个备选流可始于基本流，于某个特定条件下执行，然后重新加入基本流（如备选流1和3）；
也可始于另一备选流（如备选流2）；
也可终止用例而不再加入其他基本流中（如备选流2和4）；

# 7.2 场景组合

按上图组合多个不同的场景：

场景1：基本流；
场景2：基本流备选流1
场景3：基本流备选流1 备选流2
场景4：基本流备选流3
场景5：基本流备选流3 备选流1
场景6：基本流备选流3 备选流1 备选流2
场景7：基本流备选流4
场景8：基本流备选流3 备选流4

# 7.3 备选流覆盖准则

覆盖每个备选流
覆盖一个循环

这两种方法可以看情况选择，到这一步基本的测试条件就出来了，每个场景对应一个测试条件，对每个测试条件进行评审，删掉重复的。

# 7.4 基本流和备选流的识别原则

基本流只有一个起点，一个终点；
基本流是主流，备选流是支流；
备选流可以始于基本流，也可以始于其他备选流；
备选流的终点，可以是一个流程的出口，可以是回到基本流，还可以是汇入其他的备选流；
备选流汇合时，谁汇合到谁，取决于流量大小也即该流程出现的可能性大小，小的汇入大的；
如果在流程图中出现了两个不相上下的基本流，一般需要把它们分别当作一个业务看待。

# 7.5 步骤

分析需求，确定业务流程（基本流、备选流）；
依据基本流、备选流生成不同的场景；
针对生成的各场景，分析设计相应的测试条件。可以采用矩阵或判定表来确定和管理测试条件，通过从确定测试条件场景所需的数据元素入手构建矩阵，矩阵中可以用V表明整个条件必须是Valid（有效的）才可执行基本流，用I表明条件为InValid（无效的）的情况下激活所需备选流，使用”N/A“（不适用）表明这个条件不适用于测试条件。
对生成的所有测试条件进行复审验证确保其准确且适度，去掉多余的或等效的测试条件

注意：

场景法的核心就是”场景“二字，我们所需的就是找出场景，场景找出来了，测试条件也就水到渠成了。当我们找到基本流和备选流之后，需要通过构造场景矩阵将场景表示出来，矩阵一旦生成，测试条件也就一目了然了。

说起来简单，但使用过程中我们还是会遇到部少问题，在很多流程图中，有不少备选流其实是隐藏的，我们要深入理解两个流的概念，为什么会有两个流，两个流的特点是什么，为什么要构造矩阵，矩阵的纵向和横向代表什么，V、I又代表什么。

# 7.6 范围

场景法适合解决业务流程清晰和业务比较复杂的系统或功能，场景法是一种基于软件业务的测试方法；
使用场景法，目的是用业务流程把各个鼓励的功能点串起来，为测试人员建立整体业务感觉，从而避免现如功能细节忽视业务流程要点的错误倾向；
基本每个软件的测试都会用到场景法，因为每个软件背后都有业务的支撑；
场景法主要用来测试软件的业务逻辑和业务流程。当拿到一个测试任务时，我们并不是先关注某个控件的细节测试（等价类+边界值+判定表等），而是要先关注主要业务流程和主要功能是否正确实现，这就需要使用场景法。业务流程和主要功能没有问题我们再从等价类、边界值、判定表等方面对功能细节进行测试（先整体后细节）；

注意：

场景法的重点是测试业务流程是否正确，业务流程测试没有问题不代表系统的功能都正确，还必须对单个功能进行详细的测试，这样才能保证测试的充分性。

# 7.7 优缺点

# 优点：

关心用户做什么，而不是关心产品做什么
实用性强，有效，设计出来的用例有价值
站在用户的角度，以用户的使用逻辑以及操作习惯为出发点，结合功能用例的设计方法，使测试用例更具有可执行性，最大程度上覆盖用户需求

# 缺点：

可能使用的场景不一定能对事件系列进行全面的分析，设计出来的用例不完整。

# 7.8 使用场景法应该注意什么？

注意主题化，要明白这个场景测试条件主要测试什么功能，切忌将测试点自己自己任意组合，想到哪里写到哪里，为了达到测试点的主题化，我们可以在进行场景法设计前，先构想出一个用户使用的场景故事，也就是保证整个场景在用户使用过程中是会出现的；
注意上下文，场景法测试设计本身就是模拟用户使用，测试基本功能连接起来是否存在Bug，一定要具备用户使用时的逻辑性；
只测试简单的基本功能，而诸如密码合法性、内存、带宽不足等这样的问题在场景中不需要出现，也就是场景中只出现主流程；
步骤简洁明了，没有歧义，数字要说明单位

# 7.9 场景法实例

我们使用京东购买书籍，整个购买过程为：用户登录到网站后，浏览检索书籍，选好自己需要的书籍后决定购买，这时把所需图书放进购物车，完成付款并生成订单，购物过程结束。

# Step1 分析基本流和备选流

# Step2 根据基本流和备选流来确定场景

# Step3 测试条件设计如下

对于每一个场景都需要确定测试条件。可以采用矩阵或决策表来确定和管理测试条件。

下面展示了一种通用个数，其中各行代表各个测试条件，而各列代表测试条件的信息。

通过从确定测试场景所需的数据元素（用户的操作或输入）入手构建矩阵，例如，在下面的矩阵中，V（Valid）用于表明这个条件必须是有效的才可执行基本流，而I（Invalid）代表无效，用于表明这种条件下将激活所需备选流，用“N/A”（不适用）表明这个条件不适用于测试条件。

我们看到以上表中，只是把场景的成立条件进行了分析设计，基本已经确定了测试条件的数量，后续只需要把测试数据填充，补充相关信息即可完成测试用例。

# 三、模型(PPDCS)

面对各具特征的被测对象，面对种类繁多的测试设计方法，选取哪种方法来进行测试设计（建模)呢？

为了解决“如何更有效地选取合适的测试设计技术来建模”这个问题，PPDCS的想法应运而生。

PPDCS的思想基于以下认识：

仔细研究那些基本的测试设计技术，发现它们大体上可以归为几大类别，每一类别有其独特的“特征”；

而研究被测对象时（通过阅读需求文档或者通过测试执行来了解被测对象等），发现对于某个可以被单独测试的单功能M来说，其内部逻辑也体现出某种主要的“特征”；那么当这两种特征吻合时，就可以用这种测试设计技术来分析这个单功能了；

PPDCS中每一个字母分别代表着一种“特征”的英文首字母缩写。

# 1 P-Process流程

# 应用条件

当需求中有明显的“业务流程”的含义时，可以考虑采用“P-Process”建模。

“P-Process业务流程”的特点是：

有多个步骤，各步骤间有一定前后约束关系，所有步骤共同完成一件事情；
整个过程可能涉及多于1个的执行者或者触发者。

“P-Process”的需求描述经常包含一系列步骤，比如，OA请假申请：

# 应用步骤

# 2 P-Parameter参数

# 2.1 应用条件

当能够从需求中明显地分出来多个参数或变量来，可以考虑采用“P-Parameter”的方式建模。

“P-Parameter参数”的特点是：

需求中经常是“多个参数”占主导地位，而没有太多“流程”上的处理；
需求规格的描述中含有多条规则，每个规则由多个参数的不同取值组合而成。

# 2.2 应用步骤

# 2.2.1 建模

P-Parameter的特点是可以用决策表测试技术来画模型

# 2.2.2 设计测试条件

# 3 D-Data数据

# 3.1 应用条件

当需求紧紧围绕着一些数据，每个数据有明确的取值范围时，可以考虑采用“D-Data”来建模。

“D-Data数据”的特点是：

不像P-Parameter，数据之间没有明显的“各种组合关系从而构成某个规则”，各数据之间逻辑上的关系是相互比较独立的；
各数据的取值之间有可能存在一些约束关系。

# 3.2 应用步骤

# 3.2.1 建模

针对D-Data为主要特征的需求，可以采用等价类来建模，另外，等价类经常和边界值结合在一起使用。

# 4 C-Combination组合

# 4.1 应用条件

当需求紧紧围绕着一些因子，每个因子有几种不同的取值，即不同状态，但是因子之间的各种组合数目庞大，人工很难穷举，需要借助某种技术选择最有效的一组测试思路的时候，可以考虑“C-Combination”方式建模。

“C-Combination组合”的特点是：

因子个数多
每个因子有多种可能的状态
因子之间有可能存在一些逻辑约束关系

这里说的因子，可以是前文所说的数据（Data），也可以是参数（Parameter）

# 4.2 应用步骤

# 4.2.1 建模

C-Combination的特点是可以用“因子-状态表”表达模型，然后就可以使用组合类的测试设计技术帮助我们得到测试条件。

组合类的测试设计技术包括结对法（Pairwise）、正交试验设计等

组合类测试设计技术的共同特点是用较少的测试场景，包含所有输入的数据，达到较高的测试覆盖率。比较推荐结对法（Pairwise），使用PICT工具。

# 5 S-State状态

# 5.1 应用条件

当需求中涉及多种“状态”时，可以考虑采用“S-State”特征建模。

“S-State状态”的特点是：

涉及多种状态，最好是针对同一个对象的多个状态，否则把多个对象的多种状态都放在一个模型中表达，容易引起混淆；
各个状态之间可以由某种事件的发生相互转换。

“S-State状态”很容易和“P-Process流程"混淆，原因是连接状态图中的多个状态和事件，看起来像流程图中的一个流（Flow）。区分二者简单的办法是：

”P-Process流程“总是有个主的”自上而下“的流程，然后有一些旁路的分支流程，每个流程基本上都不可逆，即流程图中的状态基本上是：”状态A--状态B--状态C“顺序；
而”S-State状态“图中的规则则无此限制，可以是从状态A到状态B，也经常有路径可以从状态B再到状态A。

# 5.2 应用步骤

# 5.2.1 建模

# 四、如何选用PPDCS

我们选用合适的模型来建模，可以把需求变得生动、具体起来，不再是干巴巴的文字了。那我们怎么选取合适的模型，有没有技巧呢？

先讲下四大核心要点：

关注触发词语
抓住核心功能
尝试不同特征
围绕既定目标

# 1 关注触发词语

无论是通过看需求文档、还是通过与人交流的方式了解需求，大多数情况下这些信息是以文字的、语言的形式呈现的，其共同特点是信息以线性的方式顺序呈现出来。我们需要用心去看，用耳朵仔细聆听这些线性信息中的”触发词语“。

由于基于”C-Combination组合“这种特征的建模，更多的目的是为了减少需要测试的组合测试场景的个数，再深入理解需求方面，不如其他4种特征建模方式，因此，在一般情况下，选取PPDCS特征时，我们过滤掉C，而只考虑PPDS。具体来说，就是用”逻辑倾听“的方式寻找需求种与”流程“、”规则“、”数据“、”状态“相对应的触发词语。

当”倾听需求“时：

IF 倾听到名字（Names -- 可能是人、物、时间、地点等），

THEN 有可能是Data（数据）触发词语；

IF 倾听到一串名字和动作（List of Names and Actions），

THEN 有可能是Rule（规则）或States（状态）触发词语；

IF 倾听到一系列事件（Sequence of Events），

THEN 有可能是Sequence（流程）触发词语。

# 2 抓住核心功能

捕捉触发词语时，如果我们事无巨细，什么都不想落下，每个细节都不放过，记录了茫茫多的信息，这就违背了”抓住核心功能“的原则。

抓住核心功能有两层含义：

蒸馏信息
忽略干扰

# 3 尝试不同特征

假设我们在某个需求中，识别到了一些Data（数据）关键点，识别了一些Rules（规则）关键点，到底以哪一种特征建模呢？举棋不定时，我们可以分别以不同的特征为基础建模，然后比较下模型之间的差异。这样做有利于提高我们判断PPDCS的准确性，经过多次练习和学习，就不会那么犹豫不决了。

# 4 围绕既定目标

前面讨论过，为了寻找某个单功能的PPDCS主导特征，往往有一个寻找触发词语的过程，这个过程是高度发散的、探索性的过程，如果缺少一个目标做牵引，很容易从”为一个单功能寻找PPDCS主导特征”变成“为多个单功能寻找PPDCS主导特征”了。

这个目标就是单功能的核心功能，尽量让所有的发散和探索都围绕着被测单功能展开。

# 五、建模

回过头来看开始我们引入的一个案例，来对这个案例尝试下测试设计。

# 1 确定测试对象

粗略看一遍需求，发现这个需求不是很大，锁定测试范围为“打印小票”这个模块，而不是整个”收银机“系统。初步判断不妨把”打印小票“作为一个单功能，详细地分析一下。

# 2 确定单功能的边界

确定了打印小票这个单功能后，我们需要从整体上判断”M打印小票“的边界（既该单功能包含的范围，这里的M代表单功能）。从需求描述不难发现，输入主要有3个：

系统其他模块传给”M打印小票“的商品数据，格式为：

[
    'ITEM000001',
    'ITEM000001',
    'ITEM000001',
    'ITEM000001',
    'ITEM000001',
    'ITEM000003-2',
    'ITEM000005',
    'ITEM000005',
    'ITEM000005'
]

1
2
3
4
5
6
7
8
9
10
11

优惠信息，包含哪些商品有什么样的优惠；
商品价格信息，主要包含商品名称、单价和数量单位，需求中也提到另外的两个信息：类别和条形码（伪），这两个信息目前没有发现与”M打印小票“这个功能在业务规则方面强相关的地方，先搁置。

其中”优惠信息“和”商品价格信息“有可能根据ITEM开头的商品编码到数据库里查询得到，这块取决于具体的实现，在测试”打印小票“时无需关注具体的实现方式。

这3类信息经过”M打印小票“的处理，应该输出购物清单，包含每一种类商品的名称、数量、单价、小计、是否有优惠、买二赠一商品列表、商品总计和节省了多少钱等信息。

其中和数量有关的输出还有“数量单位”，这个并不影响业务逻辑，只要在测试结果观察时关注下就可以了，为了简便，下文就统一用“数量”涵盖了。在“小计”和“商品总计”里还含了一个钱的“计价单位"，也不影响业务逻辑，就不单独罗列这个参数了(引申思考：该系统只支持人民币吗?计价单位除了“元”是否还有其他的可能? )。

# 3 单功能拆分

对”M打印小票”的输人输出进行初步分析后发现：输出信息是比较多且复杂的，比如单品的“小计”就包含了3种可能------产品原价、 95折后的价格、计算买二赠一后的价格，测试的时候势必要单独考量。直觉告诉我，这个单功能有点大了，需要进一步拆分。

“M打印小票”的输出信息之所以复杂，是因为输人数据的复杂，准确地说，是第一类输人数据比较复杂，这个由"ITEM" 开头的-系列数字包含了很多信息在里面，那么各种异常的可能情况就比较多，因此，需要对第一类输人数据进行专门验证，以确保在各种可能的输人数据下，均可以正常处理，智且称其为“MI-输人数据处理” (MI代表拆分后的第一个单功能)吧。

除了输入数据的处理外，“M打印小票”最主要的功能就是处理打印小票的规则了 --------- 根据输入信息确定输出哪些信息的规则，我们把它暂且成为“M2-业务规则处理”（M2代表拆分后的第二个单功能）吧。

商品虽然有很多种类，其“业务处理规则“是统一的，所以只要以一种商品来测试这个业务处理规则即可。对于多种商品的情况，与单品购物相比，只有两个变化：

一是打印的购物清单上又列出一些商品；二是商品”总计“和”省钱“两处需要将单品相应的数值累加起来。这两点不是很复杂，所以不妨把"同时购买多种商品"这种场最列到功能交互中，进行探索性测试。

这样，我们把原来一个单功能”M打印小票“拆分成了两个单功能”M1-输入数据处理“和”M2-业务规则处理“，并且将”同时购买多种商品“的复杂场景移到了功能交互中处理。

# 4 挑选一个单功能建模

批选一个单功能建模？干嘛不按流程一个一个地建模？别忘了，基于风险做测试！哪个地方比较复杂？风险比较大？我更想先了解哪一块？万一后面没有足够的时间测试了呢？

”M1-输入数据处理“比较简单，而“M2-业务规则处理”是核心功能，我打算先从M2开始。

# 5 确定边界

“M2-业务规则处理”的边界与上面单功能边界是类似的，只不过输入1中的商品信息只有一类。

其中，对最重要的输人信息“输入1”来说，它又具体包含什么信息呢？我看到的是一组编号，这个编号可以有两种形式：ITE000001和ITEM000003-2，分别代表了两类不同的商品，一类是无需称重的普通商品，一类是需要称重的商品。另外，输入1中还涵盖了该商品的数量信息，对于多于1件的商品，其数量的表示方法不一致（思考：对于普通商品比较好说，有多少行就是多少件；对于称重商品，计量单位是什么呢？可否出现小数？可否也存在多行数据，比如出现两个ITEM000003-2，或者同时存在ITEM000003-2和和ITEM000003-3？存在多行的话，后面显示商品数量时要算相加后的结果吗? )，后面的业务规则处理也是比较复杂的，所以要区分开来。这样，针对输入1就识别了两个参数出来：商品编号类型、是否大于1件。

输入信息2提取相关的参数有两个：商品名称、单价；

输入信息3为商品优惠信息，目前需求提到2种优惠信息，并且不同优惠信息处理起来是不同的，需要区分开来，于是也提取出两个参数：买二赠一、95折优惠。

输出信息比较容易识别，对于每个单品要输出：商品名称、数量、单价、小计、节省（只针对95折优惠才有）；如果有买二赠一的优惠，还要打印优惠的商品名称和数量；另外每一单还要输出商品的总计和节省了多少钱的信息。

# 6 选择模型

“M2-业务规则处理”这个单功能，占主导因素的特征是哪一个呢？流程、参数、数据、组合还是状态？

理论上说，每一个单功能都有一些数据需要处理、都可以用一个流程图来刻画，所以除非数据和流程是我们想测试的主要的点，否则我们应当从其他特征去考虑，

而对M2这个单功能，显然数据和流程不是我们最关注的；而组合一般是我们最后才考虑应用的，因为它纯粹是为了减少待测场景的数量应运而生的方法，在分析因为逻辑方面并无太大优势；接下来剩下状态和参数两种特征，比较容易判别了。

对“M2-业务规则处理”，状态的特征并不是十分明显，却有一些规则需要处理，并且能判断出来规则主要与优惠信息的参数有关。而参数（P）更适合分析规则，最终，我们可以确定“M2-业务规则处理”这个单功能，占主导因素的是P（Parameter）这个特征，因此我们可以选择判定表来建模。

# 7 确定参数（判定表表头）

输入参数和输出参数已经确定过了，因此判定表的表头已经确定好了，在真正识别一条条业务规则之前，先确定下每个输入参数的可取的值

为什么有n行、q件、q1+q2件？因为”多于1件“的这个取值参数，我们没有在需求中确认清楚，真实项目我们要搞清楚，此处使用n和q表述：

Y（n行）：对应普通商品；

Y（q件）：对应称重商品，如果只有一行称重商品的编码，比如”ITEM0000003-2“，q就等于末尾的数字，这里是2，如果有两行称重商品的编码，q就等于末尾两位数字相加q1+q2

# 思考：

这里还有什么问题吗？

# 8 识别业务规则---普通商品

先从最简单的业务规则开始：

**规则1：**普通商品，购买1件，商品名称有效，单价有效，非优惠商品，其输出包括商品名称、数量为1、单价和小计以及总计均为P，其他项目不打印。

写完这条规则，发现其实商品名称和单价，并不影响小票打印规则本身。当然，针对无效的商品名称和无效的单价需要测试，但是这种针对数据的异常测试可以放到”M1-输入数据处理”单功能中。于是，删除这两个参数，继续识别其他的业务规则。

思考：

这里还有什么问题吗？

先将普通商品的各种情况遍历掉，由于购买1件的情形比较简单，后面的规则中就只测试购买多件的情况。

**规则2：**普通商品，购买n件，非优惠商品；

规则3：普通商品，购买n件，只属于买二赠一优惠商品；

**规则4：**普通商品，购买n件，只属于95折优惠商品；

**规则5：**普通商品，购买n件，属于买二赠一和95折同时优惠商品。

我们把这些规则填进判定表吧。

将规则3填进判定表中时，遇到点问题：商品小计该是多少，我们稍加分析，购买的件数n与商品小计之间是由明确的关系的

将n换算成3的倍数：n=3a+b，那么商品小计就等于(2a+b) * p（P为单价）

观察这个判定表不难发现，规则3和规则5的输出是完全一样的，输入只有“95折”这个参数的取值有差别，这是因为需求中明确：*当“95折”和“买二赠一”发生冲突时，只享受“买二赠一”的优惠。*也就是说，当发生冲突时，“95折”这个参数的取值规则不产生任何影响，是一个不关心项，我们在表格中将其标为“-”，于是，判定表也更新了，删除原来的规则5，并且将规则3的“95折“这个参数设置为不关心项。

# 9 识别业务规则---称重商品

接下来我们识别称重商品的业务规则

**规则5：**称重商品，购买1件，非优惠商品

规则5比较简单，但也有个小疑问：称重商品只有1件时，商品编号显示的是”ITEM0000003-1“还是”ITEM0000003“？

在思考这个问题时，又会引出另一个问题：普通商品和称重商品编号规则是统一确定的、还是各自存在一套单独的编号规则？有没有可能同时存在“ITEM0000003”和“ITEM0000003-2”

**规则6：**称重商品，购买多件，只有1行编号，非优惠商品

**规则7：**称重商品，购买多件，有多行编号，非优惠商品【？】

**规则8：**称重商品，购买多件，只有1行编号，买二赠一优惠【？】

规则9：称重商品，购买多件，只有多行编号，买二赠一优惠【？】

**规则10：**称重商品，购买多件，只有1行编号，只属于95折优惠商品

**规则11：**称重商品，购买多件，有多行编号，只属于95折优惠商品【？】

判定表再次更新了。

表中的红色字体，均代表有疑问的地方，到目前位置，我们还没有写测试用例，还没有进行测试执行工作，已经发现了很多问题（风险），所以测试分析和测试设计这件事，要尽早的做，踏踏实实的做。

# 10 判定规则完整性

判定表整理出来后，是否存在规则的遗漏呢？我们把这个判定表转为判定树，方便查看。选择商品编号作为树的根节点，依次向下画，得到判定树。

从判定树可以看出有4个悬空的节点，这有可能意味着规则的遗漏，需要逐一审视下。

”？1“和"?3"这两种情况指的是，只够买1件”买二赠一“优惠的商品，此时并不会享受优惠；

”？2“和”？4“这两种情况指的是，只够买1件非”买二赠一“但享受”95折“优惠的商品。

这4种情况均有实际意义，我们需要补充到判定表中。

# 11 得出测试条件

理想情况下，我们先拿着这个Model（判定表）去和需求人员交流，澄清我们的疑问，然后修正Model，但我们选取的这个例子不具备这个条件，因此我们就继续往下进行了，真实项目中，一定要把这些疑问搞清楚！

”M2-业务规则处理”就像是一棵树，我们限制至少已经有了15条枝干需要进行测试，如果某一条枝干少测了，我们可能会担心。所以这15条枝干就像遍历树的基本路径一样，我们把他们称为“测试条件”

测试条件代表了要对单功能进行测试的一些基本的测试场景。我们对单功能M建模后，可以识别出来该单功能一共有多少个基本场景，并且知道每一个场景是什么，这就意味着，我们可以根据测试实际情况进行优先级排序，基于风险优先测试那些更重要的场景。

假设针对这个“M2-业务规则处理“，一共15个测试条件，我们仅测试覆盖了10个测试条件，那么我们知道我们的测试覆盖为10/15=66.7%。

这个覆盖度合理吗？要不要提高到100%？

我们要具体分析，剩下优先级不那么高的5个场景，和项目中其他还未测试的内容比，哪个优先级更高？哪个质量风险更大？把优先的测试时间和资源投入到哪个上面更合适一些？不要一味的，不假思索的追求高的测试覆盖率。

如果时间允许，或者项目有这个需要，我们可以使用更易懂的文字描述上述的这15个测试条件------这不是必须的：

Given：给定被测对象所处的预置状态（预置条件）

每个测试场景都是在一个预置的状态下发生的，这可能包括被测系统当前的状态，与被测系统相关的另一个系统的状态等。从某种程度上讲，这些预置的状态也是测试时隐含的输入。
When：当执行某个操作时（动作）

用户/模块/系统执行了某个操作，或者向某个函数传入了一个指定的参数，这些就是某个测试场景主要的、显式的输入，表明被测对象在某个特定状态下，受到了一个外在的”激励“
Then：发生了什么事（后置条件）

被测对象在这个”激励“下的反应，比如返回一个值、执行一个动作、抛出一个异常等。同时不i要忘记此时被测系统的状态是否发生变化，这些都是测试中要仔细观察的内容。

下面我们选择前两个测试场景作为例子，描述下测试条件

# 12 M1建模

”M1-输入数据处理“这个单功能不涉及业务规则的处理，要简单许多，其主要范围式”针对输入1“的数据，即用户购买的商品信息，对各种典型的、非典型的数据数据进行测试”

还是一样的问题，我们来给M1选一个模型，PPDCS，显然是数据（D），因此我们可以用等价类的方法来建模。

首先我们来识别一下有哪些Data，一个正常的输入数据格式如下：

[
    'ITEM000001',
    'ITEM000001',
    'ITEM000001',
    'ITEM000001',
    'ITEM000001',
    'ITEM000003-2',
    'ITEM000005',
    'ITEM000005',
    'ITEM000005'
]

1
2
3
4
5
6
7
8
9
10
11

比较明显的信息前面分析M1时已经提到了，比如商品编号、称重商品编号、以及商品ITEM的行数。

这里有问题吗？

接下来，要识别每一个数据的有效等价类（VEC-Valid Equivalent Class）和无效等价类（IVEC-Invalid Equivalent Class）。

这个模型中，我们列举出了我们能想到的一些无效等价类，看起来已经很多了，但仍然可能有遗漏，没关系，建模的过程不是一次完成的，想到的时候再更新就OK了。

那么多无效等价类，是不是考虑的异常输入太多了？有些是不是没必要啊？注意，我们现在只是分析每一个Data可能的无效等价类而已，这并不代表每一种情况都要去测试，决定要不要测试的因素，还是风险大小，这个和测试场景（测试条件）的识别有关，我们接下来就做这个。

# 13 M1识别测试条件

针对等价类表这样的model，有多种方式可以完成覆盖，最简单的方式，就是设计足够多的测试条件，确保每一个有效等价类和无效等价类都被覆盖到就可以了。

另外一种覆盖等价类的方式是根据引起缺陷的故障因子个数以及是否覆盖无效等价类进行区分，共有如下4中组合。

单因子故障假设和多因子故障假设的说法也是借鉴工程领域对于故障模型和故障假设的概念。

假设测试中发现一个异常现象，如果我们预测这个异常极有可能只与其中某一个变量有关，不大可能是两个或两个以上的变量同时作用引起的，那么就是单因子故障假设。相反，如果我们预测软件中的很多异常都是由于两个或两个以上变量的某种组合导致，那么就是多因子故障假设。

假设有两个数值型的Data：X1和X2。

X1的有效等价类为[e, f)，[f, g)，无效等价类是[0,e)，[g, Max1]；
X2的有效等价类是[a, b)，[b, c)，[c, d)，无效等价类是[0, a)，[d, Max2]

那么对应4种覆盖等价类的方式如下表，圆点代表在相应的等价类种选取一个值测试。

那么这4种覆盖等价类的方式究竟选取哪一种呢？依然要根据我们的测试对象，根据当前对风险的判断来确定。

对于打印小票这个例子，我们可以选取弱健壮等价类来覆盖，详情如下表：

测试条件1覆盖有效等价类组合；
测试条件2~9覆盖”普通商品编号“这个Data的无效等价类；
测试条件10~19覆盖”称重商品编号“这个Data的无效等价类；
测试条件20~21覆盖”商品ITEM的行数“这个Data的无效等价类；
测试条件22~24覆盖”商品ITEM的排列“这个Data的无效等价类；

相对完整的测试覆盖需要投入的精力是比较大的，即使我们这样做了等价类划分的覆盖，我们的测试仍然是不完整的，因为在实际工作中，还会有我们没有考虑到的等价类、还会有我们未知的需求、还会有那些我们未知的单功能、还会有单功能之外的多功能交互和其他非功能性的质量属性部分。如果不加以分析和辨别，就一味的指望着使用一种方法解决测试完整性的难题，用所有的测试资源和时间去追求100%的等价类覆盖，只能事与愿违！

# Q&A问答

# 课后练习

#测试基础

上次更新: 7/26/2026, 3:17:15 PM

← 测试分析测试用例→