パフォーマンステストプロジェクトの事例

1. プロジェクトの導入と展開

1.1 マイクロモールの機能紹介

ライトモールは電子商取引プロジェクトであり、各プロジェクトの各インターフェースの機能を総合的に評価し、最適化を提案する必要があります。

機能的なフレームワーク

• フロントデスク：ホームページ、商品ページの詳細、ショッピングカートに追加、注文、支払い、共同購入、クーポン。
• 舞台裏：商品管理、会員管理、モール管理

1.2 ライトモールプロジェクトの技術紹介

フロントエンド (目に見える部分 - HTML、JS テクノロジの実装):

• WeChat アプレット
• ウェブページ

バックエンド (目に見えない部分 - JAVA はバックエンド テクノロジ コードを通じて実装されます):

• サーバー (アプリケーションサーバー、データベースサーバー、バックグラウンドビジネスロジックコード)

1) Light Mall は、Web および WeChat ミニ プログラムのフロントエンドとバックエンドの分離をサポートするプロジェクトです。

• フロントエンドとバックエンドの分離は、フロントエンド システムとバックエンドを開発用の 2 つのサブプロジェクトに分離することとして理解できます。
• 外部パフォーマンスは次のとおりです。フロントエンドとバックエンドの分離プロジェクトのフロントエンドがリクエストを送信した後、応答コンテンツは json 文字列になります。
• フロントエンドとバックエンドが分離されていないプロジェクトの場合、レスポンスは HTML ページになります

フロントエンドとバックエンドを分離していないプロジェクトと比較して、フロントエンドとバックエンドを備えたプロジェクトは、データ送信時に基本的なデータのみ送信すればよく、HTML形式の送信が不要であるため
作業効率が高く、フロントエンドとバック
エンドの拡張性が優れています。バックエンドはデータ インターフェイスを介して分離されており、理由が変更でない限り、フロントエンド コードは追加したい機能を追加でき、バックエンド コードは独立して機能を追加することもできます。バックエンドが結合されているため、機能を追加するにはフロントエンドとフロントエンドが連携する必要があります。

2) フロントエンドは、WeChat アプレット、モバイル端末、Web ページをサポートする VUE テクノロジー フレームワークを使用して開発されています。

3) バックエンドは開発に SpringBoot フレームワークを使用し、データベースとして MySql を使用します。

4) 現在はまだ開発と改善の段階です

1.3 マイクロモールプロジェクトの技術アーキテクチャ

技術アーキテクチャ図:

1.4 データベース設計に精通している

パフォーマンス テストを行う前に、テスト対象のビジネス機能の一部に関係するデータベース テーブルについてある程度理解しておく必要があります。

1) 後でデータベースのパフォーマンスを監視しやすくするために、データベースの設計構造に精通していること。

2) パフォーマンス テスト プロセス中に、データベースにボトルネックが発生しやすくなります。

1.5 マイクロモールプロジェクトの展開プロセス

準備：

JDKのインストール

MySQL のインストール

nginxをインストールする

Node.jsをインストールする

プロジェクトの構築手順:

プロジェクト展開プロセス:

2. パフォーマンステスト要件の分析

• 機能テスト: 要件仕様書のビジネス機能に焦点を当てます (順方向および逆方向)。
• パフォーマンス テスト: システムが特定のビジネス要件シナリオ (時間、リソース) をどの程度満たしているかに焦点を当てます。
  • 懸念される次元: ビジネス機能、プロジェクト コード、サーバー、ハードウェア構成

2.1 性能要件の取得

1) 顧客からの提案（顧客は甲または製品の場合があります）

• 要件を明確に提示できるソフトウェアは、一般に、金融、銀行、通信、医療に関連する業界ソフトウェアです。
• たとえ顧客からの要求であっても、その要求の合理性を事前に判断する必要があります。

2) 履歴データ分析に基づく（ソフトウェア稼働時の稼働データに基づいて達成すべき性能指標を算出）

• 日常の活動 - 安定した負荷の予備評価
• ピーク - 圧力荷重の予備評価

2.2 新エネルギー試験点の抽出

パフォーマンス テスト ポイントの抽出ルール:

ライトモール性能テストポイント抽出：

• 1) 性能テストポイントの抽出ルールに従って、ライトモールプロジェクトの機能と組み合わせて、テストするテストポイントを分類します。
• 2) 先ほど説明した性能指標の取得方法（製品供給・稼働データの計算）により、各テストポイントが満たすべき性能指標を取得します。
• 3) パフォーマンス テストの目標を決定します。
  • 各コア ビジネス機能は、対応するパフォーマンス インデックス要件を満たす必要があります。
  • ビジネス プロセス (複数のインターフェイスの組み合わせ) に基づいて、パフォーマンス インデックスの要件が満たされているかどうかをテストします。
  • ユーザーの実際のビジネス シナリオをシミュレートし、長期安定性テストを実施します。

2.3 パフォーマンス テスト計画 (この部分は上記と重複しますが、前の部分は考え方のポイントであり、最終的にテスト計画書に実装する必要があります)

1) テストの背景

ライトモールは同社が新たに開発したECプロジェクトであり、プロジェクト立ち上げ後の安定した運営と、その後のプロモーションでのユーザー増加に耐えられるよう、プロジェクトのパフォーマンスをテストする必要がある。

2) 試験目的

• 中核的なビジネス機能の TPS を決定する
• ビジネスプロセスのストレステスト（マルチインターフェースの組み合わせ）
• このシステムは、実際のシステム動作圧力下で 24 時間安定して動作できます。
  

3) 試験範囲

4) テスト戦略:

