Test script generation method and device, electronic equipment and storage medium

Abstract

The invention provides a test script generation method and device, electronic equipment and a storage medium, and the method comprises the steps: obtaining test input information containing demand information and test data, carrying out the structural processing of the test input information into a parameter dictionary, and determining a target feature based on the test input information to match a target test template constructed based on a specific grammar template engine, and finally, binding the parameter dictionary with the target test template, and dynamically rendering to generate a script file conforming to a test rule. According to the method, the test input information is subjected to structured processing to form the parameter dictionary, the target template is accurately matched and dynamically rendered, and the script generation efficiency and quality are greatly improved.

Description

Technical Field

[0001] The present application relates to the field of testing, and in particular to a test script generation method, device, electronic device and storage medium. Background Art

[0002] With the continuous development of in-vehicle electronic systems and smart cockpit technologies, the number of in-vehicle functional modules continues to increase, and the functional linkages are becoming increasingly complex. To ensure the software quality of in-vehicle systems, test engineers must complete a large number of automated tests based on CAN signals, UDS diagnostics, system events, and other multi-dimensional aspects during the development cycle. The current mainstream testing method relies on manual test script writing to achieve test process automation.

[0003] With frequent test iterations and constantly changing requirements, testers need to constantly adjust scripts to adapt to new version requirements. For example, adding a test to change the flashing state of an alarm indicator requires manually adding test logic and verification statements to multiple script files. Changes to signal definitions (such as name, period, and start bit) also require manual modification of the parsing and verification logic in the scripts, making it easy to omit or create logical inconsistencies. Summary of the Invention

[0004] In view of this, the embodiments of the present application provide a test script generation method, device, electronic device and storage medium, which greatly improve the efficiency and quality of script generation by structured processing of test input information into a parameter dictionary, precise matching of target templates and dynamic rendering.

[0005] The technical solution of the embodiment of the present application is implemented as follows: In a first aspect, an embodiment of the present application provides a test script generation method, the method comprising: Acquire test input information, perform structured processing on the test input information, and obtain a parameter dictionary; wherein the test input information includes requirement information and test data imported from the test system; Determining a target test template that matches the target feature based on the target feature; wherein the target feature is determined based on the test input information, and the target test template is constructed based on a template engine that matches a specific syntax; The parameter dictionary is bound to the target test template, and a test script file that complies with the test rules is dynamically rendered and generated.

[0006] In a second aspect, an embodiment of the present application further provides a test script generating device, the device comprising: An acquisition module, configured to acquire test input information, perform structured processing on the test input information, and obtain a parameter dictionary; wherein the test input information includes requirement information and test data imported from the test system; a determination module, configured to determine, based on a target feature, a target test template that matches the target feature; wherein the target feature is determined based on the test input information, and the target test template is constructed based on a template engine that matches a specific grammar; A generation module is used to bind the parameter dictionary with the target test template, dynamically render and generate a test script file that complies with the test rules.

[0007] In a third aspect, an embodiment of the present application further provides an electronic device comprising: a processor, a storage medium and a bus, wherein the storage medium stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the storage medium through the bus, and the processor executes the machine-readable instructions to execute the test script generation method described in any one of the first aspects.

[0008] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is run by a processor, the test script generation method described in any one of the first aspects is executed.

[0009] The embodiments of the present application have the following beneficial effects: First, the acquired test input information, which contains both requirement information and test data, is structured to generate a parameter dictionary. This process transforms the disorganized original information into an ordered, standardized data structure, greatly improving the manageability and usability of the information and laying a solid foundation for the subsequent accurate generation of test scripts. Secondly, the target features are determined based on the test input information, and accordingly matched to the target test template built based on a specific syntax template engine. This precise matching mechanism ensures that the generated test script can closely fit the test requirements and avoids the problem of mismatch between the script and the actual test scenario caused by improper template selection. Finally, the parameter dictionary is bound to the target test template and dynamically rendered to generate a test script file that conforms to the test rules, thus realizing the automated generation of test scripts. This not only greatly shortens the script writing cycle and improves testing efficiency, but also reduces the errors that may occur in manually written scripts, effectively improving the quality and accuracy of test scripts, and providing a strong guarantee for the efficient implementation of software testing work. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without creative work.

[0011] Figure 1 10 is a flow chart of steps S101-S103 provided in an embodiment of the present application; Figure 2 This is a block diagram of the test script generation principle provided by the embodiment of the present application; Figure 3 Schematic diagram of the process of steps S301-S302 provided in the embodiment of the present application; Figure 4 4 is a flow chart of steps S401-S402 provided in an embodiment of the present application; Figure 5 It is a flowchart of steps S501-S502 provided in an embodiment of the present application; Figure 6 Schematic diagram of the process of steps S601-S602 provided in an embodiment of the present application; Figure 7 This is a schematic diagram of the structure of the test script generation device provided in an embodiment of the present application; Figure 8 It is a schematic diagram of the composition structure of the electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0012] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. It should be understood that the drawings in the present application only serve the purpose of illustration and description and are not used to limit the scope of protection of the present application. In addition, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate the operations implemented according to some embodiments of the present application. It should be understood that the operations of the flowcharts can be implemented out of sequence, and steps without logical context can be reversed or implemented simultaneously. In addition, those skilled in the art, under the guidance of the contents of this application, can add one or more other operations to the flowchart, or remove one or more operations from the flowchart.

