软件工程课件：软件实现

软件实现5.1软件编码5.2软件测试基础5.3测试设计和管理5.4软件测试过程5.5软件测5.6软件测试策略5.7白盒测试5.8黑盒测试5.9回归测试5.10软件调试5.11小结习题5

知识点

软件编码，软件测试基础，软件测试过程，软件测试的基本方法，测试策略，黑盒与白盒测试，回归测试与调试。

难点

软件测试的策略，白盒测试和黑盒测试技术，测试用例的设计。

基于工作过程的教学任务

通过本章的学习，了解如何选择程序设计语言，培养良好的编码风格，熟悉理解选择良好的程序设计途径的重要性；掌握软件测试的目标、准则、方法和步骤，掌握单元测试、集成测试、确认测试的方法步骤；掌握白盒测试和黑盒测试技术的概念、方法以及方案的设计，能够熟练按照测试的原则和技术，分析确定高效的测试用例；掌握软件调试的概念和策略，了解自动测试工具和调试工具。掌握测试即找错、调试即纠错的核心概念。

5.1软件编码

软件经过结构化设计后进入程序编码阶段，编码即编程序。程序的质量基本上取决于软件设计的质量。编码使用的语言和程序的布局风格对程序质量有相当大的影响。

程序内部的良好文档资料，有规律的数据说明格式，简单清晰的语句构造和输入输出格式等，可以提高程序的可读性，改进程序的可维护性。

5.1.1编码目的

软件编码的目的就是实现人和计算机的通信，指挥计算机按照人的意志正常工作，把模块的过程描述翻译成用语言书写的源程序。源程序应该正确可靠、简明清晰，而且具有较高的效率。

软件工程项目对代码编写的要求，不仅仅是源代码语法上的正确性，也不只是源程序中没有各种错误，还要求源代码具有良好的结构性和良好的程序设计风格。

如果人们写出的源程序既便于阅读，又便于测试和排除所发现的程序故障，就能够有效地在开发期间消除绝大多数在程序中隐藏的错误，使得程序可以做到正常稳定的运行，极大地减少运行期间软件失效的可能性，大大提高软件的可靠性。

如果写出的源程序在运行过程中发现了问题或错误时容易修改，而且当软件在使用过程中，能根据用户需要很容易扩充其功能及改善其性能，这样的程序就具有较好的可维护性。维护人员可以很方便地对它进行修改、扩充和移植。

尽管软件的质量更多地依赖于软件设计，但是，程序设计语言的特性和编码途径等，也会对程序的可靠性、可读性、可测试性和可维护性产生影响。

5.1.2程序设计语言的选择

虽然好的程序设计语言有助于写出可靠而又容易维护的程序。但是，事在人为，工具再好，使用不当也不会达到预期的效果。按照软件工程方法论，程序是软件设计的自然结果，程序的质量基本上取决于设计的质量。此外，编写程序的途径和编程经验也很大程度上决定着程序的质量。

现在，软件公司使用面向对象的语言，不管是哪一种面向对象语言，开发新的软件都会承受压力。随之产生的问题是：哪种面向对象语言比较合适？今天，最广泛应用的面向对象编程语言是C++和Java。

C++流行的真正原因是它与C具有明显的相似性，因此，很多管理者把C++看作C的一个扩展集，从而得出任何了解C的程序员都能够迅速地掌握额外部分的结论。但是，只有在采用了面向对象技术，而且产品是由对象和类而不是函数来组织的时候，C++的使用才有意义。

因此，在采用C++之前，相关软件专业人员经过面向对象范型方面的培训是非常重要的。当企业对从C转换到C++带来的结果感到失望时，一个主要的原因是相关人员缺乏面向对象范型的培训。

如果软件企业决定采用Java，从传统的结构化范型转变到面向对象范型是不可能的。Java是纯面向对象程序语言，不支持传统的结构化范型的函数和过程。不像C++这样的混合面向对象语言，Java程序员从一开始就必须使用面向对象范型(而且只能使用面向对象范型)。由于需要从一个范型转到另一个范型，与转变到像C++这种混合型的面向对象语言相比，采用Java所需的教育和培训就显得更为重要。

决定了实现语言之后，下面的问题是如何采用软件工程原理获得更高质量的代码。在实际选择语言时不能仅仅使用理论上的标准，还必须同时考虑实用方面的各种限制。下面是选择语言的主要标准。

(1)系统用户的要求。如果所开发的系统由用户负责维护，用户通常要求用他们熟悉的语言书写程序。

(2)可以使用的编译程序。运行目标系统的环境中可以提供的编译程序往往限制了可以选用的语言。

(3)可以得到的软件工具。如果某种语言有支持程序开发的软件工具可以利用，则目标系统的实现和验证变得比较容易。

(4)工程规模。如果工程规模很庞大，现有的语言又不完全适用，那么设计并实现一种供这个工程项目专用的程序设计语言，可能是一个正确的选择。

(5)程序员的知识。虽然对于有经验的程序员来说，学习一种新语言并不困难，但是要完全掌握一种新语言却需要实践。如果和其他标准不矛盾，那么应该选择一种已经为程序员所熟悉的语言。

(6)软件可移植性要求。如果目标系统将在几台不同的计算机上运行，或者预期的使用寿命很长，那么选择一种标准化程度高、程序可移植性好的语言是很重要的。

(7)软件的应用领域。所谓的通用程序设计语言，实际上并不是对所有应用领域都同样适用。因此，选择语言时应该充分考虑目标系统的应用范围。

5.1.3良好的编程实践

源代码的逻辑简明清晰、易读易懂是好程序的一个重要标准。关于编程风格，许多建议都和特定的语言相关。目前主流开发工具主要以Java和C++为主，因此这里为Java和C++这样的面向对象语言给出一些与语言无关的良好编程实践建议，这就需要从程序内部的文档入手建立良好的编程风格。所谓程序内部的文档，包括恰当的标识符、适当的注释和程序的视觉组织等。

1.标识符使用一致和有意义的变量名

选取含义鲜明的名字，使它能正确地提示程序对象所代表的实体，这对于帮助阅读者理解程序是很重要的。如果使用缩写，那么缩写规则应该一致，并且应该给每个名字加注解。程序员给出只对自己有意义的变量名是远远不够的，在软件工程领域，有意义的变量名是指“从将来维护程序员的角度来看是有意义的”。例如：

在20世纪70年代后期，南非约翰内斯堡有个小型软件公司，由两个编程团队组成。团队A由来自莫桑比克的人组成，拥有葡萄牙血统，母语是葡萄牙语，代码写得很好，变量名是有意义的，但是仅对说葡萄牙语的人有意义。团队B由以色列移民组成，母语是希伯来语，代码写得一样好，选择的变量名同样是有意义的，但是仅对说希伯来语的人有意义。

一天，团队A和负责人一同辞职了。团队B完全无法维护团队A曾经编写的任何优秀代码，因为他们不会讲葡萄牙语，对讲葡萄牙语的人有意义的变量名，对于语言能力仅限于希伯来语和英语的以色列人是完全不可理解的。公司老板无法雇用足够的会说葡萄牙语的程序员代替团队A，很快在大量不满客户的诉讼压力下破产了，因为这些客户的代码基本上是不可维护的了。

这种情况很容易避免，公司的领导应当在一开始就坚持用英语命名全部的变量名，而英语是每个计算机专业人员都理解的语言，于是变量名对每个维护人员就都是有意义的。

