テスト自動化フレームワーク： Archi構造と種類

自動テストにおけるフレームワークとは何ですか?

A テスト自動化フレームワーク コーディング標準、テストデータの処理、オブジェクト リポジトリの処理などの一連のガイドラインです。自動化スクリプト作成時にこれに従うと、コードの再利用性の向上、移植性の向上、スクリプトのメンテナンス コストの削減などの有益な結果が生まれます。これらは単なるガイドラインであり、ルールではありません。また、必須ではなく、ガイドラインに従わずにスクリプトを作成することもできます。ただし、フレームワークを使用するメリットは得られません。

なぜフレームワークが必要なのでしょうか?

フレームワークが必要な理由を理解するために例を考えてみましょう。

参加者に以下のガイドラインを遵守するよう求められたセミナー/講義/会議に出席したことがあると思います。

• 参加者は講義開始の5分前までに着席してください。
• メモを取るためのノートとペンをご持参ください。
• 腹筋を読んでくださいtracそうすれば、プレゼンテーションの内容がだいたいわかるでしょう。
• 携帯電話はマナーモードに設定してください。
• 講義の途中で退席する必要がある場合は、講演者とは反対側の出口ゲートをご利用ください。
• 質問はセッションの最後に受け付けます。

セミナーを開催できると思いますか WITHOUT これらのガイドラインを遵守していますか？

答えは大 はい！ 確かに、上記のガイドラインがなくてもセミナー、講演、会議、デモンストレーションを行うことはできます。実際、ガイドラインが定められているにもかかわらず、私たちの中にはそれに従わない人もいます。

しかし、ガイドラインに従えば、視聴者の減少などの有益な結果が得られるだろう。trac講義中の集中力向上、参加者の継続率向上、および主題の理解度向上。

上記に基づいて、 フレームワークは、従うことで有益な結果を生み出す一連のガイドラインとして定義できます。

テスト自動化フレームワーク Archi構造：主要構成要素

それぞれのフレームワークの種類を比較する前に、各フレームワークに何が含まれているかを確認しておくと役立ちます。 Archi構造とは、これらの部分がどのように層状に配置されているかを説明するもので、ある層の変化が他の層に影響を与えないようにするためのものです。

• テストスクリプト層: テストケースを格納します。スクリプトは、ナビゲーション手順を繰り返す代わりに再利用可能な関数を呼び出すため、短くなります。
• 関数ライブラリ: ログイン、検索、ログアウトなどの共有アクションを保存することで、ワークフローの変更は一度行うだけで済みます。
• オブジェクトリポジトリ: フレンドリー名をGUI要素のロケーターにマッピングします。インターフェースが変更された場合、このレイヤーのみが編集されます。
• テストデータ層: 入力値と期待値をコード内ではなく、Excel、CSV、またはデータベースなどのデータソースに保持します。
• 設定レイヤー: 環境を含む URLs、ブラウザの選択、タイムアウト、および認証情報。
• レポートレイヤー: 実行レポート、障害発生時のスクリーンショット、および診断ログを生成します。
• 実行層: ビルドサーバーからスイートをトリガーし、自動化をリンクします 継続的インテグレーション.

以下のフレームワークの種類は、主にこれらの層をどの程度厳密に分離しているかという点で異なります。

テスト自動化フレームワークの種類

以下に、さまざまな種類の自動テスト フレームワークを示します。

1. 線形スクリプティング
2. テストライブラリ Archi構造フレームワーク。
3. データ駆動型 テスト フレームワーク。
4. キーワード駆動型またはテーブル駆動型のテストフレームワーク。
5. ハイブリッドテスト自動化フレームワーク。

それらを詳しく見てみましょう –

1) リニア スクリプト – 記録と再生

これはすべてのテスト自動化フレームワークの中で最も単純であり、としても知られています。 「録音＆再生」。この内 自動化テスト フレームワーク、テスターは各ステップ (ナビゲーションとユーザー入力) を手動で記録し、最初のラウンドでチェックポイント (検証ステップ) を挿入します。 その後、記録されたスクリプトを後続のラウンドで再生します。

例： へのログインを検討してください 航空券予約申し込み ログオンが成功したときにアプリケーションが読み込まれたかどうかを確認します。ここで、テスターはステップを記録し、検証ステップを追加するだけです。

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
Dialog("Login").WinEdit("Password:").Set "Mercury"
Dialog("Login").WinButton("OK").Click
'Check Flight Reservation Window has loaded after successful log-on
Window("Flight Reservation").Check CheckPoint("Flight Reservation")

優位性

• スクリプトを生成する最速の方法
• 自動化の専門知識は不要
• テストツールの機能を学ぶ最も簡単な方法

デメリット

• スクリプトの再利用はほとんどない
• テストデータはスクリプトにハードコードされています
• メンテナンスの悪夢

2) テストライブラリ Archi構造フレームワーク

としても知られています 「構造化されたスクリプト」 or 「機能分解」。

この自動テスト フレームワークでは、テスト スクリプトは最初に「録音と再生" 方法。 Laterでは、スクリプト内の一般的なタスクが識別され、関数にグループ化されます。これらの関数は、メイン テスト スクリプトによって呼び出されます。 ドライバ さまざまな方法でテストケースを作成します。

