Device testing method, apparatus, device, and storage medium

Abstract

The present disclosure provides a device testing method, device, apparatus and storage medium, and relates to the technical field of device testing. In some embodiments of the present disclosure, a fault injection instruction and a control instruction sent by a test host computer are received, wherein the control instruction is an instruction including a fault type, a duration, a fault interval and an injection number sent by the test host computer through a communication interface after running a fault injection driver; an API interface provided by the fault injection driver is called according to the fault injection instruction and the control instruction; a test sequence is executed according to a predefined test case set to obtain a test result; the test sequence includes a bus short circuit recovery test, a continuous message conflict stress test, a common mode interference tolerance test and an impedance mismatch communication test; and a structured test report is generated according to the test result; the present disclosure simulates various abnormalities of a bus for device testing through fault injection, thereby improving the accuracy of device testing.

Description

Technical Field

[0001] This disclosure relates to the field of equipment testing technology, and in particular to an equipment testing method, apparatus, device and storage medium. Background Technology

[0002] KNX bus technology, as an international standard building automation communication protocol, has been widely used in smart homes and smart buildings due to its high reliability and interoperability. At the physical layer, the KNX bus typically uses twisted-pair cable as the transmission medium, maintains a standard operating voltage of 29V, and sets the communication rate at 9600bps. Although the protocol itself has certain anti-interference design features, the physical environment in actual engineering deployments and long-term operation is often far more complex than the ideal laboratory environment. Physical layer anomalies such as impedance mismatch caused by cable aging, short circuits or open circuits due to wiring errors during construction, common-mode noise caused by high-voltage intrusion, and bus conflicts caused by concurrent communication of multiple devices occur frequently. This places extremely high demands on the hardware robustness and software fault tolerance of terminal devices connected to the bus (such as central control screens).

[0003] Existing KNX control panel production line testing technologies primarily focus on verifying the functional integrity of the device under standard, ideal bus environments. Typically, the testing process connects to a standard KNX power supply and interface, and sends standard KNX messages to detect whether the device can respond to commands, drive the screen display, and execute logic control normally.

[0004] Currently, production line testing verifies the basic functions of equipment under ideal bus conditions, but it cannot test for hardware and software failures under abnormal bus scenarios. Therefore, the accuracy of equipment testing is low. Summary of the Invention

[0005] This disclosure provides a device testing method, apparatus, equipment, and storage medium to at least address the problem of low accuracy in existing device testing.

[0006] The technical solution disclosed herein is as follows: This disclosure provides a device testing method, including: The system receives fault injection instructions and control instructions sent by the test host computer. The control instructions are sent by the test host computer through the communication interface after running the fault injection driver. The control instructions include: fault type, duration, fault interval, and number of injections. According to the fault injection instruction and the control instruction, the API interface provided by the fault injection driver is invoked; The test sequence is executed according to a predefined set of test cases to obtain test results; the test sequence includes: bus short-circuit recovery test, continuous message collision stress test, common-mode interference tolerance test and impedance mismatch communication test. Based on the test results, a structured test report is generated.

[0007] Optionally, the API interface is a Python API interface; the step of calling the API interface provided by the fault injection driver according to the fault injection instruction and the control instruction includes: The test management layer calls the Python API interface provided by the fault injection driver to perform scripted control of fault injection.

[0008] Optionally, the test results include: bus short-circuit recovery test results, wherein the step of executing the test sequence according to a predefined test case set to obtain the test results includes: During the bus short-circuit recovery test, a bus short-circuit fault of a preset duration is injected into the device under test. Monitor whether the device under test resumes KNX communication within a preset recovery time, and monitor whether the operating system crashes; If KNX communication is restored within the preset recovery time, a bus short-circuit recovery test result indicating successful communication recovery is generated. If KNX communication is not restored within the preset recovery time, a bus short-circuit recovery test result indicating unsuccessful communication recovery will be generated. If the response time of the operating system is detected to be greater than or equal to the preset response time, a bus short-circuit recovery test result for the operating system crash is generated. If the operating system's response time is detected to be less than the preset response time, a normal bus short-circuit recovery test result is generated.

