BOWEN UNIVERSITY, IWO

COLLEGE OF COMPUTING AND COMMUNICATION STUDIES

DEPARTMENT OF SOFTWARE ENGINEERING
SEN 301- OBJECT ORIENTED ANALYSIS AND DESIGN
LECTURE NOTE 4

Software Testing
7.1 TESTING AND QUALITY ASSURANCE

Once a program code is written, it must be tested to detect and subsequently handle
all errors in it. A number of schemes are used for testing purposes.
Another important aspect is the fitness of purpose of a program that ascertains
whether the program serves the purpose which it aims for. The fitness defines the
software quality.
7.1.1. Testing Object-Oriented Systems
Testing is a continuous activity during software development. In object-oriented
systems, testing encompasses three levels, namely, unit testing, subsystem testing,
and system testing.
7.1.2. Unit Testing
In unit testing, the individual classes are tested. It is seen whether the class attributes
are implemented as per design and whether the methods and the interfaces are error-
free. Unit testing is the responsibility of the application engineer who implements
the structure.
7.1.3. Subsystem Testing
This involves testing a particular module or a subsystem and is the responsibility of
the subsystem lead. It involves testing the associations within the subsystem as well
as the interaction of the subsystem with the outside. Subsystem tests can be used as
regression tests for each newly released version of the subsystem.
7.1.4. System Testing
System testing involves testing the system as a whole and is the responsibility of the
quality-assurance team. The team often uses system tests as regression tests when
assembling new releases.

7.2. Categories of System Testing

 Alpha testing : This is carried out by the testing team within the
organization that develops software.
Beta testing : This is carried out by select group of co-operating customers.
Acceptance testing : This is carried out by the customer before accepting the
deliverables.

7.3. Object-Oriented Testing Techniques

Grey Box Testing

The different types of test cases that can be designed for testing object-oriented
programs are called grey box test cases. Some of the important types of grey box
testing are:
State model based testing :This encompasses state coverage, state
transition coverage, and state transition path coverage.
Use case based testing: Each scenario in each use case is tested.
Class diagram based testing: Each class, derived class, associations, and
aggregations are tested.
Sequence diagram based testing : The methods in the messages in
the sequence diagrams are tested.

7.4. Techniques for Subsystem Testing

The two main approaches of subsystem testing are:

Thread based testing : All classes that are needed to realize a single use
case in a subsystem are integrated and tested.
Use based testing : The interfaces and services of the modules at each level
of hierarchy are tested. Testing starts from the individual classes to the small
modules comprising of classes, gradually to larger modules, and finally all
the major subsystems.

7.5. The Full-Lifecycle Object-Oriented Testing (FLOOT)

The Full-Lifecycle Object-Oriented Testing (FLOOT) methodology is a collection of

