JP2018116497A - 画面判定装置及びプログラム - Google Patents

Abstract

【課題】Ｗｅｂアプリケーションに関する画面の同一性を適切に判定可能とすること。【解決手段】画面判定装置は、Ｗｅｂアプリケーションに関する第１の画面の記述情報と、前記Ｗｅｂアプリケーションと同一又は異なるＷｅｂアプリケーションに関する第２の画面の記述情報とのそれぞれに対して所定の編集を行う編集部と、編集後の記述情報を比較して、前記第１の画面と前記第２の画面との同一性を判定する判定部と、を有する。【選択図】図５

Description

本発明は、画面判定装置及びプログラムに関する。

近年、ニーズに合ったサービスを迅速に提供するため、サービスを短いサイクルで提供する開発スタイルが増加しており、それに伴いソフトウェアテストの頻度も増加している。このような中、Ｗｅｂアプリケーションにおいて、機能テストにおける画面遷移テストに稼働がかかることが問題となっている。機能テストとはＪＳＴＱＢ（非特許文献１）によると「コンポーネント（独立してテストできるソフトウェアの最小単位）やシステム（コンポーネントのセット）の機能仕様の分析に基づいて実施するテスト」と定義され、コンポーネントレベルの機能を確認するテストから、システムレベルの機能を確認するテストまで存在する。

機能テストにおける画面遷移テストは、機能テストの中でも、「クライアントサイドからのインタラクションに対し、クライアントサイドに表示される画面から、仕様通りに実装されているかどうかを確認することができる機能に対するテスト」とここでは定義する。

機能テストにおける画面遷移テストに稼働がかかるのは、クライアントサイドからのインタラクションとして、画面にあるリンクやボタンをクリックしたり、フォームに適切な値を入力するなどの人間の操作が求められるためである。このような画面遷移テストを自動化し、稼働削減を狙う方法として、テストケースのスクリプト化し、自動実行する手法が広く知られている。

テストケースを人手でスクリプト化するには稼働がかかるため、以下の２つのテストスクリプト自動生成技術が存在する。
・Capture and Replay技術を用いたテストスクリプトの自動生成（非特許文献２）
・モデルベーステストによるテストスクリプトの自動生成（非特許文献３）

"JSTQB"、［online］、インターネット＜ＵＲＬ：http://jstqb.jp/syllabus.html＞ "Selenium IDE"、［online］、インターネット＜ＵＲＬ：https://addons.mozilla.org/ja/firefox/addon/selenium-ide/＞ "結合テストにおけるテスト項目自動生成手法の提案と評価"、丹野 治門，張 暁晶，星野 隆、電子情報通信学会技術研究報告、Oct 2010

Capture and Replay技術では、仕様から人手で作成したテストケースをユーザが実行することで、ユーザの画面に対する操作を記録してテストスクリプトとして出力することができる。しかし、Capture and Replay技術を用いた場合、画面操作を記録するためのツール操作といった追加の稼働が発生するため、一般的に３回以上同等のテストを実施しない場合は、稼働の元が取れないという欠点が存在する。

モデルベーステストでは、仕様をマシンが読み取れる形式のモデルで記述することで、読み取った仕様からテストケースを自動生成し、テストスクリプトとして出力することができる。しかし、モデルを記述するための追加の稼働がかかるという欠点が存在する。

以上より、既存のテストスクリプト自動生成技術では、テストスクリプトを生成するための追加の稼働が発生することが問題であるということがいえる。

一方で、追加の稼動を削減することでテストスクリプトの自動生成の効率化を図ろうとした場合、テストスクリプトによって実現される画面遷移の網羅性が問題となる。すなわち、一般的に画面はＵＲＬで識別されるが、同一ＵＲＬの画面同士でも、機能テストでは異なる画面と判別される必要が有ることがある。例えば、検索サイトにおいて、検索結果が無かったときの画面と検索結果が有ったときの画面はＵＲＬで見た場合、同一となることがあるが、機能テストの観点では別々の画面としてみなされるのが望ましい。また、多少の相違が有っても、機能テストの観点では機能的に同じ画面であれば同じ画面としてみなされるのが望ましい。各画面の同一性が適切に判定されなければ、各画面への遷移を網羅することが困難となり、テストの網羅性が低下してしまう。したがって、Ｗｅｂアプリケーションに関する画面の同一性を適切に判定できる技術が望まれる。

