Corso di Laurea Magistrale

in
Ingegneria Informatica
Module B-Software Systems
Engineering
a.a. 2012-2013

Gigliola Vaglini
1 11

Software Testing
Lecture 11

Verification&Validation
Verification:
Are we building the software right?
The software should conform to its specification.

Validation:
Are we building the right software?
The software should do what the user really
requires.
3

V&V comincia appena si decide di

cominciare a realizzare un prodotto
software
V&V dura oltre la consegna e finch il
software in uso

V & V confidence
Aim of V & V is to establish confidence that the system is
fit for purpose.
Depends on systems purpose, user expectations and
marketing environment
Software purpose
The level of confidence depends on how critical the software is to an
organisation.

User expectations
Users may have low expectations of certain kinds of software.

Marketing environment
Getting a product to market early may be more important than finding
defects in the program.

Deve essere specificato il livello di

dependability (rispondenza alle
necessit) che il software deve
raggiungere
Il progettista deve essere in grado di
determinare quando questo livello
raggiunto

Differenti misure di dependability

Availability (disponibilit): misura il QoS in
termini di rapporto tra il tempo di
funzionamento e il tempo in cui il sistema gi
Reliability (affidabilit): si misura in termini
della frazione delle operazioni terminate con
successo rispetto a tutte quelle tentate
Il QoS si pu misurare anche in termini del
tempo che passa tra due fallimenti successivi

Verification theory: definitions

Failure: observable event that the user
see as anomalous
Fault: the cause of a failure
Error: it has two meanings
A difference between the computed and the
expected result
An action (generally of a person) that causes
a fault
8

Verification theory
P : D R.
P(d) is a correct result if it satisfies
the program specification, i.e.
ok(P,d)=true
P is correct (written ok(P)) if
ok(P,d)=true for each dD

What kind of techniques

Testing: dynamic technique
The behavior of the product is experimented
We are looking for counterexamples
Analysis: static thecnique
Properties are proved
V&V should include both dynamic and validation
techniques.

10

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 programs non-functional attributes.

11

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.

12

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 systems expected use.
A successful test shows that the system operates as intended.

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.
A successful test is a test that makes the system perform
incorrectly and so exposes a defect in the system.

13

An input-output model of
program testing

The system is executed with test data

and its operational behaviour is observed.

14

Inspections and testing

Software inspections Concerned with
analysis of the static system
representation to discover problems
(static verification)
Do not require execution of a system so may
be used before implementation
May be supplement by tool-based document
and code analysis.

15

Inspections and testing

16

Advantages of inspections
During testing, errors can mask (hide) other errors.
Because inspection is a static process, you dont 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.
17

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 customers real requirements.
Inspections cannot check non-functional characteristics
such as performance, usability, etc.

18

A model of the software

testing process

19

La verifica nellingegneria
tradizionale
Quando si progettano ponti un test
assicura infinite situazioni corrette
Se un ponte pu sopportare un carico di
10000 tonnellate, pu sopportare
qualunque carico di peso inferiore

20

10

La verifica in SE
I programmi non hanno un comportamento
continuo
Verificare una funzione in un punto non
dice niente su tutti gli altri punti
A=/(x+20)
Ogni valore di x corretto eccetto x=-20

21

Tesi di Dijkstra
Program testing can be used to show the
presence of bugs, but never to show their
absence (Dijkstras thesis 1972)
Non vi garanzia che, se alla n-esima prova, un
modulo od un sistema ha risposto correttamente
(ovvero non sono stati pi riscontrati difetti),
altrettanto possa fare alla (n+1)-esima
Impossibile produrre tutte le possibili
configurazioni di valori di input (test case) in
corrispondenza di tutti i possibili stati interni di
un sistema software
22

11

Impatto di nuove tecnologie

Tecniche di sviluppo pi avanzate possono
ridurre la frequenza di alcuni tipi di
errori, ma non eliminano del tutto gli
errori
Nuovi approcci introducono nuovi tipi di
errori: ad esempio il deadlock per i
programmi concorrenti.

23

24

12

Come trattare i risultati

dellanalisi
Ottimistica inaccuratezza
Si possono accettare programmi che non rispettano
alcune propriet: testing

Pessimistica inaccuratezza
Si possono non accettare programmi che possiedono
le propriet volute: tecniche di analisi automatica,
theorem proving

Propriet semplificate
Si riduce il grado di libert per semplificare le
propriet da verificare: model checking
25

Propriet dei risultati dellanalisi

Soundness: si accettano programmi solo
se hanno una certa propriet
Completeness: si accetta ogni programma
che ha una certa propriet

26

13

