JP7283569B2 - 操作パターン生成装置、操作パターン生成方法及びプログラム - Google Patents

Description

本発明は、操作パターン生成装置、操作パターン生成方法及びプログラムに関する。

近年のソフトウェア開発の現場では、多様化する消費者ニーズに対応するため、短期間に複数の新バージョンをリリースするような開発スタイルが増加している。ソフトウェアは、大きく「設計」、「実装」、「試験（テスト）」の工程を経てリリースされる。開発したソフトウェアの正常性を確認するテスト工程は、ソフトウェアの不具合をリリース前に検出し、修正する作業である。テスト工程では、様々な観点でソフトウェアの正常性を確認するため、重要、かつ、多くの時間を要する作業となっている。

テスト工程では、テスト観点のうちの一つとして、テスト対象のＷｅｂアプリケーションが、設計者の意図した通りの動作を行うかどうかを確認する機能テストが行われる。機能テストにはさらにいくつかの確認観点が存在するが、画面遷移に関するテスト（以下「画面遷移テスト」という。）に膨大な時間を要することが問題となっている。

画面遷移テストは、任意の画面で任意の操作をした際に、次に表示される画面が設計者の意図した通りであるかどうかを確認するテストである。画面遷移テストが時間を要する理由としては、アプリケーションの全ての画面遷移に関する操作を網羅的に実施する必要があるため、リンクやボタンのクリック操作や入力フォーム等へのデータ投入などの人の手を介する操作が多く求められるからである。

従来、画面遷移テストに要する時間を削減する方法として、テストスクリプトを利用する方法がある。この方法は、テスト手順を特定のフォーマットのテストスクリプトとして記述し、そのテストスクリプトをツールに読み込ませることで、テストスクリプトに記載された手順に従ってブラウザ操作を自動で行い、テストを実施するものである。この方法によれば、画面遷移テストを実施する際の人手による操作を大幅に削減することが可能となる。

しかし、ブラウザ操作を自動実施するためのテストスクリプトを作成するためには、対象のＷｅｂアプリケーションの仕様の把握とスクリプトの記法の習熟が必要となる。また、スクリプトを作成する作業自体にも大きな時間を要する。更に、Ｗｅｂアプリケーションの既存機能に変更が加わることで、既存のテストスクリプトが使用できなくなるため、アプリケーションに仕様変更が施されるたびにテストスクリプトを修正する必要がある。一般的に、テストスクリプトを使用した自動テストを３回以上繰り返し実施しないと、テストスクリプトの作成に要した時間以上のテスト工程の作業削減効果は得られないと言われている。

このような課題を解決するために、テスト対象のＷｅｂアプリケーションを自動で操作することで仕様情報を復元し、復元された仕様情報からテストスクリプトを自動生成するリバースベースのテストスクリプト自動生成技術（以下「リバースベーステスト技術」という。）が存在する（特許文献１、非特許文献１）。リバースベーステスト技術によれば、人手によるテストスクリプト作成作業を必要とせずに画面遷移テストの自動化を実現することができる。

リバースベーステスト技術では、仕様復元の際に以下のステップで処理が行われる。
（１）操作対象画面の画面構造（ＨＴＭＬのＤＯＭ構造）を取得する。
（２）取得したＤＯＭ構造からボタン、リンクなどの操作できる対象（以下「操作要素」という。）と入力フォーム、チェックボックス、ラジオボタンなどのデータを投入する対象（以下、入力要素）の情報を取得する。
（３）入力要素に投入するデータについてユーザによる指定（以下「画面入力値補助」という。）が行われている場合は、ユーザによって指定されたデータを画面自動操作時にフォームに入力するデータの候補（以下「入力データ候補」という。）とする。画面入力値補助が行われない場合は、既定のルール（チェックボックスやラジオボタン等であれば個々の選択肢全てなど）に従って入力データ候補を作成する。
（４）生成した入力データ候補と操作要素の組み合わせにより、操作パターンを作成する。
（５）決定した操作パターンを消化するまで、同一画面の自動操作を続け、仕様を復元する。

