Equipment detection method and system, test terminal and equipment to be detected

Abstract

The invention relates to the technical field of equipment detection, in particular to an equipment detection method and system, a test terminal and to-be-detected equipment. When the test terminal tests a plurality of to-be-detected devices, the test terminal firstly filters the connected to-be-detected devices and filters out illegal to-be-detected devices through check codes, then some detected devices are filtered out by detecting the detection state codes carried by the to-be-detected devices, repeated detection is avoided, and the detection efficiency is improved. The detection efficiency is improved; meanwhile, when the to-be-detected equipment which is not detected is detected, the test terminal can obtain the card control file corresponding to the to-be-detected terminal according to the equipment model, and detection of the to-be-detected equipment is completed according to the card control file. Therefore, the test terminal can automatically and adaptively detect the to-be-detected devices of various types, the test configuration does not need to be manually changed, the robustness of device detection is greatly improved, and the method can adapt to various test scenes.

Description

Technical Field

[0001] This application relates to the field of equipment testing technology, specifically to an equipment testing method, system, testing terminal, and device to be tested. Background Technology

[0002] With societal development, the application of smart wearable products is becoming increasingly widespread, such as smartwatches and smart bracelets, which are worn by users to monitor heart rate, blood oxygen, and air pressure. To achieve these functions, smart wearable products need sensors to monitor heart rate, blood oxygen, and air pressure. Therefore, the manufacturing process of smart wearable products requires testing, verification, and calibration of all hardware sensors and functions within the product.

[0003] The inventors of this application discovered in their research that smart wearable products need to undergo performance testing before leaving the factory. Existing technologies usually involve manual testing or software testing. Manual testing is time-consuming, labor-intensive, and has low testing efficiency. Moreover, the entire testing process relies on manual labor, which can easily lead to false detections or missed detections. Summary of the Invention

[0004] In view of the above problems, this application provides a device testing method, system, testing terminal, and device to be tested to solve the above-mentioned technical problems existing in the prior art.

[0005] According to one aspect of the embodiments of this application, a device testing method is proposed, applied to a testing terminal, the testing terminal being used to test multiple devices to be tested, the method comprising: Receive a broadcast message sent by the device under test, the broadcast message including the device model, check code and test status code of the device under test; The device to be tested is verified according to the verification code. If the verification is successful, a list of devices to be tested that have not been tested is determined according to the test status code. The list of devices to be tested includes the device models of the devices that have not been tested. Perform the following operations on each device in the list of devices to be tested, until the list of devices to be tested has been traversed: According to the device model, a control file is sent to the device to be tested in the list of devices to be tested. The control file includes detection data items so that the device to be tested can perform automatic detection based on the detection data items. The system receives a self-test data output file sent by the device under test, the self-test data output file including the test results corresponding to the test data items, compares the test results corresponding to the test data items with a preset test threshold, and determines the automatic test result of the device under test. A card control result file is generated based on the automatic detection results, and the card control result file is sent to the device under test so that the device under test can modify the detection status code according to the card control result file.

[0006] Optionally, in some embodiments, the broadcast message further includes a start character; Before verifying the device under test according to the check code, the process further includes: The devices to be tested are screened based on the start symbol; Obtain the signal strength indication of the device under test that has passed the screening, obtain the distance value between the device under test and the test terminal based on the signal strength indication, and if the distance value is less than a preset distance threshold, verify the device under test based on the check code.

[0007] Optionally, in some embodiments, the test terminal is also connected in communication with a server; The step of sending the control file to the devices in the list of devices to be tested according to the device model includes: Based on the device model, determine whether a card control file corresponding to the device model exists locally. If it does not exist, send a card control file retrieval request to the server so that the server returns the card control file corresponding to the device model.

[0008] Optionally, in some embodiments, the method further includes: The card control result file is sent to the server.

