敏捷测试

 

 

框架

 

一绪论

1 背景介绍

 

近年来，社会信息化程度不断提高，人们在生活和工作方方面面对软件的依赖成都越来越高，尤其是金融行业，各种金融产品和交易方式的革新，软件更新越来越快，需求呈爆发式增长，传统的开发方法逐渐不能适应这种周期短，变化快的节奏。2001年，敏捷宣言的诞生，为软件开发团队提供了新思路和新模式，打破了传统的软件过程和软件生命周期的概念。在十多年间，敏捷开发方法逐步从概念化的理念，一点点成熟和规范化，如Scrum敏捷开发方法，XP极限编程敏捷开发方法等具体敏捷方法的提出，凭借其以人为核心，快迭代的特性，成为了许多软件开发团队的选择。

对于软件开发商来说，软件质量的保证也是软件开发过程中需要注重的部分，是企业发展中的核心问题之一。但是，在采用了敏捷开发方法之后，代码的提交频率更高，带来了更多的不确定性，一方面是产品无法快速准确的完成客户需求的风险，另一方面则是在快速迭代中，代码质量降低，缺陷数量增多的风险。因此，越来越多的公司开始发现，传统的测试方法和自动化技术逐渐不能满足当前不断变化的需求和短周期的快迭代模式。在敏捷开发方法下，产品的开发和发布速度大大提高，产品的质量和可靠性成了关注重点，这对软件测试团队是一个极大的挑战。可以说，软件测试在保证产品质量，控制开发成本，提高开发效率等方面是起着举足轻重的作用的，所以，在敏捷开发项目中，软件测试过程也需要应用新的敏捷测试方法。

本人通过在dddd软件Dddd海量数据智能搜索匹配敏捷项目的测试团队中工作，在项目进展初期，测试团队还在应用传统的瀑布模型实施软件测试工作，在时间和资源分配上经常产生需求初期测试人员闲置率高，开发中后期，测试工作量暴增，缺陷发现时间较晚，工作量大的问题。同时，自动化测试实施效率也比较低，过去的自动化回归测试进入时间较晚，无法在最早的时候发现程序缺陷。测试工作面临着巨大的挑战，测试人员工作进入了高投入低产出的恶性循环。对于测试团队来说，急需要一套能够适应敏捷开发方法的测试方法，一个能有指导意义的软件测试模型，不仅能保证产品的质量和可靠性，同时可以降低软件开发的风险和成本，提高开发的效率。

当然在优化测试流程和测试方法的同时，自动化测试实施是其中最为重要的一块。是否能够合理并高效地使用自动化测试来规范测试流程、提高测试效率，是至关重要的。自动化测试能够解放测试人员，在非工作时间完成对新提交代码的验证，让测试人员有更多的精力和时间，着力于对快速变动的软件需求掌握和管理，对测试用例的更新，提高测试工作的准确性和更高的覆盖度。同时，自动化测试中的测试数据能够复用在敏捷开发的整个生命周期之中，一次投入成本，有长期回报。当然，为了能够更好地进行敏捷测试，单一的自动化回归测试是不够的，我们还需要其他种类的自动化工具和管理工具整合起来做二次开发，通过引入自动任务管理软件，加入自动触发机制，在每次代码提交的时候自动触发单元测试和相关的功能测试和回归测试，避免更新不及时，测试不及时的问题，同时通过测试管理工具解决开发测试效率低下的问题。有了这样的统一高效的自动化测试集成系统，可以将测试用例，测试数据，测试脚本，测试报告统一到一起，减少不同步带来的成本，提高测试效率和测试的准确度，优化测试的整体效果。

 

 

 

 

2 国内外对敏捷测试的研究现状

 

 

“敏捷项目对于测试人员来说，是一个领导整个项目过程极好的机会。”AIG Computer Services的Business Group Manager George Wilson说。在敏捷开发羡慕中，不再是开发者掌舵整个过程，将测试人员放在次要的位子，他建议测试人员在整个项目进程中，应该起到领导作用。“还有其他更好的人能消除用户和开发者之间的鸿沟吗？理解什么是必需的，怎样才能达到目标？在发布之前如何确保质量？”这就要求QA team自身在敏捷活动中非常灵活，打破传统测试方法中，测试人员的自我定位和自我认知。

 

事实上，对软件测试的重视也是近几年才有所提升，从对软件测试的定义上，就可以发现，大部分时候，软件测试人员的角色都是次要。

传统的软件测试定义是以人工行为方式或者运用自动化工具执行或测试某个系统的过程。它的目的在于检验被测的软件产品能否满足预先定义的需求或分析期望结果与实际输出结果之间的差别。

就软件测试的发展而言，可大致分为以下几个时期[1]：

论证时期：

早在20 世纪70 年代，C.Baker 区分了软件的“调试”和“测试” ：即认为程序检

查应包括两个目的：一是证明程序能够运行；二是证明程序符合技术任务书的要

求。前者是“调试”的核心任务，后者是“测试”的核心任务。论证时期软件测试的主要目的是证明软件符合它的技术任务书的要求，证明软件不存在错误。测试工作者应用类似结构数学的方法进行论证。这一阶段，缺少测试选择准则的标准，一个软件似乎通过了测试，但仍有许多错误。

破坏性测试时期：

Glonford J. Myers 在这一阶段定义了软件测试的概念：“为了发现错误而执行程

序的过程” 。这个概念说明，如果把程序测试看成是发现错误的过程，而不是证明它完成预期要求的过程，则有可能发现更多的错误。成功的测试是力图让程序执行失败而使查错取得进展的过程。

生命周期评估和预防时期（现状）：

随着软件工程和测试技术的发展，提出了“生命周期测试（Life Cycle Testing）”

这一概念，即测试不只影响软件的编程和运行，同时能够影响软件技术任务书和软件设计，而且在项目开始时需要进行相应的测试工作。项目在一个软件项目一开始就与整个软件开发工作组息息相关。在这一时期，各种软件测试技术以及软件质量保证体系应运而生；软件测试流程被细化分为各个阶段，并且相应的测试技术为各个阶段的软件测试提供保障；与此同时，各种测试模型在软件测试活动中，起着指导作用。

伴随着软件产品不确定的用户需求、更复杂的产品架构、更急迫的交付时间，

传统的软件测试方法虽然具有预备性的特点，但是也存在着诸多缺陷。例如：要

么将编程过程与测试划分为独立不同的阶段，无法满足“尽早地和不断地进行软件测试”的原则；要么将需求、设计、编程、测试串行，无法支持迭代、自发性以及变更调整。.

 

 

为了满足用户的需求、设计出具有更高可靠性的软件产品，敏捷软件过程

（Agile Software Process）被引用于现在软件企业的开发过程中。

敏捷方法在几周或者几个月的时间内完成相对较小的功能，强调尽早的将可能

小的并且可用的功能交付给用户使用，并在整个项目周期中持续改善和增强。在开发过程中，敏捷方法重视频繁的功能交付、重视与客户的交流与沟通，并以迭代式的开发手段强调对变化的快速响应能力。

在实际工作中，XP（极限编程）、SCRUM 等体现敏捷软件过程思想的轻载方法

已经成为热点，并被应用于实际的项目开发活动中。

敏捷的理念在开发过程中渐入佳境，但是现有的软件测试环节却陷入尴尬局

面。现有的软件测试流程依旧较为依赖传统的W 模型，因而这些过程、测试模型

不能满足软件产品对测试行为的要求。因此一种基于敏捷软件过程的软件测试模

型的研究与设计，具备现实意义。

 

 

 

 

 

测试的自动化是最原始的起步阶段，其目的就是将原先手工测试所作的工作转化为自动化代劳。显著的特征就是以工具为中心。如果说测试的自动化是在一个点上下功夫，第二阶段就是在一条线上作战了。“自动化的测试”的内涵更加丰富，它意在将软件测试里的所涉及的各个环节作为一个统一的整体考虑，从测试案例的管理，测试案例的执行到测试报告的展现都有相应的策略及自动化实现，故称“自动化的测试”。第三阶段，在这里软件自动化测试和软件开发再次做一个整合，从自动化流程上，能够达到真正的测试驱动开发，比如coding与unit testing做整合。目前国内软件公司软件自动化测试的实施情况大多处于第一阶段或从第一向第二过渡的阶段。

当传统的测试方式无法适应新的开发模式时，新的测试方法就会诞生并取代原有的不适合的测试方法。自动化测试是轻型开发模式[4]测试活动的另一个优秀思路也是采取轻型开发模式的必要条件之一。在只有测试实现了自动化，回归测试才能实现，重构才能够贯彻，而迭代也才能够进行，才能够迎合敏捷开发的脚步。

目前比较流行的敏捷测试方法有测试驱动开发和相关环境驱动测试等[5]。还有很多国外知名专家按照敏捷的原理为软件测试开发了相应的测试框架，其中最著名的就是Kent Beck等提出的xUnit系列单元测试框架和Ward Cunningham等提出的Framework for Integrated Test(FIT)集成测试框架[6]。xUnit系列提出的比较早，目前已有一套完善的测试工具和方法论来支持了，适用于各种语言的单元测试。FIT框架是当前国内外的研究重点，很多知名的测试专家如Lisa Crispin等都在如何使用FIT进行有效的软件测试方面得出了很多的研究成果。虽然FIT可能是一个不错的解决方案，其关注点集中在测试用例的可读性，以及测试用例和测试代码的分离，但是还是需要更完善的Web自动回归测试和缺陷跟踪，使得敏捷测试管理更规范化。软件测试的工具很多，如测试管理有Mercury Interactive公司的TestDirector和sourceforge的开源项目TestLink、单元测试工具有Xunit系列、自动化测试工具有ThoughtWorks的Selenium框架以及优秀的开源工具Watir等、缺陷跟踪工具有目前业内最成熟知名度最大的Bugzilla和LAMP模式下的Mantis以及轻量级的Web缺陷跟踪工具BugFree。大部分的测试工具都是对测试生命周期的一部分流程进行管理，并没有一个轻量级的工具可以对整个敏捷测试生命周期进行管理，使得测试流程自动化执行。因此，一个可以适合敏捷测试，并且能够管理测试整个生命周期的轻量级的集成框架是本文研究的方向。

 

4研究方向与内容

本文通过对目前敏捷测试过程分析，为了提高敏捷测试的效率和使得敏捷测试管理更加规范化，采用集成多种测试工具和测试管理工具的方案为敏捷测试提供了新的解决方案。通过对回归测试工具、测试管理工具和缺陷跟踪工具的原型的改进分析与设计，实现了一套拥有回归测试、测试管理和缺陷跟踪三大模块并可以应用于敏捷测试生命周期管理的自动化测试集成系统。

文中先经过分析系统各部分的数据格式及集成方案，对系统各个部分进行了详细的需求分析，并找出需要做的集成整合工作及测试工具集成过程中应增加的功能和方法；其次根据需求分析的结果和提出的所要增加改进的功能进行系统设计，并设计数据集成方案中的数据库和文件系统中测试用例和结果文件的管理方式；还根据各部分操作数据方法的不同，设计功能流程；最后介绍了系统的实现及具体实现页面。经过上诉几个步骤，本文实施了一套完整的可应用于敏捷测试的自动化测试集成系统。

本文说明了如何利用良好设计、扩展功能和数据集成的方法组建一个全面的自动化测试集成系统。该系统构造了一个完整的敏捷测试解决方案。

在整个过程中主要完成以下工作：

1. 介绍传统软件测试概念和敏捷测试的概念，通过介绍敏捷测试的管理方法和测试流程的自动化以及集成系统的方法，来说明本文所做工作的必要性。

 

2. 分析开源测试工具，比较各个测试工具的优势和不足，选取需要做集成的开源工具，提出开源工具的集成方案。

3. 对集成系统的各个部分的集成方案进行详细的需求分析，明确集成系统的功能和集成方法。

4. 设计并实现一套适用于敏捷测试需求并且能够管理整个测试生命周期的集成系统。

5. 阐述了部署实施的细节，并构建分布式的回归测试服务器。通过对系统功能实现的测试，说明了系统是如何管理测试生命周期的以及集成系统的优势所在。

 

5 论文结构

论文共分为六章，各章主要内容如下：

第一章：绪论。交代研究背景、国内外研究现状，以及本文的主要研究内容和论文结构。

第二章：相关理论综述。对传统软件测试，敏捷开发理论，敏捷测试理论进行理论描述，概述软件测试相关概念，然后通过介绍和分析敏捷软件开发的核心实质和价值观，提出响应的敏捷测试的概念。然后对比分析传统测试和敏捷测试，提出敏捷测试方法的优势和价值。

第三章：敏捷测试方法与管理。

第四章：自动化集成测试系统的设计与实现。对自动化测试集成系统进行需求分析，提出系统的总体架构，然后重点阐述TestLink二次开发以及TestLink与Selenium和Bugzilla的集成设计和实现细节。最后是系统的部署和运行，以及对可用性的测试与分析。

第五章：敏捷测试在实践中的效果评估。具体分析整套敏捷测试方案在Dddd项目中的应用与实践效果的分析与评估。

第六章：总结与展望。概括总结敏捷测试方案具体实施中的测试方法，测试管理和自动化技术的优化，并提出存在的可以改进的问题。

 

二相关理论综述

伴随着软件产业的发展和近年来软件开发领域理论和实践的积累和日趋成

熟，软件测试的技术、方法及工具也随着这种快速发展不断地被更新。与先进的

软件开发方法相适应的软件测试也是提高软件整体质量和开发效率的关键。本章

在先论述软件测试基本理论的基础上，阐述了当下处于快速发展时期的敏捷测试

及自动化测试。

1 软件测试概述

软件测试是有计划、有组织和系统性的软件质量保证活动，是软件开发中不可或缺的环节，也是软件工程的重要组成部分。软件测试就是软件在投入运行前，对软件需求分析、设计规格和编码的最终审查，是保证软件质量的关键步骤。软件测试是为了发现错误而执行程序，并根据软件开发各阶段的规格说明和程序的内部结构面精心设计的软件工程活动。

一个软件生命周期包括制定计划、需求分析定义、软件设计、程序编码、软件测试、软件运行、软件维护、软件停用等八个阶段。软件测试的根本目的是保证软件质量，软件质量内涵包括：正确性、可靠性、可维护性、可读性、结构化、可测试性、可移植性、可扩展性、用户界面友好性、易学、易用、健壮性等。软件测试不仅仅是对程序的测试，而是贯穿于软件定义和开发的整个过程．

因此，软件开发过程中产生的需求分析、概要设计、详细设计以及编码等各个阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都是软件测试的对象。软件测试在软件生命周期中，主要横跨单元测试阶段和综合测试阶段，即要在每个模块编写出以后进行测试、在完成单元测试后进行的测试，如集成测试、系统测试、验收测试等。

软件测试设计的关键问题主要包括四个方面：一、测试由谁来执行。通常软件产品的开发设计包括开发者和测试者两种角色。开发者通过开发形成产品，测试者通过测试来检验产品中是否存在缺陷。通常的测试工作是由开发者负责完成自己开发的代码的单元测试，测试者承担系统测试。二、测试什么。测试经验表明，通常表现在程序中的故障，并不一定是由于编码导致的问题，所以要排除故障也要追溯到前期的工作。事实上，软件需求分析、设计和实施阶段是软件故障的主要来源。三、什么时候进行测试。软件测试可以在开发中进行测试，也可以在各个模块装配成为一个完整的程序之后再进行测试。四、怎样进行测试。对软件进行测试就是根据软件的功能规范说明和程序实现，利用各种测试方法，生成有效的测试用例，对执行测试。

软件测试的目的是要证明程序中有故障存在，并找到最多的错误，所以测试用例必须要计划周全，应从软件容易出现缺陷和错误的方面作为出发点，尽量多的发现问题。软件测试的目的是检查系统是否符合需求，以及发现软件中存在的错误。软件测试的原则是尽早并及时测试软件，由专人进行软件测试，测试用例应完整完全，严格执行测试计划，保存测试的分析报告以备今后应用。

软件测试的方法主要有白盒测试法和黑盒测试法。白盒测试法又称为结构测试、逻辑驱动测试或基于程序的测试，多运用在单元测试中。黑盒测试法又被称为功能性测试、数据驱动测试或基于规格说明的测试，是在不考虑程序结构和内部特性的基础上，检查输入与输出之间的关系是否符合要求，多用系统测试中【3，·】。

 

2.1.1传统软件测试的定义

Glenford J.Myers曾对软件测试的目的提出过以下观点[7]：

l 测试是为了发现程序中的错误而执行程序的过程。

l 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。

l 成功的测试是发现了至今为止尚未发现的错误的测试。

 

这种观点指出软件测试是以查找错误为中心，而不是为了演示软件的正确性。但是从字面意思理解，很多人会认为发现错误是软件测试的唯一目的，实际上并非如此，这些是远远不够的。

软件测试不仅仅是为了找出错误。通过分析错误产生的原因和错误的发展趋势，可以帮助项目管理者发现当前软件开发过程中的问题关键所在，以便及时改进；这种分析也能帮助测试人员设计出有针对性的测试方法，改善测试的效率和有效性；没有发现错误的测试也是有价值的，完整的测试是评定软件质量[8]的一种方法；另外，根据测试目的的不同，还有回归测试、压力测试、性能测试等，分别为了检验修改或优化过程是否引发新的问题、软件所能达到处理能力和是否达到预期的处理能力等。

软件测试本身的范围及外延的变化在很大程度上取决于软件开发的过程。最初，在传统开发模型里面，软件测试对开发所起的唯一的作用就是发现软件开发过程中引入的缺陷，但是软件测试除了能够发现缺陷之外，还能够帮助开发团队来提高产品的质量，这是一个更大的目标，对于整个组织而言，也产生了更大的效果[9]。

 

2.1.2传统软件测试带来的问题