有些命名约定可以使代码更容易理解，其思想是变量名应该包括类型信息。例如，ptrChTmp可能表示一个临时变量(Tmp)用来指向字符(Ch)的指针(ptr)，这种方案最著名的是匈牙利命名法。这类方案的缺点是，当参与者不能拼读出变量名时，代码审查的效果会降低，逐个地读出变量名尤其痛苦。但是，对有匈牙利命名法经验的人来说，该方法增强了代码的可读性。

2.注释—自文档化代码的问题

当问到为何代码没有包含注释时，程序员常常会自豪地说：“我写的是自文档化代码”。意思是程序中的变量名经过认真选择，代码编写得十分精巧，以至于没有添加注释的必要。自文档化代码的确存在，但非常稀少。通常的情形是程序员在编写代码制品时认真考虑代码中每个名词的细微差别，并进行注释。

另外，在每个代码段中序言注释是必须有的，每个代码的顶部必须提供图5-1中列出的最基本信息。除了序言注释外，应当在代码中插入行内注释，以帮助维护程序员理解代码。专家建议，行内注释的使用场合应该仅仅是当代码编写的方式不明显，或使用了该语言中某些难以理解的方法的时候。相反，含糊不清的代码应当以清晰的方式重新编写，行内注释是帮助程序员维护的一种手段，不应当助长拙劣的编程实践或为其寻找借口。

图5-1一个代码制品的序言注释

3.业务数据常量建议使用参数

很少有真正的常量，也就是说，值“永远不会”改变。例如，销售税不是真正的常量，可能不时会调整销售税率，假定销售税率当前是6.0%，如果数值6.0硬性编码到某产品的许多代码中，那么改变该产品将是一项浩大的工程，可能导致忽视“常量”6.0的一个或两个实例，也可能错误地改变一个不相关的6.0。

更好的解决方案是像下面的Java声明：

publicstaticfinalfloatSALESTAXRATE=(float)6.0;

或在C++中声明：

constfloatSALESTAXRATE=6.0;

这样，无论哪里需要销售税率的值，都应当使用常量SALESTAXRATE而不是数值6.0。如果销售税率改变了，只需采用编辑器替换包含SALESTAXRATE值的那行代码即可。更好的方法是，运行开始时从参数文件或数据库基表中读入销售税率的值。因此，常量都应该当作参数处理，这样，当某个值发生变化时，就可以快速有效地实现改变。

4.视觉组织—代码编排以增加可读性

要想代码易于阅读相当简单。例如，即使编程语言允许，一行中也不应当出现多个语句。缩进是增加代码可读性最重要的技术，设想一下如果没使用缩进来帮助理解代码，很多代码都难于阅读。在Java或C++中，缩进可以用来匹配相应的{…}对，还能显示哪些语句属于给定的代码块。因此，正确的缩进太重要了，可使用CASE工具确保缩进的正确性。

另一个有用的方法是插入空行。方法之间应当用空行隔开，此外，用空行隔开大的代码块通常有助于阅读。额外的“空白区域”使代码更容易阅读，也更容易理解。

5.语句构造

设计期间确定了软件的逻辑结构，然而个别语句的构造却是编写程序的一个主要任务。构造语句时应该遵循的原则是，每个语句都应该简单而直接，不能为了提高效率而使程序变得过分复杂。下述规则有助于使语句简单明了：

不要为了节省空间而把多个语句写在同一行；

尽量避免复杂的条件测试；

尽量减少对“非”条件的测试；

避免大量使用循环嵌套和条件嵌套；

利用括号使逻辑表达式或算术表达式的运算次序清晰直观。

6.输入/输出

设计输入/输出界面的原则是友好、简洁、统一，符合用户的日常工作习惯。在设计和编写程序时应该考虑下述有关输入/输出风格的规则：

对所有输入数据都进行检验；

检查输入项重要组合的合法性；

保持输入格式简单；

使用数据结束标记，不要要求用户指定数据的数目；

明确提示交互式输入的请求，详细说明可用的选择或边界数值；

当程序设计语言对格式有严格要求时，应保持输入格式一致；

设计良好的输出报表给所有输出数据加标志。

7.编码标准与效率

编码标准是福也是祸。带有偶然性内聚的模块通常是使用某些规则的结果，如“每个模块将由35～50条可执行语句组成”。与这种死板的风格不同的是，“程序员在构造一个少于35条或多于50条可执行语句的模块之前，应当征求管理层的意见”。因为，没有哪种编码标准能适用所有可能的情形。

根据有关资料，以下原则对提高程序效率有一些帮助：

在编码之前，先化简算术和逻辑表达式，尽量使用整型算术和逻辑表达式；

 if语句嵌套不应当超过3层，除非得到上级的许可；

特别注意嵌套的循环，以确定是否有语句可以从循环内层移到循环外层；

应当避免使用goto语句，非要使用的话，尽量使用前向goto语句，用于处理错误；

尽量避免使用多维数组和复杂的表格；

尽量使用执行时间短的算术运算；

尽量避免混合使用不同数据类型的量。

5.1.4程序员的基本素质

要成为一名合格的程序员，不仅要具备编程功底和动手能力，还需要具备以下素质。

1.团队精神和协作能力

随着软件规模扩大，一个人的力量开发大型软件十分困难，甚至是不可能实现的。因此，团队精神和协作能力是程序员应具备的基本素质之一。

2.文档习惯

编写良好的文档是正规软件开发流程中非常重要的环节。缺乏文档，一个软件系统就会缺乏生命力，在未来的查错、升级以及模块复用时就会遇到极大的麻烦。因此，具备良好和规范的文档编写习惯同样是程序员应具备的基本素质之一。

3.规范化、标准化的代码编写习惯

早期的软件生产往往只注重个人的编程技巧，强调程序简练和执行效率，而不重视程序源代码的可读性和可维护性。作为一些国外知名软件公司，对代码的变量命名，代码内注释格式，甚至嵌套中行缩进的长度和函数间的空行数字都有明确规定。良好的编写习惯，不但有助于代码的移植和纠错，也有助于不同技术人员之间的协作。因此，程序员要养成良好的编码习惯。

4.需求理解能力

程序员需要理解一个模块的需求，写程序时往往只关注一个功能需求，他们把性能指标全部归结到硬件、操作系统和开发环境上，而忽视了代码本身的性能。性能需求指标中，稳定性、并访支撑能力以及安全性都很重要，作为程序员需要评估该模块在系统运营中所处的环境，将要受到的负荷压力以及各种潜在的危险和恶意攻击的可能性。

5.复用性和模块化思维能力

复用性和模块化思维能力是要求程序员在完成任何一个功能模块或函数时，多想一些，不要局限在完成当前任务的简单思路上，想想看该模块是否可以脱离这个系统存在，是否可以通过简单的修改参数的方式在其他系统和应用环境下直接引用，实现模块或函数的复用，如此可以极大地避免重复性开发工作，使程序员将更多时间和精力投入到创建新代码的工作中。

6.测试习惯

对于一个软件工程，问题发现越早，解决问题的代价就越小。程序员在每段代码、每个模块完成后都进行认真测试，就可以尽早发现和解决潜在的问题。

7.学习和总结的能力

程序员是一个知识更新很快的职业。程序员如果想安身立命，就必须不断跟进新的技术，学习新的技能。

5.2软件测试基础

