Dry Cleaning Inventory and Order Control System - University of ...

needmoreneedmoreΔιαχείριση Δεδομένων

28 Νοε 2012 (πριν από 4 χρόνια και 9 μήνες)

149 εμφανίσεις

















Dry Cleaning Inventory and Order Control System


Testing Design


Eric Tallman


November 4, 2005


Submitted in partial fulfillment

of the requirements of

CMPS 490


Computer Project
Testing Design


i

November 4, 2005



1

INTRODUCTION

................................
................................
........................

1

1.1

Purpose

................................
................................
................................
................................
............

1

1.2

Scope

................................
................................
................................
................................
................

1

1.3

Glossary
................................
................................
................................
................................
...........

3

1.4

References

................................
................................
................................
................................
.......

4

1.5

Overview of Document
................................
................................
................................
...................

4

2

TEST PLAN

................................
................................
...............................

5

2.1

Schedules and Resources

................................
................................
................................
...............

5

2.2

Test Recording

................................
................................
................................
................................

6

2.3

Test Reporting

................................
................................
................................
................................

6

2.4

Static Testing

................................
................................
................................
................................
..

7

3

VERIFICATION TESTING

................................
................................
.........

7

3.1

Unit Testing

................................
................................
................................
................................
....

7

3.2

Integration testing

................................
................................
................................
..........................

8

3.2.1

“Add” Module Testing

................................
................................
................................
................

8

3.2.2

“Delet
e” Module Testing

................................
................................
................................
............
10

3.2.3

“Edit” Module Testing

................................
................................
................................
...............
11

3.2.4

“View” Module Testing

................................
................................
................................
.............
14

3.2.5

“Login”/“Logout” Module Testing

................................
................................
............................
15

3.2.6

“Order” Module Testing

................................
................................
................................
.............
16

4

VALIDATION TESTING

................................
................................
...........

16

4.1

System Testing

................................
................................
................................
...............................
16

4.2

Acceptance and Beta Testing

................................
................................
................................
.......
17

5

GANTT CHART

................................
................................
.......................

18

INDEX

................................
................................
................................
.................

19

Testing Design


1

November 4, 2005


1

Introduction

1.1

Purpose

The purpose of this document is to overview the
testing design to be used for this
system. Using this testing strategy
, it is intended that all use cases will be tested
thoroughly enough to ensure proper system operation. This testing design will be able to
be applied to any additional modules

or use cases that are added in later versions,
however, o
nly if those modules are designed in such ways that are compatible with the
setup and development of the initial use cases.

The intended audience for this document is the group of developers that may find a
need to modify and update this software. They
will be able to use this document to
analyze how the initial release was tested and may follow a similar path of validation of
the components.

I will also utilize this document in testing the implementation I have set
forth in the project.

1.2

Scope

This docu
ment will cover the aspects of complete testing strategy

to be employed
with this software project. The test design to be presented here is three
-
fold. The three
aspects in testing are: Unit testing, Module testing, and Integration testi
ng. Unit testing
can be seen as the testing of individual files within each module. This however is not
very practical as all of these units are heavily dependent on each other within a module.
Each module will be tested thoroughly however. Each module

requires some user
interaction in some way, i.e. entering data into a simple web form.

Integration testing
will also take place ensuring all functionality can be reached and performed successfully
from the intended user menu.
The testing assumes the web

interface provided will be
Testing Design


2

November 4, 2005


used in testing and utilizing the system implemented for this project.

The web interface
will then forward a request to a JSP

file manipulating Java Bean
s

before interacting with
a database run by a DB
MS, PostgreSQL.

Testing Design


3

November 4, 2005


1.3

Glossary

Acceptance Testing

This is testing using data by the developer
, namely myself, Eric
Tallman.

Beta Testing

This is testing performed by the end user

with actual data.

Database

An organized collection of data.

D
BMS

Also known as a Database Management System. This is a
program/suite used to manage a database and run operations on
this database as indicated by the end user of the system.

Integration Testing

This is testing of the software application as a whole.

All
modules

must be able to be accessed and performed in some
related manner, in this system, the modules are available from a
single user menu

Java Beans

These are Java classes that maintain naming conventions and
standards

to be used in passing information along .jsp files in this
particular use of Beans
. They contain information that coincides
with form

