敏捷测试（三）从一个实例详解敏捷测试的最佳实践



敏捷软件开发是目前十分流行，并在业界逐步推广的软件开发模式。不同与传统的软件开发模式，敏捷开发模式有着自己鲜明的价值和方法。其中，敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求，带来了新的挑战。本文将结合一个软件项目实例，基于项目开发的不同阶段，详细介绍每个阶段的主要测试活动。文中将分析每个主要测试活动的前提条件和目标任务，并根据实例推荐最佳的解决方案。

第一部分：敏捷软件开发简介

敏捷软件开发（Agile Software Development）初起于九十年代中期。最早是为了与传统的瀑布软件开发模式（waterfall model）相比较，所以当时的方法叫做轻量级方法（Lightweight methods）。二十世纪初，17 位该方法的倡导者建立了敏捷联盟（Agile Alliance），并将该软件开发方法命名为敏捷软件开发过程。

敏捷联盟在成立之初总结了四条基本的价值原则：
1. 人员交流重于过程与工具（Individuals and interactions over processes and tools）
2. 软件产品重于长篇大论（Working software over comprehensive documentation）
3. 客户协作重于合同谈判（Customer collaboration over contract negotiation）
4. 随机应变重于循规蹈矩（Responding to change over following a plan）

基于这四点原则，敏捷软件开发有着自己独特的流程，如下图：

整个过程中夹杂了很多在敏捷开发前己经出现的软件开发方法，包括极限编程（Extreme Programming,1996）、Scrum（1986）、特征驱动开发（Feature Driven Development），测试驱动开发（Test Driven Development）等。这些方法在敏捷软件开发流程的各个阶段都有充分的体现和应用。

例如，Scrum 主要着重于项目管理，团队中的项目经理（Scrum master）需要在每个客户需求到来的时候制定 Sprint 的周期，定义每个 Sprint 的目标、分派任务、进行监督、最后总结得失并开始计划新的 Sprint。

相反，特征驱动开发和测试驱动开发主要被应用于 Sprint 周期中。如果项目进行于开发新功能时期，这个阶段主要推行特征驱动开发。所有测试和开发人员都将自己的工作重心放在新的功能上面，从开发和测试两个方面来完成各自的任务。如果项目进行于测试新功能时期，这个阶段需要将工作的重点挪到测试上来。所有的测试和开发人员都密切关注着目前版本的缺陷状况。测试人员需要在每天的站立会议（Daily Standup Meeting）上报告前一个工作日发现的新缺陷情况，项目经理根据项目进度和缺陷严重性来决定是否修复这些问题。需要及时修复的缺陷是目前 Sprint 中的一个新任务，将由项目经理添加到 Sprint Backlog 上并通知开发人员去修复漏洞。

对于敏捷开发和测试中的审查过程，极限编程中的同行评审（peer review）思想得到了充分应用。代码和文档的审查追求简单而高效。团队成员两两组成一对，互相评审；有时候，一个开发和一个测试人员也可以组成一对，互相协作。这样能够有助于缺陷和问题在第一时间被抹杀在萌芽中。

敏捷开发还有以下几个关键概念 (Key Issues)：
1. 迭代过程（Iterative process）
2. 用户故事（User stories）
3. 任务（Tasks）
4. 站立会议（Stand-up meeting）
5. 持续集成（Continuous integration）
6. 最简方案（Simplest solutions）
7. 重构（Re-factoring）

这些概念是敏捷开发中经常使用到的观点和方法。下面我们将详细论述测试人员在敏捷软件开发中扮演的角色和职能。

第二部分：敏捷开发中的测试人员

本部分将简要介绍敏捷开发中测试人员所需要具备的素质和职责。

2.1 敏捷开发团队介绍

我们的敏捷开发团队由四位开发人员、两位测试人员、一位产品设计，一位项目经理和一位产品经理组成（参见图 2）。每天早上十点，在固定的时间和会议室里面，团队会举行站立会议。这时候，团队成员按照既定的顺序向项目经理汇报各自前一天完成的任务，所遇到的困难和当天要完成的任务。同时，项目经理更新 Sprint Backlog（一张制作精良的 Excel 表格），并及时解决每个人所提出的问题。如图所示：