Testarea Automata A Componentelor Software DIN Cadrul Echipamentelor Multimedia

TESTAREA AUTOMATA A COMPONENTELOR SOFTWARE DIN CADRUL ECHIPAMENTELOR MULTIMEDIA

NOȚIUNI FUNDAMENTALE

Necesitatea testării

„În ultimii ani, industria software a cunoscut o răspândire spectaculoasă. În zilele noastre au mai rămas foarte puține mecanisme sau facilități care nu sunt controlate prin software, sau nici măcar nu conțin elemenete software. În industria automotive de exemplu, de la motor la transmisie și înapoi la frâne, tot mai multe funcționalități sunt controlate de microprocesoare și soft-urile aferente acestora. De aceea, se poate afirma că software-ul este un element esențial pentru funcționaliatea dispozitivelor și a industriei. Deasemenea, funcționarea armonioasă a unei companii sau organizații, depinde de fiabilitatea oferită de sistemele software folosite pentru sprijinirea proceselor de afaceri sau anumitor sarcini specifice. Viteza prin care o companie reușeste să introducă un nou produs, depinde în mare parte de viteza necesară ajustării sau chiar extinderii sitemului informatic.”

Testarea este întregul proces prin care, sistematic, se execută programe pentru a demonstra implementarea corectă a cerințelor specificate pentru un produs, pentru a crește încrederea în acesta și pentru a detecta erori.

Orice utilizare a unui obiect de test cu scopul de a-l examina este considerată testare. Condițiile ce se doresc a fi îndeplinite trebuie sa se regăsească bine definite sub forma specificațiilor. La sfârșitul testului se va găsi tot timpul un rezultat, comportamentul actual., acesta se va compara cu comportamentul așteptat și se va lua decizia dacă obiectul testat a trecut sau nu testul.

Testarea software are diferite scopuri, toate la fel de importante și la fel de necesare. Numai prin combinarea acestora se poate realiza un produs de calitate:

Se testează pentru a se găsi erori

Se testează pentru a verifica calitatea

Se testează pentru a câstiga încredere

Se analizează programul sau documentația pentru a preveni defectele

Testarea contribuie la îmbunătățirea calității produsului, nu va putea fi realizat niciodată un produs performant și de caliatate fără a fi testat. Un produs testat corespunzator va fi perceput de client la aceleași performanțe ca cele rezultate în urma testării.

Calitatea ridicată a unui produs software nu este îndeplinită doar eliminând erorile care apar în timpul testării. La calitatea produsului contribuie și: funcționalitatea, eficiența, portabilitatea, mentenabilitatea, încrederea și accesul la utilizare pe care le oferă acesta.

În ultimii 40 de ani, s-au acceptat ca norme generale în munca de testare următoarele principii:

Testarea arată prezența defectelor, nu absența lor – testarea poate demonstra că un produs nu îndeplinește cerințele, adică există defecte, în schimb nu poate dovedi că un produs este lipsit de defecte. Chiar dacă nu sunt găsite erori în timpul testării, aceasta nu e o dovadă a inexistenței acestora. Testarea corespunzătoare reduce probabilitatea ca defecetele ascunse să fie prezente în obiectul de testat.

O testare completă nu este posibilă – un test complet, în care s-ar lua în calcul toate valorile posibile pentru toate intrările și combinațiile acestora, considerând deasemenea toate precondițiile posibile, este imposibil de realizat. Ar fi necesar un număr astronomic de cazuri de testare, din această cauză, fiecare test este întotdeauna doar o mostră. Efortul de testare trebuie să fie controlat, luându-se în considerare prioritățile și riscurile.

Este indicat ca activitățile de testare să înceapă cât mai curând posibil – aceasta contribuie la găsirea timpurie a defectelor, alături de concentrarea testării pe obiective bine definite. Se dă astfel ocazia de a rezolva într-un stadiu incipient erorile apărute. Costurile necesare corectării defectelor crește odată cu timpul în care ele se află în sistem. Astfel, prin detectarea erorilor într-un stadiu incipient, se va reduce costul necesar corectării acestora. (1)

Defectele tind să se grupeze împreună – adesea, majoritatea defectelor se găsesc în doar câteva părți a obiectului de testat. Defectele nu sunt distribuite în mod egal, dar au tendința de a fi grupate. Astfel, dacă mai multe defecte sunt detectate într-un singur loc, nu este exclus ca și altele să apară în jurul acestora. Acest principiu trebuie privit cu flexibilitate.

Paradoxul „Pesticidelor”- în cazul în care aceleași teste sunt repetate obsesiv, tind să-și piardă din eficiență. Defectele nedetectate anterior, rămân nedescoperite. Astfel, pentru a menține eficiența testelor și pentru a lupta cu acest paradox al „pesticidelor”, este necesară dezvoltarea de teste noi în permanență. Prin testarea părților software ce nu au fost acoperite anterior vor fi descoperite noi defecte.

Testarea este dependentă de context – trebuie să se adapteze la riscurile inerente ce apar datorită mediului în care va fi folosit produsul. Prin urmare, nu există două sisteme ce ar trebui testate în exact același mod. Pentru fiecare sistem în parte, criteriile de testare ar trebui decise în mod individual, în funcție de mediul în care va fi acesta utilizat.

Sistem fără eroare echivalent cu sistem util – concluzie erontă – găsirea defectelor și repararea acestora nu garantează că sistemul în ansamblul său va îndeplini așteptările și nevoile utilizatorilor. Implicarea timpurie a utilizatorilor în procesul de dezvoltare și utilizarea prototipurilor sunt măsuri preventive ce pot fi luate pentru a evita o astfel de problemă.

Pentru a răspunde la întrebarea „de ce este necesară testarea”, s-au scos în evidență următorii factori:

Importanța economică a software-ului este de necontestat – funcționalitatea mașinilor și a echipamentelor, depinde direct de acesta. Este imposibil de imaginat sisteme mari de telecomunicații, finanțe sau de control trafic, care să nu funcționeze cu ajutorul software-ului.

Calitatea software-ului a devenit unul dintre factorii determinanți ce fac un succes dintr-un produs și sistem commercial sau tehnic.

Testarea este necesară pentru îmbunătățirea calității software-ului – prin testare corespunzătoare se asigură atât un produs de calitate cât și un proces de dezvoltare software ridicat.

Etapele procesului de testare

Testarea într-un proces software de dezvoltare înseamnă mai mult decât executarea testelor. Include mai multe procese ce se urmăresc sau se suprapun. Fiecare fază de testare are loc concomitent cu o fază din procesul de dezvoltare software.

Pentru a fi mai ușor de integrat în întregul proces de dezvoltare software, s-a realizat o structură mai detaliată pentru sarcinile de testare ce trebuie îndeplinite. Ceea ce înseamnă că va fi necesar să se împartă sarcinile de dezvoltare în subsarcini mai mici și mai ușor de urmărit: planul de testare și controlul, analiza și design-ul testării, implementarea și executarea testelor, evaluarea criteriilor de oprire/raportarea și închiderea activităților de testare.

Figura 1. Etapele procesului de testare

Planul de testare:

O sarcină atât de extinsă precum testarea necesită o planificare atentă. Această planificare începe cât mai curând posibil în proiectul software și este influențată de politica organizației, de domeniul de aplicare a testelor, obiective, riscuri și constrângeri. În planificarea activităților pot fi incluse:

