CN1755643A - Software testing method - Google Patents

Abstract

The invention discloses a method for software testing, comprising the following steps: 1) establishing a connection with the software under test; 2) constructing a test command frame of a test case and sending the constructed test command frame to the software under test; 3) Generate the waiting frame of the test command frame, which contains the expected result of the test case in the waiting frame; 4) compare the execution result frame for the test command frame returned by the waiting frame and the software under test, If the two are consistent, the test result is judged to be passed, otherwise it is not passed. By using the method of the invention, the test efficiency can be improved and the cost of human resources can be reduced.

Description

A method of software testing

technical field

The invention relates to a method for testing software, in particular to a method for testing software with a communication interface based on script language.

Background technique

Currently, software is becoming more and more complex and its size is increasing. It is often necessary to develop a software in several versions. After detailed testing and bug modification of each version, the software will gradually stabilize and reach the usable level. The workload of testing each version of a large-scale software is very large. Today, with the increasing cost of human resources, how to reduce the workload of testing or automate most of the testing work is an important issue for those skilled in the art to study. topic.

At present, when using test tools to test software TCP/IP interfaces, it can generally be divided into three steps: data input, result output, and result comparison. First, the test tool sends a command frame to the software under test, and the software under test outputs a corresponding response message frame to the test tool according to the received command frame, and then compares the results. Currently, comparison of results needs to be done manually, ie manual testing.

In the manual test scheme, after the test tool receives the response frame sent by the software under test, it displays the response frame on the screen in a certain way, and the tester visually observes the content of the response frame and compares it with the expected result. If the received response frame is consistent with the expected result, the test result of the test case is passed. Otherwise it is not passed. In this scheme, the result comparison step is completed in the tester's brain, and some response frames are very complicated, and the result comparison is very laborious and error-prone, which makes the tester easily fatigued and the test efficiency is low.

Therefore, the existing technology has the disadvantages of low test efficiency, error-prone after long-time work, a large number of test engineers, and high labor costs.

Contents of the invention

The purpose of the present invention is to provide a method for software testing, realize automatic testing of specific software, improve testing efficiency, and improve testing accuracy.

To achieve the above object, the present invention provides a method for software testing, comprising the following steps:

1) set up the connection with the software under test; 2) construct the test command frame of the test case and send the test command frame constructed to the software under test; 3) generate the waiting frame of the test command frame, in the waiting frame Include the expected result of the test case; 4) compare the waiting frame with the execution result frame returned by the software under test, if the two are consistent, then judge that the test result is passed, otherwise it is not passed.

Preferably, the method for comparing the waiting frame and the execution result frame is: if each byte of the two frames is the same, the two frames are considered to be consistent; otherwise, they are inconsistent.

Preferably, the comparison method between the waiting frame and the execution result frame is: only compare the concerned fields, if the concerned fields are the same, the two frames are considered to be consistent, otherwise they are inconsistent.

Preferably, after the step 2), it further includes: setting the time to wait for the software under test to return the execution result frame, if within the set time, the execution result frame is not received, then it is judged that the test result is If not, otherwise step 4) is performed to compare the waiting frame with the execution result frame.

Specifically, the frame structure includes a frame header and a data area, the frame header is fixed in length, includes a command word field, and a data area length field, and the length of the data area is variable. Length specified.

Preferably, the communication interface of the software under test is a TCP/IP interface, an E1 line interface or a serial line interface.

Preferably, the method is used for testing the communication interface of the software under test.

Preferably, the test command frame is created and/or sent by a scripting language.

Preferably, the waiting frame is created by a script language.

Preferably, the scripting language is Tool Command Language (TCL) or scripting language "Dragon Snake" (python).

Using the method of the invention can avoid duplication of work in each version test, thereby improving test efficiency. And because the tool is not fatigued, as long as the test script is correct, the test result of the test tool is reliable, so the accuracy of the test can be improved and the cost of human resources can be reduced.

Description of drawings

Fig. 1 is a schematic diagram of the connection relationship between the test tool and the software under test applying the method for software testing according to an embodiment of the present invention;

Fig. 2 is the flowchart of an embodiment of the method for software testing of the present invention;

Fig. 3 is a schematic diagram of an embodiment of the frame structure of the frame used in the present invention.

Detailed ways

The preferred embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings, and the accompanying drawings are for illustration only, and are not intended to limit the protection scope of the present invention.

FIG. 1 shows a schematic diagram of the connection relationship between a testing tool and a software under test using a software testing method according to an embodiment of the present invention. The test tool is generally software, which can be on different hardware or the same hardware as the software to be tested. The test tool can run on an ordinary PC. If the software under test is a complete system, such as a router, the software under test and the test tool are on different hardware. If the software under test is pure software, it can be on the same computer. In the embodiment shown in Fig. 1, the automated testing tool of the method for software testing of the present invention is used to communicate with the software under test through the TCP/IP protocol, it sends a test command frame, receives the corresponding execution output of the software under test, and communicates with the software under test Expected results (in software testing, the expected results after executing a test case) comparison. In other embodiments, it can also be connected with the software under test through interfaces such as serial port lines and E1 lines.

Fig. 2 is a flow chart of an embodiment of the software testing method of the present invention. As shown in Figure 2, in one embodiment of the present invention, the specific steps that the method for software testing comprises are:

1. The initialization of the software under test; that is, the startup of the software under test. If the software under test is an embedded system, it includes hardware initialization and software startup, such as the initialization of the network port, the initialization of the TCP/IP protocol stack, etc.; if the software under test Software is pure software, it refers to the activation of the software.

2. Establish a connection with the software under test;

3. Construct and send the test command frame of the test case;

4. Generate the waiting frame of the above-mentioned test command frame, which contains the expected result of the test case in the waiting frame;

5. After receiving the test command frame, the software under test returns the execution result frame after a series of calculations or operations;

6. After receiving the execution result frame of the software under test, compare the execution result frame of the software under test with the waiting frame containing the expected result. If the two are consistent, the test result of the test case is PASS (pass), otherwise it is FAILED (Fail);

7. Repeat steps 3 to 6 until all test cases are executed.

The above steps are described in detail below.

Methods of establishing connections are well known. According to the communication interface of the software under test, the connection between the test tool and the software under test is established. Taking the testing of software with TCP/IP interface as an example, establishing a connection can be to establish a socket (socket) connection between the software under test and the test tool, establish a server socket (Server Socket) on one side, and establish a server socket (Server Socket) on the other. One party establishes a client socket (Client Socket). Can use TCL (tool command language, a kind of scripting language) extended command to establish socket connection, also can use other methods to establish socket connection, the method for these establishment sockets is known to those skilled in the art, So this article will not go into details. Of course, it is also possible to directly use TCP/IP instead of using a socket connection. In a word, any method known to those skilled in the art can be used to establish a connection between the test tool and the software under test.

After the connection is established, construct and send the test command frame. FIG. 3 shows an example of a frame structure of a command frame used in the present invention. As shown in Figure 3, the frame structure includes a frame header and a data area. The frame header has a fixed length, including frame number (indicating the number of frames), frame type (indicating binary or text type, value 0~1), command word (command meaning, 100~10000, four bytes), data area length, IP address, port number, etc., the length of the data area is variable, and is specified by the length of the data area in the frame header. For the command frame, the data area stores other parameters of the command except the command word (when needed). For example, if a test case is to start the OSPF protocol, and the command code for starting the OSPF protocol defined in the software under test is 1001, then the test tool constructs a command frame, and fills in 1001 in the command word field (this use case does not need to fill in the data area) . The frame structure of the waiting frame, execution result frame and command frame described later is the same. It should be noted that the frame structure shown in FIG. 3 is just an example, and various modifications can be made to it according to the principles of the present invention, which are obvious to those skilled in the art, so this article does not list them one by one.

In the step of constructing and sending the test command, constructing the command frame can be realized by using TCL extension commands NewCurFrame and FillCurFrame. Among them, NewCurFrame creates an empty frame, and FillCurFrame fills the empty frame created by NewCurFrame with the specified content. The so-called specified content is to determine the content to be filled according to the specific test case. Sending a command frame is implemented by the TCL extension command send. After sending the command frame, wait for the response of the software under test. Using the scripting language to create and send the command frame can modify the content of the command frame (and the waiting frame described later) more flexibly. Generally, there is no need to re-modify the source code and recompile the test tool during modification, which can effectively improve efficiency.