[0009] Optionally, the test results include: continuous message collision stress test results, wherein the step of executing the test sequence according to a predefined test case set to obtain the test results includes: Inject message conflicts continuously at preset time intervals for a preset duration, and then count the number of message retransmissions and the communication success rate of the device under test. If the communication success rate is greater than a preset success rate threshold, a continuous message conflict stress test result is generated indicating that the conflict test has passed. If the communication success rate is less than or equal to the preset success rate threshold, a continuous message conflict stress test result indicating that the conflict test failed is generated.

[0010] Optionally, the test results include: common-mode interference tolerance test results, wherein the test results obtained by executing the test sequence according to a predefined test case set include: Under a common-mode noise environment with preset frequency and preset amplitude, monitor the KNX group transmission frequency of the device under test to determine whether a malfunction occurs. If the KNX group's message transmission frequency exceeds the preset frequency threshold, it is determined to be a false action; If no malfunction occurs within the preset malfunction duration, a common-mode interference tolerance test result indicating that the interference test has passed is generated. If a malfunction occurs within the preset malfunction time, a common-mode interference tolerance test result indicating that the interference test has failed will be generated.

[0011] Optionally, the test results include: impedance mismatch communication test results, wherein the test results obtained by executing the test sequence according to the predefined test case set include: A series impedance with a preset value is connected to the bus to test the communication quality of the device under test. The communication quality includes the signal-to-noise ratio and frame error rate of the device under test. If the frame error rate is less than the error rate threshold, an impedance mismatch communication test result indicating that the impedance test has passed is generated. If the frame error rate is greater than or equal to the error rate threshold, an impedance mismatch communication test result indicating that the impedance test has failed is generated.

[0012] Optionally, the method further includes: The diagnostic command-line tool in the device under test is read to access the virtual file node to obtain the internal state of the KNX protocol stack, wherein the internal state includes the bus online or offline status, the number of reconnection attempts, and frame error statistics.

[0013] This disclosure also provides a device testing apparatus, including: The receiving module is used to receive fault injection instructions and control instructions sent by the test host computer. The control instructions are instructions sent by the test host computer through the communication interface after running the fault injection driver. The control instructions include: fault type, duration, fault interval and number of injections. The calling module is used to call the API interface provided by the fault injection driver according to the fault injection instruction and the control instruction; The testing module is used to execute test sequences according to a predefined set of test cases and obtain test results; the test sequences include: bus short-circuit recovery test, continuous message collision stress test, common-mode interference tolerance test, and impedance mismatch communication test. The generation module is used to generate a structured test report based on the test results.

[0014] This disclosure also provides an electronic device, including: processor; Memory used to store processor-executable instructions; The processor is configured to execute instructions to implement the steps in the above method.

[0015] This disclosure also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0016] The technical solutions provided by the embodiments of this disclosure bring at least the following beneficial effects: In some embodiments of this disclosure, a fault injection command and a control command are received from a test host computer. The control command, issued by the test host computer through a communication interface after running the fault injection driver, includes the fault type, duration, fault interval, and number of injection attempts. Based on the fault injection command and the control command, the API interface provided by the fault injection driver is invoked. A test sequence is executed according to a predefined test case set to obtain test results. The test sequence includes: bus short-circuit recovery test, continuous message collision stress test, common-mode interference tolerance test, and impedance mismatch communication test. A structured test report is generated based on the test results. This disclosure simulates various bus anomalies through fault injection to perform device testing, thereby improving the accuracy of device testing.

[0017] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0019] Figure 1 A schematic flowchart of a device testing method provided for an exemplary embodiment of this disclosure; Figure 2 A schematic diagram of the structure of a device testing apparatus provided for an exemplary embodiment of this disclosure; Figure 3 A schematic diagram of the structure of an electronic device provided for an exemplary embodiment of this disclosure. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0021] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure.

[0022] It should be noted that the user information involved in this disclosure includes, but is not limited to, user device information and user personal information; the collection, storage, use, processing, transmission, provision and disclosure of user information in this disclosure all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0023] To address the aforementioned technical problems, in some embodiments of this disclosure, fault injection instructions and control instructions sent by a test host computer are received. The control instructions are sent by the test host computer through a communication interface after running the fault injection driver, and include: fault type, duration, fault interval, and number of injections. Based on the fault injection instructions and control instructions, the API interface provided by the fault injection driver is invoked. A test sequence is executed according to a predefined test case set to obtain test results. The test sequence includes: bus short-circuit recovery test, continuous message collision stress test, common-mode interference tolerance test, and impedance mismatch communication test. A structured test report is generated based on the test results. This disclosure improves the accuracy of device testing by simulating various bus anomalies through fault injection.

