企业管理测试策略.docx

《企业管理测试策略.docx》由会员分享，可在线阅读，更多相关《企业管理测试策略.docx（38页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第17章 软件测试策略软件测试策略把软件测试用例的设计方法集成到一系列已经周密计划过的步骤中去，从而使得软件的开发得以成功的完成。同样重要的是，软件测试策略为软件开发人员、质量保证组织、和客户提供了一个路线图这个路线图描述了测试的步骤，以及当这些步骤在计划和实施的过程中，需要多少工作量、时间、和资源。因此，任何测试策略都必须和测试计划、测试用例设计、测试执行、还有测试结果数据的收集与分析结合在一起。一种软件测试策略应当具备足够的灵活性，这样在必要的时候它能够有足够的创造性和可塑性来应付所有的大软件系统。与此同时，软件测试策略还必须保证足够的严格，这样才能保证对项目的整个进程进行合理的计划和跟踪

2、管理。ShoomanSHO83对这个问题进行了探讨：在许多情况下，测试是一个独立的过程，不同的测试类型的数量和不同的开发方法是一样多。许多年以来，我们对付程序出错的唯一武器就是谨慎的设计，以及程序员个人的智慧。我们现在处于这样的一个时代现代设计技术(和正式的技术复审)正在帮助我们减少代码中存在的初始错误。类似地，不同的测试方法正在开始聚合为有限的几种方法和思想。这些方法法和思想想就是我我们所说说的策略略。在第第16章章中，我我们已经经介绍了了软件测测试技术术。在本本章中，我们将将会把注注意力放放在软件件测试策策略上。17.11 软件件测试的的策略途途径测试是一一系列可可以事先先计划并并且可以以

3、系统地地进行管管理的活活动。正正是由于于这个原原因，应应当为软软件工程程过程定定义一个个软件测测试的模模板即我们们可以把把特定的的测试用用例设计计方法放放置进去去的一系系列步骤骤。人们已经经提出了了许多软软件测试试策略，所有这这些策略略都为软软件开发发人员提提供了一一个供测测试用的的模板，而且它它们都包包含下列列的类属属特征：测试开开始于模模块层，然后后“延伸伸”到整整个基于于计算机机的系统统集合中中。不同的的测试技技术适用用于不同同的时间间点。测试是是由软件件的开发发人员和和(对大大型系统统来说)独立的的测试组组来管理理的。测试和和调试是是不同的的活动，但是调调试必须须能够适适应任何何的测试

4、试策略。软件测试试策略必必须提供供可以用用来检验验一小段段源代码码是否得得以正确确实现的的低层测测试，同同时也要要提供能能够验证证整个系系统的功功能是否否符合用用户需求求的高层层测试。一种策策略必须须为使用用者提供供指南，并且为为管理者者提供一一系列的的重要的的程碑。因为测测试策略略的步骤骤是在软软件完成成的最终终期限的的压力已已经开始始出现的的时候才才开始进进行的，所以测测试的进进度必须须是可测测量的，而且问问题要尽尽可能早早的暴露露出来才才好。17.11.1 验证和和确认软件测试试是我们们通常所所讲的一一个更为为广泛的的话题验验证和确确认(VVeriificcatiion andd Vaa

5、liddatiion，VVV)的一一个部分分。验证证指的是是保证软软件正确确地实现现了某一一特定功功能的一一系列活活动。确确认指的的则是保保证软件件的实现现满足了了用户需需求的一一系列活活动。BBoehhmBBOE881是是用另外外一种方方法来解解释这两两者的区区别的：验证：“我们是是否正确确地完成成了产品品？”确认：“我们是是否完成成了正确确的产品品？”VV的的定义还还包含了了许多我我们称作作软件质质量保证证(SQQA)的的许多活活动。回忆一下下我们在在第8章章中对软软件质量量的讨论论。为了了获取软软件质量量而必需需的活动动可以看看作是图图17-1中所所描绘的的一些组组成部分分。软件件工程方

6、方法提供供了质量量的基础础，分析析、设计计和构造造(编码码)方法法通过提提供一致致的技术术和可预预测的结结果而帮帮助提高高质量，正式的的技术复复审(跟跟踪检查查)有助助于保证证作为每每一个软软件工程程步骤的的结果而而产生的的工作产产品的质质量。在在这些过过程当中中，测度度和控制制被应用用于软件件配置的的每一个个元素中中。标准准和规程程也有助助于保证证一致性性，而一一个形式式化的SSQA过过程保证证了“整整套质量量思想”的实现现。测试是质质量可以以被评估估更更实际点点说，错错误可以以被发现现的的最后堡堡垒，但但是，测测试不应应当被视视为一个个安全网网。象人人们所说说的那样样，“你你不能测测试质量

