Multi-platform testing methods, devices, electronic equipment, storage media and program products

Abstract

This application provides a multi-platform testing method, apparatus, electronic device, storage medium, and program product. The method includes: acquiring runtime configuration information to be tested, including platform types and test parameter information for multiple computing platforms, whereby the computing platforms manage multiple computing resources; determining multiple sets of test tasks and multiple business types corresponding to each test task based on the test parameter information, whereby the test tasks are used to perform business tests on the multiple computing platforms; determining the multiple computing platforms to be invoked for executing each test task and the protocol information required for communication with each computing platform based on the platform type and business type; and executing each set of test tasks according to the protocol information to obtain the test results of each test task, thereby improving the efficiency of multi-platform testing.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a multi-platform testing method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] With the widespread application of various computing platforms such as supercomputing platforms, cluster management, and hybrid cloud, a large number of computing platforms are deployed to uniformly manage distributed computing resources. This has made it a key requirement to ensure the stable operation of business by conducting unified and standardized business function testing on multiple platforms.

[0003] In related technologies, multi-platform testing is usually carried out using an independent testing approach. This means that users need to configure test parameters and corresponding test cases for different computing platforms, and when executing test cases, they need to use the testing tools corresponding to the platform.

[0004] However, in the above process, the testing requirements of a single business test need to be completed collaboratively across multiple platforms, and the testing tools corresponding to different computing platforms are different, making it difficult to achieve unified and coherent cross-platform business testing, resulting in poor efficiency of multi-platform testing. Summary of the Invention

[0005] This application provides a multi-platform testing method, apparatus, electronic device, storage medium, and program product to solve the technical problem of poor efficiency in multi-platform testing.

[0006] Firstly, this application provides a multi-platform testing method, including:

[0007] Obtain the runtime configuration information to be tested. The runtime configuration information includes the platform type and test parameter information of multiple computing platforms. The computing platform is used to manage multiple computing resources.

[0008] Based on the test parameter information, multiple sets of test tasks and multiple business types corresponding to each test task are determined. The test tasks are used to perform business tests on multiple computing platforms.

[0009] Based on the platform type and business type, determine the multiple computing platforms that need to be invoked to execute each test task, as well as the protocol information required to communicate with each computing platform;

[0010] According to the agreement information, execute each group of test tasks and obtain the test results for each test task.

[0011] In this embodiment, by acquiring runtime configuration information containing platform types and test parameter information of multiple computing platforms, multiple sets of test tasks and the corresponding business types of each test task are determined based on the test parameter information. Furthermore, the computing platform and corresponding communication protocol information required to execute each test task are determined based on the platform type and business type. Finally, each set of test tasks is executed according to the protocol information to obtain the test results. In this method, the electronic device can dynamically determine the computing platform and its communication protocol for each test task based on the platform type and business type, and complete business process testing involving multiple computing platforms within a unified testing framework. This enables cross-platform business testing even when different platforms use different communication protocols, effectively avoiding the problem of process fragmentation caused by the independence of testing tools. It eliminates the need to maintain test cases and test data for each platform separately, improving the efficiency and consistency of multi-platform testing. Moreover, this method is applicable to the testing needs of various types of computing platforms such as supercomputing platforms, cluster management, and hybrid clouds, reducing the deployment and maintenance costs of the testing system, ensuring the stable operation of multi-computing platform services, and improving the efficiency of multi-platform integration testing while achieving unified multi-platform testing.

[0012] Optionally, the method described above is used to obtain the runtime configuration information to be tested, including:

[0013] Obtain the runtime configuration file input by the user, parse and process the runtime configuration file to obtain the platform type, test environment information and runtime information of the computing platform;

[0014] Based on the platform type, test environment information, and runtime information, determine the environment configuration information and permission configuration information corresponding to each computing platform. The environment configuration information is used to configure the test environment of the computing platform, and the permission configuration information is used to configure the access permissions of the computing platform.

[0015] The environment configuration information, permission configuration information, platform type, and test parameter information are determined as the runtime configuration information.

[0016] In this embodiment, by parsing the user-input runtime configuration file, the environment configuration information and permission configuration information corresponding to each computing platform are obtained, realizing the automated parsing and dynamic loading of test configuration, and improving the convenience of multi-platform test environment configuration and permission management.

[0017] Optionally, the method described above determines multiple sets of test tasks based on test parameter information, including:

[0018] Based on the test parameter information, load the corresponding test file. The test file includes multiple test tasks and corresponding task identifiers. The task identifiers are used to indicate the execution stage of the test task.

[0019] Based on the task identifier of each test task, multiple test tasks are grouped to obtain a set of pre-test tasks, a set of intermediate test tasks, and a set of post-test tasks. The set of pre-test tasks is used to perform pre-test preparation operations, the set of intermediate test tasks is used to perform business operations on the computing platform, and the set of post-test tasks is used to perform post-test cleanup operations.

[0020] In this embodiment, the corresponding test file is loaded according to the test parameter information, and the test tasks are divided into three sets of tasks: pre-task, intermediate-task, and post-task according to the task identifier of each test task. This realizes the phased management and orderly execution of test tasks, and ensures the integrity and logical clarity of the test process.

[0021] Optionally, using the method described above, each group of test tasks is executed according to the protocol information to obtain the test results for each test task, including:

[0022] Determine the number of task processes used to execute the test tasks;

[0023] Based on the number of task processes, the set of pre-test tasks, the set of intermediate test tasks, and the set of post-test tasks, the task execution strategy is determined. The task execution strategy is used to indicate the execution steps and distribution method of each test task on multiple task processes.

[0024] Based on the protocol information and task execution strategy, the test tasks of each task process are executed in parallel to obtain the test results of each test task.

[0025] In this embodiment, by determining the number of task processes and formulating a task execution strategy in combination with the sets of pre-, intermediate, and post-tasks, test tasks are executed in parallel according to protocol information and execution strategy, thereby realizing the quantitative allocation of test resources and concurrent scheduling of tasks, and improving the execution efficiency of multi-platform testing.

[0026] Optionally, the method described above determines the task execution strategy based on the number of task processes, the set of pre-test tasks, the set of intermediate test tasks, and the set of post-test tasks, including:

[0027] Based on the number of task processes, each test task in the pre-test task set is distributed to multiple task processes for parallel execution;

[0028] After the pre-test tasks are completed, each test task in the intermediate test task set is distributed to multiple task processes for parallel execution, based on the number of task processes.

[0029] After the intermediate test tasks are completed, each test task in the set of subsequent test tasks is distributed to any task process and executed in the order of distribution.

[0030] In this embodiment, by distributing the pre-tasks and intermediate tasks to multiple processes for parallel execution and distributing the post-tasks to a single process for sequential execution, phased concurrency control of test tasks is achieved, ensuring the sequential dependency of test execution and avoiding resource contention and cleanup conflicts.

[0031] Optionally, using the method described above, test tasks for each task process are executed in parallel based on protocol information and task execution strategy to obtain test results for each test task, including:

[0032] Retrieve the test tasks corresponding to the task processes in the task queue. The task queue includes multiple sets of test tasks to be executed.

[0033] Access permissions for test tasks are verified. After successful verification, the test task is executed according to the protocol information corresponding to the test task, and the corresponding test results are obtained and stored in the result queue. The result queue is used to store the test results of each test task.

[0034] In this embodiment, test tasks are obtained through a task queue and permission verification is performed. After the verification is passed, the test tasks are executed according to the protocol information and the results are stored in the result queue. This achieves unified management of the permission security of test tasks and the execution results, and ensures the integrity and traceability of test data in a multi-process environment.

[0035] Optionally, after obtaining the test results for each test task, the method described above further includes:

[0036] Obtain test information for each test task during execution;

[0037] Based on the test results and corresponding test information of each test task in the result queue, determine the first parameter and the second parameter. The first parameter is used to indicate the coverage of each test task to the called interface, and the second parameter is the pass rate of each test task.

[0038] A test report is generated based on the test results of each test task, the corresponding test information, the first parameter, and the second parameter.

[0039] In this embodiment of the application, by obtaining test information during the execution of the test task, combining the test results to determine the interface coverage and test pass rate, and generating a test report, the comprehensiveness and practicality of the test report are ensured, and the analyzability of the test results is improved.

[0040] Secondly, this application provides a multi-platform testing apparatus, comprising:

[0041] The acquisition module is used to acquire the runtime configuration information to be tested. The runtime configuration information includes the platform type and test parameter information of multiple computing platforms. The computing platform is used to manage multiple computing resources.

[0042] The first determination module is used to determine multiple sets of test tasks and multiple business types corresponding to each test task based on test parameter information. The test tasks are used to perform business tests on multiple computing platforms.

[0043] The second determining module is used to determine, based on the platform type and business type, the multiple computing platforms to be invoked for executing each test task, as well as the protocol information required for communication with each computing platform;

[0044] The processing module is used to execute each group of test tasks according to the protocol information and obtain the test results of each test task.

[0045] Optionally, in the apparatus described above, the module for obtaining the operational configuration information to be tested is specifically used for:

[0046] Obtain the runtime configuration file input by the user, parse and process the runtime configuration file to obtain the platform type, test environment information and runtime information of the computing platform;

[0047] Based on the platform type, test environment information, and runtime information, determine the environment configuration information and permission configuration information corresponding to each computing platform. The environment configuration information is used to configure the test environment of the computing platform, and the permission configuration information is used to configure the access permissions of the computing platform.

[0048] The environment configuration information, permission configuration information, platform type, and test parameter information are determined as the runtime configuration information.

[0049] Optionally, in the apparatus described above, multiple sets of test tasks are determined based on test parameter information, and the first determining module is specifically used for:

[0050] Based on the test parameter information, load the corresponding test file. The test file includes multiple test tasks and corresponding task identifiers. The task identifiers are used to indicate the execution stage of the test task.

[0051] Based on the task identifier of each test task, multiple test tasks are grouped to obtain a set of pre-test tasks, a set of intermediate test tasks, and a set of post-test tasks. The set of pre-test tasks is used to perform pre-test preparation operations, the set of intermediate test tasks is used to perform business operations on the computing platform, and the set of post-test tasks is used to perform post-test cleanup operations.

[0052] Optionally, the apparatus described above executes each set of test tasks according to the protocol information, and obtains the test results of each test task. The processing module is specifically used for:

[0053] Determine the number of task processes used to execute the test tasks;

[0054] Based on the number of task processes, the set of pre-test tasks, the set of intermediate test tasks, and the set of post-test tasks, the task execution strategy is determined. The task execution strategy is used to indicate the execution steps and distribution method of each test task on multiple task processes.

[0055] Based on the protocol information and task execution strategy, the test tasks of each task process are executed in parallel to obtain the test results of each test task.

[0056] Optionally, in the apparatus described above, the task execution strategy is determined based on the number of task processes, the set of pre-test tasks, the set of intermediate test tasks, and the set of post-test tasks. The processing module is specifically used for:

[0057] Based on the number of task processes, each test task in the pre-test task set is distributed to multiple task processes for parallel execution;

[0058] After the pre-test tasks are completed, each test task in the intermediate test task set is distributed to multiple task processes for parallel execution, based on the number of task processes.

[0059] After the intermediate test tasks are completed, each test task in the set of subsequent test tasks is distributed to any task process and executed in the order of distribution.

[0060] Optionally, in the apparatus described above, the test tasks of each task process are executed in parallel according to the protocol information and task execution strategy to obtain the test results of each test task. The processing module is further used for:

[0061] Retrieve the test tasks corresponding to the task processes in the task queue. The task queue includes multiple sets of test tasks to be executed.

[0062] Access permissions for test tasks are verified. After successful verification, the test task is executed according to the protocol information corresponding to the test task, and the corresponding test results are obtained and stored in the result queue. The result queue is used to store the test results of each test task.

[0063] Optionally, in the apparatus described above, after obtaining the test results of each test task, the apparatus further includes a generation module, which is specifically used for:

[0064] Obtain test information for each test task during execution;

[0065] Based on the test results and corresponding test information of each test task in the result queue, determine the first parameter and the second parameter. The first parameter is used to indicate the coverage of each test task to the called interface, and the second parameter is the pass rate of each test task.

[0066] A test report is generated based on the test results of each test task, the corresponding test information, the first parameter, and the second parameter.

[0067] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0068] The memory stores instructions that the computer executes;

[0069] The processor executes computer-executable instructions stored in memory to implement the method described in the first aspect.

[0070] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a computer, are used to implement the method described in the first aspect.

[0071] The computer-readable storage medium provided in this application embodiment can execute the technical solutions in the above method embodiments, and its beneficial effects are similar, so they will not be described again here.

[0072] Fifthly, this application provides a computer program product, including a computer program, which, when executed by a computer, is used to implement the method of the first aspect.

[0073] The computer program product provided in this application embodiment can execute the technical solutions in the above method embodiments, and its beneficial effects are similar, so they will not be described again here.

[0074] The multi-platform testing method, apparatus, electronic device, storage medium, and program product provided in this application obtains runtime configuration information containing platform type and test parameter information of multiple computing platforms, determines multiple sets of test tasks and the corresponding business types of each test task based on the test parameter information, determines the computing platform to be called and the corresponding communication protocol information to be called to execute each test task based on the platform type and business type, and finally executes each set of test tasks according to the protocol information to obtain test results. In the above method, electronic devices can dynamically determine the target platform and its communication protocol for each test task based on platform type and business type, achieving physical and logical decoupling between test tasks and underlying communication protocols. This allows for direct location and execution of cross-platform business process tests based on platform type and business type, rather than configuring separate test tools for each platform. Furthermore, by dividing test tasks into pre-process, intermediate, and post-process stages and employing a multi-process parallel execution mechanism, pre-process and intermediate tasks are distributed to multiple processes for parallel execution, while post-process tasks are distributed to a single process for sequential execution. This achieves efficient scheduling and rational resource utilization of test tasks, solving the problems of low concurrent execution efficiency and insufficient resource utilization in existing technologies. Moreover, this method is applicable to integrated testing scenarios for various types of computing platforms, such as supercomputing platforms, cluster management, and hybrid clouds, enhancing the versatility and scalability of the testing solution. While improving the accuracy and consistency of multi-platform testing, it significantly improves testing efficiency and the stability of multi-computing platform business operations, meeting the needs for integrated, standardized, and efficient multi-platform testing. Attached Figure Description

[0075] 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.

[0076] Figure 1 This is a schematic diagram of the system architecture provided for an embodiment of this application;

[0077] Figure 2 A flowchart illustrating a multi-platform testing method provided in an embodiment of this application;

[0078] Figure 3 A flowchart illustrating a method for generating a test report provided in an embodiment of this application;

[0079] Figure 4 A flowchart illustrating another multi-platform testing method provided in this application embodiment;

[0080] Figure 5 A flowchart illustrating a method for parallel execution of multiple processes provided in an embodiment of this application;

[0081] Figure 6A flowchart illustrating yet another multi-platform testing method provided in this application embodiment;

[0082] Figure 7 A schematic diagram illustrating the processing procedure of a configuration management layer provided in an embodiment of this application;

[0083] Figure 8 A schematic diagram illustrating the processing procedure of a test execution engine provided in an embodiment of this application;

[0084] Figure 9 This is a schematic diagram of the structure of a multi-platform testing device provided in an embodiment of this application;

[0085] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

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

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

[0088] With the widespread application of various computing resource management platforms such as supercomputing platforms, cluster management, and hybrid cloud, various computing platforms are deployed in large numbers to uniformly manage distributed computing resources and support the efficient flow of various businesses. Conducting unified, standardized, and efficient business function testing on multiple platforms has become a core requirement to ensure stable business operation and reduce testing costs.

[0089] The limitations of traditional single-tool, independent testing models are becoming increasingly apparent when dealing with multi-platform collaborative testing scenarios. This often leads to low testing efficiency, high operational complexity, and difficulties in consistently executing cross-platform tests. This places higher demands on the uniformity, efficiency, and standardization of multi-platform testing.

[0090] In related technologies, users need to configure test parameters and corresponding test cases for different computing platforms, and when executing test cases, they need to use the test tools corresponding to the platform to perform the tests.

[0091] However, in the above process, the testing requirements of a single business need to be completed collaboratively across multiple platforms. The testing tools, configuration methods, and execution logic of different computing platforms are significantly different, making it difficult to achieve unified and coherent cross-platform business testing. Although the platforms are logically independent, the underlying implementation of the testing tools is isolated from each other. If only a combination of independent tools is used for testing, it will lead to a large script maintenance overhead and a long cross-platform verification cycle.

[0092] For example, the technical problems of the traditional independent testing mode can be understood as the inability to achieve unified scheduling and efficient execution in multi-platform collaborative testing scenarios. For instance, cross-platform business testing requires frequent switching of testing tools and manual adjustment of configuration parameters. The parallel execution of post-test tasks with other tasks leads to resource conflicts, and multiple tools need to be combined to complete the test.

[0093] In the integration testing of multi-platform systems, it is usually necessary to build separate test environments, configure test parameters, and execute test tasks based on the characteristics of different platforms. However, due to the inherent defects of the traditional independent testing model: First, its architecture is based on a single platform corresponding to a single test tool, which makes it impossible for the system to achieve unified adaptation and scheduling across multiple platforms, and it is impossible to cover the testing requirements of multiple platforms through unified configuration. Second, resource conflicts are prone to occur during the execution of test tasks, and protocol adaptation is scattered, making it impossible to achieve unified management of multiple protocols. Third, configuration management lacks standardized processes, and environment switching and parameter adjustment require manual operation, which is inefficient and prone to errors. In addition, the lack of permission verification mechanisms during the testing process makes it easy for test anomalies caused by unauthorized access. These factors make it extremely difficult to achieve integrated and efficient testing of multiple platforms, making it difficult to guarantee the efficiency, standardization, and accuracy of multi-platform testing.

[0094] Therefore, this application provides a multi-platform testing method. It obtains runtime configuration information containing platform types and test parameter information for multiple computing platforms. Based on the test parameter information, it determines multiple sets of test tasks and the corresponding business types for each test task. Based on the platform type and business type, it determines the computing platform and corresponding communication protocol information required to execute each test task. Finally, it executes each set of test tasks according to the protocol information to obtain test results. By associating and dynamically adapting test tasks with platform types, business types, and protocol information, it achieves unified scheduling and coherent execution of cross-platform business processes. This method is applicable to the integration testing needs of various types of computing platforms such as supercomputing platforms, cluster management, and hybrid clouds, avoiding test process interruptions caused by platform differences and protocol heterogeneity, and significantly improving the completeness and execution efficiency of multi-platform testing.

[0095] Figure 1 For a schematic diagram of the system architecture provided in this application embodiment, please refer to [link / reference]. Figure 1This includes electronic devices and terminal devices. Electronic devices include multiple computing platforms and can be any device with on-device computing capabilities, such as servers and terminal devices.

[0096] The terminal device and the electronic device can communicate with each other. The terminal device can send test information to be tested to the electronic device, and the electronic device can receive the test information sent by the terminal device, process the test information, determine the computing platform required for the test information, and complete the cross-platform test operation.

[0097] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0098] Figure 2 This application provides a flowchart illustrating a multi-platform testing method, specifically as follows: Figure 2 As shown, the method includes the following steps:

[0099] S201. Obtain the runtime configuration information to be tested.

[0100] The execution subject of this application embodiment can be an electronic device or a multi-platform testing device installed in an electronic device. The multi-platform testing device can be implemented by software or by a combination of software and hardware.

[0101] The runtime configuration information includes platform types and test parameter information for multiple computing platforms. In other words, the runtime configuration information is used to uniformly describe the platform environment, runtime parameters, and permission information that the test depends on.

[0102] A computing platform is used to manage multiple computing resources. In other words, a computing platform is a system that can schedule and manage underlying physical or virtual computing resources (such as servers, virtual machines, containers, etc.).

[0103] For example, a computing platform can be a supercomputing platform, a cluster management platform, a hybrid cloud management platform, etc. Users can apply for, use, and release these resources through the application programming interface (API) or interface provided by the computing platform.

[0104] The platform type is used to indicate the category of the computing platform to be tested, and is used to distinguish computing platforms with different architectures, interface specifications, and communication methods, so as to match the corresponding protocols and execution logic in the future.

[0105] Test parameter information can be various general configuration information required during the test process. For example, test parameter information can include runtime information, environment parameters, etc.

[0106] In some embodiments, the electronic device may obtain the runtime configuration information to be tested based on the following implementation: obtaining the runtime configuration file input by the user, and parsing the runtime configuration file to obtain the platform type, test environment information and runtime information of the computing platform; determining the environment configuration information and permission configuration information corresponding to each computing platform based on the platform type, test environment information and runtime information; and determining the environment configuration information, permission configuration information, platform type and test parameter information as runtime configuration information.

[0107] The runtime configuration file can be written in a structured format (e.g., YAML) to centrally store all the basic configurations required for multi-platform testing. It supports multi-level inheritance and dynamic coverage. Users can centrally define various configuration items required for testing through this runtime configuration file, which is convenient for management and maintenance.

[0108] Test environment information refers to relevant information used to identify the type of environment in which the test takes place, such as test environment address, environment identifier, environment purpose, network partition, etc., which is used to distinguish different deployment environments such as development environment, test environment, and pre-production environment.

[0109] Runtime information refers to dynamic information related to the execution of test tasks. For example, runtime information may include the path to the test script to be executed, the location of data files, the log path, the result storage path, etc.

[0110] Environment configuration information is used to configure the testing environment of the computing platform. Specifically, it determines the connection address, access port, and call path of the current computing platform in the corresponding testing environment, ensuring correct access to the target testing environment.

[0111] Permission configuration information is used to configure access permissions for the computing platform. Specifically, it configures the role permissions required to access each computing platform, ensuring that test tasks can be executed within the legally authorized scope. For example, by defining the credential information required for different roles (e.g., administrators, regular users, visitors, etc.) to perform operations on the platform, and a matrix of role-API access relationships, permission verification is used in subsequent tests.

[0112] In some embodiments, the electronic device can load the basic configuration template for the platform from a predefined configuration template library based on the parsed platform type. Combining this with test environment information, it can extract the actual parameters corresponding to the environment from the template and, based on the role type specified in the runtime information, load the account credentials and permission list for that role from the permission configuration template. For example, for different types of computing platforms, it can automatically adapt to their specific configuration structures, generating complete environment configuration information and permission configuration information for the current platform, the current test environment, and the specified role, providing an accurate configuration foundation for subsequent permission verification and API calls.

[0113] In some embodiments, users can inject configuration parameters that need to be modified through dynamic parameter passing, configuration overriding, command line input, or interface modification. The electronic device reads and merges the dynamic parameters passed by the user at runtime, automatically updates and generates the modified runtime configuration file, and achieves real-time updating and flexible adjustment of runtime parameters without the need to manually edit the original configuration file.

[0114] Specifically, users can specify overridden items via command-line parameters, such as temporarily modifying the test environment identifier or timeout. These parameters are merged with the configuration file content during the configuration loading phase, achieving runtime overriding. Furthermore, the configuration file supports the use of variable placeholders, which the electronic device can automatically replace during parsing and processing, enabling flexible injection of dynamic parameters.

[0115] When a user modifies and saves the configuration file, the electronic device can detect the file change through a real-time monitoring mechanism, use a file locking mechanism to ensure safe reading and writing in a multi-process concurrent environment, and reload the configuration content to achieve hot updates of the configuration without restarting the test process. Furthermore, the configuration caching mechanism improves the efficiency of frequent access, providing flexible and efficient configuration management support for large-scale, multi-process test execution.

[0116] S202. Based on the test parameter information, determine multiple sets of test tasks and multiple business types corresponding to each test task.

[0117] Among them, test tasks are used to perform business tests on multiple computing platforms. In other words, a test task can be understood as a set of specific test operation instructions designed for scenarios such as the business functions and interface performance of the computing platform. It is the smallest execution unit for implementing business testing on multiple platforms. By executing these instructions, it is possible to verify whether the business processing capabilities of the computing platform meet expectations.

[0118] The business type is used to indicate the business domain or operation category to which the test task belongs. It is used to distinguish different types of test scenarios, clarify the verification objectives of the test task, and provide a basis for subsequent matching of the corresponding computing platform and communication protocol.

[0119] In some embodiments, the electronic device may determine multiple sets of test tasks based on test parameter information in the following manner: loading the corresponding test file according to the test parameter information; grouping the multiple test tasks according to the task identifier of each test task to obtain a set of pre-test tasks, a set of intermediate test tasks, and a set of post-test tasks.

[0120] The test file includes multiple test tasks and corresponding task identifiers. A test file is a pre-written script file describing the test logic. Each test case includes multiple test tasks, and task identifiers can be attached to the test tasks using decorators or function attributes.

[0121] Task identifiers are used to indicate the execution stage of a test task. Specifically, a task identifier can be a character, code, or label with stage characteristics; for example, a task identifier can be "before," "after," etc. This allows for quick differentiation of the execution order and stage affiliation of test tasks, providing a clear basis for task grouping.

[0122] The pre-test task set is used to perform preparatory operations before testing. In other words, the pre-test task set can be a collection of all preparatory test tasks that need to be completed before the formal execution of the test. These tasks can be used to set up the test environment and ensure test conditions are ready, such as initializing the computing platform environment, access permission authentication, platform connectivity testing, pre-allocating test resources, and calibrating test parameters.

[0123] Intermediate test task sets are used to execute business operations on the computing platform. In other words, intermediate test task sets can be a collection of test tasks used to verify the core business functions and performance of the computing platform. They are a core component of multi-platform testing, including test tasks directly related to the computing platform's business, such as computing resource scheduling, business task submission and execution, data interaction and transmission, and interface calls and responses.

[0124] The post-test task set is used to perform cleanup operations after testing. In other words, the post-test task set can be a collection of end-test tasks that need to be executed after the test is completed. These tasks are used to restore the computing platform to its initial state and ensure a clean test environment, such as test data cleanup, test resource release, computing platform state reset, and test log archiving.

[0125] In some embodiments, the electronic device can obtain test parameter information from the running configuration information, which includes information such as the test script path. Furthermore, it can scan a specified directory based on the test script path, filter out and load test files that meet the requirements, such as script files that start with "test_".

[0126] In some embodiments, the electronic device can traverse the test tasks in the loaded test files, determine the execution stage of each test task based on the task identifier carried by each test task, and classify and integrate test tasks belonging to the pre-stage to form a pre-test task set to ensure full coverage of pre-test preparation operations; classify and integrate test tasks belonging to the intermediate stage to form an intermediate test task set to focus on the core business verification of the computing platform; and classify and integrate test tasks belonging to the post-stage to form a post-test task set to ensure that no post-test closing operations are omitted.

[0127] If a task does not have an explicitly specified task identifier, it can be categorized into the intermediate test task set by default to ensure that all tasks are executed in an orderly manner. After grouping, the three sets are internally sorted according to the order in which the tasks appear in the file or the user-specified priority, laying the foundation for subsequent phased execution.

[0128] In some embodiments, when an electronic device determines the service type corresponding to each test task, each test task, in addition to carrying a task identifier, also specifies its service type through metadata, such as computing service or storage service. When the electronic device loads the test file and parses the test task, it extracts the service type information and stores it as an attribute of the test task object.

[0129] For test tasks that do not explicitly specify a business type, electronic devices can infer it based on the task name, module name, or default rules. For example, they can extract keyword A from the task name and automatically match it as business type A, or set a default business type for subsequent processes. In this way, the determined business type will be used in subsequent steps to match communication protocol information based on the platform type and business type, ensuring that test tasks of different business types can interact with the target platform using the correct protocol.

[0130] S203. Based on the platform type and business type, determine the multiple computing platforms that need to be called to execute each test task, as well as the protocol information required to communicate with each computing platform.

[0131] Protocol information describes the communication rules and formats followed when communicating with the computing platform, including but not limited to HyperText Transfer Protocol (HTTP), WebSocket protocol, Secure Shell (SSH) protocol, database protocols, etc.

[0132] In some embodiments, the electronic device can invoke the unified interface abstraction layer of the platform type corresponding to the current test task. This abstraction layer provides the same access specifications for different platforms and internally maintains the mapping relationship between different business types and API paths, request methods, and communication protocols under each platform.

[0133] Furthermore, based on the business type of the test task, the above mapping relationship is queried through the unified interface abstraction layer to parse out the target API information and basic protocol type corresponding to the business. Then, based on the parsed protocol type, the corresponding protocol parameter template is loaded from the predefined protocol template library, such as the timeout setting for the HTTP protocol and the authentication method for the SSH protocol. Afterwards, the placeholders in the template are replaced with the test environment parameters in the runtime configuration information (such as the access address and port number of the target computing platform) to generate complete and executable protocol information, which is then bound to the test task for subsequent execution phases.

[0134] S204. Execute each group of test tasks according to the protocol information and obtain the test results of each test task.

[0135] Test results can be a set of output data after each test task is completed. It is used to indicate the execution status of the test task and the business processing effect of the computing platform. Specifically, it includes but is not limited to the success / failure status of the test task, execution time, response parameters, error logs (if execution fails), business function verification results, etc., providing core basis for subsequent generation of test reports and analysis of computing platform performance.

[0136] In some embodiments, the electronic device may execute each set of test tasks according to protocol information based on the following implementation method to obtain the test results of each test task: determine the number of task processes used to execute the test tasks; determine the task execution strategy based on the number of task processes, the set of pre-test tasks, the set of intermediate test tasks, and the set of post-test tasks; and execute the test tasks of each task process in parallel according to the protocol information and the task execution strategy to obtain the test results of each test task.

[0137] The task process is used to carry out the execution of test tasks. It is an independent execution unit within the test system. The task process can receive distributed test tasks, establish communication with the target computing platform according to the protocol information, execute test operations and return the results. In the embodiments of this application, multiple task processes can realize the parallel execution of test tasks and improve test efficiency.

[0138] The task execution strategy is used to instruct the execution steps and distribution methods of each test task across multiple task processes. In other words, the task execution strategy defines how test tasks are allocated to processes at different stages, the order of execution, and the synchronization methods between processes, so as to ensure the correctness of the test process and the efficient use of resources.

[0139] In other words, the task execution strategy can be understood as a standardized execution rule for the number of task processes and the stage attributes (pre-test / intermediate / post-test) of test tasks. It clarifies the distribution objects, execution order, and parallel mode of various test tasks. In this way, system resources can be allocated reasonably, task execution conflicts can be avoided, and the test process can be carried out in an orderly and efficient manner, while meeting the different execution needs of pre-test, intermediate, and post-test tasks.

[0140] In some embodiments, the electronic device can read a preset concurrent process count configuration item from the test parameter information of the runtime configuration information. This configuration item can be specified by the user in the runtime configuration file or command-line parameters. For example, the user can set "concurrency=8" in the runtime configuration file to indicate that 8 task processes are executed in parallel, or dynamically override the number of task processes in the command line by using "processes=16".

[0141] If not explicitly configured, the electronic device can determine the default number of task processes based on the current number of CPU cores. For example, it can be set to twice the number of CPU cores to maximize execution efficiency when resources are sufficient. Thus, before starting test execution, a corresponding number of task processes are created based on the final determined number of processes, and task queues and result queues are initialized for inter-process communication. This fully utilizes system resources to improve concurrency efficiency while avoiding resource contention caused by too many processes.

[0142] In some embodiments, the electronic device may determine a task execution strategy based on the number of task processes, a set of pre-test tasks, a set of intermediate test tasks, and a set of post-test tasks, according to the following implementation: Based on the number of task processes, each test task in the pre-test task set is distributed to multiple task processes for parallel execution; after the pre-test tasks are completed, each test task in the intermediate test task set is distributed to multiple task processes for parallel execution; after the intermediate test tasks are completed, each test task in the post-test task set is distributed to any task process, and the test task is executed in the order of distribution.

[0143] In some embodiments, the electronic device distributes all test tasks in the pre-test task set equally according to the number of task processes or based on task load estimation, so that each task process is assigned approximately an equal number of pre-test tasks, and starts multi-process parallel execution. If any task process completes the execution of a test task, the next test task can be immediately distributed to ensure the continuity of process operation.

[0144] After the electronic device determines that all pre-test tasks have been completed through the process synchronization mechanism, it distributes the test tasks in the intermediate test task set to multiple task processes for parallel execution in the same way, and waits for all intermediate test tasks to complete.

[0145] Finally, after all intermediate tasks have been completed, all test tasks in the set of post-test tasks are distributed to the same task process (e.g., the first process or a specified process) and executed sequentially according to the order of the post-test tasks in the set, in order to avoid resource contention or state conflicts caused by multiple processes performing cleanup operations at the same time.

[0146] Throughout the process, the electronic device distributes tasks to each process through a task queue. After each process completes its execution, it puts the results into a result queue. The main process then collects all test results from the result queue.

[0147] In some embodiments, when executing pre-test tasks or intermediate test tasks, each task process establishes communication with the target computing platform based on the pre-test task or intermediate test task distributed to it and the corresponding protocol information. First, it completes permission verification (based on the permission configuration information determined in S201), and then performs preparatory operations such as environment initialization, connectivity detection, and resource pre-allocation. After the execution is completed, each process reports the execution results of the pre-test / intermediate test tasks. After ensuring that all tasks have been completed and there are no serious abnormalities, it enters the post-test task execution stage.

[0148] When executing post-test tasks, the individual task process carrying the post-test tasks executes each post-test task in the order of distribution. It communicates with the computing platform in conjunction with the protocol information to complete the cleanup of test data, release of resources, archive of logs, reset of platform status and other sorting operations. The results are recorded in a timely manner after each post-test task is completed. After all post-test tasks are completed, the results of all pre-test, intermediate and post-test tasks are summarized to form the final test results of each test task.

[0149] In some embodiments, the electronic device may, based on the following implementation method, execute the test tasks of each task process in parallel according to the protocol information and the task execution strategy, and obtain the test results of each test task: obtain the test tasks corresponding to the task processes in the task queue; perform access permission verification on the test tasks, and after the verification is passed, execute the test tasks according to the protocol information corresponding to the test tasks, obtain the corresponding test results and store them in the result queue, which is used to store the test results of each test task.

[0150] The task queue includes multiple sets of test tasks to be executed. The task queue is used to store each test task and sort them according to the task distribution priority. It provides unified task distribution to each idle task process, realizes orderly scheduling and load balancing of tasks, and ensures that each task process can efficiently obtain the tasks to be executed, avoiding task omission or duplicate execution.

[0151] In some embodiments, after completing the currently assigned test task, each task process immediately releases some of the system resources it occupies and synchronously sends a task acquisition request to the task queue. The task queue monitors the status of each task process in real time. When it detects that a task process is in an idle state, it prioritizes assigning the test task that is ranked first in the queue and is suitable for that process (combining task type and process load) to that idle process.

[0152] If there are still tasks waiting to be executed in the task queue, the idle process acquires and executes a task, then repeats the above process until all tasks in the task queue have been completed. This ensures that each task process remains running, maximizing the utilization of system resources and preventing process idleness. Simultaneously, the task queue employs a locking mechanism to ensure data security when multiple processes concurrently acquire tasks, ensuring that each task is acquired by only one process once.

[0153] In some embodiments, the electronic device can pre-extract the permission configuration information (including identity credentials, authentication keys, role permissions, etc.) corresponding to each computing platform determined in S201, and associate and bind it with each test task. After the task process obtains the test task, it extracts the permission verification information corresponding to the test task, as well as the permission configuration requirements of the computing platform that the task needs to call; then, it compares the extracted permission verification information with the preset permission configuration information, and the verification content includes whether the identity credentials are valid, whether the access permissions match, and whether the operation scope complies with the permission regulations.

[0154] If all validation items pass, the permission validation is deemed successful, and subsequent test tasks can be executed. If any validation item fails, the permission validation is deemed unsuccessful, the execution of the test task is terminated, a permission validation failure log is recorded, and the failure result is stored in the result queue. At the same time, a prompt message is provided to facilitate technical personnel in troubleshooting permission configuration issues.

[0155] In some embodiments, after successful permission verification, the task process obtains the protocol information bound to the test task, which includes parameters such as protocol type, API path, and authentication credentials. Based on the protocol information, it calls the platform adaptation layer's unified interface to convert the task into an actual request for the target platform.

[0156] For example, for HTTP requests, a complete HTTP request message can be constructed based on the protocol information, an authentication header can be added, and the message can be sent to the target computing platform over the network. For SSH tasks, an SSH connection will be established and the corresponding commands will be executed. After receiving the response data from the target computing platform, it will be parsed into a standard format and returned to the task process. If an exception occurs during execution (e.g., network timeout, server error), the task process will decide whether to re-execute the task according to a preset retry policy. If the number of retries is exceeded, the failure result will be recorded and placed in the result queue.

[0157] The multi-platform testing method, apparatus, electronic device, storage medium, and program product provided in this application obtains runtime configuration information containing platform type and test parameter information of multiple computing platforms, determines multiple sets of test tasks and the corresponding business types of each test task based on the test parameter information, determines the computing platform to be called and the corresponding communication protocol information to be called to execute each test task based on the platform type and business type, and finally executes each set of test tasks according to the protocol information to obtain test results. In the above method, electronic devices can dynamically determine the target platform and its communication protocol for each test task based on platform type and business type, achieving physical and logical decoupling between test tasks and underlying communication protocols. This allows for direct location and execution of cross-platform business process tests based on platform type and business type, rather than configuring separate test tools for each platform. Furthermore, by dividing test tasks into pre-process, intermediate, and post-process stages and employing a multi-process parallel execution mechanism, pre-process and intermediate tasks are distributed to multiple processes for parallel execution, while post-process tasks are distributed to a single process for sequential execution. This achieves efficient scheduling and rational resource utilization of test tasks, solving the problems of low concurrent execution efficiency and insufficient resource utilization in existing technologies. Moreover, this method is applicable to integrated testing scenarios for various types of computing platforms, such as supercomputing platforms, cluster management, and hybrid clouds, enhancing the versatility and scalability of the testing solution. While improving the accuracy and consistency of multi-platform testing, it significantly improves testing efficiency and the stability of multi-computing platform business operations, meeting the needs for integrated, standardized, and efficient multi-platform testing.

[0158] Based on any of the above embodiments, the method for generating a complete test report by the electronic device after obtaining the test results of each test task in the above processing method will be described in detail.

[0159] Figure 3 This is a flowchart illustrating a method for generating a test report according to an embodiment of this application. Please refer to [link / reference]. Figure 3 The method includes the following steps:

[0160] S301. Obtain test information during the execution of each test task.

[0161] Test information can be detailed process data generated during the execution of each test task.

[0162] S302. Based on the test results and corresponding test information of each test task in the result queue, determine the first parameter and the second parameter.

[0163] The first parameter is used to indicate the coverage of the called interfaces by each test task. That is, the first parameter is the ratio (usually presented as a percentage) of the number of computing platform interfaces actually called by the test task to the total number of interfaces that the test task is supposed to call. It can be used to judge the completeness of the coverage of the computing platform interfaces by the test task and reflect the comprehensiveness of the test. For example, if a test task is supposed to call 5 interfaces and actually successfully calls 4, then the first parameter is 80%.

[0164] The second parameter is the pass rate of each test task. That is, the second parameter is the ratio (usually presented as a percentage) of the number of successfully executed test tasks to the total number of test tasks included in the summary. It can be used to measure the overall execution effect of the test tasks and the business stability of the computing platform. For example, if a total of 100 test tasks are executed, and 95 of them are successfully executed, then the second parameter is 95%.

[0165] In some embodiments, the electronic device extracts the test results of all test tasks from the result queue, distinguishes between tasks that were successfully executed, failed, or terminated, and matches the test information corresponding to each test task, extracting the list of interfaces that are preset to be called and the record of interfaces that are actually called for each test task.

[0166] For the first parameter, the first parameter of a single test task is calculated by summing the number of valid interfaces actually called by each test task (excluding failed or invalid interfaces) and dividing it by the total number of interfaces that the task is required to call.

[0167] For the second parameter, the total number of test tasks involved in the execution (excluding unexecuted tasks) is summarized, along with the number of tasks that were successfully executed. The overall test task execution pass rate is calculated by dividing the number of successful tasks by the total number of tasks. Alternatively, tasks can be grouped into pre-, mid-, and post-task groups, and the second parameter of each group can be calculated separately. Finally, the complete first and second parameters are determined to ensure the accuracy and relevance of the parameter calculations.

[0168] S303. Generate a test report based on the test results of each test task, the corresponding test information, the first parameter, and the second parameter.

[0169] The test report is used to present the overall execution status and quality evaluation results of this test in a structured and visual format, including but not limited to detailed execution records of each test task, API coverage analysis, pass rate trends, details of failed tasks, error log aggregation, and other information.

[0170] In some embodiments, the electronic device can organize and aggregate the test results and information of all test tasks in a unified format, such as converting them into intermediate data files in JSON or XML format. Then, by invoking a report generation engine (e.g., the Allure framework), the aggregated data is input into the engine, specifying the report template and configuration parameters. The report generation engine renders the data into a structured HTML page based on the template, including an overview dashboard, functional module distribution, test case list, and details of failed test cases. Furthermore, the calculated first parameter (API coverage) and second parameter (test pass rate) are embedded in the comprehensive dashboard on the report's homepage, and the coverage distribution and pass rate changes are displayed in chart form across different dimensions.

