成功

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

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

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

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

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

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

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

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

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

较深入的系统测试技能

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

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

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

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

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

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

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

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

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

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

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

过程演进

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

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

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

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

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

停船识别

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

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

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