[0024] The technical solutions provided by the embodiments of this disclosure are described in detail below with reference to the accompanying drawings.

[0025] Figure 1 This is a schematic flowchart illustrating a device testing method provided as an exemplary embodiment of this disclosure. Figure 1 As shown, the method includes: S101: Receives fault injection instructions and control instructions sent by the test host computer. The control instructions are sent by the test host computer through the communication interface after running the fault injection driver. The control instructions include: fault type, duration, fault interval and number of injections. S102: Call the API interface provided by the fault injection driver according to the fault injection instruction and control instruction; S103: Execute the test sequence according to the predefined test case set to obtain the test results; the test sequence includes: bus short circuit recovery test, continuous message collision stress test, common mode interference tolerance test and impedance mismatch communication test. S104: Generate a structured test report based on the test results.

[0026] In this embodiment, the entity executing the above method can be a terminal device or a server.

[0027] The terminal device includes, but is not limited to, mobile stations (MS), mobile terminals, mobile phones, handsets, and portable equipment. This terminal device can communicate with one or more core networks via a radio access network (RAN). For example, the terminal device can be a mobile phone (or "cellular" phone), a computer with wireless communication capabilities, a computer with wireless transceiver capabilities, a virtual reality (VR) terminal device, an AR terminal device, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical care, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, etc. The operating systems installed on the terminal device include, but are not limited to, iOS, Android, Windows, Linux, and Mac OS. In different networks, terminals may be called by different names, such as: user equipment, mobile station, user unit, station, cellular phone, personal digital assistant, wireless modem, wireless communication device, handheld device, laptop, cordless phone, wireless local loop station, television, etc. For ease of description, this embodiment will simply refer to it as terminal device.

[0028] In this embodiment, the implementation form of the server is not limited. For example, the server can be a conventional server, a cloud server, a cloud host, a virtual center, or other server devices. The server mainly consists of a processor, hard disk, memory, system bus, and other common computer architecture types.

[0029] In this embodiment, fault injection instructions and control instructions sent by the test host computer are received. The control instructions are sent by the test host computer through the communication interface after running the fault injection driver, and include: fault type, duration, fault interval, and number of injections. Based on the fault injection instructions and control instructions, the API interface provided by the fault injection driver is invoked. A test sequence is executed according to a predefined test case set to obtain test results. The test sequence includes: bus short-circuit recovery test, continuous message collision stress test, common-mode interference tolerance test, and impedance mismatch communication test. A structured test report is generated based on the test results. This disclosure improves the accuracy of device testing by simulating various bus anomalies through fault injection.

[0030] It should be noted that the KBFIM (KNX Bus Fault Injection Module) is connected in series to the KNX bus loop of the production line test station, located between the KNX power supply and the device under test (KNX central control screen).

[0031] The KNX central control screen (often also known as the KNX smart touchscreen) is a visual interactive terminal in the KNX smart home or building control system. Through a graphical interface, it centralizes the control of various devices such as lighting, curtains, air conditioning, and security systems onto a single screen, providing users with an intuitive and convenient operating experience.

[0032] In some embodiments of this disclosure, the KBFIM is controlled by an independent MCU and communicates with the host computer via a USB-CDC or RS232 interface to receive fault injection commands. The protocol format is: command byte + parameters + checksum. The MCU firmware implements precise fault timing control, resulting in high injection time accuracy.

[0033] In some embodiments of this disclosure, the test host computer runs a fault injection driver and sends control commands to the KBFIM. Specifically, the test host computer sends control commands to the KBFIM via a serial port or USB. In some embodiments of this disclosure, the API interface provided by the fault injection driver is invoked according to the fault injection instructions and control instructions. One possible approach is to perform scripted control of fault injection by having the test management layer invoke the Python API interface provided by the fault injection driver. The Python API interface provided by the fault injection driver is available for the test management layer to invoke, enabling scripted control of fault injection.

