JP2016177659A - 検証プログラム、検証装置及び検証方法 - Google Patents

Abstract

【課題】網羅的な検証を効率良く行う。
【解決手段】検証装置１００は、作成部１３２と、設定部１３４と、検証部１３５とを含む。作成部１３２は、検証対象である検証対象ＡＰＩ（Application Programming Interface）に対して実行されるテストケースを作成する。設定部１３４は、検証対象ＡＰＩと、当該検証対象ＡＰＩが実行される際に利用する情報である参照情報を戻り値として返す関係にある他のＡＰＩとの階層関係の設定を行う。検証部１３５は、設定部１３４によって設定された階層関係に基づき、上位の階層にある他のＡＰＩを呼び出すことにより参照情報を取得し、取得した参照情報及びテストケースを用いて検証対象ＡＰＩを検証する。
【選択図】図２

Description

本発明は、検証プログラム、検証装置及び検証方法に関する。

近年、プログラムにおいて、ＡＰＩ（Application Programming Interface）が盛んに利用されている。ユーザは、ＡＰＩを利用することで、ＯＳ（Operating System）やライブラリ（Library）で提供される機能を有効に活用することができる。また、ＡＰＩ（あるいは、ＡＰＩを実装するソフトウェア）の挙動の検証やデバック作業を効率的に行うために、様々なテスト手法が提案されている。

例えば、テスト実行時のシステムの状態をＡＰＩ呼び出しにより取得したうえで、取得した状態に応じて関連するソフトウェアを制御することにより、常に同じテスト条件を作り出すことができる技術が知られている（例えば、特許文献１）。

また、プラグインモジュールからの情報を受けてテストケースを構築することにより、未知なる機能が発生したとしても、容易にテストの実施を可能とすることができる技術が知られている（例えば、特許文献２）。また、ＡＰＩなどのソースコードを利用できない外部関数を処理する際に、モデルを提供して、その外部関数が適切に呼び出されるかどうかを評価するといった技術が知られている（例えば、特許文献３）。

国際公開第２００９／１５０７８８号 特開２００９−２２３７００号公報 特開２００６−２３６３３６号公報

しかしながら、上記の従来技術では、網羅的な検証を効率良く行うことができるとは限らない。具体的には、検証対象とするＡＰＩが、他のＡＰＩの処理結果を利用するなどの所定の関係性を有する場合、他のＡＰＩが処理結果として発行する情報によって検証結果が変化する場合がある。このような場合、上記の従来技術では、他のＡＰＩが処理結果として発行する情報を適切に把握することができないため、検証対象とするＡＰＩに対して適切な検証を行うことは困難である。また、他のＡＰＩが処理結果として発行する情報の組合せを手動で設定することは可能だが、かかる組合せは膨大な数になり、現実的ではない。

本願は、上記に鑑みてなされたものであって、網羅的な検証を効率良く行うことができる検証プログラム、検証装置及び検証方法を提供することを目的とする。

本願に係る検証プログラムは、検証対象である検証対象ＡＰＩ（Application Programming Interface）に対して実行されるテストケースを作成する作成手順と、前記検証対象ＡＰＩと、当該検証対象ＡＰＩが実行される際に利用する情報である参照情報を戻り値として返す関係にある他のＡＰＩとの階層関係の設定を行う設定手順と、前記設定手順によって設定された階層関係に基づき、上位の階層にある前記他のＡＰＩを呼び出すことにより前記参照情報を取得し、取得された前記参照情報及び前記テストケースを用いて検証対象ＡＰＩを検証する検証手順と、をコンピュータに実行させることを特徴とする。

実施形態の一態様によれば、網羅的な検証を効率良く行うことができるという効果を奏する。

図１は、実施形態に係る検証処理の一例を示す図である。 図２は、実施形態に係る検証装置の構成例を示す図である。 図３は、実施形態に係るキャンペーンＡＰＩを説明する図である。 図４は、実施形態に係る広告グループＡＰＩを説明する図である。 図５は、実施形態に係る広告ＡＰＩを説明する図（１）である。 図６は、実施形態に係る広告ＡＰＩを説明する図（２）である。 図７は、実施形態に係る作成処理を説明する図（１）である。 図８は、実施形態に係る作成処理を説明する図（２）である。 図９は、実施形態に係る作成処理を説明する図（３）である。 図１０は、実施形態に係る検証処理を説明する図（１）である。 図１１は、実施形態に係る検証処理を説明する図（２）である。 図１２は、実施形態に係る検証処理を説明する図（３）である。 図１３は、実施形態に係る検証装置による作成処理手順を示すフローチャートである。 図１４は、実施形態に係る検証装置による検証処理手順を示すフローチャートである。 図１５は、検証装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。

以下に、本願に係る検証プログラム、検証装置及び検証方法を実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る検証プログラム、検証装置及び検証方法が限定されるものではない。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。

〔１．検証処理の一例〕
まず、図１を用いて、実施形態に係る検証処理の一例について説明する。図１は、実施形態に係る検証処理の一例を示す図である。図１では、検証システム１を例に挙げて、実施形態に係る検証処理について説明する。具体的には、図１では、検証システム１に含まれる検証装置１００が検証対象となるＡＰＩの動作を検証する処理（本願に係る検証プログラムに相当する）の流れについて説明する。

図１に示すように、検証システム１には、ユーザ端末１０と、実行サーバ２０_１、２０_２、及び２０_３と、検証装置１００とが含まれる。検証装置１００は、図示しない通信ネットワーク（例えば、インターネット）を介して、ユーザ端末１０、実行サーバ２０_１、２０_２、及び２０_３と通信可能に接続される。なお、以下では、実行サーバ２０_１、２０_２、及び２０_３を区別する必要のないときは、実行サーバ２０と表記する。また、検証システム１に含まれるユーザ端末１０や実行サーバ２０の台数は、図１に示した例に限られない。例えば、検証システム１には、複数台のユーザ端末１０が含まれてもよいし、さらに多くの実行サーバ２０が含まれてもよい。

ユーザ端末１０は、ユーザによって利用される情報処理装置である。具体的には、ユーザ端末１０は、検証対象となるＡＰＩの動作を検証するため、検証装置１００が提供する検証プログラムのＵＩ（User Interface）を表示したり、検証装置１００にプログラムの実行命令を送信したりするためなどに利用される。ユーザ端末１０は、例えば、スマートフォンやタブレット端末やＰＤＡ（Personal Digital Assistant）等の移動端末や、デスクトップ型ＰＣ（Personal Computer）や、ノート型ＰＣ等である。なお、実施形態における一般ユーザとは、例えば、実行サーバ２０が提供するＡＰＩであって、ウェブネットワーク上に配信させる広告を設定するための機能を提供するＡＰＩ（以下、「広告に係るＡＰＩ」と表記する場合がある）を利用しようとする広告主等が該当する。

実行サーバ２０は、ＡＰＩを実行するサーバ装置である。例えば、実行サーバ２０は、インターネットを介して、ＡＰＩをユーザに提供する。そして、実行サーバ２０は、ユーザからの所定の入力や制御に従い、ＡＰＩを実行する。例えば、実行サーバ２０は、広告に係るＡＰＩをユーザに提供することで、広告に係る入札の設定を受け付けたり、ユーザが広告配信を所定のウェブサイトで行う手間を省いたり、所定のウェブサイトで広告を表示させるための処理を実行する。実施形態では、実行サーバ２０は、検証装置１００が実行する検証プログラムによって、検証に係る設定を受け付けたり、ＡＰＩを実行したりする。なお、実行サーバ２０_１、２０_２、及び２０_３は、それぞれ異なるＡＰＩを保持し、検証装置１００からの送信される制御に従い、各々の処理を実行する。ユーザ端末１０や検証装置１００は、各々の実行サーバ２０のＡＰＩを利用する場合、実行サーバ２０を特定する情報を指定する。例えば、ユーザ端末１０や検証装置１００は、実行サーバ２０を特定するＵＲＬ（Uniform Resource Locator）を指定する。