The oracle
An oracle is any (human or mechanical)
agent which decides whether a program
behaves correctly in a given test, and
accordingly produces a verdict of pass
or fail.
There exist many different kinds of
oracles, and oracle automation can be
very difficult and expensive.
27

Come derivare un buon oracolo

Nella fase della specifica dei requisiti
Rendere le propriet verificabili

Gli oracoli di sistema vanno progettati durante il

progetto del sistema. Ad es. in un progetto
UML
Una message sequence chart indica un caso di test e
unuscita attesa
Una statechart una macchina a stati finiti che
descrive tutti i comportamenti ammissibili

28

14

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.

29

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.

30

15

Unit testing
One module is tested in isolation
It is a defect testing process: we are looking for logical
errors
It is performed directly by the module programmer
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.

31

Object class testing

Testing 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.

32

16

Automated testing
Whenever possible, unit testing should be automated so
that tests are run and checked without manual intervention.
In automated unit testing, you make use of a test
automation framework to write and run your program tests.
Unit testing frameworks provide generic test classes that
you extend to create specific test cases. They can then run
all of the tests that you have implemented and report, often
through some GUI, on the success of otherwise of the
tests.

33

Automated test components

A setup part, where you initialize the system with the test
case, namely the inputs and expected outputs.
A call part, where you call the object or method to be
tested.
An assertion part where you compare the result of the call
with the expected result. If the assertion evaluates to true,
the test has been successful if false, then it has failed.

34

17

Unit test effectiveness

The test cases should show that, when used as expected,
the component that you are testing does what it is
supposed to do.
If there are defects in the component, these should be
revealed by test cases.
This leads to 2 types of unit test case:
The first of these should reflect normal operation of a program and
should show that the component works as expected.
The other kind of test case should be based on testing experience
of where common problems arise. It should use abnormal inputs to
check that these are properly processed and do not crash the
component.
35

Testing strategies
Partition testing, where you identify groups of inputs that
have common characteristics and should be processed in
the same way.
You should choose tests from within each of these groups.

Guideline-based testing, where you use testing guidelines

to choose test cases.
These guidelines reflect previous experience of the kinds of errors
that programmers often make when developing components.

36

18

Partition testing
Input data and output results often fall into different classes
where all members of a class are related.
Each of these classes is an equivalence partition or
domain where the program behaves in an equivalent way
for each class member.
Test cases should be chosen from each partition.

37

Equivalence partitioning

38

19

Equivalence partitions

39

Testing guidelines (sequences)

Test software with sequences which have only a single
value.
Use sequences of different sizes in different tests.
Derive tests so that the first, middle and last elements of
the sequence are accessed.
Test with sequences of zero length.

40

20

General testing guidelines

Choose inputs that force the system to generate all error
messages
Design inputs that cause input buffers to overflow
Repeat the same input or series of inputs numerous times
Force invalid outputs to be generated
Force computation results to be too large or too small.

41

Component (Integration) testing

For testing A before
B,C and D are built,
their behavior must
be simulated through
components with the
same interface, called
stubs.
For testing B,C and D
without A, the calling
environment must be
simulated through
components called
42
drivers.

21

Big bang o integrazione

incrementale
Si parla di test di integrazione big bang quando tutti i
moduli (gi testati separatamente) sono integrati in un
sol colpo
Si parla di test di integrazione incrementale quando i
moduli sono integrati via via che vengono prodotti e
testati singolarmente.

Eventuali anomalie nelle interfacce possono essere rilevate ed

eliminate durante lo sviluppo, e non si propagano sul prodotto
finale
E pi facile localizzare (e quindi rimuovere) eventuali anomalie
Il test incrementale esercita pi a lungo ciascun modulo

43

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.
44

22

Interface testing

45

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

46

23

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.

47

Interface testing guidelines

Design tests so that parameters 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.

48

24

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.

49

System testing
applicato sul sistema software completo
ed integrato
L'obiettivo e' valutare l'adesione del ai
requisiti specificati
Lo esegue il team addetto al testing
(esterno al gruppo di sviluppo)

50

25

System testing
Testing with respect to
Functional requirements
Non functional requirements

System requirements are also

Performance, Reliability, Maintainability,
Usability...

51

Test di
Configurazione: tutti i comandi per
scambiare/cambiare le relazioni fisiche
logiche dei componenti HW
Recovery: capacit di reazione del sistema
a cadute
Stress: affidabilit in condizione di carico
limite
Sicurezza: invulnerabilit del sistema
rispetto ad accessi non autorizzati
52

26

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.

53

Testing policies
Exhaustive system testing is impossible so testing policies
which define the required system test coverage may be
developed.
Examples of testing policies:
All system functions that are accessed through menus should be
tested.
Combinations of functions that are accessed through the same
menu must be tested.
Where user input is provided, all functions must be tested with both
correct and incorrect input.

