Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems

Testing Applications on the Web\ Test Planning for Mobile and Internet-Based Systems \ \ By Hung Q. Nguyen Bob Johnson Michael Hackett \ John Wiley & Sons\ ISBN: 0-471-20100-6 \ \ \ Chapter One\ Web Testing versus Traditional Testing\ Why Read This Chapter?\ Web technologies require new testing and bug analysis methods. It is assumed that you have experience in testing applications in traditional environments; what you may lack, however, is the means to apply your experience to Web environments. To effectively make such a transition, you need to understand the technology and architecture differences between traditional testing and Web testing.\ Introduction\ This chapter presents the application model and shows how it applies to mainframes, PCs, and, ultimately, Web/client-server systems. It explores the technology differences between mainframes and Web/client-server systems, as well as the technology differences between PCs and Web/client-server systems. Testing methods that are suited to Web environments are also discussed.\ Although many traditional software testing practices can be applied to the testing of Web-based applications, there are numerous technical issues that are specific to Web applications that need to be considered.\ The Application Model\ A computer system, which consists of hardware and software, can receive inputs from the user, then stores them somewhere, whether in volatile memory such as RAM(Random Access Memory), or in nonvolatile memory, such as hard disk memory. It can execute the instructions given by software by performing computation using the CPU (Central Processing Unit) computing power. Finally, it can process the outputs back to the user. Figure 2.1 illustrates how humans interact with computers. Through a user interface (UI), users interact with an application by offering input and receiving output in many different forms: query strings, database records, text forms, and so on. Applications take input, along with requested logic rules, and store them in memory, and then manipulate data through computing; they also perform file reading and writing (more input/output and data storing). Finally, output results are passed back to the user through the UI. Results may also be sent to other output devices, such as printers.\ In traditional mainframe systems, as illustrated in Figure 2.2, all of an application's processes, except for UI controls, occur on the mainframe computer. User interface controls take place on dumb terminals that simply echo text from the mainframe. Little computation or processing occurs on the terminals themselves. The network connects the dumb terminals to the mainframe. Dumb-terminal UIs are text-based or form-based (nongraphical). Users send data and commands to the system via keyboard inputs.\ Desktop PC systems, as illustrated in Figure 2.3, consolidate all processes-from UI through rules to file systems-on a single physical box. No network is required for a desktop PC. Desktop PC applications can support either a text-based UI (command-line) or a Graphical User Interface (GUI). In addition to keyboard input events, GUI-based applications also support mouse input events such as click, double-click, mouse-over, drag-and-drop, and so on.\ Client-server systems, upon which Web systems are built, require a network and at least two machines to operate: a client computer and a server computer, which serves requested data to the client computer. With the vast majority of Web applications, a Web browser serves as the UI container on the client computer.\ The server receives input requests from the client and manipulates the data by applying the application's business logic rules. Business logic rules are the computations that an application is designed to carry out based on user input-for example, sales tax might be charged to any e-commerce customer who enters a California mailing address. Another example might be that customers over age 35 who respond to a certain online survey will be mailed a brochure automatically. This type of activity may require reading or writing to a database. Data is sent back to the client as output from the server. The results are then formatted and displayed in the client browser.\ The client-server model, and consequently the Web application model, is not as neatly segmented as that of the mainframe and the desktop PC. In the client-server model, not only can either the client or the server handle some of the processing work, but server-side processes can be divided between multiple physical boxes or computers (application server, Web server, database server, etc.). Figure 2.4, one of many possible client-server models, depicts I/O and logic rules handled by an application server (the server in the center), while a database server (the server on the right) handles data storage. The dotted lines in the illustration indicate processes that may take place on either the client-side or the server-side. See Chapter 5, "Web Application Components," for information regarding server types.\ A Web system may comprise any number of physical server boxes, each handling one or more service types. Later in this chapter, Table 2.1 illustrates some of the possible three-box server configurations. Note that the example is relatively a basic system. A Web system may contain multiple Web servers, application servers, and multiple database servers (such as a server farm, a grouping of similar server types that share workload). Web systems may also include other server types, such as e-mail servers, chat servers, e-commerce servers, and user profile servers (see Chapter 5 for more information). Understanding how your Web application-under-test is structured is invaluable for bug analysis-trying to reproduce a bug or learning how you can find more bugs similar to the one that you are seeing.\ Keep in mind that it is software, not hardware, that defines clients and servers. Simply put, clients are software programs that request services from other software programs on behalf of users. Servers are software programs that offer services. Additionally, client-server is also an overloaded term; it is only useful from the perspective of describing a system. A server may, and often does, become a client in the chain of requests. In addition, the server-side may include many applications and systems including mainframe systems.\ Hardware and Software Differences\ Mainframe systems (Figure 2.5) are traditionally controlled environments, meaning that hardware and software are primarily supported (it does not necessarily mean that all the subcomponents are produced by the same company), end to end, by the same manufacturer. A mainframe with a single operating system, and applications sold and supported by the same manufacturer, can serve multiple terminals from a central location. Compatibility issues are more manageable compared to the PC and client-server systems.\ A single desktop PC system consists of mixed hardware and software-multiple hardware components built and supported by different manufacturers, multiple operating systems, and nearly limitless combinations of software applications. Configuration and compatibility issues become difficult or almost impossible to manage in this environment.\ A Web system consists of many clients, as well as server hosts (computers). The system's various flavors of hardware components and software applications begin to multiply. The server-side of Web systems may also support a mixture of software and hardware and, therefore, are more complex than mainframe systems, from the configuration and compatibility perspectives. See Figure 2.6 for an illustration of a client-server system running on a local area network (LAN).\ The GUI of the PC makes multiple controls available on screen at any given time (e.g., menus, pull-down lists, help screens, pictures, and command buttons.). Consequently, event-driven browsers (in event-driven model, inputs are driven by events such as a mouse click or a keypress on the keyboard) are also produced, taking advantage of the event-handling feature offered by the operating system (OS). However, event-based GUI applications (data input coupled with events) are more difficult to test. For example, each event applied to a control in a GUI may affect the behavior of other controls. Also, special dependencies can exist between GUI screens; interdependencies and constraints must be identified and tested accordingly.\ The Differences between Web and Traditional Client-Server Systems\ The last two sections point out the application architecture and hardware and software differences among the mainframe, PC, and Web/client-server systems. We will begin this section by exploring additional differences between Web and traditional systems so that appropriate testing considerations can be formulated.\ Client-Side Applications\ As illustrated in Figure 2.7, most client-server systems are data-access-driven applications. A client typically enables users, through the UI, to send input data, receive output data, and interact with the back end (for example, sending a query command). Clients of traditional client-server systems are platform-specific. That is, for each supported client operating system (e.g., Windows 16- and 32-bit, Solaris, Linux, Macintosh, etc.), a client application will be developed and tested for that target operating system.\ Most Web-based systems are also data-access-driven applications. The browser-based clients are designed to handle similar activities to those supported by a traditional client. The main difference is that the Web-based client is operating within the Web browser's environment. Web browsers consist of operating system-specific client software running on a client computer. It renders HyperText Markup Language (HTML), as well as active contents, to display Web page information. Several popular browsers also support active content such as client-side scripting, Java applet, ActiveX control, eXtensible Markup Language (XML), cascading style sheet (CSS), dynamic HTML (DHTML), security features, and other goodies. To do this, browser vendors must create rendering engines and interpreters to translate and format HTML contents. In making these software components, various browsers and their releases introduce incompatibility issues. See Chapter 10, "User Interface Tests," and Chapter 17, "Configuration and Compatibility Tests," for more information.\ From the Web application producer's perspective, there is no need to develop operating-system-specific clients since the browser vendors have already done that (e.g., Netscape, Microsoft, AOL, etc.). In theory, if your HTML contents are designed to conform to HTML 4 standard, your client application should run properly in any browser that supports HTML 4 standard from any vendor. But in practice, we will find ourselves working laboriously to address vendor-specific incompatibility issues introduced by each browser and its various releases. At the writing of this book, the golden rule is: "Web browsers are not created equal."\ In addition to the desktop client computer and browser, there are new types of clients and browsers, which are a lot smaller than the desktop PC version. These clients are often battery-powered, rather than wall-electric-powered as is a desktop PC. These clients are mobile devices including PDAs (Personal Digital Assistants), smart phones, and handheld PCs. Since these devices represent another class of client computers, there are some differences in the mobile application model. For simplicity, in this chapter, we will only refer to the desktop PC in the client discussion. Read Chapter 6, "Mobile Web Application Platform," for discussions on the mobile client application model.\ Event Handling\ In the GUI and event-driven model, inputs, as the name implies, are driven by events. Events are actions taken by users, such as mouse movements and clicks, or the input of data through a keyboard. Some objects (e.g., a push button) may receive mouse-over events whenever a mouse passes over them. Amouse single-click is an event. A mouse double-click is a different kind of event. A mouse click with a modifier key, such as Ctrl, is yet another type of event. Depending on the type of event applied to a particular UI object, certain procedures or functions in an application will be executed. In an event-driven environment, this is a type of procedure referred to as event-handling code.\ Testing event-driven applications is more complicated because it's very labor-intensive to cover the testing of many combinations and sequences of events. Simply identifying all possible combinations of events can be a challenge because some actions trigger multiple events.\ Browser-based applications introduce a different flavor of event-handling support. Because Web browsers were originally designed as a data presentation tool, there was no need for interactions other than single-clicking for navigation and data submission, and mouse-over ALT attribute for an alternate description of graphic. Therefore, standard HTML controls such as form-based control and hyperlinks are limited to single-click events. Although script-based events can be implemented to recognize other events such as double-clicking and drag-and-drop, it's not natural in the Web-based user interface to do so (not to mention that those other events also cause incompatibility problems among different browsers.\ In Web-based applications, users may click links that generate simulated dialog boxes (the server sends back a page that includes tables, text fields, and other UI objects). Users may interact with browser-based UI objects in the process of generating input for the application. In turn, events are generated. Some of the event-handling code is in scripts that are embedded in the HTML page and executed on the client-side. Others are in UI components (such as Java applets and ActiveX controls) embedded in the HTML page and executed on the client-side. Still others are executed on the server-side. Understanding where (client- or server-side) each event is handled enables you to develop useful test cases as well as reproduce errors effectively.\ Browser-based applications offer very limited keyboard event support. You can navigate within the page using Tab and Shift-Tab keys. You can activate a hyperlink to jump to another link or push a command button by pressing the Enter key while the hyperlink text, graphic, or a button is highlighted. Supports for keyboard shortcuts and access keys, such as Alt-[key] or Ctrl-[key], are not available for the Web applications running in the browser's environment, although they are available for the browser application itself. Another event-handling implication in browser-based applications is in the one-way request and submission model.\ \ Continues...\ \ \ \ Excerpted from Testing Applications on the Web by Hung Q. Nguyen Bob Johnson Michael Hackett Excerpted by permission.\ All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.\ Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site. \ \

