テスト自動化をゼロから展開するためのヒントとコツ

まえがき

以下に説明するヒントと推奨事項は、2つの会社でゼロからテストと自動化を作成し、3番目の会社で同様の作業を開始した経験に基づいて作成されました。 したがって、すべてを知っている専門家の栄誉について不満はありません。むしろ、最近のトピックである会社のテスト自動化に関する段階的なガイドの形で形成された経験を共有する試みです。



これを読むことに決めた場合、プログラミング言語で自動テストを作成し、特定のプロジェクトのツールを選択するトピックは、それらを統合して厳密なリストを作成することは不可能であるため、すぐに考慮する必要があります-どのプロジェクトが最高のツールを持っている。 ここでは、間違いなく、自分で掘る必要があります。



しかし、一般的なテストへのアプローチ方法、開始する場所、テスト計画を考え出し、テストケースの生成を開始する方法、さらに自動化するテストを選択する方法、作業時間を評価する方法、および一般的な自動化が必要かどうかについては、以下で説明します。



PS：そして最後に-このテキストは、アレクセイ・バランツェフとナタリア・ルコルによる有益な講義と、このトピックに関して近年善良な人々によって書かれた深byの情報がなければ形成されなかっただろう。



これで、警告が表示されます-ストーリーを開始できます。

パート1-テスト自動化の展開

1.テスト自動化戦略の選択（以降-AT）

AT戦略で一般的に使用されるオプションがいくつかあります。 さまざまなATアクティビティの順序と強度は、特定の戦略の選択に依存します。 戦略を選択することは最も重要なタスクではありませんが、そこから自動化の展開プロセスを開始することが最善です。 自動化の展開の最初の段階に固有の戦略について、3つのオプションを提供します。 もちろん、戦略にはさらに多くのオプションがあります;完全なリストは、ナタリアルコルのセミナーで見つけることができます。



1.1戦略を試してみましょう



ATがプロジェクトや会社に一度も参加したことがない場合に使用され、中程度のリソースの割り当てで慎重な開始が計画されます。



次の場合に戦略を適用するのは理にかなっています：

• 正確な自動化の目標はありません（特定の日付までに特定のモジュールのコードの40％をカバーし、手動テストのコストを削減するなど）。
• ATは以前にプロジェクトで使用されたことはありません。
• テスターはATの経験がない（またはほとんどない）。
• 割り当てられたリソースは中程度または低いです。

戦略の説明：

• テストの準備段階（テスト計画、テストケースなどの準備）にさらに注意を払います。
• 手動テストの補助として使用できるツールにもっと注意を払ってください。
• ATテクノロジーと方法論をさらに試してください。 誰も緊急の結果を期待しておらず、実験することができます。
• 特定のモジュールの自動化を掘り下げることなく、最初からプロジェクトをトップレベルから操作します。

1.2戦略「ここが目標」



戦略の特徴は、特定の結果に焦点を合わせていることです。 ATの新しいステージの目標が選択/決定され、タスクはこの結果の達成によって導かれます。



次の場合に戦略を適用するのは理にかなっています：

• プロジェクトの準備作業がすでに実行されている場合、テスト計画、テストケース、ATの前段階の自動テストという形で、何らかの背景があります。
• ATには特定の目標があります（グローバルではなく、6か月間の自動テストの80％ではなく、1か月間の特定モジュールの自動テストの50％）
• 特定の目標を達成するため、特定のツールが選択されました。最適なのは、専門家がツールを使用するための特定の技術的背景を持っている場合です。

戦略の説明：

• 一貫性のある戦略であり、アジャイル開発方法論を幾分連想させる。 段階的に前進します。 フォームのメタタスクが完了するまでのモジュールごとのセルフテストの範囲（6か月間80％）。
• 各段階で、新しい目標が設定され（最後の目標を継続する可能性が高いが、必ずしもそうではない）、この目標を達成するためのツールが選択されます。
• 特定の目標に深く焦点を合わせ、プロジェクト全体ではなく、特定のタスク専用にテストケース、自動テストを作成します。

1.3戦略「ウラン作戦」



実際、戦略は2〜3週間ごとに設定された優先順位に従って、ATで一定かつ系統的な作業です。 最適-サードパーティのタスクに特に気を取られない、自動化に常に正確に取り組んでいる人の存在。



次の場合に戦略を適用するのは理にかなっています：

• 特定の目標はなく、「すべてが良かった」という一般的な欲求のみがあります。 「ここでの目標」がアジャイルの原則に似ている場合、この戦略はウォーターフォールの方法論に近い精神です。
• 少なくとも1人がプロジェクトに常に携わっており、自動化のタスクに密接に従事しているという形のリソースがあります。
• ATの明確に定義された目標はありませんが、十分に長い期間設定できる希望（優先順位）があります（これらのモジュールはそれらよりも重要であり、従来より多くのミスがバックエンド/フロントエンドで発生するため、多くの努力がそれに向けられるべきです）。

戦略の説明：

• 上記の戦略の考え方は、設定された優先順位を考慮に入れた、一定かつ系統的な作業です。
• この戦略のフレームワーク内で、特定のモジュールに完全に焦点を当てることなくプロジェクト全体が自動化されるため、最初は基本部分に重点を置く必要があります。

要約すると：



一般的なロジックと自動化戦略を検討する価値がありますが、次のオプションをお勧めします。1か月（3〜4週間）の初めに、「Let's try」戦略を使用し、特に車自体のコードを深く掘り下げることなく、さらなる作業の基礎を準備します。モジュールのテストと詳細。 この段階が完了すると、さらに作業を行うための既製の基盤ができます。 それから、大まかに言えば、ウォーターフォールまたはアジャイル-どのように取り組むのが便利かを選択する必要があります。 そして、選択された戦略に従って行動し続けます。

2.タスクの並列化

複数の人がプロジェクトに取り組んでいる、またはプロジェクトをテストしている場合、この項目は理にかなっています。 次に、チーム内のタスクを並列化する上で重要なポイントがあります。 ATチームで作業する人が1人だけの場合は、この項目を安全にスキップできます。



互いに近い能力と知識の観点から、テスト自動化プロセスは、類似したタイプの異なるタスクをカプセル化する役割に分割できます。



役割



建築

• ツール選択
• アプローチの選択

開発

• テスト開発とデバッグ
• サポートアップデート
• バグ修正

テスト設計

• テスト選択
• テスト設計
• テストデータ設計

運営管理

• 計画中
• メトリックコレクション
• トレーニング

テスト中

• エラーのローカライズ
• エラーの確立
• テストデータの準備

複数の人がプロジェクトのテストに取り組んでいる場合、特定の人について上記の役割を並列化するのが論理的です。 この場合、「管理」の役割を1人に割り当て、「テスト設計」と「テスト」の役割をすべてに分割し、「アーキテクチャ」と「開発」の役割を1人または2人のヒーローに割り当てることは理にかなっています。



このロジックは次のとおりです。

1. このプロジェクトには明確なテストリーダーがいて、誰が計画を立て、期限を決定し、違反した場合に責任を負います。
2. テスターに​​は、ハンドテスターと自動化の2つの一般的なタイプがあります。 同時に、役割「テスト設計」と「テスト」のタスクは、両方のタイプに等しく関連しています。 したがって、すべてのテスターは、後で手動テストと自動化の両方で使用できるテストを作成および設計します。
3. さらに、作成されたテスト計画とテストケースに従って手動テスターが手動テストを実行し、自動化が開発に適した形式に必要なテストを完了し、自動化に取り組んでいます。

しかし、あなたが男性オーケストラを持っている場合、彼はすぐにすべてを行いますが、彼はすべてのプロではありません。

3.テスト計画の作成

AT戦略を選択した後、次の重要なポイントは作業の開始点-テスト計画の作成です。 テスト計画は、開発者と製品マネージャーとの間で合意する必要があります。テスト計画を作成する段階でエラーが発生する可能性はかなり後であるためです。



良い方法では、テスターが作業する比較的大きなプロジェクトのためにテスト計画を準備する必要があります。 大規模なオフィスで通常使用されるオプションよりも形式化されていないテスト計画について説明しますが、形式的な深byを内部で使用する必要はありません。



テスト計画は、次の項目で構成されています。



3.1テストの対象。



プロジェクトの簡単な説明、主な特性（Web /デスクトップ、iO上のUI、Android、特定のブラウザー/ OSなどで動作します）。



3.2プロジェクトの構成。



プロジェクトのコンポーネントおよびモジュール（詳細は説明していません）、および互いに分離された論理的に壊れたリスト、および大きなモジュールの外部の機能。



各モジュールで、利用可能な関数のセットをリストします（詳細に入ることはありません）。 マネージャーとテストデザイナーは、新しいスプリントのテストと自動化のタスクを定義するときに、このリストから外します（たとえば、「データ編集モジュールに変更が加えられ、ファイルアップロードモジュールが変更され、クライアントで通知を送信する機能が完全にやり直されました」）。



3.3プロジェクトのテスト戦略と計画されたタイプのテスト。



