KR102485341B1 - Apparatus and method for managing testcase for testing software - Google Patents

Abstract

A test case management apparatus for software testing according to an embodiment of the present invention includes a plurality of first test cases for testing functional elements of first software and a plurality of second test cases for testing functional elements of second software. a case generating unit that compares functional elements of the first software and functional elements of the second software to detect at least one third test case corresponding to a first detection condition among the plurality of second test cases; A first detection unit compares the plurality of first test cases with the plurality of second test cases to obtain at least one fourth test case corresponding to a second detection condition among the plurality of first test cases and the plurality of second test cases. It may include a second detection unit that detects a test case, and a determination unit that determines at least one of the detected third and fourth test cases as an optimum test case.

Description

Test case management device and method for software testing {APPARATUS AND METHOD FOR MANAGING TESTCASE FOR TESTING SOFTWARE}

The present invention relates to a test case management apparatus and management method for software testing.

The controller software (SW) is developed in such a way that a base model is initially developed, and derivative models are developed by modifying parts of the base model when functions included in the base model are added, changed, or deleted. The derived model developed in this way is tested using the test case that performed the test on the initial base model.

There are two main ways to perform the test. One is to perform verification using all the test cases used as input data when verifying the initial base model (SW revalidation), and the other is to consider the SW part changed from the initial base model for efficiency of verification. This is a method to perform verification by selecting some of the test cases used for base model verification (SW regression verification).

However, in the case of the SW re-validation method, although the reliability of the test can be secured, there is a problem of low test efficiency due to excessive test time. There is a problem of poor test reliability.

One object of the present invention is to provide a test case management apparatus and management method for software testing that can improve the efficiency and/or reliability of software testing.

The technical problems of the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art from the description below.

A test case management apparatus for software testing according to an embodiment of the present invention includes a plurality of first test cases for testing functional elements of first software and a plurality of second test cases for testing functional elements of second software. a case generating unit that compares functional elements of the first software and functional elements of the second software to detect at least one third test case corresponding to a first detection condition among the plurality of second test cases; A first detection unit compares the plurality of first test cases with the plurality of second test cases to obtain at least one fourth test case corresponding to a second detection condition among the plurality of first test cases and the plurality of second test cases. It may include a second detection unit that detects a test case, and a determination unit that determines at least one of the detected third and fourth test cases as an optimum test case.

In an embodiment, the first detection condition may be a condition for detecting a test case corresponding to functional elements different from those of the first software among functional elements of the second software.

In one embodiment, the second detection condition detects test cases defined by different values among test cases corresponding to the same functional elements among the functional elements of the first software and the functional elements of the second software. It may be a condition that

In one embodiment, the functional elements of the second software may be created by deleting some of the functional elements of the first software or adding other functional elements to the functional elements of the first software.

In one embodiment, each of the plurality of first test cases may include input values of variables defined in functional elements of the first software.

In one embodiment, each of the plurality of second test cases may include input values of variables defined in functional elements of the second software.

A test case management method for software testing according to an embodiment of the present invention includes a plurality of first test cases for testing functional elements of first software and a plurality of second test cases for testing functional elements of second software. generating, comparing functional elements of the first software with functional elements of the second software and detecting at least one third test case corresponding to a first detection condition among the plurality of second test cases; At least one fourth test case corresponding to the second detection condition is detected among the first plurality of test cases and the plurality of second test cases by comparing the plurality of first test cases with the plurality of second test cases. and determining the detected at least one third test case and a fourth test case as an optimal test case.

In an embodiment, the first detection condition may be a condition for detecting a test case corresponding to functional elements different from those of the first software among functional elements of the second software.

In one embodiment, the second detection condition detects test cases defined by different values among test cases corresponding to the same functional elements among the functional elements of the first software and the functional elements of the second software. It may be a condition that

In one embodiment, the functional elements of the second software may be created by deleting some of the functional elements of the first software or adding other functional elements to the functional elements of the first software.

In one embodiment, each of the plurality of first test cases may include input values of variables defined in functional elements of the first software.

In one embodiment, each of the plurality of second test cases may include input values of variables defined in functional elements of the second software.

According to the test case management apparatus and management method for software testing according to an embodiment of the present invention, the efficiency and/or reliability of software testing can be improved.

