Vericare si validare software.

Introducere
Marius Minea 26 septembrie 2013

Tehnici ce vor discutate

Testare black-box (f ar a acces la surs a) Testare white-box/glass-box (cu acces la surs a) Generarea de teste la nivel de modul Metrici de acoperire cu teste Analiz a static a a codului surs a Analiz a dinamic a si prolare Testarea programelor orientate pe obiecte Testarea programelor concurente Vericare (formal a) a modelelor Generarea automat a de teste bazat a pe specicat ie / model Testarea securit a tii software Conceperea unui plan de test

Erori au fost, erori sunt nc a ...

Erori grave: Therac-25

- aparat medical pentru terapie cu radiat ie - 6 accidente cu mort i si r ani grave (1985-87, SUA, Canada) - cauza direct a: erori in programul de control

Erori grave: Therac-25

- aparat medical pentru terapie cu radiat ie - 6 accidente cu mort i 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) abilitate = sigurant a lipsa m asurilor de sigurant a hardware lipsa practicilor de ingineria program arii (proiectare defensiv a, specicare, documentat ie, simplitate, analiz a formal a, testare) corectarea unei erori nu face sistemul mai sigur !!

Erori: racheta Ariane 5

- Autodistrugere dup a o defect iune la 40 s de la lansare (1996) - Cauza: conversia 64-bit oat 16-bit int genereaz a o except ie de dep a sire netratat a n programul ADA - Cost: 500 milioane dolari (racheta), 7 miliarde dolari (proiectul)

Erori: racheta Ariane 5

- Autodistrugere dup a o defect iune la 40 s de la lansare (1996) - Cauza: conversia 64-bit oat 16-bit int genereaz a o except ie 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: - execut ia nu mai era necesar a in timpul erorii - analiza absent ei dep a sirii pentru variabilele neprotejate necesitatea specic arii si respect arii unei interfet e proiectarea gre sit a a redundant ei: sistemul de referint a inert ial si cel de rezerv a scoase din funct iune de aceea si eroare

Eroarea din procesorul Pentium

Eroare n unitatea de mp a tire cu virgul a mobil a, 1994 algoritm de mp art ire 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 dont care cost: cca. 500 milioane dolari

Eroarea din procesorul Pentium

Eroare n unitatea de mp a tire cu virgul a mobil a, 1994 algoritm de mp art ire 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 dont care cost: cca. 500 milioane dolari Analiz a retrospectiv a Circuitul putea vericat formal - demonstrare automat a de teoreme - cu structuri speciale de date pentru reprezentarea nmult irii / mp art irii dar accentul a fost pus pe componente mai complexe (unitatea de execut ie, coerent a memoriei cache)

Erori: probele trimise pe Marte

Mars Pathnder, 1997 ajuns a pe Marte, proba spat ial a se reseta frecvent cauza: inversiune de prioritate ntre procese cu resurse comune fenomenul si solut ia: cunoscute n literatura de specialitate !
[Sha, Rajkumar, Lehoczky. Priority Inheritance Protocols, 1990]

1. procesul A de prioritate mic a obt ine resursa R 2. A ntrerupt de C (prioritate mare) 3. C a steapt a eliberarea lui R; A revine n execut ie 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! Solut ia: ridicarea priorit a tii unui proces care obt ine o resurs a (A) la nivelul celui mai prioritar proces care poate solicita resursa (C)

Erori: probele trimise pe Marte

Mars Climate Orbiter, 1998 dezintegrare la intrarea n atmosfer a eroarea tehnic a: discrepant a ntre unit a ti de m asur a n sistemele anglo-american si metric erori multiple de proces: lipsa unor interfet e 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 consecint ele foarte grave

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

Vericare si validare: terminologie

Software Engineering Institute Capability Maturity Model Integration: Vericarea asigur a c a produsul e construit n concordant a cu cerint ele, specicat iile si standardele. Sunt ndeplinite cerint ele specicate ? Produsul e construit corect (cum trebuie) ? (are we building the product right?) Validarea asigur a a produsul va utilizabil pe piat a. Produsul acoper a nevoile operat ionale ? Produsul poate utilizat n mediul intent ionat ? Se construie ste produsul care trebuie ? (are we building the right product?)

V & V: terminologie

NASA Software Assurance Guidebook and Standard: V&V: Procesul de a asigura c a produsul software: va satisface cerint ele (funct ionale si altele) validare si ecare pas n construirea sa rezult a un produs corect vericare Diferent a dintre vericare 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 funct iona conform cerint elor.

V&V: proces si tehnologii

Tehnologii inspect ie review (analiz a de c atre un tert ) inspection (ca mai sus, dar cu proces si roluri riguros denite) walkthroughs (prezentare solicit and opinii) testare analiz a si vericare formal a Proces faza de conceptie: stabilirea planului de testare analiza cerint elor: scenarii de test pe baza celor de utilizare design: vericarea modelulul n raport cu specicarea implementare: inspect ie + testare la nivel de modul integrare: testare de integrare, rapoarte de test

Ce e testarea ?

