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.
しかし、従来のテスト方法には、開発者が想定したテストデータの範囲内でしかテストが行われないという問題がある。
例えば、図1に示すソースコードにおいて、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.
この問題を解決するために、想定されるあらゆるテストデータをプログラムに投入してテストを行う、自動テスト実行システムがある。自動テスト実行システムは、まずテスト対象のソースコードを解析し、メソッド引数の個数や型の情報を取得する。図1の例では「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には、ソースコードの分岐行を検索し、各分岐行毎に分岐条件を抽出し、分岐条件の正否両条件を取り出し、プログラム入力変数のみで表した式に分解してテスト項目を抽出し出力するテスト項目作成装置が開示されている。
しかしながら、従来の自動テスト実行システムには、開発者が目視でテスト結果を確認する必要があるため確認作業に多大な作業量を必要とする、という問題がある。さらに自動テスト実行システムは、ありとあらゆるテストデータを投入するため、同じような内容のテストを行っている場合がある。たとえば自動テスト実行システムが以下のようなテストデータを生成したとする。
(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.
本発明の自動テスト実行システムによれば、次のような効果がある。
(1)重複したテストケースがテスト実行結果から除去されるため、開発者がテスト結果を確認する作業を最小限に抑えることができ、その分の工数が削減できる。
(2)開発者がテスト結果を目視で確認する作業を最小限に抑えることができるため、人 為的な確認作業ミスが発生しにくく、ソフトウェアの品質向上につながる。
よって、本発明により、効率的な自動テスト実行システムが実現された。
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.
以下、実施例を示した図面を参照して本発明の実施の形態を説明する。
図2は、本発明の自動テスト実行システムの一実施例を示すシステム概要構成図である。本システムは、自動テスト実行の基本処理を行うための自動テスト実行部21と、自動テスト実行の効率化処理を行うための自動テスト最適化部22とから構成される。
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
自動テスト実行部21では、まずテスト対象ソースコード23を読み取り、ソースコード解析部24に与える。ソースコード解析部24は、境界値表25を生成する。次にテストデータ生成部26が、境界値表25と、あらかじめ用意してある代表テストデータ表27を読み込み、テストデータ表28を生成する。自動テスト最適化部22では、テスト対象ソースコード23をトレース機能埋込部29に与える。トレース機能埋込部29は、修正済みテスト対象ソースコード210を生成する。そしてテスト実行部211はテストデータ表28と修正済みテスト対象ソースコード210を読み込み、テスト対象メソッドを実行し、テスト実行結果表212とトレース情報ファイル217を出力する。さらに出力したトレース情報ファイル217の内容をトレース情報表213に登録する。ここでテスト結果分析部214が、トレース情報表213を読み込み、分析した結果を元にテスト実行結果表212を書き換える。最後にテスト結果表示部215がテスト実行結果表212を読み込み、その内容を表示装置216に表示する。
The automatic
次に各構成要素の詳細を、手順を追って説明する。
ここでは、例として図1のソースコードを自動テストする場合について考える。このソースコードには除算を行うdivideメソッドが定義されている。このメソッドを自動テストするには、まずソースコードを、図2のソースコード解析部24に与える。
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
図3はソースコード解析部の処理の流れを示したものである。
ステップ31:まず、ソースコード解析部は、境界値表とテストデータ表を初期化する。境界値表とはテスト対象のメソッド内の条件分岐処理の境界値を登録するための表である。またテストデータ表とは、自動テストを実行する際のテストデータとなる値を登録するための表である。ここでは、これらの各表を保存する計算機上のメモリ領域を計算機のメモリ上に確保している。
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.
ステップ32:次に、テスト対象のソースコードを読み込む。ソースコードには1つ以上のメソッドの定義が記述されている。
ステップ33:次に、ソースコード解析部はソースコードを一行ずつ読み込み、各メソッドの定義内容を1つずつ取得する。ここで「メソッド定義」とは、図1の符号11の範囲の文字列のことを示す。なお、メソッド定義は「<型> <メソッド名>(<メソッド引数のリスト>){ <メソッド本体> }」という構文で記述されているものとする。
ステップ34:次に、取得したメソッド定義を解析し、メソッド引数の定義を1つずつ取得する。なお、メソッド引数のリストは、「<型名> <一時変数名>, <型名> <一時変数名>, ..」という形式で列挙されており、「<型名> <一時変数名>」の各々がメソッド引数の定義である。
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.
ステップ35:この時点で、メソッド名、メソッド引数の型名、メソッド引数の一時変数名がわかっているので、これらの情報を境界値表、テストデータ表に登録する。テストデータ表の形式は、図5に示すとおりである。符号51、52、53の箇所にそれぞれ、メソッド名、メソッド引数の一時変数名、メソッド引数の型名、を埋め込むことで登録を行う。また、境界値表の形式は、図6に示すとおりであり、こちらも同様に図6の符号61、62、63の箇所にそれぞれ、メソッド名、メソッド引数の一時変数名、メソッド引数の型名、を埋め込むことで登録を行う。
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
ステップ36:次にステップ34で取得したメソッド引数の定義について、このメソッド引数の一時変数がメソッド定義の中で参照されている箇所を探し、その箇所を1つずつ取得する。たとえば、図1のソースコードにおいて、メソッド引数x(符号12)は、2行目、4行目、10行目で参照されているので、これらの行をひとつずつ取得する。 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.
ステップ37:次にステップ36で取得した参照箇所行と、ステップ34で取得したメソッド引数の一時変数名を、境界表登録処理に与え、実行する。境界表登録処理の詳細は図4で説明する。
Step 37: Next, the reference location line acquired in
以上の処理を繰り返し、すべてのテスト対象メソッドについて、境界値表とテストデータ表の各項目を埋める。この時点でテストデータ表は、図5のように、空のテストデータ表となっている。 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.
次に図4について説明する。境界値登録処理は、メソッド引数の一時変数名と、その変数が参照されている箇所の文字列を与えて実行する。図4は境界値登録処理の詳細について示したものである。
ステップ41:まずメソッド引数の参照箇所が比較式であるかどうかを判定する。比較式とはif文やswitch文などのことである。なお、厳密に境界値の解析を行う場合は、比較式だけではなくwhileなどの制御文についても判定する必要があるが、本実施例では説明を簡潔にするためif文のみに限定する。
ステップ42:参照箇所が比較式であった場合、比較している値が単純なint型の値であるかどうかを判定する。例えば、図1の2行目は「if(100 < x)」という条件文が記述されているが、ここで比較値は”100”であり、これは単純なint型の値である。なお、厳密に境界値の解析を行う場合は、比較値が単純なint値の場合だけでなく、たとえばdouble, float, String型であった場合や、比較値が変数の参照である場合についても考慮する必要がある。しかし本実施例では説明を簡潔にするためint値のみに限定する。
ステップ43、44、45:比較値がint値であった場合、その比較値、比較値から1を引いた値、比較値に1を加えた値、を境界値表に登録する。たとえば図1の2行目を解析する場合、比較値は100であるため、図6の符号64の箇所に100を、符号65の箇所に99を、符号66の箇所に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.
図3及び図4の処理をすべてのメソッドに対して実行すると、最終的に図6に示すような境界値表が完成する。 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.
ここで、代表テストデータ表について説明する。代表テストデータ表とは、自動テスト実行システムが保持するテストデータの集合であり、よく使用されるテストデータを、代表テストデータとして保持しているものである。図8は代表テストデータ表の例を示したものである。代表テストデータ表は、型列81とテストデータ列82で構成されたデータの集合である。図8ではたとえば、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
次に図7について説明する。図7は、図2のテストデータ生成部26の詳細な処理について示したものである。テストデータ生成部26は、境界値表25と代表テストデータ表27を読み込み、テストデータ表28を生成する。
Next, FIG. 7 will be described. FIG. 7 shows the detailed processing of the test
ステップ71:まず、テストデータ生成部は、代表テストデータ表、境界値表を読み込む。
ステップ72:次に、境界値表からメソッド行をひとつずつ取得する。ここで「境界値のメソッド行」とは図6の符号67に示す範囲のデータのことである。符号67の範囲には、図1のソースコードのdivideメソッドについての境界値情報が格納されている。
ステップ73:次に、ステップ72で取得した行の境界値情報と、代表テストデータ表のテストデータをすべて組み合わせて、テストデータ表に書き込む。組み合わせ処理はメソッド引数ごとに行う。例えば、図6及び図8において、divideメソッドの引数xに対するテストデータの組み合わせを行う際は、まず、図6の境界値表から引数xの境界値(符号64、65、66)をすべて取得する。また、引数xはint型の値なので、図8の代表テストデータ表の型列からint型の行を取り出し、そのテストデータ列の値(符号83の範囲)を全て取得する。同様に、引数yについても、境界値表と代表テストデータ表からテストデータを全て取得する。そして、図9に示すように引数x、yに関するテストデータについて全ての組み合わせを求める。図9では144通りの組み合わせが求められる。これらのテストデータの組み合わせを、図5の空のテストデータ表に登録すると、図10に示すようなテストデータ表が完成する。図10はテストデータ表の一部を示したものである。
すべてのメソッドについて上記処理を繰り返すことにより、テストデータ表が完成する。
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.
図11は、図2のトレース機能埋込部29の詳細な処理の流れを示したものである。
ステップ111:トレース機能埋込部は、まずテスト対象ソースコードを一行ずつ読み込む。
ステップ112:次に読み込んだ行がトレース対象行かどうかを判定する。トレース対象行とは、例えばJava(登録商標)言語によって記述されたソースコードであれば、ifやwhileなどの制御文や、代入処理やメソッド呼び出しなどの式が記述されている行を示す。空白行やコメント行、中括弧だけの行、クラス、メソッドの定義行などはトレース対象行としない。例えば図1では、2、3、4、6、7、8、10、11行目がトレース対象行に該当する。
ステップ113:ステップ112で読み込んだ行がトレース対象行であった場合、その行番号を取得する。
ステップ114:読み込んだ行の行末に”trace(<行番号>);”というメソッド呼び出し処理を埋め込む。traceメソッドは、引数として与えられた数値を、図2のトレース情報ファイル217に書き込む機能をもつメソッドである。トレース情報ファイルは単純なテキストファイルである。traceメソッドは、図2の自動テスト最適化部22が提供している。
ステップ115:読み込んだすべての行に対して上記処理が完了したら、トレース情報出力処理が埋め込まれたソースコードを、修正済みテスト対象ソースコードとして保存する。
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.
この時点で、図1のソースコードは、図12に示すように修正され、修正済みテスト対象ソースコードとして保存されている。これにより、メソッドの各行が実行されるごとに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.
図13は、図2のテスト実行部211の処理の詳細を示したものである。
ステップ131:テスト実行部は修正済みテスト対象ソースコードをコンパイルし、実行可能な形式に変換する。
ステップ132:図10のテストデータ表を読み込み、メソッド行をひとつずつ取得する。ここで取得するのは図10の符号101に示すような範囲のデータである。
ステップ133:テスト実行結果表、トレース情報表を初期化する。図14、図15はそれぞれテスト実行結果表、トレース情報表の例であり、このようなデータを格納するためのメモリ領域を確保する。なおこれらの表はテスト対象メソッドの数だけ生成することになる。
ステップ134:テスト実行結果表に、ステップ132で取得したメソッド名とメソッド引数の情報を書き込む。例えば図14の符号141に示す範囲にメソッド名とメソッド引数の情報を書き込む。
ステップ135:ステップ132で読み込んだメソッド行からテストデータを一件ずつ取得する。符号102は、1件目のテストデータ(テストケース名:テスト1、x=0、y=0)を指している。ここで、1件のテストデータを使用した1つのメソッドの実行を、1つのテストケースとし、固有のテストケース名を付ける。
ステップ136:ステップ132で取得したテストデータのテストケース名を、テスト実行結果表、トレース情報表に登録する。例えば、符号103に示す列がテストケース名となるため、符号102のテストデータの場合、「テスト1」がテストケース名となる。この「テスト1」を、符号143と、符号152の箇所に書き込む。
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
ステップ137:以上でテスト実行の準備が完了し、いよいよテスト対象のメソッドを実行する。メソッドの実行時には、ステップ135で読み込んだテストデータをメソッド引数として実行する。例えば、符号102に示すテストデータを使用する場合は、x=0、y=0をdivideメソッドに対して与えて実行する。
ステップ138:テスト対象メソッドの実行が完了したら、そのメソッドが返値を返したかどうかを判定する。
ステップ139:テスト対象メソッドが返値を返した場合、その返値の型を登録するための新たな行をテスト実行結果表に挿入する。図14ではテスト2(符号144)でint型の返値を返しているので、int型の返値を登録するための行(符号145)を新たに追加している。
ステップ1310:次にテスト対象メソッドの返値をテスト実行結果表に登録する。図14では、符号146の箇所にテスト2(符号144)の返値の値である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
ステップ1311:ステップ138の判定によって、テスト対象メソッドが返値を返さない場合、次にテスト対象メソッド実行時に例外がスローされたかどうかを判定する。
ステップ1312:例外が発生した場合、その型の例外を登録するための新たな行をテスト実行結果表に挿入する。図14ではテスト1(符号143)でArithmeticExceptionをスローしているので、ArithmeticExceptionが発生したことを登録するための行(符号147)を新たに追加している。
ステップ1313:次に例外が発生したことを実行結果表に○を付けて登録する。図14では、符号148の箇所にテスト1でArithmeticExceptionが発生したことを登録している。
ステップ1314:最後にメソッドの実行により出力されたトレース情報ファイルの内容を、トレース情報表に登録する。例えば図10のテスト1(符号102)のテストを実行すると、トレース情報ファイルには、「2 6 10」という数値の羅列が出力される。これらの数値をトレース情報表に、図15の符号153に示すように書き込む。
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.
図16は、図2のテスト結果分析部214の処理の詳細を示したものである。
ステップ161:まずテスト結果分析部214は、テスト実行結果表とトレース情報表とを結合する。いずれの表も列数は同一なので、テストケース名で単純に結合可能である。図17は、図14のテスト実行結果表と、図15のトレース情報表を結合したものである。図17に示すとおり、テスト実行結果表の部分(符号171)とトレース情報表の部分(符号172)が結合していることがわかる。
ステップ162:次に、ステップ161で結合した表から、テスト実行結果をひとつずつ取得する。
ステップ163:次に、ステップ162で取得したテスト実行結果以降のテスト実行結果を、ひとつずつ取得する。例えば、ステップ162において符号173のテスト実行結果を取得した場合は、ステップ163では、符号174、符号175...のテスト実行結果を1つずつ取得する。
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
ステップ164:次に、ステップ162及び163で取得したテスト実行結果を比較し、トレース情報が同一かどうかを判定する。例えば、符号173と符号174のテスト実行結果を取得した場合は、それぞれの符号1720と符号1721の部分を比較する。この場合は、[2,6,10]と[2,6,10,11]であり、異なっていることがわかる。しかし、符号173と符号178のテスト実行結果を取得した場合、符号1720と符号1722を比較すると、いずれも[2,6,10]であり、同一であることがわかる。
Step 164: Next, the test execution results acquired in
ステップ165:ステップ164で同一であると判定した場合、ステップ163で取得したテスト実行結果を、テスト実行結果表から削除する。先ほどの例では、符号173と符号178のトレース情報が同一であったため、符号178のテスト実行結果をテスト実行結果表から削除する。
Step 165: When it is determined in
以上の処理を繰り返すと、重複したテスト実行結果が取り除かれたテスト実行結果表が完成する。図18は、テスト結果分析部によって図17から重複が取り除かれたものである。図18では、削除したテスト実行結果(テスト4〜7、10)を網掛けで表している。
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 (
最後に、テスト結果表示部215によって、テスト実行結果表の内容が、表示装置216に表示される。例えば、テスト結果表示部によって図18のテスト実行結果表は表示装置で図19のように表示される。開発者は、この表示を見ることで、以下のテストケースと、その実行結果を確認することができる。
(テスト1)y=0の場合(例外が発生)
(テスト2)x,y ともに100以下の場合
(テスト3)xが100以下、yが100より大きい場合
(テスト8)xが100より大きい、yが100以下の場合
(テスト9)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:自動テスト実行部、22:自動テスト最適化部、23:テスト対象ソースコード23、24:ソースコード解析部、25:境界値表、26テストデータ生成部、27:代表テストデータ表、28:テストデータ表、29:トレース機能埋込部、210:修正済みテスト対象ソースコード、211テスト実行部、212:テスト実行結果表、213:トレース情報表、214:テスト結果分析部、215:テスト結果表示部、216:表示装置、217:トレース情報ファイル
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 | インターナショナル・ビジネス・マシーンズ・コーポレーションInternational Business Machines Corporation | 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 |