マジックテスター 訓練されていない人が間違いに気付く方法、および同じロボットを教える方法

こんにちは 私の名前はイリヤ・カツエフです。私はヤンデックスの試験部門の小さな研究ユニットを代表しています。 実験プロジェクトRobotester-テスターの日常業務の大部分を実行できるロボットについては、すでにお読みいただけました。



私たちの主な目標は、Yandexでエラーを見つけるための根本的に新しいアプローチを考案することです。 私は、将来の仕事のどれだけがロボットの肩にかかるかについて推測するのが本当に好きです。 彼らはすでに素晴らしいスポーツレポートを書いて 、兵士のために荷物を運びます 。 一般に、人間の進歩はロボットに移せる仕事の量に直接依存しているように思えます。この場合、人々は自由時間を持ち、クールな新しいものを思いつきます。





私が個人的に支持しているこのような論文があります-準備のできていないユーザーが気付くことができるロボットは、ロボットによって検出されます。 それが私たちが検証しようとしたものです。 しかし、ここで疑問が生じます：人は間違いを正確に何と見なしますか？



人工知能はまだ誰も発明していませんが（たとえば、ホーキングはこれがより良いことだと信じていますが）、いくつかの成功を収めることができました。 この投稿では、人間のテスターが持っている経験をどのように定式化し、ロボットを教えようとしたか、そしてその結果についてお話します。

ロボテスター 最初のアプローチ

Robotesterを作成したとき、テスターの時間を要するルーチン作業を自動化するタスクに直面しました。 Webページを開き、要素を使用して実行できるアクションを理解し、テキストフィールドに入力し、ボタンを押して、エラーがいつ発生したかを推測するアルゴリズムを教えました。 しかし、問題がありました-高い信頼性で、ロボットは最も些細なエラーしか検出できないことが判明しました。



事実、ロボットの動作原理（可能な限り多くのページをチェックする）が多数のテストにつながったため、エラーを判断する精度が重要な要素になりました。 Yandex.Marketをチェックするために、ロボットは1日あたり800,000の異なるチェックを行うと計算しました。 したがって、チェックの誤検知率が平均0.001（小さい数字のようです）である場合、毎日、実際にはそうではない800のエラーが検出されたという報告が届きます。 当然、これは誰にも合いません。



「偽の」エラーメッセージが常に発生することに注意してください。 特にWebテストに関しては、補助ツールを使用するため、ロボットを使用するブラウザに問題がある場合や、インターネットに問題がある場合などがあります。



非常に「きれいな」チェックがあります。 たとえば、404リンク応答コードは、問題があることを示す可能性が非常に高いです。 低精度のチェックの例は、テキスト（スペースとコンマ）に文字の組み合わせ「、」が存在することです。 実際、スペースとコンマの間にデータがロードされていない場合、そのような文字の組み合わせはエラーを示します。 しかし、時々それはちょうどタイプミスです。 特に、ユーザーのコメントのテキストまたは外部ソースからのコンテンツが検証領域に入る場合。 したがって、これらのエラーを見つけるには、「実際の」問題と「誤った」問題を分離して、手動で作業を行う必要があります。



その結果、ロボットはテスターの作業の一部を完全に引き継ぎました（たとえば、すべての壊れたリンクを見つけました）。 そして、「ロボットに知能を追加する」方法を考えました。

ロボットはどのようにエラーを推測しますか？

従来、テストでは、テスト中のプログラムは特定の入力データで実行され、結果は以前に設定された何らかの「正しい」結果と比較されます。 手動で設定することも、プログラムの以前のバージョンを起動したときに保存することもできます（このバージョンと以前のバージョンとのすべての違いを見つけることができます）が、一般的な原則は変わりません。 実際、アプローチは全体として何十年も変わらず、これらのテストを実装するためのツールのみが変化しています。

ただし、間違いの原因を特定するために根本的に異なるアプローチが可能であることがわかります。



最初に、ロボットは、このサービスのプロのテスターであるとは限らず、人が犯す可能性のあるエラーを識別するために学習する必要があるという事実について話しました。



このページのエラーはどこにありますか？







もちろん、正しい答えは、以下の5つの文の中に重複した文があるということです。 これが間違いであることを理解するには、マーケットの専門家である必要はありません-最低限の常識を持っている必要があります。



別の例。







ここでは、ある場所では「非売品」と表示され、別の場所では価格が表示されます。 繰り返しますが、これは間違った状況であることを誰もが完全に理解しています。



別の例。







これは単なる空白のページです。 つまり、彼女には標準の「ヘッダー」と「フッター」がありますが、中央にはコンテンツがありません。