戦略については段落1で説明します。自動化の場合、通常は1種類のテストのみが使用されます-回帰（アプリケーション全体の詳細なテスト、以前に作成されたテストの実行）。 概して、自動テストは他の種類のテストで使用できますが、カバレッジの少なくとも40％に達するまで、これによる基本的な利点はありません。



ただし、テスト計画が自動化エンジニアだけでなく手動テスターでも使用される予定の場合は、テスト戦略全体（自動化ではない）を検討し、使用/必要なタイプのテストを選択またはマークし、この段落にペイントする必要があります。



3.4テストのシーケンス。



テストの準備、タスクのタイミングの評価、テストに関する統計の収集と分析の実行方法。

この段落に何を書くべきかわからない場合は、安全にスキップできます。



3.5テストを完了するための基準



このリリースの一部としてテストが完了したと見なされる時期を簡単に説明してください。 特定の基準がある場合は、それらを記述します。



要約すると：



テスト計画を作成する必要があります。テスト計画を作成しないと、すべての自動化は混chaとして非体系的になります。 手動テスト（非常に貧弱な手動テスト）で、テスト計画、テストケースなしで実行でき、おとりテスターを比較的成功して使用できる場合、これは自動化では機能しません。

4.主なタスクの定義

戦略を選択してテスト計画を作成したら、自動化のテストを開始する一連のタスクを選択する価値があります。



自動化がもたらす最も一般的なタイプのタスク：

• 受け入れテスト（煙テスト）の完全自動化は、テスト部門によるビルドの後に最初に実行されるタイプのテストです。 スモークテストの一部として、常に機能するはずの機能がチェックされ、どのような条件でも機能します。機能しない場合は、開発者との合意により、ビルドがテストに受け入れられないと見なされます。
• 見つかった欠陥の数を最大化します。 この場合、最初に作業ロジックの変更を最も頻繁に受けるシステムのモジュール（または機能の側面）を選択してから、最も日常的なテスト（つまり、少量の変動で同じステップが大量のデータに対して実行されるテスト）を選択する必要があります。
• 手動テストによる「ヒューマンファクター」の最小化。 その後、再び、最も日常的なテストが選択されます。これは、テスターから最も注意を払う必要があります（簡単に自動化できます）。 たとえば、ユーザーインターフェイスのテスト（たとえば、テーブルの60列の名前の確認）、123個の要素を持つコンボボックスの内容の確認、Webページ上のテーブルのExcelへのエクスポートの確認など。
• ほとんどのクラッシュシステムを見つける。 ここでは、「ランダム」テストを適用できます。

自動化の展開の最初の段階で、受け入れテストの自動化のタスクを最も時間のかからないように設定することをお勧めします。 同時に、問題を解決することにより、受け入れられた次のビルドで受け入れテストを実行できます。



煙テストの主な基準は、比較的単純であることと同時に、プロジェクトの重要な機能を強制的に検証することです。



また、不必要なチェックに時間を無駄にしないために、煙テストはポジティブ（システムの正しい動作をチェックし、ネガティブテストはシステムが正しく動作するかどうかをチェックします）であることも理解されています。



要約すると：



自動化のために主要なタスクのリストをコンパイルするとき、最初に煙テストを記述して自動化することが論理的です。 将来的には、それらをプロジェクトに含めて、各アセンブリで実行できます。 数が限られているため、これらのテストのパフォーマンスはアセンブリの速度を低下させることはありませんが、そのたびに重要な機能が引き続き機能するかどうかを確実に知ることができます。

5.選択したタスクのテストケースを作成する

テストケースに関しては、テストプロセスを2つの部分に分割するのが一般的です。既成のシナリオ（テストケース）によるテストと調査テストです。



研究テストに関しては、すべてが非常に明確であり、特別な予備準備なしで新しい機能を研究するか、セモリナテスターを使用した簡単なセモリナテストの形式の2つのバリエーションがあります。 スクリプト化されたテストは、プロジェクトの機能のために時間を費やし、テストスクリプトが作成され、可能な限り大容量であることを意味します。



私の観点からは、最も合理的なアプローチは、新しい機能とモジュールを研究スタイルでテストし、可能性の低いシナリオをテストしようとするアプローチの合理的な組み合わせであり、テストが完了すると、後で回帰テストに使用されるテストケースが作成されます



明白なことに加えて、テストケースをさらに使用するための3つのオプション：

