软件测试技术课件：静态白盒测试

静态白盒测试静态测试静态测试不运行程序，测试非运行部分—检验和审查白盒测试访问代码，能够查看和审查静态白盒测试在不执行软件的条件下有条理地仔细审查软件的设计、体系结构和代码，从而找出软件缺陷的过程，有时也称为结构化分析进行静态白盒原因尽发现软件缺陷，以找出黑盒测试难以发现或隔离的软件缺陷，能让开发过程初期让测试小组集中精力过行软件设计的审查为黑盒测试员在接受软件测试时设计和应用测试用例提供思路正式审查

基本要素确定问题（审查的目的是找出软件问题）遵守规则（要遵守固定的规则）准备期间（发现问题）编写报告是寻找缺陷的第一步正式审查副作用

间接效果交流（学习的良机）质量（变得细心）小组同志化（了解对方）解决方案程序代码审查

代码审查的目标： 产生正确性、清晰性、规范性、一致性和高效性的合格代码代码审查的范围： 业务逻辑、算法效率、代码风格，编程规则代码审查的方法 互查（Peer-To-Peer）、走查（Walk-Through）、会议评审(Inspection）程序代码审查选择要审查的代码模块的准则：对于正确操作产品起关键作用的模块复杂度高的模块与过去发生错误率较高的模块功能类似的模块相对较新的或缺乏经验的软件工程师编写的模块在项目应用静态白盒测试会议评审组织一般五到七人主审员：协调本次审查并主持讨论责任人：负责被审查的产品讲解员：在审查会上讲解被审查的产品审查员：审查产品记录员：记录在审查会议上讨论的问题经理：责任人的管理者编码标准和规范有些代码虽然可以正常运行，编写不符合某种标准和规范。三个重要的原因：可靠性、可读性/维护性、移植性四部分组成：标题、标准、解释说明、示例例如：命名规则匈牙利命名规则非常简单，变数名以一个或者多个小写字母开始，这些字母表示变量的类型

iNum、cSex等

GNU命名规则文档名+主版本号+辅版本号+补丁编号

Foobar-1.2.3.src.tar.gz编程规则的审查

Java最基本语句的使用

Trycatchthrowsfinally线程中的异常重载函数的审查C++中的重载函数的审查，最好，不同返回类型用不同的函数名内存分配和管理内存及时释放和避免缓冲区溢出

程序性能审查 减少创建对象 减少循环体的执行代码 提高异常处理效率 减少IO操作通用代码审查清单一、数据引用错误。二、数据声明错误。三、计算错误。四、比较错误。五、控制流程错误。六、子程序参数错误。七、输入/输出错误。八、其他检查。一、数据引用错误定义：是指使用未经正确初始化用法和引用方式的变量、常量、数组、字符串或记录而导致的软件缺陷。

是否引用了未初始化的变量？查找遗漏之处与查找错误同等重要。数据引用错误数组和字符串的下标是整数值吗？下标总是在数组和字符串大小范围之内吗？在检索操作或者应用数组下标时是否包含“丢掉一个”这样的潜在错误？是否在应该使用常量的地方使用了变量－例如在检查数组范围时？变量是否被赋予不同类型的值？例如，无意中使代码为整形变量赋予一个浮点数值？为引用的指针分配内存了吗？一个数据结构是否在多个函数或者子程序中引用，在每一个引用中明确定义结构了吗？二、数据声明错误。

产生的原因：不正确地声明或使用变量和常量数据声明错误所有变量都赋予正确的长度、类型和存储类了吗？变量是否在声明的同时进行了初始化？是否正确初始化并与其类型一致？变量有类似的名称吗？这基本上不算软件缺陷，但有可能是程序中其他地方出现名称混淆的信息。存在声明过、但从未引用或者只引用过一次的变量吗？在特定模块中所有变量都显式声明了吗？如果没有，是否可以理解为该变量与更高级别的模块共享？三、计算错误

是基本的数据逻辑问题，计算无法得到预期结果。计算错误计算中是否使用了不同数据类型的变量，例如将整数与浮点数相加？计算中是否使用了不同数据类型相同但不同长度的变量－例如，将字节与字相加?计算时是否了解和考虑到编译器对类型或长度不一致的变量的转换规则？赋值的目的变量是否小于赋值表达式的值？在数值计算过程中是否可能出现溢出？除数/模是否可能为零？对于整型算术运算，某些计算，特别是除法的代码处理是否会丢失精度？变量的值是否超过有意义的范围？例如，可能性的计算结果是否小于0%或者大于100%？对于包含多个操作数的表达式，求值的次序是否混乱，运算优先级对吗？需要加括号使其清晰吗？四、比较错误小于、大于、等于、不等于、真、假。比较和判断错误很可能是边界条件问题。

比较得正确吗？虽然听起来简单，但是比较应该是小于还是小于或等于常常发生混淆。比较错误存在分数或者浮点值之间的比较吗？如果有，精度问题会影响比较吗？1.00000001和1.00000002极其接近，它们相等吗？每一个逻辑表达式都正确表达了吗？逻辑计算如期进行了吗？求值次序有疑问吗？逻辑表达式的操作数是逻辑值吗？例如，是否包含整数值的整型变量用于逻辑计算中？五、控制流程错误原因：编程语言中循环等控制结构未按预期方式工作。它们通常由计算或者比较错误直接或间接造成。控制流程错误

如果程序包含begin..end和do...while等语句组，end是否对应？程序、模块、子程序和循环能否终止？如果不能，可以接受吗？可能存在永远不停的循环吗？循环可能从不执行吗？如果是这样，可以接受吗？如果程序包含像switch...case语句这样的多个分支，索引变量能超出可能的分支数目吗？如果超出，该情况能正确处理吗？是否存在“丢掉一个”错误，导致意外进入循环？

六、子程序参数错误来源于软件子程序不正确地传递数据。

子程序参数错误子程序接收的参数类型和大小与调用代码发送的匹配吗？次序正确吗？如果子程序有多个入口点，引用的参数是否与当前入口点没有关联？常量是否当作形参传递，意外在子程序中改动？子程序是更改了仅作为输入值的参数？每一个参数的单位是否与相应的形参匹配。如果存在全局变量，在所有引用子程序中是否有相似的定义和属性？七、输入/输出错误包括文件读取、接受键盘或者鼠标输入以及向打印机或者屏幕等输出设备写入错误。

输入/输出错误软件是否严格遵守外部设备读写数据的专用格式？文件或者外设不存在或者未准备好的错误情况有处理吗？软件是否处理外部设备未连接、不可用，或者读写过程中存储空间占满等情况？软件以预期方式处理预计的错误吗？检查错误提示信息的准确性、正确性、语法或拼写了吗？

其他检查软件是否使用其他外语？是否处理扩展ASCII字符？是否需要用统一编码取代ASCII？软件是否要移植到其他编译器和CPU，具有这样做的许可吗？如果没有计划或者测试，那么，移植性可能成为一个大难题。是否考虑了兼容性，以使软件能够运行于不同数量的可用内存，不同的内部硬件，例如图形卡和显卡，不同的外设，例如打印机和调制解调器？程序编译是否产生“警告”或者“提示”信息？这些信息通常指示进行了有疑问的处理。纯粹主义者可能认为警告信息是不可接受的。静态白盒测试所面临的主要问题管理者会花的时间太多认为静态检查代码体现不出生产率所以不做或者虎头蛇尾静态测试工具FindBugs™-FindBugsinJavaProgramsC++test

总结静态白盒测试被证实是早期发现软件缺陷最有效的方法。但这是一项需要大量准备工作才能有成效的任务，但是许多研究表明花费的时间与得到的好处相比是值得的.动态白盒测试与单元测试回顾：静态白盒测试基本概念在不执行软件的条件下有条理地仔细审查软件的设计、体系结构和代码，从而找出软件缺陷的过程，有时也称为结构化分析原因

尽早发现软件错误;为黑盒测试人员提供建议方式：

正式审查：1.确定问题2.遵守规则3.准备期间4.编写报告方法：互查、走查、会议评审动态白盒测试检查代码并观察运行状况.利用查看代码（做什么）和实现方法(怎么做)得到的信息来确定哪些需要测试、哪些不要测试、如何开展测试又称为结构化测试(structraltesting)39不执行代码白盒测试发现缺陷不执行代码解决缺陷测试与调试明确概念调试动态白盒测试内容直接测试底层函数、过程、子程序和库。以完整程序的方式从顶层测试软件。但是根椐对软件运行的了解调整测试用例；从软件获得读取变量和状态信息的访问权，以便确定测试与预期结果是否相符，同时强制软件以正常难以实现的方式运行;估算执行测试时“命令”的代码量和具体代码，然后调整测试，去掉多余的测试用例，补充遗漏的用例.白盒测试期望达到的目的

所有独立路径至少都能测试一遍；所有逻辑判断都能测试True和False两条路径；所有循环结构都能测试到边界和循环域内的情况；确保内部数据结构的有效性。白盒测试主要方法3-1逻辑覆盖测试法

3-2基本路径测试法

3-3循环路径覆盖法3-1逻辑覆盖测试法

语句覆盖判定覆盖条件覆盖判定/条件覆盖条件组合覆盖路径覆盖逻辑覆盖测试法语句覆盖每条语句至少执行一次。判定覆盖每个判定的每个分支至少执行一次。条件覆盖每种条件下的语句都应该被执行。逻辑覆盖测试法判定/条件覆盖同时满足判定覆盖和条件覆盖条件组合覆盖每个判定中，各条件的每一种组合至少出现一次。路径覆盖程序中每一条可能的路径至少执行一次。46案例代码Line1:voidDoWork(intx,inty,intz)Line2:{Line3:

intk=0,j=0;Line4:if((x>3)&&(z<10))Line5:{Line6:

k=x*y-1;//语句块1Line7:

j=sqrt(k);Line8:}Line9:

if((x==4)||(y>5))Line10:{Line11:

j=x*y+10;//语句块2Line12:}Line13:

j=j%3;//语句块3Line14:}47辅助方法－流程图x>3&&z<10x==4||y>5入口

语句块1语句块2语句块3出口abcde

画出模块的流程图发现问题辅助设计测试用例48语句覆盖－设计用例测试用例输入为：{x=4、y=5、z=5}x>3&&z<10x==4||y>5入口

语句块1语句块2语句块3出口abcde程序执行的路径是：abd49分支/判定覆盖测试用例的输入为：{x=4、y=5、z=5}{x=2、y=5、z=5}x>3&&z<10x==4||y>5入口

语句块1语句块2语句块3出口abcde程序执行的路径是：abd程序执行的路径是：ace50条件覆盖－设计用例x>3&&z<10x==4||y>5入口

语句块1语句块2语句块3出口abcdeT1和－T1T2和－T2T3和－T3T4和－T451条件覆盖－设计用例测试用例的输入为：{x=4、y=6、z=5}{x=2、y=5、z=5}{x=4、y=5、z=15}x>3&&z<10x==4||y>5入口

语句块1语句块2语句块3出口abcde程序执行的路径是：abd程序执行的路径是：ace程序执行的路径是：acdx>3&&z<10x==4||y>5入口

语句块1语句块2语句块3出口abcde条件覆盖－设计用例测试用例通过路径条件取值覆盖分支x=4、y=6、z=5abdT1、T2、T3、T4bdx=2、y=5、z=5ace-T1、T2、-T3、-T4cex=4、y=5、z=15acdT1、-T2、T3、-T4cd52测试用例通过路径条件取值覆盖分支x=2、y=6、z=5acd-T1、T2、-T3、T4cdx=4、y=5、z=5acdT1、-T2、T3、-T4cd则可以设计测试用例如下：假如根据定义设计测试用例如下：判定－条件覆盖测试用例测试用例

通过路径

条件取值覆盖分支x=4、y=6、z=5abdT1、T2、T3、T4bdx=2、y=5、z=11ace-T1、-T2、-T3、-T4ce53

根据定义只需设计以下两个测试用例便可以覆盖8个条件值以及4个判断分支。54条件组合测试用例测试用例

通过路径

条件取值覆盖组合号x=4、y=6、z=5abdT1、T2、T3、T41和5x=4、y=5、z=15acdT1、-T2、T3、-T42和6x=2、y=6、z=5acd-T1、T2、-T3、T43和7x=2、y=5、z=15ace-T1、-T2、-T3、-T44和8丢失了一条路径abe55路径测试测试用例测试用例通过路径覆盖条件x=4、y=6、z=5abdT1、T2、T3、T4x=4、y=5、z=15acdT1、-T2、T3、-T4x=2、y=6、z=15ace-T1、-T2、-T3、-T4x=5、y=6、z=5abeT1、T2、-T3、-T4在上面的测试用例中修改一个测试用例则可对程序进行了全部的路径覆盖。

3-2基本路径测试法基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。571236784591110基本路径测试2-1路径测试路径是控制流程图中节点的顺序，始于入口节点，止于出口节点程序控制结构相应的流程图分支测试程序可能通过的路径是：路径1：1–11路径2：1–2–3–4–5–10–1–11路径3：1–2–3–6–8–9–10–1–11路径4：1–2–3–6–7–9–10–1–1158基本路径测试2-2计算路径数，以便可以测试软件流程图矩阵图14523cbaegfd节点连接到节点1154325432aefbgcd用链接权重替代交叉点值的字母，矩阵就可以成为评估测试中控制结构的有效工具替换后的矩阵图1和0表示连接存在，字母被替换为1循环路径覆盖法五种测试用例1）整个跳过循环

2）只有一次通过循环

3）两次通过循环

4）m此通过循环，m<循环最大次数

5）n-1,n,n+1次通过循环动态白盒测试步骤

1

分析模块函数；

2

在模块中找到相应的关键点（函数）；

3

根据第二点，画出模块程序流程图；

4

计算圈复杂度；

5

根据圈复杂度算出测试用例的最优个数；

6

根据路径测试法和圈复杂度写出具体测试用例；

7

进行测试。

练习publicbooleanmodule(intaValue,intbValue){ booleanflag=false; if(aValue>8&&bValue>9){ if((aValue*bValue)>150){ flag=true; }else{ flag=false; } }else{ if((aValue+bValue)>10){ flag=true; }else{ flag=false; } } returnflag; }将测试进行分段测试越早发生越好。代码分段构建和测试，最后合在一起形成更大的部分。单元集成系统用户验收测试阶段单元测试概念定义单元测试是对软件基本组成单元进行的测试时机在代码完成后由开发人员完成,QA人员辅助意义尽早发现错误，发现的越早成本越低12小时6小时3小时单元测试集成测试系统测试运行单元程序有时需要基于被测单元的接口，开发相应的驱动模块和桩模块。

驱动模块（drive）:对底层或子层模块进行测试所编写的调用这些模块的程序。桩模块（stub）：对顶层或上层模块进行测试时所编写的替代下层模块的程序。单元测试内容单元测试的步骤第一步:人工静态检查

这个阶段工作主要是保证代码算法的逻辑正确性(尽量通过人工检查发现代码的逻辑错误)、清晰性、规范性、一致性、算法高效性。并尽可能的发现程序中没有发现的错误。第二步:动态执行跟踪通过设计测试用例，执行待测程序来跟踪比较实际结果与预期结果来发现错误。

动态跟踪调试，是单元测试的重点与难点。人工静态检查1. 确定所编写的代码是否实现了模块或方法所要求的功能。2. 确定形式参数个数、数据类型、顺序是否正确;确定返回值类型及返回值的正确性。

3. 确定对输入参数有没有作正确性检查;

如果没有作正确性检查，确定该参数是否的确无需做参数正确性检查。