概要

「Webサービスの性能テスト 基礎編その１」で、紹介しきれなかった性能テストに関する話題と、負荷テスト、ストレステストに関しての、実施上の注意点についてご紹介いたします。

性能テストの追加事項

「Webサービスの性能テスト 基礎編その１」の記事では、比較的によくあると思われるWebシステムを単純化して、性能テストを実施するうえで考慮すべき点をご説明しましたが、世の中のシステムが、すべてWebシステムではありません。あらゆるシステムのパターンを網羅することはできませんが、２、３追加のシステム例をご紹介したいと思います。

独自プロトコルによるクライアント・サーバーシステム

最近のシステムでは少なくなりましたが、セキュリティなどの関係からサーバーシステムと、ユーザが操作するクライアントシステム間が、独自のプロトコルを使って構築されてる場合があります。このような場合には、どのように性能テストをするとよいのでしょうか。

まず、このような分散化されたシステムの場合にはトータルのスループットを測定することも必要ですが、実際には各コンポーネント単位での性能を測定しておくことが重要になります。
もちろん、十分に運用体系を考えて準備をした性能テストにて、トータルのスループットが要件を満たしているならば、現時点ではそのシステムは性能的に問題がないと言えるはずです。
しかしながら、複雑なシステムほど個々のコンポーネントの遅延の積み重ねがあり、その結果、性能要件を満たせない可能性が増えてきます。
したがって、どこでどれだけの時間を消費しているかを測定しておくことは重要ですし、そのために、市販されているツールだけでは足りずに専用の測定ツールを開発する必要性もあります。あるいは、コンポーネント間のI/F部分に計測用のログ出力を事前に組み込んでおくことも必要です。

バッチプログラム

業務関係のシステムでは、よく見られるのが、バッチプログラムではないでしょうか。
ユーザのエントリーをもとに、夜間や日中の特定の時間に起動されエントリーされたデータを考慮し、一括処理を行うことがよくあります。

通常このようなバッチプログラムはタイマー起動で実行され、結果もファイル出力やデータベースのデータの更新といった形が多く、ユーザとの対話型システムほどの即答性は求められないことが多いかと思います。
バッチプログラムが動作している間、業務システムの機能の一部に使用制限がかかることはよくあることですし、仮にシステムを使うユーザがいない夜間にバッチを実行するのであれば、パフォーマンスにあまり考慮されずにプログラムが開発される場合があります。

では、バッチプログラムの性能テストは不要なのでしょうか。バッチプログラムは無駄に時間を浪費してもよいのでしょうか。

ユーザとの対話型システムは、時間軸に対する許容度は厳しいですが、バッチプログラムでは、秒を争うようなケースは少ないと考えられます。しかし、夜間バッチが業務時間になっても終わっていなければ業務を始められません。また、バッチプログラムは単機能のプログラムが複数が連続して動作し、全体として処理を完結するケースが多いものです。その場合、各プログラムの積もり積もった遅延が無視できないこともありえます。

つまり、バッチプログラムといえども、実行するために許容される時間は存在します。当然、その許容時間内で収まるかどうかを確認するための、性能テストは必要となります。
ただしWebシステムとは違い、単体のプログラムが相手になるため、測定方法自体はプログラムの実行時間を測定することで基本的には事足ります。
それよりも、バッチプログラムが本番稼働と同様に処理をするため、そのデータ準備が大変になることが往々にしてあります。処理するデータのボリュームとデータパターン、これを如何に本番稼働時と同等に準備するかが重要になります。システムのデータの保持期間等によっても違いは出るかと思いますが、最低でも1年稼働した時に想定されるデータのボリュームを用意する必要があります。

携帯端末用アプリケーション

一般に言われる携帯型端末のアプリケーションでも、性能テストは必要です。
ただし、アプリケーションの性質によっては、性能テストというよりもユーザビリティテストの中でテストすべき項目に近いものが多いかと思われます。
例えば、ユーザのドラッグ操作に対して、遅延なく画面が描画されるという要件があれば、それは性能テストの対象としてみることもできます。しかし実際は、性能というよりもユーザビリティテストの方が妥当性の高いテストとなる場合が多いでしょう。
ただし、アプリケーションによっては性能テストが必要な場合もあるので、アプリケーションの特性に合わせて、どのようなテストを実施するか検討が必要になります。たとえば、回線を使ってサーバーとやり取りをするようなアプリケーションの場合には、回線が遅い場合にセッションがたまって不具合が発生することがあるため、このようなアプリケーションでは性能テストが必要となります。

どのようなシステムやアプリケーションでも、性能テストを行う場合、何をテストするのかを明確にすることが重要であり、それはプロジェクトの初期に計画すべきです。もちろん、初期はあいまい性を含んだ計画かもしれませんが、開発が進むにしたがい具体化していき、それを開発するエンジニアもきちんと理解したうえで開発するべきです。これらが十分にできていないと、性能テストの際、火を噴く可能性も大いにありますのでご注意してください。

