Verificare Si Validare Software

– aparat medical pentru terapie cu radia¸tie

– 6 accidente cu mor¸ti ¸si r˘ani grave (1985-87, SUA, Canada)

– cauza direct˘a: erori in programul de control

– aparat medical pentru terapie cu radia¸tie

– 6 accidente cu mor¸ti ¸si r˘ani grave (1985-87, SUA, Canada)

– cauza direct˘a: erori in programul de control

Analiz˘a retrospectiv˘a [Leveson 1995]:

ˆıncredere excesiv˘a ˆın software (ˆın analiza produsului)

fiabilitate = siguran¸t˘a

lipsa m˘asurilor de siguran¸t˘a hardware

lipsa practicilor de ingineria program˘arii (proiectare defensiv˘a, specificare, documenta¸tie, simplitate, analiz˘a formal˘a, testare) corectarea unei erori nu face sistemul mai sigur !!

– Autodistrugere dup˘a o defec¸tiune la 40 s de la lansare (1996)

– Cauza: conversia 64-bit float → 16-bit int genereaz˘a o excep¸tie de dep˘a¸sire netratat˘a ˆın programul ADA

– Cost: 500 milioane dolari (racheta), 7 miliarde dolari (proiectul)

– Autodistrugere dup˘a o defec¸tiune la 40 s de la lansare (1996)

– Cauza: conversia 64-bit float → 16-bit int genereaz˘a o excep¸tie de dep˘a¸sire netratat˘a ˆın programul ADA

– Cost: 500 milioane dolari (racheta), 7 miliarde dolari (proiectul)

Analiz˘a retrospectiv˘a

principala cauz˘a: reutilizarea nejudicioas˘a de software

cod preluat de la Ariane 4, f˘ar˘a reanalizare corespunz˘atoare:

– execu¸tia nu mai era necesar˘a in timpul erorii

– analiza absen¸tei dep˘a¸sirii pentru variabilele neprotejate

⇒ necesitatea specific˘arii ¸si respect˘arii unei interfe¸te

proiectarea gre¸sit˘a a redundan¸tei: sistemul de referin¸t˘a iner¸tial ¸si cel de rezerv˘a scoase din func¸tiune de aceea¸si eroare

Eroare ˆın unitatea de ˆımp˘a¸tire cu virgul˘a mobil˘a, 1994 algoritm de ˆımp˘ar¸tire cu refacere, ˆın baza 4

determin˘a urm˘atoarea cifr˘a din cˆat dintr-un tabel cˆateva intr˘ari marcate gre¸sit ca ”don’t care”

cost: cca. 500 milioane dolari

Eroare ˆın unitatea de ˆımp˘a¸tire cu virgul˘a mobil˘a, 1994 algoritm de ˆımp˘ar¸tire cu refacere, ˆın baza 4

determin˘a urm˘atoarea cifr˘a din cˆat dintr-un tabel cˆateva intr˘ari marcate gre¸sit ca ”don’t care”

cost: cca. 500 milioane dolari

Analiz˘a retrospectiv˘a

Circuitul putea fi verificat formal

– demonstrare automat˘a de teoreme

– cu structuri speciale de date pentru reprezentarea ˆınmul¸tirii /ˆımp˘ar¸tirii dar accentul a fost pus pe componente mai complexe

(unitatea de execu¸tie, coeren¸ta memoriei cache)

Mars Pathfinder, 1997

ajuns˘a pe Marte, proba spa¸tial˘a se reseta frecvent

cauza: inversiune de prioritate ˆıntre procese cu resurse comune fenomenul ¸si solu¸tia: cunoscute ˆın literatura de specialitate ! [Sha, Rajkumar, Lehoczky. Priority Inheritance Protocols, 1990]

1. procesul A de prioritate mic˘a ob¸tine resursa R

2. A ˆıntrerupt de C (prioritate mare)

3. C a¸steapt˘a eliberarea lui R; A revine ˆın execu¸tie

4. A ˆıntrerupt de B (prioritate medie, A < B < C)