information to be processed. Accordingly, the set and
get methods for the information stored

must follow the Java
Beans standard.

JSP

J
ava
S
erver
P
ages
-

The technology allows Java

code and pre
-
defined actions to be placed within and along side of static
content. Such pages are given the extension *.jsp

Module Testing

T
his is testing of each use case/module within the system
designed. Each use case will be run from beginning to end to
ensure the module acts as was intended and specified in the
System Design Document.

PostgreSQL

A Database

Management Sy
stem that is free open source. The
system makes use of SQL to query the database and returns the
results to the server as requested.

Unit Testing

This is the testing of each file within a module. Although
individual file testing serves little benefit in

this project type, each
unit will be tested through the use of module testing. A unit is
working properly only if it helps perform and achieve the task
that its containing module was intended for.

Web Interface

A simple and straight
-
forward user interfa
ce used to interact with
the system and underlying database. This is made of a set of
interrelated pages that communicate with each other and the web
server.




Testing Design


4

November 4, 2005


1.4

References

Tallman, Eric. “Dry Cleaning Inventory and Order

Control System
-

E
xtended Abstract.”

University of Scranton. 2 September 2005.


Tallman, Eric. “Dry Cleaning Inventory and Order

Control System
-

Justification and

Feasibility.” University of Scranton. 9 September 2005.


Tallman, Eric. “Dry Cleaning Invent
ory and Order Control System
-

Requirements


Specification.” University of Scranton. 23 September 2005.


Tallman, Eric. “Dry Cleaning Inventory and Order Control System


System Design.”


University of Scranton.
21 October 2005.


Tallman, Eric. “Dry Cl
eaning Inventory and Order Control System
Oral Report 2
.”


University of Scranton. 7 October 2005.


1.5

Overview of Document


The rest of this document will describe the
testing

desi
gn in detail. Chapter 2
contains
the testing plan to be used for this system. This includes resources, scheduling
of testing, and an approach philosophy in testing the system.

Chapter 3 covers the details
of verification testing. This includes unit, mo
dule, and integrative testing. Enough
thorough examples of testing will be included so that the developer

may infer how tests
of similar modules

would be tested. Chapter 4 then goes on to detail validation testing.
This

includes checking and validating requirements in the SRS and SDD
. Also there is
acceptance testing and beta testing discussed in chapter 4. A Gantt chart showing project
progress is also included.

Testing Design


5

November 4, 2005


2

Test Plan

The test plan used for this syste
m will be as complete as possible. It is intended
that all units and modules

are tested appropriately using the strategy

that will be laid out
in the following sections.

2.1

Schedules and Resources

Test Phase

Start Date

End Da
te

Unit Testing

September 23, 2005

December 1, 2005

Module Testing

September
25
, 2005

December 5, 2005

Integration Testing

September 27
, 2005

December 7, 2005


As the developer

of this web application, I will perform all testing on th
e system.
I will design tests that I feel are appropriate to properly validate the system’s
functionality. As testing progresses, I will make note of any errors that I come across and
attempt to fix such problems. Once the error is fixed, I will restart

testing on that
particular module to ensure proper functionality. Although each use case makes up one
path in the use of the system, I will then proceed to testing each module one after another
in a random though thorough manner. This will allow me to m
ake sure that erroneous
data is not carried across separate requests that may be handled by the same session of a
logged in user. Once again, any errors at this level will be note
d and fixed as deemed
necessary.

Resources needed for testing include a web
browser to access the web application.
Errors will be fixed in the development environment, Eclipse. After fixes, the application
will be built and redeployed for continued testing.


Testing Design


6

November 4, 2005


2.2

Test Recording

Tested Item


Tester



Expected Results


Experimental

Results


Date Tested


Pass of fail?



Responsible for fixing


(same as tester)

Figure
1
-

This is a sample test record



Figure 1 illustrates the typical test record that I will use in my testing of the web
applic
ation and its components. Although the last field in the table is not necessary when
the tester and developer

responsible for fixing errors are the same, it is included with the
note “(same as tester)” to show good practice in recording
testing activity.

2.3

Test Reporting



Module

/ Use Case

SUCCESSFULLY
TESTED ITEMS

Items With Errors

