Abstract:
A method of testing a first business system and a second business system is provided herein. The first business system is integrated with the second business system. The method includes performing a test of the first business system. The method further includes recording, during the test of the first business system, one or more calls from the first business system to the second business system. Also, the method includes identifying the one or more calls from the first business system far testing of the second business system.

Description:
BACKGROUND 
       [0001]    In the field of information technology, enterprise applications typically include numerous business systems. The software for each business system may be developed independently. This independent approach usually introduces challenges when the independently developed applications are deployed in a manner in which they must interact with each other. This may be especially so given the increasingly integrated nature of the typical enterprise application. 
         [0002]    The testing of the integration, e.g., the calls between business systems, is known as staging, also end-to-end testing. Staging is intended to identify potential problems that may arise when independently developed applications interact with each other. Typically, this type of testing is performed at the end of a release cycle. In some cases, due to time and other resource constraints, staging may not be performed at all. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0003]    Certain embodiments are described in the following detailed description and in reference to the drawings, in which: 
           [0004]      FIG. 1  is a block diagram of a testing platform in accordance with an embodiment; 
           [0005]      FIG. 2  is a block diagram of a relay testing system in accordance with an embodiment; 
           [0006]      FIG. 3  is a process flow diagram of a method for testing integrated applications in accordance with an embodiment; 
           [0007]      FIG. 4  is a block diagram of a system for relay testing in accordance with an embodiment; 
           [0008]      FIG. 5  is a block diagram of a system for relay testing in accordance with an embodiment; and 
           [0009]      FIG. 6  is a block diagram showing a non-transitory, computer-readable medium that stores code for relay testing in accordance with an embodiment. 
       
    
    
     DETAILED DESCRIPTION 
       [0010]    In many cases, the resources are not available for staging enterprise applications. For example, it may not be practical to provide the computer resources necessary for two complete production environments, one for the business of the enterprise, and one for staging. As such, individual business systems may only perform silo testing. 
         [0011]    In silo testing, the applications of a single business system are tested unto themselves, without testing calls to external applications. External applications may belong to external business systems, and as such, may not be available for testing. Due to circumstances such as these, the integration of enterprise applications may not be tested until the applications are deployed in a production environment. 
         [0012]    In one embodiment, a relay test system may be used for coverage of integrated business systems. Coverage describes a portion of calls between different business systems that are tested. In other words, the coverage indicates to what degree the integration of an enterprise&#39;s applications is tested. 
         [0013]      FIG. 1  is a block diagram of a testing platform  100  in accordance with an embodiment. The testing platform  100  includes a business system  102  and a relay testing system  104 . 
         [0014]    The relay testing system  104  may be used to perform an end-to-end test of the business system  102 . In the end-to-end test, the relay testing system  104  may test integration between business systems  102 , provide alerts for integration errors, and provide alerts for a lack of coverage in areas of integration during the testing. 
         [0015]    During testing of the business system  102 , the relay testing system  104  may record calls to external applications. The business system  102  including these external applications may then be loaded onto the testing platform  100 , and the recorded calls may be executed. 
         [0016]    In this manner, the external calls may be treated like a baton in a relay race, where the external calls are handed off to the next business system, which then executes those calls. In turn, those calls may trigger further external calls to other business systems  102 . The relay may be complete when the recorded calls are not further tested. Advantageously, the relay testing system may improve the quality of integration for newly deployed business systems. 
         [0017]      FIG. 2  is a block diagram of the relay testing system  104  in accordance with an embodiment. The relay testing system  104  may include business process modeling  202 , an output recorder  204 , a database  206 , service utilization  208 , a data recommender  210 , and data coverage  212 . The business process modeling  202  may model business processes, and the interactions of the various business systems  102 . 
         [0018]    The output recorder  204  may provide a mechanism that records or traps all outputs of one business system  102  intended for another, e.g., external business system. The output may include calls to external business systems, and data. The output may be recorded using application or communication hooks. In some embodiments, the output recorder  204  may be a non-intrusive network sniffing based communication recorder. The recorded outputs may be stored in the database  206 . 
         [0019]    In addition to external calls and other outputs, the database  206  may maintain various stores of data regarding the end-to-end testing. For example, information about which calls are tested may be stored in the database  206 . The data in the database  206  may be used to conduct the end-to-end testing, and to produce data coverage reports and workflow visualizations. Data coverage reports may describe the coverage of the business systems  102  tested using the relay testing system  104 . Workflow visualizations may show visualizations of currently tested integrations. 
         [0020]    The service utilization  208  may respond to external calls from the business system  102  being tested. Because the external business system may not be available for testing, external calls may crash applications being tested. To prevent crashes, or to facilitate the testing, the service utilization  208  may complete the business processes, i.e., applications, making the external calls. This may be done using stubbing, response generation, and the like. In various embodiments, the service utilization  208  may use automatic or manual processes. 
         [0021]    In one embodiment, the service utilization  208  may interface with the output recorder  204 . For example, two business systems  102 , system A and system B may be tested using the relay testing system  104 . When system A is being tested, an application may make a call to another application in system B. The service utilization  208  may be triggered to complete the call without crashing the application. The service utilization  208  may also send a record of the call to the output recorder  204 . The output recorder  204  may stored the record of the call in the database  206 . 
         [0022]    In some enterprises, mock services, or other techniques may be used in regard to external calls to applications not available on the testing platform  100 . Implementations of the relay testing system  104  in such enterprises may not include the service utilization  208 . 
         [0023]    The data recommender  210  may “recommend” calls to test in the business system  102 . The recommended calls may include calls recorded when another business system  102  was tested on the testing platform  100 . 
         [0024]    The data coverage  212  may describe coverage based on the recorded calls that are tested in each relay of the end-to-end testing. The data coverage  212  may provide the data coverage reports. 
         [0025]    In one embodiment, the data coverage  212  may run, and query the database  206  to determine which calls have been tested. This determination may be further based on the business process modeling  202 . In some embodiments, the data coverage  212  may determine whether the integration between System A and System B has been covered. 
         [0026]      FIG. 3  is a process flow diagram of a method  300  for testing integrated applications in accordance with an embodiment. It should be understood that the process flow diagram is not intended to indicate a particular order of execution. The method  300  may be performed by the relay testing system  104  in end-to-end testing. 
         [0027]    The method  300  begins at block  302 , where system A is tested. The system A may be a business system  102 . In one embodiment, system A may be loaded onto the testing platform  100 . 
         [0028]    At block  304 , calls to system B may be recorded during the test of system A. Each call may be a request to execute a program in system B. The call may include specified parameters depending on the program. 
         [0029]    At block  306 , the data recommender  210  may recommend testing the recorded calls. In one embodiment, an interface may be presented to a user participating in an end-to-end test of systems A and B. In some embodiments, the user may query the database  206  to determine which programs to test in system B. 
         [0030]    Once the testing of system A is concluded, at block  308 , system B may be tested. In one embodiment, the system B may be loaded onto the testing platform  100 . The calls recommended by the data recommender  210  may be tested. The test may also include the execution of other programs and parameters. 
         [0031]    At block  310 , the coverage of systems A and B may be determined. The coverage may be determined using data coverage reports. Based on the determination, further testing of systems A or B may proceed as described above. 
         [0032]      FIG. 4  is a flow diagram showing an example end-to-end test of business systems in accordance with an embodiment. In each relay of the end-to-end test, various activities, e.g., billing activities, inventory activities, and shipment activities may be performed. Each of the activities may represent a test of corresponding business systems, e.g., billing system  402 , inventory system  404 , and shipment system  406 . 
         [0033]    In the end-to-end test, each business system may be silo tested during each relay of the end-to-end test. Further, during the silo test, all external service calls may be recorded and saved in the database  206 . The data recommender  210  may recommend testing the programs in the inventory system  404  that were requested by the recorded external service calls. Those programs may then be tested during the silo test of the appropriate system. 
         [0034]    For example, as shown, the billing system  402  makes external service calls to the inventory system  404 . As such, during the during the silo test of the billing system  402 , all external service calls to the inventory system  404  may be recorded. The data recommender  210  may then recommend the recorded service calls for testing to a user that is silo testing the inventory system  404 . Accordingly, the recommended service calls may be tested during the silo testing of the inventory system. 
         [0035]    Similar to the billing system  402 , the inventory system  404  makes calls to the shipment system  406 . Further, the shipment system  406  makes calls back to the billing system  402 . As such, these calls are also recorded, and then tested during the silo testing of the respective systems. One implementation of end-to-end testing may include external service calls to more than one external system. For example, the billing system  402  may make external service calls to the inventory system  404  and the shipment system  406 . Accordingly, the silo test of those systems may include the calls recorded during the silo test of the billing system  402 . It should be noted that silo testing may include further transactions for testing, beyond the recorded service calls. 
         [0036]      FIG. 5  is a block diagram of a system  500  for relay testing in accordance with an embodiment. The functional blocks and devices shown in  FIG. 5  may comprise hardware elements, software elements, or some combination of software and hardware. The hardware elements may include circuitry. The software elements may include computer code stored on a non-transitory, computer-readable medium. Additionally, the functional blocks and devices of the system  500  are but one example of functional blocks and devices that may be implemented in an embodiment. Specific functional blocks may be defined based on design considerations for a particular electronic device. 
         [0037]    The system  500  may include a server  502  and a client  504 , in communication over a network  506 . The client  504  may be similarly configured to the server  502 . For example, the server  502  may include a processor  508 , which may be connected through a bus  510  to a display  512 , a keyboard  514 , an input device  516 , and an output device, such as a printer  518 . The input devices  516  may include devices such as a mouse or touch screen. The server  502  may also be connected through the bus  510  to a network interface card  520 . The network interface card  520  may connect the server  502  to the network  506 . 
         [0038]    The network  506  may be a local area network, a wide area network, such as the Internet, or another network configuration. The network  506  may include routers, switches, modems, or any other kind of interface device used for interconnection. In one example embodiment, the network  506  may be the Internet. 
         [0039]    The server  502  may have other units operatively coupled to the processor  512  through the bus  510 . These units may include non-transitory, computer-readable storage media, such as storage  522 . The storage  522  may include media for the long-term storage of operating software and data, such as hard drives. The storage  522  may also include other types of non-transitory, computer-readable media, such as read-only memory and random access memory. 
         [0040]    The storage  522  may include the machine readable instructions used in embodiments of the present techniques. In an embodiment, the storage  522  may include business systems  524 , an output recorder  526 , and a data recommender  528 . During an end-to-end test of the business systems  524 , the output recorder  526  may record calls between the business systems  524 . The data recommender  528  may recommend the recorded calls to a user participating in the end-to-end test. The recommended calls may be tested accordingly. 
         [0041]      FIG. 6  is a block diagram showing a non-transitory, computer-readable medium that stores code for relay testing in accordance with an embodiment. The non-transitory, computer-readable medium is generally referred to by the reference number  600 . 
         [0042]    The non-transitory, computer-readable medium  600  may correspond to any typical storage device that stores computer-implemented instructions, such as programming code or the like. For example, the storage device may include a hard disk drive, a magnetic disk drive, e.g., to read from or write to a removable magnetic disk, and an optical disk drive, e.g., for reading a CD-ROM disk or to read from or write to other optical media. Further, other types of media that are readable by a computer system and that are suitable to the desired end purpose may be used, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, and the like. 
         [0043]    The storage device may be connected to a system bus by a storage device interface, such as a hard disk drive interface, a magnetic disk drive interface and an optical drive interface. For example, the storage device may be the storage  522  discussed with respect to  FIG. 5 . 
         [0044]    When read and executed by a processor  602  via a communication path  604 , the instructions stored on the non-transitory, computer-readable medium  600  are adapted to cause the processor  602  to perform an end-to-end test of the business systems  524  according to an example embodiment, as described herein. 
         [0045]    The business systems  606  may be loaded onto a testing platform. During testing of the business systems  606 , the output recorder  608  may record external calls between the business systems  606 . The data recommender  610  may recommend the recorded calls for testing during the end-to-end test of the business systems  606 . The recommended calls may be tested.