JP5513263B2

JP5513263B2 - 情報処理装置及びその制御方法、プログラム

Info

Publication number: JP5513263B2
Application number: JP2010128272A
Authority: JP
Inventors: 明日可和田
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2010-06-03
Filing date: 2010-06-03
Publication date: 2014-06-04
Anticipated expiration: 2030-06-03
Also published as: US8683427B2; US20110302552A1; JP2011253465A

Description

本発明は、複数のソフトウェアコンポーネントを組み合わせてソフトウェアを構築する情報処理システムに関し、特に、ソフトウェアコンポーネント単位でのテスト作業を支援するコンポーネントテスト支援技術に関するものである。

昨今の大規模ソフトウェアシステムの開発では、しばしば１つのシステムをそれぞれ固有の単位機能を有する複数のソフトウェアコンポーネント（以下、コンポーネントと称す）に分割して開発する手法がとられる。ここで、システム全体の機能をコンポーネントに分割する方法の１つとして、過去にシステムを構築した際の分割ノウハウをパターンとして蓄積しておき、新たに同様なシステムを開発する際にこれを適用する方法がある。

例えば、Ｐｉｐｅｓ＆Ｆｉｔｅｒｓパターンと称される分割方法では、入力されたデータに何らかの変換を加えて出力する処理（以下、この処理をフィルタ処理と称す）を単位機能と考え、データの流れに沿ってコンポーネントに分割する（非特許文献１）。この分割方法は、フィルタ処理コンポーネントの交換や組み合わせの変更によりシステムが実現する機能の切替や拡張を可能とし、映像ストリーム処理システム等の多くの場面に適用される。また、システム全体に対して特定の分割パターンを適用しなくとも、将来の機能拡張を想定し、変更可能性の高い機能を個別のコンポーネントとして分割する方法がある。逆に、複数のシステムで共通して利用可能な機能をコンポーネントとして分割する方法もある。

ここで、いずれの方法で分割されたシステムにおいても、機能は異なるが同一の処理フローを実現する類似のコンポーネント群が存在する場合が多い。上述のＰｉｐｅｓ＆Ｆｉｔｅｒｓパターンを適用したシステムにおいては、フィルタ処理コンポーネント群がこの類似のコンポーネント群に相当する。

一方で、複数のコンポーネントによって構成されるシステムの品質を確保するためには、一般に複数の粒度のテストがくり返し実施される。例えば、コンポーネント単位で実施する単体テスト、複数のコンポーネントのまとまりで実施する結合テスト、システム全体を統合して実施するシステムテストという形で段階的に範囲を広げながらテストが実施される。ここで、例えば、単体テストを十分に実施しなかった結果としてコンポーネント単体の品質が低いと、これが波及しシステム全体の品質も低下する。そこで、各粒度でのテストを効率よく進め、システムの品質を確保するために、テストケースのトレーサビリティを向上させ結合テストの結果を単体テストにフィードバックする方法がある（特許文献１）。

特開２００５−２４２７５１号公報

ソフトウェアアーキテクチャ、近代科学社、２０００年、ｐ．５２

コンポーネントの単体テストを考えた場合、あるコンポーネントが他のコンポーネントに提供する機能（以下、インタフェースと称す）の呼び出し順は、重複呼び出しを考慮した場合には無限の組み合わせが存在する。また、各インタフェースの引数に代入する値の組み合わせも膨大であるため、すべての組み合わせに対してコンポーネントの単体テストを実施することは困難である。

そこで、一般には、重要なテストケース・バグの発見が期待されるテストケースに絞り単体テストを実施する。例えば、インタフェースの呼び出し順に関しては正常シナリオと典型的な異常シナリオに絞り単体テストを実施する。また、引数については、例えば、２変数の組み合わせのみ網羅し、同値分割や境界値分析等を利用して無限のパラメータ値を有限な値に置換することで、効率・効果的なテストを実施する。しかしながら、これらの方法によるテストケースの絞込み作業は、対象システムに対する過去の経験や個人のスキルに依存する部分も多く、その結果、テストの抜け漏れが発生していた。

ここで、上述のＰｉｐｅｓ＆Ｆｉｔｅｒｓパターンを構成するフィルタ処理コンポーネント群のような類似のコンポーネント間では、あるコンポーネントＡでバグが発見された場合、同様のバグが別のコンポーネントＢに含まれている可能性が高まる。このような場合は、コンポーネントＡの開発・テスト担当者からコンポーネントＢの開発・テスト担当者に対してバグの内容を伝達することにより、コンポーネントＢにて同様のバグが発生していないかを確認することが可能である。より具体的には、コンポーネントＢの担当者は、コンポーネントＡでバグが発見されたテストと同様のテストをコンポーネントＢでも実施済みであるかを確認し、実施していない場合はテストケースを追加することでバグの可能性を潰すことが可能である。

しかしながら、多数の類似するコンポーネントで構成されるシステムの場合、類似するコンポーネントの組み合わせが多数存在し、担当者間のコミュニケーションに依存した相互の確認作業には限界が生ずる。その結果、コンポーネント間に品質の差が生じ、システム全体の品質の低下を招く。

本発明は上記の課題を解決するためになされたものであり、その目的は、複数のコンポーネントが連携動作する情報処理システムにおける、コンポーネント単体及びシステム全体の品質を向上することである。

上記の目的を達成するための本発明による情報処理装置は以下の構成を備える。即ち、
複数のソフトウェア部品であるコンポーネントが連携動作することにより実現される１つのシステムにおける、前記コンポーネントのテストを支援する情報処理装置であって、
コンポーネントに対するインタフェースの呼び出し順を記述する、コンポーネントのテストケースを格納するテストケース格納部と、
前記コンポーネントが提供するインタフェースの分類情報を格納するインタフェース分類情報格納部と、
前記テストケース格納部に格納されている前記コンポーネントのテストケースから、前記インタフェース分類情報格納部に格納されているインタフェースの分類情報を用いて、前記テストケースに含まれるコンポーネント固有の情報を取り除き、抽象度を高めた表現に変換したものであるモデル化テストケースを作成するモデル化テストケース作成部と、
前記モデル化テストケース作成部が作成するモデル化テストケースを、複数のコンポーネント間で比較することで差分となるモデル化テストケースを抽出するモデル化テストケース比較抽出部と
を備える。