54

27

Test-driven development
Test-driven development (TDD) is an approach to program
development in which you inter-leave testing and code
development.
Tests are written before code and passing the tests is the
critical driver of development.
You develop code incrementally, along with a test for that
increment. You dont move on to the next increment until
the code that you have developed passes its test.
TDD was introduced as part of Extreme Programming.
However, it can also be used in plan-driven development
processes.
55

Test-driven development

56

28

TDD process activities

Start by identifying the increment of functionality that is
required. This should normally be small and implementable
in a few lines of code.
Write a test for this functionality and implement this as an
automated test.
Run the test, along with all other tests that have been
implemented. Initially, you have not implemented the
functionality so the new test will fail.
Implement the functionality and re-run the test.
Once all tests run successfully, you move on to
implementing the next chunk of functionality.
57

Benefits of test-driven development

Code coverage
Every code segment that you write has at least one associated test
so all code written has at least one test.

Simplified debugging
When a test fails, it should be obvious where the problem lies. The
newly written code needs to be checked and modified.

System documentation
The tests themselves are a form of documentation that describe
what the code should be doing.

58

29

Regression testing
Regression testing is the selective retesting of a
system or component to verify that modifications have
not caused unintended effects...
Regression testing is testing the system to check that
changes have not broken previously working code.
This kind of testing is easy to automatize: the new
program is executed with the old test data and the
results are compared against the old ones stored in a
data base.

59

Requirements based testing

Requirements-based testing involves examining each
requirement and developing a test or tests for it.
MHC-PMS requirements:
If a patient is known to be allergic to any particular medication, then
prescription of that medication shall result in a warning message
being issued to the system user.
If a prescriber chooses to ignore an allergy warning, they shall
provide a reason why this has been ignored.

60

30

Requirements tests
Set up a patient record with no known allergies. Prescribe medication for
allergies that are known to exist. Check that a warning message is not issued
by the system.
Set up a patient record with a known allergy. Prescribe the medication to that
the patient is allergic to, and check that the warning is issued by the system.
Set up a patient record in which allergies to two or more drugs are recorded.
Prescribe both of these drugs separately and check that the correct warning for
each drug is issued.
Prescribe two drugs that the patient is allergic to. Check that two warnings are
correctly issued.
Prescribe a drug that issues a warning and overrule that warning. Check that
the system requires the user to provide information explaining why the warning
was overruled.
61

Specific testing
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 behaviour.
62

31

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 users working
environment have a major effect on the reliability, performance,
usability and robustness of a system. These cannot be replicated in
a testing environment.

63

Types of user testing

Alpha testing
Users of the software work with the development team to test the
software at the developers 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.

64

32

Alpha and beta testing

Before the software is released, it is
sometimes given to a small,
representative set of potential users for
trial use, either in-house (alpha testing)
or external (beta testing).

65

Acceptance testing
Acceptance testing checks the system
behavior against the customers
requirements; the customers undertake,
or specify, typical tasks to check that
their requirements have been met. This
testing activity may or may not involve
the developers of the system.

66

33

The acceptance testing process

67

Stages in the acceptance

testing process
Define acceptance criteria
Plan acceptance testing
Derive acceptance tests
Run acceptance tests
Negotiate test results
Reject/accept system

68

34

Agile methods and acceptance

testing
In agile methods, the user/customer is part of the
development team and is responsible for making decisions
on the acceptability of the system.
Tests are defined by the user/customer and are integrated
with other tests in that they are run automatically when
changes are made.
There is no separate acceptance testing process.
Main problem here is whether or not the embedded user is
typical and can represent the interests of all system
stakeholders.
69

Testing theory
Lecture 12

70

35

Testing theory
Given a test T (T is a subset of D), T
is successful for P if ok(P,T),
otherwise it is called inadequate.
T is called ideal if ok(P,T) ok(P)
One goal of the testing theory is the
definition of methods to choice tests
that approximate the ideal tests.

71

Test selection criteria

A test selection criterium C for a
program P is a set of predicates on D.
Test T is chosen through criterium C if it
satisfies C.
C = {<x1, x2,..., xn> | n 3
i, j, k, ( xi<0 xj=0 xk>0)}
<-5, 0, 22> and <-10, 2, 8, 33, 0, -19> satisfy C
<1, 3, 99> does not satisfiy C
72

36

Raffinamento dei test

Un criterio C1 pi fine di un altro C2
se, per ogni programma P, per ogni test
T1 che soddisfa C1 ne esiste un
sottoinsieme T2 che soddisfa C2.

73

Test selection criteria properties

