JP2007249495A

JP2007249495A - ソフトウェア検証方法、情報処理装置およびプログラム

Info

Publication number: JP2007249495A
Application number: JP2006070873A
Authority: JP
Inventors: Kenjiro Ikeda; 健次郎池田
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2006-03-15
Filing date: 2006-03-15
Publication date: 2007-09-27

Abstract

【課題】ソフトウェアの部分検証を適正に行うための検証範囲を特定する技術を提供する。
【解決手段】情報処理装置は、相互の呼出し関係が規定された複数のモジュールを含むソフトウェアの検証処理が記述された検証シナリオと、検証シナリオにより処理すべき検証規模の上限を表す最大検証規模と、各モジュールの検証規模とを認識した後、ソフトウェアにおける検証の起点モジュールに対し検証シナリオを実行する。情報処理装置は、起点モジュールから呼出され、且つ、起点モジュールおよび自モジュールの検証規模の総和が最大検証規模以下となるモジュール集合を求める。そして、求めたモジュール集合から被呼出し回数が最も多いモジュールを検出し該モジュールおよび起点モジュールを検証範囲として認識する。
【選択図】図２

Description

本発明は、ソフトウェアを検証する技術に関し、特に、ソフトウェアを部分検証するための技術に関する。

従来、開発されたソフトウェアが適正であるか否かを検証するための種々の技術が提案されている。そのひとつに、例えば、後述の特許文献１に記載された技術がある。特許文献１には、ソフトウェアを構成するモジュール群から特定の作業を行うための対象モジュール群を抽出するために、各モジュールを製造する開発拠点に対し、その製造能力に応じたモジュールを分配するという方式が記載されている。また、ソフトウェアを検証する際は、そのソフトウェアに含まれる静的な情報を用いて検証対象が特定される。
特開平５−２００３７号公報

上記特許文献１に記載の技術のような従来の検証方法において、大規模のソフトウェアの部分検証を行う際は、機能分割されたモジュール構造の設計情報やソースコードでの呼出し関係といった静的な情報により、部分検証の対象範囲が特定される。そのため、検証対象のソフトウェアが修正された場合、あるいは、特定のシナリオに沿って検証を行う場合は、検証対象の範囲が適切ではなくなり、結果として、検証精度が低下するおそれがある。

本発明は、上記課題に鑑みてなされたものであり、その目的は、ソフトウェアの部分検証を適正に行うための検証範囲を特定する技術を提供することにある。

本発明に係るソフトウェア検証方法は、情報処理装置が、相互の呼出し関係が規定された複数のモジュールを含むソフトウェアの検証処理が記述された検証シナリオと該検証シナリオにより処理すべき検証規模の上限を表す最大検証規模と前記各モジュールの検証規模とを認識するステップと、前記ソフトウェアにおける検証の起点モジュールに対し前記検証シナリオを実行し、前記起点モジュールから呼出され且つ前記起点モジュールおよび自モジュールの検証規模の総和が前記最大検証規模以下となるモジュール集合を求めるステップと、前記モジュール集合から被呼出し回数が最も多いモジュールを検出し該モジュールおよび前記起点モジュールを検証範囲として認識するステップとを実行するという方法である。

本発明によれば、検証シナリオに沿って測定したモジュールの呼出し回数を用いて検証範囲を特定することから、任意の検証シナリオに対し適切な検証範囲を提供することができる。また、モジュールの呼出し回数という動的な情報を用いることから、たとえ検証対象のソフトウェア自体が修正されても、適切な検証範囲を特定することができる。このように、ソフトウェアにおける検証の起点モジュールと強く関連するモジュールを、規定の最大検証規模に達するまで検証範囲に追加するよう構成したことで、より高い精度での部分検証が可能となる。

本発明の実施形態について図面を参照して詳細に説明する。図１１に、本実施形態の情報処理装置１０の機能的な構成を示す。情報処理装置１０は、検証対象のソフトウェア１００および検証シナリオ２００を読み出して認識し、各種設定値の初期化処理を行う初期設定手段１１と、部分検証の検証範囲の候補を検出する候補検出手段１２と、検出された候補を用いて検証範囲を特定する検証範囲特定手段１３とを備える。検証シナリオ２００は、別途作成された、いわゆるテストケースや一連のテストデータのようなプログラムである。

図１に、検証対象となるソフトウェア１００のモジュール構造を示す。図示のソフトウェア１００は、それぞれ所定の処理が記述されたｍ１〜ｍ１２の１２個のモジュール１を有し、各モジュール１は、矢印２で示す静的な呼出し関係を持つ。

