JPH11282722A

JPH11282722A - プログラム検証方法

Info

Publication number: JPH11282722A
Application number: JP10087378A
Authority: JP
Inventors: Mutsumi Komuro; 睦小室
Original assignee: Hitachi Software Engineering Co Ltd
Current assignee: Hitachi Software Engineering Co Ltd
Priority date: 1998-03-31
Filing date: 1998-03-31
Publication date: 1999-10-15

Abstract

(57)【要約】【課題】プログラム構成が複雑で、ドキュメントもな
いソフトウェアシステムについて、必要修正箇所を効率
的に見い出し、さらに修正の良否、性能の劣化を効率的
に検証可能にすること。【解決手段】仕様変更によって修正が必要となる１つ
の修正対象プログラムに対し、変更後の仕様条件を満た
す第１のテストデータと、この第１のテストデータの処
理結果と同一処理結果となる第２のテストデータを入力
し、これらの第１、第２のテストデータに対する処理を
前記修正対象プログラムの所定分割単位でコンピュータ
に実行させ、第１、第２のテストデータに対する実行状
況、結果を比較し、その異同によって仕様変更に対する
修正対象プログラムの修正必要個所を所定分割単位で特
定する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ソフトウェア開発
に伴うプログラム中のバグ検出やプログラムの正しさを
検証する際に使用するプログラム検証方法に関するもの
であり、特に、仕様変更に伴う修正必要箇所の自動検
出、修正したプログラムの修正の良否や性能の劣化など
のテストを支援するのに好適なプログラム検証方法に関
するものである。

【０００２】

【従来の技術】従来において、プログラムが仕様通りに
作成されているかどうかの検証方法として各種の方法が
提唱されているが、仕様の記述に特別の技術が必要な
上、検証作業も簡単ではなく、工数も多くかかるため、
現実には用いられていない。

【０００３】また、実際に出来上がったプログラムに対
するバグの抽出は十分な量のテストデータを流して不具
合がないかどうかを調べるやり方が一般的で、従来、行
われていた対策はバグ抽出の環境を整える方法か、バグ
が最初から入り込まないように設計時のレビューを徹底
するといったエンジニアリング的な解決策が主であり、
バグの系統的な発見方法はほとんど知られていなかっ
た。

【０００４】一方、既に作成済みのプログラムの保守に
関してはプログラムを静的に解析してサブルーチン呼出
しや変数の依存関係を調べる手法が知られている。

【０００５】

【発明が解決しようとする課題】ところで、西暦２００
０年には現在稼働しているコンピュータシステムの多く
が正しく動作しなくなると言われている。これは、その
システムを構成するプログラム内部での年月処理が西暦
の下２桁のみを用いて行われていることに起因してい
る。すなわち、もともと２０００年以降まで使用するこ
とを想定して設計されていないプログラムをその年月処
理の限界を越えて使用する状況が生じたことが原因であ
る。同様の状況は、１６ビットコンピュータが３２ビッ
トへと、あるいはさらに６４ビットへと機能拡張される
ような時にも生じる。

【０００６】このような場合、既に作成してから年月が
経っているため、もともとのシステムの設計者を捜すこ
とは困難である。また、度重なる顧客要求への対応から
システム全体のプログラムの構成も複雑化し、しかもシ
ステム構築に当てられる費用、日数が限られているため
ドキュメントも整備されていないのが現実である。した
がって、使用されているプログラムのソースを直接調べ
る必要がある。

【０００７】そこで、上記のように、プログラムを静的
に解析してサブルーチン呼出しや変数の依存関係を調べ
る手法を用いて対象プログラムの修正必要箇所を探し出
すことが考えられる。

【０００８】しかしながら、この手法では変数の依存関
係などの間接的な情報しか得られず、修正必要個所を直
接的に特定することができず、修正必要個所を特定する
までに長時間を要するという問題があった。

【０００９】また、解析時の環境が実際に稼働する時の
環境と異なるため、解析結果が不必要に多過ぎたり、少
な過ぎたりするなど、適切な解析結果が得られないとい
う問題があった。

【００１０】さらに、他システムへの呼出しが生じるよ
うな処理を含む場合、実際にどのような呼出しが生じる
かを決定できないため、他システムへの呼出しを行なう
ステップ以降の解析が進められなくなるといった問題点
があった。

【００１１】さらに、最近の業務プログラムの開発では
ＣＡＳＥツールの使用が一般化し、簡易プログラム記述
から生成されたプログラムが用いられている場合があ
る。このような場合、使用しているプログラムのソース
コードは人間が直接読んで理解することが著しく困難で
ある。この場合、元の簡易プログラム記述とプログラム
作成に使用したのと同じバージョンのＣＡＳＥツールが
入手できればよいが、多くの場合それは困難であり、難
解なソースコードを解読して解析を進めざるを得なくな
り、修正必要個所を特定するまでに長時間を要するとい
う問題があった。

【００１２】一方、修正を必要とするプログラムは、既
に稼働中のシステムであるから、修正後でも最低限、現
在利用している範囲の機能はそのまま使用可能であるこ
とが必要である。

【００１３】そこで、稼働中のシステムを最初に設計さ
れた限界を越えて引き続き使用したいという時に生じる
ソフトウェアの修正作業およびそれに引き続くテスト作
業を自動化あるいは支援することが可能な方法の実現が
強く望まれている。

【００１４】本発明は、このような事情を解決すべくな
されたものであり、その目的は、プログラム構成が複雑
で、ドキュメントもないソフトウェアシステムについ
て、必要修正箇所を効率的に見い出し、さらに新たな仕
様通りに修正されたことを検証し、さらに、修正前と同
じ稼働条件ではもともとのシステムと同じ機能をそのま
ま使用できることを効率的に検証することができるプロ
グラム検証方法を提供することである。

【００１５】