[0034] In some embodiments of this disclosure, the production line stress testing framework automatically executes test sequences according to a predefined set of test cases, wherein the test sequences include: bus short-circuit recovery test, continuous message collision stress test, common-mode interference tolerance test, and impedance mismatch communication test.

[0035] In some embodiments of this disclosure, during the bus short-circuit recovery test, a bus short-circuit fault of a preset duration is injected into the device under test (DUT); it is monitored whether the DUT recovers KNX communication within a preset recovery time, and whether the operating system crashes; if KNX communication is recovered within the preset recovery time, a bus short-circuit recovery test result indicating successful communication recovery is generated; if KNX communication is not recovered within the preset recovery time, a bus short-circuit recovery test result indicating unsuccessful communication recovery is generated; if the operating system's response time is detected to be greater than or equal to a preset response time, a bus short-circuit recovery test result indicating an operating system crash is generated; if the operating system's response time is detected to be less than a preset response time, a bus short-circuit recovery test result indicating an operating system crash is generated. It should be noted that this disclosure does not limit the preset duration, preset recovery time, or preset response time, which can be adjusted according to actual circumstances.

[0036] For example, during the bus short-circuit recovery test, a bus short-circuit fault lasting 500 milliseconds is injected into the device under test (DUT). The test monitors whether the DUT restores KNX communication within 3 seconds and whether the operating system crashes. Specifically, the recovery time is calculated by parsing the "KNX_BUS_RECONNECT_SUCCESS" log flag in the device's logcat. If KNX communication is restored within 3 seconds, a successful bus short-circuit recovery test result is generated; otherwise, a failed result is generated. The operating system's response time is also monitored. If the response time is greater than or equal to 5 seconds, a bus short-circuit recovery test result indicating an operating system crash is generated; if the response time is less than 5 seconds, a normal result is generated.

[0037] In some embodiments of this disclosure, message conflicts are continuously injected at preset time intervals for a preset duration, and the number of message retransmissions and communication success rate of the device under test are statistically analyzed. If the communication success rate is greater than a preset success rate threshold, a continuous message conflict stress test result indicating that the conflict test has passed is generated; if the communication success rate is less than or equal to the preset success rate threshold, a continuous message conflict stress test result indicating that the conflict test has failed is generated. It should be noted that this disclosure does not limit the preset time interval, preset success rate threshold, or preset success rate threshold; these parameters can be adjusted according to actual circumstances.

[0038] For example, message collisions are continuously injected at 100-millisecond intervals for 30 seconds. The number of message retransmissions and the communication success rate of the device under test are counted. The communication success rate is counted by bus monitoring. If the communication success rate is greater than 90%, a continuous message collision stress test result is generated indicating that the collision test has passed. If the communication success rate is less than or equal to 90%, a continuous message collision stress test result is generated indicating that the collision test has failed. This continuous message collision stress test evaluates the communication stability of the device in a collision environment.

[0039] In some embodiments of this disclosure, during the common-mode interference tolerance test, under a common-mode noise environment with a preset frequency and preset amplitude, the KNX group transmission frequency of the device under test is monitored to determine whether a malfunction occurs. If the KNX group transmission frequency is greater than a preset frequency threshold, it is determined to be a malfunction. If no malfunction occurs within a preset malfunction duration, a common-mode interference tolerance test result indicating that the interference test has passed is generated. If a malfunction occurs within a preset malfunction duration, a common-mode interference tolerance test result indicating that the interference test has failed is generated. It should be noted that this disclosure does not limit the preset frequency, preset amplitude, preset malfunction duration, and preset frequency threshold; these parameters can be adjusted according to actual circumstances.

[0040] For example, during the common-mode interference tolerance test, in a common-mode noise environment with a preset frequency of 1kHz and a preset amplitude of 10Vpp, the KNX communication function of the device under test is verified to be normal, and the KNX group transmission frequency of the device under test is monitored. If the group transmission frequency is more than 3 times the normal value, it is judged as a malfunction. If no malfunction occurs within 60 seconds, a common-mode interference tolerance test result indicating that the interference test has passed is generated. If a malfunction occurs within 60 seconds, a common-mode interference tolerance test result indicating that the interference test has failed is generated.