• プロジェクトモジュールのチェックリストをテストケースから生成します。これにより、検証が高速化されますが、主な問題領域がチェックされます。
• 初心者向けのトレーニング-プロジェクトに参加したテスターは、アプリケーションの多くの明らかでない側面をキャプチャするため、テストケースの観点からプロジェクトを学習できます。
• 自動テストの基礎としてさらに使用します。 ATを展開するときにシステムアプローチを使用する場合、テストケースの作成と使用は完全に論理的です。実際、テストケースは既製の自動テストスクリプトです。

テストケースを詳細に説明するための原則については説明しません。このトピックに関する多くの資料がネットワーク上にあります。簡単に説明します。



適切なテストケースは、次の点で構成されています。

1. 名前（説明）は、テストがチェックする内容の非常に短い説明です。
2. システムの準備状態は、テストケースの開始時点でのシステムの状態の説明です。
3. ステップのシーケンス-タイトルに記載されている目的を検証する連続的に記述されたアクション。
4. 期待される結果は、テストケースの一連のステップを通過した後に待機しているシステムの状態です。

テストケースの便利な保存のための多くのソリューションがありますが、私が使用したもののうち、Testlinkアプリケーションは非常に優れていることが証明され、テストケースの実行を作成/保存および追跡するための便利な無料システムであるsitechco.ruシステムが最適であることが証明されました。



要約すると：



さらにATを使用するには、手順4で設定したタスクのテストケースを作成する必要があります。 これらは、通常の回帰テストの作成の開始として同時に機能し、さらなる自動テストの基礎として機能します。



テストケースの作成を計画しているテスターへの推奨事項として、ペアワイズ手法、等価クラス、およびテスト設計手法について読むことをお勧めします。 少なくともこれらのトピックを表面的に学習すれば、優れた有用なテストケースを作成するのがはるかに簡単になります。

6.自動化のためのツールの選択

明らかに-アプリケーションが実行されているプラ​​ットフォームに応じてATツールが選択されます。



AngularJSのバックエンドとiOSベースのタブレットと携帯電話のクライアントの2つの部分で構成されるプロジェクトのツールを選択する例を示します。



1.バックエンド



カルマ+分度器（ジャスミン）。



長所：Protractorツールをシェルとして使用することをお勧めします;これは、AngularJSで記述されたアプリケーションに最適です。 分度器はユーザーの操作を模倣し、Jasmine BDDフレームワークを使用して作成された自動テストを作成できます。 さて、Karmaを使用すると、これらのテストを異なるブラウザーで実行できます。



短所：テスターは、JSで少なくとも単純なスクリプトを作成できる必要があります。 または、プログラマーはこれらのスクリプトを彼に書く必要があり、ATの開発によってオーバーヘッドになる可能性があります。



Selenium Webdriver。



長所：GUI Webアプリケーションのテストを自動化するための便利でシンプルで信頼性の高いツールキット。 一般的に、多くのドキュメント、例の深aは便利です。 最も原始的なバージョンでは、テスターからのプログラミング知識は必要ありません。

短所：ProtractorはAngularJSチームによって作成され、AngularJSをテストしますが、Seleniumはユニバーサルです。 私の観点からは、AngularJSプロジェクトで分度器+ジャスミンのテストを作成する方が便利です。 手動のテスターだけでなく、深刻な自動テストが計画されている場合、柔軟なテスト設定にはプログラミングの知識が必要なため、テスターはプログラミング言語（java、python、ruby、c＃）を知る必要があります。



2.フロントエンド



ひょうたん+キュウリ。



概して、タブレットや携帯電話でiOSアプリケーションを自動化するための最も便利なツールは、Calabash + Cucumberバンドルです。 Calabashは、機能テストを自動化するためのフレームワークであり、本質的には、デバイスまたはシミュレーター上のアプリケーションの動作を制御するドライバーです。 Cucumberは、テストインフラストラクチャ（テストの実行、スクリプトの解析、レポートの生成）を提供します。



Calabashは有料ソリューション（https://xamarin.com/test-cloud）であることを考慮する価値があります。



要約すると：



テスト自動化のためのツールは上記で説明されていますが、これらは利用可能な唯一のツールとはほど遠く、このインフラストラクチャのセットアップと社内でのATの展開に関与している人には、ネットワークを掘り下げて検討することをお勧めします。ツール。

7.自動化のためのテストの選択

そのため、現在の段階では、テスト計画を作成し、モジュールの機能の一部をテストケースとして説明しました。 次のタスクは、既存のさまざまなテストケースから必要なテストを選択することです。 現時点では、スモークテスト用のテストケースしか用意されていませんが、プロジェクトでテストケースの開発を数回繰り返した後は、さらに多くのテストケースがあり、すべてを自動化する意味がありません。



1.次のことを自動化することは非常に困難です。