例： 上記と同じ例を使用すると、航空予約にログインするための関数は次のようになります。

Function Login()
  SystemUtil.Run "flight4a.exe","","","open"
  Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
  Dialog("Login").WinEdit("Password:").Set "Mercury"
  Dialog("Login").WinButton("OK").Click
End Function

ここで、次のようにメイン スクリプトでこの関数を呼び出します。

Call Login()
---------------------------
'Other Function calls / Test Steps.
---------------------------

優位性

• 「記録と再生」と比較して、構造化スクリプトではより高いレベルのコード再利用が実現されます。
• 自動化スクリプトはコードの再利用が多いため、開発コストが低くなります。
• スクリプトのメンテナンスが簡単に

デメリット

• テスト ライブラリ フレームワークを使用してスクリプトを作成するには、技術的な専門知識が必要です
• テスト スクリプトの計画と準備にはさらに時間が必要です。
• テストデータはスクリプト内でハードコードされています

3) データ駆動型テスト フレームワーク

このフレームワークでは、一方、 テストケース ロジックはテストスクリプト内にあり、テストデータはテストスクリプトとは別に保管されます。テストデータは外部ファイル（Excelファイル、テキストファイル、CSVファイル、ODBCソース、DAOオブジェクト、ADOオブジェクト）から読み込まれ、テストスクリプト内の変数にロードされます。変数は入力値と検証値の両方に使用されます。テストスクリプト自体は、線形スクリプトまたはテストライブラリフレームワークを使用して作成されます。この手法については、さらに詳しく説明します。 データ駆動型テスト チュートリアル。

例： 開発ping この方法を用いたフライト予約ログインスクリプトは、2つのステップで構成されます。

ステップ1） テスト – データ ファイルを作成します。これには Excel 、 CSV 、またはその他のデータベース ソースを使用できます。

ステップ2） テスト スクリプトを開発し、テスト データ ソースへの参照を作成します。

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set DataTable("AgentName", dtGlobalSheet)
Dialog("Login").WinEdit("Password:").Set DataTable("Password", dtGlobalSheet)
Dialog("Login").WinButton("OK").Click
'Check Flight Reservation Window has loaded
Window("Flight Reservation").Check CheckPoint("Flight Reservation")
'Note "dtGlobalSheet" is the default excel sheet provided by QTP.

優位性

• テスト スクリプトへの変更はテスト データには影響しません。
• 複数のデータセットを使用してテストケースを実行できます
• 外部データファイルのテストデータを変更するだけで、さまざまなテストシナリオを実行可能

デメリット

• テスト スクリプトとテスト データの両方を計画し、準備するにはさらに時間が必要です

4) キーワード駆動またはテーブル駆動のテスト フレームワーク

その キーワード駆動型 または、テーブル駆動型自動化フレームワークの開発には、データテーブルとキーワードが必要です。 の独立 テスト自動化ツール それらを実行するために使用されます。 テストはアプリケーションの有無にかかわらず設計できます。 キーワード駆動テストでは、テスト対象アプリケーションの機能が表と各テストの段階的な手順に文書化されます。

キーワード駆動フレームワークには、キーワード、アプリケーション マップ、コンポーネント機能という 3 つの基本コンポーネントがあります。

キーワードは、GUI コンポーネントで実行できるアクションです。例: GUI コンポーネント テキスト ボックスの場合、キーワード (アクション) には、InputText、VerifyValue、VerifyProperty などがあります。

アプリケーションマップとは何ですか?

アプリケーション マップは、GUI コンポーネントの名前付き参照を提供します。 アプリケーションマップは「」にほかなりません。オブジェクトリポジトリ

コンポーネント機能とは何ですか?

コンポーネント関数は、GUI コンポーネントをアクティブに操作または問い合わせる関数です。 関数の例としては、すべてのエラー処理を備えた Web ボタンをクリックし、すべてのエラー処理を備えた Web 編集にデータを入力することが挙げられます。 コンポーネントの機能は、アプリケーションに依存することも、独立することもできます。

例:: キーワード ビューを理解するために、同じ例を見てみましょう。 2つのステップが必要です

ステップ 1: データテーブルの作成 (Data Driven Framework で作成するテストデータテーブルとは異なります)。このデータ テーブルには、GUI オブジェクトに対して実行されるアクションと、対応する引数 (存在する場合) が含まれています。各行は 1 つのテスト ステップを表します。

ステップ 2: 執筆 Code コンポーネント関数の形式で。

データ テーブルを作成したら、各ステップを読み取り、[Action] フィールドに含まれるキーワードに基づいてステップを実行し、エラー チェックを実行し、関連情報をログに記録するプログラムまたはスクリプト セットを作成するだけです。 このプログラムまたはスクリプトのセットは、以下の疑似コードのようになります。

Function main()
{
  Call ConnectTable(Name of the Table) { //Calling Function for connecting to the table.
  while (Call TableParser() != -1) //Calling function for Parsing and extracting values from the table.
  {
    Pass values to appropriate COMPONENT functions. Like Set(Object Name, Argument) ex. Set(Agent Name, Guru99).
  }
}
  Call CloseConnection() //Function for Closing connection after all the operation has been performed.
} //End of main

