Resource allocation for executing automation scripts

Computer implemented methods and systems are provided for testing. A number of computers are configured for remote login. A number of test instances are identified. A test input file is partitioned into a number of segments, wherein the number of segments equals the number of test instances. A number of input files are created based on the number of segments, wherein the number of input files equals the number of segments. The number of test instances are executed on the number of computers to produce a number of test result files, wherein each test instance uses one of the input files. The number of test result files equals the number of test instances. The number of test result files are collated to produce a single combined test result file.

CROSS-REFERENCE TO RELATED APPLICATIONS

Not applicable.

REFERENCE TO A MICROFICHE APPENDIX

Not applicable.

BACKGROUND

An enterprise may test a variety of computer applications, such as purchased or leased applications that have been developed externally, applications developed by the enterprise for internal use, and applications developed by the enterprise for external use. The enterprise may test the applications on test computers that are configured similarly to the computers that are expected to use the applications. Because thorough testing of an application may require time-consuming tests conducted using significant amounts of test data, application testers may use a testing tool to automate the testing process.

Application testers may write a test of an application using a scripting language that executes a series of commands that might otherwise have to be entered interactively through a keyboard at a command prompt. A scripting language may insulate application testers from the intricacies of more formal development and from usage of programming tools designed for application developers. A scripting language also may make it easy for an application tester with specific knowledge (an engineer, statistician, economist, etc.) to test a specified application.

An application tester may use a testing tool to input an application that is to be tested on a test computer and to also use an automatic testing script to launch or to execute the application under test. The testing tool may also allocate a test computer for the application and launch the application under test on the test computer by executing the automatic testing script. Such a testing tool may use an application program interface, such as a web portal, accessed through a user interface to test applications. Despite the automated testing offered by testing tools executing automation scripts to test applications, the process of testing applications still may be very time-consuming.

SUMMARY

Disclosed herein are computer implemented methods and systems for testing. In some method embodiments, a number of computers are configured for remote login. A number of test instances are identified. A test input file is partitioned into a number of segments, wherein the number of segments equals the number of test instances. A number of input files are created based on the number of segments, wherein the number of input files equals the number of segments. The number of test instances are executed on the number of computers to produce a number of test result files, wherein each test instance uses one of the input files. The number of test result files equals the number of test instances. The number of test result files are collated to produce a single combined test result file.

Some system embodiments include a number of computers and a testing tool. The computers are configured for remote login. The testing tool identifies a number of test instances, and partitions a test input file into a number of segments, wherein the number of segments equals the number of test instances. The testing tool also creates a number of input files based on the number of segments, wherein the number of input files equals the number of segments, and executes the number of test instances on the number of computers, wherein each test instance uses one of the input files. Additionally, the testing tool receives a number of test result files from the number of computers, wherein the number of test result files equals the number of test instances, and collates the number of test result files into a combined test result file.

In other method embodiments, a number of computers are configured for remote login. A number of test instances are identified of a first test. At least one instance is identified of a second test. A test input file is partitioned into a number of segments, wherein the number of segments equals the number of test instances. A number of input files are created based on the number of segments, wherein the number of input files equals the number of segments. A number of instances of the first test are executed, wherein each instance uses one of the input files, and where the number of instances of the first test is less than the number of test instances. The second test is executed in response to executing the number of instances of the first test. A number of remaining instances of the first test are executed in response to executing the second test wherein each remaining instance uses one of the input files. A number of test result files are collated from executing the first test to produce a combined test result file.

DETAILED DESCRIPTION

In embodiments of the present disclosure, computer implemented methods and systems are provided for testing applications. An example of a test application framework is a Hewlett-Packard Mercury Loadrunner™ (Loadrunner™). Because the Loadrunner™ is not set up to login to a test computer, the Loadrunner™ requires a user to login remotely to one test computer, which becomes the only test computer configured to test the user's application. Even though the Loadrunner™ may test an application on only one test computer at a time, the Loadrunner™ requires the configuration of each available test computer before the testing tool may test any application on any test computer. While certain shortcomings of prior systems may be used to better illustrate the present disclosure, the present disclosed system may not necessarily overcome all the shortcomings of these prior systems or have all the resulting advantages. Further, the present system discloses numerous additional aspects not found in these prior systems.

