継続的テストは、すべての品質特性に関わるテスト活動を含むテスト実践です。したがって、継続的テストには非機能テストも含まれます。ご存知のとおり、ソフトウェアの品質特性には、機能性、信頼性、使いやすさ、効率性などが含まれます。継続テストにおける機能実装方法についてはすでにいくつか紹介しましたが、次に、継続テストにおける非機能テストについて説明します。
性能試験
パフォーマンス テストは、おそらくテスト エンジニアなら誰でもよく知っている用語であり、パフォーマンス テストの実行方法については説明できる人も多いと思いますが、パフォーマンス テストが何なのかについては、定義を与えるのは困難です。パフォーマンス テストは全体的な概念であり、特定の制約の下でテスト システムが耐えることができる同時ユーザーの数を指します。ここでの制約とは、テスト対象のシステムの動作に必要なソフトウェア、ハードウェア、ネットワークなどの外部制約を指します。
パフォーマンス テストには、負荷テスト、ストレス テスト、限界テスト、容量テストなどの概念も含まれます。これらの概念は絡み合っており、業界で一般的に受け入れられている定義はありません。
実際、負荷テストは、実際のソフトウェア システムが負担する負荷条件をシミュレートするテストです。ストレス テストは、予想される負荷以上でシステムがどのように動作するかを評価するために使用されます。制限テストはストレス テストに似ており、容量テストは負荷テストに似ています。ただし、これらは概念的な分類にすぎず、テスト プロセス中に負荷テストとストレス テストを明確に区別することは困難です。
実際の作業では、パフォーマンス テスト、ストレス テスト、負荷テストは、負荷テストという 1 つのことを指すことがよくあります。したがって、仕事では、上記の概念に言及した場合、他の前提条件がない限り、負荷テストに従って準備することができます。
継続的テストは、スムーズで継続的な製品配信プロセスに傾いているため、パフォーマンス テストでは、DevOps パイプラインの双方向駆動パフォーマンス テスト テクノロジのアプリケーション プラクティス、特にコード テクノロジとしてのパフォーマンス テストの実装に傾いています。
パフォーマンス テスト ツールの概要
パフォーマンス テストは、高同時アクセスをシミュレートすることによって行われます。このシミュレーションは、実際には複数のユーザーが同時にシステムにアクセスするのではなく、ツールを使用して行われます。高い同時実行性をシミュレートするパフォーマンス テスト ツールには、マルチプロセス、マルチスレッド、コルーチンという 3 つのモードがあります。プロセス、スレッド、コルーチンの関係を図 3-1 に示します。
プロセスは CPU リソースをより有効に活用するために定義され、システム リソースの割り当てとタスクの識別に使用されます。プロセスはシステム リソース割り当ての最小単位であり、主にアドレス空間、グローバル変数、ファイル記述、ハードウェアなどのリソースを占有します。オペレーティング システムは、システム リソースを最大限に活用できるように、マルチプロセス方式で複数のタスクを完了します。
現在主流の性能テストツールの中で、LoadRunnerはマルチプロセスに対応していますが、このツールの認可料は非常に高価です。さらに、マルチプロセス モードはより多くのシステム リソースを占有し、プロセス間のスケジューリング オーバーヘッドが比較的大きいため、パフォーマンス テストでマルチプロセス モードを使用することはお勧めできません。
スレッドは異なります。スレッドはコンテキスト切り替えの消費を削減し、システムの同時実行性を向上させます。スレッドは自動車生産工場における複数の生産ラインのようなもので、各生産ラインは同じトランザクション作業を同時に処理します。1 つのプロセス内で複数のスレッドを起動して同じロジックを処理すると、同時処理の効果が得られます。LoadRunner と JMeter はどちらもマルチスレッド同時アクセス モデルをサポートしており、そのうちの JMeter はオープンソースのパフォーマンス テスト ツールです。
パフォーマンス テストのプロセスでは、同時アクセスをシミュレートするためにマルチスレッド モデルがよく使用されます。これにより、同時アクセスが完了し、システム リソースが最大限に活用されます。コルーチンは比較的新しい概念で、CPU ではなくユーザー制御を通じてスケジューリングを完了するため、カーネル レベルでのコンテキストの切り替えによるリソースの消費を回避し、I/O のスレッドのパフォーマンスのボトルネックを突破します。コルーチンはマルチスレッドのロック機構を必要とせず、スケジューリングはスレッドに基づいて実装されます。
Locust は、コルーチン アクセス モデルに基づいたパフォーマンス テスト ツールです。パフォーマンス テストに携わっている読者の多くは LoadRunner について聞いたことがあるはずですが、Locust について知っている人は少ないでしょう。これら 2 つのツールにはそれぞれ利点があり、実際のプロジェクトではどちらを選択するかは状況によって異なります。
しかし、現在のコンテナ化テクノロジーの時代では、LoadRunner はあまり役に立たなくなりました。LoadRunnerとLocustはどちらもUIスクリプトの編集や記録、シーン設定などの機能を提供しているため、コンテナ上で利用する場合は同時シミュレーションのみとなり、スクリプトの記述はクライアントPC上で完了する必要があります。コンテナ上のパフォーマンステストツールとしては、以下の機能があれば幸いです。
PC 上でのスクリプト編集とデバッグをサポートします。
コンテナ上でのスクリプト編集とデバッグをサポートします。
サーバー側でのパフォーマンス テストのサポート。
サーバー側の性能シナリオ設定機能を備えています。
サーバー側のUIを必要としないシーン設定機能を備えています。
CI（継続的インテグレーション）システムとの連携が可能です。
要約すると、Locust は強くお勧めします。コンテナに使用しない場合でも、Locust は良い選択です。Locust は、ユーザーの動作を定義するための Python コードの使用をサポートし、純粋な Python を使用してテスト スクリプトを記述するオープンソースのパフォーマンス テスト ツールです。
Locust を使用して、システムにアクセスする何百万もの同時ユーザーをシミュレートします。HTTP/HTTPS に加えて、Locust は他のプロトコルを使用するシステムのテストにも使用できます。Python を使用して対応するライブラリを呼び出し、リクエストを記述するだけです。
Locust は、Web サイトやその他のシステムの負荷テストに使用できる分散ユーザー負荷テスト ツールでもあります。Locust を使用すると、システムで同時に処理されるユーザーの数をテストできます。これは完全に時間ベースであるため、1 台のマシンで数千の同時ユーザーをサポートできます。
プロセスとスレッドを使用する LoadRunner やその他のテスト ツールでは、単一マシン上で高い同時実行負荷をシミュレートすることは困難です。他の多くのイベント駆動型アプリケーションと比較して、Locust はコールバックを使用せず、軽量の処理メソッドであるコルーチンを使用します。
コルーチンは、ユーザーによって制御されるユーザー モードの軽量スレッドです。コルーチンには独自のレジスタ コンテキストとスタックがあり、切り替えの進行中、コルーチンはレジスタ コンテキストとスタックを他の場所に保存します。スイッチバックすると、コルーチンは保存されたコンテンツを復元してカーネル切り替えの消費を削減できるだけでなく、ロックせずにグローバル変数にアクセスすることもできます。コルーチンはシステムレベルのリソースのスケジューリングを回避するため、単一マシンの同時実行能力が大幅に向上します。
GB/T 25000.10 の 8 つの品質特性のうち、パフォーマンス効率の独立した品質特性には、時間特性、リソース使用率、容量、パフォーマンス効率の準拠などの品質サブ特性が含まれます。技術的手段を使用して情報システムのパフォーマンス効率をテストするプロセスは、パフォーマンス テストと呼ばれます。パフォーマンス テストにより、情報システムがパフォーマンス効率の要件をどの程度満たしているかを評価できます。情報システムには通常、次の側面に関する情報が含まれています。
同時ユーザー数: これはサーバーに関するもので、同時にサーバーと対話するオンライン ユーザーの数を指します。ストレス テスト中の同時ユーザー数とは、1 つまたは一連の操作を同時に実行するユーザーの数、または特定のスクリプトを同時に実行するユーザーの数を指します。同時実行の状況はシナリオによって異なりますので、実際のテスト作業では、特定の要件に応じて同時ユーザーの数を設定する必要があります。
同時ユーザーの最大数: 情報システムの最大サービス能力を表すために使用されます。
スループット: システムが単位時間あたりに処理できるリクエストの数。対話型システムの場合、スループットの単位は通常、バイト/秒、ページ/秒、またはリクエスト/秒です。非対話型システムの場合、スループットの単位は通常、トランザクション/秒です。
応答時間: ユーザーの応答時間とシステムの応答時間に分けられます。ユーザー応答時間とは、ユーザーがその操作に対して認識できるシステムの応答時間を指します。人間の目は、「視覚の持続」現象により 0.1 秒を超える視覚変化しか検出できないため、ユーザーの応答時間は 0.1 秒以内で十分です。システム応答時間は、コンピュータがユーザーの入力または要求に応答するまでにかかる時間です。ストレス テストでは通常、ユーザーの観点から問題を考慮するため、ユーザーの応答時間を測定します。
リソース使用率: テスト対象サーバーの CPU 使用率、メモリ使用率、ディスク I/O 速度、ネットワーク スループットなど、情報システムのパフォーマンス ステータスを表す一連のデータ インジケーター。
待ち時間: 情報システム利用者が業務を実行する際に発行する連続した 2 つのリクエスト間の時間間隔。
パフォーマンス テストは、システムの保守性を評価するために使用されます。性能試験は主に以下の3種類に分かれます。
負荷ストレス テスト: システムに負荷を継続的に加えることにより、システムのパフォーマンスの変化を観察し、システムが一連のパフォーマンス指標 (応答時間、CPU 使用率、メモリ使用量、ネットワーク スループット、ディスク I/O 速度、主要なパフォーマンス指標は、応答時間、CPU 使用率、メモリ使用率を前提として維持できる最大負荷です。
障害回復テスト: システムの冗長性バックアップまたは負荷分散メカニズムを提供するシステムの場合、シミュレートされたシステムの部分的な障害の後、多数のユーザーがシステムにアクセスし続けた場合に、システム サービス機能の回復がテストされます。主にシステムの堅牢性と回復可能性を評価するために使用されます。
疲労試験：総業務量を確保した条件でシステムを長時間稼働させる試験で、主にシステムが故障せずに長時間安定して動作する能力を評価するために使用されます（試験期間は通常7×24です）時間、3×24時間、または1×24時間）。
最後に、私の記事を注意深く読んでくださった皆さんに感謝します。互恵性は常に必要です。それはそれほど価値のあるものではありませんが、必要な場合はそれを取り上げることができます。
ソフトウェアテストインタビューアプレット
ソフトウェア テストの質問バンクには、何百万人もの人が参加しました。！！誰が知っているのか！！！ネットワーク全体で最も包括的なクイズ ミニ プログラムです。携帯電話を使用して、地下鉄やバスの中でもクイズに答えることができます。
次の面接の質問セクションが取り上げられます。
1. ソフトウェアテストの基礎理論、2. Web、アプリ、インターフェース機能テスト、3. ネットワーク、4. データベース、5. Linux
6. Web、アプリ、インターフェイスの自動化、7. パフォーマンス テスト、8. プログラミングの基本、9. 時間面接の質問、10. 公開テストの質問、11. セキュリティ テスト、12. コンピューターの基本
これらの資料は、[ソフトウェア テスト] の友人にとって最も包括的で完全な準備倉庫となるはずです。この倉庫は、最も困難な旅を乗り越える何万人ものテスト エンジニアにも同行してきました。あなたにも役立つことを願っています。