2019年7月19日 / 最終更新日時 : 2021年6月29日 user 事例・ソリューション

テスト自動化における 10 のベストプラクティス #10: 機能テストと負荷テストを組み合わせる

ソフトウェア開発の目標は、素晴らしいユーザーエクスペリエンスを提供することです。これには、アプリケーションの機能やユーザビリティだけでなく、パフォーマンスも含まれます。たとえば、処理が遅いモバイルアプリケーションは、多くの場合、利用者に削除されます。更新に時間がかかるWebページは放置され、誰からも閲覧されなくなります。機能テストと負荷テストを組み合わせて実行し、ピーク時であっても信頼できるパフォーマンスでアプリケーションが期待どおり動作することを確認しましょう。

一般的なQAプロセスとして、以下のようなフェーズがあるでしょう。

アプリケーションが単体テストと統合テストにパスします。
自動化された機能テストが「ユーザーストーリー/BDDシナリオどおりに Webサイト/アプリケーションの新機能が動作しているか」また「デグレードが発生していないか」を検証します。
QAチームが探索的テストを実施し、潜在的な欠陥を発見します。この探索的テストは、本番環境での運用よりも低い負荷を想定して実施されます。
最後に、シミュレートされた使用条件 (さまざまなトラフィック、複数のユーザー、増やされたネットワーク負荷など) でパフォーマンステストを行い、システムの動作を検証します。

この手法の欠点は、本番環境の条件下におけるアプリケーションの動作について、テストプロセスの４フェーズ目に初めてフィードバックされるため、最終段階まで結果が分からないことです。対象的に、機能テストと負荷テストを組み合わせた場合、テストプロセスは以下のようなステップになるでしょう。

アプリケーションが単体テストと統合テストにパスします。
自動化された機能テストを負荷テストと組み合わせて実施します。本番環境の条件下でアプリケーションが期待どおりに動作するかを確認します。
QAチームが探索的テストを実施し、潜在的な欠陥を発見します。探索的テストでは、本番環境での運用よりも低い負荷を想定して実施されますが、その後、本番環境を想定した負荷でさらに実施されます。この2段階の探索的テストによって、エンドユーザーが運用環境でどのようなユーザーエクスペリエンスを得るかについて、重要な洞察がもたらされます。

この手法では、テストプロセスの早い段階に、本番環境の条件下で重要な機能を検証できます。テストプロセスの後期に問題を検出する場合と比較して、問題の特定を解決するのが容易です。

主要な概念

パフォーマンステスト

パフォーマンステストは、システムを評価するためのベンチマークを生成します。このテストは、アプリケーションまたはWebサイト、およびそのデータベースファイル、サーバー、ネットワークハードウェアなどから構成されます。

パフォーマンステストのベンチマークには、アプリケーションが余裕を持って処理できる同時ユーザー数、システム全体の応答性、スループット、リソース使用量、待ち時間などを含めることができます。

一般的に、待ち時間とは、ユーザーの要求に対してアプリケーションが応答するまでに必要な時間を指します。ネットワークでは、待ち時間という用語はもっと具体的に「ネットワークのノード間を1方向にデータパケットが移動するのに要する時間」または「データパケットが一周して元の場所に戻るのに要する時間」を表すために使用されます。

負荷テスト

負荷テストはパフォーマンステストに含まれる検証方法の１つです。負荷テストは、「通常負荷」と「高負荷」で一定時間、アプリケーションのパフォーマンスを検証します。また、負荷テストでは、目標となるトランザクション数および複数同時ユーザー数でのトランザクション数の処理能力に対する検証を含む場合もあります。負荷テストの目的は、「通常時の負荷」だけでなく「高い負荷」でもシステムが適切に動作するかどうかを判断することです。

ストレステスト

ストレステストもパフォーマンステストに含まれる検証方法の１つです。ストレステストは、「ブレークポイント」と呼ばれる、システムのレスポンスが激しく遅くなったり、失敗したりするポイントを特定します。

ストレステストでは、予想される処理の限界を超えた負荷をあたえ、アプリケーション/Web サイトをテストします。これは、極限の状況でアプリケーション/Webサイトがどのように応答するかを調べるのに役立ちます。たとえば、トランザクション数が多すぎてアプリケーションがクラッシュした場合に、回復までにどの程度の時間を要するのか、どの程度のデータが失われるのか、などです。

ベストプラクティス

計測できるメトリクスを定義する

パフォーマンステストのゴールを、計測できるものに設定します。たとえば、応答時間、スループット、1 秒あたりに処理されるリクエストの数、リソースの使用量などです。常にユーザーの視点でパフォーマンスを測定しましょう。たとえば、クライアントアプリケーションの処理が遅い場合、サーバーからの応答が早いかどうかは問題ではありません。

現実的なシナリオを使用する

最も一般的なワークフローをシミュレートする現実的なテストを作成します。シナリオには、ユーザーの使用頻度の高い操作を優先させます。機能テストの優先順位の詳細については、前の記事（テスト自動化における 10 のベストプラクティス #9: E2E テストの計画）を参照してください。

クリーンな環境を用意する

テスト環境は、パフォーマンスに影響する可能性がある他のアプリケーションやトラフィックから隔離するべきです。Webテストの場合、ブラウザーのキャッシュとクッキーを消去することを意味します。キャッシュされたデータとクッキーを使ってクライアントリクエストを処理している場合、負荷テストとパフォーマンスの結果に信頼がおけない状況になる恐れがあります。

リスクの高いシナリオから検証する

他のテストに進む前に、スモークテストとサニティテストを実施しましょう。テスト対象のアプリケーションに重大な問題がある場合、他のテストを行う前に、問題の存在を知りたいはずです。

小さく始める

多数の同時ユーザーでのテストを行う前に、少数の同時ユーザーで機能テストが正常に完了することを確認します。そして、徐々に同時ユーザー数を増やし、どこでボトルネックが発生するかを特定します。

ツール

Ranorex（Ranorex Studio）には、デスクトップ/Web/モバイルアプリケーションのUIテストを自動化するための多彩なツールが用意されています。Ranorexから、様々なトランザクション負荷をシミュレートできます。

データ駆動型テストを利用して大量のデータを生成し、データベースに対してCRUDアクション (作成、更新、削除) を実行します。
特定のアクション実行の繰り返し回数を設定し、クエリーやページロードといったアクションをシミュレートします。
並列テストを実行し、さまざまな端末から負荷を生成します。

さらに本格的な負荷テストを実施するために、RanorexはNeotys社のNeoLoadと統合します。
NeoLoadには、負荷テストを設計および解析するための先進的なツールがあります。また、アプリケーションあるいはWebサイトのパフォーマンスの解析において、Neoloadは物理マシンや仮想サーバーだけでなく、クラウドベースのプロバイダーにも対応します。さらに、NeoLoadを使用すると、アプリケーションのインフラストラクチャをリアルタイムでモニタリングしてパフォーマンスのボトルネックを特定できます。NeoLoad については、以下の関連情報をご参照ください。