本発明は、上記の点に鑑みてなされたものであって、Ｗｅｂアプリケーションに関する画面の同一性を適切に判定可能とすることを目的とする。

そこで上記課題を解決するため、画面判定装置は、Ｗｅｂアプリケーションに関する第１の画面の記述情報と、前記Ｗｅｂアプリケーションと同一又は異なるＷｅｂアプリケーションに関する第２の画面の記述情報とのそれぞれに対して所定の編集を行う編集部と、編集後の記述情報を比較して、前記第１の画面と前記第２の画面との同一性を判定する判定部と、を有する。

Ｗｅｂアプリケーションに関する画面の同一性を適切に判定可能とすることができる。

同一ＵＲＬでも異なる画面としてテストしたい画面の例を示す図である。 Tree Edit Distanceの一例を示す図である。 本発明の実施の形態におけるシステム構成例を示す図である。 本発明の実施の形態におけるクライアント装置１０のハードウェア構成例を示す図である。 本発明の実施の形態におけるクライアント装置１０の機能構成例を示す図である。 クライアント装置１０が実行する処理手順の一例を説明するためのフローチャートである。 画面遷移図の一例を示す図である。 テストケースの生成及び実行処理の処理手順の一例を説明するためのフローチャートである。 フォームの一例を示す図である。 遷移先画面の判定処理の処理手順の一例を説明するためのフローチャートである。 ＤＯＭツリーの一例を示す図である。 画面遷移図の生成処理の処理手順の一例を説明するためのフローチャートである。 テストスクリプトの出力処理の処理手順の一例を説明するためのフローチャートである。

以下、図面に基づいて本発明の実施の形態を説明する。本実施の形態では、テスト対象から仕様をリバースし、リバースした仕様に基づいて網羅的なテストケースを自動生成し、テストスクリプトとして出力するといったアプローチを提案する。本アプローチによって、追加の稼働を必要とせずに網羅的なテストスクリプトを自動生成することができる。

本実施の形態では、機能テストにおける画面遷移テストを対象としているため、以下のステップで処理が実行される。
（１）テスト対象を解析し、仕様としてテスト対象を構成する画面と画面間の繋がり、各画面に到達するための手段を抽出する。
（２）（１）で取得した仕様から機能テストにおける画面遷移テストに適した画面遷移図を生成する。
（３）（２）で生成した画面遷移図の各遷移に対応するテストスクリプトを、（１）で抽出した画面に到達するための手段の情報に基づいて、出力したいスクリプト形式に合わせて出力する。

（１）ではテスト対象を構成する画面とその画面に到達するための手段を抽出する。Ｗｅｂアプリケーションでは、ｊｓｐファイル等の画面（ＨＴＭＬ）の元となるファイルから、クライアントサイドからのリクエストに応じて、動的に画面を生成するケースが一般的である。したがって、動的解析技術を用いてテスト対象を探索しつつ、情報を収集する。具体的には、動的解析において遷移する各画面のＨＴＭＬを解析し、ボタンやリンク等の情報を自動取得し、すべてのボタンやリンクをクリックするようなテストケースを生成する。また、入力フォームが存在する場合は無作為な値をテスト入力値とする。各画面に対し、上記を繰り返すことで画面遷移の網羅を目指す。

（２）では、（１）で取得したテスト対象を構成する画面情報を用いて、機能テストにおける画面遷移テストに適した画面遷移図を生成する。機能テストにおける画面遷移テストでは、機能の粒度で画面を識別する必要がある。一般的に画面はＵＲＬで識別されるが、同一ＵＲＬの画面同士でも、機能テストでは異なる画面と判別されることがある。例えば、検索サイトにおいて、検索結果が無かったときの画面と検索結果が有ったときの画面はＵＲＬで見た場合、同一となることがあるが、機能テストの観点では別々の画面としてみなされる。したがって、機能テストの観点に合った、適切な画面識別を行う必要がある（技術課題１：機能テストにおける適切な画面識別方法の検討）。

