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

从一个实例详解敏捷测试的最佳实践简介：敏捷软件开发是目前十分流行，并在业界逐步推广的软件开发模式。不同与传统的软件开发模式，敏捷开发模式有着自己鲜明的价值和方法。其中，敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求，带来了新的挑战。本文将结合一个软件项目实例，基于项目开发的不同阶段，详细介绍每个阶段的主要测试活动。文中将分析每个主要测试活动的前提条件和目标任务，并根据实例推荐最佳的解决方案。第一部分：敏捷软件开发简介敏捷软件开发（AgileSoftwareDevelopment）初起于九十年代中期。最早是为了与传统的瀑布软件开发模式（waterfallmodel）相比较，所以当时的方法叫做轻量级方法（Lightweightmethods）。二十世纪初，17位该方法的倡导者建立了敏捷联盟（AgileAlliance），并将该软件开发方法命名为敏捷软件开发过程。敏捷联盟在成立之初总结了四条基本的价值原则：1.人员交流重于过程与工具（Individualsandinteractionsoverprocessesandtools）2.软件产品重于长篇大论（Workingsoftwareovercomprehensivedocumentation）3.客户协作重于合同谈判（Customercollaborationovercontractnegotiation）4.随机应变重于循规蹈矩（Respondingtochangeoverfollowingaplan）基于这四点原则，敏捷软件开发有着自己独特的流程（参见图1）。图1.敏捷软件开发流程整个过程中夹杂了很多在敏捷开发前己经出现的软件开发方法，包括极限编程（ExtremeProgramming,1996）、Scrum（1986）、特征驱动开发（FeatureDrivenDevelopment），测试驱动开发（TestDrivenDevelopment）等。这些方法在敏捷软件开发流程的各个阶段都有充分的体现和应用。例如，Scrum主要着重于项目管理，团队中的项目经理（Scrummaster）需要在每个客户需求到来的时候制定Sprint的周期，定义每个Sprint的目标、分派任务、进行监督、最后总结得失并开始计划新的Sprint。相反，特征驱动开发和测试驱动开发主要被应用于Sprint周期中。如果项目进行于开发新功能时期，这个阶段主要推行特征驱动开发。所有测试和开发人员都将自己的工作重心放在新的功能上面，从开发和测试两个方面来完成各自的任务。如果项目进行于测试新功能时期，这个阶段需要将工作的重点挪到测试上来。所有的测试和开发人员都密切关注着目前版本的缺陷状况。测试人员需要在每天的站立会议（DailyStandupMeeting）上报告前一个工作日发现的新缺陷情况，项目经理根据项目进度和缺陷严重性来决定是否修复这些问题。需要及时修复的缺陷是目前Sprint中的一个新任务，将由项目经理添加到SprintBacklog上并通知开发人员去修复漏洞。对于敏捷开发和测试中的审查过程，极限编程中的同行评审（peerreview）思想得到了充分应用。代码和文档的审查追求简单而高效。团队成员两两组成一对，互相评审；有时候，一个开发和一个测试人员也可以组成一对，互相协作。这样能够有助于缺陷和问题在第一时间被抹杀在萌芽中。敏捷开发还有以下几个关键概念(KeyIssues)：1.迭代过程（Iterativeprocess）2.用户故事（Userstories）3.任务（Tasks）4.站立会议（Stand-upmeeting）5.持续集成（Continuousintegration）6.最简方案（Simplestsolutions）7.重构（Re-factoring）这些概念是敏捷开发中经常使用到的观点和方法。下面我们将详细论述测试人员在敏捷软件开发中扮演的角色和职能。回页首第二部分：敏捷开发中的测试人员本部分将简要介绍敏捷开发中测试人员所需要具备的素质和职责。2.1敏捷开发团队介绍我们的敏捷开发团队由四位开发人员、两位测试人员、一位产品设计，一位项目经理和一位产品经理组成（参见图2）。每天早上十点，在固定的时间和会议室里面，团队会举行站立会议。这时候，团队成员按照既定的顺序向项目经理汇报各自前一天完成的任务，所遇到的困难和当天要完成的任务。同时，项目经理更新SprintBacklog（一张制作精良的Excel表格），并及时解决每个人所提出的问题。图2.敏捷开发团队成员由于敏捷开发要求参与人能够快速而高效得应对变化，所以无形中对测试人员提出很高的要求。2.2测试人员需要具备的素质测试是软件开发中不可或缺的一部分。在敏捷软件开发中亦是如此。不同的组织给测试人员以不同的称号：测试开发(TestDeveloper)、质量分析员(QualityAnalyst)、软件质量工程师(SoftwareQualityEngineer)等。每个称号隐含有不同的职能。以上的称号分别对应以下的能力要求：1.具有质量检测和编写代码的能力–测试开发2.具有防止缺陷(QualityAssurance)和质量控制(QualityControl)的能力–质量分析员3.具有开发和执行测试程序的能力-软件质量工程师总结而言，有三方面的基本素质要求：代码编写（Coding）、测试(Testing)和分析(Analysis)。在很多其他的开发流程中，各个测试阶段对测试人员的能力有所不同；有时候侧重分析（比如系统配置测试），有时候侧重代码编写(比如功能测试)。但是，在敏捷开发流程中，测试人员需要结合这三方面来开展工作，只有这样才能真正反映敏捷测试的本质：简单而高效得应对变化。2.3测试人员的主要职责在敏捷软件开发中，测试人员的职责有三个主要方面：1.定义质量(DefineQuality)：这应该是软件测试人员的基本职责。敏捷方法鼓励测试人员在Sprint计划的时候直接与客户交流，从自己的经验出发，共同为产品功能制定质量要求。2.交流缺陷（Communication）：敏捷过程强调团队中的交流。开发人员经常会专注于重要而新奇的功能，测试人员应该抓住细节，寻找设计中的“missingdoor”；另外，开发人员使用单元测试来保证产品的基本质量，测试人员可以使用验收测试（AcceptanceTest）来鉴定客户需求与实际成果之间的不一致性。3.及时反馈(Feedback):敏捷过程强调简单而高效。测试人员需要及时反馈产品目前的质量问题。这样一来，团队才可以立刻着手解决。如果传统的流程是一周汇总一次状态的话，敏捷流程要求每天汇总质量问题。在我们的项目中，内部的测试报告会以网页的形式显示在内部站点上。每个团队成员能够随时获取。另外，我们的测试框架提供自助测试(Self-assistantTest)：通过点击测试用例列表中的某个具体用例，开发人员不需要中断测试人员的工作就可以重现缺陷。以上总结了测试人员在敏捷开发中的需要展现的能力和担负的任务，下面请跟随一个项目实例来详细了解敏捷测试的最佳实践。回页首第三部分：敏捷开发中的测试流程本部分结合一个软件项目，详细介绍项目流程中的主要测试活动，每个活动的前提条件和目标任务等。3.1介绍项目实例项目介绍：根据一家在线B2B公司的要求，我们将为其开发一款类似于谷歌的搜索服务。作为WebService，该服务可以内嵌于网页中。当用户输入关键词并选择商户的类型和位置后，系统会返回具体商户的列表（参见图3）。图3.项目实例图典型的敏捷开发和测试活动参见下表。它主要由三部分构成，从最初的用户故事设计和发布计划，到几次Sprint周期的迭代开发和测试，以及最后的产品发布阶段。每个时间段都有相应的测试活动。通常Sprint周期被分成两类：特征周期（FeatureSprint）和发布周期（ReleaseSprint）。特征周期主要涉及新功能的开发和各类测试。发布周期则会结合计划，确定新版本功能，然后对最新的功能进行测试。敏捷开发的主要活动测试活动用户故事设计寻找隐藏的假设发布计划设计概要的验收测试用例迭代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：一个有textinput和searchbutton组成的form；后台通过server程序将符合类型和地址的商户名从数据库中取出，返回给用户；每个返回项包括商户的名称、地址和评价意见。4.寻找这些观点中的问题Q：搜索框如何在用户忘记具体名字的时候提醒用户？A：在第一版本中实现比较困难。可以让用户输入至少一个类型来提高模糊查找的效果。5.最后寻找到隐藏的假设以上的思考让测试人员对系统的隐含假设更加清晰：首先，系统应该能够在高峰时候处理200条搜索请求和1000个鼠标点击事件。其次，用户可以在已经查找到的内容中继续查找最后，系统提供一个商户类别清单；如果用户选择商户类别而忘记具体名字，系统提供模糊查询。在敏捷开发中，这些假设可以作为用户故事记录下来，从而指导未来系统的开发和测试。3.2.2设计概要的验收测试用例定义完一系列用户故事后，测试人员就可以着手设计概要的验收测试用例。正如我们在前文论述，不同于单元测试，验收测试检查系统是否满足客户的预期，也就是用户故事是否能够实现。于是，测试人员可以根据每条用户故事来扩展，寻找其中的“动作”，然后为每条“动作”制定正例和反例。项目实例：动作数据期待的结果搜索一组能成功搜索到的（类别，位置）数据在该类别和位置条件下的一组商户信息搜索一组不能成功搜索到的（类别，位置）数据空列表3.3迭代Sprint阶段当一个Sprint周期正式开始时，项目经理将制定该周期的具体开发和测试任务。在定期的Sprint计划会议（PlanningMeeting）上，每位团队成员都要提供自己在未来一个Sprint周期