《软件测试设计》第3章——基于规格说明的测试（1）
概念：通过分析组件或系统的测试依据文档，而不是其内部结构获取和选择测试用例的一种方法。
为黑盒技术
基于规格说明测试的共同特点：
① 利用正式或非正式的模型来描述待解决的问题、软件或其组件
② 根据模型系统地获取测试用例
基于规格说明的测试可帮助测试人员选择合适测试用例。
基于规格说明的测试通常由以下步骤组成：
① 分析规格说明。
② 根据规格说明选择有效的输入以确定测试对象是否可正确地实现需求，也需选择无效的输入确定测试对象以正确地处理它们。
③ 根据输入数据确定系统的期望输出。
④ 执行测试用例。
⑤ 将测试执行得到的实际结果与期望结果进行比较。
⑥ 确定测试对象的实现是否符合规格说明。
3.1 等价类划分
作用：用来减少测试用例数目，并保证合理的测试覆盖率。
概念：将输入域输出域划分为不同的等价类，其中的任何值都能使组件或系统产生相同的响应结果。
对于等价类划分技术而言，只要测试等价类中的一个代表值就足够。
不仅需测试有效的等价类（指合理且有意义的数据构成的集合）；还需测试无效的等价类（指不合理且错误的数据构成的集合）
等价类划分技术的对象即可是输入，也可是输出
3.1.1 识别等价类
不同的输入类型需要不同的等价类划分
① 若输入是连续数值。通常有一个有效等价类和两个无效等价类，两个无效等价类的其中一个为高于有效值的范围；另一个为低于有效值的范围。
② 若输入是离散数值。通常有一个有效等价类和两个无效等价类。
③ 若输入是一组选项，并且测试对象对这组选项中每个值执行相同处理，那么可为输入创建一个有效等价类（该组选项中的任一数值）和一个无效等价类（所有不在该组选项中的值）。
④ 若输入是一组选项，并且测试对象对这组选项中每个值执行不同处理，那么可将该组选项中的每个输入都划分一个有效等价类，然后单独划分一个无效等价类（不在该组选项中的任何其他选项）。
⑤ 若规定了输入数据必须遵守某些规则，那么可划分一个有效等价类（满足所以规则）个若干无效等价类（从不同角度违反规则）
⑥ 若输入数据是布尔变量，可划分一个有效等价类和一个无效等价类
⑦ 在已划分的等价类中元素这程序中处理方式不同时，需将该等价类进一步划分为更小的等价类。
3.1.2 创建测试用例
由于测试资源的限制，通常情况下测试人员需创建一个测试用例同时验证多个输入数据的等价类。
基于等价类划分技术设计测试用例时需为每个参数赋予一个输入值，为此必须确定如何组合这些等价类的代表值使其成为一组有效的输入数据。
相应等价类的输入可根据下面原则组合：
① 所有有效等价类的代表值的组合都需要集成到测试用例中，即覆盖有效等价类的所有组合。
② 无效等价类的代表值只和其他有效等价类的代表值组合，有效等价类代表值的选择可以随意。
根据上述组合原则，可得有效测试用例（正面测试用例）的个数等于每个输入参数的有效等价类个数的乘积；而无效测试用例（负面测试用例）的个数为无效等价类的个数。
上述原则所需测试用例仍然过多，故采用如下规则减少测试用例的数目。
① 根据输入参数的代表值组合而成的有效测试用例和无效测试用例按照测试用例的使用频率和重要程度排序，为每个测试用例设置不同优先级。有针对地选择要执行的测试用例。
② 优先选择包含边界值或边界值组合的测试用例
③ 将一个等价类的每个代表值和其他等价类的每个代表值组合设计测试用例（双向组合代替完全组合）
④ 保证满足最小原则，即一个等价类的每个代表值至少在一个测试用例中出现
3.1.3 覆盖率准则
等价类划分技术的测试准则可定义如下：
等价类划分覆盖率=（执行的等价类数量/总的等价类数量）×100%
3.1.4 案例分析：LACP参数等价类测试
① 案例描述
如图为LACP图形配置界面
Index取值范围10001~10006，整型
ActorKey取值范围1~65535，整型
AggregatorSize取值范围1~8，整型
AggregatorName必须由字母组成，长度不超过8
测试人员的目标：
(1) 识别案例中不同参数输入域的等价类
(2) 细分等价类。
(3) 根据得到的等价类创建相应的测试用例。
(4) 分校相关的覆盖率准则
② 识别等价类
下表为LACP相关参数的有效等价类和无效等价类
③ 细分等价类
测试对象的需求规格说明或者功能规格说明不仅是等价类划分的基础，还需对其进行分析以发现其中的漏洞。分析过程可对前面定义的等价类进一步细化。若同时考虑规格说明中每个输入参数的所有条件，并结合测试人员的经验知识，就可认为完成了等价类的划分。
经过分析，Index、ActorKey和AggregatorSize参数还需增加“非整数”无效等价类，最终生成16个等价类，包括4个有效等价类和12个无效等价类。
LACP输入参数的等价类和代表值
④ 创建测试用例
根据有效等价类的原则，可以得到有效测试用例数目为1（1×1×1×1=1）
根据无效等价类的原则，可以得到无效测试用例数目为12（3+3+3+3=12）
因此从16个等价类得到了13个测试用例，如下：
在选择测试用例的输入后，还需为每个测试用例确定期望的结果。
⑤ 覆盖率准则
根据等价类划分技术的覆盖率准则，即执行的等价类数量与总的等价类数量的比值可以得到针对LACP功能的等价类覆盖率。
对于本例，输入参数等价类总数共16个，测试用例数目为13个。只要执行13个测试用例，就可以覆盖16个等价类，即实现100%的等价类覆盖率。
若没执行ID为13的测试用例，只执行了其他12个测试用例，对应只覆盖了15个等价类，等价覆盖率为93.75%
3.2 边界值分析
边界值分析是种测试软件边界值的技术，是等价类划分技术的有效补充。
出现边界值错误的主要原因：
① 测试对象规格说明中没有明确定义输入域的边界值。
② 开发人员容易对边界值产生误解。
边界值分析技术适用于等价类中有明确边界值的情况。针对每个参数的边界，需测试边界值和两个邻近的值。因此需要在边界值的两边，以最小的步长分别取值，步长的定义依赖于参数的单位和类型。
边界值分析技术的步骤如下：
① 识别测试对象中参数的等价类
② 识别每个等价类的边界值
③ 创建边界值相关测试用例
④ 定义边界值分析技术的覆盖率
3.2.1 识别等价类
详细参加3.1节
3.2.2 识别边界值
① 若输入是连续数值，必须考虑边界值和边界值邻近的上下两个数值。
② 若输入是离散数值，同样考虑边界值和边界值邻近的上下两个数值。
③ 对于有序集合，集合元素的第1个和最后1个是测试感兴趣的对象
④ 若是复杂的数据结构作为输入或输出，那么一个空的列表或0矩阵可以作为边界值
⑤ 对无效等价类，只有其内部值可以触发测试对象不同的异常处理时边界的分析才有意义
⑥ 对于列表和表格，空列表和满列表以及列表的第1个元素和最后1个元素都应作为分析的对象，因为对其测试常常可发现由于编程错误而导致的失效。
⑦ 应尽量选择庞大的数据结构、列表和表格等作为边界值分析的数据，如能导致内存溢出、文件和数据存储达到边界的数据，以检查测试对象在这种极端情形下的行为。
常见边界值类型：
① 对16bit整数而言，边界值32767和-32768
② 屏幕上光标和左上和右下位置
③ 数组元素的第1个和最后1个
3.2.3 创建测试用例
类似用等价类划分技术设计测试用例，有效等价类范围内的有效边界值也需在测试用例中组合，无效边界值在测试用例中单独验证。
3.2.4 覆盖率准则
类似于等价类划分技术完成准则，边界值分析技术的覆盖率定义如下：
边界值覆盖率=（执行的边界值的数量/总的边界值的数量）×100%
注意边界值数量必须考虑边界值上限和下限的临近数值的数量。
临近等价类的重叠数据作为一个边界值看待，此时只有一个测试用例与之相对应。
3.2.5 案例分析：LACP参数边界值测试
边界值分析技术是等价类划分技术的有效补充。
下仍采用3.1.4节中案例1
① 识别等价类
识别出的等价类参见3.1.4节的内容
② 识别边界值
得到LACP输入参数后，需识别每个参数的等价类的边界值。根据前面提到的边界值分析的有关建议，得到相应的边界值如下：
参数Aggregator Name定义了有效边界值和无效边界值，它是基于长度展开的。若条件允许，也可针对Aggregator Name中字母组成规则定义边界值。
上表所示参数的有效边界值即包括有效等价类的边界，也包括有效等价类中与边界值相邻的值。实际应用中可根据测试资源情况，决定对边界是否补充。下表为只包括最直接的边界值，共得到16个边界值，其中有效边界值为8个，无效边界值8个。
③ 创建测试用例
类似等价划分技术
根据上表可知，基于有效边界值分析得到的测试用例数目为16个（2×2×2×2=16）
无效测试用例数目为8（2+2+2+2=8），故从16个边界值得到24个测试用例。
在选择测试用例的输入后，需为每个测试用例确定期望的结果，如下表所示。
④ 覆盖率准则
类似等价类划分的覆盖率准则，同样边界值覆盖率也可作为测试出口准则之一。
注意，边界值的数量必须考虑边界值上限的邻近数值和下限的邻近数值的数量，具体数量只针对不相等的输入值。对于邻近等价类的重叠数据作为一个边界值来看待，因为此时只有一个测试用例与之对应。
3.3 决策表测试
决策表可方便获取特定的系统需求并记录测试对象的内部实现，可记录测试对象的各种复杂规则，并有效地指导测试用例的设计。
决策表是分析和表达多逻辑条件下执行不同操作的表格，能够将复杂的问题按照各种可能的情况全部列举出来，以避免遗漏测试需求，故利用决策表可设计出比较完整的测试用例集合。决策表测试技术特别适用于针对不同逻辑条件的组合，测试对象需执行不同操作的场景。
决策表由4部分组成：
① 条件桩。列出测试对象的所以条件。一般情况下，列出的条件次序不影响测试对象的动作。
② 动作桩。列出测试对象所有可能执行的操作。一般情况下，这些执行的操作没有先后顺序约束。
③ 条件项。列出针对特定条件的取值，即条件的真假值。
④ 动作项。列出在不同条件项的各种取值组合情况下测试对象应执行的动作。
其格式如下
| 规则 | 规则1 | 规则2 | …… | 规则p | |
| 条件桩 | 条件1 | ||||
| 条件2 | |||||
| …… | |||||
| 条件m | |||||
| 动作桩 | 动作1 | ||||
| 动作2 | |||||
| …… | |||||
| 动作n | |||||
条件桩中条件1、2到m表示测试对象的各种输入条件；动作桩中动作1、2到n表示测试对象根据不同输入条件的组合需要执行的操作。规则1、2到p定义了不同条件组合下测试对象需要执行的操作。
决策表测试的主要步骤：
① 列出所有条件桩和动作桩
② 确定规则的数目。若有n个条件，每个条件有两个取值（0或1），则共有2n个规则。
③ 填入条项和动作项得到初始的决策表。
④ 简化相似的规则得到优化的决策表。
⑤ 每列规则设计一个测试用例
下利用案例进行介绍
案例2 判断三角形类型
输入3个整数值a、b和c，判断三角形类型
3.3.1 确定条件桩和动作桩
首先分析测试对象，确定测试对象的输入个数（条件的数目）和输入个数（动作的数目），并且确定决策表规则的数量。
经分析，可得到如下4个条件（并不唯一）：
① C1：a、b和c构成三角形？
② C2：a=b？
③ C3：a=c？
④ C4：b=c？
当条件桩中条件数目为n时，可的初始决策表的规则数目为2n个。
本案例共16个规则。
本案例最终确定的动作桩如下：
① A1：非三角形
② A2：不规则三角形
③ A3：等腰三角形
④ A4：等边三角形
⑤ A5：不符合逻辑
3.3.2 初始决策表
三角形初始决策表如下所示。
3.3.3 优化决策表
检查上表，可看出有的动作对应一个规则，有的动作对应多个规则，因此需要优化。将具有相同动作且条件项之间存在相似关系的规则进行合并，相关条件项置位“不关心”，用“-”表示。例如，当条件“C1：a、b和c构成三角形？”的取值为N时，后面几个条件的判断没有意义，结果都是“A1：非三角形”；同时删除初始决策表中不符合逻辑的规则，优化的决策表如下：
决策表优化可从以下几个方面进行：
① 引入“不关心”的条件。在初始的决策表中规则9至16中C2、C3和C4是不用关心的条件
② 检查决策表中是否存在不一致处，如相同的规则产生不一致的动作，此时需要严格分析：
(1)重新分析测试对象，确定是否是测试人员分析和理解有误导致决策表设计错误。
(2)重新分析测试对象，确定是否由于测试对象的规格说明本身有误造成决策表设计错误。
③ 简化决策表，删除冗余规则。判断决策表是否冗余，可为决策表的每个规则引入规则计数器
(1)若规则内没有包含“不关心”条件，规则计数器为1.
(2)若规则中出现一个“不关心”条件，规则计数器乘2。出现n个，计数器为2n
(3)若决策表的规则计数器综合大于2n（此处n为桩中条件的数目），则决策表内有冗余项。
3.3.4 创建测试用例
针对优化后的决策表，把其条件项组合作为输入，动作项作为输出，每条规则可得一个测试用例。
本案例结果如下所示
3.3.5 覆盖率准则
决策表测试也可以明确定义覆盖率准则，基本要求是决策表的每一列（规则）至少要有一个测试用例覆盖
3.3.6 因果图和决策表
除了决策表，也可基于因果图技术得到测试用例，或通过因果图得到决策表，再得测试用例。
因果图中的“因”：一个明确的输入条件或输入条件的等价类。“果”：一个输出条件或输出动作。
将“因”和“果”通过布尔图连接成因果图，其基本符号如下：
= ！ || &&
每个节点值为0或1，0表示不存在，1表示存在。
决策表和因果图可相互转换。
① 决策表转换为因果图
(1) 罗列决策表条件桩中的所有条件，作为因果图的“因”
(2) 罗列决策表动作桩中的所有动作，作为因果图的“果”
(3) 根据决策表中的每个规则，确定哪些条件的组合可得相关的动作，并通过因果图符号连接。
② 因果图转换为决策表
(1) 将因果图的所有条件（因）填入决策表的条件桩中。
(2) 将因果图的所有动作（果）填入决策表的动作桩中。
(3) 根据因果图确定各条件组合对应的动作，并确定决策表各个规则的条件项和动作项，在需要时优化决策表。
3.3.7 案例分析：ATM取款的决策表测试
① 案例3：ATM取款
ATM取款需满足如下条件
(1) 银行卡有效
(2) 密码正确
(3) 若密码错误。最多输入3次
(4) 银行卡账号有钱
ATM可能动作
(1) 拒绝银行卡
(2) 要求重输密码
(3) 吞卡
(4) 要求重输入取款金额
(5) 输入要求数目的现金
根据描述，采用决策表测试技术，目标如下
(1) 根据案例中提供的条件或动作获取测试对象的因果图
(2) 将得到的因果图转换为响应的决策表
(3) 优化决策表
(4) 根据优化的决策表得到相关测试用例表
② 因果图
③ 初始决策表
④ 优化决策表
去除不相关和冗余
⑤ 创建测试用例
每条规则可设计一个测试用例
3.4 状态转换测试
3.4.1 状态转换图
状态转换图描述了测试对象和数据之间的关系。
测试对象的输出和行为不仅和当前输入数据有关，且与测试对象当前状态有关。
状态转换图是设计状态转换测试用例的基础，基于状态转换图进行的测试就是状态转换测试。
测试对象从初始状态可转换到不同的状态，状态转换图中的各个状态通过不同的事件驱动，如函数调用：除初始状态之外，还有一个特殊的状态是结束状态。
下举例介绍
案例4 某航空公司的订票系统
订票系统转换图如下
① 状态：以圆圈表示，状态可反映系统以前的时间，并决定系统可能发生的事件的反应。
② 转换：以箭头表示，转换指的是由于事件的驱动，系统从一个状态到另一个状态
③ 事件：和特定的转换相关联，以具体的时间名称表示。事件可驱动状态的转换或其他动作，通常来说，事件由系统的相关接口触发，也可来自系统内部，如计时器超时。事件可以是独立的，也可是相互关联的，如事件A必须在事件B之后发生。
④ 活动：以“/”形式表示，活动由状态转换触发，如出票（Ticket）。通常活动得到的结果会作为系统的输出。活动一般在状态转换过程中发生。
⑤ 条件：以“[]”表示，可以是True或False，说明状态转换只有在满足这个条件之后才能进行。
⑥ 特殊状态：开始状态和结束状态
3.4.2 测试用例
状态转换测试经常利用状态转换树或状态转换表设计测试用例。
① 状态转换树
将可能具有无限多状态循环的状态转化图转换为不含循环的具有一定数目状态的状态转换树。
转换过程需覆盖所有状态，并包含状态转换图中的所有转换。
转换步骤如下（针对0-Switch）：
(1) 将初始状态或开始状态作为状态转换树的根，根在整个状态转换树中的层次是1。
(2) 假设当前生成状态转换树的层次为K，那么从左到右检查所有层次为K的节点。将该节点对应的所有下一个可能状态作为其子节点，状态之间的转换作为两个状态的边。
(3) 重复(2)，直到一个位于层次K上的节点出现在层次J上，且J≤K。这个节点成为最终的叶节点，无须继续生成其子节点。或节点的状态是结束状态，也不需要针对该节点继续进行状态转换。
案例4的状态转换图转为的状态转换树的结构如下：
生成状态转换树后即可根据不同的测试强度得到如下测试用例列表：
(1) 至少覆盖所有状态一次：3个测试用例即可满足该覆盖率要求。
(2) 至少覆盖所有事件一次：3个测试用例就能覆盖所有事件。
本案例中覆盖所有事件和所有状态的测试用例相同，如下图所示
(3) 至少覆盖所有的状态转换一次：需5个测试用例覆盖所有事件。
这个级别的测试可以提供较好的测试覆盖率，也可确保生产的测试用例数目不是很庞大，这是状态转换测试技术最常用的覆盖率
(4) 至少覆盖所有路径一次：这个级别的覆盖率最高，但经常是不现实的。若状态转换图中有循环的情形，那么可能的路径是无穷的。例如AB可以相互转换
A→B→A→B→A。。。
这样路径是无穷的。但覆盖这样循环的测试用例对于发现一些累计的计算错误或资源方面的缺陷非常重要，如内存泄露。
除了设计测试用例覆盖所有的状态、事件和路径之外，还需检查再不同状态情况下错误调用函数的测试用例。
② 状态转换表
由状态转换图可得相应状态转换表，如下表所示。
状态转换表优点是罗列了所有可能的状态转换组合，且不仅仅是有效的状态转换
利用状态转换表可发现测试对象实现方面的问题，如实现了无效或不希望的状态转换路径。
状态转换表缺点是当测试对象的状态和事件增加时，它会快速增加；另外表格很多多余或空白单元格。
上表中灰色条目是所有有效的状态转换，最终生成有效状态转换的测试用例如下表所示。
| 编号ID | 当前状态 | 事件 | 活动 | 后续状态 |
| 1 | null | GiveInfo | StartPayTimer | Made |
| 2 | Made | PayMoney | -- | Paid |
| 3 | Made | Cancel | -- | CancelledByCustmer |
| 4 | Made |
PayTimerExpires |
-- | CancelledByNonPay |
| 5 | Paid | Ticket | Ticketed | |
| 6 | Paid | Cancel | Refund | CancelledByCustmer |
| 7 | Ticketed | GiveTicket | -- | Used |
| 8 | Ticketed | Cancel | Refund | CancelledByCustmer |
选择有效状态转换后，可根据测试对象的风险选择部分无效的状态转换，确定测试对象是否实现了某些不该实现的无效状态转换
3.4.3 N-Switch
定义：程序图中长度为n+1的连续的边或弧线（通常在状态图中表示循环）的序列。
单独的一条边就是一个0-Switch，两条连续边的序列就是1-Switch
下图为状态机
根据0-Switch定义，其状态转化图如图
根据1-Switch定义，该状态机所有1-Switch为ab、ac、bb、bc、cd、ce、dd、de、ea、ef、fd和fe。1-Switch状态树的生成规则是在0-Switch状态树的基础上再增加一个层次，即针对0-Switch状态树的所有叶节点，把每个叶节点可能的下一个状态作为该节点的子节点。注意只需增加一个层次。
3.4.4 覆盖率准则
如3.4.2所述，状态转换测试有如下测试强度，即覆盖率准则。
① 状态覆盖：每个状态至少执行一次
② 事件覆盖：每个事件至少执行一次
③ 状态转换覆盖：每个状态转换至少执行一次
④ 路径覆盖：每个路径至少执行一次
3.4.5 案例5分析：堆栈的状态转换测试
① 案例5描述
堆栈的状态转换图如图
根据堆栈状态转换图，测试人员可采用以下方法获得测试用例列表
(1) 根据状态转换图获取0-Switch的状态转换表，并得到满足0-Switch覆盖率的测试用例列表
(2) 根据0-Switch的状态转换表获取扩展的0-Switch的状态转换表，并得到相关的测试用例列表
(3) 根据0-Switch的状态转换图获取1-Switch的状态转换图，并得到满足1-Switch覆盖率的测试用例列表
② 状态转换树（0-Switch）
可看出一共8个叶节点，所以从堆栈的根节点到最后的叶节点共可产生8条不同的路径，每条路径代表一个测试用例就可实现所有路径的覆盖率（0-Switch覆盖）。此时可保证每种状态至少到达一次，并且根据测试对象的规格说明在每个状态中调用相关函数。测试用例如表所示
若需检查堆栈对函数的异常处理，那么可增加健壮性测试来确认是否会出现不应该出现的状态转换。扩展状态转换树如下图所示，使每个节点都尽可能多地调用函数，即对每个状态尽量执行所有的函数。
总共12条路径，所以还需增加4个健壮性测试用例
③ 状态转换树（1-Switch）
若要求得到的覆盖率达到1-Switch，需扩展0-Switch的状态转换树
