client-server application testing

8/14/2019 Client-Server Application Testing

http://slidepdf.com/reader/full/client-server-application-testing 1/21

Client/Server Software TestingHongmei Yang

Contents

Acknowledgement

Introduction

I: Introduction to Client/Server Architecture

1. What is Client/Server Computing?

2. Architectures for Client/Server System.2.1. Client/Server 2-tiered architecture

2.2. Modified 2-tiered architecture

2.3. 3-tiered architecture3. Critical Issues Involved in Client/Server System Management

II Client/Server Software Testing

1. Introduction to Client/Server Software Testing2. Testing Plan for Client/Server Computing

3. Client/Server Testing in Different Layers

3.1. Testing on the Client Side—Graphic User Interface Testing3.1.1. Complexity for Graphic User Interface Testing

3.1.2. GUI testing techniques

3.2. Testing on the Server Side---Application Testing

3.2.1. Client/Server loading testing3.2.2. Volume testing

3.2.3. Stress testing

3.2.4. Performance testing3.2.5. Other server side testing related to data storage

3.2.6. Examples for automated server testing tools

3.3. Networked Application Testing4. Special Concerns for Internet Computing —Security Testing

Summary

References

Appendix I Client/Server test plan based on application functionality

Appendix II CASE STUDY

The business scenarios for the MFS imaging system

Appendix III CASE STUDY

Acceptance testing specification for the MFS imaging system



Acknowledgment

I want to thank Dr. Corliss for his guidance and support on this essay and my study at Marquette

University.

2



Client/Server Software Testing

Introduction

The first part of this essay is the introduction to Client/Server architecture, which includes three

sections: What is the Client/Server Computing, Architectures for Client/Server System, andCritical Issues Involved in Client/Server System Management.

Client/Server computing is a current reality for professional system developers and for

sophisticated departmental computing users. The section, What is the Client/Server Computing, points out the definition and major characteristics of Client/Server computing. Netcentric (or

Internet) computing, as an evolution of Client/Server model, has brought new technology to the

forefront. Hence, the major characteristics and differences between Netcentic and traditionalClient/Server computing are also presented in this section.

Both traditional and Netcentric computing are tiered architectures. The brief introduction for three popular architectures, namely, 2-tiered architecture, modified 2-tiered architecture, and 3-tiered

architecture are found in the section -- The Architecture for Client/Server Computing.

The second part of this essay is about Client/Server software testing. There are four sections in this part: Introduction to Client/Server Software Testing, Testing Plan for Client/Server Computing,

Client/Server Testing in Different Layers, and Special Concerns for Internet Computing—Security

Testing.

In the section Introduction to the Client/Server Software Testing, we present some basic

characteristics of Client/Server software testing from different points of view.

Because of the difference between traditional and Client/Server software testing, a practical testing

plan based on application functionality is attached in section 2 Testing Plan for Client/Server Software Testing. We also give some detailed explanation for different test plans, such as, system

test plan, operational plan, acceptance test plan, and regression test plan, which are parts of a

Client/Server testing plan.

As mentioned in Part I, a Client/Server system has several layers, which can be viewed

conceptually and physically. Viewed physically, the layers are client, server, middleware, and

network. In section 3 Client/Server Testing in Different Layers, specific concerns related to client,

server and network problems, testing techniques, testing tools and some activities are addressedseparately in Testing on the Client Side, Testing on the Server Side, and Network Testing.

For Internet-based Client/Server systems, security is one of the major concerns. Hence, this essay

also includes some security risks that need to be tested in the Part II, section 4 Special Concerns

for Internet Computing—Security Testing.

3



Client/Server Software Testing

I: Introduction to Client/Server architecture:

Client/Server system development is the preferred method of constructing cost-effectivedepartment- and enterprise-level strategic corporate information systems. It allows the rapid

deployment of information systems in end-user environments.

1: What is Client/Server Computing?

Client/Server computing is a style of computing involving multiple processors, one of which istypically a workstation and across which a single business transaction is completed [1].

Client/Server computing recognizes that business users, and not a mainframe, are the center of a

business. Therefore, Client/Server is also called “client-centric” computing.