In embodiments of the present disclosure, a test application framework may use a testing tool that identifies an application to be tested and allocates a number of test computers for testing the application. Rather than requiring a user to login remotely to a test computer, the testing tool configures a number of computers for remote login, which enables the testing tool to allocate multiple computers for testing the application. For example, if ten test computers are available for testing applications, the testing tool may identify ten test instances of a billing application to be executed. The testing tool configures a number of test computers for executing a test instance of the application, and provides a test input file to each of the test instances. For example, the testing tool may partition a test input file of a spreadsheet containing 2,000 data rows into ten segments of 200 data rows apiece. The testing tool may create ten input files based on the ten segments. The testing tool invokes an automatic testing script for each test instance to test the application using the provided test input file. For example, the testing tool may execute ten test instances of the billing application using the ten input files. The testing tool may collate ten result files to produce a single combined test result file from executing the ten test instances of the billing application, which may have been executed ten times faster than the execution of the test input file of 2,000 data rows being executed on one test computer. The increase of execution speed may be critical for thorough testing of applications facing deadlines To the user, the test result file appears to have been produced by executing the application on one computer using all of the input data, a process which may have taken much longer and caused an application testing deadline to have been missed.

Instead of the testing tool allocating all of the available test computers for testing the billing application, the testing tool may allocate some of the available test computers for testing the billing application, thereby leaving the remainder of the test computers available for testing a collections application. The testing tool may begin testing an application on allocated test computers without requiring the available test computers to be configured for testing another application. Although this discussion describes testing a billing application and a collections application, the testing tool may be used to test any type or number of applications. The testing tool may also partition the test input file for the billing application into smaller segments so that the collections application has a shorter wait time before a test computer is available. For example, the testing tool may partition a test input file containing 2,000 data rows for the billing application into twenty segments of 100 data rows apiece even though only ten test computers are available. In this example, the collections application waits for the testing of any instance of the billing application using 100 data rows to complete, instead of waiting for any instance of the billing application to complete testing using 200 data rows. The test computer that completed testing of an instance of the billing application is available for testing the collections application even while other instances of the billing application are still executing on other test computers. Once the collections application begins testing on any test computer, then execution of the remainder of the test instances for the billing application may begin as previously executing test instances complete and test computers become available.

Turning now toFIG. 1, a block diagram of a system100for testing applications is shown according to some embodiments of the present disclosure. The numbers and types of each component inFIG. 1are depicted for the purpose of an illustrative example only, as the system100can include any number and type of components. The system100includes a testing tool102, a user interface104, computers106-112, and data storage114. The testing tool102may be implemented by a general purpose computer, which is described in greater detail in reference toFIG. 3. Although some embodiments describe the testing tool102as electronically taking certain actions or processing certain data, in other embodiments these actions or activities may be accomplished manually, such as by a user requesting testing of an application. In other embodiments, these actions may be accomplished partially by hand and partially by the computer. The testing tool102may include an application program interface, such as a web portal, that may be accessed via the user interface104. The computers106-112may be located in a secure environment to reduce the possibility of computer users or other applications affecting test results. An application to be tested may be installed on the computers106-112, or the computers106-112may use a uniform resource locater (URL) to reference, via a communications network, the application to be tested. The data storage114includes test input files116-120. Each of the test input files116-120includes data for testing a corresponding application.

The testing tool102may execute automation scripts122to automatically test applications on the computers106-112. The automation scripts122may be input via the user interface104for each of the applications to be tested. The automation scripts122may include partitioning124automation scripts and collating126automation scripts. The testing tool102uses the partitioning124automation scripts to partition the test input files116-120into smaller segments of data used for testing applications, and to create input files based on the segments, such as input files128-134.

The testing tool102tests an application by partitioning a test input file into a number of segments, creating a number of input files128-134based on the segments, and executing automation scripts122to test the application on the computers106-112using the input files128-134. The testing tool102executes test instances of the application on the computers106-112using the input files128-134and the automation scripts122to run commands, for example, as if a user were entering data into the application. After testing is executed, the testing tool102uses the collating126automation scripts to collate the results from the application using the input files128-134into one of the combined test result files136-140. By executing the automation scripts122on each of the test instances, the testing tool102produces a result file for each of the test instances based on using one of the input files128-134. Each result file may contain results information including one or more of lists of what was tested, whether any errors occurred, data that was read, data that was written, back-office data, remote commands, communications with other systems, and similar testing information. The testing tool102collates the result file from each test instance to generate a combined test result file that combines the test results from executing each of the test instances based on using the input files128-134. The testing information listed in the generated test result file appears to the user as if the application was tested on only one test computer using one large input file that includes all of the input files128-134.

