自动化测试与自动化测试生命周期

1.1 自动化测试的定义及概述
1.1.1 软件测试的定义与分类

        软件测试[2]&＃xff0c;就是在软件投入运行前&＃xff0c;对软件需求分析、设计规格说明和编码的最终复查&＃xff0c;是软件质量保证的关键步骤。

        定义1&＃xff1a;软件测试是为了发现错误而在规定的条件下执行程序的过程。

        定义2&＃xff1a;软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例&＃xff08;即输入数据及其预期的输出结果&＃xff09;&＃xff0c;并利用这些测试用例去运行程序&＃xff0c;以发现程序错误的过程。

        由软件测试的定义&＃xff0c;不难看出测试的目的[13]&＃xff0c;是寻找错误&＃xff0c;并且是尽最大可能找出最多的错误。著名的Grenford J. Myers在《The Art of Software Testing》一书中提出以下观点&＃xff1a;

        测试是程序的执行过程&＃xff0c;目的在于发现错误&＃xff1b; 
        一个好的测试用例在于发现至今未发现的错误&＃xff1b; 
        一个成功的测试是发现了至今未发现的错误的测试。 
        软件测试&＃xff0c;按照不同的分类原则有不同的分类结果&＃xff1a;

&＃xff08;1&＃xff09; 按测试用例设计方法分&＃xff0c;软件测试分为&＃xff1a;黑盒测试&＃xff0c;白盒测试和灰盒测试。

        黑盒测试&＃xff08;Black-box testing&＃xff09;&＃xff0c;又称为功能测试或数据驱动测试&＃xff0c;把系统看成一个黑盒子&＃xff0c;不考虑程序的内在逻辑&＃xff0c;只根据需求规格说明书的要求来检查程序的功能是否符合它的功能说明。

        白盒测试&＃xff08;White-box testing&＃xff09;&＃xff0c;又称为结构测试或逻辑驱动测试&＃xff0c;允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例&＃xff0c;对程序的逻辑路径进行测试。

        灰盒测试&＃xff08;Gray-box testing&＃xff09;&＃xff0c;是融合了白盒和黑盒测试的一种测试策略&＃xff0c;又称混合测试法

        本文主要涉及的是根据需求规格说明书进行的黒盒测试。

&＃xff08;2&＃xff09; 按测试策略和过程分&＃xff0c;软件测试分为&＃xff1a;单元测试、集成测试&＃xff08;组装测试&＃xff09;、确认测试、系统测试以及回归测试[2]。

        单元测试&＃xff08;Unit Testing&＃xff09;&＃xff0c;又称模块测试&＃xff0c;是最小单位测试&＃xff0c;是在系统开发过程中要进行的最低级别的测试活动。单元测试活动中对源代码实现的每个程序单元进行测试&＃xff0c;检查各个程序模块是否正确地实现了规定的功能。其目的在于发现各模块内部可能存在的各种错误&＃xff0c;单元测试需要从程序的内部结构出发设计测试用例&＃xff0c;必要的时候要制作驱动模块和桩模块。测试工程师要依据详细设计说明书和源程序清单&＃xff0c;了解模块的I/O条件和逻辑结构。主要采用白盒测试的测试用例&＃xff0c;辅之以黒盒测试的测试用例。

        集成测试&＃xff08;Integration Testing&＃xff09;&＃xff0c;也称为组装测试&＃xff0c;是在单元测试的基础上&＃xff0c;将所有模块按照结构设计要求组装成为一个可运行的系统。集成测试对应于软件概要设计阶段的测试&＃xff0c;它要求尽可能地暴露程序单元或模块间接口和软件设计上的错误和缺陷&＃xff0c;确保程序单元或模块间接口正确和软件结构合理。集成测试按系统集成方式&＃xff0c;可分为非增量式和增量式两种。其中增量式集成方式可分为自定向下集成、自底向上集成和混合增量式集成。集成测试主要依据概要设计说明书&＃xff0c;主要采用黒盒测试&＃xff0c;辅之以白盒测试方法。

        系统测试&＃xff08;System Testing&＃xff09;&＃xff0c;是基于一定的计算机硬件环境&＃xff0c;对整个软件进行的一系列测试&＃xff1b;是将已经通过集成测试的软件与具有一定代表性的计算机实用环境相结合&＃xff0c;根据软件项目系统级的有关文档&＃xff0c;检查软件与系统定义、与需求的符合性&＃xff0c;检验并确认软件在整个系统中的功能、性能和正确性。完成集成测试后的软件系统&＃xff0c;必须与系统的其他元素相结合&＃xff0c;进行系统级的确认和验证测试。

        所谓确认&＃xff08;validation&＃xff09;&＃xff0c;是一系列的活动和过程&＃xff0c;其目的是想证实在给定的外部环境下软件的逻辑正确性。分为静态确认和动态确认。

        所谓验证&＃xff08;verification&＃xff09;&＃xff0c;是试图证明在软件生成周期各个阶段以及阶段间的逻辑协调性、完备性和正确性。

        系统测试主要采用黒盒测试方法&＃xff0c;对于具体的项目&＃xff0c;这个阶段的测试中非常重要的一点是建立满足具体软件项目的仿真环境。

        验收测试&＃xff08;Acceptance Testing&＃xff09;&＃xff0c;是以用户为主的测试。一般&＃xff0c;在软件系统测试结束以及软件配置审查之后开始&＃xff0c;验收测试应由用户、测试人员、软件开发人员和质量保证人员一起参与&＃xff0c;验证软件系统的功能和性能及其它特性是否与用户的要求一致。

        回归测试&＃xff08;Regression Testing&＃xff09;不是一个特定的测试级别&＃xff0c;只要对软件代码有修改&＃xff0c;不论是修改错误还是增加新的功能或是提高性能&＃xff0c;原则上都要进行回归测试&＃xff0c;以保证对代码修改的正确性&＃xff0c;且不会对其余部分带来负面影响。本文中主要论述的是在集成测试和系统测试阶段遇到代码变动所进行的重复测试。回归测试可以通过重新执行所有的测试用例的一个子集进行&＃xff0c;回归测试集包括三种类型的测试用例&＃xff1a;

        能够测试软件的所有功能的代表性测试用例。 
        专门针对可能会被修改影响的软件功能的附加测试。 
        针对修改过的软件成分的测试。 
        回归测试可以有选择地重复执行集成和系统测试的测试用例&＃xff0c;回归测试变动比较小&＃xff0c;同时测试所基于的实际硬件环境相对比较稳定。但回归测试要频繁地重复运行&＃xff0c;需要的工作量很大&＃xff0c;所以&＃xff0c;回归测试最值得自动化。自动测试便于回归测试以非常高效的方式进行。