Today, Client/Server computing is extended to the Internet—netcentric computing (network

centric computing), the concepts of business users have expanded greatly. Forrester Report

describes the netcentric computing as “Remote servers and clients cooperating over the Internet todo work” and says that Internet Computing extends and improves the Client/Server model [2].

The characteristics of Client/Server computing includes:1. There are multiple processors.

2. A complete business transaction is processed across multiple servers

Netcentric computing ---- as an evolution of Client/Server model, has brought new technology to

the forefront, especially in the area of external presence and access, ease of distribution, and media

capabilities. Some of new technologies are [3]:

a. Browser, which provides a “universal client”. In the traditional Client/Server environment,

distributing an application internally or externally for an enterprise requires that the application

be recompiled and tested for all specific workstation platforms (operating systems). It also

usually requires loading the application on each client machine. The browser-centricapplication style offers an alternative to this traditional problem. The web browser provides a

universal client that offers users a consistent and familiar user interface. Using a browser, auser can launch many types of applications and view many types of documents. This can be

accomplished on different operating systems and is independent of where the applications or

documents reside.

4



b. Direct supplier-to-customer relationships. The external presence and access enabled by

connecting a business node to the Internet has opened up a series of opportunities to reach anaudience outside a company’s traditional internal users.

c. Richer documents. Netcentric technologies (such as HTML, documents, plug-ins, and Java)

and standardization of media information formats enable support for complex documents,

applications and even nondiscrete data types such as audio and video.d. Application version checking and dynamic update. The configuration management of

traditional Client/Server applications, which tend to be stored on both the client and server

sides, is a major issue for many corporations. Netcentric computing can checking and updateapplication versions dynamically.

2: Architectures for Client/Server System.

Both traditional Client/Server as well as netcentric computing are tiered architectures. In both

cases, there is a distribution of presentation services, application code, and data across clients and

servers. In both cases, there is a networking protocol that is used for communication betweenclients and servers. In both cases, they support a style of computing where processes on different

machines communicate using messages. In this style, the “client” delegates business functions or other tasks (such as data manipulation logic) to one or more server processes. Server processesrespond to messages from clients.

A Client/Server system has several layers, which can be visualized in either a conceptual or a physical manner. Viewed conceptually, the layers are presentation, process, and database. Viewed

physically, the layers are server, client, middleware, and network.

2.1. Client/Server 2-tiered architecture:

2-tiered architecture is also known as the client-centric model, which implements a “fat” client.

Nearly all of the processing happens on the client, and client accesses the database directly rather than through any middleware. In this model, all of the presentation logic and the business logic are

implemented as processes on the client.

2-tiered architecture is the simplest one to implement. Hence, it is the simplest one to test. Also, it

is the most stable form of Client/Server implementation, making most of the errors that testers find

independent of the implementation. Direct access to the database makes it simpler to verify the testresults.

The disadvantage of this model is the limit of the scalability and difficulties for maintenance.

Because it doesn’t partition the application logic very well, changes require reinstallation of the

software on all of the client desktops.

2.2. Modified 2-tiered architecture:

Because of the nightmare of maintenance of the 2-tiered Client/Server architecture, the business

logic is moved to the database side, implemented using triggers and procedures. This kind of model is known as modified 2-tiered architecture.

5



In terms of software testing, modified 2-tiered architecture is more complex than 2-tiered

architecture for the following reasons:a. It is difficult to create a direct test of the business logic. Special tools are required to implement

and verify the tests.

b. It is possible to test the business logic from the GUI, but there is no way to determine the

numbers of procedures and/or triggers that fires and create intermediate results before the end product is achieved.

c. Another complication is dynamic database queries. They are constructed by the application and

exist only when the program needs them. It is very difficult to be sure that the test generates aquery “correctly”, or as expected. Special utilities that show what is running in memory must

be used during the tests.

2.3. 3-tiered architecture:

For 3-tiered architecture, the application is divided into a presentation tier, a middle tier, and a data

tier. The middle tier is composed of one or more application servers distributed across one or more physical machines. This architecture is also termed the “the thin client—fat server” approach.

