Software Engineering

Unit IV: User Interface Design and Testing

• Interface design focuses on the following

– The design of interfaces between software components

– The design of interfaces between the software and other nonhuman

producers and consumers of information

– The design of the interface between a human and the computer

• Graphical user interfaces (GUIs) have helped to eliminate many of the most
horrific interface problems

• However, some are still difficult to learn, hard to use, confusing,

counterintuitive, unforgiving, and frustrating

• User interface analysis and design has to do with the study of people and
how they relate to technology

A Spiral Process
• User interface development follows a spiral process

– Interface analysis (user, task, and environment analysis)

• Focuses on the profile of the users who will interact with the
system

• Concentrates on users, tasks, content and work environment

• Studies different models of system function (as perceived from

the outside)

• Delineates the human- and computer-oriented tasks that are

required to achieve system function

– Interface design

• Defines a set of interface objects and actions (and their screen

representations) that enable a user to perform all defined tasks

Computer Science Shift II Page 85

 Software Engineering
in a manner that meets every usability goal defined for the
system

– Interface construction

• Begins with a prototype that enables usage scenarios to be

evaluated

• Continues with development tools to complete the construction

– Interface validation, focuses on

• The ability of the interface to implement every user task

correctly, to accommodate all task variations, and to achieve all
general user requirements

• The degree to which the interface is easy to use and easy to

learn

• The users' acceptance of the interface as a useful tool in their

work

The Golden Rules of User Interface Design

1. Place the User in Control

2. Reduce the User's Memory Load
3. Make the Interface Consistent

Place the User in Control

• Define interaction modes in a way that does not force a user into
unnecessary or undesired actions
– The user shall be able to enter and exit a mode with little or no effort
(e.g., spell check
edit text
spell check)
• Provide for flexible interaction

Computer Science Shift II Page 86

 Software Engineering
– The user shall be able to perform the same action via keyboard
commands, mouse movement, or voice recognition
• Allow user interaction to be interruptible and "undo"able
– The user shall be able to easily interrupt a sequence of actions to do
something else (without losing the work that has been done so far)
– The user shall be able to "undo" any action
• Streamline interaction as skill levels advance and allow the interaction to be
customized
– The user shall be able to use a macro mechanism to perform a
sequence of repeated interactions and to customize the interface
• Hide technical internals from the casual user
– The user shall not be required to directly use operating system, file
management, networking. etc., commands to perform any actions.
Instead, these operations shall be hidden from the user and performed
"behind the scenes" in the form of a real-world abstraction
• Design for direct interaction with objects that appear on the screen
– The user shall be able to manipulate objects on the screen in a manner
similar to what would occur if the object were a physical thing (e.g.,
stretch a rectangle, press a button, move a slider)

Reduce the User's Memory Load

• Reduce demand on short-term memory

– The interface shall reduce the user's requirement to remember past
actions and results by providing visual cues of such actions
• Establish meaningful defaults
– The system shall provide the user with default values that make sense
to the average user but allow the user to change these defaults
– The user shall be able to easily reset any value to its original default
value
• Define shortcuts that are intuitive
– The user shall be provided mnemonics (i.e., control or alt
combinations) that tie easily to the action in a way that is easy to
remember such as the first letter

Computer Science Shift II Page 87

 Software Engineering
• The visual layout of the interface should be based on a real world metaphor
– The screen layout of the user interface shall contain well-understood
visual cues that the user can relate to real-world actions
• Disclose information in a progressive fashion
– When interacting with a task, an object or some behavior, the
interface shall be organized hierarchically by moving the user
progressively in a step-wise fashion from an abstract concept to a
concrete action (e.g., text format options
format dialog box)

Make the Interface Consistent

• The interface should present and acquire information in a consistent fashion

– All visual information shall be organized according to a design
standard that is maintained throughout all screen displays
– Input mechanisms shall be constrained to a limited set that is used
consistently throughout the application
– Mechanisms for navigating from task to task shall be consistently
defined and implemented
• Allow the user to put the current task into a meaningful context
– The interface shall provide indicators (e.g., window titles, consistent
color coding) that enable the user to know the context of the work at
hand
The user shall be able to determine where he has come from and what alternatives
exist for a transition to a new task

