JP2021179764A - 生成プログラム、生成装置、生成方法 - Google Patents

Abstract

【課題】キーワード駆動型テストの内容に関するテキストを自動で生成する生成装置を提供する。【解決手段】生成装置２０は、記憶部と制御部とを有し、記憶部は、テストコード３、テキスト５及び設計情報２１を記憶する。制御部は、生成装置の各部を制御する処理部であって、特定部、取得部及び生成部を有する。特定部は、テストコードに出現する項目ＩＤ（例えば、「ｉ＿ｎａｍｅ」と「ｂｔｎａｄｄ」）を特定するＳ１。取得部は、設計情報を参照することにより、特定部が特定した項目ＩＤに対応する項目名（例えば、「名前」と、「登録ボタン」）を取得するＳ２。生成部は、取得部が取得した項目名をキーワード（例えば、キーワード５ｘとして「名前入力エリア」、キーワード５ｙとして「登録ボタン」）に含むテキストを生成し、記憶部に格納する。【選択図】図５

Description

本発明は、生成プログラム、生成装置、生成方法に関する。

プログラムをテストする手法の一つにキーワード駆動型テストがある。キーワード駆動型テストは、テストケースを自然言語のテキストで記述することにより、テストケースを人が理解し易いようにする技術である。このように自然言語を利用することで、テキストの可読性を向上させたり、テストのメンテナンス性を高めたりすることができる。キーワード駆動型テストは、例えば、プログラムのテストを自動実行する際に必要なテスト実装の技法として活用されている。

そのようなキーワード駆動型テストにおいては、開発者がテストコードに出現する項目から自然言語のキーワードを生成し、そのキーワードを含むテキストを手作業で記述する。これにより、開発者とは異なる第三者が、テキストに基づいてテスト内容を容易に理解することができる。

例えば、テストコードに「reserve_btn」という項目がある場合を考える。この場合には、開発者が、当該項目から自然言語の「予約ボタン」というキーワードを生成し、該キーワードを含むテキストを手作業で記述する。これにより、このテストが「予約ボタン」を押下したときの振る舞いに関するテストであることを第三者が簡単に理解できる。

しかしながら、このように開発者がテストコードからキーワードを手作業で生成するのは極めて煩雑である。

国際公開第２０１７／１３５２８５号

一側面によれば、キーワード駆動型テストの内容に関するテキストを自動で生成することを目的とする。

一側面によれば、コンピュータに、プログラムに含まれる項目を識別する識別子と、前記項目の名前とを対応付けた設計情報を記憶した記憶部を参照することにより、前記プログラムに対するテストの内容に出現する前記識別子に対応した前記名前を取得し、取得した前記名前を含むテキストであって、前記テストの内容に関するテキストを生成する、処理を実行させるための生成プログラムが提供される。

一側面によれば、キーワード駆動型テストの内容に関するテキストを自動で生成することができる。

図１（ａ）は、キーワード駆動型テストの対象となるプログラムのソースコードの模式図であり、図１（ｂ）は、webブラウザがプログラムをレンダリングして生成したwebページの模式図である。 図２（ａ）は、プログラムのテストを自動で行うテストコードの模式図であり、図２（ｂ）は、キーワード駆動型テストにおけるテキストの模式図である。 図３（ａ）は、テキストをコンピュータが自動的に生成することができないプログラムの模式図であり、図３（ｂ）は、このプログラムのテストを自動で行うテストコードの模式図である。 図４（ａ）は、テストケースをコンピュータが自動的に生成することができない別の例について示す模式図であり、図４（ｂ）は、そのプログラムのテストを自動で行うテストコードの模式図である。 図５は、第１実施形態に係る生成装置が行う処理について示す模式図である。 図６は、図３（ｂ）のテストコードに基づいて生成装置がテキストを生成する場合の模式図である。 図７は、図４（ｂ）のテストコードに基づいて生成装置がテキストを生成する場合の模式図である。 図８は、第１実施形態に係る生成装置の機能構成図である。 図９は、第１実施形態に係る生成方法のフローチャートである。 図１０は、第２実施形態に係る生成装置の機能構成図である。 図１１は、第２実施形態に係る設計情報の模式図である。 図１２は、第２実施形態に係る操作情報の模式図である。 図１３（ａ）は、第２実施形態に係る変換ルール情報の模式図であり、図１３（ｂ）は、第２実施形態において中間情報を生成する方法について示す模式図である。 図１４は、第２実施形態に係る生成部が生成したテキストの一例を示す模式図である。 図１５は、第２実施形態に係る説明文の模式図である。 図１６は、第２実施形態に係る生成方法のフローチャートである。 図１７は、第２実施形態に係るテキストの生成処理のフローチャートである。 図１８は、第２実施形態に係るテストの実行方法のフローチャートである。 図１９は、第２実施形態においてテキストから説明文を生成する方法のフローチャートである。 図２０は、第１実施形態と第２実施形態の各々の生成装置のハードウェア構成図である。

本実施形態の説明に先立ち、本願発明者が検討した事項について説明する。

図１（ａ）は、キーワード駆動型テストの対象となるプログラム１のソースコードの模式図である。

このプログラム１は、HTML(HyperText Markup Language)形式で記述されたソースコードであって、label要素１ａと、input要素１ｂ、１ｃとを有する。これらの要素は、開始タグ「＜」と終了タグ「＞」とで囲まれた要素であって、プログラム１に含まれる項目の一例である。

このうち、label要素１ａには文字列「名前」が指定される。また、input要素１ｂには、type属性の値として「text」が指定される。「text」は、テキストを入力する入力ボックスを画面に生成する値である。更に、input要素１ｂには、id属性の値として「i_name」が指定される。id属性の値は、プログラム１に含まれる項目を一意に識別する識別子の一例である。この例では、「i_name」によってinput要素１ｂが識別されることになる。そのid属性の値は、プログラム１の開発時に開発者によって決定される。