This model is very complicated for testing because the business and/or data objects can be invokedfrom many clients, and the objects can be partitioned across many servers. The characteristicsmake the 3-tiered architecture desirable as a development and implementation framework at the

same time make testing more complicated and tricky.

3: Critical Issues Involved in Client/Server System Management:

Hurwitz Consulting Group, Inc. has provided a framework for managing Client/Server systemsthat identifies eight primary management issues [4]:

a. Performance

b. Problemc. Software distribution

d. Configuration and administration

e. Data and storagef. Operations

g. Security

h. License

II Client/Server Software Testing:

Software testing for Client/Server systems (Desktop or Webtop) presents a new set of testing

problems, but it also includes the more traditional problems testers have always faced in themainframe world. Atre describes the special requirements of Client/Server testing [5]:

a. The client’s user interface b. The client’s interface with the server

c. The server’s functionality

d. The network (the reliability and performance of the network)

1. Introduction to the Client/Server Software Testing:

6



We can view the Client/Server software testing from different perspectives:

a. From a “distributed processing” perspective: Since Client/Server is a form of distributed

processing, it is necessary to consider its testing implication from that point of view. The term

“distributed” implies that data and processes are dispersed across various and miscellaneous platforms. Binder states several issues needed to be considered in the Client/Server

environments [6].

• Client GUI considerations

• Target environment and platform diversity considerations

• Distributed database considerations (including replicated data)

• Distributed processing considerations (including replicated processes)

• Nonrobust target environment

• Nonlinear performance relationships

b. From a cross-platform perspective: The networked cross-platform nature of Client/Server systems requires that we pay much more attention to configuration testing and compatibility

testing. The purpose of configuration testing is to uncover the weakness of the system operatedin the different known hardware and software environments. The purpose of comparabilitytesting is to find any functionally inconsistency of the interface across hardware and software.

c. From a cross-window perspective: The current proliferation of Microsoft Windows

environments has created a number of problems for Client/Server developers. For

example, Windows 3.1 is a 16-bit environment, and Window 95 and Window NT are 32-bitenvironment. Mixing and matching 16- bit and 32-bit code/16bits or 32bits systems and

products causes major problems. Now there exit some automated tools that can generate

both 16-bit and 32-bit test scripts.

2. Testing Plan for Client/Server Computing:

In many instances, testing Client/Server software cannot be planned from the perspective of

traditional integrated testing activities because this view either is not applicable at all or is too

narrow, and other dimensions must be considered. The following are some specific considerationsneeding to be addressed in a Client/Server testing plan.

• Must include consideration of the different hardware and software platforms on which the

system will be used.

• Must take into account network and database server performance issues with which mainframesystems did not have to deal.

• Has to consider the replication of data and processes across networked servers

See attached “Client/Server test plan based on application functionality” [7].

In the test plan, we may address or construct several different kinds of testing:a. The system test plan: System test scenarios are a set of test scripts, which reflect user behaviors

in a typical business situation. It’s very important to identify the business scenarios before

constructing the system test plan.

See attached CASE STUDY: The business scenarios for the MFS imaging system

7



b. The user acceptance test plan: The user acceptance test plan is very similar to the system test plan. The major difference is direction. The user acceptance test is designed to demonstrate the

major system features to the user as opposed to finding new errors.

See attached CASE STUDY: Acceptance test specification for the MFS imaging system

c. The operational test plan: It guides the single user testing of the graphical user interface and of

the system function. This plan should be constructed according to subsection A and B of

Section II in the testing plan template -- Client/Server test plan based on application

functionality. (See attached Appendix I)

d. The regression test plan: The regression test plan occurs at two levels. In Client/Server

development, regression testing happens between builds. Between system releases, regression

testing also occurs postproduction. Each new build/release must be tested for three aspects:

• To uncover errors introduced by the fix into previously correct function.

• To uncover previously reported errors that remain.

• To uncover errors in the new functionality.

e. Multiuser performance test plan: It is necessary to be performed in order to uncover any

unexpected system performance problem under load. This test plan should be constructed formSection V of the testing plan template-- Client/Server test plan based on application

