自动测试技术

一、自动测试技术简介

 

1. 自动测试的前提条件

 　　 自动测试是把以人为驱动的测试行为转化为机器执行的一种过程。实施自动测试之前需要对软件开发过程进行分析，以观察其是否适合使用自动测试。自动测试通常需要满足以下条件：

 　　1) 软件需求变动不频繁

    　　测试脚本的稳定性决定了自动测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求更新测试用例以及相关的测试脚本，较大的变动势必会增加维护脚本的成本，导致自动测试失败。一般情况下，对于需求分析中相对稳定的模块进行自动测试，而变动较大的模块仍采用手工测试。

 

　　2) 项目周期足够长

　　    自动测试需求的确定、自动测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成。这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。 

 

　　3) 自动测试脚本可重复使用

　　    在手工测试无法完成，需要投入大量时间成本与人力成本时，可考虑引入自动测试。

 

2. 自动测试过程

 　　自动测试与软件开发过程从本质上来讲是一样的。自动测试过程可概括为利用自动化测试工具，经过对测试需求的分析，设计出自动测试用例，搭建自动测试的框架，设计与编写自动测试脚本，测试脚本的正确性，完成该套测试脚本。具体来讲可分为如下步骤：

 

　　1) 自动测试需求分析

 　　当测试项目满足了自动化的前提条件，并确定在该项目中需要使用自动测试时，就可进行自动测试需求分析。此过程需要确定自动测试的范围以及相应的测试用例、测试数据，并形成详细的文档，以便于自动测试框架的建立。

 

　　2) 自动测试框架的搭建

　　自动测试框架与软件架构一样，定义了在使用该套脚本时需要调用哪些文件、结构，调用的过程，以及文件结构如何划分。搭建自动测试框架时需要将如下典型要素考虑进去。

　　    (1) 公用的对象。不同的测试用例会有一些相同的对象被重复使用，比如窗口、按钮、页面等。这些公用的对象可被抽取出来，在编写脚本时调用。当这些对象的属性因为需求的变更而改变时，只需要修改该对象属性即可，无需修改所有相关的测试脚本。

　　    (2) 公用的环境。测试用例使用相同的测试环境，将该测试环境独立封装，在各个测试用例中灵活调用，增强脚本的可维护性。

　　    (3) 公用的方法。编写测试工具经常使用的方法，方便脚本的调用。

　　    (4) 测试数据。一个测试用例往往需要执行多个测试数据，可将测试数据放在独立的文件中，由测试脚本执行到该用例时自动读取测试数据文件，以达到数据覆盖的目的。

 

　　3) 自动测试脚本的编写

 　　自动测试脚本的编写过程是具体的测试用例的脚本转换。建议以录制为参考，以编写脚本为主要行为，避免录制脚本带来的冗余、公用元素的不可调用、脚本的调试复杂等问题。

 

　　4) 脚本的测试与试运行

 　　事实上，测试用例形成的脚本通过测试后，并不意味着执行多个甚至所有的测试用例就不会出错。输入数据以及测试环境的改变，都会导致测试结果受到影响甚至失败。因此，脚本的测试与试运行极为重要，需要检查多个脚本不能按计划执行的原因，并保证其得到修复。

 

 

 

二、自动测试发展历程

如图6.1所示，自动测试发展大致经历了如下四个阶段。

图6.1  自动测试发展阶段

 

 

         第一阶段：机械方式实现人工重复操作。

    　　最初，自动测试主要研究如何采用自动方法来实现和替代人工测试中的繁琐和机械重复的工作。通过工人设计测试数据，对程序进行动态执行检测，脚本驱动自动执行。此时的自动测试活动只是软件测试过程的偶然行为，可在一定程度上提高效率，简化测试人员工作，但对整体的测试过程并无太大改进。

 

         第二阶段：统计分析的自动测试。

    　　只有自动测试结果具有可靠性，其使用才具有实际的意义。针对不同的测试准则和测试策略，指导测试的自动化过程以及对测试的结果进行评估。

 

