こんにちは
昨日、答えて、この質問に6度目に、彼は記事を書く時が来たと固く決心したようです。 すぐに注意します-これはもっぱら私のビジョンであり、自動化の世界の半分は同意しないと確信しています-私のレシピは、「ツールについて読む」、「ツールを置く」、「ツールを使用する」、「履歴書でできることを書く」よりもやや複雑ですトゥルザを使用してください。」
この記事は、日常のチェックを自動化する手動テスターだけでなく、一般に受け入れられている基準がないためにQA Automation Engineerが誰であるか、ほとんどの場合決定するビジネスおよびHRにとっても有用です。 「良い男」に基づいて
それはさらに悪化します-マネージャー/ PM /など...手動テスターのところに来て、次のように言います。「聞いて、テストを自動化するかもしれません-これにより多くの時間とお金を節約できます。 必要な本とコースを教えてください。
0.すべきではない間違いから始めましょう。
- 私のために何でもできるスマートな本をくれ
- すべてを教える有料コースを教えてください
- 私のすべての質問に答える専門のフォーラムをください。
- どこでも受け入れられる便利な証明書をください
これはすべて良いですが、以下で説明するレシピに加えてのみです。 決してこれで始めることはできません。
1.まず、プログラミング言語を選択する必要があります
ツールではなく、TestCompleteではなく、マクロのようなスクリーンポークでもありません。 オブジェクト指向プログラミング言語。 以前はC＃で少し作業してからJavaを選択しましたが、それでも後悔していませんでした。 しかし、私は主張しません。 Javaで解決できない問題はまだ1つも発生していないと言えます-DelphiアプリケーションでもWinAPIを使用してテストされます（ただし、そのようなタスクなどにはDelphic DUnitを使用することをお勧めします）。
したがって、プリミティブ、クラス、オブジェクト、ポリモーフィズム、カプセル化、インターフェイス、抽象クラス、静的フィールド、ループ、配列、シート、マップ、フローなどを学習します。この調査は、いつでも全体として継続されます。すでにテストを自動化しています。 しかし、基本的なレベル-ジュニアJava開発者-では、（Javaを選択した場合）言語に精通し、適切なスキルを身に付ける必要があります。これは、問題の主要なローカリゼーションが肩にかかっているためです。 「スクリプトがありますが、エラーは理解できず、理由もわかりません」ということは忘れてください-開発者は、ここで近くの人がアプリケーションを起動しなくてもバグを見つけることができることを知る必要があります。 悪臭のするコードの臭いを聞くだけでなく、改善のためのソリューションを提供できる人がいるときに、製品の品質が突然向上するとき、それを信じないでください。
スムーズに移動しました
2.デザインフレームワークを使用してテストフレームワークを開発する。
はいはい。 たとえば、Seleniumを開いた-あらゆる種類の例は、考え抜かれずにコピーされ、結果の「フレームワーク」について1000個のテストを作成しました。 顧客はビジネスに来て、「私はここで何かをやり直す必要があります」、ビジネスは開発者に来ます-「ここで市場に少し適応する必要があります」、開発者はすべてを素晴らしい方法でカットします-テストの90％が失敗します。 彼らは、「ここで少し変更しました。テストを整理する必要があります」自動化、および「1か月作業があります」に対応する自動化に来ます。
作成するフレームワークアーキテクチャは、柔軟性があるだけでなく、既存のテストのリファクタリングと新しいテストの作成にかかる時間を最小限に抑えるよう常に努力する必要があります。 理想的には、開発者と自動化エンジニアが同時に何かを修正するために座っている場合、自動化エンジニアはすべてをより速く行い、開発者に何らかの形式のTDDを提供する必要があります。
このような素晴らしいアーキテクチャを作成するには、設計パターンとその適切な使用が役立ちます。Builder、Facade、Factory、Null Object、Singleton、Adapter、および他の多くのパターンは、こうした問題の解決に積極的に役立ちます。 テストフレームワークの有能なアーキテクチャは、開発者、ビジネス、そして最終的にはユーザーにとって幸せです。 機能の直線的な成長/変化を伴うテストサポートリソースの指数関数的成長は、エンジンアーキテクチャを改良するときが来たことを示していることに注意してください。 Javaのサンプルパターンの最も完全なリストは、 ここにあります 。 それとは別に、Page Object Patternに注意しますが、最初にクラシックに精通してください。
3.ライブラリの使用
外部API、ライブラリ、ドライバー、その他の機能-タスクにスムーズに流れ込むもの。 Selenium-Web、Robotium / Espressoをテスト-Android、Fest / Jemmyをテスト-Java Swing、JemmyFXをテスト-JavaFX、すばらしいApache HttpComponentsをテスト-リクエストを作成し、多くのAPI、GSONをテスト-オブジェクトモデルなどとの間でjsonをやり取りするのに役立ちます...多くの美しいライブラリがほとんどすべてのタスクのために書かれています-それらのいくつかについてはここで読むことができます 。 それらの多くがあることを恐れないでください-あなたはすでにあなたに合った/好きな/アーキテクチャに適合するものを選択するのに十分知っています。 たとえば、Java Swingアプリケーションのテストには、JUnit、Fest、Mockito、およびjava.lang.reflectの幅広い機能を使用します。このセットは、私にとって十分すぎるほどです。
初期段階で頻繁にstackoverflowおよび同様のリソースにアクセスできるように準備してください。 時々ソースを調べる必要があるという事実に備えてください。 そして最も重要なこと-それを理解しないことを恐れないでください。
4.テスト計画/テストの作成
この記事では、100％のカバレッジ、スクリプトなどのアイデアがどのプロジェクトにとっても悲惨であるという事実については語りません。 一般に、自動化されたテストでは、たとえばテスト用の分離された入力など、従来のテストアプローチは有害です。 一般的に、あなたのスキル、分析的に考える能力、疑うべきことを疑う能力、それが存在できない問題を探す能力は、すでに役割を果たしています。 優れたテストスクリプトは優れたインターフェイスのようなものです...完璧ではありません。 私の経験ではこのような統計が得られます。すべてのシナリオの5％が機能の95％をカバーしています。 現在のプロジェクトでは、ほぼ2年間の180の本格的な機能テストがあり、95％から99％の6つの成功した実装を提供します。主要な機能と顧客の忠誠心にまったく影響を与えず、高速でした修正しました。 しかし、彼らのために、別の2000年のテストを行うことは金銭的に不利です。100％のカバレッジを夢見ているリーダーや企業に目を向けています。 私を信じて、あなたはそれを必要としません。 セキュリティまたは請求の自動テストに関するものではない場合、ここで予約します。ここでは、リスクを最小限に抑えるべきではありませんが、可能であればゼロに減らします。 しかし、これは別の話です...
5 ***。 ユーティリティと独自のライブラリを書く
アスタリスクがあります...プロジェクトには素晴らしいものがすべてあり、リグレッションがカバーされ、テストが追いかけられ、開発者は落ち着いて、既存の機能を壊すことを恐れずにアーキテクチャを落ち着いてリファクタリングできます。 しかし、たとえば、自分の手で何かをエミュレートするには、開発者は毎月同じ操作を自分の手で実行する必要があります。 これらのプロセスを最適化するユーティリティを作成し、そこにあらゆる種類の無効なシナリオを含め、会社レベルで宣伝し、誰もが使用を開始できるようにします...これにより作業がスピードアップし、奇妙なことに、開発者がより多くの時間があるため、バグの数が減りますブランチへの変更をコミットする前に、さらにスクリプトを確認してください。 周りを見てみると、自動化できるプロセスがたくさんあるので、何をすべきかわかりません。
社内のさまざまなプロジェクトで使用できる非常に抽象的なライブラリを作成し、将来の作業で使用します。
おわりに
もちろん、あなたは自分自身に「ジース」と考えることができますが、...
- はい、これは最短ではありません、これはあなたが本当にクールなスペシャリストになることができる方法です
- これは非常に興味深い方法です-とげがありますが、興味深いです
- あなたはスペシャリストとして絶対に自信があります
- テストの自動化に疲れている場合は、開発者に安全に行くことができます
- 有料ツールに依存しないため、バグも発生する可能性があります。
- すべてを正しく編成すると（専門の管理者が行うように）、自己開発のための多くの自由時間が得られます。
- まあ、より多くの富:)
PS
ビジネス、マネージャー、採用スペシャリストへ：
専門的なテスト自動化ツールは、最終的には会社のお金を節約します。 ここで現実に非常に近い比較を見ます 。