Test case generation device and test case generation method
The test case generation method automates the process of generating test case documents by analyzing test requirement documents with waveform diagrams, addressing the complexity and manual effort issues in existing methods, and achieving efficient and accurate test case generation.
Patent Information
- Application Number
- PCT/JP2024/030588
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-09-27
- Filing Date
- 2024-08-28
- Publication Date
- 2025-04-03
AI Technical Summary
Existing methods for generating test case documents in product development processes are complex and require manual effort, necessitating a simpler and automated process for generating test case text.
A test case generation method that reads a test requirement document containing a waveform diagram, analyzes parameter values and timing, selects appropriate functions for setting and determining parameter values, and generates a test case document with defined procedures and criteria.
Enables the automatic generation of test cases for product verification processes, reducing manual effort and human errors, while also reducing the time required for the entire test process.
Smart Images

Figure JP2024030588_03042025_PF_FP_ABST
Abstract
Description
Test case generation device and test case generation method
[0001] The present invention relates to a test case generation device and a test case generation method.
[0002] In the product development process, tests to verify the operation of a product are executed according to procedures described in test case documents. To reduce the man-hours required for such tests, technologies have been proposed that automate test execution, test result evaluation, and test report output. In addition, technologies have been proposed that automatically generate test case documents, which were previously created manually.
[0003] Japanese Patent Application Laid-Open No. 2015-49659
[0004] However, in the above-described technical example, in order to automatically generate a test case document, it is first necessary to generate a test model from a design specification document, and then generate a test case document using the test model.
[0005] Therefore, an object of the present invention is to automatically generate test case documents used in tests executed by a verification device in the product development process or the like, using a process that is simpler than conventional processes.
[0006] One aspect of the present invention is a test case generation method for generating a test case document that defines a procedure for executing a test on a verification device and criteria for judging the results of the test executed according to the procedure. The method includes reading a test requirements document that includes types of parameters used in the test and waveform diagrams showing changes in the values of the parameters over time, and analyzing the values of the parameters and the timing at which the values change. The method further includes selecting a function that sets the value of the parameter for a parameter identified as an input value of the test based on the type, and determining a procedure for executing the function based on the timing at which the value of the parameter changes. The method then includes selecting a function that determines whether the value of the parameter for a parameter identified as an output value of the test based on the type is equal to or exceeds an expected value, and determining the judging criteria using the function. The method further includes generating a test case document that includes the determined procedure and judging criteria.
[0007] According to one aspect of the present invention, a test case document used for a test executed by a verification device in a product development process or the like can be automatically generated by a process simpler than conventional methods.
[0008] FIG. 1 is a schematic diagram showing an example of a system for testing an electronic control unit. FIG. 2 is a block diagram showing an example of the functional configuration of a test case generation device. FIG. 3 is an explanatory diagram showing an example of a test requirement document. FIG. 4 is an explanatory diagram showing an example of a test case document (data setting and acquisition function). FIG. 5 is an explanatory diagram showing an example of a test case document (Action 0). FIG. 6 is an explanatory diagram showing an example of a test case document (Action 1). FIG. 7 is an explanatory diagram showing an example of a test case document (Action 2). FIG. 8 is an explanatory diagram showing an example of a test case document (Action 3). FIG. 9 is a flowchart showing an example of a test case generation process (overall processing). FIG. 10 is a flowchart showing an example of a test case generation process (data acquisition unit setting process). FIG. 11 is a flowchart showing an example of a test case generation process (operation procedure setting process). FIG. 12 is a flowchart showing an example of a test case generation process (operation procedure setting process). FIG. 13 is a flowchart showing an example of a test case generation process (judgment criterion setting process). FIG. 14 is a flowchart showing an example of a test case generation process (judgment criterion setting process). FIG. 15 is an explanatory diagram clearly showing blocks indicating the passage of time in an expected waveform diagram of a test requirement document. FIG. 16 is a block diagram showing an example of a hardware configuration of a test case generation device.
[0009] Hereinafter, embodiments of the present invention will be described with reference to the drawings. Note that the present invention is not limited to the embodiments described in this specification, and different embodiments and their modifications can be combined as appropriate.
[0010] 1 shows an example of a test execution system 1 that performs tests to verify the operation of electronic control units mounted on vehicles, etc. Note that the system to which the present invention is applied is not limited to electronic control units mounted on vehicles, etc., but can also test the functions of electronic control units mounted on industrial equipment, for example.
[0011] The test execution system 1 shown in FIG. 1 includes a test case generation device 100, a hardware-in-the-loop simulation (HILS) 200, and an electronic control device 300. The HILS 200 is a type of verification device that quantifies engine functions and behaviors of a vehicle, which is an example of a control target of the electronic control device 300, to enable simulations that mimic the actual vehicle. The HILS 200 tests the functions of the electronic control device 300 in accordance with a test case document 20 in which test content is described in a functional format (ATP (Auto Test Procedure) method) created based on a test requirement document 10 that defines test requirements for the electronic control device 300. In this embodiment, the test case generation device 100 automatically generates the test case document 20 used to test the electronic control device 300 based on the test requirement document 10. Both the test case generation device 100 and the HILS 200 can be configured as general-purpose computers equipped with a processor and a memory.
[0012] The HILS 200 receives control signals from the electronic control unit 300 in accordance with the test case description 20 generated by the test case generation device 100, and executes a simulation corresponding to the control signals. The HILS 200 then outputs the resulting system state to the electronic control unit 300. Furthermore, the HILS 200 sequentially exchanges control signals and system states with the electronic control unit 300, and tests whether the electronic control unit 300 can perform the required functions. The HILS 200 then outputs a test report 30 including the test results. The present invention relates to the test case generation device 100, in particular, of the system. The configuration of the test case generation device 100 and the processing executed by the test case generation device 100 will be described in detail below.
[0013] [Configuration of the Test Case Generation Device] FIG. 2 is a functional block diagram of the test case generation device 100. The test case generation device 100 includes a control unit 110 whose functions are realized when a program stored in a storage device is loaded and executed by a processor. The control unit 110 includes an analysis unit 111 and a generation unit 112. The analysis unit 111 reads and scans the data of the test requirements document 10 and analyzes the contents thereof. The generation unit 112 determines the contents to be written in the test case document 20 based on the contents of the test requirements document 10 analyzed by the analysis unit 111. The generation unit 112 then outputs data of the test case document 20 including the determined contents. The configurations of the test requirements document 10 and the test case document 20, as well as the processes executed by the analysis unit 111 and the generation unit 112, are described in detail below.
[0014] [Configuration of Test Requirements Document] FIG. 3 shows an example of a portion of the test requirements document 10 relevant to the description of this embodiment. The test requirements document 10 has columns for "Type" and "Variable Name." The test requirements document 10 also has expected waveform diagrams associated with parameters indicated by the variable names. The expected waveform diagram is a graph showing the change in parameter value over time, with the horizontal axis representing the time axis. Note that, in this specification, the term "value" simply refers to at least one of a character string and a numerical value. The length of the expected waveform diagram along the time axis is divided into blocks at predetermined time intervals (in FIG. 3, blocks are shown only at the top for ease of viewing the parameter values in the expected waveform diagram). As an example, in the expected waveform diagram of FIG. 3, one block corresponds to 0.5 seconds. The length of the elapsed time in the expected waveform diagram can be identified by the number of blocks corresponding to the length of the expected waveform diagram along the time axis.
[0015] The type is information indicating the nature of the parameter, and this information makes it possible to identify at least whether the parameter is an input value or an output value of the test. The type includes, for example, "HILS," which indicates that the parameter is an input value used in a function executed by the test. The type also includes "RAM" or "FLX (BUS)," which indicates that the parameter is a variable or communication data to which the test result value is output. Furthermore, there is also a type called "Diag," in which the parameter can be either an input value or an output value of the test. For example, the "Diag" type indicates a parameter value indicating whether a process for clearing a fault code beforehand when executing a test is on or off, and a parameter value for subsequently confirming that a predetermined value has been set for the fault code.
[0016] The variable name column contains information required for the test according to the parameter type. For example, if the type is "HILS," the variable name column may contain the name of the parameter to which the input value for the function executed in the test is set. If the type is "Diag," the variable name column may contain the name of the function itself to be executed. If the type is "RAM" or "FLX," the variable name column may contain the name of the parameter to which the output value of the test result is set. To the right of each variable name, an expected waveform diagram, which is a graph showing the change in the parameter value over time, is associated with the variable name. The expected waveform diagram is divided into multiple phases in units of actions based on predetermined criteria. Actions are divided based on criteria such as the start and end timing of an operation in the test, or the timing a predetermined time has elapsed since the operation ended. In the test, it is determined whether the output value of the test result is normal for each action. Dividing the test phases into multiple actions makes it possible to determine the output value multiple times in a series of tests.
[0017] When an expected waveform diagram shows changes over time in the value of a parameter to which an input value to a function executed in a test is set, the value to be set for that parameter is written at a position indicating the timing at which that value should be set. For example, the expected waveform diagram for a parameter of type "HILS" shown second from the top in FIG. 3 indicates that for the "IGNSW" parameter, "1" should be set in Action 0 at the start of the test. After a further time has passed, "0" is set to that parameter in Action 2. Thereafter, the same Action 2 indicates that "1" should be set to that parameter again.
[0018] Furthermore, the value of a ramp function parameter may also be described as the value to be set for the parameter. In this case, four parameters used by the ramp function (values before and after the change, the change width, and the change time) are described. For example, the expected waveform diagram of the parameter of type "HILS" shown third from the top in FIG. 3 indicates that the "Current_High" parameter is set to "2.5" at the start of the test. Then, when Action 1 is reached, the parameter is set to the ramp function parameters "2.5, 5, 0.1, 0.1."
[0019] On the other hand, if the expected waveform diagram shows a change over time in the value of a parameter to which the output value of the test result is set, the expected value that should be set for that parameter is written. If a change occurs in the expected value during the test, the changed value is written at the position indicating the timing of the change. For example, the expected waveform diagram of the parameter type "RAM" (seventh from the top in Figure 3) indicates that the "vx_PWM_OUT" parameter should be set to "3" in Action 0 at the start of the test. After a further time has passed, Action 1 indicates that the value of that parameter should change to "1." Then, Action 2 indicates that the value of that parameter should change again to "3."
[0020] For example, in the case of the "Diag" type, the expected waveform diagram can be written as follows: The expected waveform diagram for the "Diag" type, which is the fourth from the top in the expected waveform diagrams shown in Figure 3, shows that the "Clear_DTC" function, which clears the trouble code (DTC), is executed (changing from OFF to ON) in Action 0. The expected waveform diagram for the "Diag" type, which is the fifth from the top, shows that the trouble code should become "44171" during Action 1.
[0021] The expected waveform diagram may also include parameters of a response time judgment function that determines whether a response time required for a change in the value of one parameter to change the value of another parameter is normal. In this case, the parameter includes a string (Debounce Time) indicating that the parameter is used for the function. For example, the expected waveform diagram associated with the "RAM" type, the sixth expected waveform diagram from the top of FIG. 3 , shows that the "vx_High_AD_OUT" parameter is set to the response time judgment function parameters "4.81, Debounce Time, 80, 1." This indicates that the response time required from the time when the "vx_High_AD_OUT" parameter value rises to "4.81" until the "vx_PWM_OUT" parameter value, which is listed immediately below "vx_High_AD_OUT," reaches "1" is determined to be normal (80 ms or less).
[0022] 4 to 8 show an example of a test case definition document 20 generated by the test case generation device 100 based on the test requirements document 10 shown in FIG. 3. As shown in FIG. 4, the test case document 20 includes a data acquisition section that sets a function (e.g., "Monitor") that acquires parameter values before executing specific test procedures. The data acquisition section is composed of at least one line that associates a sequence number, a function (Function) that acquires parameter values, and a variable name (Variable_Name) that indicates the name of the function parameter.
[0023] 5 to 8, the test case document 20 includes an operational procedure that describes functions to be executed in a test using the HILS 200 and parameters to be used in the functions in the order in which the functions are executed. The test case document 20 also includes a judgment criterion (Expected Results) that includes information for judging whether the parameter values of the test results are normal. The test case document 20 is also divided into Action units based on the test requirements document 10. The lines between a header line indicating an Action (a line listing Action0, Action1, etc.) and the next "Excepted results" header line are operational procedures included in the Action listed in that header line. The lines between the "Excepted results" header line and the next Action header line are judgment criteria based on the results of performing the operational procedures for the Action. Figure 5 shows the lines for Action 0, Figure 6 shows the lines for Action 1, Figure 7 shows the lines for Action 2, and Figure 8 shows the lines for Action 3. In reality, these lines for Action 0 to Action 3 are generated consecutively, but for convenience of illustration, the figures are divided by Action. Note that in Figures 4 to 8, the header lines in the test case document 20 are shown shaded.
[0024] An operation procedure consists of at least one line, each of which is associated with a sequence number, a function (Function) used for the operation, a variable name (Variable_Name) indicating the name of the function's parameter, and a value (Value) to be set for that parameter. The variable name and value are set as needed only for the function that uses them. Examples of operation procedure functions include "Set," which sets a value to a parameter, "Ramp," which changes the parameter with a ramp response according to the value, "Clear_DTC," which clears a fault code (DTC), and "Wait," which waits for a predetermined period of time. While the sequence number of an operation procedure generally indicates the order of processing, consecutive lines without a "Wait" function in between do not necessarily need to be processed in the order of the sequence numbers in the test case document 20.
[0025] A criterion consists of at least one row, each associated with a sequence number, a function (Function) used to determine the value, a variable name (Variable_Name) indicating the name of the parameter to be determined, and a value (Value) to be set for that parameter. Examples of functions used for the criterion include "Check_Values," which verifies that the parameter is set to a predetermined value, and "Check_Accuracy_Action," which verifies the accuracy of the parameter (i.e., that the value has not changed). Other examples of criterion functions include "Check_DTC," which verifies that the fault code has been cleared, and "Check_DTC_Others_OR," which verifies that the fault code is set to a predetermined value. Another example of a criterion function is "Compare Transition," which is a response time judgment function. Because the criterion indicates the criteria for determining the test results for each action, unlike the operation procedure, the sequence number of the row does not necessarily indicate the chronological order in which the judgment is made.
[0026] [Test Case Generation Process] The test case generation process executed by the test case generation device 100 will be described below with reference to Figures 9 to 14. Each step of the test case generation process is realized by loading and executing a program in which instructions for the test case generation process are written.
[0027] 9 shows the overall process of the test case generation process. In step 1001 (shown as S1001 in the figure, and the same applies below), the control unit 110 reads data from the test requirement document 10. In step 1002, the control unit 110 executes a sub-module for data acquisition unit setting processing. In step 1003, the control unit 110 executes a sub-module for operation procedure setting processing. In step 1004, the control unit 110 executes a sub-module for judgment criterion setting processing.
[0028] In step 1005, the control unit 110 proceeds to the next Action described in the test requirement document 10. Specifically, this process involves scanning the Actions described in the expected waveform diagram of the test requirement document 10 along the time axis, and processing the portion of the expected waveform diagram to the right of the next detected string "Action." In step 1006, the control unit 110 determines whether all Actions have been processed. This determination can be made by determining whether the string "End" is detected after sequentially scanning and processing the Actions described in the expected waveform diagram of the test requirement document 10 along the time axis. If all Actions have been processed, the entire process ends (Yes); if not, the process returns to step 1003 (No).
[0029] 10 shows the processing of the submodule of the data acquisition unit setting processing executed in step 1002 of the overall processing. This processing is processing for generating the rows of the data acquisition unit shown in FIG. 4 described above. In step 1011, the analysis unit 111 scans the type of the test requirements document 10 and determines whether the character string "RAM" or "FLX" is identified. If the character string "RAM" or "FLX" is identified, the process proceeds to step 1012 (Yes); if not, the process proceeds to step 1013 (No).
[0030] In step 1012, the generation unit 112 selects the "Monitor" function as a function to be set in the function column of the test case document 20. Then, the generation unit 112 adds a row indicating that the "Monitor" function is to be executed to the judgment criteria for the Action currently being processed. Specifically, the generation unit 112 adds a row in which the "Monitor" function is set in the function column and the variable name associated with the type identified in step 1011 in the test requirement document 10 is set in the variable name column.
[0031] In step 1013, the analysis unit 111 determines whether the "Monitor" function has been selected for all "RAM" or "FLX" types in the expected waveform diagram. If selected, the data acquisition unit setting process ends (Yes); if not, the process returns to step 1011 (No).
[0032] 11 and 12 show the processing of the submodule of the operational procedure setting process executed in step 1003 of the overall processing. Note that, as an initial setting for this process, the scan position in the time axis direction of the expected waveform diagram of the test requirements document 10 is set to the leftmost block of the range of Actions to be processed. When scanning the expected waveform diagram in the following description of the operational procedure setting process, this scan position and the range to the right of this position in the time axis direction of the expected waveform diagram are targeted. Furthermore, among the parameter values listed in the expected waveform diagram, values that have already been identified are excluded from subsequent scans.
[0033] In step 1021, the analysis unit 111 scans the type of the test requirements document 10. Then, it determines whether the character string "HILS" is identified. If the character string "HILS" is identified, the process proceeds to step 1022 (Yes); if not, the process proceeds to step 1026 (No).
[0034] In step 1022, the analysis unit 111 scans the range of the currently processed Action in the expected waveform diagram associated with the type for which the character string "HILS" was identified in step 1021 in the test requirement document 10. The analysis unit 111 then determines whether a value (a value not for a Ramp response, for example, a single value) has been identified in the range. If a value has been identified, the process proceeds to step 1023 (Yes); otherwise, the process proceeds to step 1026 (No). In step 1023, the generation unit 112 selects the "Set" function as a function to be set in the function column of the test case document 20. The generation unit 112 then adds a line indicating that the "Set" function is to be executed to the operation procedure for the currently processed Action. Specifically, the generation unit 112 adds a row in which the “Set” function is set in the function column, the variable name associated with the type identified in step 1021 as the string “HILS” in the test requirements document 10 is set in the variable name column, and the value identified in step 1022 is set in the value column.
[0035] In step 1024, the analysis unit 111 determines whether a parameter value for a ramp response has been identified within the range of the currently processed Action in the expected waveform diagram scanned in step 1022. For example, this determination can be made by determining that a parameter value for a ramp response has been identified when the parameter value is four numeric values. If a value for a ramp response has been identified, the process proceeds to step 1025 (Yes); otherwise, the process proceeds to step 1026 (No). In step 1025, the generation unit 112 selects the "Ramp" function as a function to be set in the function column of the test case book 20. The generation unit 112 then adds a line indicating that the "Ramp" function is to be executed to the operation procedure for the currently processed Action. Specifically, the generation unit 112 adds a row in which the “Ramp” function is set in the function column, the variable name is set in the variable name column, and the value identified in step 1024 is set in the value column.
[0036] In step 1026, the analysis unit 111 determines whether the character string "Diag" is identified in the type of the test requirement document 10. If the character string "Diag" is identified, the process proceeds to step 1027 (Yes); otherwise, the process proceeds to step 1029 (No). In step 1027, the analysis unit 111 scans the range of the Action currently being processed in the expected waveform diagram associated with the type in which the character string "Diag" was identified in step 1026 in the test requirement document 10. The analysis unit 111 then determines whether a value is described in that range. If a value is described, the process proceeds to step 1028 (Yes); otherwise, the process proceeds to step 1029 (No). Note that it is possible to set a value to be excluded here (for example, the character string "OFF"). In step 1028, the generation unit 112 selects a function (e.g., "Clear_DTC") listed in the variable name column associated with the type identified in step 1026 as the character string "Diag" in the test requirement document 10 as the function to be set in the function column of the test case document 20. The generation unit 112 then adds a row indicating that the selected function will be executed to the operation procedure of the Action currently being processed. Specifically, the generation unit 112 adds a row in which the selected function is set in the function column and appropriate values are set in the variable name column and value column as necessary depending on the selected function.
[0037] In step 1029, the analysis unit 111 scans the types in the test requirements document 10 and scans the currently processed Action range in the expected waveform diagram associated with the type for which the character string "HILS" or "Diag" is identified. If the analysis unit 111 identifies a value in the range, it moves the scan position along the time axis to the block in which the value is located (or, if the value spans multiple blocks, to the leftmost block of the value). If no such value is identified, the analysis unit 111 moves the scan position to the block containing the next character string "Action" or "End." In step 1029, the analysis unit 111 counts the number of blocks shifted to the right along the time axis of the expected waveform diagram. If values are identified at the same position along the time axis in the expected waveform diagrams of multiple parameters, the count becomes 0.
[0038] In step 1030, the generation unit 112 selects the "Wait" function as a function to be set in the function column of the test case book 20. The generation unit 112 then adds a row indicating the execution of the "Wait" function to the operation procedure of the currently processed Action. Specifically, the generation unit 112 adds a row in which the "Wait" function is set in the function column and the elapsed time based on the number of blocks moved to the right, counted in step 1029, is set in the value column. The elapsed time can be calculated by multiplying the number of blocks moved to the right by the time per block. Note that if the number of blocks counted in step 1029 is 0, i.e., if operations using multiple parameters are written at the same position on the time axis of the expected waveform diagram, the "Wait" function is not set.
[0039] In step 1031, the analysis unit 111 determines whether the scan position in the time axis direction of the expected waveform diagram has reached the block containing the character string "Action" or "End," i.e., whether the scan has reached the right end of the area of the Action currently being processed. If the block has been reached, the process proceeds to step 1032 (Yes); if not, the process returns to step 1021 (No). In step 1032, the analysis unit 111 moves the scan position in the time axis direction of the expected waveform diagram to the leftmost block in the Action currently being processed.
[0040] 13 and 14 show the processing of the submodule of the criterion setting processing executed in step 1004 of the overall processing. In step 1041, the analysis unit 111 scans the type of the test requirements document 10. Then, it determines whether the character string "RAM" or "FLX" is identified in the type. If the character string "RAM" or "FLX" is identified, the process proceeds to step 1042 (Yes); if not, the process proceeds to step 1045 (No).
[0041] In step 1042, the analysis unit 111 scans the range of the currently processed Action in the expected waveform diagram associated with the type for which the character string "RAM" or "FLX" was identified in step 1041 in the test requirement document 10. The analysis unit 111 then determines whether a value has been identified in the range. If a value has been identified, the process proceeds to step 1043 (Yes); otherwise, the process proceeds to step 1044 (No). In step 1043, the generation unit 112 selects a function (Check_Values) that judges the value at the end of the Action as the function to be set in the function column of the test case document 20. The generation unit 112 then adds a line indicating that the "Check_Values" function is to be executed to the judgment criteria for the currently processed Action. Specifically, the generation unit 112 adds a row in which the “Check_Values” function is set in the function column, the variable name associated with the type identified in step 1041 as the string “RAM” or “FLX” is set in the variable name column, and the value identified in step 1042 is set in the value column.
[0042] In step 1044, the generation unit 112 selects a function (Check_Accuracy_Action) that determines whether a value has not changed throughout the entire Action as the function to be set in the function column of the test case document 20. Then, the generation unit 112 adds a row indicating that the "Check_Accuracy_Action" function is to be executed to the determination criteria for the Action currently being processed. Specifically, the generation unit 112 adds a row in which the "Check_Accuracy_Action" function is set in the function column, the variable name associated with the type identified in step 1041 as the character string "RAM" or "FLX" in the test requirement document 10 is set in the variable name column, and the value most recently identified within the range of Actions preceding the Action currently being processed in the expected waveform diagram associated with the variable name is set in the value column.
[0043] In step 1045, the analysis unit 111 determines whether a parameter including the string "Debounce Time," indicating that a response time judgment function is used, is identified in the range of the currently processed Action during scanning of the expected waveform diagram associated with the type. If the parameter is identified, the process proceeds to step 1046 (Yes); otherwise, the process proceeds to step 1047 (No). In step 1046, the generation unit 112 selects a response time judgment function (Compare Transition) as a function to be set in the function column of the test case book 20. The generation unit 112 then adds a line indicating that the function is to be executed to the judgment criteria for the currently processed Action. Specifically, the generation unit 112 adds a row in which the "Compare Transition" function is set in the function column, the variable name associated with the type identified in step 1041 as the character string "RAM" or "FLX" in the test requirements document 10 and the variable name associated with the type one level below that are set in the variable name column, and the value based on the parameter identified in step 1045 (the variable name of the parameter to be processed, the variable name of the parameter one level below, and the response time) are set in the value column. Note that the response time may be set in a separate column instead of in the value column.
[0044] In step 1047, the analysis unit 111 determines whether the character string "Diag" has been identified in the type of the test requirement document 10. If the character string "Diag" has been identified, the process proceeds to step 1048 (Yes); if not, the process proceeds to step 1053 (No). In step 1048, the analysis unit 111 scans the range of the Action currently being processed in the expected waveform diagram associated with the type in which the character string "Diag" was identified in step 1047 in the test requirement document 10. The analysis unit 111 then determines whether a value has been identified in that range. If a value has been identified, the process proceeds to step 1049 (Yes); if not, the process proceeds to step 1053 (No).
[0045] In step 1049, the analysis unit 111 determines whether "Clear_DTC" is written in the variable name associated with the type identified in step 1047 as the character string "Diag" in the test requirement document 10. If "Clear_DTC" is written, the process proceeds to step 1050 (Yes); otherwise, the process proceeds to step 1051 (No). In step 1050, the generation unit 112 selects a function (Check_DTC) that checks whether the fault code has been cleared as the function to be set in the function column of the test case document 20. The generation unit 112 then adds a row indicating that the function is to be executed to the judgment criteria for the Action currently being processed. Specifically, the generation unit 112 adds a row in which the "Check_DTC" function is set in the function column and a row in which "NA," indicating that the value has been cleared, is set in the value column.
[0046] In step 1051, the analysis unit 111 determines whether "Read_DTC_Pcode" is described in the variable name associated with the type identified in step 1047 as the character string "Diag" in the test requirement document 10. If "Read_DTC_Pcode" is described, the process proceeds to step 1052 (Yes); otherwise, the process proceeds to step 1053 (No). In step 1052, the generation unit 112 selects a function (Check_DTC_Others_OR) that verifies that the failure code is a predetermined value as a function to be set in the function column of the test case document 20. The generation unit 112 then adds a line indicating the execution of this function to the operation procedure of the currently processed Action. Specifically, the generation unit 112 adds a line in which the "Check_DTC_Others_OR" function is set in the function column and the value identified by the scan in step 1048 is set in the value column. In step 1053, the analysis unit 111 determines whether or not a judgment function has been selected for all of the types "RAM," "FLX," and "Diag" in the expected waveform diagram. If selected, the judgment criterion setting process ends (Yes); if not, the process returns to step 1041 (No).
[0047] [Specific Example of Test Case Generation Process] Here, a specific example will be described of how the test case document 20 is generated from the expected waveform diagram of the test requirement document 10 by the above-mentioned test case generation process, particularly the operation procedure setting process and the judgment criterion setting process. Figure 15 shows the blocks and elapsed time for each predetermined time period in the expected waveform diagram for Action 0 and Action 1 in the test requirement document 10 illustrated in Figure 3. Below, a specific example of the test case generation process will be described using Action 0 and Action 1 in the test requirement document 10 of Figure 11 and the test case documents 20 of Figures 5 and 6 as examples.
[0048] <Operation Procedure Setting Process for Action 0> First, in the test requirement document 10 shown in FIG. 11 , the value of the parameter of the type "HILS" that is the first from the top is entered as "12" in the first block of the expected waveform diagram. Therefore, the generation unit 112 generates the first line of the operation procedure of the test case document 20 in FIG. 5 by setting the function to "Set," the variable name to "Battery_Vol," and the value to "12." Next, in the test requirement document 10, the value of the parameter of the type "HILS" that is the second from the top is entered as "1" in the first block of the expected waveform diagram. Therefore, the generation unit 112 generates the second line of the operation procedure of the test case document 20 in FIG. 5 by setting the function to "Set," the variable name to "IGNSW," and the value to "1." Next, in the test requirement document 10, the value of the parameter of the type "HILS" that is the third from the top is entered as "2.5" in the first block of the expected waveform diagram. Therefore, the generation unit 112 generates the third line of the operation procedure of the test case document 20 in FIG. 5 with the function set to "Set", the variable name set to "Current_High", and the value set to "2.5".
[0049] Next, in the test requirements document 10, the parameter value of the fourth type from the top, "Diag," is written as "ON" in the fourth block of the expected waveform diagram. Here, one block in the expected waveform diagram corresponds to 0.5 seconds. Therefore, the generator 112 first generates the fourth line of the operation procedure in the test case document 20 in FIG. 5 by setting the function to "Wait" and the value to "2" (0.5 seconds x 4 blocks). Then, since the variable name of the fourth type from the top, "Diag," is written as "Clear_DTC," the generator 112 sets the function to "Clear_DTC" and generates the fifth line of the operation procedure in the test case document 20 in FIG. 5. Furthermore, in the expected waveform diagram, there are eight blocks from the execution of "Clear_DTC" to the end of Action 0, and no other parameter values are written. Therefore, the generation unit 112 sets the function to "Wait" and the value to "4" (0.5 seconds x 8 blocks), and generates the sixth line of the operation procedure of the test case document 20 in FIG.
[0050] <Process for Setting Judgment Criteria for Action 0> In the test requirement document 10, the value of the parameter of type "RAM" (sixth from the top) is entered as "2.5" in Action 0 of the expected waveform diagram. Therefore, the generation unit 112 generates the first row of the judgment criteria for the test case document 20 in FIG. 5 by setting the function to "Check_Values," the variable name to "vx_High_AD_OUT," and the value to "2.5." Next, in the test requirement document 10, the value of the parameter of type "RAM" (seventh from the top) is entered as "3" in Action 0 of the expected waveform diagram. Therefore, the generation unit 112 generates the second row of the judgment criteria for the test case document 20 in FIG. 5 by setting the function to "Check_Values," the variable name to "vx_PWM_OUT," and the value to "3." Next, in the test requirement document 10, the value of the parameter of type "FLX" (eighth from the top) is entered as "3" in Action 0 of the expected waveform diagram. Therefore, the generation unit 112 generates the third row of the judgment criteria in the test case document 20 in Figure 5 by setting the function to "Check_Values," the variable name to "State_Number_Output," and the value to "3." Here, in the test requirements document 10, the value of the parameter of type "Diag," which is the fourth from the top, is written as "ON" in the fourth block of the expected waveform diagram, and "Clear_DTC" is written in the variable name column. Therefore, the generation unit 112 generates the fourth row of the judgment criteria in the test case document 20 in Figure 5 by setting the function to "Check_DTC" and the value to "NA."
[0051] <Operation Procedure Setting Process for Action 1> In the test requirement document 10, the value of the parameter of type "HILS," which is the third parameter from the top, is described as "2.5, 5, 0.1, 0.1" in the first block of the expected waveform diagram. Therefore, the generation unit 112 generates the first line of the operation procedure in the test case document 20 of FIG. 6 by setting the function to "Ramp," the variable name to "Current_High," and the value to "2.5, 5, 0.1, 0.1." Next, in the test requirement document 10, the value of the parameter of type "Diag," which is the fifth parameter from the top, is described as "44171" in the fourth block from the execution of the Ramp function in the expected waveform diagram. Therefore, the generation unit 112 first generates the second line of the operation procedure in the test case document 20 of FIG. 5 by setting the function to "Wait" and the value to "2" (0.5 seconds x 4 blocks). Then, because "Read_DTC_Pcode" is listed as the variable name for the fifth type from the top, "Diag," the generator 112 generates the third line of the operation procedure in the test case book 20 in FIG. 6 with "Read_DTC_Pcode" as the function. Furthermore, in the expected waveform diagram, there are four blocks from the execution of "Read_DTC_Pcode" to the end of Action 1, and no other parameter values are listed. Therefore, the generator 112 generates the fourth line of the operation procedure in the test case book 20 in FIG. 6 with "Wait" as the function and "2" (0.5 seconds x 4 blocks).
[0052] <Process for Setting Judgment Criteria for Action 1> In the test requirement document 10, the value of the seventh parameter from the top, type "RAM," is entered as "1" in Action 1 of the expected waveform diagram. Therefore, the generation unit 112 generates the first row of the judgment criteria for the test case document 20 in FIG. 6 by setting the function to "Check_Values," the variable name to "vx_PWM_OUT," and the value to "1." Next, in the test requirement document 10, the value of the eighth parameter from the top, type "FLX," is entered as "5" in Action 1 of the expected waveform diagram. Therefore, the generation unit 112 generates the second row of the judgment criteria for the test case document 20 in FIG. 6 by setting the function to "Check_Values," the variable name to "State_Number_Output," and the value to "5." Next, in the test requirement document 10, the value of the fifth parameter from the top, type "Diag," is entered as "44171" in Action 1 of the expected waveform diagram. Since the variable name of this type "Diag" is "Read_DTC_Pcode," the generation unit 112 sets the function to "Check_DTC_Others_OR" and the value to "44171," thereby generating the third row of the judgment criteria in the test case book 20 of FIG. 6 . Furthermore, in Action 1, the expected waveform diagram of the parameter of the type "RAM," which is the sixth from the top, lists the values of "4.81, Debounce Time, 80, 1," which are parameters of the response time judgment function. Therefore, the generation unit 112 sets the function to "Compare Transition," the variable names to "vx_High_AD_OUT, vx_PWM_OUT," and the values to "4.81, 1 80 (ms)," thereby generating the fourth row of the judgment criteria in the test case book 20 of FIG. 6 .
[0053] We will not provide specific examples of Action1 and Action2, but in a manner similar to the above specific example, it is possible to generate a test case document 20 from a test requirements document 10 by using the operating procedure setting process and the judgment criteria setting process.
[0054] Effects, Modifications, and the like of the Present Embodiment In tests to verify product operation during the product development process, the increasing number of tests due to the recent increase in system complexity has tended to increase the burden of testing work and lengthen the time required for the entire testing process. Against this technical background, according to the present embodiment, in testing the electronic control unit 300 using the HILS 200, the test case document 20 is automatically generated based on information described in the expected waveform diagram in the test requirements document 10. This significantly reduces the amount of work required for designers and others to create the test case document 20 by referring to the test requirements document 10. As a result, the time required for the entire testing process is also shortened. Furthermore, according to the present embodiment, human error can be reduced compared to manually creating the test case document 20 based on the test requirements document 10. This also makes it possible to improve the accuracy of the test case document 20.
[0055] Furthermore, according to this embodiment, even if a test is divided into multiple actions, it is possible to generate a test case book 20 that allows the test results to be confirmed for each action. While the above embodiment describes the generation of a test case book 20 for a test that includes multiple actions, it is also possible to generate a test case book 20 for a test that includes only one action. Furthermore, according to this embodiment, even if the test content includes a ramp function or a response time judgment function, a test case book 20 in which the procedure and judgment criteria are appropriately described is generated. Furthermore, even if both an operation to clear a fault code and subsequent verification that an expected value is set for the fault code are performed, as in the example of the "Diag" type, a test case book 20 in which both the procedure and judgment criteria are described is generated.
[0056] In this embodiment, the elapsed time along the time axis is determined based on the number of blocks divided into predetermined time intervals. However, this method is merely an example, and it is possible to determine the elapsed time based on the length along the time axis even if the expected waveform diagram is not divided into blocks. Furthermore, when selecting a function to be used in an operating procedure or a function to be used in a judgment criterion, the generation unit 112 may refer to a library in which the function to be selected is associated with conditions such as information written in parameter types and variable names, the presence or absence of values in the expected waveform diagram, etc. Such library data can be stored, for example, in a storage unit included in the test case generation device 100 or in an external storage unit accessible from the test case generation device 100.
[0057] Although not illustrated or described in this embodiment, if the test requirements document 10 includes information indicating the unit of each parameter value, the line corresponding to that parameter in the test case document 20 may also include information indicating the unit. The parameter value may be, for example, seconds or microseconds, or volts (V), depending on the nature of the parameter value. Furthermore, the functions listed in the type and variable name columns in the test requirements document 10 are not limited to those exemplified above. In the data acquisition unit setting process, operation procedure setting process, and judgment criterion setting process described in this embodiment, it is also possible to further set conditions based on the type, variable name, and values in the expected waveform diagram, and to further perform a process of setting a predetermined function when the conditions are met.
[0058] 16 shows an example of the hardware configuration of a computer that constitutes the test case generation device 100 according to this embodiment. The test case generation device 100 includes a processor 910, a memory 920, a storage 930, a portable storage medium drive 940, an input / output device 950, and a communication interface 960.
[0059] The processor 910 includes a control unit, an arithmetic unit, an instruction decoder, etc., and the execution unit executes arithmetic and logic operations using the arithmetic unit in accordance with program instructions decoded by the instruction decoder and control signals output from the control unit. The processor 910 also includes a control register that stores various information used for control, a cache that can temporarily store the contents of previously accessed memory 920, etc. The processor 910 may also be configured with multiple CPU (Central Processing Unit) cores.
[0060] The memory 920 is a storage device such as a random access memory (RAM), and serves as a main memory into which programs executed by the processor 910 are loaded and in which data used for processing by the processor 910 is stored. The storage 930 is a storage device such as a hard disk drive (HDD) or flash memory, and stores programs and various data. The portable storage medium drive 940 is a device that reads data and programs stored in a portable storage medium 970. The portable storage medium 970 is, for example, a magnetic disk, an optical disk, a magneto-optical disk, or a flash memory. The processor 910 executes programs stored in the storage 930 or the portable storage medium 970 in cooperation with the memory 920 and the storage 930. The programs executed by the processor 910 and the data to be accessed may be stored in another device capable of communicating with the information processing device. For example, the test requirements document 10 and the test case document 20 may be stored in the storage 930 included in the test case generation device 100. On the other hand, the test requirements document 10 and the test case document 20 can also be stored in the storage of another device. In this case, these data can be accessed via communication from the test case generation device 100. Furthermore, the test requirements document 10 and the test case document 20 can also be stored in a portable storage medium 970.
[0061] The input / output device 950 is, for example, an input means such as a touch panel or keyboard, and an output means such as a display, which accepts operational commands from a user and outputs the results of processing by the information processing device. The communication interface 960 includes, for example, a communication module, a LAN card, a radio frequency receiver and transmitter, and an optical receiver and transmitter, and enables data communication with the outside. The components of the information processing device described above are connected by a bus 980.
[0062] Furthermore, a person skilled in the art will easily understand that new embodiments can be created by omitting parts of the technical ideas of the various above-described embodiments, combining parts of them appropriately, or replacing parts of them with well-known technology.
[0063] 10: Test requirement document, 20: Test case document, 100: Test case generation device, 200: HILS (verification device), 111: Analysis unit, 112: Generation unit
Claims
1. A test case generation device that generates a test case document that defines a procedure for executing a test on a verification device and judgment criteria for the results of the test executed according to the procedure, comprising: an analysis unit that reads a test requirements document including a type of parameter used in the test and a waveform diagram showing the change in value of the parameter over time, and analyzes the value of the parameter and the timing at which the value changes; and a generation unit that selects a function for setting the value of the parameter for a parameter identified by the type as an input value of the test, and determines a procedure for executing the function based on the timing at which the value of the parameter changes, while selecting a function for determining whether the value of the parameter is an expected value for a parameter identified by the type as an output value of the test, and determines the judgment criteria using the function, and generates a test case document including the procedure and the judgment criteria determined.
2. The test case generation device of claim 1, wherein the waveform diagram includes a character string or a numerical value indicating the value of the parameter at a position on the time axis of the waveform diagram corresponding to the timing at which the value of the parameter changes, and the analysis unit analyzes the timing at which the value of the parameter changes based on the position at which the character string or numerical value is identified in the waveform diagram.
3. The test case generation device of claim 1, wherein the waveform diagram is divided into a plurality of phases based on a predetermined criterion, the analysis unit analyzes the parameter values and the timing at which the values change for each phase, and the generation unit generates the test case book in which the procedures and the judgment criteria are set for each phase.
4. The test case generation device of claim 1, wherein the waveform diagram has four numerical values indicating the value of the parameter before and after the change, the amount of change, and the time of change at the position of the timing at which the ramp function should be executed, and the generation unit selects the ramp function when the value of the parameter set in the waveform diagram is four numerical values.
5. The test case generation device of claim 1, wherein the waveform diagram includes a character string indicating a response time judgment function at a timing position where the response time judgment function should be executed to determine whether the response time until the value of one variable changes in response to a change in the value of another variable is normal, and the generation unit selects the response time judgment function when the value of the parameter set in the waveform diagram includes the character string indicating the response time judgment function.
6. The test case generation device of claim 1, wherein the waveform diagram is divided into blocks of a predetermined time each in at least a time axis direction, and the analysis unit identifies the time during which the value of the parameter is held or the time until the value of the parameter changes based on the number of blocks in the time axis direction of the waveform diagram.
7. The test case generation device according to claim 1, wherein the verification device verifies the operation of an electronic control device mounted in a vehicle, and the waveform diagram represents the change over time in the value of a parameter assuming that the vehicle is in a fault state.
8. A test case generation method for generating a test case document that defines a procedure for executing a test using a verification device and criteria for judging the results of a test executed according to the procedure, comprising the steps of: reading a test requirements document that includes the types of parameters used in the test and a waveform diagram showing the changes in the values of the parameters over time, and analyzing the values of the parameters and the timing at which the values change; selecting a function that sets the value of the parameter for the parameter identified by the type as an input value of the test, and determining a procedure for executing the function based on the timing at which the value of the parameter changes, while selecting a function that judges whether the value of the parameter is an expected value for the parameter identified by the type as an output value of the test, and determining the judging criterion using the function; and generating a test case document that includes the procedures and judging criteria determined.
Citation Information
Patent Citations
ECU evaluation device, computer program, and ECU evaluation method
JP2015005189A
Evaluation pattern generation device
JP2020101911A
Verification system, verification device, and vehicle control device
WO2017038290A1