基本的な概念
最初にしたいことは、この記事で将来使用される主な用語と概念を思い出してください。
テストは、記述された要件への準拠を判断し、述べられた目的と判断への適合性を実証するために、ソフトウェア製品の計画、準備、評価、およびこれらの結果に関連する作業に関連する、動的および静的なライフサイクルのすべてのアクティビティを含むプロセスです欠陥;
テストの自動化 -ソフトウェアを使用して、特定のプロセステスト（テスト管理、テスト設計、テスト実行、結果の検証など）を実装または支援します。
自動化されたソフトウェアテストは、テストの主な機能と手順（結果の起動、初期化、実行、分析、出力など）が特定のテクノロジスタックを使用して自動的に実行されるソフトウェアテストプロセスであり、自動テスト用ツールが主要な場所を占めます。
自動テストツールは、自動テストの専門家がテストスクリプトの実行結果を作成、デバッグ、実行、および分析するためのソフトウェアです。
アプリケーションプログラミングインターフェイス （場合によってはアプリケーションプログラミングインターフェイス）（英語のアプリケーションプログラミングインターフェイス、API [hey-pei]）-外部ソフトウェアで使用するためにアプリケーション（ライブラリ、サービス）が提供する既製のクラス、プロシージャ、関数、構造、定数のセット製品。 プログラマーがあらゆる種類のアプリケーションを作成するために使用します。
負荷テスト -増加する負荷（同時作業ユーザー数および/またはトランザクション数）の下でのコンポーネントまたはシステムの動作を評価して、調査中のコンポーネントまたはシステムの最大許容負荷レベルを決定するために実施されるパフォーマンステストの一種。
回帰の死のスパイラル -この効果は、プロジェクトのテストにより多くの時間が費やされると発生します。 製品には、より多くの既製の機能があり、それが機能することを常に監視する必要があります。
回帰テスト -変更後、実行されたプログラムをテストして、変更プロセスが変更を受けていない領域でエラーを引き起こしたりアクティブにしたりしていないことを確認します。 ソフトウェア製品またはその環境のコードの変更後に実行されます。
テストスクリプトは、ソフトウェアの特定の部分を自動的にチェックするための一連の指示です。
テストスイートは、特定のソフトウェアをテストするためのテストスクリプトの組み合わせであり、このスイートを実行することによって追求される共通の機能または目標と組み合わせます。
テストデータ -テスト\テストスクリプトの先頭に存在し、作業に影響するデータ、またはテスト中のシステムまたはコンポーネントの影響を受けるデータ（データベースなど）。
フレームワーク （英語のフレームワーク-フレームワーク、構造）-ソフトウェアシステムの構造。 大規模なソフトウェアプロジェクトのさまざまなコンポーネントの開発と統合を促進するソフトウェア。 （ 単語「 フレーム 」も使用され、一部の著者はそれを主要なものとして使用します。 英語のアナログにまったく基づかないことも含めて ）。
機能テスト -コンポーネントまたはシステムの機能の仕様の分析に基づいたテスト。
テストの種類
基本的な概念を少し理解しているので、主な種類のテストを検討することをお勧めします。
•このリストの最初の項目はストレステストです。 自動化なしの実装を想像することは困難です（ ソフトウェアは、次のように負荷を模倣します。さまざまなシナリオに従ってさまざまなスクリプト（アクション）を実行する仮想ユーザーを接続します。 ）;
• 回帰テストが続きます。 プログラムに変更を加えた後に発生したエラーは、回帰エラー（英語の回帰バグ）と呼ばれます。 これは、多くの条件に応じて設定された定期的な頻度で実行されます。プロジェクトの新しいアセンブリごとに、または顧客の各バージョンごとに実行できます。
• 機能テストは 、機能要件の実現可能性、つまり、ユーザーが必要とするタスクを解決する特定の条件でのソフトウェアの能力を検証するために実行されます。 （ 回帰/機能テストの自動化の主なタスクの1つは、死の回帰スパイラルからプロジェクトを保護することです。 ）
自動テストの長所と短所
しかし、上記のように、すべてがとても美しく、美しいのでしょうか？ これらの質問に答えるために、私は適切な結論を引き出すために「賛否両論」を提案します。
利点：
•実行時に「ヒューマンファクター」は除外されます。テストスクリプトは過失によるエラーを起こしません。
•高速実行。
•テスト結果に関するレポートを自動生成および保存。
•バックグラウンドでの実行-テストの実行中、数時間後に他のタスクを実行したり、テストスクリプトを実行したりできます。
短所：
•均一性-すべての記述されたテストは、実装されたアルゴリズムに従って常に厳密に実行されますが、テスターはテストを手動で実行し、詳細に注意を払い、欠陥を見つけることができます。 （ たとえば、プロジェクトの次の更新後、オプションのフィールドが操作フォームに追加されましたが、開発者がミスを犯し、入力のデータ形式が正しくありませんでした。アプリケーションの機能\回帰テスト中、テストスクリプトはエラーなしで動作します。このフィールドでは実装されていません。 ）;
•サポートコスト-アプリケーションが頻繁に変更されるほど高くなります。 （ 改善の結果、特定の機能が変更され、テストスクリプトが部分的または完全に不適合になる可能性があります。自動テストスペシャリストは、テストスクリプトを現在の状態にするタスクを持ちます。 ）
•特定のプロジェクトのテストフレームワークを開発するための高コスト（ 実際には 、別のプロジェクトをテストするアプリケーションが開発されています ）。
自動テストを実装する
テスト自動化の実装について考える前に、プロジェクトの品質管理プロセスが構築され、文書化され、時計のように機能することを確認する必要があります。 自動化の導入は流行ではありません。 これは、プロジェクトの品質管理を新しいレベルに引き上げるために設計されたタスクです。これにより、プロジェクトテストの効果が向上します（追加の頭痛なし）。
2番目のステップは、専門家に依頼することです。専門家は、自動化プロセスを短時間でプロフェッショナルレベルに移行するのを支援します。 間違いなく、あなたは自分で方向性を開発しようとすることができますが、経験豊富な専門家がいないと、このプロセスはおそらくかなりの時間がかかり、試行錯誤を経て、より大きな予算に影響し、最終的には使用を完全に落胆させる可能性があります自動テスト。
自動化プロジェクトでゼロからテストを導入する場合、ほとんどの場合、フレームワークを開発することをお勧めします。 このアプローチにより、スペシャリストはフレームワークを個別に変更し、テストスクリプトでカバレッジを開発できます。 今日では、価格/労働力/効率の点で最も技術的に高度なソリューションです。
このようなフレームワークの機能は次のとおりです。
•コードの最大限の再利用：実行プロセスを制御するAPIが実際に作成されます。
•データドリブンテクニックの適用（同じシナリオに従ってテストし、ソースデータの異なるセットや値で実行）。
•すべてのテストケースとテストスイートも外部ファイルに記述されているため、起動パラメーターを簡単に管理できます。
•フレームワークには最大限の柔軟性があります。既存のテストスクリプトとスタートアップパッケージを簡単に追加、削除、編集できますが、このタスクでは追加の資格は不要で、フレームワークを操作する能力のみが必要です。
•新しい操作をシステムに簡単に追加したり、既存の操作を変更したりできます。 この場合、複雑なアクションは必要ありません。新しい関数を記述するだけで済みます。 これにより、フレームワーク自体を簡単かつ簡単に拡張できます。
•多くのテスト部門にとって、このソリューションは万能薬かもしれません。 フレームワークを開発し、フレームワークを使用した簡単なトレーニングを実施した結果によると、自動テストでシステムをカバーする専門家の資格要件は大幅に削減され、XMLスキルは十分です。
まとめ
結論として、自動化の目標は、専門家を解放することでプロセス（この場合はテスト）の効率を高め、それによりコストを削減することです。
自動化の問題を検討する場合、実装のコストを覚えておく価値があります。 ほとんどのテスト自動化ツールが支払われ、さらに、適応のための追加の人件費が必要です。 ソフトウェア製品の手動テストと自動テストのバランスを見つけることは、あらゆる組織のテスト部門の重要なタスクです。