0% found this document useful (0 votes)
3 views29 pages

MSIS-811 Unit 8

Advanced information system

Uploaded by

sun.hope4
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)
3 views29 pages

MSIS-811 Unit 8

Advanced information system

Uploaded by

sun.hope4
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/ 29

Advanced Systems Analysis and Design – MSIS811

Software Testing

Chapter 8 Software Testing 1


Program testing

 Testing is intended to show that a program does what it is


intended to do and to discover program defects before it
is put into use.
 When you test software, you execute a program using
artificial data.
 You check the results of the test run for errors, anomalies
or information about the program’s non-functional
attributes.
 Can reveal the presence of errors NOT their
absence.
 Testing is part of a more general verification and
validation process, which also includes static validation
techniques.
Chapter 8 Software Testing 2
Program testing goals

 To demonstrate to the developer and the customer that the


software meets its requirements.
 For custom software, this means that there should be at
least one test for every requirement in the requirements
document. For generic software products, it means that
there should be tests for all of the system features, plus
combinations of these features, that will be incorporated in
the product release.
 To discover situations in which the behavior of the software is
incorrect, undesirable or does not conform to its specification.
 Defect testing is concerned with rooting out undesirable
system behavior such as system crashes, unwanted
interactions with other systems, incorrect computations
and data corruption.
Chapter 8 Software Testing 3
Validation and defect testing

 The first goal leads to validation testing


 You expect the system to perform correctly using a given
set of test cases that reflect the system’s expected use.
 The second goal leads to defect testing
 The test cases are designed to expose defects. The test
cases in defect testing can be deliberately obscure and
need not reflect how the system is normally used.

Chapter 8 Software Testing 4


Testing process goals

 Validation testing
 To demonstrate to the developer and the system customer
that the software meets its requirements
 A successful test shows that the system operates as
intended.
 Defect testing
 To discover faults or defects in the software where its
behavior is incorrect or not in conformance with its
specification
 A successful test is a test that makes the system perform
incorrectly and so exposes a defect in the system.

Chapter 8 Software Testing 5


Verification vs validation

Testing is part of a broader process of software


verification and validation (V & V).
 Verification: "Are we building the product right”.
 The software should conform to its specification i.e. to check that
the software meets its stated functional and non-functional
requirements.
 Validation: "Are we building the right product”.
 The software should do what the user really requires i.e to
ensure that the software meets the customer’s expectations.
 The ultimate goal of verification and validation
processes is to establish confidence that the
software system is ‘fit for purpose’.
Chapter 8 Software Testing 6
Inspections and testing

 Software inspections are concerned with analysis of


the static system representation to discover
problems (static verification)
 Software testing is concerned with exercising and
observing product behaviour (dynamic verification)
 The system is executed with test data and its operational
behaviour is observed.

Chapter 8 Software Testing 7


Inspections and testing

Chapter 8 Software Testing 8


Software inspections

 These involve people examining the source


representation with the aim of discovering
anomalies and defects.
 Inspections not require execution of a system so
may be used before implementation.
 They may be applied to any representation of the
system (requirements, design,configuration data,
test data, etc.).
 They have been shown to be an effective technique
for discovering program errors.

Chapter 8 Software Testing 9


Advantages of inspections

 During testing, errors can mask (hide) other errors.


But inspection is a static process, you don’t have to
be concerned with interactions between errors.
 Incomplete versions of a system can be inspected
without additional costs. If a program is incomplete,
then you need to develop specialized test harnesses
to test the parts that are available.
 As well as searching for program defects, an
inspection can also consider broader quality
attributes of a program, such as compliance with
standards, portability and maintainability.

Chapter 8 Software Testing 10


Inspections and testing

 Inspections and testing are complementary and not


opposing verification techniques.
 Both should be used during the V & V process.
 Inspections can check conformance with a
specification but not conformance with the
customer’s real requirements.
 Inspections cannot check non-functional
characteristics such as performance, usability, etc.

Chapter 8 Software Testing 11


Stages of testing

 Development testing, where the system is tested


during development to discover bugs and defects.
 Release testing, where a separate testing team test a
complete version of the system before it is released
to users.
 User testing, where users or potential users of a
system test the system in their own environment.

Chapter 8 Software Testing 12


Development testing

 Development testing includes all testing activities


that are carried out by the team developing the
system.
 Unit testing, where individual program units or object
classes are tested. Unit testing should focus on testing the
functionality of objects or methods.
 Component testing, where several individual units are
integrated to create composite components. Component
testing should focus on testing component interfaces.
 System testing, where some or all of the components in a
system are integrated and the system is tested as a whole.
System testing should focus on testing component
interactions.

Chapter 8 Software Testing 13


Unit testing

 Unit testing is the process of testing individual


components in isolation.
 It is a defect testing process.
 Units may be:
 Individual functions or methods within an object
 Object classes with several attributes and methods
 Composite components with defined interfaces used to
