Interface test case generation method and device, vehicle and storage medium

Abstract

The invention provides an interface test case generation method and device, a vehicle and a storage medium, and relates to the technical field of software testing. The method comprises the steps of obtaining a data dictionary file of at least one to-be-tested model; for each data dictionary file, interface information corresponding to each interface contained in the file is extracted, and the interface information comprises the data type and the extreme value of the input signal; for the input signal of each interface, determining test data of the input signal according to the data type and the extreme value of the input signal; the test data comprises a boundary value, an intermediate value and an invalid value; and according to a preset arrangement rule, arranging the test data of the input signals corresponding to the interfaces to obtain a test case corresponding to each data dictionary file. According to the method, the test cases of the multiple models can be automatically generated in batches, the time for manually compiling the test cases is shortened, the design efficiency of the test cases is improved, and then the interface test efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and in particular to a method, apparatus, vehicle, and storage medium for generating interface test cases. Background Technology

[0002] In the automotive electronics software development process, software systems require testing, including unit testing, integration testing, and software conformance testing. These testing phases are necessary at every stage of actual project development to ensure software functionality, performance stability, and security. These testing phases consume significant time and effort, especially the model interface testing within the integration testing phase. Due to the large number of interfaces, numerous test cases are needed to cover various scenarios. Therefore, avoiding repetitive testing work and reducing the time spent on test case design and execution is crucial.

[0003] In related technologies, model interface testing involves testing the interfaces exposed by models in a software system. By simulating different calling scenarios, it verifies the correctness of the interface's input data processing logic, output results, and stability under various boundary conditions. The method involves manually identifying the input / output numerical range and data type of each model interface, then designing test cases adapted to the testing tool, and finally using that tool to perform interface testing.

[0004] However, due to the large number and wide variety of model interfaces, the process of designing test cases requires a lot of time to identify the data range and data type of various interfaces, and then design data values ​​that can cover various interface call scenarios based on these contents. Then, test cases are written based on various data values. This not only involves a large workload and a long time, but also has high repetition, resulting in low efficiency in test case design and interface testing. Summary of the Invention

[0005] This application provides a method, apparatus, vehicle, and storage medium for generating interface test cases, in order to solve the technical problems in the prior art where writing test cases involves a large workload, takes a long time, and is highly repetitive, thus leading to low efficiency in test case design and interface testing.

[0006] Firstly, embodiments of this application provide a method for generating interface test cases, including: Obtain at least one data dictionary file for the model to be tested; For each data dictionary file, extract the interface information corresponding to each interface contained in the file. The interface information includes the data type and maximum / minimum value of the input signal. For each interface's input signal, test data for the input signal is determined based on the data type and maximum / minimum value of the input signal; the test data includes boundary values, intermediate values, and invalid values. According to the preset arrangement rules, the test data of the input signals corresponding to each interface are arranged and processed to obtain the test cases corresponding to each data dictionary file.

[0007] Based on the above technical content, this application embodiment obtains at least one data dictionary file of the model to be tested. Since the data dictionary file records relevant information of all interfaces of the model, interface information, including data type and maximum / minimum values, can be directly extracted from each data dictionary file. For the input signal of each interface in a data dictionary file, test data is calculated according to its data type and maximum / minimum values, including boundary values, intermediate values, and invalid values. The test data of all input signals in the data dictionary file is obtained. Finally, the test data of the input signals corresponding to each interface in the data dictionary file are arranged according to a preset rule to generate test cases corresponding to the data dictionary file. Performing the same operation on multiple data dictionary files can obtain test cases corresponding to each data dictionary file, realizing batch processing of model data dictionary files and automated generation of interface test cases, reducing the time spent manually writing test cases, solving the problems of large workload, long time consumption, and high repetition caused by manually identifying interface information and designing test cases in the prior art, reducing manual operation costs, improving the efficiency of test case design, and thus improving the efficiency of interface testing; and the test data covers boundary values, intermediate values, and invalid values ​​to ensure comprehensive test scenarios, avoid key test scenarios that may be missed during manual design, and improve the completeness of testing.

[0008] In one possible implementation, the boundary values ​​include a lower boundary value and an upper boundary value; the step of arranging the test data of the input signals corresponding to each interface according to a preset arrangement rule includes: For each data dictionary file, the lower boundary value, median value, and upper boundary value of all input signals in the file are concatenated row by row to obtain the first two-dimensional structure data; wherein, the lower boundary value, median value, and upper boundary value of each input signal occupy a separate column in the first two-dimensional structure data; The middle value of each input signal is used as the padding value to fill the empty values ​​in the corresponding column of each input signal in the first two-dimensional structure data, thus obtaining the second two-dimensional structure data. The invalid value of each input signal is concatenated with the second two-dimensional structure data row by row to obtain the third two-dimensional structure data; Based on the third two-dimensional structure data, test cases corresponding to the data dictionary file are generated.

[0009] In this embodiment, the composition of boundary values ​​(including upper and lower boundary values) and their specific arrangement rules are defined. The lower boundary value, intermediate value, and upper boundary value are all valid values. Valid data (lower boundary value, intermediate value, and upper boundary value) are first concatenated row by row to ensure that the lower boundary value, intermediate value, and upper boundary value of each input signal occupy a separate column in the concatenated first two-dimensional structure data, and each row corresponds to one valid value for one input signal (other input signals in that row are empty values). The intermediate value of the input signal is then used to fill the empty values ​​in the column containing that input signal, thereby ensuring that when testing a certain interface, the input signals of other interfaces are all valid values ​​(intermediate values). This avoids mutual interference between input signals from different interfaces, making single-interface testing scenarios more accurate and improving test targeting. Furthermore, by "concatenating invalid value data," it specifically covers "all interfaces having invalid values." This approach addresses the shortcomings of existing technologies in testing for abnormal inputs, comprehensively verifies the model's ability to handle invalid inputs, and enhances the rigor of testing. The standardized arrangement rules make the test case structure clear, covering all test scenarios with minimal data, facilitating subsequent maintenance and modification, and reducing test case management costs while covering all interface testing scenarios.

[0010] In one possible implementation, concatenating the lower boundary values, intermediate values, and upper boundary values ​​of all input signals in the file row by row to obtain the first two-dimensional structure data includes: The lower boundary value, intermediate value, and upper boundary value of each input signal are treated as a single-column structured data, and a column index is specified; the column index is determined according to the extraction order of the input signals. According to the extraction order of the input signals, the single-column structure data corresponding to each input signal is sequentially concatenated with the preset two-dimensional structure data row by row, and the row index is reset once for each row concatenation of the single-column structure data of an input signal, until the single-column structure data of all input signals in the data dictionary file are concatenated to obtain the first two-dimensional structure data; wherein, the preset two-dimensional structure data is initially empty.

[0011] In this embodiment, the lower boundary value, median value, and upper boundary value of each input signal are treated as a single-column structured data, and column indices are specified according to the extraction order of the input signals. This ensures that the test data of each input signal occupies a dedicated column, and the initial predicted two-dimensional structured data is null. Then, the single-column structured data (test data) of the first input signal, the second input signal, and so on are sequentially concatenated with the preset two-dimensional structured data row by row. Since concatenating the single-column structured data of one input signal increases the number of rows by three (i.e., the lower boundary value, median value, and upper boundary value rows), the row index is reset once, ensuring the orderliness of the data structure, avoiding the chaos caused by the mixing of multiple signal data, and reducing errors in the data processing process. Furthermore, the independent processing of each column allows the test data of each signal to be maintained separately, which facilitates subsequent adjustment of the test data for specific signals (such as modifying boundary values), improving the flexibility and maintainability of the test cases.

