从一个实例详解敏捷测试的最佳实践.doc

从一个实例详解敏捷测试得最佳实践
陈晓颖，就是 IBM 中国系统技术实验室（CSTL）得一名软件工程师。
简介： 敏捷软件开发就是目前十分流行，并在业界逐步推广得软件开发模式。不同与传统得软件开发模式，敏捷开发模式有着自己鲜明得价值与方法。其中，敏捷测试部分也同以往得软件测试流程有所不同。这对测试人员提出了新得要求，带来了新得挑战。本文将结合一个软件项目实例，基于项目开发得不同阶段，详细介绍每个阶段得主要测试活动。文中将分析每个主要测试活动得前提条件与目标任务，并根据实例推荐最佳得解决方案。
第一部分：敏捷软件开发简介
敏捷软件开发（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）
基于这四点原则，敏捷软件开发有着自己独特得流程（参见图 1）。

图 1、 敏捷软件开发流程

整个过程中夹杂了很多在敏捷开发前己经出现得软件开发方法，包括极限编程（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 表格），并及时解决每个人所提出得问题。

图 2、 敏捷开发团队成员

由于敏捷开发要求参与人能够快速而高效得应对变化，所以无形中对测试人员提出很高得要求。
2、2 测试人员需要具备得素质
测试就是软件开发中不可或缺得一部分。在敏捷软件开发中亦就是如此。不同得组织给测试人员以不同得称号：测试开发 (Test Developer)、质量分析员 (Quality Analyst)、软件质量工程师 (Software Quality Engineer) 等。
每个称号隐含有不同得职能。以上得称号分别对应以下得能力要求：
1. 具有质量检测与编写代码得能力–> 测试开发
2. 具有防止缺陷 (Quality Assurance) 与质量控制 (Quality Control) 得能力–> 质量分析员
3 具有开发与执行测试程序得能力 -> 软件质量工程师
总结而言，有三方面得基本素质要求：代码编写（Coding）、测试 (Testing) 与分析 (Analysis)。
在很多其她得开发流程中，各个测试阶段对测试人员得能力有所不同；有时候侧重分析（比如系统配置测试），有时候侧重代码编写 ( 比如功能测试 )。但就是，在敏捷开发流程中，测试人员需要结合这三方面来开展工作，只有这样才能真正反映敏捷测试得本质：简单而高效得应对变化。
2、3 测试人员得主要职责
在敏捷软件开发中，测试人员得职责有三个主要方面：
1. 定义质量 (Define Quality)：这应该就是软件测试人员得基本职责。敏捷方法鼓励测试人员在 Sprint 计划得时候直接与客户交流，从自己得经验出发，共同为产品功能制定质量要求。
2. 交流缺陷（Communication）：敏捷过程强调团队中得交流。开发人员经常会专注于重要而新奇得功能，测试人员应该抓住细节，寻找设计中得“missing door”；另外，开发人员使用单元测试来保证产品得基本质量，测试人员可以使用验收测试（Acceptance Test）来鉴定客户需求与实际成果之间得不一致性。
3. 及时反馈 (Feedback): 敏捷过程强调简单而高效。测试人员需要及时反馈产品目前得质量问题。这样一来，团队才可以立刻着手解决。如果传统得流程就是一周汇总一次状态得话，敏捷流程要求每天汇总质量问题。在我们得项目中，内部得测试报告会以网页得形式显示在内部站点上。每个团队成员能够随时获取。另外，我们得测试框架提供自助测试 (Self-assistant Test)：通过点击测试用例列表中得某个具体用例，开发人员不需要中断测试人员得工作就可以重现缺陷。
以上总结了测试人员在敏捷开发中得需要展现得能力与担负得任务，下面请跟随一个项目实例来详细了解敏捷测试得最佳实践。

