JP4874277B2 - Automated test execution system - Google Patents
Automated test execution system Download PDFInfo
- Publication number
- JP4874277B2 JP4874277B2 JP2008062107A JP2008062107A JP4874277B2 JP 4874277 B2 JP4874277 B2 JP 4874277B2 JP 2008062107 A JP2008062107 A JP 2008062107A JP 2008062107 A JP2008062107 A JP 2008062107A JP 4874277 B2 JP4874277 B2 JP 4874277B2
- Authority
- JP
- Japan
- Prior art keywords
- test
- test data
- source code
- trace information
- execution
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
Description
本発明は、テスト対象のソースコードを解析し、プログラムに対して様々な値を投入して対象のプログラムをテストするシステムに関するものである。 The present invention relates to a system for analyzing a source code to be tested and inputting various values into the program to test the target program.
ソフトウェアの品質を確保するためには、対象のソフトウェアを十分にテストすることが重要である。そのためのテスト手法のひとつとして、ソフトウェアを構成するモジュール単位でテストを行う単体テストがある。単体テストは、まずプログラムの開発者がテストデータを作成し、そのテストデータを対象のプログラムに投入してテストを行う、という手順が一般的である。 In order to ensure the quality of software, it is important to thoroughly test the target software. One of the test methods for that purpose is unit testing in which software is tested in units of modules. The unit test generally involves a procedure in which a program developer first creates test data, and inputs the test data into a target program for testing.
しかし、従来のテスト方法には、開発者が想定したテストデータの範囲内でしかテストが行われないという問題がある。
例えば、図１に示すソースコードにおいて、divideメソッドは、与えられえた二つの引数を用いて除算を行うメソッドである（なお本明細書では、説明のための例としてJava(登録商標)言語によるソースコードを用いる）。このメソッドをテストする場合、ある開発者は以下のような引数の組み合わせをテストデータとして考案したとする。
(1) x = 4, y = 2
(2) x = 10, y = 5
この開発者は上記テストデータを用いてテストを行えば十分品質は保てると判断したのであろうが、これでは十分であるとは言えない。たとえば引数x, yの値が100以上であった場合に、3、4行目及び7、8行目が正しく実行されるかテストする必要がある。また、y = 0であった場合、多くの計算機では10行目で0による除算エラーが発生するため、この点についてもテストする必要がある。またdivideメソッドの引数がint型である以上、マイナスの値や、極端に大きな値が引数として与えられた場合の挙動についてもテストしておいたほうがよいかもしれない。このようにソフトウェアのテストにおいて、投入されるテストデータは開発者のスキルや考え方に大いに依存しており、未熟な開発者がテストを行った場合、テストケースに漏れが発生してしまう可能性がある。
However, the conventional test method has a problem that the test is performed only within the range of test data assumed by the developer.
For example, in the source code shown in FIG. 1, the divide method is a method for performing division using two given arguments (in this specification, as a description example, a source in Java (registered trademark) language). Use code). When testing this method, a developer devised the following combination of arguments as test data:
(1) x = 4, y = 2
(2) x = 10, y = 5
The developer may have determined that the quality can be maintained by testing with the above test data, but this is not sufficient. For example, when the values of the arguments x and y are 100 or more, it is necessary to test whether the third, fourth, seventh and eighth lines are executed correctly. Also, if y = 0, many computers generate a division-by-zero error on the 10th line, so this point also needs to be tested. Also, since the argument of the divide method is an int type, you may want to test the behavior when a negative value or an extremely large value is given as an argument. In this way, in software testing, the test data that is input largely depends on the skill and way of thinking of the developer, and if an inexperienced developer performs the test, there is a possibility that the test case may leak. is there.
この問題を解決するために、想定されるあらゆるテストデータをプログラムに投入してテストを行う、自動テスト実行システムがある。自動テスト実行システムは、まずテスト対象のソースコードを解析し、メソッド引数の個数や型の情報を取得する。図１の例では「divideメソッドはint型の引数を2つもつ」という情報を得られる。次に取得した引数の情報をもとに、ありとあらゆるテストデータを生成する。引数がint型の場合は、int型の最小値、最大値、ゼロなど、あらゆるint型の値をテストデータとして生成する。次に生成したテストデータを次々とテスト対象プログラムに投入し、その返値などをテスト結果として記録する。開発者はこの記録を目視で確認し、プログラムが想定どおりに動作しているかどうかを判断する。この自動テスト実行システムによって、開発者が思いもつかなかったようなテストデータを用いたテストを実施できるようになる。これにより、テストケースの漏れを防ぐことができるため、より品質の高いソフトウェアを開発することが可能となる。 In order to solve this problem, there is an automatic test execution system that performs tests by inputting all possible test data into a program. The automated test execution system first analyzes the source code to be tested and obtains information on the number and type of method arguments. In the example of FIG. 1, the information “divide method has two int type arguments” can be obtained. Next, all kinds of test data are generated based on the obtained argument information. If the argument is an int type, any int type value such as an int minimum value, maximum value, or zero is generated as test data. Next, the generated test data is input to the test target program one after another, and the return value is recorded as the test result. Developers visually check this record to determine if the program is working as expected. This automatic test execution system makes it possible to conduct tests using test data that the developer never thought of. As a result, leakage of test cases can be prevented, so that higher quality software can be developed.
特許文献１には、ソースコードの分岐行を検索し、各分岐行毎に分岐条件を抽出し、分岐条件の正否両条件を取り出し、プログラム入力変数のみで表した式に分解してテスト項目を抽出し出力するテスト項目作成装置が開示されている。
しかしながら、従来の自動テスト実行システムには、開発者が目視でテスト結果を確認する必要があるため確認作業に多大な作業量を必要とする、という問題がある。さらに自動テスト実行システムは、ありとあらゆるテストデータを投入するため、同じような内容のテストを行っている場合がある。たとえば自動テスト実行システムが以下のようなテストデータを生成したとする。
(1) x = 4, y = 2
(2) x = 10, y = 5
この場合、どちらのテストデータを用いたとしても、divideメソッドの2行目、6行目、10行目及び11行目が実行される。処理の流れはいずれのテストデータを用いても同一であり、10行目で行っている処理が4÷2か、10÷5か、の違いしかない。これは実質的には重複したテストを行っていることになる。
However, the conventional automatic test execution system has a problem that a large amount of work is required for the confirmation work because the developer needs to visually confirm the test result. Furthermore, since the automatic test execution system inputs all kinds of test data, there are cases where the same contents are tested. For example, assume that an automatic test execution system generates the following test data.
(1) x = 4, y = 2
(2) x = 10, y = 5
In this case, regardless of which test data is used, the second, sixth, tenth and eleventh lines of the divide method are executed. The flow of processing is the same regardless of which test data is used, and the only difference is whether the processing performed on the 10th line is 4 ÷ 2 or 10 ÷ 5. This is essentially a duplicate test.
このような重複したテストデータがあった場合、(1)か(2)のいずれかのテストのみ実施しても問題ないはずである。しかし自動テスト実行システムは、重複したいずれのテストについても実施する。これにより本来実施する必要のなかったテストまで実施していることになり、その結果、テスト結果の確認作業の無駄な工数が増大し、また大量のテスト結果を目視で確認するため、人為的なミスも発生しやすくなるという問題がある。 If there is such duplicate test data, there should be no problem if only the test (1) or (2) is performed. However, the automated test execution system performs any duplicate tests. As a result, tests that were originally not necessary to be performed are performed. As a result, the number of useless man-hours for confirming the test results is increased, and a large amount of test results are visually confirmed. There is a problem that mistakes are likely to occur.
本発明の目的は、自動テスト実行システムが実行した自動テスト結果において重複を生じさせず、必要最小限のテスト結果のみを確認するようにし、より効率的にテストを実施するための方法を提供することにある。 SUMMARY OF THE INVENTION An object of the present invention is to provide a method for performing a test more efficiently by checking only a minimum necessary test result without causing duplication in an automatic test result executed by an automatic test execution system. There is.
上記目的を達成するために本発明の自動テスト実行システムは、テスト対象ソースコードを読み込み、そのテスト対象ソースコード中に定義されているメソッドとメソッド引数の型を解析して空のテストデータ表を作成し、同時にメソッドに定義されている条件式を解析して境界値表を作成するソースコード解析部と、代表テストデータ表及び前記境界値表を読み込み、すべてのテストデータを組み合わせて前記空のテストデータ表に登録するテストデータ生成部と、前記テスト対象ソースコードに対し、処理の流れを示すトレース情報を取得するための機能を埋め込み該テスト対象ソースコードを修正することにより、修正済みテスト対象ソースコードを作成するトレース機能埋込部と、前記テストデータを登録したテストデータ表を読み込み、各テストデータを使用して前記修正済みテスト対象ソースコードのメソッドを実行し、それぞれの実行を各テストケースとして、その返値または発生した例外をテスト実行結果表に登録すると同時にそのトレース情報をトレース情報表に登録するテスト実行部と、前記トレース情報表と前記テスト実行結果表とを結合し、結合した表中におけるトレース情報の重複したテストケースを削除するテスト結果分析部と、重複したテストケースを削除された前記テスト実行結果表を、表示装置に表示するテスト結果表示部と、を備えたことを特徴とする。 In order to achieve the above object, the automatic test execution system of the present invention reads the test target source code, analyzes the method and method argument types defined in the test target source code, and creates an empty test data table. A source code analysis unit that creates a boundary value table by simultaneously analyzing the conditional expression defined in the method, reading the representative test data table and the boundary value table, combining all the test data, and A test data generator to be registered in a test data table and a function for acquiring trace information indicating the flow of processing are embedded in the test target source code, and the test target source code is corrected to correct the test target Read the trace function embedding part that creates the source code and the test data table in which the test data is registered. The test data is used to execute the method of the modified test target source code, each execution is set as each test case, and the return value or the exception that occurred is registered in the test execution result table and the trace information at the same time. A test execution unit for registering in the trace information table, a test result analysis unit for combining the trace information table and the test execution result table, and deleting duplicate test cases in the trace information in the combined table, And a test result display unit that displays the test execution result table from which the test cases have been deleted on a display device.
本発明の自動テスト実行システムによれば、次のような効果がある。
（１）重複したテストケースがテスト実行結果から除去されるため、開発者がテスト結果を確認する作業を最小限に抑えることができ、その分の工数が削減できる。
（２）開発者がテスト結果を目視で確認する作業を最小限に抑えることができるため、人 為的な確認作業ミスが発生しにくく、ソフトウェアの品質向上につながる。
よって、本発明により、効率的な自動テスト実行システムが実現された。
The automatic test execution system of the present invention has the following effects.
(1) Since duplicate test cases are removed from the test execution result, the work of the developer confirming the test result can be minimized, and the man-hours can be reduced accordingly.
(2) Since the developer can minimize the work of visually checking the test results, it is difficult for human error to be confirmed and the software quality is improved.
Therefore, an efficient automatic test execution system is realized by the present invention.
以下、実施例を示した図面を参照して本発明の実施の形態を説明する。
図２は、本発明の自動テスト実行システムの一実施例を示すシステム概要構成図である。本システムは、自動テスト実行の基本処理を行うための自動テスト実行部２１と、自動テスト実行の効率化処理を行うための自動テスト最適化部２２とから構成される。
Hereinafter, embodiments of the present invention will be described with reference to the drawings showing examples.
FIG. 2 is a system outline block diagram showing an embodiment of the automatic test execution system of the present invention. This system includes an automatic
自動テスト実行部２１では、まずテスト対象ソースコード２３を読み取り、ソースコード解析部２４に与える。ソースコード解析部２４は、境界値表２５を生成する。次にテストデータ生成部２６が、境界値表２５と、あらかじめ用意してある代表テストデータ表２７を読み込み、テストデータ表２８を生成する。自動テスト最適化部２２では、テスト対象ソースコード２３をトレース機能埋込部２９に与える。トレース機能埋込部２９は、修正済みテスト対象ソースコード２１０を生成する。そしてテスト実行部２１１はテストデータ表２８と修正済みテスト対象ソースコード２１０を読み込み、テスト対象メソッドを実行し、テスト実行結果表２１２とトレース情報ファイル２１７を出力する。さらに出力したトレース情報ファイル２１７の内容をトレース情報表２１３に登録する。ここでテスト結果分析部２１４が、トレース情報表２１３を読み込み、分析した結果を元にテスト実行結果表２１２を書き換える。最後にテスト結果表示部２１５がテスト実行結果表２１２を読み込み、その内容を表示装置２１６に表示する。
The automatic
次に各構成要素の詳細を、手順を追って説明する。
ここでは、例として図１のソースコードを自動テストする場合について考える。このソースコードには除算を行うdivideメソッドが定義されている。このメソッドを自動テストするには、まずソースコードを、図２のソースコード解析部２４に与える。
Next, details of each component will be described step by step.
Here, as an example, consider the case of automatically testing the source code of FIG. This source code defines a divide method that performs division. In order to automatically test this method, first, the source code is given to the source
図３はソースコード解析部の処理の流れを示したものである。
ステップ３１：まず、ソースコード解析部は、境界値表とテストデータ表を初期化する。境界値表とはテスト対象のメソッド内の条件分岐処理の境界値を登録するための表である。またテストデータ表とは、自動テストを実行する際のテストデータとなる値を登録するための表である。ここでは、これらの各表を保存する計算機上のメモリ領域を計算機のメモリ上に確保している。
FIG. 3 shows the processing flow of the source code analysis unit.
Step 31: First, the source code analysis unit initializes the boundary value table and the test data table. The boundary value table is a table for registering boundary values for conditional branch processing in a test target method. The test data table is a table for registering values to be test data when executing an automatic test. Here, a memory area on the computer for storing these tables is secured in the memory of the computer.
ステップ３２：次に、テスト対象のソースコードを読み込む。ソースコードには１つ以上のメソッドの定義が記述されている。
ステップ３３：次に、ソースコード解析部はソースコードを一行ずつ読み込み、各メソッドの定義内容を１つずつ取得する。ここで「メソッド定義」とは、図１の符号１１の範囲の文字列のことを示す。なお、メソッド定義は「<型> <メソッド名>(<メソッド引数のリスト>){ <メソッド本体> }」という構文で記述されているものとする。
ステップ３４：次に、取得したメソッド定義を解析し、メソッド引数の定義を１つずつ取得する。なお、メソッド引数のリストは、「<型名> <一時変数名>, <型名> <一時変数名>, ．．」という形式で列挙されており、「<型名> <一時変数名>」の各々がメソッド引数の定義である。
Step 32: Next, the source code to be tested is read. The source code describes one or more method definitions.
Step 33: Next, the source code analysis unit reads the source code line by line, and acquires the definition contents of each method one by one. Here, “method definition” indicates a character string in the range of 11 in FIG. It is assumed that the method definition is described in the syntax “<type><methodname>(<method argument list>) {<method body>}”.
Step 34: Next, the acquired method definitions are analyzed, and method argument definitions are acquired one by one. The method argument list is enumerated in the format of "<type name><temporary variable name>, <type name><temporary variable name>, ..." and "<type name><temporary variable name>"Is a method argument definition.
ステップ３５：この時点で、メソッド名、メソッド引数の型名、メソッド引数の一時変数名がわかっているので、これらの情報を境界値表、テストデータ表に登録する。テストデータ表の形式は、図５に示すとおりである。符号５１、５２、５３の箇所にそれぞれ、メソッド名、メソッド引数の一時変数名、メソッド引数の型名、を埋め込むことで登録を行う。また、境界値表の形式は、図６に示すとおりであり、こちらも同様に図６の符号６１、６２、６３の箇所にそれぞれ、メソッド名、メソッド引数の一時変数名、メソッド引数の型名、を埋め込むことで登録を行う。
Step 35: At this point, since the method name, method argument type name, and method argument temporary variable name are known, these pieces of information are registered in the boundary value table and test data table. The format of the test data table is as shown in FIG. Registration is performed by embedding the method name, the temporary variable name of the method argument, and the type name of the method argument in the portions denoted by
ステップ３６：次にステップ３４で取得したメソッド引数の定義について、このメソッド引数の一時変数がメソッド定義の中で参照されている箇所を探し、その箇所を１つずつ取得する。たとえば、図１のソースコードにおいて、メソッド引数x（符号１２）は、2行目、4行目、１０行目で参照されているので、これらの行をひとつずつ取得する。 Step 36: Next, with respect to the method argument definition acquired in step 34, a part where the temporary variable of this method argument is referred to in the method definition is searched, and the part is acquired one by one. For example, in the source code of FIG. 1, since the method argument x (reference numeral 12) is referenced in the second, fourth, and tenth lines, these lines are acquired one by one.
ステップ３７：次にステップ３６で取得した参照箇所行と、ステップ３４で取得したメソッド引数の一時変数名を、境界表登録処理に与え、実行する。境界表登録処理の詳細は図４で説明する。
Step 37: Next, the reference location line acquired in
以上の処理を繰り返し、すべてのテスト対象メソッドについて、境界値表とテストデータ表の各項目を埋める。この時点でテストデータ表は、図５のように、空のテストデータ表となっている。 The above processing is repeated to fill in the items in the boundary value table and the test data table for all the test target methods. At this time, the test data table is an empty test data table as shown in FIG.
次に図４について説明する。境界値登録処理は、メソッド引数の一時変数名と、その変数が参照されている箇所の文字列を与えて実行する。図４は境界値登録処理の詳細について示したものである。
ステップ４１：まずメソッド引数の参照箇所が比較式であるかどうかを判定する。比較式とはif文やswitch文などのことである。なお、厳密に境界値の解析を行う場合は、比較式だけではなくwhileなどの制御文についても判定する必要があるが、本実施例では説明を簡潔にするためif文のみに限定する。
ステップ４２：参照箇所が比較式であった場合、比較している値が単純なint型の値であるかどうかを判定する。例えば、図１の２行目は「if(100 < x)」という条件文が記述されているが、ここで比較値は”100”であり、これは単純なint型の値である。なお、厳密に境界値の解析を行う場合は、比較値が単純なint値の場合だけでなく、たとえばdouble, float, String型であった場合や、比較値が変数の参照である場合についても考慮する必要がある。しかし本実施例では説明を簡潔にするためint値のみに限定する。
ステップ４３、４４、４５：比較値がint値であった場合、その比較値、比較値から1を引いた値、比較値に1を加えた値、を境界値表に登録する。たとえば図１の２行目を解析する場合、比較値は100であるため、図６の符号６４の箇所に100を、符号６５の箇所に99を、符号６６の箇所に101を、それぞれ登録する。
Next, FIG. 4 will be described. The boundary value registration process is executed by giving a temporary variable name of a method argument and a character string at a location where the variable is referenced. FIG. 4 shows details of the boundary value registration process.
Step 41: First, it is determined whether or not the reference portion of the method argument is a comparison expression. A comparison expression is an if statement or a switch statement. When strictly analyzing the boundary value, it is necessary to determine not only the comparison expression but also a control statement such as while. However, in this embodiment, only the if statement is used for the sake of simplicity.
Step 42: If the reference location is a comparison expression, it is determined whether or not the value being compared is a simple int type value. For example, the second line in FIG. 1 describes a conditional statement “if (100 <x)”, where the comparison value is “100”, which is a simple int type value. When strictly analyzing boundary values, not only when the comparison value is a simple int value, but also when the comparison value is, for example, a double, float, or String type, or when the comparison value is a variable reference. It is necessary to consider. However, in this embodiment, only the int value is limited to simplify the description.
図３及び図４の処理をすべてのメソッドに対して実行すると、最終的に図６に示すような境界値表が完成する。 When the processes of FIGS. 3 and 4 are executed for all the methods, a boundary value table as shown in FIG. 6 is finally completed.
ここで、代表テストデータ表について説明する。代表テストデータ表とは、自動テスト実行システムが保持するテストデータの集合であり、よく使用されるテストデータを、代表テストデータとして保持しているものである。図８は代表テストデータ表の例を示したものである。代表テストデータ表は、型列８１とテストデータ列８２で構成されたデータの集合である。図８ではたとえば、int型のテストデータの代表値として、0, -1 , 1, Integer.MAX_VALUE(int型の最大値)、Integer.MIN_VALUE(int型の最小値)、など、int型の引数をもつメソッドをテストするときに、頻繁に使用されるテストデータが登録されている。int型のテストデータの他にも、double, float, String型、さらにユーザが独自に定義した型の代表テストデータも登録されている。代表テストデータ表自体は、自動テスト実行システムが提供するデータ表であり、このデータ表の作成方法等については周知であり、本発明の範囲外となるため、ここでは言及しない。
Here, the representative test data table will be described. The representative test data table is a set of test data held by the automatic test execution system, and holds frequently used test data as representative test data. FIG. 8 shows an example of a representative test data table. The representative test data table is a set of data composed of a
次に図７について説明する。図７は、図２のテストデータ生成部２６の詳細な処理について示したものである。テストデータ生成部２６は、境界値表２５と代表テストデータ表２７を読み込み、テストデータ表２８を生成する。
Next, FIG. 7 will be described. FIG. 7 shows the detailed processing of the test
ステップ７１：まず、テストデータ生成部は、代表テストデータ表、境界値表を読み込む。
ステップ７２：次に、境界値表からメソッド行をひとつずつ取得する。ここで「境界値のメソッド行」とは図６の符号６７に示す範囲のデータのことである。符号６７の範囲には、図1のソースコードのdivideメソッドについての境界値情報が格納されている。
ステップ７３：次に、ステップ７２で取得した行の境界値情報と、代表テストデータ表のテストデータをすべて組み合わせて、テストデータ表に書き込む。組み合わせ処理はメソッド引数ごとに行う。例えば、図６及び図８において、divideメソッドの引数xに対するテストデータの組み合わせを行う際は、まず、図６の境界値表から引数xの境界値（符号６４、６５、６６）をすべて取得する。また、引数xはint型の値なので、図８の代表テストデータ表の型列からint型の行を取り出し、そのテストデータ列の値（符号８３の範囲）を全て取得する。同様に、引数yについても、境界値表と代表テストデータ表からテストデータを全て取得する。そして、図９に示すように引数x、yに関するテストデータについて全ての組み合わせを求める。図９では144通りの組み合わせが求められる。これらのテストデータの組み合わせを、図５の空のテストデータ表に登録すると、図１０に示すようなテストデータ表が完成する。図１０はテストデータ表の一部を示したものである。
すべてのメソッドについて上記処理を繰り返すことにより、テストデータ表が完成する。
Step 71: First, the test data generation unit reads the representative test data table and the boundary value table.
Step 72: Next, method lines are acquired one by one from the boundary value table. Here, the “boundary value method line” refers to data in the range indicated by
Step 73: Next, the boundary value information of the line acquired in
The test data table is completed by repeating the above process for all methods.
図１１は、図２のトレース機能埋込部２９の詳細な処理の流れを示したものである。
ステップ１１１：トレース機能埋込部は、まずテスト対象ソースコードを一行ずつ読み込む。
ステップ１１２：次に読み込んだ行がトレース対象行かどうかを判定する。トレース対象行とは、例えばJava(登録商標)言語によって記述されたソースコードであれば、ifやwhileなどの制御文や、代入処理やメソッド呼び出しなどの式が記述されている行を示す。空白行やコメント行、中括弧だけの行、クラス、メソッドの定義行などはトレース対象行としない。例えば図１では、２、３、４、６、７、８、１０、１１行目がトレース対象行に該当する。
ステップ１１３：ステップ１１２で読み込んだ行がトレース対象行であった場合、その行番号を取得する。
ステップ１１４：読み込んだ行の行末に”trace(<行番号>);”というメソッド呼び出し処理を埋め込む。traceメソッドは、引数として与えられた数値を、図２のトレース情報ファイル２１７に書き込む機能をもつメソッドである。トレース情報ファイルは単純なテキストファイルである。traceメソッドは、図２の自動テスト最適化部２２が提供している。
ステップ１１５：読み込んだすべての行に対して上記処理が完了したら、トレース情報出力処理が埋め込まれたソースコードを、修正済みテスト対象ソースコードとして保存する。
FIG. 11 shows the detailed processing flow of the trace
Step 111: The trace function embedding unit first reads the test target source code line by line.
Step 112: It is determined whether or not the next read line is a trace target line. For example, in the case of source code written in the Java (registered trademark) language, the trace target line indicates a line in which a control statement such as if or while or an expression such as an assignment process or a method call is described. Blank lines, comment lines, lines with only braces, class, method definition lines, etc. are not traced lines. For example, in FIG. 1, the second, third, fourth, sixth, seventh, eighth, tenth and eleventh lines correspond to the trace target lines.
Step 113: If the line read in
Step 114: Embed a method call process of “trace (<line number>);” at the end of the read line. The trace method is a method having a function of writing a numerical value given as an argument to the trace information file 217 of FIG. The trace information file is a simple text file. The trace method is provided by the automatic
Step 115: When the above process is completed for all the read lines, the source code in which the trace information output process is embedded is stored as a corrected test target source code.
この時点で、図１のソースコードは、図１２に示すように修正され、修正済みテスト対象ソースコードとして保存されている。これにより、メソッドの各行が実行されるごとにtraceメソッドが呼び出されトレース情報ファイルに行番号が出力されるようになる。このトレース情報ファイルに書き込まれた行番号の羅列を見れば、このメソッドがどのような処理の流れで実行されたかが追跡可能となる。 At this point, the source code of FIG. 1 is corrected as shown in FIG. 12 and stored as a corrected test target source code. As a result, the trace method is called every time each line of the method is executed, and the line number is output to the trace information file. By looking at the list of line numbers written in this trace information file, it is possible to trace the processing flow of this method.
図１３は、図２のテスト実行部２１１の処理の詳細を示したものである。
ステップ１３１：テスト実行部は修正済みテスト対象ソースコードをコンパイルし、実行可能な形式に変換する。
ステップ１３２：図１０のテストデータ表を読み込み、メソッド行をひとつずつ取得する。ここで取得するのは図１０の符号１０１に示すような範囲のデータである。
ステップ１３３：テスト実行結果表、トレース情報表を初期化する。図１４、図１５はそれぞれテスト実行結果表、トレース情報表の例であり、このようなデータを格納するためのメモリ領域を確保する。なおこれらの表はテスト対象メソッドの数だけ生成することになる。
ステップ１３４：テスト実行結果表に、ステップ１３２で取得したメソッド名とメソッド引数の情報を書き込む。例えば図１４の符号１４１に示す範囲にメソッド名とメソッド引数の情報を書き込む。
ステップ１３５：ステップ１３２で読み込んだメソッド行からテストデータを一件ずつ取得する。符号１０２は、1件目のテストデータ（テストケース名：テスト１、x=0、y=0）を指している。ここで、１件のテストデータを使用した１つのメソッドの実行を、１つのテストケースとし、固有のテストケース名を付ける。
ステップ１３６：ステップ１３２で取得したテストデータのテストケース名を、テスト実行結果表、トレース情報表に登録する。例えば、符号１０３に示す列がテストケース名となるため、符号１０２のテストデータの場合、「テスト１」がテストケース名となる。この「テスト１」を、符号１４３と、符号１５２の箇所に書き込む。
FIG. 13 shows details of the processing of the
Step 131: The test execution unit compiles the corrected test target source code and converts it into an executable format.
Step 132: The test data table of FIG. 10 is read and method lines are acquired one by one. Here, the data in the range as indicated by
Step 133: A test execution result table and a trace information table are initialized. FIGS. 14 and 15 are examples of a test execution result table and a trace information table, respectively, and a memory area for storing such data is secured. These tables are generated as many as the number of methods to be tested.
Step 134: Write the method name and method argument information acquired in
Step 135: Obtain test data one by one from the method line read in
Step 136: The test case name of the test data acquired in
ステップ１３７：以上でテスト実行の準備が完了し、いよいよテスト対象のメソッドを実行する。メソッドの実行時には、ステップ１３５で読み込んだテストデータをメソッド引数として実行する。例えば、符号１０２に示すテストデータを使用する場合は、x=0、y=0をdivideメソッドに対して与えて実行する。
ステップ１３８：テスト対象メソッドの実行が完了したら、そのメソッドが返値を返したかどうかを判定する。
ステップ１３９：テスト対象メソッドが返値を返した場合、その返値の型を登録するための新たな行をテスト実行結果表に挿入する。図１４ではテスト２（符号１４４）でint型の返値を返しているので、int型の返値を登録するための行（符号１４５）を新たに追加している。
ステップ１３１０：次にテスト対象メソッドの返値をテスト実行結果表に登録する。図１４では、符号１４６の箇所にテスト２（符号１４４）の返値の値である0を登録している。
Step 137: The preparation for the test execution is completed, and the test target method is finally executed. When executing the method, the test data read in
Step 138: When the execution of the test target method is completed, it is determined whether or not the method returns a return value.
Step 139: When the test target method returns a return value, a new row for registering the return value type is inserted into the test execution result table. In FIG. 14, since an int return value is returned in test 2 (reference numeral 144), a new line (reference numeral 145) for registering an int return value is added.
Step 1310: Next, the return value of the test target method is registered in the test execution result table. In FIG. 14, 0, which is the return value of test 2 (reference numeral 144), is registered at the
ステップ１３１１：ステップ１３８の判定によって、テスト対象メソッドが返値を返さない場合、次にテスト対象メソッド実行時に例外がスローされたかどうかを判定する。
ステップ１３１２：例外が発生した場合、その型の例外を登録するための新たな行をテスト実行結果表に挿入する。図１４ではテスト１（符号１４３）でArithmeticExceptionをスローしているので、ArithmeticExceptionが発生したことを登録するための行（符号１４７）を新たに追加している。
ステップ１３１３：次に例外が発生したことを実行結果表に○を付けて登録する。図１４では、符号１４８の箇所にテスト１でArithmeticExceptionが発生したことを登録している。
ステップ１３１４：最後にメソッドの実行により出力されたトレース情報ファイルの内容を、トレース情報表に登録する。例えば図１０のテスト１（符号１０２）のテストを実行すると、トレース情報ファイルには、「２ ６ １０」という数値の羅列が出力される。これらの数値をトレース情報表に、図１５の符号１５３に示すように書き込む。
Step 1311: If the test target method does not return a return value as a result of the determination in
Step 1312: If an exception occurs, a new row for registering the exception of that type is inserted into the test execution result table. In FIG. 14, since ArithmeticException is thrown in Test 1 (reference numeral 143), a line (reference numeral 147) for registering that an ArithmeticException has occurred is newly added.
Step 1313: The fact that an exception has occurred next is registered with a circle in the execution result table. In FIG. 14, the fact that an ArithmeticException has occurred in
Step 1314: The contents of the trace information file output last by executing the method are registered in the trace information table. For example, when the test of test 1 (reference numeral 102) in FIG. 10 is executed, a numerical sequence of “2 6 10” is output to the trace information file. These numerical values are written in the trace information table as indicated by
上記処理をすべてのテスト対象メソッドに対して実行すると、テスト対象メソッドごとにテスト実行結果表とトレース情報表が生成される。 When the above process is executed for all test target methods, a test execution result table and a trace information table are generated for each test target method.
図１６は、図２のテスト結果分析部２１４の処理の詳細を示したものである。
ステップ１６１：まずテスト結果分析部２１４は、テスト実行結果表とトレース情報表とを結合する。いずれの表も列数は同一なので、テストケース名で単純に結合可能である。図１７は、図１４のテスト実行結果表と、図１５のトレース情報表を結合したものである。図１７に示すとおり、テスト実行結果表の部分（符号１７１）とトレース情報表の部分（符号１７２）が結合していることがわかる。
ステップ１６２：次に、ステップ１６１で結合した表から、テスト実行結果をひとつずつ取得する。
ステップ１６３：次に、ステップ１６２で取得したテスト実行結果以降のテスト実行結果を、ひとつずつ取得する。例えば、ステップ１６２において符号１７３のテスト実行結果を取得した場合は、ステップ１６３では、符号１７４、符号１７５．．．のテスト実行結果を１つずつ取得する。
FIG. 16 shows the details of the processing of the test
Step 161: First, the test
Step 162: Next, the test execution results are obtained one by one from the table joined in
Step 163: Next, the test execution results after the test execution result acquired in
ステップ１６４：次に、ステップ１６２及び１６３で取得したテスト実行結果を比較し、トレース情報が同一かどうかを判定する。例えば、符号１７３と符号１７４のテスト実行結果を取得した場合は、それぞれの符号１７２０と符号１７２１の部分を比較する。この場合は、[２，６，１０]と[２，６，１０，１１]であり、異なっていることがわかる。しかし、符号１７３と符号１７８のテスト実行結果を取得した場合、符号１７２０と符号１７２２を比較すると、いずれも[２，６，１０]であり、同一であることがわかる。
Step 164: Next, the test execution results acquired in
ステップ１６５：ステップ１６４で同一であると判定した場合、ステップ１６３で取得したテスト実行結果を、テスト実行結果表から削除する。先ほどの例では、符号１７３と符号１７８のトレース情報が同一であったため、符号１７８のテスト実行結果をテスト実行結果表から削除する。
Step 165: When it is determined in
以上の処理を繰り返すと、重複したテスト実行結果が取り除かれたテスト実行結果表が完成する。図１８は、テスト結果分析部によって図１７から重複が取り除かれたものである。図１８では、削除したテスト実行結果（テスト４〜７、１０）を網掛けで表している。
By repeating the above processing, a test execution result table from which duplicate test execution results have been removed is completed. FIG. 18 is obtained by removing duplication from FIG. 17 by the test result analysis unit. In FIG. 18, the deleted test execution results (
最後に、テスト結果表示部２１５によって、テスト実行結果表の内容が、表示装置２１６に表示される。例えば、テスト結果表示部によって図１８のテスト実行結果表は表示装置で図１９のように表示される。開発者は、この表示を見ることで、以下のテストケースと、その実行結果を確認することができる。
（テスト１）y=0の場合（例外が発生）
（テスト２）x,y ともに100以下の場合
（テスト３）xが100以下、yが100より大きい場合
（テスト８）xが100より大きい、yが100以下の場合
（テスト９）x,yともに100より大きい場合
Finally, the test
(Test 1) When y = 0 (exception occurs)
(Test 2) When x and y are both 100 or less (Test 3) When x is 100 or less and y is greater than 100 (Test 8) When x is greater than 100 and y is 100 or less (Test 9) x, y If both are greater than 100
このように、本発明の自動テスト実行システムを用いることで、自動テスト実行部が実行した自動テスト結果に含まれる重複を、自動テスト最適化部が省き、必要最小限のテスト結果のみを開発者に提示できるため、開発者がテスト結果を確認する作業を最小限に抑えることができ、工数が削減や作業ミスの低減によるソフトウェアの品質向上が実現できる。 In this way, by using the automatic test execution system of the present invention, the automatic test optimization unit eliminates duplicates included in the automatic test results executed by the automatic test execution unit, and only the minimum necessary test results are developed by the developer. Therefore, it is possible to minimize the work for the developer to check the test results, and it is possible to improve the quality of the software by reducing the man-hours and the work errors.
２１：自動テスト実行部、２２：自動テスト最適化部、２３：テスト対象ソースコード２３、２４：ソースコード解析部、２５：境界値表、２６テストデータ生成部、２７：代表テストデータ表、２８：テストデータ表、２９：トレース機能埋込部、２１０：修正済みテスト対象ソースコード、２１１テスト実行部、２１２：テスト実行結果表、２１３：トレース情報表、２１４：テスト結果分析部、２１５：テスト結果表示部、２１６：表示装置、２１７：トレース情報ファイル
21: Automatic test execution unit, 22: Automatic test optimization unit, 23:
Claims (1)
代表テストデータ表及び前記境界値表を読み込み、すべてのテストデータを組み合わせて前記空のテストデータ表に登録するテストデータ生成部(26)と、
前記テスト対象ソースコードに対し、処理の流れを示すトレース情報を取得するための機能を埋め込み該テスト対象ソースコードを修正することにより、修正済みテスト対象ソースコードを作成するトレース機能埋込部(29)と、
前記テストデータを登録したテストデータ表を読み込み、各テストデータを使用して前記修正済みテスト対象ソースコードのメソッドを実行し、それぞれの実行を各テストケースとして、その返値または発生した例外をテスト実行結果表に登録すると同時にそのトレース情報をトレース情報表に登録するテスト実行部(211)と、
前記トレース情報表と前記テスト実行結果表とを結合し、結合した表中におけるトレース情報の重複したテストケースを削除するテスト結果分析部(214)と、
重複したテストケースを削除された前記テスト実行結果表を、表示装置に表示するテスト結果表示部(216)と、を備えたことを特徴とする自動テスト実行システム。 Read the test source code, analyze the method and method argument types defined in the test source code, create an empty test data table, and simultaneously analyze the conditional expression defined in the method Source code analysis unit (24) that creates a boundary value table,
A test data generation unit (26) that reads a representative test data table and the boundary value table, and registers all test data in the empty test data table;
A trace function embedding unit (29) that embeds a function for acquiring trace information indicating the flow of processing in the test target source code and creates the corrected test target source code by modifying the test target source code. )When,
Read the test data table in which the test data is registered, use the test data to execute the method of the modified test target source code, and test each return value or exception that occurred with each execution as each test case A test execution unit (211) that registers the trace information in the trace information table at the same time as registering in the execution result table,
A test result analysis unit (214) that combines the trace information table and the test execution result table, and deletes a test case in which trace information is duplicated in the combined table;
An automatic test execution system comprising: a test result display unit (216) that displays the test execution result table from which duplicate test cases have been deleted on a display device.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008062107A JP4874277B2 (en) | 2008-03-12 | 2008-03-12 | Automated test execution system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008062107A JP4874277B2 (en) | 2008-03-12 | 2008-03-12 | Automated test execution system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2009217664A JP2009217664A (en) | 2009-09-24 |
| JP4874277B2 true JP4874277B2 (en) | 2012-02-15 |
Family
ID=41189419
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2008062107A Expired - Fee Related JP4874277B2 (en) | 2008-03-12 | 2008-03-12 | Automated test execution system |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4874277B2 (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9632917B2 (en) | 2014-02-18 | 2017-04-25 | International Business Machines Corporation | Software testing |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5874891B2 (en) * | 2011-03-30 | 2016-03-02 | 日本電気株式会社 | Program test apparatus, program test method, and program |
| JP5629239B2 (en) | 2011-05-23 | 2014-11-19 | インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ | Apparatus and method for testing operation of software |
| JP6878707B2 (en) * | 2019-01-28 | 2021-06-02 | 三菱電機株式会社 | Test equipment, test methods and test programs |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0217547A (en) * | 1988-07-06 | 1990-01-22 | Fujitsu Ltd | Test data generation backup processing system |
| JP2585460B2 (en) * | 1990-09-28 | 1997-02-26 | 富士通株式会社 | Test data creation method |
| JP3105279B2 (en) * | 1991-03-04 | 2000-10-30 | 日本電信電話株式会社 | Program unit test data generation method |
| JPH06250883A (en) * | 1993-02-26 | 1994-09-09 | Hitachi Ltd | Method for preparing test command |
| JPH0969056A (en) * | 1995-08-31 | 1997-03-11 | Toshiba Corp | Test support device for computer program component |
-
2008
- 2008-03-12 JP JP2008062107A patent/JP4874277B2/en not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9632917B2 (en) | 2014-02-18 | 2017-04-25 | International Business Machines Corporation | Software testing |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2009217664A (en) | 2009-09-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101739339B (en) | Program dynamic dependency relation-based software fault positioning method | |
| CN100547562C (en) | The method and system of the unit testing use-case of problem when generation can be reproduced operation automatically | |
| US9898387B2 (en) | Development tools for logging and analyzing software bugs | |
| US9594543B2 (en) | Activity diagram model-based system behavior simulation method | |
| Zimmerman et al. | JMLUnit: The next generation | |
| US9274930B2 (en) | Debugging system using static analysis | |
| US20110078651A1 (en) | Method and system for test reduction and analysis | |
| JPH08272648A (en) | Method for automatically generating debugging command file and device for automatically regenerating break point in debugging command file | |
| US10037260B2 (en) | System for expression evaluation at debug time | |
| US20140214396A1 (en) | Specification properties creation for a visual model of a system | |
| WO2015130675A2 (en) | Apparatus and method for testing computer program implementation against a design model | |
| JP4874277B2 (en) | Automated test execution system | |
| Tiwari et al. | Reuse: reducing test effort | |
| Campbell | An executable semantics for CompCert C | |
| US11099978B2 (en) | Modeling system for software-implemented testing using domain specific profiles to translate tests for a subset of paths included in a UML test model | |
| CN111680463A (en) | File checking method and device | |
| US7624381B1 (en) | Portable detection of start and completion of object construction | |
| Mijatov et al. | Testing functional requirements in UML activity diagrams | |
| JP2009104252A (en) | Debugging support device and debugging support method | |
| WO2017064722A1 (en) | Bytecode generation from uml models | |
| JP2005338987A (en) | Exception test support program and device | |
| CN113282495B (en) | Java software fault positioning method based on track monitoring | |
| US20100251213A1 (en) | Method for executing debug commands | |
| JP2021111389A (en) | Improvement in parsability of code snippet | |
| Tran-Jørgensen et al. | Enhancing Testing of VDM-SL models |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20100701 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20111019 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20111101 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20111122 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20141202 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |