FACULTATEA DE ELECTRONICA, TELECOMUNICATII SI TEHNOLOGIA INFORMATIEI
Implementarea, testarea, verificarea i
validarea produselor software
Coordonator, Conf. Dr. Ing. tefan Stncescu
Lecu Radu erban Tic Andra Maria Vidracu Mihai 442A -2011-
Cuprins
I. Etapele de realizare ale produselor software Lecu Radu erban 1. Introducere 2. Etapele de realizare ale unui produs software
II. Implementarea produselor software 1. Introducere 2. Scopul 3. Codul surs 3.1. Scopul 3.2. Organizarea 3.3. Calitatea 3.4. Licenierea 4. Calitatea produselor software 5. Limbajul de programare 5.1. Compilarea i interpretarea 5.2. Limbaje procedurale vs. limbaje obiect-orientate 5.3. Alte limbaje de programare folosite 6. Reguli de scriere a unui cod de calitate 7. Documentarea codului 7.1. Pseudocod 7.2. Organigrame 7.3. UML 8. Concluzii
III. Testarea produselor software 1. Introducere 2. Scopul testrii 3. Realizarea unui test software 4. Automatizarea testrii
Bibliografie
5. Tipuri de teste software Vidracu Mihai 5.1. Testare prin metoda cutiei negre (Black-box) 5.2. Testare white-box 5.3. Testare gray-box 5.4. Testarea funcional 5.5. Testarea nefuncional 5.5.1. Testare de compatibilitate 5.5.2. Testare de anduran 5.5.3. Testare de incrcare 5.5.4. Testare de localizare 5.5.5. Testarea de performan 5.5.6. Testare de securitate 5.5.7. Testare de utilizabilitate 5.6. Concluzii Bibliografie
IV. Verificarea i validarea produselor software Tic Andra Maria 1. Introducere 2. Recenzii 3. Verificri formale 3.1. Model checking 3.2. Inferena logic 3.3. Derivarea de program 3.4. Verificare prin demonstrare de teoreme 4. Concluzii 5. Bibliografie
V. Concluzii
Implementarea, testarea, verificarea i validarea produselor software
I. Etapele de realizare ale produselor software
Lecu Radu erban
1) Introducere
Dezvoltarea unui produs software presupune etape de analiz, proiectare, scriere, testare, debugging i mentenan a codului surs al programelor. Dezvoltarea unui produs software poate fi folosit pentru a face referire la programarea calculatoarelor, nsa ntr-un sens mai extins reprezint totalitatea activitailor de realizare ale unui produs software (= programarea calculatorarelor) ideal ntr-un proces planificat i structurat. Scopul final este de a obine o soluie software eficient i care poate evolua n timp. [4]
2) Etapele de realizare ale unui produs
Implementarea, testarea, verificarea i validarea produsului software sunt cele mai importante etape de realizare ale unui produs software. Pentru nelegerea lor este ns nevoie de cunoasterea tuturor etapelor. Dei sunt considerate etape separate, intre ele exist o puternic relaie de interdependen.
2.1) Analiza cerinelor Analiza cerinelor este prima etap a ciclului de realizare a unui produs n care se stabilesc cerinele aplicaiei, pornind de la cerinele utilizatorului final, se identific funciile viitorului produs software precum i datele implicate. Aceast etap rspunde la ntrebarea ce se va realiza prin dezvoltarea produsului software.[17]
2.2) Proiectarea arhitecturii software Proiectarea reprezint acea etap a ciclului de realizare a unui produs n care se stabilete modul de realizare a cerinelor identificate n etapa de analiz, adic trebuie s raspund la ntrebarea cum se vor realiza aceste cerine att la nivel global ct i la nivel de detaliu. Aceast etap pornete deci de la cerinele i specificaiile definite anterior i continu cu detalierea i transformarea acestora pn la definirea structurii unei soluii care s fie reprezentat folosind un limbaj grafic, textual sau mixt. Proiectul astfel obinut trebuie s poata fi utilizat mai departe la construirea sau elaborarea produsului software (codificare, testare, integrare).[17]
2.3) Implementarea codului Implementarea codului reprezint scrierea textului folosind formatul i sintaxa unui limbaj de programare ales. Codul este special conceput pentru a facilita munca unui programator, astfel oferin posibilitatea acestuia s specifice operaiile ce vor fi realizate de ctre calculator. Odat ce un program a fost realizat el va fi convertit n cod binar numit cod main, care poate apoi fi citit si executat.[5]
2.4) Compilarea si interpretarea Compilarea reprezint o metod prin care calculatorul convertete codul surs scris ntr-un limbaj de programare (de cele mai multe ori un limbaj de nivel nalt cum ar fi c++, Java) ntr-un limbaj de nivel jos (cod main sau assembler). n urma realizrii acestei operaii se obine un fiier executabil ce poate fi neles i rulat de ctre maina sau mainile pentru care a fost conceput.[6] Interpretorul reprezint o metod prin care maina convertete codul surs n cod main la momentul n care acesta este rulat. Interpretorul poate fi un program care fie execut codul surs direct, fie transform codul iniial ntr-un cod intermediar, iar acesta va fi ncrcat pentru execuie, fie interpreteaz codul care anterior a fost compilat de ctre un compilator care face parte din sistemul de interpretare.[7] Fiecare din cele 2 variante are avantajele si dezavantajele sale. Spre exempul un compilator este mai rapid n momentul execuiei, nsa interpretorul folosete principiul mainii virtuale care ofer avantajul siguranei datelor.
2.5) Documentarea n general documentarea se refer la procesul de a oferi dovezi. Documentarea software sau documentarea codului surs reprezint text scris care exprim modul de implementare al programului, modul de folosire al acestuia, informaii legate de testarea programului, modificri aduse unei noi versiuni sau orice alte informaii legate de programul respectiv.[8] Exist diferite tipuri de documente: - Documente de cerine software; - Documente de arhitectur i design; - Documente tehnice; - Documente ale utilizatorului.
2.6) Integrarea Integrarea se refer la faptul c un modul poate fi integrat n interiorul unui alt modul mai complex, sau c un modul mai complex poate fi realizat din mai multe module simple. Prin integrare, datele sau informaiile oferite la ieire de primul modul pot fi folosite de ctre un al doilea modul ca valori de intrare cu condiia ca ambele module s respecte acelasi format la ieire, respectiv intrare. [9]
2.7) Testarea software Testarea software reprezint o investigatie dirijat n scopul de a obine informaii legate de calitatea produsului software realizat n etapele anterioare.
2.8) Debugging Debugging-ul reprezint o metod prin care se detecteaz i se elimina bug-urile (erorile) unui program (sau, general vorbind, n orice component electronic), n scopul de a-l face s funcioneze pe msura ateptrilor. Aparent debug este echivalent cu testarea, ns prin termenul de debug se intelege testarea, descoperirea cauzelor de eroare i rezolvarea acestor erori. Debuggingul este puternic dependent de modul n care codul este implementat. Principala problem este aceea c orice modificare adus codului poate s duc la modificarea funcionalitii ntregului program. Astfel este foarte important modul n care codul este realizat pentru a facilita rezolvarea unor astfel de buguri. De aceea este necesar respectarea unor reguli de scriere a liniilor de cod cum ar fi: coupling, ncapsularea datelor, cohesion. [10]
2.9) Verificarea i validarea software Verificarea asigur c produsul e construit n concordan cu cerinele, specifcaiile i standardele specificate. Validarea asigur c produsul va fi utilizabil pe pia. 2.10) Mentenana Odat lansat pe pia un produs software nu nseamn c este lipsit de erori. Mai mult, dei produsul este funcional, pot fi aduse nbuntiri ulterioare. Astfel dupa apariia versiunii iniiale procesele de implementare, testare, debug pot fi continuate. [11]
2.11) Specificarea Specificarea (spec) reprezint un set explicit de cerine ce trebuiesc satisfacute de un material, produs, sau serviciu. Astfel putem spune c specificarea reprezint un standard.
II. Implementarea produselor software
1) Introducere
Implementarea reprezint realizarea unei aplicaii sau execuia unui plan, unei idei, unui model, etc. n tiina calculatoarelor implementarea reprezint realizarea unui algoritm sub form de program. Exist numeroase aplicai care pot utiliza diferite standarde. Spre exemplu, la browser-ele web este de recomandat s conin implementri ale World Wide Web Consortium, iar sistememele de dezvoltare conin implementri ale limbajelor de programare. Este cunoscut faptul c prezena unuia sau a mai multor utilizatori n cadrul tuturor etapelor de realizare a produsului este una benefic. De exemplu prezena utilizatorului la realizarea designului sistemului, li se ofer posibilitatea s modeleze sistemul n conformitate cu prioritile lor i li se ofer posibilitatea s adapteze produsul final conform cerinelor lor. n plus exist o probabilitate ca s reacioneze mult mai uor la schimbri. Implementarea unui produs software reprezint munca n echip a unui numar mare de dezvoltatori de programe de multe ori aflai n locaii diferite (ex: tri diferite). Astfel este necesar folosirea unor metode de implementare a produsului software. O metod de implementare a produsului software reprezinta o abordare sistematic structurata pentru a integra efectiv un serviciu software de baz sau o component n structura ntregului produs. [5]
2) Scopul
Codul implementat are 2 roluri ce trebuie avute n vedere - pentru a putea fi rulat de sistemul de calcul pentru care a fost destinal; - pentru a fi inteles de programatorii care citesc codul, inclusiv cel care l-a conceput iniial.
3) Codul surs
Codul surs reprezint reprezint textul scris folosind formatul i sintaxa unui limbaj de programare ales. Codul este special conceput pentru a facilita munca unui programator, astfel oferind posibilitatea acestuia s specifice operatiile ce vor fi realizate de ctre calculator. El poate fi vzut ca o modalitate prin care utilizatorul informeaz calculatorul ce i cum are de fcut n scopul manipulrii anumitor date. Odat ce un program a fost realizat el va fi convertit n cod binar numit cod main, care poate apoi fi citit si executat. Prin scrierea de cod utilizatorul informeaz un compilator sau interpretor cum s realizeze codul binar folosit pentru rularea programului. Majoritatea aplicaiilor sunt distribuite ntr-un format de tip executabil, care nu conine cod surs. Utlizatorul nu trebuie s cunoasc modul cum a fost implementat programul, ci numai ce face programul. n caz contrar acesta ar putea modifica codul surs sau nelege cum funcioneaz.[12]
3.1) Scopul Codul surs este n primul rnd folosit pentru a comunica unui sistem de calcul ce are de fcut. Un alt scop este acela ca odat realizat un cod surs ntr-o aplicaie cu o anumit funcie, acesta s poat fi utilizat n multiple alte situaii ale aceluiai program sau a unui alt program care care are de realizat aceiai funcie. Aceast tehnic este folosit de ctre programatori att pentru economisirea de timp ct i pentru nvtarea de tehnici noi de implementare a unui program.
3.2) Organizarea Codul surs al unui program poate fi coninut de ctre un singur fiier sau de ctre mai multe fisiere. Dei este de dorit evitarea acestei situaii, n anumte cazuri este necesar scrierea codului surs n limbaje de programare diferite. Spre exemplu limbajul de programare C poate conine i linii de cod scrise n limajul assembler.
3.3) Calitatea Calitatea unui produs software este data de modul n care acesta este implementat i are implicaii puternice n care ulterior, un alt programator poate nelege testa i modifica codul iniial. Calitatea produsului software este dat de anumite caracteristici care au fost prezentate mai sus. Pentru ca un produs s fie considerat de calitate sunt necesare respectarea anumitor reguli de implementare. 3.4) Licenierea Un produs software odat realizat poate fi de 2 tipuri: free software sau proprietary software. Prin free software se ntelege acel software care poate fi folosit, distribuit, modificat, sau studiat de ctre oricine fr a fi nevoie s plteasc pentru el. n al doilea caz codul surs este inut secret, utilizatorul putnd s aib numai posibilitatea de utilizare a lui numai pe baz de licen.
4)Calitatea produselor software
Un produs software pentru a putea fi considerat funcional este suficient s ndeplineasc cerinele de realizare. Un produs software pentru a putea fi considerat de calitate pe lng faptul c este funcional el trebuie s respecte i o serie de alte cerine. Nu exist produse software lipsite de erori. Un produs nu este finalizat odat cu lansarea sa pe piat deoarece ulterior pot fi oricnd adugate funcionaliti noi. Un produs software trebuie astfel conceput nct s poat fi neles, testat, corectat i modificat cu uurin i cu riscuri ct mai mici de generare de noi erori. Produsele software sunt caracterizate de o serie de caliti care au implicaii att n ceea ce privete implementarea codului surs al produsului, ct i al altor operaii cum ar fi testarea, verificarea, validarea, mentenana, debugging, integrarea.
Caracteristicile necesare pordusului software pentru a putea fi considerat de calitate sunt:
4.1) Corectitudinea (reliability) Prin corectitudine se exprim ct de des rezultatul dat de program este corect. Reliability se refer la corectitudinea algoritmilor. Scopul este de a minimiza greelile de program datorate managementului resurselor i erorilor logice. [4]
4.2) Robustee (robustness) Prin robustee se intelege ct de bine reueste programul s anticipeze probelemele aprute n cadrul manipulrii datelor. Acesta se refer la detecia unor situaii cum ar fi date incorecte, nepotrivite, distruse, nedisponibilitatea lor la un moment dat, probleme legate de indisponibilitatea de memorie, de servicii oferite de sistemul de operare, conexiune prin reea sau probleme datorate utilizatorului i intrrilor introduse de acesta. [4]
4.3) Utilizabilitate (usability) Utilizabilitatea se refer la uurina cu care o persoan poate folosi un anumit program n scopul rezolvarii problemelor pentru care a fost realizat programul, sau n anumite cazuri i a unor probleme neanticipate. Aceasta implic o gam larg de elemente att de tip software ce in de aspectul grafic al aplicaiei i de controlul produsului software, ct si de partea hardware a mainii de calcul pe care ruleaz aplicaia. Elementele de tip grafic se refer la influena aspectului grafic al programului asupra utilizatorului, la intuitivitatea i coerena programului, iar celelalte elemente se refer la funcionalitatea programului adic la probleme care duc la stri de asteptare mult prea mari datorate implementrii sau chiar la blocarea programului. [4]
4.4) Portabilitate (portability) Prin portabilitate se nelege gama de sisteme hardware i sisteme de operare pe care se poate interpreta sau compila i rula programul. Aceasta se refer la adaptabilitatea facilitilor oferite de program la multitudinea de sisteme hardware i sisteme de operare. [4]
4.5) Mentenabilitate (maintainability) Aceast proprietate se refer la uurina cu care programul poate fi modificat de ctre programatorii prezeni i viitori cu scopul de a corecta buguri, de a face modificri, de a reliza faciliti suplimentare sau de a-l adapta la alte sisteme hardware sau sisteme de operare. n acest caz trebuie luat n calcul modul cum a fost proiectat i implementat produsul.[4]
4.6) Eficien/ performan (efficiency/performance) Prin aceste caracteristici se nelege cantitatea de resurse folosite de ctre program. Cu ct sunt folosite mai puine resurse cu att eficiena este mai mare. Aceastea includ distribuirea corect de resurse cum ar fi tergerea de fiiere temporare sau de date stocate inutil n memorie, folosirea inutil a reelei. O importan deosebit n acest caz o are i structura hardware. De multe ori un program este conceput n anumite scopuri pe baza crora se alege i configureaz sistemul de calcul pe care va funciona programul respectiv. Astfel structura acestui sistem trebuie astfel aleas nct costurile de cumprare ale hardului s fie orientate ctre cresterea performanei produsului software prin creterea performanelor componentelor hardware folosite mai intens (ex: n cazul serverelor folosite intens pentru stocarea de date s se pun mai mult accentul pe viteza de stocare a datelor dect pe cea de procesare). Astfel componeta software este n strns legtur cu cea hardware. [4]
Alte caracteristici:
4.7) Lizibilitatea codului sursa Prin lizibilitatea codului surs se nelege usurina cu care scopul, fluxul de informaie i operaiile codului surs pot fi nelese de ctre un programator. Aceasta are implicaii asupra unor caliti menionate mai sus cum ar fi portabilitatea, utilizabilitatea sau mentenabilitatea.
4.8) Complexitatea algoritmilor Complexitatea algoritmilor se refer la alegerea dintr-o mulime de algoritmi care au aceiai funcionalitate ns care pot fi mai eficieni sau nu. Eficiena se poate face pe diferite criterii: timp, resurse folosite, dificultate de implementare. Programatorii experimentai au sarcina de a alege cel mai eficient algoritm corespunztor aplicaiei pe care o implementeaz.
5) Limbajul de programare
Codul surs este diferit n funcie de limbajul de programare ales. n plus putem avea diferite limbaje de programare folosite n cadrul aceluiai proiect n funcie de aplicaia dorit. Exist limbaje de programare procedurale i limbaje de programare obiect-orientate. Putem folosi n cazul aplicaiilor Web limbaje de programare destinate browser-elor (Web development): JSP, JavaScript, HTML. n cazul serverelor de multe ori trebuie stocat o cantitate mare de informaie, caz n care vom folosi aplicaii si limbaje de programare destinate realizrii i gestiunii unor baze de date: SQL, Oracle. Spre exemplu, putem folosi o aplicaie care foloseste o interfa web scris n JSP care folosete diferite clase Java i cu ajutorul creia se conecteaz la un server ce are o baz de date realizat folosind MySQL
5.1) Compilarea si interpretarea n principiu, limbajele de nivel nalt pot fi grupate n 2 categorii: compilatoare i interptretoare. n realitate exist rar programe care pot fi asociate exclusiv uneia din cele 2 categorii. Compilarea reprezint o metod prin care calculatorul convertete codul surs scris ntr-un limbaj de programare numit surs (de cele mai multe ori un limbaj high- level cum ar fi c++, Java) ntr-un limbaj de calculator numit limbaj int (cod main sau assembler). Sursa iniial se numete cod surs iar rezultatul cod obiect. n urma realizrii acestei operaii se obine un fiier executabil ce poate fi neles i rulat de ctre maina sau mainile pentru care a fost conceput. Un program care face operaia invers poat numele de decompilator. Comilatoarele ofer posibilitatea de dezvoltare a unor porgrame care sunt independente de maina pe care acestea sunt rulate. n cazul programelor scrise n assembler codul trebuia modificat dac era schimbat maina pe care era rulat programul. Un compilator pur este folosit numai n cazul limbajelor de tip low-level, deoarece este mai natural i mai eficient. [6] Interpretorul reprezint o metod prin care maina convertete codul surs n cod main la momentul n care acesta este rulat. Interpretorul poate fi: - un program care execut codul surs direct - un program care transoform codul iniial ntr-un cod intermediar, iar acesta va fi ncrcat pentru execuie - un program care interpreteaz codul care anterior a fost compilat de ctre un compilator care face parte din sistemul de interpretare. Principalul dezavantaj al unui interpretor este c acesta este mult mai lent. Spre exemplu un program interpretat poate fi de 10 ori mai lent dect cel compilat. De aceea nu este niciodat folosit un interpretor pur. n schimb precompilarea programului si apoi interpretarea noului cod la rulare reduce puternic timpul de rulare, pstrnd avantajele oferite de interpretare.[7]
5.2) Limbaje procedurale vs limbaje obiect-orientate Printr-o procedur se nelege o rutin, subrutin, metod sau funcie care conine o serie de pai ce trebuiesc parcuri. Orice procedur poate fi apelat la orice moment de timp, n timpul execuiei programului respectiv, inclusiv oferindu-se posibilitatea ca o procedur s se autoapeleze. Scopul programelor procedurale este de a mprii funcia acestuia ntr-o colecie de variabile, structuri de date i subrutine.[13] n cazul programrii obiect-orientate, se folosesc obiecte, care interacioneaz n scopul de a realiza o anumit funcie. Principalul avantaj al programrii obiect orientate este acela c un program este mult mai usor de organizat. Un limbaj de programare procedural poate fi vzut ca o clas care conine un singur obiect. n cazul programrii obiect orientate acest obiect poate fi divizat n mai multe obiecte. Dup aceea putem introduce interefee prin care obiectele pot interaciona. Programarea obiect orientat ofer avantaje cum ar fi ncapsularea datelor, motenire, polimorfism, date abstracte care duc la simplificarea codului i a complexitii acestuia, n acelai timp introducnd avantajul securitii ridicate ale datelor. [14]
5.3) Alte limbaje de programare folosite (limbaje de programare pentru aplicaii web i limbaje de programare folosite pentru baze de date). Iniial calculatoarele au fost realizate pentru a funciona independent. Ele rulau programe simple care procesau cantiti mici de informaie. Dup apariia internetului a fost necesar extinderea acestor limbaje pentru a oferii posibilitatea de comunicare ntre calculatoare. Aplicaiile web i stocarea unor cantiti foarte mari de informaie stau la baza acestei dezvoltri. Apariia browserelor web a dus la realizarea de limbaje de programare folosite de acestea. Au fost astfel realizate limbaje de programare cum ar fi HTML, JSP, JavaScript, PHP. Prin Web development se nelege procesul de realizare a unui site web. Acesta presupune aceleai etape ca in cazul orcrui alt tip de program. Aplicaiile web au fost destinate a fi folosite de un numr mare de utilizatori din ntreaga lume. Astfel a fost necesar realizarea unor servere pe care s fie stocate informaiile. Stocarea poate fi realizat folosind baze de date. Bazele de date reprezint o modalitate prin care o cantitate mare de informaie poate fi organizat pentru ca datele s fi stocate, citite i modificate independent. De cele mai multe ori bazele de date ofer att posibilitate de realizare i gestionare grafic, ct i sub form de linii de cod.
6) Reguli de scriere a unui cod de calitate
Pe lng faptul c programul trebuie bine documentat, un programator trebuie s aib n vedere c scrierea unui program este numai una din multiplele etape de realizare ale unui program software profesional, iar programarea unui software complex presupune munca n echip a unui numar mare de oameni. Cnd un program complex este realizat exist mai muli programatori care lucreaz la acel proiect. De multe ori un program este realizat de o anumit echip de programatori, iar la un moment dat anumii membrii sau chiar ntreaga echip trebuie s preia proiectul pentru a-l finaliza. Noii programatori care se ocup de proiect trebuie s nteleag liniile de cod scrise pentru a putea finaliza proiectul. Astfel codul trebuie astfel realizat nct s fie usor de inteles de ctre alte persoane. Trebuie realizat un program cu o complexitate ct mai sczut. Un alt lucru ce nu trebe neglijat este c odat realizat un program, sau un modul al unui program cu o anumit fucionalitate, cu ct este mai bine organizat, cu att poate fi mai usor integrat n cadrul altor aplicaii care necesit aceiai funcionalitate fr sau cu un numr mic de modificri necesare.
Modelul conceptula al couplingului (wikipedia) n plus dup etapa de implementare a codului urmeaz etape de debugging, testare, verificare, validare, mentenant, etc. care sunt puternic dependente de modul n care este scris codul Termenul de coupling (cuplarea) se refer la gradul de dependena dintre 2 subsisteme, adic la modul n care fiecare modul al unui porgram se bazeaz pe modul de funcionare al unui alt modul al aceluiai program sau al altuia i vice versa. [15] Coupling poate fi definit ca fiind cantitatea de informaie pe care un subsistem o are despre alt subsistem Se disting 7 tipuri de coupling care sunt prezentate n figura de mai sus: -Content coupling (Tight coupling) - un modul se bazeaz pe modul de funcionare al altuli modul (ex. accesul la datele din acel modul). - Common coupling - dou module mpart aceiai dat. - Controll coupling - 2 module folosesc date, protocoale, sau interfa care au acelai format. - Stamp coupling - 2 module folosesc acelai set de flaguri (steaguri) astfel influenndu-se unul pe cellalt. - Data coupling - 2 module mpart aceleai date care sunt transmise de la unul la cellalt. - Message coupling - comunicarea dintre cele 2 module se face pe baz de mesaje sau transmiterea de parametrii. - No coupling - modulele nu comunic unul cu cellalt. Micorarea gradului de coupling se poate face prin interfee. Interfaa reprezint un contract prin care un modul cunoate numai informaiile oferite prin contract de cellalt modul. Coupling este n general pus n contrast cu cel de cohesion (coesiune). Dac coupling se refer la modul n care 2 module sunt legate ntre ele, coesiunea se refer la modul de implementare al unui singur modul. Termenul de coesiune se refer la modul n care un modul are un scop bine definit.[16] Se disting 7 tipuri de coesiune: - Coincidental cohesion (lowest) - apare cnd pri ale unui modul sunt grupate arbitrar, singura relaie dintre ele fiind c au fost grupate. - Logical cohesion - apare cnd pri ale unui modul sunt grupate deoarece ele din punct devedere logic fac acelai lucru. - Temporal cohesion - apare cnd pri ale unui modul sunt gurpate deoarece ele sunt rulate cu aproximaie n aceiai perioad de timp. - Procedural cohesion - apare cnd pri ale unui modul sunt gurpate deoarece ele urmresc aceiai secven de instruciuni. - Communicational cohesion - apare cnd pri ale unui modul sunt gurpate deoarece folosesc aceleai date. - Sequential cohesion - apare cnd pri ale unui modul sunt gurpate deoarece o ieire a unei pri este intrare a altei pri. - Functional cohesion - apare cnd pri ale unui modul sunt gurpate deoarece ele contribuie la o singur funcie bine definit. De ce este important s folosim coupling i cohesion? Cei 2 termeni fac referire la complexitatea i modul n care este structurat un program. Principiul aplicat este Divide et impera (Dezbin i cucerete). n primul rnd prin coeziune se divid module complexe n mai multe module mai simple cu funcionaliti bine definite. n al doilea rnd se micoreaz gradul de coupling ct mai mult posibil astfel nct singurele dependene ntre module s fie cele necesare (ex: cnd 1 modul este dependent de functionarea altuia putem fi nevoii s folosim stamp coupling n loc de no coupling).
7) Documentarea codului Fiecare etap a realizarii produsului software presupune realizarea unei documentaii corespunztoare. Simpla implementare a codului nu este suficient deoarece complexitatea unui program este foarte mare. Astfel att utilizatorul ct i cei ce se ocup de etapele urmatoare au nevoie de informaii suplimentare, care s usureze munca acetora. O alt problem este aceea c un program presupune utilizarea mai multor limbaje de programare. Exist programatori care nu cunosc unele limbaje folosite. Astfel pentru inelegerea intregului program de ctre acetia pot fi folosite alte metode. O variant este scrierea de pseudocod. Realizarea acestor documente presupune i utilizarea unor forme grafice cum ar fi organigramele sau schite UML.
7.1) Pseudocod Un limbaj pseudocod este o scriere intermediar, menit s simplifice scrierea unui algorit ntr-un limbaj de programare i s ajute la realizarea claritii algoritmului n timp scurt. Pseudocodul poate fi vazut ca un limbaj de programare, menit nu pentru a fi introdus pe un calculator, ci utilizat ca o forma simplificat de scriere a unui algoritm folosit n cadrul unui program. Pseudocodul este un limbaj apropiat de limbajul uman, astfel putnd fi utilizat de ctre orice programator. Sintaxa general a pseudocodului este urmtoarea: algorithm <nume_algoritm> <declarare_variabile> {tipul variabilelor} <declarare_proceduri> {definirea de proceduri/functii} begin <procesul_de_calcul_P> {instructiunile algoritmului} end Elemente lexicale ale limbajului: - Cuvinte cheie - cuvinte care au un anumit neles i se folosesc numai ntr-un anumit context care sunt utilizate pentru a defini o anumit instruciune. - Identificatori - nume de variabile (constante, variabile sau funcii) care sunt folosite pentru aplelarea acestora, n timpul desfaurrii procedeului de calcul - Expresiile - forme lexicale, asemntoare operaiilor matematice, alcatuite din operatori i operanzi
7.2 Organigrame n locul scrierii de pseudocod se poate opta pentru folosirea unei reprezentri grafice a algoritmului numit organigram. n cazul dezvoltrii unui program software, organigrama este un grafic aparinnd unui program sau algoritm destinat a fi implementat pe o main de calcul. Elementele principale ale unei organigrame sunt:
- blocurile de start si stop - blocul de scriere a unei instruciuni sau secvene de instructiuni - bloc de decizie - legturi intre blocuri (realizate printr-o sgeat de legatur)
START INSTRUCTIUNE CONDIIE? Da Nu STOP Exemplu:
7.3 UML UML este un limbaj folosit pentru a defini un produs software din punct de vedere al entitailor participante, al fluxului de operaii i al relaiilor dintre entitaile participante. Un model este o abstractizare a unui sistem, ntr-un anumit context, pentru un scop bine precizat. Un model capteaz conceptele relevante ale acelui sistem (din punct de vedere al scopului pentru care a fost conceput), ignornd aspectele neeseniale. In cursul etapelor de dezvoltare a aplicaiilor software (analiza, proiectare, implementare, testare) se creeaz mai multe modele ale produsului, care capteaz diferite aspecte ale acestuia (structura, comportarea, instalarea, distribuirea, utilizarea). Pentru modelarea sistemelor complexe (n special a sistemelor software) au fost concepute un numr mare de modalitai (tehnologii) i limbaje care sa sustin aceste metodologii. Unificarea acestora s-a impus din necesitatea de a facilita schimburile de idei si proiecte si a fost susinut de personaliti marcante din domeniul ingineriei software (Software Engineering), iar rezultatul l-a reprezentat limbajul UML. UML (Unified Modeling Language) este un limbaj pentru construirea, specificarea, vizualizarea i documentarea modelelor. El a fost conceput i standardizat pentru modelarea sistemelor software, dar poate fi folosit i n alte domenii de proiectare (hardware, construcii etc.). Limbajul UML definete mai multe tipuri de diagrame (modele) care pot fi folosite pe parcursul oricrei etape (faze, iteratii) de proiectare (software sau alte domenii), oferind mai multe vederi ale sistemului dezvoltat. In UML sunt definite semantica (intelesul) i notaiile acestor diagrame, care pot fi folosite ntr-un mod foarte flexibil, n funcie de necesittile particulare de dezvoltare, fr s se prevada nici o restricie asupra modului de utilizare a diagramelor La definirea cerinelor si la dezvoltarea unui sistem complex colaboreaza mai multe categorii de specialiti i fiecare dintre aceste categorii sunt interesate de aspecte diferite ale sistemului dezvoltat. Fiecare dintre categoriile de specialiti beneficiza de cel puin o vedere a sistemul reprezentata sub form unei diagrame UML. STOP Nu a>b? Da START a=2 b=7 b=b-a Cele mai importante diagrame specificate n limbajul UML sunt: diagrame ale claselor, diagrama secvenelor, diagrama de colaborare, diagrame de stare, diagrame de utilizare. Diagrama claselor este partea esentiala a limbajului UML, n special in proiectele dezvoltate n abordarea obiect orientat. Diagrame ale clasele se dezvolt atat n etapele de analiz cat si in etapele de proiectare, cu diferite niveluri de detaliere si ele reprezinta modelul conceptual al sistemului, care stabilete structura sistemului. Diagramele de colaborare, diagramele secventelor si diagramele de stare reprezinta comportarea sistemului, in diferite faze de executie. Se folosesc In principal in proiectare si implementare. Diagramele de cazuri de utilizare (Use Case) sunt diagrame de descriere a comportrii sistemelor din punct de vedere al utilizatorului. Aceste diagrame sunt simplu de neles, astfel ncat cu ele pot lucra att dezvoltatorii (proiectantii sistemelor) ct i clienii acestora. Se folosesc n special n etapa de analiz, dar i n etapele de proiectare i testare. Mai exist i alte diagrame: diagrama componentelor, diagrame de instalare (deployment), diagrama pachetelor (package). Toate aceste diagrame se reprezint folosind elemente ale limbajului (simboluri) care sunt figuri geometrice simple (linii, dreptunghiuri, ovale). Exista unele simboluri care se pot folosi n orice tip de diagram (de exemplu simbolurile de documentare), iar alte simboluri sunt specifice diagramei n care se folosesc. Mai mult, unele simboluri (de exemplu o linie cu sageata la capat) poate avea diferite semnificaii, n funcie de diagrama n care se folosesc. Exist posibilitatea de a genera cod pe baza unui proiect UML, pentru diferite limbaje de programare: c#, java, folosind unelte de generare de cod. Astfel se poate accelera faza de implementare de cod, oferind avantajul eliminrii erorilor de scriere a codului. Exemple: - Diagrama de context static
medic administrator Evidenta cosultatii medicale - Diagram de secvent: sd Vizualizare medici Persoana Sistem Baza de date 1: Alegere vizualizare medici 2: Verificare drepturi de vizualizare 3: Cerere lista medici 4: returneaza lista medici
- Diagram de activitate: Vizualizare medici Trimite cerere Mesaj eroare Are drept de vizualizare? Cerere vizualizare medici Vizualizare lista medici Da Nu
- Diagram a claselor:
8) Concluzii Implementarea unui produs software este o etap dificil prin faptul c n cadrul programelor complexe poate fi realizat numai de ctre un grup de oameni. Astfel se pune accentul pe lucrul n echip. Implementarea unui produs software reprezint etapa de scriere efectiv a codului. Codul reprezint att un limbaj de comunicare ntre programator i calculator ct i unul folosit ntre mai muli programatori. Astfel codul trebuie astfel realizat i organizat nct s poat fi ineles i modificat sau utilizat de ctre un alt programator care ulterior va citi codul. Exist un numr mare de limbaje de programare. Alegerea limbajului de programare folosit este dependent de caracteristicile programului. Dei este de preferat s fie folosit un singur limbaj de programare n cadrul realizrii unui produs de cele mai multe ori este imposibil deoarece funciile necesare produsului nu pot fi acoperite de ctre un singur limbaj de programare. Calitatea codului este esenial. Nici un cod nu este lipsit de erori. Astfel prin respectarea unor reguli elementare de scriere a codului se permite corectarea cu usurin a bug-urilor fr a duce la generarea de erori noi. n plus complexitatea este redus fiind mult mai uor de neles, modificat iar erorile sunt mai usor de detectat. n al treilea rnd modificarea codului pentru realizarea de noi versiuni este mult mai usoar, fr a fi necessare modificri majore ale vresiunii curente. Pentru a simplifica munca celor ce preiau programul n cadrul urmtoarelor etape, documentarea are un rol important. Aceasta presupune cunoasterea si utilizarea diferitelor moduri de reprezentare a liniilor de cod, pseudocod, organigrame, UML.
III. Testarea produselor software
1) Introducere
Testarea software reprezint o investigaie dirijat n scopul de a obine informaii legate de calitatea produsului software realizat n etapele anterioare. Testarea reprezint rularea programului n scopul de a descoperi bug-uri software. Testarea este o etap puternic dependent de contextul operaional n care programul va fi folosit. Testarea produselor software reprezint o etap important n dezvoltarea produsului software deoarece, 40-50 % din eforturi sunt directionate n aceast direce, mai ales pentru produsele software care necesit un grad mare de siguran. O analogie interesant este similaritatea dintre testarea software i pesticide, care poart numele de Pesticide Paradox. Orice metod este folosit pentru gsirea si eliminarea gndacilor va lsa n urm anumite categorii de gndaci care sunt imuni la acea metod. Astfel orice metod este folosit pentru detecia si corecia erorilor nu duce la dispariia n totalitate a tuturor erorilor. Din acest motiv defectele software sunt denumite bugs iar testarea i rezolvarea acestor defecte poat numele de debugging. Complexitatea i varietatea erorilor este att de mare nct este imposibil minii umane s rezolve toate aceste erori. Eliminarea erorilor este atat de dificil nct n timpul necesar pentru eliminarea tuturor acestora apar noi erori. n urma testrii se poate, sau nu, confirma faptul ca produsul software supus testrii corespunde cerinelor care au dus la crearea acestui produs i ca functioneaz corespunztor asteptrilor. Este evident c dei testarea reprezint o etap separat. Ea este puternic dependent de etapa de dezvoltare i are la baz metodele de dezvoltare ale produlsului software. Un produs software este diferit de orice alt sistem fizic cu intrri i ieiri. Un produs software nu sufer defecte datorate trecerii timpului (ex: coroziunea n cazul unor componente electrice ale unui circuit). Singurele tipuri de defecte pe care le poate suferii un produs software sunt date de proiectare i implementre. Un produs software odat realizat, nu va mai suferi modificri dect n urma realizrii unei noi versiuni a acelui program. Astfel, dac un produs este declarat funcional momentul n care are loc finalizarea testrii el va fi funcional la orice alt moment de timp ulterior. Principala cauz a erorilor unui produs software este dat de complexitatea acestuia. Oamenii au o capacitate limitat de procesare n cazul unei complexiti ridicate. Din acest motiv defectele de proiectare sunt inevitabile. De aceea este imposibil de conceput un produs software care sa nu conin erori i nu exist nici o modalitate de testare a produsului software care s elimine sau cel puin s detecteze toate aceste defecte. Exist situaii cnd rezolvarea unei erori s duca la apariia unora noi. Astfel, dac este detectat o anumit eroare n faza de testare, se poate ncerca remedierea ei. Este totui posibil ca acea remediere s nu duc la rezolvarea erorii, sau chiar s duc la apariia unora noi. Dup realizarea coreciei trebuie reluat faza de testare pentru a avea sigurana c modificarea realizat a dus la rezolvarea problemei fr introducerea unora noi. Este important de neles c orice modificare adus unui program software trebuie nsoit de un set de teste care s asigure funcionalitatea noii versiuni nainte de a fi dat utilizatorilor. Cea mai mic modificare poate duce chiar la schimbarea total a modului de funcionare a produsului software. O alt situaie este n cazul n care eroarea apare pentru un numr foarte restrns de valori de intrare. Acesta poate fi un lucru favorabil dac eroarea este neglijabil (ex: dei nu se obine rezultatul dorit pentru acel domeniu de valori, apariia acestor erori nu duce la pierderi seminificative). n acelai timp, poate fi i un lucru nefavorabil deoarece aceast eroare este greu de detectat i e posibil s nu fie detectat n faza de testare. Dei probabilitatea de apariie a acestei erori este mic, n anumite situaii efectele aprute n urma acestei erori pot fi devastatoare (ex: costuri mari, pierderi de viei umane). Testarea nu poate oferii o garanie de 100% c produsul funcioneaz corect n orice condiii ci numai n acele condiii pentru care a fost testat. Astfel alegerea intrrilor folosite este esenial pentru acoperirea unei game ct mai largi de posibile erori. Informaia obinut n urma testrii este esenial pentru remedierea defectului respectiv. n momentul n care se detecteaz o eroare, este posibil s nu se cunoasc i cauza care a generat acea eroare. Programatorul trebuie ca dup detecia erorii s identifice pe baza acesteia instruciunea sau secvena de instruciuni care a dus la apariia erori. n unele situaii erorile pot s apar, nu din cauz de cod greit, ci datorat unor lacune, neclariti la nivel de cerine sau cerine incomplete. Acestea pot duce la erori care apar nc din faza de proiectare de ctre designerul programului. Acestea poart numele de cerinte non-funcionale. O alt cauz important care poate duce la apariia unei erori este aceea de compatibilitate, ce poate fi cauzat att de inteaciunea lor cu alte aplicaii, cu diferite sisteme de operare sau prin rularea acestora pe sisteme hardware diferite, ct i din cauza nonconformrilor ce apar de la o versiune la alta ntr-un proces incremental de dezvoltare al produsului. Dac de exemplu produsul software a fost testat numai pe un singur sistem de operare se poate oferii sigurana n urma testtii produsului ca acesta funcioneaz corect numai pentru acest sistem de operare. Similare este i n cazul testarii produsului software pe o singur arhitectur hardware. De la o versiune la alta a unui singur program, dei versiunea nou nu are erori de funcionare, aceasta a suferit modificri care au dus la incompatibilitatea cu alte programe cu care versiunea anterioar putea interaciona fr probleme. Foarte posibil este i apariia incompatibilitii dintre 2 subdiviziuni ale aceluiai program.
2) Scopul testrii
Ideal scopul testrii este de a detecta i elimina toate erorile dintr-un program. Acest lucru este inposibil. n realitate, scopul principal este detecia erorilor, corecia celor care pot fi eliminate, minimizarea acelora care nu pot fi eliminate (rezolvarea parial a erorii, sau remedierea acelei erori dei se tie c vor aprea erori noi dar care pot fi ignorate) sau ignorarea ei n cazul n care eroarea nu poate fi eliminat sau costul remedierii erorii este mai mare dect costul datorat ei. De asemenea scopul testrii este acela de a oferi utilizatorului sigurana c produsul este conform cerinelor. n general scopurile testrii performanelor produsului software sunt: - cerceterea calitii produsului software - testarea si validarea acestuia. Deoarece produsele software sunt folosite n aplicaii critice, urmarile unui bug pot si dezastroase. ntr-o lume n care aproape orice produs are i o component software testarea produselor software n scopul creterii calitii lor este esenial. innd cont i de imperfeciunea naturii umane, a fost necesar realizarea de tehnici, algoritmi i unelte pentru testarea produselor software.
3) Realizarea unui test software
Pentru testarea unui produs trebuie realizat o secven de activitate de testare.
1) Identificarea obiectivelor 3) Calcului ieiriii estimate 2) Selectarea intrrii 4) Pregtrirea mediului de execuie 5) Executarea programului Mediu de execuie
Program 6) Analiza rezultatului testrii 7) Verdict asociat testului
4) Automatizarea testrii
Scopul testrii automate este de a minimiza cantitatea de munc manual n executara testului i acoperirea unei game mai mari de valori pentru a face testul prin aplicarea unui numr mai mare de teste. Testara automat are un impact major asupra metodelor de testare concepute i al uneltelor folosite pentru testare. Prin testarea automat se detecteaz blocrile programelor i operaiile curente oferind informaii de diagnosticare. Un model de testare poate fi reprezentat astfel:
Un tester poate s identifice componentele unui program cum ar fi GUI (Graphic user interface) i poate deasemenea realiza anumite funcionaliti cum ar fi calcule aritmetice, concatenri de stringuri, sau integrri de baze de date. Sistemul supus testului (SUT) joac un rol important n arhitecura uneltelor de test. Sistemul de test necesit introducerea de valori de intrare care pot fi alese numai n urma cunoaterii modului de funcionare al SUT-ului. n cazul testrii manuale utilizatorul aplic valori la intrare. La iesirea SUT-ului vom avea valori de ieire care sunt comparate cu valorile dorite. Un SUT poate fi reprezentat astfel: Sistemul supus testului (SUT) Intrrile testului Precondiiile dateor Precondiiile strii programului
Intrri ale mediului Rezultatele testrii Postcondiiile datelor Postcondiiile strii programului
Intrrile sistemului Motorul de funcionare Remote GUI GUI Set de date SUT GUI
User GUI
User GUI
API GUI
Pornind de la aceast structur putem proiecta un sistem de testare astfel nct utilizatorul este inlocuit de unealta de testare. Acesta introduce valorile de intrare pentru fiecare intrare de test definit i preia valorile de ieire corespunztoare. Prin compararea valorilor de ieire obinute de la SUT cu cele dorite se obin rezultatele testrii.[18]
Bibliografie - [1]Head First Software Development - Dan Pilone & Russ Miles- editura OREILLY - [2]Software Development and Professional Practice - [3]SCJP (Sun Certified Programmer for Java 6) - Kathy Sierra & Bert Bates editura Mc Graw Hill - [4]http://en.wikipedia.org/wiki/Computer_programming - [5] http://en.wikipedia.org/wiki/Implementation - [6] http://en.wikipedia.org/wiki/Compiler - [7] http://en.wikipedia.org/wiki/Interpreter_(computing) - [8] http://en.wikipedia.org/wiki/Documentation - [9] http://en.wikipedia.org/wiki/Digital_integration - [10] http://en.wikipedia.org/wiki/Debugging - [11] http://en.wikipedia.org/wiki/Software_maintenance - [12] http://en.wikipedia.org/wiki/Source_code - [13] http://en.wikipedia.org/wiki/Procedural_language -[14] http://en.wikipedia.org/wiki/Object-oriented_programming -[15] http://en.wikipedia.org/wiki/Coupling_(computer_programming) - [16] http://en.wikipedia.org/wiki/Cohesion_(computer_science) - [17] http://www.progapl.ase.ro/ps-id/Cap%205- 1_4%20Metode%20de%20proiectare%20clasice.pdf - [18] http://www.testingeducation.org/course_notes/hoffman_doug/test_automation/auto8.pdf -[19] http://education.yahoo.com/reference/encyclopedia/entry/computer-prog - [20] http://searchsoa.techtarget.com/definition/source-code - [21] http://c2.com/cgi/wiki?WhatIsSoftwareDesign - [22] http://www.inventoryops.com/software_selection.htm -[23] http://www.shiva.pub.ro/PDF/TEST/Testarea%20software%20si%20asigurarea%20calit atii%20-%20curs2.pdf - [24] http://www.chillarege.com/authwork/TestingBestPractice.pdf - [25] http://www.comp.lancs.ac.uk/computing/resources/IanS/SE7/Presentations/PDF/ch23.p df
Mihai Vidracu
5. Tipuri de teste software
5.1. Testarea prin metoda cutiei negre (black box)
Aceasta metod testeaz funcionalitatea aplicaiei, nu abordeaz deloc codul i procesele interne ale aplicaiei. Tester-ul nu trebuie s tie decat ceea ce trebuie s faca programul, nu i cum face. Se urmrete funcia de transfer a programului: se dau date de intrare i se verific datele de ieire, fr a se tii cum se face prelucrarea lor. Cazuri de testare se construiesc n jurul cerinelor i specificaiilor. Aceste teste pot fi funcionale (cele mai multe) sau nefuncionale. Aceasta metod se poate aplica la toate nivelele de testare: de unitate, de integrare, de sistem i de acceptare. [8] Deci se testeaz: - Funcionalitatea - Validarea datelor de intrare (s nu se accepte date de intrare neconsistente, ca-1 la data naterii) - Datele de ieire - Trecerea dintr-o stare n alta a sistemului (de exemplu la programul de instalare, componentele unei aplicaii se instaleaz intr-o anumita ordine, sau la realizarea unei conexiuni).[3]
5.2. Testarea white-box
Testarea prin metoda cutiei albe (sau cutiei de sticl/transparenta), sau testarea structural este o tehnic de testare care verific structura intern i modul de prelucrare a datelor (n opozitie cu testarea black-box descrisa mai sus). Pentru a efectua o astfel de testare, evaluatorul trebuie s tie cum a fost fcut programul i s aiba experienta n programare. Testerii introduc elemente de testare n cod care i ajuta s determine dac instruciunile s-au executat corect pnn punctele introduse. Este similar cu testarea unui circuit electronic n care se masoara din loc n loc parametrii pentru a evalua funcionarea corecta. Se poate aplica la nivelul de unitate, de integrare i de sistem, dar cel mai des se folosete la nivelul unitii. Dei astfel se descopera multe erori i probleme, nu se detecteaz partile neimplementate sau specificaii i cerine lipsa.[8], [5] n categoria cutiei albe sunt incluse: - Testarea fluxului de control - Testarea cailor pe care le poate lua programul - Testarea cii de date - Testarea tratrii corecte a erorilor [3] 5.3. Testarea gray-box
Testarea prin metod cutia cutiei gri presupune ca testerul s cunoasc algoritmii i structurile de date din interiorul programului, dar s testeze ca un utilizator (ca la black-box). Nu are nevoie de acces la codurile sursa. Manipularea datelor de intrare i de ieire nu se calific n testarea gray-box, intruct acestea se afla inafar sistemului (cutiei), insa modificarea structurii de date se incadreaza n aceasta categorie, pentru c, n mod normal, un utilizator nu ar putea schimba datele dinafara sistemului. Testarea gray-box poate include i ingineria inversa pentru a determina, de pild, valorile maxime i mesajele de eroare. Cunoscand conceptele din spatele produsului software, un tester poate face alegeri mai bune i n cunostinta de cauza n ceea ce priveste tipurile de teste care trebuie efectuate. n general, unui astfel de tester i se permite pregtirea unui mediu de test propriu (de exemplu, sa adauge propriile date intr-o baza de date i apoi s creeze propriile scripturi SQL pentru a vedea rspunsurile). n concluzie, testarea grey-box implementeaz teste inteligente, bazate pe cantiti limitate de informaie.[8], [3]
5.4. Testarea funcional
Testarea funcional se aplic pentru a verific dac un produs software se comporta i funcioneaz corect, conform specificaiile din proiect. O specificare funcional este o descriere a comportamentului asteptat de la program. Indiferent de ce form o ia, formal sau informal, specificarea funcional este cea mai important sursa de informaii pentru proiectarea testelor. Crearea de cazuri de testare din specificarile de program se numete testare funcional. Testarea funcional, sau, mai precis, proiectarea funcional de cazuri de testare, incearca s raspunda intrebarii: Face programul ceea ce trebuie ? , considernd numai specificaiile programului, nu i designul lui sau structurea de implementare. Fiind bazat pe specificaiile de program i nu pe cod, testarea funcional se mai numete i testare black-box (metod cutiei negre). Testarea funcional este n general tehnica de baza pentru proiectarea de cazuri de testare. Proiectarea de teste poate incepe ca parte a procesului de specificare a cerinelor i poate continua prin fiecare nivel de proiectare i de interfata a specificaiilor; este singura metod de testare care se poate aplic atat de devreme i atat de larg. n plus, testarea funcional este eficient n detectarea unor clase de defecte care de obicei trec de testarea white-box (sau glass box) sau de testarea bazat pe defecte (detaliate n capitolele urmatoare). Tehnicile de testare funcional se pot aplic pentru orice descriere a comportamentului programului, de la descrierea informal parial pn la descrierea formal, i la orice nivel de granularitare, de la un singur modul la ntregul sistem. De asemenea, proiectarea testelor n acest mod este mai ieftin i mai usor de executat de cat n cazut testrii white-box. n testarea i analiza aplicate n scopul verificrii (adic a descoperirii oricaror discrepante intre ceea ce face un program i ceea ce ar trebui s faca), trebuie fcuta referire la cerine, exprimate de de utilizatori, i specificate de inginerii software. O specificare funcional (adic o descriere a comportamentului esteptat al programului)este sursa primar de intormatii pentru czurile de test. Testarea funcional, cunoscuta i ca testare black-box (sau testare bazat pe specificaii) implic tehnici care creaza cazuri pentru testare derivate din specificaiile funcionale. n general, aceste tehnici produc specificaii pentru czurile de test care identifica anumite clase de teste, i care sunt instantiate pentru a produce teste individuale. Principiul care st la baza proiectrii cazurilor de test este partitionarea posibilelor comportamente ale programului intr-un numar finit de clase omogene, unde fiecare clasa poate fi considerata corecta sau incorecta. Practic, proiectantul de cazuri de test trebuie s formlizeze specificaiile suficient de mult, astfel incat acestea s poata servi ca baza de identificare a claselor de comportamente. Un avantaj al proiectrii de teste este acela ca scoate n evidenta slabiciunile i inconsistenta specificaiilor. Crearea de cazuri de teste funcionale este un proces analitic care descompune specificaiile n cazuri. Multitidinea de aspecte care trebuie luate n considerare n timpul testrii funcionae face ca procesul s fie predispus la erori. Chiar i proiectantii cu experienta pot omite cazuri importante de testare. O metodologie pentru proiectarea testelor funcionale ajuta la descompunerea design-ului de testare n pasi elementari. Astfel se poate controla complexitaea procesului i se pot separa activitatile umane de cele care pot fi automatizate. Uneori, testarea funcional poate fi complet automata. Este posibil atunci cand specificaiile sunt date sub form unui model forml (de exemplu, la un procesor de text, regulile gramaticale, sau starile n cazul unui automat). n aceste cazuri exceptionale, etapa de lucru efectiv are loc n simpul specificarii i proiectrii software-ului. Treaba proiectantului de teste se limiteaza la alegerea criteriilor de test, care definesc strategia de generare a specificaiilor cazurilor de test. n majoritatea cazurilor insa, testarea funcional este o activitate intensicv umana. Designer-ii trebuie s porneasca de la specificaiile informle scrise n limbaj natural i s le structureze astfel incat s identifice cazurile de test.[4], [1]
5.5. Testarea nefuncional Testarea nefuncional consta n testarea cerinelor nefuncionale alea produsului software. Se mai numete i testare structural. O cerinta nefuncional este un tip de cerinta care specifica criteriul ce poate fi folosit pentru a evalua operarea unui sistem, n locul unor comportamente specifice (cerinele funcionale definesc funcii i comportamente bine definite). Planul pentru implementarea cerinelor nefuncionale este detaliat n arhitectura sistemului. Cerinele nefuncionale sunt adesea numite calitati ale sistemului. Alti termeni care definesc acelasi lucru: constrangeri, atribute ale calitatii, scopuri ale calitati, cerine ne-comportamentale. Cerinele nefuncionale se impart n dou categorii: Calitate n executie, ca securitatea i usurinta n utilizare, care se poate observa n timpul rularii Calitati de evolutie, ca testabilitate, mentenabilitate, extensibilitate i scalabilitate, care sunt incluse n structura statica a produsului software.
Revenind la testarea nefuncional, aceasta include: testarea de compatibilitate, testarea de conformitate, de anduran, de incarcare, de localizare, de performan, de recuperare, de securitate, de scalabilitate, de stres, de utilizabilitate i testare de volum. [8] n continuare le vom detalia pe fiecare, prezentand caracteristicile fiecarui tip de testare.
5.5.1. Testarea de compatibilitate Acest tip de testare se aplic pentru a evalua compatibilitatea aplicaiei cu sistemul de calcul. Testarea unei aplicaii pentru compatibilitate poate deveni o sarcina foarte complicata. Exista multe sisteme de operare diferite, configuratii hardware i software, deci se ajunge la un numar imens de combinatii. Nu exista o cale ocolitoare pentru problema testrii compatibilitatii: aplicaia fie ruleaza cum a fost proiectata pe un anumit sistem de calcul, fie nu ruleaza deloc. Un mediu potrivit pentru acest tip de testare poate totusi usura acest proces i il poate face mai eficient. Clientul care cere dezvoltarea unei aplicaii ar trebui s menioneze toate sistemele de operare-tinta posibile pentru utilizatorul final (inclusiv sistemele de operare pentru servere, dac este cazul) pa care aplicaia trebuie s ruleze. Exista i alte cerine de compatibilitate care trebuie specificate: de exemplu, produsul de testat trebuie s ruleze cu mai multe versiuni de browsere web, cu dispozitive ca imprimante de toate felurile, sau cu alte componente software, ca programe de scanare antivirus sau procesoare de text. Compatibilitatea se poate extinde i asupra actualizarilor de la versiuni mai vechi de software. Nu numai sistemul trebuie s poata fi actualizat corect de la o versiune mai veche, trebuie luate n considerare i datele i alte informaii folosite n versiunile precedente (ca preferinte de setari. etc). Uneori, aplicaia mai trebuie s fie compatibila i n sens invers, adic datele prelucrate i salvate de versiunile anterioare trebuie s poata fi accesate de versiunea noua i invers (datele noi trebuie s poata fi deschise pe statii de calcul care au versiunea veche a aplicaiei). Acestea sunt situatii care trebuie luate n calcul cand se pune problema compatibilitatii. Data fiind diversitatea configuratiilor i potentialele probleme de compatibilitate, este probabil imposibil de testat fiecare permutare. Tester-ii trebuie s ierarhizeze configuratiile posibile n ordine, de la cele mai comune configuratii pnla cele mai rar intalnite (de exemplu, dac majoritate utilizatorilor folosesc Windows 7 i browser-ul Mozilla Firefox, aceasta configuratie ar trebui s fie prima n lista, punandu-se accent pe aceasta). Pentru alte configuratii mai rare, se pot impune limite de timp i cost i se pot face teste mai putn dure. Pe langa selectarea celor mai importante configuratii, tester-ii trebuie s identifice i cele mai potrivite cazuri de test i de date pentru aceasta testare. De obicei nu este fezabila rularea ntregului set de cazuri de test pe fiecare configuratie de test posibila (decat dac aplicaia este una mica), altfel ar dura prea mult timp. Deci, trebui selectat cel mai reprezentativ set de cazuri , care s confirme ca aplicaia funcioneaz corect pe o anumita platform.Pe langa acestea, tester-ii au nevoie i de date adecvate pentru testare, care s suporte acel set de cazuri de test. Este important actualizarea continua a cazurilor de test de compatibilitate i datele pe masura ce sunt descoperite probleme n aplicaie, nu numai n timpul dezvoltarii ei, ci i dupa livrare. Datele colectate de la utilizatori n cazul defectarii sunt o sursa buna de informaii pentru crearea i adaugarea de noi teste n suita de testare. Aceste date sunt utile i pentru determinarea celor mai potrivite configuratii pentru cre s se faca teste de compatibilitate (se poate ajunge la refacerea ierarhiei de configuratii folosita la testare). O alta sursa de informaii este programul lansat pentru beta-testing. Pentru a testa aplicaia ca la carte, trebuie re-creat mediul n care ea va opera la utilizatorul final. Pentru a indeplini aceste conditii, se instaleaz sistemul de operare, hardware-ul i configuratia software, i abia atunci se executa testele pe diferite set-up- uri. Cum pot exista nenumarate combinatii de setari, este cam scumpa achizitionarea masinilor pe care le-ar putea avea utilizatorii. De asemenea, reinstalarea aplicaiei pe fiecare ar dura prea mult pentru a fi o optiune viabila. O abordare mai fezabila implic utilizarea de hard-disk-uri care se pot demonta usor, n combinatie cu o unealta de gestiune a partitiilor. Astfel, pe un numar mic de masini, se poate testa un numar mai mare de configuratii. Tester-ul doar plaseaza discul care trebuie. Restarteaza masina i selecteaza configuratia dorita. Alta solutie este aceea de a folosi programe care creaza imagini diferite pentru hard-disk (ca Symantec GHOST). Astfel se creaza fisiere imagine pentru configuratiile necesare, care pot fi folosite oentru a recrea configuratia pe alta masina (sau chiar pe aceeasi) mai tarziu. Singurul dezavantaj este acela ca dureaza destul de mult timp refacerea configuratiilor pe masina tinta folosind fisierele imagine (depinde de dimensiune). n plus, i fisierele imagine sunt mari ca dimensiune, deci trebuie gasita o cale usoara (si compatibila pentru fiecare computer) de transport de pe o masina pe alta. Indiferent de tehnic folosita pentru a gestiona partitiile, odata ce s-a setat mediul necesar, testele pot fi rulate i se poate evalua compatibilitatea pe platform respectiva. Este important i modul de instalare al aplicaiei pe configuratia setat anterior. Este critica respectarea modului de instalare pe care il va folosi utilizatorul, folosind aceleasi versiuni de componente i aceleasi proceduri de instalare. Aceasta constrangere se respecta cel mai bine atunci cand un program de instalare este pus la dispozitie devreme n fluxul de proiectare, i software-ul este predat echipei de testare sub form instalabila, n loc de un pachet specializat. Dac o metod specializata sau manuala este folosita la instalare, este posibil ca mediul de test s nu reflecte mediul utilizatorului, i rezultatele testului de compatibilitate s fie imprecise. Este important s nu existe unelte de dezvoltare pe platform de test, pentru c ele pot interfera i mediu nu va mai fi atat de similar cu conditiile reale de operare.[7],[4],[5]
5.5.2. Testarea de anduran (soak testing) Acest tip de test se folosete pentru a determina dac o aplicaie face fata incarcarii de procesare siipastreaza comportamentul corect o perioada lunga de timp. n timpul testrii de anduran, se monitorizeaza atent consumul de resurse, mai ales memoria, pentru a observa potentialele defecte. De exemplu, un program poate funciona corect cand se testeaz 1 ora. Dar peste o zi, apar probleme, ca pierderi de memorie, care schimba comportamentul n mod nedorit. n timpul acestor teste se monitorizeaza i performan produsului. Observatiile inregistrate n timpul soak-testing-ului se folosesc pentru a imbunatatii parametrii elementului testat. De multe ori se urmrete ca parametrii s nu coboare sub un anumit nivel dupa funcionarea prelungita. Un sistem complet integrat trebuie s fie funcional continuu, saptamani (sau chiar luni) ntregi fr a se bloca/intrerupe.[9]
5.5.3. Testarea de incarcare (load testing) Testarea la sarcina consta n incarcarea aplicaiei cu cerine i masurarea rspunsului i parametrilor ei. Se aplic pentru a determina comportamentul unui sistem sub conditii normale de funcionare i n cazuri de supra-sarcina. Astfel se poate afla care este capacitatea maxima de operare a aplicaiei, dar i unde se afla punctele slabe (bottle-necks) care cauzeaza degradarea performntei. Uneori sarcina este pusa intentionat mult peste capacitatiile aplicaiei pentru a se observa tipul de erori care pot aparea i pentru a se crea solutii pentru ele (metode de scadere a incarcarii sau macar de semnalare a limitarii). n multe cazuri, n software, incarcarea inseamna acces concurent al mai multor utilizatori. Situatia n care relevanta acestui test este maxima se intalneste la aplicaiile multi-user, de tip client-server. Exista i alte tipuri de software care pot fi testate prin incarcare. De exemplu, un procesor de text sau un editor grafic pot fi fortate s citeasca un document extrem de mare, sau un program din domeniul bancar, caruia i se poate cere s genereze un raport folosind date distribuite pe mai multi ani. Cel mai precis test de sarcina este cel care simuleaza lucrul n conditii normale (la capatul opus se afla testele folosind modelarea teoretica sau analitica). Pentru un website, testarea de incarcare poate ajuta la determinarea calitatii serviciilor (QoS performnce) folosind comportamentul asteptat al clientului. Aproape toate uneltele de testare prin incarcare urmaresc principiul clasic de testare. Cand clientul viziteaza site-ul, un programel inregistreaza comunicarea i apoi creaza script- urile de interactiune asociate. Apoi, un generator de sarcina incearca s redea scripturile inregistrare, care pot fi modificate inainte de rulare, pentru a avea diferiti parametrii i a simula mai multi clienti. La re-rularea procedurii, se monitorizeaza i se colecteaza statistici hardware i software. Acestea includ starile procesorului, ale memoriei, operatiile de intrare-ieire ale discului pentru servere, timpul de rspuns, transferul sistemului de testat etc. La final, aceste statistici se vor analiza i se intocmeste un raport de testare la incarcare. Testele de sarcina analizeaza foarte precis aplicaiile care au fost proiectate pentru mai multi utilizatori, prin incarcarea lor cu un numar divers de utilizatori virtuali i reali i masurarea performntelor n acest conditii. Aceste teste se fac de obicei n medii identice (sau cat mai apropiate) cu cele reale. Exemplu: un site de tip magazin virtual. Se evalueaza funcionarea componentei care se ocupa de cosul de cumparaturi. De pild, trebuie s suporte 100 de accese concurente, de tipuri diferite: 25 de utilizatori virtuali (UV) se logheaza, se uita prin catalog i apoi se de-logheaza. Alti 25 se locheaza, adauga produse n cos, le cumpara i apoi pleaca. Inca 25 se locheaza, returneaza produsele cumparate anterior i pleaca, i inca 25 se logheaza pentru prima data (nu au alte activitati anterioare). Specificul unui plan de test sau script variaza n funcie de organizare. Pentur exemplul de mai sus primii 25 de utilizatori virtuali ar putea cauta produse unice, sau aleatoare, sau pot selecta dintr-un anumit set; depinde de planul de test dezvoltat anterior. Oricum ar fi, toate testele de incarcare vor s simuleze performntele pe o gama cat mai mare de varfuri de lucru. O credinta gresita este aceea ca uneltele de testare ofera doar inregistrare i redare (ca uneltele de testare prin regresie). De fapt, ele analizeaza intreaga stiva OSI (uneltele de testare prin regresie se axeaza pe performan interferei grafice). De exemplu, o unealta de regresie inregistreaza i reda un click pe un buton intr-un browser, dar o unealta de testare prin incarcare trimite hipertext-ul (html) pe care browser-ul il emite dupa ce utilizatorul apasa acel buton. Intr-un mediu multi-user, uneltele de incarcare pot trimite comenzi pentru mai multi utiizatori, ficare cu ID, parola, setari diferite.
Experienta utilizatorului la testul de incarcare
n exemplul de mai sus, 100 de utilizatori virtuali lucrau cu aplicaia de magazn virtual. Performan se masoara aici din punctul de vedere al utilizatorului. Aceasta descrevalueazaie cat de repede raspunde produsul software i cat de satisfcut este user-ul (cum percepe el performan).
Unelte de testare prin incarcare
- AppLoader: solutie de testare de performnte i de incarcare. Se testeaz la nivel de interfata grafica. Poate fi folosit i pentru testarea de unitate, de integrare i de regresie. - IBM Rational Performnce Tester: unealta de testare de scara larga, pe baza ed Eclipse. Se folosete n principal pentru executia unui numar foarte mare de teste pentru a masura timpul de rspuns al aplicaiilor pentru servere. - Apache Jmeter: aplicaie desktop Java pentru testarea de incarcare i masurarea performntelor. - LoadTest: verific funcionalitatea i performan sub sarcina. - LoadRunner: utilizata pentru executarea unui volum mare de teste concurente - OpenSTA (Open System Testing Arhitecture): aplicaie de test prin incarcare, open source. - SilkPerformer: testare de performnte intr-un model deschis i partajabil, care simuleaza un teste realistice de incarcare pentru mii de utilizatori, care ruleaza scenarii de afaceri. - SLAMD: open source, aplicaie web Java - Visual Studio Load Test: unealta inclusa n Visual Studio, care permite dezvoltatorilor s rulese un numar mare de teste cu o combinatie de configuratii care simuleaza incarcarea reala de la utilizator.
Testare de incarcare se poate face n 2 feluri: - testare de longevitate (sau de anduran, descrisa mai sus), care evalueaza abilitatea sistemului de a suporta o sarcina moderata, costanta, timp indelungat. - Testarea de volum, care supune aplicaia la sarcina maxima o perioada limitata de timp.[8]
Testarea de sarcina difera de testarea prin stres (care evalueaza modul n care produsul lucreaza sub sarcina extrema, peste cea maxima, specificata).[11]
5.5.4. Testarea de localizare Testarea de localizare este axata pe aspectele de interntionalizarea i de localizarea ale produsului software. Localizarea este procesul de adaptare a unei aplicaii globalizate pentru o anumita cultura. Pentru a localiza o aplicaie este nevoie de o intelegere de baza a seturilor de caractere i a problemelor asociate lor. Localizarea include i traducerea interfetei cu utilizatorul i adaptarea graficii pentru zona n care va fi distribuit produsul. De asemenea, i documentatia trebuie tradusa, inclusiv cea de ajutor (help menu). O atentie speciala trebuie acordata solutiilor pentru afaceri. Trebuie implementate corect procesele tipice practicii locale. Diferentele legate de desfasurarea afacerilor n anumite culturi sunt date de cerinele guvernamentale i legislative ale tarii respective, deci localizarea produselor destinate afacerilor poate deveni o sarcina dificila. Testarea de localizare evalueaza cat de bine este localizat produsul intr-o anumita limba-tinta. Acest test se bazeaza pe resultatele testrii globalizate, unde suportul funcional pentru o anumita tara a fost deja verifict (se compara cu acesta). Dac produsul nu este suficient de bine globalizat pentru a suporta o anumita limba, mai bine se evita localizarea n acea tara decat as apara probleme aditionale, care pot deveni greu de rezolvat (si cu costuri mai mari, pentru c, cu cat o problema este descoperita mai tarziu, cu atat solutionarea este mai scumpa). La livrare, producatorul trebuie s se asigura ca aplicaia funcioneaz corect pe piata pentru cre a fost proiectat. Mai jos sunt cateva puncte pe care trebuie s se puna accent la testul de localizare:
- Componente care se altereaza n timpul localizarii, ca interfata cu utilizatorul i anumite fisiere: - Sistemul de operare; - Versiuni de tastaturi (pentru fiecare limba, accente, diacritice, caractere speciale etc.); - Filtre de text; - Hot-key-uri (combinatii de taste); - Reguli de verificre a scrierii; - Reguli de sortare; - Trecerea de la litere mai la litere mici (si invers) pentru anumite cuvinte; - Imprimante; - Diverse dimensiuni ale hartiei pentru imprimat; - Mouse-ul; - Formtul de data; - Rigle i masuratori; - Disponibilitate de memorie; - Interfata vocala (accente) (unde este cazul); - Continut video;[8]
5.5.5. Testarea de performan Aceasta testare se folosete pentru estimarea comportamentului unui produs software, n privinta rspunsului i stabilitatii, sub o anumita sarcina. Este utila i pentru a investiga, masura, valida sau verific alte calitati ale sistemului, ca scalabilitatea, fiabilitatea i utilizarea de resurse. Testarea de performan este o categorie mai larga, car include alte subtipuri de testare, dintre care unele vor fi abordate n paragrafele urmatoare, iar altele au fost deja descrise: - Testare la sarcina: cea mai simpla form de testare de performan. Evalueaza comportamentul produsului la o anumita sarcina asteptata (exemplu: multiple tranzactii, accesuri multiple de la utilizatori etc.). Evidentiaza foarte bine bottle-neck-urile (gatuirile care limiteaza performntele). - Testarea de anduran (soak testing): pentru determinarea comportamentului aplicaiei la incarcare continua. Se urmrete gestionarea memoriei i degradarea performntelor n raport cu timpul (exemplu: timpul de rspuns pentru o aplicaie server- client, care nu trebuie s creasca peste o anumita valoare); - Testarea de stres (stress testing): se folosete pentru determinarea limitelor superioare ale capacitatii aplicaiei (pentru toti parametrii de masurat) i a robustetii ei la incarcare extrema; - Testarea n impulsuri (spike testing): dupa cum sugereaza i numele, se realizeaza print simularea cresterii brutse a numarului de utilizatori (acolo unde se aplic) i evaluarea comportamentului produsului. - Testarea n configuratie: este o alta varianta clasica a testrii de performan. n locul testrii performntei prin perspectiva incarcarii, se testeaz efectele schimbarii de configuratie din mediul programului asupta comportamentului i performntei. - Testarea de izolare: nu este un test unic de performan. Este mai mult un termen folosit pentru a denumi repetarea unui anumit test n scopul evidentierii defectului.
Scopurile testrii de performan: - Demonstreaza ca aplicaiaiatinge performantele cerute. - Poate fi folosita pentru compararea a dou solutii diferite. - Poate determina care componenta din produs sau din setul de date duce la comportamente neasteptate.
Conditii de test
n testarea de performan este important (si de cele mai multe ori i dificil) ca mediul de test s fie similar cu cel asteptat la funcionarea normala, insa nu este intotdeauna posibil n practica. Motivul este acela ca, n productie (adic n timpul funcionarii), sarcina de lucru are o natura aleatoare, si, dei sarcinile de test fac tot posibilul de a le imita pe cele reale, este imposibila replicarea exacta a variabilitatii din realitate. Implementarile arhitecturale slab legare au creat dificultati aditionale tester-ilor. Serviciile pentru intreprinderi au nevoie de testare coordonata (cu toti consumatorii care creaza volume de tranzactii similare cu cele din realitate) pentru a replica cat mai precis starile care apar n funcionarea reala. Din cauza costurilor, complexitatii i a constrangerilor legate de timp, majoritatea organizatiilor folosesc acum unelte care monitorizeaza i creaza conditii similare cu cele reale (denumite i zgomot) n mediile lor de test. Este critic pentru costurile de dezvoltare ca testele de performan s aiba loc cat mai repede. Cu cat un defect este descoperit mai devreme, cu atat este mai ieftn de remediat.
Mituri ale testrii de performan:
1. Testarea de performan este folosita pentru a defecta produsul Aceasta testare se face pentru a intelege punctul slab al produsului. Altfel, testarea sub conditii normale de funcionare se aplic (pentru a determina comportamentul sub sarcina asteptata de la utilizator). n funcie de cerine, se poate face i testare pentru pike-uri, anduran sau de stres. 2. Testarea de performan ar trebui fcut numai dupa testarea de integrare Dei asa se procedeaza de multe ori n industrie, testarea ed performan se poate face i n timpul dezvoltarii. Se numete testare timpurie de performan. Astfel, proiectarea se face cu cerinele de performan mereu n vedere; gasirea unui bug n performnte ar fi mai usor de remediat n etapele de dezvoltare decat dupa implementarea finala. 3. Testarea de performan implic numai crearea de script-uri i orice schimbare a aplicaiei se poate reflecta prin modificarea script-urilor. Procesul de testare este unul evolutiv. Dei scripting-ul este important, este doar una din componentele testrii de performan. Cea mai mare provocare pentru tester-ul de performan este aceea de a determina ce tip de test este necesar i de a analiza indicatorii de performan pentru a afla unde se afla bottle-neck-ul.[8]
5.5.6. Testarea de securitate Aceasta testare se aplic pentru a determina dac un produs software protejeaza datele sii mentine funcionalitatea. Exista 6 concepte de baza legate de cuvantul securitare n software: confidentialitate, integritare, autentificare, disponibilitate, autorizare i non-repudiere.
Taxonomie Termeni utilizati n securitare i explicatiile lor: - Descoperire= are scopul de a identifica serviciile folosite de acel produs software. Nu are sensul de descoperire a vulnerabilitatilor, ci doar o detectare a versiunii, care evidentiaza versiuni depasite de software vulnerabile la atacuri noi. - Scanare de vulnerabilitate = se cauta probleme cunoscute de securitate, folosind unelte automate pentru a crea conditiile pentru vulnerabilitatiile stiute. Nivelul de risc raportat este setat automat de unealta, fr verificre manuala sau interpretare. - Estimarea vulnerabilitatiilor = se folosete descoperirea i scanarea pentru a identifica vulnerabilitatile i de a plasa descoperirile n contextul mediului sub test. Exemplu: eliminarea pozitivelor false din raport i deciderea nivelului de risc pentru diecare descoperire. - Estimarea securitatii = construita peste estimarea vulnerabilitatii prin adaugarea de verificre manuala pentru confirmare. Nu include i exploatarea vulnerabilitatii. Verificrea are form accesului autorizat pentru confirmarea setarilor i implic examinarea fisierelor log, rspunsului, mesajelor de eroare, coduri etc. O estimare a securitatii vrea s obtina o acoperire cat mai mare a sistemelor testate, dar nu intra n specificul unei anumite vulnerabilitati. - Testarea de penetrare: simuleaza un atac al unui program rau intentionat. Implic exploatarea vulnerabilitatilor gasite pentru a obtine acces n continuare la aplicaie. Astfel tester-ii inteleg cum poate un atacator s castige acces la informaii confidentiale, s afecteze integritatea datelor sau disponibilitatea unui serviciu, i impactul actiunilor lui.
Confidentialitate inseamna ca datele i procesele trebuie protejate de publicare neautorizata. Integritatea este cerinta ca datele i procesele s fie protejate de modificare neautorizata.este o masura pentru asigurarea corectitudinii informaiei. Schemele de integritate folosesc de obicei aceleasi tehnologii ca cele pentru confidentialitate, dar implic adaugarea de informaii la o comunicare pentru a form baza unei verificri algoritmice, n locul codarii ntregii comuncari. Autentificarea se refera la confirmarea identitatii unei persoane, urmarirea sursei de provenienta a unei informaii sau asigurarea ca o masina sau un program este de incredere. Non-repudierea consta n asigurarea ca un mesaj transferat a fost trimis i receptionat de participantii la comunicare (si nu de altcineva). Este o cale de a garanta ca emitatorul unui mesaj nu poate nega emiterea acelui mesaj i receptorul nu poate nega receptia mesajului. Disponibilitatea este cerinta ca datele i procesele s fie protejate de atacuri de tipul refuz de acces pentru utilizatorii autorizati.[8]
5.5.7. Testarea de utilizabilitate Aceasta testare este o tehnic de evaluare a produsului prin testarea lui pe utilizatori. Ofera informaii directe despre cum folosesc utilizatorii reali aplicaia. Testarea de utilizabilitate se concentreaza pe masurarea capacitatii produsului de a indeplinii scopurile pentru cre a fost creat, si, mai precis, usurinta n utilizare Se poate spune ca primul test de utilizabilitate a avut loc n anii 40 i a fost efectuat de Henry Dreyfuss, care a proiectat cabinele pentru dou vase de croaziera (Independence i Constitution). Mai intai a construit cateva prototipuri i a adus mai multe persoane s locuiasca n ele. Astfel proiectantii si-au dat seama ca trebuie s puna intrerupatoarele pentru iluminat langa pat, ca oamenii s nu se loveasca n intuneric de alte obiecte, ca trebuie s lase spatiu pentru bagajele mari i alte astfel de lucruri care par marunte. Testarea de utilizabilitate este o metod de tip black-box. Scopul este acela de a observa cum folosesc oamenii produsul, unde apar erori, i cum se pot remedia acestea. Aceasta testare implic de obicei cum raspund subiectii n 4 zone de interes: eficient, precizie, amintiri i rspuns emotional. Rezultatele primului test sunt folosite ca baza, sau masuratoare de control. Celelalte teste pot fi comparate cu baza pentru a indica o imbunatatire. - Eficient: cat dureaza i cati pasi sunt necesari ca utilizatorul s indeplineasca o anumita sarcina; - Precizie: cate greseli fac oamenii, i cu ce consecinte - Amintiri: cat de usoriaminteste utilizatorul aplicaia, dupa o perioada n care nu a avut contact cu ea - Raspuns emotional: ce senzatii i s utilizatorului indeplinirea unei sarcini (stres, usurare, incredere) Pregtirea unui test de utilizabilitate implic proiectarea atenta a unui scenariu sau a unei situatii reaslistice, n care persoana executa o lista de sarcini folosind produsul de testat timp ce observatorii iau notite. Alte instrumente de testare, ca instruciuni din script-uri, prototipuri de pe hartie, i chestionare pre/post testare, sunt folosite pentru a obtine feedback n legatura cu produsul testat. Scopul este acela de a observa interactiunea cu utilizatorul, ce i place i ce il deranjeaza. Testarea prin metod holului este una din tehnici. n locul unei echipe angajate, specializate de testeri, sunt implicti doar 5 sau 6 oameni, alesi aleator, care s simuleze utilizatorul final. De aici vine i numele metodei, adic se iau niste oameni la intamplare de pe hol. Se folosesc oameni care nu au legatura cuproiectul, care nu stiu detaliile interioare ale acestuia. Este eficient mai ales n stadiile timpurii ale proiectrii design-ului, cand designerii cauta impasuri posibile n care se pot afla utilizatorii. n situatii n care evaluatorii, dezvoltatorii i utilizatorii se afla n locatii diferite (alte tari i alte fusuri orare), realizarea unui test n conditii de laborator poate fi o provocare serioasa. Astfel se ajunge i la evaluarea utilizabilitatii a distanta, utilizatorii i evaluatorii aflandu-se la mare departare unii de altii (atat spatial cat i temporal, adic fusuri orare diferite). Testarea la distanta poate fi sincrona sau asincrona. Metod sincrona implic video-conferinte i alte unelte de comunicare n timp real. n cazul metodei asincrone, evaluatorul so tester-ul lucreaza separat. Metodele asincrone includ urmarirea automata a click-urilor, fisiere log pentru incidente critice i feedback subiectiv. Ca un studiu de laborator, un test de utilizabilitate la distanta se bazeaza pe sarcini, i platform permite captura de click-uri i de alte activitati. Acest tip de test are loc n mediul utilizatorului, fapt care ajuta i mai mult la simularea folosirii reale. O alta metod de testare a utilizabilitatii este raportul expert. Se aduc experti cu cunotiinte extinse n domeniul utilizarii unui produs. Rapoartele expert pot fi fcute i automat, dar folosind programe carora li s-au impus anumite reguli pentru un design corect. Dei nu ofera atatea detalii ca un raport fcut de om, este mai rapid i mai ieftin. Este important i numarul de oameni care testeaz. n 1990, Jakob Nielsen propunea folosirea unui numar mare de teste, dar cu grupuri mici (de maxim 5 oameni). El considera ca dac 2-3 oameni nu se descurca usor intr-o anumita interfata grafica, nu are sens s observe i pe altii facand acelasi lucru. Argumentul lui a prmit i un suport matematic: U = 1 - ( 1 p ) n
U= numarul de probleme descoperite P= probabilitatea ca un utilizator s decopere o problema N= numarul de utilizatori ns exista i dezavantaje ale metodei lui Nielsen: - Din moment ce utilizabilitatea este legata de un set mic de testeri, un esantion asa de mic nu este reprezentativ pentru intreaga populatie, deci rezultatele vor fi mai mult legate de esantionul testat decat de populatia pe care o reprezinta (legea numerelor mari) - Problemele de utilizabilitate nu sunt toate la fel de usor de descoperit, deci cele ascunse pot incetini procesul.
Nielsen nu se oprea la un singur test cu cei 5 utilizatori. Dupa testare i decoperirea problemelor, acestea erau remediate pe loc i se faca un nou test cu alt grup. Astfel a observat ca obtinea rezultate mai bune decat dac facea un singur test cu 10 oameni. n practica, testele se fac odata sau de 2 ori pe saptamana n timpul dezvoltarii, folosind grupuri de 3-5 oameni, iar rezultatele se livreaza n cursul a 24 de ore designer-ilor. Se poate ajunge la un numar total de 50 pnla 100 de subiecti care au testat programul n timplu ciclului de dezvoltare. n primele etape, n care probabilitatea de a descoperi probleme serioase este mai mare, se pot folosi subiecti cu orice grad de inteligenta. n urmatoarele etape, se aleg subiectii cu abilitati intr-o gama mai larga. S-a bservat ca cei cu experienta nu au avut deloc problema la nici unul din teste, n timp ce incepatorii intalneau mai multe obstacole. n urmatoarele etape, se recruteaza testeri din populatia tinta (carora le este destinat produsul software).[8]
5.6.Concluzii
Dupa cum se poate vedea, testarea software reprezint o investigaie dirijat n scopul de a obine informaii legate de calitatea produsului software, prin rularea programului n scopul de a descoperi bug-uri software. Este o etap puternic dependent de contextul operaional n care programul va fi folosit. Testarea nu ofera garantia c produsul funcioneaz corect n orice condiii ci numai n acele condiii pentru care a fost testat. Astfel alegerea dintre modalitatile de testare folosite este esenial pentru acoperirea unei game ct mai largi de posibile erori. Informaia obinut n urma testrii este esenial pentru remedierea defectului respectiv. n momentul n care se detecteaz o eroare, este posibil s nu se cunoasc i cauza care a generat acea eroare. Programatorul este cel care trebuie ca dup detecia erorii s identifice pe baza acesteia instruciunea sau secvena de instruciuni care a dus la apariia erori. Numai dupa remedierea defectelor se poate trece la etapa urmatoare de dezvoltare a produsului software.
Bibliografie - [1] Elfriede Dustin: Effective Software Testing - 50 Specific Ways to Improve Your Testing - [2] Paul Ammann, Jeff Offutt: Introduction To software testing - [3] Dan Pilone, Russ Miles: Head First Software Development - [4] Mauro Pezzand, Michael Young: Software testing and Analisys: Process, Principles and Techniques - [5] Kshirasagar Naik, Priyadashi Tripathy: Software Testing and Quality Assurance - [6] Gerald D. Everett, Raymond McLeod Jr: Software Testing: Testing Across the Entire Software Development Life Cycle - [7] Glenford J. Myers: The Art Of Software Testing, 2nd Edition (2004) - [8] www.wikipedia.com - [9] www.informit.com - [10] www.calsoftlabs.com - [11] www.searchsoftwarequality.techtarget.com - [12]www.integrant.com - [13] www.nresult.com
IV. Verificarea i validarea produselor software
Tic Andra Maria
1. Introducere Prin activitile de verificare i validare se urmrete ca software-ul s satisfac specificaiile sale in timpul fiecrei faze a ciclului su de dezvoltare. Se asigur faptul ca fiecare articol software s fie verificat de o persoan diferit de aceea care l-a produs i c efortul de verificare i validare este adecvat pentru ca fiecare articol software s fie operaional. Obiectivul activitilor de verificare i validare este de a reduce erorile software la un nivel acceptabil. Efortul necesar poate reprezenta 30-90% din totalul resurselor proiectului, in functie de complexitatea i gradul de risc al funcionrii necorespunztoare a software-ului. Organizarea activitilor de verificare i validare este inclus in activitile de management ale proiectului software. Verificarea asigur c produsul este construit in concordan cu cerinele, specificaiile i condiiile stabilite in etapele de proiectare i standardele in vigoare la momentul punerii pe pia a acestuia. Este un proces de control al calitii folosit la evaluarea conformitii i se desfasoar concomitent cu dezvoltarea software-ului respectiv, fiind de cele mai multe ori un proces intern.[1],[9] Verificarea inseamn stabilirea i documentarea faptului c articolele referitoare la software, procesele i serviciile sunt in conformitate cu cerinele specificate. Validarea asigur utilizabilitatea produsului pe piaa. Este procesul de a evalua un sistem sau o component in timpul sau la sfritul procesului de dezvoltare pentru a determina dac satisface cerinele specificate. Validarea este un proces extern de asigurare a calitii. [1],[9] Diferena dintre verificare i validare este important numai pentru teoreticieni. In practic, verificarea i validarea se refer la toate activitile care asigur c software-ul va funciona conform cerinelor. [1] Validarea poate fi clasificat astfel: Validare in perspectiv activitaile desfurate inainte ca noi articole s fie lansate pentru a se asigura caracteristicile de interes care intrunesc standarde de funcionare corecte si sigure. Validare retrospectiv proces pentru articolele deja in uz, distribuie sau producie. Se reia evaluarea specificaiilor i ateptrilor de la produs, iar daca lipsesc date se sisteaz etapa curent. Acest proces se realizeaz dac se constat lipsa realizrii unei validri de perspectiv, la schimbarea unor legislaii sau standarde, la repunerea pe pia a unor produse anterior excluse. Validare curent are loc concomitent cu procesul de proiectare/dezvoltare.[1] Activitile de verificare includ recenzii si verificri formale. Scopurile verificrii sunt acelea de a demonstra ca programul este corect (dac metoda i programul permite) i de a gsi erori. Verificarea este consistent dac un sistem raportat corect se dovedete a fi corect i complet, dac prin metoda respectiv se poate determina corectitudinea fiecrui sistem. Detecia de erori este consistent cnd erorile raportante sunt reale i complet cnd s-au gsit toate erorile. [2] Metodele de verificare pot fi: Statice, cnd se verific fr execuia codului i aici se inscriu analiza de fluxuri de date si verificarea formal. Dinamice, cnd se execut codul: rulare pe maina virtual, execuia simbolic.
2. Recenziile (Reviews) de software sunt reprezentate de intlniri pe parcursul crora un produs este examinat de personalul care s-a ocupat de proiect, manageri, utilizatori, clieni sau alte pri interesate s comenteze sau s aprobe. [3] Clasificare: - Recenzii de la egal la egal, realizate de autorul proiectului sau de mai muli colegi din echipa respectiv, cu scopul evalurii coninutului tehnic i al calitii muncii depuse. o Recenzia codului examinarea sistematic a codului surs. o Programare in echip doi programatori dezvolt impreun un produs software la aceeai staie de lucru. o Inspecii se urmrete o procedur strict de depistare a defectelor. o Walkthrough autorii organizeaz pentru toate parile interesate o prezentare a proiectului, participanii avnd oportunitatea s afle rspunsuri, s sesizeze defecte sau neconcordane. o Recenzii tehnice o echipa format din personal calificat examineaz dac produsul este adecvat pentru uzul destinat i identific discrepane cu standarde i specificaii. - Recenzii la nivel de management, realizate de reprezentani ai nivelului managerial al intreprinderii pentru a evalua activitatea curent i pentru a lua decizii referitor la desfurarea urmtoarelor etape ale proiectului. - Audituri, realizate de personal din exteriorul proiectului pentru a evalua conformitatea produsului cu specificaiile, standardele i acordurile contractuale iniiale.[3] Procedura IEEE 1028, [3], pentru formalizarea recenziilor definete un set de activiti bazate pe procesul de inspecie al lui Michael Fagan, dezvoltat pentru prima dat la IBM. Paii urmtori sunt obligatorii: 0. Coordonatorul recenziei folosete o list standard de criterii de intrare care asigur condiiile optime pentru succesul intregului proces. 1. Organizarea: invitarea personalului, informarea acestuia referitor la topic-ul review-ului, a locaiei i a orei, asigurarea materialelor i dispozitivelor pentru buna desfaurare a intlnirii. 2. Planificarea: coordonatorul identific i confirm obiectivele intlnirii, organizeaz o echip care s realizeze discuia. 3. Recapitularea procedurilor: asigurarea faptului c toi participanii ineleg scopul acestei dezbateri. 4. Pregtirea individual: fiecare parte a echipei se pregtete pentru dezbaterea de grup, examinnd atent potenialele defecte luate in discuie. 5. Examinarea de grup: are loc intlnirea propriu-zis cu toi participanii unde sunt expuse rezultatele individuale cu scopul ajungerii la un consens. 6. Aplicarea deciziilor: autorul produsului impreun cu echipa sa repar defectele pentru a satisface cerinele exprimate in timpul intlnirii. Se verific satisfacerea tuturor cerinelor. 7. Sfritul evalurii: coordonatorul verific finalizarea cu succes a intregului proces.
Avantajul organizrii acestei recenzii este c se pot identifica probleme mult mai ieftin dect dac identificarea acestora s-ar face in etapa de testare (proces de detectare a erorilor). Mai mult, ele ofer oportunitatea autorilor tehnici de a inva s dezvolte documentaie cu o marj de eroare foarte redus, putnd astfel s identifice din timp i s renune la aspecte ale proiectului care pot duce la detectarea ulterioar de defecte. Vorbim aici de un proces de prevenire a apariiei defectelor.[3] Recenziile de cod constau in verificarea codurilor i inlturarea defectelor de ctre membrii echipei proiectului. Un defect este reprezentat de un bloc de cod care nu este implementat conform cerinelor, care nu funioneaz dup intenia programatorului sau care nu este incorect dar poate fi perfecionat. Pe lng faptul c inltur bug-urile, aceast tehnic este de asemenea benefic pentru dezvoltatorii inceptori care pot inva in aceasta manier noi modaliti de programare.[3] Inspeciile sunt cele mai folosite in proiectele software. Scopul inspectorilor este ca acetia s ajung impreun la un consens asupra unui produs i s aprobe utilizarea acestuia in cadrul proiectului. Scopul principal al inspeciei este identificarea defectelor. [4] Spre deosebire de restul recenziilor, walkthrough-urile au ca obiective familiarizarea audienei cu coninutul proiectului i obinerea de rspunsuri despre calitatea tehnic i despre coninuntul documentaiei acestuia. [5]
Planificare Recapitulare Aplicare Dec\\ Intlnire Pregtire Finalizare 3. Verificrile formale sunt modalitile prin care se aprob sau dezaprob corectitudinea algoritmilor care stau la baza unui sistem pe baza unor specificaii sau proprieti, folosind metode formale, matematice. Deoarece sistemul este modelat matematic, sunt posibile rezultate garantate in limitele posibilitilor/presupunerilor de modelare. [8] Verificrile formale sunt foarte folositoare la demonstrarea corectitudinii sistemelor software exprimate prin codul lor surs. Acest tip de verificare const in furnizarea unei dovezi formale asupra corectitudinii algoritmului pe baza modelrii matematice abstracte a sistemului, corespondena dintre modelul matematic i natura sistemului fiind cunoscute din etapa conceptual. Verificarea formal pentru software cunoate mai multe abordri: Abordarea tradiionala a anilor `70 cnd codul este mai inti scris si apoi dovedit a fi corect intr-o etapa separat. Programare scris in mod dependent, cnd scrierea codurilor se face concomitent cu verificarea corectitudinii acestora. [8]
3.1. Model checking Metoda model checking const in explorarea sistematic si exhaustiv a modelului matematic. Acest lucru este posibil att pentru modelele finite ct i pentru cele infinite unde seturile infinite de stri pot fi reprezenate in mod finit prin abstractizare. De obicei aceast metod const in explorararea tuturor strilor i tranziiilor din model, utiliznd tehnici de abstractizare pe domenii, care consider grupuri intregi de stri intr-o singura operaie, reducnd astfel timpul de calcul. Implementarea tehnicilor include enumerarea spaiului de stri, a spaiului simbolic de stri, interpretarea abstract, simularea simbolic i rafinarea abstract. Proprietile care vor fi verificate sunt descrise in logica temporal, precum LTL- linear temporal logic si CTL- computational tree logic. [9] Aceast metod rezolv urmatoarea problem: dndu-se modelul unui sistem, se verific dac acesta indeplinete o anume specificaie dat. Pentru a rezolva aceast problem dupa un algoritm, modelul sistemului i specificaiile acestuia vor fi formulate intr-un limbaj matematic precis: se verific dac o structur dat satisface o formul logic dat. Model checking-ul este un automat cu stri finite. Spre deosebire de verificarea prin demonstrare de teoreme, aceast metoda nu necesit o anotare a programului de ctre utilizator, verificarea fcndu-se automat pentru toate execuiile posibile, in caz de eroare generndu-se un contraexemplu. Se urmeaz urmtorii pai: Se face specificarea proprietilor i traducerea ei in limbajul C. Programul original este instrumentat. Deoarece programul poate fi complex, se folosete abstracia in verificare, adic se dorete concentrarea asupra poriunii relevante din program. Acest lucru se realizeaz prin tehnica program slicing - se determin fragmentul de program care afecteaz o anumita proprietate a programului. Se genereaz programul boolean pornind de la predicatele din specificaie. Se analizeaz programul boolean: se calculeaz mulimea strilor atinse. Dac se depisteaza erori se vor genera contraexemple i noi predicate: o Dac contraexemplul este realizabil, atunci eroarea este real. o Altfel, se pleac din nou din starea de eroare in programul abstract i se parcurge calea de eroare inapoi pn cnd se gsete o inconsisten. Dup aceea se genereaz predicatele corespunztoare. Se regenereaz programul boolean i se reia verificarea.
3.2. Inferena logic O alt abordare este reprezentat de inferena logic care const in folosirea unei versiuni formale a unui raionament matematic. Se folosesc de obicei teoreme precum HOL, ACL2, Isabelle, Coq. Aceste teoreme sunt aplicate parial automat i sunt conduse de inelgerea de ctre utilizator a sistemului de validat. Instrumentele mai noi precum Perfect Developer i Escher C Verifier incearc s automatizeze complet procesul. Logica liniar i cea temporal poate de asemenea fi folosit la inferena logic i nu numai in cazul model checking-ului. 3.3. Derivarea de program O alta metoda este reprezentata de derivarea de program, cnd producerea de cod eficient se face plecnd de la specificaiile funcionale i se urmeaz o serie de pai cu rolul de a conserva corectitudinea. Formalismul Bird-Meertens respect aceste principii, fiind considerat ca o alt form de verificare concomitent cu construirea codului.
3.4. Verificarea prin demonstrare de teoreme se realizeaz prin folosirea unui demonstrator de teoreme, plecnd de la anumite condiii de verificare. [10] In anul 1967, in lucrarea sa intitulat Atribuirea de sensuri programelor, Robert W. Floyd spunea c o baz adecvat pentru definirea formal a sensurilor programelor trebuie sa fie in aa fel inct s stabileasc un standard riguros de dovezi. Mai mult, el pleac de la ideea c dac valorile iniiale ale variabilelor programului satisfac relaia R1, atunci valorile finale vor satisface relaia R2. Astfel, scopul lucrrii sale era s formalizeze semantica limbajelor de programare. [8],[10] Lucrarea lui Floyd dezvolt reguli generale pentru combinarea condiiilor de verificare i reguli specifice pentru diferitele tipuri de instruciuni. Se introduc invarianii pentru raionamentele despre cicluri i se trateaz terminarea folosind o masur pozitiv de descrcare. Metoda introdusa de Floyd poart numele de metoda anotrii unui program cu aseriuni: - Condiia de verificare: se consider o formula Vc(P,Q) astfel inct dac P este adevrat inainte de a se executa c, atunci Q este adevrat la ieire. - Cea mai verificabil consecin: avem un program i consideram o condiie iniial. Dup execuia programului aceasta va fi cea mai puternic proprietate valabil. Aceste aseriuni au fost exprimate in logica predicatelor de ordinul I. Mai trziu, in anul 1969, Floyd a conceput impreuna cu Hoare ceea ce se numeste logica Floyd-Hoare sau regulile lui Hoare. Acesta este un sistem formal cu un set de reguli logice pentru rationarea riguroas asupra corectitudinii programelor. Ei au avut ca punct de plecare lucrarea lui Floyd. [6],[10] In aceast lucrare au tratat precondiii i postcondiii pentru execuia unei instruciuni, folosind notaia de triplet Hoare care pune mai clar in eviden relaia dintre instruciune i cele doua aseriuni. De aceast dat au lucrat cu programe textuale i nu cu scheme logice. Cele doua notaii de triplet Hoare: Corectitudinea parial: {P} S {Q} dac S este executat intr-o stare care satisface P i execuia lui S se termin, atunci starea rezultant satisface Q. Corectitudinea total: [P] S [Q] daca S este executat intr-o stare care satisface P , atunci execuia lui S se termin i starea rezutant satisface Q. Regulile lui Hoare sunt definite pentru fiecare tip de instruciune in parte, prin combinaia lor putndu-se raiona programe intregi: Axioma declaraiei goale: { } { } P sare peste P - declaraia sare peste nu schimb starea programului aa c tot ceea ce este adevrat inainte de sare peste va fi adevarat i dup. Axioma pentru atribuire: { [ / ]} : { } P E x x E P = . Aici [ / ] P E x denot expresia P in care toate apariiile variabilei x au fost inlocuite cu expresia E. Aceast axiom afirm faptul c adevrul lui { [ / ]} P E x este echivalent cu adevrul dupa asignare al lui {P}. Astfel, cnd { [ / ]} P E x este adevrat inainte de asignare, atunci {P} este adevrat dup asignare i dac{ [ / ]} P E x este fals inainte de asignare atunci {P} va fi de asemenea fals. Ex: {x=y-2}x:=x+2{x=y} in rezultat, x=y, substituim x cu expresia atribuit, x+2 i se obine x+2=y de unde x=y-2. Aceast axiom nu se aplic atunci cnd mai multe nume refer aceeai valoare stocat. Ex: {y=3}x:=2{y=3}. Regula de compunere sau de secveniere: { } { },{ } { } { } ; { } P S Q Q T R P S T R - se aplic programelor executate secvenial S i T, unde S se execut inaintea lui T. Ex: Pentru S: {x+1=43}y:=x+1{y=43} i T: {y=43}z:=y{z=43}, atunci {x+1=43}y:=x+1;z:=y{z=43}. Regula de decizie: { } { },{ } { } { } { } B P S Q B P T Q P if BthenS elseT endif Q . . . Regula consecinei: ` ,{ } { }, ` { `} { `} P P P S Q Q Q P S Q
Regula ciclului cu test initial while: { } { } { } { } P B S P P while BdoS done B P . . , unde P este testul iniial. Regula ciclului cu test iniial while pentru corectitudine total: ,{ } { } { } { } is well founded P B t z S P t z P while BdoS done B P < . . = . < . . In continuare, in 1975, E.W.Dijkstra a reformulat regulile lui Hoare in lucrarea sa intitulat Guarded commands, non-determinancy and formal derivation of programs. Spre deosebire de Hoare i Floyd a cror logic este prezentat ca un sistem deductiv, semantica transformrii bazata pe predicate a lui Dijkstra este o strategie complet pentru a reduce problema verificrii tripletului Hoare la demonstrarea unei legi logice de ordinul intai (concluzionare pe baza unui predicat considerat adevrat). [7],[10] Abordarea lui Dijkstra folosete operatorul weakest precondition. Astfel, pentru o instruciune S i o postcondiie dat Q pot exista mai multe precondiii P astfel inct {P} S {Q} sau [P] S [Q]. Dijkstra calculeaz o precondiie necesar i sufiecient wp(S,Q) pentru terminarea cu succes a lui S cu postcondiia Q. Wp este un transformator de predicate care permite definirea unui calcul cu astfel de transformri. [7],[10] Preconditiile lui Dijkstra: Salt peste (skip): wp(skip,R)=R. Renun la (abort): wp(abort,R)=false. Atribuire o Var1: wp(x:=E,R)= y, y=E =>R[x<-y], unde y este o nou variabil care stocheaz valoarea final a variabilei x. o Var2: wp(x:=E,R)=R[x<-E]. Prima variant evit o potenial replicare a lui E in R, pe cnd a doua variant este mult mai simpl, deoarece avem o singur apariie a lui x in R. Secveniere: wp(S1;S2,R)=wp(S1,wp(S2,R)). Condiionare: ( 1 2 , ) ( ( 1, )) ( ( 2, )) wp if EthenS elseS elseend R E wp S R E wp S R = . . Bucla while: ( , ) , (( ) ( , ))[ ] , (( ) )[ ] wp while EdoS done R I y E I wp S I x y x y y E I R x y = . . . < . .
Y este un tuplu nou de variabile. Prima formul inseamn c invariantul I trebuie s ramn neschimbat. A doua inseamn c S (corpul buclei while) trebuie s pstreze invariantul i s micoreze variantul: aici variabila y reprezint starea iniiala a blocului de execuie. Ultima formul inseamn c R trebuie s fie stabilit la finalul buclei while. In concluzie, la verificarea prin demonstrare de teoreme se urmeaz paii: Se scriu tripletele Hoare sau precondiiile Dijkstra. Se verific inlnuirea acestora cu un demonstrator de teoreme sau cu o procedur de decizie.
4. Concluzii [8],[11]
Metodele formale fac posibile inelegerea i punerea in discuie a problemelor, descoperirea contradiciilor, prin notaii clare i precise. Ele sunt o modalitate prin care se verific pri de o importan major din programe cu ajutorul unui studiu abstract, deoarece notaiile matematice au o semantic precis care poate fi ineleas intr-un context internaional, inlturnd ambiguitile.
V. Concluzii Fiecare etap care are loc este puternic dependent de etapele realizate anterior. Astfel anumite etape nu pot fi realizate dect n urma finalizirii alteia (ex: Proiectarea nu poate s nceap decat dup finalizarea analizei). n plus nu exist o divizare temporal exact a acestora, ele putnd s se suprapun (ex: Documentarea se face pentru fiecare etap n parte). Astfel etapele nu pot fi tratate independent. De asemenea, fiecare etap trebuie s respecte anumite reguli pentru a putea fi considerat de calitate. Asigurarea calitii duce la minimizarea complexitii produsului i deci la o mai bun organizare a sa, oferind posibilitatea de a obine un produs performant. Nerespecterea regulilor de calitate poate duce la realizarea unui produs neperformant, la realizarea lui la costuri mult prea ridicare sau chiar la nefinalizarea acestuia.