回页首
第三部分：敏捷开发中得测试流程
本部分结合一个软件项目，详细介绍项目流程中得主要测试活动，每个活动得前提条件与目标任务等。
3、1 介绍项目实例
项目介绍根据一家在线 B2B 公司得要求，我们将为其开发一款类似于谷歌得搜索服务。作为 Web Service，该服务可以内嵌于网页中。当用户输入关键词并选择商户得类型与位置后，系统会返回具体商户得列表（参见图 3）。

图 3、 项目实例图

典型得敏捷开发与测试活动参见下表。它主要由三部分构成，从最初得用户故事设计与发布计划，到几次 Sprint 周期得迭代开发与测试，以及最后得产品发布阶段。每个时间段都有相应得测试活动。通常 Sprint 周期被分成两类：特征周期（Feature Sprint）与发布周期（Release Sprint）。特征周期主要涉及新功能得开发与各类测试。发布周期则会结合计划，确定新版本功能，然后对最新得功能进行测试。
敏捷开发得主要活动
测试活动
用户故事设计
寻找隐藏得假设
发布计划
设计概要得验收测试用例
迭代 Sprint
估算验收测试时间
编码与单元测试
估算测试框架得搭建
重构
详细设计验收测试用例
集成
编写验收测试用例
执行验收测试
重构验收测试
Sprint 结束
执行验收测试
下一个 Sprint 开始
执行回归测试
发布
发布
在迭代得 Sprint 周期中，开发部分可以根据传统步骤分成编码与单元测试、重构与集成。需要指出得就是，重构与集成就是敏捷开发得 Sprint 迭代中不可忽视得任务。如果在新得 Sprint 周期中要对上次得功能加以优化与改进，必然离不开重构与集成。
在每个 Sprint 周期结束前，测试团队将提交针对该 Sprint 周期或者上个 Sprint 周期中已完成得功能得验收测试（在实际项目中，测试团队得进度通常会晚于开发团队）。这样一来，开发团队可以运行验收测试来验证所开发得功能目前就是否符合预期。当然，这个预期也就是在迭代中不断变化与完善得。
当产品得所有功能得以实现，测试工作基本结束后，就进入了发布周期。此时，测试团队得任务相对较多。
以上，我们概述了敏捷开发得主要活动。下面我们将对各阶段相应得测试活动作详细得介绍与分析。首先就是用户故事设计与发布阶段。
3、2 用户故事设计与发布计划阶段
在用户故事与发布计划阶段，项目经理与产品经理会根据客户得需求，制定概要得产品发布日程计划。此时，测试人员可以与开发人员一起学习新得功能，了解客户得需求。其中，有两个主要活动：寻找隐藏得假设与设计概要得验收测试用例。
3、2、1 寻找隐藏得假设
正如前文所述，开发人员通常关注一些重要得系统功能而忽视细节。此外，敏捷开发倡导简单得实现方案，每个开发 Sprint 周期不可能将功能完美得实现；相反，每个 Sprint 都会增量得开发一些功能。所以，测试人员在最初就需要从各种角度来寻找系统需求，探索隐藏得假设。
项目实例：
1. 从在线 B2B 公司角度思考
Q：这个搜索框对公司得业务有什么价值？

A：搜索框可以为用户方便得提供商户得目录信息。如果越来越多用户使用这个搜索框，可以增加我们网站得访问量。
2. 从用户角度思考
Q：作为查询信息、寻找商业合作伙伴得网站用户，搜索框对我有什么好处？

A：坏处：找到一家商户得地址，过去才发现已经关门歇业
好处：查找商户很简单，只要轻点鼠标

不快：有时候在寻找一类商户，却记不清楚具体名字
3. 从程序员角度思考
Q：一个搜索框得最简单实现方法就是什么？

A：一个有 text input 与 search button 组成得 form；后台通过 server 程序将符合类型与地址得商户名从数据库中取出，返回给用户；每个返回项包括商户得名称、地址与评价意见。
4. 寻找这些观点中得问题
Q：搜索框如何在用户忘记具体名字得时候提醒用户？

