zoukankan      html  css  js  c++  java
  • 控制流测试与条件测试

    控制流测试

    控制流测试(Control Flow Testing):是一种在考虑测试对象的控制流情况下导出测试用例的测试方法,并且借助于控制流图能评估测试的完整性(覆盖率)。

    原则

    • 控制流图是一个带有开始节点和结束节点的有向图
    • 程序的指令(语句)是通过节点来表示的
    • 一个不带分支和汇总的语句序列可以简单地用一个节点来表示
    • 语句之间的路径通过有向线(控制流)表示
    • 控制流图的开始和结束节点在实际应用中常常被省略

    测试活动

    1. 列出应该覆盖的路径
    2. 设计输入、输出使得程序能按逻辑含义走到此路径
    3. 运行测试来观察此路径是否走到。如果没有走到,则要么是对逻辑理解不足,要么是逻辑本身有错误。

    主要的控制流测试方法:

    • 语句覆盖
    • 分支覆盖
    • 判定覆盖
    • 路径覆盖(包括结构化的路径覆盖等)

    语句覆盖

    语句覆盖(C0-覆盖) / 语句覆盖测试 / 语句测试(Statement testing):在控制流中每条可执行的语句至少被执行一次!

    • 必要的、最简单的,但也是最弱的标准
    • 无法检测到缺失的语句
    • 但能发现无法执行到的语句(死代码)

    覆盖率:
    语句覆盖 = 已执行的语句数目 / 所有语句的总数目 * 100%

    语句即节点,控制流图内的所有节点都走到即为100%语句覆盖

    分支覆盖

    分支覆盖(C1-覆盖) / 分支覆盖测试 / 分支测试(Branch testing):在控制流图内的每一条边都至少被执行一次!

    • 在实践中作为最小的测试标准
    • 能发现无法执行到的程序分支
    • 无法发现缺失的分支
    • 没有测试到分支的组合

    覆盖率:
    分支覆盖 = 已执行的分支数目 / 分支总数目 * 100%

    每一条边即每一条控制流(有向线)都走过了,才为100%分支覆盖

    判定覆盖

    判定覆盖 / 判定测试(Decision testing):每一个可能的判定输出都应该被测试到!

    • 如果达到100%判定覆盖,则等价于分支覆盖
    • 但这里计数的不是分支,而是判定的输出,判定覆盖在小于100%时,判定的覆盖率与分支的覆盖率可能有所不同!

    覆盖率:
    判定覆盖 = 已执行的判定结果 / 所有的判定结果总数 * 100%

    判定覆盖计数的是判定的结果,即布尔值truefalse的个数

    示例代码:

    if (x > y) {
        y = x;
    }
    if (y > z) {
        z = y;
    }
    

    这段代码一共有两个if判定,每个判定都可以有truefalse两个判定结果,一共是四个判定结果。

    所以如果只用一条case同时覆盖x > yy > z,实际上执行到的是两个判定结果,判定覆盖率为2 / 4 = 50%

    在同一条case的情况下,画出控制流图,分支覆盖一共有9条有向线(包括开始节点和结束节点的两条有向线),有两条分支没有走到,所以分支覆盖率为7 / 9 = 77.8%

    路径覆盖

    路径覆盖(C-覆盖,C4-覆盖)/ 路径覆盖测试 / 路径测试(Path testing):在控制流图内的每一个分支序列(路径)都应该执行一次!

    强标准,因为

    • 在包含循环时,可能会有无数的路径
    • 在具有k个连续的分支时,则会有2k种不同的路径

    定制选择有意义的路径(Beizer)
    限制重复次数:循环覆盖测试方法
    限制考虑的路径:片段对覆盖(Segment pair)

    针对路径测试,按照Beizer的启发式方法[Beizer90]:

    • 从最简单的、功能上有意义的路径开始(从入口到出口的最简单路径)
    • 每次新的路径应该只是对现有的微小变化(如果可能,仅只改变一个判定输出/真值)
    • 优先考虑短的路径、简单路径、功能上有意义的路径、不带循环的路径
    • 应该达到100%判定覆盖
    • 避免功能上无意义的路径,如果为了达到判定覆盖必须执行这路径,则应该检查是否是一个错误,如果不是,则增加此路径。
    • 优先考虑那些很有可能是实际执行的路径

    从开始节点到结束节点之间全部可能的路径都走过才是100%路径覆盖

    • 部分路径测试经常用在安全关键软件的测试中
    • 常用条件覆盖方法组合使用,因为它们检查软件的另一个方面
    • 当只需要增加少量的测试用例时,它可以作为分支测试的深入
    • 应该使用工具来创建控制流图

    结构化的路径覆盖

    结构化的路径覆盖(Ci(k)-覆盖):执行在一个内循环中运行次数还没有超过k次的所有路径!

    对于k = 2时,这种方法也成为内部边界-路径覆盖(Boundary Interior)

    仅仅当k为很小值时才有实际意义。

    其他针对循环的测试的标准:

    • 最小和最大迭代次数,排除迭代数
    • 在程序中的循环一般:嵌套、交叉、非结构化的循环

    条件测试

    • 简单条件测试
    • 条件测试/判定测试 或 判定条件测试
    • 改进的条件/判定测试(MC/DC)
    • 复合条件测试

    它们的区别是测试的深度(从上往下越来越深入),需要的测试用例数,以及能发现多少缺陷

    简单条件测试

    简单条件测试(Condition testing:一个布尔表达式内的每个原子条件(Atomic condition) 都应该对其二个值(真/TRUE 和 假/FALSE)进行测试。

    一个原子条件是一个不包含逻辑运算符NOT、AND或OR的条件

    如果在程序内的所有条件都仅仅是一个原子条件,则相应的简单条件测试对应为判定测试。

    满足简单条件覆盖不一定会满足判定覆盖,所以简单条件测试仅仅是理论上进行探讨,没有太大实际意义

    条件测试/判定测试 或 判定条件测试

    **条件测试/判定测试(Decision condition testing):

    • 每一个判定都应该要对它的二个值(真和假)进行测试
    • 每个原子条件都应该要对它的二个值(真和假)进行测试

    包含了简单条件覆盖以及判定覆盖。通常不需要比简单条件覆盖更多的测试用例,但是必须谨慎选择。

    • 此方法适合于测试那些重要的,但还不是关键和核心的代码
    • 此方法与后面的二种方法相比需要较少的测试用例,但是比单纯的判定覆盖要更繁琐(还要看原子条件的覆盖)

    改进的条件/判定测试(MC/DC测试)

    改进的条件/判定测试(Modified Condition/Decision Coverage)

    • 每一个判定都应该要对它的二个真值(真和假)进行测试
    • 每一个原子条件都应该对它的二个真值(真和假)进行测试
    • 在测试中能够表明,每一个原子条件的值独立地影响表达式的结果

    针对单个的原子条件,必须关注具有不同结果的测试用例,结对进行比较。

    1. 先列出所有可能的真值组合
    2. 选出那些单个原子条件影响结果的测试用例对
    • 提供一个更高的控制流覆盖并能发现比条件覆盖/判定覆盖更多的缺陷
    • 需要更多的测试用例,但是:
      • 当有n个原子条件,通常需要n+1个测试用例。测试用例的数目与条件的数目是线性关系(线性增长)。
      • 很适合安全关键系统,例如,在航空和航天业广泛采用改进的条件测试/判定测出(MC/DC)方法

    限制:耦合的条件

    例如: (A AND B) OR ((NOT A) AND C)

    这些条件称作耦合(重叠),而这些耦合的项往往无法实现MC/DC测试。

    解决方法:

    • MC/DC仅仅针对不耦合的条件
    • 对于含有耦合条件的每个判定作为特例,视不同的情况生成测试用例

    限制:短路/精简的评判(Short-circuiting)

    在有条件的进行评价的程序设计语言中往往无法达到MC/DC的覆盖。

    解决方法:必须降低“测试用例对”的要求,对于每个原子条件生成一对测试用例,

    • 要覆盖这个条件的二个真值(真/假)
    • 要覆盖整个判定式的二个真值(真/假)
    • 所有其他原子条件具有相同的逻辑或不进行评估。

    复合条件测试

    复合条件测试(Multiple condition testing):测试原子条件的所有可能的真值(真/假)组合

    • 复合条件覆盖包含了MC/DC覆盖
    • 因为测试用例可以从真值表直接导出,所以测试的设计更为简单
    • 缺点:非常耗资(n个原子条件将会有2n个组合)
    • 长期需要稳定可靠的嵌入式系统测试中常会使用此方法(例如,在电话网内的交换机系统,按要求应该运行30年),但也逐渐被MC/DC所替代
  • 相关阅读:
    【乱侃】How do they look them ?
    【softeware】Messy code,some bug of Youdao notebook in EN win7
    【随谈】designing the login page of our project
    【web】Ad in security code, making good use of resource
    SQL数据库内存设置篇
    关系数据库的查询优化策略
    利用SQL未公开的存储过程实现分页
    sql语句总结
    sql中使用cmd命令注销登录用户
    SQLServer 分页存储过程
  • 原文地址:https://www.cnblogs.com/limuyuan/p/control-flow-testing-and-condition-testing.html
Copyright © 2011-2022 走看看