web アプリケーションの ui 機能テストのための html...

1SIGSS 2014年7月研究会於富良野

Web アプリケーションのアプリケーションの UI 機能テストの機能テストのためのための HTML 構造パターンの抽出手法構造パターンの抽出手法

神谷神谷年洋年洋

[email protected]

(※) この資料はSlideshareでも配布されます。


導入導入

ユニットテスト（デベロッパーテスト）が行われています GUIに対するユニットテストも技術的には可能になりましたただし、現場ではGUIに対するユニットテストはそれほど行われていませんその理由として、作成・維持のコストが高すぎることが指摘されています

参考 SISS 2014年5月研研究会の発表


UI機能テストの記述機能テストの記述

UIの機能テストは、ユニットテストとしてもシステムテストとしても可能だが、ユニットテスト（モックによってロジックから切り離されて）システムテスト(ロジックも含めて)

どちらの場合も、自動化されたUIの機能テストは次の要素から構成される構成要素構成要素例例

(1) 前提条件特定のページが表示されている、等

(2) 入力値・操作ユーザーが特定のボタンやリンクをクリックした、フォームにテキストを入力した、等

(3) 期待する動作特定のページに遷移した、表示されたページ内に特定のテキストが含まれている、等


例例


既存のテストフレームワークの問題点既存のテストフレームワークの問題点

「期待する動作」において、表示されているページが特定のページであることの判定が難しい

つまりつまり Webアプリケーションの画面（ページ）の内容は、アプリケーションの多くの層が反映されるプレゼンテーション(UIの見た目やページ内の動作) ビジネスロジック、データベース（コンテンツ）

テストにおいて、表示されたページから層ごとに記述を分離するのが困難 DOMツリーという単一の表現で記述されるため


既存のテストフレームワークの問題点既存のテストフレームワークの問題点 (つづきつづき)

結果結果「期待する動作」の記述は次の２択

ページ内容のごく一部をチェックする、あるいはページの内容全体を文字列として、用意しておいた期待値と比較

問題問題ごく一部をチェックする方法 → チェックしていない部分の記述が干渉・衝突

たまたま同じ名前のラベルが存在する、など内容全体を文字列として比較する歩法 → プロダクションコードのあらゆる層の変更によりテスの書き直しが必要

いずれの方法でも、一貫性のチェックはできない同じ「分類」に属する２つのページが同じレイアウトになっているか


提案手法のアプローチ提案手法のアプローチ

WebアプリケーションのUIを対象としたテストを容易にするための

HTML構造パターン構造パターンテスト対象となるWebアプリのページの分類をパターンとして用意しておき

トップページ、検索結果ページ、特集ページなどあるページがその分類のページであるかを判定する

仕掛け仕掛けパターンはDOMツリーの木構造に対する正規表現のようなものパターンの生成はサンプルとなるページ何枚かを入力として共通の構造を抽出する


例例


提案手法を用いたテスト提案手法を用いたテスト

パターンによりページ内の多くの要素がチェックされる → チェックしていない部分が干渉・衝突する危険性が減少

ページを不変部分と可変部分に分けて記述する → 可変部分に相当する層の変更があってもテストの書き直しは不要 → 一貫性のチェックが可能


テストフレームワークとしての実装テストフレームワークとしての実装

パターンを生成するためのツール + ユニットテストから利用されるパターンマッチングのライブラリ

パターン生成ツールパターン生成ツール HTMLによってページを記述したもの、あるいは、動的に取得したDOMツリーのスナップショットからパターンを生成する

DOMツリーのスナップショットを取得するツールも含まれている生成されたパターンはHTML（によく似たXML）のフォーマットで記述される

ブラウザで表示可能適当なエディタで編集可能

マッチングライブラリマッチングライブラリ与えられたページがパターンにマッチするかを判定マッチ→パターン中の「ワイルドカード」に相当するDOMの部分木を取得


