メニュー

Selenium自動化プロジェクトのテスト見積もりに影響を与える7つの要因– Seleniumチュートリアル＃32

7 factors affecting test estimation selenium automation project selenium tutorial 32

問題を排除するために楽器を試してください

Seleniumチュートリアルの最後のカップルでは、​​次のことを学びました。 Cucumber andSeleniumツールを使用した自動化テスト 。また、 SeleniumWebDriverとCucumberの統合 。

このチュートリアルでは、さまざまなことについて説明します Selenium自動化の労力見積もりに影響を与える要因 。

計画と見積もりは、ソフトウェア開発ライフサイクルの2つの最も重要な側面です。

個人的には、ソフトウェア業界には 防弾方法はありません 何かをすることのすべてのプロジェクトは排他的であり、複雑さと環境要因のセットが異なるため、見積もりと計画の戦略を実装することは、高齢者の適切な介入と管理サポートを伴う個々のチームの共同作業である必要があります。

Seleniumの自動化

プロジェクトの見積もりを開始する前に、プロジェクトが通過するすべてのフェーズを理解して、正確で正当な見積もりを行うことが重要です。

Excelシートでテストケースを書く方法

推定は手動テストプロセスで実行できるだけでなく、自動化のこの時代では、推定手法はテスト自動化にも適用されます。 Seleniumが市場で勢いを増し、人気を博している今、私はSeleniumプロジェクトを見積もる際に考慮すべきいくつかの要因について書き込もうとしています。

はじめましょう！！

自動化イニシアチブを最初から開始しており、利用可能な既製のフレームワークがないことを前提としています。

学習内容：

セレン自動化の推定に影響を与える要因

「セレン」固有のプロジェクトの見積もりに影響を及ぼし、考慮する必要があるさまざまな要因を以下に説明します。

＃1プロジェクトの範囲

スコープとは、通常、自動化のための正しいテストケースを特定することを意味します。それを達成するために「除算とルール」戦略を適用します。アプリケーションを小さなチャンクまたはモジュールに分割し、それぞれを分析して、自動化のための適切なテストケースを考え出します。

必要な手順は次のとおりです。

  1. 候補となるテストケースを特定するための基礎となるさまざまな要因を特定します。
  2. アプリケーションをより小さなモジュールに分割する
  3. 各モジュールを分析して、候補となるテストケースを特定します
  4. ROIを計算する

正しいテストケースを特定する方法の詳細については、以前の論文を参照してください。 自動化のための正しいテストケースの選択

＃2アプリケーションの複雑さ

ここに含まれる手順は次のとおりです。

  1. 自動化する必要のあるテストケースの数に基づいて、アプリケーションのサイズを決定します。
  2. フィボナッチ数列によるサイズの複雑さ。
  3. 各テストケースの検証ポイントとチェックポイントを特定します

ここでは、大/中および小サイズのアプリケーションの定義を確立する必要があります。この定義は、個人/グループの観点とは異なります。アプリケーションをどのように分類するかは、テストケースの数によっても異なります。

例えば：

アプリケーションに自動化する300〜500のテストケースがある場合は、それを小規模なアプリケーションと見なすことができます。テストケースが1500を超える場合は、複雑に分類できます。この係数は、アプリケーションごとに異なる可能性があります。一部の人にとっては、自動化する1500のテストケースは小規模/中規模と見なすことができます。したがって、テストケースの正確な数を特定したら、それを小/中または大にスケーリングします。労力の見積もりに向けた戦略は、これらの基準に大きく依存します。

また、テストケースのさまざまなチェックポイントと検証ポイントも考慮する必要があります。テストケースには複数のチェックポイントを含めることができます

ただし、検証ポイントは1つだけです。検証ポイントが複数ある場合は、別々のテストケースに分割することをお勧めします。これにより、テストスイートのメンテナンスと拡張も容易になります。

＃3サポートツール/テクノロジーの使用

ここに含まれる手順は次のとおりです。

  1. フレームワークと自動化のニーズを特定する
  2. ニーズに基づいて、使用するツールを分析および特定します。
  3. ツールを使用することの依存関係/影響を特定します。

フレームワークを構築したり、自動化を完了したりするには、Seleniumだけでは不十分です。 Selenium（Webドライバー）はテストケースのスクリプトを作成するだけですが、結果の報告、ログの追跡、スクリーンショットの撮影など、他のタスクもあります。

これらを実現するには、フレームワークと統合される個別のツールが必要です。したがって、ここでは、要件に最適で、プラスのROIを得るのに役立つこれらのサポートエンティティを特定することが重要です。

＃4フレームワークの実装

ここにトリッキーな部分Jがあります。

  1. 自動化スイートの入力（データがスクリプトに入力されるパターン）と出力（レポート/テスト結果）を特定します。
  2. 入力ファイルを設計します。これは、単純なテキストファイルから複雑なExcelファイルまでさまざまです。これは基本的に、テストデータを含むファイルです。
  3. 入力パラメータに基づいてフォルダ構造を設計し、
  4. レポート機能を実装します（ExcelファイルまたはReportNGなどのツールを使用して）
  5. フレームワークでロガーを決定/実装する
  6. フレームワークにビルドツールを実装する
  7. ユニットテストフレームワークの実装（JunitまたはTestNG）