functionality. (See attached Appendix I)

3. Client/Server Testing in Different Layers:

3.1. Testing on the Client Side—Graphic User Interface Testing:

3.1.1 The complexity for Graphic User Interface Testing is due to:

a. Cross-platform nature: The same GUI objects may be required to run transparently(provide a consistent interface across platforms, with the cross-platform nature

unknown to the user) on different hardware and software platforms

b. Event-driven nature: GUI-base applications have increased testing requirements

because they are in an event-driven environment where user actions are events thatdetermine the application’s behavior. Because the number of available user actions is

very high, the number of logical paths in the supporting program code is also very high.

c. The mouse, as an alternate method of input, also raises some problems. It is necessaryto assure that the application handles both mouse input and keyboard input correctly.

d. The GUI testing also requires testing for the existence of a file that provides supporting

data/information for text objects. The application must be sensitive to the existence, or nonexistence.

e. In many cases, GUI testing also involves the testing of the function that allows end-

users to customize GUI objects. Many GUI development tools give the users the abilityto define their own GUI objects. The ability to do this requires the underlying

application to be able to recognize and process events related to these custom objects.

8



3.1.2 GUI testing techniques: Many traditional software testing techniques can be used in GUI

testing.

a. Review techniques such as walkthroughs and inspections [8]. These human testing

procedures have been found to be very effective in the prevention and early correction

of errors. It has been documented that two-thirds of all of the errors in finishedinformation systems are the results of logic flaws rather than poor coding [9].

Preventive testing approaches, such as walkthroughs and inspections can eliminate the

majority of these analysis and design errors before they go through to the productionsystem.

b. Data validation techniques: Some of the most serious errors in software systems have been the result of inadequate or missing input validation procedures. Software testing

has powerful data validation procedures in the form of the Black Box techniques of

Equivalence Partitioning, Boundary Analysis, and Error Guessing. These techniques

are also very useful in GUI testing.

c. Scenario testing: It is a system-level Black Box approach that also assure good WhiteBox logic-level coverage for Client/Server systems.

d. The decision logic table (DLT): DLT represents an external view of the functional

specification that can be used to supplement scenario testing from a logic-coverage perspective. In DLTs, each logical condition in the specification becomes a control path

in the finished system. Each rule in the table describes a specific instance of a pathway

that must be implemented. Hence, test cases based on the rules in a DLT provideadequate coverage of the module’s logic independent of its coded implementation.

In addition to these traditional testing techniques, a number of companies have begun

producing structured capture/playback testing tools that address the unique properties of GUIs. The difference between traditional capture/playback and structured capture/playback

paradigm is that capture/playback occurs at an external level. It records input as keystrokes

or mouse actions and output as screen images that are saved and compared against inputsand output images of subsequent tasks.

Structured capture/playback is based on an internal view of external activities. Theapplication program’s interactions with the GUI are recorded as internal ‘events” that can

be saved as “scripts” written in some certain language.

3.2 Testing on the Server Side---Application Testing:

There are several situations that scripts can be designed to invoke during several tests: load

testing, volume tests, stress tests, performance tests, and data-recovery tests.

3.2.1 Client/Server loading tests:

Client/Server systems must undergo two types of testing: single-user-functional-based

testing and multiuser loading testing.

9



Multiuser loading testing is the best method to gauge Client/Server performance. It is

necessary in order to determine the suitability of application server, database server, andweb server performance. Because multiuser load test requires emulating a situation in

which multiple clients access a single server application, it is almost impossible to be done

without automation.

For the Client/Server load testing, some common objectives include:

• Measuring the length of time to complete an entire task

• Discovering which hardware/software configuration provides optimal performance

• Tuning database queries for optimal response

• Capturing Mean-Time-To-Failure as a measure of reliability

• Measuring system capacity to handle loads without performance degradation

• Identifying performance bottlenecks

Based on the test objectives, a set of performance measurements should be described.Typical measurements include:

• End-to-end response time• Network response time

• GUI response time

• Server response time

• Middleware response time

3.2.2 Volume testing:

