(57)【要約】【課題】ソフトウェアを短時間にしかも安価でテストすることができ、そして、信頼性を向上させたソフトウェアテストシステムを提供することを目的とする。【解決手段】ソフトウェアテストシステムは、テスト対象ソフトウェアがインストールされている端末装置と、前記テスト対象ソフトウェアのテストデータ、および、前記テスト対象ソフトウェアのテスト手続きに従って前記テスト対象ソフトウェアをテストするテストドライバが記憶されているソフトウェアテスト装置と、を有していて、前記テストドライバが前記端末装置に伝送され、前記端末装置において前記テストデータと前記テスト手続きとの組み合わせにより前記テスト対象ソフトウェアがテストされる。【選択図】図１
2008176793.tif 000002
【特許請求の範囲】
【請求項１】
テスト対象ソフトウェアがインストールされている端末装置と、
前記テスト対象ソフトウェアのテストデータ、および、前記テスト対象ソフトウェアのテスト手続きに従って前記テスト対象ソフトウェアをテストするテストドライバが記憶されているソフトウェアテスト装置と、
を備えたソフトウェアテストシステムにおいて、
前記テストドライバが前記端末装置に伝送され、前記端末装置において前記テストデータと前記テスト手続きとの組み合わせにより前記テスト対象ソフトウェアがテストされる
ことを特徴とするソフトウェアテストシステム。
【請求項２】
前記端末装置において、前記テストデータと前記テスト手続きとを組み合わせて得られた複数のテストケースが、１つの前記テストドライバを用いて行われる請求項１に記載のソフトウェアテストシステム。
【請求項３】
前記ソフトウェアテスト装置が、前記テスト結果に関する情報を提供する部分を含む請求項２に記載のソフトウェアテストシステム。
【請求項４】
前記テスト結果に関する情報が、HTML（登録商標）、MS WORD（登録商標）、および、MS Excel（登録商標）からなる群から選ばれる少なくとも１つの形態で提供される請求項３に記載のソフトウェアテストシステム。
【請求項５】
前記テストデータおよび前記テスト手続きが、前記テスト対象ソフトウェアの内部データに基づいて生成され、そして、前記テスト対象ソフトウェアの内部データが、APIに関するデータおよび変数の型に関するデータを含む請求項２に記載のソフトウェアテストシステム。
【請求項６】
前記テストデータが、前記変数の型ごとにテストすべき値の範囲を指定する変数の型のパーティションと、前記変数の型のパーティションおよび前記APIに関するデータに基づいて前記APIに含まれた変数ごとにテストすべき値の範囲を指定するAPI変数のパーティションと、を含む請求項５に記載のソフトウェアテストシステム。
【請求項７】
前記テスト手続きが、前記APIおよび前記APIに含まれた関数に関する呼出しの順序と前記呼出し間の関係とを指定するテストスクリプトである請求項６に記載のソフトウェアテストシステム。
【請求項８】
前記テストドライバが、前記テスト結果を検査するテスト結果検査関数を含む請求項２に記載のソフトウェアテストシステム。
【請求項９】
前記ソフトウェアテスト装置が、前記テスト対象ソフトウェアのエラーに関する情報を表示する部分を含む請求項２に記載のソフトウェアテストシステム。
【請求項１０】
テスト対象ソフトウェアの内部データに基づいてテストデータを生成する段階と、
前記テスト対象ソフトウェアの内部データに基づいて、前記テスト対象ソフトウェアに含まれた関数のテスト手続きを生成する段階と、
前記テストデータと前記テスト手続きの組み合わせに対応してテストドライバを生成する段階と、
を含むことを特徴とするソフトウェアのテスト方法。
【請求項１１】
前記テストデータと前記テスト手続きとを組み合わせて得られた複数のテストケースを、１つの前記テストドライバを用いて行う請求項１０に記載のソフトウェアテストシステム。
【請求項１２】
前記ソフトウェアのテスト方法が、前記テスト結果に関する情報を提供する段階を含む請求項１１に記載のソフトウェアのテスト方法。
【請求項１３】
前記テスト結果に関する情報を、HTML（登録商標）、MS WORD（登録商標）、および、MS Excel（登録商標）からなる群から選ばれる少なくとも１つの形態で提供する請求項１２に記載のソフトウェアのテスト方法。
【請求項１４】
前記テスト対象ソフトウェアの内部データが、APIに関するデータと変数の型に関するデータを含む請求項１１に記載のソフトウェアのテスト方法。
【請求項１５】
前記テストデータを生成する段階が、前記変数の型ごとにテストすべき値の範囲を指定する変数の型のパーティションを生成する段階と、前記変数の型のパーティションおよび前記APIに関するデータに基づいて、前記APIに含まれた変数ごとにテストすべき値の範囲を指定するAPI変数のパーティションを生成する段階と、を含む請求項１４に記載のソフトウェアのテスト方法。
【請求項１６】
前記テスト手続きを生成する段階が、前記APIおよび前記APIに含まれた関数に関する呼出しの順序と前記呼出し間の関係とを指定するテストスクリプトを生成することを含む請求項１５に記載のソフトウェアのテスト方法。
【請求項１７】
前記テストドライバが、前記テスト結果を検査するテスト結果検査関数を含む請求項１１に記載のソフトウェアテストシステム。
【請求項１８】
前記テスト対象ソフトウェアのエラーに関する情報を表示する段階を含む請求項１１に記載のソフトウェアのテスト方法。
【請求項１９】
請求項１０から１８のいずれか１項に記載のソフトウェアのテスト方法を実行するためのプログラムを記録したコンピュータ読取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェアテストシステム、ソフトウェアのテスト方法、および、そのテスト方法を実行するためのプログラムを記録したコンピュータ読取り可能な記録媒体に関する。
【背景技術】
【０００２】
ソフトウェアテストとは、ソフトウェアが定められた要求事項を満足させているかどうかを検証し、期待される結果と実際の結果との違いを識別するために、ソフトウェアシステムの全体あるいは一部の構成要素を実行・評価するプロセスである。
【０００３】
たとえば、携帯電話、スマートフォン、ＰＤＡなどの無線通信端末機を開発するプロセスにおいて、開発者は、自ら開発した端末機に搭載されたソフトウェアが、無線通信システムと実際に連動して正常に作動するのかどうかを確認しなければならない。そのようなテストプロセスにおいて欠陥が見つかれば、その欠陥の原因を分析して、その解決を求める。
【０００４】
従来のソフトウェアテスト方式は、あらかじめ用意されたテストケースのみを用いてソフトウェアをテストするものであった。
【０００５】
このようなテストケースは、テストスクリプトとテストデータを含むため、ソフトウェアテストを遂行する前に、テスト用のスクリプトとテストデータがすべて固定されていた。
【０００６】
このような従来のソフトウェアテスト方式によれば、テストデータが固定されているために、テストを遂行しても、テストが不十分であったり不完全な部分が発見されたとしてもそれを補完することができない場合が多く、テスト終了後に更なる分析を通じて新しいテストデータをつくらなければならず、したがって、コストと時間のロスが多いという問題点があった。また、このような従来の方式は、テスト対象ソフトウェアごとに別個のテストプログラムが必要となるため、時間およびコストの面において問題点があった。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
上記課題を解決するために、本発明に係るソフトウェアテストシステムは、テスト対象ソフトウェアがインストールされている端末装置と、前記テスト対象ソフトウェアのテストデータ、および、前記テスト対象ソフトウェアのテスト手続きに従って前記テスト対象ソフトウェアをテストするテストドライバが記憶されているソフトウェアテスト装置と、を備えたソフトウェアテストシステムにおいて、前記テストドライバが前記端末装置に伝送され、前記端末装置において前記テストデータと前記テスト手続きとの組み合わせにより前記テスト対象ソフトウェアがテストされることを特徴とする。
【０００８】
前記端末装置において、前記テストデータと前記テスト手続きとを組み合わせて得られた複数のテストケースが、１つの前記テストドライバを用いて行われることが好ましい。
【０００９】
前記ソフトウェアテスト装置が、前記テスト結果に関する情報を提供する部分を含むことが好ましい。
【００１０】
前記テスト結果に関する情報が、HTML（登録商標）、MS WORD（登録商標）、および、MS Excel（登録商標）からなる群から選ばれる少なくとも１つの形態で提供されることが好ましい。
【００１１】
前記テストデータおよび前記テスト手続きが、前記テスト対象ソフトウェアの内部データに基づいて生成され、そして、前記テスト対象ソフトウェアの内部データが、APIに関するデータおよび変数の型に関するデータを含むことが好ましい。
【００１２】
前記テストデータが、前記変数の型ごとにテストすべき値の範囲を指定する変数の型のパーティションと、前記変数の型のパーティションおよび前記APIに関するデータに基づいて前記APIに含まれた変数ごとにテストすべき値の範囲を指定するAPI変数のパーティションと、を含むことが好ましい。
【００１３】
前記テスト手続きが、前記APIおよび前記APIに含まれた関数に関する呼出しの順序と前記呼出し間の関係とを指定するテストスクリプトであることが好ましい。
【００１４】
前記テストドライバが、前記テスト結果を検査するテスト結果検査関数を含むことが好ましい。
【００１５】
前記ソフトウェアテスト装置が、前記テスト対象ソフトウェアのエラーに関する情報を表示する部分を含むことが好ましい。
【００１６】
また、本発明の更なる実施例によれば、テスト対象ソフトウェアの内部データに基づいてテストデータを生成する段階と、前記テスト対象ソフトウェアの内部データに基づいて、前記テスト対象ソフトウェアに含まれた関数のテスト手続きを生成する段階と、前記テストデータと前記テスト手続きの組み合わせに対応してテストドライバを生成する段階と、を含むことを特徴とするソフトウェアのテスト方法が提供される。
【００１７】
ここで、前記テストデータと前記テスト手続きとを組み合わせて得られた複数のテストケースを、１つの前記テストドライバを用いて行うことが好ましい。
【００１８】
前記ソフトウェアのテスト方法が、前記テスト結果に関する情報を提供する段階を含むことが好ましい。
【００１９】
前記テスト結果に関する情報を、HTML（登録商標）、MS WORD（登録商標）、および、MS Excel（登録商標）からなる群から選ばれる少なくとも１つの形態で提供することが好ましい。
【００２０】
前記テスト対象ソフトウェアの内部データが、APIに関するデータと変数の型に関するデータを含むことが好ましい。
【００２１】
前記テストデータを生成する段階が、前記変数の型ごとにテストすべき値の範囲を指定する変数の型のパーティションを生成する段階と、前記変数の型のパーティションおよび前記APIに関するデータに基づいて、前記APIに含まれた変数ごとにテストすべき値の範囲を指定するAPI変数のパーティションを生成する段階と、を含むことが好ましい。
【００２２】
前記テスト手続きを生成する段階が、前記APIおよび前記APIに含まれた関数に関する呼出しの順序と前記呼出し間の関係とを指定するテストスクリプトを生成することを含むことが好ましい。
【００２３】
前記テストドライバが、前記テスト結果を検査するテスト結果検査関数を含むことが好ましい。
【００２４】
前記テスト対象ソフトウェアのエラーに関する情報を表示する段階を含むことが好ましい。
【００２５】
さらに、本発明によれば、前述したソフトウェアのテスト方法を実行するためのプログラムを記録したコンピュータ読取り可能な記録媒体が提供される。
【発明の効果】
【００２６】
本発明によれば、テスト対象プログラムを短時間に、しかも、安価でテストすることができるソフトウェアテストシステム、ソフトウェアのテスト方法、および、そのテスト方法を実行するためのプログラムを記録したコンピュータ読取り可能な記録媒体が提供される。
【００２７】
また、本発明によれば、テスト対象プログラムに対するテストの信頼性を著しく向上させることができる。
【００２８】
さらに、本発明は、埋め込みシステム(embedded system)に効率的に適用することができる。
【発明を実施するための最良の形態】
【００２９】
以下、添付した図面を参照しながら本発明の好ましい実施例について説明する。
【００３０】
図１は、本発明の１つの実施例に係るソフトウェアテストシステムを示す図である。
【００３１】
この実施例に係るソフトウェアシステムは、図１に示すように、ソフトウェアテスト装置(1)、端末装置(2)、および、信号伝送手段を含む。
【００３２】
ソフトウェアテスト装置(1)は、内部データを抽出する部分(11)と、変数の型のパーティション（type partition）を生成する部分(101)およびAPI変数のパーティション（variable partition）を生成する部分(102)を含むテストデータを生成する部分(12)と、テスト手続きを生成する部分(13)と、テストドライバを生成する部分(14)と、エラー情報を表示する部分(16)と、テスト結果に関する情報を提供する部分(17)と、を含む。ここでパーティションは分割領域と同じ意味である。
【００３３】
［内部データを抽出する部分(11)］
データを抽出する部分(11)は、テスト対象ソフトウェアのソースコードを分析して、テスト対象ソフトウェアの内部データを抽出する。
【００３４】
以下では、テスト対象ソフトウェアのソースコードがC言語で作成される場合について説明する。しかし、本発明はこれに限定されることなく、C++、JAVA（登録商標）などで作成される場合にも適用される。
【００３５】
一般的に、現代のシステムはその構成の複雑性に起因して、構造化・階層化され、機能単位のモジュールの形態で開発されている。第１のモジュールの機能が第２のモジュールに提供される場合、第１のモジュールを内部モジュールとして、第２のモジュールを外部モジュールとして定義すると、内部モジュールは、内部モジュールの機能を外部モジュールに提供するための一連のAPI(Application Program Interface)を提供する。外部モジュールは、内部モジュールの具体的な内部構成に関係なく、提供されるAPIを用いて開発される。即ち、外部モジュールの観点から内部モジュールの機能が正しく動作するということは、提供されたAPIの機能が正しく動作するということを意味する。
【００３６】
本発明の実施例に係るソフトウェアテストシステムは、この点に着目して、最適なソフトウェアテストのために、APIを中心としてテスト対象ソフトウェアをテストするものである。
【００３７】
しかし、Cのような伝統的なプログラミング言語においては、ソースコード内にAPIとAPIでない関数を区別できる情報がない。
【００３８】
このような場合にも効果的なソフトウェアテストを遂行するために、本発明に係る内部データを抽出する部分(11)は、テスト対象ソフトウェアのソースコードを分析して、テスト対象となるAPIを決める。このために、内部データを抽出する部分(11)は、関数間の呼出し関係を用いる。すなわち、別の関数によって呼び出されない関数については、外部から接近可能なAPIであると解釈する。ただし、main()関数によって呼び出される場合は考慮しない。すなわち、main()関数以外の別の関数によって呼び出されない関数をAPIとして選択する。
【００３９】
図２にテスト対象ソフトウェアの内部データを抽出した結果を示す。
【００４０】
図２には、APIと、APIでない一般関数に関するデータと、変数の型に関するデータが示されている。
【００４１】
APIは、main()関数以外の別の関数によって呼び出されない関数として定義され、一般関数はAPIでない関数として定義される。
【００４２】
関数データの表示画面(201)には、api1乃至api12からなる12個のAPIと一般関数であるdegree_tan()が示されている。
【００４３】
また、変数の型に関するデータの表示画面(202)には、Enm2・Nodeなどの変数の型が示されている。
【００４４】
また、内部データを抽出する部分(11)は、テスト対象ソフトウェアのソースコードを分析し、テスト対象ソフトウェアに含まれた関数間の呼び出し関係を抽出する。
【００４５】
図３はテスト対象ソフトウェアに含まれた関数間の呼び出し関係を示すコールグラフ(Call Graph)である。
【００４６】
図３には、APIであるapi4、api6、api7、および、api8と、一般関数であるshow_uni、cp_node、show_node間の呼び出し関係が示されている。
【００４７】
図３から分かるように、APIを対象としてテスト対象ソフトウェアをテストすると、テスト対象ソフトウェアをより詳細にテストすることが可能である。例えば、api4をテストする場合に、1)api4の関数パラメータによってshow_uni、または、cp_nodeが呼び出されてテストされ、show_uniが呼び出された場合、再びshow_nodeが呼び出されてテスト対象ソフトウェアを自動的に隅々までテストすることが可能であり、2)実際の環境においてテスト対象ソフトウェアが遂行される関数呼出しの経路を順にテストすることができる。 
【００４８】
また、内部データを抽出する部分(11)はテスト対象ソフトウェアのソースコードを分析して、テスト対象ソフトウェアのコントロールフローグラフ(Control Flow Graph, CFG)を生成する。
【００４９】
図４にテスト対象ソフトウェアのコンロトロールフローグラフを示す。
【００５０】
図４には、関数内部のコントロール構造がブロック(Block)とブロック間のコントロールフローとして示されている。コントロールフローグラフにおけるノード（ｎｏｄｅ）は、プログラムブロックを表しており、ノード間を連結する線であるエッジ(ｅｄｇｅ)は、ブロックとブロック間の遂行順序を表している。 
【００５１】
内部データを抽出する部分(11)において、各々のノードに固有番号が表記され、そして、ノードの種類に関する説明が前記ノード番号と併記される。たとえば、第２のノード(node2)の場合、1: for_initと表記され、1は第２のノード(node2)の固有番号を指しており、for_initは第２のノード(node2)の種類に関する説明を示すものである。
【００５２】
エッジの始まりに該当するノードは、アウトノード(out-node)であり、エッジの終わりに該当するノードは、インノード(in-node)である。２つのノードが１つのエッジによって連結されているならば、アウトノード(out-node)に該当するブロックの遂行が完了すると、インノード(in-node)に該当するブロックの遂行が始まる。たとえば、エッジ23(Edge23)の場合、第２のノード(node2)がアウトノード(out-node)であり、第３のノード(node3)がインノード(in-node)であり、第２のノード(node2)に該当するブロックの遂行が完了すると、第３のノード(node3)に該当するブロックの遂行が始まる。
【００５３】
コントロールフローグラフには、関数内部のコントロールフロー以外に関数呼び出しも明示されている。第８のノード(node8)は関数を表しており、図４では第６のノード(node6)に該当する5番ブロックにおいてshow_nodeという関数に関する呼び出しが発生したことを表している。
【００５４】
[テストデータを生成する部分(12)]
テストデータを生成する部分(12)は、変数の型のパーティションを生成する部分(101)とAPI変数のパーティションを生成する部分(102)とを含む。
【００５５】
変数の型のパーティションを生成する部分(101)は、テスト対象ソフトウェアに含まれた変数の型毎にテストすべき値の範囲を指定する変数の型のパーティションを生成する。
【００５６】
図５に変数の型のパーティションの生成結果を示す。
【００５７】
図５を参照すると、テスト対象ソフトウェアに含まれた変数の型毎にテストすべき値の範囲が指定され、テスト対象ソフトウェアに含まれた変数の型毎にテスト分割領域が生成される。
【００５８】
このようなテスト分割領域は、次の形態を有しても良い。
【００５９】
1)区間タイプ(Range Type Partition)
当該変数の型が有し得る値の範囲を領域別に分割して表す。たとえば、Intは、-2147483648〜2147483647の範囲を、-2147483648〜-2の範囲(RANGE)と、2〜2147483647の範囲(RANGE)に分割する。
【００６０】
2)値並びタイプ(Value-List Type Partition)
当該変数の型が有し得る1つ以上の特定の値並びのリストを作成する。各々の値(value)は、算術型（値）あるいは文字列（値）を有しても良い。Intを例にあげると、値は、-1、0、1として並んでいる。
【００６１】
API変数のパーティションを生成する部分(102)は、変数の型のパーティションとAPIに関するデータに基づいて、APIに含まれた関数の変数毎にテストすべき値の範囲を指定するAPI変数のパーティションを生成する。
【００６２】
図６にAPI変数のパーティションの生成結果を示す。
【００６３】
図６を参照すると、APIに含まれた関数の変数毎にテストすべき値の範囲が指定されていることが分かる。
【００６４】
API変数のパーティションは、変数の型のパーティションを生成する部分で生成された変数の型のパーティションのデータと各々のAPIを分析して得られたデータを組み合わせて生成される。
【００６５】
API変数のパーティションは、変数の型のパーティションに基づいて生成され、各々のAPIにおいて使われる変数に関するテストデータを生成するのに用いられる。
【００６６】
一方で、図６にはテストすべき値の範囲が具体的に示されていないが、互いに異なるAPIに含まれた同じ変数におけるテストすべき値の範囲は異なっても良い。これについて、api1とapi10の両方に含まれたintをたとえにして説明すると、次のとおりである。api1とapi10の両方にはintがあるが、api1とapi10に用いられるテストすべき値の範囲は、api1およびapi10に関する分析結果によって少し異なってくる。なぜなら、API変数のパーティションは、テスト対象ソフトウェアのソースコードに含まれるさまざまな常数値の中で、関数におけるコントロールフローに影響を及ぼす値がどのようなものであるかを分析して、その結果に基づいて、テストに用いられる入力値などを自動的に生成するからである。
【００６７】
［テスト手続きを生成する部分(13)］
テスト手続きを生成する部分(13)は、APIおよびAPIに含まれた関数に関する呼出しの順序と各呼出し間の関係を指定するテストスクリプトを生成する。
【００６８】
図７にテストスクリプトの生成結果を示す。 
【００６９】
図７を参照すると、基本的にAPI毎に生成された１つのテストスクリプトがテストスクリプト表示画面(701)に示されている。また、テスト手続きを生成する部分(13)は、APIリスト(List)に登録された関数間の遂行順序による依存関係が存在する場合、当該関数の遂行における先後関係を考慮して、複数のAPI呼出しを含むテストスクリプトをも生成する。テストスクリプトは、このスクリプトと結合するテスト入力データをともに指定する。
【００７０】
たとえば、テストスクリプトcodescroll_api10_5384は、partition-testing default defaultからなる。partition-testingはテストデータであり、後述するテストプログラム遂行時に用いられる入力値でもある。このようなテストデータは、前述した変数の型のパーティション、API 変数のパーティションを用いて自動的に生成される。
【００７１】
[テストドライバを生成する部分(14)]
テストドライバを生成する部分(14)は、テストデータとテストスクリプトに対応して１つのテストドライバを生成する。このようなテストドライバは、ソフトウェアテスト装置に記憶され、テスト対象ソフトウェアがインストールされている端末装置(2)にシリアル・ケーブル、USBケーブルなどの信号伝送手段を通じて伝送される。
【００７２】
図８にテストドライバの生成結果を示す。
【００７３】
図８を参照すると、テストドライバの表示画面(801)には、テスト対象ソフトウェアを後述するテストを遂行する部分(15)において運用できるようにするテストドライバのファイルリストが示されており、テストドライバのソースコードの表示画面(802)にはテストドライバのソースコードが示されている。
【００７４】
このようなテストドライバは、テスト対象ソフトウェアがテストを遂行する部分(15)において運用されるようにするプログラムであり、テストを遂行する部分(15)がテスト対象ソフトウェアにおいて使用されるデータを生成したり、あるいは、テスト対象ソフトウェアから提供されたAPIを呼び出したりするときに用いられ、それにより、テスト対象ソフトウェアと、テストを遂行する部分(15)とを連結させる機能を果たす。
【００７５】
一方、テストドライバは、テスト対象ソフトウェアに関するテストの遂行結果が正しいかどうかを検査することができるテスト結果検査関数(Test Oracle Function)を有しているため、テスト対象ソフトウェアに関するテストの遂行結果のエラー可否を自動的に判断して、使用者にその結果を知らせることができる。
【００７６】
[テストを遂行する部分(15)]
端末装置(2)におけるテストを遂行する部分(15)は、１つのテストドライバによりテストデータとテスト手続きを組み合わせた複数のテストケースを遂行することでテスト対象ソフトウェアのテストを行う。
【００７７】
これに関して、テストデータが１００個、テストスクリプトが１００個である場合を例に挙げて説明する。これらのテストデータとテストスクリプトとを組み合わせると、１００×１００=１０,０００のテストケースが生じる。これらのテーストケースは１つのテストドライバに結合し、テスト対象ソフトウェアは、テストケースと結合したテストドライバによってテストされる。本発明の好ましい実施例によれば、テストケースは１つのテストドライバに結合するだけで、テストケース毎にテストプログラムを生成するものではない。これについてより詳細に説明する。従来のソフトウェアテストシステムはテストケース毎にテストプログラムを生成したが、この場合には、全体のテストプログラムが大きくなりすぎて、埋め込みシステムに適用するのが難しいという問題があった。しかし、本発明の好ましい実施例に係るソフトウェアテストシステムは、１つのテストドライバを用いることで、テストケースが増えてもテストプログラムは大きくならないというメリットがある。 
【００７８】
一方、端末装置(2)は、無線通信用端末機、ユビキタス(Ubiquitous)環境を実現する一連の電子装置のような、運用ソフトウェアがインストールされたあらゆる端末を含む。
【００７９】
図９にテストプログラムの生成結果を示す。
【００８０】
図９には、テストドライバにテストデータとテストスクリプトが結合して生成されたテストプログラムが示されている。
【００８１】
図１０にテスト対象ソフトウェアに関するテスト結果を示す。
【００８２】
図１０を参照すると、テスト要約画面(Test summary window, 1001)、カバリッジ要約画面(Coverage summary window, 1002)、テスト詳細結果画面(Test details window, 1003)、および、追加情報画面(Additional information window, 1004)が示されている。
【００８３】
1)テスト要約画面(1001)は、遂行されたテストケースの数、成功したテストケースの数、失敗したテストケースの数、警告を発したテストケースの数、使われたスクリプトの数などを要約して表示する。2)カバリッジ要約画面(1002)は、全体のテストケースを遂行した結果、達成されたカバリッジの情報を表示する。別のテストケースによって達成されたカバリッジは別に表示する。3)テスト詳細結果画面(1003)は、スクリプト毎に全テストケースの数、成功したテストケースの数、失敗したテストケースの数、警告を発したテストケースの数を表示する。4)追加情報画面(1004)は、全テストケースを遂行した際に、その関数コントロールフローグラフおよび呼び出しグラフのどの部分について何回（テストが）行われたかをグラフで表示する。
【００８４】
[エラー情報を表示する部分(16)]
エラー情報を表示する部分(16)は、テスト対象ソフトウェアをテストした後、テスト対象ソフトウェアのエラーに関する情報を示すものである。
【００８５】
図１１にテスト対象ソフトウェアのエラーに関する情報を示す。
【００８６】
図１１を参照すると、テスト対象ソフトウェアのエラーに関する情報がグループ化されて示されている。
【００８７】
たとえば、エラー情報を表示する部分(16)はエラーに関する情報を、1)エラーが発生した位置、2)エラーが発生したAPI、3)エラーメッセージの種類別に整列して表示することができる。
【００８８】
[テスト結果に関する情報を提供する部分(17)]
テスト結果に関する情報を提供する部分(17)は、テスト対象ソフトウェアのテスト結果に関する情報を生成し、これを記憶した後で提供する。
【００８９】
このようなテスト対象ソフトウェアのテスト結果に関する情報は、HTML、MS WORD、MS Excelのうち少なくとも１つ形態で提供することができる。
【００９０】
また、テスト対象ソフトウェアのテスト結果に関する情報は、韓国語、英語、日本語のうち少なくとも１つの言語で提供することができる。
【００９１】
図１２は、本発明の好ましい実施例に係るソフトウェアのテスト方法を示す図である。      
【００９２】
図１２に示すように、この実施例に係るソフトウェアのテスト方法は、内部データを抽出する段階(S11)と、変数の型のパーティションを生成する段階(S101)、および、API変数のパーティションを生成する段階(S102)を含むテストデータを生成する段階(S12)と、テスト手続きを生成する段階(S13)と、テストドライバを生成する段階(S14)と、テストを遂行する段階(S15)と、エラー情報を表示する段階(S16)と、テスト結果に関する情報を提供する段階(S17)と、を含む。
【００９３】
[内部データを抽出する段階(S11)]
内部データを抽出する段階(S11)では、テスト対象ソフトウェアのソースコードを分析し、テスト対象ソフトウェアの内部データを抽出する。
【００９４】
以下では、テスト対象ソフトウェアのソースコードがC言語で作成される場合について説明する。しかし、本発明はこれに限定されることなく、C++、JAVA（登録商標）などで作成される場合にも適用される。
【００９５】
一般的に、現代のシステムはその構成の複雑性に起因して、構造化・階層化され、機能単位のモジュールの形態で開発されている。第１のモジュールの機能が第２のモジュールに提供される場合、第１のモジュールを内部モジュールとして、第２のモジュールを外部モジュールとして定義すると、内部モジュールは、内部モジュールの機能を外部モジュールに提供するための一連のAPI(Application Program Interface)を提供する。外部モジュールは、内部モジュールの具体的な内部構成に関係なく、提供されるAPIを用いて開発される。即ち、外部モジュールの観点から内部モジュールの機能が正しく動作するということは、提供されたAPIの機能が正しく動作するということを意味する。
【００９６】
本発明の実施例に係るソフトウェアのテスト方法は、この点に着目して、最適なソフトウェアテストのために、APIを中心としてテスト対象ソフトウェアをテストするものである。
【００９７】
しかし、Cのような伝統的なプログラミング言語においては、ソースコード内にAPIとAPIでない関数を区別できる情報がない。
【００９８】
このような場合にも効果的なソフトウェアテストを遂行するために、本発明に係る内部データを抽出する段階(S11)は、テスト対象ソフトウェアのソースコードを分析して、テスト対象となるAPIを決める。このために、内部データを抽出する段階(S11)においては、関数間の呼出し関係を用いる。すなわち、別の関数によって呼び出されない関数については、外部から接近可能なAPIであると解釈する。ただし、main()関数によって呼び出される場合は考慮しない。すなわち、main()関数以外の別の関数によって呼び出されない関数をAPIとして選択する。
【００９９】
図２にテスト対象ソフトウェアの内部データを抽出した結果を示す。
【０１００】
図２には、APIと、APIでない一般関数に関するデータと、変数の型に関するデータが示されている。
【０１０１】
APIは、main()関数以外の別の関数によって呼び出されない関数として定義され、一般関数はAPIでない関数として定義される。
【０１０２】
関数データの表示画面(201)には、api1乃至api12からなる12個のAPIと一般関数であるdegree_tan()が示されている。
【０１０３】
また、変数の型に関するデータの表示画面(202)には、Enm2・Nodeなどの変数の型が示されている。
【０１０４】
また、内部データを抽出する段階(S11)では、テスト対象ソフトウェアのソースコードを分析し、テスト対象ソフトウェアに含まれた関数間の呼び出し関係を抽出する。
【０１０５】
図３は、テスト対象ソフトウェアに含まれた関数間の呼び出し関係を示すコールグラフである。
【０１０６】
図３には、APIであるapi4、api6、api7、および、api8と、一般関数であるshow_uni、cp_node、show_node間の呼び出し関係が示されている。
【０１０７】
図３から分かるように、APIを対象としてテスト対象ソフトウェアをテストすると、テスト対象ソフトウェアをより詳細にテストすることが可能である。例えば、api4をテストする場合に、1)api4の関数パラメータによってshow_uni、または、cp_nodeが呼び出されてテストされ、show_uniが呼び出された場合、再びshow_nodeが呼び出されてテスト対象ソフトウェアを自動的に隅々までテストすることが可能であり、2)実際の環境においてテスト対象ソフトウェアが遂行される関数呼出しの経路を順にテストすることができる。 
【０１０８】
また、内部データを抽出する段階(S11)において、テスト対象ソフトウェアのソースコードを分析して、テスト対象ソフトウェアのコントロールフローグラフ(Control Flow Graph, CFG)を生成する。
【０１０９】
図４にテスト対象ソフトウェアのコンロトロールフローグラフを示す。
【０１１０】
図４には、関数内部のコントロール構造がブロック(Block)とブロック間のコントロールフローとして示されている。コントロールフローグラフにおけるノード（ｎｏｄｅ）は、プログラムブロックを表しており、ノード間を連結する線であるエッジ(ｅｄｇｅ)は、ブロックとブロック間の遂行順序を表している。 
【０１１１】
内部データを抽出する段階部分(S11)では、各々のノードに固有番号が表記され、そして、ノードの種類に関する説明が前記ノード番号と併記される。たとえば、第２のノード(node2)の場合、1: for_initと表記され、1は第２のノード(node2)の固有番号を指しており、for_initは第２のノード(node2)の種類に関する説明である。
【０１１２】
エッジの始まりに該当するノードは、アウトノード(out-node)であり、エッジの終わりに該当するノードは、インノード(in-node)である。２つのノードが１つのエッジによって連結されているならば、アウトノード(out-node)に該当するブロックの遂行が完了すると、インノード(in-node)に該当するブロックの遂行が始まる。たとえば、エッジ23(Edge23)の場合、第２のノード(node2)がアウトノード(out-node)であり、第３のノード(node3)がインノード(in-node)であり、第２のノード(node2)に該当するブロックの遂行が完了すると、第３のノード(node3)に該当するブロックの遂行が始まる。
【０１１３】
コントロールフローグラフには、関数内部のコントロールフロー以外に関数呼び出しも明示されている。第８のノード(node8)は関数を表しており、図４は第６のノード(node6)に該当する5番ブロックにおいてshow_nodeという関数に関する呼び出しが発生したことを表している。
【０１１４】
[テストデータを生成する段階(S12)]
テストデータを生成する段階(S12)は、変数の型のパーティションを生成する段階(S101)とAPI変数のパーティションを生成する段階(S102)とを含む。
【０１１５】
変数の型のパーティションを生成する段階(S101)において、テスト対象ソフトウェアに含まれた変数の型毎にテストすべき値の範囲を指定する変数の型のパーティションを生成する。
【０１１６】
図５に変数の型のパーティションの生成結果を示す。
【０１１７】
図５を参照すると、テスト対象ソフトウェアに含まれた変数の型毎にテストすべき値の範囲が指定され、テスト対象ソフトウェアに含まれた変数の型毎にテスト分割領域が生成される。
【０１１８】
このようなテスト分割領域は、次の形態を有しても良い。
【０１１９】
1)区間タイプ(Range Type Partition)
当該変数の型が有し得る値の範囲を領域別に分割して表す。たとえば、Intは、-2147483648〜2147483647の範囲を、-2147483648〜-2の範囲(RANGE)と、2〜2147483647の範囲(RANGE)に分割する。
【０１２０】
2)値並びタイプ(Value-List Type Partition)
当該変数の型が有し得る1つ以上の特定の値並びのリストを作成する。各々の値(value)は、算術型（値）あるいは文字列（値）を有しても良い。Intを例にすると、値は、-1、0、1として並んでいる。
【０１２１】
API変数のパーティションを生成する段階(S102)は、変数の型のパーティションとAPIに関するデータに基づいて、APIに含まれた関数の変数毎にテストすべき値の範囲を指定するAPI変数のパーティションを生成する。
【０１２２】
図６にAPI変数のパーティションの生成結果を示す。
【０１２３】
図６を参照すると、APIに含まれた関数の変数毎にテストすべき値の範囲が指定されていることが分かる。
【０１２４】
API変数のパーティションは、変数の型のパーティションを生成する段階で生成された変数の型のパーティションのデータと各々のAPIを分析して得られたデータを組み合わせて生成される。
【０１２５】
API変数のパーティションは、変数の型のパーティションに基づいて生成され、各々のAPIにおいて使われる変数に関するテストデータを生成するに用いられる。
【０１２６】
一方で、図６にはテストすべき値の範囲が具体的に示されていないが、互いに異なるAPIに含まれた同じ変数におけるテストすべき値の範囲は異なっても良い。これについて、api1とapi10の両方に含まれたintをたとえにして説明すると、次のとおりである。api1とapi10の両方にはintがあるが、api1とapi10に用いられるテストすべき値の範囲は、api1およびapi10に関する分析結果によって少し異なってくる。なぜならば、API変数のパーティションは、テスト対象ソフトウェアのソースコードに含まれるさまざまな常数値の中で、関数におけるコントロールフローに影響を及ぼす値がどのようなものであるかを分析して、その結果に基づいて、テストに用いられる入力値などを自動的に生成するからである。
【０１２７】
［テスト手続きを生成する段階(S13)］
テスト手続きを生成する段階(S13)では、APIおよびAPIに含まれた関数に関する呼出しの順序と各呼出し間の関係を指定するテストスクリプトを生成する。
【０１２８】
図７にテストスクリプトの生成結果を示す。 
【０１２９】
図７を参照すると、基本的にAPI毎に生成された１つのテストスクリプトがテストスクリプト表示画面(701)に示されている。また、テスト手続きを生成する段階(S13)は、APIリスト(List)に登録された関数間の遂行順序による依存関係が存在する場合、当該関数の遂行における先後関係を考慮して、複数のAPI呼出しを含むテストスクリプトをも生成する。テストスクリプトは、このスクリプトと結合するテスト入力データをともに指定する。
【０１３０】
たとえば、テストスクリプトcodescroll_api10_5384は、partition-testing default defaultからなる。partition-testingはテストデータでり、後述するテストプログラム遂行時に用いられる入力値でもある。このようなテストデータは、前述した変数の型のパーティション、API 変数のパーティションを用いて自動的に生成される。
【０１３１】
[テストドライバを生成する段階(S14)]
テストドライバを生成する段階(S14)では、テストデータとテストスクリプトに対応して１つのテストドライバを生成する。このようなテストドライバは、ソフトウェアテスト装置に記憶され、テスト対象ソフトウェアがインストールされている端末装置(2)にシリアル・ケーブル、USBケーブルなどの信号伝送手段を通じて伝送される。
【０１３２】
図８にテストドライバの生成結果を示す。
【０１３３】
図８を参照すると、テストドライバの表示画面(801)には、テスト対象ソフトウェアを遂行する段階(S15)で運用できるようにされたテストドライバのファイルリストが示されており、テストドライバのソースコードの表示画面(802)にはテストドライバのソースコードが示されている。
【０１３４】
このようなテストドライバは、テスト対象ソフトウェアがテストを遂行する段階(S15)で運用できるようにするプログラムであり、テスト対象ソフトウェアにおいて使用されるデータを生成したり、あるいは、テスト対象ソフトウェアから提供されたAPIを呼び出したりするときに用いられ、それにより、テスト対象ソフトウェアと、テストを遂行する段階(S15)とを連結させる機能を果たす。
【０１３５】
一方、テストドライバは、テスト対象ソフトウェアに関するテストの遂行結果が正しいかどうかを検査することができるテスト結果検査関数(Test Oracle Function)を有しているため、テスト対象ソフトウェアに関するテストの遂行結果のエラー可否を自動的に判断して、使用者にその結果を知らせることができる。
【０１３６】
[テストを遂行する段階(S15)]
テストを遂行する段階(S15)では、１つのテストドライバによりテストデータとテスト手続きを組み合わせた複数のテストケースを遂行することでテスト対象ソフトウェアのテストを行う。
【０１３７】
これに関して、テストデータが１００個、テストスクリプトが１００個である場合の例に挙げて説明する。これらのテストデータとテストスクリプトとを組み合わせると、１００×１００=１０,０００のテストケースが生じる。これらのテーストケースは１つのテストドライバに結合し、テスト対象ソフトウェアは、テストケースと結合したテストドライバによってテストされる。本発明の好ましい実施例によれば、テストケースは１つのテストドライバに結合するだけで、テストケース毎にテストプログラムを生成するものではない。これについてより詳細に説明する。従来のソフトウェアのテスト方法はテストケース毎にテストプログラムを生成したが、この場合には、全体のテストプログラムが大きくなりすぎて、埋め込みシステムに適用するのが難しいという問題があった。しかし、本発明の好ましい実施例に係るソフトウェアのテスト方法は、１つのテストドライバを用いることで、テストケースが増えてもテストプログラムは大きくならないというメリットがある。 
【０１３８】
図９にテストプログラムの生成結果を示す。
【０１３９】
図９には、テストドライバにテストデータとテストスクリプトが結合して生成されたテストプログラムが示されている。
【０１４０】
図１０にテスト対象ソフトウェアに関するテスト結果を示す。
【０１４１】
図１０を参照すると、テスト要約画面(Test summary window, 1001)と、カバリッジ要約画面(Coverage summary window, 1002)、そして、テスト詳細結果画面(Test details window, 1003)、および、追加情報画面(Additional information window, 1004)が示されている。
【０１４２】
1)テスト要約画面(1001)は、遂行されたテストケースの数、成功したテストケースの数、失敗したテストケースの数、警告を発したテストケースの数、使われたスクリプトの数などを要約して表示する。2)カバリッジ要約画面(1002)は、全体のテストケースを遂行した結果、達成されたカバリッジの情報を表示する。別のテストケースによって達成されたカバリッジは別に表示する。3)テスト詳細結果画面(1003)は、スクリプト毎に全テストケースの数、成功したテストケースの数、失敗したテストケースの数、警告を発したテストケースの数を表示する。4)追加情報画面(1004)は、全テストケースを遂行した際に、その関数コントロールフローグラフおよび呼び出しグラフのどの部分について何回（テストが）行われたかをグラフで表示する。
【０１４３】
[エラー情報を表示する段階(S16)]
エラー情報を表示する段階(S16)では、テスト対象ソフトウェアをテストした後、テスト対象ソフトウェアのエラーに関する情報を示す。
【０１４４】
図１１にテスト対象ソフトウェアにおけるエラーに関する情報を示す。
【０１４５】
図１１を参照すると、テスト対象ソフトウェアのエラーに関する情報がグループ化されて示されている。
【０１４６】
たとえば、エラー情報を表示する段階(S16)において、エラーに関する情報を、1)エラーが発生した位置、2)エラーが発生したAPI、3)エラーメッセージの種類別に整列して表示することができる。
【０１４７】
[テスト結果に関する情報を提供する段階(S17)]
テスト結果に関する情報を提供する段階(S17)では、テスト対象ソフトウェアのテスト結果に関する情報を生成し、これを記憶した後で提供する。
【０１４８】
このようなテスト対象ソフトウェアのテスト結果に関する情報は、HTML、MS WORD、MS Excelのうち少なくとも１つ形態で提供することができる。
【０１４９】
また、テスト対象ソフトウェアのテスト結果に関する情報は、韓国語、英語、日本語のうち少なくとも１つの言語で提供することができる。
【０１５０】
前述した本発明の好ましい実施例に係るコンピュータ読取り可能な記録媒体には、前述した本発明の好ましい実施例に係るソフトウェアのテスト方法を実行するためのプログラムが記録されている。
【０１５１】
このような本発明の好ましい実施例に係るコンピュータ読取り可能な記録媒体は、コンピュータ読取り可能なデータが記憶されているあらゆるタイプの記録装置を含む。たとえば、ROM、RAM、CD-ROM、磁気テープ、フロッピーディスク、光データ記憶装置、キャリアウェイブ(carrier wave、たとえばインターネットを通じての伝送)などがある。また、コンピュータ読取り可能な記録媒体は、ネットワークで連結されたコンピュータ装置に分散され、分散方式でコンピュータ読取り可能なコードが記憶され、実行されても良い。
【０１５２】
以上本発明の好ましい実施例について説明したが、本発明はこれらの実施例に限定されるものではない。本明細書に記載された内容に基づいて、当業者が上記好ましい実施例を変更して実施するか、または、それを応用することができることは明らかである。そのような変更または応用はもっぱら特許請求の範囲により定められる本発明の権利範囲に含まれるものと解釈すべきである。
【図面の簡単な説明】
【０１５３】
【図１】本発明の１つの実施例に係るソフトウェアテストシステムを示す図。
【図２】対象ソフトウェアの内部データを抽出した結果を示す図。
【図３】対象ソフトウェアに含まれた関数間の呼出し関係を示すコールグラフ(Call Graph)。
【図４】対象ソフトウェアのコントロールフローグラフ(Control Flow Graph, CFG)。
【図５】変数の型のパーティションの生成結果を示す図。
【図６】API変数のパーティションの生成結果を示す図。
【図７】テストスクリプトの生成結果を示す図。
【図８】テストドライバの生成結果を示す図。
【図９】テストプログラムの生成結果を示す図。
【図１０】テスト結果を示す図。
【図１１】エラーに関する情報を示す図。
【図１２】本発明の別の実施例に係るソフトウェアのテスト方法を示す図。
【符号の説明】
【０１５４】
1   ソフトウェアテスト装置        
2   端末装置
11  内部データを抽出する部分     
12  テストデータを生成する部分
13  テスト手続きを生成する部分           
14  テストドライバを生成する部分
15  テストを遂行する部分                 
16  エラー情報を表示する部分
17  テスト結果に関する情報を提供する部分         
101  変数の型のパーティションを生成する部分
102  API変数のパーティションを生成する部分
S11  内部データを抽出する段階
S12  テストデータを生成する段階
S13  テスト手続きを生成する段階
S14  テストドライバを生成する段階
S15  テストを遂行する段階
S16  エラー情報を表示する段階
S17  テスト結果に関する情報を提供する段階
S101  変数の型のパーティションを生成する段階
S102  API変数のパーティションを生成する段階
【図１】
2008176793.tif 000003
【図２】
2008176793.tif 000004
【図３】
2008176793.tif 000005
【図４】
2008176793.tif 000006
【図５】
2008176793.tif 000007
【図６】
2008176793.tif 000008
【図７】
2008176793.tif 000009
【図８】
2008176793.tif 000010
【図９】
2008176793.tif 000011
【図１０】
2008176793.tif 000012
【図１１】
2008176793.tif 000013
【図１２】
2008176793.tif 000014