[0009] According to another aspect of the embodiments of this application, a device testing method is also proposed, applied to a device under test, the device under test being used to connect to the test terminal described in the above embodiments, the method comprising: Obtain the detection status code and send a broadcast message so that the test terminal can establish a connection with the device under test according to the broadcast message and send the card control file according to the detection status code; The system receives a card control file sent by the test terminal, the card control file includes detection data items, and performs automatic detection according to the card control file to generate a self-test data output file. The system then sends the self-test data output file to the test terminal so that the test terminal can generate a card control result file based on the self-test data output file. The system receives the card control result file sent by the test terminal and modifies its own detection status code according to the card control result file.

[0010] Optionally, in some embodiments, before sending the broadcast message, the process further includes: Obtain its own MAC address, device model, device serial number, and start character; A CRC checksum is generated based on the MAC address, device model, device serial number, and start character. The verification code is broadcast via the broadcast message.

[0011] According to a third aspect of the embodiments of this application, a test terminal and a device under test are also provided, including: a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other through the communication bus; The memory is used to store at least one program that causes the processor to execute the device detection method described in the above embodiments.

[0012] According to a fourth aspect of the embodiments of this application, a device testing system is also proposed, including the test terminal described in the above embodiments, a plurality of devices to be tested as described in the above embodiments, and a server; The test terminal connects to multiple devices under test via Bluetooth Low Energy and is used to test the multiple devices under test. The server is communicatively connected to the test terminal and is used to send card control files to the test terminal and store the card control result files sent by the test terminal.

[0013] According to a fifth aspect of the embodiments of this application, a readable computer storage medium is also provided, wherein the storage medium stores at least one program, which, when run on a test terminal, causes the test terminal to execute the device detection method described in the above embodiments; or, when run on a device to be tested, causes the device to be tested to execute the device detection method described in the above embodiments.

[0014] In summary, when the testing terminal tests multiple devices under test, it first filters the connected devices by using checksums to eliminate invalid devices. Then, by detecting the detection status code carried by the device itself, it filters out devices that have already been tested, avoiding duplicate testing and improving efficiency. Simultaneously, when testing devices that haven't been tested, the testing terminal retrieves the corresponding control file based on the device model and completes the testing according to the control file. This approach allows the testing terminal to automatically and adaptively test various types of devices without requiring manual changes to test configurations or manual classification of devices. It adapts to various types of devices, significantly improving the robustness of device testing and making it suitable for diverse testing scenarios.

[0015] The above description is merely an overview of the technical solutions of the embodiments of this application. In order to better understand the technical means of the embodiments of this application and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of this application more obvious and understandable, specific implementation methods of this application are described below. Attached Figure Description

[0016] The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a schematic diagram of the equipment testing system proposed in the embodiments of this application; Figure 2 This is a schematic flowchart of the equipment testing method proposed in the embodiments of this application; Figure 3 This is a schematic diagram of the broadcast message data structure in the device detection method proposed in this application embodiment; Figure 4 This is a schematic diagram of the card control file structure proposed in an embodiment of this application; Figure 5 This is a schematic diagram of the self-test data output file structure proposed in an embodiment of this application; Figure 6 This is a schematic diagram of the card control result file structure proposed in the embodiments of this application; Figure 7 This is a schematic flowchart of another device testing method proposed in an embodiment of this application; Figure 8 This is an interactive signaling diagram of the equipment detection system proposed in an embodiment of this application; Figure 9 This is a schematic diagram of the test terminal and the device under test proposed in the embodiments of this application. Detailed Implementation

[0017] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. Although exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein.

[0018] In order to conduct factory testing of smart wearable products, the existing technology lists the detection items of each sensor separately on the screen of the smart wearable product, and the detection items are detected by manually clicking on the screen. After the test is completed, the worker records whether the test item passes or fails by checking the test results output on the screen. This method is labor-intensive, and the manual recording process may result in recording errors, which may lead to missed detections or incorrect test results.

[0019] To reduce manual intervention, smart wearable devices can be connected to a computer via USB. The computer-based testing software then controls the wearable device via USB communication to automate the testing and record the results automatically. However, this method still requires manual connection of the wearable device and computer using a USB cable, and manual startup of the testing software, which is also labor-intensive. Furthermore, it can only test one device at a time, resulting in low efficiency. Additionally, some smart wearable devices' USB ports only provide charging functionality and lack USB communication capabilities, making testing impossible via USB or similar interfaces.

