A / BテストをUIテストでカバーします。 ネイティブコードで混乱しないようにする方法

こんにちは、Habr！



私の名前はVitaliy Kotovです。私はBadooで働いており、ほとんどの場合、テストの自動化の問題に取り組んでいます。 この記事でそのような質問に対する解決策を共有したいと思います。



それは、A / BテストでUIテストを実行するプロセスをどのように整理したかについてです。 私たちが遭遇した問題と、最終的にどの洪水に遭遇したかについてお話します。 猫へようこそ！

始めるまで...

この記事では、テストという言葉は非常に一般的です。 それは、UIテストとA / Bテストを同時に話しているからです。 テキストが読みやすくなるように、私は常にこれらの2つの概念を分離し、考えを定式化しようとしました。 それでもどこかで単語の最初の部分を見逃して、単に「テスト」と書いた場合、UIテストを意味します。



素敵な読書を！

A / Bテストとは

それでは、まずA / Bテストの概念を決めましょう。 ウィキペディアからの引用です：



「A / Bテスト（A / Bテスト、スプリットテスト）はマーケティングリサーチの方法であり、その本質は、要素のコントロールグループが、1つ以上のインジケーターが変更されたテストグループのセットと比較されることです。どの変更がターゲットを改善するかを見つけるために” リンク 。



プロジェクトに関して言えば、A / Bテストの存在は、ユーザーごとに機能が異なることを意味します。 いくつかのオプションを強調します。

• この機能は、あるユーザーグループでは使用できますが、別のユーザーグループでは使用できません。
• この機能はすべてのユーザーが利用できますが、さまざまな方法で機能します。
• この機能はすべてのユーザーが使用でき、同じように機能しますが、外観が異なります。
• 前の3つのオプションの任意の組み合わせ。

このすべてのロジックが機能するために、 UserSplit Toolというツールが社内にあり、開発者のRinat Akhmadeevがこの記事で詳細に説明しました。



次に、A / Bテストの存在がテスト部門、特に自動化にとって意味することについて説明します。

UIテストカバレッジ

UIテストでのカバレッジについて話すとき、テストしたコードの行数について話しているのではありません。 これは理解できます。ページを開くだけでも多くのコンポーネントが関係する可能性があるため、まだ何もテストしていません。



テスト自動化の分野での長年の作業で、UIテストのカバレッジを測定する多くの方法を見てきました。 それらをすべてリストするのではなく、UIテストでカバーされる機能の数によってこのインジケーターを評価することを好むというだけです。 これは理想的な方法ではありません（私は個人的には理想的な方法を知りません）が、私たちの場合はうまくいきます。



そして、ここで記事のトピックに直接戻ります。 各機能が使用するユーザーに応じて異なる動作をする可能性がある場合、UIテストの適切なレベルのカバレッジを測定および維持するにはどうすればよいですか？

UIテストで最初に機能がカバーされた方法

UserSplit Toolが会社に登場し、A / Bテストが非常に多くなる前でさえ、UIテストで機能をカバーするための次の戦略を順守しました。



それは、以前は、機能が実稼働になったとき、しばらくの間「調整」されたままだったためです。動作と外観が変わる可能性があります。 また、彼女は自分自身を証明することもできず、ユーザーの目からすぐに姿を消しました。 不安定な機能のUIテストを作成するのは高価であり、実践していません。



開発プロセスにA / Bテストが導入されても、最初は何も変わっていません。 各A / Bテストには、いわゆる「コントロールグループ」、つまり機能のデフォルトの動作を確認するグループがありました。 UIテストが書かれたのは彼のことでした。 このような機能のUIテストを作成するときに行う必要があるのは、ユーザーをデフォルトの動作で有効にすることを忘れないことです。 このプロセスをA / Bグループの力（英語の力による）と呼びます。



私は物語の中で役割を果たし続けるので、私は力の詳細をさらに詳しく説明します。

A / BテストおよびQaAPIの強制

記事やレポートでQaAPIについて繰り返し語っています。 それにもかかわらず、奇妙なことに、これまでのところ、このツールに関する本格的な記事を書いていません。 おそらく、いつかこのギャップは埋められるでしょう。 それまでの間、私の同僚のDmitry Marushchenkoのスピーチのビデオを見ることができます。「4。QaAPIの概念：バリケードの反対側からのテストの様子 。」



簡単に言うと、QaAPIを使用すると、特別なバックドアを介してテストからアプリケーションサーバーにリクエストを送信し、データを操作できます。 たとえば、このツールを使用して、特定のテストケース用にユーザーを準備し、メッセージを送信し、写真をアップロードします。



同じQaAPIを使用して、A / Bテストグループを強制できます。 テストの名前と目的のグループの名前を示すだけです。 テスト呼び出しは次のようになります。

QaApi::forceSpliTest(“Test name”, “Test group name”, {USER_ID or DEVICE_ID});
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この力が働き始めるべきuser_idまたはdevice_idを指定する最後のパラメータ。 user_idパラメーターはまだないため、権限のないユーザーの場合はdevice_idパラメーターを指定します。 そうです、不正なページについては、A / Bテストもあります。



