敏捷测试初见
1 敏捷和传统开发的差异返回
敏捷软件开发（Agile Software Development）初起于九十年代中期。最早是为了与传统的瀑布软件开发模式
（waterfall model）相比较，所以当时的方法叫做轻量级方法（Lightweight methods）。二十世纪初，17 位
该方法的倡导者建立了敏捷联盟（Agile Alliance），并将该软件开发方法命名为敏捷软件开发过程。
有个非常有意思的游戏能够帮助大家理解敏捷和传统开发的差异。游戏有两个角色，一个是“老板”，另一个
是“员工”，在 2 分钟内，“员工”需要在“老板”的完全指挥下，即“向前一步，向后一步，停，向左一步，向右
一步”，完成 60 步移动的任务。“员工”需要执行“老板”的每一个指令，不允许做出相违背的动作。“老板”则
不参与行动，只发出指令指挥“员工”的活动。我们体验这个游戏时，当场 60% 的参与者成功完成了任务，
大致估计出我们的工作效率是 50%*60%=30%。游戏后，参与者被问及对这种行为方式的感受时，无论是
“员工”还是“老板”都表示非常不满。
接着，大家又做了另一组游戏。2 分钟内参与者被要求独立的、自主的完成 60 步移动任务，在这次游戏里，
所有参与者任务相同，大家可以自行决定、并依据自己的判断随时调整其步伐方向，快慢。最后，我们发现
所有参与者不但毫无折扣的按时完成了任务，因而工作效率也达到 100%*100%=100%，而且所有人对于
这种新的工作方式更是产生了极大的兴趣。
敏捷开发的最大特点是：
高度迭代；
持续的响应客户的频繁反馈。
敏捷开发的优势：
低风险
高透明度
面对变化的高适应能力
2 敏捷开发
返回
2.1 敏捷宣言
图1 敏捷宣言
2.2 敏捷方法
业界流行的敏捷开发的方法有许多，我们需要根据项目大小，性质来选择合适自己的敏捷方法。比如说 XP
（极限编程，eXtreme Programming）更加适合小型项目 3-5 人的团队。Scrum，DSDM (Dynamic System
s Development Methodology) 等更加适合大型团队的项目开发。而敏捷开发也不是一成不变放之四海皆准
的准则，而是一个方法的最佳实践。各个团体和企业也不断定制着自己的最佳游戏规则。VersionOne 的敏
捷开发的调研报告中很好的对比了各个方法被业界采纳的比例（见下 图 2）。这个图表就是 2007 年对来
自 71 个国家 1700 多人的调查结果的说明。
图2 敏捷方法使用百分比
除了图例中的方法外还有 Crystal, Lean Software Development, FeatureDriven Development, Xbreed, RUP 等等。
2.3 敏捷方法的共性
虽然各种敏捷方法的名称、所需环境、适合的团队有很大差异，但是他们拥有相似、相同的以下几大特点：
拥抱变化
“唯一不变的就是变化”所以，需求的变动是必不可少的，每次的决定和需求的调整都是将产品开发推向更正
确的方向。而在接受变化的同时，我们应该积极的反馈显示活动中暴露出来的可能的设计缺陷和错误。
客户的参与
最终使用者、内部使用者、客户代表、商业伙伴都可以是我们的客户。对于客户的参与更能使我们做出客户
真正需要的产品。
较少的文档
传统开发的文档在敏捷中仍有大用，只是我们可以将原来的文档进行精简。在敏捷中文档不是最佳的沟通方
式，更鼓励通畅的交通和沟通，而沟通的效率远高于文档。
最大化的生产力
敏捷开发模式要最大化的提高团队的工作效率。无论是依靠剪除冗余的文档工作，还是提供民主的、通畅的
沟通平台都是为了帮助 团队能够集中有限的精力处理。
测试驱动开发
是让开发人员在编写功能代码之前，根据对需求的理解先设计和编写单元测试代码。先思考如何对将要实现
的功能进行验证，再考虑功能的实现。然后迭代的增加新功能的单元测试和功能代码编写，直到完成全部功
能的开发。
自动化冗余工作
将团队成员从冗余的劳动中解放出来，无论是自动化的测试还是自动化工具的开发只要能够节约成本都是敏
捷开发、敏捷测试的目标。
民主的团队
敏捷团队是一支民主的团队，团队关系是平行的，每个团队成员能够平等的参与讨论，决策。传统开发的垂
直的官僚机构在敏捷开发中已是过时的。
3 敏捷测试
返回
在敏捷开发流程中，测试不再是瀑布试开发流程的一个环节，而是全程参与整个开发流程。通过各种方式来
保证产品的质量，无论是原则中的“频繁交付”，还是对“可工作的软件”的度量，或是敏捷开发实践中的“测试
驱动开发”，“行为驱动开发”，都离不开测试的支持。 当然，敏捷测试对测试人员提出了更高的要求，对测试
人员来说也是新的挑战。
页:
[1]
