Overview
Automated tests play back a recorded (or programmed) sequence of user actions
that cover a certain area of the tested application.
To get larger coverage, you
can perform tests with different input data. Suppose, for example, you test an
input form of an application. After you have recorded a script, it contains only
values that you entered during the recording. Most likely, data you have
specified does not cause errors in the application, but other data may cause
them. Data-driven testing allows you to test the form with a different set of
input values to be sure that the application works as expected.
Contents:
- http://www.onestoptesting.com/automation-framework/data-driven-testing/introduction.asp - Introduction
- http://www.onestoptesting.com/automation-framework/data-driven-testing/frameworks.asp - Data Driven Automation Frameworks
- http://www.onestoptesting.com/automation-framework/data-driven-testing/scripts.asp - Data Driven Scripts
- http://www.onestoptesting.com/automation-framework/data-driven-testing/support.asp - TestComplete's Support for Data-Driven Testing
introduction
Data-driven testing means that scripts read data from an
http://www.onestoptesting.com/automation-framework/data-driven-testing/introduction.asp# - - external Data Driven Scripts
Data driven scripts are those application-specific scripts captured or
manually coded in the automation tool’s proprietary language and then modified
to accommodate variable data.
Variables will be used for key application input
fields and program selections allowing the script to drive the application with
external data supplied by the calling routine or the shell that invoked the test
script.
TestComplete's Support for Data-Driven Testing
Since DDT itself is very straightforward, TestComplete’s direct support for
the technique is likewise quite straightforward.
If you examine the TestComplete
online help, under “data-driven testing”, you’ll find a fairly long help topic
with links to external pages on the subject, but also links to five script
routines. It’s worth noting that while these methods are listed with the DDT
topics, they’re not the only routines you’ll need to perform DDT, but for now
we’ll look at those five.
They are GetCSVCount, GetCSVItem, CallMethod, SetValue
and GetValue. The first two methods are ones that you’ll use quite a bit in DDT,
the other three will see less frequent use unless you are getting into some
fairly robust DDT scripting.
GetCSVCount and GetCSVItem work with comma-separated strings in order to
provide an easy way to get to the values contained within the strings. This is
called “parsing”. A comma-separated value (CSV) string might look something like
this:
You can see that each element of this string is separated by a comma. Each
individual element of the string is a called a “field” or a “value”. The
GetCSVCount and GetCSVItem methods work with strings like this. If we passed
this string in to the GetCSVCount function, we’d get a return value of 10. There
are ten discreet values in this CSV string. In addition, if we wanted to the get
the customer’s first name, we could use GetCSVItem to do that.
Here’s an important thing to keep in mind: GetCSVItem is what’s known as
“zero-based”. That means that the first item in the CSV string is considered
number 0 rather than number 1. Likewise, if we wanted the last item, it would be
item number 9, not number 10. Thus, if we wanted the customer’s first name, we’d
have to ask for item number 2, not number 3, thus:
So, with these two functions, we’re able to easily retrieve values from CSV
files, something that is quite useful if our external DDT data is in CSV text
files or spreadsheets. Returning again to our customer/orders example, we might
see the following. (This is pseudo-code only.)
function ReadExternalData(aFileName) { var lsLine var lsCustomerName, lsAddr, lsCity, lsRegion, lsPostalCode openFile(aFileName) while not EOF(aFileName) { lsLine = readLine(aFileName) if (GetCSVCount(lsLine) == 5 { lsCustomerName = GetCSVItem(lsLine, 0) lsAddr = GetCSVItem(lsLine, 1) lsCity = GetCSVItem(lsLine, 2) lsRegion = GetCSVItem(lsLine, 3) lsPostalCode = GetCSVItem(lsLine, 4) EnterCustomerRecord(lsCustomerName, lsAddr, lsCity, lsRegion, lsPostalCode) } } closeFile(aFileName) } function EnterCustomerRecord(aCustomerName, aAddr, aCity, aRegion, aPostalCode) { var p, w p = Sys.OrdersProcess w = p.MainForm w.Activate() w.ToolButton5.Click(6, 7) w = p.OrderFrm w.Activate() w.CustomerName_Edit.wText = aCustomerName w.Street_Edit.wText = aAddr w.City_Edit.wText = aCity w.State_Edit.wText = aRegion w.Zip_Edit.wText = aPostalCode w.OKButton.Click() validateRecordEntry() }
Don’t worry about trying to make this code actually work – it’s rather
abstracted and is for demonstration only, but your actual DDT code might be
similar. What this small amount of code does is very powerful and serves as a
great example of a standard DDT scenario. While it’s also possible to do more
complex tasks, which I’ll examine in future papers, this is a good starting
place.
As for the other three methods covered in the help (CallMethod, SetValue and
GetValue) I won’t talk about those now – they’re not necessary for this http://www.onestoptesting.com/automation-framework/data-driven-testing/support.asp# - - primer
on DDT.
The part of this whole process that’s not clearly covered is that of actually
reading the external data. That is in part because there are so many options.
TestComplete can read your DDT data from text files, spreadsheets, database
tables or from internal data arrays. To access your data, you can use ADO, OLE
automation or standard text file access methods. Many of these storage options
and access methods are shown in the DDT demo project included with TestComplete,
which we’ll cover shortly. For now, just plan on getting to your data whichever
way is most comfortable
------------- amar
|