1

11 1

Corso di Laurea Magistralein

Ingegneria Informatica

Module B-Software Systems Engineeringa.a. 2012-2013

Gigliola Vaglini

2

Software Testing

Lecture 11

2

3

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.

4

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

3

5

V & V confidence Aim of V & V is to establish confidence that the system is

‘fit for purpose’.

Depends on system’s 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.

6

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

4

7

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

8

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

5

9

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

10

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.

6

11

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.

12

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.

7

13

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.

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.

14

An input-output model of program testing

The system is executed with test data and its operational behaviour is observed.

8

15

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.

Inspections and testing

16

Inspections and testing

9

17

Advantages of inspections During testing, errors can mask (hide) other errors.

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

18

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.

10

19

A model of the software testing process

20

La verifica nell’ingegneria 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

11

21

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

22

Tesi di Dijkstra Program testing can be used to show the

presence of bugs, but never to show their absence (Dijkstra’s 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

12

23

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.

24

13

25

Come trattare i risultati dell’analisi

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

26

Proprietà dei risultati dell’analisi

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

che ha una certa proprietà

14

27

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.

28

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

un’uscita attesa– Una statechart è una macchina a stati finiti che

descrive tutti i comportamenti ammissibili

15

29

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.

30

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.

16

31

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.

32

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.

17

33

Automated testingWhenever 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.

34

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.

18

35

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.

36

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.

19

37

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.

38

Equivalence partitioning

20

39

Equivalence partitions

40

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.

21

41

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.

42

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

22

43

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

44

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.

23

45

Interface testing

46

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

24

47

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.

48

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.

25

49

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.

50

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)

26

51

System testing

Testing with respect to– Functional requirements– Non functional requirements

System requirements are also Performance, Reliability, Maintainability, Usability...

52

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

27

53

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.

54

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.

28

55

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 don’t 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.

56

Test-driven development

29

57

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.

58

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.

30

59

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.

60

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.

31

61

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.

62

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.

32

63

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.

64

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.

33

65

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

66

Acceptance testing

Acceptance testing checks the system behavior against the customer’s 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.

34

67

The acceptance testing process

68

Stages in the acceptance testing process

Define acceptance criteria

Plan acceptance testing

Derive acceptance tests

Run acceptance tests

Negotiate test results

Reject/accept system

35

69

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.

70

Testing theory

Lecture 12

36

71

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.

72

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

37

73

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.

74

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.

38

75

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

76

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)

39

77

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.

78

Howden’s theorem

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

40

79

Howden’s 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

80

Indecidable problems

Indecidable problems are greatly influencing testing

A problem is indecidable if it is possible to prove that no algorithm exists solving it

41

81

Problemi di decisione

82

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

42

83

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 Church-Turing ci assicura che può essere eseguito da una macchina di Turing

84

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

43

85

Problema della terminazione

86

44

87

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

88

Weyuker’s 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”

45

89

Weyuker’s theorem Esiste un dato di ingresso che causa una particolare

sequenza di esecuzione di istruzioni? Esiste un dato di ingresso che causi l’esecuzione di

ogni possibile sequenza di istruzioni di un programma? Questo teorema è importante per i metodi di test

che richiedono l’esecuzione 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

90

Testing techniques The main classification is based on how tests

are generated from the software engineer’s 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.

46

91

White-box testing

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

coverage

92

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

47

93

Black-box vs. white-box

94

Testing process

Planning the quality

48

95

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

96

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.

49

97

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

98

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

50

99

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

100

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

51

101

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 be tested (optional)

102

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 won’t be tested

52

103

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

104

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

53

105

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

106

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)

54

107

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

108

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

55

109

Test process documents

110

Hierarchy of planning and specification documents

56

111

Tracciamento del processo di testing

112

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

57

113

114

58

115

116

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

59

117

118

60

119

120

61

121

Tracciamento del processo di testing

Misure dello sforzo

Matrice di celle che confronta l’effettività del testing (righe) con il numero di difetti trovati (colonne)

122

62

123

124

Alcuni esempi di processo

63

125

Cleanroom

126

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 all’IBM nella metà degli anni ‘80.

Cleanroom mira alla prevenzione dei difetti, piuttosto che alla loro rimozione (il nome richiama le camere pulite usate nell’industria elettronica per prevenire l’introduzione di difetti nella fabbricazione di circuiti integrati).

