0% found this document useful (0 votes)
38 views21 pages

Debark University CS: Department of

This document discusses software testing and object-oriented testing strategies. It defines key terms like error, bug, fault and failure. It describes different testing methodologies like black box testing and white box testing. It also discusses unit testing, integration testing, system testing and different types of performance testing. Finally, it discusses how testing is performed throughout the software development life cycle from requirements to maintenance.

Uploaded by

aklilu Yebuzeye
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
38 views21 pages

Debark University CS: Department of

This document discusses software testing and object-oriented testing strategies. It defines key terms like error, bug, fault and failure. It describes different testing methodologies like black box testing and white box testing. It also discusses unit testing, integration testing, system testing and different types of performance testing. Finally, it discusses how testing is performed throughout the software development life cycle from requirements to maintenance.

Uploaded by

aklilu Yebuzeye
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 21

Debark University

Department of cs

System Analysis & Design


COSC3092

Jan, 2020
03/12/2021 Shimels T. 1
Chapter 6 – Software Testing

• Introduction to Software Testing


• OO testing Activities
• Verification and Validation
• Object-oriented Testing Strategies
• Software Testing and the life cycle

03/12/2021 Shimels T. 2
Software Testing

• Software testing is defined as an activity to check whether


the actual results match the expected results and to ensure
that the software system is  defect free.
• Testing is the process of evaluating a system or its
component(s) with the intent to find whether it satisfies the
specified requirements or not.
• Testing is executing a system in order to identify any gaps,
errors, or missing requirements
• “Testing is the process of executing a program with the
intention of finding errors.” – Myers
• “Testing can show the presence of bugs but never their
absence.” - Dijkstra
03/12/2021 Shimels T. 3
Error, Bug, Fault & Failure
• Error : It is a human action that produces the incorrect
result that produces a fault.
• Bug : The presence of error at the time of execution of
the software.
• Fault : State of software caused by an error.
• Failure : Deviation of the software from its expected
result. It is an event.

03/12/2021 Shimels T. 4
OO testing Activities

• Review OOA and OOD models


• Class testing after code is written
• Integration testing within subsystems
• Integration testing as subsystems are added to the
system
• Validation testing based on OOA use-cases

03/12/2021 Shimels T. 5
Correctness of OOA/OOA Models

• Syntactic correctness
– judged by making sure proper modeling
conventions and symbolism were used
• Semantic correctness
– Does the model reflect the real world problem?

03/12/2021 Shimels T. 6
Consistency of OOA/OOD Models
Consistency of OOA/OOD Models
• Assess the class-responsibility-collaborator (CRC) model and
object-relationship diagram
• Review system design
– examine the object-behavior model to check mapping of
system behavior to subsystems
– review concurrency and task allocation
– examine the use-case scenarios and exercise the user
interface design
• Test object model against the object relationship network to
ensure that all design object contain necessary attributes and
operations needed to implement the collaborations defined for
each CRC card
03/12/2021 Shimels T. 7
1. Revisit the CRC model and the object-relationship model
Class Model Assessment

2. Inspect the description of each CRC card to determine if a


delegated responsibility is part of the collaborator's
definition
3. Invert the connection to ensure that each collaborator that
is asked for service is receiving requests from a
responsible source
4. Using the inverted connections from step 3, determine
whether
– Other classes might be required
– Responsibilities are properly grouped among classes
5. Determine whether widely requested responsibilities might
be combined into a single responsibility
6. Steps 1 to 5 are applied iteratively to each class and during
OOA model evaluation Shimels T.
03/12/2021 8
Verification and Validation
Verification
• The software should confirm to its specification
• Are we building the product right?
Validation
• The software should do what the user really requires
• Are we building the right product?
• Apply:
– Black-box testing to create a deficiency list
– Acceptance tests through alpha (at developer’s site)
and beta (at customer’s site) testing with actual
customers
03/12/2021 Shimels T. 9
Testing Methodologies

Black box testing


• No knowledge of internal program design or code
required.
• Tests are based on requirements and functionality.
White box testing
• Knowledge of the internal program design and code
required.
• Tests are based on coverage of code statements,
branches, paths, conditions.

03/12/2021 Shimels T. 10
Object Oriented Programming Testing Concerns

• Classes may contain operations that are inherited from super


classes
• Subclasses may contain operations that were redefined rather than
inherited
• All classes derived from an previously tested base class need to
be thoroughly tested
Fault-Based Testing
• Best reserved for operations and the class level
• Uses the inheritance structure
• Tester examines the OOA model and hypothesizes a set of
plausible/reasonable defects that may be encountered in operation
calls and message connections and builds appropriate test cases
• Misses incorrect specification and errors in subsystem
interactions
03/12/2021 Shimels T. 11
Scenario-Based Testing

• Using the user tasks described in the use-cases and


building the test cases from the tasks and their variants
• Uncovers errors that occur when any actor interacts
with the Object Oriented software
• Concentrates on what the user does, not what the
product does
• You are better off spending more time on reviewing
the use-cases as they are created and less time on use-
case testing

03/12/2021 Shimels T. 12
Object-oriented Testing Strategies

03/12/2021 Shimels T. 13
Unit testing

• Smallest testable unit is the encapsulated class or


object.
• Tests each module individually.
• Approach:
– Test each method within a class
– Test the attributes of the class between methods
• Follows a white box testing (Logic of the program).
• Done by developers

03/12/2021 Shimels T. 14
Integration Testing
• Once all the modules have been unit tested, integration
testing is performed.
• It is systematic testing.
• Focuses on groups of classes that collaborate in some
manner
• Produce tests to identify errors associated with
interfacing.
Types:
• Big Bang Integration testing
• Top Down Integration testing
• Bottom Up Integration testing
03/12/2021 Shimels T. 15
System Testing

• The system as a whole is tested to uncover


requirement errors.
• Verifies that all system elements work properly and
that overall system function and performance has been
achieved.
Types:
• Alpha Testing
• Beta Testing
• Acceptance Testing
• Performance Testing

03/12/2021 Shimels T. 16
Cont….
Alpha Testing
• It is carried out by the test team within the developing
organization .
Beta Testing
• It is performed by a selected group of friendly customers.
Acceptance Testing
• It is performed by the customer to determine whether to
accept or reject the delivery of the system.
Performance Testing
• It is carried out to check whether the system meets the
nonfunctional requirements identified in the SRS
document.
03/12/2021 Shimels T. 17
Types of Performance Testing:

• Stress Testing
• Regression Testing
• Configuration Testing
• Compatibility Testing
• Recovery Testing
• Maintenance Testing
• Documentation Testing
• Usability Testing

03/12/2021 Shimels T. 18
Software Testing and the life cycle

• Requirements engineering
– criteria: completeness, consistency, feasibility, and testability.
– typical errors: missing, wrong, and extra information
– determine testing strategy
– generate functional test cases
– test specification, through reviews and the like
• Design
– functional and structural tests can be devised on the basis of the
decomposition
– the design itself can be tested (against the requirements)
– formal verification techniques
– the architecture can be evaluated

03/12/2021 Shimels T. 19
Testing and the life cycle (cont’d)

• Implementation
– check consistency implementation and previous
documents
– code-inspection and code-walkthrough
– all kinds of functional and structural test techniques
– extensive tool support
– formal verification techniques
• Maintenance
– regression testing: either retest all, or a more selective
retest
03/12/2021 Shimels T. 20
03/12/2021 Shimels T. 21

You might also like