Webアプリケーションテストの自動化

テスト自動化は、開発とテストという2つの分野の出会いの場です。 したがって、おそらく、この慣行は難しいが興味深いものだと考えています。

試行錯誤を通して、次の技術的スタックに到達しました。

1. SpecFlow（オプション）：DSL
2. NUnit：テストフレームワーク
3. PageObject + PageElements：UIの抽象化
4. コンテキストのテスト（ターゲット環境、システムユーザーに関する情報）
5. Selenium.WebDriver

スケジュールされたテストを実行するには、TFS 2012とTeamCityを使用します。
この記事では、これにどのようになったのか、典型的なエラーとそれらを解決する方法について説明します。

なぜそんなに難しいの？

明らかに、テスト自動化には多くの利点があります。 自動ソリューション：

1. 時間を節約
2. テスト時に人的要因を排除
3. 定期的な回帰テストの負担を軽減

自動テストを行ったことがある人なら誰でも、コインの裏側について知っています。 自動テストには次のものがあります。

1. UIの変更による脆弱で「破損」
2. わかりにくい、「最愛の人と」のコードを含む
3. 無効：不正な動作をテストするか、環境に依存します

たとえば、次のコードを考えます。 名前で見ると、「江南スタイル」のリクエストに応じて、Googleが韓国の人気アーティストPSYのYouTubeチャンネルに最初の結果を提供するという事実をテストしていることがわかります。

[Test] public void Google_SearchGangnamStyle_PsyYouTubeChanelIsOnTop() { var wd = new OpenQA.Selenium.Firefox.FirefoxDriver {Url = "http://google.com"}; try { wd.Navigate(); wd.FindElement(By.Id("gbqfq")).SendKeys("gangnam style"); wd.FindElement(By.Id("gbqfb")).Click(); var firstResult = new WebDriverWait(wd, TimeSpan.FromSeconds(10)).Until( w => w.FindElement(By.CssSelector("h3.r>a"))); Assert.AreEqual("PSY - YouTube", firstResult.Text); Assert.AreEqual("http://www.youtube.com/user/officialpsy", firstResult.GetAttribute("href")); } finally { wd.Quit(); } } 

このテストには多くの問題があります。

1. シャッフルされたアプリケーションレイヤー（ドライバー、ロケーター、結果）
2. テストで線が縫われる
3. IEなどでWebドライバーを変更するには、すべてのテストを変更する必要があります
4. ロケーターはテストで配線され、各テストで再度複製されます
5. Webドライバー作成コードの複製
6. エラーメッセージを伴わないアサート
7. 最初のアサートが「落ちる」場合、2番目の条件はまったくチェックされません。
8. テストを一見すると、何が起こっているのか明確ではありません。コードを理解し、時間をかけてコードを理解する必要があります。

自動化に「額に」近づくと、同じアクションのルーチンの繰り返しを取り除くのではなく、テストサポート、誤検知、スパゲッティコードでさらに頭痛がします。

自動テストのアプリケーション層

テストもコードです。 それらをアプリケーションのコードと同じように扱います。 ビジネスアプリケーション層のテーマはすでに十分にカバーされています。 テストで強調表示できるのはどのレイヤーですか？

1. テクニカルドライバー（WebDriver、Selenium RCなど）
2. コンテキストのテスト（ターゲット環境、ユーザー、データ）
3. UIの抽象化-ページ、ウィジェット、ページコンポーネント（PageObjectパターン）
4. テスト（テストフレームワーク：NUnit、xUnit、MSTest）
5. DSL

進化的リファクタリングを実行し、テストを修正します。

テクニカルドライバー

私たちの場合、これはSelenium.WebDriverです。 WebDriver自体はテスト自動化ツールではなく、単なるブラウザー管理ツールです。 HTTPリクエストのレベルでテストを自動化し、多くの時間を節約できました。 Webサービスをテストするには、Webドライバーはまったく必要ありません。プロキシで十分です。
Webドライバーを使用することをお勧めします。理由は次のとおりです。

1. 最近のアプリケーションは、単なる要求/応答以上のものです。 セッション、Cookie、Javaスクリプト、Webソケット。 このすべてをプログラムで繰り返すのは非常に困難です。
2. このようなテストは、ユーザーの行動にできるだけ近いものです。
3. コードの記述の複雑さははるかに低くなります。