1 is a diagram for explaining functional elements of first software and second software according to an embodiment of the present invention.
2 shows a test case management device for software testing according to an embodiment of the present invention.
3 is a flowchart showing a test case management method for software testing according to an embodiment of the present invention.
4 is a diagram for explaining a plurality of first test cases for testing functional elements of the first software according to an embodiment of the present invention.
5 is a diagram for explaining a plurality of second test cases for testing functional elements of a second software according to an embodiment of the present invention.
6 and 7 are diagrams for explaining in detail a test case management method for software testing according to an embodiment of the present invention.
8 shows a computing system for executing a test case management method for software testing according to an embodiment of the present invention.

Hereinafter, some embodiments of the present invention will be described in detail through exemplary drawings. In adding reference numerals to components of each drawing, it should be noted that the same components have the same numerals as much as possible even if they are displayed on different drawings. In addition, in describing an embodiment of the present invention, if it is determined that a detailed description of a related known configuration or function hinders understanding of the embodiment of the present invention, the detailed description will be omitted.

In describing the components of the embodiment of the present invention, terms such as first, second, A, B, (a), and (b) may be used. These terms are only used to distinguish the component from other components, and the nature, order, or order of the corresponding component is not limited by the term. In addition, unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by a person of ordinary skill in the art to which the present invention belongs. Terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with the meaning in the context of the related art, and unless explicitly defined in the present application, they should not be interpreted in an ideal or excessively formal meaning. don't

Hereinafter, 'software' may refer to software executed by a controller of a vehicle, but this is only an example to aid understanding, and is not limited thereto. In addition, 'software' may include first software and second software, and the second software deletes some of the functional elements of the first software, adds other functional elements to the functional elements of the first software, or It may be defined as software that changes all or part of the functional elements of the first software.

1 is a diagram for explaining functional elements of first software and second software according to an embodiment of the present invention.

Referring to Figure 1, the functional elements of the first software (a) and the second software (b) are shown. Here, the functional element may include 'state' and 'transition' defined in software, 'state' may mean the state of the vehicle controller at a specific point in time, and 'transition' may mean each It may mean an operation connecting 'states'. In addition, 'transition' may consist of a 'transition condition' for generating a transition and an operation that occurs when the transition condition is satisfied.

Referring to (a) of FIG. 1 , the first software may be composed of functional elements (sub 1 to sub 8). Referring to (b) of FIG. 1 , the second software may be composed of functional elements (subs 1 to 3, sub 4, sub 6, and sub 8 to 11). That is, the second software may have a form in which sub 5 is changed to sub 11, sub 7 is deleted, and sub 9 and sub 10 are added among the functional elements of the first software. In this way, the second software may be defined as software in which some of the functional elements of the first software are deleted, other functional elements are added to the functional elements of the first software, or all or some of the functional elements of the first software are changed. . Meanwhile, for ease of understanding, functional elements of the first software and the second software are defined as 'transition' below.

Among the functional elements of the second software, the test cases related to the functional elements (ex. subs 9 and 10) added compared to the functional elements of the first software (ie, test cases for testing the added functional elements) are the first 2 Need to be used for software testing. In addition, if some of the functional elements of the second software are changed (ex. sub 5 -> sub 11, see FIG. 1) or deleted (ex. sub 7 deleted, see FIG. 1), the changed or deleted The test case(s) related to the functional element affected by the functional element also need to be used for testing of the second software.

Accordingly, the test case management apparatus and management method for software testing according to an embodiment of the present invention may include a technical idea for determining an optimal test case for a second software test.

Specifically, a test case management apparatus and management method for software testing according to an embodiment of the present invention includes a test case and a first test case corresponding to functional elements different from those of the first software among functional elements of the second software. Among the functional elements of the software and the functional elements of the second software, among test cases corresponding to the same functional elements, test cases defined by different values may be detected and determined as an optimal test case. This will be described in more detail below with reference to FIGS. 2 to 7 .

2 shows a test case management device for software testing according to an embodiment of the present invention.

Referring to FIG. 2 , the test case management apparatus 100 for software testing according to an embodiment of the present invention includes a case generating unit 110, a first detection unit 120, a second detection unit 130, and a determination unit. (140).

The case generating unit 110 may generate a test case for testing software. For example, the case generating unit 110 may use a Simulink/Stateflow model to detect an object requiring a test among functional elements of software and generate a test case for testing the detected object.

The case generating unit 110 may generate test cases for testing each of the first software and the second software. For example, the case generator 110 may generate a plurality of first test cases for testing functional elements of the first software and a plurality of second test cases for testing functional elements of the second software.