[0020] Bluetooth Low Energy (BLE) technology has become an essential function for communication between smart wearable devices and mobile apps. Data interaction via BLE greatly expands the functionality and data visualization capabilities of smartwatches. To address issues encountered in the factory testing of smart wearable devices in existing technologies, this applicant proposes applying BLE technology to the testing of smart wearable devices. By connecting the test terminal to the smart wearable device using BLE technology, the test terminal can automatically control the testing process, thereby improving the automation level and testing efficiency of smart wearable devices.

[0021] The inventors of this application discovered during their research that, while introducing BLE technology into the testing of smart wearable devices allows for the connection of a test terminal to multiple smart wearable devices, enabling simultaneous testing of multiple devices, in practice, only smart wearable devices of the same type can often be tested at a time. When different types of smart wearable devices are involved, the test terminal cannot automatically identify them, requiring manual identification and modification of the test terminal's configuration before testing of new types of smart wearable devices can proceed, thus impacting testing efficiency. Furthermore, in some special testing scenarios, it is impossible to effectively identify smart wearable devices that have already passed or failed testing, often resulting in repeated testing. This wastes testing resources and further hinders the improvement of testing efficiency.

[0022] In view of this, this application proposes a device detection method, system, test terminal, and device under test to solve the aforementioned technical problems in the prior art. In this application embodiment, Bluetooth Low Energy technology is used to achieve wireless connection between the test terminal and multiple devices under test. When testing multiple devices under test through the test terminal, the test terminal first filters the connected devices under test, filtering out illegal devices using a checksum. Then, by detecting the detection status code carried by the device under test itself, some devices that have already been tested are filtered out, avoiding duplicate testing and improving detection efficiency. Simultaneously, when testing devices that have not been tested, the test terminal first obtains the device model of the device under test, and then obtains the corresponding control file based on the device model. This control file sets different detection data items for different device models. The test terminal sends the corresponding control file to the device under test so that the device under test can automatically perform detection based on the control file. In this way, the testing terminal can automatically obtain the corresponding card control file according to the type of device under test, thus enabling adaptive testing of various types of devices without manual modification of test configurations or manual classification of devices. This adaptability significantly improves the robustness of device testing and makes it suitable for various testing scenarios. Furthermore, this embodiment also sends the test results to the device under test after the test, allowing the device to change its test status code based on the results to avoid subsequent repeated testing. Simultaneously, to facilitate management personnel's understanding of the test results, the testing terminal also sends the test results to the server, enabling management personnel to remotely access the server and understand the test results in real time, greatly improving testing efficiency and reducing labor costs.

[0023] It should be noted that the device testing method, system, test terminal, and device under test proposed in this application can be applied to testing smart wearable devices, as well as other terminal devices with wireless access capabilities. No limitation is imposed in this application. The test terminal proposed in this application can be a smart terminal device such as a mobile phone or tablet, or other dedicated test terminal devices.

[0024] like Figure 1 The diagram shown illustrates the structure of the equipment testing system proposed in an embodiment of this application. Figure 1The image shows multiple devices of the same or different types to be tested, including smartwatches, smart bracelets, or other smart devices. These devices are arranged in batches, including devices that have already been tested, devices currently being tested, and devices yet to be tested. Each device has wireless connectivity, preferably Bluetooth Low Energy (BLE) functionality.

[0025] Bluetooth Low Energy (BLE) is a wireless technology designed for low-power, short-range, and low-data-volume communication. It operates in the 2.4 GHz ISM band, employing 40 channels (3 broadcast channels and 37 data channels), GFSK modulation, and a base rate of 1 Mbps (2 Mbps in BLE 5.x). It uses a dual-mode "broadcast-connection" architecture at the link layer. In broadcast mode, devices periodically send short packets (maximum 31 bytes), which the receiver can scan to retrieve data without a handshake. Furthermore, the BLE protocol itself supports a "one master, many slaves" topology; the test terminal, acting as the central device, can theoretically maintain connections with up to 8-10 devices under test simultaneously.