1. サードパーティのプログラムでファイルを開くことを確認する（たとえば、印刷用に送信されたドキュメントの正当性を確認する）
2. 画像の内容を確認します（この問題を部分的に解決するプログラムがありますが、タスクの単純なカットでは、そのようなテストを自動化せずに、手動テストに任せる方が良いです）
3. ajaxスクリプトに関連するチェック（この問題は簡単に解決でき、さまざまなアプリケーションの解決策がありますが、一般にajaxは自動化がはるかに困難です）。

2.単調な仕事を取り除く。



実践が示すように、1つの関数のみをチェックするには、いくつかのテストケースが必要な場合があります（たとえば、2桁の数字を入力できる入力フィールドがあります。1〜2テスト、「2文字」、「1文字」より慎重に確認するために、値、ゼロ、境界値、および文字入力を伴う否定的なテストがないかどうかのテストを追加します）。 この場合の手動テストに対する自動テストの利点は、フィールドのデータエントリをチェックするテストが1つある場合、入力パラメーターを変更することで簡単にその数を増やすことができることです。



概して、自動テストはテストの最も単調で単調な部分をカバーし、テスターに​​研究テストの余地を残します。



したがって、自動化用のテストケースを選択する場合は、検討する価値もあります。



3.テストの単純さ。



そして、自動化のためにテストケースを選択するための最後の重要な基準は、テストの相対的な単純さです。 テストのより多様なステップ-テストケース自体が悪いほど、自動化が難しくなり、この自動テストが起動時にクラッシュした場合にバグを見つけるのが難しくなります。



最適なテストの長さを決定するまで、自動化のために少量のテストケースを選択し、徐々に経験を積み、ますます複雑になるテストケースを自動化してください。



8.自動化のためのテストの設計

テストケースは通常、単純な人間の言語で書かれているため、自動化のために選択されたテストケースを追加して修正する必要がありますが、さらに自動化するためのテストケースは、翻訳しやすいように必要な技術的詳細を追加する必要がありますコード（やがて、どのテストを生きた言語で記述する必要があり、どのテストをテストケースの作成段階でも詳細かつ明確に記述する必要があるかが理解されるようになります）。



したがって、自動化を目的としたテストケースの内容について、次の推奨事項を策定することができます。



1.自動テストケースで期待される結果は、非常に明確かつ具体的に説明する必要があります。

• 悪い：結果-[フォーム]ページが開きます。
• 良好：結果-フォームページが開き、ページに検索フォーム<input type = "text" placeholder = "Search" ..>が含まれ、要素css = div.presentations_thumbnail_boxおよびlink = Notesがあります。

2.ブラウザとテストを実行するアプリケーションの同期の機能を考慮します。



テストでリンクをクリックすると、新しいページでのアクションの次のステップが記述されたとします。 同時に、ページは長時間ロードされる可能性があり、アプリケーションは、目的のアイテムのダウンロードの開始を待たずにエラーで失敗します。 多くの場合、これは、要素のロードを待機するパラメーターを設定することで簡単に解決できます。

• 悪い：トップメニューの[フォーム]リンクをクリックします。 変更を確認します。
• 良い：トップメニューの[フォーム]リンクをクリックします。 「変更を保存しますか？」というテキストを含むフォームが表示されるまで待ちます。 「OK」ボタンをクリックします。

3.テストケースにハード値を書き込まないでください。



必要でない場合のみ。 ほとんどの場合、テスト環境を作成するときに適切なデータが決定されるため、自動テストを作成するときに値を選択する方が最適です。

• 悪い：スライド「スライド1_11」を開きます
• 良い：プレゼンテーションの最初のスライドが開いています。

4.自動テストケースは独立している必要があります。

ルールには例外がありますが、ほとんどの場合、テストケースの前後にどのテストケースが実行されるかわからないと想定する必要があります。

• 悪い：前のテストで作成されたファイルから...

5.使用するツールのドキュメントを注意深く調べることは価値があります。



そのため、誤って選択されたコマンドが原因でテストケースが偽陽性になる、つまり、 アプリケーションが正常に動作しない状況で成功します。



要約すると：



自動化を目的とする正しく記述されたテストケースは、テストされたアプリケーションの正しい動作の記述というよりも、人間が理解できる小さなプログラムを開発するためのミニチュア技術タスクに非常に似ています。 以下に、自動化のために再設計されたいくつかのテストケースを示します。 残りの部分は、プロジェクトテスターが上記のルールに従ってやり直せると思います。

9.自動化のためのアプリケーションスタックのセットアップ

次のステップ（または複数の専門家の場合の並行タスク）は、自動テストの作成と実行に関する今後の作業で使用するアプリケーションのスタックを展開することです。

