Test case automatic scripting method and device, equipment and storage medium

Abstract

The invention discloses an automatic scripting method and device for a test case, equipment and a storage medium, and relates to the technical field of automobile electric control testing, and the method comprises the steps: obtaining the test case, a variable mapping file and a basic action library; obtaining a variable mapping relation according to the test case or the variable mapping file; screening the test cases based on a preset text matching rule to obtain a target test case; and converting the target test case according to a preset packaging interface, the variable mapping relationship and the basic action library to obtain a target test script executable by a target platform. According to the method, the test case is automatically converted into the target test script by using the preset test script generation tool by standardizing the table format and the statement format, so that the test case is quickly and automatically scripted, and the test efficiency is improved.

Description

Technical Field

[0001] This application relates to the technical field of automotive electronic control testing, and particularly to an automatic scripting method, device, equipment, and storage medium for test cases. Background Technique

[0002] With the rapid development of automotive electronic technology and the continuous improvement of automotive functions, more and more electronic control units are applied to automobiles. As a result, the software quality of electronic control units becomes increasingly important. The rapid iteration of software and the shortening of the software life cycle pose higher requirements for the software testing of electronic control units. Automation has become an efficiency improvement means that has to be used in the field of electronic control testing. In the field of automotive electronic control testing, especially in the HIL testing field of controllers, ECU-TEST is the most widely used automated testing platform, which can simultaneously call the tool chain software of multiple HIL system suppliers that comply with the ASAM specification (such as NI VeriStand, dSpace ControlDesk, ETAS INCA, Vector CANoe / CANape, etc.) to complete automated testing.

[0003] During the actual testing process, testers generally first compile test cases in Excel according to the software function specifications. They generally list the test descriptions and the variables and their variable values to be set and monitored according to the test steps. Then, testers manually write in the ECU-TEST automation tool according to the Excel-format test cases to convert the test cases into executable test scripts (or test sequences, which are *.pkg in ECU-TEST). In this process, manually writing Excel-format test cases into test scripts is inefficient and error-prone. At the same time, these manually written test scripts must also be debugged in a real HIL bench environment to ensure their normal execution, which requires long-term occupation of bench resources and software and hardware resources, etc.

[0004] Therefore, how to automatically convert test cases into ECU-TEST automation scripts is an urgent problem to be solved at present. Summary of the Invention

[0005] The main purpose of this application is to provide an automatic scripting method, device, equipment, and storage medium for test cases, aiming to solve the technical problem of how to automatically convert test cases into ECU-TEST automation scripts.

[0006] To achieve the above object, this application proposes an automatic scripting method for test cases, and the method includes:

[0007] Obtain test cases, variable mapping files, and basic action libraries;

[0008] Obtain a variable mapping relationship according to the test case or the variable mapping file;

[0009] Screen the test cases based on a preset text matching rule to obtain target test cases;

[0010] Convert the target test cases according to a preset encapsulation interface, the variable mapping relationship, and the basic action library to obtain target test scripts executable on the target platform.

[0011] In one embodiment, the step of screening the test cases based on a preset text matching rule to obtain target test cases includes:

[0012] Obtain test step data and expected result data according to the test case;

[0013] Obtain a statement format specification according to a preset text matching rule;

[0014] Screen the test step data and the expected result data according to the statement format specification to obtain target test step data and target expected result data;

[0015] Obtain target test cases based on the test case, the target test step data, and the target expected result data.

[0016] In one embodiment, the step of screening the test step data and the expected result data according to the statement format specification to obtain target test step data and target expected result data includes:

[0017] Obtain a first format specification and a second format specification according to the statement format specification;

[0018] Screen the test step data according to the first format specification to obtain target test step data;

[0019] Screen the expected result data according to the second format specification to obtain target expected result data.

[0020] In one embodiment, the step of screening the expected result data according to the second format specification to obtain target expected result data includes:

[0021] Obtain a variable comparison specification, an action library specification, and a delay operation specification according to the second format specification;

[0022] Screen the expected result data according to the variable comparison specification, the action library specification, and the delay operation specification to obtain target expected result data.

[0023] In one embodiment, before the step of screening the target expected result data from the expected result data according to the variable comparison specification, the action library specification, and the delay operation specification, the method further includes:

[0024] Obtaining a preset time specification, range specification, and enumeration specification;

[0025] Adding the time specification, the range specification, and the enumeration specification to the variable comparison specification to obtain a target variable comparison specification;

[0026] Updating the variable comparison specification according to the target variable comparison specification.

[0027] In one embodiment, the step of obtaining the variable mapping relationship according to the test case or the variable mapping file includes:

[0028] When the variable mapping file is a variable mapping relationship table, converting according to the variable mapping relationship table to obtain a target global mapping file;

[0029] Or,

[0030] Extracting an initial global mapping file according to the test case, and mapping the initial global mapping file according to a preset bench to obtain a target global mapping file;

[0031] Obtaining the variable mapping relationship according to the target global mapping file.

[0032] In one embodiment, after the step of screening the test case based on a preset text matching rule to obtain a target test case, the method further includes:

[0033] Obtaining the configuration function of the script generation tool;

[0034] When the waveform drawing function in the configuration function is in an active state, saving the variable data in the target test case, and drawing a waveform diagram according to the variable data.

[0035] In addition, to achieve the above object, the present application also proposes a test case automatic scripting device, the device includes:

[0036] A data acquisition module, configured to acquire test cases, variable mapping files, and a basic action library;

[0037] A variable mapping module, configured to obtain a variable mapping relationship according to the test case or the variable mapping file;

[0038] A matching and screening module, configured to screen the test case based on a preset text matching rule to obtain a target test case;

[0039] A script conversion module, configured to convert the target test case according to a preset encapsulation interface, the variable mapping relationship, and the basic action library, so as to obtain a target test script executable on a target platform.

