第七章软件测试报告.docx

第七章软件测试报告.docx

《第七章软件测试报告.docx》由会员分享，可在线阅读，更多相关《第七章软件测试报告.docx（19页珍藏版）》请在冰豆网上搜索。

第七章软件测试报告

第七章软件测试

编码完成之后，就是对源程序进行测试。

软件测试是一项“劳民伤财”的工作，统计表明，开发大规模的软件，有40%以上的精力是耗费在软件测试上（40-20-40规则，Myers认为软件测试占大约50%的项目时间和超过50%总成本）。

为了保证软件的正确可靠、为了防患于未然，无论怎样强调软件测试的重要性，都不过分。

关于软件测试，曾有种种似是而非的说法，众多的术语和测试技术，也常使我们眼花缭乱。

在这里我试尝给大家勾画出一个清晰的逻辑轮廓。

7.1基本概念

7.1.1软件测试的目的（与地位）

说测试不能不提到G.J.Myers的经典著作《软件测试技巧》，他在书中说道：

“测试是为了发现错误而执行程序的过程。

”

E.W.Dijkstra则说：

“程序测试能证明错误的存在，但不能证明错误不存在。

”

在这里，他们明确指出：

测试的目的是发现程序中的错误，是为了证明程序有错，而不是证明程序无错。

（其实你也证明不了）

在软件开发过程中，分析、设计、编码等工作都是建设性的，唯独测试带有“破坏性”，因为它抱着“吹毛求疵”的目的，明确宣布要在程序中“找岔子”。

他们认为这种吹毛求疵的态度是至关重要的（态度决定一切！

）。

如果你是为了证明程序无错而去进行测试，错误就可能在你的眼皮底下漏过，反之，只要你抱着证明程序有错的目的去测试，就会尽心尽力去找程序中的错误。

根据Myers的说法，测试又是一个“（在计算机上）执行程序的过程”。

分析和设计阶段都要对文档进行技术审查和管理复审，源程序完成后，也要进行代码复审（codereview）。

这些审查对减少软件错误有重要作用，但都不能代替在计算机上进行的测试，R.S.Pressman认为，测试可视为分析、设计、编码3个阶段的“最终复审（ultimatereview）”，可见测试在软件质量保证中的重要地位。

现在我们干脆把Myers的：

“程序测试是为了发现错误而执行程序的过程。

”作为软件测试的定义。

另一个与测试密切相关的活动叫纠错（debugging），我们也常常说起“纠错和调试”。

[纠错和调试]测试的目的是发现错误，纠错则是为了确定错误的性质，并且加以纠正。

因此，软件测试其实是这样一个过程：

测试——纠错——测试——纠错——…………,这种边测试边纠错的活动，常常借助于一种称为调试程序（debuggingroutine）的专用工具，所以也有人把纠错称为调试。

7.1.2软件测试的方法和技术

广义地说，软件测试不仅指在计算机上进行的测试（机器测试），也应包括用人工方式进行的代码复审（人工测试），下面我们列出这两类测试所采用的方法和技术。

[注]

（1）机器测试和人工测试

程序通过编译后，先要经代码复审，然后再进行机器测试。

机器测试是用设定的测试数据（testdata）执行被测程序的过程，故又称为动态测试（dynamictesting）。

代码复审采用人工的方式进行，目的在于检查程序的静态结构，找出编译不能发现的错误。

经验表明，组织良好的代码复审，可以发现程序中30%到70%的编码和逻辑错误，从而加快动态测试的进程，提高整个测试的效率。

根据Myers的研究：

人工测试和机器测试是互补的。

而且，机器测试只能发现错误的症状，人工测试一旦发现了错误，也就同时确定了错误的位置与性质。

人工测试并不是可有可无的，或是为了节约计算机机时而采取的权宜之计，它是机器测试的准备，也是测试中不可缺少的环节。

（2）白盒测试和黑盒测试

动态测试是一个包括：

①设计“测试用例”→②执行被测程序→③分析测试结果并发现错误的过程。

[测试用例]以发现程序的错误为目的，而精心设计的一组测试输入数据，以及用这组数据执行被测程序时所期望的输出结果。

测试用例＝{输入数据+期望结果}

