性能テストの概念的な話

# はじめに

一般的なWebシステムを念頭に、性能テスト（performance testing）の概念的なところについて少しまとめてみました。

個別のツールや、チューニングについての記事は多いですが、大枠のフレームについての記事があまりなかったので、書いてみましたが、誤りなど指摘いただけますと幸いです。

最初性能テストの話をまとめようと思っていたのですが、考えてみたら、要件があり、設計があり、テストがありと、一連の流れが必要なのでした。

まずはテストプロセスの定義から。定義についてはこちら[^1]を参照しています。

（テストに関する用語はなんでもそうですが、定義している団体や個人によって、意味合いが異なっています。なので、ここに書いたことはそれを念頭に置いて頂ければと思います。人によって、高負荷テスト、高負荷試験etc...なんでもありですしね）

## テストプロセスの定義

* 性能テスト（performance testing)
 * ソフトウェア製品の性能を判定するためのテストプロセス。
* ストレステスト（stress testing）
 * 予測又は特定した負荷、若しくはメモリやサーバなどのリソースの可 用性が低減したときの限界、又は、それを超えた条件でシステムやコンポーネントを評価するために行 なわれる性能テストの一種。[After IEEE 610] performance testing, load testing も参照のこと。
* ロードテスト（load testing）
 * コンポーネントやシステムの振る舞いを測定する性能テストの一種。負 荷（たとえば、同時実行ユーザ数やトランザクションの数）を増加させ、コンポーネントやシステムがどの 程度の負荷に耐えられるか判定する。performance testing, stress testing も参照のこと。
 * いわゆる狭義の負荷テスト、負荷試験

また、世の中には、ほかにも性能テストの仲間がいろいろいます。[^3][^4][^9]
（Advanced Software Testingシリーズあたりを読むとちゃんともっと網羅的なんだろうがとりあず...）

* 性能テストの他のなかまたち
 * スパイクテスト（Spike testing)
 * 構成テスト（Configuration testing）
 * 耐久テスト（Soak or endurance testing)
        * 実際に長期間の高負荷運転を行い、その際にシステムリ ソース監視を行って異常値を検出する[^10]

などなど。
とりあえず今回は、主に、ストレステストと、ロードテストに絞って話をすすめます。
（ロードテストと、耐久テストなんかは混同してよく使われたりしますね）

# 性能テストの目的

[^4]一般的には、システムが、特定のワークロードの元で、応答性（responsiveness）、安定性（stability）の面で、どの程度動作するかを測定するのが目的です。

さらに、拡張性（scalability）や、信頼性（reliability）や、リソース使用量（resource usage）などの他の品質特性を調査するために役立てることができます。

# 性能要件（または性能目標）

性能テストを行う前に性能要件が必要です。
おそらくプロジェクトによって、要件とされるものは異なると思いますが、以下にWebシステムでの、代表的な要素をあげます。[^2][^8]

## 代表的な性能要件の要素

* スループット(throughput)
 * RequestPerSecや、TransactionPerSecなど
* レスポンスタイム(response time)
 * 画面の表示速度など
* リソース使用量（resource usage）
 * CPU使用率、メモリ使用率など

## 性能要件の具体例

性能要件としては上記の要素を使いつつ、なるべく具体的に書きます。[^7]

例えば、「ピーク帯の同時接続数がooのとき、平均レスポンスタイムがxxであること」など。

# 性能設計

性能要件を達成するための、性能設計では、サイジングや、流入設計などを行います。[^5]詳細は参考資料を参照してください。

今回はテストに焦点を当てているので省略します。

# 性能テスト

性能要件、性能設計を元に、性能テストを行います。
性能テストはテストプロセスと、テストの観点から構成されます。

単に性能テストといった場合は、ざっくりとしたワークロード（例えばWebシステムであれば平常時のリクエストの状態）をかけて、システムの負荷特性（どこがボトルネックであるか、などの洗い出し）を行う場合が多いようです。

## ロードテスト

ロードテストのテスト観点としては、想定される上限に限りなく近いワークロード（例えばWebシステムであれば、ピーク帯のアクセスの状態）時に、性能要件で定義した性能を達成できているかを確認します。

## ストレステスト

想定の上限値、もしくは、想定以上の負荷をかけた場合の挙動を把握するために行われることが多いようです。

# まとめ

つらつらと書いてきましたが、テストプロセス（ロードテストやストレステストや耐久テスト）などは、それぞれオーバーラップしている部分がありますし、論者によって概念も違ったりします。

性能テストを実際のプロジェクトで行う場合は、テストプロセスは参考にしつつも、性能要件（目標）を明確にして、それを達成することができるシステムなのか、を主眼に置いて実施するのが良いように思います。


# 参考
[^1]: JSTQBのソフトウェテスト標準用語集 http://jstqb.jp/dl/JSTQB-glossary.V2.3.J01.pdf

[^2]: ソフトウェアテスト基本テクニック 第8回　性能テスト:http://gihyo.jp/dev/serial/01/tech_station/0008

[^3]: Performance testing: the good, the bad and the slow:https://kazucocoa.wordpress.com/2016/08/12/reading-advanced-software-testing-vol-3/

[^4]: Software performance testing:https://en.wikipedia.org/wiki/Software_performance_testing

[^5]: WEBアプリケーション・サーバー 設計・構築ノウハウ 第2版:https://www.amazon.co.jp/dp/4822229947

[^6]: 性能エンジニアリング入門（5）：http://www.atmarkit.co.jp/ait/articles/1201/06/news121.html

[^7]: 第2回　「応答一律3秒」という性能要件はやめよう:http://itpro.nikkeibp.co.jp/article/COLUMN/20101101/353654/

[^8]: 絵で見てわかるシステムパフォーマンスの仕組み:https://www.amazon.co.jp/dp/B00LHFOTF4/

[^9]: Performance testing: the good, the bad and the slow:https://www.ibm.com/developerworks/community/blogs/invisiblethread/entry/performance_testing_the_good_the_bad_and_the_slow?lang=ja_jp

[^10]: 負荷テストアプローチ別の目標設定と指標の考え方:http://www.oracle.com/technetwork/jp/ats-tech/tech/useful-class-8-520782-ja.html