[0040] In addition, to achieve the above object, the present application further provides a test case automatic scripting device, where the device includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the test case automatic scripting method as described above.

[0041] In addition, to achieve the above object, the present application further provides a storage medium, where the storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium, and when the computer program is executed by a processor, the steps of the test case automatic scripting method as described above are implemented.

[0042] In addition, to achieve the above object, the present application further provides a computer program product, where the computer program product includes a computer program, and when the computer program is executed by a processor, the steps of the test case automatic scripting method as described above are implemented.

[0043] The present application provides a test case automatic scripting method, and the method of the present application includes: obtaining a test case, a variable mapping file, and a basic action library; obtaining a variable mapping relationship according to the test case or the variable mapping file; screening the test case based on a preset text matching rule to obtain a target test case; and converting the target test case according to a preset encapsulation interface, the variable mapping relationship, and the basic action library to obtain a target test script executable on a target platform. In summary, the present application standardizes the table format and statement format, and uses a preset test script generation tool to automatically convert the test case into a target test script, realizing the rapid automatic scripting of the test case and improving the test efficiency. Description of the Drawings

[0044] The drawings here are incorporated into the specification and form a part of this specification, showing embodiments consistent with the present application, and are used together with the specification to explain the principles of the present application.

[0045] To more clearly illustrate the technical solutions in the embodiments of the present application or in the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, for those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0046] Figure 1 It is a schematic flowchart of the first embodiment of the test case automatic scripting method of the present application;

[0047] Figure 2 This is a schematic diagram of the main interface of the host computer of the script generation tool in an embodiment of the method for automatically scripting test cases of this application;

[0048] Figure 3 This is a schematic diagram of the configuration interface of the host computer of the script generation tool in an embodiment of the method for automatically scripting test cases of this application;

[0049] Figure 4 This is a schematic flow diagram provided by the second embodiment of the method for automatically scripting test cases of this application;

[0050] Figure 5 This is a schematic diagram of the working process from test cases to scripts in an embodiment of the method for automatically scripting test cases of this application;

[0051] Figure 6 This is a schematic diagram of the conversion process from test cases to scripts in an embodiment of the method for automatically scripting test cases of this application;

[0052] Figure 7 This is a schematic diagram of the module structure of the test case automatic scripting device in an embodiment of this application;

[0053] Figure 8 This is a schematic diagram of the device structure of the hardware operating environment involved in the method for automatically scripting test cases in an embodiment of this application.

[0054] The implementation, functional features, and advantages of the purpose of this application will be further described with reference to the embodiments and the accompanying drawings. Detailed implementation manners

[0055] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not used to limit this application.

[0056] In order to better understand the technical solutions of this application, the following will be described in detail in conjunction with the accompanying drawings of the specification and the specific implementation manners.

[0057] The main solution of the embodiments of this application is: obtaining test cases, variable mapping files, and basic action libraries; obtaining variable mapping relationships according to the test cases or the variable mapping files; screening the test cases based on preset text matching rules to obtain target test cases; and converting the target test cases according to preset encapsulation interfaces, the variable mapping relationships, and the basic action libraries to obtain target test scripts executable on the target platform.

[0058] With the rapid development of automotive electronic technology and the continuous improvement of automotive functions, more and more electronic control units are being applied to vehicles. As a result, the software quality of electronic control units has become increasingly important. The rapid iteration of software and the shortening of the software life cycle have put forward higher requirements for the software testing of electronic control units. Automation has become an essential means to improve efficiency in the field of electronic control testing. In the field of automotive electronic control testing, especially in the HIL testing field of controllers, ECU-TEST is the most widely used automated testing platform, which can simultaneously call the tool chain software of multiple HIL system suppliers that comply with the ASAM specification to complete automated testing.

[0059] In the actual testing process, testers generally first prepare test cases in Excel according to the software function specifications. Generally, according to the test steps, the test description and the variables and their variable values to be set and monitored are included. Then, the testers manually write in the ECU-TEST automation tool according to the Excel-format test cases to convert the test cases into executable test scripts. In this process, manually writing Excel-format test cases into test scripts is inefficient and error-prone. At the same time, these manually written test scripts must also be debugged in a real HIL bench environment to ensure their normal execution, which requires long-term occupation of bench resources and software and hardware resources. Therefore, how to automatically convert test cases into ECU-TEST automation scripts is an urgent problem to be solved at present.

[0060] This application standardizes the table format and statement format, and uses a preset test script generation tool to automatically convert test cases into target test scripts, realizing the rapid and automatic scripting of test cases and improving the test efficiency.

[0061] It should be noted that the execution subject of this embodiment can be a test case automatic scripting system, or a computing service device with data processing, network communication, and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device that can implement the above-mentioned test case automatic scripting function. This embodiment does not specifically limit this. Hereinafter, taking the test case automatic scripting system as an example, this embodiment and the following embodiments will be described.

[0062] Based on this, the embodiment of this application provides a method for automatically scripting test cases. Refer to Figure 1 , Figure 1 which is a schematic flowchart of the first embodiment of the test case automatic scripting method of this application.

[0063] In this embodiment, the test case automatic scripting method includes steps S10 to S40:

[0064] Step S10: Obtain test cases, variable mapping files, and a basic action library.

[0065] It should be noted that in this step, the system obtains a test case file compiled according to specific Excel format specifications from the user. This file contains all the information required for testing, such as functional module division, test case number, test steps, and expected results. At the same time, the system also obtains a variable mapping file, which establishes the mapping relationship between the generalized variables used in the test cases and the system variables on the actual HIL test platform. In addition, the system loads a basic action library, which contains a series of basic actions pre-packaged in ECU-TEST. These actions can be test steps that are repeatedly used, shared by multiple modules, or not easily expressed in an Excel sheet (such as those containing if-else logic).

