Test Daemon is an innovation in software testing and application analysis. It sets focus on activities that occur in the database, while other available and automated software testing tools work at the user interface level. More precisely, this means that inputs and outputs are used to measure application success. The interface level testing must be combined with database level testing to provide a real measure of application’s success. Test Daemon is designed to automate following testing activities with ORACLE databases:
- Functional testing and program flow analysis;
- Performance testing;
- Auditing changes on data within the database;
- Reversing changes in the database.
Users define what tables and columns they wish to audit. providing the flexibility of very broad or very precise testing and/or analysis of the database transaction events are captured in sequence and time stamped providing an audit trail of production data manipulation captured information is presented in a report for easy review and analysis reports may be customized and provide immediate testing/auditing documentation improved reliability and validity of test results through precise test case development, controlled test execution, and comprehensive data capture improved efficiency and productivity of the tester through automation of repetitive testing tasks in the event that production data must be directly manipulated, a documented audit trail of the production data intervention can be captured and stored.
How Does Test Daemon Work?
The user utilizes Test Daemon to define a set of columns inside those production database tables that need to be tested. Once Test Daemon identifies them, a set of audit tables is automatically created at a unique space in the database, within the test. The audit tables are uniquely identified and do not impact the existing production database tables. For each production table defined, an audit table is created. The audit tables contain only those table columns selected by the user plus Test Daemon generated columns that allow auditing of transaction events. The table columns and the Test Daemon audit columns are used to store information about transaction events. This information includes new data values, old data values, the user ID that processed the change(s), the exact date and time of the changes and the order of the changes that occurred.The tester links the tables to a test case. As soon as a program, whose purpose is to change data, is run, the test case execution captures and stores database transaction events. Test case properties (i.e. test case name, date and time of execution and tester ID) are also stored. Once designed, test cases may be reused as required. Furthermore, multiple test cases may be executed at the same time. Test Daemon has a comprehensive set of filters that can help with defining what to capture. They provide flexibility to track various types of database transaction events that occur, so you can focus on testing or analysis. Once transaction event information is captured, the user can request a report to review the capture results. Then, it is possible to customize the report in order to focus the review on specific transaction events. Since data capture is permanently stored in audit tables, you can request multiple reports with different parameters defined, so a comprehensive and probably complex review of the occurred transaction events can be simplified.
The audit tables are stored in the database until a user decides to delete them. The ability to delete audit tables is a part of Test Daemon functionality and any such actions should be done using the software option provided, to avoid any mistakes. Deleting audit tables directly from the database could indirectly affect Test Daemon internal data.
Test Daemon is a client\server application that communicates with an ORACLE database regardless of the database platform. The entire Test Daemon application remains with the client (PC Workstation or LAN Server). There are no components of Test Daemon software that have to be installed on the server. It is connected with an ORACLE database through SQL*NET.
Who Can Benefit Most From Test Daemon?
Testers – Test Daemon is an invaluable tool when used in program testing. It shows testers how programs update the database as well as uncover processing errors before they get into the production version of the program.
Analysts – Test Daemon records the exact order of all transaction events occurring in the database. This enables analysts to examine the program workflow. This way, errors can be corrected before they are discovered in the production. Programmers can find Test Daemon a useful gadget. When used for development or maintenance, Test Daemon can become an effective unit testing tool as well. It can be used to analyze the effects of program code changes on the sequence of transaction events. Also, it is possible to track database updates.
Managers – Test Daemon may be used as a monitoring tool in order to ensure that programs are performing as expected in a production environment, and that processes are not corrupting database data. Maintenance work that was performed directly on production data can be audited as well.
Test Daemon vs. Traditional Test Methods
Traditional testing methods tend to represent manual execution of a program in a test environment that may have been built for the purposes of the test program. Generally, the tester captures the table configuration before and after program execution and determines success or failure by comparing the two configurations. In order to compare them, the tester “eyeballs” the two tables looking for expected differences. A tester can also use SQL to focus on the before and after comparison of a large table. In this case the tester will write a script to allow comparison of a table for expected changes.There are a number of limitations with the manual comparison and the SQL script data extraction methods of testing. First, manually comparing database tables is not a trivial task. If the tables are large, the tester will only look for expected changes. Even if the tester decides to use SQL, generally, the script is written to focus on areas of the table that are expected to change. Changes that were not expected may be missed completely. Another way to compare table data is to export it into flat files and use operating system (OS) utilities, such as ‘diff’ in UNIX or ‘Windiff’ in Windows. However, even if only a few records are changed, the export and comparison of the whole table is necessary. At best, this method allows you to view the before and after status of the table and its data contents. The tester has no way of seeing or analyzing the transaction events in between that caused the change in the database table. Other limitations with manually comparing tables or using OS utilities to perform the table comparison are:
- The tester is less likely to isolate changes that occurred and weren’t supposed to;
- The tables that were updated with the same values as stored in the original table will not be identified.
Also, the question “How to supply data for the test?” is always an issue. If good test data does not exist, testers tend to use a copy of the production data. While it may be argued that production data is a good representation of the ‘real world’ for test purposes, it is generally much bigger in volume than specific test data. Therefore, significant resources are required to store and use it. As a result, the test effort becomes more cumbersome and test results become more obscured by the presence of large amounts of data.