敏捷测试中的系统测试模型

chenjx

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

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

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

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

敏捷的过程实现模型

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

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

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

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

系统测试团队参与的目的

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

项目和迭代的时间线

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

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

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

周  开发  系统测试活动  
1  开始
设计
团队承诺 决定并提出迭代承诺，包括：根据在迭代中交付的新功能，定义压力测试的测试应用程序的提高及选择。
2  开发/测试 与高级架构师一起审查测试应用程序设计的增强。
开始应用程序增强的开发和单元测试。
利用可用的驱动程序开始回归测试。
3-4  开发/测试
审查开发/测试结果 继续应用程序增强的开发和单元测试，及回归测试。
创建测试场景并准备必要配置的机器。开发/提高自动化脚本。
5  高优先级的缺陷，没有新的功能 压力运行新的功能。在连续的迭代中增加压力/负载。
对新的功能驱动程序进行回归。
打开缺陷，带补丁执行，提供追踪，并检验缺陷。培训开发人员加入 SVT 的工作。
用额外的细节改进测试场景，并追踪进展。
6  审查系统测试结果
打包
演示
了解的经验
交付 继续与第 5 周同样的活动。
参与演示的计划、准备及执行。
提出系统测试结果。
为所了解的经验提供输入。
每天 功能测试的回归 对当前的驱动程序进行回归。

碎片

是lz新身体会吗？
请讲详细些，如此了了，没有实际指导作用。

hummel

最近实践了有幸实践了几个敏捷的项目.刚好看到这个帖子,故来抒发下.
1.项目迭代计划
敏捷会将系统模块或者功能拆解,然后进行在功能上进行迭代开发,这点我觉得取决项目,上次几个咨询公司的来交流比较强调这个,我倒不觉得是核心.也取决于客户,如果自己公司,如果对产品有极好的控制和引导,这个问题就不存在.
2.沟通
敏捷强调不同形式,便捷的沟通.什么story讲解会,照片啊,小黑板啊,晨会啊,
个人认为是提供了些方法,好像是想打破cmmi的一流程,但流程如果控制不好,风险也很大.
3.测试迁移
敏捷强调这个测试指导开发,认为是将测试迁移,其实知道cmmi的,都知道这只能算换汤不换药.

呵呵,以上好像都是评判敏捷哈,不过有个思想是倒是在我们项目组得到认可,减少返工,从而降低成本.我们会分析那些缺陷的出现就是属于返工带来的不必要的成本,是需求不清晰,还是测试和开发理解不一致,当类似问题还很多.

另外敏捷开发周期为1-2周,这基本可以考虑出你的项目是否适用,另外敏捷开发还有个成本,不要忽略,一个周期完成后,敏捷理论中讲,需要2-4天项目组进行review,可这点好多公司是办不到.