[0026] In this embodiment, the testing terminal connects simultaneously to multiple devices under test via BLE technology. Furthermore, the testing terminal can connect to various servers via cloud services, such as a file server, to retrieve pre-stored control files for various device types under test. This allows the testing terminal to retrieve a control file for a specific device type from the file server in real time if it does not currently have one. The file server can also record control result files for each device under test, enabling administrators to remotely access and query the server by connecting to the file server and obtaining the device testing results remotely.

[0027] The test terminal and the device under test proposed in this application embodiment consist of Figure 1 The equipment testing system described herein executes the equipment testing method proposed in the embodiments of this application, specifically, as follows: Figure 2 The diagram illustrates a device testing method proposed in an embodiment of this application. This method is applied to a test terminal and includes: Step S101: Receive a broadcast message sent by the device under test; Before testing the device under test at the test terminal, the device under test must first be powered on and Bluetooth enabled to obtain its own device model, checksum, and test status code. A broadcast message is then sent via Bluetooth, containing the aforementioned information. The broadcast message may include a 2-byte start character (e.g., "EW," used to filter Bluetooth devices), a 10-byte device model (i.e., smartwatch model), a 13-byte device serial number (i.e., unique device serial number), and a 1-byte test status character (used to identify whether the watch's test status is untested, tested, or faulty; for example, 0 indicates untested, 1 indicates the device has passed the test, and 3 indicates the device has failed the test).

[0028] The device model is typically the initial setting of the device under test at the time of manufacture. The checksum is a checksum output by the device under test using a CRC checksum algorithm based on the start character EW, device model characters, device serial number characters, detection status code characters, MAC address, and fault code, etc., for access verification. The checksum can be 2 bytes.

[0029] Figure 3 The data structure of the broadcast message is shown, including: a start symbol, device model, device serial number, and detection status symbol. After receiving a response message from the test terminal, the terminal under test also sends a broadcast response packet, which may include a MAC address, checksum, and fault code.

[0030] Step S102: Verify the device to be tested according to the verification code; The test terminal performs a CRC check on the device under test based on the checksum in the broadcast message.

[0031] Step S103: Determine whether the verification passes; The verification code sent by the device under test is verified to ensure the legitimacy of the connected Bluetooth device. If the verification passes, proceed to step S104. If the verification fails, the detection of the device under test is terminated, and the process proceeds to step S101 to continue judging other devices under test.

[0032] The verification process involves the test terminal performing CRC calculations based on the received start character EW, device model characters, device serial number characters, detection status code characters, MAC address, and fault code to generate a checksum. The generated checksum is then compared with the checksum sent in the broadcast message. If they match, the verification passes, and the test terminal successfully identifies the device under test; otherwise, the verification fails.

[0033] It should be noted that before performing CRC verification, the device under test can perform an initial screening based on a start character, where the start character "EW" represents a legitimate Bluetooth device. After the initial screening, the test terminal can perform a secondary filtering based on the signal strength indication of the device under test.

[0034] Since multiple Bluetooth signals from devices under test may exist simultaneously during testing, in order to avoid false testing of devices outside the target testing range, this application embodiment also proposes to filter the devices under test based on the distance between the device under test and the testing terminal.

[0035] The test terminal uses the Received Signal Strength Indication (RSSI) signal broadcast by BLE technology to measure the distance between itself and the device under test. If the distance value is less than a preset distance threshold, the device under test is verified according to the verification code. Bluetooth devices that exceed the preset distance are not detected.

[0036] The above method filters the device under test by using start symbols and signal strength indication signals, thus avoiding false testing of other devices.

[0037] Step S104: Determine whether the detection has been completed based on the detection status code; The detection status code is used to indicate the detection status of the device under test. For example, 0 indicates no detection, 1 indicates the device has passed the detection, and 3 indicates the device has failed the detection. When the detection status code is 1 or 3, it means that the device under test has been detected, so the process terminates and proceeds to step S101 to continue judging other devices under test; when the detection status code is 0, it means that the device under test has not been detected, so proceeds to step S105.

[0038] Step S105: Determine the list of devices to be tested that have not yet been tested; After scanning all devices to be tested within all preset distance ranges, a list of devices to be tested is created based on the selected devices. In subsequent steps, only devices in this list are tested. Simultaneously, the testing terminal can record the number of devices in the list and iterate through the list based on this number.

[0039] Step S106: Send a control file to the device under test in the list of devices to be tested according to the device model. The control file includes detection data items so that the device under test can perform automatic detection according to the detection data items. After the testing terminal completes scanning of all devices to be tested, it generates a list of devices to be tested. This list records information about all devices, including but not limited to device model and serial number. The testing terminal then sequentially tests each device in the list until all devices have been scanned.

[0040] When testing a device, the testing terminal first obtains the corresponding control file based on the device model information. This control file includes test data items. Different device models correspond to different control files. By obtaining the corresponding control file based on the device model, the test data items can be automatically matched with the device under test. This method improves the adaptability of the testing terminal to various types of devices, eliminating the need for manual configuration of the test data items.

[0041] Figure 4 The diagram illustrates the structure of a control file, which is a configuration file used in the testing process of smart wearable devices. It contains preset testing standards for various test data items. The control file EWQC-xxx.json can include various test data items, including but not limited to: device information, geomagnetic sensor control values, accelerometer control values, gyroscope control values, and model descriptions. The test data items may differ for different types of devices under test.

[0042] In some embodiments, when the card control file stored in the test terminal itself does not match the device model of the device under test, in the embodiments of this application... Figure 1 In the illustrated device testing system, the testing terminal is also connected to a file server. The file server pre-stores control files corresponding to various device models. The testing terminal can send a control file retrieval request, including device model information, to the file server, enabling the file server to retrieve the corresponding control file based on the device model information and send it to the testing terminal. Upon receiving the control file, the testing terminal sends it to the device under test to complete the testing.

[0043] This approach further enhances the adaptability of the testing terminal. Administrators only need to remotely configure the relevant card control files on the file server in advance to complete the testing of various types of devices to be tested.

[0044] Step S107: Receive the self-test data output file sent by the device under test. The self-test data output file includes the test results corresponding to the test data items. Compare the test results corresponding to the test data items with the preset test threshold to determine the automatic test result of the device under test. After receiving the control file sent by the test terminal, the device under test automatically starts the testing process, completes its own testing according to the testing data items in the control file, generates testing results, and generates a self-test data output file based on the testing results. The self-test data output file includes the testing results corresponding to the testing data items.

[0045] like Figure 5 As shown, the data items contained in the self-test data output file EWAutoCheck-xxx.json include, but are not limited to, device information, geomagnetic sensor detection values, accelerometer detection values, gyroscope detection values, and model descriptions.

[0046] After the device under test completes the test and generates a self-test data output file according to the control file, it sends the self-test data output file to the test terminal via Bluetooth connection.

[0047] After receiving the self-test data output file, the test terminal compares the test results corresponding to the test data items in the file with the pre-set test thresholds for each test data item to determine the automatic test results. If any test result exceeds the test threshold range, the device under test is considered unqualified. If the test results for all test data items meet the test threshold requirements, the device under test is considered to have passed the test.

[0048] Step S108: Generate a card control result file based on the automatic detection result, and send the card control result file to the device under test, so that the device under test can modify the detection status code according to the card control result file; The testing terminal generates a card control result file based on the automatic detection results. The card control result file records the detection results for each detection data item, such as... Figure 6 As shown, the data items contained in the card control result file EWCheckout-xxx.json are included, including but not limited to: device information, geomagnetic sensor card control result / fault code, accelerometer card control result / fault code, gyroscope card control result / fault code, and model description.

[0049] After the test terminal generates the card control result file, it sends the card control result file to the device under test. The device under test modifies its own detection status code according to the card control result file. If the detection passes, the detection status code is assigned the value 1; if the detection fails, the detection status code is assigned the value 3, so as to mark its own detection status.

[0050] Step S109: Determine whether all devices to be tested in the list of devices to be tested have been traversed; After completing the testing of one device, the testing terminal determines whether to iterate through all devices in the device list. For example, it may decrement the number of devices in the list by one. If the number is 0, it indicates that the testing of all devices has been completed, and the process ends. If the number is not 0, the testing of the next device continues, and the process jumps to step S106 until the testing of all devices is completed.

[0051] As can be seen from the above embodiments, when the testing terminal tests multiple devices under test, it first filters the connected devices by filtering out illegal devices using verification codes. Then, by detecting the detection status code carried by the device itself, it filters out devices that have already been tested, avoiding duplicate testing and improving testing efficiency. Simultaneously, when testing devices that have not yet been tested, the testing terminal obtains the corresponding card control file based on the device model and completes the testing according to the card control file. In this way, the testing terminal can automatically and adaptively test various types of devices under test without requiring manual changes to the test configuration or manual classification of the devices. It can adapt to various types of devices under test, greatly improving the robustness of device testing and adapting to various testing scenarios.

[0052] In another embodiment of this application, another device detection method is also proposed, such as... Figure 7 The diagram shows a flowchart of the device testing method, which is applied to the device to be tested. Specifically, it includes: Step S201: Obtain the detection status code and send a broadcast message so that the test terminal establishes a connection with the device under test according to the broadcast message and sends the card control file according to the detection status code; As described in the above embodiments, when the device under test is powered on, it starts the Bluetooth device and obtains the MAC address, device model, device serial number, start character, detection status code and fault code stored locally. It then performs CRC verification based on the start character, device model, device serial number, MAC address, etc., and generates a 2-byte check code.

[0053] After the device under test starts Bluetooth broadcasting, it carries the device signal, check code, and detection status code in the broadcast message, so that the test terminal can establish a connection with the device under test according to the broadcast message and filter the device under test according to the start character and check code.

[0054] Once the device under test passes the screening, the test terminal obtains the corresponding card control file according to the device model of the device under test and sends it to the device under test.

[0055] Step S202: Receive the card control file sent by the test terminal. The card control file includes detection data items. Perform automatic detection according to the card control file, generate a self-test data output file, and send the self-test data output file to the test terminal so that the test terminal can determine the automatic detection result according to the self-test data output file. After receiving the control file, the device under test automatically starts the detection process according to the detection data items in the control file, generates a self-test data output file EWAutoCheck.json, and sends it to the test terminal.

[0056] Step S203: Receive the automatic detection result sent by the test terminal, and modify its own detection status code according to the automatic detection result; Once the device under test receives the EWCheckout.json control result file from the test terminal, the test is considered complete. The test status code and fault code data are updated according to the content of the control result file, and the screen display of the terminal under test is refreshed, showing either 1 "Test passed" or 3 "Device test has fault".

[0057] As can be seen from the above, the terminal under test carries a detection status code in the broadcast message it sends. The test terminal can judge the status of the terminal under test based on the detection status code, which can effectively filter out the devices under test that have already been tested, avoid repeated testing, and greatly improve the detection efficiency.

[0058] Figure 8 The following is an interactive signaling diagram of the device detection system proposed in an embodiment of this application: Device under test: After power-on, it acquires MAC address, device model, device serial number, start character, detection status code and fault code, etc., and performs CRC check based on the start character, device model, device serial number, MAC address, etc., generates a 2-byte CRC check code, and broadcasts the above information via Bluetooth broadcast information. The broadcast signal is transmitted in character form.

[0059] Test terminal: During operation, the test terminal continuously scans for Bluetooth signals within its coverage area. Once a Bluetooth signal is detected, the relevant information of the Bluetooth device will be displayed in the Bluetooth search list of the test terminal.

[0060] Upon detecting Bluetooth broadcast information, the start character in the broadcast information is retrieved, and the device to be tested is determined based on the start character to determine whether it is a qualified Bluetooth device, thus performing an initial screening of the devices to be tested. Then, the RSSI value of the received Bluetooth broadcast information is converted into actual distance data between the test terminal and the device to be tested. If the actual distance is less than a preset distance threshold, such as 1 meter, a broadcast response message is sent to the devices to be tested in the list of devices to be tested.

[0061] The device under test: After receiving the broadcast response message, it continues to send a broadcast response packet, which contains the check code generated by the device under test; Test terminal: After receiving the broadcast response packet, it generates a CRC checksum based on the received start character, device model, device serial number, MAC address and other information, and compares the generated checksum with the checksum in the broadcast response packet. If they are equal, it is considered that the device under test has been successfully identified, and a Bluetooth connection is established between the test terminal and the device under test.

[0062] Add all the devices that pass the screening to the device test list, count the number of devices to be tested in the device test list, and start the automatic test process.

[0063] The device model of the first device to be tested is obtained from the filtered list of devices to be tested, and the card control file corresponding to the device model is checked locally on the test terminal. If it does not exist, a request to obtain the card control file is sent to the server; if it exists, the card control file is sent to the device to be tested.

[0064] Server: The server pre-stores control files corresponding to various device models. When it receives a request from the test terminal to obtain a control file, it obtains the corresponding control file according to the device model and sends the control file to the test terminal so that the test terminal can send the control file to the corresponding device to be tested.

[0065] Device under test: Automatic detection is initiated according to the control file. After the detection is completed, the device under test saves the detection results as a self-test data output file, EWAutoCheck-xxx.json, and then sends the file to the test terminal.

[0066] Test terminal: The test terminal compares the test results recorded in the self-test data output file with the detection thresholds set in the control file. If the data is within the detection threshold range, the test passes; if the data is outside the detection threshold range set in the control file, the device under test is determined to be faulty, and a control result file EWCheckout-xxx.json is generated.

[0067] The test terminal sends the card control result file to both the device under test and the server. The device under test: After receiving the card control result file, it modifies its own detection status code and fault code according to the detection result, and displays the detection result on the screen, such as: the screen displays 1 "Detection passed" or 3 "Device detection has a fault".

[0068] Server: Stores the card control results files so that administrators can view and remotely access them at any time.

[0069] Test terminal: After each device to be tested is completed, the number of devices to be tested in the list of devices to be tested is decremented by one, until the list of devices to be tested has been traversed, and the testing of the current batch of devices is completed.

[0070] In other embodiments, such as Figure 9 As shown in the embodiments of this application, a test terminal and a device under test are also proposed. The test terminal and the device under test are used to run the device testing method proposed in the above embodiments. The test terminal and the device under test may include: a processor 402, a memory 406, a communication interface 404, and a communication bus 408.

[0071] The processor 402, memory 406, and communication interface 404 communicate with each other via communication bus 408. The memory 406 stores at least one program 410, which causes the processor 402 to execute steps related to the device detection method proposed in this application embodiment.

[0072] Specifically, program 410 may include program code, which includes computer-executable instructions.

[0073] The processor 402 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. The test terminal or device under test may include one or more processors of the same type, such as one or more CPUs; or they may be processors of different types, such as one or more CPUs and one or more ASICs.

[0074] Memory 406 is used to store program 410. Memory 406 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0075] Specifically, program 410 can be called by processor 402 to cause the test terminal and the device under test to execute the above-described device detection method proposed in the embodiments of this application, which will not be repeated here.