本発明によれば、複数のコンポーネントが連携動作する情報処理システムにおける、コンポーネント単体及びシステム全体の品質を向上することができる。より具体的には、あるコンポーネントの単体テストで利用するテストケースをもとに、類似する他のコンポーネントのテストケースを追加することで、コンポーネント単体、及びシステム全体の品質を向上することができる。

実施形態１のテスト支援システムの構成を示すブロック図である。本発明の適用対象とするソフトウェアシステムの一例を示す図である。実施形態１のコンポＡのテストケース群の一例を示す図である。実施形態１のコンポＡのインタフェース分類情報の一例を示す図である。実施形態１のコンポＡのモデル化テストケース群の一例を示す図である。実施形態１のコンポＢのテストケース群の一例を示す図である。実施形態１のコンポＢのインタフェース分類情報の一例を示す図である。実施形態１のコンポＢのモデル化テストケース群の一例を示す図である。実施形態１のテスト支援手順のフローチャートである。実施形態１のモデル化テストケース群の作成手順のフローチャートである。実施形態１のモデル化テストケース群の抽出手順のフローチャートである。実施形態２に関るテスト支援システムの構成を示すブロック図である。実施形態２のテスト支援手順のフローチャートである。実施形態２の重要テストケースの抽出手順のフローチャートである。実施形態２のテストケース群の作成・追加手順のフローチャートである。実施形態３のテスト支援手順のフローチャートである。

＜発明の概要＞
本発明は、複数のソフトウェア部品であるコンポーネントが連携動作することにより１つのシステムを実現する情報処理技術に向けられたものである。特に、本発明では、コンポーネント単位で実施する単体テストで利用するテストシナリオやテスト結果をもとに、類似する他のコンポーネントのテストシナリオを追加し、コンポーネント単体、及びシステム全体の品質を向上する。

例えば、ストリームのフィルタ処理を提供するビデオデコードコンポーネント（コンポーネントＡ）、及び高画質化処理コンポーネント（コンポーネントＢ）が存在すると想定する。この場合において、コンポーネントＡに対する単体テストでは、
１．ストリーム処理開始
２．ストリーム処理停止
３．ストリームパラメータ設定
というシーケンスを有するテストケースでバグが発見されたとする。この場合には、コンポーネントＢに対しても同類のシーケンスを有する複数のテストケースを追加する。

このように、コンポーネントＡでバグが発見されたテストケースと類似のテストケースをコンポーネントＢに自動的に追加可能とすることで、以下のような効果を得ることができる。

・各コンポーネントの品質を相互に向上させることが可能となる。

・システムの品質が向上する。

また、本発明は、他のアーキテクチャパターンを採用したソフトウェアシステムに対しても同様に適用可能である。例えば、対話型アプリケーションに多く採用されるＭｏｄｅｌ−Ｖｉｅｗ−Ｃｏｎｔｒｏｌｌｅｒパターンでは、単一システム内に複数のＶｉｅｗコンポーネントが存在する。そこで、これらのＶｉｅｗコンポーネントに対して、本発明を適用することでこれらのコンポーネント間で品質を相互に向上させることが可能である。

以下、本発明の実施形態について図面を用いて詳細に説明する。但し、本発明の技術的範囲がこの実施形態に限定されるものではない。

＜実施形態１＞
図１は実施形態１のコンポーネントテスト支援システムの構成を示すブロック図である。

１０１はテストケース格納部であり、コンポーネント単位で実施される単体テストのテストケースを格納する。ここで、テストケースとは、テスト対象となるコンポーネントに対するインタフェースの呼び出し順が何らかの方法により記述されたオブジェクトを示すものである。

具体的には、テストケースは、例えば、プログラム言語を用いて記述されたソースコードであっても良いし、ＸＭＬ等を用いた記述や、特定のテストツール上の記述であっても良い。また、テストケースは、テストを実施したい事象（イベント）の数だけ別項に定義され、１つのコンポーネントに対して複数のテストケース（以降、これを単にテストケース群と称す）が定義される。格納するテストケース群は、テストケース格納部１０１内の記憶部にあらかじめ記憶しておいても良いし、テストケース格納部１０１内に入力部を設け、ユーザからの入力を記憶部に逐次記憶しても良い。入力部としては、例えば、キーボード、マウス、ディジタイザ、タッチパネル、ジョイスティック等の多様な操作機器が想定されるが、実施形態１では、これらの入力部の配置や有無を規定しない。

１０２はインタフェース分類情報格納部であり、インタフェースの分類情報を格納する。このインタフェースの分類情報は、複数のコンポーネント間で共通に利用され、また、１つのインタフェースに対して１ないし複数の分類情報が割り当てられる。格納するインタフェースの分類情報は、インタフェース分類情報格納部１０２の記憶部にあらかじめ記憶しておいても良いし、インタフェース分類情報格納部１０２内に入力部を設け、ユーザからの入力を記憶部に逐次記憶しても良い。入力部としては、テストケース格納部１０１の入力部と同様、多様な操作機器が想定されるが、実施形態１ではこれらの入力部の配置や有無を規定しない。また、テストケース格納部１０１内の入力部と、インタフェース分類情報格納部１０２内の入力部をハードウェア構成上において共通利用してもよい。

１０３はモデル化テストケース作成部である。モデル化テストケース作成部１０３は、テストケース格納部１０１に格納されているコンポーネントのテストケース群を、インタフェース分類情報格納部１０２に格納されているインタフェース分類情報を用いて変換することで、モデル化テストケースを作成する。

１０４はモデル化テストケース比較抽出部であり、モデル化テストケース作成部１０３が作成するモデル化テストケース群を複数のコンポーネント間で比較し、その差分、つまり、一方のコンポーネントにのみ定義されているモデル化テストケースを抽出する。

尚、図１のシステムを実現するハードウェア構成としては、汎用のコンピュータ（情報処理装置）で実現することができる。この汎用コンピュータに搭載される標準的な構成要素（例えば、ＣＰＵ、ＲＡＭ、ＲＯＭ、ハードディスク、外部記憶装置、ネットワークインタフェース、ディスプレイ、キーボード、マウス等）を有している。

