如我在本文中提到的，系统测试是在将软件产品交付给客户使用之前完成的最终产品测试。此测试一般在完成开发和功能验证测试之后进行。某些入口标准用来确定对于系统测试的代码准备状态（举例来说 ， 回归状态，缺陷后备，等等）。必须达到这些标准，从而正式地开始系统测试并要求结果。

在一般的系统测试中，目标是用类似客户的配置在高压下对系统进行类似客户的工作量（举例来说，多平台、多软件版本，等等）。 正式的系统测试执行包含压力、寿命期运行、内存泄漏分析、多应用程序、复杂且各种各样的拓扑、高可用性及中断测试、混合的版本测试、全平台测试、产品集成测试，及文档测试。

本文介绍了团队所采用的将一组系统测试子集作为敏捷开发环境的一部分，并与代码开发活动并行的方法。我们将展示出我们的方法可以交付更好的系统测试应用程序，让实验方法将包含与代码开发并行的系统测试子集的价值和效率最大化，并提高团队的沟通和技能。这些成功 导致 （led） 了在完整的系统测试开始时改进了的完整的 软件验证团队（ SVT ） 的加速的时间，以及改进了的产品质量的预期好处。

在六个迭代中，系统测试核心团队与开发团队并行工作。这能够让传统的系统测试应用程序的子集的开发和执行在每个迭代的过程中执行。该并行导致了此处描述的各个方面的成功。

敏捷的过程实现模型

在开发的一年之后，使用现有的瀑布实践并交付开放的 alpha 和 beta，我们的项目转换了工具，并实现敏捷的开发模型。整个团队需要将敏捷的开发原则作为“现场实验”，从而满足特定客户的需求。第一个迭代是过渡的，通常着重于交付在瀑布开发模型下开发了几个月的代码。当第一个迭代开始时，整个团队包括大约五十五个人，包括设计人员、开发人员、测试人员、信息开发人员和客户交付团队。

迭代 1 用作过渡的迭代，用于完成已经处于开发中的可交付件。敏捷开发过渡适当地启动，并且带有对前一或两个迭代的适度的开发承诺。主要的焦点在于在团队和集成的过程之间构建并交流新的项目和人与人之间的文化，例如，并行的早期系统测试，这将会用于在新的环境中令团队成功。

九个系统测试人员（整个系统测试团队的子集）在先前的瀑布开发周期中兼职参与。在开发代码的过程中，他们关注构建技术技能、计划、测试案例开发，和应用程序单元测试。这样做，他们练就了项目所用的技术中的技能，但没有获得内行的经验。

当转变为敏捷开发时，九个系统测试人员中的五个全职参与项目。因此，在第一个迭代之前，系统测试团队已经了解了新技术，创建了测试应用程序，并且像团队一样一起工作。这些早期的测试及开发活动令敏捷周期的开始有更高的生产率。

系统测试团队参与的目的

五个系统测试人员面临的挑战是确保代码质量足以达到在任一已知的迭代中开发的功能的 beta 级交付。为了迎接这个挑战，他们决定在每个迭代中运行传统的系统测试应用程序开发和执行的子集，预期最终的迭代进行一组更复杂的具体客户的，基于场景的测试。系统测试团队与项目的高级架构师会面，并一起为了增强和执行选择一个现有的系统测试应用程序。然后，该应用程序将用于在迭代过程中的压力和寿命期运行，并且在最终的迭代里大量地使用。目的是在项目最终在世界范围内交付时，系统测试人员有限且同时的参与会为最终的完全的系统测试迭代建立起坚固的基础。

项目和迭代的时间线

迭代有六个星期之久。表 1 显示了一般的迭代规划，以及为每个星期计划的具体的系统测试活动。在迭代的第 1 周中，高级架构师提出建议的候选功能列表。该列表主要基于具体客户的需求，并且通过用例进行描述。该列表可在线访问，以便在迭代进行中，所有的团队成员都可以改进用例。每个团队成员都会审查候选的列表，并与团队成员和高级架构师一起讨论设计及问题，并且在周末提交在迭代结束时（是否）要交付的功能。每天举行一个小会。高级架构师每天都出席大部分小会议，并且在所有迭代过程中都与全部团队成员在一起。

如前面所提到的，最后的迭代计划着重于在开发迭代中不能实现的最终的缺陷清理和复杂的测试。为了提高稳定性，最后的迭代没有新的功能。六个迭代完成了。同时，在最后的迭代中，大量的开发人员需要加入系统测试团队成员中，通过提供对测试执行和调试的辅助来完成最终的迭代。其余的开发人员会处理缺陷。这意味着在较早的迭代中的开发阶段里，一些开发人员需要为了最后的迭代而培训系统测试的知识。

