PR
図●テストの種類と確認対象の開発工程を示す「V字モデル」
図●テストの種類と確認対象の開発工程を示す「V字モデル」
[画像のクリックで拡大表示]

 ソフトウエアあるいはコンピュータシステムが思ったとおり(仕様通り)に動作するか確かめる作業。システムの品質を高め、稼働後の障害やトラブルを防ぐには欠かせない。一般に全開発工程の3分の1を費やす。

図●テストの種類と確認対象の開発工程を示す「V字モデル」
図●テストの種類と確認対象の開発工程を示す「V字モデル」

 テストは着眼点によって大きく4種類に分かれる()。まず「単体テスト」を実施。プログラムを1本ずつ単独で実行し、ロジックの誤りや記述ミスを取り除く。次の「結合テスト」はあるプログラムから別のプログラムを呼び出す処理を正しく実行できるかを確認する。3番目の「システムテスト」は基本設計書に沿って、システムが意図通りに動くかを調べる。そして最後の「受け入れテスト」で要件定義書の内容に実装漏れがないかをチェックする。一般にシステムテストまではシステムの作り手がこなし、受け入れテストは発注者が担当する。

 4種類のうちシステムテストは、確認内容によってさらに細分化できる。新機能や修正機能に問題がないか調べる「機能テスト」、未変更の機能に影響がないか確認する「回帰テスト」は、その代表。大量アクセスを意図的に発生させて性能要件をチェックする「負荷テスト」、システム障害からの復旧手順を調べる「障害テスト」、システム運用手順に問題がないか確かめる「運用テスト」は、非機能要件のシステムテストだ。

 いずれのテストでも「このように動かしたら、結果がこうなるはずだ」という観点で、入力データや操作内容、期待する結果を用意する。これらを「テストケース」もしくは「テストシナリオ」と呼ぶ。テストケースは大規模システムでは1万件を軽く超える。開発規模が11万人月に達する三菱東京UFJ銀行のシステム統合では、結合テスト以降のテストケースが100万件を超えた。2年半に及ぶ開発工程のうち最大6000人がかりで10カ月をテストに費やした。

 すべてのシナリオを消化しても、バグがなくなるとは限らない。バグはテストで見つかれば「不良」として処理されるが、表面化しないまま本番稼働を迎えると「潜在バグ」となる。稼働後に表面化するとシステム障害を引き起こす。

 潜在バグはエラー処理など通常は実行しない条件下のロジックに存在するケースが多い。2005年12月に東京証券取引所の株式売買システムで発生した誤発注を取り消せない不具合は、稼働から5年半以上が経過して初めて実行された処理ロジックにバグが潜んでいた。

 テストケースは通常、要件定義書や設計書など開発成果物の作成者が洗い出す。個人の思い込みによってテストケースの作成漏れが生じる可能性があるため、第三者が設計書とテストケースを照らし合わせて不足がないかチェックすることもある。この6月には、富士通が第三者による品質検証専門の子会社を新設している。