以下に、図１を操作対象の画面とした場合の操作パターン例を示す。

上記の手順（１）－（３）にて、３種類（リンク１、リンク２、送信ボタン）の操作要素が取得され、４種類の入力フォーム（画面入力値補助で４つの値が指定されているとする）、３種類のプルダウン、及び２種類のチェックボックスについて入力データ候補が選定される（図２参照）。

手順（４）にて、操作要素と入力データ候補の組み合わせを行い、操作パターンを決定する（図３参照）。

手順（５）５で、作成した操作パターンを既定の回数に到達するまで順番に消化していく。

特開２０１８－１１６４９７号公報

倉林 利行, 伊山 宗吉,切貫 弘之, 丹野 治門: "画面操作を伴うテストにおけるテストスクリプトの自動生成手法", ソフトウェアエンジニアリングシンポジウム2017論文集 pp. 260-264, 2017年9月

リバースベーステスト技術は、上記したアルゴリズムにより、対象のＷｅｂアプリケーションの画面を自動で操作しながら、次々と画面を辿ることで、画面遷移に関する仕様情報を復元することを可能としている。しかし、操作パターンの算出を操作要素と入力データ候補の組み合わせで行っているため、操作パターン数が膨大となり、仕様復元のための画面の自動操作に多くの時間を要するという課題がある。

これらの操作パターンには画面遷移の仕様復元に寄与しない操作も多く含まれていると考えられる。仮に、図１の画面が以下の図４の仕様を持っている場合、最少で４回の操作で画面遷移の仕様を復元できるところ、これまでのリバースベーステスト技術では数十通りの操作パターンを実施する場合がある。

この課題への対応策として、上限値を設定することが考えられる。例えば、画面入力値補助で指定された値が複数存在する場合に上限値に従っていくつかをサンプリングすることや、導出した操作パターンからいくつかを選定してアプリの解析に用いることなどは容易に実現することが可能である。このような方法により、仕様復元に要する解析時間そのものを短縮することは可能である。

しかし、単純な上限数で操作パターン数を削減すると、画面遷移の仕様復元のために本来必要である操作パターンの欠落や操作の偏りが生じる可能性がある。したがって、仕様復元に紐付かない可能性の高い操作を判断し、その操作パターンだけを画面の自動操作から除外する必要がある。

本発明は、上記の点に鑑みてなされたものであって、Ｗｅｂアプリケーションの画面遷移の仕様復元に要する時間を短縮することを目的とする。

そこで上記課題を解決するため、操作パターン生成装置は、Ｗｅｂアプリケーションの画面において遷移を発生させる操作要素と、前記画面においてデータが入力される入力要素に対する入力データの候補との組み合わせに係る操作パターンを、前記Ｗｅｂアプリケーションに対するテストスクリプトに関して生成する生成部を有し、前記生成部は、前記操作要素のうちクエリストリングが設定されていないリンクについては、いずれの前記候補とも組み合わせない。

Ｗｅｂアプリケーションの画面遷移の仕様復元に要する時間を短縮することができる。

操作パターン例を説明するための操作対象の画面例を示す図である。 手順（１）－（３）によって得られる情報の一例を示す図である。 手順（４）によって得られる情報の一例を示す図である。 操作対象の画面の仕様の一例を示す図である。 本発明の実施の形態におけるシステム構成例を示す図である。 本発明の実施の形態におけるクライアント装置１０のハードウェア構成例を示す図である。 本発明の実施の形態におけるクライアント装置１０の機能構成例を示す図である。 クライアント装置１０が実行する処理手順の一例を説明するためのフローチャートである。 テストシナリオの生成処理の処理手順の一例を説明するためのフローチャートである。 リンクに対するテストシナリオの生成処理の処理手順の一例を説明するためのフローチャートである。 ボタンの押下によって送信されるデータを説明するための図である。 ボタンに対するテストシナリオの生成処理の処理手順の一例を説明するためのフローチャートである。 入力要素に対する入力データ候補の生成処理の処理手順の一例を説明するためのフローチャートである。

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

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

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

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

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

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

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

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

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

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

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

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