软件测试与软件开发过程息息相关，软件测试在所有的软件开发过程中都是最重要的部分。在软件开发过程中，一方面通过测试活动验证所开发的软件在功能上满足软件需求中描述的每一条特性，性能上满足客户要求的负载压力和相应的响应时间、吞吐量要求；另一方面，面向市场和客户，开发团队还要满足在预算范围内尽快发布软件的要求。

传统的软件测试流程一般是先在软件开发过程中进行少量的单元测试，然后在整个软件开发结束阶段，集中进行大量的测试，包括功能和性能的集成测试和系统测试。随着开发的软件项目越来越复杂，传统的软件测试流程不可避免地给测试工作带来以下问题[10]：

问题一：项目进度难于控制，项目管理难度加大。

大量的软件错误往往只有到了项目后期系统测试时才能够被发现，解决问题所花的时间很难预料，经常导致项目进度无法控制，同时在整个软件开发过程中，项目管理人员缺乏对软件质量状况的了解和控制，加大了项目管理难度。

问题二：对于项目风险的控制能力较弱。

项目风险在项目开发较晚的时候才能够真正降低。往往是经过系统测试之后，才真正确定该设计是否能够满足系统功能、性能和可靠性方面的需求。

问题三：软件项目开发费用超出预算。

在整个软件开发周期中，错误发现的越晚，单位错误修复成本越高，错误的延迟解决必然导致整个项目成本的急剧增加。

这些问题势必会导致整个项目的质量、进度和成本的出现问题，而项目的质量、项目的进度、项目的成本共同决定了项目本身是否成功。人们在失败中吸取教训，软件开发和测试的过程也在挫折中不断完善。

2 敏捷测试概述

 

2.2.1敏捷开发

l 敏捷开发的核心内容

 

随着软件开发过程的不断完善与发展，敏捷开发的概念被提了出来。敏捷软件开发宣言，正式宣布了对四种敏捷开发核心价值和十二条原则，可以指导迭代的以人为中心的软件开发方法[11]。

敏捷软件开发关注保持简洁的代码，经常性测试以及及时地交付应用的功能模块。敏捷宣言的创建是为了替代文档驱动的繁重的软件开发流程，例如瀑布式方法。

敏捷宣言强调的敏捷软件开发的四个核心价值是[12]：

1) 个人和互动高于流程和工具

2) 工作软件高于理解文档

3) 客户协作高于合同协商

4) 变化响应高于计划遵循

 

敏捷选择提出的12条原则已经应用于管理大量的业务以及与IT相关项目中，包括商业智能。

12原则包括[12]：

1) 通过早期和连续型的高价值工作交付满足“客户”。

2) 大工作分成可以迅速完成的较小组成部门。

3) 识别最好的工作是从自我组织的团队中出现的。

4) 为积极员工提供他们需要的环境和支持，并相信他们可以完成工作。

5) 创建可以改善可持续工作的流程。

6) 维持完整工作的不变的步调。

7) 欢迎改变的需求，即使是在项目后期。

8) 在项目期间每天与项目团队和业务所有者开会。

9) 在定期修正期，让团队反映如何能高效，然后进行相应地行为调整。

10) 通过完车的工作量计量工作进度。

11) 不断地追求完善。

12) 利用调整获得竞争优势。

毫无疑问，从开发的角度讲，提出的敏捷宣言给开发的过程带来了很大的好处。因为开发工程师可以把精力真正的放在为客户开发一个让其满意的产品上，而不是在开发过程中，去遵循一个非常固定的步骤，而把大量的精力放在并不一定真正有价值的事情上。

l 敏捷开发的价值观

 

敏捷开发的价值观包括了XP（极限编程）[13]的四个价值观：沟通、简单、反馈、勇气，此外，还扩展了第五个价值观：谦逊。

1) 沟通

 

建模不但能够促进你团队内部的开发人员之间沟通、还能够促进你的团队和你的项目管理者之间的沟通。

2) 简单

画一两张图表来代替几十甚至几百行的代码，通过这种方法，建模成为简化软件和软件开发过程的关键。这一点对开发人员而言非常重要，因为它简单，容易发现出新的想法，随着你对软件的理解的加深，也能够很容易的改进。

3) 反馈

 

Kent Beck有句话讲得非常好：“乐观是编程的职业病，反馈则是其处方。”通过图表来交流你的想法，你可以快速获得反馈，并能够按照建议行事。

4) 勇气

 

勇气非常重要，当你的决策证明是不合适的时候，你就需要做出重大的决策，放弃或重构（refactor）你的工作，修正你的方向。

5) 谦逊

 

最优秀的开发人员都拥有谦逊的美德，他们总能认识到自己并不是无所不知的。事实上，无论是开发人员还是客户，甚至所有的项目管理者，都有他们自己的专业领域，都能够为项目做出贡献。一个有效的做法是假设参与项目的每一个人都有相同的价值，都应该被尊重。

l 测试驱动开发

 

测试驱动开发表现出迭代开发的核心的就是开发人员自己能够第一时间确认其需求得到了正确实现，而当单元测试覆盖了更多的内容，代码质量也将得到提高。测试驱动开发的指导思想就是让敏捷开发人员在编写功能代码之前，先根据需求编写测试代码。先思考如何对将要实现的功能进行验证，并完成单元测试脚本的编写，然后编写足够，仅仅足够的功能代码满足这些测试用例，直至通过测试。按照这个方法，递增的在迭代中增加新功能的单元测试和功能代码编写，直到完成全部功能的开发[14]。

在单元测试活动中，测试人员也被鼓励参与到单元测试的设计中来，不但可以帮助开发人员构思出更多的单元测试用例来扩大单元测试的覆盖率，还可通过学习如何使用单元测试，如何复用单元测试用例到回归测试和功能测试，以达到最大化利用有效的资源（如下图）和节约成本的作用。同时，在回归测试和用户接收测试（User Acceptance Test）中如能将单元测试脚本有机的关联起来，并自动化其执行，更能够进一步提高测试的成效并降低测试成本。

单元测试脚本因随需求、设计的变化随时更新。需要开发人员站在全局的立场，开发始终坚持先修改测试脚本，再修改产品原代码。此时，也建议测试人员参与单元测试脚本的改进，帮助开发人员合理的变更单元测试脚本，同时着手修改测试计划和测试策略[15]。测试驱动开发如图2.1所示。

软件开发其他阶段的测试驱动开发，根据测试驱动开发的思想完成对应的测试文档即可。

测试驱动开发的基本过程如下：

1) 明确当前要完成的功能。可以记录成一个TODO 列表。

2) 快速完成针对此功能的测试用例编写。

3) 测试代码编译不通过。

4) 编写对应的功能代码。

5) 测试通过。

6) 对代码进行重构，并保证测试通过。

7) 循环完成所有功能的开发。

 

 

2.2.2敏捷测试

敏捷测试当然不能简单地理解为测得更快，绝对不是比以前用更少时间进行测试，也不是将测试的范围缩小了或将质量降低来减少测试任务[16]。

假如将过去传统的测试流程和方法硬塞入敏捷开发流程中，测试工作可能会事倍功半，测试人员可能会天天加班，而不能发挥应有的作用。敏捷测试应该是适应敏捷方法而采用的新的测试流程、方法和实践，对传统的测试流程有所剪裁，有不同的侧重，例如减少测试计划、测试用例设计等工作的比重，增加与产品设计人员、开发人员的交流和协作。在敏捷测试流程中，参与单元测试，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，而对原有功能的回归测试则依赖于自动化测试。由于敏捷方法中迭代周期短，测试人员尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续的对软件产品质量进行反馈。敏捷测试不仅意味着对敏捷项目进行测试。很多测试方法，如探索性测试，原本就是敏捷方法，不管它是否应用于敏捷项目中。边测试边了解应用，并且让这些信息指导测试，与重视可用软件和影响变化的思想相一致。简单地说，敏捷测试就是持续地对软件质量问题进行及时地反馈[17]。敏捷测试定义描述如图

 

敏捷测试简单地可分为新功能测试和原有功能的回归测试。敏捷方法中，针对这两部分的测试建立相应的策略，以提高测试的效率，最大限度地降低质量风险。新功能测试的策略主要有[17]：

l 不需要测试用例，直接基于用例和对需求的理解来完成新功能的验证。即使要写测试用例，只要保证各个功能点被覆盖，不要过于详细。

 

l 持续地进行验证，一旦某块新代码完成，就开始验证，而不是等到所有代码完成后才开始测试。这也包括参与到单元测试和集成测试中。

l 实施端到端的测试，确保完整的业务流程的实现，同时，也容易发现业务逻辑不够清晰、不够合理等各方面的问题。

l 阅读代码来发现问题，可以和开发人员工作保持同步，消除测试周期的压力。

l 基于经验，可以实施更多的探索性测试、组合交互性测试和用户场景测试，更有效地发现埋藏较深的缺陷。

回归测试是敏捷测试中需要面对的难点。每次迭代都会增加新的功能，一个产品可能会经过十几次、甚至几十次迭代，回归测试范围在不断增大，而每次迭代周期没变，可能还是一个月。这样验收测试的时间非常有限，所以回归测试很大程度上依赖于自动化测试，因为很难将回归测试控制在非常有限的范围内。当然，还是有些办法可以帮助减少回归测试的范围，例如：

l 通过版本差异比较技术来了解代码变动的所有地方，再做代码关联分析，就可以明确知道要进行哪些地方的回归测试，回归测试范围会大大缩小。

l 基于风险和操作面分析来减少回归测试的范围，例如回归测试只是保证主要功能点没有问题，而忽视一些细节的问题。

l 持续测试的过程，只要有时间，就进行测试，包括开发人员、产品设计人员都参与到日常的试用和测试中来。

 

敏捷软件测试的七个关键成功要素包括敏捷软件测试的七个关键成功要素包括使用团队整体参与的方法、采用敏捷测试思维、自动化回归测试、提供并获取反馈、构建核心实践的基础、与客户合作和保持大局观。虽然敏捷方法应用于测试是成功的，但是敏捷测试仍然离不开必要的管理，没有完善的管理方法，敏捷测试很难发挥出它的优势。

 

2.3 敏捷测试管理方法

2.3.1测试生命周期管理

相较于传统软件测试的测试生命周期而言，敏捷测试并不特别注重过程，但这并非意味着敏捷测试不需要过程的控制。实际上，如果考察敏捷开发的一个迭代，在一个迭代中发生的测试与传统软件测试在生命周期管理上还是有诸多类似之处的。通常一个迭代中的测试目标相对固定：针对迭代定义的新功能的验证、针对原有功能的验证、以及保证开发过程中的持续的开发质量。与传统的软件测试相比，在验证方面，敏捷测试的一个迭代的测试目标与其基本一致；另一方面，由于测试执行活动仍然需要依赖计划、用例等，对传统软件测试的过程稍加修改就可以将其应用在每个迭代的测试活动中。在一个迭代中，针对验证目标的测试仍然按照测试需求、测试计划、测试设计与执行、以及测试评估总结的过程方式来管理，但是由于敏捷测试本身的特性是迭代周期短，因而每个迭代中新增内容的验证不多；大量依赖自动化测试；依赖沟通而非文档等，在具体的操作上有一些区别[18]。以下是在一次迭代中针对验证与确认工作的测试流程如图2.3所示。

l 测试需求

收集和整理本迭代中的所有需求，主要体现为新增功能和原有功能的修改，每个迭代中的需求变化是需要管理的。通常需要对来自产品的需求进行一定程度的细化，细化到本产品的测试工程师能够清楚理解需要验证的点即可。测试需求通常需要与产品负责人和开发组确认。

l 测试计划

 

“一页纸（One Page）”的测试计划是一个很好的实践。测试计划中只需要包含本次迭代的目标，以及简单的时间和资源计划即可。

l 测试设计与执行

 

敏捷测试中的测试设计与执行通常是交织在一起的，对于新功能，测试工程师通常通过对新功能的使用和尝试来了解之，然后为其设计测试用例并用脚本（手工测试用例或自动化脚本）的方式将其固定下来；而对于原有功能的测试主要依靠自动化测试来进行。在测试设计阶段，测试工程师需要维护验收测试，以保证其准确地反映了每个迭代的目标。推荐使用在线表格或是轻量的用例管理软件对用例进行管理，在自动化程度比较高的情况下，甚至可以直接依赖测试需求列表和自动化测试脚本，而无需创建手工用例集合。

l 测试评估总结

测试评估总结意味着对每个迭代中进行的测试进行评估与总结。与传统的测试相同，敏捷测试中评估的主要目的同样是获得被测产品质量与测试质量的度量，但在具体方法上与传统软件测试有一定的差别。

敏捷测试与传统软件测试有很多相似之处，但是也有很多不同。传统测试的管理模式就无法全部迁移到敏捷测试之中。所以，需要的是更适合敏捷测试高度快速迭代的测试集成框架。由敏捷测试的生命周期来看，该框架中必须包含对整个敏捷测试生命周期的管理，而且该框架必须是轻量级的。首先，需要对敏捷测试过程中的测试数据进行管理，这些测试数据包括测试需求、简要的测试计划、测试用例以及自动化测试的脚本等。其次，自动化测试时敏捷测试的基石，所以需要对自动化回归测试流程进行管理。最后，需要对测试结果和缺陷的进行跟踪，以及管理测试的评估总结。

敏捷测试的测试数据管理包括对敏捷测试需求的管理、对简要的测试计划的管理和对自动化测试数据脚本的管理。

软件测试的第一步就是需求分析，只有对软件需求做了准确、完整的分析后，才可能有完整地测试需求，敏捷测试也是如此。测试需求是测试计划和测试用例生成的基础。测试人员需要根据测试需求来编写测试计划和测试用例。迭代中的每个需求变化都是需要管理的。

测试计划可以做到精简，没有必要把每一个步骤和期望的结果详细的描述出来，很大程度上是提出一个测试的思路。敏捷测试不同于以往针对传统开发模式的测试，敏捷测试并不需要为每次迭代准备特别详细的测试计划文档，只是需要在测试计划中描述一些主要内容，包括在本次迭代中哪些内容是需要被测试的、本次迭代中会安排哪些类型的测试、测试通过的质量标准是什么，其他内容需要测试工程师自己来控制。因此，具体的实践就是在一页纸内描述完所有的测试计划，如果一个测试计划超过了一页纸的内容，通常意味着在敏捷测试中，文档写得过多。测试用例是将软件测试的行为活动做一个科学的组织归纳。目的是能够将软件测试的行为转化成可管理的模式，同时测试用例也是将测试具体量化的方法之一。测试用例构成了设计和制定测试过程的基础。通过测试用例的设计来完成整个测试的设计。因此，测试数据和测试用例的管理在整个敏捷测试生命周期中是相当重要的。

 

 

2.3.2自动化测试管理

自动化测试时敏捷测试的基石。自动化软件测试使用一种自动化测试工具来验证各种软件测试的需求，它包括测试活动的管理与实施、测试脚本的开发与执行。

自动化软件测试的高层次定义是：以改进软件测试生命周期的效率和有效性为目标，贯穿整个软件测试生命周期的应用程序和软件技术的实施。自动化软件测试是指跨越整个软件测试生命周期中的自动化工作，以及关注自动化集成测试和系统测试的工作。自动化软件测试的总体目标是设计、开发和交付自动化测试，并通过重复测试来提高测试效率。若成功实施，那么它可以大幅度减少针对软件密集型系统的传统测试和评估方法、过程相关的成本、时间和资源。

通常软件测试的工作量是非常大的。而测试中的许多操作是重复性的、非智力性的和非创造性的，并要求做准确细致的工作，计算机就最适合于代替人工去完成这样的任务。软件自动化测试是相对手工测试而存在的，主要是通过所开发的软件测试工具、脚本等来实现，具有良好的可操作性、可重复性和高效率等特点。

软件测试自动化实现的基础是可以通过设计的特殊程序模拟测试人员对计算机的操作过程、操作行为，或者类似于编译系统那样对计算机程序进行检查。软件测试自动化实现的原理和方法主要有：直接对代码进行静态和动态分析、测试过程的捕获和回放、测试脚本技术、虚拟用户技术和测试管理技术。

1）代码分析

代码分析类似于高级语言编译系统，一般针对不同的高级语言去构造分析工具，在工具中定义类、对象、函数、变量等定义规则、语法规则；在分析时对代码进行语法扫描，找出不符合编码规范的地方；根据某种质量模型评价代码质量，生成系统的调用关系图等。

2）捕获和回放

代码分析是一种白盒测试的自动化方法，捕获和回放则是一种黑盒测试的自动化方法。捕获是将用户每一步操作都记录下来。这种记录的方式有两种：程序用户界面的像素坐标或程序显示对象（窗口、按钮、滚动条等）的位置，以及相对应的操作、状态变化或是属性变化。所有的记录转换为一种脚本语言所描述的过程，以模拟用户的操作。

回放时，将脚本语言所描述的过程转换为屏幕上的操作，然后将被测系统的输出记录下来同预先给定的标准结果比较。捕获和回放可以大大减轻黑盒测试的工作量，在迭代开发的过程中，能够很好地进行回归测试。

3）脚本技术

脚本是一组测试工具执行的指令集合，也是计算机程序的一种形式。脚本可以通过录制测试的操作产生，然后再做修改，这样可以减少脚本编程的工作量。当然，也可以直接用脚本语言编写脚本。脚本中包含的是测试数据和指令，一般包括如下信息：

l 同步（何时进行下一个输入）。

l 比较信息（比较什么，比较标准）。

l 埔获何种屏幕数据及存储在何处。

l 从哪个数据源或从何处读取数据。

l 控制信息等。

 

自动化测试的管理包括对自动化测试脚本的管理和自动化测试流程的管理。自动化测试的管理有助于提高敏捷测试的效率、缩短敏捷测试的迭代周期。