テクニカルドライバーレイヤーには以下が含まれます。

1. すべてのWebドライバー設定
2. Webドライバーの作成と破棄の背後にあるロジック
3. エラー制御

始めるために、設定で設定を行います。 私たちにとってはこのように見えます：

 <driverConfiguration targetDriver="Firefox" width="1366" height="768" isRemote="false" screenshotDir="C:\Screenshots" takeScreenshots="true" remoteUrl="…"/> 

構成の読み取り、Webドライバーの作成と破棄のロジックを引き受ける別のクラスを作成しましょう。

 [Test] public void WebDriverContextGoogle_SearchGangnamStyle_PsyYouTubeChanelIsOnTop() { var wdc = WebDriverContext.GetInstance(); try { var wd = wdc.WebDriver; wd.Url = "http://google.com"; wd.Navigate(); wd.FindElement(By.Id("gbqfq")).SendKeys("gangnam style"); wd.FindElement(By.Id("gbqfb")).Click(); var firstResult = new WebDriverWait(wd, TimeSpan.FromSeconds(10)).Until( w => w.FindElement(By.CssSelector("h3.r>a"))); var expected = new KeyValuePair<string, string>( "PSY - YouTube", "http://www.youtube.com/user/officialpsy"); var actual = new KeyValuePair<string, string>( firstResult.Text, firstResult.GetAttribute("href")); Assert.AreEqual(expected, actual); } finally { wdc.Dispose(); } } 

少し良くなりました。 これで、常に1つのWebドライバーのみが使用されるようになりました。 すべての設定は構成内にあるため、再コンパイルせずにドライバーやその他の設定を変更できます。

コンテキストのテスト

アプリケーションのブラックボックステストには、一定量の入力データが必要です。

1. ターゲット環境-URL、テスト済みアプリケーションのポート
2. 異なる役割セットを持つユーザー

この情報はテストロジックには適用されないため、構成セクションに記載します。 構成内のすべての環境について説明します。

 <environmentsConfiguration targetEnvironment="Google"> <environments> <environment name="Google" app="GoogleWebSite"> <apps> <app name="GoogleWebSite" url="http://google.com/" /> </apps> <users> <user name="Default" login="user" password="user" /> </users> </environment> </environmentsConfiguration> 

代わりにwd.Url = " google.com "; wd.Url = EnvironmentsConfiguration.CurrentEnvironmentBaseUrl;になりました。

1. すべてのテストでURLが重複することはもうありません
2. 別の環境をテストするには、異なる構成でプロジェクトを組み立て、変換を追加するだけで十分です

 <environmentsConfiguration targetEnvironment="Google-Test" xdt:Transform="SetAttributes"> 

ページオブジェクト

ページオブジェクトパターンは、テストの自動化で実証されています。
基本的な考え方は、ページの動作をページクラスにカプセル化することです。 したがって、テストは低レベルのテクニカルドライバーコードでは機能せず、高レベルの抽象化で機能します。

ページオブジェクトの主な利点：

1. 権限の分離：ページのすべての「ビジネスロジック」はページオブジェクトに配置する必要があります。テストクラスはパブリックメソッドのみを呼び出し、結果を確認します。
2. DRY-すべてのロケーターは1か所に配置されます。 UIが変更された場合、1つの場所でのみロケーターを変更します
3. テクニカルドライバーレイヤーを非表示にします。 テストは高レベルの抽象化で機能します。 将来、ドライバーを変更したい場合があります。たとえば、PhantomJSを使用するか、パフォーマンスを改善するために一部の領域でWebDriverの使用を一般的に拒否します。 この場合、ページオブジェクトコードを置き換えるだけです。 テストは変更されません
4. ページオブジェクトを使用すると、ロケーターを宣言スタイルで記述できます。

ページオブジェクトに欠けているもの

正規パターンでは、アプリケーションのページごとに1つのクラスを作成します。 これは場合によっては不便です：

1. カスタマイズ可能および/または動的に変更可能なレイアウト
2. 多くのページに存在するウィジェットまたはその他の要素