&＃xff08;3&＃xff09; 按测试内容分&＃xff0c;接口测试、路径测试、功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试。

        本文的测试系统主要针对集成测试和系统测试阶段&＃xff0c;在这些阶段测试的内容主要是功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试。

1.1.2 自动测试的概述

        自动化测试是借助于测试工具、测试规范&＃xff0c;从而局部或全部代替人工进行测试及提高测试效率的过程。

        自动测试相对于手工测试而言&＃xff0c;其主要进步在于自动测试工具的引入。自动测试的一般定义[1]为&＃xff1a;各种测试活动的管理与实施&＃xff0c;包括测试脚本的开发与执行&＃xff0c;以便使用某种自动测试工具来验证测试需求。测试活动的自动化在许多情况下可以获得最大的实用价值&＃xff0c;尤其在自动测试的测试用例开发和组装阶段&＃xff0c;测试脚本被重复调用&＃xff0c;可重用脚本可能运行很多次。因此&＃xff0c;采用自动测试可以获得很高的回报。

        系统测试级上的回归测试是有效应用自动测试的情况。回归测试设法验证改进后的系统提供的功能是否按照规定执行&＃xff0c;系统在运行中没有出现非预期变化。自动测试几乎可以不加改动地重用先前的测试用例和测试脚本&＃xff0c;以非常有效的方式执行回归测试。

自动测试具有以下优点[4]&＃xff1a;

        &＃xff08;1&＃xff09; 能执行更多更频繁的测试&＃xff0c;使某些测试任务的执行比手动方式更高效&＃xff0c;可以更快地将软件推向市场&＃xff1b;

        &＃xff08;2&＃xff09; 能执行一些手动测试困难或不可能做的测试&＃xff1b;

        &＃xff08;3&＃xff09; 更好地利用资源&＃xff0c;利用整夜或周末空闲的设备执行自动化测试&＃xff1b;

        &＃xff08;4&＃xff09; 将烦琐的任务自动化&＃xff0c;让测试人员投入更多的精力设计出更多更好的测试用例&＃xff0c;提高测试准确性和测试人员的积极性&＃xff1b;

        &＃xff08;5&＃xff09; 自动测试具有一致性和可重复性的特点&＃xff0c;而且测试更客观&＃xff0c;提高了软件的信任度。

