Procese de testare si infrastructura

7.8 Analizatorii statici

Analizatorii statici opereaza pe o sursacod si pune in valoare procesul de testare a codului si determina posibilele microfoane ascunse inainte de oricare testari care au loc.Functiile tipice sunt ,detectia variabilelor nedeclarate si nefolosite ,loialitatea pentru codurile standarte general acceptate sau declarate local si codul analizei complexe(de obicei McCabe sau nodul de legatura).Un exemplu comun a analizatorilor statici este puful ,care analizeaza codul C si provine cu fiecare sistem UNIX.

7.8.1Analiza Lexicala si Sintactica

Analiza statica are inceputul in asumarea analizei lexicale si sintactice al codului sursa.Un foarte folositor instrument de testare ar produce o lista de referinta aratind precum este in Figura 7.15,care este profitul programului ADA care arata sursa codului reformatat cu instrumentul de testare reformatind standardele cu numarul liniei pentru linia fiecarei declaratii.Acest file este referinta pentru celelalte iesiri a instrumentului de testare ,care se refera la linia numerelor generate si asociate declaratiilor reformatate .

1 With TEXT IO 2 use TEXT IO 3 4 procedure TRIANGLE is 5 type MY INT is new INTEGER range 0. . 1000; 6 7 package INOUT INT is new TEXT IO. INTEGER I0(MY INT); 8 use INOUT INT; 9 I, J, K, MATCH: MY INT; 10 11 begin 12 loop 13 PUT(input: THREE NUMBERS (O TO FINISH)); 14 GET(I); 15 if 16 I = O ... Figura 7.15 Exemplu instrumentului de testare a enumerarii declaratiilor

7.8.2 Incalcarile standartelor de programare

Anumite instrumente ale testarii vor cauta codul sursa pentru posibilele incalcari ale standartelor de programare folosind standartele relevante ale limbii.Raportarea altor incalcari particulare este optionala si tu poti defini pedepsele incalcarilor.Acele analize statice vor produce pedepsele totale obtinute pentru codul sursa analizat.Aceasta informatie este aratata in sumarul managementului (vezi fugura 7.16) care deasemenea contine rezultatele din analizele complexe(vezi sectiunea 18.8.4) si analiza dinamica in sumar.Figura 7.16 este un sumar tipic analizei statice :noteaza incalcarile standartelor raportate si greselile raporate.

7.8.3 Incercarea calii de analiza

Analiza statica deasemenea produce analiza caii de incercare continuta in codul sursa.Analiza caii poate fi definita ca LCSAJ(Linear Code Sequence & Jumps) si fiecare secventa a codului (segventa liniara a codului) urmata de saltul control-flux (vezi Figura 7.17).Acoperirea LSCAJ este folosita in analiza dinamica ca o masura riguroasa de executie a programei . Conceptul este limba independenta ,care necesita doar ca formatarea programului sa permita sa fie exprimate in termeni de unambiguitatea declaratiei numarului de linii.aceasta este tinuta de reformarea analizatorului static .Vezi sectiunea 12.4 pentru mai multe detalii.

Gestionarea testarii software-ului

Management summary STANDARDS VIOLATIONS IN STATIC ANALYSIS ================================================ LINE No. VIOLATION PENALTY MARK ================================================ 18 Use of GOTO statement 10 -----------------------------------------------TOTAL PENALTY FROM STATIC ANALYSIS = 10 TOTAL NUMBER OF LINES IN PROGRAM = 58

Figura 7.16 Exemplu de rezumat al instrumentului management

Figura 7.17

Extragerea din un test de control analitic aratind un LSCAJ

7.8.4 Testul de acoperire a problemelor

Exemplu: noi avem un sistem compus din 5 capitole si 3 articole primare.Noi putem insista ca developatorii sa obtina 100% de acoperire a declaratiilor a capitolelors.Dar testul nu evaluaeaza toate conditiile,nu controleaza daca conditiile legate se termina ,si nu evalueaza toti operatorii logici.Deci noi vrem sa exersam toate deciziile.Declaratia IF in Figura 7.18 poate fi satisfacuta daca A si B sunt adevarate.C nu este necesar sa fie evaluat vreodata.

IF A & (B, or C) THEN D ELSE E

Figura 7.18 Deciazia gresita de acoperire a evaluarii

Procesul de testare si infrastructura