[0012] In one possible implementation, the invalid values ​​include lower boundary values ​​and upper boundary values; The step of concatenating invalid values ​​of each input signal with the second two-dimensional structure data row by row to obtain the third two-dimensional structure data includes: Invalid two-dimensional structure data is determined based on the lower boundary value and upper boundary value of each input signal, and row and column indices are specified; the column indices are determined according to the extraction order of the input signals; each column in the invalid two-dimensional structure data corresponds to the lower boundary value and upper boundary value of an input signal, and each row is the lower boundary value or upper boundary value of all input signals; The invalid two-dimensional structure data is concatenated with the second two-dimensional structure data row by row, and the row index of the second two-dimensional structure data is reset to obtain the third two-dimensional structure data...

[0013] In this embodiment, the types of invalid values ​​are defined, including lower boundary values ​​and upper boundary values, and the concatenation logic for invalid data is specified. This adds a test scenario where all input signals are invalid, making the model's response to abnormal inputs more accurate. Since the column index of the invalid two-dimensional structure data is consistent with the column index of the first and second two-dimensional structure data, row-by-row concatenation ensures that invalid data from different input signals are not misaligned. Furthermore, the invalid two-dimensional structure data and the second two-dimensional structure data are concatenated row-by-row, with each row representing the same type of invalid value (such as lower boundary or upper boundary value) for all input signals. This ensures the completeness of the invalid scenario (covering the situation where all signals are simultaneously abnormal), improving the comprehensiveness of the model's robustness testing.

[0014] In one possible implementation, the interface information further includes the name and initial value of the input signal; generating test cases corresponding to the data dictionary file based on the third two-dimensional structure data includes: For each data dictionary file, a two-dimensional structure of initial values ​​is generated based on the names and initial values ​​of all input signals in the file, and row and column indices are specified. The column indices are determined according to the extraction order of the input signals. Each column in the two-dimensional structure of initial values ​​corresponds to the name and initial value of an input signal. The first row contains the names of all input signals, and the second row contains the initial values ​​of all input signals. The initial two-dimensional structure data and the third two-dimensional structure data are concatenated row by row, and the row index is reset to obtain the target two-dimensional structure data; the first row of the test data in the target two-dimensional structure data is the initial value of each input signal; Based on the target two-dimensional structure data, test cases corresponding to the data dictionary file are generated.

[0015] In this embodiment, including "input signal name" makes the correspondence between test cases and model interfaces clearer, reduces confusion when mapping test cases to model interfaces, and lowers the mapping cost when importing test tools. Furthermore, adding the initial values ​​of all input signals as the first row of test data ensures that the first cycle of model operation is the initial value, covering the initial running state when the model starts. This overcomes the deficiency of ignoring initial state testing in the prior art, making the test more in line with the actual running scenario and improving the realism of interface testing.

[0016] In one possible implementation, the method further includes: determining the test time corresponding to each row of test data based on the number of rows of test data in the target two-dimensional structure data and the model running cycle, thereby obtaining a test time series; Insert the test time series into the target two-dimensional structure data, and specify the column index of the test time series as 0 to obtain the target two-dimensional structure data with the test time series; Based on the target two-dimensional structure data with test time series, test cases adapted to the testing tool are generated.

[0017] In this embodiment, a time series is automatically generated based on the number of test data rows and the model running cycle, avoiding the tedious manual calculation of test time and reducing the workload and error rate of time dimension processing. Furthermore, the test time series is inserted into the first column of the target two-dimensional structure data, with the specified column index as 0, so that the test cases meet the format requirements of the testing tool for time and input signals, facilitating direct adaptation and import into the testing tool, improving the efficiency of automated testing, and solving the problem of having to re-edit the time information when changing testing tools in the prior art. This improves the compatibility of test cases and the efficiency of tool adaptation. When the testing tool is imported for interface testing, each row of test data can be automatically called sequentially according to the test time series to test the input signals of each interface, further improving the efficiency of interface testing.

[0018] In one possible implementation, the extreme values ​​include a maximum value and a minimum value; for each interface's input signal, determining the test data for the input signal based on the data type and extreme values ​​of the input signal includes: Following the extraction order of the input signals from each interface, the steps of calculating test data are performed sequentially for each input signal until the test data of all input signals in a data dictionary file has been calculated, thus obtaining the test data of each input signal in the data dictionary file. The steps for calculating the test data include: Based on the data type, maximum value, and minimum value of the input signal, determine the lower boundary value, upper boundary value, and intermediate value of the input signal; Values ​​exceeding the lower boundary that are less than the lower boundary value and values ​​exceeding the upper boundary that are greater than the upper boundary value are considered invalid values.

[0019] In this embodiment, test boundary values, intermediate values, and invalid values ​​are explicitly calculated based on data type and maximum and minimum values. This ensures that test data for different types of signals (such as integers, floating-point numbers, enumeration values, etc.) conforms to their type characteristics, avoiding invalid test data due to type mismatch and improving the accuracy of test data. Furthermore, the test data for each input signal is calculated iteratively according to the extraction order of the input signals, improving the efficiency of automatic calculation. The standardized calculation process ensures the consistency of test data generation, giving test cases for different models and signals a unified standard and improving the standardization of interface testing.

[0020] Secondly, embodiments of this application provide an apparatus for generating interface test cases, comprising: The acquisition module is used to acquire at least one data dictionary file for the model to be tested. The extraction module is used to extract the interface information corresponding to each interface contained in each data dictionary file. The interface information includes the data type and maximum / minimum value of the input signal. The calculation module is used to determine the test data of the input signal for each interface based on the data type and maximum / minimum value of the input signal; the test data includes boundary values, intermediate values, and invalid values. The processing module is used to arrange and process the test data of the input signals corresponding to each interface according to a preset arrangement rule, so as to obtain the test cases corresponding to each data dictionary file.

[0021] Thirdly, embodiments of this application provide a vehicle including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the computer program, it implements the method for generating interface test cases as described in any of the first aspects.

[0022] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method for generating interface test cases as described in any of the first aspects.

[0023] It is understood that the beneficial effects of the second to fourth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here.

[0024] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of this application; Figure 2 This is a flowchart illustrating a method for generating interface test cases according to an embodiment of this application; Figure 3 This is a flowchart illustrating a method for generating interface test cases according to another embodiment of this application; Figure 4 This is a flowchart illustrating a method for generating interface test cases according to another embodiment of this application; Figure 5 This is a schematic diagram of the structure of an interface test case generation device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a vehicle provided in one embodiment of this application. Detailed Implementation

[0027] The present application will be described more clearly below with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the function of the present application, but do not limit the present application in any way. It should be noted that those skilled in the art can make several modifications and improvements without departing from the concept of the present application. These all fall within the protection scope of the present application.

[0028] In the automotive electronics software development process, software systems require testing, including unit testing, integration testing, and software conformance testing. These testing stages are necessary at every phase of actual project development to ensure software functionality, performance stability, and reliability. These testing stages consume significant time and effort, especially model interface testing within the integration testing phase. This involves simulating different calling scenarios to verify the interface's processing logic for input data, the correctness of output results, and the stability of the interface under various boundary conditions, ensuring the model interface can correctly receive requests and return expected results. However, due to the large number of interfaces, a large number of test cases are needed to cover various scenarios. Therefore, avoiding repetitive testing work to reduce test case design and execution time is crucial. For interface testing, the test case design approach is relatively clear, based on the range and data type of the model's input signals, and the design approach is generally consistent across different projects. However, the workload is substantial, making automated test case generation a primary goal. Furthermore, most automotive electronics software testing tools on the market support importing Excel spreadsheets for testing. These tools can recognize Excel spreadsheets containing test input interfaces, model runtime cycles, and expected model outputs. After importing the table into the testing tool, you only need to map the input and output interfaces to the actual interfaces identified by the model or code in the testing tool (generally, the input and output interface names in the test cases are consistent with the actual model or code, so the mapping workload is very small).

