はじめに
すべてのブエノスディアス！ 私の記事では、Webアプリケーションをゼロから自動テストするプロセスを構築する方法について、できる限り簡潔かつ簡単に説明したいと思います。 まず第一に、許容できる価格/品質比を正しく優先順位付けして選択する必要があります。 すぐに決定します-これは、手動テストによく使用されるスクリプトの動物園の「膝までの」ソリューションではありません。 同時に、自動化のための「フレームワーク」の設計にあまり努力しません。 私たちの目標は、嵐の活動の結果をできるだけ早く経営陣に提供することですが、システムは次のとおりであるべきです。
- 手動テストの専門家でもテストを作成できるように、できるだけシンプルに
- この段階では作業量全体を適切に評価できないため、柔軟で拡張可能
- クロスプラットフォーム（Selenium WebDriver C＃は、Firefox、Chrome、およびIEをサポートします）
この例では、.NET（Microsoft Unit Testing Framework）とSelenium WebDriver C＃を使用します。
参照資料
パート1：はじめに
パート2.1：Selenium APIラッパー-ブラウザー
パート2.2：Selenium APIラッパー-WebElement
パート3：WebPages-ページの説明
パート4：最後にテストを書く
フレームワークの公開
行こう
そのため、まず、優先度が高いがかなり単純なテストシナリオを一定数選択する必要があります。
次に、スタジオで新しいソリューションを作成します。 テスト、ページの説明、ユーティリティの3つのプロジェクトを作成することは論理的です。 これらが3つの基本エンティティになります。
スキームは非常に単純です。テストはページで機能し、ページ上のデータを要求するか、ページで何らかのアクションを実行します。 ユーティリティでは、Selenium WebDriverを使用してページ上のブラウザーおよびWeb要素を操作するクラスを配置します。 Selenium WebDriver APIには多くの欠点があり、むしろ不便に思えるかもしれないため、ラッパーを記述することは論理的です。 これらのラッパーで、特定のspecificいコードをすべてカプセル化（非表示）します。 たとえば、自動テスト開発者に必要な機能のみを提供するBrowserクラスとWebElementクラスを作成しましょう。 将来的には、このプロセスを別の記事で説明したいので、やめません。
テスト
テストの内容を決定します。 車輪の再発明はしません-理想的には、テストは4つの部分で構成されます：
- 入力（テスト）データ
- 前提条件、すなわち 必要なチェックを実行できるシステムの状態
- Webアプリケーションとの相互作用
- check-予想される結果と結果の比較。 このためのMS Unit Testing Frameworkには、個別のクラスAssertがあります
テストの原子性を確保することが重要です-テストは1つの論理操作をチェックし、理想的には1つのチェックを行う必要があります。 このアプローチの利点は次のとおりです。
- テスト結果の分析時間の短縮
- 大規模なログの実装に時間を浪費する必要はありません（MSユニットテストフレームワークは、テスト中にあらゆる種類の診断情報を収集できることを忘れないでください。たとえば、コールスタック、イベントログ、IntelliTrace、写真とビデオの記録、コードカバレッジ分析）
テスト対象の製品のWebページの説明
ページの説明はどうなりますか？
第一に、これらは私たちが取り組む要素の説明です。 id、クラス、名前、xpathなどでそれらを認識する方法です。ページ上のすべての要素を一度に記述する必要はありません。これは時間の無駄です。 さらに、これらの説明はすべてプライベートであり、ページクラスを超えてはなりません。
次に、ページにはプロパティ（ゲッター）とメソッドが含まれます。これにより、テストはページから情報（テキストフィールドの値など）を取得できます。
3番目に、ページには、ボタンをクリックするなど、ページ自体でアクションを実行するためのメソッドが含まれます。 ページの説明にロジックやチェックを含めないでください。 チェックはテスト中でなければなりません。 同時に、ここではSelenium WebDriver APIへの呼び出しはありません。
公益事業
このプロジェクトでは、少なくとも、Selenium WebDriver APIのラッパーがあります。 後でこの場所は、あらゆる種類のヘルパー、ユーティリティ、拡張機能などの集積になります。 別のエンティティやプロジェクトに含める前。
結論と例
したがって、自動テストのロジックを明確に区別する必要があり、このために3つの個別のプロジェクトを作成しました。 プロジェクト開発の過程で、独自のエンティティを持つ他の論理レベルが表示されることを除外しませんが、最小値はそのようになります。
次に、1つの簡単な例を示し、この記事を終了します。 興味深いことがわかった場合は、継続を作成し、WebDriver APIのテスト、ページ、およびラッパーの実装の詳細を説明します。
[TestClass] public class LogOnTests : TestsBase { [TestMethod] public void LogOnWithEmptyLogin() { #region TestData const string login = null; const string password = "password"; const string error = "Empty login!"; #endregion Browser.Open(...); LogOnPage.LogOn(login, password); Assert.AreEqual(error, LogOnPage.Error, "Error expected."); } } public static class LogOnPage { private static readonly WebElement LoginEdit = new WebElement().ById("Login"); private static readonly WebElement PasswordEdit = new WebElement().ById("Password"); private static readonly WebElement LogOnButton = new WebElement().ById("LogOn"); private static readonly WebElement LogOnValidationError = new WebElement().ById("LogOnValidation"); public static void LogOn(string login, string password) { LoginEdit.Text = login; PasswordEdit.Text = password; LogOnButton.Click(); } public static string Error { get { return LogOnValidationError.Text; } } }
PS私は古いロシアのことわざを覚えていました：誰が早く起きるか、彼はテストをデバッグします。