但自动化测试仍然存在着一定的局限性[15]&＃xff1a;

        &＃xff08;1&＃xff09; 不能取代手工测试&＃xff0c;不可能自动化所有的测试。如测试只是偶尔执行&＃xff0c;或待测系统经常变动、不稳定&＃xff0c;测试需要大量的人工参与时&＃xff0c;就不适宜采用自动测试。

        &＃xff08;2&＃xff09; 自动测试工具本身不具有想象力&＃xff0c;只是按命令执行。而手工测试时测试执行者可以在测试中判断测试输出是否正确&＃xff0c;以及改进测试&＃xff0c;还可以处理意外事件。

        &＃xff08;3&＃xff09; 自动测试对测试质量的依赖性较大&＃xff0c;在确保测试质量的前提下&＃xff0c;实施自动化测试才有意义。

        &＃xff08;4&＃xff09; 自动测试在刚开始执行时&＃xff0c;工作效率并不一定高于手动测试&＃xff0c;只有当整个自动测试系统成熟&＃xff0c;且测试工程师熟练掌握测试工具后&＃xff0c;工作效率才会随着测试执行次数的增加而提高。

        &＃xff08;5&＃xff09; 自动测试的成本可能高于手工测试。自动测试的成本大致有以下几个部分组成&＃xff1a;自动测试开发成本、自动测试运行成本、自动测试维护成本和其他相关任务带来的成本。软件的修改带来测试脚本部分或全部修改&＃xff0c;就会增加测试维护的开销。

1.1.3 测试与自动化测试概念的区别

        测试[5]是通过执行测试用例实现&＃xff0c;描述测试用例质量有四个特征&＃xff1a;有效性、修改性、可仿效性和经济性。有效性指是否能发现缺陷、或至少可能发现缺陷&＃xff1b;可仿效性指测试用例是否能测试多项内容&＃xff0c;以减少测试用例的数量&＃xff1b;经济性指测试用例的执行、分析和调试是否经济&＃xff1b;修改性指每次软件修改后对测试用例的维护成本。通常要平衡这四个方面。

        自动测试技术&＃xff0c;与测试技术存在着很大区别。自动化的程度与测试的质量是独立的。无论自动执行还是手动执行测试都不影响测试的有效性和仿效性。测试本身的有效性直接导致测试的成败&＃xff0c;而自动测试只对测试的经济性和修改性有影响&＃xff0c;自动测试通常要比手动测试经济得多&＃xff0c;自动测试的方法越好&＃xff0c;长期使用获得的收益就越大。测试质量取决于测试执行者实现测试质量的技术&＃xff1b;而自动化质量取决于测试自动化者的自动化技术。

        图2-1说明了测试与自动化测试在测试用例的四个质量特征上的区别。

图2-1 测试用例质量Keviat图

1.2 自动化测试生命周期的概述
1.2.1 自动化测试过程

        提到测试&＃xff0c;一般都认为是使用测试用例进行测试&＃xff0c;而事实上&＃xff0c;这只是完整测试过程中的一个步骤&＃xff0c;测试活动其实是一个过程&＃xff0c;如图2-2所示&＃xff0c;是一系列的步骤&＃xff0c;通过这些步骤实现测试活动&＃xff0c;导致测试的执行和测试产物的产生。测试过程有开发者、测试设计工程师和测试工程师的共同参与。包括了测试计划、设计、开发、执行和评估这几个步骤[1]。各个步骤分别又有不同的自动化工具提供支持。

图2-2 自动化测试过程

&＃xff08;1&＃xff09;自动测试的计划

        理想情况下&＃xff0c;测试始于测试目标和测试策略的建立&＃xff0c;测试策略应满足测试目标的要求。管理层的测试计划包括评估完成所有测试活动的时间&＃xff0c;测试活动安排及资源分配&＃xff0c;控制测试过程以及跟踪整个测试过程所需采取的活动&＃xff0c;这些高层次活动应该在项目开始前就实施&＃xff0c;并贯穿项目的整个开发过程。

        测试计划是测试过程中最重要的活动&＃xff0c;包括风险评估、鉴别和确定测试需求的优先级&＃xff0c;估计测试资源的需求量&＃xff0c;开发测试项目计划以及给测试小组成员分配测试职责等。

        测试计划的目的是收集从需求/设计文档中得到的信息&＃xff0c;并将这些信息表现在测试需求中&＃xff0c;而测试需求将在测试场景中得到实现。测试场景是测试计划的一部分&＃xff0c;它直接提供给测试条件、测试用例、测试数据的开发。我们可以视测试计划为从软件需求中抽出来工作文档&＃xff0c;并和测试需求和测试结果相联系。测试计划还会随着软件需求的更新而更新&＃xff0c;是动态的文档。

        这个阶段主要是测试设计工程师根据开发者提供的功能需求&＃xff0c;高级设计文档及详细设计文档&＃xff0c;使用如Rational RequisitePro这样的工具得到测试需求&＃xff0c;测试计划&＃xff0c;以及测试用例的Excel形式的列表。