一方、input要素１ｃにおけるtype属性の値には「button」が指定される。「button」は、画面にボタンを生成する値である。また、input要素１ｃにはvalue属性の値として文字列「登録」が指定される。このvalue属性は、ボタンに付す名前を指定する属性である。

更に、input要素１ｃにおけるid属性の値には、input要素１ｃを識別する「btnadd」が指定される。

図１（ｂ）は、webブラウザがプログラム１をレンダリングして生成したwebページの模式図である。

図１（ｂ）に示すように、このwebページ２には、input要素１ｂに対応した入力ボックス２ａと、input要素１ｃに対応したボタン２ｂとが表示される。

次に、図１（ａ）のプログラム１のテストを自動で行うテストコードについて説明する。

図２（ａ）は、プログラム１のテストを自動で行うテストコードの模式図である。

このテストコード３は、プログラム１に対するテストの内容を記述したプログラムであって、コード３ａ、３ｂを有する。コード３ａは、id属性が「i_name」の入力ボックス２ａに文字列「test user」を入力するコードである。また、コード３ｂは、id属性が「btnadd」のボタン２ｂをクリックするコードである。なお、「#」で始まる文は、開発者が記述したコメント文である。

このテストコード３を実行すると、入力ボックス２ａに文字列「test user」を入力し、更にボタン２ｂをクリックしたときのプログラム１の振る舞いをテストすることができる。

但し、テストコード３を作成した開発者以外の第三者は、このテストコード３を見ただけではテストの内容を直ちに理解することはできない。また、開発者が異動した場合には、テストの内容を知らない第三者がテストコード３のメンテナンスをするのが難しくなる。

これらの問題を解決する方法として、以下のようなキーワード駆動型テストがある。

図２（ｂ）は、キーワード駆動型テストにおけるテキストの模式図である。

このテキスト５は、図２（ａ）のテストコード３で実行されるテストの内容を自然言語で説明した説明文であって、説明文５ａ、５ｂを有する。この例では、プログラム１とテストコード３に基づいて、コンピュータが自動的にこのテキスト５を生成する。

説明文５ａは、図２のコード３ａで実行されるテストの内容を説明した文章である。この例では、テキスト５の可読性を高めるために、コンピュータが「名前入力エリア」というキーワード５ｘを説明文５ａに記述する。

コンピュータは、コード３ａのid属性の値「i_name」がプログラム１のinput要素１ｂに出現していることを特定し、該input要素１ｂの近くにあるlabel要素１ａの「名前」からの類推で「名前入力エリア」というキーワード５ｘを生成する。

同様に、説明文５ｂは、図２（ａ）のコード３ｂで実行されるテストの内容を説明した文章である。この例では、コンピュータは、コード３ｂのid属性の値「btnadd」でプログラム１のinput要素１ｃを特定し、その中にあるvalue属性「登録」からの類推で「登録ボタン」というキーワード５ｙを生成する。

このようなテキスト５は、キーワード５ｘ、５ｙを含む自然言語の文章で記述されているため、テストコード３の開発者以外の第三者にとって可読性が高くなる。そのため、第三者がテストの内容を容易に理解できると共に、第三者がテストコード３のメンテナンスをするのが容易となる。

しかしながら、以下のようにキーワード駆動型テストのテストケースをコンピュータが自動的に生成することができない例もある。

図３（ａ）は、テキストをコンピュータが自動的に生成することができないプログラムの模式図である。

このプログラム１は、画面表示を行わないHTML形式で記述されたプログラムである。図３（ａ）の例では、コマンドラインにおいて文字列「test user」を引数としてプログラム１に渡し、コマンドラインからプログラム１を実行する場合を示している。このようなプログラム１においては、画面でユーザに入力を促す必要がないため、「登録」等のような自然言語の文字列を含むinput要素１ｃ（図１（ａ）参照）等の項目がなく、該文字列からキーワードを類推することができない。

図３（ｂ）は、このプログラム１のテストを自動で行うテストコードの模式図である。

このテストコード３は、コード３ｃにおいて引数の文字列「test user」をid属性が「i_name」の項目に格納し、コード３ｄにおいてプログラム１を実行するコードである。

この例では、キーワードを類推する手がかりとなる自然言語の文字列を含んだ項目がプログラム１にないため、テストコード３の内容を説明するテキストをコンピュータが自動で生成できない。

図４（ａ）は、テストケースをコンピュータが自動的に生成することができない別の例について示す模式図である。

この例では、文字が付されていない再生ボタン９を表示するプログラムについて考える。このプログラムにおいては、再生ボタン９に文字を付する必要がないため、「登録」等のような自然言語の文字列を含むinput要素１ｃ（図１（ａ）参照）等の項目がなく、該文字列からキーワードを類推することができない。

図４（ｂ）は、そのプログラムのテストを自動で行うテストコードの模式図である。

このテストコード３は、再生ボタン９を表示する項目のid属性の値が「btnplay」である場合に、その再生ボタン９をクリックするコードである。

但し、前述のように元のプログラムには自然言語の文字列を含んだ項目がない。そのため、その文字列に基づいてコンピュータがキーワードを類推することができず、キーワード駆動型テストの内容を示すテキストを自動で生成することができない。

以下に、テスト対象のプログラムに自然言語の文字列がない場合であっても、キーワード駆動型テストの内容に関するテキストを自動で生成できる各実施形態について説明する。

（第１実施形態）
図５は、第１実施形態に係る生成装置が行う処理について示す模式図である。

生成装置２０は、テストコード３と設計情報２１とに基づいてキーワード駆動型テストの内容に関するテキスト５を生成するサーバやPC等のコンピュータである。

テストコード３は、図１（ｂ）で説明したように、プログラム１（図１（ａ）参照）をテストするときのコードである。

