皆のためのセレン：QAエンジニアに自動テストの操作方法を教える方法

こんにちは、Habr！ 私の名前はVitaliy Kotovです。QA部門のBadooで働いており、テストの自動化、および場合によっては自動化テストの自動化を行っています。

今日は、BadooでSeleniumテストを簡単に操作できるようにした方法、手動テスト部門の担当者にそれらを操作する方法、およびこれから得た利益についてお話します。 記事を読んだ後、各段階の面倒さを評価し、おそらく、私たちの経験を部分的に採用したいと思うでしょう。

はじめに

時間が経つにつれて、自動テストの数は非常に印象的になり、自動化機能の数が一定で、テストの数が絶えず増加しているシステムは非効率的であると理解するようになります。

Badooでは、サーバー側とデスクトップWebが1日に2回リリースされます。 私の同僚のイリヤ・クディノフは、この記事について「2年間、1日4年間生き残る方法」という記事で非常に詳細に、そして興味深い話をしました。 この記事のさらなる例を理解しやすくするために、これをよく理解することをお勧めします。

自動テストのカバレッジが高いほど、リリースプロセス中にその数が大きく影響されることは明らかです。 どこかで機能を変更し、どこかでレイアウトを変更し、ロケーターが必要な要素の検索を停止し、どこかでA / Bテストをオンにし、一部のユーザーのビジネスロジックが異なるようになりました。

ある時点で、リリース後のテストの編集には、自動化が次のリリースまでにほとんどすべての時間を費やすという状況がありました。 そして円で。 新しいテストを作成し、アーキテクチャをサポートおよび開発し、いくつかの新しい問題を解決する時間はありませんでした。 そのような状況で何をすべきか？ 頭に浮かぶ最初の解決策は、別の自動化エンジニアを雇うことです。 ただし、このソリューションには大きなマイナス点があります。テストが再び2倍になった場合、別の自動化エンジニアを再び雇用せざるを得なくなります。

したがって、私たちは別の道を歩み、手動テスト部門の人にテストを行うように教えることを決定しました。彼らのタスクではリリース前にテストを独立して編集することに同意しました。 このソリューションの利点は何ですか？

まず、テスターが自動テストを修正できる場合、テスターはその落下の理由をさらに理解することができます。 したがって、テストの可能な限り早い段階でバグを見つける可能性が高くなります。 この場合、問題を迅速かつ簡単に修正でき、 設定された期日にタスクが実稼働に移行するため、これは良いことです。

次に、デスクトップWeb自動テストは、製品自体と同様にPHPで記述されています。 したがって、自動テストコードを使用して、テスターはこのプログラミング言語で作業するスキルを開発し、diffタスクを理解し、テスト中に何が行われ、最初にどこを見るべきかを理解することが容易になります。

第三に、もし彼らがテストを支配するなら、彼らは時々新しいものを書くのに時間がかかるかもしれません。 これはテスター自身にとって興味深いものであり、カバレッジに役立ちます。

そして最後に、すでに理解したように、自動化エンジニアは、アーキテクチャの問題を解決し、テストを高速化し、テストをより簡単に理解しやすくするためにより多くの時間を費やすことができます。

プラスが整理されています。 次に、短所が何であるかを考えてみましょう。

QAエンジニアは機能のチェックに加えてテストを修正する必要があるため、タスクのテストには時間がかかります。 一方で、これは確かにそうです。 一方、Badooの小さなタスクは、すべてまたはほとんどすべてが影響を受ける大規模なリファクタリングよりも優先されることを理解する価値があります。 QA部門の責任者であるイリヤ・アジェエフは、 「開発ワークフローがタスクの分解にどのように影響するか」という記事で、これがなぜなのか、どうやってこれに至ったのかについてよく語りました。 したがって、修正は数行のコードに減らす必要があり、これにはそれほど時間はかかりません。

