avatar

白盒测试

什么是白盒测试

定义:按照程序内部结构,逻辑驱动测试程序
目的:检测产品内部动作是否按照设计说明书的规范进行,检验程序的每条路径是否都能按照预定要求进行工作
对象:源程序
用代码内部的分支,路径,条件,使程序设计的控制结构导出测试用例

白盒测试方法分类

①、静态测试
②、动态测试

白盒测试的原则

①、保证一个模块中所有路径至少被测试一次
②、所有逻辑值都要测试真和假两种情况
③、检查程序内部的数据结构是否有效
④、检查上下边界及可操作范围内运行所有循环

白盒测试的类别

①、软件共用问题的测试
②、语言测试
③、sql语句测试
④、数据类型测试
⑤、界面测试
⑥、数值队形测试
⑦、业务对象测试
⑧、数据管理对象测试

白盒测试依据

①、软件需求报告
②、软件需求规格说明
③、程序设计文档
④、软件界面设计
⑤、编码规范
⑥、开发命名标准

白盒测试流程

①、界面对象测试流程
界面对象(UI)→业务对象(BO)→数据管理对象(DMO)→DBserver端
②、业务对象测试流程
DBserver端→数据管理对象(DMO)→业务对象(BO)→界面对象(UI)

白盒测试方法

①、尽量先用自动化工具来进行静态解析
②、建议先从静态测试开始(静态结构分析、代码走查、静态质量度量),然后进行动态测试(如覆盖率测试)
③、以静态分析结果作为依据,再使用代码检查和动态测试方法对静态分析结果进行进一步确认,提高测试效率及准确性
④、覆盖率测试是白盒测试的重要手段,在测试报告中可作为量化指标的依据,对于软件的重点模块,应使用多种覆盖率标准衡量代码的覆盖率

代码检查

概述:主要检查代码和流图设计的一致性、代码结构的合理性、代码编写的标准性、可读性、代码的逻辑表达的正确性等方面。包括变量检查、命名和类型审查、程序逻辑审查、
程序语法检查和程序结构检查等内容。

目的:

①、检查代码是否按照某种标准或规范编写的代码
②、检查代码以发现程序缺陷
③、通过检查代码容易发现程序产生的错误
④、通过检查代码来发现代码是不是流程图要求的;
⑤、通过检查代码来发现有没有遗漏的项目;
⑥、要代码易于移植,代码经常需要在不同的硬件中运行,或者使用不同的编译器编译;
⑦、要代码易于阅读、理解和维护。

方式:

①、桌面检查
②、走查
③、代码审查

项目:

①、目录文件组织
②、检查函数
③、数据类型及变量
④、检查条件判断语句
⑤、检查循环体制
⑥、检查代码注释
⑦、桌面检查

静态结构分析

定义:主要以图形的方式表现程序的内部结构(例如函数调用关系图、函数内部控制流图);通过应用程序各函数之间的调用关系展示了系统的结构,列出所有函数,用连线表示调用关系和作用。
主要分析:
①、可以检查函数的调用关系是否正确
②、是否存在孤立的函数而没有被调用
③、明确函数被调用的频繁度,对调用频繁的函数可以重点检查

SQL语句测试

主要检查以下两点:
①、语句检查
②、类型转换

代码检查的分析与评价

主要注意以下两点:
①、能力(陈述经代码检查证实了的本软件的能力)
②、缺陷和限制

白盒测试常用技术(7种)

逻辑覆盖法

测试覆盖率

用于确定测试所执行到的覆盖项的百分比;覆盖项指作为测试基础的一个入口或属性,比如语句、分支、条件等
测试覆盖率可表示出测试的充分性,在测试分析报告中可作为量化指标的依据,测试覆盖率越高效果越好。但覆盖率不是目标,只是一种手段。
测试覆盖率包括功能覆盖和结构覆盖:

逻辑覆盖

根据覆盖目标的不同和覆盖源程序语句的详尽程度,逻辑覆盖又可分为语句覆盖 、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖、修改条件判定覆盖、组合覆盖和路径覆盖。

面向对象的覆盖

面向对象的覆盖主要讨论继承上下文覆盖和基于状态的上下文覆盖。

测试覆盖准则

测试覆盖准则主要讨论(ESTCA)错误敏感测试用例分析和(LCSAJ)线性代码序列与跳转。
(1)ESTCA覆盖准则
(2)现行代码序列与跳转LCSAJ线性代码序列与条状LCSAJ是指一组顺序执行的代码,以控制流跳转为结束点。可产生4层覆盖

插桩技术

插桩测试是一个被广泛应用的测试方法。插桩测试就是向源程序中插入语句然后执行程序,通过打印语句,获得动态信息(我们最为关心的信息)

基本路径测试法

基本路径测试法是在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的
每个可执行语句至少执行一次。重点内容如下:
程序的控制流图:描述程序控制流的一种图示方法。
程序环形复杂度:McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数,这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。

程序控制流图

程序控制流图(可简称流图)是对程序流程图进行简化后得到的,它突出表示程序控
制流的结构。程序控制流图是描述程序控制流的一种方式。控制流图图形符号;
图形符号:圆圈代表一个结点, 表示一个或多个无分支的语句或源程序语句;
程序控制流边和点圈定的部分叫做区域。当对区域计数时,图形外的一个部分也应记为一个区域;
判断语句中的条件为复合条件时,即条件表达式由一个或多个逻辑运算符连接的逻辑表达式(a and b),则需要改变复合条件的判断为一系列只有单个条件的嵌套的判断。
基本路径测试方法是在控制流图的基础上,通过分析控制结构的环形复杂度,导出执行路径的基本集,再从该基本集设计测试用例。基本路径测试方法包括以下4个步骤:
3.1.1画出程序的控制流图。
3.1.2计算程序的环形复杂度,导出程序基本路径集中的独立路径条数,这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。
3.1.3导出基本路径集,确定程序的独立路径。
3.1.4根据③中的独立路径,设计测试用例的输入数据和预期输出。
• 程序环路复杂性计算方法(三种):
• (1)流图中区域的数量对应于环形复杂度
• (2)给定流图G的环形复杂度V(G),定义为V(G)=E-N+2, E是流图中边的数量,N是流图中节点的数量。
• (3) V(G)=P+1, P是流图G中的判定节点数。

