千亿级公司低代码平台的测试体系介绍

一、有赞低代码平台-bos介绍

1.1、什么是低代码平台

       低代码开发平台已经成为现在很多企业开发管理应用程序的重要工具，低代码平台的出现帮助企业降低了软件开发的成本，提高了软件开发的效率，越来越多的公司开始开发低代码平台，甚至基于低代码平台开始商业化，比如微软的Power Platform,Salesforce的Lightning，阿里的星环等，我在这里介绍一下有赞的低代码开发平台-BOS。

1.2、什么是BOS，解决什么问题

        商业操作系统（Business Operating System），商家的经营需要广告曝光，销售员，货品，快递，资产，营销策划，服务等要素，企业数字化前提是对经营要素进行数字化，现实世界承担执行和信息采集，而虚拟世界事前模拟推演得出最佳路径和步骤，从而提升商家经营效率。

        BOS对经营要素进行数字化登记，并提供了搭建工具，用于集成数字化后的要素，按商家的意愿来调度要素，来构建企业数字化的各种业务链路，被数字化后的要素称之为”组件“。”组件“多来自生态，市场化运作方式商家可以集成优质的要素从而丰富货源，提升服务水平，内容得到精准的曝光，用户体验链路更加细腻。要素需要生态共识的”数据标准“才能被按需集成，而有赞则是标准的起草者，便于买家认知，也是组件接入和执行的依据，还能建立组件之间的通讯。

         商业操作系统致力于用无代码编排替代传统编码方式来集成要素实现业务需求，来满足千差万别的企业数字化要求。另外，也降低了研发门槛，倡导“全民研发”的理念，让运营人员自行调整逻辑和交互，最大限度释放创造力还原一个点子，即时、高效、低成本验证数字化方案的可行性，并且全链路的逻辑一览无余。

        接入的组件都依赖数据标准，彼此之间无依赖，这就让分布式独立开发组件变得可行，从而垂直业务，ISV，商家都能提供组件，运营按编排成为产品，多版本的迭代并相互隔离。

        综上，BOS由数据标准，组件接入标准，应用层编排模型，规则引擎，数据连接器，组件扩展标准，自动测试/运维，产品授权和鉴权，产品模板，开发者准入、培训和认证体系，经营者商业关系管理，以及市场化运作方式构成。

1.3、以交易接入为例，讲述一下bos发展

        小结：因为本文重点讲的是bos的测试体系，对于bos的内容不过多赘述了，有兴趣的小伙伴可以查看有赞coder的文章，里面有更多相关bos的内容。

二、业务代码接入低代码平台的测试用例设计和自动化介绍

2.1、bos测试case的设计思路

       bos主要的核心主要是将业务需求结构化，比如针对交易，先是把交易业务抽象成订单确认，下单等一个一个工作流，工作流是由一个一个业务产品组成，如这里的（订单基础产品，渠道数量产品，自提产品等），产品之间会有一些叠加互斥的关系，然后产品内部，又是由一个一个活动任务组成如（数据初始化，业务校验，业务装配等），再然后活动任务，又是由一个一个组件组成（组件由开发编码并上传到bos）。针对这样的结构化的需求，我们需要把对应的case也做结构化，需要针对不同组件改动设计组件的测试case，针对活动任务合在一起的产品设计针对产品的测试case，针对整个大的工作流设计工作流的测试case。我们的测试case，需要跟着业务代码的结构化，而做结构化，从而达到精准并且全面得测试到某个组件，某个产品，某个工作流的目的。