2.3.3缺陷跟踪管理

软件中的缺陷是软件开发过程中的“副产品”。通常，缺陷会导致软件产品在某种程度上不能满足用户的需要。软件缺陷管理是在软件生命周期中获取、管理、沟通任何变更请求的过程。可以确保你的软件中的缺陷被跟踪管理而不丢失。

敏捷和精简的思想提供了一些实践和准则以帮助敏捷测试人员减少对缺陷跟踪系统的依赖。如果开发过程很可靠，所有成员都致力于生产高质量的产品，缺陷可能很少并容易跟踪。但是，如果没有缺陷跟踪系统就没有地方记录缺陷的细节，有很多东西是不适合写在卡片上的，例如怎么触发缺陷，什么环境什么操作系统等。缺陷系统适合记录所有的补充文档，如屏幕输出。

另一个需要缺陷跟踪管理的理由是可跟踪性，它连接了缺陷和测试用例。也并非所有的缺陷都关联了测试用例。跟踪缺陷的理由包括：“可以以史为鉴”；缺陷的数据库可以被用作知识库使用；而且客户报告缺陷时，可以更容易的从工具中找到缺陷的修改解决方法。

需要使用缺陷跟踪系统的情况：

1) 分散式团队。

2) 需要跟踪缺陷以满足审计要求或者在发布说明中描述它们。

3) 有些缺陷的周期超过了一个迭代，你需要记录下来在以后修补。

4) 存在问题众多的遗留系统。

 

综上所述，轻量级的缺陷跟踪管理对于敏捷测试过程还是很必要的。

2.4 测试流程自动化

2.4.1自动化测试

简单是敏捷的核心价值，自动化测试是敏捷测试的基石[18]。测试流程的自动化成为敏捷测试中提高测试效率改善测试效果的唯一途径。敏捷测试要求测试能够测试在短的时间间隔内持续发生且能够在短时间内完成。考虑到纯粹的依赖人工测试基本不可能达到短的时间间隔内持续发生和短时间内完成目标，而自动化测试在执行效率方面具有天然的优势，在敏捷测试中使用自动化测试技术应该是自然而然的选择。

由于开发周期短，需求、设计等方面沟通也需要花费很多时间，没有足够时间开发自动化测试脚本，至少对新功能的测试很难实现自动化测试。这时候，就需要正确的流程来提高自动化测试的效益[19]。针对稳定的产品特性开发自动化测试脚本，也就是针对前期完成的已有功能开发自动化测试的脚本，而大部分新功能测试采用手工测试。自动化测试的流程如图2.4所示。

 

 

 

 

2.4.2测试流程

测试生命周期的测试流程自动化不仅仅是指测试的自动化，还包括测试前的准备和测试后的结果管理。敏捷测试流程如图2.5所示，包括测试需求、测试用例、测试脚本、测试执行、测试结果和缺陷跟踪和测试总结等。测试流程的自动化是指整个敏捷测试生命周期中的所有节点都要自动化完成，测试流程自动化成为敏捷测试中提高测试效率改善测试效果的唯一途径。

为了管理敏捷测试生命周期，上节中提出了测试集成框架，测试流程的自动化管理是该框架的核心所在，需要构建一个灵活的、开放的敏捷测试框架，必须要对测试流程进行有效的全自动的管理，使测试脚本的开发简单易行，脚本维护也方便，执行流程更自动化[20]。

 

 

 

 

2.5本章小结

本章首先介绍了传统软件测试的定义，接着引入敏捷软件测试的概念。进而，提出敏捷测试的管理。然后与传统软件测试做比较，详细阐述了敏捷测试的生命周期，并说明敏捷测试整个生命周期的管理是至关重要的，提出了需要设计敏捷测试集成框架来管理敏捷测试的生命周期，并且说明了敏捷测试流程的自动化和高效管理敏捷测试生命周期的必要性。

 

 

 

 

 

敏捷测试是一种新兴的软件测试。随着软件系统的规模和复杂性的提高，软件的生产成本、软件中存在的缺陷和故障造成的各类损失也大大增加，软件质量问题已经成为所有使用软件和开发软件的人们关注的焦点。另一方面，随着企业竞争的日益激烈，客户对于软件产品的要求和期望日益提升，现实条件下应用的复杂性日益提高，带来了软件需求的频繁变动，使得当下的软件项目面临着严峻的挑战。采用传统的软件开发流程往往使得测试人员面临时间短、任务重的尴尬

处境。这也正是近年来敏捷开发过程逐渐兴起和不断发展的主要原因。而应用了敏捷软件开发方法的情况下，如何在多变的环境中，从容应对变化，如何适应快速迭代和变更，在速度和质量之间寻求一个平衡点，如何使得测试人员与开发同步，如何加大共享与交流，既保持整个项目的敏捷性、灵活性，又确保高质量地按时发布软件产品，成为近年来软件测试行业所面临的课题。

敏捷宣言是：

●人和交互重于过程和工具；

·可以工作的软件重于面面俱到的文档；

·客户合作重于合同谈判：

·随时应对变化重于循规蹈矩(拥抱变化胜于遵循计划)。

要充分了解敏捷测试，则需要先熟悉敏捷开发过程。

 

 

 

2．2．1敏捷开发过程

敏捷不是用来对组织的初始项目进行一次性检查并给以评价的工具。它是一种有生命力的方式，一种不断产生的和不断回应商业动荡的方式。敏捷的组织是计划的，并且理解计划的局限性。虽然敏捷所设定的问题是变革的产生和回应，而另外的三个成分对定义敏捷有所帮助，它们是：灵活性和即兴创作，与现实的

一致性，灵活性和结构性的平衡。敏捷不仅仅是一种反应，而是一种行动。第一，也是最重要的，敏捷组织创造变革，这种变革增加竞争对手的压力。创造变革需要创新，需要创造新的知识才能提供商业价值。第二，敏捷组织具有反应能力，能迅速而有效地回应预期或没有预期的商业环境的变化IS,61。

敏捷开发是一种以人为核心，迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

敏捷开发方法的特点：

·拥抱变化’

·客户的参与

·较少的文档

·最大化的生产力

●测试驱动开发

·自动化冗余工作

●民主的团队

●尊重团队

典型的敏捷开发过程模型有：XP、FDD、Scrum、ASD、DSDM和Crystal。

其中Scrum与XP应用最为广泛【6】。

1)XP(极限编程，eXtreme Programming)

极限编程是KentBeck、Ward Cunningham和Ron Jeffries共同提出的。XP倡导团体性、简易性、反馈和勇气的价值。XP的重要方面是改变了变革成本的观点。并且强调重构和测试优先开发的技术优势。XP提供了一个动态实践的系统，其完整性也己得到证明。

2)FDD(特性驱动开发，Feature．Driven Development)

JeffDe Luca和Peter Coad协作提出FDD。FDD由一个最低限度的5步过程组成，其核心是开发一个完全“定型’’的对象模型，构建一个特性列表，然后按特性来规划，迭代进行按特性的设计和按特性的构建。FDD的过程很简明，它的两个关键角色是首席架构师和首席程序员。FDD与XP的不同点在于其“轻”的前端体系结构建模方法。

3)Scrum

以英式橄榄球争球队形Scrum为名，最初由Ken Schwaber和Jeff Sutherland ．提出，后来Mike Beedle也参与协作。有关Scrum过程模型在后面的章节中还会有详细的介绍。^

4)ASD(自适应软件开发，Adaptive Software Development)

自适应软件开发由Jim Highsmith提出，它为敏捷方法提供了一个哲学背景，表明了软件开发组织如何对当前的业务气候的混乱性做出反应——利用而不是回避变革。ASD既包含实践——迭代开发、基于特性的计划、客户重点小组评审，也包含一个“敏捷的”管理哲学，称为领导．协作管理。

5)DSDM(动态系统开发方法，Dynamic System Development Method)

动态系统开发方法于20世纪90年代中期在英国提出。它是快速应用开发实践的派生和扩展。DSDM至少在欧洲是敏捷软件开发系统中对培训和文档支持得最好的。DSDM的9个原理主要包括：积极的用户参与、频繁交付、团队决策、在整个项目生命周期中的集成测试以及开发过程中的可恢复改变。

6)Crystal方法

Crystal方法是Alistair Cockbum对敏捷社团的一大贡献，阐明了其把交流和对话放在首位的立场。软件开发是“一种发明与交流的合作性工作。，他强调人、交互、团队、技能、才智和交流，并将其作为性能的第一要义。过程依然重要，但还是其次。

 

2．2．2敏捷测试的概念

敏捷测试是遵循敏捷宣言的一种测试实践：强调从客户的角度，即使用系统的用户的角度，来测试系统；重点关注持续迭代的新开发的功能，而不再强调传统测试过程中严格的测试阶段；建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。

关于敏捷测试的有一个不成熟的定义：一种面临迅速变化的需求和频繁迭代，迅速制定出与当前迭代高度适应的测试策略，快速做好测试准备并执行测试，尽早的发现优先级较高的bug、在有限的时间内完成覆盖率较高、测试较充分的测试。敏捷测试的核心，就是在设计阶段之前充分学习该项目的行业知识，从最终用户角度和实际出发充分的挖掘需求。在设计阶段要完成对敏捷设计的灵活性、可扩展性和易维护性的检查。在敏捷开发的高度迭代过程中，测试人员首先要从整个项目全局考虑，及早发现需要更改设计的问题，但时间上不能花太久，其实这个测试更多的是去看、去思考，而能不能发现问题就要看测试人员对现有需求的领会能力，对整个项目是否有一个全局的把握，是否从最终用户角度去考虑问题，是否以实现客户的商业价值为目标；然后在最短时间内完成所有功能和业务逻辑的测试，最好是每人分配不同的功能和业务逻辑进行测试，这样就可以在最短时间内及时将优先级较高的bug及时反馈给开发人员；最后在开发人员忙于修改那些优先级较高，难度较大比较耗时的bug时，测试人员可以有充分的时间来对这一迭代进行较细致的测试，发现功能和业务逻辑中不易察觉的问题，次要功能问题、验证、界面等等问题。

 

2．2．3敏捷测试的流程与方法

敏捷测试的流程可总结如下：

1)验证需求和设计

在测试初期，测试人员要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。积极地参与前期工作，并迅速反馈给设计和开发其静态测试结果。要尽早的开始测试，不要等待到功能完全做好才开始。

2)测试计划与测试用例

· 编写计划、测试用例

● 测试用例的评审

31实施运行测试

· 每日提供bug趋势，并依此进行探索性测试用例的编写

● 测试用例的维护

● 根据项目不断补充Common Sense

· 控制中间版本

· 发布版本前编写Release Note

4)需求管理

采用敏捷开发模式的项目中，客户对于需求的变更很频繁。因此，需求管理是十分必要和重要的工作。

5)项目开发末期开展“bug大扫除"

敏捷测试的方法主要有测试驱动开发、递增迭代测试模型和静态测试三种方式，下面分别对这三种方式进行阐述。

 

1)测试驱动开发

测试驱动开发的指导思想就是让开发人员在编写功能代码之前，先根据需求编写测试代码。先思考如何对将要实现的功能进行验证，并完成单元测试脚本的编写，然后编写足够的功能代码满足这些测试用例，直至通过测试。按照这个方·法，递增地在迭代中增加新功能的单元测试和功能代码编写，直到完成全部功能的开发【7】。一

 

21递增迭代测试模型

Confirmative测试包含对需求的静态测试，开发人员做的单元测试，以及Build验证测试，功能测试(仅限于对当前迭代功能)和重要的其他类型测试。Investigative测试包含系统测试，压力，并发，安全甚至全球化的测试，以及回归测试。通过了Confirmative测试的产品Build就可以在迭代结束时发布了。而为了保证产品拥有更好的质量，也为了完成对那些较低优先级的质量验证的需求得以确保成功的实现，需要针对性的做Investigative测试。

 

31静态测试

在敏捷开发过程的静态测试是项目迭代开发前期测试人员的最主要工作。在这段时期测试人员的工作重心是认真了解需求和用例设计，并针对设计的可行性，可用性进行验证，确认设计是对需求的准确实现，最佳实现。这个过程能够帮助团队发现早期的设计缺陷，通过发现问题，并定制新的设

计方案，团队也通过这个过程，更好的了解了测试的重要性，也摒除了可能存在的对需求的种种“假设”，因而更加明确了团队的目标和方向。

 

 

2．3自动化测试概述

自动化测试是Serum敏捷测试的核心价值观之一。

软件自动化测试，是一项让计算机代替测试人员进行软件测试的技术。软件．测试自动化可以使某些任务提高执行效率，具有很多优势。随着传统测试策略愈发难以适应当前复杂的软件开发需要，甚至还存在导致各种问题及错误的风险，自动化测试愈来愈受到软件开发及测试人员的重视。

 

2．3．1自动化测试概念及基本方法

软件自动化测试就是执行某种程序设计语言编制的自动测试程序，控制被测软件的执行，模拟手动测试步骤，完成全自动或半自动测试。其目的在于缩短测试周期，增强对软件性能方面的测试能力等，从而达到保证软件质量并使软件能够提前上线。

软件自动化测试的一般定义为：各种测试活动的管理与实施，包括测试脚本的开发与执行，以便使用某种自动化测试工具来验证测试需求。它是结合项目测试的需求，通过自动化测试工具或其他手段，按照测试工程师的预定计划进行自动的测试，目的是排除影响测试的人为因素，减轻手工测试的劳动量，从而降低花费在测试上的开销，达到提高软件质量的目的。也就是说，进行自动化测试，不仅是技术、工具的问题，实际上它是一个测试过程框架，测试人员在进行自动化测试时，要依据这个框架，运用自动化测试技术，有计划进行测试活动。它的意义在于使测试过程变成更加系统化、有计划的过程，能够被更迅速、更正确、更经济地完成。

软件自动化测试分为全自动测试和半自动测试两种方式：全自动测试就是指在自动测试过程中，根本不需要人工干预，由程序自动完成测试的全过程。半自动测试就是指在自动测试过程中，需要人工手动输入测试用例或选择测试路径，再由自动测试程序按照人工指定的要求完成自动测试【8】。

软件自动化测试的实现通过设计的脚本程序模拟测试人员对软件的操作过程和操作行为，或者类似于编译系统那样对计算机程序进行检查。软件测试自动化实现的方法主要有：直接对代码进行静态和动态分析、测试过程的捕获和回放、测试脚本技术和虚拟用户技术【9】。

1)代码分析。

代码分析是一种白盒测试的自动化测试方法，代码分析类似于高级编译系统，一般针对不同的高级语言构造分析工具，在工具中定义类、对象、函数、变量等

通过自动录制得到的脚本，所有的输入数据都是常数，是固定的。

如果需要使用一个测试脚本测试多组数据，就需要对脚本进行参数化，把固

定的常数修改为来自数据源变量。

测试脚本语言是脚本语言的一种，准确地讲是脚本语言在测试领域的一个分．

支，是自动化软件测试设计的基础。要理解测试脚本语言就不能不对脚本语言进

行一些了解。^

脚本语言就是在执行时以解释为主的编程语言，比如常见的

Perl，Python，Php，Tcl，Guile，Ruby以及UNIX系统的各种Shell都是脚本语言，它

的执行效率比不上编译后再执行的程序，如用C，C++，Java，Pascal等语言编写

的程序。

脚本语言应用到测试领域就可以称之为测试脚本语言，以上提到的脚本语言

都可以作为测试脚本语言来使用，特别是Tcl语言更是被业界称为事实上的测试脚

本语言标准。随着软件测试的发展，各种测试工具也相继推出，为了保护知识产

权或者说是保护商业秘密，这些商业化的软件大多使用自己的测试脚本语言，比

如MI的TSL语言等【10】。

 

2．4本章小结

’’口‘●‘

本章首先阐述了软件测试相关理论，包括软件测试的目的、方法与技术，以及软件测试的生命周期。然后着重阐述了敏捷测试。敏捷测试是遵循敏捷开发过程的一种测试实践，在简单介绍敏捷开发过程的基础上，详细阐述了敏捷测试的概念、方法与流程，并由此引出了自动化测试。自动化测试敏捷测试的核心价值观之一，也是当前软件测试领域备受关注的一种测试方式。本章在最后部分介绍

了自动化测试的基本概念和方法，以及自动化测试脚本的相关知识。

 

 

 

 

 

 

（以项目为实例进行分析）

1 敏捷开发特点

2 敏捷开发vs敏捷测试

 

Shan项目组承担的是Shannondoah外包测试工作。Shannondoah是一个面向全球的应用服务，测试活动是基于Nokia敏捷测试模式的。此外，敏捷测试的一项重要内容是自动化冗余工作。因此，深入研究国际化软件测试、敏捷测试，以及自动化测试，对测试实践具有很大的帮助。

软件测试是使用人工或自动方法来执行或测定系统或系统部件的过程，以验证它是否满足规定的需求，或识别出期望的结果和实际结果之间的差别。软件测试是软件开发中不可或缺的环节，也是软件工程的重要组成部分。自20世纪70年代开始，业界就公认，在一个典型的编程项目中，测试会占到一半乃至更多的时间和资源【1】。40多年来，随着编程语言和软件开发技术发展

2

 

随着软件应用范围的扩大，软件复杂度的提高，以及软件设计技术的不断发展，软件开发规模越来越大，处理的问题愈来愈复杂。自动化测试愈来愈受到软件开发及测试人员的重视。自动化软件测试技术可以克服传统测试技术的许多问题。其依据的是一套严密的测试法则和评估标准，具有完整的自动测试过程。它可以避免测试人员惯性思维所导致的测试疏漏，减少由于手工测试中繁杂的重复工作所导致的人为差错。自动化测试易于实现错误信息的追踪和场景的再现，且测试活动的自动化在许多情况下可以获得最大的实用价值，尤其在自动化测试的测试用例开发和组装阶段，测试脚本很可能被重复调用。因此，采用自动化测试可以获得很高的经济回报。软件自动化测试己成为当前软件测试技术研究的重点和难点，有关软件自动化测试技术、理论的研究和软件自动化测试工具的研发越来越受到软件界的重视。