[0066] It can be understood that the Excel format specification refers to the restriction and suggestion of the syntax rules of the step statements in the Excel cells of the specific steps of the use case (including setup steps and determination steps). On the basis of ensuring simplicity and readability, the general requirements of various use cases are fully considered. The variable mapping file is for decoupling the test cases from the device platform, enabling the test cases to be used across platforms. The basic action library improves the reusability and maintainability of the test scripts.

[0067] In addition, it should be noted that the Excel format specification consists of at least the following 11 columns: (1) Primary Function: The primary functional module of the controller function specification. (2) Secondary Function: The secondary functional module of the controller function specification. (3) Tertiary Function: The tertiary functional module of the controller function specification. All test cases are hierarchically managed using 3-level modules. (4) Test Case Number: The file name of the test script corresponding to each test case (*.pkg file in ECU-TEST), and the numbering rule is customized according to different requirements. (5) Test Case Description: A description of the test point to be tested by this use case, with the number of words within 30. (6) Precondition: The necessary precondition for implementing this test, generally used in the actual vehicle test scenario. During bench testing, the necessary precondition can be used as a test step. (7) Step Sequence Number: The steps of the use case may consist of multiple steps (i.e., a pair of combinations of test steps + expected results). This column indicates the specific step sequence number. (8) Test Step Description: A description of the test steps for this step, used to support use case reading, review and maintenance, and actual vehicle testing. (9) Test Step: The variable expression of the test step, used for machine recognition and specific variable input. (10) Expected Result Description: A step description of the expected result corresponding to the test step, used to support use case reading, review and maintenance, and actual vehicle testing. (11) Expected Result: The variable expression corresponding to the expected result step, used for machine recognition and specific variable input.

[0068] In addition, it should be noted that the primary functions, secondary functions, and tertiary functions are used to divide the function specifications into different levels for the modularization of test cases. To standardize the output of test case documents, all function specifications are divided into 3 levels. And in this Excel format specification, the columns of primary functions, test case numbers, test steps, and expected results cannot be empty.

[0069] Step S20: Obtain the variable mapping relationship according to the test case or the variable mapping file.

[0070] It should be noted that in this step, the system will parse the variable mapping file or extract the variable mapping file from the test case, and establish a mapping relationship between the generalized variables used in the test case and the system variables on the actual HIL test platform according to the definitions in the file. This variable mapping file can be a dedicated variable mapping table based on Excel or a Global Mapping file in the ECU-TEST environment. This embodiment does not limit this.

[0071] In addition, it should be noted that when designing the test case, decoupling from the device platform is considered, so generalized variable settings and judgments are used. A matching relationship, that is, a variable mapping relationship, needs to be established between these generalized variables and the system variables in the device environment of the specific test case execution platform. It enables the test case to be written independently of the specific test platform, thereby improving the portability and reusability of the test case. It can be understood that this step can ensure that the variables in the test case can be correctly mapped to the actual test environment.

[0072] In a feasible implementation manner, step S20 specifically includes:

[0073] Step S201: When the variable mapping file is a variable mapping relationship table, convert it according to the variable mapping relationship table to obtain a target global mapping file; or, extract an initial global mapping file according to the test case, and map the initial global mapping file according to a preset test bench to obtain a target global mapping file.

[0074] It should be noted that when the system has received the variable mapping relationship table provided by the tester (i.e., the Excel variable mapping table), this table contains information such as variable names, device types, Targets, variable descriptions, and enumeration value definitions. At this time, the system will first read this variable mapping relationship table, and then use the device type (such as platforms like VeriStand, INCA, CANoe, ControlDesk, etc.) to convert it into a target global mapping file (i.e., the Global Mapping file). For example, the tester provides an Excel variable mapping table containing multiple variables, and each variable is marked with the corresponding device type (such as VeriStand, INCA, etc.) and Target path. At this time, the system will read this table and automatically generate a Global Mapping file, which contains the variable mapping relationships corresponding to the Excel variable mapping table and can be directly used in the ECU-TEST platform.

[0075] In addition, it should be noted that when the tester does not provide a variable mapping relationship table, the system will extract the variable information from the test cases to obtain an initial global mapping file. Then, the system will obtain the mapping of the variables in the initial global mapping file by the tester according to the preset test bench (i.e., the actual HIL test environment) to obtain the target global mapping file. It can be understood that the initial Global Mapping file only contains variable names and no specific mapping relationships.

[0076] Step S202: Obtain the variable mapping relationship according to the target global mapping file.

[0077] It should be noted that after obtaining the target global mapping file, the system will read the variable mapping relationships in the file and apply them to the subsequent automatic scripting process of the test cases. It can be understood that this process ensures that the generalized variables in the test cases can be correctly mapped to the system variables in the device environment of the specific case execution platform, thus realizing the automatic scripting of the test cases. For example, after obtaining the target Global Mapping file, the system will read the variable mapping relationships in the file and replace the generalized variables in the test cases with specific device variables according to these relationships. Then, the tool software will use the API interface of ECU-TEST to convert the test cases into executable test scripts (i.e., pkg files), and this script contains the correct variable mapping relationships and can be directly run on the preset test bench.

[0078] Additionally, it should be noted that the variable mapping relationship in the target global mapping file (Global Mapping file) ensures that the generalized variables in the test cases can be correctly mapped to the system variables in the device environment of the specific test case execution platform, thus realizing the rapid deployment of test cases and automated testing. At the same time, since the Global Mapping file supports multi-platform mapping, the test cases can also be easily deployed to different HIL test environments, improving the flexibility and efficiency of testing.

[0079] Step S30: Screen the test cases based on preset text matching rules to obtain target test cases.

[0080] It should be noted that in this step, the system has a built-in set of preset text matching rules for screening the obtained test cases. These rules are designed based on the statement format specifications of the test cases to check whether the test cases meet the requirements. Only the test cases that meet the requirements will be matched as target test cases for subsequent script generation. For example, the system checks whether the "test steps" and "expected results" columns in the test cases conform to the statement format specifications. If a certain test case contains unrecognized variables or actions in the "test steps" column, or if the comparison expression in the "expected results" column is incorrect, then this test case will be excluded by the system and no subsequent script generation will be performed.