【課題を解決するための手段】上記目的を達成するため
に、本発明は、仕様変更によって修正が必要となる１つ
の修正対象プログラムに対し、変更後の仕様条件を満た
す第１のテストデータと、この第１のテストデータの処
理結果と同一処理結果となる第２のテストデータを入力
し、これらの第１、第２のテストデータに対する処理を
前記修正対象プログラムの所定分割単位でコンピュータ
に実行させ、第１、第２のテストデータに対する処理手
順を比較し、その異同によって仕様変更に対する修正対
象プログラムの修正必要個所を所定分割単位で特定する
ようにしたことを特徴とする。

【００１６】あるいは、仕様変更によって修正が必要と
なる１つの修正対象プログラムに対し、変更後の仕様条
件を満たす第１のテストデータと、この第１のテストデ
ータの処理結果と同一処理結果となる第２のテストデー
タを入力し、これらの第１、第２のテストデータに対す
る処理を前記修正対象プログラムの所定分割単位でコン
ピュータに実行させ、指定した変数集合の指定した複数
のアドレスでの値の集合の組を作成し、それぞれの値集
合について予め与えておいた等式を満たすか否かを調べ
ることによって仕様変更に対する修正対象プログラムの
修正必要個所を所定分割単位で特定するようにしたこと
を特徴とする。

【００１７】ここで、第１、第２のテストデータに対す
る修正対象プログラムの処理は、並列解釈可能な解釈手
段を用いて所定分割単位で並列解釈し、実行するように
構成することが可能である。この場合、所定分割単位の
最小単位は命令文の１行、あるいは１行をさらに細かく
分けたもので構成される。

【００１８】

【発明の実施の形態】以下、図面を参照して本発明の実
施形態を詳細に説明する。本発明は次のような状況で実
施される。すなわち、既に利用実績のあるプログラムＰ
に対し、設計時に考えていた限界を越えて稼働させたい
というユーザ要求があり、プログラムＰを修正して新し
いプログラムＰ'を作成したいというような状況であ
る。本発明の実施においては次の仮定を置く。

【００１９】(仮定１) プログラムＰを分割する仕方
Δ(Ｐ)が与えられており、修正はこの分割を保つ。すな
わち、Ｐ'に対しても分割Δ(Ｐ')が定義でき、Δ(Ｐ)と
Δ(Ｐ')の間には図１に示すように１：１の対応関係φ
がつくものとする。

【００２０】もっとも簡単な場合は、Δはプログラムの
１行への分割であり、φは同じ行番号を持つ行同士を対
応させる関係である。

【００２１】前述の場合、プログラムＰと入力データＤ
を与えると、分割Δ(P)上の遷移系列が定まる。これを
δ(Ｐ，Ｄ)で表わすことにする。また、φによりΔ(Ｐ)
上の遷移系列の空間ＳとΔ(Ｐ')上の遷移系列の空間Ｓ'
との間の同型写像が存在する。これをΦとする。

【００２２】(仮定２) 修正後プログラムＰ’の定義
域Ｄ(Ｐ')から修正前プログラムＰの定義域Ｄ(Ｐ)への
写像ψが存在し、図１の図式が可換となる。これは式で
書けば、δ(Ｐ’，Ｔ)＝Φ(δ(Ｐ,φ(Ｔ)))がすべての
Ｔ∈Ｄ(Ｐ')に対して成り立つということである。

【００２３】例えば、いわゆる「２０００年問題」の場
合には１９ＸＸ年代（ＸＸ＝００〜９９）のデータがＤ
(Ｐ)であり、一方Ｄ(Ｐ’)は２０００年以降のデータも
含む。φは２０００年以降のデータから日付をシフトし
て１９ＸＸ年代のデータを得る写像である。このこと
は、例えば２０００年の９月１日を基点として延べ日数
を用いて、２００１年の５月１日時点の利息計算を行う
というような場合には、１９９８年９月１日を基点とし
て１９９９年５月１日時点の利息計算を行うようにシフ
トすればよいことを意味する。

【００２４】このような前提のもとで、既に利用実績の
あるプログラムＰに対し、設計時に考えていた限界を越
えて稼働させたいというユーザ要求があり、プログラム
Ｐを修正して新しいプログラムＰ'を作成したいとす
る。このような場合、プログラムＰの検証を行いたい適
当な分割Δ(Ｐ)を選び、仕様変更後のテストデータＴに
ついて、修正前プログラムＰが正しく動く限界内のデー
タＴ０で、Ｐ(Ｔ０)とＰ'(Ｔ)とが同じ処理手順を与え
るものを選定し、修正前のプログラムＰに入力し、処理
を実行させる。前記仮定２より、例えばＴ０＝φ（Ｔ）
とすれば、このようにすることが可能である。ここで、
Ｐ(Ｔ)を考えると修正前プログラムＰにはまだ修正作業
を施していないので正しくは動かないはずである。そこ
で、遷移系列δ（Ｐ，Ｔ０），δ（Ｐ，Ｔ)を比較す
る。分割Δ(Ｐ)が適切に選ばれていれば、遷移系列δ
（Ｐ，Ｔ０），δ（Ｐ，Ｔ)に違いが生じる。その違い
の生じた分割Δ∈Δ(Ｐ)に要修正箇所がある筈である。
分割Δ(Ｐ)に従って実行する場合、プログラムＰ，Ｐ'
の１分割上の実行を並列に行い、同期をとって比較して
ゆくことが望ましい。本発明は、基本的にはこのように
して修正必要個所を検出する。

【００２５】修正必要個所が判明し、必要な修正を実施
したならば、修正前のプログラムＰに対しテストデータ
Ｔ０を与え、さらに修正後のプログラムＰ'に対しテス
トデータＴを与え、これらのプログラムＰ，Ｐ'を分割
単位Δで実行させ、その遷移系列δ（Ｐ，Ｔ０），δ
（Ｐ，Ｔ)を比較する。すると、修正作業が正常に行な
われているならば、２つのプログラムＰ，Ｐ'の処理手
順は同一になる筈であるから、遷移系列が同一であれば
修正正常、同一でなければ、修正不良として検出する。

【００２６】さらに、必要な修正の良否を確認したなら
ば、修正前のプログラムＰおよび修正後のプログラム
Ｐ'に対し、同じテストデータＴ０を与え、その遷移系
列δ（Ｐ，Ｔ０），δ（Ｐ，Ｔ)を比較する。この結
果、処理手順が同じでも、その処理手順を導き出すまで
の時間が長くなっていれば、修正後のプログラムＰ'の
性能は明らかに劣化しているものとして検出する。逆
に、処理手順を導き出すまでの時間が短くなっていれ
ば、性能が向上しているものとして検出する。

