JPS62216047A - リグレツシヨン防止用テストケ−スの決定方式 - Google Patents
リグレツシヨン防止用テストケ−スの決定方式Info
- Publication number
- JPS62216047A JPS62216047A JP61052111A JP5211186A JPS62216047A JP S62216047 A JPS62216047 A JP S62216047A JP 61052111 A JP61052111 A JP 61052111A JP 5211186 A JP5211186 A JP 5211186A JP S62216047 A JPS62216047 A JP S62216047A
- Authority
- JP
- Japan
- Prior art keywords
- test case
- statement
- test
- program
- sentence
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000012360 testing method Methods 0.000 title claims abstract description 91
- 230000002265 prevention Effects 0.000 claims abstract description 14
- 238000000034 method Methods 0.000 claims description 7
- 230000004048 modification Effects 0.000 claims description 6
- 238000012986 modification Methods 0.000 claims description 5
- 230000000694 effects Effects 0.000 abstract description 6
- 238000012937 correction Methods 0.000 abstract description 2
- 238000010586 diagram Methods 0.000 description 5
- 238000003780 insertion Methods 0.000 description 4
- 230000037431 insertion Effects 0.000 description 4
- 238000012217 deletion Methods 0.000 description 3
- 230000037430 deletion Effects 0.000 description 3
- 238000005259 measurement Methods 0.000 description 3
- 230000001186 cumulative effect Effects 0.000 description 2
- 238000009863 impact test Methods 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 238000009825 accumulation Methods 0.000 description 1
- 238000011179 visual inspection Methods 0.000 description 1
Landscapes
- Debugging And Monitoring (AREA)
Abstract
(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。
め要約のデータは記録されません。
Description
【発明の詳細な説明】
〔産業上の利用分野〕
本発明は、プログラム修正時に行なわれるリグレッショ
ン防止用テストのテストケース決定方式〔従来の技術〕 データ処理システムで仕様変更や障害が発生してソース
プログラムを修正した場合、確かにその仕様変更がなさ
れたかまた障害が修正されたかの確認テストの他に、他
の機能のレベルダウンが起きていないかテスト（リグレ
ッション防止用テスト）する必要がある。このテストは
、全テストケースを再実行して行なっているのが現状で
あるが、これは時間がか＼る。
ン防止用テストのテストケース決定方式〔従来の技術〕 データ処理システムで仕様変更や障害が発生してソース
プログラムを修正した場合、確かにその仕様変更がなさ
れたかまた障害が修正されたかの確認テストの他に、他
の機能のレベルダウンが起きていないかテスト（リグレ
ッション防止用テスト）する必要がある。このテストは
、全テストケースを再実行して行なっているのが現状で
あるが、これは時間がか＼る。
ところであるプログラムが走ったとき、そのブログラム
の各文（命令）がどの程度実行されたかを集計するテス
トカバレージ測定ツールなるものがある。第４図にその
概要を示す。
の各文（命令）がどの程度実行されたかを集計するテス
トカバレージ測定ツールなるものがある。第４図にその
概要を示す。
これを処理順に説明すると、■あるプログラムＢのテス
トケースＴ２を実行し、■実行したプログラム部分に関
する情報（５ＹＳＣＯｔｌＮＴ情報又はルート情報）を
得る。この情報は該プログラム＃の各命令のうち、どれ
を、何回通った（実行した）かというもの、又は各命令
単位ではなくその複数個からなるルート（ブランチして
いる場合、どちらの経路かということ）単位でどのルー
トを何回通ったかというものである。この文またはルー
ト（こ＼では単に文ともいう）はテストケースが変れば
変るものである。即ち実行されるプログラムは同じでも
テストケースが異なる（これで使用するデータが異なる
ことになる）と、ｉｆ文などでルートが分れ、実行され
る命令文が異なることになる。どの文を通ったかの情報
は、コンパイラの機能などを利用して取出すことができ
る。
トケースＴ２を実行し、■実行したプログラム部分に関
する情報（５ＹＳＣＯｔｌＮＴ情報又はルート情報）を
得る。この情報は該プログラム＃の各命令のうち、どれ
を、何回通った（実行した）かというもの、又は各命令
単位ではなくその複数個からなるルート（ブランチして
いる場合、どちらの経路かということ）単位でどのルー
トを何回通ったかというものである。この文またはルー
ト（こ＼では単に文ともいう）はテストケースが変れば
変るものである。即ち実行されるプログラムは同じでも
テストケースが異なる（これで使用するデータが異なる
ことになる）と、ｉｆ文などでルートが分れ、実行され
る命令文が異なることになる。どの文を通ったかの情報
は、コンパイラの機能などを利用して取出すことができ
る。
この情報は各テストケース毎に纏め、また各文単位でも
纏め（累計し）、このＩ！”Ｊ結果をカウントログファ
イルに記録する（■、■）。図示の例（Ｆｌ）ではプロ
グラムＢがテストケースＴｌ。
纏め（累計し）、このＩ！”Ｊ結果をカウントログファ
イルに記録する（■、■）。図示の例（Ｆｌ）ではプロ
グラムＢがテストケースＴｌ。
Ｔ２につき実行され、文番号１００，２００，３００．
４００の各命令文がテストケースＴ１では１８．１８，
４．４回実行され、テストケースＴ２では２，２．Ｏ，
０回実行され、従って累計は２０．２０，４．４である
としている。この累計結果は、当該テストによる各命令
文の実行状況（実行網羅率；カバレージ）を示す。また
このログファイルは、プログラムＡもテストケースＴＩ
Ｔ２．Ｔ３について実行され、各命令文の実行回数は図
示（Ｆ２）の如くであるとしている。カウントログファ
イルの内容はディスプレイに表示され又はプリンタによ
り用紙に打出され、目視に供される。
４００の各命令文がテストケースＴ１では１８．１８，
４．４回実行され、テストケースＴ２では２，２．Ｏ，
０回実行され、従って累計は２０．２０，４．４である
としている。この累計結果は、当該テストによる各命令
文の実行状況（実行網羅率；カバレージ）を示す。また
このログファイルは、プログラムＡもテストケースＴＩ
Ｔ２．Ｔ３について実行され、各命令文の実行回数は図
示（Ｆ２）の如くであるとしている。カウントログファ
イルの内容はディスプレイに表示され又はプリンタによ
り用紙に打出され、目視に供される。
なおプログラムの命令文数は数百〜数千など多数あるの
が普通で、ログデータはその各々についてとるのが普通
であるから、カウントログファイルの文番号数は図示の
４つではなく数百〜数千と多数ある。図ではこれを簡略
化して示している。
が普通で、ログデータはその各々についてとるのが普通
であるから、カウントログファイルの文番号数は図示の
４つではなく数百〜数千と多数ある。図ではこれを簡略
化して示している。
テストケースについても同様である。
このようなテストカバレージ測定ツールを利用すれば、
リグレッション防止用テストケースを絞り込み、必要な
だけのテストにして所要時間の短縮などを図ることがで
きる。即ちカウントログファイルのＦｌを見るとテスト
ケースＴ２では文番号３００と４００の命令文は実行し
ていない。従って命令文３００，４００を修正したとき
のリグレッション防止用テストでは、テストケースＴ２
は実行する必要がない。
リグレッション防止用テストケースを絞り込み、必要な
だけのテストにして所要時間の短縮などを図ることがで
きる。即ちカウントログファイルのＦｌを見るとテスト
ケースＴ２では文番号３００と４００の命令文は実行し
ていない。従って命令文３００，４００を修正したとき
のリグレッション防止用テストでは、テストケースＴ２
は実行する必要がない。
本発明はか＼る点に着目するもので、迅速、効率的なテ
ストを可能にしようとするものである。
ストを可能にしようとするものである。
本発明は、プログラム修正時に行なわれるリグレッショ
ン防止用テストのテストケース決定方式において、予め
プログラムを各テストケースにつき実行して、テストケ
ース別かつ文番号別に当該文の実行回数を記録しておき
、プログラムを修正したとき、当該文番号について前記
記録をチェックして、該修正の影響を受けるテストケー
スを検出し、これをリグレ・ツション防止用テストケー
スとすることを特徴とするものである。
ン防止用テストのテストケース決定方式において、予め
プログラムを各テストケースにつき実行して、テストケ
ース別かつ文番号別に当該文の実行回数を記録しておき
、プログラムを修正したとき、当該文番号について前記
記録をチェックして、該修正の影響を受けるテストケー
スを検出し、これをリグレ・ツション防止用テストケー
スとすることを特徴とするものである。
第１図に示すように本発明ではテストケース実行時にど
の文を通ったかという情報を採取し、これを蓄積してお
く。そしてソース修正が発生したとき、修正された文が
通過したルート上にあるテストケースを洗い出す。洗い
出されたテストケースが、実行ルートが変る可能性のあ
るテストケースである。第１図では、文番号２００を修
正した時、該当するのはテストケース１であり、従って
これをリグレッション防止のためのテストケースとする
。テストケース２は該当せず、従って実行不要とする。
の文を通ったかという情報を採取し、これを蓄積してお
く。そしてソース修正が発生したとき、修正された文が
通過したルート上にあるテストケースを洗い出す。洗い
出されたテストケースが、実行ルートが変る可能性のあ
るテストケースである。第１図では、文番号２００を修
正した時、該当するのはテストケース１であり、従って
これをリグレッション防止のためのテストケースとする
。テストケース２は該当せず、従って実行不要とする。
こうして実行を要するテストケースを絞り込むことがで
きる。
きる。
第４図でこれを行なうには、影響を凋査したい場所（文
、ブランチ、又はモジュール）を指定し■、指定された
場所が実行されているテストケースをカウントログファ
イルより求め、これを影響テストケース（修正の影響を
受けるテストケース、従ってリグレッション防止用テス
トケースとして採用すべきテストケース）として表示さ
せる■。
、ブランチ、又はモジュール）を指定し■、指定された
場所が実行されているテストケースをカウントログファ
イルより求め、これを影響テストケース（修正の影響を
受けるテストケース、従ってリグレッション防止用テス
トケースとして採用すべきテストケース）として表示さ
せる■。
必要部分のみ取出すと第３図のようになる。Ｔｌ。
Ｔ２．Ｔ３は各テストケースであり、これを実行すると
ＩＦ文などで各々の実行ルートが変り、必ずしも各ケー
スとも同一ではない。そこで各々の実行ルートを取出し
、実行ルートに名前（テストケース名）をつけて蓄積す
る。この蓄積（ファイル）に対して場所（文、ブランチ
など）を指定し、指定された場所を通っているテストケ
ースを探す。
ＩＦ文などで各々の実行ルートが変り、必ずしも各ケー
スとも同一ではない。そこで各々の実行ルートを取出し
、実行ルートに名前（テストケース名）をつけて蓄積す
る。この蓄積（ファイル）に対して場所（文、ブランチ
など）を指定し、指定された場所を通っているテストケ
ースを探す。
場所を■とすると、これを通っているテストケースは図
示例ではＴ１とＴ２であり、そこでこれらを影響テスト
ケースとして表示する。
示例ではＴ１とＴ２であり、そこでこれらを影響テスト
ケースとして表示する。
命令文の修正には更新の他に、新たな挿入、削除もある
。新たな挿入の場合には、当然、当該文番号はログデー
タになく、このま＼では全テストケースが影響なしテス
トケースになってしまうが、熱論これは不都合である。
。新たな挿入の場合には、当然、当該文番号はログデー
タになく、このま＼では全テストケースが影響なしテス
トケースになってしまうが、熱論これは不都合である。
この場合は挿入された文の番号の前後いずれか一方又は
両方の文番号の実行回数が１以上か否かをチェックし、
イエスであれば当該テストケースは影響テストケースと
する。また、挿入文番号の前、後の文番号に対応する文
が段落名、ラベルなどの非実行文（この場合には、実行
文と区別するために実行回数にはマイナス値を設定する
。）のときは、更に１つ前又は後の文番号で判定する。
両方の文番号の実行回数が１以上か否かをチェックし、
イエスであれば当該テストケースは影響テストケースと
する。また、挿入文番号の前、後の文番号に対応する文
が段落名、ラベルなどの非実行文（この場合には、実行
文と区別するために実行回数にはマイナス値を設定する
。）のときは、更に１つ前又は後の文番号で判定する。
上記の１つ前又は後の文番号も非実行文のことがあるが
、この場合は更に１つ進める。判定対象の文番号の実行
回数が０のときは影響なしテストケースとする。
、この場合は更に１つ進める。判定対象の文番号の実行
回数が０のときは影響なしテストケースとする。
削除は、更新と同じで、削除された文番号の実行回数が
１以上のテストケースは影響ありテストケース、０なら
影響なしテストケースとする。当該文番号が非実行文の
ときは、上記挿入と同様な判定処理を行なう。
１以上のテストケースは影響ありテストケース、０なら
影響なしテストケースとする。当該文番号が非実行文の
ときは、上記挿入と同様な判定処理を行なう。
第２図の例について説明すると、（ａｌは文番号２１）
０を挿入した例、（ｂｌは文番号３０００などを削除し
た例である。＋ａ）では文番号２１）０の前、後の文番
号２１００．２２００をチェックし、これらの文番号の
実行回数値は−１（非実行文）であるからその次をチェ
ックし、文番号２０００の実行回数１０、文番号２３０
０の実行回数Ｏを得る。一方でもＯでなければ影響あり
と考えられるので、このテストケースは影響ありテスト
ケースとみなす。
０を挿入した例、（ｂｌは文番号３０００などを削除し
た例である。＋ａ）では文番号２１）０の前、後の文番
号２１００．２２００をチェックし、これらの文番号の
実行回数値は−１（非実行文）であるからその次をチェ
ックし、文番号２０００の実行回数１０、文番号２３０
０の実行回数Ｏを得る。一方でもＯでなければ影響あり
と考えられるので、このテストケースは影響ありテスト
ケースとみなす。
（ｂｌでは、文番号３０００を削除した場合は、この実
行回数は０であるからこのテストケースは影響なしテス
トケースになる。文番号３１００を削除すると、この実
行回数は−１であるからこの前後をチェックし、これら
は共にＯであるから、この場合も影響なしテストケース
になる。文番号３２００を削除した場合も同様であるが
、文番号３３００を削除すると、この実行回数は−１、
従って前後をチェックして０．１０を得、共にＯではな
いからこの場合は影響ありテストケースとなる。
行回数は０であるからこのテストケースは影響なしテス
トケースになる。文番号３１００を削除すると、この実
行回数は−１であるからこの前後をチェックし、これら
は共にＯであるから、この場合も影響なしテストケース
になる。文番号３２００を削除した場合も同様であるが
、文番号３３００を削除すると、この実行回数は−１、
従って前後をチェックして０．１０を得、共にＯではな
いからこの場合は影響ありテストケースとなる。
文番号３４００を削除した場合も影響ありテストケース
となる。
となる。
第５図はカウントログファイルの論理構造例の一部を示
す。（ａｌは文番号レコード、（ｂ）は合計レコード、
（Ｃ１はテストケースレコードである。
す。（ａｌは文番号レコード、（ｂ）は合計レコード、
（Ｃ１はテストケースレコードである。
以上説明したように本発明によれば効率よく従って迅速
にリグレッション防止用テストを行なうことができ、プ
ログラム修正時に通用して甚だ有効である。
にリグレッション防止用テストを行なうことができ、プ
ログラム修正時に通用して甚だ有効である。
第１図は本発明の説明図、第２図は挿入、削除の場合の
判定要領の説明図、第３図はや一詳細な本発明の説明図
、第４図は測定ツールの説明図、第５図はその論理構造
の説明図である。 図面でＴＩ、Ｔ２．・・・・・・はテストケース、Ｆ１
〜Ｆ２はログファイル内の各記録である。
判定要領の説明図、第３図はや一詳細な本発明の説明図
、第４図は測定ツールの説明図、第５図はその論理構造
の説明図である。 図面でＴＩ、Ｔ２．・・・・・・はテストケース、Ｆ１
〜Ｆ２はログファイル内の各記録である。
Claims (2)
- （１）プログラム修正時に行なわれるリグレッション防
止用テストのテストケース決定方式において、予めプロ
グラムを各テストケースにつき実行して、テストケース
別かつ文番号別に当該文の実行回数を記録しておき、 プログラムを修正したとき、当該文番号について前記記
録をチェックして、該修正の影響を受けるテストケース
を検出し、これをリグレッション防止用テストケースと
することを特徴としたリグレッション防止用テストケー
スの決定方式。 - （２）プログラム修正の影響を受けるテストケースを、
命令文を更新又は削除したときは、該更新又は削除した
文番号の実行回数が１以上のテストケースを影響ありテ
ストケースとし、 命令文を新たに挿入したときは、該挿入文番号の前、後
の文番号をチェックし、いずれか一方又は両方の文番号
が１以上であれば影響ありテストケースとすることを特
徴とする特許請求の範囲第１項記載のリグレッション防
止用テストケースの決定方式。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP61052111A JPH081609B2 (ja) | 1986-03-10 | 1986-03-10 | リグレッション防止用テストケースの決定方式 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP61052111A JPH081609B2 (ja) | 1986-03-10 | 1986-03-10 | リグレッション防止用テストケースの決定方式 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPS62216047A true JPS62216047A (ja) | 1987-09-22 |
| JPH081609B2 JPH081609B2 (ja) | 1996-01-10 |
Family
ID=12905751
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP61052111A Expired - Fee Related JPH081609B2 (ja) | 1986-03-10 | 1986-03-10 | リグレッション防止用テストケースの決定方式 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JPH081609B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0635754A (ja) * | 1992-07-13 | 1994-02-10 | Hitachi Ltd | 再テスト方法およびそのための装置 |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4939973B2 (ja) * | 2007-02-22 | 2012-05-30 | 富士通株式会社 | 試験制御装置、試験制御方法及び試験制御プログラム |
| JP5468644B2 (ja) * | 2012-06-15 | 2014-04-09 | 日本発條株式会社 | スタビリンク |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS55163697A (en) * | 1979-06-05 | 1980-12-19 | Mitsubishi Electric Corp | Memory device |
| JPS5852759A (ja) * | 1981-09-24 | 1983-03-29 | Fujitsu Ltd | パス情報の抽出方式 |
-
1986
- 1986-03-10 JP JP61052111A patent/JPH081609B2/ja not_active Expired - Fee Related
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS55163697A (en) * | 1979-06-05 | 1980-12-19 | Mitsubishi Electric Corp | Memory device |
| JPS5852759A (ja) * | 1981-09-24 | 1983-03-29 | Fujitsu Ltd | パス情報の抽出方式 |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0635754A (ja) * | 1992-07-13 | 1994-02-10 | Hitachi Ltd | 再テスト方法およびそのための装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| JPH081609B2 (ja) | 1996-01-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5987250A (en) | Transparent instrumentation for computer program behavior analysis | |
| US9098632B2 (en) | Computer program testing | |
| US8214805B2 (en) | Method and system for graphical user interface testing | |
| Göde et al. | Studying clone evolution using incremental clone detection | |
| McIntosh et al. | Mining co-change information to understand when build changes are necessary | |
| US20030093716A1 (en) | Method and apparatus for collecting persistent coverage data across software versions | |
| US7401322B1 (en) | Software debugging tool | |
| US20040078693A1 (en) | Software testing | |
| US20160321586A1 (en) | Selecting tests for execution on a software product | |
| Biagiola et al. | Web test dependency detection | |
| Mondai et al. | Micro-clones in evolving software | |
| US20070162522A1 (en) | Evidentiary enrichment of traceability links between software specification requirements | |
| JP4939973B2 (ja) | 試験制御装置、試験制御方法及び試験制御プログラム | |
| US20030088810A1 (en) | Methods and apparatus for determining software component sizes associated with errors | |
| JP2816666B2 (ja) | バグ自動検出装置 | |
| EP3113016A1 (en) | Tracing dependencies between development artifacts in a development project | |
| CN114139923A (zh) | 任务关联性分析方法、装置及计算机可读存储介质 | |
| JP2005228326A (ja) | データ処理システム、アプリケーションプログラムのカスタマイズパラメータを表示する方法およびコンピュータプログラム製品 | |
| JPS62216047A (ja) | リグレツシヨン防止用テストケ−スの決定方式 | |
| Toth et al. | Using version control history to follow the changes of source code elements | |
| JPH11224186A (ja) | ソフトウェア解析装置及びソフトウェア解析方法 | |
| JP5741265B2 (ja) | プログラム改善支援システム | |
| US20040019885A1 (en) | Performance monitoring | |
| JPH0926897A (ja) | プログラム解析装置及びプログラム解析方法 | |
| JP2658065B2 (ja) | プログラムの評価方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| LAPS | Cancellation because of no payment of annual fees |