DruidaTest - testing Database applications using an approach based on business Rules and user Interface-DAtabase interaction
DruidaTest is a standalone application for specification based testing of database applications that have an user interface.
Given a model of the user interface and a set of business rules that specify the behaviour of the application, DruidaTest generates
a set of rules that represent the set of test cases (both user inputs and test database) that achieve MCDC coverage (SQLFpc coverage).
DruidaTest allows evaluating the coverage by running the rules and provides the information that the tester needs to complete the test cases
and the test database in order to achieve better coverage. It is built on top of SQLFpc Web Service.
The basic concepts are introduced in the paper:
Contents:
Download
Download here the latest version.
Next, unpack the ZIP file. The following filles will be present in your directory:
- druidatest-all.jar: Java archive for the application and its dependencies.
- druidatest.bat, druidatest.sh: Launcher command file.
After running it for the first time, the following files are generated:
- druidatest.settings.xml: Remembers the last used configuration .
- druidatest.error.xml: If an error occours, some debug data is included in this file.
If you notify a software problem report you should include this file in order to
facilitate the detection of the problem.
First at all, you must be sure that you have your database running and the adequate
jdbc database driver is in your default directory. Here you can find the drivers
for some databases (maven):
Quick Start
Launch the main class of druidatest.jar using the following java command (where drivername.jar is the name of the vendor's database driver file. Note that you don't need specify
a driver name if your are going to use the jdbc-odbc bridge driver):
java -classpath drivername.jar;druidatest.jar in2test.application.druidatest.DruidaTest
Alternatively, you may edit the druidatest.bat script file specifying this
command and then run the script.
The following window will be displayed:
Procedure:
- Fill in the information that is needed to connect the database using jdbc (Database connection info at the left of the window)
- Fill in the test assignment specification in two steps in the IDMDL Specification & IRM Rules textbox:
-
- Fill in the test assignment model in IDMDL syntax in order to generate the IDM model
- Fill in the rules specification in IRMDL syntax just below
- At the bottom of the screen, click Compile Specification for generating the coverage rules obtained from the specification
- After compiling the model, FPC Rules can be evaluated in two ways:
-
- All FPC Rules for all IRM Rules by clicking Run Coverage Evaluation (All)
- All FPC Rules for the selected IRM Rule by clicking Run Coverage Evaluation (Rule)
- After evaluating the rules, FPC Rules can be reseted in two ways:
-
- Reset all FPC Rules for all IRM Rules by clicking Reset Coverage (All)
- Reset all FPC Rules for the selected IRM Rule by clicking Reset Coverage (Rule)
Specifying connection info
The information required to access the database is explained below:
- Database connection info required for getConnection(): You must specify the driver
class name and connection url along with the access credentials. The driver class
name and connection url is database vendor specific. Some examples of connectinons
are:
| Database Vendor | Class Driver Name | Connection url |
|---|
| Oracle (OCI Driver) |
oracle.jdbc.driver.OracleDriver |
jdbc:oracle:oci:@<SERVER>:<PORT>:ORCL |
| SQL Server |
com.microsoft.sqlserver.jdbc.SQLServerDriver |
jdbc:sqlserver://<SERVER>:<PORT>;database=<DATABASENAME> |
The option Connections in the menubar facitlitates the configuration for
some typical connections.
- Database connection info required for getMetadata(): In order to obtain the database schema, the Java getMetadata methods are used, which require additional information about the database catalog and database schema where to find the information about the database tables and views. This information is not allways required, but in many ocasions is needed, depending on the database vendor and the access privileges of the user who has access to the database. Below
are some common scenarios:
- In Oracle: The database username is asssociated with the schema and
with a null catalog. So as, usually, you will not specify any catalog, but if you don't sypecify
any schema, and click Load All Tables in Schema you will find all tables
and views that this user has access to, possibly including system tables and tables
from other schemas (if user has DBA privileges). Therefore, is highly recommended
to specify the schema.
- In SQLServer: The database username has its own schema, but usually all
tables are created and used under a special user named dbo. The catalog is the database name.
So as, in a common scenario you will specify the database name as catalog name and dbo as schema name.
However, in many cases if you don't specify any information
for schema or catalog you attain the same effect, provided that the user has only
access to his database and dbo schema.
|
Version |
Date |
Changes |
|
1.0.19.109 |
2017.02.25 |
Java 6 to 8 compatibility |
|
1.0.73.0 |
2012.04.02 |
Initial release |
|
1.0.69.0 |
2012.01.16 |
Initial release (internal) |
]