Definirea și abordarea generală a strategiei pentru testare

Decizia cu privire la mediul de testare

Definirea nivelurilor de testare, precum și coordonarea, respectiv integrarea activităților de testare împreună cu celelalte activități de testare.

Selectarea metricii pentru monitorizarea și controlul activității de testare, precum și definirea criteriilor de ieșire.

Se determină cât de bine pregătită trebuie să fie documentația, pentru a se putea decide șabloanele.

Se scrie planul de testare și se iau deciziile asupra ce, cine, când și câtă testare este necesară.

Se estimează efortul și costurile necesare testării; se (re)estimează și se (re)planifică sarcinile de testare.

Analiza și design-ul testării:

Pentru a realiza acestea e necesar să se cunoască urmatorele:

Datele de test – datele existente în sistem înainte de a fi executat testul. Aceste date afectează sau sunt afectate de componentele sistemului supus testării.

Datele de intrare – variabilele ce sunt citite de o componentă (acestea pot fi stocate în interiorul sistemului sau în afara acestuia).

Rata de acoperire a testului – reprezintă media prin care un obiect specificat a fost exercitat printr-o suită de teste, deseori aceasta se reprezintă în procente. În principiu, se folosește testarea white box pentru a determina rata de acoperire a codului.

Oracolul de testare – o sursă ce determină rezultatul așteptat de sistemul supus testării: referințe către rezultate anterioare ale testului, manualul utilizatorului sau prin cunoștințe specializate. N-ar trebui să se folosească codul dezvoltat ca sursă pentru oracol.

În această etapă se revizuiesc bazele testării: specificațiile, arhitectura sistemului, design-ul și interfețele. Se identifică și se prioritizează totodată condițiile de testare, bazate pe: analiza obiectelor supuse testării, specificațiilor testării și pe baza comportamnetului și structurii software-ului.

Se crează și se ordonează testele în funcție de nivel: teste pozitive ce dovedesc funcționalitatea și teste negative, ce verfică tratarea situațiilor în care apar erori.

În această etapă se face și design-ul mediului de test: se hotărăște domeniul de disponibilitate și operațiile executate, inclusiv administrarea utilizatorului. Se încarcă seturile de date și parametrii sistemului.

Deasemenea se realizează infrastructura testării, se defines procesele, preocedurile și responsabilitățile, și dacă este cazul, se aleg instrumentele necesare testării.

Implementarea și executarea testelor:

În această etapă se execută următoarele acțiuni:

Se finalizează, implementează și proritizează testele, prin identificarea datelor de test.

Se dezvoltă și se prioritizeză procedurile de test, prin crearea de date de test și dacă este necesar prin scrierea scenariilor automate de testare.

Se crează suite de test din procedurile de test, eficientizându-se astfel executarea testelor.

Se verfică mediul de testare, totodată se verfică și se actualizează trasabilitatea (se verifică dacă testele îndeplinesc cerințele specificate de client)

Executarea testelor se face manual sau automat, urmărindu-se secvențele de test specificate în planul de testare.

Rezultatele testelor sunt înregistrate pentru a putea fi mai târziu analizate. Se înregistrează, deasemenea, versiunea de software folosită și versiunea instrumentului de testare

Se compară rezultatele actuale cu cele așteptate.

Se raportează și se analizează diferențele dintre acestea pentru a stabili cauza apariției incidentului: codul scris, datele de test sau documentația. După ce o corectură a fost facută, se repetă activitățile de testare pentru a confirma corectura.

Testele de regresie se execută pentru a asigura că o schimbare (după instalarea unei noi versiuni de software, sau după corectarea unui defect) nu a introdus alte defecte noi sau nu a descoperit unele ce nu erau vizibile până la introducerea corecturii.

Evaluarea criteriilor de oprire si raportarea:

Principalele sarcini în această fază de testare sunt:

Evaluarea execuției testelor cu obiectivele definite și evaluarea jurnalului de înregistrări rezultat în urma execuției testelor (rezumatul activităților de testare, rezultatele testelor, comunicarea criteriilor de ieșire).

Tot aici se furnizează informații pentru luarea deciziei: dacă mai este necesar să se execute încontinuare și alte teste.

Închiderea activității de testare:

Se strâng datele din toate activitățile de testare încheiate, pentru a consolida experiența, procesul de testare, datele și numerele. În această etapă se închid rapoartele cu incidente, tot aici, se pot ridica solicitări de modificare pentru orice punct rămas în discuție.

Se verifică prin planul de livrare, ce a fost testat și livrat.

Se documenteaza criteriile de aceptanță ale sistemului.

Se finalizează arhitectura testării, mediul de test și infrastructura testării, pentru a putea fi refolosite ulterior.

Se analizează “lecția învățată”, pentru proiecte viitoare.

Se utilizează informația acumulată, pentru a îmbunătății maturitatea testării.

În concluzie, procesul de testare poate fi împărțit în diferite etape:

Planificarea testării – acoperă activitățile ce defines abordarea necesară pentru toate fazele testării, după cum și planificarea resurselor.

Design-ul testării (specificațiile) – acoperă design-ul testelor și rezultatele așteptate de acestea.

Executarea testelor – include definirea datelor de test, executarea testelor și compararea rezultatelor.

Evaluarea și raportarea testării – acoperă evaluarea criteriile de ieșire și înregistrarea rezultatelor testelor într-o formă scrisă.

Concluzia testării – se închid rapoartele incidentelor apărute și este dezvoltată “lecția învățată”.

Controlul testării – constă în controlarea activităților ce acoperă toate fazele enumerate mai sus dintr-un proces de testare.

Modele de testare

Pentru ca efortul necesar dezvoltării de software să fie controlat și structurat, se folosec diferite modele și procese de dezvoltare software. Există multe astfel de modele, fiecare dintre ele definind o cale sistematică pentru o derulare ordonată a muncii dintr-un proiect. De obicei, se definesc fazele proiectului și pașii de design. Acestea trebuie completate cu un rezultat documentat. O fază este considerată încheiată atunci când documentele cerute sunt completate în conformitate cu criteriile de calitate stabilite. Într-un proiect, modelul de dezvoltare definește sarcinile colective și obligatorii ce trebuie îndeplinite de fiecare persoană implicată, în ordine cronologică.

Testarea apare în fiecare din aceste modele, dar cu înțelesuri diferite și sub diferite forme. Mai jos, vor fi scurt prezentate câteva modele, din punctul de vedere al testării.

Modelul Waterfall – testarea văzută ca elemental final de inspecție. Acesta a fost primul model fundamental, este impresionant de simplu și foarte cunoscut.

Un nivel de dezvoltare va fi inițiat numai după ce anteriorul său a fost finalizat. În acesta este permisă existența unor bucle de feedback între nivele adiacente, doar dacă este necesară o revizure într-un nivel anterior. Cel mai mare dezavantaj al acestui nivel este faptul că testarea este înțeleasă ca o acțiune ce se execută o singură dată, la sfârșitul proiectului, chiar înainte de lansarea acestuia. Testarea este văzută ca “inspecție finală”, o analogie cu o inspecție industrială, înainte de predarea produsului către client.

Figura 2. Modelul Waterfall

