インターフェイスロジックを除き、Seleniumで他に何を確認しますか

こんにちは、Habr！



私の名前はVitaliy Kotovで、Badooテスト部門で働いています。 ほとんどの場合、私はSeleniumを使用しています。 この素晴らしいツールを使用して、さまざまなタスクを解決します。機能のテストから、エラーログでの作業の簡素化、APIとの相互作用のチェックまでです。



この記事では、Seleniumが解決するのに役立つタスクについて説明します。 行こう！ :)

セレンについて少し

Googleが「Selenium」について最初に伝えることは次のとおりです。

SeleniumはWebブラウザー自動化ツールです。 ほとんどの場合、Webアプリケーションのテストに使用されますが、これに限定されません。

Seleniumを使用すると、手でできることとほぼ同じことを実行できます。ページを開いて、それらとやり取りします。 しかし、彼は目を「ぼかす」ことができず、誤って間違った方向にクリックすることができないため、より速く確実に行います。



テストの自動化において、Seleniumが最初に使用されるのは、サイトの機能をチェックすることです。

機能チェック

ユーザーは通常、サイトで何をしますか？ 彼らはそれを開き、前後にクリックし、クリックの結果をいくつか見る：リダイレクト、ポップアップ、要素の強調表示など。 このプロセスをテストしたい（必要がある）。 ユーザーに、ビジネスロジックに埋め込まれたアクションに対する応答を正確に表示させる必要があります。



これを行うために、ユーザーのアクションを記述するスクリプトが作成されます。 例：

1. サイトを開きます。
2. 認証ボタンをクリックします。
3. ログインフォームがロードされるのを待ちます。
4. ユーザー名とパスワードを入力します。
5. [送信]ボタンをクリックします。
6. 許可されたページへのリダイレクトを待ちます。

サイトで認証が壊れている場合（たとえば、プログラマが何かを台無しにした場合、getUserメソッドは常にfalseを返します）、Seleniumはステップ6を実行できません。テストは失敗し、通知されます。 実際、コードのどこかで例外がスローされ、プロセスは対応するエラーコードで終了します。



この一連のアクションは、機能テストと呼ばれます。 これはおそらくSeleniumを使用する最も一般的な方法です。 しかし、もっと面白いものがあります。

JSエラー収集

通常のユーザーには、JSエラーは表示されません。 これは正しいです-彼は必要ありません。 ただし、開発者にとっては、コードが「シュート」するかどうかを理解することが重要です。 このコンテキストのJSエラーは、ユーザーに気付くものとユーザーに干渉しないものの2種類に分けます。



最初のタイプのエラーでは、すべてが明らかです。 JSエラーのためにサイトがユーザーのアクションに応答しない場合、Seleniumテストはこれを認識します。



2番目のタイプのエラーでは、すべてがより複雑になります。 アプリケーションの使用を妨げない場合、修正する価値はありますか？ Badooでは、このようなエラーと第1種のエラーを修正しようとします。 まず、何らかの方法でエラーが発生すると、問題が発生します。 第二に、ある場合にユーザーに干渉しない場合、これは別の場合にユーザーに干渉しないという意味ではありません。



Badoo開発者は、独自のソリューションを使用してJSエラーを収集します。 クライアントでエラーが発生すると、コードはすべての可能なデータを収集し、それを特別なストアに送信します。 エラーが発生した時間、ユーザー情報、およびトレースに関する情報を保存します。 ただし、この情報でさえ、エラーを再現するには不十分な場合があります。 これがSeleniumが私たちを助ける場所です。



Seleniumテストでは、ユーザーがサイトで実行する最も一般的なアクションをすべてチェックします。 エラーがある場合、これらのテストの通過中にエラーが発生する可能性が高くなります。 そのようなエラーに注意するようにSeleniumに教えてください。



この問題を次のように解決しました。テストサーバーのみに接続されるテンプレートを追加しました。 このテンプレートには、JSエラーを特定のオブジェクトに収集するJSコードがありました。 このようなもの：