　　 第三阶段：面向目标的自动测试技术。

    　　软件测试并不是机械和随机地发现错误，而是带有很强的目的性。进化计算和人工智能等技术，以及各种高性能的算法被引入自动测试技术。

 

　　 第四阶段：智能应用的自动测试技术。

    　　能力成熟度模型被引入软件工程，测试业界产生对应的测试成熟度模型。不同的自动测试等级成为测试好坏的一个衡量依据。

 

 

三、测试成熟度模型

 

1. 初始级

　　TMM初始级软件测试过程的特点是测试过程无序，有时甚至是混乱的，几乎没有妥善定义的。初始级中软件的测试与调试常常被混为一谈，软件开发过程中缺乏测试资源、工具以及训练有素的测试人员。初始级的软件测试过程没有定义成熟度目标。

 

2. 定义级

　　TMM的定义级中，测试已具备基本的测试技术和方法，软件的测试与调试已经明确地被区分开。这时，测试被定义为软件生命周期中的一个阶段，它紧随编码阶段之后，由于测试计划往往在编码之后才得以制订，这显然有背于软件工程的要求。

　　 TMM的定义级中需实现3个成熟度目标：制订测试与调试目标，启动测试计划过程，制度化基本的测试技术和方法。

 

　　1) 制订测试与调试目标

　　软件组织必须区分软件开发的测试过程与调试过程，识别各自的目标、任务和活动。正确区分这两个过程是提高软件组织测试能力的基础。与调试工作不同，测试工作是一种有计划的活动，可以进行管理和控制。这种管理和控制活动需要制订相应的策略和政策，以确定和协调这两个过程。

　　制订测试与调试目标包含5个子成熟度目标：

　　(1) 分别形成测试组织和调试组织，并有经费支持。

　　(2) 规划并记录测试目标。

　　(3) 规划并记录调试目标。

　　(4) 将测试和调试目标形成文档，并分发至项目涉及的所有管理人员和开发人员。

　　(5) 将测试目标反映在测试计划中。

 

　　2) 启动测试计划过程

        测试计划作为过程可重复、可定义和可管理的基础，包括测试目的、风险分析、测试策略以及测试设计规格说明和测试用例。此外，测试计划还应说明如何分配测试资源，如何划分单元测试、集成测试、系统测试和验收测试。

        启动测试计划过程包含5个子目标：

　　(1) 建立组织内的测试计划组织并予以经费支持。

　　(2) 建立组织内的测试计划政策框架并予以管理上的支持。

　　(3) 开发测试计划模板并分发至项目的管理者和开发者。

　　(4) 建立一种机制，使用户需求成为测试计划的依据之一。

　　(5) 评价、推荐和获得基本的计划工具并从管理上支持工具的使用。

 

　　3) 制度化基本的测试技术和方法

　　改进测试过程能力，组织中应用基本的测试技术和方法，并说明何时和怎样使用这些技术、方法和支持工具。

        基本测试技术和方法制度化有如下2个子目标：

　　(1) 在组织范围内成立测试技术组，研究、评价和推荐基本的测试技术和测试方法，推荐支持这些技术与方法的基本工具。

　　(2) 制订管理方针以保证在全组织范围内一致使用所推荐的技术和方法。

 

 

3. 集成级

　　TMM的集成级中，测试不再是编码阶段之后的阶段，已被扩展成与软件生命周期融为一体的一组活动。 测试活动遵循V字模型。测试人员在需求分析阶段便开始着手制订测试计划，根据用户需求建立测试目标和设计测试用例。软件测试组织提供测试技术培训，测试工具支持关键测试活动。但是，集成级没有正式的评审程序，没有建立质量过程和产品属性的测试度量。

　　 集成级要实现如下4个成熟度目标：建立软件测试组织，制订技术培训计划，测试软件生命周期，控制和监视测试过程。

 

　　 1) 建立软件测试组织

　　软件测试过程对软件产品质量有直接影响。测试往往是在时间紧、压力大的情况下完成一系列复杂活动，测试组完成与测试有关的活动，包括制订测试计划，实施测试执行，记录测试结果，制订与测试有关的标准和测试度量，建立测试数据库，测试重用，测试跟踪以及测试评价等。

　　建立软件测试组织要实现4个子目标：

　　(1) 建立全组织范围内的测试组，并得到上级管理层的领导和各方面的支持，包括经费支持。

　　(2) 定义测试组的作用和职责。

　　(3) 由训练有素的人员组成测试组。

　　(4) 建立与用户或客户的联系，收集他们对测试的需求和建议。　

 

　　 2) 制订技术培训计划

　　为高效率地完成好测试工作，测试人员必须经过适当的培训。　　制订技术培训规划有3个子目标：

　　(1) 制订组织的培训计划，并在管理上提供包括经费在内的支持。

　　(2) 制订培训目标和具体的培训计划。

　　(3) 成立培训组，配备相应的工具、设备和教材。

 

　　 3) 测试软件生命周期

　　提高测试成熟度和改善软件产品质量都要求将测试工作与软件生命周期中的各个阶段联系起来。

        该阶段有4个子目标：

　　(1) 将测试阶段划分为子阶段，并与软件生命周期的各阶段相联系。

　　(2) 基于已定义的测试子阶段，采用软件生命周期V字模型。

　　(3) 制订与测试相关的工作产品的标准。

　　(4) 建立测试人员与开发人员共同工作的机制。这种机制有利于将测试活动集成于软件生命周期中。

 

　　 4) 控制和监视测试过程

　　软件组织采取如下措施：制订测试产品的标准，制订与测试相关的偶发事件的处理预案，确定测试里程碑，确定评估测试效率的度量，建立测试日志等。

      控制和监视测试过程有3个子目标：

　　(1) 制订控制和监视测试过程的机制和政策。

　　(2) 定义、记录并分配一组与测试过程相关的基本测量。

　　(3) 开发、记录并文档化一组纠偏措施和偶发事件处理预案，以备实际测试严重偏离计划时使用。

 

 

4.管理和测量级

　　TMM的管理和测量级中，测试活动包括软件生命周期中各个阶段的评审、审查和追查，使得测试活动涵盖软件验证和确认活动。因为测试是可以量化并度量的过程，根据管理和测量级要求，与软件测试相关的活动，如测试计划、测试设计和测试步骤都要经过评审。为了测量测试过程，建立测试数据库，用于收集和记录测试用例，应记录缺陷并按缺陷的严重程度划分等级。

 

　　 管理和测量级有3个要实现的成熟度目标：建立组织范围内的评审程序，建立测试过程的测量程序和软件质量评价。

 

　　 1) 建立组织范围内的评审程序

　　软件组织应在软件生命周期的各阶段实施评审，以便尽早有效地识别、分类和消除软件中的缺陷。建立评审程序有3个子目标：

　　(1) 管理层要制订评审政策支持评审过程。

　　(2) 测试组和软件质量保证组要确定并文档化整个软件生命周期中的评审目标、评审计划、评审步骤以及评审记录机制。

　　(3) 评审项由上层组织指定。通过培训参加评审的人员，使他们理解和遵循相关的评审政策和评审步骤。

 

　　 2) 建立测试过程的测量程序

　　测试过程的测量程序是评价测试过程质量、改进测试过程的基础，对监视和控制测试过程至关重要。测量包括测试进展、测试费用、软件错误和缺陷数据以及产品测量等。

       建立测试测量程序有3个子目标：

　　(1) 定义组织范围内的测试过程测量政策和目标。

　　(2) 制订测试过程测量计划。测量计划中应给出收集、分析和应用测量数据的方法。

　　(3) 应用测量结果制订测试过程改进计划。

 

　　 3) 软件质量评价

　　软件质量评价内容包括定义可测量的软件质量属性，定义评价软件工作产品的质量目标等项工作。软件质量评价有2个子目标：

　　(1) 管理层、测试组和软件质量保证组要制订与质量有关的政策、质量目标和软件产品质量属性。