• Maintain consistency across a family of applications

– A set of applications performing complimentary functionality shall all
implement the same design rules so that consistency is maintained for
all interaction
• If past interactive models have created user expectations, do not make
changes unless there is a compelling reason to do so
– Once a particular interactive sequence has become a de facto standard
(e.g., alt-S to save a file), the application shall continue this
expectation in every part of its functionality

Computer Science Shift II Page 88

 Software Engineering
Reconciling Four Different Models

• Four different models come into play when a user interface is analyzed and
designed
– User profile model – Established by a human engineer or software
engineer
– Design model – Created by a software engineer
– Implementation model – Created by the software implementers
– User's mental model – Developed by the user when interacting with
the application
• The role of the interface designer is to reconcile these differences and derive
a consistent representation of the interface

User Profile Model

• Establishes the profile of the end-users of the system

– Based on age, gender, physical abilities, education, cultural or ethnic
background, motivation, goals, and personality
• Considers syntactic knowledge of the user
– The mechanics of interaction that are required to use the interface
effectively
• Considers semantic knowledge of the user
– The underlying sense of the application; an understanding of the
functions that are performed, the meaning of input and output, and the
objectives of the system
• Categorizes users as
– Novices
• No syntactic knowledge of the system, little semantic
knowledge of the application, only general computer usage
– Knowledgeable, intermittent users
• Reasonable semantic knowledge of the system, low recall of
syntactic information to use the interface
– Knowledgeable, frequent users

Computer Science Shift II Page 89

 Software Engineering
• Good semantic and syntactic knowledge (i.e., power user), look
for shortcuts and abbreviated modes of operation

Design Model

• Derived from the analysis model of the requirements

• Incorporates data, architectural, interface, and procedural representations of
the software
• Constrained by information in the requirements specification that helps
define the user of the system
• Normally is incidental to other parts of the design model
– But in many cases it is as important as the other parts

Implementation Model

• Consists of the look and feel of the interface combined with all supporting
information (books, videos, help files) that describe system syntax and
semantics
• Strives to agree with the user's mental model; users then feel comfortable
with the software and use it effectively
• Serves as a translation of the design model by providing a realization of the
information contained in the user profile model and the user’s mental model

User's Mental Model

• Often called the user's system perception

• Consists of the image of the system that users carry in their heads
• Accuracy of the description depends upon the user’s profile and overall
familiarity with the software in the application domain

Computer Science Shift II Page 90

 Software Engineering

User Interface Analysis

Elements of the User Interface

• To perform user interface analysis, the practitioner needs to study and

understand four elements
– The users who will interact with the system through the interface
– The tasks that end users must perform to do their work
– The content that is presented as part of the interface
– The work environment in which these tasks will be conducted

User Analysis

• The analyst strives to get the end user's mental model and the design model
to converge by understanding
– The users themselves
– How these people use the system
• Information can be obtained from
– User interviews with the end users
– Sales input from the sales people who interact with customers and
users on a regular basis
– Marketing input based on a market analysis to understand how
different population segments might use the software
– Support input from the support staff who are aware of what works and
what doesn't, what users like and dislike, what features generate
questions, and what features are easy to use

Task Analysis and Modeling

• Task analysis strives to know and understand

– The work the user performs in specific circumstances
– The tasks and subtasks that will be performed as the user does the
work

Computer Science Shift II Page 91

 Software Engineering
– The specific problem domain objects that the user manipulates as
work is performed
– The sequence of work tasks (i.e., the workflow)
– The hierarchy of tasks
• Use cases
– Show how an end user performs some specific work-related task
– Enable the software engineer to extract tasks, objects, and overall
workflow of the interaction
– Helps the software engineer to identify additional helpful features

Content Analysis

• The display content may range from character-based reports, to graphical

displays, to multimedia information
• Display content may be
– Generated by components in other parts of the application
– Acquired from data stored in a database that is accessible from the
application
– Transmitted from systems external to the application in question
• The format and aesthetics of the content (as it is displayed by the interface)
needs to be considered

