Premo 测试框架详解

BitXHub 是趣链科技自主研发的跨链技术平台，提供基于异构联盟链间的账本互操作解决方案。为保证 BitXHub 跨链平台在日常迭代过程中的功能符合用户需求，并尽可能多的把问题在发布或交付之前发现并改正，Premo 测试工具应运而生。Premo 主要基于 BitXHub 自身的 gosdk 实现，具有易于扩展和维护的特点。本文主要围绕功能测试、性能测试以及自动化测试三个方面来概述 Premo 的测试框架。

【架构总览】

Premo 测试框架如下图所示。基于测试的内容主要分为「功能测试」和「性能测试」。功能测试主要基于 testing 和 testify 实现整体测试框架，基于 gosdk 实现和 BitXHub 跨链平台的通信和调用；性能测试主要是在 gosdk 的基础上通过协程实现。Premo 在功能测试的基础上又进一步实现了持续集成测试，持续集成测试部分主要借助 GitHub Actions 实现。

【功能测试】

功能测试模块主要依托于 BitXHub 项目自身的 gosdk，testify 开源库和 testing 库实现。功能测试模块根据测试的功能点分为多个测试文件，每一个测试文件内的测试用例都包含于一个测试套件中，在日常测试可以基于你所需要测试的功能点来运行不同的套件，如下图所示。例如 model1001_chain_test.go 内的所有测试用例都包含在 model1 这个套件中，如果需要运行 chain 相关的测试用例只需运行 model1 的套件即可。

▲并行化测试

随着项目的不断扩展，测试用例的数目也在不断增加，回归全量测试用例所消耗的时间也越来越长，顺序测试的方法在快速迭代的版本开发中显得越来越低效。采用并行化测试可以有效解决这个问题，然而这又会引入一个新的问题，也就是测试用例之间的耦合性。很多用例在串行测试的过程中不会暴露问题，一旦进行并行化测试就会出现并发上的问题。

以 BitXHub 跨链平台为例，BitXHub 跨链平台在接收跨链交易的过程中会根据账户地址维护一个 nonce 值用于实现跨链交易的有序性，每收到一笔交易 nonce 值就会增加 1，如果收到的 nonce 值小于预期的 nonce 值，BitXHub 跨链平台就会丢掉这笔交易，反之，如果大于预期的 nonce，BitXHub 跨链平台就会暂存这笔交易，直至 nonce 达到预期。这就会要求我们在并行化测试的用例中人为的去维护这个 nonce 值。因此，并行化测试中很重要的一点就是需要维护用例之间的相对独立性，如何维护用例的相对独立性则需要根据项目自身因地制宜。

【性能测试】

衡量一个跨链服务系统是否可靠稳定很重要的一点便是跨链自身的性能指标。Premo 根据上述需求，基于 BitXHub 自身的 gosdk 实现了一套完整的性能测试方案用于检验 BitXHub 跨链平台的性能是否满足需求。Premo 中进行的性能测试主要是压力测试，通过向 BitXHub 跨链平台发送大量的跨链交易来验证 BitXHub 处理跨链交易的性能。整体性能测试主要分 3 个步骤进行，分别是应用链准备、发送跨链交易和统计 TPS。

▲应用链准备

在发送跨链交易前，需要预先根据不同的交易类型注册一定数量的应用链到中继链，以便后续 Premo 通过 SDK 使用这些应用链的身份向中继链发送跨链交易。应用链注册成功后还需要部署相应的验证规则，用于中继链验证交易的有效性。

▲发送跨链交易

根据预先设定的 TPS 和应用链数量可以计算出一条应用链在一秒内需要向 BitXHub 跨链平台发送的跨链交易数量。预先设定的交易类型可以构造出对应的交易体。注意由于跨链交易的有序性要求，我们需要在交易体中维护每一条跨链交易的 nonce 值。同时为了更加均匀的发送跨链交易，每隔 50ms，Premo 就会发送部分跨链交易到 BitXHub 跨链平台上，例如 Premo 需要模拟 20 条应用链每秒总共发送 2000 条跨链交易，那么每条应用链需要在 1 秒内发送 100 条跨链交易，每 50ms 每条应用链就会发送 5 条跨链交易。