C is consistent for P, if, for each pair
of tests T1 and T2 chosen by C,
ok(P,T1) ok(P,T2)
C is complete for P if it exists at least
a test T such that ok(P,T1) whenever
ok(P)
A consistent and complete selection
criterium chooses ideal tests.
74

37

Teorema di Goodenough e Gerhart

Il fallimento di un test T per un programma P
selezionato da un criterio C consistente e
completo permette di dedurre la correttezza
del programma P, cio:

consistente(C,P) completo(C,P) selezionato(C,T)

successo(T,P) ok(P)

La consistenza del criterio C garantisce lo

stesso risultato (in termini di rilevamento dei
malfunzionamenti) per tutti i test selezionati.
La completezza di C garantisce che, se P non
corretto, non lo neppure per uno dei test
selezionati da C

75

Particular test selection

criteria

A selection criterium C that includes all

elements of D is complete but not
consistent. Proof?
A selection criterium C that is satisfied
by no element of D is consistent but not
complete.
A selection criterium C satisfied by a
test T=D is consistent and complete
(exhaustive test)
76

38

Proof
If a failure exists, it will occurr for a
input datum d; C chooses at least a test T
containing d and thus T will cause the
failure.
On the other hand, not each test T
satisfying C contains d.

77

Howdens theorem
No algorithm exists for any P able to
define a finite ideal test (no consistent
and complete selection criterium
exists).

78

39

Howdens theorem
Non si dice che il criterio consistente e
completo non esiste (basta prendere il
criterio che seleziona tutti e soli i dati
che causano un malfunzionamento), dice
solo che non effettivo (non pu essere
tradotto in un algoritmo in grado di
produrre il risultato in un tempo finito)
Il teorema di HOWDEN corrisponde alla
tesi di Dijkstra
79

Indecidable problems
Indecidable problems are greatly
influencing testing
A problem is indecidable if it is possible
to prove that no algorithm exists
solving it

80

40

Problemi di decisione

81

Linguaggi computazionalmente
completi
Un linguaggio di programmazione si dice
computazionalmente completo se vi si
possono definire tutte le funzioni
ricorsive oppure tutte le funzioni
calcolabili da una Macchina di Turing

82

41

Tesi di Church-Turing (1936)

Ogni algoritmo che pu essere eseguito da
un umano o da un computer pu essere
eseguito da una macchina di Turing
Per dimostrare che una funzione
calcolabile (la funzione caratteristica di
un insieme, ad esempio), basta scrivere un
algoritmo che la calcoli: la tesi di ChurchTuring ci assicura che pu essere eseguito
da una macchina di Turing
83

Un problema indecidibile se possibile

dimostrare che non esiste una macchina
di Turing che risolve il problema
Es. stabilire se l'esecuzione di un
programma termina a fronte di un input
arbitrario e' un problema indecidibile

84

42

Problema della terminazione

85

86

43

Indecidable problems
It is not possible to decide whether two
programs compute the same function or not

Consequence
Given a program C known correct (the
specification of P?) , we cannot prove
that P is correct through the proof of
the equivalence of P and C

87

Weyukers theorem
For each program P the following are
undecidable problems
at least an input datum exists that
causes the execution of instruction i or
of branch b.
at least an input datum exists that
causes the execution of all instructions of
P or of all branch of P
88

44

Weyukers theorem
Esiste un dato di ingresso che causa una particolare
sequenza di esecuzione di istruzioni?
Esiste un dato di ingresso che causi lesecuzione di
ogni possibile sequenza di istruzioni di un programma?
Questo teorema importante per i metodi di test
che richiedono lesecuzione di particolari elementi del
programma.
Tuttavia, dato un problema indecidibile, possibile
individuare sottoproblemi significativi decidibili, per i
quali possibile formulare algoritmi in grado di
risolvere parzialmente il problema.
Inoltre si possono sempre risolvere problemi
indecidibili in maniera creativa e non meccanica
89

Testing techniques
The main classification is based on how tests
are generated from the software engineers
intuition and experience, the specifications, the
code structure, the (real or artificial) faults to
be discovered, the field usage, or, finally, the
nature of the application.
Sometimes these techniques are classified as
white-box, if the tests rely on information
about how the software has been designed or
coded, or as black-box if the test cases rely
only on the input/output behavior.
90

45

White-box testing
Coverage criteria
Statement coverage
Edge coverage
Condition coverage
Path coverage
Data flow (syntactic dependency)
coverage
91

Black-box testing: three steps

Decompose the system specification in a
set of independent functions.
Identify the relevant values: special
cases, normal cases, wrong cases..
Constraints the possible combinations of
values

92

46

Black-box vs. white-box

93

Testing process
Planning the quality

94

47

Testing and quality