表 1：每个迭代的活动：开发和系统测试

成功

在此我们将开始讨论一些实现了的重要成功、遇到的挑战，及与敏捷的系统测试活动相关的对比的好处。让我们从成功开始讨论。

更健壮且更实际的系统测试应用程序

敏捷的开发周期从客户开始。为了了解商业目标、IT 策略、应用方向，和优先级，架构师经常和客户会见。系统测试团队分析迭代的测试用例，并根据作为外部客户的关键的用例的子集设计测试应用程序的增强。如果测试应用程序增强是大规模的，那么就在先前的迭代中开发那些增强，从而给测试应用程序的开发留出时间。如果可以快速地完成应用程序的增强，那么就在当前的迭代中开发它们。

在第 2 周中，系统测试团队向架构师提出应用程序的设计增强。这会形成向系统测试团队提供机会来结合架构师的建议的对话。它还向架构师提供他们没考虑过的系统测试的观点，而有时，这会导致产品设计的变更。由于系统测试团队与架构师和开发团队有密切的合作关系，所以系统测试人员对客户的需求的了解深入得多。

将小型的系统测试团队与开发活动并行令系统测试团队能够以增量的方式开发更健壮“类似客户的”测试应用程序。这是比历史上在瀑布开发周期中进行的更实际的方法，因为它允许系统测试团队参与可交付件的创建，而不是在短暂的时间内，被迫消耗，并测试大量可交付件。敏捷的开发周期允许系统测试团队扮演实际的客户，从应用程序设计到系统测试应用程序的编码和单元测试。

开发和系统测试团队之间更密切的交流

由敏捷开发实践的采用及系统测试活动的加入所带来的重大好处是，开发和系统测试团队之间通过参与每日的会议而进行的更频繁且更深入的交流。因此，系统测试团队可以洞察会影响测试计划和/或测试应用程序的当前的构建问题、最近发现的缺陷、设计修改等等。当系统测试人员报告在并行的系统测试中发现的问题时，小会议也给开发团队带来好处。每日的会议交流允许系统测试向整个观众简要地描述可能需要多个开发人员协作或了解的问题。最终，会议允许开发指出什么时候系统测试方法与当前的代码基础功能不一致。

开发和系统测试之间的密切交流的另一个重要好处是，当新的功能首次出现在一个构建中时，系统测试团队可以立即注意到。对可用功能的交流是至关重要的，因为每个迭代中只有三个星期是执行系统测试应用程序的设计、编码，和单元测试的。这是重要的，因为系统测试有时为该迭代并行地开发测试应用程序及产品功能。记住，系统测试会令对测试应用程序及单元测试的增强的改进非常快速。因为系统测试及时地收到了构建中存在所需功能的通知，所以他们能够尽可能快地执行应用程序测试。

架构师、开发人员，和系统测试人员之间的密切交流令整个团队得益于许多观点和建议，提高代码质量和完整性。

较深入的系统测试技能

在敏捷的开发周期中加入系统测试子集的另一个优点是它促进较深入的系统测试应用程序开发和测试技能。在发布周期的较早期，将这一较小的“核心”系统测试团队指派到项目中。敏捷的开发周期的迭代特性令系统测试团队以较小的且更容易消费的规模在较长的时间内理解产品。

贯穿迭代的系统测试的连续子集

在所有的迭代过程中都执行系统测试的子集，即使每个迭代的系统测试时间都是有限的。在测试过程中，使用各种自动化的技术来启用压力/负载测试、内存泄漏分析、数据完整性测试，和回归测试。压力/负载工具允许系统测试在指定的持续时间内在模拟的客户量下运行测试应用程序。执行脚本获取浏览器动作（这些会被回放），允许执行自动的实施。这些脚本还允许生成随机的数据，这模拟了不同的客户交互。相关的配置脚本允许测试人员为每次执行指定所期望的持续时间和模拟客户的数量。他们通过定期查看产品日志，以及压力工具的日志来监控运行进展。压力工具还生成统计，这提供了潜在的问题及意外活动的指示。压力工具在第一个迭代之后的每个测试运行中都会用到。

伴随代码稳定性，及进行寿命期测试运行的能力的成功导致了以第三个迭代开始的迭代完成时，增加内存泄漏分析。在每个测试之前，系统测试人员配置许多产品参数来允许在测试过程中收集内存泄漏分析信息。在每次运行之后，他们会将运行的日志输入到内存泄漏分析工具中。工具会生成一组图，查看在运行过程中的内存使用，并检查内存泄漏的指示。如果发现了内存泄漏，那么会打开并追踪故障报告。一旦最终的执行在无问题的情况下完成，那么测试人员就会在测试追踪工具的完成记录中加入信息，指示最终的内存泄漏分析的结果。