软件的质量就是软件的生命，为了保证软件的质量，人们在长期的开发过程中积累了许多经验，并形成了许多行之有效的方法。但是借助这些方法，我们只能尽量减少软件中的错误和不足，而不能完全避免所有的错误。因此，软件测试是保证软件质量,提高软件可靠性的关键，是对软件规格说明、设计和编码的最后复审。软件产品最大的成本是检测软件错误、修正软件错误的成本。

1.什么是软件测试

软件测试的经典定义是：在规定条件下对软件进行操作，以发现错误，对软件质量进行评估。我们知道，软件是由文档、数据以及程序组成的，其中，程序是按照事先设计的功能和性能等要求执行的指令序列；数据是程序能正常操纵信息的数据结构；文档是与程序开发维护和使用有关的各种图文资料。那么，软件测试就应该是对软件开发过程中形成的文档、数据以及程序进行的测试，而不仅仅是对程序进行的测试。

大量统计资料表明，在整个软件开发中，测试工作量一般占30%～40%，甚至超过50%。在极端情况下，测试那种关系到人的生命安全的软件所花费的成本，可能相当于软件工程其他开发步骤总成本的3倍到5倍。因此，必须高度重视软件测试工作，绝不要以为写出程序之后软件开发工作就接近完成了，实际上，大约还有同样多的开发工作量需要完成。

软件测试只能证明软件存在缺陷，而不能证明软件没有缺陷。软件缺陷必须眼见为实。思考：如果软件中的问题没有人发现，那么它算不算软件缺陷？

2.软件测试的目的

软件测试的目的就是把软件的缺陷控制在一个可以进行软件系统交付/发布的程度上，可以交付/发布的软件系统并不是不存在任何缺陷，而是对于软件系统而言，没有主要的缺陷，或者说没有影响业务正常进行的缺陷，因此软件测试不可能无休止地进行下去，而是要把缺陷控制在一个合理的范围之内，因为软件测试也是需要花费巨大成本的。

因此，在测试阶段，测试人员应该努力设计出一系列测试方案，目的是为了“破坏”已经建造好的软件系统，即竭力证明程序中有错误，不能按照预定要求正确工作。有研究表明，发现并纠正软件中缺陷的费用可能占整个开发费用的40%～80%。因此，软件企业投入大量的资金不仅仅是为了“验证软件正确运行”，而是要找出导致软件无法正确运行的在软件中存在的大量缺陷。

G . Myers给出了关于测试的一些规则，这些规则可以看作是软件测试的目标：

(1)测试是为了发现程序中的错误而执行程序的过程；

(2)测试是为了证明程序有错，而不是证明程序无错；

(3)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；

(4)成功的测试是发现了至今为止尚未发现的错误的测试。

仅就测试而言，它的目标是发现软件中的错误，它只能证明软件存在缺陷，而不能证明软件没有缺陷。但是，发现错误并不是最终目的。对任何软件来说，开发完成时都会遗留没有被发现的缺陷，所以，软件测试并非是简单的“挑错”，而是贯穿于软件开发过程的始终，是一套完善的质量管理体系，这就要求测试工程师应该具有系统的测试专业知识及对软件的整体把握能力。

3.软件测试方法和测试策略

软件的测试设计与软件产品的设计一样，是一项需要花费许多人力和时间的工作，我们希望以最少量的时间和人力，最大可能地发现最多的错误。目前常用的测试方法主要有：白盒测试法、黑盒测试法。常用的软件测试策略主要有：单元测试、集成测试、确认测试、系统测试和验收测试。

实际上，为了保证软件质量，从项目开始测试人员就要介入，要了解客户需求，参与项目评审，把握测试要点。如果测试人员数量少，软件质量是得不到保证的。因此测试行业的确需要大量人才，尤其是性能测试。

5.3测试设计和管理

对于软件项目测试来说，测试团队应该合理地统筹安排软件测试工作，做好测试设计工作，例如测试策略的设计、测试方案的设计、测试用例的设计等；在测试工作开始后，要有效地管理好测试，例如测试用例管理、配置管理、测试缺陷跟踪管理等，否则会使得测试工作效率低下，甚至导致整个软件开发的低效率。

5.3.1错误曲线

软件是程序、数据、文档及其相关服务的完整集合，它并不是一种有形的产品。但是在软件开发过程中隐藏的错误会引起程序使用初期较高的故障率，错误改正之后，故障曲线会趋于平稳。理想情况下，软件的故障率呈现如图5-2所示的理想曲线。

图5-2软件故障率曲线

在软件的运行初期，未知的错误使得程序有较高的故障率，当修正了这些错误而且未引入新的错误时，软件将进入一种比较理想的平稳运行期。如图5-2中的实际曲线那样。这是因为软件开发时的需求环境、软硬件环境在不断变化，因此软件在其生命周期中会经历多次修改，每次修改都不可避免地会引入新的错误，导致软件的失效率升高，而对这些错误又要进行新的修改，使得软件的故障曲线呈现一种锯齿形，导致最后的故障率慢慢升高，即软件产生了退化，从而使得软件可靠性下降，当修改的成本变得难以接受时，软件就被抛弃。

5.3.2软件测试配置

要实现软件测试，就要对软件测试进行配置，包括编写测试计划、配置相应的软件测试环境、设计测试用例、编写测试文档等。本节主要介绍测试计划、测试环境和测试文档，测试用例将在下节中详细介绍。

1.软件测试计划

软件测试计划描述测试活动的目标、范围、方法、策略、资源、组织和进度等，并确定测试项、哪些功能特性将被测试、哪些功能特性将无需测试，识别和明确测试过程中的风险，使得测试活动能够在准备充分且定义清晰的条件下进行。

借助软件测试计划，可以使测试人员明确测试活动的意图，了解整个项目测试情况以及项目测试不同阶段所要进行的工作，方便管理者做宏观调控，进行相应资源配置，确保测试实施过程顺畅，有效地跟踪和控制测试过程，并能容易应对可能发生的各种变更。它规范了软件测试内容、方法和过程，为有组织地完成测试任务提供保障。

测试计划的文档可以作为软件测试人员之间，以及测试人员和软件开发人员等之间的交流工具，为软件测试的管理提供依据，并能够帮助及早地发现和修正软件需求分析、设计等阶段存在的问题。应该在软件需求分析阶段甚至更早的时候制定测试计划。

测试计划应当足够完整但也不应当过于详尽。通常来说，一个正规的测试计划应该包含以下几个项目：

测试的基本信息：包括测试目的、背景、测试范围等；

测试的具体目标：列出软件需要进行的测试部分和不需要进行的测试部分；

测试的策略：测试人员采用的测试方法，如回归测试、功能测试、自动测试等；

测试的通过标准：测试是否通过的界定标准以及没有通过情况的处理方法；

停测标准：给出每个测试阶段停止测试的标准；

测试用例：详细描述测试用例，包括测试值、测试操作过程、测试期待值等；

测试的基本支持：测试所需硬件支持、自动测试软件等；

部门责任分工：明确所有参与软件管理、开发、测试、技术支持等部门的职责；

测试人力资源分配：列出测试所需人力资源以及软件测试人员的培训计划；

测试进度安排：制定每一个阶段的详细测试进度安排表；