【注】其中{}表示重复

在这一过程中，毫无疑问①设计“测试用例”是最关键！

这是因为只有合理设计的“测试用例”，才可能最大限度地发现程序中的错误，从而有效地完成测试任务。

我们按照在设计“测试用例”时，是否涉及程序的内部结构，把动态测试分为：

“白盒测试”和“黑盒测试”。

（3）穷举测试和选择测试

能不能通过动态测试，发现程序中的所有错误呢？

人们自然地想到：

应该让被测程序在一切可能的输入情况下执行一遍，这就是所谓的“穷举测试”。

那么穷举测试可能吗？

请看：

[试对一个“C++编译器”进行黑盒穷举测试]一方面要编写出所有能够想象出来的合法的C++程序让它编译，另一方面又要编写出一切不合法的C++程序，看它能否指出程序的错误。

显而易见，合法与不合法的C++程序的数量都是无穷的，因此，用黑盒测试方法进行穷举测试是不可能的。

[试对下图所示的程序进行白盒穷举测试]

[注]51+52+53+……+520≈1014=106亿=102万亿=100万亿这意味着若能每秒完成一次测试，也得用漫长的320万年才能完成这次测试任务。

由此可见，穷举测试是不实现的，这就是我们所说的测试不能保证程序无错的原因。

在实际测试中，我们只能选择一些有代表性的、典型的测试用例，对程序进行有限的测试，通常称这种测试为选择测试。

7.1.3软件测试的步骤

按照软件工程的观点。

软件测试依次由以下四个层次的测试组成：

（1）单元测试：

在编码阶段完成；以模块为单位，包括代码复审、动态测试；确定测试用例时，可综合运用白盒和黑盒两类测试技术；

（2）综合测试：

以软件的设计信息为依据，采纳一定的“测试策略”进行测试；主要用黑盒测试技术确定测试用例；

（3）确认测试：

以软件的需求信息为依据，采纳一定的“测试策略”进行测试；主要用黑盒测试技术确定测试用例；

（4）系统测试：

指整个计算机系统（包括软件与硬件）的测试，可与系统的安装和验收结合进行。

[注]1）各级测试均须事先制订测试计划，事后写出测试报告；

2）测试应由独立的测试小组进行，并挑选有经验的优秀程序员来担任；

3）图：

软件测试的步骤。

7.2代码复审

代码复审在程序通过编译之后，动态测试开始之前进行。

决不能以为程序通过编译就问题不大，其实编译只能发现极小部分错误，特别对大型软件更是如此。

7.2.1代码会审

代码会审以小组会的方式进行，会审小组一般由3到4人组成，包括组长一人、程序作者一人。

会前要先把源程序清单分发给与会者，还应把复审的要点编成“错误检验表”，供与会者参考。

***程序错误检验表

数据引用错误

例如使用未赋过值或未初始化的变量

数据说明错误

例如变量类型与初始化的值不符，变量未说明

数据计算错误

例如混合类型运算，用零作除数

数据比较错误

例如在不同类型的变量间作比较

控制流程错误

例如多做或少做了循环，子程序等最后未终止

接口错误

例如实参和形参类型、顺序或数量不符

输入输出错误

例如忘记打开或关闭文件，I/O出错处理不对

…………

…………

开会时，程序作者逐句朗读和讲解程序，其它人则集中精力，捕捉程序在结构、功能、与编码风格等方面的可能错误。

要注意的是：

大家都要把精力集中于发现错误，而把改正错误的工作放到会后去做。

如果错误较多，或有的错误要作重大改正，应在改正后重新安排代码会审。

7.2.2走查

走查与代码会审相似，所不同的是：

走查要求与会者扮演“计算机”的角色，用人工的方式来运行被审程序。

因此，在会前至少要指定一人提出“测试用例”，开会时把这些测试数据“输入”被测程序，并在纸上跟踪监视程序的执行情况，让人代替机器沿着程序的逻辑“走”一遍，并从中“查”出错误，这就是“走查”这一名称的由来。

走查实质上是以走查为方式，随着走查的进程不断向程序作者提出有关询问，并从中发现程序的错误。

7.2.3办公桌检查

