Automated Testing Method, System, Program Product and Storage Medium for Urban Lighting Monitoring Equipment

Abstract

The present application provides an automated testing method, system, program product and storage medium for urban lighting monitoring devices, relating to the field of urban lighting monitoring. The general communication interface, as a data interaction channel, can accept data transmission from different urban lighting monitoring devices. The general protocol encoding and decoding interface then parses or encodes the data and generates test cases according to preset rules, accurately positioning the direction for subsequent testing. The test context constructed based on these elements updates the current test progress in real time, detailedly records the current test details and the content of the data reported by urban lighting monitoring devices, covering all-stage event information from the preparation to the start, completion and end of the test, and navigates the test process. It makes the whole test process closely connected and in good order, realizes the automated testing of urban lighting monitoring devices, and improves the test efficiency.

Description

Technical Field

[0001] This application relates to the field of urban lighting monitoring, and particularly to an automated testing method, system, program product, and storage medium for urban lighting monitoring devices. Background Art

[0002] Currently, for the testing of urban lighting monitoring devices, when faced with differences in communication methods and protocols of different devices, technicians first obtain the software provided by the manufacturer, and then, according to the operation process set by the software, gradually input test instructions. For example, for the data acquisition function of the device, click the corresponding data acquisition start button in the software interface, and then observe whether the collected data displayed by the software is within the expected range; for the control instruction execution function, input specific control parameters in the software, such as the lighting brightness adjustment instruction, and then check the actual lighting brightness change of the device.

[0003] However, this testing method that relies on specific devices and manufacturer software has many drawbacks. Since each device may require separate writing of a test system or manual operation, when faced with large-scale testing tasks, the problem of low efficiency is particularly prominent, greatly prolonging the development cycle and delaying the delivery schedule. Summary of the Invention

[0004] This application provides an automated testing method, system, program product, and storage medium for urban lighting monitoring devices to improve testing efficiency.

[0005] In a first aspect, this application provides an automated testing method for urban lighting monitoring devices, including: performing data interaction with different urban lighting monitoring devices through a general communication interface, and using the received data as input data; parsing the input data through a general protocol encoding and decoding interface to obtain a standard data structure that the program can process; obtaining test cases according to preset rules in combination with the standard data structure; constructing a test context based on the general communication interface, the general protocol encoding and decoding interface, and the test cases, where the test context updates the current test progress, the text description of the current test details, and the descriptive text content of the data reported by the urban lighting monitoring device, including test preparation events, test start events, test completion events, and test end events; sequentially executing each test item in the test cases; after execution, determining the test result. When the test result is a failure and the cumulative failure times of the corresponding test item do not exceed the preset retry times threshold, retesting the corresponding test item; when the test result is a success or the failure times exceed the retry times threshold, terminating the retry operation for the corresponding test item; at the same time, regardless of whether the corresponding test item is a success or a failure, generating an event corresponding to the test result status of the test item according to the preset event triggering and generation mechanism and publishing it; using an event scheduler to process the events generated by the test context.

[0006] By adopting the above technical solutions, the universal communication interface, as a channel for data interaction, can accept the data inflow from different urban lighting monitoring devices, avoiding the tediousness of frequently adjusting the communication settings due to differences in equipment. The universal protocol codec interface parses the input data, accurately extracts the standard data structure that the key information conversion program can process, and generates test cases according to preset rules to accurately locate the direction for subsequent tests. The test context constructed based on these elements updates the current test progress in real time, records the current test details and the content of the data reported by the urban lighting monitoring equipment in detail, covers the event information of the entire stage of the test from preparation to start, completion to end, and navigates the test process. Execute each test item in the test case in sequence, and advance the test process in a rigorous and orderly manner. At the same time, according to the preset event triggering and generation mechanism, generate and publish events corresponding to the test result status, and use the event scheduler to efficiently process the events generated by the test context, so that the entire test process is closely connected and orderly, realizing the automated testing of urban lighting monitoring equipment and improving test efficiency.

[0007] In combination with the first aspect, after sequentially executing the steps of each test item in the test case, the method further includes: sending an instruction to the urban lighting monitoring device through a general communication interface according to a preset time sequence and interval; after sending the instruction, monitoring the response of the urban lighting monitoring device through the general communication interface and the general protocol encoding / decoding interface. If a timing conflict is found in the urban lighting monitoring device, determine the conflicting urban lighting monitoring device and the corresponding urban lighting monitoring device, where the corresponding urban lighting monitoring device is the urban lighting monitoring device that should perform operations in the correct time sequence without conflict; command the corresponding urban lighting monitoring device to send a synchronization instruction to the conflicting urban lighting monitoring device through the general communication interface, receive the reply instruction sent by the conflicting urban lighting monitoring device using the general communication interface, and parse through the general protocol encoding / decoding interface to obtain the sending time and receiving time of the synchronization instruction; obtain a first time difference through the sending time, receiving time, and a preset correction parameter; respectively obtain a second time difference of the automated test system of the urban lighting monitoring device for the conflicting urban lighting monitoring device and a third time difference of the automated test system of the urban lighting monitoring device for the corresponding urban lighting monitoring device; calculate the deviation of the conflicting urban lighting monitoring device, where the deviation is the current time of the conflicting urban lighting monitoring device minus the current time of the automated test system of the urban lighting monitoring device minus the second time difference; obtain the time function of the conflicting urban lighting monitoring device, where the time function is used to correct the time of the data sent by the conflicting urban lighting monitoring device; the calculation method of the time function is: the first time difference plus the current time of the conflicting urban lighting monitoring device minus the current time of the conflicting urban lighting monitoring device minus the second time difference to obtain a first intermediate quantity; the first intermediate quantity is multiplied by a preset parameter to obtain a second intermediate quantity; the current time of the conflicting urban lighting monitoring device plus the second intermediate quantity to obtain the time function.

[0008] By adopting the above technical solution, when multiple devices are running, the response situation is monitored through the general communication interface. Once a timing conflict is found, a synchronization instruction is sent through the corresponding device and the time difference and deviation are calculated to obtain the time function to correct the data time of the conflicting device. The communication and data interaction among devices proceed orderly under the mechanism, and conflicts caused by differences in device response and processing time sequences can be corrected in a timely manner, ensuring the accuracy and coherence of the test context information.

[0009] In combination with the first aspect, in some embodiments, the steps of using an event scheduler to process events generated by the test context specifically include: dividing the events into three priority levels: high, medium, and low according to a preset priority table; adding the events to the priority queue according to the time of generation, and at the same time changing the waiting time of the events according to the priority level, where the waiting time decreases sequentially from high to low according to the priority level; processing the events in the priority queue in the order of waiting time.

[0010] By adopting the above technical solutions, the event levels are divided according to a preset priority table and the waiting time is changed accordingly, and the events in the priority queue are processed according to the waiting time. As time increases, the rate of increase in the waiting time of high-priority events increases, and the rate of increase in the waiting time of low-priority events decreases, enabling high-priority events to be processed preferentially, avoiding untimely processing, and thereby improving the overall test reliability.

[0011] Combined with the first aspect, the general communication interface includes: communication parameters, establishing communication, starting and stopping communication, data sending and receiving. Among them, the communication parameters support socket communication and MQTT communication. When establishing communication, if the urban lighting monitoring device is a TCP connection, a TCP server is established; if the urban lighting monitoring device is a UDP connection, a UDP server is established; if the urban lighting monitoring device is an MQTT connection, it connects to the MQTT server as an MQTT client.

[0012] By adopting the above technical solutions, the general communication interface supports multiple communication methods and can flexibly establish corresponding server or client connections according to the connection type of the urban lighting monitoring device. In the scenario of diverse communication requirements of urban lighting monitoring devices, it can adapt to different device communications, ensure the smooth progress of data interaction, enhance the compatibility and flexibility of the connection between the test system and various devices, and reduce connection and data transmission obstacles caused by communication method differences.

[0013] Combined with the first aspect, the general protocol encoding and decoding interface includes message unpacking, message verification, and function code extraction. Message unpacking is to split the input data into multiple messages according to the preset message header, message tail, and message length bytes. Message verification is to judge whether the message is correct according to the preset verification method. Function code extraction is to parse out the corresponding device functions in the message.

[0014] By adopting the above technical solutions, the message unpacking, verification, and function code extraction functions of the general protocol encoding and decoding interface cooperate with each other. Unpacking splits the input data according to preset rules, verification ensures the correctness of the message, and function code extraction clarifies the device functions. This makes the data processing flow clear and efficient, can quickly and accurately parse the data, provides a reliable basis for the accurate execution of subsequent test cases, and improves the data processing quality and speed of the entire test process.

[0015] Combined with the first aspect, the test cases include: checking whether the device is online, checking the switch-on and switch-off functions, checking the device working conditions, checking the device working parameters, checking the device communication parameters, and checking the device information.

[0016] By adopting the above technical solutions, the test cases cover various inspection contents of the equipment, and comprehensively detect from online status to functions, operating conditions, parameters, and basic information, etc. This comprehensiveness conducts a comprehensive evaluation of the equipment, avoids missing key detection points, ensures that the urban lighting monitoring equipment meets the requirements in all aspects, improves the integrity and effectiveness of the test, and helps to improve the equipment quality and system stability.

[0017] Combined with the first aspect, the event scheduler is an ordered blocking queue that processes the events published by the test context in the order of first in first out.

[0018] By adopting the above technical solutions, the event scheduler, as an ordered blocking queue, processes the events published by the test context in the order of first in first out. This makes the event processing process standardized and orderly, avoiding chaos and cut-in phenomena. When multiple events occur concurrently, it can handle them in an orderly manner, ensuring that each event is reasonably processed and guaranteeing the stable operation of the test system.

[0019] In a second aspect, the present application provides an automated test system for urban lighting monitoring equipment. The automated test system for urban lighting monitoring equipment includes: one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is used to store computer program code. The computer program code includes computer instructions, and the one or more processors call the computer instructions to enable the automated test system for urban lighting monitoring equipment to execute the methods described in the first aspect and any possible implementation manner in the first aspect.

[0020] In a third aspect, the present application provides a computer program product containing instructions. When the computer program product runs on the automated test system for urban lighting monitoring equipment, it enables the automated test system for urban lighting monitoring equipment to execute the methods described in the first aspect and any possible implementation manner in the first aspect.

[0021] In a fourth aspect, the present application provides a computer-readable storage medium including instructions. When the instructions run on the automated test system for urban lighting monitoring equipment, it enables the automated test system for urban lighting monitoring equipment to execute the methods described in the first aspect and any possible implementation manner in the first aspect.

[0022] One or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages:

[0023] 1. As a channel for data interaction, the universal communication interface can accept data inflows from different urban lighting monitoring devices, avoiding the tediousness of frequently adjusting communication settings due to differences in equipment. The universal protocol encoding and decoding interface parses the input data, accurately extracts key information and converts it into a standard data structure that the program can process, and generates test cases based on preset rules to accurately locate the direction for subsequent tests. The test context constructed based on these elements updates the current test progress in real time, records the current test details and the content of the data reported by the urban lighting monitoring equipment in detail, covers the event information of the entire stage of the test from preparation to start, completion to end, and navigates the test process. Execute each test item in the test case in sequence, and advance the test process in a rigorous and orderly manner. At the same time, according to the preset event triggering and generation mechanism, generate and publish events corresponding to the test result status, and use the event scheduler to efficiently process the events generated by the test context, so that the entire test process is closely connected and orderly, realizing the automated testing of urban lighting monitoring equipment and improving test efficiency.

[0024] 2. When multiple devices are running, the response is monitored with the help of a universal communication interface. Once a timing conflict is found, a synchronization command is sent through the corresponding device and the time difference and deviation are calculated to obtain a time function to correct the data time of the conflicting device. The communication and data interaction between devices are carried out in an orderly manner under the mechanism, and conflicts caused by differences in device response and processing timing can be corrected in a timely manner, ensuring the accuracy and consistency of the test context information.

[0025] 3. Divide the event levels according to the preset priority table and change the waiting time accordingly, and process the events in the priority queue according to the waiting time. As time goes by, the rate at which the waiting time of high-priority events increases increases, and the rate at which the waiting time of low-priority events increases decreases, so that high-priority events can be processed first, avoiding untimely processing, thereby improving the overall test reliability. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 This is a flow chart of an automated testing method for urban lighting monitoring equipment in an embodiment of the present application;

[0027] Figure 2 This is another flow chart of the automated testing method for urban lighting monitoring equipment in an embodiment of the present application;

[0028] Figure 3 This is a specific flow chart of step S108 in the embodiment of the present application;

[0029] Figure 4 It is an exemplary hardware structure diagram of the automated testing system for urban lighting monitoring equipment in an embodiment of the present application. DETAILED DESCRIPTION

[0030] The terms used in the following embodiments of this application are only for the purpose of describing specific embodiments and are not intended to limit this application. As used in the specification and appended claims of this application, the singular forms "a", "an", "the", "above-mentioned", "said", and "this" are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used in this application refers to and includes any or all possible combinations of one or more of the listed items.

[0031] Hereinafter, the terms "first" and "second" are only used for descriptive purposes and should not be construed as implying or suggesting relative importance or implicitly indicating the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include one or more of such features. In the description of the embodiments of this application, unless otherwise specified, the meaning of "a plurality" is two or more.

[0032] Please refer to Figure 1 , Figure 1 which is a schematic flowchart of a process of the automated test method for urban lighting monitoring devices in the embodiments of this application;

[0033] S101. Perform data interaction with different urban lighting monitoring devices through a general communication interface, and the received data is used as input data;

[0034] Among them, the general communication interface represents a standardized information transmission channel, which refers to an interface module that can be compatible with multiple types of data transmission protocols and connection methods and is used to realize the information interaction and docking between the test system and different urban lighting monitoring devices.

[0035] In some embodiments, when the test system is started and the physical connection with the urban lighting monitoring device is completed, the general communication interface starts to work. It first identifies and initializes the configured connection device, determines the communication parameters of the device, such as the baud rate, IP address, etc. (if it is a network connection). Then, it continuously listens for data sending requests from the device end. Once data is received, it completely receives and stores it in the specified data buffer area, and the received data is the input data for subsequent processing.

[0036] In some embodiments, the general communication interface includes: communication parameters, establishing communication, starting and stopping communication, data sending and receiving. Among them, the communication parameters support socket communication and MQTT communication. When establishing communication, if the urban lighting monitoring device is a TCP connection, a TCP server is established; if the urban lighting monitoring device is a UDP connection, a UDP server is established; if the urban lighting monitoring device is an MQTT connection, it connects to the MQTT server as an MQTT client.

[0037] It can be seen that the general communication interface supports multiple communication methods and can flexibly establish corresponding server or client connections according to the connection types of urban lighting monitoring devices. In scenarios with diverse communication requirements of urban lighting monitoring devices, it can adapt to different device communications, ensure the smooth progress of data interaction, enhance the compatibility and flexibility of the connection between the test system and various devices, and reduce connection and data transmission obstacles caused by differences in communication methods.

[0038] In some embodiments, in the design phase of the communication interface, an interface ITransport is constructed, which covers functions such as opening communication, closing communication, sending data, and receiving data. "Opening communication" is used to establish a connection, and "closing communication" can terminate the connection and release resources. "Sending data" can transmit information such as instructions to urban lighting monitoring devices, and "receiving data" can obtain device response data.

[0039] This interface supports common communication methods. For example, TCP / UDP can meet the stable and efficient data transmission under network connections and is suitable for large-scale monitoring networks; MQTT, as a lightweight Internet of Things message transmission protocol, has advantages in scenarios with limited resources or high real-time requirements. In actual applications, this interface can be flexibly implemented according to the specific requirements of urban lighting monitoring projects, such as scale, device distribution, and performance requirements, to build an adapted communication link to ensure the smooth and stable operation of data interaction in the test system.

[0040] S102. Parse the input data through the general protocol encoding and decoding interface to obtain a standard data structure that the program can process;

[0041] Among them, the general protocol encoding and decoding interface refers to a functional module dedicated to processing data format conversion and parsing, which means that according to the established protocol specifications, the input data is structurally decomposed and interpreted to convert the received raw data into a recognizable form.

[0042] In some embodiments, when the general communication interface receives input data and stores it in the buffer, the general protocol encoding and decoding interface is triggered to start. It first reads the data in the buffer, determines the starting position of the data according to the preset protocol header identifier, and then determines the valid range of the data according to the message structure specified by the protocol, such as the message length field. Then, a decoding operation is performed on the data to convert binary or other encoded data into a readable text or numerical form, extract each field information in the message, and combine them into program data with clear semantics, so as to further generate test cases based on these data later, ensuring the accuracy and standardization of data parsing and enabling the test process to proceed based on correct data information.

[0043] In some embodiments, the general protocol encoding and decoding interface includes message unpacking, message verification, and function code extraction. Message unpacking divides the input data into multiple messages according to the preset message header, message tail, and message length byte. Message verification determines whether the message is correct according to the preset verification method. Function code extraction parses the corresponding device function in the message.

[0044] It can be seen that the message unpacking, verification, and function code extraction functions of the general protocol encoding and decoding interface cooperate with each other. Unpacking divides the input data according to the preset rules, verification ensures the correctness of the message, and function code extraction clarifies the device function. This makes the data processing process clear and efficient, can quickly and accurately parse the data, provides a reliable basis for the accurate execution of subsequent test cases, and improves the data processing quality and speed of the entire test process.

[0045] In some embodiments, in the process of parsing the input data through the general protocol encoding and decoding interface to obtain the data, the interface IProtocol constructed in the protocol encoding and decoding design stage plays a key role. This interface is designed based on the complex and diverse types of messages uploaded by the device. Its generic support feature enables it to be widely compatible with a variety of data types. For example, binary data commonly found in the data interaction of urban lighting monitoring devices and json string data that facilitates the structured expression of information can both be effectively accepted.

[0046] After the general communication interface obtains the input data, the message unpacking function of the IProtocol interface is launched first. Strictly in accordance with the preset unpacking rules, the input data is accurately disassembled into individual message segments with independent semantics, such as being divided according to specific start identifiers, length fields, and other delimiting conditions. Immediately afterwards, the message verification function conducts a rigorous inspection on each of the split messages, checking multiple aspects such as its data integrity, format correctness, and compliance with the established communication protocol specifications, so as to screen out messages that may be incorrect or abnormal and ensure the data quality.

[0047] Subsequently, based on the key information of the function code carried in the message, the IProtocol interface can quickly and accurately determine the function of the urban lighting monitoring device corresponding to the message. For example, a specific function code value may correspond to the lighting brightness adjustment function or the device status monitoring function of the device. Based on the determination of the device function, further in-depth parsing is carried out to obtain a message format that meets the requirements of the test case, and the original data is converted into a standardized data structure that can be directly used and processed by the test process, laying a foundation for generating accurate and effective test cases based on the data subsequently.

[0048] S103. Obtain test cases according to the preset rules in combination with the standard data structure;

[0049] Among them, the preset rules represent a set of pre-set logical judgment and data extraction criteria, which refer to the specifications for extracting test cases from data based on the functional characteristics, test requirements, and industry standards of urban lighting monitoring devices, and are used to guide the determination of the specific implementation content of the test process.

[0050] In some embodiments, after the standard data structure is generated by the general protocol encoding and decoding interface, the step of obtaining test cases according to the preset rules in combination with this data is started. The system first loads the preset rule library and compares each field in the standard data structure with the conditions in the preset rules one by one. For example, compare the device type field with the device type classification in the rule. If the match is successful, further check the relevant function fields and parameter ranges. According to these matching results, select the corresponding test cases from the preset test case template set, or dynamically generate new test cases according to the rules, ensuring that the test cases are closely combined with the actual situation of the device and the test requirements, making the test targeted and effective, and being able to comprehensively cover the performance index tests of the device.

[0051] In some embodiments, the test cases include: checking whether the device is online, checking the switch-on and switch-off functions, checking the device working conditions, checking the device working parameters, checking the device communication parameters, and checking the device information.

[0052] It can be seen that the test cases cover various inspection contents of the device, comprehensively detecting from online status to functions, working conditions, parameters, and basic information, etc. This comprehensiveness conducts a comprehensive evaluation of the device, avoids missing key detection points, ensures that the urban lighting monitoring device meets the requirements in all aspects, improves the integrity and effectiveness of the test, and helps to improve the device quality and system stability.

[0053] In some embodiments, it mainly consists of test parameters TestParams and an orderly arranged set of test items AbstractTestStep. Among them, the test items adopt the design pattern of an abstract class. This design is ingenious and provides a solid foundation for subsequent extensibility. By inheriting the AbstractTestStep abstract class and effectively implementing the abstract methods therein, developers can conveniently expand a rich variety of test functions and scenarios according to specific test requirements. It is worth mentioning that default test items are provided. These default test items are carefully selected and optimized to cover and meet the vast majority of common test scenarios. Whether it is the basic function detection of urban lighting monitoring equipment, such as verifying the lighting on and off functions and measuring the brightness adjustment range, or testing the core performance indicators such as the communication stability and data transmission accuracy of the equipment, the default test items can handle them efficiently. This not only improves the generality and practicality of test cases, reduces the cumbersome work of frequently rewriting test cases for different projects, but also ensures that in most cases, the test process can be quickly started and smoothly advanced, improving the test efficiency and quality.

[0054] S104. Construct a test context based on the general communication interface, general protocol encoding / decoding interface, and test cases. The test context updates the current test progress, the text description of the current test details, and the descriptive text content of the data reported by the urban lighting monitoring equipment, including test preparation events, test start events, test completion events, and test end events.

[0055] Among them, the test context represents the comprehensive information management and scheduling environment during the entire test process. It refers to a logical container that integrates various information resources such as the general communication interface, general protocol encoding / decoding interface, and test cases, and is used to record various state changes, data information, and event situations during the test process.

[0056] In some embodiments, after obtaining the test cases, the construction of the test context begins. First, information such as the current connection status and communication parameters of the general communication interface is entered into the test context, such as the number of currently connected urban lighting monitoring devices and the connection method of each device. Then, the standard data features parsed by the general protocol encoding and decoding interface, such as common data formats and field meanings, are also integrated. At the same time, the detailed content of the test cases, including information such as the test case number, test objective, and test steps, is stored in the test context. During the test process, as the test progresses, the current test progress is continuously updated, such as the proportion of completed test items and the execution time of the ongoing test items. A detailed textual description of the current test details is recorded, such as a description of abnormal phenomena occurring during the test, and a descriptive textual content of the data reported by the urban lighting monitoring devices, such as an explanation of the change in a certain sensor data reported by the device, providing a comprehensive and detailed information basis for the monitoring, analysis, and traceability of the test, and ensuring the manageability and traceability of the test process.

[0057] In this crucial stage of constructing the test context, which is the core of automated testing, it is implemented based on the Runable interface. This feature enables it to run stably in a multi-threaded environment, thereby improving the efficiency of batch testing and effectively meeting the complex requirements of large-scale urban lighting monitoring device testing.

[0058] This test context encompasses a series of core methods, each method performing its own functions and collaborating to build a complete and efficient test process framework. First is the onTaskReady method, which methodically carries out preparatory work before starting the test, precisely clearing the context cache to ensure the purity of the test environment and the consistency of the initial state. At the same time, it publishes a preparatory event to announce to the entire test system that the test process is about to start.

[0059] The onTaskStart method plays a key role when the test is officially started. It strictly executes each test item in the exact order given in the test case and has an intelligent retry mechanism. It can automatically perform retry operations according to the preset number of retries in the case of test item failure, greatly improving the accuracy and reliability of the test. After each test item is executed, regardless of whether the result is successful or failed, this method will promptly publish the corresponding event, record the test result information in detail, and update the context cache in real time, ensuring that key information such as the test progress, test details, and device status always remains up-to-date and accurate, providing real-time and detailed data support for the monitoring and management of the entire test process.

[0060] The onTaskEnd method marks the end of the test process. At this time, it publishes an end event to notify the system that the test has completed the execution of all scheduled test items, and the entire test process is about to conclude. This enables the system to promptly be aware of the termination status of the test, facilitating subsequent operations such as resource recovery and result aggregation.

[0061] Finally, the onTaskDone method focuses on the post-test wrap-up work and publishes a completion event to announce the successful conclusion of the test task at the overall level. Throughout the test process, the context cache acts as an information hub, containing important data such as an accurate record of the current test progress, a detailed description of each test step, and details of any potential problems. Each event publication is orderly cached in the event scheduler, which provides a convenient interface for external programs to obtain the latest test status in real time. Based on this information, external programs can formulate and execute corresponding handling methods for each event. For example, when receiving a test failure event, they can initiate a troubleshooting and repair process; when receiving a test completion event, they can generate a detailed test report, etc. This realizes the efficient interaction and collaborative work between the test system and the external environment, further enhancing the intelligent level and overall efficiency of the automated test of urban lighting monitoring equipment.

[0062] S105. Execute each test item in the test case in sequence;

[0063] In some embodiments, after constructing the test context, the step of executing each test item in the test case in sequence begins. The system first reads the test case information from the test context to determine the first test item in the test case. Then, according to the requirements of the test item, it sends corresponding control instructions or data requests to the urban lighting monitoring equipment through the general communication interface. For example, if the test item is to detect the sensor data acquisition function of the equipment, it sends a data acquisition instruction. Next, it waits for the response data from the equipment, receives and parses the response data through the general protocol encoding and decoding interface, and compares the parsing result with the expected result of the test item, recording the comparison result. After completing the first test item, the same operation process is sequentially performed on the subsequent test items according to the order specified in the test case to ensure a comprehensive and orderly test of the various functions and performances of the urban lighting monitoring equipment, without missing any key test points, and guaranteeing the integrity and systematicness of the test.

[0064] In some specific embodiments, a linear execution method is adopted. A test item execution queue is created, and the test items in the test case are sequentially added to the queue. Then, the test items are sequentially taken out and executed according to the queue order. After executing one test item, the next one is taken until all test items in the queue are executed. There is no limitation here.

[0065] In some other specific embodiments, different states are defined for each test item, such as waiting to execute, executing, executed, etc. The execution of the next test item is driven according to the state transition of the current test item, and data transfer and result recording are performed during the state transition, which is not limited herein.

[0066] S106. After execution is completed, the test result is judged. When the test result is a failure and the cumulative number of failures of the corresponding test item does not exceed the preset retry times threshold, the corresponding test item is tested again.

[0067] In some embodiments, after executing a test item, the step of judging the test result is started. The system first obtains the response data of the device for the test item from the general protocol encoding / decoding interface, and obtains the expected result standard of the test item in combination with the test context. Then, the response data is compared and analyzed in detail with the expected result. For example, for a data accuracy test item, it is compared whether the difference between the value in the response data and the expected value is within the allowable error range; for a function integrity test item, it is checked whether all expected function identifiers are included in the response data. When the test result is a failure and the cumulative number of failures of the corresponding test item does not exceed the preset retry times threshold, it indicates that the device may have an accidental failure or a repairable problem. At this time, the corresponding test item is tested again, the test instruction is sent again and the above test process is repeated to eliminate the influence of accidental factors on the test result, improve the accuracy and reliability of the test, and ensure that the device obtains a more accurate performance evaluation after multiple tests.

[0068] S107. When the test result is a success or the number of failures exceeds the retry times threshold, the retry operation for the corresponding test item is terminated; at the same time, regardless of whether the corresponding test item is a success or a failure, an event of the test result state of the corresponding test item is generated and published according to the preset event trigger and generation mechanism.

[0069] In some embodiments, after the test results are judged, if the test result is successful, it indicates that the test item passes the test, and the retry operation for the corresponding test item is directly terminated because the test goal has been achieved. If the number of failures exceeds the retry count threshold, it means that there are relatively serious or difficult-to-fix problems with the test item, and continuing to retry may waste a lot of time and resources, so the retry operation is also terminated. At the same time, regardless of whether the test result is successful or failed, corresponding events of the test result status of the test item are generated and published according to the preset event trigger and generation mechanism. For example, if the test is successful, a test success event is generated, including information such as the test item name and test time; if the test fails, a test failure event is generated, which may also include preliminary analysis information on the failure reason (such as data anomaly, function not responding, etc.) in addition to the above information. These events can be received and processed by other system modules or external monitoring systems to promptly grasp the test progress and results, comprehensively monitor and manage the test process, and provide a basis for subsequent test analysis and equipment improvement.

[0070] S108. Use an event scheduler to process the events generated by the test context.

[0071] Among them, the event scheduler refers to the core component specifically used to manage and process various events generated in the test context, which is a functional module that queues, distributes, and executes events according to certain scheduling strategies and priority rules, and is used to ensure that events can be processed orderly and efficiently, avoiding event accumulation and processing chaos.

[0072] In some embodiments, after an event is generated in the test context, the event scheduler starts to work. It first receives the event information from the test context and classifies the events according to the preset priority rules.

[0073] In some specific embodiments, a combination of a priority queue and a thread pool is adopted to create event queues with different priorities. Each queue corresponds to a thread pool. When an event enters the queue, the threads in the thread pool process the event according to the queue order, which is not limited here.

[0074] In some specific embodiments, a timing task scheduling framework is used to set the processing time interval and priority for each event, and the framework triggers the event processing tasks in turn according to the time and priority rules. It can be understood that other methods can also be used to implement the function of the event scheduler, which is not limited here.

[0075] In some embodiments, the event scheduler is an ordered blocking queue that processes the events published by the test context in the order of first in first out.

[0076] It can be seen that the event scheduler, as an ordered blocking queue, processes the events published by the test context in the first-in, first-out order. This makes the event processing process standardized and orderly, avoiding chaos and cut-in phenomena. When multiple events occur concurrently, it can handle them in an orderly manner, ensuring that each event is reasonably processed and guaranteeing the stable operation of the test system.

[0077] It can be seen that the general communication interface, as a data interaction channel, can accept the data inflow from different urban lighting monitoring devices, avoiding the trouble of frequently adjusting communication settings due to device differences. The general protocol encoding and decoding interface then parses the input data, accurately extracts key information and converts it into data, and generates test cases according to preset rules, precisely positioning the direction for subsequent tests. The test context constructed based on these elements updates the current test progress in real time, details the current test details and the content of the data reported by urban lighting monitoring devices, covering all-stage event information from test preparation to start, completion, and end, and navigates the test process. Execute each test item in the test case in sequence, rigorously and orderly promote the test process, and at the same time, according to the preset event trigger and generation mechanism, generate events corresponding to the test result status and publish them. Use the event scheduler to efficiently process the events generated by the test context, making the entire test process closely connected and orderly, realizing the automated test of urban lighting monitoring devices and improving the test efficiency.

[0078] Example 1: Docking of the single-lamp controller with the Likon 1.1 protocol

[0079] First, when communicating and docking with the single-lamp controller with the Likon 1.1 protocol, considering its communication method using UDP and the characteristic of transmitting binary messages, when instantiating the general communication interface, it is necessary to operate strictly in accordance with the specific requirements of the UDP server. Specifically, accurately obtain the port number of the UDP server from the pre-configured configuration file. Relying on this port, on the one hand, it can listen to the binary data received on this port to collect data from the single-lamp controller; on the other hand, it can also send binary data to the single-lamp controller through this port to complete two-way data interaction, and then use the received data as the input data for the subsequent test process. After instantiation, officially start the communication through the open method specified by the general communication interface, and specifically loop to listen to the data on the port in an independent thread to ensure the timeliness and integrity of data reception. This process perfectly fits the content of data interaction with different urban lighting monitoring devices through the general communication interface.

[0080] Subsequently, for the received binary message, the general protocol encoding and decoding interface is instantiated according to the corresponding requirements for parsing and processing. When the communication instance receives data, it will pass it to the encoding and decoding instance. The encoding and decoding instance will first accurately intercept the message header and message tail according to the established rules, and rigorously verify the content body of the message to judge the integrity of the message, ensuring that the data meets the requirements in terms of format and content, and preventing incorrect data from entering the subsequent process. Then, according to the function code given in the message, using the preset corresponding encoding and decoding method, the original binary message is converted into the message class required for automated testing, so as to successfully obtain the data, strictly implementing the key step of parsing the input data through the general protocol encoding and decoding interface to obtain the data.

[0081] In terms of arranging test cases, based on the general characteristics of urban lighting monitoring equipment, the test items are executed in sequence as follows: inspection of online, inspection of equipment information, inspection of equipment working parameters, inspection of equipment working conditions, inspection of equipment switching on and off functions, and inspection of equipment communication parameters. This sequence is set by comprehensively considering the importance of each functional module of the equipment and the rationality of the test logic, following the requirement of parsing data according to preset rules to obtain test cases, ensuring that the test cases can comprehensively and specifically cover the key performance indicators of the equipment, and realizing the comprehensive detection of the single-lamp controller.

[0082] After that, the above-mentioned instantiated general communication interface, general protocol encoding and decoding interface, and arranged test cases are used to construct the test context. This test context is like the core command hub of the entire test process, updating the current test progress in real time during the test, and detailedly recording the text description of the current test details and the descriptive text content of the data reported by the single-lamp controller, covering the relevant information of various important stages from test preparation events, test start events, to test completion events and test end events, clearly presenting the full process status of the test.

[0083] When actually executing the test, each test item in the test case is executed in sequence, and the whole process does not require manual intervention, realizing a highly automated test process. After each test item is executed, the test result is judged. When the test result is a failure and the cumulative failure times of the corresponding test item do not exceed the preset retry times threshold, the system will automatically retest the test item, excluding the interference of accidental factors through multiple attempts to ensure the accuracy of the test result; when the test result is a success or the failure times exceed the retry times threshold, the retry operation for the corresponding test item is terminated. At the same time, regardless of whether the corresponding test item is finally successful or failed, the test result status events of the corresponding test item will be strictly generated according to the preset event triggering and generation mechanism, and these events will be sent to the event scheduler for unified processing.

[0084] During the entire testing process, various types of events generated at different stages play clear and important roles. When the test preparation event is received, the system can store the device-related information with empty information in the database as a device registration record for subsequent management and tracking of the device; when the test starts, the test context sends test item success or failure events. At this time, the system can record the specific test information in detail in the database or push it to the corresponding notification page for relevant personnel to observe the test progress in real time; when the test context publishes the test end event, the system will fully record the results of this test and the collected device information to provide data support for subsequent analysis and summary; when the test context publishes the event of the completion of this test, the system will clear the cache of this test, destroy this test context, and release the system performance resources. At the same time, it can also notify the page to prepare for the test of the next batch of devices to ensure the orderly connection of the entire test process and the reasonable utilization of system resources. It efficiently realizes the complete process of using the event scheduler to process the events generated by the test context, comprehensively ensuring the smooth progress of the docking test of the single lamp controller of the LiKong 1.1 protocol and the reliability and effectiveness of the test results.

[0085] Embodiment 2: Docking of the LiKong MQTT Protocol Single Lamp Controller

[0086] In the communication interface instantiation link, since the LiKong MQTT protocol single lamp controller uses the MQTT method for communication, when instantiating the general communication interface, it is necessary to access the MQTT server as a client. With the unique subscription topic mechanism of MQTT, it is possible to accurately receive device data from the single lamp controller. At the same time, the publish topic function can also be used to send data to the device, thereby building a stable and efficient data interaction channel, perfectly meeting the requirements of data interaction with different urban lighting monitoring devices through the general communication interface and providing a stable data source for the subsequent test process.

[0087] In terms of instantiating the encoding and decoding interface, since the transmitted message is a json string, it is necessary to convert the json string into a json object to efficiently obtain the key-value pair information therein. Then, according to the keys in the json or the subscribed topics, quickly locate and find the corresponding encoding and decoding methods in the preset encoding and decoding rule system, and then convert them into the message classes required for automated testing, thus successfully realizing the key step of parsing the input data through the general protocol encoding and decoding interface to obtain the data, ensuring that the data can enter the subsequent test case generation link in a suitable format.

[0088] The subsequent test process is consistent with that of the first implementation example. First, according to the common functions of urban lighting monitoring devices and preset rules, the converted data is parsed to obtain test cases, which cover the detection requirements for various aspects of the device's performance and comprehensively and systematically plan the content and direction of the test. Then, a test context is constructed using the successfully instantiated general communication interface, general protocol encoding and decoding interface, and carefully arranged test cases. This test context plays a central role in the entire test process, updating the current test progress in real time, recording in detail the text description of the current test details and the descriptive text content of the data reported by the single-lamp controller, and completely covering the information presentation and management of each key stage from the test preparation event, test start event to test completion event, test end event, etc., providing a strong guarantee for the smooth progress and monitoring of the test.

[0089] When executing each test item in the test case, there is no need for manual intervention either, and it is carried out strictly in sequence. After the test item is executed, the test result is accurately judged. When the test result is a failure and the cumulative number of failures does not exceed the preset retry times threshold, the test item is automatically retested to exclude the interference of accidental factors through repeated verification; if the test result is a success or the number of failures exceeds the retry times threshold, the retry operation is terminated. And regardless of the test result, according to the preset event triggering and generation mechanism, an event of the test result status of the corresponding test item is generated and sent to the event scheduler for unified processing and scheduling.

[0090] In the actual use process, in a large-scale urban lighting monitoring system, there are often multiple devices running simultaneously and interacting with the test system. Due to the differences in the response time and internal processing timing of different devices, unexpected timing conflicts may occur in the test context.

[0091] Please refer to Figure 2 , Figure 2 which is another process schematic diagram of the automatic test method for urban lighting monitoring devices in the embodiments of the present application;

[0092] In some embodiments, after step S105, it further includes:

[0093] S201. Send instructions to the urban lighting monitoring device through the general communication interface according to the preset time sequence and interval;

[0094] In some embodiments, after step S105 sequentially executes each test item in the test case, in order to further deeply detect the response performance of the device under different time series and the collaborative working ability, etc., this step is started. The system first reads the preset time sequence and interval information from the preset instruction sequence configuration file, and then, according to the connection status currently established by the general communication interface with each urban lighting monitoring device, at the arrival of each interval time in the preset time sequence, accurately sends corresponding instructions to the corresponding urban lighting monitoring device through the general communication interface.

[0095] S202. After sending the instruction, monitor the response of the urban lighting monitoring device through the general communication interface and the general protocol encoding / decoding interface. If a timing conflict occurs in the urban lighting monitoring device, determine the conflicting urban lighting monitoring device and the corresponding urban lighting monitoring device, where the corresponding urban lighting monitoring device is the urban lighting monitoring device that should perform operations in the correct time sequence under non-conflicting circumstances.

[0096] Among them, the timing conflict means that during the process of the urban lighting monitoring device receiving and processing the instruction, the actual response time sequence is inconsistent with the preset reasonable time sequence. It refers to the phenomenon that the operations that should be executed in sequence are disordered due to factors such as the difference in the device's own processing speed and network transmission delay, and is used to reflect the abnormal state in the time dimension during the collaborative work of devices. The conflicting urban lighting monitoring device is the device that does not respond to the instruction in the correct time sequence when a timing conflict occurs, and the corresponding urban lighting monitoring device is the device that should perform operations in the correct time sequence under normal circumstances but is affected by the conflict of other devices.

[0097] In some embodiments, after executing step S201 to send the instruction, it is necessary to closely monitor the response of the urban lighting monitoring device through the general communication interface and the general protocol encoding / decoding interface. The system continuously listens to the feedback data received from each device through the general communication interface, uses the general protocol encoding / decoding interface to parse these data, extracts the key information related to the instruction response time, operation execution sequence, etc., and then compares and analyzes it with the preset correct time sequence. Once it is found that the device operation sequence reflected by the received data does not conform to the preset sequence, it is determined that a timing conflict has occurred, and then accurately find out which are the conflicting urban lighting monitoring devices and the corresponding urban lighting monitoring devices. For example, when performing a group control test on multiple street lamp nodes, if it is preset to turn on the lighting in sequence of node 1, node 2, and node 3, and it is found through parsing the feedback data that node 3 lights up first, then node 3 is the conflicting urban lighting monitoring device, and node 1 and node 2 may be the corresponding urban lighting monitoring devices for subsequent targeted coordination and processing.

[0098] S203. Command the corresponding urban lighting monitoring device to send a synchronization instruction to the conflicting urban lighting monitoring device through the general communication interface, receive the reply instruction sent by the conflicting urban lighting monitoring device through the general communication interface, and parse the sending time and receiving time of the synchronization instruction with the help of the general protocol encoding and decoding interface;

[0099] In some embodiments, the corresponding urban lighting monitoring device will send a synchronization instruction to the conflicting urban lighting monitoring device through the general communication interface according to the system's instruction. The content of the synchronization instruction will be customized according to the specific conflict situation, such as informing the other party how long to delay the response or advance to what time to respond, etc. After sending, the conflicting urban lighting monitoring device receives the synchronization instruction. After internal processing, it then uses the general communication interface to send a reply instruction to the corresponding urban lighting monitoring device to feedback the reception and processing situation. On the side of the test system, it receives the reply instruction sent by the conflicting urban lighting monitoring device through the general communication interface, and then parses the sending time and receiving time of the synchronization instruction with the help of the general protocol encoding and decoding interface. These time data will be used as important bases for subsequent calculations and adjustments.

[0100] S204. Obtain the first time difference through the sending time, receiving time, and preset correction parameter; respectively obtain the second time difference of the automated test system of the urban lighting monitoring device for the conflicting urban lighting monitoring device and the third time difference of the automated test system of the urban lighting monitoring device for the corresponding urban lighting monitoring device;

[0101] Among them, the first time difference is calculated through the sending time and receiving time of the synchronization instruction and the preset correction parameter, and reflects the time difference between the time consumed in the transmission process of the synchronization instruction and the ideal time, which is used to measure the time deviation in the communication and coordination process between devices. The second time difference refers to the difference in time perception of the automated test system of the urban lighting monitoring device for the conflicting urban lighting monitoring device, which reflects the difference between the time of this device recorded by the test system and the actual time. Similarly, the third time difference is the time perception difference for the corresponding urban lighting monitoring device.

[0102] In some specific embodiments, calculate according to the preset time difference calculation formula (such as the first time difference = receiving time - sending time - preset correction parameter). For the second and third time differences, find the preset time and actual response time of the corresponding device in the device time record database of the system, and subtract to obtain the difference.

[0103] S205. Calculate the deviation of the conflicting urban lighting monitoring device. The deviation is the current time of the conflicting urban lighting monitoring device minus the current time of the automated test system of the urban lighting monitoring device minus the second time difference;

[0104] Among them, the deviation represents the degree of deviation between the current actual time of the conflicting urban lighting monitoring device and the theoretically expected time. It refers to a time deviation amount obtained by comprehensively considering factors such as the time perception difference of the automated test system for it and the time difference during the synchronization instruction interaction process. It is used to locate the abnormal degree of the conflicting urban lighting monitoring device in terms of time, as well as the direction and amplitude that need to be corrected.

[0105] S206. Obtain the time function of the conflicting urban lighting monitoring device, where the time function is used to correct the time of the data sent by the conflicting urban lighting monitoring device; the calculation method of the time function is: the first time difference plus the current time of the conflicting urban lighting monitoring device minus the current time of the conflicting urban lighting monitoring device and then minus the second time difference to obtain the first intermediate quantity; S207. Multiply the first intermediate quantity by a preset parameter to obtain the second intermediate quantity; S208. Add the second intermediate quantity to the current time of the conflicting urban lighting monitoring device to obtain the time function.

[0106] Among them, the time function is a mathematical expression for correcting the time of the data sent by the conflicting urban lighting monitoring device. It refers to a functional relationship that can dynamically adjust the time of the conflicting device through a series of arithmetic combinations of time parameters. For example, substituting the various time differences and other data calculated in the previous steps into the time function can obtain a specific time adjustment amount, enabling the next data sending time of the conflicting device to meet the overall preset timing requirements.

[0107] It can be seen that during the operation of multiple devices, by monitoring the response situation through the general communication interface, once a timing conflict is detected, a synchronization instruction is sent through the corresponding device, and the time difference and deviation are calculated to obtain the time function to correct the data time of the conflicting device. The communication and data interaction among devices proceed orderly under the mechanism, which can promptly correct the conflicts caused by the timing differences in device response and processing, ensuring the accuracy and coherence of the test context information.

[0108] In the actual usage process, according to the preset event triggering and generation mechanism to handle the events generated by the test context, when facing a large number of concurrent events or events that occur quickly and continuously, the event scheduler may not be able to handle them in a timely manner. This may result in some important events not being processed, affecting the subsequent development of the test.

[0109] Please refer to Figure 3 , Figure 3 which is the specific process schematic diagram of step S108 in the embodiment of the present application;

[0110] In some embodiments, step S108 specifically includes:

[0111] S301. Divide the events into three priority levels: high, medium, and low according to the preset priority table;

[0112] Among them, the preset priority table refers to a pre-set reference standard for measuring the importance and urgency of different events. It refers to a level classification list formulated based on the impact of the event on the operation of urban lighting monitoring equipment, test results, and overall system stability. It is used to clearly distinguish the order of processing of each event.

[0113] The three priority levels of high, medium and low are different levels of classification of events based on the preset priority table. High priority means that the event is the most urgent and important and needs to be handled as a priority to avoid serious impact on the city lighting system; medium priority means that the event has a certain importance and urgency and will be handled after the high priority event is handled or resources permit; low priority is relatively less important and urgent and can be handled after other more critical events are handled.

