Test case execution method and device, equipment and medium

Abstract

The invention relates to a test case execution method and device, equipment and a medium. The method comprises the steps that multiple test cases are analyzed, a mapping file, a variable name and an expression of each test case are obtained, and the mapping files are used for representing the mapping relation between the variable names and the expressions; according to the mapping file, the variable name and the expression of each test case, generating a test code of each test step in each test case; packaging the test codes of the test steps of the same type, and obtaining a code module corresponding to each test step type; and according to a preset execution sequence, calling the code module corresponding to the test step type to which each test step belongs in sequence to obtain test results of the plurality of test cases. According to the technical scheme, the execution efficiency and accuracy of the test case are improved.

Description

Technical Field

[0001] The present invention relates to the field of controller testing technology, and in particular to a method, device, equipment and medium for executing a test case. Background Art

[0002] A test case is a set of test inputs, execution conditions, and expected results designed for a specific test objective. It is a detailed description of the specific steps and expected outputs for testing a software system, and is designed to verify whether the software meets the specified requirements and whether there are defects.

[0003] In actual applications, it is necessary to execute each test step in the test case in sequence according to the actual business process, and then obtain the test results after all test cases are executed.

[0004] However, the efficiency and accuracy of executing test cases in the existing technology are low. Summary of the invention

[0005] The present invention provides a method, device, equipment and medium for executing a test case, which solves the problem of low efficiency and accuracy in executing the test case in the prior art.

[0006] In a first aspect, the present invention provides a method for executing a test case, the method comprising:

[0007] Parse multiple test cases to obtain the mapping file, variable name and expression of each test case. The mapping file is used to represent the mapping relationship between the variable name and the expression.

[0008] Generate test code for each test step in each test case based on the mapping file, variable name and expression of each test case;

[0009] Encapsulate the test codes of the same type of test steps and obtain the code module corresponding to each test step type;

[0010] According to the preset execution order, the code modules corresponding to the test step type to which each test step belongs are called in turn to obtain the test results of multiple test cases.

[0011] Optionally, based on the mapping file, variable name, and expression of each test case, generate test code for each test step in each test case, including:

[0012] Parse each test step of each test case and determine the node attributes of the test step;

[0013] Generate test code for the test step according to the node attributes of the test step and the mapping file, variable name and expression of the test case.

[0014] Optionally, the code module corresponding to each test step type includes a variable unit and a mapping file unit, the variable unit is used to store variable values ​​related to the test step corresponding to the test step type, and the mapping file unit is used to store a mapping file corresponding to the test step type.

[0015] Optionally,

[0016] According to the preset execution order, the code modules corresponding to the test step types of each test step are called in turn to obtain the test results of multiple test cases, including:

[0017] Step a: According to the current test step type, obtain the target code module corresponding to the current test step type;

[0018] Step b, calling the target code module according to the node attribute of the current test step to obtain the sub-test result of the current test step;

[0019] Step c: if it is determined according to the preset execution order that the current test step has a subsequent test step, the subsequent test step is determined as a new current test step;

[0020] Step d: if it is determined according to the preset execution order that the current test step does not have a subsequent test step, the sub-test result of the current test step is determined as the test result;

[0021] Repeat steps a to d until the test results are obtained.

[0022] Optionally, after encapsulating the test codes of the same type of test steps and obtaining the code module corresponding to each test step type, the method further includes:

[0023] Storing the code module corresponding to each test step type in a first preset path;

[0024] Correspondingly, according to the current test step type, the target code module corresponding to the current test step type is obtained, including:

[0025] The first preset path is traversed, and the target code module is obtained from the first preset path according to the current test step type.

[0026] Optionally, the method further comprises:

[0027] Storing the code module input by the user to a second preset path;

[0028] Correspondingly, according to the current test step type, the target code module corresponding to the current test step type is obtained, including:

[0029] The second preset path is traversed, and the target code module is obtained from the second preset path according to the current test step type.

[0030] Optionally, before parsing the multiple test cases to obtain the mapping file, variable name, and expression of each test case, the method further includes:

[0031] In response to the user's input operation on the vehicle controller test interface, a test case acquisition request is sent to the server, the test case acquisition request is used to obtain the test case corresponding to the target bench information and the test requirement information, and the vehicle controller test interface is displayed through the browser;

[0032] Receive multiple test cases returned by the server.

[0033] Optionally, according to the code module corresponding to each test step type, the test case is executed in a preset execution order to obtain the test result, including:

[0034] According to the code module corresponding to each test step type, the test case is executed in a preset execution order to control the target test bench to test the vehicle controller to be tested corresponding to the target test bench and obtain the test result.

[0035] Optionally, after parsing multiple test cases and obtaining a mapping file, a variable name, and an expression for each test case, the method further includes:

[0036] Stores the mapping file, variable names, and expressions for each test case into memory.

[0037] In a second aspect, the present invention provides a test case execution device, the device comprising:

[0038] The data acquisition module is used to parse multiple test cases and obtain the mapping file, variable name and expression of each test case. The mapping file is used to represent the mapping relationship between the variable name and the expression.

[0039] A code generation module, used for generating test codes for each test step in each test case according to the mapping file, variable name and expression of each test case;

[0040] A code acquisition module is used to encapsulate the test codes of the same type of test steps and obtain the code module corresponding to each test step type;

[0041] The result acquisition module is used to execute the test cases in a preset execution order according to the code modules corresponding to each test step type and obtain the test results.

[0042] In a third aspect, the present invention provides an electronic device, comprising: a processor, and a memory communicatively connected to the processor;

[0043] Memory stores computer-executable instructions;

[0044] The processor executes the computer-executable instructions stored in the memory to implement the execution method of the test case in the first aspect and various possible implementations.