ここで重要な質問が発生します-これは間違いだと人はどのように理解しますか？ これはどのメカニズムに基づいていますか？



長い間考えていましたが、ここでのキーワードは経験です。 つまり、ある人はすでに自分の人生で多くのWebページを見てきましたが、その一部はまったく同じタイプのものでした。 そして、彼が特定のパターンを形成したのは彼らからでした。 このテンプレートは、非常に一般的なもの（「ページを空白にしない」、「すべての検索結果を異なるものにする」）、または逆にこれらのページに結び付ける（「選択した2つのブロックに同時に数字を含める、または含めない」）ことができます。 つまり、これらの規則はすでに彼の頭の中で形成されており、これらの例からわかるように、それらは完全に単純なように見えます。



したがって、ここでのさらなるタスクが明らかになりました-多くの類似またはあまり類似していないWebページを分析して、これらのルールを自動的に抽出する方法を学ぶ必要があります。



定式化されたルールは非常に単純であり、それらを自動的に抽出する方法を学習すれば、人間の介入なしで自動テストを形成することが可能です。 たとえば、Yandexサービスの多くのページを分析するためにロボットが提供され、すべての下部に「会社について」というリンクがあることがわかります。 したがって、この事実はルールとして定式化され、ロボットはサービスの新しいバージョンまたは別のサービスの実装をチェックします。



このアイデアの最も簡単なアプリケーションは次のとおりです。本番環境のサービスのすべてのページを分析し、そのような「ルール」を分離し、同じサービスの新しいバージョンに対して実行されるかどうかを確認します。



このアプローチは、すべての人に長い間知られています。 これは連続テストと呼ばれ、それを使用する人がいます。 ただし、この方法は、サービスがバージョンから顕著に変更されない場合にのみ適用できます。



昨日と今日の検索結果を見てみましょう。検索結果と広告は次に変わります。 最終的には、ユーザーの地域、好み、時刻に依存します。 したがって、直接比較すると、「ごみ」が多すぎます（状況によっては、このような直接的な方法が許容されることに注意してください）。



ここでは、アイデアを開発し、ゴミの「クリア」された比較を実行します。ページ自体を比較するのではなく、ページの「モデル」を比較します。

ブロック

一般的なアイデアを定式化したので、次にそれを実装する方法に移りましょう。 私たちのタスクは、ルールを自動的に抽出することです。 人間の理解のために、それらは非常に簡単です。 それらを「ブロック」の言語で定式化します-ページの特定の部分に要素が含まれるかどうか、特定のブロックがページに存在するかどうかなどについて話します。 個人の場合、ページは自然な方法でそれらに分割されます-ここに承認フォームがあり、ここに検索フォームがあります（そしてサブブロックは検索バー、「検索」ボタンです）。 ただし、ロボットはその前のhtmlコードを「見る」ため、このコードのどの部分がブロックを形成するかは完全にはわかりません。



ブロックの概念を明確に明確にすることにしました。 つまり、最初に私たちは人間がブロックと呼ぶものを自分自身で理解することに決めました。 ブロックが何であるか見てみましょう。



1.永久。 ブロック全体がすべてのページに存在します）。















2.変更。 タグはすべてのページに存在しますが、すべてが変化するたびにタグ内に存在します。















3. 1ページに均一なブロック。







4.同じタイプですが、本質的に同じページ上の異なるブロック。







さらに、異なるページでは、同じブロックが異なる場所に立つことができます。















つまり、私たちにとって、「ブロック」はページの特定の部分であり、変更されても、ほぼ一定のままです。 たとえば、段落2のフォーム（上記参照）が「同じオレンジの形」の特殊なケースであることは簡単に理解できますが、フォームの内容は変わります。



別の問題は、連続するいくつかの類似したブロックで表されます。 時には「同じタイプのいくつかのブロック」である場合もあれば、異なるタイプのオブジェクトのセットである場合もあり、一般的にどのタイプのオブジェクトがあるのか​​を理解したいと思います。



まず、各ページですでに選択されているブロックをマークする方法が必要です。 従来のxpath（たとえば、 /html/body/div[1]/table[2]/tbody/tr/td[2]/div[2]/ul/li[3]/span/a



）は適切ではありません。その中の数字は変化する可能性があります-同じブロックが3番目または5番目の行になる可能性があります。 他のブロックの種類に応じて（最後の2つの例を参照）。



したがって、最初にxpathから番号を削除します（get /html/body/div/table/tbody/tr/td/div/ul/li/span/a