負荷テスト実施について

負荷テストの実施については、目的が性能テストとは異なりますが、ほぼ同等の仕組みを使ってテストを実施できます。

再度、JSTQBにおける負荷テスト（ロードテスト）の定義を見直してみましょう。

ロードテスト（load testing）
コンポーネントやシステムの動作を測定するテスト。負荷を増大させ、コンポーネントがどの程度負荷に耐えられえるかを判定する。

性能テストが全体的なスループットを測定して、要件を満たしているかどうかを判断するのに対して、負荷テストでは性能要件以上の負荷を与えた上で、システムを構成するコンポーネントのボトルネックや限界値を探し出すことに重きを置きます。

基本的には、性能テストで採用した方式を延長して、負荷を増やすことで、テストを実施することが多いのですが、スループットの測定からコンポーネントのボトルネックに目的が変化しているため、それに合わせたテストの方法を変える場合もあります。

例えば、システム全体に負荷をかけるのではなく、コンポーネントを狙い撃ちして負荷をかけるようなテストを実施する必要が出てくる場合もあるでしょう。
その場合には、市販のツールやオープンソースのツールがそのままでは使えないケースも出てきます。そうなると、テストの準備工数が増大しますので、プロジェクト内での優先順位との調整が必要となってきます。

さらには、負荷テストの結果をもとに、コンポーネントに対してチューニング作業や改修作業が必要になることは、ほとんど必須と言っていいでしょう。
つまり、事前に余裕をもってスケジューリングをしておかないと、負荷テストが実施できない。あるいは、実施して何か解決すべき問題が見つかっても、手が施せないため、爆弾を抱えたまま本稼働を迎えてしまう場合があるということです。

ストレステスト実施について

ストレステストを実施するのは困難な場合が多く、かつ、負荷テストをしているつもりが、ストレステストになっていたというようなケースもよくあります。
それでは、JSTQBで定義されているストレステストの定義をもう一度見直してみましょう。

ストレステスト（storess testing）
要件で定義した限界、またはそれを超えた条件で、システムやコンポーネントを評価するテスト。

まず、この定義で問題なのは「要件で定義した限界」という言葉です。どれだけ要件で、限界値を定義しているケースが存在するのでしょうか。
よく言われる３秒ルールにしても、同時アクセスユーザ数を規定することはあっても、システムとしての許容される同時アクセスユーザ数を定義することは少ないはずです。

また、負荷テストの定義が「負荷を増大させ」とある以上、増大させる規模が大きくなれば、必然的に「要件で定義した限界」に達する可能性があるのは自明のことかと思います。このため、負荷テストを実施しているつもりが、あるところからストレステストを実施しているのと同等になるのはよくあることです。

ただし、ストレステストの目的は、限界値の超えた場合の振る舞いを評価することです。
負荷テストがスループットを気にせず、正しく動作することのみを期待値として評価するのに対して、ストレステストではシステムとして致命的な不具合が発生しないことを確認します。
さらに言えば、ストレステストの結果、ユーザに正しい画面ではなくエラー画面が表示されるケースもあるでしょう。その場合でも、システムとして守らなければならない最低限の機能だけは動作することを確認します。例えば、データベースのデータが論理矛盾をおこさないとか、セキュリティの問題が発生しないとか、そういったレベルでの動作を確認することをストレステストの目的とする場合もあります。

性能系テストの難しさ

性能テスト、負荷テスト、ストレステストのどれも非機能性テストと呼ばれる種類のテストであり、機能性テストとは異なりOK/NGの判断基準そのものから定義を行うことが必要なケースが多くあります。
また、システム全体に対してアクションをかけて結果を判断するためには、システム全体がどのように構築されているか、コンポーネント間がどのような方法で通信しているかを、どの程度理解しているかによっても、テストの方法、内容まで大きく変わってきます。
それは、とりもなおさずテスト技法を知っているだけではなく、開発手法、利用しているミドルウエア、データベースエンジン、そしてお客様の業務についてどれだけの知識を持っているか、あるいはそれら知識を持っている人を巻き込んでテストを設計し実施できるかにかかってきます。

性能系テストをサービスとして請け負っているベンダーも存在しますので、そういう方々にお願いすれば、ポイントをちゃんと押さえてテストしていただけますが、それは、正しいインプットをサービスベンダーに提供できる場合であって、丸ごとお任せでうまくいくようなテストではありません。

サービスベンダーにテストをお願いする場合でも、自分たちでテストを行う場合でも、テスト対象を正しく理解し、何をテストしなければならないかを、明確に定義することは必要であり、これが一番難しいことでもあります。

それから、性能テストでNGとなってもリカバリに使える時間と資源が限られる場合が多いことも忘れないでください。
何度も言いますが、「品質」と「性能」は後付けではどうにもなりません。最初から作りこむ必要があります。

Tweet