【IT168 技术文章】
如我在本文中提到的，系统测试是在将软件产品交付给客户使用之前完成的最终产品测试。此测试一般在完成开发和功能验证测试之后进行。某些入口标准用来确定对于系统测试的代码准备状态（举例来说 ， 回归状态，缺陷后备，等等）。必须达到这些标准，从而正式地开始系统测试并要求结果。
在一般的系统测试中，目标是用类似客户的配置在高压下对系统进行类似客户的工作量（举例来说，多平台、多软件版本，等等）。 正式的系统测试执行包含压力、寿命期运行、内存泄漏分析、多应用程序、复杂且各种各样的拓扑、高可用性及中断测试、混合的版本测试、全平台测试、产品集成测试，及文档测试。
本文介绍了团队所采用的将一组系统测试子集作为敏捷开发环境的一部分，并与代码开发活动并行的方法。我们将展示出我们的方法可以交付更好的系统测试应用程序，让实验方法将包含与代码开发并行的系统测试子集的价值和效率最大化，并提高团队的沟通和技能。这些成功 导致 （led） 了在完整的系统测试开始时改进了的完整的 软件验证团队（ SVT ） 的加速的时间，以及改进了的产品质量的预期好处。
在六个迭代中，系统测试核心团队与开发团队并行工作。这能够让传统的系统测试应用程序的子集的开发和执行在每个迭代的过程中执行。该并行导致了此处描述的各个方面的成功。
敏捷的过程实现模型
在开发的一年之后，使用现有的瀑布实践并交付开放的 alpha 和 beta，我们的项目转换了工具，并实现敏捷的开发模型。整个团队需要将敏捷的开发原则作为“现场实验”，从而满足特定客户的需求。第一个迭代是过渡的，通常着重于交付在瀑布开发模型下开发了几个月的代码。当第一个迭代开始时，整个团队包括大约五十五个人，包括设计人员、开发人员、测试人员、信息开发人员和客户交付团队。
迭代 1 用作过渡的迭代，用于完成已经处于开发中的可交付件。敏捷开发过渡适当地启动，并且带有对前一或两个迭代的适度的开发承诺。主要的焦点在于在团队和集成的过程之间构建并交流新的项目和人与人之间的文化，例如，并行的早期系统测试，这将会用于在新的环境中令团队成功。
九个系统测试人员（整个系统测试团队的子集）在先前的瀑布开发周期中兼职参与。在开发代码的过程中，他们关注构建技术技能、计划、测试案例开发，和应用程序单元测试。这样做，他们练就了项目所用的技术中的技能，但没有获得内行的经验。
当转变为敏捷开发时，九个系统测试人员中的五个全职参与项目。因此，在第一个迭代之前，系统测试团队已经了解了新技术，创建了测试应用程序，并且像团队一样一起工作。这些早期的测试及开发活动令敏捷周期的开始有更高的生产率。
系统测试团队参与的目的
五个系统测试人员面临的挑战是确保代码质量足以达到在任一已知的迭代中开发的功能的 beta 级交付。为了迎接这个挑战，他们决定在每个迭代中运行传统的系统测试应用程序开发和执行的子集，预期最终的迭代进行一组更复杂的具体客户的，基于场景的测试。系统测试团队与项目的高级架构师会面，并一起为了增强和执行选择一个现有的系统测试应用程序。然后，该应用程序将用于在迭代过程中的压力和寿命期运行，并且在最终的迭代里大量地使用。目的是在项目最终在世界范围内交付时，系统测试人员有限且同时的参与会为最终的完全的系统测试迭代建立起坚固的基础。
项目和迭代的时间线
迭代有六个星期之久。表 1 显示了一般的迭代规划，以及为每个星期计划的具体的系统测试活动。在迭代的第 1 周中，高级架构师提出建议的候选功能列表。该列表主要基于具体客户的需求，并且通过用例进行描述。该列表可在线访问，以便在迭代进行中，所有的团队成员都可以改进用例。每个团队成员都会审查候选的列表，并与团队成员和高级架构师一起讨论设计及问题，并且在周末提交在迭代结束时（是否）要交付的功能。每天举行一个小会。高级架构师每天都出席大部分小会议，并且在所有迭代过程中都与全部团队成员在一起。
如前面所提到的，最后的迭代计划着重于在开发迭代中不能实现的最终的缺陷清理和复杂的测试。为了提高稳定性，最后的迭代没有新的功能。六个迭代完成了。同时，在最后的迭代中，大量的开发人员需要加入系统测试团队成员中，通过提供对测试执行和调试的辅助来完成最终的迭代。其余的开发人员会处理缺陷。这意味着在较早的迭代中的开发阶段里，一些开发人员需要为了最后的迭代而培训系统测试的知识。
表 1：每个迭代的活动：开发和系统测试
周 开发 系统测试活动
1 开始
设计
团队承诺 决定并提出迭代承诺，包括：根据在迭代中交付的新功能，定义压力测试的测试应用程序的提高及选择。
2 开发/测试 与高级架构师一起审查测试应用程序设计的增强。
开始应用程序增强的开发和单元测试。
利用可用的驱动程序开始回归测试。
3-4 开发/测试
审查开发/测试结果 继续应用程序增强的开发和单元测试，及回归测试。
创建测试场景并准备必要配置的机器。开发/提高自动化脚本。
5 高优先级的缺陷，没有新的功能 压力运行新的功能。在连续的迭代中增加压力/负载。
对新的功能驱动程序进行回归。
打开缺陷，带补丁执行，提供追踪，并检验缺陷。培训开发人员加入 SVT 的工作。
用额外的细节改进测试场景，并追踪进展。
6 审查系统测试结果
打包
演示
了解的经验
交付 继续与第 5 周同样的活动。
参与演示的计划、准备及执行。
提出系统测试结果。
为所了解的经验提供输入。
每天 功能测试的回归 对当前的驱动程序进行回归。
成功
在此我们将开始讨论一些实现了的重要成功、遇到的挑战，及与敏捷的系统测试活动相关的对比的好处。让我们从成功开始讨论。
更健壮且更实际的系统测试应用程序
敏捷的开发周期从客户开始。为了了解商业目标、IT 策略、应用方向，和优先级，架构师经常和客户会见。系统测试团队分析迭代的测试用例，并根据作为外部客户的关键的用例的子集设计测试应用程序的增强。如果测试应用程序增强是大规模的，那么就在先前的迭代中开发那些增强，从而给测试应用程序的开发留出时间。如果可以快速地完成应用程序的增强，那么就在当前的迭代中开发它们。
在第 2 周中，系统测试团队向架构师提出应用程序的设计增强。这会形成向系统测试团队提供机会来结合架构师的建议的对话。它还向架构师提供他们没考虑过的系统测试的观点，而有时，这会导致产品设计的变更。由于系统测试团队与架构师和开发团队有密切的合作关系，所以系统测试人员对客户的需求的了解深入得多。
将小型的系统测试团队与开发活动并行令系统测试团队能够以增量的方式开发更健壮“类似客户的”测试应用程序。这是比历史上在瀑布开发周期中进行的更实际的方法，因为它允许系统测试团队参与可交付件的创建，而不是在短暂的时间内，被迫消耗，并测试大量可交付件。敏捷的开发周期允许系统测试团队扮演实际的客户，从应用程序设计到系统测试应用程序的编码和单元测试。
开发和系统测试团队之间更密切的交流
由敏捷开发实践的采用及系统测试活动的加入所带来的重大好处是，开发和系统测试团队之间通过参与每日的会议而进行的更频繁且更深入的交流。因此，系统测试团队可以洞察会影响测试计划和/或测试应用程序的当前的构建问题、最近发现的缺陷、设计修改等等。当系统测试人员报告在并行的系统测试中发现的问题时，小会议也给开发团队带来好处。每日的会议交流允许系统测试向整个观众简要地描述可能需要多个开发人员协作或了解的问题。最终，会议允许开发指出什么时候系统测试方法与当前的代码基础功能不一致。
开发和系统测试之间的密切交流的另一个重要好处是，当新的功能首次出现在一个构建中时，系统测试团队可以立即注意到。对可用功能的交流是至关重要的，因为每个迭代中只有三个星期是执行系统测试应用程序的设计、编码，和单元测试的。这是重要的，因为系统测试有时为该迭代并行地开发测试应用程序及产品功能。记住，系统测试会令对测试应用程序及单元测试的增强的改进非常快速。因为系统测试及时地收到了构建中存在所需功能的通知，所以他们能够尽可能快地执行应用程序测试。
架构师、开发人员，和系统测试人员之间的密切交流令整个团队得益于许多观点和建议，提高代码质量和完整性。
较深入的系统测试技能
在敏捷的开发周期中加入系统测试子集的另一个优点是它促进较深入的系统测试应用程序开发和测试技能。在发布周期的较早期，将这一较小的“核心”系统测试团队指派到项目中。敏捷的开发周期的迭代特性令系统测试团队以较小的且更容易消费的规模在较长的时间内理解产品。
贯穿迭代的系统测试的连续子集
在所有的迭代过程中都执行系统测试的子集，即使每个迭代的系统测试时间都是有限的。在测试过程中，使用各种自动化的技术来启用压力/负载测试、内存泄漏分析、数据完整性测试，和回归测试。压力/负载工具允许系统测试在指定的持续时间内在模拟的客户量下运行测试应用程序。执行脚本获取浏览器动作（这些会被回放），允许执行自动的实施。这些脚本还允许生成随机的数据，这模拟了不同的客户交互。相关的配置脚本允许测试人员为每次执行指定所期望的持续时间和模拟客户的数量。他们通过定期查看产品日志，以及压力工具的日志来监控运行进展。压力工具还生成统计，这提供了潜在的问题及意外活动的指示。压力工具在第一个迭代之后的每个测试运行中都会用到。
伴随代码稳定性，及进行寿命期测试运行的能力的成功导致了以第三个迭代开始的迭代完成时，增加内存泄漏分析。在每个测试之前，系统测试人员配置许多产品参数来允许在测试过程中收集内存泄漏分析信息。在每次运行之后，他们会将运行的日志输入到内存泄漏分析工具中。工具会生成一组图，查看在运行过程中的内存使用，并检查内存泄漏的指示。如果发现了内存泄漏，那么会打开并追踪故障报告。一旦最终的执行在无问题的情况下完成，那么测试人员就会在测试追踪工具的完成记录中加入信息，指示最终的内存泄漏分析的结果。
数据完整性测试也在一些测试场景中进行，从而确保系统测试的子集的执行。测试应用程序严重依赖于 IBM? DB2? 来进行数据持久化。应用程序包含一组更新应用程序数据库中相同表的事务工作负载。这些事务工作负载是同时运行的，因此推动负载并有意地创建数据库争用。目的在于强迫事务回滚，这样系统测试人员可以确保成功地完成恢复。当试图对已上锁的记录进行更新时，事务回滚并在稍后重新执行。在执行完成时，所有的数据库活动都完成了，并且不得不使所有的事务都一致。测试应用程序中嵌入了数据库一致性检查。应用程序持久化了的数据在其使用的一组表中有相关的值。在执行的末尾，测试人员运行一组额外的测试来检验每个应用程序的表中的数据与彼此一致。
回归测试也用于以第二个迭代开始的迭代开发中。通过在当前的构建上为当前的迭代运行先前的系统测试应用程序的迭代版本，在每个迭代执行迭代的回归测试。随着我们进入后面的迭代，这些测试执行快速地成为早期的同时的测试执行的集合。这令在迭代过程中确定并处理回归缺陷，而不是像瀑布模型那样，在测试的结尾。
因此，即使敏捷的版本周期包含一系列相关的短迭代，仍旧能够执行系统测试的子集。由于团队利用大量的自动化功能，因此压力/负载测试、内存泄漏分析、数据完整性测试，和回归测试都将执行。这些类型的测试提供了模拟的客户环境中的产品代码稳定性置信度。
