1 项目背景及目标

　　1.1 项目背景

　　随着房产业务高速发展，系统复杂度越来越高，作为测试同学，我们经常遇到如下问题：

　　1. 房源存在多维度不同的业务数据，业务的整个链路比较长，缺少系统的排查工具，这就会导致问题排查成本高；

　　2. 另一方面，业务交互服务较多，数据依赖较强，这就会导致数据构造场景频繁，且耗时较多。

　　其实构造数据和问题排查的需求不仅仅是我们业务需要，其他业务组也需要；不仅仅测试人员需要，其他人员也会需要；

　　比如：

　　产品同学需要测试数据梳理业务逻辑，验收新的功能。

　　开发需要测试数据进行联调、测试、复现问题和排查问题。

　　其他业务组同学日常工作中需要上下游的测试数据支持。

　　客服同学需要一些数据查询的工具，用来排查用户反馈的问题。

　　......

　　从团队整体效率而言，若测试数据需要依赖他人支持，还会有额外的沟通成本、等待时间成本，所消耗的时间就更多了。

　　那如何节省造数据和写排查工具的成本呢？

　　传统的解决方式：

　　1. 借助外部工具：比如jmeter或者postman等工具直接往数据库或者请求接口读写数据，这种方式不够灵活，定制化的数据就很难获取。

　　2. 通过脚本语言编写造数据的脚本或者排查问题的工具，通常比较适用于需要大批量的复杂数据需求。优点是可以满足不同场景，不同类型的数据构造需求，缺点是对于开发者和使用者都需要有一定的技术和业务门槛，需要知道数据之间的关系，脚本的配置以及脚本的执行方式，很难大范围推广，而且脚本的通用性不够好，换个数据需求，就需要重新编写和修改脚本。

　　上述2个方案都可以在一定程度上减少造数据成本，但不够完美，那基于这些问题，我们希望能有一套机制快速支持我们查数据，造数据，看数据；当然我们又不希望针对每一种场景数据都现去写数据操作代码，接口调用代码等等，所以我们希望通过低代码的技术来实现一套低成本，高效率的数据工厂；

　　低代码技术是近两年新兴的软件开发方式，它通过提供一套功能组件，通过对组件进行拖拽操作和简单配置来实现软件的开发和发布，与传统编程方式相比，低代码技术可以帮助开发者更快速，更简单的开发出相应的工具，降低软件开发的难度和成本。

　　1.2 项目目标

　　基于上面的背景分析，我们希望通过低代码的方式搭建一个简单、高效、安全的金字塔平台。　　

　　1.2.1 简单

　　平台应给工具创建者提供低代码实现功能的能力，包括前端页面设计和后端规则设计，才能让有数据需求的同学在最短时间完成数据工具的创建。让工具的创建者不再需要会写代码，只需要通过规范化的配置工具，进行简单设置，就可以轻松的实现一个工具搭建；通过一键发布，就可以生成工具链接投入使用。

　　1.2.2 高效

　　我们的核心目的是降本增效，为了方便大家快速上手，平台应该提前预设一些模版，简化页面设计；支持一些通用函数，方便直接引用；同时为了方便管理与应用，我们希望将工具管理平台和工具操作平台分离，工具管理平台面向工具创建者，工具操作平台面向工具使用者，最大限度降低使用门槛和学习成本，快速拿到用户想要的数据结果。

　　1.2.3 安全

　　为了确保平台的数据和页面安全，一方面平台应该制定相应的权限模块，根据不同权限进行相应管控；另一方面平台需要记录所有用户的操作行为日志，方便数据跟踪。其次对于工具维度，应该确保工具使用和调试互不影响，降低工具的维护成本。

　　基于这样的背景和目标，接下来我们拿个案例，来对平台进行一下建模分析。

　　2 平台的实现分析

　　2.1 需求案例

　　例如我们有这样一个查询需求：要做一个查询机构详细信息的工具。

　　我们希望支持不同环境（测试环境和线上环境），支持多维度条件查询（机构名称、机构id等），最终返回机构的详细内容（机构注册地址，简称，id，状态，负责人等等）

　　2.2 需求分析

　　不管是查询数据还是构造数据工具，都是通过条件输入、规则执行、结果展示这三个步骤就可以达到想要的结果。　　

　　2.2.1 条件输入模块