キーワード駆動フレームワークについては以上です。

キーワード駆動フレームワークの利点は、キーワードが再利用可能であることです。これを理解するには、たとえば YAHOO メールなどの Web サイトのログイン操作を検証する場合を考えてみましょう。表は次のようになります。

この場合、キーワード「Set」、「Click」、「Verify」は同じままであり、対応するコンポーネント機能は既に開発済みです。アプリケーションマップを変更するだけで済みます。ping （オブジェクトリポジトリ）以前のフライト予約からYahoo!へ Mail 、引数の値を変更すると、同じスクリプトが機能します。

優位性

• コードの高い再利用性を実現
• テストツールに依存しない
• テスト対象のアプリケーションとは関係なく、同じスクリプトが AUT に対しても機能します (いくつかの制限があります)。
• テストは AUT の有無にかかわらず設計可能

デメリット

• 初期投資はかなり高額ですが、この利点は、アプリケーションがかなり大きく、テスト スクリプトが数年間維持される場合にのみ実現できます。
• キーワード駆動フレームワークを作成するには、高度な自動化の専門知識が必要です。

注： にもかかわらず、 OpenText UFT ワン（旧マイクロフォーカス） UFT) はキーワード駆動型フレームワークとして宣伝されていますが、これを使用してもテストツールとアプリケーションの完全な独立性を実現することはできません。

5) ハイブリッド テスト自動化フレームワーク

名前が示すように、このフレームワークは、上で説明した XNUMX つ以上の自動化フレームワークを組み合わせて、それぞれの強みを生かし、弱点を軽減しようとしています。 ハイブリッド テスト QA 自動化フレームワークは、ほとんどのテスト自動化フレームワークが時間の経過と複数のプロジェクトに進化するものです。 最大の業界では、キーワードフレームワークと関数分解手法を組み合わせて使用​​しています。

PS： 言及する価値のある他の自動化フレームワークは次のとおりです。

モジュール性フレームワークのテスト

このフレームワークでは、テスト スクリプト内の共通タスクがモジュールとしてグループ化されます。

例:: アクションの使用 QTP モジュール式スクリプトを作成できます

ログイン用のサンプルスクリプト

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
Dialog("Login").WinEdit("Password:").Set "Mercury"
Dialog("Login").WinButton("OK").Click
'End of Script

これで、次のようにメイン スクリプトでこのアクションを呼び出すことができます。

RunAction ("Login[Argument]", oneIteration)

ビジネスプロセステスト (BPT)

これらの自動化フレームワークは、大規模なビジネス プロセスをコンポーネントに分割し、同じまたは異なるテスト スクリプトで複数回再利用できます。 たとえば、フライトを予約するビジネス プロセスは、ログイン、フライトの検索、予約、支払いとログアウトなどのコンポーネントに分割されており、同じビジネス プロセスまたは異なるプロセスで再利用できます。 また、BPT は、中小企業とオートメーション エンジニア間の緊密な調整を促進します。

適切なテスト自動化フレームワークの選び方

どのタイプも常に最適とは限りません。最適な選択は、チームのスキル、アプリケーションの規模、そしてスイートが存続しなければならない期間によって異なります。以下の表は、結果を左右する要素に基づいて、5つのタイプを比較したものです。

契約する前に、以下の質問をよく考えてみてください。

1. このスイートはどれくらいの期間使用できるのでしょうか？ キーワード駆動型またはハイブリッド型デザインへの高額な初期投資は、長年のメンテナンスを考慮すれば正当化される。しかし、短期間のプロジェクトではそうではない。
2. 誰がテストを作成するのですか？ 手動テスターがテストケースを提供する場合、キーワードテーブルがあれば、スクリプト言語を習得することなく作業を進めることができます。
3. インターフェースの変動性はどの程度ですか？ 画面の切り替えが頻繁に行われる場合は、オブジェクトリポジトリを別途用意することが不可欠であり、そうしないとすべてのスクリプトを編集する必要が生じる。
4. どの程度のデータバリエーションが必要か？ 多くの入力の組み合わせは、データ駆動型設計を直接的に示唆している。
5. 既にどのツールが使用されていますか？ フレームワークは選択されたものに適合する必要があります 自動化ツール そしてチームが理解できる言語、例えば Selenium 　 Java or Cucumber.

ほとんどのチームはライブラリまたはデータ駆動型のアプローチから始め、その後、 回帰 スイートが拡張されます。

テスト自動化フレームワークの利点 Archi構造

テスト自動化フレームワーク アーキテクチャの利点は次のとおりです。

• テスト自動化フレームワークはリスクとコストの削減に役立ちます
• テストの効率が向上します
• メンテナンスコストの削減に貢献します
• コードの再利用を許可します
• 最大のテストカバレッジを達成することができます
• アプリケーションの機能を最大限に活用します
• テストケースの重複を減らすのに役立ちます
• テスト自動化によりテストの効率とパフォーマンスの向上に役立ちます

よくあるご質問