EXPECTED RE
-
TESTING DATES













Figure
2

-

This is a sample test report



Figure 2 illustrates what is a test report to be u
sed in testing and
development/maintenance of this web application. The following table illustrates the
type of information

that

will be recorded for each test.

Module

/ Use
Case

SUCCESSFULLY
TESTED ITEMS

Items With Errors

EXPECTED RE
-
TESTING DATES

Manag
er Login

All files in the path

EmployeeLoginSave.jsp

Immediately


㄰⼳〯〵

This shows the name of the user “Manager” and the use case that is being tested “Login.”
Using this information, I and other developers will be able to cross reference the SDD

to
inspect the specifics of performing the desired operation.

Testing Design


7

November 4, 2005


2.4

Static Testing


This static testing is a crucial part of the software development process
throughout. As a module and its components are constructed, the developer

m
ust
constantly be mindful of syntactical and design errors. This is especially true as Eclipse,
the development environment used to code this project does not have a JSP

editor.
Therefore, coding is done mostly in a plain text editor. Every
line must be scrutinized as
it is typed in sequence.


It is unrealistic to think this static testing is complete as the code is laid down.
The code will be read through after compilation errors occur or when the system does not
perform in the expected way
. The developer

will then have to examine each line of code
and make sure the process is implemented in a way that is valid and satisfies the system
requirements.


3

Verification Testing

3.1

Unit Testing

Testing of individual units is not feas
ible for a web application based on JSP
. This
is because JSP files are compiled at run
-
time of the system. Thus the units must be tested
via testing of the modules

that these units make up. This is allowable because the modul
e
will not give correct results if the units that make it up do not operate in the way intended
by the developer

of the system.

The only unit testing that is feasible in unit testing is for the Java Beans
. Each bean
class c
an be compiled. This will either result in a functional class file to be utilized or an
error will be returned via compilation line. From this possible error, the developers can
then return to the bean file and correct the cause of the compilation error.

Testing Design


8

November 4, 2005


3.2

Integration testing

At this level, modules

of the system will be tested thoroughly to ensure proper
system implementation. I will describe a test strategy

for each type of module in this
project. I will then list the oth
er modules that may be tested using that strategy. The
modules in this system are generically divided into

the

“add”, “delete”, “edit”, “view”
,
“login/logout”
,

and

“order


categories. The interfaces for these different types of
modules have been universa
lized so that the user may easily learn the ins and outs of the
system.

The first four of
these modules are even similar among
themselves
. However,
the user interfaces for each differ slightly in the type of and presentation of information
that will be a
vailable to the user.

3.2.1


“Add” Module Testing

The “add” modules

within the system have been implemented in very similar
ways. They all follow

a general pattern that is illustrated in the add branch use case
below.


Figure
3

-

Add Branch Use Case Realization



This use case illustrates that all add use cases will start from the
EmployeeHome.jsp page. Clicking on the appropriate link for the module to be tested, in
this example (Add Branch), will forward the user to a
n input form. Here the user will
then test the module using real data that is appropriate for the particular case. JavaScript
will enforce data integrity appropriately for each use case, as each use case’s data set is
different.

Testing Design


9

November 4, 2005



Then the user completes
module testing by hitting the appropriate submit button
on the form page. The user now only has to confirm the addition of the branch
information. If the module works correctly, the user will see a page that displays a
message confirming the addition or
failure to add data to the system.


All modules

of the “add” category must be tested in this way. A number of
actions that take place cannot be manipulated directly by the user. Passed form data
is
used for

the correct execution of those
statements
,

and this process
is automatic from the
time the user clicks on the form’s submission button.

Unfortunately, any fail
ing

modules
may produce errors that have not been anticipated and
may result in a rather cryptic
message on the screen. The de
veloper

would at this point have to go through and
statically test the code to find any errors caused and not handled by the code.

The developer

might then access the database through an interface that is not the
web i
nterface being tested. As an example, the developer/user may login to the database
server and run queries on the same data tested to ensure that the database has successfully
and correctly added the data set as a record.

The following modules
/use cases

may be tested using

this “add” module strategy
:

Add “Account” Customer


p䑄

㔮ㄮ5

䅤搠Ara湣栠


p䑄

㔮ㄮ5T

䅤搠A浰moyee


