23

Seleniumを使用して、ASP.NETアプリケーションのUIレイヤーをテストします。テストケースの多くは、複数のページにまたがるより長いフローをテストします。

テストは非常に脆弱であり、実際にページを変更するコードの変更だけでなく、コントロールの名前変更（コントロールのclientIDをSeleniumのClickメソッドに渡す必要があるため）や置換などの無害なリファクタリングによっても壊れていることがわかりましたリピーター付きのグリッドビュー。その結果、壊れたテストを修正するために、テストケースの文字列値を更新するのに「無駄」な時間を費やしていることに気付きました。

より保守しやすいSeleniumテストを作成する方法はありますか？または、より優れたWeb UIテストツールですか？

追加のために編集： 通常、最初のドラフトはIDEでテストを記録することによって作成されます。（この最初のステップはQAスタッフによって実行される場合があります。）次に、生成されたC＃コードをリファクタリングします（定数の抽出、繰り返されるコードのメソッドの抽出、異なるデータでのテストケースの繰り返しなど）。ただし、各テストケースのコードの一般的なフローは、最初に生成されたコードにかなり近いままです。

4

8 に答える 8

11

PageObject パターンが非常に役立つことがわかりました。

http://code.google.com/p/webdriver/wiki/PageObjects

詳細: - Selenium のポイントは何ですか? -セレン批評

テスト ケースを段階的にリファクタリングすることから始めるのがよいでしょう。

セレン+ c#と同じシナリオを使用します

私のコードは次のようになります。

テストメソッドは次のようになります

    [TestMethod]
    public void RegisterSpecialist(UserInfo usrInfo, CompanyInfo companyInfo)
    {
        var RegistrationPage = new PublicRegistrationPage(selenium)
              .FillUserInfo(usrInfo)
              .ContinueSecondStep();
        RegistrationPage.FillCompanyInfo(companyInfo).ContinueLastStep();
        RegistrationPage.FillSecurityInformation(usrInfo).ContinueFinishLastStep();
        Assert.IsTrue(RegistrationPage.VerifySpecialistRegistrationMessagePayPal());
        selenium.WaitForPageToLoad(Resources.GlobalResources.TimeOut);
        paypal.LoginSandboxPage(usrInfo.sandboxaccount, usrInfo.sandboxpwd);
        Assert.IsTrue(paypal.VerifyAmount(usrInfo));
        paypal.SubmitPayment();
        RegistrationPage.GetSpecialistInformation(usrInfo);
        var bphome = new BPHomePage(selenium, string.Format(Resources.GlobalResources.LoginBPHomePage, usrInfo.AccountName, usrInfo.Password));
        Assert.IsTrue(bphome.VerifyPageWasLoaded(usrInfo));
        Assert.IsTrue(bphome.VerifySpecialistProfile());
        bphome.Logout();
    }

ページオブジェクトは次のようになります

public class PublicRegistrationPage
{
    public ISelenium selenium { get; set; }

    #region Constructors
    public PublicRegistrationPage(ISelenium sel)
    {
        selenium = sel;
        selenium.Open(Resources.GlobalResources.PublicRegisterURL);
    }
    #endregion
    #region Methods

    public PublicRegistrationPage FillUserInfo(UserInfo usr)
    {
        selenium.Type("ctl00_cphComponent_ctlContent_wizRegister_tUserFirstName", usr.FirstName);
        selenium.Type("ctl00_cphComponent_ctlContent_wizRegister_tUserLastName", usr.LastName);
        selenium.Select("ctl00_cphComponent_ctlContent_wizRegister_ddlUserCountry", string.Format("label={0}",usr.Country ));
        selenium.WaitForPageToLoad(Resources.GlobalResources.TimeOut);
        selenium.Type("ctl00_cphComponent_ctlContent_wizRegister_tUserEmail", usr.Email );
        selenium.Type("ctl00_cphComponent_ctlContent_wizRegister_tUserDirectTel", usr.DirectTel);
        selenium.Type("ctl00_cphComponent_ctlContent_wizRegister_tUserMobile", usr.Mobile);
        return this;
    }

}