実施形態において、実行サーバ２０は、ウェブネットワークで利用されるＡＰＩ（以下、「ウェブＡＰＩ」と表記する場合がある）を提供する。ウェブＡＰＩは、ＡＰＩ同士で相互の利用関係を有する場合がある。相互の利用関係とは、例えば、ウェブＡＰＩ同士が上位及び下位という階層関係を有すること等をいう。例えば、下層のウェブＡＰＩは、上層のウェブＡＰＩの所定の処理の結果である戻り値を取得し、取得した戻り値を利用して処理を行う場合がある。この場合、下層のウェブＡＰＩは、上層のウェブＡＰＩから得られる戻り値を取得できない場合には、処理がエラーとなる場合がある。なお、以下では、上層のＡＰＩが発行する戻り値のような情報であって、下層のＡＰＩの実行のために参照される情報を「参照情報」と表記する場合がある。参照情報は、上層のＡＰＩの処理結果として発行される所定のＩＤ情報であり、上層のＡＰＩで行われた処理を識別することができる。例えば、参照情報は、数桁の数値等により構成される。

検証装置１００は、検証対象となるＡＰＩ（以下、「検証対象ＡＰＩ」と表記する場合がある）の動作をテスト（検証）するためのテストケースを作成し、テストケースに従ってＡＰＩをテストする情報処理装置である。検証装置１００は、検証プログラムを実行することにより、検証対象ＡＰＩのテストを網羅的に効率良く実施することができる。以下、図１を用いて、検証システム１及び検証装置１００による検証処理を流れに沿って説明する。

まず、図１に示した例において、検証装置１００は、ユーザがＡＰＩのテストに関する情報等を検証プログラムに設定するために利用されるＵＩをユーザ端末１０に提供する（ステップＳ１１）。すなわち、ユーザ端末１０は、検証プログラムに係るＵＩを表示部に表示させ、ユーザからの入力を受け付ける。

ここで、ユーザ端末１０は、検証対象ＡＰＩの階層を設定する（ステップＳ１２）。上記のように、検証対象ＡＰＩがウェブＡＰＩである場合、ＡＰＩ同士に階層関係を有する場合がある。そして、階層関係がある場合には、検証対象ＡＰＩに対して上層のＡＰＩを設定していなければ、検証におけるテストの項目に漏れが生じたり、エラーが発生したりするため、網羅的な検証が行えない場合がある。そこで、ユーザ端末１０は、検証対象ＡＰＩの階層を設定することで、漏れのないテストを検証プログラムに行わせることができる。

また、ユーザ端末１０は、検証プログラムによって提供される所定のテストパターンを選択することで、ＡＰＩのテストケースを作成させる。ここで、テストパターンとは、検証のためにＡＰＩに実行させる所定の動作を示す。例えば、テストパターンは、ユーザから入力を受け付ける項目を有するＡＰＩにおいて、提供した入力必須項目に入力がなされているか否か、あるいは、入力項目に設定された最大値を超える値が入力されているか否かなど、具体的にＡＰＩがテストとして行う項目として予め定義された動作（挙動）のパターンである。なお、用途に応じて、ユーザ端末１０は、検証プログラムによって提供される所定のテストパターン以外のテストパターンを作成させることもできる。また、テストケースとは、テストパターンをまとめたものであり、検証プログラムがＡＰＩに対して実行する一連のテスト項目を示す。また、テストケースには、テストが行われる環境に関する情報等も含まれる。

このように、検証装置１００は、ＡＰＩの階層など、ユーザ端末１０から設定される情報の送信を受け付ける。そして、検証装置１００は、ユーザ端末１０から設定された情報に基づいて、テストケースを作成する（ステップＳ１３）。そして、検証装置１００は、ユーザ端末１０からの制御に従い、テストケースを実行することにより、検証対象ＡＰＩのテストを行う。なお、検証装置１００は、必要に応じて実行サーバ２０_１、２０_２、及び２０_３にアクセスし、それぞれが保持するＡＰＩをテストさせる場合がある（ステップＳ１４）。

ここで、検証装置１００に係る検証プログラムは、テストを実行するにあたり、検証対象ＡＰＩの上層のＡＰＩに対して、最上層に位置するＡＰＩから順に参照情報を発行させる。すなわち、検証プログラムは、検証対象ＡＰＩが実行するテストパターンについて、上層に位置するＡＰＩから発行される全ての参照情報が入力された状態でテストを行わせる。すなわち、検証プログラムによれば、検証対象ＡＰＩが実行するテストパターンにおいて、他のＡＰＩの動作結果が組み込まれるような相互の関係を有するテストパターンであっても、取りうる結果の全てを網羅的に取得することができる。

そして、検証装置１００は、検証対象ＡＰＩに対して行われたテスト結果の通知をユーザ端末１０に行う（ステップＳ１５）。例えば、検証装置１００は、検証対象ＡＰＩに対して行われたテストケースの一覧をＵＩに表示させることで、ユーザ端末１０に結果を通知する。この場合、検証装置１００は、１つのテストパターンに対して、複数の結果を表示する場合がある。これは、ＡＰＩのテストにおいて、上層のＡＰＩから発行された参照情報が異なることにより、１つのテストパターンを検証するために、異なる参照情報ごとに検証対象ＡＰＩが実行されていることによる。言い換えれば、検証装置１００は、検証対象ＡＰＩに設定された階層関係に基づいて、１つのテストパターンに対する複数のテスト環境（テストケース）を動的に作成する場合がある。

このように、実施形態に係る検証装置１００は、検証対象である検証対象ＡＰＩに対して実行されるテストケースを作成し、検証対象ＡＰＩと、当該検証対象ＡＰＩが実行される際に利用する参照情報を戻り値として返す関係にある他のＡＰＩとの階層関係についての設定を行う。そして、検証装置１００は、設定された階層関係に基づいて、他のＡＰＩを上位の階層から順に呼び出すことにより、検証対象ＡＰＩの実行に用いられる参照情報を取得しながら、テストケースを用いて検証対象ＡＰＩを検証する。

これにより、実施形態に係る検証装置１００は、ウェブＡＰＩなどの相互に関係を有するＡＰＩの検証処理を効率良く行うことができる。すなわち、テストを実施させるユーザは、検証対象ＡＰＩの階層関係を設定することで、上位階層のＡＰＩがとりうる戻り値の組合せ等を意識することなく、検証対象ＡＰＩに対するテストを実行させることができる。このように、検証装置１００は、階層関係を有するＡＰＩに対して、網羅的な検証を効率良く行うことができる。

〔２．検証装置の構成〕
次に、図２を用いて、実施形態に係る検証装置１００の構成について説明する。図２は、実施形態に係る検証装置１００の構成例を示す図である。図２に示すように、検証装置１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。なお、検証装置１００は、検証装置１００を利用する管理者等から各種操作を受け付ける入力部（例えば、キーボードやマウス等）や、各種情報を表示するための表示部（例えば、液晶ディスプレイ等）を有してもよい。

（通信部１１０について）
通信部１１０は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。かかる通信部１１０は、通信ネットワークと有線又は無線で接続され、通信ネットワークを介して、ユーザ端末１０や実行サーバ２０等との間で情報の送受信を行う。

（記憶部１２０について）
記憶部１２０は、例えば、ＲＡＭ（Random Access Memory)、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。実施形態に係る記憶部１２０は、ＡＰＩ情報記憶部１２１と、テストケース記憶部１２２と、テスト結果記憶部１２３とを有する。以下、各記憶部について順に説明する。

（ＡＰＩ情報記憶部１２１について）
ＡＰＩ情報記憶部１２１は、検証装置１００が検証を行うＡＰＩに関する情報を記憶する。例えば、ＡＰＩ情報記憶部１２１は、ＡＰＩを識別するための識別情報（例えば、ＡＰＩの名称や種別）や、ＡＰＩに関する変数や配列に関する情報（例えば、ＪＡＶＡ（登録商標）等においてはフィールドと表記される）や、ＡＰＩが保持されている場所（例えば、実行サーバ２０のＵＲＬ）などを記憶する。

