レスポンシブデザインを使用したニュースサイトのレイアウトのテスト

EastBanc Technologies QA部門がこれまでに直面した最も注目すべき課題の1つは、サイトwww.washingtonpost.comの自動テストシステムの作成です。 これは、情報およびニュースポータルの形式で実装される電子新聞です。



自動テストシステムを作成する必要がある主な理由は、アプリケーションが新しいCMS（いわゆるPageBuilder）に切り替えることを計画していたためです。 この種の移行では、さまざまなページで新しいCMSを通じて公開されたコンテンツが適切に見えるように、ミスをしないことが非常に重要です。



すべてのページがテストに準拠しているかどうかを確認する作業はありません。 私たちのタスクは、PageBuilderのバグを特定し、焼きたてのPageBuilderによって作成されたページのレイアウトの信頼性を確認し、特定のページをページ表示の潜在的な問題につながる可能性のあるコンテンツで埋めるというニュアンスにWashingtonpostエディターの注意を引き付けることです。

テストシステムの作成は活発に開発されていますが、私たちの意見では、いくつかの興味深い点がすでに一般に公開されています。



これを行う前に、プロジェクトの1つの機能に注意する必要があります。すべてのテストは「外部」で行われます。 つまり 私たちは、他のユーザーと同様に、テスト用に戦闘バージョンのサイトを使用します。

レイアウトテストツールの選択

インターネットを探索した後、次のアプローチとツールに決めました。 ページフレームをテストするために、後でtestNGと統合したGalenフレームワークを採用しました。



当然、ページフレームのガレンテストに合格しても、レイアウトの有効性を意味するわけではありません。 ブロックの場所に加えて、ブロック内のさまざまな要素の表示も確認する必要があります。 スクリーンショットを比較して、ブロックの内部コンテンツをテストすることにしました。

さまざまなロゴ、ボタン、特定のディスプレイを備えた一部のブロックは、スクリーンショットテストに翻弄されます。Galenが到達できず、機能テストで検証することが困難/不可能であるすべてです。



Azure-Galenによってテストされ、緑色であふれている-スクリーンショットテスト：



ご注意 全体像





ガレンとスクリーンショットのテストは、いくつかの機能テストを正常に置き換えることができ、同時に視覚化、速度、そして両方で勝利することができます。 特定のケースのテスト方法の選択は、パフォーマンス基準、サポートの容易さ、テスト範囲の完全性、および可視性に基づいて、ページの種類ごとにテストケースをまとめて議論することにより行われます。



たとえば、最初に機能テストを記述した検証用ブロックには、Most ReadブロックとInformation Blockの2つがあります。 今度は、スクリーンショットで最初をチェックし、ガレンテストで2番目をチェックします。



MostReadブロック、スクリーンショットテストによる検証：





機能テストに関して：コードの行がはるかに小さくなり、テストカバレッジの完全性が向上し、ページ上のこのブロックの外観を変更するときにテストを更新するのにそれほど時間はかかりません。



このブロックのテストは、スクリーンショット方式の章で検討されています。



WaPo情報ブロック：





Galenはこのブロックのテキストとリンクの対応を問題なくチェックします。リンク自体はロケーターで指定され、テキストと内部ガレンチェックとの対応は確認されます。 機能テストに関しては、テスト範囲の完全性は変更されていませんが、テストが単一のテストの一部として実行されるという事実により、時間を大幅に節約できます。



ガレノステストコード 。



当社の自動テストシステムは、Java、Maven、TestNG、 Selenium WebDriver 、Selenium Grid、 Galen Frameworkを使用しています。



スクリーンショットベースのテストを作成する際に、 ImageMagickユーティリティのクロスプラットフォームセットが積極的に役立ちます。



PageObjectパターンとYandex- HTML Elementsのフレームワークを使用してJavaでテストコードを記述していることにすぐに注目します 。 テストを実行するには、mavenとtestNGが使用されます。



