Test script generation method, electronic device, and program product

Abstract

The application relates to the field of automobile electronic test automation, in particular to a test script generation method, an electronic device and a program product. The method comprises the following steps: obtaining and analyzing a test parameter table to obtain column names and row data, extracting grouped field values from the row data based on a preconfigured parameter index and field name mapping relationship, and recording a case original order; dividing the case into data groups according to the grouped field values, obtaining a corresponding target template from a template mapping table, filling the data group field values into the template to generate multiple script segments, and assembling the script segments into a target file according to the original order. The scheme can realize unified extraction, grouping, template generation and sequential assembly of multiple test cases, improve script batch generation efficiency, reduce manual intervention and error probability, and ensure the correspondence, structural consistency and sequential consistency of the generation result and the test requirement.

Description

Technical Field

[0001] This application relates to the field of automotive electronics testing, and more particularly to a test script generation method, electronic device, and program product. Background Technology

[0002] As the complexity of in-vehicle network communication continues to increase, the demand for verification of the interaction behavior between network nodes is growing rapidly. The testing process usually relies on professional testing tools to simulate bus communication, monitor signal changes, and diagnose responses. As the core carrier for controlling the testing process, injecting stimulus signals, and judging test results, the quality and efficiency of test scripts directly affect the length of the entire verification cycle.

[0003] In existing technologies, test script development primarily relies on manual writing or generation from standardized templates. Testers manually write script statements line by line to send signals, detect responses, and determine pass / fail conditions, based on the test case descriptions in the requirements document and the script syntax rules supported by specific testing tools. Multiple test statements are then combined into complete test cases. When multiple nodes under test or various test scenarios need to be verified, testers generate new test cases by copying existing scripts and modifying them line by line. Finally, all test cases are organized into a test suite and delivered for execution. Currently, all test parameters in standardized script templates are filled into the same template for generation, simply reading all data from a table and directly outputting the script.

[0004] In existing technologies, when faced with a large number of test cases, a single general template is difficult to adapt to the standardized testing requirements of various types of vehicle networks. Manually writing scripts line by line results in extremely low generation efficiency. Furthermore, the structure of the test scripts needs to correspond to the logical grouping and hierarchical relationship in the test requirements. However, in the manual writing method, the output order and grouping structure of each test case depend entirely on the writer's subjective organization. Summary of the Invention

[0005] This application provides a test script generation method, electronic device, and program product to improve the efficiency of batch script generation.

[0006] In a first aspect, embodiments of this application provide a test script generation method, including:

[0007] Obtain multiple test cases, each test case including multiple parameter metrics and test information corresponding to each parameter metric;

[0008] Based on the mapping relationship between pre-configured parameter indicators and preset field names, the group field values ​​corresponding to the preset field names are extracted from the test information, and the original order of each test case is recorded.

[0009] Based on the grouping field value, the test cases are divided into multiple data groups;

[0010] Obtain the target test script template corresponding to the grouping field value from the preset template mapping table;

[0011] Fill the field values ​​of each data group into the corresponding target test script template to generate multiple test script fragments;

[0012] The test script fragments corresponding to each test case are assembled in the original order to obtain the target test script file.

[0013] In one possible implementation, it also includes:

[0014] The fill field values ​​are extracted from each of the data groups according to the mapping relationship;

[0015] The derived parameter values ​​are calculated based on the filled field values ​​and the preset field operation configuration information, so as to fill the filled field values ​​and the derived parameter values ​​into the corresponding target test script template.

[0016] In one possible implementation, calculating the derived parameter value includes:

[0017] Obtain preset field operation configuration information, which includes a conversion expression and the associated field name corresponding to the conversion expression;

[0018] Obtain the target field value corresponding to the associated field name from the populated field values;

[0019] The derived parameter value is calculated based on the transformation expression and the target field value.

[0020] In one possible implementation, it also includes:

[0021] Based on the mapping relationship, multiple candidate field names are filtered from the test information;

[0022] Based on the candidate field names, determine the association relationships between the candidate field names from the preset field association rules;

[0023] The preset field operation configuration information is generated based on the association relationship.

[0024] In one possible implementation, it also includes:

[0025] When there are multiple test script templates in the preset template mapping table that correspond to the grouping field value, obtain the version identifier of the corresponding test script template;

[0026] Based on the preset priority of the version identifier, the target test script template corresponding to the grouping field value is determined from multiple test script templates.

[0027] In one possible implementation, it also includes:

[0028] When the version identifiers are different and the template types corresponding to each test script template are the same, obtain the creation time of each test script template;

[0029] The test script templates are arranged in descending order of their creation time, and the first test script template in the sequence is taken as the target test script template.

[0030] In one possible implementation, it also includes:

[0031] When the version identifiers are different and the template types are different, the target test script template is determined from the multiple test script templates according to the preset template type priority.

[0032] In one possible implementation, the mapping relationship is established in the following way:

[0033] Match the parameter index with the preset field names in the preset field name library;

[0034] Detect whether there are any abnormal indicators among the parameter indicators that do not match the preset field name;

[0035] When the abnormal indicator does not exist, a mapping relationship is established between the parameter indicator and the corresponding preset field name.

[0036] Secondly, embodiments of this application provide a test script generation apparatus, comprising:

[0037] The acquisition module is used to acquire multiple test cases. Each test case includes multiple parameter metrics and test information corresponding to each parameter metric.

[0038] The extraction module is used to extract the group field values ​​corresponding to the preset field names from the test information based on the mapping relationship between pre-configured parameter indicators and preset field names, and record the original order of each test case;

[0039] The partitioning module is used to divide the test cases into multiple data groups based on the grouping field value;

[0040] The matching module is used to obtain the target test script template corresponding to the grouping field value from the preset template mapping table;

[0041] The generation module is used to fill the field values ​​of each data group into the corresponding target test script template to generate multiple test script fragments.

[0042] The generation module is further configured to assemble the test script fragments corresponding to each test case in the original order to obtain the target test script file.

[0043] In one possible implementation, it also includes:

[0044] The fill field values ​​are extracted from each of the data groups according to the mapping relationship;

[0045] The derived parameter values ​​are calculated based on the filled field values ​​and the preset field operation configuration information, so as to fill the filled field values ​​and the derived parameter values ​​into the corresponding target test script template.

[0046] In one possible implementation, calculating the derived parameter value includes:

[0047] Obtain preset field operation configuration information, which includes a conversion expression and the associated field name corresponding to the conversion expression;

[0048] Obtain the target field value corresponding to the associated field name from the populated field values;

[0049] The derived parameter value is calculated based on the transformation expression and the target field value.

[0050] In one possible implementation, it also includes:

[0051] Based on the mapping relationship, multiple candidate field names are filtered from the test information;

[0052] Based on the candidate field names, determine the association relationships between the candidate field names from the preset field association rules;

[0053] The preset field operation configuration information is generated based on the association relationship.

[0054] In one possible implementation, it also includes:

[0055] When there are multiple test script templates in the preset template mapping table that correspond to the grouping field value, obtain the version identifier of the corresponding test script template;