Each of the plurality of first test cases may include input values of variables defined in functional elements of the first software, and each of the plurality of second test cases may include variables defined in functional elements of the second software. Can contain inputs. Here, the variable may be a variable related to transition conditions of functional elements.

The first detection unit 120 may detect at least one third test case corresponding to the first detection condition. Here, the first detection condition may be defined as a condition for detecting test cases corresponding to functional elements different from those of the first software among functional elements of the second software. For example, the first detection unit 120 compares functional elements of the first software with functional elements of the second software to determine at least one third test case corresponding to the first detection condition among a plurality of second test cases. can be detected.

The second detection unit 130 may detect at least one fourth test case corresponding to the second detection condition. Here, the second detection condition may be defined as a condition for detecting test cases defined with different values among test cases corresponding to the same functional elements among the functional elements of the first software and the functional elements of the second software. there is. For example, the second detection unit 130 compares the plurality of first test cases with the plurality of second test cases, and at least corresponds to the second detection condition among the plurality of first test cases and the plurality of second test cases. One fourth test case can be detected.

In addition, the second detection unit 130 simulates the first software and the second software using a plurality of first test cases for testing the first software, and uses a plurality of second test cases for testing the second software. The fourth test case can be detected based on the coverage result obtained by simulating the first software and the second software using Here, the coverage result can be defined as pass/fail information obtained as a result of simulating the software using a plurality of test cases, and the test case corresponding to the pass is a test case capable of testing the software, A test case corresponding to a fail may be a test case in which software testing is impossible.

The determination unit 140 may determine at least one of the detected third and fourth test cases as an optimal test case.

3 is a flowchart showing a test case management method for software testing according to an embodiment of the present invention. 4 is a diagram for explaining a plurality of first test cases for testing functional elements of the first software according to an embodiment of the present invention. 5 is a diagram for explaining a plurality of second test cases for testing functional elements of a second software according to an embodiment of the present invention. 6 and 7 are diagrams for explaining in detail a test case management method for software testing according to an embodiment of the present invention.

First, referring to FIG. 3, the test case management method for software testing according to an embodiment of the present invention includes a plurality of first test cases for testing functional elements of first software and functional elements of second software. generating a plurality of second test cases (S110); at least one of the plurality of second test cases corresponding to the first detection condition by comparing functional elements of the first software with functional elements of the second software; Detecting a third test case (S120), by comparing the plurality of first test cases with the plurality of second test cases, at least one corresponding to a second detection condition among the plurality of first test cases and the plurality of second test cases. It may include detecting one fourth test case (S130), and determining at least one third and fourth test case as an optimal test case (S140).

Hereinafter, steps S110 to S140 described above will be described in more detail with reference to FIGS. 2 and 4 to 7 .

In step S110, the case generation unit 110 may generate test cases for testing each of the first software and the second software. For example, the case generator 110 may generate a plurality of first test cases for testing functional elements of the first software and a plurality of second test cases for testing functional elements of the second software.

Referring to FIG. 4 , the case generating unit 110 may generate a plurality of first test cases for testing each of functional elements R1 to R9 of the first software. Each of the plurality of first test cases may include input values of variables (ex. A and B) related to transition conditions of functional elements of the first software, and as shown in FIG. 4, input values of each variable It can be defined in the form of a set of values.

Referring to FIG. 5 , the case generator 110 may generate a plurality of second test cases for testing each of functional elements R1 to R7, R10, and R11 of the second software. Each of the plurality of second test cases may include input values of variables (ex. A and B) related to transition conditions of functional elements of the second software, and as shown in FIG. 5, input values of each variable It can be defined in the form of a set of values.

In step S120, the first detection unit 120 may detect at least one third test case corresponding to the first detection condition. Here, the first detection condition will be defined as a condition for detecting test cases corresponding to functional elements different from those of the first software (ie, added or deleted functional elements) among functional elements of the second software. can

Referring to FIGS. 4 and 5 , the first detection unit 120 compares functional elements R8 and R9 deleted from the second software and added functional elements from the second software when compared with functional elements of the first software. Test cases for testing R10 and R11) may be detected as at least one third test case. Specifically, in FIGS. 4 and 5, test cases related to R8 ({(0, 0), (1, 0), (1, 1), (1, 3)}) and test cases related to R9 ({( 0, 0), (1, 0), (1, 1), (1, 3), (1, 0)}), test cases related to R10 ({(0, 0), (1, 0), (1, 2)}) and test cases related to R11 ((0, 0), (1, 0), (1, 2), (1, 0)}) can be detected as a third test case. . Meanwhile, although not shown, the functional element R5 of the second software may be defined as the same as the functional element R5 of the first software, but with a changed transition condition, and it is assumed that this case does not correspond to the first detection condition. do.