[0081] It can be understood that the preset text matching rules are an important means to ensure the quality of test cases and the accuracy of script generation. By screening out the test cases that meet the requirements, the system can ensure that the generated test scripts can correctly execute the test tasks.

[0082] In a feasible implementation manner, after the step S30, steps A10 to 20 are further included:

[0083] Step A10: Obtain the configuration function of the script generation tool.

[0084] It should be noted that in this step, the system determines the configuration function of the current script generation tool. This configuration function allows testers to set flexibly multiple parameters in the script generation process according to actual needs to ensure that the generated test scripts can meet specific test requirements. Specifically, the tester needs to select the upper computer interface of the script generation tool (such as Figure 2 shown). In the upper computer interface, the test case table and variable mapping table to be uploaded can be selected (or a Global Mapping file can be generated using the variable mapping table). Click the "Setting" button to enter the configuration function interface (such as Figure 3As shown. In the configuration function interface, the tester can browse and modify multiple configuration parameters including: the root directory of the variable tree, adding a default delay between setting steps, restoring default values, automatically adding a Trace plot for variables (i.e., automatically plotting waveforms for test case variables), the timeout for multi-variable detection, the timeout for single-variable detection, etc.

[0085] Additionally, it should be noted that as Figure 3 shown, the root directory of the variable tree refers to the root directory of the variable paths of systems on different platforms in the ECU-TEST environment. If it has been modified in ECU-TEST, it needs to be synchronized and updated here, and dSpace is consistent with VeriStand. When generating test cases using the Global Mapping file, the root directory of the variable tree here does not need to be modified. Adding a default delay between setting steps (i.e., one delay per row in Excel) means that when this setting is activated, when generating the script, a default delay step will be automatically added after all the steps in the cells of one row of Excel are generated. One delay per step means that when this setting is activated, when generating the script, a default delay step will be automatically added between each setting step. Restoring default values means that when this setting is activated, when generating the script, initialization and Cleanup operations will be automatically added, that is, at the first step of the pkg, the current values of all the set variables are read and stored, and at the last step, the set values stored in the first step are written into the set variables. The timeout for multi-variable detection (i.e., the default timeout (ms) for MutilCheck) means that when multiple variables need to be checked simultaneously in the expected result, MutilCheck in ECU-TEST can be used to synchronously check multiple variables, and this configuration is the timeout for MutilCheck. The timeout for single-variable detection (i.e., the default timeout (ms) for single-step Check) means the timeout for setting the loop detection when judging a single variable.

[0086] It can be understood that the function of adding a default delay between setting steps here is to solve the problem of asynchronous execution of test steps that may occur during actual testing due to system response delays or signal transmission delays. By adding delay operations, it can be ensured that each test step can be completely executed within the expected time.

[0087] Step A20: When the waveform plotting function in the configuration function is in an active state, save the variable data in the target test case and draw a waveform diagram based on the variable data.

[0088] It should be noted that when the waveform graph drawing function in the configuration function of the script generation tool is activated, the tool will automatically save the variable data in the target test case while generating the test script, and draw the corresponding waveform graph based on this data. Specifically, in the configuration function interface, when the system recognizes that the option of "Auto-increase variable Trace plot (automatically draw waveform graph for case variables)" is checked. And when using the script generation tool to perform script conversion on the test case, the system will automatically recognize and extract the variable data in the test case. During the execution of the test script, these variable data will be recorded and saved in real time. After the test is completed, the tool will automatically draw the waveform graph according to the saved variable data and embed it in the test report.

[0089] Step S40: Convert the target test case according to the preset encapsulation interface, the variable mapping relationship, and the basic action library to obtain a target test script executable on the target platform.

[0090] It should be noted that in this step, the system will execute this step according to a pre-written test script generation tool. This tool converts the test steps and expected results in the target test case into test script statements executable on the ECU-TEST platform according to the preset encapsulation interface (i.e., the API interface of ECU-TEST) and the variable mapping relationship. At the same time, the tool will also replace the basic actions referred to in the test case with the corresponding ECU-TEST action library according to the definitions in the basic action library.

[0091] This embodiment provides a method for automatically scripting test cases. The method of this embodiment includes: obtaining a test case, a variable mapping file, and a basic action library; obtaining a variable mapping relationship according to the test case or the variable mapping file; screening the test case based on a preset text matching rule to obtain a target test case; converting the target test case according to the preset encapsulation interface, the variable mapping relationship, and the basic action library to obtain a target test script executable on the target platform. In summary, this embodiment realizes the rapid automatic scripting of test cases by standardizing the table format and statement format, and uses a preset test script generation tool to automatically convert test cases into target test scripts, improving the test efficiency.

[0092] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar content as in the above-mentioned first embodiment can be referred to the above introduction and will not be repeated hereinafter. On this basis, please refer to Figure 4 , Figure 4 is a schematic flowchart of the second embodiment of the method for automatically scripting test cases of the present application. The specific steps of step S30 include:

[0093] Step S301: Obtain test step data and expected result data according to the test case.

[0094] It should be noted that in this step, the system will obtain test step data and expected result data by reading the "test step" column and "expected result" column in the test case respectively. The test step data includes all the data in the test step column of the test case table, and the expected result data includes all the data in the expected result column of the test case table. Additionally, it should be noted that the test step data refers to the step information for specific test execution, usually including variables to be set and their values, actions or operations to be performed, etc.; while the expected result data refers to information such as variable values or states expected to be obtained after test execution.

[0095] Step S302: Obtain a statement format specification according to a preset text matching rule.

[0096] It should be noted that the process of obtaining a statement format specification according to a preset text matching rule is as follows: First, the system will obtain a set of predefined statement format specifications for test steps and expected results. This set of specifications defines the syntax and rules that can be filled in the test step column and expected result column in the Excel test case. For example, only variables that can be set (written), action libraries, delay operations, etc. can be filled in the test step column. Similarly, the expected result column also has similar syntax rules, including variable comparison, action libraries, delay operations, etc.

[0097] It can be understood that the statement format specification is a set of rules formulated to ensure that test cases can be correctly parsed and converted by an automated script conversion tool. It defines the writing methods and syntax requirements for test steps and expected results in test cases.

[0098] Step S303: Screen the test step data and the expected result data according to the statement format specification to obtain target test step data and target expected result data.

[0099] It should be noted that the specific process of screening the test step data and the expected result data according to the statement format specification to obtain the target test step data and the target expected result data is as follows: After completing the format specification check and verification of the test step data and the expected result data, the system will screen out the test step data and the expected result data that meet the specification requirements as the target test step data and the target expected result data. These data will be used in the subsequent automated script conversion process. For example, if the variable filled in the test step column is set to "IVI_DSeatFrontRearAdj = 1" and it meets the statement format specification after matching and screening, then this test step data will be used as the first part of the target test step data. Similarly, similar screening and processing are also performed on the expected result data.

[0100] In addition, it should be noted that the target test step data and the target expected result data refer to the test step data and the expected result data that meet the statement format specification requirements and can be correctly parsed and converted by the automated script conversion tool.

[0101] In a feasible implementation manner, the step S303 specifically includes:

[0102] Step B10: Obtain the first format specification and the second format specification according to the statement format specification.

[0103] It should be noted that in this step, the system will parse the statement format specification, which details the writing rules for test steps and expected results. Based on these rules, the system will further refine the first format specification for matching and screening test step data; at the same time, the system also obtains the second format specification for matching and screening expected result data.

[0104] In addition, it should be noted that the first format specification and the second format specification are further refinements and concretizations based on the statement format specification, which provide clear rules for the matching and screening of data within the subsequent script.

[0105] Step B20: Screen the test step data according to the first format specification to obtain the target test step data.

[0106] It should be noted that in this step, the system will match and screen the test step data one by one according to the first format specification. For the test step data that meets the first format specification, the system will regard it as the target test step data; for the data that does not meet the specification, an error prompt will be given and modification will be required. It can be understood that the purpose of this step is to ensure that all test steps meet the expected format requirements so that they can be correctly processed and executed in the subsequent steps.

[0107] Additionally, it should be noted that the first format specification refers to the statement format specification of the test step column. The first format specification specifically includes: the test step can only contain settable variables, action library calls, or delay operations, and the syntax must conform to the following form: for example, "Variable setting: IVI_DSeatFrontRearAdj = 1", "Action library: IGN_OFF", "Delay operation: Wait 5s, Delay2min". When setting variables, constants can be replaced with enumeration values, but the definition of the enumeration value needs to be indicated in the variable mapping relationship. For example: IVI_DSeatFrontRearAdj = ON, and the enumeration value ON represents the numerical value 1 in the mapping relationship.

[0108] Step B30: Screen the expected result data according to the second format specification to obtain the target expected result data.

[0109] It should be noted that the second format specification refers to the statement format specification of the expected result column. Similar to the previous step, the system will match and screen the expected result data one by one according to the second format specification. For the expected result data that conforms to the second format specification, the system will regard it as valid target expected result data; for the data that does not conform, error prompts will be given and modification will be required. Additionally, it should be noted that the second format specification specifically includes variable comparison specifications, action library specifications, and delay operation specifications, etc.

[0110] In a feasible implementation manner, the step B30 specifically includes:

[0111] Step B301: Obtain the variable comparison specification, action library specification, and delay operation specification according to the second format specification.

[0112] It should be noted that the second format specification specifically includes variable comparison specifications, action library specifications, and delay operation specifications, etc. Specifically, the variable comparison specification defines how to perform comparison operations between variables, including the comparison symbols used (such as =, ==,!=, >, >=, <, <=), where "=" and "==" are equivalent. The action library specification lists all available action library keywords, which represent a series of pre-defined test steps or operations that are repeatedly used in ECU-TEST and are not easily expressed in the table. The delay operation specification defines how to perform delay operations, including the keywords used (such as Wait or Delay) and the expression method of the delay time (the supported time units include ms, s, min, etc.).

[0113] Step B302: Screen the expected result data according to the variable comparison specification, the action library specification, and the delay operation specification to obtain the target expected result data.

[0114] It should be noted that this step is the process of the system screening the expected result data according to the variable comparison specification, action library specification and delay operation specification. By checking each entry in the expected result data one by one, it is determined whether it meets the requirements of these specifications. Only those entries that meet the specifications will be retained as the target expected result data. For example, during the screening process, you may encounter an expected result data: "BCM_PositionLampSt=1(Wait5s)". According to the variable comparison specification and delay operation specification, this data meets the requirements because it uses the correct comparison symbol (=) and delay operation specification (Wait 5s). Therefore, this data will be retained as part of the target expected result data. On the contrary, if a piece of expected result data uses an undefined action library keyword or a comparison symbol that does not comply with the regulations, it will be regarded as data that does not meet the specifications and will be excluded from the target expected result data.

[0115] In a feasible implementation manner, before step B302, steps C10 to C30 are further included:

[0116] Step C10: Obtain preset time specifications, range specifications, and enumeration specifications.

[0117] It should be noted that in this step, the system will read the time specification, range specification and enumeration specification from the system configuration or preset rule base. The time specification refers to the addition of time configuration when comparing variables on the basis of the standard variable comparison specification (such as "Within" means within a certain time range, "Keep" means lasting for a certain time). The range specification refers to the expression of the value range in the expected result, in addition to the expression forms such as >, <, etc. (such as percentages and upper and lower deviation values). The enumeration specification refers to the specification that the constant values involved in the comparison in all the above rules can be replaced by enumeration values (the enumeration values are defined in the variable mapping relationship).

[0118] As you can understand, time specifications are used to precisely control the timing constraints of events in a test case, ensuring that test steps and expected results are executed in the predetermined order and duration. Range specifications are used to define the appropriate range of variable values to support more complex test logic and judgment conditions. Enumeration specifications can improve the readability and maintainability of test cases by assigning easy-to-understand names (enumeration values) to constant values.

[0119] Step C20: Adding the time specification, the range specification, and the enumeration specification to the variable comparison specification to obtain a target variable comparison specification.

[0120] It should be noted that after obtaining the preset time specification, range specification, and enumeration specification, the system will combine these specifications with the original variable comparison specification to form a target variable comparison specification. It can be understood that the purpose of this step is to further enrich and improve the description ability of the expected results of test cases. Specifically, the system will embed the time specification, range specification, and enumeration specification into the variable comparison specification to form new comparison rules. For example, for the time specification, there are the following 4 time specifications: (1) BCM_PositionLampSt = 1 (Change Within 10s), which means that the value changes within 10s and the current value is 1. And the variable comparison before "Change Within" can be omitted, that is, the current value is not determined, only the value change within 10s is verified. (2) BCM_PositionLampSt = 1 (Within 10s), which means that the value becomes 1 within 10s, and the expected value can be an enumerated value or a cached value. (3) BCM_PositionLampSt > 2 (Keep 10s). This means that the value > 2 is maintained for more than 10s. (4) BCM_PositionLampSt = 1 (Keep10s Within 12s). This means that the situation where the value > 2 is maintained for more than 10s within 12s. For the range specification, there are the following 2 range specifications: (1) BCM_PositionLampSt = 1000 (5%), which means that the expected value is 1000, with an upper and lower deviation of 5%, that is, 950 - 1050. (2) BCM_PositionLampSt = 1000 (5), which means that the expected value is 1000, with an upper and lower deviation value of 5, that is, 995 - 1005.

[0121] Step C30: Update the variable comparison specification according to the target variable comparison specification.

[0122] It should be noted that in this step, the system will apply the integrated target variable comparison specification to the actual test cases and update the original variable comparison specification. It can be understood that by updating the variable comparison specification, the system can ensure that the test cases meet the new specification requirements, thereby supporting more complex test scenarios and logical judgments. This helps to improve the accuracy and efficiency of testing, and reduce the testing cost and risk.

[0123] Step S304: Obtain a target test case based on the test case, the target test step data, and the target expected result data.

[0124] It should be noted that after obtaining the target test step data and target expected result data, the system will automatically generate a test script that meets the requirements of the ECU-TEST platform based on these data and other information in the test case (such as variable mapping relationships, action libraries, etc.). The generated test script can be directly run on the ECU-TEST platform for HIL automated testing of the controller. For example, in a specific test case, the system will generate a test script containing multiple test steps and expected result judgments based on the target test step data and target expected result data. This test script will be executed in the order of the test steps defined in the test case, and after each test step is executed, it will check whether the actual result is consistent with the expected result. If they are consistent, the next test step will be continued; if not, the error information will be recorded and the next test step will be continued.

[0125] In this embodiment, by splitting the statements of the test case according to the format, the first format specification and the second format specification are obtained, and based on this, the test step data and expected result data are screened and normalized. At the same time, combined with the preset time specification, range specification, and enumeration specification, the accuracy and consistency of the test case are further ensured, providing a more reliable and efficient data basis for subsequent automated script generation, and effectively improving the automation level and test efficiency in the field of automotive electronic control testing, especially controller HIL testing.

[0126] Refer to Figure 5 , Figure 5 is a schematic diagram of the workflow from test case to script in an embodiment of the automatic scripting method for test cases of the present application; specifically, Figure 5It shows the working process of the entire system from requirements to use cases, then to scripts, and finally to bench execution. A test method and tool are aimed at automating the conversion of test cases in Excel format into automated scripts for ECU-TEST. Specifically, requirements analysis is the starting point of the test process. Test engineers need to analyze based on functional requirements to clarify the test objectives and scope. Among them, test cases refer to that the system will read test cases prepared by test engineers in Excel while complying with the preset Excel format specifications and use case step statement specifications. These test cases describe in detail the test steps and expected results and are the basis for subsequent script generation. Generating the GlobalMapping file uses the test case to script tool preset in the system to extract use case variables and generate the GlobalMapping file. This file establishes the matching relationship between the generalized variables in the test cases and the system variables in the device environment of the specific use case execution platform. Preparing the bench and action library means perfecting the matching of the GlobalMapping file on the real bench and preparing the relevant scripts for the action library. The action library contains a series of test steps that are repeatedly used, shared by multiple modules, or not easily expressed in Excel. These steps are packaged into basic action library scripts in ECU-TEST. Checking test cases means that the system will check the format specifications and use case step statement specifications of the test cases to ensure that the test cases comply with the specifications. Generating test scripts, that is, after passing the check, generating a test script file based on the ECU-TEST API. This file contains the test steps and expected results of all test cases and can be directly run in the ECU-TEST software. Bench execution of the test means calling the bench host computer software and using the generated test script file to perform automated tests on the controller under test.

[0127] Refer to Figure 6 , Figure 6 is a schematic diagram of the conversion process from test cases to scripts in an embodiment of the test case automatic scripting method of this application; specifically, Figure 6It details the conversion process of test cases into test script files. Extract test case numbers: In the system, first extract the test case numbers in the Excel test cases. This number will be used as the file name of the final test script. Analyze test steps and expected results: Next, the tool analyzes the test step column and the expected result column. The text in the corresponding cells is first split by line and then regular text matching is performed to identify the specific content of the test steps and expected results. Check format specifications: During the matching process, the system checks whether the test cases comply with the Excel format specifications and the use case step statement specifications. If not, the user will be prompted to modify. Generate test script (i.e., PKG): After successful matching, the tool enters the script generation phase. According to the tool configuration properties, initialization steps, test steps, expected result steps, delay operations (if necessary), Cleanup steps, etc. are inserted into the script. At the same time, according to the configuration properties, post-processing steps such as drawing variable waveform diagrams can also be inserted. Save the test script: Finally, save the generated script file, and the conversion of one use case is completed. The system can analyze and generate in batches, quickly realizing the scripting of use cases.

[0128] This application also provides a test case automatic scripting device, please refer to Figure 7 , the test case automatic scripting device includes:

[0129] A data acquisition module 10, configured to acquire test cases, variable mapping files, and basic action libraries;

[0130] A variable mapping module 20, configured to obtain variable mapping relationships according to the test cases or the variable mapping files;

[0131] A matching and screening module 30, configured to screen the test cases based on preset text matching rules to obtain target test cases;

[0132] A script conversion module 40, configured to convert the target test cases according to preset encapsulation interfaces, the variable mapping relationships, and the basic action libraries to obtain target test scripts executable on the target platform.

[0133] The test case automatic scripting device provided by this application adopts the test case automatic scripting method in the above embodiment, and can solve the technical problem of how to automatically convert test cases into ECU-TEST automatic scripts. Compared with the prior art, the beneficial effects of the test case automatic scripting device provided by this application are the same as those of the test case automatic scripting method provided by the above embodiment, and other technical features in the test case automatic scripting device are the same as the features disclosed in the method of the above embodiment, and will not be elaborated here.

[0134] In one embodiment, the variable mapping module 20 is further configured to, when the variable mapping file is a variable mapping relation table, obtain a target global mapping file through conversion according to the variable mapping relation table; or extract an initial global mapping file according to the test case, and obtain a target global mapping file through mapping of the initial global mapping file according to a preset test bench; and obtain a variable mapping relation according to the target global mapping file.

[0135] In one embodiment, the matching and screening module 30 is further configured to obtain test step data and expected result data according to the test case; obtain a statement format specification according to a preset text matching rule; screen the test step data and the expected result data according to the statement format specification to obtain target test step data and target expected result data; and obtain a target test case based on the test case, the target test step data, and the target expected result data.

[0136] In one embodiment, the matching and screening module 30 is further configured to obtain a first format specification and a second format specification according to the statement format specification; screen the test step data according to the first format specification to obtain target test step data; and screen the expected result data according to the second format specification to obtain target expected result data.

[0137] In one embodiment, the matching and screening module 30 is further configured to obtain a variable comparison specification, an action library specification, and a delay operation specification according to the second format specification; and screen the expected result data according to the variable comparison specification, the action library specification, and the delay operation specification to obtain target expected result data.

[0138] In one embodiment, the matching and screening module 30 is further configured to obtain a preset time specification, range specification, and enumeration specification; add the time specification, the range specification, and the enumeration specification on the basis of the variable comparison specification to obtain a target variable comparison specification; and update the variable comparison specification according to the target variable comparison specification.

[0139] In one embodiment, the script conversion module is further configured to obtain the configuration function of a script generation tool; when the waveform drawing function in the configuration function is in an active state, save the variable data in the target test case, and draw a waveform diagram according to the variable data.

[0140] The present application provides a test case automatic scripting device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the test case automatic scripting method in the first embodiment above.

[0141] Reference is made below to Figure 8 , which shows a schematic structural diagram of a test case automatic scripting device suitable for implementing the embodiments of the present application. The test case automatic scripting device in the embodiments of the present application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions: tablet computers), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 8 The test case automatic scripting device shown is only an example and should not impose any limitation on the functions and usage scope of the embodiments of the present application.