[0056] Based on the preset priority of the version identifier, the target test script template corresponding to the grouping field value is determined from multiple test script templates.

[0057] In one possible implementation, it also includes:

[0058] When the version identifiers are different and the template types corresponding to each test script template are the same, obtain the creation time of each test script template;

[0059] The test script templates are arranged in descending order of their creation time, and the first test script template in the sequence is taken as the target test script template.

[0060] In one possible implementation, it also includes:

[0061] When the version identifiers are different and the template types are different, the target test script template is determined from the multiple test script templates according to the preset template type priority.

[0062] In one possible implementation, the mapping relationship is established in the following way:

[0063] Match the parameter index with the preset field names in the preset field name library;

[0064] Detect whether there are any abnormal indicators among the parameter indicators that do not match the preset field name;

[0065] When the abnormal indicator does not exist, a mapping relationship is established between the parameter indicator and the corresponding preset field name.

[0066] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0067] The memory stores computer-executed instructions;

[0068] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0069] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0070] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0071] In a sixth aspect, embodiments of this application provide a testing method, comprising: obtaining a target test script file according to the first aspect and / or various possible implementations of the first aspect; and performing tests based on the target test script file.

[0072] The test script generation method, electronic device, and program product provided in this application automatically convert test requirements in tabular form compiled by testers into executable scripts. During the process, the data can be automatically identified without manually adjusting the column name format of the table, and the matching script template can be automatically selected to fill in the content according to the type of test case. At the same time, the order of each test case in the original table is preserved, and finally the batch-generated script fragments are assembled into a complete script file according to the order. Through the above means, the efficiency and accuracy of test script generation are improved, the manual writing and maintenance costs are reduced, and the consistency and maintainability of batch updates of test scripts in scenarios with frequent changes in requirements are improved. Attached Figure Description

[0073] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0074] Figure 1 Flowchart of the test script generation method provided in this application Figure 1 ;

[0075] Figure 2 Flowchart of the test script generation method provided in this application Figure 2 ;

[0076] Figure 3 Flowchart of the test script generation method provided in this application Figure 3 ;

[0077] Figure 4 Flowchart of the test script generation method provided in this application Figure 4 ;

[0078] Figure 5 Flowchart of the test script generation method provided in this application Figure 5 ;

[0079] Figure 6 A schematic diagram of the test script generation device provided in this application;

[0080] Figure 7 A schematic diagram of the structure of the electronic device provided in this application.

[0081] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0082] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application.

[0083] First, let me explain the terms used in this application:

[0084] Test parameter table: This refers to a structured data file used to store test case configuration parameters. It contains column names and row data. The column names are used to identify the parameter types represented by each column, and the row data is used to store the specific values ​​of each test case under each parameter type.

[0085] Data parsing refers to the operation of converting the test parameter table from a file format into a data structure that can be processed programmatically. After parsing, a set of column names and a set of row data are obtained.

[0086] Mapping relationship: refers to the correspondence established between the parameter indicator names in the table and the preset field names used internally by the system.

[0087] Grouping field value: refers to the specific value extracted from the row data to identify the group category to which the test case belongs. It is the specific data content of the grouping field in each row.

[0088] Original order: refers to the row order of each test case in the test parameter table. It is recorded synchronously when extracting the grouping field values ​​and is used to restore the order of each test case in the subsequent assembly stage.

[0089] Data group: refers to a collection formed by aggregating multiple test cases with the same grouping field value. All test cases within the same data group have the same grouping field value.

[0090] Preset template mapping table: This refers to the pre-configured mapping table between grouping field values ​​and test script templates, used to find the corresponding test script template based on the grouping field values.

[0091] Target test script template: refers to the test script template corresponding to the grouping field value found from the preset template mapping table, which includes placeholders to be filled and a fixed script logic structure.

[0092] Test script fragment: refers to the executable script content corresponding to the test case generated after filling the field values ​​of the test case into the target test script template, and stored in the form of a string.

[0093] The target test script file is a complete script file formed by assembling the test script fragments corresponding to multiple test cases in their original order. It is the final executable output.

[0094] Normalization processing refers to the process of standardizing the format of column names, including converting English characters in column names to a uniform uppercase and lowercase format, and removing space characters from column names.

[0095] Preset field name library: refers to the pre-configured set of standard system field names, which are used to match the normalized column names to establish a mapping relationship between column names and preset field names.

[0096] Derived parameter values: These are parameter values ​​that are newly generated by performing operations on the original field values ​​extracted from the test cases. They are not original data extracted directly from the test parameter table.

[0097] Field operation configuration information: refers to configuration data containing the transformation expression and the names of the associated fields involved in the transformation expression, which is used to instruct the system how to calculate the derived parameter value based on the original field value.

[0098] Transformation expression: refers to an operation formula that includes operators and variable placeholders. The variable placeholders correspond to the associated field names. During execution, the variable placeholders are replaced with the corresponding field values ​​before evaluation.

[0099] Version identifier: refers to the identification information used to distinguish different release versions of the same test script template, and is stored in the form of a version number.

[0100] Template type: refers to the category of test logic to which the test script template is applicable. Different template types correspond to different script structures and logic frameworks.

[0101] Automotive electronics automated testing is typically deployed in a test environment to verify in-vehicle network communication, signal interaction, and diagnostic functions. In this scenario, the test system generally needs to receive multiple test cases and their parameter information, import the corresponding scripts into the test project, and execute them to complete batch verification of different communication objects and test scenarios.

[0102] In existing solutions, test engineers typically write scripts manually based on test requirements, or use semi-automatic script generation tools that rely on specific input files to complete part of the script construction. The basic approach is to first organize the test information such as signals, cycles, timeouts, and diagnostics in the test cases, then manually or through tools write the relevant fields into the script structure, and finally assemble them into a script file that can be called by the test platform.

[0103] However, this type of solution relies heavily on manual processing. Problems such as missing fields, incorrect order, inconsistent formatting, or logical inconsistencies can easily arise during the extraction, grouping, template selection, and script assembly of test information. Especially when test requirements change frequently and the number of test cases is large, engineers often need to repeatedly adjust multiple script fragments, resulting in low generation efficiency and difficulty in ensuring structural consistency between different test cases.

[0104] Furthermore, when the same batch of test cases involves different test groups, if there is a lack of a unified field extraction and sequential recording mechanism, the generated results may have template adaptation errors or the output file content may not correspond to the original test requirements, thereby increasing the cost of subsequent verification, maintenance and batch updates, and affecting the stability and accuracy of the automated testing process.

[0105] In view of this, how to improve the efficiency of test script generation in multiple test case scenarios, while ensuring the accuracy and consistency of the generated results, has become an urgent technical problem to be solved. To address this issue, a test script generation method is provided. This method obtains multiple test cases, extracts the corresponding grouping field values ​​based on the mapping relationship between pre-configured parameter indicators and preset field names, records the original order, and then completes data grouping, template acquisition, script fragment filling, and assembly according to the original order based on the grouping field values, finally obtaining the target test script file.