In step S130, the second detection unit 130 may detect at least one fourth test case corresponding to the second detection condition. Here, the second detection condition may be defined as a condition for detecting test cases defined with different values among test cases corresponding to the same functional elements among the functional elements of the first software and the functional elements of the second software. there is.

Referring to FIGS. 4 and 5 , the second detection unit 130 detects differences between test cases corresponding to the same functional elements R1 to R7 among the functional elements of the first software and the functional elements of the second software. A test case defined as a value (a test case corresponding to R6 and R7) can be detected as the fourth test case.

Specifically, in FIG. 4, the second detection unit 130 performs test cases ({(0, 0), (1, 0), (1, 1), (1, 1), (1, 2)}) and the test cases associated with R7 ({(0, 0), (1, 0), (1, 1), (1, 1), (1, 2), (1, 0) }), test cases related to functional element R6 of the second software in FIG. 5 ({(0, 0), (1, 0), (1, 1), (1, 1), (1, 1), ( 1, 2)}) and test cases related to R7 ({(0, 0), (1, 0), (1, 1), (1, 1), (1, 1), (1, 2), (1, 0)}) can be detected as the fourth test case.

In addition, the second detection unit 130 simulates the first software and the second software using a plurality of first test cases for testing the first software, and uses a plurality of second test cases for testing the second software. The fourth test case can be detected based on the coverage result obtained by simulating the first software and the second software using

For example, referring to FIG. 6 , the second detection unit 130 determines functional elements M1 of the first software and functional elements (M1) of the second software by using a plurality of first test cases for the first software. M2) can be simulated. As a result of the simulation, R6 and R7 among functional elements M2 of the second software may not be covered by the plurality of first test cases. This may mean that R6 and R7 among the function elements M2 of the second software may be affected by the change in the transition condition of the function element R5 or the deletion of R8 and R9 described above. Accordingly, the second detection unit 130 may detect test cases related to functional elements R6 and R7 of the first software as fourth test cases. Also, referring to FIG. 7 , the second detection unit 130 detects functional elements M1 of the first software and functional elements M2 of the second software by using a plurality of second test cases for the second software. can be simulated. As a result of the simulation, R6 and R7 among functional elements M1 of the first software may not be covered by the plurality of second test cases. This may mean that R6 and R7 among the functional elements M1 of the first software may be affected by the change in the transition condition of the functional element R5 or the addition of R10 and R11 described above. Accordingly, the second detection unit 130 may detect test cases related to functional elements R6 and R7 of the second software as fourth test cases.

In step S140, the determination unit 140 may determine at least one of the detected third and fourth test cases as the optimum test case.