Work Environment Analysis

• Software products need to be designed to fit into the work environment,

otherwise they may be difficult or frustrating to use
• Factors to consider include
– Type of lighting
– Display size and height
– Keyboard size, height and ease of use
– Mouse type and ease of use
– Surrounding noise
– Space limitations for computer and/or user
– Weather or other atmospheric conditions

Computer Science Shift II Page 92

 Software Engineering
– Temperature or pressure restrictions
– Time restrictions (when, how fast, and for how long)

User Interface Design

• User interface design is an iterative process, where each iteration elaborate

and refines the information developed in the preceding step

• General steps for user interface design

1) Using information developed during user interface analysis, define
user interface objects and actions (operations)
2) Define events (user actions) that will cause the state of the user
interface to change; model this behavior
3) Depict each interface state as it will actually look to the end user
4) Indicate how the user interprets the state of the system from
information provided through the interface

• During all of these steps, the designer must

1) Always follow the three golden rules of user interfaces
2) Model how the interface will be implemented
3) Consider the computing environment (e.g., display technology,
operating system, development tools) that will be used

Interface Objects and Actions

• Interface objects and actions are obtained from a grammatical parse of the
use cases and the software problem statement
• Interface objects are categorized into types: source, target, and application
– A source object is dragged and dropped into a target object such as to
create a hardcopy of a report
– An application object represents application-specific data that are not
directly manipulated as part of screen interaction such as a list

Computer Science Shift II Page 93

 Software Engineering
• After identifying objects and their actions, an interface designer performs
screen layout which involves
– Graphical design and placement of icons
– Definition of descriptive screen text
– Specification and titling for windows
– Definition of major and minor menu items
– Specification of a real-world metaphor to follow

Design Issues to Consider

• Four common design issues usually surface in any user interface

– System response time (both length and variability)
– User help facilities
• When is it available, how is it accessed, how is it represented to
the user, how is it structured, what happens when help is exited
– Error information handling (more on next slide)
• How meaningful to the user, how descriptive of the problem
– Menu and command labeling (more on upcoming slide)
• Consistent, easy to learn, accessibility, internationalization
• Many software engineers do not address these issues until late in the design
or construction process
– This results in unnecessary iteration, project delays, and customer
frustration

Guidelines for Error Messages

• The message should describe the problem in plain language that a typical
user can understand
• The message should provide constructive advice for recovering from the
error
• The message should indicate any negative consequences of the error (e.g.,
potentially corrupted data files) so that the user can check to ensure that they
have not occurred (or correct them if they have)

Computer Science Shift II Page 94

 Software Engineering
• The message should be accompanied by an audible or visual cue such as a
beep, momentary flashing, or a special error color
• The message should be non-judgmental
– The message should never place blame on the user

Questions for Menu Labeling and Typed Commands

• Will every menu option have a corresponding command?

• What form will a command take? A control sequence? A function key? A
typed word?
• How difficult will it be to learn and remember the commands?
• What can be done if a command is forgotten?
• Can commands be customized or abbreviated by the user?
• Are menu labels self-explanatory within the context of the interface?
• Are submenus consistent with the function implied by a master menu item?

User Interface Evaluation

Design and Prototype Evaluation

• Before prototyping occurs, a number of evaluation criteria can be applied

during design reviews to the design model itself
– The amount of learning required by the users
• Derived from the length and complexity of the written
specification and its interfaces
– The interaction time and overall efficiency
• Derived from the number of user tasks specified and the
average number of actions per task
– The memory load on users
• Derived from the number of actions, tasks, and system states
– The complexity of the interface and the degree to which it will be
accepted by the user
• Derived from the interface style, help facilities, and error
handling procedures

Computer Science Shift II Page 95

 Software Engineering
• Prototype evaluation can range from an informal test drive to a formally
designed study using statistical methods and questionnaires
• The prototype evaluation cycle consists of prototype creation followed by
user evaluation and back to prototype modification until all user issues are
resolved
• The prototype is evaluated for
– Satisfaction of user requirements
– Conformance to the three golden rules of user interface design
– Reconciliation of the four models of a user interface

