A device joint debugging test method, system, terminal and medium

Abstract

This invention relates to the field of equipment testing, specifically disclosing a method, system, terminal, and medium for equipment integration testing. The method includes configuring an environment database and a test case database; extracting test cases to be executed from the test case database; selecting a target environment from normal environments for each test case; publishing the test cases to be executed in the target environment and collecting the execution results; updating the environment status of the target environment in the environment database based on the test case execution results (if the test case succeeds, the target environment status is normal; if the test case fails, the target environment status is abnormal); and real-time monitoring of the environment status of each environment, repairing abnormal environments, and updating the corresponding environment status in the environment database based on the repair results. This invention synchronizes the test case execution results to the environment status, selects the environment for executing test cases based on the environment status, and monitors and repairs the environment status, ensuring environment stability and test case success rate, thereby improving the efficiency of integration testing.

Description

Technical Field

[0001] This invention relates to the field of equipment testing, and specifically to a method, system, terminal, and medium for equipment commissioning and testing. Background Technology

[0002] The traditional process of testing equipment using automated testing tools is as follows: Figure 1 As shown, the test environment is prepared to ensure its availability; test cases are imported; unexecuted test cases are extracted to ensure that all test cases are executed; test cases are assigned to idle environments to ensure that only one test case is executed in one environment at a time; test results are collected and saved; and test reports are output.

[0003] In the aforementioned automated process, environment preparation and test case execution are separated. However, the test integration and debugging phase involves four subsystems: hardware, firmware, drivers, and system testing. This means joint testing of the code from these four subsystems significantly increases complexity and frequently leads to the following anomalies: 1) Test object anomalies prevent test cases from completing, thus failing to return the current test case's execution result and preventing the execution of the next test case; 2) Test code anomalies prevent test case execution, also failing to return the current test case's execution result and preventing the execution of the next test case; 3) Previous test cases may have caused some state values ​​in the test object to be corrupted even if no core dump occurs, resulting in unexpected test case execution results and increasing troubleshooting time and manpower. These test object anomalies or test code anomalies will be collectively referred to as test environment anomalies. When facing these test environment anomaly issues, traditional automated processes assign test cases to idle environments. If the abnormal environment is also idle, assigning test cases to the abnormal environment may lead to test case execution failures, reducing testing efficiency. If all tests are performed manually after the test environment is completed, a large amount of testing resources will be invested, similarly impacting integration and debugging efficiency. Summary of the Invention

[0004] To address the aforementioned issues, this invention provides a device integration testing method, system, terminal, and medium. It synchronizes the results of test case execution to the environment status, selects the environment for executing test cases based on the environment status, and monitors and repairs the environment status to ensure environment stability and test case success rate, thereby improving integration testing efficiency.

[0005] In a first aspect, the technical solution of the present invention provides a method for equipment commissioning and testing, comprising the following steps:

[0006] Configure the environment database and use case database;

[0007] Extract the test cases to be executed from the test case database, and select the target environment from the normal state environment for the test cases to be executed;

[0008] Publish the test cases to be executed to the target environment for execution, and collect the test case execution results;

[0009] Update the environment status of the target environment in the environment database based on the test case execution results. If the test case execution is successful, the environment status of the target environment is updated to normal; if the test case execution fails, the environment status of the target environment is updated to abnormal.

[0010] It monitors the environmental status of each environment in real time, repairs abnormal environments, and updates the environmental status of the corresponding environment in the environment database based on the repair results.

[0011] In an optional implementation, test cases to be executed are extracted from the test case database, and a target environment is selected from the normal state environment for the test cases to be executed, specifically including:

[0012] Step 1: Select test cases with the status "Init" from the test case database and add them to the queue of test cases to be executed;

[0013] Step 2: Select test cases with a status of Failed and an execution count of 1 from the test case database and add them to the queue of test cases to be executed;

[0014] Step 3: Check if the test case to be executed is not empty. If it is, proceed to step 4; otherwise, wait for the first preset time and return to step 1.

[0015] Step 4: Dequeue the first test case and select a target environment with a Ready state for the first test case.

[0016] Step 5: Check if the target environment has been obtained. If yes, proceed to step 6; otherwise, return to step 3.

[0017] Step 6: Update the environment status of the target environment to Running;

[0018] Step 7: Update the test case information of the first test case in the test case database, including incrementing the execution count by 1 and updating the environment IP address to the IP address of the selected target environment;

[0019] Step 8: Add the first test case to the test case execution shared queue.

[0020] In an optional implementation, selecting a target environment with a Ready state for the head of the queue use case specifically includes:

[0021] Step 1: Check if the environment label used to identify the environment type of the first use case in the use case database is empty. If it is, proceed to Step 2; otherwise, proceed to Step 5.

[0022] Step 2: Obtain the environment IP address of the first test case in the test case database;

[0023] Step 3: Check if there is an environment with the same environment IP address and a status of Ready in the environment database. If so, proceed to Step 4; otherwise, environment selection fails.

[0024] Step 4: Select the environment with the same environment IP address and the status "Ready" as the target environment. If the environment selection is successful, update the environment IP address of the first test case in the test case database to the IP address of the target environment.

[0025] Step 5: Check the test case status of the first test case in the queue. If the test case status is Init, proceed to step 6; if the test case status is Failed, proceed to step 8.

[0026] Step 6: Check if there is an environment with the same environment tag and a status of Ready in the environment database. If so, proceed to step 7; otherwise, environment selection fails.

[0027] Step 7: Select a target environment from the environments with the same environment label and a status of Ready. If the environment selection is successful, update the environment IP address of the first test case in the test case database to the IP address of the target environment.

[0028] Step 8: Check if there is an environment in the environment database that has the same environment tag and is in the Ready state, and whose environment IP address is different from the environment IP address of the first test case in the queue. If so, proceed to step 9; otherwise, proceed to step 10.

[0029] Step 9: Select a target environment from the environments with the same environment label and a status of Ready, and whose environment IP address is different from the environment IP address of the first test case in the queue. If the environment selection is successful, update the environment IP address of the first test case in the test case database to the IP address of the target environment.

[0030] Step 10: Check if the status of the environment whose environment IP address is the same as the environment IP address of the first test case in the queue is Ready. If yes, proceed to step 11; otherwise, environment selection fails.

[0031] Step 11: Select the environment whose environment IP address is the same as the environment IP address of the first test case as the target environment. If the environment selection is successful, update the environment IP address of the first test case in the test case database to the IP address of the target environment.

[0032] In one optional implementation, the test cases to be executed are published to the target environment for execution, and the execution results are collected, specifically including:

