UI自動テストの実践

1. デザインの背景

IT業界の発展に伴い、プロダクトは複雑化し、Webサイドの業務やプロセスは煩雑になってきており、現状ではUIテストは1ページのみであり、膨大な作業量が必要となっています。複数ページの機能や処理のニーズに応え、工数を削減するために、この UI 自動テスト プログラムが設計されました。Snail 自動テスト フレームワークに統合するインターフェイスを提供して、ユース ケースの設計を容易にすることを目的としています。

プログラム全体は Selenium に基づいて設計されています。このプログラムは、日常のユースケース設計に合わせて Selenium が提供するインターフェイスを再カプセル化し、要素の読み込み、要素の配置と分析などの問題を解決し、ユースケース設計を簡素化します。

Seleniumのモデルを採用した理由。1 つ目の理由は、ユーザーにとってオープンソースのフレームワークなので覗いてみたいから、2 つ目は Selenium とシームレスに接続できるからです。マルチプラットフォーム、マルチブラウザ、マルチ言語をサポートし、自動テストを実現するWebアプリケーションテストツールです。Selenium2はブラウザのネイティブAPIをWebDriver APIにカプセル化し、ブラウザページ内の要素を直接操作したり、操作したりすることができます。ブラウザ自体 (スクリーンショット、ウィンドウ サイズ、起動、シャットダウンなど) なので、実際のユーザーとまったく同じです。

現在サポートされているのは、Mac、Windows オペレーティング システム、Chrome、Firefox、および IE ブラウザです。

2.動作原理

  • Snail 管理バックグラウンドにテスト ケースを追加します。
  • Snail 管理バックエンド テスト ケースの実行は、タスク実行インターフェイスを呼び出し、タスク ID とテスト データの JSON 形式文字列をプログラムに送信します。
  • プログラムはデータを取得し、解析して処理します。
  • ブラウザを起動すると、selenium-webdriver はターゲット ブラウザを特定のポートにバインドし、起動されたブラウザが Webdriver のサーバーとして機能します。
  • クライアント (つまり、テスト スクリプト) は、ComandExecutor を使用して HTTP リクエストをサーバー (通信プロトコル: WebDriver ワイヤー プロトコル) に送信します。HTTP リクエストの本文には、WebDriver ワイヤー プロトコルで指定された JSON 形式の文字列が含まれます。 Selenium にブラウザに次に何をしてほしいかを伝えるために使用されます)。
  • サーバー側は、ネイティブ ブラウザ コンポーネントを利用して Web サービス コマンドをブラウザのネイティブ呼び出しに変換し、操作を完了する必要があります。
  • 最後に、処理結果とタスク ID が JSON 文字列の形式で Snail に返され、Snail の管理背景を通じて各ユースケースの実行結果を確認できます。

3. フレームワークの紹介

3.1 エンジニアリング構造

実際の業務プロセスに応じて対応するインターフェースを呼び出し、WEB-UI自動テストケースを実装します。Case 層はサービス層と pageObject 層のインターフェースを呼び出すことができ、PageObject は各ページ要素をカプセル化したもの、service は共通のビジネスモジュール機能をカプセル化したものです。たとえば、企業情報をクエリするためのテスト ケースはログインに依存する必要があり、このビジネス関数はサービス内のインターフェイスを直接呼び出すことができます。エンタープライズ クエリを作成するには、pageObject のインターフェイスを呼び出し、クエリのビジネス プロセスに従って、これらのインターフェイスをテスト ケースに結合して UI 自動化テスト ケースを形成します。詳細については、以下の例で説明します。

ビジネス上の問い合わせなど。クエリを実行する前に、管理バックグラウンドにログインする必要があります。ログイン操作はビジネス層にカプセル化されています。サービス層のインターフェイスを直接呼び出すことができます。このステップの詳細を気にする必要はありません。ログオン後では、パスを指定し、対応する空間を見つけて、モデル レイヤーのインターフェイスを直接呼び出す必要があります。このステップの詳細について心配する必要はありません。次のステップは、クエリとすべての配置を作成することです。クエリを作成するためのメソッドもビジネス層にカプセル化されており、これはエンタープライズ クエリの実装であり、ユースケース設計における最も重要なリンクでもあります。