　　(2) 测试过程应是结构化、已测量和已评价的，以保证达到质量目标。

 

 

5.优化、预防缺陷和质量控制级

　　本级的测试过程是可重复、可定义、可管理的，因此软件组织优化调整和持续改进测试过程。测试过程的管理为持续改进产品质量和过程质量提供指导，并提供必要的基础设施。

　　优化、预防缺陷和质量控制级有3个要实现的成熟度目标。

 

　　 1) 应用过程数据预防缺陷

　　此时的软件组织能够记录软件缺陷，分析缺陷模式，识别错误根源，制订防止缺陷再次发生的计划，提供跟踪这种活动的办法，并将这些活动贯穿于全组织的各个项目中。

        应用过程数据预防缺陷的成熟度有如下4个子目标：

　　(1) 成立缺陷预防组。

　　(2) 识别和记录在软件生命周期各阶段引入的软件缺陷和消除的缺陷。

　　(3) 建立缺陷原因分析机制，确定缺陷原因。

　　(4) 管理、开发和测试人员互相配合制订缺陷预防计划, 防止已识别的缺陷再次发生。缺陷预防计划要具有可跟踪性。

 

　　 2) 支持软件质量控制

　　软件组织通过采用统计采样技术，测量组织的自信度，测量用户对组织的信赖度以及设定软件可靠性目标来推进测试过程。为了加强软件质量控制，测试组和质量保证组要有负责质量的人员参加，他们应掌握能减少软件缺陷和改进软件质量的技术和工具。

        支持统计质量控制的子目标有：

　　(1) 软件测试组和软件质量保证组建立软件产品的质量目标，如产品的缺陷密度、组织的自信度以及可信赖度等。

　　(2) 测试管理者要将这些质量目标纳入测试计划中。

　　(3) 培训测试组学习和使用统计学方法。

　　(4) 收集用户需求以建立使用模型。

 

　　 3) 优化测试过程

　　优化测试过程在测试成熟度的最高级，已能够量化测试过程。这样就可以依据量化结果来调整测试过程，不断提高测试过程能力，并且软件组织具有支持这种能力持续增长的基础设施。基础设施包括政策、标准、培训、设备、工具以及组织结构等。

优化测试过程包含：

　　(1) 识别需要改进的测试活动。

　　(2) 实施改进。

　　(3) 跟踪改进进程。

　　(4) 不断评估所采用的与测试相关的新工具和新方法。

　　(5) 支持技术更新。

 

　　优化测试过程所需子成熟度目标包括：

　　(1) 建立测试过程改进组，监视测试过程并识别其需要改进的部分。

　　(2) 建立适当的机制以评估改进测试过程能力和测试成熟度的新工具和新技术。

　　(3) 持续评估测试过程的有效性，确定测试终止准则。终止测试的准则要与质量目标相联系。

 

 

　　总之，TMM的5个阶段可总结如下：

　　第一阶段：测试和调试没有区别，除了支持调试外，测试没有其它目的。

　　第二阶段：测试的目的是表明软件能够工作。

　　第三阶段：测试的目的是表明软件能够正常工作。

　　第四阶段：测试的目的不是要证明什么，而是要把软件不能正常工作的预知风险降低到能够接受的程度。

　　第五阶段：测试成为了自觉的约束，不用太多的测试投入即可产生低风险的软件。

　　综上所述，以下给出了测试成熟度模型的基本描述。

 

测试成熟度模型的基本描述