For example, to test a billing application, the testing tool102partitions the first test input file116into four segments, creates four input files128-134based on the four segments, and executes automation scripts122to test based on the four input files128-134on the four computers106-112. If the testing tool102allocates less than all of the computers106-112for testing a specific application, the testing tool102leaves the remainder of the computers106-112for other users. Continuing this example, after testing is executed, the testing tool102uses the collating126automation scripts to collate the results from executing the four input files128-134into the first combined test result file136. The number of partitioned segments and the corresponding number of input files128-134inFIG. 1are depicted for illustrative examples only, as the testing tool102may partition a test input file into any number of segments, create any number of input files128-134, and collate any number of result files.

FIG. 2shows a flowchart of a method for testing according to some embodiments of the present disclosure. The testing tool102may execute the method to allocate computers for automatically testing an application, to partition a test input file into segments, to test the application, and to combine the results from the computers testing the application into a result file.

In box202, a number of the computers106-112are configured for remote login. For example, the testing tool102configures the computers106-112at a secure environment for remote login. The testing tool102identifies that four computers106-112are available for testing applications and creates a local user identification (ID). The testing tool102updates a registry for each of the computers106-112to allow auto login based on the local user ID and configures each of the computers106-112to automatically login. The testing tool102disables a screen saver for each computer to prevent each of the computers106-112from locking, and configures each of the computers106-112to accept requests to execute automation scripts. The testing tool102executes this remote login configuration process to enable users of the testing tool102to access the computers106-112located in the secure environment without the need for the user to configure and remotely login to each of the computers106-112individually. By configuring all of the computers106-112in advance, the testing tool102makes any number of the computers106-112readily available for testing a specific application based on any requirements for testing the specific application.

In box204, testing of an application is requested. For example, a user inputs a request via the user interface104to the testing tool102for testing of a billing application, for example, by entering arguments into a command line of the user interface104. The arguments may identify the application to be tested and a test input file that corresponds to the application.

In box206, a number of test instances are identified. For example, the testing tool102identifies four test instances for the billing application by identifying all four of the computers106-112that are available for executing a test instance. The testing tool102identifies the first available computers for executing a test instance, such as first identifying the computer106, next identifying the computer108, then identifying the computer110, and finally identifying the computer112. The testing tool102may identify four test instances, which equals the number of computers106-112, so that use of the computers106-112is optimized for testing the billing application. In another example, the testing tool102identifies only three test instances, which is less than the number of computers106-112available for testing. The testing tool102may identify only three of the four available computers106-112for testing the billing application so that one of the computers106-112, such as the computer112, is allocated for another use, such as testing a collections application. The testing tool102may be dynamically modified on a test by test basis to determine whether to reserve some of the computers106-112for other uses or to optimize the number of the computers106-112used for testing the current application to be tested.

In box208, at least one instance of a second test is optionally identified. For example, the testing tool102identifies one instance of a test for the collections application. In the collections application example, the testing tool102may balance the needs of the user that first requested the testing of the billing application using a large input file with the needs of another user that later requested the testing of the collections application using a small input file. The testing tool102may balance the needs of both users by first scheduling some of the instances for the testing using the large input file that was requested first, and then scheduling the later-requested testing using the short input file into the testing schedule before the testing of the billings application is completed with the large input file. The flexible scheduling offered by the testing tool102may insure that the testing of the billings application with the large input file does not consume all of the testing resources for a substantial period of time while the collections application that requires only a test with a small input file has to wait idle.

In box210, an application for testing is optionally installed on computers. For example, the testing tool102installs the billing application on the computers106-112. In another example, the testing tool102installs the billing application on the computers106-110, leaving the computer112available for testing other applications. Because the test instance for the collections application may be executed through an interface on any of the test computers106-112, the collections application may not need to be installed on any of the computers106-112. For this example, the collections application may be executed by instructing any of the computers106-112to access a web page via a communications network, where the webpage includes the URL for the collections application. Each test instance, whether resident on a test computer or executed through an interface, includes at least one test for a corresponding application.

