软件测试策略

bigmushroom

http://www.51testing.com/html/97/n-231997.html
　软件测试策略把软件测试用例的设计方法集成到一系列已经周密计划过的步骤中去，从而使得软件的开发得以成功的完成。同样重要的是，软件测试策略为软件开发人员、质量保证组织、和客户提供了一个路线图——这个路线图描述了测试的步骤，以及当这些步骤在计划和实施的过程中，需要多少工作量、时间、和资源。因此，任何测试策略都必须和测试计划、测试用例设计、测试执行、还有测试结果数据的收集与分析结合在一起。

　　一种软件测试策略应当具备足够的灵活性，这样在必要的时候它能够有足够的创造性和可塑性来应付所有的大软件系统。与此同时，软件测试策略还必须保证足够的严格，这样才能保证对项目的整个进程进行合理的计划和跟踪管理。Shooman［SHO83］对这个问题进行了探讨：

　　在许多情况下，测试是一个独立的过程，不同的测试类型的数量和不同的开发方法是一样多。许多年以来，我们对付程序出错的唯一武器就是谨慎的设计，以及程序员个人的智慧。我们现在处于这样的一个时代——现代设计技术（和正式的技术复审）正在帮助我们减少代码中存在的初始错误。类似地，不同的测试方法正在开始聚合为有限的几种方法和思想。

　　这些方法和思想就是我们所说的策略。

　　1、软件测试的策略途径

　　测试是一系列可以事先计划并且可以系统地进行管理的活动。正是由于这个原因，应当为软件工程过程定义一个软件测试的模板——即我们可以把特定的测试用例设计方法放置进去的一系列步骤。

　　人们已经提出了许多软件测试策略，所有这些策略都为软件开发人员提供了一个供测试用的模板，而且它们都包含下列的类属特征：

　　● 测试开始于模块层②，然后“延伸”到整个基于计算机的系统集合中。

　　● 不同的测试技术适用于不同的时间点。

　　● 测试是由软件的开发人员和（对大型系统来说）独立的测试组来管理的。

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

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

　　1.1 验证和确认

　　软件测试是我们通常所讲的一个更为广泛的话题验证和确认（Verification and Validation，V＆V）的一个部分。验证指的是保证软件正确地实现了某一特定功能的一系列活动。确认指的则是保证软件的实现满足了用户需求的一系列活动。Boehm［BOE81］是用另外一种方法来解释这两者的区别的：

　　验证：“我们是否正确地完成了产品？”

　　确认：“我们是否完成了正确的产品？”

　　V＆V的定义还包含了许多我们称作软件质量保证（SQA）的许多活动。

　　回忆一下我们在第8章中对软件质量的讨论。为了获取软件质量而必需的活动可以看作是图17－1中所描绘的一些组成部分。软件工程方法提供了质量的基础，分析、设计和构造（编码）方法通过提供一致的技术和可预测的结果而帮助提高质量，正式的技术复审（跟踪检查）有助于保证作为每一个软件工程步骤的结果而产生的工作产品的质量。在这些过程当中，测度和控制被应用于软件配置的每一个元素中。标准和规程也有助于保证一致性，而一个形式化的SQA过程保证了“整套质量思想”的实现。

　　测试是质量可以被评估——更实际点说，错误可以被发现——的最后堡垒，但是，测试不应当被视为一个安全网。象人们所说的那样，“你不能测试质量。如果你开始测试的时候它不在那里，那么当你完成测试的时候它仍然不会在那里”。质量在软件的整个过程中都和软件结合在一起。方法和工具的正确使用，有效的正式技术复审和可靠的管理与测度都可以导致在测试过程中得以认可的质量。

　　Miller［MIL77］把软件测试和质量保证联系在一起：“程序测试的内在动机是使用对大规模系统和小规模系统都能节约地并且有效地应用的方法来认可软件的质量。”

　　需要重点加以注意的是，验证和确认包含了范围很广的SQA活动，其中包括正式技术复审、质量和配置审查、性能监控、仿真、可行性研究、文档复审、数据库复审、算法分析、开发测试、质量测试和安装测试［WAL89］。虽然测试在V＆V中发挥着非常重要的作用，但是其他的活动也是必要的。
　

bigmushroom

虽然很少有人会对这些答复产生异议，但是作为一个软件工程师，需要有更严格的标准来决定是否已经进行了足够的测试。Musa和Ackerman［MUS89］提出了一个基于统计标准的答复：“不，我们不能绝对地认定软件永远也不会再出错，但是相对于一个理论上合理的和在试验中有效的统计模型来说，如果一个在按照概率的方法定义的环境中，1000个CPU小时内不出错的操作概率大于0。995的话，那么我们就有95％的信心说我们已经进行了足够的测试。”