（３）は、出力したいスクリプト形式に合わせてテストスクリプトを生成するステップである。（１）で抽出した画面に到達するための手段（リンクやボタンのクリック、フォームへの入力等）を、出力したいスクリプト形式で記述する。本ステップについては、抽出した手段をそれに対応するメソッドで記述するだけなので技術的課題はないと考えられる。

以上より、本アプローチには以下の技術的課題があると考えられる。
技術課題１：機能テストにおける適切な画面識別方法の検討。

［技術課題１：機能テストにおける適切な画面識別方法の検討］
＜従来技術と問題点＞
本実施の形態では、機能テストにおける画面遷移テストを、機能テストの中でも、「クライアントサイドからのインタラクションに対し、クライアントサイドに表示される画面から、仕様通りに実装されているかどうかを確認することができる機能に対するテスト」と定義する。一般的に画面はＵＲＬで識別されるが、本定義における画面遷移テストでは、同一ＵＲＬの画面同士でも画面によっては異なる画面としてテストすることが重要である。例えば、検索サイトにおいて、図１のように検索結果が無かったときの画面と検索結果が有ったときの画面はＵＲＬで見た場合、同一となることがあるが、機能テストの観点では別々の画面としてみなす。このような場合、ＵＲＬではなく、表示される画面から識別するべきである。しかし、単純に表示された画面同士を画像として比較すると、確認したい機能部分が同一でも、それ以外の箇所が異なっていた場合、異なる画面と判別されてしまう。したがって、画面全体ではなく、画面を構成する要素の一部を比較する必要がある。画面は主にＨＴＭＬ、ＤＯＭ（Document Object Model ）構造、テキスト、画像、ＣＳＳ（Cascading Style Sheets）等の要素で構成されている。

試験観点によって着目すべき箇所は異なるが、本実施の形態では機能の違いがＨＴＭＬのＤＯＭ構造に表れるケースを対象とする。ＨＴＭＬのＤＯＭ構造比較の既存手法として、Tree Edit Distance（以下「ＴＥＤ」という。）を用いた手法が存在する（例えば、「"A survey on tree edit distance and related problems" Philip Bille. 2004. Theoretical Computer Science. Volume 337, Issues 1-3, 9 June 2005, Pages 217-239.」）。

ＴＥＤとは、両ＤＯＭツリーが一致するまでノードの削除・挿入を行ったときの削除・挿入の回数となる。例えば、図２においてＤＯＭツリー１とＤＯＭツリー２を一致させるには、ＤＯＭツリー２の＜ｐ＞、＜ｓｔｒｏｎｇ＞、＜Ｕ＞の３つのノードを削除し、＜ｉｍｇ＞ノードを挿入する必要があるため、ＴＥＤの値は４となる。閾値が３以下の場合、ＤＯＭツリー１とＤＯＭツリー２の構造は不一致と判断することができ、閾値が４以上の場合、ＤＯＭツリー１とＤＯＭツリー２の構造は一致すると判断することができる。

ＴＥＤを用いた画面の構造比較の欠点として、画面ごとに適切な閾値が異なるため、閾値の設定が困難であるといった点が挙げられる。閾値（ＴＥＤに対する許容範囲）を必要とする原因として、以下の２つが考えられる。
原因１：機能テストにおける画面の識別に影響を与えないノードの存在
原因２：並列化されたノードの存在
原因１については、太字タグ＜ｂ＞など、機能テストにおいて画面の識別に影響を与えないノードが存在することが挙げられる。原因２については、見出しタグなどが挙げられる。例えば、ニュースサイトにおいて、見出しの数が異なっている場合でもニュースを表示するという機能は同一であるため、見出しの数は機能に影響を与えないということがいえる。このように画面の識別に影響を与えないノードが存在し、それらのノードによってＴＥＤの値が増加するため、閾値を設ける必要がある。

