软件测试(3)——白盒测试

白盒测试

白盒测试也称结构性测试、逻辑驱动测试、基于程序的测试

特点

– 将程序的执行表现与编码意图作比较
– 关心软件内部设计和程序实现
– 主要测试依据是代码和设计文档
– 支持严格定义、数学分析和精确度量
– 不验证需求规格,无法发现功能遗漏等问题

在这里插入图片描述

主要使用阶段
–单元测试阶段:一般由开发人员进行
–集成测试阶段:一般由测试人员和开发人员共同完成

白盒测试方法

静态测试

人工代码检查

  • 代码审查
    • 由3-5 人小组进行
    • 一个会议协调人,负责分发相关材料,记录错误等
    • 程序员一行一行解释程序
    • 小组成员提问
    • 通常审查小组有一个潜在错误的checklist以供审查
  • 代码走查
    • 充当计算机的角色,在一定的测试集下人工推演程序的执行
      在这里插入图片描述

软件度量

依据ISO/IEC 9126标准、国标、国军标,采取度量统计的方法能够分析程序的某些质量因素

  • McCabe度量法
    • 基于图论
    • V(G) = E-n+2p ,E为图G中的边数,n为节点数,P为连通分量个数。V(G)值过大,则程序不易理解与维护
  • Halstead度量法
    • 以程序中出现的操作符和操作数为计算对象,给出源程序后,根据这些参数,按公式可求得程序工作量的估值
    • 参数:
      • n1 程序中运算符出现的种类
      • N1 程序中运算符的总数
      • n2 程序中运算对象出现的种类
      • N2 程序中运算对象的总数
    • 公式:
      • 程序的长度: N = N1+ N2
      • 程序量: V =(N1 + N2)log2(n1 +n2 )
      • 语言抽象级别: L = (2 * n2)/(nl * N2)
      • 程序工作量: E = V/L

其它方法

  • 代码自动审查:通过程序抽象、有限状态机等技术,在不
    运行程序的情况下,发现其中的错误
  • 风格检查
    • 编码风格: 针对程序指令、运算符、代码结构、声明等方面制定规则并检查
    • 命名风格: 对程序中局部变量、全局变量、类等的命名制定规则并检查,以利于程序的理解、维护

动态测试

覆盖测试分析

衡量软件被测试执行的程度

在尽可能多地执行程序的路径,进行逻辑覆盖的同时,考察程序执行表现是否异常,尤其是某些复杂的和"正常"情况下不易执行的路径。

运行时错误检测

在程序中注入监控代码,监控程序运行,检测是否有错误发生

变异测试:一种检查测试集检错是否充分的方法

在程序中人为植入错误(变异算子,如删除语句、修改比较运算符、修改算术运算符、替换变量等),检查在给定测试集下,人为植入的错误是否能够被发现。
– 能够发现:测试集发现问题能够好
– 不能发现:测试集检错能力弱,应补充测试用例。

覆盖测试

逻辑覆盖方法

  1. 语句覆盖

    每条语句至少被执行一次(一个测试用例)

    问题:假分支没有得到检查

  2. 判定覆盖

    使程序中每个判定真假的分支至少执行一次

    问题:没有检查每个独立条件

  3. 条件覆盖

    每个判断中每个条件的真假可能取值均至少被取到一次

    条件覆盖不一定包含判定覆盖,判定覆盖也不一定包含条件覆盖

  4. 判定/条件覆盖

    在覆盖条件的同时,要求也覆盖判定(分支/边)

    问题:未考虑条件的组合情况

  5. 条件组合覆盖

    设计足够多的测试用例,使得每个判定中条件的各种可能组合都至少出现一次

    问题:指数级爆炸

  6. 修正条件/判定覆盖

    • 程序的每个入口和出口都必须执行一次
    • 程序中每个条件必须至少取到其所有可能值各一次
    • 判定中,每个条件应独立影响判定结果至少一次
  7. 路径覆盖

    设计足够多的测试用例,覆盖程序中的每条路径

    路径覆盖未必条件组合覆盖

    条件组合覆盖未必路径覆盖(比如循环)

  • 高覆盖未必找到更多错误,只是找到的可能性更大无论哪种覆盖方法,都无法绝对保证程序的正确性
  • 覆盖率不是目的,只是一种手段,不要追求绝对100%的覆盖率,且不可能针对所有的覆盖率去测试

路径测试

  • 基本路径测试

    • 在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出基本路径集合,从而设计测试用例的方法。

在这里插入图片描述

  • McCabe的基路径方法

    • 以程序控制流图中的线性独立环路为基
    • 线性独立环路:至少拥有一条以上其它线性独立路径中没有的边,从初始节点到终止节点的路径
    • 线性独立环路数的数量即程序控制流图的圈数量
    • 路径加法就是一条路径后接另一条路径,乘法对应于路径的重复,这样任何路径都可以由基本路径表达
    • 弱点
      • 假设测试基路径集合是充分的(实际未必)
      • 向量运算用于程序路径的表达上,没有真实物理意义

在这里插入图片描述

圈数计算

不增加从汇节点到源节点的边
– V(G) = e – n+2p = 10 – 7 + 2 = 5

增加汇节点->源节点边后
– V(G) = e – n+p = 11 – 7 + 1 = 5

可得到基

P1:A,B,C,G
P2:A,B,C,B,C,G
P3:A,B,E,F,G
P4:A,D,E,F,G
P5:A,D,F,G
  • 循环测试策略

    • 简单循环(循环最大次数n)
      • 跳过整个循环
      • 只循环一次
      • 循环两次
      • 循环m次,m<n
      • 分别循环n-1,n,n+1次
    • 嵌套循环
      • 从内层开始,所有外层的循环次数为最小,内层循环按简单循环策略
      • 或由内向外,外层仍取最小,内层取典型值

数据流测试

主要测试程序中的数值流(覆盖值传递路径),检测变量定义与使用的情况。

它比较容易发现下列类型的错误
–变量被定义,但是从来没有使用。
–所使用的变量没有被定义。
–变量在使用之前被定义两次。
–其它定义不当或使用不当的情况

def(x): 定义变量x 的节点的集合

use(x): 使用变量x 的节点的集合

du(s, x): 节点集,其中的每个节点s’满足s’属于use(x) ,且从s 到s’ 有一条路径,其上变量x没有被重新定值。

覆盖准则

  • 全定义(all-defs):对任一变量x,和它的任一定义点s属于def(x) ,测试执行至少包含到du(s, x) 中某个节点的一条路径
  • 全使用(all-uses):对任一变量x,和它的任一定义点s 属于def(x) ,测试执行至少包含到du(s,x)中每个节点的一条路径。
  • 全定义-使用路径(all-du-paths):对任一变量x,和它的任一定义点s 属于 def(x) ,测试执行包含到du(s,x)中每个节点的所有路径。

猜你喜欢

转载自blog.csdn.net/qq_21110935/article/details/84188888
今日推荐