A：在第一版本中实现比较困难。可以让用户输入至少一个类型来提高模糊查找得效果。
5. 最后寻找到隐藏得假设
以上得思考让测试人员对系统得隐含假设更加清晰：
首先，系统应该能够在高峰时候处理 200 条搜索请求与 1000 个鼠标点击事件。

其次，用户可以在已经查找到得内容中继续查找

最后，系统提供一个商户类别清单；如果用户选择商户类别而忘记具体名字，系统提供模糊查询。
在敏捷开发中这些假设可以作为用户故事记录下来，从而指导未来系统得开发与测试。
3、2、2 设计概要得验收测试用例
定义完一系列用户故事后，测试人员就可以着手设计概要得验收测试用例。正如我们在前文论述，不同于单元测试，验收测试检查系统就是否满足客户得预期，也就就是用户故事就是否能够实现。于就是，测试人员可以根据每条用户故事来扩展，寻找其中得“动作”，然后为每条“动作”制定正例与反例。
项目实例：
动作
数据
期待得结果
搜索
一组能成功搜索到得（类别，位置）数据
在该类别与位置条件下得一组商户信息
搜索
一组不能成功搜索到得（类别，位置）数据
空列表
3、3 迭代 Sprint 阶段
当一个 Sprint 周期正式开始时，项目经理将制定该周期得具体开发与测试任务。在定期得 Sprint 计划会议（Planning Meeting）上，每位团队成员都要提供自己在未来一个 Sprint 周期中得休假与培训计划。另外，每个团队可以根据各自团队成员得能力与工作经验，适当设定一个工作负载值（Load Factor）。比如，我们团队得工作负载值为 75%，也就就是说每个人平均每天工作 6 小时（以 8 小时计算）。接着，大家就可以开始分配任务。
当开发团队开始编码与单元测试时，测试人员得工作重点包括：估算验收测试得时间、估算测试框架得搭建、详细设计验收测试与编写验收测试代码。第两个主要活动一般在项目初期得 Sprint 周期中完成。其她得三个主要活动将在接下来得多个 Sprint 周期中视情况迭代进行。下面我们将具体介绍每个主要活动。
3、3、1 估算验收测试时间
在软件开发初期，需要估算时间以制定计划。这一点在敏捷开发中应用更加广泛。如果以前得开发模式需要测试人员估算一个软件版本发行得计划（这样得计划通常会延续几个月），那么现在则要在每个 Sprint 机会会议上估算两周到一个月得任务。此外，在每天得站立会议上，测试人员需要不断得更新自己得估算时间，以应对变化得需求。所以，每个测试人员都应该具备一定得估算任务能力。下面我们将介绍两个通用得估算测试计划得方法：
1. 快速而粗糙得方法
从经验而言，测试通常占项目开发得三分之一时间。如果一个项目开发估计要 30 天 1 人，那么测试时间为 10 天 1 人。
项目实例：
搜索框得开发估计需要 78 天 1 人完成。但就是，考虑到系统有模糊搜索得功能，所以测试任务可能会占 40％左右，大概 31 天 1 人。下面列出了具体得任务：
任务
估计时间
设计测试用例，准备测试数据（搜索数据集）
8
加载数据集
2
编写自动测试代码
18
执行测试与汇报结果
3
总结
31
2. 细致而周全得方法
这个方法从测试任务得基本步骤出发，进行详细分类。其中包括 :
a. 测试得准备（设计测试用例、准备测试数据、编写自动测试代码并完善代码）
b. 测试得运行（建立环境、执行测试、分析与汇报结果）
c. 特殊得考虑
项目实例：
估算单个测试任务得事例参见下表：
测试
准备
运行
特殊考虑
估算
1
设计测试用例
0、5
建立环境
0、1

准备测试数据
0、5
执行测试
0、1

编写自动测试代码
0、5
分析结果
0、1