また、設計情報２１は、画面名、項目ID、及び項目名の各々を対応付けた情報である。

このうち、画面名は、プログラム１が表示する画面の名前である。また、項目IDは、プログラム１に含まれる項目を識別する識別子の一例である。図１（ａ）のようにプログラム１がHTML形式で記述されている場合、プログラム１の項目としてはlabel要素１ａやinput要素１ｂ、１ｃ等がある。また、項目IDとしては各要素のid属性の値がある。そして、項目名は項目の名前である。

この設計情報２１は、プログラム１の設計時に開発者が作成したプログラム１の設計書を基にして予め作成し得る。例えば、コンピュータが設計書からプログラム１を自動生成した場合には、id属性の値とその名前とを対応付けた対応表もコンピュータが自動で生成するため、その対応表を設計情報２１として使用すればよい。これにより、開発者が手作業で設計情報２１を作成する手間を省き、開発者の負担減を図ることができる。

また、手作業でプログラム１を開発した場合でも、上記の対応表を開発者が作成している場合には、その対応表を設計情報２１として使用すればよい。

更に、設計情報２１は、項目IDと項目名との対応付けがされていればそのファイル形式は特に限定されない。そのようなファイル形式としては、CSV(Comma Separated Value)、JSON(JavaScript Object Notation)、及びXML(Extensible Markup Language)の各型式がある。

本実施形態では、この設計情報２１を基にして、生成装置２０が以下のようにしてキーワード駆動型テストの内容に関するテキストを生成する。

まず、生成装置２０は、テストコード３に出現するプログラム１の項目IDを特定し（Ｓ１）、当該項目IDに対応する項目名を設計情報２１から取得する（Ｓ２）。

例えば、生成装置２０は、テストコード３に出現する項目IDとして「i_name」を特定する。そして、生成装置２０は、この項目ID「i_name」に対応した項目名「名前」を設計情報２１から取得する。

同様に、生成装置２０は、テストコード３に出現する項目ID「btnadd」を特定し、これに対応した項目名「登録ボタン」を設計情報２１から取得する。

これらの項目IDは、プログラム１に含まれる項目を一意に識別するid属性の値である。そのため、本実施形態では、プログラム１の項目に対応した項目名を一意に取得できる。

次いで、生成装置２０は、取得した「名前」と「登録ボタン」の各々を含むキーワード５ｘ、５ｙを生成し、各キーワード５ｘ、５ｙを含むテキスト５を生成する（Ｓ３）。

キーワード５ｘは「名前入力エリア」であるが、このうちの「名前」が、生成装置２０が設計情報２１から取得した項目名である。残りの「入力エリア」については、setValue等の関数名に基づいて生成装置２０が類推して生成する。一方、キーワード５ｙの「登録ボタン」は、生成装置２０が設計情報２１から取得した項目名である。

テキスト５は、プログラム１に対するキーワード駆動型テストのテストケースを説明した自然言語の文章である。この例では、文「名前入力エリアに”test user”と入力する」と、文「登録ボタンをクリックする」が、テストケースを説明する文章となる。

以上により、生成装置２０が行う基本的な処理を終える。

これによれば、設計情報２１にある項目名を利用して生成装置２０がテキスト５を生成する。そのため、図３（ａ）や図４（ａ）のようにキーワードを類推するための自然言語のテキストがプログラム中に存在しない場合であっても、そのプログラムに対するキーワード駆動型テストを説明したテキストを生成することができる。

図６は、図３（ｂ）のテストコード３に基づいて生成装置２０がテキスト５を生成する場合の模式図である。前述のように、このテストコード３は、自然言語の文字列を含んだ項目がないプログラム１（図３（ａ）参照）に対するテストコードである。

この例における設計情報２１は、コマンド名、パス、及びパラメータ名の各々を対応付けた情報である。このうち、コマンド名は、生成装置２０に対してプログラム１の実行を指示するコマンドの名前である。また、パスは、生成装置２０においてプログラム１が置かれているディレクトリのパスである。そして、パラメータ名は、プログラム１内で使用するパラメータの名前である。

この場合、パス「user_add.exe」は、プログラム１自身を識別する識別子となる。そして、パラメータ名「名前」は、パス「user_add.exe」に対応付けられた名前となる。

この例では、生成装置２０は、テストコード３に出現するパス「user_add.exe」を特定する（Ｓ１）。更に、生成装置２０は、設計情報２１を参照することにより、特定したパス「user_add.exe」に対応するパラメータ名「名前」とコマンド名「登録コマンド」を取得する（Ｓ２）。

その後、生成装置２０は、取得した「名前」と「登録コマンド」の各々を含むキーワード５ｖ、５ｗを生成し、これらのキーワードを含むテキスト５を生成する（Ｓ３）。

キーワード５ｖは「名前パラメータ」であるが、このうちの「名前」が、生成装置２０が設計情報２１から取得した文字列である。残りの「パラメータ」については、設計情報２１の「パラメータ名」に基づいて生成装置２０が類推して生成する。一方、キーワード５ｗの「登録コマンド」は、生成装置２０が設計情報２１から取得したコマンド名である。

図５の例と同様に、テキスト５は、プログラム１に対するキーワード駆動型テストのテストケースを説明した自然言語の文章である。この例では、文「名前パラメータに”test user”を設定」と、文「登録コマンドを実行する」が、テストケースを説明する文章となる。

以上により、生成装置２０が行う基本的な処理を終える。

このように、本実施形態によれば、キーワードを類推する手がかりとなる自然言語の文字列を含んだ項目がないプログラムであっても、設計情報２１から取得した名前からテキスト５を自動で生成することができる。

図７は、図４（ｂ）のテストコード３に基づいて生成装置２０がテキスト５を生成する場合の模式図である。前述のように、テストコード３は、再生ボタン９（図４（ａ）参照）に文字を付するための自然言語の文字列がないプログラムに対してテストを行うためのコードである。

