Patent Application
20080306752
The present invention relates to a tool for automatically executing relevant testing in an Application Platform. Specifically, when an object in an Application Platform is changed, testing may be executed for the changed object as well as any related objects.
During software development and especially at the software development-to-production phase, different efforts are made to ensure that the software produced is of a high quality. This begins on the coding level with unit tests. In a unit test, a specific compiling unit is tested without regard to its relationship with other compiling units.
In an Application Platform, a number of objects are defined, such as Process Components, Business Objects, Inbound/Outbound Process Agents, Interfaces, Operations, and Messages. Integration Scenarios define exactly which objects interact with other objects and how they interact. Test plans are designed based on the Integration Scenarios, i.e., the relationship between the objects. After the successful execution of these test plans, it is guaranteed that the Application Platform will be free of known errors.
Code testing is a known useful technique to ensure that Application Platforms are error-free. However, after a correction is made to an object in an Application Platform, currently there is no quality assurance beyond the direct impact area of the correction. Only the code sections that are directly impacted by the correction are currently tested. Therefore, there may be code sections outside the direct impact area of the correction that are not tested. The result is that there may be undetected errors resulting from the change. It would be beneficial to test all objects that are related to the changed object, whether directly or indirectly affected, to maintain the integrity of the system and to ensure that the Application Platform remains error-free.
Embodiments of the present invention work cooperatively with existing Application Platform objects to automatically test all objects that are related to a changed object. An object may be associated with related objects within an Application Platform. Each object may also be associated with a test plan to test its integrity. When an object in the Application Platform is changed, the identity of the changed object may be sent by the system as an input to a component relation module, which uses the input to navigate a backend resource which maintains the relationships between objects and test plans. The resource may be, for example, a database accessible via an intranet. The component relation module may traverse the database and obtain the identity of test plans associated with the changed object. The component relation module may return this information to the CPU which may execute the identified test plan.
Additionally, the objects associated with the changed object may be identified, and the test plans associated with those related objects may also be executed automatically. There may be another resource in the backend which maintains the relationships between objects. For example, the resource may be a database based on a decision tree accessible via an intranet. The component relation module may traverse the decision tree and obtain the values for objects related to the changed object. Then, the field completion module may obtain the test plans associated with the related objects as discussed above. The component relation module may return this information to the CPU which may execute the identified test plans.
A user may change an object in the Application Platform by way of an input/output device 104, such as a keyboard or a mouse, for example. Any parameter value of the object may be changed. For example, a business object may contain services provided by a business object and data of the object itself. Either the services that may be performed or the data stored within the object may be changed. The CPU 106 may detect this change and receive the identity of the changed object as input. The identity of the changed object may be passed onto the component relation module 108 via network 110. The component relation module 108 may then search the testing database 112 to determine the test plan that is uniquely associated with the changed object. When the component relation module 108 finishes searching the testing database 112, it may access the test plan associated with the changed object. Thereafter, the component relation module 108 may return the accessed test plan to the CPU 106 via network 110. The CPU 106 may perform the test as instructed by the retrieved test plan.
If the test is not performed successfully, the CPU 106 may return an error message to the user via display 102 indicating that the changed object did not pass the test and must be changed.
If the test is performed successfully, the CPU 106 may pass the input (i.e. the identity of the changed object) to the component relation module 108 via network 110. The component relation module 108 may then search the component relation database 114 to determine the objects that are associated with the changed object. The component relation database 114 may contain a decision tree representing the hierarchy of objects in the Application Platform. The objects that are related to the changed object may be determined by traversing the decision tree. When the component relation module 108 finishes searching the component relation database 114, it may access the objects related to the changed object. Thereafter, for each object related to the changed object, the component relation module 108 may search the testing database 112 to determine the test plans associated with that object. Once the test plans for all objects related to the changed object have been accessed, the component relation module 108 may return the accessed test plans to the CPU 106 via the network 110. The CPU 106 may then perform the test plans.
If the additional tests are performed successfully, the CPU 106 may returns a message to the user via display 102 indicating that the changed object passed all tests. Alternatively, if the additional tests are performed successfully, no message may be returned to the user.
There may be different degrees of relation for an object to be considered “related” to the changed object. For example, an object may be considered related to the changed object if it is below the changed object in the hierarchy, i.e. if it is a descendant of the changed object. As another example, an object may be considered related to the changed object if it is within one generation of the changed object, i.e. if it is a child or parent of the changed object.
As another example, an object may be considered related to the changed object if it is a parent of the changed object or if it is a descendant of the changed object. For example, if the changed object was B 204, then the component relation module 108 would first traverse the decision tree 200 to determine which objects were below B 204 in the hierarchy. The objects below B 204 in the hierarchy are: D 208, E 210, F 212, G 214, and H 216. The component relation module 108 would then traverse the decision tree 200 to determine which objects were above B 204 in the hierarchy. The object above B 204 in the hierarchy is A 202. The component relation module 108 would then search the testing database 112 to determine which test plans were associated with objects D 208, E 210, F 212, G 214, and H 216, and A 202.
The CPU 106 may then determine whether the test has been performed successfully, step 308. If the test has not been performed successfully, the CPU 106 may return an error message to the user via display 102 indicating that the changed object did not pass the test and must be changed, step 310.
If the test has been performed successfully, the CPU 106 may pass the input (i.e. the identity of the changed object) to the component relation module 108 via network 110. The component relation module 108 may then search the component relation database 114 to determine the objects that are associated with the changed object, step 312. The component relation database 114 may contain a decision tree representing the hierarchy of objects in the Application Platform. The objects that are related to the changed object may be determined by traversing the decision tree. The definition of objects related to the changed object may be pre-determined by the CPU 106 or by the user, as discussed above. When the component relation module 108 finishes searching the component relation database 114, it may access the objects related to the changed object, step 314. Thereafter, for each object related to the changed object, the component relation module 108 may search the testing database 112 to determine the test plans associated with that object, step 316. Once the test plans for all objects related to the changed object have been accessed, the component relation module 108 may return the accessed test plans to the CPU 106 via network 110, step 318. The CPU 106 may perform the tests as instructed by the retrieved test plans, step 320.
The CPU 106 may then determine whether the additional tests have been performed successfully, step 322. If the additional tests have not been performed successfully, the CPU 106 may return an error message to the user via display 102, step 310. This error message may contain a general message indicating that the changed object or an object related to the changed object failed a test and must be changed. Alternatively, a specific error message may be returned to the user indicating exactly which related object did not pass its test. If the additional tests are performed successfully, the CPU 106 may not display any message to the user, step 326.
Several embodiments of the invention are specifically illustrated and/or described herein. These embodiments may be used in combination with each other to provide alternative embodiments. It will be appreciated that modifications and variations of the invention are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention.