[0142] As Figure 8As shown, the test case automatic scripting device may include a processing device 1001 (such as a central processing unit, a graphics processing unit, etc.), which may perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM: Random Access Memory) 1004. In the RAM 1004, various programs and data required for the operation of the test case automatic scripting device are also stored. The processing device 1001, the ROM 1002, and the RAM 1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems may be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 may allow the test case automatic scripting device to communicate with other devices wirelessly or wiredly to exchange data. Although the figure shows a test case automatic scripting device having various systems, it should be understood that it is not required to implement or have all the shown systems. More or fewer systems may be alternatively implemented or had.

[0143] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes program codes for performing the methods shown in the flowcharts. In such an embodiment, the computer program may be downloaded and installed from a network through the communication device, or installed from the storage device 1003, or installed from the ROM 1002. When the computer program is executed by the processing device 1001, the above functions defined in the methods of the embodiments disclosed in the present application are performed.

[0144] The test case automatic scripting device provided by the present application adopts the test case automatic scripting method in the above embodiments, and can solve the technical problem of how to realize the automatic conversion of test cases into automatic scripts of ECU-TEST. Compared with the prior art, the beneficial effects of the test case automatic scripting device provided by the present application are the same as those of the test case automatic scripting method provided by the above embodiments, and other technical features in the test case automatic scripting device are the same as the features disclosed in the method of the previous embodiment, and will not be elaborated here.

