• 快捷搜索
  • 全站搜索

银行自动化功能测试通用框架及特征建模

2016-07-22 01:01:56作者:中国农业银行数据中心 周期律 杨志刚 郭丽 高琦 编辑:金融咨询网
本文提出了一种以自动化测试特征分析建模为核心的研究思路。首先提出一套适用于商业银行两类主流测试工具的自动化功能测试通用框架,确定了五项关键资源及七项关键操作,并对关键资源的具体特征进行分析,并设计形式化表达式规则来建立模型,接着应用模型来逐项优化关键操作。最后介绍了基于该模型设计的自动化测试系统在农业银行的应用情况,验证了模型实用性及高效性。

近年来,商业银行的测试任务越来越复杂繁重,传统人工测试的局限逐步暴露,特别是大量的回归测试导致人力、物力及财力耗费巨大,自动化功能测试技术逐步在商业银行中得到了广泛的应用。

        传统的自动化软件测试框架主要分为三种。一是录制/回放的自动化测试框架:采用录制界面操作、编辑脚本、回放脚本模拟界面操作的模式,主流商用测试工具(如QTP等)大都采用此架构,此框架高度依赖于界面对象识别,灵活性较差,维护成本较高:二是数据驱动的自动化测试框架:通过将测试数据与测试脚本(或工具)进行分离,有效增加了测试的灵活性,基于此类框架衍生出多种自动化测试模型,包括TAF自动化测试模型、基于RFT工具的数据模型驱动自动化方法、基于STAF的自动化测试技术等,由于不同应用的数据特征高度异构,因此该框架的应用效果依赖于数据模型的构建质量:三是关键字驱动的自动化测试框架:在数据驱动框架基础上,提取关键字指令来驱动自动化测试,基础关键字模型包含对象(Item)、操作(Operation)和值(Value)三类,衍生框架包括ATS自动化测试框架、LKDT关键字驱动自动化测试框架、基于Ruby语言的自动化测试框架等,其应用效果取决于关键字模型匹配应用特征程度及模型简化度(影响模型可用性)。

        目前,商业银行主要依托两类工具来展开测试:一类是基于录制/回放的自动化测试框架的商用工具(如QTP等)或者基于商用工具的二次开发工具;另一类是基于交易(银行应用系统实现业务功能点的原子单位)报文的自主研发工具,这类工具不直接模拟界面操作,而是采用直接组装交易报文并与后台通信的模式,一般基于数据驱动或关键字驱动框架。

        然而,由于商业银行应用系统具有业务复杂、体量庞大、变更频繁、数据关联紧密等特点,上述两类工具一直难以在商业银行内部大规模推广使用,其原因是传统的自动化测试框架并不能很好地适用商业银行的应用特殊性,导致最能体现自动化测试价值的回归测试在银行中的通过率极低(案例失效率高),同时,案例初始设计、失效修复及日常维护的代价巨大,严重制约了自动化测试技术的发展。

        在此背景下,笔者基于商业银行应用特征,抽象出自动化测试的关键测试资源及测试操作,构成适用银行主流测试工具的自动化功能测试通用框架,分析每项关键资源特征并建立形式化表达式模型来描述特征,从而将每项关键操作简化为表达式的生成、解析及执行。该模型充分反映了商业银行测试操作的逻辑,并且极为简洁灵活,基于此模型,可设计一系列自动化测试技术来最大程度提升回归测试时案例的有效性,使得自动化测试真正具备在商业银行大规模推广应用的条件。 一、商业银行自动化功能测试通用框架

        自动化功能测试的本质是对一系列测试资源进行相应测试操作的过程。采用商用工具或自行研发工具,通过其测试资源及测试操作的共性进行分析,抽象出五项关键资源及基于这些资源的七项关键操作,将其组合到一起.形成商业银行自动化功能测试的通用框架、如图1所示)。

1.jpg

        在图1中,方框代表自动化功能测试的关键资源,其中,方框中的元素为该项关键资源的示例,虚线箭头代表自动化功能测试的关键操作,箭头指向为关键操作的对象,箭头源头为关键操作的依赖对象。

        从关键资源层面来看,底层资源包括交易和测试数据。交易是商业银行核心应用系统完成业务逻辑的基本单元,商业银行测试一般是以交易执行结果是否符合预期为最终目标;测试数据是驱动测试的核心要素,特别是商业银行的业务逻辑非常复杂,这使得测试数据对于测试效果的影响变得更加关键。

        中间层资源的测试案例是整个自动化功能测试通用框架的核心:测试案例是由一系列测试操作及在操作过程反映出的测试逻辑组成的.由于商业银行对于应用系统的操作通常都以交易为单位,而交易的执行又靠测试数据驱动,因此,商业银行测试案例是一种以交易及测试数据这两种关键资源为基础,通过按特定测试逻辑有序地执行若干交易来实现测试目的的关键资源。

        上层资源包括执行场景及执行结果。批次是执行场景及执行结果的基本对象,一个批次包含若干有序的测试案例。执行场景是由批次的案例组成、执行方式、并发策略等一系列测试执行要素组成的;执行结果是批次执行完成后,相应案例的输入及输出报文组成的。可见,测试案例是构成执行场景与执行结果的基础。

        从关键操作层面来看,录制交易与准备数据是对于底层的交易及测试数据的关键操作;设计案例与录制操作是对中间层测试案例的关键操作;设计执行场景、执行批次及分析结果则是对上层执行场景及执行结果的关键操作。

        以一个正常借记卡存款的测试需求为例,其涉及柜员签到、借记卡信息查询及借记卡存款三个原子交易以及柜员、终端、借记卡、金额等测试数据,测试执行前必须通过录制交易操作来获取三个交易足够的信息,并通过数据准备操作完成相关数据的抽取或生成。设计测试案例操作须按以下逻辑将交易及数据组合到一起:首先柜员签到,然后查询某特定借记卡信息确定余额,接着存钱入该借记卡,最后再次查询这张借记卡信息以确定钱已经存入。案例设计完成后.通过执行场景设计操作确定批次包含的测试案例、执行方式及并发策略,然后通过执行批次操作完成批次中案例的执行并获取结果,最后通过分析结果操作对批次中案例的执行结果进行分析并生成报告。

        该框架具备通用性,其定义的关键资源及关键操作很好地抽象了商业银行采用自行研发工具或商用工具开展自动化测试时需要考虑的关键要素。其中,由于商用工具一般为通用性工具,缺少银行特有的“交易”概念,其关键及相应测试操作相对本文提出框架有所减少,对应图如图2所示。