例えばユーザは、検証に係るテスト項目となるテストケースを作成する際には、ＵＩを介して、ＡＰＩ情報記憶部１２１に記憶されているＡＰＩの情報を参照することができる。

（テストケース記憶部１２２について）
テストケース記憶部１２２は、ＡＰＩの検証に用いられるテストケースに関する情報を記憶する。例えば、テストケース記憶部１２２は、検証対象ＡＰＩである検証対象ＡＰＩの識別情報や、検証対象ＡＰＩに設定された階層情報や、実際にテストとして実行されるテストパターンの種別や、テストで実行されるメソッド（method）の種類などが記憶される。

例えばユーザは、検証対象ＡＰＩに対するテストケースを作成した際に、ＵＩを介して、テストケース記憶部１２２に記憶されているテストケースの情報を参照することができる。これにより、ユーザは、テストケースにおいて実行されるテストパターンの種別などを確認することができる。

（テスト結果記憶部１２３について）
テスト結果記憶部１２３は、テストケースを用いて検証対象ＡＰＩの挙動に対するテストが行われた後の結果を記憶する。例えば、テスト結果記憶部１２３は、テストを行った環境に関する情報や、各々のテストパターンや、各々のテストパターンに対して期待される状態や、実際に期待される状態が発生したか否かが検証された結果などを記憶する。

また、上述のように、テストの結果は、上層のＡＰＩが発行する参照情報によって異なる場合がある。すなわち、検証対象ＡＰＩは、上層のＡＰＩが発行する参照情報を受けて処理を実行するため、１つのテストパターンの実行であっても、複数の結果を返す場合がある。このような場合には、テスト結果記憶部１２３は、実施されたテストケースに対する結果として、実施された全てのテストパターンの結果を網羅的に記憶する。

例えばユーザは、所定のテストケースを用いて検証対象ＡＰＩに対してテストが行われた場合に、ＵＩを介して、テスト結果記憶部１２３に記憶されているテストケースの結果を参照することができる。

（制御部１３０について）
制御部１３０は、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、検証装置１００内部の記憶装置に記憶されている各種プログラム（検証プログラムの一例に相当）がＲＡＭを作業領域として実行されることにより実現される。また、制御部１３０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。

実施形態に係る制御部１３０は、図２に示すように、ＵＩ提供部１３１と、作成部１３２と、受付部１３３と、設定部１３４と、検証部１３５と、実行部１３６と、格納部１３７とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部１３０の内部構成は、図２に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部１３０が有する各処理部の接続関係は、図２に示した接続関係に限られず、他の接続関係であってもよい。

（ＵＩ提供部１３１について）
ＵＩ提供部１３１は、検証処理に関するＵＩを提供する。具体的には、ＵＩ提供部１３１は、検証装置１００が提供する検証プログラムをユーザが利用するために、ユーザ端末１０の表示部に表示させるＵＩを提供する。一例として、ＵＩ提供部１３１は、後述する検証部１３５によって検証された結果を表示するＵＩを提供する。

ユーザは、ＵＩ提供部１３１によって提供されるＵＩを介して、ＡＰＩの検証処理に係る種々の設定を行う。また、ユーザは、ＵＩに表示されるテストパターンを参照し、実際にテストを行う項目としてテストパターンを選択する。そして、ユーザは、選択したテストパターンがまとめられたテストケースを作成させる。

また、ＵＩ提供部１３１は、後述する検証部１３５によって検証された結果を表示するＵＩを提供する。これにより、ユーザは、ＡＰＩのテストが実施された後に、ＵＩを介してテスト結果を参照することができる。このとき、ＵＩ提供部１３１は、ＵＩを介して、検証対象ＡＰＩの検証結果と併せて、検証対象ＡＰＩの検証に用いられた他のＡＰＩに関する情報についても提供することができる。検証対象ＡＰＩの検証に用いられた他のＡＰＩとは、具体的には、検証対象ＡＰＩに対して階層関係が設定されたＡＰＩのことを示す。例えば、ＵＩ提供部１３１は、実行された検証対象ＡＰＩのスクリプトにおいて、実際に参照情報として用いられたＡＰＩの識別情報（例えば、名称）等を提供する。

すなわち、ＵＩ提供部１３１は、後述する作成部１３２や、検証部１３５、及び記憶部１２０等と相互に情報をやり取りすることにより、実行するテストの内容や、テストの結果等をユーザに提供する。

（作成部１３２について）
作成部１３２は、検証対象である検証対象ＡＰＩに対するテストケースを作成する。例えば、作成部１３２は、ユーザから検証対象ＡＰＩに対して実行するテストに関する設定を受け付けることにより、ユーザが所望するテストケースを作成する。なお、テストケースの作成にあたり、作成部１３２は、ＡＰＩに係る情報を取得する。作成部１３２は、ユーザから送信される情報を用いてＡＰＩに関する情報を取得してもよいし、外部の提供装置からＡＰＩに関する情報を取得してもよい。この場合、作成部１３２は、取得した情報をＡＰＩ情報記憶部１２１に格納する。また、図２に示すように、作成部１３２には、受付部１３３と、設定部１３４とが含まれる。

（受付部１３３について）
受付部１３３は、テストケースに関する設定を受け付ける。具体的には、受付部１３３は、ＵＩ提供部１３１が提供するＵＩを介して、ユーザ端末１０から送信されるテストケースに関する設定を受け付ける。

例えば、受付部１３３は、検証を行おうとするＡＰＩである検証対象ＡＰＩの指定を受け付ける。また、受付部１３３は、検証対象ＡＰＩにおける配列や変数の環境情報（例えば、フィールド等）の設定を受け付ける。

また、受付部１３３は、検証対象ＡＰＩと、当該検証対象ＡＰＩが実行される際に利用する参照情報を戻り値として返す関係にある他のＡＰＩとの階層関係についての指定を受け付ける。すなわち、受付部１３３は、ユーザから指定された検証対象ＡＰＩがウェブＡＰＩであり、参照情報等を利用して処理を実行する階層関係にあるＡＰＩがある場合には、かかる指定をユーザから受け付ける。かかる階層関係は、後述する設定部１３４により設定される。

また、受付部１３３は、テストとして実行するＡＰＩの処理の種別（メソッド）について受け付ける。例えば、受付部１３３は、メソッドとして「ａｄｄ」や「ｓｅｔ」といった具体的なメソッドの指定を受け付ける。また、受付部１３３は、ＡＰＩリファレンス（API Reference）を受け付け、かかるＡＰＩリファレンスに対応するテストパターンを受け付ける。

テストパターンは、テストの際に検証対象ＡＰＩに入力される情報であり、予め検証プログラムによっていくつかのパターンが用意される。例えば、テストパターンとして、入力情報として「必須項目×デフォルト値」や、「必須項目×最小値」などのパターンが予め準備される。一例として、「必須項目×デフォルト値」であれば、ＡＰＩにおいて入力が必須となっている項目に対してデフォルト値が入力されている、という状況を示したテストパターンとなる。

（設定部１３４について）
設定部１３４は、受付部１３３によって受け付けられた情報に基づいてテストケースを作成するための設定を行う。例えば、設定部１３４は、検証対象ＡＰＩと、当該検証対象ＡＰＩが実行される際に利用する参照情報を戻り値として返す関係にある他のＡＰＩとの階層関係についての設定を行う。

設定部１３４によって階層関係が設定されたテストケースは、検証対象ＡＰＩのテストを実行するときに、階層関係に基づく処理を行うことができる。例えば、検証対象ＡＰＩが参照情報を利用するスクリプト（script）を実行する場合、参照情報を取得していなければ、結果としてエラーが返される。一方、設定部１３４によって階層関係が設定されたテストケースを用いて検証対象ＡＰＩが実行される場合、実行されるスクリプトには、上位階層のＡＰＩを呼び出して取得された参照情報が入力される。これにより、検証プログラムは、検証対象ＡＰＩに対する処理について、エラーを発生させずに行うことができる。

