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

('商业银行自动化功能测试通用框架及特征建模作者：周期律等来源：《中国金融电脑》2015年第3期近年来，商业银行的测试任务越来越复杂繁重，传统人工测试的局限逐步暴露，特别是大量的回归测试导致人力、物力及财力耗费巨大，自动化功能测试技术逐步在商业银行中得到了广泛的应用。传统的自动化软件测试框架主要分为三种。一是录制/回放的自动化测试框架：采用录制界面操作、编辑脚本、回放脚本模拟界面操作的模式，主流商用测试工具（如QTP等）大都采用此架构，此框架高度依赖于界面对象识别，灵活性较差，维护成本较高。二是数据驱动的自动化测试框架：通过将测试数据与测试脚本（或工具）进行分离，有效增加了测试的灵活性，基于此类框架衍生出多种自动化测试模型，包括TAF自动化测试模型、基于RFT工具的数据模型驱动自动化方法、基于STAF的自动化测试技术等，由于不同应用的数据特征高度异构，因此该框架的应用效果依赖于数据模型的构建质量。三是关键字驱动的自动化测试框架：在数据驱动框架基础上，提取关键字指令来驱动自动化测试，基础关键字模型包含对象（Item）、操作（Operation）和值（Value）三类，衍生框架包括ATS自动化测试框架、LKDT关键字驱动自动化测试框架、基于Ruby语言的自动化测试框架等，其应用效果取决于关键字模型匹配应用特征程度及模型简化度（影响模型可用性）。目前，商业银行主要依托两类工具来展开测试：一类是基于录制/回放的自动化测试框架的商用工具（如QTP等）或者基于商用工具的二次开发工具；另一类是基于交易（银行应用系统实现业务功能点的原子单位）报文的自主研发工具，这类工具不直接模拟界面操作，而是采用直接组装交易报文并与后台通信的模式，一般基于数据驱动或关键字驱动框架。然而，由于商业银行应用系统具有业务复杂、体量庞大、变更频繁、数据关联紧密等特点，上述两类工具一直难以在商业银行内部大规模推广使用，其原因是传统的自动化测试框架并不能很好地适用商业银行的应用特殊性，导致最能体现自动化测试价值的回归测试在银行中的通过率极低（案例失效率高），同时，案例初始设计、失效修复及日常维护的代价巨大，严重制约了自动化测试技术的发展。在此背景下，笔者基于商业银行应用特征，抽象出自动化测试的关键测试资源及测试操作，构成适用银行主流测试工具的自动化功能测试通用框架，分析每项关键资源特征并建立形式化表达式模型来描述特征，从而将每项关键操作简化为表达式的生成、解析及执行。该模型充分反映了商业银行测试操作的逻辑，并且极为简洁灵活，基于此模型，可设计一系列自动化测试技术来最大程度提升回归测试时案例的有效性，使得自动化测试真正具备在商业银行大规模推广应用的条件。一、商业银行自动化功能测试通用框架自动化功能测试的本质是对一系列测试资源进行相应测试操作的过程。采用商用工具或自行研发工具，通过其测试资源及测试操作的共性进行分析，抽象出五项关键资源及基于这些资源的七项关键操作，将其组合到一起，形成商业银行自动化功能测试的通用框架。在图1中，方框代表自动化功能测试的关键资源，其中，方框中的元素为该项关键资源的示例，虚线箭头代表自动化功能测试的关键操作，箭头指向为关键操作的对象，箭头源头为关键操作的依赖对象。从关键资源层面来看，底层资源包括交易和测试数据。交易是商业银行核心应用系统完成业务逻辑的基本单元，商业银行测试一般是以交易执行结果是否符合预期为最终目标；测试数据是驱动测试的核心要素，特别是商业银行的业务逻辑非常复杂，这使得测试数据对于测试效果的影响变得更加关键。中间层资源的测试案例是整个自动化功能测试通用框架的核心。测试案例是由一系列测试操作及在操作过程反映出的测试逻辑组成的，由于商业银行对于应用系统的操作通常都以交易为单位，而交易的执行又靠测试数据驱动，因此，商业银行测试案例是一种以交易及测试数据这两种关键资源为基础，通过按特定测试逻辑有序地执行若干交易来实现测试目的的关键资源。上层资源包括执行场景及执行结果。批次是执行场景及执行结果的基本对象，一个批次包含若干有序的测试案例。执行场景是由批次的案例组成、执行方式、并发策略等一系列测试执行要素组成的；执行结果是批次执行完成后，相应案例的输入及输出报文组成的。可见，测试案例是构成执行场景与执行结果的基础。从关键操作层面来看，录制交易与准备数据是对于底层的交易及测试数据的关键操作；设计案例与录制操作是对中间层测试案例的关键操作；设计执行场景、执行批次及分析结果则是对上层执行场景及执行结果的关键操作。以一个正常借记卡存款的测试需求为例，其涉及柜员签到、借记卡信息查询及借记卡存款三个原子交易以及柜员、终端、借记卡、金额等测试数据，测试执行前必须通过录制交易操作来获取三个交易足够的信息，并通过数据准备操作完成相关数据的抽取或生成。设计测试案例操作须按以下逻辑将交易及数据组合到一起：首先柜员签到，然后查询某特定借记卡信息确定余额，接着存钱入该借记卡，最后再次查询这张借记卡信息以确定钱已经存入。案例设计完成后，通过执行场景设计操作确定批次包含的测试案例、执行方式及并发策略，然后通过执行批次操作完成批次中案例的执行并获取结果，最后通过分析结果操作对批次中案例的执行结果进行分析并生成报告。该框架具备通用性，其定义的关键资源及关键操作很好地抽象了商业银行采用自行研发工具或商用工具开展自动化测试时需要考虑的关键要素。其中，由于商用工具一般为通用性工具，缺少银行特有的“交易”概念，其关键及相应测试操作相对本文提出框架有所减少。在图2中，方框代表商用工具自动化功能测试的关键资源，其中，虚线方框的交易资源在商用工具中并不实际存在，但隐含在测试脚本资源中，虚线箭头代表商用工具自动化功能测试的关键操作。其中，商用测试工具中的测试脚本相当于通用框架中的测试案例，除交易资源及相关操作外，其余商用工具应用中的关键资源与关键操作都在自动化功能测试通用框架中一一对应。交易资源的信息隐含在测试脚本中，录制脚本操作实际承担了通用框架中录制交易及录制操作两个关键操作的功能，一个完成录制及设计操作的测试脚本包含了足够的交易信息以确保交易报文能被正确组装并执行。该框架为分析商业银行自动化功能测试划定一个研究范畴，并明晰了一个研究思路，即通过分析关键资源特征并建立模型，来提升关键操作效能，最终达到最大程度提升自动化回归测试通过率的目的。二、关键资源特征分析为了便于对框架中五种关键资源的特征进行分析，限定特征范畴为实现最大程度测试自动化而需要进行的测试操作或需要满足的特定逻辑。1.交易特征交易是构成测试案例的基础，特征分析时主要考虑两方面因素：一是实现交易报文组装与解析；二是识别交易变更后的接口变动。（1）基本信息特征，指交易包含用于定位交易的基础信息。（2）版本信息特征，指交易包含用于标记交易变更的信息。（3）格式信息特征，指交易包含用于描述交易接口格式，进而实现输入输出报文组装及解析所需的所有信息。2.测试数据特征测试数据是驱动测试案例正确执行的关键要素。特征分析时主要考虑两方面因素：一是从实例数据中抽象出数据使用逻辑；二是提升数据准备及有效性校验效率。（1）业务含义特征，指实例数据的业务含义具有相似性。（2）关联性特征，指多个实例数据之间存在的关联关系。（3）数据准备特征，指同一类别的实例数据的数据准备方式相同。3.测试案例特征自动化测试案例是核心关键资源，特征分析时主要考虑两方面因素：一是尽可能全面，覆盖能提高测试自动化程度的所有测试操作与特定逻辑；二是尽可能简化，对特征进行合理分类。（1）交易构成特征，指测试案例中包含的交易及其执行顺序。（2）输入数据特征，指测试案例设计或执行时需要填入数据的特征，具体可分为4类：①固定数据，案例执行前填入并完成准备，且不会因为环境变更而失效的数据；②非固定数据，案例执行前填入并完成准备，且可能会因为环境变更而失效的数据；③实时内部数据，案例执行时才能获取，且需从前面已执行完成交易的输入或输出数据域获取的数据；④实时外部数据，案例执行时才能获取，且需从测试环境（后台数据库或其他系统）获取的数据。（3）相关操作特征，指案例执行到某个交易时，为能继续进行执行后续交易而需对测试环境（后台数据库或其他系统）执行的特定操作（SQL语句或相关系统执行指令）。（4）结果验证策略特征，指校验案例执行结果是否正确的策略，具体可分为3类：①应用正确性，即校验案例特定交易执行结果在应用上是否正确；②预期常数，即校验案例特定交易的特定输出数据域是否为预期常数值；③数字逻辑关系，即校验案例中各交易特定输入或输出数据域之间是否符合预期逻辑关系。4.执行场景特征执行场景的基本对象是批次，特征分析时主要考虑实现案例执行方式的多样性。（1）案例构成特征，指批次中包含的案例及其执行顺序。（2）执行方式特征，指批次中交易报文的组装方式及通信方式。（3）并发策略特征，指多个批次同时执行时的并发方式。5.执行结果特征执行结果是批次中所有案例执行完成后的输入及输出报文集合，特征分析时主要考虑实现执行结果分析的多样性。（1）案例构成特征，指批次中包含的案例及其执行顺序。（2）解析方式特征，指批次中交易输入及输出报文的解析方式。（3）分析策略特征，指批次中案例执行结果的验证方式。三、关键资源特征建模关键资源进行建模的原则：充分描述关键资源特征；以实现最大程度测试自动化为核心目的；尽可能简化模型。1.交易模型易模型对三种特征进行了具体描述。基本信息包含交易号、交易名等数据元；版本信息包含版本号、版本时间等数据元；格式信息由一个或多个交易数据域组成，数据域是组成交易格式的基本单元，包含域号、域名、输入/输出标记、公有/私有标记、类别（数据类型）、长度、循环信息及报文定位信息等数据元，其中，循环信息用于对一个循环数据域（在报文中处于某个循环体中）的特征进行描述：循环标记用来描述数据域是否为循环数据域，循环体号用来描述数据域是否处于不同循环体中，循环次数用来描述数据域在循环体中出现的固定次数（或最大次数），循环层级用来描述数据域所处循环体的层级（循环体可能迭代）；报文定位信息用来描述某个数据域如何在报文中定位，进而实现报文组装及解析。以XML报文为例，报文定位信息包含数据域对应的节点路径，而对于普通线性报文，报文定位信息需包含起始及结束位置等。为了进一步明晰交易模型与实际交易报文间的关系，以一个商业银行经典的交易报文为例进行分析。商业银行交易报文由输入报文及输出报文构成，其中两项报文又分别由若干公有数据域（交易不同数据域相同）及私有数据域组成（交易不同数据域不同），1、2、3、4等数字方框代表数据域，输出报文私有数据域的第2、3、4数据域为循环域，其中第4数据域的循环层级为2。结合前述的交易模型可见，模型搜集了足够的信息去“理解”报文，同时能在交易版本变更后，识别交易接口格式是否发生变化，这是决定案例是否受影响需要修复及如何通过技术手段加速修复过程的关键。在此基础上，为了对交易报文组装或解析能对任意数据域进行精确读写，本文定义了一套能指向报文中任意特定数据域的形式化规则。公式1：[输入/输出标记].[公有/私有标记][数据域号]公式2：[输入/输出标记].[公有/私有标记]{[本级循环数据域号]@[特定循环次数]}[输入/输出标记].[公有/私有标记]{[本级循环数据域号（定位域）]@[本级循环数据域号（条件域）]=[特定字符串]}公式1为特定数据域（非循环域）定位形式化规则，公式2为特定数据域（循环域）定位形式化规则，其中，中括号及其中文字代表一个数据项，输入/输出标记为“I”或“O”（输入或输出），公有/私有标记为“-”表示为公有域，否则为私有域，公式1的数据域号为精确定位的数据域顺序索引号（大于0的自然数），公式2定义了两种循环域定位规则（可支持嵌套定义）：一种是按特定循环次数精确定位循环体中的数据域；另一种是按条件循环域等于特定字符串的规则精确定位循环体中的数据域。上述形式化规则。2.测试数据模型测试数据结构分为3层，数据结构层及数据类别层共同组成了测试数据模型，基于数据模型生成的实例数据存储在实例数据层中。其中，测试数据层存储了一类测试实例数据所需的由若干数据列组成的基本数据结构，一个数据列是一类实例数据业务含义的聚合，这描述了业务含义特征，同时，一个数据结构包含若干数据列，这描述了关联性特征，比如对于借记卡这类数据结构来说，包含卡号、省号、行号、状态、账号、开户人、证件类型、证件号等数据列。数据类别层存储了数据结构相同、数据准备规则不同的数据类别，这描述了数据准备特征。模型提供了两种对某个特定数据类别的数据准备方式：一种是需要从测试环境中抽取的数据，如状态正常的借记卡、销户状态并且余额为0的借记卡等；另一种是需要通过内置接口函数生成的数据，如卡号位数不够的借记卡，卡号与开户人不匹配的卡等。实例数据层存储了测试案例执行时使用的实际数据。基于数据结构层与数据类别层构成的测试数据模型，对于数据类别层中的每一种数据类别，可以实现实例数据的自动准备及自动校验，其具体实现方法本文不再详细阐述。上述模型分离了数据模型与实例数据，在此基础上，为了建立特定数据模型与特定实例数据之间的关联，本文定义了一套能指向报文中任意特定数据域的形式化规则。公式3：[数据类别号].[数据结构的数据列].[数据提取规则]公式3是实例数据定位形式化规则，数据提取规则包括顺序、随机及特定三种，代表案例执行时从实例数据中取出一条数据的方式。如“状态正常卡.卡号.随机”指的数据类别是状态正常卡的卡号数据列，用随机的方式从实例数据中提取。3.测试案例模型基于交易模型及测试数据模型，测试案例模型按如下方式建立并描述相应特征。（1）交易构成特征：扩展交易模型中的特定数据域定位形式化规则（如公式1、2所示），加入“案例中交易顺序号”以描述了一个案例中包含交易的顺序，扩展后的特定数据域定位形式化规则如下。公式4：[输入/输出标记][案例中交易顺序号].[公有/私有标记][数据域号]公式5：[输入/输出标记][案例中交易顺序号].[公有/私有标记]{[本级循环数据域号]@[特定循环次数]}[输入/输出标记][案例中交易顺序号].[公有/私有标记]{[本级循环数据域号（定位域）]@[本级循环数据域号（条件域）]=[特定字符串]}公式4为扩展的特定数据域（非循环域）定位形式化规则，公式5为扩展的特定数据域（循环域）定位形式化规则。（2）输入数据特征：基于扩展的特定数据域规则（如公式4、5所示），加入等号及相应的输入数据模型，其中4种输入数据类型按表2所示规则进行建模。（3）相关操作特征：基于扩展的特定数据域规则（如公式4、5所示），加入等号及相应的相关操作模型，如I2.2=SQL语句或者I2.2=外部系统调用命令，表示执行到案例中第2个交易时，执行SQL语句更新后台数据库或者调用外部系统指令。（4）结果验证策略特征：基于扩展的特定数据域规则（如公式4、5所示），加入等号及相应的结果验证模型，其中三种验证策略可按表3所示的规则进行建模。4.执行场景及执行结果模型执行场景及执行结果的基本对象是批次，而批次所依赖的交易、数据及案例这三种关键资源的模型已经完成建模，其模型建立在对已有模型进行筛选的基础上，目的是为了实现执行及分析的选择多样性。其中，案例构成特征可参照按测试案例的交易构成特征模型设计形式化规则；执行方式特征、解析方式特征及分析策略特征在交易模型及案例模型中已经有了充分的描述，只用实现对其进行筛选即可；并发策略特征相对独立，但其本质仍然是多种方式的筛选，记录同时执行的批次个数等信息即可。四、模型应用前文已完成对5项自动化功能测试关键资源的建模，本节将首先介绍如何应用模型去优化关键操作，使之能最大程度实现测试自动化，并最终解决回归测试通过率低这一关键问题，然后介绍基于该模型设计的自动化功能测试系统在农业银行的应用情况。1.关键操作优化（1）录制交易交易在开发过程中必然会存在具备格式信息的数据文件，有些商业银行会生成标准格式文件（如WSDL等），有些商业银行会生成自定义的格式文件，而另一些商业银行虽然不生成格式中间文件，但其源代码中包含了格式信息（如C语言中的头文件等），这些格式文件通常都很有规律，很容易用开发程序进行自动解析，从而自动生成交易模型定义的基本信息、版本信息及格式信息数据，提升交易录制效率。同时，录制交易后可通过比对版本信息及格式信息，自动识别接口是否发生变更。（2）准备数据凡是需要在案例执行前填入、并可能因为环境变更而失效的数据（案例填入的非固定数据），都建立数据模型，从而使得环境变更后能自动从后台数据库抽取实例数据或者从接口程序生成实例数据，提升数据准备效率。（3）设计案例案例执行的所有逻辑简化为案例模型定义的形式化表达式，从而可以开发一系列技术来提高案例设计效率。①设计案例可视化界面无须考虑底层技术限制，可尽最大可能提高操作效率及界面友好度，最终所有操作都直接生成一系列简单的表达式。②交易接口变更自动识别后，如果是数据域调序及数据域删除的情况，可自动修复受影响案例，如果是数据域增加的情况，可让用户输入一次值，修改所有受影响案例，提高接口变更案例修复效率。③一个基础案例设计完成后，可直接将其导入其他案例以加速其他案例的设计过程，其导入操作仅需对基础案例的表达式简单复制，并根据其他案例已包含交易数据调整表达式中的“案例中交易顺序号”即可，提高案例设计效率。④一个基础案例设计完成后，可让用户选择某几个数据域，输入批量的实例数据，即可自动高效衍生出路径覆盖案例群，其衍生动作仅需对表达式简单复制，并调整相关数据域的固定数据即可，加速案例生成过程。⑤一个基础案例设计完成后，可让用户选择某几个填入固定数据的数据域，筛选关键要素选值（关键要素用于扩展数据模型中的数据结构层，对部分关键数据列进行补充描述，本文中不进行详细阐述），即可自动生成数据类别，数据类别可自动抽取或生成实例数据，结合④中的衍生技术，进而自动生成基于数据模型的案例群，加速案例生成过程。（4）录制操作商业银行应用系统客户端都会存储记录用户操作的日志文件，直接解析客户端日志，并将其转换为案例模型定义的表达式，即可实现客户端操作批量录制，提升操作录制效率。（5）设计执行场景筛选已设计好的案例进入批次，并通过配置项确定执行方式及并发策略，即可完成执行场景准备。（6）执行批次按序将批次中每个案例模型的表达式进行解析，按其对应测试逻辑执行相应操作，按交易模型定义的格式组包报文并按特定协议与被测应用系统进行交互，获取返回报文。（7）分析结果按执行结果模型中的分析策略，选择案例模型中相应的结果验证策略表达式，解析表达式，并按其逻辑进行执行结果的自动分析，提升结果分析效率及结果分析质量。2.应用效果基于本文模型，农业银行自主研发的自动化功能测试系统（BATS）中应用了一系列关键技术，包括后台交易格式录制技术、测试数据资源池构建技术、案例执行通信技术、案例执行自动化技术、交易变更案例修复技术、案例执行结果自动分析技术、客户端日志录制技术、案例自动衍生技术、测试案例自动生成技术、案例设计可视化技术等，并对自动化测试关键操作进行大幅优化，使得测试自动化程度达到一个新的高度，同时，无论是环境变更还是接口变更，这些技术都大幅提升了回归测试通过率，将人工干预降至最低。系统在农业银行新一代核心系统测试中广泛推广应用，目前已积累3600余个交易，20000余个自动化案例及近60类数据模型，系统平均交易执行时间在毫秒级；交易录制平均时间1秒；普通测试人员（无需掌握任何脚本编程技能）设计包含15个交易的复杂案例低于20分钟；识别1个交易接口变更（涉及10个以上相关案例）并修复案例时间低于30分钟；一次大规模回归测试（50个案例以上）执行时间低于10分钟，结果分析及报表生成时间低于10秒；10类数据模型（几百个实例数据）自动准备时间低于2分钟，案例覆盖率达到全量交易的92.9%；一次4000余个案例的回归测试相对传统的人工测试效率提高70余倍，相当于节约了102人天，系统全面解决了造成自动化测试低效的一系列关键问题，成为商业银行大规模开展自动化测试的成功案例。不同于传统的自动化测试理论研究框架，本文提出了一种以自动化测试特征分析建模为核心的研究思路。首先提出了一套适用于商业银行两类主流测试工具的自动化功能测试通用框架，确定了五项关键资源及七项关键操作，然后对关键资源的具体特征进行分析，并设计形式化表达式规则来建立模型，接着应用模型来逐项优化关键操作，以最大程度实现测试自动化，解决回归测试通过率低这一关键问题，最后介绍了基于该模型设计的自动化测试系统在农业银行的应用情况，验证了模型实用性及高效性。',)