基于敏捷开发实践的可交付软件项目管理中的测试策略创新

开篇：润墨网以专业的文秘视角，为您筛选了一篇基于敏捷开发实践的可交付软件项目管理中的测试策略创新范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

【摘要】目前敏捷软件开发已经在广大的软件公司广泛使用，测试已经不再像瀑布模型中独立的一个模块存在，而是紧密地贯彻在整个SDL（软件开发生命周期）中，被更多的项目经理及开发人员认可的TDD（测试驱动开发），BDD（行为驱动开发）等XP（极限编程）的重要思想都应用到很多成功的项目开发中。相对于原本的瀑布模型中有一个独立的相当规模的测试团队来说，敏捷测试可以说从需求一开始提出就已经开始了，本文讲着重介绍规划，管理，运营，项目开发过程中各个阶段的测试策略及何特点。

【关键词】敏捷开发;敏捷测试;敏捷实践;测试策略;TDD BDD极限编程项目管理

本文分为以下主题介绍敏捷实践活动的测试策略：

1.敏捷实践启动

在项目启动阶段，通常被称为“sprint 0”或“0 Scrum的迭代”，这个目标是让你的团队根据需求分析找到正确的方向。虽然主流敏捷社区不喜欢谈论这么多，事实是这一阶段的持续时间可以从几个小时到几周 取决于项目的性质和组织的文化。实际这个阶段有个重要的任务就是为了给客户演示未来软件模型而搭建的测试，主要任务是，组织各种方法测试并开始建立测试环境。这个阶段你的项目，你会做初期要求的构想。作为这一努力的结果，你及你的团队应该通过简单的测试获得更好的需求理解，并且制定一些验收标准。

1.1 测试环境搭建

在项目的开始，你需要开始设置你的环境，包括设定你的工作区域，您的硬件，并开发工具（命名一些东西）。有几个策略，来组织你的测试环境：

①采用开源软件（OSS）工具的开发。

②采用开源软件与商业的独立测试工具。

③有一个共同的错误/缺陷跟踪系统

④投资于硬件测试。团队可能需要的硬件上做测试。

⑤投资虚拟化和测试实验室的管理工具。

⑥投资持续集成（CI）和连续部署（CD）工具。

1.2 缺陷管理

缺陷管理往往是交付团队结合自己的需求管理和缺陷管理策略来简化他们的整体变更管理过程。这是因为缺陷是另一种类型的要求。要求也是一种缺陷，事实上，一些敏捷团队甚至捕捉使用缺陷管理工具的需求 。

采用这一战略的主要障碍，是把需求的处理和缺陷处理同等对待。在敏捷交付团队形势估计时，顾客通常需要支付新的需求的开发费用，但是不会同意在项目中支付缺陷的修复费用。在这种情况下，简单有效的做法是将工作项目标记为需要付费的（或不）。这种定价策略是把你的需求和缺陷管理过程合并为一个单一的简单的改变，这也是过程改进的机会。

2.整个团队测试策略

2.1 整个团队测试策略

敏捷社区中常见的一个组织的战略，团队需要包括人的分析能力，设计能力， 编程技能，领导能力，测试。显然这个列表没有罗列全部的团队的能力，同时，也不是每个团队成员都能拥有如上的能力。但是，在敏捷团队中，每个人都能以任何方式快速地学习新的技能，尽可能的通过学习去尝试并且分享给队友，从而提高团队的整体生产力。这被称为自组织“团队”。

如图1所示，我们可以看到传统和敏捷开发流程的不同。在传统瀑布模型下的团队，程序员是常见的（专家） 编写代码，然后把它扔来给测试人员（也是专家）。 虽然比没测试好，但是这样的独立作业，带来的是昂贵的花费和时间的开销。在敏捷团队的程序员和测试人员一起工作，并随着时间的推移，这两个角色之间的区别变得模糊。敏捷社区中一个有趣的哲学是，开发人员应该尽早尽量验证自己的工作，尽自己的能力，努力获得更好的这样做过的效果。

图1 传统和敏捷开发比较

2.2 开发团队测试策略

如图2所示。Ambysoft 2008测试驱动开发（TDD）的调查，TDD的测试技术在实践中的运用。有趣的是受访者明确表示，他们不只是做TDD也不是人人做TDD，令人惊讶的是。他们中的许多人也在做回顾和检查，结束生命周期测试，和平行独立测试 ，活动敏捷的纯粹主义者似乎很少。

图2 敏捷团队测试/验证实践

2.2.1 持续集成（CI）

持续集成（CI）是一种实践，每隔几小时至少一次，最好是更多的时候，你应该：

①建立你的系统。这包括编译你的代码和潜在的重建您的测试数据库（的）。这听起来简单，但大型组成的系统的子系统，你需要一个战略去思考怎样建备份系统以及真实的系统的整体。