[0041] In some embodiments of this disclosure, during the impedance mismatch communication test, a series impedance of a preset value is connected to the bus to test the communication quality of the device under test. The communication quality includes the signal-to-noise ratio and frame error rate of the test device. If the frame error rate is less than an error rate threshold, an impedance mismatch communication test result indicating that the impedance test has passed is generated; if the frame error rate is greater than or equal to the error rate threshold, an impedance mismatch communication test result indicating that the impedance test has failed is generated. It should be noted that this disclosure does not limit the error rate threshold and can be adjusted according to actual conditions.

[0042] For example, a 100Ω series impedance is connected to the bus to test the communication quality of the device under test. The communication quality includes the signal-to-noise ratio and frame error rate of the device under test. If the frame error rate is less than 5%, an impedance mismatch communication test result is generated indicating that the impedance test has passed. If the frame error rate is greater than or equal to 5%, an impedance mismatch communication test result is generated indicating that the impedance test has failed.

[0043] It should be noted that if the bus short-circuit recovery test, continuous message collision stress test, common-mode interference tolerance test, and impedance mismatch communication test are all passed, a test result of passing will be generated; if any one of the bus short-circuit recovery test, continuous message collision stress test, common-mode interference tolerance test, and impedance mismatch communication test is failed, a test result of failing will be generated.

[0044] In some embodiments of this disclosure, before and after each test step, the diagnostic command-line tool in the device under test is read, and the virtual file node is accessed to obtain the internal state of the KNX protocol stack. The internal state includes the bus online or offline status, the number of reconnections, and frame error statistics.

[0045] In some embodiments of this disclosure, a structured test report is generated based on the test results. The production line stress testing framework automatically generates a structured test report containing JSON or HTML format, detailing quantitative indicators such as the pass / fail status of each test case, fault recovery time, and number of malfunctions. It also calculates the KNX bus robustness level (A / B / C / D levels) of the device using a weighted scoring algorithm, with level B and above considered the production line's acceptable factory standard.

[0046] In some embodiments of this disclosure, test reports are automatically uploaded to the production line MES system and bound to the equipment serial number for quality statistical analysis and batch defect tracing.

[0047] Figure 2 This is a schematic diagram of the structure of a device testing apparatus 20 provided for an exemplary embodiment of this disclosure. (See diagram below.) Figure 2As shown, the device testing apparatus 20 includes: a receiving module 21, a calling module 22, a testing module 23, and a generating module 24.

[0048] The receiving module 21 is used to receive fault injection instructions and control instructions sent by the test host computer. The control instructions are instructions sent by the test host computer through the communication interface after running the fault injection driver. The control instructions include: fault type, duration, fault interval and number of injections. Module 22 is used to call the API interface provided by the fault injection driver according to the fault injection command and control command; Test module 23 is used to execute test sequences according to a predefined set of test cases and obtain test results; the test sequences include: bus short-circuit recovery test, continuous message collision stress test, common-mode interference tolerance test and impedance mismatch communication test; Module 24 is used to generate a structured test report based on the test results.

[0049] Optionally, the API interface is a Python API interface; when calling the API interface provided by the fault injection driver based on the fault injection instructions and control instructions, module 22 is used for: By testing the management layer's calls to the Python API interface provided by the fault injection driver, fault injection can be controlled via scripts.

[0050] Optionally, the test results include: bus short-circuit recovery test results. When the test module 23 executes the test sequence according to the predefined test case set and obtains the test results, it is used for: During the bus short-circuit recovery test, a bus short-circuit fault of preset duration is injected into the device under test. Monitor whether the device under test resumes KNX communication within the preset recovery time, and monitor whether the operating system crashes; If KNX communication is restored within the preset recovery time, a bus short-circuit recovery test result indicating successful communication recovery will be generated. If KNX communication is not restored within the preset recovery time, a bus short-circuit recovery test result indicating unsuccessful communication recovery will be generated. If the operating system's response time is detected to be greater than or equal to the preset response time, a bus short-circuit recovery test result for the operating system crash will be generated. If the operating system's response time is detected to be less than the preset response time, a normal bus short-circuit recovery test result for the operating system will be generated.