[0033] Step 1: Check if the test case execution shared queue is empty. If it is, wait for the second preset time and continue to execute Step 1; otherwise, execute Step 2.

[0034] Step 2: Start the background running subprocess for test case processing;

[0035] Step 2.1: Dequeue the first test case in the shared queue and send it to the corresponding target environment for execution;

[0036] Step 2.2: Subscribe to the execution results of test cases from the target environment and set the timeout.

[0037] Step 2.3: Check whether the execution result of the test case was successfully received within the timeout period. If so, set the test case status to Success; otherwise, set the test case status to Failed.

[0038] Step 2.4: Add the test case status to the test case result sharing queue, and return to step 1 after the background running subprocess for test case processing finishes.

[0039] In an optional implementation, the environment state of the target environment in the environment database is updated based on the test case execution result, specifically including:

[0040] Step 1: Check if the test case result sharing queue is empty. If it is, wait for the third preset time period and continue to execute Step 1; otherwise, execute Step 2.

[0041] Step 2: Retrieve the test case status from the test case result sharing queue and update it in the test case database;

[0042] Step 3: Check if the test case status is Success. If yes, proceed to Step 4; otherwise, proceed to Step 5.

[0043] Step 4: Update the environment status of the corresponding target environment in the environment database to Ready, and return to Step 1;

[0044] Step 5: Update the environment status of the corresponding target environment in the environment database to Failed, and return to Step 1.

[0045] In one optional implementation, the environmental status of each environment is detected in real time, abnormal environments are repaired, and the environmental status of the corresponding environment in the environment database is updated based on the repair results. Specifically, this includes:

[0046] Step 1: Check if there is an environment with a status of Failed. If so, proceed to Step 2; otherwise, wait for the fourth preset time period before continuing to execute Step 1.

[0047] Step 2: Update the status of the environment that is currently in the Failed state to Starting.

[0048] Step 3: Start the background subprocess of the restart environment;

[0049] Step 3.1: Restart the environment in the Starting state and set the timer to the fourth preset duration;

[0050] Step 3.2: After the fourth preset time, check if the restart environment status is "Starting". If it is, proceed to step 3.3; otherwise, proceed to step 3.4.

[0051] Step 3.3. Explanation: The environment restart failed. The restart environment status is reset to Failed. The restart environment background subprocess ends and returns to step 1.

[0052] Step 3.4 indicates that the environment restart was successful. The environment Ready status message is output to the process that subscribes to the environment Ready message. The process that subscribes to the environment Ready message will update the status of the restarted environment to Ready.

[0053] In an optional implementation, the process that subscribes to the environment Ready message will restart the environment and update its state to Ready, specifically including:

[0054] Step 1: Receive the environment Ready status message;

[0055] Step 2: Check if the corresponding environment exists in the environment database. If it exists, proceed to step 3; otherwise, proceed to step 4.

[0056] Step 3: Update the environment status in the environment database to Ready;

[0057] Step 4: Insert the corresponding environment into the environment database and configure its environment status as Ready.

[0058] Secondly, the technical solution of the present invention provides a device integration and testing system, comprising,

[0059] Database configuration module: Configures the environment database and test case database;

[0060] Environment selection module: Extracts test cases to be executed from the test case database and selects a target environment from the normal state environment for the test cases to be executed;

[0061] Test Case Deployment and Execution Module: Deploys the test cases to be executed to the target environment for execution and collects the test case execution results;

[0062] Environment status update module: Updates the environment status of the target environment in the environment database based on the test case execution results. If the test case execution is successful, the environment status of the target environment is updated to normal; if the test case execution fails, the environment status of the target environment is updated to abnormal.

[0063] Abnormal Environment Repair Module: Real-time detection of the environmental status of each environment, repair of abnormal environments, and updating the environmental status of the corresponding environment in the environment database based on the repair results.

[0064] Thirdly, the technical solution of the present invention provides a terminal, comprising:

[0065] Memory, used to store device integration and testing programs;

[0066] A processor is configured to implement the steps of the device integration testing method described above when executing the device integration testing program.

[0067] Fourthly, the present invention provides a computer-readable storage medium storing a device integration testing program, wherein the device integration testing program, when executed by a processor, implements the steps of the device integration testing method described in any of the above claims.

[0068] This invention provides a device integration testing method, system, terminal, and medium, which, compared to existing technologies, offers the following advantages: Before test case deployment, a normal environment is selected, ensuring each test case runs in a stable and clean environment, avoiding batch failures of subsequent test cases due to environment configuration contamination, and improving test case execution efficiency and success rate. During test case execution, the environment state is updated on a per-test-case basis, promptly identifying environment anomalies for subsequent environment restart and repair, thus improving environment stability. Simultaneously, real-time detection of environment anomalies leads to restart and repair, enhancing environment stability, and timely updating the environment state based on the repair results facilitates subsequent test case execution, improving environment utilization and test case execution efficiency. Attached Figure Description

[0069] To more clearly illustrate the technical solutions of the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0070] Figure 1 This is a schematic diagram of the traditional process of testing equipment using automated testing tools.

[0071] Figure 2 This is a schematic diagram illustrating the principle and flow of the equipment integration and testing method provided in this embodiment of the invention.

[0072] Figure 3 This is a schematic flowchart of a device integration and testing method according to an embodiment of the present invention.

[0073] Figure 4 This is a functional diagram of the equipment integration and testing architecture.

[0074] Figure 5 This is a schematic diagram of the interaction method of the equipment integration and testing architecture.

[0075] Figure 6 This is a schematic diagram of the use case database structure.

[0076] Figure 7 This is a schematic diagram of the environmental database structure.

[0077] Figure 8 This is a schematic diagram of a use case state machine.

[0078] Figure 9 This is a schematic diagram of the environmental state machine.

[0079] Figure 10 This is a schematic diagram of the use case extraction process.

[0080] Figure 11 This is a schematic diagram of the use case publishing and use case result subscription process.

[0081] Figure 12 This is a flowchart illustrating the use case processing flow.

[0082] Figure 13 This is a schematic diagram of the use case state update process.

[0083] Figure 14 This is a schematic diagram of the environment status query process.

[0084] Figure 15 This is a schematic diagram of the environmental status monitoring process.

[0085] Figure 16 This is a diagram illustrating the environment restart process.

[0086] Figure 17 This is a schematic diagram of the Ready message flow in the subscription environment.

[0087] Figure 18 This is a flowchart of the use case business plane.

[0088] Figure 19 This is a diagram illustrating the environment ready release process.

