软件测试基础7-8章

7.1软件静态测试

静态测试是软件测试中的一个术语，通常是指不执行程序代码而寻找代码中可能存在的错误或评估程序代码的过程。

静态测试主要包括各阶段的评审、代码检查、程序分析、软件质量度量等。

7.1.1各阶段评审

一般评审包括：培训评审、预备评审、同行评审，我们所关心的是同行评审。

7.1.2同行评审

同行评审一般包括审查、小组评审、走查、桌面评审、临时评审五种类型。

这些同行评审类型的区别在于正式程度：①审查时最正式，然后是小组评审、走查、桌面评审，临时评审最随意；②同行评审越正式，发现的缺陷越多，但评审越正式，花费成本越高；③被评审对象越重要或者风险越高，采用的评审方式就越正式。

7.2代码检查

代码检查是“白盒”测试的一种静态测试方法，是众多软件测试方法中发现软件缺陷最有效的方法之一。是以组为单位阅读代码，是一系列规程和错误检查技术的集合。

代码检查的内容有：

1.  完整性检查；

2.  一致性检查；

3.  正确性检查；

4.  可修改性检查；

5.  可预测性检查；

6.  健壮性检查；

7.  可理解性检查；

8.  可验证性检查；

9.  结构性检查；

10. 可追溯性检查；

7.2代码检查方法

代码检查一般采用静态“白盒”测试的方法，如代码审查、桌面检查、代码走查和技术评审。其中代码走查和代码审查是由若干个程序员和测试人员组成的一个小组，集体讨论。

代码审查

代码审查一般不少于4人，分别为组长、资深程序员、程序编写者与专职测试人员等，组长不能是被测程序的编写者。

代码审查由4个步骤组成：准备、程序阅读、审查会、编写报告

桌面检查

桌面检查就是程序员自己检查自己所编写的程序，根据相关的文档对源程序代码进行分析、检验，以发现程序中是否有错误的过程。桌面检查主要做的工作是：代码和设计是否一致；代码是否遵循标准、是否可读；代码逻辑表达是否正确；代码结构是否合理；程序编写与编写标准是否符合；程序中是否有不安全、不明确和模糊的部分；编程风格是否符合要求。

代码走查

代码走查和代码审查类似，代码审查是一种正式的评审活动，而代码走查的讨论过程是非正式的，代码走查比代码审查要更技术性些，在代码走查中编写代码的程序员要向5人小组或者其他程序员和测试人员组成的小组做正式陈述。

技术评审

技术评审是最正式的审查类型，具有高度的组织化，要求每一个参与者都接受训练。技术评审由开发组、测试组和相关人员（QA、产品经理等）联合进行。技术评审与走查和审查的不同之处在于表述代码的表述者。

7.3软件复杂性分析

软件危机产生的最直接原因是软件的复杂性已经远远超出人们对复杂性控制的能力。软件复杂性越高，软件隐含错误的概率越大，软件的可靠性、可维护性越差。软件可靠性问题的本质就是复杂性问题。当复杂性超过一定限度时，软件缺陷便急剧上升，甚至引发软件开发的失败。软件的可维护性跟复杂性也存在联系。软件的维护开销除与维护人员的素质等相关外，维护工作量是复杂性的一个指数函数，软件复杂度越高，维护起来越麻烦。

7.3.1软件复杂性度量方法

目前，人们已经研究出来许多度量的方法和标准，但主要分为两大类：面向对象的软件复杂性度量和面向过程的软件复杂性度量。其中著名的软件复杂性度量方法有Line Count语句行度量、基于FPA功能点分析的度量、Halstead软件科学度量法和McCabe结构复杂性度量。

面向对象复杂性度量方法有C&K方法、MOOD方法。

7.3.2软件复杂性度量元

规模度量元Line Count复杂度

方法：基于规模度量程序的复杂性，最简单的方法就是统计程序的源代码行数。

思想：统计一个程序模块的源代码行数目，并以源代码行数做为程序复杂性的度量。

范围：一般程序出错率的估算范围是从0.04％～7％之间，即每100行源程序中可能存在0.04～7个错误。