⇒ C a¸steapt˘a dup˘a B, de¸si nu depinde de el ¸si are prioritate mai mare! Solu¸tia: ridicarea priorit˘a¸tii unui proces care ob¸tine o resurs˘a (A)

la nivelul celui mai prioritar proces care poate solicita resursa (C)

Mars Climate Orbiter, 1998 dezintegrare la intrarea ˆın atmosfer˘a

eroarea tehnic˘a: discrepan¸ta ˆıntre unit˘a¸ti de m˘asur˘a ˆın sistemele anglo-american ¸si metric

erori multiple de proces: lipsa unor interfe¸te formale

Mars Polar Lander, 1998

trenul de aterizare e activat prematur la intrarea ˆın atmosfer˘a

¸socul e interpretat ca aterizare, motoarele sunt oprite eroarea: lipsa test˘arii de integrare

Erorile sunt multe, ¸si consecin¸tele foarte grave

Citi¸ti:

Forum on Risks to the Public in Computers and Related Systems http://catless.ncl.ac.uk/Risks

Software Engineering Institute – Capability Maturity Model Integration:

Verificarea asigur˘a c˘a produsul e construit ˆın concordan¸t˘a cu cerin¸tele, specifica¸tiile ¸si standardele.

Sunt ˆındeplinite cerin¸tele specificate ? Produsul e construit corect (cum trebuie) ? (are we building the product right?)

Validarea asigur˘a a produsul va fi utilizabil pe pia¸t˘a.

Produsul acoper˘a nevoile opera¸tionale ?

Produsul poate fi utilizat ˆın mediul inten¸tionat ? Se construie¸ste produsul care trebuie ?

(are we building the right product?)

NASA Software Assurance Guidebook and Standard:

V&V: Procesul de a asigura c˘a produsul software:

– va satisface cerin¸tele (func¸tionale ¸si altele) – validare

– ¸si fiecare pas ˆın construirea sa rezult˘a un produs corect – verificare

“Diferen¸ta dintre verificare ¸si validare e important˘a doar pentru teoretician; practicienii folosesc V&V referindu-se la toate activit˘a¸tile care asigur˘a c˘a software-ul va func¸tiona conform cerin¸telor”.

Tehnologii

– inspec¸tie

review (analiz˘a de c˘atre un ter¸t)

inspection (ca mai sus, dar cu proces si roluri riguros definite)

walkthroughs (prezentare solicitˆand opinii)

– testare

– analiz˘a ¸si verificare formal˘a

Proces

– faza de conceptie: stabilirea planului de testare

– analiza cerin¸telor: scenarii de test pe baza celor de utilizare

– design: verificarea modelulul ˆın raport cu specificarea

– implementare: inspec¸tie + testare la nivel de modul

– integrare: testare de integrare, rapoarte de test

“Testarea e procesul prin care se execut˘a un program cu inten¸tia de a g˘asi erori” (Myers, The Art of Software Testing).

“Testarea e procesul prin care se execut˘a un program cu inten¸tia de a g˘asi erori” (Myers, The Art of Software Testing).

Aparent la fel, dar de fapt invers (¸si fals)

– “Testarea e procesul de a demonstra c˘a programul nu are erori”. (imposibil doar prin testare)

Dijkstra: “Testing can be used very effectively to show the presence of bugs but never to show their absence.”

⇒ un test de succes e acela care descoper˘a (¸si localizeaz˘a) o eroare.

Rolul unui testor e s˘a g˘aseasc˘a erori

– cˆat mai devreme cu putin¸t˘a

(costul corect˘arii cre¸ste odat˘a cu timpul)

– ¸si s˘a asigure corectarea lor

(rapoarte, depanare, mentenan¸t˘a) (Patton, Software Testing)

Cauza / sursa erorilor

– cele mai multe, cauzate de deficien¸te ˆın specifica¸tie

– apoi cele originˆand ˆın faza de proiectare

– doar relativ pu¸tine (uneori sub 15%) erori directe de programare

Costul erorilor

