Equipment testing method and device, electronic equipment and computer program product
By directly burning and publishing software in the equipment and loading the dynamic link library to complete the test, the problem of low production efficiency of the equipment is solved and efficient production of the equipment is achieved directly out of the factory.
Patent Information
- Application Number
- CN202510462492.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-11
- Publication Date
- 2025-08-26
AI Technical Summary
In the prior art, the equipment production efficiency is low, and it is necessary to upgrade the production testing software to release software and then verify it after hardware function testing, resulting in low production efficiency.
The software is directly burned and published in the equipment to be tested, and the dynamic link library is loaded through the release software to complete the test. The test items for the equipment are encapsulated and the factory will be shipped directly after passing the test.
By integrating production testing functions and publishing software, the software upgrade verification steps are omitted, and the equipment production efficiency is improved.
Smart Images
Figure CN120540971A_ABST
Abstract
Description
Technical Field
[0001] The present application belongs to the field of equipment testing technology, and in particular relates to an equipment testing method, apparatus, electronic equipment, and computer program product. Background Art
[0002] During the device manufacturing process, production test software is typically burned into the device. This software is then used to test the functionality of the device's hardware to ensure proper functioning before shipment. However, because the software burned into the device at the factory must be release software, after hardware functional testing, the production test software must be upgraded to release software for further verification before the device can be shipped. This demonstrates the low efficiency of current device production. Summary of the Invention
[0003] In view of this, the embodiments of the present application provide a device testing method, apparatus, electronic device and computer program product to solve the technical problem of low equipment production efficiency in the prior art.
[0004] In a first aspect, an embodiment of the present application provides a device testing method, which is applied to a device to be tested, wherein the device to be tested has release software burned into it and is in communication connection with a target device, the method comprising:
[0005] After the device to be tested is powered on, the release software is loaded;
[0006] detecting whether a test instruction sent by the target device is received;
[0007] If the test instruction is received, the pre-stored dynamic link library is loaded and run through the release software to complete the test of the device to be tested, where the dynamic link library encapsulates at least one test item for the device to be tested.
[0008] Optionally, after detecting whether a test instruction sent by the target device is received, the method further includes:
[0009] If the test instruction is not received, the publishing software is started.
[0010] Optionally, the detecting whether a test instruction sent by the target device is received includes:
[0011] Detecting whether at least one target interface receives a predefined data packet sent by the target device within a preset time.
[0012] Optionally, the predefined data packet includes predefined target identification data.
[0013] Optionally, the step of loading and running a pre-stored dynamic link library by publishing software to complete the test of the device to be tested includes:
[0014] Execute each of the test items, obtain working status data of the target hardware corresponding to each of the test items, and determine and store the test result corresponding to the test item based on the working status data.
[0015] Optionally, after the pre-stored dynamic link library is loaded and executed by the release software to complete the test of the device to be tested, the method further includes:
[0016] Determining whether at least one of the test results meets a preset condition;
[0017] If the preset conditions are met, it is determined that the device to be tested is qualified;
[0018] If the preset condition is not met, it is determined that the device to be tested has failed the test.
[0019] Optionally, the preset conditions include:
[0020] The number of the test results is the same as the number of preset test items, and each of the test results indicates a pass.
[0021] In a second aspect, an embodiment of the present application provides a device testing apparatus, which is applied to a device to be tested, wherein the device to be tested has release software burned into it and is in communication connection with a target device, and the apparatus comprises:
[0022] A software loading unit, configured to load the release software after the device to be tested is powered on;
[0023] a detection unit, configured to detect whether a test instruction sent by the target device is received;
[0024] The testing unit is configured to load and run a pre-stored dynamic link library through the release software upon receiving the test instruction to complete the test of the device to be tested, wherein the dynamic link library encapsulates at least one test item for the device to be tested.
[0025] In a third aspect, an embodiment of the present application provides an electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the processor implements the steps of the device testing method as described in any one of the first aspects above.
[0026] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the device testing method as described in any one of the first aspects above.
[0027] In a fifth aspect, an embodiment of the present application provides a computer program product. When the computer program product is run on a terminal device, the terminal device executes each step of the device testing method as described in any one of the first aspects above.
[0028] The device testing method, apparatus, electronic device, and computer program product provided by the embodiments of the present application have the following beneficial effects:
[0029] In the embodiments of this application, the release software is directly burned into the device under test, and the dynamic link library is directly loaded through the release software to complete the test of the device under test. This integrates the production test function with the release software, so that the device under test can be shipped directly after the test is completed. Compared with the existing methods, the step of upgrading the production test software to the release software and verifying it after passing the test is omitted, thereby improving equipment production efficiency. BRIEF DESCRIPTION OF THE DRAWINGS
[0030] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.
[0031] Figure 1 A flowchart for implementing the device testing method provided in an embodiment of the present application;
[0032] Figure 2 A schematic diagram of the structure of a device testing apparatus provided in an embodiment of the present application;
[0033] Figure 3 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0034] It should be noted that the terms used in the embodiments of the present application are only used to explain the specific embodiments of the present application and are not intended to limit the present application. In the description of the embodiments of the present application, unless otherwise specified, "multiple" refers to two or more than two, and "at least one" and "one or more" refer to one, two or more. The terms "first" and "second" are used for descriptive purposes only and cannot be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, the definition of "first" and "second" features can explicitly or implicitly include one or more of the features.
[0035] References to "one embodiment" or "some embodiments" in this specification mean that a particular feature, structure, or characteristic described in conjunction with that embodiment is included in one or more embodiments of the present application. Thus, phrases such as "in one embodiment," "in some embodiments," "in other embodiments," and "in yet other embodiments" appearing in various places in this specification do not necessarily refer to the same embodiment, but rather mean "one or more but not all embodiments," unless otherwise specifically emphasized. The terms "including," "comprising," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.
[0036] The execution subject of the device testing method provided in the embodiment of the present application can be a device to be tested, wherein the device to be tested can be any electronic device. For example, the electronic device can include but is not limited to a mobile phone, a tablet computer, a laptop computer, and a desktop computer.
[0037] When producing equipment, users can use the equipment to be tested to perform the various steps of the equipment testing method provided in the embodiments of the present application, thereby improving equipment production efficiency.
[0038] See also Figure 1 , Figure 1 This is a flowchart for implementing a device testing method provided in an embodiment of the present application. The device testing method can be applied to a device to be tested, wherein the device to be tested has release software burned into it and can communicate with a target device. The device testing method may include steps S101 to S103, as detailed below:
[0039] Step S101: After the device to be tested is powered on, the release software is loaded.
[0040] In this embodiment of the present application, the release software is the official software with complete functionality, and is the software version used by users after the device leaves the factory. In this embodiment of the present application, the user directly pre-burns the release software into the device under test before testing the device. After the device under test is powered on, the device under test can load the release software.
[0041] In actual applications, after the device under test is powered on, the device under test may perform device initialization steps. Exemplarily, the device initialization steps may include but are not limited to device hardware detection steps, device memory initialization steps, and peripheral device configuration steps.
[0042] After the device under test completes the device initialization steps, the device's main control unit (such as an MCU or embedded processor) loads the core program of the release software from memory and starts the device's basic functions. The basic functions of the device under test may include data acquisition and perception, communication and connection functions, and data processing functions.
[0043] Step S102: Detect whether a test instruction sent by the target device is received.
[0044] For example, the target device may include but is not limited to a mobile phone, a tablet computer, a laptop computer, and a desktop computer.
[0045] In a possible implementation, the device under test may include several different types of target interfaces. Based on this, the device under test may detect whether it has received a test instruction sent by the target device in the following manner:
[0046] It is detected whether at least one target interface receives a predefined data packet sent by the target device within a preset time.
[0047] Specifically, the device under test can detect for each target interface whether the target interface receives a predefined data packet sent by the target device and corresponding to the target interface within a preset time. Different target interfaces can correspond to different predefined data packets.
[0048] The starting point of the preset time may be the time when the device to be tested is powered on. The preset time may be 3 seconds, but this application does not limit this.
[0049] Afterwards, if any target interface receives a predefined data packet sent by the target device and corresponding to the target interface within the preset time, the device to be tested can determine that it has received the test instruction sent by the target device; if each target interface does not receive a predefined data packet sent by the target device and corresponding to the target interface within the preset time, the device to be tested can determine that it has not received the test instruction sent by the target device.
[0050] Exemplarily, the target interface of the device under test refers to a hardware interface, which may include, but is not limited to, a Universal Serial Bus (USB) interface, an RS-232 interface, and a CAN bus. The communication protocol between each target interface and the target device is pre-defined to ensure that the device under test can reliably receive the necessary signals from the target interface. The predefined data packets corresponding to the USB interface may be specific byte data, and the predefined data packets corresponding to the RS-232 interface may be specific data frames.
[0051] If it is detected that specific byte data sent by the target device is received through the USB interface, or if it is detected that a specific data frame sent by the target device is received through the RS232 interface, the device to be tested can determine that a predefined data packet sent by the target device is received, and further can determine that a test instruction sent by the target device is received.
[0052] Receiving test instructions through different target interfaces can ensure that the device under test can reliably receive the test instructions from the target device, avoiding the situation where the device under test cannot receive the test instructions due to a certain interface failure, and improving the reliability of the test.
[0053] In another possible implementation, the predefined data packet sent by the target device may include predefined target identification data, and the device to be tested determines whether a test instruction is received and whether to enter the test mode by identifying the target identification data. Exemplarily, the predefined target identification data can be 0x1234. When the data packet received by the device to be tested includes the identifier 0x1234, it indicates that the production test mode can be entered. If the received identifier is 0x5678, it indicates the formal function mode, then the test step is skipped directly and the release software is started directly. This shows that when the device leaves the factory and arrives in the hands of the user, it basically will not receive the predefined data packet sent by the target device (host computer, which can be a computer, etc.). Therefore, each time the device is started, the release software is started to enter the formal function mode, which is convenient for the user to use.
[0054] Step S103: If a test instruction is received, the pre-stored dynamic link library is loaded and run by the release software to complete the test of the device to be tested, where the dynamic link library encapsulates at least one test item for the device to be tested.
[0055] In the embodiments of the present application, a dynamic link library (DLL or .so file) encapsulates multiple hardware function test items. Each test item is encapsulated as an independent function or class responsible for verifying the validity of a specific hardware function. The dynamic link library is loaded by the operating system or underlying firmware, and is loaded through an interface call.
[0056] Exemplarily, when loading and running a pre-stored dynamic link library, the device under test can execute each test item, obtain working status data of the target hardware corresponding to each test item, and determine and store the test result corresponding to the test item based on the working status data.
[0057] Exemplarily, each test item corresponds to a functional module of a specific device hardware and verifies the actual operating status of the device hardware. In the embodiment of the present application, all test items encapsulated by the dynamic link library may include but are not limited to testing of communication interfaces, sensors, and power modules.
[0058] Exemplarily, the test of the communication interface may include testing the functionality, stability and data transmission rate of the interface (such as RS232, USB interface), and therefore, the working status data of the communication interface includes data on functionality, stability and data transmission rate.
[0059] Exemplarily, the test performed on the sensor may include testing the response time, accuracy, and stability of each sensor. Therefore, the working status data of the sensor includes data on the response time, accuracy, and stability.
[0060] Exemplarily, the test on the power management module may include testing of battery charging, working status and load capacity of the power management module. Based on this, the working status data of the power management module includes data indicating load capacity and the like.
[0061] As each test item executes, the device controller reads the operating status of the corresponding hardware, performs functional verification, and reports the test result (success or failure) to the main control unit via a callback function. After the test is complete, the result is stored in the device using a flag bit as proof of test compliance. This flag bit is typically recorded as a binary flag, with success set to 1 and failure set to 0. The flag bit can be stored in non-volatile memory and is used to ensure that all test items have been executed.
[0062] When the test is completed, the device will determine whether the device has passed the test by checking the mark bit. Among them, only when the number of mark bits is the same as the number of test items and all indicate success, the device will notify that the test is passed, otherwise the test fails. The embodiment of the present application can avoid the omission of test items, thereby improving the test reliability of the software to be tested. After determining that the device to be tested has passed the test, the user can perform the factory steps for the device to be tested. After determining that the device to be tested has failed the test, the device can re-execute the corresponding test item based on the missing or failed record of the mark bit. If there is still a missing or failed item after the test, the user can carry out targeted maintenance.
[0063] In the embodiments of this application, the release software is directly burned into the device under test, and the dynamic link library is directly loaded through the release software to complete the test of the device under test. This integrates the production test function with the release software, so that the device under test can be shipped directly after the test is completed. Compared with the existing methods, the step of upgrading the production test software to the release software and verifying it after passing the test is omitted, thereby improving equipment production efficiency.
[0064] Based on the device testing method provided in the above embodiment, the present application further provides a device testing apparatus for implementing the above method embodiment. The device testing apparatus can be applied to the device to be tested, wherein the device to be tested is burned with the release software and is in communication connection with the target device. Figure 2 , Figure 2 This is a schematic diagram of the structure of a device testing device provided in an embodiment of the present application. Figure 2 As shown, the device testing apparatus 20 may include a software loading unit 21, a detection unit 22, and a testing unit 23.
[0065] The software loading unit 21 is used to load the release software after the device to be tested is powered on.
[0066] The detection unit 22 is used to detect whether a test instruction sent by the target device is received.
[0067] The testing unit 23 is configured to load and run a pre-stored dynamic link library by publishing software upon receiving a test instruction to complete the test of the device to be tested. The dynamic link library encapsulates at least one test item for the device to be tested.
[0068] Optionally, the device testing apparatus 20 may further include a software startup unit.
[0069] The software starting unit is used to start the release software if no test instruction is received.
[0070] Optionally, the detection unit 22 is specifically configured to:
[0071] It is detected whether at least one target interface receives a predefined data packet sent by the target device within a preset time.
[0072] Optionally, the predefined data packet includes predefined target identification data.
[0073] Optionally, the testing unit 23 is specifically configured to:
[0074] Execute each test item, obtain the working status data of the target hardware corresponding to each test item, and determine and store the test result corresponding to the test item based on the working status data.
[0075] Optionally, the device testing apparatus 20 may further include a test result determination unit.
[0076] The test result determination unit is specifically used for:
[0077] Determining whether at least one test result meets a preset condition;
[0078] If the preset conditions are met, it is determined that the device to be tested is qualified;
[0079] If the preset conditions are not met, it is determined that the device under test has failed the test.
[0080] Optional, pre-conditions include:
[0081] The number of test results is the same as the number of preset test items, and each test result indicates a pass.
[0082] It should be noted that the information interaction, execution process and other contents between the above-mentioned units are based on the same concept as the method embodiment of this application. Their specific functions and technical effects can be found in the method embodiment part and will not be repeated here.
[0083] See also Figure 3 , Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Figure 3 As shown, the electronic device 3 provided in this embodiment may include: a processor 30, a memory 31, and a computer program 32 stored in the memory 31 and executable on the processor 30. For example, a program corresponding to the device testing method. When the processor 30 executes the computer program 32, the steps in the device testing method embodiment are implemented. For example, Figure 1 Alternatively, when the processor 30 executes the computer program 32, the functions of the modules / units in the embodiment corresponding to the above-mentioned device testing apparatus are realized, for example Figure 2 The functions of the units 21 to 23 are shown.
[0084] For example, the computer program 32 can be divided into one or more modules / units, one or more modules / units are stored in the memory 31 and executed by the processor 30 to complete the present application. One or more modules / units can be a series of computer program instruction segments that can complete specific functions. The instruction segments are used to describe the execution process of the computer program 32 in the electronic device 3. For example, the computer program 32 can be divided into a software loading unit 21, a detection unit 22, and a test unit 23. The specific functions of each unit can be seen in FIG. Figure 2 The relevant descriptions in the corresponding embodiments are not repeated here.
[0085] Those skilled in the art will understand that Figure 3 This is merely an example of the electronic device 3 and does not constitute a limitation on the electronic device 3 . The electronic device 3 may include more or fewer components than shown in the figure, or may combine certain components, or may include different components.
[0086] The processor 30 may be a central processing unit (CPU), or other general-purpose processors, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.
[0087] The memory 31 can be an internal storage unit of the electronic device 3, such as a hard drive or memory of the electronic device 3. The memory 31 can also be an external storage device of the electronic device 3, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, or flash card equipped on the electronic device 3. Furthermore, the memory 31 can include both an internal storage unit of the electronic device 3 and an external storage device. The memory 31 is used to store computer programs and other programs and data required by the electronic device. The memory 31 can also be used to temporarily store data that has been output or is about to be output.
[0088] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units as needed, that is, the internal structure of the equipment testing device can be divided into different functional units to complete all or part of the functions described above. The functional units in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.
[0089] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments can be implemented.
[0090] An embodiment of the present application provides a computer program product. When the computer program product is run on a terminal device, the terminal device implements the steps in the above-mentioned various method embodiments.
[0091] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.
[0092] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0093] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.
Claims
1. A device testing method, characterized in that: Applied to a device to be tested, the device to be tested has release software burned into it and is in communication connection with a target device, the method includes: After the device to be tested is powered on, the release software is loaded; detecting whether a test instruction sent by the target device is received; If the test instruction is received, the pre-stored dynamic link library is loaded and run through the release software to complete the test of the device to be tested, where the dynamic link library encapsulates at least one test item for the device to be tested.
2. The method according to claim 1, characterized in that After detecting whether a test instruction sent by the target device is received, the method further includes: If the test instruction is not received, the publishing software is started.
3. The method according to claim 1, characterized in that The detecting whether the test instruction sent by the target device is received includes: Detecting whether at least one target interface receives a predefined data packet sent by the target device within a preset time.
4. The method according to claim 3, characterized in that The predefined data packet includes predefined target identification data.
5. The method according to claim 1, wherein The method of loading and running the pre-stored dynamic link library by publishing software to complete the test of the device to be tested includes: Execute each of the test items, obtain working status data of the target hardware corresponding to each of the test items, and determine and store the test result corresponding to the test item based on the working status data.
6. The method according to claim 5, characterized in that After the pre-stored dynamic link library is loaded and run by the release software to complete the test of the device to be tested, the method further includes: Determining whether at least one of the test results meets a preset condition; If the preset conditions are met, it is determined that the device to be tested is qualified; If the preset condition is not met, it is determined that the device to be tested has failed the test.
7. The method according to claim 6, characterized in that The preset conditions include: The number of the test results is the same as the number of preset test items, and each of the test results indicates a pass.
8. A device testing apparatus, characterized in that: Applied to a device under test, the device under test has release software burned into it and is in communication connection with a target device, the device comprises: A software loading unit, configured to load the release software after the device to be tested is powered on; a detection unit, configured to detect whether a test instruction sent by the target device is received; The testing unit is configured to load and run a pre-stored dynamic link library through the release software upon receiving the test instruction to complete the test of the device to be tested, wherein the dynamic link library encapsulates at least one test item for the device to be tested.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, each step of the device testing method according to any one of claims 1 to 7 is implemented.
10. A computer program product, characterized in that When the computer program product is executed by a processor, each step of the device testing method according to any one of claims 1 to 7 is implemented.