Vehicle function testing device and control method thereof

Abstract

The present invention discloses a test device and a control method thereof for generating test cases based on defect injection technology. The method comprises: based on a detailed software design document, identifying at least one function in a program to be tested; generating a test design document based on possible defect locations related to the functions of the at least one identified function and defect types to be injected into the defect locations; searching for defect locations to be injected based on the generated test design document and the source code of the program; determining a defect injection method and defect type; and predicting the expected result of applying defect injection corresponding to the defect injection method and defect type to the searched location to generate a test case.

Description

Technical Field

[0001] The present disclosure relates to a vehicle functional safety testing device and a control method thereof, and more particularly, to a testing device capable of generating test cases based on a fault injection technology and a control method thereof. Background Art

[0002] The statements in this section merely provide background information related to the present disclosure and may not constitute prior art.

[0003] ISO 26262, a standard for functional safety of vehicles, recommends Fault Injection Test (FIT) as a method to determine whether the safety mechanism is operating normally when performing software unit testing and integrated testing. However, there are limitations in ensuring the reliability of fault injection testing for verifying the functional safety of software by simply standardizing the requirements for functional safety of software for vehicles.

[0004] In order to overcome this limitation, a method capable of generating test cases by applying software design documents and safety requirement documents derived in a design phase when performing defect injection testing of vehicle software may be required. Summary of the invention

[0005] Accordingly, the present disclosure is directed to a vehicle function test device and a control method thereof that substantially obviate one or more problems due to limitations and disadvantages of the related art.

[0006] The present disclosure provides a vehicle test device and a control method thereof that provide more convenient functions.

[0007] The present disclosure provides a testing device capable of generating test cases based on defect injection technology and a control method thereof.

[0008] A control method for a test device may include: based on a software detailed design document, identifying at least one function to be tested in a program to be tested; generating a test design document based on possible defect locations related to the functions of the identified at least one function to be tested and the defect type to be injected into the defect location; based on the generated test design document and the source code of the program to be tested, searching for the defect location to be injected among the extracted defect locations; determining a defect injection method and a defect type; and predicting an expected result of applying the defect injection corresponding to the defect injection method and the defect type to the searched defect location to generate a test case.

[0009] In another aspect of the present disclosure, a software testing device may include: a test scope determination unit, configured to extract the test scope from the program to be tested based on functions and calling relationships related to the security mechanism; a test design document generation unit, configured to generate a test design document including a defect location to be injected, a defect type, or a normal condition to be violated according to the test scope and at least one requirement document; and a test case generation unit, configured to generate a test case based on the source code of the program to be tested and the test design document.

[0010] Further areas of applicability will become apparent from the description provided herein.It should be understood that the description and specific examples are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order that the present disclosure may be fully understood, various forms of the present disclosure given by way of example will now be described with reference to the accompanying drawings, in which:

[0012] Figure 1 is a block diagram showing an example of a configuration of a test device of one form of the present disclosure;

[0013] Figure 2 is a view showing an example of a form of a program input through a user interface in one form of the present disclosure;

[0014] Figure 3 is a flow chart showing an example of a unit testing process performed by a testing device in one form of the present disclosure;

[0015] Figure 4 is a flow chart illustrating an example of a comprehensive testing process performed by a testing device in one form of the present disclosure;

[0016] Figure 5 is a view showing an example of the form of a test design document of one form of the present disclosure; and

[0017] Figure 6 is a view showing an example of the form of a test case of one form of the present disclosure.

[0018] The drawings described herein are for illustration purposes only and are not intended to limit the scope of the present disclosure in any way. DETAILED DESCRIPTION

[0019] The following description is merely exemplary in nature and is not intended to limit the present disclosure, application, or uses. It should be understood that throughout the drawings, corresponding reference numerals indicate the same or corresponding parts and features.

[0020] Unless otherwise specified, the terms "include" or "comprising" used herein should be interpreted not to exclude other elements but to further include these other elements. In addition, throughout the specification, the same reference numerals denote the same constituent elements.

[0021] In one form of the present disclosure, a test apparatus and a control method thereof are proposed for automatically generating necessary test cases by inputting requirement / design documents and program codes when performing a defect injection test for verifying the safety of software installed in a component of a vehicle.

