Automatic node testing method, device and equipment and storage medium
Through Golang-based layered architecture and data-driven testing, the problems of low efficiency and scalability in large-scale node testing are solved, efficient and flexible test management is achieved, and test efficiency and accuracy are improved.
Patent Information
- Application Number
- CN202510870817.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-26
- Publication Date
- 2025-09-23
AI Technical Summary
Existing technologies suffer from low testing efficiency, waste of resources, lack of versatility and scalability in large-scale node testing, difficulty in real-time monitoring of test progress and results, and the need to frequently modify code to adapt to node changes.
It adopts a layered architecture based on the Golang language, takes advantage of high concurrency features to schedule test tasks, and combines data-driven testing and visualization platforms to achieve flexible management and efficient execution of test tasks.
It improves the efficiency and accuracy of large-scale node testing, reduces system maintenance costs, provides an intuitive operation interface and real-time monitoring, quickly locates problems, and reduces manpower and time costs.
Smart Images
Figure CN120687367A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of computers, and in particular to a node automation testing method, device, equipment and storage medium. Background Art
[0002] In the prior art, when testing large-scale nodes, traditional testing methods often use manual testing or simple script testing. Manual testing is almost not feasible for large-scale nodes, and simple script testing, when dealing with concurrent testing of a large number of nodes, is slow to execute test tasks due to the concurrent performance limitations of the language itself or unreasonable architectural design, which consumes a lot of time and resources. At the same time, existing testing solutions are usually designed for specific systems or scenarios and lack versatility and scalability. When the node type, test scenario or business requirements change, the test code needs to be rewritten or significantly modified, which increases the testing cost and cycle. In addition, large-scale node testing involves a large number of test nodes, test cases and test data. Traditional testing solutions lack effective visual management and monitoring methods, making it difficult to grasp the test progress, node status and test results in real time, which is not conducive to timely discovery and resolution of problems arising during the testing process.
[0003] In summary, how to achieve efficient, flexible and easy-to-manage testing of large-scale nodes is an urgent problem that needs to be solved. Summary of the Invention
[0004] In view of this, the purpose of the present invention is to provide a node automation testing method, apparatus, device, and storage medium that can achieve efficient, flexible, and easy-to-manage testing of large-scale nodes. The specific solution is as follows:
[0005] In a first aspect, the present application discloses a node automation testing method, which is applied to a test system, comprising:
[0006] Acquire a test task using a target interface of the application layer, and store the test task in a target task queue based on the task priority; the test task includes a test case, test data, a test node range, and the task priority;
[0007] Determine a target test task from all the test tasks in the target task queue by using a processing layer based on the task priority of each of the test tasks, and determine a target test node from all the test nodes based on the test node range corresponding to the target test task by using load balancing;
[0008] Utilizing the processing layer to assign the target test task to the target test node, running the target test task on the target test node to obtain corresponding test results and monitoring log information, and returning the test results and monitoring log information to the target visualization platform of the application layer;
[0009] Among them, the test system is a system built based on the Golang language. The application layer, the processing layer and the basic service layer of the test system communicate through an application programming interface, and the test nodes include physical nodes, virtual nodes and containerized nodes.
[0010] Optionally, before acquiring the test task using the target interface of the application layer, the method further includes:
[0011] Registering each of the test nodes to the test system using the basic service layer;
[0012] Using the basic service layer to record the basic information of each test node and monitor the node status of each test node in real time; the node status includes online state, offline state, busy state and idle state;
[0013] Deploy a corresponding test environment for each test node using the basic service layer;
[0014] Obtaining a test case using the first interface of the application layer;
[0015] The second interface of the processing layer is used to obtain test data from an external data source, so that a user can construct a test task based on the test data and the test case.
[0016] Optionally, the deploying a corresponding test environment for each test node using the basic service layer includes:
[0017] According to the test requirements and test scenarios of each test node, the basic service layer is used to call the target script to deploy a corresponding test environment for each test node; the test environment includes a software environment, a configuration file and a dependent library.
[0018] Optionally, after obtaining the test case by using the first interface of the application layer, the method further includes:
[0019] Utilizing the processing layer to edit, delete and group the test cases according to the test scenarios and test function points corresponding to each test case;
[0020] The test case includes case information, preconditions, test steps, input data, expected output and verification rules.
[0021] Optionally, after obtaining the test case by using the first interface of the application layer, the method further includes:
[0022] Performing parameterization processing on each of the test cases to obtain parameterized test cases;
[0023] Accordingly, the method of obtaining test data from an external data source by using the second interface of the processing layer so that the user can construct a test task based on the test data and the test case includes:
[0024] The second interface of the processing layer is utilized to obtain test data from different external data sources, so that the user can construct different test tasks based on different test data and the same parameterized test case.
[0025] Optionally, the node automated testing method further includes:
[0026] Describing the dependency relationship between the test tasks in the target task queue using a directed acyclic graph;
[0027] Accordingly, the utilization processing layer determines the target test task from all the test tasks in the target task queue based on the task priority of each test task, including:
[0028] Determine a first target test task from all the test tasks in the target task queue based on the task priority of each of the test tasks, and determine whether there is a second target test task corresponding to the first target test task in the target task queue based on the directed acyclic graph; the second target test task is a predecessor task corresponding to the first target test task;
[0029] If a second target test task corresponding to the first target test task exists in the target task queue, the first target test task and the second target test task are determined as target test tasks.
[0030] Optionally, the node automated testing method further includes:
[0031] Integrating the target layer of the test system with the target system using a target extension interface;
[0032] The target layer is any one or more combinations of the application layer, the processing layer, and the basic service layer; and the target system includes a continuous integration / continuous deployment system.
[0033] In a second aspect, the present application discloses a node automation testing device, which is applied to a testing system and includes:
[0034] A task acquisition module is used to acquire a test task using a target interface of the application layer and store the test task in a target task queue based on the task priority; the test task includes a test case, test data, a test node range and the task priority;
[0035] a node determination module, configured to determine a target test task from all the test tasks in the target task queue based on the task priority of each of the test tasks using a processing layer, and to determine a target test node from all the test nodes based on the test node range corresponding to the target test task through load balancing;
[0036] A task execution module is used to allocate the target test task to the target test node using the processing layer, run the target test task on the target test node to obtain corresponding test results and monitoring log information, and return the test results and monitoring log information to the target visualization platform of the application layer;
[0037] Among them, the test system is a system built based on the Golang language. The application layer, the processing layer and the basic service layer of the test system communicate through an application programming interface, and the test nodes include physical nodes, virtual nodes and containerized nodes.
[0038] In a third aspect, the present application discloses an electronic device, comprising:
[0039] Memory, used to store computer programs;
[0040] The processor is used to execute the computer program to implement the aforementioned node automation testing method.
[0041] In a fourth aspect, the present application discloses a computer-readable storage medium for storing a computer program, wherein the computer program implements the aforementioned node automation testing method when executed by a processor.
[0042] In this application, when performing node testing, the target interface of the application layer is used to obtain the test task, and the test task is stored in the target task queue based on the task priority; the test task includes a test case, test data, a test node range and the task priority; the processing layer is used to determine the target test task from all the test tasks in the target task queue based on the task priority of each test task, and the target test node is determined from all test nodes based on the test node range corresponding to the target test task through load balancing; the target test task is assigned to the target test node by the processing layer, and the target test task is run on the target test node to obtain the corresponding test results and monitoring log information, and the test results and the monitoring log information are returned to the target visualization platform of the application layer; wherein the test system is a system built based on the Golang language, and the application layer, the processing layer and the basic service layer of the test system communicate through an application programming interface, and the test nodes include physical nodes, virtual nodes and containerized nodes. It can be seen that this application uses the Golang language to build a test system, and uses the high concurrency characteristics of Golang to achieve concurrent testing of large-scale nodes, make full use of computing resources, and significantly shorten the test time. The constructed test system includes an application layer, a processing layer, and a basic service layer. Its layered architecture design and modular implementation enable the test system to easily adapt to different types of nodes, communication protocols, and test scenarios. Users can add new test functions and node types through simple configuration and expansion without modifying the core code, reducing the system's maintenance costs and expansion difficulty. At the same time, the target visualization platform of the application layer provides an intuitive operation interface and real-time monitoring functions, facilitating test configuration, task scheduling, status monitoring, and result analysis. This helps users quickly locate and resolve problems, thereby improving the efficiency and convenience of test management. By improving test efficiency and accuracy, functional defects in the system can be discovered in advance, avoiding the need for costly repairs in the later maintenance phase. BRIEF DESCRIPTION OF THE DRAWINGS
[0043] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.
[0044] Figure 1 This is a flow chart of a node automation testing method disclosed in this application;
[0045] Figure 2 A schematic diagram of a specific test system architecture disclosed in this application;
[0046] Figure 3 A schematic diagram of a specific node automation test process disclosed in this application;
[0047] Figure 4 This is a schematic diagram of the structure of a node automation test device disclosed in this application;
[0048] Figure 5 This is a structural diagram of an electronic device disclosed in this application. DETAILED DESCRIPTION
[0049] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.
[0050] In the prior art, when testing large-scale nodes, traditional testing methods often use manual testing or simple script testing. Manual testing is almost not feasible for large-scale nodes, and simple script testing, when dealing with concurrent testing of a large number of nodes, is slow to execute test tasks due to the concurrent performance limitations of the language itself or unreasonable architectural design, which consumes a lot of time and resources. At the same time, existing testing schemes are usually designed for specific systems or scenarios and lack versatility and scalability. When the node type, test scenario or business requirements change, the test code needs to be rewritten or significantly modified, which increases the testing cost and cycle. In addition, large-scale node testing involves a large number of test nodes, test cases and test data. Traditional testing schemes lack effective visual management and monitoring means, making it difficult to grasp the test progress, node status and test results in real time, which is not conducive to timely discovery and resolution of problems arising during the testing process. In order to solve the above technical problems, the present application discloses a node automation testing method that can achieve efficient, flexible and easy-to-manage testing of large-scale nodes.
[0051] See also Figure 1 As shown, an embodiment of the present invention discloses a node automation testing method, which is applied to a test system, including:
[0052] Step S11: Acquire a test task using a target interface of the application layer, and store the test task in a target task queue based on the task priority; the test task includes a test case, test data, a test node range, and the task priority.
[0053] In this embodiment, the test system uses Figure 2The layered architecture shown here comprises an application layer, a processing layer, and a basic service layer. Communication between these layers is achieved through well-defined application programming interfaces (APIs). This allows the test system to adapt to different node types, different communication protocols, and diverse test scenarios, facilitating the addition of new test functionality and scaling, ensuring system flexibility and scalability. Test nodes include physical nodes, virtual nodes, and containerized nodes. This test system is built on Golang (also known as the Go language). Because Go supports goroutines and channels, it offers simplicity, efficiency, and strong concurrency, making it easy to implement highly concurrent programming. This makes it ideal for handling concurrent task scheduling and node management in large-scale node testing. By leveraging Golang's high concurrency, an efficient test task scheduling and execution mechanism can be designed to enable concurrent testing of large-scale nodes, fully utilizing computing resources, shortening test time, and improving test efficiency.
[0054] In this embodiment, the basic service layer is primarily responsible for setting up the test environment and managing nodes, providing foundational services for upper layers. The processing layer is the core of the test system, implementing key functions such as test case management, task scheduling, test execution, and result analysis. The application layer provides users with a visual user interface (also known as the target visualization platform) and an API (Application Programming Interface) to facilitate test configuration, task management, and result viewing. The target visualization platform provides an intuitive test management interface through a web interface. Users can use the platform to design and manage test cases, create and schedule test tasks, monitor node status, and view and analyze test results. The open API (also known as the target extension interface) provided by the test system can be used to integrate and extend the target layer of the test system with other systems. The target layer is any combination of the application layer, processing layer, and basic service layer. For example, the test system can be integrated with a continuous integration / continuous deployment (CI / CD) system to automate the testing process, or with a defect management system to automatically submit defects discovered during testing.
[0055] In this embodiment, Figure 3As shown, before using the target interface of the application layer to obtain the test task, the basic service layer is used to register each test node with the test system; the basic service layer is used to record the basic information of each test node and monitor the node status of each test node in real time; the node status includes online status, offline status, busy status and idle status; the basic service layer is used to deploy the corresponding test environment for each test node; the first interface of the application layer is used to obtain the test case; the second interface of the processing layer is used to obtain the test data from the external data source, so that the user can build the test task based on the test data and test case. When using the basic service layer to deploy the corresponding test environment for each test node, the basic service layer can be used to call the target script to deploy the corresponding test environment for each test node according to the test requirements and test scenarios of each test node; the test environment includes the software environment, configuration files and dependency libraries, so as to ensure that the node is in a testable state. That is, before receiving the test tasks sent by the user, the basic service layer will register each test node and operate each test node through a unified interface. These test nodes include physical nodes, virtual nodes, and containerized nodes (such as Docker containers). Once the test nodes are registered with the test system, the basic service layer will monitor the node status of these test nodes in real time. At the same time, it will call the Golang os / exec package to call the script tool and other target scripts to execute the deployment script according to the test requirements, automatically deploying the software environment, configuration files, and dependency libraries required for the test to the node. In a specific embodiment, users can pre-define the environment configuration according to different test scenarios to improve the efficiency and consistency of environment construction.
[0056] In this embodiment, after the test environment for the test node is deployed, the test system can use the first interface of the application layer to obtain test cases sent by the user and the second interface of the processing layer to obtain test data from an external data source. The user can then construct a test task based on the test data and test cases. The user designs the test cases based on the functional requirements of the system, specifying the test steps, input data, expected output, and validation rules. The data-driven module prepares the input data required for the test and stores it in the external data source. Test cases are typically designed based on different functional points, such as node registration, data synchronization, and transaction processing. Each test case contains basic use case information (such as use case ID, name, description), preconditions (such as node status and data preparation requirements), test steps (a sequence of operations arranged in order), input data, expected output, and validation rules. After obtaining the test cases using the first interface of the application layer, the processing layer can be used to edit, delete, and group the test cases according to the test scenarios and test functional points corresponding to each test case.
[0057] It should be noted that a test case only contains test logic and validation rules, while the test data is stored in an external data source. In this embodiment, each test case can also be parameterized to obtain a parameterized test case. Accordingly, the second interface of the processing layer is used to obtain test data from the external data source, allowing users to construct test tasks based on the test data and test cases. Specifically, this can include using the second interface of the processing layer to obtain test data from different external data sources, allowing users to construct different test tasks based on different test data and the same parameterized test case. A test task includes a test case, test data, test node range, and task priority. In this embodiment, test data can be read from multiple data sources (such as CSV files, databases, Excel spreadsheets, etc.), and the test data can be associated with test cases to implement data-driven testing. This data-driven approach allows for the convenient generation of a large number of test cases, covering various input scenarios and improving the comprehensiveness of testing. It is understood that each test task can contain multiple test cases, specifying parameters such as the test node range and priority. By separating test data from test logic, the reusability and maintainability of test cases are improved. Through data-driven testing technology, key functional points such as node communication, business logic, and data consistency are covered to ensure comprehensive verification of system functions. Functional defects that are difficult to detect with traditional solutions can be discovered, improving system reliability and stability.
[0058] In a specific implementation, Golang's encoding / csv, database / sql and other standard libraries are used to realize the reading of different data sources such as CSV files and databases. When reading data, a built-in data verification mechanism is used to verify the correctness of the data format through regular expressions, custom functions, etc. A dynamic data mapping mechanism is designed to realize the automatic binding of test data and test case parameters through Golang's structure and reflection characteristics. Users can specify the correspondence between data fields and test case parameters in the form of key-value pairs in the test case configuration file. Before the test is executed, the data-driven module traverses the test case list, extracts the corresponding data from the data source according to the mapping relationship, and dynamically generates a complete test case instance to realize the flexible association between data and use cases. Build a data-driven test pipeline to connect data reading, use case generation, test execution and result recording in series.
[0059] Step S12: using the processing layer to determine the target test task from all the test tasks in the target task queue based on the task priority of each test task, and determining the target test node from all test nodes based on the test node range corresponding to the target test task through load balancing.
[0060] In this embodiment, the testing system leverages Golang's high concurrency to achieve dynamic allocation and load balancing of test tasks. Golang's goroutine and channel mechanisms provide powerful support for high-concurrency task scheduling. The scheduling engine builds a multi-level task scheduling system based on this, encompassing task queue design, dynamic load monitoring, and flexible priority handling, to achieve efficient test task allocation and execution. In one specific implementation, the task queue can be implemented using a double-ended queue (Deque) data structure, built using the container / list standard library. The front end is used to insert high-priority tasks, while the back end processes ordinary tasks. To prevent task starvation, a time-slice polling mechanism is introduced to elevate the priority of ordinary tasks that have not been executed for a long time, ensuring fair task execution. Furthermore, the sync.RWMute read-write lock is used to control queue concurrency, ensuring data consistency and security when multiple goroutines access the queue simultaneously. Furthermore, a directed acyclic graph (DAG) can be used to describe the dependencies between the test tasks in the target task queue to manage these dependencies, ensuring that dependent tasks are executed in the correct order and avoiding data inconsistencies.
[0061] In this embodiment, to dynamically monitor the load of each test node, the test system can obtain system resource information such as node CPU utilization and memory usage through the runtime package. This information is then combined with custom metrics such as test task execution time and resource consumption to comprehensively assess the node load. A sliding window algorithm is used to incorporate load data from the past period into the calculation, smoothing data fluctuations and avoiding misjudgments caused by instantaneous load changes. The test system regularly updates node load information and pushes it to the intelligent scheduling engine in real time via a channel, providing an accurate basis for task allocation.
[0062] In a specific embodiment, the multi-level priority of the test task includes four levels: emergency, high, medium, and low. The intelligent scheduling engine adopts a priority-based preemptive scheduling strategy according to the task priority and node load. When a high-priority task enters the queue, if the priority of the currently executing task is lower than the new task, and the target node has sufficient resources, the engine will suspend the execution of the current task, assign the high-priority task to the appropriate node, and resume the execution of the original task after the high-priority task is completed. At the same time, since some high-priority test tasks have low-priority predecessor tasks, the processing layer is used to determine the target test task from all test tasks in the target task queue based on the task priority of each test task. Specifically, it may include: determining the first target test task from all test tasks in the target task queue based on the task priority of each test task, and judging whether there is a second target test task corresponding to the first target test task in the target task queue based on a directed acyclic graph; the second target test task is the predecessor task corresponding to the first target test task; if there is a second target test task corresponding to the first target test task in the target task queue, the first target test task and the second target test task are determined as target test tasks. This task execution method ensures that high-priority tasks are prioritized while ensuring that dependent tasks are executed in the correct order, avoiding data inconsistencies. After determining the target test task, the scheduling engine uses polling, priority scheduling, and minimum load algorithms to rationally allocate test tasks to various nodes based on the status of each test node and the test task requirements (such as test type, priority, and the node range corresponding to the test task), ensuring efficient execution of the test task.
[0063] In this example, sync.WaitGroup is used to control the number of concurrent tasks, preventing system resource exhaustion due to excessive tasks. Before a task is executed, the count is incremented using the Add method. After the task is completed, the count is decremented using the Done method. The main program then blocks using the Wait method, waiting for all tasks to complete. To address potential errors during task execution, such as network anomalies and node crashes, the defer statement is combined with the recover function to capture exceptions. This allows for logging of any exceptions during task processing and provides feedback via a channel.
[0064] Step S13: Use the processing layer to assign the target test task to the target test node, run the target test task on the target test node to obtain corresponding test results and monitoring log information, and return the test results and monitoring log information to the target visualization platform of the application layer.
[0065] In this embodiment, the test system will use the processing layer to assign the target test task to the corresponding target test node, and run the test case corresponding to the test task on the target test node, execute the corresponding test logic according to the input data, such as calling the corresponding test script or API according to the definition of the test case, interacting with the target test node, obtaining the test results and the log information and data collected in real time during the test to provide a basis for result analysis. During the test execution process, the user can monitor the status of the node and the test progress in real time through the target visualization platform, and display the execution status of each test task. After the test is completed, the test system will verify the test results according to the verification rules of the test case to determine whether the test case has passed. In addition, the user can understand the functional test status of the system through the test report, and repair and optimize the problems found.
[0066] In this embodiment, concurrent execution is employed during test execution, leveraging Golang's goroutines to run multiple data-driven test cases simultaneously, improving test efficiency. During test execution, the data-driven module reads data from the data source and sequentially passes it to the test cases, enabling the execution of the same test logic in different data scenarios. In this embodiment, statistical analysis and aggregation of test results provide data support for system function optimization. In this embodiment, the target visualization platform of the test system can also be used to analyze failed test tasks, extract error information and logs, and generate detailed analysis reports. The test reports include information such as test pass rates and defect statistics. By establishing a traceability mechanism for data and test results, the test reports detail the input data used for each test case, making it easier for users to quickly locate problematic data. When a test case fails, the failed data and its associated test context (such as test environment configuration and node status) are automatically saved to a log file, providing comprehensive data support for problem analysis. Centralized log management and detailed test reports help users quickly locate and resolve issues, improving the efficiency and convenience of test management. Automated testing reduces manual intervention, labor costs, and time costs. At the same time, by improving testing efficiency and accuracy, functional defects in the system can be discovered in advance, avoiding more costly repairs in the later maintenance stage.
[0067] As can be seen, this application uses the Golang language to build a test system. By leveraging Golang's high concurrency characteristics, it can achieve concurrent testing of large-scale nodes, fully utilize computing resources, and significantly shorten test time. The constructed test system includes an application layer, a processing layer, and a basic service layer. The layered architecture design and modular implementation enable the test system to easily adapt to different types of nodes, communication protocols, and test scenarios. Users can add new test functions and node types through simple configuration and expansion without modifying the core code, reducing the system's maintenance costs and expansion difficulty. At the same time, the target visualization platform of the application layer provides an intuitive operation interface and real-time monitoring functions, facilitating users' test configuration, task scheduling, status monitoring, and result analysis, helping users quickly locate and resolve problems, thereby improving the efficiency and convenience of test management. By improving test efficiency and accuracy, functional defects in the system can be discovered in advance, avoiding the need to spend more money on repairs in the later maintenance phase.
[0068] See also Figure 4 As shown, the present application discloses a node automation testing device, which is applied to a testing system, comprising:
[0069] The task acquisition module 11 is used to acquire a test task using a target interface of the application layer and store the test task in a target task queue based on the task priority; the test task includes a test case, test data, a test node range and the task priority;
[0070] A node determination module 12 is configured to determine a target test task from all the test tasks in the target task queue based on the task priority of each test task using a processing layer, and determine a target test node from all the test nodes based on the test node range corresponding to the target test task through load balancing;
[0071] The task execution module 13 is used to allocate the target test task to the target test node using the processing layer, run the target test task on the target test node to obtain corresponding test results and monitoring log information, and return the test results and monitoring log information to the target visualization platform of the application layer;
[0072] Among them, the test system is a system built based on the Golang language. The application layer, the processing layer and the basic service layer of the test system communicate through an application programming interface, and the test nodes include physical nodes, virtual nodes and containerized nodes.
[0073] As can be seen, this application uses the Golang language to build a test system. By leveraging Golang's high concurrency characteristics, it can achieve concurrent testing of large-scale nodes, fully utilize computing resources, and significantly shorten test time. The constructed test system includes an application layer, a processing layer, and a basic service layer. The layered architecture design and modular implementation enable the test system to easily adapt to different types of nodes, communication protocols, and test scenarios. Users can add new test functions and node types through simple configuration and expansion without modifying the core code, reducing the system's maintenance costs and expansion difficulty. At the same time, the target visualization platform of the application layer provides an intuitive operation interface and real-time monitoring functions, facilitating users' test configuration, task scheduling, status monitoring, and result analysis, helping users quickly locate and resolve problems, thereby improving the efficiency and convenience of test management. By improving test efficiency and accuracy, functional defects in the system can be discovered in advance, avoiding the need to spend more money on repairs in the later maintenance phase.
[0074] In a specific embodiment, the device may further include:
[0075] A node registration module, configured to register each of the test nodes with the test system using the basic service layer;
[0076] A status monitoring module, configured to record basic information of each test node using the basic service layer and monitor the node status of each test node in real time; the node status includes online status, offline status, busy status, and idle status;
[0077] An environment deployment module, configured to deploy a corresponding test environment for each test node using the basic service layer;
[0078] A test case acquisition module, configured to acquire a test case using the first interface of the application layer;
[0079] The test data acquisition module is used to acquire test data from an external data source using the second interface of the processing layer, so that a user can construct a test task based on the test data and the test case.
[0080] In a specific implementation, the environment deployment module may specifically include:
[0081] The environment deployment unit is used to deploy a corresponding test environment for each test node by calling the target script using the basic service layer according to the test requirements and test scenarios of each test node; the test environment includes a software environment, a configuration file and a dependency library.
[0082] In a specific embodiment, the device may further include:
[0083] A test case management module, configured to utilize the processing layer to edit, delete and group the test cases according to the test scenarios and test function points corresponding to the test cases;
[0084] The test case includes case information, preconditions, test steps, input data, expected output and verification rules.
[0085] In a specific embodiment, the device may further include:
[0086] A parameterization processing module, configured to perform parameterization processing on each of the test cases to obtain a parameterized test case;
[0087] Accordingly, the test data acquisition module may specifically include:
[0088] The test data acquisition unit is used to acquire test data from different external data sources using the second interface of the processing layer, so that the user can construct different test tasks based on different test data and the same parameterized test case.
[0089] In a specific embodiment, the device may further include:
[0090] A dependency determination module, configured to describe the dependency relationships between the test tasks in the target task queue using a directed acyclic graph;
[0091] Accordingly, the node determination module 12 may specifically include:
[0092] a predecessor task determination unit, configured to determine a first target test task from all the test tasks in the target task queue based on the task priority of each of the test tasks, and to determine whether a second target test task corresponding to the first target test task exists in the target task queue based on the directed acyclic graph; the second target test task is a predecessor task corresponding to the first target test task;
[0093] The target task determining unit is configured to determine the first target test task and the second target test task as target test tasks if a second target test task corresponding to the first target test task exists in the target task queue.
[0094] In a specific embodiment, the device may further include:
[0095] A system integration module, configured to integrate the target layer of the test system with the target system using a target extension interface;
[0096] The target layer is any one or more combinations of the application layer, the processing layer, and the basic service layer; and the target system includes a continuous integration / continuous deployment system.
[0097] Furthermore, the embodiment of the present application also discloses an electronic device, Figure 5 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content in the diagram should not be considered as any limitation to the scope of application of the present application.
[0098] Figure 5 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of the present application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps of the node automated testing method disclosed in any of the aforementioned embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be an electronic computer.
[0099] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and the external device. The communication protocol it follows is any communication protocol that can be applied to the technical solution of this application and is not specifically limited here; the input and output interface 25 is used to obtain external input data or output data to the outside world. Its specific interface type can be selected according to specific application needs and is not specifically limited here.
[0100] In addition, the memory 22 as a carrier for resource storage can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include an operating system 221, a computer program 222, etc., and the storage method can be temporary storage or permanent storage.
[0101] The operating system 221 is used to manage and control the hardware devices on the electronic device 20 and the computer program 222, which can be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program that can be used to implement the node automation testing method performed by the electronic device 20 disclosed in any of the aforementioned embodiments, the computer program 222 can further include a computer program that can be used to perform other specific tasks.
[0102] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when executed by a processor, the computer program implements the aforementioned disclosed node automated testing method. The specific steps of this method can be referred to the corresponding contents disclosed in the aforementioned embodiments and will not be repeated here.
[0103] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from the other embodiments. Reference can be made to the descriptions of the identical or similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and the relevant parts can be referred to the descriptions of the methods.
[0104] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0105] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
[0106] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.
[0107] The above is a detailed introduction to the technical solution provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. At the same time, for those skilled in the art, according to the ideas of the present application, there may be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.
Claims
1. A node automation testing method, characterized in that: Applicable to test systems, including: Acquire a test task using a target interface of the application layer, and store the test task in a target task queue based on the task priority; the test task includes a test case, test data, a test node range, and the task priority; Determine a target test task from all the test tasks in the target task queue by using a processing layer based on the task priority of each of the test tasks, and determine a target test node from all the test nodes based on the test node range corresponding to the target test task by using load balancing; Utilizing the processing layer to assign the target test task to the target test node, running the target test task on the target test node to obtain corresponding test results and monitoring log information, and returning the test results and monitoring log information to the target visualization platform of the application layer; Among them, the test system is a system built based on the Golang language. The application layer, the processing layer and the basic service layer of the test system communicate through an application programming interface, and the test nodes include physical nodes, virtual nodes and containerized nodes.
2. The node automation testing method according to claim 1, characterized in that: Before obtaining the test task by using the target interface of the application layer, the method further includes: Registering each of the test nodes to the test system using the basic service layer; Using the basic service layer to record the basic information of each test node and monitor the node status of each test node in real time; the node status includes online state, offline state, busy state and idle state; Deploy a corresponding test environment for each test node using the basic service layer; Obtaining a test case using the first interface of the application layer; The second interface of the processing layer is used to obtain test data from an external data source, so that a user can construct a test task based on the test data and the test case.
3. The node automation testing method according to claim 2, characterized in that: The deploying a corresponding test environment for each test node using the basic service layer includes: According to the test requirements and test scenarios of each test node, the basic service layer is used to call the target script to deploy a corresponding test environment for each test node; the test environment includes a software environment, a configuration file and a dependent library.
4. The node automation testing method according to claim 2, characterized in that: After obtaining the test case by using the first interface of the application layer, the method further includes: Utilizing the processing layer to edit, delete and group the test cases according to the test scenarios and test function points corresponding to each test case; The test case includes case information, preconditions, test steps, input data, expected output and verification rules.
5. The node automation testing method according to claim 2, characterized in that: After obtaining the test case by using the first interface of the application layer, the method further includes: Performing parameterization processing on each of the test cases to obtain parameterized test cases; Accordingly, the method of obtaining test data from an external data source by using the second interface of the processing layer so that the user can construct a test task based on the test data and the test case includes: The second interface of the processing layer is utilized to obtain test data from different external data sources, so that the user can construct different test tasks based on different test data and the same parameterized test case.
6. The node automation testing method according to claim 1, characterized in that: Also includes: Describing the dependency relationship between the test tasks in the target task queue using a directed acyclic graph; Accordingly, the utilization processing layer determines the target test task from all the test tasks in the target task queue based on the task priority of each test task, including: Determine a first target test task from all the test tasks in the target task queue based on the task priority of each of the test tasks, and determine whether there is a second target test task corresponding to the first target test task in the target task queue based on the directed acyclic graph; the second target test task is a predecessor task corresponding to the first target test task; If a second target test task corresponding to the first target test task exists in the target task queue, the first target test task and the second target test task are determined as target test tasks.
7. The node automation testing method according to any one of claims 1 to 6, characterized in that: Also includes: Integrating the target layer of the test system with the target system using a target extension interface; The target layer is any one or more combinations of the application layer, the processing layer, and the basic service layer; and the target system includes a continuous integration / continuous deployment system.
8. A node automation testing device, characterized in that: Test system, including: A task acquisition module is used to acquire a test task using a target interface of the application layer and store the test task in a target task queue based on the task priority; the test task includes a test case, test data, a test node range and the task priority; a node determination module, configured to determine a target test task from all the test tasks in the target task queue based on the task priority of each of the test tasks using a processing layer, and to determine a target test node from all the test nodes based on the test node range corresponding to the target test task through load balancing; A task execution module is used to allocate the target test task to the target test node using the processing layer, run the target test task on the target test node to obtain corresponding test results and monitoring log information, and return the test results and monitoring log information to the target visualization platform of the application layer; Among them, the test system is a system built based on the Golang language. The application layer, the processing layer and the basic service layer of the test system communicate through an application programming interface, and the test nodes include physical nodes, virtual nodes and containerized nodes.
9. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor, configured to execute the computer program to implement the node automation testing method according to any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that Used to store a computer program, wherein when the computer program is executed by a processor, the node automation testing method according to any one of claims 1 to 7 is implemented.