(转载)从一个实例详解敏捷测试的最佳实践
上一篇 / 下一篇 2009-02-20 13:55:20 / 个人分类：测试工作讨论
从一个实例详解敏捷测试的最佳实践 |  |
|
2009 年 2 月 16 日 敏捷软件开发是目前十分流行，并在业界逐步推广的软件开发模式。不同与传统的软件开发模式，敏捷开发模式有着自己鲜明的价值和方法。其中，敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求，带来了新的挑战。本文将结合一个软件项目实例，基于项目开发的不同阶段，详细介绍每个阶段的主要测试活动。文中将分析每个主要测试活动的前提条件和目标任务，并根据实例推荐最佳的解决方案。 敏捷软件开发（Agile Software Development）初起于九十年代中期。最早是为了与传统的瀑布软件开发模式（waterfall model）相比较，所以当时的方法叫做轻量级方法（Lightweight methods）。二十世纪初，17 位该方法的倡导者建立了敏捷联盟（Agile Alliance），并将该软件开发方法命名为敏捷软件开发过程。 敏捷联盟在成立之初总结了四条基本的价值原则：
基于这四点原则，敏捷软件开发有着自己独特的流程（参见图 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)：
这些概念是敏捷开发中经常使用到的观点和方法。下面我们将详细论述测试人员在敏捷软件开发中扮演的角色和职能。
本部分将简要介绍敏捷开发中测试人员所需要具备的素质和职责。 我们的敏捷开发团队由四位开发人员、两位测试人员、一位产品设计，一位项目经理和一位产品经理组成（参见图 2）。每天早上十点，在固定的时间和会议室里面，团队会举行站立会议。这时候，团队成员按照既定的顺序向项目经理汇报各自前一天完成的任务，所遇到的困难和当天要完成的任务。同时，项目经理更新 Sprint Backlog（一张制作精良的 Excel 表格），并及时解决每个人所提出的问题。 图 2. 敏捷开发团队成员  由于敏捷开发要求参与人能够快速而高效得应对变化，所以无形中对测试人员提出很高的要求。 测试是软件开发中不可或缺的一部分。在敏捷软件开发中亦是如此。不同的组织给测试人员以不同的称号：测试开发 (Test Developer)、质量分析员 (Quality Analyst)、软件质量工程师 (Software Quality Engineer) 等。 每个称号隐含有不同的职能。以上的称号分别对应以下的能力要求：
总结而言，有三方面的基本素质要求：代码编写（Coding）、测试 (Testing) 和分析 (Analysis)。 在很多其他的开发流程中，各个测试阶段对测试人员的能力有所不同；有时候侧重分析（比如系统配置测试），有时候侧重代码编写 ( 比如功能测试 )。但是，在敏捷开发流程中，测试人员需要结合这三方面来开展工作，只有这样才能真正反映敏捷测试的本质：简单而高效得应对变化。 在敏捷软件开发中，测试人员的职责有三个主要方面：
以上总结了测试人员在敏捷开发中的需要展现的能力和担负的任务，下面请跟随一个项目实例来详细了解敏捷测试的最佳实践。
本部分结合一个软件项目，详细介绍项目流程中的主要测试活动，每个活动的前提条件和目标任务等。 项目介绍：根据一家在线 B2B 公司的要求，我们将为其开发一款类似于谷歌的搜索服务。作为 Web Service，该服务可以内嵌于网页中。当用户输入关键词并选择商户的类型和位置后，系统会返回具体商户的列表（参见图 3）。 图 3. 项目实例图  典型的敏捷开发和测试活动参见下表。它主要由三部分构成，从最初的用户故事设计和发布计划，到几次 Sprint 周期的迭代开发和测试，以及最后的产品发布阶段。每个时间段都有相应的测试活动。通常 Sprint 周期被分成两类：特征周期（Feature Sprint）和发布周期（Release Sprint）。特征周期主要涉及新功能的开发和各类测试。发布周期则会结合计划，确定新版本功能，然后对最新的功能进行测试。
在迭代的 Sprint 周期中，开发部分可以根据传统步骤分成编码和单元测试、重构和集成。需要指出的是，重构和集成是敏捷开发的 Sprint 迭代中不可忽视的任务。如果在新的 Sprint 周期中要对上次的功能加以优化和改进，必然离不开重构和集成。 在每个 Sprint 周期结束前，测试团队将提交针对该 Sprint 周期或者上个 Sprint 周期中已完成的功能的验收测试（在实际项目中，测试团队的进度通常会晚于开发团队）。这样一来，开发团队可以运行验收测试来验证所开发的功能目前是否符合预期。当然，这个预期也是在迭代中不断变化和完善的。 当产品的所有功能得以实现，测试工作基本结束后，就进入了发布周期。此时，测试团队的任务相对较多。 以上，我们概述了敏捷开发的主要活动。下面我们将对各阶段相应的测试活动作详细的介绍和分析。首先是用户故事设计和发布阶段。 在用户故事和发布计划阶段，项目经理和产品经理会根据客户的需求，制定概要的产品发布日程计划。此时，测试人员可以和开发人员一起学习新的功能，了解客户的需求。其中，有两个主要活动：寻找隐藏的假设和设计概要的验收测试用例。 3.2.1 寻找隐藏的假设 正如前文所述，开发人员通常关注一些重要的系统功能而忽视细节。此外，敏捷开发倡导简单的实现方案，每个开发 Sprint 周期不可能将功能完美得实现；相反，每个 Sprint 都会增量得开发一些功能。所以，测试人员在最初就需要从各种角度来寻找系统需求，探索隐藏的假设。 项目实例：
Q：这个搜索框对公司的业务有什么价值？
Q：作为查询信息、寻找商业合作伙伴的网站用户，搜索框对我有什么好处？ 好处：查找商户很简单，只要轻点鼠标
Q：一个搜索框的最简单实现方法是什么？
Q：搜索框如何在用户忘记具体名字的时候提醒用户？
以上的思考让测试人员对系统的隐含假设更加清晰： 首先，系统应该能够在高峰时候处理 200 条搜索请求和 1000 个鼠标点击事件。 在敏捷开发中，这些假设可以作为用户故事记录下来，从而指导未来系统的开发和测试。 3.2.2 设计概要的验收测试用例 定义完一系列用户故事后，测试人员就可以着手设计概要的验收测试用例。正如我们在前文论述，不同于单元测试，验收测试检查系统是否满足客户的预期，也就是用户故事是否能够实现。于是，测试人员可以根据每条用户故事来扩展，寻找其中的“动作”，然后为每条“动作”制定正例和反例。 项目实例：
当一个 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 人。下面列出了具体的任务：
这个方法从测试任务的基本步骤出发，进行详细分类。其中包括 :
项目实例： 估算单个测试任务的事例参见下表：
估算多个测试任务的汇总参见下表：
3.3.2 估算测试框架的搭建 测试框架是自动测试必不可少的一部分工作。由于敏捷开发流程倡导快速而高效得完成任务，这就要求一定的自动测试率。一个完善的测试框架可以大大提高测试效率，及时反馈产品的质量。 在敏捷开发流程中，在第一个 Sprint 周期里，需要增加一项建立测试框架的任务。在随后的迭代过程中，只有当测试框架需要大幅度调整时，测试团队才需要考虑将其单独作为任务，否则可以不用作为主要任务罗列出来。 项目实例： 考虑该项目刚刚进入测试，需要为此建立一个测试框架。于是，在原先的估算中多增加一些任务。
3.3.3 详细设计验收测试用例 完成对测试任务的估算，接着就可以着手详细设计验收测试用例。我们可以对概要设计中的测试用例进行细化，根据不同的测试环境、测试数据以及测试结果，编写更详细的测试用例。另外，可以结合几个用例，完成一个复杂的测试操作。 由于敏捷开发的流程是不断迭代的过程，所以很多复杂的功能可能会在未来的 Sprint 周期中被优化。对测试人员而言，一个有效的方法是尽量将一些验证基本功能的测试用例作为基本验证测试用例（Basic Verification Test Case）在第一时间实现自动化；而对一些复杂的功能测试用例，可以先采用手工的方法测试，直到在未来 Sprint 周期中该功能达到稳定时候再考虑自动化。此外，对测试中出现的缺陷可以设计回归测试用例（Regression Test Case），为其编写自动测试代码，使得此类问题在发布周期（Release Sprint）时可以顺利而高效得进行验证。 项目实例： 基本验证测试用例：
功能测试用例：
3.3.4 编写验收测试用例 敏捷开发不提倡撰写太多的文档，提倡直接编写测试用例。此外，测试人员和客户应取得良好的沟通，将这些需求总结下来，转化成验收测试用例。如果资源充足，最好对验收测试用例建立版本控制机制。 考虑到需求在每一轮 Sprint 周期中会不断得变化，测试团队要控制测试的自动化率，正确估计未来功能的增减。自动化率过高会导致后期大量测试代码需要重构，反而增加很多工作量。 在一个 Sprint 周期结束时，团队要举行一个回顾会议（Retrospective Meeting）。团队成员可以在会议上畅所欲言，指出在过去一个 Sprint 周期中可行的，不可行的和有待改进的地方。待改进之处将在项目经理监督下于未来的 Sprint 周期中实现。 由于敏捷开发倡导增量开发，当新的 Sprint 开始时，测试团队需要根据新 Sprint 周期的开发进度及时重构验收测试。如果新 Sprint 周期没有具体的新功能开发，测试团队可以将精力集中在执行验收测试和寻找缺陷上。 如果下一个 Sprint 周期是发布周期，那么测试人员需要准备执行回归测试。下面我们来详细了解每个测试活动。 3.4.1 重构验收测试 正如上文所提及，敏捷开发是以迭代方式进行的，功能在每次迭代中推陈出新。于是，验收测试用例经常需要修改或者添加，相应的验收测试代码也需要删减。这部分工作如果时间花销很大，最好在估算的时候一并提出。 项目实例： 在下一个 Sprint 周期中，我们需要实现之前没有实现的“模糊查找”功能。测试人员要在新的 Sprint 周期中更新原来的验收测试用例，在测试“搜索”模块中添加模糊查找测试。重新估算的测试任务参加下表：
3.4.2 执行验收测试 验收测试可以分为两大类，基本验证测试和功能测试。如果是基本验证测试，推荐开发人员在运行完单元测试和提交代码前直接运行自动测试脚本。如果是功能测试，可以在每个 Sprint 后期，新功能代码提交后，由测试人员单独执行。 敏捷开发的开发和测试是相辅相成的。一旦基本验证测试出现问题，那就说明开发人员的实现违反了最初客户定义的需求，所以不能够提交。如果功能测试出现问题，那么测试人员要及时与开发人员沟通。如果是缺陷，需及时上报给项目经理，并在每天站立会议中提出；如果不是，那么继续下一项任务。这个过程充分体现了敏捷开发所提倡的团队交流机制。 3.4.3 执行回归测试 在发布周期中，测试人员所肩负的任务非常重要，因为这是产品发布前的最后质量检验。 首先，要建立一套自动生成 build、运行自动测试代码、手工执行测试用例并汇总测试结果的框架。估算方法参加上文。 其次，定期执行各类测试，包括功能和系统测试。 最后，要整理之前在每个特征测试周期中出现的问题。如果已经整理并归类为回归测试用例，那么只要定时执行就可以了；否则，需一一添加。如果用例已经被自动化，可以直接运行；如果是手工测试，测试人员需要按照测试用例进行操作，最后汇总测试结果。这部分测试就是所谓的回归测试。
以上我们回顾了敏捷测试在整个项目开发中的基本流程。详细介绍了各阶段存在的主要测试活动，结合实际项目，叙述每个测试活动的最佳实践。 最后，我们来探讨一下测试中的两个问题：手工测试和测试报告。 手工测试和自动测试是两个主要的测试类型。考虑到敏捷开发的高效性，自动测试会优于手工测试。手工测试有两个主要的缺点：不可靠和容易被遗忘。比如，在文中的搜索实例中，一旦我们重新建立索引，那么先前在搜索文本中出现的文字错误就无法重现。另外，当测试人员按部就班得手工完成一个一个测试用例时，他们很容易遗忘一些特殊的测试用例，很多缺陷因此而被埋没。敏捷测试主张一些基本的验收测试可以被自动化；对一些涉及系统方面的测试，手工测试比较适合。 测试报告是反映一个测试团队工作的最好成果。为适应敏捷开发的节奏，测试报告可以以网页的形式发布在内部的 web 服务器上，在一些问题区域上标注鲜明的色彩，用来警示团队中的每个人。 综上所述，本文详细谈论了敏捷开发中测试的各项任务。希望本文有助于正在使用敏捷模式或者打算使用敏捷模式的团队更好得理解敏捷测试。 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
TAG:
标题搜索
日历
|
|||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | ||||||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 | |||
| 12 | 13 | 14 | 15 | 16 | 17 | 18 | |||
| 19 | 20 | 21 | 22 | 23 | 24 | 25 | |||
| 26 | 27 | 28 | 29 | 30 | 31 | ||||
我的存档
数据统计
- 访问量: 75976
- 日志数: 59
- 图片数: 5
- 文件数: 1
- 书签数: 1
- 建立时间: 2008-01-21
- 更新时间: 2013-05-29