Modelul general V – ideea de bază a acestui model este considerarea ambelor sarcini, de dezvoltare și testare, activități echivalente și la fel de importante. Cele două ramuri ale literei “V” simbolizează aceasta. Ramura stângă reprezintă procesul de dezvoltare, în timpul căruia este gândit gradual design-ul sistemului și implementarea acestuia ca pas final. Ramura dreaptă reprezintă procesele de integrare și testare, aici, elementele programului sunt adăugate succesiv pentru a forma un subsistem mai mare (integrare) și vor fi testate totodată.

Integrarea și testarea sunt elementele care finalizează faza de acceptare a întregului sistem dezvoltat.

Figura . Modelul general “V”

Elementele din ramura stângă sunt aceleași ca cele din modelul Waterfall:

Requirments definition: definirea cerințelor clientului, aici sunt stabilite și aprobate.

Functional system design: cerințele clientului sunt mapate în funcționalități și dialoguri ale noului sistem.

Tehnical system design: design-ul implementării sistemului. Aici sunt incluse definirea interfețelor și descompunerea sistemului în subsisteme mai simple și mai ușor de înțeles (arhitectura sistemului). Fiecare din aceste subsisteme, va putea fi dezvoltat individual mai târziu.

Component specification: se definesc toate subsistemele împreună cu sarcinile acordate fiecăruia, comportamentul, structura internă și interacțiunea cu alte subsisteme.

Programming: fiecare componentă specificată (modul, unitate sau clasă) este implementată într-un limbaj de programare.

În timp ce se avansează în aceste nivele, sistemul software este descris în detaliu tot mai mult. În cazul în care se fac greșeli în această construcție, cel mai simplu mod de a le găsi este de a le căuta în nivelul de abstractizare pe care sunt produse. Astfel, ramura din dreapta modelului „V” definește câte un nivel de testare corespunzător pentru fiecare nivel de construcție.

Component test: verifică dacă fiecare componentă software funcționează corect, după cum este specificat în cerințe.

Integration test: verifică dacă grupurile de componente colaborează între ele după modul în care este specificat în design-ul tehnic al sistemului.

System test: aici se verifică dacă întregul sistem îndeplinește cerințele.

Acceptance test: verifică îndeplinirea cerințelor, după cum a fost specificat în contract, din punctul clientului de vedere.

Cu fiecare nivel de test, trebuie să se verifice dacă rezultatul dezvoltării îndeplinește cerințele specificate, sau cerințele ce sunt relevante pentru nivelul specific de abstractizare. Acest proces, de verficare a rezultatelor dezvoltării conform cu cerințele originale se numește validare.

TESTAREA APLICATIILOR SOFTWARE IN DOMENIUL AUTOMOTIVE

Mediul automotive

In timpul secolului 20, automobilul a devenit principalul mod de transport. Acum, in secolul 21 acestea au devenit sofisticate si in continuă dezvoltare. Ingineria automotive este un domeniu vast de studiu care face posibilă această tehnologie si inovație. Ingineri auto de azi sunt specialiști care studiază o gamă variată de subiecte, care includ aerodinamică, în caz de accident, de manipulare, de generare de energie electrică și de suspendare.

Utilizând calculatorul și software-ul avansat, inginerul auto poate modela un întreg automobil și apoi simula comportamentul vehiculului. Prin schimbarea de componente întregi, cum ar fi motoare, frâne, suspensii, anvelope și transmisii, inginerul poate evalua eficient modul în care aceste modificări ar putea afecta performanțele și siguranța vehiculului. Inginerii folosesc, de asemenea, calculatoarele din mașini în sine pentru a controla diverse aspecte ale proiectului.

Ințelegerea noastră de tehnologie auto este în continuă expansiune și din ce în ce mai complexă. Inginerii auto și știința de inginerie auto va fi în fruntea eforturilor de integrare a energiei electrice și pentru a îmbunătăți siguranța, performanțele și economia de combustibil în anii următori.

Figura 4. Evolutia automotive

MontaVista

Odată cu explozia de smartphone-uri, tablete și aplicații, cererea clientului în piața de automobile de îmbunătățire a părții multimedia a cauzat nevoia de un software de Infotainment în vehicul pentru a se potrivi sau o depășească pe cea a pieței de dispozitive mobile.

Figura 5. Utilitzate MontaVsta

Există o nevoie de grafică de înaltă performanță și capacitatea de multimedia, conectivitate la Internet prin WiFi sau 3G/4G, suport Bluetooth, conectivitate USB, mass-media și de gestionare a muzicii, contacte de management, e-mail și browser de internet și servicii de localizare GPS. MontaVista construieste și livreaza aceste elemente pe Linux de peste un deceniu. S-a folosit aceasta experienta pentru a crea o platforma automotive (MV ATP: Automotive Technology Platform) bazata pe Linux fiind un software compatibil GENIVI pentru piata auto.

Figura 6. Structura MontaVista

Abordarea acestei platforme este de a face disponibila o tehnologie care evoluează cu noi caracteristici potrivite pentru demo-uri concept care servesc drept un punct de plecare avansat pentru soluțiile personalizate.

Soluțiile actuale de Infotainment au nevoie de o valoarea de software ridicata, ce sa contina componente personalizate, pentru care calitatea si securitatea sa fie de necontestat. O companie nu trebuie să facă doar dovada că are experiență și durabilitate pentru a furniza și a sprijini un client în aceste cerințe stricte, acesta trebuie să aibă și capacitatea de a oferi servicii profesionale de a lucra alături de furnizori și OEM-uri (OEM = Original Equipement Manufacturer) pentru a construi soluția finală.

Capacitatea de a livra la scară largă soluții personalizate cu management global de proiect este o fundație critică a lui MontaVista in domeniul automotive. MontaVista are un mare grup de ingineri și manageri de proiect care au cunoștințe pe mai multe discipline necesare pentru a furniza servicii de design personalizat în faza de proiectare și dezvoltare. Nivelul oferit de MontaVista asigură că soluția ta va fi livrată pentru a satisface cerințele stricte de calitate din piața auto. Odată construit și implementat, MontaVista oferă sprijin pe termen lung pentru nevoile clientului, asigurându-i ca produsele ii sunt susținute de suport de clasă mondială pentru un deceniu sau mai mult.

Figura 7. Structura MontaVista

Comunicare D-Bus

D-Bus este sistem de comunicare bazat pe mesaje, o metodă prin care aplicațiile comunică una cu cealaltă. D-Bus vine cu un daemon (pentru evenimente cum ar fi adaugarea unui nou dispozitiv hardware) si un daemon per user (pentru comunicarea generală intre procese). Magistrala de mesaje este creată pe baza unui canal de comunicare unu la unu, pe care oricare doua aplicatii o pot folosi să comunice direct (fara a mai trece prin daemonul de mesaje). Cele mai multe sisteme implementează un canal de sistem privilegiat, si unul privat pentru fiecare user logat, astfel incât informația de pe D-Bus poate fi restricționată.

D-Bus lucrează cu socket-uri de Unix intre aplicație si daemon (aplicațiile comunică una cu cealaltă printr-un proces derivat din D-Bus Daemon).

Arhitectură

D-Bus are 3 straturi arhitecturale:

libdbus – o librărie care permite ca două aplicații să se conecteze intre ele si sa schimbe mesaje

dbus-daemon – un daemon executabil pentru magistrala de mesaje, construit in libdbus. La acestă magistrală se pot conecta mai multe aplicații. Daemon-ul poate transmite mesajele de la o aplicație catre 0 sau mai multe aplicatii.

Librarii wrapper bazate pe anumite aplicații.

Design

Designul D-Bus se adresează la doua cazuri:

comunicarea intre aplicații desktop in aceași sesiune permitând integrarea sesiunii desktop ca un intreg.

comunicarea intre sesiuni desktop si sistemul de operare, cel din urmă conținând de obicei kernelul și orice alt sistem daemon sau proces.

Mecanism

Orice aplicație care foloseste D-Bus conține obiecte care de obicei se conectează la obiecte C++ sau Python. Fiecare obiect D-Bus operează mai degrabă ca o instanță decât ca un tip. Mesajele primite pe conexiunea D-Bus sunt conectate cu un anumit obiect si nu cu aplicația ca un intreg.

Automatizarea procesului testarii

Testarea automată inseamnă automatizarea execuției testelor sau a anumitor proceduri de verificare. In zilele noastre această implică automatizarea de task-uri care sunt dificil de executat manual, cum ar fi testarea impotriva regresiilor sau de performanță.

Un factor important il reprezintă o buna arhitectură a sistemului. Aceasta defineste și inoiește librăriile de test. Având decizii consistente în ceea ce privește dimensiunea testelor, convențiilor prvitoare la denumirea datelor de test, interacțiunii cu mediul de testare. Astfel se pot crea blocuri de testare ce pot fi refolosite de catre tool-urile folosite.

Testele automate sunt programate pentru a verifica alte programe. Deci, ca orice alt software, nivelul de complexitate și timpul necesar pentru a-l invața inseamnă că se doreste a se avea o documentație despre modul de funcționare si arhitectură. Testarea automata se dorește doar în contextul unei afaceri reușite, astfel incât se scurtează perioada de verificare, se reduce efortul manual sau acoperă anumiti factori de calitate in coparație cu testarea manuală.

Automatizarea testarii se preteaza pentru testele de verificare atunci cand proiectul este intr-un stadiu avansat de dezvoltare, cand gradul de stabilitate al acestuia este foarte ridicat. Nu se doreste automatizarea unor teste care verifica spre exemplu imagini de pe ecran prin compararea lor cu referinte pre-salvate, iar acestea se modifica in fiecare saptamana, deasemenea nu se doreste automatizarea unui sistem nu tocmai stabil care poate ramane blocat dupa anumite actiuni, logica necesara implementarii unui test automat care sa ia in calul toate posibilele situatii de blocaj nu merita efortul. Factorul uman este mult mai potrivit in acest stadiu pentru a face testele de verificare.

In schimb, testele de integrare sunt foarte potrivite automatizarii in stadii incipiente de proiect. In situatiile in care sistemul este instabil, testarea la nivelul interfetelor, sau bazate pe verificarea output-ului prin trace-uri este poate singura metoda de testare a codului. Aceste teste se doresc automatizate, pentru ca e mai usor pentru utilitar sa urmareasca trace-uri pre-stabilite decat pentru operatorul uman.

FRAMEWORK PENTRU TESTAREA AUTOMATA

Concept

In lucrarea de fata se face un studiu asupra introducerii automatizarii intr-un proces de testare in domeniul Automotive. Se pune accent pe automatizarea testarii intr-un proiect ce se afla intr-un stadiu incipient de dezvoltare.

Dupa o analiza a stadiului sistemului multimedia, s-a hotarat ca o automatizare a testelor de verificare ar fi ineficienta, in conditiile in care componentele sunt instabile, nu au toata functionalitatea expusa, iar interactiunea cu celelalte componente nu este complet implementata. In schimb, s-a vazut un adevarat castig in implementarea testelor de integrare, ce sa verifice la limita de functionalitate a componentei, astfel incat sa se elimine dependenta de celelalte.

Fiind un sistem Linux based, in care componentele comunica prin D-Bus, s-a hotarat ca am putea implementa testele de integrare, daca:

Am avea interfetele componentei expuse public

Am gasi un tool de testare automata ce sa permita concetarea la sistem, sa apeleze metodele expuse de interfete si a monitorizeze semnalele emise de aceasta

Am putea pregati echipa de preintegrare astfel incat sa creeze aceste teste automate, urmarind arhitectura componentei

Daca resursele consumate pentru implementarea primelor 3 puncte se vor dovedi a fi o buna investitie in viitor

Testarea automata – costuri, riscuri si beneficii

Costuri

In ceea ce privește costul se iau în calcul costul inițial și costul recurent.

Costul inițial include următoarele:

evaluarea și selectarea tool-ului potrivit. Multe companii încearcă să treacă peste acest aspect, dar plătesc mai târziu pentru aceasta.

cumpărarea tool-ului, adaptarea unuia open source sau dezvoltarea unui tool propriu.

invățarea too-lului pentru a fi folosit corect. Aceasta include mai multe costuri în vederea acumulării de cunoștiințe și a documentării arhitecturii de testare automată.

integrarea tool-lului cu procesul de testare existent, alte tool-uri și cu echipa de verificare.

Figura 8. Automatizarea în ansamblu

Costurile recurente includ următoarele:

mentenanța tool-ului și a scripturilor de test. De obicei scripturile trebuie reînoite fiind consumatoare de timp.

suportarea taxelor de licență.

instruirea personalului costă în cazul unor modificari.

portarea testelor spre platforme noi.

extinderea funcționalitațiilor cu aplicații și cerințe noi.

Riscuri

Cel mai mare risc poate fi considerat faptul că testele manuale existente pot fi incomplete sau incorecte. Dacă acestea stau la baza verificării automate testarea este ineficientă și consumatoare de timp. Trebuie verificate in detaliu testele manuale înainte de a lua decizia automatizării lor pentru că este mult mai scump să se rezolve aceste probleme mai târziu.

Un alt risc des întâlnit este acela că scripturile de test sunt greu de menținut. De fiecare dată cand software-ul care trebuie verificat suferă modificări, testele automate trebuie revizuite. Din această cauză trebuie acordată o atentie sporită designului care trebuie să fie robust și modular.

După o perioadă de folosire a testelor automate se observă, de obicei, o scădere a randamentului de găsire a defectelor, deoarece echipa se concentrează pe menținerea scripturilor de test. Automatizarea este utilă în creșterea încrederii, abordarea regresiilor si repetarea testelor de multe ori. Cu toate acestea explorarea naturală care apare atunci cand se execută testele manuale nu se regăsește în scripturi. Trebuie asigurat un mix adecvat între testarea automată și cea manuală.

Beneficii

Beneficiile reprezintă motivul pentru care acceptăm costurile și riscurile automatizării. Companiile investesc foarte mult în dezvoltarea testelor automate cu scopul de a avea recompense repetate fără a investi prea mult efort în mentenanța de pe parcurs. Se acordă o atenție sporită asupra testelor ce se doresc a fi automate, alegându-se doar acelea care aduc un benficiu și in viitor. O abordare gresită, care din pacate este vizibilă in multe companii, este aceea de a automatiza toate testele existente chiar dacă nu se pretează în timp.