[0045] In a fourth aspect, the present invention proposes a computer-readable storage medium, which stores computer execution instructions. When the computer execution instructions are executed by a processor, they are used to implement the execution method of the first aspect and various possible test cases.

[0046] The test case execution method, device, equipment and medium proposed in the present invention parse multiple test cases to obtain the mapping file, variable name and expression of each test case, wherein the mapping file is used to represent the mapping relationship between the variable name and the expression; the test code of each test step in each test case is generated according to the mapping file, variable name and expression of each test case; the test code of the test steps of the same type is encapsulated to obtain the code module corresponding to each test step type; and the code module corresponding to the test step type to which each test step belongs is called in sequence according to the preset execution order to obtain the test results of the multiple test cases. The technical solution encapsulates each type of test step into a code module, and when executing the test step of the test case later, it only needs to call the corresponding code module to implement the function of the test step, which greatly reduces the coupling between the various expression parsing methods, thereby improving the test efficiency and accuracy. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 A schematic diagram of the execution architecture of the test case provided by the present invention;

[0048] Figure 2 A schematic diagram of the principle of the method for executing the test case provided by the present invention;

[0049] Figure 3 A flowchart of a first embodiment of a method for executing a test case provided by the present invention;

[0050] Figure 4a A flowchart of a second embodiment of the method for executing a test case provided by the present invention;

[0051] Figure 4b A flowchart of a third embodiment of the method for executing a test case provided by the present invention;

[0052] Figure 5A flowchart of a fourth embodiment of the method for executing a test case provided by the present invention;

[0053] Figure 6 A flowchart of a fifth embodiment of the method for executing a test case provided by the present invention;

[0054] Figure 7 A flowchart of a sixth embodiment of the method for executing a test case provided by the present invention;

[0055] Figure 8 A flowchart of a seventh embodiment of a method for executing a test case provided by the present invention;

[0056] Fig. 9 A flowchart of Embodiment 8 of the method for executing a test case provided by the present invention;

[0057] Fig.10 A schematic diagram of the structure of the test case execution device provided by the present invention;

[0058] Fig.11 The present invention provides a schematic structural diagram of an electronic device. DETAILED DESCRIPTION

[0059] The following will describe the embodiments of the present invention with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention, not for limiting the scope of protection of the present invention.

[0060] It should be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present invention, and thus the drawings only show components related to the present invention rather than being drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component may be changed arbitrarily, and the component layout may also be more complicated.

[0061] As a text-based markup language, the universality of XML enables XML to transmit and exchange data between different software and platforms. XML data is represented in a structured way, which makes the data easier to understand and process. As well as its form and content separation characteristics, cross-platform compatibility, high flexibility and extensibility, XML files are widely used, so the test cases used in the parsing engine are displayed in XML format.

[0062] At present, due to the increasing complexity of test scenarios, each test process involves many test cases, which in turn leads to many test steps. However, there are nested calls between test steps, and test cases also nested calls to multiple other test cases, resulting in high coupling between steps, making the XML file structure generated by the test case complex and the parsing time long, which leads to low efficiency of the test process. At the same time, the high coupling between steps will also cause problems in one step, which will affect other test steps associated with it, causing problems in the entire test process, and it is difficult to locate which test step caused the failure.

[0063] In summary, the existing technology has problems of low accuracy and efficiency when executing test cases.

[0064] In response to the above technical problems, the inventors have come up with the idea of ​​parsing the variable information, node attributes, and expression types in each test case and converting them into code, and then encapsulating different test steps according to different types to obtain corresponding test code modules. In this way, when executing the test case, the test code module can be directly called to complete the test task, reducing the coupling between different test steps, and thus solving the problem of low accuracy and efficiency caused by high coupling of steps when executing the test case.

[0065] Figure 1 The following is a schematic diagram of the execution architecture of the test case provided by the present invention. Figure 1 As shown in FIG. 1 , the execution architecture of the test case includes the World Wide Web (WEB) cloud (referred to as the cloud), the host computer, the HIL bench, and the electronic control unit under test. Among them, the backend and the host computer, the XML-Remote Procedure Call (RPC) server, and the test case parsing engine are all deployed in the host computer.

[0066] The test case parsing engine is used to receive the test task sent by the WEB cloud through the XML-RPC server, parse and execute the test task, obtain the test data, and upload it to the WEB cloud. Specifically, the test case parsing engine consists of a test case parsing and execution module, a device simulation module, a data analysis module, a test report module, a log module, a data transmission module, a user-defined module, and a built-in function module.

[0067] Figure 2 The schematic diagram of the principle of the execution method of the test case provided by the present invention is as follows. Figure 2As shown, the process includes: after obtaining the test case from the cloud, the mapping attribute is first parsed through the parsing module to parse the mapping variables of all mapping files in the test case, and the variable attribute parsing and expression parsing are performed through the parsing module to obtain the key information such as the variables set by all test cases and the expressions related to the variables. Then the parsing module parses each test step to obtain the node attributes of each test step and convert it into code (such as python) code. After that, the test case is executed through the test case parsing and execution module, specifically including the simultaneous automatic processing of multiple hardware-in-the-loop (HIL) device test tasks through the device simulation module to obtain the test results. After that, the test result analysis is performed through the data analysis module and the test report module to obtain the variable information, expression information, parameter results, expected results, step execution time, assertion results, mapping (English: mapping) path, and generate and upload the final test report.

[0068] In addition, the present invention also provides a user-defined module and a built-in function module for realizing the function of dynamically injecting user-defined functions.

[0069] It should be understood that Figure 1 and Figure 2 The specific principles and implementation process will be described in detail in the following embodiments and will not be repeated here.

[0070] Figure 3 The flowchart of the first embodiment of the method for executing the test case provided by the present invention is as follows. Figure 3 As shown, the method includes:

[0071] S301. parse multiple test cases to obtain a mapping file, variable name, and expression for each test case.

[0072] The mapping file is used to represent the mapping relationship between variable names and expressions.

[0073] The mapping files include global mapping files and local mapping files. Similarly, the variable names include the names of global variables and the names of local variables.

[0074] In this step, first obtain the test cases sent by the server, and use Figure 1 The parsing module in the test case identifies each common test step in the test case. The characteristic of common test steps is that they have no nested structure.

[0075] Secondly, when parsing common test steps, the parsing module will also identify variable models related to common test steps, including global variables, local variables, and state variables. After that, different parsing strategies are adopted according to the type of variable. For example, if the type of the variable is a basic data type, the variable name and the file name are concatenated to form a variable identifier; if the type of the variable is an enumeration type, the corresponding enumeration attribute is added. Then, based on the parsing results, a mapping relationship between variables and common test steps is constructed to ensure that these variables can be correctly referenced when executing common test steps.

[0076] In actual applications, a mapping file may have a specific identifier, such as xam. The mapping file path can be traversed to parse out files identified as xam, which are mapping files.

[0077] In addition, when parsing test cases, the parsing module also detects whether the current normal test step involves calling sub-case packages, which may contain more complex logic or other test steps. For the called sub-case packages, the parsing module repeats the parsing process of the normal test steps to obtain the global variables, local variables, and state variables of the sub-case packages.

[0078] When parsing the sub-case package, the parsing module will focus on the interaction of variables, that is, whether the current test case needs to provide parameters to the sub-case package, and whether the return value of the sub-case package needs to be passed to the current test case.

[0079] Furthermore, the mapping file, variable name and expression of each test case may be stored in the memory.

[0080] In a specific implementation, after parsing each test case to obtain the mapping file, variable name and expression, the mapping file, variable name and expression can also be saved to a data structure (such as a dictionary or list) in the memory. When executing the test steps later, these parsed mapping files, variable names and expressions can be directly called without re-parsing the entire test case, thereby improving the test efficiency.

[0081] S302: Generate test code for each test step in each test case according to the mapping file, variable name and expression of each test case.

[0082] Specifically, in the process of parsing the test cases, the initial variables set in all test cases will be parsed, and then the global variables and local variables in the initial variables will be distinguished by analyzing the test case structure to ensure that the context information of each test case can be correctly captured. Then, based on the obtained initial variables, mapping files and specific code writing formats, the expressions contained in the test steps will be converted into executable code.

[0083] In a possible implementation, each test step of each test case can be parsed to determine the node attributes of the test step, and then the test code of the test step is generated according to the node attributes of the test step and the mapping file, variable name and expression of the test case.

[0084] In this implementation, first read the mapping file, variable name and expression of each test case, and traverse each test step, then use XML parsing library to extract the node attribute of each step, such as operation attribute, input attribute, prediction result attribute etc., these node attributes can be used as the basis for generating test code.Then combine the node attribute of each step with the mapping file, variable name and expression of the test case, just can determine the relationship between the specific test requirement of each test step and the upper and lower steps.Then by code generation module, based on the type (such as input, verification and output types) of each test step, the node attribute and mapping file, variable name and expression of each test step are converted into test code (such as Python code) accordingly.Specifically, string formatting or template engine can be used, node attribute is dynamically inserted in the code generation module, thereby generates complete Python sentence, can guarantee that the code generated matches the logic of step definition like this.

[0085] S303: Encapsulate the test codes of the same type of test steps, and obtain the code module corresponding to each test step type.

[0086] In this step, the design method of the simple factory pattern is utilized to create a factory class, which returns the corresponding test step object according to the test step type (such as input, verification and output) passed in. Wherein, the simple factory pattern encapsulates different types of test steps in respective classes, thereby reducing the coupling between each test step. Then the strategy pattern calling class method is adopted to process the parsing content of different types of expressions, and different calling strategies are defined for each expression, so that when executing the test case, the appropriate test strategy can be selected according to the test needs. For example, a strategy interface can be created, which defines a method for executing a specific type of test case, and implements the specific type of the strategy interface for the type of each test step. Specifically, different strategy interfaces centrally manage the types of each test step, and the test steps under each test step type are called through the strategy interface.

[0087] Then, the class of each test step type is modularly designed. Specifically, each test step type is defined as an independent code module. Each code module is responsible for specific functions and test tasks. These code modules have good encapsulation and reusability, and can be executed independently without relying on the content implementation of other modules. The specific execution logic of the test steps corresponding to each test step type is encapsulated inside its code module, so that when executing the test case, you only need to call the corresponding code module without paying attention to its internal implementation details. Among them, each code module can include logic such as initialization, execution, and result processing, and can independently handle specific types of logic and methods, enhance the readability and maintainability of the code, and encapsulate the implementation details of the test steps through modular thinking, making subsequent expansion and modification easier.

[0088] Furthermore, the code module corresponding to each test step type also includes a variable unit and a mapping file unit.

[0089] After modular encapsulation, each code module will manage the variable values ​​and mapping information related to the module. Specifically, the variable unit is used to store the variable values ​​related to the test step corresponding to the test step type. The stored variables can be input parameters, configuration options, or other values ​​that need to be used during the execution of the test step; the mapping file unit is used to store the mapping file corresponding to the test step type, which mainly describes the relationship between the variable name and its corresponding expression. For example, the mapping file can be a dictionary with the key as the variable name and the value as the expression.

[0090] S304: Call the code modules corresponding to the test step type to which each test step belongs in sequence according to a preset execution order to obtain test results of multiple test cases.

[0091] Before executing this step, you need to create a preset execution order list to clarify the execution order of each test step in the test case. This execution order can be achieved through simple numerical indexing, priority settings or configuration files.

[0092] It should be understood that the preset execution order list needs to be determined according to the actual business process.

