Malloc Corporation - productsTestDaedmonDescription

By: Malloc  09-12-2011


Test Daemon is a testing and analytical tool designed to monitor one of an enterprise's most valuable assets - DATA! Test Daemon captures transaction events as they occur in a database and presents them in a comprehensive and customizable report so the tester or developer can analyze these events.

Test Daemon breaks new ground in software testing and application analysis because it focuses on the activity in the database. Other available automated software testing tools work at the user interface level. 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 true measure of application success. Test Daemon is designed to automate the following testing activities with ORACLE databases:

1. Functional testing and program flow analysis.
2. Performance testing.
3. Auditing changes on data in the database.
4. Reversing changes in the database.
5. How Does Test Daemon Work?

The tester uses Test Daemon to define a set of columns within production database tables to be tested. Once identified to Test Daemon, a set of audit tables is automatically created in a unique space in the database under 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 the table columns selected by the user plus Test Daemon generated columns that allow for 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 and old values of the data, the userid that processed the changes, the exact date and time of the changes and the order in which the changes occurred.

The tester links the tables to a test case and it is the test case execution that captures and stores the database transaction events once a program that changes data is run. Test case properties like, test case name, date and time of execution and the tester ID are also stored. Once designed, test cases may be reused as required. Further, multiple test cases may be executed at the same time.

Test Daemon has a comprehensive set of filters used when defining what to capture. They provide the flexibility to specifically track different types of database transaction events that occur so you can focus your test or analysis.

Once transaction event information is captured, the user requests a report to review the results of the capture. The user may customize the report in order to focus their review on specific transaction events. Since the data capture is permanently stored in audit tables, you can request multiple reports with different parameters defined on each to facilitate a comprehensive review of the transaction events that have occurred.

The audit tables are stored in the database until the user explicitly deletes them. The ability to delete audit tables is part of Test Daemon functionality and any such deletes should be done using the software option provided so that it is done correctly. Deleting audit tables directly from the database could adversely affect Test Daemon internal data.

Test Daemon is a client\server application that interfaces with an ORACLE database regardless of the database platform. The entire Test Daemon application resides on the client (PC Workstation or LAN Server). There are no components of Test Daemon software that have to be installed on the server side. It connects to an ORACLE database through SQL*NET.

What are the Key Benefits of Test Daemon?

· user defines which tables and columns within tables to audit providing the flexibility of very broad or very precise testing and/or analysis of the database transaction events

· 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

Who Should Use Test Daemon?

· Testers - Test Daemon is an invaluable tool when used during program testing. It allows a tester to analyze how programs update the database and uncover processing errors before they get into the production version of the program.

· Analysts - Test Daemon will record the exact order of all transaction events occurring in the database. This allows analysts to examine the program flow. Again, this allows errors to be corrected before they are discovered in production.

· Programmers – When used for development or maintenance, Test Daemon is an effective unit testing tool. It is used to analyze the effects of program code changes on the sequence of transaction events and on updates to the database.

· Managers – Test Daemon may be used as a monitoring tool to ensure that programs are performing as expected in a production environment and processes are not corrupting data in the database. Test Daemon can be used to audit maintenance work performed directly on production data.

Test Daemon vs. Traditional Test Methods

Traditional test methods tend to be the manual execution of a program in a test environment that may or may not have been built for the purposes of the program under test. Generally, the tester captures the table configuration before and after a program execution and determines success or failure of the test by comparing the two configurations of the table. In order to compare the tables, the tester “eyeballs” the two tables looking for expected differences. A tester may decide to use SQL to focus 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, the script is generally 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 whole tables 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 intermediary transaction events 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 did occur and should not have, and tables that were updated with the same values as originally stored in the table will not be identified.

With any test effort the question of how to supply data for the test is always an issue. If good baseline 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 more voluminous than preparing specific test data and therefore requires significant resources to store and use it. As a result, the test effort becomes more cumbersome and the test results more obscured by the presence of large amounts of data.

