Automatic test method and system for urban lighting monitoring equipment, program product and storage medium

Abstract

The invention provides an automatic test method and system for urban lighting monitoring equipment, a program product and a storage medium, and relates to the field of urban lighting monitoring. The universal communication interface serves as a data interaction channel and can receive data transmission of different urban lighting monitoring devices. And the universal protocol encoding and decoding interface analyzes or encodes the data, generates a test case according to a preset rule, and accurately positions the direction for a subsequent test. The current test progress is updated in real time based on the test context constructed by the elements, the current test details and the content of data reported by the urban lighting monitoring equipment are recorded in details, the event information of the whole stage of the test from preparation to start, completion to end is covered, and the test process is navigated. The whole test process is closely linked and orderly, the automatic test of the urban lighting monitoring equipment is realized, and the test efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of urban lighting monitoring, and in particular to an automated testing method, system, program product and storage medium for urban lighting monitoring equipment. Background Art

[0002] At present, for the testing of urban lighting monitoring equipment, when faced with differences in communication methods and protocols of different devices, technicians first obtain the software provided by the manufacturer, and then gradually enter the test instructions according to the operating procedures set by the software. For example, for the data acquisition function of the equipment, 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, enter specific control parameters in the software, such as the light brightness adjustment instruction, and then check the actual light brightness changes of the equipment.

[0003] However, this testing method that relies on specific devices and manufacturer software has many disadvantages. Since each device may need to write a separate test system or perform manual operations, the problem of inefficiency is particularly prominent when facing large-scale testing tasks, which greatly prolongs the development cycle and delays the delivery schedule. Summary of the invention

[0004] The present application provides an automated testing method, system, program product and storage medium for urban lighting monitoring equipment, which are used to improve testing efficiency.

[0005] In the first aspect, the present application provides an automated testing method for urban lighting monitoring equipment, including: exchanging data with different urban lighting monitoring equipment through a universal communication interface, using the received data as input data; parsing the input data through a universal protocol encoding and decoding interface to obtain a standard data structure that can be processed by the program; obtaining a test case based on preset rules and the standard data structure; constructing a test context based on the universal communication interface, the universal protocol encoding and decoding interface, and the test case, and 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 event, test completion event, test end event; execute each test item in the test case in sequence; after execution, judge the test result. When the test result is failure and the cumulative number of failures of the corresponding test item does not exceed the preset retry threshold, test the corresponding test item again; when the test result is success or the number of failures exceeds the retry threshold, terminate the retry operation on the corresponding test item; at the same time, no matter whether the corresponding test item is successful or failed, generate and publish the event of the test result status of the corresponding test item according to the preset event triggering and generation mechanism; use the event scheduler to handle 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 executing the steps of each test item in the test case in sequence, the method also includes: sending instructions to the urban lighting monitoring device with the help of a universal communication interface according to a preset time sequence and interval; after sending the instructions, monitoring the response of the urban lighting monitoring device through the universal communication interface and the universal protocol codec interface, and if a timing conflict is found in the urban lighting monitoring device, determining the conflicting urban lighting monitoring device and the corresponding urban lighting monitoring device, wherein the corresponding urban lighting monitoring device is an urban lighting monitoring device that should perform operations in the correct timing when no conflict occurs; commanding the corresponding urban lighting monitoring device to send a synchronization instruction to the conflicting urban lighting monitoring device through the universal communication interface, using the universal communication interface to receive a reply instruction sent by the conflicting urban lighting monitoring device, and using the universal protocol codec interface to parse and obtain the sending time and receiving time of the synchronization instruction; through the sending time, receiving time and preset correction time parameters, obtain a first time difference; respectively obtain a second time difference of the automatic test system of the urban lighting monitoring equipment for the conflicting urban lighting monitoring equipment and a third time difference of the automatic test system of the urban lighting monitoring equipment for the corresponding urban lighting monitoring equipment; calculate and obtain the deviation of the conflicting urban lighting monitoring equipment, the deviation is the current time of the conflicting urban lighting monitoring equipment minus the current time of the automatic test system of the urban lighting monitoring equipment minus the second time difference; obtain the time function of the conflicting urban lighting monitoring equipment, the time function is used to correct the time of the data sent by the conflicting urban lighting monitoring equipment; the time function is calculated as follows: the first time difference plus the current time of the conflicting urban lighting monitoring equipment minus the current time of the conflicting urban lighting monitoring equipment 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 equipment plus the second intermediate quantity to obtain the time function.

[0008] By adopting the above technical solution, 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 instruction 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.

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

[0010] By adopting the above technical solution, 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 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.

[0011] In combination with the first aspect, the general communication interface includes: communication parameters, establishing communication, communication start and stop, and data sending and receiving. 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 universal communication interface supports multiple communication methods and can flexibly establish corresponding server or client connections according to the connection type of urban lighting monitoring equipment. In the diverse communication demand scenarios of urban lighting monitoring equipment, it can adapt to the communication of different devices to ensure the smooth data interaction, enhance the compatibility and flexibility of the test system and various types of equipment, and reduce the connection and data transmission barriers caused by differences in communication methods.