7、量。如果果你开始始测试的的时候它它不在那那里，那那么当你你完成测测试的时时候它仍仍然不会会在那里里”。质质量在软软件的整整个过程程中都和和软件结结合在一一起。方方法和工工具的正正确使用用，有效效的正式式技术复复审和可可靠的管管理与测测度都可可以导致致在测试试过程中中得以认认可的质质量。MilllerMILL77把软件件测试和和质量保保证联系系在一起起：“程程序测试试的内在在动机是是使用对对大规模模系统和和小规模模系统都都能节约约地并且且有效地地应用的的方法来来认可软软件的质质量。”需要重点点加以注注意的是是，验证证和确认认包含了了范围很很广的SSQA活活动，其其中包括括正式技技术复审审、质量量

8、和配置置审查、性能监监控、仿仿真、可可行性研研究、文文档复审审、数据据库复审审、算法法分析、开发测测试、质质量测试试和安装装测试WALL89。虽然然测试在在VVV中发挥挥着非常常重要的的作用，但是其其他的活活动也是是必要的的。17.11.2 软件测测试的组组织对每一个个软件项项目来说说，在测测试开始始的时候候总会产产生一些些固有的的利益冲冲突。开开发软件件的人们们现在开开始被要要求对软软件进行行测试。这本身身来说似似乎是无无害的：毕竟，谁能比比开发人人员更了了解这个个软件呢呢？不幸幸的是，这些开开发人员员有很高高的兴趣趣要急于于证明他他们的程程序是毫毫无错误误的，是是按照用用户的需需求开发发的

9、，而而且完全全能够按按照预定定的进度度和预算算完成。这些兴兴趣和认认真地测测试是相相互冲突突的。从心理学学的角度度上来讲讲，软件件分析和和设计(包括编编码)是是建设性性的工作作。软件件工程师师构造一一个计算算机程序序、程序序文档、还有相相关的数数据结构构。和其其他任何何建设者者们一样样，软件件工程师师也对自自己的“大厦”感到非非常骄傲傲，而对对任何试试图摧毁毁其“大大厦”的的人嗤之之以鼻。当测试试开始的的时候，就会存存在一种种微妙的的、但确确实存在在着的、试图要要“摧毁毁”软件件工程师师建立起起来的东东西的企企图。从从开发者者的观点点来看，测试可可以被看看作是(从心理理上来说说)破坏坏性的。所

10、以开开发者只只是简单单地设计计和进行行能够证证明程序序正确性性的测试试，而不不是去尽尽量发现现错误。不幸的的是，错错误是确确确实实实地存在在着的，而且如如果软件件工程师师不能找找到错误误，那么么客户就就会找到到它们。通过上面面的这些些讨论，常常会会导致人人们产生生如下的的误解：(1)软件的的开发人人员根本本不应当当参与测测试；(2)软软件应当当给那些些会无情情地挑毛毛病的陌陌生人来来测试；(3)测试者者只有在在测试的的步骤即即将开始始的时候候才参与与项目。这些想想法都是是错误的的。软件开发发者总是是负责程程序的单单个单元元(模块块)的测测试，保保证每个个单元能能够完成成设计的的功能。在很多多情

11、况下下，开发发者也进进行集成成测试进行行完整的的程序结结构构造造(和测测试)的的步骤。仅仅在在软件体体系结构构完成后后，独立立测试组组织才开开始介入入。独立测试试组织(ITGG)的功功能就是是为了避避免让开开发者来来进行测测试时会会引发固固有问题题。独立立地测试试可以消消除可能能存在的的利益冲冲突。毕毕竟，独独立组织织中的人人员是靠靠找错误误来拿工工资的。然而，软软件开发发人员并并不能把把程序交交给ITTG就一一走了之之，开发发人员和和ITGG在软件件项目中中应当紧紧密合作作，以保保证测试试顺利进进行。而而且在测测试进行行过程中中，那么么开发人人员必须须可以去去修改测测试过程程中发现现的错误误

12、。ITG从从需求说说明过程程开始，参与了了一个大大项目的的整个过过程(计计划和确确定测试试过程)，从这这种意义义上来说说，它是是软件项项目组中中的一部部分。然然而，在在许多情情况下，ITGG是直接接向软件件质量保保证组织织负责的的，这样样它就获获得它作作为软件件开发组组织的一一部分而而可能得得不到的的独立性性。17.11.3 一种软软件测试试策略软件工程程的过程程可以看看作是如如图1772所所示的一一个螺旋旋结构。最初，系统工工程定义义了软件件的功能能，从而而引出了了软件需需求分析析，建立立了软件件的信息息域、功功能、行行为、性性能、约约束和确确认标准准。沿着着螺旋向向内前进进，经过过设计阶阶

