自動テストとは何ですか? 自動テストを行うにはどうすればよいですか?

機能テストとインターフェイステストについては以前に紹介しましたが、インターフェイステストを紹介するときに API の自動化についても言及しました。では、自動化とは一体何なのか、なぜ自動化したいのか、ここでは要約することに重点を置きます。

1. 自動化とは何ですか?

名前が示すように、自動テストは手動テストに関連しており、ソフトウェアの手動テストをマシンによる実行に変換する実践を指します。

単体テストはホワイトボックステストであり、多くの企業は開発者による単体テストの責任を負っていることに注意してください。これについてはこの記事では説明しません。この記事では、API テストと GUI テストに焦点を当てます。

手動 API テストの方法は、インターフェイステストツール (Postman など) を使用し、次の手順を実行することです。

インターフェイスの URL を入力してください
GET、POST などのリクエストタイプを選択します。
ヘッダーとパラメーターの情報を入力します
リクエストを送信する
応答コードと応答本文を含む応答を検証します。
API 自動化とは、対応する API を自動的にリクエストし、結果が期待どおりかどうかを自動的に検証することです。

手動 GUI テストの方法は、テスト対象のシステムを開き、要件に従って作成されたテストケースを参照し、手動で 1 つずつクリックして、結果が期待どおりかどうかを確認します。

GUI 自動化とは、ソフトウェアインターフェイス上でさまざまな手動操作をシミュレートし、結果を自動的に検証することです。

2. なぜ自動化したいのですか?

自動テストというと響きが美しく、テスターを単純な反復作業から解放します。ただし、自動テストの本質は、あるコード (自動化されたユースケース) を使用して別のコード (開発および実装されたビジネスロジック) をテストすることです。そのため、自動化されたユースケース自体は開発作業に属しており、次のように更新する必要があります。テスト対象のオブジェクトを更新するため、特定の要件があり、メンテナンスコストがかかります。

開発費や保守費がかかるため、コストパフォーマンスを考慮する必要があります。自動テストの利点を見てみましょう。

自動テストは、多数の手動による反復操作を置き換えることができ、テストエンジニアは、より包括的なユースケースの設計や新機能のテストにより多くの時間を費やすことができます。
自動テストは回帰テストに答え、効率を向上させることができます
自動テストは、無人時間を有効活用してテストを頻繁に実行できるため、システム安定性テストを 7 時間 24 時間継続的に実行する必要がある主要なビジネスに適しています。

自動テストでは、各テストで実行される操作と検証の一貫性と再現性を確保し、人間による省略や過失を回避できます。自動テストの欠点を見てみましょう。

自動テストは手動テストを置き換えることはできません。
自動テスト自体には「インテリジェンス」はありません。事前に定義されたテスト手順を段階的に実行して結果を検証するだけであり、テスト対象のシステムの変更には対応できません。自動テストには一定の発展があります
。そして維持費。統計によると、自動テストのコストは、自動テストの有効実行数が 5 以上の場合にのみ回収できます。
自動テストでは、回帰テストの範囲内の欠陥のみを検出でき、手動テストのような探索的テストはできません。自動テスト
のメリットとデメリットを総合すると、どのようなシナリオが自動テストの使用に適していますか?

要件が安定し、変更が頻繁に行われない
シナリオ頻繁な回帰テストが必要なシナリオ安定性を確保するために 7*24 時間を必要とする前述の重要なビジネスなど、
手動テストでは達成できないプロジェクト、または手動テストするにはコストが高すぎるプロジェクトも達成可能
自動テスト技術により、中断することなく動作します。

3. 自動テストの準備をする

テストユーザーのログインを例に挙げると、手動テストの手順は次のとおりです。

登録ユーザー
テストユーザーログイン次の
2 つの問題があります。

登録時には、登録サービスが利用可能である必要があります。ユーザーを登録できない場合、テストはブロックされます。
テスト中はユーザーは使用されません。つまり、この時点で作成したばかりのユーザーを誰かが削除してしまうと、テストは失敗します。
問題点 1 はテストデータの準備、問題点 2 はテスト環境の干渉です。

3.1 テストデータの準備

引き続きテストユーザーのログインを例として、登録ユーザーを取得する方法がいくつかあります。

GUIで直接操作する
この方法はシンプルで直接的な方法ですが、効率が低いです
APIの生成と
実装の呼び出しには問題ありません問題は、フロントエンド操作が一連のバックエンドAPIを呼び出す可能性があることです。これら一連の API を取得する際に発生する問題については、手動で 1 つずつ呼び出すプロセスにより、フロントエンドでの直接操作に追いつくことができます。
データベース操作の実装には
問題ありませんが、問題は、どのデータベーステーブルが企業によって変更されたのかを受験生が知らないこと、第二に、わかっていても手動で挿入するのが面倒で、DBのデータを直接変更してしまうことです。削除したり、誤って削除したりしました。変更されたことを考えるだけで手が震えます。

