A TFTP-based embedded software testing device and method

Abstract

The present invention relates to an embedded software testing device and method based on TFTP protocol, wherein the device comprises a host computer and a slave computer, wherein the host computer is connected with the slave computer through TFTP protocol; wherein the host computer transmits messages with the slave computer through TFTP protocol, the host computer dynamically manages pile codes, the slave computer parses the pile codes, realizes that the pile codes are opened during the software operation process, and executes the predetermined test function. Compared with the prior art, the present invention has the advantages of improving test efficiency and realizing automatic test by dynamically opening the pile codes.

Description

Technical Field

[0001] The invention relates to an embedded software testing technology, in particular to an embedded software testing device and method based on a TFTP protocol. Background Art

[0002] Embedded systems are widely used in railway signal systems. VCU (Vital Control Unit) is a security development platform that provides functions such as 2-out-of-2 and hot standby redundancy. Upper-level applications can call the interfaces provided by the platform to implement their own functions. It has been applied in railway signal systems, such as input and output control units, signal light control units, etc.

[0003] When testing an embedded platform, a large amount of test stub code needs to be inserted into the source code, and the compilation and burning process is time-consuming, so fixed stub code cannot be used. In this case, an automated testing platform needs to be introduced to enable the upper computer to send commands, and the lower computer to parse the commands. Then, the functions we need are implemented according to the parsed commands, and the function of automatically recording test logs is implemented.

[0004] In embedded systems, the system resource utilization is quite sensitive, and the test platform cannot take up too many resources. Therefore, how to conduct testing so as not to take up additional system resources has become a technical problem that needs to be solved. Summary of the invention

[0005] The purpose of the present invention is to provide an embedded software testing device and method based on TFTP protocol in order to overcome the defect of the above-mentioned prior art, which can be applied to embedded platform software testing, improve test efficiency and realize automated testing by dynamically opening pile codes.

[0006] The purpose of the present invention can be achieved by the following technical solutions:

[0007] An embedded software testing device based on TFTP protocol comprises a host computer and a slave computer, wherein the host computer is connected with the slave computer via TFTP protocol;

[0008] The host computer transmits messages to the slave computer through the TFTP protocol, dynamically manages the pile code through the host computer, and the slave computer analyzes the pile code to open the pile code during the software operation process and execute the established test function.

[0009] Preferably, the host computer includes:

[0010] Use case management module, used to manage use cases that need to be executed;

[0011] The stub management module is used to edit the file information that needs to be sent by the use case for parsing by the lower computer.

[0012] Preferably, the use case management module uses a python script to send information to the lower computer.

[0013] Preferably, the lower computer includes an MVCU (Master Vital Control Unit) and an SVCU (Slave Vital Control Unit) which are connected to each other via a TFTP protocol.

[0014] Preferably, the MVCU and SVCU both include:

[0015] The stub parsing module is used to parse the file and open the corresponding stub after receiving the message command sent by the upper computer through the callback function;

[0016] The stub code module is used to execute the stub code at runtime if the corresponding stub is opened. The stub code can change a certain value of the software under test and send print information.

[0017] Preferably, the pile analysis module is called periodically.

[0018] Preferably, the stub code module writes corresponding functions to implement different functions according to specific needs.

[0019] A testing method using the embedded software testing device based on the TFTP protocol, the method specifically comprises the following steps:

[0020] Step S1, preparation of lower machine pile list: compile lower machine pile;

[0021] Step S2, write the lower machine stub code: write the required stub function according to actual needs;

[0022] Step S3: Create a use case folder on the host computer and name it according to the use case file name. Each folder can store multiple steps of a use case.

[0023] Step S4, host computer script editing, the host computer shall write the corresponding pile script file and put it in the corresponding use case folder. The script content can be customized by the user. According to different file contents, the customized function is realized, which shall correspond to the parsed script content of the lower computer in step S2;

[0024] Step S5, the upper computer script executes. After the upper computer script is written, the use case script content is transmitted to the lower computer through the TFTP protocol. If multiple use cases need to be executed, the names of all use case files to be executed can be written in all executed python files;

[0025] Step S6, lower computer script parsing: after receiving the script, the lower computer parses the script content. If the script content is an MVCU script, execute step S7; if the script content is an SVCU script, execute step S8;

[0026] Step S7: After receiving the script information, the MVCU parses the script content and implements the function defined in step S2;

[0027] Step S8: After receiving the script, the lower computer parses it and finds that it is basically an SVCU script, and then forwards the script information to the SVCU; after receiving the script information, the SVCU parses the script content to implement the function defined in step S2.