[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 divide the input data into multiple messages according to the preset message header, message tail and message length bytes. Message verification is to determine whether the message is correct according to the preset verification method. Function code extraction is to parse out the corresponding device function 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 divides the input data according to preset rules, verification ensures the correctness of the message, and function code extraction clarifies the device function. This makes the data processing flow clear and efficient, and can quickly and accurately parse data, providing a reliable basis for the precise execution of subsequent test cases, and improving the data processing quality and speed of the entire test process.

[0015] Combined with the first aspect, the test cases include: checking whether the equipment is online, checking the light switch function, checking the equipment working condition, checking the equipment working parameters, checking the equipment communication parameters, and checking the equipment information.

[0016] By adopting the above technical solutions, the test cases cover many aspects of equipment inspection, from online to comprehensive inspection of functions, working conditions, parameters and basic information. This comprehensiveness conducts a comprehensive evaluation of the equipment to avoid missing key inspection points, ensure that urban lighting monitoring equipment meets the requirements in all aspects, improve the integrity and effectiveness of the test, and help improve equipment quality and system stability.

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

[0018] By adopting the above technical solution, the event scheduler acts as an ordered blocking queue and processes events released by the test context in a first-in-first-out order. This makes the event processing process standardized and orderly, avoiding confusion and queue jumping. When multiple events are concurrent, they can be processed in an orderly manner to ensure that each event is handled reasonably and to ensure the stable operation of the test system.

[0019] In a second aspect, the present application provides an automated testing system for urban lighting monitoring equipment, the automated testing system for urban lighting monitoring equipment comprising: 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 to enable the automated testing system for urban lighting monitoring equipment to execute the method described in the first aspect and any possible implementation manner of the first aspect.

[0020] In a third aspect, the present application provides a computer program product comprising instructions. When the computer program product is run on an automated testing system for urban lighting monitoring equipment, the automated testing system for urban lighting monitoring equipment executes the method described in the first aspect and any possible implementation of the first aspect.

[0021] In a fourth aspect, the present application provides a computer-readable storage medium comprising instructions, which, when executed on an automated testing system for urban lighting monitoring equipment, enables the automated testing system for urban lighting monitoring equipment to execute the method described in the first aspect and any possible implementation of 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: 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.

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

[0024] 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

[0025] Figure 1 This is a flow chart of an automated testing method for urban lighting monitoring equipment in an embodiment of the present application; Figure 2 This is another flow chart of the automated testing method for urban lighting monitoring equipment in an embodiment of the present application; Figure 3 This is a specific flow chart of step S108 in the embodiment of the present application; 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

[0026] The terms used in the following embodiments of the present application are only for the purpose of describing specific embodiments, and are not intended to be used as limitations to the present application. As used in the specification and appended claims of the present application, the singular expressions "one", "a kind of", "said", "above", "the" and "this" are intended to also include plural expressions, unless there is a clear indication to the contrary in the context. It should also be understood that the term "and / or" used in the present application refers to and includes any or all possible combinations of one or more listed items.

[0027] In the following, the terms "first" and "second" are used for descriptive purposes only and are not to be understood as suggesting or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features, and in the description of the embodiments of the present application, unless otherwise specified, "plurality" means two or more.

[0028] See also Figure 1 , Figure 1 This is a flow chart of an automated testing method for urban lighting monitoring equipment in an embodiment of the present application; S101, exchanging data with different city lighting monitoring devices through a universal communication interface, and using the received data as input data; Among them, the universal communication interface represents a standardized information transmission channel, which refers to an interface module that is compatible with multiple types of data transmission protocols and connection methods, and is used to realize information interaction between the test system and different urban lighting monitoring equipment.

[0029] In some embodiments, when the test system is started and physically connected to the city lighting monitoring device, the universal communication interface starts to work. It first identifies and initializes the configuration of the connected device, and determines the communication parameters of the device, such as baud rate, IP address, etc. (if it is a network connection). Then, it continuously monitors the data sending request from the device end. Once the data is received, it is completely received and stored in the specified data buffer area. The received data is the input data for subsequent processing.

[0030] In some embodiments, the universal communication interface includes: communication parameters, establishing communication, starting and stopping communication, and data sending and receiving, wherein 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, the MQTT server is connected as an MQTT client.

[0031] It can be seen that the universal communication interface supports multiple communication methods and can flexibly establish corresponding server or client connections according to the connection type of urban lighting monitoring equipment. In the diverse communication demand scenarios of urban lighting monitoring equipment, it can adapt to the communication of different devices to ensure the smooth data interaction, enhance the compatibility and flexibility of the test system and various types of equipment, and reduce the connection and data transmission barriers caused by differences in communication methods.

[0032] In some embodiments, in the design 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 instructions and other information to the city lighting monitoring equipment, and "receiving data" can obtain device response data.

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

[0034] S102, parsing input data through a universal protocol encoding and decoding interface to obtain a standard data structure that can be processed by the program; Among them, the general protocol codec interface refers to a functional module specifically used to handle data format conversion and parsing. It refers to the structured decomposition and interpretation of input data based on established protocol specifications, and is used to convert the received raw data into a recognizable form.

[0035] In some embodiments, when the universal communication interface receives input data and stores it in the buffer area, the universal protocol encoding and decoding interface is triggered to start. It first reads the data in the buffer area, 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. Next, the data is decoded, the binary or other encoded data is converted into a readable text or numerical form, the various field information in the message is extracted, and combined into program data with clear semantics, so that test cases can be further generated based on these data in the future, ensuring the accuracy and standardization of data analysis, so that the test process can be promoted based on the correct data information.

[0036] In some embodiments, the general protocol encoding and decoding interface includes message unpacking, message verification, and function code extraction. Message unpacking is to divide the input data into multiple messages according to the preset message header, message tail and message length bytes. Message verification is to determine whether the message is correct according to the preset verification method. Function code extraction is to parse out the corresponding device function in the message.

[0037] 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 preset rules, verification ensures the correctness of the message, and function code extraction clarifies the device function. This makes the data processing flow clear and efficient, and can quickly and accurately parse data, providing a reliable basis for the precise execution of subsequent test cases, and improving the data processing quality and speed of the entire test process.

[0038] In some embodiments, in the process of parsing input data to obtain data through the general protocol codec interface, the interface IProtocol constructed in the protocol codec design phase plays a key role. This interface is designed based on the complexity and diversity of device upload message types. Its generic support makes it widely compatible with a variety of data types, such as binary data commonly used in urban lighting monitoring equipment data interaction and json string data that facilitates information structured expression, which can be effectively accepted.

[0039] When the general communication interface obtains the input data, the message unpacking function of the IProtocol interface is first started, strictly following the preset unpacking rules to accurately disassemble the input data into message fragments with independent semantics, such as segmentation according to specific start identifiers, length fields and other defining conditions. Then, the message verification function rigorously checks the split messages one by one, verifies their data integrity, format correctness, and compliance with established communication protocol specifications, etc., so as to filter out messages that may contain errors or anomalies and ensure data quality.

[0040] 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 equipment corresponding to the message. For example, a specific function code value may correspond to the lighting brightness adjustment function or the equipment status monitoring function of the equipment. Based on the determination of the equipment function, the message format that meets the test case requirements is further analyzed, and the original data is converted into a standardized data structure that can be directly used and processed by the test process, laying the foundation for the subsequent generation of accurate and effective test cases based on the data.

[0041] S103, obtaining a test case according to a preset rule and a standard data structure; Among them, the preset rules refer to a set of pre-set logical judgments 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 equipment, and are used to guide the determination of the specific implementation content of the test process.

[0042] In some embodiments, after the general protocol codec interface generates a standard data structure, the step of obtaining a test case in combination with the data according to preset rules is initiated. 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, the device type field is compared with the device type classification in the rule. If the match is successful, the relevant function fields and parameter ranges are further checked. Based on these matching results, the corresponding test case is selected from the preset test case template set, or a new test case is dynamically generated according to the rules to ensure that the test case is closely integrated with the actual situation and test requirements of the device, so that the test is targeted and effective, and can fully cover the various performance indicator tests of the device.

[0043] In some embodiments, the 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.

[0044] It can be seen that the test cases cover many aspects of equipment inspection, from online to comprehensive inspection of functions, working conditions, parameters and basic information. This comprehensiveness conducts a comprehensive evaluation of the equipment to avoid missing key inspection points, ensure that urban lighting monitoring equipment meets the requirements in all aspects, improve the integrity and effectiveness of the test, and help improve equipment quality and system stability.

[0045] In some embodiments, it is mainly composed of test parameters TestParams and orderly arranged test items AbstractTestStep. Among them, the test items adopt the design pattern of abstract class, which 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 easily and flexibly expand a variety of test functions and scenarios based on specific test requirements. It is worth mentioning that it is equipped with default test items. These default test items have been carefully selected and optimized to cover and meet most common test scenarios. Whether it is the basic function detection of urban lighting monitoring equipment, such as the verification of lighting on and off functions, the determination of brightness adjustment range, or the testing of core performance indicators such as equipment communication stability and data transmission accuracy, the default test items can respond efficiently. This not only improves the versatility and practicality of test cases, reduces the tedious 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 promoted, improving the test efficiency and quality.

[0046] S104. Construct a test context according to the general communication interface, the general protocol encoding and decoding interface, and the test case. 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; Among them, the test context represents the comprehensive information management and scheduling environment of the entire test process. It refers to a logical container that integrates various information resources such as general communication interfaces, general protocol encoding and decoding interfaces, and test cases. It is used to record various state changes, data information, and event situations during the test process.

[0047] In some embodiments, after obtaining the test case, the test context is constructed. First, the current connection status, communication parameters and other information of the general communication interface are entered into the test context, such as the number of currently connected urban lighting monitoring devices, the connection mode of each device, etc. Then, the standard data features parsed by the general protocol encoding and decoding interface, such as common data formats, field meanings and other information, are also integrated. At the same time, the detailed content of the test case, including the number of the test case, the test target, the test steps and other information, are 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, the execution time of the ongoing test items and other information, and the text description of the current test details is recorded in detail, such as the description of abnormal phenomena occurring during the test process, and the descriptive text content of the data reported by the urban lighting monitoring device, such as the description of the changes in a certain sensor data reported by the device, etc., to provide a comprehensive and detailed information basis for the monitoring, analysis and backtracking of the test, and ensure the manageability and traceability of the test process.

[0048] In the critical stage of building 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 responding to the complex needs of large-scale urban lighting monitoring equipment testing.

[0049] The test context covers a series of core methods, each of which performs its own functions and works together to build a complete and efficient test process framework. The first is the onTaskReady method, which methodically carries out preparations before starting the test, accurately clears the context cache, ensures the purity of the test environment and the consistency of the initial state, and publishes a preparation event to announce to the entire test system that the test process is about to start.

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

[0051] The onTaskEnd method marks the end of the test process. It publishes an end event at this time to notify the system that the test has completed the execution of all scheduled test items and the entire test process is about to end, so that the system can know the termination status of the test in time to perform subsequent resource recovery and result aggregation and other related operations.

[0052] Finally, the onTaskDone method focuses on the finishing work after the test is completed, publishes the completion event, and announces the successful completion of the test task at the overall level. During the entire test process, the context cache plays the role of an information center, which contains important data such as an accurate record of the current test progress, a detailed description of each step of the test, and details of possible problems. Each time an event is published, it will be cached in the event scheduler in an orderly manner. This mechanism provides a convenient interface for external programs to obtain the latest status of the test in real time. Based on this information, external programs can formulate and execute corresponding processing methods for each event. For example, when a test failure event is received, the troubleshooting and repair process is started; when a test completion event is received, a detailed test report is generated, etc., thereby realizing efficient interaction and collaborative work between the test system and the external environment, and further improving the intelligence level and overall efficiency of the automated testing of the entire urban lighting monitoring equipment.

[0053] S105, executing each test item in the test case in sequence; In some embodiments, after the test context is constructed, the steps of executing each test item in the test case in sequence are started. The system first reads the test case information from the test context and determines the first test item in the test case. Then, according to the requirements of the test item, the corresponding control instructions or data requests are sent to the urban lighting monitoring device through the universal communication interface. For example, if the test item is the sensor data acquisition function of the detection device, a data acquisition instruction is sent. Next, wait for the response data of the device, receive and parse the response data through the universal protocol encoding and decoding interface, compare the parsing result with the expected result of the test item, and record the comparison result. After completing the first test item, the same operation process is performed on the subsequent test items in the order specified in the test case, to ensure that the various functions and performances of the urban lighting monitoring equipment are comprehensively and orderly tested, without missing any key test points, to ensure the integrity and systematicness of the test.

[0054] In some specific embodiments, a linear execution method is adopted to create a test item execution queue, add test items in the test case to the queue in sequence, and then take out and execute the test items in the queue order. After executing one test item, the next one is taken out, until all test items in the queue are executed, which is not limited here.

[0055] In other specific embodiments, different states are defined for each test item, such as waiting for execution, executing, and completed execution. The execution of the next test item is driven according to the state transition of the current test item, and data is transferred and result recorded during the state transition process, which is not limited here.

[0056] S106: After the execution is completed, the test result is determined. When the test result is a 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; In some embodiments, after executing a test item, the step of determining the test result is initiated. The system first obtains the response data of the device to the test item from the general protocol codec 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 data accuracy test items, compare whether the difference between the numerical value in the response data and the expected numerical value is within the allowable error range; for functional integrity test items, check whether all expected functional identifiers are contained 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 count 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 results, improve the accuracy and reliability of the test, and ensure that the device obtains a more accurate performance evaluation after multiple tests.

[0057] S107, when the test result is successful or the number of failures exceeds the retry number threshold, the retry operation on the corresponding test item is terminated; at the same time, no matter whether the corresponding test item is successful or failed, an event of the test result status of the corresponding test item is generated and published according to the preset event triggering and generation mechanism; In some embodiments, after the test result is determined, if the test result is successful, it indicates that the test item has passed the test, and the retry operation of the corresponding test item is terminated directly because the test goal has been achieved. If the number of failures exceeds the retry number threshold, it means that the test item has a more serious or difficult to repair problem, 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, 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. 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. In addition to the above information, it can also include preliminary analysis information of the cause of failure (such as data anomalies, function unresponsiveness, etc.). These events can be received and processed by other system modules or external monitoring systems, so as to grasp the test progress and results in a timely manner, comprehensively monitor and manage the test process, and provide a basis for subsequent test analysis and equipment improvement.

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

[0059] Among them, the event scheduler refers to the core component specifically used to manage and process various events generated in the test context. It refers to a functional module that queues, distributes and executes events according to certain scheduling strategies and priority rules. It is used to ensure that events can be processed in an orderly and efficient manner to avoid event accumulation and processing confusion.

[0060] In some embodiments, when an event is generated in the test context, the event scheduler starts to work. It first receives event information from the test context and classifies the event according to a preset priority rule.

[0061] In some specific embodiments, a priority queue is combined with a thread pool to create event queues of different priorities, each queue corresponds to a thread pool, and when an event enters the queue, the thread in the thread pool processes the event in the order of the queue, which is not limited here.

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

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

[0064] It can be seen that the event scheduler, as an ordered blocking queue, processes events released by the test context in a first-in-first-out order. This makes the event processing process standardized and orderly, avoiding confusion and queue jumping. When multiple events are concurrent, they can be processed in an orderly manner to ensure that each event is handled reasonably and to ensure the stable operation of the test system.

[0065] It can be seen that 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 communication settings due to differences in equipment. The universal protocol codec interface parses the input data, accurately extracts key information and converts it into data, 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 from preparation to start, completion to end of the test, 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.

[0066] Example 1: Connecting a single lamp controller using the 1.1 protocol First, when communicating with the single-lamp controller of the control 1.1 protocol, given that it uses UDP communication and transmits binary messages, when instantiating the general communication interface, it is necessary to strictly follow the specific requirements of the UDP server. Specifically, the port number of the UDP server is accurately obtained from the pre-configured configuration file. Based on this port, on the one hand, it can monitor the binary data received on this port to realize data collection 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 input data for subsequent test processes. After the instantiation is completed, the communication is officially started through the open method specified by the general communication interface, and the data of the port is cyclically monitored in a separate thread to ensure the timeliness and integrity of data reception. This process perfectly matches the content of data interaction with different city lighting monitoring equipment through the general communication interface.

[0067] Subsequently, for the received binary message, the general protocol codec interface is instantiated according to the corresponding requirements for parsing and processing. When the communication instance receives the data, it will pass it to the codec instance. The codec instance will first accurately intercept the message header and message tail according to the established rules, and strictly check the content of the message to determine the integrity of the message, ensure that the data meets the requirements in both format and content, and avoid erroneous data from entering the subsequent process. Then, according to the given function code in the message, the preset corresponding codec method is used to convert the original binary message 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 codec interface to obtain the data.

[0068] In terms of arranging test cases, based on the universal characteristics of urban lighting monitoring equipment, test items are executed in the order of online inspection, equipment information inspection, equipment working parameters inspection, equipment working condition inspection, equipment light switch function inspection, and equipment communication parameters inspection. This order is set by comprehensively considering the importance of each functional module of the equipment and the rationality of the test logic. The requirement of parsing data to obtain test cases according to preset rules is followed to ensure that the test cases can comprehensively and specifically cover various key performance indicators of the equipment and realize all-round detection of single lamp controllers.

[0069] After that, the test context is constructed using the instantiated universal communication interface, universal protocol encoding and decoding interface, and the arranged test cases. The test context is like the core command hub of the entire test process. It updates the current test progress in real time during the test, and records the text description of the current test details and the descriptive text content of the data reported by the single lamp controller in detail, covering the relevant information of each important stage from test preparation events, test start events, to test completion events, test end events, etc., clearly presenting the full process status of the test.

[0070] When actually executing the test, each test item in the test case is executed in sequence, without manual intervention throughout the process, realizing a highly automated test process. After each test item is executed, the test result will be 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 threshold, the system will automatically test the test item again, eliminating the interference of accidental factors through multiple attempts to ensure the accuracy of the test results; and when the test result is a success or the number of failures exceeds the retry threshold, the retry operation of the corresponding test item is terminated. At the same time, regardless of whether the corresponding test item is ultimately successful or failed, the event of the test result status of the corresponding test item will be generated strictly in accordance with the preset event triggering and generation mechanism, and these events will be sent to the event scheduler for unified processing.

[0071] In the whole test process, various events generated at different stages play a clear and important role. When receiving the test preparation event, the system can store the relevant information of those devices with empty information in the database as a device registration record, which is convenient for the subsequent management and tracking of the equipment; when the test starts, the test context will send the test item success or failure event. At this time, the system can record the specific test information in detail in the database, or push it to the corresponding notification page, so that relevant personnel can observe the test progress in real time; when the test context releases the test end event, the system will fully record the results of this test and the collected device information, providing data support for subsequent analysis and summary; and when the test context releases the test completion event, the system will clear the test cache, destroy the test context, release system performance resources, and also notify the page to prepare for the next batch of equipment testing, ensuring the orderly connection of the entire test process and the rational use of system resources, and efficiently realizing the complete process of using the event scheduler to handle the events generated by the test context, which fully guarantees the smooth implementation of the control 1.1 protocol single lamp controller docking test and the reliability and effectiveness of the test results.

[0072] Example 2: MQTT protocol single lamp controller connection In the communication interface instantiation phase, since the MQTT protocol single lamp controller uses MQTT to communicate, it is necessary to access the MQTT server as a client when instantiating the general communication interface. With the unique subscription topic mechanism of MQTT, it is possible to accurately receive device data from the single lamp controller, and also use the publishing topic function to send data to the device, thereby building a stable and efficient data interaction channel, which perfectly meets the requirements of data interaction with different city lighting monitoring equipment through the general communication interface, and provides a stable data source for subsequent test processes.

[0073] In the instantiation of the codec interface, since the message transmitted is a json string, the json string needs to be converted into a json object in order to efficiently obtain the key-value pair information therein. Then, according to the key in the json or the subscribed topic, the corresponding codec method is quickly located and found in the preset codec rule system, and then converted into the message class required for automated testing, thereby successfully achieving the key step of parsing the input data through the general protocol codec interface to obtain the data, ensuring that the data can enter the subsequent test case generation link in a suitable format.

[0074] The subsequent test process is consistent with the implementation example 1. First, according to the common functions and preset rules of urban lighting monitoring equipment, the converted data is parsed to obtain test cases. These test cases cover the detection requirements for various aspects of the equipment performance and comprehensively and systematically plan the content and direction of the test. Then, the test context is constructed using the successfully instantiated general communication interface, general protocol encoding and decoding interface, and carefully arranged test cases. The test context plays a core hub role in the entire test process, updating the current test progress in real time, recording the text description of the current test details in detail, and the descriptive text content of the data reported by the single lamp controller. It fully covers the information presentation and management of each key stage from test preparation events, test start events to test completion events, test end events, etc., providing a strong guarantee for the smooth progress and monitoring of the test.

[0075] When executing each test item in the test case, there is no need for manual intervention and it is carried out in strict sequence. After the test item is executed, the test result is accurately determined. When the test result is a failure and the cumulative number of failures does not exceed the preset retry threshold, the test item is automatically tested again, and repeated verification is performed to eliminate the interference of accidental factors; if the test result is a success or the number of failures exceeds the retry threshold, the retry operation is terminated. In addition, regardless of the test result, the event of the test result status of the corresponding test item is generated according to the preset event triggering and generation mechanism, and it is sent to the event scheduler for unified processing and scheduling.

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

[0077] See also Figure 2 , Figure 2 This is another flow chart of the automated testing method for urban lighting monitoring equipment in an embodiment of the present application; In some embodiments, after step S105, the method further includes: S201, sending instructions to the city lighting monitoring equipment through the universal communication interface according to the preset time sequence and interval; In some embodiments, after step S105 executes each test item in the test case in sequence, this step is initiated in order to further test the response performance and collaborative working ability of the device under different time sequences. The system first reads the preset time sequence and interval information from the preset instruction sequence configuration file, and then accurately sends the corresponding instructions to the corresponding city lighting monitoring device through the universal communication interface according to the current connection status established between the universal communication interface and each city lighting monitoring device in accordance with the preset time sequence when each interval time arrives.

[0078] S202. After sending the command, monitor the response of the urban lighting monitoring equipment through the general communication interface and the general protocol codec interface. If a timing conflict is found in the urban lighting monitoring equipment, determine the conflicting urban lighting monitoring equipment and the corresponding urban lighting monitoring equipment, wherein the corresponding urban lighting monitoring equipment is the urban lighting monitoring equipment that should perform operations according to the correct timing when no conflict occurs; Among them, timing conflict refers to the situation that the actual response time sequence of the urban lighting monitoring equipment is inconsistent with the preset reasonable time sequence during the process of receiving and processing instructions. It refers to the phenomenon that the operations that should be executed in sequence are out of order due to factors such as differences in the processing speed of the equipment itself and network transmission delays. It is used to reflect the abnormal state in the time dimension when the equipment works together. Conflicting urban lighting monitoring equipment is those devices that do not respond to instructions in the correct time sequence when timing conflicts occur, while the corresponding urban lighting monitoring equipment is the equipment that should execute operations in the correct time sequence under normal circumstances but is affected by conflicts with other equipment.

[0079] In some embodiments, after executing the step S201 to send the instruction, it is necessary to closely monitor the response of the urban lighting monitoring equipment through the general communication interface and the general protocol codec interface. The system will continue to monitor the general communication interface to receive feedback data from each device, use the general protocol codec interface to parse these data, extract key information related to the instruction response time, operation execution order, etc., and then compare and analyze 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 light nodes, if the preset is to turn on the lighting in order of node 1, node 2, and node 3, and it is found by parsing the feedback data that node 3 is lit 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, so as to carry out targeted coordination processing later.

[0080] S203, instruct the corresponding city lighting monitoring device to send a synchronization instruction to the conflicting city lighting monitoring device through the universal communication interface, receive a reply instruction sent by the conflicting city lighting monitoring device using the universal communication interface, and obtain the sending time and receiving time of the synchronization instruction by parsing with the universal protocol encoding and decoding interface; In some embodiments, the corresponding city lighting monitoring device will send a synchronization instruction to the conflicting city lighting monitoring device through the universal communication interface according to the system's instructions. The content of the synchronization instruction will be customized according to the specific conflict situation, such as telling the other party how long to delay the response or what time to respond in advance. After sending, the conflicting city lighting monitoring device receives the synchronization instruction, and after internal processing, it uses the universal communication interface to send a reply instruction to the corresponding city lighting monitoring device to feedback the reception and processing status. On the test system side, the reply instruction sent by the conflicting city lighting monitoring device is received through the universal communication interface, and then the universal protocol codec interface is used to parse and obtain the sending time and receiving time of the synchronization instruction. These time data will serve as an important basis for subsequent calculations and adjustments.

[0081] S204, obtaining a first time difference through the sending time, the receiving time and the preset correction parameter; respectively obtaining a second time difference of the automatic test system of the urban lighting monitoring equipment for the conflicting urban lighting monitoring equipment and a third time difference of the automatic test system of the urban lighting monitoring equipment for the corresponding urban lighting monitoring equipment; Among them, the first time difference is calculated by the sending time and receiving time of the synchronization command and the preset correction parameters, reflecting the time difference between the time spent in the transmission of the synchronization command 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 equipment for the conflicting urban lighting monitoring equipment, reflecting the difference between the equipment time recorded by the test system and the actual time. The third time difference is similar, which is the time perception difference for the corresponding urban lighting monitoring equipment.

[0082] In some specific embodiments, the calculation is performed according to a 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, the preset time and the actual response time of the corresponding device are searched in the system's device time record database, and the difference is obtained by subtracting them.

[0083] S205, calculating a 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; Among them, the deviation indicates the degree of deviation between the current actual time of the conflict city lighting monitoring equipment and the theoretical time. It refers to a time deviation obtained after comprehensively considering factors such as the difference in the automated test system's time perception and the time difference in the synchronization command interaction process. It is used to locate the degree of abnormality in the time of the conflict city lighting monitoring equipment and the direction and magnitude of the correction that needs to be made.

[0084] S206. Obtain the time function of the conflicting city lighting monitoring device, and the time function is used to correct the time of the data sent by the conflicting city lighting monitoring device; the time function is calculated as follows: the first time difference plus the current time of the conflicting city lighting monitoring device minus the current time of the conflicting city lighting monitoring device 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 current time of the conflicting city lighting monitoring device to the second intermediate quantity to obtain the time function.

[0085] The time function is a mathematical expression used to correct the time of data sent by the conflicting urban lighting monitoring equipment. It refers to a functional relationship that can dynamically adjust the time of the conflicting equipment through a series of time parameter calculation combinations. For example, by substituting the various time differences and other data calculated in the previous steps into the time function, a specific time adjustment amount can be obtained, so that the next data sending time of the conflicting equipment can meet the overall preset timing requirements.

[0086] It can be seen that 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 instruction 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.

[0087] In actual use, the event scheduler may not handle events generated by the test context in a timely manner when facing a large number of concurrent events or events that occur in rapid succession, which may result in some important events not being processed, affecting the subsequent testing.

[0088] See also Figure 3 , Figure 3 This is a specific flow chart of step S108 in the embodiment of the present application; In some embodiments, step S108 specifically includes: S301, classifying events into three priority levels: high, medium, and low according to a preset priority table; 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.

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

[0090] 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; 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.

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

[0092] S303: Process events in the priority queue in order of waiting time.

[0093] 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 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 to avoid untimely processing, thereby improving the overall test reliability.

[0094] The following introduces an exemplary automated testing system 400 for urban lighting monitoring equipment provided in an embodiment of the present application. Figure 4 Schematic diagram of an exemplary hardware structure of an automated testing system 400 for urban lighting monitoring equipment provided in an embodiment of the present application.

[0095] 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 via 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, the method in the embodiment of the present application is implemented.

[0096] Those skilled in the art will understand that Figure 4 The structure shown in the figure is only a block diagram of a part of the structure 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 a different arrangement of components.

[0097] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, 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.

[0098] As used in the above embodiments, the term "when..." may be interpreted to mean "if..." or "after..." or "in response to determining..." or "in response to detecting...", depending on the context. Similarly, the phrases "upon determining..." or "if (the stated condition or event) is detected" may be interpreted to mean "if determining..." or "in response to determining..." or "upon detecting (the stated condition or event)" or "in response to detecting (the stated condition or event)", depending on the context.

[0099] 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 process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from one website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk), etc.