[0013] In the following description, reference is made to “some embodiments”, which describes a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0014] In addition, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. The components of the embodiments of the present application generally described and shown in the drawings here can be arranged and designed in various configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work are within the scope of protection of the present application.

[0015] In the following description, the terms "first\second\third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0016] It should be noted that the term "comprising" will be used in the embodiments of the present application to indicate the existence of the features declared thereafter, but does not exclude the addition of other features.

[0017] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application belongs. The terms used herein are for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0018] See also Figure 1 , Figure 1 This is a flow chart of steps S101-S103 of the test script generation method provided in the embodiment of the present application, which will be combined with Figure 1 Steps S101-S103 are shown for explanation.

[0019] In step S101 , test input information is acquired and structured to obtain a parameter dictionary; wherein the test input information includes requirement information and test data imported from a test system.

[0020] See Figure 2 , Figure 2 This is a block diagram of the test script generation principle provided by the embodiment of the present application, such as Figure 2As shown, test input information includes requirement information imported from the test system and test data. This information forms the basis for generating test scripts and covers key elements such as test objectives, conditions, and expected results. The system cleans, formats, and maps key values ​​to test input information, converting it into a standardized parameter dictionary. A parameter dictionary is a data structure used to store and organize various parameters required for testing, such as signal names, status values, trigger conditions, and expected results. This structured processing ensures data consistency and accessibility, providing a unified data interface for subsequent template rendering.

[0021] In step S102, a target test template matching the target feature is determined based on the target feature; wherein the target feature is determined based on the test input information, and the target test template is constructed based on a template engine matching a specific grammar.

[0022] Please continue to see Figure 2 Target features are determined based on test input information and are used to describe the specific test objectives and conditions. For example, target features can include test types (such as CAN message tests and signal linkage tests) and signal characteristics (such as signal name, period, and start bit). Target test templates are built based on a template engine that matches a specific syntax and are used to define the logical structure and content of test scripts. Templates contain variable placeholders, control statements (such as if and for), and comment structures, making script logic highly reusable and consistent across different scenarios.

[0023] In this application's examples, the Jinja2 template engine is primarily used, but other template engines (such as Mako and Mustache) are mentioned as alternatives. The system automatically selects the most suitable target test template from the template library based on the target characteristics. For example, to test the flashing state change of an alarm indicator light, the system might select a template that includes state monitoring and conditional judgment.

[0024] In step S103, the parameter dictionary is bound to the target test template, and a test script file that complies with the test rules is dynamically rendered and generated.

[0025] Please continue to see Figure 2, the system injects the specific parameter values ​​in the parameter dictionary into the variable placeholders of the target test template to realize dynamic replacement of data. In the embodiment of the present application, this process is called parameter binding. After that, the rendering function of the template engine is used to dynamically generate a test script file based on the bound template. The rendering process includes structured control operations such as logic processing, conditional judgment, and loop generation to adapt to complex and changeable test scenarios. The generated test script file complies with the test rules and can be executed directly on the test platform. The script format can be Python, CAPL, Shell, etc. to meet the needs of different platforms.

[0026] The above approach eliminates the need to manually write large amounts of repetitive code, significantly improving generation efficiency. Through parameterized and templated design, the method can flexibly adapt to the needs of different vehicle models and different test scenarios, supporting rapid iteration and change response. Structured processing and template rendering mechanisms ensure the consistency and accuracy of test scripts, reducing human errors and omissions. The decoupled design of templates and parameters enables high template reuse rates and low maintenance costs, facilitating team collaboration and standardization. It also supports multiple template engines, input methods, output formats, and execution mechanisms, facilitating integration with existing test management platforms and continuous integration systems.

[0027] In some embodiments, see Figure 3 , Figure 3 It is a flow chart of steps S301-S302 provided in an embodiment of the present application. The method also includes steps S301-S302, which will be described in combination with each step.

[0028] In step S301 , in response to a change in the test input information, difference information is determined based on the changed test input information.

[0029] Here, during the actual testing process, test requirements or test data may change, such as adding new test cases, modifying signal definitions, adjusting test conditions, etc. These changes may come from updating the requirements document, modifying the DBC file, or adjusting the test strategy.

[0030] The system monitors changes in test input information in real time or periodically. Once a change is detected, it compares and analyzes the test input information before and after the change to determine the specific differences. Differences may include newly added parameters, modified parameter values, deleted parameters, etc.