总之，软件测试计划是整个软件测试流程工作的基本依据，测试计划中所列条目在实际测试中必须一一执行。在测试的过程中，若发现新的测试用例，就要尽早补充到测试计划中。若预先制定的测试计划项目在实际测试中不适用或无法实现，那么也要尽快对计划进行修改，使计划具有可行性。

2.软件测试环境

软件测试环境是指为了完成软件测试工作所必需的计算机硬件、软件、网络设备、历史数据的总称。它包括测试设计环境、测试实施环境和测试管理环境三部分。测试环境可以模拟实际运行时可能的各种情况，是测试实施的一个重要阶段，也是软件测试的基础。测试环境适合与否会严重影响测试结果的真实性和正确性，合理的测试环境可以提高软件测试的工作效率。

经过良好规划和配置的测试环境，可以尽可能地减少环境的变动对测试工作的不利影响，并可以对测试工作的效率和质量的提高产生积极的作用。配置测试环境是测试实施的一个重要阶段，一般来说，配置测试环境有五个基本要素：硬件、软件、网络环境、数据准备、测试工具。其中，硬件、软件是测试环境中最基本的两个要素，并派生出后三者。

3.测试文档

软件测试是一个很复杂的过程，涉及软件开发其他阶段的工作，对于提高软件质量、保证软件正常运行有着十分重要的意义，因此必须把对测试的要求、过程及测试结果以正式的文档形式写下来。测试文档的编制是软件测试工作规范化的一个重要组成部分。

软件测试文档不只在测试阶段才开始考虑，它应在软件开发的需求分析阶段就开始着手编制，软件开发人员的一些设计方案也应在测试文档中得到反映，以利于设计的检验。测试文档对于测试阶段的工作有着非常明显的指导作用和评价作用。即便在软件投入运行的维护阶段，也常常要进行再测试或回归测试，这时仍会用到软件测试文档。

整个测试流程会产生很多个测试文档，一般可以把测试文档分为两类：测试计划和测试分析报告。

测试计划前面已经描述过，测试计划文档描述将要进行的测试活动的范围、方法、资源和时间进度等，其中罗列了详细的测试要求，包括测试的目的、内容、方法、步骤以及测试的准则等。

测试分析报告是执行测试阶段的测试文档，对测试结果进行分析说明，说明软件经过测试以后，结论性的意见如何，软件的能力如何，存在哪些缺陷和限制等，这些意见既是对软件质量的评价，又是决定该软件能否交付用户使用的依据。由于测试分析报告要反映测试工作的情况，自然应该在测试阶段编写。

《计算机软件测试文档编制规范》(GB/T9386

2008)标准给出了更具体的测试文档编制建议，规定了各个测试文档的格式和内容，主要涉及测试计划、测试说明和测试报告等。

5.3.3测试用例设计

测试用例是为了高效率地发现软件缺陷而精心设计并执行的少量测试数据。在实际测试中，由于无法达到穷举测试，所以要从大量输入数据中精选有代表性或特殊性的数据作为测试数据。不同的测试数据发现程序错误的能力差别很大，为了提高测试效率、降低测试成本，应该选用高效的测试数据。一个好的测试用例应该能发现尚未发现的软件缺陷。从测试用例本身构成的角度来看，测试用例是测试执行的最小实体，是为特定的目的而设计的一组测试输入、执行条件和预期结果。

测试用例通俗一点来讲就是编写一组前提条件、输入、执行条件、预期结果以完成对某个特定需求或目标测试的数据，体现测试方案、方法、技术和策略的文档。

1.测试用例的作用

测试用例始终贯穿于整个软件测试，是软件测试的核心。在软件测试过程中，参照测试用例，任何人员的流动对测试的影响、对项目质量的影响都可以说是微乎其微的。所以，测试用例可以预防部分风险或减少潜在风险的发生。

2.测试用例的主要内容

一个完整的测试用例应该包括以下内容：

测试用例的编号；

测试日期；

测试用例设计人员和测试人员；

测试用例的优先级；

测试标题；

测试目标；

测试环境；

输入数据/动作；

测试的操作步骤；

测试预期的结果。

3.测试用例的编写

在测试用例编写中主要涉及测试设计说明、测试用例说明和测试程序说明。ANSI/IEEE829标准分别对其进行了描述、规定，并制定了相应的格式和内容。

1)测试设计说明

测试设计说明是为单个软件功能定义测试方法的细节描述。ANSI/IEEE829定义测试说明为“提炼测试方法，明确指出设计包含的特性及其相关测试”。测试设计说明包括的要素有：标识符、要测试的特性、测试方法、测试用例信息、通过/失败规则等。

2)测试用例说明

有了测试设计说明，就可以按照测试设计说明进行描述，对每一个测试项设计具体的测试用例。ANSI/IEEE829称测试用例说明为“编写用于输入的实际数值和预期结果”，测试用例说明还明确指出使用具体测试用例产生的测试程序的各种限制。测试用例说明包括的要素有：标识符、测试标题、测试日期、测试项、测试环境要求、特殊要求、测试输入说明、操作步骤、预期结果、测试用例之间的关联以及测试用例设计人员和测试人员等。

3)测试程序说明

测试程序说明也称作测试脚本说明，详细定义执行测试用例的每一步操作。ANSI/IEEE829定义测试程序说明为“明确指出为实现相关测试设计而操作软件系统和试验具体测试用例的全部步骤”。测试程序说明包括的要素有：标识符、测试目的、特殊要求、程序步骤、操作日志、环境设置、启动步骤、程序运行步骤、结果判断、程序关闭、程序终止、测试环境重置、异常事件流等。

4.测试用例的设计

测试用例是整个测试工作中的重中之重，测试的一般流程包括制定测试计划、编写测试用例、执行测试、跟踪测试缺陷、编写测试报告等。测试计划、大纲制定后就需要进行测试用例的设计，之后所有的工作全都是在测试用例的基础上展开的。

测试用例的设计应注意以下几点问题：

利用成熟的测试用例设计方法来指导设计；

保证测试用例的正确性；

保证测试用例的明确性，避免测试用例存在含糊的因素，使测试人员在测试过程中不会出现模棱两可的测试结果；

保证测试用例的代表性，尽量将具有相似功能的测试用例抽象合并，使每一个测试用例都具有代表性，可以测试一类或一系列的系统功能；

保证测试用例的简洁性，避免冗长和复杂的测试用例，使其具有良好的可读性，便于测试人员的理解和操作；

要有足够详细、准确和清晰的步骤；

设计测试用例时，要使得测试结果具有可判定性和可重现性；

测试用例应该从系统的最高级别向最低级别逐一展开；

每个测试用例都应单独放在文档中；

系统中的所有功能都应该对应到测试用例中；

每个测试用例都应该依据需求进行设计；

利用测试用例文档编写测试用例时必须符合内部的规范要求；

测试用例的设计人员最好是具有丰富经验的测试人员。

5.测试用例的设计方法

测试用例是多样的、复杂的而且也是简单的，设计的技术也不唯一，一般包括白盒测试用例的设计、黑盒测试用例的设计和综合设计。具体的内容在后面章节中会详细介绍到。

5.4软件测试过程

软件测试的过程分成若干个阶段，每个阶段各有特点。按照尽早进行测试的原则，测试人员应该在需求阶段就介入，并贯穿软件开发的全过程。测试过程的各个阶段为：

测试需求的分析和确定；

测试计划；

测试设计；

测试执行；

测试记录和缺陷跟踪；

回归测试；

测试总结和报告。