Testing is the analysis and the
controlled execution of a program
with the aim of revealing defects.
Testing is planning, designing,
costruction, maintenance of test and
testing environments

95

The testing process

Testing concepts, strategies, techniques,
and measures need to be integrated into a
defined and controlled process which is
run by people. The test process supports
testing activities and provides guidance
to testing teams, from test planning to
test output evaluation, in such a way as to
provide justified assurance that the test
objectives will be met costeffectively.
96

48

 Thus the testing is a process

This process must produce deliverables.
i.e. documents
IEEE Standard for Software Test
Documentation (Std. 829-1998 Revised
Std. 829-1983).

97

Std IEEE 829

The standard defines 8 types of documents to
be used in 3 distinct phases
Tests design

Test plan
Test design specification
Test case specification
Test procedure
Test item transmittal report

Tests execution

Test log
Test incident report

Tests end

Test summary report

98

49

Test plan
The Test plan is a document describing
the scope, approach, resources, and
schedule of intended testing activities.
It identifies test items, the features
to be tested, the testing tasks, who
will do each task, and any risks
requiring contingency planning.

99

Test plan outline

Test Plan Identifier
A unique identifier

Introduction

Summary of the items and features to be

tested
Need for an history of each item (optional)
References to related documents such as
project authorization, project plan, QA
plan, configuration management plan,
relevant policies, relevant standards
References to lower level test plans
100

50

Test plan outline (cont.)

Test Items
Test items and their version
Characteristics of their transmittal media
References to related documents such as
requirements specification, design
specification, users guide, operations
guide, installation guide
References to bug reports related to test
items
Items which are specifically not going to
101
be tested (optional)

Test plan outline (cont.)

Features to be Tested
All software features and combinations of features
to be tested
References to test-design specifications associated
with each feature and combination of features

Features Not to Be Tested

All features and significant combinations of features
which will not be tested
The reasons these features wont be tested

102

51

Test plan outline (cont.)

Approach

For each major group of features or combinations of

features, specify the approach
Specify major activities, techniques, and tools which are to
be used to test the groups
Specify a minimum degree of comprehensiveness required
Identify which techniques will be used to judge
comprehensiveness
Specify any additional completion criteria
Specify techniques which are to be used to trace
requirements
Identify significant constraints on testing, such as test-item
availability, testing-resource availability, and deadline

103

Test plan outline (cont.)

Item Pass/Fail Criteria
Specify the criteria to be used to determine whether each
test item has passed or failed testing
Suspension Criteria and Resumption Requirements
Specify criteria to be used to suspend the testing activity
Specify testing activities which must be redone when testing
is resumed

Testing Tasks
Identify tasks necessary to prepare for and perform testing
Identify all task interdependencies
Identify any special skills required

104

52

Test plan outline (cont.)

Environmental Needs

Specify necessary and desired properties of the test

environment: physical characteristics of the facilities including
hardware, communications and system software, the mode of
usage (i.e., stand-alone), and any other software or supplies
needed
Specify the level of security required
Identify special test tools needed
Identify any other testing needs
Identify the source for all needs which are not currently
available

Test Items section

Identify groups responsible for providing the environmental

needs identified in the Environmental Needs section
105

Test plan outline (cont.)

Test Deliverables
Identify the deliverable documents: test
plan, test design specifications, test case
specifications, test procedure
specifications, test item transmittal
reports, test logs, test incident reports,
test summary reports
Identify test input and output data
Identify test tools (optional)
106

53

Test plan outline (cont.)

Staffing and Training Needs
Specify staffing needs by skill level
Identify training options for providing necessary skills

Responsibilities
Identify groups responsible for managing, designing, preparing,
executing, witnessing, checking and resolving
Identify groups responsible for providing the test items
identified in the Test Items section
Identify groups responsible for providing the environmental
needs identified in the Environmental Needs section

107

Test plan outline (cont.)

Schedule

Specify test milestones

Specify all item transmittal events
Estimate time required to do each testing task
Schedule all testing tasks and test milestones
For each testing resource, specify its periods of use

Risks and Contingencies

Identify the high-risk assumptions of the test plan

Specify contingency plans for each

Approvals

Specify the names and titles of all persons who must

approve the plan
Provide space for signatures and dates

108

54

Test process documents

109

Hierarchy of planning and

specification documents

110

55

Tracciamento del processo di

testing

111

Tracciamento del processo di

testing
Lo scopo tracciare i progressi nei test e
paragonarli al piano
Test progress S Curve
Asse Y: Test case
Asse X: time (week)
3 informazioni: Attempted, Successful, Planned
Una S Curve rappresenta il fatto che i dati sono
cumulativi nel tempo e la forma di S risulta da un
periodo di intensa attivit di test
112