p䑄

㔮ㄮ1

䅤搠䍬潴桩湧


p䑄

㔮ㄮ㈰

䅤搠f湶n湴潲y


p


㔮ㄮㄳ
Ⱐ㔮㈮I

䅤搠䍵獴潭敲


p䑄

㔮ㄮ㈳
1
, 5.2.10
2




1

Use Case 5.1.23 may only be reached from Use Case 5.1.9. The customer referred to

by this use case is a
“Pay Per Visit” Customer and hence needs its own realization to add data to the system.

2

Use Case 5.2.10 may only be reached from Use Case 5.2.3. The customer referred to by this use case is a
“Pay Per Visit” Customer and hence nee
ds its own realization to add data to the system.

Testing Design


10

November 4, 2005


3.2.2

“Delete” Module Testing

The “delete” modules

within the system have been implemented in very similar
ways. They all follow a general pattern that is illustrated
in the delete branch use case
below.


Figure
4

-

Delete Branch Use Case Realization


This use case illustrates that all delete use cases will start from the EmployeeHome.jsp
page. Clicking on the appropriate link for the module t
o be tested, in this example
(Delete Branch), will forward the user to an input form. Here the user will then test the
module using real data (here for an existing branch) that is appropriate for the particular
case. JavaScript will enforce data integrit
y appropriately for each use case, as each use
case’s data set is different.


Then the user completes module testing by hitting the appropriate submit button
on the form page. The user now only has to confirm the deletion of the branch
information. If th
e module works correctly, the user will see a page that displays a
message confirming the deletion or failure to delete data from the system.

Deletions are unique

modules

as foreign key constraints must be enforced. They
are enforced in
the module code, and therefore the message returned concerning the
failure of a deletion will point the developer

to the area of concern.

For example, in this
branch deletion example, many entries throughout the database maintain foreign

keys to
the branch table. If there still exists an employee that works at the branch to be deleted,
the interface will display a message alerting the developer to that problem.

Testing Design


11

November 4, 2005



All modules

of the “
delete
” category must be tested in thi
s way. A number of
actions that take place cannot be manipulated directly by the user. Passed form data is
used for the correct execution of those statements, and this process is automatic from the
time the user clicks on the form’s submission button. U
nfortunately, any failing modules
may produce errors that have not been anticipated and may result in a rather cryptic
message on the screen. The developer

would at this point have to go through and
statically test the code to find any e
rrors caused and not handled by the code.

The developer

might then access the database through an interface that is not the
web interface being tested. As an example, the developer/user may login to the database
server and run queries
on the same data tested to ensure that the database has successfully
and correctly
deleted
the data set as a record.

Ensuring the correctness and stability of
the data in a database is crucial. The database must not be allowed to enter into an
unallowabl
e state at any time.

The following modules
/use cases may be tested using this “
delete
” module
strategy
:

Delete

“Account” Customer


p䑄

㔮ㄮ
4

䑥汥瑥

B牡nc栠


p䑄

㔮ㄮ1
U

䑥汥瑥

䕭灬oyee


p䑄

㔮ㄮ
T

䑥汥瑥

C汯l桩湧


p䑄

5⸱⸲
1

䑥汥瑥

f湶e湴潲y


p䑄

㔮ㄮ5
4
Ⱐ㔮㈮I




3.2.3

“Edit” Module Testing

The “edit” and “update” modules

within the system have been implemented in
very similar ways. The two different

types of edit modules are really one in the same, but
they have been named in specific ways to meet naming conventions desired by the end
Testing Design


12

November 4, 2005


user. They all follow a general pattern that is illustrated in the update branch use case
below.


Figure
5

-

Update Branch Use Case Realization


This use case illustrates that all edit/update use cases will start from the
EmployeeHome.jsp page. Clicking on the appropriate link for the module to be tested, in
this example (
Update

Branch), will
forward the user to an input form. Here the user will
then test the module using real data (here for an existing branch) that is appropriate for
the particular case. JavaScript will enforce data integrity appropriately for each use case,
as each use case
’s data set is different.


The data from this form is then utilized to in retrieving the desired information
from the system (branch information in this example). The data is displayed in a manner
almost identical to the add modules

of the

