(57)【特許請求の範囲】
【請求項１】
ソフトウェアの入力値及び出力値に関する要求を含む仕様に対して、１個のソフトウェアの少なくとも１つの機能を検証するためにコンピュータによってテストケースを自動的に形成する方法であって、
・組み合わせ要求と順序要求とを区別するステップと、
・モデル化された仕様を取得するために、真偽表で組み合わせ要求をモデル化し、有限状態機械で順序要求をモデル化するステップと、
・前記ソフトウェアの前記入力値を、前記入力値が承継である確率及び前記入力値の間の遷移時間に関連付けて演算行列を確立するステップと、
・前記演算行列にモンテカルロドローを実行することによりテストされる前記入力値の承継を選択するステップと、
・それぞれ選択された承継を前記モデル化された仕様を考慮して予測される前記出力値に関係付けるテスト行を含むテストケースを決定するステップと、
・決定される前記テストケースが以下の基準、機能コードの検証された割合、要求の検証された割合、検証時間、及び検証コストの少なくとも１つに対して既定の閾値に到達することを可能にする場合、前記決定工程を停止するステップと
を含むことを特徴とする方法。
【請求項２】
前記演算行列を確立するステップが、前記機能の既知のバグが現れる工程における入力値の承継の発生頻度を識別するために、検証される前記機能に関連するソフトウェアバグのデータベースからデータの統計的分析を遂行する段階を含むことを特徴とする、請求項１に記載の方法。
【請求項３】
前記演算行列を確立するステップが、過去のテストケースにおける入力値の各承継の検証の頻度を識別するために、検証される前記機能に関連する過去のテストケースのデータベースからデータの統計的分析を遂行する段階を含むことを特徴とする、請求項１に記載の方法。
【請求項４】
前記演算行列の形成が、入力値の承継ごとに、入力値の前記承継に対する以下の種類の制約、論理制約、条件制約、承継制約及び時間制約の少なくとも１つを識別して検証される前記機能に対してユーザプロファイルを決定する段階を含むことを特徴とする、請求項１に記載の方法。
【請求項５】
前記テストケースを決定する工程を停止するステップが、重み付け基準に関する数式に基づいて決定されることを特徴とする、請求項１に記載の方法。
【請求項６】
前記決定工程を停止するステップが、前記数式に対して各テスト行を確認するステップによって先行され、各テストステップが、前記数式の結果の有利な展開をもたらす場合に保持されることを特徴とする、請求項５に記載の方法。
【請求項７】
前記決定工程を停止するステップは、各テスト行を確認するステップであって、前記テストされた入力値が先行するテスト行において既にテストされているかどうかを検証するステップによって先行されることを特徴とする、請求項６に記載の方法。
【請求項８】
前記決定工程をいつ停止するかを決定する基準の閾値をユーザが定義することを可能にする構成ステップを含むことを特徴とする、請求項１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェア製品の機能検査のためのテストケースを形成する方法に関する。
【背景技術】
【０００２】
過去数年にわたって、電子機器は、自動車設計において主要な役割を果たしている。従って、自動車の電子機器の構造は、ますます複雑になってきており、自動車製造業者は、電子モジュールの設計を自動車用電子機器の供給業者に下請けに出す。こうした電子モジュールは、一般に、ソフトウェアを実行するプロセッサを有しており、こうしたモジュールで検出される誤りの多くは、バグとして知られるソフトウェアエラーである。
【０００３】
ソフトウェア開発サイクルにおける早い段階でバグを発見すること及び自動車製造業者又は車両ユーザによって発見されるバグの数を減少させることは、自動車下請け業者の優先目的である。
【０００４】
従来は、ソフトウェアテスト技術者が個人の知識に基づいて手動でテストケースを形成することが通常行われており、テストケースの品質は、個々のソフトウェアテスト技術者に依存することとなっていた。
【発明の概要】
【０００５】
よって、本発明の目的は、ソフトウェア、ソフトウェアコンポーネント又はソフトウェア製品の機能性テストのためのテストケースの形成を自動化することである。そうすることによって、上述の問題を解決して、従来技術よりも確実にソフトウェアバグを検出することが可能になる。
【０００６】
このため、本発明は、ソフトウェアの入力値及び出力値に関する要求を含む仕様（ｓｐｅｃｉｆｉｃａｔｉｏｎ）に対して、１個のソフトウェアの少なくとも１つの機能を検証するためにコンピュータによってテストケースを自動的に形成する方法を提供する。この方法は、以下のステップを含む。  
・組み合わせ（ｃｏｍｂｉｎａｔｏｒｉａｌ）要求と順序（ｓｅｑｕｅｎｔｉａｌ）要求とを区別するステップ  
・モデル化された仕様を取得するために、例えば真偽表で組み合わせ要求をモデル化し、例えば有限状態機械で順序要求をモデル化するステップ  
・ソフトウェアの入力値を、入力値が承継である確率及び入力値の間の遷移時間に関係付けて演算行列（ｏｐｅｒａｔｉｏｎ  ｍａｔｒｉｘ）を確立するステップ  
・演算行列にモンテカルロドロー（Ｍｏｎｔｅ  Ｃａｒｌｏ  ｄｒａｗ）を実行することによりテストされる入力値の承継を選択するステップ  
・モデル化された仕様を考慮して予測される出力値をそれぞれ選択された承継に関係付けるテスト行を含むテストケースを決定するステップ  
・決定されるテストケースが以下の基準、機能コードの検証された割合、要求の検証された割合、検証時間、及び検証コストの少なくとも１つに対して既定の閾値に到達することを可能にする場合、決定工程を停止するステップ
【０００７】
提案される要求の工程及び演算行列の形成は、人間の最小限の介入で、コンピュータが本発明の方法を自動化することを可能にする。これは、バグ検出性能の改善、機能を検証するのに必要な時間の減少、及び検証コストの相関減少をもたらす。
【０００８】
本発明の他の特徴及び利点は、本発明の特定の非制限的実施の以下の説明から明らかになる。
【０００９】
以下、添付の図面への参照が行われる。
【図面の簡単な説明】
【００１０】
【図１】本発明の原理のブロック図である。
【図２】モデル化された仕様を形成する工程のブロック図である。
【図３】本発明を使用する演算行列を構築する原理のブロック図である。
【図４】等確率演算行列を示す図表である。
【図５】等確率演算行列を示す図表である。
【図６】ユーザプロファイルに結び付けられる演算行列を形成する動作を示す図表である。
【図７】過去のテストケースに結び付けられる演算行列を形成する動作を示す図表である。
【図８】過去のバグに結び付けられる演算行列を形成する動作を示す図表である。
【図９】テストケースを決定する工程を示す図表である。
【図１０】テストケースの決定を停止する基準を示す図表である。
【発明を実施するための形態】
【００１１】
概略的に言えば、本発明の重要な態様は、特に自動車分野における使用が意図されるソフトウェアコンポーネント又は製品の機能性テストのためにテストケースを生成する統合的アプローチを提案する。
【００１２】
この方法は、ソフトウェアの入力値及び出力値に関する要求を含む仕様に対して少なくとも１つのソフトウェア機能を検証するためにコンピュータがテストケースを自動的に形成することを可能にする。
【００１３】
本発明の１つの実施によると、このアプローチは、以下の特徴ａ）からｇ）の１つ以上に基づく。  
ａ）１個のソフトウェアの機能要求を表すモデル  
ｂ）運転者プロファイルを作成するアプリケーションフレーム  
ｃ）過去に検出されたバグ及び以前のプロジェクトに関連するテストケースを回収するアプリケーションフレーム  
ｄ）重大な要求に関連する統計データ（回帰制御入力又は運転者の動作、回帰バグ、フィードバック）を使用してソフトウェア仕様モデルを拡張するアプリケーションフレーム
ｅ）ソフトウェアの品質（その構造的及び機能的範囲）及び生成されたテストケースのコストに基づく目標機能  
ｆ）テストを受ける機能の入力フィールドのモンテカルロシミュレーションに基づくテストアルゴリズム  
ｇ）テストケースの自動生成の間、目標機能を表す数式を最適化する発見的最適化アルゴリズム
【００１４】
本発明に関する他の情報は、統合的アプローチ及び対応するコンピュータプラットフォームが基礎とする以下の１）から３）の番号がつけられた分析の中で与えられる。
【００１５】
１）ソフトウェア要求のモデル化：現在のソフトウェア要求モデルは、所与の産業又は学術に関して開発されている。ソフトウェア要求を表す統合モデルは、自動車産業において存在しない。自動車製造業者は、供給業者に形式化された要求を引き渡す。そして、当該の供給業者は、自動車製造業者の形式化された要求に自身の工程を適合させなければならない。従って、自動車の用途及びその制限を考慮して、ソフトウェア要求を表すモデルが提案される。各ソフトウェア機能は、１組の入力信号、中間信号、及び出力信号を有する。信号は、要素によって互いに結び付けられる。要素は、１組の同じ型の機能要求である。２つの型の機能要求は、２つの型のモデル化要素である、判断表（ＤＴ、ｄｅｃｉｓｉｏｎ  ｔａｂｌｅ）及び有限状態機械（ＦＳＭ、ｆｉｎｉｔｅ  ｓｔａｔｅ  ｍａｃｈｉｎｅ）に基づいてモデル化され得る第１のレベルで（組み合わせ又は順序として）提案される。
【００１６】
２）バグを発見する高い確率を示すことを理由として遂行される重大なテストへの集中：自動車製造業者又は車両ユーザによって発見されている全てのバグの分析は、こうしたバグの一部を明らかにするために、所定の運転者向け制御入力又は動作が要求されることを示している。さらに、自動車分野において、所与のソフトウェア製品の機能性の半分以上が一連の車両ごとに共通することを考えれば、過去に検出されたバグ又は過去に開発されたテストケースの使用は非常に有利である。よって、２つのアプリケーションフレームが提案される。１つのアプリケーションフレームは、特定のソフトウェア機能を使用するときに運転者の行動をモデル化するものである。もう１つのアプリケーションフレームは、所与の機能について過去に利用されたデータを再利用するものである。さらに、統計的データを要求モデルに重ね合わせるための構造が提案され、このデータは、車両の運転者の行動プロファイル及び類似の製品におけるバグの検出に関する経験の使用に関連する。さらに、要求モデルのこの拡張は、既存のバグを発見する確率に関係があるテストを生成することを可能にする。
【００１７】
３）品質指標による自動テスト生成の監視：ソフトウェアテストは、いつテスト手順を終了させる必要があるかをソフトウェアテスト技術者が決定することを支援する特定の仮定及び目標に基づくことが多い。テストケースの生成を監視するために、品質指標、例えば、生成されたテストの形式構造又は機能範囲及びコストに基づく目標機能が提案される。また、品質指標のこうした３つのサブセットに対してソフトウェア試験者が正確な目標規定を定義することを可能にするインターフェースウィンドウが提案される。結果として、発見的最適化アルゴリズムは、入力フィールドにおいてモンテカルロシミュレーションによりテストケースを生成する間、目標機能を最適化することを目的とする。
【００１８】
図面を参照すると、図１に示される一般原理の中で、本発明の１つの特定の実施において、本方法は仕様をモデル化する段階から開始する。
【００１９】
仕様は、検証されるソフトウェア機能の入力値及び出力値に関する要求Ｒｅｑを含む。ここで、３つの入力Ｉと２つの出力Ｏがある。
【００２０】
・入力Ｉ１は、可能値０、１を有する。  
・入力Ｉ２は、可能値１、２、３を有する。  
・入力Ｉ３は、可能値０、１を有する。
【００２１】
この段階は、仕様における組み合わせ要求と順序要求とを区別するステップを含む（図２）。要求は、出力Ｏが入力Ｉに依存するとき、すなわちＯＲｅｑ（ｔ）＝ｆ（ＩＲｅｑ（ｔ））であるときに組み合わせである。要求は、時間ｔにおいて、出力Ｏが時間ｔで入力Ｉに依存し、より早い時間で出力Ｏに依存するとき、すなわちＯＲｅｑ（ｔ）＝ｆ（ＩＲｅｑ（ｔ）、ＯＲｅｑ（ｔ−１））であるときに順序である。
【００２２】
次に、組み合わせ要求は、真偽表又は判断表によって自動的にモデル化され、順序要求は、有限状態機械によって（開始状態、終了状態、及び条件に影響を受け得るそれらの間の遷移を結合して）モデル化される。これは、シミューレートされ得る要求のモデル化された仕様を取得することを可能にする。次に、モデル化された仕様は、好ましくは、テストされて、それが最初の仕様と良好に適合することを確実にするために確認される。
【００２３】
次に、ソフトウェアの入力値、入力値が承継する確率、及び入力値間の遷移時間に関する演算行列が作成される。演算行列は、入力値  （Ｉ１、Ｉ２、Ｉ３）の可能値（例えば、  ０、１；１、２、３）  が存在するのと同数の行及び列を備える。各行は、入力値に対応し、各列も同様に、入力値に対応する。全ての入力及び可能値は、こうした行及び列で表される。各行及び列の交点は、列の入力値が行の入力値を承継する確率（同じ行に対する確立の合計は１に等しい）、及び列の入力値が行の入力値を承継する時間又は時間範囲を含む。これは、入力値の承継と呼ばれる。
【００２４】
ここで、５つの演算行列が作成される。
【００２５】
第１の演算行列（図４）において、入力値は、同じ確率を有する任意の入力によって承継されてもよい。よって、全ての承継は、入力に関係なく同じ発生確率を有する。
【００２６】
第２の演算行列（図５）において、入力値は、同じ確率を有する任意の入力によって承継されてもよい。全ての承継は、入力値を承継する各入力において同じ発生確率を有する。
【００２７】
第３の演算行列（図６）は、入力値の承継ごとに入力値の承継に対する以下の種類の制約の少なくとも１つを識別して検証される機能に対してユーザプロファイルを決定することによって取得される。  
・論理制約
・条件制約
・承継制約
・時間制約
【００２８】
論理制約を分析することは、循環式（ｃｙｃｌｉｃ）又は非循環式（ａｃｙｃｌｉｃ）入力を識別することを可能にする。すなわち、入力値に値３を割り当てるために値１及び２の前後にそれを割り当てることが必要であれば、入力は循環式である。条件制約を分析することは、入力が既定の値になるのに必要な入力値を識別することを可能にする。例えば、Ｉ１は、Ｉ２が０に等しい場合に限り、１に等しくてもよい。承継制約を分析することは、必須承継を識別することを可能にする。例えば、Ｉ１が１になると、Ｉ２が２になって、Ｉ３が０になる。時間制約は、１つの入力値が別の１つを承継するのに必要な待機時間又は待機時間の範囲を決定することを可能にする。こうした承継は、第３の演算行列に繰り越される。
【００２９】
第４の演算行列（図７）は、検証される機能に関連する過去のテストケースのデータベースからデータを統計的に分析することにより生ずる。この統計的分析は、過去のテストケースにおける入力値の各承継の検証の頻度を識別するように指向される。データベースは、再利用を容易にするために機能によって分類され得る全ての過去のテストケースを結合する。統計的分析は、検証されるものと同じ機能に関連するテストケースに重点が置かれる。このデータベースは、例えば、Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｅｌのスプレッドシートのようなスプレッドシートに記憶される。第４の演算行列の形成及び統計的分析は、例えば、Ｖｉｓｕａｌ  Ｂａｓｉｃ型のプログラミング言語を使用して開発されるマクロコマンドによって達成される。
【００３０】
第５の演算行列（図８）は、検証される機能に関連するバグのデータベースからデータを統計的に分析することにより生ずる。この統計的分析は、機能の既知のバグが現れる工程における入力値の承継の発生頻度を識別するように指向される。データベースは、過去に検出された全てのバグを、再利用を容易にするために機能によって分類され得る、全てのバグを発生に導いた工程（すなわち、遷移時間を有する入力値の承継）、及び検証されるものと同じ機能に関連するバグに重点が置かれる統計的分析と結合する。このデータベースは、例えば、Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｅｌのスプレッドシートのようなスプレッドシートに記憶される。第５の演算行列の形成及び統計的分析は、例えば、Ｖｉｓｕａｌ  Ｂａｓｉｃ型のプログラミング言語を使用して開発されるマクロコマンドによって達成される。
【００３１】
５つの演算行列は、単一の演算行列を形成するように結合されてもよく、又は５つの演算行列において承継が選択され得るように互いに記憶されてもよい。
【００３２】
次に、方法は、演算行列（ここでは５つの演算行列）の少なくとも１つにおいてモンテカルロドローを遂行することによって、テストされる入力値の承継を選択するステップと、選択されたそれぞれの承継をモデル化された仕様から予想される出力値と関連付けるテスト行を有するテストケースを決定するステップとを含む（図９）。
【００３３】
決定されるテストケースが以下の基準、機能コードの検証された割合（検証が及ぶコードの量）、要求の検証された割合（検証による要求範囲）、検証時間、及び検証コストの少なくとも１つに対して既定の閾値に到達することを可能にする場合、決定工程は停止される。
【００３４】
テストケースの決定の停止は、少なくとも何らかの重み付け基準に関する数式（又は目的関数）から決定される。
【００３５】
ここで、数式は、Ｆ＝Σ（Ｏｔａｒｇｅｔ−Ｏｃｕｒｒｅｎｔ）×Ｗｉ＋Σ（Ｃｔａｒｇｅｔ−Ｃｃｕｒｒｅｎｔ）×Ｗｉであり、Ｏｔａｒｇｅｔは検証された割合閾値（コード及び要求）であり、Ｏｃｕｒｒｅｎｔはテストケースが決定されることによって現在検証された割合であり、Ｃｔａｒｇｅｔは時間及びコストの閾値であり、Ｃｃｕｒｒｅｎｔはテストケースの現在の状態において検証に必要な時間であり、Ｗｉはそれぞれ割合、時間及びコストに加えられる重み付けである。
【００３６】
図９は、到達する必要がある閾値及び閾値に割り当てられた重要性の関数としての重み付けを操作者が入力することを可能にするインターフェースを示す。
【００３７】
決定工程の停止は、この数式に対して各テスト行を確認するステップによって先行される。各テストステップは、数式の結果の有利な展開をもたらす場合に保持される。そうでなければ、このテスト行は破棄されて、新しいテスト行が形成される。同様に、決定工程の停止は、テストされた入力値が過去のテスト行において既にテストされているかどうかを検証する各テスト行を確認するステップによって先行される。これは、テストケースの決定及び決定工程を停止する決定を最適化することを可能にする発見的アルゴリズムを構成する。
【００３８】
方法は、好ましくは、ユーザが決定工程を停止する基準の閾値を定義することを可能にする構成ステップを含む。
【００３９】
この構成段階の間、操作者は、テスト行の破棄後に認識されるテストの数及び設定された閾値を達成することなくプログラムが無限ループを実行するのを防ぐための承継をさらに示してもよい。
【００４０】
機能の複数の開始構成がテストケースに対して認識され得る場合、方法を構成するステップは、考慮に入れられる開始構成の数を操作者が固定することが出来るように適合されてもよい。
【００４１】
本発明の方法の全体は、コンピュータプログラムによって実装される。
【００４２】
勿論、本発明は、記載された実施に限定されず、請求項に定義される本発明の範囲内の全ての変形を包含する。
【００４３】
特に、演算行列は、中間演算行列、例えば、最終的な演算行列を形成するために結合される上記の５つの演算行列から生成されてもよい。勿論、中間演算行列の数は異なってもよく、如何なる中間演算行列を経ずに最終的な演算行列を生成することが可能である。また、中間であるかそうでないか、全体的か部分的かに関わらず、経験及び／又は機能の特定の特徴の関数として操作者によって形成される演算行列を追加することが可能である。
【００４４】
テストケースを決定する工程は、１つ以上の上記の基準又は１つ以上の他の基準の関数として停止されてもよい。
【図１】
0005412510.tif 000002
【図２】
0005412510.tif 000003
【図３】
0005412510.tif 000004
【図４】
0005412510.tif 000005
【図５】
0005412510.tif 000006
【図６】
0005412510.tif 000007
【図７】
0005412510.tif 000008
【図８】
0005412510.tif 000009
【図９】
0005412510.tif 000010
【図１０】
0005412510.tif 000011