Principalele beneficii sunt acelea de a reduce timpul, efortul și o acoperire mai bună a specificațiilor. Pe langă acestea automatizare aduce o mai buna prezicere a timpului de executare. Aceste teste pot fi lăsate să ruleze peste noapte, iar in timpul orelor de program se analizează datele. De asemenea oferă o incredere noilor funcționalități ale software-ului prin rularea testelor de regresie. Astfel se poate analiza riscul introducerii acestora.

Automation Test Platform

Automation Test Platform (ATP) este un utilitar de testare creat petru departamentul Multimedia din cadrul companiei Continental. Scopul acestei aplicații este de a face disponibil un mediu generic pentru interfetele publice testate prin:

– definirea formatului in care se scriu intrăriile și ieșirile

– crearea unui mecanism de a conduce sistemul/aplicația ce se doresc a fi verificate

– executarea de teste

– raportarea rezultatelor

Arhitectura ATP-ului:

Figura 9. Structura ATP

Raportarea conține toate testele, atât cele care au un rezultat pozitiv cât si cele cu rezultat negativ. Testele sunt descrise explicit pană la pași de testare. In acest mod raportul de livrare poate fi interpretat și de persoane care nu sunt implicate tehnic in testare.

Figura 10. Raportare teste

Interfata grafica

Zona de editare este folosită pentru scrierea pașiilor de test, testelor și a suitelor de test stocate in fișiere XML.

Figura 11. Interfata ATP – editare teste

Zona de rulare a testelor permite utilizatorului să execute teste și sa vizualizaze executarea rezultatului current.

Figura 12. Interfata ATP – rulare teste

Zona de raportare afișează rezultatele referitoare execuții:

Figura 13. Interfata ATP – raportare teste

Zona de log-uri stochează log-urile aplicației. Acestea sunt inregistrate doar când testele rulează. De asemenea dacă se rulează mai multe teste log-urile se adaugă astfel ăncat pot fi investigate ulterior.

Figura 14. Interfata ATP – memorare log-uri

Test automat

Dupa ce s-a decis ca tool-ul de testare automata existent poate fi adaptat astfel incat sa fie folosit intr-un proiect nou, pentru realizarea testelor de integrare, s-a cerut updatarea acestuia cu o noua librarie ce se contina pasi ce de apelare a metodelor expuse pe DBus si monitorizarea semnalelor emise:

Dupa ce un serviciu este vizibil pe DBus, acesta isi expune obicetele, ce pot fi:

– metode: caracterizare prin posibiliatea de apelare, si prin faptul ca returneaza ceva (semal sau cod de eroare)

Figura 15. Metodele

semanale: mesajele returnate in urma evenimentele

Figura 16. Semnalele

Dupa modelul de mai sus au fost creati pasi de test in noua librarie care sa contina pasi ce permit apelarea metodelor si pasi ce permit asteptarea dupa anumite semnale o perioada, sau pasi pentru testarea negativa, care sa monitorizeze o perioada de timp sa vada ca un anumit semnal nu este emis.

Analiza modului de functionare

Pentru a putea creea framework-ul necesar dezvoltarii testelor s-a studiat mai intai arhitectura sistemului, dupa care s-a continuat cu studiul arhitecturii modulului suspus testarii.

In figura de mai jos sunt reprezentate pachetele software functionale dintr-un sistem software implementate intr-un sistem multimedia al unui automobile.

Se observa interactiunea dintre module si stratificarea acestora in functie de nivelul la care sunt folosite. Avem in partea de sus nivele superioare: Video, HMI si Graphics, acestea vor putea fi experimentate de utilizatorul final, ele fiind singurele vizibile. Dupa care exista nivelele de logica pentru toate celelalte componente software (Media, Audio, Radio, Navigation, etc). Nivelul SSW, este cel care asigura comunicarea intre module, este creierul sistemului, cel care ia decizia: “cine/ce/cand”, acesta comunica si cu nivelul inferior, cel al Sistemului de Operare.

Figura 17. Diagrama functionala a sistemului software

Dependenta modulelor una de celalalta este reprezentata mai jos. Se observa si aici cum modulul de Sistem Software este cel de care depind toate celelalte module.

Figura 18. Tabelul dependintelor

In continuarea lucrarii vom pune accentual pe componenta Radio a sistemului, deoarece pentru aceasta a fost implementat framework-ul de testare automata. Din tabel se observa dependintele acesteia de HMI, Media, Audio si SSW.

Fiecare modul, componenta software, respecta urmatoarea structura:

Figura 19. Structura componentelor SW

HMI Presentation: include partea grafica a HMI-ului: redarea ecranului, stratificare, widget-uri, animații și logica ecranului.

HMI Logic: include conversia logica de la un eveniment HMI catre apelarea unei functii la nivelul aplicatiei logice

Application Logic: are rol dublu: va implementa caracteristiceile specifice pe care le doreste un client si care nu sunt oferite de Middleware, totodata va face lucrurile mai usoare pentru HMI, deoarece ridica nivelul interfetei Application Framework atunci cand aceasta nu este potrivita si nu poate fi interpretata de HMI

Application Framework: ofera infrastructura de baza pentru a construi aplicatii

Middleware: asigura generitatea functionalitatilor pentru fiecare domeniu suportat

Infrastructure: furnizeaza serviciile de baza ale sistemului

OS: sistemul de operare

Drivers: SW folosit pentru a sprijini si abstractiza nivelele superioare de SW de componentele HW

Interactiunea componentei Radio cu celelalte componente

Componenta Radio comunica cu cea de AppFramework, ce este parte a componentei de SSW in realizarea use case-urilor de Create, Stop, Resume, Pause, ConFigura etc.

Figura 20. Diagrama comunicarii intre Radio si SSW (AppFramework)

Cel mai general caz de interactiune a componentei de Radio este pentru use case-urile de baza: setare de banda, setare de frecventa, search, search accelerated. Cursul urmat este astfel: comanda vine de la utilizator prin componenta de HMI (Human Machine Interface), ajunge la aplicatia de Radio, care o proceseaza si trimite comenzi mai departe catre modulele de Audio si Radio Services pentru a executa comanda in nivelele inferioare.

Figura 21. Comunicare intre Radio, HMI si Audio

Pentru ca unele informatii a modulului Radio trebuie sa fie afisate si pe cluster-ul masinii, exista o componenta speciala a SSW, Export Component, ce monitorizeaza semanalele emise de Radio pentru a le putea afisa pe Cluster atunci cand Radio este cerut de utilizator sa fie sursa curenta.

Figura 22. Comunicare intre Radio, HMI si SSW (ExportComponent)

Modulul de Radio interactioneaza cu cel de Navigation pentru a putea oferi utilizatorului logo-ul aferent tarii statiei ascultate. Logo-urile sunt salvate intr-o baza de date, iar de fiecare data cand modulul Navigation afla ca s-a schimbat tara va anunta si modulul de Radio pentru ca acesta sa schimbe log-urile afisate.

Figura 23. Comunicare intre Radio, HMI si Navigation

Se doreste ca sistemul sa implementeze si recunoasterea vocala. Pentru aceasta, modulul Radio trebuie sa poata raspunde la comenzi ce vin din modulul Speech. Use case-urile implementate prin comenzi vocale au fost: tunare de frecventa, schimbarea benzii, salvarea unei statii in memorie, rechemarea unei staii din memorie etc.