办公桌检查可以看成是由一个人参加的代码会审，其内容可以是按照“错误检查表”来检查被审的程序，也可以仿照“走查”对程序进行运行。

只适合规模较小的软件。

7.3测试用例的设计

测试用例是以发现程序的错误为目的，而精心设计的一组测试输入数据，以及用这组数据执行被测程序时所期望的输出结果。

测试用例＝{输入数据+期望结果}

其中{}表示重复。

这个式子表明，每一个完整的测试用例不仅含有被测程序的输入数据，而且还包括用这组数据执行被测程序后期望的输出结果，如果实测的结果与期望的结果不相符，就表明程序可能存在错误。

下图列出了常用的测试用例设计方法。

7.3.1黑盒测试方法

前面已经提到，黑盒测试方法仅以程序的外部功能为依据来设计测试用例，一方面要检查程序能否完成一切应做的事情，另一方面要检查程序能否拒绝一切不应该做的事情。

（1）等价分类法

这种方法就是把被测程序的输入域（就是整个键盘）进行

分类——划分为若干个“等价类”。

[注]1）集合X上的等价关系R所构成的等价类形成一个集合X的划分，此划分叫做X关于R的商集，记作X/R。

X/R={[a]R|a∈X}

2）集合X上的等价关系与集合X的划分是一一对应的。

从逻辑上来说，就是按测试结果“等价”把被测程序的输入域划分为若干个等价类，每一个等价类都选择一例“测试用例”，它代表了一类与它等价的其它测试。

这样，测试人员就有可能使用少量“有代表性”的测试用例，对程序进行“有限的测试”。

我们再次强调：

黑盒测试方法一方面要检查程序能否完成一切应做的事情，另一方面要检查程序能否拒绝一切不应该做的事情。

与“应做的事情”相对应的是“有效等价类”，而与“不应该做的事情”相对应的称之为“无效等价类”。

设计等价类的测试用例分为两步：

1划分等价类并给出定义；

2选择测试用例，其原则是：

有效等价类的测试用例尽量公用；无效等价类必须每类一例。

[例1]某城市的电话号码由3部分组成，这3部分的名称和内容分别是：

地区码：

空白或3位数字；

前缀：

非“0”或“1”开头的3位数字；

后缀：

4位数字。

假定被测程序能接受一切符合上述规定的电话号码，拒绝所有不符合上述规定的电话号码，请用等价分类法来设计它的测试用例。

（2）边界值分析法（边值法）

在等价分类法中，代表一个等价类的测试用例可以在这个

等价类的允许值范围内任意选择。

但如果把测试用例选在等价类的边值上，往往会有更好的效果，这就是边界值分析法的主要思想。

[例]税款计算程序。

（“收入”≤3500作为判定条件，可用800、3600两个测试数据分别代表免税和征税两个等价类，但……）

大多数情况下，边界值及其邻近的数据都属于敏感区，容易暴露程序的错误。

边界值分析法也适用于检查程序的输出值边界。

[例]当月实发工资计算程序

（如果该工资计算程序规定：

当职工的扣款金额超过当月应发工资的一半时，其超出部分应留待下月扣除，如果按边界值分析法选择此时的测试用例，就应有意识地让扣款达到或超过应发工资额的半数，分别观察被测程序计算当月实发工资有何变化）

（3）错误猜测法（猜错法）

所谓猜错，就是猜测被测程序中哪些地方容易出错，并据

此设计测试用例。

这种方法更多地依赖于测试人员的直觉与经验，所以仅是一种辅助手段，用来补充一些测试用例。

注：

等价分类法的一个缺陷是未对输入条件的组合进行分析。

（4）因果图法

因果图法是借助图形来设计测试用例的一种方法。

所谓的

因果图是一种简化了的逻辑图，能直观地表明输入条件（因）和输出结果（果）之间的相互关系。

该方法适用于被测程序具有多种输入条件，程序的输出又依赖于输入条件的各种组合的情况，往往要借助专用软件来设计测试用例。

7.3.2白盒测试方法

白盒测试方法是以程序的内部逻辑结构为依据来设计测试用例。

我们知道穷举测试是不现实的，合理的白盒测试，就是要选取足够的测试用例，以实现对源程序比较充分的覆盖，以便尽可能多地发现程序中的错误。