　　条件输入模块其实就是一个简单的表单，通过不同基础组件组装而成。　　

　　a.基础组件库

　　首先我们需要有一个组件库，包括我们常用的文本组件、选择框组件、提示信息......

　　针对我们上面的需求，想要区分环境，不同查询维度，我们的表单就可以设置一个“环境参数”选择框组件、“类型参数”选择框组件、“不同类型对应的查询内容”输入框组件，一个查询按钮，就可以完成输入表单的设计。

　　b.组件展示形式

　　有了这些基础组件后，我们希望这些基础组件以什么样的形式展示呢？这就需要对不同组件进行属性设置，比如表单一行展示几个组件、参数是否必填、选择框的选项如何设置、参数的提示信息等等，这样才是一个完整的输入表单。　　

　　2.2.2 规则模块

　　前端的表单配置好了，才只是完成了第一步，我们希望数据处理逻辑也能通过配置的方式完成；对于数据处理来说，无非就是从各种接口、数据存储容器里面拿到自己想要的结果；所以我们就可以把这些获取数据的行为定义成规则组件，通过不同规则的组合，规则执行，来获取最终想要的结果。因此规则模块就分为规则配置和规则执行。　　

　　a.规则配置

　　我们常见的规则有接口维度(http接口、RPC接口...)的处理，也有存储容器维度(mysql/redis...)的处理，不同维度需要的参数信息不同，那么我就就可以针对不同维度设置不同的规则参数，最终组合到一起，就形成了数据处理流。不同规则之间组合的过程有前后操作的依赖关系，存在后一个接口的入参是前一个接口的出参，所以就需要用到变量的提取和引用，通过“变量传递”的方式将规则串联起来，当然变量的提取与引用对数据表的增删改查操作也是支持的，数据表返回的结果信息我们当做仅有一层的json形式来统一处理（变量提取通过JsonPath的方式；变量引用方式：${变量名}）。在数据处理流组装过程中，也避免不了需要做些简单的逻辑判断，那么就需要有些基础的控制器组件(目前条件控制器支持等于(==)、不等于(!=)、大于(>)、小于(<)、大于等于(>=)、小于等于(<=)、与(&&)、或(||)表达式)。

　　针对我们上面的需求：因为要区分不同环境（测试环境和线上环境），区分不同类型（机构id，机构名称等）所以需要在规则配置中增加条件判断控制器组件，来进行不同条件的判断处理。　　

　　另一方面，想要获得机构负责人的姓名，需要先通过接口1（机构id获取到负责人id），然后通过接口2（负责人id获取负责人姓名）的方式才能得到；那这里面负责人id,就是需要定义成过程变量(dktUserId:data.userId)，由接口1提取出来；然后在接口2中输入部分进行参数引用（${dktUserId}）。

　　接口1规则参数设置情况:　　

　　接口2规则参数设置情况:　　

　　b.规则执行

　　规则信息配置好后，就需要按照配置结构、参数、变量等逻辑进行规则的执行，返回规则执行的结果信息。在规则执行期间，有些参数我们希望可以通过系统自动生成，比如自动生成手机号，姓名、随机数，时间戳等等，这里我们就需要引入内置函数的概念，通过内置函数的引用（内置函数的引用方式：${_getPhone(11)}）实现系统自动赋值的逻辑；另一方面我们可能也会用到固定的一个值，那么就需要一个可以设置常量的逻辑（常量的引用方式：&常量值）；所以我们的规则执行引擎框架就需要对这些信息进行识别、解析、处理。

　　2.2.3 结果展示模块

　　执行完的结果我们需要展示在页面；结果展示我们希望结果可读性高、简单、明了，因此我们定义了一些模版，用户可以根据自己的需求，选择不同模版，只需要通过模版属性的配置，就可以实现想要的结果展示，对于结果的内容我们支持多维度数据展示，方便用户使用。　　

　　a. 展示内容

　　有时候只需要返回最后一个规则的结果信息，有时候需要组装结果，将执行过程中的结果、变量、常量等信息都返回，所以我们除了接口结果返回，也需要支持过程变量的返回；当返回结果出错，或者异常时，我们希望能够可以便捷的进行问题追踪，所以需要将我们执行过程日志记录下来，方便调试工具。

　　b. 展示形式

