(57)【要約】【課題】サービスの開発及び改善のサイクルの速度に合わせて、継続的にサービスの提供するために必要な情報を自動的に設定する。【解決手段】アプリケーション及びサービスの間のＡＰＩ（インタフェース）を介したデータの入出力を制御するＡＰＩ集約装置であって、サービスは種類が異なる複数のＡＰＩを有し、ＡＰＩ集約装置は、任意のサービスが有する複数のＡＰＩの中からターゲットＡＰＩの代替ＡＰＩを特定するためのテストの実行契機を検知した場合、フレームワーク情報に基づいて複数のテストケースを生成し、複数のテストケースを解析し、解析の結果に基づいて削除可能なテストケースを特定し、特定されたテストケースを削除し、テストケースに基づいてテストを実行し、テストの実行結果に基づいて代替ＡＰＩを特定し、互換情報に登録する。【選択図】図１
2019101801.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも一つのアプリケーション及び複数のサービスの間のインタフェースを介したデータの入出力を制御するインタフェース集約装置であって、
前記複数のサービスの各々は、種類が異なる複数のインタフェースを有し、
前記インタフェース集約装置は、
プロセッサ、前記プロセッサに接続されるメモリ、及び前記プロセッサに接続されるネットワークインタフェースを備え、
テストの要件を定義するテストケースを生成するために用いられるフレームワーク情報、及び任意のインタフェースと互換性を有する代替インタフェースを管理するための互換情報を保持し、
任意のサービスが有する前記複数のインタフェースの中からターゲットインタフェースの前記代替インタフェースを特定するためのテストの実行契機を検知した場合、前記フレームワーク情報に基づいて複数のテストケースを生成し、
前記複数のテストケースを解析し、前記解析の結果に基づいて削除可能な少なくとも一つのテストケースを特定して、前記特定された少なくとも一つのテストケースを削除し、
前記複数のテストケースに基づいてテストを実行し、
前記テストの実行結果に基づいて前記ターゲットインタフェースの代替インタフェースを特定し、
前記ターゲットインタフェース及び前記ターゲットインタフェースの代替インタフェースを対応づけたデータを前記互換情報に登録することを特徴とするインタフェース集約装置。
【請求項２】
請求項１に記載のインタフェース集約装置であって、
テストケースに基づくテストの実行結果の履歴を管理し、
前記解析の結果に基づいて、前記複数のテストケースの中から削除候補のテストケースを特定し、
前記削除候補のテストケースと同一内容であり、実行順番が後である重複テストケースが存在し、かつ、前記削除候補のテストケース及び前記重複テストケースに基づくテストの実行間隔が第１閾値より小さい場合、前記重複テストケースを削除する第１削除処理を実行し、
前記削除候補のテストケースに基づくテストの実行結果として成功を示す出力値が得られる確率が第２閾値より大きく、かつ、前回の前記削除候補のテストケースと同一内容のテストケースに基づくテストが実行されてからの経過時間が第３閾値より小さい場合、前記削除候補のテストケースを削除する第２削除処理を実行し、
前記削除候補のテストケースに基づくテストの実行結果として失敗を示す出力値が得られる確率が第４閾値より大きく、かつ、前回の前記削除候補のテストケースと同一内容のテストケースに基づくテストが実行されてからの経過時間が第５閾値より小さい場合、前記削除候補のテストケースを削除する第３削除処理を実行することを特徴とするインタフェース集約装置。
【請求項３】
請求項２に記載のインタフェース集約装置であって、
前記テストケースは入力値を含み、
前記インタフェース集約装置は、前記代替インタフェースを特定するために使用する判定ルールを保持し、
前記複数のテストケースは、前記ターゲットインタフェースに関する第１テストケース及び第１インタフェースに関する第２テストケースを含み、
前記第１テストケースに基づいてテストを実行することによって第１出力値を取得し、
前記第２テストケースに基づいてテストを実行することによって第２出力値を取得し、
前記第１テストケースの入力値及び前記第１出力値と、前記第２テストケースの入力値及び前記第２出力値とを比較し、
前記第２テストケースの入力値及び前記第２出力値が前記第１テストケースの入力値及び前記第１出力値と一致する場合、前記互換情報に、前記ターゲットインタフェースの代替インタフェースとして前記第１インタフェースを登録し、
前記第２テストケースの入力値及び前記第２出力値が前記第１テストケースの入力値及び前記第１出力値と一部異なる場合、前記判定ルールを適用することによって前記第２出力値が前記第１出力値と一致するか否かを判定し、
前記判定ルールを適用することによって前記第２出力値が前記第１出力値と一致すると判定された場合、前記互換情報に、前記ターゲットインタフェースの代替インタフェースとして前記第１インタフェースを登録することを特徴とするインタフェース集約装置。
【請求項４】
請求項２に記載のインタフェース集約装置であって、
新規インタフェースの追加通知を受信した場合、及び、前記アプリケーションからのリクエストに対して正常でない応答をしたインタフェースの前記代替インタフェースが前記互換情報に登録されていない場合の少なくともいずれかを、前記テストの実行契機として検知することを特徴とするインタフェース集約装置。
【請求項５】
請求項２に記載のインタフェース集約装置であって、
前記アプリケーションから任意のサービスが有する第２インタフェースに対するリクエストを受信した場合、前記第２インタフェースに前記リクエストを送信し、
前記第２インタフェースを介して応答を受信し、
前記受信した応答が正常な応答であるか否かを判定し、
前記受信した応答が正常な応答でないと判定された場合、前記互換情報を参照し、前記第２インタフェースの代替インタフェースに対してリクエストを送信することを特徴とするインタフェース集約装置。
【請求項６】
請求項２に記載のインタフェース集約装置であって、
前記第１削除処理、前記第２削除処理、及び前記第３削除処理が実行された後、前記複数のテストケースを実行した場合の処理負荷を算出し、
前記処理負荷が第４閾値より大きい場合、前記削除候補のテストケースを特定し、
前記重複テストケースが存在し、かつ、前記削除候補のテストケース及び前記重複テストケースに基づくテストの実行間隔が第６閾値より小さい場合、前記重複テストケースを削除する第４削除処理を実行し、
前記第６閾値は前記第１閾値より大きいことを特徴とするインタフェース集約装置。
【請求項７】
請求項２に記載のインタフェース集約装置であって、
前記全てのテストケースが値の読み出しを行う参照系のテストを実行するためのテストケースであるか否かを判定し、
前記少なくとも一つのテストケースが前記参照系のテストを実行するためのテストケースではないと判定された場合、テスト環境を生成し、
前記テスト環境上で、前記複数のテストケースに基づくテストを実行することを特徴とするインタフェース集約装置。
【請求項８】
少なくとも一つのアプリケーション及び複数のサービスの間のインタフェースを介したデータの入出力を制御するインタフェース集約装置が実行するインタフェース管理方法であって、
前記複数のサービスの各々は、種類が異なる複数のインタフェースを有し、
前記インタフェース集約装置は、
プロセッサ、前記プロセッサに接続されるメモリ、及び前記プロセッサに接続されるネットワークインタフェースを有し、
テストの要件を定義するテストケースを生成するために用いられるフレームワーク情報、及び任意のインタフェースと互換性を有する代替インタフェースを管理するための互換情報を保持し、
前記インタフェース管理方法は、
前記インタフェース集約装置が、任意のサービスが有する前記複数のインタフェースの中からターゲットインタフェースの前記代替インタフェースを特定するためのテストの実行契機を検知した場合、前記フレームワーク情報に基づいて複数のテストケースを生成する第１のステップと、
前記インタフェース集約装置が、前記複数のテストケースを解析し、前記解析の結果に基づいて削除可能な少なくとも一つのテストケースを特定して、前記特定された少なくとも一つのテストケースを削除する第２のステップと、
前記インタフェース集約装置が、前記複数のテストケースに基づいてテストを実行する第３のステップと、
前記インタフェース集約装置が、前記テストの実行結果に基づいて前記ターゲットインタフェースの代替インタフェースを特定する第４のステップと、
前記インタフェース集約装置が、前記ターゲットインタフェース及び前記ターゲットインタフェースの代替インタフェースを対応づけたデータを前記互換情報に登録する第５のステップと、を含むことを特徴とするインタフェース管理方法。
【請求項９】
請求項８に記載のインタフェース管理方法であって、
前記インタフェース集約装置は、テストケースに基づくテストの実行結果の履歴を管理し、
前記第２のステップは、
前記インタフェース集約装置が、前記解析の結果に基づいて、前記複数のテストケースの中から削除候補のテストケースを特定するステップと、
前記削除候補のテストケースと同一内容であり、実行順番が後である重複テストケースが存在し、かつ、前記削除候補のテストケース及び前記重複テストケースに基づくテストの実行間隔が第１閾値より小さい場合、前記重複テストケースを削除する第１削除処理を実行するステップと、
前記削除候補のテストケースに基づくテストの実行結果として成功を示す出力値が得られる確率が第２閾値より大きく、かつ、前回の前記削除候補のテストケースと同一内容のテストケースに基づくテストが実行されてからの経過時間が第３閾値より小さい場合、前記削除候補のテストケースを削除する第２削除処理を実行するステップと、
前記削除候補のテストケースに基づくテストの実行結果として失敗を示す出力値が得られる確率が第４閾値より大きく、かつ、前回の前記削除候補のテストケースと同一内容のテストケースに基づくテストが実行されてからの経過時間が第５閾値より小さい場合、前記削除候補のテストケースを削除する第３削除処理を実行するステップと、を含むことを特徴とするインタフェース管理方法。
【請求項１０】
請求項９に記載のインタフェース管理方法であって、
前記テストケースは入力値を含み、
前記インタフェース集約装置は、前記代替インタフェースを特定するために使用する判定ルールを保持し、
前記複数のテストケースは、前記ターゲットインタフェースに関する第１テストケース及び第１インタフェースに関する第２テストケースを含み、
前記第４のステップは、
前記インタフェース集約装置が、前記第１テストケースに基づいてテストを実行することによって第１出力値を取得するステップと、
前記インタフェース集約装置が、前記第２テストケースに基づいてテストを実行することによって第２出力値を取得するステップと、
前記インタフェース集約装置が、前記第１テストケースの入力値及び前記第１出力値と、前記第２テストケースの入力値及び前記第２出力値とを比較するステップと、
前記第２テストケースの入力値及び前記第２出力値が前記第１テストケースの入力値及び前記第１出力値と一致する場合、前記インタフェース集約装置が、前記互換情報に、前記ターゲットインタフェースの代替インタフェースとして前記第１インタフェースを登録するステップと、
前記第２テストケースの入力値及び前記第２出力値が前記第１テストケースの入力値及び前記第１出力値と一部異なる場合、前記インタフェース集約装置が、前記判定ルールを適用することによって前記第２出力値が前記第１出力値と一致するか否かを判定するステップと、
前記判定ルールを適用することによって前記第２出力値が前記第１出力値と一致すると判定された場合、前記インタフェース集約装置が、前記互換情報に、前記ターゲットインタフェースの代替インタフェースとして前記第１インタフェースを登録するステップと、を含むことを特徴とするインタフェース管理方法。
【請求項１１】
請求項９に記載のインタフェース管理方法であって、
第１のステップでは、前記インタフェース集約装置は、新規インタフェースの追加通知を受信した場合、及び、前記アプリケーションからのリクエストに対して正常でない応答をしたインタフェースの前記代替インタフェースが前記互換情報に登録されていない場合の少なくともいずれかを、前記テストの実行契機として検知することを特徴とするインタフェース管理方法。
【請求項１２】
請求項９に記載のインタフェース管理方法であって、
前記アプリケーションから任意のサービスが有する第２インタフェースに対するリクエストを受信した場合、前記インタフェース集約装置が、前記第２インタフェースに前記リクエストを送信するステップと、
前記インタフェース集約装置が、前記第２インタフェースを介して応答を受信するステップと、
前記インタフェース集約装置が、前記受信した応答が正常な応答であるか否かを判定するステップと、
前記受信した応答が正常な応答でないと判定された場合、前記インタフェース集約装置が、前記互換情報を参照し、前記第２インタフェースの代替インタフェースに対してリクエストを送信するステップと、を含むことを特徴とするインタフェース管理方法。
【請求項１３】
請求項９に記載のインタフェース管理方法であって、
前記インタフェース集約装置が、前記第１削除処理、前記第２削除処理、及び前記第３削除処理が実行された後、前記複数のテストケースを実行した場合の処理負荷を算出するステップと、
前記処理負荷が第４閾値より大きい場合、前記インタフェース集約装置が、前記削除候補のテストケースを特定するステップと、
前記重複テストケースが存在し、かつ、前記削除候補のテストケース及び前記重複テストケースに基づくテストの実行間隔が第６閾値より小さい場合、前記インタフェース集約装置が、前記重複テストケースを削除する第４削除処理を実行するステップと、を含み、
前記第６閾値は前記第１閾値より大きいことを特徴とするインタフェース管理方法。
【請求項１４】
請求項９に記載のインタフェース管理方法であって、
前記第３のステップは、
前記インタフェース集約装置が、前記全てのテストケースが値の読み出しを行う参照系のテストを実行するためのテストケースであるか否かを判定するステップと、
前記少なくとも一つのテストケースが前記参照系のテストを実行するためのテストケースではないと判定された場合、前記インタフェース集約装置が、テスト環境を生成するステップと、
前記インタフェース集約装置が、前記テスト環境上で、前記複数のテストケースに基づくテストを実行するステップと、を含むことを特徴とするインタフェース管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＡＰＩ（インタフェース）を介したアプリケーション及びマイクロサービスの接続を管理するＡＰＩ集約装置及びＡＰＩ管理方法に関する。
【背景技術】
【０００２】
近年のビジネス環境では、開発部門及び運用部門が連携し、サービスの開発及び改善を継続的に行うＤｅｖＯｐｓが注目されている。
【０００３】
ＤｅｖＯｐｓの一つとして、マイクロサービスという考え方がある。この考え方では、サービスを複数の小さなマイクロサービスに分割し、各マイクロサービスを個別に開発する。開発対象のマイクロサービスは小さい単位のシステムであるため、マイクロサービス開発及び改善のサイクルを短くできる。各マイクロサービスはＡＰＩを介して連携することによって、システムとして一貫性した動作が可能となる。
【０００４】
マイクロサービスの開発及び改善のサイクルは短いため、ＡＰＩのバージョンの更新が頻繁に発生する。頻繁なＡＰＩのバージョンの更新に伴ってＡＰＩの互換性が失われ、サービス全体が正常に動作しない可能性がある。
【０００５】
ＡＰＩの機能不全を解決するための手段として特許文献１に記載の技術が知られている。特許文献１には、「ＡＰＩ集約装置２４は、通信システムのアプリケーション２５ａとイネーブラ２７ａ〜２７ｄとの間にＡＰＩ２６ａ、２８ａ〜２８ｄを介して接続される。ＡＰＩ集約装置２４は、アプリケーション２５ａから所望のイネーブラ２７ｂへＡＰＩ２６ｂ、２８ｂを介してリクエスト情報を送信した際に、当該リクエスト情報の内容に適合したレスポンス情報が返信されない機能不全の場合、当該機能不全のイネーブラ２７ｂに予め対応付けられた対応イネーブラ２７ｃからのレスポンス情報を、当該対応イネーブラ２７ｃに繋がる対応ＡＰＩ２８ｃを介して当該アプリケーション２５ａへ返信するＡＰＩ互換処理を行う。」ことが記載されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１６−１５１８８１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
特許文献１の技術では、ＡＰＩ及び対応ＡＰＩを予め対応づけて管理する必要がある。ＤｅｖＯｐｓでは、ＡＰＩのバージョンの更新が頻繁に発生するため、ＡＰＩ及び対応ＡＰＩの登録を頻繁に行う必要がある。したがって、管理コストがかかり、また、サービスの開発及び改善のサイクルの速度に対応できない可能性がある。
【０００８】
上記課題を解決するためには、サービスの開発及び改善のサイクルの速度に合わせて、継続的にサービスの提供するために必要な情報を動的に設定する必要がある。
【０００９】
本発明は、ＡＰＩのバージョンの更新が頻繁に発生する場合でも、サービスの開発及び改善のサイクルの速度に合わせて、継続的にサービスの提供するために必要な情報を自動的に設定する装置及び方法を提供することを目的とする。
【課題を解決するための手段】
【００１０】
本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、少なくとも一つのアプリケーション及び複数のサービスの間のインタフェースを介したデータの入出力を制御するインタフェース集約装置であって、前記複数のサービスの各々は、種類が異なる複数のインタフェースを有し、前記インタフェース集約装置は、プロセッサ、前記プロセッサに接続されるメモリ、及び前記プロセッサに接続されるネットワークインタフェースを備え、テストの要件を定義するテストケースを生成するために用いられるフレームワーク情報、及び任意のインタフェースと互換性を有する代替インタフェースを管理するための互換情報を保持し、任意のサービスが有する前記複数のインタフェースの中からターゲットインタフェースの前記代替インタフェースを特定するためのテストの実行契機を検知した場合、前記フレームワーク情報に基づいて複数のテストケースを生成し、前記複数のテストケースを解析し、前記解析の結果に基づいて削除可能な少なくとも一つのテストケースを特定して、前記特定された少なくとも一つのテストケースを削除し、前記複数のテストケースに基づいてテストを実行し、前記テストの実行結果に基づいて前記ターゲットインタフェースの代替インタフェースを特定し、前記ターゲットインタフェース及び前記ターゲットインタフェースの代替インタフェースを対応づけたデータを前記互換情報に登録することを特徴とする。
【発明の効果】
【００１１】
本発明の一形態によれば、インタフェース集約装置は、サービスの開発及び改善のサイクルの速度に合わせて、互換情報を自動的に設定できる。上記した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。
【図面の簡単な説明】
【００１２】
【図１】実施例１の計算機システムの構成例を示す図である。
【図２】実施例１のＡＰＩ集約装置のハードウェア構成の一例を示す図である。
【図３】実施例１のフレームワーク情報のデータ構造の一例を示す図である。
【図４】実施例１の互換情報のデータ構造の一例を示す図である。
【図５Ａ】実施例１の結果情報のデータ構造の一例を示す図である。
【図５Ｂ】実施例１の結果情報のデータ構造の一例を示す図である。
【図６】実施例１のＡＰＩ集約装置が、新規ＡＰＩが追加された場合に実行する処理の一例を説明するフローチャートである。
【図７】実施例１のＡＰＩ集約装置によって生成されるテストケースの一例を示す図である。
【図８】実施例１のマイクロサービスのネストの一例を示す図である。
【図９】実施例１のテストケース調整部が実行するテストケース削減処理の一例を説明するフローチャートである。
【図１０】実施例１のテスト環境構築部が実行するテスト環境構築処理の一例を説明するフローチャートである。
【図１１】実施例１の代替ＡＰＩ判定部が実行する代替ＡＰＩ判定処理の一例を説明するフローチャートである。
【図１２】実施例１のＡＰＩ集約装置がアプリケーションからリクエストを受信した場合に実行する処理を説明するフローチャートである。
【図１３】実施例１のＡＰＩ集約装置が実行する代替ＡＰＩ選択処理を説明するフローチャートである。
【図１４Ａ】実施例２の計算機システムの構成例を示す図である。
【図１４Ｂ】実施例２の計算機システムの構成例を示す図である。
【図１５Ａ】実施例３のテストケース調整部が実行するテストケース削減処理の一例を説明するフローチャートである。
【図１５Ｂ】実施例３のテストケース調整部が実行するテストケース削減処理の一例を説明するフローチャートである。
【発明を実施するための形態】
【００１３】
以下、本発明の実施例を、図面を用いて説明する。ただし、本発明は以下に示す実施の形態の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。
【００１４】
以下に説明する発明の構成において、同一又は類似する構成又は機能には同一の符号を付し、重複する説明は省略する。
【００１５】
本明細書等における「第１」、「第２」、「第３」等の表記は、構成要素を識別するために付するものであり、必ずしも、数又は順序を限定するものではない。
【００１６】
図面等において示す各構成の位置、大きさ、形状、及び範囲等は、発明の理解を容易にするため、実際の位置、大きさ、形状、及び範囲等を表していない場合がある。したがって、本発明では、図面等に開示された位置、大きさ、形状、及び範囲等に限定されない。
【実施例１】
【００１７】
図１は、実施例１の計算機システムの構成例を示す図である。図２は、実施例１のＡＰＩ集約装置１００のハードウェア構成の一例を示す図である。
【００１８】
計算機システムは、ＡＰＩ集約装置１００、複数のアプリケーション１０１、及び複数のマイクロサービス１０２から構成される。アプリケーション１０１は計算機（図示省略）上で稼働し、マイクロサービス１０２は一つ以上の計算機から構成されるシステム（図示省略）上で稼働する。なお、本発明は、アプリケーション１０１及びマイクロサービス１０２の種類及び数に限定されない。
【００１９】
ＡＰＩ集約装置１００、アプリケーション１０１を実行する計算機、及びマイクロサービス１０２を実行するシステムは、ネットワークを介して互いに接続される。ネットワークは、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）及びＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等である。ネットワークの接続形式は、有線又は無線のいずれでもよい。
【００２０】
ＡＰＩ集約装置１００は、一つのアプリケーション１０１に対して、ＡＰＩ集約装置１００と接続するための少なくとも一つのＡＰＩ１０５を提供する。また、一つのマイクロサービス１０２は、ＡＰＩ集約装置１００と接続するための少なくとも一つのＡＰＩ１０６を提供する。
【００２１】
一つのアプリケーション１０１に提供される複数のＡＰＩ１０５はバージョンが異なり、また、一つのマイクロサービス１０２が提供する複数のＡＰＩ１０６はバージョンが異なる。なお、ＡＰＩ１０５は、マイクロサービス１０２毎に異なるバージョンのＡＰＩが含まれてもよい。なお、一つのマイクロサービス１０２が提供する複数のＡＰＩ１０６には、ＡＰＩ１０６のバージョンを取得するためのＡＰＩが含まれる。
【００２２】
本実施例のＡＰＩ集約装置１００は、任意のＡＰＩ１０６（ターゲットＡＰＩ１０６）と互換性を有するＡＰＩである代替ＡＰＩ１０６を特定するためのテストの実行契機を検知した場合、テストの要件（テストの内容）を定義するテストケースを生成する。また、ＡＰＩ集約装置１００は、生成されたテストケースに基づいてテストを実行し、実行結果に基づいて代替ＡＰＩ１０６を特定する。ＡＰＩ集約装置１００は、ターゲットＡＰＩ１０６及び代替ＡＰＩ１０６を対応づけて、後述する互換情報１２１に登録する。
【００２３】
また、本実施例のＡＰＩ集約装置１００は、アプリケーション１０１から任意のマイクロサービス１０２のＡＰＩ１０６に対するリクエストを受信した場合、必要に応じて互換情報１２１を参照し、指定されたＡＰＩ１０６又は代替ＡＰＩ１０６に当該リクエストを送信する。これによって、マイクロサービス１０２から正常な応答を得ることができるため、継続的なサービスの提供を実現できる。
【００２４】
ＡＰＩ集約装置１００は、図２に示すようにハードウェアとして、プロセッサ２０１、メモリ２０２、及びネットワークインタフェース２０３を有する。プロセッサ２０１、メモリ２０２、及びネットワークインタフェース２０３は、内部バスを介して互いに接続される。
【００２５】
プロセッサ２０１は、メモリ２０２に格納されるプログラムを実行する演算装置である。プロセッサ２０１がプログラムにしたがって処理を実行することによって、特定の機能を実現する機能部（モジュール）として動作する。以下の説明では、機能部を主語に処理を説明する場合、プロセッサ２０１が当該機能部を実現するプログラムを実行していることを表す。
【００２６】
メモリ２０２は、プロセッサ２０１が実行するプログラム及びプログラムが使用する情報を格納する記憶装置である。また、メモリ２０２は、プログラムが一時的に使用するワークエリアを含む。
【００２７】
ネットワークインタフェース２０３は、ネットワークを介して他の装置と接続するインタフェースである。
【００２８】
なお、ＡＰＩ集約装置１００は、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）及びＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等の記憶装置を有してもよい。また、ＡＰＩ集約装置１００は、キーボード、マウス、及びタッチパネル等の入力装置、並びに、ディスプレイ及びプリンタ等の出力装置と接続するインタフェースを有してもよい。
【００２９】
なお、ＡＰＩ集約装置１００には、ネットワークインタフェース２０３を介して図示しない管理用端末が接続される。
【００３０】
ここで、メモリ２０２に格納されるプログラム及び情報について説明する。メモリ２０２は、受信部１１０、送信部１１１、互換操作制御部１１２、テスト設定部１１３、テスト制御部１１４、及び代替ＡＰＩ判定部１１５を実現するプログラムを格納する。また、メモリ２０２は、フレームワーク情報１２０、互換情報１２１、及び結果情報１２２を格納する。
【００３１】
フレームワーク情報１２０は、テストケースのひな形であるフレームワークを管理するための情報である。フレームワーク情報１２０のデータ構造の詳細は図３を用いて説明する。互換情報１２１は、ＡＰＩ１０６及び代替ＡＰＩ１０６の対応付けを管理するための情報である。互換情報１２１のデータ構造の詳細は図４を用いて説明する。結果情報１２２は、テスト結果を格納する情報である。結果情報１２２のデータ構造の詳細は、図５Ａ及び図５Ｂを用いて説明する。
【００３２】
受信部１１０は、外部装置から送信されたデータの受信処理を実行する。例えば、受信部１１０は、アプリケーション１０１からマイクロサービス１０２に対するリクエストを受信し、また、マイクロサービス１０２から応答を受信する。
【００３３】
送信部１１１は、外部装置に対するデータの送信処理を実行する。例えば、送信部１１１は、受信したリクエストをマイクロサービス１０２に送信し、また、受信した応答をアプリケーション１０１に送信する。
【００３４】
互換操作制御部１１２は、所定のＡＰＩ１０６に対するリクエストの送信を制御する。互換操作制御部１１２は、リクエストに対するＡＰＩ１０６からの応答が正常であるか否かを判定し、応答が正常でない場合、代替ＡＰＩ１０６にリクエストを送信する。互換操作制御部１１２は、参照部１３１及び互換操作部１３２を含む。
【００３５】
参照部１３１は、互換情報１２１を参照し、代替ＡＰＩ１０６を特定する。互換操作部１３２は、受信したリクエストを代替ＡＰＩ１０６宛てのリクエストに変換し、出力する。
【００３６】
テスト設定部１１３は、代替ＡＰＩ１０６を特定するためのテストのテストケースを生成する。本実施例では、一つのテストに対して一つのテストケースが生成される。テスト設定部１１３は、テストケース生成部１４１及び呼出部１４２を含む。
【００３７】
テストケース生成部１４１は、フレームワーク情報１２０に基づいてテストケースを生成する。呼出部１４２は、テスト制御部１１４を呼び出す。
【００３８】
テスト制御部１１４は、テストケースを解析し、解析結果に基づいてテストケースを削除する。テスト制御部１１４は、テストケースに基づいてテストを実行し、実行結果を結果情報１２２に格納する。また、テスト制御部１１４は、テストを実行するためのテスト環境を構築する必要がある場合、テスト環境を構築する。テスト制御部１１４は、テストケース調整部１５１、テスト実行部１５２、及びテスト環境構築部１５３を含む。
【００３９】
テストケース調整部１５１は、テストケースを解析し、解析結果に基づいて削除可能なテストを特定し、特定されたテストケースを削除する。テスト実行部１５２は、テストケースに基づいて、代替ＡＰＩ１０６を特定するためのテストを実行する。テスト環境構築部１５３はテスト環境を構築する。
【００４０】
代替ＡＰＩ判定部１１５は、結果情報１２２に基づいて代替ＡＰＩ１０６を特定し、特定された代替ＡＰＩ１０６に関する情報を互換情報１２１に登録する。
【００４１】
なお、ＡＰＩ集約装置１００が有する各機能部については、複数の機能部を一つの機能部にまとめてもよいし、一つの機能部を機能毎に複数の機能部に分けてもよい。
【００４２】
図３は、実施例１のフレームワーク情報１２０のデータ構造の一例を示す図である。
【００４３】
フレームワーク情報１２０は、テスト種別３０１及び入力値種別３０２から構成されるエントリを格納する。なお、エントリには、テスト種別３０１及び入力値種別３０２以外のフィールドが含まれてもよい。
【００４４】
テスト種別３０１は、テストの種別を格納するフィールドである。例えば、テスト種別３０１には、データ更新、データ参照、及びデータ削除等のテストの種別を示す値が格納される。
【００４５】
入力値種別３０２は、テスト種別３０１に対応するテストにおいて入力される値の種別を格納するフィールドである。入力値種別３０２には、例えば、変数又は項目の名称等が格納される。
【００４６】
なお、フレームワーク情報１２０には、システム構成及びマイクロサービス１０２の条件等を管理するためのテーブルが含まれてもよい。
【００４７】
図４は、実施例１の互換情報１２１のデータ構造の一例を示す図である。
【００４８】
互換情報１２１は、代替元４０１及び代替先４０２から構成されるエントリを格納する。
【００４９】
代替元４０１は、代替元となるＡＰＩ１０６を特定するためのフィールド群であり、サービス名４１１、ＡＰＩ名４１２、及びＡＰＩバージョン４１３を含む。
【００５０】
サービス名４１１は、ＡＰＩ１０６を提供するマイクロサービス１０２の名称を格納するフィールドである。なお、マイクロサービス１０２を識別できる情報であれば、名称以外の値でもよい。
【００５１】
ＡＰＩ名４１２は、ＡＰＩ１０６の名称を格納するフィールドである。なお、ＡＰＩ１０６を識別できる情報であれば、名称以外の値でもよい。
【００５２】
ＡＰＩバージョン４１３は、ＡＰＩ１０６のバージョンを格納するフィールドである。
【００５３】
代替先４０２は、代替元４０１に対応するＡＰＩ１０６の代替ＡＰＩ１０６を特定するためのフィールド群であり、サービス名４２１、ＡＰＩ名４２２、及びＡＰＩバージョン４２３を含む。サービス名４２１、ＡＰＩ名４２２、及びＡＰＩバージョン４２３は、サービス名４１１、ＡＰＩ名４１２、及びＡＰＩバージョン４１３と同様のフィールドである。
【００５４】
図５Ａ及び図５Ｂは、実施例１の結果情報１２２のデータ構造の一例を示す図である。なお、図５及び図５Ｂに示すテーブルは、実際には一つのテーブルであるが説明のため二つに分けている。
【００５５】
結果情報１２２は、ＡＰＩ名５０１、ＡＰＩバージョン５０２、実行時刻５０３、テスト種別５０４、処理結果５０５、実行回数５０６、成功結果５０７、及び失敗結果５０８から構成されるエントリを格納する。
【００５６】
ＡＰＩ名５０１及びＡＰＩバージョン５０２は、ＡＰＩ名４１２及びＡＰＩバージョン４１３と同様のフィールドである。また、テスト種別５０４は、テスト種別３０１と同様のフィールドである。
【００５７】
実行時刻５０３は、テストの開始時刻を格納するフィールドである。なお、実行時刻５０３には、テストの終了時刻が格納されてもよい。
【００５８】
処理結果５０５は、最新のテストの実行結果を格納するフィールドである。図６Ａに示す処理結果５０５には、応答の意味を表すステータスコードが格納される。
【００５９】
実行回数５０６は、ＡＰＩ名５０１、ＡＰＩバージョン５０２、及びテスト種別５０４によって特定されるテストケースに基づくテストの実行回数を格納するフィールド群である。実行回数５０６は、成功５１１及び失敗５１２を含む。成功５１１は、実行結果が成功である回数を格納するフィールドである。失敗５１２は、実行結果が失敗である回数を格納するフィールドである。
【００６０】
成功結果５０７は、テストの実行結果が成功である場合の予測値及び出力値の関係を示すフィールド群である。成功結果５０７は、予測値５１３及び結果５１４を含む。予測値５１３はテストケースに含まれる出力値の予測値を格納するフィールドである。結果５１４はテストを実行することによって取得された出力値を格納するフィールドである。
【００６１】
失敗結果５０８は、テストの実行結果が失敗である場合の予測値及び出力値の関係を示すフィールド群である。失敗結果５０８は、予測値５１５及び結果５１６を含む。予測値５１５及び結果５１６は、予測値５１３及び結果５１４と同様のフィールドである。
【００６２】
図６は、実施例１のＡＰＩ集約装置１００が、新規ＡＰＩ１０６が追加された場合に実行する処理の一例を説明するフローチャートである。図７は、実施例１のＡＰＩ集約装置１００によって生成されるテストケースの一例を示す図である。図８は、実施例１のマイクロサービス１０２のネストの一例を示す図である。
【００６３】
ＡＰＩ集約装置１００は、管理用端末から新規ＡＰＩ１０６の追加通知を受信する（ステップＳ１０１）。本実施例のＡＰＩ集約装置１００は、新規ＡＰＩ１０６の追加通知の受信を、代替ＡＰＩ１０６を特定するためのテストの実行契機として検知する。このとき、ＡＰＩ集約装置１００は、テスト設定部１１３を呼び出す。追加通知には、マイクロサービス１０２及びＡＰＩ１０６を特定するための情報が含まれる。
【００６４】
テスト設定部１１３のテストケース生成部１４１は、新規ＡＰＩ１０６の代替ＡＰＩ１０６を特定するためのテストのテストケースを生成する（ステップＳ１０２）。テストケースの生成方法は公知の技術を用いればよい。例えば、以下のような生成方法が考えられる。
【００６５】
テストケース生成部１４１は、フレームワーク情報１２０及び結果情報１２２を参照して、マイクロサービス１０２、ＡＰＩ１０６、及びバージョンの組合せに対して、実行条件、テストの種別、入力値、及び予測値等から構成されるテストケースを生成する。より具体的には、テストケース生成部１４１は、ＡＰＩ名５０１が追加通知に含まれるＡＰＩ１０６の情報に一致するエントリを検索する。テストケース生成部１４１は、検索された成功結果５０７等に基づいて実行条件、入力値、及び予測値を決定することによって、テストケースを生成する。
【００６６】
テストケース生成部１４１は、例えば、図７に示すようなテストケースのリスト７００を生成する。リスト７００は、テストケースに対応するエントリを複数含む。エントリは、テスト内容７０１、入力値７０２、及び判定フラグ７０３から構成される。
【００６７】
テスト内容７０１は、テストの具体的な内容を格納するフィールドである。テスト内容７０１には、ＡＰＩ１０６を特定する情報及びテスト種別等が格納される。入力値７０２は、テストの入力値を格納するフィールドである。
【００６８】
判定フラグ７０３は、他のマイクロサービス１０２にネストされたマイクロサービス１０２のテストケースの削減処理を実行するか否かを示すフラグを格納するフィールドである。
【００６９】
ここで、ネストとは、ルーチン及びデータブロックの中に、他のルーチン及びデータブロックが埋め込まれていることを示す。したがって、マイクロサービス１０２のネストとは、図８に示すように、あるマイクロサービス１０２の呼出に他のマイクロサービス１０２の呼出が含まれることを示す。
【００７０】
図８では、実線は実際のアプリケーション実行パスを示す。一点鎖線はテストケースの対象となるアプリケーション実行パスを示す。テストケース生成部１４１は、ネストされたマイクロサービスを呼び出すＡＰＩ１０６の互換性を網羅的に確認するためのテストのテストケースを生成する。しかし、生成されるテストケースの数は膨大となるため、全てのテストケースに基づくテストを実行した場合、処理コストが大きくなる。そこで、本実施例では、テストケースの数を削減するための削減処理が実行される。
【００７１】
判定フラグ７０３には、「有」及び「無」のいずれかが格納される。「有」は呼び出し時間及び実績等に基づいてテストケースの削減処理を実行することを示し、「無」は呼び出し時間及び実績等に基づいてテストケースの削減処理を実行しないことを示す。
【００７２】
なお、マイクロサービス１０２のネストの判定は、他のテストケースとの関係を解析することによって判定できる。また、呼出条件が予め設定されている場合、当該呼出条件に基づいて判定することもできる。
【００７３】
テスト設定部１１３の呼出部１４２は、テストケースが生成された後、テスト制御部１１４を呼び出す。このとき、呼出部１４２は、生成されたテストケースをテスト制御部１１４に出力する。以上がステップＳ１０２の説明である。
【００７４】
次に、テスト制御部１１４のテストケース調整部１５１は、テストケース削減処理を実行する（ステップＳ１０３）。テストケース削減処理の詳細は図９を用いて説明する。
【００７５】
次に、テスト制御部１１４のテスト環境構築部１５３は、テスト環境構築処理を実行する（ステップＳ１０４）。テスト環境構築処理の詳細は図１０を用いて説明する。
【００７６】
次に、テスト制御部１１４のテスト実行部１５２は、生成されたテストケースに基づいてテストを実行する（ステップＳ１０５）。また、テスト実行部１５２は、テストの実行結果に基づいて結果情報１２２を更新する（ステップＳ１０６）。結果情報１２２は以下のようにして更新される。
【００７７】
テスト実行部１５２は、ＡＰＩ名５０１、ＡＰＩバージョン５０２、テスト種別５０４の組合せに基づいて、実行したテストに対応するエントリを検索する。実行したテストに対応するエントリが存在しない場合、テスト実行部１５２は、エントリを追加し、ＡＰＩ名５０１、ＡＰＩバージョン５０２、テスト種別５０４に値を設定する。
【００７８】
テスト実行部１５２は、検索されたエントリ又は追加されたエントリの実行時刻５０３にテストの開始時刻を設定し、また、処理結果５０５にテストの実行結果を格納する。また、テスト実行部１５２は、テストの実行結果に基づいて成功５１１及び失敗５１２のいずれか一方の値に１を加算する。
【００７９】
テスト実行部１５２は、処理結果が成功である場合、成功結果５０７に値を設定し、処理結果が失敗である場合、失敗結果５０８に値を設定する。
【００８０】
テスト制御部１１４は、結果情報１２２の更新が完了した後、代替ＡＰＩ判定部１１５を呼び出す。以上がステップＳ１０６の処理の説明である。
【００８１】
代替ＡＰＩ判定部１１５は、新規ＡＰＩ１０６の代替ＡＰＩ１０６を特定するための代替ＡＰＩ判定処理を実行し（ステップＳ１０７）、その後、処理を終了する。代替ＡＰＩ判定処理の詳細は図１１を用いて説明する。
【００８２】
図９は、実施例１のテストケース調整部１５１が実行するテストケース削減処理の一例を説明するフローチャートである。
【００８３】
テストケース調整部１５１は、テストケースを実行順番にソートし（ステップＳ２０１）、テストケースのループ処理を開始する（ステップＳ２０２）。具体的には、テストケース調整部１５１は、実行順にターゲットテストケースを選択する。
【００８４】
テストケース調整部１５１は、ターゲットテストケースがネストのマイクロサービス１０２のテストケースであるか否かを判定する（ステップＳ２０３）。すなわち、ターゲットテストケースが削除候補のテストケースであるか否かが判定される。
【００８５】
具体的には、テストケース調整部１５１は、ターゲットテストケースに対応するエントリの判定フラグ７０３が「有」であるか否かを判定する。判定フラグ７０３が「有」である場合、テストケース調整部１５１は、ターゲットテストケースがネストされたマイクロサービス１０２のテストケースであると判定する。
【００８６】
ターゲットテストケースがネストのマイクロサービス１０２のテストケースでないと判定された場合、テストケース調整部１５１は、ステップＳ２０９に進む。
【００８７】
ターゲットテストケースがネストのマイクロサービス１０２のテストケースであると判定された場合、テストケース調整部１５１は、バージョン及び引数がターゲットテストケースと同一であり、実行順番が後のテストケースが存在し、かつ、二つのテストケースに基づくテストの実行間隔が第１閾値より小さいか否かを判定する（ステップＳ２０４）。
【００８８】
以下の説明では、バージョン及び引数がターゲットテストケースと同一であり、実行順番が後のテストケースを重複テストケースと記載する。また、ステップＳ２０４の判定条件を第１削除条件と記載する。
【００８９】
なお、テストケース間の実行間隔は実行スケジュールに基づいて判定する方法が考えられる。また、結果情報の実行時刻５０３に基づいて実行間隔を算出する方法でもよい。
【００９０】
第１削除条件を満たさないと判定された場合、テストケース調整部１５１は、ステップＳ２０６に進む。
【００９１】
第１削除条件を満たすと判定された場合、テストケース調整部１５１は、重複テストケースを削除する（ステップＳ２０５）。その後、テストケース調整部１５１は、ステップＳ２０６に進む。ターゲットテストケース及び重複テストケースに基づくテストは、実行間隔が短い場合、同一の出力値が得られる可能性が高い。したがって、テストケース調整部１５１は、第１削除条件を満たす場合、重複テストケースを削除する。
【００９２】
なお、重複テストケースが複数存在する場合、テストケース調整部１５１は、実行間隔が第１閾値より小さい重複テストケースを削除する。
【００９３】
ステップＳ２０６では、テストケース調整部１５１は、ターゲットテストケースに基づくテストの実行結果として成功を示す出力値を得られる確率が第２閾値より大きく、かつ、前回の同一内容のテストケースに基づくテストの終了時刻からの経過時間が第３閾値より小さいか否かを判定する（ステップＳ２０６）。なお、第２閾値及び第３閾値は任意に設定できる。例えば、第２閾値は０．７、第３閾値は１時間と設定することができる。
【００９４】
以下の説明では、テストの実行結果として成功を示す出力値が得られる確率が第２閾値より大きいテストケースを成功テストケースと記載する。また、ステップＳ２０６の判定条件を第２削除条件と記載する。
【００９５】
第２削除条件を満たすと判定された場合、テストケース調整部１５１は、ターゲットテストケースを削除し（ステップＳ２０８）、その後、ステップＳ２０９に進む。前回のテストが完了してからの経過時間が短い成功テストケースに基づくテストを実行した場合、成功を示す出力値を得る可能性が高い。したがって、テストケース調整部１５１は、第２削除条件を満たす場合、成功テストケースを削除する。
【００９６】
第２削除条件を満たさないと判定された場合、テストケース調整部１５１は、ターゲットテストケースに基づくテストの実行結果として失敗を示す出力値が得られる確率が第４閾値より大きく、かつ、前回の同一内容のテストケースに基づくテストの終了時刻からの経過時間が第５閾値より小さいか否かを判定する（ステップＳ２０７）。なお、閾値は任意に設定できる。例えば、第４閾値は０．８５、第５閾値は２４時間と設定することができる。
【００９７】
以下の説明では、テストの実行結果として失敗を示す出力値が得られる確率が第４閾値より大きいテストケースを失敗テストケースと記載する。また、ステップＳ２０７の判定条件を第３削除条件と記載する。
【００９８】
第３削除条件を満たすと判定された場合、テストケース調整部１５１は、ターゲットテストケースを削除し（ステップＳ２０８）、その後、ステップＳ２０９に進む。前回のテストが完了してからの経過時間が短い失敗テストケースに基づくテストを実行した場合、失敗を示す出力値を得る可能性が高い。したがって、テストケース調整部１５１は、第３削除条件を満たす場合、失敗テストケースを削除する。
【００９９】
第３削除条件を満たさないと判定された場合、テストケース調整部１５１はステップＳ２０９に進む。
【０１００】
ステップＳ２０９では、テストケース調整部１５１は、ターゲットテストケースの後に実行されるテストケースが存在するか否かを判定する（ステップＳ２０９）。
【０１０１】
ターゲットテストケースの後に実行されるテストケースが存在すると判定された場合、テストケース調整部１５１は、ステップＳ２０２に戻り、新たなターゲットテストケースを選択し、同様の処理を実行する。
【０１０２】
ターゲットテストケースの後に実行されるテストケースが存在しないと判定された場合、テストケース調整部１５１はテストケース削減処理を終了する。
【０１０３】
本実施例では、前述のような削除条件に基づいてテストケースの数を減らすことによって、テスト時間の短縮及びテストに使用する計算機リソースの削減が可能となる。これによって、サービスの開発及び改善のサイクルの速度に合わせたテストの実行が可能となる。
【０１０４】
図１０は、実施例１のテスト環境構築部１５３が実行するテスト環境構築処理の一例を説明するフローチャートである。
【０１０５】
テスト環境構築部１５３は、生成されたテストケースを参照し（ステップＳ３０１）、テストケースに基づいて実行されるテストが参照系のテストのみであるか否かを判定する（ステップＳ３０２）。
【０１０６】
具体的には、テスト環境構築部１５３は、リスト７００に登録された全てのエントリのテスト内容７０１がデータ参照であるか否かを判定する。リスト７００に登録された全てのエントリのテスト内容７０１がデータ参照である場合、テスト環境構築部１５３は、実行されるテストが参照系のテストのみであると判定する。
【０１０７】
テストが参照系のテストのみであると判定された場合、テスト環境構築部１５３は処理を終了する。
【０１０８】
テストが参照系以外のテストを含むと判定された場合、テスト環境構築部１５３はテスト環境を構築する（ステップＳ３０３）。
【０１０９】
テスト環境の構築方法は、公知の技術を用いればよいため詳細な説明は省略する。なお、テスト環境が構築された場合、テスト制御部１１４は、更新系及び参照系のテストをテスト環境で実行するように制御してもよいし、更新系のテストはテスト環境で実行し、参照系のテストは実際のシステム環境で実行するように制御してもよい。
【０１１０】
次に、テスト環境構築部１５３は、テストが完了したか否かを判定する（ステップＳ３０４）。例えば、テスト環境構築部１５３は、テスト実行部１５２からテストの完了通知を受け付けた場合、テストが完了したと判定する。
【０１１１】
テストが完了していないと判定された場合、テスト環境構築部１５３は、テストが完了するまで待ち状態に移行する。
【０１１２】
テストが完了したと判定された場合、テスト環境構築部１５３は、テスト環境を破棄し（ステップＳ３０５）、その後、テスト環境構築処理を終了する。
【０１１３】
図１１は、実施例１の代替ＡＰＩ判定部１１５が実行する代替ＡＰＩ判定処理の一例を説明するフローチャートである。
【０１１４】
代替ＡＰＩ判定部１１５は、結果情報を参照して、実行されたテストに対応するエントリの値を読み出す（ステップＳ４０１）。例えば、代替ＡＰＩ判定部１１５は、現在時刻と実行時刻５０３との差が閾値より小さいエントリを、実行されたテストに対応するエントリとして特定できる。
【０１１５】
代替ＡＰＩ判定部１１５は、エントリで示されたＡＰＩ１０６のループ処理を開始する（ステップＳ４０２）。
【０１１６】
具体的には、代替ＡＰＩ判定部１１５は、実行したテストに対応するエントリの中から候補エントリを一つ選択する。また、代替ＡＰＩ判定部１１５は、新規ＡＰＩ１０６のテストケースの入力値及び出力値と、候補エントリに対応するＡＰＩ１０６のテストケースの入力値及び出力値とを比較する。以下の説明では、候補エントリに対応するＡＰＩ１０６を候補ＡＰＩ１０６と記載する。
【０１１７】
代替ＡＰＩ判定部１１５は、候補ＡＰＩ１０６のテストケースの入力値及び出力値が、新規ＡＰＩ１０６のテストケースの入力値及び出力値と完全に一致しているか否かを判定する（ステップＳ４０３）。
【０１１８】
候補ＡＰＩ１０６のテストケースの入力値及び出力値が、新規ＡＰＩ１０６のテストケースの入力値及び出力値と完全に一致していると判定された場合、代替ＡＰＩ判定部１１５は、新規ＡＰＩ１０６の代替ＡＰＩ１０６として候補ＡＰＩ１０６を互換情報１２１に登録する（ステップＳ４０４）。その後、代替ＡＰＩ判定部１１５はステップＳ４０６に進む。
【０１１９】
具体的には、代替ＡＰＩ判定部１１５は、互換情報１２１にエントリを追加し、追加されたエントリの代替元４０１に新規ＡＰＩ１０６の情報を設定する。また、代替ＡＰＩ判定部１１５は、追加されたエントリの代替先４０２に候補ＡＰＩ１０６の情報を設定する。
【０１２０】
候補ＡＰＩ１０６のテストケースの入力値及び出力値が、新規ＡＰＩ１０６のテストケースの入力値及び出力値と完全に一致していないと判定された場合、代替ＡＰＩ判定部１１５は、候補ＡＰＩ１０６への代替が可能であるか否かを判定する（ステップＳ４０５）。
【０１２１】
具体的には、代替ＡＰＩ判定部１１５は、判定ルールを適用し、新規ＡＰＩ１０６及び候補ＡＰＩ１０６のテストケースの入力値及び出力値のいずれかを置き換えて、同じ出力値が得られるか否かを判定する。例えば、以下に示す（１）、（２）、（３）に示すような判定ルールが考えられる。
【０１２２】
（１）新規ＡＰＩ１０６の引数の数（テストの入力値の数）が候補ＡＰＩ１０６の引数の数より多い場合、代替ＡＰＩ判定部１１５は、追加された引数にＮｕｌｌを入力し、新規ＡＰＩ１０６のテストケースの出力値を取得する。代替ＡＰＩ判定部１１５は、取得された出力値が候補ＡＰＩ１０６のテストケースの出力値と同一である場合、候補ＡＰＩ１０６への代替が可能であると判定する。
【０１２３】
例えば、候補ＡＰＩ１０６の引数がｉｎｔ＿ａ及びｓｔｒｉｎｇ＿ｂであり、新規ＡＰＩ１０６の引数がｉｎｔ＿ａ、ｓｔｒｉｎｇ＿ｂ、及びｓｔｒｉｎｇ＿ｃである場合、代替ＡＰＩ判定部１１５は、ｓｔｒｉｎｇ＿ｃにＮｕｌｌを入力した新規ＡＰＩ１０６のテストケースの出力値が、候補ＡＰＩ１０６のテストケースの出力値と一致するか否かを判定する。
【０１２４】
（２）新規ＡＰＩ１０６の変数及び候補ＡＰＩ１０６の変数が異なる場合、代替ＡＰＩ判定部１１５は、候補ＡＰＩ１０６の変数を新規ＡＰＩ１０６の変数に置き換えた候補ＡＰＩ１０６のテストケースの出力値を取得する。代替ＡＰＩ判定部１１５は、取得された出力値が新規ＡＰＩ１０６のテストケースの出力値と同一である場合、候補ＡＰＩ１０６への代替が可能であると判定する。
【０１２５】
例えば、候補ＡＰＩ１０６の変数がｉｎｔ＿ａ及びｓｔｒｉｎｇ＿ｂであり、新規ＡＰＩ１０６の変数がｉｎｔ＿ｘ及びｓｔｒｉｎｇ＿ｂである場合、代替ＡＰＩ判定部１１５は、ｉｎｔ＿ａをｉｎｔ＿ｘに置き換えた候補ＡＰＩ１０６のテストケースの出力値が新規ＡＰＩ１０６のテストケースの出力値と同一であるか否かを判定する。
【０１２６】
（３）新規ＡＰＩ１０６の出力値の形式が異なる場合、代替ＡＰＩ判定部１１５は、候補ＡＰＩ１０６の出力値の形式を新規ＡＰＩ１０６の出力値の形式に変換した候補ＡＰＩ１０６のテストケースの出力値を取得する。代替ＡＰＩ判定部１１５は、取得された出力値が新規ＡＰＩ１０６のテストケースの出力値と同一である場合、候補ＡＰＩ１０６への代替が可能であると判定する。
【０１２７】
例えば、候補ＡＰＩ１０６の出力値がｉｎｔ＿ｃ＝２及びｓｔｒｉｎｇ＿ｄ＝１００であり、新規ＡＰＩ１０６の出力値がｉｎｔ＿ｃ＝２及びｉｎｔ＿ｄ＝１００である場合、代替ＡＰＩ判定部１１５は、ｓｔｒｉｎｇ型の値をｉｎｔ型の値に変換した候補ＡＰＩ１０６のテストケースの出力値が新規ＡＰＩ１０６のテストケースの出力値と同一であるか否かを判定する。
【０１２８】
本実施例の代替ＡＰＩ判定部１１５には前述したような判定ルールが予め設定されているものとする。なお、外部から判定ルールが入力されてもよい。この場合、メモリ２０２に判定ルールが格納され、代替ＡＰＩ判定部１１５は、当該判定ルールを参照し、判定を行う。
【０１２９】
候補ＡＰＩ１０６への代替が可能でないと判定された場合、代替ＡＰＩ判定部１１５はステップＳ４０６に進む。
【０１３０】
候補ＡＰＩ１０６への代替が可能であると判定された場合、代替ＡＰＩ判定部１１５はステップＳ４０４に進む。
【０１３１】
ステップＳ４０６では、代替ＡＰＩ判定部１１５は、ステップＳ４０１で取得した全てのエントリについて処理が完了したか否かを判定する（ステップＳ４０６）。
【０１３２】
ステップＳ４０１で取得した全てのエントリについて処理が完了していないと判定された場合、代替ＡＰＩ判定部１１５は、ステップＳ４０２に戻り、新たな候補エントリを選択し、同様の処理を実行する。
【０１３３】
ステップＳ４０１で取得した全てのエントリについて処理が完了したと判定された場合、代替ＡＰＩ判定部１１５は代替ＡＰＩ判定処理を終了する。
【０１３４】
次に、アプリケーション１０１からリクエストを受信した場合のＡＰＩ集約装置１００の処理について説明する。図１２は、実施例１のＡＰＩ集約装置１００がアプリケーション１０１からリクエストを受信した場合に実行する処理を説明するフローチャートである。
【０１３５】
ＡＰＩ集約装置１００の受信部１１０は、アプリケーション１０１からリクエストを受信する（ステップＳ５０１）。リクエストには、マイクロサービス１０２を特定するための情報、ＡＰＩ１０６のバージョン、メソッド、ヘッダ情報、及び認証情報等が含まれる。マイクロサービス１０２を特定するための情報は例えばＵＲＬが考えられる。
【０１３６】
次に、ＡＰＩ集約装置１００の互換操作制御部１１２は、送信部１１１を介して、指定されたマイクロサービス１０２のＡＰＩ１０６にリクエストを送信する（ステップＳ５０２）。
【０１３７】
次に、ＡＰＩ集約装置１００の受信部１１０は、マイクロサービス１０２から応答を受信する（ステップＳ５０３）。受信部１１０は応答を互換操作制御部１１２に出力する。
【０１３８】
次に、ＡＰＩ集約装置１００の互換操作制御部１１２は、受信した応答が正常な応答であるか否かを判定する（ステップＳ５０４）。
【０１３９】
具体的には、互換操作制御部１１２は、応答に含まれるステータスコードに基づいて、受信した応答が正常な応答であるか否かを判定する。
【０１４０】
受信した応答が正常な応答であると判定された場合、互換操作制御部１１２は、送信部１１１を介して、アプリケーション１０１に受信した応答を送信する（ステップＳ５０５）。その後、互換操作制御部１１２は処理を終了する。
【０１４１】
受信した応答が正常な応答でないと判定された場合、互換操作制御部１１２は、互換情報１２１に、リクエストを送信したＡＰＩ１０６の代替ＡＰＩ１０６が登録されているか否かを判定する（ステップＳ５０６）。
【０１４２】
具体的には、互換操作制御部１１２の参照部１３１は、互換情報１２１の代替元４０１を参照し、リクエストの送信先のＡＰＩ１０６と一致する情報が設定されたエントリを検索する。エントリが存在する場合、参照部１３１は、リクエストを送信したＡＰＩ１０６の代替ＡＰＩ１０６が登録されていると判定する。
【０１４３】
リクエストを送信したＡＰＩ１０６の代替ＡＰＩ１０６が登録されていると判定された場合、互換操作制御部１１２の互換操作部１３２は、検索されたエントリの代替先４０２に対応する代替ＡＰＩ１０６にリクエストを送信する（ステップＳ５０７）。互換操作制御部１１２は、マイクロサービス１０２から応答を受信した後、互換操作制御部１１２は、ステップＳ５０５に進む。
【０１４４】
リクエストを送信したＡＰＩ１０６の代替ＡＰＩ１０６が登録されていないと判定された場合、互換操作制御部１１２は、テスト設定部１１３に対して代替ＡＰＩ選択処理の実行を指示する（ステップＳ５０８）。当該指示には、リクエストを送信したＡＰＩ１０６の名称及びバージョン等が含まれる。代替ＡＰＩ選択処理の詳細は図１３を用いて説明する。本実施例のＡＰＩ集約装置１００は、正常でない応答を送信したＡＰＩ１０６の代替ＡＰＩ１０６が互換情報１２１に登録されていないことを、代替ＡＰＩ１０６を特定するためのテストの実行契機として検知する。
【０１４５】
互換操作制御部１１２は、代替ＡＰＩ判定部１１５から処理の終了通知を受け付けるまで待ち状態に移行する。
【０１４６】
互換操作制御部１１２の参照部１３１は、代替ＡＰＩ判定部１１５から処理の終了通知を受け付けた場合、互換情報１２１に、リクエストを送信したＡＰＩ１０６の代替ＡＰＩ１０６が登録されているか否かを判定する（ステップＳ５０９）。ステップＳ５０９の処理はステップＳ５０６の処理と同一である。
【０１４７】
リクエストを送信したＡＰＩ１０６の代替ＡＰＩ１０６が登録されていると判定された場合、互換操作制御部１１２の互換操作部１３２は、ステップＳ５０７に進む。
【０１４８】
リクエストを送信したＡＰＩ１０６の代替ＡＰＩ１０６が登録されていないと判定された場合、互換操作制御部１１２の互換操作部１３２は、アプリケーション１０１にエラー応答を送信する（ステップＳ５１０）。その後、互換操作制御部１１２は処理を終了する。
【０１４９】
図１３は、実施例１のＡＰＩ集約装置１００が実行する代替ＡＰＩ選択処理を説明するフローチャートである。
【０１５０】
テスト設定部１１３は、互換操作制御部１１２から代替ＡＰＩ選択処理の実行指示を受け付ける（ステップＳ６０１）。ステップＳ６０２からステップＳ６０７の処理は、図６で説明したステップＳ１０２からステップＳ１０７の処理と同一であるため説明を省略する。ただし、リクエストを送信したＡＰＩ１０６に対して処理が実行される。
【０１５１】
実施例１によれば、ＡＰＩ集約装置１００は、新規ＡＰＩ１０６の追加時又はＡＰＩ１０６から正常な応答を得られなかった場合に、テストを実行し、テストの実行結果に基づいて、継続的にサービスの提供するために必要な互換情報１２１を自動的に生成及び更新できる。本実施例では、ＡＰＩ集約装置１００は、テストケースの数を削減することによって、サービスの開発及び改善のサイクルの速度に合わせたテストを実行できる。
【０１５２】
したがって、実施例１のＡＰＩ集約装置１００は、サービスの開発及び改善のサイクルの速度に合わせて、互換情報１２１を自動的に生成及び更新できる。
【実施例２】
【０１５３】
実施例２では、計算機システムの構成が異なる。具体的には、計算機システムは、複数のＡＰＩ集約装置１００を有する。以下、実施例１との差異を中心に実施例２について説明する。
【０１５４】
図１４Ａ及び図１４Ｂは、実施例２の計算機システムの構成例を示す図である。なお、アプリケーション１０１及びＡＰＩ集約装置１００の間のＡＰＩ１０５、並びにＡＰＩ集約装置１００及びマイクロサービス１０２の間のＡＰＩ１０６は、説明の簡単のため省略している。
【０１５５】
実施例２の計算機システムは、複数のＡＰＩ集約装置１００を有する。このような構成にすることによって、ＡＰＩ１０５、１０６の増加及びリクエストの増加に伴うＡＰＩ集約装置１００の負荷を分散することができる。なお、実施例２のＡＰＩ集約装置１００は、実施例１のＡＰＩ集約装置１００と同一の処理を実行する。
【０１５６】
アプリケーション１０１は、いずれかのＡＰＩ集約装置１００に対してリクエストを送信する。
【０１５７】
図１４Ａに示す計算機システムの場合、ＡＰＩ集約装置１００がアクセスするマイクロサービス１０２を予め設定し、また、マイクロサービス１０２にアクセスするためのＵＲＬ等をハッシュ関数に入力して算出されるハッシュ値をＡＰＩ集約装置１００に割り当てる。アプリケーション１０１は、前述のＵＲＬ等をハッシュ関数に入力してハッシュ値を算出し、算出されたハッシュ値に基づいて、アクセス先のＡＰＩ集約装置１００を決定する。ＡＰＩ集約装置１００は、リクエストを受信した場合、割り当てられたマイクロサービス１０２のＡＰＩ１０６にリクエストを送信する。
【０１５８】
図１４Ａに示すＡＰＩ集約装置１００は、担当するマイクロサービス１０２に関する互換情報１２１を保持する。なお、ＡＰＩ集約装置１００の障害に対応するために、各ＡＰＩ集約装置１００は、少なくとも一つのＡＰＩ集約装置１００に、互換情報１２１のコピーを送信する。
【０１５９】
図１４Ｂに示す計算機システムの場合、ＡＰＩ集約装置１００は各マイクロサービス１０２にアクセスできる。図１４Ｂに示す計算機システムは、各ＡＰＩ集約装置１００にリクエストを振り分けるロードバランサ１３００を有する。アプリケーション１０１は、ロードバランサ１３００にリクエストを送信する。ロードバランサ１３００は、負荷が分散するように各ＡＰＩ集約装置１００にリクエストを転送する。転送方式は、ラウンドロビン方式及びプロセッサ２０１の稼働率に基づく方式等が考えられる。
【０１６０】
図１４Ｂに示すＡＰＩ集約装置１００は、任意のタイミングで、互換情報１２１のコピーを他のＡＰＩ集約装置１００に送信する。すなわち、各ＡＰＩ集約装置１００が保持する互換情報１２１は、同期するように管理される。
【０１６１】
実施例２によれば、複数のＡＰＩ集約装置１００をシステムに含めることによって、ＡＰＩ集約装置１００の負荷の増大を回避できる。これによって、マイクロサービス１０２の応答の遅延等のマイクロサービス１０２を利用したサービスの品質低下を抑止できる。
【実施例３】
【０１６２】
実施例３では、テストケース削減処理が一部異なる。以下、実施例１との差異を中心に実施例３について説明する。
【０１６３】
実施例３のシステム構成は、実施例１と同一である。また、実施例３のＡＰＩ集約装置１００のハードウェア構成及びソフトウェア構成は、実施例１のＡＰＩ集約装置１００と同一である。
【０１６４】
実施例３の新規ＡＰＩ１０６が追加された場合に実行する処理の流れは、実施例１の処理の流れと同一である。実施例３のアプリケーション１０１からリクエストを受信した場合に実行する処理の流れは、実施例１の処理の流れと同一である。実施例３では、テストケース削減処理が一部異なる。
【０１６５】
図１５Ａ及び図１５Ｂは、実施例３のテストケース調整部１５１が実行するテストケース削減処理の一例を説明するフローチャートである。
【０１６６】
実施例３のステップＳ２０１からステップＳ２０９の処理は、実施例１の処理と同一である。実施例３では、ステップＳ２０９の処理が実行された後、テストケース調整部１５１は、テストケースを実行した場合のＡＰＩ集約装置１００の処理負荷を算出する（ステップＳ２５１）。
【０１６７】
テストケースを実行した場合のＡＰＩ集約装置１００の処理負荷を算出する方法は、公知の方法を用いればよい。例えば、各テストケースに必要なリソース量の合計値をＡＰＩ集約装置１００の処理負荷として算出する方法、又は各テストケースに必要なリソース量の最大値をＡＰＩ集約装置１００の処理負荷として算出する方法等が考えられる。
【０１６８】
テストケース調整部１５１は、算出された処理負荷が第６閾値より大きいか否かを判定する（ステップＳ２５２）。
【０１６９】
算出された処理負荷が第６閾値以下であると判定された場合、テストケース調整部１５１は、テストケース削減処理を終了する。
【０１７０】
算出された処理負荷が第６閾値より大きいと判定された場合、テストケース調整部１５１はテストケースのループ処理を開始する（ステップＳ２５３）。ステップＳ２５３の処理はステップＳ２０２の処理と同一である。
【０１７１】
テストケース調整部１５１は、ターゲットテストケースがネストのマイクロサービス１０２のテストケースであるか否かを判定する（ステップＳ２５４）。ステップＳ２５４の処理は、ステップＳ２０３の処理と同一である。
【０１７２】
ターゲットテストケースがネストのマイクロサービス１０２のテストケースであると判定された場合、テストケース調整部１５１は、重複テストケースが存在し、かつ、二つのテストケースに基づくテストの実行間隔が第７閾値より小さいか否かを判定する（ステップＳ２５５）。なお、第７閾値は、第１閾値より大きい値が設定される。
【０１７３】
以下の説明では、重複テストケースが存在し、かつ、二つのテストケースに基づくテストの実行間隔が第７閾値より小さいという条件を第４削除条件と記載する。
【０１７４】
第４削除条件を満たさないと判定された場合、テストケース調整部１５１は、ステップＳ２５９に進む。
【０１７５】
第４削除条件を満たすと判定された場合、テストケース調整部１５１は、重複テストケースを削除する（ステップＳ２５６）。
【０１７６】
次に、テストケース調整部１５１は、テストケースを実行した場合のＡＰＩ集約装置１００の処理負荷を算出する（ステップＳ２５７）。ステップＳ２５７の処理負荷の算出方法は、ステップＳ２５１の処理負荷の算出方法と同一である。
【０１７７】
テストケース調整部１５１は、算出された処理負荷が第６閾値より大きいか否かを判定する（ステップＳ２５８）。ステップＳ２５８の処理はステップＳ２５２と同一である。
【０１７８】
算出された処理負荷が第６閾値より大きいと判定された場合、テストケース調整部１５１は、ステップＳ２５９に進む。
【０１７９】
ステップＳ２５８では、テストケース調整部１５１は、ターゲットテストケースの後に実行されるテストケースが存在するか否かを判定する（ステップＳ２５９）。ステップＳ２５９の処理は、ステップＳ２０９の処理と同一である。
【０１８０】
算出された処理負荷が第６閾値以下であると判定された場合、テストケース調整部１５１は、テストケースのループ処理を終了し、その後、テストケース削減処理を終了する。
【０１８１】
実施例３によれば、テストケースに基づくテストの実行に伴うＡＰＩ集約装置１００の負荷を低減できる。これによって、マイクロサービス１０２の応答の遅延等のマイクロサービス１０２を利用したサービスの品質低下を抑止できる。
【０１８２】
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。また、例えば、上記した実施例は本発明を分かりやすく説明するために構成を詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、各実施例の構成の一部について、他の構成に追加、削除、置換することが可能である。
【０１８３】
また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、本発明は、実施例の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をコンピュータに提供し、そのコンピュータが備えるプロセッサが記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。
【０１８４】
また、本実施例に記載の機能を実現するプログラムコードは、例えば、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｊａｖａ（登録商標）等の広範囲のプログラム又はスクリプト言語で実装できる。
【０１８５】
さらに、実施例の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することによって、それをコンピュータのハードディスクやメモリ等の記憶手段又はＣＤ−ＲＷ、ＣＤ−Ｒ等の記憶媒体に格納し、コンピュータが備えるプロセッサが当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしてもよい。
【０１８６】
上述の実施例において、制御線や情報線は、説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていてもよい。
【符号の説明】
【０１８７】
１００  ＡＰＩ集約装置
１０１  アプリケーション
１０２  マイクロサービス
１０５、１０６  ＡＰＩ
１１０  受信部
１１１  送信部
１１２  互換操作制御部
１１３  テスト設定部
１１４  テスト制御部
１１５  代替ＡＰＩ判定部
１２０  フレームワーク情報
１２１  互換情報
１２２  結果情報
１３１  参照部
１３２  互換操作部
１４１  テストケース生成部
１４２  呼出部
１５１  テストケース調整部
１５２  テスト実行部
１５３  テスト環境構築部
２０１  プロセッサ
２０２  メモリ
２０３  ネットワークインタフェース
１３００  ロードバランサ
【図１】
2019101801.tif 000003
【図２】
2019101801.tif 000004
【図３】
2019101801.tif 000005
【図４】
2019101801.tif 000006
【図５Ａ】
2019101801.tif 000007
【図５Ｂ】
2019101801.tif 000008
【図６】
2019101801.tif 000009
【図７】
2019101801.tif 000010
【図８】
2019101801.tif 000011
【図９】
2019101801.tif 000012
【図１０】
2019101801.tif 000013
【図１１】
2019101801.tif 000014
【図１２】
2019101801.tif 000015
【図１３】
2019101801.tif 000016
【図１４Ａ】
2019101801.tif 000017
【図１４Ｂ】
2019101801.tif 000018
【図１５Ａ】
2019101801.tif 000019
【図１５Ｂ】
2019101801.tif 000020