[0051] Optionally, the test results include: continuous message collision stress test results. When test module 23 executes the test sequence according to the predefined test case set and obtains the test results, it is used for: Inject message conflicts continuously at preset time intervals for a preset duration, and then count the number of message retransmissions and the communication success rate of the device under test. If the communication success rate is greater than the preset success rate threshold, a continuous message conflict stress test result is generated indicating that the conflict test has passed. If the communication success rate is less than or equal to the preset success rate threshold, a continuous message conflict stress test result is generated indicating that the conflict test failed.

[0052] Optionally, the test results include: common-mode interference tolerance test results. When the test module 23 executes the test sequence according to the predefined test case set and obtains the test results, it is used for: Under a common-mode noise environment with preset frequency and preset amplitude, monitor the KNX group transmission frequency of the device under test to determine whether a malfunction has occurred. If the KNX group's message transmission frequency exceeds the preset frequency threshold, it is determined to be a false action; If no malfunction occurs within the preset malfunction duration, a common-mode interference tolerance test result indicating that the interference test has passed is generated. If a malfunction occurs within the preset malfunction time, a common-mode interference tolerance test result indicating that the interference test has failed will be generated.

[0053] Optionally, the test results include: impedance mismatch communication test results. When test module 23 executes the test sequence according to the predefined test case set and obtains the test results, it is used for: Connect a series impedance with a preset value to the bus to test the communication quality of the device under test. The communication quality includes the signal-to-noise ratio and frame error rate of the device under test. If the frame error rate is less than the error rate threshold, an impedance mismatch communication test result indicating that the impedance test has passed is generated. If the frame error rate is greater than or equal to the error rate threshold, an impedance mismatch communication test result indicating that the impedance test has failed will be generated.

[0054] Optionally, test module 23 can also be used for: The diagnostic command-line tool in the device under test is read to access the virtual file node to obtain the internal state of the KNX protocol stack. The internal state includes the bus online or offline status, the number of reconnections, and frame error statistics.

[0055] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0056] Figure 3 This is a schematic diagram of the structure of an electronic device provided as an exemplary embodiment of the present disclosure. For example... Figure 3 As shown, the electronic device includes a memory 31 and a processor 32. Additionally, the electronic device also includes a power supply component 33 and a communication component 34.

[0057] Memory 31 is used to store computer programs and can be configured to store various other data to support operation on the electronic device. Examples of this data include instructions for any application or method used to operate on the electronic device.

[0058] The memory 31 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0059] Communication component 34 is used for data transmission with other devices.

[0060] The processor 32 executes computer instructions stored in the memory 31 to: receive fault injection instructions and control instructions sent by the host computer, wherein the control instructions are issued by the host computer through the communication interface after running the fault injection driver, and the control instructions include: fault type, duration, fault interval, and number of injections; call the API interface provided by the fault injection driver according to the fault injection instructions and control instructions; execute test sequences according to a predefined test case set to obtain test results; the test sequences include: bus short-circuit recovery test, continuous message collision stress test, common-mode interference tolerance test, and impedance mismatch communication test; and generate a structured test report based on the test results.

[0061] Accordingly, embodiments of this disclosure also provide a computer-readable storage medium storing a computer program. When the computer-readable storage medium stores a computer program, and the computer program is executed by one or more processors, it causes one or more processors to perform... Figure 1 Each step in the method embodiment.

[0062] Accordingly, embodiments of this disclosure also provide a computer program product, which includes a computer program / instructions that are executed by a processor. Figure 1 Each step in the method embodiment.

[0063] The above Figure 3The communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component also includes a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA) technology, Ultra-Wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0064] The above Figure 3 The power supply component provides power to the various components of the device in which it resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which it resides.

[0065] The aforementioned electronic devices also include a display screen and audio components.

[0066] The display includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of touch or swipe actions, but also the duration and pressure associated with the touch or swipe operation.