②运行你的回归测试套件。你将需要确定的测试范围的大小。对于小的系统，你会得到一个单一的测试 套件的所有测试，但在更复杂的情况下，配置好测试用例是非常重要的。

③执行静态分析。静态代码分析是一个质量技术在自动化工具检查代码中的缺陷，经常寻找如安全缺陷或编码风格的问题类型。

先进的团队，特别是那些在一个敏捷的规模的情况下，会发现他们也需要考虑将CI工作自动化实现并且部署，这样可以推广到其他的环境建设，或如果有一个工作建立在一天结束的时候，你可能想将它部署到演示环境，你的团队以外的人可以看到进展。

2.2.2 测试驱动开发（TDD）

从图3可以看出，有效的TDD方法提供的测试用例比较详细的规格说明更能被工程师很好的把握和操作。有效的单元测试已经是开发文档的重要部分，同时，定义清晰的可被接受的测试用例也会在将来成为产品的一个验收标准的一部分。

图3 测试驱动开发（TDD）是一种敏捷开发技术的实践

图4 一个程序员标准的一天的工作安排

可被接受的TDD的测试用例的开发需要程序员根据需求，已经测试人员的反馈不断调整，同时，自我驱动代码重构及实现。根据图 4显示，其实一个程序员在拿到需求之后，更乐意去不断的寻找之前的类似相关代码的实现然后撰写测试用例，所以相关测试用例最好能够被系统集成并且被分享，这样可以节约开发的时间，也能够为客户的验收测试提供帮助。

2.3 独立的测试团队

整个团队参与敏捷实践的测试工作已经可以协助开发团队发现简单的功能性的测试用例的开发，然后在大规模的复杂开发团队，我们还需要一个独立的测试团队来做独立的完成阶段已经生命周期结束量产前的测试。独立的测试团队努力的目标是找出系统性的问题（整个团队的测试通常是在验证性试验），独立的测试团队将专注于更复杂的体验的测试，区别于整个团队测试，独立的测试团队将支持多个项目团队。大多数组织有许多开发团队并行工作，往往有几十几甚至百名开发人员，所以需要有一定规模的独立的测试团队支持实现规模效应。这将大大减少你所需要的测试工具的许可证数量，分享昂贵的硬件环境，并使测试专家能够分享支持多个开发团队。

从规模效应的角度来看，敏捷开发团队跟独立测试团队的人员配比往往会15：1或20：1，大量的测试人同时工作在多个不同项目组中，而之前传统的人员比率往往接近3：1或1：1。

2.3.1 平行的独立的测试

独立的测试小组报告缺陷给开发团队，这些缺陷被视为需求并被开发团队加上优先级放入工作项栈在下次版本的时候解决。

许多开发团队可能没有所需要的资源进行有效的系统集成测试，从经济角度来看资源必须在多个团队共享。该含义是，你需要一个独立的测试团队的工作 并行地跟解决这些问题的开发团队工作。系统集成测试往往需要昂贵的环境这不是哪个单个项目团队所能承担的。

采用独立的测试的方法依然是现有的质量/测试人员仍然以传统的方式进行的，我们需要帮助测试人员克服这些文化上的挑战，帮助他们获得的技能和心态，有更好的敏捷思维。

2.3.2 结束生命周期测试

结束生命周期测试对于很多敏捷团队来说是一个重要的努力成果，系统准备投产项目即将结束。如果独立的平行试验尽早开始，那么最终通过最后的生命周期测试可以很短，因为问题早已已基本被覆盖。独立测试工作延伸到交付的每个重要的里程碑，一旦解决方案的交付可用，独立的测试团队立即平行地进行完整的测试。

综上所述，敏捷测试贯穿整个项目的生命周期，直至整体解决方案交付完成，在这个期间影响软件质量，测试效果的不单单是独立的测试团队，整个团队的每个利益相关者都需要参与，灵活的测试环境以及便捷的缺陷管理，敏捷的灵活的测试策略能够帮助我们交付一个完美的整体解决方案给客户。

参考文献

[1]徐德华，应翔翔.论知识共享模型及其在中小型企业中的应用[J]. 经济论坛，2010，12.

[2]王敏.基于Scrum敏捷开发的软件过程管理研究[D].昆明理工大学，2010.

[3]尤建新，武小军.基于ERP的企业质量成本管理信息系统研究[J].中国质量，2002，12.

作者简介：洪钢（1978―），男，工商管理硕士，高级工程师，美满电子科技（上海）有限公司高级测试经理，主要从事Android，Linux上的SDK（软件开发工具）平台及整体解决方案的集成，敏捷测试，自动化实现，版本流程规范及风险控制等工作。