多数のテストが壊れた大規模なタスクでは、多くのバグが発生する可能性があります。 このようなリファクタリング後のテストの修復プロセスで、手動テスト中に見逃されたバグが存在する状況に何度も遭遇しました。 そして、私たちが覚えているように、バグを見つけるのが早ければ早いほど、それを修正するのは簡単です。

したがって、小さなことは、自動テストを作成した経験のない人がテストを理解できるように、テストを適切にすることです。

リファクタリングのテスト

最初の段階はかなり退屈でした。 テストのリファクタリングを開始し、ページのテストのロジックをテスト自体のロジックから最大限に分離しようとするため、プロジェクトの外観を変更するときに、テスト自体のコードに触れることなく複数のロケーター定数を修正するのに十分でした。 その結果、 PageObjectのようなクラスを取得しました 。 それぞれは、1つのページまたは1つのコンポーネントに関連する要素、およびそれらとの相互作用の方法（要素の待機、要素の数のカウント、クリックなど）を説明します。 そのようなクラスにはアサートタイプの論理チェックはなく、UIとの相互作用のみが必要であることに同意しました。

これにより、非常に簡単に読み取れるテストが得られました。

$Navigator->openSignInPage(); $SignInPage->enterEmail($email); $SignInPage->enterPassword($password); $SignInPage->submitForm(); $Navigator->waitForAuthPage();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、次のようなシンプルなUIクラス：

 lass SignInPage extends Api { const INPUT_EMAIL = 'input.email'; const INPUT_PASSWORD = 'input.password'; const INPUT_SUBMIT_BUTTON = 'button[type=”submit”]'; public function enterEmail($email) { $this->driver->element(self::INPUT_EMAIL)->type($email); } public function enterPassword($password) { $this->driver->element(self::INPUT_PASSWORD)->type($password); } public function submitForm() { $this->driver->element(self::INPUT_SUBMIT_BUTTON)->click(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、パスワードのロケーターが変更され、目的の入力フィールドが見つからずにテストが中断した場合、それを修正する方法が明確になります。 さらに、enterPassword（）メソッドが複数のテストで使用されている場合、対応するロケーターを変更するとすぐにすべてが修正されます。

このフォームでは、テストはすでに人に見せることができます。 これらは読みやすく、PHPでコードを記述した経験がなくても操作できます。 基本を説明するには十分です。 これを行うために、独立したソリューションの例と割り当てを含む一連のトレーニングセミナーを開催しました。

トレーニング

トレーニングは、単純なものから複雑なものまで徐々に行われました。 最初のレッスンの後、タスクは壊れたテストを修正することでした。そこではいくつかのロケーターを修正する必要がありました。 2番目のレッスンの後、UIクラスにいくつかのメソッドを追加し、テストでそれらを使用することにより、既存のテストを拡張する必要がありました。 3回目以降、彼らはすでに自分で新しいテストを書くことができました。

これらのセミナーに基づいて、テストを適切に処理する方法と、プロセスで発生する可能性のある落とし穴に関する記事が社内Wikiに書き込まれました。 よく寄せられる質問へのベストプラクティスと回答を収集しました。ロケーターを正しく構成する方法、その場合はテスト用に新しいクラスを作成する価値があり、既存のテストにテストを追加する、新しいUIクラスを作成するタイミング、定数の正しい名前付け方法ロケーターなど。

現在、新しいQAエンジニアが会社に来ると、Wikiから自動テストの操作に慣れる必要のある記事のリストを受け取ります。 また、テストプロセスで落下テストに最初に遭遇したとき、彼はすでに完全に武装しており、何をすべきかを知っています。 もちろん、彼はいつでも私や他のオートマリストに近づいて、何かを明確にしたり尋ねたりすることができますが、これは正常なことです。

私たちは、QAエンジニアが新しいテストの作成を含む自動テストで作業する能力が、社内の成長の要件の1つであることで合意しています。 開発したい場合（そして誰がしたくないのでしょうか？）、自動化にも対処しなければならないという事実に備える必要があります。

Teamcity

Seleniumテストは、プロジェクトコードと同じリポジトリにあります。 最初のSeleniumテストの作成を始めたとき、PHPUnitといくつかの単体テストが既にありました。 テクノロジーを作成しないために、同じPHPUnitを使用してSeleniumテストを実行し、ユニットテストの隣のフォルダーに配置することにしました。 自動化エンジニアのみがテストに関与していましたが、リリース後に行ったため、マスターでテストをすぐに変更できました。 そして、それに応じて、彼らはMasterとともにTeamCityでもテストを開始しました。

彼らがタスクでテストを使い始めたとき、編集はタスクコードが存在する同じブランチに対して行われることに同意しました。 第一に、これにより、テストの編集内容がタスク自体とマスターに同時に配信され、第二に、タスクがリリースからロールバックされた場合、追加のアクションなしで編集内容もロールバックされました。 その結果、リリースブランチからTeamCityでテストの実行を開始しました。

したがって、自動化ツールがリリースのテストのみを監視でき、同時に新しいタスクがテストの修正とともにすぐにリリースされるシステムを取得しました。 このようなシステムでは、生涯にわたるグリーンビルドが提供されます。 :)

しかし、それだけではありません。

diffタスクでテストを実行する

各タスクのすべてのテストを実行することは、時間とリソースの両方で非常に高価です。 各テストにはブラウザーを提供する必要があるため、強力なSeleniumファームをサポートする必要があります。 また、プロジェクトがデプロイされ、多数の自動テストが並行して実行される強力なサーバーも必要です。 そして、これは高価な喜びです。

どのタスクを実行する価値があるかをタスクごとに動的に計算することはクールだと判断しました。 これを行うために、各テストにチェック対象の機能またはページに関連付けられたグループのセットを割り当てました：検索、プロファイル、登録、チャット、およびグループなしでテストをキャッチし、対応する通知をオートマトンに書き込むスクリプトを記述しました。

次に、タスクでテストを実行する前に、Gitを使用して変更されたファイルを分析する方法を学びました。 ほとんどの場合、それらは関連する機能に何らかの形で似ている、または対応するフォルダーにあるとも呼ばれます：

• /js/search/common.js
  
  
  
  
• /View/Chat/GetList.php
  
  
  
  
• /tpls/profile/about_me_block.tpl
  
  
  
  

どのグループの名前とも一致しないファイルのルールをいくつか考え出しました。 たとえば、チャットではなく、メッセージ機能と呼ばれるファイルの一部があります。 エイリアスのマップを作成し、messagerというファイルを見つけたら、チャットグループのテストを実行します。ファイルがコアフォルダーのどこかにある場合は、テストセット全体を実行する価値があると判断します。

もちろん、そのような問題を解決するための普遍的なアルゴリズムは存在しません-あるクラスの変更が最も予期しない場所でプロジェクトに影響を与える可能性は常にあります。 しかし、これは恐ろしいことではありません。ステージングでは、一連のテストを実行し、問題に必ず気づくようにするためです。 さらに、次回同様の問題を見逃さないためのルールを考え出し、事前に発見します。

不安定で壊れたテスト

最後にやるべきことは、不安定で壊れたテストに対処することです。 失敗したテストが何百回もあるので、どのテストがマスターで壊れているのか、ケースの50％で合格したためにどのテストが失敗したのかを把握する必要はありません。 テストに自信がない場合、テスターはそれらを注意深く調査せず、さらに編集します。

大きなタスクをリリースするとき、ユーザーには見えないいくつかの小さなバグ（たとえば、機能に影響しないJSエラー）が許可され、本番環境への重要な変更のレイアウトを遅らせることなく次のリリースで修正できます。

そして、テスターに​​同意できれば、テストではさらに難しくなります。彼らは正直に問題を見つけてクラッシュします。 さらに、バグがマスターにある場合、テストは他のタスクに該当し始めますが、これは非常に悪いことです。

そのようなテストのために、次のシステムを思いつきました。 落下テストの名前と問題を修正するチケットを指定できるMySQLプレートを入手しました。 テストは実行前にこのリストを取得し、各テストはそのリスト内で自身を検索します。 見つかった場合、そのようなチケットの準備ができていないことを示すメッセージでSkippedとマークされ、テストを実行しても意味がありません。

バグトラッカーとして、JIRAを使用します。 並行して、スクリプトはcronによって追跡され、 JIRA APIを介してこのテーブルからチケットステータスをチェックします 。 チケットがクローズ状態になった場合、レコードを削除し、テストが自動的に再開されます。

その結果、壊れたテストは実行結果から除外されます。 一方では、これは良いことです-彼らはもはや実行に時間を費やさず、この実行の結果を「詰まらせません」。 一方、テスターはSeleniumManagerを常に開いて、どのテストが無効になっているかを確認する必要があるため、必要に応じて手動でケースを確認してください。 そのため、この機能を乱用しないようにしています。無効なテストが1つまたは2つ以上あることはほとんどありません。

不安定なテストの問題に戻りましょう。 この記事はUIテストに関するものなので、これらは高レベルのテストである統合とシステムであることを理解する必要があります。 そのようなテストは、定義上、不安定であり、これは正常です。 ただし、これらの不安定性を把握し、明らかに「ケース内」にあるテストからそれらを分離したいと考えています。

かなり前に、すべてのテストの開始を特別なMySQLテーブルに記録する価値があるという結論に達しました。 テストの名前、実行時間、結果、このタスクが実行されたタスクまたはステージングなど。 まず、統計のためにこれが必要です。 次に、このテーブルは、テストを実行および監視するためのWebインターフェイスであるSeleniumManagerで使用されます。 彼についていつか別の記事を書きます。 :)

上記のフィールドに加えて、新しいコードがテーブルに追加されました-エラーコード。 このコードは、落とされたテストの証跡に基づいて生成されます。 たとえば、タスクAでは、テストは74行目で行われ、85行目で、UIクラスは15行目で呼び出されました。なぜこの情報を接着して記述しないのですか：748515？ 次回、テストが他のタスクBに該当する場合、現在のエラーのコードを取得し、テーブルからの単純な選択で、以前に同様のクラッシュがあったかどうかを確認します。 存在した場合、テストは明らかに不安定であり、それに応じて注意することができます。

もちろん、テストは時々変更され、テストの対象となる行も変更されます。 そして、しばらくの間、古い間違いは新しいと見なされます。 ただし、一方で、これはそれほど頻繁には発生しません。覚えているように、テストロジックはUIロジックから分離されており、ほとんど変更されないためです。 そのため、ほとんどの不安定なテストは、実際にキャッチしてタグ付けします。 SeleniumManagerには、機能が機能することを確認するために、選択したタスクの不安定なテストを再起動できるインターフェイスがあります。

まとめ

私は詳細を試みましたが、あまりにも細心の注意を払わずに、「選ばれた」グループだけが自動テストに従事していたポイントAから、テストが誰にとっても便利で理解しやすいポイントBに至るまでの経路を説明しました。

このパスは、次の手順で構成されていました。

1. すべてのテストを記述する特別なアーキテクチャの開発。 古いテストのリファクタリング。
2. 新入社員向けのトレーニングセミナーとドキュメントの作成。
3. 自動テストの最適化：TeamCityでのテスト起動のフローの変更、特定のタスクのdiffテストの実行。
4. テスト実行の結果の簡素化：テスターは、まず、おそらく自分のタスクに関連する倒れたテストを確認する必要があります。

その結果、手動テスターがSeleniumテストを非常に快適に操作できるシステムになりました。 彼らはどのように動作し、どのように実行するかを理解し、それらを編集する方法を知っており、必要に応じて新しいものを書くことができます。

同時に、自動化エンジニアは、不安定なテストをキャッチして編集するためのより正確なシステムを作成し、テストを実行して実行結果を解釈するための便利なインターフェイスを作成し、テスト自体をスピードアップして改善する：複雑なタスクを行う機会と時間を得ました。

ツールを改善して使いやすくすると、「幸せ」になります。 ご清聴ありがとうございました！