テストツールを導入すると何が嬉しいのか
私がWebアプリケーションの開発に携わっていたときに、部分的にテストツールを利用したことがありました。
私の整理ではテストツール導入の場面は以下の3になるかと思います。
- 負荷テスト
- シナリオを網羅するテスト
- 単体テスト自動化
私が導入したのは1番の負荷テストと、2版のシナリオを網羅するテストの一部分の単純なシナリオでした。最近特に注目を浴びているのは単体テストの自動化であると思います。設計時点でテストコードを先に設定し、コードを書き終えてコンパイルした時にそのテストコードが正しい値を返すかどうかを見ることで確かに開発の生産性は上がるだろうなという気がします。特に統合開発環境に最初からついてくるものを使わない手はありません。
私の経験に話を戻しますと、負荷テストでテストツールを使いたい事情は単純に欲しい負荷が生み出しづらいからです。WebアプリケーションでもWebサーバ1台で処理を完結させる小規模なものから、WebサーバもDBサーバも複数台用意してキャッシュサーバとロードバランサーなどを組み合わせた大規模なものもあります。そういった環境で要求されるような重い重い負荷はやはり専用のツールに頼ることが望ましいです。
また、キャッシュやロードバランシングのような部分は特にチューニングの善し悪しが現れやすいところです。もちろんWebサーバもDBサーバもそれなりのチューニングを施す部分がありますが、それは思ったよりもCPUが使われて「いない」ような場合が多く、WebサーバやDBサーバでギリギリのチューニングをして性能悪化を回避するような場合、それよりも先回りして台数を増設しておくことが重要ではないかと思います。負荷テストではそういったボトルネック探しが行われます。
負荷テストの条件設定はお客様と調整して決定し、その設定で良好なパフォーマンスを得たことを説明すればリリース前後のお客様の精神状態も良好なものになると思われます。
シナリオを網羅するテストは、デバッグと関連があります。複雑な画面遷移に合わせて多くのシナリオを消化するような場合、あるバグが何のシナリオに起因するものか追求できなくなってしまう場合があります。特にテスターとしてあまり専門性の高くない人材を投入する場合にそういったことが起こることが多くなります。シナリオを事前に作成し、テストツールに取り込ませてテストを行った場合はプログラムでどのようなトランザクションを発生させたかを追跡可能になっている場合がほとんどです。また、デバッグが完了した場合に同じテストを実行して問題が回避されたことを確認できることもまた非常に大きなメリットです。
負荷テストとシナリオテストの合わせ技もあります。負荷テストの結果、何らかのボトルネックが見つかったとします。それにより構成の変更があり、Webサーバの増設とDBサーバのメジャーバージョンアップが行われたとしましょう。典型的なWeb3層構成ではDBサーバに変更があってもアプリケーション全体に与える影響が少ないはずです。しかしその品質をテストで証明する場合、どこまでをテストの範囲とすべきかは難しい問題です。こうした場合に前回利用したシナリオは非常に便利なものです。
私の認識の範囲ではWebアプリケーションの開発で用いるテストツールというとこのあたりかと思います。加えて、某ブラウザで複雑なJavaScriptを長時間操作した際にメモリリークのような現象が観測されるという事態にあたり、自作の打鍵ツールを開発しました。ひとつの動作を何百回か何千回かを繰り返したら某ブラウザのメモリ使用量が50メガバイトを超えていてちょっと驚いた記憶があります。別のブラウザではそのようなこともなく涼しい顔をして動いていたような記憶もあります。
そういう自分が使った負荷テストツールはwcatでした。情報が少ない中なんとか使いこなしたようなものでしたが、日本語の解説も増えてお手軽なものになってきたように思います。簡単なシナリオテストにはwastを利用しました。こちらも本格的なシナリオを消化させようと思うと大変で、準備は進めたものの実際の開発の場面では人間がやってしまったほうが早かったような記憶があります。（マスターすれば違うのでしょうが）
『Microsoft TechNet: IT Pro 道場 自主トレシリーズ - 負荷テストの実施』 http://technet.microsoft.com/ja-jp/dd696125.aspx
『[HOW TO] Web Application Stress (WAS) Tool のインストールおよび使用方法』 http://support.microsoft.com/kb/313559/ja