Software Testing

General Characteristics of Strategic Testing

• To perform effective testing, a software team should conduct effective

formal technical reviews
• Testing begins at the component level and work outward toward the
integration of the entire computer-based system
• Different testing techniques are appropriate at different points in time
• Testing is conducted by the developer of the software and (for large
projects) by an independent test group
• Testing and debugging are different activities, but debugging must be
accommodated in any testing strategy

Verification and Validation

• Software testing is part of a broader group of activities called verification

and validation that are involved in software quality assurance
• Verification (Are the algorithms coded correctly?)
– The set of activities that ensure that software correctly implements a
specific function or algorithm
• Validation (Does it meet user requirements?)
– The set of activities that ensure that the software that has been built is
traceable to customer requirements

Computer Science Shift II Page 96

 Software Engineering

A Strategy for Testing Conventional Software

Levels of Testing for Conventional Software

• Unit testing
– Concentrates on each component/function of the software as
implemented
nted in the source code
• Integration testing
– Focuses on the design and construction of the software architecture
• Validation testing
– Requirements are validated against the constructed software
• System testing
– The software and other system elements are tested as a whole

Computer Science Shift II Page 97

 Software Engineering
Introduction to Testing Strategy applied to Conventional Software

• Unit testing
– Exercises specific paths in a component's control structure to ensure
complete coverage and maximum error detection
– Components are then assembled and integrated
• Integration testing
– Focuses on inputs and outputs, and how well the components fit
together and work together
• Validation testing
– Provides final assurance that the software meets all functional,
behavioral, and performance requirements
• System testing
– Verifies that all system elements (software, hardware, people,
databases) mesh properly and that overall system function and
performance is achieved

Test Strategies for Conventional Software

1.Unit Testing

• Focuses testing on the function or software module

• Concentrates on the internal processing logic and data structures
• Is simplified when a module is designed with high cohesion
– Reduces the number of test cases
– Allows errors to be more easily predicted and uncovered
• Concentrates on critical modules and those with high cyclomatic
complexity when testing resources are limited

Computer Science Shift II Page 98

 Software Engineering
Targets for Unit Test Cases

• Module interface
– Ensure that information flows properly into and out of the module
• Local data structures
– Ensure that data stored temporarily maintains its integrity during all
steps in an algorithm execution
• Boundary conditions
– Ensure that the module operates properly at boundary values
established to limit or restrict processing
• Independent paths (basis paths)
– Paths are exercised to ensure that all statements in a module have been
executed at least once
• Error handling paths
– Ensure that the algorithms respond correctly to specific error
conditions

Common Computational Errors in Execution Paths

• Misunderstood or incorrect arithmetic precedence

• Mixed mode operations (e.g., int, float, char)
• Incorrect initialization of values
• Precision inaccuracy and round-off errors
• Incorrect symbolic representation of an expression (int vs. float)

Drivers and Stubs for Unit Testing

• Driver
– A simple main program that accepts test case data, passes such data to
the component being tested, and prints the returned results
• Stubs
– Serve to replace modules that are subordinate to (called by) the
component to be tested

Computer Science Shift II Page 99

 Software Engineering
– It uses the module’s exact interface, may do minimal data
manipulation, provides verification of entry, and returns control to the
module undergoing testing
• Drivers and stubs both represent overhead
– Both must be written but don’t constitute part of the installed software
product

2. Integration Testing

• Defined as a systematic technique for constructing the software architecture

– At the same time integration is occurring, conduct tests to uncover
errors associated with interfaces
• Objective is to take unit tested modules and build a program structure based
on the prescribed design
• Two Approaches
– Non-incremental Integration Testing
– Incremental Integration Testing

 Non-incremental Integration Testing

• Commonly called the “Big Bang” approach

• All components are combined in advance
• The entire program is tested as a whole
• Chaos results
• Many seemingly-unrelated errors are encountered
• Correction is difficult because isolation of causes is complicated
• Once a set of errors are corrected, more errors occur, and testing appears to
enter an endless loop

Computer Science Shift II Page 100

 Software Engineering
 Incremental Integration Testing

• Three kinds

Top-down integration

