プロジェクトで自動化テストを始めるための完全なガイドです。
自動テストとは何ですか
自動テストは、実際の結果と期待される結果をテストして比較するソフトウェアのテスト技法です。 これは、テスト スクリプトを書いたり、自動テスト ツールを使用したりすることで実現できます。 テストの自動化は、手動で行うのが困難な反復タスクやその他のテスト タスクを自動化するために使用されます。
プロジェクトの自動テストを開始したいが、以下のような最も基本的なステップで苦労していませんか
- どうやってプロジェクトに自動化を導入するか
- 最適で正しい自動ツールを選択する方法
- スクリプトを効果的に開発する方法
- テスト スクリプトを実行および保守する方法
- そして最後に、自動テストを成功させるために従う必要のあるベスト プラクティスとは何か
?
本日、「自動テストを始める」についての一連のチュートリアルで皆さんの知識を豊かにしようと計画しました。
あなたのプロジェクトで自動化を始めるための一連のチュートリアルを見てみましょう!
エンドツーエンドの自動化プロセス：
チュートリアル#1：プロジェクトで自動化を始めるためのベストガイド
チュートリアル#2：自動化テストの種類といくつかの誤解
チュートリアル#3：プロジェクトに自動化を導入する10のステップ
チュートリアル#4：最適な自動化ツールを選ぶためのA to Zガイド
チュートリアル#5：スクリプト開発と自動化のフレームワーク
チュートリアル#6: 自動化ツールは、自動化されたテストのために必要です。
自動化のヒント：
チュートリアル#8：テスト作業を自動化する前に読むべき10のヒント
チュートリアル#9：テスト計画は手動と自動化プロジェクトでどう違うのか
チュートリアル#10：いつ自動化を選択するのか
自動化されたテストはどのようなものなのか
自動化されたテストはどのようなものなのか
自動化されたテストはどのようなものなのか
自動化されたテストはどのようなものなのか
手動テストと自動化されたテストの違いは？
Tutorial #11:
自動化テストの課題
Tutorial #12: 自動化における概念実証 (POC) の実装ガイド
Tutorial #13: 自動化のために正しいテストケースを選択する方法
Tutorial #14: 手動テストケースを自動化スクリプトに変換する方法
自動化キャリア:
Tutorial #15: より良い自動化テスターとなるためのヒント
Tutorial #16: テスト自動化 – それは専門キャリアなのでしょうか?
人気のある自動化ツール：
チュートリアル#17：Seleniumチュートリアル 31+ Best Free Selenium Training Tutorials
Tutorial #18: QTPチュートリアル
チュートリアル#19: SoapUI Webサービステストツール
Tutorial #20: HP LoadRunner for Performance Testing
自動化フレームワーク：
チュートリアル#21.Automation(自動化)フレームワーク:Automation(自動化)フレームワークとは？ なぜ自動化のためのフレームワークが必要なのか
チュートリアル#22: 最も人気のある自動化フレームワーク
アジャイルにおける自動化:
チュートリアル#23: アジャイルワールドで効率的な自動化を行う方法
その他の自動化ツール:
チュートリアル#24: 最高の自動テストツール
チュートリアル#25: Sikuli GUI自動化ツール
チュートリアル#26.Automation.Tools
Automation: 自動化されたテストのためのツール
自動化されたテストのためのツール
自動化されたテストのためのツール
p PowerShell。 PowerShellでデスクトップアプリケーションのUIを自動化する
Tutorial #27: Katalon Automation Recorder (Selenium IDE Alternative)
Tutorial #28: Geb Tool: Geb Toolを使ったブラウザの自動化
Tutorial #29: AutoIt: AutoItを使ってWindowsのポップアップを処理する方法
Tutorial #30: Cucumber:
モバイル自動テスト:
Tutorial #32: Appium Studio Hands-on Tutorial
Tutorial #33: Appium Tutorial for Beginners
Tutorial #34: Selendroid Tutorial.を使ったモバイル自動テスト
Mobile Automation Testing:
Mobile Automation Testing:
Mobile Automation Testing:
自動テスト:
自動テスト:
自動テスト:
自動テスト:
テスト:
テスト:
テスト: 自動テスト:
テスト: r Androidモバイル自動化フレームワーク
Tutorial #35: Ranorex Tutorial:
ドメイン固有の自動化例:
チュートリアル#36: JAVA/J2EEアプリケーションの自動化
自動化のための面接対策:
チュートリアル#37: 自動化テストの面接質問
チュートリアル#38: Selenium面接質問
「The Ultimate Guide to Automation Testing」シリーズから最初のチュートリアルを見てみましょう！
自動化を行うには、どのようにすればよいのでしょうか？
自動化テストとは
ソフトウェアが何でもできるのであれば、なぜソフトウェアはソフトウェアをテストできないのでしょうか
この文はあなたにとって論理的に聞こえますか?
もしそうなら、おめでとうございます。あなたは今、この一連の有益なチュートリアルで説明する中心点である、テストの自動化について考えています。 あなたは、テストするアプリケーションを提示されます。 それは、100以上のフォームと数千のレポートを含むERPアプリケーションです。
あなたは、約50の異なるフィールドを含むフォームを開き、探索的テストを開始します。 そして、送信を押します。 エラー! 処理されない例外のように見えるエラー メッセージが表示されます。 あなたはとてもうれしくなりました。 あなたは誇らしげにその手順を書き留め、バグ管理システムにバグを報告しました。 よく頑張った！自信と元気が湧いてきた。 あなたは、その日が終わるまでテストを続け、さらにいくつかのバグを発見しました。 「
さて、翌日になると、開発者は問題を修正し、ビルドの新しいバージョンをリリースしました。 同じフォームを同じ手順でテストし、バグが修正されていることを確認しました。 そして、修正済みとマークします。 素晴らしい努力です。
さて、3 日目になると、開発者が再び新しいバージョンをリリースしました。 今度は、リグレッションの問題がないことを確認するために、再びそのフォームをテストする必要があります。 同じ20分です。
さて、今から 1 か月後、新しいバージョンが常にリリースされ、リリースのたびに、この長いフォームと同様のフォーム 100 個をテストし、回帰がないことを確認しなければならないことを想像してみましょう。
今、あなたは怒りを感じ、疲れを感じています。 ステップをスキップし始めます。 全フィールドの 50% 程度しか入力しません。
そしてある日、クライアントが同じフォームに同じバグがあると報告しました。 あなたは情けなく感じています。 あなたは今、自信がないように感じています。 自分は十分な能力がないと思っている。
あなたにお知らせがあります。これは、世の中のマニュアル テスターの 90% が経験することです。 あなたも同じです。
リグレッションの問題は、最も苦痛な問題です。 私たちは人間です。 そして、毎日同じことを同じエネルギー、スピード、正確さで行うことはできません。 これは機械がやることです。 これが、最初に繰り返したのと同じスピード、正確さ、エネルギーで同じ手順を繰り返すために、自動化が必要なのです。
私の言いたいことが伝わったでしょうか！
こうした状況が発生したら、テストケースは自動化すべきなのです。 テストの自動化はあなたの友人です。 自動化により、回帰に気を配りながら、新しい機能に集中することができます。
スクリプトはすべてのフィールドを埋めて、スクリーンショットとともに結果を教えてくれます。 失敗した場合、テスト ケースが失敗した場所をピンポイントで特定できるので、簡単に再現するのに役立ちます。
しかし、スクリプトが準備できたら、同じ精度で何百回も繰り返し実行することができ、しかもかなり速く実行できます。 これにより、手動テストにかかる多くの時間を節約できます。
自動化を必要とするシナリオ
上記のシナリオは、自動テストが必要になる唯一のケースというわけではありません。
たとえば、
- ピクセルごとに 2 つの画像を比較する
- 数千の行と列を含む 2 つのスプレッドシートを比較する
- 10万人のユーザーの負荷でアプリケーションをテストする
- パフォーマンスのベンチマーク
- 異なるブラウザーや異なるオペレーティング システムで並行してアプリケーションをテストする
。
これらの状況は、ツールによるテストを必要とし、そうすべきものです。
では、いつ自動化するのでしょうか
これは、SDLC におけるアジャイル方法論の時代であり、開発とテストがほぼ並行して行われるため、いつ自動化するかを決めるのは非常に困難です。
自動化に踏み切る前に、次の状況を検討してください
- 製品が UI もない初期の段階の場合もありますが、その段階では、何を自動化したいかを明確に考えなければなりません。 以下の点を覚えておく必要があります。
最適な自動化事例を決定する方法:
自動化はテストサイクルの不可欠な部分であり、自動化を決定する前に、自動化によって何を達成したいかを決めることが非常に重要です。
自動化がもたらすように見えるメリットは非常に魅力的ですが、同時に、整理されていない自動化スイートはゲーム全体を台無しにしかねません。
このシリーズでは、正しいテストケースを選び、持っている自動化スクリプトで正しい結果を出すために、自動化スイートがいかに効率化できるのかについて説明します。
また、「いつ自動化するか」「何を自動化するか」「何を自動化しないか」「どのように自動化を戦略するか」といった質問への答えも取り上げました。
自動化に適したテスト
この問題に取り組む最善の方法は、製品に適した「自動化戦略」をすばやく思いつくことです。
それでは、深く掘り下げて、各グループが何を達成するのに役立つかを理解しましょう。
#1) すべての基本的な機能のポジティブなテストからなるテストスイートを作成する。 このスイートは自動化されるべきで、このスイートが任意のビルドに対して実行されると、結果がすぐに表示されます。 このスイートで失敗するスクリプトは S1 または S2 の欠陥につながり、そのビルドは失格にすることができます。
追加のステップとして、この自動テスト スイートを BVT (Build verification tests) の一部として追加し、QA 自動スクリプトを製品構築プロセスにチェックすることが可能です。
これにより、次のような自動化の目標が達成されます:
- テストの労力を削減する。
- 初期の段階でバグを見つける。
#2）次に、エンドツーエンド テストのグループがあります。 エンド ツー エンド ソリューション テストに触れるいくつかの自動化スクリプトも用意する必要があります。
自動化テスト スイートは、統合部分のいずれかが壊れている場合に示される必要があります。 このテスト スイートは、ソリューションの個々の小さな特徴/機能をカバーする必要はありませんが、全体として製品の動作をカバーする必要があります。
よりよく理解するために、私たちがオンライン ショッピング ポータルをテストしていると仮定しましょう。
したがって、このようなスクリプトが実行されると、ソリューション全体として正常に機能していることを確信できます。
第三のセットは、特徴/機能ベースのテストです。
たとえば、ファイルを参照して選択する機能があるとします。これを自動化するとき、異なるタイプのファイルの選択、ファイルのサイズなどを含むケースを自動化し、特徴テストを行うことができます。 その機能性に何らかの変更/追加があったとき、このスイートは回帰スイートとして機能します。
#4) リストの次は、UI ベースのテストです。 ページネーション、テキスト ボックスの文字数制限、カレンダー ボタン、ドロップダウン、グラフ、画像、および多くのそのような UI のみを中心とした機能など、純粋に UI ベースの機能をテストする別のスイートを持つことができます。 これらのスクリプトの失敗は、UI が完全にダウンしているか、特定のページが期待どおりに表示されない場合を除き、通常はあまり重要ではありません！
#5) 単純だが手動で実行するのが非常に面倒な別のテスト セットを用意することができます。 たとえば、1000 人の顧客の詳細をデータベースに入力することは単純な機能ですが、手動で実行するのは非常に面倒です。
自動化してはいけないもの
以下に、自動化してはいけないいくつかのテストを挙げます。
#1) 否定テスト/フェイルオーバー テスト
否定テストやフェイルオーバー テストの自動化を試みるべきではないでしょう。 ここで一般化すると、このようなテストの主な目的は、意図的な障害を発生させ、製品の信頼性をどの程度管理できるかを見ることです。
上記の障害のシミュレーションは簡単ではありません。
2 アドホック テスト
これらのテストは常に製品に関連しているとは限らず、プロジェクト開始の段階でテスターが思いつくことでさえあるかもしれません。
たとえば、データの圧縮/暗号化を扱う機能をテストしているテスターは、さまざまなデータ、ファイルの種類、ファイル サイズ、破損したデータ、データの組み合わせ、異なるアルゴリズムの使用、複数のプラットフォームなどに対して、徹底したアドホック テストを行ってきたかもしれません。
自動化を計画する際には、優先順位をつけ、その機能だけのためにすべてのアドホック テストを徹底的に自動化するのではなく、他の主要な機能を自動化するための時間を少し確保するようにするとよいでしょう。
#3> 膨大な事前設定を必要とするテスト
膨大な事前条件を必要とするテストも存在します。
たとえば、一部の機能で他社のソフトウェアと統合する製品があります。その製品は、システムへのインストール、キューの設定、キューの作成などを必要とするメッセージング キュー システムと統合します。
サードパーティ製ソフトウェアは何でもよく、セットアップは本質的に複雑である可能性があり、そのようなスクリプトが自動化されている場合、これらは永遠にそのサードパーティ製ソフトウェアの機能/セットアップに依存します。 プロジェクトが保守段階に入ったときに、プロジェクトが別のチームに移され、実際のテストは非常に単純なのに、サードパーティ製ソフトウェアの問題によりスクリプトが失敗するようなスクリプトをデバッグすることになるのを何度も目にしてきました。
上記はほんの一例ですが、一般に、単純なテストに続く手間のかかる事前設定があるテストに注意してください。
テスト自動化の簡単な例
ソフトウェアをテストするとき (Web またはデスクトップ)、通常はマウスとキーボードを使って手順を実行します。
たとえば、電卓をテストしている場合、テスト ケースは 2 つの数字を加算して結果を見るというものです。 The script will perform the same steps by making use of your mouse and keyboard.
The example is shown below.
Manual Test Case Steps:
- Launch Calculator
- Press 2
- Press +
- Press 3
- Press =
- The screen should display 5.
- Close Calculator.
Automation Script:
//the example is written in MS Coded UI using c# language.public void TestCalculator(){//launch the applicationvar app = ApplicationUnderTest.Launch("C:\\Windows\\System32\\calc.exe");//do all the operationsMouse.Click(button2);Mouse.Click(buttonAdd);Mouse.Click(button3);Mouse.Click(buttonEqual);//evaluate the resultsAssert.AreEqual("5", txtResult.DisplayText,”Calculator is not showing 5);//close the applicationapp.Close();}
The above script is just a duplication of your manual steps. The script is easy to create and easy to understand as well.
What are Assertions?
The second last line of the script needs some more explanation.
Assert.AreEqual(“5”, txtResult.DisplayText,”Calculator is not showing 5);
In every test case, we have some expected or predicted result at the end. In the above script, we have an expectation that “5” should be shown on the screen. The actual outcome is the result that is displayed on the screen.
同じことが自動テストにも当てはまります。
あるツールはそれを「アサーション」と呼び、あるものは「チェックポイント」と呼び、あるものは「バリデーション」と呼びます。 しかし基本的には、これは単なる比較です。
テストケースがアサーションによって失敗している場合、それはテスト自動化によってバグを検出したことを意味します。
上記のスクリプトでは、2 番目の最後の行でアサーションを実行しています。 5 は期待される結果、txtResult. DisplayText が実際の結果で、これらが等しくない場合、「Calculator is not showing 5」というメッセージが表示されます。
結論
しばしば、テスターはプロジェクトの締め切りに遭遇し、テストの見積もりを改善するためにすべてのケースを自動化しなければならない、という指令を受けています。
それらは次のとおりです:
- すべてのテストケースを自動化できる。
- テストを自動化すればテスト時間を大幅に短縮できる。 計画や順序なしにすべてのテストを自動化すると、メンテナンスが大変で、頻繁に失敗し、多くの手動介入も必要な、巨大なスクリプトになります。
適切な候補をグループ化して自動化することで、多くの時間を節約し、自動化のすべての利点を得ることができます。
この優れたチュートリアルは、わずか 7 つのポイントにまとめることができます。
- 期待される結果と実際の結果を比較する（アサーション）。
- 反復的だが必要なタスクを自動化できる（例：回帰テストケース）。
- 手動で行うのが困難なタスクを自動化できる（例：回帰テストケース）。
- スクリプトはすばやく繰り返し実行できます。
- 長期的に費用対効果があります。 そこには課題、リスク、その他多くの障害があります。
このシリーズの今後の予定:
今後のチュートリアルでは、自動化に関連するいくつかの側面について説明する予定です。
- 自動テストの種類といくつかの誤解
- 組織に自動化を導入する方法と、テストの自動化を行う際のよくある落とし穴を回避する方法です。
- ツール選択プロセスと各種自動化ツールの比較
- スクリプト開発と自動化フレームワークの例
- テスト自動化の実行と報告
- テスト自動化のベストプラクティスと戦略
- テスト自動化で最も重要なこと
- テスト自動化で最も重要なこと
- テスト自動化で最も重要なことは？