Testarea embedded în domeniul automotive [608314]

ACP 1

Testarea embedded în domeniul automotive

Master – TSAeA

Profesor îndrumător: Student: [anonimizat]

1. Bazele testării ………………………….. ………………………….. ………………………….. …………………….. 3
1.1 Importanța testării ………………………….. ………………………….. ………………………….. …………. 3
1.2 Cele 7 principii ale testării ………………………….. ………………………….. ………………………….. 4
2. Testarea în cadrul ciclului de dezvoltare software ………………………….. ………………………….. …… 6
2.1 Nivele de testare ………………………….. ………………………….. ………………………….. ……………….. 6
2.1.1 Testarea de modul/componentă ………………………….. ………………………….. ………………… 7
2.1.2 Testarea de integrare ………………………….. ………………………….. ………………………….. …… 7
2.1.3 Testarea d e sistem ………………………….. ………………………….. ………………………….. ………. 9
2.1.4 Testarea de acceptanță ………………………….. ………………………….. ………………………….. … 9
2.2 Tipurile de testare ………………………….. ………………………….. ………………………….. …………… 10
2.2.1 Testarea funcțională ………………………….. ………………………….. ………………………….. ….. 10
2.2.3 Testarea structurală ………………………….. ………………………….. ………………………….. …… 10
2.2.4 Retestarea ………………………….. ………………………….. ………………………….. ………………… 10
2.2.5 Testarea regresivă ………………………….. ………………………….. ………………………….. …….. 11
3. Bibliografie ………………………….. ………………………….. ………………………….. …………………… 12

1. Bazele testării

1.1 Importanța testării
Sistemele software sunt o parte integrantă a vieții, de la aplicații pentru afaceri (ex. bancare)
la produse (ex. autoturisme). Cei mai mulți dintre oameni au experimentat produse software care
nu funcționează cum ar trebui. Produsele software care nu func ționează corect pot conduce la o
multitudine de probleme printre care pierderi de bani, timp sau reputație a diferitor branduri, și în
anumite situații se poate ajunge la vătămări sau chiar moarte.
• Eroare – acțiune a omului care produce un rezultat nedori t
• Defect – manifestarea unei erori în software
• Defectare – deviere a software -ului de la rezultatul sau serviciul așteptat. Datorită
defectării se poate identifica defectul
Cauza apariției greșelilor in sistemele software este faptul că sunt create de o ameni care
prezintă următoarele vulnerabilități :
• nu cunosc totul
• au abilități, dar nu sunt perfecți
• sunt supuși greșelii
Sub presiune crescândă pentru livrarea software -ului la termene stricte nu există timp
pentru verificări amănunțite, iar presup unerile pot fi greșite.
Deci de ce este testarea atât de necesară :
• pentru că orice software este foarte probabil sa aibă greșeli
• pentru a avea cunoștință în legătură cu fiabilitatea software -ului
• pentru ca defecțiunile pot produce costuri suplimentare mari
• poate reduce riscul apariției problemelor și poate contribui la calitatea softwareului
dacă defectele identificate sunt corectate înainte de lansarea softului
furnizarea
de informație către pă rțile interesate

Testarea și calitatea – prin intermediul testării este posibilă determinarea nivelului calității unui
soft. Testarea poate conferii încredere în nivelul calității unui soft dacă sunt identificate puține
defecte sau chiar deloc. Calitate a sistemului crește atunci când defectele identificate sunt corectate.
Testarea este una dintre activitățile prin care este asigurată calitatea.
Pentru a determina câtă testare este suficientă trebuie ținut seama de nivelul de risc al sistemului,
inclus iv siguranța tehnică, dar și constrângerile specifice proiectului cum ar fi timpul și bugetul.
Testarea trebuie să furnizeze suficiente informații părților interesate pentru a lua decizii
documentate în privința lansării soft -ului, pentru următorul pas în dezvoltarea lui și predarea către
clienți.