域测试法

域测试是一种基于程序结构的测试方法,基于对程序输入空间(域)的分析,选择测试点进行测试。主要为:
4.1域错误:程序的控制流存在错误,对于某一特定的输入可能执行的是一条错误路径,这种错误称为路径错误,也叫做域错误;
4.2 计算型错误:对于特定输入执行的路径正确,但赋值语句的错误导致输出结果错误,称为计算型错误;
4.3丢失路径错误:由于程序中的某处少了一个判定谓词而引起的丢失路径错误

符号测试

符号测试基本思想是允许程序的输入不仅仅是具体的数值数据,而且包括符号值,符号值可以是基本的符号变量值,也可以是符号变量值的表达式
5.1符号测试执行的是代数运算,可以作为普通测试的一个扩充;
5.2符号测试可以看作是程序测试和程序验证的一个折衷办法;
5.3 符号测试程序中仅有有限的几条执行路径;

Z路径覆盖法

分析程序中的路径是指检验程序从入口开始,执行过程中经历的各个语句,直到出口。
Z路径覆盖对循环机制进行简化,减少路径的数量,使得覆盖所有路径成为可能,简化循环意义下的路径覆盖称为Z路径覆盖;
循环简化:限制循环次数,只考虑循环一次或零次情况;
循环简化的目的是限制循环的次数,无论循环的形式和循环体实际执行的次数,简化后的循环测试只考虑执行循环体一次和零次(不执行)两种情况,即考虑执行时进入循环体
一次和跳过循环体这两种情况。

程序变异测试法

程序变异是一种错误驱动测试。错误驱动测试是指该方法是针对某类特定程序错误的,要想找出程序中所有的错误几乎是不可能的,解决办法是将错误的搜索范围尽可能地缩小,
以利于专门测试某类错误是否存在。

白盒测试.png

白盒测试1.png
1或0(默认表达方式,Default)
1代表真 0代表假
Y或N
Y=Yes代表真 N=No代表假
T或F
T=True代表真 F=False代表假
4种原因与结果的关系
白盒测试2.png

4种原因与原因的约束
白盒测试1.png

E约束(排他性约束、Exclusive):C1和C2中最多有一个可能为1,即C1和C2不能同时为1

I约束(包含性约束, Inclusive):: C1、C2、C3中至少有一个必须是1,即: C1、C2、C3不能同时为0

O约束(唯一性约束, Only):C1和C2必须有一个且仅有一个为1

R约束(必要性约束, Request):: C1是1时,C2必须是1

M约束(强制约束,Masking)::唯一的针对结果的约束;若结果E1是1,则结果E2强制为0
判定表法Decision Table Method:
判定表是分析和表达多种输入条件下系统执行不同动作的工具,它可以把复杂的逻辑关系和多种条件组合的情况表达得既准确又明确。
一般情况下,我们在画出因果图后写出判定表,两者绑定使用。但是无论是因果图法也好,判定表法也好,它们两者都是可以单独使用的。
根据个人喜好,熟练了以后,可以考虑直接使用判定表法,省去画图步骤(Normally)。
因果图+判定表的经验结论

判定表法的优点:

1、充分考虑了输入条件间的组合,对组合情况覆盖充分;
2、最终每个用例覆盖多种输入情况,有利于提高测试效率;
3、设计过程中,对输入条件间的约束关系做了考虑,避免了无效用例,用例的有效性高;
4、能同时得出每个测试项的预期输出。

判定表法的缺点:

1、当被测试特性输入较多时,会造成判定表规格过于庞大;
2、输入之间的约束条件不能有效区分输入是否确实需要进行组合测试,会造成不需要组合测试的输入做了组合,从而产生用例冗余。

场景法

软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流
现在的场景法就是测试用例设计脑图,人称XMind

错误推测法

任何有意义的错误推测都值得单独写一条测试用例,一般情况下,推测开发需求中没有明确指明的,错误推测法很随意,就是个头脑风暴

语句覆盖(每一可执行语句至少执行一次。即执行判定为真的语句)

判定覆盖(程序中每个判断的取真分支和取假分支至少经历一次。即全真和全假的情况都执行一次)

条件覆盖(每个判断的每个条件的可能取值至少执行一次。即至少执行一次判断为真的情况,但不要求将所有判定为真的情况都写出来)
条件覆盖不一定包含判定覆盖。条件覆盖只能保证每个条件至少有一次为真,而不考虑所有的判定结果

判定/条件覆盖(判断中每个条件的所有可能取值至少执行一次,同时每个判定的可能结果也至少出现一次。即全真和全假两种情况)

条件组合覆盖(每个判断的所有可能的条件取值组合至少执行一次。)

路径覆盖(覆盖程序中所有可能的路径)

文章作者: guardianss
文章链接: https://guardianss.github.io/%E7%99%BD%E7%9B%92%E6%B5%8B%E8%AF%95.html
版权声明: 本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 Guardian
打赏
  • 微信
    微信
  • 支付寶
    支付寶

评论