首先在分析清楚需求的前提下对测试活动进行计划和设计，然后按既定的计划执行测试和记录测试，对测试的结果进行检查分析，形成测试报告，这些测试结果和分析报告又能指导下一步的测试设计，因此形成了一个循环的环，如图5-3所示。

图5-3软件测试的过程

5.4.1软件测试基本原则

软件测试的目标是以最少的时间和人力找出软件中潜在的各种错误和缺陷。为了能设计出有效的测试方案，软件工程师必须遵循以下测试准则。

1．所有的测试都应追溯到用户需求

最严重的错误(从用户角度)是那些导致软件无法满足需求的错误。

2．尽早地和不断地进行软件测试

概要设计时应完成测试计划。详细的测试用例定义可在设计模型确定后开始，所有测试可在任何代码被产生之前进行计划和设计。

3．不可能做穷尽测试

对于程序本身，在很多情况下，由于其运算复杂性和逻辑复杂性，在有限的时间内穷举测试也是不可能的。所以在测试过程中，应该采用具有代表性、最有可能查出系统问题的测试用例，尽量去发现错误。

4．软件测试不等于程序测试

软件测试应贯穿于软件定义与开发的整个期间。据美国一家公司统计，软件错误属于需求分析和软件设计的错误约占64%，属于程序编写的错误仅占36%。程序编写的许多错误是“先天的”。

5．应由独立的第三方测试机构来构造测试

由于思维定式，人们难于发现自己的错误或缺陷。因此，为达到测试目的，应采取互相自测，由客观、公正、严格的独立的测试部门测试或者独立的第三方测试机构进行测试。

6．设计完善的测试用例，并长期保留测试用例，直至系统废弃

测试用例是执行程序的最小实体。软件测试的本质就是针对要测试的内容确定一组测试用例。测试用例应由输入数据和预期的输出结果两部分组成，同时还要兼顾合理的输入和不合理的输入数据。

7．软件测试只能表明缺陷的存在，而不能证明产品已经没有缺陷

软件测试只是查找软件缺陷的过程，即使测试人员使用了大量的测试用例、不同的测试方法对软件产品进行测试，测试成功以后也不能说明软件产品已经准确无误，完全符合用户的需求。也就是人们常说的“软件测试只能说明错误，不能说明正确”。

8．注意测试中的群集现象

经验表明，软件产品中所存在的缺陷数与已发现的缺陷数成正比。根据这个规律，应当对缺陷群集的软件部分进行重点测试，以提高测试投资的效益。

在所测的软件部分中，若发现缺陷数目多，则可能残存的缺陷数目也比较多。这种缺陷群集性现象已被许多软件的测试实践所证实。例如，在美国IBM公司的OS/370操作系统中，47%的错误或缺陷仅与该系统4%的程序模块有关。这种现象对测试很有用。

9．及时更新测试，并进行回归测试

程序员在编写程序时经常会有这样的经验，对一个程序的缺陷进行了修改，而重新调试时，发现由于上一个改动而导致了更多缺陷的出现。同样，软件测试发现缺陷并改正后，很可能引入新的软件缺陷，往往是因为程序之间的关联性，或者缺陷的表现和缺陷的原因不在同一个地方等。所以，任何一次软件缺陷改正并提交后，都必须进行回归测试。回归测试的目的是对修正缺陷后的应用程序进行测试，以确保缺陷被修复，并且没有引入新的软件缺陷。

10．软件测试应该有计划、有组织地进行

作为软件开发中的重要活动，软件测试应该由软件测试计划进行指导，成立合适的软件测试团队，妥善并长期保存一切软件测试过程文档，并建立有效的软件缺陷发现、上报、改正、跟踪、统计机制，避免软件测试过程中的盲目性、随意性和重复劳动。

5.4.2软件测试的步骤、测试信息流

1.软件测试的步骤

软件测试过程按各测试阶段的先后顺序可分为单元测试、集成(组装)测试、确认(有效性)测试、系统测试和验收(用户)测试五个步骤，如图5-4所示。

图5-4软件测试的步骤

(1)单元测试：测试执行的开始阶段。测试对象是每个单元。测试目的是保证每个模块或组件能正常工作。单元测试主要采用白盒测试方法，检测程序的内部结构。

(2)集成测试：也称组装测试，在单元测试基础上，对已测试过的模块进行组装，进行集成测试。测试目的是检验与接口有关的模块之间的问题。集成测试主要采用黑盒测试方法。

(3)确认测试：也称有效性测试，在完成集成测试后，验证软件的功能和性能及其他特性是否符合用户要求。测试目的是保证系统能够按照用户预定的要求工作。确认测试通常采用黑盒测试方法。

(4)系统测试：在完成确认测试后，为了检验它能否与实际环境(如软硬件平台、数据和人员等)协调工作，还需要进行系统测试。可以说，系统测试之后，软件产品基本满足开发要求。

(5)验收测试：测试过程的最后一个阶段。验收测试主要突出用户的作用，同时软件开发人员也应该参与进去。

上述步骤是传统软件测试的步骤，测试作为软件工程的一个阶段，它的根本任务是保证软件的质量，因此除了进行测试之外，还有另外一些与测试密切相关的工作(如软件配置、测试配置等)应该完成。

2.软件测试信息流

软件测试阶段的信息流如图5-5所示，这个阶段的输入信息包括两类：

图5-5测试阶段的信息流

软件配置：指测试对象。通常包括需求说明书、设计说明书和被测试的源程序等；

测试配置：通常包括测试计划、测试步骤、测试用例以及具体实施测试的测试程序、测试工具等。

实际上测试配置是软件配置的一个子集，最终交出的软件配置应该包括上述测试配置以及测试的实际结果和调试的记录。

对测试结果与预期的结果进行比较以后，即可判断是否存在错误，决定是否进入排错阶段，进行调试任务。通常根据出错的情况得到出错率来预估被测软件的可靠性，这将对软件运行后的维护工作有重要价值。

5.4.3软件测试组织与人员

随着软件开发规模的增大、复杂程度的增加，以寻找软件中的错误为目的的测试工作就显得更加困难。为了尽可能多地找出程序中的错误，生产出高质量的软件产品，加强对测试工作的组织和管理就显得尤为重要。

1.软件测试的组织

软件测试是一个复杂的过程，它的组织形式包括以下三个部分：

1)测试的过程及组织

根据软件测试计划，由一位对整个系统设计熟悉的设计人员编写测试大纲，明确测试的内容和测试通过的准则，设计完整合理的测试用例，以便系统实现后进行全面测试。当软件由开发人员完成并检验后，提交测试组，由测试负责人组织测试，测试一般可以下列方式组织：编写测试大纲、测试用例，将测试过程分阶段——单元测试、集成测试、确认(有效性)测试、系统测试和验收(用户)测试。

2)测试人员组织

要成功地完成项目测试任务，必须建立一个高素质的软件测试团队，并将成员有效地组织起来，进行合理分工，以达到最高的工作效率。测试团队的组织和人员管理是软件测试管理中非常重要的一部分，直接影响软件测试效率和软件产品质量。

3)软件测试文档组织

软件测试文档描述要执行的软件测试及测试的结果。测试文档不只在测试阶段才考虑，它在软件开发的需求分析阶段就开始着手，因为测试文档与用户有着密切的关系。在设计阶段的一些设计方案也应在测试文档中得到反映，以利于设计的检验；在已开发的软件投入运行的维护阶段，常常还要进行再测试或回归测试，这时仍须用到测试文档。所以，在整个测试过程中，对测试文档的类型、使用和编写等的组织非常重要。