[0093] In this step, first, according to each test step type, the code module in the previously defined strategy interface is called. Each test step type has a corresponding code module responsible for performing a specific test task. Then, according to the preset execution order, the code module corresponding to each test step is called in sequence. In this process, the context class can be used to execute the strategy of each step and pass in the necessary input data (such as the variable value stored in the variable unit). After executing each step, the generated results or status are stored in a result list or dictionary for subsequent analysis and reporting.

[0094] In the above embodiment, firstly, multiple test cases are parsed to obtain their mapping files, variable names and expressions, including mapping files, variable names and expressions, to clarify the relationship between variables and expressions. Then, the test code for each test step is generated according to these mapping files, variable names and expressions, and the test codes of the same type are encapsulated into code modules to ensure modularity and reusability. In the execution phase, these code modules are run in a preset order to obtain test results. This process of test case parsing and execution not only improves test efficiency and flexibility, but also reduces error rates and meets the needs of complex test scenarios.

[0095] Figure 4a The flowchart of the second embodiment of the method for executing the test case provided by the present invention is as follows: Figure 4a As shown, based on the first embodiment, S304 can be implemented by the following steps:

[0096] S401. According to the current test step type, obtain the target code module corresponding to the current test step type.

[0097] In this step, after the current test step is determined, it is necessary to analyze the node attributes of the current test step, determine the current test step type based on the node attributes, and then determine the target code module.

[0098] Further, based on the first embodiment, after obtaining the code module corresponding to each test step type, the code module corresponding to each test step type can also be stored in the first preset path. In this way, the first preset path can be traversed to obtain the target code module from the first preset path.

[0099] The first preset path may be a folder specifically used to store each code module. When the code module corresponding to each test step type is stored in the first preset path, each code module may be saved in a suitable file format (such as .py or other script formats), and each file may be named for subsequent identification and calling.

[0100] Furthermore, when executing the test step, the first preset path is traversed to find the target code module matching the current step type. Specifically, during the traversal process, the target code module is identified according to the characteristics of the file name or file content. When a matching target code module is found, the content in the target code module is loaded to facilitate the subsequent execution process, effectively ensuring the reusability of the code and improving the flexibility of test execution.

[0101] S402. According to the node attribute of the current test step, the target code module is called to obtain the sub-test result of the current test step.

[0102] In this step, the functions and methods in the target code module are determined according to the node attributes of the current test step obtained in the previous step. Then, these node attributes are used as parameters to call the corresponding variable unit and / or mapping file unit in the target code module to transfer the relevant parameters (such as input parameters, status, etc.) in the current test step to the target code module, so that the target code module executes the corresponding test steps (such as performing calculations, calling external devices, etc.) according to the received parameters, and after executing the test steps, collects its return value or execution result, that is, the sub-test result (such as execution status, output data, etc.).

[0103] For example, if a node attribute is identified as a variable (English: Variables), the variable unit will be called. Among them, if the type of the variable is a basic data type (such as integer, floating point, etc.), the variable name and its corresponding file name will be spliced ​​together to form a unique variable name identifier. This method can also ensure that each variable can be correctly referenced and identified in different contexts; if the type of the variable is an enumeration type, the variable will be written into a special enumeration class, and appropriate enumeration attributes will be added to it, which ensures that the enumeration variable can be properly managed and called in subsequent processing. For example, if the node attribute is identified as MAPPING, the mapping unit will be called, which will be responsible for obtaining the mapping relationship between the variable and the expression, so as to correctly reference these variables in subsequent steps.

[0104] S403: If it is determined according to the preset execution order that the current test step has a subsequent test step, the subsequent test step is determined as a new current test step.

[0105] In this step, it is necessary to determine whether there is a subsequent step to be executed in the current test step according to the preset execution order, that is, whether there is a next test step that needs to be executed according to the preset execution order after the current test step. If there is a subsequent test step, the subsequent test step is set as the new current test step, that is, it is ready to execute the next test step instead of staying on the sub-test result of the current test step. In this way, the control of the entire test process is guaranteed, ensuring that all subsequent test operations can be carried out smoothly.

[0106] Afterwards, S401 is executed again.

[0107] S404: If it is determined according to the preset execution order that the current test step does not have a subsequent test step, the sub-test result of the current test step is determined as the test result.

[0108] In this step, after confirming that the current step has been completed and there are no subsequent steps according to the preset execution order, it means that the test task has been completed and all test cases have been executed. Then the sub-test result of the current test step can be set as the final test result.

[0109] Steps S401 to S404 are executed in a loop until the test result is obtained.

[0110] This looping mechanism allows us to handle multiple nested steps, ensuring that all necessary logic is executed while properly managing variable interaction issues.

[0111] In the above embodiment, the corresponding target code module is obtained by determining the current test step and the node attributes of the current test step. Then the target code module is called and the sub-test result is obtained. If there is a subsequent test step, the subsequent test step is set as the new current step and continues to be executed; if there is no subsequent step, the result of the current step is used as the final test result. The entire method flow ensures the flexibility and accuracy of the test, so that complex test tasks can be carried out smoothly, and also provides a basis for subsequent data processing and result analysis.

[0112] Figure 4b FIG. 3 is a flow chart of the third embodiment of the method for executing the test case provided by the present invention. Figure 4b As shown, S304 can also be implemented by the following steps:

[0113] Step 1: Get the node attributes in the current test step.

[0114] Step 2: Determine the type corresponding to the current test step according to the node attributes in the current test step.

[0115] Step 3: Determine the target code module corresponding to the current test step according to the type corresponding to the current test step.

[0116] Step 4: Determine whether the current test step is a normal test step.

[0117] If yes, execute step 5; if no, re-determine the new current test step according to the sub-use case package that needs to be called by the current test step, and re-execute step 1.