数据完整性测试也在一些测试场景中进行，从而确保系统测试的子集的执行。测试应用程序严重依赖于 IBM? DB2? 来进行数据持久化。应用程序包含一组更新应用程序数据库中相同表的事务工作负载。这些事务工作负载是同时运行的，因此推动负载并有意地创建数据库争用。目的在于强迫事务回滚，这样系统测试人员可以确保成功地完成恢复。当试图对已上锁的记录进行更新时，事务回滚并在稍后重新执行。在执行完成时，所有的数据库活动都完成了，并且不得不使所有的事务都一致。测试应用程序中嵌入了数据库一致性检查。应用程序持久化了的数据在其使用的一组表中有相关的值。在执行的末尾，测试人员运行一组额外的测试来检验每个应用程序的表中的数据与彼此一致。

回归测试也用于以第二个迭代开始的迭代开发中。通过在当前的构建上为当前的迭代运行先前的系统测试应用程序的迭代版本，在每个迭代执行迭代的回归测试。随着我们进入后面的迭代，这些测试执行快速地成为早期的同时的测试执行的集合。这令在迭代过程中确定并处理回归缺陷，而不是像瀑布模型那样，在测试的结尾。

因此，即使敏捷的版本周期包含一系列相关的短迭代，仍旧能够执行系统测试的子集。由于团队利用大量的自动化功能，因此压力/负载测试、内存泄漏分析、数据完整性测试，和回归测试都将执行。这些类型的测试提供了模拟的客户环境中的产品代码稳定性置信度。

在产品周期早期除去的缺陷

因为在迭代过程中，系统测试执行回归、压力，和持续时间执行，所以在缺陷注入不久就被确定并除去了。由于产品代码在开发人员心里是新写的，所以系统测试可以收到来自开发的立即的修复。在敏捷的环境中，系统测试更容易检验修补，由于缺陷周转时间较快，并且由于准确的测试环境仍旧适当。因为工作在相同时间的相同用例上，开发人员和系统测试人员有相同的优先权，由此开发人员和系统测试人员之间的协作较好。这便于缺陷更快地确定、修复，及检验。

较早的迭代测试初始且较基本的产品功能。此次，系统测试应用程序还是基本且较简单的，然而，为了找到缺陷，能够在特定压力级别和持续时间内运行。后续的迭代引入了增加的产品功能和更复杂的产品配置。系统测试应用程序的功能和复杂度也增加了。在后继的迭代中，压力的等级和测试持续时间增加了。一般，在这些后继的迭代中可以找到更复杂的缺陷，但仍旧非常接近于注入产品的时间。

一般来说，在敏捷的开发周期中对系统测试缺陷的开发关注较多。这导致了较早地检测出缺陷，并且更快地缺陷修复周转时间。

过程演进

敏捷开发本身虑及了连续的增强。在迭代的末尾有一个“了解到的经验”的会话，让所有的参与者确定问题区域，并建议整体的改进和效率。

敏捷模型的一个关键特征是开发过程应该演进。这对所有与产品交付件相关的团队来说都是正确的，包括系统测试。在每个迭代中都实现了关于如何提高生产力的洞察。每个团队被要求提供他们关于了解到什么及可以提高什么的想法。整个团队开会并讨论每一个痛处或成功点。在该对话中，确定出额外的改进，从在线存储库中获得，并集成到下一个迭代中。

与系统测试相关的过程演进的一个具体实例发生在第一个迭代期间，在该迭代中，系统测试团队形式化一个用于测试追踪的过程。在过去，测试追踪工具用于定义系统测试场景及编档测试执行结果。在迭代 1 中，系统测试团队为那些测试场景定义模板，并且创建公共的配置文档。这些配置文档允许系统测试团队详述由一个公共的文档源安装并执行公告的系统测试规程所必要的步骤。这个独立的定义令个别的测试人员能够避免创建并维护重复的文档。所有相关的测试场景都指向公共的文档。

系统测试团队如何增量地改进他们的过程的另一个实例出现在内存泄漏分析被引入到迭代 3 中时，而不是等到最后的，只进行系统测试的迭代。如前面提到的，该变更是可能的，由于代码的稳定性。公共的配置文档中加入了必要的工具和安装说明，这是每个计划的测试场景所参考的。同样，测试完成的详情包括每次运行后的内存泄漏分析的结果。