代わりに/html/body/div[1]/table[2]/tbody/tr/td[2]/div[2]/ul/li[3]/span/a



）そして、より安定したマッチオプションを取得します（つまり、このブロックはどのページでもxpathに該当します） -もちろん、複数の要素が同じxpathに対応できるようになりました。 この不正確さを減らすために、属性の一部の値を各タグの説明に追加します。 手で属性を多かれ少なかれ安定したものに分割しました。 たとえば、id属性は、ページが読み込まれたときに新たに生成されることがよくあります。つまり、まったく情報がありません。 たとえば、上記で検討したブロックの場合、次の説明が取得されます。別のipath

 <body> <div class="b-max-width"> <table class="l-head"> <tbody> <tr> <td class="l-headc"> <div class="b-head-search" onclick="return {name:'b-head-search'}"> <div class="b-head-searchwrap b-head-searcharrow"> <form class="b-search"> <table class="b-searchtable"> <tbody> <tr> <td class="b-searchinput"> <span class="b-form-input b-form-input_is-bem_yes b-form-input_size_16 i-bem" onclick="return {'b-form-input':{name:'b-form-input'}}"> <span class="b-form-inputbox"> <text src="  Turion II">
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、ブロックを探しましょう。 htmlコードをtreeとして表す場合、タスクはルート頂点から安定したパスを探すことです（ここでの安定性は、ページが変わってもパスはほとんど変わらないことを意味します）。 このような多くの安定したパスを構築するアルゴリズムは、ツールの主要部分です。 「試行錯誤によって」構築しました。 つまり、アルゴリズムを変更し、結果を確認しました。 以下でアルゴリズムを説明しますが、今のところ完全に予期しない問題についてお話します-ページ上で目立つブロックをどのように表現するかわからないことに突然気付きました。



確かに-ブロックはページによって異なります。 ページをブロックに分割したように見えるものの形でレポートを取得したかったのです。 しかし、どのブロックオプションを取るべきでしょうか？ 何度も何度も、レポートに空または情報価値のないバージョンが登場するケースに遭遇しました。 同じページにすべてのオプションを何らかの形でコンパクトに表示する必要がありました。 開発者の1人が良いアイデアを思いつきました-たとえば、 Coubサービスのポルノサイトで行うように ：ビデオにマウスを合わせると 、そこからフレームが変化します。 まったく同じことをしました-ブロックの上にマウスを移動すると、このブロックは「点滅」し始め、異なるページでどのように見えるかを示します。 それは非常に便利であることが判明しました。



その結果、「ページモデル」は次のようになります（以下を参照）。 それを見て、どのブロックが目立っているかをすぐに理解できます。

ブロック割り当てアルゴリズム

次に、アルゴリズムについて。 基本的なアルゴリズムは次のとおりです。

1. セットから1ページを選択します。
2. 最初のページから、ルート頂点から他の頂点までのすべての最大パスを収集します。
3. 次に、選択したパスごとに、すべてのページに配置しようとします。
   
   パスの一部を配置でき、長さが少なくとも4異なる場合は、この部分を多くのパスに追加します。
   
   ほぼ最後まで進んだ場合（1〜3タグに到達しなかった場合）、セットのパスをこの切り刻まれたバージョンに置き換えます。
4. その結果、結果のパスはブロックに対応します。 さらに、すべてのページにあるもの、またはページの95％などを選択するのは簡単です。

このアルゴリズムの大きな利点は、最初のページの要素数とページ数の両方に線形に依存することです。



しかし、すぐにわかったように、アルゴリズムがうまく機能しない場所があります。 たとえば、これらのブロック（isbn、authorなど）の場合：







html要素はまったく同じであるため、シリアル番号のみが異なります。 しかし、この数字が何の意味も持たないことはすぐに明らかになります。上記の例では、ISBNは2番目または1番目のいずれかです。 したがって、このような要素を区別する唯一の方法は、内部のテキストを使用することであることが明らかになりました。 そのため、アルゴリズムを次のように変更しました。最初に、テキストのみが異なる複数の子孫が要素にある場所を探しています。 次に、すべてのページから同様の子孫要素を収集し、各ページが各クラスターの代表を1つだけ持つように、テキスト全体でそれらをクラスター化します。



アルゴリズムには他にも改善がありましたが、Yandexの仕様に関連しているため、あまり興味を引くものではないかもしれません。 ここで説明するアルゴリズムでさえ、ほとんどのページセットで非常にうまく機能します。

ルール生成

そのため、トレーニングセットからページの構造を分析し、ブロックを選択し、どのブロックが何ページに存在するかを理解したら、次のタイプのルールを定式化できます。