なお、図７における各部の機能及び各部が実行する処理手順は、特許文献２において開示された通りである。但し、本実施の形態では、テストシナリオ生成部１１の機能が拡張される。

以下、クライアント装置１０が実行する処理手順について説明する。図８は、クライアント装置１０が実行する処理手順の一例を説明するためのフローチャートである。図８に示した処理手順は、特許文献２の図６に示された処理手順と基本的に同じである。

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

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

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

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

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

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

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

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

図８に示した処理手順において、本実施の形態では、Ｗｅｂアプリケーションのリバースベーステスト技術による網羅的な画面操作による仕様復元に要する時間を削減するために、ステップＳ１０２の処理内容が拡張される。一つの画面（Ｗｅｂページ）を操作するパターン数を単純に削減すると、仕様復元ができなくなる可能性があるため、仕様復元に寄与しない操作を判別する仕組みが必要となる。リバースベーステスト技術は、操作要素と入力要素に投入する入力データ候補（入力値）の組み合わせから操作パターンを作成していることから、本実施の形態では、操作要素及び入力要素の特徴を活用し、画面遷移に寄与しない操作を判定し、操作パターンから除外することで解析時間を短縮するアプローチをとる。

Ｗｅｂアプリケーションの画面（Ｗｅｂページ）に関して、本実施の形態で着目する操作要素（リンク及びボタン）と入力要素について以下に記述する。

［操作要素］
＜リンク＞
・説明：リンクが押下すると、Ｗｅｂブラウザは指定されたリソース（ＵＲＬ）にアクセス（リクエスト（ＨＴＴＰリクエスト）の送信）をする。当該アクセスでは、次の画面を呼び出す処理が行われるのみであり、データの送信はあまり行われない。データ送信を行いたい場合は、ＵＲＬの末尾にパラメータとして特定の情報が付加される（クエリストリング）。

・ＨＴＭＬ記述例：<a href=“hoge/hoge?param=ZZZ”>リンク</a>
＜ボタン＞
・説明：ボタンが押下されると、Ｗｅｂブラウザは関連する入力要素に投入されているデータを指定されたリソース（ＵＲＬ）へリクエスト（ＨＴＴＰリクエスト）を送信する。

・ＨＴＭＬ記述例：<input type="submit" value="送信">
［入力要素］
＜テキストボックス、ラジオボタン、プルダウンなど＞
・説明：入力要素には、自由記述、リストからの選択などの操作によりデータが入力される。各入力要素にはデフォルト値を設定することができる（チェックボックスが選択された状態やテキストボックスに文字が入力されている状態で画面が表示される）。

・ＨＴＭＬ記述例（テキストボックス）：<input type="text" value="デフォルト値" >
本実施の形態では、上記の特徴を用いることで、リバースベーステストにおける仕様復元の精度を落とさずに操作パターン数の削減が行われる。以下に具体的な削減方法を示すため、ステップＳ１０３の詳細について説明する。

図９は、テストシナリオの生成処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ２０１において、テストシナリオ生成部１１は、対象画面に含まれる全ての操作要素及び全ての入力要素を対象ＨＴＭＬに基づいて抽出する。

続くステップＳ２０２～Ｓ２０６では、抽出された操作要素ごとにステップＳ２０３～Ｓ２０５が実行される。ステップＳ２０３～Ｓ２０５において処理対象とされている操作要素を「対象操作要素」という。

ステップＳ２０３において、テストシナリオ生成部１１は、対象ＨＴＭＬに基づいて、対象操作要素がリンクであるか否かを判定する。対象操作要素がリンクである場合（Ｓ２０３でＹｅｓ）、テストシナリオ生成部１１は、リンクに対するテストシナリオの生成処理を実行する（Ｓ２０４）。一方、対象操作要素がリンクでない場合（Ｓ２０３でＮｏ）、テストシナリオ生成部１１は、ボタンに対するテストシナリオの生成処理を実行する（Ｓ２０５）。