図２は実施形態１の情報処理システムの構造の一例を示す図である。本システムは、例えば、映像ストリーム処理システムのように、入力ストリームに対するＤｅｍｕｘ（デマルチプレクサ）、デコード、高画質化処理等のフィルタ処理をくり返すことによって出力ストリームに変換するような処理系を想定している。

制御コンポーネント２０１は、複数のフィルタ処理コンポーネント２０２〜２０４との相互作用をくり返しながら、システム全体の処理シーケンスを進めるコンポーネントである。

フィルタ処理コンポーネント２０２〜２０４はそれぞれ、入力ストリームに対する各種フィルタ処理を担う。ここで、各フィルタ処理コンポーネント２０２〜２０４は、それぞれがシステムに対して提供する機能は異なるものの、システム内での配置や他コンポーネントとの関連、制御コンポーネント２０１との相互作用の手順など類似の構成を有する。そのため、各フィルタ処理コンポーネントがそれぞれ独立して単体テストを実施する場合においても、単体テストに含まれるテストケースの構成は類似する。以下、フィルタ処理コンポーネント２０２（以下、単にコンポＡと称す）とフィルタ処理コンポーネント２０３（以下、単にコンポＢと称す）を例に、コンポＡに定義したテストケースの一部をコンポＢに適用する場面を想定し説明を続ける。

図３は実施形態１のテストケース格納部１０１に格納されるコンポＡのテストケース群の一例を示す図である。

テストケース３０１では、コンポＡの基本テストケースの１つとしてＴｅｓｔＣａｓｅＡ１（）が定義され、それぞれのインタフェースの返値を期待値と確認することを想定した記述がなされている。

行３０２では、コンポＡに定義されているインタフェースｃｏｍｐｏＡＯｐｅｎ（）を呼び出すことが記述されている。行３０３では、インタフェースｃｏｍｐｏＡＳｔａｒｔ（）を、引数ｐａｒａｍＡ１を伴って呼び出すことが記述されている。

図４は実施形態１のインタフェース分類情報格納部１０２に格納されるコンポＡのインタフェース分類情報の一例を示している。

列４０１はコンポＡのインタフェース定義を示し、コンポＡが外部コンポーネントに公開しているインタフェースが一覧として示される。例えば、コンポＡが図２に示す情報処理システムで利用される場合、列４０１に示すインタフェースを制御コンポーネント２０１が呼び出すことにより、システム内の処理が進行する。

列４０２は、列４０１に示すコンポＡのインタフェース定義の各行に対応するインタフェース分類情報を示している。この例では、インタフェース分類情報は、インタフェース分類番号（１〜５）と、インタフェース分類番号を補足する付加的な説明とで表現している。この付加的な説明としては、図４では、前処理、後処理、処理の開始、処理の停止、パラメータ設定の少なくとも１つがある。

行４０３〜行４０６は、コンポＡのインタフェース定義とインタフェース分類情報の対応付けを示している。行４０３は、コンポＡに定義されているインタフェースｃｏｍｐｏＡＯｐｅｎ（）がインタフェース分類番号１として分類されることを示している。行４０４は、コンポＡに定義されているインタフェースｃｏｍｐｏＡＣｌｏｓｅ（）がインタフェース分類番号２として分類されることを示している。

行４０５は、コンポＡに定義されているインタフェースｃｏｍｐｏＡＳｔａｒｔ（）をインタフェース分類番号３及び５として分類することを示している。ここで、インタフェースｃｏｍｐｏＡＳｔａｒｔ（）は、該当インタフェースの呼び出しの中でパラメータｐａｒａｍＡ１の設定を行なっている。このようなインタフェースについては、パラメータの設定とインタフェースの呼び出しの本体を分けて考え、パラメータの設定を実施した後にインタフェースの本体を呼び出すというシーケンスに置換してインタフェース分類情報を割り当てている。

行４０６は、コンポＡに定義されているインタフェースｃｏｍｐｏＡＳｔｏｐ（）がインタフェース分類番号４として分類されることを示している。

図５は実施形態１のモデル化テストケース作成部１０３によって作成されるコンポＡに関するモデル化テストケース群を示す図である。

モデル化テストケース５０１の例は、テストケース３０１にインタフェース分類情報４０２を適用し、変換した結果である。ここで、テストケースからモデル化テストケースへの変換とは、テストケースに含まれるコンポーネント固有の情報（インタフェース名やインタフェースの構成）を取り除き、抽象度を高めた表現に置換する作業を示している。

図６は実施形態１のテストケース格納部１０１に格納されるコンポＢのテストケース群の一例を示す図である。

テストケース６０１では、コンポＢの基本テストケースの１つとしてＴｅｓｔＣａｓｅＢ２（）が定義され、それぞれのインタフェースの返値を期待値と確認することを想定した記述がなされている。

図７は実施形態１のインタフェース分類情報格納部１０２に格納されるコンポＢのインタフェース分類情報の一例を示している。

列７０１はコンポＢのインタフェース定義を示し、コンポＢが外部コンポーネントに公開しているインタフェースが一覧として示される。

列７０２は、列７０１に示すコンポＢのインタフェース定義の各行に対応するインタフェース分類情報を示している。ここで、先に示したコンポＡに適用するインタフェース分類情報４０２と、コンポＢに適用するインタフェース分類情報７０２は、同一の分類情報を用いなければならない。

行７０３〜行７０７は、コンポＡのインタフェース定義とインタフェース分類情報の対応付けを示している。行７０３は、コンポＢに定義されているインタフェースｃｏｍｐｏＢＩｎｉｔｉａｌｉｚｅ（）をインタフェース分類番号１として分類することを示している。以下、行７０４〜行７０６についても、各行で定義されているインタフェース定義に対して、対応するインタフェース分類番号が対応付けられている。

図８は実施形態１のモデル化テストケース作成部１０３によって作成されるコンポＢに関するモデル化テストケース群を示す図である。

モデル化テストケース８０１の例は、テストケース６０１にインタフェース分類情報７０２を適用し、変換した結果である。

図９は実施形態１のコンポーネントテスト支援手順のフローチャートである。以下では、本フローチャートに沿って、図２〜図８の具体例を交えながら説明する。