（1）逻辑覆盖法

逻辑覆盖其实是对程序（逻辑）覆盖（程度）要求的一组

总称，按照对程序逻辑覆盖程度的由低到高顺序，它们是：

1）语句覆盖：

要求被测程序的每条语句至少执行一次；

2）判定覆盖：

不仅要求被测程序的每条语句至少执行一次，

而且要求每一分支至少执行一次；

3）条件覆盖：

不仅要求被测程序的每条语句至少执行一次，

而且要求判定中的每个条件均按“真”、“假”两种结果至少执行一次；

4）条件组合覆盖：

不仅要求被测程序的每条语句至少执行一

次，而且要求判定中的每个条件的所有可能组合都至少执行一次。

[例2]如图显示了某程序的逻辑结构，试为它设计足够的测试用例，分别实现对程序的①判定覆盖；②条件覆盖；和③条件组合覆盖。

[例3]设计下列伪代码程序的“判定覆盖”和“条件组合覆盖”的测试用例。

START

INPUT（A，B，C，D）

IF（A＞0）AND（B＞0）

THENX=A+B

ELSEX=A-B

ENDIF

IF（C＞A）OR（D＜B）

THENY=C-D

ELSEY=C+D

ENDIF

PRINT（X,Y）

END

（2）路径覆盖法

路径测试法是借助程序图设计测试用例的一种白盒方法。

在逻辑覆盖法中，测试用例可基于流程图来设计的，对于结构复杂的程序（模块），其流程图也很复杂，设计时难免顾此失彼，发生错漏。

而程序图是一种简化了的流程图，但它保持了控制流的全部轨迹，包括了所有的判定结点，用它来设计测试用例更为简洁。

与逻辑覆盖法类似，路径覆盖也是对程序（逻辑）覆盖（程度）要求的一组总称，按照由低到高对程序逻辑覆盖程度的顺序，它们是：

1）结点覆盖：

程序的测试路径至少经过程序图中的每个结点

一次；（相当于逻辑覆盖中的语句覆盖）

2）边覆盖：

程序的测试路径至少经过程序图中的每条边

一次；（相当于逻辑覆盖中的判定覆盖）

3）路径覆盖：

程序的测试路径至少经过程序图中的每条路径

一次；（不需要考虑程序的循环，只要求每条路径至少经过一次）

[注]1）路径覆盖考虑的是整个路径，逻辑覆盖着眼于每个单独的判定结点；

2）把路径覆盖和条件组合覆盖结合起来，可以实现查错能力最强的白盒测试；

3）测试简单的程序，同时满足“结点覆盖”和“边覆盖”是最低的覆盖要求。

[例3]如图是某程序的程序图，若要分别实现对程序的①结点覆

盖；②边覆盖；和③路径覆盖。

请分别列出它们的执行路径。

[注]1）目前，面向对象软件的“测试用例”的设计方法，还处于研究、发展阶段，一般来说面向对象测试关注的是“设计适当的操作序列”检查类的状态。

2）大型通用软件，在正式发布前，通常需要执行Alpha和Beta测试，目的是从实际终端用户的使用角度，对软件的功能和性能进行测试，以发现可能只有最终用户才能发现的错误。

α测试是指软件开发公司组织内部人员模拟各类用户对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。

α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作，并尽最大努力涵盖所有可能的用户操作方式。

经过α测试调整的软件产品称为β版本。

β测试是由软件的多个用户在实际使用环境下进行的测试，这些用户返回有关错误信息给开发者。

测试时，开发者通常不在测试现场。

因而，β测试是在开发者无法控制的环境下进行的软件现场应用。

在β测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告。

β测试主要衡量产品的FLURPS（即功能、局域化、可使用性、可靠性、性能和支持），着重于产品的支持性，包括文档，客户培训和支持产品生产能力。

只有当α测试达到一定的可靠程度时，才能开始β测试。

它处在整个测试的最后阶段。

同时，产品的所有手册文本也应该在此阶段完全定稿。

7.3.3测试用例设计策略

以上介绍的测试用例设计方法如果把它们单独使用，没有一种足以产生一组完善的测试用例。