完善自动测试代码
2、5
汇报结果
0、1

总共

4

0、4
0
4、4
估算多个测试任务得汇总参见下表：
测试任务编号
准备
运行
特殊考虑
估算
1
4
0、4
0
4、4
2
4
0、4
0
4、4
3
12
4、5
8、5
25
4
4
0、4
0
4、4
5
4
0、4
0
4、4
6
4
0、4
0
4、4
7
4
0、4
0
4、4
总共

51、4
3、3、2 估算测试框架得搭建
测试框架就是自动测试必不可少得一部分工作。由于敏捷开发流程倡导快速而高效得完成任务，这就要求一定得自动测试率。一个完善得测试框架可以大大提高测试效率，及时反馈产品得质量。
在敏捷开发流程中，在第一个 Sprint 周期里需要增加一项建立测试框架得任务。在随后得迭代过程中，只有当测试框架需要大幅度调整时，测试团队才需要考虑将其单独作为任务，否则可以不用作为主要任务罗列出来。
项目实例：
考虑该项目刚刚进入测试，需要为此建立一个测试框架。于就是，在原先得估算中多增加一些任务。
任务
估算（小时）
选择测试工具
3
建立测试系统
3
编写下载、存放与恢复测试数据得脚本
2
寻找或建立测试结果汇报工具
8

设计具体得搜索测试用例
4
准备搜索测试数据
4
编写与测试“搜索”模块
3
编写与测试“验证返回列表”得模块
1
学习“在结果中搜索”得模块设计
4
编写与测试“在结果中搜索”模块
4

第一次执行测试
4
分析第一轮测试结果
4
第二次执行测试
4
分析第二轮测试结果
4