国际化软件测试是近年来逐渐发展的新兴测试领域，与传统的面向单一区域和语言的常规软件测试相比，具有很多不同的特征，表现在跨区域的全球测试、测试内容广泛、测试周期时效性强等多个方面，因此国际化软件测试是一项复杂的系统工程，这对国际化软件测试管理提出了更高的要求，项目计划和预算管理

与跟踪、测试文档管理、测试缺陷管理、技术支持和沟通交流等都比传统的软件测试项目复杂。随着软件市场全球竞争的加剧，软件的开发周期不断缩短，对于全球发布的国际化软件来说，越来越多的国际大型软件公司追求多语言版本与源语言版本同时发布或者相隔时间尽量缩短。为了达到同步发布的目的，软件的国际化测试和本地化测试以及核心功能测试需要与软件开发过程并行进行【2】。因此，制定合理的测试计划，以及选用适当的自动化测试工具以减轻测试负担都是至关重要的。

 

三敏捷测试方法设计与实践

（理论，重点）

2．1 敏捷测试概念

敏捷测试是指在敏捷开发模式中的测试。敏捷测试包括单元测试（通常由程序员完成）和可接受性测试（通常由测试人员完成）。

2．2 敏捷测试的实质

敏捷测试不仅仅是测试软件本身，还包括软件测试的过程和模式。测试除了需要确保软件的质量，敏捷的测试团队还要保证整个软件开发过程是正确的。敏捷开发的最大特点是高度迭代，有周期性，并且能够及

时、持续的响应客户的频繁反馈。敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的有效需求得以圆满实现并确保整个项目过程安全地、及时地发布最终产品。敏捷测试人员因而需要在活动中关注产品需求，产品设计；在完成各项测试计划、测试执行工作的同时，敏捷测试人员需要参与几乎所有的团队讨论和决策。

 

 

1 测试方法（需求分析，测试用例，测试流程）

3．1 验证需求和设计

在测试初期，测试人员要学会做静态测试，将自身作为第一用户，做好需求分析，以及对设计逻辑的分析。需求和设计一般包括：（1） 由项目经理根据需求文本而编写的功能设计文本（Functional Design Specification）；（2） 由开发人员根据功能文本编写的实施设计文本（Implementation Design Specification）作为测试人员， 审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性［3］。

3．2 测试计划，测试用例

3．2．1 编写测试计划、测试用例

测试人员根据已审核通过的需求和设计编制测试计划，设计测试用例。功能设计文本是主要依据。敏捷测试对测试用例的要求非常高。在写用例时应该考虑好用例需要达到的粒度。测试计划和测试用例也要被项目经理和开发人员审核。

3．2．2 测试用例的审核

测试人员在出TC 的同时， 可以出一份TC＿Matrix（TestCase 跟踪矩阵），其中注明TC 已覆盖了哪些Features。具体每个Features 对应的TC 的编号，这样在测试经理和PM 对TC 进行Review 的时候，能够对TC 的覆盖率一目了然，对覆盖率不足（如某个重点Feature 的Test Case 不够）的地方能够及时给出意见。

3．3 实施运行测试

在敏捷方法中，测试有两种：单元测试和接收测试。在build 版本给测试前，开发首先要做单元测试，确保给测试的版本能够通过smoking test（冒烟测试）。做单元测试的好处是可以提高版本质量，减轻测试的工作量，减少浅层次的bug 的发生率，使测试人员能够将更多的精力投入到寻找深层次的bug 上面。测试人员的验证测试就是将上一步设计的测试用例按计划付诸实施的过程。测试执行的一开始可以针对部分功能，之后可以逐步扩展。接着开始采用迭代的过程完成测试任务。即将测试任务划分为多个周期，一开始可以做些关键的功能性测试， 接着的迭代周期可以做边缘化的功能测试和其它测试，最后的几个迭代应该用于回归测试， 关键的性能和稳定性测试

［4］。验证测试中的几项关键工作如下：

3．3．1 每日提供bug 趋势

为方便衡量项目的进度， 测试可在每天测试完毕后提供bug 趋势。即将每天新生成的Bug 数和每天被解决的Bug 数标成一个趋势图表。一般在项目的开始阶段新生Bug 数曲线会呈上升趋势， 到项目中后期被解决Bug 数曲线会趋于上升，而新生Bug 数曲线应下降， 到项目最后， 两条曲线都趋向于零。项目经理会持续观察这张图表，确保项目健康发展，同时通过分析预测项目Bug 趋于零的时间。

3．3．2 测试用例的维护

在执行测试阶段中，测试人员需要对已有的测试用例进行及时的维护。通常在以下两种情况下需要新增一些测试用例：一是对于当初测试设计不周全的领域，二是当产品的功能设计出现更改时（敏捷项目中功能设计的更改频繁），所涉及的测试用例也要相应地修改， 使测试用例保持和现有的功能需求同步。

3．3．3 控制中间版本

为更好地保证软件质量，规避风险，必须加强对中间版本的控制。有的团队有过这样的经历，在项目前期很轻松，到后期bug 越来越多，开发人员和测试人员都异常忙碌，经常加班加点赶着发版本。为减轻项目后期工作量，规避风险，建议开发进行Daliy Build（每日构建），或者按照完成一个feature 就进行一次build，针对这个feature 进行测试，这样就可以有效避免后期bug 越来越多的状况发生， 后期工作量也就会相应减少，项目的质量也会更有保证。

3．3．4 发布版本前编写Release Note

在每次发布版本之前，测试人员要根据待发布的版本情况编写Release Note（版本注释），使客户对该版本的情况一目了然。Release Note 主要包括三方面的内容：Fixed，New Features，Known Problems。其中，Fixed 部分写明此版本修复了上个版本中存在的的哪些比较大的bug；New Features 部分写明此版本新增加了哪些功能；Known Problems 部分写明此版本尚存在哪些比较大的问题，有待下个版本改善；或者列出需求不太明确的地方，有待客户给出明确答复意见，在下个版本中完成。

3．4 需求管理

采用敏捷开发模式的项目中， 客户对于需求的变更很频繁。整个项目进行过程中，对不断变化的需求，一定要作跟踪，每次的需求变更都要有相应的历史记录，方便后期的管理和维护工作。可将每次的变更整理记录到需求跟踪文档中，并使该文档始终保持最新更新的状态，与需求的变化保持同步。

3．5 项目末期开展“bug 大扫除”

在项目开发的末期，可以开展“bug 大扫除”活动。划出一个专门的时间段，在这期间所有参与项目的人员，集中全部精力，搜寻项目的Bug。要注意以下要点：（1）参与者不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，目的是要集思广益；（2）鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug；（3）为调动积极性，增强趣味性，可适当引入竞争机制。

 

 

2 敏捷测试中的（人员管理，团队管理）

3 敏捷测试中的自动化技术——持续集成测试

4 总结敏捷测试vs传统测试优势

1 敏捷测试与传统模式测试

传统需求工程最终目标是冻结需求， 而敏捷软件开发以迭代思想为核心。敏捷开发的最大特点是高度迭代，有周期性，并且能够及时、持续的响应客户的频繁反馈［2］。敏捷测试即是不断修正质量指标， 正确建立测试策略，确认客户的有效需求得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。区别于传统瀑布型模式，在敏捷环境中，从确认客户需求开始， 到测试计划、测试用例、测试执行、缺陷跟踪、回归测试，一直到最后软件系统发布，测试贯穿整个流程［3］。如图1。

这样敏捷测试也需要高度迭代工作、频繁得到客户的反馈，需要动态调整测试计划、测试的执行。面对采用诸多开发最佳实践的开发者以及快速迭代出新功能的软件系统， 测试人员要保持快速的响应， 并实时地调整测试过程。这对测试人员是个考验， 即使是采用了相同敏捷实践的开发者也不会表现出一样的生产力，只有测试工程师根据整个团队的特点，总结出一套最适合团队的测试模式，才是最理想的。

 

----------------------------------以下为实践-------

 

～3敏捷测试实践

Shannondoah是Nokia Ovi移动互联服务的服务之一，它与Nokia Music联系

紧密。Nokia Music整合了Store和Contacts两大功能，以音乐为平台为大众提供

更多更好的服务。其中Shannondoah就是这样一个交流的平台，可以建立自己的

音乐分享，并通过好友以及整个网络关系发现和发掘更多的音乐。

本章主要阐述了基于Nokia Serum敏捷测试模式的Shan的测试实践。

3．1项目测试流程

Shah项目组的测试是基于Nokia Serum mode的敏捷测试模式。这种测试模式

在Nokia Serum开发过程中得到了充分的应用。

3．1．1项目组整体测试流程

为缩短手机软件研发周期，降低手机软件研发成本，增强市场竞争力，Nokia

手机软件研发部门于2008年初引入Serum敏捷开发。

Serum开发流程是敏捷过程的一种。其基本假设是开发软件就像开发新产品，

无法一开始就能定义软件产品最终的规程，过程中需要研发、创意、尝试错误，

所以没有一种固定的流程可以保证专案成功。Serum将软件开发团队比拟成橄榄球

队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度

自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝

向目标有明确的推进，因此Serum非常适用于产品开发专案【1l】。

根据Nokia公司通用的Serum测试流程，Shan项目组也制定出了自己的项目

流程。．

由于项目组是外包测试服务商，所以，以与客户方签订Time Box的形式作为

项目组整个的测试期限，初步定义为6个月，测试项目命名为Shan 2009。根据项

目的开发时间，6个月后，项目仍在继续，其跨越了2009年，则项目更新命名为Shan

2010。

每个Time Box按照需要分为2．3个Train，每个Train的时间为8．12周。每个

Train开始的时候，由测试经理向Serum Master来确认当前Train需要开发的feature．

在每个Train结束的时候，测试团队需要提交一个针对这些新功能的测试报告。

每个Train的Deadline确定以后，Serum Master把每个Train分为若干个Sprint，

每个Sprint的开发周期2-4周不等，这由Scrum Master根据项目需求而定。每个

Sprint开始时，Scrum Master、Developers、Testers和UI Designers参与Sprint Planning

Meeting，在每个Sprint结束时，Scrum Master、Developers、Testers和UI Designers

参与Sprint Review Meeting。

一

·

在每个周期中，根据客户提供新产品的需求说明，测试团队制定计划并完成

测试任务，，．著在Sprint的最后一天后衮付属于这个周期的测试成果。^

测试团队每天用1 5分钟开会检视每个成员的进度与计划，了解所遭遇的困难

并设法排除。采用Scrum模式，是因为需求可能变更频繁，这就需要全体的项目

组成员在充分理解客户的需求的同时，还要对此项目所用到的相关的知识点了解

透彻，以尽可能快的速度应对客户的变更来降低需求变更频繁带来的风险。

要更为详细的了解Serum，首先要熟悉有关Scrum的几个名词：

·User Story：User Story在敏捷项目中是项目范围的基本单位。在项目中，每个

User Story是从稍多于一行的描述逐步精细到一套验收标准的。User Story是把

需求分解为有优先级的、可测试的、可评估的小工件的有效机制。

·Backlog：可以预知的所有任务，包括功能性的和非功能性的所有任务。

·Sprint：一次迭代开发的时间周期，在这段时间内，开发团队需要完成一个制

定的Backlog，并且最终成果是一个增量的、可以交付的产品。通过迭代的方

法在每个Sprint都提交一个可使用的版本，客户可以在这个版本基础上考虑对

软件的更新或者增加新功能，同时给出一些反馈。

●SprintBacklog：一个Sprint周期内所需要完成的任务与工作量估计。

· Scrum Master：负责监督整个Scrum进程、修订计划的一个团队成员。

●Product Owner：代表客户的利益，负责管理产品和投资收益率。

·SprintPlanning Meeting：在启动每个Sprint前召开。该会议需要制定的任务是：

ProductOwner和团队成员将Backlog分解成小的功能模块，决定在即将进行的

Sprint里需要完成多少小功能模块，确定好这个Sprint Backlog的任务优先级。

·Daily Scrum Meeting：开发与测试团队成员每天召开，一般为15分钟。每个开

发成员需要向Scrum Master汇报三个项目：今天完成了什么?是否遇到了障。

碍?即将要做什么?通过该会议，团队成员可以相互了解项目进度。

· Sprint Review Meeting：在每个Sprint结束后，这个Team将这个Sprint的工作

’

成果演示给Product Owner和其他相关的人员，并对这个Sprint的工作进行总

结。一般该会议为4小时。

 

 

3．1．2项目组一个迭代周期的测试流程

真正的项目实践和详细的测试计划是在每个Sprint中展开的，在一个迭代周

期中Serum Testing的基本活动如图3-1所示。

 

 

从上面的流程上可以总结出，在一个迭代周期里，Shan项目组的测试实践主

要包括以下几个方面：

1)在每个Sprint开始时：

· 参与Sprint计划会议，了解当前Sprint需要开发的的新功能。

●针对不同的Sprint Backlog，制定相应的测试计划。

2)在Sprint进行过程中：

●根据User Story创建测试用例。

●在Ni曲tly Build上，执行功能测试，探索性测试以及自动化测试。

●缺陷验证。开发人员修复bug之后，第一时间进行验证，并提供反馈。

 

3)在每个Sprint结束时：

·参与Sprint总结会议。

·提供当前Sprint开发的新功能的质量报告。

此外，在每个Train开始的时候，由于开发团队处于开发新功能的技术研究阶

段，所以测试团队会有大概两周的时间空余，项目组会安排一次针对上一个Train

的相关实现内容进行一轮有效的非功能性测试。在每个Train结束的前两周，开发

团队会提供一个比较稳定的版本，测试团队会进行一轮测试全集的回归测试，来

有效评估当前Train的产品质量，并提供有效的测试报告。

在充分了解Shan项目组在各个测试流程的工作内容之后，下面会详细阐述作

者在各个测试阶段的测试工作。

 

 

 

 

3．2测试计划与测试用例

测试计划与测试用例的编写属于测试流程中的计划阶段。这一阶段的成果直

接指导测试过程的进行。

3．2．1需求获取与测试计划

测试计划是测试项目实施的最初阶段，是整个测试项目实施的基石，测试计

划的好坏在一定程度上决定了最终测试的实施效果。在敏捷测试项目中，测试计

划分为项目整体的和每个Sprint的独立的测试计划。

’

’

项目整体的测试计划是在项目启动阶段由Scrum团队整体参与制定。由于

Shannondoah是国际化软件服务，所以符合国际化软件开发测试流程，测试整体规

划采用项目里程碑驱动的测试。

里程碑(Milestone)是项目实施过程的各个关键阶段，在国际化软件开发和

测试项目中，里程碑表示软件开发和测试的标志性、阶段性临界点。软件开发过

程有多个计划的里程碑，分别表示软件到各个阶段所具有的功能和完成的任务。

从软件周期来讲，软件主要里程碑包括基本功能完成编码，软件完成AlphaBuild

和Beta Build，完成预发布Build(RC Build)，完成R]M Build。

软件项目的里程碑示意图如图3．2所示。这些不同阶段的里程碑的测试内容不

同，测试方法不同，每一个里程碑对应一个关键的软件项目阶段，时效性非常强，

为了做到软件项目按照项目计划按时发布，要求软件测试人员做好准备，在软件

测试计划和项目进度计划安排的时间内，完成相应地测试任务。

 

 

 

在M1阶段，Shan项目组主要实施国际化软件的核心功能测试。核心功能测

试以测试软件的功能和性能为主，保证软件的功能符合设计规格说明书和用户需

求。从测试阶段上可以细分为单元测试、集成测试、系统测试和验收测试；从测

试实现方式上可以分为手工测试和自动化测试。

在M2阶段，Shah项目组进行国际化测试。国际化测试包括国际化能力测试

和本地化能力测试。软件国际化能力包括软件对不同操作系统的安装和设置能力、

区域数据格式的支持能力、对不同文化习俗的兼容能力、对多字节字符集的处理

能力和文档写作方式的控制能力。本地化能力测试在于检测软件是否考虑了本地

化的方便性，即软件是否可以比较容易得翻译成任何目标语言，而不需要修改软

件源代码。这一阶段的测试任务还在进行中。

在M3阶段，Shan项目组实施本地化测试。这一阶段的任务本地化测试包括

本地化功能测试、本地化用户界面测试和本地化语言质量测试。软件本地化测试

的目的是为了尽早发现和报告本地化软件的缺陷。通过对这些缺陷的处理，确保

本地化软件的语言质量、互操作性、功能等符合软件本地化的设计要求，满足当

地语言市场和用户对软件功能和语言文化的需求。由于现在项目还处在M2阶段，

所以这部分测试活动还没有展开。

 

 

所以这部分测试活动还没有展开。

在项目实施的具体阶段，即在每个Sprint开始时都要制定Sprint测试计划。测

试计划的制定主要依据需求获取的结果。需求获取主要有两个方式，一是User

Joumeys和User Stories，一是Meeting Minutes。

Shah项目组目前已经进行了35个迭代周期的测试活动。在每个Sprint的开始，Serum Master会提供User Journeys和User Stories，描述本Sprint将要实现的功能

点。然后相关测试活动的测试人员获取到自己负责部分的内容，就可以制定测试

计划了。

 

 

 

图3．3显示的是第7个Sprint的User Journeys，而User Stories在这一阶段并

没有更新。由于作者主要进行的是手机端的测试，所以作者关注的是User Journeys

关于Mobile部分的描述。

从图3．3中可以看出，在这个迭代周期中，手机端主要实现了两部分功能：一

是可以在Ovi music的主页上看到朋友正在听的歌曲；一是通过Ovi music里的按