Testarea e procesul prin care se execut a un program cu intent ia de a g asi erori (Myers, The Art of Software Testing).

Ce e testarea ?

Testarea e procesul prin care se execut a un program cu intent ia 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 eectively 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.

Ce e testorul ?

Rolul unui testor e s a g aseasc a erori c at mai devreme cu putint a (costul corect arii cre ste odat a cu timpul) si s a asigure corectarea lor (rapoarte, depanare, mentenant a) (Patton, Software Testing)

Erori, cauze si cost

Cauza / sursa erorilor cele mai multe, cauzate de decient e n specicat ie apoi cele origin and n faza de proiectare doar relativ put ine (uneori sub 15%) erori directe de programare Costul erorilor cre ste, chiar exponent ial, avans and n procesul de product ie O($1) la specicare, O($1000+) dup a livrare

Cauzele si costul erorilor (cont.)

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

Cauzele si costul erorilor (cont.)

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: vericare si validare: 52% cost (57% timp) din acesta, 27% cost n examinare, 73% n testare 21% pt. 4 defecte n testarea nala, din care 1 de proiectare eliminarea prin examinarea codului: 160x mai ecient a dec at la testare

Cauzele si costul erorilor (cont.)

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: vericare si validare: 52% cost (57% timp) din acesta, 27% cost n examinare, 73% n testare 21% pt. 4 defecte n testarea nala, din care 1 de proiectare eliminarea prin examinarea codului: 160x mai ecient a dec at la testare Studiu dup a NASA JPL (sondele Voyager, Galileo) majoritatea: decient e n specicarea cerint elor si a interfet elor 1 eroare la 3 pagini de cerint e si 21 pagini de cod doar 3 din 197 erau erori de programare 2/3 din erorile funct ionale: omisiuni n specicarea cerint elor majoritatea erorilor de interfat a: datorate proastei comunic ari

Calit a tile testorului software

What Makes a Good Software Tester (Patton) They They They They They They They They are explorers. are troubleshooters are relentless are creative are (mellowed) perfectionists exercise good judgment are tactful and diplomatic (?) are persuasive (!)

Principii ale test arii (Myers)

Un caz de test trebuie s a deneasc 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 except ie: dezvoltarea simultan a cu testarea unitar a (TDD) Corolar: grupul de testori ar trebui s a e altul dec at cel de dezvoltare Sunt necesare cazuri de test pentru condit ii de intrare valide si invalide. Trebuie testat c a produsul face ce trebuie si nu face ce nu trebuie ! P astrat i si refolosit i cazurile de test! Nu planicat i procesul de testare presupun and c a nu vor g asite erori! Probabilitatea de a g asi erori ntr-un fragment de cod e proport ional a cu num arul de erori deja g asite.

Axiome ale test arii (Patton)

Testarea software e un exercit iu 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 corectate E greu de spus c and o eroare e o eroare ... Specicat iile produselor nu sunt niciodat a denitive 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 nd rates and the severity composition of the bugs we found were within the expected range. Our bug x 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 x. 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 x.

Testarea ntreb ari fundamentale

[Cem Kaner, Black-box software testing course, Florida Inst. of Tech] Ce test am ? Ce vrem s a a 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

Testarea o viziune mai general a

o investigat ie tehnic a a produsului de testat efectuat a pentru a oferi persoanelor implicate informat ie legat a de calitate [Kaner] investigat ie: c autare activ a, organizat a de informat ii tehnic a: experimente, logic a, modele, algoritmi, unelte produsul testat: ce prime ste clientul, n totalitate (software, hardware, baze de date, documentat ie, etc.) persoane implicate: n succesul produsului, si al test arii

Scopuri ale test arii

[ Kaner 2003 What is a good test case ? ] g asirea de defecte: mai ales n p art ile 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 conformant ei la specicat ii / reguli / standarde minimizarea riscurilor de accidente ( si costurilor legale ...) g asirea de scenarii de utilizare sigur a (funct ionare corect a) evaluarea calit a tii produsului (dar nu doar prin testare) Ce nu poate face testarea ? vericarea produsului (absent a de erori) asigurarea calit a tii produsului (problem a de proces)

Calit a tile unui bun caz de test

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 funct ionarea / performant a produsului (de ex. detecteaz a modic ari n comportament / performant a)

C ateva utilitare de ncercat

Klee http://klee.llvm.org/ testare C/C++ prin execut ie simbolic a Pex http://research.microsoft.com/en-us/projects/Pex/ testare C# prin execut ie simbolic a CHESS testarea programelor concurente http://research.microsoft.com/en-us/projects/CHESS/ RoadRunner analiz a dinamic a pentru programe Java concurente hhttp://www.cs.williams.edu/~freund/rr/ Java Pathnder http://babelfish.arc.nasa.gov/trac/jpf model checking si testare / execut ie simbolic a Randoop http://people.csail.mit.edu/cpacheco/randoop/ testare prin generare aleatoare + feedback, pentru Java Blast (vericator pentru C), CREST (execut ie concret a + simbolic a), Daikon (generare de invariant i), FramaC, ESCJava2 (analiz a static a) ...