&＃xff08;2&＃xff09;自动测试的设计

        测试设计包括经过测试需求分析后&＃xff0c;定义测试活动模型&＃xff08;确定测试所使用的测试技术&＃xff09;&＃xff0c;定义测试体系结构&＃xff0c;完成测试程序的定义与映射&＃xff08;建立测试程序与测试需求之间的联系&＃xff09;&＃xff0c;自动/手动测试映射&＃xff08;确定哪些测试使用自动测试&＃xff09;&＃xff0c;以及测试数据映射。

        需要指出的是确定自动/手动测试映射&＃xff0c;对于自动测试相当重要&＃xff0c;因为并不是所有的测试都适合自动化。作者认为&＃xff0c;一般以下几类情况适合进行自动测试&＃xff1a;

        当前的测试项目比较大&＃xff0c;且在今后项目中重复测试的概率比较高&＃xff1b; 
        测试本身的执行简单、机械&＃xff0c;而测试所需硬件环境则相对来说比较稳定&＃xff1b; 
        测试难以通过手动方式实现&＃xff0c;例如部分负载/压力测试&＃xff1b; 
        测试基本不需要人工参与&＃xff0c;且重复性较高&＃xff0c;如系统的配置测试。 
        这个阶段主要参与者有测试设计工程师&＃xff0c;其任务是根据测试需求&＃xff0c;测试计划文档&＃xff0c;测试用例列表等&＃xff0c;使用工具如Excel来构建电子数据表&＃xff0c;包括测试条件电子数据表&＃xff0c;测试数据电子数据表&＃xff0c;有关各种映射关系定义的表格以及详细测试电子数据表。

&＃xff08;3&＃xff09;自动测试的开发

        测试开发包括创建具有可维护性、可重用性、简单性、健壮性的测试程序。同时要注意确保自动测试开发的结构化和一致性。

        这个阶段由测试设计工程师在上一阶段的基础上&＃xff0c;根据详细测试表、映射关系定义表等电子数据表格&＃xff0c;可以使用Robot、WinRunner等工具&＃xff0c;生成手工测试脚本&＃xff0c;自动化测试脚本。尤其是自动测试脚本的开发&＃xff0c;有线性脚本、结构化脚本、共享脚本、数据驱动脚本和关键字驱动脚本这几种脚本技术。各种脚本技术将在后面章节详细论述。

&＃xff08;4&＃xff09;自动测试的执行与评估

        随着测试计划的建立和测试环境的搭建完毕&＃xff0c;按照测试程序进度安排执行测试&＃xff0c;可以通过手动或自动或半手动半自动方式执行&＃xff0c;它们各自可以发现不同类型的错误。测试执行结束后&＃xff0c;需要对测试结果进行比较、分析以及结果验证&＃xff0c;得出测试报告&＃xff08;包括总结性报告和详细报告&＃xff09;。其中总结性报告是提供给被测方中高层管理者及客户的&＃xff0c;而详细报告&＃xff0c;寄过编辑整理&＃xff0c;作为反馈文档提供给开发小组成员。执行及评价过程如图2-3所示。

                                                                           图2-3 测试执行及评估流程

        这个阶段由测试设计工程师与测试工程师共同参与。构建好的待测系统上使用测试用例脚本执行测试数据&＃xff0c;其中测试数据是被设计用于测试该应用程序各种特征的。可以使用Excel、Word、ClearQuest等工具&＃xff0c;得到测试后的测试结果日志、测试度量、缺陷报告及测试评估总结等。

1.2.2 自动化测试与自动化测试过程的区别

        如果需要的是一个完全的自动化的测试过程&＃xff0c;而不仅仅是一些自动化测试&＃xff0c;那么围绕测试执行过程的前处理和后处理任务就必须自动化&＃xff0c;如图2-4。前处理&＃xff0c;包括所有与建立和恢复那些与测试先决条件相关的工作。后处理&＃xff0c;包括对测试结果进行评估&＃xff0c;保存工具日志文件&＃xff0c;清除测试环境等工作。对测试过程进行自动化&＃xff0c;更有利于减轻工作量。

图2-4 自动化测试与自动化测试过程的区别