Figura 24. Comunicare intre Radio, HMI si Speech

Datorita complexitatii sistemului si interactiunii modulelor s-a constat ce e foarte dificil sa se tezteze o functionalitate complet: modulele faceau implementarea pe rand, o problema dintr-un modul putea sa afecteze intreaga functionalitate ce se dorea testata. O alta problema era izolarea problemei: dupa ce aceasta era descoperita, era foarte dificil sa se gaseasca modulul ce a generat-o, avand in vedere ca erau implicate cate 4 sau 5 module intr-o functionalitate.

Pentru a rezolva acestea s-a hotarat implementarea unui framework care sa inlocuiasca toate modulele, mai putin cel supus testarii cu adaptoare. Aceste adaptoare au rolul de a inlocui exact functionalitatea originala dar sa aduca in plus posibilitatea de monitorizare a semnalelor trimise de modulul supus testarii catre adaptoare si posibilitatea de apelea metode din acestea.

Deoarece Radio este modulul supus testarii s-au creat adaptoare pentru urmatoarele: Audio, Cluster, RadioPlugin, LifeCycle, Navigation si Speech. Modelul urmat in implementarea acestora a fost simetric, efortul cel mai mare a fost consumat pentru implementarea primului adaptor.

Script-uri automate

Dupa implementarea adaptoarelor a aparut o nevoie de imbunatatire: adaugarea si scoaterea din sistem automat a adaptoarelor, in functie de necesitatile testarii.

Folosind shell scripting-ul s-au automatizat aceste operatiuni. Inlocuirea serviciilor originale cu cele de test oferite de adaptoare si vice versa. Deoarece pasii ce trebuiau urmati erau identici, pentru a nu se pierde timpul cu executarea lor manuala de fiecare data cand se dorea inlocuirea lor s-au creat script-uri automate pentru fiecare modul.

Audio script:

#!/bin/sh

#functions

installAudioATP()

{

INSTALL_PATH="/usr/lib/ovip/Radio/AudioATP"

${INSTALL_PATH}/IAudioWatcherCollector &

#remove original Audio Qt plugin

servicefw –system remove AudioServicesPlugin

#add AudioATP plugin

servicefw –system add ${INSTALL_PATH}/IAudioWatcherATP.xml

echo "install finished"

}

uninstallAudioATP()

{

export QT_PLUGIN_PATH=/usr/lib/ovip/AppFwk/Core:/usr/lib/ovip/AppFwk/Domains:/usr/lib/ovip/UIFramework

PLUGIN_PATH="/usr/share/ovip/AppFwk/Audio"

echo "uninstall called"

#remove old Audio Qt plugin

servicefw –system remove AudioServicesPlugin

#add AudioATP plugin

servicefw –system add ${PLUGIN_PATH}/AudioServicePlugin.xml

ps -ef | grep IAudioWatcherCollector | awk '{print $2}' | xargs kill

echo "uninstall finished"

}

if [ "$#" -eq 1 ]; then

ARG="$1"

fi

if [ "$ARG" = "-install" ]; then

echo $ARG

installAudioATP

fi

if [ "$ARG" = "-uninstall" ]; then

echo $ARG

uninstallAudioATP

fi

Cluster script:

#!/bin/sh

#functions

installClusterATP()

{

INSTALL_PATH="/usr/lib/ovip/Radio/ClusterATP"

echo "install called"

#start ClusterServer

${INSTALL_PATH}/ClusterServer &

#remove original Cluster Qt plugin

servicefw –system remove AppExportComponentService

#add ClusterATP plugin

servicefw –system add ${INSTALL_PATH}/ClusterRadioCommands.xml

}

uninstallClusterATP()

{

echo "uninstall started"

export QT_PLUGIN_PATH=/usr/lib/ovip/AppFwk/Core:/usr/lib/ovip/AppFwk/Domains:/usr/lib/ovip/UIFramework

PLUGIN_PATH="/usr/share/ovip/AppFwk/Ssw/Export"

echo "uninstall called"

#remove old Audio Qt plugin

servicefw –system remove AppExportComponentService

#add AudioATP plugin

servicefw –system add ${PLUGIN_PATH}/AppExportComponentService.xml

ps -ef | grep IAudioWatcherCollector | awk '{print $2}' | xargs kill

echo "uninstall finished"

}

if [ "$#" -eq 1 ]; then

ARG="$1"

fi

if [ "$ARG" = "-install" ]; then

echo $ARG

installClusterATP

fi

if [ "$ARG" = "-uninstall" ]; then

echo $ARG

uninstallClusterATP

fi

Radio Plugin script:

#!/bin/sh

#functions

installITunerATP()

{

INSTALL_PATH="/usr/lib/ovip/Radio/RadioPluginATP"

echo "install called"

#remove original Speech Qt plugin

servicefw –system remove RadioServicesPlugin

#add SpeechATP plugin

servicefw –system add ${INSTALL_PATH}/ITunerWatcherATP.xml

}

uninstallITunerATP()

{

echo "uninstall started"

export QT_PLUGIN_PATH=/usr/lib/ovip/AppFwk/Core:/usr/lib/ovip/AppFwk/Domains:/usr/lib/ovip/UIFramework

PLUGIN_PATH="/usr/share/ovip/AppFwk/Radio"

echo "uninstall called"

#remove old Audio Qt plugin

servicefw –system remove RadioServicesPlugin

#add AudioATP plugin

servicefw –system add ${PLUGIN_PATH}/RadioServicesPlugin.xml

echo "uninstall finished"

}

if [ "$#" -eq 1 ]; then

ARG="$1"

fi

if [ "$ARG" = "-install" ]; then

echo $ARG

installITunerATP

fi

if [ "$ARG" = "-uninstall" ]; then

echo $ARG

uninstallITunerATP

fi

Life Cycle script:

#!/bin/sh

#functions

installLifeCycleATP()

{

INSTALL_PATH="/usr/lib/ovip/Radio/LifeCycleATP"

echo "install called"

${INSTALL_PATH}/ControlServiceWatcherServer &

#remove original LyfeCycleATP Qt plugin

servicefw –system remove ControlService

#add LyfeCycleATP plugin

servicefw –system add ${INSTALL_PATH}/ControlServiceWathcer.xml

}

uninstallLifeCycleATP()

{

echo "uninstall started"

export QT_PLUGIN_PATH=/usr/lib/ovip/AppFwk/Core:/usr/lib/ovip/AppFwk/Domains:/usr/lib/ovip/UIFramework

PLUGIN_PATH="/usr/share/ovip/AppFwk/Core"

ps -ef | grep ControlServiceWatcherServer | awk '{print $2}' | xargs kill -9

#remove LifeCycleATP Qt plugin

servicefw –system remove ControlService

#add LifeCycleATP plugin

servicefw –system add ${PLUGIN_PATH}/ControlService.xml

echo "uninstall finished"

}

if [ "$#" -eq 1 ]; then

ARG="$1"

fi

if [ "$ARG" = "-install" ]; then

echo $ARG

installLifeCycleATP

fi

if [ "$ARG" = "-uninstall" ]; then

echo $ARG

uninstallLifeCycleATP