続いて、ステップＳ２０４の詳細について説明する。リンクは特定のリソースにアクセスする機能を持っており、画面上の入力要素に設定されているデータが利用されるケースは少ない。データ送信を行う場合はクエリストリングが用いられる。

クエリストリングとは、遷移先ＵＲＬの末尾に「？」＋「ｋｅｙ＝ｖａｌｕｅ」の形でパラメータを付加する方法であるが、どの入力要素に設定されたデータを送信するかを決定する実装方法は様々であり、また、ｋｅｙ名も実装者が自由に決められることから、機械的に特定することは難しい。

そこで、本実施の形態において、テストシナリオ生成部１１は、リンクにクエリストリングが設定されている場合は、従来のリバースベーステストの解析と同様に網羅的な操作パターンを生成し、解析に利用する。一方で、クエリストリングが付加されていない場合は、データ送信が行われないため、入力要素へのデータ投入は仕様復元に寄与しないと考えられる。そこで、クエリストリングが設定されていない場合は入力要素へのデータ投入を実施しない（いずれの入力データ候補とも組み合わせない）ことで操作パターンを削減する。具体的には、テストシナリオ生成部１１は、ステップＳ２０４において、図１０に示される処理手順を実行する。

図１０は、リンクに対するテストシナリオの生成処理の処理手順の一例を説明するためのフローチャートである。以下において、ステップＳ２０４において処理対象とされているリンクを「対象リンク」という。

ステップＳ３０１において、テストシナリオ生成部１１は、対象画面（対象ＨＴＭＬ）のＤＯＭ構造から対象リンクに関する情報（＜ａ＞タグ、＜ａｒｅａ＞タグ等）を取得する。続いて、テストシナリオ生成部１１は、ステップＳ３０１において取得されたａタグに設定されている遷移先ＵＲＬの値（ｈｒｅｆ属性の値等）を取得する（Ｓ３０２）。

続いて、テストシナリオ生成部１１は、遷移先ＵＲＬの文字列にクエリストリングが設定されている（含まれている）か否かを判定する（Ｓ３０３）。遷移先ＵＲＬにクエリストリングが設定されているか否かは、例えば、遷移先ＵＲＬの文字列（ｈｒｅｆ属性の値等）が「？ｘｘｘ＝ｘｘｘ」の形式であるか否かに基づいて判定することができる。例えば、対象リンクに関する＜ａ＞タグが、<a href=“hoge/hoge?param=ZZZ”>リンク</a>であれば、移先ＵＲＬの文字列にクエリストリングが設定されている（含まれている）と判定される。

クエリストリングが設定されていない場合（Ｓ３０３でＮｏ）、テストシナリオ生成部１１は、対象リンクに対していずれの入力要素を関連付けずに（いずれの入力要素に対する入力データの候補とも組み合わせずに）操作パターンを作成する（入力要素へのデータ投入はせずに対象リンクの押下だけの操作パターンを生成する）（Ｓ３０４）。

一方、クエリストリングが設定されている場合（Ｓ３０３でＹｅｓ）、テストシナリオ生成部１１は、対象画面の各入力要素への入力データの生成処理を実行する（Ｓ３０５）。ステップＳ３０５の詳細については後述される。続いて、テストシナリオ生成部１１は、対象リンクとステップＳ３０５において生成された入力データ候補との組み合わせに基づいて操作パターンを生成する（Ｓ３０６）。

ステップＳ３０４又はＳ３０６に続いて、テストシナリオ生成部１１は、生成した操作パターンに基づいてテストシナリオを生成する（Ｓ３０７）。