[0031] For example, suppose the original test input includes a test case for a speed sensor, specifying that the sensor should output speed values ​​within a specific range under certain conditions. Later, a requirement change requires adjusting the speed range. Upon detecting this change, the system identifies the discrepancy as a modification of the speed range.

[0032] In step S302, based on the difference information, determine whether the target test template needs to be updated. If not, reload the changed test input information and the target test template, and render the affected content to be updated; if so, reload the changed test input information and the updated target test template, and render the affected content to be updated.

[0033] Here, the system analyzes the impact of the change on the target test template based on the difference information and determines whether the template needs to be updated. If the change only involves adjusting parameter values ​​and does not affect the template's logical structure or control flow, then no template update is required. However, if the change requires modification of the template logic (such as adding conditionals or loop structures), then a template update is required.

[0034] For example, continuing with the speed sensor example above, if the only difference is a change in the speed range, and the logical structure in the template (such as initialization, sending commands, and verifying results) remains unchanged, then there is no need to update the template. However, if the requirement change requires additional logic for detecting and handling sensor fault conditions, the template needs to be updated to include this new logic.

[0035] When processing changes, there are two situations: Case 1: No need to update the target test template.

[0036] The system reloads the modified test input information (e.g., the modified speed range) into the system, leaving the target test template unchanged because the template logic is unaffected by the change. The system injects the modified parameter values ​​into the template, re-renders the affected sections (e.g., the speed value validation statement), and generates the new test script content.

[0037] Case 2: The target test template needs to be updated.

[0038] Similarly, the system first loads the changed test input information, loads the updated target test template from the template library or edits it on-site to ensure that the template logic is consistent with the latest requirements, and injects the changed parameter values ​​into the updated template, re-rendering all affected parts to generate a test script that fully meets the latest requirements.

[0039] The above method can quickly respond to changes in test input information by automatically detecting differences and determining the need for template updates, reducing manual intervention and response time. Without the need to update the template, only the parameters need to be reloaded and the affected parts need to be rendered, significantly reducing maintenance costs and workload.

[0040] In some embodiments, see Figure 4 , Figure 4This is a flow chart of steps S401-S402 provided in an embodiment of the present application, which will be explained in conjunction with each step.

[0041] In step S401, the task to be tested is tested based on the test script file, and a test log is recorded.

[0042] Here, the system loads the generated test script file (such as Python, CAPL, or Shell script) into the test execution environment (such as CANoe, Python interpreter, or test framework). The test is initiated according to the test plan or manual instructions, and the script automatically executes the preset test logic, including sending test signals, simulating input conditions, and verifying output results. During the test, the system continuously monitors the response of the task under test (such as ECU functions and system interactions) and records key events and state changes. For example: Record the entire life cycle of the test execution, including: Timestamp: The time when the event occurred with millisecond accuracy.

[0043] Test step: The script line number or function module currently being executed.

[0044] Input / output data: sent test signal value, received response data.

[0045] State change: The state transition of the task under test (such as from "initialization" to "running").

[0046] Error information: Error details such as script execution exception, communication interruption, verification failure, etc.

[0047] Log format: Use a structured format (such as JSON, XML) or standardized text format to facilitate subsequent parsing.

[0048] Storage method: Save logs to a database, file system, or cloud storage, and support retrieval by test task, time range, or error type.

[0049] In step S402, the test log is analyzed and processed, and problem location feedback is performed based on the analysis result.

[0050] Here, test log analysis and processing include filtering out invalid logs (such as duplicate records and debug information) and extracting key fields (such as error codes and timestamps). Combining the test script logic with the design documentation of the task under test, the root cause of the problem can be inferred. For example, hardware failure: sensor signal loss; software defect: algorithm logic error leading to verification failure; configuration error: parameter setting outside the valid range. Finally, a visual report (such as HTML or PDF) or real-time notification (such as email or instant message) is generated.

[0051] The above method reduces manual operation and recording time, intelligent analysis quickly locates problems, shortens the debugging cycle, and structured logs and pattern recognition technology improve the problem reproduction rate and location accuracy.

[0052] In some embodiments, the template engine includes at least one of a Jinja2 template engine, a Mako template engine, a Mustache template engine, a Handlebars template engine, a Java Velocity template engine, a Freemarker template engine, and a custom rule engine.

[0053] Here, the template engine is a key tool for connecting test input information (such as parameters and logic rules) with the target test template. Its core functions include: Dynamic rendering: Replace placeholders, conditional statements, or loop structures in the template with actual test data to generate executable test scripts.

[0054] Logic separation: Decouple test logic (template) from test data (input information) to facilitate maintenance and reuse.

