Embedded terminal production test method

Abstract

The invention discloses an embedded terminal production test method, and belongs to the technical field of production test. According to the method, a test configuration file is imported through upper computer test software, test item configuration is extracted and organized from the test configuration file, and a test item queue is formed; and after the upper computer and the embedded terminal complete identity authentication through handshake communication, analyzing and sending a test command in sequence, receiving and analyzing a test result, and dynamically updating the test progress until all test items are completed. According to the invention, a configuration-driven test architecture is adopted, test logic and software are separated, standardization, configurability and cross-product-line reuse of a test process are realized, and the problems of high development and maintenance cost, non-uniform operation, poor environmental suitability and the like of traditional production test software are solved; and the universality, the expandability and the production efficiency of the test system are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of production testing, in particular to an embedded terminal production testing method. BACKGROUND

[0002] In the field of smart home, consumer electronics and other digital product research and manufacturing enterprises, there are various product types, diverse technical platforms, complex functional characteristics and continuous iteration. In order to ensure product quality and production efficiency, various terminal devices need to go through strict production testing process before leaving the factory, and the development and maintenance of production testing software as a key tool to realize automatic testing has become an important link in the research and development system.

[0003] However, there are significant differences in functional requirements, hardware platforms, communication protocols, testing processes and use scenarios between product lines, which leads to the development mode of "one product one software" in production testing software. That is, each type of product often needs to develop and maintain a set of special testing software for a long time. This decentralized development method not only causes repeated investment of research and development resources, but also brings problems such as complex version management, low code reuse rate and high maintenance cost.

