Automated business process testing that spans multiple platforms or applications

A system and method for automated software testing includes defining a data model of an automated software test for a feature or business process being tested and then identifying an address for a function library at a local or remote location for executing the data model of the automated software test based upon the platform of the application. This identified function library is accessed at the address at the local or remote location so that an execution of a function within the function library may be invoked to obtain results therefrom.

TECHNICAL FIELD

The present invention relates to automated software testing across multiple software platforms, and more particularly, to a method for testing across multiple software platforms using a mix of languages.

BACKGROUND

The implementation of software on a computer system requires that the software be tested in order to confirm that is operating as expected. Historically, software functionality has been tested by creating a large combination of inputs to the software and verifying the outputs against the expected correct response.

To date, these inputs have been supplied and outputs verified either by manual or automated test execution. Manual execution is time and labor intensive, so automation is important to achieve economical test coverage. Scripting languages enable a programmer to automate test execution by simulating manual activity using code.

The problem with using scripting languages is that they are platform specific. Modern applications and business processes comprise components that are distributed over multiple platforms, and functionality may be ported from one platform to another. This requires a means of test automation that can execute across multiple platforms using the languages best suited to each platform, with flexibility to change to different languages should future needs arise.

This need for test procedures that span multiple platforms or applications is exemplified by enterprise planning applications such as SAP software whose functionality may be implemented using one or more platforms, or whose business processes may integrate with third party applications. In either case there is a need to execute tests that span platforms or applications end to end within a single procedure.

SUMMARY

The present invention disclosed and described herein, in one aspect thereof, comprises a system and method for automated software testing. A data model is defined of an automated software test for a business process being tested. The data model may span test steps across multiple applications or multiple components of the same application. An identification is made of at least one available address for a function library at a local or remote location for executing the automated software test based upon a platform of the application being tested. The identified function library is accessed at the local or remote location to invoke an execution of a function in the function library to obtain results from the execution of the function.

DETAILED DESCRIPTION

Referring now to the drawings, and more particularly, toFIG. 1, there is a system and method for automated software testing that enables the automation of test procedures whose definition is independent from a specific platform or scripting language. The system comprises a database102containing the test procedures that is logically connected during execution to one or more function libraries106containing a number of functions112that are specific to a particular language or platform. This database102describes the enterprise execution environment including all applications, application components, platforms and their location, and a table108that describes how each type of component is recognized and what actions can be performed against it.

The test procedures are constructed within the database102by selecting the application, the component within the application, the action to be performed against the component, and the relevant data value(s) to be either input to the software or verified against the output. This data is passed to an application program interface (API)110that makes a call to the function library106associated with the platform and invokes the function112needed to execute the specified action. The function112returns its results to the API110that in turn logs the results into the database102. These functions112maybe written in any language or protocol that is appropriate to the associated platform or software operating environment. Thus, a mix of these functions112on different platforms may be executed during a single test procedure, and functions112may be substituted if the same test procedure must be executed on another platform.

Platforms are identified by an interface mechanism. This interface mechanism may be operating system dependent or independent, or may be a capability of the development environment used to construct the application. For example, the Windows operating system provides an API for standard application components within its environment as this interface mechanism, while the Java runtime environment is operating system independent and supports accessibility through a standard class. Applications developed using either Java or .NET provide reflection interfaces, and applications executing within a browser may be accessed through the document object model interface. This multiplicity of potential interface mechanisms introduces complexity into the automated test process that this invention addresses.

Software applications may also provide their own interface mechanism for interacting with the software. SAP software, as a specific instance of this, provides an interface known as the SAP GUI API (graphical user interface application programming interface) that allows actions to be performed with and against the components of SAP software for various purposes including the automated execution of tests. SAP software also provides services in the form of XML messages that may be used to invoke business processes and related functionality within the SAP software that may also be used for automated testing. A business process is a transaction such as creating a sales order or generating an invoice that may require the use of one or more software components or applications to complete the transaction.

Referring now toFIG. 10, there is illustrated the manner in which a business process1002may be implemented across a plurality of software applications1004. A business process1002could comprise any business application such as generating a sales order or invoice that may require the use of multiple software components or applications1004in order to complete the business process. Each of the software components or applications1004which are implementing the business process1002may be executed on a number of different platforms1006. Thus, each business process1002, in addition to requiring operation across multiple software components or applications1004require the execution of these components or applications on multiple types of platforms1006. This of course renders the testing of the business process1002a very complex process.

Referring now also toFIG. 11, there is illustrated the manner in which a business process1002may be implemented and tested to confirm its proper operation. Various software components or applications1102necessary to incorporate a desired business process1002are purchased at step1102. The software components or applications1004are configured to a desired business process1002at step1104. Once the software has been configured to operate according to the desired business process1002on the appropriate platforms1006, the configuration of the business process is tested at step1106. The proper operation of the configuration of the software may then be tested.