系统测试团队定义约定及编写良好的过程，来帮助实现可重复的且一致的测试。在开始项目的测试工作之前，许多改进都还不为人知或未定义。一些想法基于“发现”，而其他的纯粹来源于对随后迭代的生产力提高的期望。“所了解的经验”的频率及对模型灵活性的关注令整个团队避免较早的痛处，提高效率，并试用解决方案。

停船识别

从迭代 3 开始，系统测试团队推动停船场景的识别。从迭代 4 开始，在迭代承诺会议过程中，系统测试团队的场景分类为停船货非停船。为了成功地完成迭代，所有的停船场景必须在没有缺陷或补丁的情况下成功运行。停船测试场景一般是那些在前面的迭代执行，并作为归回场景转到当前迭代的测试案例。这些测试场景还组合形成了一组同时执行的测试。比起较早的迭代，这些组合的测试一般在较高的负载下执行，并且还至少执行二十四小时。

非停船的测试场景一般基于需要在后来的迭代中交付的客户需求，但基于当前迭代中正在开发的功能。这允许在功能验证完成之后不久执行最初的系统测试和问题确定。敏捷环境中的这种附加的灵活性令复杂的问题得以确定、隔离、追踪、修补，并在跨多个迭代的时间段里在系统测试环境中执行。

系统测试团队在测试追踪工具中区别停船和非停船测试场景。在迭代的第 1 周中的承诺会议上，高级架构师指导将每个承诺划分为停船和非停船的。那些分类记录于在线承诺页上，并随后当为每个承诺创建测试执行记录时使用。对于停船场景，测试阶段有在迭代的系统测试周期末尾的完成日期，发生在第 5 和 6 周。非停船场景遍及多个迭代，但在最终迭代中，所有余下的非停船场景都成为停船场景。通过允许当未预期的问题出现时应用附加的资源，以较低优先级的测试场景为代价，测试场景之间的差别帮助管理风险。这令迭代交付按计划完成，但需要对非停船场景后备的小心管理。

挑战

以下是在敏捷系统测试活动中面临的一些最重要的挑战。

短迭代

系统测试场景的回归测试发生在第 2 到 6 的迭代周中。在第 2 到 4 周中，系统测试还需要提高并单元测试系统测试应用程序，以便它可以用于第 5 和 6 周中的新功能的测试。

对于新功能的系统测试场景的执行只发生在第 5 和 6 周。这种时间长度证明，当在后面的迭代中系统测试运行更加复杂时，在这种“现场试验”过程中，对场景的子集进行测试是种挑战。举例来说，在测试需要更复杂的拓扑，以及比三天更长的持续时间，和/或伴随中断和故障测试的复杂工作负载的情况下，在分配的时间内包含这些复杂的场景是困难的。这些较复杂的场景趋于暴露出较困难的故障，它们更难调试，并且有时是间歇的。用追踪重新创建这些类型的缺陷是耗费时间的，因为我们应用补丁并检验集成到驱动程序中的修复。在分配给少量测试人员的情况下，这是非常困难的。因此，一些较复杂的场景和缺陷需要跨迭代。

即使只有一个应用程序用于应用程序开发和场景执行，应用程序开发还是耗费迭代中的大量时间。通过为了对应用程序进行一些功能增强而扩展到两个迭代，在一个迭代进行应用程序开发而当需要时在以后的迭代中执行场景，来部分地减少浪费。

另一个挑战是迭代结果审查和演示的计时。在第 6 周，系统测试团队向整个团队提出他们的迭代结果。在一些迭代中，最后一周没有完成测试，从而提出结果，并且系统测试结果的提出需要移动到后继迭代的第 1 周。同样，有时系统测试团队负责一部分向产品管理层的演示，从而显示迭代的可交付件。这些演示需要大量的准备，而在后面的迭代中系统测试团队的参与更困难。

另一个使得第 5 和 6 周非常具有挑战的因素是系统测试需要培训开发人员进行系统测试的执行，以便那些开发人员在后面的迭代中可以辅助系统测试。然而，这需要有经验的系统测试人员来指导那些在特殊的迭代中分派到系统测试的开发人员，增加完成计划的系统测试承诺的难度。由于这涉及对于不熟悉系统测试的开发人员大约 1-2 周的学习曲线，所以如果将同样的开发人员分派到多个连续迭代的系统测试中才可以实现系统测试的好处，这不总是可能的。

第一个敏捷开发经验