64

127

Principi base Lo sviluppo del software è basato sull’uso di metodi formali. La verifica che la specifica è rispettata dal progetto è realizzata

tramite “team review”. L’implementazione è 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 l’interruzione del testing per l’incremento 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 dell’affidabilità del software e un livello di confidenza in quella stima.

128

65

129

Extreme programming

130

Extreme programming

Extreme Programming (XP) è una metodologia di tipo “agile”: cioè mette l’accento più sull’adattabilità 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 all’inizio.

66

131

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.

132

Principi base

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

– Communication– Simplicity– Feedback– Courage– Respect (the latest value)

67

133

134

68

135

Basic techniques

Graphs

136

Grafi utilizzati

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

69

137

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.

138

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}

70

139

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

140

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

71

141

Strutture di controllo in un CFG

142

72

143

Alcune definizioni

144

Semplificazioni Un nodo ed il suo successore immediato che

hanno entrambi un solo punto d’ingresso 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)

73

145

146

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 all’esecuzione

74

147

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?

148

Path conditions Una Path Condition (pc), per un determinato statement,

indica le condizioni che gli input devono soddisfare affinché un’esecuzione percorra un cammino lungo cui lo statement sia eseguito.

Una pc è un’espressione Booleana sugli input simbolici di un programma; all’inizio dell’esecuzione simbolica essa assume il valore vero (pc:= true ).

Per ogni condizione che si incontrerà lungo l’esecuzione, pc assumerà differenti valori a seconda dei differenti casi relativi ai diversi cammini dell’esecuzione.

75

149

Evoluzione di una pc

150

Esempio

76

151

CFG con accompagnamento di ET

152

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 l’output ad ogni foglia è corretto allora il programma è corretto.

77

153

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

154

Call-Direct-Graph CDG(P)

78

155

Esempio

156

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

79

157

Relazione di dominanza

158

Dominatori

80

159

Dominatori

160

Esempio

81

161

Dominanza diretta

162

Albero delle dominanze

82

163

Albero delle dominanze per un CDG

164

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

83

165

Postdominatori

166

Postdominatori

84

167

Esempio

168

Postdominanza diretta

85

169

Albero delle postdominanze

170

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.

86

171

In pratica

172

Dipendenze unitarie sul controllo

87

173

In pratica

174

Esempio

88

175

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.

176

Regioni Affinchè ogni nodo predicato abbia al più due

archi uscenti (l’uno etichettato con vero e l’altro con falso), ulteriori nodi, chiamati nodi regione, vengono inseriti nel grafo.

I nodi regione riassumono l’insieme delle dipendenze sul controllo per ogni predicato.

Gli archi uscenti da un nodo regione sono etichettati con incond.

89

177

CD Graph

178

Esempio

90

179

Proprietà

180

DF Graph Al grafo del controllo viene associata una

relazione che descrive il flusso dei dati e che rappresentata l’evoluzione 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 un’espressione

o un predicato– annullamento: al termine di un’istruzione il valore

associato alla variabile non è più significativo Es. nell’espressione a:=b+c la variabile a è

definita mentre b e c sono usate

91

181

Esempio

182

Relazione DEF_USO

92

183

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.

184

Esempio

93

185

Testing strutturale

186

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

94

187

Criteri di copertura basati sul flusso del controllo

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

coverage

188

95

189

190

96

191

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]

192

97

193

194

98

195

Il caso di test usato in precedenza copre tutti rami del grafo?– No. Non viene coperto l’arco corrispondente al caso

false dell’istruzione 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

196

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

99

197

198

100

199

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 l’uscita dal

loop per un valore più grande di X Quali fault eventualmente non scoprirò?

– Fault che si verificano dopo diverse iterazioni del loop.

200

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

101

201

202

N-copertura dei cicli

Un test T soddisfa il criterio di n-copertura 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....

102

203

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 …)

204

Metodi basati sui CFG L’insieme (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 l’attraversamento almeno una volta di almeno un cammino per ogni classe.

103

205

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

206

104

207

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)

208

Cammini linearmente indipendenti

Il numero dei cammini linearmente indipendenti di un programma è pari al numero ciclomatico di McCabe (metrica del SW basata sull’analisi 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

l’esecuzione di ciascuna istruzione almeno una volta

105

209

210

106

211

212

107

213