testing techniques to verify and validate object-oriented software. The FLOOT
lifecycle is depicted in Figure 1, indicating a wide variety of techniques (described
in Table 1 are available to you throughout all aspects of software development. The
list of techniques is not meant to be complete: instead the goal is to make it explicit
that you have a wide range of options available to you. It is important to understand
that although the FLOOT method is presented as a collection of serial phases it does
not need to be so: the techniques of FLOOT can be applied with evolutionary/agile
processes as well. The reason why I present the FLOOT in a "traditional" manner is
to make it explicit that you can in fact test throughout all aspects of software
development, not just during coding.
 
Figure 1. The FLOOT Lifecycle.
 Table 1. Testing techniques.

FLOOT Technique Description

Testing that verifies the item being tested when given the appropriate input
Black-box testing
provides the expected results.
Boundary-value
Testing of unusual or extreme situations that an item should be able to handle.
testing
Class testing The act of ensuring that a class and its instances (objects) perform as defined.
Class-integration The act of ensuring that the classes, and their instances, form some software
testing perform as defined.
Code review A form of technical review in which the deliverable being reviewed is source code.
Component testing The act of validating that a component works as defined.
Coverage testing The act of ensuring that every line of code is exercised at least once.
Design review A technical review in which a design model is inspected.
Inheritance- The act of running the test cases of the super classes, both direct and indirect, on a
regression testing given subclass.
Integration testing Testing to verify several portions of software work together.
Method testing Testing to verify a method (member function) performs as defined.
An inspection, ranging anywhere from a formal technical review to an informal
Model review walkthrough, by others who were not directly involved with the development of
the model.
Path testing The act of ensuring that all logic paths within your code are exercised at least once.
A process by which your users work through a collection of use cases, using a
Prototype review prototype as if it was the real system. The main goal is to test whether the design of
the prototype meets their needs.
The best way to determine if a model actually reflects what is needed, or what
Prove it with code should be built, is to actually build software based on that model that show that the
model works.
Regression testing The acts of ensuring that previously tested behaviors still work as expected after
changes have been made to an application.
The act of ensuring that the system performs as expected under high volumes of
Stress testing
transactions, users, load, and so on.
A quality assurance technique in which the design of your application is examined
critically by a group of your peers. A review typically focuses on accuracy, quality,
Technical review
usability, and completeness. This process is often referred to as a walkthrough, an
inspection, or a peer review.
Usage scenario A testing technique in which one or more person(s) validate a model by acting
testing through the logic of usage scenarios.
The testing of the user interface (UI) to ensure that it follows accepted UI
User interface testing standards and meets the requirements defined for it. Often referred to as
graphical
user interface (GUI) testing.
White-box testing Testing to verify that specific lines of code work as defined. Also
referred to as clear-box testing.
 7.6. Software Quality Assurance

Software Quality
Schulmeyer and McManus have defined software quality as “the fitness
for use of the total software product”. A good quality software does
exactly what it is supposed to do and is interpreted in terms of
satisfaction of the requirement specification laid down by the user.

7.6.1. Quality Assurance

Software quality assurance is a methodology that determines the extent to
which a software product is fit for use. The activities that are included for
determining software quality are:
Auditing
Development of standards and guidelines
Production of reports
Review of quality system
7.6.2. Quality Factors
Correctness : Correctness determines whether the
software requirements are appropriately met.
Usability : Usability determines whether the software can be used
by different categories of users (beginners, non-technical, and
experts).
Portability : Portability determines whether the software can
operate in different platforms with different hardware
devices.
Maintainability : Maintainability determines the ease at which
errors can be corrected and modules can be updated.
Reusability : Reusability determines whether the modules and
classes can be reused for developing other software products.
Object-Oriented Metrics
Metrics can be broadly classified into three categories: project metrics,
product metrics, and process metrics.
Project Metrics
Project Metrics enable a software project manager to assess the status and
performance of an ongoing project. The following metrics are appropriate
for object-oriented software projects:
Number of scenario scripts
Number of key classes
Number of support classes
Number of subsystems
Product Metrics
Product metrics measure the characteristics of the software product that has
been developed. The product metrics suitable for object-oriented systems
are:
Methods per Class: It determines the complexity of a class. If all the
methods of a class are assumed to be equally complex, then a class
with more methods is more complex and thus more susceptible to
errors.
Inheritance Structure: Systems with several small inheritance
lattices are more well– structured than systems with a single large
inheritance lattice. As a thumb rule, an inheritance tree should not
have more than 7 (± 2) number of levels and the tree should be
balanced.
Coupling and Cohesion: Modules having low coupling and high
cohesion are considered to be better designed, as they permit greater
reusability and maintainability.
Response for a Class: It measures the efficiency of the methods that
are called by the instances of the class.
Process Metrics
Process metrics help in measuring how a process is performing. They are
collected over all projects over long periods of time. They are used as
indicators for long-term software process improvements. Some process
metrics are:
Number of KLOC (Kilo Lines of Code)
Defect removal efficiency
Average number of failures detected during testing
Number of latent defects per KLOC