对于大部分团队成员来说，该项目是敏捷开发中的首次经历，对于该项目，开发和系统测试活动的并行对团队的每个人都是陌生的。系统测试团队的五个人比预期超时工作。在项目过程中，每个人，包括系统测试团队成员，都了解如何估量每个迭代的设计、开发，和测试任务。过度承诺或错误的估计对系统测试团队，以及整个团队的其他成员产生了压力。

用例

在敏捷的周期早期需要定义并实现跨迭代的用例的标准化命名约定。为了确保系统测试团队不忘记任何用例，并且让所有团队都能够清楚地辨别每个用例，拥有一贯地使用的（从第一个迭代到最后的迭代）标准化的“用例标识符”是有帮助的。

模板用于一贯地编制跨整个团队的用例。虽然用例的概念对整个团队不是全新的，但是根据外部的客户价值陈述用例对大部分团队成员来说是陌生的。因此，由于迭代末尾的“所了解的经验的”反馈（其中包含来自整个团队的反馈，包括客户交付团队），用例描述的模板和用词不断地变化。

在项目过程中，客户文档是格式化的用例文档。由于系统测试不能得到标准的外部客户级文档，因此系统测试团队不能测试这类客户文档。如果该标准的产品文档在未来生成，那么它需要额外的测试工作。

好处

以下是与敏捷的系统测试工作相关的具体好处。

较好的系统测试应用程序

由于在许多迭代过程中一系列的连续增强，所开发的系统测试应用程序拥有较高的质量。当进行所有这些改进时，应用程序的许多其他方面也改进了，包括执行的验证、提供的日志，及异常处理。由于在许多月内进行开发，所以测试应用程序更加健壮，这与在传统的，集中的测试准备阶段中开发的相反。

提高了的全部系统测试的加速时间

在敏捷的环境中，与开发密切合作的核心系统测试团队向开发组织提供了重大的潜在好处。核心团队可以为在产品发布之前在最终系统测试时的使用而生成系统测试应用程序、场景，和自动脚本的子集。与开发并行地创建并执行这些资料将帮助让较广大的系统测试团队生产的更快。

出于技能转移的立场，系统测试核心团队在适当的时候可以向较广大的系统测试团队介绍新的技术和版本内容。核心团队可以提出类似客户的应用程序设计，并向广大的团队演示应用程序，同时提供所开发的文档、已建立的开发联系的指示，因而提高全部系统测试迭代的加速时间。

在全部系统测试开始时的提高了的产品质量

因为系统测试核心团队在产品开发周期的早期执行系统测试的子集，所以在正式进入完全的系统测试时应该提高代码质量，这必定影响较广的系统测试团队的生产力。此外，利用参与早期系统测试活动的系统测试核心团队的发布周期（在其后，产品发布之前，进行集中的完全的系统测试）可以提供与传统的开发/测试方法相比，提高了的质量。注意写到此时，最终的系统测试迭代还没有开始。在开发迭代中，由于系统测试核心团队早期的测试，与压力相关的及内存泄漏缺陷的子集在正式的系统测试开始之前就被除掉了。

结束语

本文所讨论的项目是小型的。它包含大约五十五个人，包括经理、架构师、开发人员，和测试人员。有大约十二个不同的组分团队，包括致力于开源技术的团队、它们是作为技术功能基础的团队。组分团队在不同的地理位置，然而，每个团队的小型规模使它在项目中相当容易地采用敏捷的开发原则。利用瀑布方法的项目的前期当作是项目中使用的技术的培训。这些先前的技术培训令到敏捷概念的过渡更容易。团队没有额外的技术学习曲线的困难。

迭代 1 用作过渡迭代，用于完成已经在开发中，并作为敏捷项目而开始运作的可交付件。敏捷开发过渡适当地启动，并且带有对前两个迭代的适度的开发承诺。主要的焦点在于在团队和建立的过程之间构建人与人之间的文化，例如，并行的早期系统测试应用程序开发和执行，这将会用于在新的环境中令团队成功。根据此项目的结果，鼓励花费在从瀑布开发到敏捷开发的过渡阶段上的时间。

在六个迭代中，系统测试核心团队与开发团队并行工作。这令传统的系统测试应用程序的开发和执行的子集在每个迭代中都能够运行。这种并行导致了以下方面的成功：

• 跨多个迭代增量地构建更健壮且实际的系统测试应用程序。
• 开发、功能验证测试，和系统测试之间较密切的沟通使得大家听到了许多观点，并形成系统测试的执行。
• 项目中使用的技术和环境中较深入的技能。
• 在产品周期较早期除去一些系统测试缺陷。
• 每个迭代都进行过程或测试的改进。