软件测试技术培训教材

软件测试技术

软件测试的目的

软件测试是以发现软件的缺陷为目的，使软件运行，将软件不运行所产生的危险性降低到允许的范围，是一个为发现错误而执行程序的过程。

软件的缺陷是对软件产品预期属性的偏离现象。包括对产品规格说明书（在我们部门多看到和听到的字眼是仕样书）的偏离；对客户/用户的期望的偏离，客户/用户的要求没有纳入软件产品中（可能是仕样书说明时的遗漏,也可能是软件实现的问题）。

定义软件缺陷的规则有以下5个：

1. 软件未达到仕样书标明的功能

2. 软件出现了仕样书指明不会出现的错误

3. 软件功能超出了仕样书指明的范围

4. 软件未达到仕样书虽未指出但应达到的目标

5. 软件测试人员认为软件难以理解、不易使用、运行速度缓

慢，或者最终用户认为不好

软件测试人员的要求

软件测试人员应具备的素质：

探索精神。软件测试人员不会害怕进入陌生环境，他们喜欢拿

到新软件，安装在自己机器上，观看结果。

故障排除能手。软件测试人员善于发现问题的症结，他们喜欢

猜谜。

不懈努力。软件测试人员总是不停尝试，他们可能会碰到转瞬

即逝或者难以重现的软件缺陷，他们不会心存侥幸，而是尽一

切可能去寻找。

创造性。测试显而易见的事实，那不是软件测试人员的工作，

他们的工作是想出富有创意甚至超常的手段来寻找软件缺陷。

追求完美。他们力求完美，但是知道某些无法企及时，不去苛

求，而是尽力接近目标。

判断准确。软件测试人员要决定测试内容、测试时间，以及看

到的问题是否算作真正的缺陷

老练稳重。软件测试人员不害怕坏消息。他们必须告诉程序

员，你的孩子（程序）很丑。优秀的测试人员知道怎样老练地

处理这些问题，和不够冷静的程序员怎样合作。

说服力。软件测试人员找出的软件缺陷有时被认为不重要，不

用修复。测试人员要善于表达观点，表明软件缺陷为何必须修

复，并通过实际演示力陈观点。

软件测试人员的一个基本素质是打破砂锅问到底。他们喜欢找出那些深藏不露的系统冲突。他们乐于处理最复杂的问题。他们热衷于来回奔忙，追求尽善尽美，为征服系统而额手称庆。这就是麻烦堆里地快乐。软件测试的一些概念

单体测试，集成测试，系统测试，回归测试，验收测试，差分测试和安装测试。

单体测试，是指对单个模块或者是一个函数等更小单位的测试，有时也被称为单元测试和模块测试。

集成测试，是指都多个模块组合起来，或者一个子系统的所有模块都结合起来后进行的测试，有时也被成为结合测试。

系统测试，是指整个系统的所有子系统都结合起来，即当前系统提交了所有功能以后进行的测试，也有的时候被成为功能测试。

回归测试，是指修复或调整好软件环境之后进行测试，即BUG修改后的确认测试。

验收测试，是指系统全部完成后，由客户确认系统或程序是否达到用户的需求的测试。

差分测试，是指当测试时间较短时（不足以进行一遍系统测试时），而只对整个系统中新变更或者新追加功能的相关部分的测试。

安装测试，确认用户系统的可安装性和可操作性。（安装测试，一般用于需要制作安装程序的项目）。

手动测试和自动化测试

手动测试，是指测试人员，根据仕样书、编写的测试大纲或者其他测试

文档，直接运行程序而完成的测试。

自动化测试，是指测试人员，使用自动测试工具、或者编写测试脚本，让程序自动运行而进行的测试。

白盒测试和黑盒测试

白盒测试，是一种按照程序内部的逻辑结构和编码结构设计并执行测试用例的测试方法。

黑盒测试，是一种从软件需求出发,根据软件需求规格说明设计测试用例,并按照测试用例的的要求运行被测程序的测试方法。CodingReview

是指对原代码的检查。主要依靠有经验的程序设计人员根据软件设计文档，通过阅读程序来发现软件错误和缺陷。