＜本実施の形態における提案：ＨＴＭＬのＤＯＭ構造の類似度を利用した画面識別技術＞
本実施の形態では、原因１に関わるノードを削除し、原因２に関わるノードを集約することでＨＴＭＬを抽象化し、抽象化されたＨＴＭＬを比較することで、閾値の設定を必要とせずに機能テストにおける適切な画面識別を可能とする。

以下、上記を実現するための具体例について説明する。図３は、本発明の実施の形態におけるシステム構成例を示す図である。図３において、サーバ装置２０及びクライアント装置１０は、例えば、ＬＡＮ（Local Area Network）又はインターネット等のネットワークを介して接続される。

サーバ装置２０は、Ｗｅｂアプリケーションを含むテスト対象のシステムを含む１以上のコンピュータである。

クライアント装置１０は、サーバ装置２０が有するＷｅｂアプリケーションについてのテスト（検証）を支援する装置である。

図４は、本発明の実施の形態におけるクライアント装置１０のハードウェア構成例を示す図である。図４のクライアント装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、インタフェース装置１０５、表示装置１０６、及び入力装置１０７等を有する。

クライアント装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってクライアント装置１０に係る機能を実現する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１０６はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置１０７はキーボード及びマウス等で構成され、様々な操作指示を入力させるために用いられる。

図５は、本発明の実施の形態におけるクライアント装置１０の機能構成例を示す図である。図５において、クライアント装置１０は、テストシナリオ生成部１１、画面自動操作部１２、画面評価部１３及びテスト資材生成部１４等を有する。これら各部は、クライアント装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。

テストシナリオ生成部１１は、テストにおいて表示された各画面に対するテストシナリオとテスト入力値とを生成する。

画面自動操作部１２は、生成されたテストシナリオとテスト入力値とをテストケースとして、画面操作を自動的に実行することで、動的解析を実現する。

画面評価部１３は、画面操作の実行により遷移した画面が既に遷移したことのある画面か否かをＵＲＬやＨＴＭＬ等の情報を用いて判定する。画面評価部１３は、画面操作の実行により遷移した画面のＨＴＭＬデータと、既に遷移したことのある画面のＨＴＭＬデータとについて、それぞれを抽象化するための編集処理を行って、編集後のＨＴＭＬデータを比較する。

図５において、画面評価部１３は、ノード削除部１３１、ノード集約部１３２及び比較部１３３を含む。ノード削除部１３１は、上記の編集処理の一部として、上記の原因１に関わるノードの削除を実行する。ノード集約部１３２は、上記の編集処理の一部として、上記の原因２に関わるノードの集約を実行する。比較部１３３は、ノードの削除やノードの集約等の編集処理によって抽象化された２つのＨＴＭＬを比較して、当該２つのＨＴＭＬに係る画面の同一性を判定する。

テスト資材生成部１４は、静的解析及び動的解析により得られた情報に基づいて、画面遷移図を生成する。テスト資材生成部１４は、また、テストシナリオ生成部１１によって生成されたテストシナリオとテスト入力値をテストスクリプトの形式で出力する。

以下、クライアント装置１０が実行する処理手順について説明する。図６は、クライアント装置１０が実行する処理手順の一例を説明するためのフローチャートである。

ステップＳ１０１において、画面自動操作部１２は、初期ＵＲＬにアクセスして、初期ＵＲＬに対応するＨＴＭＬデータ等を取得する。その結果、当該ＨＴＭＬデータ等に基づく画面が表示装置１０６に表示される。初期ＵＲＬは、例えば、ユーザによって入力されてもよいし、補助記憶装置１０２に予め記憶されていてもよい。