この場合は、生成装置２０は、テストコード３に出現する項目IDとして「btnplay」を特定し（Ｓ１）、当該項目IDに対応する項目名「再生ボタン」を設計情報２１から取得する（Ｓ２）。

次いで、生成装置２０は、取得した「再生ボタン」を含むキーワード５ｚを生成し、そのキーワード５ｚを含むテキスト５を生成する（Ｓ３）。

このように、本実施形態によれば、キーワードを類推する手がかりとなる自然言語の文字列を含んだ項目がないプログラムであっても、設計情報２１から取得した名前からキーワード５ｚを自動で生成することができる。

次に、本実施形態に係る生成装置２０の機能構成について説明する。
図８は、本実施形態に係る生成装置２０の機能構成図である。
図８に示すように、生成装置２０は、記憶部３１と制御部３２とを有する。

このうち、記憶部３１は、テストコード３、テキスト５、及び設計情報２１を記憶する。なお、生成装置２０の外部にある記憶装置のリポジトリにテストコード３、テキスト５、及び設計情報２１の各々を記憶させてもよい。

一方、制御部３２は、生成装置２０の各部を制御する処理部であって、特定部３３、取得部３４、及び生成部３５を有する。

特定部３３は、テストコード３に出現する項目IDを特定する処理部である。例えば、図５の例では、特定部３３は、項目IDとして「i_name」と「btnadd」とを特定する。

取得部３４は、設計情報２１を参照することにより、特定部３３が特定した項目IDに対応する項目名を取得する。図５の例では、取得部３４は、「i_name」に対応する項目名「名前」と、「btnadd」に対応する項目名「登録ボタン」とを取得する。

そして、生成部３５は、取得部３４が取得した項目名をキーワードに含むテキスト５を生成し、それを記憶部３１に格納する処理部である。図５の例では、生成部３５は、項目名「名前」を含むキーワード５ｘとして「名前入力エリア」を生成し、かつ項目名「登録ボタン」をキーワード５ｙとして生成する。そして、生成部３５は、これらのキーワード５ｘ、５ｙを含むテキスト５を生成し、それを記憶部３１に格納する。

図９は、本実施形態に係る生成方法のフローチャートである。

まず、特定部３３がテストコード３に出現する項目IDを特定し（ステップＳ１）、特定した項目IDに対応する項目名を取得部３４が設計情報２１から取得する（ステップＳ２）。

そして、生成部３５が、取得部３４が取得した項目名をキーワードに含むテキストを備えたテキスト５を生成する（ステップＳ３）。

以上により、本実施形態に係る生成方法の基本処理を終える。

上記した本実施形態によれば、例えば図７に示したように、プログラム１に出現する項目の項目IDと項目名とを対応付けた設計情報２１を用いて生成装置２０がテキスト５を自動的に生成する。そのため、開発者がテキスト５を手作業で作成する必要がなく、テキスト５を簡単に生成することができる。

更に、このように設計情報２１を利用することにより、キーワードとして使用可能な自然言語の文字列がプログラム１に存在しない場合であっても、そのプログラム１に対するテストを説明するテキスト５を生成することができる。

（第２実施形態）
第１実施形態では、記憶部３１（図８参照）に予め格納されているテストコード３に基づいて、生成装置２０がテキスト５を生成した。これに対し、本実施形態では、テスト対象のプログラムがwebアプリケーションプログラムである場合に、生成装置が、そのプログラムに対する操作内容をテストの内容として記録する。そして、生成装置が、記録したテストの内容に関するテキストを自動で生成する。

図１０は、本実施形態に係る生成装置４０の機能構成図である。
図１０に示すように、生成装置４０は、通信部４１、入力部４２、表示部４３、記憶部４４、および制御部４５を備える。

このうち、通信部４１は、インターネットやLAN(Local Area Network)等のネットワークに生成装置４０を接続するためのインターフェースである。

また、入力部４２は、生成装置４０に各種のデータを入力するためのキーボードやマウス等の入力装置である。例えば、開発者は、入力部４２を操作することにより、テスト対象となる実行中のプログラムに対し、ボタンのクリックやデータの入力等を行う。

表示部４３は、制御部４５から出力される各種の情報を表示するための液晶ディスプレイ等の表示装置である。例えば、表示部４３は、テスト対象のプログラム１が生成した画面を表示する。

一方、記憶部４４は、プログラム１、設計情報６１、操作情報６２、変換ルール情報６３、テキスト６５、及び説明文６６を記憶する。なお、プログラム１、設計情報６１、操作情報６２、変換ルール情報６３、テキスト６５、及び説明文６６の各々を、生成装置４０の外部にある記憶装置のリポジトリに格納してもよい。その場合、生成装置４０は、通信部４１を介してリポジトリ内のこれらの情報を参照すればよい。

プログラム１は、HTML形式で記述されたテスト対象のwebアプリケーションプログラムである。

図１１は、設計情報６１の模式図である。
設計情報６１は、画面ID、画面名、画面項目ID、及び画面項目名の各々を対応付けた情報である。

本実施形態では、プログラム１が表示する複数の画面の各々もプログラム１の項目の一例となる。画面IDは、これらの画面の各々を識別するid属性の値であって、画面識別子の一例である。ここでは、「tyu010」や「tyu020」等の文字列を画面IDとして採用する。

そして、画面名は、プログラム１が生成する画面の名前である。例えば、画面ID「tyu010」で識別される画面の名前は「登録画面」である。

また、画面項目IDは、画面項目識別子の一例であって、プログラム１が画面に表示する項目を識別するid属性の値である。そのような項目としては、例えば、画面に表示されるボタンや入力ボックス等の要素がある。この例では、「cuscode」等の文字列を項目IDとして採用する。

更に、画面項目名は、画面に表示される項目の名前である。例えば、画面項目ID「cuscode」で識別される画面項目の名前は「顧客コード」である。