また、設定部１３４は、検証対象ＡＰＩに対する階層関係の順序を示す情報である階層レベルをＡＰＩごとに設定することが可能である。例えば、検証対象ＡＰＩが参照する戻り値を発行するＡＰＩの更に上層のＡＰＩが存在する場合には、設定部１３４は、更に上層のＡＰＩを「階層レベル１」とし、検証対象ＡＰＩが参照する戻り値を発行するＡＰＩを「階層レベル２」と設定することができる。すなわち、設定部１３４は、検証対象ＡＰＩについて多層的な関係性を設定することができる。

このように、受付部１３３及び設定部１３４による処理に基づいて、作成部１３２は、ユーザが所望するテストケースを作成する。また、作成部１３２は、作成されたテストケースをテストケース記憶部１２２に格納する。

（検証部１３５について）
検証部１３５は、検証対象となるＡＰＩを検証する。例えば、検証部１３５は、設定部１３４によって設定された階層関係に基づき、上位の階層にあるＡＰＩを呼び出すことにより上位の階層にあるＡＰＩから発行される参照情報を取得し、取得された参照情報及び作成部１３２によって作成されたテストケースを用いて、検証対象ＡＰＩを検証する。

なお、検証部１３５は、設定部１３４によって検証対象ＡＰＩに対する階層関係の順序を示す情報である階層レベルが設定された上層のＡＰＩがある場合には、設定部１３４によって設定された階層レベルが上位の順に上層のＡＰＩを呼び出すことにより参照情報を取得し、取得された参照情報を用いて検証対象ＡＰＩを検証する。具体的には、検証部１３５は、検証対象ＡＰＩに対して上位階層となる複数のＡＰＩが設定されている場合には、階層レベルの最上位のＡＰＩを呼び出す（実行する）ことで参照情報を取得し、取得された参照情報を利用して、次の階層レベルのＡＰＩを呼び出す。すなわち、検証部１３５は、設定された階層レベルが上位の順に他のＡＰＩを呼び出し、参照情報として、下位で必要な上位設定を予め登録する。例えば、検証部１３５は、上位のＡＰＩから取得される参照情報をテストケース記憶部１２２に登録（格納）する。そして、検証部１３５は、登録された参照情報を用いて、より下位のＡＰＩを呼び出す。検証部１３５は、かかる処理を繰り返すことで、最終的に検証対象ＡＰＩで利用する参照情報を取得し、取得された参照情報を用いて検証対象ＡＰＩを検証する。図２に示すように、検証部１３５は、実行部１３６と、格納部１３７とを有する。

（実行部１３６について）
実行部１３６は、検証対象ＡＰＩに対する検証処理を実行する。例えば、実行部１３６は、作成部１３２によって作成されたテストケースに従い、検証対象ＡＰＩに対して所定の入力を行う。そして、実行部１３６は、入力された情報に対する検証対象ＡＰＩからの出力を得る。言い換えれば、実行部１３６は、テストパターンごとに定義されたテストを検証対象ＡＰＩに実行し、結果を得る。

実行部１３６は、上述のように、階層関係が設定されたＡＰＩに対しては、上層のＡＰＩから参照情報を取得しながら、検証対象ＡＰＩに対するテストを実行していく。そして、実行部１３６は、１つのテストパターンから参照情報ごとに派生するテスト結果を取得する。すなわち、実行部１３６によれば、階層関係に応じて出力が変化する結果についても取得できるので、ユーザは、網羅的に検証対象ＡＰＩの挙動に関する結果を得ることができる。また、実行部１３６は、設定部１３４によって設定された階層関係に基づいて、自動的に上層のＡＰＩを呼び出して参照情報を得ることができるので、ユーザは、効率的に漏れのないテスト結果を得ることができる。

（格納部１３７について）
格納部１３７は、実行部１３６によって実行された検証処理の結果を格納する。具体的には、格納部１３７は、テストケースに従って実行された各々のテストパターンの結果をテスト結果記憶部１２３に格納する。

〔３．処理の一例〕
上記、検証プログラムを実行する検証装置１００の構成について説明した。以下では、検証装置１００が実行する検証処理の一例として、具体的に、ユーザが広告に係るＡＰＩの一例である「広告ＡＰＩ」を利用する例を示すとともに、かかる広告ＡＰＩの検証が行われる処理について、ユーザ端末１０に表示されるＵＩとともに説明する。以下の説明においては、検証装置１００からユーザ端末１０にＵＩが提供されており、ユーザは、ＵＩを介して、ユーザ端末１０で実行可能なツールとして検証プログラムを利用する例を想定する。

まず、図３乃至図６を用いて、検証対象ＡＰＩの一例として、広告に係るＡＰＩに関する概要を説明する。広告に係るＡＰＩは、ウェブネットワークを介して所定のユーザに利用される機能を提供するＡＰＩの一例であり、より詳しくは、ウェブネットワーク上で配信される広告の設定を受け付ける機能を提供するＡＰＩである。例えば、広告に係るＡＰＩは、ユーザ（例えば、広告主）が広告を配信させようとする場合に利用するウェブＡＰＩであり、所定の階層関係を有するものとする。

実施形態においては、広告に係るＡＰＩは、アカウントの設定等を行う「アカウントＡＰＩ」、広告の全体予算等の設定を行う「キャンペーンＡＰＩ」、詳細な入札価格等の設定を行う「広告グループＡＰＩ」、具体的な広告コンテンツの設定を行う「広告ＡＰＩ」の順に階層関係を有するものとする。すなわち、アカウントＡＰＩは、キャンペーンＡＰＩに対して上位である。また、キャンペーンＡＰＩは、広告グループＡＰＩに対して上位である。また、広告グループＡＰＩは、広告ＡＰＩに対して上位である。

まず、ユーザは、アカウントＡＰＩを利用し、アカウントの設定を行ったものとする。続いて、ユーザは、キャンペーンＡＰＩを利用する。図３は、実施形態に係るキャンペーンＡＰＩを説明する図である。キャンペーンＡＰＩは、広告に係るウェブＡＰＩの１つであり、例えば、所定の実行サーバ２０から提供される。ユーザは、キャンペーンＡＰＩを利用する場合、表示画面３１に表示される所定のＵＩを用いて、画面内の項目に情報を入力する。これにより、ユーザは、広告に係るキャンペーンを設定できる。表示画面３１において、「＊」が表示される項目は、入力が必須である必須項目を示す。例えば、表示画面３１において、「キャンペーン名」が入力されていない場合、キャンペーンＡＰＩは、エラーを返す。表示画面３１において、「＊」が表示されていない項目は、入力が必須でない任意項目を示す。任意項目の場合、項目に情報が入力されていなくても、エラーとならない場合がある。また、表示画面３１において、「入札方法」や、「配信方法」を選択するためのラジオボタンが設けられている。かかる選択によって、キャンペーンＡＰＩが戻り値として発行する参照情報が変化する場合がある。

そして、ユーザは、キャンペーンＡＰＩを利用し、キャンペーンの設定を行ったものとする。続いて、ユーザは、広告グループＡＰＩを利用する。図４は、実施形態に係る広告グループＡＰＩを説明する図である。ユーザは、広告グループＡＰＩを利用する場合、表示画面３２に表示される所定のＵＩを用いて、画面内の項目に情報を入力する。これにより、ユーザは、配信させようとする広告コンテンツの上位概念である広告グループを作成することができる。なお、図４に示すように、表示画面３２にも表示画面３１と同様、必須項目や、任意項目や、選択項目が存在する。

そして、ユーザは、広告グループＡＰＩを利用し、広告グループの設定を行ったものとする。続いて、ユーザは、広告ＡＰＩを利用する。図５は、実施形態に係る広告グループＡＰＩを説明する図（１）である。図５に示すように、ユーザは、広告ＡＰＩにおいて、表示画面３３のようなＵＩを介して、広告コンテンツに係るキーワードを入力することができる。広告コンテンツに係るキーワードは、例えば、検索処理の際に検索クエリとして用いられる。