続くステップＳ１０２〜Ｓ１０７では、初期ＵＲＬに対応するＨＴＭＬデータ、及び当該ＨＴＭＬデータに係る画面を起点として遷移可能な全てのＨＴＭＬデータに関して、動的解析等が実行される。具体的には、動的解析として、初期ＵＲＬに対応する画面を起点として実際にテスト対象の画面操作が自動的に実施される。動的解析では、各画面上の全てのリンクに対してクリックを実施し、入力フォームとそれに対応するサブミットボタンが有る場合には、サブミットボタンを押したときのリクエストに対してテスト入力値が生成され、画面操作が繰り返される。遷移先の画面について、既に遷移した画面との比較を行い、新規に遷移した画面かどうかの判断を行って、到達画面数をカウントする。以上の動的解析によって遷移先画面の情報（ＨＴＭＬ、ＵＲＬ等）と画面間の繋がり、画面に到達するための手段が取得される。また、コントローラを通らない画面遷移が動的解析で発見された場合、その画面遷移の情報も追加される。コントローラを通らない画面遷移とは、例えば、ａタグでのリンクがクリックされた場合に発生する画面遷移である。コントローラとは、Ｗｅｂアプリケーションにおいて一般的に用いられているデザインパターンであるＭＶＣ（Model View Controller）の構成において、クライアントサイドからのリクエストに対して実行する処理を決定する部分をいう。例えば、サーブレットがコントローラの一例である。

以下、ステップＳ１０２〜Ｓ１０７の間で処理対象とされているＨＴＭＬデータを、「対象ＨＴＭＬ」という。

ステップＳ１０３において、テストシナリオ生成部１１は、対象ＨＴＭＬに係る画面（以下、「対象画面」という。）に対するテストシナリオを生成する。すなわち、対象画面において画面の遷移を発生させる画面要素（リンクやサブミットボタン等）ごとに、操作及びロケータの組からなるテストシナリオが生成される。操作は、クリック等の操作である。ロケータは、操作の対象とされる画面要素の識別情報である。

続くステップＳ１０４〜Ｓ１０６は、ステップＳ１０３において生成されたテストシナリオごとに実行される。Ｓ１０４〜Ｓ１０６において処理対象とされているテストシナリオを、以下「対象テストシナリオ」という。

ステップＳ１０５において、テストシナリオ生成部１１が、対象テストシナリオに基づいてテストケースを生成し、画面自動操作部１２が、当該テストケースを対象画面に対して実行する。その結果、画面遷移が発生する。なお、対象テストシナリオが、入力値を必要とする場合、ステップＳ１０５において、テスト入力値の生成が行われる。

遷移先の全ての画面（ＨＴＭＬ）に対してステップＳ１０２〜Ｓ１０７が実行されると、テスト資材生成部１４は、画面遷移図を生成する（Ｓ１０８）。具体的には、テスト資材生成部１４は、ステップＳ１０２〜Ｓ１０７において実際に発生した画面遷移を示す画面遷移図を生成する。

図７は、画面遷移図の一例を示す図である。図７では、画面Ａから画面Ｂ及び画面Ｃに遷移し、画面Ｃから画面Ｂに遷移することが示されている。

続いて、テスト資材生成部１４は、各画面遷移が発生したときのテストシナリオとテスト入力値とをテストスクリプトの形式で出力する（Ｓ１０９）。

続いて、図６のステップＳ１０５の詳細について説明する。図８は、テストケースの生成及び実行処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ２０１において、テストシナリオ生成部１１は、対象テストシナリオの操作にフォームへの入力操作が含まれているか否かを判定する。対象テストシナリオの操作にフォームへの入力操作が含まれていない場合（Ｓ２０１でＮｏ）、テストシナリオ生成部１１は、対象テストシナリオをそのままテストケースとする（Ｓ２０２）。続いて、画面自動操作部１２は、当該テストケースを対象画面に対して実行する（Ｓ２０３）。当該テストケースの実行により、画面遷移が発生する。続いて、画面評価部１３は、テストケースの実行によるリンクのクリックやボタンの押下により発生したリクエストを「リクエストＡ」として記憶する（Ｓ２０５）。