2.软件测试人员

软件测试人员是用户的眼睛，是最早看到并使用软件的人，所以应该站在用户的角度，代表用户说话，及时发现问题，力求使软件功能趋于完善。

为了让测试团队的每个成员都清楚自己的任务，并使得每一个任务都落实到具体的负责人，测试团队管理者应当明确定义测试团队的角色和职责。典型的测试团队的角色和相应的职责如下所述。

(1)测试经理：代表团队与其他部门进行交流，与用户进行沟通，人员招聘、管理和培训，制定测试预算、进度，估计测试工作量；制定测试计划，引入测试工具；定义和改进测试过程；监控测试活动进行并跟踪进展情况。

(2)测试工程师：负责设计和实现测试脚本，确定测试特定需求和测试用例优先级；备份和归档所有测试文档和资料；生成测试复用包和测试总结报告；向测试经理汇报并在开始测试前向测试人员介绍各自的任务。

(3)测试人员：建立和初始化测试环境，准备测试数据和软硬件；执行测试工程师建立的测试脚本，并负责解释和记录测试用例的执行结果。根据具体分工不同，测试人员可以分为系统结构测试人员、系统功能测试人员、系统流程测试人员、可用性测试人员、网络测试人员、安全测试人员等。

5.5软件测试的基本方法

5.5.1软件测试方法与技术

1．静态测试与动态测试

根据程序是否运行可以把软件测试方法分为静态测试和动态测试两大类。

1)静态测试

静态测试方法的主要特征是走读源代码，对软件进行分析、检查和审阅，不实际运行被测试的软件。因此，静态方法常称为“分析”。所谓静态分析，就是不需要执行所测试的程序，而只是通过扫描程序正文，对程序的数据流和控制流等信息进行分析，找出系统的缺陷，得出测试报告。

静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。

在静态测试中，主要就是对软件配置(包括需求规格说明书、软件设计说明书、源程序等)做检查和审阅，具体包括：

检查算法的逻辑正确性，确定算法是否实现了所要求的功能；

检查模块接口的正确性，确定形参的个数、数据类型、顺序是否正确，确定返回值类型及返回值的正确性；

检查输入参数是否有合法性检查。如果没有合法性检查，则应确定该参数是否不需要合法性检查，否则应加上参数的合法性检查；

检查调用其他模块的接口是否正确，检查实参类型、实参个数是否正确，返回值是否正确。若被调用模块出现异常或错误，检查程序是否有适当的出错处理代码；

检查是否设置了适当的出错处理，以便在程序出错时，能对出错部分进行重新安排，保证其逻辑的正确性；

检查表达式、语句是否正确，是否含有二义性；

检查常量或全局变量使用是否正确；

检查标识符的使用是否规范、一致，变量命名是否好理解、简洁、规范和易记；

检查程序风格的一致性、规范性，代码是否符合行业规范，是否所有模块的代码风格一致、规范；

检查代码注释是否完整，是否正确反映了代码的功能，并查找错误的注释。

实践表明，通过静态测试，可找出30%～70%的逻辑设计错误。但程序中仍会隐藏许多错误，无法通过静态测试来发现，因此必须通过动态测试进行详细分析。

2)动态测试

动态测试方法通过运行软件来检验软件的动态行为和运行结果的正确性。动态测试真正运行被测程序，在执行过程中，通过输入有效的测试用例，对其输入与输出的对应关系进行分析，以达到检测的目的。动态测试方法的基本步骤如下：

选取定义域的有效值，或选取定义域外的无效值；

对已选取值决定预期的结果；

用选取值执行程序；

将执行结果与预期的结果相比，不吻合则说明程序有错。

不同的测试方法其各自的目标和侧重点不一样，在实际工作中要将静态测试和动态测试结合起来，以达到更加完美的效果。

在动态测试中，又有基于程序结构的白盒测试(或称为覆盖测试)和基于功能的黑盒测试。

2．白盒测试与黑盒测试

根据软件测试的不同方面，软件测试可以分为针对系统外部功能的黑盒测试和针对系统内部逻辑结构白盒测试。

1)黑盒测试—测试对象为程序的功能

黑盒测试也称功能测试或数据驱动测试，它在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用——逐一验证程序的功能。

黑盒测试方法主要有等价类划分、边值分析、因果图、错误推测等，主要用于软件确认测试。黑盒法着眼于程序外部结构，不考虑内部逻辑结构，针对软件界面和软件功能进行测试。黑盒法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。

2)白盒测试—测试对象为程序的逻辑结构

白盒测试也称结构测试或逻辑驱动测试，它知道产品内部工作过程，通过测试来检测产品内部动作是否按照规格说明书的规定正常进行。白盒测试按照程序内部的结构测试程序，检验程序中的每条通路是否都能按预定要求正确工作，而不顾它的功能——程序的每一组成部分至少被测试一次。这一阶段测试以软件开发人员为主。

白盒测试的主要方法有逻辑覆盖、路径分析等，主要用于软件验证。白盒法全面了解程序内部逻辑结构，对所有逻辑路径进行测试。白盒法是穷举路径测试，在使用白盒法时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。

3．验证测试与确认测试

验证和确认是软件能力成熟度集成模型(CMMI)三级的两个过程域，是对软件测试过程中的两种不同目的的测试过程。

1)验证测试(Verification)

验证测试指测试人员在模拟用户环境的测试环境下，对软件进行测试，验证已经实现的软件产品或产品组件是否实现了需求中所描述的所有需求项。也就是组织开发工作产品的同行对工作产品进行系统性的检查，发现工作产品中的缺陷，并提出必要的修改意见，达到消除工作产品缺陷的目的，适用于所有立项开发的软件项目及产品。其中白盒测试法是一种验证技术，回答了“我们在正确地构造一个系统吗？”的问题。

2)确认测试(Validation)

确认测试指测试人员在真实的用户环境下，确认软件产品或产品组件不仅实现了需求中所描述的所有需求项，而且它也是满足用户的最终需要的，也就是确保产品或产品构件适合其预定的用途。确认主要是对中间及最终产品的检查与验收，表现形式为审批、签字确认、正式的验收报告等。确认与验证紧密结合，并采用验证的方法，如同行评审、检查、走查、测试等。它适用于所有立项开发的软件项目与产品。其中黑盒测试法是一种确认技术，回答了“我们在构造一个正确的系统吗？”的问题。

验证和确认二者的区别是：测试环境和测试目的不同，但都是软件产品在发布前必须进行的测试活动。

5.5.2软件测试的误区

随着市场对软件质量要求的不断提高，软件测试不断受到重视。但是，我国不少软件企业的软件开发模式仍然处在无序开发的不规范状态，导致重视编码和轻视测试的现象。对于很多人(甚至是软件项目组的技术人员)还存在对软件测试的认识误区，这进一步影响了软件测试活动的开展和软件测试质量的提高。

误区1：软件开发完成后进行软件测试。

软件测试的对象不仅仅是软件代码，还包括软件需求文档和设计文档。软件开发与软件测试应该是交互进行的，例如，单元编码需要单元测试，模块组合阶段需要集成测试。如果等到软件编码结束后才进行测试，那么测试的时间将会很短，测试的覆盖面将很不全面，测试的效果也将大打折扣。更严重的是，如果此时发现了软件需求阶段或概要设计阶段的错误，修复该类错误将会耗费大量的时间和人力。