The purpose of volume testing is to find weaknesses in the system with respect to itshandling of large amount of data during extended time periods

3.2.3 Stress testing:

The purpose of stress testing is to find defects of the system capacity of handling largenumbers of transactions during peak periods. For example, a script might require users to

login and proceed with their daily activities while, at the same time, requiring that a series

of workstations emulating a large number of other systems are running recorded scripts thatadd, update, or delete from the database.

3.2.4 Performance testing:System performance is generally assessed in terms of response time and throughput rates

under differing processing and configuration conditions. To attack the performance

problems, there are several questions should be asked first:

• How much application logic should be remotely executed?

• How much updating should be done to the database server over the network fromthe client workstation?

• How much data should be sent to each in each transaction?

According to Hamilton [10], the performance problems are most often the result of the

client or server being configured inappropriately.

10



The best strategy for improving client-sever performance is a three-step process [11]. First,

execute controlled performance tests that collect the data about volume, stress, and loadingtests. Second, analyze the collected data. Third, examine and tune the database queries and,

if necessary, provide temporary data storage on the client while the application is

executing.

3.2.5 Other server side testing related to data storage:

• Data recovery testing

• Data backup and restoring testing

• Data security testing

• Replicated data integrity testing.

3.2.6 Examples for automated server testing tools:

LoadRunning/XL, offered from Mercury Interactive, is a Unix-based automated server

testing tool that tests the server side of multiuser Client/Server application.LoadRunning/PC is similar to products based on Windows environments.

SQL Inspector and ODBC Inspector are tools for testing the link between the client and theserver. These products monitor the database interface pipeline and collect information

about all database calls or a selected subset of them.

SQL Profiler, is used for tuning database calls. It stores and displays statistics about SQLcommands embedded in Client/Server applications.

SQLEYE is an NT-based tool, offered by Microsoft. It can track the information passedthrough the SQL Server and its client. Client application connect indirectly to SQL server

through SQLEYE, which allows users to view the queries sent to SQL Server, the returned

results, row counts, message, and errors

3.3 Networked Application Testing

Testing the network is beyond the scope of an individual Client/Server project as it may servemore than a single Client/Server project. Thus, network testing falls into the domain of the

network management group. As Robert Buchanan [12] said: “If you haven’t tested a network

solution, it’s hard to say if it works. It may ‘work’. It may execute all commands, but it may be too slow for your needs”.

Nemzom blames the majority of network performance problem on insufficient network capacity [13]. He views bandwidth and latency as the critical determinants of network speed

and capacity. He also sees interactions among intermediate network nodes (switches,

bridges, routers and gateways) as adding to the problem.

Elements of network testing include:

• Application response time measures

• Application functionality

• Throughput and performance measurement

11



• Configuration and sizing

• Stress testing and performance testing

• Reliability

It is necessary to measure application response time while the application is completing a

series of tasks. This kind of measure reflects the user’s perception of the network, and isapplicable through the entire network life cycle phase. Testing application functionality

involves testing shared functionality across workstations, shared data, and shared processes. This type of testing is applicable during the development and evolution.

Configuration and sizing measure the response of specific system configurations. This is

done for different network configurations until the desired performance level is reached. .

The point of stress testing is to overload network resource such as routers or hubs.Performance testing can be used to determine how many network devices will be required

to meet the network’s performance requirements. Reliability testing involves running the

network for 24-72 hrs under a medium-to-heavy load. From a reliability point of view, it isimportant that the network remain functional in the event of a node failure.

4 Special Concerns for Internet Computing --- Security Testing:

For internet-based Client/Server systems, security testing for the web server is important. The

web server is your LAN’s window to the world and, conversely, is the world’s window toyour LAN.

The following excerpt is taken from the WWW Security FAQ [14]:

It’s a maxim in system security circles that buggy software opens up security holes. It’s a maxim in software

development circles that large, complex programs contain bugs. Unfortunately, web servers are large, complex

programs that can contain security holes. Furthermore, the open architecture of web server allows arbitrary CGI

scripts to be executed on the server’s side of the connection in response to remote requests. Any CGI scriptinstalled at your site may contain bugs, and every such bug is a potential security hole.

Three types of security risks have been identified [15]:

1. The primary risk is errors in the web server side misconfiguration that would allowremote users to:

• Steal confidential information

• Execute commands on the server host, thus allowing the users to modify the system

• Gain information about the server host that would allow them to break into the

system

• Launch attacks that will bring the system down.2. The secondary risk occurs on the Browser-side

• Active content that crashes the browser, damages your system, breaches your

company’s privacy, or creates an annoyance.

• The misuse of personal information provided by the end user.

3. The tertiary risk is data interception during data transfer.

12



The above risks are also the focuses of web server security testing. As a tester, it is your

responsibility to test if the security extends provided by the server meet the user’s expectationfor the network security.

Summary:

Client/Server system development is the preferred method of constructing cost-effectivedepartment- and enterprise-level strategic corporate information systems. It allows the rapid

deployment of information systems in end-user environments

Both traditional Client/Server as well as netcentric computing are tiered architectures.

Currently, the dominant three types of Client/Server architectures include 2-tiered

architecture, modified 2-tiered architecture, and three tiered architecture. 2-tiered architectureis the simplest one to implement, and the simplest one to test. The characteristics of the 3-

tiered architecture that make desirable as development and implementation framework at the

same time make testing more complicated

Testing Client/Server software cannot be planned from the perspective of traditional

integrated testing activities. In a Client/Server testing plan, some specific considerations, such

as different hardware and software platforms, network and database server performanceissues, the replication of data and processes across networked servers, etc. need to be

addressed.

The complexity for GUI (Graphic User Interface) testing is increase because of some

characteristics of GUIs, for instance, its cross-platform nature, event-driven nature, and an

additional input method—mouse. Many traditional software testing techniques can be used in

GUI testing. Currently, a number of companies have begun producing structuredcapture/playback tools that address the unique properties of GUIs.

There are several situations that scripts can be designed to be invoked during server tests: loadtesting, volume tests, stress tests, performance tests, and data-recovery tests. These types of

testing are nearly impossible without automation. Some sophisticated testing tools used in

server side testing already emerged in the market, such as LoadRunning/Xl, SQL Inspector,SQL profiler, and SQLEYE.

Network test is a necessary but difficult series of tasks. Its difficulty is compounded by thefact that Client/Server development may be targeted for an exiting network or for one that is

yet to be installed. Proactive network management and proper capacity planning will be veryhelpful. In addition, performance and stress testing can ease the network testing burden.

For internet-based Client/Server systems, security testing for the web server is important. The

web server is your LAN’s window to the world and, conversely, is the world’s window to

your LAN. As a tester, it is your responsibility to find weakness in the system security

13



References:

1. Goodyear, Mark. Enterprise System Architectures. CRC Press LLC, 2000, p.1-1.

2. Mosley, Daniel J.. Client/Server Software Testing on the Desktop and the Web, Prentice HallPTR, Upper Saddle River, NJ, 2000, pXV.

3. Goodyear, Mark. Enterprise System Architectures. CRC Press LLC, 2000, pp.1-4.4. Bourne, Kelly. SQL Process. DAMS, Vol. 8, No.12, November 1995, p.34 (3).

5. Shaku, Atre. Client/Server Application Development Testing: A Special Report by Atre

Associates, Inc., 222 Grace Church Street, Port Chester, NY 10573-5155.

6. Binder, Robert A. Test Case Design for Object-Oriented Programming: The FREE Approach.Robert Binder Systems Consulting, Inc., Chicago, 1992.

7. Mosley, Daniel J. Client/Server Software Testing on the Desktop and the Web, Prentice Hall

PTR, Upper Saddle River, NJ, 2000, pp.72-4.8. Mosley, Daniel J. The Handbook of MIS Application Software Testing: Methods, Techniques,

and Tools for Assuring Quality Through Testing. Prentice-Hall Yourdon Press, EnglewoodCliffs, NJ, 1993.

9. Myers, Glenford. Software Reliability, John Wiley &Sons, New York, 1977.

10. Hamilton, Dennies. Don’t Let Client/Server Performance Gotchas Getcha. Datamation, Vol.