これらのインストールオプションの詳細については説明しません。すべての情報はネットワーク上にあります。ソリューションの検索を開始するには、各オプションに1-2リンクを添付します。



バックエンド



1.カルマ+分度器（ジャスミン）



-Karma +分度器-ツールをデプロイするための優れたツール-mherman.org/blog/2015/04/09/testing-angularjs-with-protractor-and-karma-part-1/#.VpY21vmLSUk

-分度器+ Jasmine-Jasmine engineering.wingify.com/posts/e2e-testing-with-webdriverjs-jasmineをインストールして設定します



このスキームを選択した場合、テストを自動的に実行するには、Karmaと継続的インテグレーションシステムの1つを「友達にする」必要があります。 私にとって最も興味深いと思われる2つのオプション、JenkinsとTeamcityを提供しています。



-Teamcity-ソリューションは非常にシンプルで、 karma-runner-reporterプラグインをインストールするだけです。

-Jenkins-同様に-karma-jenkins-reporterプラグインをインストールする簡単なソリューション。



2. Selenium Webdriver



ソリューション自体はあまりエレガントではありませんが、これは上記のとおりです。 それでも簡単な方法を選択する場合は、次のように入力します。



- セレンIDE ;

-IDEから取得したテストが明らかに十分でない場合のSelenium Webdriverを使用する原則はここで読むことができます 。



ツールをインストールした後は、継続的インテグレーションシステムでそれらを実行します。繰り返しになりますが、私は、（私の意見では）最も便利な2つのオプション、TeamcityとJenkinsを提案します。



-Teamcity-IDEからのテストを言語（C＃、Java、Python、Ruby）のテストに変換し、Teamcityで起動を構成します。 1つの解決策は記事にあります。

-ジェンキンス（率直に言って- 難しい）。



フロントエンド



1.カラバッシュキュウリ+



- 第一実施形態のインストール。

-2 番目のインストールオプション。



その後、楽しい部分が始まります-Calabashを継続的インテグレーションシステムと連動させます。



-Teamcityはおそらく私が見た中で最も良いオプションです。

-ジェンキンス-それも簡単ではありません。開始するオプションとして。



要約：



繰り返します-自動化のためのチューニングツールの機能-まったく異なる記事のトピック-特定のソリューション用に選択されたアプリケーションスタックを構成する方法の例を示しました。また、一般的なテスト手法が非常に安定している場合、特定のアプリケーションおよび自動化言語の選択は、プロジェクトの詳細に完全に依存するタスクです。

10.テストデータの準備

このコンテキストでは、テストデータとは、テストが開始された時点でのアプリケーションの状態を指します。自動テストで使用される値とパラメーターはほとんど常に「ハードコード化」されており、柔軟性が非常に低いことを考慮すると、アプリケーションのどの状態でも実行できる可能性は低いと想定するのは理にかなっています。たとえば、顧客がこれらの記事を参照する実稼働システムや、編集する記事がまったくない完全にクリーンなシステムで、一般的な記事の編集をチェックする自動テストを実行することはほとんどありません。



最初のケースでは、自動テストは多くの不要な作業を行い、2番目のケースでは実行できません。

したがって、自動テストを正しく使用するには、事前にアプリケーションをこれらのテストに対応する状態にする必要があります。



ここには特別なルールはありません。テストから始めれば、すべてが直観的に明確です。唯一の注意点は、通常、自動テストは独立したテストの独立したセットによって実行されることです。この場合、1つのセットのテストはランダムな順序で実行されることがよくあります。したがって、自動テストを作成するときは、1つのテストが完了してもセットの他のテストを実行できるように、自動テストを作成してください。

• 不良-テストは最初に準備されたファイルにアクセスし、プロセスで削除します。以下によって起動される別のテストも、すでに削除されたファイルを参照する必要があります。エラーが発生します。
• 良い-ファイルを削除するテストは、作業の開始時にファイルを作成するか、作業の終了時にファイルを作成します。したがって、ファイルはテストの前後に存在します。

11.自動テストの開発と開始

おそらく、これはすべての中で最も短い章になるでしょう-セルフテストを書く方法、人間の言語で既製の空白とツールの拡張されたスタックを持つ-は、以下のリンクで詳細に説明されています：

• 分度器+ジャスミン-angular.github.io/protractor/#/tutorial
• Selenium IDE-forworktests.blogspot.ru/2013/03/selenium.html
• セレンwebdriverを- www.seleniumhq.org/docs/03_webdriver.jsp
• ひょうたん-habrahabr.ru/post/219655