[0029] However, due to the large number and wide variety of model interfaces, the traditional process of designing interface test cases requires a lot of time to identify the data range and data type of various interfaces, then design data values ​​that can cover various interface call scenarios, and then write test cases based on various data values. This is not only labor-intensive and time-consuming, but also highly repetitive. If the testing tool is switched, the test cases need to be adapted to the new tool, and even all test cases need to be re-edited on the new tool. Therefore, the efficiency of test case design and interface testing is low.

[0030] To reduce test case design time for model interface testing, a method for automatically generating model interface test cases is proposed. This method extracts information such as the name, initial value, data type, maximum value, and minimum value of different input interfaces from the model's corresponding data dictionary. Then, based on the data type, maximum value, and minimum value of different input signals, intermediate values, invalid values, and boundary values ​​are calculated iteratively. For the test data of all input signals in the same data dictionary file, the test data is arranged according to a format compatible with the testing tool and to minimize the impact of different input signals on the expected output. The resulting test data meets the following requirements: each input signal's test data occupies one column; the data from the first cycle of model execution is the initial value; when testing a specific input signal, all other input signals remain within the valid range (usually intermediate values). The test cases include scenarios where all input signals are invalid. After arranging the data, the test time is filled into the first column of the test data according to the model's runtime cycle to obtain the test cases corresponding to that data dictionary. By performing the same operation repeatedly on multiple model data dictionary files, test cases can be obtained for each data dictionary file. This enables batch generation of model data dictionary files and automated generation of interface test cases, reducing the time spent manually writing test cases. It solves the problems of high workload, long time consumption, and high repetition caused by manually identifying interface information and designing test cases in existing technologies, reducing manual operation costs, improving the efficiency of test case design, and thus improving the efficiency of interface testing. Furthermore, the test data covers boundary values, intermediate values, and invalid values, ensuring comprehensive test scenarios and avoiding key test scenarios that may be missed during manual design, thereby improving the completeness of the test.

[0031] First refer to Figure 1 , Figure 1 The schematic diagram illustrates an application scenario provided according to an embodiment of this application, in which the devices involved include a server 101 and a display device 102.

[0032] In this application scenario, server 101 stores data dictionaries for multiple models to be tested, and deploys the models to be tested and testing tools. The central processing unit in server 101 extracts relevant interface information from the data dictionary file, generates test cases based on the interface information, and sends the test cases to display device 102 for display. Then, the test cases are imported into the testing tool, and the interface of the model is tested through the testing tool. The test results are sent to display device 102 for display.

[0033] The following is combined with Figure 1 Application scenarios, refer to Figures 2-4This document describes a method for generating interface test cases according to exemplary embodiments of this application. It should be noted that the above application scenarios are shown only to facilitate understanding of the spirit and principles of this application, and the embodiments of this application are not limited in any way. Rather, the embodiments of this application can be applied to any applicable scenario.

[0034] It should be noted that the implementation methods of this application can be applied to vehicles, and the vehicle can be a server or a host of the vehicle, that is, the interface test case generation method provided by the exemplary implementation method of this application can be executed on the server or the host of the vehicle.

[0035] It should be noted that the method for generating interface test cases according to the exemplary embodiments of this application can be executed on the same device or on different devices.

[0036] refer to Figure 2 , Figure 2 This is a flowchart illustrating a method for generating interface test cases according to an embodiment of this application. Figure 2 As shown, the method in the embodiments of this application may include: Step S201: Obtain at least one data dictionary file for the model to be tested.

[0037] In this step, the model's data dictionary is a standardized description document of the data elements (such as fields, interface parameters, entities, etc.) and their attributes in the model. It is used to define the structure, meaning, relationships, and constraints of the data, and typically provides a basis for data governance, interface documentation, and test case design. A complete data dictionary entry usually contains basic information about the data elements (such as name and data type), data constraints, and business rules (such as value range, etc.). This information is usually represented in the form of an Excel spreadsheet. One data dictionary corresponds to one model under test. The data dictionary file for each model under test can be automatically exported using an Object Relational Mapping Framework (ORM), resulting in an Excel spreadsheet file corresponding to each of the multiple models under test.

[0038] Step S202: For each data dictionary file, extract the interface information corresponding to each interface contained in the file. The interface information includes the data type and maximum / minimum value of the input signal.

[0039] Among them, extreme values ​​include the maximum value and the minimum value.

[0040] In this step, each data dictionary file corresponds to an Excel spreadsheet. For each Excel spreadsheet, a specific sheet is obtained, and data such as the name, data type, initial value, maximum value, and minimum value of the input signal of the input interface are extracted from that specific sheet.

[0041] Step S203: For the input signal of each interface, determine the test data of the input signal according to the data type and maximum / minimum value of the input signal; the test data includes boundary values, intermediate values ​​and invalid values.

[0042] Boundary values ​​can include upper and lower boundary values, while invalid values ​​are values ​​outside the valid range of the input signal.

[0043] In this step, a data dictionary file contains input signals for multiple interfaces. For each input signal, based on its data type and maximum and minimum values, boundary values, intermediate values, and invalid values ​​are calculated iteratively as test data. By iteratively calculating the test data for each input signal, test data for all input signals within the data dictionary is obtained.

[0044] For example, if the data type of input signal A is an integer, with a maximum value of 10 and a minimum value of 0, then the upper boundary value is 10, the lower boundary value is 0, and the intermediate value can be any value between 0 and 10. Invalid values ​​are those outside the valid range of 0 to 10, such as 11 or -1. If the data type of input signal B is an enumeration value, and its value is a set such as {20, 22, 24, 26, 28}, then the boundary values ​​are the minimum and maximum elements in the enumeration set, i.e., the upper boundary value is 28, the lower boundary value is 20, and the intermediate value is the middle element between the maximum and minimum elements, such as 22, 24, or 26. Values ​​outside the set are invalid (such as 19, 21, 23, 29, etc.).

[0045] It should be noted that the calculation method of test data varies depending on the data type of the input signal, which will not be listed here.

[0046] Step S204: According to the preset arrangement rules, the test data of the input signals corresponding to each interface are arranged and processed to obtain the test cases corresponding to each data dictionary file.

[0047] In this step, the test data for all input signals in the same data dictionary file are arranged according to a preset sorting rule. The final test cases include a header (such as the input signal name), test time, and the corresponding test dataset. The preset rule is based on two considerations: the format that the testing tool can adapt to and minimizing the impact of different input signals on the expected output. This ensures that the final arranged test data meets the following requirements: the test data for each input signal corresponding to each input interface occupies a separate column in the test dataset; the first row of data in the test dataset contains the initial values ​​of each input signal; when testing any input signal, the test data for other input signals are all intermediate values ​​within the valid value range; and the test dataset includes test scenarios where all input signals have invalid values.

[0048] For each data dictionary file corresponding to multiple models to be tested, repeat the above steps in a loop to obtain test cases for each model to be tested.

[0049] In this embodiment, the data dictionary file of the model is processed in batches and interface test cases are generated automatically, reducing the time spent manually writing test cases. This solves the problems of large workload, long time consumption and high repetition caused by manually identifying interface information and designing test cases in the prior art, reducing manual operation costs, improving the efficiency of test case design, and thus improving the efficiency of interface testing. In addition, the test data covers boundary values, intermediate values ​​and invalid values, ensuring comprehensive test scenarios and avoiding key test scenarios that may be missed during manual design, thereby improving the completeness of the test.

[0050] Figure 3 This is a flowchart illustrating a method for generating interface test cases according to another embodiment of this application. This embodiment describes the automated generation process of interface test cases in detail from the overall perspective of the solution.

