保险自动化测试平台建设及应用

刘峰耀 张国庆

（英大泰和财产保险股份有限公司 北京市 100005）

1 建设方向

自1985年第一款名为AutoTester 自动化测试工具出现到现在，已经有35年的历程，而自动化测试工具也在随着软件开发时代的变迁而发生着变化。从具备简单录制回放功能的线性测试工具，到具备数据驱动的框架阶段[1]，再到现在以关键字驱动[2]以及更先进的智能驱动框架，自动化测试工具的演进速度越来越快。特别是随着移动互联技术的发展以及企业线上化转型步伐的加快，对软件迭代更新的频率要求越来越高，软件开发模型开始从瀑布模型向敏捷开发模型转变，传统的手工测试或者较为落后的自动化测试工具，很难应付软件开发的快速迭代和变更。在此情况下，研发针对保险行业的自动化测试平台，构建适应保险行业的自动化测试体系，是当前大部分保险公司运维模式改进的方向。

从测试环节上分，软件测试包含了单元测试、集成测试、性能测试以及回归测试等环节；从测试对象上分，包含了基于界面的功能提供型系统、基于接口的服务提供型系统和基于移动技术的APP系统。传统意义上的自动化测试工具，主要是针对基于界面的UI自动化测试而研发，未考虑对于接口或者APP的自动化测试等场景。同时，测试环节主要是应用在回归测试上，随着基于Devops 运维模式的流行和敏捷开发模式的应用，测试也需要“敏捷化”，各个测试环节都需要更高的执行效率和响应速度，也需要采用自动化测试。

因此，保险自动化测试管理平台的建设重点在以下两个方向展开：一是基于“立体式”全方位自动化测试的理念，构建自动化测试“一站式”解决方案，把UI、接口和APP 自动化测试集成在一起，在一个平台上同时进行UI、接口和APP 自动化测试；二是除了在上线前的模拟生产测试中应用全流程自动化测试以外，需要逐步将自动化测试应用到集成测试、单元测试等环节，真正达到“敏捷测试”的速度要求。而实现自动化测试的全环节使用，需要自动化测试平台具备足够的自动或智能特性，能够自动生成自动化测试用例和脚本，减少测试人员手工编写测试脚本所耗费的学习成本和使用成本。

2 功能需求分析

根据对项目整体需求的分析，确定自动化测试平台主要包括5类功能需求。平台整体功能结构如图1 所示。

（1）系统管理：包括用户管理、角色管理、项目管理、客户端管理以及监控管理等功能。通过用户管理实现对用户的增加、删除、修改、查询、导入、导出和解锁功能；通过角色管理提供用户角色权限的设置；通过项目管理提供被测系统所属项目的管理；通过客户端管理提供客户端的查询、添加、修改、删除；通过监控资源功能管理各个自动化执行机和各个执行机的权限。

图1：自动化测试平台功能结构图

图2：自动化测试平台应用架构图

图3：用例分层设计结构图

图4：自动生成用例逻辑图

（2）测试管理：用例管理提供自动化用例的查询、添加、修改、复制用例、发布等功能；用例模块提供项目的模块化管理，能够对各个项目进行模块化划分，能够将每个项目分为多个模块方便用例管理；通过协议模板实现接口测试的协议模板管理；用例集合用于将多个用例进行组合使其成为一个完整的案例，可进行测试用例的复用；公共参数用于用管理所有项目或对应项目中随时可调用的固定值，提升脚本维护效率。

（3）测试执行：任务调度提供调度设置、查询、修改、删除和执行功能；任务执行提供查看自动化调度执行结果的查看和管理；用例明细提供单条自动化调度执行结果明细和调试，用于查看单个任务执行详细结果、执行步骤并进行失败用例的调试，方便自动化测试人员定位执行中遇到错误并进行调试。

（4）质量管理：版本管理提供测试版本的登记；版本看板提供版本查询及视图功能，用于查看各个版本中用例执行统计的执行情况，并可自动生成测试报告。

（5）监控管理：定时任务监控用于查看各个调度的定时任务配置情况，方便系统管理员对发生错误的定时任务查看日志，快速定位问题；服务监控方便系统管理员查看自动化测试平台服务器运行状态，方便服务器的管理。

3 平台架构设计

3.1 系统架构设计原则