In box212, a test input file is partitioned into a number of segments, wherein the number of segments equals the number of test instances. Rather than waiting a long time for one test instance to execute using the entire test input file, a number of test instances may execute smaller portions of the test input file in significantly less time. For example, the testing tool102partitions the first test input file116, corresponding to the billing application, into four segments. The number of segments equals the number of test instances, which may be equal to the number of computers106-112allocated for testing the billing application. The number of segments equals the number of test instances because each test instance requires the use of at least a portion of the test input file to execute. The testing tool102partitions the first test input file116into four segments by reading the first test input file116, counting a number of data rows in the first test input file116, and dividing the number of data rows by the number of test instances. For example, the first input test file116is a spreadsheet for the billing application, and the spreadsheet includes 2,800 data rows. The testing tool102divides the 2,800 data rows by the four test instances to produce a preliminary 700.0 data rows per test instance. If the preliminary number of data rows is not an integer, the testing tool102may round the number of data rows per test instance to the next integer. As is well known, a variety of techniques are available for rounding numbers composed of a fractional part to an integer. Rounding may round any number composed of a fractional part up to the nearest integer, down to the nearest integer. Rounding may round up to the nearest integer if the fractional portion of the composed number is one half or greater and round down if the fractional portion of the composed number is less than half. Yet other rounding schemes may be employed, all of which are contemplated by the present disclosure. Rounding may also be referred to as approximating. In such a situation, the number of data rows may be one integer higher for some of the test instances than for some of the other test instances. Alternatively, the testing tool102may partition the first test input file116in other ways that do not attempt to create segments of approximately the same size. In this example, the testing tool102allocates 700 data rows per test instance to each segment for the billing application.

In another example, the testing tool102does not partition the second test input file118, which corresponds to the collections application, into segments because the second test input file118is a spreadsheet that includes only 20 data rows, which may be less than the minimum number of data rows required for partitioning any of the test input files116-120into segments. The minimum number of data rows required for partitioning a test input file may be based on consumption of resources. For example, the time required for partitioning 20 data rows into 4 segments of 5 data rows apiece, creating 4 input files based on the 4 segments, and collating the 4 test result files from executing 4 instances, each using 5 data rows, may be greater than the time required for executing one test instance using 20 data rows.

In box214, a number of input files128-134are created based on the number of segments, wherein the number of input files128-134equals the number of segments. For example, the testing tool102creates the four input files128-134for the billing application, with each of the input files128-134based on one of the four segments that include 700 data rows apiece. In another example, the testing tool102creates one additional input file for the collections application, with the additional input file based on the second test input file118of 20 data rows.

In box216, the number of test instances is executed wherein each test instance uses one of the input files. For example, the testing tool102executes the four test instances for the billing application by executing the automation scripts122. Alternatively, the testing tool102executes a number of instances of the test for the billing application, where the number of instances of the test executing for the billing application is less than the total number of test instances for the billing application. For example, the testing tool102executes three instances of the test for the billing application, out of the four possible test instances for the billing application, on three of the computers106-110. By executing only a limited number of test instances for the billing application, the testing tool102is allocating the computer112for testing the collections application instead of allocating all of the computers106-112for testing the billing application. After the short time required for executing the collections application is completed, the remaining test instance for the billing application may be executed on the computer112. In this example, the collections application is executed without waiting for execution of the test instances for the billing application even though testing of the billing application was requested before testing of the collections application was requested. Three of the instances of the billing application are executed without waiting, while the fourth instance of the billing application is executed after waiting for the short time required for executing the collections application.

If the testing tool102allocates the computers106-112after the testing of the billing application is requested, but before the testing of the collections application is requested, the testing tool102may allocate all four of the computers106-112for testing the billing application. In this situation, testing of the collections application must wait until one of the computers106-112has completed execution of a test instance of the billing application using 700 data rows. In this example, due to the sequence of the testing requests, a late arriving request to test 20 data rows must wait on one of the computers106-112to complete testing using 700 data rows.