钮链接可以进入到Shannondoah。

根据这两个功能点的描述，作者制定的测试计划是：

11设计属于这两个模块的测试用例；

21评估测试执行方式。由于这两个部分都需要与Web端进行交互，所以不适合

采用自动化测试，而采用手动测试。

由于每个Sprint历时2-4周不等，具有时间跨度。所以，测试组会在每周与

Serum Master的电话会议中获取更为详细的需求以及测试需求变化，通常以

Meeting Minutes的形式表述，如表3．1。

表

 

 

根据上述需求，作者制定出了更为详细的测试计划：

1)优先执行BAT测试，测试在收到Nightly Bulid后及时展开；

2)在3月20日执行新功能点验证测试；

3)使用触屏手机做测试优先级为l的测试；

4)在合适时间进行电池使用测试；

5)使用N97手机做特殊的登录注销测试；

6)在一周内完成60条自动化脚本编写；

7)在N86和N97上进行测试全集的自动化测试； 一

8)完成126条的脚本修改和上传工作。

以上的测试计划是作者根据Sprint7的测试需求制定的。到目前为止，作者一

共参与了从Sprint5到Sprint35共31个迭代周期的测试计划。

在图3．4中，可以看到依据测试计划进行的测试的执行情况。

■勤BAT Wdget_1．00(1 39)with Alvin 1o．30．2009

■擗BAT WdgeU．00(1 39)with N86 10．30．2009

■辩BAT Wdget．．1．00(1 39)with N97 1o．30．2009． ，

j‘勤BAT Wagetj．oo(1 43)with Alvin 11．05．2009

j‘捌BAT vⅥdget_1．oo(1 43)with N86 11．05．2009

j鲫BAT wdget_1．00(1 43)with N97 1 1．05．2009

o舒BAT Wdget_1．00(1 44)with Alvin 1 1．09．2009

二勤BATV、hdget_1．oo(1 44)with N86 11．09．2009

j鲫BATWdget_1．00(1 44)with N97 11．09．2009

p神BAT wdg既j．00(1 44)with Sage”．09．2009

一蝴BAT Wdget_1．oo(1 45)with Alvin”．1 1．2009

■‘封BAT wdgetj．oo(1 45)with N86 11．”．2009

一’蝴BAT Wdgetj．00(1 45)with N97 11．”．2009

■’螂BAT wdget_．1．oo(1 45)with Saga 1 1．1 1．2009

■’蝴Full Round Tests—All widget ASTE cases V 1．0．1 45 with N97

0鲫Full Round Tests-for Widget with Alvin v 1．0．145

■舒New Feature testing for$27 widget with Alvin

■脚New Feature testing for$28 widget with Alvin

图3-4测试执行

在在测试计划制定完成后，其他各种测试行为依据测试计划逐步展开。

 

3．2．2测试用例设计

在敏捷测试的起始阶段，测试人员不能得到全部需求，而且即使是已有需求

也有可能发生变化。在每个迭代周期的初始，项目组通常只能获得User Stories。

因此，为保证测试用例能有效地应用于测试实践，测试用例设计需要更复杂的流

程。在Shan项目组中，测试用例的流程如图3．5所示。

 

软件是开发人员需要去努力实现敏捷化的对象，而测试用例则是测试人员需

要去努力实现敏捷化的对象。要想在测试用例的设计方面应用“能工作的软件比

全面的文档更有价值”这一敏捷原则，关键是考虑怎样使设计出来的测试用例是

能有效工作的。而且测试用例的设计也已经不是一个阶段，而是需要迭代的，测

试人员需要不断地审视和完善测试用例。

基于上述问题，作者首先考虑了测试用例粒度的问题。

测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的

纲要，仅仅指出要测试的内容，如探索性测试(ExploratoryTesting)中的测试设

计，仅需指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试

方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定

输入的每项数据，期待的结果及检验的方法，具体到界面元素的操作步骤，指定

测试的方法和工具等等。

测试用例写得过于复杂或过于详细，会带来两个问题：一个是效率问题，一

个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考

空间就比较少，容易限制测试人员的思维。

 

 

测试用例写得过于简单，则可能失去了测试用例的意义。过于简单的测试用

例设计其实并没有进行“设计。，只是把需要测试的功能模块记录下来而己，它的

作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功

能包括哪些而己。测试用例的设计的本质应该是在设计的过程中理解需求，检验

需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。

大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是

测试用例设计的关键，也将影响测试用例设计的效率和效果，应该根据项目的实

际情况、测试资源情况来决定设计出怎样粒度的测试用例。

随着每个Sprint的展开，项目组最重要的测试参考资源是UI Spec。因此，更

为详细的测试用例设计主要是基于UI的。通常的设计流程如图3-6所示。

 

 

作者从以下几个方面考虑了基于UI的测试用例的设计与编写：

关于设计。

检查控制流和设计是否符合工业标准。

检查UI设计是否符合流行标准。

比较最终LⅡ与原始UI是否具有一致性。

检查默认值是否正确。

关于功能。

UI设置能够被正确的写入配置文件。

检查键盘的快捷键是否能正常工作。

测试每一个数字输入框：输入不同类型的数字和非数字字符。

关于拼写和信息。

检查拼写是否正确。

检查提示信息对于最终用户是否有好。

检查错误提示信息是否能够给用户提供正确和足够的帮助。

关于国际化和本地化。

·检查数字格式是否本地化。

·检查日期和时间格式是否本地化。

●+检查UI是否为DBCS字符(双字节字符集)提供足够缓冲空间。

·检查本地化翻译后字符是否被截断。

5)关于兼容性。

·检查UI是否能够在不同浏览器及不同版本上均显示正确。

·检查IJI是否能够在不同的操作系统上运行正常。

·检查UI是否能在不同的语言平台上运行正常。

下面，以Recently played的例子详细说明基于UI的测试用例设计过程，以及

作者的工作成果。在UI Spec中，有关Recently played的几个界面显示如图3．7所

示。

 

首先，在详细研究UI Spec中几个页面关于Recently played功能后，作者设计

出了测试框架，并交由客户进行确认。测试框架图如图3-8所示。

 

在测试框架图通过客户认可之后，作者又根据测试框架图写出测试策略。与

通常的测试用例编写策略相同，作者主要采取等价类划分，边界值分析，错误猜

想等方法。例如表3-2表示的是作者根据Recently played的测试框架图写出的测试

策略框架。

表3．2测试策略框架

作者的相关功能测试框架设计出来后，项目组其他成员对该测试框架进行了

评审，主要是检查是否有遗漏或者重复的功能点，以及测试策略是否正确等，用

以保证测试用例能够有效地被设计出来。

评审后，作者就开始测试用例的编写。初始的测试用例的粒度相对较粗，在

相关功能点锁定后，则细化测试用例粒度，完善测试用例。作者的测试用例的编

写思路和原则表现在以下几个方面：

1)用例的前提条件(Precondition)的l、2、3、4⋯，每一条是平等的，没有先

后之分的，但也是关键部分。

2)操作步骤：表达为一种动作(action)，一般动词开头，且步骤之间要有逻辑性，

有先后之分，如下例(表3．3)。

在这个模块下，根据测试策略，作者编写了测试用例16条。此外，作者还负

责朋友列表模块，听歌状态模块等7个模块的测试用例编写。

在作者目前所参与的31个迭代周期中，共编写测试用例141条。限于篇幅约

束，就不一一列出，而只将编写的各模块的测试用例数量列出：

●登录与退出：14

·听歌状态：t4 。

·听歌历史：29

·我的文件夹：35

·正在听歌：12

·朋友列表：27

●错误提示：10

 

 

3．2．3测试用例评审

测试用例设计出来后，为保证测试用例的质量，需要进行同行评审。图3．5

的蓝框范围内就表示了测试用例的评审过程。临时的同行评审，类似结对编程一

样的方式，体现了敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例

设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计及编写。作者在

实践的基础上，总结了测试用例评审的一些评审规则(表3．4)：

 

对于同行评审后的测试用例，修改完善后就可以作为最终的测试用例交给测

试人员进行测试。当然，如果某些方面发生变化，如IJI、需求等，还要进行测试

用例的再次迭代。

由于评审时，都是轮换评审与被评审，且还与Web端进行交互评审，而每个

测试人员的测试用例数量不尽相同，所以没有准确的工作量统计。如果根据到目

前为止共有15版UI，每次在UI测试用例设计后的测试用例评审人均30条计算，

可以错略估计作者测试用例的评审量为450条。

3．3测试执行

针对产品的两部分，Shan项目组也进行了两部分测试实践，即Web端和手机

端的测试。在每种测试中又分为手动测试和自动化测试。

在自动化测试工具选择上，Web端使用的是Selenium自动化测试工具，手机

端使用的是ASTE自动化测试工具。

3．3．1测试活动

Shan的测试活动是在不同的测试环境上，依据不同的测试优先级别，选用不

同的测试手段实施的。

1)测试环境

测试运行环境测试执行测试的基础。

Shan测试分为Web端和手机端两部分，表3．5和表3-6表示了在项目进行到

29

某个Sprint阶段所需要准备的全部测试环境。随着项目进行，市场需求会不断发

生变化，例如Windows 7，谷歌浏览器，以及N900手机的上市，根据其市场保有

量及重视程度，测试环境内容及优先级都会发生变化。

只有测试环境准备正确，测试活动才能顺利进行。

2)测试活动及优先级

测试活动主要以国际化软件的核心功能测试为主。测试主要分为版本可接受

性测试、新功能点测试和测试全集测试。

·BAT，即版本可接受性测试，测试优先级别最高。

BAT也可以表述成另一种测试行为，即Nightly Build测试。Ni曲tly Build是

测试团队每天都会收到的版本。除了每天都会收到，Ni曲tly Build还有一个特点是

变化性较强且不稳定。因为开发人员根据Sprint Backlog每天都会完成或修改一些

功能，这些变化极有可能导致版本衰退。所以NB Testing的主要目的是验证软件

主要功能是否有衰退。在项目中前期，Web端每天会有一到两个版本，选取一个

电脑操作系统和浏览器进行测试；手机端每一天或两天有一个版本，在三个手机

操作系统中各选取一款手机进行测试。每个Sprint对应test set中的测试用例内容

及数量应该相对固定，且皆为验证功能是否能够正常完成，这样NB Testing易于完成且方便客户对比测试结果，所以NB通常以自动化测试方式为主。NB test set

变化的原因应该是随着项目的前进，更多功能被完成，更多基本功能需要被验证，

更多case需要被添加或者因为己不再适用而被移除。

在这个测试活动环节，作者的工作是执行手机端的BAT测试。在每个迭代周

期中，测试用例的数量多少会有些变化，手机端的测试用例平均在40条，每个迭

代周期的测试版本会产生4．5个，所以以平均计算，在31个迭代周期中，工作量

可计算为4．5*40*3l，即共执行5580条BAT测试用例。

●New feature，新功能点测试

在每个Sprint中，都有新的功能完成。开发人员会在提供Ni曲tly Build的同

时，表明新的版本实现了哪些新的功能。当一个Sprint中的所有计划的功能点完

成，或者在Sprint结束的时候，都要进行New feature的验证，通常由手动测试完

成。在时间允许的情况下，自动化测试人员可以参与其中。这样，一是提高了测

试效率；二是自动化测试人员可以更直接地了解哪些功能点适合转化成自动化测

试。

在这一方面，由于作者主要执行自动化测试，所以参与不多。·Sprint Release Testing，迭代版本发布测试一

每一个Sprint结束的时候，开发团队需要提交一个Sprint Release作为Sprint

的成果物及演示的依据。在很多Serum模式的项目实践中，这个版本实际就是某

一个NB。相对于NB Testing，Sprint Release的测试更加细致，不仅仅验证功能的

基本可用性，还会对于功能使用的不同情况进行验证。另外，由于SprintRelease

理论上应该包含了SprintBacklog中描述的所有功能，所以对于新功能的验证也是

测试内容之一。测试完成后，TestManager和DevelopManager将测试团队提交的

TestReport作为描述SprintRelease质量的重要文档附在SprintReleaseNotes中供相

关人员参考。

在这个测试阶段，作者作为自动化测试人员，主要的工作是对新加功能进行

自动化脚本开发，很少参与测试执行。而自动化脚本的工作量统计，将在下一章

关于自动化脚本编写的内容中提出。

●Full set，测试全集测试

这是一个更为完整的测试，不仅仅局限于一个Sprint的测试用例，它包括了

截止到某个Sprint为止，所有应完成的功能点的测试。通常每两个Sprint执行一次。

可以不包括全部测试环境，但是覆盖率要尽可能广。

测试全集里的测试用例是随着新功能点的实现不断增加的。所以，以第35个

迭代周期为例，作者参与执行自动化测试用例128条，手动测试用例30条。在总

共参与的31个迭代周期里，粗略估计共执行测试用例1500条。

 

在功能测试的执行上，由于作者主要进行的是手机端的自动化测试，所以有

关自动化测试的详细过程与活动，将会在第4章作更为详细的论述。

3)内存泄漏测试

在计算机科学中，内存泄漏指由于疏忽或错误造成程序未能释放已经不再使

用的内存的情况。内存泄漏并非指内存在物理上的消失，而是应用程序分配某段

内存后，由于设计错误，失去了对该段内存的控制，因而造成了内存的浪费。

内存泄漏会因为减少可用内存的数量从而降低计算机的性能。最终，在最糟

糕的情况下，过多的可用内存被分配掉导致全部或部分设备停止正常工作，或者

应用程序崩溃。

内存泄漏可能不严重，甚至能够被常规的手段检测出来。在现代操作系统中，

一个应用程序使用的常规内存在程序终止时被释放。这表示一个短暂运行的应用

程序中的内存泄漏不会导致严重后果。

在以下情况，内存泄漏导致较严重的后果：程序运行后置之不理，并且随着

时间的流失消耗越来越多的内存(比如服务器上的后台任务，尤其是嵌入式系统

中的后台任务，这些任务可能被运行后很多年内都置之不理)；新的内存被频繁地

分配，比如当显示电脑游戏或动画视频画面时；程序能够请求未被释放的内存(比

如共享内存)，甚至是在程序终止的时候；泄漏在操作系统内部发生；泄漏在系统

关键驱动中发生；内存非常有限，比如在嵌入式系统或便携设备中；当运行在一

个终止时内存并不自动释放的操作系统(比如AmigaOS)之上，而且一旦丢失只

能通过重启来恢复。

由于手机内存有限，所以测试人员要对Shanno widget进行内存泄露测试，以

确保程序使用可以被用户接受。

Shanno widget的内存泄露测试使用的工具是Goofy，它可以记录Nokia手机

的内存使用情况。首先要在手机端和电脑上安装Goofy，然后打开手机端的Goofy

录制功能录制一个操作过程；录制完毕后，在手机文件管理器中找到录制文件到

复制到PC端的Goofy文件夹下，启动Goofy程序进行分析；Goofy会生成一个．CSV

文件，这个文件可以被Excel打开并进行统计。

下面的表格和图表，是作者进行启动Shanno widget程序的内存使用测试的结

果分析。

在使用Goofy在使用Goofy录制后，得到内存使用情况如表3-7所示，

 

 

 

4)缺陷的报告与追踪

缺陷处理是测试活动的重要一环，而且Shan项目组的测试实践依照国际化软

件测试中的缺陷驱动测试方式，内容繁多，将在3．3．2章节中进行详细介绍。

 

3．3．2缺陷处理