[0022] In particular, in one form of the present disclosure, a test apparatus and a control method thereof are provided, which automatically generate meaningful test cases from requirement / design documents and program codes by text processing when performing defect injection testing of software based on AUTomotive Open System Architecture (AUTOSAR). Preferably, the requirement / design documents are written in a natural language.

[0023] First, refer to Figure 1 The configuration of a test device in one form of the present disclosure is described.

[0024] Figure 1 is a block diagram showing an example of a configuration of a test apparatus of one form of the present disclosure.

[0025] Reference Figure 1 A test device in one form of the present disclosure includes: a program code management unit 101, used to store / manage the code of the program to be tested; a requirement document management unit 102, used to store / manage the requirement document about the program to be tested; a test scope determination unit 103, used to extract the test scope from the program to be tested based on the functions and calling relationships related to the security mechanism; a test design document generation unit 104, used to generate a test design document including the defect location and defect type to be injected into the test and the normal state to be violated according to the test scope and the requirement document; and a test case generation unit 105, used to generate a test case 300 based on the program code and the test design document.

[0026] Here, the test device can receive or output information related to the test through the user interface 200. For example, the user interface 200 can obtain various information for generating test cases from an input device such as a keyboard or a mouse, and display / output a test design document, a result of generating a test case, and other content stored in the server through a display device or a printing device.

[0027] Hereinafter, various components of a testing device of one form of the present disclosure will be described in more detail.

[0028] First, the program code management unit 101 stores the code of the test program so that a specific defect injection location is included when a defect injection test case is generated based on the code. Here, the code of the test program can represent the source code. In this case, the source code of the software installed in the actual vehicle component (e.g., controller) will be verified, rather than just the model based on the system requirements, so that the availability and effectiveness of the test can be ensured.

[0029] Will refer to Figure 2 Table 1 and Table 1 describe the specific code management form of the program code management unit 101. Figure 2 is a view showing an example of a form of a program input through a user interface in one form of the present disclosure.

[0030] Reference Figure 2 , a program 400 including three functions 410, 420, and 430 may be input to the test apparatus through the user interface 200. Therefore, the program code management unit 101 may manage / store the program 400 input in the form shown in Table 1 below.

[0031] [Table 1]

[0032] OK Code 001_1 int var2; 001_2 g_var+=1; 001_3 var2 = FuncB(); 001_4 FuncC(var2); 002_1 return 5; 003_1 a=a+2;

[0033] In Table 1 above, the line item is stored in the form of "Function ID_Number of the line in the function", and the function ID represents the function ID in the software detailed design document. In short, it can be seen from Table 1 that in the software detailed design document, each function has a separate ID for management.

[0034] Return to reference Figure 1 , it is required that the document management unit 102 can manage / store all documents in the intermediate steps for generating the test case 300 and the documents obtained from the user in order to generate the test case 300, and can store information required for traceability between documents.

[0035] The test scope determination unit 103 can determine the scope of the entire program to be tested by using the software detailed design document stored in the requirement document management unit 102. The test scope can be determined based on the relevance to the safety mechanism, that is, based on whether the program corresponds to a function reflecting a technical safety requirement (TSR) and a function having a calling relationship with the function. Here, the technical safety requirement can be defined in the ISO 26262 standard.

[0036] The test design document generation unit 104 can search for a safety description (Safety Description, SD) using the software detailed design document about the functions included in the test scope. The test design document generation unit 104 adds the defect injection position to the test design document from the FIT related information corresponding to the SD. At this time, when the error type related to the SD does not occur at the injection position, the injection position is excluded. When the injection position is determined, the test design document generation unit 104 can add the defect type to be injected (injection details) to the test design document from the SD form based on the defect type system table (FIT defect). The specific form of the defect type system table is shown in Table 2 below.

[0037] [Table 2]

[0038]

[0039]

[0040] Referring to Table 2, a defect type system table (FIT defect) is defined by classifying defect types with individually assigned IDs into multiple categories. For example, the largest category is the test step, and the sub-defect type is defined by the test unit according to the defect occurrence location and the defect type category. Of course, the defect type system table is exemplary and is not necessarily the same as shown in Table 2.

[0041] When the defect type (injection details) to be injected is added, the test design document generation unit 104 can confirm the mechanism for performing search / solution when the defect occurs from the technical safety requirements (TSR) to finally generate the test design document. At this time, the test design document generation unit 104 can derive the mechanism for performing search / solution when the defect occurs from the TSR written in a natural language, the SDD to be described below, etc. through text processing.