　　我们目前平台初始化了三种模版，基础json格式、表格形式、描述列表形式。

　　（1）普通模版：基础表单，返回结果是将接口或者数据库结果以json的方式进行展示出来

　　优点：这种方式不需要配置，支持任何结果返回；

　　不足：当前模版不支持过程中的结果或变量展示。　　

　　（2）表格模版：返回结果以表格的形式展示，多用户返回结果多条时使用

　　优点：支持多条数据结果展示；可以自定义表格title，结果可读性强。

　　不足：当前模版不支持过程中的结果或变量返回；只支持最后一个规则返回结果是list类型的结构体；需要进行表格数据源设置。　　

　　（3）描述列表模版：返回结果以key：value的方式进行展示，多用于组合内容，且只有1条结果数据的场景使用。

　　优点：支持多维度数据展示（变量展示、结果展示、常量展示），可以自定义描述列表的key设置，结果可读性强。

　　不足：需要根据不同维度数据进行 属性API设置，有一定的配置成本。

　　针对我们上面的需求，因为没有一个接口能够一次性就返回机构的所有维度信息，所以我们需要根据不同接口规则进行不同信息的获取，最后将相关信息组装展示；这里使用列表模版就非常适合。　　

　　其实到这里一个工具就完成，可以投入使用；但是如果从平台角度考虑，我们不仅要实现基础功能，还需要从平台的安全性、价值性等方面考虑，所以就需要为平台增加些辅助功能　　

　　2.2.4 辅助功能模块

　　a. 安全功能

　　为了方便平台更好管理，我们将工具拆分2个平台，管理平台和操作平台，不同平台进行不同权限角色的维护处理，方便工具更好的维护和操作；另外针对管理平台我们记录着用户操作行为，方便跟踪工具的变更。

　　b. 版本控制

　　为了方便工具的管理和升级，我们引入了发布，增加版本号功能，区分正式版和草稿版，方便管理者更好的进行工具的调试、升级，遇到问题，也可以通过历史版本的方式进行版本回滚，降低工具的维护成本。

　　c. 效果统计

　　为了更加直观的了解我们提供的工具对业务有多大帮助，我们也进行了平台工具维度的数据统计功能的实现，包括工具的执行量、用户数等不同维度的数据统计，让工具的维护者更加直观的了解当前工具的效果情况。

　　基于上面的需求过程的分析，其实我们的平台框架也就已经出来了

　　2.3 项目架构设计

　　2.3.1 平台架构设计　　

　　展示层分为2个平台，管理平台和操作平台，可以满足一人创建，多人使用的场景

　　管理平台：进行数据工具的新建、设计、调试、发布等管理，平台用户权限设置、平台操作日志等管理

　　操作平台：发布后的工具展示以及使用，可以支持不同权限的人查看使用。

　　业务层主要围绕规则库和组件库的设置来扩展出的一些基础功能；

　　规则处理层主要运用规则处理引擎来对相关规则进行执行处理；

　　整个平台的所有功能都增加了权限控制和日志记录，让平台的使用更加安全；

　　数据存储层，针对规则和页面的数据是存储在mongodb中，方便字段的扩展和解析；日志和权限控制存在关系依赖所以存储在mysql中；

　　2.3.2 平台整体实现方案

　　金字塔平台，采用业务逻辑自动化的低代码技术方式，完成数据录入、数据处理、数据分析等各种业务逻辑的操作，从而实现测试工具的开发和使用。

　　数据录入：通过表单输入、内置函数、常量定义的方式，可以支持不同维度的数据录入。

　　数据处理：支持规则组件、逻辑控制器组件，通过规则执行引擎进行数据处理，最后通过展示结果模版配置的方式实现结果数据的不同形态的展示。

　　数据分析：在整个工具的搭建中，平台支持规则开关设置、页面调试、日志记录、草稿和发布的区分、工具的数据统计等来协助开发者进行工具相关数据的分析。

　　a. 前端低代码实现方案

　　目前开源已有的前端低代码实现技术框架比较多，像阿里的宜搭，百度的爱速搭，腾讯的微搭等，当然还有我们公司自研的珊瑚海，墨斗等等。

　　对于我们来说：

　　如果从0-1去实现前端低代码逻辑，那么对于前端的技术水平要求较高；

　　如果直接引用开源的前端低代码，那么平台功能比较复杂，学习成本比较高