このように画面ID、画面名、画面項目ID、及び画面項目名の各々を対応つけることにより、複数の画面を表示するプログラム１のテストに関するテキストを生成することができる。

図１２は、操作情報６２の模式図である。
操作情報６２は、実行中のプログラム１が入力部４２を介して受け付けた操作の内容を示す情報である。例えば、「ID: #tyu010---btnadd」で示される操作情報６２は、画面IDが「tyu010」の画面において、id属性の値が「btnadd」のボタンがクリックされたことを示す。

本実施形態では、この操作情報６２が、プログラム１に対するテストの内容を示す情報となる。但し、開発者は、操作情報６２を見ただけではテストの内容を直ちには理解できない。そのため、生成装置４０が、後述のように操作情報６２に基づいてキーワード駆動型のテストケースを示すテキスト６５を生成する。

図１３（ａ）は、変換ルール情報６３の模式図である。
変換ルール情報６３は、操作情報６２を画面IDと画面項目IDに変換するルールを記憶した情報である。

例えば、一行目の「画面項目：#[画面ID]---[画面項目ID]」は、操作情報６２が記号「---」で連結された二つの文字列からなる場合に、一方の文字列を「画面ID」に変換し、他方を「画面項目ID」に変換するルールを示す。

本実施形態では、この変換ルール情報６３に基づいて、生成装置４０が操作情報６２から中間情報６４を生成する。

図１３（ｂ）は、その中間情報６４を生成する方法について示す模式図である。

中間情報６４は、「画面ID」や「画面項目ID」等の設計情報６１の項目を記憶した情報である。

ここでは、図１２と同様に操作情報６２が「ID: #tyu010---btnadd」で表される場合を考える。この操作情報６２は、二つの文字列「tyu010」、「btnadd」が記号「---」で連結された形式を有する。変換ルール情報６３においてこの形式に合致するのは「画面項目」である。「画面項目」では、「画面ID」と「画面項目ID」が記号「---」で連結されている。

よって、この操作情報６２は、画面IDが「tyu010」であり、かつ画面項目IDが「btnadd」の中間情報６４に変換される。

再び図１０を参照する。
制御部４５は、生成装置４０の各部を制御する処理部である。この例では、制御部４５は、アプリ実行部４６、記録部４７、特定部４８、取得部４９、生成部５０、テスト実行部５１、及び変換部５２を有する。

このうち、アプリ実行部４６は、テスト対象のプログラム１を実行する処理部である。また、記録部４７は、実行中のプログラム１が入力部４２を介して受け付けた操作の内容を操作情報６２として記録し、操作情報６２を記憶部４４に格納する処理部である。

特定部４８は、中間情報６４に現れる画面IDと画面項目IDを特定する処理部である。図１３（ｂ）の例では、特定部４８は、中間情報６４に現れる画面ID「tyu010」と画面項目ID「btnadd」を特定することになる。

取得部４９は、設計情報６１を参照することにより、特定部４８が特定した画面IDと画面項目IDの各々に対応付けられた名前を取得する処理部である。図１３（ｂ）の例では、取得部４９は、画面項目ID「btnadd」に対応する画面項目名「登録ボタン」と、画面ID「tyu010」に対応する画面名「登録画面」とを設計情報６１（図１１参照）から取得する。

また、生成部５０は、取得部４９が取得した名前をキーワードに含むテキスト６５をテストケースとして生成し、該テキスト６５を記憶部４４に格納する処理部である。

図１４は、生成部５０が生成したテキスト６５の一例を示す模式図である。

このテキスト６５は、図１３（ｂ）の中間情報６４に基づいて生成部５０が生成したテキストである。ここでは、テキスト６５は、画面ID、画面名、画面項目ID、及び画面項目名を有する。

このうち、画面IDと画面項目IDの各々は中間情報６４におけるのと同一である。また、画面名と画面項目名の各々は、テキスト６５におけるキーワードである。ここでは、設計情報６１（図１１参照）において画面ID「tyu010」に対応する「登録画面」が画面名となる。また、設計情報６１において画面項目ID「btnadd」に対応する「登録ボタン」が画面項目名となる。

このようにテキスト６５に「登録画面」や「登録ボタン」等の自然言語のキーワードを記述することにより、開発者は、テキスト６５が説明するテストが「登録画面」と「登録ボタン」に関するものであることを容易に理解できる。

再び図１０を参照する。
テスト実行部５１は、テキスト６５に基づいてプログラム１に対するテストを実行する処理部である。そのテストの内容は、操作情報６２に記録されている操作内容と同一である。

そして、変換部５２は、テキスト６５の内容を自然言語の説明文６６に変換し、それを記憶部４４に格納する処理部である。

図１５は、その説明文６６の模式図である。
この説明文６６は、図１４のテキスト６５を変換部５２が変換して得られた文である。ここでは、テキスト６５に現れる「登録画面」と「登録ボタン」等の自然言語を組み合わせた文章「「登録画面」の「登録ボタン」を〇〇する」を変換部５２が生成する。

これにより、キーワードを羅列したテキスト６５よりも可読性の高い説明文６６を得ることができ、説明文６６の内容に基づいて開発者がテストの内容を更に容易に理解することができる。

次に、本実施形態に係る生成方法について説明する。
図１６は、本実施形態に係る生成方法のフローチャートである。
まず、記録部４７が、実行中のプログラム１が受け付けた操作の内容を操作情報６２として記録する（ステップＳ１１）。例えば、プログラム１の実行中に、画面IDが「tyu010」の画面に存在するid属性の値が「btnadd」のボタンを開発者がクリックした場合は、記録部４７は、「ID: #tyu010---btnadd」で示される操作情報６２を記録する。

次に、特定部４８が、操作情報６２にid属性が存在するかどうかを判定する（ステップＳ１２）。

