CN112783708A - DTU hardware testing method, terminal and computer readable storage medium - Google Patents
DTU hardware testing method, terminal and computer readable storage medium Download PDFInfo
- Publication number
- CN112783708A CN112783708A CN202110122287.5A CN202110122287A CN112783708A CN 112783708 A CN112783708 A CN 112783708A CN 202110122287 A CN202110122287 A CN 202110122287A CN 112783708 A CN112783708 A CN 112783708A
- Authority
- CN
- China
- Prior art keywords
- dtu
- hardware
- test
- tested
- firmware
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000012360 testing method Methods 0.000 title claims abstract description 362
- 230000009471 action Effects 0.000 claims abstract description 15
- 238000000034 method Methods 0.000 claims description 26
- 238000007639 printing Methods 0.000 claims description 19
- 230000000007 visual effect Effects 0.000 claims description 10
- 238000010998 test method Methods 0.000 claims description 4
- 238000004519 manufacturing process Methods 0.000 abstract description 9
- RVCKCEDKBVEEHL-UHFFFAOYSA-N 2,3,4,5,6-pentachlorobenzyl alcohol Chemical compound OCC1=C(Cl)C(Cl)=C(Cl)C(Cl)=C1Cl RVCKCEDKBVEEHL-UHFFFAOYSA-N 0.000 description 55
- 238000004891 communication Methods 0.000 description 20
- 238000010586 diagram Methods 0.000 description 10
- 238000004590 computer program Methods 0.000 description 7
- 230000008569 process Effects 0.000 description 7
- 230000006870 function Effects 0.000 description 6
- 238000012986 modification Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 238000012545 processing Methods 0.000 description 5
- 238000006243 chemical reaction Methods 0.000 description 3
- 238000012800 visualization Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 2
- 238000013522 software testing Methods 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 230000004075 alteration Effects 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000007405 data analysis Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/2205—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested
- G06F11/2221—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested to test input/output devices or peripheral units
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/2273—Test methods
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Software Systems (AREA)
- Debugging And Monitoring (AREA)
Abstract
The application discloses a DTU hardware testing method, a terminal and a computer readable storage medium, wherein the DTU hardware testing method comprises the following steps: when the DTU hardware to be tested is identified on the test tool, obtaining test firmware, and burning the test firmware to the DTU hardware to be tested; after the burning is successful, sending a test instruction to the DTU hardware to be tested, and selecting different test tasks according to the test instruction so that the DTU hardware to be tested executes corresponding test actions based on the test tasks; and after the test is finished, acquiring the target firmware and the set credential information, and writing the target firmware and the set credential information into the DTU hardware to be tested. By the tracking test of the DTU hardware production link, the problem that the quality of the DTU hardware is easy to appear when the DTU hardware is manually tested is solved, so that the efficiency of DTU hardware test is improved, and the quality of the DTU hardware test is ensured.
Description
Technical Field
The present application relates to the field of device testing technologies, and in particular, to a DTU hardware testing method, a terminal, and a computer-readable storage medium.
Background
The DTU is a data acquisition and transmission unit of a scene, and generally comprises a communication module, a communication interface, I \ O input and output, analog acquisition and other interfaces; in the current DTU production process, a plurality of complicated links are often needed for testing the DTU, the technical level of factory workers is not uniform, the DTU hardware is often easy to have defects and the like, and when a batch of equipment flows into the market, the enterprises are often seriously influenced. Among them, the detection in the production process of the DTU becomes the heart of many DTU manufacturers, and how to detect the DTU quickly and accurately becomes the problem to be solved urgently.
Disclosure of Invention
The embodiment of the application aims to solve the problem that the quality of DTU hardware is easy to occur when the DTU hardware is manually tested by providing a DTU hardware testing method, a terminal and a computer readable storage medium.
In order to achieve the above object, an aspect of the present application provides a DTU hardware testing method, where the DTU hardware testing method includes the following steps:
when the DTU hardware to be tested is identified on the test tool, obtaining test firmware, and burning the test firmware to the DTU hardware to be tested;
after the burning is successful, sending a test instruction to the DTU hardware to be tested, and selecting different test tasks according to the test instruction so that the DTU hardware to be tested executes corresponding test actions based on the test tasks;
and after the test is finished, acquiring target firmware and set credential information, and writing the target firmware and the set credential information into the DTU hardware to be tested.
Optionally, the obtaining the test firmware, and burning the test firmware to the DTU hardware to be tested includes:
acquiring the equipment information of the DTU hardware to be tested, and selecting corresponding test firmware according to the equipment information of the DTU hardware to be tested;
and calling a program burning interface to burn the test firmware to the DTU hardware to be tested.
Optionally, after the step of sending a test instruction to the DTU hardware to be tested and selecting different test tasks according to the test instruction, the method includes:
obtaining a test result;
and displaying the test result through a visual page, and sending the test result to a cloud server.
Optionally, before the step of selecting the corresponding test firmware according to the device information of the DTU hardware to be tested, the method includes:
sending a downloading request to a cloud server according to the equipment information of the DTU hardware to be tested;
and downloading the test firmware from the cloud server according to the downloading request.
Optionally, after the step of displaying the test result through a visualization page and sending the test result to a cloud server, the method includes:
selecting control types and control numbers according to test items corresponding to the equipment information of the DTU hardware to be tested;
and dynamically adjusting the test interface according to the control type and the control number.
Optionally, the obtaining a test firmware when the DTU hardware to be tested is identified on the test fixture, and before the step of burning the test firmware to the DTU hardware to be tested, the method includes:
identifying a hardware code of the DTU hardware on the test tool through identification equipment to determine whether the DTU hardware is the DTU hardware to be tested, wherein the hardware code is pasted on the DTU hardware in advance;
and if the DTU hardware is to-be-tested DTU hardware, executing the step of burning the test firmware to the to-be-tested DTU hardware.
Optionally, after the step of identifying, by an identification device, the hardware code of the DTU hardware on the test fixture, the method further includes:
and acquiring a picture of the DTU hardware to be tested, and storing the picture to a cloud server and a local terminal.
Optionally, after the step of obtaining the target firmware and the set credential information after the test is completed, and writing the target firmware and the set credential information into the DTU hardware to be tested, the method includes:
setting label information corresponding to the DTU hardware to be tested;
and sending a printing instruction to a printing device so as to enable the printing device to print the label information according to the printing instruction.
In addition, in order to achieve the above object, another aspect of the present application further provides a terminal, where the terminal includes a memory, a processor, and a DTU hardware test program stored in the memory and running on the processor, and the processor implements the steps of the DTU hardware test method when executing the DTU hardware test program.
In addition, to achieve the above object, another aspect of the present application further provides a computer readable storage medium, where a DTU hardware testing program is stored, and when the DTU hardware testing program is executed by a processor, the DTU hardware testing program implements the steps of the DTU hardware testing method as described above.
In this embodiment, when the DTU hardware to be tested is identified on the test fixture, the test firmware is obtained and burned into the DTU hardware to be tested; after the burning is successful, sending a test instruction to the DTU hardware to be tested, and selecting different test tasks according to the test instruction so that the DTU hardware to be tested executes corresponding test actions based on the test tasks; and after the test is finished, acquiring the target firmware and the set credential information, and writing the target firmware and the set credential information into the DTU hardware to be tested. By the tracking test of the DTU hardware production link, the problem that the quality of the DTU hardware is easy to appear when the DTU hardware is manually tested is solved, so that the efficiency of DTU hardware test is improved, and the quality of the DTU hardware test is ensured.
Drawings
Fig. 1 is a schematic terminal structure diagram of a hardware operating environment according to an embodiment of the present application;
FIG. 2 is a schematic flowchart of a DTU hardware testing method according to a first embodiment of the present application;
FIG. 3 is a flowchart illustrating a DTU hardware testing method according to a second embodiment of the present application;
FIG. 4 is a flowchart illustrating a DTU hardware testing method according to a third embodiment of the present application;
fig. 5 is a schematic flowchart of a step before a step of selecting corresponding test firmware according to the device information of the DTU hardware to be tested in the DTU hardware testing method of the present application;
fig. 6 is a schematic flow chart illustrating a step of obtaining a target firmware and set credential information after a test is completed in the DTU hardware testing method of the present application, and writing the target firmware and the set credential information into the DTU hardware to be tested;
fig. 7 is a schematic flow chart illustrating the steps of displaying the test result through a visual page and sending the test result to a cloud server in the DTU hardware testing method of the present application.
The implementation, functional features and advantages of the objectives of the present application will be further explained with reference to the accompanying drawings.
Detailed Description
It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.
The main solution of the embodiment of the application is as follows: when the DTU hardware to be tested is identified on the test tool, obtaining test firmware, and burning the test firmware to the DTU hardware to be tested; after the burning is successful, sending a test instruction to the DTU hardware to be tested, and selecting different test tasks according to the test instruction so that the DTU hardware to be tested executes corresponding test actions based on the test tasks; and after the test is finished, acquiring target firmware and set credential information, and writing the target firmware and the set credential information into the DTU hardware to be tested.
In the current DTU production process, a plurality of complicated links are often needed for testing the DTU, the technical level of factory workers is not uniform, and the quality problem of DTU hardware is easy to occur. When the DTU hardware to be tested is identified on the test tool, the test firmware is obtained and is burnt to the DTU hardware to be tested; after the burning is successful, sending a test instruction to the DTU hardware to be tested, and selecting different test tasks according to the test instruction so that the DTU hardware to be tested executes corresponding test actions based on the test tasks; and after the test is finished, acquiring the target firmware and the set credential information, and writing the target firmware and the set credential information into the DTU hardware to be tested. By the tracking test of the DTU hardware production link, the problem that the quality of the DTU hardware is easy to appear when the DTU hardware is manually tested is solved, so that the efficiency of DTU hardware test is improved, and the quality of the DTU hardware test is ensured.
As shown in fig. 1, fig. 1 is a schematic terminal structure diagram of a hardware operating environment according to an embodiment of the present application.
As shown in fig. 1, the terminal may include: a processor 1001, such as a CPU, a network interface 1004, a user interface 1003, a memory 1005, a communication bus 1002. Wherein a communication bus 1002 is used to enable connective communication between these components. The user interface 1003 may include a Display screen (Display), an input unit such as a Keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface, a wireless interface. The network interface 1004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface). The memory 1005 may be a high-speed RAM memory or a non-volatile memory (e.g., a magnetic disk memory). The memory 1005 may alternatively be a storage device separate from the processor 1001.
Optionally, the terminal may further include a camera, a Radio Frequency (RF) circuit, a sensor, a remote controller, an audio circuit, a WiFi module, a detector, and the like. Of course, the terminal may also be configured with other sensors such as a gyroscope, a barometer, a hygrometer and a temperature sensor, which are not described herein again.
Those skilled in the art will appreciate that the terminal structure shown in fig. 1 does not constitute a limitation of the terminal device and may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components.
As shown in fig. 1, a memory 1005, which is a kind of computer-readable storage medium, may include therein an operating system, a network communication module, a user interface module, and a DTU hardware test program.
In the terminal shown in fig. 1, the network interface 1004 is mainly used for connecting to a backend server and performing data communication with the backend server; the user interface 1003 is mainly used for connecting a client (user side) and performing data communication with the client; and the processor 1001 may be configured to call the DTU hardware test program in the memory 1005 and perform the following operations:
when the DTU hardware to be tested is identified on the test tool, obtaining test firmware, and burning the test firmware to the DTU hardware to be tested;
after the burning is successful, sending a test instruction to the DTU hardware to be tested, and selecting different test tasks according to the test instruction so that the DTU hardware to be tested executes corresponding test actions based on the test tasks;
and after the test is finished, acquiring target firmware and set credential information, and writing the target firmware and the set credential information into the DTU hardware to be tested.
Referring to fig. 2, fig. 2 is a schematic flowchart of a DTU hardware testing method according to a first embodiment of the present application.
While the embodiments of the present application provide an embodiment of a DTU hardware testing method, it should be noted that, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in an order different from that shown or described here.
The DTU hardware testing method comprises the following steps:
step S10, when the DTU hardware to be tested is identified on the test fixture, obtaining test firmware, and burning the test firmware to the DTU hardware to be tested;
in this embodiment, the DTU (data Transfer unit) is a wireless terminal device specifically configured to convert serial data into IP data or convert IP data into serial data and transmit the serial data through a wireless communication network, and the DTU hardware is a PCBA, where the PCBA is called a circuit board.
The test Firmware (Firmware) is a program written in flash memory chips such as an EROM (erasable read only memory) or an EEPROM (electrically erasable programmable read only memory), and through the test Firmware, the DTU PCBA to be tested can realize a specific test action according to a standard program, and a result after the test Firmware is finished is a test result. The test firmware may specifically include, but is not limited to, one or a combination of read/write test firmware, speed test firmware, chip test firmware, hardware test firmware, and the like.
Before testing the DTU PCBA, the to-be-tested DTU PCBA needs to be installed on a testing tool, and the testing tool is a device used for checking whether the DTU PCBA achieves the expected index, wherein the to-be-tested DTU PCBA has various interfaces including but not limited to a communication interface, an I/O input/output interface, an analog quantity interface, a program programming interface and the like. The DTU PCBA to be tested is communicatively connected to the test terminal through a communication interface and using a communication conversion module, where the communication conversion module is used to convert a received signal, for example: the test terminal receives the data frame transmitted by the USB bus, the USB communication is converted into corresponding host communication (test terminal) by the communication conversion module, then the data is sent to the test terminal, the data returned from the test terminal is converted into a USB signal and returned to the DTU PCBA to be tested, wherein the test terminal comprises a test panel, a test mobile phone, a test computer and other intelligent terminals. In addition, a program programming interface in the DTU PCBA to be tested is in communication connection with the test terminal through a programming tool.
When the testing terminal identifies the DTU PCBA to be tested on the testing tool, the device information of the DTU PCBA to be tested, such as the device model, the device type, the device name, the version number and the like, is acquired, the testing content is determined according to the device information of the DTU PCBA to be tested, corresponding testing firmware is selected based on the testing content, such as read-write testing firmware, chip testing firmware, hardware testing firmware and the like, and then the testing terminal calls a program burning interface to burn the testing firmware to the DTU PCBA to be tested. In an embodiment, taking a Jlink burning tool as an example, the Jlink burning tool is connected between a USB of a test terminal and a program burning interface of a DTU PCBA to be tested, when burning is performed, configuration information such as a corresponding port and a model of a Jlink chip needs to be set, after setting is completed, a test firmware to be burned, such as a Jlink-v8.bin file, is selected, and the test firmware can be burned by clicking and sending.
Further, before the test of the PCBA of the DTU, the environment of the test fixture needs to be debugged, for example, a simulation response is performed according to an interface of the DTU, such as an interface of 4-20mA, when the test is performed, a current input of 10mA is given, and whether the current is 10mA is determined through the test to determine whether the hardware is normal; and similarly, given a voltage input, whether the hardware is normal or not is determined by testing the reading of firmware. In the subsequent test, the automatic test can be completed only by placing the DTU PCBA to be tested on the test tool, and in the test process, the test operation is automatically performed in the software without manual participation.
Referring to fig. 5, before the step of selecting the corresponding test firmware according to the device information of the DTU hardware to be tested, the method includes:
step S11, sending a downloading request to a cloud server according to the device information of the DTU hardware to be tested;
and step S12, downloading the test firmware from the cloud server according to the downloading request.
The method comprises the steps that configuration information, test firmware and the like corresponding to different types of DTU PCBAs are stored in a cloud server, meanwhile, the test firmware has multiple versions, and the latest version is stored in the cloud server, so that a test terminal needs to send a download request to the cloud server before burning of the test firmware, wherein the download request comprises device information of the DTU PCBAs to be tested; after receiving the downloading request, the cloud server searches for the latest version of test firmware matched with the equipment information, sends the latest version of test firmware to the test terminal, and then burns the latest version of test firmware by the test terminal.
Step S20, after the burning is successful, sending a test instruction to the DTU hardware to be tested, and selecting different test tasks according to the test instruction so that the DTU hardware to be tested executes corresponding test actions based on the test tasks;
after the test terminal burns the test firmware into the DTU PCBA to be tested, the test terminal receives burning feedback information, determines whether the current burning is successful or not based on the burning feedback information, and if the burning is successful, various tests can be carried out on the DTU PCBA to be tested according to a communication protocol. In one embodiment, the test terminal and the DTU PCBA to be tested communicate by using a Modbus, but not limited to a serial port type and a network type, wherein the Modbus is a serial communication protocol; in the test firmware, an RTOS (real-time operating system) system is used for independently forming all test items into a test task, the test task comprises watchdog testing, system clock testing, and testing of peripheral interfaces such as interfaces of analog quantity input 0-5V, 4-20mA, 485, 232, TTL, communication modules and the like, and the specific test items are determined according to the interfaces of the DTU. When the test terminal sends a test instruction to the DTU PCBA to be tested, different test tasks can be selected based on the test instruction, specifically, selection and control of a test item of the DTU PCBA to be tested are realized through a holding register in a Modbus protocol, for example: starting and suspending each test task is realized by holding the address 01 of the register, or selecting the test item by holding the address 02 of the register, and the like. After receiving the test instruction, the DTU PCBA to be tested executes a corresponding test action according to the test task selected in the test instruction, for example: and if the current test task is system clock test, the DTU PCBA to be tested performs various tests related to the system clock.
Step S30, after the test is completed, obtaining the target firmware and the set credential information, and writing the target firmware and the set credential information into the DTU hardware to be tested.
When the testing of the DTU PCBA to be tested is completed, namely the testing is successful, the target firmware is obtained according to the device information of the tested DTU PCBA, the target firmware is formal firmware, namely a device driver stored in the device, and the DTU PCBA can realize the running action of a specific machine according to the standard device driver through the formal firmware. Meanwhile, the test terminal sends an acquisition request of the certificate information to the cloud server, the cloud server feeds back corresponding certificate information to the test terminal based on the acquisition request, and further writes formal firmware and the certificate information into the successfully tested DTU PCBA, wherein the certificate information refers to relevant information of network access of the DTU, such as equipment ID, identity information of manufacturer number and the like, such as Ali triple information and the like.
It should be noted that the credential information here is related to the cloud server used, and there may be differences in credential information of different cloud servers, and secondly, the credential information functions like an identity card of a user as a credential for identity recognition.
Further, referring to fig. 6, after the step of obtaining the target firmware and the set credential information after the test is completed, and writing the target firmware and the set credential information into the DTU hardware to be tested, the method includes:
step S31, setting label information corresponding to the DTU hardware to be tested;
step S32, sending a print instruction to a printing device, so that the printing device prints the label information according to the print instruction.
After the test of the DTU PCBA is completed, label information corresponding to the DTU PCBA can be printed out, and the label information is convenient for a user to check, wherein before the label information is printed, the content, the format and the like of the label information need to be set firstly, if the content of the label information is set according to the device information corresponding to the DTU PCBA, the label information can comprise information such as a device number, a device model, a device ID (identity) place and a device name, a printing instruction is sent to a printing device (such as a printer), and the printing device prints the corresponding label information based on the printing instruction. Or directly using a pre-stored label information template and performing customized printing based on the label information template, wherein the content in the label information template can be realized by self-defining and selecting parameters in the configuration information.
In this embodiment, when the DTU hardware to be tested is identified on the test fixture, the test firmware is obtained and burned into the DTU hardware to be tested; after the burning is successful, sending a test instruction to the DTU hardware to be tested, and selecting different test tasks according to the test instruction so that the DTU hardware to be tested executes corresponding test actions based on the test tasks; and after the test is finished, acquiring the target firmware and the set credential information, and writing the target firmware and the set credential information into the DTU hardware to be tested. Through carrying out full link test, configuration with DTU hardware from PCBA link to the delivery state, reduce the user and go to intervene, improve efficiency of software testing, simultaneously, PCBA is active traceable from all links from production to the warehouse-out, realizes reliable closed loop, avoids the loss that unusual hardware warehouse-out caused. Moreover, the DTU hardware test and the firmware writing and configuration before delivery are integrated, so that errors caused by human factors are reduced, test cases can be reduced, and the productivity is improved.
Further, referring to fig. 3, a second embodiment of the DTU hardware testing method of the present application is provided.
The difference between the second embodiment of the DTU hardware testing method and the first embodiment of the DTU hardware testing method is that after the step of sending a testing instruction to the DTU hardware to be tested and selecting different testing tasks according to the testing instruction, the method includes:
step S21, obtaining a test result;
and step S22, displaying the test result through a visual page, and sending the test result to a cloud server.
The testing terminal obtains a testing result in real time in the process of carrying out the DTU PCBA testing, and displays the testing result through a visual page, specifically, the testing terminal maps the testing data in the obtained testing result into recognizable graphs, images, charts and the like through a data analysis tool or software and by applying technologies such as computer graphics, images, human-computer interaction and the like. The visualization is a process of converting data, information and knowledge into an visualized visual form, emphasizes the processing process of people on the data, the information and the knowledge from top to bottom, and is suitable for drawing a large amount of information as compared with complicated data, and the chart can express the information more simply.
The test terminal also needs to send the test result to the cloud server in a synchronous manner, so that the user can subsequently inquire and use the related test data, and analyze the test result based on the test data to generate a corresponding analysis report and the like.
Further, referring to fig. 7, after the step of displaying the test result through a visualization page and sending the test result to the cloud server, the method includes:
step S220, selecting control types and control numbers according to test items corresponding to the equipment information of the DTU hardware to be tested;
and step S221, dynamically adjusting a test interface according to the control type and the control number.
The test terminal can dynamically adjust the content of a test interface while displaying a test result, specifically, obtain the device information of the to-be-tested DTU PCBA, obtain the device model from the device information, select the control type and the control number according to the test item corresponding to the device model, for example, the A model has 5 to-be-tested items, wherein the status type has 3 items, and the numerical type has 2 items, the test terminal can automatically set a test page according to the status types, use the status control to represent the real-time situation of each status type test item, and display the specific numerical value of the test item of the numerical type in real time through the numerical control, thereby realizing the visual display and dynamic adjustment of the test.
In the embodiment, the test result is obtained, the test result is displayed through the visual page, and the displayed content can be dynamically adjusted based on the test item information corresponding to the equipment model, so that the user can know the test result more clearly and clearly, and meanwhile, the test result is synchronized to the cloud server, and the user can conveniently use the related test data for subsequent query.
Further, referring to fig. 4, a third embodiment of the DTU hardware testing method of the present application is provided.
The third embodiment of the DTU hardware testing method is different from the first and second embodiments of the DTU hardware testing method in that, before the step of obtaining the test firmware and burning the test firmware to the DTU hardware to be tested when the DTU hardware to be tested is identified on the test fixture, the method includes:
step S13, identifying the hardware code of the DTU hardware on the test tool through identification equipment to determine whether the DTU hardware is the DTU hardware to be tested, wherein the hardware code is pasted on the DTU hardware in advance;
step S14, if the DTU hardware is a DTU hardware to be tested, performing a step of burning the test firmware to the DTU hardware to be tested.
A hardware code is generated in a factory in the process of producing the DTU PCBA, and the hardware code is pasted on the DTU PCBA as a test tracing hardware code, and the hardware code includes but is not limited to a code in the form of a bar code, and may also be a unique identification code UID of a chip, and the like, wherein the form of the hardware code may be: XX-XX, such as XY-04A.
The testing terminal is provided with a camera or scanning equipment, when the fact that the DTU PCBA is installed on the testing tool is detected, the hardware code on the DTU PCBA is identified through the camera or the scanning equipment, the identified hardware code is matched with the prestored hardware code, whether the currently identified hardware code is identified for the first time is judged, if yes, the DTU PCBA is the DTU PCBA to be tested, and if not, the DTU PCBA is tested. And after the current DTU PCBA is determined to be the to-be-tested DTU PCBA, obtaining test firmware, and burning the test firmware to the to-be-tested DTU PCBA. The dynamic state of the DTU PCBA on the test tool can be detected in real time by a camera or scanning equipment in the test terminal, and after the new DTU PCBA is detected to be installed on the test tool, a new round of test operation is automatically carried out.
Further, after the step of identifying the hardware code of the DTU hardware on the test fixture by the identification device, the method further includes:
and acquiring a picture of the DTU hardware to be tested, and storing the picture to a cloud server and a local terminal.
The test terminal can photograph the DTU PCBA through the camera while identifying the DTU PCBA, and stores the photograph to the cloud server and the terminal, so that the user can conveniently check and use the photograph subsequently.
In this embodiment, pass through the camera or sweep a yard equipment and discern DTU PCBA on the test fixture to confirm whether this DTU PCBA is the DTU PCBA that awaits measuring, simultaneously, still store DTU PCBA's picture to cloud ware and terminal local, the follow-up use of looking for of convenience of customers.
In an embodiment, the DTU hardware testing apparatus includes a memory, a processor, and a DTU hardware testing program stored in the memory and capable of running on the processor, where the DTU hardware testing program implements the following steps when executed by the processor:
when the DTU hardware to be tested is identified on the test tool, obtaining test firmware, and burning the test firmware to the DTU hardware to be tested;
after the burning is successful, sending a test instruction to the DTU hardware to be tested, and selecting different test tasks according to the test instruction so that the DTU hardware to be tested executes corresponding test actions based on the test tasks;
and after the test is finished, acquiring target firmware and set credential information, and writing the target firmware and the set credential information into the DTU hardware to be tested.
In one embodiment, the DTU hardware testing apparatus includes a burning module, a sending module and an obtaining module;
the burning module is used for acquiring test firmware when the DTU hardware to be tested is identified on the test fixture and burning the test firmware to the DTU hardware to be tested;
the sending module is used for sending a test instruction to the DTU hardware to be tested after the burning is successful, and selecting different test tasks according to the test instruction so that the DTU hardware to be tested executes corresponding test actions based on the test tasks;
and the acquisition module is used for acquiring target firmware and set credential information after the test is finished, and writing the target firmware and the set credential information into the DTU hardware to be tested.
Further, the burning module comprises an acquisition unit and a burning unit;
the acquisition unit is used for acquiring the equipment information of the DTU hardware to be tested and selecting the corresponding test firmware according to the equipment information of the DTU hardware to be tested;
and the burning unit is used for calling a program burning interface to burn the test firmware to the DTU hardware to be tested.
Further, the sending module comprises an acquiring unit and a sending unit;
the acquisition unit is used for acquiring a test result;
the sending unit is used for displaying the test result through a visual page and sending the test result to a cloud server.
Further, the acquiring unit comprises a sending subunit and a downloading subunit;
the sending subunit is configured to send a download request to a cloud server according to the device information of the DTU hardware to be tested;
and the downloading subunit is used for downloading the test firmware from the cloud server according to the downloading request.
Further, the sending unit comprises a selecting subunit and an adjusting subunit;
the selection subunit is used for selecting the control type and the control quantity according to the test item corresponding to the device information of the DTU hardware to be tested;
and the adjusting subunit is used for dynamically adjusting the test interface according to the control type and the control number.
Further, the acquisition module comprises an identification unit and a burning unit;
the identification unit is used for identifying a hardware code of the DTU hardware on the test tool through identification equipment to determine whether the DTU hardware is the DTU hardware to be tested, and the hardware code is pasted on the DTU hardware in advance;
the burning unit is used for burning the test firmware to the DTU hardware to be tested if the DTU hardware is the DTU hardware to be tested.
Further, the identification unit comprises an acquisition subunit;
the acquisition subunit is configured to acquire a picture of the DTU hardware to be tested, and store the picture to a cloud server and a local terminal.
Further, the acquisition module further comprises a setting unit and a sending unit;
the setting unit is used for setting label information corresponding to the DTU hardware to be tested;
the sending unit is used for sending a printing instruction to a printing device so that the printing device can print the label information according to the printing instruction.
The implementation of the functions of each module of the DTU hardware testing apparatus is similar to the process in the above method embodiment, and is not described herein again.
In addition, the application also provides a terminal, the terminal comprises a memory, a processor and a DTU hardware testing program which is stored on the memory and runs on the processor, and when the terminal identifies the DTU hardware to be tested on the testing tool, the terminal acquires the testing firmware and burns the testing firmware to the DTU hardware to be tested; after the burning is successful, sending a test instruction to the DTU hardware to be tested, and selecting different test tasks according to the test instruction so that the DTU hardware to be tested executes corresponding test actions based on the test tasks; and after the test is finished, acquiring the target firmware and the set credential information, and writing the target firmware and the set credential information into the DTU hardware to be tested. Through carrying out full link test, configuration with DTU hardware from PCBA link to the delivery state, reduce the user and go to intervene, improve efficiency of software testing, simultaneously, PCBA is active traceable from all links from production to the warehouse-out, realizes reliable closed loop, avoids the loss that unusual hardware warehouse-out caused. Moreover, the DTU hardware test and the firmware writing and configuration before delivery are integrated, so that errors caused by human factors are reduced, test cases can be reduced, and the productivity is improved.
In addition, the present application also provides a computer readable storage medium, where a DTU hardware test program is stored, and when being executed by a processor, the DTU hardware test program implements the steps of the DTU hardware test method described above.
As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may 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, and the like) having computer-usable program code embodied therein.
The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may 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, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
It should be noted that in the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" does not exclude the presence of elements or steps not listed in a claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The application can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by one and the same item of hardware. The usage of the words first, second and third, etcetera do not indicate any ordering. These words may be interpreted as names.
While alternative embodiments of the present application have been described, additional variations and modifications of these embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. It is therefore intended that the following appended claims be interpreted as including alternative embodiments and all such alterations and modifications as fall within the scope of the application.
It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.
Claims (10)
1. A DTU hardware testing method, comprising:
when the DTU hardware to be tested is identified on the test tool, obtaining test firmware, and burning the test firmware to the DTU hardware to be tested;
after the burning is successful, sending a test instruction to the DTU hardware to be tested, and selecting different test tasks according to the test instruction so that the DTU hardware to be tested executes corresponding test actions based on the test tasks;
and after the test is finished, acquiring target firmware and set credential information, and writing the target firmware and the set credential information into the DTU hardware to be tested.
2. The DTU hardware testing method of claim 1, wherein the step of obtaining test firmware and burning the test firmware into the DTU hardware to be tested comprises:
acquiring the equipment information of the DTU hardware to be tested, and selecting corresponding test firmware according to the equipment information of the DTU hardware to be tested;
and calling a program burning interface to burn the test firmware to the DTU hardware to be tested.
3. The DTU hardware testing method of claim 1, wherein the step of sending a test instruction to the DTU hardware to be tested and selecting a different test task according to the test instruction comprises:
obtaining a test result;
and displaying the test result through a visual page, and sending the test result to a cloud server.
4. The DTU hardware testing method of claim 2, wherein the step of selecting the corresponding test firmware according to the device information of the DTU hardware to be tested comprises:
sending a downloading request to a cloud server according to the equipment information of the DTU hardware to be tested;
and downloading the test firmware from the cloud server according to the downloading request.
5. The DTU hardware testing method of claim 3, wherein after the step of displaying the test result on a visual page and sending the test result to a cloud server, the method comprises:
selecting control types and control numbers according to test items corresponding to the equipment information of the DTU hardware to be tested;
and dynamically adjusting the test interface according to the control type and the control number.
6. The DTU hardware testing method of claim 1, wherein before the step of obtaining the test firmware and burning the test firmware to the DTU hardware to be tested when the DTU hardware to be tested is identified on the testing tool, the method comprises:
identifying a hardware code of the DTU hardware on the test tool through identification equipment to determine whether the DTU hardware is the DTU hardware to be tested, wherein the hardware code is pasted on the DTU hardware in advance;
and if the DTU hardware is to-be-tested DTU hardware, executing the step of burning the test firmware to the to-be-tested DTU hardware.
7. The DTU hardware testing method of claim 6, wherein after the step of identifying the hardware code of the DTU hardware on the testing tool by the identification device, the method further comprises:
and acquiring a picture of the DTU hardware to be tested, and storing the picture to a cloud server and a local terminal.
8. The DTU hardware testing method of any of claims 1-3, wherein the step of obtaining target firmware and set credential information after the testing is completed, and writing the target firmware and the set credential information into the DTU hardware to be tested, comprises:
setting label information corresponding to the DTU hardware to be tested;
and sending a printing instruction to a printing device so as to enable the printing device to print the label information according to the printing instruction.
9. A terminal, characterized in that the terminal comprises a memory, a processor and a DTU hardware test program stored on the memory and running on the processor, and the processor implements the steps of the DTU hardware test method according to any one of claims 1 to 8 when executing the DTU hardware test program.
10. A computer readable storage medium, characterized in that the computer readable storage medium has stored thereon a DTU hardware test program, which when executed by a processor implements the steps of the DTU hardware test method of any of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110122287.5A CN112783708A (en) | 2021-01-28 | 2021-01-28 | DTU hardware testing method, terminal and computer readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110122287.5A CN112783708A (en) | 2021-01-28 | 2021-01-28 | DTU hardware testing method, terminal and computer readable storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112783708A true CN112783708A (en) | 2021-05-11 |
Family
ID=75759569
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110122287.5A Pending CN112783708A (en) | 2021-01-28 | 2021-01-28 | DTU hardware testing method, terminal and computer readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112783708A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117665545A (en) * | 2024-02-01 | 2024-03-08 | 广州市大枣信息科技有限公司 | Burn-in test device, system and method |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4159534A (en) * | 1977-08-04 | 1979-06-26 | Honeywell Information Systems Inc. | Firmware/hardware system for testing interface logic of a data processing system |
| KR19980025438A (en) * | 1996-10-01 | 1998-07-15 | 구자홍 | Hardware Integration Test Method |
| CN101304542A (en) * | 2007-05-10 | 2008-11-12 | 联发科技股份有限公司 | Device and method for calibrating data processing apparatus |
| CN111143150A (en) * | 2019-12-27 | 2020-05-12 | 深圳市越疆科技有限公司 | Method and system for testing PCBA (printed circuit board assembly), testing equipment and micro-control unit |
| CN111209150A (en) * | 2019-12-31 | 2020-05-29 | 珠海六点智能科技有限公司 | Board card testing method and system based on Debian system |
| CN111610427A (en) * | 2020-04-15 | 2020-09-01 | 广东乐心医疗电子股份有限公司 | Finished product testing method, circuit board testing method and device |
-
2021
- 2021-01-28 CN CN202110122287.5A patent/CN112783708A/en active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4159534A (en) * | 1977-08-04 | 1979-06-26 | Honeywell Information Systems Inc. | Firmware/hardware system for testing interface logic of a data processing system |
| KR19980025438A (en) * | 1996-10-01 | 1998-07-15 | 구자홍 | Hardware Integration Test Method |
| CN101304542A (en) * | 2007-05-10 | 2008-11-12 | 联发科技股份有限公司 | Device and method for calibrating data processing apparatus |
| CN111143150A (en) * | 2019-12-27 | 2020-05-12 | 深圳市越疆科技有限公司 | Method and system for testing PCBA (printed circuit board assembly), testing equipment and micro-control unit |
| CN111209150A (en) * | 2019-12-31 | 2020-05-29 | 珠海六点智能科技有限公司 | Board card testing method and system based on Debian system |
| CN111610427A (en) * | 2020-04-15 | 2020-09-01 | 广东乐心医疗电子股份有限公司 | Finished product testing method, circuit board testing method and device |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117665545A (en) * | 2024-02-01 | 2024-03-08 | 广州市大枣信息科技有限公司 | Burn-in test device, system and method |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111769995A (en) | Instrument terminal management method, system, mobile terminal and readable storage medium | |
| CN113672441A (en) | Method and device for testing intelligent equipment | |
| CN112783708A (en) | DTU hardware testing method, terminal and computer readable storage medium | |
| US20230391147A1 (en) | Method and Apparatus for Displaying Function Menu Interface of Automobile Tyre Pressure Monitoring System | |
| CN113126993B (en) | Automatic test method and system applied to vehicle detection software | |
| CN112822073B (en) | Test method, device, system, electronic equipment and readable storage medium | |
| CN114281624A (en) | Method, system, device and equipment for testing I2C signal integrity | |
| CN111901589B (en) | Automatic test system for television mainboard | |
| CN113052457A (en) | Manufacturing management method and system of intelligent product and readable storage medium | |
| CN113220322A (en) | Test software updating method, electronic device and storage medium | |
| CN113673797A (en) | Production monitoring method and device and computer readable storage medium | |
| CN109379588B (en) | Automatic testing method and system for high-definition DVR | |
| CN111277303A (en) | Production testing method and system based on universal asynchronous receiving and transmitting transmitter to Bluetooth | |
| CN115717987A (en) | Display module testing system and method | |
| CN115963379A (en) | Automatic test method, device, equipment and storage medium for circuit board | |
| CN115470057A (en) | Display screen testing method and device | |
| CN115967660A (en) | Method and device for testing CAN protocol conversion, terminal equipment and storage medium | |
| CN111352780B (en) | Method and device for determining state of path and readable storage medium | |
| CN110704252A (en) | Automatic testing device and testing method based on cloud dynamic management | |
| CN211827293U (en) | Tool with display device | |
| CN110023770A (en) | For testing method, test platform and the test macro of chip | |
| CN113721562A (en) | Automatic configuration method for production line test resources | |
| CN111610427A (en) | Finished product testing method, circuit board testing method and device | |
| CN107086899B (en) | Intelligent serial port testing device and testing method | |
| CN111291105B (en) | PCB board inspection data processing method, device and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |