Selenium Manager：単一のインターフェース履歴

こんにちは、Habr！



私の名前はVitaliy Kotovで、Badooで働いています。 以前の記事の 1つで、テスターと開発者の両方が自動テストと対話するのに役立つ特定のインターフェイスがあると述べました。



彼についてもっと話すように頼まれました。



カットの下で、私は（最終的に！）このインターフェースがどのように書かれ、何ができるかについてお話します。 根付いた機能と、何らかの理由で請求されていないことが判明した機能について説明します。 おそらく、いくつかのアイデアはあなたにとって面白そうだと思われますし、そのような「ヘルパー」についても考えるでしょう。

それがすべて始まった方法

したがって、すべてはSeleniumテストから始まりました。 したがって、インターフェースの名前-Selenium Manager。 現在では、 Smokeテストを実行することもできます。



ある時点で、テストで多くのことができることに気付きました。 また、起動時に指定できる追加のキーの数によって明らかになり、テストは何らかの方法で実行されました。 それらのほんの一部を次に示します。

• プラットフォーム -テストを実行するプラットフォーム（開発者、ショット、またはステージング）を決定します。 会社でのテストのどの段階については、この記事で読むことができます。
  
  
• アプリ -テストを実行するアプリケーションを決定します。 テストにはPageObjectとは別のビジネスロジックしか含まれていないため、このキーは非常に便利です。
  
  
• ブラウザ -テストを実行するブラウザを設定します。
• ローカル -このキーを指定すると、テストはSeleniumファームではなく、ローカルで発生したSeleniumサーバーに移動します。
  
  
• ヘルプ -このキーを指定すると、テストを実行する代わりに、すべてのキーの指示が表示されます。 :)
  
  

などなど。 合計で、25個のキーをカウントしました。 また、そのうち11個について、値に3つ以上のオプションを指定できます。 これは非常に多く、これらすべてを念頭に置いたり、ヘルプコマンドを際限なく使用したくはありませんでした。

最初のバージョン

インターフェイスの最初のバージョンは2014年に登場しました。 私の考えによると、彼は設定から​​すべての可能なキーと値を解析し、ブラウザに対応するHTML要素のセットを描画するだけでした。 ユーザーが必要なパラメーターのセットを設定し、「get start command」ボタンをクリックすると、画面に対応する行が表示され、端末にコピーできます。



夕方、プロトタイプを「投げる」と、私はそれをみんなに見せに行きました。 もちろん、誰もが「しかし、このインターフェイスからすぐにテストを実行できるかもしれませんか？」と答えました。 もちろん、かなり期待されています。



私はこのように考え始めました...

インターフェイスからテストを実行する

テストはPHPで書かれています。 「ランチャー」として、PHPUnitを使用します。 コンソールからテストを実行するというアイデアは、次のとおりです。必要なパラメーターセットを設定し、テストを指定し、テストコードが実行されるサーバーにAJAXリクエストで送信します。



サーバー側では、 execコマンドを使用して起動されるコマンドラインが生成されます。 コマンドをコンソールから切り離すことを忘れないでください。そうしないと、テスト自体が実行されている限り、execが実行されます。 これは必要ありません-プロセスのPIDのみを取得する必要があります。



このようなもの：

function launchTest($cmd, $logfile) { $cmd = escapeshellcmd($cmd); exec($command = 'sh -c "' . $cmd . '" > ' . $logfile . ' & echo $!', $out); if (count($out) !== 1) { die("Wrong launch command: {$command}"]); } return $out[0]; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンテキストからわかるように、まずテスト中にログを書き込むログファイルを作成します。