[0067] An audio component may be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals may be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0068] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0069] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0070] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0071] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0072] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0073] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0074] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0075] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0076] The above are merely specific embodiments of this disclosure, enabling those skilled in the art to understand or implement this disclosure. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to these embodiments, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A device testing method, characterized in that, include: The system receives fault injection instructions and control instructions sent by the test host computer. The control instructions are sent by the test host computer through the communication interface after running the fault injection driver. The control instructions include: fault type, duration, fault interval, and number of injections. According to the fault injection instruction and the control instruction, the API interface provided by the fault injection driver is invoked; The test sequence is executed according to a predefined set of test cases to obtain test results; the test sequence includes: bus short-circuit recovery test, continuous message collision stress test, common-mode interference tolerance test and impedance mismatch communication test. Based on the test results, a structured test report is generated.

2. The method according to claim 1, characterized in that, The API interface is a Python API interface; the step of calling the API interface provided by the fault injection driver according to the fault injection instruction and the control instruction includes: The test management layer calls the Python API interface provided by the fault injection driver to perform scripted control of fault injection.

3. The method according to claim 1, characterized in that, The test results include: bus short-circuit recovery test results. The test results obtained by executing the test sequence according to a predefined test case set include: During the bus short-circuit recovery test, a bus short-circuit fault of a preset duration is injected into the device under test. Monitor whether the device under test resumes KNX communication within a preset recovery time, and monitor whether the operating system crashes; If KNX communication is restored within the preset recovery time, a bus short-circuit recovery test result indicating successful communication recovery is generated. If KNX communication is not restored within the preset recovery time, a bus short-circuit recovery test result indicating unsuccessful communication recovery will be generated. If the response time of the operating system is detected to be greater than or equal to the preset response time, a bus short-circuit recovery test result for the operating system crash is generated. If the operating system's response time is detected to be less than the preset response time, a normal bus short-circuit recovery test result is generated.

4. The method according to claim 1, characterized in that, The test results include: continuous message collision stress test results. The test results obtained by executing the test sequence according to a predefined test case set include: Inject message conflicts continuously at preset time intervals for a preset duration, and then count the number of message retransmissions and the communication success rate of the device under test. If the communication success rate is greater than a preset success rate threshold, a continuous message conflict stress test result is generated indicating that the conflict test has passed. If the communication success rate is less than or equal to the preset success rate threshold, a continuous message conflict stress test result indicating that the conflict test failed is generated.

5. The method according to claim 1, characterized in that, The test results include: common-mode interference tolerance test results. The test results obtained by executing the test sequence according to a predefined test case set include: Under a common-mode noise environment with preset frequency and preset amplitude, monitor the KNX group transmission frequency of the device under test to determine whether a malfunction has occurred. If the KNX group's message transmission frequency exceeds the preset frequency threshold, it is determined to be a false action; If no malfunction occurs within the preset malfunction duration, a common-mode interference tolerance test result indicating that the interference test has passed is generated. If a malfunction occurs within the preset malfunction time, a common-mode interference tolerance test result indicating that the interference test has failed will be generated.

6. The method according to claim 1, characterized in that, The test results include: impedance mismatch communication test results, wherein the test sequence is executed according to a predefined test case set to obtain the test results, including: A series impedance with a preset value is connected to the bus to test the communication quality of the device under test. The communication quality includes the signal-to-noise ratio and frame error rate of the device under test. If the frame error rate is less than the error rate threshold, an impedance mismatch communication test result indicating that the impedance test has passed is generated. If the frame error rate is greater than or equal to the error rate threshold, an impedance mismatch communication test result indicating that the impedance test has failed is generated.

7. The method according to claim 1, characterized in that, The method further includes: The diagnostic command-line tool in the device under test is read to access the virtual file node to obtain the internal state of the KNX protocol stack, including the bus online or offline status, reconnection count, and frame error statistics.

8. A device for testing equipment, characterized in that, include: The receiving module is used to receive fault injection instructions and control instructions sent by the test host computer. The control instructions are instructions sent by the test host computer through the communication interface after running the fault injection driver. The control instructions include: fault type, duration, fault interval and number of injections. The calling module is used to call the API interface provided by the fault injection driver according to the fault injection instruction and the control instruction; The testing module is used to execute test sequences according to a predefined set of test cases and obtain test results; the test sequences include: bus short-circuit recovery test, continuous message collision stress test, common-mode interference tolerance test, and impedance mismatch communication test; The generation module is used to generate a structured test report based on the test results.

9. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to execute instructions to implement the steps of the method as described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-7.

Images