2.jpg

        在图2中,方框代表商用工具自动化功能测试的关键资源,其中,虚线方框的交易资源在商用工具中并不实际存在,但隐含在测试脚本资源中,虚线箭头代表商用工具自动化功能测试的关键操作。

        其中,商用测试工具中的测试脚本相当于通用框架中的测试案例,除交易资源及相关操作外,其余商用工具应用中的关键资源与关键操作都在自动化功能测试通用框架中一一对应。交易资源的信息隐含在测试脚本中,录制脚本操作实际承担了通用框架中录制交易及录制操作两个关键操作的功能,一个完成录制及设计操作的测试脚本包含了足够的交易信息以确保交易报文能被正确组装并执行。

        该框架为分析商业银行自动化功能测试划定一个研究范畴,并明晰了一个研究思路,即通过分析关键资源特征并建立模型,来提升关键操作效能,最终达到最大程度提升自动化回归测试通过率的目的。

二、关键资源特征分析

        为了便于对框架中五种关键资源的特征进行分析,限定特征范畴为实现最大程度测试自动化而需要进行的测试操作或需要满足的特定逻辑。

        1.交易特征

        交易是构成测试案例的基础,特征分析时主要考虑两方面因素:一是实现交易报文组装与解析;二是识别交易变更后的接口变动。

        (1)基本信息特征,指交易包含用于定位交易的基础信息。

        (2)版本信息特征,指交易包含用于标记交易变更的信息。

        (3)格式信息特征,指交易包含用于描述交易接口格式,进而实现输入输出报文组装及解析所需的所有信息。

        2.测试数据特征

        测试数据是驱动测试案例正确执行的关键要素。特征分析时主要考虑两方面因素:一是从实例数据中抽象出数据使用逻辑;二是提升数据准备及有效性校验效率。

        (1)业务含义特征,指实例数据的业务含义具有相似性。

        (2)关联性特征,指多个实例数据之间存在的关联关系。

        (3)数据准备特征,指同一类别的实例数据的数据准备方式相同。

        3.测试案例特征

        自动化测试案例是核心关键资源,特征分析时主要考虑两方面因素:一是尽可能全面,覆盖能提高测试自动化程度的所有测试操作与特定逻辑;二是尽可能简化,对特征进行合理分类。

       (1)交易构成特征,指测试案例中包含的交易及其执行顺序。

       (2)输入数据特征,指测试案例设计或执行时需要填入数据的特征,具体可分为4类:①固定数据,案例执行前填入并完成准备,且不会因为环境变更而失效的数据;②非固定数据,案例执行前填入并完成准备,且可能会因为环境变更而失效的数据;3、实时内部数据,案例执行时才能获取,且需从前面已执行完成交易的输入或输出数据域获取的数据;④实时外部数据,案例执行时才能获取,且需从测试环境(后台数据库或其色系统)获取的数据。

       (3)相关操作特征,指案例执行到某个交易时,为能继续进行执行后续交易而需对测试环境(后台数据库或其他系统)执行的特定操作(SQL语句或相关系统执行指令)。

       (4)结果验证策略特征,指校验案例执行结果是否正确的策略,具体可分为3类:①应用正确性,即校验案例特定交易执行结果在应用上是否正确;②预期常数,即校验案例特定交易的特定输出数据域是否为预期常数值;③数字逻辑关系,即校验案例中各交易特定输入或输出数据域之间是否符合预期逻辑关系。

        4.执行场景特征

        执行场景的基本对象是批次,特征分析时主要考虑实现案例执行方式的多样性。

       (1)案例构成特征,指批次中包含的案例及其执行顺序。

       (2)执行方式特征,指批次中交易报文的组装方式及通信方式。

       (3)并发策略特征,指多个批次同时执行时的并发方式。

        5.执行结果特征

        执行结果是批次中所有案例执行完成后的输入及输出报文集合,特征分析时主要考虑实现执行结果分析的多样性。

       (1)案例构成特征,指批次中包含的案例及其执行顺序。

       (2)解析方式特征,指批次中交易输入及输出报文的解析方式。

       (3)分析策略特征,指批次中案例执行结果的验证方式。

 1 2 3 下一页 尾页

扫码即可手机
阅读转发此文

本文评论

相关文章