1.2.3 自动化测试生命周期方法学

        自动化测试生命周期方法学&＃xff08;Automated Test Lifecycle Methodology&＃xff0c;ATLM&＃xff09;[1]是一个旨在确保自动化测试成功实施的结构化的方法学&＃xff0c;反映了现代的快速应用开发&＃xff08;Rapid Application Development, RAD&＃xff09;工作的益处。它是一个多阶段的过程&＃xff0c;该方法学由六个部分组成&＃xff1a;自动测试决定&＃xff0c;自动测试工具获取&＃xff0c;自动测试引入测试过程&＃xff0c;自动测试计划、设计与开发&＃xff0c;测试的执行与管理&＃xff0c;测试的评审与评估。如图2-5所示。

        在2.2.1节中论述的自动化测试过程是自动化测试生命周期的一个重要组成部分。而ATLM则从方法论的角度&＃xff0c;更全面更系统地论述了整个自动化测试项目。

图2-5 自动测试生命周期方法学

&＃xff08;1&＃xff09;自动测试决定

        正如在2.1.2节中论述的&＃xff0c;自动化测试确实存在许多优点&＃xff0c;但并不是任何测试都能自动化&＃xff0c;它也存在着局限性。克服不正确的自动测试期望&＃xff0c;必须针对测试项目的具体情况&＃xff0c;确定什么时候&＃xff0c;对什么进行自动化[14]。如果对不适合自动化的测试&＃xff0c;实施自动化&＃xff0c;不但耗费了大量资源&＃xff0c;而且得不到相应的回报。要记住&＃xff1a;自动测试不可能完全替代手动测试。

        作者认为&＃xff0c;在针对测试项目的整个周期时间、资源分配情况及资金安排情况的综合分析后&＃xff0c;确定什么时候&＃xff0c;对什么进行自动化。

&＃xff08;2&＃xff09;测试工具获取

        实现自动化测试&＃xff0c;测试工具的选择很重要&＃xff0c;而目前还没有一个单一的测试工具能用来完成所有的测试需求。测试工具品种不一&＃xff0c;功能性能各异。对自动测试工具的适当选择&＃xff0c;很大程度上决定了该工具能否获得相应的投资回报。

        作者认为&＃xff0c;要对市场上各种测试工具进行广泛地调查比较。在选择时&＃xff0c;建议考虑以下几个方面&＃xff1a;该工具引入后改进测试的效果&＃xff0c;能实现何种测试需求&＃xff1b;测试工具与待测软件/系统的互操作性&＃xff1b;工具的成本估算&＃xff1b;引入工具所需的额外时间&＃xff1b;工具所需的专业知识及培训费用等等。有时&＃xff0c;可以选择开放性开发的测试工具。

&＃xff08;3&＃xff09;自动测试引入阶段

        首先需要测试过程分析&＃xff0c;从而确定适用的技术环境以及自动工具可支持的各种测试。其次&＃xff0c;将潜在的测试工具和实用程序映射到测试需求中&＃xff0c;验证测试工具是否与应用及环境兼容。

        作者认为&＃xff0c;使测试工具得到最大回报的方法&＃xff0c;就是在测试中最大限度地发挥它的功能。对于获得的测试工具&＃xff0c;要真正引入到测试项目中&＃xff0c;与待测系统实现互操作&＃xff0c;可以以某些测试工具为基础进行二次开发&＃xff0c;使得测试工具更专业化&＃xff0c;更适合测试工程师操作。

&＃xff08;4&＃xff09;自动化测试过程

        自动化测试过程包括&＃xff1a;测试计划、设计及开发&＃xff0c;测试执行与管理&＃xff0c;测试评审与评价&＃xff0c;已经在2.2.1节中具体论述过了。

1.3 自动测试生命周期方法学的应用
        自动测试生命周期方法学作为一种结构化的方法学&＃xff0c;本课题以之为指导&＃xff0c;进行自动化测试系统的设计与实现。

        本文第三章将论述根据iSAM系统的测试需求作出自动测试的决定&＃xff0c;以及自动测试系统建模的方法。

        第四、五章将详细介绍自动化测试系统的框架和实现&＃xff0c;以及为此系统设计和实现的自动工具。这正对应于自动测试生命周期第二阶段自动测试工具的获取和第三阶段自动测试引入到过程。

        第六章将详细介绍自动测试过程中的核心——自动测试用例的设计与实现&＃xff0c;这部分是以自动测试生命周期的第四阶段为指导的。

        第七章主要包括了测试的执行、测试结果的分析及评价&＃xff0c;这章与自动测试生命周期中的第五、六阶段相对应。

        最后一章是对本自动测试系统的总结。