[0028] Preferably, the lower machine piles are listed in an enumerated manner, identified by the test case number and step number, and a unique identifier is assigned to each test pile, which is convenient for corresponding to the test case, so that the subsequent regression is to automatically execute the test case that needs to be executed.

[0029] Preferably, the stub code can change function variables, or implement a certain function through a function. According to different user requirements, the functions implemented by the stub can be customized to meet test requirements.

[0030] Compared with the prior art, the present invention has the following advantages:

[0031] 1. The present invention can realize dynamic injection of pile code, reduce burning and compiling time, and realize dynamic opening of multiple piles;

[0032] 2. The present invention adopts TFTP protocol transmission, which occupies relatively few resources and does not affect the performance of the tested software;

[0033] 3. The present invention adopts TFTP protocol transmission, the file content can be customized according to user needs, and the scalability is relatively strong;

[0034] 4. The present invention provides use case management to facilitate subsequent test regression;

[0035] 5. The present invention supports the sequential execution of multiple use cases and can realize automated testing;

[0036] 6. The present invention can be applied to different embedded systems and has a wide range of applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 It is the software flow chart of the present invention;

[0038] Figure 2 It is a structural block diagram of the present invention;

[0039] Figure 3 Schematic diagram prepared for the lower machine stub code;

[0040] Figure 4 This is a schematic diagram of the host computer pile command. DETAILED DESCRIPTION

[0041] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0042] In embedded systems, the resource utilization of the system is relatively sensitive, and the test platform cannot occupy too many resources. Since the TFTP protocol provides a simple and low-cost file transfer service, the VCU uses the TFTP protocol for external communication. In order not to occupy additional system resources, the test platform also uses the TFTP protocol.

[0043] The present invention adopts the mode of TFTP to transmit the message, dynamically manages piles through the host computer, and the lower computer parses the pile code, realizes that the pile code is opened in the software running process, and performs the predetermined function. Between embedded internal, in order to save resource cost, also adopt the transmission mode of TFTP, such as Figure 2 TFTP transfers data in the form of files, so the file content can be easily changed and the content to be transferred can be defined according to user needs, which improves the scalability of the platform.

[0044] like Figure 2 As shown, the embedded software testing device based on the TFTP protocol of the present invention comprises a host computer and a slave computer, wherein the host computer is connected to the slave computer via the TFTP protocol;

[0045] The host computer transmits messages to the slave computer through the TFTP protocol, dynamically manages the pile code through the host computer, and the slave computer analyzes the pile code to open the pile code during the software operation process and execute the established test function.

[0046] The main modules of the host computer (running on PC software) are as follows:

[0047] 1) The use case management module mainly manages the use cases that need to be executed, and uses Python scripts to control the sending to the lower computer.

[0048] 2) Stub management module, edits the file information that needs to be sent by the use case for parsing by the lower computer.

[0049] The lower computer (the tested software and stub code) has the following main modules.

[0050] 1) The pile parsing module is called periodically. After receiving the message command sent by the upper computer through the callback function, the lower computer will parse the file and open the corresponding pile.

[0051] 2) Stub code module: During runtime, if the corresponding stub is opened, the stub code is executed. The stub code can change a certain value measured by the software under test, send print information, etc. According to specific needs, corresponding functions can be written to implement different functions.

[0052] The present invention realizes dynamic stub code management, occupies less resources, and does not affect the performance of the tested software. The flow chart is shown in FIG. Figure 1 ,include:

[0053] Step S1, prepare the lower machine pile list: write the piles of the lower machine. The lower machine piles are listed in an enumerated manner, identified by the test case number and step number, and a unique identifier is assigned to each test pile, which is convenient for corresponding to the test case, so that the subsequent regression is to automatically execute the test case that needs to be executed, such as Figure 3 shown.

[0054] Step S2, write the lower machine stub code: write the required stub function according to actual needs. The stub code can change function variables, or implement certain functions through functions. According to different user needs, the functions implemented by the stub can be customized to meet the test requirements, such as Figure 3 shown.

[0055] Step S3, create a use case folder on the host computer: it can be named according to the use case file name. Each folder can store multiple steps of a use case to facilitate use case management.

[0056] Step S4, host computer script editing: The host computer needs to write the corresponding stub script file and put it in the corresponding use case folder. The script content can be customized by the user. According to different file contents, customized functions can be implemented. It must correspond to the parsed script content of the lower computer in step S2. Figure 4 shown.

[0057] Step S5, upper computer script execution: After the upper computer script is written, the use case script content is transferred to the lower computer through the TFTP protocol. If multiple use cases need to be executed, the names of all use case files to be executed can be written in all executed python files. The specific process is as follows Figure 4 .

[0058] Step S6, lower computer script analysis: After receiving the script, the lower computer analyzes the script content, which is an MVCU script, and measures local reception.