お役に立てれば。

于 2009-07-11T17:04:14.253 に答える
3

Selenium テストを記録して再生することで、どのように作成していますか? 私たちが行ったことは、(これらの ID の命名規則を使用して) ID をクリックするのではなく、"clickSubmit()" のようなメソッドを呼び出すように、ページの周りにオブジェクト モデルを構築することです。これにより、Selenium テストが多くの変更に耐えることができます。

于 2009-01-21T20:40:58.897 に答える
2

リファクタリングに対して回復力のあるテストを作成できる場合とできない場合があります。リファクタリングの負担を軽減する方法は次のとおりです。継続的な統合は不可欠です。

毎日またはビルドごとに実行します。修正が早ければ早いほど簡単です。

開発者が自分でテストを実行できることを確認してください。繰り返しになりますが、問題が発見されて修正されるのが早ければ早いほど、より簡単になります。

Selenium テストを少なくします。クリティカル パス / プリ 1 テスト シナリオに焦点を当てる必要があります。詳細なテストは、ユニット テスト レベル (または jsunit テスト) で行う必要があります。統合テストは常に高価で価値が低くなります。

于 2009-05-06T01:06:11.113 に答える
0

Selenuium-RCでXPath式を使用すると、テストの堅牢性が大幅に向上することがわかりました。

同様の方法でテストを作成します。最初のパスは、ほとんどのページフローとクリック操作を取得するためにIDE/レコードを介して書き込まれることがよくあります。それができたら、Selenium-RCを介してテストを進め、アサーションを追加し、絶対ウィジェットロケーターをより読みやすく親しみやすいXpath式に変更します。（テストを文書化するだけでなく！:)）

注意すべき点の1つは、テストがxpathを多用する場合、JavaScriptの実行能力が低いため、IE6では実行速度が少し遅くなる可能性があることです。（私は、FFよりもIEで実行するのにほぼ1時間かかるテストスイートをいくつか持っています。それは管理可能ですが、テストを書くときに覚えておくべきことです。）

于 2009-01-28T18:18:43.770 に答える
0

テストの自動化に関しては、無害な変更はありません;)

Rational Robot (RRAFS) でSAFS フレームワークを使用して、自動化スクリプトへの影響を最小限に抑えます。アプリケーション マップを維持する作業はまだ残っていますが、スクリプトはほとんどの部分で安定しています。SAFS フレームワークは、cynicalman が言及しているメソッドと非常に似ているように聞こえますが、スクリプトで使用する一般的なメソッドを既にパッケージ化しています。

SAFS サイトには、Selenium の部分的なサポートがあると書かれているので、これでうまくいくかもしれません。

于 2009-01-21T23:05:48.400 に答える
-1

理論上、Selenium にはUI Elementと呼ばれる抽象化があります(ドキュメントはこちら)。

特徴は

  • まさに html 実装に依存しない抽象ロケーター。これは、Web フレームワークのコンポーネントまたはウィジェットの概念にうまく対応します。

  • ロールアップ ルールにより、いくつかのコマンドを 1 つのより抽象的なコマンドにマージできます。

この機能を活用するのに数日間苦労しましたが、次の理由により、最終的に放棄することにしました。

  • オフセット ロケータ (コンポーネントの一部と考えてください) などの一部の概念は、完全にまたは有効に開発されていません。
  • この機能はフォーマッターで完全にはサポートされておらず、フォーマッターが新しいほど機能のサポートが少なくなり、コアの Selenium の進化がこの機能を置き去りにしていることを示唆しています。
  • Selenium 2.0 (WebDriver) には完全には統合されていません。
于 2016-03-02T16:24:01.900 に答える
-2

堅牢なセレン テストを保証するには、Xpath が最適な方法だと思います。現在、xpath 式を簡単に記述できるようにするためのライブラリに取り組んでいます。

興味がある場合は、こちらで確認できます: http://www.unit-testing.net/CurrentArticle/How-To-Write-XPath-for-Selenium-Tests.html

于 2010-11-01T05:30:10.697 に答える