Some embodiments address this sequencing situation by identifying a number of test instances for the billing application that is greater than the number of computers. The increased number of test instances results in partitioning the test input file into an increased number of segments, which results in increasing the corresponding number of input files. Because the test input file is being partitioned into a greater number of input files than in the previous example, each input file is reduced in size compared to the previous example. Subsequently, testing an instance using an input file requires reduced execution time, which enables later requests for testing of applications to be addressed without waiting for every instance associated with the earlier request to execute.

For example, rather than partitioning the first test input file116for the billing application into four segments and creating four input files to execute on the four computers106-112, the testing tool102partitions the first test input file116for the billing application into seven segments and creates seven input files to execute on the four computers106-112. The 2,800 data rows in the first test input file116are partitioned into seven segments of 400 data rows apiece, which results in creating seven input files of 400 data rows apiece. The creation of four input files for the billing application would have resulted in the later request for testing the collections application to wait for one of the computers106-112to execute a test on 700 data rows. In contrast, the creation of seven input files for the billing application results in the late arriving collection application and the three remaining instances of the billing application collectively waiting for the four computers106-112to execute a test on only 400 data rows for each of the first four instances of the billing application. This type of partitioning results in less waiting time for the testing of subsequent applications and instances.

In box218, the second test is optionally executed in response to executing the number of instances of the first test. For example, having begun execution of the three instances of the test for the billing application on the computers106-110, the testing tool102executes the test for the collections application on the remaining computer112. In this example, the test on the 20 data rows for the collections application does not have to wait until the test on the 700 data rows for the billing application is completed on each of the computers106-112. In the example based on seven input files, having completed execution of one of the first four instances of the test for the billing application using 400 data rows on one of the computers106-112, the testing tool102executes the test for the collections application. In this example, the test on the 20 data rows for the collections application waits until execution is completed using only 400 data rows, not 700 data rows, for the billing application on one of the computers106-112.

In box220, a number of remaining instances of the first test are optionally executed in response to executing the second test. For example, when executing the test for the collections application on the remaining computer112is completed, the testing tool102executes the one remaining instance of the test of the billing application on the remaining computer112. In this example, the test on the 20 data rows for the collections application may be completed relatively quickly, such that the remaining instance of the test for the billing application that has not already begun execution does not have to wait long before it is allocated to the remaining computer112. In the example based on seven input files, the testing tool102has completed execution of some of the first four instances of the test for the billing application and begun execution of the test for the collections application. As execution of some of the first four instances of the test for the billing application is completed such that some of the computers106-112become available, the testing tool102begins executing the test for some of the three remaining instances of the billings application.

In box222, a number of test result files are collated from executing the number of test instances to produce a combined test result file, wherein the number of test result files equals the number of test instances. For example, the testing tool102uses the collating126automation scripts to produce the first combined test result file136from executing the four test instances for the billing application on the computers106-112. In this example, the four computers106-112may execute the test for the billing application on all of the data rows in the first test input file116approximately four times faster than the test would have been executed using only one of the computers106-112. The user of the testing tool102may use the user interface104to access the first combined test result file136, which displays the result data as if the test had been executed on only one of the computers106-112. The number of the computers106-112used to test the application is transparent to the user.

The system described above may be implemented on any general-purpose computer with sufficient processing power, memory resources, and network throughput capability to handle the necessary workload placed upon it.FIG. 3illustrates a typical, general-purpose computer system suitable for implementing one or more embodiments disclosed herein. The computer system380includes a processor382(which may be referred to as a central processor unit or CPU) that is in communication with memory devices including secondary storage384, read only memory (ROM)386, random access memory (RAM)388, input/output (I/O) devices390, and network connectivity devices392. The processor may be implemented as one or more CPU chips.

The secondary storage384is typically comprised of one or more disk drives or tape drives and is used for non-volatile storage of data and as an over-flow data storage device if RAM388is not large enough to hold all working data. Secondary storage384may be used to store programs which are loaded into RAM388when such programs are selected for execution. The ROM386is used to store instructions and perhaps data which are read during program execution. ROM386is a non-volatile memory device which typically has a small memory capacity relative to the larger memory capacity of secondary storage. The RAM388is used to store volatile data and perhaps to store instructions. Access to both ROM386and RAM388is typically faster than to secondary storage384.

The processor382executes instructions, codes, computer programs, scripts which it accesses from hard disk, floppy disk, optical disk (these various disk based systems may all be considered secondary storage384), ROM386, RAM388, or the network connectivity devices392.