ステップＳ９０１で、モデル化テストケース作成部１０３は、テストケース格納部１０１に格納されているコンポＡのテストケース群を、インタフェース分類情報格納部１０２に格納されているコンポＡのインタフェース分類情報を用いて変換する。これにより、モデル化テストケース作成部１０３は、モデル化テストケース群Ａを作成する。

ステップＳ９０２で、モデル化テストケース作成部１０３は、テストケース格納部１０１に格納されているコンポＢのテストケース群を、インタフェース分類情報格納部１０２に格納されているコンポＢのインタフェース分類情報を用いて変換する。これにより、モデル化テストケース作成部１０３は、モデル化テストケース群Ｂを作成する。

ステップＳ９０３で、モデル化テストケース比較抽出部１０４は、ステップＳ９０１で作成されたモデル化テストケース群Ａの中から、ステップＳ９０２で作成されたモデル化テストケース群Ｂに含まれないモデル化テストケースを抽出する。

図１０は実施形態１のモデル化テストケース作成部１０３によるモデル化テストケース群の作成手順の詳細を示すフローチャートである。これは、図９のステップＳ９０１及びステップＳ９０２に対応する。ここで、ステップＳ９０１とステップＳ９０２には、どちらも同一の処理を適用できるが、これらの２つの処理は、処理の入力となるテストケース群とインタフェース分類情報とが異なる。以降では、ステップＳ９０１、つまり、コンポＡに対して処理が実施されたとして説明する。コンポＡの処理を実施する場合の入力は、図３に例示するテストケース群と図４に例示するインタフェース分類情報である。

まず、ステップＳ１００１で、モデル化テストケース作成部１０３は、初期化処理として、変数ｎに０（ｎ＝０）を設定する。

ステップＳ１００２で、モデル化テストケース作成部１０３は、以降のステップＳ１００３からステップＳ１０１４までの処理を、テストケース格納部１０１に格納されているコンポＡのテストケースの数Ｎだけくり返す。

ステップＳ１００３で、モデル化テストケース作成部１０３は、テストケース格納部１０１に格納されているコンポＡのテストケースから新たに１つのテストケースを取り出し、これをＳｅｑ［ｎ］とする。同時に、モデル化テストケース作成部１０３は、初期化処理として、変数ｉ及び変数ｊに０を設定する。コンポＡの具体例では、テストケース３０１が取り出されたとして、以降の処理を説明する。

ステップＳ１００４で、モデル化テストケース作成部１０３は、以降のステップＳ１００５からステップＳ１０１２までの処理を、Ｓｅｑ［ｎ］に定義されているインタフェースの呼び出し数Ｉだけくり返す。

ステップＳ１００５で、モデル化テストケース作成部１０３は、Ｓｅｑ［ｎ］の先頭から順にインタフェース呼び出しを１つ取り出し、Ｓｅｑ［ｎ］［ｉ］とする。コンポＡの具体例では、インタフェース呼び出し３０３が取り出された場合について処理を説明する。

ステップＳ１００６で、モデル化テストケース作成部１０３は、ステップＳ１００５で取り出されたインタフェース呼び出しがインタフェース分類情報に定義されているかを判定する。ここで、定義されていると判定した場合（ステップＳ１００６でＹＥＳ）、ステップＳ１００７に進む。一方、定義されていないと判定した場合（ステップＳ１００６でＮＯ）、ステップＳ１０１０に進む。上記の具体例では、該当するインタフェース分類情報が行４０５に定義されているため、ステップＳ１００７に進む。

ステップＳ１００７で、モデル化テストケース作成部１０３は、ステップＳ１００８の処理を、該当するインタフェース分類情報に定義されているインタフェース分類情報の数だけくり返す。コンポＡの具体例では、行４０５にインタフェース分類情報が２つ定義されているため、くり返し数は２である。

ステップＳ１００８で、モデル化テストケース作成部１０３は、ステップＳ１００５で取り出されたインタフェース呼び出しに対するインタフェース分類情報をＡｂｓｔＳｅｑ［ｎ］［ｊ］に保持する。また、モデル化テストケース作成部１０３は、変数ｊをインクリメントする。

ステップＳ１０１０で、インタフェース呼び出しがインタフェース分類情報に定義されていない場合、モデル化テストケース作成部１０３は、ＡｂｓｔＳｅｑ［ｎ］［ｊ］に該当するインタフェース分類情報が存在しなかったことを示す“ｏｔｈｅｒ”を保持する。また、モデル化テストケース作成部１０３は、変数ｊをインクリメントする。但し、このステップＳ１０１０は省略しても良いし、処理内容を変更しても良い。いずれにせよ、ステップＳ１０１０の処理内容に、実施形態１を実施する期間における一貫性があれば良い。

ステップＳ１０１１で、モデル化テストケース作成部１０３は、変数ｉをインクリメントする。ステップＳ１０１３で、モデル化テストケース作成部１０３は、変数ｎをインクリメントする。

以上、ステップＳ１００１からステップＳ１０１４の処理を実施した結果として、コンポＡの例では、モデル化テストケース５０１をはじめとするモデル化テストケース群がモデル化テストケース作成部１０３に保持される。

また、図９の処理をコンポＢについて適用することで、コンポＢの例では、モデル化テストケース８０１をはじめとするモデル化テストケース群がモデル化テストケース作成部１０３に保持される。

図１１は実施形態１のモデル化テストケース作成部１０３に保持されるコンポＡのモデル化テストケース群とコンポＢのモデル化テストケース群の比較手順の詳細を示すフローチャートである。これは、図９のステップＳ９０３に対応する。以降は、モデル化テストケース作成部１０３に、コンポＡに関するモデル化テストケース群（図５）とコンポＢに関するモデル化テストケース群（図８）が保持されているとして処理を説明する。

まず、ステップＳ１１０１で、モデル化テストケース比較抽出部１０４は、初期化処理として、変数ｎａに０（ｎａ＝０）を設定する。

ステップＳ１１０２で、モデル化テストケース比較抽出部１０４は、以降のステップＳ１１０３からステップＳ１１１６までの処理を、モデル化テストケース作成部１０３に格納されているコンポＡのモデル化テストケースの数ＮＡだけくり返す。