级别	简单描述	特征	目标
初始级	测试处于一个混乱的状态，缺乏成熟的测试目标，测试处于可有可无的地位	还不能把测试同调试分开; 编码完成后才进行测试工作; 测试的目的是表明程序没有错; 缺乏相应的测试资源
定义级	测试目标是验证软件是否符合需求，会采用基本的测试技术和方法	测试被看做是有计划的活动; 测试同调试分开; 在编码完成后才进行测试工作	启动测试计划过程;将基本的测试技术和方法 制度化
集成级	测试不再是编码后的个阶段，而是贯穿在整个软件生命周期中，测试建立在满足用户或客户的需求上	具有独立的测试部门; 根据用户需求设计测试用例; 有测试工具辅助进行测试工作; 没有建立起有效的评审制度; 没有建立起质量控制和质量度量标准	建立软件测试组织;制.订技术培训计划;测试在 整个生命周期内进行;控制和监视测试过程
管理和度量级	测试是一个度量和质量的控制过程。在软件生命周期中，评审被作为测试和软件质量控制的一部分	进行可靠性、可用性和可维护性等方面的测试; 采用数据库来管理测试用例; 具有缺陷管理系统并划分缺陷的级别; 还没有建立起缺陷预防机制，缺乏自动对测试中产生的数据进行收集和分析的手段	实施软件生命周期中各阶段评审:建立测试数据库并记录、收集有关测试数据;建立组织范围内的评审程序;建立测试过程的度量方法和程序;进行软件质量评价
优化级	具有缺陷预防和质量控制的能力，已经建立起测试规范和流程，并不断地进行测试改进.	运用缺陷预防和质量控制措施; 选择和评估测试工具存在一个既定的流程; 测试自动化程度高;自动收集缺陷信息; 有常规的缺陷分析机制	应用过程数据预防缺陷，统计质量控制，建立 软件产品的质量目标，持续改进、优化测试过程

 

 

四、三代测试框架

 

　　测试框架是为自动化软件测试提供支持的集合。测试框架经历了如下发展过程：

 

　　 第一代，无测试框架。

　　无测试框架几乎没有起到自动化测试管理作用，测试需求与测试用例关联非常弱，对自动化测试人员的编程水平以及对测试方面的整体知识把握要求都非常高。

 

　　 第二代，部分的测试框架。

　　部分的测试框架完成部分自动化测试管理，实现对测试用例的管理和缺陷跟踪，面向业务流，实现自动化测试需编写程序。

 

　 　第三代，完整的测试框架。

　　完整的测试框架具有如下功能：

　　(1) 基于完整的BPT的测试框架；

　　(2) 拥有数据场景管理；

　　(3) 企业级的面向工作流的缺陷管理；

　　(4) 业务流复用框架，轻松完成；

　　(5) 高伸缩的自动执行框架。

 

 

五、自动测试原理

　　自动测试模拟人工对计算机的操作过程和操作行为，采用类似于编译的方法对程序代码进行检查。自动测试原理可概括如下：直接对代码进行静态和动态分析、测试过程的捕获和回放、测试脚本技术和虚拟用户技术。

 

1. 代码分析

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

 

2. 录制回放

　　录制回放是黑盒测试的自动化方法，通过捕获用户的每一步操作，如用户界面的像素坐标或程序显示对象(窗口、按钮、滚动条等)的位置以及相应操作、状态变化或属性变化，用一种脚本语言记录描述，模拟用户操作。回放时，将脚本语言转换为屏幕操作，比较被测系统的输出记录与预先给定的标准结果。

　　目前的自动化负载测试解决方案几乎都是采用“录制—回放”的技术。所谓“录制—回放”技术，就是先由手工完成一遍测试流程，由计算机记录下这个流程期间客户端和服务器端之间的通信信息(这些信息通常是一些协议和数据)，并形成特定的脚本程序。然后在系统的统一管理下同时生成多个虚拟用户，并运行该脚本，监控硬件和软件平台的性能，提供分析报告或相关资料。通过模拟出成百上千的用户对应用系统进行负载能力的测试。

 

 

3. 脚本技术

　　1) 脚本概述

    　　脚本是一组测试工具执行的指令集合，也是计算机程序的另一种表现形式。脚本至少具有如下的功能：

　　 (1) 支持多种常用的变量和数据类型；

　　(2) 支持各种条件逻辑和循环结构；

　　(3) 支持函数的创建和调用。

 

　　脚本有两种：一种是手动编写或嵌入源代码；一种是通过测试工具提供的录制功能，运行程序自动录制生成脚本。录制生成脚本简单且智能化，容易操作，但仅靠自动录制脚本无法满足用户复杂的要求，因此需要手工添加函数进行参数设置，增强脚本的实用性。

 