• ベンチマーク テスト-----最初にベンチマーク テストを実行して、推定基準を決定します。
• 負荷テスト - システム負荷を徐々に増加させ、システム パフォーマンスの変化をテストし、最終的にシステムのパフォーマンス指標を満たしながらシステムが耐えられる最大負荷テストを決定します。
• それぞれ 5、10、30、50、および 100 人のユーザーをシミュレートしてシステムの負荷テストを行い、システム ソフトウェア インジケーターがさまざまな同時実行条件の下で要件を満たしているかどうかを確認します。
• 安定性テスト-----200ユーザーのシステムで7時間×24時間ノンストップの安定性テストを実施し、サーバーログに異常やエラーがないか確認します。システムの各種指標に異常な変動がないかを確認します。ソフトウェア、およびメモリ オーバーフローの問題があるかどうか。
• システムの長期的な安定性と、メモリ オーバーフローなどの問題がないかどうかを確認します。

5) リスク管理:

6) 納品リスト: スケジュールの各段階の製品に対応します。

性能試験計画、試験スクリプト、性能欠陥統計、性能試験報告書など。

7) 進捗と分業：性能試験作業はいくつかのステップに分かれており、各ステップの開始時間と終了時間と担当者が定められています。

2.4 パフォーマンス テスト ケースの作成

次のパフォーマンス テスト ケース テンプレートを参照して記述します。

• 単一のビジネス機能のパフォーマンス テストの場合、テスト ポイントごとにテスト ケースを作成します (複数のインターフェイスは強く関連しています。インターフェイスによっては、複数のインターフェイスを同じユース ケースに含めることができます)。
• 複数のビジネス機能を組み合わせてテストする場合、代表的なビジネス プロセスが選択され、ユーザーの実際のビジネス シナリオに従ってテスト ケースが作成されます。

3. パフォーマンステストスクリプトの開発

JMeter を使用してテスト スクリプトを作成し、デバッグします。

3.1 一般的に使用されるテストコンポーネント

初期化作業：

1) テストケース構造の作成

注: スレッド グループは、リクエストの数に関係なく、ユースケースです。

2) HTTP リクエストのデフォルト値を設定する

3) ユーザー定義変数

4) リスナーを追加します - 結果ツリーを表示します

5) リスナーの追加 - 集計レポート

3.2 スクリプトの作成

3.2.1 ログインスクリプト

アサーション: ステータス コード、errmsg

インターフェイスのテストを行う場合は、応答でビジネス データをアサートする必要があり、ステータス コードと説明情報を追加できます。

パフォーマンス テストを行っている場合は、ステータス コードと説明情報アサーションのみを追加できます。

3.2.2 ホームページデータの取得

3.2.3 製品を検索する

URL のパラメーターが中国語の場合は、次のリストにパラメーターを記述することをお勧めします。

アサーション: ステータス コード、errmsg

インターフェイス テスト スクリプトの場合は、応答内の項目の数についてアサーションを行う必要があります。

3.2.4 製品の詳細を表示する

アサーション: ステータス コード、errmsg

インターフェイス テスト スクリプトの場合は、応答内の製品の詳細についてアサーションを行う必要があります。

3.2.5 カートに追加

リクエストの追加 1 – ログイン

json エクストラクターを追加します。

リクエストの追加 2 – カートに追加

アサーションの追加: ステータス コード、errmsg

インターフェイス テスト スクリプトの場合は、ショッピング カートに再度クエリを実行して、ショッピング カートから返されたデータが、ショッピング カートに追加して返されたデータと一致するかどうかを確認する必要があります。つまり、別のリクエストを追加する必要があります。

3.2.6 ショッピングカートを表示する

リクエスト: まずログインリクエストを送信し、トークン情報を抽出し、ショッピングカートを表示し、トークン情報を X-litemall-Token ヘッダーフィールドに割り当て、リクエストパスとパラメータを入力します。

3.2.7 注文の送信

注文の送信: 1) 最初にログインしてトークン情報を抽出するリクエストを送信します; 2) 決済リクエストを追加し、X-litemall-token ヘッダー フィールドにトークン情報を割り当て、パス リクエストとパラメータを入力します; 3)注文リクエストを追加し、トークン情報を X-litemall-token ヘッダー フィールドに割り当て、パス リクエストとパラメータを入力します (アドレスと ID はユーザー ID と一致する必要があることに注意してください)

応答：

ステータスコード; errmsg

スクリプトがインターフェイス テスト スクリプトの場合、応答メッセージ内の注文データがデータベース内の注文テーブル内の注文数と一致していることをアサートする必要があります。

3.2.8 注文の表示

スクリプトの作成プロセスでは、一般的に使用される静的データをユーザー定義変数に書き込み、スクリプトの実行時に参照できます。利点は、後でデータを変更しない場合、各スクリプトにアクセスすることなく変数を直接変更できることです。変更を加える。

3.2.9 ビジネスプロセススクリプト

ユースケースは複雑であるように見えますが、単一のインターフェイス スクリプトが記述されており、直接組み合わせることができるため、スクリプトの作成は簡単です。

最後に、私の学習教材の一部を共有したいと思います:

上記のコンテンツは、ソフトウェア テストの友人にとって最も包括的で完全な準備倉庫となるはずです。各モジュールをより適切に整理するために、多くの高品質のブログ投稿も参照しました。インターネット上でのプロジェクトやプロジェクトで、すべての知識ポイントを見逃さないように努めています。多くの友人がこれらのコンテンツを参考にしてレビューし、BATJ などの大手メーカーからオファーを獲得しました。この倉庫は多くのソフトウェア テスト学習者にも役立ちました。あなたにもお役に立てれば幸いです。 . .

以下の WeChat 公式アカウントをフォローして無料で入手してください! ↓ ↓ ↓ ↓ ↓