A method and apparatus for supporting automated testing of parallel mesh generation software
By employing a collaborative architecture of master nodes, build nodes, and parallel test nodes, combined with structured configuration parameter files, the problems of inflexible node scheduling and low resource utilization in grid generation testing are solved. This enables efficient automated test process management and data management, thereby improving testing efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- ZHEJIANG UNIV
- Filing Date
- 2025-05-22
- Publication Date
- 2026-07-17
AI Technical Summary
Existing technologies suffer from problems such as inflexible node scheduling, low resource utilization, excessive manual intervention, and improper data management in grid generation testing for large-scale data processing and complex modeling verification, resulting in low testing efficiency.
It adopts a three-node collaborative architecture consisting of a master node, a build node, and a parallel test node. It uses structured configuration parameter files to uniformly define and drive the compilation, testing, and analysis processes, thereby achieving efficient automated test process management.
It improves the automation of the testing process, enhances resource utilization and overall execution efficiency, reduces manual intervention, and ensures efficient management of test data and report generation.
Smart Images

Figure CN120540987B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of software testing and quality analysis technology, and in particular to a method and apparatus for supporting automated testing of software with parallel mesh generation. Background Technology
[0002] In the field of software testing and automated verification, with the expansion of system scale and the increase in application complexity, traditional serial testing and verification processes can no longer meet the needs for efficient and accurate testing. Especially in scenarios requiring large-scale data processing, complex modeling verification, and mesh generation testing, the serial execution mode suffers from long execution cycles, low resource utilization, and high error rates, which seriously restricts the efficiency of software system development and delivery.
[0003] To improve testing efficiency, some testing systems have begun to introduce automated build and test processes, coupled with a certain degree of parallel scheduling. However, existing technologies still have the following problems in practical applications:
[0004] (1) Lack of a flexible and scalable node scheduling system. In the existing automated testing framework, the node deployment method is fixed and the scheduling granularity is coarse. It is difficult to allocate nodes according to different task types (such as compilation tasks, testing tasks, and quality analysis tasks), resulting in insufficient resource utilization and serious task congestion.
[0005] (2) Limited automation in compilation and testing processes. Traditional systems often rely on a large number of manual scripts for maintenance and configuration file management when performing compilation, testing and quality analysis. They lack unified and structured parameter configuration standards, which can easily lead to configuration errors, increase maintenance costs, and reduce the overall automation level of the process.
[0006] (3) Lack of efficient artifact management and transfer mechanism during parallel execution. During testing, artifacts and test input data usually need to be transferred and managed between different nodes. Existing methods lack a systematic mechanism for artifact distribution, persistence, and archiving, which leads to frequent problems such as data redundancy, transmission delay, and artifact loss, further reducing the overall testing efficiency.
[0007] (4) The mesh testing and quality analysis stages are separated and require a lot of manual intervention. In the testing process involving mesh structure generation and analysis, existing systems often require manual intervention to complete the extraction, analysis and report generation of the test product mesh. There is a lack of an integrated processing mechanism from testing to quality assessment, which increases labor costs and the probability of errors.
[0008] Therefore, there is an urgent need for a testing method that supports parallel processing, automates the entire process of building, testing, and quality analysis, and has the ability to efficiently manage artifacts and generate reports, so as to improve the automation level, resource utilization and overall execution efficiency of system testing and meet the actual needs of rapid delivery of large-scale and complex systems. Summary of the Invention
[0009] In view of this, embodiments of the present invention provide a method and apparatus for supporting automated testing of parallel mesh generation software, in order to solve the problems existing in the background art.
[0010] According to a first aspect of the embodiments of this application, a method for supporting automated testing of parallel mesh generation software is provided, comprising:
[0011] Deploy master nodes, build nodes, and parallel test nodes, establish connections between nodes, and generate a schedulable test infrastructure environment;
[0012] Based on the aforementioned test environment, obtain the structured configuration parameter files required for compilation tasks, test tasks, and quality analysis;
[0013] According to the structured configuration parameter file, when the master node detects a preset event, it distributes the compilation task to the build node to generate the build artifact;
[0014] According to the structured configuration parameter file, after the compilation task is completed, the build artifacts are distributed to the parallel test nodes;
[0015] According to the structured configuration parameter file, test tasks are performed on the built product on the parallel test node to generate a test product mesh;
[0016] Based on the structured configuration parameter file, perform quality analysis on the test product mesh and generate a corresponding test report.
[0017] According to a second aspect of the embodiments of this application, an apparatus for supporting automated testing of parallel mesh generation software is provided, comprising:
[0018] The master node is used to listen for preset events, parse structured configuration parameter files, and distribute compilation tasks to build nodes; it receives build artifact information returned by build nodes and distributes build artifacts and test tasks to parallel test nodes; it receives test artifact meshes and quality analysis reports returned by parallel test nodes, realizing unified scheduling and coordination control of the entire automated testing process.
[0019] The build node is used to receive compilation tasks distributed by the master node, perform compilation operations according to the structured configuration parameter file, generate build artifacts, and return the build artifacts to the master node;
[0020] Parallel test nodes are used to receive test tasks and build artifacts distributed by the master node, execute test operations according to the structured configuration parameter file, generate test artifact grids, perform quality analysis, and feed the results back to the master node;
[0021] The three nodes communicate with each other to generate a schedulable test environment and enable collaborative execution and data exchange of each stage of the test in a local area network or virtual network.
[0022] The technical solutions provided by the embodiments of this application may include the following beneficial effects:
[0023] As can be seen from the above embodiments, this application overcomes the problems of chaotic node collaboration, lack of unified scheduling of task execution, and low efficiency of test data flow in the traditional grid generation software testing process by adopting a three-node collaborative architecture based on the master control node, the build node, and the parallel test node, and by uniformly defining and driving the compilation, testing, and analysis processes through structured configuration parameter files. In this way, it achieves the technical effect of highly automated testing process, clear task scheduling logic, and full traceability of build and test products.
[0024] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description
[0025] 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.
[0026] Figure 1 A flowchart illustrating a method for automated testing of parallel mesh generation software, provided as an embodiment of this application.
[0027] Figure 2 This is a system architecture diagram illustrating the master control node, build node, parallel test node, and their communication relationships, provided for embodiments of this application.
[0028] Figure 3 This is a schematic diagram of a container management platform provided in an embodiment of this application.
[0029] Figure 4 This is a schematic diagram of a task triggering event provided in an embodiment of this application.
[0030] Figure 5 This is a state diagram of the build node and parallel test node provided in the embodiments of this application.
[0031] Figure 6 This is a schematic diagram of the virtual network configuration of the master control node provided in the embodiments of this application.
[0032] Figure 7 This is a schematic diagram of the virtual network configuration for building nodes provided in an embodiment of this application.
[0033] Figure 8 This is a schematic diagram showing the connection between the construction node and the master control node via a virtual network, as provided in the embodiments of this application.
[0034] Figure 9 This is a schematic diagram of the virtual network configuration for the test node provided in an embodiment of this application.
[0035] Figure 10 This is a schematic diagram showing the test node connected to the master node and the construction node via a virtual network, as provided in the embodiments of this application.
[0036] Figure 11 This is a schematic diagram of the structured configuration parameter file for the construction phase provided in an embodiment of this application.
[0037] Figure 12 A flowchart of the compilation script for calling the structured configuration parameter file during the build phase, provided in an embodiment of this application.
[0038] Figure 13 This is a schematic diagram of the product information configuration and product catalog provided in the embodiments of this application.
[0039] Figure 14 This is a schematic diagram of the structured configuration parameter file for the parallel testing phase provided in an embodiment of this application.
[0040] Figure 15 A flowchart of the test script for calling the structured configuration parameter file during the parallel testing phase provided in this application embodiment.
[0041] Figure 16 This is a schematic diagram of a structured configuration parameter file for the quality analysis stage provided in an embodiment of this application.
[0042] Figure 17 The flowchart of the master node monitoring and construction node response provided in the embodiments of this application is shown.
[0043] Figure 18 The compilation task definition diagram in the structured configuration file provided in the embodiments of this application.
[0044] Figure 19 This is a schematic diagram illustrating the process of executing compilation tasks for the build node provided in the embodiments of this application.
[0045] Figure 20 This is a schematic diagram illustrating the process of persistent storage of construction artifacts and recording of metadata provided in an embodiment of this application.
[0046] Figure 21This is a schematic diagram illustrating the process of a parallel test node executing a build product test task and generating a test product mesh, as provided in the embodiments of this application.
[0047] Figure 22 A screenshot of SFTP mounting a local disk provided in an embodiment of this application.
[0048] Figure 23 This is a schematic diagram of the VTK format test product mesh generated and persistently saved by the parallel test nodes provided in the embodiments of this application.
[0049] Figure 24 This is a schematic diagram of the process for analyzing the mesh quality of test products and generating test reports, provided in an embodiment of this application.
[0050] Figure 25 This is a schematic diagram of the mesh quality analysis function call and log output provided in an embodiment of this application.
[0051] Figure 26 This is a schematic diagram of the quality analysis process provided in an embodiment of this application.
[0052] Figure 27 The generated mesh quality report diagram provided for the embodiments of this application.
[0053] Figure 28 This is a schematic diagram of the deployment of a multi-node test system based on a hybrid communication architecture of virtual switching and physical switching, provided in an embodiment of this application. Detailed Implementation
[0054] The method of the present invention will now be described in detail with reference to the accompanying drawings and embodiments.
[0055] like Figure 1 As shown, the present invention provides a method for automated testing of parallel mesh generation software, comprising the following steps:
[0056] S1: Deploy the master node, build nodes, and parallel test nodes; establish connections between nodes; and generate a schedulable test environment. The overall system architecture is as follows: Figure 2 As shown, it includes the following sub-steps:
[0057] S11: On a Linux system, the runtime environment of the master control node is deployed in the master control node through a container management platform to support the high availability of the scheduling service. The master control node is responsible for receiving task trigger events, unifying the scheduling of build and test processes, and coordinating the parallel execution of multiple nodes.
[0058] Specifically, the container management platform refers to a management platform with functions such as containerized deployment, resource scheduling, node management, and runtime environment maintenance. A container management platform such as... Figure 3As shown, deploying the main control service using a container management platform provides higher maintainability and elastic scalability, and supports fault self-recovery mechanisms, achieving high availability and stable operation of the scheduling system.
[0059] Specifically, the task triggering events refer to code commits, branch merging, tag pushing, timed triggering, manual triggering, and external system calls, such as... Figure 4 As shown.
[0060] Specifically, the scheduling service refers to the process whereby, upon receiving a task trigger event, the master node distributes compilation tasks to the build nodes, distributes test tasks to the parallel test nodes, and coordinates the execution of corresponding task flows by each node. This unified scheduling mechanism simplifies task management and improves the overall process efficiency.
[0061] S12: On the Linux system, a compilation environment is deployed in the build node through a container management platform to support efficient compilation task execution. The build node is responsible for receiving compilation tasks from the master node, executing relevant build processes, generating build artifacts, and ensuring efficient collaboration and task transmission with other nodes.
[0062] Specifically, the build node refers to the virtual machine used for build operations, and its node status is as follows: Figure 5 As shown, this node internally deploys a build task execution service that can run in a container, capable of automatically pulling build tasks, executing the compilation process, and producing build results. After deployment, this service registers with the master node by establishing a trusted connection, allowing the master node to automatically issue build instructions based on triggered events and transfer the relevant code and dependencies to the build nodes for execution. This automatic pulling and registration mechanism ensures real-time task response and the system's elastic scalability.
[0063] S13: On the Linux system, a test environment is deployed in the parallel test node through a container management platform to support efficient test task execution. The parallel test node is responsible for receiving the build artifacts from the build node and the test tasks from the master node, executing the corresponding test process, and feeding back the test report to the master node.
[0064] Specifically, the parallel test node refers to a virtual computing node that can independently run the test process, and its node status is as follows: Figure 5 As shown, internally deployed service components are capable of automatically executing test scripts, collecting test results, and generating reports. Test nodes load necessary dependency libraries and testing tools through a uniformly configured container runtime environment. An independent dual-source input mechanism of "build artifact transmission + parallel test scheduling" is introduced to ensure that test nodes have high flexibility and independence, effectively solving the problem of excessive build / test coupling in traditional test architectures.
[0065] S14: Configure a virtual network in a local area network environment to establish a connection between the virtual network card inside the container and the local area network, ensuring that the master node, build node and parallel test node can communicate with each other efficiently and securely.
[0066] Specifically, the virtual network configuration includes a master node network configuration, a node network configuration for building nodes, and a parallel test node network configuration, as shown in the figure. The three node network configurations are as follows: Figure 6 , Figure 7 and Figure 9 As shown.
[0067] Specifically, the interconnection includes building nodes connecting to the master node and parallel test nodes via a virtual network, as shown in the diagram. Figure 8 As shown. The parallel test nodes are connected to the master node and the build node via a virtual network. The connectivity of the parallel test nodes is as follows. Figure 10 As shown, using virtual networks to isolate and control nodes not only ensures network security but also improves data transmission efficiency between nodes. Virtual network interface cards (NICs) can be quickly reused and expanded after unified configuration, avoiding the cumbersome setup and inconvenient management issues of traditional physical network deployments.
[0068] S2: Based on the aforementioned test environment, obtain the structured configuration parameter files required for compilation tasks, test tasks, and quality analysis, including the following sub-steps:
[0069] S21: Based on the source code location, dependency information, and compilation options described in the structured configuration parameter file, a script file for compilation is written in advance, and a command to call the compilation script is written in the structured configuration parameter file to complete the automated compilation of the source code.
[0070] Specifically, the compilation information in the structured configuration parameter file is organized using a hierarchical syntax, supporting the definition of multiple build targets within the same build process. For example... Figure 11 As shown, taking a specific build task as an example, this task specifies the current build stage, the platform-compatible tag identifier, the sequence of build scripts to be executed, and the inherited base build template. The compilation task parameters are abstracted and encapsulated into scripts, and managed through structured files, enabling the entire build process to be reproduced, audited, and quickly switched between different build strategies. Simultaneously, it achieves unattended triggering of build tasks, improving the level of CI automation.
[0071] The build information uses a tagging mechanism to limit the execution node range of the task, ensuring that the task only runs on nodes that meet specific platform conditions; such as Figure 12As shown, the script section lists several pre-build and core scripts that are executed in sequence to implement the environment preparation and source code build process; predefined build behavior templates, such as build cache paths and compilation toolchain configurations, are introduced through an inheritance mechanism to improve configuration reusability and consistency.
[0072] S22: In the structured configuration parameter file, define the output information that needs to be saved during compilation and testing, such as... Figure 13 As shown, this includes the file path to be saved, directory path, storage period, and target storage location;
[0073] Specifically, by pre-setting the product retention strategy in the parameter file, resources can be precisely controlled, redundant products can be avoided, and the system's storage efficiency and lifecycle management capabilities can be improved. At the same time, it is convenient to reuse products in subsequent processes, thereby improving the overall task execution efficiency.
[0074] S23: In the structured configuration parameter file, define the execution content of the test phase, specifically including the path of the test script, the test timeout, and the handling strategy after the test fails;
[0075] Specifically, such as Figure 14 As shown, the structured configuration parameter file defines the test task name, execution phase identifier, runtime environment label, dependent preceding build tasks, and specific test execution scripts and their parameters for the testing phase. The test execution scripts are as follows: Figure 15 As shown in the diagram, this configuration uses structured fields to describe the test service, enabling it to automatically identify the test execution order, target test script path, execution permission settings, and dependencies, supporting automatic scheduling and execution control of the test process. Using structured fields to fully express the context of test tasks enhances the system's adaptability and parallel control capabilities for complex test processes, making it particularly suitable for test management in multi-phase, cross-platform, or microservice architectures.
[0076] S24: In the structured configuration parameter file, define the execution content of the quality analysis phase, specifically including the name of the quality analysis tool, the path of the analysis script, the analysis parameter configuration, the quality threshold standard, and the name of the generated test report.
[0077] Specifically, in the structured configuration parameter file, such as Figure 16As shown, several key fields are configured for the quality analysis phase, including: a tag field to identify the task phase, the script path for executing the quality analysis, dependency declarations of preceding build tasks, and execution environment tags. The analysis script, after being granted execution permissions, is scheduled by the master node to run on the target node to perform operations such as code quality checks, metric analysis, and quality threshold verification. This configuration also supports generating corresponding test reports after the analysis task is completed and integrating with other modules through a unified naming convention, facilitating the system's automatic aggregation of quality results and output of test documentation, improving test coverage and traceability. Decoupling and structurally managing quality gating standards and analysis tool configurations enhances the configurability and project adaptability of quality analysis; unified standards also facilitate later integration with quality alerts and release interception mechanisms in DevOps.
[0078] S3: According to the structured configuration parameter file, when the master node detects a preset event, it distributes the compilation task to the build node to generate the build artifact, including the following sub-steps:
[0079] S31: The master node continuously monitors the preset trigger conditions. When an event that meets the trigger conditions is detected, the event information is recorded and preparations are made to start subsequent tasks. The trigger conditions include source code submission, branch merging, tag creation or other operations related to version changes.
[0080] Specifically, listening ensures that the system can respond to code change events immediately, avoiding delays caused by manual triggering or periodic polling, and improving the real-time performance and agility of the build system.
[0081] Specifically, the master node continuously monitors the trigger sources integrated with the version control system, and when it detects such... Figure 17 When performing operations related to version changes, such as source code submission, target branch merging, and tag creation, the system automatically records key information about the event, including the trigger time, committer ID, changed branch, and change summary. This event is then used as the basis for subsequent process scheduling to prepare for the execution of corresponding build or test tasks, ensuring that the system can automatically drive downstream processing after a version update.
[0082] S32: The master node determines the compilation task content to be distributed based on the structured configuration parameter file, including the module to be compiled and the compilation parameters.
[0083] Specifically, the master node receives, for example Figure 16After the trigger event indicated by the `stage` field, the system automatically parses the fields related to the compilation stage in the structured configuration parameter file, including the specified build module identifier, the path to the required build scripts, compilation parameters, and dependency definitions. Through this parameter parsing process, the system extracts the key elements of the compilation task and constructs a unified-format task description object, which serves as the basis for subsequent task scheduling and distribution, thereby achieving flexible build management in multi-module, multi-configuration environments. Driving the parsing of build content through configuration files helps in modular management of different tasks, avoiding hard coding. Utilizing structured configuration to automatically parse modules and their parameters to construct a unified task object represents a module-level scheduling abstraction that is difficult to achieve with traditional pipeline scripts. This method enhances cross-project versatility, reduces script maintenance costs, and improves the standardization of task scheduling.
[0084] S33: The master node distributes the corresponding compilation task to the build node according to the determined compilation task content, so that the build node can perform the compilation operation subsequently;
[0085] Specifically, such as Figure 18 As shown, after parsing and organizing the compilation task content, the master node selects an available build node based on the build tags or resource constraints specified in the task description. It then sends the task instructions, containing information such as the build script path, compilation parameters, and execution order, to the target build node via the scheduling module. During the distribution process, the master node can record the task allocation status and track node responses to ensure that build tasks are accurately and efficiently distributed and enter the execution queue, supporting subsequent parallel or sequential compilation processes.
[0086] S34: The build node receives the compilation tasks distributed by the master node, performs the compilation operation according to the task content, and generates the corresponding build artifacts;
[0087] Specifically, after receiving the compilation task distributed by the master node based on the structured configuration parameter file, the build node, as follows: Figure 19 As shown, the system automatically parses the information of the modules to be compiled, compilation parameters, and dependency descriptions contained in the task, and calls the locally configured compilation scripts or compilation toolchains to compile the corresponding modules one by one. After the compilation is completed, the system automatically generates the corresponding build artifacts and records the compilation logs and result status to support subsequent artifact archiving, quality assessment, and build traceability verification. Delegating execution to the build nodes reduces the pressure on the master node, while supporting parallel builds and improving the overall system throughput.
[0088] S35: The build node persistently saves the generated build artifacts according to the definition of artifact saving in the structured configuration parameter file.
[0089] Specifically, after completing the compilation operation and generating the build artifacts, the build node automatically executes the artifact persistence process according to the artifact saving strategy and path definition preset in the structured configuration parameter file. For example... Figure 20 As shown, the process includes identifying build files to be archived, classifying and naming artifacts according to configuration requirements and mapping their paths, and storing them in designated persistent storage locations. Furthermore, the build node will synchronously record and save path and artifact metadata information to facilitate subsequent artifact scheduling, distribution, and backtracking queries, ensuring the traceability of the build process and the controllability of artifact management. Integrating artifact management strategies into the configuration system and decoupling them from the build execution logic gives the build process higher maintainability and automation, making it suitable for build archiving needs across multiple versions and environments.
[0090] S4: Based on the structured configuration parameter file, after the compilation task is completed, the build artifacts are distributed to the parallel test nodes, including the following sub-steps:
[0091] S41: The master node determines the distribution rules based on the structured configuration parameter file, including the build artifacts to be distributed and their corresponding parallel test nodes;
[0092] Specifically, the master control node according to, for example Figure 18 The structured configuration parameter file shown contains configurations for artifact distribution. These configurations are used to parse out the build artifacts to be distributed and their corresponding target test nodes. The master control node, based on the current system state, determines the distribution path and parallel delivery strategy for each build artifact, preparing resource scheduling for the subsequent automated testing phase. This ensures that test nodes can receive build artifacts in a timely manner, supporting the concurrent execution of subsequent test tasks and improving overall process efficiency and system response speed.
[0093] S42: The master node will distribute the corresponding build artifacts to the parallel test nodes according to the distribution rules determined in S41;
[0094] Specifically, the master node distributes the corresponding build products to designated parallel test nodes via network transmission according to the established distribution rules. During the distribution process, the system can support multi-threading or asynchronous mechanisms to improve transmission efficiency and record the distribution status for tracking and fault retries. This improves the efficiency and stability of data distribution, especially in high-concurrency and large-scale clusters, where it has significant advantages.
[0095] S43: The parallel test node receives the build artifacts distributed by the master node and prepares to perform subsequent test operations.
[0096] Specifically, the test node has the ability to automatically prepare the received products (such as path mounting, verification, preprocessing, etc.), which is a key link to realize the "zero human intervention automated test link" and significantly improves the closed-loop efficiency of the test process.
[0097] S5: Based on the structured configuration parameter file, perform test tasks on the built artifacts on the parallel test nodes to generate a test artifact mesh, such as... Figure 21 As shown, it includes the following sub-steps:
[0098] S51: Based on the structured configuration parameter file, determine the test input content to be used in the testing phase, wherein the test input content includes a pre-prepared geometric data file;
[0099] Specifically, the parallel test nodes, based on the paths and credentials defined in the structured configuration parameter file, such as... Figure 22 As shown, by mounting the SFTP file management service provided by the master node, the geometric data files required for the test are obtained as test input, ensuring that the test task has complete initial data support. Dynamically loading master node resources through the SFTP mounting mechanism avoids redundant data copying, enhances data sharing capabilities between nodes, and facilitates unified scheduling and management of large-scale data input.
[0100] S52: Based on the structured configuration parameter file, determine the test execution rules, such as... Figure 14 As shown, the test execution rules include the test script path, test parameter configuration, test timeout, and test failure handling strategy;
[0101] Specifically, by incorporating the handling strategy after a test failure into configuration management, operations such as retrying, aborting, and skipping can be performed automatically, improving the system's fault tolerance for unpredictable test behavior.
[0102] S53: On the parallel test node, the built artifact is invoked, and the test task is executed according to the determined test input content and the determined test execution rules;
[0103] Specifically, the parallel test nodes, based on the structured configuration parameter file, call the corresponding build artifacts and, in conjunction with pre-determined test inputs and test execution rules, automatically execute test scripts or commands to complete the testing process of the build artifacts. By unifying the test execution scripts, parameters, inputs, and artifacts into an execution flow driven by structured configuration, each test node can run independently and automatically, constructing a "self-scheduled + self-executing" test micro-unit, greatly enhancing the system's automation level.
[0104] S54: On the parallel test node, a test product grid is generated based on the test task execution results;
[0105] Specifically, after completing the test task, the parallel test node automatically generates a test product mesh based on the test execution results and outputs it in the form of a VTK file to represent the spatial data or calculation results generated during the test for subsequent visualization or analysis.
[0106] Specifically, the test nodes can dynamically generate VTK format grid data based on the test results, taking into account both the needs of scientific computing visualization and versatility, meeting the needs of subsequent analysis and processing, and laying the foundation for a closed-loop technology.
[0107] S55: Persistently save the test product mesh on the parallel test node according to the structured configuration parameter file.
[0108] Specifically, the parallel test nodes persistently save the generated VTK format test product mesh to the master node according to the save path and naming rules defined in the structured configuration parameter file, ensuring that the test results are traceable and reusable. Figure 23 The generated VTK format test product mesh.
[0109] S6: Based on the structured configuration parameter file, perform quality analysis on the test product mesh and generate a corresponding test report, such as... Figure 24 As shown, it includes the following sub-steps:
[0110] S61: Based on the structured configuration parameter file, determine the indicators that need to be tested in the quality analysis stage, including accuracy indicators and integrity indicators;
[0111] Specifically, the parallel test node parses out the indicators to be tested in the current quality analysis stage based on the preset quality analysis configuration items in the structured configuration parameter file. The indicators include accuracy indicators to reflect the correctness of the data and integrity indicators to evaluate the completeness of the data, providing a basis for subsequent analysis processes.
[0112] S62: Determine the quality analysis rules based on the structured configuration parameter file. The quality analysis rules include minimum angle, maximum angle, side length ratio, cell shape regularity, area consistency, and mesh connectivity consistency.
[0113] S63: Load the test product mesh onto the parallel test node as the object data for quality analysis;
[0114] S64: On the parallel test node, according to the determined quality analysis rules, perform quality analysis on the loaded test product mesh to obtain the detection results of various quality indicators;
[0115] Specifically, the parallel test nodes, according to the quality analysis rules pre-determined in the structured configuration parameter file, such as... Figure 25 As shown, a quality analysis operation is performed on each item of the loaded test product mesh, automatically calculating the actual values of various indicators, including quality elements such as volume, angle, and shape regularity, and so on. Figure 26 As shown, the corresponding detection results are output as the basis for generating subsequent reports.
[0116] S65: On the parallel test node, a corresponding test report is generated based on the test results of each quality indicator.
[0117] Specifically, the test report structure is as follows: Figure 27 As shown, the execution process based on quality analysis is automatically generated, including mesh optimization operation logs, quality assessment data for each stage, and overall performance indicators. The report includes: optimization operation records for mesh volume-to-side-length ratio and dihedral angles, optimization strategies used (such as flipping, Laplace smoothing, splitting, etc.), quality analysis results for each round (number of bad elements, minimum quality minQ, average quality avg, and corresponding element IDs), angle statistics (minimum angle, maximum angle, average angle, etc.), mesh removal and repair information (such as hole handling), and final mesh quality indicators, including total time, optimization speed, number of tetrahedra, memory usage, and generation success flags.
[0118] refer to Figure 2 This invention also provides an apparatus for supporting automated testing of parallel mesh generation software, comprising:
[0119] The master node is used to listen to preset events, parse structured configuration parameter files, distribute compilation tasks to build nodes, receive build artifact information returned by build nodes, distribute build artifacts and test tasks to parallel test nodes, receive test artifact mesh and quality analysis reports returned by parallel test nodes, and realize unified scheduling and coordination control of the entire automated testing process.
[0120] Specifically, the master node is deployed in a physical server environment or a containerized scheduling service environment. It continuously listens for preset trigger events, including code commits, branch merging, or tag creation. When an event is captured, it automatically parses the structured configuration parameter file, extracts the task configuration and execution rules, and then calls the scheduling logic to send the compilation task to the build node. After receiving the build artifact, it combines the test task configuration to complete the synchronization of tasks and artifacts of the parallel test nodes. After the test is completed, it summarizes the grid data and quality analysis reports fed back by each node, realizing unified scheduling and closed-loop control across nodes and stages.
[0121] Specifically, a containerized scheduling service and a structured configuration file parsing mechanism are adopted, which can dynamically trigger and automatically distribute compilation and testing tasks according to preset events, improving the response speed and flexibility of the testing process. This achieves the technical effects of reducing manual intervention, improving automation and multi-node collaboration efficiency, which is conducive to the continuous integration and stable testing of large-scale grid generation software in high-performance computing environments.
[0122] The build node is used to receive compilation tasks distributed by the master node, perform compilation operations according to the structured configuration parameter file, generate build artifacts, and return the build artifacts to the master node;
[0123] Specifically, the build node is deployed in a physical server environment or a containerized scheduling service environment. It receives the task content, which includes the source code path, dependency description and compilation parameters, distributed by the master node. It automatically calls the preset build script to execute the compilation process. After the compilation is completed, it persists or encapsulates the build product according to the product saving path and storage strategy defined in the structured configuration parameter file, and feeds back the build product information to the master node through a shared mount directory or file transfer protocol.
[0124] Specifically, the build nodes adopt a standardized container compilation environment and parameterized build process, which can effectively avoid inconsistencies in the environment and configuration deviations during the build process, and improve the stability and repeatability of the compilation task. This achieves the technical effects of improving build efficiency, reducing build failure rate and improving the controllability of build products, providing reliable input guarantee for the subsequent testing phase.
[0125] Parallel test nodes are used to receive test tasks and build artifacts distributed by the master node, execute test operations according to the structured configuration parameter file, generate test artifact grids, perform quality analysis, and feed the results back to the master node;
[0126] Specifically, the parallel test nodes are deployed in a physical server environment or a containerized scheduling service environment. After receiving the build artifacts and test tasks distributed by the master node, they automatically load geometric data files and call test tools to execute mesh generation test tasks according to the test input paths, execution scripts, parameter configurations, and timeout policies defined in the structured configuration parameter file, generating test artifact meshes. Subsequently, based on the analysis rules, they load the mesh data, perform quality analysis including indicators such as element shape regularity, side length ratio, and connectivity consistency, and generate structured test reports according to the configuration requirements. The test artifacts and analysis results are then synchronously fed back to the master node.
[0127] Specifically, the parallel test nodes adopt a parameter-driven automatic testing and quality analysis mechanism, which can realize an efficient and unified grid testing and quality verification process, significantly shortening the testing cycle. This achieves the technical effects of highly automated testing process, timely and accurate result feedback, and good system scalability, meeting the testing needs of parallel grid software in large-scale scenarios.
[0128] The three nodes communicate with each other to generate a schedulable test environment and enable collaborative execution and data exchange of each stage of the test in a local area network or virtual network.
[0129] Specifically, such as Figure 28 As shown, the three types of nodes are deployed in virtualization platforms or physical server environments, respectively, with network connections achieved through Bridge bridging. Virtual nodes bridge their virtual network interface cards to the physical network via virtual switches, while physical nodes connect to the same LAN switch via network cables, placing all nodes in a unified logical Layer 2 network and supporting direct IP-based communication. This architecture offers excellent flexibility and scalability, allowing for seamless addition or replacement of nodes in different deployment environments, supporting dynamic expansion of the testing process and multi-node collaboration. Because it adopts a unified network architecture based on Bridge and flexibly accommodates hybrid deployments of virtual machines and physical nodes, it can achieve elastic expansion of the deployment structure while ensuring network communication stability. This results in convenient deployment, efficient node interoperability, and sustainable expansion of the testing system, providing strong network support for the stable operation of large-scale parallel testing systems.
[0130] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.
[0131] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.
Claims
1. A method for supporting automated testing of parallel mesh generation software, characterized in that, include: Deploy master nodes, build nodes, and parallel test nodes, establish connections between nodes, and generate a schedulable test infrastructure environment; Based on the aforementioned test environment, obtain the structured configuration parameter files required for compilation tasks, test tasks, and quality analysis; According to the structured configuration parameter file, when the master node detects a preset event, it distributes the compilation task to the build node to generate the build artifact; According to the structured configuration parameter file, after the compilation task is completed, the build artifacts are distributed to the parallel test nodes; According to the structured configuration parameter file, test tasks are performed on the built product on the parallel test node to generate a test product mesh; Based on the structured configuration parameter file, perform quality analysis on the test product mesh and generate a corresponding test report; Specifically, based on the aforementioned test environment, the structured configuration parameter files required for compilation tasks, test tasks, and quality analysis are obtained, including: Based on the source code location, dependency information, and compilation options described in the structured configuration parameter file, a script file for compilation is written in advance, and a command to call the compilation script is written in the structured configuration parameter file to complete the automated compilation of the source code. The structured configuration parameter file defines the artifact information that needs to be saved during compilation and testing, including the file path, directory path, storage period, and target storage location to be saved. The structured configuration parameter file defines the execution content of the test phase, including the path of the test script, the test timeout, and the handling strategy after the test fails. The structured configuration parameter file defines the execution content of the quality analysis phase, including the name of the quality analysis tool, the path of the analysis script, the configuration of analysis parameters, the quality threshold standards, and the name of the generated test report.
2. The method for automated testing of parallel mesh generation software according to claim 1, characterized in that, Deploy the master node, build nodes, and parallel test nodes, establish connections between nodes, and generate a schedulable test infrastructure environment, specifically including: On a Linux system, the runtime environment of the master node is deployed in the master node through a container management platform to support the high availability of the scheduling service. The master node is responsible for receiving task trigger events, unifying the scheduling of build and test processes, and coordinating the parallel execution of multiple nodes. On a Linux system, a build environment is deployed in the build node through a container management platform to support efficient build task execution. The build node is responsible for receiving build tasks from the master node, executing the relevant build process, generating build artifacts, and ensuring efficient collaboration and task transmission with other nodes. On a Linux system, a test environment is deployed in a parallel test node through a container management platform to support efficient test task execution. The parallel test node is responsible for receiving build artifacts from the build node and test tasks from the master node, executing the corresponding test process, and feeding back the test report to the master node. Configure a virtual network in the local area network environment to establish a connection between the virtual network card inside the container and the local area network, ensuring that the master node, build node and parallel test node can communicate with each other efficiently and securely.
3. The method for automated testing of parallel mesh generation software according to claim 1, characterized in that, According to the structured configuration parameter file, when the master node detects a preset event, it distributes compilation tasks to the build node to generate build artifacts, specifically including: The master node continuously monitors preset trigger conditions. When an event that meets the trigger conditions is detected, the event information is recorded and preparations are made to start subsequent tasks. The trigger conditions include source code submission, branch merging, tag creation, or other operations related to version changes. The master node determines the compilation tasks to be distributed based on the structured configuration parameter file, including the modules to be compiled and the compilation parameters; The master node distributes the corresponding compilation tasks to the build nodes based on the determined compilation task content, so that the build nodes can perform the compilation operations subsequently. The build node receives compilation tasks distributed by the master node, performs compilation operations according to the task content, and generates the corresponding build artifacts; The build node persistently saves the generated build artifacts according to the definition of artifact saving in the structured configuration parameter file.
4. The method for automated testing of parallel mesh generation software according to claim 1, characterized in that, Based on the structured configuration parameter file, after the compilation task is completed, the build artifacts are distributed to the parallel test nodes, specifically including: The master node determines the distribution rules based on the structured configuration parameter file, including the build artifacts to be distributed and their corresponding parallel test nodes; The master node will distribute the corresponding build artifacts to the parallel test nodes according to the distribution rules; Parallel test nodes receive the build artifacts distributed by the master node and prepare for subsequent test operations.
5. The method for automated testing of parallel mesh generation software according to claim 1, characterized in that, Based on the structured configuration parameter file, test tasks are executed on the built artifacts on the parallel test nodes to generate a test artifact mesh, specifically including: Based on the structured configuration parameter file, the test input content to be used in the testing phase is determined, and the test input content includes a pre-prepared geometric data file; Based on the structured configuration parameter file, the test execution rules are determined, including the test script path, test parameter configuration, test timeout, and test failure handling strategy. On the parallel test node, the built artifact is invoked, and the test task is executed according to the determined test input content and the determined test execution rules; On the parallel test node, a test product grid is generated based on the test task execution results; According to the structured configuration parameter file, the test product mesh is persistently saved on the parallel test node.
6. The method for automated testing of parallel mesh generation software according to claim 1, characterized in that, Based on the structured configuration parameter file, a quality analysis is performed on the test product mesh, and a corresponding test report is generated, specifically including: Based on the structured configuration parameter file, the indicators that need to be tested in the quality analysis phase are determined, including accuracy indicators and integrity indicators. Based on the structured configuration parameter file, quality analysis rules are determined, including minimum angle, maximum angle, side length ratio, cell shape regularity, area consistency, and mesh connectivity consistency. On the parallel test node, the test product mesh is loaded as the object data for quality analysis; On the parallel test node, quality analysis is performed on the loaded test product mesh according to the determined quality analysis rules to obtain the detection results of various quality indicators; On the parallel test node, a corresponding test report is generated based on the test results of each quality indicator.
7. An apparatus for supporting automated testing of parallel mesh generation software, characterized in that, include: The master node is used to listen for preset events, parse structured configuration parameter files, and distribute compilation tasks to build nodes; Receive build artifact information returned by the build node, distribute build artifacts and test tasks to the parallel test node; receive test artifact mesh and quality analysis report returned by the parallel test node, and realize unified scheduling and coordination control of the entire automated testing process; The build node is used to receive compilation tasks distributed by the master node, perform compilation operations according to the structured configuration parameter file, generate build artifacts, and return the build artifacts to the master node; Parallel test nodes are used to receive test tasks and build artifacts distributed by the master node, execute test operations according to the structured configuration parameter file, generate test artifact grids, perform quality analysis, and feed the results back to the master node; The three nodes communicate with each other to generate a schedulable test environment and enable collaborative execution and data exchange of each stage of the test in a local area network or virtual network. Specifically, based on the aforementioned test environment, the structured configuration parameter files required for compilation tasks, test tasks, and quality analysis are obtained, including: Based on the source code location, dependency information, and compilation options described in the structured configuration parameter file, a script file for compilation is written in advance, and a command to call the compilation script is written in the structured configuration parameter file to complete the automated compilation of the source code. The structured configuration parameter file defines the artifact information that needs to be saved during compilation and testing, including the file path, directory path, storage period, and target storage location to be saved. The structured configuration parameter file defines the execution content of the test phase, including the path of the test script, the test timeout, and the handling strategy after the test fails. The structured configuration parameter file defines the execution content of the quality analysis phase, including the name of the quality analysis tool, the path of the analysis script, the configuration of analysis parameters, the quality threshold standards, and the name of the generated test report.