农业银行测试技术的探索与实践

近年来，农业银行数据中心(北京)(以下简称“中心”)在测试工作开展中面临多方面的挑战：首先，测试场景的广度及深度快速扩大，测试逻辑越来越复杂，简单堆砌人力的方式已经不能胜任;

其次，外部需求对于中心承接测试的效率及质量要求越来越高，如何“又快又好”地开展测试成为工作重点;

再次，由于人力、环境等资源限制，如何提高有限资源的投入产出比，是推进测试工作持续发展的关键。

在此背景下，中心经过长期探索与实践，逐步意识到测试技术对于测试工作的重要性，并摸索出了一条适应中心的测试技术发展之路。

一、农业银行测试技术的探索历程

中心的测试技术探索是在中心测试技术体系整体规划的指导下开展的，其主要历程可分为三个阶段。

1.商用测试工具引入阶段早期，测试需求相对简单，而承接测试项目快速膨胀，人力资源成为主要瓶颈。为解决这个问题，中心通过引入适用特定测试场景的商用测试工具来快速满足最紧迫的测试需求。

2.自主研发专项测试技术阶段经过一段时间的实践发现，部分测试场景中引入的商用工具并不能很好适应中心测试工作的发展，应用效果不理想，难以大规模推广应用。针对这些领域，中心投入力量进行自主研发，经过不断积累优化，逐步形成了一系列完备、创新的专项测试技术。

3.专项测试技术整合阶段无论是商用引入，还是自主研发，在各项专项测试技术的发展过程中，各自独立的体系带来了较高的维护成本，极大限制了整体投入产出比的提高。因此，实现专项测试技术内部标准化，推动专项测试技术间整合，建设可复用的组织级测试资产库，成为目前中心测试技术工作的关键。

二、农业银行测试技术的体系建设

中心的测试技术体系建设首先从整体上规划适应中心职能的测试技术(及相关测试工具)建设思路，并以此为指导，推动中心测试技术研究、研发、引入及推广工作有组织、有计划、有重点的开展。同时，在此过程中，通过不断积累已掌握测试技术的探索实践经验，来制定未掌握测试技术的探索实践方法。

1.测试技术体系建设整体思路

(1)战略明确，规划清晰

测试技术体系的建设，需要从中心测试工作职能出发确定支撑各项具体测试任务的测试技术(及相关测试工具)的建设目标、方向、功能及适用场景。

(2)急用先行，稳步推进
推进测试技术体系的建设工作要有侧重，有先后，以支撑中心亟待突破领域的专项测试技术为重，以推动大幅提升测试效率及质量的专项测试技术为重，以适用更广范围、有利于构建中心级可复用测试资产的专项测试技术为重。

(3)权衡自研与外购

在风险可控的前提下，综合评估自研与外购两种工作方式的投入产出比。一般来说，需要现成商用工具大量定制改造才能投入使用的领域，自研可以适应深度定制，持续优化;需求相对清晰通用的专项技术领域，成熟商用工具无需过多定制即能快速实施，满足测试需求。

(4)关注前沿技术

测试技术体系建设不能闭门造车，要时刻关注技术前沿，跟进业界动态，确保测试技术方向的科学性及正确性。

(5)动态调整，与时俱进
测试技术体系规划并非一成不变，要根据内外部变化，及时调整测试技术的研究目标、方向及策略，避免在错误的道路上一条路走到黑。

2.农业银行测试技术体系规划

中心的测试技术体系建设规划概况如图1所示。

测试技术体系自上而下分为4个层面。

一是测试任务层：根据中心测试职能，将中心测试任务分为4类(其中由于验收测试采用人工测试的方式，不涉及测试技术，故未列入图1中)。

二是分类层：将适用于特定测试任务的专项测试技术按其特点进行分类。

三是专项测试技术层：适用于特定测试任务的分类专项测试技术。

四是测试工具层：应用特定专项测试技术的测试工具。

其中，专项测试技术层的每项技术概况如下。(1)交易级(接口)自动化测试技术：通过与后台系统进行接口级(交易报文)通信来进行自动化测试，用于大规模后台交易的自动化回归测试、无界面接口交易的自动化功能测试、批量测试数据准备等。

(2)基于日志回放的自动化测试技术：以不同并发回放特定条件的日志数据来进行自动化测试，用于重点行部交易自动化回归测试、全量交易自动化性能测试等。

(3)界面级(非移动端)自动化测试技术：模拟人工从非移动端界面发起自动化测试，用于非移动端系统界面的自动化回归测试、批量测试数据准备等。