Noi putem continua aratarea acestor exemple de tipul complex crescinde a masurilor inainte de a le realiza: Nefezibilitatea citorva cai (vezi sectia 12.4) Un nivel de complexe de teste la fel ca cel aratat in Figura 18.29 si numarul cailor executabile calculate in ecuatia din figura 18.2 Din citeva puncte putem sa vedem ca citeva limite trebuie setate in unitatea de testare si ne intoarcem lacaracteristica de testare .Noi stim ca simpla testare a fiecarui element GUI nu v-a fi aratata interactiunea dintre elementesi fiind ireal ca vreun utilizator sa petreaca timpul sau pentru analizarea elementelor GUI.Deci ne uitam la scenariu sau poteci prin intermediul software-ului.Si noi repede descoperim ca acestea sunt la fel de infinite ca combinatiile de date pe care le putem folosi.Concluzie:la un anumit timp nu mai este un algoritm care sa te ghideze si trebuie sa-yti folosesti judecata bazata pe risc.Daca ai citit specificatiile si/sau contractul,tu trebuie sa ai o idee buna bazata pe risc si tipurile de acoperire tu vei avea nevoie sa fii atit de sigur cit se poate la gasirea bug-urilor.

7.8.5 Programe de verificare structurate

Acest lucru necesita un sablon definit de utilizator pentru a se potrivi constructiile admise de limba impotriva celor cuprinse in programul subiect(exemplu:IF THEN ELSE ENDIF).Un sablon standart este de multe ori suplinit de programele de verificare structurate care descriu constructiile definite sau apropiate limbii ,si tu ai posibilitatea de al modifica pentru a recunoaste cele folisite de catre grupul tau.Sabloanele pot contine grafice simple si optionale.Figura 7.19 arata citeva cintructii ADA. PROGRAMMING VERIFICATION WILL USE THE FOLLOWING STRUCTURES --------------------------------------SIMPLE COLLAPSE REPEAT CASE WHILEDO IF THEN IF THEN ELSE FORLOOP Figura 7.19 Definitia programului de verificare structurat Folosind sabloanele ,toate tipurile de limbi acceptate continu te in program sunt recunoscute.Se spune ca programul pentru a fi complet structurat daca graficele lui se reduc la un simplu nod dupa aceasta constructiile accectabile vor fi sterse.nUnele instrumente de testare de asemenea vor prezenta un raport catre Essential Complexity a McCabe,care vor depasi unitatea in cazul in care subiectul programului nu este corect strucurat.McCabe Essential Compplexity metric este obtinut prin aplicarea formulei (vezi sectia 18.8.4) la graficul rezidual. Numarul al Essential knots este deasemenea luat ca o masura de nestructuratie.O programa structurata nu va avea noduri e sentiale. Figura 7.20 este un exemplu de complexitate a analizei sumare.

EXEMPLU DE ANALIZA COMPLEXA

Manage Software Testing

7.8.6 Analizatorii fluxului de date si procedurii de apel

Informatia procedurii de apel consta din informatia despre care procedura apeleaza apeleaza alta intr-un program.Fiecare procedura in program analizeaza si afiseaza lista apelurilor altor proceduri (inclusiv apelurile recursive),este produs.Daca procedura nu apeleaza alta procedura,atunci mesajul esta printat. Figura 7.21 arata un exemplu a citorva informatii despre procedurile de apel. Fluxul de date a erorilor de mesaje sunt produse de analizatorii fluxului de date,si raporteaza trei tipuri de conexiuni ale fluxului de dategasite grupate de eroarede genu: UR,Du si DD.In exemplul aratat in Figura 7.22 mesajul consta din nume variabile ,linii de numere si tipul ambelor parti ale erorii . Daca cealalta parte se intimpla ca rezultatul sa apeleze ,este indicat ,la fel cum declara si alte variabile,dar niciodata folosite.

Figura 7.21 Exemplu de sumar a procedurii de apel

Figura 7.22 Exemplu de flux de date analizind erorile de mesaje

Procesul de testare si infrastructura De exemplu, n cazul n care programul prezentat n figura 13.3 a fost analizat de ctre ananalizor dataflow urmtoarele mesaje vor fi produse. Analiza parametru procedur (figura 7.23) cuprinde informaii despre tipurile de utilizarepentru fiecareparametru de o procedur. Fiecare procedura este analizata la rndul su, precum i tipurilede utilizare a parametrilor sisunt determinate pentru sa detecteze dac parametrul este: - Referite numai: valoarea acesteia este utilizat, dar niciodat nu s-a schimbat n cadrul procedurii. - Definit numai: aceasta are o valoare atribuit, dar aceast valoare nu este niciodatfolosita. - Atit de referin i definite. - Nu este utilizat n cadrul procedurii. Analiza este efectuat dincolo de frontierele procedurii. Astfel, o variabila, care este trecuta la o procedurai n cadrul acestei proceduri este trecut ca un parametru la altul, vor fi clasificate n mod corect, n funcie de utilizarea sa n ambele proceduri.