[0106] In the corresponding test system architecture, a test requirement input module, a template matching and generation module, and a test execution environment can be deployed together to create a seamless process for test case input, template matching, and script output. This makes it more suitable for batch script generation and subsequent invocation scenarios in automotive electronics automated testing. The technical solution of this application and how it solves the aforementioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0107] Figure 1 A flowchart illustrating the test script generation method provided in this application is shown below. Figure 1 As shown, the method includes:

[0108] S101. Obtain multiple test cases, each test case including multiple parameter indicators and test information corresponding to each parameter indicator.

[0109] Specifically, test cases serve as input objects to be processed, carrying the basic data units required for script generation. Each test case contains multiple parameter indicators, which characterize different parameter categories in the test requirements. Test information carries the specific content corresponding to each parameter indicator.

[0110] In practice, the executing entity can be a script generation service program deployed in the automotive electronics automated testing environment. This service program runs on an industrial control computer, a test server, or a host computer connected to the test environment.

[0111] Multiple test cases can be obtained by reading external files, which can be table files, structured text files, or database export files. The system first receives the test case file path or file stream, then reads the row records, column fields, and cell contents according to preset parsing rules, and organizes each test record into a test case object.

[0112] For tabular files, the system can load test cases by row, parameter names by column, and corresponding test information by cell content; for structured text files, the system can extract parameter indicators and test information by key-value pairs; for database sources, the system can construct multiple test case instances based on the query results.

[0113] To ensure consistency in subsequent processing, the system performs uniform formatting after acquiring multiple test cases. This includes removing whitespace characters, standardizing capitalization, standardizing the representation of time or period fields, filling empty fields with preset placeholders, and creating a list of test cases in memory. If a test case is found to have missing parameter names, duplicate occurrences of the same parameter with conflicting values, or unparseable test information, the system marks the test case as an anomaly and writes it to the log. In this application, only test cases that pass the integrity check proceed to the next processing step.

[0114] By first acquiring multiple test cases and performing unified parsing, subsequent mapping, grouping, template selection, and script population of parameter metrics and test information can be performed on a consistent data structure. In one possible embodiment, multiple test cases can also be obtained by receiving request messages from an external test management platform via an import interface. These request messages contain a set of test cases, test case identifiers, a set of parameter metrics, and corresponding test information. Upon receiving the message, the system performs deserialization and forms a set of objects to be processed. It should be understood that the above examples are merely illustrative and not limiting.

[0115] S102. Based on the mapping relationship between pre-configured parameter indicators and preset field names, extract the group field values ​​corresponding to the preset field names from the test information, and record the original order of each test case.

[0116] Specifically, the pre-configured mapping relationship between parameter indicators and preset field names is used to convert the input parameter indicators into field identifiers that can be recognized by the system. The preset field names are a set of field names predefined by the system and stored in a preset field name library or configuration file, and at least include field identifiers used for classification and template matching.

[0117] In practice, the system loads the mapping configuration before executing this step. The mapping configuration records the correspondence between parameter indicator names and preset field names. For example, it maps the input parameters such as message type, diagnostic service category, or signal group name to the internal preset field name group identifier field.

[0118] Once loading is complete, the system iterates through the parameter index list of each test case. Based on the pre-configured mapping relationship, it extracts the values ​​corresponding to the target preset field names from the test information corresponding to each parameter index, and uses these values ​​as grouping field values. Grouping field values ​​are used to represent the category to which the test case belongs, such as communication tests, diagnostic tests, periodic tests, or more granular template categories.

[0119] During extraction, the system can directly read the raw values ​​from the test information, or it can first normalize the test information, such as converting numeric classification codes to string encoding, using the first subfield of a composite field as the grouping field value, or selecting values ​​at specified positions after splitting content concatenated with delimiters. Simultaneously, the system generates a sequence identifier for each test case according to the input order when retrieving multiple test cases. This sequence identifier can be a consecutive integer index or a position number recorded in a list structure, serving as the concrete carrier of the original order. The original order is used to restore the arrangement relationship consistent with the input test requirements after subsequent test script fragment generation.

[0120] The mapping mechanism enables the system to adapt to different input table formats, and the grouping data can be extracted correctly without manual adjustment of column names; by synchronously recording the original order, the output results are ensured to be arranged in the input order, maintaining the traceability between test requirements and generated scripts.

[0121] In one possible implementation, if a test case corresponds to multiple preset field names that can be used for grouping, the system selects one of the field values ​​as the primary grouping field value according to a preset priority rule, which can be preset in the configuration file. It should be understood that the above example is merely illustrative and not limiting.

[0122] S103. Divide the test cases into multiple data groups based on the grouping field value.

[0123] Specifically, the grouping field value serves as the basis for classifying test cases, and the data group is used to represent a set of test cases aggregated according to the same or corresponding grouping field values.

[0124] In practice, after extracting the grouping field values ​​for each test case, the system creates a grouping index structure. This index structure can be a hash table, a dictionary table, or a temporary grouping table in the database. The keys are the grouping field values, and the values ​​are the sets of test cases belonging to those grouping field values. The system iterates through the test case list, reads the grouping field value for each test case, and checks if the corresponding group already exists in the current index structure. If it does, the test case is added to the existing data group; otherwise, a new data group is created and written to the current test case.

[0125] For test cases with empty grouping field values, invalid formats, or values ​​outside the allowed range, this application can classify them into an abnormal group or abort the generation process according to the configuration. If there are different representations in the test information that can be mapped to the same grouping category, such as "fault diagnosis" and "diagnosis-fault" corresponding to the same template category, the system will first convert them into unified grouping field values ​​according to the grouping normalization rules before performing formal grouping.

[0126] After grouping, each data group retains details of the test cases within the group, the sequence identifier of each test case, and the corresponding group field values. Subsequent template retrieval and field population can be performed separately for each data group, without needing to determine the template type independently for each test case.

[0127] By dividing multiple test cases into multiple data groups, test script fragments for similar test requirements can be generated under a unified template framework, reducing repeated template searches and inconsistent test script structures.

[0128] In one possible embodiment, the system may also output grouping statistics after grouping is completed. These statistics include at least the number of data groups, the number of use cases per group, and the number of abnormal groups. The system will then save these statistics to the processing context for subsequent auditing and debugging. It should be understood that the above example is merely illustrative and not limiting.

[0129] S104. Obtain the target test script template corresponding to the grouping field value from the preset template mapping table.

[0130] Specifically, the preset template mapping table is used to store the correspondence between grouping field values ​​and test script templates, and the target test script template is the template carrier used to generate test script fragments.

[0131] In practice, the preset template mapping table can be stored in a local configuration file, relational database, key-value store, or template management service. The table should contain at least information such as grouping field values, template identifier, template content storage address, and effective status.

[0132] After obtaining the grouping field values ​​for each data group, the system accesses the preset template mapping table group by group, using the grouping field values ​​as search criteria to find the corresponding template record. If the query result is unique, the template content associated with that template record is directly loaded into memory as the target test script template for that data group; if the query result contains multiple candidate templates, the target template is determined according to preset rules; if no matching template is found, the system marks the corresponding data group as having a missing template and records the grouping field values ​​and the affected test case identifiers in the log.

