Browse Prior Art Database

Automated JPOS/ OPOS Testing Architecture

IP.com Disclosure Number: IPCOM000014508D
Original Publication Date: 2000-Dec-01
Included in the Prior Art Database: 2003-Jun-19
Document File: 2 page(s) / 50K

Publishing Venue

IBM

Abstract

Disclosed is a an architecture for the automated JPOS/ OPOS testing. Functional testing of IBM Service Objects (SO) for OLE for Retail POS (OPOS) has always been a long drawn manual process. Applications developed using Visual Basic are used to test each of the eleven devices that IBM SO supports. The user must interact with the test tool to exercise the various APIs of the device under test and inspect the result of the execution. Some of the test cases are pretty standard in the sense that they could be executed without the need for human intervention. The end result of the execution is compared with a pre-specified expected result and the detail of the execution would be captured in a log file. The novel architecture below (see Fig. 1) describes how we could automate the functional testing process such that minimal human intervention is required. In addition to minimizing human intervention, we have created an environment such that we could test both Java for Retail POS (JPOS) and OPOS with a flag that we pass into the test environment. The automation tool reduces the testing effort and make testing more efficient, effort-less and most importantly, repeatable.

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 JPOS/ OPOS Testing Architecture

Disclosed is a an architecture for the automated JPOS/ OPOS testing. Functional testing of IBM Service Objects (SO) for OLE for Retail POS (OPOS) has always been a long drawn manual process. Applications developed using Visual Basic are used to test each of the eleven devices that IBM SO supports. The user must interact with the test tool to exercise the various APIs of the device under test and inspect the result of the execution. Some of the test cases are pretty standard in the sense that they could be executed without the need for human intervention. The end result of the execution is compared with a pre-specified expected result and the detail of the execution would be captured in a log file. The novel architecture below (see Fig. 1) describes how we could automate the functional testing process such that minimal human intervention is required. In addition to minimizing human intervention, we have created an environment such that we could test both Java for Retail POS (JPOS) and OPOS with a flag that we pass into the test environment. The automation tool reduces the testing effort and make testing more efficient, effort-less and most importantly, repeatable.

The architecture makes use of JACL (the Java implementation of Tcl/Tk) to interpret the Tcl scripts. The Tcl scripts contain the APIs that we want to test the POS Subsystem with. Testing of JPOS is pretty straight forward because primarily JACL is a Java implementation of Tcl/Tk and it integrates seamlessly with JPOS. It is treated like an application that calls the POS Subsystem.

The biggest challenge is to enable JACL to talk to OPOS objects. This is essentially trying to link Java with Microsoft COM objects. There are numerous Java-COM bridges in the market but none of them is able to interface the JACL application to the OPOS COM Automation objects smoothly. The most straight forward implem...