Gateway host adaptive closed-loop test method and system based on intelligent plan driving

Abstract

The invention discloses a gateway host adaptive closed-loop test method and system based on intelligent plan driving, and aims to solve the problems of rigid test process, low efficiency and weak traceability of the existing gateway machine. The core of the technical scheme is to construct a complete closed loop of'plan editing-automatic matching-batch asynchronous testing-intelligent retesting-data tracing '; a multi-level tree structure including equipment types, hardware models and the like is adopted to manage a test plan, a time consumption threshold can be customized to distinguish common / asynchronous cases, and parallel execution is realized; configuration of retest times is supported, and only failed use cases are accurately retested; a structured report associated with the unique detection order number is generated, and full-process tracing is achieved. The system comprises a test plan management core module and the like, and an optional authority management module distinguishes administrator authority from common user authority. The test flexibility and universality are improved, the test time is remarkably shortened, the operation threshold is reduced, and a reliable automatic test scheme is provided for links such as gateway machine production quality inspection and factory acceptance.

Description

Technical Field

[0001] This invention relates to a gateway host adaptive closed-loop testing method and system based on intelligent pre-plan driven technology, belonging to the field of communication equipment testing technology. Background Technology

[0002] As a critical node connecting communication equipment rooms and power substations to the superior master station, the reliability of gateway equipment's functions and performance is paramount. Comprehensive testing of gateway equipment is required in all stages, including production quality inspection, factory acceptance, and maintenance diagnostics. Currently, common gateway testing methods rely primarily on manual or semi-automated testing tools, which have the following significant drawbacks: 1. Rigid testing process: Test cases are strongly coupled with specific equipment models and testing environments, lacking a flexible and configurable test plan management mechanism; when test requirements change or new equipment models are added, test scripts need to be modified or even redeveloped, resulting in poor adaptability and high maintenance costs.

[0003] 2. Low testing efficiency: The test often adopts a sequential execution mode, which can severely block the entire test queue and become a performance bottleneck for time-consuming test items such as "4G module detection". In addition, traditional batch testing usually requires a full retest or manual screening of failed test cases after some test cases fail, which is inefficient.

[0004] 3. Lack of closed-loop traceability capability: The test process is not fully recorded, and the test results are not strongly correlated with equipment information and the test environment, making it difficult to form an effective quality traceability chain, which is not conducive to problem localization and quality analysis.

[0005] Therefore, there is an urgent need in this field for an automated testing solution that can improve testing flexibility, efficiency, and traceability. Summary of the Invention

[0006] Purpose of the invention: In order to overcome the shortcomings of the existing technology, the present invention provides a gateway host adaptive closed-loop testing method and system based on intelligent contingency plan drive. By introducing intelligent contingency plan management, batch asynchronous testing and precise retesting mechanism, it realizes flexible configuration of the testing process, significant improvement of testing efficiency and complete traceability of the testing process.

[0007] Technical solution: To achieve the above objectives, the technical solution adopted by this invention is as follows: An adaptive closed-loop testing method for gateway hosts based on intelligent pre-plans is proposed. This method constructs a complete closed-loop testing system integrating "pre-plan editing - automatic matching - batch asynchronous testing - intelligent retesting - data traceability," comprising the following steps: S1. Test Plan Management: A multi-level tree structure including device type, hardware model, functional modules, and test cases is used for visual editing of test plans. Test plans can be imported and exported as standardized format files. A time threshold can be set; based on the execution time of test cases, test cases with a time less than or equal to the threshold are marked as normal test cases, while those with a time greater than the threshold are marked as asynchronous test cases. The time threshold can be customized by the user (e.g., default 5 seconds) and can be flexibly adjusted according to the test environment and device type. S2. Load the device under test: Receive the configuration information of the device under test, select the corresponding test plan according to the device type of the device under test, select, load and display all test cases under the test plan, preset the execution order of the test cases and create a test case list; S3. Batch Testing: The main test thread executes all test cases in the test case list according to the preset execution order. For any test case, the test case's flag is first determined: if it is a normal test case, the main test thread starts the normal test case and waits for the test to end. The main test thread updates the test results to the result database and then continues to execute the next test case; if it is an asynchronous test case, the asynchronous execution mode is adopted. The asynchronous test case is started by creating an independent thread, while the main test thread continues to execute the next test case. S4 Intelligent Retesting: After all test cases have been tested, filter out all test cases that failed, rebuild the test case list, and execute batch tests.