Seleniumを使用したテスト自動化でのスクリプト作成以外にも、ファイルからのデータの読み取り、テスト結果のレポート/追跡、ログの追跡、入力条件と環境に基づいたスクリプトのトリガーなど、他にも多くの要件があります。したがって、構造が必要です。これらすべてのスクリプトを処理します。この構造はあなたのフレームワークに他なりません。

Webアプリケーションは、実装するための多くのサポートツールとテクノロジを必要とするため、本質的に複雑です。同様に、Seleniumでフレームワークを実装することも、統合する他のツールが必要になるため、注意が必要です（複雑とは言いません）。 Seleniumはツールではなく、実際にはjarファイルのコレクション/グループであることがわかっているため、構成されており、「インストール」されていません。Selenium自体は、複雑なフレームワークを構築するのに十分な強度がありません。フレームワークを構築するためのサードパーティツールのリストが必要です。

ここで、Seleniumには「既製」のものは何もないことを覚えておく必要があります。すべてについて、コーディングする必要があるため、エラーをグーグルで調べてトラブルシューティングを行うための見積もりの​​準備が必要です。

ここで、フレームワークの構築が自動化の取り組みの最も重要な側面であることを理解する必要があります。フレームワークが堅固であれば、特にアジャイルの時代にメンテナンスと拡張が容易になります。フレームワークが優れていれば、すべてのスプリントにテストを簡単に統合できます。

フレームワークを設計するこの特定の要素が見積もりの​​最も重要な側面であると言えば、間違いではありません。必要に応じて（複雑なアプリケーションのように）、この要素を再度別のWBSに分解し、見積もりを行う必要があります。

＃5学習とトレーニング

Seleniumの学習は、他の自動化ツールの学習とは少し異なります。基本的には、単なるスクリプト言語ではなくプログラミング言語の学習が含まれます（ただし、スクリプト言語は、環境設定の変更を行った後に自動スクリプトを呼び出すスクリプトを作成するようなフレームワークを構築する際に役立ちます）。

WebDriverとJavaを組み合わせる場合、コアJavaに精通していれば、Seleniumの自動化を開始するのに非常に良い状態にあると言えます。

Javaの学習に加えて、ANT / Maven（ビルド用）、TestNG / jUnit（ユニットテストフレームワーク）、Log4J（ロギング用）、レポート（レポート用）などの他のテクノロジーを学習するための準備が必要です。このリストは、フレームワークのレベル。このリストが大きくなるほど、時間がかかります。

経営陣がセレンを使用することを決定した場合、これらの学習活動は計画活動と並行して行うことができます。これらのテクノロジーの学習に制限はないため、チームが明確な方向で学習プロセスを開始し、全員が同じページにいることができるように、チームのために明確な計画（シラバス）を用意することをお勧めします。

実際には、私たちテスターは本格的なプログラミング言語を学ぶことにあまり熱心ではなく、これは開発者にとっては簡単なことだと感じています。しかし今、私たちはこの考え方を変える必要があり、プログラミング言語を学ぶことは新しいテストプロセスを学ぶことと同じくらい重要であると考えるべきです。これにより、言語と自動化に関するテスターの知識が増えるだけでなく、アプリケーションが内部でどのように機能するかを理解する機会が得られ、新しいバグを見つける範囲が広がる可能性があります。

＃6環境設定

環境設定は以下を扱います（これに限定されません）：-

  • テスト環境でのコードの設定
  • 実稼働環境でのコードのセットアップ
  • 自動テストをトリガーするためのスクリプトを作成します。
  • レポート用のロジックの開発
  • スクリプトを実行する頻度を確立し、その実装のためのロジックを開発する
  • テストデータとテストケースを入力するためのテキスト/ Excelファイルの作成
  • 環境と資格情報を追跡するためのプロパティファイルの作成

＃7コーディング/スクリプティングとレビュー

実際にテストを書き始める前に、2つの前提条件があります。

  1. 候補となるテストケースは便利なはずです
  2. フレームワークの準備ができました

Webアプリケーションが実行するさまざまなアクションを特定します。ナビゲーション、クリック、テキストの入力などの単純なアクションにすることができます。または、データベースへの接続、フラッシュやAjaxの処理などの複雑なアクション。一度に1つのテストケースを取得し、その特定のテストケースが実行するすべてのアクションを特定し、それに応じてテストケースごとに時間を見積もります。テストスイート全体のすべての時間の合計により、正確な数がわかります。

レビューのための準備もあるはずです。レビューは、ピアまたは開発者のいずれかが実行できる単なるコードレビューです。ペアプログラミングは迅速で最良のオプションですが、それが不可能な場合は、利用可能なリソースまたは組織のレビュー戦略に基づいて、それに時間を割り当てる必要があります。

推定に影響を与える各要因の詳細：

要因＃1：範囲

意味 ：ROIによる自動化の候補テストケースの特定

メッセージでc ++アサート