[0133] In this application, the target test script template can be template text containing a fixed test script framework and placeholders. The placeholders in the template are used to identify the positions that need to be replaced with field values ​​later. After the template content is loaded, the system can also perform a pre-check on the template syntax, including whether the template file is readable, whether the placeholders are closed, and whether the necessary placeholder fields exist, to ensure that the subsequent filling process can be executed.

[0134] A pre-defined template mapping table establishes a stable correspondence between grouping logic and template logic, enabling the system to automatically select the appropriate test script framework for different types of test cases. By replacing the single, universal template filling method with a differentiated template matching mechanism, the generated test scripts can adapt to the logical requirements of various test types, improving the applicability and flexibility of the script generation method.

[0135] In one possible embodiment, the template mapping table can also maintain independent sub-tables for different projects, different controllers, or different bus types. The system selects the corresponding sub-table based on the current batch processing context before performing template retrieval. It should be understood that the above examples are merely illustrative and not limiting.

[0136] S105. Fill the field values ​​of each data group into the corresponding target test script template to generate multiple test script fragments.

[0137] Specifically, the field values ​​come from the test information in the test cases and the intermediate data obtained based on the test information. The test script fragments are the partial test script results after the template has been replaced with specific content.

[0138] In practice, after obtaining the corresponding target test script template for each data group, the system first establishes a template field list, which is obtained by parsing the placeholder marks in the template. Within that data group, the system extracts the field values ​​corresponding to the placeholder marks for each test case. Field value extraction can be directly completed based on the mapping results between parameter indicators and preset field names. For example, it can read message names, signal names, transmission periods, timeout thresholds, diagnostic commands, expected return values, trigger conditions, and termination conditions from the test information. For fields required by the template but not directly given in the original test information, derivation calculations can be performed according to preset rules. For example, combining the period field with the timeout multiple yields the waiting time, and converting hexadecimal diagnostic parameters into string representations agreed upon in the template.

[0139] After extraction, the system performs format validation and type conversion on the field values ​​to ensure that text, numeric, and boolean content conform to the template syntax requirements. For example, numeric values ​​retain a specified number of digits, strings are enclosed in quotes according to the syntax required by the corresponding software, and boolean states are converted to predefined identifiers. The system performs replacement operations according to the placeholder positions in the template. The replacement method can be direct string replacement, or the field key-value pairs can be injected into the template context through the template engine to complete the rendering.

[0140] If a data group contains multiple test cases, the system can generate a corresponding test script fragment for each test case based on the template design, or it can write multiple test case blocks sequentially under the group-level template framework to form a combined test script fragment for the data group.

[0141] In this application, to maintain the correspondence between test cases in subsequent assembly, the system generates an independent test script fragment for each test case and associates the test case identifier, grouping field value, and original order identifier in the fragment metadata. If a necessary placeholder field exists in the template but the current test case does not provide a corresponding field value, the system marks the test case as a failure to fill the field and does not write it into the normal output set.

[0142] By filling field values ​​into target test script templates that match grouping field values ​​according to rules, the generated test script content directly corresponds to the test requirements and maintains structural consistency within the same group of test cases. Simultaneously, by replacing manual script writing with a template-filling mechanism, script fragments for each test case are automatically generated, avoiding the inefficient operation and human error of manually writing scripts line by line.

[0143] In one possible embodiment, after generating the test script fragment, the system can also call a syntax checker to perform static validation on the fragment, confirming that the parentheses, semicolons, keywords, and function call formats meet the requirements of the target testing platform. It should be understood that the above examples are merely illustrative and not limiting.

[0144] S106. Assemble the test script fragments corresponding to each test case in their original order to obtain the target test script file.

[0145] Specifically, the target test script file is the final output script file of this method that can be called by the test environment. The original order is used to constrain the arrangement of each test script fragment in the final file.

[0146] In practice, after obtaining multiple test script fragments, the sequence identifier associated with each fragment is first read, and the fragments are sorted in ascending order according to the sequence identifier to form a fragment queue consistent with the input test cases. The fragments are then written to the target file buffer according to preset assembly rules. Assembly rules may include writing to the file header, public variable area, function definition area, test script fragment body area, and file footer, where the test script fragments in the test script fragment body area are strictly concatenated in their original order.

[0147] After assembly, the system outputs the buffer contents as the target test script file and saves it to the local project directory, shared directory, or import directory specified by the test platform. It also returns the file path, generation status, and exception information.

[0148] To ensure that the output content is consistent with the input test requirements, the system can also perform a sequence consistency check after assembly, that is, compare whether the original sequence list of test cases corresponds one-to-one with the sequence list of fragments in the file; if the check fails, the target test script file is marked as invalid and a reassembly or exception report is triggered.

[0149] By assembling the test cases in their original order instead of manually sorting them, the test logic in the final test script file is arranged in accordance with the initial input test cases. This ensures that the correspondence between the output content and the original test requirements remains consistent during batch generation. Maintaining logical consistency between the test case order in the output script and the input test requirements improves the readability of the generated script and enhances subsequent maintenance efficiency.

[0150] As can be seen from the preceding steps, this application solves the problems of field omission, disordered order, template mismatch, and content mismatch that are prone to occur when manually compiling test scripts or relying on scattered input methods by using a continuous processing chain of unified test case acquisition, field mapping extraction, group processing, template retrieval, template filling, and assembly in the original order. This ensures that the test script generation process in batch testing scenarios has a stable data source, clear classification criteria, and a consistent output structure.

[0151] The test script generation method provided in this application eliminates the impact of input table column name format differences on parameter extraction by pre-configuring the mapping relationship between parameter indicators and preset field names. Based on grouping field values, test cases are automatically divided into multiple data groups, and corresponding script templates are matched to each data group. Then, multiple script fragments generated according to the original order of each test case are assembled into a target test script file. This allows the test script generation process to automatically convert tabular test requirements into structured executable scripts without manual intervention, significantly improving the efficiency of batch test script generation and the logical consistency of output results. When generating test scripts, batch test cases maintain consistent field extraction rules, determined template adaptation relationships, and traceable output order. The generated target test script file can establish a stable correspondence with the original test requirements, making it suitable for batch test script generation scenarios in automotive electronic automation testing.

[0152] Figure 2 Flowchart of the test script generation method provided in this application Figure 2 ,like Figure 2 As shown, this embodiment, based on the above embodiments, provides a detailed description of the test script generation method, which includes:

[0153] S201. Extract the fill field values ​​from each data group according to the mapping relationship.

[0154] Specifically, the mapping relationship records the correspondence between preset field names and parameter indicators. By querying the mapping relationship, the data source location corresponding to each preset field name can be determined. After locating the location from the test information of the test case, the corresponding value can be read.

[0155] By automatically locating fields and extracting data through mapping relationships, the repetitive operation of manually searching and copying parameter values ​​one by one from the table is avoided, thus improving the accuracy and efficiency of data extraction.

[0156] S202. Calculate the derived parameter values ​​based on the fill field values ​​and the preset field operation configuration information, so as to fill the fill field values ​​and derived parameter values ​​into the corresponding target test script template.