このQaAPIメソッドを呼び出した後、承認されたユーザーまたはデバイスの所有者は、私たちが偽造した機能のバージョンを見ることが保証されます。 これらは、A / Bテスト中の機能を対象としたUIテストで記述した課題です。



そして、私たちは長い間住んでいました。 UIテストは、A / Bテストのコントロールグループのみを対象としました。 その後、それほど多くはありませんでした、そしてそれは働いた。 しかし、時間が経ちました。 A / Bテストの数が増え始め、ほとんどすべての新機能がA / Bテストの下で実行され始めました。 機能の制御バージョンのみを対象とするアプローチは、私たちに適したものではなくなりました。 そして、ここに理由があります...

A / Bテストをカバーする理由

最初の問題はカバレッジです



上で書いたように、時間の経過とともに、ほとんどすべての新しい機能がA / Bテストの下で登場し始めました。 コントロールに加えて、各機能にはさらに1つ、2つ、または3つの他のオプションがあります。 このような機能の場合、最適な場合のカバレッジは50％を超えず、最悪の場合は約25％になります。 以前は、そのような機能がほとんどなかった場合、これは総カバレッジインジケータに大きな影響を与えませんでした。 今-それはレンダリングし始めました。



問題2-長いA / Bテスト



一部のA / Bテストには、かなり時間がかかります。 そして、私たちは1日に2回リリースされ続けています（これは、QAエンジニアのIlya Kudinovの記事「 1日2回のリリースで 4年間生き残る方法 」で読むことができます）。



したがって、この時間中にA / Bテストのバージョンの1つを破る確率は非常に高くなります。 そして、これは確かにユーザーエクスペリエンスに影響を与え、機能のA / Bテストの全ポイントを無効にします。結局、あるバージョンでは機能が悪い結果を示すことがあります。



A / Bテストの結果を確認したい場合は、どのバージョンの機能も、予想とは異なる動作をさせてはなりません。



3番目の問題は、UIテストの関連性です。



A / Bテストのリリースなどがあります。 これは、A / Bテストが十分な統計を収集し、製品マネージャーがすべてのユーザーに勝利のオプションを開く準備ができていることを意味します。 A / Bテストのリリースは、コードではなく、構成の構成に依存するため、コードのリリースと非同期に発生します。



非制御バリアントが勝ち、良くなったとします。 それだけをカバーしたUIテストはどうなりますか？ そうです：彼らは壊れます。 しかし、ビルドのリリースの1時間前に中断した場合はどうなりますか？ このビルドの回帰テストを実施できますか？ いや ご存知のように、テストが壊れていると、遠くまで行かないでしょう。



したがって、A / Bテストを事前に閉じて、UIテストのパフォーマンスを妨げないようにし、その結果、ビルドの次のリリースを妨げないようにする必要があります。



おわりに



前述の結論は明白です。すべてのオプションを使用して、UIテストでA / Bテストをカバーする必要があります。 論理的ですか？ はい！ ありがとう、発散！



...ジョーク！ それほど単純ではありません。

A / Bテストのインターフェース

不便だと思われた最初のことは、どのA / Bテストと機能が既にカバーされていて、まだカバーされていないかを制御することでした。 歴史的に、UIテストは次の原則に従って呼び出します。

• 機能またはページの名前。
• ケースの説明。
• テスト。

たとえば、ChatBlockedUserTest、RegistrationViaFacebookTestなどです。 ここでも、分割テストの名前を不快に思ったようです。 まず、名前が非常に長くなります。 第二に、A / Bテストの最後にテストの名前を変更する必要があり、これはUIテストの名前を考慮した統計の収集に悪影響を及ぼします。



QaAPIメソッドを常に呼び出すためにコードを取得するのは、まだ楽しみです。



そこで、UIテストのコードからQaApi :: forceSplitTest（）へのすべての呼び出しを削除し、MySQLテーブルのどこに力が必要かに関するデータを転送することにしました。 彼女のために、Selenium ManagerでUIプレゼンテーションを行いました（ ここで説明しました ）。



次のようになります。







表では、どのUIテストにどのA / Bテストの力を適用し、どのグループに適用するかを指定できます。 UIテスト自体、テストクラス、またはすべての名前を指定できます。



さらに、この力が許可されたユーザーまたは許可されていないユーザーに適用されるかどうかを示すことができます。



次に、起動時にUIテストを教えて、このテーブルからデータを取得し、実行中のテストまたはすべての（すべての）テストに直接関連するデータを強制します。



したがって、A / Bテストのすべての操作を1か所で収集することができました。 これで、カバーされたA / Bテストのリストが見やすくなりました。



そこで、新しいA / Bテストを追加するためのフォームを作成しました。







これにより、コミットを作成することなく、UIテストが実行されるすべてのクラウドに分解されるのを待つなどせずに、必要な力をすばやく簡単に追加および削除できます。

UIテストアーキテクチャ

私たちが注意を払うことに決めた2つ目のことは、A / Bテスト用のUIテストを書くためのアプローチの改訂です。