ユーザは、キーワードの設定を行った場合、次の設定を行う。図６は、実施形態に係る広告グループＡＰＩを説明する図（２）である。図６に示すように、ユーザは、広告ＡＰＩにおいて、表示画面３４のようなＵＩを介して、広告コンテンツに係る詳細な設定を行う。なお、広告ＡＰＩにおいて、ユーザが配信を希望する広告コンテンツの種別によって、広告ＡＰＩの処理が変化する場合がある。例えば、ユーザは、広告ＡＰＩにおいて、テキストによる広告コンテンツを作成するか、あるいは、例えばスマートフォン等で動作するアプリ用の広告コンテンツを作成するかを選択できる。このようにＡＰＩの処理が２通りある場合、後述するテストケースに影響を与える場合がある。

以上、図３乃至図６を用いて、広告に係るＡＰＩについて説明した。続いて、図７乃至図１１を用いて、検証装置１００で実行される検証プログラムが広告ＡＰＩを検証する処理の一例について説明する。

図７は、実施形態に係る作成処理を説明する図（１）である。図７では、広告ＡＰＩに関するテストケースを作成するための処理の流れを示している。

まず、ユーザは、テストを実行するシステムを選択する（ステップＳ２１）。ここでは、システムとは、種々のＡＰＩを管理するためのカテゴリを示す。実施形態においては、システム「ｂｌｔａｐｉ」において、検証に係るＡＰＩが管理されているものとする。

続いて、ユーザは、検証を行うサービス（ＡＰＩ）を選択する（ステップＳ２２）。ここでは、ユーザは、４つのサービスのうち、検証を行うＡＰＩとして広告ＡＰＩ（図７では「ａｄＧｒｏｕｐａｄ」と表記）を選択する。

そして、ユーザは、サービスに関するフィールド（Ｆｉｅｌｄ）、そのフィールドに係る状態（Ｖａｌｕｅ）などを適宜選択する（ステップＳ２３、２４）。なお、かかる処理は、サービスを選択した時点で、自動で行われてもよい。すなわち、検証装置１００は、ＡＰＩに係る情報を取得した時点で、各々のＡＰＩの変数や配列に関する情報を取得し、サービスが選択された時点で、取得していた情報を適用することで、各サービスに対するフィールド等が読み込まれる。

そして、ユーザは、サービスに関する上位階層の設定を行う（ステップＳ２５）。図７において、階層関係は「Ｃｈａｉｎ」という項目で示されている。すなわち、ユーザは、サービス「ａｄＧｒｏｕｐａｄ」の上位階層のサービスとして、「ａｃｃｃｏｕｎｔ」、「ｃａｍｐａｉｎ」、「ａｄＧｒｏｕｐ」を指定し、階層関係を設定させる。なお、図７の「ａｃｃｃｏｕｎｔ」、「ｃａｍｐａｉｎ」、「ａｄＧｒｏｕｐ」という表記は、上述の広告に係るＡＰＩとして説明した「アカウントＡＰＩ」、「キャンペーンＡＰＩ」、「広告グループＡＰＩ」にそれぞれ対応する。

なお、検証を行うサービスについて、テストを実施可能なメソッドが複数存在する場合がある（ステップＳ２６）。例えば、サービス「ａｄＧｒｏｕｐａｄ」では、メソッドとして「ａｄｄ」、「ｓｅｔ」、「ｒｅｍｏｖｅ」、「ｇｅｔ」が選択可能である。かかるメソッドは、テストが実行される際にユーザによって選択される。そして、ユーザは、サービス「ａｄＧｒｏｕｐａｄ」のＡＰＩリファレンスを設定する（ステップＳ２７）。かかるＡＰＩリファレンスについても、検証装置１００は、各々のＡＰＩに対して設定された情報を事前に取得することができる。

そして、ユーザは、検証処理で実行されるテストパターンを選択する（ステップＳ２８）。一例として、ユーザは、サービス「ａｄＧｒｏｕｐａｄ」に対するテストパターンとして、「必須項目×デフォルト値」、「必須項目×最小値」といった入力項目を選択する（図７では、それぞれ「ｒｅｑｕｉｒｅｄ×ｄｅｆａｕｌｔ」、「ｒｅｑｕｉｒｅｄ×ｍｉｎ」と表記）。

そして、ステップＳ２１〜Ｓ２８の項目で選択された情報に基づいて、作成部１３２は、テストケースを作成する（ステップＳ２９）。なお、上述のように、広告ＡＰＩは、テキスト広告と、アプリ用広告という２種類の広告を作ることが可能であり、かかる処理は異なる処理により行われる。そのため、作成部１３２は、テキスト広告と、アプリ用広告という２種類の処理に対応したテストケースをそれぞれ自動的に作成する。

ここで、上記のようにユーザが設定する処理を、ＵＩを模した図を用いて説明する。図８は、実施形態に係る作成処理を説明する図（２）である。図８では、ユーザがＵＩを介して、サービス「ａｄＧｒｏｕｐａｄ」に階層関係を指定する例を示している。例えば、ＵＩは、ユーザ端末１０が有する表示部４１に表示される。

ユーザは、サービス「ａｄＧｒｏｕｐａｄ」の「上位階層設定」という項目を選択することで、上位階層の設定に用いる表４１０を表示させることができる。表４１０に示すように、サービス「ａｄＧｒｏｕｐａｄ」に対して、「階層レベル Ｌｅｖｅｌ−１」として、「Ａｃｃｏｕｎｔ」が設定されている。なお、「階層レベル」の項目は、数字が小さいほど上位を示す。同様に、サービス「ａｄＧｒｏｕｐａｄ」に対して、「階層レベル Ｌｅｖｅｌ−２」として「ｃａｍｐａｉｎ」が、「階層レベル Ｌｅｖｅｌ−３」として「ａｄＧｒｏｕｐ」が、それぞれ設定されている。このように、ユーザは、ＵＩを介して、サービス「ａｄＧｒｏｕｐａｄ」に対する階層関係を指定する。受付部１３３は、かかる指定を受け付け、設定部１３４は、かかる指定に基づいて、階層関係を設定する。

続いて、テストパターンの例について、ＵＩを模した図を用いて説明する。図９は、実施形態に係る作成処理を説明する図（３）である。図９では、ユーザがＵＩを介して、テストパターンを指定する例を示している。

図７では、ユーザは、「必須項目×デフォルト値」、「必須項目×最小値」という２つのテストパターンを選択する例を示した。実際には、ユーザは、図９に示すように、多数用意されたテストパターンから、テストパターンを任意に選択することができる。

また、図９に示すように、テストパターンには「期待結果」という項目が存在する。これは、テストパターンとして情報が入力された場合に、その入力に対して、ＡＰＩが「成功」と返すことが望ましいのか、「失敗」と返すことが望ましいのかを選択する項目である。例えば、ＡＰＩは、「必須項目×デフォルト値」の場合、処理が可能な値が必須項目に入力されているので、「成功」を返すことが望まれる。一方、ＡＰＩは、「必須項目×入力なし」の場合、必須項目に値が入力されていないため、「失敗（エラー）」を返すのが望ましい。このように、検証装置１００は、予め想定されるテストパターンと期待結果を記憶する。そして、ユーザは、かかるテストパターンを選択することにより、行いたいテストを効率良く行うことができる。なお、ユーザは、テストパターンを任意に作成してもよい。この場合、受付部１３３は、かかるテストパターンの作成を受け付ける。設定部１３４は、新たに作成されたテストパターンを設定する。

上記のように、ユーザがテストを行うＡＰＩを選択し、テストに係る情報を選択することにより、作成部１３２によってテストケースが作成される。

続いて、図１０乃至図１２を用いて、作成部１３２によって作成されたテストケースを用いて、検証対象ＡＰＩを検証する処理について説明する。まず、図１０を用いて、テストを行うにあたってユーザが指定するテスト環境について説明する。

図１０は、実施形態に係る検証処理を説明する図（１）である。図１０では、テストケースを実行する際にユーザが選択する項目について説明する。