Obiectivele testării – printre obiectivele care trebuie atinse prin intermediul testării se numără
identificarea defectelor, asigurarea unui nivel de încredere asupra nivelului de calitate al
produsului, furniz area de informații pentru luarea de decizii, prevenirea erorilor, etc.

1.2 Cele 7 principii ale testării
1.2.1 Testarea indică prezența defectelor
• Testarea poate arăta că defectele sunt prezente
• Testarea reduce probabilitatea ca defecte neidentificate să rămână în soft
• Faptul că nu sunt identificate defecte nu este o dovadă a corectitudinii soft -ului
1.2.2 Testarea exhaustivă este imposibilă
Ce este testarea exhaustivă ?
• Executarea tuturor sc enariilor posibile Cât timp ar lua testarea
exhaustivă ?
• O cantitate impracticabilă de timp
1.2.3 Testarea timpurie
• Activitățile de testare trebuie începute cât de devreme posibil în ciclul de viață al dezvoltării
unui soft sau a unui sistem
• Pregătirea timpurie a mediului/instrumentelor de testare
• Poate prevenii multiplicarea erorilor
• Depistarea erorilor din timp permite corectarea acestora la costuri reduse
1.2.4 Defectul de grupare (Defect clustering)
• Un număr redus de module conțin ce le mai multe dintre defectele detectate în timpul
testelor de pre -lansare sau prezintă cele mai multe defecțiuni de funcționare.
• Principiul Pareto : aproximativ 80% dintre probleme sunt cauzate de 20% dintre module
• Acțiuni : alocarea de timp mai mult pe ntru a testa zona respectivă a aplicației pentru a găsi
cât mai multe defecte posibile
1.2.5 Paradoxul pesticidului
• Dacă același set de cazuri de test sunt executate din nou și din nou există posibilitatea ca
prin intermediul acestui set de cazuri de test sa nu se mai poată identifica nici un bug
• Este necesar ca testele sa fie revizuite și actualizate periodic
• Teste noi trebuie scrise periodic pentru a verifica părți diferite ale sistemului sau soft -ului
pentru a crește probabilitatea găsirii de noi erori.
1.2.6 Testarea este dependentă de context
• Testarea se realizează diferit în contexte diferite

• Un softwa re considerat critic pentru siguranța celor care utilizează sistemul este testat în
mod diferit de un site de vânzări
1.2.7 Aberația absenței erorilor
 Găsirea și corectarea defectelor nu ajută în cazul în care sistemul construit este
inutilizabil și nu îndeplinește nevoile și așteptările utilizatorilor

2. Testarea în cadrul ciclului de dezvoltare software
2.1 Nivele de testare

Fig. 1 Modelul în V de dezvoltare software

Verificare
• Construim produsul într -un mod corect?
• Procesul în care evaluăm sistemul sau o componentă a acestuia pentru a determina
dacă rezultatele dintr -o anumită fază de dezvoltare satisfac condițiile impuse la
începutul respectivei faze
Validare
• Construim pro dusul care trebuie ?
• Determinarea dacă rezultatele dezvoltării software sunt în concordanță cu nevoile
și cerințele beneficiarului
Testare
 Procesul de executare a soft -ului pentru a verifica dacă satisface cerințele
specificate și pentru a identifica defectele

2.1.1 Testarea de modul/componentă
Testarea de modul constituie nivelul cel mai de jos al testării și se realizează prin testarea
în mod separat/izolat al fiecărui modul. În cele mai multe dintre cazuri este necesară o analiză
detaliată a fiecărui modul. De cele mai multe ori acest tip de testare se realizează de către
dezvoltator. Mai este cunoscută ca și testare de unitate, componentă, modul, program.
2.1.2 Testarea de integrare
Se testează mai mult de un modul/o componentă și presupune verificarea modului în care
se face comunicarea/conexiunea între acestea. Se testează interacțiunea dintre componentele
sistemului.

Integrarea de tip Big -Bang