56

113

114

57

115

Tracciamento del processo di

testing
Sistemi che richiedono alta stabilit: uso
sotto stress (20 ore per giorno)
Utilizzo della CPU
Si traccia il tempo di utilizzo durante il
funzionamento tra release differenti
Associato alla misurazione dei crash non
previsti nelle varie release

116

58

117

118

59

119

120

60

Tracciamento del processo di

testing
Misure dello sforzo
Matrice di celle che confronta
leffettivit del testing (righe) con il
numero di difetti trovati (colonne)

121

122

61

123

Alcuni esempi di processo

124

62

Cleanroom

125

Il processo Cleanroom
Il Cleanroom Software Engineering process
un processo di sviluppo teso a produrre
software con un livello certificabile di
reliability.
Il processo fu sviluppato da Harlan Mills e altri
allIBM nella met degli anni 80.
Cleanroom mira alla prevenzione dei difetti,
piuttosto che alla loro rimozione (il nome
richiama le camere pulite usate nellindustria
elettronica per prevenire lintroduzione di
difetti nella fabbricazione di circuiti integrati).
126

63

Principi base
Lo sviluppo del software basato sulluso di metodi formali.
La verifica che la specifica rispettata dal progetto realizzata
tramite team review.
Limplementazione sviluppata in modo incrementale con un
controllo di qualit statistico.

La qualit di ogni incremento misurata a confronto di standard

prestabiliti per verificare che il processo sta procedendo in modo
accettabile. Un fallimento nel raggiungere uno standard produce
linterruzione del testing per lincremento attuale e il ritorno alla fase
di progetto.
Il testing viene portato avanti come un esperimento statistico. I
comportamenti di input/output selezionati e testati sono poi analizzati
statisticamente per ottenere una stima dellaffidabilit del software e
un livello di confidenza in quella stima.

127

128

64

Extreme programming

129

Extreme programming
Extreme Programming (XP) una
metodologia di tipo agile: cio mette
laccento pi sulladattabilit che sulla
predicibilit.
Successivi cambiamenti dei requisiti sono
visti come naturali durante il progetto,
anzi pi naturali che il tentativo di
definire tutti i requisiti allinizio.
130

65

Scopo
The main aim of XP is to reduce the cost of
change. In traditional system development
methods the cost of changing the requirements
at a later stage will be high.
XP sets out to reduce the cost of change by
introducing basic values, principles and
practices.
By applying XP, a system development project
should be more flexible with respect to
changes.
131

Principi base
XP fornisce un insieme di pratiche che
incoraggiano particolari valori.
I valori sono 5

Communication
Simplicity
Feedback
Courage
Respect (the latest value)
132

66

133

134

67

Basic techniques
Graphs

135

Grafi utilizzati

CFG(P)
Execution tree
CDG(P)
Grafi di dominanza
Grafi di dipendenza
DFD(P)
..
136

68

Flusso del controllo

Il codice rappresentato tramite un
grafo, il grafo del flusso di controllo
(Control flow Graph - CFG), i cui nodi
rappresentano statement (istruzioni e/o
predicati) del programma e gli archi il
passaggio del flusso di controllo.

137

Elementi di base di un CFG

Un grafo costruito secondo la seguente
notazione
Istruzioni=nodo
Passaggio del flusso del controllo=arco
etichettato con {true, false, uncond}

138

69

Definizione di un CFG
Dato un programma P, CFG(P)=<N, AC,
nI,nF>, dove

<N, AC> un grafo con archi etichettati

N= { nI,nF }Ns Np
nI e nF sono il nodo iniziale e il nodo finale
Ns e Np sono insiemi disgiunti di nodi
istruzione e nodi predicato, rispettivamente
AC (N-{nF})x(N-{nI})x{true,false,uncond}
rappresenta la relazione di flusso di controllo
139

Costruzione di un CFG
Un CFG pu essere costruito in modo
strutturato
Si definiscono i sottografi delle varie
strutture di controllo
Si compongono i sottografi

140

70

Strutture di controllo in un CFG

141

142

71

Alcune definizioni

143

Semplificazioni
Un nodo ed il suo successore immediato che
hanno entrambi un solo punto dingresso ed un
solo punto di uscita si possono ridurre ad un solo
nodo nel grafo
La riduzione pu essere applicata n volte
(sequenze di nodi); il nodo risultante pu essere
etichettato con le etichette dei nodi in esso
ridotti
I self-loops possono essere sostituiti da un solo
nodo (loop naturale ha una sola uscita e un solo
ingresso)
144

72

145