　　使用概率论模型和软件可靠性理论，可以建立一种作为执行时间的函数软件故障（在测试过程中发现的错误）模型［MUS89］。一个称为对数泊松执行时间模型（logarithmic Poissonexecution－time model）的软件故障模型为：

　　f（t）＝（1/p）1n（l0pt+1） （17。1）

　　其中f（t）＝软件在一定的测试时间t后，可能会发生故障的预期累计数目。

　　l0＝在测试刚开始时的初始软件故障密度（单位时间内的故障数）。

　　p＝错误被发现和修正的过程中故障密度的指数递减值。

　　瞬时的故障密度，l（t）可以使用f（t）的导数得出，

　　l（t）＝l0/（l0pt+1） （17。2）

　　使用等式（17。2）中给出的关系，测试人员可以预测测试进程中错误的急剧减少。实际的错误密度可以画在预测曲线上。如果在测试过程中实际收集的数据和对数泊松执行时间模型能够在大量数据下都相当好地接近的话，那么这个模型就可以用来预测为了达到一个可以接收的低故障密度，整个测试过程所需要的时间。

　　通过在软件测试过程中收集数据和利用现有的软件可靠性模型，就可能得到回答“测试什么时候完成”这种问题的有意义的指导原则。毫无疑问的是，在测试的量化规则建立之前仍然需要大量的进一步工作，但是，现有经验理论总比直觉要好不少。

　　2、策略问题

　　在本章的后面部分，我们会探讨一个软件测试的系统化策略。但是，如果无视一些重要的问题的话，那么即使是最好的策略也会失败。 Tom Gilb【GIL95】指出如果要实现一个成功的软件测试策略的话，下面的问题是必须涉及的：

　　在着手开始测试之前较长时间内，就要以量化的形式确定产品的需求。虽然测试的主要目的是找错误，一个好的测试策略同样可以评估其他的质量特性，比如可移植性、可维护性和可用性。这些应当用一种可以测度的方式来表示，从而保证测试结果是不含糊的。

　　明显地指出测试目标。测试的特定目标应当用可以测度的术语来描述。比如，测试有效性、测试覆盖率、故障出现的平均时间、发现和改正缺陷的开销、允许剩余的缺陷密度或出现频率、以及每次回归测试的工作时间都应当在测试计划中清楚地说明【GIL95】。

　　了解软件的用户并为每一类用户建立相应档案通过着重于测试产品的实际用途。“使用实例”——描述每一类用户的交互情况图研究可以减少整个测试的工作量。

　　建立一个强调“快速循环测试”的测试计划。Gilb【GIL95】建议软件工程队伍“学会以对客户有用的功能添加或/和质量改进的快速循环测试方法（用百分之二的项目开销）进行测试”。从这些快速循环测试中得到的反馈可以用来控制质量的级别和相应的测试策略。

　　设计一个能够测试自身是否“强壮”的软件。软件可以使用反调试技术的方法来设计，这就是说，软件应当能够诊断特定类型的错误，另外，设计应当能够包括自动测试和回归测试。

　　使用有效的正式技术复审作为测试之前的过滤器。正式技术复审在发现错误方面可以和测试一样有效，由于这个原因，复审可以减少为了得到高质量软件所需的测试工作量。

　　使用正式技术复审来评估测试策略和测试用例本身。正式的技术复审可以发现在测试过程中的不一致性、遗漏和完全的错误。这样可以节省时间，同时也能够提高产品的质量。

　　为测试过程建立一种连续改善的实现方法。测试策略必须进行测量，在测试过程中收集的度量数据应当被用作软件测试的统计过程控制方法的一部分。

bigmushroom

1.2 软件测试的组织

　　对每一个软件项目来说，在测试开始的时候总会产生一些固有的利益冲突。开发软件的人们现在开始被要求对软件进行测试。这本身来说似乎是无害的：毕竟，谁能比开发人员更了解这个软件呢？不幸的是，这些开发人员有很高的兴趣要急于证明他们的程序是毫无错误的，是按照用户的需求开发的，而且完全能够按照预定的进度和预算完成。这些兴趣和认真地测试是相互冲突的。

　　从心理学的角度上来讲，软件分析和设计（包括编码）是建设性的工作。软件工程师构造一个计算机程序、程序文档、还有相关的数据结构。和其他任何建设者们一样，软件工程师也对自己的“大厦”感到非常骄傲，而对任何试图摧毁其“大厦”的人嗤之以鼻。当测试开始的时候，就会存在一种微妙的、但确实存在着的、试图要“摧毁”软件工程师建立起来的东西的企图。从开发者的观点来看，测试可以被看作是（从心理上来说）破坏性的。所以开发者只是简单地设计和进行能够证明程序正确性的测试，而不是去尽量发现错误。不幸的是，错误是确确实实地存在着的，而且如果软件工程师不能找到错误，那么客户就会找到它们。