Bottom-up integration

Sandwich integration
• The program is constructed and tested in small increments
• Errors are easier to isolate and correct
• Interfaces are more likely to be tested completely
• A systematic test approach is applied

Top-down integration

• Modules are integrated by moving downward through the control hierarchy,

beginning with the main module
• Subordinate modules are incorporated in either a depth-first or breadth-first
fashion
– DF: All modules on a major control path are integrated
– BF: All modules directly subordinate at each level are integrated
• Advantages
– This approach verifies major control or decision points early in the
test process
• Disadvantages
– Stubs need to be created to substitute for modules that have not been
built or tested yet; this code is later discarded
– Because stubs are used to replace lower level modules, no significant
data flow can occur until much later in the integration/testing process

Computer Science Shift II Page 101

 Software Engineering

Bottom-up integration

• Integration and testing starts with the most atomic modules in the control
hierarchy
• Advantages
– This approach verifies low-level data processing early in the testing
process
– Need for stubs is eliminated
• Disadvantages
– Driver modules need to be built to test the lower-level modules; this
code is later discarded or expanded into a full-featured version
– Drivers inherently do not contain the complete algorithms that will
eventually use the services of the lower-level modules; consequently,
testing may be incomplete or more testing may be needed later when
the upper level modules are available

Sandwich Integration

• Consists of a combination of both top-down and bottom-up integration

• Occurs both at the highest level modules and also at the lowest level
modules
• Proceeds using functional groups of modules, with each group completed
before the next
– High and low-level modules are grouped based on the control and
data processing they provide for a specific program feature
– Integration within the group progresses in alternating steps between
the high and low level modules of the group
– When integration for a certain functional group is complete,
integration and testing moves onto the next group
• Reaps the advantages of both types of integration while minimizing the need
for drivers and stubs
• Requires a disciplined approach so that integration doesn’t tend towards the
“big bang” scenario

Computer Science Shift II Page 102

 Software Engineering

Test Strategies for Object-Oriented Software

• With object-oriented software, you can no longer test a single operation in

isolation (conventional thinking)
• Traditional top-down or bottom-up integration testing has little meaning
• Class testing for object-oriented software is the equivalent of unit testing for
conventional software
– Focuses on operations encapsulated by the class and the state behavior
of the class
• Drivers can be used
– To test operations at the lowest level and for testing whole groups of
classes
– To replace the user interface so that tests of system functionality can
be conducted prior to implementation of the actual interface
• Stubs can be used
– In situations in which collaboration between classes is required but
one or more of the collaborating classes has not yet been fully
implemented

• Two different object-oriented testing strategies

– Thread-based testing
• Integrates the set of classes required to respond to one input or
event for the system
• Each thread is integrated and tested individually
• Regression testing is applied to ensure that no side effects occur
– Use-based testing
• First tests the independent classes that use very few, if any,
server classes
• Then the next layer of classes, called dependent classes, are
integrated
• This sequence of testing layer of dependent classes continues
until the entire system is constructed

Computer Science Shift II Page 103

 Software Engineering
Validation Testing

• Validation testing follows integration testing

• The distinction between conventional and object-oriented software
disappears
• Focuses on user-visible actions and user-recognizable output from the
system
• Demonstrates conformity with requirements
• Designed to ensure that
– All functional requirements are satisfied
– All behavioral characteristics are achieved
– All performance requirements are attained
– Documentation is correct
– Usability and other requirements are met (e.g., transportability,
compatibility, error recovery, maintainability)
• After each validation test
– The function or performance characteristic conforms to specification
and is accepted
– A deviation from specification is uncovered and a deficiency list is
created

Alpha and Beta Testing

• Alpha testing
– Conducted at the developer’s site by end users
– Software is used in a natural setting with developers watching intently
– Testing is conducted in a controlled environment
• Beta testing
– Conducted at end-user sites
– Developer is generally not present
– It serves as a live application of the software in an environment that
cannot be controlled by the developer

Computer Science Shift II Page 104

 Software Engineering
– The end-user records all problems that are encountered and reports
these to the developers at regular intervals
After beta testing is complete, software engineers make software modifications
and prepare for release of the software product to the entire customer base

System Testing

• Recovery testing
– Tests for recovery from system faults
– Forces the software to fail in a variety of ways and verifies that
recovery is properly performed
– Tests reinitialization, checkpointing mechanisms, data recovery, and
restart for correctness
• Security testing
– Verifies that protection mechanisms built into a system will, in fact,
protect it from improper access
• Stress testing
– Executes a system in a manner that demands resources in abnormal
quantity, frequency, or volume
• Performance testing
– Tests the run-time performance of software within the context of an
integrated system
– Often coupled with stress testing and usually requires both hardware
and software instrumentation
– Can uncover situations that lead to degradation and possible system
failure

Computer Science Shift II Page 105

 Software Engineering

The Art of Debugging

• Debugging occurs as a consequence of successful testing

• It is still very much an art rather than a science
• Good debugging ability may be an innate human trait
• Large variances in debugging ability exist
• The debugging process begins with the execution of a test case
• Results are assessed and the difference between expected and actual
performance is encountered
• This difference is a symptom of an underlying cause that lies hidden
• The debugging process attempts to match symptom with cause, thereby
leading to error correction

Debugging Strategies

• Objective of debugging is to find and correct the cause of a software error

• Bugs are found by a combination of systematic evaluation, intuition, and
luck
• Debugging methods and tools are not a substitute for careful evaluation
based on a complete design model and clear source code
• There are three main debugging strategies
– Brute force
– Backtracking
– Cause elimination

Computer Science Shift II Page 106

 Software Engineering
Characteristics of Testable Software

• Operable
– The better it works (i.e., better quality), the easier it is to test
• Observable
– Incorrect output is easily identified; internal errors are automatically
detected
• Controllable
– The states and variables of the software can be controlled directly by
the tester
• Decomposable
– The software is built from independent modules that can be tested
independently
• Simple
– The program should exhibit functional, structural, and code simplicity
• Stable
– Changes to the software during testing are infrequent and do not
invalidate existing tests
• Understandable
– The architectural design is well understood; documentation is
available and organized

Test Characteristics

• A good test has a high probability of finding an error

– The tester must understand the software and how it might fail
• A good test is not redundant
– Testing time is limited; one test should not serve the same purpose as
another test
• A good test should be “best of breed”
– Tests that have the highest likelihood of uncovering a whole class of
errors should be used
• A good test should be neither too simple nor too complex

Computer Science Shift II Page 107

 Software Engineering
– Each test should be executed separately; combining a series of tests
could cause side effects and mask certain errors

Two Unit Testing Techniques

• Black-box testing
– Knowing the specified function that a product has been designed to
perform, test to see if that function is fully operational and error free
– Includes tests that are conducted at the software interface
– Not concerned with internal logical structure of the software
• White-box testing
– Knowing the internal workings of a product, test that all internal
operations are performed according to specifications and all internal
components have been exercised
– Involves tests that concentrate on close examination of procedural
detail
– Logical paths through the software are tested
– Test cases exercise specific sets of conditions and loops

White-box Testing

• Uses the control structure part of component-level design to derive the test
cases
• These test cases
– Guarantee that all independent paths within a module have been
exercised at least once
– Exercise all logical decisions on their true and false sides
– Execute all loops at their boundaries and within their operational
bounds
Exercise internal data structures to ensure their validity

Computer Science Shift II Page 108

 Software Engineering
White-box Testing technique

1. Basis Path Testing

2. Flow Graph Notation
3. Independent Program Paths
4. Cyclomatic Complexity

Basis Path Testing

• White-box testing technique proposed by Tom McCabe

• Enables the test case designer to derive a logical complexity measure of a
procedural design
• Uses this measure as a guide for defining a basis set of execution paths
• Test cases derived to exercise the basis set are guaranteed to execute every
statement in the program at least one time during testing

Flow Graph Notation

• A circle in a graph represents a node, which stands for a sequence of one or