[0118] Step 5: According to the node attributes of the current test step, call the target code module to execute the current test step.

[0119] If the current test step has no subsequent test step, the test process ends; if the current test step still has other subsequent test steps, the current test step is determined as the new current test step, and step 1 is executed again.

[0120] Figure 5 FIG. 4 is a flow chart of the fourth embodiment of the method for executing the test case provided by the present invention. Figure 5 As shown, based on the second embodiment, the above-mentioned acquisition of the target code module corresponding to the current test step type according to the current test step type can also be implemented by the following steps:

[0121] S501: Store the code module input by the user into a second preset path.

[0122] In this step, the use of user-defined functions and built-in functions is provided. Specifically, the code module input by the user can be obtained and stored in the second preset path, so that it can be called when the relevant steps in the subsequent test case are executed.

[0123] It should be understood that the code module input by the user may be a completely new code module edited by the user, or may be a code module regenerated by the user by editing a previously generated code module, and the embodiments of the present application do not impose specific limitations on this.

[0124] It should be understood that the first preset path and the second preset path may be the same or different, and the embodiment of the present application does not impose any specific limitation on this.

[0125] S502: traverse the second preset path, and obtain a target code module from the second preset path according to the current test step type.

[0126] Figure 6 FIG. 5 is a flow chart of the fifth embodiment of the method for executing the test case provided by the present invention. Figure 6 As shown, S502 can be implemented by the following steps:

[0127] S601: Determine a second preset path.

[0128] S602: traverse the second preset path to obtain the Python file.

[0129] In this step, the second preset path is traversed to determine the type of each entry. Then, corresponding processing is performed according to the type of each entry. For example, if the entry is a Python file, the full path is recorded. If the entry is a folder, the contents of the folder are traversed until all Python files are found.

[0130] S603: Add the path of the traversed Python file to the module search path.

[0131] Add the paths of all found Python files to the search path to ensure that the latest user-defined functions can be accessed in time when subsequent modules are imported, and use specific keywords (such as the type of code module) as module identifiers to import user-defined functions.

[0132] It should be understood that the module search path includes the path of the Python file obtained by traversing the first preset path.

[0133] S604: Determine the module identifier according to the current test step type.

[0134] S605: Determine whether the module identifier exists in the module search path.

[0135] If it exists, execute S606; if it does not exist, prompt the user that the recognition failed and end the current operation process.

[0136] S606: Import the code module corresponding to the module identifier.

[0137] After the code module is successfully imported, the test case parsing engine can directly call the imported code function.

[0138] Optionally, the attribute information of the built-in function can be saved to memory according to the functional characteristics of the built-in function. The attribute information includes important information such as function name, parameter type and return value, so that it can be efficiently matched and used in subsequent calls. When it is necessary to access globally available standard Python functions and user-specific functions, the test case parsing engine will use dynamically loaded user-defined modules and built-in functions to execute the functions of the test step.

[0139] As cars are transformed from the fuel era to the new energy era and then to the intelligent era, the automotive electronic control unit (ECU) has also ushered in a huge development. There are many types of ECUs in the car, which are responsible for controlling different functions and systems of the vehicle. These ECUs are usually distributed throughout the vehicle. The automotive ECU will take on more functions, such as vehicle automation control, intelligent interconnection, data interaction, etc.

[0140] The execution method of the test case shown in the above embodiments can also be applied to the scenario of testing ECU. In this scenario, ECU-TEST, as an embedded system test and verification software tool, has been widely used in automotive ECU development. However, due to the lack of ECU-TEST resources, it cannot meet the needs of every tester.

[0141] Therefore, the present invention contemplates deploying test cases in the cloud. Every time the vehicle controller needs to be tested, it only needs to be downloaded from the cloud, and the downloaded test cases can be executed through the test case execution methods shown in the above embodiments. This effectively solves the problem of scarce ECU-TEST resources and meets the usage needs of more testers.

[0142] Next, the execution method of the test case in the scenario of ECU testing is explained in detail.

[0143] In some embodiments, before parsing multiple test cases and obtaining the mapping file, variable name, and expression of each test case, a test case acquisition request may be sent to the server in response to the user's input operation on the vehicle controller test interface. The test case acquisition request is used to obtain the test case corresponding to the target bench information and the test requirement information, and the vehicle controller test interface is displayed through the browser. Afterwards, multiple test cases returned by the server are received.

[0144] In this step, after the user inputs the target bench information and test case requirement information in the test interface of the vehicle controller, the host computer can determine the test case acquisition request information corresponding to the vehicle controller test performed by the user based on the above information, and send the test case acquisition request information to the server side. If the server finds that the storage module contains a target test case that matches the test case requirement information, it will send the target test case and the test case identifier of the target test case to the host computer, that is, display it to the user in the vehicle controller test interface displayed by the browser.

[0145] The target test bench information refers to the specific hardware or simulation test bench information, such as the model, specifications and connection method of the test bench, etc. The test requirement information refers to the functions or performance requirements that the user wants to test, which may include specific test scenarios, conditions and operating parameters that the controller needs to go through.

[0146] Specifically, the user can access the vehicle controller test system through a browser, and input the corresponding bench information and test case requirement information in the test interface of the vehicle controller displayed in the browser. For example, the user can input the bench information and test case requirement information through simple operation input or selection operation of options in the test interface of the vehicle controller.

[0147] In the scenario of testing ECU, according to the code module corresponding to each test step type, the test case is executed in the preset execution order to control the target test bench to test the vehicle controller to be tested corresponding to the target test bench and obtain the test results. Specifically, due to the variety of controller types under test, if the test steps involve the interaction of multiple devices, it is necessary to automatically call the corresponding target HIL test bench.