[0042] Next, the test case generation unit 105 can generate a test case 300 based on the test design document generated by the test design document generation unit 104 and the program code stored in the program code management unit 101. The test case may include an ID, an injected defect (line, type, and code), and an expected result. Here, the injected fault line can be extracted by searching the injection position of the test design document in the program code, and the injected defect type can select one of generation (G) and mutation (M). The injected defect code can be generated to violate the normal state item of the test design document, and the expected result can be generated by the handling item of the test design document.

[0043] As shown in Table 2, testing can be mainly divided into unit testing and integrated testing. Unit testing can refer to the testing of a single function, and integrated testing can refer to the testing of two or more functions that are related to each other (e.g., call relationships). Figure 1 The configuration of the test setup is described in Figure 3 and Figure 4 Describe the unit testing and integration testing process.

[0044] Figure 3 is a flowchart illustrating an example of a unit test process performed by a test device of one form of the present disclosure.

[0045] In the description Figure 3 Before describing the sequence of the flowchart shown in FIG. 1 , input values ​​and output values ​​will first be described.

[0046] The software detailed design document refers to a software detailed design document (SDD) supplemented to facilitate the test target identification process and the subsequent test case generation process for defect injection testing. An example of the software detailed design document is shown in Table 3 below.

[0047] [Table 3]

[0048]

[0049] Referring to Table 3, the SDD may include a mapping structure regarding functions constituting the software, relevant technical safety requirements (TSR) information, and global variables, return statements, calling functions, and parameter information related to defect injection testing.

[0050] Preferably, the SDD is written based on the following considerations.

[0051] The software detailed design document must include a description of the internally designed safety mechanism (Safety Description (SD)) and the functional behavior of the software and must be written in a natural language, and the writing form of the SD is classified based on the AUTOSAR error types as shown in Table 4 below.

[0052] [Table 4]

[0053] AUTOSAR Error Types SD format Data Error Data value requirements Program flow error Procedure requirements Access Error Access address requirements Timing Error Timing Constraints Asymmetric Error Asymmetric requirements

[0054] The details of Table 4 can be defined as follows.

[0055] 1) Data value requirements

[0056] - SWC should define VAR1 ranging from C1 to C2.

[0057] -The value of VAR1 should not be greater (less) than C1.

[0058] 2) Procedure requirements

[0059] - Should ensure that VAR1 is read correctly by BSW / RTE.

[0060] - Should ensure proper conversion of VAR1 to CAN / SPI.

[0061] 3) Access address requirements

[0062] - Reading / writing of VAR1 should be done via BSW / RTE.

[0063] 4) Timing Constraint Requirements

[0064] - If a defect on VAR1 exceeding C1 is detected, the SWC shall set VAR1 on command.

[0065] 5) Asymmetric requirements

[0066] - Correct routing of output VAR1 should be ensured.

[0067] In the above definition, SWC represents software component, VAR# represents variable, C# represents constant, CAN / SPI represents function related to CAN / SPI interface, and BSW / RTE represents BSW / RTE layer function.

[0068] In addition, the defect type system table (FIT defect) is the same as described above with reference to Table 2.

[0069] Next, the technical safety requirement may represent a technical safety requirement (TSR) defined in the ISO 26262 standard. An example of the TSR is shown in Table 5 below.

[0070] [Table 5]

[0071]

[0072] Furthermore, the program code may refer to program code automatically generated by a model-based development support tool such as MATLAB or Simulink or directly written by a developer.

[0073] Reference Figure 3 In the unit test step, first, the test scope determination unit 103 can identify the software unit (i.e., function) as a unit test target of the software defect injection test (SW FIT) (S21). The test target is preferably a function that reflects the security mechanism in the function of the software component (Software Component, .c file). The identified test target can be stored / managed in the requirement document management unit 102 in the form of a FIT target system table.

[0074] Subsequently, the test design document generation unit 104 may extract the possible defect locations related to the functions of the unit functions (S22). Here, the possible defects may represent defects that cause the software to deviate from a safe state. Specifically, the test design document generation unit 104 may identify the safety mechanism and the global variables related to the safety mechanism in the function identified as the test target through the software detailed design document, and may extract the defects that may occur due to the pollution of the values ​​of the global variables (potential defect causes).