fi

Navigation script:

#!/bin/sh

#functions

installNavATP()

{

INSTALL_PATH="/usr/lib/ovip/Radio/NavATP"

echo "install called"

#rename original libNav services

mv /usr/lib/ovip/AppFwk/Domains/libNavigationCorePlugin.so.1.0 /usr/lib/ovip/AppFwk/Domains/libNavigationCorePlugin.so.1.0_bk

#start NavATP service

${INSTALL_PATH}/NavDBUSCommandsService &

#remove original NavigationCoreService Qt plugin

servicefw –system remove NavigationCoreService

#add NavATP plugin

servicefw –system add ${INSTALL_PATH}/NavigationCoreServiceATP.xml

}

uninstallNavATP()

{

echo "uninstall started"

export QT_PLUGIN_PATH=/usr/lib/ovip/AppFwk/Core:/usr/lib/ovip/AppFwk/Domains:/usr/lib/ovip/UIFramework

PLUGIN_PATH="/usr/share/ovip/AppFwk/Nav"

echo "uninstall called"

# filters out only the second column – pids column

ps -ef | grep NavDBUSCommandsService | awk '{print $2}' | xargs kill -9

#remove old NavATP Qt plugin

servicefw –system remove NavigationCoreService

#rename original libNav services

mv /usr/lib/ovip/AppFwk/Domains/libNavigationCorePlugin.so.1.0_bk /usr/lib/ovip/AppFwk/Domains/libNavigationCorePlugin.so.1.0

#add NavATP plugin

servicefw –system add ${PLUGIN_PATH}/NavigationCoreService.xml

echo "uninstall finished"

}

if [ "$#" -eq 1 ]; then

ARG="$1"

fi

if [ "$ARG" = "-install" ]; then

echo $ARG

installNavATP

fi

if [ "$ARG" = "-uninstall" ]; then

echo $ARG

uninstallNavATP

fi

Speech script:

#!/bin/sh

#functions

installSpeechATP()

{

INSTALL_PATH="/usr/lib/ovip/Radio/SpeechATP"

echo "install called"

#remove original Speech Qt plugin

servicefw –system remove SpeechServiceRadio

#add SpeechATP plugin

servicefw –system add ${INSTALL_PATH}/SpeechDataCommands.xml

}

uninstallSpeechATP()

{

echo "uninstall started"

export QT_PLUGIN_PATH=/usr/lib/ovip/AppFwk/Core:/usr/lib/ovip/AppFwk/Domains:/usr/lib/ovip/UIFramework

PLUGIN_PATH="/usr/share/ovip/AppFwk/Speech"

echo "uninstall called"

#remove old Audio Qt plugin

servicefw –system remove SpeechServiceRadio

#add AudioATP plugin

servicefw –system add ${PLUGIN_PATH}/SpeechServiceRadio.xml

echo "uninstall finished"

}

if [ "$#" -eq 1 ]; then

ARG="$1"

fi

if [ "$ARG" = "-install" ]; then

echo $ARG

installSpeechATP

fi

if [ "$ARG" = "-uninstall" ]; then

echo $ARG

uninstallSpeechATP

fi

Master script:

#!/bin/sh

INSTALL_PATH="/usr/lib/ovip/Radio"

MY_NAME=`basename $0`

# ########## FUNCTIONS ########

usage()

{

echo "$MY_NAME will install/uninstall an ATP Application."

echo "Usage:"

echo " ############## SOURCE FIRST env.sh ###########"

echo " ./$MY_NAME -installRadioAppATP Installs RadioAppATP"

echo " ./$MY_NAME -uninstallRadioAppATP Uninstalls RadioAppATP"

echo " "

echo " ./$MY_NAME -installSpeechATP Installs SpeachATP"

echo " ./$MY_NAME -uninstallSpeechATP Uninstalls SpeachATP"

echo " "

echo " ./$MY_NAME -installAudioATP Installs AudioATP"

echo " ./$MY_NAME -uninstallAudioATP Uninstalls AudioATP"

echo " "

echo " ./$MY_NAME -installLifeCycleATP Installs LifeCycleATP"

echo " ./$MY_NAME -uninstallLifeCycleATP Uninstalls LifeCycleATP"

echo " "

echo " ./$MY_NAME -installClusterATP Installs ClusterATP"

echo " ./$MY_NAME -uninstallClusterATP Uninstalls ClusterATP"

echo " "

echo " ./$MY_NAME -installRadioPluginATP Installs ITunerATP"

echo " ./$MY_NAME -uninstallRadioPluginATP Uninstalls ITunerATP"

echo " "

echo " ./$MY_NAME -installNavATP Installs NavATP"

echo " ./$MY_NAME -uninstallNavATP Uninstalls NavATP"

}

CONFIG=""

# ########## MAIN ########

for param in $@; do

case "$param" in

-installLifeCycleATP)

CONFIG=LyCyATP

TARGET="LifeCycleATP"

export QT_PLUGIN_PATH="${INSTALL_PATH}/$TARGET"

${INSTALL_PATH}/$TARGET/LifeCycleATP.sh -install

shift

;;

-uninstallLifeCycleATP)

CONFIG=LyCyATP

TARGET="LifeCycleATP"

${INSTALL_PATH}/$TARGET/LifeCycleATP.sh -uninstall

shift

;;

-installRadioAppATP)

CONFIG=RAPPATP

TARGET="RadioAppATP"

export QT_PLUGIN_PATH="${INSTALL_PATH}"

${INSTALL_PATH}/RadioAppATP.sh -install

shift

;;

-uninstallRadioAppATP)

CONFIG=RAPPATP

TARGET="RadioAppATP"

${INSTALL_PATH}/RadioAppATP.sh -uninstall

shift

;;

-installSpeechATP)

CONFIG=SpeechATP

TARGET="SpeechATP"

export QT_PLUGIN_PATH="${INSTALL_PATH}/$TARGET"

${INSTALL_PATH}/$TARGET/SpeechATP.sh -install

shift

;;

-uninstallSpeechATP)

CONFIG=SpeechATP

TARGET="SpeechATP"

${INSTALL_PATH}/$TARGET/SpeechATP.sh -uninstall

shift

;;

-installAudioATP)

CONFIG=AudioATP

TARGET="AudioATP"

export QT_PLUGIN_PATH="${INSTALL_PATH}/$TARGET"

${INSTALL_PATH}/$TARGET/AudioATP.sh -install

shift

;;

-uninstallAudioATP)

CONFIG=AUDIOATP

TARGET="AudioATP"

${INSTALL_PATH}/$TARGET/AudioATP.sh -uninstall

shift

;;

-installClusterATP)

CONFIG=ClusterATP

TARGET="ClusterATP"

export QT_PLUGIN_PATH="${INSTALL_PATH}/$TARGET"

${INSTALL_PATH}/$TARGET/ClusterATP.sh -install

shift

;;

-uninstallClusterATP)

CONFIG=ClusterATP

TARGET="ClusterATP"

${INSTALL_PATH}/$TARGET/ClusterATP.sh -uninstall

shift

;;

-installITunerATP)

CONFIG=ITunerATP

TARGET="ITunerATP"

export QT_PLUGIN_PATH="${INSTALL_PATH}/$TARGET"

${INSTALL_PATH}/$TARGET/ITunerATP.sh -install