[0145] It should be understood that each part disclosed in this application can be implemented by hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in a suitable manner in any one or more embodiments or examples.

[0146] As described above, the above are only specific embodiments of this application, but the protection scope of this application is not limited thereto. Any person skilled in the art within the technical scope disclosed in this application can easily think of changes or substitutions, which should all be covered within the protection scope of this application. Therefore, the protection scope of this application should be subject to the protection scope of the claims.

[0147] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., computer programs) stored thereon, and the computer-readable program instructions are used to execute the test case automatic scripting method in the above embodiments.

[0148] The computer-readable storage medium provided by this application can be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination of the above. More specific examples of computer-readable storage media can include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM) or flash memory, optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. In this embodiment, the computer-readable storage medium can be any tangible medium that contains or stores a program, and this program can be used by or in combination with an instruction execution system, device, or device. The program code contained on the computer-readable storage medium can be transmitted by any appropriate medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0149] The above computer-readable storage medium can be included in the test case automatic scripting device; it can also exist separately without being assembled into the test case automatic scripting device.

[0150] The above computer-readable storage medium stores one or more programs which, when executed by a test case automatic scripting device, cause the test case automatic scripting device to: obtain test cases, variable mapping files, and a basic action library; obtain a variable mapping relationship according to the test cases or the variable mapping files; filter the test cases based on a preset text matching rule to obtain target test cases; and transform the target test cases according to a preset encapsulation interface, the variable mapping relationship, and the basic action library to obtain target test scripts executable on a target platform.