[0051] like Figure 3 As shown, the method includes: Step S301: Obtain at least one data dictionary file for the model to be tested.

[0052] For each data dictionary file, perform the following test case generation process, including steps S302 to S311: Step S302: Extract the interface information corresponding to each interface contained in the file. The interface information includes the data type and maximum / minimum value of the input signal.

[0053] Step S303: For the input signal of each interface, determine the test data of the input signal according to the data type and maximum / minimum value of the input signal; the test data includes boundary values, intermediate values ​​and invalid values.

[0054] It should be noted that in this embodiment, different data types have different definitions and numerical ranges for the boundaries. Therefore, the lower boundary value and the upper boundary value need to be determined according to the data type of the input signal.

[0055] Specifically, the data type determines the valid range of values ​​and how boundary values ​​are determined. Data types typically include integers, floating-point numbers, and enumerated values. For integers, the boundary values ​​are discrete integers, such as a minimum value of 0 and a maximum value of 10, with the boundary values ​​being 0 and 10. The intermediate value can be any value between 0 and 10, and is usually the average of the upper and lower boundary values ​​(minimum value + maximum value) / 2 (e.g., the intermediate value between 0 and 10 is 5). Invalid values ​​are those that exceed the valid range, such as -1 and 11. For floating-point numbers, the boundary values ​​are the endpoints of a continuous interval. For example, if the minimum value is 0.0 and the maximum value is 10.0, then the boundary values ​​can be 0.0 and 10.0, or approximate values ​​within the precision range. The intermediate value can be any value within the continuous interval of 0.0 to 10.0, such as 4.9, 5.2, etc. In general, the intermediate value is (minimum value + maximum value) / 2; for example, the intermediate value between 0.0 and 10.0 is 5.0. Invalid values ​​are values ​​that are outside the valid value range of 0.0 to 10.0, such as -1.0, 11.0, etc. For enumerated value types, such as {1, 3, 5}, the boundary values ​​are the minimum and maximum elements in the enumeration set, with the lower boundary value being 1 and the upper boundary value being 5. The middle value is the middle element in the set. For example, the middle value of the set {1, 3, 5} is 3. When the set contains multiple middle elements, any one of them can be used as the middle value. For example, in the set {1, 3, 5, 7}, the lower boundary value is 1, the upper boundary value is 7, and the middle value is either 3 or 5. When the set has a large number of elements, the middle value can be the value closest to the middle among the multiple middle elements. For example, in the set {1, 3, 5, 7, 9, 11, 13}, 3, 5, 7, 9, and 11 can all be used as the middle value, but usually the element closest to the middle, 7, is used as the middle value. For enumeration sets, values ​​outside the set are invalid values. For example, in the set {1, 3, 5, 7}, -1, 2, 4, and 8 are invalid values.

[0056] In one possible implementation, for each interface's input signal, test data for the input signal is determined based on the input signal's data type and maximum / minimum value. This includes: sequentially performing the test data calculation steps for each input signal according to the extraction order of the input signals for each interface, until the test data for all input signals in a data dictionary file has been calculated, resulting in test data for each input signal in the data dictionary file. The test data calculation steps include: determining the lower boundary value, upper boundary value, and intermediate value of the input signal based on its data type, maximum value, and minimum value; and treating values ​​below the lower boundary value and values ​​above the upper boundary value as invalid values.

[0057] In this embodiment, a data dictionary file contains multiple input signals. It is necessary to obtain the number of input signals in the data dictionary file, for example, a total of i input signals. For the i input signals, the data type, maximum value and minimum value of each input signal are extracted in sequence. According to the extraction order, the test data of each input signal is calculated in a loop until the test data of all i input signals in the data dictionary file has been calculated, and then the loop stops.

[0058] In this embodiment, test boundary values, intermediate values, and invalid values ​​are explicitly calculated based on data type and maximum and minimum values. This ensures that test data for different types of signals (such as integers, floating-point numbers, enumeration values, etc.) conforms to their type characteristics, avoiding invalid test data due to type mismatch and improving the accuracy of test data. Furthermore, the test data for each input signal is calculated iteratively according to the extraction order of the input signals, improving the efficiency of automatic calculation. The standardized calculation process ensures the consistency of test data generation, giving test cases for different models and signals a unified standard and improving the standardization of interface testing.

[0059] Step S304: For each data dictionary file, concatenate the lower boundary value, intermediate value, and upper boundary value of all input signals in the file row by row to obtain the first two-dimensional structure data; wherein, the lower boundary value, intermediate value, and upper boundary value of each input signal occupy a separate column in the first two-dimensional structure data.

[0060] Among them, the lower boundary value, the middle value, and the upper boundary value are all valid values.

[0061] In this step, row-by-row concatenation is used to merge test data from different input signals (such as the upper boundary values, median values, and lower boundary values ​​of multiple input signals). This means that each input signal's test data occupies one column, and each input signal's test data consists of 3 rows (one row for the upper boundary value, one row for the median value, and one row for the lower boundary value). By concatenating the test data of multiple input signals row by row, the number of rows increases, and the final number of rows is the sum of the number of rows for each input signal's test data. For example, if there are 6 input signals, and each input signal has 3 rows of test data, then the final number of rows after concatenation will be 3 * 6 = 18 rows. The number of columns increases as the number of input signals being concatenated increases, and the final number of columns equals the number of input signals. The purpose of row-by-row concatenation is to integrate all possible test scenarios, such as valid value testing of a single input signal, boundary value testing of a single input signal, etc.

[0062] In one possible implementation, the lower boundary value, intermediate value, and upper boundary value of all input signals in the file are concatenated row by row to obtain the first two-dimensional structure data. This includes: treating the lower boundary value, intermediate value, and upper boundary value of each input signal as a single-column structure data and specifying a column index; the column index is determined according to the extraction order of the input signals; according to the extraction order of the input signals, the single-column structure data corresponding to each input signal is sequentially concatenated row by row with the preset two-dimensional structure data, and the row index is reset once every time the single-column structure data of an input signal is concatenated row by row, until the single-column structure data of all input signals in the data dictionary file are concatenated to obtain the first two-dimensional structure data; wherein, the preset two-dimensional structure data is initially empty.

[0063] In this embodiment, the test data of each input signal is converted into single-column structured data, that is, the test data of one input signal occupies one column, the lower boundary value, the middle value and the upper boundary value each occupy one row, and the column index is specified according to the order in which the input signals are extracted.

[0064] For example, there are three input signals in the data dictionary file. The information of input signal A and input signal B are extracted in the order of extraction, as shown in Table 1.

[0065] Table 1

[0066] Then, the test data for input signal A and signal B are calculated sequentially, resulting in the following test data for signal A and signal B: Signal A: Lower boundary value = 0, middle value = 5, upper boundary value = 10, invalid values ​​= -1, 11.

[0067] Signal B: Lower boundary value = 20, middle value = 24, upper boundary value = 28, invalid values ​​= 19, 29.

[0068] Convert the test data of signal A into a single-column structure and specify the column index as 1; then convert the test data of signal B into a single-column structure and specify the column index as 2.

[0069] Initially, the preset two-dimensional structure data is empty. When processing the first input signal A, the test data (single-column structure data) of signal A is concatenated with the empty preset two-dimensional structure data row by row, and the row index is reset. Each row corresponds to one test data of signal A. The preset two-dimensional structure data containing the test data of signal A is obtained. Then, signal B is processed. The test data (single-column structure data) of signal B is concatenated with the preset two-dimensional structure data row by row, and the row index is reset. The first two-dimensional structure data containing the test data of signal A and signal B is obtained. The first column of the first two-dimensional structure data is the test data of signal A, the second column is the test data of signal B, and each row corresponds to a valid value (lower boundary value, middle value, or upper boundary value) of an input signal.