続いて、画面評価部１３は、ステップＳ２０３で遷移した画面が既に遷移したことのある画面か否かをＵＲＬやＨＴＭＬ等の情報を用いて判定する（Ｓ２０５）。この際、ステップＳ２０３で遷移した画面が未だ遷移したことのない画面である場合、当該遷移に関する情報が、遷移リストの要素として追加される。遷移リストとは、動的解析において発生した画面間の遷移に関する情報を要素とするリストである。当該要素は、遷移前画面のＵＲＬ、遷移後画面のＵＲＬ、リクエストＡ、遷移後画面のＨＴＭＬ、及びテストケース等を含む。

一方、対象テストシナリオの操作にフォームへの入力操作が含まれている場合（Ｓ２０１でＹｅｓ）、テストシナリオ生成部１１は、変数ｉに０を代入する。変数ｉは、ステップＳ２０７以降の実行回数を記憶するための変数である。続いて、テストシナリオ生成部１１は、フォームへの入力値（テスト入力値）を生成する（Ｓ２０７）。例えば、対象画面が図９に示される通りであれば、対象テストシナリオには、姓に対応するフォームへの入力操作、名に対応するフォームへの入力操作、メールアドレスに対応するフォームへの入力操作、及び登録ボタンの押下等が含まれている。したがって、この場合、フォームごとに１つのテスト入力値が無作為に（ランダムに）生成される。

ステップＳ２０８において、テストシナリオ生成部１１は、生成された各テスト入力値がそれぞれに対応するフォームへの入力対象とされたテストケースを、対象テストシナリオに基づいて生成する。続いて、画面自動操作部１２は、当該テストケースを対象画面に対して実行する（Ｓ２０９）。すなわち、対象テストシナリオにおいて値の入力先とされている各フォームに対してテスト入力値が入力され、対象テストシナリオにおいて押下対象とされているサブミットボタンが押下される。その結果、画面遷移が発生する。

続いて、画面評価部１３は、ボタンの押下により発生したリクエストを「リクエストＡ」として記憶する（Ｓ２１０）。続いて、画面評価部１３は、ステップＳ２０５と同様の処理を実行する（Ｓ２１１）。

続いて、画面評価部１３は、変数ｉに１を加算する（Ｓ２１２）。続いて、画面評価部１３は、変数ｉの値が、Ｎに到達したか否かを判定する（Ｓ２１３）。Ｎは、ステップＳ２０７以降のループ回数として予め設定された定数である。Ｎの値を大きくすればするほど、動的解析における画面遷移の網羅性を高めることができるが、処理時間が長くなる。

変数ｉの値が、Ｎに等しい場合（Ｓ２１３でＹｅｓ）、対象テストシナリオについては、図８の処理が終了する。変数ｉの値が、Ｎに達していない場合（Ｓ２１３でＮｏ）、ステップＳ２０７以降が繰り返される。すなわち、対象テストシナリオについて、異なるテスト入力値が生成されてテストケースが実行される。

続いて、図８のステップＳ２０５及びＳ２１１の詳細について説明する。図１０は、遷移先画面の判定処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ３０１において、画面評価部１３は、遷移リストの中のリクエストＡを含むいずれかの要素の中に、現在の遷移先画面（すなわち、対象画面）のＵＲＬが遷移後画面のＵＲＬとして含まれているか否かを判定する。現在の遷移先画面のＵＲＬがリクエストＡの遷移後画面のＵＲＬとして遷移リストに含まれていない場合（Ｓ３０１でＮｏ）、画面評価部１３は、リクエストＡ、遷移前画面のＵＲＬ、現在の遷移先画面のＵＲＬ、現在の遷移先画面のＨＴＭＬ（対象ＨＴＭＬ）、及び対象テストシナリオに係るテストケースをセットとする要素を遷移リストに追加する（Ｓ３０２）。

