自動テストとは何ですか?
私は数年前からテストの仕事をしていて、この 1 年間で自動テストについて本当に学び、実践してきました。私は、自動テストの実践に関する経験を共有する記事を書きたいと常に考えていました。最終的には、時間をかけてこれを行うことにしました。
まず、自動テストの概念を明確にします。広義には、自動化には、パフォーマンス テスト ツール (loadrunner、jmeter) や、 1～100個のテストデータを生成するプログラム。狭義には、手動テストのプロセスはツールの記録またはスクリプト作成によってシミュレートされ、テスト ケースはスクリプトの再生または実行によって実行され、それによってシステム機能の手動検証を置き換えます。
もちろん、私たちのより一般的な理解では、「自動テスト」は「製品またはプロジェクトの UI レイヤーに基づく自動テスト」と見なされます。
階層化された自動テスト
この概念は最近明らかになり、従来の自動テストでは製品の UI レイヤーの自動テストに重点が置かれていますが、階層化された自動テストでは製品のさまざまな段階 (レベル) で自動テストが必要であると主張されています。
受験生は上記のピラミッドを知らない人はいないと思いますが、これは製品開発のさまざまな段階に対応するテストではないでしょうか。Java の Junit、testNG、C# の NUnit、Python の Unittest、pytest などの、標準化された単体テストと、対応する単体テスト フレームワークが必要です。ほとんどすべての主流言語には、対応する単体テスト フレームワークがあります。
統合テストとインターフェイス テストは、多くの新しいテスターにとって理解するのが簡単ではありません。単体テストは、if 分岐や for ループの実装など、コードの実装ロジックに焦点を当てます。次に、統合テストとインターフェイス テストは、関数やクラス (メソッド) 提供されたインターフェイスが信頼できるかどうか。たとえば、2 つのパラメーターの結果を計算して返す add() 関数を定義した場合、add() を呼び出してパラメーターを渡し、戻り値が 2 つのパラメーターに加算されるかどうかを比較する必要があります。もちろん、インターフェイスのテストは URL の形式で配信することもできます。たとえば、get を通じてサーバーにリクエストを送信すると、送信したコンテンツは URL の一部としてサーバーに渡されます。しかし、たとえば、Web サービス技術によって提供されるパブリック インターフェイスは、soapUI などのツールによってテストする必要があります。
UI レイヤーの自動テストについてはよく知っている必要があり、ほとんどのテスターの仕事のほとんどは UI レイヤーの機能をテストすることです。UI テストは、ページ上での最も単純なビットごとのテストであり、最も単純なブラックボックスの手動テストでもあります。ただし、記録されたスクリプトの多くは再生中に使用できないため、UI の自動化は非常に難しく、スクリプトを自分で記述する必要があります。ただし、記録スクリプトが不足することはありません。最初は、テスト対象の製品の UI 自動化スクリプトが記録スクリプトによってどのように記述されるかを知ることしかできないからです。たとえば、フォームの送信や結果のクエリなどの機能を繰り返しテストしますが、対応する自動テスト ツールを通じてこれらの操作をシミュレートできるため、繰り返しの作業が解放されます。UI レイヤーには多くの自動テスト ツールがあり、より主流のものは QTP、Robot Framework、watir、Selenium などです。
なぜ長方形や逆三角形ではなくピラミッドを描くのでしょうか? これは、さまざまな段階に投資された自動テストの割合を示すためです。単体テストやインターフェーステストを行ったことのない製品の場合、UI層の自動テストだけを行うのは非科学的であり、製品の品質を本質的に保証することが困難になります。無駄に包括的なUI層の自動化テストを実現しようとすると、お金と人員の無駄、多大な労力が投入され、最終的な利益は支払ったコストをはるかに下回ってしまう可能性があります。レベルが高くなるほど維持コストが高くなるためです。特に UI レイヤーの要素は時々変更されます。したがって、単体テストとインターフェイス テストのフェーズに、より多くの自動テストを配置する必要があります。
UI 層の自動テストは非常に手間とコストがかかるため、単体テストとインターフェイス テストのみを行います。いいえ! どんな種類の製品であっても、最終的にユーザーに提示されるのは UI レイヤーだからです。したがって、テスターは UI レイヤーにもっと重点を置く必要があります。となると、テスターはUI層に多くのエネルギーを注ぐからこそ、自動化によって反復的な作業を「部分的に解放」するお手伝いが必要なのです。
自動テストで最も恐れられるのは変更です。変更の直接の結果はテスト ケースの実行に失敗するため、自動化スクリプトを保守する必要があります。失敗を制御し、保守コストを削減する方法が自動化の成功にとって重要です。 。逆に、常に正常に実行される自動テスト ケースには価値がありません。
ピラミッド内の 3 つのテストの比率については、実際のプロジェクトの要件に応じて分割する必要があります。『The Way of Google Testing』という本では、Google 製品について、投資の 70% が単体テスト、20% が統合およびインターフェースのテスト、10% が UI 層の自動テストであるとしています。
自動テストを行う必要があるのはなぜですか?
51testingの「中国ソフトウェアテスト実務者調査報告書」によると、手動テストが89％を占めており、開発に比べてテストの敷居が低く、給料も一般的に低いため、求められる知識は一定の幅があるものの、深みに欠けています。これがテストの一般的な状態です。
手作業による技能試験の敷居が高くないからこそ、プロ以外の人も含めて多くの卒業生がこの業界に流れ込んでいる。それにより、この業界における競争はさらに激化しています。マニュアルテストを数年続けている人は、強い危機感を持っているでしょう。仕事の技術内容が低いため昇給がネックになっている一方、新規参入者に脅かされている 同じ仕事を会社が5Kで雇ってもできるので、高くならない8Kを費やします。
まあ、この質問は技術的な話題の議論に登場するべきではありませんが、実際、ほとんどのテスターが直面しなければならない問題です。したがって、テスター自体の開発という観点から見ると、競争力を高めるためには自動化技術が実は必要なのです。もちろん、一定の年数を経たテスターは管理職などへの異動を選択しますが、それはまた別の話です。
試験産業の発展の観点から見ると、製品の特性により、国内製品には世界一流の製品が少なく、技術内容が比較的低く、品質要件が比較的低く、海外プロジェクトが外部委託されており、試験人件費が低いため、そのため、多数の手動テスターが必要になります。
したがって、近い将来、純粋なマニュアルテスターの需要は減少し、企業はより高い技術力を備えたテストを必要とするようになると思います。品質にはテストが必要であり、テスト行為がなくなることはありませんが、純粋な手動テスターが消える可能性はあります。
まあ、テストは日当たりの良い業界だと言えますが、私は純粋に警戒心が強いです。将来がどうなろうとも、私たちは皆、スキルを向上させる必要がありますよね?
自動テストにはどのようなプロジェクトが適していますか?
自動テストを学習することに決めた場合、次に直面するのは学習方法です。この問題はテストした製品に基づいて分析されますが、学習した技術が適用（検証）できない場合、学習プロセスは困難になります。
まず、製品が自動テストに適しているかどうかを検討します。この方法の一般的なコンセンサスは、3 つの側面からトレードオフを行うことです。
ソフトウェア要件は頻繁に変更されません
テスト スクリプトの安定性によって、自動テストのメンテナンス コストが決まります。ソフトウェア要件が頻繁に変更される場合、テスターは要件の変化に応じてテスト ケースと関連テスト スクリプトを更新する必要があります。また、スクリプトのメンテナンス自体はコード開発のプロセスであり、必要に応じて変更、デバッグ、およびテストの自動化を行う必要があります。コストが、それを使用することで節約されたテスト コストより低くない場合、自動テストは失敗します。
プロジェクト内の一部のモジュールは比較的安定していますが、一部のモジュールの要件は非常に変わりやすいです。これにより、比較的安定したモジュールのテストを自動化できますが、比較的大きな変更については依然として手動テストが必要です。
長いプロジェクトサイクル
自動テスト要件の決定、自動テスト フレームワークの設計、テスト スクリプトの作成とデバッグを完了するには、長い時間がかかります。このようなプロセス自体がテストソフトウェアの開発プロセスであり、完了までに長い時間がかかります。プロジェクトのサイクルが比較的短く、そのようなプロセスをサポートする十分な時間がない場合、自動テストは冗談になります。
自動テストスクリプトは再利用可能
自動テストスクリプトの再利用は、テスト項目（C/SシステムとB/Sシステムの違いなど）に大きな違いがあるかどうか、この違いは何か、という3つの側面から検討する必要があります。最後に、テスターがこの違いに適応する自動テスト フレームワークを開発する能力があるかどうかです。
自動テストにどのツールを選択するか
XX プロジェクトが自動テストに適していることが確認できたら、次に行う必要があるのはテスト ツールを選択することです。
まず、テストする製品がデスクトッププログラム（C/S）なのか、Webアプリケーション（B/S）なのかを確認する必要があります。
デスクトップ プログラム用のツールには、QTP、AutoRunner が含まれます。
Web アプリケーション用のツールには、QTP、AutoRunner、Robot Framework、watir、Selenium が含まれます。
B/S アーキテクチャには多くの利点があるため、数年前に C/S アーキテクチャの多数のアプリケーションが B/S アーキテクチャに変換されました。これにより、Web 開発およびテスト技術の開発も促進されます。C/S アーキテクチャを備えたテスト対象製品がある場合は、QTP が推奨され、UI 自動テストの分野では QTP が試用率の半分を占めます。したがって、QTP が自動化の分野で強力であること、使いやすいことなどを示すだけで十分です。主流のツールを学ぶことで、より多くの機会を得ることができます。QTP に関する書籍も多数市販されています。もちろん、QTP を十分に学ぶには、VBS スクリプト言語をマスターする必要があります。
テスト対象の製品が B/S 構造の場合、セレンが推奨されますが、QTP やその他のツールは推奨されません。Selenium は B/S アプリケーションを非常によくサポートしており、さらに重要なのは、多言語開発をサポートしているためです。Selenium を実際に試すには、習得する必要があるのはツールだけではなく、言語も学ぶ必要があります。セレンを選択する必要があるのはなぜですか? 言語も学ぶ必要があるので、間違いなく学習コストが高くなります。コストは増加しますが、競争力も向上します。さらに、その過程で自動化ツールを学ぶだけでなく、学んだ言語を使用してより多くのことを実行できるようになります。
よし！Selenium を試してみることにした場合、言語を選択するという新たな問題に直面することになります。Selenium は、Java、Python、Ruby、php、C#、JavaScript をサポートします。
言語の習得の容易さの観点からは、Ruby と Python が推奨されます
言語の適用範囲の広さという点では、Java、C#、php、
言語関連のテスト技術 (およびデータ) に関して: Ruby、Python、Java
または、技術チーム全体で主流に使用されている言語を考慮して、対応する言語を選択することもできます。
セレンを使用する前に
わかりました！上記のプロセスの後、それに応じた選択をする必要があると思いますが、Selenium ツールを選択した場合は読み進めてください。
Selenium を開始する前に、言語の学習に 1 ～ 2 か月かかることが望ましいとされていますが、これは言語の基礎がない学生を想定しています。Ruby、Python、Java を学ぶことをお勧めします。
もちろん、言語の基礎が十分にあり、このリンクをスキップする場合、または豊富な Java プログラミング能力がある場合は、Python の学習に数日以内で済む可能性があります。
すでに言語の基礎が固まっているなら、まず Selenium について理解する必要があります。Selenium は単なるツールではなく、ツールの集合体であり、1.0 と 2.0 に分かれています。もちろん 3.0 も登場しています。 。
Selenium は単純なツールではなく、いくつかのツールで構成されており、それぞれに独自の特性とアプリケーション シナリオがあります。
セレンIDE
Selenium IDEは、Firefoxブラウザに組み込まれ、ブラウザの簡単な操作の記録・再生機能を実現するプラグインです。それでは、いつ使用されるのでしょうか？
バグ再現スクリプトの迅速な作成: テスト プロセス中に、テスターはバグを発見した後、IDE を介して再現手順を記録できるため、開発者はバグをより簡単に再現できます。
IDE に記録されたスクリプトは多言語に変換できるため、スクリプトの開発を迅速に行うことができます。この機能については、後で使用する際に詳しく紹介します。
セレングリッド
Selenium Grid は自動テスト支援ツールで、既存のコンピューター インフラストラクチャを利用して Web アプリの機能テストを高速化できます。グリッドを使用すると、複数のマシン上で同時に異種環境で複数のテスト ケースを並行して実行するのに非常に便利です。その特徴は次のとおりです。
・並列実行
· 1 つのホストを使用して、異なる環境および異なるブラウザでのユースケースの実行を制御します。
・試験機の追加・変更も柔軟に対応
セレンRC
Selenium RC は、Selenium ファミリのコア ツールです。Selenium RC は、自動テスト スクリプトを作成するためにさまざまな言語をサポートしています。Selenium RC サーバーは、テストの目的を達成するためにアプリケーションにアクセスするためのプロキシ サーバーとして機能します。
Selenium RC はクライアント ライブラリと selenium Server を使用します。クライアント ライブラリは主に、Selenium Server のライブラリを制御するテスト スクリプトを作成するために使用されます。
Selenium Server はブラウザの動作を制御する役割を担っており、一般に Selenium Server は主にランチャー、HTTP プロキシ、コアの 3 つの部分で構成されています。このうち、Selenium Core は Selenium Server によってブラウザ ページに埋め込まれます。実際、Selenium Core は JS 関数の集合体であり、これらの JS 関数を通じてプログラムを使用してブラウザを操作することができます。ランチャーは、ブラウザを起動し、ブラウザ ページに selnium Core をロードし、ブラウザのプロキシを Selenium Server の Http プロキシに設定するために使用されます。
セレン2.0
Selenium 1.0 のファミリー関係を明確にした後、Selenium 2.0 ではこのファミリーに WebDriver が追加されました (単純に次のように表現されます)。
セレン 2.0 = セレン 1.0 + WebDriver
Selenium 2.0 では、WebDriver が主なプロモーションであることを強調しておく必要があります。WebDriver は Selenium RC の代替品です。Selenium は下位互換性を目的としており、Selenium RC は完全には放棄されていません。Selenium を使用して新しい自動テスト プロジェクトを開発する場合、強くお勧めします このコラムでは WebDriver の使用を推奨しています。では、Selenium RC と Webdriver の主な違いは何でしょうか?
selenium RC はブラウザで JavaScript アプリケーションを実行し、ブラウザの組み込み JavaScript トランスレータを使用して selenese コマンドを翻訳して実行します (selenese は selenium コマンドのコレクションです)。
WebDriver は、ネイティブ ブラウザ サポートまたはブラウザ拡張機能を通じてブラウザを直接制御します。WebDriver はブラウザごとに開発され、テスト対象の Web アプリケーションに埋め込まれた JavaScript を置き換えます。ブラウザとの緊密な統合により、JavaScript セキュリティ モデルによって課される制限を回避する、より高度なテストを作成できます。ブラウザ ベンダーからのサポートに加えて、WebDriver はオペレーティング システム レベルの呼び出しを使用してユーザー入力をシミュレートします。
新しいプロジェクトの場合は、Webdriver を直接学習しても問題ありませんが、RC は時代遅れのテクノロジーです。
Selenium学習ルート
テスト環境を構成し、学習している言語に対応する Selenium テスト環境を構成します。Selenium は、定義の意味論のようなものです ---「こんにちは」。中国語を使用している場合は、表現力を高めるために、書き方は「ニーハオ」、英語を使用している場合は、書き方は「こんにちは」です。 。したがって、同じ意味論であっても、言語が異なれば書き方 (文法) も異なります。
次に、Webdriver API に精通する必要があります。Webdriver API は、ページ上のさまざまな要素を検索して操作するために Selenium によって定義されたメソッドです。
まず要素の配置を学習します。Selenium は、ID、名前、クラス名、タグ名、リンク テキスト、部分リンク テキスト、xpath、css、およびその他の配置方法を提供します。xpath と css の強力な構文は少し複雑なので、それまでの間はフロントエンドの知識をさらに知る必要があるかもしれません。XML、JavaScriptなど。
要素を配置する目的は要素を操作することであり、入力ボックス、ドロップダウン ボックス、ボタンのクリック、ファイルのアップロード、ダウンロード、ページネーション、ダイアログ ボックス、警告ボックスなど、さまざまな要素の操作を学習する必要があります。等
一定期間学習した後は、ページ上のさまざまな要素を操作する手動テストを簡単にシミュレートできます。次に、これらの「ユースケース」を整理し、一緒に実行する必要があります。
次に、単体テスト フレームワークを学習して使用する必要があります。単体テスト フレームワーク自体が、ユース ケースの構成と運用を解決します。
いくつかの「テスト ケース」を作成すると、テスト ケース内で繰り返される操作が多数あることがわかります。それらを別のファイルに書き込んで、必要に応じてこれらの操作を呼び出すことはできますか? もちろんそれは可能であり、プログラミング スキルを活用してこれを実現するのは非常に簡単です。すると、ユースケースごとにいくつかのデータがあり、データは同じだが変更されると修正が非常に面倒であることがわかり、別のファイルに書き込んで読み取ることもできます。
次に、新しい質問があります。私が作成したスクリプト (ユース ケース) はすべてパイプライン化されています。ユース ケースが失敗したか成功したかを知るにはどうすればよいですか。次に、スクリプトに検証とアサーションを追加する必要があります。
さらにアイデアが出てきました。単体テスト フレームワークのログが単純すぎるので、美しいテスト レポートを生成できないでしょうか。このスクリプトを定期的に実行できますか? 各スクリプト実行のテスト結果を私の電子メールに直接送っていただけますか。あなたはできる...
これらの問題を解決するには、より多くのプログラミング技術を学ぶ必要があり、そうすれば「テスト構造」はますます強力かつ柔軟になります。一定の多用途性と携帯性を実現しました。まともな自動テストフレームワークが誕生しました。
ある日、UI 自動化テストを行わなくなったとしても、単体テストやインターフェイス テストを行うのは基本的には難しくないことがわかるでしょう。Seleniumのおかげでテストツールなどの開発も苦になりません！ところで、私もありがとう！