误区2：软件发布后如果发现质量问题，那是软件测试人员的错。

从软件开发的角度看，软件的高质量不是软件测试人员测出来的，是在软件生命周期的各个过程中设计出来的。出现软件错误，不能简单地归结为某一个人的责任，有些错误的产生可能不是技术原因，可能来自于混乱的项目管理。

解决之道是：应该分析软件项目的各个过程，从过程改进方面寻找产生错误的原因和改进的措施。

误区3：软件测试要求不高，随便找个人都行。

很多人都认为软件测试就是安装和运行程序，点点鼠标、按按键盘的工作，这是由于不了解软件测试的具体技术和方法造成的。随着软件工程学的发展和软件项目管理经验的提高，软件测试已经形成了一个独立的技术学科，演变成一个具有巨大市场需求的行业。软件测试技术不断更新和完善，新工具、新流程、新测试设计方法都在不断更新，需要掌握和学习很多测试知识，所以具有编程经验的程序员不一定是一名优秀的测试工程师。

误区4：软件自动测试效率高，将取代软件手工测试。

自动测试具有测试效率高、人工干涉少、灵活方便等优点。然而，自动测试技术应用范围受到限制，需要针对被测软件单独编写和调试比较复杂的测试脚本，而且自动测试工具价格通常十分昂贵，非一般软件公司可以购买得起。当前软件测试领域，测试工程师的手工测试仍然处于十分重要的地位，软件自动测试仅是手工测试的辅助手段。

误区5：软件测试是测试人员的事情，与程序员无关。

开发和测试是相辅相成的过程，需要软件测试人员、程序员和系统分析师等保持密切联系，需要更多的交流和协调，以便提高测试效率。对于单元测试主要应该由程序员完成，必要时测试人员可以帮助设计测试用例。对测试中发现的软件错误，很多需要程序员通过修改编码才能修复。程序员可以有目的地分析软件错误的类型、数量，找出产生错误的位置和原因，以便在今后的编程中避免同样的错误，积累编程经验，提高编程能力。

误区6：项目进度吃紧时少做些测试，时间富裕时多做测试。

这是不重视软件测试的表现，也是软件项目过程管理混乱的表现，必然会降低软件测试的质量。因为缩短测试时间带来的测试不完整，会给项目质量带来潜在风险，往往造成更大的浪费。克服这种现象的最好办法是加强软件过程的计划和控制，包括软件测试计划、测试设计、测试执行、测试度量和测试控制。

误区7：软件测试是没有前途的工作，只有程序员才是软件高手。

项目的成功往往依靠个别全能程序员，他们负责总体设计和程序详细设计，认为软件开发就是编写代码，给人的印象往往是程序员是真正的牛人，具有很高的地位和待遇。因此，软件测试很不受重视，软件测试人员的地位和待遇自然就很低了，甚至软件测试变得可有可无。

总之，随着市场对软件质量的要求不断提高，软件测试将变得越来越重要，相应的软件测试人员的地位和待遇将会逐渐提高。在微软等软件过程比较规范的大公司，软件测试人员的数量和待遇与程序员没有多大差别，优秀测试人员的待遇甚至比程序员还要高。软件测试将会成为一个具有很大发展前景的行业，市场需要更多具有丰富测试技术和管理经验的测试人员，他们同样是软件专家。

5.6软件测试策略

一个好的测试策略和测试方法，必将给软件测试带来事半功倍的效果。依据软件本身的性质、规模及应用场合的不同，可以选择不同的测试方案。以最少的软件、硬件及人力资源投入得到最佳的测试效果，这就是测试策略的目标所在。

5.6.1测试策略

1．什么是软件测试策略

软件测试策略是指在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合。测试策略通常描述测试工程的总体方法和目标，描述目前在进行哪个阶段的测试(如单元测试、集成测试、系统测试)以及每个阶段内进行的测试种类(如功能测试、性能测试、压力测试等)，以确定合理的测试方案，使得测试更有效。

软件测试策略包含以下四个特征：

(1)测试从模块层开始，然后扩大延伸到整个基于计算机的系统集合中；

(2)不同的测试技术适用于不同的时间点；

(3)测试是由软件的开发人员和(对于大型系统而言)独立的测试组来管理的；

(4)测试和调试是不同的活动，但是调试必须能够适应任何的测试策略。

2．影响测试策略的因素

软件测试策略随着软件生命周期的变化、软件测试方法、技术与工具的不同而发生变化。这就要求在制定测试策略的时候，应该综合考虑测试策略的影响因素及其依赖关系。这些影响因素可能包括测试项目资源因素、项目的约束和测试项目的特殊需要等。

3．测试策略的确定

一个好的测试策略应该包括实施的测试类型和测试的目标，实施测试的阶段、技术，用于评估测试结果和测试是否完成的评测和标准，对测试策略所述的测试工作存在影响的特殊事项等内容。为了确定一个好的测试策略，可以从基于测试技术的测试策略和基于测试方案的测试策略两个方面来考虑。

1)基于测试技术的测试策略

在任何情况下都应使用边界值分析方法；

必要时使用等价类划分法补充一定数量的测试用例；

必要时再用错误推测法补充测试方案；

对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，看其是否达到了要求；

根据对程序可靠性的要求采用不同的逻辑覆盖标准，再补充一些测试方案。

2)基于测试方案的测试策略

根据程序的重要性和一旦发生故障将造成的损失来确定它的测试等级和测试重点；认真研究，使用尽可能少的测试用例发现尽可能多的程序错误，以避免测试过度和测试不足。

除此之外，测试策略的制定从策略本身来说，包括宏观的测试战略和微观的测试战术，如图5-6所示。

图5-6测试策略

总之，测试活动需要采用各种不同的策略。这些策略表明了为确保软件质量而采用的不同的出发点、不同的事例、不同手段和测试方案。

5.6.2单元测试

程序员编写代码时，一定会反复调试自己编写的程序代码以保证其能够编译通过。如果是编译没有通过的代码，没有任何人会愿意交付给自己的老板。没有任何人可以轻易承诺这段代码的运行结果一定是正确的。这时，单元测试会为此做出保证。

1.单元测试的定义

单元测试是针对软件设计中的最小单位—程序模块进行正确性检验的测试工作。作为一个最小的单元应该有明确的功能定义、性能定义和接口定义，而且可以清晰地与其他单元区分开来。一个菜单、一个显示界面或者能够独立完成的具体功能都可以是一个单元。从某种意义上，单元的概念已经扩展为组件。

单元测试主要测试每个程序模块内部在语法、格式和逻辑上可能存在的错误。通常，一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。因此，单元测试通常是由程序员自己来完成的。

2.单元测试的目的

单元测试的主要目的是确保各单元模块被正确地编码。单元测试除了保证测试代码的功能性外，还需要保证代码在结构上具有可靠性和健全性，并且能够在所有条件下正确响应。进行全面的单元测试，可以减少应用级别所需的工作量，并且彻底减少系统产生错误的可能性。如果手动执行，单元测试可能需要大量的工作，自动化测试会提高测试效率。

除此之外，单元测试也应验证代码是否根据详细设计说明书进行。例如，验证代码是否与设计规格相符合、跟踪需求和设计的实施、发现需求和设计中存在的错误等。