[0008] Specifically, in step S1, visual editing includes adding, deleting, modifying, moving up, and moving down nodes in a multi-level tree structure.

[0009] Specifically, in step S3, for asynchronous test cases, the main test thread does not wait for the test to finish and directly continues to execute the next test case; each asynchronous test case runs in parallel in the background through different independent threads, without blocking the sequential execution of ordinary test cases; after the asynchronous test case test is completed, the test results are directly updated to the result database through an independent thread.

[0010] Specifically, in step S4, the testing process is completed after the number of times the batch test is re-executed reaches a set value or all test results pass. The number of times the batch test is re-executed is defined as the number of retests. The number of retests can be configured by the user in the system interface. The default number of retests is 1, and it can also be adjusted as needed according to the testing purpose.

[0011] Specifically, after step S4, step S5 is executed. In step S5, a structured test report is generated, and all test operations, process logs, test results, and test reports are associated with a unique test order number and saved to the results database. This allows for querying historical test records based on the test order number. The test order number can be automatically generated by the system and can be a combination of "date + random 6-digit number + last 4 digits of device SN code" (e.g., 20240520-123456-3576) to ensure global uniqueness.

[0012] An adaptive closed-loop testing system for gateway hosts based on intelligent pre-test plans achieves the above method through the collaborative work of a test plan management module, a device configuration and matching module, a test execution engine (containing an asynchronous scheduler), an intelligent retest module, and a data traceability and reporting module. The test plan management module allows for visual editing of test plans through a visual editing interface, supporting the creation, editing, import, and export of standardized format files for test plans. The test plans adopt a multi-level tree structure that includes device type, hardware model, functional modules, and test cases. The device configuration and matching module is used to receive and store the configuration information of the device to be tested, select the corresponding test plan according to the device type of the device to be tested, select, load and display the test cases under the test plan, preset the execution order of the test cases and establish a test case list; The test execution engine has a built-in asynchronous scheduler for executing batch test instructions, executing all test cases in the test case list according to a preset execution order. The test execution engine identifies normal test cases and asynchronous test cases through the main test thread. The main test thread starts normal test cases and waits for the test to finish. The main test thread calls the asynchronous scheduler to create an independent thread to start asynchronous test cases, executing normal and asynchronous test cases in parallel. When executing test cases, the test execution engine interacts with the device under test through its built-in test proxy logic. The intelligent retesting module, after the test execution engine has executed all test cases, filters out all test cases that failed and rebuilds the test case list, and calls the test execution engine a number of times. The data traceability and reporting module is used to generate structured test reports and store test records.

[0013] Specifically, it also includes a permission management module to differentiate the operation permissions of system administrators and ordinary testers. Among them, functions such as editing test plans, importing / exporting standardized format files, and configuring devices under test are system administrator permissions, while ordinary testers' permissions include viewing test plans, starting / stopping tests, viewing test reports, and querying historical test records.

[0014] Beneficial Effects: The gateway host adaptive closed-loop testing method and system based on intelligent pre-plan driven by this invention has the following advantages compared with the prior art: 1. Great flexibility: Through editable and importable / exportable test pre-plans, the testing process can be quickly adapted to gateway devices of different models and with different testing requirements, improving the versatility and maintainability of the testing tools; 2. Extremely high testing efficiency: Batch testing combined with the asynchronous execution of time-consuming tasks solves the "blocking" problem in the testing process and shortens the overall testing time; the intelligent retesting mechanism avoids unnecessary repeated testing and further optimizes the efficiency of the fault diagnosis stage; 3. Strong traceability: The logging and result storage of the entire process, associated with a unique test order number, establishes a complete "test file" for each device under test, greatly facilitating quality auditing and root cause analysis; 4. Reduced operational threshold and human error: The visual operation interface and automated process control reduce the skill requirements for testers and reduce the risk of misoperation caused by manual intervention. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the system architecture and data flow for an example embodiment; Figure 2 This is a schematic diagram of the multi-level tree structure of the test plan in the embodiment; Figure 3 This is a schematic diagram of the batch testing and intelligent retesting process used in the example. Figure 4 This is an execution timing diagram of the asynchronous execution mode in the embodiment. Detailed Implementation