cre¸ste, chiar exponen¸tial, avansˆand ˆın procesul de produc¸tie

O($1) la specificare, O($1000+) dup˘a livrare

Dinamica erorilor ˆın software [dup˘a John Rushby, SRI]

20-50 erori/kloc ˆınainte de testare, 2-4 dup˘a

examinarea formal˘a a codului: 10x reducere de erori ˆınainte de testare

Dinamica erorilor ˆın software [dup˘a John Rushby, SRI]

20-50 erori/kloc ˆınainte de testare, 2-4 dup˘a

examinarea formal˘a a codului: 10x reducere de erori ˆınainte de testare

Studiu de caz pe 10kloc timp real, distribuit:

verificare ¸si validare: 52% cost (57% timp)

din acesta, 27% cost ˆın examinare, 73% ˆın testare

21% pt. 4 defecte ˆın testarea finala, din care 1 de proiectare

eliminarea prin examinarea codului: 160x mai eficient˘a decˆat la testare

Dinamica erorilor ˆın software [dup˘a John Rushby, SRI]

20-50 erori/kloc ˆınainte de testare, 2-4 dup˘a

examinarea formal˘a a codului: 10x reducere de erori ˆınainte de testare

Studiu de caz pe 10kloc timp real, distribuit:

verificare ¸si validare: 52% cost (57% timp)

din acesta, 27% cost ˆın examinare, 73% ˆın testare

21% pt. 4 defecte ˆın testarea finala, din care 1 de proiectare

eliminarea prin examinarea codului: 160x mai eficient˘a decˆat la testare

Studiu dup˘a NASA JPL (sondele Voyager, Galileo)

majoritatea: deficien¸te ˆın specificarea cerin¸telor ¸si a interfe¸telor

1 eroare la 3 pagini de cerin¸te ¸si 21 pagini de cod doar 3 din 197 erau erori de programare

2/3 din erorile func¸tionale: omisiuni ˆın specificarea cerin¸telor majoritatea erorilor de interfa¸t˘a: datorate proastei comunic˘ari

What Makes a Good Software Tester (Patton)

They are explorers.

They are troubleshooters

They are relentless

They are creative

They are (mellowed) perfectionists

They exercise good judgment

They are tactful and diplomatic (?) They are persuasive (!)

Un caz de test trebuie s˘a defineasc˘a ie¸sirea sau rezultatul dorit.

– pare evident dar … daca nu, vom vedea ceea ce dorim s˘a vedem

Un programator ar trebui s˘a evite s˘a-¸si testeze propriul program.

– psihologic, nu dore¸ste s˘a g˘aseasc˘a erori

– excep¸tie: dezvoltarea simultan˘a cu testarea unitar˘a (TDD)

Corolar: grupul de testori ar trebui s˘a fie altul decˆat cel de dezvoltare

Sunt necesare cazuri de test pentru condi¸tii de intrare valide ¸si invalide. Trebuie testat c˘a produsul face ce trebuie ¸si nu face ce nu trebuie !

P˘astra¸ti ¸si refolosi¸ti cazurile de test!

Nu planifica¸ti procesul de testare presupunˆand c˘a nu vor fi g˘asite erori! Probabilitatea de a g˘asi erori ˆıntr-un fragment de cod e propor¸tional˘a cu

num˘arul de erori deja g˘asite.

Testarea software e un exerci¸tiu de apreciere a riscurilor

Cu cˆat mai multe erori g˘ase¸sti, cu atˆat mai multe sunt

Paradoxul pesticidelor (Beizer): erorile devin reziliente la teste

(pentru a g˘asi erori noi e nevoie de teste noi) Nu toate erorile g˘asite vor fi corectate

E greu de spus cˆand o eroare e o eroare … Specifica¸tiile produselor nu sunt niciodat˘a definitive

Testorii nu sunt cei mai populari membri ai echipei de proiect 🙂 Testarea de software e o profesie tehnic˘a guvernat˘a de o disciplin˘a

Disciplina test˘arii: organizare ¸si metrici