[0171] The multi-platform testing method, apparatus, electronic device, storage medium, and program product provided in this application obtain test information during the execution of each test task, determine a first parameter to indicate the coverage of the called interface and a second parameter to indicate the pass rate of the test result based on the test results and corresponding test information of each test task in the result queue, and finally generate a complete test report based on the test results, test information, first parameter, and second parameter. In the above method, electronic devices can use the test information from the entire test task execution process and dynamically deduce the two core evaluation parameters of interface coverage and execution pass rate based on the test results. This enables multi-dimensional and refined analysis of test results across multiple platforms, providing a comprehensive and intuitive presentation of the execution status, interface coverage, and overall test pass rate of each test task. This not only provides testers with a core basis for quickly troubleshooting business anomalies and optimizing test case design, but also accurately determines the business processing capabilities and test coverage quality of each computing platform. It effectively avoids the limitations of existing technologies that rely solely on test success or failure status to judge test effectiveness, failing to accurately determine interface coverage completeness and test pass rate. This improves the accuracy and comprehensiveness of test result analysis. Furthermore, this method is applicable to integration testing scenarios for various types of computing platforms, such as supercomputing platforms, cluster management, and hybrid clouds, enhancing the readability and traceability of test reports. While improving the accuracy of test result analysis, it significantly enhances the quality assurance capabilities of cross-platform integration testing.

[0172] Figure 4 This is a flowchart illustrating another multi-platform testing method provided in an embodiment of this application. Please refer to... Figure 4 The method includes the following steps:

[0173] S401. Obtain the runtime configuration information to be tested.

[0174] The runtime configuration information includes platform types and test parameter information for multiple computing platforms, which are used to manage multiple computing resources.

[0175] It should be noted that the execution process of S401 above can be found in S201, and will not be repeated here.

[0176] S402. Load the corresponding test file according to the test parameter information.

[0177] The test file includes multiple test tasks and corresponding task identifiers, with the task identifiers indicating the execution stage of the test task.

[0178] S403. Based on the task identifier of each test task, group multiple test tasks to obtain a set of pre-test tasks, a set of intermediate test tasks, and a set of post-test tasks.

[0179] The pre-test task set is used to perform pre-test preparation operations, the intermediate test task set is used to perform business operations on the computing platform, and the post-test task set is used to perform post-test cleanup operations.

[0180] S404. Determine the multiple business types corresponding to each test task.

[0181] It should be noted that the execution process of S402-S404 above can be found in S202, and will not be repeated here.

[0182] S405. Based on the platform type and business type, determine the multiple computing platforms that need to be called to execute each test task, as well as the protocol information required to communicate with each computing platform.

[0183] It should be noted that the execution process of S405 above can be found in S203, and will not be repeated here.

[0184] S406. Determine the number of task processes used to execute the test task.

[0185] S407. Based on the number of task processes, distribute each test task in the pre-test task set to multiple task processes for parallel execution.

[0186] S408. After the pre-test task is completed, according to the number of task processes, each test task in the intermediate test task set is distributed to multiple task processes for parallel execution.

[0187] S409. After the intermediate test tasks are completed, each test task in the set of subsequent test tasks is distributed to any task process and executed in the order of distribution.

[0188] S410. Based on the protocol information and task execution strategy, execute the test tasks of each task process in parallel to obtain the test results of each test task.

[0189] It should be noted that the execution process of S406-S410 above can be found in S204, and will not be repeated here.

[0190] S411. Obtain test information for each test task during execution.

[0191] S412. Based on the test results and corresponding test information of each test task in the result queue, determine the first parameter and the second parameter.

[0192] The first parameter indicates the coverage of the called interface by each test task, and the second parameter is the pass rate of each test task.

[0193] S413. Generate a test report based on the test results of each test task, the corresponding test information, the first parameter, and the second parameter.

[0194] It should be noted that the execution process of S411-S413 can be found in S301-S303, and will not be repeated here.

[0195] The multi-platform testing methods, devices, electronic equipment, storage media, and program products provided in this application achieve unified support for multiple platforms through a unified interface abstraction and adapter pattern. They provide a unified access interface for different platforms, shielding the differences between platforms and achieving true multi-platform integration testing. By adopting YAML-formatted configuration files and a dynamic parameter injection mechanism, flexible configuration management is achieved, greatly improving testing flexibility. Based on a multi-process concurrent execution mechanism, and through task queue and process pool management, efficient concurrent execution of test cases is achieved, supporting dynamic adjustment of the number of concurrent processes to optimize resource utilization and significantly improve testing efficiency. Through a permission matrix and role mapping mechanism, automated verification of API permissions is achieved, automatically verifying permissions for each API. This approach generates access test cases for different roles and produces detailed permission verification reports to ensure system security. Furthermore, by integrating the Allure framework, it implements a unified report generation mechanism to automatically generate detailed test reports containing execution steps, log information, and performance metrics. It also provides coverage calculation and pass rate analysis to improve the reliability and effectiveness of multi-platform testing. In addition, this method achieves automated testing across multiple platforms, addressing existing technologies' shortcomings in areas such as platform support (single platform support), protocol adaptation (support only specific protocol information), configuration management (manual configuration modification is required for switching between multiple environments), concurrent execution (insufficient concurrency efficiency and resource utilization), permission verification, and business logic (difficulty in handling cross-platform business processes and complex business logic).

[0196] Figure 5 This is a flowchart illustrating a method for parallel execution of multiple processes provided in an embodiment of this application. Please refer to... Figure 5 The method includes the following steps:

[0197] The specific process is as follows: At the start of test execution, the main process first creates a task queue and a result queue. The task queue is used to store all test tasks to be executed, and the result queue is used to collect the test results returned by each worker process after completion. Subsequently, the main process starts multiple worker processes (worker process 1, worker process 2, ..., worker process N) according to the configured number of concurrent processes. These worker processes run independently and wait together to obtain test tasks from the task queue.

[0198] After each worker process starts, it continuously retrieves test tasks from the task queue (execute test task 1, execute test task 2, ..., execute test task N), and sequentially calls multiple internal functional modules to complete the test execution. Specifically, the permission verification module (permission configuration information) verifies whether the current role has permission to execute the operation; after the verification is successful, the API request module is called to send a request to the target computing platform according to the protocol information bound to the test task; after receiving the response, the parameter verification module asserts and verifies the returned result; finally, the result recording module encapsulates the test results of this execution (including execution status, response data, time consumption, etc.) and puts them into the result queue.

[0199] Furthermore, while creating worker processes, the main process continuously receives execution results returned by each worker process from the result queue. Once all test tasks are completed, the main process, based on the collected complete test results, calls the report generation module to generate the final test report. Through this process, decoupled distribution of test tasks, parallel execution of multiple processes, modular processing, and unified collection of results are achieved, effectively improving the execution efficiency and resource utilization of multi-platform testing.

[0200] Figure 6 This is a flowchart illustrating yet another multi-platform testing method provided in an embodiment of this application. Please refer to... Figure 6 This method employs a layered architecture design, consisting of a configuration management layer, an execution engine layer, a platform adaptation layer, a business logic layer, and a report presentation layer. These layers interact through standardized interfaces, achieving a highly cohesive and loosely coupled system architecture.

[0201] The configuration management layer is responsible for managing all test-related configuration information and is the data-driven core of the entire system. This layer uses a configuration parser to parse user-input YAML-formatted runtime configuration information, obtaining basic information such as the computing platform type, test environment information, and runtime parameters. It supports nested configurations and reference parsing, and uses a configuration validator to verify the completeness and correctness of configuration files, ensuring configuration validity. It also dynamically loads the corresponding environment and role configuration files based on the platform type.

[0202] Furthermore, the configuration management layer supports multi-level configuration inheritance and dynamic injection of runtime parameters (parameter injector), supports command-line parameters to override configuration file parameters, allowing users to modify configurations in real time via command-line parameters, and enables rapid switching between multiple environments via an environment switcher, supporting dynamic switching between test, pre-production, and production environments; it employs a file locking mechanism to ensure secure access to configuration files in a multi-process environment, and improves configuration reading efficiency through a caching mechanism, providing a unified, flexible, and dynamically adjustable configuration data foundation for the entire testing process.

[0203] The execution engine layer is responsible for scheduling, executing, and monitoring test cases, serving as the system's control center. Built on the pytest framework, this layer distributes test tasks to multiple processes via task queues, enabling concurrent execution. The execution engine layer supports step-by-step execution of test tasks, dividing test cases into sets of pre-, mid-, and post-stages based on task identifiers and scheduling them in sequence. During execution, the engine layer monitors the execution status of each task process in real time through a status monitor, including execution progress, error summaries, and performance metrics. It also supports a failure rerun mechanism, redistributing failed test tasks according to a preset strategy to improve test stability and reliability.

[0204] The platform adaptation layer is responsible for enabling unified access to different computing platforms through a unified interface abstraction, and is the core abstraction layer of the system. This layer employs the adapter and decorator patterns to provide a unified interface access method for different types of platforms such as supercomputing platforms, cluster management platforms, and hybrid cloud platforms. It dynamically creates platform objects using the factory pattern. Internally, the platform adaptation layer automatically maps API paths to business models, parses the corresponding target API information based on the business type of the test task, and supports transparent adaptation of multiple communication protocols such as HTTP, WebSocket, SSH, and databases through protocol adapters. This shields the protocol and interface differences between different platforms, providing a unified request processing interface for the upper layer. Furthermore, it uses request handlers to uniformly process API requests, supporting authentication, parameter processing, and error handling.

[0205] The business logic layer is responsible for encapsulating platform-specific business logic and providing a unified business operation interface. This layer uses a business model-driven approach to encapsulate complex business operations into simple interface calls. It employs the strategy pattern to flexibly handle different business scenarios, enabling parameterized configuration of business scenarios. The template method pattern solidifies the business process framework, and data classes encapsulate business objects, allowing test cases to be written in business language rather than technical language. Furthermore, this layer supports configurable business logic, allowing dynamic adjustments to business behavior based on configuration, and enabling the combination and reuse of business processes.

[0206] The report presentation layer is responsible for collecting, analyzing, and visualizing test results. During test execution, this layer collects detailed information such as execution logs, request-response data, assertion results, and execution time for each test task, storing this information in structured JSON format. After test execution, the report presentation layer calculates API coverage and pass rate based on the collected test results. Coverage is calculated by comparing the actual API calls with the platform's complete API list, and pass rate is calculated by the percentage of successful test tasks. Finally, this layer integrates the Allure framework to render the test data into a detailed HTML test report, including test steps, performance metrics, coverage charts, and failure analysis, and provides online viewing and download functionality.

[0207] The specific process is as follows: Developers, operations and maintenance personnel, testers and other users submit test configuration information and execution instructions to the configuration management layer through the API interface, configuration file interface or command line interface of the interface layer; after parsing the configuration information, the configuration management layer distributes it to the report generation module, permission verification module, test execution engine and pre-built cleanup module. Among them, the permission verification module first completes the access permission verification of the test task, the test execution engine creates a task queue based on the configuration and schedules multiple processes to execute the test, the pre-built cleanup module is responsible for the pre-test environment initialization and post-test resource reclamation, and the report generation module is used to summarize the test results and process data.

[0208] During test execution, the test execution engine layer connects to multiple platform types of computing platforms such as OpenAPI, Mix, GridView, and SCNET through the platform adapter. Furthermore, through the protocol adaptation layer, it transparently adapts to various communication protocol information such as HTTP, WebSocket, SSH, and databases, achieving standardized interaction with the target computing platform and shielding the differences between the underlying platform and protocols.

[0209] Furthermore, the configuration information, test data, execution results, and report content of the entire testing process are persistently stored in the configuration file storage, test data storage, test result storage, and report storage modules of the data storage layer, respectively, to ensure data traceability. In addition, by integrating external systems such as Allure reporting system, CI / CD system, and monitoring system, the system can realize the visualization of test reports, the automated integration of test processes, and the real-time monitoring of system status, thus completing the closed loop of the entire multi-platform testing process.

[0210] The multi-platform testing methods, devices, electronic devices, storage media, and program products provided in this application, through unified interface abstraction and adapter patterns, and based on a unified interface design for multi-protocol adaptation, can simultaneously manage multiple different types of platforms, avoiding the complexity of maintaining multiple independent testing tools in traditional testing. Based on a multi-process concurrent execution mechanism, through task queues and intelligent scheduling algorithms, it achieves efficient concurrent execution of test cases, optimizing resource utilization. By automatically generating access test cases for different roles for each API, generating detailed permission verification reports, and supporting multi-dimensional report analysis, it provides a more comprehensive evaluation of test quality. Through the implementation of the automated testing system, the workload of manual testing is significantly reduced, testing efficiency is improved, and the efficient concurrent execution mechanism and resource management optimize the utilization efficiency of hardware resources, reducing the hardware investment requirements of the testing environment. Through comprehensive automated testing, the testing quality and reliability of software products are improved.

[0211] Figure 7 A schematic diagram illustrating the processing procedure of a configuration management layer provided in this application embodiment, such as... Figure 7 As shown, the process is as follows: multiple YAML-formatted runtime configuration files provided by various configuration sources serve as the input data source for configuration management. Subsequently, a YAML parser uniformly parses the configuration information, distributing the structured configuration data to a parameter injector, configuration validator, and environment switcher for layered processing. The parameter injector injects and overrides runtime dynamic parameters, the configuration validator verifies the legality and completeness of the configuration, and the environment switcher switches and adapts configurations to different test environments based on testing requirements. The processed configuration data enters the configuration manager, where a configuration caching module enables efficient storage and fast access to configuration information. A configuration mapping module establishes the association between configuration items and business modules. A dynamic parameter module supports real-time adjustment and updating of runtime parameters. Finally, a configuration update module pushes the latest configuration to downstream business modules such as the test execution engine, platform adapter, permission validator, and report generator, completing the entire configuration management and application process and providing stable and flexible configuration support for multi-platform testing.

[0212] Figure 8 A schematic diagram illustrating the processing procedure of a test execution engine provided in this application embodiment, as shown below. Figure 8As shown, the test execution engine is responsible for scheduling, executing, and collecting test cases. This engine employs a multi-process concurrent execution mechanism, significantly improving testing efficiency. It primarily uses a task scheduler to distribute and schedule test tasks, supporting load balancing; a concurrency controller to control the number of concurrently executing processes, avoiding resource contention; a status monitor to monitor test execution status in real time, providing execution progress and error summaries; and a result collector to collect test execution results, including execution logs, error messages, and performance metrics.

[0213] The specific process is as follows: In the task scheduling layer, the task queue generator constructs a queue of tasks to be executed, the task dispatcher distributes the tasks to each task process in the concurrent execution layer, and the process pool manager is responsible for the creation, scheduling and resource management of task processes (worker process 1, worker process 2, ..., worker process N). The status monitor monitors the entire link status of task distribution, process operation and test execution. Subsequently, after each process in the concurrent execution layer obtains a task, it passes the task to the test case executor in the test execution layer. The test case executor executes each set of test tasks (pre-test cases, intermediate test cases and post-test cases) in sequence according to the preset stages to ensure the orderliness and completeness of the test process.

[0214] Finally, at the result collection layer, the execution results of each test task are uniformly summarized by the result collector and transmitted to the result processor for standardized processing, generating a detailed test report in Allure format. By analyzing the test results, the pass rate and API test coverage are obtained, and the test coverage is analyzed. The result processor, in conjunction with the error handling module, identifies execution exceptions and failed test cases and triggers a rerun mechanism to retry failed test cases. At the same time, the status monitor synchronously collects the status data of the result processing and rerun process, realizing a closed loop and traceability of the entire test execution process.

[0215] Figure 9 This is a schematic diagram of the structure of a multi-platform testing device provided in an embodiment of this application, as shown below. Figure 9 As shown, the device 90 includes: an acquisition module 91, a first determination module 92, a second determination module 93, and a processing module 94.

[0216] The acquisition module 91 is used to acquire the runtime configuration information to be tested. The runtime configuration information includes the platform type and test parameter information of multiple computing platforms. The computing platform is used to manage multiple computing resources.

[0217] The first determining module 92 is used to determine multiple sets of test tasks and multiple business types corresponding to each test task based on test parameter information. The test tasks are used to perform business tests on multiple computing platforms.

[0218] The second determining module 93 is used to determine, based on the platform type and business type, the multiple computing platforms to be invoked for executing each test task, as well as the protocol information required for communicating with each computing platform;

[0219] Processing module 94 is used to execute each group of test tasks according to the protocol information and obtain the test results of each test task.

[0220] The multi-platform testing device provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0221] In one possible implementation, the acquisition module 91 is specifically used for:

[0222] Obtain the runtime configuration file input by the user, parse and process the runtime configuration file to obtain the platform type, test environment information and runtime information of the computing platform;

[0223] Based on the platform type, test environment information, and runtime information, determine the environment configuration information and permission configuration information corresponding to each computing platform. The environment configuration information is used to configure the test environment of the computing platform, and the permission configuration information is used to configure the access permissions of the computing platform.

[0224] The environment configuration information, permission configuration information, platform type, and test parameter information are determined as the runtime configuration information.