[0070] For example, the test data of signal A can be converted into single-column structured data (column index is 1, corresponding to signal A), as shown in Table 2; Table 2

[0071] The single-column structure data of signal A is concatenated with the preset two-dimensional structure data row by row. The initial preset two-dimensional structure data is empty. The concatenated preset two-dimensional structure data is shown in Table 3.

[0072] Table 3

[0073] Then process signal B, converting the test data of signal B into a single-column structure input (column index is 2, corresponding to signal B) as shown in Table 4.

[0074] Table 4

[0075] The single-column structure data of signal B is concatenated with the preset two-dimensional structure data containing the test data of signal A, and the row index is reset. After concatenation, the number of rows increases and the number of columns becomes 2. The first two-dimensional structure input containing the test data of signals A and B is shown in Table 5. The unfilled positions are all empty values.

[0076] Table 5

[0077] It should be noted that this embodiment uses two input signals, A and B, as an example to describe the data splicing process. In actual scenarios, there are more input signals, and the splicing process is similar, so it will not be described in detail here.

[0078] In this embodiment, the lower boundary value, median value, and upper boundary value of each input signal are treated as a single-column structured data, and column indices are specified according to the extraction order of the input signals. This ensures that the test data of each input signal occupies a dedicated column, and the initial predicted two-dimensional structured data is null. Then, the single-column structured data (test data) of the first input signal, the second input signal, and so on are sequentially concatenated with the preset two-dimensional structured data row by row. Since concatenating the single-column structured data of one input signal increases the number of rows by three (i.e., the lower boundary value, median value, and lower boundary value rows), the row index is reset once, ensuring the orderliness of the data structure, avoiding the chaos caused by the mixing of multiple signal data, and reducing errors in the data processing process. Furthermore, the independent processing of each column allows the test data of each signal to be maintained separately, which facilitates subsequent adjustment of the test data for specific signals (such as modifying boundary values), improving the flexibility and maintainability of the test cases.

[0079] Step S305: Use the intermediate value of each input signal as the fill value to fill the empty values ​​in the corresponding column of each input signal in the first two-dimensional structure data to obtain the second two-dimensional structure data.

[0080] In this step, the empty values ​​are filled by column using the median value to ensure that when testing a certain signal, the other signals are all valid values. Specifically, if the median value of signal A is 5, then the empty values ​​in the first column (signal A column) are filled with the median value of signal A, 5. Similarly, the empty values ​​in the second column containing signal B are filled with the median value of signal B (24). The second two-dimensional structure data after filling the empty values ​​is shown in Table 6. When the lower boundary value of the tested signal A is 0, signal B is the median value; when the upper boundary value of the tested signal B is 28, signal A is the median value, and so on.

[0081] Table 6

[0082] Step S306: Concatenate the invalid values ​​of each input signal with the second two-dimensional structure data row by row to obtain the third two-dimensional structure data.

[0083] In this step, the purpose of concatenating the invalid values ​​of each input signal with the second two-dimensional structure data row by row is to increase the test scenario where all input signals are invalid.

[0084] In one possible implementation, invalid values ​​include lower boundary values ​​and upper boundary values. The invalid values ​​of each input signal are concatenated row-wise with the second two-dimensional structure data to obtain the third two-dimensional structure data. This includes: determining invalid two-dimensional structure data based on the lower boundary and upper boundary values ​​of each input signal, and specifying row and column indices; the column indices are determined according to the extraction order of the input signals; each column in the invalid two-dimensional structure data corresponds to the lower boundary and upper boundary values ​​of one input signal, and each row represents the lower boundary or upper boundary values ​​of all input signals; the invalid two-dimensional structure data is concatenated row-wise with the second two-dimensional structure data, and the row indices of the second two-dimensional structure data are reset to obtain the third two-dimensional structure data.

[0085] It should be noted that for each input signal, there may be multiple invalid values. In order to unify the invalid scenarios of all input signals, this embodiment uses one lower boundary value and one upper boundary value of each input signal as invalid values.

[0086] For example, the invalid values ​​of signal A and signal B obtained from the calculation are shown in Table 7 below.

[0087] Table 7

[0088] The invalid value arrays of signals A and B are transposed, and the column and row indices are specified according to the order of input signal extraction. The resulting invalid two-dimensional structure data is shown in Table 8. The first column is the column containing signal A, the second column is the column containing signal B, the first row is the lower boundary value of signal A and signal B, and the second row is the upper boundary value of signal A and signal B.

[0089] Table 8

[0090] The invalid two-dimensional structure data shown in Table 8 is concatenated with the second two-dimensional structure data shown in Table 6 by row, two new rows of completely invalid scenarios are added, and the row index is reset to obtain the third two-dimensional structure data.

[0091] It should be noted that invalid two-dimensional structure data can be concatenated into any row of the second two-dimensional structure data. In order to make the final test dataset more standardized and uniform for easy modification and maintenance, this embodiment concatenates invalid two-dimensional structure data into the end of the second two-dimensional structure data, and the resulting third two-dimensional structure data is shown in Table 9.

[0092] Table 9

[0093] In this embodiment, the types of invalid values ​​are defined, including lower boundary values ​​and upper boundary values, and the concatenation logic for invalid data is specified. This adds a test scenario where all input signals are invalid, making the model's response to abnormal inputs more accurate. Since the column index of the invalid two-dimensional structure data is consistent with the column index of the first and second two-dimensional structure data, row-by-row concatenation ensures that invalid data from different input signals are not misaligned. Furthermore, the invalid two-dimensional structure data and the second two-dimensional structure data are concatenated row-by-row, with each row representing the same type of invalid value (such as lower boundary or upper boundary value) for all input signals. This ensures the completeness of the invalid scenario (covering the situation where all signals are simultaneously abnormal), improving the comprehensiveness of the model's robustness testing.

[0094] Through the aforementioned steps S304-S306, the composition of boundary values ​​(including upper and lower boundary values) and their specific arrangement rules are defined. The lower boundary value, intermediate value, and upper boundary value are all valid values. First, valid data (lower boundary value, intermediate value, and upper boundary value) are concatenated row by row, ensuring that the lower boundary value, intermediate value, and upper boundary value of each input signal occupy a dedicated column in the concatenated first two-dimensional structure data, and that each row corresponds to one valid value for one input signal (other input signals in that row are empty values). Then, the intermediate value of the input signal is used to fill the empty values ​​in the column containing that input signal, thereby ensuring that when testing a certain interface, the input signals of other interfaces are all valid values ​​(intermediate values), avoiding mutual interference between input signals from different interfaces, making single-interface testing scenarios more accurate, and improving testing specificity. Furthermore, by "concatenating invalid value data," it specifically covers "all interfaces are invalid values." This approach addresses the shortcomings of existing technologies in testing for abnormal inputs, comprehensively verifies the model's ability to handle invalid inputs, and enhances the rigor of testing. The standardized arrangement rules make the test case structure clear, covering all test scenarios with minimal data, facilitating subsequent maintenance and modification, and reducing test case management costs while covering all interface testing scenarios.

[0095] In one possible embodiment, after obtaining the third two-dimensional structure data containing valid test scenarios (boundary values ​​and intermediate values) and invalid test scenarios of all input signals, test cases corresponding to the data dictionary file are generated based on the third two-dimensional structure data.

[0096] In one possible implementation, test cases corresponding to the data dictionary file are generated based on the third-dimensional structural data, including the following steps S307 and S308: Step S307: For each data dictionary file, generate initial value two-dimensional structure data based on the names and initial values ​​of all input signals in the file, and specify row and column indices; the column indices are determined according to the extraction order of the input signals, and each column in the initial value two-dimensional structure data corresponds to the name and initial value of an input signal, the first row is the name of all input signals, and the second row is the initial value of all input signals.