[0075] In addition, when it is confirmed that there is a safety mechanism in the system that is capable of searching for and resolving possible defects extracted in the previous step (S22), the test design document generation unit 104 can determine the applicable defect type from the types defined in the defect type system table (FIT defect) (for example, the 54 FIT defect types in Table 2) (S23).

[0076] Subsequently, the test design document generation unit 104 may confirm the state before defect injection (S24). Here, the state before defect injection refers to the state of the function or variable before defect injection, that is, the normal state, and the test case may be designed to deviate from the state. The state before defect injection may be confirmed by a software detailed design document (SDD), and a specific method may be configured in the form of confirming a normal state table as shown in Table 6 below.

[0077] [Table 6]

[0078]

[0079] Referring to Table 6, the normal state is defined by SD details based on SD form.

[0080] Next, the test design document generating unit 104 refers to the technical safety requirement specification written in the system level design step, and confirms whether there is a safety mechanism that can be searched / solved when a defect actually occurs (S25).

[0081] Through the above process ( S22 to S25 ), the test design document generating unit 104 can generate a test design document.

[0082] When generating the test design document, the test case generating unit 105 may search the program code for the defect location extracted when generating the test design document (S26).

[0083] When the defect position to be injected is searched, the test case generating unit 105 may determine the defect injection mode in mutation (M) and generation (G) as the compilation type defect injection mode (S27).

[0084] Next, the test case generation unit 105 may determine the details of the defect to be injected into the actual code (S28). Here, the injected defect is preferably designed to deviate from the normal state before the defect injection confirmed when generating the test design document.

[0085] Then, the test case generation unit 105 can predict the result of the system / software after the defect injection (S29). At this time, the defect injection is performed in the software implementing the safety mechanism, so the expected result can be the operation of the error handling mechanism.

[0086] Through the above process, the test case generating unit 105 can generate a FIT test case.

[0087] Next, we will refer to Figure 4 Describe the comprehensive testing process.

[0088] Figure 4 is a flow chart illustrating an example of a comprehensive testing process performed by a testing device of one form of the present disclosure.

[0089] because Figure 4 The process shown is similar to Figure 3 The unit testing process shown is different, so in order to simplify the description, only the differences will be described.

[0090] In the integrated test process, instead of the SDD applied to the unit test, the design document for each AUTOSAR layer is used as an input value of the test scope determination unit 103 and the test design document generation unit 104. Therefore, the function identification process (S21) can be replaced by a process (S31) of arranging functions having a calling relationship in the test target, and the process (S22) of extracting defect locations that may occur related to the functions of the unit functions can be replaced by a process (S32) of extracting defect locations that may occur when calling between functions.

[0091] The subsequent processes ( S33 to S39 ) correspond to the above-mentioned processes ( S23 to S29 ), respectively, and thus repeated descriptions will be omitted.

[0092] In the following, reference will be made to Figure 2 The procedure shown again describes the operation of the test device.

[0093] First, the tester receives the technical safety requirements (TSR) and the software detailed design document (SDD) through the user interface 200, and stores the TSR and SDD in the requirement document management unit 102. The TSR may have the form shown in Table 5, and the SDD may have the form shown in Table 3.

[0094] Similarly, the source code of the illustrated program may be stored in the program code management unit 101 through the user interface 200 , and the storage form may be converted into the form of Table 1 as described above.

[0095] In the case of unit testing, the test scope determination unit 103 may determine only FuncA() 410 that implements a safety mechanism (ie, reflects TSR) among the functions FuncA() 410 , FuncB() 420 , and FuncC() 430 as a test target.

[0096] In the case of integrated testing, the test scope determination unit 103 may determine the calling relationship with FuncA() that implements the safety mechanism (eg, the function call between FuncA() and FuncB() or the function call between FuncA() and FuncC()) as the test target.

[0097] In the case of unit testing, the test design document generation unit 104 may determine the global variable "g_var1" of the function FuncA() as a candidate for the injection position. Since the content described in the SDD corresponds to the "data value requirement" in the SD form, and a data error may occur in the global variable according to Table 2, the test design document generation unit 104 may select "g_var1" as the defect injection position.