软件测试阶段与测试方法

下图说明了整个软件产品周期，测试活动所处的位置和介入的阶段。单体测试阶段

单体测试阶段有两个活动单体测试设计和单体测试。单体测试设计，以详细设计的第一个设计完成为切入点，根据详细设计进行单体测试设计，直到单体测试开始前完成。单体测试是以第一段可以测试的函数或者代码完成为切入点，根据单体测试设计的设计文档进行测试。单体测试，主要有3种方法：白盒测试、黑盒测试和Coding Review。

白盒测试

白盒测试是一种按照程序内部的逻辑结构和编码结构设计并执行测试用例的测试方法。主要包括命令覆盖度，即对程序中的条件句的所有命令至少被执行一次的选择测试方案的方法；分支覆盖度，即选择的TESTCASE应是在判断命令中的所有可能结果至少执行一次；路径覆盖度，即覆盖了从程序的入口到出口的全路径的方法。

以下将通过举例介绍几种单体测试中制作测试用例和选择测试数据的方法。

根据上面这段流程图(A,B,X都为整数)，我们可以找到有一个输入、两个条件判断语句、两个命令执行语句。注意要使用尽可能少的测试数据白盒测试所需要的测试用例进行覆盖(这个例子比较简单，实际测试中可能会碰到的程序要比这个复杂的得多)

1. 命令执行语句覆盖：程序中每一可执行语句至少执行一次。

选择 (A,B,X) = (2,0,3) 即通过a->c->e路径对两个命令执行语句进行执行测试

2. 分支覆盖：程序中每个判定的True分支和False分支至少执行一

次。

使用(A,B,X) = (2,0,3) 和 (A,B,X) = (1,0,1)分别覆盖分支a->c->e和a->b->d，完成对分支a、b、c、d和e的覆盖

或者使用(A,B,X) = (3,0,3) 和 (A,B,X) = (2,1,1)分别覆盖分支a->c->d和a->b->e，完成对分支a、b、c、d和e的覆盖

3. 条件覆盖：使程序的每个条件语句的True和False取值至少满足

一次

条件1 (1=A)

条件2 (0==B)T2(0==B) F2(0!=B)

条件3 (2==A) T3(2==A) F3(2!=A)

条件4 (1=X)

使用(A,B,X) = (2,0,3),覆盖条件(T1、T2、T3和T4)

使用(A,B,X) = (1,0,1),覆盖条件(F1、T2、F3和F4)

使用(A,B,X) = (2,1,1),覆盖条件(T1、F2、T3和F4)

对T1~T4和F1~F4进行覆盖

或者

使用(A,B,X) = (1,0,2),覆盖条件(F1、T2、F3和T4)

使用(A,B,X) = (2,1,1),覆盖条件(T1、F2、T3和F4)

对T1~T4和F1~F4进行覆盖

4. 路径覆盖，设计足够的测试用例，要求覆盖程序中所有的路径。

根据这段程序我们很容易能够分析到，该程序有4个路径:

Route1: a->c->e 选择测试用例(2,0,3)

Route2：a->b->d 选择测试用例(1,0,1)

Route3：a->b->e 选择测试用例(2,1,1)

Route4：a->c->d 选择测试用例(3,0,3)

这样我们根据以上4个方面的分析，可以选择出 (2,0,3)、(1,0,1)、

(3,0,3)、(2,1,1) 和(1,0,2)共五组测试数据覆盖上面提出的所有测试用例。这里要注意的是进行白盒测试时，我们不能使用穷举法对所有的条件和分支进行排列组合，比如对那4个条件进行排列组合，如果使用穷举法的话应该有42种情况。我们只要分析出程序的主要分支和条件，并对每个分支和条件使用尽可能少的测试用例进行覆盖就可以了。

我们在上面举出的例子只是包含了的条件判断，如果涉及到循环，要想清晰的分析出全部路径就比较困难了。

下面介绍一种针对有循环语句的流程图，进行路径测试的方法,这种方法又被称为基本路径测试。

首先要把流程图改成流图。

以下就是一个含有循环语句的流程图，假设流程图的菱形决定框中不包含复合条件

将上面的流程图映射到一个对应的流图，见下图。图中的每一个圆，称为流图的节点，代表一个或多个语句。一个处理矩形框序列或者一个菱形决定框可被映射为一个节点。流图中的箭头，称为边或者连接，代表控制流，类似于流程图中的箭头。一条边必须终止于一个节点，即使该节点并不代表任何语句。由边和节点限定的范围称为区域。计算区域时应包括图外部的范围。

下面在引入一个概念“独立路径”，独立路径是指程序中至少引进一个新的处理语句集合或者一个新条件的任一路径。即独立路径必须至少包含一条在定义该路径之前不曾用到的新边。而所有这些度量路径的集合，就是我们要进行路径覆盖测试所采用的测试用例集。

那么这个流图的一个独立路径集合为(由于每个人选择路径的方式可能不同，因此我这里只是为大家找到一个独立路径的集合)：路径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->11

注意,这里的每一条新的路径都包含了一条新边。

而路径1->2->3->4->5->10->1->2->3->6->8->9->10->1->11，对于上面4条来说不是独立路径，因为它只是已有路径的简单合并，并未包含任何新边。这样我们就得到了使用路径覆盖法，测试这段程序的所需的独立路径的集合，在选择符合这个集合的数据，就组成了测试用例集。

黑盒测试

黑盒测试，是一种从软件需求出发,根据软件需求规格说明设计测试用例,并按照测试用例的的要求运行被测程序的测试方法。主要根据等价类划分和边界值分析的方法建立测试用例。

等价类划分是将程序的输入域划分成有效和无效的数据类(又称作有效等价类和无效等价类)。接着做两件事情:

1． 设计一个测试用例，使其尽可能多的覆盖有效等价类。重复这一步，最终使得所有的有效等价类均被覆盖

2． 设计一个测试用例，使其只覆盖一个无效等价类。重复这一步，最终使所有的无效等价类均被覆盖

划分等价类时采用的方法

(1) 输入条件代表一个范围或者需要一个特定的值，则可以定义一

个有效等价类和两个无效等价类；

例：范围 “……数据项的个数的范围可以从1到

9999……”

有效等价类： 1<数据项的个数<9999

无效等价类： 数据项的个数<1

数据项的个数>9999

特定的值 “……学生选课允许选择2门至4门……”

有效等价类： 选课2门至4门

无效等价类： 只选1门课或者未选课

选课超过4门

(2) 输入条件代表集合的某个元素或者是该输入条件是布尔式的，

则可以定义一个有效等价类和一个无效等价类；

例：代表集合 “……统计中国各省、市、自治区人

口……”

有效等价类： 中国各省、市、自治区

无效等价类： 外国的省、市等

布尔式 “……该标识符必须以字母开头，……”

有效等价类： 以字母开头的字符串

无效等价类： 以非字母开头的字符串

(3) 如果确认已划分的等价类中各元素在程序中的处理方式是不同

的，则应将此等价类进一步划小。

边界值分析(Boundary Value Analysis)是一种补充等价划分的测试用例设计技术，它不是简单的选择等价类的任意元素，而是选择等价类边界的测试用例，它不仅注重输入条件，而且也从输出结果中到处测试用例。

边界值分析的方法

(1) 输入条件代表以α和β为边界的范围时，测试用例应当包含

α、β以及略大于α和略小于β的值

(2) 输入条件代表一组值，测试用例应当执行其中的最大值和最小

值，还应当执行略大于最小值和略小于最大值的值

(3) 如果程序数据结构有预定义的边界(比如要求数组有100项)，要

测试其边界的数据项

(4) 对于方法1和2，也要考虑输出条件，测试用例应当包括能够产

生最大和最小的输出值的数据

Coding Review

Coding Reivew，是指对原代码的检查。主要依靠有经验的程序设计人员根据软件设计文档，通过阅读程序来发现软件错误和缺陷。 代码审查的内容包括：检查代码和设计的一致性；检查代码的标准性，可读性；检查代码逻辑表达的正确性和完整性；检查代码结构的合理性。