めでたしめでたしめでたしめでたし

（※) 前回の発表ここまで


今回の発表のモチベーション今回の発表のモチベーション

効果的なテスト手法であるためには？

➯ 「パターンの開放・閉鎖原則」みたいな何か？

開放: 表現力いろんな構造をパターンとして表現できるべき

閉鎖: カバレッジページ内の多くの要素をチェックすべき


表現力表現力

表現力は定量的に評価しづらい

繰り返しの表現＋任意部分の表現正規表現のような

属性に関しては、属性値のみ任意、属性名も含めて任意の２パターン


例例

<img width="400px" src="yakei1.jpg"><img width="400px" src="yakei2.jpg">

可能なパターン何らかの任意部分 img要素（属性は不明）の並び img要素（width属性で値が"400px"のもの、および、他に任意の属性を持つ）の並び

img要素（width属性で値は"400px"、および、src属性で値は任意）の並びこのパターンが生成できることが望ましい


パターン生成手順パターン生成手順

繰り返しの検出 → 任意部分の識別

まず、入力となったDOMツリー内でで折り畳みを行う折り畳み = 繰り返しを検出して「繰り返し要素」に置き換える

この際、差異（テキストや属性）を「ワイルドカード」に置き換える DOMツリーの同じ階層内に限ったDAG化のようなもの

次に、DOMツリー間の差異を順次マージしていくマージ = 差異に相当する要素を「ワイルドカード要素」に置き換える


例例: 入力となった入力となったDOMツリーツリー


例例: 折り畳み後折り畳み後


カバレッジカバレッジ

パターンとページのマッチング → マッチした → マッチしない

マッチした場合 → カバーされた要素 = ワイルドカード以外にマッチした要素 → カバーされていない要素 = ワイルドカードによって無視された要素

カバレッジマッチした場合のみに定義されるワイルドカード以外にマッチした要素数 / ページ内の要素数


実験実験 - RQ

RQ1: パターンによってページを分類できるかRQ2: マッチしたものについて、カバレッジはどの程度か

目的はパターンのマッチングの精度の評価であるため、機械的に生成したパターンをそのまま用いる

実際の運用では、手作業でパターン中の不要な部分を削除することを想定

(ごく初期的、小規模な実験)


実験実験 - セットアップセットアップ

対象は、ある料理の献立サイト（１ページあたり400以上の要素を含む）

3つのページ分類 G ジャンル K 献立 S 検索結果

１つの分類あたり9ページを取得する 6ページをパターン生成に利用する（seed群）他の3ページを評価に用いる（trial群）

マッチする/しないマッチした場合のカバレッジ


実験実験 - 結果結果

RQ1 ページ分類は１例を除き成功失敗した分類Sの１例について調査

'trial'群の１ページが、同じ分類の他のページとバナー広告の構造が違っていた

RQ2 カバレッジは19%〜78％表に出ているのはカバーできなかった要素


まとめと今後の方針まとめと今後の方針

まとめ Web UIのテストのためのHTML構造パターンの改良カバレッジという指標を定義した初期的なテストを行った今後の方針カバレッジを改善する方法をさがす実装を洗練する

手作業でパターンを修正する作業の補助大規模なテストを行う


投稿後に発見した参考文献 Karthik Pattabiraman and Benjamin Zorn, “DoDOM: Leveraging DOM

Invariants for Web 2.0 Application Robustness Testing,” Proc. 21st IEEEInternational Symposium on Software Reliability Engineering (ISSRE’10),pp. 191-200, 1-4 Nov. 2010.

Ali Mesbah and Arie van Deursen, “Invariant-Based Automatic Testing ofModern Web Applications,” IEEE Transactions on Software Engineer- ing,vol. 38, no. 1, pp. 35-53, Jan.-Feb. 2012.

web アプリケーションの ui 機能テストの ための html...

Documents

web アプリケーションの ui 機能テストのための html...