部分的には、これらの問題は継承の助けを借りて解決できますが、技術的な観点とコードを理解する観点の両方から集約が望ましいと考えられています。
したがって、パターンの拡張バージョン-ページ要素を使用することをお勧めします。 ページ要素-ページを小さなコンポーネント（ブロック、ウィジェットなど）に分割できます。 その後、これらのブロックは複数のページで再利用できます。
ページを作成します。

 [FindsBy(How = How.Id, Using = "gbqfq")] public IWebElement SearchTextBox { get; set; } [FindsBy(How = How.Id, Using = "gbqfb")] public IWebElement SubmitButton { get; set; } public GoogleSearchResults ResultsBlock { get; set; } public void EnterSearchQuery(string query) { SearchTextBox.SendKeys(query); } public void Search() { SubmitButton.Click(); } 

そして、結果を備えた「ウィジェット」

 public class GoogleSearchResults : PageElement { [FindsBy(How = How.CssSelector, Using = "h3.r>a")] public IWebElement FirstLink { get; set; } public KeyValuePair<string, string> FirstResult { get { var firstLink = PageHelper.WaitFor<GoogleSearchResults>(w => w.FirstLink); return new KeyValuePair<string, string>(firstLink.Text, firstLink.GetAttribute("href")); } } } 

NuGetには、優れたPageFactory.InitElementsメソッドを備えたWebDriver.Supportパッケージがあります。
この方法は優れていますが、副作用があります。 WebDriver.SupportパッケージのPageFactoryはプロキシを返し、要素がロードされるのを待ちません。 さらに、すべての同期メソッドがByクラスで機能する場合、 FindsBy属性の使用方法はまだわかりません。
この問題は、基本クラスPageを作成することで解決されます。

 /// <summary> /// Get Page element instance by type /// </summary> /// <typeparam name="T">Page element type</typeparam> /// <param name="waitUntilLoaded">Wait for element to be loaded or not. Default value is true</param> /// <param name="timeout">Timeout in seconds. Default value=PageHelper.Timeout</param> /// <returns>Page element instance</returns> public T GetElement<T>(bool waitUntilLoaded = true, int timeout = PageHelper.Timeout) where T : PageElement /// <summary> /// Wait for all IWebElement properies of page instance to be loaded. /// </summary> /// <param name="withElements">Wait all page elements to be loaded or just load page IWebElement properties</param> /// <returns>this</returns> public Page WaitUntilLoaded(bool withElements = true) 

WaitUntilLoadedメソッドを実装するには 、FindBy属性を持つすべてのパブリックプロパティを収集し、WebDriverWaitクラスを使用するだけで十分です。 これらのメソッドの技術的な実装は省略します。 出力で、シンプルでエレガントなコードを取得することが重要です。

 var positionsWidget = Page.GetElement<GoogleSearchResults>(); 

最後の不便なケースがありました。 状態に応じていくつかの要素を非表示/表示するウィジェットがあります。 このようなウィジェットを、それぞれ1つのプロパティを持つ複数のウィジェットに分割することは実用的ではありません。
解決策も見つかりました。

 public static IWebElement WaitFor<TPage>( Expression<Func<TPage, IWebElement>> expression, int timeout = Timeout) var firstLink = PageHelper.WaitFor<GoogleSearchResults>(w => w.FirstLink); 

これらの方法の技術的な実装は退屈しません。 リファクタリング後のコードの外観を見てみましょう。

 [Test] public void Google_SearchGangnamStyle_PsyYouTubeChanelIsOnTop() { try { var page = WebDriverContext.CreatePage<GooglePage>(EnvironmentsConfiguration.CurrentEnvironmentBaseUrl); page.EnterSearchQuery("gangnam style"); page.Search(); var expected = new KeyValuePair<string, string>( "PSY - YouTube", "http://www.youtube.com/user/officialpsy"); var actual = page.GetElement<GoogleSearchResults>().FirstResult; Assert.AreEqual(expected, actual); } finally { WebDriverContext.GetInstance().Dispose(); } } 

この段階で、はるかに良くなりました：

1. テストクラスはドライバー制御を放棄し、これらの責任をページクラスに委任しました。
2. ロケーターの重複を取り除きました
3. テストの読みやすさの改善

テスト

ページオブジェクトのロケーターとロジックを取り出した後、テストコードはより簡潔で簡潔になりました。 ただし、いくつかの点はまだあまり良くありません。

1. Webドライバーを作成するためのロジックは、テストごとに複製されます
2. 各メソッドでページを作成するロジックも冗長です
3. 魔法の線、「江南スタイル」、「PSY-YouTube」、「http://www.youtube.com/user/officialpsy」callused
4. テストスクリプト自体は十分に脆弱です。インデックス作成の結果が変わる可能性があるため、コードを変更する必要があります。

