UML软件工程组织

 

 

面向行业应用的自动化测试运行控制方法研究

2008-07-31 作者:张少博 罗省贤 来源:网络

 

引言

软件测试作为保证软件质量和可靠性的关键技术,正日益受到广泛的重视。而软件测试自动化,已经成为国内软件工程领域一个众所周知的课题。不言而喻,软件测试从业者都意识到软件测试这项工作走向成熟化、标准化的一个必经之路就是要实施自动化测试。

随着IT应用在各个行业的广泛推广,软件系统在许多关键业务中都扮演着极其重要的角色。信息化程度的提高意味着应用系统的可靠性对业务的开展起着关键的支撑作用。开发与维护始终伴随在行业应用系统的整个生命周期中,随之而来的面向行业应用的自动化测试需求越来越强。

但是在自动化测试过程中,如何对自动化测试脚本进行有效的管理,使各个自动化测试工具能够统一协调的运行,是目前许多行业所面临的急待解决的难题。本文结合利用业务规则生成基础脚本、创建运行控制点、实现运行控制机制、测试用例管理和报告管理等技术,设计了一套面向行业应用的基于终端界面的自动化测试运行控制方法,很好地解决了自动化测试中面临的脚本运行控制问题。

1 自动化测试流程

1.1 自动化测试

自动化测试就是通过测试工具或其他手段,按照测试工程师的预定计划对软件产品进行自动的测试,它是软件测试的一个重要的组成部分,能够完成许多手工无法完成或者难以实现的一些测试工作。正确、合理地实施自动化测试,能够快速、全面地对软件进行测试,从而提高软件质量,节省经费,缩短产品发布周期。

1.2自动化测试流程

自动化测试工具的软件测试流程,不仅仅包含完整的软件测试流程框架,同时还提供了内嵌软件测试流程的测试管理工具的支持,包括完整的测试评测方法。

1.2.1 自动化测试工具软件测试流程框架

自动化测试工具标准流程提供了一套完整的测试流程框架,软件测试团队可以以它为基础。根据业务发展的实际要求,定制符合团队使用的软件测试流程。自动化测试工具标准流程中的软件测试流程如图1所示:1.2.2自动化测试工具的评测方法 软件测试的主要评测方法包括测试覆盖和质量评测。测试覆盖是对测试完全程度的评测,它是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。质量评测是对测试对象(系统或测试的应用程序)的可靠性、稳定性以及性能的评测,它建立在对测试结果的评估和对测试过程中确定的变更请求(缺陷)分析的基础上。

2行业应用面临的运行控制问题及对策

2.1面临问题

目前,行业应用系统越来越多,这些系统可能包括ERP系统,CRM系统等。这些系统在发布之前或升级之前都要经过测试,确保主要功能都能正常运行,错误最少。如何有效地测试不断升级和不断更换应用环境的应用系统,是每个公司都会面临的问题。

同时,目前企业的网络应用环境都必须支持大量用户和不同的软硬件应用环境。难以预知的用户负载和越来越复杂的应用环境使公司时时担心会发生用户响应速度过慢、系统崩溃等问题。这些都不可避免地导致公司收益的损失。

在大型业务系统的测试过程中大都采用了自动化测试工具,但是这些工具只提供了测试的基本手段,缺乏一个可用的自动化测试管理框架,导致自动化测试往往无法得到有效的实施和进行。其根本原因是由于自动化测试建立在业务基础上,具有强烈的行业相关性,而自动化测试工具是与业务无关的,不能自动适应各个行业具体业务需求,测试过程的实施还需要大量的人为干预,自动化测试的实施效果往往很难达到人们的预期目标。

2.2方法思路

为了确保那些复杂的企业级应用在不同环境下都能可靠地运行,需要一个能简单操作的测试工具来自动完成应用程序的功能性测试;为了能在终端用户正式使用前,对应用系统各个环节的质量、可靠性和可扩展性进行测试和评价,就需要适用于不同体系架构的自动化负载压力测试工具,以预测系统行为并为系统优化提供依据。

为了应对在大型业务系统的自动化测试中面临的诸多问题,构建业务系统与自动化测试工具之间的桥梁,我们提出并建立了自动化测试运行控制平台。该平台能够根据行业业务生成基础脚本,并使用测试管理工具,管理功能测试和压力测试脚本,最后完成自动化测试,并提交测试报告。 构建自动化测试运行控制平台,首先需要通过对核心业务进行扫描分析。建立业务系统的应用描述模型;同时建立行业专家知识库,对行业业务信息进行收集和提炼,将业务信息通过规则进行表达,建立业务规则模型;再根据业务规则模型建立相关基础脚本:再根据行业应用以及测试实施的特点,运行测试脚本控制模型,完成自动化测试。 该运行控制平台还构建了庞大的测试用例库,同时将所有用例进行编目索引,使具体用例与相关的业务进行关联,方便测试脚本的自动生成。