13、段，最最终到达达了编码码。为了了开发计计算机软软件，我我们沿着着流线的的螺旋前前进，每每一圈都都会降低低软件的的抽象层层次。软件测试试策略也也可以放放在螺旋旋的语境境里来考考虑(图图17-2)。单元测测试从螺螺旋的漩漩涡中心心开始，它着重重于软件件以源代代码形式式实现的的各个单单元；测测试沿着着螺旋向向外前进进就到了了集成测测试，这这时的测测试则着着重于对对软件的的体系结结构的设设计和构构造；再再沿着螺螺旋向外外走一圈圈，我们们就遇到到了确认认测试，我们要要用根据据软件需需求分析析得到的的需求对对已经建建造好的的系统进进行验证证；最后后，我们们要进行行系统测测试，也也就是把把软件和和其他的的系

14、统元元素放在在一起进进行测试试。为了了对计算算机软件件进行测测试，我我们沿着着螺旋的的流线向向外，每每转一圈圈都扩宽宽了测试试的范围围。从过程的的观点来来考虑测测试的整整个过程程的话，在软件件工程环环境中的的测试事事实上是是顺序实实现的四四个步骤骤的序列列，这些些步骤表表示在图图17-3中。最开始始，测试试着重于于每一个个单独的的模块，以确保保每个模模块都能能正确执执行，所所以，我我们把它它叫做单单元测试试，单元元测试大大量地使使用白盒盒测试技技术，检检查每一一个控制制结构的的分支以以确保完完全覆盖盖和最大大可能的的错误检检查；接接下来，模块必必须装配配或集成成在一起起形式完完整的软软件包，集

15、成测测试解决决的是验验证与程程序构造造的双重重问题，在集成成过程中中使用最最多的是是黑盒测测试用例例设计技技术，当当然，为为了保证证覆盖一一些大的的分支，也会用用一定数数量的白白盒测试试技术；在软件件集成(构造)完成之之后，一一系列高高级测试试就开始始了，确确认标准准(在需需求分析析阶段就就已经确确定了的的)必须须进行测测试，确确认测试试提供了了对软件件符合所所有功能能的、行行为的和和性能的的需求的的最后保保证，在在确认过过程中，只使用用黑盒测测试技术术。最后的高高级测试试步骤已已经跳出出了软件件工程的的边界，而属于于范围更更广的计计算机系系统工程程的一部部分，软软件，一一旦经过过验证之之后，

16、就就必须和和其他的的系统元元素(比比如硬件件、人员员、数据据库)结结合在一一起。系系统测试试要验证证所有的的元素能能正常地地啮合在在一起，从而完完成整个个系统的的功能/性能。17.11.4测测试完成成的标准准每当讨论论软件测测试的时时候都会会引发一一个经典典问题的的讨论：“我们们什么时时候做测测试呢？我们又又怎样才才能知道道我们的的测试已已经足够够了呢？”很遗遗憾的是是，到目目前为止止对这个个问题还还没有一一个确定定性的答答案，但但是还是是有一些些在经验验引导下下的实际际的答案案和早期期的尝试试。对上面问问题的一一个答复复是：“你永远远也不可可能完成成测试，这个重重担将会会简单地地从你(或者开

17、开发人员员)身上上转移到到你的客客户身上上”。每每次客户户/用户户执行一一个计算算机程序序的时候候，程序序就是在在一个新新的数据据集合下下经受测测试的考考验，这这个清醒醒的事实实使得其其他的软软件质量量保证活活动更加加重要。对上面面问题的的另一个个答复是是(有些些讽刺，但无疑疑是准确确的)：“当你你时间不不够或者者资金不不够用的的时候，就完成成了测试试。”虽然很少少有人会会对这些些答复产产生异议议，但是是作为一一个软件件工程师师，需要要有更严严格的标标准来决决定是否否已经进进行了足足够的测测试。MMusaa和AcckerrmannMUUS899提出出了一个个基于统统计标准准的答复复：“不不，我