[0148] Figure 7 FIG. 6 is a flow chart of the sixth embodiment of the method for executing a test case provided by the present invention. Figure 7 As shown, based on the first embodiment, S304 can be implemented by the following steps:

[0149] S701, start the target test software.

[0150] In this step, the target test software's application programming interface (API) or command line interface is automatically called through a programming interface or script (such as a pre-written python script), and then the startup command is executed to ensure that the target test software is correctly configured in the test environment for subsequent test case execution. The target test software is an application for controlling and monitoring the HIL simulation bench.

[0151] S702: Load and activate the test.

[0152] In this step, use the API call provided by the target test software, enter the model root path and project path provided by the user, automatically load the specific model project file, and check the return value during the loading process to ensure that the required control model can be correctly loaded into the target test software. Then, according to the set test path, call the corresponding API to activate the test configuration, ensuring that the model and test conditions are closely combined, which is convenient for subsequent analysis of test results.

[0153] S703, connect to the target rack and obtain variable attributes.

[0154] In this step, the target test software needs to be connected to the target test bench, for example, the Transmission Control Protocol (TCP) or other communication protocols can be used to connect to the target test bench to configure the required network parameters (such as Internet Protocol (IP) address and port number). After the target test software is successfully connected to the target test bench, the status information of the device can be obtained through the API to ensure that the connection is valid, thereby ensuring that the hardware device can be monitored and controlled in real time.

[0155] After the connection is successful, the properties of all model variables, such as name, type, current value, and status information, can be called through the API, and the above information can be stored in memory for subsequent access and analysis. Through the above connection, the function of each variable and its role in the model can be clearly defined, which is convenient for optimizing the execution process of test cases.

[0156] S704: Implement the reading and writing functions of the model variables and complete the automatic calling of the controller.

[0157] In this step, it is necessary to analyze the acquired variable attributes, identify their types (such as basic types, enumeration types, or array types), and then record each type of variable so that corresponding processing measures can be taken when performing subsequent read and write operations. Then, according to the acquired variable path, the model variables are automatically read and written, thereby realizing the automatic call of the controller.

[0158] Specifically, if you want to implement the model variable reading function, you can obtain all variable information according to the connected device, and then obtain the current value of the specified variable according to the given variable path, and store the current value of the variable obtained in a dictionary or list for subsequent processing. Then determine whether the variable is readable, for example, determine the type of the obtained variable. If the type is a basic type, you can directly perform a numerical reading operation. If the type is an enumeration type, you may need to map it to a more understandable string form.

[0159] To implement the write function of the model variable, you need to construct a new variable value (such as the value entered by the user) according to the test requirements, then obtain the specified variable according to the given variable path, and determine whether the variable is writable. If it is writable, write the new variable value to the model variable, and check the return value after each write to determine whether the write operation is successful. After completing the read or write operation of the model variable, the relevant functions of the controller can be triggered according to specific conditions or states.

[0160] In the above embodiment, the reading and writing functions of the model variables are realized, which not only enhances the automatic calling capability of the controller, but also ensures the flexibility and accuracy of the test process, improves the test efficiency, ensures that various model variables can be flexibly controlled and detected in the case of multi-device interaction, and improves the overall test efficiency.

[0161] Figure 8 FIG. 7 is a flow chart of the seventh embodiment of the method for executing a test case provided by the present invention. Figure 8 As shown, in Figure 7 During the execution of the embodiment shown, a large amount of data information is generated. In order to determine the implementation of the entire test case, the data information needs to be analyzed in real time. The analysis process includes:

[0162] S801. Determine the data type.

[0163] In this step, the data information generated in the test task is first classified, including obtaining the stored variable information, expression information, and expected value information from the memory. Then the type of each data information is identified, such as whether the variable information is an integer, floating point, or enumeration. After the data type is identified, the data information is classified and stored, which is convenient for direct call in subsequent analysis.

[0164] S802. Perform data analysis based on the data type and record the analysis results.

[0165] In this step, a detailed analysis will be performed based on the identified data type. For example, if the data type is a variable type, the analysis will be performed based on the type of the variable. For example, for an enumeration type (Enum), it is necessary to confirm whether the value of the variable is consistent with the expected enumeration attribute. If the data type is the expression information in the test step, the execution of the expression will be analyzed in combination with the value of the variable. If the calculation result of the expression meets the expectation, the result will be recorded. If it does not meet the expectation, an error analysis will be performed to identify the problem. If the data type is an expected value defined in advance, the execution of the expected value will be checked, and the expected value will be compared with the actual output value to record whether the expected value and the output value are consistent.

[0166] S803. Assemble assertion expressions and analyze assertion situations.

[0167] After completing the analysis of variables, expressions, and expected values, they are integrated into assertion expressions, which are a way to verify test behavior and are used to indicate the relationship between actual results and expected results.

[0168] Specifically, an assertion expression is constructed based on the analysis results of variables, expressions, and expected values, and the assertion expression is executed to compare the output result of the assertion expression with the expected result to determine whether the test passes. If the output result of the assertion expression is the same as the expected result, the test passes; otherwise, the test fails.

[0169] S804. Record variable status and analyze test task execution status.

[0170] Finally, the state of the variables and the changes in their stored values ​​are checked, for example, by monitoring whether the variables remain consistent during the test execution, where the state of the variables can reflect the stability of the test, or by recording the current value and state of the variables at each important execution stage to form a detailed execution log.

[0171] The above-mentioned embodiment uses a systematic method to determine data types, analyze variables and expressions, and generate assertion expressions, ensuring that each link has been fully verified. By comparing the actual results with the expected results, it can quickly identify abnormal situations in the test, thereby significantly improving the test efficiency. Finally, by monitoring the variable status and recording changes, it can determine the stability and reliability of the test process, providing data support for subsequent test case debugging and optimization, and ensuring the accuracy of the test results.