Referring now toFIG. 2, there is illustrated a software application or business process200that requires an automated software testing procedure. The software application or business process200may include any type of code operable on any hardware platform or in any software environment. The software application or business process200includes components that are distributed across a mainframe202, a browser204, a PC206, a server208, mobile devices210and XML messages212. The mobile devices210may include any number of devices including a mobile telephone personal data assistant, mobile e-mail device, etc. The XML messages212may be delivered across multiple transports using various protocols. Thus, the execution of the software application or business process requires the execution of each of these components in different platforms as discussed previously and any testing procedure must demonstrate this behavior.

As can be seen, an automated test procedure using a scripting language formatted only for the mainframe platform would be able to test the inputs and outputs of the mainframe component202of the software application or business process200but cannot provide testing capabilities with respect to the remaining components. Likewise, scripting languages for mobile devices210may not be able to execute components against the mainframe202, browser204, PC or server208. The execution of XML messages may require yet another language depending on the protocol and transport. The limits of a particular scripting language to a specific component greatly limits the use of the scripted language. The manner of overcoming this problem is using multiple scripting languages, one for each separate component. However, composing a testing procedure for each component would require a great deal of programming time.

Referring now toFIG. 3a, there is illustrated a block diagram of the system enabling the automation of software testing across any platform using a mix of scripting languages. The database102contains data models of automated test procedures described by actions to be performed on the application and components associated with different platforms to execute tests over each of the components. The data model of the automated test procedure including the application, its platform interface, component, the component type, action and data combined are generated and forwarded from the database102to an API110. The application, its platform interface, the component, the component type, action and data comprises the test action request302illustrated inFIG. 3b.

The application303includes an indication of the software application that is being tested by the automated testing software. The platform interface information305provides an indication of the location of the function library106a-ffor the application being tested. The component information307includes an indication of the part of the software application that is to be tested. The component type309indicates what kind of component is to be tested. The action information311provides an indication of which particular function or activity is to be formed on the selected component type, and the data313includes any physical data necessary to carry out the requested action on the component. The test action request302enables the API110and function libraries106a-fto perform any desired test execution.

Referring now back toFIG. 3a, the API110selects the particular function112from a function library106a-fbased on the platform interface necessary to perform the action forwarded from the database102in the test action request302and routes the test action request302to the proper function library106a-fbased on the location of the application. The selected function112performs the action included within the test action request302to generate a particular test result based upon the provided data. The function112receives back the actual results, which are compared to the expected results at the function106. These results308, including either or both of the actual results and the comparison results, are sent back to the database102through the API110and saved for logging purposes.

The function library106a-fcomprises one or more functions112each associated with a particular component. Each of the functions112executes the test action request302and generates a result308of the action including any returned data values. The results308illustrated inFIG. 3cincludes the results320provided by function library106a-fand the results of the comparison322of the results320with an expected result. The expected result is provided to the function library106a-ffrom the database102in the test action request302. Using a combination of the functions112, applications and business processes200may be tested over a number of platforms. Thus, for example, the test procedure data model for an application or business process200that is executed on a browser204, PC206and a mobile device210would provide a set of test action requests that accessed function libraries106b,106cand106eto generate results308simulating execution of the application and business process200across these components. Each of the functions112in the function libraries106a-fenable particular actions to be executed on the platform with which the function library106a-fis associated. Function library106aenables the execution of actions on a mainframe platform102. Function library106bexecutes actions against components on a browser platform106a-f. Function library106cexecutes actions on a PC platform206. Function library106dexecutes actions on a server platform208and function library106eexecutes actions against components associated with mobile device platforms210. Function library106fexecutes actions on an XML message platform212.

Referring now toFIG. 4, there is a flow diagram illustrating the process by which a particular test procedure may use the cross-platform automated software testing functionalities of the present invention. Initially, at step402, an application or business process to be tested is selected from the database102. Next, the platform interface of the application or business process200is selected at step404from a list of the platform interfaces within the database102. Next, a component within the application or business process200is selected at step406. The component comprises some part of the application that is to be tested by the automated testing process. The database102performs at step408a lookup of the component type from the database102. The type of the component describes its characteristics; for example, whether it is a text field, a push button, a menu or a list. Each component type has an associated list of actions that may be performed against the component; for example, input or verify the value in a text box. Next, an action that may be associated with the selected component type is selected at step410, and all necessary data parameters for performing the selected action on the component are supplied at step412. This collection of information is stored as a test action request302at step413, and passed to the API110at step414.

The API110uses the IP address of the function library106a-fwithin the test action request302to connect at step416to the associated function112in the function library106a-fnecessary for carrying out the software test. The test action request302is used to invoke the function112to execute at step418the information contained in the test action request302. This process involves performing the provided action on the provided component using any of the data provided in the test action request302. A result is received from the execution of the function at step420and the result may be compared to an expected result at step422. The results420are returned to the database102via the API110at step424. The results420are stored at step426within the database102.

InFIG. 5, there are illustrated function libraries106a-fand an application or business process200that resides upon multiple platforms at multiple locations. The function libraries106a-fare distributed across a PC platform502in a first location, a mainframe platform504in a second location and a web browser platform506in a third location. Each of these platforms is able to communicate with each other via the Internet508or intranet510. The application or business process200is additionally implemented on each of the different platforms illustrated inFIG. 5. The fact that the application or business process200may be executed on the PC platform502, mainframe platform504and browser platform506require that locations of the function libraries106a-fmust be able to be determined such that the automated test execution may be run. The locations of the function libraries106a-fare identified by an IP address.