簡単に言えば、通常のUIテストの作成方法を説明します。 アーキテクチャは非常にシンプルで使い慣れています。

• テストクラス-対象となる機能のビジネスロジックがそこに記述されています（実際、これらはテストのスクリプトです：これをやった、これを見た）。
• PageObjectクラス-UIおよびロケーターとのすべての相互作用について説明します。
• TestCaseクラス-UIに直接関係しない一般的なメソッドがありますが、いくつかのテストクラスで有用です（たとえば、QaAPIとの相互作用）。
• コアクラス-通常のテストを作成する際に、セッションを上げる、ログを記録するなど、触れる必要のないロジックがあります。

一般に、このアーキテクチャは完全に私たちに合っています。 UIが変更された場合、PageObjectクラスのみを変更する必要があります（テスト自体は影響を受けません）。 機能のビジネスロジックが変更された場合、シナリオを変更します。



前回の記事で書いたように、誰もがUIテスト（手動テスト部門と開発者の両方）で作業します。 このプロセスが単純で理解しやすいほど、それらに直接関係のない人がテストを実行する頻度が高くなります。



しかし、私が上で書いたように、十分に確立された機能とは異なり、A / Bテストは出入りします。 通常のUIテストと同じ形式で記述した場合、A / Bテストの完了後、多くの異なる場所からコードを永久に削除する必要があります。 リファクタリングのために、特にそれなしですべてが機能する場合、時間を割り当てることが常に可能であるとは限りません。



それにもかかわらず、未使用のメソッドとロケーターでクラスを成長させる気はありません;これにより、同じPageObjectsを使用するのが難しくなります。 あなたの人生を楽にする方法は？



その後、PhpStormが私たちを救いに来ました（便利なIDEを提供してくれたJetBrainsの方々に感謝します） 。つまり、この機能です 。



つまり、特別なタグを使用して、コードをいわゆるリージョンに分割できます。 私たちは試しました-そして私たちはそれが好きでした。 1つのファイルでアクティブなA / Bテスト用の一時的なUIテストの作成を開始し、コードゾーンを、このコードを将来配置するクラスを示す領域に分割しました。



その結果、テストコードは次のようになりました。







各領域には、特定のクラスに属するコードがあります。 確かに他のIDEにも似たようなものがあります。



したがって、A / Bテストのすべてのバリアントを1つのテストクラスでカバーし、PageObjectメソッドとロケーターの両方をそこに配置しました。 そして、その完了後、最初にクラスから失われたオプションを削除し、その後、リージョンに示されている内容に従って残りのコードを簡単に目的のクラスに配布しました。

A / Bテストを閉じる方法

すべてのA / Bテストを一度にUIテストでカバーしてカバーすることはできません。 一方、そのようなタスクはありません。 自動化の観点からの課題は、重要で長時間実行されるテストのみを迅速にカバーすることです。



それにもかかわらず、最小のA / Bテストでもリリースする前に、勝利バージョンですべてのUIテストを実行し、すべてが正常に機能することを確認し、100％のユーザーのために高品質の作業機能を複製したいと思います。



MySQLテーブルを使用した上記のソリューションは、この目的には適していません。 実際、そこに力を加えると、すべてのUIテストですぐに有効になります。 ステージング（テストのフルセットを実行する運用前環境）に加えて、これは個々のタスクのブランチに対して起動されるUIテストにも影響します。 手動テスト部門の同僚は、これらのリリースの結果を処理します。 また、失敗したA / Bテストにバグがある場合、タスクのテストもドロップされ、問題はA / Bテストではなくタスクにあると判断できます。 このため、テストと試用には時間がかかることがあります（誰も満足しません）。



これまで最小限の変更で管理しており、ターゲット環境をテーブルに指定する機能を追加しました。







この環境は、既存のレコードでオンザフライで変更できます。 したがって、個々のタスクのテストに合格した結果に影響を与えることなく、ステージングにのみ力を加えることができます。

まとめると

そのため、このストーリーを開始する前に、UIテストはA / Bテストのメイン（コントロール）グループのみを対象としていました。 しかし、私たちはもっと欲しいと思い、A / Bテストの他のバージョンもカバーする必要があるという結論に達しました。



要約すると：

• A / Bテストのカバレッジを簡単に制御するためのインターフェイスを作成しました。 その結果、A / Bテストを使用したUIテストの操作に関するすべての情報が得られました。
  
  
• 一時的なUIテストを、パーマネントのランクへのさらなる削除または転送のためのシンプルで効果的なフローで記述する方法を開発しました。
  
  
• 他の実行中のUIテストに干渉したり、Gitで不必要にコミットしたりすることなく、A / Bテストのリリースを簡単かつ簡単にテストする方法を学びました。
  
  

これらすべてにより、テストの自動化を絶えず変化する機能に適合させ、カバレッジのレベルを簡単に制御および向上させることができ、レガシーコードで大きくなることはありません。



混controlledとした状況を一見管理された秩序にもたらし、自分自身や同僚の生活を簡素化した経験はありますか？ コメントで共有してください。 :)



ご清聴ありがとうございました！ そして明けましておめでとうございます！