软件测试实验三 修正条件/判定覆盖测试设计

一、实验目的

1、 巩固所学的修正条件/判定覆盖测试方法；
2、提高运用语修正条件/判定覆盖测试方法的能力。

二、实验前提

1、 掌握逻辑覆盖的基本方法、概念；
2、熟悉程序语言的逻辑结构与基础知识；
3、选择一段程序语言。

三、实验内容

以信用卡还款为实例,见图3-1,针对信用卡还款业务逻辑代码进行分析,运用修正条件/判定覆盖法进行测试用例设计。信用卡还款是网上银行系统和第三方支付平台的常见功能。登录第三方支付平台,选择信用卡还款模块,进入信用卡还款页面。在信用卡还款页面的第二步操作页面,验证储蓄卡是否有效并进行还款。信用卡还款业务流程描述如下。
(1)在“填写还款信息”页面,输入信用卡卡号、持卡人姓名,单击“确定付款”按钮,进入“使用储蓄卡付款”页面；
(2)在“使用储蓄卡还款”页面,输入储蓄卡卡号、持卡人姓名、单击“下一步”按钮,进入还款详细”页面；
(3)在“还款详细”页面,在“还款类型”下拉框中选择“全部还款”或“分期还款”,单击“确定还款”按钮完成还款。
以下为通过第三方支付平台进行信用卡还款的部分伪代码实现。

四、实验环境

1. 首先要让学生了解信用卡还款业务场景，能够模拟操作信用卡还款流程；
2. 能够将业务场景与代码逻辑关系对应；
3. 根据代码画出程序流程图，并分析各判定节点；
4. 根据代码流程图分析出判定条件与真假取值。

五、实验过程简述

1. 明确被测试对象使用的测试方法；
2. 小组讨论业务场景并进行分析；
3. 测试实施工作安排；
4. 评审程序流程图和测试用例；
5. 执行测试，根据测试用例带入各条件测试数据，给出测试结果。

六、实验过程实施

1.测试分析
（1）根据信用卡业务描述,分析信用卡还款流程,包括主流程、分支流程以及正常流程、异常流程。
(2)模拟信用卡还款场景:触发信用卡还款的条件,不同条件是否走不同的还款流程。
(3)信用卡还款数据项检查:数据项的计算规则;数据项后台判断逻辑。
2.测试设计
根据信用卡还款代码,设计出程序流程图(图3-2),并对程序流程图做节点标记,分析流程图的判定条件与结果。

3.测试执行
根据业务场景与逻辑判定，运用修正条件/判定覆盖法进行用例设计。修正条件/判定覆盖法是为了实现条件/判定覆盖中尚未考虑到的各种条件组合情况覆盖,减少条件组合覆盖中产生的过多、无价值的测试用例。具体地说,修正条件/判定覆盖满足以下条件：
(1)每个判定的所有可能结果至少能取值一次(达到判定覆盖)。
(2)判定中的每个条件的所有可能结果至少取值一次(达到条件覆盖)。
(3)一个判定中的每个条件独立地对判定的结果产生影响(在条件组合中固定一个变量或条件,改变另一个变量或条件,如果对结果有影响,就需要测试,如果对结果没有影响就不需要测试)。
(4)每个入口和出ロ至少执行一次,覆盖不同人口或出口的路径。
根据修正条件/判定覆盖方法(MC/DC)进行分析,得到如表3-1所示的符合MC/DC质量标准的测试用例。
测试用例

七、实验小结

"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。
判定覆盖比语句覆盖要多几乎一倍的测试路径，当然也就具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。
往往大部分的判定语句是由多个逻辑条件组合而成（如，判定语句中包含AND、OR、CASE），若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。
多重条件覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。更改的判定/条件覆盖要求设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身的所有可能结果也至少出现一次。并且每个条件都显示能单独影响判定结果。
实验中对于路径测试有了更深的理解，可以更好、更迅速的去划分路径，设计测试用
例。通过实验，我对软件测试有了进一一步的认识和学习，对白盒测试流程有了较清楚的了解，收获很多。