[0089] Figure 20 This is a schematic block diagram of a device integration and testing system provided in this embodiment of the invention.

[0090] Figure 21 This is a schematic diagram of the structure of a terminal provided in an embodiment of the present invention. Detailed Implementation

[0091] To enable those skilled in the art to better understand the present invention, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are merely some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0092] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0093] The key terms used in this invention will be explained below.

[0094] A core dump, also known as a kernel dump, is a file created when a program crashes or terminates abnormally. It saves the program's memory information, register state, stack information, and more. This file typically contains all the state information at the time of the crash, helping developers quickly locate and fix problems.

[0095] Zebu (Zero Bugs): Zebu is a hardware emulation system primarily used for verifying and debugging complex system-on-a-chip (SoC). It can accelerate the simulation process, improve verification efficiency, and support multiple debugging modes, such as prototype verification, verification acceleration, and low-power simulation.

[0096] Virtual Prototype (VP) is a virtual prototyping technology used for simulation and verification during product development. It allows developers to test and optimize products before actual manufacturing, thereby reducing development time and costs.

[0097] HAPS (High-performance ASIC Prototyping System) is a high-performance FPGA prototyping system provided by Synopsys. It is mainly used for prototyping ASIC and SoC designs, helping designers to perform functional verification and debugging before actual manufacturing, thereby accelerating the development process and reducing costs.

[0098] MQTT (Message Queuing Telemetry Transport): A lightweight, publish / subscribe-based messaging protocol, particularly suitable for communication between Internet of Things (IoT) devices.

[0099] Figure 2This is a schematic diagram illustrating the principle and flow of the device integration testing method provided in this embodiment of the invention. Test cases are assigned to environments in good condition, test results are collected, the environment status is updated based on the test results, and the environment is restarted based on the environment status. The environment status is then updated again based on the restart results. This embodiment, by assigning test cases to environments in good condition, avoids assigning test cases to idle environments. Instead, it checks the condition of the required environment before each test case assignment, ensuring that the test cases assigned to a good environment can be effectively executed. Simultaneously, the results of individual test cases are associated with the environment status. If the test case succeeds, the environment status is set to good; otherwise, the environment status is updated to abnormal. Upon detecting an abnormal environment status, the environment is isolated and restarted. This achieves dynamic perception and timely repair of the environment status during test case execution, improving the test case execution rate and success rate. Furthermore, the environment status is updated based on the status after restart. If the status is good after restart, it can continue to be used for test case execution; otherwise, it is set to abnormal again, awaiting identification and restart by the environment status monitoring module, improving environment stability and test case success rate. In this embodiment, when reclaiming test results, a time-limited reclamation is performed. The timeout can be differentiated according to the needs of each test case. If no response is received after the timeout, the test case status is considered to be Failed, thus promptly identifying abnormal environment issues of the test object or test code.

[0100] Figure 3 This is a schematic flowchart of a device integration and testing method according to an embodiment of the present invention. Figure 3 The executing entity can be a device integration testing system. The device integration testing method provided in this embodiment of the invention is executed by a computer device, and correspondingly, the device integration testing system runs on the computer device. Depending on different requirements, the order of the steps in this flowchart can be changed, and some steps can be omitted.

[0101] like Figure 3 As shown, the method includes the following steps.

[0102] S1, configuration environment database and use case database.

[0103] S2 extracts the test cases to be executed from the test case database and selects the target environment from the normal state environment for the test cases to be executed.

[0104] S3 publishes the test cases to be executed to the target environment for execution and collects the test case execution results.

[0105] S4 updates the environment status of the target environment in the environment database based on the test case execution result. If the test case execution is successful, the environment status of the target environment is updated to normal; if the test case execution fails, the environment status of the target environment is updated to abnormal.

[0106] S5 monitors the environmental status of each environment in real time, repairs abnormal environments, and updates the environmental status of the corresponding environment in the environment database based on the repair results.

[0107] This embodiment breaks away from the independent control of test environment preparation and test case execution in traditional automated processes. It synchronizes the results of test case execution with the environment status, monitors and repairs the environment status, and updates the environment status based on the repaired status, ensuring the stability of the environment and the success rate of test cases.

[0108] The equipment integration testing method in this embodiment is based on Figure 4 and Figure 5 The architecture shown is illustrated below. The device integration testing method of this embodiment will be further described in detail below, taking into account the device integration testing architecture. For example... Figure 4 and Figure 5 As shown, the equipment integration and testing architecture consists of three layers: management plane, control plane, and business plane.

[0109] Management plane – Use case pool management: User-oriented, supports importing, exporting, deleting and querying use cases, and mainly interacts with the use case database.

[0110] Management plane – Environment pool management: User-facing, supporting functions such as querying environment-related information from data blocks and restarting environments. Restarting an environment involves setting the environment status in the environment database to "Failed," thereby triggering the environment status monitoring mechanism to restart the environment.

[0111] Control plane – Use case control: Implements the extraction of use cases to be executed, publishes use cases to the selected environment and subscribes to the use case execution results, and updates the use case status based on the use case execution results.

[0112] Control plane – Environment control: Enables the updating and management of environment status, monitoring and repair of environment status, querying of environment status, and subscription to the environment Ready function.

[0113] Business plane - Use case broker: After the environment starts, the use case broker will start automatically. It interacts with the use case control plane through MQTT to realize the subscription of use cases, execution of use cases, and publication of use case results.

[0114] Business plane - Environment agent: After the environment starts, the environment agent will start automatically. The agent will determine whether the environment meets the test conditions based on the actual situation of the project. If it does, it will interact with the environment control plane through MQTT to register or update the environment's Ready status.

[0115] The use cases and environment management aspect primarily focus on user database operations. Figure 6 This is a diagram of the use case database structure. Figure 7 This is a schematic diagram of the environmental database structure.

[0116] like Figure 6 As shown, the use case database includes the following data structures.

[0117] Use case ID in the database: refers to the ID generated by the database after the use case is submitted.

[0118] Use case status: Values ​​include Init, Running, Failed, and Success.

[0119] Test case execution count: The number of times a test case is run. If a test case fails, it will be rerun.

[0120] Environment tag: The environment in which the test case runs. This tag can be written according to the project plan. Examples include different types of environments such as zebu, hamas, and VP.

[0121] Environment IP: The network IP address configured for the environment.

[0122] Timeout Duration: The estimated execution time of the test case, defaulting to 1 hour (this can be set according to the actual project requirements). Subsequent timeout settings will be based on this field. If a test case times out without a response, its status will be marked as Failed. This granular setting, done on a test case basis, allows for more precise control over the duration of each test case, improving environment utilization.