　　2) 脚本分类

　　脚本分为以下几种类型：

　　(1) 线性脚本。录制手工执行的测试用例得到的线性脚本，包含用户键盘和鼠标输入，用于检查某个窗口是否弹出等操作。

　　(2) 结构化脚本。结构化脚本类似于结构化程序设计，包含控制脚本执行指令，具有顺序、循环和分支等结构。结构化脚本的优点是健壮性好，通过循环和调用减少工作量，缺点是较复杂，而且测试数据仍然与脚本“捆绑”在一起。

　　(3) 共享脚本。共享脚本侧重描述脚本中共享的特性，脚本可以被多个测试用例使用，一个脚本可以被另一个脚本调用。当重复任务发生变化时，只需修改一个脚本，便可达到脚本共享的目的。

 

 

4. 虚拟用户技术

　　虚拟用户技术通过模拟真实用户行为对被测程序(Application Under Test，AUT)施加负载，测量AUT的性能指标值，如事务的响应时间、服务器吞吐量等。虚拟用户技术以真实用户的“商务处理”(用户为完成一个商业业务而执行的一系列操作)作为负载的基本组成单位，用“虚拟用户”(模拟用户行为的测试脚本)模拟真实用户。

　　负载需求(例如并发虚拟用户数、处理的执行频率等)通过人工收集和分析系统使用信息来获得，负载测试工具模拟成千上万个来自不同IP地址、不同浏览器类型以及不同网络连接方式的虚拟用户同时访问AUT，并实时监视系统性能，帮助测试人员分析测试结果。虚拟用户技术具有成熟测试工具支持，但确定负载的信息要依靠人工收集，因此准确性不高。

 

 

六、自动测试的19条经验教训

Elfriede Dustin在总结了多年的自动测试项目经验后，提出了19条经验教训：

　　(1) 在软件开发周期中使用的各种工具不能够很轻易地整合在一起(The various tools used throughout the development lifecycle did not easily integrate)。

　　(2) 很多冗余的信息被存储在多个库中(Duplicate information was kept in multiple repositories)。

　　(3) 被测试工具牵着鼻子走(The automated testing tool drove the testing effort)。

　　(4) 整个测试组的每个人都在忙着编写自动测试脚本(Everyone on the testing staff was busy trying to automate scripts)。

　　(5) 重复开发的劳动，尝试编写一些非常复杂的测试脚本(Elaborate test scripts were developed，duplicating the development effort)。

　　(6) 自动测试脚本的创建往往会很麻烦，而不像工具厂商所吹嘘的那样简单易用(Automated test script creation was cumbersome)。

　　(7) 工具的培训开展得太迟，测试工程师缺乏工具方面的知识(Training was too late in the process，so test engineers lacked tool knowledge)。

　　(8) 测试工具在系统测试前两周才引入(The test tool was introduced to the testing program with two weeks left for system testing)。

　　(9) 测试人员对工具有抵触情绪(Testers resisted the tool)。

　　(10) 对自动化测试的期待值过高，期待及早得到回报(There were expectations of early payback)。

　　(11) 工具在识别第三方控件方面存在问题(The tool had problems recognizing third-party controls (widgets))。

　　(12) 缺乏测试脚本开发的规范性指南(A lack of test development guidelines was noted)。

　　(13) 某些测试工具需要插入代码到被测试程序中，但是开发人员直到测试后期才被告知这个问题(The tool was intrusive，but the development staff wasn’t informed of this problem until late in the testing lifecycle)。

　　(14) 工具创建的报告没什么用处(Reports produced by the tool were useless)。

　　(15) 在尚未确定系统工程环境之前就选择和购买工具(Tools were selected and purchased before a system engineering environment was defined)。　　(16) 工具的不同版本都在使用(Various tool versions were in use)。

　　(17) 工具的升级与现有的系统工程环境不兼容(The new tool upgrade wasn’t compatible with the existing system engineering environment)。