操作情報６２が「ID: #tyu010---btnadd」で示される場合は、「tyu010」と「btnadd」がid属性であるため、特定部４８はid属性があると判断する。

一方、id属性がないプログラムを実行している場合には、特定部４８はid属性がないと判断する。この場合には、id属性である画面IDや画面項目IDを格納した設計情報６１を利用してテキスト６５を生成することができない。よって、この場合は、ステップＳ１３に移り、生成部５０が、id属性を使用しないでテキスト６５を生成する。

一例として、生成部５０は、生成装置４０においてプログラム１が格納されてディレクトリのパス「/HTML[1]/BUTTON[1]」をテキスト６５として生成する。

一方、操作情報６２にid属性がある場合（ステップＳ１２：肯定）はステップＳ１４に移る。

ステップＳ１４においては、特定部４８が、操作情報６２の記述形式が変換ルール情報６３の形式に合致するかを判定する。

例えば、「ID: #tyu010---btnadd」で示される操作情報６２は、変換ルール情報６３（図１３（ａ）参照）の一行目の形式と合致する。

一方、「ID:#other_item」で示される操作情報６２は、変換ルール情報６３（図１３（ａ）参照）のいずれの行の形式とも一致しない。この場合には、変換ルール情報６３を用いて操作情報６２を設計情報６１の項目に変換できないため、設計情報６１を利用してテキスト６５を生成することができない。

よって、この場合は、ステップＳ１５に移り、生成部５０が、操作情報６２に含まれるid属性を利用してテキスト６５を生成する。例えば、「ID:#other_item」で示される操作情報６２において「other_item」がid属性である場合は、生成部５０は、テキスト６５として「other_item」を生成する。

一方、操作情報６２の記述形式が変換ルール情報６３の形式に合致する場合（ステップＳ１４：肯定）はステップＳ１６に移る。

ステップＳ１６においては、特定部４８が、操作情報６２に含まれる全てのid属性が設計情報６１（図１１参照）に存在するかを判定する。一例として、操作情報６２が「ID: #tyu010---btnadd」で表される場合は、特定部４８は、id属性の「btnadd」と「tyu010」の両方が設計情報６１に存在すると判定する。

一方、操作情報６２が「ID: #tyu010---noexist」で表される場合は、特定部４８は、id属性の「noexist」が設計情報６１に存在しないと判定する。この場合には、設計情報６１を利用してテキスト６５を生成することができないため、前述のステップＳ１５において生成部５０が操作情報６２に含まれるid属性を利用してテキスト６５を生成する。例えば、上記のように操作情報６２が「ID: #tyu010---noexist」で表される場合は、生成部５０は、テキスト６５として「ID: #tyu010---noexist」を生成する。

また、操作情報６２に含まれる全てのid属性が設計情報６１に存在する場合（ステップＳ１６：肯定）はステップＳ１７に移る。

ステップＳ１７においては、生成装置４０が、設計情報６１に基づいたテキスト６５の生成処理を行う。その生成処理の詳細については後述する。

以上により、本実施形態に生成方法の基本的な処理を終える。

次に、ステップＳ１７におけるテキスト６５の生成処理について説明する。
図１７は、ステップＳ１７におけるテキスト６５の生成処理のフローチャートである。

まず、特定部４８が、変換ルール情報６３に基づいて、操作情報６２から中間情報６４を生成する（ステップＳ２１）。例えば、操作情報６２が「ID: #tyu010---btnadd」で表される場合は、特定部４８は、変換ルール情報６３（図１３（ａ））に基づいて、設計情報６１の画面ID「tyu010」と画面項目ID「btnadd」とを含む中間情報６４を生成する。

次に、特定部４８が、中間情報６４に出現する画面IDと画面項目IDの各々を特定する（ステップＳ２２）。上記の例では、特定部４８は、画面IDとして「tyu010」を特定し、画面項目IDとして「btnadd」を特定する。

次いで、取得部４９が、設計情報６１を参照することにより、特定部４８が特定した画面IDと画面項目IDの各々に対応する名前を取得する（ステップＳ２３）。上記の例では、取得部４９は、画面ID「tyu010」に対応する画面名「登録画面」と、項目ID「btnadd」に対応する画面項目名「登録ボタン」とを設計情報６１（図１１参照）から取得する。

続いて、生成部５０が、取得部４９が取得した名前を含むテキスト６５を生成する（ステップＳ２４）。上記の例では、生成部５０は、画面名「登録画面」と画面項目名「登録ボタン」とを含むテキスト６５を生成する。本実施形態では、このテキスト６５が、プログラム１に対するテストの内容を示すキーワード駆動型テストのテストケースを表すことになる。

以上により、テキストの生成処理の基本的な処理を終える。

本実施形態によれば、記録部４７が、プログラム１が受け付けた操作の内容を操作情報６２に記録する（ステップＳ１１）。これにより、操作情報６２から得た中間情報６４に基づいて、生成部５０がテストの内容に関するテキスト６５を自動で生成することができる。

しかも、生成部５０は、テストの内容を表す中間情報６４における画面項目IDや画面IDに対応した名前を設計情報６１から取得し、その名前を含むテキスト６５を生成する。その名前はキーワードとして機能するためテキスト６５の可読性が高まり、テキスト６５に基づいて開発者がテストの内容を容易に把握することが可能となる。

更に、このように生成部５０が自動でテキスト６５を生成することにより、開発者が手作業でテキスト６５を生成する必要がなく、開発者の負担を減らすこともできる。

次に、テキスト６５に基づいたテストの実行方法について説明する。
図１８は、本実施形態に係るテストの実行方法のフローチャートである。

まず、テスト実行部５１が、テキスト６５内の画面IDと画面項目IDの各々が設計情報６１に存在するかを判定する（ステップＳ３１）。一例として、テキスト６５内の画面IDと画面項目IDがそれぞれ「tyu010」と「btnadd」である場合は、テスト実行部５１は、これらが設計情報６１に存在すると判定する。