PrefaceForewordAcknowledgmentsAbout the AuthorsPt. 1Introduction1Ch. 1Welcome to Web Testing3Ch. 2Web Testing versus Traditional Testing15Pt. 2Methodology and Technology39Ch. 3Software Testing Basics41Ch. 4Networking Basics81Ch. 5Web Application Components111Ch. 6Mobile Web Application Platform149Ch. 7Test Planning Fundamentals177Ch. 8Sample Application193Ch. 9Sample Test Plan203Pt. 3Testing Practice213Ch. 10User Interface Tests215Ch. 11Functional Tests253Ch. 12Server-Side Testing269Ch. 13Using Scripts to Test297Ch. 14Database Tests317Ch. 15Help Tests353Ch. 16Installation Tests367Ch. 17Configuration and Compatibility Tests395Ch. 18Web Security Testing415Ch. 19Performance Testing479Ch. 20Testing Mobile Web Applications527Ch. 21Web Testing Tools553Ch. 22Finding Additional Information567App. ALogiGear Test Plan Template579App. BWeekly Status Report Template595App. CError Analysis Checklist: Web Error Examples601App. DUI Test-Case Design Guideline: Common Keyboard Navigation and Shortcut Matrix613App. EUI Test-Case Design Guideline: Mouse Action Matrix615App. FWeb Test- Case Design Guideline: Input Boundary and Validation Matrix 1617App. GDisplay Compatibility Test Matrix621App. HBrowser OS Configuration Matrix623Index625