Sunt integrate într -un program executabil toate modu lele existente la un moment dat.
Modulele "driver" și "ciot" necesare sunt de asemenea integrate. Metoda este periculoasă căci toate
erorile apar în același timp și localizarea lor este dificilă.

Integrarea incrementală/progresivă

Metodele de integr are progresivă sunt mult mai eficiente. In fiecare moment se adaugă
ansamblului de module integrate numai un singur modul. Astfel, erorile care apar la un test provin
din modulul care a fost ultimul integrat. Avantajele acestei metode constau în faptul că defectele
ar fi mai ușor de identificat și respectiv corectat.

Integrarea descendentă (de sus în jos)

Pași :
• Pasul 1 : componenta a
• Pasul 2 : a+b
• Pasul 3 : a+b+c
• Pasul 4 : a+b+c+d
• etc

Se începe prin testarea modulului principal, apoi se testează programul obținut prin
integrarea modulului principal și a modulelor direct apelate de el, și așa mai departe. Metoda
Fig. 2 Integrarea descendentă

presupune implementarea unui singur modul "driver" (pentru modulul principal ) și a câte unui
modul "ciot" pentru fiecare alt modul al programului.
Integrarea descendentă poate avea loc pe parcursul unei implementări descendente a
programului. Modulul principal este testat imediat ce a fost implementat, moment în care nu au
fost încă implementate modulele apelate de el. De aceea, pentru testare este necesar să se
implementeze module "ciot". In continuare, pe măsură ce se implementează modulele de pe nivelul
ierarhic inferior, se trece la testarea lor folosind alte module “ciot”, ș.a.m.d. In fiecare pas este
înlocuit un singur modul "ciot" cu cel real. “Cioturile” sunt defapt porțiuni de cod care simulează
funcționalitatea componentelor neintegrate ori nedezvoltate încă. Avantajele testării de sus în jos
:
• Erorile de proiectare sunt descoperite timpuriu, la începutul procesului de integrare atunci
când sunt testate modulele principale ale sistemului.
Programul obținut este mai fiabil
căci principalele module sunt cel mai mult testate
• Prin testarea modulel or de nivel superior se poate considera că sistemul în ansamblul său
există dintr -o faza timpurie a dezvoltării și deci se poate exersa cu el în vederea validării
cerințelor Dezavantaje :
• Este necesar să se implementeze câte un modul "ciot" pentru fiecar e modul al programului,
cu excepția modulului principal
• Este dificil de simulat prin module "ciot" componente complexe și componente care conțin
în interfață structuri de date
• În testarea componentelor de pe primele nivele, care de regulă nu afișează rez ultate, este
necesar să se introducă instrucțiuni de afișare, care apoi sunt extrase, ceea ce presupune o
nouă testare a modulelor

Integrarea de jos în sus

Pași :
• Pasul 1 : componenta n
• Pasul 2 : n+i
• Pasul 3 : n+i+o
Pasul 4 : n+i+o+d
• etc.

Se începe prin testarea modulelor care nu apelează alte module, apoi se adaugă progresiv
module care apelează numai modulele deja testate, până când este asamblat întregul sistem.
Metoda necesită implementarea câte unui modul "driver" pentru fiecare modul al programului (și
nici un modul "ciot").

Fig. 3 Integrarea ascendentă