[0225] In one possible implementation, the first determining module 92 is specifically used for:

[0226] Based on the test parameter information, load the corresponding test file. The test file includes multiple test tasks and corresponding task identifiers. The task identifiers are used to indicate the execution stage of the test task.

[0227] Based on the task identifier of each test task, multiple test tasks are grouped to obtain a set of pre-test tasks, a set of intermediate test tasks, and a set of post-test tasks. The set of pre-test tasks is used to perform pre-test preparation operations, the set of intermediate test tasks is used to perform business operations on the computing platform, and the set of post-test tasks is used to perform post-test cleanup operations.

[0228] In one possible implementation, the processing module 94 is specifically used for:

[0229] Determine the number of task processes used to execute the test tasks;

[0230] Based on the number of task processes, the set of pre-test tasks, the set of intermediate test tasks, and the set of post-test tasks, the task execution strategy is determined. The task execution strategy is used to indicate the execution steps and distribution method of each test task on multiple task processes.

[0231] Based on the protocol information and task execution strategy, the test tasks of each task process are executed in parallel to obtain the test results of each test task.

[0232] In one possible implementation, the processing module 94 is specifically used for:

[0233] Based on the number of task processes, each test task in the pre-test task set is distributed to multiple task processes for parallel execution;

[0234] After the pre-test tasks are completed, each test task in the intermediate test task set is distributed to multiple task processes for parallel execution, based on the number of task processes.

[0235] After the intermediate test tasks are completed, each test task in the set of subsequent test tasks is distributed to any task process and executed in the order of distribution.

[0236] In one possible implementation, the processing module 94 is further configured to:

[0237] Retrieve the test tasks corresponding to the task processes in the task queue. The task queue includes multiple sets of test tasks to be executed.

[0238] Access permissions for test tasks are verified. After successful verification, the test task is executed according to the protocol information corresponding to the test task, and the corresponding test results are obtained and stored in the result queue. The result queue is used to store the test results of each test task.

[0239] In one possible implementation, the apparatus further includes a generation module, which is specifically used for:

[0240] Obtain test information for each test task during execution;

[0241] Based on the test results and corresponding test information of each test task in the result queue, determine the first parameter and the second parameter. The first parameter is used to indicate the coverage of each test task to the called interface, and the second parameter is the pass rate of each test task.

[0242] A test report is generated based on the test results of each test task, the corresponding test information, the first parameter, and the second parameter.

[0243] The multi-platform testing device provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0244] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 10 As shown, the electronic device 1000 may include at least one processor 1001 and a memory 1002.

[0245] The memory 1002 is used to store programs. Specifically, the program may include program code, which includes computer-executable instructions.

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

[0247] The processor 1001 is used to execute computer execution instructions stored in the memory 1002 to implement the method described in the foregoing method embodiments. The processor 1001 may be a CPU, an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0248] Optionally, the electronic device 1000 may also include a communication interface 1003. In specific implementations, if the communication interface 1003, memory 1002, and processor 1001 are implemented independently, they can be interconnected via a bus to complete communication. The bus can be an industry-standard architecture (ISA) bus, a peripheral component (PCI) bus, or an extended industry standard architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc., but this does not imply that there is only one bus or one type of bus.

[0249] Optionally, in a specific implementation, if the communication interface 1003, memory 1002 and processor 1001 are integrated on a single chip, then the communication interface 1003, memory 1002 and processor 1001 can communicate through an internal interface.

[0250] The electronic device in this embodiment can be used to execute the technical solutions of the above method embodiments. The specific implementation methods and technical effects are similar, and will not be repeated here.

[0251] This application provides a computer-readable storage medium, which may include various media capable of storing computer-executable instructions, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), RAM, a disk, or an optical disk. Specifically, the computer-readable storage medium stores computer-executable instructions, which, when executed by a computer, cause the technical solution shown in the above method embodiment to be executed. The specific implementation and technical effects are similar and will not be repeated here.

[0252] This application provides a computer program product, including a computer program. When the computer program is executed by a computer, the technical solution shown in the above method embodiment is executed. The specific implementation method and technical effect are similar, and will not be repeated here.

[0253] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0254] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0255] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0256] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

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

[0258] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0259] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed 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 examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0260] 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 multi-platform testing method, characterized in that, include: Obtain the runtime configuration information to be tested, which includes platform types and test parameter information for multiple computing platforms, wherein the computing platforms are used to manage multiple computing resources; Based on the test parameter information, multiple sets of test tasks and multiple business types corresponding to each test task are determined. The test tasks are used to perform business tests on multiple computing platforms. Based on the platform type and the business type, determine the multiple computing platforms to be invoked to execute each test task, as well as the protocol information required to communicate with each computing platform; According to the protocol information, each group of test tasks is executed, and the test results of each test task are obtained.

2. The method of claim 1, wherein, Obtain the runtime configuration information to be tested, including: Obtain the runtime configuration file input by the user, and parse the runtime configuration file to obtain the platform type, test environment information and runtime information of the computing platform; Based on the platform type, the test environment information, and the operation information, determine the environment configuration information and permission configuration information corresponding to each computing platform. The environment configuration information is used to configure the test environment of the computing platform, and the permission configuration information is used to configure the access permissions of the computing platform. The environment configuration information, the permission configuration information, the platform type, and the test parameter information are determined as the runtime configuration information.

3. The method of claim 1, wherein, Based on the test parameter information, multiple sets of test tasks are determined, including: Based on the test parameter information, load the corresponding test file. The test file includes multiple test tasks and corresponding task identifiers. The task identifiers are used to indicate the execution stage of the test task. Based on the task identifier of each test task, the multiple test tasks are grouped to obtain a pre-test task set, an intermediate test task set, and a post-test task set. The pre-test task set is used to perform pre-test preparation operations, the intermediate test task set is used to perform business operations on the computing platform, and the post-test task set is used to perform post-test cleanup operations.

4. The method of claim 3, wherein, Based on the protocol information, each group of test tasks is executed, and the test results of each test task are obtained, including: Determine the number of task processes used to execute the test tasks; Based on the number of task processes, the set of pre-test tasks, the set of intermediate test tasks, and the set of post-test tasks, a task execution strategy is determined. The task execution strategy is used to indicate the execution steps and distribution methods of each test task on multiple task processes. Based on the protocol information and the task execution strategy, the test tasks of each task process are executed in parallel to obtain the test results of each test task.

5. The method of claim 4, wherein, Based on the number of task processes, the set of pre-test tasks, the set of intermediate test tasks, and the set of post-test tasks, a task execution strategy is determined, including: Based on the number of task processes, each test task in the pre-test task set is distributed to multiple task processes for parallel execution; After the pre-test task is completed, each test task in the intermediate test task set is distributed to multiple task processes for parallel execution, according to the number of task processes. After the intermediate test task is completed, each test task in the set of subsequent test tasks is distributed to any task process and executed in the order of distribution.

6. The method according to claim 4 or 5, characterized in that, For any given task process; Based on the protocol information and the task execution strategy, test tasks for each task process are executed in parallel to obtain the test results for each test task, including: Obtain the test tasks corresponding to the task processes in the task queue, wherein the task queue includes multiple sets of test tasks to be executed; Access permissions for the test tasks are verified, and after verification, the test tasks are executed according to the protocol information corresponding to the test tasks, and the corresponding test results are obtained and stored in the result queue. The result queue is used to store the test results of each test task.

7. The method of claim 6, wherein, After obtaining the test results of each test task, the method further includes: Obtain test information during the execution of each test task; Based on the test results and corresponding test information of each test task in the result queue, a first parameter and a second parameter are determined. The first parameter is used to indicate the coverage of the calling interface by each test task, and the second parameter is the execution pass rate of each test task. A test report is generated based on the test results of each test task, the corresponding test information, the first parameter, and the second parameter.

8. A multi-platform testing device, characterized by, include: The acquisition module is used to acquire the runtime configuration information to be tested. The runtime configuration information includes the platform type and test parameter information of multiple computing platforms. The computing platforms are used to manage multiple computing resources. The first determining module is used to determine multiple sets of test tasks and multiple business types corresponding to each test task based on the test parameter information. The test tasks are used to perform business tests on multiple computing platforms. The second determining module is used to determine, based on the platform type and the business type, the multiple computing platforms to be invoked for executing each test task, as well as the protocol information required for communicating with each computing platform; The processing module is used to execute each group of test tasks according to the protocol information and obtain the test results of each test task.

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

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.

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

Images