[0157] Specifically, by pre-storing the calculation logic in the form of configuration information, and loading the configuration and executing the calculation at runtime, secondary processing of the original field values ​​is achieved. This configuration information includes the calculation expression and the correspondence between each variable in the expression and the value of the filled field.

[0158] By automatically calculating derived parameter values ​​using the configuration information, the data sources required for template filling are expanded from the original field values ​​to a wider range that includes the calculation results. Testers do not need to pre-fill all the parameters required by the script in the table, reducing the workload of manual pre-calculation.

[0159] In its implementation, after dividing the data into groups, the system reads the mapping table corresponding to each data group, locates the fill fields whose names match the target template field names, and extracts these field values ​​from the data group. The mapping relationship can consist of field names, field indexes, or field identifiers to ensure extraction even when test case parameter names are not entirely consistent. For fields requiring derivation, the system calls the corresponding calculation rules based on preset field operation configuration information, such as multiplying the period value with a multiplier, or combining the starting value, offset, and constraint conditions to obtain derived parameter values. The calculated derived parameter values ​​and fill field values ​​are written into the corresponding placeholder area in the same target test script template, forming a test script fragment with complete parameter content.

[0160] In one possible implementation, the target test script template can pre-set field placeholders, expression placeholders, and script statement placeholders. During the population process, the system first replaces the field values ​​with the corresponding placeholder content, and then writes the derived parameter values ​​to the corresponding positions of the expression placeholders, thus ensuring consistency between the direct fields and calculated fields in the template. If the same data group corresponds to multiple field values ​​or multiple derived parameter values, the system performs calculations and population sequentially according to the association order defined in the preset field operation configuration information, ensuring that the parameter arrangement in the output test script is consistent with the semantics of the test script. In this way, the test script template can simultaneously carry both original test information and calculation result information, allowing the generated target test script file to be directly used in the test project.

[0161] Both the fill field values ​​and derived parameter values ​​are uniformly controlled by the mapping relationship and operation configuration information. The generation process of the test script fragment can maintain the consistency of field source, calculation logic and writing position, thereby enabling the final output test script file to have high structural stability and parameter integrity.

[0162] In some alternative implementations, S202 above includes:

[0163] S2021. Obtain the preset field operation configuration information. The preset field operation configuration information includes the conversion expression and the associated field name corresponding to the conversion expression.

[0164] Specifically, the computational logic is stored as expression text. Variable identifiers are extracted by parsing the expression structure, and these identifiers are then mapped to predefined field names. Storing the computational logic in a configurable manner allows the calculation rules for derived parameters to be modified and extended independently of the program code, improving the system's flexibility and maintainability.

[0165] S2022. Obtain the target field value corresponding to the associated field name from the populated field values.

[0166] Specifically, using the associated field name as the query key, the system retrieves the field value corresponding to that associated field name from the populated field value set and identifies that value as the target field value. For each variable placeholder in the transformation expression, a retrieval operation is performed to obtain the corresponding target field value. Utilizing the key-value pair structure in the populated field value set, the system obtains the corresponding numerical value through field name matching, providing the specific operands for each variable in the transformation expression.

[0167] By replacing variable placeholders in the transformation expression with actual numerical values, the expression becomes computable. This enables data transfer from original field values ​​to computational expressions, ensuring that the input data for calculation operations accurately corresponds to each variable.

[0168] S2023. Calculate the derived parameter value based on the transformation expression and the target field value.

[0169] Specifically, the variable placeholders in the transformation expression are replaced with the corresponding target field values ​​to form a mathematical expression containing specific numbers. This mathematical expression is then evaluated, and the result is output as the derived parameter value. An expression evaluation algorithm parses and calculates the replaced mathematical expression, performing operations according to operator precedence and bracket rules to obtain the calculation result.

[0170] By replacing manual calculation with automated expression evaluation, arithmetic errors that may be introduced by manual calculation are eliminated, ensuring the accuracy and consistency of derived parameter values.

[0171] In practical implementation, the preset field operation configuration information can be stored in the configuration table or field mapping table corresponding to the test script template. After receiving the field value to be filled, the system first retrieves the corresponding data item based on the associated field name, and then sends the data item as the calculation input to the conversion expression. The conversion expression can take the form of arithmetic operation, string concatenation, conditional judgment, or type conversion. When the target field value meets the data type required by the expression, the operation is performed directly; when the target field value is a composite field, the field can be split or the format normalized first, and then substituted into the expression for calculation, thereby outputting a derived parameter value consistent with the current test case parameter. If the preset field operation configuration information contains multiple associated field names, the system can retrieve the values ​​sequentially according to the preset reference order in the expression and complete the joint calculation, finally obtaining a derived parameter value that can be directly written into the target test script template. In practical applications, the storage medium of this configuration table can also be other models, which is not limited in this application.

[0172] The above processing enables the system to automatically generate parameter content derived from expressions based on the filled field values. These derived parameter values ​​can be directly used to fill in test script fragments, reducing reliance on manual input and maintaining consistency in parameter calculation rules across the same batch of test cases. Because a clear correspondence is established between the transformation expression and the associated field names, the system can reliably acquire input fields and complete automatic calculations when generating test scripts, thereby improving the accuracy of matching the generated test script results with the original test requirements.

[0173] Figure 3 Flowchart of the test script generation method provided in this application Figure 3 ,like Figure 3 As shown, in some optional implementations, it also includes:

[0174] S301. Filter multiple candidate field names from the test information based on the mapping relationship.

[0175] Specifically, it iterates through all preset field names, searches for the corresponding parameter metric in the mapping relationship for each preset field name, extracts the value of that parameter metric from the test information of the test cases, and determines whether the value is null or invalid. Preset field names with non-null and valid values ​​are identified as candidate field names, and a candidate field name set is constructed.

[0176] Data validity checks filter out fields with valid values, excluding null or invalid fields, ensuring that all input data used to determine subsequent relationships is valid. From all preset field names, fields with valid values ​​in the current test case are selected, narrowing down the data range for determining relationships.

[0177] S302. Based on the candidate field names, determine the association relationships between the candidate field names from the preset field association rules.

[0178] Specifically, the system retrieves preset field association rules, which contain criteria for determining the relationships between field names. For each field name in the candidate field name set, the test device compares and matches them one by one according to the criteria in the preset field association rules to determine which field names have relationships. A relationship refers to an attribute relationship between two or more field names that has operational dependencies or logical connections; for example, the value of one field is derived from the value of another field through an operation.

[0179] By matching candidate field names with conditions in preset association rules, the system identifies combinations of field names that meet the association conditions, determines the association type and direction between each field name, and discovers the dependencies between fields. This eliminates the need for manual analysis and configuration of field associations, reducing the complexity of field operation configuration.

[0180] S303. Generate preset field operation configuration information based on the association relationship.

[0181] Specifically, based on the established relationships, the dependent field is determined as the associated field name in the transformation expression, and the dependent field is determined as the output field of the transformation expression. The test device converts the relationships into structured configuration information containing the transformation expression and the associated field names, and stores this configuration information in the preset field operation configuration information.