テストの立ち上げを容易にするため、テストの立ち上げの履歴を表示し、高度な資格を持つ専門家が関与することなくレポートを表示するために、別のアプリケーション-ダッシュボードを開発しています。



現在、テストプロセス全体を適切に整理する方法についてはまだ研究段階にあり、すべてのアプローチが完全にマスターされ、研究されているわけではないことを強調しておくと役立ちます。

Galen Frameworkを使用したテスト

Galen Frameworkには多くの否定できない利点があります。レスポンシブデザインのための広範なテスト機能を備えた、柔軟で使いやすいツールです。 さらに、十分に文書化されており、現在積極的に開発中です。



Galen Frameworkは、すでに記事の 1つで十分詳細に説明されています。 Galenでの作業の原則を簡単に説明すると、次のようになります。特別に文書化された直感的な構文を使用してページ仕様（いわゆるspecファイル）を記述します。 仕様ファイルには、ページ要素の相対的な位置、サイズ、インデント、ネスト、およびページレイアウトが準拠すべきその他のパラメーターと条件が記述されており、要素内のテキストの対応を確認することもできます。 そして、これらのチェックはすべて、指定したタグに応じて適用されます。



specファイルのタグは次のように指定できます。











Galenはすべてのチェックを実行してから、htmlファイルの形式で視覚的なレポートを生成します。 レポートには、このテストで失敗した特定のチェックが示され、失敗した各チェックについて、特定のテストに合格しなかった要素が強調表示されるテスト済みページの完全なスクリーンショットを見ることができます。

たとえば、隣接する要素間の距離のテストに失敗すると、レポートでは次のようになります。







赤で強調表示されたチェックをクリックすると、チェックされたページ全体のスクリーンショットが表示され、そのような要素が強調表示されます。







Galen Frameworkは、次のパラメーターを入力として受け入れます。

• チェックが行われるブラウザ
• テストを実行する許可
• テストされたページのURL
• .specファイルのチェックを開始する前に、起動したページに適用する必要がある（必要な場合）JavaScriptファイル（たとえば、サイトにログオンしているユーザーへのページ表示を確認する必要がある場合）
• 起動された.specファイルの名前
• .specファイルのチェックに適用する必要があるタグ（たとえば、デスクトップ、Destopのレイアウトをテストする場合はall）。

ご覧のとおり、Galenに提供されるパラメーターを変更することで、サイトのフレームワークのほぼ完全なテストカバレッジを達成できます。



サイトワイヤフレームテストツールを決定したら、次のタスクは、Galenテストでページの最大カバレッジを提供できるスキームを選択することでした。

同じタイプのページのサブセットからテストページを選択する

テストが同じタイプのページの多くをチェックするように設計されている場合、レイアウトをテストするために選択するページはどれですか？



特に気にすることなく、テストスイートを実行するたびにサブセットからランダムページを選択することにしました（つまり、レシピページのサブセットをテストするために、レシピの1つを選択し、そのURLをすべてのレイアウトテストに渡します）。 したがって、タスクのすべてのページをチェックする価値がないため、ランダムページを選択するオプションが最適であるように見えました。 チェックされたページのサブセットのランダムページのURLは、自動サイトテストシステム内のすべてのテストに共通の方法でGalenに送信されます（組版テストを除き、機能テストとスクリーンショットテストもあります）。



たとえば、同じタイプのページを表示するための2つのオプションがあります-レシピのページで、そのうちの1つにエラーが含まれています：







この例は、ページの右側の列に配置する必要がある「Most Read」ブロックが、メインページの左側ではなく右側にあることを示しています。 この種の問題がないことを確認するには、多数のページを確認し、多くの要因を考慮する必要があります。

どの権限でテストを実行しますか？

最初に、最も一般的なデバイスを選択し、その解像度を使用してテストを実行するというアイデアが生まれました。 しかし、惑星の加速された動員の明確に追跡された傾向は、私たちがこの分野の無条件の指導者を選抜する（そしてさらに予測する）ことを許しません。 Webアプリケーションを表示できるデバイスはたくさんありますが、最近ではそのようなデバイスに対する権限の統一は絶対に流行していません。 突然のクリーピングは、任意の有効な解像度で正しく表示するためにアダプティブデザインがアダプティブであると考え、私たちの心を救い、この分野のさらなる研究を妨げました。 決定が下されました。すべての有効な解像度でレイアウトをテストしています。