[0076] This application also provides a computer-readable storage medium storing executable instructions. When the executable instructions are run on a test terminal and a device under test, the test terminal and the device under test perform the device testing method provided in any of the above embodiments.

[0077] This application also provides a device testing program for executing the device testing method provided in the above embodiments.

[0078] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, the embodiments of this application are not directed to any particular programming language. It should be understood that the content of this application described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of this application.

[0079] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0080] Similarly, it should be understood that, in order to simplify this application and aid in understanding one or more of the various aspects of the invention, in the above description of exemplary embodiments of this application, various features of the embodiments of this application are sometimes grouped together into a single embodiment, figure, or description thereof.

[0081] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying abstract and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying abstract and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0082] It should be noted that the above embodiments are illustrative of this application and not restrictive, and those skilled in the art can design alternative embodiments without departing from the scope. Unless otherwise specified, the steps in the above embodiments should not be construed as limiting the order of execution.

Claims

1. A method for testing equipment, characterized in that, The method is applied to a testing terminal used to test multiple devices to be tested, and the testing terminal is used to test multiple devices to be tested. Receive a broadcast message sent by the device under test, the broadcast message including the device model, check code and test status code of the device under test; The device to be tested is verified according to the verification code. If the verification is successful, a list of devices to be tested that have not been tested is determined according to the test status code. The list of devices to be tested includes the device models of the devices to be tested that have not been tested. Perform the following operations on each of the devices to be tested in the list of devices to be tested, until the list of devices to be tested has been traversed: According to the device model, a control file is sent to the device to be tested in the list of devices to be tested. The control file includes detection data items so that the device to be tested can perform automatic detection based on the detection data items. The system receives a self-test data output file sent by the device under test, the self-test data output file including the test results corresponding to the test data items, compares the test results corresponding to the test data items with a preset test threshold, and determines the automatic test result of the device under test. A control result file is generated based on the automatic detection results, and the control result file is sent to the device under test so that the device under test can modify the detection status code according to the control result file.