[0004] More prominent is that the above problems will have a serious impact on the production end. Because each production testing software is developed by different teams based on different technology stacks (such as C#, Qt, Python, etc.), the user interface, operation logic and interaction mode lack unified standards, resulting in that the production line operators need to be retrained when switching product lines, with high learning cost and frequent operation errors.

[0005] In addition, different software has different compatibility requirements for running environment such as operating system version, driver dependency and third-party library, which causes a lot of time to be spent on software deployment and environment debugging every time the production line is switched or the equipment is replaced, seriously affecting the starting efficiency and overall rhythm of the production line.

[0006] In summary, the existing production testing software system has defects such as decentralized development, difficult maintenance, non-unified operation and poor environment adaptability, which has been difficult to meet the needs of modern intelligent manufacturing for efficient, flexible and standardized production testing. Therefore, it is urgent to build a unified, extensible and easy-to-maintain production testing software architecture to realize the reuse of testing capabilities across product lines, reduce research and development and operation and maintenance costs, and improve production efficiency and system stability. SUMMARY

[0007] The technical problem to be solved by the present application is to provide an embedded terminal production testing method to realize the reuse of testing capabilities across product lines in view of the above defects of the prior art.

[0008] To achieve the above purpose, the present application provides an embedded terminal production testing method, which comprises the following steps:

[0009] Step S1, start the host computer test software, import a test configuration file into the host computer test software, select a test item from the test configuration file, and write test item configuration information corresponding to the selected test item into a test item queue;

[0010] Step S2, the embedded terminal and the host computer complete a handshaking process through multiple communications, and the embedded terminal identity is authenticated through the handshaking process;

[0011] Step S3, the host computer test software reads a piece of test item configuration information from the test item queue, parses the test item configuration information, and obtains a test command queue;

[0012] Step S4, the host computer test software takes out a test command from the test command queue, and encapsulates the test command into a test command data packet and sends it to the embedded terminal;

[0013] Step S5, the embedded terminal executes the test according to the test command, and returns a test result data packet to the host computer test software after the execution is completed;

[0014] Step S6, the host computer test software receives and parses the test result data packet, and updates the test result and progress;

[0015] Step S7, repeat steps S4-S6 until all test commands in the test command queue have completed the test, then repeat steps S3-S6 to test the next test item until all test items in the test item queue have completed the test.

[0016] In the embedded terminal production test method, the step S2 comprises:

[0017] Step S21, the embedded terminal sends a handshaking synchronization information to the host computer;

[0018] Step S22, the host computer judges whether the handshaking synchronization information is consistent with a preset handshaking synchronization information, if yes, a handshaking success response is returned, and if no, a handshaking failure response is returned;

[0019] Step S23, after receiving the handshaking success response, the embedded terminal sends terminal device information to the host computer; the terminal device information comprises a synchronization field, a terminal production test version number, and a terminal model code;

[0020] Step S24, the host computer checks the terminal device information, if the check is passed, jump to step S3, if the check is not passed, an error prompt is popped up, and the test is terminated.

[0021] The test item configuration information includes test item name, original command code data, and subcommand array, the subcommand array includes at least one subcommand configuration, the subcommand configuration includes subcommand serial number, subcommand code data, subcommand execution function name, data source, and test result range; the original command code data includes subcommand number and subcommand code data of all subcommands.

[0022] The subcommand configuration further includes pre-execution prompt information and post-execution prompt information, and the host computer test software displays the pre-execution prompt information in a pop-up window before executing the subcommand corresponding to the subcommand configuration, and displays the post-execution prompt information in a pop-up window after executing the subcommand corresponding to the subcommand configuration.

[0023] The data source includes code gun reading, local reading, and network reading.

[0024] The subcommand code data includes whether there is data, test state, test result judgment method, and execution action.

[0025] The test state includes untested, tested, test passed, and test failed; the test result judgment method includes automatic, manual, self-check, and external check; wherein, the automatic indicates that the embedded terminal judges, the manual indicates that the test personnel manually judges, the self-check indicates that the host computer test software judges according to the test item configuration, and the external check includes that the host computer test software judges in combination with external equipment; and the execution action includes unsetting, starting, stopping, reading, and writing.

[0026] The test command data packet and the test result data packet have the same data structure, and both include packet header, payload, and check value; wherein, the packet header includes synchronization field, command information field, and payload data length field, the command information field includes command field and subcommand field; and the payload includes whether there is data field, test state field, test result judgment method field, execution action field, subcommand data length field, and subcommand data content field.

[0027] The present application has the following beneficial effects:

[0028] 1. By introducing a test configuration file driven test mechanism, the test project, test command and its execution logic are decoupled from the host software code, realizing the external configuration of the test process. Different product lines only need to replace the configuration file to adapt to their respective test requirements, avoiding the development and maintenance of independent test software for each type of product, significantly improving the universality and consistency of the test system.

[0029] 2. The increase or decrease of test items and the adjustment of test commands can be completed by modifying the configuration file, without the need to recompile or deploy the host software, greatly reducing the cost of function extension and maintenance. The import cycle of new products is significantly shortened, adapting to the flexible production demand of multiple varieties and small batches.

[0030] 3. Using a layered processing mechanism, the test item queue and the test command queue are separated, supporting the ordered execution of complex test processes. The structured communication protocol of test command data packets and test result data packets ensures efficient and reliable interaction between the host computer and the embedded terminal, improving the stability and fault tolerance of the test process.

[0031] 4. The unified host test software interface and operation logic reduce the learning cost and the risk of misoperation of the production line operators. Combined with the identity authentication mechanism of the embedded terminal, the accuracy of the test object is ensured, preventing misoperation or omission, and ensuring product quality.

[0032] 5. Since the test logic is driven by the configuration, the host software can use any technology stack (such as C#, Python, Qt, etc.) to implement the core communication and scheduling functions, facilitating the integration of existing development resources for enterprises, and realizing the smooth transition and unified management of the technology platform.

[0033] In summary, the present application effectively solves the problems of development redundancy, maintenance difficulty and operation inconsistency caused by the traditional production test software "one product one software", and builds a highly cohesive, low-coupling and reusable production test architecture, significantly improving the research and development efficiency, production efficiency and system maintainability. BRIEF DESCRIPTION OF DRAWINGS

[0034] The drawings described herein are used to provide a further understanding of the present application, and form a part of the present application. The illustrative embodiments of the present application and their descriptions serve to explain the present application, and do not constitute an improper limitation of the present application. In the drawings:

[0035] Figure 1 The steps of the embedded terminal production test method provided for the embodiments of the present application are shown in the schematic diagram.

[0036] Figure 2 The host test software interface initial state and execution result display page schematic diagram provided for the embodiments of the present application. DETAILED DESCRIPTION

[0037] In order to make the purposes, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0038] The embodiments of the present application will be further described in detail below with reference to the drawings in the specification. It should be understood that the described embodiments are only used for illustrating and explaining the present application, and are not used for limiting the present application.

[0039] The scheme of the present application is suitable for intelligent home and digital product production enterprises to produce and test various embedded terminals, abstracts diversified test items into configuration files in a unified format, and realizes the compatibility of multiple production lines through unified host computer test software and user interface operation.

[0040] As shown in Figure 1 The present embodiment provides an embedded terminal production test method, which comprises the following steps:

[0041] Step S1, start the host computer test software, import the test configuration file into the host computer test software, select the test items from the test configuration file, and write the test item configuration information corresponding to the selected test items into the test item queue.

[0042] In the present embodiment, the embedded terminal includes a set-top box, an IPC (Internet Protocol Camera), and a smart sound box, the test items are mainly hardware tests, including LED lights, keys, USB ports, SN number reading and writing, virtual card number reading and writing, codec terminal test, codec function test, etc. The host computer is installed with host computer test software, which imports and edits test configuration files, sends test commands, displays test results and progress, processes and uploads test results through a man-machine interface. The embedded terminal runs corresponding production test software, which is connected with the host computer test software, performs number burning, function test, and product setting according to the test commands sent by the host computer test software, and returns the test results.

[0043] In the embodiment of the present application, the test item requirements and test results of various different embedded terminals are analyzed to form a set of unified configuration information, and various test scenarios of various embedded terminals are compatible through different values of various fields. For each embedded terminal, a test configuration file corresponding to the terminal is formed, and the configuration file is uploaded to a server. When a tester tests, the configuration file corresponding to the embedded terminal is obtained from the server, imported into the host computer test software, and then the test items are selected from the host computer test software to perform the test. In this way, the test items and the host computer test software are decoupled, so that a set of unified host computer test software and user interface operation can be used to realize the compatibility of multiple production lines. When the test items need to be added, deleted or modified, the configuration file is directly modified, and then the new configuration file is imported into the host computer test software, without the need to recompile the host computer test software.

[0044] In the embodiment of the present application, the test item configuration information includes a test item name, original command code data, and a subcommand array, the subcommand array includes at least one subcommand configuration, and the subcommand configuration includes a subcommand serial number, subcommand code data, a subcommand execution function name, data source, and a test result range.

[0045] Preferably, in the embodiment of the present application, the test configuration file is in JSON format. The following is an example of a test configuration file of a set top box. In the example, test_items represents a test item list, and the names of various fields are shown in Table 1.

[0046]

[0047]

[0048]

[0049]

[0050]

[0051]

[0052] Table 1: Test item configuration field meaning table

[0053]

[0054] The name field is a test item name, and the above set-top box test configuration file example includes test items LED, KEY, USB, SN, and cnx_vsc. The test item LED is used to test the LED light on the set-top box, the test item KEY is used to test the key on the set-top box, the test item USB is used to test the USB port of the set-top box, the test item SN is used to test the SN number read-write function of the set-top box, and the test item cnx_vsc is used to test the acquisition and writing function of the virtual card number of the set-top box. The original command encoding data includes the number of sub-commands and the sub-command encoding data of all sub-commands. Taking the LED test item in the above set-top box test configuration file as an example, the original command encoding data is "20001110011", wherein the first "2" indicates that there are two sub-commands, and the following "00011" and "10011" respectively indicate the sub-command encoding data of the two sub-commands.

[0055] Each test item corresponds to a test command, and each test command can further include multiple test sub-commands. The length of sub_commands indicates the number of sub-commands, and each element in sub_commands corresponds to a sub-command configuration information. Among them, the LED test item contains 2 test sub-commands, the KEY test item contains 3 test sub-commands, the USB test item contains 1 test command, the SN test item contains 1 test command, and the cnx_vsc test item contains 2 test sub-commands. In each command, the command field indicates the sub-command encoding data, the handler field indicates the sub-command execution function name, the data_source field indicates the data source, the result_judgment field indicates the test result judgment method, "auto" indicates that the embedded terminal judges, "manual" indicates that the test personnel manually judges, "self_check" indicates that the host computer test software judges according to the test item configuration, and "ext_check" indicates that the host computer test software judges in combination with external equipment. The lower_limit and upper_limit respectively indicate the lowest allowable value of the test result and the highest allowable value of the test result, which are used in self-checking and external checking.

[0056] In the embodiment of the application, the data source includes code scanning gun reading, local reading, and manufacturing execution system (MES) reading.

[0057] In the above set-top box test configuration file example, the data_source field indicates the data source, "BARCODE" corresponds to code scanning gun reading, "LOCAL_PATH" corresponds to local reading, and "MES_PATH" corresponds to reading from the MES system. It can be understood that more data sources can be expanded according to actual test needs, such as reading from a database.

[0058] In the above example of the set-top box test configuration file, the handler has two cases, do_common_test and do_conax_vsc_test. The do_common_test is used to parse the subcommand configuration, encapsulate it into a data packet, and send it to the embedded terminal. If the data source is configured, the corresponding data is obtained according to the data source configuration, and the data length and data content are appended to the subcommand data to encapsulate them into a data packet. The do_conax_vsc_test is used to read the chipid from the set-top box, obtain the virtual card number from the server according to the chipid, and write the virtual card number into the set-top box.

[0059] In the embodiment of the application, the subcommand encoding data includes: subcommand number, whether there is data, test status, test result judgment method, and execution action. In the above example of the test configuration file, the subcommand encoding data is a 5-digit decimal or hexadecimal number, in which the first digit represents the subcommand number, the second digit represents whether there is data, the third digit represents the test status, the fourth digit represents the test result judgment method, and the fifth digit represents the execution action. The test status includes: not tested, tested, test passed, and test failed. The test result judgment method includes: automatic, manual, self-check, and external check. The "automatic" means that the embedded terminal judges, the "manual" means that the test personnel manually judges, the "self-check" means that the host computer test software judges according to the test item configuration, and the "external check" includes that the host computer test software judges in combination with external equipment. The execution action includes: not set, start, stop, read, and write. If the data is set, the data_source field needs to be configured, the host computer test software obtains the data corresponding to the subcommand according to the content of the data_source field, and then sends the obtained data and the subcommand to the embedded terminal. The test result judgment method in the subcommand encoding data and the result_judgment in the subcommand configuration have the same meaning, but for the convenience of understanding, the result_judgment in the subcommand configuration is usually set in the form of a string, and the corresponding position in the subcommand encoding data is usually set as a decimal or hexadecimal number.

[0060] In some embodiments of the application, the subcommand configuration further includes pre-execution prompt information and post-execution prompt information. The host computer test software displays the pre-execution prompt information in a pop-up box before executing the subcommand corresponding to the subcommand configuration, and displays the post-execution prompt information in a pop-up box after executing the subcommand corresponding to the subcommand configuration.

[0061] As shown in the above example of the test configuration file of the set top box and Table 1, the popup_msg_before field represents the pre-execution prompt information and the post-execution prompt information. The tester performs test preparation according to the prompt information before the test and manually judges whether the test result is correct according to the prompt information after the test. It can be understood that the pre-execution prompt information and the post-execution prompt information are set according to the needs of the test, and one, two, or zero of them can be set. For example, in the above example, the sub-commands under the test item LED need to remind the tester to prepare before the test and manually judge the result after the test, and therefore, corresponding settings are made in the popup_msg_before and popup_msg_after fields. The sub-commands under the test item KEY need to remind the tester to prepare before the test, but the test result judgment is completed by the test software on the set top box, and therefore, only the popup_msg_before needs to be configured.

[0062] The tester imports the test configuration file into the host computer test software, and after selecting the test item from the test configuration file, the host computer test software writes the test item configuration information corresponding to the selected test item into the test item queue. Taking the test configuration file of the set top box as an example, which includes five test items of LED, KEY, USB, SN, and cnx_vsc, the configuration information of these test items is written into the test item queue in turn, and a test item queue with a length of 5 is obtained.

[0063] After the host computer test software imports the configuration and initializes the test item, it enters the main test interface, and the interface status bar displays that it is waiting for device connection.

[0064] In step S2, the embedded terminal and the host computer complete the handshake process through multiple communications, and the embedded terminal identity authentication is performed through the handshake process.

[0065] In the embodiment of the application, step S2 includes:

[0066] In step S21, the embedded terminal sends handshake synchronization information to the host computer.

[0067] In step S22, the host computer judges whether the handshake synchronization information is consistent with the preset handshake synchronization information. If yes, a handshake success response is returned; if no, a handshake failure response is returned.

[0068] In step S23, after receiving the handshake success response, the embedded terminal sends terminal device information to the host computer. The terminal device information includes a synchronization field, a terminal production version number, and a terminal model code.

[0069] Step S24, the host computer checks the terminal device information, if the check is passed, jump to step S3, if the check is not passed, pop up an error prompt, terminate the test.

[0070] In the preferred embodiment of the present application, the embedded terminal and the host computer are connected through a serial port. After the embedded terminal is powered on, it actively sends a specific synchronization character "GIEC" to request communication with the host computer. The host computer analyzes the handshake synchronization information of the embedded terminal, and if the synchronization character is "GIEC", it returns the character "ACK" to the embedded terminal. After receiving "ACK", the embedded terminal sends terminal device information to the host computer, which includes a synchronization field, a terminal production version number, and a terminal model code. The host computer determines whether it is compatible with the terminal device information, and if it is compatible, it enters a working mode and prepares to send a test command. If it is not compatible, it prompts the tester through a pop-up message and terminates the test.

[0071] Further, for embedded terminals with high security requirements, it is desirable to encrypt or compress data packets during communication with the host computer. In step S23, the terminal device information also includes whether encryption and compression are required. The host computer first determines whether it is compatible with the corresponding terminal according to the terminal device information, and then determines whether encryption or compression is required. If encryption or compression is required, the data packets are encrypted or compressed during subsequent communication with the terminal. The encryption and compression algorithms can be agreed upon in advance with the terminal, and a fixed encryption algorithm and compression algorithm are used. Of course, it can be understood that different encryption algorithms or compression algorithms can be used as needed during the interaction of the host computer and different embedded terminals, and a field corresponding to the encryption algorithm and compression algorithm can be added to the terminal device information.

[0072] Step S3, the host computer test software reads a test item configuration information from the test item queue, analyzes the test item configuration information, and obtains a test command queue.

[0073] In the embodiment of the present application, a test item configuration information is taken out from the test item queue each time, and a test command queue is obtained by analyzing it. Taking the above set-top box test configuration file as an example, it is assumed that the test item corresponding to the LED is taken out, and a test command queue with a length of 2 is obtained.

[0074] Step S4, the host computer test software takes a test command from the test command queue and encapsulates it into a test command data packet to send to the embedded terminal.

[0075] In the embodiment of the present application, the host computer test software sends only one test command to the embedded terminal at a time, and after receiving the test result of the embedded terminal, the next test command is sent.

[0076] In the embodiment of the present application, the test command data packet comprises a packet header, a load, and a check value; wherein the packet header comprises a synchronization field, a command information field, and a load data length field, the command information field comprises a command field and a subcommand field; the load comprises: a data field, a test state field, a test result judgment method field, an execution action field, a subcommand data length field, and a subcommand data content field; wherein the data field, the test state field, the test result judgment method field, and the execution action field in the load one-to-one correspond to each bit of the subcommand code data in the subcommand configuration in the test command configuration file. The data structure of the test command data packet is shown as follows:

[0077]

[0078] The data structure of the packet header is shown as follows:

[0079]

[0080] The name field in the above set-top box test configuration file example is the first byte of the cmd field in the packet header, and the second byte is temporarily reserved.

[0081] The data structure of the load is shown as follows:

[0082]

[0083] Taking the SN serial number writing as an example, the data of the test command data packet is shown in Table 2.

[0084] Table 2 SN serial number writing data packet example

[0085]

[0086]

[0087] In step S5, the embedded terminal performs a test according to the test command, and returns a test result data packet to the host computer test software after the test is completed.

[0088] In the embodiment of the present application, the data structure of the test result data packet and the test command data packet is the same, the test result is returned through the test state field in the load, if there is test data to be returned together, the presence of data is indicated through the data field, and then the test data is added to the test result data packet to be returned to the host computer test software.

[0089] Taking the above set-top box test configuration file as an example, the test configuration and command interaction data process is shown in Table 3.

[0090] Table 3 Set-top box test configuration and command interaction data process

[0091]

[0092]

[0093] Step S6, the host computer test software receives and parses the test result data packet, updates the test result and progress.

[0094] As Figure 2 The host computer test software interface initial state and execution result display page schematic diagram is shown. The host computer test software updates the test progress and result in the page according to the actual test progress. In addition, the host computer test software selects the appropriate opportunity to upload the test data to the designated server according to the actual needs.

[0095] Step S7, repeat steps S4-S6 until all test commands in the test command queue have completed the test, then repeat steps S3-S6 to test the next test project until all test projects in the test project queue have completed the test.

[0096] If several different types of embedded terminals need to be tested in sequence at one station, the corresponding test configuration file needs to be imported in sequence, the embedded terminal needs to be handshaked, and the test command needs to be sent. After the test project of a certain type of embedded terminal is completely executed, the host computer test software is restarted, and the next type of embedded terminal is tested according to the above process. If the test configuration file needs to be modified, the host computer test software is restarted, and the new test configuration file is imported, without the need to recompile the host computer test software. Before testing, the SN bar code is usually pasted on the shell of the embedded terminal. The SN number corresponding to the SN bar code can be written into the non-volatile memory of the embedded terminal by executing the SN number writing test project, and at the same time, the binding of the SN number and the test results of all subsequent test projects is realized.

[0097] For example, for the above set-top box test configuration file example, if a new test project needs to be added to test the decoding function of the set-top box product, the following configuration is added in the test configuration file. The signal source is connected to the set-top box through the signal line, the set-top box is connected to the television through the HDMI line, the set-top box product locks the frequency and starts decoding and playing after receiving the test command, and then returns the test result. In this test, it is necessary to confirm whether the circuit has been connected, and to manually judge whether the video picture plays normally, therefore, the popup_msg_before and popup_msg_after fields are set, and the result_judgment is set to "manual".

[0098]

[0099]

[0100] The test command details are shown in Table 4, and the test result details are shown in Table 5.

[0101] Table 4: Set-top box decoding function test command details

[0102]

[0103] Table 5: Set-top box decoding function test result details

[0104]

[0105] For example, a temperature sensing test needs to be added to the IPC product. The following test items are added to the test configuration file corresponding to the IPC product. After receiving the test command, the IPC reads the value of the temperature sensor and returns the result. In this test, the upper_limit and lower_limit are used by the host test software to determine whether the result is within a reasonable range. Therefore, the result_judgment field is set to "self_check", and the corresponding threshold values are set for the lower_limit and upper_limit fields.

[0106]

[0107]

[0108] The test command details are shown in Table 6, and the test result details are shown in Table 7, which carries the value of the temperature sensor read.

[0109] Table 6: IPC temperature sensing test command details

[0110]

[0111] Table 7: IPC temperature sensing test result details

[0112]

[0113] The above is only a specific embodiment of the present application, which cannot be used to limit the scope of the present application. Equivalent changes made by those skilled in the art based on the present application, as well as changes well known in the art, should still fall within the scope of the present application.

Claims

1. An embedded terminal production test method, characterized by, The method comprises the following steps: Step S1, starting the host computer test software, importing a test configuration file into the host computer test software, selecting a test item from the test configuration file, and writing test item configuration information corresponding to the selected test item into a test item queue; Step S2, completing a handshake process through multiple communications between the embedded terminal and the host computer, and performing embedded terminal identity authentication through the handshake process; Step S3, the host computer test software reads a piece of test item configuration information from the test item queue, analyzes the test item configuration information, and obtains a test command queue; Step S4, the host computer test software takes out a test command from the test command queue, encapsulates the test command into a test command data packet, and sends the test command data packet to the embedded terminal; Step S5, the embedded terminal performs a test according to the test command, returns a test result data packet to the host computer test software after the test is completed; Step S6, the host computer test software receives and analyzes the test result data packet, and updates the test result and progress; Step S7, repeating steps S4-S6 until all test commands in the test command queue have completed the test, then repeating steps S3-S6 to test the next test item until all test items in the test item queue have completed the test.

2. The method of claim 1, wherein, The step S2 comprises: Step S21, the embedded terminal sends handshake synchronization information to the host computer; Step S22, the host computer judges whether the handshake synchronization information is consistent with preset handshake synchronization information, if yes, returns a handshake success response; if no, returns a handshake failure response; Step S23, after receiving the handshake success response, the embedded terminal sends terminal device information to the host computer; the terminal device information comprises a synchronization field, a terminal production version number, and a terminal model code; Step S24, the host computer checks the terminal device information, if the check is passed, jumps to step S3, if the check is not passed, pops up an error prompt and terminates the test.

3. The method of claim 1, wherein, The test item configuration information comprises a test item name, original command code data, and a subcommand array, the subcommand array comprises at least one subcommand configuration, the subcommand configuration comprises a subcommand serial number, subcommand code data, a subcommand execution function name, a data source, and a test result range; the original command code data comprises the number of subcommands and the subcommand code data of all subcommands.

4. The method of claim 3, wherein, The subcommand configuration further comprises pre-execution prompt information and post-execution prompt information, the host computer test software displays the pre-execution prompt information in a pop-up window before executing the subcommand corresponding to the subcommand configuration, and displays the post-execution prompt information in a pop-up window after executing the subcommand corresponding to the subcommand configuration.

5. The method of claim 3, wherein, The data source comprises code gun reading, local reading, and network reading.

6. The method of claim 3, wherein, The subcommand code data comprises whether there is data, a test state, a test result judgment method, and an execution action.

7. The method of claim 6, wherein, The test states include: untested, tested, test passed, test failed; the test result judgment methods include: automatic, manual, self-check, external check; wherein "automatic" means judged by the embedded terminal, "manual" means judged by the tester manually, "self-check" means judged by the host computer test software according to test item configuration, and "external check" includes judgment by the host computer test software in combination with external equipment; and the execution actions include: unsetting, starting, stopping, reading, and writing.

8. The method of claim 6, wherein, The test command data packet and the test result data packet have the same data structure, and both include a packet header, a payload, and a check value; The packet header includes a synchronization field, a command information field, and a payload data length field, the command information field includes a command field and a sub-command field; the payload includes: a data field presence field, a test state field, a test result judgment method field, an execution action field, a sub-command data length field, and a sub-command data content field.

Images