[0016] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0017] This invention provides a gateway host adaptive closed-loop testing method and system based on intelligent pre-test plan, comprising two levels: method and system. At the method level, this invention constructs a complete closed-loop testing system integrating "pre-test plan editing - automatic matching - batch asynchronous testing - intelligent retesting - data traceability". At the system level, this invention achieves the aforementioned method through the collaborative work of a test pre-test plan management module, a device configuration and matching module, a test execution engine (containing an asynchronous scheduler), an intelligent retesting module, and a data traceability and reporting module.

[0018] like Figure 1As shown, this is the core architecture of an adaptive closed-loop test for gateway hosts based on intelligent pre-test plans, designed according to the design concept of this invention. Users operate through a human-computer interaction interface. When a user edits or imports a test plan through the pre-test plan management module, the test plan is stored in the pre-test plan database. During testing, the device configuration and matching module reads the device information (such as SN code and IP address) of the device under test and matches it with the selected test plan. Upon successful matching, a test case list is constructed and sent to the test execution engine. The test execution engine calls the specific implementation in the test case library and instructs the test agent to interact with the gateway device under test. During the operation of the test execution engine, the built-in asynchronous scheduler identifies and asynchronously executes time-consuming tasks (i.e., asynchronous test cases). All test results and logs are collected by the data traceability and reporting module and stored in the result database. Finally, the intelligent retest module can initiate a new round of targeted testing based on the phased results of the testing process. This architecture is divided into four layers from top to bottom, with data interaction between each layer achieved through preset connection methods. The specific structure and data flow are as follows (e.g., ...). Figure 1 (as shown) 1. User Operation Layer: This layer includes the test PC and the user interface (GUI), serving as the entry point for user interaction with the system. Users initiate various operation commands through the visual GUI on the test PC, including editing and importing / exporting test plans, configuring information on the device under test, starting tests, confirming retests, and querying reports. Simultaneously, users receive feedback from the system regarding operation results, test status, and test reports.

[0019] 2. Core Software Layer: This layer is the core of the gateway testing tool software, integrating seven functional modules, each with its own function and working collaboratively. Among them, the permission management module verifies user operation permissions, distinguishing the operation scope of system administrators from that of ordinary testers; the contingency plan management module provides visual editing, import, and export functions for test contingency plans; the device configuration and matching module is responsible for receiving and storing information about the device under test and comparing it with the test contingency plan for consistency; the test execution engine is the core of test execution, with a built-in asynchronous scheduler used to control the sequential execution of test cases and the asynchronous scheduling of time-consuming tasks, while also realizing instruction interaction with the device under test through test proxy logic; the test proxy logic is an internal component of the test execution engine, responsible for instruction interaction with the gateway device under test; the intelligent retesting module is used to filter failed test cases and initiate retesting; and the data traceability and reporting module is responsible for storing test data, querying historical records, and generating reports.

[0020] 3. Data Storage Layer: This layer contains the data center's database server, specifically divided into a contingency plan database and a results database. The contingency plan database is used to persistently store test contingency plans edited or imported through the contingency plan management module, forming a reusable contingency plan resource pool. New contingency plans can be generated by editing existing ones. The stored content includes the tree structure information of the test contingency plans, equipment type, hardware model, functional modules, test cases, etc. The results database is used to store all test operations, process logs, test results, and other data. All data is associated with a unique test order number, providing data support for data traceability and report generation by the report generation module.

[0021] 4. Equipment Testing Layer: This layer includes the equipment layer / test station and the gateway under test. The gateway under test is deployed on the test station and establishes a physical connection with the test agent logic of the core software layer through Ethernet or serial port. It receives test instructions issued by the test agent logic, executes the corresponding test operations, and feeds back test status, execution results and other data to the test agent logic, thus completing the bidirectional flow of test data.

[0022] The data flow of the entire system follows the logic of "user operation - instruction transmission - data processing - result feedback". For example, after a user initiates a batch test instruction, the instruction is received by the test execution engine. The test execution engine retrieves the matching test cases and sends the test instructions to the gateway device under test through the test proxy logic. After the gateway device under test executes the instructions, it sends back the results. The results are then transmitted to the data traceability and reporting module for storage through the test proxy logic and the test execution engine. Finally, the results can be displayed to the user or a test report can be generated through the GUI interface.

[0023] like Figure 2 As shown, this is a multi-level tree structure of a test plan designed based on the design concept of this invention. The tree structure adopts a multi-level hierarchical design, with the following nodes from top to bottom: root node, device model node, functional module node, and test case node. The hierarchy of each node is clear and logically related. The specific structure is as follows: 1. Root node: The root nodes of this tree structure are "Single board testing" and "Complete system testing", which are the top-level classifications of all test plans and are used to define the overall scope of testing.

[0024] 2. Device Model Node: The root node is directly associated with specific device model nodes, such as "Gateway Mainboard - 3576 Version", which is used to specify the model of the device under test corresponding to the test plan, so as to achieve accurate association between the test plan and the device model.

[0025] 3. Functional Module Nodes: The device model node is divided into multiple functional module nodes. Each functional module node corresponds to a core functional module of the device under test, such as "Network Test", "4G Test", "Serial Port Test", "GPIO Test", "Dual Frequency Module Detection", "Encryption Module Detection", "LED Lighting Test", "LED Display Test", "GPS Detection", "USB Detection", etc., to realize the classification test of device functions.

[0026] 4. Test Case Nodes: Each functional module node contains multiple specific test case nodes. Each test case node corresponds to a specific test operation, and each test case has a unique identifier code containing information such as device model, functional module, and test content, facilitating identification and management. For example, the "Network Test" functional module contains test cases such as "GE6 Port Connectivity Test (3576-NET-ETH)," "GE1 Port Connectivity Test (3576-NET-GE1)," and "Upload Test Program (3576-NET-SCP-UP)"; the "4G Test" functional module contains test cases such as "SIM1 Connectivity Test (3576-SIM1-CONN)" and "SIM1 Signal Strength (3576-SIM1-ISSI)"; the "Serial Port Test" functional module contains test cases from "COM1 Data Transmission and Reception Test (3576-SERIAL-COM1)" to "COM8 Data Transmission and Reception Test (3576-SERIAL-COM8)." Other functional modules also correspond to multiple targeted test case nodes.

[0027] System administrators can visually edit this tree structure through the contingency plan management module, including adding, deleting, modifying, moving up and down nodes at each level. For example, they can add a new device model node, add new test case nodes to functional module nodes, and adjust the order of test case nodes, enabling flexible configuration of test contingency plans. In practical application scenarios, the specific functions of the above test cases are as follows: ① Network testing test cases: such as "GE6 port connectivity test" and "GE1 port connectivity test," are primarily used in the gateway device production quality inspection and factory acceptance stages. As a key node connecting the communication room and the upstream master station, the gateway's GE port is the core interface for wired network connection. These test cases can verify whether the interface can establish a normal network connection, avoiding communication interruptions between the gateway and the master station due to interface failure. In the maintenance and diagnostic stage, if the gateway experiences network communication abnormalities, these test cases can also quickly locate whether the problem is a GE port hardware or driver failure. ② 4G Test Cases: Such as "SIM1 Connectivity Test" and "SIM1 Signal Strength Test," these are mainly suitable for gateway devices deployed in scenarios such as power stations without wired network coverage. The 4G module serves as a backup or primary network communication guarantee. During the production phase, these test cases can verify whether the SIM card slot has good contact and whether the 4G module's signal reception capability meets the standards. During the maintenance phase, if the gateway experiences wireless communication failure, testing the SIM card connectivity and signal strength can help troubleshoot whether the problem lies with the SIM card, the 4G module, or the external signal coverage. ③ Serial Port Test Cases: Such as "COM1 Data Transmission / Reception Test" to "COM8 Data Transmission / Reception Test," these are suitable for scenarios where the gateway communicates with field sensors, controllers, and other peripherals via serial ports. During production testing, these cases ensure that all serial ports can transmit and receive data normally, preventing peripheral data from failing to upload to the gateway due to serial port failure. During maintenance, if communication between peripherals and the gateway is abnormal, these test cases can quickly distinguish whether the problem lies with the gateway's serial port or the peripheral itself.

[0028] like Figure 3 The diagram illustrates a batch testing and intelligent retesting process designed based on the design concept of this invention. This process encompasses batch test execution, test result analysis, intelligent retesting triggering, and report generation. The specific steps are as follows: 1. Process Startup: After the user confirms that the test plan has been matched in the GUI interface, the user initiates a batch test command, and the process officially starts.

[0029] 2. Test case execution sequence: After receiving batch test instructions, the test execution engine extracts test cases in the order preset in the test plan and starts the test execution process.

[0030] 3. Test Case Type Determination: For each test case to be executed, the test execution engine first determines whether it is a normal test case or an asynchronous test case (time-consuming test task): ① If it is a normal test case: The test execution engine waits for the test case to complete, records its test results, and then continues to execute the next test case; ② If it is an asynchronous test case: The test execution engine submits the test case to a separate background thread, and does not need to wait for its execution result. It immediately continues to execute subsequent test cases, realizing the parallel execution of the main thread and asynchronous tasks.

[0031] 4. Verification of completion of all test cases: The test execution engine continues to execute test cases until all test cases have been completed (including the completion of normal test cases and the completion of asynchronous test cases in the background thread).

[0032] 5. Test Result Analysis: After all test cases have been executed, the data traceability and reporting module collects the result data of all test cases, and the intelligent retesting module automatically analyzes the result data to determine whether there are any failed test cases with the test result of failing.

[0033] 6. Intelligent retest trigger: If the analysis results indicate the existence of failed test cases, the system will push an intelligent retest prompt to the user through the GUI interface; after the user confirms, the intelligent retest module will filter out all failed test cases, load them into a new test list, and push the test list to the test execution engine to start the intelligent retest process.

[0034] 7. Retest Execution: The test execution engine starts batch retests according to the new test list (containing only failed test cases). During the retest, the execution rules of ordinary test cases and asynchronous test cases are followed. The retest results are stored in association with the original test order number.

[0035] 8. Report Generation: If the analysis result shows no failed test cases, or after the intelligent retest is completed, the data traceability and reporting module generates a structured test report based on the stored test data (including original test data and retest data); if there is a retest process, a final report containing the original test results and the retest results is generated.

[0036] 9. Process End: After the test report is generated, it can be viewed and exported by users through the GUI interface, and the entire batch testing and intelligent retesting process ends.

[0037] like Figure 4 The diagram shown illustrates the execution sequence of an asynchronous execution mode designed based on the design concept of this invention. Taking a single asynchronous test case as an example, multiple asynchronous test cases can be executed in parallel through multiple independent threads without blocking conflicts with the main test thread. Callback notifications are used to synchronize the results of asynchronous test cases to the main thread. This sequence diagram clearly presents the interaction sequence between the main test thread, the asynchronous scheduler, and the time-consuming test tasks. The specific sequence flow is as follows: 1. Asynchronous task startup: During the execution of batch tests, the main test thread extracts asynchronous test cases marked as time-consuming test tasks and sends an instruction to the built-in asynchronous scheduler to start the asynchronous task.

[0038] 2. Independent Thread Creation: After receiving the instruction from the main test thread, the asynchronous scheduler immediately creates an independent background thread for the time-consuming test task, which is dedicated to executing the time-consuming test task and avoids occupying the main test thread's resources; multiple asynchronous test cases can be executed in parallel through multiple independent threads (such as independent thread 1, independent thread 2).

[0039] 3. The main test thread continues to proceed: After sending a start command to the asynchronous scheduler and receiving a response, the main test thread does not wait for the execution result of the time-consuming test task, but immediately returns and continues to execute the subsequent test cases in the test plan, so as to realize the parallel progress of the main test thread and the time-consuming test task and avoid the main test queue from being blocked.

[0040] 4. Parallel execution process: The main test thread continuously executes subsequent test cases (sending start instructions for ordinary test cases or other asynchronous test cases). At the same time, time-consuming test tasks execute specific time-consuming operations (such as 4G module detection, dual-band module testing, etc.) in an independent background thread according to the preset test logic. The two run in parallel without conflict or interference.

[0041] 5. Asynchronous task execution complete: After the time-consuming test task completes all test operations in an independent thread, it generates the corresponding test results (pass / fail) and marks its own execution status as "completed".

[0042] 6. Callback Notification and Status Update: Time-consuming test tasks use a callback mechanism to feed back the "execution completed" status and test results to the asynchronous scheduler. After receiving the callback, the asynchronous scheduler sends a callback notification to the main test thread to synchronize the execution status and results of the time-consuming test task. After receiving the callback notification, the main test thread updates the test result status of the asynchronous test case and aggregates it with the results of other completed test cases to ensure the integrity and consistency of the overall test results.

[0043] By implementing the above timing process, the parallel execution of time-consuming test tasks and the main test thread is achieved, effectively solving the test queue blocking problem caused by time-consuming tasks and significantly improving the overall testing efficiency.

[0044] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the above embodiments do not limit the present invention in any way, and all technical solutions obtained by equivalent substitution or equivalent transformation fall within the protection scope of the present invention.

Claims

1. A gateway host adaptive closed-loop testing method based on intelligent pre-plan driven, characterized in that: Includes the following steps: S1. Manage test plans: Adopt a multi-level tree structure that includes device type, hardware model, functional module and test cases for visual editing of test plans, and support importing and exporting test plans as standardized format files; Set a time consumption threshold. Based on the execution time of the test cases, mark test cases with a time consumption less than or equal to the time consumption threshold as normal test cases, and mark test cases with a time consumption greater than the time consumption threshold as asynchronous test cases. S2. Load the device under test: Receive the configuration information of the device under test, select the corresponding test plan according to the device type of the device under test, select, load and display all test cases under the test plan, preset the execution order of the test cases and create a test case list; S3, Batch Testing: The main test thread executes all test cases in the test case list according to the preset execution order. For any test case, the test case is first marked: if it is a normal test case, the main test thread starts the normal test case and waits for the test to end. The main test thread updates the test results to the result database and then continues to execute the next test case. If it is an asynchronous test case, the asynchronous execution mode is adopted. The asynchronous test case is started by creating an independent thread, while the main test thread continues to execute the next test case. S4 Intelligent Retesting: After all test cases have been tested, filter out all test cases that failed, rebuild the test case list, and execute batch tests.

2. The gateway host adaptive closed-loop testing method based on intelligent pre-plan driven according to claim 1, characterized in that: In step S1, visual editing includes adding, deleting, modifying, moving up, and moving down nodes in a multi-level tree structure.

3. The gateway host adaptive closed-loop testing method based on intelligent pre-plan driven according to claim 1, characterized in that: In step S3, for asynchronous test cases, the main test thread does not wait for the test to finish and directly continues to execute the next test case; each asynchronous test case runs in parallel in the background through different independent threads, without blocking the sequential execution of ordinary test cases; after the asynchronous test case is completed, the test results are directly updated to the result database through an independent thread.

4. The gateway host adaptive closed-loop testing method based on intelligent pre-plan driving according to claim 1, characterized in that: In step S4, the testing process is completed after the number of times the batch test is re-executed reaches a set value or all test results pass.

5. The gateway host adaptive closed-loop testing method based on intelligent pre-plan driven according to claim 1, characterized in that: After step S4, continue to step S5; in step S5, generate a structured test report, and associate all test operations, process logs, test results and test reports with a unique test order number and save them to the result database, supporting the query of historical test records based on the test order number.

6. A gateway host adaptive closed-loop testing system based on intelligent pre-plan driven system, characterized in that: It includes a test plan management module, an equipment configuration and matching module, a test execution engine, an intelligent retesting module, and a data traceability and reporting module; The test plan management module allows for visual editing of test plans through a visual editing interface, supporting the creation, editing, import, and export of standardized format files for test plans. The test plans adopt a multi-level tree structure that includes device type, hardware model, functional modules, and test cases. The device configuration and matching module is used to receive and store the configuration information of the device to be tested, select the corresponding test plan according to the device type of the device to be tested, select, load and display the test cases under the test plan, preset the execution order of the test cases and establish a test case list; The test execution engine has a built-in asynchronous scheduler for executing batch test instructions, executing all test cases in the test case list in a preset execution order; The test execution engine identifies normal test cases and asynchronous test cases through the main test line. The main test thread starts normal test cases and waits for the test to end. The main test thread calls the asynchronous scheduler to create an independent thread to start asynchronous test cases, and executes normal test cases and asynchronous test cases in parallel. The intelligent retesting module, after the test execution engine has executed all test cases, filters out all test cases that failed and rebuilds the test case list, and calls the test execution engine a number of times. The data traceability and reporting module is used to generate structured test reports and store test records.

7. The gateway host adaptive closed-loop test system based on intelligent pre-plan driving according to claim 6, characterized in that: It also includes a permission management module to differentiate the operation permissions of system administrators and ordinary testers; among them, it includes editing test plans, importing / exporting standardized format files, and configuring the device under test to have system administrator permissions.

Images