[0100] Those skilled in the art can understand that to implement all or part of the processes in the above-mentioned embodiments, the processes can be completed by computer programs to instruct related hardware, and the programs can be stored in computer-readable storage media. When the programs are executed, they can include the processes of the above-mentioned method embodiments. The aforementioned storage media include: ROM or random access memory RAM, magnetic disk or optical disk and other media that can store program codes.

Claims

1. An automated testing method for urban lighting monitoring equipment, characterized in that: include: Data is exchanged with different city lighting monitoring devices through a universal communication interface, and the received data is used as input data; Parsing the input data through a universal protocol encoding and decoding interface to obtain a standard data structure that can be processed by the program; Get test cases based on preset rules and standard data structures; A test context is constructed according to the universal communication interface, the universal protocol encoding and decoding interface, and the test case, wherein the test context updates the current test progress, a text description of the current test details, and the descriptive text content of the data reported by the urban lighting monitoring equipment, including a test preparation event, a test start event, a test completion event, and a test end event; Execute each test item in the test case in sequence; 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; Events generated by the test context are processed using an event dispatcher.

2. The method according to claim 1, characterized in that After the step of sequentially executing each test item in the test case, the method further includes: Sending instructions to the city lighting monitoring equipment via the universal communication interface according to the preset time sequence and interval; After sending the command, the response of the urban lighting monitoring equipment is monitored through the universal communication interface and the universal protocol codec interface. If a timing conflict is found in the urban lighting monitoring equipment, the conflicting urban lighting monitoring equipment and the corresponding urban lighting monitoring equipment are determined, wherein the corresponding urban lighting monitoring equipment is the urban lighting monitoring equipment that should perform operations according to the correct timing when no conflict occurs; Instruct the corresponding city lighting monitoring device to send a synchronization instruction to the conflicting city lighting monitoring device through the universal communication interface, receive a reply instruction sent by the conflicting city lighting monitoring device using the universal communication interface, and obtain the sending time and receiving time of the synchronization instruction by parsing with the universal protocol encoding and decoding interface; Obtain a first time difference through the sending time, the receiving time and the preset correction parameters; respectively obtain a second time difference of the automated test system of the urban lighting monitoring equipment for the conflicting urban lighting monitoring equipment and a third time difference of the automated test system of the urban lighting monitoring equipment for the corresponding urban lighting monitoring equipment; Calculate and obtain the deviation of the conflicting city lighting monitoring device, where the deviation is the current time of the conflicting city lighting monitoring device minus the current time of the automated test system of the city lighting monitoring device minus the second time difference; A time function of the conflicting city lighting monitoring device is obtained, and the time function is used to correct the time of the data sent by the conflicting city lighting monitoring device; the time function is calculated as follows: the first time difference plus the current time of the conflicting city lighting monitoring device minus the current time of the conflicting city lighting monitoring device minus the second time difference 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 city lighting monitoring device is added to the second intermediate quantity to obtain the time function.