2. The method according to claim 1, characterized in that, The broadcast message also includes a start character; Before verifying the device under test according to the check code, the process further includes: The devices to be tested are screened based on the start symbol; Obtain the signal strength indication of the device under test that has passed the screening, obtain the distance value between the device under test and the test terminal based on the signal strength indication, and if the distance value is less than a preset distance threshold, verify the device under test based on the check code.

3. The method according to claim 1, characterized in that, The test terminal is also connected to the server. The step of sending the control file to the devices in the list of devices to be tested according to the device model includes: If the device model is determined to be a card control file corresponding to the device model, and if it is not found locally, a card control file retrieval request is sent to the server so that the server returns the card control file corresponding to the device model.

4. The method according to claim 3, characterized in that, The method further includes: The card control result file is sent to the server.

5. A method for testing equipment, characterized in that, Applied to a device under test, the device under test being used to connect to a test terminal as described in any one of claims 1-4, the method comprising: The test terminal acquires the detection status code and sends a broadcast message to enable the test terminal to establish a connection with the device under test according to the broadcast message and send the card control file according to the detection status code. The system receives a card control file sent by the test terminal, the card control file includes detection data items, and performs automatic detection according to the card control file to generate a self-test data output file. The system then sends the self-test data output file to the test terminal so that the test terminal can generate a card control result file based on the self-test data output file. The system receives the card control result file sent by the test terminal and modifies its own detection status code according to the card control result file.

6. The method according to claim 5, characterized in that, Before sending the broadcast message, the following further includes: Obtain its own MAC address, device model, device serial number, and start character; A CRC checksum is generated based on the MAC address, device model, device serial number, and start character. The verification code is broadcast via the broadcast message.

7. A test terminal, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one program that causes the processor to execute the device detection method as described in any one of claims 1-4.

8. A testing device, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one program that causes the processor to execute the device detection method as described in claim 5 or 6.

9. A device testing system, characterized in that, Includes the test terminal as described in claim 7, multiple devices to be tested as described in claim 8, and a server; The test terminal connects to multiple devices under test via Bluetooth Low Energy and is used to test the multiple devices under test. The server is communicatively connected to the test terminal and is used to send card control files to the test terminal and store the card control result files sent by the test terminal.

10. A readable computer storage medium, characterized in that, The storage medium stores at least one program, which, when run on a test terminal, causes the test terminal to perform the device testing method as described in any one of claims 1-4; or, when run on a device to be tested, causes the device to perform the device testing method as described in claim 5 or 6.

Images