BitXHub は、Qulian Technology が独自に開発したクロスチェーン テクノロジー プラットフォームで、異種アライアンス チェーンに基づく相互運用性ソリューションを提供します。毎日の反復プロセスにおける BitXHub クロスチェーン プラットフォームの機能がユーザーのニーズを満たしていることを確認し、リリースまたは配信前にできるだけ多くの問題を見つけて修正するために、Premo テスト ツールが誕生しました。 Premo は主に BitXHub 独自の gosdk に基づいて実装されており、拡張と保守が簡単です。この記事では、機能テスト、パフォーマンス テスト、自動テストの 3 つの側面に主に焦点を当て、Premo のテスト フレームワークの概要を説明します。

【アーキテクチャ概要】

Premo テスト フレームワークを次の図に示します。テスト系の内容は主に「機能テスト」と「パフォーマンステスト」に分かれます。機能テストは主に、gosdk の実装と BitXHub クロスチェーン プラットフォームの通信と呼び出しに基づいて、全体的なテスト フレームワークを実現するためのテストとテストに基づいており、パフォーマンス テストは主に gosdk に基づいたコルーチンを通じて実現されます。 Premo はさらに機能テストに基づいて継続的統合テストを実装しており、継続的統合テストの部分は主に GitHub Actions で実装されます。

【機能テスト】

機能テスト モジュールは、主に BitXHub プロジェクト独自の gosdk、testify オープン ソース ライブラリ、およびテスト ライブラリによって実装されます。機能テスト モジュールは、テストの機能ポイントに応じて複数のテスト ファイルに分割されています。各テスト ファイル内のテスト ケースは、テスト スイートに含まれています。日常のテストでは、必要な機能ポイントに基づいて異なるスイートを実行できます。図に示すように、次のようにテストします。たとえば、model1001_chain_test.go のすべてのテスト ケースは、model1 スイートに含まれており、チェーン関連のテスト ケースを実行する必要がある場合は、model1 スイートを実行するだけで済みます。

▲並列化テスト

プロジェクトの継続的な拡大に伴い、テスト ケースの数も増加し、完全なテスト ケースに戻るまでにかかる時間はますます長くなり、逐次テストの方法は、迅速な反復ではますます非効率になってきています。バージョン開発。並列テストはこの問題を効果的に解決できますが、これにより、テスト ケース間の結合という新しい問題が発生します。多くのユースケースでは、シリアル テストのプロセスでは問題が明らかになりませんが、並列テストが実行されると、同時実行の問題が発生します。

BitXHub クロスチェーン プラットフォームを例に挙げると、BitXHub クロスチェーン プラットフォームは、クロスチェーン トランザクションの秩序性を実現するために、クロスチェーン トランザクションを受信する過程でアカウント アドレスに応じてノンス値を維持します。トランザクションを受信するたびに増加します 1. 受信したノンス値が期待されるノンス値より小さい場合、BitXHub クロスチェーン プラットフォームはトランザクションを破棄します。逆に、期待されるノンス値より大きい場合、BitXHub クロスチェーン プラットフォームはトランザクションを破棄します。クロスチェーン プラットフォームは、ノンスが期待値に達するまでトランザクションを一時的に保存します。これには、並列テスト ケースでノンス値を人為的に維持する必要があります。したがって、並列テストで非常に重要な点は、ユースケース間の相対的な独立性を維持する必要があることであり、ユースケースの相対的な独立性をどのように維持するかは、プロジェクト自体のローカル条件に適応させる必要があります。

【性能試験】

クロスチェーンサービスシステムの信頼性と安定性を測る重要なポイントは、クロスチェーン自体のパフォーマンス指標です。上記の要件に基づいて、Premo は BitXHub 独自の gosdk に基づくパフォーマンス テスト ソリューションの完全なセットを実装し、BitXHub クロスチェーン プラットフォームのパフォーマンスが要件を満たしているかどうかを検証しました。 Premo のパフォーマンス テストは主にストレス テストであり、多数のクロスチェーン トランザクションを BitXHub クロスチェーン プラットフォームに送信することにより、クロスチェーン トランザクションの処理における BitXHub のパフォーマンスを検証します。全体的なパフォーマンス テストは主に、アプリケーション チェーンの準備、クロスチェーン トランザクションの送信、TPS のカウントの 3 つのステップに分かれています。

▲ アプリケーションチェーンの準備

クロスチェーン トランザクションを送信する前に、Premo がこれらのアプリケーション チェーンの ID を使用してクロスチェーン トランザクションをリレーに送信できるように、さまざまなトランザクション タイプに応じて一定数のアプリケーション チェーンをリレー チェーンに事前登録する必要があります。 SDK を介してチェーンします。アプリケーション チェーンが正常に登録された後、対応する検証ルールを展開して、リレー チェーン内のトランザクションの有効性を検証する必要があります。

