Browse Prior Art Database

Intelligent file handling (IFH) over a network by a centralised test harness

IP.com Disclosure Number: IPCOM000132277D
Original Publication Date: 2005-Dec-06
Included in the Prior Art Database: 2005-Dec-06
Document File: 4 page(s) / 166K

Publishing Venue

IBM

Abstract

GUI Testing has traditionally been perceived as conventional testing of menus, bitmaps and windows. Further, GUI design and development technologies have continuously evolved with time. Technically, this progress has to be well-matched with equivalent GUI Testing methods.This disclosure aims at providing a framework that will reduce time and effort spent in preparation and consolidation of test as well as efficiently testing the subject

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 29% of the total text.

Page 1 of 4

Intelligent file handling (IFH) over a network by a centralised test harness

Much of distributed testing involves a series of tests to run on various platforms which would also involve the use of multiple machines. The following should be taken into consideration:
1.File Synchronisation with Central Repository: Running tests generally requires a set of files necessary for the execution of the tests. A common set of files is stored in what is called the 'Central Repository'. The repository can be seen as a 'File system' or 'File Server' forming the crux of the file storage used by the test harness. The IFH harness will synchronise the files on the repository with the files on the test machine(s). This is accomplished by comparing the timestamps between files on the repository and the test machine(s). If the timestamps differ then the test harness copies the most recent file(s) across to the test machine(s) involved in the test run. This is done due to performance reasons. In a scenario where testers are spread around the world it can be very time consuming to copy all files by default. Thus the comparison saves the need for all files to be copied. Only the most recently updated files are synchronised. Synchronisation is kicked off at the start of the automation by default. This behaviour can be controlled by the user. The following four options are available to the user.

No synchronisation is performed. (the network may be down)

Synchronise with a brand new test machine that only has a 'Driver' file so the automation on that machine knows where the file server is. All files are then copied over (except the 'Driver' file, so it's not overwritten as it contains information specific to that local machine, such as userids.) Synchronisation with an existing test machine. Only files where there is newer timestamp on the file server are copied to the local test systems, except the 'TestRunInstructions' and 'Driver' files as these files contain information specific to that local machine, such as userids or test run definitions.

Synchronisation with an existing test machine, where some of the files are being developed locally so that they have a more recent time stamp than on the file server. Only files where there is a newer timestamp on the repository are copied to the local test systems, except the 'TestRunInstructions' and 'Driver' files as these files contain information specific to that local machine, such as userids or test run definitions. The files with the more recent timestamp on the local system are not and cannot be copied back to the server, as these are still under development and may not have been tested. This is to avoid untested material being accidentally percolated to all test systems. Files once tested, would be approved and moved to the file server manually to ensure there is effective control and maintenance. This is why the design in uni-directional.

Synchronisation is uni-directional from the repository to the test m...