有効なアクセス許可には、最小ビューポート幅= 241ピクセル（ブラウザーが減少することはありません）から最大ビューポート幅= 1920ピクセル（上限は単純な自発的な努力）までのすべてのアクセス許可が割り当てられました。 自動テストのためのビューポートの高さが決定パラメータであるページはまだないため、これまでのところ高さに注意を払いません。



すべての解像度でレイアウトをテストする方法は？



まず、有効な権限の範囲全体が異なるレイアウトの範囲に分割されました。 レイアウト自体は「ゴム」ですが、ブロックの配置が異なるため、区別することができます。 レイアウトの境界を決定することは難しくありません。ブラウザの隅でドラッグし、ページブロックがどの境界点で変化するかを調べます：相対的な位置、数、および/または動作。 簡略化するために、ビューポートの幅のみを考慮します。 次の表が判明しました。



デスクトップ：最大1920ピクセル、最小1018ピクセル。

ラップトップ：最大1017px、最小769px。

タブレット：最大768ピクセル、最小481ピクセル。

モバイル：最大480ピクセル、最小361ピクセル。

SMALL_MOBILE：最大360ピクセル、最小280ピクセル。



ちなみに、このような解像度のデバイスでWashington Postを表示するユーザーの数は悲惨なほど少ないため、SMALL_MOBILEレイアウトをテストしないことにしました（推測的な結論であり、さらにテストを追加しても問題ありません）。 異なる組版で4つの範囲をテストするために残ります。



以下は、デスクトップのアクセス許可についてGalenテストを実行するコードです。