【００２７】図２は、本発明を実施するための最も基本
的なシステム構成を示した図であり、２つのプログラム
を所定分割単位（例えば、１行単位）で交互に実行可能
な解釈器２０２をコンピュータ（図示せず）内部に用意
しておき、修正対象のプログラムＰ２０１に対し、変更
後の仕様条件を満たすテストデータＴと、このテストデ
ータＴと同一処理結果となるテストデータＴ０を入力
し、処理を実行させ、その処理手順を比較することによ
り、修正前プログラムＰ２０１の修正必要個所を検出
し、修正必要個所メッセージ２０３を出力するという構
成である。

【００２８】解釈器２０２は、例えば図４に示すように
入力器２０２１、評価器２０２２、比較器２０２３、メ
ッセージ出力器２０２４から構成され、評価器２０２２
がプログラムＰ２０１の命令文を所定分割単位で解釈
し、入力器２０２１から２つのテストデータＴ０，Ｔを
読み込み、このテストデータＴ０，Ｔに対する処理を実
行させる。プログラムＰ２０１の命令文を所定分割単位
を例えば、１行単位とした場合、評価器２０２２がプロ
グラムＰ２０１の命令文を１行単位で解釈し、入力器２
０２１から２つのテストデータＴ０，Ｔを交互に読み込
み、このテストデータＴ０，Ｔに対する処理を１行単位
で実行させる。そして、その実行手順を比較する。処理
手順が同一ならば、その行は修正不要として検出する。
しかし、処理手順が同一でなければ、異なる動作をして
いることになるので、その異なる手順を与える行は新し
い仕様条件を満たすことができず、修正を必要とする個
所として検出し、メッセージ出力器２０２４から修正必
要個所メッセージ２０３を出力させる。このようにし
て、Φ（δ（Ｐ，Ｔ０）），δ（Ｐ，Ｔ)の比較が行わ
れる。

【００２９】ここで、本発明の方法をさらに一般化して
考えると次の通りになる。いま、既に利用実績のあるプ
ログラムＰに対し、設計時に考えていた限界を越えて稼
働させたいというユーザ要求があり、そのプログラムＰ
を修正して新しいプログラムＰ'を作成したいとする。
プログラムＰの稼働限界を越えたデータをＴとすると、
その処理手順Ｐ（Ｔ）は正しく動作しない可能性がある
ため、プログラムＰを修正したプログラムＰ'を作成す
る必要がある。そこで、Ｐ(ψ（Ｔ））を考えると、前
述の仮定（２）からδ(Ｐ'，Ｔ）＝Φ(δ(Ｐ,φ(Ｔ)))
であるから、Ｐ(φ(Ｔ))は分割Δ上の遷移系列のみに着
目するなら、Ｐ'（Ｔ）をシミュレートしている。

【００３０】そこで、Ｐ（Ｔ）とＰ(φ(Ｔ))の動作を比
較し、δ(Ｐ，Ｔ)＝δ(Ｐ，φ(Ｔ))が成立しているかど
うかを調べる。これは図３に示すように図２の解釈器２
０２を用いて遷移系列δ(Ｐ，Ｔ)とδ(Ｐ，ψ(Ｔ))を順
に比較していくことで実現される。

【００３１】すなわち、評価器２０２２は、プログラム
Ｐのカレント評価位置Ｌ１とカレント評価環境ＥＮＶ１
およびプログラムＰ'のカレント評価位置Ｌ２とカレン
ト評価環境ＥＮＶ２を保持している。評価器２０２２
は、プログラムＰにデータＴ０を環境ＥＮＶ１で与えた
ときの位置Ｌ１での実行結果と、プログラムＰ'にデー
タＴを環境ＥＮＶ２で与えたときの位置Ｌ２での実行結
果とをそれぞれ新しい環境と新しい評価位置の組（ＥＮ
Ｖ１，Ｌ１），（ＥＮＶ２，Ｌ２）として出力する（ス
テップ３０１）。このようにして新しい評価位置が決定
される。

【００３２】比較器２０２３は、Ｌ１とＬ２とを比較し
（ステップ３０２）、Ｌ１とＬ２の位置はΔ（Ｐ）上で
同じ分割単位に属するか否かを判定する。すなわち、Ｌ
１＝φ（Ｌ２）か否かを判定する。

【００３３】Ｌ１＝φ（Ｌ２）でない場合、Ｐ（Ｔ）と
Ｐ(ψ(Ｔ))の遷移系列が異なっていることになるため、
この部分の分割単位Ｌ１，Ｌ２を修正必要個所としてそ
のカレント評価環境の情報ＥＮＶ１，ＥＮＶ２と共にメ
ッセージ出力する（ステップ３０３）。しかし、Ｌ１＝
φ（Ｌ２）であった場合、Ｐ（Ｔ）とＰ(φ(Ｔ))の遷移
系列は同じであることになるため、修正不要の個所とし
て判定し、入力器２０２１から次の分割単位の文を入力
させる。以上の動作をプログラムＰのファイル終了コー
ドＥＯＦが見つかるまで（ステップ３０４）、繰り返し
実行する。

【００３４】本発明の検証方法により処理手順Ｐ(Ｔ
０)，Ｐ(Ｔ)を比較する場合、単に処理手順を比較する
だけでなく、次に実行されるべき分割単位（例えば行番
号）や経路、指定した変数集合の指定した複数のアドレ
スでの値の集合の組などを含めて比較することにより、
さらに高度の検証が可能になる。

【００３５】１行の文を解釈した結果である次に実行さ
れるべき分割単位（例えば行番号）を採用した場合、次
に実行されるべき分割単位が一致しない場合には修正必
要個所として検出するという構成になる。また、指定し
た変数集合の指定した複数のアドレスでの値の集合の組
を採用した場合、指定した変数集合の指定した複数のア
ドレスでの値の集合の組を作成し、それぞれの値集合に
ついて予め与えておいた等式を満たすか否かを調べるこ
とによって仕様変更に対する修正対象プログラムＰの修
正必要個所を検出するという構成になる。

【００３６】なお、２つの文を並列処理可能な解釈器２
０２を用いて２つのテストデータＴ０，Ｔに対する処理
を交互に実行させているが、解釈器２０２に代えて、同
一機能の解釈器を内蔵した２つのコンピュータを用意
し、この２つのコンピュータに修正対象の同一プログラ
ムＰを同期して実行させ、一方のコンピュータに入力し
たテストデータＴ０に対する処理手順と他方のコンピュ
ータに入力したテストデータＴに対する処理手順とを第
３のコンピュータで比較し、その異同によって仕様変更
に対する修正必要個所を検出するように構成することが
できる。

【００３７】次に、以上のようにして検出した修正前プ
ログラムＰの修正必要個所を仕様変更後の条件に合うよ
うに修正し、その修正したプログラムＰ’の修正が正し
く行なわれているかどうかを検証する方法について説明
する。

【００３８】図５（ａ）は、修正の正しさを検証するた
めの基本的なシステム構成を示したものであり、図２の
場合と同様の解釈器２０２をコンピュータ内部に用意し
ておき、さらにそのコンピュータ内には修正前プログラ
ムＰ５０１と修正後プログラムＰ’５０２を実行可能状
態で格納しておく。この構成において、修正後プログラ
ムＰ’５０２に対して変更後の仕様条件を満たすテスト
データＴを入力すると共に、修正前プログラムＰに対し
ては、このテストデータＴと同一処理結果となるテスト
データＴ０を入力し、処理を所定分割単位で並列に実行
させ、その処理手順の比較によりδ(Ｐ’，Ｔ)＝Φ(δ
(Ｐ,ψ(Ｔ)))であるか否かを比較し（例えば、次に実行
すべき行番号が同じであるか否かを比較し）、処理手順
が等しくなければ、その所定分割単位における修正は不
良であるとして検出し、修正不良個所メッセージ５０３
を出力するという構成である。

【００３９】図６は、この場合の検証方法手順を示した
フローチャートであり、評価器２０２２は、プログラム
Ｐのカレント評価位置Ｌ１とカレント評価環境ＥＮＶ１
およびプログラムＰ'のカレント評価位置Ｌ２とカレン
ト評価環境ＥＮＶ２を保持している。評価器２０２２
は、プログラムＰにデータＴ０を環境ＥＮＶ１で与えた
ときの位置Ｌ１での実行結果と、プログラムＰ'にデー
タＴを環境ＥＮＶ２で与えたときの位置Ｌ２での実行結
果とをそれぞれ新しい環境と新しい評価位置の組（ＥＮ
Ｖ１，Ｌ１），（ＥＮＶ２，Ｌ２）として出力する（ス
テップ６０１）。このようにして新しい評価位置が決定
される。

【００４０】比較器２０２３は、Ｌ１とＬ２とを比較し
（ステップ６０２）、Ｌ１とＬ２の位置はΔ（Ｐ）上で
同じ分割単位に属するか否かを判定する。すなわち、Ｌ
１＝φ（Ｌ２）か否かを判定する。

【００４１】Ｌ１＝φ（Ｌ２）でない場合、修正前プロ
グラムＰ５０１と修正後プログラムＰ'５０２の動作が
異なっていることになるため、修正後プログラムＰ'５
０２の行Ｌ２の修正は正しくないものとしてそのカレン
ト評価環境情報ＥＮＶ１，ＥＮＶ２と共にメッセージ出
力する（ステップ６０３）。しかし、Ｌ１＝φ（Ｌ２）
であった場合、Ｐ（Ｔ）とＰ(φ(Ｔ))の遷移系列は同じ
であることになるため、修正不要の個所として判定し、
入力器２０２１から次の分割単位の文を入力させる。以
上の動作をプログラムＰのファイル終了コードＥＯＦが
見つかるまで（ステップ６０４）、繰り返し実行する。

【００４２】これにより、修正後プログラムＰ’５０２
の修正が正しく行なわれているか否かを自動的に検証す
ることができる。

【００４３】ここで、２つの文を解釈器２０２を用いて
２つのテストデータＴ０，Ｔに対する処理を交互に実行
させているが、図５（ｂ）に示すように、解釈器２０２
に代えて、同一機能の解釈器を内蔵した２つのコンピュ
ータ５０４，５０５を用意し、この２つのコンピュータ
５０４，５０５に修正前プログラムＰ５０１と修正後プ
ログラムＰ’５０２を組み込み、これらのプログラムＰ
５０１およびＰ’５０２を第３のコンピュータ５０６の
同期制御部５０７の同期制御動作によって同期して実行
させ、一方のコンピュータ５０４に入力したテストデー
タＴ０に対する処理手順と他方のコンピュータ５０５に
入力したテストデータＴに対する処理手順とを第３のコ
ンピュータ５０６で比較し、その異同によって仕様変更
に対する修正が正しく行なわれているかどうかを検証
し、仕様変更に対する修正が正しく行なわれていなけれ
ば、修正不良個所メッセージ５０３を出力するように構
成することができる。

【００４４】このように、δ(Ｐ'，Ｔ）＝Φ(δ(Ｐ,ψ
(Ｔ)))∈Ｄ（Ｐ’）が成立しているか否かにより、仕様
変更に対する修正が正しく行なわれているかどうかを検
証することができる。

【００４５】また、修正の際に、修正すべきでない個所
を誤って変更したためにプログラムＰ’が劣化する可能
性がある。いま、Ｔ∈Ｄ（Ｐ）を任意にとると、この範
囲では修正前プログラムＰも修正後プログラムＰ’も同
じ動作を示すべきである。すなわち、δ(Ｐ'，Ｔ）＝Φ
(δ(Ｐ,Ｔ))が成立しなければならない。これは、図７
に示すような手順を実行することにより、修正後プログ
ラムＰ’が劣化しているかどうかを検証することができ
る。

【００４６】図７において、評価器２０２２は、プログ
ラムＰのカレント評価位置Ｌ１とカレント評価環境ＥＮ
Ｖ１およびプログラムＰ'のカレント評価位置Ｌ２とカ
レント評価環境ＥＮＶ２を保持している。評価器２０２
２は、プログラムＰにデータＴを環境ＥＮＶ１で与えた
ときの位置Ｌ１での実行結果と、プログラムＰ'にデー
タＴを環境ＥＮＶ２で与えたときの位置Ｌ２での実行結
果とをそれぞれ新しい環境と新しい評価位置の組（ＥＮ
Ｖ１，Ｌ１），（ＥＮＶ２，Ｌ２）として出力する（ス
テップ７０１）。このようにして新しい評価位置が決定
される。

【００４７】比較器２０２３は、Ｌ１とＬ２とを比較し
（ステップ７０２）、Ｌ１＝φ（Ｌ２）か否かを判定す
る。

【００４８】Ｌ１＝φ（Ｌ２）でない場合、Ｐ（Ｔ）と
Ｐ’(Ｔ)の遷移系列が異なっていることになるため、こ
の部分の分割単位Ｌ１，Ｌ２を性能劣化個所としてその
カレント環境の情報ＥＮＶ１，ＥＮＶ２と共にメッセー
ジ出力する（ステップ７０３）。しかし、Ｌ１＝φ（Ｌ
２）であった場合、Ｐ（Ｔ）とＰ’(Ｔ)の遷移系列は同
じであることになるため、正常個所として判定し、入力
器２０２１から次の分割単位の文を入力させる。以上の
動作をプログラムＰ，Ｐ’のファイル終了コードＥＯＦ
が見つかるまで（ステップ７０４）、繰り返し実行す
る。

【００４９】ここで、従来においても、プログラムを稼
働させて得た最終結果を比較する形での劣化防止テスト
は行われていたが、その方法では、結果には直接現れな
い処理途中の段階での動作の違いを検出できない。

【００５０】しかし、本発明の方法によれば、処理途中
の段階の動作の相違を検出しているため、高い検出能力
で劣化の有無を検出することができる。

【００５１】この劣化検出方法の拡張として、Φを通し
た動作の対応チェック時に付加的なチェックを行うこと
もできる。図８は、予め指定した変数集合{Ｖ１，Ｖ
２，...，Ｖｎ}の値の比較を考慮した場合の処理手順を
示すフローチャートである。

【００５２】図８において、評価器２０２２は、プログ
ラムＰのカレント評価位置Ｌ１とカレント評価環境ＥＮ
Ｖ１およびプログラムＰ'のカレント評価位置Ｌ２とカ
レント評価環境ＥＮＶ２を保持している。評価器２０２
２は、プログラムＰにデータＴ０を環境ＥＮＶ１で与え
たときの位置Ｌ１での実行結果と、プログラムＰ'にデ
ータφ（Ｔ）を環境ＥＮＶ２で与えたときの位置Ｌ２で
の実行結果とをそれぞれ新しい環境と新しい評価位置の
組（ＥＮＶ１，Ｌ１），（ＥＮＶ２，Ｌ２）として出力
する（ステップ８０１）。このようにして新しい評価位
置が決定される。

【００５３】比較器２０２３は、Ｌ１とＬ２とを比較し
（ステップ８０２）、Ｌ１＝φ（Ｌ２）か否かを判定す
る。

【００５４】Ｌ１＝φ（Ｌ２）でない場合、Ｐ（Ｔ）と
Ｐ’(ψ(Ｔ))の遷移系列が異なっていることになるた
め、この部分の分割単位Ｌ１，Ｌ２を性能劣化個所とし
てそのカレント環境の情報ＥＮＶ１，ＥＮＶ２と共にメ
ッセージ出力する（ステップ８０３）。しかし、Ｌ１＝
φ（Ｌ２）であった場合、Ｐ（Ｔ）とＰ’(ψ(Ｔ))の遷
移系列は同じであることになるため、正常個所として判
定する。

【００５５】次に、変数ｉ＝１とし（ステップ８０
４）、Ｌ１の位置における変数ＶｉとＬ２の位置におけ
る変数Ｖｉを評価し、その評価結果の「評価（Ｖｉ，Ｅ
ＮＶ１）」、「評価（Ｖｉ，ＥＮＶ２）」を比較器２０
２３に渡す。比較器２０２３は、「評価（Ｖｉ，ＥＮＶ
１）」と「評価（Ｖｉ，ＥＮＶ２）」とを比較し、両者
が等しいかどうかを、ｉ＞ｎになるまでｉを１ずつ更新
しながら判定し、等しくない場合は、そのＬ１の位置に
おける変数ＶｉとＬ２の位置における変数Ｖｉとが不一
致であることを示すメッセージ「Ｌ１，Ｌ２，ＥＮＶ
１，ＥＮＶ２」を出力する（ステップ８０５，８０６，
８０７，８０８）。すなわち、Ｌ１の位置における変数
集合Ｖ１〜ＶｎとＬ２の位置における変数集合Ｖ１〜Ｖ
ｎとが不一致であることを示すメッセージを出力する。

【００５６】ｉ＞ｎに達したならば、入力器２０２１か
ら次の分割単位の文を入力させる。以上の動作をプログ
ラムＰ，Ｐ’のファイル終了コードＥＯＦが見つかるま
で（ステップ８０９）、繰り返し実行する。

【００５７】このように、プログラムＰ，Ｐ’の処理途
中における変数集合の値が所定の関係を満たすかどうか
をも付加して調べることにより、実際に出力される変数
の値が変化していることによる修正後プログラムＰ’の
劣化を検出することができる。

【００５８】このような処理途中における変数集合の値
が所定の関係を満たすかどうかをも付加して調べる方法
は、劣化検出のみだけでなく、修正が正しく行なわれて
いるかどうかを検証する方法および修正必要個所を検出
する方法にも全く同様に適用することができる。

【００５９】また、変数集合の値を比較するのに代え
て、実行経路と順序の相違を検出し、修正前プログラム
Ｐの修正必要個所の検出、修正後プログラムＰ’の修正
の良否および性能劣化の検出を行なうようにしてもよ
い。また、実行経路と順序の相違に加え、各実行経路に
おける変数の値やループ回数などの値の相違を検出し、
修正前プログラムＰの修正必要個所の検出、修正後プロ
グラムＰ’の修正の良否および性能劣化の検出を行なう
ようにしてもよい。

【００６０】すなわち、仕様変更によって修正が必要と
なる修正前の修正対象プログラムに対し、変更前の仕様
に基づく第１のテストデータを与えてコンピュータに実
行させ、プログラム中のどの経路をどの順序で通ったか
を予め調べておき、仕様変更後の第２のテストデータを
与えて実行させたときの経路および順序の変化を比較す
ることによって仕様変更に対する修正対象プログラムの
修正必要箇所を特定するようにしてもよい。

【００６１】また、仕様変更によって修正が必要となる
修正前の修正対象プログラムに対し、変更前の仕様に基
づく第１のテストデータを与えてコンピュータに実行さ
せ、プログラム中のどの経路をどの順序で通ったかを予
め調べておき、同じ計算手順になるべき仕様変更後の第
２のテストデータを修正後のプログラムに与えて実行さ
せたときの経路および順序の変化を比較することによっ
て仕様変更に伴う修正後プログラムの修正の良否を検証
するようにしてもよい。

【００６２】また、仕様変更によって修正が必要となる
修正前の修正対象プログラムに対し、変更前の仕様に基
づく第１のテストデータを与えてコンピュータに実行さ
せ、プログラム中のどの経路をどの順序で通ったかを予
め調べておき、仕様変更の影響を受けない範囲に属する
第２のテストデータを修正後のプログラムに与えて実行
させたときの経路および順序の変化を比較することによ
って仕様変更に伴う修正後プログラムの劣化の有無を検
証するようにしてもよい。

【００６３】また、仕様変更によって修正が必要となる
修正前の修正対象プログラムに対し、変更前の仕様に基
づく第１のテストデータを与えてコンピュータに実行さ
せ、プログラム中のどの経路をどの順序で通ったかを予
め調べておき、仕様変更後の第２のテストデータを与え
て実行させたときの途中の変数の値、ループの回数等の
途中経過を示す値が仕様変更前のものから予め定めた限
界範囲以内に収まっているか否かを比較することによっ
て仕様変更に対する修正対象プログラムの修正必要箇所
を特定するようにしてもよい。

【００６４】また、仕様変更によって修正が必要となる
修正前の修正対象プログラムに対し、変更前の仕様に基
づく第１のテストデータを与えてコンピュータに実行さ
せ、プログラム中のどの経路をどの順序で通ったかを予
め調べておき、同じ計算手順になるべき仕様変更後の第
２のテストデータを修正後のプログラムに与えて実行さ
せたときの途中の変数の値、ループの回数等の途中経過
を示す値が仕様変更前のものから予め定めた限界範囲以
内に収まっているか否かを比較することによって仕様変
更に伴う修正後プログラムの修正の良否を検証するよう
にしてもよい。

【００６５】さらに、仕様変更によって修正が必要とな
る修正前の修正対象プログラムに対し、変更前の仕様に
基づく複数のテストデータを修正前のプログラムに与え
てコンピュータに実行させ、プログラム中のどの経路を
どの順序で通ったかを予め調べておき、仕様変更の影響
を受けない範囲に属する第２のテストデータを修正後の
プログラムに与えて実行させたときの途中の変数の値、
ループの回数等の途中経過を示す値が仕様変更前のもの
から予め定めた限界範囲以内に収まっているか否かを比
較することによって仕様変更に伴う修正後のプログラム
の劣化の有無を検証するようにしてもよい。

【００６６】このような実行途中経過の情報を用いるこ
とにより、修正後プログラムＰによる実行結果の全体が
既にわかっているので、指定した繰り返し制御文での繰
り返しの回数の比が２：１の範囲に収まっているかどう
かなど、緩いチェックや経路、実行順序全体を通した大
域的比較が可能となる。

【００６７】また、他のシステムへの呼出しが生じるよ
うな処理を含むプログラムについては、次のようにして
修正の良否および性能劣化を検出することができる。

【００６８】すなわち、仕様変更によって修正が必要と
なる修正前の修正対象プログラムに対し、変更前の仕様
に基づく第１のテストデータをに与えてコンピュータに
実行させ、データベースへの検索、他システムの呼出
し、ユーザ入力のいずれかを含む外部とのデータ入出力
の履歴を収集し、これらをスタブ化することで同じ計算
手順になるべき仕様変更後の第２のテストデータを修正
後のプログラムに与えて実行させたときの動作の比較を
検証用の環境で実現し、仕様変更に伴う修正後プログラ
ムの修正の良否を検証する。

【００６９】また、仕様変更によって修正が必要となる
修正前の修正対象プログラムに対し、変更前の仕様に基
づく第１のテストデータを与えてコンピュータに実行さ
せ、データベースへの検索、他システムの呼出し、ユー
ザ入力のいずれかを含む外部とのデータ入出力の履歴を
収集し、これらをスタブ化することで仕様変更の影響を
受けない範囲に属する第２のテストデータを修正後のプ
ログラムに与えて実行させたときの動作の比較を検証用
の環境で実現し、仕様変更に伴う修正後プログラムの劣
化の有無を検証する。

【００７０】このようにすることによって、他のシステ
ムへの呼出しが生じるような処理を含むプログラムにつ
いても修正の良否および性能劣化を確実に検出すること
ができる。

【００７１】ところで、解釈器２０２は、図９に示すよ
うに専用の「マクロ命令replace」９０１による指定に
よって修正後プログラムＰ，修正前プログラムＰ’の両
方または一方を解釈して実行するように構成され、検証
時には２つのプログラムの並列解釈を可能にし、修正後
プログラムＰ’の顧客納入時には修正後プログラムＰ’
のみの解釈を可能にしている。

【００７２】なお、以上説明した検証方法を直接適用し
ないものについては、外部仕様から、あるいは稼働シス
テムに実際データを流すことによりスタブを作成し、検
証システムではこのスタブを用いて検証を行うようにす
る。

【００７３】

【発明の効果】以上の説明から明らかなように本発明に
よれば、プログラム構成が複雑で、ドキュメントもない
内部構成が不明のプログラムについて、必要修正箇所を
効率的に特定することができる。

【００７４】また、新たな仕様通りに修正されたことを
効率的に検証し、さらに、修正前と同じ稼働条件ではも
ともとのシステムと同じ機能をそのまま使用できること
を効率的に検証することができる。

【００７５】さらに、修正後プログラムの性能が修正前
より劣化しているか否かを効率的に検証することができ
る。

【００７６】従って、「２０００年問題」に代表される
ように、稼動限界を越えて使用するプログラムにおい
て、その修正を必要とする個所を特定し、さらに修正し
たプログラムの良否、性能の劣化を検証する場合に適用
することにより、極めて有効な効果が得られる。

【図面の簡単な説明】

【図１】本発明の前提となる修正前プログラムと修正後
プログラムとの関係を示す図である。

【図２】本発明の基本的なシステム構成の例を示す図で
ある。

【図３】修正必要個所を特定する手順の一例を示すフロ
ーチャートである。

【図４】解釈器に内部構成の一例を示す図である。

【図５】修正後プログラムの修正の良否を検出するシス
テム構成の一例を示す図である。

【図６】修正後プログラムの修正の良否を検出する手順
の一例を示すフローチャートである。

【図７】修正後プログラムの性能の劣化を検出する手順
の一例を示すフローチャートである。

【図８】修正後プログラムの性能の劣化を変数集合の値
も含めて検出する手順の一例を示すフローチャートであ
る。

【図９】修正後プログラムに実装する専用のマクロ命令
の例を示す図である。

【符号の説明】

２０１…修正前プログラム、２０２…解釈器、２０３…
修正必要個所メッセージ、５０１…修正前プログラム、
５０２…修正後プログラム、５０３…修正不良個所メッ
セージ、５０４，５０５…コンピュータ、９０１…マク
ロ命令。

Claims

【特許請求の範囲】

【請求項１】仕様変更によって修正が必要となる１つ
の修正対象プログラムに対し、変更後の仕様条件を満た
す第１のテストデータと、この第１のテストデータの処
理結果と同一処理結果となる第２のテストデータを入力
し、これらの第１、第２のテストデータに対する処理を
前記修正対象プログラムの所定分割単位でコンピュータ
に実行させ、第１、第２のテストデータに対する処理手
順を比較し、その異同によって仕様変更に対する修正対
象プログラムの修正必要個所を所定分割単位で特定する
ことを特徴とするプログラム検証方法。
【請求項２】仕様変更によって修正が必要となる１つ
の修正対象プログラムに対し、変更後の仕様条件を満た
す第１のテストデータと、この第１のテストデータの処
理結果と同一処理結果となる第２のテストデータを入力
し、これらの第１、第２のテストデータに対する処理を
前記修正対象プログラムの所定分割単位でコンピュータ
に実行させ、指定した変数集合の指定した複数のアドレ
スでの値の集合の組を作成し、それぞれの値集合につい
て予め与えておいた等式を満たすか否かを調べることに
よって仕様変更に対する修正対象プログラムの修正必要
個所を所定分割単位で特定することを特徴とするプログ
ラム検証方法。
【請求項３】第１、第２のテストデータに対する修正
対象プログラムの処理を並列解釈可能な解釈手段を用い
て所定分割単位で並列解釈し、実行することを特徴とす
る請求項１または２記載のプログラム検証方法。
【請求項４】仕様変更前の第１のプログラムと仕様変
更後の第２のプログラムに対し、仕様変更の影響を受け
ない範囲に属する同一のデータを与えて所定分割単位で
コンピュータに実行させ、その処理手順を比較し、その
異同により仕様変更に伴う第２のプログラムの性能を検
証することを特徴とするプログラム検証方法。
【請求項５】仕様変更前の第１のプログラムと仕様変
更後の第２のプログラムに対し、仕様変更の影響を受け
ない範囲に属する同一のデータを与えて所定分割単位で
コンピュータに実行させ、指定した変数集合の指定した
複数のアドレスでの値の集合の組を作成し、それぞれの
値集合について予め与えておいた等式を満たすか否かを
調べることによって仕様変更に伴う第２のプログラムの
性能を検証することを特徴とするプログラム検証方法。
【請求項６】仕様変更前の第１のプログラムと仕様変
更後の第２のプログラムに対し、同じ計算手順となるべ
きテストデータを入力し、このテストデータに対する処
理を第１、第２のプログラムの所定分割単位でコンピュ
ータに実行させ、その処理手順を比較し、その異同によ
って仕様変更後の第２のプログラムの修正の良否を検証
することを特徴とするプログラム検証方法。
【請求項７】仕様変更前の第１のプログラムと仕様変
更後の第２のプログラムに対し、同じ計算手順となるべ
きテストデータを入力し、このテストデータに対する処
理を第１、第２のプログラムの所定分割単位でコンピュ
ータに実行させ、指定した変数集合の指定した複数のア
ドレスでの値の集合の組を作成し、それぞれの値集合に
ついて予め与えておいた等式を満たすか否かを調べるこ
とによって仕様変更後の第２のプログラムの修正の良否
を検証することを特徴とするプログラム検証方法。
【請求項８】第１、第２のプログラムの処理を並列解
釈可能な解釈手段を用いて所定分割単位で並列解釈し、
実行することを特徴とする請求項４ないし７記載のいず
れかのプログラム検証方法。
【請求項９】仕様変更によって修正が必要となる修正
前の修正対象プログラムに対し、変更前の仕様に基づく
第１のテストデータを与えてコンピュータに実行させ、
プログラム中のどの経路をどの順序で通ったかを予め調
べておき、仕様変更後の第２のテストデータを与えて実
行させたときの経路および順序の変化を比較することに
よって仕様変更に対する修正対象プログラムの修正必要
箇所を特定することを特徴とするプログラム検証方法。
【請求項１０】仕様変更によって修正が必要となる修
正前の修正対象プログラムに対し、変更前の仕様に基づ
く第１のテストデータを与えてコンピュータに実行さ
せ、プログラム中のどの経路をどの順序で通ったかを予
め調べておき、同じ計算手順になるべき仕様変更後の第
２のテストデータを修正後のプログラムに与えて実行さ
せたときの経路および順序の変化を比較することによっ
て仕様変更に伴う修正後プログラムの修正の良否を検証
することを特徴とするプログラム検証方法。
【請求項１１】仕様変更によって修正が必要となる修
正前の修正対象プログラムに対し、変更前の仕様に基づ
く第１のテストデータを与えてコンピュータに実行さ
せ、プログラム中のどの経路をどの順序で通ったかを予
め調べておき、仕様変更の影響を受けない範囲に属する
第２のテストデータを修正後のプログラムに与えて実行
させたときの経路および順序の変化を比較することによ
って仕様変更に伴う修正後プログラムの性能を検証する
ことを特徴とするプログラム検証方法。
【請求項１２】仕様変更によって修正が必要となる修
正前の修正対象プログラムに対し、変更前の仕様に基づ
く第１のテストデータを与えてコンピュータに実行さ
せ、プログラム中のどの経路をどの順序で通ったかを予
め調べておき、仕様変更後の第２のテストデータを与え
て実行させたときの途中の変数の値、ループの回数等の
途中経過を示す値が仕様変更前のものから予め定めた限
界範囲以内に収まっているか否かを比較することによっ
て仕様変更に対する修正対象プログラムの修正必要箇所
を特定することを特徴とするプログラム検証方法。
【請求項１３】仕様変更によって修正が必要となる修
正前の修正対象プログラムに対し、変更前の仕様に基づ
く第１のテストデータを与えてコンピュータに実行さ
せ、プログラム中のどの経路をどの順序で通ったかを予
め調べておき、同じ計算手順になるべき仕様変更後の第
２のテストデータを修正後のプログラムに与えて実行さ
せたときの途中の変数の値、ループの回数等の途中経過
を示す値が仕様変更前のものから予め定めた限界範囲以
内に収まっているか否かを比較することによって仕様変
更に伴う修正後プログラムの修正の良否を検証すること
を特徴とするプログラム検証方法。
【請求項１４】仕様変更によって修正が必要となる修
正前の修正対象プログラムに対し、変更前の仕様に基づ
く複数のテストデータを修正前のプログラムに与えてコ
ンピュータに実行させ、プログラム中のどの経路をどの
順序で通ったかを予め調べておき、仕様変更の影響を受
けない範囲に属する第２のテストデータを修正後のプロ
グラムに与えて実行させたときの途中の変数の値、ルー
プの回数等の途中経過を示す値が仕様変更前のものから
予め定めた限界範囲以内に収まっているか否かを比較す
ることによって仕様変更に伴う修正後のプログラムの性
能を検証することを特徴とするプログラム検証方法。
【請求項１５】仕様変更によって修正が必要となる修
正前の修正対象プログラムに対し、変更前の仕様に基づ
く第１のテストデータをに与えてコンピュータに実行さ
せ、データベースへの検索、他システムの呼出し、ユー
ザ入力のいずれかを含む外部とのデータ入出力の履歴を
収集し、これらをスタブ化することで同じ計算手順にな
るべき仕様変更後の第２のテストデータを修正後のプロ
グラムに与えて実行させたときの動作の比較を検証用の
環境で実現し、仕様変更に伴う修正後プログラムの修正
の良否を検証することを特徴とするプログラム検証方
法。
【請求項１６】仕様変更によって修正が必要となる修
正前の修正対象プログラムに対し、変更前の仕様に基づ
く第１のテストデータを与えてコンピュータに実行さ
せ、データベースへの検索、他システムの呼出し、ユー
ザ入力のいずれかを含む外部とのデータ入出力の履歴を
収集し、これらをスタブ化することで仕様変更の影響を
受けない範囲に属する第２のテストデータを修正後のプ
ログラムに与えて実行させたときの動作の比較を検証用
の環境で実現し、仕様変更に伴う修正後プログラムの性
能を検証することを特徴とするプログラム検証方法。
【請求項１７】前記解釈手段は、制御文による指定に
よって第１，第２のプログラムの両方または一方を解釈
して実行する手段を備えることを特徴とする請求項３ま
たは８記載のいずれかのプログラム検証方法。