[0114] S302, adding the event to the priority queue according to the time of generation, and changing the waiting time of the event according to the priority level, wherein the waiting time decreases from high to low priority level;

[0115] Waiting time refers to the length of time an event takes to be processed in the priority queue. It is calculated as follows: the waiting time is equal to the current time minus the time when the event was generated, multiplied by a coefficient. The coefficient is determined by the priority level of the event and decreases with the priority level from high to low. This design aims to more accurately regulate the processing rhythm of events of different priorities through the combination of time and coefficient, so that high-priority events can be processed in a shorter time, followed by medium-priority events, and low-priority events are processed relatively delayed, so as to reasonably allocate processing resources and avoid the situation where low-priority events occupy resources for a long time and high-priority events cannot be processed in time.

[0116] In some embodiments, whenever a new event occurs, the system first obtains the priority level (high, medium, low) of the event and the time information when it occurs, and records the current time. Then, the event is inserted into the corresponding position in the priority queue according to the occurrence time. For the calculation and adjustment of the waiting time, the system will, according to the pre-set rules, first calculate the difference between the current time and the event occurrence time, and then multiply it by the corresponding coefficient. For example, the coefficient for high-priority events is set to 0.1, medium-priority is 0.5, and low-priority is 1. If a high-priority event occurs at 10:00:10 and the occurrence time is 10:00:00, then the waiting time is (10:00:10 - 10:00:00) × 0.1 = 1 second; if it is a medium-priority event, the waiting time is (10:00:10 - 10:00:00) × 0.5 = 5 seconds; and for a low-priority event, the waiting time is (10:00:10 - 10:00:00) × 1 = 10 seconds. In this way, resources are preferentially allocated to important and urgent events, while also taking into account the processing requirements of events at different levels, making the entire event processing process more orderly and efficient, ensuring that the urban lighting monitoring system can respond to various situations in a timely manner, maintain a stable operating state and an accurate testing process.

[0117] S303. Process events in the priority queue in the order of waiting time from earliest to latest.

[0118] It can be seen that the event levels are divided according to the preset priority table and the waiting time is changed accordingly, and the events in the priority queue are processed according to the waiting time. As time increases, the rate of increase in the waiting time of high-priority events increases, and the rate of increase in the waiting time of low-priority events decreases, enabling high-priority events to be processed first, avoiding untimely processing, and thus improving the overall testing reliability.

[0119] The following introduces the exemplary automated testing system 400 for urban lighting monitoring devices provided by the embodiments of the present application. Figure 4 It is a schematic diagram of the exemplary hardware structure of the automated testing system 400 for urban lighting monitoring devices provided by the embodiments of the present application.

[0120] In some embodiments, the automated test system 400 of the urban lighting monitoring device is a computer device or the automated test system 400 of the urban lighting monitoring device includes a computer device. The computer device includes a processor, a memory, and a network interface connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store data. The network interface of the computer device is used to communicate with other external terminals or servers through a network connection. In some embodiments, the network interface can be a wired network interface, and in some embodiments, the network interface can also be a wireless network interface. When the computer program is executed by the processor, it realizes the method in the embodiments of the present application.

[0121] Those skilled in the art can understand that Figure 4 the structure shown in is only a block diagram of some structures related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0122] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, and are not intended to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

[0123] As used in the above embodiments, depending on the context, the term "when..." can be interpreted to mean "if..." or "after..." or "in response to determining..." or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if detecting (the stated condition or event)" can be interpreted to mean "if determining..." or "in response to determining..." or "when detecting (the stated condition or event)" or "in response to detecting (the stated condition or event)".

[0124] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center in a wired manner (such as coaxial cable, optical fiber, digital subscriber line) or a wireless manner (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more integrated available media. The available medium can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid-state drive), etc.

[0125] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware with a computer program. The program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the above method embodiments. The foregoing storage medium includes: various media that can store program codes such as ROM or random access memory RAM, magnetic disks, or optical discs.

Claims

1. An automated testing method for urban lighting monitoring equipment, characterized in that: include: Get test cases based on preset rules and standard data structures; Construct a test context based on the general communication interface, general protocol encoding and decoding interface, and test cases. The test context updates the current test progress, the text description of the current test details, and the descriptive text content of the data reported by the equipment, including test preparation events, test start events, test completion events, and test end events; Execute each test item in the test case in sequence; When it is determined that a timing conflict occurs in a device, a first time difference between the system and the conflicting device, a second time difference between the system and the correct device, and a third time difference between the conflicting device and the correct device are obtained, wherein the time difference is determined by the corresponding sending time, receiving time, and preset correction parameters; the first time difference plus the current time of the conflicting device minus the current time of the conflicting device minus the second time difference is obtained to obtain a first intermediate value; The first intermediate quantity is multiplied by a preset parameter to obtain a second intermediate quantity; The current time of the conflicting device is added to the second intermediate quantity to obtain a time function; The time function is used to correct the time of data sent by the conflicting device; After the execution is completed, the test result is judged. When the test result is failure and the cumulative number of failures of the corresponding test item does not exceed the preset retry number threshold, the corresponding test item is tested again; When the test result is successful or the number of failures exceeds the retry threshold, the retry operation of the corresponding test item is terminated; at the same time, no matter whether the corresponding test item is successful or failed, the event of the test result status of the corresponding test item is generated and published according to the preset event triggering and generation mechanism; Use the event dispatcher to handle events generated by the test context.

2. The method according to claim 1, characterized in that The steps to use the event dispatcher to handle events generated by the test context include: Classify events into three priority levels: high, medium, and low according to the preset priority table; Add events to the priority queue according to the time they are generated, and change the waiting time of the events according to the priority level, where the waiting time decreases from high to low priority levels; Events in the priority queue are processed in order of waiting time.

3. The method according to claim 1, characterized in that Test cases include: checking whether the device is online, checking the light switch function, checking the device working condition, checking the device working parameters, checking the device communication parameters, and checking the device information.

4. The method according to claim 1, characterized in that The event scheduler is an ordered blocking queue that processes events published by the test context in a first-in-first-out order.

5. An automated testing system for equipment, characterized in that: The automated testing system of the device comprises: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code comprises computer instructions, and the one or more processors call the computer instructions so that the automated testing system of the device executes the method as claimed in any one of claims 1 to 4.

6. A computer program product comprising instructions, characterized in that When the computer program product runs on an automated testing system for a device, the automated testing system for the device is enabled to execute the method according to any one of claims 1 to 4.

7. A computer-readable storage medium comprising instructions, characterized in that: When the instructions are executed on an automated testing system of a device, the automated testing system of the device is caused to execute the method according to any one of claims 1 to 4.

Images