続いて、図９のステップＳ２０５の詳細について説明する。ボタンが押下された際は、当該ボタンと同一画面上の複数の入力要素のデータが合わせてサーバへ送信される。しかし、必ずしも同一画面上の全ての入力要素のデータが送信されるのではなく、押下されたボタンに関連している入力要素のみがデータ送信の対象となる。

図１１は、ボタンの押下によって送信されるデータを説明するための図である。図１１の場合、「送信ボタンＡ」の押下時には、入力フォームとプルダウンの二つの入力要素に設定された値が送信され、「送信ボタンＢ」押下時には、チェックボックスに設定された値が送信される。いずれの入力要素のデータが送信の対象となるのかはｆｏｒｍタグが基準となる。ＤＯＭツリーの構造において、ボタンのタグの上位に存在するｆｏｒｍタグの開始タグ（＜ｆｏｒｍ＞）から終了タグ（＜／ｆｏｒｍ＞）の間に含まれる入力要素（すなわち、当該ボタンが属するフォームに内の入力要素）の値（入力データ）が送信される対象となる。つまり、ｆｏｒｍタグの外にある入力要素は送信の対象とならないため、このような入力要素へのデータ投入は仕様復元に寄与しないと考えられる。

そこで、本実施の形態において、テストシナリオ生成部１１は、操作対象がボタン押下される際に入力データが送信対象となる入力要素を特定し、当該入力要素のみをデータ投入の対象とすることで、操作パターン数を削減する。具体的には、テストシナリオ生成部１１は、ステップＳ２０５において、図１２に示される処理手順を実行する。

図１２は、ボタンに対するテストシナリオの生成処理の処理手順の一例を説明するためのフローチャートである。以下において、ステップＳ２０４において処理対象とされているボタンを「対象ボタン」という。

ステップＳ４０１において、テストシナリオ生成部１１は、対象画面（対象ＨＴＭＬ）のＤＯＭ構造から対象ボタンに関する情報（＜ｂｕｔｔｏｎ＞タグ、＜ｉｎｐｕｔ ｔｙｐｅ＝”ｂｕｔｔｏｎ”＞タグ等）を取得する。続いて、テストシナリオ生成部１１は、対象ＨＴＭＬにおいて、対象ボタンの上位に位置するｆｏｒｍタグの情報（ｆｏｒｍ要素の情報）を取得する（Ｓ４０２）。

続いて、テストシナリオ生成部１１は、当該ｆｏｒｍタグ（当該ｆｏｒｍ要素）の開始タグ（＜ｆｏｒｍ＞）から終了タグ（＜／ｆｏｒｍ＞）までの間に存在する入力要素を特定する（Ｓ４０３）。続いて、テストシナリオ生成部１１は、特定した入力要素のみについて、入力データ候補の生成処理を実行する（Ｓ４０４）。ステップＳ４０４の詳細については後述される。

続いて、テストシナリオ生成部１１は、対象ボタンとステップＳ４０４において生成された入力データ候補との組み合わせに基づいて操作パターンを生成する（Ｓ４０５）。続いて、テストシナリオ生成部１１は、生成した操作パターンに基づいてテストシナリオを生成する（Ｓ４０６）。

続いて、図１０のステップＳ３０５及び図１２のステップＳ４０４の詳細について説明する。

従来のリバースベーステスト技術では、入力要素に投入するデータについてユーザによる補助（画面入力値補助）で指定された値があれば、その値が入力データ候補とされ、指定されていない場合は、既定のルールに従って入力データ候補が生成される。既定のルールとしては、例えば、チェックボックスでは、”個々の要素をそれぞれ一つずつチェックする”、”先頭の一つだけチェックする”や、テキストボックスであれば、”複数個のランダムな文字列を生成する”などが可能である。しかし、どの場合でも、操作パターン数の増大や、画面遷移に必要な操作パターンの欠落が発生する可能性がある。