Avantajele testării de jos în sus :
• Nu sunt necesare module "ciot". Modulele "driver" se implementează mult mai ușor
decât modulele "ciot" Dezavantaje
• Programul pe baza căruia se efectuează validarea cerințelor este disponibil numai
după testarea ultimului modul
• Corectarea erorilor descoperite pe parcursul integrării necesită repetarea procesului
de proiectar e, codificare și testare a modulelor. Principalele erori de proiectare sunt
descoperite de abia la sfârșit, când sunt testate modulele principale ale programului.
ceea ce, în general, conduce la reproiectare și reimplementare
2.1.3 Testarea de sistem
Acestea sunt teste ale sistemului de programe și echipamente complet. Sistemul este
instalat și apoi testat în mediul său real de funcționare. Sunt teste de conformitate cu specificația
cerințelor de sistem (software) :
teste funcționale, prin care se ver ifica satisfacerea cerințelor funcționale
teste prin care se verifica satisfacerea cerințelor ne -funcționale :
o de performanță,
o de fiabilitate,
o de securitate, etc.
Adesea, testele de sistem ocupă cel mai mult timp din întreaga perioadă de testare.
2.1.4 Testarea de acceptanță
Sunt teste de conformitate cu produsul solicitat, conform contractului cu clientul ( ->Specificația
cerințelor utilizatorilor). Aceste teste sunt uneori conduse de client. Pentru unele produse
software, testarea de acceptare are loc în două etape:
Testarea alfa: se efectuează folosindu -se specificația cerințelor utilizatorilor, până când cele două
părți cad de acord că programul este o reprez entare satisfăcătoare a cerințelor.
Testarea beta: programul este distribuit unor utilizatori selec ționați, realiz ându-se astfel testarea
lui în condi ții reale de utilizare.

2.2 Tipurile de testare
2.2.1 Testarea funcțională
Testarea funcțională est e canalizată pe verificarea cerințelor funcționale ale aplicației.
Acest tip de testare trebuie executat de către testeri. Asta nu înseamnă că programatorii nu ar trebui
să își verifice codul, asta firește se aplică oricărui stadiu al testării.
Testare de tip black box care nu se bazează pe cunoașterea internă a design -ului sau a
codului. Testele sunt bazate pe cerințe și funcționalitate.
2.2.2 Testarea nefuncțională
Termenul de testare nefuncțională descrie testele necesare pentru a măsura c aracteristici
ale sistemului sau/și software -ului care pot fi cuantificate, cum ar fi timpul de răspuns în cazul
testării de performanță. Rezultatele acestor teste pot fi raportate la un model de calitate al
produselor software. Testarea nefuncțională incl ude, dar nu se limitează la, testarea de
performanta, testarea de stres, testarea de utilitate, testarea de fiabilitate și testarea de
portabilitate,
Testarea nefuncțională ia în considerare comportamentul extern al software -ului și în cele
mai multe di ntre cazuri pentru a fi realizată se utilizează tehnici de proiectare ale testării black box.
Acest tip de testare poate fi aplicată la toate nivelurile de testare.
2.2.3 Testarea structurală
Acest tip de testare se bazează pe cunoașterea logicii intern e a codului aplicației. Testele
sunt bazate pe acoperirea sintaxei de cod, ramuri, căi, condiții. Presupune parcurgerea structurii
codului.
Acest tip de testare este o modalitate de măsurare a rigurozității testării prin acoperirea unui
set de elemente s tructurale sau elemente de acoperire.
Se poate aplică la orice nivel de testare, dar este cel mai probabil să fie utilizată la testarea
de componentă și la cea de integrare. Este mai puțin probabil să fie utilizată la nivelri mai mari de
testare (struct ura unui meniu de exemplu, la nivel
de sistem).
2.2.4 Retestarea
Presupune reexecutarea unor teste prin
intermediul cărora în trecut s -au identificat
defecte și care între timp se presupune că au
fost corectate.

Fig. 4 Retestarea

2.2.5 Testarea regresivă
Intră în această categorie testele executate după corectarea erorilor, pentru a se verifica
dacă în cursul corectării nu au fost introduse alte erori. Aceste teste sunt executate de regulă în
timpul întreținerii.

Fig. 5 Testarea regresi vă

3. Bibliografie

1. http://www.softwaretesting.ro/Romana/Files/Services/Software%20Testing%20Services.html
2. http://www.istqb.org/downloads/category/15 -foundation -level -exam -documents.html
3. http://shiva.pub.ro/cursuri/testarea -produselor -informatice -asigurarea -calitatii/