编者注：在2022年8月13日举办的 “2022 MeterSphere 开源持续测试平台城市遇见· 深圳站” 活动中，深圳法大大网络科技有限公司测试负责人董虎分享了题为《基于 MeterSphere 打通 DevOps 流程》的主题演讲。以下内容根据本次演讲整理而成。
法大大是国内领先的电子合同与电子签云服务平台（Fadada Agreement & Signature Cloud），致力为企业、政府和个人提供基于合法数字签名技术的电子合同和电子单据的在线协同签署及管理服务，构建商业契约的数字化基础能力，助力企业数字化转型和社会数字化升级。
法大大的主要产品能力及服务包括：电子签名和电子印章管理、合同模板创作和管理、合同或文件的多方协作签署、签署后的合同管理、合同智能审核及全链路存证和出证服务等。企业的各种数字化业务系统、IT 系统及产业互联网平台，可与法大大平台无缝集成，实现具体业务场景与电子签的全链路数字化闭环，进而促进业务发展、效率提升、安全保障和风险控制。
深圳法大大网络科技有限公司测试负责人 董虎
一、法大大的业务背景
法大大所有的产品模块共同构建起了一个完整的 Fadada Cloud，并通过以下两种方式为客户提供服务：
■ Cloud（SaaS 和 OpenAPI）
■ Open Platform，简称为 OP（OP-SaaS 和 OP-OpenAPI）
这两种方式都可以通过 SaaS 或 OpenAPI 的模式与用户及客户系统进行交互。SaaS 和 OpenAPI 并存的模式是法大大产品体系的一个特色。
其中 SaaS 产品为标准上市产品，也就是即开即用产品，会被较多的用户所采纳，包含 PC 端、小程序、微信、企业微信之类产品。它们的后台服务一般会有自己的架构。法大大的 SaaS 模式后台架构有以下几个维度：
① 前端的 APP 类产品：终端产品；
② 前端对应的后台；
③ 后台的 Business Facade（业务外观）层；
④ Core（核心）层和业务层。
与之对应，测试产品也可以做出分层，即不仅仅将其当作一个简单的工具去设定或者使用，而是做出产品形态的划分。
OpenAPI 集成模式的产品也拥有一定的用户群。很多客户不愿意直接使用 SaaS 版本的产品，而是会采用集成的方式与公司内部的系统打通，与业务进行关联。
二、为什么使用 MeterSphere 开源测试平台？
法大大的测试团队人数在 30 人以内。对于这种规模的团队，如果公司支持的话，会安排少部分专属的测试开发人员，去定制开发测试平台；其他绝大部分测试人员则是集中于业务测试方面。但在实际工作中，公司业务很多，测试开发人员也需要去做业务测试的工作。另外，这少部分测试开发人员开发出的测试平台也不一定能够满足当前的业务需求。
从时间、成本、效率三个维度考量，并考虑到后续项目推广的要求，经过对多个现有测试产品的调研，最终我们决定使用 MeterSphere 开源持续测试平台。
选择 MeterSphere 开源持续测试平台的理由如下：
■使用体验佳：MeterSphere 的界面简单易用，具备接口管理、接口用例管理、自动化测试的编排能力，支持自动输出测试报告能力，大幅缩短了原来的测试时长；
■能够在不同 Scrum 团队、项目中推广：具备简单易用的特性、项目团队协同能力，以及个性化的协议满足能力；
■测试数据的沉淀与量化，并直观显示：用户可以以此建立一套可量化的评测体系来衡量测试人员的工作情况，提高测试的能效。
MeterSphere 是一个简单易用的测试平台工具，不过这也不意味着使用 MeterSphere 进行测试工作没有技术含量。
我们也可以将 MeterSphere 与我们自己的测试产品集成使用，比如与 TAPD、Jira 进行集成；我们可以提供标准化的 API 产品，让第三方公司可以集成 MeterSphere 平台去完善自己的产品，同时也可以去提供 GUI，实现一些原本不易实现的交互验证。这样一来，第三方公司就可以结合自己的业务集成 MeterSphere。
结合公司的业务去思考，虽然整个 MeterSphere 的架构比较复杂，但因为我们公司的团队是以 Scrum 团队模式去运行，实际在用户层面，我们每个产品的模块也都是模块化部署的。也就是说，我们的每个产品测试中也只需要用到一些基本的功能，所以只要按需上架产品功能即可。
如果需要测试方案的第三方团队要求比较高，则需要针对其产品特性去做定制。
三、自动化测试流水线整体思路
最初法大大的测试团队在整个 DevOps 流水线中存在感较低。在我们的 PipeLine（流水线）链路中，从代码仓库的建立、扫描，到构建部署镜像等步骤，都有可使用的工具，甚至我们的发布工具从 SIT（系统集成测试）、UAT（用户接受测试）和生产都有智能的平台工具。但是整个链路缺乏测试平台的接入和打通，且测试环节中没有平台化的工具体现，所使用的都是 JMeter、Postman 等本地化的工具。
有了 MeterSphere 开源持续测试平台后，我们着手将其嵌入公司的自动化测试流水线。
在建设自动化测试流水线之前，我们首先需要了解 GitFlow 分支发布的流程规范。
法大大的 GitFlow 流程如下：
① 拉取线上归档分支的 feature 分支（开发分支）去进行开发；
② 提测之后，将代码合并到 test 分支（集成测试分支）进行测试；
③ 在 test 分支的测试通过之后，将代码合并到 release 分支（发版分支）；
④ 线上测试通过、发布成功后归档到 master 分支。
我们与开发、运维、测试人员等全面同步了 GitFlow 分支发布的流程规范，加深了各部门对 DevOps 中这个重要环节的理解。
法大大内部使用的是稳豸发布平台，这是一个我们基于 Jenkins 自建的平台，使用体验更佳，也更适配我们的日常工作流程。稳豸发布平台基于 GitFlow 分支管理规范去运行，为我们的测试工作带来更良好的体验。
基于 MeterSphere 平台的自动化测试流水线
法大大的自动化测试流水线整体思路如下：
① 在部署环境推进项目时，测试人员与运维人员打通 MeterSphere 与稳豸发布平台等其他平台；
② 部署成功之后，发送一个 Kafka 消息到内部的质量平台，内部质量平台就可以获取服务信息，包括它的环境、版本信息、镜像号以及服务名称等；
③ 获取服务信息后，到质量平台对应的测试计划做智能匹配。匹配到测试计划后，即可调度对应的 MeterSphere 在 ms-api-server 层的应用服务接口，用它去跟 MeterSphere 做实际的交互，也就是执行 MeterSphere 的测试计划；
④ 由 MeterSphere 来测试对应的真实应用服务，然后把测试结果信息回传到 ms-api-server 层；
⑤ 对 MeterSphere 的测试结果进行解析，返回测试报告信息到质量平台，并将测试结果通过企业微信通知给对应人员。
MeterSphere 的自动化测试功能确实非常强大，不只可以用于功能测试，也可以用到接口自动化，以及后续的 UI 自动化。MeterSphere 可以集成被测对象的内容模块到测试计划中，只需要去调度对应的测试计划标识，就可以方便地调动多个测试用例。
通过 MeterSphere 平台可以进行测试计划的管理和调度、测试结果的上传，也可以定制测试结果通知消息模板的配置管理策略等。
测试结束后，平台会将测试结果以流水线中设定的格式，通过企业微信群告知测试人员。实际上在我们的自动化测试流水线中，平台会更加详细地记录用例执行的方式、过程以及结果等具体信息。这也是 MeterSphere 平台本身所具备的能力。
我们可以凭借这些记录来判断哪些真实的业务场景实际应用得更多，这样就可以进一步得知团队应该在哪些方面着重发力。
由于互联网公司的发展较快，测试工作也需要随着不断更新迭代的产品而逐步完善。在此过程中，测试质量的评估可能更依赖于主观或者业务的熟悉度。但是除主观判断以外，对于测试工作，我们也需要一套客观的衡量标准。
测试覆盖率这一指标就可以在一定程度上满足我们的自动化测试质量衡量需求。在实际工作中，我们可以基于功能测试以及测试工作的策划讨论，通过代码覆盖率平台去收集、分析测试的结果，再去查看真实的测试情况，相对客观地评估自动化测试水平。
四、MeterSphere 在法大大的使用情况
在 2021 年 10 月之前，法大大的部分测试团队就已开始使用 MeterSphere 开源持续测试平台。直至现在，法大大各个业务线都已经开始推广使用 MeterSphere 平台，测试覆盖率较高。
MeterSphere 开源持续测试平台在法大大的整体使用情况如下：
■ 项目数量：10+；
■ 接口数量：3000+；
■ 自动化测试脚本数量：数千个；
■ 接入用户数量：50+。
法大大的测试团队主要使用 MeterSphere 平台来进行内部业务 5.0 和 5.1 两个版本的测试工作。不同模式产品的测试团队对 MeterSphere 测试功能的要求不同：
■ SaaS 产品：对 MeterSphere 测试要求较低，主要集中在功能测试方面；
■ OpenAPI 产品：对 MeterSphere 测试要求较高。需要随接口的变动去重新组装接口脚本。同时，由于法大大电子业务对安全性的高要求，每个接口的传输有加密要求，无形中提高了我们测试工作的成本，编写脚本时经常遇到困难。
作为应对，我们用到了 MeterSphere 一个比较强大的功能——Jar 包管理。在团队自动化测试流水线中嵌入 MeterSphere 平台之后，我们依靠 MeterSphere 在前后置脚本中使用 BeanShell 引用外部 Jar 包的功能解决了这一困难。基于 MeterSphere 平台，我们可以提前准备好加密的 Jar 包，将它们上传到平台，然后在对应的脚本中直接引入需要的 Jar 包。
不过，我们在实际测试业务中也遇到了一些问题。在单个场景中，往往会有多个接口请求，而每个接口请求都需要测试人员写出对应的 BeanShell 脚本，不但过程繁琐，而且对不擅长 Java 的测试人员也不友好。
为了解决这个问题，我们将逻辑封装进了一个名叫 “Fadada Data Center” 的自用服务，然后把需要加密的核心接口全部交给这个服务去处理，让它通过设定好的函数去请求服务器。这样就可以降低对测试业务人员测试开发能力的要求，只需要测试人员对业务的逻辑理解清晰，具有接口与接口之间的参数关联能力和整个逻辑的处理能力即可。
五、后续自动化测试平台完善计划
目前法大大是用 Swagger 去管理接口文档的，之后我们计划新增一个功能，使得基于 Swagger 的接口可以自动生成对应的接口用例。这样就可以免去 URL 参数及其描述信息的填写步骤，直接初始化成功，让 MeterSphere 平台的使用成本更低，让整个自动化链路运行更加顺畅。也让测试人员可以专注于测试工作本身，而不是反复进行工具的切换等重复性的工作。
目前我们的自动化测试平台与测试覆盖率平台依然是比较分离的状态。在一般的功能测试和自动化测试结束之后，我们只能在本平台上看到测试报告，然后再去相对主观地推演测试的结果。我们希望可以将自动化测试平台与测试覆盖率平台关联起来，使得测试执行结束后即可在我们的质量平台看到自动化测试的覆盖率情况，也可以实现用例执行情况的可视化，形成更加整体化的测试工作闭环。
目前公司的性能测试工作主要使用的是 JMeter 本地工具，还没有应用测试平台工具。希望之后能将 MeterSphere 平台的性能测试模块也应用起来，创造更大的工作价值。
