银行测试探索丨信贷长链路业务测试数据快速构造方法，了解一下

一、引言

随着银行数字化转型的不断深入，对信贷领域的测试工作提出了更高的标准和要求，如何在高效完成测试任务的同时确保测试质量就成了一个亟待解决的难题。有实践研究表明，在具体测试过程中往往大量的时间精力都是耗费在测试数据准备工作上面，能否尽量减少这部分耗费，将更多的时间精力专注于业务逻辑等方面更好地去提升测试质量？本文基于此进行了探索，提出了一种长链路业务测试数据快速构造方法，并将该方法应用于信贷领域多个场景，取得了良好成效。

二、背景与挑战

当前信贷领域长链路业务测试主要有三方面特点：一是业务链路长，随着信贷业务不断迭代，业务场景一般涉及多个业务模块，整体业务流程长；二是信贷业务复杂度高，业务形态的不同会有不同的触发方式，业务逻辑的不同也会产生不同的组合方式；三是信贷业务依赖性强，业务前后环节间的依赖性强，后一环节的输入是前一环节的输出。

一般来讲，测试数据准备有“造”数和“找”数两种方式。“造”数主要是通过某种方式模拟实际业务的运行逻辑生成测试数据，一种方法是通过GUI构造测试数据，这是最常见、最可靠的方式，直接通过客户端或界面完成数据构造，缺点是成本高、效率低；另一种方法是通过数据库构造数据，缺点是直接修改数据库容易产生脏数据，全量导入数据有评估和操作成本。“找”数是通过某种方式去查找已经存在的测试数据，一种方法是通过数据库去查找可用数据，缺点是数据共用导致数据属性频繁变化，会相互影响；另一种方法是通过找项目组或者是相关系统的对应开发人员配合提供，缺点是需要熟悉各自模块，沟通成本高。这两种方式无疑都能够满足基本测试数据准备需要，但往往都伴随着“造”数难和“找”数难的问题，而对于信贷业务来说，其长链路的特点使得“造”数更难和“找”数更难，如何快速构造测试数据就成为了影响测试进度及质效的关键。

三、方法探索

在对当前信贷长链路业务测试数据准备过程中的相关现状进行分析梳理并总结归纳后，我们发现主要有以下特点：

信贷长链路数据准备一般涉及范围广，完成一次流程往往要跨多个系统或者是模块，对上下游系统间的合作需要高度的默契；

数据准备需要熟悉业务流程、熟悉业务接口和实现逻辑，对数据准备人员较高要求；

大部分情况下数据构造流程伴随着业务状态的变化，数据状态是不可逆的，只能按需不断构造新的数据；

链路越长整体成本越高；

数据间依赖性强，往往需要做数据的串联，例如下一个请求的入参需要上一个请求的返回值；

找谁造数、造什么样的数，时间往往都消耗在沟通上。

基于以上痛点和难点，并结合对测试数据实际准备过程中相关问题的探索和研究形成了长链路业务测试数据快速构造方法论，主要包括场景梳理、功能编排、数据构造、结果反馈以及维护保鲜等几部分，总体流程如下图所示：

1、场景梳理

场景梳理主要是指在熟悉长链路业务流程、接口和实现逻辑的基础上，按照待造数长链路业务场景流程梳理出涉及到哪些模块、功能、对应接口以及实现逻辑，大致如下图所示：

场景梳理的方法总结起来有三种：一是与对应开发人员沟通确认；二是将整个场景涉及到功能、接口等信息记录下来再进行筛选，例如Jmeter录制、抓包等；三是通过F12从前台界面逐一分析每个功能涉及到的接口相关信息。在实际操作过程中，一般需要结合三种方法使用会起到较好的作用。

2、功能编排

功能编排是将无序的功能编排成有序的场景，主要采用了JSONPath技术来进行处理。其优点是：语法灵活简单、使用简便、无需一层一层往下找，特别是对于比较复杂的JSON结构数据效果更加明显，在各种主流的编程语言中均有对应的库支持。其语法大致介绍如下：

简单来讲，功能编排的核心主要是通过JSONpath语法完成参数动态替换，如下图所示：

3、数据构造及结果反馈

数据构造主要包括明确输入、输出格式等信息，并按照完成组合好的场景完成数据构造，而结果反馈是将构造完成的数据按照格式反馈给用户。

4、维护保鲜机制

维护保鲜机制是为了解决在首次建立长链路业务数据构造流程后，中间由于某些原因导致长链路场景发生了变化（例如功能和接口有改变）而数据构造失效不可用，在通过维护保鲜后能够及时响应变化，以确保数据构造能够随时可用。在检查反馈数据结果是否符合预期后，如不符合则进入维护保鲜环节及时进行处置，待处置成功后继续循环构造流程。处置措施一般包括以下三方面：

1.若判断是场景发生变化，需重新评估；

2.若判断是场景中功能发生变化，需定位到具体功能，重新梳理更新场景；

3.其他问题：例如环境不可用等，需进一步排查解决。

……

由于作者版权要求，仅展示文章的一部分，如需阅读完整版文章，可以私信下方二维码。

学习交流群

↓↓↓↓↓

添加微信：atstudy-js  或者扫描下方二维码，备注“博客”邀请你进入Python自动化测试学习交流群~