18、们们不能绝绝对地认认定软件件永远也也不会再再出错，但是相相对于一一个理论论上合理理的和在在试验中中有效的的统计模模型来说说，如果果一个在在按照概概率的方方法定义义的环境境中，110000个CPPU小时时内不出出错的操操作概率率大于00.9995的话话，那么么我们就就有955的信信心说我我们已经经进行了了足够的的测试。”使用概率率论模型型和软件件可靠性性理论，可以建建立一种种作为执执行时间间的函数数软件故故障(在在测试过过程中发发现的错错误)模模型MMUS889。一个称称为对数数泊松执执行时间间模型(loggariithmmic Poiissoonexxecuutioon-ttimee mood

19、ell)的软软件故障障模型为为：f(t)=(11/p)1n(l0pt+11) (17.1)其中f(t)=软件在在一定的的测试时时间t后后，可能能会发生生故障的的预期累累计数目目。l0=在在测试刚刚开始时时的初始始软件故故障密度度(单位位时间内内的故障障数)。p=错误误被发现现和修正正的过程程中故障障密度的的指数递递减值。瞬时的故故障密度度，l(t)可可以使用用f(tt)的导导数得出出，l(t)=l00/(ll0ptt+1) (117.22)使用等式式(177.2)中给出出的关系系，测试试人员可可以预测测测试进进程中错错误的急急剧减少少。实际际的错误误密度可可以画在在预测曲曲线上(图 117-4

20、4)。如如果在测测试过程程中实际际收集的的数据和和对数泊泊松执行行时间模模型能够够在大量量数据下下都相当当好地接接近的话话，那么么这个模模型就可可以用来来预测为为了达到到一个可可以接收收的低故故障密度度，整个个测试过过程所需需要的时时间。通过在软软件测试试过程中中收集数数据和利利用现有有的软件件可靠性性模型，就可能能得到回回答“测测试什么么时候完完成”这这种问题题的有意意义的指指导原则则。毫无无疑问的的是，在在测试的的量化规规则建立立之前仍仍然需要要大量的的进一步步工作，但是，现有经经验理论论总比直直觉要好好不少。17.22策略问问题在本章的的后面部部分，我我们会探探讨一个个软件测测试的系系统

21、化策策略。但但是，如如果无视视一些重重要的问问题的话话，那么么即使是是最好的的策略也也会失败败。 TTom GillbGGIL995指指出如果果要实现现一个成成功的软软件测试试策略的的话，下下面的问问题是必必须涉及及的：在着手开开始测试试之前较较长时间间内，就就要以量量化的形形式确定定产品的的需求。虽然测测试的主主要目的的是找错错误，一一个好的的测试策策略同样样可以评评估其他他的质量量特性，比如可可移植性性、可维维护性和和可用性性(第118章)。这些些应当用用一种可可以测度度的方式式来表示示，从而而保证测测试结果果是不含含糊的。明显地指指出测试试目标。测试的的特定目目标应当当用可以以测度的的术

22、语来来描述。比如，测试有有效性、测试覆覆盖率、故障出出现的平平均时间间、发现现和改正正缺陷的的开销、允许剩剩余的缺缺陷密度度或出现现频率、以及每每次回归归测试的的工作时时间都应应当在测测试计划划中清楚楚地说明明GIIL955。了解软件件的用户户并为每每一类用用户建立立相应档档案通过过着重于于测试产产品的实实际用途途。“使使用实例例”描述每每一类用用户的交交互情况况图(第第20章章)研究究可以减减少整个个测试的的工作量量。建立一个个强调“快速循循环测试试”的测测试计划划。GiilbGILL95建议软软件工程程队伍“学会以以对客户户有用的的功能添添加或/和质量量改进的的快速循循环测试试方法(用百分

23、分之二的的项目开开销)进进行测试试”。从从这些快快速循环环测试中中得到的的反馈可可以用来来控制质质量的级级别和相相应的测测试策略略。设计一个个能够测测试自身身是否“强壮”的软件件。软件件可以使使用反调调试技术术(第117.33.1节节)的方方法来设设计，这这就是说说，软件件应当能能够诊断断特定类类型的错错误，另另外，设设计应当当能够包包括自动动测试和和回归测测试。使用有效效的正式式技术复复审作为为测试之之前的过过滤器。正式技技术复审审(第88章)在在发现错错误方面面可以和和测试一一样有效效，由于于这个原原因，复复审可以以减少为为了得到到高质量量软件所所需的测测试工作作量。使用正式式技术复复审来

24、评评估测试试策略和和测试用用例本身身。正式式的技术术复审可可以发现现在测试试过程中中的不一一致性、遗漏和和完全的的错误。这样可可以节省省时间，同时也也能够提提高产品品的质量量。为测试过过程建立立一种连连续改善善的实现现方法。测试策策略必须须进行测测量，在在测试过过程中收收集的度度量数据据应当被被用作软软件测试试的统计计过程控控制方法法的一部部分。17.33单元测测试单元测试试完成对对最小的的软件设设计单元元模模块的验验证工作作。使用用过程设设计描述述作为指指南，对对重要的的控制路路径进行行测试以以发现模模块内的的错误。测试的的相关复复杂度和和发现的的错误是是由单元元测试的的约束范范围来限限定的

