This disclosure relates to application testing and more specifically to systems and methods for driving a set of tests against a software application and even more specifically to systems and methods for performing network testing of applications and devices that do not have network address visibility.
Mobile devices, such as cellular telephones, PCs, PDAs and the like, typically have software loaded thereon by the device manufacturer or by an intermediary. When such software is loaded on a device, it is necessary to test the software to be sure it is operable. It is also necessary to test such software before it is loaded on a device, for example, when the software is being developed to be sure that it will work properly and without interference with other operations of the device. Note that while software is being discussed in the example, any form of application coding, such as firmware, ASICS, etc., will have the same requirements, and the term software is meant to cover all forms of application coding and/or control.
Generally with software which is designed to run on any platform, the designer must be able to verify accuracy of the application with respect to inputs sent to or received from the platform. This verification relies on the ability to apply input parameters to the platform while the platform is in its normal operating environment. However, in the case of wireless technology, the normal operating environment for the telephone platform on which the software will operate includes a communication network which is not normally available to a software design team. For example, in a cellular telephone a software application designer cannot normally create an incoming call over the network in order to send commands to the telephone. The problem is compounded in that often the software is designed and tested externally to an actual wireless device. Thus, even having access to a cellular network will not help when the software is not yet embedded in an actual device.
Various embodiments of the present invention are directed to a system and method and computer program product which allows applications that are otherwise not addressable by a network to be accessed and tested via the network. For test purposes, an Application Under Test (AUT) is bundled with several components that allow a Test Server (TS) to access the AUT as if the AUT were directly addressable via the network. In one embodiment, the AUT is bundled with a Client Proxy (CP). The client proxy is also limited in that it also is not addressable by the test server. However, the client proxy can make outgoing socket connections (Hyper Text Transfer Protocol—HTTP, in this example implementation). The client proxy queries a Server Proxy (SP) for queued requests, sends the appropriate commands to the AUT, and then responds to the SP with the results. The combination of the SP and the CP, working in tandem, abstract the network connection to the device and provide a virtual connection to the AUT. To the TS, there is a socket (HTTP) connection directly to the device, and thus the methods are invoked directly on the device.
The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention. It should be appreciated by those skilled in the art that the conception and specific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the invention as set forth in the appended claims. The novel features which are believed to be characteristic of the invention, both as to its organization and method of operation, together with further objects and advantages will be better understood from the following description when considered in connection with the accompanying figures. It is to be expressly understood, however, that each of the figures is provided for the purpose of illustration and description only and is not intended as a definition of the limits of the present invention.
For a more complete understanding of the present invention, reference is now made to the following descriptions taken in conjunction with the accompanying drawing, in which:
Process 205 determines if a CP has polled the SP. If so, the request data is extracted from the queue for this device and placed in the response for the client request via process 206 which is passed to the AUT via the DTS via process 207. When process 208 determines that there is a response from the AUT, process 209 sends a second request to the SP, this time with the results from the original, queued request. The SP answers the request, processes 210, 211 and 212 by taking the results from the CP, unblocking the original SP request from the test server, writing the results into the response for the TS, returning that response, and closing the socket connection (standard HTTP).
This presents a clean interface to the TDA and the TS so that by making a call on the AUT, the result will come back. On the other hand the TS may not want to wait on some longer running client activities. In this case, the TS makes a call on the AUT and returns immediately. It is then up to the AUT to post the response back to the TS. This is an example of executing a callback through the server/client proxies 13 and 16. The callback need not pass back through the server/client proxy, as the AUT/DTS can post the results to the publicly addressable TS. An example of this is the eventing architecture within the DTS. The TS may invoke methods on the DTS to add or remove event listeners and events for those listeners. When the AUT or the DTS signals an event, all the listeners are invoked for that event. In the case of the DTS, it packages these events and posts them to the TS.
A bootstrap server (BS) (not shown) is a second example of the TS, SP, CP combination. As part of the testing process, new devices must be inducted into a group of machines that will be associated with a particular TS. The BS is essentially the same thing as the DTS, that is, a webserver attached to an executable, with the purpose of exposing the executable as an invokable object over a socket (HTTP) connection. The process of induction, and the typical use case for the BS is as follows:
With this level of automation and control, the TDA can continuously run any series of tests, against any version of the AUT, on any subset of the devices under control by the TS.
The server proxy/client proxy combination provides a transparent socket (HTTP) connection from the TS to the DTS. However, the DTS does not require the proxies if it has an addressable network address. The DTS is essentially a web server that resides on the device. The layering of this mechanism is as follows:
As discussed, the DTS is a small webserver that is used to provide remote invocation of whatever application it is attached to, be it the AUT or the BS. In both of these implementations, the DTS is an in-process Dynamic Link Library (DLL) file to the AUT and the BS. But it does not have to be. The DTS could use a variety of means to communicate with the target application, but the simplest approach has been to make it an in-process DLL.
The actual transport between DTS 12 and TS 14 can be any suitable protocol, such as Short Message Service (SMS), TCB socket, provided that the DTS's HTTP interface is presented to the TS. Any method of embedding HTTP information inside another message will work.
Note that the test driver application can be scaled because it can provide the same (or different) test sequences to any number of devices, just so long as each device presents an HTTP address. Thus, each device simply appears to be an HTTP server that is accessible directly from a test application. Each device test server has a corresponding HTTP listener on TS 14 to accept addresses for its associated AUT. In a preferred embodiment the HTTP addresses are manually allocated on the TS but this process could be automated.
With proper security, the metadata pertaining to an HTTP address of a device can be stored on a TS and the metadata could, for example, contain data on applications on particular devices, what carrier the device is assigned to, what kind of hand set, what operating system, etc. Then a user makes a request to the TS indicating an access to the devices of a particular operating system or manufacturer. Those messages are then relayed via the HTTP connector to the devices.
When implemented via computer-executable instructions, various elements of embodiments of the present invention are in essence the software code defining the operations of such various elements. The executable instructions or software code may be obtained from a readable medium (e.g., a hard drive media, optical media, RAM, EPROM, EEPROM, tape media, cartridge media, flash memory, ROM, memory stick, and/or the like). In fact, readable media can include any medium that can store information.
Computer system 300 also preferably includes random access memory (RAM) 303, which may be SRAM, DRAM, SDRAM, or the like. In this example, computer system 300 uses RAM 303 to store requests and responses. Computer system 300 preferably includes read-only memory (ROM) 304 which may be PROM, EPROM, EEPROM, or the like. RAM 303 and ROM 304 hold user and system data and programs, as is well known in the art.
Computer system 300 also preferably includes input/output (I/O) adapter 305, communications adapter 311, user interface adapter 308, and display adapter 309. I/O adapter 305, user interface adapter 308, and/or communications adapter 311 may, in certain embodiments, enable a user to interact with computer system 300 in order to input information, such as selection of tests to be run.
I/O adapter 305 preferably connects to storage device(s) 306, such as one or more of hard drive, compact disc (CD) drive, floppy disk drive, tape drive, etc. to computer system 300. The storage devices may be utilized when RAM 303 is insufficient for the memory requirements associated with storing media data. Communications adapter 311 is preferably adapted to couple computer system 300 to network 312 (e.g., the Internet, a LAN, a cellular network, etc.). User interface adapter 308 couples user input devices, such as keyboard 313, pointing device 307, and microphone 314 and/or output devices, such as speaker(s) 315 to computer system 300. Display adapter 309 is driven by CPU 301 to control the display on display device 310 to, for example, display test results.
It should be noted that the exact configuration of a portion of a system according to various embodiments may be slightly different. For example, devices according to one or more embodiments may be any kind of processor-based device, such as a general-purpose computer, a cell phone, a Personal Digital Assistant, and/or the like. Additionally, servers (e.g., servers 14 and 16) according to one or more embodiments may be any kind of processor-based device capable of sending data, such as a personal computer, a server-type computer, and the like. Moreover, embodiments of the present invention may be implemented on application specific integrated circuits (ASICs) or very large scale integrated (VLSI) circuits. In fact, persons of ordinary skill in the art may utilize any number of suitable structures capable of executing logical operations according to the embodiments of the present invention.
Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the invention as defined by the appended claims. Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification. As one of ordinary skill in the art will readily appreciate from the disclosure of the present invention, processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized according to the present invention. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.