ステップＳ１１０３で、モデル化テストケース比較抽出部１０４は、モデル化テストケース作成部１０３から新たに１つのコンポＡのモデル化テストケースを取り出し、ＡｂｓｔＳｅｑ［ｎａ］とする。同時に、モデル化テストケース比較抽出部１０４は、初期化処理として、変数ｎｂに０（ｎｂ＝０）を設定する。上記の具体例では、モデル化テストケース５０１が取り出されたとして、以降の処理を説明する。

ステップＳ１１０４で、モデル化テストケース比較抽出部１０４は、以降のステップＳ１１０５からステップＳ１１１３までの処理を、モデル化テストケース作成部１０３に格納されているコンポＢのモデル化テストケースの数ＮＢだけくり返す。

ステップＳ１１０５で、モデル化テストケース比較抽出部１０４は、モデル化テストケース作成部１０３から新たに１つのコンポＢのモデル化テストケースを取り出し、ＡｂｓｔＳｅｑ［ｎｂ］とする。同時に、モデル化テストケース比較抽出部１０４は、初期化処理として、変数ｊに０（ｊ＝０）を設定する。上記の具体例では、モデル化テストケース８０１が取り出されたとして、以降の処理を説明する。

ステップＳ１１０６で、モデル化テストケース比較抽出部１０４は、以降のステップＳ１１０７からステップＳ１１１０までの処理を、ＡｂｓｔＳｅｑ［ｎａ］が保持するインタフェース分類情報の数Ｊだけくり返す。上記の具体例では、モデル化テストケース５０１はインタフェース分類情報を５つ保持しているため、くり返し数は５である。

ステップＳ１１０７で、モデル化テストケース比較抽出部１０４は、ＡｂｓｔＳｅｑ［ｎａ］及びＡｂｓｔＳｅｑ［ｎｂ］からそれぞれ順にインタフェース分類情報を取り出し、ＡｂｓｔＳｅｑ［ｎａ］［ｉ］、ＡｂｓｔＳｅｑ［ｎｂ］［ｉ］とする。

ステップＳ１１０８で、モデル化テストケース比較抽出部１０４は、ステップＳ１１０７で取り出されたコンポＡ及びコンポＢに関するインタフェース分類情報が等しいかを判定する。ここで、等しいと判定した場合（ステップＳ１１０８でＹＥＳ）、ステップＳ１１０９に進む。一方、等しくない、すなわち、異なると判定した場合（ステップＳ１１０８でＮＯ）、ステップＳ１１１２に進む。上記の具体例では、最初に取り出されるインタフェース分類情報がともに‘１’であるため、ステップＳ１１０９に進む。

ステップＳ１１０９で、モデル化テストケース比較抽出部１０４は、変数ｊをインクリメントする。

ステップＳ１１１１に到達する場合は、ＡｂｓｔＳｅｑ［ｎａ］とＡｂｓｔＳｅｑ［ｎｂ］のインタフェース分類情報の並びが完全に一致している場合である。そのため、モデル化テストケース比較抽出部１０４は、ＡｂｓｔＳｅｑ［ｎａ］をモデル化テストケース群Ｂに含まれるモデル化テストケースであると判定する。上記の具体例では、コンポＡのモデル化テストケース５０１とコンポＢのモデル化テストケース８０１のインタフェース分類情報の並びが完全に一致しているため、ステップＳ１１１１に到達し、モデル化テストケース群Ｂに含まれると判定される。

ステップＳ１１１２に到達する場合は、ＡｂｓｔＳｅｑ［ｎａ］とＡｂｓｔＳｅｑ［ｎｂ］のインタフェース分類情報の並びが異なっている場合である。そのため、モデル化テストケース比較抽出部１０４は、コンポＢから次のモデル化テストケースを取り出すためにｎｂをインクリメントし、次の比較処理に備える。

ステップＳ１１１４に到達する場合は、ＡｂｓｔＳｅｑ［ｎａ］がコンポＢに対するすべてのモデル化テストケースと一致しない場合である。そのため、モデル化テストケース比較抽出部１０４は、ＡｂｓｔＳｅｑ［ｎａ］をモデル化テストケース群Ｂに含まれないモデル化テストケースであると判定する。

ステップＳ１１１５で、モデル化テストケース比較抽出部１０４は、変数ｎａをインクリメントする。

以上、ステップＳ１１０１からステップＳ１１１６の処理を実施した結果として、モデル化テストケース群Ａの中から、モデル化テストケース群Ｂに含まれないモデル化テストケースが抽出される。また、ステップＳ１１０１からステップＳ１１１６では、インタフェース分類情報の並びが同一である場合のみ定義済みのモデル化テストケースと判定しているが、これに限定されない。例えば、モデル化テストケースの一部のみ一致している場合にも定義済みのモデル化テストケースと判定しても良い。あるいは、モデル化テストケースの一部が同一である場合に類似のモデル化テストケースと判定しても良い。

以上説明したように、実施形態１によれば、類似するコンポＡ、コンポＢにそれぞれ定義されているテストケースをモデル化テストケースに変換し、これらを比較することで、コンポＡのみに定義されているモデル化テストケースを抽出可能となる。

また、実施形態１では、図２の情報処理システムを構成するフィルタ処理コンポーネントを例に処理の詳細を説明しているが、本実施形態は他の構成の情報処理システムにも適用可能であり、情報処理システムを構成によって限定されるものではない。

＜実施形態２＞
以下、本発明の実施形態２について、実施形態１との差異を中心に説明する。但し、本発明の技術的範囲がこの実施形態に限定されるものではない。

図１２は実施形態２のコンポーネントテスト支援システムの構成を示すブロック図である。

１２０１はテストケース格納部であり、実施形態１のテストケース格納部１０１と同様にコンポーネント単位で実施される単体テストのテストケースを格納する。１２０２はテスト結果格納部であり、テストケース格納部１２０１に格納されたテストケースを実際に動作させて得られるテスト結果を格納する。１２０３は重要テストケース抽出格納部であり、テスト結果格納部１２０２に格納されたテスト結果に基づいて、テストケース格納部１２０１より重要テストケースを選定し、格納する。

１２０４はインタフェース分類情報格納部であり、実施形態１のインタフェース分類情報格納部１０２と同様にインタフェースの分類情報を格納する。１２０５はモデル化テストケース作成部である。モデル化テストケース作成部１２０５は、格納されているコンポーネントのテストケースを、インタフェース分類情報格納部１２０４に格納されているインタフェース分類情報を用いて変換することで、モデル化テストケースを作成する。ここでの格納されているコンポーネントのテストケースとは、テストケース格納部１２０１もしくは重要テストケース抽出格納部１２０３に格納されているコンポーネントのテストケースである。