一方、現在の遷移先画面のＵＲＬがリクエストＡの遷移後画面のＵＲＬとして遷移リストに含まれている場合（Ｓ３０１でＹｅｓ）、画面評価部１３は、遷移リストにおいてリクエストＡを含み、かつ、現在の遷移先画面のＵＲＬを遷移後画面のＵＲＬとして含む要素の遷移後画面のＨＴＭＬデータごとに、ステップＳ３０３〜Ｓ３１１を実行する。以下、処理対象とされているＨＴＭＬを「対象遷移済みＨＴＭＬ」という。また、現在の遷移先画面のＨＴＭＬを、上記において定義した通り「対象ＨＴＭＬ」という。

続いて、画面評価部１３は、対象遷移済みＨＴＭＬ及び対象ＨＴＭＬのそれぞれについて、ステップＳ３０４〜Ｓ３０８を実行する。対象遷移済みＨＴＭＬ及び対象ＨＴＭＬのうち、処理対象とされているＨＴＭＬを、「着目ＨＴＭＬ」という。

ステップＳ３０５において、画面評価部１３は、着目ＨＴＭＬのＤＯＭツリーを生成する。図１１にＤＯＭツリーの一例を示す。図１１に示されるように、ＤＯＭツリーは、各ノード（各画面要素）の階層構造を示す。

続いて、ノード削除部１３１は、画面の役割に影響を与えない（すなわち、画面の識別に影響を与えない）ノードを、ＤＯＭツリーから削除する（Ｓ３０６）。画面の役割に影響を与えないノードとは、属性ノード、テキストノード、及び文字の大きさや字体、位置を表すノード（Ｃｅｎｔｅｒタグ、Ｕタグなど）等の３種類である。したがって、図１１において破線の矩形で示されているノードが削除される。

続いて、ノード集約部１３２は、ＤＯＭツリーにおいて並列関係を有するノード（並列ノード）を１つのノードに集約する（Ｓ３０７）。並列ノードとは、ＤＯＭツリーの階層構造において同じ階層に属する同じタグ名の複数のノードをいう。図１１では、１点鎖線で囲まれている２つの＜ｈ１＞タグに対応するノードが並列ノードに該当する。ノードの集約は、並列ノードのうちの１つを残して他を削除することによって実現されてもよいし、各ノードを抽象化した１つのノードによって、並列ノードを置換することによって実現されてもよい。

ステップＳ３０４〜Ｓ３０８が対象遷移済みＨＴＭＬ及び対象ＨＴＭＬのそれぞれについて実行されることにより、それぞれについて抽象化されたＤＯＭツリーが生成される。

続いて、比較部１３３は、抽象化された２つのＤＯＭツリーのそれぞれをＨＴＭＬに変換し、変換結果を比較して、比較結果を出力する（Ｓ３０９）。すなわち、対象遷移済みＨＴＭＬに係る画面と、対象ＨＴＭＬに係る画面との同一性が判定される。比較されたＨＴＭＬが一致する場合、「一致」が比較結果として出力される。そうでない場合、「不一致」が比較結果として出力される。なお、比較されたＨＴＭＬの一致には、完全一致が要求されなくてもよい。例えば、同一タグの出現順等が異なることが許容されてもよい。

比較結果が「一致」である場合（Ｓ３１０でＹｅｓ）、対象遷移済みＨＴＭＬに関する処理は終了する。比較結果が「不一致」である場合（Ｓ３１０でＮｏ）、画面評価部１３は、ステップＳ３０２と同じ処理を実行して（Ｓ３１２）、図１０の処理を終了する。

続いて、図６のステップＳ１０８の詳細について説明する。図１２は、画面遷移図の生成処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ４０１〜Ｓ４０３は、遷移リストに含まれている要素（遷移前画面のＵＲＬ、遷移後画面のＵＲＬ、リクエスト、遷移後画面のＨＴＭＬ、及びテストケースのセット）ごとに実行される。以下、処理対象の要素を「対象要素」という。