代码审查不需要测试工具和设备，且具有一旦发现错误就能定位错误和一次发现一批错误等优点。应该注意的是，通常程序设计员对自己编写的程序有一种“好感”，因此他们在检查自己的程序时经常存在误区，无法检查出程序编写时的错误。因此代码的检查应该由他人检查而不是自己。

介绍几种常用的单体测试工具：

BoundChecker：用于边界检查的工具(部门经常使用)

Purify：用于内存检查的工具

Pure Coverage：用于路径检查的工具

集成测试阶段

集成测试阶段也包括测试设计和测试执行两个活动。

集成测试设计，以概要设计完成为切入点，根据概要设计进行集成测试设计，直到满足集成测试的条件时为止。

集成测试执行是从第一次开始进行模块结合开始。

集成测试阶段主要采用的测试方法是自顶向下法和自底向上法。

自顶向下法

自顶向下的集成策略通过下面5个步骤来实现：

1. 将主控模块作为测试驱动器，所有的稳定桩替换为隶属于主控模

块的模块

2. 根据集成的实现方法(深度优先或者广度优先)，下层的稳定桩一

次一个地被替换为真正的模块

3. 在每一个模块集成的时候都要进行测试

4. 在完成了每一次测试之后，又一个稳定桩被用真正的模块替换

5. 可以用回归测试来保证没有引进新的错误

自底向上法

自底向上的集成策略可以使用下列步骤来实现：

1. 低层模块组合成能够实现软件特定子功能的簇。

2. 写一个驱动程序(一个供测试用的控制程序)来协调测试用例的输

入输出

3. 对簇进行测试

4. 移走驱动程序，沿着程序结构的层次向上对簇进行组合

系统测试阶段

系统测试阶段也同样包括测试设计和测试执行两个活动。

系统测试设计，以需求分析完成为切入点，根据得到的准确的需求进行系统测试设计，直到满足系统测试的条件时为止。

系统测试执行是从整个系统的全部模块结合之后开始。

系统测试与集成测试和单体不同，系统测试是完全的黑盒测试，几乎不接触任何代码。

系统测试主要根据功能规格说明书(我们部门通常叫做仕样书)进行测试，其中如何时系统运行错误和进行有意图的错用是需要系统测试关心的一些问题。

测试人员站在开发者的角度进行测试是进行系统测试的一个盲点，正确的思想是始终以用户角度出发进行测试。

系统测试设计的步骤：

1． 经过对用户仕样书（VISIO图，Word文档，CANVAS图等）的仔细分析，制定测试大纲初稿，要求包含用户式样书的所有功能

点，这被我们称为功能识别。

当用户式样书上列出的项目足够清楚时，可直接按照用户式样书进行测试(一般不建议使用这样的方法，除非项目对质量要求不高，并且根据仕样书能够保证测试)。

如果测试大纲中很难描述的部分，在测试中也可以直接使用用户仕样书进行。例如画面数据有关部分，需要测试画面数据使用的颜色，画面中元素的所在位置，文字的字体等等。

2． 分析仕样书中每个功能点的细节，对应每个功能点考虑测试方法，并将测试方法填入测试大纲初稿。对应每个功能的测试方

法，都要将对应的确认内容(即预计的测试过程会出现的结果)

写入测试大纲。

仕样书中没有详细说明的部分，要根据仕样书的其他类似功能要求或者其他类似操作（或者以前的版本）来预计确认内容，也可以直接和项目负责人或者用户询问以确定确认内容。

对仕样书没有详细说明的功能点，如果实际测试中发现与预计测试结果不同，需要及时与项目负责人或用户勾通，以确定测试结果是否正确，以防止开发人员在设计时忽略该功能，如果原来的预计测试结果错误，需要即使修改测试大纲。

编写各功能模块的系统测试大纲时，要注意不要忽略和接口相关的功能点

3． 根据仕样书分析，仕样书中未写出的，但测试人员以用户角度出发而认为是合理的内容，也应在测试大纲中进行补充。

4． 制作测试用例集，根据测试大纲中的每个功能点的测试方法，选择测试数据，组成测试用例。不要求对每个功能点都编写测