[0182] The field relationships described by natural language or logical rules are converted into structured configuration data that can be parsed by computers. The operation logic between fields is expressed by conversion expressions, which enables the field operation configuration information to be dynamically generated according to the actual data situation, thereby improving the accuracy and adaptability of the configuration.

[0183] In this implementation, after acquiring the test information, the system first iterates and matches the field items in the test information according to the pre-configured parameter indicators and field mapping relationships, extracting the field names that correspond to the mapping relationships as candidate field names. The mapping relationship can be determined by the field name, field type, field source identifier, or field meaning identifier. Each candidate field name is then input into a preset field association rule base for association determination. The rule base can pre-store relationships such as similar field relationships, master-detail field relationships, difference relationships, ratio relationships, or dependency relationships. The system determines the association relationships between candidate field names based on the rule matching results. Based on these association relationships, the system generates preset field operation configuration information. The configuration information includes at least a transformation expression and the corresponding associated field name, indicating which target field values ​​to extract from the fill field values ​​and what operation method to use to calculate the derived parameter values.

[0184] In practical applications, the preset field association rules can be carried by configuration files, rule tables, or database records. The operation configuration information can be output as structured data according to the template field requirements of the test project. In practical applications, the rule base and configuration information carrier can also be selected from other models or forms, and this application does not limit them.

[0185] This method identifies candidate field names during the test information filtering phase and establishes computational dependencies between fields through preset field association rules. These dependencies are then converted into computational configuration information, providing clear input and expression bases for subsequent calculations of derived parameter values. This improves the consistency of field configurations and the matching accuracy of generated test scripts. Because the association relationships are uniformly determined by preset rules, the generated results of multiple test cases on field computational configurations remain consistent, facilitating automated processing and subsequent invocation of batch test scripts.

[0186] This invention extracts fill field values ​​from each data group according to the mapping relationship, and performs operations on the fill field values ​​according to the preset field operation configuration information to obtain derived parameter values. The fill field values ​​and derived parameter values ​​are then used to fill the target test script template. This allows the derived parameter values ​​to be automatically generated and participate in the template filling without manual pre-calculation or additional input. At the same time, preset field operation configuration information is automatically generated through candidate field name filtering and field association rules, further reducing the workload of manually configuring the operation logic.

[0187] Figure 4 Flowchart of the test script generation method provided in this application Figure 4 ,like Figure 4 As shown, this embodiment, based on the above embodiments, provides a detailed description of the test script generation method, which includes:

[0188] S401. When there are multiple test script templates in the preset template mapping table that correspond to the grouping field value, obtain the version identifier of the corresponding test script template.

[0189] Specifically, the search operation is performed in the preset template mapping table using the grouping field value as the query key. When the search results return multiple test script templates, the test device detects the existence of multiple templates and then obtains the version identifier corresponding to each test script template. The version identifier is identification information used to distinguish different release versions of the same template, and can be in the form of version number or version name, etc.

[0190] Templates in the template mapping table may have multiple versions due to modifications, optimizations, or adaptations to different testing environments. Each version is distinguished by a version identifier. When multiple results are returned, the system uses the version identifier to differentiate the version of each template, avoiding uncertainty in template selection caused by the coexistence of multiple versions.

[0191] S402. Based on the preset priority of the version identifier, determine the target test script template corresponding to the grouping field value from multiple test script templates.

[0192] Specifically, a preset version priority rule is obtained, which specifies the priority order among different version identifiers. The test device sorts multiple candidate test script templates according to this priority order and determines the test script template with the highest priority as the target test script template corresponding to the grouping field value.

[0193] By establishing a selection order among versions through pre-defined priority rules, the version with the highest priority is automatically selected according to this order when multiple versions coexist, ensuring the certainty and consistency of template selection and avoiding the subjectivity and uncertainty of manual judgment and selection.

[0194] In practical implementation, after retrieving multiple test script templates from the preset template mapping table based on the grouping field value, the system first reads the identifiers of each candidate template, and then compares the reading results with preset priority rules. This preset priority can be pre-configured in the template management module and establishes a one-to-one hierarchical relationship with the version identifier. The system sorts the multiple candidate templates according to this hierarchical relationship and selects the template with the highest ranking as the target test script template. If the version identifiers of multiple candidate templates are different, the higher priority is determined by the revision order or release level reflected by the version identifier; if the version identifiers are the same, the template that was registered earlier or has a valid status can be directly determined as the target test script template. In practical applications, the encoding method of the version identifier can also use strings, integers, or composite fields; this application does not limit this.

[0195] By introducing version identifiers and preset priorities when there are multiple templates, the system can form a deterministic selection result among multiple candidate test script templates and stably output the target test script template that matches the grouping field value. Thus, the template selection process is combined with template version management, ensuring the consistency and traceability of the generated test script results even when the same grouping field value is updated or coexisting, thereby reducing template selection ambiguity and improving the accuracy of test script generation.

[0196] In some alternative implementations, it also includes:

[0197] S403: When the version identifiers are different and the template types corresponding to each test script template are the same, obtain the creation time of each test script template.

[0198] Specifically, the test involves checking whether the version identifiers of multiple candidate test script templates are different, and also checking whether the template types of each template are the same. When both conditions are met, the test device reads the creation time field from the metadata information of each template to obtain the creation time of each template. The creation time refers to the timestamp recorded by the system when the template file was first generated.

[0199] In scenarios where templates of the same type but different versions exist, different versions of templates are applicable to the same test type but have different revision statuses. The order of each version can be determined by the creation time, avoiding the problem of not being able to determine the age by relying solely on version identifiers.

[0200] S404 sorts the test script templates in descending order of creation time and uses the first test script template in the sequence as the target test script template.

[0201] Specifically, the candidate test script templates are sorted in ascending order of creation time, with later-created templates at the top of the sequence and earlier-created templates at the bottom. After sorting, the test device selects the first test script template in the sequence as the target test script template.

[0202] In scenarios where different version identifiers exist but the template type is the same, the template created later represents a newer revision, which usually contains more complete logic or corrective content. Selecting the latest template conforms to the conventional logic of template iteration and updates, ensuring the timeliness and correctness of template selection.

[0203] In this application, the creation time is used to characterize the generation sequence of each test script template. It can be automatically written by the template management module when a template is added to the database, edited and saved, or a version is released. The time field can be stored in the template metadata as a timestamp of year, month, day, hour, minute, and second, so as to serve as a template selection criterion when version identifiers cannot directly distinguish between templates and the template types are consistent. The template type of each test script template can be extracted from the template header information, template attribute table, or template registration record. Consistent template types indicate that they are designed for the same test script structure and filling scenario, thus allowing the creation time to be used for sorting and selecting templates of the same type. In practical applications, the creation time can also be the database record time, file system write time, or a standard time generated by a unified time service; this application does not limit this.