[0172] Fig. 9 FIG. 8 is a flow chart of an embodiment 8 of the method for executing a test case provided by the present invention. Fig. 9 As shown, the obtained test report can also be analyzed, which can be achieved through the following steps:

[0173] S901. Read the data generated during the test process to obtain the data information in the memory.

[0174] In this step, the test report function module can access various data generated during the test execution process. This data may include information such as variables in memory, mapped variables, expressions, expected expressions, etc. By reading this data, the test report function module can fully understand the status and results of the test process.

[0175] S902. Data analysis and report content splicing.

[0176] In this step, the read data is analyzed to extract valuable information, which will serve as the basic content of the test report. Then, according to the functional attributes of each test step, the extracted information is spliced ​​into a test report. Among them, the content of the test report includes multiple common fields, such as file name, step identifier (Identification, ID) and identification mark (such as type). For example, the step ID means that each step has a unique ID to ensure the traceability of the test steps. The identification mark type is marked as 0 and is used to distinguish the user's information dictionary.

[0177] S903: Basic step processing.

[0178] For basic test steps, the test report will contain the following field information: variable information, expression information, step name information, parameter result information, expected result information, step execution time, assertion result information, and mapping path information, etc. Among them, variable information indicates the status and content of the variables related to the test step, expression information indicates the expression used in the step and its execution result, step name information describes the name of the step, parameter result information indicates the parameters used when executing the step and its result, expected result information indicates the expected value compared with the actual result, step execution time is used to record the start and end time of the step for subsequent performance analysis, assertion result information indicates the assertion result of the step execution, indicating whether the test passes, and mapping path information indicates the path of the mapping file related to the step.

[0179] S904: Special step processing.

[0180] When the step is of tsPackage type, it means that a sub-use case package is called. In this case, the pre_id field needs to be added to identify the same sub-use case package used by the current use case. Among them, all test step report information nested in the sub-use case package will contain the pre_id identifier to ensure a clear hierarchical relationship.

[0181] For the TsLoop loop step, the test report data generated for each loop needs to contain the loop_counter field to identify the number of the current loop. This allows you to clearly understand the results of each loop when analyzing the loop execution.

[0182] In addition to writing the data analysis results into the test report, the data and situations during the execution will also be recorded in the log, which will provide a basis for subsequent debugging. Similarly, after the task is completed, the tester can check the generated test report at any time to verify the test results. At the same time, the test report and log will be written into the file for subsequent sharing and transmission.

[0183] The above embodiments can ensure the transparency and traceability of the test results. Through systematic report generation and log recording, the test process and results can be efficiently verified, providing a basis for improving the test strategy.

[0184] Fig.10 A schematic diagram of the structure of the test case execution device provided by the present invention, such as Fig.10 As shown, the test case execution device 10 includes a data acquisition module 101, a code generation module 102, a code acquisition module 103, and a result acquisition module 104.

[0185] The data acquisition module 101 is used to parse multiple test cases and obtain a mapping file, a variable name and an expression of each test case. The mapping file is used to indicate a mapping relationship between a variable name and an expression.

[0186] A code generation module 102, for generating test code for each test step in each test case according to the mapping file, variable name and expression of each test case;

[0187] A code acquisition module 103 is used to encapsulate the test codes of the same type of test steps and obtain a code module corresponding to each test step type;

[0188] The result acquisition module 104 is used to call the code module corresponding to the test step type to which each test step belongs in sequence according to a preset execution order to obtain the test results of multiple test cases.

[0189] In a possible implementation, the code generation module 102 is specifically configured to:

[0190] Parse each test step of each test case and determine the node attributes of the test step;

[0191] Generate test code for the test step according to the node attributes of the test step and the mapping file, variable name and expression of the test case.

[0192] In a possible implementation, the code module corresponding to each test step type includes a variable unit and a mapping file unit, the variable unit is used to store variable values ​​related to the test step corresponding to the test step type, and the mapping file unit is used to store the mapping file corresponding to the test step type.

[0193] In a possible implementation, the result acquisition module 104 is specifically configured to:

[0194] Step a: According to the current test step type, obtain the target code module corresponding to the current test step type;

[0195] Step b, calling the target code module according to the node attribute of the current test step to obtain the sub-test result of the current test step;

[0196] Step c: if it is determined according to the preset execution order that the current test step has a subsequent test step, the subsequent test step is determined as a new current test step;

[0197] Step d: if it is determined according to the preset execution order that the current test step does not have a subsequent test step, the sub-test result of the current test step is determined as the test result;

[0198] Repeat steps a to d until the test results are obtained.

[0199] In a possible implementation, after encapsulating the test codes of the same type of test steps and obtaining the code module corresponding to each test step type, the test case execution device 10 further includes a first storage module for storing the code module corresponding to each test step type to a first preset path;

[0200] Accordingly, the result acquisition module 104 is specifically used for:

[0201] The first preset path is traversed, and the target code module is obtained from the first preset path according to the current test step type.

[0202] In a possible implementation, the test case execution device 10 further includes a second storage module, which is used to store the code module input by the user to a second preset path;

[0203] Accordingly, the result acquisition module 104 is specifically used for:

[0204] The second preset path is traversed, and the target code module is obtained from the second preset path according to the current test step type.

[0205] In a possible implementation, before parsing multiple test cases to obtain a mapping file, a variable name, and an expression of each test case, the test case execution device 10 further includes:

[0206] A sending module, used to send a test case acquisition request to a server in response to a user's input operation on a vehicle controller test interface, wherein the test case acquisition request is used to acquire a test case corresponding to target test bench information and test requirement information, and the vehicle controller test interface is displayed through a browser;

[0207] The receiving module is used to receive multiple test cases returned by the server.

[0208] In a possible implementation, the result acquisition module 104 is specifically configured to:

[0209] According to the code module corresponding to each test step type, the test case is executed in a preset execution order to control the target test bench to test the vehicle controller to be tested corresponding to the target test bench and obtain the test result.

[0210] In one possible implementation, after parsing multiple test cases and obtaining the mapping file, variable name and expression of each test case, the test case execution device 10 also includes a third storage module for storing the mapping file, variable name and expression of each test case in the memory.

[0211] The test case execution device provided in the embodiments of the present application can be used to execute the test case execution method in any of the above embodiments. Its implementation principles and technical effects are similar and will not be repeated here.

[0212] Fig.11 This is a schematic diagram of the structure of an electronic device provided by the present invention. Fig.11 As shown, the electronic device 110 includes:

[0213] Processor 111, memory 112, and communication interface 113;

[0214] The memory 112 is used to store executable instructions of the processor 111;

[0215] Among them, the processor 111 is configured as executable instructions to execute the technical solution of any of the aforementioned method embodiments.

[0216] Optionally, the memory 112 may be independent or integrated with the processor 111 .

[0217] Optionally, when the memory 112 is a device independent of the processor 111, the electronic device 110 may further include:

[0218] A bus is used to connect the above devices.

[0219] The electronic device is used to execute the technical solution in any of the aforementioned method embodiments, and its implementation principle and technical effect are similar and will not be repeated here.

[0220] In the scenario of testing the vehicle controller, the electronic device 110 can be implemented as a host computer.

[0221] An embodiment of the present invention further provides a readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the technical solution provided by any of the aforementioned embodiments is implemented.

[0222] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0223] The above embodiments are only preferred embodiments for fully illustrating the present invention, and the protection scope of the present invention is not limited thereto. Any equivalent substitution or change made by a person skilled in the art based on the present invention is within the protection scope of the present invention.

Claims

1. A method for executing a test case, characterized in that: The method comprises: Parsing multiple test cases to obtain a mapping file, a variable name, and an expression for each test case, wherein the mapping file is used to represent a mapping relationship between the variable name and the expression; Generate test code for each test step in each test case based on the mapping file, variable name and expression of each test case; Encapsulate the test codes of the same type of test steps and obtain the code module corresponding to each test step type; According to the preset execution order, the code modules corresponding to the test step type to which each test step belongs are called in sequence to obtain the test results of the multiple test cases.

2. The method according to claim 1, characterized in that The method of generating the test code for each test step in each test case according to the mapping file, variable name and expression of each test case includes: Parsing each test step of each test case to determine the node attributes of the test step; The test code of the test step is generated according to the node attributes of the test step and the mapping file, variable name and expression of the test case.

3. The method according to claim 1 or 2, characterized in that: The code module corresponding to each test step type includes a variable unit and a mapping file unit, wherein the variable unit is used to store variable values ​​related to the test step corresponding to the test step type, and the mapping file unit is used to store a mapping file corresponding to the test step type.

4. The method according to claim 1 or 2, characterized in that: The step of sequentially calling the code modules corresponding to the test step type to which each test step belongs according to the preset execution order to obtain the test results of the multiple test cases includes: Step a: According to the current test step type, obtain the target code module corresponding to the current test step type; Step b, calling the target code module according to the node attribute of the current test step to obtain the sub-test result of the current test step; Step c: if it is determined according to the preset execution order that the current test step has a subsequent test step, then the subsequent test step is determined as a new current test step; Step d: if it is determined according to the preset execution order that the current test step does not have the subsequent test step, then the sub-test result of the current test step is determined as the test result; Repeat step a to step d until the test result is obtained.

5. The method according to claim 4, characterized in that After encapsulating the test codes of the same type of test steps and obtaining the code module corresponding to each test step type, the method further includes: Storing the code module corresponding to each test step type in a first preset path; Correspondingly, obtaining the target code module corresponding to the current test step type according to the current test step type includes: Traverse the first preset path, and obtain the target code module from the first preset path according to the current test step type.

6. The method according to claim 4, characterized in that The method further comprises: Storing the code module input by the user to a second preset path; Correspondingly, obtaining the target code module corresponding to the current test step type according to the current test step type includes: The second preset path is traversed, and the target code module is obtained from the second preset path according to the current test step type.

7. The method according to claim 1 or 2, characterized in that: Before parsing the multiple test cases to obtain the mapping file, variable name and expression of each test case, the method further includes: In response to a user input operation on a vehicle controller test interface, a test case acquisition request is sent to a server, wherein the test case acquisition request is used to acquire a test case corresponding to target bench information and test requirement information, and the vehicle controller test interface is displayed through a browser; Receive multiple test cases returned by the server.

8. The method according to claim 7, characterized in that The step of executing the test cases in a preset execution order according to the code modules corresponding to each test step type to obtain the test results includes: According to the code module corresponding to each test step type, the test case is executed in a preset execution order to control the target test bench to test the vehicle controller to be tested corresponding to the target test bench and obtain the test result.

9. The method according to claim 1 or 2, characterized in that: After parsing the multiple test cases to obtain the mapping file, variable name and expression of each test case, the method further includes: Stores the mapping file, variable names, and expressions for each test case into memory.

10. A test case execution device, characterized in that: The device comprises: A data acquisition module is used to parse multiple test cases and obtain a mapping file, a variable name and an expression for each test case, wherein the mapping file is used to represent a mapping relationship between the variable name and the expression; A code generation module, used to generate test code for each test step in each test case according to the mapping file, variable name and expression of each test case; A code acquisition module is used to encapsulate the test codes of the same type of test steps and obtain the code module corresponding to each test step type; The result acquisition module is used to execute the test cases in a preset execution order according to the code modules corresponding to each test step type and obtain the test results.

11. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, they are used to implement the test case execution method according to any one of claims 1 to 9.

Images