Rookie understanding about data-driven and keyword-driven differences

Do manual testing for a long time, always want to the direction of automation, see the Forum on various articles, controversial and so on, said from the data driven to the keyword drive, the data driven down to nothing, the key word driver said so deified, but I feel are the same ah, are the object parameterization, and then the data (parameters) passed in, Executes, and then returns the result

Here are some arguments to digest yourself.

Excerpt from some ingenious arguments:

the Phililschen of the 51testing forum:

　
"What is data-driven?" A large part of the people must think that data driven is to write something that needs to be parameterized in Excel, and then call it when running a script. If I tell you that this is actually not data driven,
And just a higher level of parameterization, you would certainly be surprised. Now let me explain: why first call data-driven, then it must have a driving meaning, such as you can use Excel to control the test of the business flow. The answer is no. So how do you drive it? So we put the test data in a separate file, just a high-level argument. While data-driven, you must have data to control the business flow of the test. For example, you test a Web application, there are a lot of pages, you can use a data to control each time it is another page under which to work (that is, through the data to navigate to the corresponding page). It is a low-level version of the keyword driver, he controls the function level, and the keyword is control action level. So data-driven should be able to control the entire test "

the dreamever of the 51testing forum:

"The data-driven itself is not an industry-standard concept, so there are several explanatory versions in different companies. First of all I agree with the landlord of the data-driven view, that is, if we just put the test data in the data file, this is a more advanced parameterization. In fact, I'm more inclined to interpret data driven as a pattern or an idea.

For data-driven discussions, we might as well put aside the QTP. Whether it's automated testing or manual testing, we need to design test cases, prepare test data, and separate test cases from data, and it's more efficient to run multiple sets of test data on a set of test cases. I believe we should all agree on this point.

　
Then we might as well look at the manual test scenario: When a manual tester a discovers that there is a test data set in the test data store directory, he realizes that the test case should be executed immediately and enter the
Set new test data. In fact, the test data changes triggered a test behavior. (Some might say that our company is not doing this, note that we are not talking about the actual test management, we are on the test model
Be abstracted). If we are more abstract, we can see that when the test data changes, the test cases are executed (whether a is active or leader call notification), and according to the pre-defined
Rules to read test data and execute test cases. So is this the case that we can understand as a kind of data-driven? This means that as long as new test data or test data changes, a will
To execute the test case. The purpose of this process is to have all the test data input and return the corresponding output.

If everyone agrees that the above scenario is a data-driven test
example, we can interpret the data drivers in the automated tests as follows: The test data is automatically read by the machine, then the test appliance runs the test script, executes the test case, and follows the pre-set parameters
Read the test data and return the test results. The goal is to have all the test data input and return the output to verify that the input and output of the data meet the expected values. The test data here includes not only the business
Data, as well as some action keywords or decision keywords, to provide enough information to let the test tool know what script to call and how to handle various situations. Compared to different test tools, the representation
May be different, QTP provides a keyword view and a data table, robot presents the concept of a decision table, watir the words themselves do not have any special mode, fully see what the tester has designed the framework
Kind of. is essentially a different message-driven performance, such as the example of the manual test just now, the test data changes we can think of it as a message, received this message a will begin to execute the test.
”

the jackmail of the 51testing forum:

"Driven in data-driven
The word, you can simply understand the direction and guide what. Results. Is the test data determines the test results, which is called data-driven, QTP implementation of data-driven functions, models, feature,
Features, nothing but a word, how to say no problem, with QTP you can simply complete the data-driven method you want to implement the test, he is the implementation of the XX function.

The keyword driver is the keyword that determines the result. The keyword in QTP is the name of the test object in step (Object method property, or value (test data)). Changing the name of the test object determines the change of the result. Some people used to write the framework is to import objects from Excel tables and exports, they are the implementation of keyword-driven.

What drives, is what determines the outcome. The result is fixed, because the drive data changes, resulting in different results, not so complex. In fact, the concept is determined by people, less to the dead, understand a general meaning on the line. ”

finally cite a keyword-driven understanding of the article , after all, this is QTP the main push of things

The initial use of QTP is simple recording, and then modify the script, the disadvantages are as follows:

1. Application software must have a certain degree of stability, and the entire business process must be fully implemented, otherwise sequential recording of the entire performance.

2. The maintenance cost of automation scripts is very high

3. The reusability of automation scripts is poor

With the advent of keyword-driven concepts, everything takes the object as a starting point, which is a bit like programming language from process to object-oriented transformation, in the QTP of the specific implementation method is:

1. Manually add the objects involved in the test to the object library in a single program interface

2. Writing automated test scripts in the expert view based on objects in the object library

The obvious advantages of doing this are:

1. The control of the script is very strong, the modularity of the organization is also better

2. It is possible to build test scripts before developing fully implementing all of the business process functions, taking on a relatively large initiative, providing more space for time-based arrangements, one word summed up: "Test-First"