That is, the determination unit 140 determines the test cases ({(0, 0), (1, 0), (1, 1), (1, 1), (1, 2)}), test cases related to R7 ({(0, 0), (1, 0), (1, 1), (1, 1), (1, 2), (1, 0)}), Test cases related to R8 ({(0, 0), (1, 0), (1, 1), (1, 3)}) and test cases related to R9 ({(0, 0), (1, 0) ), (1, 1), (1, 3), (1, 0)}), test cases related to R6 among the functional elements of the second software ({(0, 0), (1, 0), ( 1, 1), (1, 1), (1, 1), (1, 2)}), test cases related to R7 ({(0, 0), (1, 0), (1, 1), (1, 1), (1, 1), (1, 2), (1, 0), test cases related to R10 ({(0, 0), (1, 0), (1, 2)}) , and test cases related to R11 ((0, 0), (1, 0), (1, 2), (1, 0)}), a total of 8 test cases can be determined as optimal test cases.

Therefore, according to the test case management apparatus and management method for software testing according to an embodiment of the present invention, it is possible to test software by selectively using only some test cases instead of test cases for testing all functional elements. Efficiency can be improved, and test reliability can be improved because software can be tested by selectively using a test case that satisfies the first detection condition or the second detection condition.

8 shows a computing system for executing a test case management method for software testing according to an embodiment of the present invention.

Referring to FIG. 8 , the test case management method for software testing according to an embodiment of the present invention described above may be implemented through a computing system. The computing system 1000 includes at least one processor 1100, memory 1300, user interface input device 1400, user interface output device 1500, storage 1600, and A network interface 1700 may be included.

The processor 1100 may be a central processing unit (CPU) or a semiconductor device that processes commands stored in the memory 1300 and/or the storage 1600 . The memory 1300 and the storage 1600 may include various types of volatile or nonvolatile storage media. For example, the memory 1300 may include read only memory (ROM) and random access memory (RAM).

Accordingly, the steps of a method or algorithm described in connection with the embodiments disclosed herein may be directly implemented as hardware executed by the processor 1100, a software module, or a combination of the two. A software module resides in a storage medium (i.e., memory 1300 and/or storage 1600) such as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, or a CD-ROM. You may. An exemplary storage medium is coupled to the processor 1100, and the processor 1100 can read information from, and write information to, the storage medium. Alternatively, the storage medium may be integral with the processor 1100. The processor and storage medium may reside within an application specific integrated circuit (ASIC). An ASIC may reside within a user terminal. Alternatively, the processor and storage medium may reside as separate components within a user terminal.

The above description is merely an example of the technical idea of the present invention, and various modifications and variations can be made to those skilled in the art without departing from the essential characteristics of the present invention.

Therefore, the embodiments disclosed in the present invention are not intended to limit the technical idea of the present invention, but to explain, and the scope of the technical idea of the present invention is not limited by these embodiments. The protection scope of the present invention should be construed according to the claims below, and all technical ideas within the equivalent range should be construed as being included in the scope of the present invention.

100: test case management device for software testing
110: case generating unit
120: first detection unit
130: second detection unit
140: decision unit
1000: computing system
1100: processor
1200: bus
1300: memory
1310: ROM
1320: RAM
1400: user interface input device
1500: user interface output device
1600: storage
1700: network interface

Claims (12)

a case generating unit generating a plurality of first test cases for testing functional elements of the first software and a plurality of second test cases for testing functional elements of the second software;
a first detection unit which compares functional elements of the first software with functional elements of the second software and detects at least one third test case corresponding to a first detection condition among the plurality of second test cases;
At least one fourth test case corresponding to the second detection condition is detected among the first plurality of test cases and the plurality of second test cases by comparing the plurality of first test cases with the plurality of second test cases. a second detection unit; and
A determination unit for determining the detected at least one third test case and a fourth test case as an optimum test case;
The first detection condition is a condition for detecting a test case corresponding to functional elements different from the functional elements of the first software among the functional elements of the second software, and the second detection condition is a condition for detecting the functional elements of the first software. A test case management device for software testing, characterized in that it is a condition for detecting test cases defined with different values among test cases corresponding to the same functional elements among functional elements and functional elements of the second software. delete delete According to claim 1,
The functional elements of the second software are created by deleting some of the functional elements of the first software or adding other functional elements to the functional elements of the first software. According to claim 1,
The test case management device for software testing, characterized in that each of the plurality of first test cases includes input values of variables defined in functional elements of the first software. According to claim 1,
The test case management device for software testing, characterized in that each of the plurality of second test cases includes input values of variables defined in functional elements of the second software. generating a plurality of first test cases for testing functional elements of the first software and a plurality of second test cases for testing functional elements of the second software;
detecting at least one third test case corresponding to a first detection condition among the plurality of second test cases by comparing functional elements of the first software with functional elements of the second software;
At least one fourth test case corresponding to the second detection condition is detected among the first plurality of test cases and the plurality of second test cases by comparing the plurality of first test cases with the plurality of second test cases. doing; and
Determining the detected at least one third test case and a fourth test case as an optimum test case,
The first detection condition is a condition for detecting a test case corresponding to functional elements different from the functional elements of the first software among the functional elements of the second software, and the second detection condition is a condition for detecting the functional elements of the first software. A test case management method for software testing, characterized in that the condition for detecting test cases defined with different values among test cases corresponding to the same functional elements among functional elements and functional elements of the second software. delete delete According to claim 7,
The test case management method for software testing, characterized in that the functional elements of the second software are created by deleting some of the functional elements of the first software or adding other functional elements to the functional elements of the first software. According to claim 7,
The test case management method for software testing, wherein each of the plurality of first test cases includes input values of variables defined in functional elements of the first software. According to claim 7,
The test case management method for software testing, wherein each of the plurality of second test cases includes input values of variables defined in functional elements of the second software.

Images