2.2、bos测试case的自动化

       bos的产品是一个持续迭代的过程，其实对于测试同学来讲这就相当于一个大规模的重构项目，所以自动化回归是必不可少的手段，针对bos开发流程，我的自动化测试策略也做了一些适配，bos在开发之前会先做大量的需求结构化，然后把原来的需求拆分成一个一个组件，所以开始阶段，我们先对组件进行case的结构化梳理，并编写自动化case，在开发提测时，之前的自动化case可以作为开发的准入case，同时这部分case也可以赋能开发自测，然后进行qa测试，这个阶段主要执行之前编写自动化case执行，并在上预发之前，把全量针对组件的自动化case执行通过，作为上预发之前的准入执行。预发测试过程中除了必要的功能回归，这边还会执行全量的预发自动化case，以及流量回放（流量回放的具体策略在下一节详细描述），待这些都通过后开始发布组件。组件依次发布完成后，开发同学会把组件配置到bos上去，形成一个个可视化的产品，工作流。具体的测试策略和组件的测试一致，只是把之前组件级的自动化case换成了产品级和工作流级的自动化case。

三、业务代码接入低代码平台的流量回放介绍

3.1、流量回放介绍

        先简要介绍一些有赞的流量回放平台，流量回放顾名思义就是采集线上的流量，在预发或者测试环境跑线上的流量，differ结果，找到差异的一种手段。有赞这边的流量回放，是基于开源的sandbox实现的，原理上是通过sandbox采集线上的流量，并通过消息的方式告知到流量回放平台，流量回放平台再把这部分流量到预发上跑（主要是读接口），或者把这部分流量到qa环境跑，不过需要mock外部依赖（读写都有）。有赞这里预发回放目前只支持读接口，因为如果是写接口，会写入线上db，变成脏数据，污染线上环境。

3.2、bos基于流量回放的测试

        前面说到业务接入bos，对测试来讲其实就类似于一个大规模的重构，如此大规模的重构，靠人工设计测试用例，势必很容易会有遗漏的地方，所以做完人工的自动化回归之后，我们引入流量回放的方式来辅助测试，来防治遗漏一些我们设计用例过程中场景比较偏比较容易遗漏的场景。针对于读接口，我们采用线上采集线下回放的方式，因为平台天然适配，取得了不错的效果。但是对于写接口，因为平台不支持，但是如果采用线上采集，qa环境回放，因为是外部依赖是mock，需要根据调用外部依赖的入参，去匹配对应的mock值，但是我们这边有很多接口是随机值，经常会导致回放失败，走不通，所以我们最后选择了一个中间方案。对于写接口（这边以订单创建接口为例），我们将订单创建接口剥离出了只读的部分（下单在[业务装配]活动任务前无数据写入），预发提供两套读接口，一套老流程无数据写入返回合同，一套bos流程无数据写入返回合同。抓取线上流量，在预发执行两个接口，比对返回值是否符合预期，主要实现如下图：         这个方案目前仅仅是一个过渡方案，后面对于这样写接口，我们的初步想法，是利用影子链路，在写接口落库操作的时候带上影子标，进入影子表，然后比对生产和影子链路的数据，也可以比较接口的返回，初步设想如下图：

四、业务代码接入低代码平台的压测方案介绍

        对于压测方案，我们主要是希望，在进行bos化改造之后，系统的性能不要下降，所以我们这边的压测策略选择了单机压测，相同的qps，观察分别走新老链路的性能指标。

五、业务代码接入低代码平台的兜底方案介绍

       在上线过程中，为了防止接入bos出现bug，我们有一套比较详细的兜底方案，我们会针对在切流过程中，出现对各种由bos平台导致的异常进行降级兜底，触发兜底之后，会走到老的链路，同时配置监控告警，防止对线上业务产生影响。兜底方案如下图：

       bos在有赞是一个比较新的东西，针对bos的测试手段目前也在摸索当中，针对现有的业务，我们沉淀了一些测试策略，并在不断迭代改进中，比如我们设想在测试过程中，可以显式告诉我们组件的调用过程，帮助我们进行问题排查；比如目前无论是组件的，产品的，工作流级别的case入口，都是工作流的接口，是否可以将其拆分开来，做具有针对性的测试，等等。希望在不久的将来，我们可以有一套非常完备的业务接入bos的测试解决方案。