Accompagnano i CFG
Il CFG rappresenta la struttura del
programma
Si possono associare ai CFG altri grafi (in
generale alberi) che rappresentano altri
aspetti, anche dinamici, legati
allesecuzione

146

73

Esecuzioni simboliche
In realt i programmi vengono eseguiti in
modo simbolico (o astratto)
Valori simbolici per le variabili si
propagano lungo i cammini di esecuzione
Gli statement si considerano eseguibili
solo se gli input soddisfano determinate
condizioni
Come si caratterizzano queste condizioni?
147

Path conditions
Una Path Condition (pc), per un determinato statement,
indica le condizioni che gli input devono soddisfare
affinch unesecuzione percorra un cammino lungo cui lo
statement sia eseguito.
Una pc unespressione Booleana sugli input simbolici di
un programma; allinizio dellesecuzione simbolica essa
assume il valore vero (pc:= true ).
Per ogni condizione che si incontrer lungo lesecuzione,
pc assumer differenti valori a seconda dei differenti
casi relativi ai diversi cammini dellesecuzione.

148

74

Evoluzione di una pc

149

Esempio

150

75

CFG con accompagnamento di ET

151

Execution tree
Ogni foglia dello execution tree rappresenta
un cammino percorso per classi di valori di
input (pc associata)
Le pc associate a due differenti foglie sono
distinte
Non esistono esecuzioni per cui sono vere
contemporaneamente pi pc (per linguaggi di
programmazione sequenziali).
Se loutput ad ogni foglia corretto allora il
programma corretto.
152

76