(4)界面级(移动端)自动化测试技术：模拟人工从移动端界面发起自动化测试，用于移动端系统界面的自动化功能测试、移动端性能测试及移动端兼容性测试、批量测试数据准备等。

(5)基于脚本发压的自动化测试技术：通过从开放平台或主机平台向被测系统发起高并发通信报文来实现自动化测试，用于重点业务的自动化性能测试。

(6)安全测试整体技术：实现各类应用系统不同级别的的安全扫描、漏洞分析及安全评估等，用于安全专项测试。

(7)体验测试整体技术：实现各类应用系统内外部体验的隔离部署及反馈搜集等，用于体验专项测试。

(8)自动化测试标准化技术：建立统一的测试数据模型库，实现界面级自动化测试技术及接口级测试技术内部的对象(交易格式及界面元素)标准化及案例标准化，用于组织级测试资产库建设。

(9)基础环境辅助技术：保障测试环境高效、高质地支持各种场景的测试工作开展，用于测试环境建立、分配、备份、回收，及模拟环境处于应用活动状态等。

(10)测试数据辅助技术：保障测试数据高效、高质地支持各种场景的测试工作开展，用于测试数据脱敏、测试数据瘦身及测试数据提取等。

(11)挡板技术(软件)：实现应用系统(软件)的虚拟化，返回模拟的软件报文，用于内部或第三方的虚拟化软件系统或服务搭建。

(12)外设模拟技术(硬件)：实现外设终端(硬件)的虚拟化，返回模拟的硬件报文，用于第三方的虚拟化硬件设备服务搭建。

(13)其他辅助测试技术：帮助提高测试效率、测试质量及测试资产复用率的其他辅助技术。

三、农业银行特色测试技术分享

1.交易级自动化测试系统农业银行新一代核心银行系统(BoEing)自动化测试系统(BATS)是中心自主设计研发、针对后台交易的自动化测试系统，主要用于大规模后台交易的自动化回归测试、无界面接口交易的自动化功能测试及批量测试数据准备等场景。

BATS的最大创新是将影响测试效率及测试质量的测试逻辑抽象成5项关键资源(交易、基础测试数据、测试案例、执行场景及执行结果)，及基于这些资源的7项关键操作(录制交易、准备数据、设计案例、录制操作、设计执行场景、执行批次及分析结果)，通过对每项关键资源建立模型，设计统一的模型表达式，将每一项关键操作的逻辑转化为模型表达式的生成、解析及执行动作(基于BATS的测试框架如图2所示)。

由此，BATS将所有的测试逻辑转化为规则的模型表达式，从而在保障测试质量的同时，最大程度地提高了测试效率。

同时，基于上述框架，BATS设计了一系列具备原始创新性的关键技术(已获得2项发明专利授权，另有1项处于实审中)，解决了自动化测试在商业银行内部难以大规模开展的几个关键问题。(1)案例设计门槛低：案例设计可视化，无需脚本编程经验，非技术人员经过半天培训即可上手，可通过多种方式自动生成案例。

(2)执行测试自动化程度高：案例执行的逻辑都被抽象后模型化，全流程关键节点都实现自动化，一个设计良好的案例可在完全无人值守的情况下反复执行。

(3)案例可回归性高： ①人员切换案例不失效，人员更换后，案例的设计、执行、修复都不受影响;

②环境切换案例不失效，与环境相关的数据均被模型化，分离案例与环境相关性;

③变更后案例修复代价小，交易变更后，能自动识别受影响案例，并最大限度自动修复。

2.测试数据脱敏及瘦身技术早期，中心开始了数据脱敏技术探索，在广泛调研商用工具后，最终选定了自主研发的道路。多年来，数据脱敏系统经过持续优化，脱敏效率及数据质量大幅提升，脱敏数据大规模应用，配套制度流程已比较完善。

近年来，针对基础环境测试数据集过大导致主机计算资源、存储资源消耗比较严重的情况，中心展开了数据瘦身技术研究，自主研发的数据瘦身系统已广泛应用于核心系统数据瘦身。

如图3所示，数据脱敏系统将生产备份数据处理成没有敏感性的数据，然后瘦身系统将脱敏后的数据处理成数据子集，此过程在专用环境中进行，由专职人员操作，保障处理过程数据的安全。除了按测试需求定制化的处理外，每个季度，会按标准化策略对全量数据进行脱敏及瘦身，并发布脱敏及瘦身标准集，该标准集适用于大部分测试需求，从而大幅提升了测试环境数据部署效率，降低了计算及存储资源消耗。

与BATS类似，数据脱敏及数据瘦身系统也设计了一系列具备原始创新性的关键技术(已获得2项发明专利授权，另有1项处于实审中)，取得了良好的应用效果。