▲统计 TPS

统计 TPS 是通过订阅 BitXHub 跨链平台的区块事件实现。订阅区块事件后，BitXHub 跨链平台每出一个块就会推送到 Premo 中，Premo 通过统计区块内的交易数量来计算 TPS，每笔交易的延时 = 收到区块的时间搓 - 交易的时间搓。Premo 根据上述信息每秒打印 TPS 和交易的平均延时。

【自动化测试】

自动化测试主要实现的功能是在任意一个分支提 PR 到 master 分支或者 release*分支时，完成全量功能测试用例的测试，同时根据测试结果生成相应的测试报告，并将测试报告发布到服务器，通过邮箱的形式通知 PR 的提交者。

▲Make 命令

Premo 将功能测试加入 make 命令中，通过 make 命令就能进行全量的功能测试。同时 make 命令根据测试的结果生成相应的测试报告。

▲GitHubActions

GitHub Actions 是 GitHub 的持续集成服务。在任意一个分支提 PR 到 master 分支或者 release*分支时会触发对应的 action，action 将根据目的分支名拉取对应的 Premo 分支进行功能测试，同时将成的测试报告发布到指定的服务器上，并将测试报告的连接通过邮件的形式发送给 PR 的提交者。

▲allure-server

GitHub 上开源的 Allure Report Server，支持通过 GitHub Actions 的方式发布测试报告，并且 allure-server 支持 docker。

「上述需要进行的工作较多，我们可以一点一点解析」

（1）根据 PR 触发 action：

具体参考 github actions 的官方文档 Eventsthat trigger workflows 相关章节；

（2）根据目的分支功能测试：

在 action 中我们可以获取目的分支名，Premo 的测试用例是根据 BitXHub 跨链平台的版本维护的，所以只需根据目的分支名拉取 Premo 进行功能测试即可；

（3）发布测试报告：

发布测试报告主要通过 allure-server 进行，allure-server 在上文已经提过。需要注意的一点是 allure-server 对应的服务器的地址不能暴露，否则会给服务器带来不稳定因素，通过仓库[Setting]中设置[Secrets]来可以解决这个问题；

（4）邮箱通知：

邮件通知在 GitHub Actions 中较为常见，使用对应的 action 即可。需要注意是由于使用的 SMTP 的形式所以邮箱的账号和密码不能公开。通过仓库[Setting]中设置[Secrets]可以解决这个问题。在邮箱通知的过程中需要知道目的邮箱的账目密码，同时还需要邮箱开启 SMTP 服务，这种情况下在 action 中配置 PR 提交者的邮箱变的不可取。

一个合适的解决方式是：通过邮箱自身的收发信规则。以腾讯企业邮箱为例，邮箱支持根据邮件的内容进行自动转发。我们只需要在邮件中携带提交者的 github 的名称（或者其他身份信息），收发信规则根据名称过滤，将邮件自动转发给 PR 提交者。通过上述方式在 action 中不需要根据不同的 PR 提交者指定不同的邮箱地址，只需要将邮件发送给"中转站"即可。

完成上述工作后，只需要根据 BitXHub 的分支维护 Premo 功能测试用例即可完成相应的自动化测试。具体流程如下图所示：

【总结】

本文介绍了 BitXHub 官方测试框架 Premo 的基本设计原理和测试模块，及功能测试和性能测试的重要实现方法。通过 Github Actions 的编排，Premo 可以较好地对 BitXHub 的功能模块实现自动化并行测试，并及时反馈测试结果。

如想进一步了解 Premo 测试框架的详细实现，可访问项目地址或联系小助手桔子（18458407117）加入技术交流群，获取更多资料。

地址：https://github.com/meshplus/premo

作者简介

祝炜洁

趣链科技数据网格实验室 BitXHub 团队