[0123] Execution start time: The start time of the most recent execution.

[0124] Execution completion time: The time when the most recent execution was completed.

[0125] Use case number, use case name, and use case parameters: the three basic elements of a use case.

[0126] like Figure 7 As shown, the use case database includes the following data structures.

[0127] Environment IP: The network IP configured for the environment.

[0128] Environment label: Same as the field description in the test case database, used to select the environment.

[0129] Environment status: Values ​​include Ready, Failed, Running, and Starting.

[0130] This embodiment introduces a use case state machine and an environment state machine to manage the use case state and environment state, respectively.

[0131] Figure 8 This is a schematic diagram of a use case state machine. Use cases are divided into 4 states according to automation requirements, and conditional transitions can occur between use case states.

[0132] Init: Refers to test cases that have not yet been executed. When the environment required by a test case exists and the environment status is Ready, the test case executor will set the test case to Running and dispatch it to the corresponding environment for execution;

[0133] Running: refers to a use case that is currently being executed.

[0134] Success: This means that the execution result of the test case meets expectations.

[0135] Failed: This means that the test case execution result does not meet expectations, or the test case is not completed within the specified time.

[0136] Figure 9 This is a schematic diagram of an environmental state machine. The environment is divided into four states according to the requirements of automation, and conditional transitions can be made between environmental states.

[0137] Ready: This refers to a stable and well-functioning environment after startup. The state of the environment determines whether test cases can be executed. When a test case needs to be assigned to this environment for execution, the state transitions to Running.

[0138] Running: This indicates that the environment is currently executing test cases. It will transition to Ready when the test cases have completed execution and met the test expectations.

[0139] Failed: This indicates an abnormal environment that prevents the test cases from being executed and requires repair. The test case transitions from the Running state to this state when it completes execution but fails to meet test expectations.

[0140] Starting: This indicates that the environment is restarting and test cases cannot be executed. When the environment status monitoring program detects that the environment status is Failed, it will set the environment to Starting and restart the environment.

[0141] The test case control plane of the equipment integration testing architecture mainly implements the functions of extracting test cases, publishing test cases, subscribing to test case results, and updating test case status.

[0142] The use case extraction process for the use case control plane involves step S2, which extracts the use cases to be executed from the use case database and selects the target environment from the normal state environment for the use cases to be executed. Figure 10 This is a flowchart illustrating the use case extraction process, such as... Figure 10 As shown, the specific steps include:

[0143] Step 1: Select test cases with the status "Init" from the test case database and add them to the queue of test cases to be executed.

[0144] Step 2: Select test cases with a status of Failed and an execution count of 1 from the test case database and add them to the queue of test cases to be executed.

[0145] Step 3: Check if the test case to be executed is not empty. If it is, proceed to step 4; otherwise, wait for the first preset time and return to step 1.

[0146] For example, the first preset duration is 10 seconds.

[0147] Step 4: Dequeue the first use case and select a target environment with a Ready status for the first use case.

[0148] It should be noted that the selection of the target environment with the state "Ready" for the first use case in the queue is implemented by the environment control plane, which will be described in detail later.

[0149] Step 5: Check if the target environment has been obtained. If yes, proceed to step 6; otherwise, return to step 3.

[0150] Step 6: Update the environment status of the target environment to Running.

[0151] Step 7: Update the use case information of the first use case in the use case database, including incrementing the execution count by 1 and updating the environment IP address to the IP address of the selected target environment.

[0152] It should be noted that the execution start time can be updated to the current time at the same time, and the test case status can be updated to Running.

[0153] Step 8: Add the first test case to the test case execution shared queue.

[0154] The test case extraction process in this embodiment prioritizes unexecuted test cases, then automatically retests test cases that failed once. This addresses the issue of environmental contamination causing test case execution results to fall short of expectations, improving test execution efficiency and environmental resource utilization. If the environment required for a test case is not ready, the process automatically proceeds to the next round of test case extraction, without affecting the timely execution of other test cases. It also allows for the submission of new test cases to the test case library at any time.

[0155] The use case release and use case result subscription process implementation step S3 is to release the use cases to be executed to the target environment for execution and collect the use case execution results. Figure 11 This is a schematic diagram of the use case publishing and use case result subscription process. It should be noted that in this embodiment, the extraction of use cases from the shared use case execution queue and the use case processing are handled by two separate processes. Figure 12 This is a flowchart illustrating the use case processing flow, such as... Figure 11 and Figure 12 As shown, the use case publishing and use case result subscription process specifically includes the following steps.

[0156] Step 1: Check if the shared queue for test case execution is empty. If it is, wait for the second preset time and continue executing Step 1; otherwise, execute Step 2.

[0157] Step 2: Start the background running subprocess for test case processing.

[0158] Step 2.1: Dequeue the first test case in the shared queue and send it to the corresponding target environment for execution.

[0159] Locate the target environment based on the environment IP address, and send the test case number, test case ID, test case parameters, etc. to the target environment for execution.

[0160] Step 2.2: Subscribe to the execution results of the test cases from the target environment and set the timeout.

[0161] Step 2.3: Check whether the execution result of the test case was successfully received within the timeout period. If so, set the test case status to Success; otherwise, set the test case status to Failed.

[0162] Step 2.4: Add the test case status to the test case result sharing queue, and return to step 1 after the background running subprocess for test case processing finishes.

[0163] This embodiment employs a shared queue for test case execution, separating test case extraction from the queue and test case dispatch into two separate processes. This allows for the addition of test cases at any time without affecting their dispatch and execution. Each test case executes in its own dedicated process, enabling rapid deployment and execution of test cases according to the maximum concurrent test cases supported by the current environment, maximizing resource utilization. Furthermore, fine-grained control over timeouts for each test case is possible, resolving issues where test cases fail to execute and return results due to abnormal test objects or test code. It also allows for rapid detection of performance degradation issues between versions. Additionally, test case results are not directly updated to the database; instead, they are placed in a shared queue, ensuring sole control over database updates and preventing operational conflicts without locks and slow operations with locks.

[0164] The use case state update process implementation step S4 updates the environment state of the target environment in the environment database based on the use case execution results. Figure 13 This is a diagram illustrating the use case state update process, such as... Figure 13 As shown, the use case status update process specifically includes the following steps.

[0165] Step 1: Check if the test case result sharing queue is empty. If it is, wait for the third preset time period and continue to execute Step 1. Otherwise, execute Step 2.

[0166] Step 2: Extract the test case status from the test case results sharing queue and update it in the test case database.