Cammini eseguibili
'cammino eseguibile un cammino per il
quale esiste un insieme di dati di
ingresso che soddisfa la path condition
'cammino non eseguibile' ( 'infeasible
path') un cammino per il quale non
esiste un insieme di dati di ingresso che
soddisfa la path condition

153

Call-Direct-Graph CDG(P)

154

77

Esempio

155

Propriet dei nodi

Dato un grafo, CFG o CDG o.., si possono
stabilire alcune propriet dei nodi che
risultano interessanti dal punto di vista
del comportamento del programma
Le propriet valgono per grafi aciclici, ma
sempre possibile eliminare i cicli interni
di un grafo

156

78

Relazione di dominanza

157

Dominatori

158

79

Dominatori

159

Esempio

160

80

Dominanza diretta

161

Albero delle dominanze

162

81

Albero delle dominanze per un CDG

163

Postdominanza
Dato un grafo CFG(P) = <N, AC, nI, nF>, e
due nodi n, m N: m postdomina n se e
solo se per ogni cammino in CFG(P) del
tipo n=p0, p1,..., pk=nF, m{p1,..., pk}
La relazione di postdominanza transitiva
e non riflessiva

164

82

Postdominatori

165

Postdominatori

166

83

Esempio

167

Postdominanza diretta

168

84

Albero delle postdominanze

169

Dipendenze sul controllo

Dato CFG(P) = <N, AC, nI, nF>, e due
nodi x, yN, y si dice dipendente sul
controllo da x se e solo se:
esiste un cammino x=p0, p1,..., pk=y tale
che i,
1 i k-1, pi postdominato da y;
x non postdominato da y.

170

85

In pratica

171

Dipendenze unitarie sul controllo

172

86

In pratica

173

Esempio

174

87

CD Graph
Le dipendenze sul controllo possono
essere espresse mediante apposito
grafo.
Ogni arco del grafo etichettato con
vero, falso o incond indicando una
dipendenza sul controllo per valore di un
predicato uguale a vero o falso, oppure
per ogni valore, rispettivamente.
175

Regioni
Affinch ogni nodo predicato abbia al pi due
archi uscenti (luno etichettato con vero e
laltro con falso), ulteriori nodi, chiamati nodi
regione, vengono inseriti nel grafo.
I nodi regione riassumono linsieme delle
dipendenze sul controllo per ogni predicato.
Gli archi uscenti da un nodo regione sono
etichettati con incond.

176

88

CD Graph

177

Esempio

178

89

Propriet

179

DF Graph
Al grafo del controllo viene associata una
relazione che descrive il flusso dei dati e che
rappresentata levoluzione del valore delle
variabili in base alle operazioni eseguite sulla
variabile stessa in ogni istruzione:

definizione: alla variabile assegnato un valore

uso: il valore della variabile usato in unespressione
o un predicato
annullamento: al termine di unistruzione il valore
associato alla variabile non pi significativo

Es. nellespressione a:=b+c la variabile a

definita mentre b e c sono usate

180

90

Esempio

181

Relazione DEF_USO

182

91

Variabili live
Definizione: la variabile x live al nodo v
se esiste un cammino nel CFG da v a n tale
che x non ridefinito in tale cammino, e n
usa x.
Propriet: la relazione lvx non riflessiva
n transitiva.

183

Esempio

184

92

Testing strutturale

185

Tecniche di testing strutturale

Tecniche in generale fondate sull'adozione di
metodi di copertura degli oggetti che
compongono la struttura dei programmi
COPERTURA: definizione di un insieme di casi di
test ( in particolare dati di input) in modo tale
che gli oggetti di una definita classe (es.
strutture di controllo, istruzioni, archi del CFG,
predicati,..etc.) siano attivati almeno una volta
nell'esecuzione dei casi di test
186

93

Criteri di copertura basati sul

flusso del controllo

Statement coverage
Edge coverage
Condition coverage
Path coverage
Data flow (syntactic dependency)
coverage

187

188

94

189

190

95

 Il caso di test sufficiente per garantire

la copertura delle istruzioni?
Quali possibili fault non rivela?
Fault nel trattamento di valori positivi di A[i]

191

192

96

193

194

97

 Il caso di test usato in precedenza copre tutti

rami del grafo?
No. Non viene coperto larco corrispondente al caso
false dellistruzione if

E se aggiungo il caso (N=1, A[0]=7, X=9)?

Posso scoprire eventuali fault per valori positivi di
A[i].

Quali fault sicuramente non riveler?

Fault in uscita dal loop per la condizione A[i] X

195

Copertura delle condizioni

Dato un programma P, viene definito un
insieme di casi di test tale che tutti i
possibili valori delle componenti di
condizioni composte sono provati almeno
una volta.
La copertura di tutte le condizioni NON
implica la copertura di tutte le decisioni

196

98

197

198

99

 Copro tutte le condizioni?

No

Quali casi devo aggiungere?

Entrambe le condizioni (i<N), (A[i]<X) devono essere
false e vere in differenti test.
Devo aggiungere un test i cui dati causino luscita dal
loop per un valore pi grande di X

Quali fault eventualmente non scoprir?

Fault che si verificano dopo diverse iterazioni del
loop.
199

Copertura di condizioni multiple

Dato un programma P, viene definito un
insieme di casi di test la cui esecuzione
implica l'esecuzione, per ogni decisione, di
tutte le combinazioni di condizioni
La copertura di tutte le combinazioni di
condizioni implica la copertura di tutte le
condizioni e di tutte le decisioni
200

100

201

N-copertura dei cicli

Un test T soddisfa il criterio di ncopertura dei cicli se e solo se ogni
cammino contenente un numero intero di
iterazioni di ogni ciclo non superiore ad n
eseguito per almeno un caso di test T
Problema: stabilire il numero ottimale di
iterazioni....
202

101

Copertura dei cammini

DEVE ESSERE ATTIVATO OGNI CAMMINO
DEL GRAFO
I problema: il numero dei cammino ,
generalmente, infinito
II problema: infeasible path
Soluzione: selezione in base a condizioni di un
numero finito ed eseguibile di cammini:
metodi fondati sui grafi di controllo
metodi data flow

( naturalmente un buon testatore cerca anche

le ragioni della presenza di infeasible path )
203

Metodi basati sui CFG

Linsieme (o un sottoinsieme definito) dei
cammini di un CFG viene partizionato in un
numero finito di classi di equivalenza
Metodo dei cammini esemplari
Metodo dei cammini linearmente indipendenti
(McCabe)

Criterio di copertura: un insieme di casi di test

che assicuri lattraversamento almeno una volta
di almeno un cammino per ogni classe.
204

102

Cammini esemplari
Un cammino privo di circuiti detto cammino
elementare
Il numero di cammini elementari in un grafo finito

Si considerano i cammini elementari e totali di

CFG(P)
Classi di cammini: un cammino elementare totale
e tutti i cammini che da esso differiscono
unicamente per il numero di attraversamenti di
circuiti che sul cammino giacciono
205

206

103

Cammini linearmente indipendenti

Un cammino si dice linearmente
indipendente se introduce almeno un
nuovo inseme di istruzioni o una nuova
condizione; in un CFG un cammino l.
indipendente se attraversa almeno un arco
non ancora percorso (teoria dei grafi)

207

Cammini linearmente indipendenti

Il numero dei cammini linearmente indipendenti di un
programma pari al numero ciclomatico di McCabe
(metrica del SW basata sullanalisi della complessit del
flusso di controllo):
V(G) = E - N +2
E: n.ro di archi in G
N: n.ro di nodi in G

V(G) = P + 1

P: n.ro di predicati in G

V(G) = n.ro di regioni chiuse in G + 1

Test case esercitanti questi cammini garantiscono
lesecuzione di ciascuna istruzione almeno una volta
208

104

209

210

105

211

212

106

213

107