まず私の見解を述べておきます。自動テストは手動テストを効果的に補完するものであり、私もこの見解に同意します。
ただし、自動テストが手動テストを支配したり、置き換えたりする可能性はありますが、それは不可能だと思います。
自動テストとは何ですか?
自動テストとは、あらかじめ作成したスクリプトに従ってスクリプトステップを一定の順序またはランダムな順序で実行し、期待される結果を比較して実際のテスト結果を得るテスト手法です。
これは事前に作成されたスクリプトであるため、自動テストは実際には現在の論理ブランチまたはブラック ボックス機能に問題があるかどうかを検証することになります。
ユース ケースはコード ブランチをカバーしており、特定の省略もあります。ユース ケースがコード ロジックの最大 70% をカバーし、ユース ケースで見つかるバグの割合が 60% を超えないことがいくつかの企業で検証されています。残りの 40% はテスターの経験とビジネスへの精通度に依存するため、手動による無料テストまたは探索的テストが依然として必要です。
そうです、それは絶対に実現可能です。しかし、ここで 2 番目の疑問が生じます。自動テストのメンテナンス コストは手動テストに比べてどれくらい高いのでしょうか? 偶数であれば、すべてを自動スクリプトとして作成するのが妥当です。この値が高すぎる場合、多くのエンジニアは、反復性の高い一部のユースケースのみを自動化に変換することになります。
ソフトウェアテストでは手動テストと自動テストのどちらが重要ですか?
この質問は多くの人から寄せられているようです。手動テストと自動テストではどちらがより重要ですか❓ 回答: どちらも重要であり、どちらがより重要であるかについては疑問の余地はありません。
ソフトウェアテストでは、ソフトウェアの機能ロジックやインターフェースなどが頻繁に変更されると、自動化されたスクリプトが必ずしも次のバージョンに適応しないことが多く、バージョンごとのデバッグに時間がかかり、テストエンジニアの保守コストと呼ばれます。
デバッグ時間が長すぎて手動テストがすでに自分で完了している場合、自動テストの価値は存在しません。
要約すると、自動化と手動テストは同等に重要であり、相対的に言えば、製品開発の初期段階や一部の小規模企業では手動テストが主流になるはずです。
手動テストと自動テストはどちらも、ユーザーのニーズと機能要件の正確な理解、およびテスト対象に対する適切なテスト設計に基づいて実行されます。
テストフェーズや機能安定性に応じて分けられますが、ソフトウェアモジュール、結合テストフェーズ、機能安定性が低い（欠陥が多い、急激な変更があるなど）場合には手動テストが適しています。維持費が発生します。
自動テストは、製品イテレーションの後期段階、または機能が比較的安定しているときに実行するのに適しており、通常は回帰テストのシナリオで使用されます。
例えば、数百万件のメタデータの移行や集計処理をテストする場合、テスト対象に応じて、データが多様性に富むため、人手によるテストでは品質を確保することが難しく、テストの効率を高める自動化の検討も当然必要になります。そしてテストの品質を確保します。時間が限られている場合は、自動化を使用して、可能な限り多くの繰り返し操作をカバーします。
同時に、自動化は機械的なアプリケーションではなく、さまざまなビジネス シナリオに応じて適切な自動化フレームワークを選択することが非常に重要であり、テスト開発の効率を効果的に向上させ、メンテナンス コストを削減できます。たとえば、強力なプロセスを備えたビジネス モジュールの場合、キーワード駆動のテスト フレームワークを使用すると、ユース ケースの編成と維持がより容易になります。一般的に使用される自動化フレームワークには、データ駆動型テスト フレームワークやモジュール型テスト フレームワークも含まれます。
自動テストの種類も、ui 自動化、インターフェイス自動化など、現地の状況に適応させる必要があり、ビジネス特性や基盤となるアーキテクチャに基づいて適切な種類を選択することも必要です。
ソフトウェアテストは手動テストが基本
自動テストは効率を向上させる手段であり、将来のトレンドです。テストで良い仕事をするには、両方が非常に重要であり、不可欠です。手動テスト 完全なテスト動作には自動テストが含まれない場合がありますが、手動テストは必ず含まれます。
手動テストは、テスト対象製品の全体的な要件を総合的に検証するもので、実際のユーザーが入力する可能性のあるすべてのデータを分類し、等価性テストを実行することで、プログラムのエラーを簡単に発見できます。
つまり、手動テストは、入力と出力の対応関係から出発し、ソフトウェアの機能の正しさを重視する、ユーザーの視点に基づいたテストです。
手動テストでは、主に次の種類のエラーを検出しようとします。
1. ユーザーが入力する可能性のあるデータはさまざまであるため、手動でテストする場合は、すべての正当な入力をテストするだけでなく、正当ではないが表示される可能性のある入力もテストする必要があります。これには、一般的なユースケース設計方法である等価クラス、境界値、因果関係図など、これらの入力のタイプを定量化して管理するためのテスト ケースの導入が必要です。
しかし、少数のテスターが規定時間内に飲食や睡眠をとらずにテストを行っても、想定されるユーザーの利用シーンをすべてカバーすることはできず、現時点では自動テスト手法を導入する必要があります。
2. 例えば、新しいバージョンを立ち上げる場合、新しい機能が正しいかどうかを検証するだけでなく、古い機能が正常に動作することも保証する必要があります。ただし、古い関数の場合は、時間がかかりすぎるテスト ケースを毎回手動で実行する必要はありません。
古い機能 (ログインおよび登録ページ、ユーザー フィードバック ページ、およびめったに操作されず変更されることのないその他のページなど) 用の自動スクリプトを作成し、毎回スクリプトを自動的に実行させることができます。通常、大きな問題はありません。
3. 現在のモバイル テストでは対象となるモデルが多数あります。Apple は問題ありませんが、Android スマートフォンが多すぎます。いくつかの機種との互換性を手動で追求すると、それ以上の機種には対応できなくなります。それは進歩を遅らせることになります。互換性を持たせたいすべてのモデルで実行できる自動スクリプトを作成すると、人的資源と時間を大幅に節約できます。
もちろん自動化にはデメリットもあり、スクリプトは一度しか使えないことがほとんどで、ある機能に対してスクリプトを書いた場合、次回その機能を変更すると基本的にそのスクリプトは無効になってしまいます。
最後に、私の記事を注意深く読んでくださった皆さんに感謝します。互恵性は常に必要です。それはそれほど価値のあるものではありませんが、必要な場合はそれを取り上げることができます。
ソフトウェアテストインタビューアプレット
ソフトウェア テストの質問バンクには、何百万人もの人が参加しました。！！誰が知っているのか！！！ネットワーク全体で最も包括的なクイズ ミニ プログラムです。携帯電話を使用して、地下鉄やバスの中でもクイズに答えることができます。
次の面接の質問セクションが取り上げられます。
1. ソフトウェアテストの基礎理論、2. Web、アプリ、インターフェース機能テスト、3. ネットワーク、4. データベース、5. Linux
6. Web、アプリ、インターフェイスの自動化、7. パフォーマンス テスト、8. プログラミングの基本、9. 時間面接の質問、10. 公開テストの質問、11. セキュリティ テスト、12. コンピューターの基本
これらの資料は、[ソフトウェア テスト] の友人にとって最も包括的で完全な準備倉庫となるはずです。この倉庫は、最も困難な旅を乗り越える何万人ものテスト エンジニアにも同行してきました。あなたにも役立つことを願っています。