关系：每行代码的出错率与源程序行数之间不存在简单的线性关系，即若程序增大，出错率以非线性的方式增长。

难度度量元Halstead复杂度

Halstead是软件科学提出的第一个计算机软件的分析“定律”，用以研究计算机软件开发中的一些定量规律。

基本思想根据程序中可执行代码行的操作符和操作数的数量计算程序复杂性。

结构度量元McCabe复杂度

McCabe复杂度的基本思想是程序的复杂性很大程度上取决于程序控制流的复杂性，单一的程序顺序结构最简单，循环和选择所构成的环路越多，程序就越复杂。

1）McCabe圈复杂度

计算公式为：V(G)=m-n+p

G是强连通有向图

V(G)是强连通有向图G中的环数

m是G中的弧数

n是G中的节点数

p是G中分离部分的数目

对于一个正常的程序来说，程序图总是连通的，即p=1

其他计算方法：

圈复杂度等于程序图中判定节点的数目加1；

圈复杂度等于强连通程序图在平面上围成的区域的个数。

McCabe圈复杂度的应用：指出在实际测试中检测的最少基本路径的数目。McCabe圈复杂度反映模块复杂性、软件缺陷数和发现它们并改正它们所需的时间之间的关系。V(G)可用做最大模块复杂性的定量指标，大量研究表明，V(G)到10是最大上限，超过这个值会使测试变得更复杂，软件错误率增加。

 

                                  第八章

8.1动态测试

8.1.1“白盒”测试

“白盒”测试是一种典型测试方法，又称为结构测试或逻辑驱动测试是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的一种测试方法。

白盒测试技术分为静态白盒测试技术和动态白盒测试技术。静态测试不实际运行软件，主要是对软件的编程格式、结构等方面进行评估。而动态测试需要在Host环境或Target环境中实际运行软件，并使用设计的测试用例去探测软件缺陷。

静态白盒测试技术分为代码检查、编码标准和规范。

动态白盒测试技术分为路径覆盖测试、路径测试、数据流测试、信息流分析、覆盖率分析。

8.1.2逻辑覆盖

逻辑覆盖是以程序内部的逻辑结构为基础的测试方法，属于“白盒”测试。逻辑覆盖的种类大致分为：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合、路径覆盖。

8.1.3语句覆盖

语句覆盖是最起码的测试要求，使得每一条语句至少被执行一次，对程序的逻辑覆盖很少，只关心判定表达式的值，是很弱的逻辑覆盖标准。

语句覆盖优点：

①检查所有语句

②结构简单的代码的测试效果较好；

③容易实现自动测试；

④代码覆盖率高；

⑤如果是程序块覆盖，则不用考虑程序块中的源代码。

语句覆盖缺点：

①无法检查出条件语句错误；

②无法检查出逻辑运算错误；

③无法检查出循环语句错误。

8.1.4判定覆盖

要求设计足够的测试用例，使得程序中的每一个分支至少通过一次即每一条分支语句的“真”值和“假”值都至少执行一次。

判定覆盖优点：

①判定覆盖要比语句覆盖查错能力强一些；

②执行了分支覆盖，实际也就执行了语句覆盖。

判定覆盖缺点：

①不能查出条件语句错误；

②不能查出逻辑运算错误；

③不能查出循环次数错误；

④不能查出循环条件错误。

8.1.5条件覆盖

不仅每一个语句至少执行一次，使得判定中的每个条件获得各种可能的结果。判定覆盖只关心整个判定表达式的结果，条件覆盖关心的则是每个条件各种取值的结果。

条件覆盖优点：能够检查所有的条件错误

条件覆盖缺点：

①不能实现对每个分支的检查；

②用例数增加。

8.1.6判定/条件覆盖

设计足够多的测试用例，使得判定中每个条件的所有可能取值至少能够获取一次，同时每个判断的所有可能的判定结果至少执行一次。

判定/条件覆盖优点：

①既考虑了每一个条件，有考虑了每一个分支；

②发现错误的能力强于分支覆盖和条件覆盖。