　　基于这两点的考虑，最终我们选择了基于公司内部珊瑚海平台进行二次改造；因为珊瑚海平台是我们公司自研的前端低代码技术，并且支持自定义组件库，资料齐全，沟通方面，改造成本低；

　　前端低代码实现方式：　　

　　通过改造已有的页面编辑器和组件库，打包成新的jar包，引入到金字塔项目中，实现金字塔表单的设计；

　　在通过解析器来实现页面渲染，展示出对应设计好的页面；

　　b. 后端低代码实现方案

　　那对与后端来说，是我们从0-1的探索和实现；整个后端其实是分为2大部分：规则存储和规则执行。

　　规则存储：

　　不管是控制器组件还是规则组件，不管是http规则，还是myql规则，无非是由基础信息、请求参数、返回参数三部分组成，所以我们就通过这三部分进行存储结构接口设计。　　

　　（a）基础描述：存放规则的基础信息，包括规则id，规则执行顺序、规则描述等等

　　（b）请求参数：存放不同规则组件不同的请求参数，比如http，需要包括请求协议、请求入参等等

　　（c）返回参数：存放过程变量，通过变量传递的方式将规则串联起来　　

　　规则执行：

　　规则执行就是通过规则设置的方式，按照配置流程，进行规则的一步步执行，但是每个规则执行的流程都是类似的，所以我们对规则的处理进行模块化抽离，形成通用的规则处理引擎；　　

　　规则处理引擎先进行参数解析，确定是哪个规则，在进行入参变量的替换，遇到控制器配置，识别控制器并进行处理；然后进行规则的执行，执行过程中需要解析内置函数，如果当前规则返回值需要被下一个规则使用，就需要进行变量的提取，执行完规则后对结果和过程日志进行封装返回。目前我们规则引擎集成了http/rpc/myql/redis四种规则的处理。

　　3 平台效果及收益

　　3.1 平台能力

　　3.1.1平台功能

　　金字塔平台分为管理平台和操作平台，管理平台包括数据配置管理，页面配置管理，权限配置管理，操作日志查询以及数据统计报表等功能；操作平台包括工具查看列表和工具执行详情。　　

　　3.1.2 平台支持的组件配置

　　金字塔平台目前支持文字组件、表单组件、输入框组件、选择框组件、表格组件、标签页组件、描述列表组件等，满足不同表单列表和结果的设置。　　

　　3.1.3 平台支持的规则类型

　　金字塔平台目前支持常见的四种规则组件（接口规则和数据规则）和两种控制器组件（条件逻辑控制器、循环逻辑控制器），满足日常基础数据工具的配置使用。　　

　　3.2 平台使用情况和收益

　　金字塔平台是2022年底开始试点使用，目前平台功能稳定，已在安居客测试团队推广使用，覆盖人群包括产品、测试、开发、客服等同学。平台目前累计发布工具45个，累计执行次数3000+次，周累计使用频次100左右，一月累计可节省120小时，约15人日。

　　对于工具的创建者来说：传统的开发一个简单的数据工具，前后端编码下来至少需要1-2天，才能投入使用，现在我们通过金字塔平台只需要简单配置，10分钟就可以完成，并投入使用，大大提高工具的开发效率。

　　对于工具的使用者来说：不需要再到处去找人配合支持构造数据或者查询相关数据，只需要通过金字塔平台的操作页面，找到对应工具，就可以自己操作完成，大大提高工作效率和工具的利用率。

　　目前金字塔平台给房产客服同学提供了相关的数据查询工具，协助客服同学排查业务反馈的问题，从而降低了房产线上无效bug量，无效bug降低40%；部分构造数据工具，可以快速协助开发同学联调、qa同学测试以及产品同学验收，大大提高测试效率，降低人工构造数据的成本。

　　4 总结

　　金字塔平台主要目的是为了协助测试同学快速的搭建一些基础的工具，来降低构造数据以及其他数据操作的工具成本，从而提高工作效率。所以在前端低代码技术实现上引入了公司部分成熟的技术框架，后端低代码技术实现上结合公司的业务体系定制不同规则组件和规则处理引擎，希望这种低代码测试思路能够帮助到大家。如果大家发现文章中的错误或者有更优的实现方案，欢迎大家一起交流指正。