このように画面IDと画面項目IDの各々が設計情報６１に存在する場合（ステップＳ３１：肯定）はステップＳ３２に移る。

ステップＳ３２においては、テスト実行部５１が、変換ルール情報６３を参照することにより、テキスト６５から操作情報６２を再現する。上記の例では、テスト実行部５１は、テキスト６５における画面IDが「tyu010」であり、かつ画面項目IDが「btnadd」であることを特定する。そして、テスト実行部５１は、変換ルール情報６３（図１３（ａ）参照）の一行目に基づいて、画面IDの「tyu010」と画面項目IDの「btnadd」とを記号「---」で連結した文字列を含む「ID:#tyu010---btnadd」を操作情報６２として再現する。

そして、テスト実行部５１が、この操作情報６２に基づいて、プログラム１のテストを実行する（ステップＳ３３）。上記の例では、テスト実行部５１は、画面ID「tyu010」で識別される画面に表示されている項目のうち、画面項目ID「btnadd」で識別されるボタンをクリックするテストを実行する。

一方、テキスト６５内の画面IDと画面項目IDのいずれかが設計情報６１に存在しない場合（ステップＳ３１：否定）は、このようにテキスト６５からテスト内容を再現することができない。よって、この場合は、ステップＳ３４に移り、テスト実行部５１がテキスト６５に即してプログラム１に対してテストを行う。

例えば、テキスト６５に「/HTML[1]/BUTTON[1]」等のパスが記述されている場合は、テスト実行部５１は、そのパスで指定される実行プログラム「BUTTON[1]」を実行することによりテストを行う。

また、テキスト６５に「ID:#tyu010---noexist」と記述されている場合は、テスト実行部５１は、画面ID「tyu010」で識別される画面に表示されている項目のうち、画面項目ID「noexist」で識別される項目を操作する。

更に、テキスト６５に「ID:#other_item」という文字列が記述されている場合は、テスト実行部５１は、この文字列で指定される操作を実行中のプログラム１に対して行う。

以上により、本実施形態に係るテストの実行方法の基本的な処理を終える。

本実施形態によれば、テキスト６５から再現した操作情報６２に基づいてテスト実行部５１がテストを実行するため、プログラム１をテストするためのテストコードを不要にすることができる。

次に、テキスト６５から説明文６６を生成する方法について説明する。

図１９は、本実施形態においてテキスト６５から説明文６６を生成する方法のフローチャートである。

まず、変換部５２が、テキスト６５内の名前が設計情報６１に存在するかを判定する（ステップＳ４１）。例えば、テキスト６５内の画面名が「登録画面」であり、画面項目名が「登録ボタン」である場合は、変換部５２は、これらの名前が設計情報６１に存在すると判定する。

このように名前が設計情報６１に存在する場合（ステップＳ４１：肯定）はステップＳ４２に移る。

ステップＳ４２においては、変換部５２が、テキスト６５内の名前が記述された説明文６６にテキスト６５を変換する。その説明文６６は、テスト時における操作の対象を説明した文章である。

例えば、上記の例のように名前が「登録画面」と「登録ボタン」である場合には、変換部５２は、「「登録画面」の「登録ボタン」を〇〇する。」という説明文６６にテキスト６５を変換する。この説明文６６においては、「「登録画面」の「登録ボタン」」がテスト時における操作の対象となる。

一方、テキスト６５内の名前が設計情報６１に存在しない場合（ステップＳ４１：否定）は、このように名前が記述された説明文６６を生成することができない。よって、この場合は、ステップＳ４３に移り、変換部５２が、テキスト６５を説明文６６に埋め込む。

例えば、テキスト６５に「/HTML[1]/BUTTON[1]」と記述されている場合は、変換部５２は、「/HTML[1]/BUTTON[1]を〇〇する。」という説明文６６を生成する。

また、テキスト６５に「ID:#tyu010---noexist」と記述されている場合は、変換部５２は、「ID:#tyu010---noexistを〇〇する。」という説明文６６を生成する。

更に、テキスト６５に「ID:#other_item」と記述されている場合は、変換部５２は、「ID:#other_itemを〇〇する。」という説明文６６を生成する。

以上により、テキスト６５から説明文６６を生成する方法の基本的な処理を終える。

上記した本実施形態では、変換部５２が、テスト時の操作対象を説明する説明文６６にテキスト６５を変換する（ステップＳ４２）。そのため、テキスト６５に基づいて開発者がテストの内容をより一層簡単に把握することができる。

（ハードウェア構成）
次に、第１実施形態と第２実施形態の各々の生成装置２０、４０のハードウェア構成について説明する。

図２０は、第１実施形態と第２実施形態の各々の生成装置２０、４０のハードウェア構成図である。

図２０に示すように、生成装置２０、４０は、記憶装置１０１、メモリ１０２、プロセッサ１０３、通信インターフェース１０４、表示装置１０５、及び入力装置１０６を有する。これらの各部は、バス１０７により相互に接続される。

このうち、記憶装置１０１は、HDD(Hard Disk Drive)やSSD(Solid State Drive)等の不揮発性のストレージであって、本実施形態に係る生成プログラム１１０を記憶する。

なお、生成プログラム１１０をコンピュータが読み取り可能な記録媒体１０８に記録させておき、プロセッサ１０３に記録媒体１０８の生成プログラム１１０を読み取らせるようにしてもよい。

そのような記録媒体１０８としては、例えばCD-ROM(Compact Disc - Read Only Memory)、DVD(Digital Versatile Disc)、及びUSB(Universal Serial Bus)メモリ等の物理的な可搬型記録媒体がある。また、フラッシュメモリ等の半導体メモリやハードディスクドライブを記録媒体１０８として使用してもよい。これらの記録媒体１０８は、物理的な形態を持たない搬送波のような一時的な媒体ではない。