25、。单元测测试通常常情况下下是面向向白盒的的，而且且这个步步骤可以以针对多多个模块块并行进进行。17.33.1单单元测试试考虑作为单元元测试的的一部分分而出现现的测试试在图117-55中用图图形的方方式说明明。对模模块接口口的测试试保证在在测试时时进出程程序单元元的数据据流是正正确的，对局部部数据结结构的检检查保证证临时存存储的数数据在算算法执行行的整个个过程中中都能维维持其完完整性，对边界界条件的的测试保保证模块块在极限限或严格格的情形形下仍然然能够正正确执行行，在控控制结构构中的所所有独立立路径(基本路路径)都都要走遍遍，以保保证在一一个模块块中的所所有语句句都能执执行至少少一次，最后，要对

26、所所有处理理错误的的路径进进行测试试。对穿越模模块接口口的数据据流的测测试需要要在任何何其他测测试开始始之前进进行，如如果数据据不能正正确地输输入和输输出的话话，所有有的其他他测试都都是没有有实际意意义的，MyeersMYEE79在他关关于软件件测试的的文章中中提出了了接口测测试的一一个清单单：1.输入的的形参数数目是否否等于实实参的数数目？2.实参参和形参参的属性性是否匹匹配？3.实参参和形参参的单元元系统是是否匹配配？4.传递递给被调调用模块块的实参参数目是是否等于于形参的的数目？5.传传递给被被调用模模块的实实参属性性是否等等于形参参的属性性？6.传递给给被调用用模块的的实参的的单元系系

27、统是否否等于形形参的单单元系统统？7.传递给给内置函函数的数数值属性性和参数数顺序是是否正确确？8.任何何对参数数的引用用和当前前入口点点是否有有关联？9.只输输入的参参数是否否被改变变了？10.跨跨模块的的全局变变量定义义是否一一致？11.约约束条件件是否作作为参数数传递？当一个模模块执行行外部II/O操操作的时时候，必必须进行行附加的的接口测测试，下下面的列列表仍来来自MyyerssMYYE799：1.文件件属性是是否正确确？2.OPPEN/CLOOSE语语句是否否正确？3.格式式规约是是否和II/O语语句匹配配？4.缓冲冲区大小小是否和和记录大大小匹配配？5.文件件是否在在打开之之前被使

28、使用？6.是否否处理了了文件结结束条件件？7.是否否处理了了I/OO错误？8.在输输出信息息里是否否有文本本错误？模块的局局部数据据结构是是经常出出现的错错误源。应当设设计测试试用例以以发现下下列类型型的错误误：1.不正正确或者者不一致致的类型型描述。2.错误误的初始始化或缺缺省值。3.不正正确的(拼写错错误的或或被截断断的)变变量名字字。4.不一一致的数数据类型型。5.下溢溢、上溢溢和地址址错误。除了局部部数据结结构，全全局数据据对模块块的影响响在单元元测试过过程中也也应当进进行审查查。在单元测测试过程程中，对对执行路路径的选选择性测测试是最最主要的的任务。测试用用例应当当能够发发现由于于错

29、误计计算、不不正确的的比较、或者不不正常的的控制流流而产生生的错误误。基本本路径和和循环测测试是发发现更多多的路径径错误的的一种有有效技术术。其他常见见的错误误有：(1)误误解的或或者不正正确的算算术优先先级；(2)混混合模式式的操作作；(33)不正正确的初初始化；(4)精度不不够精确确；(55)表达达式的不不正确符符号表示示。比较较和控制制流是紧紧密地耦耦合在一一起的(比如，控制流流的转移移是在比比较之后后发生的的)，测测试用例例应当能能够发现现下列错错误：(1)不不同数据据类型的的比较；(2)不正确确的逻辑辑操作或或优先级级；(33)应该该相等的的地方由由于精度度的错误误而不能能相等；(4

30、)不正确确的比较较或者变变量；(5)不不正常的的或者不不存在的的循环中中止；(6)当当遇到分分支循环环的时候候不能退退出；(7)不不适当地地修改循循环变量量。好的设计计要求错错误条件件是可以以预料的的，而且且当错误误真的发发生的时时候，错错误处理理路径被被建立，以重定定向或者者干净地地终止处处理。YYourrdonnYOOU755把这这种方法法叫做反反调试(anttideebuggginng)，不幸的的是，存存在一种种把错误误处理过过程加到到软件中中去，但但从不进进行测试试的倾向向。这里里有一个个现实生生活中的的故事可可以说明明这个问问题：一个交互互式设计计系统按按照合同同进行开开发。在在一个