40; No. 21; November 1, 1994, p.39.11. Mosley, Daniel J. Client/Server Software Testing on the Desktop and the Web, Prentice Hall

PTR, Upper Saddle River, NJ, 2000, p.143.

12. Buchanan,Robert. Weird Science (Proactive Testing for Network Systems). LAN Magazine,

Vol.9, No. 7, July 1994, pp.115-9.13. Nemzow, Marty. Keeping a Lid on Network Capacity. LAN Magazine, Vol. 9, No. 13,

December 1994, pp. 61-4.

14. Massachusetts Institute of Technology, Institute National de Researche en Informatique et enAutomatique, Keio University). All rights reserved. http://www.w3.org/consortium/legal/.

15. Mosley, Daniel J. Client/Server Software Testing on the Desktop and the Web, Prentice Hall

PTR, Upper Saddle River, NJ, 2000, p.276.

14

http://www.w3.org/consortium/legal/

http://www.w3.org/consortium/legal/



Appendix I

Client/Server test plan based on application functionality

* Source: Mosley, Daniel J. Client/Server Software Testing on the Desktop and the Web, Prentice Hall PTR, Upper

Saddle River, NJ, 2000, p72-4.

Document ID

Document locator

I. Introduction

ScopeGeneral Testing Objectives

Level of Tests

Types of TestsAreas Not Being Tested

Supporting Documents

Methods

Test Case Design and ConstructionStandards

II Environment RequirementsHardware

Software

Personal

III Work Flow and Deliverable

Testing Responsibilities

Testing MilestonesTesting Deliverables

IV. Test Management and Procedure ControlsTesting Management

Test Team

Testing ScheduleRequired Resources

Testing DeliverablesTest Analysis, Reporting, and Tracking MechanismsDefect Identification

Defect Tracking

Testing Quality Metrics

Testing Process Improvement MetricsTesting Procedure Controls

Test Initiating

15



Test Execution

Test FailureConfiguration Management

Document Control

V. Graphical User Interface Test PlanGUI Description

GUI Testing Objectives

GUI Testing MethodsGUI Objects to Be Tested

GUI Test Case Design

GUI Test Data CreationGUI Verification Tests

GUI Test Tools

VI. Server Test PlanServer Testing Objectives

Server Testing MethodsServer Functions to Be Tested

Stress Testing

Volume Testing

Server Test Data CreationServer Verification Testing

Test Tools

VII. Network Test Plan

Network Testing Objectives

Network Testing Methods

Network Functions to Be TestedPerformance Testing

Stress Testing

Network Test Data Creation Network Verification Testing

Network Testing Tools

VIII. Functional Testing

Functional Testing Objectives

Functional Testing Methods

Function To Be Tested

Black BoxCause-Effect Graphing

Equivalence partitioningBoundary Analysis

Error Guessing

16



Appendix II: CASE STUDY

The business scenarios for the MFS imaging system

• According to the Client/Server test plan template, this document belongs to the Business

Scenarios in the system test plan

To construct the Acceptant Test Specification for the MFS imaging system, we identify the business scenarios first, then develop the acceptance test based on this scenarios.

Usage scenarios:

1.1: Under what circumstances do we look at an invoice/image?

a. Scanning: In mailroom, students open the mail (and sort invoices in alphabetic order byvendors’ name?), then scan the invoices into FDD.

b. Data entry: There are three different situations for data entry1. The processors open the image file, and perform corresponding data entry.

2. Import data entry from library. In this situation,

-----how to attach image file to MFS record?-----how to deal with one-to-many relationship between records and one batch of

invoice?

3. Credit charge: may have information of any number of people or department, but we onlyhave one batch.

c. Imaging Research:

1. Grant invoice. About imaging Batch Reports (from library) and imaging direct invoicevoucher approval

2. To retrieve the image file for further verification:

• when the vendor claims that an invoice isn’t paid

• when the department claims that ordered product aren’t received.

• when the PO # on the invoice doesn’t match or there is no PO# at all, we have to

forward the image file to the department for further approval or request for more

information.3. Verify the account number

