結合テストの中で定番のテスト。


インターフェーステストでは、個々の機能が正しく連携するかどうかを検証します。

機能間やモジュール間でデータを引き渡した際、データの型が異なることによってデータの値が変わらないか、引き渡されるべきデータがすべて引き渡されているか、連携元と連絡先のモジュールは仕様書通りに問題無く動作するかなどの検証を行います。

業務テストとは、実際の業務を想定したテストです。

内容は目的の業務や対象システムによって異なりますが、実際に業務で行う工程や1日の流れをテスト仕様書として作成します。


テストを行う際は、イレギュラーケースを必ず含めることです。

基本的に正しい動作はシステム開発中に何回もチェックしているため、問題なく動作することがほとんどです。

しかしイレギュラーケースを含めてテストを行う事で、正常に動作しない箇所などを見つける事が出来ます。

業務などで発生する可能性があるイレギュラーなシナリオは必ず検証する必要があります。

システムリソースの限界まで操作し、意図しないシステムのパフォーマンス低下や停止が発生しないかを検証するテストです。

同時にアクセスが集中した際にも、定められた最大アクセス数までレスポンスが低下せずに正しく処理できるかどうかなどの検証をします。


また、予想される連続稼働時間までシステムを動かし続け、意図せず停止しないかを検証します。

稼働テストの問題点として、例えばエラーログの保存領域が少なく見積もられていた結果、100時間の稼働には問題無くとも、200時間稼働した場合エラーログの保存領域が無くなり意図しない動作を起こしてしまうことも考えられます。

上位のモジュールから呼び出して、下位へとテストを行う方式です。

トップダウンテストの特徴は上位モジュールから順番にテストを行うため、より重要な上位モジュールに対して早期段階からテストが可能となる点が特徴となります。

重要な上位のモジュールを繰り返しテストすることによって重大な潜在バグを発見しやすいというメリットがあります。


しかし、上位のモジュールから順にテストを行うため、下位モジュールまで、ある程度開発が進まなければテストを進められません。

開発初期段階では、テストしながら開発を行うのは難しいです。

トップダウンテストとは反対に、下位モジュールから上位に向かって順に行うテスト方式です。

ボトムアップテストは開発初期から同時にテストを行うことが可能で、テストケースやテスト仕様書の作成、結果のチェックが簡単であるというメリットがあります。

下位モジュールからテストを行うため、最終的に上位モジュール部分にバグが見つかった場合、修正量が肥大化する恐れがあります。

可能な限り、実際に運用する本番環境と同じ環境をテスト環境でも準備をする。


システムを利用するクライアント端末やWebブラウザも「テスト環境では問題無く動作、操作出来るが、
本番環境では動かない」といった問題が出てきてしまう可能性があります。

同じミドルウェアやサーバーを活用することは勿論、バージョンも同じであれば、より品質の高いテストが可能となります。


また、環境だけでなくデータやスケジュールも本番環境と同様であることが望ましいです。

自動的に実行されるジョブを本番環境で予定していれば、テスト環境の方にも本番環境と同じ内容の物を用意しておく事が大切です。

テストを簡易的に済ませようとして、DBに保存されているデータを直接追加、変更、削除してしまう事があります。

しかし、データを変更する場合には、必ずシステム上の機能を利用して変更するようにした方が良い。


システム上の機能を駆使してデータを変更することによって、漏れていたイレギュラーな操作によるバグを発見出来る可能性もあります。