system. The fields are filled in with the data
that was queried. The developer
/user then can modify the data in these boxes to ensure
proper JavaScript checking. For example, it should be obvious to the developer/user that
in the phon
e number field, only numbers will be accepted as input, and only in a certain
quantity, i.e. 10 digit phone number.


Then the user completes module testing by hitting the appropriate submit button
on the form page. The user now only has to confirm the
upd
ate

of the branch
Testing Design


13

November 4, 2005


information. If the module works correctly, the user will see a page that displays a
message confirming the
update

or failure to
update
data
in

the system.

Update modules

allow for the possibility to change foreign key
references. As
such, the developer

needs to modify such information in the edit form to ensure the
changes are handled properly in the module code.


All modules

of the “
edit

/“update”

category must be tested in this way.

A
number of actions that take place cannot be manipulated directly by the user. Passed
form data is used for the correct execution of those statements, and this process is
automatic from the time the user clicks on the form’s submission button. Unfortu
nately,
any failing modules may produce errors that have not been anticipated and may result in
a rather cryptic message on the screen. The developer

would at this point have to go
through and statically test the code to find any errors
caused and not handled by the code.

The developer

might then access the database through an interface that is not the
web interface being tested. As an example, the developer/user may login to the database
server and run queries on the

same data tested to ensure that the database has successfully
and correctly
updated

the data set as a record. Ensuring the correctness and stability of
the data in a database is crucial. The database must not be allowed to enter into an
unallowable stat
e at any time.

The following modules
/use cases may be tested using this “
edit

/”update”

module
strategy
:

Update “Account” Customer


p䑄

㔮ㄮ5

啰摡瑥tf湶n湴nry


p䑄

㔮ㄮㄵⰠ㔮㈮5

啰摡瑥⁅浰moyee


p䑄

㔮ㄮ5

啰摡瑥⁂牡nc栠


p䑄

㔮ㄮㄹ

䕤楴⁃畳瑯ue爠r牤rr


p䑄

㔮ㄮㄱⰠ㔮㈮5

啰摡瑥⁃t潴桩湧


p䑄

㔮ㄮ㈲

Testing Design


14

November 4, 2005


3.2.4

“View” Module Testing

The “view” modules

within the system have been implemented in v
ery similar
ways. They all follow a general pattern that is illustrated in the view customer order use
case below.


Figure
6

-

View Order Use Case Realization


Testing at this level will begin with the developer
/user inputting data into the
form that they are presented with after clicking the desired module’s link from the
EmployeeHome.jsp page

for an employee
.
A view for the customer will involve logging
in which will be covered in a later section.
From here,
the proper data checking will be
performed on the client side. This is not an issue since this system will not be online and
only trusted personnel will be allowed to access the system.


From here, the developer

will then click on the fo
rm’s submission button starting
the transaction/module. The user will then be given access to edited information that is
displayed on the screen. If no matches are returned from using the module but there were
no errors, a message indicating this will be

displayed. Once again, if there is a run
-
time
error in the code and files fail to perform as they were intended, the developer will have
to go into the source code and statically test the code to find errors. They should be
keeping track of these errors

that occur along the way, as in all module testing of any
type. Testing concludes for these modules

once the developer has confirmed that the
module
can produce existing properly queried information and no errors are found.




Testing Design


15

November 4, 2005



The follow
ing modules
/use cases can be tested using this “view” testing strategy
:

View Customer Order


p䑄

㔮ㄮ㄰Ⱐ㔮㈮5

m物湴rf湶潩捥


p䑄

㔮ㄮ㈴Ⱐ㔮㈮ㄱ

䝥湥ra瑥tfnc潭攠剥灯牴p


p䑄

㔮ㄮㄶ


e眠w牤e爠


㔮㌮5


3.2.5

“Login”/“Logout” Module Testing

Module testing for login to the system involves the developer
/user entering both valid
and invalid user credentials at the login screens. Developers

must handle this t
esting and
will either receive a failed login message or will be forwarded to the proper page for
which they are entitled to access from the system. The developer must ensure that these
privileged accesses are handled properly in the code. This may be do
ne by logging in as
a regular employee and try to obtain administrative rights. Once the developer has tested
and confirmed that login is correct, this module is considered tested and functional.

The
login in SDD

5.3.1 is also a view module.