Lastly, the need to ‘fix’ data in the production database itself is often the fastest way to keep the business operating. While this is not an official testing practice it is a method of problem analysis and resolution that leaves the ‘fix’ result to manifest itself ‘live’ in the production data. When this occurs changes are made but rarely recorded. This means that if something else goes wrong there may be no knowledge of the original intervention and its possible relationship to the new problem. Also, there is no way to learn from each intervention to improve programs and implement long term solutions.

Test Daemon addresses these traditional test method limitations. First, navigating through Test Daemon to build test cases and then executing the test case run means a tester builds a test environment specific to the program under test.

Second, the tester controls how many tables to audit, how much of a table to audit and what types of transaction events to audit. Therefore, the amount of data captured and analyzed is controlled and allows for more precise data analysis.

Next, Test Daemon captures all transaction events in sequence and time stamps them. This provides access to the crucial intermediary steps so that a tester knows how the table went from its initial configuration to its final configuration.

By sequencing and time stamping transaction events, Test Daemon exposes unexpected changes to the database, expected changes that did not occur and should have, and table values that were updated with the same values as originally stored in the table.

Finally, by using Test Daemon to capture production data ‘fixes’, a permanent record of what was done exists. This supports later analysis and the potential to design long term solutions to production problems. Further, if the change has been captured on Test Daemon, it can be used to rollback pre- or post-commit changes, so data does not have to be manually restored.

Main Features

· User friendly, menu/toolbar driven GUI Client/Server Application.

· Reports can be saved in a number of different formats including; Excel, Lotus, ASCII, HTML, CSV, SQL, Dbase and Windows Metafile.

· Once defined, test cases can be reused over and over again.

· Automatically creates and drops audit tables

Test Daemon is a Client/Server application. It works on Win95/98, WinNT 3.51/4.0 with Oracle databases, version 7.x and up, residing on any platform. It may also work with Oracle version 6.x but the appropriate testing for versions earlier than 7.0 has not been performed.

Software/Hardware Requirements:
Windows 95/98/2000 or Windows NT 4.0
100% compatible PC computer
Pentium Processor
16 MB of RAM
20 MB of free Hard Disk Space
VGA Display

Other products and services from Malloc


Malloc Corporation - productsG DAOframework

Code generation overcomes some deficiencies of inheritance (i.e. Java allows class to be inherited only from one super class, each database object is represented by customized Java class, enables IDE features like ?Code Assist. Integrator with JDBC enabled Data Sources such as all major databases and file formats. G-DAO FRAMEWORK - PRODUCT DESCRIPTION What is G-DAO Framework. Java technologies such as JDBC.


Malloc Corporation - RemoteDataServices

We need a program which will continuously compare data in Sybase and Oracle databases and send us daily report about discrepancies.. Databases can be sent to us as an export files , bcp files or as any other popular file format. Remote access could be provided so we can export data ourselves or just work directly on your database. For complex requirements we provide a proof of concept which ensures success and quality of service.


Malloc Corporation - Database Analyzer

DB Analyzer is designed to help IT personnel such as Business Analysts, Managers, System Architects, Developers and Database Administrators to better understand how and what data is stored in the database. Quality Assurance analysts can check the quality of test bed database and ensure the data is sufficiently diversified and appropriate for user acceptance testing.


Malloc Corporation - dataMigrationCaseStudy

Many legacy databases do not implement referential integrity and sometimes are not even properly designed so even rudimentary data rules are implemented and controlled at the application level and not by database engine. Having data model will definitely help understood database structure however it will not do much when it comes to understanding data stored in the database, its format, usage, patterns, spreads, etc.


Malloc Corporation - services

Data migration between wide spectrum of sources and destinations such as databases, files, messaging and remote systems. Design and development of data layers for business applications also known as "back end" applications and middleware. Design and development of OLTP Relational Databases and back end systems. Performance optimization related to massive data volumes manipulation.