プロジェクト全体は Selenium に基づいており、pageObject モードを使用して構築されています。以下は、プロジェクト内のいくつかの重要なモジュールの紹介です。

3.1.1 ドライバー — インターフェース層

Web ページのすべての要素に対する操作は、ドライバー インターフェイスで定義および実装されます。ドライバーは、Selenium によって提供されるインターフェイスを再カプセル化し、カプセル化されたインターフェイスを外部に提供します。pageObject は、入力ボックスへの値の割り当てなど、いくつかのパブリック メソッドを実装します。現在、pageObject は多くのメソッドをカプセル化しておらず、ほとんどの関数は Selenium を通じて実装できます。ドライバー層は、オープン ソース ツール インターフェイスを再カプセル化します。ブラウザーを駆動する場合、不可欠なツールであるブラウザー ドライバーがあります。このドライバーは参照ライブラリに配置されます。ドライバーのバージョンは、テストされたブラウザーのバージョンと同じである必要があります。 .一致します。

3.1.2 モデル — データモデル

データ モデルの作成は、テスト データとテスト ケースの分離を実現するために採用される方法であり、特定のテスト データを初期化します。ビジネス プロセスでテスト データを必要とする要素をモデルで定義すると、管理とコードの読み取りが容易になります。

3.1.3 pageObject — ビジネス層

pageObject モードでは、インターフェイス フォームを使用して、各ページが使用する必要がある要素をカプセル化します。カプセル化を実装するには、次の 2 つの手順のみです。

  • 要素をどのように配置するかを決定します。
  • ドライバー内の対応する操作インターフェイスを呼び出します。

ドライバーのインターフェイス実装には、ある程度のフォールト トレランスが含まれていますが、包括的ではありません。一部のページまたはコンポーネントは独自です。ドライバーのインターフェイスを呼び出すだけでは、テスト ケースの安定性を保証できません。この場合、テスト ケースを追加する必要があります。 pageObject のインターフェイス実装一部のフォールト トレラント アルゴリズムは、ユースケースの安定性を保証します。

3.1.4 サービス — ビジネス機能の提供

ビジネス プロセスは他のビジネス モジュールの機能に依存することが多く、テスト ケースの設計を容易にし、車輪の再発明を避けるために、サービス層はログインやエンタープライズ クエリなどのいくつかの一般的なビジネス機能を提供します。証明書利用者はサービス層でそれを呼び出すだけで済みます。

3.2 機能の最適化

Selenium が再カプセル化されている間、インターフェイスも最適化されており、フレームワークの本来の目的は、UI ユースケースの設計を可能な限り簡単に設計、読み取り、保守できるようにすることです。

3.2.1 インターフェースの最適化