ステップＳ４０２において、テスト資材生成部１４は、画面遷移図リストに、対象要素のリクエスト、対象要素の遷移前画面のＵＲＬ、対象要素の遷移後画面のＵＲＬを含む要素を追加する。すなわち、画面遷移図リストは、リクエスト、遷移前画面のＵＲＬ、遷移後画面のＵＲＬのセットを一つの要素とするリストである。

続いて、テスト資材生成部１４は、画面遷移図リストに基づいて、画面遷移図を生成する（Ｓ４０４）。なお、生成された画面遷移図は、表示装置１０６に表示されてもよいし、画面遷移図を示すデータが、補助記憶装置１０２に保存されてもよい。

続いて、図６のステップＳ１０９の詳細について説明する。図１３は、テストスクリプトの出力処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ５０１〜Ｓ５０３において、テスト資材生成部１４は、遷移リストの各要素に含まれているテストケースをスクリプトの形式で出力することで、テストスクリプトを出力する。

上述したように、本実施の形態によれば、遷移先の画面と、遷移済みの画面との比較において、それぞれのＨＴＭＬデータに所定の編集処理を行い、編集後のＨＴＭＬデータを比較して同一性が判定される。その結果、検索結果画面のように、同一のＵＲＬの画面であっても、異なる画面であることを判定することができる。また、機能的又は役割的に同じ画面が異なる画面であると判定される可能性を低下させることができる。すなわち、Ｗｅｂアプリケーションに関する画面の同一性を適切に判定可能とすることができる。その結果、例えば、Ｗｅｂアプリケーションの不具合を市場流出前において検知できる可能性と高めることができ、短期開発をも可能とすることができる。なお、本実施の形態は、同一のＷｅｂアプリケーションに関する画面の同一性だけでなく、異なるＷｅｂアプリケーションに関する画面の同一性の判定に適用されてもよい。

また、本実施の形態によれば、テスト対象から仕様をリバースし、リバースした仕様に基づいてテストケースを自動生成し、テストスクリプトとして出力することができる。これによりＷｅｂアプリケーションにおける網羅的な画面遷移テストのテストスクリプト生成を追加の稼働を必要とせずに自動で行うことができる。その結果、例えば、ソフトウェアテストにかかる費用を削減することができる。

更に、本実施の形態によれば、技術課題１に関して、閾値の設定を必要とせずに機能テストにおける適切な画面識別が可能となり、検証パターンの質を向上させることができる。

なお、本実施の形態において、クライアント装置１０は、画面判定装置の一例である。ノード削除部１３１及びノード集約部１３２は、編集部の一例である。比較部１３３は、判定部の一例である。ＨＴＭＬデータは、画面の記述情報の一例である。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０ クライアント装置
１１ テストシナリオ生成部
１２ 画面自動操作部
１３ 画面評価部
１４ テスト資材生成部
２０ サーバ装置
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
１０６ 表示装置
１０７ 入力装置
１３１ ノード削除部
１３２ ノード集約部
１３３ 比較部
Ｂ バス

Claims (4)

1. Ｗｅｂアプリケーションに関する第１の画面の記述情報と、前記Ｗｅｂアプリケーションと同一又は異なるＷｅｂアプリケーションに関する第２の画面の記述情報とのそれぞれに対して所定の編集を行う編集部と、
   編集後の記述情報を比較して、前記第１の画面と前記第２の画面との同一性を判定する判定部と、
   を有することを特徴とする画面判定装置。
2. 前記所定の編集は、並列関係を有する画面要素を一つに集約することである、
   ことを特徴とする請求項１記載の画面判定装置。
3. 前記所定の編集は、画面の識別に影響を与えない画面要素を削除することである、
   ことを特徴とする請求項１記載の画面判定装置。
4. Ｗｅｂアプリケーションに関する第１の画面の記述情報と、前記Ｗｅｂアプリケーションと同一又は異なるＷｅｂアプリケーションに関する第２の画面の記述情報とのそれぞれに対して所定の編集を行う編集部と、
   編集後の記述情報を比較して、前記第１の画面と前記第２の画面との同一性を判定する判定部と、
   としてコンピュータを機能させることを特徴とするプログラム。

Images