また、一般に、自動テストの開発に関する一般的な推奨事項はこちらで読むことができます。



頑張って

マニュアルの11章の要約

上記のすべての推奨事項を満たし、自動テストを設定、作成、および実行した後、作業の最も重要な部分を実行しました。プロジェクトにテスト自動化を展開し始めました。



自動テストがプロジェクトのテストプロセスの不可欠な部分になるまで、テストケースの作成、ツールのセットアップ、適切で有益なレポートの生成など、多くのタスクが先にありますが、最初のステップは完了しています。



マニュアルの2番目の部分では、テスト、メンテナンス、または持続可能性タスクの新しいサイクルごとに、自動化エンジニアが直面するタスクについて説明します。自動テストを熟考して分析することが習慣になるまで、かなり頻繁にそれらに戻る必要があります。

マニュアルの最初の章はすべて正常に完了しました！



この場所で、シャンパンを抱きしめて喜んで飲むことができます！



おめでとうございます、最初の一歩が踏み出されました！

パート2-テスト自動化プロセスの開発と保守

12.自動化の有効性の評価

ある時点で、ATに関与するほとんどすべての専門家は、個々のモジュール、機能、およびプロジェクト全体での自動テストの有効性の問題に直面します。残念ながら、テストの自動化の開発およびサポートコストは見返りがなく、定期的な手動テストの方が便利なことがよくあります。重要な瞬間にこれに遭遇しないために、開発の2番目または3番目のサイクルから開始する自動テストの有効性を検討することをお勧めします。



パフォーマンス評価は、2つの論理フィールドで考慮され



ます。1.一般的な自動化の有効性の評価。



マニュアルと比較したATの有効性の評価は、次のアルゴリズムによって非常に近似的に計算できます。

1. , ( , ), , — TAuto.
2. , - -, — TMan.
3. ( , ) , — TManRun.
4. , — TAutoRun.
5. , — TAutoMull.
6. ( — ) — N.
7. , . R.

TManTotal = N * Tman + N * R * TManRun

TAutoTotal = TAuto + N * TAutoRun + N * R * TAutoMull



したがって、TManTotal> = TAutoTotalオートメーションが理にかなっている場合、次の式を導き出します。



この調査は、自動化の有効性に関するデータがまだない新しいモジュールまたは新しい大規模な機能の作業を計画する際に、これらのコストが報われるかどうかを判断するために実行できます。



2.自動テストの有効性の評価



定期的に（理想的にはテストサイクルごとに1回）、個々の自動テストの有効性を評価する必要があります。



このような調査を実施する理由はいくつかあり



ます。1.機能の動的な変更。



開発者は、オートテストですでにカバーされているプロジェクトモジュールの1つを強く再描画することを約束することがよくあります。このモジュールの機能のロジックが変更されると、テスト中のテストがエラーで失敗し始めることは論理的です。そして、新しい条件で動作するように書き直し始めます。そして、ロジックが再び変わります。などなど。



これは、近い将来にモジュール機能のロジックがさらに変更される可能性があるかどうかを停止して評価する必要がある場所です（開発者とのコミュニケーション）。何が変わり、何がまだ計画されていませんか？



したがって、すべての作業が完了するまで動的に変更されるものをやり直さないでください。自動テストの代わりに、この領域を手動で一時的にテストしてください。



作業が計画されておらず、モジュールがしばらく安定している可能性が最も高い場合、テストは新しい条件に正しく変更されます。



2.仕事の重複。



長いアイドルモジュールに新しい機能が追加され、新しいテストケースと自動テストが書き込まれることがあります。また、新しいテストが重複したり、既存のテストを複製したりすることもあります。この考え方を念頭に置いて、ビルドの各ビルドを完了するのに時間がかかるだけの意味のない重複があるかどうかを時々確認する必要があります。



3.ランタイムの最適化。



最初は、まだいくつかの自動テストがある場合、各ビルドで非常に高速に実行されますが、自動テストの数が増えると、各テストビルドの時間が長くなります。エラーが検出された場合、または新しい機能で中断するテストが表示された場合、テストアセンブリの完了を待機するたびに、テストアセンブリを何度も再起動する必要があります。



時々、実行するすべてのセルフテストが作業に必要かどうかを停止して監視する価値があります。



テストを開発する場合、テストの種類（クリティカル、マイナー、トリビアル）でマーカーを配置することは良い解決策です。また、特定のタスクに対して特定のテストグループを実行するようにツールを構成します。たとえば、完全なリグレッションテストでは、すべてのマークでテストを実行する価値があります。エラーを見つけて修正する場合は、特定のセットのセルフテストを実行して、時間をかけすぎないようにすることができます。