对于软件测试人员，寻找和报告软件缺陷是最本职的工作[12】。

Shan作为国际化软件，规模大，对质量的要求严格，测试过程中发现和报告

了大量的软件缺陷。这些不同类型的软件缺陷分别由不同角色的项目成员报告和

处理，由于测试人员和开发人员分布在不同的国家和地区，而且测试人员包括了

内部测试和外包测试两部分，因此，缺陷的跟踪及管理都非常重要。

借助基于互联网的全球的软件缺陷系统，软件项目团队的全体成员对软件缺

陷进行集中管理。使用缺陷追踪数据库，可以使项目测试和开发的进展情况更加

透明。同时，这也是与缺陷跟踪工具驱动测试相适应的。测试人员向缺陷跟踪系

统报告新bug，在新版本上执行回归测试验证bug是否正确修正；开发人员每天浏

览属于自己需要处理的bug，修正bug后及时更新bug的状态；项目经理根据缺陷

跟踪系统的bug分布信息，跟踪和控制软件开发过程；市场销售和技术支持人员

根据缺陷跟踪系统的bug状况，估计软件的发布期限。图3．10表示了缺陷跟踪系

统驱动的软件测试。Shan项目组的缺陷处理实践也是在此基础上进行的。

 

 

判断一个运行结果是否是软件bug，可从以下几个方面分析：软件未达到产品

说明书标明的功能；软件产品出现了产品说明书指明不会出现的错误；软件功能

超出产品说明书指明的范围；软件未达到产品说明书虽未指出但应达到的目标；

软件测试人员认为软件难以理解、不易使用、运行速度缓慢，或最终用户认为不

好。

一旦测试人员认定软件缺陷后，就要编写缺陷报告。缺陷报告是测试过程本

身的主要有形产品，是描述在待测试系统中能够影响顾客的质量经验值的失败模

式的强健的技术文档。优秀的缺陷报告对反映测试小组真实的和可理解的工作质

量，同测试本身一样都是非常重要的。在缺陷的描述上，至少要包括以下一些方

面内容：序号、标题、预置条件、操作步骤、预期结果、实际结果、注释、严重

程度、概率、版本、测试者、测试日期。在实际提交bug时可以根据实际情况进

行补充，如附上图片、log文件等。

测试人员除了要及时处理相关bug的状态外，还要根据整个项目的进展集中

分析处理缺陷。根据NokiaScrum Testing的缺陷处理流程，可以看出每个阶段测试

人员关注处理缺陷的方式都是不同的，这与里程碑驱动的测试又是相适应的。

在Nokia Serum mode项目进行过程中，对于不同的项目阶段，测试团队提交

的ErrorReport的侧重点也有不同，开发人员对于测试团队提交上来的ErrorReport

会采用不同的策略对待。所以测试人员也根据这种策略采用了不同的缺陷报告方

式。

在功能开发阶段，由于开发人员专注于User Story即功能的完成，所以在这个

阶段以报功能的缺陷为主。如果功能基本完成，测试人员则将积累的UI问题验证

重现后提交给开发人员。同时验证bug修复情况。

根据测试实践经验，bug的产生主要在新功能实现阶段，回归测试产生的bug

并不多。而作者的自动化测试实践主要用来进行回归测试和版本验证测试，所以

累计的bug总量为34个。在缺陷处理方面，作者的主要工作是验证bug的修复情

况，跟踪bug状态。此外，作者的另一项工作是评审缺陷报告，这项工作的意义

在于提高缺陷报告的质量。在Widget端目前共198个bug中，除去作者自己提交

的bug，对其余的缺陷报告都进行了评审工作。

对于一定阶段的缺陷整理分析，有利于产品质量的提高。图3．11就表示了

Shanno widget的质量分析情况。

 

 

 

3．4测试总结与需求管理

测试总结与需求管理都是对测试项目组的测试活动进行整体掌控的方式，是

有效管理敏捷测试的行为【13】。

3．4．1测试总结

测试总结是对测试行为及结果的汇总与分析。测试总结可以是测试组内部的

测试活动的总结，也可以是测试组在整个Scrum团队中行为的总结。测试总结是

为了更好地实施测试活动，提升软件产品的质量。

测试团队对于整个Scrum团队的测试总结的主要输出成果是测试报告。在

NokiaScrum软件开发过程中，测试团队定期提供软件测试报告是非常重要的。良

好的软件质量报告可以帮助Scrum Master了解当前软件的质量情况，并帮助Scrum

Master改进下一阶段的软件开发过程。测试团队可以在每个Sprint结束时向Scrum

Master提交软件质量报告。

在一个完整的测试报告中，首先要包括测试概况，即测试的用例数量，通过

率等。在此基础上，还要详细列出在这个Sprint中出现的新bug，以及因此fail掉

的测试用例；对于所有未通过的测试用例给出未通过原因，包括未执行的测试用

例。如果测试是在不同的环境下进行的，还要给出不同环境测试结果的对比结果。

表3．8表示了在进行一轮测试后，作者编写的测试报告的最主要内容。

在测试报告中，还有一点虽然不是必须的，但却是很重要的，就是用户体验。

这是敏捷测试的核心价值观之一。测试人员要根据自己的测试行为，以最终用户

的角度对产品实现的功能进行评价，可以表示肯定，最好是提出意见和建议，以

促进开发人员实现更好的软件。

在测试团队内部的总结的主要输出产物是项目问题管理表。其组成要素有如

下几个方面：报告人、报告时间、问题来源、问题类型、问题描述、严重程度、相关工作产品、原因分析、责任人、计划解决措施、计划解决时间、实际解决时

间、实际解决情况、问题状态。根据上述要素跟踪问题的产生和解决，可以总结

出测试活动的不足之处；在解决方案顺利实施后，可以促进项目组的整体活动向

更好的方面发展。

_●‘

。

3．4．2需求管理

采用敏捷测试模式的项目中，客户对于需求的变更很频繁。因此，需求管理

是十分必要和重要的工作。

需求变化主要有两个方面。一是每个Sprint都会有新的需求产生，这在3．2．1

章节的需求获取环节已经提过。在新的需求产生前，应该及时备份现有需求，形

成完整的需求变更列表，以便总结观察项目的进展变化。

需求变化的另一方面是来自市场的变化。由于Shan的产品是面向全球用户的，

因此世界市场需求与环境的变更也使测试需求发生改变。市场的变更主要也有两

个方面，这也可以从Shan测试的两方面来体现。

Shanno widget是基于Nokia手机的应用程序，因此，随着Nokia移动设备市

场的战略调整，测试设备和测试策略也要做相应改变。根据目前的市场状态，决

定测试手机被执行的优先级别。

Ovi Sharmo是基于互联网的服务，测试在PC端进行，所以随着主流PC操作

系统和浏览器的变化，测试重点和测试策略也要进行改变。表3-9表示了针对上述

问题的需求管理。

 

 

4测试过程中的自动化实施

软件自动化测试，是一项让计算机代替测试人员进行软件测试的技术。软件

测试自动化可以使某些任务提高执行效率，具有很多优势。随着传统测试策略愈

发难以适应当前复杂的软件开发需要，甚至还存在导致各种问题及错误的风险，

自动化测试愈来愈受到软件开发及测试人员的重视。

软件自动化测试就是各种测试活动的管理与实施，包括测试脚本的开发与执

行，以便使用某种自动化测试工具来验证测试需求。它是结合项目测试的需求，

通过自动化测试工具或其他手段，按照测试工程师的预定计划进行自动的测试，

目的是排除影响测试的人为因素，减轻手工测试的劳动量，从而降低花费在测试

上的开销，达到提高软件质量的目的。它的意义在于使测试过程变成更加系统化、

有计划的过程，能够被更迅速、更正确、更经济地完成。

软件自动化测试是一个复杂的过程，为了确保自动化测试的成功，就必须遵

循软件开发流程。因此自动化测试的执行应经过需求定义、测试计划、测试设计、

测试开发等一系列的活动。为此，Dustin、Rashka和Paul合作公布了自动化测试

生命周期方法学(Automated Test Lifecycle Methodology，ATLM)——这是一种经

过调整的结构化方法学，能确保自动化测试的成功实现。它定义了以下六个阶段

方法学：自动化测试的决定：自动化测试工具的选择；自动化测试的引入；自动

化测试计划、设计和开发；．自动化测试的执行和管理；自动化测试项目评审【14】。

 

4．1自动化测试的计划

自动化测试的计划是自动化测试的准备阶段，是能否良好实施自动化测试的

保障。

这个阶段是成功引入自动化测试到一个新的项目中所必须的步骤。测试过程

分析确保整个测试过程和测试策略适当，必要时可以加以改进，以便成功地引入

自动化测试；在测试工具考查阶段，测试工程师根据测试需求、可用的测试环境

和人力资源、用户环境、平台以及被测的应用的产品特性，研究将自动化测试工

具或实用程序引入到测试工作是否对项目有好处。

4．1．1自动化测试的评审与决定

测试项目的评审与评估是贯穿于整个自动化测试生命周期的活动。尤其当自

动化测试应用于敏捷测试中，在每个Sprint开始的时候，随着迭代功能的不断实

现，测试需求的变化，以及测试资源的变化，都要对自动化测试的执行能力进行

重新评审，以确定可以执行的自动化测试用例。

在这一阶段，测试团队对自动化测试进行风险评估、鉴别和确定测试需求的

优先级，估计测试资源的需求量，开发测试项目计划以及给测试小组成员分配测

试职责；找出能自动化的软件测试过程以及应该自动化的软件测试过程；知道自

动化测试的预期结果和列出在正确执行自动化测试后的益处；同时，需要列出自

动化测试的备选方案。

自动化测试主要执行BAT(Build Accepting Test，版本验证测试)，以及比较

稳定模块的测试；通常，对于New feature的功能，由于不确定其实现的完整性和

稳定性，通常都由手动测试首先执行。

在自动化测试执行之前，自动化测试人员和手动测试人员会一起讨论各个功

能的实现情况，最终确定自动化测试执行的cases。表4．1给出了这样一个例子，

是对于Recently played view的测试用例的分析情况。

 

 

4．1．2自动化测试工具的选择

测试工具是用于促进测试过程的。测试工具能被用于实现一个过程并执行测

试过程的各种规范。在很多情况下，测试工具自带的内建程序可以被理解为过程。

然而，它们往往是不完整的，不能正确反映过程。一个最好的软件测试工具能够

提供高度可自定义的工作流程和跟踪报告能力，更好的满足测试需求。因此，这

一阶段用于指导测试人员对自动化测试工具进行评估，并确定使用的测试工具【15】．

Shan项目组针对手机端测试选用的是ASTE自动化测试工具。

ASTE(Automatic System Test Engine)是Nokia专门为Nokia Symbian$60操

作系统编写的自动化测试工具。测试过程基于UI(用户接口)实现：通过关键字

控制终端的键盘、旋钮和触摸屏来模拟测试工程师的双手操作：抓取LCD屏幕显

示图像进行智能比对识别来模拟测试工程师的双眼辨识文字或图像信息。由于

ASTE是服务器的解决方案，所以不提供用户接口，需要通过LUX来进行控制；

通过HTI(一致性测试接口)实现PC和Symbian OS设备的信息传递，以此来实

现控制手机，按键和截屏等操作【16】． ．

HTI(Harmonized Test Interface)是一个用来操控Symbian操作系统的组件。

HTI框架用于处理执行操控的系统设备(通常是PC)和被操控的Symbian操作系

统设备之间的信息通信。ASTE通过使用HTI来控制手机执行按键，截屏，移动文

42

件，开始／停止程序等操作。

可以使用ASTE及HTI的环境是：PC操作系统是Windows，系统语言是英语。

被测试的设备(手机)支持HTI和ASTE的主题。

LUX是一个用户接口，能够通过Windows系统使安装了ASTE的

Symbian／Nokia硬件自动执行基于UI的测试，并自动产生logger和测试结果，方

便测试人员及时有效地分析测试

 

4．2自动化测试脚本设计与评审

自动化脚本的设计与评审属于自动化的测试开发阶段。在此阶段，测试团队

要在测试分析和设计的基础上，创建具有可维护性、可重用性、简单性和健壮性

的测试脚本。并且通过脚本评审，保证测试脚本的质量和有效性。

 

4．2．1自动化测试脚本设计与维护

Shah项目组自动化测试团队所选用的脚本语言是ASL脚本语言(Advanced

Scripting Language)，ASL是由Nokia公司研发的，与自动化测试工具ASTE相适

应的脚本语言。它使用关键字和参数模式，同时支持球语句，循环语句和多种变

量。ASL的文件是100％基于文本的。Keywords由Action Keywords，Verification

Keywords和Miscellaneous Keywords组成，在脚本编写中使用最频繁的Keywords

如表4．2和表4．3所示。

43

自动化测试脚本的设计与编写是基于自动化测试用例的，测试脚本的文件格

式为TCF，每一个文件储存一个测试用例。作者的自动化脚本设计策略如下：

1)制定集成策略，编写初始化、场景恢复脚本。

首先制定集成策略的目的是：在编写脚本时遵守相同的原则，以便使后期的

调试工作更加方便有序，同时提高脚本的健壮性。

对于集成策略，首先要考虑的是每条case的初始化与场景恢复设置。为了排

除case之间的耦合依赖关系，编写的每一条case，都要在其中考虑有相应的初始

化与场景恢复部分。

ASTE提供了两个独立于case主过程存在的语句块(]'NIT和CLEAMJP)来

进行初始化与场景恢复。例如(图4．2)：

其次，在测试过程中，使用不同的测试账号进行测试，排除因数据使用而造

成耦合依赖关系的可能。此外，对测试帐户设置统一的Login，RemoveAccount

步骤。

2)编写Macros描述若干公共步骤。

作者使用Macros的有以下几点考虑：

·对一些case执行过程中遇到的公共步骤(非测试点部分)，将其定义为Macros，

在编写脚本的时候进行调用，可以增加脚本的重用，同时减少脚本编写上的工

作量。

·拆分调试过程，对调试过程进行细分，减少Debug需要的时间。

·增加脚本的健壮性，方便脚本的更新，减少feature变动时脚本的维护成本。

·使不同平台下脚本的移植更加有效率。

3)创建脚本文件。

使用TCF格式保存脚本文件。脚本编写要将验证步骤和验证点通过ASTE提

供的关键字描述下来。

在编写脚本过程中，要注意添加注释，描述case的测试步骤与期望结果。将case

中的内容作为注释添加到脚本文件中，可以极大的方便脚本的review与维护。通

常，一个测试脚本的脚本结构(The StructureofScript)可表示如图4-3：

 

4)准备测试数据。

准备测试过程中需要使用到的测试数据。例如特殊账户的建立，特殊字符文

件等。为了保证测试用例之间互不影响，作者共建立特殊账号128个，这与作者

的脚本编写是一一对应的。

5)调试并查看运行结果。

对编写好的脚本进行最终的调试，对于脚本中有错误的部分进行修改。脚本

调试要在不同平台间的移植，包括不同型号的手机之间和不同版本的浏览器之间。

在整个项目实践中，作者共编写测试脚本128条。

有关脚本的另一个重要方面是脚本维护，也可是说是脚本修改(Script

modify)。由于项目采取的是Serum敏捷开发模式，每个Sprint中只是实现一部分

功能，而且无法确定产品的最终形态，整个项目是一个持续集成的过程。另一方

面，在Nokia Scrum Testing中，需要自动化测试的尽早介入。所以基于以上原因，

某一功能点的自动化脚本在其相对稳定后就开始进行设计与编写。但是随着该功

能本身以及与其相关的功能的逐步完善，自动化脚本也要进行相应的修改。因此。

脚本修改需要相当大的工作量。图4．4表示了自动化测试脚本后期的维护的成本构

成。

 

脚本修改在某种程度上可以说是脚本的再次设计。脚本修改的原因主要有两

个方面：一是功能点本身的UI设计发生变化，某些流程或验证方式需要进行修改；

二是相关的功能点完成或改变而产生的变化，需要进行相应的修改。对于第一种

原因的脚本修改相对容易，只需要添an／删除，或者修改某些步骤，或是修改验证

方式。例如，有关听歌历史的分页问题。在最初的UI设计中，在听歌历史界面中

每页显示8首歌，而后期的UI中又改为10首歌，这样我们只需要修改歌曲计数

器的判断条件即可。而对于第二种原因产生的脚本修改，则相对复杂，因为经常

涉及到几个功能点。下面通过一个典型的功能点的脚本来说明这种脚本修改。

在Shanno widget中，一个很重要的功能是，使用手机的音乐播放器Music

player播放的音乐可以加入Shan的听歌历史里。这种加入的条件的是，只要当

Shanno widget的账户连接到Shan的服务器，Musicplayer里的听歌记录即会被导

入Shan的听歌历史里：而不需要必须先连接到Shan的服务器才可以。但是Shanno

widget与Music player相关联的听歌行为是在Sprint 24才完成的，而听歌历史的列

表功能则在Sprint 10就完成了，而且听歌历史在W曲端和手机端都有涉及，所以

与听歌历史相关的测试用例就需要设计完成，并且相关的脚本也要设计完成，于

是听歌情况我们就需要在已有的可用的功能的基础上进行设计。在Sprint 10阶段，

听歌记录是通过Ovi旗下的另一项服务Ovi Contacts实现的。Ovi Contacts集成了

聊天室、twitter、名片夹、共享GPS坐标、共享听歌状态等功能，所以我们需要

先登录Ovi Contacts，再在Music player听歌，才能将听歌历史传入Shan的听歌历

史里。因此，此阶段的设计需要启动Ovi Contacts相关功能，脚本设计的流程如图

4．5所示：

而且，在脚本最后的场景恢复阶段，还要恢复Ovi Contacts相关设置。

由于Shan的产品设计就是要整合Contacts和NokiaMusic，所以必然要弱化Ovi

Contacts的音乐共享功能，而由Shanno widget整合完成。所以，在进行到Sprint 18

的时候，Ovi Contacts的网络共享功能被关闭了，而Shanno widget与Musicplayer

的关联功能并没有实现，所以我们需要设计新的算法来实现刷新听歌历史的功能。

在与开发方充分沟通后，Widget端与Web端的自动化组设计出了模拟听歌

(Scobble)的算法程序playbackPost．PY，它不依赖手机而实现指定账号的指定歌

曲的听歌功能。在配置好测试文件以及测试数据后，只需在脚本中调用批处理文

件ExcuteScobble．bat即可。

kw—ServerExecute ”D：＼＼Shan＼＼Scrob＼kExcuteScobble．bat”

这个脚本在Sprint 24实现Shanno widget与Music player的关联功能后，也有

使用价值。如果只是检查听歌历史，而不需要验证听歌状态，同样可以调用此方

法，可以节省真实听歌状态的听歌时间，加快测试速度。

当然，在Sprint24实现Shanno widget的音乐共享功能后，需要完成相关功能

的脚本编写，相关脚本也必然要进行修改。此阶段的脚本设计类似于Sprint 10的

脚本，只是不需要调用Ovi Contacts，而是在编写宏函数后在Shanno widget直接

调用Music player程序。主要的不同之处如下所示：

CALL LaunchOviShanno(％Account％)

CALL HL_NowPlaying槲点击NowPlaying的图标即可进入Music player程序

脚本的维护的工作量是巨大的。对于15的版本的UI Spec，基本上每一版都

有相应的脚本维护工作。

4．2．2自动化测试脚本评审

在脚本编写并调试完毕后，为了提高脚本的质量，从而确保测试质量，还要

进行脚本评审。

参加并负责的评审人员由A．其他的脚本编写者和B．手动测试者组成。选择A

的好处是熟悉脚本的编写规则，Review速度快；不足是模块信息掌握相对不全面，

Case中的测试目的与测试点的覆盖，在实现上是否完全，可能会存在纰漏。选择B

的好处是对测试模块与Case的把握相对全面；不足之处在于，不熟悉脚本的编写

规则，阅读脚本速度慢。

评审方法采取的是C．文本走读和D．脚本执行两种方式。C中主要进行根据

Check Point进行脚本的静态检查，Check Point由表4-4所显示的要素组成。D检