Then, create a waiting frame for placing the expected result, and fill the created waiting frame with the expected result of the test case according to the content of the test case. Still taking the test case of starting the OSPF protocol mentioned above as an example, if the software under test supports the OSPF protocol and has not started the OSPF protocol, after the test tool sends the command to start the OSPF protocol, if the software under test executes successfully, it will return a result (such as 0000), then in this example, the expected result is 0000. Fill 0000 into the data area of the waiting frame. The creation and filling of waiting frames are preferably realized by TCL extension commands NewWaitFrame and FillWaitFrame. Among them, NewWaitFrame creates a waiting frame for placing the expected result, which is to open up an area in the memory for storing the waiting frame. FillWaitFrame fills the created wait frame with the specified content, that is, assigns values to each field of the frame header, and stores the expected result in the data area.

After receiving the command frame, the software under test will perform a series of calculations according to the contents of the command frame, and return the execution result frame containing the execution result.

If the execution result frame returned by the software under test is not received within the specified time, the test case is considered to fail (FAILED). If the execution result frame is received within the specified time, it is compared with the previously created waiting frame. If the two are consistent, pass (PASS), otherwise fail.

Specifically, the comparison process is that after the test tool receives the execution result frame from the software under test, it opens an area in the memory to store the result frame; and then compares the execution result frame with the waiting frame. The method of byte-by-byte comparison can be used for comparison, that is, if each byte is the same, the two frames are considered to be consistent, otherwise they are inconsistent; the field of interest comparison method can also be used, that is, only the field of interest is compared, if the field of interest If the fields are the same, the two frames are considered to be consistent, otherwise they are inconsistent. Still taking the above-mentioned test case of starting the OSPF protocol as an example, you can only care about the contents of the command word field and the data area. If in the frame returned by the system under test, the command word field is the start OSPF command (1001), and the data If the field content is 0000, it is considered that the test case of starting OSPF is executed successfully.

Those skilled in the art should appreciate that the part of the TCL extension commands involved in the method of the present invention can also be implemented using other scripting languages, such as python (dragon and snake) language. Among them, programming in the python language can be found in "Learning Python" (ISBN: 1-56592-464-9, 384 pages) published by O'Reilly in April 1999 by Mark Lutz et al., and in May 2001 by O'Reilly "Python Standard Library" by Fredrick Lundh (ISBN: 0-596-00096-0).

Although the present invention is described by preferred embodiments, those skilled in the art should understand that the present invention is not limited to these embodiments, but various changes and modifications can be made thereto without departing from the essence of the present invention. Accordingly, the scope of the present invention is to be determined only by the claims and their equivalents.

Claims (10)

1. the method for a software test may further comprise the steps:

1) sets up and being connected of tested software;

2) the test command frame of structure test case and the test command frame of being constructed sent to tested software;

3) generate the wait frame of described test command frame, comprise the expected results of described test case in the described wait frame;

4) the execution result frame that returns of more described wait frame and described tested software at described test command frame, if both unanimities are then judged test result for passing through, otherwise for not passing through.

2. method according to claim 1, it is characterized in that the comparative approach of described wait frame and described execution result frame is: compare each byte of two frames, if described two each bytes of frame are all the same, then think these two frame unanimities, otherwise be inconsistent.

3. method according to claim 1 is characterized in that, the comparative approach of described wait frame and described execution result frame is: the field of relatively being concerned about only, if the field of being concerned about is all the same, then think two frame unanimities, otherwise be inconsistent.

4. method according to claim 1, it is characterized in that, in described step 2) further comprise afterwards: set and wait for that described tested software returns the time of execution result frame, if in the time of setting, do not receive described execution result frame, then judge test result for not passing through, otherwise execution in step 4) carry out the comparison of described wait frame and described execution result frame.

5. method according to claim 1 is characterized in that the structure of described each frame comprises frame head and data field, described frame head length is fixed, comprise command word field, data field length field, described data field length is variable, is specified by the data field length in the described frame head.

6. method according to claim 1 is characterized in that, described tested software has the communication interface of selecting from the group that comprises TCP/IP interface, Serial Port Line interface and E1 line interface.

7. method according to claim 6 is characterized in that, described method is used for the communication interface of described tested software is tested.

8. according to each described method of claim 1 to 7, it is characterized in that described test command frame is created and/or sent by script.

9. according to each described method of claim 1 to 7, it is characterized in that described wait frame is created by script.

10. according to Claim 8 or 9 described methods, it is characterized in that described script is Tool Command Language or script " dragons and snakes ".

Images