判定/条件覆盖缺点：

①不能全面覆盖所有路径；

②用例数量的增加

8.1.7条件组合覆盖

要求设计足够多的测试用例，使得每个判定中条件的各种组合至少出现一次。满足条件组合覆盖标准的测试用例，也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准。

条件组合覆盖优点：能够检查所有的条件错误。

条件组合覆盖缺点：满足条件组合覆盖要求的测试用例不一定能使程序中的每条路径都执行到、

8.1.8路径覆盖

要求设计足够多的测试用例，使得程序中所有的路径都至少执行一次。

8.1.9各个覆盖之间的关系

 

 

 

 

 

 

 

 

 

 

 

 

 

8.2“黑盒”测试

“黑盒”测试又称功能测试或数据驱动测试，把测试对象当作看不见内部的黑盒，在完全不考虑程序内部结构和处理过程的情况下，测试者仅依据程序功能的需求规范考虑，确定测试用例和推断测试结果的正确性.站在使用软件或程序的角度，从输入数据与输出数据的对应关系进行的测试，在软件的接口处进行测试，通过导出执行程序所有功能需求的输入条件集，实现功能覆盖，需求覆盖。

黑盒”测试主要用到的方法有：等价类划分法、因果图方法、边界值分析法、猜错法、随机数法等，这些测试方法是从更广泛的角度来进行“黑盒”测试。

8.2.1等价类划分

等价类划分法是典型的“黑盒”测试方法，该方法设计测试用例时完全不必考虑软件结构，只需考虑需求规格说明书中的功能要求。等价类，把所有可能的输入数据,即程序的输入域划分成若干部分,划分，从每一部分中选取少数有代表性的数据做为测试用例，代表性数据等同于该类中的其他值。

有效等价类：对于程序规格说明来说，是合理的，有意义的输入数据构成的集合。无效等价类：对于程序规格说明来说，是不合理的，无意义的输入数据构成的集合。设计测试用例时，要同时考虑有效等价类和无效等价类设计。

8.2.2边界值分析

边界值分析是一种补充等价划分法的测试用例设计方法，不是选择等价类的任意元素，而是选择等价类边界的测试用例。边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法,稍高于其边界值及稍低于其边界值的一些特定情况，边界值分析方法，选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据的方法。

边界值分析原则

1）如果输入条件规定了值的范围，则应取刚达到这个范围的边界值，以及刚刚超越这个范围的边界值作为测试的输入数据。

2）如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为册数数据。

3）根据规格说明的每个输出条件，使用原则 1）。

4）如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。

5）分析规格说明，找出其他可能的边界条件。

8.2.3因果图

因果图是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，该方法充分考虑了输入情况的各种组合及输入条件之间的相互制约关系。因果图方法是一个非常有效的黑盒测试方法。它能够生成没有重复性的且发现错误能力强的测试用例。而且对输入、输出同时进行了分析。从因果图生成的测试用例包括了所有输入数据的取“真”与取“假”的情况。构成的测试用例数目达到最少。测试用例数目随输入数据数目的增加而线性地增加。如果哪个开发项目在设计阶段就采用了判定表，也就不必再画因果图。可以直接利用判定表设计测试用例了。

8.2.4随机测试

随机测试指测试输入数据是所有可能输入值中随机选取的，是一种基本的黑盒测试方法。随机选取用随机模拟的方法，包括用伪随机数发生器、硬件随机模拟器产生输入数据。这种方法能够获得大量的测试数据，测试人员只需规定输入变量的取值区间、在需要的时候提供必要的变换机制，使产生的随机数服从预期的概率分布。不能事先将测试的输入数据存入文档，在排错时无法重现测试中错误发生的过程，难以进行回归测试，补救的办法是将随机产生的测试数据记录备用。

8.2.5猜错法

猜错法是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。

猜错法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。

8.2.6探索性测试

探索性测试是一种测试思维技术。它没有很多实际的测试方法、技术和工具，但是却是所有测试人员都应该掌握的一种测试思维方式。

1.探索性测试定义