查脚本在实际运行中是否存在问题。在过程C发现的问题，会提交给ScriptDesigner

对脚本进行修改或重新编写。在D中发现的问题，ScriptDesigner应重新进行

Debug。

对于数量较大的脚本编写计划，可以进行数次的评审，提高脚本的质量，减

轻脚本维护上花费的工作量。

脚本的分数是评审活动的主要成果物，这些分数是评审者根据Check Point对

每条脚本进行评分活动而得出来的。

在评审过后，脚本设计者可以与评审者对脚本中存在疑问的部分进行讨论。

在讨论过后，脚本设计者根据结论修改、重写或重新调试脚本。

4．3自动化测试实施

在脚本准备完毕后，就进入了自动化测试的真正实施阶段。ASTE主要执行基

于UI的功能测试，在某些情况下也可以执行性能测试。

4．3．1自动化功能测试

无论执行哪种测试，对于测试对象和测试脚本的配置是相同的。执行测试前，

有两个重要的文件需要配置，ASTE．Xml和Target．Xml，而且是在每次执行不同的

脚本和手机设备时，都要进行重新配置。在ASTE．Xml中，要配置被测试手机系

统的发布版本(softwareRelease)，数据驱动文件Localisation．xls和Userinputs．xls

(包括通用的和被测目标专用的)。在Target．Xml中，主要配置连接方式HTI和

DataGateway，以及接入端口COMPORT，这需要在被测目标连接计算机后在计算

 

机的设备管理器中查询。配置部分详细如图4-6标识。

 

LUX在执行自动化脚本时，可以单条执行，也可以执行一个测试集。

如果执行测试集，可以通过配置TestDrop实现。TestDrop是测试脚本版本控

制的框架。Test DropFrame由如下三个部分构成：Localisation，TestCases，

Testdrop．xml。Localisation用来存放Symbian$60的系统文件，其中Localisation．txt

文件用来定义逻辑名，定义逻辑名的好处首先是使脚本参数化，避免了由于UI变

动而产生的大量的验证点的修改；其次，在产品本地化阶段，即使测试人员不了

解测试界面的语言，自动化脚本执行也可以根据逻辑名比对出验证点是否显示正

常。TestCases用来存放要运行的测试脚本，其中Userlnput．txt用来定义用户的测

试数据，BDF．txt用来定义Bitmap，Images文件里要存放BDF．txt中定义的相应的

图片。Testdrop．xml用来描述TestDrop的结构。TestDropStructure如图4．7所示。

 

这样的生成结果，可以清楚地判断出错误出现的位置，根据运行步骤的判断，

可以明确错误的原因：是因为脚本设计导致的错误，还是软件本身功能的错误，

或者是未知错误的出现，比如系统崩溃。根据不同的出错原因，可以进行脚本修

改，或者是提交缺陷报告，或者选择重新测试。

作者的自动化功能测试主要执行了BAT测试，测试全集中的部分测试用例。

整体工作量可以根据3．3．1章节中的工作量进行综合计算。

 

 

4．3．2自动化性能测试

自动化测试除了进行功能测试外，还可以进行性能表现测试。例如在项目中

前期，服务器很不稳定，登录性能很差。为了向Scrum Master和开发人员提出改

进意见，测试项目组进行了性能表现测试，希望通过结果的严重性，促使开发人

员改进登录表现。

表

 

根据上述自动化测试执行，能够看出自动化测试可以完成一些手工测试不能

或难以完成的测试。对于一些非功能性方面的测试，如：压力测试、并发测试、

大数据量测试、崩溃性测试等，这些测试用手工测试是很难，甚至是不可能完成

的；但自动化测试则能方便地执行这些测试【17】。

在整个自动化测试实践中，作者一共执行了10次性能测试。

4．3．3自动化测试实施评估

决定自动化测试实施成败有两个关键因素，一是前期缜密的筹备；二是执行

过程中灵活地根据实际情况进行调整。在自动化测试实施阶段，每个过程都有自

己的关注点和工作量。表4．7表示了自动化测试各个阶段的工作量分配和关注点。

每一个阶段的问题如果没有解决，不宜开展下一阶段的任务，这样容易将可

能的错误风险直接传递到后面的工作中。从表4．7中可以看出，自动化测试框架是

自动化测试实施的一个非常重要的组成部分，它是一系列思想、规范和代码实现

的组合。Shan项目组就是根据这样的工作计划来控制测试的执行效率和进度。

4．4本章小结

本章主要阐述了作者的自动化测试实践。自动化测试是Shan项目组测试活动

的重要组成部分，也是保证测试活动顺利进行的重要一环。本章基于作者的测试

实践，详细介绍了自动化测试实施的整个流程，包括自动化测试的计划，自动化

测试脚本的设计与评审，以及自动化测试的功能测试与性能测试的执行方式与过

程。

56

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

四敏捷测试中的自动化测试设计（重点）

 

近年来，随着人们对软件质量的重视，软件测试技术逐渐成为人们关注的焦点。为了应对复杂快速多变的软件需求，越来越多的软件团队将敏捷方法应用于软件实践当中。敏捷开发的核心是测试驱动开发，其适合于更快的迭代开发周期、更频繁的需求和设计的变更的应用。

自动化测试是敏捷测试的关键所在。而在频繁的迭代变更中，如何使测试流程自动化，并对测试用例进行有效管理和复用，成为了目前的难题。本文提出了一个测试集成系统，把自动化测试工具与测试管理工具和缺陷跟踪工具整合起来系统运作，规范了测试过程管理。本文通过详尽的需求分析，提出了集成系统的架构，选取了三款不同种类的开源测试工具作为系统的基础工具，结合详尽的分析、扩展功能设计和数据集成的方法，设计了一套覆盖敏捷测试工作整个过程的测试集成系统，并介绍了该系统的实现。测试分析结果表明，本系统不仅满足了敏捷测试频繁迭代的要求，而且对敏捷测试的生命周期进行了有效的组织管理。

 

2 测试自动化的敏捷方法

每个团队，每个项目都会遇到独有的自动化挑战。无论你所在的团队处于何种情况， 你都可以使用敏捷法则和价值来寻找解决方案。勇气、反馈、简化、交流、持续开发和快速响应这些概念是所有成功团队多应具备的特质［4］。自动化将测试人员“一次构建，多次部署”的梦想实现了［5］。构建和部署过程的自动化使测试人员在任何给定的环境下都可以准确的知道正在测试是什么。TDD （Test Driven Development）使团队优先考虑测试［6］。基于测试来设计代码，所以可测性从来不是问题。自动化测试量与代码库一起增长，为持续的重构提供了安全网。团队也不会产生太多的技术债务， 而且速度稳定甚至能随着时间而加快［7］。

图2 描绘了“测试自动化金字塔”［3］， 引用Mike Cohn 提出的观点， 该观点反映出了由技术单元和组件测试所构成的基础层。基础层由健壮的单元测试、组件测试与支持团队的面向技术的测试所构成。通常情况下， 他们与被测的系统采用相同的语言，使用xUnit 工具家族实现，是TDD（测试驱动开发）的精

髓所在。单元测试代码主要由开发人员来完成， 测试人员在这个级别主要负责单元测试代码review， 或者与开发结对编程共同完成单元测试。这些测试有更大的测试集，针对的是被测产品中的下层功能和类。这些测试也会使测试过程流畅、避免回退，并保持开发动力。保证测试通过率在某个百分点之上才可以进行提测，测试结果报告如图3 所示，在我们开发的项目中，要求方法覆盖率和行覆盖率均达到90％以上，条件覆盖率在80％以上才能提交测试。金字塔的中间层包含了大量用于支持团队的自动化业务测试。这些测试旨在验证我们“在做正确的事情”。该层次的测试包括冒烟测试，功能测试，回归测试。所编写的测试用例会设定好输入和输出，将输入放到产品代码中并接收输出，然后将其与期望结构进行比较。由于这些测试绕过了展现层，因此编写和维护的成本并不高。

金字塔顶层通过GUI 自动化测试完成，会使用并操作展现层。再编写完代码后再来编写这些测试，主要用于评判产品并成为回归测试套件的一部分。该层自动化Ruby with Watir 控制浏览器页面的文档对象模型（DOM），从而可以访问页面上几乎所有的对象。那些自动化测试单元在每天晚上的自动构建完成之后自动运行，使用每夜构建来代替每次构建。持续为团队提供应用软件行为的高层反馈。图4 是本人编写的某个自动化脚本运行结果， 测试人员可以通过点击对应模块链接来查看失败原因，直到所有场景运行通过（图5）。这个架构有效地满足了团队对于面向业务的测试需求。

GUI 层的自动化测试由测试人员独立完成， 所以测试人员需要很好的掌握UI 脚本的编码方法。

 

 

1 目标与需求

该自动化测试框架的目标是，为测试Dddd项目创造一个自动化的测试过程，需求包括：

－ 通过Jenkins制定每次代码提交后，通过xxxx驱动自动部署，部署成功后触发相关模块的单元测试和功能测试。

－ 通过Jenkins制定自动化回归测试的日程表，包括1）每天的Daily Job和2）每次代码提交后，并且在功能测试通过之后，触发自动化回归测试。

－ 生成并分析缺陷报告，向相关人员发送缺陷总结邮件。

 

2 作用范围和限制

该自动化测试框架将尽量使用已有的测试工具，在改进已有的测试脚本，增加灵活性和任务定制的基础上，让整个框架易于理解和维护，降低测试人员所需要花费的维护和开发成本。

 

 

 

五敏捷测试方法与自动化测试实施效果分析

（以项目为实例进行分析）

1 燃尽图走向

2 测试人员工作负载量

3 缺陷消失梯度

4 客户满意度

 

 

六总结与展望

本文以作者所在实习公司的测试项目为背景，详细阐述了敏捷测试实现的过

程和基于敏捷的自动化测试的实施，并在实践基础上，对相关测试问题进行了进

一步的研究。在整个论文撰写和项目实践过程中，具体工作如下：

1)学习敏捷开发过程及各种模型；

2)学习敏捷测试、国际化软件测试和自动化测试的相关方法与技术；

31全程参与项目组测试测试的各个环节，包括需求获取、测试用例设计、测试执

行、缺陷追踪及测试总结；

4)重点参与自动化测试的实施，包括自动化测试的计划与评估、自动化测试的脚

本设计、自动化测试执行，以及提交自动化测试报告；

5)分析并总结了在应用敏捷开发模式的软件项目中，软件测试人员所应具有的敏

捷思想和技术能力；

61研究了自动化测试成本的评估方法，并提出了可行性建议并应用于实践。

在论文和项目实践过程中，引发了作者对于中国软件企业发展的思考。由于

作者所在的项目组是Nokia的外包测试服务提供方，所以在实践过程中可以充分

体会和应用敏捷测试这种先进的理念。在这一点上，对于中国软件企业进军国际

市场具有借鉴意义。首先通过合作，学习国外先进的技术和管理方法，并在自身

实践中应用，改进和完善，提高中国软件企业国际竞争力。

随着敏捷开发模式越来越广泛的应用于软件产品的研发，敏捷测试在近年来

也有了一定程度的研究和积累，并有实际的成功案例可循。但是，敏捷测试还是

处于一个相对不完善的阶段，尤其是对于中国软件测试行业来说。所以，作者会

在之后的工作中进一步加深对敏捷测试的研究，以期能应用于测试实践并提高测

试实践的有效性。

 

5敏捷测试相关问题的进一步讨论

对于测试实践的总结及相关测试理论的研究，引发了作者对于敏捷测试以及

敏捷测试中自动化测试实施的等问题的思考。

5．1关于敏捷测试的讨论

在作者的测试实践中，深刻体会了NokiaSerum敏捷测试的方法与理念，感受

到敏捷在动荡的业务环境中创造变革和响应变革的能力。并根据这样的实践经历，

总结出敏捷测试的核心价值观和作为敏捷测试的一员所应具备的能力。

5．1．1敏捷测试的核心价值观

在Serum敏捷开发过程中，软件测试质量保证工作起到至关重要的作用。作

者在深入体会敏捷模式下软件测试活动的同时，总结出NokiaScrum敏捷测试的核

心价值观，并期望其可以适用于所有敏捷测试的过程：

1)质量第一

在软件测试过程中，要有软件质量第一的思想。任何的软件测试活动，都围绕提高软件质量为目的展开。

2)测试驱动开发

测试驱动开发，是Scrum敏捷开发的关键特征之一。在Serum开发过程中，

每个新功能点的开发，都需要及时有效的测试，包括单元测试，功能测试，回归

测试等。开发人员根据测试结果，快速地进行缺陷修复以及功能改进，以保证特

征功能的质量。

3)持续不断的测试

开发过程中，通常都会有Ni曲tly Build，这就是持续集成生成的版本，每个版

本都包含的前一天对代码的修改，因此要求测试人员在每个版本上都进行连续的

测试。

4) 自动化测试

由于测试人员需要对每个Nightly Build进行测试，相应地，就会产生大量的

测试工作。为了提升测试的效率，节约测试成本，这便是引入自动化的目的。

5)快速响应

敏捷开发过程中，快速有效地进行测试并提交测试结果，能有效提高开发工作的效率。

6)用户体验

用户体验主要是指功能稳定易用，用户界面绚丽精美，目录结构是否合理等

等。每个新功能点开发出来，都要求测试人员在测试过程中对其进行用户体验评

估，并提出好的修改意见，以提高软件质量及在市场上的竞争力。

7)团队合作

在Serum敏捷开发过程中，对开发人员和测试人员都提出了更高的要求，包

括更高的技术能力和更有效的沟通，尤其是开发人员和测试人员之间的沟通。这

就要求Serum开发团队和测试团队作为一个整体，共同为软件质量负责。

 

5．1．2向敏捷转变

如果说开发人员在敏捷过程中的最大改变是工程规范，或者说严格度被提升

到了最高。那么，测试人员在敏捷过程中的改变则是更为多样的。

与瀑布模型环境不同，在Scrum模型环境下，需要测试人员从项目一开始就

参与测试。参加SprintPlan Meeting，并参与到详细制定User Story的过程当中。

从而可以帮助确定User Story的验收测试标准，估算User Story的大小。

敏捷测试中，测试人员还要尽可能多的将功能测试自动化，为团队的综合效

率和生产率做出贡献。精益理论提到，团队要更关注质量构筑和浪费最小化，因

为相较于其他因素，这更有助于改良生产周期(从概念到实践)。所以，编写自动

化测试，就是在为代码库的总体质量做贡献，由此缩短总体周期。

敏捷开发强调的是敏捷设计。设计的灵活性、可扩展性和易维护性是敏捷设

计的目标。而之所以要有这样的目标就是为了适应多变化的需求，而敏捷开发中

高度的迭代正是及早发现问题，及时修正并完善需求的有效方法。同样的思想可

以指导测试人员测试用例和自动化脚本的设计。

综上所述，测试人员向敏捷转变所需要的方法是，尽早的开始测试，开始系

统测试，不要等待到功能完全做好才开始：

了解计划中的待实现的功能，了解其权重分配，设计系统测试和功能测试用

例。测试执行的一开始可以是针对部分功能的，之后可以逐步扩展。接着开始采

用迭代的过程完成测试任务，即将测试任务划分为多个周期，一开始可以做些关

键的功能性测试，可以对代码中的可复用部分(组件，构件)做完整的安全测试、

性能测试、压力测试、并发测试，以及全球化测试等。接着的迭代周期可以做边

缘化的功能测试和其他测试，最后的几个迭代应该用于回归测试，关键的性能和

稳定性测试。

策略性的进行自动化测试，设计并开发可以用于日后回归测试和用户接收测

试的自动化脚本，持续维护与开发这些脚本。自动化测试为团队带来的是长期效

益，自动化测试的开发也应该首先选择部分测试对象，例如，API，框架等比较稳

定和关键的功能做功能测试的自动化；对产品的性能指标，压力测试也要较早的

制定自动化测试的计划。

最后，要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人

员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需

求分析，设计和开发。积极地参与前期工作，并迅速反馈给设计和开发其静态测