一方で、ユーザによるデータ入力作業を減らすために、入力要素にはデフォルト値が設定されていることが多い。例えば、電子商取引サイト等における会員情報変更画面を開くと、現在登録されている氏名や住所などの会員情報が既に入力要素に入力された状態となっており、変更したい情報のみをユーザが書き換えるという仕様になっている場合が多い。このように、入力されるデータが既知の場合や入力される可能性の高い値が特定できている場合は、その値が初期状態でのデフォルト値とされる。つまり、入力要素にデフォルト値が設定されている場合は、そのデフォルト値が次の画面へ遷移するために必要なデータである可能性が高いと言える。

そこで、本実施の形態において、テストシナリオ生成部１１は、入力要素にデフォルト値が設定されている場合は、既定のルールに沿った新たな入力データ候補の生成はせずに、デフォルト値のみを入力データ候補とすることで、操作パターン数を削減する。具体的には、テストシナリオ生成部１１は、図１０のステップＳ３０５及び図１２のステップＳ４０４において、図１３に示される処理手順を実行する。

図１３は、入力要素に対する入力データ候補の生成処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ５０１～Ｓ５０８では、ステップＳ３０５又はＳ４０４において入力要素とされた入力要素ごとにステップＳ５０２～Ｓ５０７が実行される。以下、処理対象とされている入力要素を「対象入力要素」という。また、ステップＳ３０５又はＳ４０４の時点における対象リンク又は対象ボタンを「対象操作要素」という。

ステップＳ５０２において、テストシナリオ生成部１１は、対象入力要素に関連する情報を対象ＨＴＭＬから取得する。続いて、テストシナリオ生成部１１は、当該情報に基づいて、対象入力要素に対して画面入力値補助による入力データの指定がされているか否かを判定する（Ｓ５０３）。当該指定がされている場合（Ｓ５０３でＹｅｓ）、テストシナリオ生成部１１は、当該入力データを対象入力要素に対する入力データ候補とする（Ｓ５０４）。

一方、画面入力値補助が指定されていない場合（Ｓ５０３でＮｏ）、テストシナリオ生成部１１は、ステップＳ５０２において取得された情報に基づいて、対象入力要素にデフォルト値が指定されているか否かを判定する（Ｓ５０５）。デフォルト値が設定されているか否かの判定は、以下のように行うことができる。

対象入力要素がテキストボックス等のように文字列の入力が可能な入力要素である場合には、対象入力要素に関してｖａｌｕｅ属性、ｐｌａｃｅｈｏｌｄｅｒ属性等が有れば、デフォルト値が設定されており、そうでなければデフォルト値は設定されていないと判定することができる。また、対象入力要素がチェックボックス等のうに、複数の選択肢の中からいずれかの選択肢を選択される入力要素である場合には、対象入力要素に関してｃｈｅｃｋｅｄ属性等が有ればデフォルト値が設定されており、そうでなければデフォルト値が設定されていないと判定することができる。

対象入力要素に対してデフォルト値が設定されている場合（Ｓ５０５でＹｅｓ）、テストシナリオ生成部１１は、当該デフォルト値のみを対象入力要素に対する入力データ候補とする（Ｓ５０６）。一方、対象入力要素に対してデフォルト値が設定されていない場合（Ｓ５０５でＮｏ）、テストシナリオ生成部１１は、既定のルール（所定のルール）に従って、対象入力要素に対する入力データ候補を生成する（Ｓ５０７）。

なお、画面入力値補助について以下に補足する。

「倉林 利行 , 切貫 弘之 , 丹野 治門: "テストスクリプトの自動生成におけるテスト入力値作成支援技術の提案",情報処理学会
研究報告ソフトウェア工学
, vol. 2018-SE-199, no. 13, pp.1-7, 2018年7月」では、「事前にテスト対象をクロールすることで入力フォームの情報を収集し、各フォームに対して入力値を指定するためのフォーマットを自動生成する」手法が提案されている。