自动化测试运行控制实施步骤如下:

(1)建立业务规则模型,并由此规则生成测试工具能识别的基础脚本(自动化测试脚本);

(2)向目标脚本中嵌入若干控制点,取得控制权;

(3)使用测试管理工具和程序实现运行控制机制;

(4)测试用例管理和测试报告管理;

上述自动化测试运行控制的实施过程如图2所示。

在完成一次自动化测试后,需要对新开发的测试用例进行分类归档,根据可复用程度分类保存到测试用例库中。随着新业务的推出,业务规则需要进一步完善,同时也可以根据测试实施的效果,对自动化测试脚本中的相关参数进行调整优化。

随着软件生命周期的推进,业务系统的开发与自动化测试反复迭代,业务规则的表达逐渐完善,测试用例库越来越丰富,自动化测试的实施的效率将越来越高。

3面向行业应用的软件测试运行控制方法

通过构建自动化测试运行控制平台可以为行业应用的自动化测试提供可行的解决方案。该平台的构建涉及到利用业务规则生成基础脚本、创建控制运行点、运行控制机制、测试用例管理和报告管理多项关键技术。 3.1利用业务规则生成基础脚本

业务规则是定义和约束企业业务结构与业务行为的规定或规范,是企业业务运作和管理决策所依赖的重要资源。业务规则应由基于规则的系统进行管理,从而把应用系统的应用逻辑与业务过程逻辑分开。

自动化测试运行控制平台建立在行业应用业务规则模型的基础之上,通过业务规则利用多级生成机制生成基础模板。

多级生成机制是自动化测试框架的重要组成部分。在这一框架中,生成机制的顶端是通过业务分析得到的业务规则和流程(业务表述层);在业务表述层之下的业务测试剧本(剧本层);在剧本层之下的是业务对象模型、交易要素模型(对象模型层);在对象模型层之下的是UI(终端界面)母版(Pattern)和指向对象模型的测试数据集(抽象数据层);在抽象数据层之下则是通过母版和数据生成的用例文本(用例表述层);在用例表述层之下则是测试工具的脚本(测试脚本层)。

这六个层面构成了逐级生成的关系,通过分析和转换工具,业务分析生成测试剧本,测试剧本和U1分析生成对象模型和要素模型;在此基础上,建立抽象数据层,然后从抽象数据层出发自动生成基础脚本和用例文本,再从用例文本生成测试脚本。各个层面的生成关系如图3所示:

3.2刨建运行控制点

为了实现对测试脚本的运行控制,需要对各个测试脚本创建运行控制点。而实现这个运行控制,需要知道测试脚本运行的人口和出口,根据测试脚本运行的机制对其进行控制。具体方法如下:

在多级运行机制生成的目标脚本中嵌入若干控制点(control point),其位置分别位于测试脚本的人口(前置控制点)、出口(后置控制点)和内部(内部控制点),其中前置、后置控制点由用例文本脚本生成器((2SC)直接置于目标脚本的人口和正常出口,内部控制点则按照需要由CSG置于目标脚本一些关键位置:如耗时无法预计的语句前,非正常出口。以便实施控制。

控制的基本手段是信号灯,信号灯位于中心数据库(DB)的控制表11Jn-signal中,控制点的基本行为就是检查自己的信号灯,并对之做出反应。控制点通过DB接口访问控制信号灯。控制点只对信号灯做出反应,如果是运行信号,则运行,如果是等待信号,则轮询等待,如果是中止信号,则中止。前置控制点负责检查运行条件,运行条件由运行控制系统确定;内置控制点检查暂停和中止信号;外置控制点则接受信号灯控制指令(用于协调与其它用例的关系,例如排队)。

在自动化工具目标脚本中,控制点以工具检查点的形式实现。

所有的控制点都在运行日志中留一条通过信息,以便审计。 run_signal结构如下:

creat table run-signal

(

Case_id varchar2(20), --用例ID

Signal number(2,0), --信号

Que number(3,0), --队列顺序

Primm了key((Case_id)

);

3.3实现运行控制机制

当创建运行控制点后,通过测试管理工具(如Qc)可以对目标脚本实行运行控制。

运行控制发生在测试脚本层面,它针对所有已经发布并且形成测试脚本的用例。分布式环境下的运行控制通过图4实现:

管理端:运行控制的决策系统,负责建立并维护运行队列,控制运行策略和信号灯;

执行端:运行控制的执行系统,负责分配测试脚本,并按照指定策略启动脚本: 信号灯组:一个受管理端控制的表,里面有针对不同用例的信号灯:

运行队列:由管理端建立的等待运行的测试用例(脚本)排队,中心数据库(DB)的表。

管理端由JAVA编写,发布的用例可以从测试工程师(TE)的桌面提交运行。此时,管理端将用例集加入运行队列中。运行队列中包含所有已经提交运行但未运行完成的用例。运行队列是可维护的,TE可以通过改变某个用例的状态(启动、等待、暂停、挂起)来控制用例的运行行为,还可以改变(属于自己的)用例的运行顺序。管理员可以对队列中所有用例的状态和顺序进行调整。运行后的用例加入另一个队列(已运行队列),运行失败的用例将标记为"失败"状态,等待TE修改或重新启动。

管理端通过执行端来分配用例并在相应的平台启动用例,方法是通过一个运行控制接口来设定执行端的运行策略。运行控制接口是一组预定义的API,它可以对不同的执行端实现相同的控制意图。

自动化测试运行控制平台对测试管理工具QC和自动化测试工具QTP等系统保持无缝集成。无缝集成指的是这样一种集成策略:通过行为的仿真,自动化测试运行控制平台使得CSG形成的用例脚本(目标脚本)对于QTP来说与普通的录制脚本没有可以感知的差别。这样,CSG生成的用例脚本将直接纳入QTP的管理并为QC所接受,无需任何专门的集成工作(无缝集成)。为了实现无缝集成,自动化测试运行控制平台将MerCUry QC定义为默认的执行端。在没有QC的情况下,自动化测试运行控制平台使用自己的执行端。自动化测试运行控制平台执行端仿真QC的行为,通过便携JAvA批处理程序调用自动化工具QTP进行自动化测试。

3.4测试用例管理及报告管理

利用自动化测试运行控制平台,用例的生成是利用业务规则通过多级生成机制生成基础用例模板及数据,并生成基于业务描述的测试用例,最终生成自动化测试脚本。业务描述用例的生成分为三种方式:直接复用、部分复用和全新开发。其中直接复用是使用过去测试实施过程中归档积累的用例,部分复用是由于业务应用环境的改变或者测试约束条件的限制可以在归档用例的基础上做部分调整即可以使用,全新开发则是由于测试对象为全新开发的业务,无归档用例可以利用,需要专门设计。

自动化测试中涉及到很多可回归测试用例。回归测试是对同一个业务系统的不同版本进行质量检查评估,是一个反复迭代的过程。在这样一个过程中,同一个业务对象在多次测试中反复出现的现象大量存在,测试用例的复用显得尤为重要。

测试用例库是回归测试的重要组成部分。用例库产生于用例管理流程,该流程由配置管理员,测试设计师,测试工程师负责。在回归测试实施后,测试设计师负责测试用例的分析,即按照用例的环境依赖程度区分其依赖要素,以便确认用例的可重用性。分析结束,交配置管理员归档,形成项目用例档案(包括可重用的和不可重用的用例)。对于可重用用例要另外单独归档,形成可重用用例档案,完善用例库积累,作为下一轮自动化测试的准备活动。

自动化测试伴随于应用系统生命周期全过程,期间将产生大量的测试报告,其中蕴含了大量的知识及测试经验积累。通过自动化测试运行控制平台运行测试脚本,能实现对测试报告的反复积累。测试报告管理系统以服务于业务系统内部测试知识挖掘为目标,充分聚集标准的测试文档、资料和资源为基础测试知识,并将内部工作过程中各个角色的测试知识挖掘为高级测试知识,反复耦合聚集完成一个更具有粘合力的测试知识系统,为内部提供强有力的测试知识保障和专业服务。

4结论

软件测试尤其是以自动化测试为代表的软件质量保证伴随着行业应用系统的整个生命周期。本文提出了一种面向行业应用的自动化测试运行控制方法,对通过业务规则生成的测试脚本进行统一协调管理,力求解决大型业务系统软件测试自动化程度低,自动化测试脚本无法有效管理等问题。由该方法支持的自动化测试运行控制平台已经在一些大型金融系统得到应用,取得良好效果。

 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号