(57)【要約】      （修正有）【課題】ソフトウェアを設計変更する際、既存の機能に悪影響を与える可能性のある箇所を実装前に検出する。【解決手段】既存のソフトウェア設計書と変更後のソフトウェア設計書を入力して、変更後に新たに追加された機能を抽出し、追加された機能の中で既存モジュールの状態を変化させる可能性がある状態変化機能を抽出し、状態変化機能の情報と、既存のソフトウェアテスト仕様書の各テストケースと期待値を組合せて、既存モジュールの状態を変更させ得る操作を反映させた新規テスト仕様を作成し、新規テスト仕様を基にテストコードを生成し、既存のソースコードに前記テストコードを一緒に走らせて、新規テストを実行し、新規テストを実行した際の実行パスと既存テストを実行した結果の実行パスの期待値を照合して、悪影響が起こる可能性のある箇所を検出し、実行時のパスが未知である場合、追加機能が既存ソースコードに悪影響を与え得ると検出する。【選択図】図１
2015094964.tif 000002
【特許請求の範囲】
【請求項１】
既存のソフトウェア設計書と、変更後のソフトウェア設計書を入力し、前記設計書の機能の中で、変更後に新たに追加された機能を抽出する追加機能抽出部と、
前記追加された機能の中で、既存モジュールの状態を変化させる可能性がある状態変化機能を抽出する状態変化機能抽出部と、
前記状態変化機能の情報のデータと、既存のソフトウェアテスト仕様書の各テストケースの入力と期待値のデータを組み合わせて、既存モジュールの状態を変更させ得る操作を反映させた新規テスト仕様を作成する新規テスト仕様生成部と、
前記新規テスト仕様のデータを基に、テストコードを生成するテストコード生成部と、
既存のソースコードに前記テストコードを一緒に走らせて、新規テストを実行するテスト実行部と、
前記新規テストを実行した際の実行パスと既存テストを実行した結果の実行パスの期待値を照合して、悪影響が起こる可能性のある箇所を検出する実行パス照合部を備え、
前記実行時のパスが未知である場合、前記追加機能が既存ソースコードに悪影響を与え得ると検出する悪影響検出装置。
【請求項２】
前記追加機能抽出部にて抽出した追加機能の情報を記憶する追加機能記憶部と、
前記状態変化機能抽出部にて抽出した既存モジュールの状態を変化させる可能性がある機能の情報を記憶する状態変化機能記憶部と、
既存のソフトウェアテスト仕様書の、各テストケースの入力と期待値を記憶する既存テスト仕様記憶部と、
前記新規テスト仕様生成部で作成した新規テスト仕様を記憶する新規テスト仕様記憶部と、
前記テスト実行部で実行された新規テストの実行結果を記憶する新規テスト結果記憶部と、
既存のソフトウェアテスト実行結果から、既存のテストケースを実行した際の実行パスを抽出して記憶する既存テスト結果記憶部とを備える請求項１に記載の悪影響検出装置。
【請求項３】
前記ソフトウェアテスト仕様書の入力は、事前状態と入力値を含み、期待値は、出力値と事後状態を含む請求項１又は請求項２に記載の悪影響検出装置。
【請求項４】
前記悪影響が起こる可能性のある箇所は、前記テストケースのＩＤであって、前記未知の実行パスに関係する条件分岐箇所を含んでいる請求項１乃至請求項３のいずれか1項に記載の悪影響検出装置。
【請求項５】
前記既存モジュールの操作を利用している機能は、前記既存モジュールの状態を変化させる可能性がある状態変化機能に該当する請求項１乃至請求項４のいずれか1項に記載の悪影響検出装置。
【請求項６】
前記既存のソースコードは、既存ソフトウェアの全てのテストケースに成功している請求項１乃至請求項５のいずれか1項に記載の悪影響検出装置。
【請求項７】
前記追加機能は、１つずつ、前記既存ソースコードに悪影響を与え得るか否か判定する請求項１乃至請求項６のいずれか１項に記載の悪影響検出装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、ソフトウェア変更時の悪影響検出装置に関する。
【背景技術】
【０００２】
ソフトウェアの派生開発において、製品の機能に追加や変更を行うことにより、既存の機能に悪影響を与えることがある。
【０００３】
上記の影響を検出するための方法として、一般的には回帰テストが用いられている。
【０００４】
回帰テストでは、機能の追加や変更をコードに実装してから影響を確認するため、不具合が検出された際に、修正に大きな工数を割く必要があるとの問題があった。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平６−１１０７３４号公報
【特許文献２】特開２０００−１４８４８２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明が解決しようとする課題は、ソフトウェアの設計変更を行う際に、既存の機能に悪影響を与える可能性のある箇所を実装前に検出することのできる悪影響検出装置を提供することである。
【課題を解決するための手段】
【０００７】
実施形態の悪影響検出装置は、既存のソフトウェア設計書と、変更後のソフトウェア設計書を入力し、前記設計書の機能の中で、変更後に新たに追加された機能を抽出する追加機能抽出部と、前記追加された機能の中で、既存モジュールの状態を変化させる可能性がある状態変化機能を抽出する状態変化機能抽出部と、前記状態変化機能の情報のデータと、既存のソフトウェアテスト仕様書の各テストケースの入力と期待値のデータを組み合わせて、既存モジュールの状態を変更させ得る操作を反映させた新規テスト仕様を作成する新規テスト仕様生成部と、前記新規テスト仕様のデータを基に、テストコードを生成するテストコード生成部と、既存のソースコードに前記テストコードを一緒に走らせて、新規テストを実行するテスト実行部と、前記新規テストを実行した際の実行パスと既存テストを実行した結果の実行パスの期待値を照合して、悪影響が起こる可能性のある箇所を検出する実行パス照合部を備え、前記実行時のパスが未知である場合、前記追加機能が既存ソースコードに悪影響を与え得ると検出する。
【図面の簡単な説明】
【０００８】
【図１】本発明の実施形態に係る悪影響検出装置の概略構成を示すブロック図である。
【図２】追加機能の抽出を説明する図である。
【図３】追加機能記憶部に記憶される追加機能の情報を説明する図である。
【図４】既存モジュールの状態を変化させる可能性がある機能の抽出を説明する図である。
【図５】状態を変化させる可能性がある機能の情報を説明する図である。
【図６】既存テスト仕様の記憶を説明する図である。
【図７】新規テスト仕様の生成を説明する図である。
【図８】テストコードの生成を説明する図である。
【図９】新規テストの結果を説明する図である。
【図１０】既存のテスト結果のうち、抽出した実行パスを説明する図である。
【図１１】実行パス照合部の出力を説明する図である。
【図１２】実施形態に係る悪影響検出装置における悪影響が起こる可能性のある箇所の検出処理の流れを示すフローチャートである。
【図１３】実行パスを説明する図である。
【発明を実施するための形態】
【０００９】
以下、本発明の一実施の形態について、図面を参照して説明する。尚、各図において同一箇所については同一の符号を付すとともに、重複した説明は省略する。
【００１０】
まず、本実施形態で用いる主要な用語について説明する。
【００１１】
「機能」とは、各ユースケースを実現する動作をいい、１つ以上の「操作」を組み合わせた一連の動作である。
【００１２】
「操作」とは、個々のモジュールが行うことのできる動作をいう。
【００１３】
「ソフトウェアテスト」とは、広義では、ソフトウェアの開発工程で混入した誤りを検出する行為をいう。本実施形態では、ソフトウェアを実行した際に、ある入力値に対する出力値が期待値と一致しているかを検証する行為を指す。
【００１４】
「ソフトウェアテスト仕様書」とは、ソフトウェアテストにおいて、入力値、及び、入力値に検証対象の操作を行った際の期待値を明示した文書をいう。
【００１５】
「実行パス」とは、ソフトウェアにおいて、ある処理を実行する際に通るソースコード上の命令の流れ(順序)をいう。図１３は、実行パスを説明する図である。例えば、図１３において、太くした線が実行パスの一例である。本実施形態では、実行パスの一部でも未知のルートを辿る場合には、未知の実行パスであると取り扱う。
【００１６】
「(ソフトウェアへの)悪影響」とは、ソースコードを変更した際に、その変更によって既存の機能に問題が発生することをいう。
【００１７】
「リグレッションテスト（回帰テスト）」とは、プログラムを変更した際に、その変更によって予想外の影響が現れていないかどうか確認するために行うテストをいう。ソースコードの欠陥を取り除いたことによって、代わりに新しい欠陥が埋め込まれていないか確認する。
【００１８】
本実施形態においては、追加機能による既存モジュールの状態変化を既存テスト上に反映させ、実行時のパスが既知か未知かによって、追加機能が既存のソースコードに悪影響を与え得る箇所を実装前に検出するものである。
【００１９】
図１は、本発明の実施形態に係る悪影響検出装置の概略構成を示すブロック図である。この装置は汎用のコンピュータ（例えばパーソナルコンピュータ（ＰＣ）等）と、同コンピュータ上で動作するソフトウェアとを用いて実現される。コンピュータとしては、ＣＡＤ（Computer Aided Design）やＣＡＥ（Computer Aided Engineering）に好適なエンジニアリングワークステーション（ＥＷＳ）等も含む。本実施形態はこのようなコンピュータに、追加機能の中で既存のモジュールの状態を変化させる可能性のある操作を抽出し、それを既存ソースコードに対して実行し、実行パスが未知のものであれば、追加した機能が既存ソースコードに悪影響を与える可能性があると判断するプログラムとして実施することもできる。
【００２０】
本実施形態では、その前提条件として、既存ソフトウェアの成果物として、ソフトウェア設計書、ソースコード、ソフトウェアテスト仕様書およびソフトウェアテスト実行結果が与えられている。ソフトウェア設計書には、入力と期待値が明示されている。入力は事前状態と入力値を含み、期待値は出力値と事後状態を含む。ソフトウェアテスト実行結果には、各テストケースを実行した際の実行パスが明示されている。既存のソースコードは、既存ソフトウェアの全てのテストケースに成功している。
【００２１】
図１に示すように、本実施形態に係る悪影響検出装置１００は、主として、追加機能抽出部１０、追加機能記憶部１１、状態変化機能抽出部１２、状態変化機能記憶部１３、既存テスト仕様記憶部１４、新規テスト仕様生成部１５、新規テスト仕様記憶部１６、テストコード生成部１７、テスト実行部１８、新規テスト結果記憶部１９、既存テスト結果記憶部２０、実行パス照合部２１から構成されている。
【００２２】
追加機能抽出部１０は、変更前（既存）のソフトウェア設計書と、変更後のソフトウェア設計書を入力し、設計書の機能の中で、設計書変更後に新たに追加された機能を抽出する。追加機能の仕様には、既存モジュールのどの操作を利用するかが含まれる。図２は、追加機能の抽出を説明する図である。図２に示す例では、機能４、機能５、機能６が追加されている。
【００２３】
追加機能記憶部１１は、追加機能抽出部１０にて抽出した追加機能の情報を記憶する。図３は、追加機能記憶部１１に記憶される追加機能の情報を説明する図である。図３に示す例では、機能４について利用される既存モジュールと操作は、それぞれ“Ｏｌｄ１”と“Ｍ１”および“Ｏｌｄ３”と“Ｍ３”である。一方、機能５および機能６については、利用される既存モジュールと操作は“なし”であり、それぞれ新たなモジュールにもとづくものであることがわかる。
【００２４】
状態変化機能抽出部１２は、追加機能の中で、既存モジュールの状態を変化させる可能性がある機能を抽出する。本実施形態では、既存モジュールの操作を利用している機能については、一律、上記に該当するとみなしている。図４は、既存モジュールの状態を変化させる可能性がある機能の抽出を説明する図である。図４に示す例では、新規モジュール“Ｎｅｗ Ａ”が新規モジュール“Ｎｅｗ Ｂ”に対してある操作を命令し、“Ｎｅｗ Ｂ”は既存モジュール“Ｏｌｄ１”に対して、操作“Ｍ１”を命令している。これにより、既存モジュール“Ｏｌｄ１”が保持しているメンバ変数情報“Ｓ１”は、変化する可能性がある。同様に、“Ｏｌｄ１”は既存モジュール“Ｏｌｄ３”に対して、操作“Ｍ３”を命令している。これにより、“Ｏｌｄ３”が保持しているメンバ変数情報“Ｓ３”は、変化する可能性がある。本実施形態では、既存機能の前に機能を追加すると既存モジュールの状態が変わり、既存機能に関するテストは追加機能を反映したテストになるから、テスト結果自体が変化することは当然想定されることである。
【００２５】
状態変化機能記憶部１３は、状態変化機能抽出部１２にて抽出した既存モジュールの状態を変化させる可能性がある機能の情報を記憶する。図５は、状態を変化させる可能性がある機能の情報を説明する図である。図５に示す例では、既存モジュール“Ｏｌｄ１”と“Ｏｌｄ３”、操作“Ｍ１”と 操作“Ｍ３”が記憶されている。
【００２６】
既存テスト仕様記憶部１４は、既存のソフトウェアテスト仕様書の、各テストケースの入力と期待値を記憶する。入力には入力値と事前状態を含み、期待値には出力値と事後状態を含んでいる。図６は、既存テスト仕様の記憶を説明する図である。図６に示す例では、テストケース１、テストケース２、テストケース３について、それぞれ入力と期待値が記憶されている。
【００２７】
新規テスト仕様生成部１５は、状態変化機能記憶部１３における状態変化機能の情報のデータと既存テスト仕様記憶部１４における既存のソフトウェアテスト仕様書の各テストケースの入力と期待値のデータを組み合わせて、既存モジュールの状態を変更させ得る操作を反映させた新規テスト仕様を作成する。抽出した操作による既存モジュールの状態変化の可能性を反映させたものである。
【００２８】
新規テスト仕様記憶部１６は、新規テスト仕様生成部１５で作成した新規テスト仕様を記憶する。
【００２９】
新規テスト仕様の生成処理は、各テストケース内で用いられる既存モジュールの事前状態を、追加機能を実行した後の状態に変更するために行うものである。図７は、新規テスト仕様の生成を説明する図である。図７に示す例では、テストケース１の入力の事前状態として、既存モジュール“Ｏｌｄ１”についてのメンバ変数情報“Ｓ１”、既存モジュール“Ｏｌｄ３”についてのメンバ変数情報“Ｓ３”が記憶されている。既存モジュールの状態を変化させる可能性のある状態変化機能として、機能４は既存モジュール“Ｏｌｄ１”において“Ｍ１”なる操作を利用し、既存モジュール“Ｏｌｄ３”に対して“Ｍ３”なる操作を利用することが記憶されている。係る状態変化機能の情報を、既存テストであるテストケース１に埋め込むことにより、既存モジュールの事前状態が変化させられる。図７に示す新規テスト仕様では、テストケース１の入力の事前状態’は、既存モジュール“Ｏｌｄ１”において“Ｓ１×Ｍ１”なる操作を利用し、既存モジュール“Ｏｌｄ３”において“Ｓ３×Ｍ３” なる操作を利用することを示している。
【００３０】
テストコード生成部１７は、新規テスト仕様記憶部１６に記憶されている新規テスト仕様のデータを基に、テストコードを生成する。図８は、テストコードの生成を説明する図である。図８に示すテストコードでは、既存のテスト仕様書の事前状態の記述後に、追加機能で利用される操作を実行して、事前状態を変更することが記述されている。これは、Ｏｌｄ１、Ｏｌｄ３にのみ着目すると、追加機能４を実行したことに等しいことを表している。
【００３１】
テスト実行部１８は、既存のソースコードにテストコード生成部１７で生成されたテストコードを一緒に走らせて、新規テストを実行するものである。本実施形態では、既存のソースコードは、既存ソフトウェアの全てのテストケースに成功していることを前提としている。図９は、新規テストの結果を説明する図である。図９に示す例では、テストケース１の出力として、出力値、事後状態に加えて、実行パスが得られている。
【００３２】
新規テスト結果記憶部１９は、テスト実行部１８で実行された新規テストの実行結果を記憶する。
【００３３】
既存テスト結果記憶部２０は、既存のソフトウェアテスト実行結果から、既存のテストケースを実行した際の実行パスを抽出して記憶する。図１０は、既存のテスト結果のうち、抽出した実行パスを説明する図である。図１０に示す例では、テストケース１の実行パス、テストケース２の実行パス、テストケース３の実行パスが記憶されている。
【００３４】
実行パス照合部２１は、新規テストを実行した際の実行パスと既存テストを実行した結果の実行パスの期待値を照合して、悪影響が起こる可能性のある箇所を検出する。具体的には、テストケースのＩＤが検出され、未知の実行パスに関係する条件分岐箇所を含んでいる。図１１は、実行パス照合部２１の出力を説明する図である。図１１に示す例では、既存モジュールにおいて既存機能に関するテストケース１の実行パスは、既存テストの実行パスの期待値である実行パス１、実行パス２、実行パス３と同じである。これらは、過去のいずれかのテストケースで出現したものであるから、安全なパスと判断する。これに対して、テストケース１の実行パスが、未知のパスである場合には、過去のいずれかのテストケースで出現しておらず、悪影響を与える可能性が大きいと判断する。尚、追加機能に関するテストを実行した場合の実行パスが、機能を追加前のテストケースの実行パスとは異なるが、別のテストケースで網羅した実行パスである場合には、未知のパスと比較すると悪影響の危険は少ないと判断できる。
【００３５】
ユーザは、実行パス照合部２１の検出結果を受けて、追加機能の見直し等を行う。
【００３６】
次に、以上のように構成された悪影響検出装置１００における悪影響が起こる可能性のある箇所の検出処理の流れについて説明する。
【００３７】
図１２は、実施形態に係る悪影響検出装置１００における悪影響が起こる可能性のある箇所の検出処理の流れを示すフローチャートである。
【００３８】
まず、設計変更前後の設計書を比較し、設計変更後に追加された機能に関する部分を抽出する（ステップＳ１２０１）。
【００３９】
次いで、追加機能の中から、既存モジュールの状態を変化させる可能性のある機能を抽出する（ステップＳ１２０２）。ここでは、既存のモジュールの操作を利用している機能などを想定している。
【００４０】
次いで、テスト仕様書の各テストケースの事前状態に、ステップＳ１２０２で抽出した操作の情報を付加する（ステップＳ１２０３）。ここでの処理は、各テストケースで事前状態が定義されている既存モジュールに対し、どの操作が利用されているかを関連付ける行為で、追加機能を実行した後の既存モジュールの状態を作るために必要である。
【００４１】
次に、上記テスト仕様書をテストコードに変換する（ステップＳ１２０４）。各モジュールの事前状態の変化は、ステップＳ１２０２で抽出した操作をテストコードの各テストケースの冒頭に埋め込むことで実現する。ステップＳ１２０４の処理によって、追加機能を実行した後の既存モジュールの状態が実現され、追加機能の実行後の状態で(テスト対象)の既存機能をテストすることが可能になる。
【００４２】
次いで、上記テストを、既存のソースコードに対して実行する（ステップＳ１２０５）。
【００４３】
次いで、上記テストの実行パスを、過去のテストケースの実行パスと比較する（ステップＳ１２０６）。
【００４４】
比較結果によって以下のように判断し、出力する（ステップＳ１２０７）。
【００４５】
（１）変更前の当該テストと同じ実行パス：問題はないと思われる。  
（２）当該テストのものとは異なるが、他のテストで出現した実行パス：問題はないと思われる。  
（３）変更前のいずれのテストでも出現しなかった実行パス：既存機能に影響を与える可能性が大きい。
【００４６】
判断結果の出力後、検出処理を終了する。
【００４７】
以上説明したように、本実施形態によれば、機能の追加や変更が既存の機能に与え得る影響を、設計の段階で確認することができるため後戻り工数を削減することができる。
【００４８】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００４９】
１００・・・悪影響検出装置
１０・・・追加機能抽出部
１１・・・追加機能記憶部
１２・・・状態変化機能抽出部
１３・・・状態変化機能記憶部
１４・・・既存テスト仕様記憶部
１５・・・新規テスト仕様生成部
１６・・・新規テスト仕様記憶部
１７・・・テストコード生成部
１８・・・テスト実行部
１９・・・新規テスト結果記憶部
２０・・・既存テスト結果記憶部
２１・・・実行パス照合部
【図１】
2015094964.tif 000003
【図２】
2015094964.tif 000004
【図３】
2015094964.tif 000005
【図４】
2015094964.tif 000006
【図５】
2015094964.tif 000007
【図６】
2015094964.tif 000008
【図７】
2015094964.tif 000009
【図８】
2015094964.tif 000010
【図９】
2015094964.tif 000011
【図１０】
2015094964.tif 000012
【図１１】
2015094964.tif 000013
【図１２】
2015094964.tif 000014
【図１３】
2015094964.tif 000015