• ブロックAはページに存在する必要があります。
• ブロックAとBは同時に存在する必要があります。
• ブロックAとBは同時に存在できません。

原則として、より複雑なパターンを抽出することは可能ですが、これについてはまだ対処していません。



どのブロックに対して、最初のタイプの条件を形成しますか？ かなりの割合のページで見つかったもの。 この割合は、信頼レベルと呼ばれる特別なパラメーターによって決定されます。 このパラメーターを単一に設定するのは間違っています-最初にやりたかった方法です。これには2つの理由があります。

1. トレーニングサンプルの100ページの1つが（タイムアウトなどにより）開かない場合があり、その結果、ブロックの必須の存在に関する条件は強調表示されません。
2. トレーニングセットのページの中で、誤ってエラーのあるページに遭遇しました。

この重要性のレベルは、機器をトレーニングする環境の安定性に応じて異なります。 パラメーター値を小さくすると、環境の不安定性の影響を「除去」できます。 ただし、このパラメーターを大幅に減らすと、ツールは不規則なパターンをさらに強調表示し始めます。 たとえば、商品の96％に価格があり、4％が「非売品」と表示されている場合、パラメーターを0.95に設定すると、「非売品」のページはエラーとしてマークされます。 デフォルトでは、信頼レベルは0.997です。



ブロックの有無の条件に加えて、各ブロック内のテキストの条件を自動的に生成します。 条件は、正規表現の形式で形成されます。 たとえば、そのようなページに発行年があるブロック







次のレギュラーシーズンがあります。

発行年：[0-9] {4}

またはこれでさえ：

発行年：（19 | 20）[0-9] {2}



同時に、このブロック自体はオプションとしてマークされます。 つまり、次のことが確認されます。そのようなブロックがある場合、「出版年」という語の後に4桁または4桁が書き込まれます。最初の2つは19または20です。人はそのようなテストについて書きます。

実際の魔法

要約すると、このツールは次のことを実行できます。一連のページに対して、これらの同じページの特定の割合で実行される特定のタイプのルールを抽出します。 これを使用してバグを探す方法は？ 2つの方法があります。

1. 十分にまれな動作を考慮するのは間違いです。 これは物議を醸す論文ですが、多くの場合、この方法で機能的なバグを見つけることができました。 次に、サービス上の多数のページを分析し、他のページと類似していないページをマークするだけで十分です。 いずれにしても、「すべてが壊れた」と言えば、このパスは機能しません。 したがって、通常は別のアプローチを使用します。
2. サービスのバージョンNから（通常は本番環境からのみ）ページを収集し、それらのルールを作成します。 次に、サービスのN + 1バージョンから多くのページを取得し（通常はテストのみ）、これらのルールへの準拠をチェックします。 バージョンNとN + 1のすべての違いの理解可能なリストが取得されます。

実際、2番目のケースでは、回帰自動テストが存在する場合と同じ結果が得られます。 ただし、この場合、大きな、さらには非常に大きな利点があります。これらのテストのコードを作成および保守する必要はありません！ サービスの新しいバージョンが投稿されるとすぐに、「すべてを再構築」ボタンをクリックすると、数分後に「自動テスト」の新しいバージョンが準備できます。



実装実験として、 トルコ語版のMarketを起動するときにこのアプローチを使用しました。 テストの専門家は、必要なケースのリストと、どのページで何をチェックするかを作成しました。 サービスの多くのページをクロールし、それらを検索結果ページ、カテゴリページなどのグループに分割しました。 さらに、ページの各グループに対して、上記のルールが自動的に構築され、示されたチェックのどれが実際に実行されるかが手動でチェックされました。 チェックの約90％が自動的に生成されたことが判明しました。 同時に、自動テストの作成に予想される人件費は約3週間でしたが、私たちのツールはすべてを1日で実行して構成することができました。



もちろん、これはどんなテストでも何倍も速く形成できるという意味ではありません。 たとえば、これまでのツールでは、静的テストのみを自動的に作成できます（ページ要素を使用した動的操作は行われません）。



現在、このツールが実行する人間の作業のどの部分に関する質問に対する正確な答えを得るために、さまざまなYandexサービスでMTを実装するのに忙しくしています。 しかし、それはすでにかなり明らかです。



私が言ったように、RobotesterおよびMagic Testerプロジェクトは実験的であり、テスト部門の研究ユニットで行われています。 あなたが学部生で、私たちの仕事に挑戦することに興味があるなら、インターンシップに来てください。