试结果[tsl。

 

 

简洁，轻量的敏捷开发模型是为了提供给软件开发团队一种迅速应对客户需求变化，能够高效完成项目工作，降低整体风险的开发模式。敏捷的测试也是服务于这个目标的测试团队对测试工作的敏捷定义。

        传统测试模式下成长起来的测试团队要如何转向敏捷，从个人和团队的两个层面又要做出那些转变呢？有什么方法和标准衡量敏捷测试团队的绩效？如何帮助团队的每个人规划正确的发展路线？团队在部署敏捷的过程中又会遇到哪些问题呢？本文主体就这些问题展开论述。

有关敏捷测试团队和个人的绩效

        在我们过去一年多开发敏捷项目的令人难忘的经历中，测试团队携手开辟了一条新的道路，并发展至今。测试团队也曾多次因其突出的能力，积极的态度以及卓有成效的工作成果屡受嘉奖。今天我们仍然在思考怎样做好敏捷测试，因为我们仍然遇到更新的问题，我们在积累成熟经验的同时也在不断尝试改进原有方式和突破对新问题的困扰。在这里，我们的实践或许因基于幸运的历史背景和人文环境，能够基本成功的部署敏捷，但我们对敏捷测试在整个软件开发过程中的角色定位，和职责的理解，仍然对将要采用敏捷测试，以及感兴趣于敏捷的测试团队，和对那些需要从传统测试转变到敏捷测试模式的团队起到参考作用。

        “如何看待敏捷测试和对测试人员做绩效考评呢？”——敏捷团队中无论开发还是测试都不是个人的开发和测试，这是团队的工作。一名好的测试人员除了能够做好本职测试工作外，表现为愿意并能够做超出原有范围的工作，能够并愿意帮助团队其他成员解决其他复杂问题，实现团队的共同目标。测试人员能够主动发现并弥补团队中的重要缺失的环节，帮助团队其他成员完成工作任务。

        测试团队的职责也从仅仅发现问题的工作中向着眼于整个项目质量保障转变。因此不难得到结论，在敏捷团队中，优秀的测试人员身上有其他成员的影子。在时间紧迫的情况下，他能转变成其他角色，做出更多的创造性的成绩。充分地发挥了个人战斗力，在帮助他人的同时，自信的态度和各项工作中的技能得到增强，自身也可以获得更大发展。

        在一次关于敏捷开发、测试经验交流中，我们认为敏捷测试团队更需要其他团队的协助，在设计测试用例时，团队的设计人员应该帮助测试团队设计测试用例，并帮助测试团队做更多的面向客户环境的真实测试。开发团队也要确保开发任务的按时推进，和测试团队保持紧密的合作，在测试任务紧要时，也能够转变其职能帮助测试团队完成测试任务。

测试人员向敏捷转变所需要的技能储备

        这引出我们今天要探讨的一个问题，测试人员如何在技能上做好准备以面临敏捷开发的全新挑战。我们认为，一名优秀的敏捷测试人员，需要有较强的学习能力，至少有主动学习的意愿。除了需要了解各种类型测试以及各种测试工具，测试技术外，也需要了解项目中软件设计模式，软件语言，以及项目的程序组织架构以便建立和团队的共同语言空间。

        因为敏捷团队是一个高度协作的团队，在这样的团队中工作需要很好的沟通技巧，语言能力和协作能力。

        除此之外，团队的每个成员，都应该认真学习并努力寻找适合自己团队的敏捷模式，并沟通以达到团队成员对敏捷开发模式的统一认识，使得团队其他成员对自己工作的充分理解和建立起成员之间的相互信任。

测试人员向敏捷转变所需要的方法

        培养好的敏捷测试人员，需要培养其技术能力，也需要用正确的培养成员的敏捷思想。敏捷的方法指导敏捷团队行动，是敏捷测试原则的实践。从一开始，就深刻影响着团队中每个人。当然，方法不是放之四海皆准的，需要团队对敏捷原则深入理解，执行敏捷测试实践后逐渐形成的规律。而一个传统的测试团队，在固有的行为规律下，在成熟的产品线里，或者层次分明的复杂组织结构里如何做好向敏捷的转变呢？似乎这种改变给许多人带来希望的同时伴随着一点恐慌？我们有没有可行的策略、方法可以遵循呢？可否让团队又能够发挥在传统开发模式下的力量集中的优势，又能够做到敏捷的随需应变呢？回答是肯定的。

        在做转变的实施前，我们需要有心里准备，任何从传统开发到敏捷开发转变不可能一蹴而就，自然也没有人能够将一个传统开发模式下的测试团队一夜之间变成彻底的敏捷。对这些还没有敏捷起来，但仍然以此作为目标的项目团队我们建议循序渐进，基于笔者的亲身体验，提供以下实施的方法请大家参考。

        首先我们建议采用迭代的开发模式作为向敏捷的模式转变的起点。很多传统开发模式或者基本上还是瀑布式的开发，或者是周期性的瀑布式开发，这些都不是敏捷的迭代。敏捷的迭代是高度的迭代，不是瀑布开发的不断累加。换句话说，传统开发是传递性的工作，一方完成，另一方接手。而敏捷活动的迭代行为更强调尽早开展各项活动，从迭代的一开始就协同工作，共同实现团队迭代的目标。而一旦抵达迭代的周期中最后一个工作日，此迭代宣布退出。

        当完成了向迭代活动的转变完成后，接着，我们开始寻找项目过程、管理、执行中最紧要的问题，并使用敏捷开发中的最佳实践来一一解决这些实际问题。也许，一开始这个过程是很缓慢，而且很难做到一步成功，但是必须通过不屑的努力和足够的耐心，慢慢转变团队的固有思维方式，并最终努力获得团队对改进后结果的统一认可。而一个问题被解决，或者不再是项目中最严峻的问题时，我们应该开始寻找下一个待解决的困难了。重复这个过程直至成功的将团队中有悖于敏捷原则和实践的过程和方法调整过来，同时将正确的思路和方法带给团队。

        在最近的几次与其他敏捷测试团队的讨论中，我们同时了解到许多软件开发项目中的测试团队遇到过类似的一些问题，如开发团队没有做单元测试或做得太少，继而在开发过程中的遗留了大量质量缺陷和频繁的回归现象。这使得测试压力急剧加大，测试过程严重受阻，甚至影响到整个迭代的退出和项目的输出结果等等。又或者传统的开发中的测试团队因为很少有条件去认识客户，了解和实际用户相关业务需求。测试脚本和用例的设计只是基于开发人员撰写的功能说明。因此，难以做到对需求变化做出快速反应。经过讨论，我们推荐给对这样的团队如下参考方案。

        首先开始采用测试驱动开发 (Test Driven)。 
        开发人员首先要善于使用测试驱动开发方法写每一行代码，先写测试脚本后写代码，并反复使用单元测试脚本验证所写代码的正确性。

列出需求
为需求撰写一个单元测试脚本
执行测试确信测试结果是失败的
然后，写上仅仅足够的代码以使得先前的测试可以通过
当所有测试通过了，便可以开始写下一个测试脚本
针对需求有效的实现所有测试脚本
另外，当需要代码重构时候，也应该先重构单元测试脚本，在改动代买之前同样先改写测试脚本。

        尽早的开始测试，开始系统测试，不要等待到功能完全做好才开始。 
        了解计划中的待实现的功能，了解其权重分配，设计系统测试和功能测试用例。测试执行的一开始可以是针对部分功能的，之后可以逐步扩展。接着开始采用迭代的过程完成测试任务，即将测试任务划分为多个周期，一开始可以做些关键的功能性测试，可以对代码中的可复用部分（组件，构件）做完整的安全测试，性能测试，压力测试，并发测试，全球化测试等。接着的迭代周期可以做边缘化的功能测试和其他测试，最后的几个迭代应该用于回归测试，和关键的性能和稳定性测试。

        然后策略性的进行自动化测试，设计并开发可以用于日后回归测试（Regression）和用户接收测试（Acceptance Test）的自动化脚本，持续维护与开发这些脚本。自动化测试为团队带来的是长期效益，自动化测试的开发也应该首先选择部分测试对象，例如，API，框架等比较稳定和关键的功能做功能测试的自动化；对产品的性能指标，压力测试也要较早的制定自动化测试的计划。

        最后，要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。积极地参与前期工作，并迅速反馈给设计和开发其静态测试结果。

        而且，要做好敏捷测试，我们需要转变测试等待开发的思想，测试人员需要了解开发，需要读懂代码，才能够更好的帮助开发人员分析和分离复杂问题。有甚者，测试人员可以成为开发人员的后备力量。当团队中需要更多的人撰写代码时，测试人员应该勇当其职。

 

 

 

 

5．2关于自动化测试的讨论

由于作者在实习工作期间，做了大量的自动化测试工作，除了体会到自动化

测试的优势之外，也发现了自动化测试的相对不足之处。如何克服自动化测试的

局限性，提高测试效率和降低测试成本，引发了作者对于敏捷测试中自动化测试

实施成本收益问题的研究。

5．2．1自动化测试与手工测试的有效整合

在实际应用中，并不是每一个项目都适合自动化测试。自动化测试的实施是

有前提的，它更适用于测试周期长，功能较为稳定的测试。软件自动化测试局限

性表现在以下几个方面【19'20】：

11某些情况下不宜使用自动化测试。

软件自动化测试并不能完全代替人的工作，不要期望将所有的测试活动或测

试进行自动化。很少运行的测试、对不稳定软件的测试、通过人的感官来判断的

测试、测试需要大量的人工参与等，这些情况下使用自动化测试将得不偿失。

2)自动化测试的成本可能高于手工测试。

自动化测试的成本大致有以下几个部分组成：自动化测试开发成本、自动化

测试运行成本、自动化测试维护成本和其他相关任务带来的成本。软件的修改带

来测试脚本部分或全部修改，就会增加测试维护的开销。如果测试人员只需要进

行很少量的测试，而且这种测试在以后的重用性很低时，花大量的精力和时间去

进行自动化测试是很不明智的。因为自动化测试的收益一般要在多次重复使用中

才能体现出来。

 

3)自动化测试工具本身并不具有灵活性。

自动化测试工具本身不具有想象力，只是按命令执行。而手工测试中，测试

者可以在测试中判断测试输出是否正确，可以根据具体的情况随时调整测试计划，

处理意外事故，用想象力和创造力改进测试。

4)自动化测试不一定具有高效性。

自动化测试在刚开始执行时，工作效率并不一定高于手工测试，只有当整个

自动化测试系统成熟，且测试工程师熟练掌握测试工具后，工作效率才会随着测

试执行次数的增加而提高。并且，商用软件自动化测试工具是软件产品。作为第

三方的技术产品，如果不具备解决问题的能力和技术支持，或者产品适应环境变

化的能力不强，将使得软件自动化测试工具的作用大大降低。

5)自动化测试对测试质量的依赖性极大。

测试工具只能判断实际结果与期望结果之间的区别。因此，在自动测试中必

需保证期望输出结果的正确性。也就是对测试本身的质量有很高的要求。

6) 自动化测试不能提高测试的有效性。

有效性是指发现软件缺陷的有效性，即能否发现缺陷。在这方面自动化测试

并不会比手工测试更加有效。因为软件测试的首次进行通常是由手工方式完成，

自动化测试应是对程序的“再测试”，也就是回归测试。长期测试的经验统计表明，

再次测试发现的缺陷不会多于首次测试发现的缺陷。

 

乃自动化测试可能会制约软件开发。

软件的改变对自动化测试有较大的影响，因此与手工测试比较，自动化测试

表现得更“脆弱”。由于设置自动测试比手工测试开销大，并且需要进行维护，这

些都可能限制了软件系统的修改或改进。由于经济原因，对自动测试影响较大的

软件修改可能受到限制从而使软件开发受到影响。

通过以上分析可以看出自动化测试并不能完全取代手工测试。认识到软件自

动化测试的这些局限性有助于我们更加合理的对软件测试进行自动化；通过自动

化测试与手工测试的完美结合，充分发挥各自的优势，以达到更好的测试效果。

自动化测试从高层管理的角度来看是一种节约成本，缩减开支的商业决策，

从开发人员的角度来看是一种从设计到开发的技术实现过程，从测试人员的角度

来看是一种自身测试能力和价值提升与展现的机会。如何看待自动化测试并不重

要，重要的是测试的实际效益如何。因此，自动化测试的重点在“测试”，而“自

动化”只是一种手段。自动化测试的实施是一个更加严谨而且具有很高技术性和

实践性的活动。而手工测试只要有付出，总会有收获，比自动化测试更可靠。只

有将手工测试和自动化测试有效整合，才能发挥出测试的整体效果。

自动化测试通常进行冒烟测试和回归测试，一般选取核一1、5'功能进行测试。因为核心功能一般开发稳定下来较早，而且又经过多轮测试，所以这部分功能测试

很少有机会发现新的bug通常以回归bug为主。回归bug指的是因开发人员修复

一个bug而产生的另一个新的bug，回归bug的存在增加了产品的不稳定性，会降

低客户对产品的信任度。但是仍然执行这部分自动化测试的目的是为了确保这些

核心功能没有bug。根据作者在工作中的统计，项目前期自动化的参与率为10％，

稳定期参与率为50％，但是总体缺陷发现率不超过10％。在测试效率方面，由于

部分自动化可以安排在非工作时间，所以可以明显提高测试效率。

自动化测试的意义在于保证产品的稳定性，而手工测试则在产品稳定性满足的基础上，负责验证容错性、安全性等非核心功能，两者各司其职，互补长短。

 

 

5．2．2自动化测试成本效益分析

自动化测试的出现，很重要的一点原因就是为了帮助手工测试解决繁重的工

作压力，自动化测试实施中所作的任何工作的目的之一都是为了最终能够节省手

工测试的成本。自动化测试是为了节省成本的这一指导思想应该一直贯穿在自动

化测试设计到实施的过程中。最后评价自动化测试是否成功的标准也是看其最终

能够节省软件测试的人力成本或时间成本的能力。

在市场经济的今天，做任何事情都讲究经济效益。效益就是投入产出比，要

估算自动化测试的效益，首先要做的就是找出自动化测试的投入成本和收益。

自动化测试实施的成本可用计算公式表示为：

自动化实施成本=前期的开发成本+后期的维护成本

后期的维护成本在4．2．1章节已经提过，前期的成本主要包括人力、时间和金

钱的成本。

对于这个成本计算公式，即使是量化，也只是一个数字，无法判定这样的一

个数字在什么范围内是合适的：对于不同规模的项目，也不具有可比性。因此需

要寻找一个更为合适的方式来进行判断。

 

在自动化测试脚本开发完毕后，其运行次数越多，代替手工的次数也越多，

节省手工测试的成本也就越多。如果用自动化测试的运行次数来度量自动化测试

的收益，即

自动化测试收益=自动化测试运行次数

那么，在此基础上，如果自动化测试脚本可以保持长时间稳定的运行，或者

是基本被频繁执行，都可以增加运行的次数。这样就引出了自动化测试成本收益

比计算公式【2l】：

P=k*n／(c l+c2)

61其中，k表示手工执行自动化测试案例所花费的时间成本，n表示自动化案例

执行的次数，cl表示自动化测试前期花费成本，c2表示自动化测试后期花费成本。

显然，要获得最大的自动化测试收益，就要尽可能降低自动化测试的成本。

构建自动化测试目标时，需要考虑自动化测试实施的两个关键问题：一是决

定自动化测试实施的最佳时间；二是选取有效地自动化测试案例。

软件测试应该尽可能早的开始，但这种做法并不适用于UI自动化测试。业界

里流传着这样一句话：“如果自动化测试失败了，那么很有可能是在错误的时间实

施了自动化测试”。

．但是作者的测试实践是基于UI的自动化测试，而且客户方要求自动化测试从

项目开始即要介入。对于这样相对冲突的测试要求与实施前提，测试人员根据以

下原则择机实施自动化测试：

1)软件界面趋于稳定，更确切地说是，被自动化测试的那部分界面对象属性趋于

稳定。

2)在晃面变化已经不可避免的情况下，如果可以预知变化的规律，也可以实施自

动化测试。

在确定自动化测试可以介入的时机后，选取有效的自动化测试案例则对提高

自动化测试效益有更大的帮助。根据自动化测试成本收益比计算公式可以分析出

测试案例应该具有以下两个特征：

1)测试对象是被测软件系统中比较稳定的功能模块，这样可以减少自动化测试的

维护成本。

2)测试案例应该是执行比较频繁的，这样会增大自动化测试的收益。

下面基于一个测试实践，来说明自动化测试成本效益的增进。

基于上述原则，自动化测试人员在与手动测试人员沟通后，在实现的功能点

中选取了功能表现比较稳定的，且属于BAT的测试用例施行自动化测试。这里以

Now playing Status为例。

Now playing Status是Music player播放模式在Shanno widget里的映射，由于

Music player是Nokia手机已有的应用程序，所以Now playing Status在项目的初始

阶段就有了比较稳定的功能表现，虽然UI有时会随着整体功能的不断实现发生变

化。但是，其基本符合了较少自动化测试维护成本的选择原则。

另一方面，Now playing Status的判断属于BAT测试用例的一部分。由于测试

版本每一天或两天就会变更，所以进行版本可接受性测试的测试用例执行的异常

频繁的，这一点也符合增加自动化测试收益的原则。

纵然测试用例的选择是合理的，但是变化也是不可避免的，因此，脚本维护

也是不可避免的。在这种情况下，为了降低测试成本，测试人员利用敏捷测试的

 

 

参考文献

参考文献

[1】蔡军红．软件质量与测试(一)．软件世界．2002

【2】崔启亮，胡一鸣．国际化软件测试．北京．电子工业出版社．2006

【3】Ron Patton．软件测试．北京．机械工业出版社．2003

【4】郑人杰．计算机软件测试技术．北京．清华大学出版社．1 992

【5】王璇．敏捷测试理论与实践．软件导刊．2009年1月第8卷第1期

【6】6 Jim HighsmitE敏捷软件开发生态系统．北京．机械工业出版社．2004

【7】http：／／www．ibm．corn／deveioperworks／cn／linux／l-tdd／index．html

【8】BruceA Posey．Just Enough Software TestAutomation．北京．机械工业出版社．2003

【9】王晓虹．软件工程中的自动化测试技术．理工科研．2009年9月中旬刊

【10】WinRunner TSLReference Guide，Version 7．6．Mercury Interactive Corporation．2003

【1l】张逸．在Serum中实施敏捷建模．重庆文理学院学报(自然科学版)．2009年10月第28卷

第5期

【12】Gerald M Weinberg．完美软件——对软件测试的各种幻想．北京．电子工业出版社．2009

【13】Gopalaswamy Ramesh．全球化软件项目管理．北京．机械工业出版社．2003

[14】ElfriedeDustin．软件自动化测试：引入、管理与实施．北京．电子工业出版社．2003

【1 5】http：／／www．ibm．com／developerworks／cn／rational／r-en-agiletestin92

[1 6】https：／／cwiki．nokia．com／ASTEWiki／KeywordDocumentation

【17】孙惠杰，杨晓红．软件测试的自动化．哈尔滨师范大学自然科学学报．2003年第19卷第5

期

【18】文昌辞，王昭顺．软件测试自动化静态分析研究．计算机工程与设计．2005年4月第26卷

第4期

【19】路晓丽，葛玮，龚晓庆．软件测试技术．北京．机械工业出版社．2007

【20】朱少民．软件测试方法和技术．北京．清华大学出版社．2005

【2l】柳胜．软件自动化测试框架设计与实践．北氨人民邮电出版社．2009