3. The method according to claim 1, characterized in that The step of using the event scheduler to process the event generated by the test context specifically includes: 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 are processed in the priority queue in order of waiting time.

4. The method according to claim 1, characterized in that: The universal communication interface includes: communication parameters, establishing communication, communication start and stop, and data sending and receiving, wherein 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, the MQTT server is connected as an MQTT client.

5. The method according to claim 1, characterized in that The universal protocol encoding and decoding interface includes message unpacking, message verification, and function code extraction. The message unpacking is to divide the input data into multiple messages according to the preset message header, message tail and message length bytes. The message verification is to determine whether the message is correct according to the preset verification method. The function code extraction is to parse out the corresponding device function in the message.

6. The method according to claim 1, characterized in that The 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.

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

8. An automated testing system for urban lighting monitoring equipment, characterized in that: The automated testing system for urban lighting monitoring equipment 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 to enable the automated testing system for urban lighting monitoring equipment to execute the method as described in any one of claims 1 to 7.

9. A computer program product comprising instructions, characterized in that When the computer program product runs on an automated testing system for urban lighting monitoring equipment, the automated testing system for urban lighting monitoring equipment executes the method according to any one of claims 1 to 7.

10. A computer-readable storage medium comprising instructions, characterized in that: When the instruction is executed on the automated testing system of the urban lighting monitoring equipment, the automated testing system of the urban lighting monitoring equipment executes the method according to any one of claims 1 to 7.

Images