JSTQB性能テストシラバスの補足（性能テストのテストタイプ）
JSTQBにて、ソフトウェアの性能テストに関する知識をまとめた「Foundation Level Specialist シラバス 性能テスト担当者」の日本語翻訳版を公開をしたのが4月でした。以下にリンクがあります。
JSTQBで翻訳した性能テストシラバスのリンク先
私はこのシラバスの翻訳チームの一員だったので、本当は公開前にちょっと紹介というnoteを書こうと思ったのですが、時間も取れず、ちょっとまとめるのも難しいという理由もあり、できませんでした。このシラバスには、性能テストで知っておくべきことがたくさん書かれてます。
・基本概念（スループットとかロードプロファイルとかランプアップとか）
・性能テストのメトリクスのおすすめ
・性能テストのテスト計画
・性能テストのテスト設計
・性能テストの実装時の注意点（相関とか）
勉強になることがたくさん書かれてて、ぜひ日本語化したいって思っていたので訳せて良かったし、とっても勉強になるのでおすすめです。
なので、ちょっと紹介するよりも読んでもらった方が早いって話があるのですが、このシラバスに書いてある性能テストのテストタイプについて、翻訳してる際に自分が理解するために絵にしたりしてたので、それをnoteで共有しようと思います。
この分類は、シラバスを読んだ結果として、私の解釈が入ってます。
性能テストのテストタイプ
本題です。
性能テストにはいろいろなテストタイプがあり、シラバスでも紹介されていますが、書かれているテストタイプは以下になります。
性能テスト（パフォーマンステスト）
性能テストは、いろいろなテストの包括概念としての用語になります。性能テストと負荷テストは何が違うのか？って話とかよくありますが、一緒でもあるけど、負荷テスト以外のことも含まれているよ、っていうのがISTQBの定義になりそうです。
負荷テスト（ロードテスト）
負荷テストは、仕様で決められた、もしくは想定の範囲内の負荷をかけてみるってテストの総称です。数ユーザーでのアクセスであることもあれば、数万ユーザーでのアクセスであることもあります。性能テストの観点と同じ、応答時間やリソースの適切な利用量といったことが観点です。
ストレステスト
ストレステストは想定の限界か限界を超えた負荷をかけてみるってテストの総称です。なので現実にはあり得ないとしてもシステムとしてはできてしまうので、万が一できちゃったらどうする？って感じでテストするのが該当しそうです。こちらも性能テストの観点と同じ、応答時間やリソースの適切な利用量といったことが観点です。
拡張性テスト（スケーラビリティテスト）
想定の範囲内で処理をするために環境をどう扱えば良いかってことに着目しています。想定の範囲内、つまり要件を満たすことが確認の主眼なので負荷テストの仲間になります。
キャパシティテスト
こちらも拡張性テストと一緒で環境面に着目しているテストなのですが、想定の範囲内ではなく、想定の範囲の限界を見つけるテストなので、ストレステストの仲間になります。
コンカレンシーテスト
ここからは、確認観点が変わってきます。性能というより、同時処理をすることで不正なデータができてしまわないか？とか処理がそもそもできなくなるってことがないかっていう機能面の確認が入ってきてるテストになります。テストの仕方としては、負荷テスト系の仕様通りの負荷をかける場合もあれば、ストレステスト系の想定外の負荷をかけることもあって良いと思われます。
耐久テスト
耐久テストはロングランテストとかいう場合もありますが、負荷をかけてる期間に着目しています。例えば2日間とか３日間経過するとだんだん遅くなるといったことがないか？ってテストするのが該当します。ほとんどの原因がメモリリークです。テストの仕方をしては、負荷テスト系の仕様通りの負荷をかける場合もあれば、ストレステスト系の想定外の負荷をかけることもあって良いと思われますが、よくやるのは、通常の負荷をかけ続ける方法かと思います。
スパイクテスト
スパイクとは、急激なピークのことです。ある時期はものすごく使う人が増えるって時にどうなるかをテストすることになるので、そういう意味では、ストレステストだとも入れるのですが、着目していることがその後のシステムリカバリーなので、テストの仕方をしては、負荷テスト系の仕様通りの負荷をかける場合もあれば、ストレステスト系の想定外の負荷をかけるのをバランスよく（ユースケースで想定できるようなシナリオで）確認するのがよさそうです。
以下が自分がシラバスの内容を理解するために自分なりに整理した絵です。
性能テストには大きく負荷テストとストレステストのやり方があり、そのやり方に当てはまるが別の観点として環境に着目するテストとして、それぞれ拡張性テストとキャパシティテストがあると整理しました。
コンカレンシーテストと耐久テストとスパイクテストは、確認したい品質がちょっと異なっていて、かつ負荷テスト的にもストレステスト的にも行えるので真ん中に配置しています。（感覚的にはコンカレンシーテストと耐久テストは負荷テスト寄りで、スパイクテストはストレステスト寄りかなって思うところもありますが、一旦全部真ん中にしてみました。）
みなさんがシラバスを読む時の役に立てば幸いです。（私の解釈を知ることで、一緒に議論してるような感覚になれればもっといいっすね）
ちょっと脱線
最後に、関係ない話を二つ書きます。
このシラバスのなりたち
通常、ISTQBのシラバスはISTQBの中でワークグループを立ち上げて作られますが、このシラバスはASTQBとGTB（アメリカとドイツのボード）にて作ったシラバスをISTQBに提供した形になっており、他のシラバスと作成の経緯が異なります。
日本発でこういうこともいつかやりたいですねー。
カバー画像について
このカバー画像は、20年近く前に、テストコンサルタントをしていた時に性能テストの講座を作った際の演習題材で実際に負荷をかけた時の結果です。
この講座は２日間コースで、性能テストの基本的なことを半日程度やってから、実際のアプリケーションに対して、ツールで負荷をかけて異変を見つけて、その後ボトルネックを特定してチューニングすると解決するのをまた負荷テストツールで確認するっていうのを3つやってみるって講座でした。３つそれぞれはボトルネックをそれぞれアプリケーションサーバーのスレッド設定、DBのキャッシュ、サーバー間のI/Oの回数にしてました。講義の中で負荷をテストツールでかけるためのテスト用アプリケーションを作り、しかもテストツールも実際に操作させて体感する演習が２日間の半分以上を占めていました。すごく良い講座だと思ったのですが、講座の金額設定を高くしすぎてほとんど売れませんでした。
テストツールは、今はもう売ってない（のかな？）QALoadというパフォーマンステストツールやVantageってモニタリングツールを使ってて、その時の販売元であったコンピュウェアジャパンの人たちと講座を共同開発しました。
このカバー画像は、SQLのupdate文にボトルネックを埋め込んでおき、少ないユーザーだと3秒でトランザクションが返ってくるものがユーザー数を急激にランプアップしてアクセス数を一気に100ユーザーでかけていくことで応答時間が50秒近くかかるようになってしまった状況をテストツールでモニタリングしている画面です。
この時は、演習をやって必ず同じような性能劣化を起こすようにして、同じ箇所のチューニングで必ず性能が回復するようにする演習を３つ作りました。特に大変なのが必ず再現できるように演習用のアプリを搭載したシステム環境のスペックと設定を作るところでした。アプリケーションサーバーのヒープメモリやガベージコレクションを起こすタイミング、SQLも色々書き換えてみて負荷かけるとどう変わるかとか、またはデータベースのキャッシュやDBサーバーとのI/Oの量とか。パフォーマンステストツールやモニタリングツールの使い方も含め、私自身がめちゃくちゃ勉強になったので、ビジネス的に成功しませんでしたが、自分の経験値アップとしてはほんといい思い出です。その後に現場で自分が性能テストをやるときや、自分がテストマネージャーになって性能テストをお願いする時にもこの時の経験がとても役に立ちました。
この時お世話になった方々には本当に感謝です。
サポートありがとうございます。これをカテにこれからも頑張ります。