[0167] An alternative implementation is to update the execution end time in the test case database while updating the test case status.

[0168] Step 3: Check if the test case status is Success. If yes, proceed to Step 4; otherwise, proceed to Step 5.

[0169] Step 4: Update the environment status of the corresponding target environment in the environment database to Ready, and return to Step 1.

[0170] Step 5: Update the environment status of the corresponding target environment in the environment database to Failed, and return to Step 1.

[0171] In this embodiment, each result is retrieved sequentially from the shared queue of test case execution results. The test case status in the test case database is updated according to the test case result. If the test case status is "success", the environment status is updated to "Ready" to indicate that the environment can continue to execute the test case. If the test case status is not "success", the environment status is updated to "Failed" to indicate that the environment is abnormal and cannot continue to execute the test case, and needs to be restarted for repair.

[0172] The environmental control plane mainly implements functions such as environmental status query, environmental status update, environmental status monitoring, and environmental Ready message subscription.

[0173] The environment status query process of the environment control plane selects the target environment with the status of Ready for the first use case in the queue during the process of retrieving the use cases to be executed from the use case database. Figure 14 This is a schematic diagram of the environment status query process, such as... Figure 14 As shown, the environment status query process includes the following steps.

[0174] Step 1: Check if the environment label used to identify the environment type of the first use case in the use case database is empty. If it is, proceed to Step 2; otherwise, proceed to Step 5.

[0175] Step 2: Obtain the environment IP address of the first test case in the test case database.

[0176] Step 3: Check if there is an environment with the same environment IP address and a status of Ready in the environment database. If so, proceed to Step 4; otherwise, environment selection fails.

[0177] It should be noted that "environment with the same environment IP address" refers to an environment whose environment IP address is the same as the environment IP address of the first use case in the queue.

[0178] Step 4: Select the environment with the same environment IP address and a status of Ready as the target environment. If the environment selection is successful, update the environment IP address of the first test case in the test case database to the IP address of the target environment.

[0179] Step 5: Check the test case status of the first test case in the queue. If the test case status is Init, proceed to step 6. If the test case status is Failed, proceed to step 8.

[0180] Step 6: Check if there is an environment with the same environment tag and a status of Ready in the environment database. If so, proceed to step 7; otherwise, environment selection fails.

[0181] Step 7: Select a target environment from environments with the same environment label and a status of Ready. If the environment selection is successful, update the environment IP address of the first test case in the test case database to the IP address of the target environment.

[0182] Step 8: Check if there is an environment in the environment database with the same environment tag and a status of Ready, and whose environment IP address is different from the environment IP address of the first test case. If so, proceed to step 9; otherwise, proceed to step 10.

[0183] Step 9: Select a target environment from the environments with the same environment label and a status of Ready, and whose environment IP address is different from the environment IP address of the first test case in the queue. If the environment selection is successful, update the environment IP address of the first test case in the test case database to the IP address of the target environment.

[0184] Step 10: Check if the status of the environment whose environment IP address is the same as the environment IP address of the first test case is Ready. If yes, proceed to step 11; otherwise, environment selection fails.

[0185] Step 11: Select the environment whose environment IP address is the same as the environment IP address of the first test case as the target environment. If the environment selection is successful, update the environment IP address of the first test case in the test case database to the IP address of the target environment.

[0186] The environment status query process in this embodiment primarily focuses on the use case control plane determining whether a ready and usable environment exists before use case deployment. If a use case is expected to execute on a certain type of environment and its status is "Init," then an environment with a status of "Ready" is selected from the environment pool with the same label. If a use case is expected to execute on a certain type of environment and its status is "Failed" (failed on the first execution), then an environment with a status of "Ready," excluding the last test environment, is selected from the environment pool with the same label. This selection effectively eliminates use case failures caused by the environment. If a use case is expected to execute on a fixed environment, then the status of that fixed environment is queried each time.

[0187] The environmental status monitoring process of the environmental control plane implements step S5, which involves real-time detection of the environmental status of each environment, repair of abnormal environments, and updating the environmental status of the corresponding environment in the environmental database based on the repair results. Figure 15 This is a flowchart illustrating the environmental status monitoring process. It should be noted that if an abnormal environment is detected during monitoring, a separate environment restart procedure is used to repair the abnormal environment. Figure 16 This is a diagram illustrating the environment restart process, such as... Figure 15 and Figure 16 As shown, the environmental status monitoring process specifically includes the following steps.

[0188] Step 1: Check if there is an environment with a status of Failed. If so, proceed to Step 2; otherwise, wait for the fourth preset time period before continuing to execute Step 1.

[0189] For example, the fourth preset duration is 10 seconds.

[0190] Step 2: Update the status of the environment that is currently in the Failed state to Starting.

[0191] Step 3: Start the background subprocess of the restart environment.

[0192] Step 3.1: Restart the environment in the Starting state and set the timer to the fourth preset duration.

[0193] In one optional implementation, before restarting the environment in step 3.1, the software and hardware fault location information of the abnormal environment is collected, and the collected fault location information is saved for subsequent rapid fault location and analysis.

[0194] Step 3.2: After the fourth preset time, check whether the restart environment status is "Starting". If it is, proceed to step 3.3; otherwise, proceed to step 3.4.

[0195] Step 3.3. Explanation: The environment restart failed. The restart environment status is reset to Failed. The restart environment background subprocess ends and returns to Step 1.

[0196] Step 3.4 indicates that the environment restart was successful. The environment Ready status message is output to the process that subscribes to the environment Ready message. The process that subscribes to the environment Ready message will update the status of the restarted environment to Ready.

[0197] This embodiment continuously monitors the environment status in the environment database. When an environment status of "Failed" is detected, it is updated to "Starting" to prevent a restart from being triggered again when the environment is not yet fully started by the next detection time. The actual environment restart step is run as a separate subprocess to avoid blocking the restart of other environments due to long restart times. The environment restart subprocess is responsible for collecting hardware and software location information before restarting the environment. During restart, a timer is set to ensure that the environment starts up to the "Ready" state for executable test cases within the specified time. Otherwise, the environment status is set back to "Failed" and restarted to repair the environment upon the next detection. This solves the abnormal problem of an environment restarting but failing to start.

[0198] The environment control plane's subscription to the environment Ready message flow is used to update the restart environment's status to Ready. Figure 17 This is a diagram illustrating the Ready message flow in the subscription environment, such as... Figure 17 As shown, the subscription environment Ready message process specifically includes the following steps.

[0199] Step 1: Receive the environment Ready status message.