shift

;;

-uninstallITunerATP)

CONFIG=ITunerATP

TARGET="ITunerATP"

${INSTALL_PATH}/$TARGET/ITunerATP.sh -uninstall

shift

;;

-installNavATP)

CONFIG=NavATP

TARGET="NavATP"

export QT_PLUGIN_PATH="${INSTALL_PATH}/$TARGET"

${INSTALL_PATH}/$TARGET/NavATP.sh -install

shift

;;

-uninstallNavATP)

CONFIG=NavATP

TARGET="NavATP"

${INSTALL_PATH}/$TARGET/NavATP.sh -uninstall

shift

;;

esac

done

if [ -z $CONFIG ]; then

usage

exit 1

fi

Interpretarea rezultatelor

Dupa implementarea pasilor enumerati in concept s-a facut un studiu asupra resurselor folosite pentru creare mediului, si asupra beneficiilor aduse de acestea:

Expunerea publica a interfetelor componentei a fost consumatoare de reusrse, nu a fost o munca grea, dar a fost meticuloasa si consumatoare de timp. Avand in vedere ca s-a dorit inlocuirea tuturor modulelor cu care comunica comopnenta supusa testarii, volumul de munca a fost mare. Acest efort a fost recompnesat prin faptul ca adaptoarele scrise astfel au putut fi folosite si pentru testarea altor componente. Deasemenea acestea adaptoare pot fi modificate pentru a face mai mult de monitorizarea semnalelor, pot sa forteze evenimente sa se intample. Acestea a fost de un real ajutor in testarea cazurilor ce necesitau evenimente imposibil de realizat intr-un caz real de functionare.

Pentru utilitarul de testare automata s-a refolosit unul existent in departament. Acesta a necesitat doar extinderea cu o librarie speciala care sa contina pasi ce permit apelarea metodelor si ascultarea de semnale pe DBus.

Dupa ce primii pasi au fost disponibili, a fost usor pentru echipa de preintegrare sa scrie testele. Acestia au urmat diagramele de arhitectura unde erau descrise eveneimentele: ce semnale si ce valori sunt asteptate dupa apelarea unui eveniment, care erau identice cu cele expuse public de interfetele de test create in framework.

Avand in vedere ca framework-ul creat pentru testarea componentei de radio a putut fi reutilizat pentru a testa alte componente (exemplu: Media), si pentru ca s-au putut testa astfel si cazurile imposibil de creat intr-un mediu real s-a dovedit ca a fost investitie de succes a resurselor.

CONCLUZII

Performanță – timpul rularii testelor s-a diminuat

Testele automate de integrare dezvoltate de mine pe baza arhitecturii modulelor software au redus semnificativ timpul necesar testarii. Odata scrise acestea au fost rulate saptamanal cu utilitarul automat, in acest timp eu si restul echipei de testare ne-am putut ocupa de alte activitati: mentenenta testelor automate sau executarea testelor manual de verificare, care nu se puteau automatiza.

Performanță – încrederea in funcționalitatea livrată a crescut

Deoarece studiul s-a facut asupra unui proiect aflat intr-un stadiu incipient de dezvoltare, s-a observant multitudinea de regresii descoperite cu testele de integrare. Fiind intr-o perioada de dezvoltare, in fiecare saptamana livram functionalitate noua, fiind multe lini de cod sansele ca acesta sa aduca regresii aupra functionalitatii deja existente erau foarte mari. Fiecare dezvoltator isi testa codul inainte de a-l livra, dar datorita instabilitatii sistemului, nu putea sa testeze si integrarea lui ce celelalte componente, deja existente.

Munca acestea revenea echipei de testare in urmatoarea etapa, iar raportul oferit de mine prin executarea testele automate de integrare ofereau un status exact asupra defectelor introduse de la o saptamana la alta.

Mai mult decat atat, deoarece s-au descoperit atat de multe defecte introduse in cod saptamanal, echipa de dezvoltare a cerut un training prin care sa afle pasii necesari rularii acestei suite, pentru a putea fi rulata individual de ei inainte de introducerea codului in build.

Performanță – izolarea modului supus testării

Cu ajutorul framework-ului creat, am izolat componenta supus testarii. Astfel ca, testarea acesteia nu a mai fost influnetata de posibilele erori din celelalte componente. Totodata am eliminat cazurile in care era imposbila testarea functinalitatii codului propriu datorita lipsei implementarii in celelalte componente.

Testand la limita noastra de functionare am putut da verdictul de implementare corecta sau nu pentru modulul nostru.

Reutilizare

Framework-ul a fost creat prin extinderea componentelor cu adaptoare care expuneau pe langa functionalitatea originala si posibilitatea de monitorizare a semnalelor cu o componeneta externa (ATP – utilitarul de testare automata), sau fortarea unor evenimente ce nu puteau fi simulate in mediul real.

Pentru ca s-a dovedit un real success in testarea componentei noastre, Aplicatia de Radio, a fost cerut si de echipele altor module. Deoarece principiul de comunicare intre componente este acelasi, celelalte echipe au refolosit framework-ul prin schimbarea componentei supusa testarii.

Script-uri automate

Nevoia de imbunatire este constanta, de aceea se doreste automatizarea tuturor actiunilor repetitive ce consuma timp.

Am identificat si operatiile de setare a mediului de test ca fiind mari consumatoare de timp, saptamanal. Astfel, prin shell scripting am creat script-uri automate care pot inlocuii fiecare componenta originala din sistem cu componenta de test echivalenta, cu adaptorul creat de framework, totodata am oferit prin acestea si posibilitatea de revenire la mediul original, in functie de necesitatile testarii.

Bibliografie

Andreas Spillner, Tilo Linz, Hans Schefar. Software Testing Foundations: A stuydy guide for the Certified Tester Exam, Rocky Nook, 2007

Jürgen Wölfle (Conti Temic): Testing Concepts and Test Environments of a Tier 1 Supplier, Vector Congress, Stuttgart, 2010

Ioana Barcan, Alexandru Lupu. Manual utilizare ATP, Continental, 2010

Clements, Paul and Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Paulo Merson, Robert Nord, Judith Stafford. Documenting Software Architectures: Views and Beyond, Second Edition. Boston : s.n., 2010.

Certified Tester Foundation Level Sylabus 2010, version 1.2b

Diaz & Hilterscheid GmbH, ISTQB, 2012

Dustin, Elfriede. Effective Software Testing. Addison Wesley, 2003.

Bibliografie

Andreas Spillner, Tilo Linz, Hans Schefar. Software Testing Foundations: A stuydy guide for the Certified Tester Exam, Rocky Nook, 2007

Jürgen Wölfle (Conti Temic): Testing Concepts and Test Environments of a Tier 1 Supplier, Vector Congress, Stuttgart, 2010

Ioana Barcan, Alexandru Lupu. Manual utilizare ATP, Continental, 2010

Clements, Paul and Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Paulo Merson, Robert Nord, Judith Stafford. Documenting Software Architectures: Views and Beyond, Second Edition. Boston : s.n., 2010.

Certified Tester Foundation Level Sylabus 2010, version 1.2b

Diaz & Hilterscheid GmbH, ISTQB, 2012

Dustin, Elfriede. Effective Software Testing. Addison Wesley, 2003.