条件覆盖和条件组合覆盖测试设计-实验八例题

目录

条件覆盖

判定-条件覆盖

条件组合覆盖

实验内容：         以银行内部转账为实例，针对内部转账业务逻辑代码进行分析，运用条件覆盖和条件组合覆盖进行测试用例设计。

实验过程：

---

条件覆盖

条件覆盖（Condition Coverage）指的是设计足够多的测试用例，使判定语句中的每个逻辑条件取真值与取假值至少出现一次，例如，在上一个实验的案例中，对于判定语句IF(a>1 OR c<0)中存在a>1、c<0 2个逻辑条件，设计条件覆盖测试用例时，要保证a>1、c<0的“真”“假”值至少出现一次。下面设计条件覆盖测试用例，在该程序中，有2个判定语句，每个判定语句有2个逻辑条件，共有4个逻辑条件，使用标识符标识各个逻辑条件取真值与取假值的情况，如表1所示。

在表1中，使用S1标记x>0取真值（即x>0成立）的情况，-S1标记x>0取假值（即x>0不成立）的情况。同理，使用S2、S3、S4标记y<0、x>2、z>0取真值，使用-S2、-S3、-S4标记y<0、x>2、z>0取假值，最后得到执行条件判断语句的8种状态，设计测试用例时，要保证每种状态都至少出现一次。设计测试用例的原则是尽量以最少的测试用例达到最大的覆

盖率，则该段程序的条件覆盖测试用例如表2所示。

判定-条件覆盖

         判定-条件覆盖（Condition/Decision Coverage）要求设计足够多的测试用例，使得判定语句中所有条件的可能取值至少出现一次，同时，所有判定语句的可能结果也至少出现一次。

例如，对于判定语句IF(a>1 AND c<1)，该判定语句有a>1、c<1两个条件，则在设计测试用例时，要保证a>1、c<1两个条件取“真”“假”值至少一次，同时，判定语句IF(a>1 AND c<1)取“真”“假”值也至少出现一次。这就是判定-条件覆盖，它弥补了判定覆盖和条件覆盖的不足之处。

根据判定-条件覆盖原则，为该程序段设计判定-条件覆盖测试用例，如表3所示。

表3   判定-条件覆盖测试用例

在表3中，条件1是指判定语句“IF x>0 AND y<0”，条件2是指判定语句“IF x>2 OR z>0”，条件判断的值0表示“假”，1表示“真”。表3-4中的3个测试用例满足了所有条件可能取值至少出现一次，以及所有判定语句可能结果也至少出现一次的要求。

相比于条件覆盖、判定覆盖，判定-条件覆盖弥补了两者的不足之处，但是由于判定-条件覆盖没有考虑判定语句与条件判断的组合情况，其覆盖范围并没有比条件覆盖更全面，判定-条件覆盖也没有覆盖acd路径，因此判定-条件覆盖仍旧存在遗漏测试的情况。

条件组合覆盖

条件组合（Multiple Condition Coverage）指的是设计足够多的测试用例，使判定语句中每个条件的所有可能至少出现一次，并且每个判定语句本身的判定结果也至少出现一次，它

与判定-条件覆盖的差别是，条件组合覆盖不是简单地要求每个条件都出现“真”与“假”两种结果，而是要求让这些结果的所有可能组合都至少出现一次。

仍以之前案例程序为例，该程序中共有4个条件：x>0、y<0、x>2、z>0，我们依然用S1、S2、S3、S4标记这4个条件成立，用-S1、-S2、-S3、-S4标记这些条件不成立。由于这4个条件每个条件都有取“真”“假”两个值，因此所有条件结果的组合有24=16种，如表4所示。

表4列出了4个条件所有结果的组合情况，经过分析可以发现，第2、6、8、13这4种情况是不存在的，这几种情况要求x>0不成立，x>2成立，这2种结果相悖，因此最终所有条件组合情况有12种。根据这12种情况设计测试用例，具体如表5所示。

表5有12个测试用例，这12个测试用例覆盖了4个条件结果的所有组合，与判定-条件覆盖相比，条件组合覆盖包括了所有判定-条件覆盖，因此它的覆盖范围更广。但是当程序中条件比较多时，条件组合的数量会呈指数型增长，组合情况非常多，要设计的测试用例也会增加，这样反而会使测试效率降低。

实验内容：
         以银行内部转账为实例，针对内部转账业务逻辑代码进行分析，运用条件覆盖和条件组合覆盖进行测试用例设计。

         内部转账用于处理发起户口号和接收户口号都是内部账户的系统内资金转账业务，主要用于财务资金的划拨、未实现自动清算业务的清算资金的划拨。

         （1）内部转账发起是指：发起行发出内部资金交易，并换人复核，满足条件时需会计主管授权。

         （2）内部转账接收是指：内部资金交易接收方根据接收方确认方式，对交易进行接收经办，满足条件的需复核或授权。

         确定接收方的入账流程，“确认方式”分为以下三种：
         （1）不需接收方确认，即发起方发起后自动记发起方和接收方的一套账务，接收方无须再做接收动作。

        （2）需接收方确认，即接收方接收时不能更改接收信息，只能依据发起方输入的信息入账或退发起方。以目前的处理方式，接收经办→入账（金额小于100万元），大于100万元时为接收经办＋接收授权→入账。

        （3）需接收方经办，即接收方接收时可以更改接收信息，执行入账或退发起行。以目前的处理方式，接收经办＋接收复核→入账（金额小于100万元），大于100万元时为接收经办＋接收复核＋接收授权→入账。

内部转账权限控制如表6所示。

以下为银行内部转账控制的部分伪代码实现：

实验过程：

1. 测试分析
（1）根据银行内部转账业务描述，分析内部转账流程，包括主流程、分支流程以及正常流程、异常流程。

（2）模拟内部转账场景：触发内部转账的条件，不同条件是否走不同的转账流程。（3）数据项检查：数据项的计算规则，数据项后台判断逻辑。

2. 测试设计
根据内部转账业务需求，设计出程序流程图，并对程序流程图做节点标记，分析流程图

的判定条件与结果。

A~Q为测试路径编号，在下面的测试用例分析中将根据测试路径编号确定测试用例的业务流向。

         根据图2-1所示的流程图，标记出节点。根据条件覆盖方法来进行分析，得到如表2所示的符合条件覆盖标准的测试用例。

S(2)条件组合覆盖

对于判定1：

①条件转账金额＞100W   取真为T1

②条件转账金额＜=100W  取假为F1

对于判定2：

①条件“确认方式”==1	取真为T2
②条件“确认方式”==2	取真为T3
③条件“确认方式”==3	取真为T4
④条件T2、T3和T4都不成立		取假为F2

对于判定3：

        ①条件“确认方式”==2  取真为T5

        ②条件“确认方式”==3  取真为T6

        ③条件T5和T6都不成立 取假为F3
通过设计足够多的测试用例，使得被测试程序中的每个判断的所有可能条件取值的组合

至少出现一次。在这个银行内部转账流程上，判定1的条件和判定2、3中的条件分别构成组合。由于业务特定的逻辑，其组合简化为7个，而不是14个。

         ①判定1的条件T1和判定3中的各个条件构成组合，即3个组合，而不是2×3=6个组合；

         ②判定1的条件F1和判定2中的各个条件构成组合，即4个组合，而不是2×4=8个组合。

因此根据条件组合覆盖，总共有7个测试用例完成组合覆盖，如表3所示。这里不考虑异常情况，如转账金额＜=0的情况。遇到这种情况会直接异常退出，也无法进入下一个判定2或判定3，和组合也没关系。