敏捷软件开发是目前十分流行,并在业界逐步推广的软件开发模式。不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。本文将结合一个软件项目实例,基于项目开发的不同阶段,详细介绍每个阶段的主要测试活动。文中将分析每个主要测试活动的前提条件和目标任务,并根据实例推荐最佳的解决方案。
第一部分:敏捷软件开发简介
敏捷软件开发(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)思想得到了充分应用。代码和文档的审查追求简单而高效。团队成员两两组成一对,互相评审;有时候,一个开发和一个测试人员也可以组成一对,互相协作。这样能够有助于缺陷和问题在第一时间被抹杀在萌芽中。