more procedural statements
• A node containing a simple conditional expression is referred to as a
predicate node
– Each compound condition in a conditional expression containing one
or more Boolean operators (e.g., and, or) is represented by a separate
predicate node
– A predicate node has two edges leading out from it (True and False)
• An edge, or a link, is a an arrow representing flow of control in a specific
direction
– An edge must start and terminate at a node
– An edge does not intersect or cross over another edge
• Areas bounded by a set of edges and nodes are called regions
• When counting regions, include the area outside the graph as a region, too

Computer Science Shift II Page 109

 Software Engineering

Independent Program Paths

• Defined as a pathh through the program from the start node until the end node
that introduces at least one new set of processing statements or a new
condition (i.e., new nodes)
• Must move along at least one edge that has not been traversed before by a
previous path
• Basis sett for flow graph on previous slide
– Path 1: 0-1-11
– Path 2: 0-1-2-3--4-5-10-1-11
– Path 3: 0-1-2-3--6-8-9-10-1-11
– Path 4: 0-1-2-3--6-7-9-10-1-11
• The number of paths in the basis set is determined by the cyclomatic
complexity

Computer Science Shift II Page 110

 Software Engineering
Cyclomatic Complexity

• Provides a quantitative measure of the logical complexity of a program

• Defines the number of independent paths in the basis set
• Provides an upper bound for the number of tests that must be conducted to
ensure all statements have been executed at least once
• Can be computed three ways
– The number of regions
– V(G) = E – N + 2, where E is the number of edges and N is the
number of nodes in graph G
– V(G) = P + 1, where P is the number of predicate nodes in the flow
graph G
• Results in the following equations for the example flow graph
– Number of regions = 4
– V(G) = 14 edges – 12 nodes + 2 = 4
– V(G) = 3 predicate nodes + 1 = 4

Deriving the Basis Set and Test Cases

1) Using the design or code as a foundation, draw a corresponding flow graph

2) Determine the cyclomatic complexity of the resultant flow graph
3) Determine a basis set of linearly independent paths
4) Prepare test cases that will force execution of each path in the basis set

Computer Science Shift II Page 111

 Software Engineering

A Second Flow Graph Example

Loop Testing - General

box testing technique that focuse

• A white-box focusess exclusively on the validity of
loop constructs
• Four different classes of loops exist
– Simple loops
– Nested loops
– Concatenated loops

Computer Science Shift II Page 112

 Software Engineering
– Unstructured loops
• Testing occurs by varying the loop boundary values
– Examples:

for (i = 0; i < MAX_INDEX; i++)

while (currentTemp >= MINIMUM_TEMPERATURE)

Black-box Testing

• Complements white-box testing by uncovering different classes of errors

• Focuses on the functional requirements and the information domain of the
software
• Used during the later stages of testing after white box testing has been
performed
• The tester identifies a set of input conditions that will fully exercise all
functional requirements for a program
• The test cases satisfy the following:
– Reduce, by a count greater than one, the number of additional test
cases that must be designed to achieve reasonable testing
– Tell us something about the presence or absence of classes of errors,
rather than an error associated only with the specific task at hand

Black-box Testing Categories

• Incorrect or missing functions

• Interface errors
• Errors in data structures or external data base access
• Behavior or performance errors
• Initialization and termination errors

Computer Science Shift II Page 113

 Software Engineering

Equivalence Partitioning

• A black-box testing method that divides the input domain of a program into
classes of data from which test cases are derived
• An ideal test case single-handedly uncovers a complete class of errors,
thereby reducing the total number of test cases that must be developed
• Test case design is based on an evaluation of equivalence classes for an
input condition
• An equivalence class represents a set of valid or invalid states for input
conditions
• From each equivalence class, test cases are selected so that the largest
number of attributes of an equivalence class are exercise at once

Object-Oriented Testing Methods

• It is necessary to test an object-oriented system at a variety of different

levels
• The goal is to uncover errors that may occur as classes collaborate with one
another and subsystems communicate across architectural layers
– Testing begins "in the small" on methods within a class and on
collaboration between classes
– As class integration occurs, use-based testing and fault-based testing
are applied
– Finally, use cases are used to uncover errors during the software
validation phase
• Conventional test case design is driven by an input-process-output view of
software
• Object-oriented testing focuses on designing appropriate sequences of
methods to exercise the states of a class

