第5回 テストを設計するには（その3）：理論的・計画的なWebアプリケーションのテストの実現（1/2 ページ）

今回はシステムの対応環境の組み合わせでの動作を検証するシステム構成試験、脆弱性の検証などを確認するセキュリティ試験などについて紹介する。

[加藤大受，ITmedia]

前回のまとめ

　前回説明した負荷試験はテストプロジェクトの中のもっとも大きなサブプロジェクトであるといえる。海外のソフトウェア部門ではTurning＆Performance Managerという役職者が存在し、大規模なシステムでは性能検証と負荷試験を1年がかりで行うグループも存在しているほど、この部分が重要視されている。ロード検証も常にアプリケーションサーバなどを利用するシステムでは重要なテスト項目となっており、ロードテストで発見される不具合も少なくない。負荷試験とロード検証の重要性と具体的な話については再度本連載の中で紹介していく予定なので楽しみにしてほしい。

　さて、今回はテストの設計の第3回としてシステムの対応環境（OS、プロトコル、ブラウザ）の組み合わせでの動作を検証するシステム構成試験、脆弱性の検証などを確認するセキュリティ試験などについて紹介する。

対応環境の組み合わせを洗い出す

　システム要件に対応するOS、Webサーバ、ブラウザ、プロトコルなどが記載されているだろう。筆者が勤務する会社で開発するパッケージではこの対応するシステム構成の組み合わせは数百、数千になることも珍しくない。例えば、次のようなシステム要件を持つWebアプリケーションを考えてみよう。

• 対応クライアントOS：Windows 2000 Workstation、Windows XP Professional（SP1、SP2）
• 対応ブラウザ：対応クライアントOSに付属するInternet Explorer
• 対応サーバOS：Windows 2003 Server
• 対応プロトコル：HTTP、HTTPS
• プロキシ経由でのアクセス：対応する

　ここで、すべての組み合わせを考えるとOS（3パターン）×ブラウザ（2パターン）×プロトコル（2パターン）×プロキシ（2パターン）の24パターンが存在することになるが、Windows XP ではIE 5.5が動作しないため、実際の組み合わせは16パターンとなる。

　この16パターンすべてでシステム構成試験を行うのが一番だが、では、この組み合わせの優先順位を考えてみよう。次のような考慮をした場合の優先順位は表1のようになる。

• OSにデフォルトで入っているブラウザのバージョンを優先する
• HTTP、HTTPSは同レベルとする
• プロキシを利用しないアクセスを優先する

表1　優先順位を考慮したシステム構成の組み合わせ OS ブラウザ プロトコル プロキシの有無 優先順位 Windows 2000 Workstation IE 5.5 HTTP 無 A Windows 2000 Workstation IE 5.5 HTTPS 無 A Windows XP Pro SP1 IE 6.0 HTTP 無 A Windows XP Pro SP1 IE 6.0 HTTPS 無 A Windows XP Pro SP2 IE 6.0 HTTP 無 A Windows XP Pro SP2 IE 6.0 HTTP 有 A Windows XP Pro SP2 IE 6.0 HTTPS 無 A Windows 2000 Workstation IE 5.5 HTTP 有 B Windows 2000 Workstation IE 6.0 HTTP 無 B Windows 2000 Workstation IE 6.0 HTTPS 無 B Windows XP Pro SP1 IE 6.0 HTTP 有 B Windows 2000 Workstation IE 5.5 HTTPS 有 C Windows 2000 Workstation IE 6.0 HTTP 有 C Windows 2000 Workstation IE 6.0 HTTPS 有 C Windows XP Pro SP1 IE 6.0 HTTPS 有 C Windows XP Pro SP2 IE 6.0 HTTPS 有 C

　ここでは検証コストを考慮せず、優先順位をA、B、Cという3段階で考えて設定しているが、実際には利用者の環境の調査やコストも考慮して組み合わせと優先順位を決定していくことになる。この優先順位を考慮した組み合わせおよび優先順位の考え方についてもテストの設計フェーズにてテスト計画書に記述しておくべきだろう。

ビジネスリスクを考慮が必要なセキュリティ試験

　Webアプリケーションの検証を行う場合、脆弱性の検証はますます重要になっている。特にインターネット上に公開されるシステムの場合はさまざまな攻撃を防御する必要がある。ハードウェアレベルで考えると、ファイアウォール、IDSなどでシステム全体への攻撃を防ぐことがシステム要件で考慮されているかを確認する必要があるが、ソフトウェアレベルについてもさまざまなセキュリティ試験が必要となる。

　また、セキュリティ試験を行う場合は必ずビジネスリスクを考慮する必要がある。例えば、構築するシステムが個人情報を持っている場合、脆弱性によって蓄えられている情報が漏洩した場合のリスクを金額ベースで算出し、ビジネスリスクを考えてみるのがいいだろう。同様にECサイトでパラメータが改ざんされ、非常に安い価格で決済が通ってしまうなどのリスクについても考えてみるべきである。

　Webアプリケーションの脆弱性で発生するものには次のようなものがある。

• パラメータの改ざん・詐称
• 非公開エリアのファイルやディレクトリの閲覧
• バッファオーバーフロー攻撃
• SQLインジェクション
• データベースへの不正なコマンド送信、破壊工作
• Cookieの改ざんや不正取得
• クロスサイト・スクリプティング

　次ページでは、それぞれについて検証のポイントを考えていこう。