性能テストとは
ITシステム開発において、満たすべき性能要件を満たしているかのテストが、性能テストです。
株式会社SHIFTでは、ソフトウェアテストに関して豊富な実績とテストナレッジを保有しており、あらゆるお客様のニーズを満たしたテスト・品質保証を上流～下流（テスト計画・テスト設計・テスト実行・テスト品質管理）まで一気通貫でご依頼いただけます。
ソフトウェアテストのことならSHIFT
「3分で知るSHIFTのテストサービス」の資料ダウンロードページへ
＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ
パフォーマンスに問題がないか試すテスト
性能テスト
性能テストとは、システムやコンポーネントがさまざまな負荷にさらされたときの性能（応答性）に焦点を当てたあらゆるタイプのテストを含む包括的な用語である。
性能テストには、以下のようにさまざまな種類があります。
・性能テスト（レスポンステスト）
・負荷テスト
・ストレステスト
・スケーラビリティテスト
・スパイクテスト
・耐久性テスト
・コンカレンシーテスト（並列実行テスト）
・キャパシティテスト（容量テスト）
たとえば、大量のユーザーが同時にアクセスしてきた場合に処理が可能か、処理時間が大幅に落ちることはないかなどを確認します。システムの内部処理の効率がよいか、同時処理が可能かなどのシステム的なつくりだけでなく、サーバーやネットワーク機器などの処理機能も確認するテストです。
性能テストを実施する目的
性能テストを実施する目的は、当初想定したユーザー数やアクセス数を処理できるか、処理時間は想定内かなどを実際に確認することです。
システムを開発する際には、機能面以外にも性能面の要件定義や設計を行います。そして、性能テストで実際に設定した性能要件を満たしているか、テストします。
目標とした性能要件を満たしていなければ、多くのユーザーによるアクセスに耐えられず、システムダウンしてしまう可能性も高いです。また、処理時間が大幅に落ちれば、ユーザーが離れていってしまうでしょう。
そのようなことを防ぐために、性能テストを実施して、性能要件を実際に満たしていることを確認します。
ソフトウェアテストに外注の選択肢を
「ソフトウェアテストを外注すべき5つの理由とは！？」の資料をぜひご覧ください。
性能テストの種類
一言で性能といってもさまざまな要件があり、それぞれの要件を満たすことを確認するためのテストは異なります。ここでは、その種類についてご説明します。
性能テスト（レスポンステスト）
システムに対する負荷が変化していく際の応答時間をテストします。たとえば、大量のデータを使用した際のシステムの応答時間などを確認し、どの程度のパフォーマンスを出せるか確認します。
負荷テスト
システムがどの程度の負荷に耐えられるかを評価します。たとえば、一定のユーザー数やアクセス数の処理を行い、応答時間、CPU使用率やメモリ使用率などのリソース使用率、エラーレートなどを測定します。
負荷テストについてはこちらもご覧ください。
＞＞負荷テストとは？目的や種類ごとの観点、実施の流れについて解説のページへ
関連サービスについて
ストレステスト
システムに負荷を限界までかけた際に、どのような振る舞いを起こすのかを評価します。障害発生時や想定よりも多くのアクセスがあった際などの、挙動テストになります。
スケーラビリティテスト
ユーザー数の増加などにより負荷が増加した際に、システム拡張が可能かを確認するテストです。
スパイクテスト
急激に負荷が増加したり減少したりする際に、システムの応答時間を確認します。
耐久性テスト
耐久性テストの主な目的は、メモリリークをチェックすることです。継続的な使用下でもメモリリークなどによるリソースの枯渇が起こらないことを確認します。
コンカレンシーテスト（並列実行テスト）
同時に複数の負荷をかけることで、不正なデータができるなどの不具合が発生しないかをテストします。特定の機能を多数のユーザーが同時並列で実行することを想定してテストを行います。純粋に性能をテストするだけでなく、機能面のテストともいえます。
キャパシティテスト（容量テスト）
システムが対応できる、最大のデータ容量を確認するテストです。最大容量のユーザー数やデータ数のデータを投入し、システムが問題なく稼働することを確認します。
性能テストにおける指標
性能テストで性能を確認する際に必要な指標について、解説します。
応答時間
システムの応答時間です。具体的には、ユーザーがシステムの画面を表示させてから完全に表示するまでの時間、何か入力してから応答が返ってきて、結果画面が表示されるまでの時間などです。
システムに負荷をかけて応答時間を測定し、どれだけのはやさで処理が可能かを確認します。
スループット
システムの処理能力を表す指標です。具体的には、単位時間あたりに処理可能なリクエスト数、トランザクション数などです。
システムに負荷をかけてスループットを測定することで、どれだけの処理を行えるかを確認します。
並行ユーザー数
システムが同時に処理できるユーザー数です。同時並行で、何人のユーザーが利用できるかを確認することが可能です。
たとえば、インターネットバンキングは月末や5、10日、昼休みなどに利用者が急激に増えます。想定されるユーザー数のアクセスを行ってシステムに負荷をかけ、システムが問題なく稼働することを確認します。
CPU使用量
CPUリソースの使用量です。システムに負荷をかけた際にCPUリソースを大量に消費しますが、想定の負荷に対して適切なCPUが選択されているか、複数のサーバーに対して負荷分散が適切に行われているかなどを確認します。
たとえば、一部のCPUしか使われていないなどの場合、処理の設計がおかしいことがわかります。その場合、CPUへの処理分散を適切に設計しなおさなければなりません。
リソース使用量
メモリ、ディスク、ネットワークなどのリソースの使用量です。システムに負荷をかけた際に、これらの容量が足りているか、適切に分散されているかなどを確認します。
通常、メモリはサーバーごとに適切な容量で搭載され、ディスクはストレージシステムに複数台搭載されています。また、ネットワークは適切に多重化されています。システムに負荷がかかった際に負荷が適切に分散されず一部の機器に集中している場合は効率が悪く、狙った性能を実現できません。そのため、処理を適切に分散させなおす必要があります。
性能テストを実施する流れ
性能テストを実施する際には、テストフェーズになってからではなく、開発を開始する際に並行して準備をはじめる必要があります。ここでは、性能テストを実施する流れについて、ご説明します。
①要件定義
開発チーム側で機能についての要件定義が行われている間に、性能側の要件定義を行います。
性能に関わる要件には、次のようなものがあります。
・業務量
・ユーザー量
・ターンアラウンドタイム（処理時間）
・スループット
・データ量
・リソース使用量
・スケーラビリティ
これらの要件に対して、どの程度の数値目標を定めるのかを検討します。そのためには、システムをサービス開始した際のユーザー数やアクセス数の予想や、処理時間はどの程度まで許容されるかなどの検証が必要です。
また、機能側の要件定義書をもとに、業務量、業務ごとの性能要件の違いなども定義していきます。
②性能テスト計画
性能テストをどのように行っていくかを計画します。まずは、性能テストの方針を定め、基本的な考え方や前提事項を検討します。
どのような性能テストを行うか、いつ行うかなどを計画します。そのために、どのような環境やツールが必要か、どのようなスキルをもつ人材を確保するかなどを検討します。
その後、テスト環境、テスト体制などについて定め、タスクを洗い出して役割分担を行い、スケジュールを確定していきます。
③詳細設計
要件定義で設定した数値目標を満たすための詳細設計を行います。
機能側を開発する開発チームと連携し、機能側の要件定義書、詳細設計書を参考にして、性能側の詳細設計をしていきます。具体的には、サーバー機器のCPU、ディスクなどの数値や分散配置の設計、ネットワーク設計などです。機器の性能なども考慮する必要があります。
要件定義書をもとに、目標とする数値を満たせる性能設計を行います。
④性能テストシナリオの作成
抽出したテスト観点から、具体的な性能テストシナリオを作成していきます。
要件定義で提示された負荷を実現するために、どのようなシナリオにすべきか、どのような負荷を組み合わせるかなどを検討していきます。
⑤テスト環境の作成とツールの準備
性能テストを行うテスト環境を用意します。実際の商用環境に近い環境を用意し、必要なテストデータ、CPU、ディスク、ネットワーク構成などの用意も必要です。
また、大量のデータやアクセス数を確保するためにツールを使用する場合は、ツールの準備も行います。
⑥性能テストの実施
用意した環境とツール、テストシナリオをもとに、性能テストを実施します。テストを実施している間、応答時間やCPU、ディスクなどのリソース使用量、スループットなどのデータを収集します。また、テスト中のログデータ、エラーデータなども収集し、問題が起きていないか監視も必要です。
⑦性能評価
性能テストの結果データを収集し、性能を評価します。結果が最初に定義した性能要件を満たしているかを確認していきます。求める性能データが得られなかった場合や、エラーが発生した、おかしな挙動が見られたなどの場合、原因の特定が必要です。
性能設計の見直しが必要な場合は設計しなおし、サーバーやネットワーク構成の変更を行います。システムの処理の問題が原因の場合、たとえば検索効率が悪いことで処理時間がかかっている、並行処理がうまく機能していないなどの場合は、処理を見直して修正が必要です。見直しや修正が終わったら、再度性能テストを行って結果を評価します。
性能テストの結果データなどは、適切に保管します。今後性能に関する問題が発生した場合などに、活用することがあるためです。また、今後の性能テストに活かすこともあります。
まとめ
この記事では、性能テストについてどのような種類があるか、どのような流れで行われるかなどを解説しました。
開発したシステムの機能面の品質が保たれていても、性能面で問題があるとさまざまな問題が起こります。処理時間がかかりすぎてユーザー離れが起きる、多くのユーザーが利用した結果、サーバーダウンするなどの問題が起こることはあってはなりません。そのため、性能テストを確実に行う必要があります。
SHIFTでは、豊富なノウハウを活かしたテストを実施しています。自社システムの性能テストを効率よく行いたい、性能テストのノウハウがないため外注したいなどの場合は、お気軽にご相談ください。
＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ
ソフトウェアテストの悩みはSHIFTが解決できます！
「自社で効率よくソフトウェアテストを実施できない…。」
「どうしてもテスト工数が膨らんでしまう…。」
「期日に間に合わない…。」
「リリース後に不具合が発生してしまっている…。」
といった悩みを抱えている企業は多いでしょう。
監修
株式会社SHIFT
「ヒンシツ大学」クオリティ エヴァンジェリスト 永井 敏隆
大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。
担当講座
ダウンロード