更に、公衆回線、インターネット、及びLAN(Local Area Network)等に接続された装置に生成プログラム１１０を記憶させてもよい。その場合は、プロセッサ１０３がその生成プログラム１１０を読み出して実行すればよい。

一方、メモリ１０２は、DRAM(Dynamic Random Access Memory)等のようにデータを一時的に記憶するハードウェアであって、その上に生成プログラム１１０が展開される。

プロセッサ１０３は、生成装置２０、４０の各部を制御するCPU(Central Processing Unit)やGPU(Graphical Processing Unit)等のハードウェアである。また、プロセッサ１０３は、メモリ１０２と協働して生成プログラム１１０を実行する。

このようにメモリ１０２とプロセッサ１０３とが協働して生成プログラム１１０を実行することにより、生成装置２０の制御部３２（図８参照）と生成装置４０の制御部４５（図１０参照）が実現される。その制御部３２には、特定部３３、取得部３４、及び生成部３５が含まれる。また、制御部４５には、アプリ実行部４６、記録部４７、特定部４８、取得部４９、生成部５０、テスト実行部５１、及び変換部５２が含まれる。

また、記憶部３１（図８参照）と記憶部４４（図１０参照）の各々は、記憶装置１０１とメモリ１０２によって実現される。

更に、通信インターフェース１０４は、生成装置４０をインターネットやLAN等のネットワークに接続するためのNIC(Network Interface Card)等のハードウェアである。その通信インターフェース１０４により図１０の通信部４１が実現される。

そして、表示装置１０５は、表示部４３（図１０参照）を実現するための液晶ディスプレイやタッチパネル等のハードウェアである。

また、入力装置１０６は、入力部４２（図１０参照）を実現するためのキーボードやマウス等のハードウェアである。例えば、開発者は、入力装置１０６を操作することにより、テスト対象となる実行中のプログラムに対してクリックやデータの入力等の種々の操作を行うことになる。

１…プログラム、２…webページ、２ａ…入力ボックス、２ｂ…ボタン、３…テストコード、５…テキスト、５ａ、５ｂ…説明文、５ｖ〜５ｚ…キーワード、９…再生ボタン、１０…テストコード、２０…生成装置、２１…設計情報、３１…記憶部、３２…制御部、３３…特定部、３４…取得部、３５…生成部、４０…生成装置、４１…通信部、４２…入力部、４３…表示部、４４…記憶部、４５…制御部、４６…アプリ実行部、４７…記録部、４８…特定部、４９…取得部、５０…生成部、５１…テスト実行部、５２…変換部、６１…設計情報、６２…操作情報、６３…変換ルール情報、６４…中間情報、６５…テキスト、６６…説明文、１０１…記憶装置、１０２…メモリ、１０３…プロセッサ、１０４…通信インターフェース、１０５…表示装置、１０６…入力装置、１０７…バス、１０８…記録媒体、１１０…生成プログラム。

Claims (9)

1. コンピュータに、
   プログラムに含まれる項目を識別する識別子と、前記項目の名前とを対応付けた設計情報を記憶した記憶部を参照することにより、前記プログラムに対するテストの内容に出現する前記識別子に対応した前記名前を取得し、
   取得した前記名前を含むテキストであって、前記テストの内容に関するテキストを生成する、
   処理を実行させるための生成プログラム。
2. 前記項目は、前記プログラムが生成する画面と、前記プログラムが前記画面に表示する画面項目とを含み、
   前記識別子は、前記画面を識別する画面識別子と、前記画面項目を識別する画面項目識別子とを含み、
   前記名前は、前記画面の名前である画面名と、前記画面項目の名前である画面項目名とを含み、
   前記設計情報には、前記画面識別子、前記画面項目識別子、前記画面名、及び前記画面項目名とが対応付けられており、
   前記コンピュータは、
   前記設計情報を参照することにより、前記テストの内容に出現する前記画面識別子と前記画面項目識別子の各々に対応付けられた前記画面名と前記画面項目名とを取得する、
   ことを特徴とする請求項１に記載の生成プログラム。
3. 前記プログラムは、HTMLで記述されたソースコードであり、
   前記項目は、前記ソースコードに記述された開始タグと終了タグとで囲まれた要素であり、
   前記識別子は、前記要素のid属性の値であることを特徴とする請求項１に記載の生成プログラム。
4. 前記コンピュータに、
   実行中の前記プログラムが受け付けた操作の内容を前記テストの内容として記録する処理を実行させるための請求項１に記載の生成プログラム。
5. 前記コンピュータに、
   前記テキストに基づいて前記プログラムに対する前記テストを実行する、
   処理を実行させるための請求項１に記載の生成プログラム。
6. 前記コンピュータに、
   前記テストにおける操作の対象を説明する説明文に前記テキストを変換する、
   処理を実行させるための請求項１に記載の生成プログラム。
7. 前記コンピュータに、
   前記テストのテストコードに出現する前記識別子に対応した前記名前を特定する、
   処理を実行させるための請求項１に記載の生成プログラム。
8. プログラムに含まれる項目を識別する識別子と、前記項目の名前とを対応付けた設計情報を記憶した記憶部を参照することにより、前記プログラムに対するテストの内容に出現する前記識別子に対応した前記名前を取得する取得部と、
   取得した前記名前を含むテキストであって、前記テストの内容に関するテキストを生成する生成部と、
   を有することを特徴とする生成装置。
9. コンピュータが、
   プログラムに含まれる項目を識別する識別子と、前記項目の名前とを対応付けた設計情報を記憶した記憶部を参照することにより、前記プログラムに対するテストの内容に出現する前記識別子に対応した前記名前を取得し、
   取得した前記名前を含むテキストであって、前記テストの内容に関するテキストを生成する、
   ことを特徴とする生成方法。

Images