31、事事务处理理模块中中，开发发人员将将错误处处理信息息“错误误！你不不可能到到达这里里！”加加入到调调用各种种控制流流分支的的一系列列条件测测试之后后。这个个“错误误信息”在用户户培训过过程中被被一个客客户发现现了！在错误处处理部分分应当考考虑的潜潜在错误误有下列列情况：1.对错错误描述述的莫名名其妙。2.所报报的错误误与真正正遇到的的错误不不一致。3.错误误条件在在错误处处理之前前就引起起了系统统异常。4.例外外条件处处理不正正确。5.错误误描述没没有提供供足够的的信息来来帮助确确定错误误发生的的位置。边界测试试是单元元测试的的最后(而且可可能也是是最为重重要的)一个步步骤。软软件通常常是在边

32、边界情况况下出现现故障的的，这就就是说，错误往往往出现现在一个个n元数数组的第第n个元元素被处处理的时时候，或或者一个个i次循循环的第第i次调调用，或或者当允允许的最最大或最最小数值值出现的的时候。使用刚刚好小于于、等于于和刚好好大于最最大值和和最小值值的数据据结构、控制流流、数值值来作为为测试用用例就很很有可能能发现错错误。17.33.2单单元测试试规程单元测试试通常看看成为是是编码步步骤的附附属品。在源代代码级的的代码被被开发、复审、和语法法正确性性验证之之后，单单元测试试用例设设计就开开始了。对设计计信息的的复审可可能能够够为建立立前面讨讨论过的的每一类类错误的的测试用用例提供供指导，每

33、一个个测试用用例都应应当和一一系列的的预期结结果联系系在一起起。因为一个个模块本本身不是是一个单单独的程程序，所所以必须须为每个个单元测测试开发发驱动器器或/和和稳定桩桩(sttub)。单元元测试的的环境如如图 117-66所示。在绝大大多数应应用中，一个驱驱动只是是一个接接收测试试数据，并把数数据传送送给(要要测试的的)模块块，然后后打印相相关结果果的“主主程序”。毫无无错误的的子程序序桩的功功能是替替代那些些隶属于于本模块块(被调调用)的的模块。一个毫毫无错误误的子程程序桩或或“空子子程序”可能要要使用子子模块的的接口，才能做做一些少少量的数数据操作作，并验验证打印印入口处处的信息息，然后

34、后返回。驱动器和和稳定桩桩都是额额外的开开销，这这就是说说，两种种都属于于必须开开发但又又不能和和最终软软件一起起提交的的软件，如果驱驱动器和和稳定桩桩很简单单的话，那么额额外开销销相对来来说是很很低的。不幸的的是，许许多模块块使用“简单”的额外外软件是是不能进进行足够够的单元元测试的的。在这这些情况况下，完完整的测测试要推推迟到集集成测试试步骤时时再完成成。当一个模模块被设设计为高高内聚时时，单元元测试是是很简单单的。当当一个模模块只表表示一个个函数时时，测试试用例的的数量就就会降低低，而且且错误也也就更容容易被预预测和发发现。17.44集成测测试 一个在软软件世界界里初出出茅庐的的年轻人人

35、可能在在所有的的模块都都已经完完成单元元测试之之后会问问这样一一个似乎乎很合理理的问题题：“如如果它们们每一个个都能单单独工作作得很好好，那么么你为什什么要怀怀疑把它它们放在在一起就就不能正正常工作作呢？”当然，这个问问题就在在于“把把它们如如何放在在一起？”接口。数据可可能在通通过接口口的时候候丢失；一个模模块可能能对另外外一个模模块产生生无法预预料的副副作用；当子函函数被联联到一起起的时候候，可能能不能达达到期望望中的功功能；在在单个模模块中可可以接受受的不精精确性在在联起来来之后可可能会扩扩大到无无法接受受的程度度；全局局数据结结构可能能也会存存在问题题还还有很多多，很多多。集成测试试是

36、通过过测试发发现和接接口有关关的问题题来构造造程序结结构的系系统化技技术，它它的目标标是把通通过了单单元测试试的模块块拿来，构造一一个在设设计中所所描述的的程序结结构。通常存在在进行非非增量集集成的倾倾向，也也就是说说，使用用一步到到位的方方法来构构造程序序。所有有的模块块都预先先结合在在一起，整个程程序作为为一个整整体来进进行测试试，然后后的结果果通常是是混乱不不堪！会会遇到许许许多多多的错误误，错误误的修正正也是非非常困难难的，因因为在整整个程序序的庞大大区域中中想要分分离出一一个错误误是很复复杂的。一旦这这些错误误被修正正之后，就马上上会有新新的错误误出现，这个过过程会继继续下去去，而且

