CA2360959A1 - Tester for url addressable computer applications - Google Patents
Tester for url addressable computer applications Download PDFInfo
- Publication number
- CA2360959A1 CA2360959A1 CA 2360959 CA2360959A CA2360959A1 CA 2360959 A1 CA2360959 A1 CA 2360959A1 CA 2360959 CA2360959 CA 2360959 CA 2360959 A CA2360959 A CA 2360959A CA 2360959 A1 CA2360959 A1 CA 2360959A1
- Authority
- CA
- Canada
- Prior art keywords
- application
- url
- test case
- addressable
- servlets
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer And Data Communications (AREA)
- Debugging And Monitoring (AREA)
- Information Transfer Between Computers (AREA)
Abstract
A method and apparatus that has the ability to create, manage, and execu te collections of test cases that provide both valid and invalid input to URL addressable programs, including servlets and JSPs. The servlet tester automatically detects all servlets and JSPs that are installed on a web application server. Alternatively, the servlet tester permits a user to enter a URL for an application that may reside on a different server. The servlet tester presents the list of URL addressable programs and test cases, if any, to the developer. In the preferred embodiment, the servlet tester is a servlet that runs on a web application server that detects the installed servlets and JSPs, and present s the developer with a web browser based user interface. The test cases may be stored in XML format that can easily be generated by test case generation tools to further automate th e testing process. The test cases generated by the servlet are not defined or constrained by the input form and defined parameters with invalid values. Test cases can be stored on the server with the application and thus, can be accessed simultaneously by multiple developers using different tools.
Description
TESTER FOR URL ADDRESSABLE COMPUTER APPLICATIONS
TECHNICAL FIELD
This application relates generally to the field of computer software applications and more particularly relates to creating, managing, and executing test cases for Uniform Resource Locator (URL) addressable computer applications.
BACKGROUND OF THE INVENTION
Like everything else, computer use has changed over the years. In the early days, large mainframe computers dominated the industry until the advent of the stand-alone computer. Now many businesses and homes have at least one stand-alone computer with more computing power than a large mainframe computer of years ago. A new paradigm of computing, moreover, has emerged: network-centric computing ordistributed computing in which at least two, but more likely many more computers, called clients and servers, are interconnected through a network wherein the software applications used by a client resides on a server. Thus, a server may provide the application or client program or databases used by an end user or by a number of other servers and clients over a network. In many instances and increasingly more so, the network connecting clients and servers is the Internet. The Internet refers to a collection of interconnected computer networks that use an Internet protocol, e.g., TCP/IP, UDP, etc. A server which accesses the Internet is said to be a web server. The World Wide Web (the Web or web) refers to a software management scheme to access the Internet with various user agents using hypertext links. An Internet network path to servers is identified by a URL
having a known syntax for defining a network connection. HyperText Transfer Protocol (HTTP) is a request-response protocol used by web browsers and other clients to access a web server.
Languages that describe data over the Internet, moreover, include many variations and flavors of mark-up languages such as extensible mark-up languages (XML), such as hypertext mark-up language (HTML), wireless mark-up language (WML), etc.
Distributed computing has fundamentally changed the methodology of software developers in writing code for these applications. Rather than writing one massive self-contained application having thousands or millions of lines of code, software developers now select and weave together smaller portions of code, called components, each associated with a particular function that can be reused across multiple applications, all on the Internet or other network. Current industry architectures for Internet and web applications, moreover, require that business or application logic be separated from presentation logic such that the business logic is solely responsible for providing business data while the presentation logic is solely responsible for driving presentation or the user interface. Presentation logic may frequently change to accommodate updating of information and web pages, etc.
These software applications, i.e., both the application and presentation logic, are written in programming languages that are independent of the operating system of either the server or the client in order to access and use the myriad of applications on the Internet. JAVAT"" is a pervasive and successful programming language developed by Sun Microsystems that is independent of the operating system of a computer. Java applications can be written on one computer and transferred over a network, such as the Internet, to any processing device having a Java Virtual Machine (JVM) regardless of the hardware or software in the receiving machine, also having a JVM, which allows interpretation and execution of Java bytecode. Thus, Java applications can be written on one server and then transferred over the web to multiple clients/servers. In fact, Java applications are often interactive across many clients and servers, such as, for instance, a person buying a book online, applying for a mortgage, registering for access to a web site, etc. across the I nternet.
A servlet is a module of Java bytecode that executes in a server application to answer client requests. JavaServer Pages (JSPs) refers to a server-side scripting language based on the servlet framework that combines HTML text with Java source code in the same document. These servlets perform application logic that writes runtime data and reads user input, also in real time.
Servlets are not tied to a specific client-server protocol but they are most commonly used with HTTP and the word "servlet" is often used in the meaning of "HTTP
servlet."
Because servlets are written in the highly portable Java language and follow a standard framework, they provide a means to create sophisticated server extensions independent of the server and operating system. Typical uses for HTTP servlets include:
processing and/or storing data submitted by an HTML form; providing dynamic content, e.g.
returning the results of a database query to the client; managing state information on top of the stateless HTTP, e.g. for an online shopping cart system which manages shopping carts for many concurrent customers and maps every request to the right customer.
The traditional way of adding functionality to a web server is the Common Gateway Interface (CGI), a language-independent interface that allows a server to start an external process which gets information about a request through environment variables, the command line and its standard input stream. The CGI then writes response data to its standard output stream. Each request is answered in a separate process by a separate instance of the CGI program, or CGI script, often called script called because CGI
programs are usually written in interpreted languages like Perl.
Servlets have several advantages over CGI. First, a servlet does not run in a separate process. This removes the overhead of creating a new process for each request:
A servlet stays in memory between requests. A CGI program, and most likely an extensive runtime system or interpreter, needs to be loaded and started for each CGI
request.
Another advantage is that a servlet requires only a single instance which answers all requests concurrently; this saves memory and allows a servletto easily manage persistent data. A servlet, moreover, may allow secure use of untrusted and potentially harmful servlets.
The service method of an HTTP servlet dispatches a request to different Java methods for different HTTP request methods. It recognizes the standard HTTP/1.1 methods of GET, HEAD, PUT, POST, DELETE, OPTIONS and TRACE. Other methods are answered with a Bad Request HTTP error. On the Internet, when requesting a specific web site, a user requests the URL and the GET method is used. A GET request does not have a body, i.e. the body is empty. The response, however, may contain a body with the response data and header fields which describe the body, especially content-type and content-encoding. When an end user sends an HTML form over the Internet, either a GET
or POST method may be used. With a GET request the parameters are encoded in the URL whereas with a POST request they are transmitted in the body. HTML editors and upload tools use PUT requests to upload resources to a web server and DELETE
requests to delete resources.
In the course of developing Web applications, developers need to create, manage, and execute collections of test cases that provide both valid and invalid input to servlets, JSPs and other URL addressable programs. There are standard software testing tools that can be applied to testing web applications. These standard tools, however, record and replay user input constrained to the user interface, such as keystrokes. For example, in a web application, input to a servlet might be provided through an HTML input form. A
standard testing tool can therefore only generate input parameters having those exact fields and in some instances, at that exact location on the user interface. As anyone who has used the Internet for more than a day knows, web pages of which servlets are an essential part constantly change. By constraining a test case to a particular HTML format or user interface, when a web page changes, the test case may no longer be valid.
There is thus a need in the industry to allow test cases to test servlets independent of the HTML or other display format. It is also desirable to determine all the servlets and JSPs that are installed on an application server so that the tester can easily determine if there is adequate test coverage.
JavaT"" is a trademark of Sun Microsystems, Inc., WindowsT"" is a trademark of Microsoft, Inc. and zSeriesT"" , xSeriesT"" , pSeriesT"" , iSeriesT"" , AS/400T"", VisualAgeT"", WebSphere StudioT"", and WebFacing TooIT"" are trademarks of International Business Machines Corporation.
SUMMARY OF THE INVENTION
These needs and others that will become apparent to one skilled in the art are satisfied by a method to test a URL-addressable computer application, comprising the steps of: locating the URL-addressable computer application; creating a test case for the application; and storing the test case in a mark-up language.
The method may further bypass a normal HTML user interface of the application.
The method may also create new HTML user interface from the test case stored in XML.
The new HTML user interface of the test case may be converted from XML to an application layer protocol request and the application layer protocol request is sent to the application wherein the application may respond to the request. The application layer protocol may be HTTP/HTTPS; it may be SMTP; or it may be FTP.
Converting the new HTML user interface to an application layer protocol request and sending the request to the application may be accomplished by a web browser.
The web browser may be on a client and the URL addressable application may be on a server. The user may use the a client to specify the URL addressable application residing on a server and yet, still use a different server to create and store the test case, to bypass the normal HTML user interface of the application, and to create the new HTML user interface from the test case.
The method may automatically locate a plurality of URL-addressable applications.
These URL-addressable applications may reside on a classpath within a server executing the method; may be associated with at least one web application on a server executing the method; or may be located underneath a document root on the server executing the method.
Alternatively, the user may specify the URL addressable application. The URL
addressable application may be on a server other than the server executing the method.
The application may be accessed through a network that supports TCP/IP. The application may be a servlet; a CGI program; and/or a JavaServer Page.
The invention is further envisioned as a development tool to create and manage test cases for URL-addressable applications, comprising: a searcher that locates and displays a URL of at least one URL-addressable application and at least one test case associated with the application, if any test cases exist; a selector to select the test case, if any exist, to execute; a test case generator to create and/or modify the test case; and a translator to translate the selected, modified, and/or created test case to an HTML file.
The development tool may further comprise a connection to a web browser which transfers the test case from a display format file into a test case request in an application layer protocol to the URL-addressable application. The development tool may also have a receiver to receive a response directed from the URL-addressable application to the web browser and to receive the response to determine if it is appropriate given the test case request. The test case may be described in a mark-up language, such as, for example, XML or the like.
The display format file may comprise an HTML file or other file used to define the presentation aspects of content (eg. Font, font size, colors, graphic elements, etc.) Other display formats include SGML, XHTML and VRML .
The invention is also a program product for use in a server for creating, storing, and managing test cases for a URL addressable application that understands HTTP, the computer program product comprising a signal-bearing medium carrying thereon:
an application locator of the URL addressable application; a test case locator and manager of any test cases associated with the URL addressable application; a mark-up language reader/writer to readlcreate mark-up language files of the test cases; a converter of the mark-up language files to display format files of the test case; a test case interpreter to read the response from the URL addressable application to a request derived from the display format files of the test case; and a safekeeper to store and manage the mark-up language test cases with the association URL addressable application.
The invention is also a program product for use in a computer network, comprising a signal-bearing medium carrying thereon a plurality of test cases applicable to a URL
addressable application accessible with a TCP/IP protocol over a network.
It is further considered that the invention is a computer system for developing software, comprising: a central processing unit; a main memory connected to the central processing unit with a communication bus; a data storage unit connected to a data storage interface which is connected to the communication bus; at least one input/output device connected to the communication bus and connected to a network interface to an external computer network; a tester stored in the main memory and capable of executing on the central processing unit to generate, store, and manage at least one test case in a mark-up language; the tester to make a display format file from the mark-up language test case; a web browser to convert the display format file to an application layer protocol request and to forward the request to an application; and the application, the application having a URL
address and accessible through a bus and/or network that can service the application protocol request and generate a response thereto.
The invention is further a servlet tester, comprising: means to locate one or more URL-addressable servlets; means to list the one or more URL-addressable servlets and any test cases for each of the one or more servlets; means to read mark-up language files of the test cases for the one or more servlets; means to create a mark-up language file of a test case for the one or more servlets; means to modify the mark-up language file of a test case for the one or more servlets; means to store the created and/or modified mark-up language file of a test case for the one or more servlets; means to transform the mark-up language file to a display format file; means to convert the display format file to an application layer protocol request to the one or more servlets; and means to interpret a response to the request from the one or more servlets to determine if the one or more servlets are functioning properly.
The list of test cases are preferably displayed on web pages on the Internet, and/or it may be displayed on a network selected from the group consisting of: an internal network, an Intranet, a LAN, a WAN, an internal bus, a wireless network.
Although the test cases may be stored in XML format or other mark-up language, the web-language file may be an HTML file and/or a WML file.
BRIEF DESCRIPTION OF THE DRAWING
Additional features and advantages of the invention will further be described below with regard to the Drawing, wherein:
Figure 1 is a high-level block diagram of a computer system in which a developer may use to develop test cases for a servlet or in which a user may access URL
addressable applications in accordance with an embodiment of the invention.
Figure 2 is a simplified diagram of a computer network, such as the Internet.
Figures 3-14 are illustrations of graphical user interfaces of an embodiment of the invention to create and test a simple servlet in accordance with an embodiment of the invention.
Figure 15 is a simplified flow chart of the method used by the servlet tester in accordance with an embodiment of the invention. It is suggested that Figure 15 be printed on the face of the patent.
DETAILED DESCRIPTION OF THE INVENTION
Referring to the Drawing, wherein like numbers denote like parts throughout the several views, Figure 1 shows a high-level block diagram of a computer system, also called a server, 100, consistent with an embodiment of the invention. Computer system 100 may comprise central processing unit (CPU) 110, main memory 112, terminal interfaces 116, 118, data storage 122, and a network, e.g., Internet, interface 120. The various devices communicate with each other via internal communications bus 130. CPU 110 is a general-purpose programmable processor, executing instructions stored in memory 112;
while a single CPU is shown in Figure 1, it should be understood that computer systems having multiple CPUs could be used. Memory 112 is a random-access semiconductor memory for storing data and programs; memory is shown conceptually as a single monolithic entity but it is well known that memory is often arranged in a hierarchy of caches and other memory devices. Operating system 140 and applications 150 reside in memory 112. Operating system 140 provides, inter alia, functions such as device interfaces, management of memory pages, management of multiple tasks, etc. as is known in the art.
Examples of such operating systems may include UNIX, WINDOWS-based, OS/400, etc.
Applications 150 may include a server software application, in which case network interface 120 may interact with the server software application 150 to enable computer system 100 to be a network server.
Terminal interfaces 116 and 118 may support the attachment of single or multiple terminals and may be implemented as one or multiple electronic circuit cards or other units.
Data storage 122 preferably comprises one or more rotating magnetic hard disk drive units, although other types of data storage could be used. Network interface 120 provides a physical connection for transmission of data to and from a network. In the preferred embodiment the network is the Internet but the network could also be any smaller self-contained network such as an Intranet, a WAN, a LAN, or other internal or external network using, e.g., telephone transmissions lines, satellites, fiber optics, T1 lines, etc. and any various available technologies. Communications bus 130 supports transfer of data, commands and other information between different devices; while shown in simplified form as a single bus, it is typically structured as multiple buses; and may be arranged in a hierarchical form.
Within the terminal devices may be a display adapter to support a video display 160, which may be a cathode-ray tube display, a flat panel display, or a touch panel, although other display technologies may be used. Also within the terminal devices 116, 118, a keyboard/pointer adapter may supports a keyboard 162 or other input or pointing device 164, depicted as a mouse, it being understood that other forms of input devices could be used. Terminal interfaces 118 may have a storage adapter to support one or more data storage devices 122, which may be rotating magnetic hard disk drives or CD-ROM
drives 166, although other data storage devices could be used. Terminal interfaces 116, 118 may also have a printer adapter for a connected network or stand-alone printer 168. The terminal interfaces 116, 118 may support any of a variety of additional devices, such as audio devices, etc. Network interface 120 provides a physical interface to a network, such as the Internet. This interface may comprise a modem connected to a telephone line through which an Internet access provider or on-line service provider is reached, but increasingly other higher bandwidth interfaces are implemented. For example, computer 100 may be connected to another network server via a local area network using an Ethernet, Token Ring, or other protocol, the second network server. in turn being connected to the Internet. Alternatively, network interface 105 may be provided through cable television, fiber optics, satellites, wireless, or other connections. The representation of Figure 1 is intended as an exemplary simplified representation of a high-end computer server, it being understood that in other servers 100 many variations in system configuration are possible in addition to those mentioned here. While system 100 could conceivably be a personal computer system, the computer 100 may also be a larger computer system such as a zSeries, an xSseries, an iSeries, or a pSeries server from I BM
or a similar computer server manufactured by other companies. While a particular hardware configuration is described herein along with various alternatives, the methods described could in general be practiced using any hardware configuration that allows access to legacy applications across a computer network from a client. CPU 110 is suitably programmed to carry out the preferred embodiment by having development tool applications 150 having a servlet tester as described herein and a network interface 120 that can be used by other connected computers to access a URL addressable application and any test cases of that application, either on server 100 or another server.
Server 100 and its components are shown and described in Figure 1 as a more or less single, self-contained computer system. It is alternatively possible to use multiple computer systems, particularly multiple systems which share a single large database, each having a specialized task. For example, one or more servers 100 could be dedicated to one or more database applications, while one or more other servers 100 could be dedicated to servicing requests received from clients or accessing the Internet.
References herein to a computer system or server should be understood to include either a single computer or a collection of computer systems which provides access to a development tool and URI_ addressable applications via a network.
Figure 2 is a simplified representation of a computer network 200. Computer network 200 is representative of the Internet, which can be described as a known computer network based on the client-server model discussed herein and which communicates data throughout the network using a network protocol, such as TCP/IP, UDP, etc.
Conceptually, the Internet includes a large network of network servers 100 that are accessible by clients 210 through a private Internet access provider 220 or an on-line service provider 230.
Client 210 is a device having a network user agent, such as a web browser.
Client 210 is separate from server 100 upon which a development tool having the servlet tester as described herein may reside and execute and any URL addressable application, which may reside on the same server 100 or a different server. Client 210 may be a personal computer system or a larger computer system such as a server, or a smaller computer system, such as notebook or laptop computer. Finally, client 210 need not be a computer at all, but preferably is a simpler appliance-like client device with less memory such as a network terminal, a thin client, a terminal-like devices, a voice response unit, etc. The convergence of computing, telecommunications and consumer electronics is causing a tremendous growth in the number and variety of pervasive mobile devices as clients 210.
This mobile architecture enables the multitude of clients 210 including laptops, sub-notebooks, handheld computers, such as personal digital assistants and companion devices, and mobile appliances, such as smartphones, pagers, simple messaging devices and wearable devices. Thus when the client system 210 is a mobile device, a display adapter and network interface has a network user agent and supports a variety of multi-modal interfaces including traditional keyboard and mouse interfaces, small text screens, pen, touch screens, speech recognition, text-to-speech and other emerging technologies like wearable devices. A servlet tester enables the use of the computer's applications on its respective client 210.
It is preferably intended that client 210 include any electronic device which may interact with a server 100 through a network user agent, such as a web browser, to access development tool applications residing on a server 100 and pertinent URL
addressable applications which may reside on the same or other servers. Such special-purpose devices for accessing the world wide web, such as an Internet access box for a television set, or a portable wireless web accessing device, which can implement a user agent for the purpose of invoking and executing an application are also intended to be within the scope of a client 200. The development servlet tester tool, moreover, could be implemented by control circuitry through the use of logic gate, programmable logic devices, or other hardware components in lieu of a processor-based system. While various relatively direct paths are shown, it will be understood that Figure 2 is a conceptual representation only, and that a computer network such as the Internet may in fact have a far more complex structure. It is also to be understood that computer network may also be an Intranet or other internal computer network, such as a WAN, a LAN, etc. The invention is particularly useful on the Internet in its preferred embodiment, although it is not intended to be so limited.
As will be described in detail below, aspects of the preferred embodiment pertain to specific method steps implementable on a server 100 or a client 210. In an alternative embodiment, the invention may be implemented as a computer program-product for use with either or both a network server 100 and a client 210. The programs defining the functions of the preferred embodiment can be delivered to the server 100 and/or to the client 210 via a variety of signal-bearing media, which include, but are not limited to: (a) information permanently stored on non-writable storage media, e.g., read only memory devices within either computer such as CD-ROM disks readable by CD-ROM drive;
(b) alterable information stored on writeable storage media, e.g., floppy disks within diskette drive or hard-disk drive; or (c) information conveyed to a computer by a telephone or a cable media network, including wireless communications. Such signal-bearing media, when carrying computer-readable instructions that direct the functions of the present invention, represent alternative embodiments of the present invention.
Aspects of this invention may be described as a software development tool, referred to as a servlet tester, intended to create and manage test cases of URL
addressable programs including servlets and JSPs or other CGI programs that understand an application layer protocol, such as HTTP, and use the protocol to transfer requests and information between servers and browsers. The servlet tester may create and manage these test cases over a network, preferably the Internet using TCP/IP and world wide web technology, although other networks, protocols, and other technologies are considered to be within the scope of the invention. Figures 3-14 are illustrations of graphical user interfaces to demonstrate how the servlet tester can be used to create and run a set of test cases for a servlet in accordance with an embodiment of the invention. By way of example only, the user interfaces are graphical. Other user interfaces, such as audible or tactile could also be developed. In a similar vein, the invention is not intended to be limited to IBM's VisualAge, or to servlets, or to Java, or to JSPs; henceforth servlets and JSPs shall be used in the context of any addressable program that creates dynamic data.
Preferably, however, the Internet language is Java and the test cases are stored in an XML
format, and knowing the HTTP methods and parameters stored in the XML file, the servlet generates its own HTML web page for the servlet. A further benefit of the using Java to implement the invention herein is the ability to do the conversion from XML to Java on any operating system that supports Java, including the OS/400, Windows NT, Linux, AIX, etc.
Two simple Java servlets which convert temperature between Celsius and Fahrenheit scales are tested. Each servlet performs error checking on its input and reports a description of the error if one exists. If no error is found, the servlets perform the requested conversion and display the result. Ideally, a developer tests each servlet by creating a set of test cases to check both the error conditions and the conversion applied to valid inputs, and the invention as described herein facilitates the testing to create dependable and correct applications.
The servlet tester allows the developer to test servlets, JSPs, and other URL
addressable programs. In Figure 3, the developer has decided to package his/her servlets in a Java Archive (JAR) file named D:Itesfer-samplelliblconverters.jar and placed the file on the web server classpath. Once this is done, he/she is ready to test the servlets and starts the web server. The graphical user interface is invoked and the user is requested to select an area of the server he/she wishes to explore for existing servlets. As seen in 310, the user may select servlets located in the classpath that are global to the application server. Alternatively, the user may view JSPs located underneath the server's document root as in 312, typically where all the web pages are stored and which is part of the configuration of a web server. A third alternative is to use defined web applications (webapps) as in 314 that may be organized according to the applications or the technology, such as health care applications, employee benefit applications, vacation/sick time applications, etc.
In accordance with another feature of the invention, the user may enter an URL
for an application/servlet, as in 316. The URL-addressed application to be tested may be located on the same server as the tester or remotely across the network on a different server. Thus, the servlet tester may automatically search the server for servlets and JSPs, or the user may enter a URL of a servlet existing on the same or another server. The servlet tester then maintains the lists of servlets and corresponding test cases, preferably in the server having the servlet. The user is given the option to either show the results in frames at 318 or to open the results in a new window 320.
In this instance, upon selecting the option having the servlet tester automatically locates the servlets in the classpath 310, a new screen of Figure 4 is displayed. Figure 4 illustrates that there are three directories having servlets in a particular classpath and in this instance the user selects the classpath entitled D:Itesfer-samplelliblconverters.jar410.
One of the unique features of the servlet tester is that it dynamically checks the classpath for servlets, as in step 412.
Figure 5 illustrates a graphical user interface showing the class tester.sample 510 of the directory chosen in the screen of Figure 4. Now in Figure 6, the class tester. sample displays two servlets: ConvertCelsius 510 and ConvertFahrenheit 612. The user selects ConvertFahrenheif from the screen of Figure 6 and the method herein automatically searches for test cases for the selected servlet. As shown in Figure 7, no test cases were found for the servlet Convert Fahrenheit as indicated 710, and the developer may then add a test case if he/she desires by clicking on the Add button 712.
To create or add a test case for a servlet, a new user interface is called, of which one is shown in Figure 8, which requests further information. An identifier 810 is requested if the user wishes to store the test case and later identify it for fast retrieval. The path of the servlet is automatically presented in 812. The user may then insert a brief description pertaining to the servlet and the test case in the text box at 814. The GET
method is selected by default for the servlet as in 816 but the user may select the POST
method as an alternative. If one wishes to add parameters or if any parameters exist, they can be entered or are displayed in the section indicated as 818. An option exists to allocate the test case as the default test case, as in 820. At 822-832, the user then selects by clicking on the action desired. If the user desires to run the test case, he/she clicks on Run 828, or if he/she wishes to save the test case for a later time, he/she may click on Save 824.
When the test case is run, the stored XML file is retrieved and the servlet tester generates an HTML file. A web browser then typically transforms the HTML file to an application layer protocol request, such as HTTP, and sends the request to the URL-addressable application. Although the preferred embodiment employs a display format file which is in HTML, other display formats (eg. SGML, VRML, XHTML, etc.) could be alternatively employed. The display format file includes display characteristic data (eg.
font size, font type, etc. ) The collection of test cases may be stored in a simple persistent format and can be re-executed during development as the web application evolves. The ability to re-execute a given collection of test cases allows the developer to detect errors introduced by changes to the web application. In the preferred embodiment, the test case is saved in XML. Other mark-up languages could be used in alternative embodiments. This format is extremely advantageous because it allows other developers using other development tools to access and edit the test case, but more importantly, by being saved in XML, the test case is not constrained to the HTML code and to the particular user interface of the servlet. Using XML, it is equally feasible to generate WML to support hand-held devices and other personal digital assistants and user-interfaces other than graphical.
In the example provided, the user decides to add a test case as shown in Figure 9.
The user then enters an I D of error-1910 for the test case; the path 812 remains the same and the user enters the description of 914 as The fahrenheit parameter is undefined.
These entry fields may accept any numeric, text, or other character string data. In this case, the description 914 sets forth the error message. Note that in the parameter entry 818, no parameters have been set forth. When all the required data has been entered, a complete request tests the servlet. More importantly, however, test cases may have only partial or incomplete data and the servlet tester herein can accommodate either or both the complete and partial requests. The servlet tester herein has the capability to bypass the normal user interface and the checks presented by the web application that might normally be rejected by the browser. The servlet tester accomplishes this by generating its own HTML format from the XML file. Preferably, then the web browser generates a request to the servlet in the appropriate application layer protocol, e.g., HTTP for web pages, SMTP
for e-mail programs, FTP for others, Telnet, Gopher, etc. Alternatively, the tester itself may generate a request using the application layer protocol, but the test may not be as faithful as when the browser generates the request.
Thus, the servlet tester allows the developer to define arbitrary test cases to fully exercise the interface of the servlet, JSP, or URL using complete and/or partial requests.
For example, a web user interface might contain JavaScript code that invalidates input before sending it to a servlet, in which case the servlet would never receive invalid input.
Today, it is known that when a web application is deployed to the Internet, hackers will send invalid input to detect security holes. By creating its own HTML
interface, the servlet tester creates and manages test cases that are independent of the application's user interface which in turn allows the developer to create and send invalid inputs to ensure a more robust and error resistant web application. The user may then enter Save 824 and store the test case in a persistent XML file.
The servlet may be run and an actual response from the saved servlet is shown in Figure 10 in which the servlet reports the correct message, i.e., the description 914 of error-1 910. The user may now enter Done 1010 and the servlet tester returns to the previous interface of Figure 7 listing the test cases for that servlet, indicating that the test case error-1 has been successfully added, as shown in Figure 11. The icons to the right of the test case ID indicate to either Run 1110 the test case or Delete 1112 the test case 910.
Figure 12 illustrates the entry of another test case for the class by clicking on Add.
In this example, a valid test case named ok-32 1210 and the description 1214 reads Convert 32 F to 0 C. Note that the user has entered fahrenheit and 32 as a name value pair 1218. The user will click on Save 824 and will then Run 828 the test case with the results shown in Figure 13. Figure 13 illustrates the valid test case ok-32 1210 and indicates that the servlet is functioning properly by the proper conversion and its result.
The developer knows the servlet is good by comparing the result with the description provided. The list of test cases has been updated in Figure 14 to represent that there are two test cases, error-1 910 and ok-32 1210 in the case list under the servlet ConvertFahrenheit. An advantage granted by the servlet tester herein is the ease with which test cases can be managed and rapidly executed. A developer need only bring up the interface listing the test cases and then press the RUN icon 1110 (Figure 11) next to each test case to rapidly invoke the test cases.
Figure 15 is a simplified flow chart of the processes described in Figures 3 through 14. The servlet tester is started at block 1510. The user then has the option of searching for servlets either on the server upon which the tester resides and is executing as in block 1512 or on a different server in which case the tester will prompt the developer for a URL
as in block 1514. If the developer responds by indicating that she/he wishes to search the current server, then the user/developer is asked where she/he would like to search. The tester may provide at least three search paths for the servlets: the classpath as in block 1524; defined web applications as in block 1520; or to search for JavaServer pages which may be underneath the server's document root as in block 1522. In any event, the user/developer selects the servlets she/he wishes to test by either entering a URL as in block 1516 or by selecting the directory and package containing the servlets.
The servlet tester then displays the directories, the packages, the servlets, and test cases, if any, as in block 1530.
The user/developer is asked by the servlet tester if she/he wishes to create or modify a test case as in block 1532. To modify a test case, the user may either click on the servlet and, as in block 1534, the servlet retrieves the XML file of the test case. To create a test case or to modify a test case, the user may enter or change enter a name, identifier, a path, description, and any name value pairs or other parameters, also in block 1534. Given a particular servlet which may have a default test case, the user may be prompted to decide whether the present test case should be the default test case, shown in block 1538. The new or modified test case is converted to HTML, WML, etc.
and the list of test cases are updated and displayed on the user interface as in block 1540.
If the user wishes to run a test case, as in block 1542, the servlet tester forwards the HTML file to a web browser. The web browser then may convert the HTML file to a request in an application layer protocol, such as HTTP/HTTPS, SMTP, FTP, Telnet, Gopher, as in block 1544. The web browser sends the request to the application.
Alternatively, the servlet tester may convert the HTML file to the application layer protocol and send the request to the application/servlet directly not involving the web browser. The test case's response is received in block 1546 and the user/developer can decide whether to accept or reject the test case as being valid/invalid. If the test case is accepted, the test case is saved in XML language as in block 1560.
It is envisioned that the servlet tester may reside on the same or a different server than the application. It is further considered within the scope of the invention that the web browser may reside on a client to access the servlet tester and the URL-addressable application. It is preferred, moreover, that the test cases be stored in XML
format on the same server as the URL-addressable application. This allows the test cases to be remotely accessed by multiple developers simultaneously. Because XML is a standard format, the test cases can be accessed and manipulated by multiple tools, not limited to a web browser. For instance, other tools that generate and/or read and/or execute test cases can access and use these test cases created and managed by the servlet tester described herein. Reports can be written using still different tools that can read XML.
While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example and not limitation and that variations are possible. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
TECHNICAL FIELD
This application relates generally to the field of computer software applications and more particularly relates to creating, managing, and executing test cases for Uniform Resource Locator (URL) addressable computer applications.
BACKGROUND OF THE INVENTION
Like everything else, computer use has changed over the years. In the early days, large mainframe computers dominated the industry until the advent of the stand-alone computer. Now many businesses and homes have at least one stand-alone computer with more computing power than a large mainframe computer of years ago. A new paradigm of computing, moreover, has emerged: network-centric computing ordistributed computing in which at least two, but more likely many more computers, called clients and servers, are interconnected through a network wherein the software applications used by a client resides on a server. Thus, a server may provide the application or client program or databases used by an end user or by a number of other servers and clients over a network. In many instances and increasingly more so, the network connecting clients and servers is the Internet. The Internet refers to a collection of interconnected computer networks that use an Internet protocol, e.g., TCP/IP, UDP, etc. A server which accesses the Internet is said to be a web server. The World Wide Web (the Web or web) refers to a software management scheme to access the Internet with various user agents using hypertext links. An Internet network path to servers is identified by a URL
having a known syntax for defining a network connection. HyperText Transfer Protocol (HTTP) is a request-response protocol used by web browsers and other clients to access a web server.
Languages that describe data over the Internet, moreover, include many variations and flavors of mark-up languages such as extensible mark-up languages (XML), such as hypertext mark-up language (HTML), wireless mark-up language (WML), etc.
Distributed computing has fundamentally changed the methodology of software developers in writing code for these applications. Rather than writing one massive self-contained application having thousands or millions of lines of code, software developers now select and weave together smaller portions of code, called components, each associated with a particular function that can be reused across multiple applications, all on the Internet or other network. Current industry architectures for Internet and web applications, moreover, require that business or application logic be separated from presentation logic such that the business logic is solely responsible for providing business data while the presentation logic is solely responsible for driving presentation or the user interface. Presentation logic may frequently change to accommodate updating of information and web pages, etc.
These software applications, i.e., both the application and presentation logic, are written in programming languages that are independent of the operating system of either the server or the client in order to access and use the myriad of applications on the Internet. JAVAT"" is a pervasive and successful programming language developed by Sun Microsystems that is independent of the operating system of a computer. Java applications can be written on one computer and transferred over a network, such as the Internet, to any processing device having a Java Virtual Machine (JVM) regardless of the hardware or software in the receiving machine, also having a JVM, which allows interpretation and execution of Java bytecode. Thus, Java applications can be written on one server and then transferred over the web to multiple clients/servers. In fact, Java applications are often interactive across many clients and servers, such as, for instance, a person buying a book online, applying for a mortgage, registering for access to a web site, etc. across the I nternet.
A servlet is a module of Java bytecode that executes in a server application to answer client requests. JavaServer Pages (JSPs) refers to a server-side scripting language based on the servlet framework that combines HTML text with Java source code in the same document. These servlets perform application logic that writes runtime data and reads user input, also in real time.
Servlets are not tied to a specific client-server protocol but they are most commonly used with HTTP and the word "servlet" is often used in the meaning of "HTTP
servlet."
Because servlets are written in the highly portable Java language and follow a standard framework, they provide a means to create sophisticated server extensions independent of the server and operating system. Typical uses for HTTP servlets include:
processing and/or storing data submitted by an HTML form; providing dynamic content, e.g.
returning the results of a database query to the client; managing state information on top of the stateless HTTP, e.g. for an online shopping cart system which manages shopping carts for many concurrent customers and maps every request to the right customer.
The traditional way of adding functionality to a web server is the Common Gateway Interface (CGI), a language-independent interface that allows a server to start an external process which gets information about a request through environment variables, the command line and its standard input stream. The CGI then writes response data to its standard output stream. Each request is answered in a separate process by a separate instance of the CGI program, or CGI script, often called script called because CGI
programs are usually written in interpreted languages like Perl.
Servlets have several advantages over CGI. First, a servlet does not run in a separate process. This removes the overhead of creating a new process for each request:
A servlet stays in memory between requests. A CGI program, and most likely an extensive runtime system or interpreter, needs to be loaded and started for each CGI
request.
Another advantage is that a servlet requires only a single instance which answers all requests concurrently; this saves memory and allows a servletto easily manage persistent data. A servlet, moreover, may allow secure use of untrusted and potentially harmful servlets.
The service method of an HTTP servlet dispatches a request to different Java methods for different HTTP request methods. It recognizes the standard HTTP/1.1 methods of GET, HEAD, PUT, POST, DELETE, OPTIONS and TRACE. Other methods are answered with a Bad Request HTTP error. On the Internet, when requesting a specific web site, a user requests the URL and the GET method is used. A GET request does not have a body, i.e. the body is empty. The response, however, may contain a body with the response data and header fields which describe the body, especially content-type and content-encoding. When an end user sends an HTML form over the Internet, either a GET
or POST method may be used. With a GET request the parameters are encoded in the URL whereas with a POST request they are transmitted in the body. HTML editors and upload tools use PUT requests to upload resources to a web server and DELETE
requests to delete resources.
In the course of developing Web applications, developers need to create, manage, and execute collections of test cases that provide both valid and invalid input to servlets, JSPs and other URL addressable programs. There are standard software testing tools that can be applied to testing web applications. These standard tools, however, record and replay user input constrained to the user interface, such as keystrokes. For example, in a web application, input to a servlet might be provided through an HTML input form. A
standard testing tool can therefore only generate input parameters having those exact fields and in some instances, at that exact location on the user interface. As anyone who has used the Internet for more than a day knows, web pages of which servlets are an essential part constantly change. By constraining a test case to a particular HTML format or user interface, when a web page changes, the test case may no longer be valid.
There is thus a need in the industry to allow test cases to test servlets independent of the HTML or other display format. It is also desirable to determine all the servlets and JSPs that are installed on an application server so that the tester can easily determine if there is adequate test coverage.
JavaT"" is a trademark of Sun Microsystems, Inc., WindowsT"" is a trademark of Microsoft, Inc. and zSeriesT"" , xSeriesT"" , pSeriesT"" , iSeriesT"" , AS/400T"", VisualAgeT"", WebSphere StudioT"", and WebFacing TooIT"" are trademarks of International Business Machines Corporation.
SUMMARY OF THE INVENTION
These needs and others that will become apparent to one skilled in the art are satisfied by a method to test a URL-addressable computer application, comprising the steps of: locating the URL-addressable computer application; creating a test case for the application; and storing the test case in a mark-up language.
The method may further bypass a normal HTML user interface of the application.
The method may also create new HTML user interface from the test case stored in XML.
The new HTML user interface of the test case may be converted from XML to an application layer protocol request and the application layer protocol request is sent to the application wherein the application may respond to the request. The application layer protocol may be HTTP/HTTPS; it may be SMTP; or it may be FTP.
Converting the new HTML user interface to an application layer protocol request and sending the request to the application may be accomplished by a web browser.
The web browser may be on a client and the URL addressable application may be on a server. The user may use the a client to specify the URL addressable application residing on a server and yet, still use a different server to create and store the test case, to bypass the normal HTML user interface of the application, and to create the new HTML user interface from the test case.
The method may automatically locate a plurality of URL-addressable applications.
These URL-addressable applications may reside on a classpath within a server executing the method; may be associated with at least one web application on a server executing the method; or may be located underneath a document root on the server executing the method.
Alternatively, the user may specify the URL addressable application. The URL
addressable application may be on a server other than the server executing the method.
The application may be accessed through a network that supports TCP/IP. The application may be a servlet; a CGI program; and/or a JavaServer Page.
The invention is further envisioned as a development tool to create and manage test cases for URL-addressable applications, comprising: a searcher that locates and displays a URL of at least one URL-addressable application and at least one test case associated with the application, if any test cases exist; a selector to select the test case, if any exist, to execute; a test case generator to create and/or modify the test case; and a translator to translate the selected, modified, and/or created test case to an HTML file.
The development tool may further comprise a connection to a web browser which transfers the test case from a display format file into a test case request in an application layer protocol to the URL-addressable application. The development tool may also have a receiver to receive a response directed from the URL-addressable application to the web browser and to receive the response to determine if it is appropriate given the test case request. The test case may be described in a mark-up language, such as, for example, XML or the like.
The display format file may comprise an HTML file or other file used to define the presentation aspects of content (eg. Font, font size, colors, graphic elements, etc.) Other display formats include SGML, XHTML and VRML .
The invention is also a program product for use in a server for creating, storing, and managing test cases for a URL addressable application that understands HTTP, the computer program product comprising a signal-bearing medium carrying thereon:
an application locator of the URL addressable application; a test case locator and manager of any test cases associated with the URL addressable application; a mark-up language reader/writer to readlcreate mark-up language files of the test cases; a converter of the mark-up language files to display format files of the test case; a test case interpreter to read the response from the URL addressable application to a request derived from the display format files of the test case; and a safekeeper to store and manage the mark-up language test cases with the association URL addressable application.
The invention is also a program product for use in a computer network, comprising a signal-bearing medium carrying thereon a plurality of test cases applicable to a URL
addressable application accessible with a TCP/IP protocol over a network.
It is further considered that the invention is a computer system for developing software, comprising: a central processing unit; a main memory connected to the central processing unit with a communication bus; a data storage unit connected to a data storage interface which is connected to the communication bus; at least one input/output device connected to the communication bus and connected to a network interface to an external computer network; a tester stored in the main memory and capable of executing on the central processing unit to generate, store, and manage at least one test case in a mark-up language; the tester to make a display format file from the mark-up language test case; a web browser to convert the display format file to an application layer protocol request and to forward the request to an application; and the application, the application having a URL
address and accessible through a bus and/or network that can service the application protocol request and generate a response thereto.
The invention is further a servlet tester, comprising: means to locate one or more URL-addressable servlets; means to list the one or more URL-addressable servlets and any test cases for each of the one or more servlets; means to read mark-up language files of the test cases for the one or more servlets; means to create a mark-up language file of a test case for the one or more servlets; means to modify the mark-up language file of a test case for the one or more servlets; means to store the created and/or modified mark-up language file of a test case for the one or more servlets; means to transform the mark-up language file to a display format file; means to convert the display format file to an application layer protocol request to the one or more servlets; and means to interpret a response to the request from the one or more servlets to determine if the one or more servlets are functioning properly.
The list of test cases are preferably displayed on web pages on the Internet, and/or it may be displayed on a network selected from the group consisting of: an internal network, an Intranet, a LAN, a WAN, an internal bus, a wireless network.
Although the test cases may be stored in XML format or other mark-up language, the web-language file may be an HTML file and/or a WML file.
BRIEF DESCRIPTION OF THE DRAWING
Additional features and advantages of the invention will further be described below with regard to the Drawing, wherein:
Figure 1 is a high-level block diagram of a computer system in which a developer may use to develop test cases for a servlet or in which a user may access URL
addressable applications in accordance with an embodiment of the invention.
Figure 2 is a simplified diagram of a computer network, such as the Internet.
Figures 3-14 are illustrations of graphical user interfaces of an embodiment of the invention to create and test a simple servlet in accordance with an embodiment of the invention.
Figure 15 is a simplified flow chart of the method used by the servlet tester in accordance with an embodiment of the invention. It is suggested that Figure 15 be printed on the face of the patent.
DETAILED DESCRIPTION OF THE INVENTION
Referring to the Drawing, wherein like numbers denote like parts throughout the several views, Figure 1 shows a high-level block diagram of a computer system, also called a server, 100, consistent with an embodiment of the invention. Computer system 100 may comprise central processing unit (CPU) 110, main memory 112, terminal interfaces 116, 118, data storage 122, and a network, e.g., Internet, interface 120. The various devices communicate with each other via internal communications bus 130. CPU 110 is a general-purpose programmable processor, executing instructions stored in memory 112;
while a single CPU is shown in Figure 1, it should be understood that computer systems having multiple CPUs could be used. Memory 112 is a random-access semiconductor memory for storing data and programs; memory is shown conceptually as a single monolithic entity but it is well known that memory is often arranged in a hierarchy of caches and other memory devices. Operating system 140 and applications 150 reside in memory 112. Operating system 140 provides, inter alia, functions such as device interfaces, management of memory pages, management of multiple tasks, etc. as is known in the art.
Examples of such operating systems may include UNIX, WINDOWS-based, OS/400, etc.
Applications 150 may include a server software application, in which case network interface 120 may interact with the server software application 150 to enable computer system 100 to be a network server.
Terminal interfaces 116 and 118 may support the attachment of single or multiple terminals and may be implemented as one or multiple electronic circuit cards or other units.
Data storage 122 preferably comprises one or more rotating magnetic hard disk drive units, although other types of data storage could be used. Network interface 120 provides a physical connection for transmission of data to and from a network. In the preferred embodiment the network is the Internet but the network could also be any smaller self-contained network such as an Intranet, a WAN, a LAN, or other internal or external network using, e.g., telephone transmissions lines, satellites, fiber optics, T1 lines, etc. and any various available technologies. Communications bus 130 supports transfer of data, commands and other information between different devices; while shown in simplified form as a single bus, it is typically structured as multiple buses; and may be arranged in a hierarchical form.
Within the terminal devices may be a display adapter to support a video display 160, which may be a cathode-ray tube display, a flat panel display, or a touch panel, although other display technologies may be used. Also within the terminal devices 116, 118, a keyboard/pointer adapter may supports a keyboard 162 or other input or pointing device 164, depicted as a mouse, it being understood that other forms of input devices could be used. Terminal interfaces 118 may have a storage adapter to support one or more data storage devices 122, which may be rotating magnetic hard disk drives or CD-ROM
drives 166, although other data storage devices could be used. Terminal interfaces 116, 118 may also have a printer adapter for a connected network or stand-alone printer 168. The terminal interfaces 116, 118 may support any of a variety of additional devices, such as audio devices, etc. Network interface 120 provides a physical interface to a network, such as the Internet. This interface may comprise a modem connected to a telephone line through which an Internet access provider or on-line service provider is reached, but increasingly other higher bandwidth interfaces are implemented. For example, computer 100 may be connected to another network server via a local area network using an Ethernet, Token Ring, or other protocol, the second network server. in turn being connected to the Internet. Alternatively, network interface 105 may be provided through cable television, fiber optics, satellites, wireless, or other connections. The representation of Figure 1 is intended as an exemplary simplified representation of a high-end computer server, it being understood that in other servers 100 many variations in system configuration are possible in addition to those mentioned here. While system 100 could conceivably be a personal computer system, the computer 100 may also be a larger computer system such as a zSeries, an xSseries, an iSeries, or a pSeries server from I BM
or a similar computer server manufactured by other companies. While a particular hardware configuration is described herein along with various alternatives, the methods described could in general be practiced using any hardware configuration that allows access to legacy applications across a computer network from a client. CPU 110 is suitably programmed to carry out the preferred embodiment by having development tool applications 150 having a servlet tester as described herein and a network interface 120 that can be used by other connected computers to access a URL addressable application and any test cases of that application, either on server 100 or another server.
Server 100 and its components are shown and described in Figure 1 as a more or less single, self-contained computer system. It is alternatively possible to use multiple computer systems, particularly multiple systems which share a single large database, each having a specialized task. For example, one or more servers 100 could be dedicated to one or more database applications, while one or more other servers 100 could be dedicated to servicing requests received from clients or accessing the Internet.
References herein to a computer system or server should be understood to include either a single computer or a collection of computer systems which provides access to a development tool and URI_ addressable applications via a network.
Figure 2 is a simplified representation of a computer network 200. Computer network 200 is representative of the Internet, which can be described as a known computer network based on the client-server model discussed herein and which communicates data throughout the network using a network protocol, such as TCP/IP, UDP, etc.
Conceptually, the Internet includes a large network of network servers 100 that are accessible by clients 210 through a private Internet access provider 220 or an on-line service provider 230.
Client 210 is a device having a network user agent, such as a web browser.
Client 210 is separate from server 100 upon which a development tool having the servlet tester as described herein may reside and execute and any URL addressable application, which may reside on the same server 100 or a different server. Client 210 may be a personal computer system or a larger computer system such as a server, or a smaller computer system, such as notebook or laptop computer. Finally, client 210 need not be a computer at all, but preferably is a simpler appliance-like client device with less memory such as a network terminal, a thin client, a terminal-like devices, a voice response unit, etc. The convergence of computing, telecommunications and consumer electronics is causing a tremendous growth in the number and variety of pervasive mobile devices as clients 210.
This mobile architecture enables the multitude of clients 210 including laptops, sub-notebooks, handheld computers, such as personal digital assistants and companion devices, and mobile appliances, such as smartphones, pagers, simple messaging devices and wearable devices. Thus when the client system 210 is a mobile device, a display adapter and network interface has a network user agent and supports a variety of multi-modal interfaces including traditional keyboard and mouse interfaces, small text screens, pen, touch screens, speech recognition, text-to-speech and other emerging technologies like wearable devices. A servlet tester enables the use of the computer's applications on its respective client 210.
It is preferably intended that client 210 include any electronic device which may interact with a server 100 through a network user agent, such as a web browser, to access development tool applications residing on a server 100 and pertinent URL
addressable applications which may reside on the same or other servers. Such special-purpose devices for accessing the world wide web, such as an Internet access box for a television set, or a portable wireless web accessing device, which can implement a user agent for the purpose of invoking and executing an application are also intended to be within the scope of a client 200. The development servlet tester tool, moreover, could be implemented by control circuitry through the use of logic gate, programmable logic devices, or other hardware components in lieu of a processor-based system. While various relatively direct paths are shown, it will be understood that Figure 2 is a conceptual representation only, and that a computer network such as the Internet may in fact have a far more complex structure. It is also to be understood that computer network may also be an Intranet or other internal computer network, such as a WAN, a LAN, etc. The invention is particularly useful on the Internet in its preferred embodiment, although it is not intended to be so limited.
As will be described in detail below, aspects of the preferred embodiment pertain to specific method steps implementable on a server 100 or a client 210. In an alternative embodiment, the invention may be implemented as a computer program-product for use with either or both a network server 100 and a client 210. The programs defining the functions of the preferred embodiment can be delivered to the server 100 and/or to the client 210 via a variety of signal-bearing media, which include, but are not limited to: (a) information permanently stored on non-writable storage media, e.g., read only memory devices within either computer such as CD-ROM disks readable by CD-ROM drive;
(b) alterable information stored on writeable storage media, e.g., floppy disks within diskette drive or hard-disk drive; or (c) information conveyed to a computer by a telephone or a cable media network, including wireless communications. Such signal-bearing media, when carrying computer-readable instructions that direct the functions of the present invention, represent alternative embodiments of the present invention.
Aspects of this invention may be described as a software development tool, referred to as a servlet tester, intended to create and manage test cases of URL
addressable programs including servlets and JSPs or other CGI programs that understand an application layer protocol, such as HTTP, and use the protocol to transfer requests and information between servers and browsers. The servlet tester may create and manage these test cases over a network, preferably the Internet using TCP/IP and world wide web technology, although other networks, protocols, and other technologies are considered to be within the scope of the invention. Figures 3-14 are illustrations of graphical user interfaces to demonstrate how the servlet tester can be used to create and run a set of test cases for a servlet in accordance with an embodiment of the invention. By way of example only, the user interfaces are graphical. Other user interfaces, such as audible or tactile could also be developed. In a similar vein, the invention is not intended to be limited to IBM's VisualAge, or to servlets, or to Java, or to JSPs; henceforth servlets and JSPs shall be used in the context of any addressable program that creates dynamic data.
Preferably, however, the Internet language is Java and the test cases are stored in an XML
format, and knowing the HTTP methods and parameters stored in the XML file, the servlet generates its own HTML web page for the servlet. A further benefit of the using Java to implement the invention herein is the ability to do the conversion from XML to Java on any operating system that supports Java, including the OS/400, Windows NT, Linux, AIX, etc.
Two simple Java servlets which convert temperature between Celsius and Fahrenheit scales are tested. Each servlet performs error checking on its input and reports a description of the error if one exists. If no error is found, the servlets perform the requested conversion and display the result. Ideally, a developer tests each servlet by creating a set of test cases to check both the error conditions and the conversion applied to valid inputs, and the invention as described herein facilitates the testing to create dependable and correct applications.
The servlet tester allows the developer to test servlets, JSPs, and other URL
addressable programs. In Figure 3, the developer has decided to package his/her servlets in a Java Archive (JAR) file named D:Itesfer-samplelliblconverters.jar and placed the file on the web server classpath. Once this is done, he/she is ready to test the servlets and starts the web server. The graphical user interface is invoked and the user is requested to select an area of the server he/she wishes to explore for existing servlets. As seen in 310, the user may select servlets located in the classpath that are global to the application server. Alternatively, the user may view JSPs located underneath the server's document root as in 312, typically where all the web pages are stored and which is part of the configuration of a web server. A third alternative is to use defined web applications (webapps) as in 314 that may be organized according to the applications or the technology, such as health care applications, employee benefit applications, vacation/sick time applications, etc.
In accordance with another feature of the invention, the user may enter an URL
for an application/servlet, as in 316. The URL-addressed application to be tested may be located on the same server as the tester or remotely across the network on a different server. Thus, the servlet tester may automatically search the server for servlets and JSPs, or the user may enter a URL of a servlet existing on the same or another server. The servlet tester then maintains the lists of servlets and corresponding test cases, preferably in the server having the servlet. The user is given the option to either show the results in frames at 318 or to open the results in a new window 320.
In this instance, upon selecting the option having the servlet tester automatically locates the servlets in the classpath 310, a new screen of Figure 4 is displayed. Figure 4 illustrates that there are three directories having servlets in a particular classpath and in this instance the user selects the classpath entitled D:Itesfer-samplelliblconverters.jar410.
One of the unique features of the servlet tester is that it dynamically checks the classpath for servlets, as in step 412.
Figure 5 illustrates a graphical user interface showing the class tester.sample 510 of the directory chosen in the screen of Figure 4. Now in Figure 6, the class tester. sample displays two servlets: ConvertCelsius 510 and ConvertFahrenheit 612. The user selects ConvertFahrenheif from the screen of Figure 6 and the method herein automatically searches for test cases for the selected servlet. As shown in Figure 7, no test cases were found for the servlet Convert Fahrenheit as indicated 710, and the developer may then add a test case if he/she desires by clicking on the Add button 712.
To create or add a test case for a servlet, a new user interface is called, of which one is shown in Figure 8, which requests further information. An identifier 810 is requested if the user wishes to store the test case and later identify it for fast retrieval. The path of the servlet is automatically presented in 812. The user may then insert a brief description pertaining to the servlet and the test case in the text box at 814. The GET
method is selected by default for the servlet as in 816 but the user may select the POST
method as an alternative. If one wishes to add parameters or if any parameters exist, they can be entered or are displayed in the section indicated as 818. An option exists to allocate the test case as the default test case, as in 820. At 822-832, the user then selects by clicking on the action desired. If the user desires to run the test case, he/she clicks on Run 828, or if he/she wishes to save the test case for a later time, he/she may click on Save 824.
When the test case is run, the stored XML file is retrieved and the servlet tester generates an HTML file. A web browser then typically transforms the HTML file to an application layer protocol request, such as HTTP, and sends the request to the URL-addressable application. Although the preferred embodiment employs a display format file which is in HTML, other display formats (eg. SGML, VRML, XHTML, etc.) could be alternatively employed. The display format file includes display characteristic data (eg.
font size, font type, etc. ) The collection of test cases may be stored in a simple persistent format and can be re-executed during development as the web application evolves. The ability to re-execute a given collection of test cases allows the developer to detect errors introduced by changes to the web application. In the preferred embodiment, the test case is saved in XML. Other mark-up languages could be used in alternative embodiments. This format is extremely advantageous because it allows other developers using other development tools to access and edit the test case, but more importantly, by being saved in XML, the test case is not constrained to the HTML code and to the particular user interface of the servlet. Using XML, it is equally feasible to generate WML to support hand-held devices and other personal digital assistants and user-interfaces other than graphical.
In the example provided, the user decides to add a test case as shown in Figure 9.
The user then enters an I D of error-1910 for the test case; the path 812 remains the same and the user enters the description of 914 as The fahrenheit parameter is undefined.
These entry fields may accept any numeric, text, or other character string data. In this case, the description 914 sets forth the error message. Note that in the parameter entry 818, no parameters have been set forth. When all the required data has been entered, a complete request tests the servlet. More importantly, however, test cases may have only partial or incomplete data and the servlet tester herein can accommodate either or both the complete and partial requests. The servlet tester herein has the capability to bypass the normal user interface and the checks presented by the web application that might normally be rejected by the browser. The servlet tester accomplishes this by generating its own HTML format from the XML file. Preferably, then the web browser generates a request to the servlet in the appropriate application layer protocol, e.g., HTTP for web pages, SMTP
for e-mail programs, FTP for others, Telnet, Gopher, etc. Alternatively, the tester itself may generate a request using the application layer protocol, but the test may not be as faithful as when the browser generates the request.
Thus, the servlet tester allows the developer to define arbitrary test cases to fully exercise the interface of the servlet, JSP, or URL using complete and/or partial requests.
For example, a web user interface might contain JavaScript code that invalidates input before sending it to a servlet, in which case the servlet would never receive invalid input.
Today, it is known that when a web application is deployed to the Internet, hackers will send invalid input to detect security holes. By creating its own HTML
interface, the servlet tester creates and manages test cases that are independent of the application's user interface which in turn allows the developer to create and send invalid inputs to ensure a more robust and error resistant web application. The user may then enter Save 824 and store the test case in a persistent XML file.
The servlet may be run and an actual response from the saved servlet is shown in Figure 10 in which the servlet reports the correct message, i.e., the description 914 of error-1 910. The user may now enter Done 1010 and the servlet tester returns to the previous interface of Figure 7 listing the test cases for that servlet, indicating that the test case error-1 has been successfully added, as shown in Figure 11. The icons to the right of the test case ID indicate to either Run 1110 the test case or Delete 1112 the test case 910.
Figure 12 illustrates the entry of another test case for the class by clicking on Add.
In this example, a valid test case named ok-32 1210 and the description 1214 reads Convert 32 F to 0 C. Note that the user has entered fahrenheit and 32 as a name value pair 1218. The user will click on Save 824 and will then Run 828 the test case with the results shown in Figure 13. Figure 13 illustrates the valid test case ok-32 1210 and indicates that the servlet is functioning properly by the proper conversion and its result.
The developer knows the servlet is good by comparing the result with the description provided. The list of test cases has been updated in Figure 14 to represent that there are two test cases, error-1 910 and ok-32 1210 in the case list under the servlet ConvertFahrenheit. An advantage granted by the servlet tester herein is the ease with which test cases can be managed and rapidly executed. A developer need only bring up the interface listing the test cases and then press the RUN icon 1110 (Figure 11) next to each test case to rapidly invoke the test cases.
Figure 15 is a simplified flow chart of the processes described in Figures 3 through 14. The servlet tester is started at block 1510. The user then has the option of searching for servlets either on the server upon which the tester resides and is executing as in block 1512 or on a different server in which case the tester will prompt the developer for a URL
as in block 1514. If the developer responds by indicating that she/he wishes to search the current server, then the user/developer is asked where she/he would like to search. The tester may provide at least three search paths for the servlets: the classpath as in block 1524; defined web applications as in block 1520; or to search for JavaServer pages which may be underneath the server's document root as in block 1522. In any event, the user/developer selects the servlets she/he wishes to test by either entering a URL as in block 1516 or by selecting the directory and package containing the servlets.
The servlet tester then displays the directories, the packages, the servlets, and test cases, if any, as in block 1530.
The user/developer is asked by the servlet tester if she/he wishes to create or modify a test case as in block 1532. To modify a test case, the user may either click on the servlet and, as in block 1534, the servlet retrieves the XML file of the test case. To create a test case or to modify a test case, the user may enter or change enter a name, identifier, a path, description, and any name value pairs or other parameters, also in block 1534. Given a particular servlet which may have a default test case, the user may be prompted to decide whether the present test case should be the default test case, shown in block 1538. The new or modified test case is converted to HTML, WML, etc.
and the list of test cases are updated and displayed on the user interface as in block 1540.
If the user wishes to run a test case, as in block 1542, the servlet tester forwards the HTML file to a web browser. The web browser then may convert the HTML file to a request in an application layer protocol, such as HTTP/HTTPS, SMTP, FTP, Telnet, Gopher, as in block 1544. The web browser sends the request to the application.
Alternatively, the servlet tester may convert the HTML file to the application layer protocol and send the request to the application/servlet directly not involving the web browser. The test case's response is received in block 1546 and the user/developer can decide whether to accept or reject the test case as being valid/invalid. If the test case is accepted, the test case is saved in XML language as in block 1560.
It is envisioned that the servlet tester may reside on the same or a different server than the application. It is further considered within the scope of the invention that the web browser may reside on a client to access the servlet tester and the URL-addressable application. It is preferred, moreover, that the test cases be stored in XML
format on the same server as the URL-addressable application. This allows the test cases to be remotely accessed by multiple developers simultaneously. Because XML is a standard format, the test cases can be accessed and manipulated by multiple tools, not limited to a web browser. For instance, other tools that generate and/or read and/or execute test cases can access and use these test cases created and managed by the servlet tester described herein. Reports can be written using still different tools that can read XML.
While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example and not limitation and that variations are possible. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
Claims (30)
1. A method to test a URL-addressable computer application, comprising:
(a) locating the URL-addressable computer application;
(b) creating a test case for the application; and (c) storing the test case in a mark-up language.
(a) locating the URL-addressable computer application;
(b) creating a test case for the application; and (c) storing the test case in a mark-up language.
2. The method of claim 1, further comprising:
(a) bypassing a normal HTML user interface of the application.
(a) bypassing a normal HTML user interface of the application.
3. The method of claim 2, further comprising:
(a) creating a new HTML user interface from the test case stored in the mark-up language.
(a) creating a new HTML user interface from the test case stored in the mark-up language.
4. The method of claim 3 where the mark-up language is XML.
5. The method of claim 4, further comprising:
(a) converting the new HTML user interface of the test case from XML to an application layer protocol request;
(b) sending the application layer protocol request to the application; and (c) the application responding to the request.
(a) converting the new HTML user interface of the test case from XML to an application layer protocol request;
(b) sending the application layer protocol request to the application; and (c) the application responding to the request.
6. The method of claim 5, wherein the application layer protocol is HTTP/HTTPS.
7. The method of claim 5, wherein the application layer protocol is SMTP.
8. The method of claim 5, wherein the application layer protocol is FTP.
9. The method of claim 5, wherein the steps of converting the new HTML user interface to an application layer protocol request and sending the request to the application are accomplished by a web browser.
10. The method of claim 5, further comprising:
(a) automatically locating a plurality of URL-addressable applications.
(a) automatically locating a plurality of URL-addressable applications.
11. The method of claim 10, wherein the plurality of URL-addressable applications are on a classpath within a server executing the method of claim 10.
12. The method of claim 10, wherein the plurality of URL-addressable applications are associated with at least one web application on a server executing the method of claim 10.
13. The method of claim 10, wherein the plurality of URL-addressable applications are located underneath a document root on a server executing the method of claim 10.
14. The method of claim 5, wherein a user may specify the URL addressable application.
15. The method of claim 14, wherein the URL addressable application may be on a server other than the server executing the method of claim 14.
16. The method of claim 9, wherein the web browser may be on a client and the URL
addressable application may be on a server.
addressable application may be on a server.
17. The method of claim 16, further comprising:
(a) using a client to specify the URL addressable application residing on a server;
(b) using a different server to create and store the test case, to bypass the normal HTML user interface of the application, and to create the new HTML
user interface from the test case.
(a) using a client to specify the URL addressable application residing on a server;
(b) using a different server to create and store the test case, to bypass the normal HTML user interface of the application, and to create the new HTML
user interface from the test case.
18. The method of claim 15, wherein the application is accessed through a network that supports TCP/IP.
19. The method of claim 5, wherein the application is a servlet.
20. The method of claim 5, wherein the application is a JavaServer Page.
21. A development tool to create and manage test cases for URL-addressable applications, comprising:
(a) a searcher that locates and displays a URL of at least one URL-addressable application and at least one test case associated with each of the at least one URL-addressable application, if any test cases exist;
(b) a selector to select the at least one test case, if any exist, to execute;
(c) a test case generator to create and/or modify the at least one test case;
and (d) a translator to translate the selected, modified, and/or created at least one test case to a file in a display format.
(a) a searcher that locates and displays a URL of at least one URL-addressable application and at least one test case associated with each of the at least one URL-addressable application, if any test cases exist;
(b) a selector to select the at least one test case, if any exist, to execute;
(c) a test case generator to create and/or modify the at least one test case;
and (d) a translator to translate the selected, modified, and/or created at least one test case to a file in a display format.
22. The development tool of claim 21, further comprising:
(a) a call to a web browser which transfer the at least one test case from a file in a display format into a test case request in an application layer protocol to the at least one URL-addressable application.
(a) a call to a web browser which transfer the at least one test case from a file in a display format into a test case request in an application layer protocol to the at least one URL-addressable application.
23. The development tool of claim 22, further comprising:
(a) a receiver to receive a response directed from the at least one URL-addressable application to the web browser and to receive the response to determine if it is appropriate given the test case request.
(a) a receiver to receive a response directed from the at least one URL-addressable application to the web browser and to receive the response to determine if it is appropriate given the test case request.
24. The development tool of claim 23 wherein the at least one test case is in XML and the display format comprises HTML.
25. A program product for use in a server for creating, storing, and managing test cases for a URL addressable application that understands HTTP, said computer program product comprising a signal-bearing medium carrying thereon:
(a) an application locator of the URL addressable application;
(b) a test case locator and manager of any test cases associated with the URL
addressable application;
(c) a mark-up language reader/writer to read/create mark-up language files of the test cases;
(d) a converter of the mark-up language files to display format files of the test case;
(e) a test case interpreter to read the response from the URL addressable application to a request derived from the display format files of the test case;
and (f) a safekeeper to store and manage the mark-up test cases with the association URL addressable application.
(a) an application locator of the URL addressable application;
(b) a test case locator and manager of any test cases associated with the URL
addressable application;
(c) a mark-up language reader/writer to read/create mark-up language files of the test cases;
(d) a converter of the mark-up language files to display format files of the test case;
(e) a test case interpreter to read the response from the URL addressable application to a request derived from the display format files of the test case;
and (f) a safekeeper to store and manage the mark-up test cases with the association URL addressable application.
26. The program product of claim 25 wherein the mark-up language comprises XML
and the display format comprises HTML.
and the display format comprises HTML.
27. A program product for use in a computer network, said computer program product comprising a signal-bearing medium carrying thereon a plurality of test cases applicable to at least one URL addressable application that is accessed using a TCP/IP protocol over a network.
28. A computer system for developing software, comprising:
(a) a central processing unit;
(b) a main memory connected to the central processing unit with a communication bus;
(c) a data storage unit connected to a data storage interface which is connected to said communication bus;
(d) at least one input/output device connected to said communication bus and connected to a network interface to an external computer network, (e) a tester stored in said main memory and capable of executing on said central processing unit to generate, store, and manage at least one test case in mark-up language; the tester to make a display format file from the test case;
(f) a web browser to convert the display format file to an application layer protocol request and to forward the request to an application; and (g) the application, the application having a URL address and accessible through a bus and/or network that can service the application protocol request and generate a response thereto.
(a) a central processing unit;
(b) a main memory connected to the central processing unit with a communication bus;
(c) a data storage unit connected to a data storage interface which is connected to said communication bus;
(d) at least one input/output device connected to said communication bus and connected to a network interface to an external computer network, (e) a tester stored in said main memory and capable of executing on said central processing unit to generate, store, and manage at least one test case in mark-up language; the tester to make a display format file from the test case;
(f) a web browser to convert the display format file to an application layer protocol request and to forward the request to an application; and (g) the application, the application having a URL address and accessible through a bus and/or network that can service the application protocol request and generate a response thereto.
29. The computer system of claim 28 wherein the mark-up language comprises XML
and the display format file comprises a HTML file.
and the display format file comprises a HTML file.
30. A servlet tester, comprising:
(a) means to locate one or more URL-addressable servlets;
(b) means to list the one or more URL-addressable servlets and any test cases for each of the one or more servlets;
(c) means to read mark-up language files of the test cases for the one or more servlets;
(d) means to create an mark-up language file of a test case for the one or more servlets;
(e) means to modify the mark-up language file of a test case for the one or more servlets;
(f) means to store the created and/or modified mark-up language file of a test case for the one or more servlets;
(g) means to transform the mark-up language file to a display format file;
(h) means to convert the display format file to an application layer protocol request to the one or more servlets; and (i) means to interpret a response to the request from the one or more servlets to determine if the one or more servlets are functioning properly.
(a) means to locate one or more URL-addressable servlets;
(b) means to list the one or more URL-addressable servlets and any test cases for each of the one or more servlets;
(c) means to read mark-up language files of the test cases for the one or more servlets;
(d) means to create an mark-up language file of a test case for the one or more servlets;
(e) means to modify the mark-up language file of a test case for the one or more servlets;
(f) means to store the created and/or modified mark-up language file of a test case for the one or more servlets;
(g) means to transform the mark-up language file to a display format file;
(h) means to convert the display format file to an application layer protocol request to the one or more servlets; and (i) means to interpret a response to the request from the one or more servlets to determine if the one or more servlets are functioning properly.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA 2360959 CA2360959A1 (en) | 2001-11-02 | 2001-11-02 | Tester for url addressable computer applications |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA 2360959 CA2360959A1 (en) | 2001-11-02 | 2001-11-02 | Tester for url addressable computer applications |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2360959A1 true CA2360959A1 (en) | 2003-05-02 |
Family
ID=4170415
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA 2360959 Abandoned CA2360959A1 (en) | 2001-11-02 | 2001-11-02 | Tester for url addressable computer applications |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2360959A1 (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111858357A (en) * | 2020-07-23 | 2020-10-30 | 杭州安恒信息技术股份有限公司 | Performance test monitoring method, equipment and related equipment |
| CN112637192A (en) * | 2020-12-17 | 2021-04-09 | 航天精一(广东)信息科技有限公司 | Authorization method and system for accessing micro-service |
| CN115203057A (en) * | 2022-08-16 | 2022-10-18 | 北京永洪商智科技有限公司 | Low code test automation method, device, equipment and storage medium |
-
2001
- 2001-11-02 CA CA 2360959 patent/CA2360959A1/en not_active Abandoned
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111858357A (en) * | 2020-07-23 | 2020-10-30 | 杭州安恒信息技术股份有限公司 | Performance test monitoring method, equipment and related equipment |
| CN111858357B (en) * | 2020-07-23 | 2024-02-02 | 杭州安恒信息技术股份有限公司 | Performance test monitoring method and equipment and related equipment thereof |
| CN112637192A (en) * | 2020-12-17 | 2021-04-09 | 航天精一(广东)信息科技有限公司 | Authorization method and system for accessing micro-service |
| CN112637192B (en) * | 2020-12-17 | 2023-10-03 | 广东精一信息技术有限公司 | Authorization method and system for accessing micro-service |
| CN115203057A (en) * | 2022-08-16 | 2022-10-18 | 北京永洪商智科技有限公司 | Low code test automation method, device, equipment and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5999941A (en) | Database access using active server pages | |
| US7882497B2 (en) | Symbiotic computer application and system and method for generation and presentation of same | |
| US8447806B2 (en) | Method and apparatus for updating and synchronizing information between a client and a server | |
| US6189000B1 (en) | System and method for accessing user properties from multiple storage mechanisms | |
| US20030115572A1 (en) | System, method and computer program product for application development using a visual paradigm to combine existing data and applications | |
| EP1156427B1 (en) | Postback input handling by server-side control objects | |
| Liu et al. | Object-based data flow testing of web applications | |
| US8260844B2 (en) | Information messaging and collaboration system | |
| US7421679B2 (en) | Method, apparatus and interface for testing web services | |
| US5987517A (en) | System having a library of protocol independent reentrant network interface functions for providing common calling interface for communication and application protocols | |
| US20020032706A1 (en) | Method and system for building internet-based applications | |
| US20020169789A1 (en) | System and method for accessing, organizing, and presenting data | |
| US20030097593A1 (en) | User terminal authentication program | |
| US20020156881A1 (en) | HTTP transaction monitor with replay capacity | |
| US20040003130A1 (en) | Systems and methods for accessing web services using a tag library | |
| US7330876B1 (en) | Method and system of automating internet interactions | |
| EP1283993A2 (en) | Method and system for building internet-based applications | |
| US20040162873A1 (en) | Method and apparatus of wrapping an existing service | |
| US7685258B2 (en) | Disconnectible applications | |
| WO2001048630A2 (en) | Client-server data communication system and method for data transfer between a server and different clients | |
| CA2360959A1 (en) | Tester for url addressable computer applications | |
| US7409591B2 (en) | Method and system for managing programs for web service system | |
| KR20020028963A (en) | ADE data set component of client computer for transmitting/receiving of data between web servers | |
| Kung et al. | Object Based Data Flow Testing of Web Applications | |
| Javed | A Comparison of WAP Development in C# and Java |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Dead |