現在のプロジェクトが総合テストの段階に入っておりますが、総合テストで見るべき観点など。実際に自分らはテストしてなくて、障害があったときの対応をしているのですが(汗)
シナリオテスト
単一の機能や画面などではなく、お客さんの利用用途にそって一連のシナリオでテストをするケース。
ポイントとしてはやはり生きた実データの流れやデータシュミレーションを設計段階から意識しておくことでしょう。
シナリオ作成時に生きたデータを作るために、現場の方にある程度入っていただいた方が良いかと思います。
負荷テスト
データ量が増えた時や大量の負荷があったときに500エラーとなったりしないか。
これはプログラムだけではなく、サーバーやDBの性能などにもかかわってきます。
DBのデータ量を増大にすることもこのテストの1つになってくると思います。
また大量のリクエストが投げられた時の耐久度を個人で測るのは難しいので、ツールを使いましょう。
「JMeter」
DBのコネクションの増大なのでアクセスできなくなる・・・なども発生しましたので、超基礎ですがコネクションクローズ処理などを見直しておきましょう。
|
1 2 3 4 5 6 |
dbへのコネクション try{ //DBがらみの処理 }finally{ DBクローズ } |
try{}catch{}finallyではなくtry{}finallyになることに注意しましょう。
【簡単】Webシステムの負荷テストツール（JMeter）の使い方
セキュリティテスト(脆弱性)
いわゆるSQLインジェクション対策やHTMLエスケープなどがしっかり行われているかなど。
これに関しては純粋なコーディング段階で検知できるものが多いとは思います。
なるべくツールで検知できるようにし、目視でのコストを減らすこと。
コーディング規約の中でチェック項目として書かれていればOKですね。
セキュリティに関して特に、有名なのは以下の本ですかね。
体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践
まとめ
ここであげられたようなことは、比較的テストの後半で見られることが多いと思いますが、
シナリオテストで想定された仕様と違っていた・・
負荷テストでデータ量を増やした、あるいはリクエストを増大させたところPGを書き換えないと対応するのが難しい・・・
などですとコードを結構書き換えることになります。(それまでやった単体テスト、結合テストを一部やり直す羽目になります。)
ですので、直前であわてるのではなく、設計段階で少なくともデータ量と想定されるレスポンス時間に関してはある程度、把握した前提で設計～実装を行う必要があるかと思います。
