L7.ppt [modalità compatibilità] -...
Transcript of L7.ppt [modalità compatibilità] -...
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