4.テストを実行するロジック。



自動テストの実行の効率を向上させるには、それらの起動のメカニズムを徹底的かつ慎重に検討することが正しいでしょう。



最も人気のあるモデル：



テストの優先度：

• クリティカル
• メジャー
• マイナー
• 些細な

上記のモデルは、テストスイートの管理に使用されます。



テストのモジュール化：

• モジュール1
• モジュール2
• モジュール3
• ...

論理的には、特定のモジュールに対して新しい自動テストが書き込まれた場合、または古い自動テストが書き換えられた場合、上記のメカニズムのように見えます。実行ごとにすべてのテストを実行しても意味がありません。



起動の必要性：

• 起動する
• 走らないで

この自動テストが正常に機能しないことは確かです（関数は変更されていますが、テストは書き直されておらず、テストは正しく機能しません）。または、このテストがキャッチするエラーについて知っていますが、すぐに修正する予定はありません。この場合、各実行で落ちるテストは私たちにとって不便かもしれません。これを行うには、テストにラベルを埋め込むことができます;指定された場合、テストはCIで開始されません。問題を修正するために、テストを再度実行できます。



打ち上げ時間：

• スケジュールによると-たとえば-午前5時に現在のテスト/安定ビルドのアセンブリ、仕事に来るまでに、テストに合格したというレポートがあなたを待っています。
• アプリケーションが変更された場合、現在のテストリポジトリブランチに新しい変更セットが表示されたら、自動テストを再開します。
• テストを変更するとき-同様に、リポジトリ内の自動テストを更新するとき。
• オンデマンド-標準のオンデマンド起動。

要約：



プロジェクトにATを実装したいという強い要望がある場合、いくつかの開発サイクルの後、時間をかけて進行中の自動化の有効性を計算することが役立ちます。そして定期的に結果を再確認してください。また、自動テストの有効性を定期的に評価する習慣を身に付けます。

13.タスク完了時間の推定

各テストサイクル（リリースのリリース）の前に、テストの作業を開始する前に、マネージャーは手動テストと自動化に費やされる予定の時間を評価します。テストサイクルでの自動化に費やされる予定の時間は、予測可能性が高くなるほど、自動テストの対象範囲が広がります。



時間コストを見積もるという観点からは、自動化のために計画されたテストを2つのタイプに分けるのが慣例です



。1.研究。



研究テストとは、リードタイムの​​見積もりを出すことが非常に難しいタスクです。これにはさまざまな理由が考えられます：自動化のための新しいツールの導入と研究、プロジェクトでこれまで使用されていなかった新しいタイプのテストが必要、プロジェクトの自動化の開始、または自動化の経験の浅い人の時間の推定



研究の特性を備えたタスクが設定されている場合、次の質問をして評価する必要があります。

• このタスクを自動化することは可能ですか？おそらく、答えは「いいえ」になり、手動テストに戻すだけで済みます。
• 自動化にはどのツールを使用する必要がありますか？おそらく新しいツールが必要であり、それを開発するのに時間がかかるか、十分に古いでしょうが、その使用のための回避策を探す必要があります-これも時間がかかります。

概して、そのようなタスクの正確な評価は不可能であり、常に概算になります。次の手法を使用できます。

• 「このタスクにどれだけ時間を費やす準備ができているのか」という観点からの評価の問題へのアプローチ。時間枠を設定する必要がありますが、これを超える価値はありません。割り当てられたフレームワークで問題が明らかに解決されない場合は、解決する価値がない場合があります。
• タスクが完了したとみなされる基準に達すると、それをやめる必要があります。

2.複製。



設定されたタスクと同様のタスクの実装に関する統計を収集できれば、タスクは複製可能です。通常、これらは、新しいタイプのテストを使用せずに自動テストを作成するタスク、自動テストの対象範囲を拡大する、テストおよびインフラストラクチャをサポートする通常のタスクです。



このようなタスクは、同様のタスクが既に完了しており、実行のおおよその時間を知っているため、評価するのに十分簡単です。それは私たちを助けるでしょう：

• 同様の自動化タスクの実行時間に関する予備統計の収集。
• そのようなタスクを実行する際に直面したリスクに関する統計の収集。

要約：



自動テストによるプロジェクト機能の対象範囲が広いほど、自動化に予定されている時間の推定はより正確になります。



マニュアルの要約：



テスト自動化については、これだけです。ここでは、私の経験の一部と、多くの標準自動化技術の使用と理解についてのみ説明します。書くのは面白かったし、読んでくれてありがとう！