Robotframework Interface Message Test-----(iii) Demo's enhanced version (data-driven testing)

In the previous Robotframework interface message Test-----(ii) on the basis of the upgrade of the demo, the XML format of the interface is saved in the XML file, and then if the program adds an interface, it can be added in the XML file without modifying the other modules in the automation test. And then in the tool add case, but the interface value of the data are all directly in the case input, that is, each additional test cases, you need to add a box in the tool, test data is always within the tool control, This makes it very uncomfortable for me to have previously managed the test data with Excel, and I always feel that I have to put the data in Excel and then implement the data-driven test.

Around this idea, a general business flowchart is given first.    

. xml: A standard specification document for XML definitions for each interface. As follows:

. xls: Test data for each interface, saved within XLS. as follows:

From the XML file to read the interface fields, and then read the corresponding data from Excel, and then assemble into SENDBUF, call the message processing module, the message is pre-processing (implemented in the DLL, the session layer to add some data, and then encrypt operations) to the server side, after the server processing the message, Return the response message, the message processing module will parse the message, extract the status code, the actual status code and the expected status code comparison, testing completed. On the basis of (b), add an Excel processing module, the data in Excel read all into the list, the simple code is as follows:

defreaddatafromexcel (): Data= Xlrd.open_workbook ('D:\logincase.xls') Table=data.sheets () [0] nrows=table.nrows Nclos=Table.ncols Listall=[]     forRowinchRange (3, nrows): Alist=[]        forColinchRange (1, Nclos): Alist.append (Table.cell (row,col). Value) Listall.append (alist)returnListall

Then modify the case within the RF tool as follows:

To this, the data has been stripped from the case into Excel, only read a piece of data, if you want to read multiple data, directly in the inside to write a simple for loop, so I thought I fully realized the data-driven test, happy for several days ....

One day accidentally point to a master's blog, looked, seems to feel like a bit of truth, as I did above, even if the implementation of data-driven testing it? So what is data-driven testing?

A data-driven test reads test data from a data file (such as an Excel file, text file, XML file, or database), and then passes the variable into a pre-written or recorded test script that can pass both the test input data and the validation data for the test output. The test data appears only in the data file, and the test script is responsible for testing the logical business process, test status, and data file reads, so the test data and test scripts are stored separately. Each row in the data file represents a set of test data that is injected into the same test flow by looping through each row in the data file for repeated test validation.

Comparison of the manual test scenario: When a manual tester a discovers that a test data is in the storage directory with a set of test data, he realizes that the test case should be executed immediately and enter this new set of test data. In fact, the test data changes triggered a test behavior. Again, you can see that when the test data changes, the test cases are executed and the test data is read and the test cases are executed according to predefined rules. So can we understand this as a kind of data-driven? This means that as long as new test data or test data changes, a will execute the test case. The purpose of this process is to have all the test data input and return the corresponding output.

Obviously, this concept emphasizes two points: first: test data and test script, module separation; second: The program reads the test data, automatically completes the test flow of some columns, and returns the test results. Most of the time, most of us do the 1th, ignoring the 2nd; Most of them can implement parametric processing of test data, but they cannot complete the test cases automatically. After understanding the concepts of data-driven testing, self-examination felt that it was impossible for me to write completely automatically, at least the following issues:

First: Test a interface, how to determine which sheet data to use?

Second: Test a interface, there are 10 use cases, placed in an RF case management, then the 10 use cases, smoke test as long as the run 3, integration requires 10, how to set? And what if there is a test case that fails with the whole cases in the failed state?

In view of the above 2 issues, I have actually solved the problem before, since the ID can determine the standard format of the interface XML, then you can use this ID as the test data sheet name, you can get the specific interface sheet data. The second way to run a few case to do, in each XLS last column plus a column, whether to execute the column, read no, no data can be sent. But the second small problem, in the RF can not be solved, should be due to the limitations of the tool itself, an RF case regardless of how many test cases actually run, as long as a failure, is all the failure state. So there are 2 types of management of test cases within the RF:

The first: A suit is an interface, and a case is one of the test cases.

Second: A suit is a module, and a case is an interface.

Obviously the first one can be more convenient to control the granularity of execution, but each test case has to create a new cases, the test data is written directly in the case, it is a bit troublesome. If you encounter an interface with forty or fifty test cases, you can only hehe ~ ~ ~ The second one is not too good to control the granularity of execution, but to manage the data within Excel, you can better manage the test data. And RF has been said to achieve data-driven testing, but has not found the relevant information, most of them are realized to this layer basically did not have the following, read a lot of documents, the basic is almost over, it seems also time to look at the official various documents ~ ~ ~

Robotframework Interface Message Test-----(iii) Demo's enhanced version (data-driven testing)