试用例，对主要的功能点或者一些在实际测试中会有较大测试

难度的功能点，需要编写测试用例，将所有的测试用例组成测

试用例集

5． 性能测试方面的补充，把仕样书上要求的性能指标整理出来，作为当前项目的性能方面的要求，组成性能测试的测试大纲。

仕样书没有说明的性能指标的功能点，如何确定其性能指标呢？对于产品的性能，它有个基本的要求，就是一个产品的性能不能低于它的前一代产品的性能，就像现在导航项目一代一代的变更，某一代的产品的性能都不会低于它前一代的产品。

系统测试阶段，测试现象的描述就非常重要了，因为测试人员的测试，不是以测试出BUG为测试的目的，测试的最终目的是帮助开发人员更好的完成项目，因此对一些难再现的BUG要多进行测试并给出客观的再现机率，而对其他的BUG要给出详细的测试操作过程和再现机率（理论上考虑，每一个BUG在特定的测试条件下的再现机率应该是100%的）。测试操作过程，描述越详细越全面，开发人员进行的对BUG的修改越容易，因此要求测试人员在测试过程中，要对自己做过的操作有很好的记忆能力。错误现象相关的图片或者错误时的调试信息，死机时的堆栈，这些都是需要提供给开发人员的Bug相关信息，这些信息对开发人员分析错误都有很大的帮助。

测试工作结束

不论是开发人员还是测试人员，都很想尽早的得到这六个字，因为这表示他们的项目完成了，可以提交给用户了，也可以去领到属于自己的项目奖金了。

那么如何判断某个项目的测试是否可以完成呢？

一个模块的BUG出现了很多，不是指整个模块的测试已经结束，同样一个模块在测试中没有一个BUG就确定这个模块的测试结束也是错误的。在原则上，测试是没有结束这个概念的，如果能够影响它导致结束的唯一外界原因可能就是Money了，当一个项目没有测试资金投入时，这个项目测试就会结束了。

那么现在就有一个问题，我们正常测试过程中，如何判断的测试的力度和质量达到目标了呢？在整个测试过程中，发现BUG的数量和测试所花费的时间可以组成一条曲线，如果这条曲线能够较长的时间趋近与一个较低的值时，也就是说，这项测试即使再多投入新的人力和物力也不会影响这条曲线的趋势时，也就可以说现在的测试力度和质量差不多可以达标了。

如果是一个小项目的话（特别是对软件质量要求不十分高的项目），通过测试负责人和项目负责人共同讨论，这个项目的质量达到了项目负责人的要求也可以终止测试工作。

但是作为一个大项目，特别是象我们部门的量产项目(即开发的软件产

品会嵌入其他硬件产品作为商品出售的项目)，测试结束唯一的原因是开发人员和日方(特别是日方)不打算再对应测试出的问题了，这时也可以说项目的开发和维护都已经结束了。

那么每个测试阶段我们如何保证自己的测试的力度达到一定目标呢，在一个测试阶段的测试中要求所有测试大纲（如果有测试用例的话也包括测试用例）和仕样书的全部内容至少测试覆盖过一次，同时本阶段测试曲线也进入一个趋进平缓的趋势时，基本上可以说我们的测试力度达到一定目标了。

这里有另一种结束测试的情况，当进行测试时，如果短时间就会发现很高的BUG数，则需要及时通知相关开发负责人，要求停止当前的测试。因为当模块存在较大问题时，与此模块有关的测试需要暂时中断，否则反而浪费测试成本，同时要求对应开发人员及时整理设计和编码后重新提交版本进行测试。

测试经验

1． 不要“没有计划地随意”测试，以高负荷的测试来确认所做的程序，向末端任意输入测试数据。若完全没有计划，就会有重

复测试，从而浪费了时间。

2． “测试让初学者做测试吧”的想法是错误的，但这种情况通常是认为测试不十分重要。实际上执行程序本身也许是很简单的

工作，但即使是象判断三角形这样的简单程序也很难能够设计

出没有遗漏的测试用例。至少能设计程序的人员才能设计测试

用例，这是最低条件。对于一个不了解其制作方法的程序，要

发现它的错误必须有高于设计者的创造性才行。如果让初学者

做测试设计，最基本内容的检测还应由经验丰富的人员来做。

3． 因认为无关而被仍掉的测试记录中可能隐藏着许多错误，必须慎重地检查测试结果，并且将输出的结果要保存到最后，在必

要的时候可以查看。

4． 在进行系统测试时，要注意修改了一个错误以后，对这个修改所能影响的所有地方都要重新测试，以确保修改不会产生二次

BUG。

5． 发现了一个错误时，要考虑其他类似的场合会不会也会产生类似的错误。

6． 按照测试大纲（或测试用例）和仕样书进行测试后，还要以用户的角度进行增加可用性测试的力度，参考标准以从用户的角

度上认为应该正确的现象为标准，必要时需要和开发人员讨

论。

7． 制定一个详细的测试大纲的重要性。导航项目的特殊性，在于它与实际情况联系很紧密，操作比较自由，进行导航测试只根据用户仕样书是无法完成的，因此制作一个条目清楚的测试大纲对完成测试是相当重要的。

8． 测试中要经常采用逆向思维的方法，要有这样的想法即“这样做结果会怎样”，“那样做结果会怎样”、“不这样做会怎

样”……，正是我们进行这样或那样的设想，才能够填补手中测试大纲的不足,就有可能发现开发人员没有想到的的事情。比如程序中有一个打印设置的功能，如果需要打印可以选择某种打印机（你已经连接的打印机），可以设置打印模式等等，但是你是否在测试中考虑了，如果没有连接打印机会怎么办的话,你可以就会先删除打印机，然后按下打印设置的菜单，发现程序死机了。原来开发人员忽略了没有连接打印机的情况。

9． 缩小BUG再现的范围，一个明显的BUG开发人员可能很容易修改，但是有些BUG开发人员调查起来比较困难，但是如果我们分析BUG出现的过程，尽量将过程缩短提高再现率，就可以减轻开发人员的调查难度，提高BUG的修改效率。

如何缩小Bug再现的范围呢？大家可能都下过很多种棋类游戏，下棋的时候需要你计算下一步会怎么样，再下一步会怎么样，一个高手可能能够计算出几十步的变化或者更多。而测试恰好相反而且要简单的多，它需要你在测试中有清楚的思路，要尽可能的记住你进行过的操作步骤，也许原来你记住一个错误出现前的5步操作，开发人员调查这个错误需要8个小时，如果你记住一个错误出现前的10步操作，开发人员调查加上修改这个错误只需要1个小时就可以了，因为很多错误的产生是在几步操作之前的一步造成的或者更多步操作之前的一步造成的。

10． 拥有技术能力，不要认为测试工作就不需要懂得技术，你对这个软件产品的功能和接口越了解，在测试中抓住错误的可能性就越大。当你对这个软件的功能非常了解时，你会对一个现象和很清楚的辨别能力，一个很小的错误现象都会被你发现，不会被你错过，同时根据你对这个软件的功能的了解，也会帮助你分析出这个错误出现的原因（此时实际上你是在做一个系统分析人员的工作），同时这个能力也会帮助你这个错误的再现率。

11． 沟通能力也很重要，很多问题再现性很低并且表面上不很象一个Bug，如果你有较强的沟通能力，对再现性较低的问题开发

人员如果能够从你的口述中想到这个错误的原因，这样即使你无法再现这个Bug，开发人员也可以进行修改；对于表面上不

是很象错误的问题，并且仕样书可能也没有详细说明，经过你用严格的仕样和你对仕样的准确的理解，有可能你会使那个发人员去相信你说的，回去检查他的代码是否有错误，或者主动和项目负责人或者日方确认仕样。

例如你可以这么问开发人员，根据仕样，某个现象是不是应该是A现象，而不能是B现象之后又是C现象（其实这个C正是你发现的错误现象），当开发人员确定的认为你说得正确时，这时你就可以告诉开发人员，现在就出现这样一个“C”现象，这只不过是一个沟通技巧罢了。

最后希望我的培训，对大家以后需要进行的测试工作有帮助。