自動テストには主に 3 つのタイプがあります。
1. 自動化された単体テスト編集
自動化された単体テストはコードレベルでテストします。バグは、開発者が作成した関数、メソッド、ルーチンで特定されます。
開発者自身が単体テストを実行することを要求する企業もあれば、専用のテスト自動化リソースを雇う企業もあります。これらのリソースはソース コードにアクセスでき、製品コードを破壊する単体テストを作成します。単体テストのおかげで、コードがコンパイルされるたびに、すべての単体テストが実行され、すべてが適切に動作しているかどうかがわかります。単体テストが失敗した場合、それは製品コードにバグがあることを意味します。
市場で最も人気のあるツールには、NUnit と Unity があります。Microsoft は、MSTest と呼ばれる独自の単体テスト フレームワークも提供しています。これらのツールの Web サイトを通じて、単体テストの作成方法に関する例とチュートリアルが提供されます。
2. 自動化されたWebサービス/APIテスト
アプリケーション プログラミング インターフェイス (API) を使用すると、ソフトウェアは他のソフトウェア アプリケーションと通信できるようになります。他のソフトウェアと同様に、API もテストする必要があります。このようなテストには、通常、Gui は関与しません。
ここでテストするのは通常、機能、コンプライアンス、セキュリティの問題です。Web アプリケーションでは、アプリケーションのリクエストと応答が安全で暗号化されているかどうかをテストできます。
これは、API テストを使用できる例の 1 つです。最も人気のある API テスト ツールは SOAPUI で、無料バージョンと有料バージョンの両方があります。必要に応じて使用できる他のツールもあります。
现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036
3. 自動 GUI テスト編集
このタイプの自動テストは、アプリケーションのユーザー インターフェイスのテストが含まれるため、自動化の最も厳密な形式です。
GUI は非常に簡単に変更できるため、これは困難です。ただし、このタイプのテストは、ユーザーがアプリケーションで行う動作に最も近いものでもあります。ユーザーはマウスとキーボードを使用するため、自動 GUI テストでも、マウスとキーボードを使用してユーザー インターフェイス上のオブジェクトをクリックしたりオブジェクトに書き込んだりすることで、同じ動作が模倣されます。したがって、バグを早期に発見でき、回帰テストやフォームへの入力など、時間がかかりすぎる多くのシナリオで使用できます。
最も人気のある GUI テスト ツールは、QTP (現在は UFT と呼ばれています)、Selenium、Test Completion、および Microsoftcoding UI (Visual Studio Ultimate および Premium エディションの一部) です。
4. 自動テストに関するいくつかの誤解
ここ何年にもわたって、私はテスト自動化についていくつかの誤解を聞いてきました。この投稿でもこれらの問題を明確にする必要があると思いました。
誤解 #1. 自動化が手動テスターに取って代わる。
テストの自動化とは、テスターがより迅速かつ信頼性の高い方法でテストを実施できるようにすることです。それは決して人間に取って代わることはできません。
テストの自動化を自動車に例えてみましょう。歩いて行けば自宅まで20分くらいかかります。でも車を使えば2分で着きます。しかし、車の運転手はあなた、つまり人間であることに変わりはなく、車は人間がより早く目標を達成するのに役立ちます。また、歩かないのでエネルギーのほとんどが節約されます。したがって、そのエネルギーをより重要なことを行うために使用できます。
自動テストについても同様です。これを使用すると、反復的で長く退屈なテストのほとんどを迅速にテストでき、新しい重要な機能に集中してテストするための時間とエネルギーを節約できます。
ジェイムズ・バッハはかつて素晴らしい言葉を残しました。
「ツールはテストしません。テストするのは人だけです。ツールは、人のテストを「支援」することだけを行います。
ツールはオブジェクトをクリックできます。ただし、クリックの位置は手動テスターによって常に指示されます。もう私の言っている意味が分かると思います。
通説 2. 太陽の下にあるものはすべて自動化できます。
テスト ケースを 100% 自動化しようとすると、おそらくそれができるでしょう。しかし、もしできるとしたら、最初の点は間違っています。すべてが自動化されたら、手動のテスターは何をするのでしょうか?
困惑していますか？そうですか？
実際のところ、重要なのは、テスト ケースを 100% 自動化することはできないということです。私たちはテスターとして、アプリケーションを 100% テストすることはできないと信じているからです。見逃してしまうシーンは必ずあります。バグはクライアントがアプリケーションを使用する場合にのみ発生します。
では、アプリケーションを 100% テストできない場合、どうすれば 100% 自動化を保証できるのでしょうか?
さらに、既存のテスト ケースをすべて自動化できる可能性は非常に低いです。自動化するのが難しく、手作業で行う方が簡単なシナリオが常に存在します。
たとえば、1 人のユーザーがデータを入力し、2 人目のユーザーがデータを承認し、3 人目のユーザーがデータを閲覧し、4 人目のユーザーがデータの閲覧を禁止します。これらのシナリオは自動化できますが、多くの時間と労力が必要です。したがって、手動で行うだけの方が簡単です。
覚えておいてください、私たちは長距離の移動のために車を使いますが、道路には長い信号があり、燃料消費があり、駐車スペースの問題や駐車料金など、頭の痛い問題が発生する可能性があります。場合によっては、ただ歩いて目的地まで行くこともあります:)。
したがって、すべてを自動化しようとするべきではありません。自動化する必要があるのは重要なシナリオのみであり、手動で実行すると多大な時間がかかります。
誤解 #3. 自動化には記録と再生のみが含まれます。
空想の世界に住まないでください。この錯覚は、実際には、さまざまな自動化ツール ベンダーからの誤った広告によって引き起こされます。ステップを記録して再生するだけでテストケースが自動化されるそうです。これは大嘘です！
自動化とは、録音と再生を除くすべてのことです。純粋な自動化エンジニアは、記録および再生機能をまったく使用しないことがよくあります。記録と再生は、ツールがステップのスクリプトをどのように生成するかを理解するためによく使用されます。
スクリプトを理解したら、常にスクリプトを使用して自動テストを作成します。テストを自動化したい場合は、プログラミングの知識が必要であることを忘れないでください。. 一方で、プログラミングの仕方がわからない場合は、あまり大胆にならないでください。なぜなら、他のタスクと同様に、プログラミングも練習と献身を通じて学ぶことができるからです。
コンピューター サイエンスの背景さえなかったのに、プログラミングを学び、今では素晴らしい自動化エンジニアになっている人を知っています。Microsoft では、プログラミングができるテスターを雇用しています。彼らはSDET（Software Development Engineer for Testing）と呼ばれます。職務記述書の最初の行には、「sdet は多くのコードを書きました…」と書かれています。
プログラミングから逃げずに学んでください。それはあなたを素晴らしいテスターにします
組織が自動テストを実装するには、まず自動テストについて正しく理解する必要があります。自動テストについては、通常、次のような誤解があります。
誤解 #4. すべてのテスト ケースは自動化できる
まず、自動テストにはテスト スクリプトの開発が必要であり、自動テストの実行にも時間がかかるため、すべてのテスト ケースを自動化する必要はありません。すべてのテスト ケースを自動化することが最も費用対効果が高いとは限りません。
一方、自動テストは主に回帰テストの負荷を軽減するために使用されます. 回帰テストで最も重要なことは、最も基本的な機能や最もよく使用される機能が影響を受けないようにすることです. この理論から、関数と最も一般的に使用される関数のテスト ケースを自動化するには十分です。
現在、世界で最も高い自動テスト率は約 80% にすぎません。
誤解 #5. 自動テストではバグは見つけられない
自動テストは主に、より多くのより深いバグを掘り出すことではなく、コードの変更による元の正しい機能のバグを回避することを目的としています。テスターが解放された後の探索的テストを通じて、より多くのより深刻なバグが発見されます。
通説 #6. 自動テストによりテスターの数が直ちに大幅に削減される
自動テストは最終的にテストの負荷を軽減しますが、自動テストを導入するには、まず自動テストスクリプトを開発し、自動テスト環境を構築する必要があり、多くの人員とエネルギーが必要となるため、すぐには実現しません。自動テストの結果が表示されるまでにかかる時間は、プロセスの長さによって異なります。
誤解 #7. 自動テストは手動テストに取って代わることができます
自動テストは回帰テストにのみ適しており、新機能テストの場合は、依然としてテスターに頼ってテスト ケースを設計し、手動で実行する必要があります。
誤解 #8. 自動化が必要なのはパフォーマンス テストだけです
自動テストは、パフォーマンス テストに加えて、機能テストでも広く使用されています。
海外の自動テストスクリプトの半分以上は機能検証テストに使用されています。
通説 #9. 自動テストは難しすぎて始めることができない
自動テストは長い間実装されており、多くの自動テスト フレームワーク、ツール、チュートリアルがオンラインで見つかります。本当に自動テストを実装したい場合は、プロのテスターを手配して学習を開始するだけで、自動テストを簡単に実装できます。
行動は興奮より悪い。
最後に、自動テストは、テストのすべての問題を解決できるほど魔法のようなものでも、非常に高度で開始が難しいものでもありません。自動テストを正しく理解し、自動テストの現実的な実装があれば、自動テストによってもたらされる利点を享受できるようになります。
これはまさに次のとおりです。
トラの色の変化について話すことはお勧めできませんし、それを特効薬として扱うことも現実的ではありません。
自動化を正しく理解し、現実的な実装を行う
最後に、私の記事をよく読んでくださった皆様に感謝申し上げます。ファンの増加と注目度を見ると、常に一定の礼儀が存在します。それほど価値のあるものではありませんが、使用できる場合は直接受け取ることができます!
ソフトウェアテスト面接文書
私たちは高給の仕事を見つけるために勉強しなければなりません。以下の面接の質問は、アリババ、テンセント、バイトなどの一流インターネット企業の最新の面接資料からのものであり、バイトの上司の中には権威ある回答をしている人もいます。 set 面接情報に基づいて、誰もが満足のいく仕事を見つけることができると思います。
