ソフトウェアの品質は、顧客満足度は大きく関わります。クライアントがソフトウェアに求める機能（機能要件）が過不足なく実装されているかは、顧客満足度を保証する上でも最低限クリアしなければならない点です。
そして、機能要件以外で顧客満足度の向上に繋がるのは、機能要件以外に開発側が気を配らなければならない「非機能要件」の部分です。そこで、今回は、非機能要件の1つの性能面についてのテストである「パフォーマンステスト」についてご紹介します。
パフォーマンステストとは？
パフォーマンステストとは、ソフトウェアを利用する際の処理速度や応答時間などが一定の基準を満たしているかを計測するためのテストです。
例えば、データベース内のデータを検索して、画面に検索結果を表示する機能のパフォーマンステストでは、検索条件を入力後に検索ボタンを押して、何秒後に検索結果が表示されるかを計測します。
こうした機能は、データベースに蓄積されるデータ量によっても検索結果表示の応答時間は変動するため「1件」「100件」「10000件」といったデータ量を何パターンか用意して、それぞれで計測します。
処理速度や応答時間が問題ないと判断する基準はさまざまな考え方がありますが、基本的には「ユーザーがソフトウェアを利用する上でストレスと感じない速度」を前提に考えられます。
ソフトウェアのパフォーマンスについては、クライアントと打ち合わせて明確に定義する部分ではありません。
しかし、パフォーマンスが悪いソフトウェアは作業効率を低下させ、ユーザーにストレスを与えます。そのため、開発側がクライアントの立場に立って考慮しなければならない点です。
このような、ソフトウェアの直接的な機能以外の副次的な内容を「非機能要件」といいます。非機能要件および非機能要件の項目をまとめた非機能要求グレードについては、こちらの記事でも詳しく紹介しているのでぜひご確認ください。
パフォーマンステストを実施する目的
パフォーマンステストを実施する目的として、次の2つが挙げられます。
- ユーザーのソフトウェア利用における満足度の向上
- パフォーマンス低下の原因を特定、修正する
それぞれの詳しい内容を解説します。
ユーザーのソフトウェア利用における満足度の向上
応答時間が速いソフトウェアはユーザーにストレスを与えず、作業の効率化にもつながるため、ユーザーのソフトウェアに対する満足度は向上します。
顧客満足度と品質の良し悪しは比例し、結果的に品質の高いソフトウェアを作り上げることにつながるため、会社の信頼度も高めます。
パフォーマンス低下の原因を特定、修正する
パフォーマンステストは基本的にはソフトウェア開発が一通り終わった最終段階で行う場合が多いです。その際、実業務で想定される環境やデータを利用すると、理想とする処理速度や応答時間とならないケースが多々あります。
そこで、パフォーマンスの低下箇所を把握することで原因の特定や速度改善に向けた対策やデバッグ作業を行えます。デバッグについては、こちらの記事でも詳しく紹介しているのでぜひご確認ください。
パフォーマンステストの3つの種類
処理速度や応答時間といった性能面の評価は、ソフトウェアの種類や個人の主観に基づいて定義する部分が多い傾向にあります。
そのため、明確な定義や判断が難しく、さまざまな手法でテストを実施します。ここでは、代表的なテストの種類を3つご紹介します。
ストレステスト
ストレステストでは、ソフトウェアに負荷が掛かった場合に耐えられる設計となっているかをテストします。
ソフトウェアは負荷が低い状態では正常に利用できても、高い負荷が掛かった状態では動作が重くなったり、場合によっては不具合が発生したりするケースがあります。
また、負荷の掛かり具合は実業務を想定したテストを行うだけでは計測が難しく、極端に高い負荷を与えて正常に機能するかを確認する場合が多いです。
例えば「データベース内のデータを検索して、画面に検索結果を表示する機能」のストレステストを行うとしましょう。この時、実際の業務で想定される検索結果の表示数が数千件であるならば、ストレステストでは数万件や数十万件といった規模のテストデータを作成します。
そして、「正常に処理されるか」や「どの程度のデータ量であればシステムダウンしてしまうか」といった点をテストします。ストレステストは高負荷によるシステムダウンを絶対に起こしてはならない業務系システムや証券の株取引システム、銀行のオンラインシステムなどで行われる場合が多いです。
拡張性テスト
拡張性テストとはデータ処理の限界値を見極めるためのテストです。システムを長期運用する場合、利用ユーザーはもちろんのことシステムに蓄積されるデータ量も年々増加します。
そのため、稼働当初は問題なく利用できていたものの、しばらく経ってから動作が遅くなるといったケースも少なくありません。原因としては、利用ユーザーの増加による同時アクセスやデータ量増加による負荷がシステムに悪影響を及ぼしている可能性があります。
よって、システムが処理可能なデータ量を開発側は正確に把握しておかな寝ればなりません。そこで、拡張性テストによってどの程度のデータ量までシステムが正常な速度で動作するかを確認するのです。
ストレステストの目的が「どのデータ量までならシステムが耐えられる設計となっているか」であるのに対して、拡張性テストは「どのデータ量までなら正常な処理が可能であるか」を目的に確認します。
システムが正常に処理されるデータ量のラインを見極め、規定のデータ量を超えたら処理が遅くなる旨のアラートを出したり、サーバーを増設するといった対策を立てられます。
ロードテスト
ロードテストとは、開発時にあらかじめ想定したアクセス数やデータ量の上限でシステムを動かした場合に正常に動作するかを検証するためのテストです。
設計時には正常に処理すると想定した負荷であっても、実際にシステムを運用していく中で不具合が生じる場合もあります。
想定した負荷の最大値が実業務で発生しても「システム処理が正常であるか」や「仕様通りに動作するか」といった点をロードテストで検証するのです。
もし、ロードテストで遅い処理が見つかった場合は、原因の特定や対策、デバッグ作業を行います。ストレステストのように極端な負荷を掛けるのではなく、機能要件で定義した機能が現実的な負荷をかけた状態で問題なく利用できるかを目的に実施されるのがロードテストです。
【まとめ】パフォーマンステストの理解度を深めよう
パフォーマンステストはソフトウェアの性能を計測するためにさまざまな観点で行います。性能面での保証はユーザーのシステム利用におけるストレス低減につながり、さらには顧客満足度の高いシステムになります。
今回ご紹介した代表的なテスト種類について理解を深め、システムへのアクセス数やデータ量などに応じた適切なテストを行いましょう。
