Webアプリケーションテストフレームワークの構成と構造

Question

私は、Seleniumなどのフレームワークを使用して.Net環境にWebアプリケーションテストを導入する予定です。最初はテストを書いている開発者がいるかもしれませんが、後でQAチームになるかもしれません。私はテストが実際にどこに生きるべきか疑問に思います。 Webアプリケーションと同じソリューションに住んでいるか、まったく別個のソリューションでテストすべきか？これらはウェブブラウザを自動化することで行われる回帰テストであり、ウェブアプリケーションのアセンブリへのアクセスは不要であることに注意してください。答えはおそらく環境やその他の要因に基づいていますが、私はこの状況で他の人が何をしているのか不思議です。

Answer 1

回帰テストは、ユニットテストと機能テストの両方を対象としています。機能テストは、さまざまな入力を伴う完全なプログラムを実行します。単体テストは、個々の関数、サブルーチン、またはオブジェクトメソッドを実行します。

単体テストはソリューションのコードの一部であり、Microsoft MVCのようにプライマリコードと一緒に使用する必要があります。機能テストはコンポーネントだけでなくシステム全体を調べるため、どこにでも生きることができます。ただし、機能テストは自動化されたスクリプトなので、ソリューション内に含める必要があります。

機能テストとユニットテストの両方を実行する利点は、プロジェクト管理の問題です。すべてのプロジェクト関連ファイルを1つのリポジトリに保存すると、コードバージョンとテストバージョンがリンクされます。テストスクリプトは、他のプロジェクトコードと同じように、リポジトリ（バージョン管理システム）に格納する必要があるため、ソリューションと一緒に保つのが良いでしょう。

このようにして、テストチームは開発者のようにソリューションをチェックアウトして、ホワイトボックステスト（コードへのアクセスをテスト）を行うことができます。彼らの仕事は、Visual Studio内で保存し、共有し、文書化することができます。マイクロソフトには、テストチームと開発者の間のオープンなコミュニケーションでテストを管理するために使用できる、Team Foundation ServerにいくつかのWebベースの管理ツールが含まれています。