access their functionality.

Chapter 8 Software Testing 14


Object class testing

 Complete test coverage of a class involves


 Testing all operations associated with an object
 Setting and interrogating all object attributes
 Exercising the object in all possible states.
 Inheritance makes it more difficult to design object
class tests as the information to be tested is not
localised.

Chapter 8 Software Testing 15


Component testing

 Software components are often composite components


that are made up of several interacting objects.
 For example, in the weather station system, the reconfiguration
component includes objects that deal with each aspect of the
reconfiguration.
 You access the functionality of these objects through
the defined component interface.
 Testing composite components should therefore focus
on showing that the component interface behaves
according to its specification.
 You can assume that unit tests on the individual objects within
the component have been completed.
Chapter 8 Software Testing 16
Interface testing

 Objectives are to detect faults due to interface errors


or invalid assumptions about interfaces.
 Interface types
 Parameter interfaces Data passed from one method or
procedure to another.
 Shared memory interfaces Block of memory is shared
between procedures or functions.
 Procedural interfaces Sub-system encapsulates a set of
procedures to be called by other sub-systems.
 Message passing interfaces Sub-systems request services
from other sub-systems

Chapter 8 Software Testing 17


Interface errors

 Interface misuse
 A calling component calls another component and makes
an error in its use of its interface e.g. parameters in the
wrong order.
 Interface misunderstanding
 A calling component embeds assumptions about the
behaviour of the called component which are incorrect.
 Timing errors
 The called and the calling component operate at different
speeds and out-of-date information is accessed.

Chapter 8 Software Testing 18


Interface testing guidelines

 Design tests so that parameter values to a called


procedure are at the extreme ends of their ranges.
 Always test pointer parameters with null pointers.
 Design tests which cause the component to fail.
 Use stress testing in message passing systems.
 In shared memory systems, vary the order in which
components are activated.

Chapter 8 Software Testing 19


System testing

 System testing during development involves


integrating components to create a version of the
system and then testing the integrated system.
 The focus in system testing is testing the
interactions between components.
 System testing checks that components are
compatible, interact correctly and transfer the right
data at the right time across their interfaces.
 System testing tests the emergent behaviour of a
system.

Chapter 8 Software Testing 20


System and component testing

 During system testing, reusable components that


have been separately developed and off-the-shelf
systems may be integrated with newly developed
components. The complete system is then tested.
 Components developed by different team members
or sub-teams may be integrated at this stage.
System testing is a collective rather than an
individual process.
 In some companies, system testing may involve a separate
testing team with no involvement from designers and
programmers.

Chapter 8 Software Testing 21


Use-case testing

 The use-cases developed to identify system


interactions can be used as a basis for system testing.
 Each use case usually involves several system
components so testing the use case forces these
interactions to occur.
 The sequence diagrams associated with the use case
documents the components and interactions that are
being tested.

Chapter 8 Software Testing 22


Release testing

 Release testing is the process of testing a particular


release of a system that is intended for use outside of
the development team.
 The primary goal of the release testing process is to
convince the supplier of the system that it is good
enough for use.
 Release testing, therefore, has to show that the system delivers
its specified functionality, performance and dependability, and
that it does not fail during normal use.
 Release testing is usually a black-box testing process
where tests are only derived from the system
specification.
Chapter 8 Software Testing 23
Release testing and system testing

 Release testing is a form of system testing.


 Important differences:
 A separate team that has not been involved in the system
development, should be responsible for release testing.
 System testing by the development team should focus on
discovering bugs in the system (defect testing). The
objective of release testing is to check that the system
meets its requirements and is good enough for external use
(validation testing).

Chapter 8 Software Testing 24


Performance testing

 Part of release testing may involve testing the


emergent properties of a system, such as
performance and reliability.
 Tests should reflect the profile of use of the system.
 Performance tests usually involve planning a series
of tests where the load is steadily increased until the
system performance becomes unacceptable.
 Stress testing is a form of performance testing
where the system is deliberately overloaded to test
its failure behavior.

Chapter 8 Software Testing 25


User testing

 User or customer testing is a stage in the testing


process in which users or customers provide input
and advice on system testing.
 User testing is essential, even when comprehensive
system and release testing have been carried out.
 The reason for this is that influences from the user’s
working environment have a major effect on the reliability,
performance, usability and robustness of a system. These
cannot be replicated in a testing environment.

Chapter 8 Software Testing 26


Types of user testing

 Alpha testing
 Users of the software work with the development team to
test the software at the developer’s site.
 Beta testing
 A release of the software is made available to users to allow
them to experiment and to raise problems that they
discover with the system developers.
 Acceptance testing
 Customers test a system to decide whether or not it is ready
to be accepted from the system developers and deployed in
the customer environment. Primarily for custom systems.

Chapter 8 Software Testing 27


30/10/2014 Chapter 8 Software Testing 28
30/10/2014 Chapter 8 Software Testing 29

You might also like