在 IBM Bluemix 云平台上开发并部署您的下一个应用。服务器
第一部分：敏捷软件开发简介
敏捷软件开发（Agile Software Development）初起于九十年代中期。最先是为了与传统的瀑布软件开发模式（waterfall model）相比较，因此当时的方法叫作轻量级方法（Lightweight methods）。二十世纪初，17 位该方法的倡导者创建了敏捷联盟（Agile Alliance），并将该软件开发方法命名为敏捷软件开发过程。app
敏捷联盟在成立之初总结了四条基本的价值原则：框架
- 人员交流重于过程与工具（Individuals and interactions over processes and tools）
- 软件产品重于长篇大论（Working software over comprehensive documentation）
- 客户协做重于合同谈判（Customer collaboration over contract negotiation）
- 随机应变重于循规蹈矩（Responding to change over following a plan）
基于这四点原则，敏捷软件开发有着本身独特的流程（参见图 1）。dom
图 1. 敏捷软件开发流程
整个过程当中夹杂了不少在敏捷开发前己经出现的软件开发方法，包括极限编程（Extreme Programming,1996）、Scrum（1986）、特征驱动开发（Feature Driven Development），测试驱动开发（Test Driven Development）等。这些方法在敏捷软件开发流程的各个阶段都有充分的体现和应用。jsp
例如，Scrum 主要着重于项目管理，团队中的项目经理（Scrum master）须要在每一个客户需求到来的时候制定 Sprint 的周期，定义每一个 Sprint 的目标、分派任务、进行监督、最后总结得失并开始计划新的 Sprint。
相反，特征驱动开发和测试驱动开发主要被应用于 Sprint 周期中。若是项目进行于开发新功能时期，这个阶段主要推行特征驱动开发。全部测试和开发人员都将本身的工做重心放在新的功能上面，从开发和测试两个方面来完成各自的任务。若是项目进行于测试新功能时期，这个阶段须要将工做的重点挪到测试上来。全部的测试和开发人员都密切关注着目前版本的缺陷情况。测试人员须要在天天的站立会议（Daily Standup Meeting）上报告前一个工做日发现的新缺陷状况，项目经理根据项目进度和缺陷严重性来决定是否修复这些问题。须要及时修复的缺陷是目前 Sprint 中的一个新任务，将由项目经理添加到 Sprint Backlog 上并通知开发人员去修复漏洞。
对于敏捷开发和测试中的审查过程，极限编程中的同行评审（peer review）思想获得了充分应用。代码和文档的审查追求简单而高效。团队成员两两组成一对，互相评审；有时候，一个开发和一个测试人员也能够组成一对，互相协做。这样可以有助于缺陷和问题在第一时间被抹杀在萌芽中。
敏捷开发还有如下几个关键概念 (Key Issues)：
- 迭代过程（Iterative process）
- 用户故事（User stories）
- 任务（Tasks）
- 站立会议（Stand-up meeting）
- 持续集成（Continuous integration）
- 最简方案（Simplest solutions）
- 重构（Re-factoring）
这些概念是敏捷开发中常用到的观点和方法。下面咱们将详细论述测试人员在敏捷软件开发中扮演的角色和职能。
第二部分：敏捷开发中的测试人员
本部分将简要介绍敏捷开发中测试人员所须要具有的素质和职责。
2.1 敏捷开发团队介绍
咱们的敏捷开发团队由四位开发人员、两位测试人员、一位产品设计，一位项目经理和一位产品经理组成（参见图 2）。天天早上十点，在固定的时间和会议室里面，团队会举行站立会议。这时候，团队成员按照既定的顺序向项目经理汇报各自前一天完成的任务，所遇到的困难和当天要完成的任务。同时，项目经理更新 Sprint Backlog（一张制做精良的 Excel 表格），并及时解决每一个人所提出的问题。
图 2. 敏捷开发团队成员
因为敏捷开发要求参与人可以快速而高效得应对变化，因此无形中对测试人员提出很高的要求。
2.2 测试人员须要具有的素质
测试是软件开发中不可或缺的一部分。在敏捷软件开发中亦是如此。不一样的组织给测试人员以不一样的称号：测试开发 (Test Developer)、质量分析员 (Quality Analyst)、软件质量工程师 (Software Quality Engineer) 等。
每一个称号隐含有不一样的职能。以上的称号分别对应如下的能力要求：
- 具备质量检测和编写代码的能力–> 测试开发
- 具备防止缺陷 (Quality Assurance) 和质量控制 (Quality Control) 的能力–> 质量分析员
- 具备开发和执行测试程序的能力 -> 软件质量工程师
总结而言，有三方面的基本素质要求：代码编写（Coding）、测试 (Testing) 和分析 (Analysis)。
在不少其余的开发流程中，各个测试阶段对测试人员的能力有所不一样；有时候侧重分析（好比系统配置测试），有时候侧重代码编写 ( 好比功能测试 )。可是，在敏捷开发流程中，测试人员须要结合这三方面来开展工做，只有这样才能真正反映敏捷测试的本质：简单而高效得应对变化。
2.3 测试人员的主要职责
在敏捷软件开发中，测试人员的职责有三个主要方面：
- 定义质量 (Define Quality)：这应该是软件测试人员的基本职责。敏捷方法鼓励测试人员在 Sprint 计划的时候直接与客户交流，从本身的经验出发，共同为产品功能制定质量要求。
- 交流缺陷（Communication）：敏捷过程强调团队中的交流。开发人员常常会专一于重要而新奇的功能，测试人员应该抓住细节，寻找设计中的“missing door”；另外，开发人员使用单元测试来保证产品的基本质量，测试人员可使用验收测试（Acceptance Test）来鉴定客户需求与实际成果之间的不一致性。
- 及时反馈 (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 都会增量得开发一些功能。因此，测试人员在最初就须要从各类角度来寻找系统需求，探索隐藏的假设。
项目实例：
- 从在线 B2B 公司角度思考
Q：这个搜索框对公司的业务有什么价值？
A：搜索框能够为用户方便得提供商户的目录信息。若是愈来愈多用户使用这个搜索框，能够增长咱们网站的访问量。
- 从用户角度思考
Q：做为查询信息、寻找商业合做伙伴的网站用户，搜索框对我有什么好处？
A：坏处：找到一家商户的地址，过去才发现已经关门歇业
好处：查找商户很简单，只要轻点鼠标
不快：有时候在寻找一类商户，却记不清楚具体名字
- 从程序员角度思考
Q：一个搜索框的最简单实现方法是什么？
A：一个有 text input 和 search button 组成的 form；后台经过 server 程序将符合类型和地址的商户名从数据库中取出，返回给用户；每一个返回项包括商户的名称、地址和评价意见。
- 寻找这些观点中的问题
Q：搜索框如何在用户忘记具体名字的时候提醒用户？
A：在初版本中实现比较困难。可让用户输入至少一个类型来提升模糊查找的效果。
- 最后寻找到隐藏的假设
以上的思考让测试人员对系统的隐含假设更加清晰：
首先，系统应该可以在高峰时候处理 200 条搜索请求和 1000 个鼠标点击事件。
其次，用户能够在已经查找到的内容中继续查找
最后，系统提供一个商户类别清单；若是用户选择商户类别而忘记具体名字，系统提供模糊查询。
在敏捷开发中，这些假设能够做为用户故事记录下来，从而指导将来系统的开发和测试。
3.2.2 设计概要的验收测试用例
定义完一系列用户故过后，测试人员就能够着手设计概要的验收测试用例。正如咱们在前文论述，不一样于单元测试，验收测试检查系统是否知足客户的预期，也就是用户故事是否可以实现。因而，测试人员能够根据每条用户故事来扩展，寻找其中的“动做”，而后为每条“动做”制定正例和反例。
项目实例：
| 动做 | 数据 | 期待的结果 |
|---|---|---|
| 搜索 | 一组能成功搜索到的（类别，位置）数据 | 在该类别和位置条件下的一组商户信息 |
| 搜索 | 一组不能成功搜索到的（类别，位置）数据 | 空列表 |
3.3 迭代 Sprint 阶段
当一个 Sprint 周期正式开始时，项目经理将制定该周期的具体开发和测试任务。在按期的 Sprint 计划会议（Planning Meeting）上，每位团队成员都要提供本身在将来一个 Sprint 周期中的休假和培训计划。另外，每一个团队能够根据各自团队成员的能力和工做经验，适当设定一个工做负载值（Load Factor）。好比，咱们团队的工做负载值为 75%，也就是说每一个人平均天天工做 6 小时（以 8 小时计算）。接着，你们就能够开始分配任务。
当开发团队开始编码和单元测试时，测试人员的工做重点包括：估算验收测试的时间、估算测试框架的搭建、详细设计验收测试和编写验收测试代码。第两个主要活动通常在项目初期的 Sprint 周期中完成。其余的三个主要活动将在接下来的多个 Sprint 周期中视状况迭代进行。下面咱们将具体介绍每一个主要活动。
3.3.1 估算验收测试时间
在软件开发初期，须要估算时间以制定计划。这一点在敏捷开发中应用更加普遍。若是之前的开发模式须要测试人员估算一个软件版本发行的计划（这样的计划一般会延续几个月），那么如今则要在每一个 Sprint 机会会议上估算两周到一个月的任务。此外，在天天的站立会议上，测试人员须要不断得更新本身的估算时间，以应对变化的需求。因此，每一个测试人员都应该具有必定的估算任务能力。下面咱们将介绍两个通用的估算测试计划的方法：
- 快速而粗糙的方法
从经验而言，测试一般占项目开发的三分之一时间。若是一个项目开发估计要 30 天 1 人，那么测试时间为 10 天 1 人。
项目实例：
搜索框的开发估计须要 78 天 1 人完成。可是，考虑到系统有模糊搜索的功能，因此测试任务可能会占 40％左右，大概 31 天 1 人。下面列出了具体的任务：
| 任务 | 估计时间 |
|---|---|
| 设计测试用例，准备测试数据（搜索数据集） | 8 |
| 加载数据集 | 2 |
| 编写自动测试代码 | 18 |
| 执行测试和汇报结果 | 3 |
| 总结 | 31 |
- 细致而周全的方法
这个方法从测试任务的基本步骤出发，进行详细分类。其中包括 :
- 测试的准备（设计测试用例、准备测试数据、编写自动测试代码并完善代码）
- 测试的运行（创建环境、执行测试、分析和汇报结果）
- 特殊的考虑
项目实例：
估算单个测试任务的事例参见下表：
| 测试 | 准备 | 运行 | 特殊考虑 | 估算 | ||
|---|---|---|---|---|---|---|
| 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 周期是发布周期，那么测试人员须要准备执行回归测试。下面咱们来详细了解每一个测试活动。
3.4.1 重构验收测试
正如上文所说起，敏捷开发是以迭代方式进行的，功能在每次迭代中推陈出新。因而，验收测试用例常常须要修改或者添加，相应的验收测试代码也须要删减。这部分工做若是时间花销很大，最好在估算的时候一并提出。
项目实例：
在下一个 Sprint 周期中，咱们须要实现以前没有实现的“模糊查找”功能。测试人员要在新的 Sprint 周期中更新原来的验收测试用例，在测试“搜索”模块中添加模糊查找测试。从新估算的测试任务参加下表：
| 任务 | 估计时间 |
|---|---|
| 设计测试用例，准备测试数据（模糊搜索数据集） | 2 |
| 加载数据集 | 1 |
| 编写自动测试代码 | 3 |
| 执行测试和汇报结果 | 2 |
| 总结 | 8 |
3.4.2 执行验收测试
验收测试能够分为两大类，基本验证测试和功能测试。若是是基本验证测试，推荐开发人员在运行完单元测试和提交代码前直接运行自动测试脚本。若是是功能测试，能够在每一个 Sprint 后期，新功能代码提交后，由测试人员单独执行。
敏捷开发的开发和测试是相辅相成的。一旦基本验证测试出现问题，那就说明开发人员的实现违反了最初客户定义的需求，因此不可以提交。若是功能测试出现问题，那么测试人员要及时与开发人员沟通。若是是缺陷，需及时上报给项目经理，并在天天站立会议中提出；若是不是，那么继续下一项任务。这个过程充分体现了敏捷开发所提倡的团队交流机制。
3.4.3 执行回归测试
在发布周期中，测试人员所肩负的任务很是重要，由于这是产品发布前的最后质量检验。
首先，要创建一套自动生成 build、运行自动测试代码、手工执行测试用例并汇总测试结果的框架。估算方法参加上文。
其次，按期执行各种测试，包括功能和系统测试。
最后，要整理以前在每一个特征测试周期中出现的问题。若是已经整理并归类为回归测试用例，那么只要定时执行就能够了；不然，需一一添加。若是用例已经被自动化，能够直接运行；若是是手工测试，测试人员须要按照测试用例进行操做，最后汇总测试结果。这部分测试就是所谓的回归测试。
总结
以上咱们回顾了敏捷测试在整个项目开发中的基本流程。详细介绍了各阶段存在的主要测试活动，结合实际项目，叙述每一个测试活动的最佳实践。
最后，咱们来探讨一下测试中的两个问题：手工测试和测试报告。
手工测试和自动测试是两个主要的测试类型。考虑到敏捷开发的高效性，自动测试会优于手工测试。手工测试有两个主要的缺点：不可靠和容易被遗忘。好比，在文中的搜索实例中，一旦咱们从新创建索引，那么先前在搜索文本中出现的文字错误就没法重现。另外，当测试人员循序渐进得手工完成一个一个测试用例时，他们很容易遗忘一些特殊的测试用例，不少缺陷所以而被埋没。敏捷测试主张一些基本的验收测试能够被自动化；对一些涉及系统方面的测试，手工测试比较适合。
测试报告是反映一个测试团队工做的最好成果。为适应敏捷开发的节奏，测试报告能够以网页的形式发布在内部的 web 服务器上，在一些问题区域上标注鲜明的色彩，用来警示团队中的每一个人。
综上所述，本文详细谈论了敏捷开发中测试的各项任务。但愿本文有助于正在使用敏捷模式或者打算使用敏捷模式的团队更好得理解敏捷测试。
参考资料
学习
- 阅读 Wikipedia 上有关 敏捷软件开发 的讨论。
- “Agile Software Development with Scrum”（Ken Schwaber and Mike Beedle，2002 年）讨论了如何使用 SCRUM 来快速得实现极限编程，同时生产出高质量的软件产品。
- “Testing Extreme Programming”（Lisa Crispin and Tip House，2003 年）讨论了极限编程中是测试人员的角色，地位；而后，详细叙述了在极限编程周期中的各个测试任务。
- 访问 IBM developerWorks 中国网站 Rational 专区，得到关于 IBM Rational 软件交付平台（Rational Software Delivery Platform）产品的技术资源和最佳实践。
- 订阅 Rational Edge 中文版，获取软件开发领域的最佳实践。
- 订阅 IBM developerWorks 时事通信，一份关于 developerWorks 指南、文章、下载、社区活动、网络广播和技术讲座的电子周刊。
- 学习 Hello World 系列教程，这是学习 IBM 软件工具的快速通道。在每一篇教程中，都会有快速入门产品演示动画。您能够经过其中的动画演示快速浏览如何使用 IBM 软件完成开发任务。
得到产品和技术
- 访问 IBM Rational 软件交付平台 V7 专题，了解 Rational V7 产品的方方面面。
- 获取免费的 Rational 软件工具包系列，了解最新的 IBM Rational 软件开发工具技术文档和资源。
- 下载免费的 IBM Rational 试用版软件，了解 IBM Rational 软件的最新特性。
- 获取更多 IBM 试用版软件，并熟练掌握来自 DB2®、Lotus®、Tivoli®，以及 WebSphere® 的开发工具和中间件产品，用这些试用版软件开发您的下一个项目。这些试用版软件能够免费直接从 developerWorks 下载。
讨论
- 参加 Rational 大学，与 IBM Rational 专家一块儿分享 Rational 产品最佳实践。
- 查看 developerWorks 博客 并加入 developerWorks 社区。
请 登陆 或 注册 后发表评论。
注意：评论中不支持 HTML 语法