Figura 7.23 Exemplu de analiz de ieire parametrului

7.8.7 Cross-Referencer
7.8.7.1 General
Cross-referencers se refer la toate elementele de date folosite ntr-un program,identificarea tipului de utilizare a fiecrui element de date(global, local, sau un parametru), i oferind o reprezentare textual a copacului de apelare complet a programuluin analiz.

7.8.7.2 Output Outputurile furnizate de cross references includ:

Un copac apel a programului de analiz n conformitate cu produse pe baz deprocedurde-procedura n formde o list a tuturor procedurilor, i a solicitat de asteptare O trimitere a tuturor elementelor de date utilizate n cadrul unui program organizat pe o procedur-de-procedura debaz enumerate dup cum urmeaz:

7.9 Analizatorii dinamici

Analizoare dinamice au dou utilizri. n primul rnd, acestea culeg date pentru a furniza informaii cantitative cu privire la de ncercare de acoperire. n al doilea rnd, ele pot identifica acele poriuni de cod care sunt utilizate frecvent sau rar n timpul execuie normal, expunndu-se astfel orice blocaje potenial de performan.

Administrare Testare Software

FIGURA 7.24 Exemplu de ieire a unui eco-referencer

Cuantificare acoperire de testare servete dou scopuri. n primul rnd, cerinele decontrol al calitii poate include o trebuie s demonstreze c fiecare calea de cod, sucursala, sau declaraie a fost executat n procesul de testare. A doua analiz, dinamic spune programatorul cum este el progreseaz n testarea lui, il ajut s identifica acele zone din cod care trebuie nc s fie abordate. 7.9.1 Rezultate analiza dinamica Analiza dinamic poate indica n mod clar un program de rezistena i, prin urmare,fiabilitatea acesteia. unele dinamic instrumente de analiz a raportului privind eficiena de date de testare folosind Indicatoride ncercare eficiena (minitrii), aa cum se arat n Figura 7.25 prin intermediul. Figura 7.29 De acoperire, i anume, valorile Ters, poate fi mrit prin a executa din nou codulinstrumentate cu date suplimentare, de testare diferite seturi.

Procese de testare si infrastructura

Figura 7.25 Exemplu de declaratie de acoperire sumara

FIGURA 7.26 Exemplu ramurii de executie a profilului

FIGURA 7.27 Exemplu ramurii de executie sumare

Administrarea testarii software-ului

FIGURA 7.28 Exemplu cararii de testare a executiei profilului

FIGURA 7.29 Exemplul cararii de testare a executiei sumare

Procese de testare si infrastructura

7.9.2 Eficacitatea testului

Ratia eficacitatii testului (TERs) 1,2 si 3 au fost definite,unde:

Cei trei numitori n formulele de mai sus pot fi identificate n timpul analizei statice i utilizate ca constante n ecuaii.Numrtorii sunt calculate de ctre o inspecie de un dosar de executare,generat la timp pentru a alerga prin codurile instrumentate. Acoperirea este maximizata prin rularea unui numr de subiecteexecuii a programelor cu apartamente de date stimulate. TER 1 i 2 n mod normal, ajunge la unitate, fr mare efort (dei sucursalele imposibile pot fi descoperite), dar TER trei GALuri de multe ori Ters1 i 2 de ctre unii marja, pentru c TER 3 necesit o strategie de testare exigenta pentru a realiza unitatea.Dac, totui, unitatea poate fi realizata pentru TER 3, atunci numrul de bug-uri nedetectate rmase n program sunt supuse n mod substanial redus.

8
Documente-text

Apel conectat

ind consultantul de proba a ajuns el a cerut sa vada cerintele din caietul de sarcini.Acesta era acoperit cu fisa

inscriptionata:Vei vedea directorul acestui proiect .Esti aici sa testezi. Compania a fcut apel telefonic de logare de software i a fost deinut de un Big European Corporation.
The test consultant promptly crashed the system twice in two ways creating the blue screen of death each time. People were not pleased. Then he got some output and wrote a script to analyze it. It showed that telephones were being put down before being picked up and traffic being transmitted to a telephone without it being picked up. He logged each bug.

Consultantul de testare a prabusit sistemult de doua ori in doua moduri diferite creind un screen albastru a incetarii functionarii fiecaruia. Oamenii nu au fost mulumii.