[0151] Computer program code for performing the operations of the present application may be written in one or more programming languages or combinations thereof. The programming languages include a variety of programming languages such as Java, Python, C++, etc., or other programming languages that can achieve similar functions. The program code may be executed entirely on a user's computer, partially on a user's computer, executed as a stand-alone software package, partially on a user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0152] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagram may represent a module, a program segment, or a portion of code that contains one or more executable instructions for implementing a specified logical function. It should also be noted that, in some alternative implementations, the functions noted in the blocks may occur in a different order than that noted in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, or they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, may be implemented by a dedicated hardware-based system for performing the specified functions or operations, or may be implemented by a combination of dedicated hardware and computer instructions.

[0153] The modules described in the embodiments of the present application may be implemented in software or in hardware. In some cases, the name of the module does not constitute a limitation on the unit itself.

[0154] The readable storage medium provided by this application is a computer-readable storage medium. The computer-readable storage medium stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned test case automatic scripting method, and can solve the technical problem of how to realize the automatic conversion of test cases into ECU-TEST automatic scripts. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by this application are the same as those of the test case automatic scripting method provided by the above embodiments, and will not be elaborated here.

[0155] This application also provides a computer program product, including a computer program, and when the computer program is executed by a processor, the steps of the test case automatic scripting method as described above are realized.