4. For file tracking: Keep live files for one and half year’s online access for any request purpose, and keep archived file for additional five and half year

5. For internal or external audit: Retrieval of image files per any particular audit request.

f. Quality assurance:1. Recheck the legibility of the image file. If we decided to rescan the file, we should

consider:

18



a. How to find the original document? In effect, the question is about after we scan the

file, where, how and how long to keep the hard copy? b. Do the rescanned images belong to the same batch or to a different batch?

2. Linking test (Is the imaging file linked to the records correctly)?

2.2: Under what conditions are invoices looked at outside the Comptroller’s Office?

a. Forward image files to the corresponding department for further approval or request for

more information. In this case, we should define how to forward the imaging file to thedepartment.

• when the department claims that the ordered product are not received

• when the PO # on the invoice doesn’t match or no PO# at all b. Facility service office should have permission to research and access to the image files

related to this department.

c. Purchase department: when the purchasing director requests the item and productprice detail, she needs to look at image file.

d. Per any client’s request, sent image files to the client for further verification. This could

be done by attaching a URL link or an image file in the email.

19



Appendix III: CASE STUDY

Acceptance testing specification for the MFS imaging system:

* According to the Client/Server test plan template, this document belongs to part of System

test Plan, it specifies the test scripts for business scenarios.

This is a complementary list for Feith’s ACCEPTANCE SPECIFICATION. We address specific

concerns related to the Marquette Financial System.1: Testing the capability of the scanning station:

• Handle different sizes, colors, and shapes of documents

• Quantify the scanning speed (seconds/10pages) and readability (legible pages / total scanned pages)

• Fine-tune scanner functions provided by Feith to rescan unreadable documents.

2: Identifying the images:

• Identify a logical document composed of several consecutive pages

• Assign key words to scanned images and index these key words and the whole batch while performing data entry

• Assign key words to scanned images and index these key words and the whole batch in the

situation that we directly import data records from the Libraries. In this case, no data entry task

is needed currently.

• Create one-to-one relationship between imported data entries and corresponding imaged

documents.

3: Integrating FDD with MFS

• Search the imaged document through MFS by currently indexed fields, such as purchase order

number, vendor number, invoice number, etc.

• Search the imaged documents at the batch level.

• Search the imaged documents with incomplete or incorrect information, which usually stay in a

“hold” state, instead of “approved”.

• Demonstrate that authorized users from the outside of the Controller office can retrieve the

images through the MFS.

4. Demonstrate how to enter data records into MFS for a corresponding imaged document storedin the Image server.

5. Viewing images locally or remotely

• View an imaged document via the browser or via FDD client software with appropriate rights.

• Demonstrate the other viewing functions provided by Feith such as: magnifying, displaying

multiple pages in a window, navigating through page control display bars ...

• Quantify the image download time in order to estimate the performance

20



6: Archiving

• Assign a lifetime to an imaged document, after which it is automatically archived or deleted.Eventually, we want to archive invoice images after 18 months. Hence, as an acceptance test, we

want to see a demonstration that has the functionality of assigning a lifetime to a document. After

a lifetime of 18 months, the document may be raised in an exception report for human action,automatically archived and removed from the online storage, or some other action we specify.

• Archive images off line automatically

• Search for off-line archived files

• Retrieve off-line archived files

7: Administration:

• Set up accounts for different users and groups with different access rights.

• For each allowed right, demonstrate that the user can exercise that right both locally and

remotely.

• For each denied right, demonstrate that the user is denied that right.

8: Testing the capability of notifying the users electronically if the image should be verified by theoutside of the Controller’s OfficeTwo possibilities:

1. Export an image to TIFF, other graphic format, or text files, attach it to an e-mail message

and send it out, receive it, extract and view it.2. Place in an email message a link (a URL) to the imaged file

If we use a URL link, we should make sure only authorized users can view the imagesthrough the attached URL.

9: Add additional imaged pages to an existing document.

10: Delete a logical document from a batch

(If we decide that images are not legible, we want to delete them from their batch and rescanthem.)

11: Add additional documents to an existing batch

(After rescanning, we may need to put the document back into its original batch)