[0200] Step 2: Check if the corresponding environment exists in the environment database. If it exists, proceed to Step 3; otherwise, proceed to Step 4.

[0201] It should be noted that the environment Ready status message can include the environment IP address, and the environment database is checked based on the environment IP address.

[0202] Step 3: Update the environment status in the environment database to Ready.

[0203] Step 4: Insert the corresponding environment into the environment database and configure its environment status as Ready.

[0204] The Environment Ready message subscription process is primarily used to notify the Environment Control Plane when the environment meets the requirements for test case execution after the Environment Business Plane starts up, so that the environment can be selected again when subsequent test cases choose an environment. This process can be used for initial registration of the environment to the Environment Database upon environment startup, or for updating the status values ​​in the Environment Database after an environment restart.

[0205] The test case business plane is mounted in rc.local to enable automatic startup after the environment starts. Combined with the test case control plane, it subscribes to test cases published by the control plane. After receiving test case messages published by the test case control plane, it executes according to the test case steps. After execution, it publishes the test case results to the test case control plane via MQTT message. Figure 18 This is a flowchart of the use case business plane.

[0206] The environment business plane is mounted in rc.local to enable automatic startup after the environment starts. Its main process is to check whether the started environment meets the requirements for test case execution. If it does, it publishes an environment Ready message to the environment control plane to register the environment or update its status; otherwise, it does nothing and waits for the environment restart processing subprocess of the environment control plane to perform a timeout check and then sets the environment status to Failed for restart repair. Figure 19 This is a diagram illustrating the environment ready release process.

[0207] The above text provides a detailed description of an embodiment of a device integration testing method. Based on the device integration testing method described in the above embodiment, this invention also provides a device integration testing system corresponding to the method.

[0208] Figure 20 This is a schematic block diagram of a device integration testing system 2000 provided in this embodiment of the invention. The device integration testing system 2000 can be divided into multiple functional modules according to its functions. A module, as referred to in this invention, is a series of computer program segments that can be executed by at least one processor and perform a fixed function, and is stored in memory.

[0209] Database Configuration Module 2001: Configures the environment database and test case database.

[0210] Environment Selection Module 2002: Extracts test cases to be executed from the test case database and selects a target environment from the normal state environment for the test cases to be executed.

[0211] Use Case Publish and Execution Module 2003: Publishes the use cases to be executed to the target environment for execution and collects the execution results.

[0212] Environment Status Update Module 2004: Updates the environment status of the target environment in the environment database based on the test case execution results. If the test case execution is successful, the environment status of the target environment is updated to normal; if the test case execution fails, the environment status of the target environment is updated to abnormal.

[0213] Abnormal Environment Repair Module 2005: Real-time detection of the environmental status of each environment, repair of abnormal environments, and updating of the environmental status of the corresponding environment in the environment database based on the repair results.

[0214] In an optional implementation, the environment selection module 2002 extracts the test cases to be executed from the test case database and selects a target environment from the normal state environment for the test cases to be executed, specifically including:

[0215] Step 1: Select test cases with the status "Init" from the test case database and add them to the queue of test cases to be executed;

[0216] Step 2: Select test cases with a status of Failed and an execution count of 1 from the test case database and add them to the queue of test cases to be executed;

[0217] Step 3: Check if the test case to be executed is not empty. If it is, proceed to step 4; otherwise, wait for the first preset time and return to step 1.

[0218] Step 4: Dequeue the first test case and select a target environment with a Ready state for the first test case.

[0219] Step 5: Check if the target environment has been obtained. If yes, proceed to step 6; otherwise, return to step 3.

[0220] Step 6: Update the environment status of the target environment to Running;

[0221] Step 7: Update the test case information of the first test case in the test case database, including incrementing the execution count by 1 and updating the environment IP address to the IP address of the selected target environment;

[0222] Step 8: Add the first test case to the test case execution shared queue.

[0223] In an optional implementation, selecting a target environment with a Ready state for the head of the queue use case specifically includes:

[0224] Step 1: Check if the environment label used to identify the environment type of the first use case in the use case database is empty. If it is, proceed to Step 2; otherwise, proceed to Step 5.

[0225] Step 2: Obtain the environment IP address of the first test case in the test case database;

[0226] Step 3: Check if there is an environment with the same environment IP address and a status of Ready in the environment database. If so, proceed to Step 4; otherwise, environment selection fails.

[0227] Step 4: Select the environment with the same environment IP address and the status "Ready" as the target environment. If the environment selection is successful, update the environment IP address of the first test case in the test case database to the IP address of the target environment.

[0228] Step 5: Check the test case status of the first test case in the queue. If the test case status is Init, proceed to step 6; if the test case status is Failed, proceed to step 8.

[0229] Step 6: Check if there is an environment with the same environment tag and a status of Ready in the environment database. If so, proceed to step 7; otherwise, environment selection fails.

[0230] Step 7: Select a target environment from the environments with the same environment label and a status of Ready. If the environment selection is successful, update the environment IP address of the first test case in the test case database to the IP address of the target environment.

[0231] Step 8: Check if there is an environment in the environment database that has the same environment tag and is in the Ready state, and whose environment IP address is different from the environment IP address of the first test case in the queue. If so, proceed to step 9; otherwise, proceed to step 10.

[0232] Step 9: Select a target environment from the environments with the same environment label and a status of Ready, and whose environment IP address is different from the environment IP address of the first test case in the queue. If the environment selection is successful, update the environment IP address of the first test case in the test case database to the IP address of the target environment.

[0233] Step 10: Check if the status of the environment whose environment IP address is the same as the environment IP address of the first test case in the queue is Ready. If yes, proceed to step 11; otherwise, environment selection fails.

[0234] Step 11: Select the environment whose environment IP address is the same as the environment IP address of the first test case as the target environment. If the environment selection is successful, update the environment IP address of the first test case in the test case database to the IP address of the target environment.

[0235] In an optional implementation, the use case publishing and execution module 2003 publishes the use cases to be executed to the target environment for execution and collects the use case execution results, specifically including:

[0236] Step 1: Check if the test case execution shared queue is empty. If it is, wait for the second preset time and continue to execute Step 1; otherwise, execute Step 2.

[0237] Step 2: Start the background running subprocess for test case processing;

[0238] Step 2.1: Dequeue the first test case in the shared queue and send it to the corresponding target environment for execution;

[0239] Step 2.2: Subscribe to the execution results of test cases from the target environment and set the timeout.

[0240] Step 2.3: Check whether the execution result of the test case was successfully received within the timeout period. If so, set the test case status to Success; otherwise, set the test case status to Failed.

