プロジェクトでテストがまったく行われていない場合、またはその程度が最小限である場合に、テスト自動化システムを構築した経験についてお話したいと思います。
この記事が初心者の自動テストに役立つことを願っています。
- 最初の部分では 、一般的なアプローチを優先します。
- 例を含む2番目のパート（ パート1 ）では、JAVA +自動テストのプロジェクトを作成し、APIをすばやくテストする方法を説明します。
- 3番目の部分では、UIテストのためにプロジェクトを補完し、並行テストを行います。
いつ自動テストを行うのですか？
短い答えはできるだけ早くです。
完全なものは以下に明らかにされます。 いずれにせよ、プロジェクトが3年間機能し、すべてが手動でチェックされたとき、人生は非常に単調になります。 また、1〜2か月で自動化する5000個のシナリオのセットには問題があります。 原則として、このようなプロジェクトでは、スクリプトの再作成を開始する必要があります。 速くなるからです。 そして、古いものが大幅な変更なしに自動化されることは事実ではありません。
なんで？
autotetsの場合：
- 回帰のシナリオを蓄積する
- 偏りのない
- 速い
蓄積されたシナリオ
自動化されたスクリプトのセットが大きいほど、特にデータが開始するたびに変化する場合は、回帰を見つける可能性が高くなります。
自動テストが安定して合格し、一部のブランチに落ちた場合、要件が変更されたか、バグが発生したか、インフラストラクチャが失敗しました。
公平性
要件が変更された場合、自動テストはメイン機能の変更とともに変更に進む必要があります。 これが、テスターがTKの承認に参加している理由です。
テストの実行が自動的にタスクにリンクする場合、誰もテストされていないと言うことはできません。 またはその逆も可能です。 一般に、問題は明らかに少ないです。
スピード
各テストが面倒な条件を満たす場合：
前提条件-テスト-事後条件
このようなテストは簡単に自動化できます。
そして、並列化は簡単です。 彼らは独立しているからです。
スレッドの数-他のユーザーを邪魔しないために耐えられるテストサーバーの数。
2番目のポイントは速度そのものです。 手動モードでは、製品の作成をクリックすると、オンラインストアでの検索と購入は5分です。 4つのブラウザー。 合計20分。 たった1つの小さなシナリオで。
このシナリオの自動テストには1.5分かかります。 しかし、8つのブラウザーでは。 （各ブラウザーの最新バージョンと最後から2番目のバージョン）。
どこから始めますか？
カスタムスクリプトを使用。
アトミックテストの価値は、特にマイクロサービスでは常に低下します。 そして一般的に、理想的な世界では、これはプログラマーの責任範囲です。 このようなエラーは、単体テストの段階で検出する必要があります。
QAはユーザーストーリーから機能するはずです。 プログラマは通常彼女を知らず、知りたくないからです。
したがって、ロジック1テスト-1ユーザーケース（ビジネスシナリオ）は現実に最も近いものです。
もちろん、データの準備には困難があります。たとえば、オンラインストアの場合、カードの支払いプロセスでは、バスケット内のものと、新しいユーザーのデータ、または既存のユーザーの承認データのいずれかが必要です。
はい、前提条件はテストよりも時間がかかる場合がありますが、スクリプトを再利用することは難しくありません。
自動化するスクリプト
短期的には変化しにくい。 少なくとも一部は自動化されました。
または最も一般的に使用されます。 テストデータの生成において手動テストを支援することは理にかなっています。 たとえば、掲示板では、アナウンスの作成を自動化するのが理にかなっています。 さらに、どのシナリオにも広告が必要です。
正確に何をしますか？
通常、そこのプロジェクトで
- バックエンド
- フロントエンド
- モバイルアプリ
- 腺
そして最後の2つのポイント-通常は別々に住んでいます。 携帯電話は独自のスクリプトでテストされており、準備なしでJTAGに従って鉄のデバッグにアプローチできる人はほとんどいません。
したがって、バックエンドとフロントを扱うことを提案します。
シナリオを選ぶ
オンラインストアがあるとします。
管理パネルがあり、クライアントと管理フロントがあります。
このすべてに役立つAPIがあります。
自動化を開始する場所
見てみましょう。
顧客がいて、従業員がいます。
クライアントには最初のケースがあります-製品の表示と検索、バスケットへの追加、デザイン。
従業員の最も一般的なケースは、製品カードの追加です。
どのケースが最初に自動化されますか？ そしてどうやって？
ストアにとって最も重要なことは販売です。
したがって、顧客の履歴はビジネスにとって最も重要です。 したがって、製品を見つけてバスケットに入れ、支払い方法を使用してチェックアウトを完了することが最初に行うことです。
APIによる。 しかし、フロントなし。 ここで議論することができますが、ほとんどの場合、デザインは2〜3倍変更されますが、バックエンドはほとんどありません。 そのため、最初の段階では、インターフェイスを手動で確認する必要があります。
次に、製品カードとその前面を編集するAPIを確認します。
そして、クライアントに戻ります。 この段階では、最も頻繁なユーザーアクションと最も頻繁なクライアントパスに関する統計が既にあります。 はい、Yandex MetricとWebvisorはテスターにも役立ちます。
訪問者の0.5％がこの機能を使用している場合、生成された支払い機能による会社の口座への支払い機能が機能するかどうかを確認することは、最初の段階では意味がありません。 もちろん、ここでこれが必要な理由をマネージャーに質問することができますが、これはそれについてではありません。
40％の人がカードを使ってサイトで支払い、30％を現金で、20％を代金引換で、10％を他のすべての方法で支払ったとします。
最初にどのタイプの支払いを確認しますか？ もちろん地図。
つまり、現時点でビジネスにとって最も重要なシナリオを明確に理解する必要があります。 そして、その品質は何よりも重要です。
事後条件
テストですべてを作成しました。 ごみ。 クリーンアップする必要があります。 どのテストを後からクリーンアップするかを事前に予測する必要があります。
商品を店に置いておくことができ、何も悪いことが起こらない場合は、通常のユーザーに管理者権限を追加する必要があります。 そして、権利に関連する次のテストが落ちるかもしれません。 それとも悪い-それは落ちているはずですが、肯定的になります。
奇妙な
ユーザーがバグを見つけるスクリプトを自動化するとき、奇妙なアプローチがあります。 通常、これらは非常にエキゾチックなシナリオであり、リソースを浪費しても意味がありません。 取引先銀行のデータを更新する機能が壊れた状況がありました。 BICディレクトリとの同期に失敗しました。
つまり、新しいBICは更新されませんでした。 しかし、新しい銀行は正常に始動しました。
このシナリオを自動化するのは理にかなっていますか？ 請負業者が毎日変わる場合-多分。 そして、それは計画の欠陥でした。
これが1年に5〜6回行われる場合、優先度の高いタスクを実行する方が良いでしょうか？
次に何が起こりますか？
次の記事では、APIのテストをすばやく開始する方法、これらのテストをリリースに埋め込む方法、テストを並列化する方法、テスト用のデータを選択する方法、および提供するものについて説明します。
農薬の効果と、それを最小限に抑える方法について思い出させてください。
テクノロジー：Java + maven + testng + allure + RestAssured + Pict。