[0059] Step S7: Implement the function defined in step S2 according to the parsed content.

[0060] If you need to transfer TFTP messages to Figure 2 In the SVCU, the following steps are taken:

[0061] Step S1-1: Same as steps S1-S6 above;

[0062] Step S1-2: After receiving the script, the lower computer parses it and finds that it is basically an SVCU script, and then forwards the script information to the SVCU.

[0063] Step S1-3: After receiving the script information, SVCU parses the script content. If it is an SVCU script, it is received locally to implement the function defined in step S2. Specific embodiments

[0065] Through step S1, establish the use case list typedef enum of the lower computer

[0066]

[0067] Through step S3, a folder named SwRT-0001 is created on the host computer, and then through S4, the script information of the host computer is written. The script information is: CONN (SYS.A), which is sent to the system A system; WAIT ("Abe-start") waits for the lower computer to send Abe-start information. When the upper computer receives the Abe-start information, it executes TFTP ("00010111", 6); after the upper computer script information is ready, through step S5, the script operation is executed, and the script content is sent to the lower computer according to the script information; after the lower computer receives the script information, the script information is parsed through step S6, and 0001 represents the first use case 01 represents the first step, and 11 represents that both CPUA and CPUB of the lower computer will open the stub; after the script is parsed, the state of SwRT_000101 is set to TRUE through step S7. When the code is executed to the stub insertion position, the parameter of Runmode will be changed to 1. If you need to close this stub, you can modify the stub script to TFTP("00010100",6) through step S4, and then send the script information again through step S5. When the lower computer receives the script information, it parses the script through step S6, and then sets the state of SwRT_000101 to FALSE through step S7, and the software will not change the value of Runmode.

[0068] If the execution is automated, in step S5, multiple use cases are written into the execution script, and the use cases can be executed sequentially.

[0069] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed by the present invention, and these modifications or replacements should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be based on the protection scope of the claims.

Claims

1. An embedded software testing device based on TFTP protocol, characterized in that: It includes a host computer and a slave computer, wherein the host computer is connected to the slave computer via a TFTP protocol; The host computer transmits a message between the TFTP protocol and the slave computer, dynamically manages the pile code by the host computer, and the slave computer parses the pile code to realize that the pile code is opened during the software operation and executes a predetermined test function; The host computer comprises: Use case management module, used to manage use cases that need to be executed; The stub management module is used to edit the file information that needs to be sent by the use case for analysis by the lower computer; The use case management module uses a python script to send information to the lower computer; The lower computer includes an MVCU and an SVCU connected to each other via the TFTP protocol; the MVCU and the SVCU each include: The stub parsing module is used to parse the file and open the corresponding stub after receiving the message command sent by the upper computer through the callback function; The stub code module is used to execute the stub code at runtime if the corresponding stub is opened. The stub code can change a certain value of the tested software and send print information. The pile analysis module is called periodically; The stub code module is used to write corresponding functions to realize different functions according to specific needs.

2. A testing method using the embedded software testing device based on the TFTP protocol according to claim 1, characterized in that: The method specifically comprises the following steps: Step S1, preparation of lower machine pile list: compile lower machine pile; Step S2, write the lower machine stub code: write the required stub function according to actual needs; Step S3: Create a use case folder on the host computer and name it according to the use case file name. Each folder can store multiple steps of a use case. Step S4, host computer script editing, the host computer shall write the corresponding pile script file and put it in the corresponding use case folder. The script content can be customized by the user. According to different file contents, the customized function is realized, which shall correspond to the parsed script content of the lower computer in step S2; Step S5, the upper computer script executes. After the upper computer script is written, the use case script content is transmitted to the lower computer through the TFTP protocol. If multiple use cases need to be executed, the names of all use case files to be executed can be written in all executed python files; Step S6, lower computer script parsing: after receiving the script, the lower computer parses the script content. If the script content is an MVCU script, execute step S7; if the script content is an SVCU script, execute step S8; Step S7: After receiving the script information, the MVCU parses the script content and implements the function defined in step S2; Step S8: After receiving the script, the lower computer parses it and finds that it is basically an SVCU script, and then forwards the script information to the SVCU; after receiving the script information, the SVCU parses the script content to implement the function defined in step S2.

3. The testing method according to claim 2, characterized in that: The lower machine piles are listed in an enumerated manner, with the test case number and step number as identifiers, and a unique identifier is assigned to each test pile, which is convenient for corresponding to the test case, so that the subsequent regression is to automatically execute the test case that needs to be executed.

4. The testing method according to claim 2, characterized in that: The stub code can change function variables, or implement a certain function through a function. According to different user requirements, the functions implemented by the stub can be customized to meet test requirements.

Images