[0241] Step 2.4: Add the test case status to the test case result sharing queue, and return to step 1 after the background running subprocess for test case processing finishes.

[0242] In an optional implementation, the environment state update module 2004 updates the environment state of the target environment in the environment database based on the test case execution result, specifically including:

[0243] Step 1: Check if the test case result sharing queue is empty. If it is, wait for the third preset time period and continue to execute Step 1; otherwise, execute Step 2.

[0244] Step 2: Retrieve the test case status from the test case result sharing queue and update it in the test case database;

[0245] Step 3: Check if the test case status is Success. If yes, proceed to Step 4; otherwise, proceed to Step 5.

[0246] Step 4: Update the environment status of the corresponding target environment in the environment database to Ready, and return to Step 1;

[0247] Step 5: Update the environment status of the corresponding target environment in the environment database to Failed, and return to Step 1.

[0248] In an optional implementation, the abnormal environment repair module 2005 monitors the environmental status of each environment in real time, repairs abnormal environments, and updates the environmental status of the corresponding environment in the environment database based on the repair results. Specifically, this includes:

[0249] Step 1: Check if there is an environment with a status of Failed. If so, proceed to Step 2; otherwise, wait for the fourth preset time period before continuing to execute Step 1.

[0250] Step 2: Update the status of the environment that is currently in the Failed state to Starting.

[0251] Step 3: Start the background subprocess of the restart environment;

[0252] Step 3.1: Restart the environment in the Starting state and set the timer to the fourth preset duration;

[0253] Step 3.2: After the fourth preset time, check if the restart environment status is "Starting". If it is, proceed to step 3.3; otherwise, proceed to step 3.4.

[0254] Step 3.3. Explanation: The environment restart failed. The restart environment status is reset to Failed. The restart environment background subprocess ends and returns to step 1.

[0255] Step 3.4 indicates that the environment restart was successful. The environment Ready status message is output to the process that subscribes to the environment Ready message. The process that subscribes to the environment Ready message will update the status of the restarted environment to Ready.

[0256] In an optional implementation, the process that subscribes to the environment Ready message will restart the environment and update its state to Ready, specifically including:

[0257] Step 1: Receive the environment Ready status message;

[0258] Step 2: Check if the corresponding environment exists in the environment database. If it exists, proceed to step 3; otherwise, proceed to step 4.

[0259] Step 3: Update the environment status in the environment database to Ready;

[0260] Step 4: Insert the corresponding environment into the environment database and configure its environment status as Ready.

[0261] The equipment integration testing system of this embodiment is used to implement the aforementioned equipment integration testing method. Therefore, the specific implementation of this system can be found in the embodiment section of the equipment integration testing method above. Thus, the specific implementation can be referred to the description of the corresponding embodiments, and will not be elaborated here.

[0262] Furthermore, since the equipment integration testing system in this embodiment is used to implement the aforementioned equipment integration testing method, its function corresponds to the function of the above method, and will not be described again here.

[0263] Figure 21 A schematic diagram of a terminal 2100 provided in an embodiment of the present invention includes: a processor 2110, a memory 2120, and a communication unit 2130. The processor 2110 is used to implement the following steps when executing the device integration test program stored in the memory 2120:

[0264] Configure the environment database and use case database;

[0265] Extract the test cases to be executed from the test case database, and select the target environment from the normal state environment for the test cases to be executed;

[0266] Publish the test cases to be executed to the target environment for execution, and collect the test case execution results;

[0267] Update the environment status of the target environment in the environment database based on the test case execution results. If the test case execution is successful, the environment status of the target environment is updated to normal; if the test case execution fails, the environment status of the target environment is updated to abnormal.

[0268] It monitors the environmental status of each environment in real time, repairs abnormal environments, and updates the environmental status of the corresponding environment in the environment database based on the repair results.

[0269] The present invention also provides a computer storage medium, which may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM), etc.

[0270] The computer storage medium stores a device integration testing program, which, when executed by the processor, performs the following steps:

[0271] Configure the environment database and use case database;

[0272] Extract the test cases to be executed from the test case database, and select the target environment from the normal state environment for the test cases to be executed;

[0273] Publish the test cases to be executed to the target environment for execution, and collect the test case execution results;

[0274] Update the environment status of the target environment in the environment database based on the test case execution results. If the test case execution is successful, the environment status of the target environment is updated to normal; if the test case execution fails, the environment status of the target environment is updated to abnormal.

[0275] It monitors the environmental status of each environment in real time, repairs abnormal environments, and updates the environmental status of the corresponding environment in the environment database based on the repair results.

[0276] The above-disclosed embodiments are merely preferred embodiments of the present invention, but the present invention is not limited thereto. Any non-creative variations that can be conceived by those skilled in the art, as well as any improvements and modifications made without departing from the principles of the present invention, should fall within the protection scope of the present invention.

Claims

1. A method for equipment commissioning and testing, characterized in that, Includes the following steps: Configure the environment database and use case database; Extracting test cases to be executed from the test case database, and selecting target environments for the test cases from normal environments, includes: Step 1, selecting test cases with the status "Init" from the test case database and adding them to the test case queue; Step 2, selecting test cases with the status "Failed" and an execution count of 1 from the test case database and adding them to the test case queue; Step 3, checking if the test cases to be executed are not empty, if so, proceeding to Step 4, otherwise waiting for a first preset time and returning to Step 1; Step 4, dequeuing the test case at the head of the queue and selecting a target environment with the status "Ready" for the test case at the head of the queue; Step 5, checking if the target environment has been obtained, if so, proceeding to Step 6, otherwise returning to Step 3; Step 6, updating the environment status of the target environment to "Running"; Step 7, updating the test case information of the test case at the head of the queue in the test case database, including incrementing the execution count by 1 and updating the environment IP address to the IP address of the selected target environment; Step 8, adding the test case at the head of the queue to the test case execution shared queue; Publish the test cases to be executed to the target environment for execution, and collect the test case execution results; Update the environment status of the target environment in the environment database based on the test case execution results. If the test case execution is successful, the environment status of the target environment is updated to normal; if the test case execution fails, the environment status of the target environment is updated to abnormal. It monitors the environmental status of each environment in real time, repairs abnormal environments, and updates the environmental status of the corresponding environment in the environment database based on the repair results.