3.单元测试的内容

单元测试的任务是测试构造软件系统的各个模块。一般来说，单元测试主要侧重于测试各个模块的模块接口、局部数据结构、独立路径、出错处理、边界条件，如图5-7所示。

图5-7单元测试的内容

(1)模块接口测试：对通过被测模块的数据流进行测试。为此，对模块接口，包括参数表、调用子模块的参数、全程数据、文件输入/输出操作都必须检查。

(2)局部数据结构测试：设计测试用例检查数据类型说明、初始化、默认值等方面的问题，还要查清全程数据对模块的影响。

(3)独立路径测试：选择适当的测试用例，对模块中重要的执行路径进行测试。基本路径测试和循环测试可以发现大量的路径错误，是最常用且最有效的测试技术。

(4)错误处理测试：检查模块的错误处理功能是否包含有错误或缺陷。例如，是否拒绝不合理的输入、出错的描述是否难以理解、是否对错误定位有误、是否出错原因报告有误、是否对错误条件的处理不正确等。

(5)边界条件测试：要特别注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。此外，如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。这类信息对进行软件性能评价是十分有用的。

4.单元测试的步骤

通常单元测试在编码阶段进行。当源程序代码编制完成，经过评审和验证，确认没有语法错误之后，就开始进行单元测试的测试用例设计。利用设计文档，设计可以验证程序功能、找出程序错误的多个测试用例。对于每一组输入，应有预期的正确输出结果。

模块接口测试中的被测模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相关联的模块。辅助模块可分为驱动模块和桩模块两种。

(1)驱动模块：用来模拟被测模块的上级调用模块，功能要比真正的上级模块简单得多。它接收测试数据，把这些数据传送给被测模块，最后输出实测结果。

(2)桩模块：用以代替被测模块调用的子模块，作用是返回被测模块所需的信息。

被测模块、与它相关的驱动模块以及桩模块共同构成了一个单元测试环境，如图5-8所示。

图5-8单元测试环境

如果一个模块要完成多种功能，并且以程序包或对象类的形式出现，例如Ada中的包，MODULA中的模块、C++中的类，这时可以将模块看成由几个小程序组成。对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。对支持某些标准规程的程序，更要着手进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。

5.6.3集成测试（组装测试）

通常经过单元测试后的模块能够单独工作，能够达到设计要求，但在把模块集成后并不能保证各模块能够正常地协同工作。其原因在于：模块相互调用时接口会引入许多新问题，程序在某些局部反映不出来的问题，在全局上很有可能暴露出来，而单元测试是无法找出这类错误的。因此，在各模块完成单元测试的基础上，还应将模块按设计要求组装起来，针对程序整体结构进行组装集成测试。

1.集成测试的定义

集成测试是介于单元测试和系统测试之间的过渡阶段，与软件开发计划中的软件概要设计阶段相对应，是单元测试的扩展和延伸。采用的测试方法主要为白盒测试方法。集成测试是根据实际情况对程序模块采用适当的集成测试策略组装起来，对系统的接口以及集成后的功能进行正确校验的测试工作，也称为组装测试或联合测试。

在集成测试时需要考虑以下问题：

模块集成后，穿越模块接口的数据是否会丢失？

模块集成后，各模块的功能是否会相互抑制？

模块集成后的功能能否达到预期的要求？

各模块的接口是否一致、各模块间的数据流和控制流是否按照设计实现其功能？

全局及局部数据的作用域是否存在问题，是否会被非法修改？

单个模块的误差通过累积是否会放大到不能接受的程度？

单个模块的错误是否会导致数据库错误？

2.集成测试的模式

选择用何种方式把模块组装起来形成一个可运行的系统是软件集成测试中的策略体现，其重要性是明显的，集成的方式直接关系到模块测试用例的形式、所用测试工具的类型、模块编号的次序和测试的次序、生成测试用例的费用和调试的费用等，一般是根据软件的具体情况来决定采用哪种模式。通常，把模块组装成为系统的测试方式有一次性集成测试和增量式集成测试两种方式。

1)一次性集成测试(也称作非渐增式集成测试)

它首先对每个模块分别进行单元测试，然后把所有的模块按设计要求组装在一起，再进行整体测试。图5-9所示的是一次性集成测试方式的实例。如图5-9(a)所示，表示的是整个系统结构，共包含6个模块。具体测试过程如下：

如图5-9(b)所示，为模块B配备驱动模块D1来模拟模块A对B的调用。为模块B配备桩模块S1来模拟模块E被B调用。对模块B进行单元测试。

如图5-9(d)所示，为模块D配备驱动模块D3来模拟模块A对D的调用。为模块D配备桩模块S2来模拟模块F被D调用。对模块D进行单元测试。

如图5-9(c)、图5-9(e)、图5-9(f)所示，为模块C、E、F分别配备驱动模块D2、D4、D5。对模块C、E、F分别进行单元测试。

如图5-9(g)表示，为主模块A配备三个桩模块S3、S4、S5。对模块A进行单元测试。

在将模块A、B、C、D、E分别进行了单元测试之后，再一次性进行集成测试。

测试结束。

图5-9一次性集成测试方式实例

2)增量式集成测试(也称渐增式集成测试)

增量式集成测试方式逐个把未经过测试的模块组装到已经测试过的模块上，进行集成测试。每加入一个新模块，进行一次集成测试，重复此过程直至程序组装完毕。在组装过程中，如果出现错误，则错误发生在新加入的模块中。

增量式集成测试有自顶向下增量测试方式、自底向上增量测试方式和混合增量测试方式三种方式。

(1)自顶向下增量测试方式：该方式从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。该方法不需要编写驱动模块，只需编写桩模块。

自顶向下集成测试的步骤如下：

①以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代；

②依据所选的集成策略(深度优先或广度优先)，每次只替代一个桩模块；

③每集成一个模块立即测试一遍，只有每组测试完成后，才着手替换下一个桩模块；

④循环执行上述步骤②～③，直至整个程序构造完毕。

如图5-10所示，表示的是按照深度优先方式遍历的自顶向下增值的集成测试实例。

具体测试过程如下：

在树状结构图中，按照先左后右的顺序确定模块集成路线。

如图5-10(a)所示，先对顶层的主模块A进行单元测试。就是对模块A配以桩模块S1、S2和S3，用来模拟它所实际调用的模块B、C、D，然后进行测试。

如图5-10(b)所示，用实际模块B替换掉桩模块S1，与模块A连接，再对模块B配以桩模块S4，用来模拟模块B对E的调用，然后进行测试。

判断模块E没有叶子结点，也就是说以A为根结点的树状结构图中的最左侧分支深度遍历结束，转向下一个分支。

如图5-10(d)所示，模块C替换掉桩模块S2，连到模块A上，然后进行测试。

判断模块C没有桩模块，转到树状结构图的最后一个分支。

如图5-10(e)所示,模块D替换掉桩模块S3，连到模块A上，同时给模块D配以桩模块S5，来模拟其对模块F的调用，然后进行测试。

如图5-10(f)所示，去掉桩模块S5，替换成实际模块F，连接到模块D上，然后进行测试。

对树状结构图进行了完全测试，测试结束。图5-10自顶向下增量测试方式实例

(2)自底向上增量测试方式：自底向上集成从软件结构最低层的模块开始组装测试，因测试到较高层模块时，所需的下层模块功能均已具备，所以该方法仅需编