まず、ユーザは、テスト環境（図１０では、「Ｅｎｖｉｒｏｎｍｅｎｔ」と表記）を選択する（ステップＳ３１）。テスト環境とは、例えば、検証プログラムを利用するユーザ毎に用意されるテストの環境設定等である。続いて、ユーザは、テストを実行するシステムを選択する（ステップＳ３２）。システムは、図７で示した項目に対応する。

そして、ユーザは、テストを実行するサービス（ＡＰＩ）を選択する（ステップＳ３３）。ここでは、ユーザは、サービスとして「ａｄＧｒｏｕｐａｄ」を選択するものとする。続いて、ユーザは、テストケースを用いて実行するメソッド（図１０では、「Ｅｘｅｃｕｔｅ」と表記）を選択する。ここでは、ユーザは、実行するメソッドとして「ａｄｄ」を選択するものとする。ユーザの選択に基づいて、実行部１３６は、検証対象ＡＰＩに対する検証処理を実行する。

具体的には、実行部１３６は、作成処理において作成された２つのテストケースについて、検証対象ＡＰＩである広告ＡＰＩに対して、指定されたメソッドを実行して、かかる処理が成功であったか、失敗であったかの結果を得る。ここで、実行部１３６は、実行される処理に参照情報が利用される場合には、適宜、上位階層のＡＰＩを呼び出すことで、参照情報を得る。なお、実行部１３６は、最上位のＡＰＩに対する参照情報については、予め所定の参照情報を用意する。例えば、実行部１３６は、広告ＡＰＩに対して最上位であるアカウントＡＰＩに対しては、テストのための所定の参照情報を当て嵌めることで処理を実行する。

そして、実行部１３６によって実行された結果について、格納部１３７は、テスト結果記憶部１２３に格納する。そして、かかる結果は、ＵＩ提供部１３１が提供するＵＩを介して、ユーザに通知される。この点について、図１１を用いて説明する。

図１１は、実施形態に係る検証処理を説明する図（２）である。図１１では、ＵＩを介して、広告ＡＰＩの「ａｄｄ」の実行を行った実行結果が表示される例を示している。図１１に示すように、ＵＩを介して、実行部１３６が行った実行結果がテストパターンごとに表示される。

また、実行部１３６は、１つのテストパターンに対して、上層のＡＰＩが発行した参照情報ごとに実行する。この点について、図１２を用いて説明する。図１２は、実施形態に係る検証処理を説明する図（３）である。図１２では、ＵＩを介して、テストパターン「ＲＥＱＵＩＲＥＤ ＰＡＴＴＥＲＮ」の詳細が表示される状態を示している。

図１２の表４１１では、１つのテストパターンが実行される場合に、いくつのテストケースが実際に検証されたかを示している。上記では、広告ＡＰＩでは、アプリ広告と、テキスト広告の２種類のテストケースが検証されることを説明した。そして、広告ＡＰＩには、上層のＡＰＩであるアカウントＡＰＩと、キャンペーンＡＰＩ、広告グループＡＰＩが設定されているため、各ＡＰＩが発行した参照情報ごとに検証が行われる。

例えば、図１２の表４１１の一例では、「（ａｃｃｏｕｎｔ）ｒｅｑｕｉｒｅｄ×ｄｅｆａｕｌｔ （ｃａｍｐａｉｇｎ） ＡＡＡ×ａａａ （ａｄＧｒｏｕｐ) XXX ＞＞＞ＡＰＰ ＡＤ」というテストケースにより、テストパターン「ＲＥＱＵＩＲＥＤ ＰＡＴＴＥＲＮ」が実行されたことを示している。例えば、「（ｃａｍｐａｉｇｎ） ＡＡＡ×ａａａ」という表記は、キャンペーンＡＰＩが発行する参照情報によって変化する情報を示している。「ＡＡＡ」や「ａａａ」等は、キャンペーンＡＰＩに入力される値によってキャンペーンＡＰＩが発行する参照情報が変化することを概念的に示すものである。一例としては、図３で示した例において、キャンペーンＡＰＩの設定で選択される入札方法の違い（「手動で設定する」か「自動入札を設定する」を選択する違い）などにより、「ＡＡＡ」や「ａａａ」に該当する項目が変化する。

図１２の例では、キャンペーンＡＰＩは「ＡＡＡ×ａａａ」、「ＡＡＡ×ｂｂｂ」、「ＢＢＢ×ａａａ」、「ＢＢＢ×ｂｂｂ」という、４種類の異なる参照情報を発行する場合があることを示している。また、広告グループＡＰＩは、「ＸＸＸ」と、「ＹＹＹ」という２種類の参照情報を発行する場合があることを示している。また、上記のように、広告ＡＰＩは、「ＡＰＰ ＡＤ（アプリ広告）」と、「ＴＥＸＴ ＡＤ（テキスト広告）」の２種類のテストケースを取りうることを示している。このように、実行部１３６は、１つのテストケースであっても、上層のＡＰＩを呼び出して参照情報を取得しながら下層のＡＰＩを実行することにより、網羅的に検証対象ＡＰＩを検証することができる。

なお、上層のＡＰＩの発行した参照情報によって、下層のＡＰＩが取りうる参照情報の数が変わる場合がある。図１２の例では、例えば、キャンペーンＡＰＩが「ＡＡＡ」という選択を行った場合、広告グループＡＰＩは「ＸＸＸ」を取りうるが、「ＹＹＹ」を取りえないという状況がありうる。かかる状況は、ＡＰＩ同士の関係性によるものであり、実行部１３６は、例えば、上層のＡＰＩを実行する過程においてかかる関係性を導出し、ＡＰＩ同士が取りうる選択によって作成されるテストケースを用いて検証を行う。そのため、図１２に示す例においても、テストパターンによっては、詳細情報に８つ以上のテストケースが表示される場合もあり、また、より少ないテストケースが表示される場合もありうる。また、図１２での図示は省略しているが、各処理結果には、検証が行われた時間などの履歴情報が含まれる。ユーザは、かかる履歴情報を参照し、ネットワーク上のＡＰＩが適切に動作しているか、また、ＡＰＩのリンク切れが発生したのがいつ頃なのか、といった情報を把握する管理ツールとして、検証プログラムを用いることができる。

〔４．検証処理手順〕
次に、図１３及び図１４を用いて、実施形態に係る検証装置１００による処理の手順について説明する。図１３は、実施形態に係る検証装置１００による作成処理手順を示すフローチャートである。

図１３に示すように、受付部１３３は、ユーザ端末１０からＡＰＩの設定を受け付ける（ステップＳ１０１）。ここで、ＡＰＩの設定とは、例えば、ＡＰＩの階層関係の設定などをいう。この場合、設定部１３４は、受付部１３３によって受け付けられた内容を設定する。さらに、受付部１３３は、検証対象ＡＰＩで検証する内容として、テストパターンの選択を受け付ける（ステップＳ１０２）。

そして、作成部１３２は、受付部１３３によって受け付けられた内容に基づいて、検証対象ＡＰＩに対するテストケースを作成する（ステップＳ１０３）。作成部１３２は、作成したテストケースをテストケース記憶部１２２に格納し、作成処理を終了する。

次に、図１４を用いて、実施形態に係る検証装置１００による検証処理の手順について説明する。図１４は、実施形態に係る検証装置１００による検証処理手順を示すフローチャートである。

まず、検証部１３５は、ユーザからテスト環境の選択を受け付ける（ステップＳ２０１）。テスト環境の選択とは、図１０に示すような、テストを行うシステム等を特定したり、ＡＰＩに実行させる処理を選択したりすることをいう。

そして、実行部１３６は、検証対象ＡＰＩに対するテストを実行する（ステップＳ２０２）。ここで、実行部１３６は、実行している検証対象ＡＰＩに関して、階層関係が設定されているか否かを判定する（ステップＳ２０３）。具体的には、実行部１３６は、実行しようとするスクリプト内に、参照情報が入るべき空欄の箇所があるか否かを判定し、かかる空欄を埋めることができる上層ＡＰＩからの戻り値（参照情報）を取得することを判定する。