2. The equipment commissioning and testing method according to claim 1, characterized in that, Select a target environment with a Ready state for the first use case in the queue, specifically including: Step 1: Check if the environment label used to identify the environment type of the first use case in the use case database is empty. If it is, proceed to Step 2; otherwise, proceed to Step 5. Step 2: Obtain the environment IP address of the first test case in the test case database; Step 3: Check if there is an environment with the same environment IP address and a status of Ready in the environment database. If so, proceed to Step 4; otherwise, environment selection fails. Step 4: Select the environment with the same environment IP address and the status "Ready" as the target environment. If the environment selection is successful, update the environment IP address of the first test case in the test case database to the IP address of the target environment. Step 5: Check the test case status of the first test case in the queue. If the test case status is Init, proceed to step 6; if the test case status is Failed, proceed to step 8. Step 6: Check if there is an environment with the same environment tag and a status of Ready in the environment database. If so, proceed to step 7; otherwise, environment selection fails. Step 7: Select a target environment from the environments with the same environment label and a status of Ready. If the environment selection is successful, update the environment IP address of the first test case in the test case database to the IP address of the target environment. Step 8: Check if there is an environment in the environment database that has the same environment tag and is in the Ready state, and whose environment IP address is different from the environment IP address of the first test case in the queue. If so, proceed to step 9; otherwise, proceed to step 10. Step 9: Select a target environment from the environments with the same environment label and a status of Ready, and whose environment IP address is different from the environment IP address of the first test case in the queue. If the environment selection is successful, update the environment IP address of the first test case in the test case database to the IP address of the target environment. Step 10: Check if the status of the environment whose environment IP address is the same as the environment IP address of the first test case in the queue is Ready. If yes, proceed to step 11; otherwise, environment selection fails. Step 11: Select the environment whose environment IP address is the same as the environment IP address of the first test case as the target environment. If the environment selection is successful, update the environment IP address of the first test case in the test case database to the IP address of the target environment.

3. The equipment commissioning and testing method according to claim 1, characterized in that, Publish the test cases to be executed to the target environment for execution, and collect the execution results of the test cases, specifically including: Step 1: Check if the test case execution shared queue is empty. If it is, wait for the second preset time and continue to execute Step 1; otherwise, execute Step 2. Step 2: Start the background running subprocess for test case processing; Step 2.1: Dequeue the first test case in the shared queue and send it to the corresponding target environment for execution; Step 2.2: Subscribe to the execution results of test cases from the target environment and set the timeout. Step 2.3: Check whether the execution result of the test case was successfully received within the timeout period. If so, set the test case status to Success; otherwise, set the test case status to Failed. Step 2.4: Add the test case status to the test case result sharing queue, and return to step 1 after the background running subprocess for test case processing finishes.

4. The equipment commissioning and testing method according to claim 3, characterized in that, Update the target environment's environment status in the environment database based on the test case execution results, specifically including: Step 1: Check if the test case result sharing queue is empty. If it is, wait for the third preset time period and continue to execute Step 1; otherwise, execute Step 2. Step 2: Retrieve the test case status from the test case result sharing queue and update it in the test case database; Step 3: Check if the test case status is Success. If yes, proceed to Step 4; otherwise, proceed to Step 5. Step 4: Update the environment status of the corresponding target environment in the environment database to Ready, and return to Step 1; Step 5: Update the environment status of the corresponding target environment in the environment database to Failed, and return to Step 1.

5. The equipment commissioning and testing method according to claim 4, characterized in that, Real-time monitoring of the environmental status of each environment, repair of abnormal environments, and updating the environmental status of the corresponding environment in the environment database based on the repair results, specifically including: Step 1: Check if there is an environment with a status of Failed. If so, proceed to Step 2; otherwise, wait for the fourth preset time period before continuing to execute Step 1. Step 2: Update the status of the environment that is currently in the Failed state to Starting. Step 3: Start the background subprocess of the restart environment; Step 3.1: Restart the environment in the Starting state and set the timer to the fourth preset duration; Step 3.2: After the fourth preset time, check if the restart environment status is "Starting". If it is, proceed to step 3.3; otherwise, proceed to step 3.

4. Step 3.

3. Explanation: The environment restart failed. The restart environment status is reset to Failed. The restart environment background subprocess ends and returns to step 1. Step 3.4 indicates that the environment restart was successful. The environment Ready status message is output to the process that subscribes to the environment Ready message. The process that subscribes to the environment Ready message will update the status of the restarted environment to Ready.

6. The equipment commissioning and testing method according to claim 5, characterized in that, The process that subscribes to the environment Ready message will restart the environment and update its status to Ready, specifically including: Step 1: Receive the environment Ready status message; Step 2: Check if the corresponding environment exists in the environment database. If it exists, proceed to step 3; otherwise, proceed to step 4. Step 3: Update the environment status in the environment database to Ready; Step 4: Insert the corresponding environment into the environment database and configure its environment status as Ready.

7. A device integration and testing system, characterized in that, include, Database configuration module: Configures the environment database and test case database; Environment Selection Module: Extracts test cases to be executed from the test case database and selects a target environment from normal environments for the test cases to be executed. This includes: Step 1, selecting test cases with the status "Init" from the test case database and adding them to the test case queue; Step 2, selecting test cases with the status "Failed" and an execution count of 1 from the test case database and adding them to the test case queue; Step 3, checking if the test cases to be executed are not empty. If so, proceed to Step 4; otherwise, wait for a first preset time and return to Step 1; Step 4, dequeueing the test case at the head of the queue and selecting a target environment with the status "Ready" for it; Step 5, checking if the target environment has been obtained. If so, proceed to Step 6; otherwise, return to Step 3; Step 6, updating the environment status of the target environment to "Running"; Step 7, updating the test case information of the test case at the head of the queue in the test case database, including incrementing the execution count by 1 and updating the environment IP address to the IP address of the selected target environment; Step 8, adding the test case at the head of the queue to the test case execution shared queue. Test Case Deployment and Execution Module: Deploys the test cases to be executed to the target environment for execution and collects the test case execution results; Environment status update module: Updates the environment status of the target environment in the environment database based on the test case execution results. If the test case execution is successful, the environment status of the target environment is updated to normal; if the test case execution fails, the environment status of the target environment is updated to abnormal. Abnormal Environment Repair Module: Real-time detection of the environmental status of each environment, repair of abnormal environments, and updating the environmental status of the corresponding environment in the environment database based on the repair results.

8. A terminal, characterized in that, include: Memory, used to store device integration and testing programs; A processor is configured to implement the steps of the device integration testing method as described in any one of claims 1-6 when executing the device integration testing program.

9. A computer-readable storage medium, characterized in that, The readable storage medium stores a device integration test program, which, when executed by a processor, implements the steps of the device integration test method as described in any one of claims 1-6.

Images