var errorObj = { _errors : [], addError : function(message, source, lineno) { this._errors.push( "Message: " + message + "\n" + "Source: " + source + "\n" + "Line: " + lineno ); }, getErrors : function() { return this._errors; } } window.onerror = function(message, source, line_no) { errorObj.addError(message, source, line_no); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同じことは、 executeコマンドを使用してSeleniumテスト自体で実行できます。 ユーザーがブラウザコンソールを開いてコードを実行したかのように、ページでJSコードを実行できます。 しかし、その後、いくつかの間違いを見逃す可能性があります。



実際、ページが完全にロードされた後にのみ、Seleniumテストでこのコードを実行できます。 したがって、ダウンロード中に表示されるすべてのエラーは気付かれません。 テンプレート内のコードはメインのJSコードの前に実行されるため、テンプレートにはこのような問題はありません。



テンプレートを追加すると、すべてのエラーがerrorObjオブジェクトに収集され始め、グローバルにアクセスできるようになりました。 そして、executeコマンドを使用できるようになりました。 errorObj.getErrors（）を実行するメソッドをSeleniumフレームワークに追加しました。つまり、errorObjに到達したすべてのエラーを受け取り、Seleniumテスト自体の側で保存しました。



PHPでSeleniumテストを作成していることを思い出させてください。 エラー収集コードは次のようなものです。

  public function collectJsErrors() { $return_errorObj = /** @lang JavaScript */ 'if (typeof errorObj !== "undefined") {return errorObj.getErrors();} else {return null;}'; $js_result = $this->execute($return_errorObj)->sync(); foreach ($js_result as $result) { $current_stacktrace = $result; //check if an error is known foreach (self::$known_js_errors as $known_error) { if (strpos($current_stacktrace, $known_error) !== false) { continue 2; } } //check if the error already caught foreach ($this->getJsErrors() as $error) { $existed_stacktrace = $error['error']; if ($current_stacktrace == $existed_stacktrace) { continue 2; } } //collect an error $this->addJsError([ 'error' => $result, 'location' => $this->getLocation(), ]); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

errorObj JSオブジェクトからエラーを取得し、それぞれを処理します。



いくつかのエラーはすでにわかっています。 彼らはプロジェクトに参加しており、すでに修正プロセスにあるか、「実験室」条件でのみ複製されていることを知っています。 たとえば、テストユーザーにのみ表示され、テスト用に準備した方法に関連するエラー。 テストではこのようなエラーは無視します。



テスト中に同じエラーが2回目に発生した場合、それも無視します-ユニークなエラーのみに関心があります。



新しいエラーごとに、URLを追加し、すべての情報を配列に格納します。



サイトでの各アクションの後にcollectJsErrors（）メソッドを呼び出します。ページを開く、要素を待機してクリックする、データを入力するなどです。 インターフェースとどのようにやり取りしても、このアクションがエラーを引き起こさないことを確認する必要があります。



エラーが収集された配列は、tearDown（）でテストの最後にのみチェックします。 結局、エラーが何らかの形でユーザーに影響を与える場合、テストは失敗します。 そうでない場合は、すぐにテストをドロップするのが悪いため、最初にスクリプトを最後まで確認する必要があります。 突然、このエラーの背後にもっと深刻な問題があります。



したがって、クライアントのエラーをキャッチするためにSeleniumテストを教えることができました。 また、エラー自体が再現しやすくなり、どのテストでエラーが検出されるかがわかりました。

レイアウトチェック

Seleniumテスト自体は、レイアウトをテストするようには設計されていません。 もちろん、対話する必要のある要素が見えないか、別の要素によって隠されている場合、テストはそれについて「教えて」くれます。 このSeleniumはそのまま使用できます。 しかし、ボタンがどこか下に移動して見た目が悪くなった場合、セレンテスト全体は問題ではありません。そのタスクはクリックすることです...



それにもかかわらず、各リリースの前に手動でレイアウトを確認することは（たとえば、デスクトップWebの場合、1日あたり2つあります）、各ページ、各ブラウザで、長い時間がかかります。 繰り返しになりますが、人的要因が介入する可能性があります。目が「ぼやけ」、何かを忘れることがあります...このプロセスを何らかの形で自動化する必要があります。



まず、写真用のシンプルなストレージを作成しました。 POSTリクエストにより、リリースの追加バージョンを示すスクリーンショットを送信することができ、リリースのバージョンを示すGETリクエストにより、このリリースに関連するすべてのスクリーンショットを取得できます。



次に、Seleniumのテストを作成して、関心のあるすべてのブラウザーを表示し、その上で、関心のあるすべてのページ、ポップアップ、オーバーレイなどを開きました。 各場所で、彼らはページのスクリーンショットを撮り、それをこのストアに送りました。



ストレージインターフェイスを使用すると、すべてのスクリーンショットを手動ですばやくスクロールし、すべてのブラウザーですべてのページが適切に表示されるようにすることができます。 もちろん、このように小さなバグを見つけることは困難です。 しかし、レイアウトが大幅に壊れた場合、すぐに目を引きました。 いずれにせよ、スクリーンショットの反転は、すべてのブラウザでサイトを手でクリックするよりも速くて簡単です。



最初は、多くのスクリーンショットがありませんでした。 しかし、しばらくしてから、サイト上のページよりもはるかに多くの選択肢があるレターをテストしたかったのです。



手紙のスクリーンショットを取得するには、いくつかのトリックに頼らなければなりませんでした。 実際、テストで生成されたレターのHTMLを取得することは、実際のメールサービスに移動するよりもはるかに簡単であり（そして、私たちはまだSeleniumテストについて話している）、そこで必要なレターを見つけ、それを開いて、スクリーンショットを撮っています。 HTML文字を「バックドア」を使用して私たちの側で受信できるからです（特定のユーザーに関するデータを受信し、簡単なcURLリクエストを使用してテストユーザーのテスト環境で操作できるQaAPIツールがあります）。 しかし、サードパーティサービスの場合、ロケーター、メソッドなどのページオブジェクトを記述、安定化、およびサポートする必要があります。



ほとんどすべての電子メールクライアントが、「裸の」HTMLで表示されるのとは少し異なる方法で文字を表示することは明らかです。 しかし、レイアウトのいくつかの重大なエラーは、文脈から外れて文字の外観を壊してしまうため、正常にキャッチされます。



しかし、結果のHTMLをどうすればよいでしょうか？ すべてのブラウザで正しく表示されるようにする方法は？ それは非常に簡単でした。 コレクターには空のページがあり、Seleniumテストで簡単な実行を実行できます。

  public function drawMailHTML(string $html) { $js = /** @lang JavaScript */ 'document.write("{HTML}")'; $js = str_replace('{HTML}', $html, $js); $this->execute($js)->sync(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

適切なブラウザでこれを行うと、HTMLがどのように表示されるかを確認できます。 スクリーンショットを撮って同じコレクターに送信するだけです。



これが行われた後、スクリーンショットがたくさんありました。 そして、それらを1日に2回手動でチェックすることは本当に難しくなっています。



この問題を解決するには、ピクセルごとの写真の単純な比較に頼ることができます。 この場合、プロジェクトにあるすべての変数を考慮する必要があります。 たとえば、文字のある例では、ユーザー名と彼の写真になります。 この場合、スクリーンショットを撮る前に、HTMLを少し修正して、写真と名前をデフォルトのものに置き換える必要があります。 または、同じ名前と写真を持つユーザー向けのレターを生成します。 :)



一貫性の低いコンテンツの場合、このような操作がはるかに多くなります。



次に、不一致ピクセルの数を取得し、変更がどれほど重要であるかを結論付けることができます。 参照ゾーンと一致しないゾーンをチェック画像にマークすることにより、差分を作成できます。



PHPでは、 ImageMagickライブラリはこれらの目的に最適です。 また、このようなテストはJavaScript開発者によって作成され、 Resemble.jsを使用します 。



例として、Badooログインページについて考えます。







何らかの理由で、「私を記憶する」チェックボックスが失われたとします。 このため、送信ボタンはわずかに高くなりました。 差分は次のようになります。







この図では、バイオレットは、参照スクリーンショットと要素が欠落しているスクリーンショットとの不一致を示しています。 正確に何が間違っているかがすぐにわかります。



比較システムは重要なピクセル数に設定できます。1つのスクリーンショットがこの数を超えていない場合は、すべてが正常であるという通知を送信できます。 いくつかのスクリーンショットが大幅に異なるようになった場合-アラームを打つ...



したがって、スクリーンショットを手動で確認することを忘れて、本当に注目に値するものだけを見ることができます。

クライアントとAPIの相互作用を確認する

Badooでは、すべてのクライアント（デスクトップWeb、モバイルWeb、AndroidおよびiOSアプリケーション）は、特定のHTTPベースのAPIを使用してサーバーと通信します。 このアプローチにはいくつかの利点があります。 たとえば、クライアントとサーバーを並行して開発する方がはるかに簡単です。



ただし、エラーの余地があります。 バグまたは一般的に誤って考えられたアーキテクチャが原因で、クライアントが本来よりも頻繁にサーバーにアクセスする可能性があります。 この場合、おそらく何かが正しく動作しないことは言うまでもなく、余分な負荷が作成されます。



開発やテストの段階でもそのようなことを監視するために、Seleniumテストも使用します。 これらのテストの最初に、「デバイスID」というCookieを生成します。 その値をサーバーに渡します。サーバーは、この「デバイスID」に対して、サーバーに送信されるすべてのAPIリクエストの記録を開始します。



その後、テスト自体が実行され、ページを開く、相互に書き込むなどの特定のシナリオを実行します。 この間、サーバーはリクエストをカウントします。



テストの最後に、サーバーに記録を停止する信号を送信します。 サーバーは特別なログを生成します。これにより、作成されたリクエストの種類の数を把握できます。 この量が基準からNパーセントを超えて逸脱すると、特別な通知が自動テスターに​​届き、状況を理解し始めます。 この動作が予期される場合があります（たとえば、サイトの新しい機能に関連付けられた新しいリクエストが表示される場合）-参照値を調整します。 また、クライアントが誤って不要なリクエストを作成することが判明する場合があり、これを修正する必要があります。



クライアントの新しいバージョンがユーザーに届く前に、ステージングでこのようなテストを実行します。 視覚的には、リリースごとのリクエスト数の比較は次のようになります。







各色は、特定の種類のリクエストを示しています。 リクエストがより頻繁に繰り返されるようになった場合、視覚的に顕著になります。 この場合、特別な通知もありますので、各リリースの前に統計を確認する必要はありません。

サーバーログ

サーバーログのエラーに迅速に対処するために、同様のトリックを使用します。 ステージングに新しいエラーが表示されるとき、それを再現する方法と、どのチケットが表示されたのかが常に明確ではありません。



Seleniumテストの最初に、特別なCookie「testname」が作成され、そこに現在のテストの名前が渡されます。 したがって、自動テスト中にサーバーでエラーが発生した場合、再生シナリオがわかっているため、ほとんどの場合、それを再現する方が簡単です。 エラーがリリースに来たタスクを見つけるには、リリースされているすべてのタスクでSeleniumテストを実行し、そのログを確認します。



このプロセスを自動化しました。これについては以前の記事で書きました。



一般に、このアプローチにより、リリース内のサーバーエラーを迅速に処理し、ローカライズできます。

金曜日の夜の自動ピザ注文

そして、実際には、なぜですか？ :)

まとめ

Seleniumは、ブラウザーを操作するためのツールです。 そして、まさにその方法と理由は、このツールを使用して決定する人次第です。 賢くすることで、人生を大幅に楽にすることができます。



もちろん、いくつかのタイプのチェックには、より適切なツールがあります。 たとえば、Seleniumは、cURLライブラリなどに記述された脆弱性スキャナーや高速パーサーを完全に置き換えることはできません。 また、負荷テストに使用するのはかなり奇妙です。この場合、戦闘アプリケーションよりもSeleniumファームのフォールトトレランスをチェックする可能性が高くなります。 :)



ただし、Seleniumが優れている特定のタスクセットがあります。 私は彼がどのように私たちを助けるかについて話しました。 私はあなたの会社でセレンを使用する興味深い方法について聞いてうれしいです。



ご清聴ありがとうございました。