Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Automated Test Execution Host

IP.com Disclosure Number: IPCOM000168044D
Original Publication Date: 2008-Mar-11
Included in the Prior Art Database: 2008-Mar-11
Document File: 2 page(s) / 62K

Publishing Venue

Siemens

Related People

Juergen Carstens: CONTACT

Abstract

Software test automation is often applied for software testing especially when many recursion tests have to be performed. However, automated tests can not cope with some situations. The following scenarios pose a problem for automated tests: 1) The computer has to be rebooted in order to test certain functional behavior of the software, for example due to license changes of the software or data saving. The problem is that all processes are killed after the reboot, but the test scripts may be not completed. A similar situation occurs when a user shuts down the computer and wants to verify the scenario after starting the machine some time later. 2) Tests are executed in a batch mode or in an unattended mode and a test failure occurs. In this case, it is difficult to detect the cause of the failure. 3) Test scripts get into infinite loop. They may consume system resources indefinitely and prevent the execution of other tests in the pipeline.

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 52% of the total text.

Page 1 of 2

Automated Test Execution Host

Idea: Nagesh Phaniraj, IN-Bangalore; Anjali Thakur, IN-Bangalore

Software test automation is often applied for software testing especially when many recursion tests have to be performed. However, automated tests can not cope with some situations. The following scenarios pose a problem for automated tests:
1) The computer has to be rebooted in order to test certain functional behavior of the software, for example due to license changes of the software or data saving. The problem is that all processes are killed after the reboot, but the test scripts may be not completed. A similar situation occurs when a user shuts down the computer and wants to verify the scenario after starting the machine some time later.

2) Tests are executed in a batch mode or in an unattended mode and a test failure occurs. In this case, it is difficult to detect the cause of the failure.

3) Test scripts get into infinite loop. They may consume system resources indefinitely and prevent the execution of other tests in the pipeline.

The above situations have been handled manually until now.

The present solution introduces the Automated Test Execution Host (ATEH), which is an executable file that starts automatically with the system start-up and runs in the background.

The test script execution is performed in an automated software test environment. During the development of test scripts, "test interrupt" commands can be added as a test step. "Test interrupts" mean external events that can affect the flow of test steps. When the test execution is started, ATEH parses the test scripts sequentially. If there is a test interrupt, ATEH takes over the control, performs the task that is required for the test interrupt and hands over the control back to the script. The proposed idea is illustrated in Figure 1.

Implementations of the proposed solution are presented in the following. They show how the ATEH deals with the situations described above.
1) In the following, a simple test script is considered requiring only one test interrupt. The complete set of steps is divided into two subsets: subset 1, which has to be performed before the test interrupt, and subset 2, which has to be performed after the test interrupt.
a) Subset 1 is running.
b) Subset 1 requests the ATEH for an interrupt.
c) The ATEH suspe...