[0055] Multi-format support: Supports generating test scripts in different languages ​​or formats (such as Python, CAPL, XML, JSON, etc.

[0056] The template engines provided in the embodiments of the present application can be divided into two categories: mainstream open source engines and custom rule engines. For mainstream open source template engines, please see Table 1.

[0057] Table 1

[0058] A custom rule engine is a specialized template engine developed based on specific business requirements or technology stacks. It may include the following features: Domain Specific Language (DSL): Design a syntax that conforms to the terminology of the test domain (e.g. @TestStep("Send CAN signal")).

[0059] Integration constraints: Enforce test specifications (such as parameter naming rules, signal value range checks).

[0060] Performance optimization: Optimize rendering speed for high-frequency test scenarios (such as real-time signal processing).

[0061] Applicable scenarios: Existing open source engines cannot meet special needs (such as specific protocol formats and compliance requirements).

[0062] This approach supports multi-language test script generation, covering mainstream technology stacks like Python, Java, and JavaScript, and is compatible with various testing frameworks (such as pytest, JUnit, and Mocha), reducing integration costs. Developers can choose the most appropriate engine based on their needs, balancing functionality and performance. Custom engines can also be extended to support enterprise-specific specifications or protocols.

[0063] In some embodiments, see Figure 5 , Figure 5 This is a flow chart of steps S501-S502 provided in an embodiment of the present application. The test input information is managed and maintained through steps S501-S502, and each step is explained in conjunction with the steps.

[0064] In step S501, the test input information is structured based on the Python pandas library, and the test requirements are described based on the YAML / JSON structure configuration file; wherein the test input information is an Excel or Google Sheets file.

[0065] Here, test input information is stored as Excel or Google Sheets files, containing structured data such as test parameters, use case steps, and expected results. The Python pandas library is used to read, clean, and transform the data, ultimately generating structured Python data objects (such as dictionaries and lists) for direct use by subsequent template engines or test frameworks.

[0066] In step S502, function items are extracted from the text based on the natural language parsing engine NLP, and the requirement data corresponding to the function items are associated with the test management component.

[0067] As an example, consider unstructured text extracted from requirement documents, user stories, or emails, such as: "The system should trigger a speeding alarm and log when the vehicle speed exceeds 120 km / h."

[0068] In the NLP processing step, word segmentation and part-of-speech tagging are first performed to identify nouns (e.g., "vehicle speed," "speeding alarm"), verbs (e.g., "trigger," "record"), and values ​​(e.g., "120 km / h"). Key entities are then extracted (e.g., "vehicle speed" as a signal, "speeding alarm" as a function, and "120 km / h" as a threshold). The logical relationships between these entities are then analyzed (e.g., "vehicle speed > 120" triggers an "alarm"). Ultimately, the text's intent can be determined (e.g., "functional verification," "boundary testing").

[0069] Test management components include test case repositories, defect tracking systems (such as Jira), and test planning tools (such as TestRail). Associations can be automated, matching test case parameters to entities in function items (such as signal names) or creating new test cases based on intent. Alternatively, a tagging system can be used to add unified tags (such as "Function ID: F001") to function items and test cases, enabling bidirectional search. Alternatively, API integration can be used to import function items directly into the test management tool via a REST API, generating tasks to be executed.

[0070] In the above approach, pandas automates the cleaning and conversion of Excel / Google Sheets, reducing manual errors. YAML / JSON configuration files support version control (such as Git), facilitating requirement change tracking. The NLP engine directly converts natural language requirements into executable tests, shortening the cycle from requirements to testing. The association of functional items with test components ensures traceability of requirement coverage and improves test integrity.

[0071] In some embodiments, the method further comprises: Determining the target type of the test script file based on test platform requirements; Converting the test script file to obtain a test script file of the target type. Alternatively, directly dynamically render and generate a test script file of the target type; Alternatively, generate test data through the test management tool interface and write it directly to the test platform; The target types include Python scripts, CANOE CAPL scripts, Shell scripts, Bat scripts, JSON or XML configuration scripts used as middleware input, LUA scripts, Robot Framework test statements, and C++ GTest templates.

[0072] Here, the target type refers to the script language or configuration format that the test script ultimately needs to adapt to, including but not limited to: Common programming languages: Python, Shell, Bat, C++ (GTest template).

[0073] Dedicated test scripts: CANoe CAPL (automotive electronic communication test), LUA (game / embedded script).

[0074] Automated testing framework: Robot Framework (keyword-driven), Robot Framework test statements (YAML / TXT format).

[0075] Middleware configuration: JSON / XML (such as Kafka and MQTT message configuration).

[0076] Requirements inputs include the test platform's technical specifications, interface protocols (such as the CAN bus specification), and automation framework requirements (such as the script types supported by Jenkins). Requirements can be determined by parsing platform constraints and extracting key fields (such as "only CAPL scripts supported" and "JSON format input required"). Alternatively, target types can be selected based on a predefined type mapping table (see Table 1). Unlisted types (such as custom DSLs) can also be added through plugins or configuration files.

[0077] In some embodiments, the test script generation method is triggered by at least one of the following methods: Connect with the continuous integration platform and automatically trigger after code push or requirement update; Alternatively, generate a request and trigger based on the Flask / Django Web UI submission; Alternatively, a scheduled task can be used to periodically scan for demand updates and trigger them; Alternatively, use a Kafka message queue to listen for task trigger requests.

[0078] This embodiment of the application provides the following four starting scenarios for script generation: When developers push new code to a code repository (such as GitLab or GitHub), test scripts are automatically generated to verify the impact of the changes.

[0079] Alternatively, testers need to quickly generate scripts for specific scenarios (such as regression testing and performance testing) without waiting for code changes. In this case, they can submit script generation parameters (such as test environment, data range, and timeout period) through a web form.

[0080] Alternatively, during periodic testing and maintenance, for example, scanning the requirements system at dawn every day to generate scripts corresponding to the next day's test plan; you can also regularly check requirements that are not associated with test scripts and automatically trigger completion generation.

[0081] Alternatively, in high-concurrency processing scenarios, parallel processing of generation requests can be achieved through Kafka partitioning.

[0082] The above approach builds a flexible and reliable test script generation trigger system. This solution, through four complementary trigger paths (continuous integration linkage, web interaction triggering, scheduled task scanning, and message queue monitoring), covers the entire lifecycle, from code changes to requirement updates. It supports diverse triggering requirements, including manual and automatic, immediate and asynchronous, centralized and distributed, significantly improving the timeliness and controllability of test script generation.

[0083] In some embodiments, see Figure 6 , Figure 6 It is a flow chart of steps S601-S602 provided in an embodiment of the present application. The method also includes steps S601-S602, which will be described in combination with each step.

[0084] In step S601, the test script file is saved in a unified directory structure.

[0085] In step S602, the test script file is managed based on a version control tool.

[0086] Here, saving the test script files in a unified directory structure can eliminate the script storage confusion caused by differences in team habits, reduce the learning cost of new members, and quickly associate scripts with test objects (such as modules, functions, and environments) through directory hierarchies, thereby improving maintenance efficiency and providing a unified input path for subsequent CI / CD processes (such as script execution and report generation).

[0087] This approach aligns the script's physical location with its logical hierarchy, allowing you to locate the target script quickly. The environment isolation design prevents script execution failures due to configuration differences, improving test stability.

[0088] In some embodiments, the test script file is alternatively managed by at least one of the following methods: Manage metadata of script content, version and status through database; Use the enterprise testing platform to connect and trace script use cases; Use object storage to uniformly store scripts and bind metadata tags; Use DevOps tools to archive and deploy script components.

[0089] Here, the embodiments of the present application provide four independent or combined technical solutions to achieve flexibility, scalability and full life cycle coverage of script management through different technology stacks.

[0090] Solution 1: Use a database to manage metadata for script content, version, and status. Separate script metadata (not the script itself) from the script file, enabling structured querying and efficient metadata management. Quickly locate scripts by script type, creation time, author, associated modules, and other criteria.

[0091] Solution 2: Use the enterprise testing platform to link scripts and test cases for traceability. Bind scripts to test cases to achieve full traceability from script to test case to requirement. Centrally manage scripts through a web interface, supporting test plan development, execution result feedback, and defect association. Connect with the CI / CD tool chain to trigger script execution and generate visual reports.

[0092] Solution 3: Use object storage to centrally store scripts and bind metadata tags. Script files are centrally stored in object storage, eliminating the need for local storage or version control systems. Metadata tags (such as environment:test and module:auth) enable flexible classification and retrieval of scripts. Object storage provides global low-latency access and supports fast access to large scripts.

[0093] Solution 4: Use DevOps tools to archive and manage script artifacts. Package scripts into deployable artifacts (such as Docker images and JAR packages) to achieve standardized delivery. Automatically deploy scripts to the test environment through the DevOps pipeline, reducing manual operations.

[0094] The above four solutions can be used independently or in combination to adapt to testing needs of different scales and complexities. From metadata management to deployment automation, they cover the entire script lifecycle and reduce manual operation and communication costs through centralization, platformization and automation.

[0095] In summary, the embodiments of the present application have the following beneficial effects: In terms of test script generation efficiency, the test input information is obtained and structured to obtain a parameter dictionary, and then the target test template is matched based on the target features and dynamically rendered to generate a test script file. This process is highly automated, avoiding the tedious and time-consuming traditional manual script writing, greatly improving the script generation speed and enabling the test team to devote themselves to testing work more quickly.

[0096] In terms of adaptability and flexibility, when test input information changes, it can determine whether to update the target test template based on the difference information and perform targeted rendering processing on the affected content, ensuring that the test script always matches the latest requirements, effectively responding to project scenarios with frequently changing requirements. Furthermore, it supports multiple template engines, allowing flexible selection based on different project characteristics to meet diverse testing needs.

[0097] For the management and maintenance of test input information, we use tools such as Python's pandas library, YAML / JSON structure configuration files, and natural language parsing engine NLP to achieve efficient structured processing of information and accurate extraction and association of functional items, improving the quality and usability of test input information and laying the foundation for generating high-quality test scripts.

[0098] Regarding test script output and application, not only can test script files of various target types be generated based on the test platform's requirements, but test script generation can also be triggered in a variety of ways, such as automatic triggering through integration with a continuous integration platform or triggering through request submission via the Web UI, allowing different teams to choose the appropriate method based on their workflows. Furthermore, a rich set of script management methods is provided, including unified directory storage, version control tool management, database metadata management, and traceability management for enterprise test platform connections. This ensures the maintainability and traceability of test scripts, providing strong support for the standardization of the entire testing process, ultimately effectively improving the quality and efficiency of software testing and reducing testing costs.

[0099] Based on the same inventive concept, the embodiment of the present application also provides a test script generation device corresponding to the test script generation method in the first embodiment. Since the principle of solving the problem by the device in the embodiment of the present application is similar to the above-mentioned test script generation method, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be repeated.

[0100] like Figure 7 As shown, Figure 7 : is a schematic diagram of the structure of a test script generation device 700 provided in an embodiment of the present application. The test script generation device 700 includes: The acquisition module 701 is used to acquire test input information, perform structured processing on the test input information, and obtain a parameter dictionary; wherein the test input information includes requirement information and test data imported from the test system; A determination module 702 is configured to determine a target test template that matches the target feature based on the target feature; wherein the target feature is determined based on the test input information, and the target test template is constructed based on a template engine that matches a specific grammar; The generating module 703 is used to bind the parameter dictionary with the target test template, dynamically render and generate a test script file that complies with the test rules.

[0101] It should be understood by those skilled in the art that Figure 7 The implementation functions of each unit in the test script generating apparatus 700 shown can be understood by referring to the relevant description of the aforementioned test script generating method. Figure 7The functions of the various units in the test script generating apparatus 700 shown may be implemented by a program running on a processor, or may be implemented by a specific logic circuit.

[0102] In a possible implementation, the generating module 703 further includes: In response to a change in the test input information, determining difference information based on the changed test input information; Based on the difference information, determine whether the target test template needs to be updated. If not, reload the changed test input information and the target test template, and render the affected content to be updated; if so, reload the changed test input information and the updated target test template, and render the affected content to be updated.

[0103] In a possible implementation, the generating module 703 further includes: Testing the task to be tested based on the test script file and recording the test log; The test log is analyzed and processed, and problem location feedback is provided based on the analysis results.

[0104] In a possible implementation, the template engine includes at least one of a Jinja2 template engine, a Mako template engine, a Mustache template engine, a Handlebars template engine, a Java Velocity template engine, a Freemarker template engine, and a custom rule engine.

[0105] In one possible implementation, the test input information is managed and maintained in the following manner: The test input information is structured based on the Python pandas library, and the test requirements are described based on a YAML / JSON structure configuration file; wherein the test input information is an Excel or Google Sheets file; Based on the natural language parsing engine NLP, functional items are extracted from the text, and the requirement data corresponding to the functional items are associated with the test management component.

[0106] In a possible implementation, the generating module 703 further includes: Determining the target type of the test script file based on test platform requirements; Converting the test script file to obtain a test script file of the target type. Alternatively, directly dynamically render and generate a test script file of the target type; Alternatively, generate test data through the test management tool interface and write it directly to the test platform; The target types include Python scripts, CANOE CAPL scripts, Shell scripts, Bat scripts, JSON or XML configuration scripts used as middleware input, LUA scripts, Robot Framework test statements, and C++ GTest templates.

[0107] In a possible implementation, the generation module 703 triggers the test script generation method in at least one of the following ways: Connect with the continuous integration platform and automatically trigger after code push or requirement update; Alternatively, generate a request and trigger based on the Flask / Django Web UI submission; Alternatively, a scheduled task can be used to periodically scan for demand updates and trigger them; Alternatively, use a Kafka message queue to listen for task trigger requests.

[0108] In a possible implementation, the generating module 703 further includes: Save the test script file to a unified directory structure; The test script file is managed based on a version control tool.

[0109] In a possible implementation, the test script file is alternatively managed by at least one of the following methods: Manage metadata of script content, version and status through database; Use the enterprise testing platform to connect and trace script use cases; Use object storage to uniformly store scripts and bind metadata tags; Use DevOps tools to archive and deploy script components.

[0110] The above test script generation device has the following beneficial effects: In terms of test script generation efficiency, the test input information is obtained and structured to obtain a parameter dictionary, and then the target test template is matched based on the target features and dynamically rendered to generate a test script file. This process is highly automated, avoiding the tedious and time-consuming traditional manual script writing, greatly improving the script generation speed and enabling the test team to devote themselves to testing work more quickly.

[0111] In terms of adaptability and flexibility, when test input information changes, it can determine whether to update the target test template based on the difference information and perform targeted rendering processing on the affected content, ensuring that the test script always matches the latest requirements, effectively responding to project scenarios with frequently changing requirements. Furthermore, it supports multiple template engines, allowing flexible selection based on different project characteristics to meet diverse testing needs.

[0112] For the management and maintenance of test input information, we use tools such as Python's pandas library, YAML / JSON structure configuration files, and natural language parsing engine NLP to achieve efficient structured processing of information and accurate extraction and association of functional items, improving the quality and usability of test input information and laying the foundation for generating high-quality test scripts.

[0113] Regarding test script output and application, not only can test script files of various target types be generated based on the test platform's requirements, but test script generation can also be triggered in a variety of ways, such as automatic triggering through integration with a continuous integration platform or triggering through request submission via the Web UI, allowing different teams to choose the appropriate method based on their workflows. Furthermore, a rich set of script management methods is provided, including unified directory storage, version control tool management, database metadata management, and traceability management for enterprise test platform connections. This ensures the maintainability and traceability of test scripts, providing strong support for the standardization of the entire testing process, ultimately effectively improving the quality and efficiency of software testing and reducing testing costs.

[0114] like Figure 8 As shown, Figure 8 This is a schematic diagram of the structure of an electronic device 800 provided in an embodiment of the present application. The electronic device 800 includes: A processor 801, a storage medium 802 and a bus 803, wherein the storage medium 802 stores machine-readable instructions executable by the processor 801. When the electronic device 800 is running, the processor 801 communicates with the storage medium 802 via the bus 803, and the processor 801 executes the machine-readable instructions to perform the steps of the test script generation method described in the embodiment of the present application.

[0115] In actual application, the various components in the electronic device 800 are coupled together via a bus 803. It is understood that the bus 803 is used to achieve connection and communication between these components. In addition to the data bus, the bus 803 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, Figure 8 Various buses are labeled as bus 803.

[0116] The electronic device has the following beneficial effects: In terms of test script generation efficiency, the test input information is obtained and structured to obtain a parameter dictionary, and then the target test template is matched based on the target features and dynamically rendered to generate a test script file. This process is highly automated, avoiding the tedious and time-consuming traditional manual script writing, greatly improving the script generation speed and enabling the test team to devote themselves to testing work more quickly.

[0117] In terms of adaptability and flexibility, when test input information changes, it can determine whether to update the target test template based on the difference information and perform targeted rendering processing on the affected content, ensuring that the test script always matches the latest requirements, effectively responding to project scenarios with frequently changing requirements. Furthermore, it supports multiple template engines, allowing flexible selection based on different project characteristics to meet diverse testing needs.

[0118] For the management and maintenance of test input information, we use tools such as Python's pandas library, YAML / JSON structure configuration files, and natural language parsing engine NLP to achieve efficient structured processing of information and accurate extraction and association of functional items, improving the quality and usability of test input information and laying the foundation for generating high-quality test scripts.

[0119] Regarding test script output and application, not only can test script files of various target types be generated based on the test platform's requirements, but test script generation can also be triggered in a variety of ways, such as automatic triggering through integration with a continuous integration platform or triggering through request submission via the Web UI, allowing different teams to choose the appropriate method based on their workflows. Furthermore, a rich set of script management methods is provided, including unified directory storage, version control tool management, database metadata management, and traceability management for enterprise test platform connections. This ensures the maintainability and traceability of test scripts, providing strong support for the standardization of the entire testing process, ultimately effectively improving the quality and efficiency of software testing and reducing testing costs.

[0120] The embodiment of the present application further provides a computer-readable storage medium, which stores executable instructions. When the executable instructions are executed by at least one processor 801, the test script generation method described in the embodiment of the present application is implemented.

[0121] In some embodiments, the storage medium can be a magnetic random access memory (FRAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a flash memory, a magnetic surface storage, an optical disc, or a compact disc read-only memory (CD-ROM); it can also be various devices including one or any combination of the above memories.

[0122] In some embodiments, executable instructions may be in the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0123] As an example, executable instructions may, but do not necessarily, correspond to a file in a file system, may be stored as part of a file that stores other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files (for example, files storing one or more modules, subroutines, or code portions).

[0124] By way of example, executable instructions may be deployed to be executed on one computing device, or on multiple computing devices at one site, or on multiple computing devices distributed across multiple sites and interconnected by a communication network.

[0125] The computer-readable storage medium has the following advantages: In terms of test script generation efficiency, the test input information is obtained and structured to obtain a parameter dictionary, and then the target test template is matched based on the target features and dynamically rendered to generate a test script file. This process is highly automated, avoiding the tedious and time-consuming traditional manual script writing, greatly improving the script generation speed and enabling the test team to devote themselves to testing work more quickly.

[0126] In terms of adaptability and flexibility, when test input information changes, it can determine whether to update the target test template based on the difference information and perform targeted rendering processing on the affected content, ensuring that the test script always matches the latest requirements, effectively responding to project scenarios with frequently changing requirements. Furthermore, it supports multiple template engines, allowing flexible selection based on different project characteristics to meet diverse testing needs.

[0127] For the management and maintenance of test input information, we use tools such as Python's pandas library, YAML / JSON structure configuration files, and natural language parsing engine NLP to achieve efficient structured processing of information and accurate extraction and association of functional items, improving the quality and usability of test input information and laying the foundation for generating high-quality test scripts.

[0128] Regarding test script output and application, not only can test script files of various target types be generated based on the test platform's requirements, but test script generation can also be triggered in a variety of ways, such as automatic triggering through integration with a continuous integration platform or triggering through request submission via the Web UI, allowing different teams to choose the appropriate method based on their workflows. Furthermore, a rich set of script management methods is provided, including unified directory storage, version control tool management, database metadata management, and traceability management for enterprise test platform connections. This ensures the maintainability and traceability of test scripts, providing strong support for the standardization of the entire testing process, ultimately effectively improving the quality and efficiency of software testing and reducing testing costs.

[0129] In the several embodiments provided in this application, it should be understood that the disclosed methods and electronic devices can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

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

[0131] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0132] If the functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, or the portion that contributes to the prior art, or the portion 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 for enabling a computer device (which can be a personal computer, platform server, or network device, etc.) to execute all or part of the steps of the methods described in various embodiments of this application. The aforementioned storage media include various media that can store program code, such as USB flash drives, mobile hard drives, ROM, RAM, magnetic disks, or optical disks.