37、且看上去去似乎是是个无限限循环的的。增量集成成是一步步到位的的方法的的对立面面。程序序先分成成小的部部分进行行构造和和测试，这个时时候错误误比较容容易分离离和修正正；接口口也更容容易进行行彻底地地测试；而且也也可以使使用一种种系统化化的测试试方法。在下面面的章节节中，将将要讨论论许多不不同的增增量集成成策略。17.44.1自自顶向下下集成自顶向下下的集成成是一种种构造程程序结构构的增量量实现方方法。模模块集成成的顺序序是首先先集成主主控模块块(主程程序)，然后按按照控制制层次结结构向下下进行集集成。隶隶属于(和间接接隶属于于)主控控模块的的模块按按照深度度优先或或者广度度优先的的方式集集成到整

38、整个结构构中去。如图177-7所所示，深深度优先先的集成成首先集集成在结结构中的的一个主主控路径径下的所所有模块块。主控控路径的的选择是是有些任任意的，它依赖赖于应用用程序的的特性，例如，选择最最左边的的路径，模块MM1，M2，和MM5，将会会首先进进行集成成，然后后是M88或者MM6(如果果对M22的适当当的功能能是必要要的)，然后，开始构构造中间间的和右右边的控控制路径径。广度度优先的的集成首首先沿着着水平的的方向，把每一一层中所所有直接接隶属于于上一层层模块的的模块集集成起来来，从图图中来说说，模块块M2，M3和M4首先进进行集成成，然后后是下一一层的MM5，M6，然后后继续。集成的整整

39、个过程程由下列列五个步步骤来完完成：1.主控控模块作作为测试试驱动器器，所有有的稳定定桩替换换为直接接隶属于于主控模模块的模模块。2.根据据集成的的实现方方法(如如深度或或广度优优先)，下层的的稳定桩桩一次一一个地被被替换为为真正的的模块。3.在每每一个模模块集成成的时候候都要进进行测试试。4.在完完成了每每一次测测试之后后，又一一个稳定定桩被用用真正的的模块替替换。5.可以以用回归归测试(第177.4.3节)来保证证没有引引进新的的错误。整个过程程回到第第2步循循环继续续进行，直至这这个系统统结构被被构造完完成。自顶向下下的集成成策略在在测试过过程的早早期主要要验证控控制和决决策点。在一个个

40、好的程程序结构构中，决决策的确确定往往往发生在在层次结结构中的的高层，因此首首先会被被遇到。如果主主控制的的确存在在问题，尽早地地发现它它是很重重要的。如果选选择了深深度优先先集成，软件的的某个完完整的功功能会被被实现和和证明，例如，考虑一一个经典典的事务务性结构构(第114章)，在这这个结构构中，有有一系列列复杂的的交互式式输入要要通过一一条输入入路径请请求、获获得和验验证，这这条输入入路径就就可以用用自顶向向下的方方式来进进行集成成。早期期的对功功能性的的验证对对开发人人员和客客户来说说都是会会增加信信心的。自顶向下下的策略略似乎相相对来说说不是很很复杂，但是在在实践过过程中，可能会会出现

41、逻逻辑上的的问题。最普通通的这类类问题出出现在当当高层测测试需要要首先对对较低层层次的足足够测试试后才能能完成的的时候。在自顶顶向下的的测试开开始的时时候，稳稳定桩代代替了低低层的模模块，因因此，在在程序结结构中就就不会有有重要的的数据向向上传递递，测试试者只有有下面的的三种选选择：(1)把把测试推推迟到稳稳定桩被被换成实实际的模模块之后后再进行行，(22)开发发能够实实现有限限功能的的用来模模拟实际际模块的的稳定桩桩，或者者(3)从层次次结构的的最底部部向上来来对软件件进行集集成。图图17-8给出出了典型型的几种种稳定桩桩类型，从最简简单的(稳定桩桩A)到到最复杂杂的(稳稳定桩DD)。第一种

42、实实现方法法(把测测试推迟迟到稳定定桩被换换成实际际的模块块之后再再进行)使我们们失去了了对许多多在特定定测试和和特定模模块组合合之间的的对应性性的控制制，这样样可能导导致在确确定错误误发生原原因时的的困难性性，并且且会违背背自顶向向下方法法的高度度受限的的本质。第二中中方法是是可行的的，但是是会导致致很大的的额外开开销，因因为稳定定桩会变变的越来来越复杂杂。第三三种方法法，也就就是自底底向上的的测试，将在下下一节加加以讨论论。17.44.2自自底向上上集成自底向上上的测试试，就象象它的名名字中所所暗示的的一样，是从原原子模块块(比如如在程序序结构的的最低层层的模块块)开始始来进行行构造和和测

