摘要：本文对于常用的软件开发模式和测试模式进行比较后，着重介绍了针对新型的开发模式——敏捷开发的测试模式，并对于这种测试模式的优缺点进行分析及本测试模式在实际项目中的运用，并介绍了自动化测试管理工具TD（Test Director）和自动化功能测试工具QTP（Quick Test Professional）在新型测试模式中的应用。

　　关键字：敏捷开发；测试模式；TD；QTP；

　　（一）前言

　　敏捷开发是一个迭代的、增量的、需求频繁变更的过程，客户每周都希望看到新变化，而这些变化最直观体现给客户的就是产品功能的增减，这种非常短的循环，使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。因此直接做成可以工作的软件比大量的描述性文档更有效。

　　正因为敏捷开发的特殊性，敏捷开发的测试无法像传统测试那样：项目初期根据详细的需求文档、设计文档来设计测试用例。因为最初的需求只是一个雏形，甚至连界面也没定，做成什么样子，有什么样的功能开发也不能确定，只能一步步的与客户确认和修改才能定下来；因此用例设计只能通过产品写用例；即先根据简单的需求写出用例的框架，然后拿到产品后，一边添加测试用例一边进行测试。同时敏捷开发的测试模式与传统测试模式不同的还有一个方面，那就是包括PM、开发人员等也都会一起投入测试。提高系统质量是个Team work，在开发过程中每个成员都有责任提交高质量的软件交付物（需求、代码、设计文档...），尤其我们团队的“敏捷开发”的项目中，我们还面临人员缺乏、项目多而分散的背景，更加需要整个团队都必须积极投入到测试过程中，PM、DEV、测试都需要积极参与测试和项目的质量保证工作。

　　（二）介绍新型的测试模式

图1 敏捷开发测试模式

　　从图1 不同的环中表示不同的敏捷实践，外环主要是开发的角度，内环为测试的角度。

　　测试计划和用例：在测试初期，主要是审核用户需求（FRD）定义的完整性、严密性和功能设计的可测性，然后根据用户需求设计测试计划。测试计划主要说明，（1）测试资源：在测试过程中需要的软件（包括操作系统，补丁版本，数据库版本，被测软件版本，还有诸如打印机、扫描仪等外部信息）和人力资源；（2）测试内容：测试的功能点，测试的类型（功能测试，性能测试，安全性测试，压力测试等）测试的方法，哪些可以自动化测试，哪些需要手动测试。如果是后期，主要是设计测试用例，包括性能测试用例，功能测试用例以及界面测试用例。同时完成配置库的配置，平台的搭建等内容，如一些管理工具（CQ，TestDirector，SVN）以及用户分配等。这个阶段主要输出：测试计划和测试用例。

　　更新测试：如果是在迭代（发布不同版本）过程中，客户可以根据上次所提供的产品做出一些新的合理的变更，这时我们需要根据变更来更新测试用例。准备在下一个版本中进行测试，也是新版本测试的重点。

　　执行测试：这时的测试主要分为两大类：接口测试和功能测试。接口测试推荐开发人员在提交代码前直接运行自动单元测试脚本来验证。功能测试：新功能代码提交后，由测试人员单独执行，首先会验证需求文档中的基本功能，一旦出现问题，那就说明开发人员的实现违反了最初客户定义的需求，应及时向开发说明问题，并且和客户沟通，确认开发和测试理解是否一致。之后再进行其它全面的功能测试，那么测试人员要及时与开发人员沟通。同时提交缺陷并且跟踪。这个阶段输出的制品是：本版新的测试用例的执行，缺陷记录。

　　自动化测试：主要用于回归测试阶段。在发布周期中，随着功能的不完添加与完善，回归测试的任务也就越来越重，同时也是必不可少的。