[0204] When multiple test script templates in the template mapping table have different version identifiers, the system first checks whether these templates have the same template type. If the template types are the same, it further reads the creation time of each test script template and sorts them from newest to oldest. The first test script template in the sorted result is determined as the target test script template. Subsequent test script fragment filling, template instantiation, and output assembly corresponding to the grouping field values ​​are all performed based on this target test script template. This processing method ensures that templates of the same type can be filtered according to the latest generated record when their versions are inconsistent, guaranteeing that the template selection result is consistent with the current template maintenance status.

[0205] By adopting the above method, in scenarios where version identifiers are different but template types are the same, the system can quickly determine the target test script template based on the creation time, reducing the workload of manually judging the order of templates and making the selection rules of similar templates more unified, thereby improving the stability and consistency of test script template matching results.

[0206] In some alternative implementations, it also includes:

[0207] S405: When the version identifiers are different and the template types are different, the target test script template is determined from multiple test script templates according to the preset template type priority.

[0208] Specifically, the test equipment checks whether the version identifiers of multiple candidate test script templates are different, and also checks whether the template types of each template are different. When both conditions are met, the test equipment obtains a preset template type priority rule, which specifies the priority order among different template types. The multiple candidate test script templates are sorted according to this priority order, and the test script template with the highest priority is determined as the target test script template corresponding to the grouping field value.

[0209] In scenarios with different template types, each template type represents a different test logic framework. The preset template type priority rule pre-sets the priority level of each type according to the execution order or importance of different test types. The preset template type priority mechanism solves the selection problem when there is a conflict between cross-type templates, enabling the system to automatically determine the template in multi-type adaptation scenarios.

[0210] In its implementation, the system first reads the version identifiers and template types of multiple test script templates corresponding to the same grouping field value, and inputs candidate templates with different version identifiers and template types into the template determination unit. The template determination unit pre-stores a template type priority table, which can be configured according to the test scenario coverage, test script compatibility, or template adaptability of the template. After comparing the template types of each candidate template, the system selects the template with the highest priority as the target test script template and outputs this target test script template to the subsequent field filling and test script fragment generation stages.

[0211] During operation, the template management module first excludes templates with the same version identifier. Then, it performs type priority judgment on templates with different version identifiers and different template types, ultimately locking in a unique target test script template. This target test script template serves as the carrier structure for subsequent test script generation. Its internal field placeholders, test script framework, and calling relationships remain consistent with the current test requirements, ensuring that the template selection result can work in conjunction with grouping field values, version control rules, and template type rules.

[0212] With this implementation method, when multiple templates simultaneously meet the version difference conditions, the selection can be completed directly based on the template type priority. The process of determining the target template is consistent with the template version management and scenario classification rules, reducing template mismatch caused by manual judgment, and ensuring that the subsequent test script fragment filling and assembly results are consistent with the test requirements.

[0213] This invention solves the template selection problem in multi-template matching by obtaining the version identifier of each template when there are multiple test script templates corresponding to the grouping field value in the preset template mapping table, and determining the target test script template according to the preset priority of the version identifier. In the scenario where the version identifiers are different but the template types are the same, the latest version is selected by sorting in descending order of creation time. In the scenario where the version identifiers are different and the template types are different, the selection is based on the preset template type priority, so that the template selection operation can be completed automatically in various multi-template matching situations.

[0214] Figure 5 Flowchart of the test script generation method provided in this application Figure 5 ,like Figure 5 As shown, this embodiment, based on the above embodiments, provides a detailed description of the test script generation method, which includes:

[0215] S501. Match the parameter indicators with the preset field names in the preset field name library.

[0216] Specifically, a preset field name library is retrieved, which contains multiple preset field names supported by the system. For each parameter index parsed from the test parameter table, the test device compares the name of the parameter index with each preset field name in the preset field name library to determine if a preset field name exists that matches the parameter index name. The matching operation can use either exact string matching or fuzzy matching. Fuzzy matching refers to matching after ignoring character case differences and removing spaces.

[0217] The preset field name library stores a set of standard field names that the system can recognize. By matching the parameter indicator names in the input table with this standard set, it can be determined which parameter indicators can be correctly recognized and processed by the system. By automatically matching instead of manually confirming the correspondence between parameter indicators and field names, the workload of manual configuration mapping is reduced.

[0218] S502. Check whether there are any abnormal indicators in the detection parameters that do not match the preset field names.

[0219] Specifically, all parameters are iterated through, and each parameter is checked to see if its corresponding preset field name was successfully found in the S401 matching operation. Parameters that fail to match any preset field name are marked as abnormal parameters. Abnormal parameters refer to parameters that exist in the input table but cannot be recognized by the system, usually caused by misspelled column names, non-standard naming formats, or the use of custom column names not supported by the system.

[0220] By analyzing the matching results, parameters that are not recognized by the system are identified, and unmatched metrics are separated from the normal processing flow. This avoids subsequent parameter extraction failures due to unrecognized fields and reduces parameter extraction failures caused by field mismatches.

[0221] S503. When there are no abnormal indicators, establish a mapping relationship between the parameter indicators and the corresponding preset field names.

[0222] Specifically, the system detects the number of abnormal indicators. When the number of abnormal indicators is zero, it is determined that all parameters have successfully matched the corresponding preset field names. The testing equipment then creates key-value pairs between each parameter and its matched preset field names and stores them in a mapping table, thus establishing the mapping relationship between the parameter indicators and the preset field names.

[0223] When all parameters can be recognized by the system, the correspondence between the successfully matched parameters and the preset field names is persistently stored, which automates the process of generating the mapping relationship and reduces the workload and error probability of manual configuration.

[0224] In practical implementation, after receiving the parameter indicators from the test information, the system compares each parameter indicator sequentially with the preset field names in the preset field name database. Matching methods can include exact match, string matching after removing spaces, alias mapping match, or rule matching based on a preset thesaurus. During the matching process, the system records the matching result and corresponding field name identifier for each parameter indicator. After completing the retrieval of all parameter indicators, it summarizes and judges the unmatched items. If there is a parameter indicator that does not correspond to any preset field name, it is marked as an abnormal indicator and the mapping is terminated. If all parameter indicators can find corresponding preset field names, a mapping table is generated according to the one-to-one correspondence between parameter indicators and field names, for subsequent grouping field value extraction, template selection, and script filling.

[0225] The mapping relationship establishment process can be completed collaboratively by a configuration module storing a preset field name library, a parsing module for performing matching judgments, and a mapping table generation module for recording mapping results. The preset field name library stored in the configuration module can be stored in a table structure, key-value pair structure, or index structure, facilitating retrieval by field name, alias, or code. The parsing module performs item-by-item comparison and anomaly detection upon receiving parameter indicators. The mapping table generation module only writes the corresponding relationship when an anomaly indicator is empty, and outputs the parameter indicator name along with the preset field name as a standardized result. If the system uses a preset version of the preset field name library, the corresponding library content can be loaded via the field name version number, ensuring consistent field parsing for the same batch of test cases across different test script template environments.

[0226] Based on the above method, parameter indicators can be stably mapped to preset field names. When extracting grouping field values ​​from test information, the target field can be directly located based on this mapping relationship, thus supporting data group partitioning and test script template filling. By detecting abnormal indicators before establishing the mapping, the system can ensure that all fields entering subsequent processing have clear and standardized correspondences, thereby ensuring consistency and traceability of field parsing results and making the generation of target test script files more consistent with the original test requirements.