ここで、各モジュール（ｍ１〜ｍ１２）の検証規模をｖｋ（ｋ＝１〜１２）とし、図中に破線で示すＭｉをソフトウェア１００の部分検証の範囲とし、検証範囲Ｍｉに含まれるモジュールの検証規模の総和をＶｉとする。モジュールの検証規模は、ソフトウェア１００に対する検証の内容に応じて変化するものであり、例えば、ソースコードの静的解析の場合であれば、ソースコードの行数を検証規模とすることができる。また、状態遷移のデッドロック検査である場合は、状態数及び遷移数をパラメータとする関数により検証規模が決定される。

ソフトウェア１００の検証の初期状態では、検証範囲Ｍｉとして、検証の起点となるモジュールが設定される。この検証範囲Ｍｉに関し、予め作成した検証シナリオの集合Ｓに沿って、検証範囲外のモジュールに対する呼出し回数ｎｉ_ｋを測定する。そして、検証範囲Ｍｉより呼出されるモジュールｍｋであり、かつ、Ｍｉ及び自モジュールの検証規模の総和が最大検証規模ＶＭＡＸを超えないモジュールｍｋの集合を追加候補のモジュール集合Ｍｃｉとして求める。

さらに、追加候補となるモジュールｍｋが存在する、すなわちＭｃｉが空集合でない場合には、モジュール集合Ｍｃｉの中からｎｉ_ｋが最大となるモジュールｍｋを求め、それを検証範囲Ｍｉに追加する。このモジュール追加による検証範囲の更新を、追加候補のモジュールｍｋが検出されなくなるまで、すなわちＭｃｉが空集合になるまで繰り返す。

図２に示すフローチャートを参照して、起点モジュールの検証範囲を決定するための基本動作を説明する。なお、図示のフローチャートにおいて、ステップST1／ST2が図１１に示す初期設定手段１１に対応し、ステップST3／ST4が候補検出手段１２に対応し、ステップST5／ST6／ST7が検証範囲特定手段１３に対応する。

まず、対象のソフトウェアの検証シナリオの集合Ｓを作成し、それを情報処理装置（１０）に認識させる(ステップST1)。検証シナリオＳには、各モジュールの検証規模ｖｓと、検証の際の最大検証規模ＶＭＡＸとが設定されている。また、各設定値の初期化処理を行う。具体的には、初期の検証範囲Ｍ１として、ソフトウェアにおける検証の起点となるモジュールｍｓのみを要素とする集合を設定し、このモジュール集合ｍｓの検証規模ｖｓをＭ１の検証規模Ｖ１とし、繰返し回数ｉを「１」に初期化する(ステップST2)。

上記の初期化後、検証シナリオＳにそって、検証範囲Ｍｉから検証範囲外のモジュールに対する呼出し回数ｎｉ_ｋを測定する(ステップST3)。測定の結果をもとに、呼出し回数ｎｉ_ｋが「０」より大きく、かつ、Ｖｉ＋ｖｋが最大検証規模ＶＭＡＸ以下になるモジュールを追加候補のモジュール集合Ｍｃｉとして求める(ステップST4)。その結果、Ｍｃｉが空集合ではない場合には(ステップST5：No)、Ｍｃｉの中から呼出し回数ｎｉ_ｋが最大となるモジュールｍｋを選び(ステップST6)、検証範囲Ｍｉに追加すると共に検証範囲の検証規模を更新する(ステップST7)。

上記ステップST3以降の手順を、検証範囲Ｍｉに追加可能なモジュールが存在しなくなるまで、すなわちＭｃｉが空集合になるまで繰返し、Ｍｃｉが空集合となった時点のＭｉをもって最終的な検証範囲Ｍｉとする。

次に、本実施形態の動作について図２のフローチャートに基づく実施例を挙げる。ここでは、図３に示すソフトウェア１０１が検証対象であるとし、許容される最大検証規模ＶＭＡＸは「６」、検証の起点となるモジュールはｍ２とする。また、各モジュール（ｍ１〜ｍ１２）の検証規模ｖｋは、図７に示すものであるとする。

情報処理装置（１０）は、ｍ２を起点モジュールとして作成された検証のシナリオ集合Ｓを認識し(図２のステップST1)、繰り返し回数ｉを初回の「１」とし、検証範囲Ｍ１を{ｍ２}とし、検証規模Ｖ１を「２」(＝ｖ２)とする(ステップST2)。検証規模Ｖ１が「２」であることは、図７に示す一覧におけるモジュールｍ２の値に基づく。

図４に、検証範囲Ｍ１に関する検証の様子を模式的に示す。まず、検証シナリオＳに沿って、検証範囲Ｍ１から検証範囲外のモジュールの呼出し回数ｎ１_ｋを測定する(ステップST3)。この測定対象となるモジュールは、図４より、起点モジュールｍ２と直接的な呼出し関係にある３つのモジュールｍ４、ｍ５及びｍ１０である。これら３つのモジュールから、呼出し回数ｎｉ_ｋが「０」より大きく、かつ、Ｖｉ＋ｖｋが最大検証規模ＶＭＡＸ以下になるモジュール集合を次のように求める（ステップST4）。