関係する手順：

  1. 候補となるテストケースを特定するための基礎となるさまざまな要因を特定します。
  2. アプリケーションをより小さなモジュールに分割する
  3. 各モジュールを分析して、候補となるテストケースを特定します
  4. ROIを計算する

成果物： 自動化する必要があるテストケースのリスト。

備考： 他の見積もり手順に進んだら、スコープをフリーズすることが重要です。

要因＃2：複雑さ

意味： 単純で小さなサイズのアプリケーションの定義を確立します。

関係する手順：

  1. 自動化する必要のあるテストケースの数に基づいて、アプリケーションのサイズを決定します。
  2. フィボナッチ数列によるサイズの複雑さ。
  3. 各テストケースの検証ポイントとチェックポイントを特定します。

成果物： アプリケーションのサイズ–小、中、大。

いくつかのテストケースとそれに対応するチェックポイントおよび検証ポイント。

備考 ：推奨–テストケースには複数のチェックポイントを含めることができますが、検証ポイントは1つだけです。テストケースに複数の検証ポイントがある場合は、別のテストケースに分割する必要があります。

要因＃3：サポートツール

意味： Selenium自体は、複雑なフレームワークを構築するのに十分な強度ではありません。フレームワークを構築するためのフレームワークツールのリストが必要です。

関係する手順：

  1. 完成したIDE
  2. 完成した単体テストツール
  3. 完成したロガー
  4. 完成したレポートツール
  5. 完成したビルドツール

成果物： フレームワークの作成に必要なツールのリスト。

備考：

例：

  • Eclipse / RAD-IDEとして
  • Ant / Maven –ビルドツールとして
  • jUnit / TestNG –ユニットテストフレームワークとして
  • Log4j –ロガーとして
  • ReportiNG –レポートツールとして
  • テキストファイル–環境/資格情報を追跡するため
  • Excelファイル–テストデータを追跡するため
  • Perl / Python –環境をセットアップしてテストスクリプトをトリガーするため。

要因4：フレームワークの実装

意味： 構造の作成

関係する手順：

  1. 入力ファイルを設計します。
  2. フォルダ構造を設計する
  3. フレームワークでロガーを決定/実装する
  4. フレームワークにビルドツールを実装する
  5. ユニットテストフレームワークを実装する

成果物：

  • IDEで作成されたフレームワークとフォルダー構造。
  • 入力データを含むExcelシート
  • 環境関連のデータと資格情報を含むプロパティファイル。

備考： これは最も重要なステップです。トラブルシューティングには予想よりも時間がかかるため、見積もりにはバッファ時間を含めることをお勧めします。

要因＃5：環境の設定

意味： コードのセットアップとダウンロード/コード展開の準備を扱います

関係する手順：

  1. 入力ファイルとレポートを準備します
  2. トリガースクリプトを作成する

成果物： 環境に対応

備考： 最小限の手間で、コードが前述の環境/ボックスにデプロイされるようにフレームワークを構築するように努める必要があります。

テキストファイル（URLと資格情報を含む）への最小限のエントリで、コードを実行してロックする準備ができているはずだと言っても間違いありません！

要因＃6：学習とトレーニング

意味： プログラミング言語やその他のサポート技術を学ぶ

関係する手順： 自動化のニーズに応じて計画を作成し、チームと共有して、シラバスに従って学習し、進めるように促します。

成果物： チームの進捗状況を追跡するトレーニングプランとそのトラッカー。

備考： 構文の学習ではなく、ロジックの構築に重点を置く必要があります。

要因＃7：コーディング/スクリプティングとレビュー

意味： 実際のテストスクリプトを作成して確認する

関係する手順：

  1. テストケースとフレームワークの準備が整いました。
  2. テストケースを取得/分割し、自動化されたスクリプトに変換して、進捗状況を追跡します

成果物： 自動テストスクリプト

備考： チーム全体が、実装されたフレームワークを使用してテストスクリプトの作成に参加する必要があります。したがって、見積もりを行う際には、チーム全体の努力を考慮に入れる必要があります。

結論 ：

これらすべての点について述べたので、最終的なSelenium自動化の見積もりに管理オーバーヘッドとバッファ時間を含めることを忘れないでください。見積もりを行うための最良かつ実証済みの方法は、WBS（作業分解図）メカニズムに従うことです。これは簡単で、自動化見積もりの​​ニーズを実装する目的に役立ちます。

上記の要因は私の経験に基づくものですが、戦略に影響を与える可能性のある他のエンティティも存在する可能性があります。

ここでの経験則は 「特定の基準を特定し、それらの基準に基づいてモジュールまたはテストケースを分割します。そしてそれをスケーリングします。」 スケーリングされた数値に基づいて–正確な見積もりを行うことができます。

次のチュートリアル＃33 ： 結論を出します 最も包括的なSeleniumオンライントレーニング無料チュートリアルシリーズ 最後のチュートリアルで、つまり「 セレンテストの面接の質問と回答 」。

Seleniumプロジェクトの労力見積もりに関する他のヒントがあればお知らせください。

テストケースの書き方

推奨読書

^