[0098] In the case of integrated testing, the test design document generation unit 104 can determine the function call syntax FuncB() and the return statement "return5;" of FuncB() in the function call between FuncA() and FuncB() as candidates for the injection position, and determine the function call syntax FuncC() and the parameter "var2" in the function call between FuncA() and FuncC() as candidates for the injection position. Since the content described in the SDD corresponds to the "data value requirement", and according to Table 2, data errors can only occur in global variables, parameters, and return statements, FuncB() and FuncC() are excluded from the defect injection position.

[0099] Figure 5 2 shows the form of the test design document generated by the test design document generating unit 104 through the above process.

[0100] Figure 5 is a view showing an example of the form of a test design document of one form of the present disclosure.

[0101] Reference Figure 5In the case of unit testing 510, the test design document may define the ID, injection location, defect type, normal state, detection, and processing value of a single function; in the case of integrated testing 520, the test design document may define the ID, injection location, defect type, normal state, detection, and processing value of each of the two functions corresponding to the defect injection location in the functions having a calling relationship.

[0102] Next, we will refer to Figure 6 Description based on Figure 5 The operation of the test case generating unit 105 of the generated test design document is shown.

[0103] Figure 6 is a view showing an example of the form of a test case of one form of the present disclosure.

[0104] Reference Figure 6 In the case of the unit test 610, the test case generation unit 105 may determine a code as an injection defect code, by which the position "001_2" of "g_var" becomes an injection defect line related to "TS_001_1" of the test design document 510, and the value of g_var becomes -1 and 11 as boundary values ​​to violate the "normal state (0 to 10 range)" of the test design document. The expected result may become the processing item TSR_002 of the test design document.

[0105] In the case of the integrated test 620, the test case generation unit 105 can determine the code as the injection defect code, through which the position "002_1" of the return statement "return5;" becomes the injection defect line related to "TS_001_2" of the test design document 520, and the return value becomes 11 as a boundary value to violate the "normal state (not greater than 10)" of the test design document 520. The expected result can be changed to the processing item TSR_004 of the test design document. The test case generation process from "TS_001_3" of the test design document 520 is also similar to that of "TS_001_2", so the repeated description will be omitted.

[0106] In one form of the present disclosure, at least one of the program code management unit 101 and the requirement document management unit 102 of the test device may be replaced by a separate device, or may be separately implemented as a program recording device (memory, etc.) or an electronic control unit (ECU).

[0107] In addition, in addition to outputting automatically generated test cases, the test case generation unit 105 can also automatically execute and determine defect injection tests for program targets such as ECUs, can output the results of defect injection tests, and can perform smooth code modifications by recommending defect and safety logic when program errors occur due to lack of defect and fail and safe logic during defect injection.

[0108] In addition, Figure 3 or Figure 4 In the present invention, a defect pattern that has occurred mainly in vehicle software for mass-produced vehicles in the past can be input instead of the SDD, and the test design document generation unit 104 can be configured to not only confirm the existence of a search / solution mechanism when a defect occurs, but also recommend an appropriate search / solution mechanism when the search / solution mechanism is omitted.

[0109] The above-described forms of the present disclosure have the following effects.

[0110] The form of the present disclosure relates to a method and apparatus for generating test cases for AUTOSAR-based software, wherein test cases for confirming the operation of safety mechanisms in the source code can be automatically generated from a requirement (TSR, SD, etc.) document written in a natural language through text processing, thereby improving convenience.

[0111] In addition, in one form of the present disclosure, the reliability of the test process can be ensured and the development cycle can be shortened when the unit test and the integrated test of the AUTOSAR-based software are performed using the defect injection technology.

[0112] Furthermore, the types of defects that may occur in AUTOSAR-based software can be defined as AUTOSAR standards, the form of software safety requirements can be specified, so that requirements for subjective intervention can be prepared objectively and test cases can be automatically generated through text processing.

[0113] The present disclosure described above can be implemented as a computer-readable program stored in a computer-readable recording medium. A computer-readable medium can be any type of recording device that stores data in a computer-readable manner. Computer-readable media may include, for example, a hard disk drive (HDD), a solid state drive (SSD), a silicon disk drive (SDD), a read-only memory (ROM), a random access memory (RAM), a compact disk read-only memory (CD-ROM), a magnetic tape, a floppy disk, and an optical data storage device.

[0114] As is apparent from the above description, a test device in one form of the present disclosure constructed as described above is capable of verifying the safety of vehicle software more conveniently and reliably.