図８に、Ｍ１からの呼出し回数に関する測定結果を示す。図示の一覧より、測定対象のモジュールｍ４、ｍ５及びｍ１０は、検証範囲Ｍ１｛ｍ２｝から呼出された回数が「０」より大きいことがわかる。また、これらの各モジュールの検証規模（図７）をそれぞれ検証範囲Ｍ１｛ｍ２｝の検証規模「２」に加算しても、規定のＶＭＡＸ「６」を超えない。具体的には、例えばモジュールｍ４の場合、その検証規模は、図７より「１」であり、この検証規模「１」とＭ１の検証規模「２」との合計は「３」である。よって、ＶＭＡＸ「６」を超えないと判断する。他のモジュールｍ５及びｍ１０についても、同様の要領にて判断することができる。

上記判断より、Ｍ１に関する測定対象であるモジュールｍ４、ｍ５及びｍ１０は、すべて条件を満たすことから、図４に示すように、検証範囲Ｍ１への追加候補Ｍｃ１は｛ｍ４，ｍ５，ｍ１０｝となる。

また、今回の追加候補Ｍｃ１は空集合ではないことから(ステップST5：No)、このＭｃ１｛ｍ４，ｍ５，ｍ１０｝の中から、呼出し回数が最大となるものを選ぶ(ステップST6)。ここでは、図８より、呼出し回数が最大値をとるモジュールとしてｍ５が検出される。そして、新たな検証範囲Ｍ２を｛ｍ２，ｍ５｝とし、新たな検証規模Ｖ２を「５」（＝「２」＋「３」）として更新する(ステップST7)。これを以って、初回の検証範囲Ｍ１に関する処理が終了し、続いて、２回目の処理へ移行する。

図５に、繰り返し回数が２回目の検証範囲Ｍ２に関する処理を模式的に示す。情報処理装置（１０）は、検証範囲Ｍ２｛ｍ２，ｍ５｝について、検証シナリオＳに沿った呼出し回数の測定を行う（図２：ステップST3）。今回の測定対象は、図５に示すように、検証範囲Ｍ２のモジュールｍ２から呼出されるモジュールｍ４及びｍ１０と、同検証範囲Ｍ２のモジュールｍ５から呼出されるモジュールｍ７とである。

図９に、モジュールｍ４、ｍ７及びｍ１０に対する呼出し回数の測定結果を示す。図示の一覧より、モジュールｍ４、ｍ７及びｍ１０は、いずれも呼出し回数が「０」より大きいが、それらの検証規模（図７）のうち、検証範囲Ｍ２の検証規模「５」に追加してもＶＭＡＸ「６」を超えない検証規模のモジュールは、検証規模が「１」のモジュールｍ４のみである。したがって、図５に示すように、検証範囲Ｍ２の追加候補Ｍｃ２は｛ｍ４｝となる（ステップST4）。

上記のようにして形成された追加候補Ｍｃ２は、空集合ではないので(ステップST5：No)、このＭｃ２から呼出し回数が最大となるものを選ぶ(ステップST6)。ここでは、追加候補Ｍｃ２の要素はモジュールｍ４のみであるから、このモジュールｍ４を選ぶ。そして、新たな検証範囲Ｍ３を｛ｍ２，ｍ５，ｍ４｝とすると共に、新たな検証規模Ｖ３を「６」（＝「２」＋「３」＋「１」）とし(ステップST7)、３回目の処理へ移行する。

図６に、繰り返し回数が３回目の検証範囲Ｍ３に関する処理を模式的に示す。情報処理装置（１０）は、検証範囲Ｍ３｛ｍ２，ｍ５，ｍ４｝について、検証シナリオＳに沿った呼出し回数の測定を行う。今回の測定対象は、図６に示すように、モジュールｍ６、ｍ７及びｍ１０である。

図１０に、モジュールｍ６、ｍ７及びｍ１０に対する呼出し回数の測定結果を示す。なお、モジュールｍ５からｍ７に対する呼出し回数は、前回（図９）と同様の「４」であるが、同じモジュールｍ７に対してはモジュールｍ６からの呼出し回数（「５」）のほうが多いので、図示の一覧からは省略されている。

図１０より、測定対象のモジュールｍ６、ｍ７及びｍ１０の呼出し回数は「０」より大きいが、それらの検証規模のうち、検証範囲Ｍ３の検証規模「６」に追加してもＶＭＡＸ「６」を超えないモジュールは存在しない。従って、追加候補Ｍｃ３は空集合となる。このように追加候補が空集合となったとき、情報処理装置（１０）は、以降の繰り返し処理を停止し、現時点の検証範囲（Ｍ３｛ｍ２，ｍ５，ｍ４｝）を、最終的に特定した検証範囲として認識する。