[0156] The computer program product provided by this application can solve the technical problem of how to realize the automatic conversion of test cases into ECU-TEST automatic scripts. Compared with the prior art, the beneficial effects of the computer program product provided by this application are the same as those of the test case automatic scripting method provided by the above embodiments, and will not be elaborated here.

[0157] The above are only partial embodiments of this application, and do not limit the patent scope of this application accordingly. Any equivalent structural transformation made by using the content of the specification and drawings of this application under the technical concept of this application, or any direct / indirect application in other related technical fields, is included in the patent protection scope of this application.

Claims

1. An automatic scripting method for test cases, characterized in that, The method includes: Obtaining test cases, variable mapping files, and a basic action library; Obtaining a variable mapping relationship according to the test cases or the variable mapping files; Screening the test cases based on a preset text matching rule to obtain target test cases; Converting the target test cases according to a preset encapsulation interface, the variable mapping relationship, and the basic action library to obtain a target test script executable on a target platform.

2. The method according to claim 1, wherein The step of screening the test cases based on a preset text matching rule to obtain target test cases includes: Obtaining test step data and expected result data according to the test cases; Obtaining a statement format specification according to a preset text matching rule; Screening the test step data and the expected result data according to the statement format specification to obtain target test step data and target expected result data; Obtaining target test cases based on the test cases, the target test step data, and the target expected result data.

3. The method according to claim 2, wherein The step of screening the test step data and the expected result data according to the statement format specification to obtain target test step data and target expected result data includes: Obtaining a first format specification and a second format specification according to the statement format specification; Screening the test step data according to the first format specification to obtain target test step data; Screening the expected result data according to the second format specification to obtain target expected result data.

4. The method according to claim 3, wherein The step of screening the expected result data according to the second format specification to obtain target expected result data includes: Obtaining a variable comparison specification, an action library specification, and a delay operation specification according to the second format specification; Screening the expected result data according to the variable comparison specification, the action library specification, and the delay operation specification to obtain target expected result data.

5. The method according to claim 4, characterized in that, Before the step of screening the expected result data according to the variable comparison specification, the action library specification, and the delay operation specification to obtain target expected result data, it further includes: Obtaining a preset time specification, range specification, and enumeration specification; Adding the time specification, the range specification, and the enumeration specification to the variable comparison specification to obtain a target variable comparison specification; Updating the variable comparison specification according to the target variable comparison specification.

6. The method according to claim 1, characterized in that The step of obtaining a variable mapping relationship according to the test cases or the variable mapping files includes: When the variable mapping file is a variable mapping relationship table, performing conversion according to the variable mapping relationship table to obtain a target global mapping file; Or, Extracting an initial global mapping file according to the test cases and performing mapping on the initial global mapping file according to a preset bench to obtain a target global mapping file; Obtaining a variable mapping relationship according to the target global mapping file.

7. The method according to claim 1, wherein After the step of screening the test cases based on a preset text matching rule to obtain target test cases, it further includes: Obtaining the configuration function of a script generation tool; When the waveform graph drawing function in the configuration function is in an active state, save the variable data in the target test case and draw a waveform graph based on the variable data.

8. An automatic scripting device for test cases, characterized in that The device includes: A data acquisition module for acquiring a test case, a variable mapping file, and a basic action library; A variable mapping module for obtaining a variable mapping relationship according to the test case or the variable mapping file; A matching and screening module for screening the test case based on a preset text matching rule to obtain a target test case; A script conversion module for converting the target test case according to a preset encapsulation interface, the variable mapping relationship, and the basic action library to obtain a target test script executable on the target platform.

9. An automatic test case scripting device, characterized in that The device includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the test case automatic scripting method according to any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the test case automatic scripting method according to any one of claims 1 to 7 are implemented.

Images