[0227] This invention matches parameter indicators with preset field names in a preset field name library to detect whether there are any unmatched abnormal indicators among the parameter indicators. If no abnormal indicators are found, a mapping relationship between the parameter indicators and the corresponding preset field names is established. This enables the mapping relationship establishment process to have an anomaly detection and automatic establishment mechanism. The mapping is only established when all parameter indicators can be recognized by the system, avoiding the failure of subsequent processing steps due to the existence of abnormal indicators, and improving the fault tolerance of the system and the reliability of the mapping relationship establishment.

[0228] Figure 6 A schematic diagram of the test script generation device provided in this application is shown below. Figure 6 As shown, the test script generation device 60 provided in this embodiment includes:

[0229] The acquisition module 601 is used to acquire multiple test cases, each test case including multiple parameter indicators and test information corresponding to each parameter indicator;

[0230] The extraction module 602 is used to extract the group field values ​​corresponding to the preset field names from the test information based on the mapping relationship between the pre-configured parameter indicators and the preset field names, and to record the original order of each test case;

[0231] The partitioning module 603 is used to divide test cases into multiple data groups based on the grouping field value;

[0232] Matching module 604 is used to obtain the target test script template corresponding to the grouping field value from the preset template mapping table;

[0233] The generation module 605 is used to fill the field values ​​of each data group into the corresponding target test script template to generate multiple test script fragments.

[0234] The generation module 605 is also used to assemble the test script fragments corresponding to each test case in their original order to obtain the target test script file.

[0235] In one possible implementation, it also includes:

[0236] Extract the fill field values ​​from each data group based on the mapping relationship;

[0237] The derived parameter values ​​are calculated based on the fill field values ​​and the preset field operation configuration information, and then the fill field values ​​and derived parameter values ​​are filled into the corresponding target test script template.

[0238] In one possible implementation, calculating the derived parameter value includes:

[0239] Retrieve preset field operation configuration information, which includes the conversion expression and the associated field name corresponding to the conversion expression;

[0240] Retrieve the target field value corresponding to the associated field name from the populated field value;

[0241] Calculate the derived parameter value based on the transformation expression and the target field value.

[0242] In one possible implementation, it also includes:

[0243] Filter multiple candidate field names from the test information based on the mapping relationship;

[0244] Based on the candidate field names, determine the association relationships between the candidate field names from the preset field association rules;

[0245] Generate preset field operation configuration information based on the association relationship.

[0246] In one possible implementation, it also includes:

[0247] When there are multiple test script templates corresponding to the grouping field value in the preset template mapping table, obtain the version identifier of the corresponding test script template;

[0248] Based on the preset priority of the version identifier, the target test script template corresponding to the grouping field value is determined from multiple test script templates.

[0249] In one possible implementation, it also includes:

[0250] When the version identifiers are different and the template types corresponding to each test script template are the same, obtain the creation time of each test script template;

[0251] The test script templates are sorted in descending order of creation time, and the first test script template in the sequence is used as the target test script template.

[0252] In one possible implementation, it also includes:

[0253] When the version identifiers are different and the template types are different, the target test script template is determined from multiple test script templates according to the preset template type priority.

[0254] In one possible implementation, the mapping relationship is established in the following way:

[0255] Match the parameter indicators with the preset field names in the preset field name library;

[0256] Check if there are any abnormal indicators in the detection parameters that do not match the preset field names;

[0257] When no abnormal indicators exist, establish a mapping relationship between the parameter indicators and the corresponding preset field names.

[0258] The test script generation device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0259] Figure 7 A schematic diagram of the structure of the electronic device provided in this application. Figure 7 As shown, the electronic device 70 provided in this embodiment includes at least one processor 701 and a memory 702. Optionally, the electronic device 70 further includes a communication component 703. The processor 701, memory 702, and communication component 703 are connected via a bus 704.

[0260] In a specific implementation, at least one processor 701 executes computer execution instructions stored in memory 702, causing at least one processor 701 to perform the above method.

[0261] The specific implementation process of processor 701 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0262] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0263] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0264] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0265] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0266] This application also provides a testing method, including: obtaining a target test script file according to the above-described test script generation method;

[0267] Tests are executed based on the target test script file.

[0268] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0269] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0270] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0271] The division of units is merely a logical functional division; 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 coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0272] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0273] In addition, the functional units in the various embodiments of the present invention 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.

[0274] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0275] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0276] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope.

Claims

1. A method for generating test scripts, characterized in that, include: Obtain multiple test cases, each test case including multiple parameter metrics and test information corresponding to each parameter metric; Based on the mapping relationship between pre-configured parameter indicators and preset field names, the group field values ​​corresponding to the preset field names are extracted from the test information, and the original order of each test case is recorded. Based on the grouping field value, the test cases are divided into multiple data groups; Obtain the target test script template corresponding to the grouping field value from the preset template mapping table; Fill the field values ​​of each data group into the corresponding target test script template to generate multiple test script fragments; The test script fragments corresponding to each test case are assembled in the original order to obtain the target test script file.

2. The method according to claim 1, characterized in that, Also includes: The fill field values ​​are extracted from each of the data groups according to the mapping relationship; The derived parameter values ​​are calculated based on the filled field values ​​and the preset field operation configuration information, so as to fill the filled field values ​​and the derived parameter values ​​into the corresponding target test script template.

3. The method according to claim 2, characterized in that, The calculation of derived parameter values ​​includes: Obtain preset field operation configuration information, which includes a conversion expression and the associated field name corresponding to the conversion expression; Obtain the target field value corresponding to the associated field name from the populated field values; The derived parameter value is calculated based on the transformation expression and the target field value.

4. The method according to claim 2, characterized in that, Also includes: Based on the mapping relationship, multiple candidate field names are filtered from the test information; Based on the candidate field names, determine the association relationships between the candidate field names from the preset field association rules; The preset field operation configuration information is generated based on the association relationship.

5. The method according to claim 1, characterized in that, Also includes: When there are multiple test script templates in the preset template mapping table that correspond to the grouping field value, obtain the version identifier of the corresponding test script template; Based on the preset priority of the version identifier, the target test script template corresponding to the grouping field value is determined from multiple test script templates.

6. The method according to claim 5, characterized in that, Also includes: When the version identifiers are different and the template types corresponding to each test script template are the same, obtain the creation time of each test script template; The test script templates are arranged in descending order of their creation time, and the first test script template in the sequence is taken as the target test script template.

7. The method according to claim 6, characterized in that, Also includes: When the version identifiers are different and the template types are different, the target test script template is determined from the multiple test script templates according to the preset template type priority.

8. The method according to claim 1, characterized in that, The mapping relationship is established in the following way: Match the parameter index with the preset field names in the preset field name library; Detect whether there are any abnormal indicators among the parameter indicators that do not match the preset field name; When the abnormal indicator does not exist, a mapping relationship is established between the parameter indicator and the corresponding preset field name.

9. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method according to any one of claims 1 to 8.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1 to 8.

Images