The PC platform502includes application or business process200and function libraries106a-fthat are associated with execution on the PC platform502. The PC platform502is able to communicate with the mainframe platform504via an intranet510. The intranet510may comprise any type of internal network that is implemented within a defined location or area such as a company intranet. The PC platform502communicates with the browser platform506over the Internet508. The Internet508comprises a worldwide communications network enabling wide spread communication amongst connected entities.

The mainframe platform504also includes applications200and function libraries106a-fthat are executed within this operating environment. Likewise, the browser platform506includes applications200and function libraries106a-fthat are executable and operable within the browser environment. Since the function libraries106a-fare located and associated with different platforms that are interconnected via an intranet510or internet508, in order for an application program interface to access these function libraries106a-fto perform automated testing procedures, there is the necessity of some manner for accessing these function libraries106a-fin different locations.

InFIG. 6there is illustrated the operation of the automated software testing system of the present invention having function libraries106a-flocated at a number of locations having separate IP addresses. Thus, the mainframe602, browser604, PC606, server608, mobile devices610, and XML message612and the associated functions112of the function libraries106a-fare at separate locations associated with separate IP addresses. In order to make it possible for the API110to locate a particular function112in a function library106a-f, each function library106a-fwill have associated therewith an IP address. The function library106a-fat that location associated with the application or business process is accessed via the Internet508or an intranet510using this IP address. In this manner, the API110may access functions112by routing test action requests302to and receiving results from the IP address which is associated with the function library106a-f.

The table600containing the information including the application or business process200, function library106a-fand IP address602is contained within the database102described with respect toFIG. 1. In this manner, a much greater variety of function libraries106a-fmay be accessed since a user is not limited to those function libraries contained within the processing entity with which the user is working but may access any platform containing function libraries106a-fthat are accessible via some type of intranet or Internet network.

Referring now toFIG. 7, there is illustrated a function library106a-fwhich is comprised of a set of functions702a-dthat are each associated with a component type and the action to be performed against the component type and the process performed by the function112. The API110passes the test action request302that contains the component, component type, action and data to the function library106a-fand the function library106a-fselects the function702that is associated with the selected action and component type. This function702executes the action and retrieves the result, which is returned to the API110. The particular function702within the function library106a-fthat is selected for generating the execution results is selected based upon the component selected, the type of action that is being performed and the data upon which the action is to be performed. The function library106a-fis at a location having an associated IP address.

The operation of the function library106a-fis more fully illustrated inFIG. 8, wherein, once the function is selected at step802, the test action request302is provided to the selected function112at step804. The function112extracts at step805the provided data from the test action request302and uses this data to perform the particular action associated with the selected function on a particular component at step806. This operation provides a particular result and this result is retrieved at step810such that the results may be provided back to the application program interface at step812. Alternatively, results from step810may be compared to an expected result and this result is additionally provided back to the API at step812. In this manner, for the selected action and associated data, automated execution may be performed on any number of platforms or software operating environments.

Referring now toFIG. 9, there is provided a particular example wherein the system of the present disclosure is used to execute tests for an application or business process900. The application or business process900includes three components, a browser component902that is operable within a browser environment, a server component904that is operable within a server environment and a mobile device component906that is operable within a mobile device environment. A test action request908is created for each of these components. The makeup of the test action request908depends upon the particular action that is desired to be tested with respect to the application or business process900for the associated component. While the disclosure with respect toFIG. 9illustrates a test action request908being created for each of the browser component902, server component904and mobile device component906, a user might desire to test only a single one or pair of these components, in which case there would only be one or two test action requests908provided to the application program interface910. Additionally, any component of the application or business process900may be tested in addition to those discussed above.

The application program interface910utilizes the IP address information within each of the test action requests908to route the test action request to three different function libraries associated at three different locations having separate IP addresses. For the test action request908for the browser component902, the API routes the test action request at912to function library one914at IP address one. For the server component904, the test action request908is routed at916from the API to a function library two918at IP address two. Finally, the test action request908for the mobile device component906is routed to function library three922at920wherein the function library three922is located at IP address three. It is noted that no test action request908is transmitted to function library four924at IP address four since no component requiring the functions of function library four is included within the application900being tested.

Each of the function libraries914,918and922generates a result in the manner described hereinabove responsive to each of the test action requests908received from the application program interface910. The results may be compared with an expected result in the test action request908to see if they match. The function libraries914,918and922transmit the results back to the API910. Function library one914transmits the results of the test for the browser component to the API at926. Function library two918transmits the results for the test of the server component904back to the API at928. Function library three922transmits the results of the test for the mobile device component906back to the API at930. Each of the results received at the API910is transmitted from the API910at932to a result log934. There are three separate results transmitted from the API910to the result log934at932since there are three separate results coming from each of the function libraries914,918and922. Each of these results are associated with a separate test for each of the browser component902, server component904and mobile device component906, respectively. The result log934then has three separate results stored therein that may be accessed by the user to determine the results of a test for application900.