Computer Science Shift II Page 114

 Software Engineering
Testing Implications for Object-Oriented Software

• Because attributes and methods are encapsulated in a class, testing methods

from outside of a class is generally unproductive
• Testing requires reporting on the state of an object, yet encapsulation can
make this information somewhat difficult to obtain
• Built-in methods should be provided to report the values of class attributes
in order to get a snapshot of the state of an object
• Inheritance requires retesting of each new context of usage for a class
– If a subclass is used in an entirely different context than the super
class, the super class test cases will have little applicability and a new
set of tests must be designed

Applicability of Conventional Testing Methods

• White-box testing can be applied to the operations defined in a class

– Basis path testing and loop testing can help ensure that every
statement in an method has been tested
• Black-box testing methods are also appropriate
– Use cases can provide useful input in the design of black-box tests

Fault-based Testing

• The objective in fault-based testing is to design tests that have a high

likelihood of uncovering plausible faults
• Fault-based testing begins with the analysis model
– The tester looks for plausible faults (i.e., aspects of the
implementation of the system that may result in defects)
– To determine whether these faults exist, test cases are designed to
exercise the design or code
• If the analysis and design models can provide insight into what is likely to
go wrong, then fault-based testing can find a significant number of errors

Computer Science Shift II Page 115

 Software Engineering

• Integration testing looks for plausible faults in method calls or message

connections (i.e., client/server exchange)
• Three types of faults are encountered in this context
– Unexpected result
– Wrong method or message used
– Incorrect invocation
• The behavior of a method must be examined to determine the occurrence of
plausible faults as methods are invoked
• Testing should exercise the attributes of an object to determine whether
proper values occur for distinct types of object behavior
• The focus of integration testing is to determine whether errors exist in the
calling code, not the called code

Fault-based Testing vs. Scenario-based Testing

• Fault-based testing misses two main types of errors

– Incorrect specification: subsystem doesn't do what the user wants
– Interactions among subsystems: behavior of one subsystem creates
circumstances that cause another subsystem to fail
• A solution to this problem is scenario-based testing
– It concentrates on what the user does, not what the product does
– This means capturing the tasks (via use cases) that the user has to
perform, then applying them as tests
– Scenario-based testing tends to exercise multiple subsystems in a
single test

Partition Testing (at the Class Level)

• Similar to equivalence partitioning for conventional software

• Methods are grouped based on one of three partitioning approaches
• State-based partitioning categorizes class methods based on their ability to
change the state of the class

Computer Science Shift II Page 116

 Software Engineering
– Tests are designed in a way that exercise methods that change state
and those that do not change state
• Attribute-based partitioning categorizes class methods based on the
attributes that they use
– Methods are partitioned into those that read an attribute, modify an
attribute, or do not reference the attribute at all
• Category-based partitioning categorizes class methods based on the generic
function that each performs
– Example categories are initialization methods, computational
methods, and termination methods

Multiple Class Testing

• Class collaboration testing can be accomplished by applying random testing,

partition testing, scenario-based testing and behavioral testing
• The following sequence of steps can be used to generate multiple class
random test cases
1) For each client class, use the list of class methods to generate a series
of random test sequences; use these methods to send messages to
server classes
2) For each message that is generated, determine the collaborator class
and the corresponding method in the server object
3) For each method in the server object (invoked by messages from the
client object), determine the messages that it transmits
4) For each of these messages, determine the next level of methods that
are invoked and incorporate these into the test sequence

Tests Derived from Behavior Models

• The state diagram for a class can be used to derive a sequence of tests that
will exercise the dynamic behavior of the class and the classes that
collaborate with it
• The test cases should be designed to achieve coverage of all states

Computer Science Shift II Page 117

 Software Engineering
– Method sequences should cause the object to transition through all
allowable states
• More test cases should be derived to ensure that all behaviors for the class
have been exercised based on the behavior life history of the object
• The state diagram can be traversed in a "breadth-first" approach by
exercising only a single transition at a time
– When a new transition is to be tested, only previously tested transitions are used

Computer Science Shift II Page 118