具体的には、まず、テスト対象のアプリケーションをクロールする際に、各画面の入力要素に設定されているｉｄ属性、ＸＰａｔｈ（ＨＴＭＬ上で要素の位置を一意に特定する記法）などの情報を取得し、クローラ（マシン）が読み取れる形式で記述されたフォーマットを出力する。その後、ユーザは、出力されたフォーマットに対して、各入力要素に投入したい具体的な値を手動で追記していく。ユーザによって具体的な値が追記されたファイルをクローラに設定し、再度アプリケーションを解析することで、ファイルに記述されたｉｄ属性（ＸＰａｔｈ）と合致する入力要素を発見した場合、クローラはユーザによって指定された具体的な値を入力フォームに投入して解析を行う。

本実施の形態では、上記のようなユーザが各入力要素に投入したい具体的な値を指定する仕組みを画面入力値補助という。

上述したように、本実施の形態によれば、入力要素や操作要素の特徴を用いることで、仕様復元に必要な画面遷移の発見に寄与する可能性が相対的に低い操作を抽出し、当該操作が画面の自動操作から除外される。これにより、仕様復元の精度を下げることなく、テストスクリプトに含まれる操作のパターンを削減することができ、Ｗｅｂアプリケーションの画面遷移の仕様復元に要する時間を短縮することが可能となる。

なお、本実施の形態において、クライアント装置１０は、操作パターン生成装置の一例である。テストシナリオ生成部１１は、生成部の一例である。

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

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

Claims (7)

1. Ｗｅｂアプリケーションの画面において遷移を発生させる操作要素と、前記画面においてデータが入力される入力要素に対する入力データの候補との組み合わせに係る操作パターンを、前記Ｗｅｂアプリケーションに対するテストスクリプトに関して生成する生成部を有し、
   前記生成部は、前記操作要素のうちクエリストリングが設定されていないリンクについては、いずれの前記候補とも組み合わせない、
   ことを特徴とする操作パターン生成装置。
2. Ｗｅｂアプリケーションの画面において遷移を発生させる操作要素と、前記画面においてデータが入力される入力要素に対する入力データの候補との組み合わせに係る操作パターンを、前記Ｗｅｂアプリケーションに対するテストスクリプトに関して生成する生成部を有し、
   前記生成部は、前記操作要素のうちボタンについては、当該ボタンが属するフォームの内の入力要素を入力データの組み合わせ対象の候補とする、
   ことを特徴とする操作パターン生成装置。
3. 前記生成部は、予め入力データのデフォルト値が設定されている前記入力要素については、当該デフォルト値のみを前記操作要素と組み合わせる、
   ことを特徴とする請求項１又は２記載の操作パターン生成装置。
4. Ｗｅｂアプリケーションの画面において遷移を発生させる操作要素と、前記画面においてデータが入力される入力要素に対する入力データの候補との組み合わせに係る操作パターンを、前記Ｗｅｂアプリケーションに対するテストスクリプトに関して生成する生成手順をコンピュータが実行し、
   前記生成手順は、前記操作要素のうちクエリストリングが設定されていないリンクについては、いずれの前記候補とも組み合わせない、
   ことを特徴とする操作パターン生成方法。
5. Ｗｅｂアプリケーションの画面において遷移を発生させる操作要素と、前記画面においてデータが入力される入力要素に対する入力データの候補との組み合わせに係る操作パターンを、前記Ｗｅｂアプリケーションに対するテストスクリプトに関して生成する生成手順をコンピュータが実行し、
   前記生成手順は、前記操作要素のうちボタンについては、当該ボタンが属するフォームの内の入力要素を入力データの組み合わせ対象の候補とする、
   ことを特徴とする請求項４記載の操作パターン生成方法。
6. 前記生成手順は、予め入力データのデフォルト値が設定されている前記入力要素については、当該デフォルト値のみを前記操作要素と組み合わせる、
   ことを特徴とする請求項４又は５記載の操作パターン生成方法。
7. 請求項１乃至３いずれか一項記載の操作パターン生成装置としてコンピュータを機能させることを特徴とするプログラム。

Images