　　(18) 工具的数据库不允许扩展(The tool’s database didn’t allow for scalability)。

　　(19) 未能正确地使用测试工具的管理功能，导致时间的浪费(Incorrect use of a test tool’s management functionality results in wasted time)。

 

 

七、自动测试研究热点

目前，软件自动测试研究的主要热点如下。

　　1. 测试自动化框架

　　实际测试情况中，项目开发中同时包含了可实现自动化的测试活动以及难以完全实现自动化的测试活动。在自动测试与软件开发过程相融合的过程中，自动测试技术或测试方法难以完全匹配到整个项目中。而且，由于项目开发的动态特性，也难以使用通用的、普适的自动测试模型来完成测试，这就要求设计出具有较大可塑性的自动测试模型，在较少改动或者配置的情况下，最大化适应自动化测试的需求。

 

 

　　2. 测试自动化脚本技术

　　在测试过程中，大量的测试行为被自动化，测试人员指定一些简单的脚本，指导测试的自动化进行。例如，对应用程序的测试，人工的测试方式用脚本方式自动模拟执行，节省人力资源。但是，众多的自动测试工具包含了不同的脚本语言，测试人员必须学习不同的测试自动化脚本语言，如果测试脚本语言标准化且易于掌握，则可以简化自动测试的复杂性和减少测试人员的工作量。因此，对测试自动化脚本技术的研究也是自动测试技术中的一个主要内容。

 

　　3. 自动测试用例生成

　　最初的自动测试用例生成采用随机方式，这种方法简单且易于实现，但测试效率不高，受测试空间的分布影响，会有大量的测试冗余数据产生。采用启发式学习方法设计的测试用例在生成效率上有了较大的提高，包括使用进化计算或智能计算等技术，指导测试用例的自动生成，这些方法采用反馈方式对测试用例的产生进行自学习，可加速有效测试用例的生成，抑制和减少冗余数据的生成。　　自动化测试用例的生成是一种典型的数据驱动测试技术，通过自动化测试数据的生成，测试程序中存在的缺陷或错误。由于测试用例对测试的重要性，以及测试数据自动构造实现上的可行性，使得这个领域成为自动测试技术中研究得最为广泛的技术之一。

 

　　4. 测试自动化中的预测

　　自动测试技术的发展不仅仅是自动化程度的提高，同时在测试的性能和效率上都提出了更高的要求。虽然测试的活动或行为已能够很大程度上实现自动化，但对测试结果的判定仍然依赖于人工干预。如果在测试过程中能通过特定的评测标准判断什么是程序错误，那么测试就能够实现真正意义的自动化。因此，测试预测是自动测试技术中非常关键的研究内容，直接关系到测试结果的准确性。

　　目前，对测试自动化中的预测问题的研究仍相对较少，研究大多集中在使用外部规则说明产生测试预测，该信息被作为自动测试过程发现错误的参照。

 

　　5. 自动测试与可靠性分析

　　自动测试是一个反复的过程，测试与可靠性之间的关系一直都是技术人员所关注的内容。究竟在多大程度上可以信任测试的结果，什么条件下所完成的测试才是充分的，只有解决了这些问题自动测试才能体现出其价值和意义。自动测试技术是为了提高测试的效率，各种自动化测试方法和技术的引入是否会影响测试的结果以及测试评测的可信度，这些都使得对自动测试的可靠性分析的研究非常有必要。

 

　　6. 自动化安全测试

　　该领域的研究主要集中在网络通信协议的安全性测试方面。随着网络应用的日益广泛，信息安全问题也日益严重，网络应用程序的安全性是测试的重要内容。针对网络安全的有限状态，自动测试机模型是该领域的主要研究内容。

 

 

简答题

　　1．自动测试相对于手工测试有什么好处？

　　2. 自动测试发展经过了几个阶段？

　　3. 测试成熟度模型是什么？其包括哪些内容？

　　4. 录制和回放是指什么？

　　5. 脚本技术可以分为几类？分别是什么？