所以在实际工作中，总是把它们结合起来使用，以满足不同测试阶段和不同程序的需要。

在综合测试阶段及其后的测试阶段，除去很小的程序，都采用黑盒方法，其策略是：

1）用等价分类法和（或）边界值分析法提出基本的测试用例；

2）用猜错法补充新的测试用例；

3）如果在程序的功能说明中含有输入条件的组合，宜在一开始就用因果图法，然后再按以上1）、2）两步进行。

单元测试的策略稍有不同，因为可以直接参考模块的源程序，所以单元测试的策略，总是把白盒方法与黑盒方法结合运用，具体的作法又有两种：

（1）先按上述步骤用黑盒方法提出一组基本的测试用例，然后用白盒方法作验证。

如果发现用黑盒方法产生的测试用例未能满足所需的覆盖标准，就用白盒方法增补新的测试用例来满足它们。

（2）先用白盒方法提出一组测试用例，然后根据模块的功能说明用黑盒方法进行补充。

一般情况下，单元测试应该以白盒方法为主。

这就是说不管你是

如何提出一组基本的测试用例的，都要用白盒方法作过验证。

[例4]如图是某三角形判断程序的流程图和程序图，这个程序的

功能是：

读入代表三角形边长的3个正整数，判断它们能否组成三

角形；如果能组成三角形，则显示三角形是等边、等腰或任意三

角形的信息；如果不能组成三角形，则显示“不是三角形”的信

息。

请为该程序设计足够的测试用例。

（用等价分类法设计它的测

试用例,并用白盒方法中的路径测试法进行验证，使其同时满足“结

点覆盖”和“边覆盖”的最低覆盖要求。

）

[解]先用黑盒方法设计测试用例，然后用白盒方法进行检验与补

充。

第一步：

运用等价分类法划分与定义等价类，然后用边界值

分析法和猜错法补充。

其结果如下表1所示。

表1：

三角形判断程序的等价类划分

有效等价类无效等价类

任何2数之和大于第3数：

3数相等⑴少于3个正整数⑼

3数中有2数相等：

含有非正整数⑽

A、B相等⑵含有非数字字符⑾

A、C相等⑶含有零数据

B、C相等⑷A=0（12）

3数均不相等⑸B=0（13）

2数之和不大于第3数：

C=0（14）

最大数为A⑹含有负整数

最大数为B⑺A是负整数（15）

最大数为C⑻B是负整数（16）

C是负整数（17）

边值法：

2数之和等于第3数：

A+B=C（18）

A+C=B（19）

B+C=A（20）

猜错法：

输入3个零（21）；输入3个负数（22）。

第二步：

选择测试用例，得出22个基本的测试用例，如下表2所示。

表2：

三角形判断程序的测试用例

测试数据测试范围期望结果

ABC

555等价类⑴等边三角形

445等价类⑵等腰三角形

544等价类⑶等腰三角形

454等价类⑷等腰三角形

345等价类⑸任意三角形

944等价类⑹非三角形

494等价类⑺非三角形

449等价类⑻非三角形

34等价类⑼无效

2．345等价类⑽无效

A56等价类⑾无效

045等价类⑿无效

205等价类（13）无效

340等价类（14）无效

-345等价类（15）无效

3-45等价类（16）无效

34-5等价类（17）无效

5510等价类（18）非三角形

5105等价类（19）非三角形

1055等价类（20）非三角形

000等价类（21）无效

-3-4-5等价类（22）无效

第三步：

用白盒方法检验第二步产生的测试用例，请见下表3。

表3：

测试数据覆盖的结点和边

测试数据覆盖结点覆盖的边

ABC

555S，1，2，3，4，5，6，ES123456E

445S，1，2，3，4，5，9，ES123459E

544S，1，2，3，4，8，10，9，ES12348109E

454S，1，2，3，4，8，9，ES123489E

345S，1，2，3，4，8，10，11，ES123481011E

944S，1，12，ES112E

494S，1，2，ES12E

449S，1，3，12，ES12312E

结果表明，只须使用22个测试用例中的前8个就能满足对程序图的结点覆盖和边覆盖，因此用黑盒方法设计的测试用例已经足够，不必再补充新的测试用例。