(57)【要約】【課題】外部のＡＰＩを利用して動作する開発アプリケーションのテスト工程を実施する際、良否が明確となるテスト結果を容易かつ確実に得られるようにする。【解決手段】テスト装置１は、蓄積部４と、アプリ２からＡＰＩリクエストを取得して蓄積部４に蓄積するとともに外部のＡＰＩを介してイネーブラ５に転送するＡＰＩリクエスト処理部１１と、外部のＡＰＩを介してＡＰＩレスポンスをイネーブラ５から受信して蓄積部４に蓄積するように処理するＡＰＩレスポンス処理部１２と、テストリクエストをアプリ２から取得して蓄積部４を検索するテストリクエスト処理部１３と、テストリクエストに一致するＡＰＩリクエストに関連付けられているＡＰＩレスポンスを蓄積部４から取得し、テストレスポンスとしてアプリ２に返すテストレスポンス処理部１４と、蓄積部４のＡＰＩレスポンスを必要に応じて書き換えるテストレスポンス操作部１５を備える。【選択図】図１
2016149043.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションの動作確認を行うテスト装置であって、
外部のＡＰＩ（Application Programming Interface）を介してイネーブラに転送されるＡＰＩリクエスト、および、前記ＡＰＩリクエストに対応するＡＰＩレスポンスを関連付けて蓄積可能な蓄積部と、
前記アプリケーションから前記ＡＰＩリクエストを取得して前記蓄積部に蓄積するとともに前記イネーブラに転送するＡＰＩリクエスト処理部と、
前記ＡＰＩリクエストに対応するＡＰＩレスポンスを前記イネーブラから受信して前記蓄積部に蓄積するように処理するＡＰＩレスポンス処理部と、
前記アプリケーションに対して所定のテストを行うためのテストリクエストを前記アプリケーションから取得して前記蓄積部を検索するテストリクエスト処理部と、
前記テストリクエストに一致する前記ＡＰＩリクエストに関連付けられている前記ＡＰＩレスポンスを前記蓄積部から取得し、前記取得したＡＰＩレスポンスをテストレスポンスとして前記アプリケーションに返すテストレスポンス処理部と、
前記蓄積部のＡＰＩレスポンスを必要に応じて書き換えるテストレスポンス操作部を備えることを特徴とするテスト装置。
【請求項２】
外部のＡＰＩを介してイネーブラに転送されるＡＰＩリクエスト、および、前記ＡＰＩリクエストに対応するＡＰＩレスポンスを関連付けて蓄積可能な蓄積部、を備え、アプリケーションの動作確認を行うテスト装置におけるテスト方法であって、
前記アプリケーションから前記ＡＰＩリクエストを取得して前記蓄積部に蓄積するとともに前記イネーブラに転送するＡＰＩリクエスト処理ステップと、
前記ＡＰＩリクエストに対応するＡＰＩレスポンスを前記イネーブラから受信して前記蓄積部に蓄積するように処理するＡＰＩレスポンス処理ステップと、
前記アプリケーションに対して所定のテストを行うためのテストリクエストを前記アプリケーションから取得して前記蓄積部を検索するテストリクエスト処理ステップと、
前記テストリクエストに一致する前記ＡＰＩリクエストに関連付けられている前記ＡＰＩレスポンスを前記蓄積部から取得し、前記取得したＡＰＩレスポンスをテストレスポンスとして前記アプリケーションに返すテストレスポンス処理ステップと、
前記蓄積部のＡＰＩレスポンスを必要に応じて書き換えるテストレスポンス操作ステップを備えることを特徴とするテスト方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーション（ソフトウェア）開発における技術に関する。
【背景技術】
【０００２】
新たに開発しようとするアプリケーションに対して、リリース前にテストを行う必要があり、アプリケーション開発のテスト工程の効率化が求められている。近年のアプリケーションは、他社が提供するＡＰＩ（Application Programming Interface。特に、WebAPI（詳細は、例えば、非特許文献１を参照）。）を利用して動作するものが多い。なお、他社が提供するＡＰＩを「外部のＡＰＩ」と称する場合がある。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】水野貴明  著、「Web API: The Good Parts」、初版、株式会社オライリー・ジャパン、２０１４年１１月１９日
【発明の概要】
【発明が解決しようとする課題】
【０００４】
他社提供のＡＰＩを利用して動作する開発アプリケーションに対して、良否が明確となるテスト結果を得るためには、他社提供のＡＰＩを利用した形態のテスト工程を実施することが本来好ましい。しかし、他社提供のＡＰＩは、すでにリリース済みの本番環境のＡＰＩであって、テスト工程にてそのような本番環境のＡＰＩを利用すると、そのＡＰＩを提供する他社のサーバに相当程度の負荷がかかってしまう。このため、相当量の不具合が含まれていると推定されるアプリケーションをテストするためにそのような本番環境のＡＰＩを利用すると、そのＡＰＩを提供する他社のサーバにかかる負荷が増大する可能性があり、そのＡＰＩを介してアプリケーションがアクセスするイネーブラや、そのイネーブラにアクセスする他のアプリケーションを利用するユーザ（端末）に相当程度の影響が生じる可能性がある。
【０００５】
このような状況に鑑みて、本番環境のＡＰＩの代替手段として、ＡＰＩモックを導入し、開発アプリケーションに対するテストを行う方法が一応考えられる。しかし、ＡＰＩモックは、本番環境のＡＰＩと比較して性能が低いため、アプリケーションからのリクエストに対して固定値のレスポンスしか返すことができない。このため、ＡＰＩモックを用いたテストによって得られるテスト結果は、極めて限定的であり、シナリオテストや連結テストなどにはフレキシブルに対応できない。ＡＰＩモックの再設定を手動で行い、所望のレスポンスを得る方法もあるが煩雑であり、容易でない。
【０００６】
そこで、本発明は、上記事情に鑑みて、外部のＡＰＩを利用して動作する開発アプリケーションのテスト工程を実施する際、良否が明確となるテスト結果を容易かつ確実に得られるようにすることを課題とする。
【課題を解決するための手段】
【０００７】
前記課題を解決するために、請求項１の発明は、アプリケーションの動作確認を行うテスト装置であって、外部のＡＰＩ（Application Programming Interface）を介してイネーブラに転送されるＡＰＩリクエスト、および、前記ＡＰＩリクエストに対応するＡＰＩレスポンスを関連付けて蓄積可能な蓄積部と、前記アプリケーションから前記ＡＰＩリクエストを取得して前記蓄積部に蓄積するとともに前記イネーブラに転送するＡＰＩリクエスト処理部と、前記ＡＰＩリクエストに対応するＡＰＩレスポンスを前記イネーブラから受信して前記蓄積部に蓄積するように処理するＡＰＩレスポンス処理部と、前記アプリケーションに対して所定のテストを行うためのテストリクエストを前記アプリケーションから取得して前記蓄積部を検索するテストリクエスト処理部と、前記テストリクエストに一致する前記ＡＰＩリクエストに関連付けられている前記ＡＰＩレスポンスを前記蓄積部から取得し、前記取得したＡＰＩレスポンスをテストレスポンスとして前記アプリケーションに返すテストレスポンス処理部と、前記蓄積部のＡＰＩレスポンスを必要に応じて書き換えるテストレスポンス操作部を備えることを特徴とする。
【０００８】
また、請求項２の発明は、外部のＡＰＩを介してイネーブラに転送されるＡＰＩリクエスト、および、前記ＡＰＩリクエストに対応するＡＰＩレスポンスを関連付けて蓄積可能な蓄積部、を備え、アプリケーションの動作確認を行うテスト装置におけるテスト方法であって、前記アプリケーションから前記ＡＰＩリクエストを取得して前記蓄積部に蓄積するとともに前記イネーブラに転送するＡＰＩリクエスト処理ステップと、前記ＡＰＩリクエストに対応するＡＰＩレスポンスを前記イネーブラから受信して前記蓄積部に蓄積するように処理するＡＰＩレスポンス処理ステップと、前記アプリケーションに対して所定のテストを行うためのテストリクエストを前記アプリケーションから取得して前記蓄積部を検索するテストリクエスト処理ステップと、前記テストリクエストに一致する前記ＡＰＩリクエストに関連付けられている前記ＡＰＩレスポンスを前記蓄積部から取得し、前記取得したＡＰＩレスポンスをテストレスポンスとして前記アプリケーションに返すテストレスポンス処理ステップと、前記蓄積部のＡＰＩレスポンスを必要に応じて書き換えるテストレスポンス操作ステップを備えることを特徴とする。
【０００９】
請求項１，２の発明によれば、本番環境のＡＰＩレスポンスを反映したテストを実施することができるため、アプリケーション開発におけるシナリオテストや連結テストなどにフレキシブルに対応することができる。また、テスト工程の際、本番環境のＡＰＩを提供する他社のサーバにアプリケーションがアクセスすることがないため、イネーブラや他のユーザに影響を及ぼすことが無い。したがって、外部のＡＰＩを利用して動作する開発アプリケーションのテスト工程を実施する際、良否が明確となるテスト結果を容易かつ確実に得られるようにすることができる。
【発明の効果】
【００１０】
本発明によれば、外部のＡＰＩを利用して動作する開発アプリケーションのテスト工程を実施する際、良否が明確となるテスト結果を容易かつ確実に得られるようにすることができる。
【図面の簡単な説明】
【００１１】
【図１】本実施形態のテスト装置の機能構成図である。
【図２】テスト用ＡＰＩ情報を蓄積する処理を示すフローチャートである。
【図３】開発アプリケーションのテスト工程の処理を示すフローチャートである。
【図４】テスト工程用のプログラムを実行するコンピュータを示す図である。
【発明を実施するための形態】
【００１２】
本発明を実施するための形態（実施形態）について、図面を参照しながら詳細に説明する。
【００１３】
＜構成＞
図１に示すように、本実施形態のテスト装置１は、アプリ２および高機能モック３を備える。
アプリ２は、例えば、開発中のアプリケーションであって、テスト装置１にインストールされたものである。
高機能モック３は、アプリ２との通信内容の蓄積処理や、アプリ２のテスト工程における処理を行う。高機能モック３の詳細は、後記する。
【００１４】
図１のイネーブラ５は、アプリ２が所定のサービスを提供するために必要な機能を保有する実態（ハードウェアまたはソフトウェア）である。バックエンドシステムとも呼ばれる。イネーブラ５が保有する機能には、例えば、セキュリティ機能、ＳＭＳ（ショートメッセージサービス）機能、クラウド制御機能、などさまざまであるが、これらに限定されない。アプリ２は、ＡＰＩを介してイネーブラ５にアクセスすることで、イネーブラ５が保有する機能を利用することができる。
【００１５】
図１のＨＭＩ（Human Machine Interface）６は、例えば、アプリ２の開発者が操作するコンソールである。ＨＭＩ６は、テスト装置１に対して所定の情報を入力したり、テスト装置１からの出力を所定の態様で表示したりする。
図１のＡＰＩは、例えば、他社が保有するサーバ（図示せず）が提供するＡＰＩ（外部のＡＰＩ）である。
【００１６】
高機能モック３は、蓄積部４、ＡＰＩリクエスト処理部１１、ＡＰＩレスポンス処理部１２、テストリクエスト処理部１３、テストレスポンス処理部１４、および、テストレスポンス操作部１５を備える。
【００１７】
蓄積部４は、ＡＰＩリクエストと、ＡＰＩレスポンスとを関連付けた情報をテスト用ＡＰＩ情報として蓄積する。「ＡＰＩリクエスト」は、ＡＰＩを利用するリクエストであって、アプリ２から送信される。「ＡＰＩレスポンス」は、ＡＰＩを利用するレスポンスであって、イネーブラ５から送信される。
【００１８】
ＡＰＩリクエスト処理部１１は、ＡＰＩリクエストをアプリ２から取得してイネーブラ５に転送する。ＡＰＩリクエスト処理部１１がＡＰＩリクエストをイネーブラ５に転送する際はＡＰＩを介する。ＡＰＩリクエスト処理部１１は、アプリ２から取得したＡＰＩリクエストを蓄積部４に蓄積する。
【００１９】
ＡＰＩレスポンス処理部１２は、ＡＰＩリクエストに対応するＡＰＩレスポンスをイネーブラ５から受信する。ＡＰＩレスポンス処理部１２がＡＰＩレスポンスをイネーブラ５に受信する際はＡＰＩを介する。ＡＰＩレスポンス処理部１２は、イネーブラ５から受信したＡＰＩレスポンスを蓄積部４に蓄積する。
【００２０】
テストリクエスト処理部１３は、アプリ２に対して所定のテストを行うためのテストリクエストをアプリ２から取得する。テストリクエストは、ＡＰＩリクエストと実質的に同等である。テストリクエスト処理部１３は、アプリ２から取得したテストリクエストを検索キーとして蓄積部４を検索する。
【００２１】
テストレスポンス処理部１４は、テストリクエストに一致するＡＰＩリクエストに関連付けられているＡＰＩレスポンスを蓄積部４から選択する。テストレスポンス処理部１４は、選択したＡＰＩレスポンスをテストレスポンスとしてアプリ２に返す。
【００２２】
テストレスポンス操作部１５は、ＨＭＩ６からの入力を受け、蓄積部４が蓄積するテスト用ＡＰＩ情報のＡＰＩレスポンスを必要に応じて書き換える。テストレスポンス処理部１４は、書き換えられたＡＰＩレスポンスをテストレスポンスとしてアプリ２に返す。
【００２３】
＜テスト用ＡＰＩ情報の蓄積＞
本実施形態のテスト装置１は、まず、アプリ２のテストを行うために、所定量のテスト用ＡＰＩ情報を蓄積部４に蓄積する。本実施形態のテスト装置１がテスト用ＡＰＩ情報を蓄積する処理は、図２のステップＳ１〜ステップＳ５に示す通りである。
【００２４】
ステップＳ１にて、ＡＰＩリクエスト処理部１１は、アプリ２からＡＰＩリクエストを取得する。ステップＳ１の後、ステップＳ２に進む。
ステップＳ２にて、ＡＰＩリクエスト処理部１１は、アプリ２から取得したＡＰＩリクエストを蓄積部４に蓄積する。ステップＳ２の後、ステップＳ３に進む。
ステップＳ３にて、ＡＰＩリクエスト処理部１１は、アプリ２から取得したＡＰＩリクエストを、ＡＰＩを介してイネーブラ５に転送する。ステップＳ３の後、ステップＳ４に進む。
【００２５】
ステップＳ４にて、ＡＰＩレスポンス処理部１２は、ＡＰＩを介してイネーブラ５からＡＰＩレスポンスを受信する。ステップＳ４の後、ステップＳ５に進む。
ステップＳ５にて、ＡＰＩレスポンス処理部１２は、イネーブラ５から受信したＡＰＩレスポンスを蓄積部４に蓄積する。蓄積部４は、ステップＳ１にて取得したＡＰＩリクエストとステップＳ５にて受信したＡＰＩレスポンスとを関連付けてテスト用ＡＰＩ情報として蓄積する。
【００２６】
アプリ２からのＡＰＩリクエストを都度変更しつつ、図２のステップＳ１〜ステップＳ５を繰り返すことで、所定量のテスト用ＡＰＩ情報が蓄積部４に蓄積される。
なお、図２の処理は、テスト工程の準備段階として事前に行われるが、本番環境のＡＰＩが利用されることを考慮して、このＡＰＩを提供する他社のサーバにかかる負荷を最小限に抑えることができるタイミングで図２の処理を実行することが好ましい。
【００２７】
＜テスト工程＞
本実施形態のテスト装置１は、蓄積部４に蓄積されたテスト用ＡＰＩ情報を用いて、アプリ２におけるテスト工程を実施する。本実施形態のテスト装置１が実施するテスト工程の処理は、図３のステップＳ１１〜ステップＳ１３に示す通りである。
【００２８】
ステップＳ１１にて、テストリクエスト処理部１３は、アプリ２からテストリクエストを取得する。ステップＳ１１の後、ステップＳ１２に進む。
【００２９】
ステップＳ１２にて、テストリクエスト処理部１３がテストリクエストを検索キーとして蓄積部４を検索し、テストレスポンス処理部１４がテストリクエストに一致するＡＰＩリクエストに関連付けられているＡＰＩレスポンスを蓄積部４から選択する。ステップＳ１２の後、ステップＳ１３に進む。
【００３０】
ステップＳ１３にて、テストレスポンス処理部１４は、選択したＡＰＩレスポンスをテストレスポンスとしてアプリ２に返す。
【００３１】
図３のテスト工程によれば、テスト装置１は、アプリ２からのテストリクエストに対して、本番環境のＡＰＩを介することなく、本番環境のＡＰＩレスポンスと同質のテストレスポンスをアプリ２に返すことができる。よって、本番環境のＡＰＩレスポンスを反映したテストを実施することができるため、アプリケーション開発におけるシナリオテストや連結テストなどにフレキシブルに対応することができる。また、テスト工程の際、本番環境のＡＰＩを提供する他社のサーバにアプリ２がアクセスすることがないため、イネーブラ５や他のユーザに影響を及ぼすことが無い。したがって、外部のＡＰＩを利用して動作する開発アプリケーションのテスト工程を実施する際、良否が明確となるテスト結果を容易かつ確実に得られるようにすることができる。
【００３２】
＜具体例＞
本実施形態のテスト装置の具体例について説明する。アプリ２は、天気情報をユーザに通知する機能を有し、イネーブラ５は、天気状態を表現する機能を有しているとする。
【００３３】
まず、本実施形態の高機能モック３を用いずにアプリ２のテストを行う場合について説明する。この場合、例えば、「今日の天気は？」、「明日の天気は？」というＡＰＩリクエストは、本番環境のＡＰＩを介してアプリ２からイネーブラ５に転送される。これに対し、「くもり（２月４日）」、「晴れ（２月５日）」というＡＰＩレスポンスが、本番環境のＡＰＩを介してイネーブラ５からアプリ２に転送される。このようにして、アプリ２は、本番の状況に応じた一意のレスポンスを得ることができ、相応のテストを行うことができる。しかし、テスト項目が多い場合、アプリ２自体に相当量の不具合が含まれている場合などは、本番環境のＡＰＩを提供する他社のサーバへの負荷が増大してしまい、イネーブラ５や、イネーブラ５にアクセスする他のアプリケーションを利用するユーザ（端末）に相当程度の影響を及ぼしてしまう。
【００３４】
一方、天気状態を表現可能なＡＰＩモックを用いる場合、ＡＰＩリクエストやＡＰＩレスポンスが本番環境のＡＰＩを介さないように済ませることができる。しかし、「今日の天気は？」、「明日の天気は？」というアプリ２からのリクエストに対して、ＡＰＩモックは、「くもり」、「くもり」という固定値のレスポンスしかアプリ２に返さない。これでは、シナリオテストや連結テストなどにはフレキシブルに対応できない。
【００３５】
本実施形態の高機能モック３を用いる場合、高機能モック３は、「くもり（２月４日）」、「晴れ（２月５日）」、「雨（２月６日）」、・・・というＡＰＩレスポンスをイネーブラ５から取得して、ＡＰＩレスポンスの集合を蓄積部４に事前に蓄積することができる。よって、アプリ２のテスト工程を実施する場合、「今日の天気は？」、「明日の天気は？」、「２月６日の天気は？」というアプリ２からのＡＰＩリクエストに対して、高機能モック３は、「くもり（２月４日）」、「晴れ（２月５日）」、「雨（２月６日）」というＡＰＩレスポンスをテストレスポンスとしてアプリ２に返すことができる。このとき、本番環境のＡＰＩを提供する他社のサーバにアプリ２がアクセスすることがないため、イネーブラ５や他のユーザに影響を及ぼすことが無いようにすることができるとともに、シナリオテストや連結テストなどにフレキシブルに対応することもできる。
【００３６】
また、シナリオテストや連結テストなどを実施することができるのであれば、テストレスポンスをＡＰＩレスポンスと同じにする必要はなく、テストレスポンスの情報量をＡＰＩレスポンスの情報量よりも小さくしてもよい。例えば、テストレスポンス操作部１５の機能によって、蓄積部４に蓄積されている「くもり（２月４日）」、「晴れ（２月５日）」、「雨（２月６日）」、・・・というＡＰＩレスポンスを編集して、「くもり」、「晴れ」、「雨」、・・・というレスポンスを、アプリ２に返すテストレスポンスとしてもよい。その結果、「今日の天気は？」、「明日の天気は？」、「２月６日の天気は？」というアプリ２からのＡＰＩリクエストに対して、高機能モック３は、「くもり」、「晴れ」、「雨」というテストレスポンスをアプリ２に返す。このように、イネーブラ５よりも低性能な機能を高機能モック３に実装させるようにし、高機能モック３自体の開発コストを抑えることができるようにしつつも、適切な値をとるテストレスポンスをアプリ２に返すことでシナリオテストや連結テストなどを確実に実施することができる。
【００３７】
（プログラム）
また、上記実施形態に係るテスト装置が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。この場合、コンピュータがプログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかるプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータに読み込ませて実行することにより上記実施形態と同様の処理を実現してもよい。以下に、テスト装置と同様の機能を実現するテストプログラムを実行するコンピュータの一例を説明する。
【００３８】
図４は、テストプログラムを実行するコンピュータを示す図である。図４に示すように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有する。これらの各部は、バス１０８０によって接続される。
【００３９】
メモリ１０１０は、ＲＯＭ（Read  Only  Memory）１０１１およびＲＡＭ（Random  Access  Memory）１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic  Input  Output  System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。ディスクドライブ１１００には、例えば、磁気ディスクや光ディスク等の着脱可能な記憶媒体が挿入される。シリアルポートインタフェース１０５０には、例えば、マウス１１１０およびキーボード１１２０が接続される。ビデオアダプタ１０６０には、例えば、ディスプレイ１１３０が接続される。
【００４０】
ここで、図４に示すように、ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３およびプログラムデータ１０９４を記憶する。上記実施形態で説明した各テーブルは、例えばハードディスクドライブ１０９０やメモリ１０１０に記憶される。
【００４１】
また、テストプログラムは、例えば、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、ハードディスクドライブ１０９０に記憶される。具体的には、上記実施形態で説明した監視プログラムが実行する各処理が記述されたプログラムモジュールが、ハードディスクドライブ１０９０に記憶される。
【００４２】
また、テストプログラムによる情報処理に用いられるデータは、プログラムデータとして、例えば、ハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、ハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して、上述した各手順を実行する。
【００４３】
なお、テストプログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限られず、例えば、着脱可能な記憶媒体に記憶されて、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、テストプログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ＬＡＮ（Local  Area  Network）やＷＡＮ（Wide  Area  Network）等のネットワークを介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
【００４４】
（その他）
本実施形態のアプリ２は、例えば、開発中のアプリケーションであって、テスト装置１にインストールされたものである。しかし、テスト装置１が、アプリ２がインストールされている別体の装置と通信可能に接続し、アプリ２からのリクエスト（ＡＰＩリクエスト、テストリクエストなど）を別体の装置から受信し、アプリ２へのレスポンス（テストレスポンスなど）を別体の装置に送信する、という形態をとることもできる。
【００４５】
本実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。
本実施形態で説明したソフトウェアをハードウェアとして実現することもでき、ハードウェアをソフトウェアとして実現することもできる。
その他、ハードウェア、ソフトウェア、フローチャートなどについて、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。
【符号の説明】
【００４６】
１      テスト装置
１１    ＡＰＩリクエスト処理部
１２    ＡＰＩレスポンス処理部
１３    テストリクエスト処理部
１４    テストレスポンス処理部
１５    テストレスポンス操作部
２      アプリ（アプリケーション）
３      高機能モック
４      蓄積部
５      イネーブラ
６      ＨＭＩ
【図１】
2016149043.tif 000003
【図２】
2016149043.tif 000004
【図３】
2016149043.tif 000005
【図４】
2016149043.tif 000006