[0133] The above are only specific embodiments of the present application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A test script generation method, characterized in that: The method comprises: Acquire test input information, perform structured processing on the test input information, and obtain a parameter dictionary; wherein the test input information includes requirement information and test data imported from the test system; Determining a target test template that matches the target feature based on the target feature; wherein the target feature is determined based on the test input information, and the target test template is constructed based on a template engine that matches a specific syntax; The parameter dictionary is bound to the target test template, and a test script file that complies with the test rules is dynamically rendered and generated.

2. The method according to claim 1, characterized in that The method further comprises: In response to a change in the test input information, determining difference information based on the changed test input information; Based on the difference information, determine whether the target test template needs to be updated. If not, reload the changed test input information and the target test template, and render the affected content to be updated; if so, reload the changed test input information and the updated target test template, and render the affected content to be updated.

3. The method according to claim 1, characterized in that The method further comprises: Testing the task to be tested based on the test script file and recording the test log; The test log is analyzed and processed, and problem location feedback is provided based on the analysis results.

4. The method according to claim 1, wherein The template engine includes at least one of a Jinja2 template engine, a Mako template engine, a Mustache template engine, a Handlebars template engine, a Java Velocity template engine, a Freemarker template engine, and a custom rule engine.

5. The method according to claim 1, characterized in that The test input information is managed and maintained in the following ways: The test input information is structured based on the Python pandas library, and the test requirements are described based on a YAML / JSON structure configuration file; wherein the test input information is an Excel or Google Sheets file; Based on the natural language parsing engine NLP, functional items are extracted from the text, and the requirement data corresponding to the functional items are associated with the test management component.