[0097] In this step, the names of the input signals are in one column, and the initial values ​​of each input signal are in another column. The order of the initial values ​​is the same as the order of the input signals. First, the names and initial values ​​of the input signals are concatenated by column. The concatenated data is shown in Table 10.

[0098] Table 10

[0099] The result after concatenating columns is transposed (i.e., rows become columns, and columns become rows). The transposed result is the initial two-dimensional structure data as shown in Table 11. The first row is the header row (the name of each input signal), and the second row is the initial value row.

[0100] Table 11

[0101] In step S308, the initial two-dimensional structure data and the third two-dimensional structure data are concatenated row by row, and the row index is reset to obtain the target two-dimensional structure data; the first row of the test data in the target two-dimensional structure data is the initial value of each input signal.

[0102] In this step, the initial value two-dimensional structure data shown in Table 11 and the third two-dimensional structure data shown in Table 9 are concatenated row by row, and an initial value row is added to the original third two-dimensional structure data. In order to ensure that the data in the first cycle of the model during interface testing is the initial value, this embodiment concatenates the initial value two-dimensional structure data on the first row of the third two-dimensional structure data and resets the row index. The resulting target two-dimensional structure data is shown in Table 12. The first row is the table header, the second to tenth rows are the test data, and the second row (i.e., the first row of the test data) is the initial value row.

[0103] Table 12

[0104] In this embodiment, adding input signal names makes the correspondence between test cases and model interfaces clearer, reduces confusion when mapping test cases to model interfaces, and lowers the mapping cost when importing test tools. Furthermore, adding the initial values ​​of all input signals as the first row of test data ensures that the first cycle of model operation covers the initial running state when the model starts, making up for the deficiency of ignoring initial state testing in the prior art, making the test more in line with the actual running scenario, and improving the authenticity of interface testing.

[0105] Step S309: Based on the number of rows of test data in the target two-dimensional structure data and the model running cycle, determine the test time corresponding to each row of test data to obtain the test time series.

[0106] In this step, the total number of rows in the target two-dimensional structure data minus 1 (minus the header row) gives the number of rows in the test data. The model execution cycle is the time it takes for the model to run one row of test data, and the number of test data rows is the number of cycles required for the model to run all test data. Starting with the first row of test data (i.e., the initial value row), the test time is 0. The duration of one cycle is added sequentially as the test time for the next row of data, resulting in the test time for each row. For example, if the target two-dimensional structure data for signals A and B has 10 rows, and the number of test data rows is 9, then the model needs to run 9 cycles to complete all test data. Assuming one execution cycle is 10 milliseconds (ms), the test time for the first row of test data is 0, the second row is 0 + 10 = 10 ms, the third row is 20 ms, and so on, until the test time for the 9th row is 80 ms. The resulting test time sequence is shown in Table 13.

[0107] Table 13

[0108] Step S310: Insert the test time series into the target two-dimensional structure data and specify the column index of the test time series as 0 to obtain the target two-dimensional structure data with the test time series.

[0109] In this step, the test time series is inserted into the 0th column of the target two-dimensional structure data (i.e., concatenated by column). The final target two-dimensional structure data with the test time series is the test case corresponding to the model, as shown in Table 14 for example.

[0110] Table 14

[0111] Step S311: Generate test cases adapted to the testing tool based on the target two-dimensional structure data with test time series.

[0112] In this step, since most testing tools support importing Excel spreadsheets for testing, the final target two-dimensional structure data with test time series is converted into an Excel spreadsheet for storage.

[0113] For the data dictionary files of multiple models, repeat steps S302 to S311 above to obtain test cases for each model to be tested.

[0114] In this embodiment, a time series is automatically generated based on the number of test data rows and the model running cycle, avoiding the tedious manual calculation of test time and reducing the workload and error rate of time dimension processing. Furthermore, the test time series is inserted into the first column of the target two-dimensional structure data, with the specified column index as 0, so that the test cases meet the format requirements of the testing tool for time and input signals, facilitating direct adaptation and import into the testing tool, improving the efficiency of automated testing, and solving the problem of having to re-edit the time information when changing testing tools in the prior art. This improves the compatibility of test cases and the efficiency of tool adaptation. When the testing tool is imported for interface testing, each row of test data can be automatically called sequentially according to the test time series to test the input signals of each interface, further improving the efficiency of interface testing.

[0115] Figure 4 This is a flowchart illustrating the method for generating interface test cases according to another embodiment of this application. This embodiment takes code execution logic as an example, and uses code scripts to extract interface information, calculate and arrange test data, and finally generate test cases in the form of an Excel spreadsheet. This enables batch processing of data dictionary files of multiple models to be tested to obtain test cases corresponding to each model.

[0116] like Figure 4 As shown, the first stage is the file preparation stage, where the data dictionary files (file format _dd.xlsx, such as _dd.xlsx file 1, _dd.xlsx file 2, _dd.xlsx file 3, etc.) of multiple models to be tested are stored in the same folder along with the script.

[0117] Phase Two: Automated Processing Phase (i.e., Script Execution Process) 1. Obtain the files to be processed: The script uses the glob.glob() function to obtain all _dd.xlsx files that meet the conditions in the current folder and stores the file names in the excel_files[] table file; the len() function is used to count the number of files to be processed and store it in the variable files_num (files_num=len(excel_files)).

[0118] 2. Process each data dictionary file in a loop: For each file in excel_files[], control the number of loop iterations using for nin range(files_num) and generate an index n (n files to be processed): 2.1 Extract interface information.

[0119] Use the read_excel() function to retrieve a specific sheet from the excel_files[n] file.

[0120] Extract the key information of the input signals of the interface from the sheet and store it as a list or a DataFrame (DF): the name of the input signal is stored in input_name[] (DF type), the initial value of the input signal is stored in input_initValue[] (DF type), the data type of the input signal is stored in input_DataType[] (DF type), the minimum value of the input signal is stored in input_Min_data[] (list type), and the maximum value of the input signal is stored in input_Max_data[] (list type).

[0121] Use the len() function to get the number of input signals, generate index i (i input signals), and store it in the variable input_num (input_num=len(input_name)).

[0122] 2.2 Calculate the test data for each input signal in a loop.

[0123] For each input signal, the loop is controlled by for i in range(input_num) as follows: a. Based on index i, obtain the data type (input_DataType[i]), minimum value (input_Min_data[i]), and maximum value (input_Max_data[i]) corresponding to the input signal; calculate the lower boundary value, intermediate value, and upper boundary value, and store them in the data[] list in order to obtain the test data array data[].

[0124] b. Use pd.DataFrame() to convert the test data array data[] to DF type (denoted as df_data) and specify the column index (the column index is incremented by 1).

[0125] c. Concatenate df_data with an empty DF type data (denoted as df_1) row by row and store it back into df_1. Then use the reset_index() function to reset the row index of df_1.

[0126] d. Extract the intermediate value of the input signal i, and use the append() function to store the intermediate value at the end of the data_NaN[] array (for subsequent filling of null values).

[0127] e. Calculate the invalid values ​​above the upper and lower boundaries, and store them in the data_Invalid[] array using the append() function; use pd.DataFrame() to convert the invalid value array data_Invalid[] to DF type, denoted as df_data_Invalid.

[0128] At this point, the test data processing for one input signal is complete (corresponding to...). Figure 4 The steps within the blue solid box are: using the for i in range(input_num) loop to enter the processing of the next input signal, and then executing steps a~e again, until all the test data of the input signals in the excel_files[n] file are processed and the for loop exits.

[0129] 2.3 Integrate the test data of all input signals.