Exemplu de raport succint de testare

(Marnie Hutcheson, Software Testing Fundamentals)

“As per our agreement, we have tested 67 percent of the test inventory […] the most important tests in the inventory as determined by our joint risk analysis.

The bug find rates and the severity composition of the bugs we found were within the expected range. Our bug fix rate is 85 percent.

It has been three weeks since we found a Severity 1 issue. There are currently no known Severity 1 issues open. Fixes for the last Severity 2 issues were regression-tested and approved a week ago. Overall, the system seems to be stable.

The load testing has been concluded. The system failed at 90 percent of the design load. The system engineers […] will need 3 months to implement the fix.

Our recommendation is to ship on schedule, with the understanding that we have an exposure if the system utilization exceeds the projections before we have a chance to install the previously noted fix.”

[Cem Kaner, Black-box software testing course, Florida Inst. of Tech]

Ce test˘am ? Ce vrem s˘a afl˘am din asta ?

Care e misiunea test˘arii ?

Cum organiz˘am lucrul pentru a ˆındeplini misiunea ?

Problema strategiei test˘arii

Cˆand am testat destul ?

Problema m˘asur˘arii ˆın testare

“o investiga¸tie tehnic˘a a produsului de testat efectuat˘a pentru a oferi persoanelor implicate informa¸tie legat˘a de calitate” [Kaner]

investiga¸tie: c˘autare activ˘a, organizat˘a de informa¸tii tehnic˘a: experimente, logic˘a, modele, algoritmi, unelte produsul testat: ce prime¸ste clientul, ˆın totalitate

(software, hardware, baze de date, documenta¸tie, etc.)

persoane implicate: ˆın succesul produsului, ¸si al test˘arii

[ Kaner 2003 – What is a good test case ? ]

– g˘asirea de defecte: mai ales ˆın p˘ar¸tile “interesante” (acoperire bun˘a)

– g˘asirea cˆat mai multor defecte: ˆın timp limitat

– oprirea livr˘arii premature / suport pentru decizie: livrare sau nu

– minimizarea costului de suport tehnic

– evaluarea conforman¸tei la specifica¸tii / reguli / standarde

– minimizarea riscurilor de accidente (¸si costurilor legale …)

– g˘asirea de scenarii de utilizare sigur˘a (func¸tionare corect˘a)

– evaluarea calit˘a¸tii produsului (dar nu doar prin testare)

Ce nu poate face testarea ?

– verificarea produsului (absen¸ta de erori)

– asigurarea calit˘a¸tii produsului (problem˘a de proces)

puternic: ¸sans˘a mare de a descoperi o anumit˘a eroare dac˘a exist˘a conving˘ator (problem˘a important˘a) ¸si credibil (e realist s˘a apar˘a) reprezentativ / probabil pentru client

u¸sor de evaluat (e o eroare sau nu?) / u¸sor de depanat / informativ de complexitate potrivit˘a (progresiv˘a)

relevant privind func¸tionarea / performan¸ta produsului

(de ex. detecteaz˘a modific˘ari ˆın comportament / performan¸t˘a)

Cˆateva utilitare de ˆıncercat

Klee http://klee.llvm.org/

testare C/C++ prin execu¸tie simbolic˘a

Pex http://research.microsoft.com/en-us/projects/Pex/

testare C# prin execu¸tie simbolic˘a

CHESS testarea programelor concurente

http://research.microsoft.com/en-us/projects/CHESS/

RoadRunner analiz˘a dinamic˘a pentru programe Java concurente

http://www.cs.williams.edu/~freund/rr/

Java Pathfinder http://babelfish.arc.nasa.gov/trac/jpf

model checking ¸si testare / execu¸tie simbolic˘a

Randoop http://people.csail.mit.edu/cpacheco/randoop/

testare prin generare aleatoare + feedback, pentru Java

Blast (verificator pentru C), CREST (execu¸tie concret˘a + simbolic˘a), Daikon (generare de invarian¸ti), FramaC, ESCJava2 (analiz˘a static˘a) …