The Ultimate Distributed SystemThe Internet

The Ultimate Distributed System The Internet

The Internet represents a very large and dynamic distributed system. Servers are added to and removed from this network continuously. Applications that live in this environment must be able to operate in the presence of partial failures in the form of missing systems or nonexistent addresses on machines. Some of these systems form basic business environments for the company running the Web site. These e-commerce systems have specific and stringent requirements for reliability and security. In this section we will consider the issues specific to this type of environment. It will not be a complete overview, but we will provide an outline of how these systems should be tested.

The "Web pages" that are displayed in the browser include both data, in the form of marked up text using HTML or XML, and behaviors, in the form of scripted functions using languages such as JavaScript. These pages often allow input from the user, perform computations, and format and present output. The browser is an extensible application that can sense when the data that it has been provided requires an additional application in order to handle it properly. These "plug-in" modules add functionality dynamically so that the browser is a changing execution environment.

So what does testing a Web page mean? It means testing that the intended display is presented to the user; that input is accepted and forwarded to a waiting application correctly; and that all actions are performed as intended. The display can fail in terms of the following:

• incorrect fonts being displayed

• mismatch of coordinates so that a figure is not visible

• the wrong language is used or different languages are used for different sections of text

• a mismatch between the platform configuration and the browser display attributes

There are pieces of code embedded into the display file as well as separate script files. Browsers can directly execute code written in languages such as Java. The Java version of Brickles runs as an applet in a browser. The browser and the standard plug-ins are "trusted" code. The testing objective is the content of the display data plus embedded and external script files. Failures include the following:

• incorrect or insufficient permissions to execute code in a specific file

• an inability to create a file when necessary

• the usual failures associated with any function such as computing the wrong answer

• inability to locate resources during execution, such as missing bitmaps

Several pieces of code may be added to the browser by a single page. This may include the Acroread PDF file viewer, a RealPlayer video player, and even the Visigenics CORBA ORB. Once loaded by a page, the code may remain loaded while other pages are loaded and other plug-ins are added. It is impossible to test all possible combinations of programs for interactions. However, it is possible to construct tests that result in different combinations of code being loaded into the browser environment. You should analyze the source listing for each of your pages and construct paths through the pages that lead to different combinations of plug-ins being loaded.

GUI versus API Testing

Earlier we discussed the differences between testing an application from the GUI or from its API. The API level is chosen less often in this situation because functions embedded in a Web page are so visually oriented that it takes less effort to simply use the GUI. The display text can be parsed and validated as syntactically correct. Then sufficient tests are constructed that execute the script code to achieve levels of coverage similar to that of a programming language.

Web Servers

The browser and Web pages sometimes work in conjunction with an application server, as shown in Figure 8.13, to invoke other applications. These servers are generic software applications available from vendors; therefore, after an acceptance test, they will be "trusted" code. The server incorporates a database that stores both the content of the pages and the data produced by users of the system.

Figure 8.13. Web server architecture

These systems automate certain aspects of customer service. A page might accept input into a customer order form, create a client record, invoke applications that automatically generate an account number and password, and then e-mail the account information to the customer.

These systems are designed to be very modular. The application programs can be changed with no modifications to the Web server and only minor changes to the Web pages. The Web pages are changed by simply changing the data, which is often stored in XML format.

Testing these systems involves two facets. First, do the scripts do what they are intended to do? There have been many versions of the browsers and their scripting languages in a very short time. As a result, unless you are deploying browsers into a managed environment in which everyone runs the same version, the tests should be run on the different combinations of the browser version and the script language version. Frames and tables are examples of features that have varied radically from one environment to another and have resulted in very different display results. Many developers include alternative paths depending on whether the browser supports frames or not. There should be test cases to cover these different possibilities.

Second, is the current data correct and in the form expected by the applications and Web pages? Testing this aspect requires scenarios in which the various data displays of the Web site are combined with the types of data that the user would enter. This analysis follows the same process as described in Using Scenarios to Construct Test Cases on page 317 in Chapter 9. The data types for each entry are analyzed, equivalence classes are defined, and values are sampled from each class.

Life-Cycle Testing of Internet Applications

Life-cycle testing, in this context, means testing across a set of user transactions. These should be selected to utilize the complete set of back-end applications. The life-cycle perspective will typically span several different platforms including the user's system, the Web site, and the supplier applications. For example, with an e-commerce system, we would begin with the presentation of material to the user. Is it presented accurately? Many of the pages are constructed using XML trees of information. It is possible for the program to incorrectly associate descriptions and prices. After presentation comes the acceptance of a customer order. This involves the Web page to receive and handle events and data, and it involves the database to manipulate inventory and to record the order. The application must allow the user to modify the order by adding or deleting items. Other applications are used to order the goods from suppliers so that they search for new orders, bundle all the items for each supplier, and interact electronically with the supplier applications. The test suite should identify multiple interlocking life cycles based on the actors for the system. The client actor has a life cycle of creating an order while the supplier actor has a life cycle of creating a different type of order.

There are significant interaction testing activities in two dimensions in this example. First, complete systems written by different teams must interact. The Web site software itself also integrates several different technologies. The example system probably includes HTML, JavaScript, XML, and Java technologies. There are issues about the compatibility of data types as well as the timing of events and limiting their effects.

One of the most important tests for a Web application is to construct test cases that stress the Web site. There are tools that make it easy to clone Web pages and invoke multiple operations on the server. The stress test should be designed to accurately reproduce the expected profile of use. There should also be tests of the server's capability to limit the number of connections in a controlled manner (display a message) rather than in a catastrophic manner (server crashes).

Perhaps the most important function of a Web page is to recognize that a request it has made has not been fulfilled. Browsers set timers to monitor every connection that must be made to another resource such as other pages and servers. Since the browser is "trusted" code, we are not testing whether the failure to obtain a resource will be recognized. We are testing whether the scripts in the page handle that failure appropriately.

What Haven't We Said?

The important areas of performance and security have not been covered. There is a growing number of tools devoted to those topics because of their implications for e-commerce. As the second major wave of e-commerce sites are deployed these areas will be a particular focus. Research is being conducted and some sophisticated models are being developed that described performance characteristics. Maybe we can cover this in the next edition.