Testarea la nivel de sistem și [632019]
Testarea la nivel de sistem și
automatizarea procesului
testării în domeniul automotive
Proiect de diplomă
Realizat de : Diana -Larisa N AP
Conducător științific : S. L. Ing. Flavius OPRI ȚOIU
Timișoara, 2019
Universitatea „Politehnica” din
Timișoara
Facultatea de Automatică și
Calculatoare
Diana -Larisa NAP
Diana -Larisa NAP
Cuprins
1.Introducere ………………………….. ………………………….. ………………………….. ………………………….. ………. 1
1.1 De ce avem nevoie de testare? ………………………….. ………………………….. ………………………….. ….. 1
1.2 Ce înseamnă testarea? ………………………….. ………………………….. ………………………….. ……………… 2
1.3 Scopul lucrării ………………………….. ………………………….. ………………………….. ………………………….. 2
2. Teoria testării la nivel de sistem ………………………….. ………………………….. ………………………….. ……… 5
2.1 Mod ele ale testării ………………………….. ………………………….. ………………………….. …………………… 5
2.1.1 Modelul V -cycle ………………………….. ………………………….. ………………………….. …………………. 5
2.1.2 Waterfall model (Modelul cascadă) ………………………….. ………………………….. ………………….. 7
2.1.3 Modelul spirală ………………………….. ………………………….. ………………………….. …………………. 8
2.1.4 Modelul haos ………………………….. ………………………….. ………………………….. ……………………. 9
2.2 Procesul fundamental de testare ………………………….. ………………………….. ………………………….. 10
2.3 Tipuri de testare ………………………….. ………………………….. ………………………….. …………………….. 11
2.4 Tehnicile statice și procesul de testare ………………………….. ………………………….. ………………….. 13
2.5 Gestionarea defectelor ………………………….. ………………………….. ………………………….. …………… 13
2.6 Gestionarea testelor ………………………….. ………………………….. ………………………….. ………………. 15
3.Tehnici de testare ………………………….. ………………………….. ………………………….. ………………………… 17
3.1 Black box ………………………….. ………………………….. ………………………….. ………………………….. ….. 17
3.2 White box ………………………….. ………………………….. ………………………….. ………………………….. …. 19
3.3 Tehnici bazate p e experiență ………………………….. ………………………….. ………………………….. …… 20
4. Prezentarea conceptului de testare manuală la nivel de sistem ………………………….. …………………. 21
4.1 Prezentarea conceptului nostru ………………………….. ………………………….. ………………………….. .. 21
4.2 Ce presupune testarea manuală? ………………………….. ………………………….. …………………………. 23
4.3 Tipuri de echipamente pentru testarea manuală ………………………….. ………………………….. ……. 23
5. Propunerea unui concept de automatizare a procesului testării ………………………….. ………………… 25
5.1 Prezentarea conceptului ………………………….. ………………………….. ………………………….. …………. 25
5.2 Ce presupune autom atizarea? ………………………….. ………………………….. ………………………….. …. 29
5.3 Tipuri de echipamente și modele ale automatizării ………………………….. ………………………….. … 31
5.4 Tehnologiile utilizate ………………………….. ………………………….. ………………………….. ………………. 31
5.5 Implementare ………………………….. ………………………….. ………………………….. ……………………….. 32
6. Concluzii ………………………….. ………………………….. ………………………….. ………………………….. ………… 39
6.1 Posibilități de extindere a conceptului nostru ………………………….. ………………………….. ………… 39
6.2 Testarea în viitor ………………………….. ………………………….. ………………………….. ……………………. 39
6.3 Concluzii ………………………….. ………………………….. ………………………….. ………………………….. …… 41
7.Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. ……… 43
Diana -Larisa NAP
Listă figuri
Figura 1.1 Schema bloc a proiectului ………………………….. ………………………….. …………. 3
Figura 2.1 Schema modelului V -Cycle ………………………….. ………………………….. ……….. 6
Figura 2.2 Schema modelelui Cascadă ………………………….. ………………………….. ……….. 7
Figura 2.3 Modelul spirală ………………………….. ………………………….. ………………………… 9
Figura 4.1 Schema bloc pentru partea manuală ………………………….. ……………………… 21
Figura 4.2 Exemplu plăcuță BCM ………………………….. ………………………….. ……………. 21
Figura 4.3 Schema pentru cutia de intrări ………………………….. ………………………….. ….. 22
Figura 4.4 Schema pentru cutia de ieșiri ………………………….. ………………………….. ……. 22
Figura 4.5 Voltmetru digital comercial ver ificând un prototip ………………………….. ….. 24
Figura 5.1 Schema bloc pentru partea automată ………………………….. ……………………… 25
Figura 5.2 Placa Arduino Uno ………………………….. ………………………….. ………………… 26
Figura 5.3 Conexiune LCD – I2C la placa Arduino ………………………….. ………………….. 27
Figura 5.4 Conexiune buton la placa arduino ………………………….. …………………………. 27
Figura 5.5 Schema optocuploare ………………………….. ………………………….. ………………. 28
Figura 5.6 Placă de test ………………………….. ………………………….. ………………………….. . 28
Figura 5.7 Schema testării automate ………………………….. ………………………….. …………. 30
Figura 5.8 Echipament pentru testarea automată ………………………….. …………………….. 31
Figura 6.1 Roboții umanodiali ………………………….. ………………………….. …………………. 40
Diana -Larisa NAP
Listă secvențe cod
Secvența de cod 5 -1 ………………………….. ………………………….. ………………………….. ………….. 32
Secvența de cod 5 -2 ………………………….. ………………………….. ………………………….. ………….. 32
Secvența de cod 5 -3 ………………………….. ………………………….. ………………………….. ………….. 32
Secvența de cod 5 -4 ………………………….. ………………………….. ………………………….. ………….. 33
Secvența de cod 5 -5 ………………………….. ………………………….. ………………………….. ………….. 33
Secvența de cod 5 -6 ………………………….. ………………………….. ………………………….. ………….. 34
Secvența de cod 5 -7 ………………………….. ………………………….. ………………………….. ………….. 34
Secvența de cod 5 -8 ………………………….. ………………………….. ………………………….. ………….. 35
Secvența de cod 5 -9 ………………………….. ………………………….. ………………………….. ………….. 35
Secvența de cod 5 -10 ………………………….. ………………………….. ………………………….. ………… 36
Secvența de cod 5 -11 ………………………….. ………………………….. ………………………….. ………… 37
Secvența de cod 5 -12 ………………………….. ………………………….. ………………………….. ………… 37
Secvența de cod 5 -13 ………………………….. ………………………….. ………………………….. ………… 38
Secvența de cod 5 -14 ………………………….. ………………………….. ………………………….. ………… 38
Diana -Larisa NAP
1
1. Introducere
1.1 De ce avem nevoie de testare?
Sistemele softwar e
Sistemele software fac parte din viața noastră de zi cu zi, de la aplicațiile de afaceri
(de exemplu , bancare) pâ nă la produsele de consum (de exemplu, mașinile), majoritatea
oamenilor s -au confruntat măcar o dată în viaț ă cu un sistem software care nu a funcționat
conform așteptărilor. Un software nefuncțional poate duce la multe probleme, inclusiv
pierderea de bani, timp sau afectarea companiei producătoare, și ar putea chiar provoca
vătămări sau deces.
Cauzele defec țiunilor software
O ființă umană poate face o eroare, care produce un defect în codul programului sau
într-un document. Dacă se execută un cod care conține erori, sistemul nu funcționează cum ar
trebui să funcționeze în mod normal, provocând astfel un eșec. Erorile apar din diverse
motive cum ar fi presiunea asupra angajaților sau complexitatea infrastructurii sau a codului
dar pot apărea deficiențe și din cauza condițiilor de mediu. De exemplu: radiațiile,
magnetismul, câmpurile electronice și poluarea pot cauza defecțiuni sau pot influența
execuția software -ului prin modificarea condițiilor hardware.
Rolul testă rii
Testarea riguroasă a sistemelor și a documentației poate contribui la reducerea riscului
de apariție a problemelor în timpul funcționării, dacă erorile găsite sunt corectate înainte ca
sistemul să fie eliberat pentru utilizarea operațională.
Testarea și calitatea
Cu ajutoru l testelor, este posibil să se observe calitatea software -ului în ceea ce
privește erorile constatate, atât pentru cerințele și caracteristicile software -ului funcțional, cât
și pentru cele nefuncționale (de exemplu: fia bilitatea, utilitatea, eficiența , întreținerea și
portabilitatea).Testarea poate oferi încredere în calitatea software -ului în cazul în care
constată puține defecte sau nu. Un test proiectat corespunzător, care trece, reduce nivelul
general al riscului într -un sistem, așadar prin testare, er orile sunt detectate și prin fixarea
acestora crește calitatea sistemului software.
Testarea ar trebui să fie integrată ca una dintre activitățile de asigurare a calității,
adică înțelegând cauzele defectelor găsite în alte proiecte, care ar trebui să pr evină reapariția
acestora și, în consecință, să îmbunătățească calitatea sistemelor viitoare.
Diana -Larisa NAP
2
Cât trebuie s ă testă m?
Stabilirea cantității suficiente de testare ar trebui să tină cont de nivelul de risc,
inclusiv de riscurile tehnice, de siguranță și de afaceri, precum și de constrângerile legate de
proiect, cum ar fi timpul și bugetul. Testarea ar trebui să furnizeze informații suficiente
pentru a lua decizii cu privire la lansarea softwa re-ului sau a sistemului testat pentru
următorul pas de dezvol tare sau predarea acestuia către clienți.
1.2 Ce înseamn ă testarea?
Testarea este mai mult decât executarea sistemului și verificarea acestuia dacă se
comportă conform așteptărilor. Testarea include examinarea documentelor, inclusiv codul
sursă, dar și o serie de activități atât înainte de execuția testului cât și după, acestea includ
planificarea și controlul, alegerea condițiilor de testare, proiectarea și executarea cazurilor de
testare, verificarea rezultatelor, evaluarea criteriilor de ieșire, raport area procesului de testare.
Testarea poate avea următoarele obiective: găsirea defectelor, creșterea încrederii cu
privire la nivelul calității, furnizarea de informații pentru luarea deciziilor dar și prevenirea
defectelor.
Pentru prevenirea apariției defectelor în cod putem apela la identificarea și
soluționarea problemelor, la recenziile documentelor ( de exemplu, cerințe) dar și la procesul
de gândire și la activitățile implicate în proiectarea testelor la începutul ciclului de viată.
În dezvoltare a testării (de exemplu: componenta, integrarea și testarea sistemului),
obiectivul principal este acela de a provoca multe defecte astfel încât erorile software -ului să
fie identificate și să poată fi reparate. În testul de acceptare, obiectivul principal este acela de
a confirma că sistemul funcționează conform așteptărilor, câștigând încrederea că a îndeplinit
cerințele. În unele cazuri, obiectivul principal al testării poate să fie evaluarea calității
software -ului, fără intenția de a remedia erorile, ia r informațiile vor fi date părților interesate
cu privire la riscul de a elibera sistemul la un moment dat. Testarea de întreținere include
adesea teste care nu prezintă defecte noi introduse în timpul schimbărilor de dezvoltare. Pe
parcursul testării oper aționale , obiectivul principal poate fi evaluarea caracteristicilor
sistemului, cum ar fi fiabilitate sau disponibilitate.
Testarea poate indica eșecuri cauzate de erori. Depanarea este activitatea de
dezvoltare care găsește, analizează și elimină cauza eșecului. Retestarea ulterioară de către un
tester asigură că remedierea rezolvă cu adevărat eșecul, iar responsabilitatea pentru fiecare
dintre aceste activități sunt testele ce trebuie testate.
1.3 Scopul lucr ării
Abordarea pe care am ales -o în dezvoltarea lucrării de licență este realizarea unui mini
test bench care are ca scop simularea echipamentelor din interiorul unei mașini în vederea
testării funcționalităților implementate în DUT (Device Under Test). Pe lângă scopul testării
funcționale, acest test bench se va utiliza în cadrul unor proiecte în scop didactic pentru a
exemplifica rolul testării în industria automotive, astfel stud enții au posibilitatea de a învă ța
încă de pe băncile facultăți i ce presupune testarea, pe baza acestui proiect au fost sus ținute și
câteva cursuri în cadrul facultăț ii prin intermediul ACLabs.
Am ales să îl numesc „Mini Test Bench” din cauza faptului că nu voi avea incluse
toate funcționalităț ile pe care le găsim în mod normal la bordul unei mașini, mă voi rezuma
Diana -Larisa NAP
3
doar la un ele dintre ele și anume farurile mașinii, semnalizarea direcției de mers, iluminat
interior și ștergătoarele. Pe lângă acestea vom mai avea incluse alte funcționalități, precum
ușa șoferului sau poziția cheii în contactu l mașinii, acestea putând avea efect asupra altor
funcționalități pe care le avem incluse, cum ar fi aprinderea lumin ii în interiorul mașinii sau
semnalizarea șoferului prin diverși martori vizuali (în cluster/ instrumentul de bord) în
legătură cu modificarea făcută.
Breakout 1 Breakout 2
Placă test
Figura 1.1 Schema bloc a proiectului
Input
Output BCM
Arduino UNO Ecran LCD I2C
1 2 3 Bloc optocuploare
jo
Butoanele 1 – up
2- ok
3- down
Diana -Larisa NAP
4
Diana -Larisa NAP
5
2. Teoria testării la nivel de sistem
2.1 Modele ale testării
2.1.1 Modelul V -cycle
Modelul V -cycle reprezintă un proces de dezvoltare care poate fi considerat o
extensie a modelului cascadă. Pe când în modelul cascadă procesul se dezvoltă în mare parte
într-o singură direcție, în acest model etapele procesului sunt îndoite în sus după faza de
codificare, obținând astfel formă tipică V. Înt re toate fazele ciclului de viaț ă al dezvoltării și
faza de testare există o relație demonstrată în acest model, astfel axele verticale ș i orizontale
reprezi ntă perioada de completare a proiectului dar și nivelul de abstractizare.
Fazele de verificare ale modelului V sunt urm ătoarele:
1. Analiza cerin țelor;
2. Proiectarea sistemului;
3. Proiectarea arhitecturii;
4. Proiectarea modulului.
Fazele de validare ale modelul ui V sunt urm ătoarele:
1. Testarea unitar ă;
2. Testarea integrat ă;
3. Testarea sistemului;
4. Testarea accept ării utilizatorului;
5. Testarea lans ării.
În analiza cerințelor, prima etapă din fază de verificare, cerințele sistemului sunt
cumulate prin analizarea nevoilo r utilizatorilor, fiind generat un document numit `cerințele
utilizatorului ` care conține organizarea generală a sistemului, structuri de date, diagrame etc..
Această fază are scopul dea stabili ce trebuie să îndeplinească sistemul, totuși nu este
determi nat și scopul în care va fi proiectat sistemul software.
Proiectarea sistemului, a doua etapă din faza de verificare, este faza în care inginerii
de sistem analizează sistemul propus prin studierea cerințelor utilizatorului căutând astfel
diverse tehnici prin care pot fi implementate cerințele, iar dacă una dintre cerințe nu poate fi
implementată va fi anunțat utilizatorul fiind stabilit un compromis și se se vor face
modificările necesare.
În cea de -a treia etapă, proiectarea arhitecturii, este faza de proiectare a arhitecturii
sistemelor de calcul și a arhitecturii software fiind o prioritate de nivel înalt. Trebuie să se
realizeze tot ceea ce constă, în mod tipic, din lista de module, funcționalitatea fiecărui
modul, relații de interfață, tabelele de date.
Modulul de proiectare este o fază care poate fi menționată ca proiectare la nivel
scăzut. Pentru a putea fi începută scrierea codului, trebuie să se împartă sistemul în unități de
module mai mici și fiecare dintre ele este explicat separat. Specif icațiile programelor de nivel
inferior vor conține o logică funcțională detaliată a modului în pseudocod: toate problemele
Diana -Larisa NAP
6
de dependenț ă, intrări și ieșiri pentru un modul, lista mesajelor de eroare etc.. Procesul de
testare a unității este dezvoltat tot î n această etapă.
În cea de -a doua fază a modelului V, faza de validare, prima etapă este testarea
unităților în care fiecare uniate de cod este executată pentru a elimina erorile. O unitate este
cea mai mică entitate testabilă a unei aplicații. Testarea unităților verifică dacă cea mai mică
entitate poate funcționa corect atunci când este izolată de restul codului.
Testarea integrată, cea de -a doua etapă din faza de validare, presupune verificarea
dacă unitățile create și testate independent pot comun ica între ele pentru a expune defectele în
interfețe.
În această etapă, testarea sistemului, planurile de testare a sistemului sunt create de
echipa pe care o are clientul, pentru realizarea proiectului, spre deosebire de planurile de
testare a unitățilo r și integrării. Apoi aplicația este testată pentru a asigura funcționalitatea,
indep endenț ă și comunicarea.
Testele din ultima etapă a acestui model, testarea acceptării utilizatorului, sunt
elaborate în timpul fazei de analiză a cerințelor. Testul de a cceptare al utilizatorilor verifică
faptul că sistemul livrat satisface cerințele utilizatorului, iar sistemul poate fi utilizat în timp
real.
Figura 2.1 Schema modelului V -Cycle
Avantajele modelului V -cycle :
1. Activitățile de test are precum planificarea, proiectarea testelor se întâmplă cu
mult înaintea scrierii codului. Acest lucru economisește mult timp. Prin urmare,
șansele de succes sunt mult mai mari fat ă de șansele modelului cascadă ;
2. Simplu și ușor de utilizat;
3. Funcționează bine pentru proiecte mici, unde cerințele sunt ușor de înțeles;
Diana -Larisa NAP
7
4. Urmărirea defectelor proactive -adică defectele se găsesc la începutul eta pei;
5. Evită fluxul descendent al defectelor.
Dezavantajele modelului V:
1. Dacă se produc schimbări în timpul realizării proiectului, documentele de
testare împreună cu documente le necesare trebuie actualizate;
2. Este rigid, iar dacă apar modificăr i acestea sunt greu de introdus;
3. Software -ul este dezvoltat în timpul fazei de implementare, astfel încât nu se
produc prototipuri timpurii ale software -ului.
2.1.2 Waterfall model (Modelul cascadă )
Modelul cascadă este o abordare secvențială utilizată în dezvoltarea sistemelor
software în care progresul se dezvoltă printr -o cădere continuă, ase mena unei cascade de
unde îi vine și numele.
În dezvoltarea de sisteme software, modelul cascadă ține să fie printre cele mai puțin
iterative și flexibile abordări, deoarece se dezvoltă în mare parte într -o singură direcție
trecând prin fazele de concepț ie, inițiere, analiză, proiectare, construcție, testare,
implementare și întreținere.
În modelul original de cascadă, fazele sunt în următoarea ordine:
1. Cerințe software și de sistem : cerințele sunt captate întru -un document;
2. Analiză : mode le, scheme și reguli de afaceri rezultate;
3. Design: arhitectură software;
4. Codarea: integrarea, dezvoltarea și demonstrarea software -ului;
5. Testarea: descoperirea defectelor ;
6. Operațiuni: instalarea, migrarea, suportul și întreținerea sistemelor complete;
Figura 2.2 Schema modelelui Cascad ă
Așadar, modelul cascadei susține că nu trebuie să trecem la următoarea fază pană în
momentul în care faza precedentă este revizuită și verificată. Este foarte important să ne
Diana -Larisa NAP
8
concentrăm p e fazele de început în ciclul de producție software deoarece o eroare găsită și
corectată la început este mult mai economică din punct de vedere al efortului și timpului
decât aceeași eroare găsită ulterior în proces. Un concept de program este mai ușor de reparat
la stadiul de creare decât câteva luni mai târziu când componentele din program sunt
ignorate.
Modelul cascadei are diverse avantaje cum ar fi:
1. Fiecare etapă și activitate din proces este bine definită;
2. Este ușor de explicat utili zatorilor;
3. Ușor de manevrat datorită inflexibilității modelului;
4. Fiecare etapă este procesată pe rând și asigură detecția timpurie a erorilor și
funcționează bine pentru proiectele mici.
Dezavantajele modelului cascadă sunt:
1. Risc și nesiguranță;
2. Este un model slab pentru proiectele lungi și continue, pentru proiectele
complexe dar și acolo unde necesitățile se pot schimba destul de des.
Modelul cascadă conține etapele care îl realizează într -un mod tradițional, dar modul
în care este utilizat afectează succesul pe care îl va avea. Modelul este utilizat cu succes dacă
cerințele primite sunt bine înțelese de la început și nu sunt făcute modificări pe parcursul
vieții proiectului.
2.1.3 Modelul spiral ă
Modelul spirală este un model al procesului de dezvoltare al software -ului. Pe baza
modelelor de risc unice ale unui proiect dat, modelul spirală ghidează o echipă pentru a
adopta elemente ale unuia sau mai multor modele de proces, cum ar fi prototipuri
incrementale, cascade sau evoluție.
Evoluția spiralei constă în patru activități de bază care trebuie să apară în fiecare ciclu.
În prima activitate se stabilește un acord al si stemului și anume performanța ,
funcționalitatea, dar și abilitatea de adaptare la schimbări. Tot în această activitate se
investighează constrângerile impuse: cost, program, riscuri, dar și implementările alternative:
model, reutilizare și modificare.
În cea de -a două activitate se selectează o abordare alternativă ce satisface mai bine
tehnologia, ri scul, costul, programul și suportul. Este pus accentul pe atenuarea riscului și
este analizată fiecare alternativă.
În cea de -a treia activitate dacă se determină că prototipul anterior are rezolvate toate
problemele tehnice și activitățile, se poate tre ce la pasul următor. Astfel, modulul de bază
`cascadă` poate să fie utilizat.
În ultima activitate, modelul spirală, are o caracteristică comună cu toate celelalte modele
și anume nevoia planificării tehnice avansate și analize multidisciplinare la aștep tarea critică.
Pentru orice artefact al unui proiect, echipa proiectului trebuie să decidă de câte detalii
este nevoie pentru acesta, deciziile find făcute prin minimizarea riscului global.
Diana -Larisa NAP
9
Avantajele modelului spirală sunt:
1. Riscurile sunt foa rte bine analizate ;
2. Este ideal pentru proiectele mari ;
3. Modelul software are o dezvoltare completă la proiectele cu cererile neclare .
Dezavantajele modelului spirală sunt:
1. Analiza riscurilor neces ită o experiență de nivel înalt;
2. Greu de înțeles fără pregătire tehnică ;
3. Succesul depinde de faza de analiză a riscurilor ;
4. Este un model costisitor.
Figura 2.3 Modelul spiral ă
2.1.4 Mod elul haos
Modelul chaos sau modelul haosului, este o structură de dezvoltare softw are.
Creatorul său a remarcat faptul că modelele de management de proiect, cum ar fi modelul
spirală și modelul de cascadă, în timp ce erau bune la gestionarea programelor și a
personalului, nu furnizau metode pentru a repara erorile sau a rezolva alte pro bleme tehnice.
Diana -Larisa NAP
10
În același timp, metodologiile de programare, în timp ce sunt eficace în ceea ce privește
remedierea erorilor și rezolvarea problemelor tehnice, nu ajută la gestionarea termenelor
limită sau la răspunsul la cererile clienților. Structura înc earcă să depășească acest decalaj.
Teoria haosului a fost folosită că instrument pentru a ajută la înțelegerea acestor probleme.
Fazele ciclului de viață se aplică la toate nivelurile proiectelor, de la fiecare linie de
cod, individuală, pană la întregul proiect. Așadar, întregul proiect, sistemele, modulele,
funcțiile și liniile de cod trebuie definite, implementate și integrate.
Comportamentul unui sistem complex este rezultat din combinația blocurilor de
construcție mai mici, toate liniile de cod nu sunt scrise într -o singură ședință, sunt scrise
bucăți mici, câte o singură linie și se verifică dacă piesele mici funcționează.
Modul în care programatorii lucrează spre sfârșitul unui proiect, atunci când au o listă
de erori seamănă cu strategia haosu lui. De obicei sunt stabilite prioritățile sarcinilor rămase,
iar programatorii le rezolvă una câte una, afirmând că acesta este singurul mod valabil de a
face munca.
Modelul chaos poate explica de ce software -ul tinde să fie atât de imprevizibil, explic ă
de ce conceptele de nivel înalt precum arhitectura nu pot fi tratate independent de liniile de
cod, dar ne oferă o explicație despre ceea ce trebuie făcut în continuare, în ceea ce privește
strategia.
2.2 Procesul fundamental de testare
Partea cea mai importantă a unei testări este execuția testului, pentru ca aceste teste să
fie eficiente, planul de testare trebuie să includă timpul necesar pentru planificarea testelor,
proiectarea cazurilor de testare, pregătirea pentru execuție, dar și pentru evalua rea
rezultatelor.
Procesul fundamental de testare constă în urmatoarele activități principale:
planificarea și controlul, analiza și proiectarea, implementarea și execuția, evaluarea
criteriilor de ieșire și raportarea, testarea activitățiilor de închidere .
În cadrul unui proces, activitățile se pot suprapune sau pot avea loc simultan,
conceperea lor este de obicei nec esară în contextul proiectului.
Planificarea și controlul unui plan
Pentru a putea fi îndeplinite toate cerințele trebuie definite obiecti vele de testare și de
specificare a activităților. Pentru a putea ține sub control un test, trebuie comparat și
monitorizat progresul sau real cu planul făcut și raportarea acestuia în cauzul în care apar
abateri. În planificarea de testare va fi luat în c onsiderare feedback -ul de la monitorizare.
Analiza testelor
În activitatea de analiză și testare a testelor întâlnim câteva sarcini majore precum
revizuirea bazei de testare care include integrarea software -ului, nivelul riscului, arhitectura ,
design et c., dar și evaluarea testabilității baz ei și a obiectelor de testare, trebuie să stabilim
prioritatea condițiilor de testare pe baza analizei comportamentului și structurii software -ului.
Diana -Larisa NAP
11
Tot în aceste activităț i trebuie să identificăm datele de testare ne cesare pentru a susține
condițiile și cazurile de testare.
Implementarea ș i executarea testelor
În această activitate sunt specificate procedurile sau scripturile de testare, aici găsim
toate cazurile de testare, combinarea tuturor posibilităților, într -o anumită ordine, dar și alte
informații necesare testării care au fost incluse pe parcurs.
Implementarea și executarea testelor au următoarele sarcini: finalizarea,
implementarea și prioritizarea cazurilor de testare și a procedurilor de testare, crearea suitelor
de testare pentru o execuție eficientă, verificarea mediului de testare și a testabilității între
baza de testare și cazurile de testare. Executarea testelor se face fie manual, fie prin utilizarea
instrumentelor de testare, în conformitate cu pla nificarea făcută. Compararea rezultatelor
reale cu rezultatele preconizate, diferențele obținute trebuie raportate ca incidente și trebuie
analizate pentru a stabili cauza acestora, activitățile trebuie repetate pentru fiecare
discrepanță, se face o reexec uție a testelor anterioare care au eșuat pentru a putea confirma un
rezultat final.
Evaluarea criteriilor de ieșire ș i raportare
Evaluarea criteriilor de ieșire este activitatea în care evaluarea testului este evaluată în
raport cu cea definită , trebuie făcut acest lucru pentru fiecare nivel de testare.
Pentru evaluarea acestor criterii trebuie să verificăm rezultatele testelor față de
criteriile de ieșire specificate în planificare, să evaluăm dacă trebuie efectuate mai multe teste
sau dacă trebuie să mo dificăm c riteriile, iar la final se scrie un raport de sinteză.
Activităț i de finalizare a testelor
Finalizarea activităților de testare apar atunci când sistemul software este lansat sau
când un proiect testat este finalizat sau anulat.
Această activ itate presupune sarcini majore precum verificarea livrărilor planificate
sau care au fost deja livrate. Rapoartele de închidere a incidentelor, finalizarea și arhivarea
testelor, analiza datelor pe care le folosim pentru modificările necesare lansării proi ectelor
dar și utilizarea noilor informații pentru a aduce testul la un nivel cât mai avansat.
2.3 Tipuri de testare
Activitățile d e testare au rolul de a verifica dacă sistemul software -ului este
funcțional. Un tip de testare este axat pe un anumit o biectiv, vom enumera câteva exemple: o
funcție care trebuie efectuată de software, o caracteristică de calitate (fiabili tatea sau
utilitatea), structura sau arhitectura software -ului sau a sistemului.
Un software poate fi dezvoltat ca și testare structur ală (un flux de control sau un
model de structură), testarea nefuncțională (modelul de performanță și modelul de utilizare)
și testarea funcțională (model al fluxului de proces sau un model de tranziție de stat).
Diana -Larisa NAP
12
Testarea funcț ională
Funcțiile pe care trebuie să le stabilească un sistem, un subsistem sau o componentă
pot fi descrise în lucrare, cum ar fi o sp ecificație a cerințelor, o specificație funcțională a
cazuri lor de utilizare.
Testele funcționale se bazează pe funcții și caracteristici care su nt înțelese de cei ce
testează sau sunt descrise în documente și interoperabilitatea acestora cu diverse sisteme
specifice pot fi executate la orice nivel de testare. Tehnicile bazate pe specificații pot fi
utilizate pentru a determina condițiile de testar e și cazurile de testare de la funcționalitatea
software -ului sau a sistemului. În cazul testării funcționale sunt luate în considerare
performanțele externe comportamentului software -ului (testarea black -box).
Un tip de testare funcțională investighează funcțiile referitoare la detectarea virușilor
din exterior sau evaluează dacă software -ul interacționează cu unul sau mai multe
componente în mod corespunzător .
Testarea nefuncțională
Testarea non -funcțională include, dar nu se limitează la testarea per formanțelor,
testarea sarcinii, testarea uzabitilității, testarea mentabilității, testarea fiabilităț ii și testarea
probabilității.
Testarea nefuncțională poate fi efectuată la toate nivelele de testare, acest termen de
testare nefuncțională ne descrie t estele de care avem nevoie pentru a măsura caracteristicile
software -ului care pot fi cuantificate pe o scară variabilă, cum ar fi timpii de răspuns pentru
testarea performanțelor.
Acest tip de testare ia în considerare comportamentul extern al software -ului și în
majoritatea cazurilor folosește tehnici de testare „ black -box ‟ pentru a realiza acest lucru.
Testarea structurală
Testarea structurală sau cutia albă poate fi efectuată la toate nivelele de testare, fiind
cea mai bună tehnică, utilizată după specificațiile primite, pentru a putea măsura în detaliu
gradul de acoperire al unui tip de structură. Prin acoperire înțelegem că o structură a fost
exercitată de o suită de teste, dacă procentajul nu tinde spre 100% atunci pot fi proiectate mai
multe teste pentru a putea acoperi și acea parte care a rămas.
În testarea componentelor și în testarea integrării componentelor, instrumentele pot fi
utilizate pentru a acoperi declarațiile sau deciziile cu codul necesar. Structural testarea poate
fi bazată p e arhitectura sistemului, cum ar fi o ierarhie de apel.
Testare a de regresie
După ce au fost remediate erorile, software -ul trebuie testat din nou pentru a putea
confirma că acesta a trecut cu succes, remedierea erorilor este o activitate de dezvoltare, nu
de testare.
Testarea prin regresie este testarea repetată a unui program deja testat, după fiecare
modificare sau după ce au fost introduse linii noi de cod. Erorile pot fi găsire fie în software –
ul testat, fie într -o componentă conexă sau necolerată , acestea apar atunci când software -ul,
sau mediul său este schimbat. Atunci când extindem un test, trebuie să ne asumăm riscul că
nu există erori în software -ul care funcționa anterior.
Diana -Larisa NAP
13
Testarea trebuie repetată pâ nă putem confirma că nu mai sunt erori , poate fi efectuată
la toate nivelurile de testare și include testarea funcțională, nefuncțională și testarea
structurală.
Testarea de regresie se face cu ajutorul aparatelor și sunt executate de mai multe ori,
astfel evoluează lent, deci retestarea reg resiei este un candidat puternic pentru testele
automatizate.
2.4 Tehnicile statice și procesul de testare
Spre deosebire de testarea dinamică, care necesită execuția software -ului, tehnicile de
testare statică se bazează pe executarea manuală și analiz a automată a documentației de
proiect fără executarea codului. Prin examinarea manuală înțelegem că testarea codului poate
fi realizată înainte de testarea dinamică. Erorile întâlnite în timpul examinării sau la începutul
ciclului de viată sunt adesea mult mai ușor de reparat decât cele detectate de testele ce rulează
codul de execuție.
O examinare ar pu tea fi efectuată în întregime ca o activitate manuală însă există și
un suport pentru instrumentele folosite. Principiul activității manuale este de a exa mina un
produs și de a preciza câteva comentarii referitoare la ceea ce se observă. Orice produs poate
fi revizuit, inclusiv cerințele, specificațiile, codul, cazurile de testare, ghidul de utilizare sau
paginile web. Recenziile sunt importante deoarece in clud detectarea și corecția defectelor
timpurii, apar îmbunătățiri, costurile de testare în timp sunt reduse. Cu ajutorul recenziilor
putem găsi difer ite cerințe care au fost omise pe parcurs.
Recenziile, analiza și testarea dinamică au același obiectiv ș i anume de a identifica
defectele. Prin diferite tehnici pot fi găsite diferite tipuri de defecte în mod eficient. În
comparație cu testarea dinamică care detecteaza eșecurile în sine , tehnicile statice detectează
cauzele defecțiu nilor.
2.5 Gestionarea d efectelor
Detectarea erorilor în timpul testării
Un tester execută testele specificate și analizează abaterile dintre rezultatele obținute
și cele reale, înregistrându -le într -un document. Erorile identificate, pot apărea atât în
documentele specifice în cod, cât și în datele de ieșire. După ce erorile sunt detectate de către
acesta, sunt transmise echipei de software, iar apoi se așteaptă că versiunea nouă a
programului să fie corectată, având apoi loc retestarea.
Dacă testerul este cel care execută t estele pentru a descoperi erorile pe care le
raportează într -o bază de date, rolul managerului de testare, coordonatorului de test este de a
analiza, gestiona și atenua riscurile și de a aloca prioritate acestora în conformitate cu
proiectul și cu cerințe le primite de la client. Apoi problemele sunt discutat e în cadrul unei
echipe, aceasta face parte din comisia de control a schimbării (CCB -Change Control Board),
această echipă este formată din șeful de testare, șeful echipei de dezvoltare, responsabilul
tehnic de proiect, însă la discuție poate să participe și clientul. În această etapă se restabilește
prioritatea cerințelor, aceștia pot hotărî dacă o problemă care a fost declarată anterior cu o
prioritate ridicată să fie redeclarată cu prioritate medie. U rmătoarea etapă este cea în care
Diana -Larisa NAP
14
dezvoltatorii localizează și analizează erorile pe care ulterior le corectează în conformitate cu
prioritatea atribuită.
În concluzie toate aceste sarcini sunt efectuate într -o manieră iterativă: tester,
managerul de test are, controlul comenzilor de schimb, dezvoltator revenind apoi din nou la
tester.
Figura 2.4 Efectuarea manierei iterative
Structura unui raport
Raportul unui defect descrie efectul acesteia, nu cauza care a provocat eroarea. Un
raport incl ude următoarele detalii: datele de eroare în care sunt enumerate toate erorile
întâlnite, fiecare având un număr unic, denumirea testului, mediul de testare, dar și data
primei apariții, tot aici se face și clasificarea erorilor care pot fi cu priori tate r idicată, medie
sau scăzută și se spec ifică starea acesteia , dacă este o eroare nou apărută după efectuarea unei
retestări.
Starea unei erori ne oferă informații despre evoluția lucrărilor efectuate pentru ca
aceasta să fie corectată. Aceste stări inclu d diverse etape, dar nu se limitează doar la atât.
Prima etapă este identificarea erorii de către tester, managerul de test trebuie să confirme
faptul că există o eroare sau în caz contrar poate să respingă eroarea respectivă. În cazul
acceptării se trece la următoarea etapă unde dezvoltatorul încearcă să identifice eroarea,
aceasta nu poate fi reprodusă, ea trebuie să fie supravegheată, după localizarea acesteia
trebuie corectată, iar apoi se trece la ultimul pas unde testerul are sarcina de a verifica
corecția efectuând o retestare, dacă testerul obține rezultatul final așteptat, testul este
considerat trecut, însă dacă rezultatul nu este conform așteptăr ilor procesul se va relua de la
început.
Figura 2.5 Tranziț ii pentru fluzul de lucru în cazul gesti noării defectelor
Tester Managerul de test
CCB Dezvoltatori
Diana -Larisa NAP
15
În concluzie, doar un tester este cel care poate afirma că o eroare a fost corectată,
managerul decide doar dacă eroarea trebuie corectată sau este respinsă, însă și comisia de
control a schimbării (CCB -Change Control Board ) poate decide acest lucru, luând în
considerare și co stul reparării . Toate modificările făcute trebuie trecute în document
asigurându -se controlul permanent al stadiului în care se află erorile, dacă este necesar se pot
planifica activității suplimentare de testare deo arece în multe cazuri acestea su nt necesare
pentru ca eroarea să fie detectată.
Analizarea rapoartelor
Toate rapoartele sunt analizate atent pentru a evalua progresul activităților de
corectare a erorilor, planul de proiect dar și calitatea software -ului. Obiectivele tipice sunt
legate de reducerea numărulu i de erori, de creșterea de viaț ă a proiectului, depistarea testelor
care prezintă un număr mai mare de erori sau a celor care prezintă un număr mai mic de erori,
câte erori cu prioritate ridicată sunt încă nerezolvate și cât durează ca acestea să fie fixate.
Gestionarea defectelor oferă o varietate de rapoarte privind erorile găsite în timpul
testării, fiind considerat un proces propriu constând într -un flux special.
2.6 Gestionarea testelor
Organizarea testelor
Organizarea testelor presupune separarea testelor, astfel încât acestea să fie
independente. Un test independent, este u n test care nu depinde de alte t este, astfel este mult
mai ușor de testat deoarece erorile dintr -un anumit test nu i nfluențează restul proiectului,
acesta fiind un avantaj. Tot în această etapă trebuie explicate și dezavantajele pe care le
întâlnim în cadrul testării independente din cadrul unei organizații, unul dintre acestea ar fi
faptul că nu putem testa un sistem c omplex în care componentele sunt interconectate între
ele, iar ieșirile unora sunt intrările altor componente.
Astfel se formează o echipă în care fiecare membru are s arcini bine stabilite, pentru
ca la finalul testării rezultatele să fie cât mai apro piate cu cele așteptate .
Planificarea ș i estimarea testelor
Înainte de începerea unui proiect este importantă planificarea testelor, adică
rezumarea scopului și conținutul planului de testare, dar și estimarea timpului care trebuie
alocat pentru ca acest ea să fie testate. Se scrie un program de execuție a unui test, se vor
stabili cazurile de testare ce trebuie efectuate pentru a putea confirma la sfârșitul acestora că
există cât mai puține defecte. Dacă mai multe teste sunt failed, acestea se vor retesta luând în
considerare prioritizarea.
Monitorizarea și controlul progresului de î ncărcare
În această parte reamintim valorile comune utilizate pentru monitorizarea pregătirii și
executăr ii testelor. Explicăm și compară m valorile de testare pentru raportar ea și testarea
testelor, de exemplu defectele găsite și corectate dar și testele care au picat. Rezumăm scopul
și conținutul documentului de sinteză a raportului de testare.
Diana -Larisa NAP
16
Riscul ș i testarea
Riscul este o po sibilă problemă care ar amenința atingerea o biectivelor unuia sau a
mai multor clienți. Nivelul de risc este determinat de ceea ce se întâmplă dar și de rezult at în
cazul în care se întâmpină probleme.
Diana -Larisa NAP
17
3.Tehnici de testare
Pentru a asigura calitatea unui produs acesta trebui e verificat și testat conform unor
proceduri cunoscute. Verificarea produsului se poate face static sau dinamic și cât mai repede
posibil.
Asigurarea calităț ii prin analiza statică
Analiza statica presupune utilizarea anumitor tehnici de revizuire ( walkt hroughs,
intensive, technical), analiza fluxului de control, analiza fluxului de date și măsurarea
complexității codului.
Asigurarea calității prin analiza dinamică
Analiza dinamică este împărțită în trei părți. Un a dinte ele presupune experiența ,
urmă toarea presupune tehnicile bazate pe erori, o altă categorie este white box iar ultima
black box.
În următoarele rânduri voi descrie ultimele două părți din analiza dinamică și anume
white box și black box dar și tehnicile bazate pe experiență.
3.1 Black box
Parțitionarea echivalenț ei
În partiționarea echivalenței intrările către software sau sistem sunt împărțite astfel
încât să prezinte un comportament similar adică să fie pr elucrate în același mod. Partiții le de
echivalență pot fi identificate pen tru datele valide, valorile ce ar trebui să fie acceptate și
nevalide sau valori ce a r trebui să fie respinse. Partiț iile pot fi de asemenea identificate pentru
ieșiri, valori i nterne, valori legate de timp ( de exemplu: înainte sau după un eveniment) și
pentru a interfera ( de exemplu: componentele integrate ce sunt testate în timpul testelor de
integrare). Testele pot fi concepute astfel încât să acopere toate pa rtițiile valide și nevalide.
Partiția de echivalenț ă se aplică la toate nivelurile de testare.
Partiția echivalentă poate fi utilizată pentru atingerea obiectivelor de intrare și ieșire.
Poate fi aplicată la intrările umane, intrare prin interfețe de sistem sau parametri de interfață
în cadrul testelor de integrare .
Analiza valori lor limită
Limi tele, adică valorile maxime și minime, ale partițiilor sunt zonele cele mai
predispuse să producă defecte, astfel comportamentul este incorect în comparație cu restul
zonelor, adică zona dinăuntrul partiției respective. O valoare limită trebuie să fie val idă
pentru ca o partiție să fie validă, în caz contrar, dacă limitele sunt nevalide și partiția este
nevalidă . Testele pot fi concepute să acopere toate limitele valide sau nevalide. Când sunt
proiectate cazurile de testare, va fi creat câte un test pentru fiecare valoare limită aleasă.
Analiza valorii limită poate fi aplicată la toate nivelurile de testare. Este relativ ușor
de aplicat și capacitatea de detectare a defectelor este ridicat ă. Specificațiile detaliate sunt
utile în determinarea interesului limitelor.
Diana -Larisa NAP
18
Această tehnică este adesea considerată o extensie a partiționării echivalente sau alte
tehnici de testare black -box. Poate fi folosită pe clase de echivalență pentru introducerea pe
ecran a utilizatorilor pe intervale de timp sau intervale d e tabelare.
Tabele de decizie
Tabelele de decizie sunt o modalitate bună de a captura cerințele de sistem care conțin
condiții logice și documentația sistemului de proiectare intern ă. Acestea pot fi folosite pentru
înregistrarea regulilor de afaceri pe care trebuie să le implementeze în sistem.
Atunci când sunt create tabelele de decizie, specificațiile sunt analizate și se identifică
condiț iile și acțiunile sistemului. Condițiile de intrare și acțiunile sunt cel mai des precizate
astfel încât aceste a să fie adevărate sau false (boolean). Aceste tabele conțin declanșarea
condițiilor, combinații de valori adevărate sau false pentru toate intrările și acțiunile rezultate
pentru fiecare combinaț ie de condiții. Fiecare coloană din tabel corespunde unei re guli de
afaceri care definește o combinație unică de condiții și care conduce la executarea condițiilor
asociate cu regula respectivă. Standardul de acoperire folosit în mod obișnuit pentru testarea
tabelelor de decizie este de a efectua câte un test pent ru fiecare coloană din tabel, care
implică acoperirea tuturor combinațiilor de condiții de declanșare.
Rezistența procesului de testare a tabelelor este crearea combinațiilor de condiții care
nu au putut fi executate în timpul testării. Acesta poate fi a plicat în toate situațiile în care
acțiunea software -ului depinde de mai multe decizii logice.
Testarea tranziț iei
Un sistem poate prezenta un răspuns diferit în funcție de condițiile curente sau istoria
anterioară. În acest caz, acest aspect al sistemul ui poate fi prezentat ca o diagramă de tranziție
de stat. Testerul vizualizează software -ul în termenii stărilor sale, tranziții între state, intrări
sau evenimente care declanșează schimbările de stat și acțiunile car e rezultă din acele
tranziții.
Un ta bel de stare prezintă relația dintre stări și intrări și poate evidenția eventualele
tranziții care sunt nevalide.
Testele pot fi proiectate as tfel încât să acopere o secvență tipică de stări, să acopere
fiecare stat, să exercite fiecare tranziție, pentr u a exercita secvențele specifice de tranziții sau
pentru testarea tranzițiilor invalide.
Testarea tranziției de stat este folosită des în industria software -ului î ncorporat și în
automatizarea te hnică. Cu toate acestea, tehnica este, de asemenea, potriv ită pentru
modelarea unui obiect de afaceri cu stări specifice sau pentru testarea fluxurilor de dialog pe
ecran.
Cazuri de utilizare
Testele pot fi obținute din cazurile de utilizare. Un caz de utilizare descrie
interacțiunile dintre actori, inclusiv u tilizatorii și sistem, care produc un rezultat pentru client.
Cazurile de utilizare pot fi descrise la nivel abstract ( caz de utilizare a afacerii, fără
tehnologii, nivel de proces de af aceri) sau la nivel de sistem ( caz de utilizare a sistemului la
nivel de funcționalitate a sistemului). Fiecare caz de utilizare are precondiții ca re trebuie
îndeplinite pentru ca acesta să funcționeze cu succes.
Diana -Larisa NAP
19
Cazurile de utilizare se termină cu precondiții care sunt rezultate le observabile și
starea finală a sistemului după ce cazul de utilizare a fost completat. Un caz de utilizare are,
de obicei, un scenariu principal dar și alte căi alternative.
Cazurile de utilizare descriu „fluxurile de proces‟ printr -un sistem bazat pe utilizarea
probabilă a acestora, astfel înc ât cazurile de testare derivate din cazurile de utilizare sunt cele
mai utile în descoperirea defectelor în fluxurile de proces în timpul utilizării în realitate a
sistemului. Cazurile de utilizare sunt utile pentru proiectarea testelor de acceptare cu
participarea utilizatorilor. De asemenea, ele ajută la descoperirea defectelor de integrare
cauzate de interacțiunea și interferența diferitelor componente, pe care testarea individuală a
componentelor nu le -ar vedea. Proiectarea cazurilor de testare din cazu rile de utilizare poate
fi combinată cu alte tehnici de testare bazate pe specificații.
3.2 White box
Structura pe bază de testare sau white -box se bazează pe o structură identificată a
software -ului sau a aplicației de sistem. La ni velul component ei av em structura software a
acesteia, adică declarații, decizii, ramuri sau chiar căi distincte. Nivelul de integrare descrie o
structură care poate fi un arbore de apel, adică o diagramă în care modulele apelează alte
module. În caz ul nivelului de sistem stru ctura poate fi o structură tip meniu, un proces de
afaceri sau o structură a paginii web.
În această secțiune, sunt discutate trei tehnici de testare structurală legate de cod
pentru acoperirea acestuia pe baza declarațiilor, sucursalelor și a deciziilor . Pentru testarea
deciziei, se poate utiliza diagrama de flux de control pentru a vizualiza alternativele pentru
fiecare decizie.
Testarea și acoperirea declaraț iilor
În testarea componentelor, acoperirea declarațiilor se referă la evaluarea procentului
de declarații execu tabile care au fost exercitate de o suită de teste de testare. Această tehnică
de testare a declarațiilor derivă din caz uri de testare pentru a exercita declarați ile specifice, în
mod normal, pentru a spori acoperirea acestora.
Raportul de acoperire este determinat de numărul de decla rații executabile acoperite
de teste care este împărțit la totalul declarațiilor executabile din codul testat.
Testarea ș i acoperirea deciziilor
Sfera de acoperire a deciziei, referitoare la test area sucursalelor, este evaluarea
procenta jului de rezultat al deciziei ( de exemplu opțiunile de TRUE sau FALSE, adică
adevărat sau fals, ale unei instrucțiuni IF) care au fost exercitate de o suită de teste. Tehnica
de testare folosită derivă din cazuri d e testare executate pentru anumite decizii specifice.
Sucursalele formează punctele de decizie din cod.
Gradul de acoperire a deciziei este determinat de numărul tuturor rezultatelor deciziei
acoperite de cazurile de testare împărțite la totalul rezultat elor decizionale posibile din codul
testat.
Decizia de testare este o formă de testare a fluxului de control, deoarece urmează un
flux specific de control prin punctele de decizie. Acoperirea deciziei este mai puternică decât
Diana -Larisa NAP
20
acoperirea declarațiilor, ad ică 100% din acoperirea deciziei garantează că și declarațiile sunt
acoperite în proporție de 100%, dar invers nu se poate spune același lucru.
Alte tehinici bazate pe structură
Există niveluri mai puternice de acoperire structurală dincolo de acoperir ea deciziei,
cum ar fi acoperirea condițiilor și acoperirea condițiilor multiple.
Conceptul de acoperire poate fi aplicat și la alte niveluri de testare, de exemplu la
nivelul de integrare, procentul de module, componente sau clase care au fost exercitat e de o
suită de tes te care ar putea fi exprimate ca acoperire de module, componente sau clase.
3.3 Tehnici bazate pe experiență
Testarea bazată pe experiență este cea în care testele sunt derivate din abilitățile și
intuiția testerului și din experien ța lor cu aplicații și tehnologii similare. Atunci când este
folosit pentru a spori sistematic tehnicile, aceste tehnici pot fi utile în identificarea testelor
speciale care nu sunt capturate cu ușurință de tehnicile formale, mai ales atunci când sunt
aplicate după mai multe abordări formale. Cu toate acestea, această tehnică poate genera
grade diferite de efica citate, în funcție de experiența testeri lor.
Este o tehnică ce se bazează pe ghicirea erorilor și este folosită în mod obișnuit fiind
bazată pe ex periență.Tehnicile bazate pe experiență sunt apreciate în general de către testeri .
Diana -Larisa NAP
21
4. Prezentare a conceptului de testare manuală la nivel de sistem
4.1 Prezentarea conceptului nostru
Breakout 1 Breakout 2
Figura 4.1 Schema bloc pentru partea manual ă
Partea manuală a proiectului este construită din două cutii, prima cutie reprezentând
partea de intrări iar cea de -a doua partea de ieșiri unde vom avea atașate be curile și motorul
de la ștergătoare, între ele este reprezentat BCM (Body Control Module).
BCM este modulul de control al diverselor accesorii electrice din corpul unui autovehicul. În
mod normal rolul BCM -ului este de a controla
toate comenzile pe care le dăm, el comunică cu
alte calculat oare din bord prin intermediul
„autobuzului vehiculului‟ . Aplicația principală
este de a controla releele care, la rândul lor
efectuează diverse acțiuni în autovehicul.
Acțiuni pe care putem să le dăm: sistemul de
climat izare, reglare oglinzi, controlarea
geamurilor, pornirea casetofonului, blocarea
ușilor etc., în cadrul proiectului vom prezenta
doar farurile mașinii, semnalizarea direcției de
mers, iluminat interior și ștergătoarele .
În figura 4.3 este prezentată p artea de intrări (input) pentru DUT -ul testat. În partea de sus
avem conexiunile necesare conectării ulterioare a unui sistem de testare automată, iar în
partea de jos avem butoanele pe care le folosim pentru a exemplifica apăsarea unui buton din
interioru l mașinii în contextul activării funcționalității dorite.
Fiecare buton este conectat la câte un pin de intrare al DUT -lui, care o dată apăsa t va
crea o cerere de activare a unui pin de ieșire aferent funcționalității cerute (ex.
Semnalizare/Hazard (lumi ni de avari i)), activarea pinului de ieșire se poate observa pe cutia
reprezentată în figura 4.5 , care conține toate ieșirile aferente funcționalităților selectate.
Pentru a aprinde farul drept al mașinii, trebuie în primul rând să activăm butonul 4 și 5 ,
fiecare buton fiind numerotat în partea dreaptă jos, ceea ce semnifică că mașina a fost pornită,
iar apoi activăm butonul 1 pentru a porni farul drept. Aceleași proceduri trebuie făcute și
pentru a pune în funcțiune restul funcționalităților pe care le a vem.
Input
Output BCM
Figura 4.2 Exemplu plăcuță BCM
Diana -Larisa NAP
22
Figura 4.3 Schema pentru cutia de intrări
În figura 4.4 avem prezentată cea de -a două cutie unde vor fi legate toate tipurile de
sarcini pe care le folosim (becuri, motoare, actuatoare) și parte a laterală a cutiei și se pot
observa punc tele unde se vor realiza conexiunile dintre DUT și cutie. Tot în partea laterală, a
primei cutii, avem legăturile de GND ( masă sistemului sau terminalul minus) și Vbatt
(terminalul plus sau firul cald), între cele două se găsește tensiunea d e alimentare de ~ 12 V.
Figura 4.4 Schema pentru cutia de ieșiri
Diana -Larisa NAP
23
4.2 Ce presupune testarea manuală ?
Testarea manuală de fapt testează codul software implicând mai multe cazuri de
testare care se rulează fără ajutorul echipamentelor automatizate. În acest caz, testării se află
în spatele ecran ului și efectuează diverse teste pentru a vedea ce funcționează, comparând
rezultatul obținut cu rezultatul așteptat. Dacă în timpul rulării unui test, se detectează o
eroare, aceasta trebuie descoperită și în codul sursă.
Fiecare aplicație trebuie test ată manual, înainte de automatizare, acesta fiind un mod
în care se determină testabilitatea sistemului software. Chiar dacă testarea manuală presupune
mai mult efort și trebuie alocată o perioadă mai îndelungată de timp, aceasta este necesară
pentru a asi gura calitatea ridicată a software -ului.
Testarea manuală este preferabilă pentru testele care se rulează de un număr mic de
ori, însă atunci când pentru un release trebuiesc repetate mai multe seturi de teste poate
deveni monoton și presupune pierdere de timp.
Chiar dacă acest tip de testare este ușor, poate fi extrem de provocator deoarece
necesită multă atenție și abilități analitice fiind nevoie de testeri experimentați, ceea ce ar
putea implica și costuri ridicate .
4.3 Tipuri de echipamente p entru testarea manual ă
Pentru testarea manuală avem nevoie de diferite echipamente electronice de testare
care sunt folosite pentru a crea diferite semnale și pentru a primi răspunsuri de la DUT. Cu
ajutorul echipamentelor se observă dacă DUT funcționeaz ă conform așteptărilor sau se pot
urmări defectele.
În general, în testarea electronică, este nevoie de o serie de echipamente de testare,
care variază, de la aparate simple cum ar fi măsurătoare de tensiune (voltmetru), măsurarea
curentului electric ( ampermetru) până la aparate mai complexe cum ar fi echipamentele de
testare automată. În domeniul automotive sunt folosite toate variațiile de echipamente pentru
a obține rezultate cât mai bune ale testelor.
Există diferite tipuri de echipamente, unele dintre ele se folosesc pentru a simula
circuitul testat, de exemplu sursele de alimentare, generator de semnale dar și aparate care
analizează răspunsurile primite cum ar fi osciloscopul.
În domeniul automotive, pentru aș -i asigura succesul, producător ii și furnizorii
trebuie să respecte standardele de siguranță și calitate. Așadar, sunt folosite și echipamente
mai avansate, diferite măsurători ( clampmetru – traducător de curent, capacimetru –
măsurarea capacității), analizatoare ( analizator cu spectru – măsurarea spectrală a energiei
semnalelor, analizator logic – testarea circuitelor digitale), sonde pentru urmărirea semnalului
dar și generatoare de semnal care îndeplinesc mai multe funcții, comparativ cu aparatele
simple.
Astfel aceste activități se vor face cu ajutorul echipamentelor electronice și a bancului
de testare (test bench).
Banca de testare permite testarea unei aplicații, prin folosirea aparatului care are
implementate diverse funcționalități ce corespund cu acțiunile din lumea real ă.
Componentele unui test bench sunt intrările, unde sunt prezentate cerințele necesare
pentru a efectua testele, ieșirile unde sunt observate rezultatele obținute la sfârșitul standului
de testare, diverse proceduri care vor transforma intrările în ieș iri dar și procedurile de
verificare care determină dacă sunt îndeplinite standardele cerute.
Diana -Larisa NAP
24
Există diverse tipuri de test bench, cum ar fi doar cele de simulare care nu conține nici
o verificare a rezultatelor, test bench complet care pe lângă driverul de simulare ne arată și
rezultatele, dar și cele hibride care este mai mult un amestec de tehnici.
În general, în test bench es te scris un fișier de cod într -un limbaj specific de simulare.
Figura 4.5 Voltmetru digital comercial verificând un prot otip
Diana -Larisa NAP
25
5. Propunerea unui concept de automa tizare a procesului testă rii
5.1 Prezentarea conceptului
Figura 5.1 Schema bloc pentru partea automat ă
Automatizarea proiectului, după cum se poate observa în figura 5. 1, presupune
folosirea m ai multor componente pe care le voi detalia în următoarele rânduri.
Pentru partea de logică și control am folosit o placă Arduino Uno, care este un
microcontroler cu 14 intrări / ieșiri digitale, 6 intrări analogice, un cristal de cuarț de 16 Mhz,
o mufă de alimentare, conexiune USB, un antet ICSP (In -Circuit Programming Serial) și un
buton de resetare.
Există mai multe tipuri de plăcuțe Arduino, cu ar fi Arduino Leonardo, Arduino
Nano, Ardino Micro etc., însă plăcuța pe care am folosit -o se numește A rduino Uno. Uno
reprezintă cifra unu în limbă italiană și marchează lansarea unui program Arduino Software
1.0 care a evoluat acum la versiuni mai noi. Placa Arduino Uno este prima pe care o găsim
într-o serie de plăci USB Arduino.
Placa Arduio Uno poat e fi programată cu software -ul dorit, vine programată din
fabrică cu un bootloader care permite încărcarea unui cod fără a utiliza un program hardware
extern. Însă există și posibilitatea de a trece de bootloader și să fie programat
microcontrolerul prin i ntermediul ICSP utilizând un Arduino ISP.
Deși majoritatea calculatoarelor au protecție internă pro prie, Arduino Uno are o
polifuză resetabilă care protejează porturile USB în caz de supracurent. Dacă pe portul USB
este aplicată o valoare mai mare de 5 00 mA, siguranța va întrerupe automat conexiunea până
când suprasarcina va fi eliminată.
Arduino se alimentează prin conexiunea USB cu ajutorul unei surse externe de
alimentare. Placa poate funcționa pe o sursă externă de la 6 la 20 volți. Dacă sunt uti lizați mai
puțin de 7V, pinul 5V poate furniza mai puțini volți, iar dacă sunt utilizați mai mult de 12V,
regulatorul de tensiune se poate supraîncălzi și placă se poate deteriora. Așadar, intervalul
recomandat este între 7 și 12 volți.
Unul dintre pini i de alimentare este pinul Vin care se folosește atunci când este
utilizată o sursă externă de alimentare, alta față de cei 5V de la conexiunea USB sau de la o
altă sursă de alimentare care este deja reglată. Pinul 5V scoate o tensiune regulată de la
gener atorul de pe placă. Placa poate fi alimentată de la mufa de alimentare DC cu o tensiune
între 7 -12V, conectorul USB al plăcii de 5V sau de la pinul Vin, 7 -12V. Tensiunea de
alimentare prin pinul de 5V dar și prin cel de 3,3V, unde rezistența curentului ma xim este de
50mA, ocolește regulatorul de tensiune și în cazul în care aceasta nu este reglată
corespunzător poate deteriora placa.
Diana -Larisa NAP
26
Pe placă Ardui no întâlnim pinii de masă (GND) , dar și pinul IOREF care are ro lul de
a furniza referința de t ensiune cu c are funcționează microcontrolerul. Tensiunea din acest pin
poate fi citită și se selectează sursa de alimentare adecvată sau poate activa traducătorii de
tensiune pe ieșiri pentru a funcționa cu 5V sau 3,3V.
Cei 14 pini digitali pot fi utilizați ca pini de intrare sau pini de ieșire, utilizând
funcțiile pinMode(), digitalWrite() și digitalRead(). Aceștia funcționează la 5 volți, pentru a
nu deteriora microcontrolerul nu se folosesc mai mult de 40 mA, valoarea recomandată fiind
de 20 mA.
Pinii seriali 0(RX) și 1(TX) sunt folosiți pentru a recepționa, respectiv a transmite
datele seriale.
Există și doi pini externi care pot fi configurați pentru a declanșa o întrerupere la o
valoare scăzută. Se implementează cu ajutorul funcției attachInterrupt().
Pinii digitali cu PWM, respectiv pinii 3, 5, 6, 9, 10 și 11 asigură ieșirea pe 8 biți cu
ajutorul funcției analogWrite(). Pinii SPI, 10 (SS), 11 (MOSI), 12 (MISO), 13 (SCK) sunt
pinii care folosesc librăria SPI pentru comunicarea SPI. La pinul 13 este cone ctat un LED
încorporat care atunci când pinul este HIGH, este pornit, iar atunci când pinul este LOW este
oprit, ledurile RX și TX se vor aprinde intermitent când datele sunt transmise prin c ip USB –
to-serial și a fost realizată conexiunea USB la computer. Pinul A4 sau SDA și pinul A5 sau
SCL suportă com unicarea TWI folosind biblioteca Wire.
Cele 6 intrări analogice, numerotate de la A0 la A5, oferă 10 biți de rezoluție, adică
1024 de valori diferite. Există și doi pini de bord, AREF folosit pentru tensi unea de referință
a intrărilor analogice cu funcția analogReference(), dar și pinul RESET care resetează
microcontrolerul, în cazul în care este adăugat un buton extern față de cel existent deja pe
placă.
Arduino dispune de o serie de facilități pentru a comunica cu un computer sau cu alte
microcontrolere. ATmega328 oferă comunicație serială URAT TTL, care este disponibilă pe
pinii RX și TX. ATmega328 de pe placa de canale comunică seria l prin USB și apare ca un
port virtual pentru software -ul de pe com puter.
Figura 5.2 Placa Arduino Uno
Pentru partea de afișare în execuție am folosit un ecran LCD 16×2, I2C. Ecranul LCD
este folosit pentru a proiecta diferite mesaje, care au fos t transmite prin cod pe plăcuța
Ardunio. În realizarea proiectului e ste folosit un ecran LCD cu interfață I2C, este aleasă
această metodă deoarece în acest mod sunt folosiți mai puțini pini pentru a utiliza produsul
Diana -Larisa NAP
27
comparativ cu numărul de pini care ar trebui folosiți pentru un ecran LCD obișnuit. I2C este
protocolul de c omunicare dintre LCD și Arduino, fiecare dispozitiv cu care comunică
Arduiono pe I2C are o adresă specifică. Pentru conectarea ecr anului vom folosi doar 4 pini
(VCC, GND, SDA și ȘCL) care sun notați pe partea din spate a ecranului.
Ecranul LCD are 16 ca ractere în lățime și 2 rânduri, este vizibil și ușor de citit
datorită contrastului care este reglabil dar și datorită scrierii cu text alb pe funda l albastru.
Setul de caractere î ncorporat acceptă text englezesc, japonez etc..
Conexiunea cu placă Ardu ino se realizează ușor, fiind sugerată folosirea bibliotecii
LiquidCrystal_I2C în scrierea codului.
.
Figura 5.3 Conexiune LCD – I2C la placa Arduino
Pentru execuție folosim interfețe de control. Butoanele ne vor ajuta să controlăm
textul care va ap ărea pe ec ranul LCD, trei butoane care îndeplinesc urmă toarele
funcționalități: up, ok și down.
Conectarea se face cu ajutorul a trei fire, unul dintre a cestea trebuie conectat la sursa
de 5V de pe placa Arduino, altul trebuie conectat la GND, iar ultimu l fir trebuie legat la unul
dintre pinii digitali. Același picior al butonului trebu ie legat la o rezistență de 10 K Ohm, rolul
acesteia este de a limita consumul de curent la apăsarea butonului, iar cealaltă parte a
butonului se conectează la sursă de 5V. Când butonul nu este apăsat valoarea citită o
considerăm ca fiind LOW ( GND) , iar când butonul este apăsat o considerăm că fiind HIGH
(Vbatt) .
Figura 5.4 Conexiune buton la placa arduino
În partea automatizată a conceptului întâlnim blocul de adapta re a semnalelor care au
ca scop protejarea plăcuței Arduino și adaptarea de la tensiunile sistemului de testat la
tensiunea de funcționare a plăcuței. Există diferite metode de a face această adaptare, una
dintre acestea folosirea unui divizor de tensiune, deși această metodă are un cost red us,
Diana -Larisa NAP
28
dezavantajul este că plăcuța Arduino se poate arde în cazul modificării tensiunii sistemului
testat. O altă metodă avantajoasă din punct de vedere al costului ar fi folosirea diodelor zener,
însă și această metodă at rage după sine un dezavantaj și anume faptul că în cazul în care
acesta se arde, plăcuța Arduino rămâne fără protecție.
Metoda folosită în realizarea proiectului este combinația celor prezentate mai sus și a
optocuploarelor, chiar dacă această metodă e ste mai costisitoare este cea mai avantajoasă
deoarece placa este protejată în permanență și decuplată galvanic de la circuitul de sarcină.
Figura 5.5 Schema optocuploare
Toate componentele au fost lipite pe o plăcuță de test. Placa de test este o pla că de
circuit imprimat care ajută la conectarea temporară a componentelor electronice prin creerea
unor trasee cu ajutorul pistolului de lipit.
Figura 5.6 Placă de test
Diana -Larisa NAP
29
5.2 Ce presupune automatizarea?
Automatizarea este un proces în care echipamentele execută testele pre -scrise ale unei
aplicații software și apoi compară rezultatele testelor reale cu rezultatele prognozate sau
așteptate.
Obiectivul principal al testării automate este de a simplifica cât mai mult efortul de
testare și de a automatiza m unca repetabilă ce ar trebui făcută în mod manual. Un alt scop al
testării automate este de a oferi cât mai repede rezultate pentru testele inițiale, posibilitatea de
a efectua o validare integrală a unui sistem software în timp util fără a compromite cali tatea și
fiabilitatea testării DUT, ceea ce înseamnă că trebuie găsite toate erorile pentru a crește
încrederea produsului livrat. Din acest motiv, automatizarea nu înseamnă doar scrierea și
dezvoltarea scripturilor de testare și executarea acestora în tim pul validării. Procesul de
automatizare implică și alte etape, cum ar fi stabilizarea, optimizarea, revizuirea etc., care
sunt foarte importante pentru atingerea obiectivelor.
Majoritatea proiectelor pot fi automatizate în momentul în care, doc umentul cu
testele create este „gata de automatizat‟ , adică toate testele au fost validate manual cel puțin o
dată.
Se practică această metodă deoarece în acest fel se evită reluarea dublă în cazul în
care testele sunt greșite, se evită pierderea de timp pentru c ăutarea erorilor, în cazul în care un
test automat nu este valid și nu se știe dacă problema este în DUT sau în testul scris, este
prevenită și pierderea timpului pentru implementarea funcționalităților care nu sunt încă în
DUT. Un alt motiv important pent ru care se practică această metodă, este creșterea siguranței
testelor deoarece se compară rezultatele testelor manuale cu rezultatele testelor automate.
Dacă se începe direct cu automatizarea, ne rezumăm doar la ceea ce face scenariul să
funcționeze și , de obicei, să automatizăm doar scenariile cu răspuns pozitiv, în loc să se
găsească și alte scenarii ce care s -ar putea să se întâmple în timpul execuției și să afecteze
executarea.
Stabilizarea este faza sistematică în care se fac îmbunătățiri ale co dului creat pentru a
avea un script de testare fiabil, care va furniza măsurători corecte, independente de starea
interioară a mediului de testare. Având în vedere complexitatea aparatului utilizat în
automatizare, acesta poate duce la o probabilitate mare de eroare, așadar stabilizarea codului
este obligatorie înainte de faza de validare.
Optimizarea este un proces utilizat pentr u a face codul cât mai eficient din punct de
vedere al timpului dar și al resurselor dar și pentru lizibilitate. Un cod bine o ptimizat va fi
executat rapid, ceea ce are drept rezultat o execuție rapidă a testelor automate, reprezentând
un beneficiu în perioada de validare.
Depanarea este procesul de identificare și rezolvare a defectelor care pot afecta
funcționarea corectă a testelor sau a unui sistem de testare. Această procedură are loc ori de
câte ori un rezultat al unui test nu este conform așteptărilor. În acest caz, cauza principală a
rezultatului incorect ar trebui să fie detectată pentru fixarea acesteia.
Testele au tomate trebuie revizuite pentru a efectua corectitudinea lor. Ceea ce
înseamnă că scopul revizuirii este de a găsi erori în scripturi, pentru a verifica dacă rezultatul
testelor automate se potrivește cu rezultatul testelor manuale și pentru a ne asigura c ă
specificațiile proiectului sunt respectate. În general faza de revizuire nu înlocuiește faza de
depanare, stabilizare și optimizare, este o metodă suplimentară pentru îmbunătățirea calității
scripturilor de testare și pentru verificarea dublă că totul a fost implementat conform
cerințelor.
După fazele prezentate anterior, urmează un nou pas și anume cel de stabilizare și
optimizare automată a testelor nou create, acesta implică acțiunile care trebuie cuprinse
pentru a crea un document nou stabil și opt imizat. Asta înseamnă că testele pot fi executate și
Diana -Larisa NAP
30
vor oferi întotdeauna un rezultat direct, utilizând toți pașii adecvați și folosirea minimă a
resurselor dar și a timpului. După executarea automată a testelor, respectiv după validare, ar
putea apărea e rori chiar dacă codul fiecărui test a fost verificat și revizuit independent. Aceste
erori pot fi cauzate de situații neașteptate cum ar fi alegerea unei variante greșite, eșecuri
sporadice sau neaducerea în starea inițială a DUT (testarea parametrilor pe valoarea inițială,
setarea tensiunii de alimentare pe valoarea inițială (valoarea normală) în urma testelor de
supratensiune).
Procesul general de stabilizare presupune și calcularea procentului de stabilitate adică
planificarea activității (trebuie de cis intervalul de timp necesar, numărul de execuții dar și
versiunea software, hardware și DUT), execuția tuturor testelor (testele se execută în
conformitate cu strategia stabilită), analiza rezultatelor (identificarea cauzelor ce provoacă
erori), îmbunăt ățiri (actualizarea testelor, corectarea erorilor în scripturile de testare sau în
sistem) și concluziile (analiza rezultatelor și definirea regulilor pentru testarea automată).
În validare singurele sarcini care trebuie îndeplinite, din punct de vedere al
automatizării sunt execuția tuturor testelor, analiza rezultatelor și raportarea erorilor DUT.
Validarea poate fi realizată doar dacă testele au fost trecute prin toate fazele descrise.
În final, dacă rezultatele automatizării sunt diferite faț ă de cele așteptate, înseamnă că
eroarea este cauzată de DUT, astfel testele trebuie refăcute după validare sau în timpul
acesteia și trebuie stabilizate din nou.
Testele specificate ș i revizuite
Testarea automată
Teste stabile ș i revizuite
Figura 5.7 Schema testă rii automate
Crearea testelor
Stabilizare ș i optimizare
Depanare
Revi zuire
Depanare
Stabilizarea și automatizarea testelor noi
Validare
Diana -Larisa NAP
31
5.3 Tipuri de echipamente și modele ale automatiză rii
Pentru automatizarea testelor avem nevoie de un echipament cât mai complex cu
diferite funcționalități impleme ntate. Înainte de realizarea acestor echi pamente trebuie creată
o platformă virtuală care să permită testarea funcționării aplicațiilor comparând rezultatul cu
așteptările pe care le avem în cazul unui scenariu real.
Scopul automatizărilor este de a sp ori productivitatea și de a obține un nivel de
calitate crescut și predictibil. Automatizarea este următorul pas după mecanizare, jucând un
rol important atât din punct de vedere economic cât și din punct de vedere al timpului
deoarece testele se vor rula singure și într -un timp mult mai scurt.
Figura 5.8 Echipament pentru testarea automat ă
5.4 Tehnologiile utilizate
Pentru realizarea proiectului am folosit Arduino, o platformă ușor de utilizat care ne
permite scrierea ușoară a unui cod și încărcarea acestuia prin doar câteva click -uri pe plăcuța
folosită.
Faptul că este atât de accesibi l, Arduino este folosit de mii d e utilizatori pentru
diferite proiecte, este folosit atât de începători pentru realizarea proiectelor mici, cât și de
utilizatori expe rimentați pentru realizarea unor proiecte mai complexe. Este o platformă ușor
de folosit și prin faptul că la realizarea ei au contribuit o mulțime de profesori, studenți
pasion ați și programatori din întreaga lume , reușind astfel să se ajungă la o perform anță
ridicată, având toate specificațiile necesare pentru a înțelege și a implementa toate funcțiile
care sunt necesare pentru realizarea unui proiect. Acesta este în continuă dezvoltare și se
adaptează noilor nevoi și provocări, Arduino include diverse o ferte, de la simple plăcuțe pe 8
biți până la diverse produse pentru aplicațiile Iot (Internet of Things). Un alt avantaj pe care îl
prezintă atât plăcuțele Arduino, cât și software -ul este faptul că sunt complet open -source,
adică permite utilizatorilor s ă acționeze liber asupra procesului de producție. Tot în cadrul
avantaj elor putem face referire și la costul redus, plăcile sunt relativ ieftine, iar cea mai
ieftină versiune poate fi asamblată manual dar și modulele Arduino pre-asamblate au un cost
redus .
Așadar, datorită specificațiilor de mai sus, am ales să folosesc Arduino în
implementarea proiectului meu, dar și datorită faptului că acesta poate rula pe diferite tipuri
de sisteme de operare că Linux, Windows sau Mac.
Diana -Larisa NAP
32
5.5 Implementare
Secven ța de cod 5-1
#define wiper_fast 2
#define wiper_slow 3
#define ignition_15 4
#define hazard 5
#define flasher_left 12
#define drive_door 13
În prima parte a codului avem den umiți pinii digitali, sub forma : #define nume pinul
aferent, aceștia sunt ieșirile pentru plăcuța Arduino și intrările pentru BCM.
Secven ța de cod 5 -2
#define wiper_output 6
#define wiperh_output A3
#define park_position A2
#define flasher_right_output A1
#define flasher_left_output A0
#define interior_light_output 8
#define kl30_out put 7
Apoi avem denumiți pinii digitali și analogici, sub forma: #define nume_output pinul
afferent, aceștia sunt ieșirile pentru BCM și intrările pentru placuța Arduino.
Secven ța de cod 5 -3
LiquidCrystal lcd(0);
int upButton = 11;
int downButton = 9 ;
int selectButton = 10;
În codul de mai sus, pe prima linie este adresa de I2C a LCD -ului, în headerul libră riei
aceasta este LiquidCristal(unit8_ti2cAddr) , ea reprezită proto colul de comunicare dintre LCD
și Arduino. În următoarele linii de cod avem inițializați pini pentru cele trei butoane pe care
le avem ( up, down ș i select) .
Diana -Larisa NAP
33
Secven ța de cod 5 -4
void setup()
{
serial_init();
lcd_init_function();
pin_declaration();
init_function();
pinMode(upButton, INPUT_PULLUP);
pinMode(downButton, INPUT_ PULLUP);
pinMode(selectButton, INPUT_PULLUP);
updateMenu();
}
La pornirea aplicației se va executa în primul rând funcția void setup(). Î n aceasta
apelăm diferite funcții, pe care l e vom descrie î n ceea ce urmează .
Secven ța de cod 5 -5
void loop()
{
if (!digitalRead(downButton)){
menu++;
updateMenu();
delay(100);
while (!digitalRead(downButton));
}
if (!digitalRead(upButton)){
menu–;
updateMenu();
delay(100);
while(!digitalRead(upButton));
}
if (!digitalRead(selectButton)){
executeAction();
updateMenu();
delay(100);
while (!digitalRead(selectButton));
}
}
În porțiunea de cod de mai sus citim cu ajutorul lui digitalRead dacă unul dintre cele
trei butoane este acționat.
Pentru butonul de u p, dacă acesta este acț ionat v ariabila meniu se decrementează, iar
după această etapă se ape lează funcția updateMenu(), după care se așteaptă cu ajutorul
funcț iei de delay 100 ms, apoi se așteaptă o noua acț iune a unui nou buton.
Diana -Larisa NAP
34
Pentru butonul down, dacă acesta este acți onat v ariabila meniu se incrementează, iar
după această etapă se ape lează funcția updateMenu(), după care se așteaptă cu ajutorul
funcț iei de delay 100 ms , apoi se așteaptă o noua acț iune a unui nou buton.
Pentru butonul select, dacă acesta este acționat se apele ază funcția executeAction()
pentru a executa testul selectat, apoi este apelată funcția updateMenu(), după care se așteaptă
cu ajutorul funcț iei de delay 100 ms, apoi se așteaptă o noua acț iune a unui nou buton.
Secven ța de cod 5 -6
void serial_init()
{
Serial.begin(9600);
while (!Serial) ;
Serial.println("Start \n");
}
În funcția serial_init() se stabilește î n primul rând boudrate -ul de 9600 biți/secundă ,
care reprezintă viteza de transmitere, acesta aștea ptă în bucla while până se iniț ializează
portul serial și va afișa p e ecran “start”.
Secvența de cod 5 -7
void lcd_init_function()
{
lcd.begin(16, 2);
lcd.setBacklight(1);
lcd.setCursor(0, 0);
lcd.print("Happy Testing!");
delay(2000);
}
Secvența de cod 5 -7 reprezintă, funcț ia de iniț ializare a ecranului LCD , prima linie
este responsabilă cu reprezentarea numă rului de coloane și al liniilor, ecranului pe care î l
utilizăm este format din 16 coloane și 2 linii, apoi este activat becklight și există posibilitatea
de a modifica luminozita tea ecranului. În următoarea linie de cod este setat ă poziția
matricială a ecranului, pe poziția (0, 0), după care se va scrie pe ecran “Happy testing !” timp
de 2 secunde.
Diana -Larisa NAP
35
Secvența de cod 5 -8
void pin_declaration()
{
pinMode(wiper_slow,OUTPUT);
pinMode(wiper_fast,OUTPUT);
pinMode(ignition_15,OUTPUT);
pinMode(flasher_left,OUTPUT);
pinMode(flasher_right ,OUTPUT);
pinMode(drive_door,OUTPUT);
pinMode(wiper_output,INPUT);
pinMode(flasher_left_output,INPUT);
pinMode(flasher_ right_output,INPUT) ;
pinMode(interior_light_output,INPUT);
}
Funcția pin_declaration() declară rolul pinilor pe care îi folosim, dacă aceștia sunt pini de
intrare sau pini de ieșire.
Secvența de cod 5 -9
void init_function()
{
digitalWrite(wiper_fast,HIGH);
delay(10);
digitalWrite(wiper_slow,HIGH);
delay(10);
digitalWrite(ignition_15,HIGH);
delay(10);
digitalWrite(flasher_left,HIGH);
delay(10);
digitalWrite(flasher_right ,HIGH);
delay(10);
digitalWrite(drive_door,HIGH);
delay(10);
}
În secvența de cod 5 -9, avem funcția init_f unction(), în care sunt inițializate releele,
dacă acestea sunt puse pe HIGH, pinul este dezactivat, iar releul este închis. În caz contrar ,
când sunt puse pe LOW, de exemplu digitalWrite(drive_door, LOW) , pinul este activat și
releul se deschide.
Diana -Larisa NAP
36
Secvența de cod 5 -10
while( (millis() – t0 < 1000) && (ok1==0) )
{
val = analogRead(wiper_output);
voltage = (val / 1023.0)*referenceVoltage;
if(voltage < 3.0)
{
lcd.clear();
lcd.setCursor(0, 0);
lcd.print("Test 1= ");
lcd.print("Passed");
delay(2000);
if(DEBUGG_MODE == 1)
{
lcd.setCursor(0, 1);
lcd.print("Voltage= ");
lcd.print(voltage);
delay(5000);
}
ok1=1;
}
În secvența de cod 5 -10 este începutul primului test, în cazul nostru primul test
pornește wiper -ul slow tip de câteva secunde. Așadar la început trebuie deschise releele, cum
am prezentat în secvența de cod 5 -9, apoi se măsoară timpul de începere a testului în t0, după
care se verifică dacă testul automat este în modul de debug sau nu, variabila fiind inițializată
la început. Dacă DEBUG_MO DE este 1 atunci pe serial se va printa timpul de start al
testului, iar dacă este 0 acest lucru nu va fi efectuat.
În bucla while, se verifică dacă diferența între timpul actual și timpul inițial de la
începerea testului este mai mic decât o secundă și d acă flagul ok ere valoarea 0. Urmă toarea
linie de cod scrie î n variabila val valoarea citită de pe pinul analog, în cazul nostru de pe
pinul aferent wiper -ului, după care în voltage, valoarea citită de pe pin, se va transforma în
tensiune prin folosirea f ormulei “voltage = (val / 1023.0)*referenceVoltage”. În if se verifică
dacă tensiunea este mai mică decât 3.0 V, în cazul în care aceasta este mai mică, înseamnă că
releeul este deschis, astfel motorul funcționează, se va șterge ce apare pe ecran, cursorul se va
seta pe poziția matricială (0, 0), iar pe ecranul LCD se va afișa “Test1=passed”, iar după 2
secunde se va afișa pe poziția matricială (1, 0) tensiunea înregistrată timp de 5 secunde, iar
flagul ok este setat pe 0.
Diana -Larisa NAP
37
Secvența de cod 5 -11
else
{
lcd.clear();
lcd.setCursor(0, 0);
lcd.print("Test 1= ");
lcd.print("Failed");
delay(2000);
if(DEBUGG_MODE == 1)
{
lcd.setCursor( 0, 1);
lcd.print("Voltage= ");
lcd.print(voltage);
delay(5000);
}
ok1=0;
}
}
În cazul contrar secvenței anterioare de cod, secvența 5 -11, în această secvență se va
intra dacă tensiunea măsurată este mai mare de 3.0 V, astfel testul nu va trece, iar pe ecran se
va afișa “Test2=Failed“ și pe rândul următor tensiunea înregistrată.
La finalul testului vor fi închise toate releele deschise la începutul acestuia, iar
variabilele folosite se vor reinițializa pe 0.
Pentru următoarele trei teste se vor efectua aceeași pași. În testul 2 se va activa
flasher_left și ignition_15 care vor simula aprinderea farului stâng, în testul 3 se va activa
drive_door, care simulează aprind erea becului în interiorul mașinii, iar în testul 4 este activat
wiper fas t.
Secven ța de cod 5 -12
void updateMenu() {
switch (menu) {
case 0:
menu = 1;
break;
case 1:
lcd.clear();
lcd.print(">Test1");
lcd.setCursor(0, 1);
lcd.print(" Test2");
break;
În func ția updateMenu () avem instrucțiunea switch , cu ajutorul căreia intrăm pe
poziția selecta tă. Pentru primul caz, pe ecran vor fi afisate primiele 2 teste, î ncepând de pe
poziția matricială (0, 0) , iar î n cazul în care se va apăsa buto nul ok, primul test se va executa.
Diana -Larisa NAP
38
În cazul doi pe ecran se va afișa lcd.print(">Test2") și lcd.print("Test3 "),
în acest caz după apăsarea butonului ok se va executa testul 2. A ltfel pentru fiecare dintre
cele 4 teste sunt implementate aceleași linii de cod.
Secvența de cod 5-13
void executeAction() {
switch (menu) {
case 1:
action1();
Test1();
break;
Secvența de cod 5 -13, conține funcția void e xecuteAction() , în care dacă este selectat
primul caz, se va executa prima acțiune, adi că se va testa primul test, după ce acesta se va
executa, cu ajutorul lui break, se va ieși din bucla res pectivă până când se va transmite o altă
acțiune. Avem 4 cazuri diferite, pentru fiecare test în parte.
Secvența de cod 5 -14
void action1() {
lcd.clear();
lcd.print(">Executing Test #1");
delay(1500);
}
Prezentăm funcția void acti on1 care este apelată în funcția void executeAction(),
astfel se șterge tot ce apare pe ecran, iar în timpul execuț iei testului pe acesta se va afișa
">Executing Test #1 ". Pentru execuția fiecărui test în parte pe ecran se va afișa același
mesaj, dar cu numă rul aferent testului care rulează.
Diana -Larisa NAP
39
6. Concluzii
6.1 P osibilităț i de extindere a conceptului nostru
Următoarea etapă în dezvoltarea proiectului ar fi îmbunătățirea lui din toate direcțiile
pe care le -am dezvoltat în cadrul acestuia. Una dintre c ele mai bune îmbunătățiri ar putea fi
legarea acestuia la un server și trimiterea rapoartelor pe mail, astfel putem să salvăm mult mai
ușor datele și să avem acces la ele ori de câte ori dorim din diferite locații.
Acest lucru ar presupune crearea unei baze de date SQL, identificarea informațiilor de
conexiune dar și alegerea unei metode de autentificare, cum ar fi Windows sau SQL Server.
Următorul pas ar fi crearea tabelelor pe care dori m să le legăm sau să le importă m împreună
cu câmpurile de valori u nice pentru acestea unde trebuie să luăm în considerare numărul de
coloane, deoarece acestea au o dimensiune maximă de 2 gigabyt i, iar dacă tabelele sunt prea
mari putem avea probleme cu importarea acestora într -o singură bază de date de Access.
Baza de da te și informațiile de conexiune trebuie securizate folosind o parolă de încredere. La
finalizarea execuției testelor se creează un raport al execuției iar acesta poate fi trimis prin
mail tuturor inginerilor implicați în dezvoltarea produsului.
O altă et apă în dezvoltarea proiectului ar putea fi controlarea acestuia de la distanță,
prin Wifi. În zilele noastre suntem tot mai dependenți de telefoane, tablete, laptopuri, diverse
dispozitive, iar toate acestea pot fi controlate prin rețelele wireless. Din ac est motiv, această
etapă de dezvoltare a proiectului ar putea aduce un benefic iu foarte mare deoarece în viitor
vom ajunge să controlăm absolut tot cu ajut orul internetului și ne dorim ca și proiectul să aibă
posibilitatea să facă acest lucru. Există diver se posibilități de conectare a acestuia la o rețea,
după o analiză amănunțită a acestora se va alege cea mai eficientă variantă din toate punctele
de vedere.
Bineînțeles că putem opta și pentru controlarea acestuia cu ajutorul bluetooth -ului
care ne per mite și ea o conexiune fără fir. Această metodă fiind și ea larg regăsită pe piață
actuală, folosită că un mijloc eficient de comunicare între diverse dispozitive.
Cum trăim într -o eră digitală așteptările sunt tot mai mari, deci o altă etapă importantă
în dezvoltarea proiectului ar presupune realizarea unei pagini web care să conțină cât mai
multe elemente cu ajutorul cărora se controlează proiectul. Aceasta va conține în primul rând
o fereastră unde utilizatorii se vor loga astfel fiecare dintre ei își p ot salva propriile teste pe
care trebuie să le testeze și rezultatele pe care le obțin dar și alte informații de care au nevoie.
Pagina va conține diferite butoane pentru fiecare comandă pe care dorim să o facem, dar și
diferite tabele unde se vor afișa au tomat rezultatele și tabele unde vor adăuga observațiile
necesare. Pentru ca pagina să fie cât mai eficientă se vor crea legături cu alte pagini, astfel
atunci când se vor dori mai multe informații în legătură cu funcționalitatea folosită, prin
apăsarea u nui click pe aceasta să se deschidă o altă pagină care să ofere toate detaliile
necesare. Tot în cadrul paginii s -ar putea implementa un chat în care toți utilizatorii pagini să
poată comunica între ei, fiind mult mai ușor să transmită rezultatele obținute dar și să clarifice
problemele pe care le întâlnesc pe parcurs.
6.2 Testarea î n viito r
În viitorul apropiat tot mai multe persoane vor rămâne fără locuri de muncă deoarece
tehnologia este în continuă dezvoltare și totul va ajunge să fie automatiza t.
Diana -Larisa NAP
40
După un studiu realizat de Organizația Internațională a Muncii, în Asia, s -a constatat
faptul că în următoarele două decenii mai mult de jumătate dintre muncitori își vor pierde
locurile de muncă din cauza automatizării, atât cei din domeniul confecț iilor cât și din alte
domenii.
Figura 6.1 Roboț ii umanodiali
După cum se observă și în figura 6.1 , de mai sus, în viitor în toate fabricile vor lucra
doar roboții fiind nevoie de un număr redus de persoane care probabil vor trebui doar să
supraveg heze că totul funcționează așa cum trebuie, iar în caz contrar vor remedia acest
lucru.
Cel mai mare risc de automatizare îl reprezintă sectorul de textile, încălțăminte și
îmbrăcăminte din industriile ce au fost analizate în studiul făcut, însă un risc destul de ridicat
îl reprezintă și domeniul automotivelor ce includ piesele auto, electrice și electronice.
În domeniul automotivelor întâlnim un procentaj crescut al persoanelor ce riscă să
rămână fără locuri de muncă, respectiv peste 60% în Indone zia și peste 70% în Thailanda.
În urma studiului s -a ajuns și la concluzia că sectorul auto din Asia de Sud -Est este declarat
ca fiind unul dintre cele mai mare producător de autovehicule, unde în viitorul apropiat toate
testele vor fi făcute automat și a stfel este nevoie de un număr cât mai mic de persoane.
În concluzie, testarea în viitor va evolua tot mai mult din toate punctele de vedere,
chiar dacă acest lucru este un avantaj, căci totul va fi automatizat și se se vor realiza cât mai
multe teste în tr-un timp mult mai scurt comparativ cu testarea manuală care ar presupune
alocarea unei perioade îndelungate de timp, atrage după sine și un dezavantaj și anume faptul
că tot mai multe persoane vor rămâne fără locuri de muncă.
Diana -Larisa NAP
41
6.3 Concluzii
Datorită fap tului că am realizat un proiect complet, atât din punct de vedere software
cât și din punct de vedere hardware, am avut posibilitatea de a învăța diverse lucruri. Pe
parcursul realizării am întâmpinat diverse probleme pe care am reușit să le remediez cât m ai
bine posibil.
Una dintre problemele întâmpinate au fost legate de partea hardware, deoarece unul
dintre fire, respectiv firul de la wiper low din cutia de inputuri nu a fost lipit bine și astfel nu
se executau bine testele, însă problema a fost reme diată.
Un pas important a fost implementarea testelor deoarece am ținut cont de cele mai
esențiale funcționalități din cadrul unei mașini pe care le utilizăm zi de zi, încercând să aduc
o complexitate proiectul ui. Am creeat un design cât mai plăcut și u șor de folosit care aduce
un plus important pentru utilizator fiind și ușor de folosit, fiecare fir și buton având scris ce
semnifică.
O altă etapă importantă a fost construcția propriu -zisă deoarece a trebuit să țin cont
de diferite probleme pe care am putea să le întâmpinăm pe parcursul folosirii deoarece se
lucra cu diferite tensiuni, chiar dacă acestea nu au o putere foarte mare, o simplă greșeală
poate duce la arderea plăcuței sau a altor componente. Chiar dacă din punct de vedere
financiar nu a fos t cea mai bună alegere, am optat pentru calitatea sporită a acestora, putând
astfel să folosim proiectul pe o perioadă cât mai îndelungată ținând cont și de siguranță
utilizatorilor.
Cu ajutorul acestor aspecte, am reușit să realizez un proiect de diplo mă deoarece am
căutat cele mai optime componente, încercând să aduc un plus lucrării explicând atât prin
scheme, imagini cât și prin specificații tot ce am folosit în cadrul acestuia.
Am reușit să realizez o lucrare completă, îmi doresc că aceasta să fi e folosită de cât
mai multe persoane și să fie un pas important în ceea ce presupune un început în învățarea a
ceea ce înseamnă testarea în domeniul automotive.
Diana -Larisa NAP
42
Diana -Larisa NAP
43
7.Bibliografie
[1] – International Software Testing Qualific ations Board – Continental Automotive
[2] – A Discipline for Software Engineering – Addison -Wesley Longman Publishing Co.,
Inc. Boston, MA, USA ©1995
[3] – M. A. Breuer, Intelligible testing, Proc. 4 Multimedia Technology and Applications
Symp., p p 11-19, April 16, 1999, Kaohsuing, Taiwan
[4] – Automated testing of computer system components Conan Chan Ming Yam Terence
[5] – Cuixiong Hu , Iulian Neamtiu, Automating GUI testing for Android a pplications,
Proceedings of the 6th International Workshop on Automation of Software Test, May 23 -24,
2011, Waikiki, Honolulu, HI, USA
[6] – M. Schneider, P. Merkle, and K. Hahmann. Test bench for complex ECU networks.
www.vector.com, Oct. 2013
[7] – Gehring, J. and Schütte, H., "A Hardware -in-the-Loop Test Bench for the Validation of
Complex ECU Networks," SAE Technical Paper 2002 -01-0801, 2002 – Jürgen Gehring,
Herbert Schütte
[8] – Roboții umanoidali lucrează alături de angajații din linia de asambla re într -o fabrică a
companiei Glory Ltd., producătorul de dozatoare automate de schimbare, în Kazo, la nord de
Tokyo, Japonia, 1 iulie 2015. REUTERS / Issei Kato
[9] – Spiral model (Boehm, 1988). A number of misconceptions stem from
oversimplifications in this widely circulated diagram (there are some errors in this diagram)
[10] – Clarus Concept of Operations. Archived 2009 -07-05 at the Wayback
Machine Publication No. FHWA -JPO-05-072, Federal Highway Administration (FHWA),
2005
[11] – "Waterfall Software Development Model" . 5 February 2014 . Retrieved 11
August 2014
[12]- https://www.scribd.com/doc/170257040/Laza -Stefanescu -Guta -Popescu -Lungu -443A –
CICLUS
[13] – https://store.arduino.cc/arduino -uno-rev3
[14]- https://www.theguardian.com/sustainable -business/2016/jul/16/robot -factories -threaten –
jobs-millions -garment -workers -south -east-asia-women
[15] – https://www.reuters.com/article/us -southeast -asia-jobs-idUSKCN0ZN0HP
Diana -Larisa NAP
44
Diana -Larisa NAP
45
DECLARAȚIE DE AUTENTICITATE A
LUCRĂRII DE FINA LIZARE A STUDIILOR
Subsemnatul _____________________________________________________,
legitimat cu _______________seria ________nr. ________________________,
CNP _____________________autorul lucrării___________________________
_________________________ _________________________________________
______________________________________________________________
elaborată în vederea susținerii examenului de finalizare a studiilor de licență
________________________________________________________________org
aniza t de către Facultatea de Automatică și Calculatoare din cadrul Universității
Politehnica Timișoara, sesiunea ____________________ a anului
universitar________________________, luând în considerare conținutul art. 39
din RODPI – UPT, declar pe proprie răspu ndere, că această lucrare este rezultatul
propriei activități intelectuale, nu conține porțiuni plagiate, iar sursele bibliografice
au fost folosite cu respectarea legislației române și a convențiilor internaționale
privind drepturile de autor.
Timișoara ,
Data Semnătura
_______________________ ______________________________
Declarația se completează „ de mână ” și se inserează în lucrarea de finalizare a studiilor, la sfârșitul
acesteia, ca parte
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Testarea la nivel de sistem și [632019] (ID: 632019)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.