[0115] In particular, in one form of the present disclosure, test cases for confirming the operation of a security mechanism of a source code are automatically generated, so that the reliability of the test process when performing testing based on defect injection technology can be ensured and the development cycle can be shortened.

[0116] The description of the present disclosure is merely exemplary in nature and thus variations that do not depart from the essence of the present disclosure are intended to be within the scope of the present disclosure. Such variations will not be regarded as departing from the spirit and scope of the present disclosure.

Claims

1. A control method for a test device, comprising: Based on the software detailed design document, identifying at least one function in the program to be tested; generating a test design document based on a possible defect location associated with the identified functionality of the at least one function and a defect type to be injected into the defect location; Searching for the defect location to be injected based on the generated test design document and the source code of the program; Determining a defect injection method and the defect type; as well as predicting an expected result of applying a defect injection corresponding to the defect injection mode and the defect type to the searched defect location to generate a test case, Among them, generating test design documents includes: Based on the software detailed design document, confirm the normal state before the defect injection; and When a defect occurs, the search / resolution mechanism is confirmed based on the Technical Safety Requirements (TSR).

2. The method according to claim 1, wherein: Identifying at least one function comprises: In the case of unit testing, identify the unit function.

3. The method according to claim 2, wherein: Generating a test design document includes: The defect locations that may occur in relation to the identified functions of the unit functions are extracted.

4. The method according to claim 1, wherein: Identifying at least one function comprises: In the case of comprehensive testing, functions with calling relationships are organized.

5. The method according to claim 4, wherein: Generating a test design document includes: The defect locations that may occur when calling between the organized functions are extracted.

6. The method according to claim 1, wherein: The test case includes at least one of an identifier (ID), a line corresponding to the defect injection, the defect type, a defect code, and the expected result.

7. The method according to claim 6, wherein: The method comprises: The defect code is generated to violate the normal state.

8. The method according to claim 1, wherein: Identifying at least one function comprises: A function reflecting a security mechanism and a function having a calling relationship with the function reflecting the security mechanism are identified.

9. A non-transitory computer-readable recording medium storing a program for executing a control method of a test device, the method comprising: Based on the software detailed design document, identifying at least one function in the program to be tested; generating a test design document based on a possible defect location associated with the identified functionality of the at least one function and a defect type to be injected into the defect location; Searching for the defect location to be injected based on the generated test design document and the source code of the program; Determining a defect injection method and the defect type; as well as predicting an expected result of applying a defect injection corresponding to the defect injection mode and the defect type to the searched defect location to generate a test case, Among them, generating test design documents includes: Based on the software detailed design document, confirm the normal state before the defect injection; and When a defect occurs, the search / resolution mechanism is confirmed based on the Technical Safety Requirements (TSR).

10. A software testing device, comprising: processor; as well as a non-transitory memory for storing instructions executable by the processor, The processor is configured to: Extract the test scope from the program to be tested based on the functions and call relationships related to the security mechanism, generating a test design document including at least one of a defect location to be injected, a defect type, and a normal state to be violated based on the test scope and at least one requirement document, generating test cases based on the source code of the program to be tested and the test design document, searching for safety mechanisms in the test scope based on the software detailed design document, and The defect position to be injected is determined based on a defect type system table.

11. The testing device according to claim 10, wherein: The processor is further configured to manage the source code based on a function identifier in a software detailed design document and a line of a function corresponding to the function identifier.

12. The testing device according to claim 10, wherein: The processor is further configured to: in the case of unit testing, identify unit functions as the test scope; in the case of integrated testing, organize functions with call relationships and identify the organized functions as the test scope.

13. The testing device according to claim 12, wherein: The processor is further configured to extract, for the unit test, the defect locations that may occur in relation to the functions of the identified unit functions, and to extract, for the integrated test, the defect locations that may occur when calling between the organized functions.

14. The testing device according to claim 10, wherein: The processor is further configured to exclude the defect locations where no error type related to the safety mechanism occurs from the defect locations to be injected.

15. The testing device according to claim 10, wherein: The processor is further configured to identify a search / resolution mechanism from at least one requirement document written in a natural language through text processing when a defect occurs.

16. The testing device according to claim 10, wherein: The test case includes at least one of an identifier (ID), a defect injection line, the defect type, a defect code corresponding to the normal state to be violated, and an expected result.

Images