Automation Guide Application testing Testing with databases

 Database use cases

Database use cases

TestArchitect offers a number of built-in actions and automation methods that allow for tests to connect to, and query, SQL-compliant databases. This allows for an expanded form of data-driven testing beyond that which relies on TestArchitect’s proprietary data sets. It also expands the possibilities for performing tests on database-dependent applications. This topic presents a few of the typical test configurations involving SQL-based databases, along with specific examples.

Actions

TestArchitect provides the following built-in actions for working with SQL-compliant databases. They are listed in the typical order of their workflow:

1. create connection string: Generate a connection string for a specified database on a given host.
2. connect database: Open a database connection using a connection string.
3. use database: Specify a database against which the ensuing SQL action lines are to be applied.
4. execute sql: Execute an SQL command against the currently in-use database; optionally, store returned data into one or more data sets.
5. disconnect database: Close the database connection.

Use cases

1. Data-driven testing. Connect your test to a database and use it in the same manner in which you typically would use a data set: to supply the test with records of input values for your AUT, along with expected outcomes for comparison with AUT outputs. (See Example - Case 1.)
2. Test the AUT’s handling and storage of data. For database driven applications, interact with the AUT and then query its database to ensure data is being written to it correctly. For example, test a database driven application by entering test records through the GUI, then have your test interface directly with the database to verify the records. (See Example - Case 2.)
3. Test the AUT’s response to database-sourced data. Ensure that a database driven application responds properly to the contents of its database. (For example: insert multiple records to the database, then query the AUT to verify that it properly handles the new content.).(See Example - Case 3.)

Example - Case 1

This example demonstrates a data-driven test whose data is obtained through SQL query to an ODBC-compliant database.

The test is of a hash function generator, to ensure that the codes it produces are correct. (The application under test (AUT), a web-based MD5 hash function generator, is available at www.miraclesalad.com/webtools/md5.php.)

Data records supplied to the test consist of several fields, accompanied by a hash code. The Hash field holds a known-valid code which has been generated by an MD5 hash function applied to a string which consists of the concatenation of the fields preceding the code:

In the test, the entire table holding the data records is queried and written to a TestArchitect data set. Then the test iterates through each data set record, concatenates all the non-Hash fields, and submits the resulting string to the String field of the AUT:

The md5 submit button is then clicked, whereupon the application computes and displays the MD5 hash code for the string. That hash code is then checked against the Hash value stored with the original record, so that only a complete match results in a Passed checkpoint. The process continues until all the records from the database have been run through the AUT.

Test Lines

Example - Case 2

This example tests a database-driven application. It first interfaces with the AUT through its user interface, inducing the application to modify its database. Then it queries the database directly to verify the accuracy of the changes made to it.

The database table with which the AUT interacts contains simple records consisting of two fields: a numeric index (key) and a stored string (string_store).

A simple entry form allows records to be added to this table:

To keep this example simple, the use of any data repositories is limited to just the one belonging to the AUT. Records submitted by the test are generated on the fly, rather than stored in another database or data set. This is done through the use of a pseudo-random generator supplied as a user-defined action, generate values. On each invocation, generate values returns both a “random” 5-digit numeric value (for the key), and a 20-character ASCII string (for string_store). These values are derived from a 5-digit seed supplied to the action.

In the test case (shown below), generate values is called multiple times within a loop to produce multiple records. Each record is supplied to the AUT by means of the user-defined action write AUT record (not shown). The 5-digit output (working seed) of each execution of generate values is used not just to supply the key value for the AUT record, but also to provide the seed for generate values in the next iteration of the while loop.

If the AUT is functioning correctly, the pseudo-random records it supplies to its database will look something like this:

Once the first loop completes and all the records have been supplied to the AUT, a second loop, with the same number of iterations, is used to directly verify the contents of the database. The output of generate values is deterministic, meaning that a given seed value is always guarateed to produce the same results. Hence, after supplying records for the AUT to add to its database, generate values can be used again in the verification loop to ensure that the database holds the correct values. All that’s required is that the same original seed value be supplied to it at the start of that loop.

Test Lines

Example - Case 3

In the last example, our test worked through the AUT’s user interface to get the application to modify its database; we then queried the database directly to validate the application’s actions. In this example, the test configuration is the same: an AUT supported by an SQL-compliant database. But now we’ll work in the opposite direction: our test will directly modify the database, and then we’ll work with the application’s UI to ensure that it responds correctly to the database changes.

The generate values action of the previous use case is used once again to provide records for the test to write out to the database. The test begins by connecting to the database, then begins a while loop in which generate values is called, followed by the built-in execute sql action, which writes the new record to the database.

Once the first loop completes and several records have been written to the database, a new while loop is run to query the AUT and verify its proper handling of the database changes. Within the loop generate values is run again to produce the same sequence of values as it did previously. The user-defined action check AUT record (not shown) is called, with the key and string value values. It accesses a simple report form from the AUT and supplies it with the key to have it retrieve the String_value from the database.

A checkpoint then compares the retrieved database String_value to the value of the string value argument supplied to the action. The action then exits and the while loop is repeated for all the new records.

Test Lines