目次
序文
現在、フルリンクの人気が高まっているため、大手メーカーも独自のフルリンク ストレス テスト ソリューションを発売しています。特にフルリンク圧力テストのトラフィック モデルの場合、それぞれのソリューションが異なります。最近、この点に関する資料をいくつか読みましたが、いくつかの洞察が得られました。みんなと共有しましょう。
フルリンク ストレス テストのトラフィック モデルの精査についてはここでは説明しません。各企業には独自の状況があります。これは主にフルリンク ストレス テスト モデルの実現であるため、実際には、その実現はトラフィック モデルの結合結果にも対応します。
業界では 3 つの一般的な方法が使用されています。1 つはビジネス モデルに基づく方法、もう 1 つは実際のトラフィックに基づく記録と再生、最後はグレースケール配信です。
ビジネスモデルに基づいた実現
これはより一般的な方法です。まず、企業のビジネスモデル、つまり企業のビジネスリンクを整理する必要があります。ここでのビジネス リンクはさらに複雑になる可能性があり、多くの場合のように非常に人気のあるスムーズなリンクではなく、途中にさまざまな分岐がある可能性があります。グラフをグラフィカルに表示する場合、あるリンクはツリー構造になっているはずです。ツリー構造の先頭はユーザーのエントリ ページで、通常はエントリ ページのログイン ページ、またはホームページ インターフェイスです。四次構造の右側はユーザーの出口であり、さまざまなビジネス モデルに応じて多数のユーザーの出口が存在するため、ほとんどの場合、これは分岐したツリー構造になります。
このようなトラフィック モデルを実装するには。のほうが難しいです。まず、このようなビジネス モデルを整理するのは簡単ではなく、インターフェイスの相互呼び出しと相まって、データ間の相互依存により複雑さが桁違いに増加する可能性があります。したがって、それを達成するための一般的な方法は、一緒に行うことです。より複雑なツリー構造を単純化するか、ビジネス接続をリストされた n 個のリンクに単純に分解します。次に、それらを個別に実装します。最後に、トラフィックの集約により、サービス リンク全体のトラフィック モデルが実現されます。
ビジネスモデルの実装の方向性は各社で実装方法が異なり、大きく分けてツール実装とスクリプト実装に分かれます。私はインターフェイスのパフォーマンス テストを行うためのツールは使用しません。すべてのテストは Java および Groovy スクリプトを使用して実装されます。まず、インターフェイス ベースのビジネス テスト フレームワークを実装し、各インターフェイスをメソッドにカプセル化します。インターフェイスのパラメータは、このメソッドのパラメータです。次に、各ユーザーをオブジェクトにカプセル化します。さまざまなユーザー情報をこのオブジェクトの属性に変換します。次に、ユーザーはさまざまなインターフェイスをリクエストするときにユーザーの属性に値を割り当て、パラメーターを渡すという目的を達成します。次に、さまざまなメソッドを呼び出すことで、さまざまなインターフェイスに対するリクエストを実装できます。パラメータやインターフェースリクエストの頻度を制御することで、現在のユーザーを制御できます。ビジネスチェーン全体の方向性。
トラフィックに応じた録画と再生
トラフィックの記録と再生に基づいて、これが最も簡単に実装できる方法です。それは実際の状況に近づく最も簡単な方法でもあります。ああ、私が接した主な再生モデルは goreply で golang 言語で書かれています。Go 言語のパフォーマンスは非常に優れており、パフォーマンス テストに対するユーザーのニーズを満たすのに十分です。ほとんどの企業は、ネイティブ エンジンに基づいてカプセル化を行うことを選択します。次に、ビジネスとの互換性を確保します。最も重要なことは、トラフィック ソースを適応させることです。通常、トラフィックのソースはログ ファイルを通じて取得されますが、業界にはそれを完了するための固定トラフィック ストレージおよび分析エンジンもいくつかあると思います。私はここのテクノロジーにはあまり詳しくないので、これ以上は共有しません。
トラフィックに基づいて録画および再生するこのモードには、トラフィックが見えないという比較的解決が難しい問題があると思います。一般に、録音トラフィックは非常に多くなります。数十万から数百万の間。これほど大規模な交通量がある彼を想像することは困難です。多くの場合、リクエスト量が非常に少ない一部のインターフェイスで問題が発生します。録音中に消失する可能性があります。もう 1 つは、トラフィックを記録する時間範囲が広すぎないことです。この場合、記録されたトラフィック ファイルには、記録時のトラフィック モデルのみが反映され、他の記録期間のトラフィック モデルは反映されません。サービスのトラフィックが時間に応じて変化する場合。次に、複数の期間のトラフィックを記録し、それらを結合する必要があります。トラフィックは目に見えないため、トラフィック モデルの分析は困難になります。
グレーの分割
これは、ある偉い人がカンファレンスで共有しているのを見た計画です。グレースケール グレースケールのリリースについて詳しく聞くかもしれません。これは、サービスまたはアプリのアップデートの範囲を特定の人々のグループまたは特定の地理的エリアに制限することです。ここで説明したグレースケール配布は、オンライン トラフィックの一部を特定のマシンに転送するというコア部分では実際に似ています。これらのマシンのサービスに対していくつかの圧力テストを実施するため。このスキーム。オンライン トラフィックに基づいて行われるため、テストはほとんど必要ありません。開発と実装に多大なリソースを投資しすぎている。この種のソリューションは、ビジネス モデルにある程度基づいており、中間状態を把握するためのトラフィック記録に基づいています。フローの真の正当性を保証できるだけではありません。また、テスト スクリプトの開発の負担も回避できます。
この方法は、企業の構造、マスター、またはディストリビューションを実現するのに比較的技術的な難易度が高くなります。ユーザーの実データをすべて使用するため、一度問題が発生すると、問題の範囲を制御できなくなり、より深刻になります。グレースケール分割トラフィックを受信するマシンの場合、圧力測定トラフィックは完全に本物です。しかし、トラフィックに基づいた録音と再生という同じ問題を避けることはできません。つまり、交通量が目に見えないことと、交通量と時間の関係が線形ではないということです。この時点でのトラフィックのグレースケール分布でさえ、トラフィックの記録と再生ほど良好ではありません。私もそう思います。私が接触した企業には、このソリューションを採用する理由がありません。
要約:
私の記事を注意深く読んでくださった皆さん、ありがとうございました！！！
私は過去数年間のソフトウェア テストのキャリアでまとめたいくつかの技術資料を個人的に整理しました。これには、電子書籍、履歴書モジュール、さまざまなジョブ テンプレート、インタビュー ブック、独習プロジェクトなどが含まれます。どなたでもコメントエリア 333 にメッセージを残していただくか、個人的に受け取っていただけます。