Selenium インターフェースを直接呼び出すと、ネットワークの問題でページの読み込みが遅くなったり、操作する必要がある要素が表示されなかったりするなど、「要素が見つかりません」というエラーが報告されることがよくあります。実行は失敗しますが、実際にはこのエラーはバグではなく、テスト結果は無効です。誤検知率を減らすために、ドライバー層のインターフェイスは要素のロードを待機する機能を備えて設計されています。使用される主なメソッドは次のとおりです: cf.searchForElementVisibleXpath(TestStartQuitwd.wd, "//*[text()='操作プラットフォームのログイン「]」、ID、200、100L)。参照コード:

クリックや入力などの操作インターフェースにループ検索判定を追加することで、要素の読み込みを最大限に待つことができ、テストケースの安定性が向上します。

3.2.2 要素の位置決めのための統一された入口

UI オートメーションのユースケース設計を経験したことのあるテスターは、Selenium を介して要素を操作する場合、不可欠な部分は要素の位置の記述であることをより明確に理解するでしょう。平たく言えば、操作する場所をインターフェイスに通知することを意味します。現在のページの要素。要素を見つける方法は数多くありますが、一般的に使用される方法には、ID、名前、CSS、Xpath などが含まれます。Selenium は、さまざまな配置方法に対応する処理用のさまざまなインターフェイスも提供しますが、これは明らかにメンテナンスの観点から最適ではありません。最良のアプローチは、ユースケース設計者が要素の配置と操作イベントの呼び出しのみを考慮し、実装時にイベントがどのチャネルを使用するかを意識せず、メンテナンスの必要がないことです。このフレームワークは、ドライバーが呼び出すメソッドをカプセル化します。その主な機能は、要素を説明する文字列を解析し、それが id、css、または xpath であるかどうかを自動的に判断することです。

3.3 要素の配置

UI オートメーションのユースケースは、実際には 2 つの部分に分けることができます。要素の検索と、要素を操作するためのインターフェイスの呼び出しです。要素を見つける方法はたくさんありますが、一般的に使用される方法には、ID、名前、CSS、XPath などがあります。実際の設計でどの配置方法を選択するかは、通常、メンテナンスの観点からより考慮されます。現在のサーバーのパフォーマンス構成は非常に優れており、パフォーマンスの問題を考慮せずに WEB-UI ユースケースを実行できるためです。メンテナンスコストの観点から、IDと名前が優先され、次にCSS、最後にXPathが優先されます。

すべての Web システムのすべての要素が一意の ID または名前を提供できることを保証することはできませんが、フロントエンド開発と協力できれば、それは素晴らしいことです。通常の状況では、id 属性と name 属性が存在しない状況に直面する必要があります。現時点では CSS スタイルを使用できます。多くの場合、CSS スタイルで位置決めのニーズを満たすことができます。もちろん、これらが提供されない場合は、xpath を選択することしかできません。xpath を使用する利点は次のとおりです。

  • 入手は簡単です。主流のブラウザで「表示」を開くだけで、コピーを通じて簡単に入手できます。
  • ページ上の要素は xpath を使用して記述できますが、不安定性があり、頻繁に使用するとユースケースのメンテナンスに大きな負担がかかるなどの欠点があります。

一般に、フロントエンドがページ上で小さな調整を行う限り、ユースケースを再メンテナンスする必要があります。xpath を使用する必要がある場合、将来のメンテナンスの量を減らすために、いくつかの最適化を行うことができます。これにより、xpath のパス長が短縮され、安定性が向上します。実際に最もよく使用されるタイプは次のとおりです。

  • //input[@value='XXXXX'] など、独自の属性テキストの位置に依存します。
  • //input[contains(text(),'indicativecharacters')] などの標識文字が含まれます。
  • //*[@id='app-container'] など、コンテンツを賢く使用します。

4. よくあるエラー

使用中に問題が発生することがよくありますが、デバッグを容易にするためにここにまとめます。

  • 一部のページのポップアップでは、ポップアップ要素が見つからないことがあります。理論的には、Selenium はページ上で要素を検索するときに要素を見つけることができますが、ポップアップ ウィンドウが表示される場合があり、その場合はポップアップ ウィンドウを再配置する必要があります。解決:

  • 一部の入力ボックスは、入力インターフェースで正常に操作できません。実際に、カレンダー コントロールで要素の配置やすべてが正しいにもかかわらず、正常に操作できないという状況に遭遇しました。解決策: 要素が選択タイプであるかどうかを確認し、値を割り当てます。解決策コード:

3. Selenium の一部のインターフェイスが動作しないことが判明しましたが、現時点で最も考えられる原因はブラウザがアップグレードされたことです。解決策: ブラウザの下位バージョンを再ダウンロードします。

4. 要素は非表示になります。ページ上に通常表示できる要素がありますが、ツールには表示されません。これは、一般に、要素を表示するには次の条件を満たす必要があるためです: Visibility!=hidden; display!=none ; opacity! =0; 高さと幅は両方とも 0 より大きい; input タグには、hidden 属性はありません。たとえば、スクリーンショットは読み取り専用の例です。

解決策: インターフェイス TestStartQuitwd.js.executeScript("var txtN = document.getElementsByName("timeRange"); txtN[0].readOnly = false;"); を呼び出します。 

5。結論

UI 自動化はオープンソース ツールに基づいて最適化されており、ドライバー層、データ層、ビジネス層、ユースケース層のソリューションにはまだ改善の余地が多くあります。WEB-UI の自動化はまだ完全ではないため、今後さらに多くの作業を行う必要があります。いつも研究を支えてくださっている方々に感謝します。

Web自動テストの実践チュートリアルが充実:Python+Selenium4環境構築

おすすめ

転載: blog.csdn.net/dad22211/article/details/132942353