Hence, both logging in and properly viewing
an existing order must be checked.


Logout module testing involves taking an existing session, signing out using the
appropriate logout button, and then try to use that session to gain access to the system.
Thi
s should be disallowed by the code and must be confirmed by the developer
. Any
errors that occur during this process must be logged and modified by the appropriate
personnel, namely the developer.

The following modules
/us
e cases must be tested using these login/logout strategies.

Login


p䑄

㔮ㄮㄬ‵⸲⸱Ⱐ㔮㌮I

iog潵琠


p䑄

㔮ㄮ㈬‵⸲5O



Testing Design


16

November 4, 2005


3.2.6

“Order” Module Testing

This module testing strategy

involves placing and checking out a custom
er’s order. As
such, these modules

may be tested using the procedures laid forth in 3.2.1 (for placing a
customer order) and 3.2.2 (deleting a customer order) of this document. However, each
has a few additional things to check. To place

an order, it is possible that no customer
will be found in the database. The module will then switch to an add module to complete
this. The modules must be tested in unison and separately. That is, it will not always be
necessary to utilize the add mod
ule when playing an order. It may be that the customer is
already in the database.

It is also crucial that income totals and clothing counts are properly adjusted when
checking out an order. It is not acceptable just to delete the order. Other tables in

the
database must be modified. The developer

must run test cases with “real” data and
ensure this is handled properly. Using this strategy
, the order module testing may be
completed and ensure the proper functioning of

the system.

The following modules
/use cases may use this strategy

for testing.

Place Customer Order


p䑄

㔮ㄮ㤬‵⸲⸳

C桥c歯畴⁃畳瑯ue爠r牤r爠


p䑄

㔮ㄮㄲⰠ
㔮㈮5


4

Validation Testing

4.1

System Testing

At this level of testing, we should continually utilize the module testing as
described in chapter 3 of this document. Using these modules

in many combinations to
check for possible errors is essential. At this point in testing, it is al
so useful to cross
-
reference the SDD

and Requirements Specification Document. We have to ensure that
the system implements the use cases in ways that are compatible with what was stated in
Testing Design


17

November 4, 2005


these documents. The use case realizations should be
used as a guide in initial system
testing. Each use case should be followed step by ste
p to ensure the module conforms
with the documentation.

4.2

Acceptance and Beta Testing

Acceptance testing will continually be performed by me, the developer

of this
project. Once the system is implemented, the system will undergo continual testing by
the business that chooses to use the system. The business will be asked to provide
feedback on system functionality. Any suggestions that merit another rel
ease of the
software will be implemented if possible and deployed. This will be a continual process
of testing. There is always a way to improve the system, so this beta testing by the
customer is essential.

Testing Design


18

November 4, 2005


5

Gantt

Chart

Activity

Complete

S
tatus

9/2

9/
9

9/
23

9
/30

10/2
1

11/5

11/2
8

12/
9

Proposal

100%

A

SSSSS








Analysis

100
%

A


SSS

SSSSS







Specification

100
%

A



BSSSS

SSSSS






High
-
level
Design

9
8
%

S



SSS

SSSSS

SSSA

A
AAA

A



System Design

9
8
%

S



SS

SSSSS

SSSSS

SSS
A

A



Implementation

40
%

C



SSSSS

SSSSS

SSSSS

SSSSS

SS


Module Testing

20
%

S




SSSSS

SSSSS

SSSSS

SSSS


Integration
Testing

5
-
10
%

S





SSS

SSSSS

SSSSS

SSSSS

SS

Project Status Symbols

S

Scheduled

A

Satisfactory

C

Caution

F

Critical


Planni
ng/Progress Symbols

B

Work Before Scheduled Time

S

Scheduled Activity Time

A

Work After Scheduled Time

Testing Design


19

November 4, 2005


Index

Beans, 2, 3, 8

Database, 3

developer, 3, 4, 5, 6, 7, 9, 11, 13, 14, 15, 16, 17, 18

Developers, 16

form, 3

Gantt, 19

Java, 3

JSP, 2, 3, 7

modules, 1, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16,
17, 18

Order, 4

SDD, 4, 7, 10, 12, 14, 16, 17, 18

strategy, 1, 5, 8, 10, 12, 14, 15, 17