在进行自动化测试平台的整体设计时，充分考虑被测系统以及平台使用者的便捷性，采用前后端分离的总体架构，考虑到平台的可扩展性和可维护性，主要包括以下几个方面：

（1）采用Spring boot 框架嵌入式Tomcat，结合测试过程与各过程中的操作环节，基于Selenium 基础工具的基本原理，进行测试过程的自动化设计，并实现自动化测试过程中脚本编写、脚本执行的过程[3]。

（2）采用分层自动化框架的做法，每层之间都是独立的，互不影响，又可以互相灵活组装后，形成一个新的测试流程或理测试场景。

（3）采用成熟的Mysql 作为底层数据库，实现数据的存取及其数据管理。

3.2 应用架构

自动化测试平台采用B/S 架构，前端基于HTML5 技术开发，主要包括数据层、服务层和展示曾三个层次，详见图 2 自动化测试平台应用架构图。

数据层：包含两类数据，一类数据来源于不同的被测系统；另一类数据来源于测试脚本形成与测试脚本执行过程中的输入、输出数据。

服务层：包括服务端与客户端两部分，服务端构建平台应用所需的服务，主要包括系统管理、测试管理、调度管理、监控管理等；客户端实现用例设计、用例集设计、测试计划生成、定时任务制定、调度任务设定、执行机分配、测试报告生成与展现等。

展现层：提供系统的基本功能，直观展现客户端与服务端的全部功能，以及各看板与视图结果。

重点包括：个人看板、版本看板、版本报告以及支持客户端的多类操作。

4 平台实现

自动化测试平台的实现关键在于Web-UI 测试、接口测试领域的流程与测试用例的快速生成。在明确测试流程、被测应用架构、数据流向和部署架构等信息后，规划出测试流程中需要自动化处理的内容与节点，通过利用开源基础组件，实现Web-UI 测试自动化[4]和接口测试自动化。

4.1 用例的组装

自动化测试平台支持通过界面化操作组装形成测试用例，将测试用例的组成要素进行拆分，通过界面化展现与元素预设的功能，实现无需编码即可形成自动化测试用例的效果。将用例拆分为步骤、包|定位路径、方法|操作、参数、步骤动作、预期结果。分别针对Web-UI、接口不同类型，将常用的方法、步骤动作作为选项，通过使用者输入或者选择预设信息，后台自动拼装成可执行脚本，并将不同步骤的顺序调整，增加步骤封装为功能菜单，降低了使用者的编码能力，使得自动化测试的使用面可以扩大。

结合保险核心业务系统模块功能多将用例进行模块化拆分，降低用例的粒度，使得用例的可维护性增强。鉴于保险核心相关系统，数据生命周期长的特点，通过中间变量传参，实现系统内，系统间的传参，保证测试场景中数据的可用性与一致性。用例分层模型示意图如图3 所示。

用例分层设计即减少了用例设计期间调试的工作量，也减少了脚本维护的工作量。当被测系统页面要素或者功能发生变化，只需要更新与维护对应功能模块的用例，与其所关联用例自动更新。

4.2 用例的生成

用例的生成方式有两种模式，一种是手工通过界面操作，自然录入生成，另一种是通过借助第三方插件，在操作被测系统的同时，将页面要素的定位信息、页面要素的基本信息抓取出来，通过自动化测试平台接口自动写入用例步骤的对应字段中，当录制结束后，可以生成的基本信息中调试与增加参数化等操作，使得用例生成更便捷，其逻辑示意图如图4 所示。

5 应用成效

通过建设自动化测试平台，可在有限时间内提升测试的覆盖面，使得人力从相对重复的场景测试中脱离出来，将工作重心着力于版本的个性化需求测试中；同时，通过自动化测试平台，有利于测试资产的复用与积累。

分析某次模拟封板测试结果可以看出，在同等发版周期不变的情况下，同等人力投入，测试范围综合扩大6 倍以上，而随着自动化测试用例的逐步完善与追加，范围可继续扩大，相对执行效率会得到有效提升。

6 结语

随着自动化测试工具的应用，软件测试工作的测试时效和测试质量得到有效提高，也提升了整体的生产效能。下一步，我们将通过分析保险行业核心软件的特性，以及常用第三方接口，进一步扩大自动化测试的范围，提升自动化测试平台的应用深度，将自动化测试推广到集成测试以及开发自测环节。