各テストの開始時に、Galenには、指定されたレイアウトの範囲からランダムな許可が与えられます（getRandomResolution（DESKTOP））：

 protected Dimension getRandomResolution(Dimension[] d) { return getRandomDimensionBetween(d[0], d[1]); } private Dimension getRandomDimensionBetween(Dimension d1, Dimension d2) { double k = Math.random(); int width = (int) (k * (Math.abs(d1.getWidth() - d2.getWidth()) + 1) + Math.min(d1.getWidth(), d2.getWidth())); int height = (int) (k * (Math.abs(d1.getHeight() - d2.getHeight()) + 1) + Math.min(d1.getHeight(), d2.getHeight())); return new Dimension(width, height); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして実際、許可の範囲は次の形式で設定されます。

 public static final Dimension[] DESKTOP = {new Dimension(1920, 1080), new Dimension(1018, 1080)};
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、有効な範囲から解像度をランダムに選択し、同じタイプのページのサブセットからテスト済みのページを選択することにより、確率的なプロセスになります。 起動すればするほど、さまざまなバグが見つかります。 テストに1回合格すると、この特定の解像度のこの特定のページが有効であるとしか言えません。 しかし、500回の実行が成功した後、レイアウトの大部分は実行可能であると主張できます。 「500件の成功」が投機的な評価であるという予約をすぐに行います。ここでは、コンテンツと同等のページ数を確認する必要があります。



ランダム解像度で実行するとすぐに成果が上がり、固定解像度でテストを実行したときに見逃していたと思われる興味深いバグがすぐに明らかになりました。



レシピページをテストする例で、このアプローチがどのように役立つかを検討してください。



レシピページのワイヤフレームテストは、768px〜1017pxの解像度範囲（ビューポート幅）で実行されます。 たとえば、次のページをご覧ください： www.washingtonpost.com/pb/recipes/maple-banana-frozen-yogurt/14143



Laptop layout'a（1017pxおよび768px）のベンチマークテストではエラーは発生しませんでした。



ただし、ランダムな解像度でテストを実行し始めた後、約半分のケースでテストが失敗し、スクリーンショットでは、右の列のブロックがメインコンテンツの下に忍び込んでいることが示されました。



正しい見解：



ご注意 全体像





壊れたレイアウト：



ご注意 全体像

スクリーンショットベースのテスト方法

記事に触発されて、スクリーンショットベースのテスト方法を使用することにしました。 ところで、レイアウトをテストするために、最初はこのメソッドに依存していました。 つまり ページのフルサイズのスクリーンショットを事前に準備されたモデルと比較し、潜在的に変化するすべての要素をスタブに置き換えるという考えがありました（事前に選択された任意の画像がスタブとして取得されます）。 これらの要素には、写真、フラッシュ広告、テキストが含まれます。 このアイデアは主に、ページに動的にロードされる多くのブロックが含まれていたため、スクリーンショットの物理的寸法とブロックの場所がテストの実行から実行に変更されたために失敗しました。 また、Chromeはフルサイズのスクリーンショットを撮る機能をしばらく失い、これも多くの問題を引き起こしました。



スクリーンショットベースのテストは、表示が重要なページ上の個々の要素とブロックをチェックするようになりました。機能テストまたはガレンテストを使用したチェックは困難または不可能です。



例：



washingtonpost.comのメインページ（左）のMostReadブロックと、このブロックのスクリーンショットを比較するモデル（右）です。







テストコードは次のようになります。

 @Test(groups = { "ScreenshotBased" }) @WebTest("Verifies that 'Post Most' block is displayed properly") public void testMakeupForPostMost() { HomePage page = new HomePage().open(); page.preparePostMostForScreenshot(); screenshotHelper.shootAndVerify(page, page.thePostMost, "_thePostMost"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スクリーンショットの保存には、次のディレクトリ構造が使用されます。/models/HomePage/firefox/HomePage_thePostMost.png



ここからわかるように、さまざまなブラウザーについて、必要なブロックのモデルスクリーンショットが取得されます。



shootAndVerify（）メソッドは、送信されたページのクラスとテストが実行されているブラウザーの名前によってモデルへのパスを検索します。



先に見てみましょう-それは非常にうまく機能します、そして、すべてがまだ完全にデバッグされていないという警告でプロセスのいくつかの詳細を説明します。



判明したように、必要なブロックの写真は、次のような多くの要因に依存する可能性があります。

• オペレーティングシステムのバージョン
• オペレーティングシステムのテーマ
• ブラウザとそのバージョン
• さまざまなフォントスムージングオプションとハードウェアアクセラレーション。

最初の問題は、撮影されたスクリーンショットのサイズがOSとブラウザの設定によって異なることでした。 ブロックのサイズ、および結果としてスクリーンショットを同じにするには、一定のサイズでブラウザーを実行する必要があります。 適切なWebドライバーメソッドを使用して、ブラウザーウィンドウのサイズを変更できます：driver.manage（）。Window（）。SetSize（requiredSize）。 ただし、この方法で、必要な表示領域（ビューポート）のサイズではなく、ウィンドウのサイズを設定します。 ちなみに、垂直スクロールバーはビューポートのサイズにも影響し、その太さもウィンドウのテーマに依存するため、これを考慮する必要があります。 問題の解決策は、指定された寸法にビューポートのサイズを調整するキャリブレーション方法でした。 最初のテストを開始した後、ウィンドウサイズの幅とビューポートの幅の差は特別なパラメーターに保存され、以降の起動時に再利用されます。



私たちが遭遇した2番目の問題は、アンチエイリアシングオプションによるブラウザーでのフォントの異なる表示でした。 次のようなさまざまなブラウザ設定をインストールして、問題を解決しようとしました。



layers.acceleration.disabled

gfx.font_rendering.cleartype_params.rendering_mode

gfx.direct2d.disabled



しかし、残念ながら、これは役に立ちませんでした。



さらに、スクリーンショットをImageMagickと比較するために、fuzzなどのパラメーターを使用して、スクリーンショット間の可能な最大差を設定します。



このパラメーターを試して、この問題を解決しようとしました。 多数のテキストが存在するという事実のために、さまざまなピクセルの数が非常に大きいため、小さなファズ係数は問題を解決しませんでした。また、係数が大きいと、ブロック内のいくつかの要素がなくてもテストの合格に影響せず、バグを見逃す可能性がありました。



解決策は、テストが実行されたすべての仮想マシンでさまざまなブラウザーのすべての設定を複製し、オペレーティングシステム自体の設定を複製することでした。



たとえば、画像の1つがロードされなかったソーシャルボタンのブロックをチェックするテスト。



レポートでは次のリンクを使用できます。



モデル画像





テストブロックのスクリーンショット：





これらの2つの画像を比較した結果：





CommandExceptionは、比較された画像が251px異なることを示しています。





スクリーンショットのサイズが一致しない状況もあります。 この場合、次のレポートを受け取ります。







未知の理由で、テストブロック内の要素がわずかに偏っている場合があります。 このような場合、1つのモデルと比較するのではなく、マスクに適したモデルのグループと比較します。 HomePage_thePostMost.png、HomePage_thePostMost（1）.pngという名前のthePostMostブロックの複数のモデルを作成でき、すべてのモデルが有効であると見なします。 幸いなことに、そのようなオプションの数は有限であり、通常は2以下です。

技術的側面

前述のように、テスト、Java、Maven、TestNG、Selenium、Galen Frameworkの作成と実行にはテクノロジースタックが使用されます。 さらに、テスト結果はグラファイトに送信されます。 テストは、Jenkins CISを使用して直接実行されます。 このようなセットが選択された理由については詳しく説明しません。 これがすべて相互接続されている方法を簡単に説明します。



Selenium Gridは、グリッドノードが実行されているWindows 7を備えた4つの仮想マシンと、ハブが実行されているLinuxマシンにローカルで展開されます。 各ノードで使用可能なFirefoxおよびChromeブラウザの3つのインスタンスがあります。 さらに、ジェンキンスとグラファイトもLinuxマシンに展開されます。 Galenテストは、TestNGとの統合を通じて一般的なテスト実行で実行されます。 これを行うために、jav Galen APIを使用できる適切なクラスが作成されました。 TestNGとガレンの相互作用を実装する際に、ガレン開発者との相互作用によりすぐに解決されるいくつかの問題がありました。 方鉛鉱開発者自身が喜んで協力し、定期的にこのツールのアップデートをリリースします。これにより、機能が拡張され、さらに便利になります。 彼自身は、ガレンとTestNGの統合に関するドキュメントを書く予定です。



機能、ガレン、およびスクリーンショットベースのテストは、Testアノテーションに割り当てられた適切なグループパラメーターを使用して分離され、個別に起動される可能性があります。

結論

スクリーンショットの比較とGalen Frameworkを使用したテストの両方の方法は、ページレイアウトのテストに適用できます。 それらは互いにうまく補完し合う。 スクリーンショットを比較する方法は、ソーシャルネットワークの共有パネルやヘッダーのメインメニューなど、単一の要素またはブロックの表示をテストする必要がある場合により適しています。 ブロックには、その中に多くのアイコンを含めることができます。これらのアイコンは、他のアイコンや要素の中に配置したり、相対的な位置を設定したりできます。



Galenを使用してこれらすべての小さな瞬間を記述するのはかなり時間がかかりますが、各ブラウザーの1つのスクリーンショットはこの問題を解決し、スクリーンショットの比較では、仕様を説明するときに何かを見逃す可能性があるオプションを除外します。 次に、Galenはブロックの相対的な配置に対処し、ヘッダーとその中の固定テキストをチェックします。 たとえば、情報ポータルなど、機能ロジックが読み込まれていない同じタイプのテンプレートページでレイアウトをテストする必要がある場合、このケースのように、サイトのほとんどすべてのページに許可なくアクセスできる場合、または他のユーザーアクションを実行する場合に役立ちます。 さらに、Galenは適応型アプリケーションレイアウトのクロスブラウザーテストをうまく解決します。