(1)数据脱敏

①脱敏配置全部参数化，支持断点续提。

②建立了统一的30余类的脱敏策略库。

③一次全量脱敏涉及数据表900余张、脱敏字段6300余个、脱敏策略30余类。

④脱敏后数据尽可能保留了源数据除敏感性以外的特征，保障了测试质量。

⑤2016年上半年，使用脱敏标准集节约了54余天主机计算资源。

(2)数据瘦身

①采用一种新的装置来描述源数据表间的关联关系，使得仅用少量人员就能完成占存储80%的大表的关联关系梳理。

②目前，以1500万客户号为入口，关联瘦身前400张大表(其余表不变)，瘦身后数据存储压缩至全量的20%左右。

③瘦身处理节点均能命中索引，瘦身效率较高。

④瘦身后数据保留完整关联性，适用大部分功能测试场景及小规模性能测试场景。

⑤2016年上半年，使用瘦身标准集节约了212.8T主机存储资源。

3.标准化测试案例库建设近年来，中心开始进行测试案例库标准化方面的研究，以整合各项专项自动化测试技术及人工测试，建设组织级测试资产库。

测试案例标准化的最终目标有3个：一是提高测试效率，提高测试全流程效率(测试分析、案例设计、测试准备、测试执行及结果验证);二是提高测试质量，提高测试案例覆盖广度及深度;三是降低复用成本，降低人员依赖，实现重要测试资源(业务知识、案例、数据、批次、缺陷等)跨项目共享。

测试案例标准化的基本原则有3个：一是人工测试及自动化测试统一考虑，避免各自为战;二是以可落地为底线，避免方案停留在纸面;三是持续考量投入产出比，某些场景自动化测试投入产出比达不到要求的就果断舍弃。

如图4所示，中心的测试案例标准化方案按照分级及分层思路开展。

(1)分级标准化。从测试手段的作用对象来划分，可以把测试划分为两个级别。①接口级测试：通过调用被测系统接口来进行测试(如发送交易报文)，一般情况下，这种测试只能依赖接口级自动化测试工具。

②界面级测试：通过操作被测系统界面来进行测试，包括人工测试及模拟界面操作的自动化测试工具。

(2)分层标准化。无论接口级还是界面级测试，测试案例都依赖于两项关键资源：测试数据及测试对象(接口级测试的测试最小粒度为交易，界面级测试的测试最小粒度为界面对象/控件)。

要实现测试案例的标准化，需要自下而上实现测试数据及测试对象的标准化。①基础测试数据标准化基础测试数据包含两种类型：一是与被测环境相关(环境切换可能失效)的数据类别，如借记卡;二是与被测环境无关(环境切换不会失效)，但具有通用性的数据类别，如随机姓名。

基础测试数据标准化的内容包含两方面：一是特定数据类别具备的相同数据结构;二是特定数据类别的实例数据准备策略。

基础测试数据标准化的目的一是分离测试案例与重要的测试数据，使得环境切换后，测试案例不用修改也不失效(案例设计时使用的是数据模型，而非实例数据);二是提高实例数据准备效率，相同测试案例在不同环境中执行时，根据数据类别的准备策略自动完成批量数据准备。

②测试对象(交易/控件)标准化接口级测试对象(交易)标准化：定义组装及解析交易输入/输出报文的交易格式模型，如果交易开发时采用了通用的代码规范，或者有通用的数据字典，交易格式模型可以自动录制完成，并自动识别其与上一个版本间的变更情况。

界面级测试对象(控件)标准化：定义特定界面元素(控件)的定位方式及支持的操作事件。

③测试案例标准化接口级测试案例标准化：每个接口级测试案例的原子操作步骤按“交易对象+数据”的模型进行标准化。其中，模型中的交易对象来自中层接口级测试对象(交易)标准化建立的交易格式模型库;模型中的数据(基础测试数据)来自底层基础测试数据标准化建立的基础测试数据模型库。

界面级测试案例标准化：每个界面级测试案例的原子操作步骤按“界面对象+控制+数据”的模型进行标准化。其中，模型中的界面对象来自中层界面级测试对象(控件)标准化建立的界面对象(控件)模型库;模型中的数据(基础测试数据)来自底层基础测试数据标准化建立的基础测试数据模型库。

本文介绍了中心在开展测试技术探索及实践过程中的历程，分享了几项较有特点的专项测试技术研究经验。下一阶段，农业银行将继续加强重点专项测试技术的研究深度及推广力度，实施专项测试技术间整合，推动测试工作持续、健康、稳定、高效地向前发展。