[0130] 2.31. Loop to fill empty values, using for j in range(input_num) to control the loop: Use the Fillna() function to loop to fill empty values ​​in df_1, filling the intermediate value array data_NaN[j] into the empty values ​​in column j of df_1 (ensuring that when testing a certain signal, other signals are valid values); exit the for loop after all columns are filled.

[0131] 2.32. After transposing df_data_Invalid (referred to as df_data_Invalid.T after transposition), concatenate df_1 and df_data_Invalid.T obtained in step 2.31 by row and store them in df_1 to obtain the updated df_1, and reset the row index (to add a scenario where all signals are invalid).

[0132] 2.4 Generate the final test cases containing initial values ​​and time.

[0133] 2.41. The DF type data generated by concatenating the input signal name (input_name) and the initial value (input_initValue) column by column is stored in Final_df. Then, Final_df is transposed and the row index is reset to obtain the updated Final_df, which contains the input signal name and the initial value.

[0134] 2.42. After concatenating the updated df_1 obtained in step 2.32 into Final_df, and resetting the row index, store it in Final_df; at this time, Final_df is a DF that stores the names of all input signals of the model and the corresponding test data of the input signals.

[0135] 2.43. Use input() to input the running cycle of the corresponding model and store it in the cycle variable. Calculate the test time: Based on the running cycle of the model and the number of rows of Final_df obtained in step 2.42, calculate the time required to run the test cases and store it in the time array time[]. At the same time, time[0]='time'.

[0136] Specifically, use len(Final_df) to count the number of rows in Final_df, determine the number of model execution cycles required for the test data (the number of cycles equals the number of rows in Final_df - 1, i.e., len(Final_df) - 1), and store the number of cycles in the variable cycle_1; create a new time array time[], with the first element being time (header); create a new variable cycle_time = 0; use for k in range(cycle_1) loop to calculate the test time for each cycle, and cycle_time starts from 0 and accumulates the running cycle, i.e., cycle_time = cycle_time + cycle; store the value of cycle_time in the time array time[] using the append() function; after the time corresponding to the required number of cycles has been processed, exit the for loop.

[0137] 2.44. Use the insert() function to insert the time array time[] into Final_df, and set the column index to 0; at this time, Final_df is the final test case generated from the corresponding excel_files[n] file.

[0138] 2.5 Save the test cases.

[0139] Use the to_excel() function to save Final_df as an Excel spreadsheet, hide the index, and replace the original data dictionary file name dd.xlsx with TestCase.xlsx, storing it in the same folder; at this point, the test cases for the excel_files[n] file are generated.

[0140] 2.6. Clean up variables.

[0141] Clear all variables, arrays, lists, and data stored in the DF memory used in the current data dictionary file processing to prepare for the processing of the next data dictionary file.

[0142] At this point, steps 2.1 to 2.6 have completed the processing of a data dictionary file (corresponding to...). Figure 4 The process within the orange solid box (for n in range(files_num)) enters the next file through a for n in range(files_num) loop to start processing the next data dictionary file. Once the test cases for all data dictionary files have been generated, the for loop for that file exits.

[0143] 2.7. Use the print() function to indicate that all test cases for all files have been generated and the script can be closed.

[0144] In this embodiment, the model data dictionary (xxxx_dd.xlsx) is processed in batches by a script to automatically extract information such as the name, data type, and maximum / minimum values ​​of the input interface. It also automatically calculates test data such as boundary values, intermediate values, and invalid values, and combines these to generate test cases covering various scenarios. Finally, it generates test cases in an Excel spreadsheet format (xxxx_TestCase.xlsx) adapted to the testing tool. The entire test data generation method and automated script implementation process reduce manual operations and solve the problems of large workload, long time, high repetition, and the need to re-edit test cases when switching tools in existing automotive electronic model interface testing, thereby improving testing efficiency.

[0145] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0146] Figure 5 This is a schematic diagram of the structure of an interface test case generation device provided in an embodiment of this application. For example... Figure 5 As shown, the interface test case generation device provided in this embodiment may include: an acquisition module 501, an extraction module 502, a calculation module 503, and a processing module 504.

[0147] The system includes: an acquisition module 501 for acquiring at least one data dictionary file for a model to be tested; an extraction module 502 for extracting interface information corresponding to each interface in each data dictionary file, including the data type and maximum / minimum values ​​of the input signals; a calculation module 503 for determining the test data of the input signals for each interface based on the data type and maximum / minimum values ​​of the input signals, including boundary values, intermediate values, and invalid values; and a processing module 504 for arranging the test data of the input signals corresponding to each interface according to a preset arrangement rule to obtain test cases corresponding to each data dictionary file.

[0148] In one possible implementation, the boundary values ​​include lower boundary values ​​and upper boundary values; the processing module 504 is specifically used for: for each data dictionary file, concatenating the lower boundary values, intermediate values, and upper boundary values ​​of all input signals in the file row by row to obtain a first two-dimensional structure data; wherein, the lower boundary value, intermediate value, and upper boundary value of each input signal occupy a separate column in the first two-dimensional structure data; using the intermediate value of each input signal as a fill value to fill the empty values ​​in the corresponding column of each input signal in the first two-dimensional structure data to obtain a second two-dimensional structure data; concatenating the invalid values ​​of each input signal with the second two-dimensional structure data row by row to obtain a third two-dimensional structure data; and generating test cases corresponding to the data dictionary file based on the third two-dimensional structure data.

[0149] In one possible implementation, the processing module 504 is specifically used to: treat the lower boundary value, intermediate value, and upper boundary value of each input signal as a single-column structured data and specify a column index; the column index is determined according to the extraction order of the input signals; according to the extraction order of the input signals, the single-column structured data corresponding to each input signal is sequentially concatenated with the preset two-dimensional structured data row by row, and the row index is reset once every time the single-column structured data of an input signal is concatenated row by row, until the single-column structured data of all input signals in the data dictionary file are concatenated to obtain the first two-dimensional structured data; wherein, the preset two-dimensional structured data is initially empty.

[0150] In one possible implementation, invalid values ​​include lower boundary values ​​and upper boundary values; the processing module 504 is specifically used to: determine invalid two-dimensional structure data based on the lower boundary value and upper boundary value of each input signal, and specify row index and column index; the column index is determined according to the extraction order of the input signals; each column in the invalid two-dimensional structure data corresponds to the lower boundary value and upper boundary value of one input signal, and each row is the lower boundary value or upper boundary value of all input signals; the invalid two-dimensional structure data is concatenated with the second two-dimensional structure data row by row, and the row index of the second two-dimensional structure data is reset to obtain the third two-dimensional structure data.

[0151] In one possible implementation, the interface information also includes the names and initial values ​​of the input signals; the processing module 504 is specifically used to: for each data dictionary file, generate initial value two-dimensional structure data based on the names and initial values ​​of all input signals in the file, and specify row and column indices; the column indices are determined according to the extraction order of the input signals, each column in the initial value two-dimensional structure data corresponds to the name and initial value of an input signal, the first row is the names of all input signals, and the second row is the initial values ​​of all input signals; the initial value two-dimensional structure data is concatenated with the third two-dimensional structure data row by row, and the row indices are reset to obtain the target two-dimensional structure data; the first row of the test data in the target two-dimensional structure data is the initial value of each input signal; and test cases corresponding to the data dictionary file are generated based on the target two-dimensional structure data.

[0152] In one possible implementation, the processing module 504 is further configured to: determine the test time corresponding to each row of test data based on the number of rows of test data and the model running cycle in the target two-dimensional structure data, and obtain a test time series; insert the test time series into the target two-dimensional structure data and specify the column index of the test time series as 0, to obtain target two-dimensional structure data with test time series; and generate test cases adapted to the testing tool based on the target two-dimensional structure data with test time series.

