TDDまたは単体テストを行うときに区別するのが難しいと思うので、これらのレベルのテストを明確に定義できる人はいますか?誰かがこれらをいつ、どのように実装するかを詳しく説明できるかどうか教えてください。
6 に答える
簡単に:
単体テスト-個々のコードを単体テストします。各ファイルまたはクラスを考えてください。
統合テスト-相互作用する複数のユニットを組み合わせる場合は、統合テストを実施して、これらのユニットを統合してもエラーが発生しないことを確認する必要があります。
回帰テスト-統合(およびおそらく修正)した後、単体テストを再度実行する必要があります。これは回帰テストであり、さらなる変更によって、すでにテストされたユニットが破損していないことを確認します。すでに行った単体テストにより、回帰テストのために何度も実行できる単体テストが作成されました。
受け入れテスト-ユーザー/顧客/企業が機能を受け取ると、彼ら(またはテスト部門)は受け入れテストを実施して、機能が要件を満たしていることを確認します。
ホワイトボックステストとブラックボックステストを調査することもできます。パフォーマンスと負荷のテスト、および考慮すべき「障害」のテストもあります。
単体テスト:失敗すると、コードのどの部分を修正する必要があるかがわかります。
統合テスト:失敗すると、アプリケーションの各部分が期待どおりに連携していないことがわかります。
受け入れテスト:失敗すると、アプリケーションが顧客の期待どおりに動作していないことを示します。
回帰テスト:失敗すると、アプリケーションが以前のように動作しなくなったことを通知します。
上記の各テストの簡単な説明と、それらがいつ適用されるかを次に示します。
単体テスト単体テスト は、自己完結型のユニット(通常はクラスまたはメソッド)で実行され、ユニットが実装されたとき、またはユニットの更新が完了したときに実行する必要があります。
これは、クラス/メソッドを記述し、バグを修正し、機能を変更したときに実行されることを意味します...
統合テスト 統合テストは、複数のユニットが互いにどの程度相互作用するかをテストすることを目的としています。このタイプのテストは、ユニット間で新しい形式の通信が確立された場合、またはユニットの相互作用の性質が変更された場合に実行する必要があります。
これは、最近作成されたユニットがシステムの残りの部分に統合されたとき、または他のシステムと相互作用するユニットが更新されたとき(およびユニットテストが正常に完了したとき)に実行されることを意味します。
回帰テスト 回帰テストは、新しいバグが導入されていないことを確認するために、システムに変更が加えられるたびに実行されます。
これは、すべてのパッチ、アップグレード、バグ修正の後に実行されることを意味します。回帰テストは、単体テストと統合テストを組み合わせた特殊なケースと見なすことができます。
受け入れテスト 受け入れテストは、サブシステム(場合によってはシステム全体)が仕様全体を満たしていることを確認することが適切な場合はいつでも実行されます。
これは、主に、新しい成果物を完了する前、またはより大きなタスクの完了を発表する前に実行されることを意味します。これを最終チェックとして見て、クライアント/ボスに駆け寄って勝利を発表する前に、あなたが本当に目標を達成したことを確認してください。
これは少なくとも私が学んだ方法ですが、他にも反対の見方があると確信しています。いずれにせよ、それがお役に立てば幸いです。
私が試してみます:
- 単体テスト:開発者は、個々のコンポーネントまたはクラスをテストするために単体テストを作成します。
- 統合テスト:コラボレーションが必要ないくつかのコンポーネントまたはパッケージを含む、より広範なテスト
- 回帰テスト:アプリケーションに1つの変更を加えると、すべてのテストを再実行し、すべての機能を確認する必要があります。
- 受け入れテスト:エンドユーザーまたはQAは、アプリケーションの配信を受け入れるためにサインオフする前にこれらを実行します。「アプリは私の要件を満たしました」と表示されます。
ユニットテスト:私の単一の方法は正しく機能していますか?(依存関係なし、または依存関係のモック)
統合テスト: 2つの別々に開発されたモジュールを組み合わせると、正しく機能しますか?
回帰テスト:新しいコードを変更/作成することで何かを壊しましたか?(すべてのコミットでユニット/統合テストを実行することは、技術的に(自動化された)回帰テストです)。QAのコンテキストでより頻繁に使用されます-手動または自動。
受け入れテスト:クライアントが行ったテストで、配信されたSWを「受け入れ」ます。
コメントできません(評判が低い:-|)ので...
@Andrejsは、各タイプのテストに関連する環境間の違いについて良い点を示しています。
単体テストは通常、他のリソース/システムへの依存関係をモックアウトして、開発者のマシンで(場合によってはCIビルド中に)実行されます。
定義上、統合テストには、(ある程度の)依存関係の可用性が必要です。環境がより代表的なものになるように呼び出される他のリソースとシステム。テスト用のデータは、実際の本番データのモックまたは難読化された小さなサブセットである可能性があります。
UAT /アクセプタンステストは、ソフトウェアを受け入れるQAおよびビジネスチームに実際の経験を表す必要があります。したがって、現実的なパフォーマンスとエンドユーザーエクスペリエンスを提供するには、完全な統合と現実的なデータボリューム、および完全にマスク/難読化されたデータセットが必要です。
他の「障害」も、パフォーマンステスト、セキュリティなどの実稼働エクスペリエンスをシミュレートするために、環境をできるだけ現実に近づける必要がある可能性があります。