PIDを受け取ったら、それと、単純なsetIntervalを実行するクライアントへのログファイルへのパスを返します 。 N秒に1回、クライアントはサーバーをノックし、ログファイルとPIDステータスの現在の内容を受け取ります。 PIDがない場合、 clearIntervalが呼び出されます。 とても簡単：

  var interval_id; function startPidProcessing() { interval_id = setInterval(self.checkPid, 4500); } function stopPidProcessing() { clearInterval(interval_id); interval_id = null; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、テストに合格する進捗が確認できます。 そして、いつ終了したかを知っています。

複数のテストを並行して実行する

2013年に、PHPUnitはテストを並行して実行できませんでした。 そして、それでも深刻な問題でした。それでも、私たちは非常に多くのSeleniumテストを持っていて、1時間以上1つのストリームに入ることができました。 それから私の同僚のイリヤ・クディノフは、ユニットテストでこの問題をどのように解決し始めたかについて記事を書きました。



しかし、最終的なソリューションはSeleniumテストにはあまり適していませんでした。



最適なソリューションはSelenium Managerでした。 結局、1つのテストをそこから起動できる場合、新しいタブを開いて2番目のテストを開始してみませんか？ 冗談です...



これは同じタブから実行できます。 これを行うには、各テストのPIDのリストをクライアント側に保存し、サーバーへの要求に応じてそれらすべてをポーリングし、それぞれのステータスを返すだけで十分です。 ログファイルも同様です。



同時に起動するテストの数をインターフェイスに設定する機能を追加しました。 実際、これはテストが実行されるスレッドの数です。 テストの総数よりもスレッドが少ない場合、テストはキューに入れられ、実行中のスレッドの1つが実行されるのを待ちます。

フィルターおよびグループテストの実行

これは十分ではありませんでした。 ここで、ターミナルを開き、そこから必要なすべてのテストファイルにパスをコピーする必要がありました。 さらに、ファイルからすべてのテストを実行するのではなく、一部のみを実行したい場合があります（このため、 フィルターパラメーターはPHPUnitに存在します）。



この問題を解決するために、クラス名のみを記述し、「::」を使用してフィルターを指定できる単純なtextarea HTML要素をクライアント上で作成しました。 たとえば、次のように：







そこに何かを書いたり、TeamCityから落ちたテストのリストをコピーすることもできます。 これらはすべてサーバーに送信され、解析されました。 ある組み合わせがそのようなテストがあるクラスの名前のように見えるかどうかを判断する方法は？ そして、このクラスでファイルへのパスを決定してテストを実行しますか？



私の方法は次のようになりました：

  public static function parseTestNames($textarea) { $parts = preg_split('/[,\s\n]+/', $textarea); $tests = []; foreach ($parts as $part) { $part_splited = explode('::', $part); $filter = $part_splited[1] ?? false; $testname = $part_splited[0]; if (is_file($testname)) { $testname = $filter ? $testname . '::' . $filter : $testname; $tests[] = $testname; } else { $found_tests = self::findPathByClassName($testname, $filter, $hard); foreach ($found_tests as $test) { $test = $filter ? $test . '::' . $filter : $test; $tests[] = $test; } } } $result = array_values(array_unique($tests)); return $result;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンテンツをスペースまたはハイフンで区切ります。 次に、各パーツを順番に処理します。 その中で、まずフィルタの値を取得するために「::」の組み合わせを探します。



次に、最初の部分（「::」記号まで）を見てください。 ファイルへのパスとして指定されている場合は、実行します。 そうでない場合（たとえば、クラスのみが指定された場合）、findPathByClassNameメソッドを実行します。このメソッドは、テストフォルダー内のクラスの名前で検索し、必要なパスを返すことができます。



PHPUnitには、テストのグループを尋ねる機能があります（詳細はこちら ）。 そして、それに応じて、これらのグループを指定してテストを実行します。 これらのグループは、これらのテストをカバーするサイトの機能に関連付けられています。 多くの場合（すべてではありませんが）多くのテストを実行する場合は、いくつかのグループに対してテストを実行する必要があります。



同じ検索を使用して対話的に取得されるグループのリストを追加しました。グループのいくつかを選択し、パスとクラス名を指定せずにテストを実行できます。



グループでテストを実行するためのインターフェイスは次のようになります。







これで、グループまたはこれらのテストの名前のリストでテストを実行できます。



実行中のテスト自体は次のようになります。







テストが既に実行されている場合は、黄色でマークされます。 緑-成功した場合、赤-落ちた場合。 青色は成功したテストを示しますが、その中にはスキップされたテストがあります。



セル内には通常のログがあり、PHPUnitを介してテストを開始すると表示されます。







テストが成功したかどうかの判断は、正規表現を使用してクライアント側で非常に簡単に実行できます。

  function checkTestReport(reg_exp) { let text = $(cell_id).html(); let text_arr = text.split("\n"); if (text_arr[0].search('PHPUnit') != -1) { return reg_exp.test(text_arr[2]); } else { return -1; } } this.isTestSuccessful = function(cell_id) { return checkTestReport(/^[\.]+\s/); }; this.isTestSkipped = function(cell_id) { return checkTestReport(/^[\.SI]+\s/); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、最もフォールトトレラントなソリューションではありません。 ある日PHPUnitの使用を停止した場合、または出力行が大幅に変更された場合、メソッドは動作を停止します（「-1」という回答を受け取ることで、このことを確認できます）。 しかし、どちらも近い将来に発生する可能性はありません。

クラウドでテストを実行する

テストを実行するためのインターフェイスを作成している間、ショットのテストの実行を積極的に開始しました。 TeamCityでは、必要なだけテストを実行するのは簡単ではないことがわかりました。 十分なエージェントはありませんが、高価です。



次に、テストの開始を「クラウド」システムに移行しました。 彼女については、次回詳細な記事を書くかもしれません。 それまでの間、このシステムは「クラウド」であるため、ログを収集するのは問題があるという事実に焦点を当てます。



実行の最後にテストが結果の記録を開始する単純なMySQLタブレットを作成しました。テストは成功または失敗し、エラー、継続時間などが続きます。



この表に基づいて、Selenium Managerの別のタブで、ショットの名前で実行の結果を描画し始めました。 落ちたテストをインターフェイスから直接再開する機能（テストが正常に合格すると、落ちたテストのリストから消えます）またはこのテストが同じエラーで他のショットでクラッシュしたかどうかを確認します（エラートレースによって決定されます）：







エラーのタイプ（同じトレース）でテストをグループ化するか、アルファベット順に並べることができます。

調査システム

上記のページに加えて、もう少し詳しく説明したいと思います。 これは調査ページです。 重要なタスクがマイナーバグでテストに入ることがあります。 ユーザーに影響を与えないJSエラーを言います。 このようなタスクをロールバックすることは実用的ではありません。 次のように進みます。バグチケットを開発者に置き、タスクをさらにスキップします。



しかし、ステージングとショットの両方に正直になり、生活を妨害し、ログを詰まらせるテストをどうすればよいですか？ 私たちはそれがなぜ落ちるのかを知っており、タスクが完了するまでそれが落ち続けることを知っています。 それを実行して期待される結果を得るのに時間の価値はありますか？



私は次の方法で問題を解決することが可能であると決めました：同じMySQLですべてがタブレットを作成し、そのタブレットにインターフェースを介してチケットのテストが追加されます。



開始前のテストはこのリストを受け取り、その名前とリストの名前を比較します。 テストを起動する必要がない場合、ログ内の対応するタスクでスキップ済みとしてマークされます。



また、王冠の王冠に行き、タスクのリストを受け取り、それらのステータスについてJIRA（バグ追跡システム）に行く簡単なスクリプトを書きました。 タスクが閉じられると、調査テーブルのエントリが削除され、テストが自動的に開始されます。

Selenium Managerで他にできること

上記に加えて、Selenium Managerには、興味深く同等に役立つものがたくさんあります。



たとえば、現在のビルドのすべてのショットのリストを取得し、それぞれに対して指定されたテストを実行します。 これは、テストがステージングで落ち始めたときに非常に役立ち、手と目で有罪のチケットを決定することができませんでした。



不安定なテストのリストと最も一般的なエラー（異なるテストの場合）が表示される表のあるページもあります。 テストの順序を保つのに役立つため、自動化エンジニアにとって便利です。 Seleniumテストは、他のUIテストと同様に、定義上不安定であり、これが正常であることを忘れないでください。 しかし、それらを安定させるために最も「悪い」テストの統計を取得することは良いことです。



各テストの反対側にあるこのプレートには、ワンクリックでテストを安定させるためのチケットを作成および転送できるボタンがあります。 チケットへのリンクはテーブルに残るため、誰かがすでにテストを行っている場合は表示されます。



次のようになります。







Seleniumファームノードのグラフィックが存在するページがあります。 自動化エンジニアのArtyom Soldatkinは、Seleniumにパッチを適用する方法について既に説明しているため、HTTPリクエストにより、これらのブラウザーとバージョンでグループ化された無料のブラウザーの数に関するデータを取得できます。 詳細についてはこちらをご覧ください 。



Seleniumファームに移動し、MySQLタブレットに折りたたんでこの情報を収集する簡単なスクリプトを作成しました。 クライアント側では、 plotly.jsを使用して、このデータに基づいてグラフを描画しました。



次のようになります。







したがって、すべてのニーズに十分な能力があるかどうかを確認する機会があります。 :)

根付かなかった機能

ほとんどの場合、試してみるまで機能が役立つかどうかを事前に言うことはできません。 一見有用なアイデアが主張されない場合があります。



たとえば、誰もが特定のテストまたはテストのグループにサブスクライブできるページがありました。 これらのテストがステージングに該当し始めると、すべての署名者がチャットで通知を受け取りました。



当初、手動テスター自身がテストのステータスを監視する場合、これは開発またはショットで完全にテストできないタスクに役立つと考えられていました。 署名することで、彼は説明に適合するテストのグループがステージングで壊れ、タスクにいくつかの問題があることを理解できました。



実際、テストのグループを予測することは困難であることが判明しました。 ほとんどの場合、多くの不必要な通知が来ましたが、落ちたテストは他のグループからのものだったため、必要な通知が届かないこともありました。



その結果、前のスキームに戻り、自動化エンジニア自身がテスト部門の担当者に問題があることを通知しました。

まとめ

インターフェイスはテストプロセスに正常に統合されました。 これで、任意のパラメーターを使用してテストを簡単、簡単、迅速に実行し、その安定性と自動テストシステム全体を監視できます。



一般的に、コンソールから逃げることができたことを嬉しく思います。 何か悪いことがあるからではなく、単にこの場合のインターフェースが便利に費やすことができる多くの時間を節約するからです。



これからどのような結論を引き出すことができますか？ ツールを使用して作業を最適化し、簡素化します-そして、あなたは幸せになります。



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