6. The method according to claim 1, characterized in that The method further comprises: Determining the target type of the test script file based on test platform requirements; Converting the test script file to obtain a test script file of the target type. Alternatively, directly dynamically render and generate a test script file of the target type; Alternatively, generate test data through the test management tool interface and write it directly to the test platform; The target types include Python scripts, CANOE CAPL scripts, Shell scripts, Bat scripts, JSON or XML configuration scripts used as middleware input, LUA scripts, Robot Framework test statements, and C++ GTest templates.

7. The method according to claim 1, characterized in that The test script generation method is triggered by at least one of the following methods: Connect with the continuous integration platform and automatically trigger after code push or requirement update; Alternatively, generate a request and trigger based on the Flask / Django Web UI submission; Alternatively, a scheduled task can be used to periodically scan for demand updates and trigger them; Alternatively, use a Kafka message queue to listen for task trigger requests.

8. The method according to claim 1, characterized in that The method further comprises: Save the test script file to a unified directory structure; The test script file is managed based on a version control tool.

9. The method according to claim 1, characterized in that The test script file is alternatively managed by at least one of the following methods: Manage metadata of script content, version and status through database; Use the enterprise testing platform to connect and trace script use cases; Use object storage to uniformly store scripts and bind metadata tags; Use DevOps tools to archive and deploy script components.

10. A test script generating device, characterized in that: The device comprises: An acquisition module, configured to acquire test input information, perform structured processing on the test input information, and obtain a parameter dictionary; wherein the test input information includes requirement information and test data imported from the test system; a determination module, configured to determine, based on a target feature, a target test template that matches the target feature; wherein the target feature is determined based on the test input information, and the target test template is constructed based on a template engine that matches a specific grammar; A generation module is used to bind the parameter dictionary with the target test template, dynamically render and generate a test script file that complies with the test rules.

Images