[0153] In one possible implementation, the extreme values ​​include the maximum and minimum values; the calculation module 503 is specifically used to: sequentially perform the step of calculating test data for each input signal according to the extraction order of the input signals of each interface, until the test data of all input signals in a data dictionary file has been calculated, and obtain the test data of each input signal in the data dictionary file; the step of calculating test data includes: determining the lower boundary value, upper boundary value and intermediate value of the input signal according to the data type, maximum value and minimum value of the input signal; and treating the lower boundary value that is less than the lower boundary value and the upper boundary value that is greater than the upper boundary value as invalid values.

[0154] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0155] Figure 6 This is a schematic diagram of the structure of a vehicle provided in one embodiment of this application. Figure 6As shown, the vehicle 600 in this embodiment includes a processor 610 and a memory 620, wherein the memory 620 stores a computer program 621 that can run on the processor 610. When the processor 610 executes the computer program 621, it implements the steps in any of the above method embodiments. Alternatively, when the processor 610 executes the computer program 621, it implements the functions of each module / unit in the above device embodiments.

[0156] For example, computer program 621 may be divided into one or more modules / units, one or more of which are stored in memory 620 and executed by processor 610 to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of computer program 621 in vehicle 600.

[0157] Those skilled in the art will understand that Figure 6 This is merely an example of a vehicle and does not constitute a limitation on the vehicle. It may include more or fewer components than shown, or combinations of certain components, or different components, such as input / output devices, network access devices, buses, etc.

[0158] The processor 610 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0159] The memory 620 can be an internal storage unit of the vehicle, such as a hard drive or memory, or an external storage device, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc. The memory 620 can also include both internal and external storage devices. The memory 620 is used to store computer programs and other programs and data required by the vehicle. The memory 620 can also be used to temporarily store data that has been output or will be output.

[0160] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0161] An embodiment of this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0162] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0163] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0164] In the embodiments provided in this application, it should be understood that the disclosed devices / vehicles and methods can be implemented in other ways. For example, the device / vehicle embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0165] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for generating interface test cases, characterized in that, include: Obtain at least one data dictionary file for the model to be tested; For each data dictionary file, extract the interface information corresponding to each interface contained in the file. The interface information includes the data type and maximum / minimum value of the input signal. For each interface's input signal, test data for the input signal is determined based on the data type and maximum / minimum value of the input signal; the test data includes boundary values, intermediate values, and invalid values. According to the preset arrangement rules, the test data of the input signals corresponding to each interface are arranged and processed to obtain the test cases corresponding to each data dictionary file.

2. The method for generating interface test cases according to claim 1, characterized in that, The boundary values ​​include lower boundary values ​​and upper boundary values; The step of arranging the test data of the input signals corresponding to each interface according to a preset arrangement rule includes: For each data dictionary file, the lower boundary value, median value, and upper boundary value of all input signals in the file are concatenated row by row to obtain the first two-dimensional structure data; wherein, the lower boundary value, median value, and upper boundary value of each input signal occupy a separate column in the first two-dimensional structure data; The middle value of each input signal is used as the padding value to fill the empty values ​​in the corresponding column of each input signal in the first two-dimensional structure data, thus obtaining the second two-dimensional structure data. The invalid value of each input signal is concatenated with the second two-dimensional structure data row by row to obtain the third two-dimensional structure data; Based on the third two-dimensional structure data, test cases corresponding to the data dictionary file are generated.

3. The method for generating interface test cases according to claim 2, characterized in that, The first two-dimensional structure data is obtained by concatenating the lower boundary values, intermediate values, and upper boundary values ​​of all input signals in the file row by row, including: The lower boundary value, intermediate value, and upper boundary value of each input signal are treated as a single-column structured data, and a column index is specified; the column index is determined according to the extraction order of the input signals. According to the extraction order of the input signals, the single-column structure data corresponding to each input signal is sequentially concatenated with the preset two-dimensional structure data row by row, and the row index is reset once for each row concatenation of the single-column structure data of an input signal, until the single-column structure data of all input signals in the data dictionary file are concatenated to obtain the first two-dimensional structure data; The preset two-dimensional structure data is initially empty.

4. The method for generating interface test cases according to claim 2, characterized in that, The invalid values ​​include values ​​exceeding the lower boundary and values ​​exceeding the upper boundary. The step of concatenating invalid values ​​of each input signal with the second two-dimensional structure data row by row to obtain the third two-dimensional structure data includes: Invalid two-dimensional structure data is determined based on the lower boundary value and upper boundary value of each input signal, and row and column indices are specified; the column indices are determined according to the extraction order of the input signals; each column in the invalid two-dimensional structure data corresponds to the lower boundary value and upper boundary value of an input signal, and each row is the lower boundary value or upper boundary value of all input signals; The invalid two-dimensional structure data is concatenated with the second two-dimensional structure data row by row, and the row index of the second two-dimensional structure data is reset to obtain the third two-dimensional structure data.

5. The method for generating interface test cases according to claim 2, characterized in that, The interface information also includes the name and initial value of the input signal; The step of generating test cases corresponding to the data dictionary file based on the third two-dimensional structure data includes: For each data dictionary file, a two-dimensional structure of initial values ​​is generated based on the names and initial values ​​of all input signals in the file, and row and column indices are specified. The column indices are determined according to the extraction order of the input signals. Each column in the two-dimensional structure of initial values ​​corresponds to the name and initial value of an input signal. The first row contains the names of all input signals, and the second row contains the initial values ​​of all input signals. The initial two-dimensional structure data and the third two-dimensional structure data are concatenated row by row, and the row index is reset to obtain the target two-dimensional structure data; the first row of the test data in the target two-dimensional structure data is the initial value of each input signal; Based on the target two-dimensional structure data, test cases corresponding to the data dictionary file are generated.

6. The method for generating interface test cases according to claim 5, characterized in that, Also includes: Based on the number of rows of test data and the model running cycle in the target two-dimensional structure data, the test time corresponding to each row of test data is determined, and the test time sequence is obtained; Insert the test time series into the target two-dimensional structure data, and specify the column index of the test time series as 0 to obtain the target two-dimensional structure data with the test time series; Based on the target two-dimensional structure data with test time series, test cases adapted to the testing tool are generated.

7. The method for generating interface test cases according to any one of claims 1 to 6, characterized in that, The extreme values ​​include the maximum value and the minimum value; For each interface's input signal, the test data for the input signal is determined based on the data type and maximum / minimum value of the input signal, including: Following the extraction order of the input signals from each interface, the steps of calculating test data are performed sequentially for each input signal until the test data of all input signals in a data dictionary file has been calculated, thus obtaining the test data of each input signal in the data dictionary file. The steps for calculating the test data include: Based on the data type, maximum value, and minimum value of the input signal, determine the lower boundary value, upper boundary value, and intermediate value of the input signal; Values ​​exceeding the lower boundary that are less than the lower boundary value and values ​​exceeding the upper boundary that are greater than the upper boundary value are considered invalid values.

8. An interface test case generation device, characterized in that, include: The acquisition module is used to acquire at least one data dictionary file for the model to be tested. The extraction module is used to extract the interface information corresponding to each interface contained in each data dictionary file. The interface information includes the data type and maximum / minimum value of the input signal. The calculation module is used to determine the test data of the input signal for each interface based on the data type and maximum / minimum value of the input signal; the test data includes boundary values, intermediate values, and invalid values. The processing module is used to arrange and process the test data of the input signals corresponding to each interface according to a preset arrangement rule, so as to obtain the test cases corresponding to each data dictionary file.

9. A vehicle comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the method for generating interface test cases as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the method for generating interface test cases as described in any one of claims 1 to 7.

Images