　　通过上面的这些讨论，常常会导致人们产生如下的误解：

　　（1）软件的开发人员根本不应当参与测试；

　　（2）软件应当给那些会无情地挑毛病的陌生人来测试；

　　（3）测试者只有在测试的步骤即将开始的时候才参与项目。这些想法都是错误的。

　　软件开发者总是负责程序的单个单元（模块）的测试，保证每个单元能够完成设计的功能。在很多情况下，开发者也进行集成测试——进行完整的程序结构构造（和测试）的步骤。仅仅在软件体系结构完成后，独立测试组织才开始介入。

　　独立测试组织（ITG）的功能就是为了避免让开发者来进行测试时会引发固有问题。独立地测试可以消除可能存在的利益冲突。毕竟，独立组织中的人员是靠找错误来拿工资的。

　　然而，软件开发人员并不能把程序交给ITG就一走了之，开发人员和ITG在软件项目中应当紧密合作，以保证测试顺利进行。而且在测试进行过程中，那么开发人员必须可以去修改测试过程中发现的错误。

　　ITG从需求说明过程开始，参与了一个大项目的整个过程（计划和确定测试过程），从这种意义上来说，它是软件项目组中的一部分。然而，在许多情况下，ITG是直接向软件质量保证组织负责的，这样它就获得它作为软件开发组织的一部分而可能得不到的独立性。

　　1.3 一种软件测试策略

　　软件工程的过程可以看作是一个螺旋结构。最初，系统工程定义了软件的功能，从而引出了软件需求分析，建立了软件的信息域、功能、行为、性能、约束和确认标准。沿着螺旋向内前进，经过设计阶段，最终到达了编码。为了开发计算机软件，我们沿着流线的螺旋前进，每一圈都会降低软件的抽象层次。

　　软件测试策略也可以放在螺旋的语境里来考虑。单元测试从螺旋的漩涡中心开始，它着重于软件以源代码形式实现的各个单元；测试沿着螺旋向外前进就到了集成测试，这时的测试则着重于对软件的体系结构的设计和构造；再沿着螺旋向外走一圈，我们就遇到了确认测试，我们要用根据软件需求分析得到的需求对已经建造好的系统进行验证；最后，我们要进行系统测试，也就是把软件和其他的系统元素放在一起进行测试。为了对计算机软件进行测试，我们沿着螺旋的流线向外，每转一圈都扩宽了测试的范围。

　　从过程的观点来考虑测试的整个过程的话，在软件工程环境中的测试事实上是顺序实现的四个步骤的序列，这些步骤表示在图17－3中。最开始，测试着重于每一个单独的模块，以确保每个模块都能正确执行，所以，我们把它叫做单元测试，单元测试大量地使用白盒测试技术，检查每一个控制结构的分支以确保完全覆盖和最大可能的错误检查；接下来，模块必须装配或集成在一起形式完整的软件包，集成测试解决的是验证与程序构造的双重问题，在集成过程中使用最多的是黑盒测试用例设计技术，当然，为了保证覆盖一些大的分支，也会用一定数量的白盒测试技术；在软件集成（构造）完成之后，一系列高级测试就开始了，确认标准（在需求分析阶段就已经确定了的）必须进行测试，确认测试提供了对软件符合所有功能的、行为的和性能的需求的最后保证，在确认过程中，只使用黑盒测试技术。

　　最后的高级测试步骤已经跳出了软件工程的边界，而属于范围更广的计算机系统工程的一部分，软件，一旦经过验证之后，就必须和其他的系统元素（比如硬件、人员、数据库）结合在一起。系统测试要验证所有的元素能正常地啮合在一起，从而完成整个系统的功能/性能。

　　1.4 测试完成的标准

　　每当讨论软件测试的时候都会引发一个经典问题的讨论：“我们什么时候做测试呢？我们又怎样才能知道我们的测试已经足够了呢？”很遗憾的是，到目前为止对这个问题还没有一个确定性的答案，但是还是有一些在经验引导下的实际的答案和早期的尝试。

　　对上面问题的一个答复是：“你永远也不可能完成测试，这个重担将会简单地从你（或者开发人员）身上转移到你的客户身上”。每次客户/用户执行一个计算机程序的时候，程序就是在一个新的数据集合下经受测试的考验，这个清醒的事实使得其他的软件质量保证活动更加重要。对上面问题的另一个答复是（有些讽刺，但无疑是准确的）：“当你时间不够或者资金不够用的时候，就完成了测试。”