基本テストクラスを作成する

 public class WebDriverTestsBase<T> : TestsBase where T:Page, new() { /// <summary> /// Page object instance /// </summary> protected T Page { get; set; } /// <summary> /// Relative Url to target Page Object /// </summary> protected abstract string Url { get; } [SetUp] public virtual void SetUp() { WebDriverContext = WebDriverContext.GetInstance(); Page = Framework.Page.Create<T>( WebDriverContext.WebDriver, EnvironmentsConfiguration.CurrentEnvironmentBaseUrl, Url, PageElements); } [TearDown] public virtual void TearDown() { if (WebDriverContext.HasInstance) { var instance = WebDriverContext.GetInstance(); instance.Dispose(); } } } 

テストを再度書き換えます

 public class GoogleExampleTest : WebDriverTestsBase<GooglePage> { [Test] public void Google_SearchGangnamStyle_PsyYouTubeChanelIsOnTop() { Page.EnterSearchQuery("gangnam style"); Page.Search(); var expected = new KeyValuePair<string, string>( "PSY - YouTube", "http://www.youtube.com/user/officialpsy"); var actual = Page.GetElement<GoogleSearchResults>().FirstResult; Assert.AreEqual(expected, actual); } } 

すでにほぼ完璧です。 TestCase属性に魔法の線を入れて、アサートにコメントを追加します

 [TestCase("gangnam style", "PSY - YouTube", "http://www.youtube.com/user/officialpsy")] public void Google_SearchGoogle_FirstResult(string query, string firstTitle, string firstLink) { Page.EnterSearchQuery(query); Page.Search(); var expected = new KeyValuePair<string, string>(firstTitle, firstLink); var actual = Page.ResultsBlock.FirstResult; Assert.AreEqual(expected, actual, string.Format( "{1} ({2}) is not top result for query \"{0}\"", firstTitle, firstLink, query)); } 

1. テストコードが明確になりました
2. 繰り返し操作は基本クラスに移動しました
3. テストが失敗した場合、テストランナーのログからすべてが明確になるように、十分な情報を提供しました。
4. TestCase属性を使用してテストコードを変更せずに、必要な数の入力および出力パラメーターを追加できます。

DSL

このコードには問題があります：

1. コードは明確になりましたが、この状態を維持するには、テストをサポートするスペシャリストの資格が適切でなければなりません
2. QA部門は独自のテスト計画を持っている可能性が高く、自動テストはまだ相関していません。
3. 多くの場合、同じ手順がいくつかのシナリオで一度に繰り返されます。 コードの重複は、継承と集約の助けを借りて回避できますが、特にステップの順序が異なる可能性があることを考えると、これはすでに困難なタスクのようです
4. Google_SearchGangnamStyle_PsyYouTubeChanelIsOnTop（） ： CamelCaseは読みにくい

SpecFlowプラグインを使用して、これらの問題を解決できます。 SpecFlowでは、指定されたWhen Thenスタイルでテストケースを記録し、それらを自動化できます。

 Feature: Google Search As a user I want to search in google So that I can find relevent information Scenario Outline: Search Given I have opened Google main page And I have entered <searchQuery> When I press search button Then the result is <title>, <url> Examples: |searchQuery |title |url |gangnam style |PSY - YouTube |http://www.youtube.com/user/officialpsy [Binding] public class GoogleSearchSteps : WebDriverTestsBase<GooglePage> { [Given("I have opened Google main page")] public void OpenGooglePage() { // Page is already created on SetUp, so that's ok } [Given(@"I have entered (.*)")] public void EnterQuery(string searchQuery) { Page.EnterSearchQuery(searchQuery); } [When("I press search button")] public void PressSearchButton() { Page.Search(); } [Then("the result is (.*), (.*)")] public void CheckResults(string title, string href) { var expected = new KeyValuePair<string, string>(title, href); var actual = Page.GetElement<GoogleSearchResults>().FirstResult; Assert.AreEqual(expected, actual); } } 

このように：

1. 各ステップは1回のみ実装できます。
2. When Then属性が正規表現をサポートしている場合-再利用可能な「機能」ステップを作成できます
3. QA部門は自動テストプロジェクトでスクリプトを記録できます
4. テスターはDSLを記述でき、自動化はプログラマーに割り当てることができます
5. いつでも、合格したテストに関するレポート、したがって開発された機能の数がCIサーバーで利用可能です

この記事では、Give When Thenを使用したSpecFlowと要件管理について詳しく読むことができます。

ガイドラインの自動化

1. 壊れやすく複雑なロケーターを避ける
   正しくない：
   

    [FindsBy(How = How.XPath, Using = "((//div[@class='dragContainer']/div[@class='dragHeader']" + "/div[@class='dragContainerTitle'])[text()=\"Account Info\"])" + "/../div[@class='dragContainerSettings']")] public IWebElement SettingsButton { get; set; } 

   
   正しく：
   

    [FindsBy(How = How.Id, Using = "gbqfb")] public IWebElement SubmitButton { get; set; } 

   
   IDを使用するのが最適です。 java-scriptはidに依存する場合があり、フロントエンド開発者はそれをより少ない確率で変更します。 id（動的マークアップ）を使用できない場合、data-aid（automation-id）、または同様の属性を使用します
   
2. LogonPage、RegistrationPage、HomePage、OrderPageなどのページクラスでアプリケーションロジックをカプセル化します。
3. 「ウィジェット」（ページ要素）でウィジェットと繰り返しブロックを選択します。例：ヘッダー、フッター、LogonLogoff
4. 表示に応じて要素をウィジェットにグループ化します。例：ConfirmationPopup、EditPopup、AddPopup
5. テストコード内の魔法の行を避け、ページやウィジェットのプロパティ、またはOrderSuccessMessage、RegistrationSuccessMessage、InvalidPasswordMessageなどのヘルパーに配置します。 これにより、要素のロード/出現を待機する不要なコードが回避されます。
6. 基本テストクラスに対して繰り返し操作を行い、SetUp、TearDownを使用します。ドライバーの作成と破棄、エラーのあるスクリーンショットの作成、認証、テストの可読性の向上
7. 別のアセンブリでページオブジェクトを取り出します。これにより、ウィジェット/ページの重複を回避できます。 テスト付きのアセンブリが多数存在する可能性があります
8. アサートはテストコードでのみ使用し、ページやウィジェットにはアサートを含めないでください
9. テスト対象を最もよく説明するアサートを使用します。 これにより、テストの可読性が向上します。
   正しくない：
   

    var actual = Page.Text == “Success” Assert.IsTrue(actual); 

   
   正しく：
   

    Assert.AreEqual(MessageHelper.Success, Page.Text) 

   
   
10. アサートエラーメッセージを使用する
    

     Assert.AreEqual(MessageHelper.Success, Page.Text, “Registration process is not successfull”); 

    
    
11. 項目をロードするためのタイムアウトとしてThread.Sleepを使用しないでください。 必要なDOM要素の読み込みを保証する高レベルの抽象化を使用します。例えば：
    

     Page.GetElement<GoogleSearchResults>(); var firstLink = PageHelper.WaitFor<GoogleSearchResults>(w => w.FirstLink); 

    
    
12. DSLを使用しない場合は、テストの名前を[Page_] Script_Expected Behaviorの形式で記述します。 これは、どのような動作がテストされているかを人々が理解するのに役立ちます。 これは、要件を変更するときに特に重要です。
13. DSLでは、ステップを意味的に、またステップの再利用を最大化するような方法でグループ化する
    正しくない：
    

     I have logged as a user with empty cart 

    
    正しく：
    

     I have logged in And my cart is empty 

    
    
14. DSLでは、1つのステップでタプルを比較します。これにより、テストがクラッシュしたときに、より簡潔なコードを記述し、より多くの情報を取得できます。
    正しくない：
    

     When I open Profile page I can see first name is “Patrick” And I can see last name is “Jane” And I can see phone is “+123 45-67-89” 

    
    そうだね
    

     When I open Profile page I can see profile info: Patrick Jane +123 45-67-89 

    
    
15. ブラックボックステストを使用し、テストコードからテストデータの初期化を行います。 これに適しています。たとえば、SSDTプロジェクト
16. CIを使用して定期的にテストを実行し、テスト結果を公開して明確にします

テストの自動化に関するeBayの非常に優れたレポートは、 www.youtube.com / watch？v = tJ0O8p5PajQにあります。