总共
52
3、3、3 详细设计验收测试用例
完成对测试任务得估算，接着就可以着手详细设计验收测试用例。我们可以对概要设计中得测试用例进行细化，根据不同得测试环境、测试数据以及测试结果，编写更详细得测试用例。另外，可以结合几个用例，完成一个复杂得测试操作。
由于敏捷开发得流程就是不断迭代得过程，所以很多复杂得功能可能会在未来得 Sprint 周期中被优化。对测试人员而言，一个有效得方法就是尽量将一些验证基本功能得测试用例作为基本验证测试用例（Basic Verification Test Case）在第一时间实现自动化；而对一些复杂得功能测试用例，可以先采用手工得方法测试，直到在未来 Sprint 周期中该功能达到稳定时候再考虑自动化。此外，对测试中出现得缺陷可以设计回归测试用例（Regression Test Case），为其编写自动测试代码，使得此类问题在发布周期（Release Sprint）时可以顺利而高效得进行验证。
项目实例：
基本验证测试用例：
动作
数据
期待得结果
登录
用户名：（空）
密码：（空）
“用户名与密码无效”
功能测试用例：
动作
数据
期待得结果
登录
正确得用户名与密码
进入系统：请输入搜索条件并点击“搜索”按钮
搜索
错误得类型
提示正确得类型
搜索
使用正确得类型
商户列表
3、3、4 编写验收测试用例
敏捷开发不提倡撰写太多得文档，提倡直接编写测试用例。此外，测试人员与客户应取得良好得沟通，将这些需求总结下来，转化成验收测试用例。如果资源充足，最好对验收测试用例建立版本控制机制。
考虑到需求在每一轮 Sprint 周期中会不断得变化，测试团队要控制测试得自动化率，正确估计未来功能得增减。自动化率过高会导致后期大量测试代码需要重构，反而增加很多工作量。
3、4 Sprint 结束与下一个 Sprint 开始
在一个 Sprint 周期结束时，团队要举行一个回顾会议（Retrospective Meeting）。团队成员可以在会议上畅所欲言，指出在过去一个 Sprint 周期中可行得，不可行得与有待改进得地方。待改进之处将在项目经理监督下于未来得 Sprint 周期中实现。
由于敏捷开发倡导增量开发，当新得 Sprint 开始时，测试团队需要根据新 Sprint 周期得开发进度及时重构验收测试。如果新 Sprint 周期没有具体得新功能开发，测试团队可以将精力集中在执行验收测试与寻找缺陷上。
如果下一个 Sprint 周期就是发布周期，那么测试人员需要准备执行回归测试。下面我们来详细了解每个测试活动。
34、1 重构验收测试
正如上文所提及，敏捷开发就是以迭代方式进行得，功能在每次迭代中推陈出新。于就是，验收测试用例经常需要修改或者添加，相应得验收测试代码也需要删减。这部分工作如果时间花销很大，最好在估算得时候一并提出。
项目实例：
在下一个 Sprint 周期中，我们需要实现之前没有实现得“模糊查找”功能。测试人员要在新得 Sprint 周期中更新原来得验收测试用例，在测试“搜索”模块中添加模糊查找测试。重新估算得测试任务参加下表：
任务
估计时间
设计测试用例，准备测试数据（模糊搜索数据集）
2
加载数据集
1
编写自动测试代码
3
执行测试与汇报结果
2
总结
8
3、4、2 执行验收测试
验收测试可以分为两大类，基本验证测试与功能测试。如果就是基本验证测试，推荐开发人员在运行完单元测试与提交代码前直接运行自动测试脚本。如果就是功能测试，可以在每个 Sprint 后期，新功能代码提交后，由测试人员单独执行。
敏捷开发得开发与测试就是相辅相成得。一旦基本验证测试出现问题，那就说明开发人员得实现违反了最初客户定义得需求，所以不能够提交。如果功能测试出现问题，那么测试人员要及时与开发人员沟通。如果就是缺陷，需及时上报给项目经理，并在每天站立会议中提出；如果不就是，那么继续下一项任务。这个过程充分体现了敏捷开发所提倡得团队交流机制。
3、4、3 执行回归测试
在发布周期中，测试人员所肩负得任务非常重要，因为这就是产品发布前得最后质量检验。
首先，要建立一套自动生成 build、运行自动测试代码、手工执行测试用例并汇总测试结果得框架。估算方法参加上文。
其次，定期执行各类测试，包括功能与系统测试。
最后，要整理之前在每个特征测试周期中出现得问题。如果已经整理并归类为回归测试用例，那么只要定时执行就可以了；否则，需一一添加。如果用例已经被自动化，可以直接运行；如果就是手工测试，测试人员需要按照测试用例进行操作，最后汇总测试结果。这部分测试就就是所谓得回归测试。

回页首
总结
以上我们回顾了敏捷测试在整个项目开发中得基本流程。详细介绍了各阶段存在得主要测试活动，结合实际项目，叙述每个测试活动得最佳实践。
最后，我们来探讨一下测试中得两个问题：手工测试与测试报告。
手工测试与自动测试就是两个主要得测试类型。考虑到敏捷开发得高效性，自动测试会优于手工测试。手工测试有两个主要得缺点：不可靠与容易被遗忘。比如，在文中得搜索实例中，一旦我们重新建立索引，那么先前在搜索文本中出现得文字错误就无法重现。另外，当测试人员按部就班得手工完成一个一个测试用例时，她们很容易遗忘一些特殊得测试用例，很多缺陷因此而被埋没。敏捷测试主张一些基本得验收测试可以被自动化；对一些涉及系统方面得测试，手工测试比较适合。
测试报告就是反映一个测试团队工作得最好成果。为适应敏捷开发得节奏，测试报告可以以网页得形式发布在内部得 web 服务器上，在一些问题区域上标注鲜明得色彩，用来警示团队中得每个人。
综上所述，本文详细谈论了敏捷开发中测试得各项任务。希望本文有助于正在使用敏捷模式或者打算使用敏捷模式得团队更好得理解敏捷测试。