実行部１３６は、階層関係が設定されている場合には（ステップＳ２０３；Ｙｅｓ）、上層のＡＰＩを呼び出し、上層のＡＰＩを実行する（ステップＳ２０４）。そして、実行部１３６は、上層のＡＰＩから発行される戻り値を参照情報として取得する（ステップＳ２０５）。

そして、実行部１３６は、取得した参照情報に基づいて、テストを実行する（ステップＳ２０６）。例えば、実行部１３６は、実行するスクリプト内に参照情報（例えば、数桁の数値などのＩＤとして発行された情報）を代入し、検証対象ＡＰＩの挙動を検証する。

そして、実行部１３６は、テスト結果を取得する（ステップＳ２０７）。なお、検証対象ＡＰＩに階層関係が設定されていない場合には（ステップＳ２０３；Ｎｏ）、実行部１３６は、検証対象ＡＰＩに係るテストケースをそのまま実行し、テスト結果を取得する（ステップＳ２０７）。そして、格納部１３７は、テスト結果をテスト結果記憶部１２３に格納し、検証処理を終了する。

〔５．変形例〕
上述した実施形態に係る検証装置１００によって実施される検証プログラムは、上記実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、上記の検証装置１００及び検証プログラムの他の実施形態について説明する。

〔５−１．ＡＰＩ〕
上記実施形態では、広告に係るＡＰＩについて検証処理を実行する例を示した。しかし、検証装置１００は、広告に係るＡＰＩに限らず、上記処理を行うことができる。例えば、検証装置１００に係る検証プログラムによれば、階層関係を有するようなＡＰＩであり、ＲＥＳＴ（Representational State Transfer）形式で設計されたＡＰＩであれば、いずれも上記の検証処理が適用可能である。

〔５−２．自動設定〕
上記実施形態において、検証装置１００は、ユーザからＡＰＩに関するフィールド等、変数や配列の設定を手動で受け付ける例を示した。ここで、検証装置１００は、ＡＰＩに特定の変換を行うことにより、上記の設定を自動で行うようにしてもよい。

例えば、検証装置１００は、所定の言語間の変換を行うコンバータ（converter）を有することにより、ＡＰＩの設定を自動的に行う。例えば、ＡＰＩの作成者は、特定のプログラミング言語（例えばＪＡＶＡ等）で作成したＡＰＩと、所定のＩＤＬ（Interface Description Language）ファイルを作成する。ＩＤＬファイルは、記載されたソースコードベースでフィールド等を予め定義するファイルである。そして、検証装置１００は、ＩＤＬコンバータを利用することで、フィールド等が定義されたＪＡＶＡソースのＡＰＩが作成される。これにより、ユーザ（または、検証プログラムにおいて事前にＡＰＩの設定を行う提供者）がフィールド等を手動で設定する手間を省くことが可能となる。

〔５−３．実行処理〕
上記実施形態では、実行部１３６が実行する処理において「ａｄｄ」を選択する例を示した。ここで、実行部１３６は、ユーザから「ｓｅｔ」等の命令が選択された際には、予め検証対象ＡＰＩを実行し、所定の戻り値を得てから検証を行うようにしてもよい。これは、「ｓｅｔ」は、所定の値を置き換える処理であり、置き換える対象となる値が存在しない場合には、検証処理を行うことができないことによる。このため、実行部１３６は、予め検証対象ＡＰＩを動作させることで、「ｓｅｔ」の対象となる戻り値を取得しておき、かかる戻り値を利用して検証処理を実行することができる。

〔５−４．上位関係〕
ＡＰＩにおいては、上位関係に応じて、下層のＡＰＩが取りうる処理の数が決まる場合がある。実施形態における広告に係るＡＰＩを用いて、具体的に説明する。例えば、キャンペーンＡＰＩでは、ＡＰＩの管理者等によって作成できるキャンペーンの数が決められている場合がある。これは、例えば、実際のＡＰＩの運用で支障をきたさぬよう、ＡＰＩに予め設定される。例えば、キャンペーンＡＰＩでは、作成できるキャンペーンの数に「１００」という上限値が定められているものとする。この場合、実行されるテストケースが「１００」を超える場合には、検証処理においてエラーが発生する。これは、検証処理においてＡＰＩが実行される際には実際にキャンペーンの作成処理が行われるため、設定された上限値を超えた処理を行うことができないことによる。しかしながら、テストケースは上層のＡＰＩが発行する参照情報の組合せにより増大するため、ユーザは、テストを実行する際に、上記のような上限値の条件を満たしているかを判断することが困難である。

この場合、実行部１３６は、所定の回避手段を行い、検証処理にエラーが発生しないよう調整する。一例として、実行部１３６は、キャンペーンＡＰＩの上位にあるアカウントＡＰＩで発行する参照情報について、テストケースが行える数を満たすよう発行させる。例えば、アカウントＡＰＩで２種類の参照情報が発行された場合、実行部１３６は、各々でキャンペーンＡＰＩに対する処理を行うことができるため、キャンペーンＡＰＩで作成されるキャンペーンの数を「２００」にすることができる。このように、実行部１３６は、上層のＡＰＩで発行される参照情報を調整することにより、作成されるテストケースが増大した場合であっても、エラーを発生させずにテストを行うことができる。

〔６．その他〕
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

例えば、図２に示した記憶部１２０は、検証装置１００が保持せずに、所定のストレージサーバ等に保持されてもよい。この場合、検証装置１００は、ストレージサーバにアクセスすることで、格納されている各種情報を取得する。

また、例えば、上述してきた検証装置１００は、ＵＩを介してユーザ端末１０との情報の送受信を中心に行うフロントエンドサーバ側と、実際にＡＰＩのテストを実行するバックエンドサーバ側に分散されてもよい。また、検証装置１００と実行サーバ２０は一体に構成されてもよい。この場合、検証装置１００は、所定のＡＰＩを自ら保持し、かかるＡＰＩを実行部１３６に実行させる。

〔７．ハードウェア構成〕
また、上述してきた実施形態に係る検証装置１００は、例えば図１５に示すような構成のコンピュータ１０００によって実現される。図１５は、検証装置１００の機能を実現するコンピュータ１０００の一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＡＭ１２００、ＲＯＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、及びメディアインターフェイス（Ｉ／Ｆ）１７００を有する。

ＣＰＵ１１００は、ＲＯＭ１３００又はＨＤＤ１４００に格納されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１３００は、コンピュータ１０００の起動時にＣＰＵ１１００によって実行されるブートプログラムや、コンピュータ１０００のハードウェアに依存するプログラム等を格納する。

ＨＤＤ１４００は、ＣＰＵ１１００によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を記憶する。通信インターフェイス１５００は、通信網５００（実施形態における所定の通信ネットワークに対応する）を介して他の機器からデータを受信してＣＰＵ１１００へ送り、また、通信網５００を介してＣＰＵ１１００が生成したデータを他の機器へ送信する。

ＣＰＵ１１００は、入出力インターフェイス１６００を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。ＣＰＵ１１００は、入出力インターフェイス１６００を介して、入力装置からデータを取得する。また、ＣＰＵ１１００は、入出力インターフェイス１６００を介して生成したデータを出力装置へ出力する。

メディアインターフェイス１７００は、記録媒体１８００に格納されたプログラム又はデータを読み取り、ＲＡＭ１２００を介してＣＰＵ１１００に提供する。ＣＰＵ１１００は、かかるプログラムを、メディアインターフェイス１７００を介して記録媒体１８００からＲＡＭ１２００上にロードし、ロードしたプログラムを実行する。記録媒体１８００は、例えばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。

例えば、コンピュータ１０００が検証装置１００として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラムを実行することにより、制御部１３０の機能を実現する。また、ＨＤＤ１４００には、記憶部１２０内の各データが格納される。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを記録媒体１８００から読み取って実行するが、他の例として、他の装置から通信網５００を介してこれらのプログラムを取得してもよい。