実際、API を呼び出すかデータベースを操作して自動化ツールにする、より良い方法があります。たとえば、通常の登録では、ユーザー名、パスワード、さらには電子メールと携帯電話番号の入力が必要になり、最終的にアカウントが生成されます。ユーザーのログイン機能をテストしたい場合、ユーザー名、パスワード、電子メールアドレス、携帯電話番号は重要ではありません。つまり、これらの値が何であるかは重要ではありません。ログインできるユーザー名/パスワード。したがって、API 呼び出しシーケンスを理解した後、デフォルトのユーザー名 (test+<timestamp> など) とパスワード (test123 など) を使用して、ワンクリックで登録できる自動化ツール (フロントエンドの知識が必要) を作成できます。このようにして、効率が大幅に向上し、手動操作エラーの可能性が減少します。

広い意味では、自動化ツールの実現も自動化技術の一部です。

3.2 テスト環境の準備

通常、テスターの操作はテスト環境で実行されます。自動テスト専用のテスト環境を構築して維持する必要がありますか? 当然、材料費や維持費もかかります。一連のテスト環境を一緒に使用すると、相互に干渉します。特に、比較的長いプロセスを持つ多くのビジネスでは、リンクを検証する必要があります。このデータが他のユーザーによって使用される可能性があり、ユースケースの失敗につながる可能性があります。そのため、再度分析して、最終的に見つける必要があります。それはデータの問題だということです。私が見つけたいくつかの解決策を次に示します。

自動化ユースケースでは、リアルタイムで環境を構築し、自動化ユースケースの実行後に環境を解放するメリット
：自動化されたテスト環境は自然に分離されるデメリット
：リアルタイム構築環境は大規模な環境が必要となるだけでなく、サーバーの数も増えますが、多くの時間がかかります。
したがって、ペースの速いインターネット製品には適していませ
ん手動テスト環境と自動テスト環境を別々に維持する
利点: データ分離
欠点: 更新がある場合、2 つのコピーを展開して維持する必要がある
インターネット製品のペースが速いため、導入の頻度が非常に高く、この方法の効率は比較的低いです。
手動テスト環境と自動テスト環境を共有します
。利点: 導入および保守が必要な環境は 1 つだけです。

欠点: データが相互に干渉する可能性がある

もちろん、命名規則、自動化ユースケースに関連するユーザーなどに固定プレフィックス (auto など) を付けるなど、データ干渉を解決する他の方法はあります。手動テストではこのタイプのデータは使用しません。

どのソリューションを使用するかは、現在解決すべき問題によって異なります。自動化が初期段階にある場合は、まず環境を共有し、自動化が構築されるまで待つことができます。自動化がより成熟し、データ干渉が深刻な場合は、2 セットの環境を維持することを検討できます。

4. 自動化技術の紹介

4.1 API自動化技術

API テストの基本手順は非常に標準的なため、コードレベルの API テストは比較的簡単です。

テストデータを準備し、
リクエストを開始し、
応答結果を検証します。リクエストパラメータであってもレスポンスパラメータであっても、それは KV のキーと値のペアであり、検証結果はこれらのキーと値のペアを解析するだけで済みます。
したがって、一般的に使用されるクラスとメソッドは少数しかありません。

問題は、どのインターフェイスがビジネスプロセス向けに設計されるか、インターフェイスの使用例をどのように設計するか、およびそれらをどのように整理して管理するかという点にあります。

この記事では詳しく紹介していませんが、時間があれば＆必要な人がいたら更新します〜

4.2 GUI自動化技術

GUI自動テストの中心的な考え方は、ページ要素認識技術に基づいてページ要素の操作を自動化し、実際のエンドユーザーの行動をシミュレートし、ソフトウェア機能の正確性を検証することです。

GUI 自動テストには主に 2 つの方向があります。

従来の Web ブラウザの GUI 自動テスト: 主流のソリューションは Selenium
モバイル端末の GUI 自動テスト: 主流のソリューションは Appium、app+Selenium
まず、Selenium と Appium の動作原理を理解しましょう。

TE は、Selenium 1.0 と 2.0 のテクノロジがまったく異なることを知っておく必要があります。前者のコアは Selenium RC であり、後者のコアは webDriver です。現在の 2.0 と 3.0 (本質的には 2.0 と同じ) が主流であることを考慮して、ここでは Selenium 2.0 の動作原理のみを紹介します。

Selenium 2.0 は典型的なクライアント/サーバーモデルです。クライアント側がテストケース、サーバー側がリモートサーバーです。実行プロセスは次のとおりです。