对探索性测试最直白的定义是：同时设计测试和执行测试。

2.探索性测试的基本过程

（1）识别软件系统的用途；

（2）识别软件系统提供的功能；

（3）识别软件系统潜在的不稳定的区域；

（4）在探索软件系统的过程中记录关于软件的信息和问题。

3.探索性测试的四个类型

探索式软件测试分为自由探索式测试、基于场景的探索式测试、基于策略的探索式测试、基于反馈的探索式测试。

8.3“灰盒”测试

8.3.1“灰盒”测试概念

灰盒”测试是一种综合测试法，它将“黑盒”测试、“白盒”测试、回归测试结合在一起，构成一种无缝测试技术。

1.灰盒”测试思想

“灰盒”测试是一种综合测试法，它将“黑盒”测试、“白盒”测试结合在一起，是基于程序运行时的外部表现同时又结合程序内部逻辑结构来设计用例，执行程序并采集程序路径执行信息和外部用户接口结果的测试技术。

灰盒测试以程序的主要功能和主要性能为测试依据，测试方法主要依据程序的程序图、功能说明书以及测试者的实践经验来设计。其目的是验证软件满足外部指标以及软件的所有通道或路径都进行了检验。通过该程序的所有路径都进行了检验和验证后，就得到了全面验证。

2.“灰盒”测试的优点

“灰盒”测试的优点：①能够进行基于需求的覆盖测试和基于程序路径覆盖的测试；②测试结果可以对应到程序内部路径，便于bug的定位、分析和解决；③能够保证设计的“黑盒”测试用例的完整性，防止遗漏软件的一些不常用的功能或功能组合；④能够需求或设计不详细或不完整对测试造成的影响。

3.“灰盒”测试的缺点

“灰盒”测试的缺点：①投入的时间比“黑盒”测试大概多20-40%的时间；②对测试人员的要求比“黑盒”测试高；③要求测试人员清楚系统内部由哪些模块构成，模块之间如何协作；④不如白盒测试深入；⑤不适用于简单的系统。

8.4测试用例设计

8.4.1测试用例设计概念

测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果，体现测试方案、方法、技术和策略。

1.高质量测试用例所应具备的特点

1)  正确性

2)  完整性

3)  准确

4)  清晰、简洁

5)  可维护性

6)   适应性

7)   可重用性

2.测试用例设计基本原则

1)   基于测试需求的原则

2)   基于测试方法的原则

3)   兼顾测试充分性和效率的原则

4)   测试用例的代表性

5)   测试结果的可判定性

6)   测试执行的可再现性原则

3.测试用例覆盖内容

1)   正确性测试。

2)   容错性测试。

3)   完整性测试。

4)   接口间测试。

5)   数据库测试

6)   边界值分析法。

7)   压力测试。

8)   等价划分。

9)   错误推测。

10)  效率。

11)  可理解性。

12)  可移植性。

13)  回归测试。

14)  比较测试。

其中（1）、（2）、（6）、（8）、（9）、（1）3为模块测试、组合测试、系统测试都涉及的并要重点进行测试；

单元测试测试要重点测试（5）；

组合测试重点进行接口间数据输入及逻辑的测试，即（4）；

系统测试重点测试（3）、（7）、（10）、（11）、（12）、（14）；

8.4.2测试用例编写要素与模板

1.测试用例编写要素

1)   名称和标识

2)   测试追踪

3)   用例说明

4)   测试的初始化要求

5)   测试的输入

6)   期望的测试结果

7)   评价测试结果的准则

8)   操作过程

9)   前提和约束

10)  测试终止条件

2.编写测试用例的注意事项

1)   功能检查

2)   面向用户的考虑

3)   数据处理

数据处理包括三方面对的内容：数据输入、数据处理以及数据输出。

1）软件流程测试

8.4.3测试用例分级

1.测试用例的级别

1)   第1级：基本

2)   第2级：重要

3)   第3级：一般

4)   第4级：特殊（如果没有，可以不使用该级别）

2.测试用例的优先级

优先级别分为高、中、低。优先级别越高越先执行。