１２０６はモデル化テストケース比較抽出部であり、実施形態１のモデル化テストケース比較抽出部１０４と同様、モデル化テストケース作成部１２０５が作成するモデル化テストケースを、複数のコンポーネント間で比較する。そして、モデル化テストケース比較抽出部１２０６は、その比較によって得られる、その差分、つまり、一方のコンポーネントにのみ定義されているモデル化テストケースを抽出する。

１０２７はテストケース作成部であり、モデル化テストケース比較抽出部１２０６により抽出されたモデル化テストケースにインタフェース分類情報格納部１２０４に格納されているインタフェース分類情報を適用することによってテストケースを作成する。

図１３は実施形態２のコンポーネントテスト支援手順のフローチャートである。ここでは、図２に示すコンポＡの重要テストケースをコンポＢに追加することを想定している。

ステップＳ１３０１で、重要テストケース抽出格納部１２０３は、テスト結果格納部１２０２に格納されたテスト結果に基づいて、テストケース格納部１２０１に格納されているテストケースから重要テストケースを選定し、格納する。

ステップＳ１３０２で、モデル化テストケース作成部１２０５は、重要テストケース抽出格納部１２０３に格納されているコンポＡの重要テストケース群を、インタフェース分類情報格納部１２０４に格納されているコンポＡのインタフェース分類情報を用いて変換する。これにより、モデル化テストケース作成部１２０５は、モデル化テストケース群Ａを作成する。このステップＳ１３０２は、実施形態１のステップＳ９０１に準ずる。

ステップＳ１３０３で、モデル化テストケース作成部１２０５は、テストケース格納部１２０１に格納されているコンポＢのテストケース群を、インタフェース分類情報格納部１２０４に格納されているコンポＢのインタフェース分類情報を用いて変換する。これにより、モデル化テストケース作成部１２０５は、モデル化テストケース群Ｂを作成する。このステップＳ１３０３は、実施形態１のステップＳ９０２に準ずる。

ステップＳ１３０４で、モデル化テストケース比較抽出部１２０６は、作成されたモデル化テストケース群Ａの中から、作成されたモデル化テストケース群Ｂに含まれないモデル化テストケースを抽出する。このステップＳ１３０４は、実施形態１のステップＳ９０３に準ずる。

ステップＳ１３０５で、テストケース作成部１２０７は、抽出されたモデル化テストケースにインタフェース分類情報格納部１２０４に格納されているインタフェース分類情報を適用することによって、テストケースを作成し、コンポＢに追加する。

図１４は実施形態２の重要テストケース抽出格納部１２０３による重要テストケース群の抽出手順の詳細を示すフローチャートである。これは図１３のステップＳ１３０１に対応する。

まず、ステップＳ１４０１で、重要テストケース抽出格納部１２０３は、初期化処理として、変数ｍと変数ｎそれぞれに０（ｍ＝０、ｎ＝０）を設定する。

ステップＳ１４０２で、重要テストケース抽出格納部１２０３は、以降のステップＳ１４０３からステップＳ１４０７までの処理を、テストケース格納部１２０１に格納されているコンポＡのテストケースの数Ｍだけくり返す。

ステップＳ１４０３で、重要テストケース抽出格納部１２０３は、テストケース格納部１２０１に格納されているコンポＡのテストケースから新たに１つのテストケースを取り出し、これをテストケース［ｍ］とする。

ステップＳ１４０４で、重要テストケース抽出格納部１２０３は、テスト結果格納部１２０２に格納されるテスト結果情報を用いて、テストケース［ｍ］によってバグが発見されたか否かを判定する。ここで、バグが発見されたと判定した場合（ステップＳ１４０４でＹＥＳ）、ステップＳ１４０５に進む。一方、バグが発見されていないと判定した場合（ステップＳ１４０４でＮＯ）、ステップＳ１４０６に進む。

ステップＳ１４０５で、重要テストケース抽出格納部１２０３は、バグが発見されたテストケース［ｍ］を重要テストケース［ｎ］として保持する。また、重要テストケース抽出格納部１２０３は、変数ｎをインクリメントする。

ステップＳ１４０６で、重要テストケース抽出格納部１２０３は、変数ｍをインクリメントする。

以上、ステップＳ１４０１からステップＳ１４０７の処理を実施した結果として、コンポＡのテストケースの中から、バグの発見されたテストケース、すなわち、重要テストケースが抽出される。ここで、重要テストケースの抽出方法は、実施形態２を適用するシステムに応じて自由に変更可能であり、実施形態２は、重要テストケース抽出格納部１２０３の処理内容を規定しない。

図１５は実施形態２のテストケース作成部１２０７によるテストケース群の作成・追加手順の詳細を示すフローチャートである。これは、図１３のステップＳ１３０５に対応する。

まず、ステップＳ１５０１で、テストケース作成部１２０７は、初期化処理として、変数ｐに０（ｐ＝０）を設定する。ステップＳ１５０２で、テストケース作成部１２０７は、以降のステップＳ１５０３からステップＳ１５０９までの処理を、モデル化テストケース比較抽出部１２０６に格納されている抽出されたモデル化テストケースの数ｐだけくり返す。

ステップＳ１５０３で、テストケース作成部１２０７は、モデル化テストケース比較抽出部１２０６に格納されているモデル化テストケースから新たに１つのテストケースを取り出し、ＡｂｓｔＳｅｑ［ｐ］とする。同時に、テストケース作成部１２０７は、初期化処理として、変数ｋに０（ｋ＝０）を設定する。

ステップＳ１５０４で、テストケース作成部１２０７は、以降のステップＳ１５０５からステップＳ１５０７までの処理を、ＡｂｓｔＳｅｑ［ｐ］に定義されているインタフェース分類情報の数Ｋだけくり返す。ステップＳ１５０５で、テストケース作成部１２０７は、ＡｂｓｔＳｅｑ［ｐ］の先頭から順にインタフェース分類情報を１つ取り出し、ＡｂｓｔＳｅｑ［ｐ］［ｋ］とする。

