概要
テスト設計に関する記事を何本か書きたいと思います。
この記事を書こうと思ったきっかけは実務での反省にあります。
先日、テスト設計がまっったくの未経験の状態でテスト仕様書の作成の仕事を振られ、何のインプットもなくふんわり設計してレビューを投げたところ、ぼっろぼろで返ってきたということがありました。
これではいけないと思い、テスト設計について一から学び、そのアウトプットとして記事を書こうというのがきっかけです。
ほぼほぼ自省録ですが、テスト設計未経験の人が
「明日までに自走でテスト作ってね^^」
と言われたときに、短時間で最低限のインプットができるような応急処置的な記事を目指して書きます。
そのような状況が実際にあるのかと言われれば疑問ですが。
- はじめに
なぜ一本目の記事がパフォーマンステストなのかと言いますと、上述のレビューで指摘が一番多かったからです。
機能的にシンプルなもののテストだったので、機能テストの設計の指摘は少なかったのですが、高負荷になることが考えられる機能だったので、パフォーマンステストにはそれなりのクオリティが求められました。
で、何をもってそれなりとするのかってところですが、それはテスト設計の前段階の性能要求で決定する必要があります。
- 性能要求の決定
パフォーマンステストとはそもそも、
"ソフトウェアを設計もしくは企画する段階で設定された性能が期待通りにでているかをチェックするためのテスト"
なので、その機能に求められる性能を明確化しなければなりません。
ここでいう性能とは、処理時間、応答時間、データ処理量やCPUやメモリなどのリソースの使用率などの数値が当てはまります。
そして、これら性能に対する要件が決まったら、それらを基に各テストケースの期待値を作り込むイメージです。
テスト設計前に性能要求を数値的に決定すべし。
- パフォーマンステストの設計
1で期待値が決まったので、実際のテストケースを作ることを考えます。
対象機能（ソフトウェア）に対し、どのようなテストデータ（テスト条件）・手順で実施するかを明確にします。
パフォーマンステストのテストデータはできるだけ本番と同じものが良いです。
私は本番のデータが取得できる環境だったので、それをテストデータとして使用しました。
もし本番データが顧客のデータなどで使えない場合は、できる限りサイズやバリデーションが本番と同じになるようにダミーデータを作成するのが良いです。
具体的な手順はその機能がどのようなものか、つまり、webアプリのバックなのかフロントなのかそれともバッチなのかによるので割愛します。
テストデータには本番と同等のデータを使うべし。
- パフォーマンステストの実施
さて、テストケースが作成できたので、実施のテストの実施を考えます。
私は結合テストフェーズでパフォーマンステストを初めて実施しようとしてました。
しかし、ソフトウェアが動くようになったらすぐに実施しろ、というのがパフォーマンステストの定石らしいです。
その理由としては、結合テストや総合テストで性能的に問題があることが見つかっても、問題箇所が機能のコア部分であることが多く、手遅れなことが多いため、らしいです。
つまりパフォーマンステストの初回実施はコーディングフェーズで、そのあとの単体/結合/総合テストフェーズ、リリース前、リリース後に都度実施するのがベストプラクティスのようです。
ただ、コーディングフェーズで本番環境に近いサイズやバリデーションを持ったダミーデータを大量に用意しておくこと結構ハードルが高いような気もしますが。。。
パフォーマンステストはソフトウェアが動くようになった段階から開始すべし
- おわりに
いかがでしたでしょうか。
まとめてみると大したことがないなと思うと同時に、この大したことないことをできていなかったんだなあと少し悲しい気分になりました。
が、まあこれも成長の余地だと前向きに受け止めます。
記述の誤りなど何か少しでも気になることがあれば遠慮なくお申し付けください。
【参考文献】
高橋寿一著 (2023) 「知識ゼロから学ぶソフトウェアテスト改訂版 アジャイル・クラウド時代のソフトウェアテスト」 翔泳社