〔８．効果〕
上述してきたように、実施形態に係る検証装置１００は、作成部１３２と、設定部１３４と、検証部１３５とを有する。作成部１３２は、検証対象である検証対象ＡＰＩに対して実行されるテストケースを作成する。設定部１３４は、検証対象ＡＰＩと、当該検証対象ＡＰＩが実行される際に利用する情報である参照情報を戻り値として返す関係にある他のＡＰＩとの階層関係の設定を行う。検証部１３５は、設定部１３４によって設定された階層関係に基づき、上位の階層にある他のＡＰＩを呼び出すことにより参照情報を取得し、取得された参照情報及びテストケースを用いて検証対象ＡＰＩを検証する。なお、上記の検証装置１００による処理は、本願に係る検証プログラムが検証装置１００の制御部１３０に係る各処理を実行させることにより行われる。

このように、実施形態に係る検証装置１００は、階層関係など相互に関係を有するＡＰＩの検証処理を効率良く行うことができる。すなわち、テストを実施させるユーザは、検証対象ＡＰＩの階層関係を設定することで、上位階層のＡＰＩがとりうる戻り値の組合せ等を意識することなく、検証対象ＡＰＩに対するテストを実行させることができる。このように、検証装置１００は、階層関係を有するＡＰＩに対して、網羅的な検証を効率良く行うことができる。

また、設定部１３４は、検証対象ＡＰＩに対する階層関係の順序を示す情報である階層レベルをＡＰＩごとに設定する。そして、検証部１３５は、設定部１３４によって設定された階層レベルが上位の順に他のＡＰＩを呼び出し、より下位の階層レベルに対応するＡＰＩが利用する参照情報を取得し、取得された参照情報を用いて検証対象ＡＰＩを検証する。

このように、実施形態に係る検証装置１００は、ＡＰＩが多層的な関係を有する場合であっても、かかる関係の定義を受け付けることにより、検証対象ＡＰＩの検証を行うことができる。これにより、検証装置１００によれば、１つのテストパターンから参照情報ごとに派生するテスト結果を網羅的に取得することができるため、漏れのない効率的な処理を行うことができる。

また、実施形態に係る検証装置１００は、検証部１３５によって検証された結果を表示するＵＩを提供するＵＩ提供部１３１（提供部の一例）をさらに有する。ＵＩ提供部１３１は、ＵＩを介して、検証対象ＡＰＩの検証結果と併せて、検証対象ＡＰＩの検証に用いられた他のＡＰＩ（例えば、検証対象ＡＰＩとの階層関係が設定されたＡＰＩ）に関する情報を提供する。

このように、実施形態に係る検証装置１００は、ユーザが検証結果を閲覧することが可能なＵＩを提供する。これにより、検証装置１００によれば、相互に関係を有するような複雑な検証を要するＡＰＩであっても、視覚的な情報に基づいて管理を行わせることができるので、ユーザの管理にかかる負担を軽減させることができる。また、検証装置１００によれば、検証結果として他のＡＰＩの情報についても提供できるので、人的に管理することが困難であったＡＰＩ同士の関連性を容易に把握させることができる。

なお、検証対象ＡＰＩは、ウェブネットワークを介して所定のユーザに利用される機能を提供するＡＰＩであってもよい。

検証装置１００によれば、上述のように、階層関係を有するウェブＡＰＩについて網羅的な検証を行うことができる。これにより、検証装置１００は、例えば、ＡＰＩが保持されているサーバの動作不備や、リンク切れなどを容易にユーザに把握させることができ、ウェブネットワークを介して利用するＡＰＩに対する利便性を向上させることができる。

また、検証対象ＡＰＩは、ウェブネットワーク上で配信される広告の設定を受け付ける機能を提供するＡＰＩであってもよい。

検証装置１００によれば、例えば、広告主が配信させようとする広告の種類（入札価格の自動設定、手動設定などの選択や、テキスト広告であるか否かなど）を設定するＡＰＩについての網羅的な検証を行うことができるため、広告主や、広告配信会社にとって、ＡＰＩの管理を効率良く行わせることができる。

以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。

また、上述した検証装置１００は、複数のサーバコンピュータで実現してもよく、また、機能によっては外部のプラットフォーム等をＡＰＩ（Application Programming Interface）やネットワークコンピューティングなどで呼び出して実現するなど、構成は柔軟に変更できる。

また、特許請求の範囲に記載した「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、検証部は、検証手段や検証回路に読み替えることができる。

１ 検証システム
１０ ユーザ端末
２０ 実行サーバ
１００ 検証装置
１１０ 通信部
１２０ 記憶部
１２１ ＡＰＩ情報記憶部
１２２ テストケース記憶部
１２３ テスト結果記憶部
１３０ 制御部
１３１ ＵＩ提供部
１３２ 作成部
１３３ 受付部
１３４ 設定部
１３５ 検証部
１３６ 実行部
１３７ 格納部

Claims (7)

1. 検証対象である検証対象ＡＰＩ（Application Programming Interface）に対して実行されるテストケースを作成する作成手順と、
   前記検証対象ＡＰＩと、当該検証対象ＡＰＩが実行される際に利用する情報である参照情報を戻り値として返す関係にある他のＡＰＩとの階層関係の設定を行う設定手順と、
   前記設定手順によって設定された階層関係に基づき、上位の階層にある前記他のＡＰＩを呼び出すことにより前記参照情報を取得し、取得された前記参照情報及び前記テストケースを用いて検証対象ＡＰＩを検証する検証手順と、
   をコンピュータに実行させることを特徴とする検証プログラム。
2. 前記設定手順は、
   前記検証対象ＡＰＩに対する階層関係の順序を示す情報である階層レベルを前記他のＡＰＩごとに設定し、
   前記検証手順は、
   前記設定手順によって設定された階層レベルが上位の順に前記他のＡＰＩを呼び出し、より下位の階層レベルに対応するＡＰＩが利用する参照情報を取得し、取得された参照情報を用いて前記検証対象ＡＰＩを検証する、
   ことを特徴とする請求項１に記載の検証プログラム。
3. 前記検証手順によって検証された結果を表示するＵＩ（User Interface）を提供する提供手順、
   をさらに含み、
   前記提供手順は、
   前記ＵＩを介して、前記検証対象ＡＰＩの検証結果と併せて、前記検証対象ＡＰＩの検証に用いられた前記他のＡＰＩに関する情報を提供する、
   ことを特徴とする請求項１又は２に記載の検証プログラム。
4. 前記検証対象ＡＰＩは、ウェブネットワークを介して所定のユーザに利用される機能を提供するＡＰＩである、
   ことを特徴とする請求項１〜３のいずれか一つに記載の検証プログラム。
5. 前記検証対象ＡＰＩは、ウェブネットワーク上で配信される広告の設定を受け付ける機能を提供するＡＰＩである、
   ことを特徴とする請求項１〜４のいずれか一つに記載の検証プログラム。
6. 検証対象である検証対象ＡＰＩに対して実行されるテストケースを作成する作成部と、
   前記検証対象ＡＰＩと、当該検証対象ＡＰＩが実行される際に利用する情報である参照情報を戻り値として返す関係にある他のＡＰＩとの階層関係の設定を行う設定部と、
   前記設定部によって設定された階層関係に基づき、上位の階層にある前記他のＡＰＩを呼び出すことにより前記参照情報を取得し、取得された前記参照情報及び前記テストケースを用いて検証対象ＡＰＩを検証する検証部と、
   を備えることを特徴とする検証装置。
7. コンピュータが実行する検証方法であって、
   検証対象である検証対象ＡＰＩに対して実行されるテストケースを作成する作成工程と、
   前記検証対象ＡＰＩと、当該検証対象ＡＰＩが実行される際に利用する情報である参照情報を戻り値として返す関係にある他のＡＰＩとの階層関係の設定を行う設定工程と、
   前記設定工程によって設定された階層関係に基づき、上位の階層にある前記他のＡＰＩを呼び出すことにより前記参照情報を取得し、取得された前記参照情報及び前記テストケースを用いて検証対象ＡＰＩを検証する検証工程と、
   を含むことを特徴とする検証方法。

Images