43、试的的，因为为模块是是自底向向上集成成的，在在进行时时要求所所有隶属属于某个个给定层层次的模模块总是是存在的的，而且且也不再再有使用用稳定桩桩的必要要。自底向上上的集成成策略可可以使用用下列步步骤来实实现：1.低层层模块组组合成能能够实现现软件特特定子功功能的簇簇。2.写一一个驱动动程序(一个供供测试用用的控制制程序)来协调调测试用用例的输输入输出出。3.对簇簇进行测测试。4.移走走驱动程程序，沿沿着程序序结构的的层次向向上对簇簇进行组组合。这样的集集成遵循循在图117-99中说明明的模式式，首先先把所有有的模块块聚集成成三个簇簇1，22，3，然后用用对每一一个簇使使用驱动动器(图图中的虚虚线

44、框)进行测测试，在在簇1和和簇2中中的模块块隶属于于Ma，把驱驱动D1和D2去掉，然后把把这两个个簇和MMa直接连连在一起起。类似似地，驱驱动器DD3也在模模块Mbb集成之之前去掉掉。Maa和Mb最后都都要和模模块Mcc一起进进行集成成，驱动动器的不不同种类类如图117-110所示示。当测试在在向上进进行的过过程中，对单独独的测试试驱动器器的需求求减少了了，事实实上，如如果程序序结构的的最上两两层是自自顶向下下集成的的，那么么所需的的驱动数数目就会会明显的的减少，从而对对簇的集集成会变变得非常常简单。17.44.3回回归测试试每当一个个新的模模块被当当作集成成测试的的一部分分加进来来的时候候，

45、软件件就发生生了改变变。新的的数据流流路径建建立了起起来，新新的I/O操作作可能也也会出现现，还有有可能激激活了新新的控制制逻辑。这些改改变可能能会使原原本工作作得很正正常的功功能产生生错误。在集成成测试策策略的环环境中，回归测测试是对对某些已已经进行行过的测测试的某某些子集集再重新新进行一一遍，以以保证上上述改变变不会传传播无法法预料的的副作用用。在更广的的环境里里，(任任何种类类的)成成功测试试结果都都是发现现错误，而错误误是要被被修改的的，每当当软件被被修改的的时候，软件配配置的某某些方面面(程序序、文档档、或者者数据)也被修修改了，回归测测试就是是用来保保证(由由于测试试或者其其他原因

46、因的)改改动不会会带来不不可预料料的行为为或者另另外的错错误的活活动。回归测试试可以通通过重新新执行所所有的测测试用例例的一个个子集人人工地来来进行，也可以以使用自自动化的的捕获回回放工具具来进行行。捕获获回放工工具使得得软件工工程师能能够捕获获到测试试用例，然后就就可以进进行回放放和比较较。回归归测试集集(要进进行的测测试的子子集)包包括三种种不同类类型的测测试用例例：能够测测试软件件的所有有功能的的代表性性测试用用例。专门针针对可能能会被修修改影响响的软件件功能的的附加测测试。针对修修改过的的软件成成分的测测试。在集成测测试进行行的过程程中，回回归测试试可能会会变的非非常庞大大。因此此，回

47、归归测试集集应当设设计为只只包括那那些涉及及在主要要的软件件功能中中出现的的一个或或多个错错误类的的那些测测试，每每当进行行一个修修改时，就对每每一个程程序功能能都重新新执行所所有的测测试是不不实际的的而且效效率很低低的。17.44.4关关于集成成测试的的讨论关于自顶顶向下和和自底向向上的集集成测试试的相对对优缺点点有许多多人进行行了探讨讨(比如如：BBEI884)，总的的来说，一种策策略的优优点差不不多就是是另一种种策略的的缺点。自顶向向下的方方法的主主要缺点点是需要要稳定桩桩和与稳稳定桩有有关的附附加测试试困难。和稳定定桩有关关的问题题可以被被主要控控制功能能的尽早早测试来来抵消。自底向向上的集集成的主主要缺点点就是“直到最最后一个个模块被被加进去去之后才才能看到到整个程程序的框框架”MYEE79，该缺缺点由简简单的测测试用例例设计和和不用稳稳定桩来来弥补的的。选择一种种集成策策略依赖赖于软件件的特性性，有的的时候还还有项目目的进度度安排。总的来来说，一一种组合合策略(有时候候被称作作是三明明治测试试)可能能是最好好的折衷衷：在程程序结构构的高层层使用自自顶向下下策略，而在下下面的较较低层中中使用自自底向上上策略。