以上説明したように、本実施形態は、検証シナリオに沿って、検証範囲のモジュールから検証範囲外のモジュールに対する呼出し回数を測定し、測定結果をもとに条件に合うモジュールを検証範囲に加えるよう構成されている。したがって、任意の検証シナリオに対し適切な検証範囲を提供することができる。また、検証対象のソフトウェア自体が修正されても、適切な検証範囲を特定することができる。その理由は、検証範囲外のモジュールの呼出し回数という動的な情報を用いて、検証毎に検証範囲を特定しているためである。

このように、ソフトウェアにおける検証の起点となるモジュールと強く関連するモジュールを、規定の最大検証規模に達するまで検証範囲に追加するよう構成したことで、より高い精度での部分検証が可能となる。

本発明は、例えば、設計モデルやソースコードを用いたソフトウェアの部分的検証に適用できる。また、スタブを用いた結合テストといった用途にも好適である。

本発明の実施形態における検証範囲の概念に関する説明図である。実施形態の動作手順を示すフローチャートである。実施形態の一実施例における検証対象のソフトウェアの説明図である。実施例における初回の処理に関する説明図である。実施例における２回目の処理に関する説明図である。実施例における３回目の処理に関する説明図である。実施例における各モジュールの検証規模に関する説明図である。実施例における初回の測定結果に関する説明図である。実施例における２回目の測定結果に関する説明図である。実施例における３回目の測定結果に関する説明図である。実施形態の情報処理装置の機能構成を示すブロック図である。

符号の説明

１モジュール（ｍ１〜ｍ１２）
２呼出し関係
１００検証対象ソフトウェア
２００検証シナリオ
１１初期設定手段
１２候補検出手段
１３検証範囲特定手段

Claims

情報処理装置が、
相互の呼出し関係が規定された複数のモジュールを含むソフトウェアの検証処理が記述された検証シナリオと該検証シナリオにより処理すべき検証規模の上限を表す最大検証規模と前記各モジュールの検証規模とを認識するステップと、
前記ソフトウェアにおける検証の起点モジュールに対し前記検証シナリオを実行し、前記起点モジュールから呼出され且つ前記起点モジュールおよび自モジュールの検証規模の総和が前記最大検証規模以下となるモジュール集合を求めるステップと、
前記モジュール集合から被呼出し回数が最も多いモジュールを検出し該モジュールおよび前記起点モジュールを検証範囲として認識するステップとを実行することを特徴とするソフトウェア検証方法。
前記情報処理装置が、
前記起点モジュールの検証範囲に対し前記検証シナリオを実行し、前記検証範囲から呼出され且つ前記検証範囲および自モジュールの検証規模の総和が前記最大検証規模以下となるモジュール集合を求めるステップと、
前記モジュール集合から被呼出し回数が最も多いモジュールを検出し該モジュールを前記検証範囲に付加して該検証範囲を更新するステップとを実行することを特徴とする請求項１記載のソフトウェア検証方法。
前記情報処理装置が、
前記検証範囲に対する前記検証シナリオの実行により求められたモジュール集合が空集合であることを認識したとき前記検証シナリオの新たな実行を停止することを特徴とする請求項２記載のソフトウェア検証方法。
相互の呼出し関係が規定された複数のモジュールを含むソフトウェアの検証処理が記述された検証シナリオと該検証シナリオにより処理すべき検証規模の上限を表す最大検証規模と前記各モジュールの検証規模とを認識する手段と、
前記ソフトウェアにおける検証の起点モジュールに対し前記検証シナリオを実行し、前記起点モジュールから呼出され且つ前記起点モジュールおよび自モジュールの検証規模の総和が前記最大検証規模以下となるモジュール集合を求める手段と、
前記モジュール集合から被呼出し回数が最も多いモジュールを検出し該モジュールおよび前記起点モジュールを検証範囲として認識する手段とを備えることを特徴とする情報処理装置。
前記起点モジュールの検証範囲に対し前記検証シナリオを実行し、前記検証範囲から呼出され且つ前記検証範囲および自モジュールの検証規模の総和が前記最大検証規模以下となるモジュール集合を求め、前記モジュール集合から被呼出し回数が最も多いモジュールを検出し該モジュールを前記検証範囲に付加して該検証範囲を更新することを特徴とする請求項４記載の情報処理装置。
前記起点モジュールの検証範囲に対する前記検証シナリオの実行により求められたモジュール集合が空集合であることを認識したとき前記検証シナリオの新たな実行を停止することを特徴とする請求項５記載の情報処理装置。
コンピュータを請求項４乃至６のいずれか１項に記載の情報処理装置として機能させることを特徴とするプログラム。