ステップＳ１５０６で、テストケース作成部１２０７は、インタフェース分類情報格納部１２０４に保持されるインタフェース分類情報を用いて、取り出したインタフェース分類情報をインタフェース呼び出しに変換し、Ｓｅｑ［ｐ］［ｋ］に保持する。ここで、モデル化テストケースからテストケースへの変換とは、モデル化テストケースに対しコンポーネント固有の情報（インタフェース名やインタフェースの構成）を付加する作業を示す、ステップＳ１３０２の逆の処理を実施することとなる。また、テストケース作成部１２０７は、変数ｋをインクリメントする。

ステップＳ１５０８で、テストケース作成部１２０７は、変数ｐをインクリメントする。ステップＳ１５１０で、テストケース作成部１２０７は、これまでの処理で蓄積されたテストケースＳｅｑをコンポＢのテストケースとして追加する。

以上、ステップＳ１５０１からステップＳ１５１０の処理を実施した結果として、コンポＢにコンポＡの重要テストケースに類似のテストケースが追加される。

以上説明したように、実施形態２によれば、例えば、コンポＡに対する単体テストでバグが発見された場合に、類似のテストをコンポＢで実施済みか否かを判定し、もし実施していない場合にはテストケースを追加することが可能となる。

また、実施形態２では、図２の情報処理システムを構成するフィルタ処理コンポーネントを例に処理の詳細を説明しているが、本実施形態は他の構成の情報システムにも適用可能であり、情報処理システムを構成によって限定されるものではない。

＜実施形態３＞
以下、本発明の実施形態３について、実施形態１との差異を中心に説明する。但し、本発明の技術的範囲がこの実施形態に限定されるものではない。

実施形態３における情報処理装置の構成は、実施形態１の図１の情報処理装置の構成に準ずる。

実施形態１では、２つのコンポーネント間での処理について説明したが、実施形態３では、複数のコンポーネント間での処理に拡張した場合の処理について説明する。

図１６は実施形態３のコンポーネントテスト支援手順のフローチャートである。

まず、ステップＳ１６０１で、モデル化テストケース作成部１０３は、初期化処理として、変数ｃとｉそれぞれに０（ｃ＝０、ｉ＝０）を設定する。

ステップＳ１６０２で、モデル化テストケース作成部１０３は、以降のステップＳ１６０３からステップＳ１６０６までの処理を、システムを構成する類似するコンポーネントの数Ｃだけくり返す。

ステップＳ１６０３で、モデル化テストケース作成部１０３は、システムを構成する類似するコンポーネントから新たに１つのコンポーネントを取り出し、これをコンポ［ｃ］とする。例えば、図２の場合、フィルタ処理コンポーネントＡ〜Ｎから、１つのコンポーネントを取り出すことになる。

ステップＳ１６０４では、モデル化テストケース作成部１０３は、テストケース格納部１０１に格納されているコンポ［ｃ］のテストケース群を、インタフェース分類情報格納部１０２格納されているコンポ［ｃ］のインタフェース分類情報を用いて変換する。このステップＳ１６０４は、実施形態１のステップＳ９０１及びステップＳ９０２に準ずる。

ステップＳ１６０５で、モデル化テストケース作成部１０３は、変数ｃをインクリメントする。ステップＳ１６０７で、モデル化テストケース作成部１０３は、以降のステップＳ１６０８からステップＳ１６１５までの処理を、システムを構成する類似するコンポーネントの数Ｃだけくり返す。ステップＳ１６０８で、モデル化テストケース作成部１０３は、初期化処理として、変数ｊを０（ｊ＝０）に設定する。

ステップＳ１６０９で、モデル化テストケース作成部１０３は、以降のステップＳ１６１０からステップＳ１６１３までの処理を、システムを構成する類似するコンポーネントの数Ｃだけくり返す。

ステップＳ１６１０で、モデル化テストケース作成部１０３は、変数ｉと変数ｊが同値であるか否かを判定する。ここで、同値であると判定した場合（ステップＳ１６１０でＹＥＳ）、ステップＳ１６１２に進む。一方、同値でないと判定した場合（ステップＳ１６１０でＮＯ）、ステップＳ１６１１に進む。

ステップＳ１６１１で、モデル化テストケース比較抽出部１０４は、モデル化テストケース作成部１０３に格納されているコンポ［ｉ］のモデル化テストケース群の中から、コンポ［ｊ］のモデル化テストケース群に含まれないモデル化テストケースを抽出する。このステップＳ１６１１は、実施形態１のステップＳ９０３に準ずる。

ステップＳ１６１２で、モデル化テストケース作成部１０３は、変数ｉをインクリメントする。ステップＳ１６１４で、モデル化テストケース作成部１０３は、変数ｊをインクリメントする。

以上説明したように、実施形態３によれば、類似する多数のコンポーネントにそれぞれ定義されているテストケースをモデル化テストケースに変換し、これらを比較することで、任意のコンポーネント間でモデル化テストケースの比較・抽出が可能となる。

尚、本発明は、以下の処理を実施することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims

複数のソフトウェア部品であるコンポーネントが連携動作することにより実現される１つのシステムにおける、前記コンポーネントのテストを支援する情報処理装置であって、
コンポーネントに対するインタフェースの呼び出し順を記述する、コンポーネントのテストケースを格納するテストケース格納部と、
前記コンポーネントが提供するインタフェースの分類情報を格納するインタフェース分類情報格納部と、
前記テストケース格納部に格納されている前記コンポーネントのテストケースから、前記インタフェース分類情報格納部に格納されているインタフェースの分類情報を用いて、前記テストケースに含まれるコンポーネント固有の情報を取り除き、抽象度を高めた表現に変換したものであるモデル化テストケースを作成するモデル化テストケース作成部と、
前記モデル化テストケース作成部が作成するモデル化テストケースを、複数のコンポーネント間で比較することで差分となるモデル化テストケースを抽出するモデル化テストケース比較抽出部と
を備えることを特徴とする情報処理装置。
複数のソフトウェア部品であるコンポーネントが連携動作することにより実現される１つのシステムにおける、前記コンポーネントのテストを支援する情報処理装置であって、
コンポーネントに対するインタフェースの呼び出し順を記述する、コンポーネントのテストケースを格納するテストケース格納部と、
前記テストケース格納部に格納されているコンポーネントのテストケースのテスト結果を格納するテスト結果格納部と、
前記テストケース格納部に格納されているコンポーネントのテストケースから、前記テスト結果格納部に格納されているテスト結果を用いて、バグが発見されたテストケースである重要なテストケースを抽出して格納する重要テストケース抽出格納部と、
前記コンポーネントが提供するインタフェースの分類情報を格納するインタフェース分類情報格納部と、
前記テストケース格納部に格納されているコンポーネントのテストケースから、もしくは前記重要テストケース抽出格納部に格納されている重要なテストケースから、前記インタフェース分類情報格納部に格納されているインタフェースの分類情報を用いて、前記テストケースに含まれるコンポーネント固有の情報を取り除き、抽象度を高めた表現に変換したものであるモデル化テストケースを作成するモデル化テストケース作成部と、
前記モデル化テストケース作成部が作成するモデル化テストケースを、複数のコンポーネント間で比較することで差分となるモデル化テストケースを抽出するモデル化テストケース比較抽出部と
前記モデル化テストケース比較抽出部が抽出したモデル化テストケースに対し、前記インタフェース分類情報格納部に格納されているインタフェースの分類情報を用いて、前記コンポーネント固有の情報を付加したものであるテストケースを作成するテストケース作成部と
を備えることを特徴とする情報処理装置。
前記インタフェース分類情報格納部に格納されているインタフェースの分類情報は、複数のコンポーネント間で共通に利用される分類情報である
ことを特徴とする請求項１または２に記載の情報処理装置。
前記インタフェース分類情報格納部に格納されているインタフェースの分類情報は、１つのインタフェースに対して１ないし複数の分類情報を割り当てる
ことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
前記インタフェース分類情報格納部に格納されているインタフェースの分類情報は、前処理、後処理、処理の開始、処理の停止及びパラメータの設定を異なるインタフェースとして分類する情報である
ことを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
前記モデル化テストケース比較抽出部は、比較するモデル化テストケースに含まれるインタフェースの分類情報が同一である場合に、同一のモデル化テストケースであると判定する
ことを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
前記モデル化テストケース比較抽出部は、比較するモデル化テストケースに含まれるインタフェースの分類情報の一部が同一である場合に、類似のモデル化テストケースであると判定する
ことを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
複数のソフトウェア部品であるコンポーネントが連携動作することにより実現される１つのシステムにおける、前記コンポーネントのテストを支援する情報処理装置の制御方法であって、
モデル化テストケース作成部が、コンポーネントに対するインタフェースの呼び出し順を記述する、コンポーネントのテストケースから、前記コンポーネントが提供するインタフェースの分類情報を用いて、前記テストケースに含まれるコンポーネント固有の情報を取り除き、抽象度を高めた表現に変換したものであるモデル化テストケースを作成する作成工程と、
モデル化テストケース比較抽出部が、前記作成工程が作成するモデル化テストケースを、複数のコンポーネント間で比較することで差分となるモデル化テストケースを抽出する抽出工程と
を備えることを特徴とする情報処理装置の制御方法。
複数のソフトウェア部品であるコンポーネントが連携動作することにより実現される１つのシステムにおける、前記コンポーネントのテストを支援する情報処理装置の制御方法であって、
抽出部が、コンポーネントに対するインタフェースの呼び出し順を記述する、コンポーネントのテストケースから、そのテスト結果を用いて、バグが発見されたテストケースである重要なテストケースを抽出する抽出工程と、
作成部が、前記コンポーネントのテストケースから、もしくは前記重要なテストケースから、前記コンポーネントが提供するインタフェースの分類情報を用いて、前記テストケースに含まれるコンポーネント固有の情報を取り除き、抽象度を高めた表現に変換したものであるモデル化テストケースを作成する作成工程と、
モデル化テストケース比較抽出部が、前記作成工程が作成するモデル化テストケースを、複数のコンポーネント間で比較することで差分となるモデル化テストケースを抽出するモデル化テストケース比較抽出工程と
テストケース作成部が、前記モデル化テストケース比較抽出工程が抽出したモデル化テストケースに対し、前記インタフェースの分類情報を用いて、前記コンポーネント固有の情報を付加したものであるテストケースを作成するテストケース作成工程と
を備えることを特徴とする情報処理装置の制御方法。
複数のソフトウェア部品であるコンポーネントが連携動作することにより実現される１つのシステムにおける、前記コンポーネントのテストを支援する情報処理装置の制御をコンピュータに実行させるためのプログラムであって、
コンポーネントに対するインタフェースの呼び出し順を記述する、コンポーネントのテストケースから、前記コンポーネントが提供するインタフェースの分類情報を用いて、前記テストケースに含まれるコンポーネント固有の情報を取り除き、抽象度を高めた表現に変換したものであるモデル化テストケースを作成する作成工程と、
前記作成工程が作成するモデル化テストケースを、複数のコンポーネント間で比較することで差分となるモデル化テストケースを抽出する抽出工程と
をコンピュータに実行させることを特徴とするプログラム。
複数のソフトウェア部品であるコンポーネントが連携動作することにより実現される１つのシステムにおける、前記コンポーネントのテストを支援する情報処理装置の制御をコンピュータに実行させるためのプログラムであって、
コンポーネントに対するインタフェースの呼び出し順を記述する、コンポーネントのテストケースから、そのテスト結果を用いて、バグが発見されたテストケースである重要なテストケースを抽出する抽出工程と、
前記コンポーネントのテストケースから、もしくは前記重要なテストケースから、前記コンポーネントが提供するインタフェースの分類情報を用いて、前記テストケースに含まれるコンポーネント固有の情報を取り除き、抽象度を高めた表現に変換したものであるモデル化テストケースを作成する作成工程と、
前記作成工程が作成するモデル化テストケースを、複数のコンポーネント間で比較することで差分となるモデル化テストケースを抽出するモデル化テストケース比較抽出工程と
前記モデル化テストケース比較抽出工程が抽出したモデル化テストケースに対し、前記インタフェースの分類情報を用いて、前記コンポーネント固有の情報を付加したものであるテストケースを作成するテストケース作成工程と
をコンピュータに実行させることを特徴とするプログラム。