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

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

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

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

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

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

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

（1） 按测试用例设计方法分，软件测试分为：黑盒测试，白盒测试和灰盒测试。

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

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

        灰盒测试（Gray-box testing），是融合了白盒和黑盒测试的一种测试策略，又称混合测试法

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

（2） 按测试策略和过程分，软件测试分为：单元测试、集成测试（组装测试）、确认测试、系统测试以及回归测试[2]。

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

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

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

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

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

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

        验收测试（Aclearcase/" target="_blank" >cceptance Testing），是以用户为主的测试。一般，在软件系统测试结束以及软件配置审查之后开始，验收测试应由用户、测试人员、软件开发人员和质量保证人员一起参与，验证软件系统的功能和性能及其它特性是否与用户的要求一致。

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

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

（3） 按测试内容分，接口测试、路径测试、功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试。

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

1.1.2 自动测试的概述

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

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

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

原文转自：http://www.ltesting.net