▲クロスチェーントランザクションの送信

事前設定された TPS とアプリケーション チェーンの数に従って、アプリケーション チェーンが 1 秒以内に BitXHub クロスチェーン プラットフォームに送信する必要があるクロスチェーン トランザクションの数を計算できます。事前に設定されたトランザクション タイプは、対応するトランザクション本体を構築できます。クロスチェーントランザクションの秩序ある要件により、トランザクション本体内の各クロスチェーントランザクションのノンス値を維持する必要があることに注意してください。同時に、クロスチェーン トランザクションをより均等に送信するために、Premo は 50 ミリ秒ごとにいくつかのクロスチェーン トランザクションを BitXHub クロスチェーン プラットフォームに送信します。たとえば、合計 2000 のアプリケーション チェーンを送信するには、Premo は 20 のアプリケーション チェーンをシミュレートする必要があります。 1 秒あたりのクロスチェーン トランザクション: アプリケーション チェーンは 1 秒以内に 100 件のクロスチェーン トランザクションを送信する必要があり、各アプリケーション チェーンは 50 ミリ秒ごとに 5 つのクロスチェーン トランザクションを送信します。

▲統計TPS

統計的 TPS は、BitXHub クロスチェーン プラットフォームでブロック イベントをサブスクライブすることで実現されます。ブロック イベントをサブスクライブした後、BitXHub クロスチェーン プラットフォームによって発行された各ブロックが Premo にプッシュされます。Premo は、ブロック内のトランザクション数をカウントして TPS を計算します。各トランザクションの遅延 = ブロックを受信する時間 - トランザクション時間こする。 Premo は、上記の情報に基づいて、TPS と 1 秒あたりの平均トランザクション レイテンシーを出力します。

【自動テスト】

自動テストの主な機能は、ブランチがマスター ブランチまたはリリース* ブランチに昇格されるときに、全機能テスト ケースのテストを完了し、同時にテスト結果に従って対応するテスト レポートを生成することです。テストレポートをサーバーフォームに公開して、PR の送信者に通知します。

▲コマンドを作成

Premo は機能テストを make コマンドに追加し、完全な機能テストを make コマンドを通じて実行できます。同時に、make コマンドはテスト結果に従って対応するテスト レポートを生成します。

▲GitHubActions

文章

▲allure-server

GitHub 上のオープン ソース Allure Report Server は、GitHub Actions を介したテスト レポートの公開をサポートし、allure-server は Docker をサポートします。

「上記にはやるべきことがたくさんあります。少しずつ分析していきます。」

(1) PR に応じたトリガーアクション:

詳細については、公式ドキュメントの関連する章「Github アクションのワークフローをトリガーするイベント」を参照してください。

(2) 目的分岐機能テストによると、

アクションでは、ターゲット ブランチ名を取得できます。Premo のテスト ケースは BitXHub クロスチェーン プラットフォームのバージョンに従って維持されるため、機能テストの場合はターゲット ブランチ名に従って Premo をプルするだけで済みます。

(3) リリーステストレポート:

テスト レポートの公開は主に、前述した allure-server を通じて行われます。注意点としては、allure-serverに対応するサーバーのアドレスを公開しないとサーバーが不安定になるため、ウェアハウスの[設定]で[シークレット]を設定することで解決できます。

(4) メール通知:

GitHub Actions では電子メール通知が一般的です。対応するアクションを使用するだけです。使用されるSMTPの形式により、メールボックスのアカウント番号とパスワードは公開できないことに注意してください。この問題は、倉庫の[設定]で[シークレット]を設定することで解決できます。電子メール通知のプロセスでは、宛先電子メールのアカウント パスワードを知る必要があり、電子メールで SMTP サービスを有効にする必要もあります。この場合、PR 送信者の電子メールをアクション。

適切な解決策は、メールボックス自体の送受信ルールを使用することです。 Tencent Enterprise Mailbox を例に挙げると、メールボックスは電子メールの内容に基づいた自動転送をサポートしています。送信者の Github 名 (またはその他の ID 情報) を電子メールに含める必要があるだけで、その名前に基づいて送受信ルールがフィルターされ、電子メールが PR 送信者に自動的に転送されます。上記の方法により、アクション内で異なる PR 送信者に応じて異なる電子メール アドレスを指定する必要はなく、電子メールを送信するだけで済みます。"乗り換え駅"それでおしまい。

上記の作業を完了した後は、BitXHub のブランチに従って Premo 機能のテスト ケースをメンテナンスするだけで、対応する自動テストを完了できます。具体的なプロセスを次の図に示します。

文章

著者について

著者について

朱偉傑

FunChain テクノロジー データグリッド ラボ BitXHub チーム