(57)【要約】      （修正有）【課題】同じ障害が原因で複数のテストが不合格になった場合に、不合格の原因となった障害の解析を効率的に行える、ソフトウェアを自動的にテストする情報処理装置を提供する。【解決手段】情報処理システム１００において、情報処理装置は、テスト制御部、第１の判断部、第２の判断部、出力部、設定受付部及び記憶部を有する。テスト制御部は、テスト対象となるソフトウェアに関する複数のテストの実行を制御する。第１の判断部は、ソフトウェアのテストが不合格になった場合、不合格になったソフトウェアに機能面の特徴があるか否かを判断する。第２の判断部は、ソフトウェアのテストが不合格になった場合、不合格になったソフトウェアに現象面の特徴があるか否かを判断する。出力部は、複数のテストのうち、不合格になったテストにおける現象面の特徴と機能面の特徴とに基づいて、不合格の原因となった障害に関するテスト結果を出力する。【選択図】図４
2020123287.tif 000002
【特許請求の範囲】
【請求項１】
テスト対象となるソフトウェアをテストする情報処理装置であって、
前記ソフトウェアに関する複数のテストの実行を制御するテスト制御部と、
前記複数のテストのうち、不合格になったテストにおける現象面の特徴と機能面の特徴とに基づいて、前記不合格の原因となった障害に関するテスト結果を出力する出力部と、
を有する、情報処理装置。
【請求項２】
前記出力部は、前記現象面の特徴と前記機能面の特徴とに基づいて、前記不合格になったテストをグループ分けして前記テスト結果を出力する、請求項１に記載の情報処理装置。
【請求項３】
前記複数のテストは、所定の機能に関する１つ以上のテスト項目を含み、
前記所定の機能に関する１つ以上のテスト項目のうち、不合格になったテスト項目の数に基づいて、前記不合格になったテストに前記機能面の特徴があるか否かを判断する第１の判断部を有する、請求項１又は２に記載の情報処理装置。
【請求項４】
前記複数のテストで用いられる所定のコマンドで発生したエラーの発生回数に基づいて、前記不合格になったテストに前記現象面の特徴があるか否かを判断する第２の判断部を有する、請求項３に記載の情報処理装置。
【請求項５】
前記出力部は、前記不合格になったテストに前記現象面の特徴と前記機能面の特徴とがある場合、前記現象面の特徴を優先して前記テスト結果を出力する、請求項４に記載の情報処理装置。
【請求項６】
前記出力部は、前記不合格になったテストに前記現象面の特徴と前記機能面の特徴とがある場合、前記所定のコマンドに関する前記テスト結果を出力する、請求項４又は５に記載の情報処理装置。
【請求項７】
前記出力部は、
前記不合格になったテストに、前記機能面の特徴があり、かつ前記現象面の特徴がない場合、前記所定の機能に関する前記テスト結果を出力し、
前記不合格となったテストに、前記現象面の特徴があり、かつ前記機能面の特徴がない場合、前記所定のコマンドに関する前記テスト結果を出力する、
請求項４乃至６のいずれか一項に記載の情報処理装置。
【請求項８】
前記機能面の特徴があると判断する第１の閾値、又は前記現象面に特徴があると判断する第２の閾値の設定を受け付ける設定受付部を有する、請求項５乃至７のいずれか一項に記載の情報処理装置。
【請求項９】
テスト対象となるソフトウェアをテストするテスト方法であって、
コンピュータが、
前記ソフトウェアに関する複数のテストの実行を制御する処理と、
前記複数のテストのうち、不合格になったテストにおける現象面の特徴と機能面の特徴とに基づいて、前記不合格の原因となった障害に関するテスト結果を出力する処理と、
を実行する、テスト方法。
【請求項１０】
テスト対象となるソフトウェアをテストするコンピュータに、
前記ソフトウェアに関する複数のテストの実行を制御する処理と、
前記複数のテストのうち、不合格になったテストにおける現象面の特徴と機能面の特徴とに基づいて、前記不合格の原因となった障害に関するテスト結果を出力する処理と、
を実行させる、テストプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、テスト方法、及びテストプログラムに関する。
【背景技術】
【０００２】
テスト対象となるソフトウェアを自動的にテストして、テスト結果を出力するテストシステムが知られている。
【０００３】
また、ソフトウェア開発プロジェクトにおいて、バグを分析して、バグによる手戻り工数等から優先すべき課題を選定するバグ分析方法、及び装置が知られている（例えば、特許文献１参照）
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、テスト対象となるソフトウェアを自動的にテストするテストシステムでは、例えば、同じ障害（バグ）が原因で複数のテストが不合格になった場合でも、その原因が同じ障害であるか否かを自動的に判別することは困難である。従って、テストシステムは、同じ障害が原因で複数のテストが不合格になった場合でも、不合格になった全てのテストについて障害票を起票し、設計者は、起票された複数の障害票を解析して不合格の原因となった障害を判別しなければならないという問題がある。
【０００５】
本発明の一実施形態は、上記の問題点に鑑みてなされたものであって、ソフトウェアを自動的にテストする情報処理システムにおいて、同じ障害が原因で複数のテストが不合格になった場合に、不合格の原因となった障害の解析を効率的に行えるようにする。
【課題を解決するための手段】
【０００６】
上記目的を達成するため、本発明の一実施形態に係る情報処理装置は、テスト対象となるソフトウェアをテストする情報処理装置であって、前記ソフトウェアに関する複数のテストの実行を制御するテスト制御部と、前記複数のテストのうち、不合格になったテストにおける現象面の特徴と機能面の特徴とに基づいて、前記不合格の原因となった障害に関するテスト結果を出力する出力部と、を有する。
【発明の効果】
【０００７】
本発明の一実施形態によれば、ソフトウェアを自動的にテストする情報処理システムにおいて、同じ障害が原因で複数のテストが不合格になった場合に、不合格の原因となった障害の解析を効率的に行えるようになる。
【図面の簡単な説明】
【０００８】
【図１】一実施形態に係る情報処理システムのシステム構成の例を示す図である。
【図２】一実施形態に係るテストツールの構成例を示す図である。
【図３】一実施形態に係る情報処理装置のハードウェア構成の例を示す図である。
【図４】一実施形態に係る情報処理装置の機能構成の例を示す図である。
【図５】一実施形態に係るテスト仕様について説明するための図である。
【図６】一実施形態に係るテストケースの例について説明するための図である。
【図７】第１の実施形態に係る情報処理装置の処理の例を示すフローチャートである。
【図８】第２の実施形態に係る情報処理装置の処理の例を示すフローチャートである。
【発明を実施するための形態】
【０００９】
以下、本発明の実施形態について、図面を参照しながら詳細に説明する。
【００１０】
＜システム構成＞
（情報処理システムのシステム構成）
図１は、一実施形態に係る情報処理システムのシステム構成の例を示す図である。情報処理システム１００は、ソフトウェアを設計する設計者１０１等が、テスト対象となるソフトウェアをテスト（試験）するシステムである。
【００１１】
近年のソフトウェア開発においては、継続的インテグレーション（ＣＩ：Continuous Integration）と呼ばれるような、ビルドやテストを頻繁に繰り返し行うことにより問題を早期に発見し、開発の効率化、省電力化、納期の短縮等を図る手法が用いられる。ＣＩシステムにおいては、手続きを自動化すると共に、変更管理ツール１０２、テスト管理ツール１０６、障害管理ツール１０９等と連携することで、ワークフロー全体の効率化を図ることも行われる。なお、ＣＩシステムは、情報処理システム１００の一例である。
【００１２】
図１に示す情報処理システム１００において、設計者１０１は、テスト対象となるソフトウェアのソースコード１０３と、当該ソフトウェアをテストするテストコード１０７を作成して情報処理システム１００に登録する。
【００１３】
ビルドツール１０４、及びテストツール１０８は、予め定められたスケジュールに従ってビルドとテストを自動的に実行し、テスト結果が不合格である場合には、障害管理ツール１０９が、不合格になったテスト結果等を設計者１０１に通知する。このとき、障害管理ツール１０９は、変更管理ツール１０２、テスト管理ツール１０６等と連携することで、障害の対策状況のトラッキング等が可能である。
【００１４】
設計者１０１は、テスト結果が不合格であれば、障害（バグ）の解析を行い、必要に応じてソースコード１０３の修正、或いはテストコード１０７の修正を行う。障害の解析にあたって、設計者１０１は、例えば、どのテストケースでどのようなエラーが発生したか、またエラーが発生したときのログ情報等から障害を特定して対策を行う。
【００１５】
このようなフローを繰り返し実行することにより、設計者１０１は、常にテスト結果が合格となる状態を維持する。これにより、設計者１０１は、テスト対象となるソフトウェア（成果物）をいつでもリリースできる状態に保つことができるので、ソフトウェアをタイムリーに市場にリリースすることができる。
【００１６】
（テストツールの構成例）
図２は、一実施形態に係るテストツールの構成例を示す図である。ここでは、一例として、組み込み系のソフトウェア開発におけるテストツールについて説明する。組み込み系のソフトウェア開発における自動テストは、基本的には対象となる対象機器２０２で、テスト対象オブジェクト１０５を実行させることでテストを行う。ここで、「対象機器」には、実際にソフトウェアが実装される電子機器（以下、「実機」と呼ぶ）だけではなく、実機の動作をエミュレートしたエミュレータも含まれる。
【００１７】
また、テスト対象オブジェクト１０５を対象機器２０２で実行させる方法には、一例として、図２（ａ）に示すように、テストツール１０８から、対象機器２０２上のテストランナー２０３を使って、テスト対象オブジェクト１０５とテストコード１０７とを実行させる方法がある。また、別の一例として、図２（ｂ）に示すように、テストツール１０８がテストコード１０７を実行し、対象機器２０２が公開しているインタフェース（Ｉ／Ｆ：Interface）を用いて、テスト対象オブジェクト１０５を操作する方法もある。図２（ａ）に示す方法は、主にホワイトボックス的なテストに用いられ、図３（ｂ）に示す方法は、主にブラックボックス的なテストに用いられることが多い。
【００１８】
上記の構成において、情報処理システム１００は、例えば、テストを自動実行し、テストが不合格になったときに、自動的に障害票を起票して設計者１０１に通知する。このような情報処理システム１００において、例えば、同じ障害（バグ）が原因で複数のテストが不合格になった場合、その原因が同じ障害であることを、情報処理システム１００が自動的に判別することは困難である。従って、情報処理システム１００は、不合格になった全てのテストについて障害票を起票することになり、設計者１０１は、複数の障害票を解析して、不合格になった複数のテストの原因が同じ障害によるものであることを判別しなければならないという問題がある。
【００１９】
このとき、例えば、情報処理システム１００が、発生した障害の現象から、同じ現象の障害を「同一の障害」としてグループ分け（グルーピング）して、設計者１０１に通知する方法が考えられる。しかし、この方法だけでは、同じ現象の障害が、同じ原因によるものであるとは限らないので、潜在的な障害（バグ）を見逃してしまう場合がある。
【００２０】
また、別の方法として、情報処理システム１００が、基本的な機能のテストと、枝葉の機能のテストとを分けて、基本的な機能のテストを先に行うことで、障害票の大量の起票を抑制する方法も考えられる。しかし、この方法では、どの機能が基本的な機能であり、どの機能が枝葉の機能であるのかを分類する必要がある。また、この方法では、基本的な機能のテストで不合格になった場合には、他の機能のテストができなくなってしまうという問題もある。
【００２１】
そこで、本実施形態に係る情報処理システム１００では、テストを自動実行し、テストが不合格になったときに、不合格になったテストにおける現象面の特徴と、機能面の特徴とに基づいて、不合格の原因となった障害に関するテスト結果を出力する。
【００２２】
好ましくは、情報処理システム１００は、不合格になったテストにおける現象面の特徴と機能面の特徴とに基づいて、不合格になったテスト（例えば、障害票等）をグループ分けしてテスト結果を出力する。
【００２３】
ここで、機能面の特徴には、例えば、テスト対象となるソフトウェアの機能仕様書に記載されている「機能」に関する特徴等が含まれる。例えば、情報処理システム１００は、機能仕様書に記載されている所定の機能に関する１つ以上のテスト項目のうち、不合格になったテスト項目の数に基づいて、不合格になったテストに機能的な特徴があるか（例えば、所定の機能に問題があるか）否かを判断する。
【００２４】
また、現象面の特徴には、例えば、テストに用いられる所定のコマンドで発生した「現象」に関する特徴等が含まれる。例えば、情報処理システム１００は、ソフトウェアのテストで用いられる所定のコマンドで発生したエラーの発生回数に基づいて、不合格になったテストに現象的な特徴があるか（同じ現象のエラーが発生しているか）否かを判断する。なお、コマンドには、例えば、所定の手順の実行を指示する命令や、所定のハードウェアへのアクセスを指示する命令等の様々な命令が含まれ得る。
【００２５】
具体的な一例として、所定のコマンドでエラーが複数回発生している等の現象面の特徴がある場合、情報処理システム１００は、機能面の特徴より優先して、現象面の特徴に関するテスト結果を設計者１０１に通知する。これは、特定のコマンドでエラーが多発している場合、テスト対象となる機能に対して適切なテストを行えない可能性が高いと考えられるためである。
【００２６】
例えば、テスト対象となる機器がスキャン機能、コピー機能、プリンタ機能、ファクシミリ機能等を一つの筐体に搭載したＭＦＰ（Multifunction Peripheral）であるものとする。また、ＭＦＰのソフトウェアのテストにおいて、スキャン機能のテストで不合格が発生しているが、実際には、準備作業に含まれるアドレス帳登録コマンドが原因でエラーが発生していたものとする。このようなときに、本実施形態に係る情報処理システム１００によれば、スキャン機能の担当者ではなく、アドレス帳機能の担当者に障害解析を依頼することが容易になる。なお、具体的な処理内容については後述する。
【００２７】
＜ハードウェア構成＞
図２は、一実施形態に係る情報処理装置のハードウェア構成の例を示す図である。図１に示す変更管理ツール１０２、ビルドツール１０４、テスト管理ツール１０６、テストツール１０８、及び障害管理ツール１０９等は、例えば、図２に示すようなコンピュータ構成を備えた情報処理装置３００、又は複数の情報処理装置３００で実行される。
【００２８】
情報処理装置３００は、例えば、ＣＰＵ（Central Processing Unit）３０１、ＲＯＭ（Read Only Memory）３０２、ＲＡＭ（Random Access Memory）３０３、ＨＤ（Hard Disk）３０４、ＨＤＤ(Hard Disk Drive)コントローラ３０５、ディスプレイ３０６、外部機器接続Ｉ／Ｆ３０７、ネットワークＩ／Ｆ３０８、キーボード３０９、ポインティングデバイス３１０、ＤＶＤ−ＲＷ(Digital Versatile Disk Rewritable)ドライブ３１２、メディアＩ／Ｆ３１４、及びバスライン３１５等を備えている。
【００２９】
これらのうち、ＣＰＵ３０１は、情報処理装置３００の全体の動作を制御する。ＲＯＭ３０２は、例えば、ＩＰＬ（Initial Program Loader）等のＣＰＵ３０１の起動に用いられるプログラムを記憶する。ＲＡＭ３０３は、ＣＰＵ３０１のワークエリアとして使用される。ＨＤ３０４は、プログラム等の各種データを記憶する。ＨＤＤコントローラ３０５は、ＣＰＵ３０１の制御に従ってＨＤ３０４に対する各種データの読み出し又は書き込みを制御する。
【００３０】
ディスプレイ３０６は、カーソル、メニュー、ウィンドウ、文字、又は画像などの各種情報を表示する。外部機器接続Ｉ／Ｆ３０７は、各種の外部機器を接続するためのインタフェースである。外部機器には、例えば、ＵＳＢ（Universal Serial Bus）メモリやプリンタ等に加え、テストの対象となる対象機器２０２等が含まれる。ネットワークＩ／Ｆ３０８は、通信ネットワークを利用してデータ通信をするためのインタフェースである。なお、情報処理装置３００は、ネットワークＩ／Ｆ３０８を介して、対象機器２０２を制御しても良い。
【００３１】
キーボード３０９は、文字、数値、各種指示などの入力のための複数のキーを備えた入力手段の一種である。ポインティングデバイス３１０は、各種指示の選択や実行、処理対象の選択、カーソルの移動などを行う入力手段の一種である。ＤＶＤ−ＲＷドライブ３１２は、着脱可能な記録媒体の一例としてのＤＶＤ−ＲＷ３１１に対する各種データの読み出し又は書き込みを制御する。なお、ＤＶＤ−ＲＷ３１１は、ＤＶＤ−ＲＷに限らず、ＤＶＤ−Ｒ等であっても良い。メディアＩ／Ｆ３１４は、フラッシュメモリ等のメディア３１３に対するデータの読み出し又は書き込み（記憶）を制御する。バスライン３１５は、上記の各構成要素を電気的に接続するためのアドレスバス、データバス及び各種の制御信号等を含む。
【００３２】
＜機能構成＞
続いて、情報処理装置３００の機能構成について説明する。
【００３３】
図４は、一実施形態に係る情報処理装置の機能構成の例を示す図である。情報処理装置３００は、例えば、図３のＣＰＵ３０１で所定のテストプログラムを実行することにより、テスト制御部４０１、第１の判断部４０２、第２の判断部４０３、出力部４０４、設定受付部４０５、及び記憶部４０６等を実現している。なお、上記の各機能構成のうち、少なくとも一部は、ハードウェアによって実現されるものであっても良い。
【００３４】
テスト制御部４０１は、例えば、図３のＣＰＵ３０１で実行されるテストツール１０８等によって実現され、テスト対象となるソフトウェアに関する複数のテストの実行を制御する。
【００３５】
第１の判断部４０２は、例えば、図３のＣＰＵで実行される障害管理ツール１０９等のテストプログラムによって実現され、ソフトウェアのテストが不合格になった場合、不合格になったソフトウェアに機能面の特徴があるか否かを判断する。例えば、第１の判断部４０２は、所定の機能に関する１つ以上のテスト項目のうち、不合格になったテスト項目の数に基づいて、不合格になったテストに機能面の特徴があるか（例えば、所定の機能に問題があるか）否かを判断する。
【００３６】
図５は、一実施形態に係るテスト仕様について説明するための図である。例えば、機能合致性を検証するためのテストケースを作成する場合、設計者１０１は、テスト対象となるソフトウェアの機能仕様５０１に対して、テストケースを設計することになる。例えば、図５の機能仕様５０１における機能Ａのサブ機能Ａ−１をテストする場合、図５のテスト仕様４１１に示すように、機能Ａのサブ機能Ａ−１に関する１つ以上のテスト項目をテストする。同様に、機能仕様５０１における機能Ａのサブ機能Ａ−２をテストする場合、テスト仕様４１１に示すように、機能Ａのサブ機能Ａ−２に関する１つ以上のテスト項目をテストする。
【００３７】
好ましくは、第１の判断部４０２は、例えば、テスト仕様４１１において、所定の機能に関する複数のテスト項目が定義されている場合、不合格になったテスト項目の数が、予め設定された第１の閾値以上のとき、所定の機能に機能面の特徴があると判断する。なお、所定の機能に関するテスト項目が１つである場合には、所定の機能に関するテスト項目が不合格であるときに、所定の機能に機能面の特徴があると判断しても良い。
【００３８】
第２の判断部４０３は、例えば、図３のＣＰＵで実行される障害管理ツール１０９等のテストプログラムによって実現され、ソフトウェアのテストが不合格になった場合、不合格になったソフトウェアに現象面の特徴があるか否かを判断する。例えば、第２の判断部４０３は、所定のコマンドで発生したエラーの発生回数に基づいて、不合格になったテストに現象面の特徴があるか（例えば、所定のコマンドに問題があるか）否かを判断する。
【００３９】
図６は、一実施形態に係るテストケースの例について説明するための図である。例えば、所定の機能に関するテストを行う場合、テストシナリオの実行に先立って、事前条件や事後条件を明確にし、テストを実行する。例えば、図６のテストケース６０１に示すように、所定の機能に関するテストを行う「テストシナリオ」の前後で、「事前条件」、「事後条件」等を自動的に実行する。
【００４０】
なお、テストケース６０１に含まれる各手順の自動実行は、様々な方法で実行可能である。例えば、多くの場合、対象機器２０２を提供しているメーカが、ビルドツール１０４と同じように、テストのための様々ツールを提供しているので、これらのツールを用いて、テスト対象オブジェクト１０５を操作することができる。また、例えば、テスト対象オブジェクト１０５が、外部に提供しているＩ／Ｆを、テストケース６０１に含まれる各手順の自動実行に用いることもできる。なお、当該Ｉ／Ｆは、別のテストケースでは、テスト対象となる場合がある。
【００４１】
好ましくは、第２の判断部４０３は、ソフトウェアのテストにおいて、所定のコマンド（例えば、手順Ｂ１の実行命令等）で発生したエラーの発生回数が第２の閾値以上のとき、不合格になったソフトウェアに現象面の特徴があると判断する。
【００４２】
出力部４０４は、例えば、図３のＣＰＵで実行される障害管理ツール１０９等のテストプログラムによって実現される。出力部４０４は、複数のテストのうち、不合格になったテストにおける現象面の特徴と機能面の特徴とに基づいて、不合格の原因となった障害に関するテスト結果を出力する。
【００４３】
例えば、出力部４０４は、不合格になったテストに、機能面の特徴と現象面の特徴とがある場合、機能面の特徴よりも現象面の特徴を優先して、所定のコマンド（手順）に障害があることを示すテスト結果を出力する。
【００４４】
また、出力部４０４は、不合格になったテストに、機能面の特徴があり、かつ現象面の特徴がない場合、所定の機能に関するテスト結果を出力する。さらに、出力部４０４は、不合格になったテストに、現象面の特徴があり、かつ機能面の特徴がない場合、所定のコマンドに関するテスト結果を出力する。
【００４５】
好ましくは、出力部４０４は、不合格になったテストにおける現象面の特徴と機能面の特徴とに基づいて、不合格になったテスト（又は障害票等）をグループ分けして、テスト結果として出力する。例えば、出力部４０４は、不合格になったテストにおける現象面の特徴と機能面の特徴とに基づいて、同じ障害が原因と考えられる複数の障害票をグルーピングして出力する。
【００４６】
設定受付部４０５は、例えば、図３のＣＰＵで実行される障害管理ツール１０９等のテストプログラムによって実現され、前述した第１の閾値又は第２の閾値の設定を受け付ける。例えば、設定受付部４０５は、図３のディスプレイ３０６等の表示部に、第１の閾値又は第２の閾値を設定するための設定画面を表示させて、設計者１０１等による、第１の閾値又は第２の閾値の設定操作を受け付ける。また、設定受付部４０５は、受け付けた第１の閾値又は第２の閾値を、記憶部４０６に設定値４１３として記憶する。なお、設定受付部４０５は、他の情報処理装置等から、第１の閾値又は第２の閾値の設定要求を受け付けるものであっても良い。
【００４７】
記憶部４０６は、例えば、図３のＣＰＵで実行されるプログラム、及びＨＤＤコントローラ３０５、ＨＤ３０４等によって実現され、テストコード１０７、テスト仕様４１１、テスト結果４１２、及び設定値４１３等を記憶する。
【００４８】
なお、図４の例では、図１のテストツール１０８及び障害管理ツール１０９に関する機能構成について説明を行ったが、情報処理装置３００は、図１の変更管理ツール１０２、ビルドツール１０４、及びテスト管理ツール１０６等をさらに実行しても良い。なお、変更管理ツール１０２、ビルドツール１０４、及びテスト管理ツール１０６等の機能構成は、一般的なツールと同様で良いので、ここでは説明を省略する。
【００４９】
＜処理の流れ＞
続いて、各実施形態に係るテスト方法の処理の流れについて説明する。
【００５０】
［第１に実施形態］
図７は、第１の実施形態に係る情報処理装置の処理の例を示すフローチャートである。この処理は、情報処理装置３００が、テスト制御部４０１により、テスト対象となるソフトウェアに関する複数のテストを実行した後、不合格になったテストがある場合に実行する処理の一例を示している。
【００５１】
ステップＳ７０１において、情報処理装置３００の第１の判断部４０２は、不合格になったテストにおける機能面の特徴を抽出する。例えば、第１の判断部４０２は、図５に示すようなテスト仕様４１１を参照して、不合格になったテストに対応する機能等を抽出する。一例として、図５に示すテスト仕様４１１において、テスト項目「境界値テスト正常系」が不合格になった場合、第１の判断部４０２は、不合格になったテスト項目に対応するサブ機能「Ａ−１」等を抽出する。
【００５２】
ステップＳ７０２において、情報処理装置３００の第２の判断部４０３は、不合格になったテストにおける現象面の特徴を抽出する。例えば、第２の判断部４０３は、不合格になったテストでエラーが発生したコマンド、及び当該コマンドで発生したエラーの回数等を抽出する。
【００５３】
ステップＳ７０３において、第１の判断部４０２は、不合格になったテストに機能面の特徴があるか否かを判断する。例えば、第１の判断部４０２は、ステップＳ７０１で抽出した機能に関する１つ以上のテスト項目のうち、不合格になったテスト項目の数が、予め設定された第１の閾値以上のとき、不合格になったテストに機能面の特徴があると判断する。
【００５４】
不合格になったテストに機能面の特徴がある場合、情報処理装置３００は、処理をステップＳ７０４に移行させる。一方、不合格になったテストに機能面の特徴がない場合、情報処理装置３００は、処理をステップＳ７０５に移行させる。
【００５５】
ステップＳ７０４に移行すると、第２の判断部４０３は、不合格になったテストに、現象面の特徴があるか否かを判断する。例えば、第２の判断部４０３は、ステップＳ７０２で抽出したコマンドで発生したエラーの回数が、予め設定された第２の閾値以上のとき、不合格になったテストに現象面の特徴があると判断する。
【００５６】
不合格になったテストに現象面の特徴がない場合、情報処理装置３００は、処理をステップＳ７０５に移行させる。一方、不合格になったテストに現象面の特徴がある場合、情報処理装置３００は、処理をステップＳ７０７に移行させる。
【００５７】
ステップＳ７０５に移行すると、出力部４０４は、特定機能のデグレードを指摘するテスト結果を出力する。例えば、出力部４０４は、ステップＳ７０３で機能面の特徴があると判断された機能のデグレードを指摘する障害票等を出力する。
【００５８】
ステップＳ７０３からステップＳ７０６に移行すると、第２の判断部４０３は、例えば、ステップＳ７０４と同様にして、不合格になったテストに、現象面の特徴があるか否かを判断する。
【００５９】
不合格になったテストに現象面の特徴がある場合、情報処理装置３００は、処理をステップＳ７０７に移行させる。一方、不合格になったテストに現象面の特徴がない場合、情報処理装置３００は、処理を終了させる。
【００６０】
ステップＳ７０７に移行すると、情報処理装置３００の出力部４０４は、特定手順のデグレードを指摘するテスト結果を出力する。例えば、出力部４０４は、ステップＳ７０２で抽出したコマンド（特定手順の一例）のデグレードを指摘する障害票等を出力する。
【００６１】
このように、情報処理装置３００の出力部４０４は、不合格になったテストにおける現象面の特徴と機能面の特徴とに基づいて、不合格の原因となった障害に関するテスト結果を出力する。
【００６２】
これにより、本実施形態に係る情報処理システム１００によれば、不合格になったテストの機能面の特徴と現象面の特徴とに基づいて、解析すべき優先順位を設計者１０１に提示することができるので、設計者１０１による障害解析をより効率化することができる。
【００６３】
［第２の実施形態］
図８は、第２の実施形態に係る情報処理装置の処理の例を示すフローチャートである。この処理は、情報処理装置３００が、テスト制御部４０１により、テスト対象となるソフトウェアに関する複数のテストを実行した後、不合格になったテストがある場合に実行する処理の別の一例を示している。なお、基本的な処理内容は、図７に示す第１の実施形態に係る情報処理装置の処理と同様なので、ここでは、第１の実施形態と同様の処理に対する詳細な説明は省略する。
【００６４】
ステップＳ８０１において、情報処理装置３００の第１の判断部４０２は、不合格になったテストにおける機能面の特徴を抽出する。なお、複数のテストが不合格になった場合、第１の判断部４０２は、不合格になった複数のテストの各々について、機能面の特徴を抽出する。
【００６５】
ステップＳ８０２において、情報処理装置３００の第２の判断部４０３は、不合格になったテストにおける現象面の特徴を抽出する。なお、複数のテストが不合格になった場合、第２の判断部４０３は、不合格になった複数のテストの各々について、現象面の特徴を抽出する。
【００６６】
ステップＳ８０３において、第１の判断部４０２は、不合格になったテストの各々について、機能面の特徴があるか否かを判断する。
【００６７】
ここで、機能面の特徴があると判断されたテストについて、情報処理装置３００は、ステップＳ８０４の処理を実行する。また、機能面の特徴がないと判断されたテストについて、情報処理装置３００は、ステップＳ８０６の処理を実行する。
【００６８】
ステップＳ８０４において、第２の判断部４０３は、不合格になったテストのうち、機能面の特徴があると判断されたテストの各々について、現象面の特徴があるか否かを判断する。
【００６９】
ここで、現象面の特徴がないと判断されたテストについて、情報処理装置３００は、ステップＳ８０５の処理を実行する。また、現象面の特徴があると判断されたテストについて、情報処理装置３００は、ステップＳ８０７の処理を実行する。
【００７０】
ステップＳ８０５において、情報処理装置３００の出力部４０４は、特定機能のデグレードを指摘する障害票（テスト結果の一例）を作成する。例えば、出力部４０４は、ステップＳ８０３で機能面の特徴があると判断され、ステップＳ８０４で現象面の特徴がないと判断されたテストの各々について、第１の閾値以上の試験項目が不合格となった機能に障害があることを示す障害票を作成する。
【００７１】
一方、ステップＳ８０６において、第２の判断部４０３は、不合格になったテストのうち、機能面の特徴がないと判断されたテストの各々について、現象面の特徴があるか否かを判断する。
【００７２】
ここで、現象面の特徴があると判断されたテストについて、情報処理装置３００は、ステップＳ８０７の処理を実行する。なお、現象面の特徴がないと判断されたテストについては、情報処理装置３００は、特に処理は行わずに、ステップＳ８０８に処理を移行させる。
【００７３】
ステップＳ８０７において、出力部４０４は、特定手順のデグレードを指摘する障害票を作成する。
【００７４】
例えば、出力部４０４は、ステップＳ８０３で機能面の特徴があると判断され、ステップＳ８０４で現象面の特徴があると判断されたテストの各々について、第２の閾値以上エラーが発生したコマンド（特定手順の一例）のデグレードを指摘する障害票を作成する。
【００７５】
また、出力部４０４は、ステップＳ８０３で機能面の特徴がないと判断され、ステップＳ８０４で現象面の特徴があると判断されたテストの各々について、第２の閾値以上エラーが発生したコマンド（特定手順の一例）のデグレードを指摘する障害票を作成する。
【００７６】
ステップＳ８０８において、出力部４０４は、ステップＳ８０５、及びステップＳ８０７で作成した障害票を、障害内容に応じてグループ分け（グルーピング）して出力する。例えば、出力部４０４は、所定の機能に障害があると判断された複数の障害票を１つのグループにまとめて出力する。また、出力部４０４は、所定の現象に障害があると判断された複数の障害票を１つのグループにまとめて出力する。
【００７７】
このように、情報処理装置３００の出力部４０４は、不合格になったテストの試験結果（障害票）を、現象面の特徴と機能面の特徴とに基づいて、障害内容に応じてグルーピングして出力する。
【００７８】
これにより、本実施形態に係る情報処理システム１００によれば、不合格になったテストの機能面の特徴と現象面の特徴とに基づいて、解析すべき優先順位を設計者１０１に提示することができるので、設計者１０１による障害解析をより効率化することができる。
【００７９】
＜適用例＞
続いて、第２の実施形態に係るソフトウェアのテスト方法の具体的な適用例について説明する。
【００８０】
ここでは、一例として、対象機器２０２が、スキャン機能、コピー機能、プリンタ機能、ファクシミリ機能等を一つの筐体に搭載したＭＦＰ（Multifunction Peripheral）等の画像形成装置であるものとして、以下の説明を行う。
【００８１】
ただし、対象機器２０２は、画像形成装置に限られず、情報処理システム１００によるテスト対象となるソフトウェアを実行する様々な機器であって良い。例えば、対象機器２０２は、ＰＪ（Projector：プロジェクタ）、ＩＷＢ（Interactive White Board：相互通信が可能な電子式の黒板機能を有する白板）、デジタルサイネージ、ＨＵＤ（Head Up Display）装置等の出力装置であっても良い。また、対象機器２０２は、例えば、産業機械、撮像装置、集音装置、医療機器、ネットワーク家電、自動車（Connected Car）、デジタルカメラ、ウェアラブル端末等の機器であっても良い。さらに、対象機器２０２は、例えば、ノートＰＣ、携帯電話、スマートフォン、タブレット端末、ゲーム機、ＰＤＡ（Personal Digital Assistant）、デジタルカメラ、ウェアラブルＰＣデスクトップＰＣ等の汎用の情報処理装置であっても良い。
【００８２】
例えば、ＭＦＰにおけるスキャン機能を実現するソフトウェアのテストを考えた場合、スキャン機能には、例えば、「スキャン ｔｏ メール機能」、「スキャン ｔｏ フォルダ機能」、「ＯＣＲ（Optical Character Recognition）機能」等の様々な機能がある。
【００８３】
また、「スキャン ｔｏ メール機能」にも、例えば、「スキャン条件設定」、「メール宛先設定」等の複数のサブ機能が含まれる。例えば、機能合致性のテストを行う場合、これらの機能仕様に対応するテストケースを作成することが一般的である。
【００８４】
一例として、「スキャン ｔｏ メール機能」の「スキャン条件設定」のテストケースを作成する場合、様々スキャン条件で、実際にスキャン結果がメール送信されるかどうかをテストする方法が考えられる。このとき、本来テストしたいのは、「スキャン条件」として、「両面指定」、「カラー指定」、「解像度指定」等の設定が、設定通りに動作するかどうかであるが、これらの機能を実行するためには、事前条件として予め実行すべき手順がある。例えば、事前条件には、「メール送信サーバが設定されていること」、「送信先のメールアドレスが登録されていること」等が含まれる。
【００８５】
自動テストの環境においては、これらの事前条件を整える処理も自動で行う必要があるため、本来のテスト対象である「スキャン ｔｏ メール機能」を実行する前に、例えば、「メール送信サーバの設定」の手順でテストが不合格になることがある。この例では、事前条件とテスト対象との因果関係が比較的明確であるが、大量のテストケースを設計・実行する際には、様々な手順でテストが実行されるので、その因果関係を事前に明確にしておくことは困難である。
【００８６】
このような場合、本発明の各実施形態を適用して、不合格となったテストにおける機能面の特徴と現象面の特徴の両方を加味して、解析すべき優先順位を示すテスト結果を設計者１０１に提示することで、障害解析を効率化することができる。
【００８７】
例えば、「スキャン ｔｏ メール機能」の「スキャン条件設定」のテストケースが１００件あって、前回のビルドでは全てのテストに合格していたものとする。また、今回のビルドでは、当該テストケースのうち、３０件以上のテストが不合格になったものとする。このような場合、情報処理装置３００は、「スキャン条件設定」機能が何かしらのデグレードを起こした可能性があるということを、機能面の特徴として抽出することが考えられる。なお、上記の「３０件」は一例であり、機能面の特徴があると判断する第１の閾値は、任意の値に設定可能である。
【００８８】
一方で、この３０件のテストケースで不合格となった現象を集計し、例えば、３０件の全てが「アドレス帳登録」コマンドでエラーが発生しているものとする。このような場合、情報処理装置３００は、「アドレス帳登録」コマンドが何かしらのデグレードを起こした可能性があるということを、現象面の特徴として抽出することが考えられる。
【００８９】
また、情報処理装置３００は、このような機能面の特徴、及び現象面の特徴が抽出できた場合に、これらの３０件の障害をグルーピングして、例えば、「アドレス帳登録コマンドのデグレードの疑い」として設計者に提示する。これにより、より適切な設計者１０１（例えば、アドレス帳登録コマンドの設計者等）に解析を促すことができるので、障害解析をより効率化することができる。
【００９０】
なお、上記の例では、テストが機能合致性テストであるものとして説明したが、これに限られない。例えば、ソフトウェアの内部構造がテスト対象であれば、その対象となる構造面での特徴を抽出すれば良い。例えば、状態遷移の網羅テストで障害が検出された場合は、その網羅テストに示す不合格の割合を特徴として抽出すること等が考えられる。
【００９１】
以上、本発明の各実施形態によれば、ソフトウェアを自動的にテストする情報処理システム１００において、同じ障害が原因で複数のテストが不合格になった場合に、不合格の原因となった障害の解析を効率的に行えるようになる。
【００９２】
＜補足＞
上記で説明した各実施形態の各機能は、一又は複数の処理回路によって実現することが可能である。ここで、本明細書における「処理回路」とは、電子回路により実装されるプロセッサのようにソフトウェアによって各機能を実行するようプログラミングされたプロセッサや、上記で説明した各機能を実行するよう設計されたＡＳＩＣ（Application Specific Integrated Circuit）、ＤＳＰ（digital signal processor）、ＦＰＧＡ（field programmable gate array）や従来の回路モジュール等のデバイスを含むものとする。
【符号の説明】
【００９３】
１００      情報処理システム
３００      情報処理装置
４０１      テスト制御部
４０２      第１の判断部
４０３      第２の判断部
４０４      出力部
４０５      設定受付部
【先行技術文献】
【特許文献】
【００９４】
【特許文献１】特開２００５−２２２１０８号公報
【図１】
2020123287.tif 000003
【図２】
2020123287.tif 000004
【図３】
2020123287.tif 000005
【図４】
2020123287.tif 000006
【図５】
2020123287.tif 000007
【図６】
2020123287.tif 000008
【図７】
2020123287.tif 000009
【図８】
2020123287.tif 000010