TEHNICI DE TESTARE APLICATE IN DOMENIUL AUTOMOTIVE LUCRARE DE DISERTAȚIE Autor: Claudiu -Florin PĂUȘIAN Conduc ător științific: Asis.Dr.Ing. Ioan… [610146]
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
2017
TEHNICI DE TESTARE APLICATE IN
DOMENIUL AUTOMOTIVE
LUCRARE DE DISERTAȚIE
Autor: Claudiu -Florin PĂUȘIAN
Conduc ător științific: Asis.Dr.Ing. Ioan -Valentin Sita
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
DECAN
Prof.dr.ing. Liviu MICLEA Vizat,
DIRECTOR DEPARTAMENT AUTOMATIC Ă
Prof.dr.ing. Honoriu VĂ LEAN
Autor : Claudiu -Florin PĂUȘIAN
Tehnici de testare aplicate în domeniul automotive
1. Enunțul temei: Lucrarea are ca obiectiv punerea în evidență a metodelor de testare care se
utilizează în domeniul automotive și totodată prezentarea unor funcționalități importante și
interesante din acest domeniu. S -a pus accent pe 3 funcționalități referitoare la accesul în mașină
fără a acționa cheia și la pornirea motorului utilizând Passive Start and Entry
2. Conținutul proiect ului: 1. FUNDAMENTARE TEORETICĂ , 2. IMPLEMENTAREA SOLUȚIEI ADOPTATE ,
3. REZULTATE EXPERIMENTALE , 4. CONCLUZII , 5. BIBLIOGRAFIE , 6. ANEXE
3. Locul documentației: Arobs Transilvania Software, Continental Automotive
4. Consultanți: Ing. Daniel Opris, Ing. Emil Un gureanu, Ing. Maxim Vetoschin
5. Data emiterii temei: 01.11.2016
6. Data predării: 11.07.2017
Semn ătura autorului
Semn ătura conduc ătorului științific
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
Declarație pe proprie răspundere privind
autenticitatea lucrării de diplomă
Subsemnatul(a) Claudiu -Florin PĂUȘIAN , legitimat(ă) cu CI seria SX nr. 420346 , CNP [anonimizat] ,
autorul lucrării:
TEHNICI DE TESTARE APLICATE ÎN DOMENIUL AUTOMOTIVE
elaborată în vederea susținerii examenului de finalizare a studiilor de disertație la Facultatea de
Automatică și Calculatoare , specializarea Controlul Avansat al Proceselor , din cadrul Universității
Tehnice din Cluj -Napoca, sesiunea Iulie 2017 a anului universitar 2016 -2017 , declar pe proprie
răspundere, că această lucrare este rezultatul propriei ac tivități intelectuale, pe baza cercetărilor mele și
pe baza informațiilor obținute din surse care au fost citate, în textul lucrării, și în bibliografie.
Declar, că această lucrare 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.
Declar, de asemenea, că această lucrare nu a mai fost prezentată în fața unei alte comisii de examen de
licență.
In cazul constatării ulterioare a unor declarații false, voi suporta sancțiunile administrative, respectiv,
anularea examenului de licență .
Data Claudiu -Florin PĂUȘIAN
(semnă tura)
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
SINTEZA
lucrării de disertație cu titlul:
Tehnici de testare în domeniul automotive
Autor: Claudiu -Florin PĂUȘIAN
Conduc ător științific: Asis.Dr.I ng. Ioan -Valentin SITA
1. Cerințele temei: Punerea în evidență a importanței fazei de testare în domeniul automotive.
2. Soluții alese: Testarea sistemului se face la nivel black box iar pentru a testa diferite funcții s -a
utilizat testarea manuală, automată și semiautomată.
3. Rezultate obținute: Rezultatele obținute au ca scop prezentarea comportamentului de bază al
funcționalităților testate utilizând diferite tool -uri și echip amente hardware atât pentru testarea manuală
cât și pentru cea automată.
4. Testări și verificări: Rularea testelor în medii controlate cât mai aproape de mediul real de
funcționare .
5. Contribuții personale: Realizarea documentației și implementarea păr ții practice la locul de muncă.
Analiza importanței realizării corecte a testelor asupra unor ansamble de sisteme și subsisteme din
domeniul automotive.
6. Surse de documentare: Locul de munca, documente oficiale cu caracter confidențial, conferințe
internaționale specifice domeniului automotive, documente publice despre diferite funcționalități
integrate în autovehicule .
Semn ătura autorului
Semn ătura conduc ătorului științific
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
1
CUPRINS
LISTĂ DE ABREVIERI ………………………….. ………………………….. ………………………….. ………………………….. .. 3
LISTĂ DE FIGURI ………………………….. ………………………….. ………………………….. ………………………….. …….. 4
STADIUL ACTUAL ………………………….. ………………………….. ………………………….. ………………………….. …… 6
1. FUNDAMENTARE TEORETICĂ ………………………….. ………………………….. ………………………….. ………….. 10
1.1 Introducere ………………………….. ………………………….. ………………………….. ………………………….. … 10
1.1.1 Introducere în domeniul automotive ………………………….. ………………………….. …………………. 10
1.1.2 Protocoale de comunicație utilizate în domeniul automotive ………………………….. ……………… 11
1.2 Testare – noțiuni fundamentale ………………………….. ………………………….. ………………………….. …. 12
1.2.1 Scopul și costul testării ………………………….. ………………………….. ………………………….. ……….. 12
1.2.2 Etapa de planificarea a testelor ………………………….. ………………………….. ………………………… 13
1.2.3 Analiza și crearea testelor ………………………….. ………………………….. ………………………….. ……. 14
1.2.4 Etapa de impl ementare a testelor ………………………….. ………………………….. ……………………… 15
1.2.4 Execuția și evaluarea testelor ………………………….. ………………………….. ………………………….. . 15
1.3 Modelul V – Noțiuni fundamentale ………………………….. ………………………….. …………………………. 16
1.3.1 Schema bloc a modelului V ………………………….. ………………………….. ………………………….. ….. 16
1.3.2 Nivele de testare ………………………….. ………………………….. ………………………….. ……………….. 16
1.4 Tehnici de testare ………………………….. ………………………….. ………………………….. …………………….. 20
1.4.1 Clasificare ………………………….. ………………………….. ………………………….. …………………………. 20
1.4.2 Testarea Black Box ………………………….. ………………………….. ………………………….. ……………… 20
1.4.3 Testarea White Box ………………………….. ………………………….. ………………………….. ……………. 22
1.4.4 Testarea Gray Box ………………………….. ………………………….. ………………………….. ……………… 22
1.5 Testare manuală vs testare automată ………………………….. ………………………….. ………………………. 23
1.5.1 Testare manuală ………………………….. ………………………….. ………………………….. ………………… 23
1.5.2 Testare automată ………………………….. ………………………….. ………………………….. ………………. 23
1.5.3 Testare semiautomată ………………………….. ………………………….. ………………………….. ………… 24
1.6 Passive Start and Entry ………………………….. ………………………….. ………………………….. ……………… 24
1.6.1 Easy PASE ………………………….. ………………………….. ………………………….. …………………………. 25
1.6.2 Walk Away Locking ………………………….. ………………………….. ………………………….. …………….. 25
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
2
1.6.3 Approach Unlock ………………………….. ………………………….. ………………………….. ……………….. 27
2. IMPLEMENTAREA SOLUȚIEI ADOPTATE ………………………….. ………………………….. …………………………. 28
2.1 Descrierea proc esului de dezvoltare al unui proiect ………………………….. ………………………….. ……. 28
2.2 Descrierea aplicației ………………………….. ………………………….. ………………………….. …………………. 28
2.3 CANoe ………………………….. ………………………….. ………………………….. ………………………….. ……….. 29
2.3.1 Crearea unui panou utilizând tool -ul CANoe ………………………….. ………………………….. ……….. 30
2.4 Diagnoză auto ………………………….. ………………………….. ………………………….. …………………………. 32
2.5 Echipamente utilizate în procesul de testare manuală ………………………….. ………………………….. … 32
2.5.1 Crearea cazurilor de test pentru testare ma nuală ………………………….. ………………………….. … 34
2.6 CANoe Testing Tool ………………………….. ………………………….. ………………………….. ………………….. 38
2.6.1 Automatizarea testelor utilizând limbajul de programare CAPL ………………………….. …………… 39
2.6.2 Crearea cazurilor de test pentru testare automată și semiautomată ………………………….. ……. 40
3 REZULTATE EXPERIMENTALE ………………………….. ………………………….. ………………………….. ……………. 49
3.1 Rezultate experimentale pentru testarea manuală ………………………….. ………………………….. …….. 49
3.2 Rezultate experimentale pentru testarea automată ………………………….. ………………………….. …… 56
3.3 Rezultate experimentale pentru testarea semiautomată ………………………….. …………………………. 58
4. CONCLUZII ………………………….. ………………………….. ………………………….. ………………………….. ………. 64
5. BIBLIOGRAFIE ………………………….. ………………………….. ………………………….. ………………………….. …… 65
6. ANEXE ………………………….. ………………………….. ………………………….. ………………………….. …………….. 67
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
3
LISTĂ DE ABREVIERI
ABS = Anti -lock Braking System
APU = Approach Unlock
BCM = Body Control Module
BD = Bază de date
CAN = Controller Area Network
CAPL = CAN Access Programming Language
DTC = Data Trouble Code
ECU = Electronic Control Unit
ESCL = Electr ical Steering Column Lock
ID = Identification
HFM = Hand s Free Module
LIN = Local Interconnect Network
LF = Low Frequency
MOST – Media Oriented System Transport
PASE = Passive Start and Entry
RFID = Radio Frequency Identification
SDLC = Software/System Development Life Cycle
STLC = Software Test Life Cycle
SUT = Software Under Test
SW = Software
TC = Test Case
TDD = Test Dri ven Development
TR = Test Report
TS = Test Script
UHF = Ulta High Frequency
WAC = Walk Away Closing
WAL = Walk Away Locking
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
4
LISTĂ DE FIGURI
Figura 1. Sisteme de închidere a mașinii
Figura 2. Door Handle și zona WAC
Figura 3. Modalități de deschidere a mașinii bazate pe PASE
Figura 4. Cheie PASE și modul de back up
Figura 5. Zone PASE
Figura 1.1 Body Control Module
Figura 1.2 Eroare, defect, eșec
Figura 1.3 Fluxul procesului de execuție și evaluare a testelor
Figura 1.4 Modelul V
Figura 1.5 Tehnici de testare – clasificare
Figura 1.6 Gray Box
Figura 1.7 Zone LF
Figura 1.8 Sistemul PASE
Figura 1.9 Starea automobilului – cheia în interiorul mașinii
Figura 1.10 Starea automobilului – cheia în afara mașinii
Figura 1.11 Lock by WAC
Figura 1.12 Zone WAC
Figura 1.13 Approach Unlock
Figura 2.1 Procesul de dezvoltare al unui proiect
Figura 2.2 Descrierea aplicației
Figura 2.3 General Settings Tab
Figura 2.4 Walk Away Locking Tab
Figura 2.5 Approach Unlock Tab
Figura 2.6 Manual Test Bench
Figura 2.7 Handfree Module
Figura 2.8 Antene LF
Figura 2.9 Descriere funcției Walk Away Locking
Figura 2.10 Activarea funcț iei Walk Away Locki ng
Figura 2.11 Poziționarea cheii în interiorul mașinii
Figura 2.12 Configurare Approach Unlock
Figura 2.13 Test Setup
Figura 2.14 Modulul de test și cazurile de test
Figura 2.15 Inserarea unui modul de test CAPL
Figura 2.16 Editarea unui modul de test CA PL
Figura 2.17 Wake Up Mode – test case
Figura 2.18 Modul Wake Up
Figura 2.19 Modul Sleep
Figura 2.20 Setări – HFM mode
Figura 2.21 Vehicle Speed test case
Figura 2.22 Start Engine
Figura 2.23 ESCL test case
Figura 3.1 Parametrii de diagnoză pentru WAC în momentul deschiderii ușii șoferului
Figura 3.2 Polling în interior și exterior – perioada 300 ms
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
5
Figura 3.3 Polling în interior și exterior – perioada 500 ms
Figura 3.4 No request
Figura 3.5 Outside vehicle – zona 2
Figura 3.6 Outside vehicle – zona 3
Figura 3.7 Lock by Walk Request
Figura 3.8 Polling – Lock by Walk Request
Figura 3.9 Citirea parametrilor de diagnoză după Lock by Walk request
Figura 3.10 Approach Unlock – zona 2
Figura 3.11 Citirea parametrilor de diagnoză înainte de Approach Unlock
Figura 3.12 Polling – înainte de Unlock Request
Figura 3.13 Approach Unlock – zona 1
Figura 3.14 Lock Request și Unlock Request
Figura 3.15 Citirea parametrilor de diagnoză după Approach Unlock
Figura 3.16 Polling – dupăUnlock Request
Figura 3.17 HFM Wake Up test case
Figura 3.18 HFM Wake Up Overview
Figura 3.19 Semnalul HFM_Refuse_to_Sleep
Figura 3.20 Raport TS_01
Figura 3.21 Set Vehicle Speed test case
Figura 3.22 Set Vehicle Speed overview
Figura 3.23 Pornire a motorului
Figura 3.24 Semnalul Ignition Req uest
Figura 3.25 Set Vehicle Speed Panel
Figura 3.26 Citirea vitezei = 30 km/h
Figura 3.27 Citirea vitezei = 0 km/h
Figura 3.28 Raport TS_002
Figura 3.29 Modulul ESCL locked respectiv unlocked
Figura 3.30 TS_0 3 test case – passed
Figura 3.31 TS_03 overview
Figura 3.32 TS_03 test case – failed
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
6
STADIUL ACTUAL
Sistemele de acces au cunoscut o ampla dezvoltare, evoluând de la chei fizice metalice la
sisteme complexe formate din cartele și senzori . În prezentarea de mai jos se poate observă evoluția
modalității de închidere a mașinii de la utilizarea unei chei fizice simple până la utilizarea unui alt
tip de cheie inteligentă, cu ajutorul careia nu trebuie sa intreprindem o a ltă acțiune în afară de
îndepărtarea de autovehicul, cu che ia validă în posesia noastră.
În conformitate cu clasificarea sistemelor de acces prezente în automobilistică exist ă 4 tipuri
de sisteme de chei , prezentate în următorul tabel .
Tabel 1 . Sisteme de chei
Denumire Acces Start
Cheie fizică Cheie fizică Cheie fizică
Cheie fizică cu RFID cu immo Cheie fizică Cheie fizică + RFID
Cheie fizică cu RFID cu immo Acces remote (Remote active) Cheie fizică + RFID
PASE Acces remote (Remote passive) Start Remote (Remote passive)
Primul model de chei este cel în care acces ul și pornirea mașinii se realizează cu ajutorul cheii
fizice clasice, fabricată din metal(Exemplu: Dacia 1310).
Cu ajutorul cheilor de generatia a doua, acces ul în mașină se realizează cu ajutorul cheii fizice
iar pentru pornirea mașinii se folosește conceptul de transponder (immobilizer) . Cheia fizica clasica
având integrat un chip RFID în corpul cheii . Pent ru porn irea vehiculului cu ajutorul acestui tip de
Central Locking
– inserare cheie în
butucul de închidere
/deschidere
– rotire cheie în sensul
acelor de ceasornic =
mașina e închisă
– îndepărtare de mașină
Figura 1. Sisteme de închidere a mașinii
Remote Central
Locking
– apăsare buton „lock”
= mașina e închisă
– îndepărtare de
mașină
Smart Key
– apăsare /atingere
mâner = mașina e
locked
– îndepărtare de
mașină
Smart Key (with
WAC)
– cheia în posesia
șoferului
– îndepărtare de
mașină = mașina e
locked
Creșterea tehnologiei sistemului de închidere a unui autovehicul
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
7
chei, în momentul introducerii cheii în contact , ECU -ul mașinii verifică dac ă cheia este criptată si
autorizată pentru folosire sau nu. Acest e tipuri de sisteme denumite „immobilizer systems ” au fost
dezvoltate p entru a preveni copierea cheilor în scopul furt ului. Doar cheile care au încorporat un
RFID tag și au fost criptate corespunzător pot fi folosite pentru pornirea mașinii. RF ID se bazează
pe tehnologia LF de la 120 până la 135 KHz. Această tehnologie poate operea în două moduri:
pasiv și activ .
A treia generație, în comparație cu cea a nterioară, permite acces ul remote activ la mașină prin
utilizarea butoanelor amplasate pe cheie. Pentru deschiderea automobilului și folosirea unei chei
de la dista nță este ne cesară o baterie și o comunicare UHF (315 sau 433 MHz) .
Ultima generație de chei implică conceptul de PASE care permite acce sul în mașină și pornirea
acesteia în modul remote pasiv. Pentru funcționarea corectă a acestui mod, singura condiție este
deținerea unei chei valide și criptate corect, de către utilizatorul autovehicu lului, fără a fi necesară
o interacțiune a acestuia cu autovehiculul . Datorită faptului că utilizatorul nu întreprinde nicio
acțiune asupra cheii și nici asupra autovehicul ului apare denumirea „Pas sive Start and Entry”.
Mașina se deblocheaza automat în momentul în care cheia validă criptată este detectată în
apropierea mașinii iar închiderea se realizează în momentul în care utilizatorul se îndepărtează de
mașină. Pentru a fi permis modul remote pasiv se utilizează tehnologia LF prin care se i dentifică
poziția cheii valide criptate , verificandu -se dacă cheia se află în interiorul mașinii sau nu.
Sistemele PASE permit :
Închidere /Deschidere remote utilizând butoa nele de pe cheie /card
Închidere /Deschidere utilizând butoanele /senzorii de la mânerele ușilor din față, de la o
distanță de aproximativ 1 -2 metri
Start by PASE
Închidere/Deschidere utilizând WAC și APU
Din generația PASE face parte funcția denumită Walk Away Locking (WA L) sau Walk Away
Closing (WAC) care facilitează acțiunea de închidere a mașinii prin îndepărtarea utilizatorului de
aceasta , deținând o cheie/un card criptat. Această t ehnolog ie de acces reprezinta ultimul pas in
implementarea actuală a sistemelor de acces.
Funcția WA C este componentă a s isteme lor de chei inteligente. Conform unui studiu realizat
la o conferinta cu tema sitemelor de tip Walk Away Locking, marea majoritate a utilizatorilor
europeni intervieva ți și-ar dori ca mașina pers onală să dețină această funcție iar restul ar dori să
aibă acces la ea.
Sistemul WAC oferă utilizatorilor cel mai mare grad de confort din punct de vedere al accesului
la autovehicul, datorită faptului că utilizatorul nu trebuie sa întreprindă nici o acțiune asupra
cheii/cartelei mașinii, daca aceasta prezinta un chip valid și o criptare corectă . Fun cția este oferită
de Renault, Cadil lac, Mercedes , VW si Audi pe o gamă extin să de modele.
Pentru mașinile de ultim ă generație, marca Renault, există 3 modalități de blocare a mașinii,
conform fișelor de prezentare ale mărcii :
1. Remote Keyless Entry – utilizând cheia
2. Utilizând Door Handle (Figura 2.a)
3. Remote Keyless Entry – utilizând PASE
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
8
Cu ajutorul unei chei inteligente criptate , având toate ușile închise, prin îndepărtarea de
autovehicul, la ieșirea din zona de siguranță reprezentată în Figura 2.b). mașina se va închide
automat. În momentul închiderii, acest lucru va fi semnalat cu ajutorul unui sunet și cu ajutorul
aprinde rii luminilor exterioare de doua o ri. În cazul în care, în interiorul mașinii sau în zona de
siguranță mai există o alta cheie criptată, operațiunea de închider e nu se va realiza.
O altă funcție importanta care face parte din generația P ASE este denumită Approach Unlock
și permite deblocarea mașinii în momentul apropierii utilizatorului de aceasta.
În Figura 3 sunt prezentate două modalități de deschidere a mașinii. Antenele de exterior trimit
semnale LF în mod periodic sau când sunt acționate butoanele de pe mânerele de la ușile din față.
Aceste semnale ar putea fi mesaje mai lungi sau mai scurte care conțin identificatorul mașinii. În
momentul în care cheia detectează semnalul, trezește microcontroler -ul, demodulează semnalul și
îl întrerupe. Cheia răspunde pe canalul UHF, răspuns care este recepționat și verificat de către
ECU -ul din mașină. În cazul în care răspunsul e valid mașina este deblocată . În cazul în care se
dorește pornirea mașinii este necesară poziționarea cheii în interiorul mașinii, în zona inside
prezentată în F igura 5. În această regiune este verificată criptarea cheii, iar dupa verificarea și
autentificarea corectitudinii datelor criptate, pornește sau nu mașina.
Figura 2. Door Handle și zona WA C [12]
CAR
KEY
1. Wake up (LF)
2. ACK (UHF)
3. Car ID with challenge (LF)
4. Key response (UHF)
Periodic
probing for a
key
Challenge
the key
If corect ->
open the car
If car ID
corect
CAR
KEY
1. Car ID with challenge (LF)
4. Key response (UHF)
If key in
range and if
car ID corect
Periodic
probing for a
key
If corect ->
open the car
Figura 3 . Modalități de deschidere a mașinii bazate pe PASE
a)
b)
a)
b)
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
9
În modul de back -up, când s -a epuizat bateria de exemplu , utilizatorul poate sa deschidă și să
pornească mașina cu ajutorul cheii fizice prezentate in Figura 4 . Pentru deschiderea mașinii se
utilizează cheia fizică de rezervă, iar pentru pornirea motorului este necesară apropierea acestei
chei de transponder.
Figura 4. Cheie PASE și modul de back up
În Figura 5 sunt pre zentate zonele acoperite de LF din interiorul și din exteriorul mașinii :
Tabel 2. Controlul acces ului PASE [8]
Poziția cheii Autorizare Mediu utilizat
Mașină – Cheie Cheie – mașină
Modul normal : cheia are baterie
Remote
Outside
Inside Deschidere/închidere
activă
Deschidere/închidere
pasivă
Pornire pasivă –
LF
LF UHF
UHF
UHF
Modul back -up : cheia nu are baterie
Remote
Outside
Inside Deschidere/închidere
activă
Deschidere/închidere
pasivă
Pornire pasivă Imposibil
Închide rea cu ajutorul modului de back -up
LF LF
Figura 5. Zone PASE [8]
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
10
1. FUNDAMENTARE TEORETICĂ
1.1 Introducere
Această lucrare are scopul de a face cititorul să înțeleagă procesul, tehnicile și metodele de
testare aplicate unu i game largi de produse din industria auto, pentru verificarea și asigurarea
funcționării corect e a acestora . Testarea este necesară pentru asigurarea ca lității și integrității
produselor.
Domeniul automotive a cunoscut o dezvoltare foarte mare în ultima perioadă, în momentul
actual fiind într-o continuă dezvoltare, astfel încât conducătorii de automobile să aibă posibilitatea
să interacționeze cu mașina cât mai ușor posibil și t otodată de a avea o siguranță cât mai mare în
momentele în care se afla în autovehicul .
Pentru a putea face o demon strație în acest scop, un prim pas a fost documentarea cu privire la
metodele de testare( manuală, semiautomată și automată ) iar apoi aplica rea acestora asupra câtorva
funcționalități c are vor fi prezentate în detaliu în capitolul ”Rezultate Experimentale”.
Pentru faza de testare manuală s -a decis alegerea a două scenarii referitoare la o nouă
tehnologie din punct de vedere al accesului în mașină si pornirii acesteia , tehnologie care poartă
numele de Passive Start and Entry (PASE) . Sistemul PASE se bazează pe chei inteligente criptate
prin intermediul cărora se elimin ă nevoia unui sistem classic electro -mecanic cheie -contact. Astfel
se elimina necesitatea folosirii cheii fizice, fiind de ajuns ținerea cheii /cardului în buzunar. În acest
mod, mașina se va deschide in momentul în care utilizatorul se apropie de ea , respectiv se va
inchide în momentul î ndep ărtării de aceasta la o distanță de aproximativ 2 metri. Totodată , prin
intermediul acestui s istem revoluționar , pornirea mașinii se face printr -o simplă apăsare a butonului
de Start , cu condiția existenței cheii criptate în mașină .
Pentru testarea automată a fost nevoie de utilizarea unui soft numit CANoe care permite crearea
unor script -uri și rularea acestora generând un raport cu rezultatele obținute . Prin setarea unor
variabile prin intermediul unui panou de control , care reprezintă interfața grafică, se poate observa
comportamentul echipamentelor utilizate, care simulează componente ale mașinii . Cazurile alese
vor fi prezentate în detaliu în capitolul ” Implementare practică ”.
Testarea semiautomată îmbină ambele tipuri de testare amintit e mai sus. Pentru executarea
unui test semiautomat este necesară aplicarea unor setări manuale în completarea rulării automate .
Cazurile alese sunt prezentat e în detaliu în capitolul ” Implementare practică ”.
Echipamentele și baza de date prin intermediul cărora este simulată mașina aparțin comp aniei
Continental Automotive, fiind utilizate în cadrul companiei Arobs Transilvania Software , cu
ajutorul cărora am reușit să exemplific conceptele d e testare manuală, automată și semiautomată în
domeniul automotive .
1.1.1 Introducere în d omen iul automotive
Domeniul a utomotive reprezintă domeniul tehnologic al dispozitivelor electronic e utilizate în
industria producă toare de mașini , un domeniu în care principalul scop este cel de a oferi
utilizatorilor de automobile un grad ridicat de siguranță . Sistemele de control electronic ECU fac
parte din categoria dispozitivelor cu o fiabilitate ridicată , fiind necesară o testare strică a fiecărui
ECU pentru garantarea securității.
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
11
Comunicația dintre ECU -uri se realiz ează prin cu ajutorul protocoalelor de comunicație .
Câteva exemple de protocoale de comunicație utilizate în domeniul automotive sunt : LIN (Local
Intercon nect Network) , CAN (Controller Area Network), Ethernet, MOST (Media Oriented
System Transport) , FlexRay etc. care sunt descris e în detaliu în sectiunea urmatoare.
În momentul de față, ECU -rile integrate in automobile se dezvolt ă din ce în ce mai mult . Pentru
automobilele de lux se estimează că sistemele electronice reprezintă aproximativ 23% din costul
total al automobilului iar aproximativ 80% din inovațiile aduse în domeniul auto motive fac parte
din categoria sistemelor electronice. [3]
Dintre ECU -urile prezente în interiorul unei mașini cel mai important este BCM -ul (Body
Control Module) care are rolul de a controla toate cel elalte ECU -uri. BCM -ul acoperă o gamă largă
de facilități cum ar fi confortul, sistemul multimedia, luminile și tehnologiile de acces atât în
interiorul cât și în exteriorul mașinii, facil ități care pot fi observate în următoarea figură .
1.1.2 Protoco ale de comunicație utilizate în domeniul automotive
Protocoalel e de comunicație utilizate în industria automotive se clasifică în funcție de viteza
de transmitere a datelor . În acest moment se folosește următoarea clasificare a sistemelor de
comunicație :
Tabel 1.1 Protocoale de comunica ție utilizate în industria automotive
Nr.
Crt. Viteza Aplica ții Protocol
1 < 10 kb/sec Acționare oglinzi
Geamuri electrice LIN
2 10 – 125 kb/sec Cluster CAN low speed
3 125 kb/sec – 1 Mb/sec Management motor
Transmisie
Sisteme de frânare CAN high speed
4 >1 Mb/sec Sisteme X -by-wire
Multimedia FlexRay, MOST
Cele mai importante două protocoale utilizate în domeniul automotive sunt CAN și LIN.
Figura 1.1 Body Control Module [17]
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
12
Protocolul CAN (Controller Area Network) are următoarele caracteri stici :
Robustețe
Viteză de transmitere a datelor relativ mare.
Utilizare : managementul motorului, transmisiei și al s istemului de frânare clasic.
Protocolul LIN (Local Interconnect Network) ar e următoatele caracteristici :
protocol simplu
ieftin
viteză mică
Utilizare : controlul sistemului de închidere centralizată, climatizare, oglinzi electrice,
etc.
Spre deosebire de CAN, care utilizează două fire pentru comunicație, LIN utilizează un singur
fir.
1.2 Testare – noțiuni fundamentale
1.2.1 Scopul și costu l testării
Scopul testării este acela de a asigura calitatea unui produs software astfel încât acesta să
satisfacă cerințele clienților. Testarea presupune indetificarea problemelor existente într-un produs
software pentru a reuși remedierea acestora în faza incipient ă a proiectului pentru a reduce
costurile.
Procesul de testare este realizat de către o echipă de testare. Din atribuțiile unui tester fac parte
următoarele:
Primirea informații lor legate de test , informații referitoare la detalii privind proiect ul, tool –
uri folosite etc.
Crearea cazurilor de test ( TC) – Un TC reprezintă un scenariu/caz prin care se verifică, cu
ajutorul unor condiții inițiale și parametrii bine definiți, funcționarea corectă sau nu a
produsului.
Crearea script -urilor (TS) – Un test script reprezintă scrie rea set ului de instrucțiuni cu
ajutorul cărora se realizează testele automate .
Crearea rapoartelor de test ( TR) – Un Test Report conține numărul de teste care au trecut
sau nu au trecut și totodată precondițiile, condițiile inițiale, rezultatele așteptate și
rezultatele primite .
Să raporteze problemele identificate Test Manager -ului.
O parte din cauzele aparitiei erorilor sunt interacțiunea imprevizibilă a componentelor, eroarea
umana , complexitatea sistemului , interpretarea greșită a specificațiilor, termenul limită dus la
extrem etc. Eroarea este considerată o eroare de programare în cod care duce la un defect, care la
rândul lu i se manifestă printr -un eșec. Cei doi termeni, eroare si defect, au o cu totul altă
întelegere.
Programatorul
face o greșeală
în cod
Eșec
Mistake (Error, Bug)
Defect
Greșeala se
manifestă printr –
un defect în cod
(Defect)
Dacă defectul este vizibil,
acesta se manifestă printr -un
eșec (Failure)
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
13
Costul test ării ocup ă o parte important ă în costul total al ap licațiilor software. P onderea
costului test ării din costul proiectului începe de la 30% și poate ajunge chiar și la 50%. Costul
testării software include cheltuieli pentru tool-uri dedicat e, pentru personal spec ializat și consumu l
de resurse.
În procesul de testare se identific ă următoarele etape conform :
planif icarea procesului de testare
analiza și proiectarea testelor
implementarea testelor
execu ția testelor și evaluarea rezultatelor
Cheltuielile totale de testare pot fi calculate ca o sumă a urmatoarelor componente: c heltuieli
pentru planificarea test ării + cheltuieli pentru analiza și proiectare a testelor + cheltuieli pentru
implementarea testelor + cheltuieli pentru execuția și evaluarea testelor . Procentajul fiecărei
componente în parte este variabil în funcție de fiecare proiect.
Există trei etape principale în procesul de dez voltare al unui produs softwar e :
Dezvoltare
Testare
Livrare
Erorile depistate și fixate în faza incipientă de descriere a specifi cațiilor nu costă practic nimic ,
datorită identificării rapide , însă e rorile depistate după livrarea produsului măresc costul ac estora
semnificativ . În consecință, cu cât erorile sunt depistate în fazele incipiente a le dezvoltării unui
produs, cu atât costu l remedierii erorilor v a fi unul cat mai mic .
1.2.2 Etapa de planificarea a testelor
Etapa de p lanificarea a testelor se realizează împreuna cu manage mentul proiectului în funcție
de planificarea întregului proiect.
Pentru această etapă este necesară aloca rea de resurse specific ându-se clar bugetul și perioada
de timp în care se va derula testarea pentru proiect .
Necesitatea etapei de planificare este dată de stabilirea exacta a funcționalităților care trebuie
testate și totodată de durata testării acestora .
Planul de test rezultă în urma planificării atente a testelor și reprezintă un document foarte
important deoarece , pe baza acestuia se desfășoară întreg proces ul de testare. Planul de test cade în
responsabilitatea Test Managerului. Este de preferat ca planificarea testării să fie facută în
momentul elaborării software -ului.
Figura 1.2 Eroare, defect, eșec
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
14
În planul de testare, sunt trecute următoarele:
responsabilit ățile membrilor din echipa de testare
timpul estimate necesar executării tuturor testelor
specificare a mediului în care rulează aplicația
configurarea mediului specific aplica ției
echipamentel e si resurse necesare
Planul de test trebuie să conțină strategii de testare care se referă la criteriile de acceptare și de
finalizare a testării , Entry Criteria (Condiții specifice sau activități în desfășurare care trebuie sa fie
prezente înainte de începerea procesului de tes tare) și Exit Criteria (Condiții specifice sau activități
în desfășurare care trebuie prezentate înainte de încheierea unei faze din ciclu de dezvoltare) .
Definirea criteriului de intrare se realizează cu ajutorului unui set de test e. Dacă în urma rulării
acestora avem un rezultat pozitiv( passed ), se poate incepe procesul de testare . În caz contrar, dacă
aceste teste sunt failed, se refuză soft -ul deoarece nu are rost continuarea execuției testelor.
Criteriul de ieșire reprezintă condițiile care trebuie în deplinite pentru a considera procesul de
testare complet.
1.2.3 Analiza și crearea testelor
Etapa de analiză are ca scop înțelege rea specificațiilor pe baza cărora are loc etapa de
implementare a soft -ului.
După finalizarea analiz ării specificațiilor se incepe crearea testelor necesare verificării
funcționalitaților . Crearea testelor sau test case design se face astfel încât să fie acoper ite toate
cerințele , existând posibilitatea ca o cerință să nu poată fi acoperita de un singur test dar și cazul în
care un test acoperă mai multe cerințe.
Cazurile de test sunt alcătuite din date de intrare în precondiții, setări în partea de procedură ș i
verificări în partea de rezultate așteptate. În general, un caz de test arată asfel :
Precondiții :
{
Precondiția I
Precondiția II
…
}
Procedură :
{
Setare I
Setare II
…
}
Rezultate așteptate :
{
Verificare I
Verificare II
…
}
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
15
După crearea testelor acestea se salvează într -o configure ție care va putea fi folosită ulterior
iar rez ultatele intr -o bază de dat e.
1.2.4 Etapa de implementare a testelor
Etapa de implementare a testelor se referă la crearea scripturilor pentru testarea automată.
Implementarea secven țelor de test se realizeaz ă în limbaje specifice mediilor de testare
asemă nătoare Visual Basic sau se utilizeaz ă limbaje de programare evoluate (C++, Java). Prin
reutilizare, se pot folosi proceduri de test din proiectele anterioare sau din cadrul aceluia și proiect
pentru module ce au p ărți comune. Prin reutilizarea testelor, cheltuielile din aceasta faz ă se reduc,
însa reutilizarea nu este întotdeauna posibil ă.
1.2.4 Execu ția și evaluarea testelor
În etapa de execuție și evaluare a testelor din cadrul p rocesului de testare sunt executate teste le
manuale și cele automate . În urma execuției testelor se obține un anumit rezultat care urmează să
fie comparat cu rezultat ul așteptat specificat în scenariul de test . Dacă aceste două rezultate coincid
testul este passed, în caz contrar este failed.
În urmatoarea figură este reprezentat procesul de execuție pentru un caz de test. Primul pas este
o analiză a scenariului de test și executarea acestuia, execuția putând fi făcută manual sau automat .
În urma execuției se obține un rezultat ce urmează sa fie s alvat într-o bază de date. În cazul în care
testul este failed procesul continuă prin raportar ea problemei găsite și analiza acesteia de către
echipa de dezvoltare. Dacă se ajunge la concluzia că problema este reală, următorul pas este
soluționarea acest eia și totodată retestare a specificației/cerinței pentru asigurarea faptului că
problema a fost înlăturată . Acest tip de retestare se numește regression testing. În cazul în care în
urma evaluării se ajunge la concluzia că nu există o problem si ca a fost un False Fail , nu se face
nicio modificare.
Figura 1.3 Procesului de execuție al unui caz de test
Caz de test
Execuție
Passed
Failed
Salvare
rezultat
într-o BD
Salvare
rezultat
într-o BD
Raportare
eroare
Soluționare
problemă
Nu este o
eroare
DA
NU
Retestare
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
16
1.3 Modelul V – Noțiuni fundamentale
1.3.1 Schema bloc a modelului V
În figura 1.4 este prezentat ă schema modelul ui V :
1.3.2 Nivele de testare
Partea din stânga a modelului V reprezintă partea de development denumită SDLC
(Software/System Development Life Cycle ), iar partea din dreapta este partea de testare denumită
și STLC ( Software Test Life Cycle ).
În figura prezentată mai sus, se poate observa di spunerea modelului V sub forma:
Software
System
Client Figura 1.4 Modelul V
Requiremets
Requirements
System requirements
analises and design
Vehicle Test
System requirements test
and integration test
SW Requirement analyses
SW arhitecture
SW design
SW Requirement test
SW integration test
SW unit test
Implementation
Software
System
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
17
1. Software Testing
Testarea software se poate face pe 3 nivele:
SW Unit Test
SW Integration Test
SW Requirement Test
a) Software Unit Test
Acest nivel de testare este bazat pe urmatoarele componente: cerințele componentei , design
detaliat și c od.
Obiectele tipice de test sunt: componente , programe , convers ii de date/programe de migrație,
module de baze de date .
Testarea unităților sau testarea componentelor se face cu scopul de a identifica defecte și
verifică funcționarea corectă a modulelelor software, a programelor, a obiectelor, a claselor etc.,
care pot fi testate separat. Aceasta poate fi făcută izolat de restul sistemului, depinzând de contextul
în ca re se află procesul de dezvoltare.
Testarea compo nentelor poate include testarea caracteristicilor funcționale și non -funcționale.
În general, testarea componentelor se face cu acces la codul care trebuie testat și cu suportul
unui mediu de dezvoltare, cum ar fi un framework de testare unitară sau un tool de debugging.
Acest nivel de testare implică comunicare și colaborare cu programatorul care a scris codul. În mod
normal defectele sunt fixate în momentul în care sunt descoperite, fără alți pași intermediari și fără
implicare la nivel administrativ .
O abordare a testării componentelor este cea în care se pregătesc și se automatizează cazurile
de test înainte de codare. Această abord are se numește TDD (Test Driven Development). Ea este
iterativă și se bazează pe ciclul de dezvoltare a cazurilor de test, apoi construirea și integrarea
bucăților de cod și executarea testelor unitare, corectând orice problemă și incrementându -se până
când trec.
b) Software Integration Test
Acest nivel de testare este bazat pe design -ul software și design -ul sistemului , arhitectură,
workflow -uri și use case -uri.
Obiectele tipice de test sunt : subsistemele, i mplementarea bazei de date , infrastructura,
interfețele , configurarea sistemului și a datelor.
Nivelul acesta presupune o interfațare a componente lor și interacțiunea cu diferite părți ale
sistemului, cum ar fi sistemele de operare sau fișierele.
Testarea de integrare poate avea mai multe nivele :
1. Testarea integrării componentelor care verifică interacțiunea dintre componentele software
și are loc după testarea componentelor .
2. Testarea integrării sistemului care verific ă interacțiunea dintre diferite sisteme sau dintre
hardware și software și poate fi făcută după testarea sistemului.
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
18
Cu cât scopul integrării este mai mare, cu atât este mai dificilă izolarea defectelor unei
componente specifice sau a unui sistem specific, ceea ce duce la creșterea riscului și la creșterea
timpului pentru rezolv area problemelor. [1]
Strategiile integrărilor sistematice pot fi bazate pe arhitectura sistemului, task -uri funcționale,
secvențe de procesare a tranzacțiilor, sau alte aspecte ale sistemului sau ale componentelor. Pentru
a ușura izolarea erorilor și pent ru detectarea preventivă a defectelor, integrarea ar trebui sa fie
incrementală și nu de tip “big -bang”.
Testarea unor caracteristici non -funcționale specifice pot fi incluse de asemenea în testarea de
integrare la fel ca și testarea funcțională. [1]
În fiecare etapă a integrării, testerii se concentrează exclusiv pe integrarea propriu -zisă. De
exemplu , dacă se integrează două module A și B, centrul de interes este verificarea comunicării
dintre mo dule și nu funcționa rea individuală a modulelor, deoarece aceasta a fost făcută la nivelul
testării unitare. Poate fi folosită abordarea funcțională și cea structurală.
În mod ideal, echipa de testare ar trebui să înțeleagă arhitectura și influența planificării
integrării. Da că testele de integrare sunt planificate înainte de construirea componentelor și a
sistemului, acele componente pot fi construite în ordinea cea mai eficientă pentru testare [ 1].
c) Software Requirement Test
În faza de testare a cerințelor software, software -ul este testat în conformitate cu cerințele
funcționale de software. Această fază poate fi pusă în aplicare doar în cazul în care cele două faze
anterioa re au fost finalizate cu succes .
2. System Testing
Pentru testarea de sistem există 2 nivele :
System Integration Test
System Requirement Test
Acest nivel de testare este bazat pe specificațiile cerințelor sistemului ș i a software -ului, u se
case-uri, specificații funcționale și rapoarte cu analizele riscului.
Obiectele tipice de test sunt : manualele sistemului, utilizatoru lui și a operațiilor și totodată
configurarea sistemului și configurarea datelor.
Testarea sistemului are în vedere comportamentul într egului sistem/produs.
În testarea sistemului, mediul de testare ar trebui să corespund ă cât mai mult cu target -ul final
sau mediului de producție, pentru a minimiza riscurile erorilor datorate neconformității mediului
de testare.
Testarea sistemului poate include teste bazate pe riscuri și/sau pe specificațiile cerințelor,
procese business, use case -uri, sau alte descrieri de text high -level sau modele comportamentale
ale sistemului, interacțiuni cu sisteme de operare, și resurse de sistem. [1]
Testarea sistemului trebui e să verifice cerințe le funcționale și non-funcționale ale sistemului și
caracteristici le calității datelor. Echipa de test are de-a face de as emenea și cu cerințe incomplete
sau care nu sunt bine documentate. Testarea de sistem a cerințelor funcționale începe prin utilizarea
adecvată a tehnicilor bazate pe specificații (b lack-box) pentru aspectele din sistem care trebuie
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
19
testate. Se pot utiliza tehnici bazate pe structură (white -box) pentru evaluarea rigurozită ții testării
care respectă un element structural, cum ar fi o structură de meniu sau o navigare pe o pagina web.
De obicei, ace st tip de testare este efectuat de o e chipă de testare independentă [1 ].
3. Acceptance Testing
Pentru testarea de acceptanță există un singur nivel :
Vehicle Test
Bazele acestui nivel de test are : cerințele utilizatorului , cerințele sistemului , use case -uri,
procese business și rapoarte de analize de risc .
Obiectele tipice de test sunt: procese business pe sistemul integrat în totalitate , procese
operaționale și de mentenanță , proceduri de utilizator , formulare , rapoarte , date de conf igurare .
Scopul testării de acceptanță este de a stabili un anumit grad de încredere în sistem, în anumite
părți ale sistemului sau în anumite caracteristici non -funcționale ale sistemului. Principalul obiectiv
al testării de acceptanță nu este acela de a descoperi defecte.
Testarea de acceptanță poate verifica și demonstra dacă sistemul este pregătit pentru furniz area
acestuia către utilizatori.
Testarea de acceptanță poate sa se desfășoare în mai multe perioade pe parcursul dezvoltarii
sistemului :
Un anum it produs software poate fi trecut prin etapa de acceptanță în momentul în care
este integrat.
Testarea de acceptanță a utilității unei componente poate fi făcută în timpul testării unitare.
Testarea de acceptanță a unei noi funcționalități poate fi făcută înainte de testarea
sistemului.
Forme uzuale ale testării de acceptanță sunt:
User acceptance testing – se verifică utilizarea sitemului de către utilizatorii business.
Operational testing – testarea de acceptanță făcută de administratorii de sistem.
Contract acceptance testing – se compară criteriile de acceptanță contractate.
Alpha and beta testing – testarea alfa este efectuată la locul unde a fost dezvoltată aplicația
însă nu de către echipa care a dezvoltat -o, iar testarea beta este efectuată de c lienți sau de
potențiali clienți.
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
20
1.4 Tehnici de testare
1.4.1 Clasificare
În figura urmatoare este prezentată o clasificare a tehnicilor de testare. După cum se observă
în imagine tehnicile de testare se împart în două mari categorii : Black Box și White Box.
1.4.2 Testarea B lack Box
Testarea de tip Black Box este o tehnică de testare software care testează funcționalitatea
software -ului under test (SUT) fără a ține cont de codul intern al programului , de detalii legate de
partea de implementare și nu sunt necesare cunoștințe legate de partea internă a soft -ului. [13]
Tipurile de testare Black Box sunt :
Testare funcțională
Testare non – funcțională
Testare de regresie Figura 1.5 Tehnici de testare – clasificare
Black Box
White Box
Testare
Equivalent
Partitioning
Boundary Value
Analysis
Decision Table
Functional
Testing
Non functional
Testing
Regression
Testing
Types
of
testing
Testing
strategy
State Transition
Testing
Branch Testing
Path Testing
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
21
Testarea funcțională se bazează pe documente cu specificații funcționale și poate fi utilizată
atât pentru testarea manual ă cât și pentru testarea automată. Î n general această metodă este mai
accesibilă utilizând testarea manual ă.
Pentru aplicarea te stării funcționale se urmăresc cinci pași :
1. Crearea cazurilor de test pe baza specificațiilor furnizate
2. Specificațiile sunt considerate input -uri pentru testarea funcțională
3. Verificarea output -urilor pe baza specificațiilor
4. Execuția cazurilor de test
5. Analiza comportamentului inițial și a rezultatelor așteptate
Tipuri de testare func țională : unit testing, integration testing, system testing, regression testing
etc.
Testarea non -funcțională , spre deosebire de testarea funcțională, testează atributele unei
componente sau ale unui sis tem care nu sunt legate de funcț ionalitate .
Tipuri de testare func țională : performance testing, stress testing, security system, load testing
etc.
Testarea de regresie presupune retestarea selectivă a unui sistem sau a unei componente
pentru a verifica faptul că modificările efectuate în cod nu au cauzat efecte nedorite . Testele de
regresie sunt un subset al setului inițial de scenarii de testare , aceste scenarii de testare fiind rulate
de multe ori, după orice modificări semnificative , fie de corectare , fie de îmbunătățire, în cadrul
codului . [16]
Scopul testelor de regresie este de a verifica faptul că modificările efectuate nu au afectat nicio
funcționalitate care anterior funcționa corect .
Testarea Equivalent Partitioning constă în p artiționarea cazurilor de test cu scopul de a reduce
numărul de scenarii de testare necesar pentru a testa în mod eficient datele de intrare, cele de ie șire,
valorile interne și valorile legate de timp. Partiționarea este folosită pentru a crea clase de
echivalență , iar prin selectarea unei valori reprezent ante de la o partiție, se presupune o acoperire
pentru toate elementele din aceeași partiție . [16]
Testarea Boundary Value Analysis este o tehnică de testare care implică determinarea
limitelor pentru valorile de input și selectarea valorilor de la limită. [13]
Testarea Decision Table
În tabelul 1.2 sunt prezentate :
Condi țiile – care reprezint ă diverse condi ții de intrare
Acțiunile – acestea se execut ă depinz ând de diversele condi ții de intrare
Fiecare regulă definește o combinație unică de condiții
Acțiunile nu depind de ord inea de evaluare a condițiilor ci doar de valorile lor
Acțiunile nu depind de condițiile anterioare de intrare sau de starea sistemului
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
22
Tabel 1.2 Tabel de decizii
Regula 1 Regula 2 … Regula X
Condiții
Condiția 1
Condiția 2
…
Condiția Y
Acțiuni
Acțiunea 1
1.4.3 Testarea White Box
Testarea de tip White Box , spre deosebire de Black Box necesită cunoașterea completă a
structurii programului și accesul la codul sursă. Acest tip de testare este utilizat de programatorii
care au scris codul.
Testarea White Box se clasific ă astfel :
Testarea State Transition Testing utilizează o diagramă de stări și se dorește crearea unui
număr de teste astfel încât să fie acoperite toate stările.
Testarea Branch Testing se bazează pe ideea de a crea u n număr de teste astfel încât să se ia
în considerare toate tranzițiile de la o stare la alta.
Testarea Pat h Testing are ca scop parcurgerea tuturor căilor posibile de la starea de început
până la starea finală.
1.4.4 Testarea Gray Box
Testarea Gray Box este o combinație între cele două tehnici de testare descrise anterior, w hite
box și black box.
Se construiesc test case -urile având acces la sursele programului , după care acestea sunt
executate utilizând tehnica Black B ox fără să ținem cont d e structura intern ă a programului.
Testarea Gray Box nu se folos ește în domeniul automotive. Figura 1.6 Gray Box
Gray Box
Black Box
White Box
+
=
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
23
1.5 Testare manuală vs t estare automată
Testare a unui produs poate fi efectuată util izând ambele tehnici de testare: manuală și automată ,
dar în fun cție de tipul de proiect se alege numărul de teste care se automatizează, respectiv care se
vor executa manual. Această decizie este responsabilitate a test manager -ului care trebuie să ia în
considerare costurile și beneficiile proiectului. Există totodată posibilitatea ca unele teste să fie
executa te atât manual cât și automat.
Chiar dacă se optează testarea automată pentru unele funcționalități, este recomandat ca
scenariile de test să fie executate manual înainte, cu scopul de a înțelege mai bine scenariul de test.
În continuare sunt prezentate câ teva diferențe principale între testarea manuală și cea automată ,
conform :
Pentru testarea manuală , echipa de test este compusă din mai mulți testeri, comparativ
cu numărul de testeri necesari din echipa de testare automată
Pentru testarea manuală nu sunt necesare cunoștințe de programare în schimb pentru
testarea automată sunt o componentă vitală
Timpul de execuție al unui test este mai mare pentru testarea manuală
Pentru testarea manuală se poate aplica metoda Error Guessing care presupune găsirea
erorilor pe baza experiențelor anterioare
1.5.1 Testare manual ă
Testarea manuală presupune execuția manual ă a testelor , conform cazurilor de test create în
etapa de test design și compararea rezultatelor așteptate cu rezultatele obținute, cu scopul de a găsi
erori în produsul software .
Avantajele testării manuale:
Costuri reduse
Flexibilitate – tester -ul are posibilitatea de a devia de la scenariul de test
Este mai interesantă găsirea erorilor prin execuție manual
Dezavantajele testării manuale:
Scenariile pot deveni repetitiv e
Unele teste sunt dificil de executat manual
Un test nu poate fi executat în mod repetat
Timpul necesar execuției manuale este mare
1.5.2 Testare automată
Testarea automată presupune crearea unor script -uri utilizând tool -uri speciale pentru testare
automată și execuția acestora printr -o simplă rulare.
Avantajele testării automate :
Rularea testelor se face în mod rapid și eficient
Script -urile create pot fi rulate în mod repetat
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
24
Testarea automată presupune costuri ridicate pentru tool -urile de automatizare, însă de -a
lungul timpului poate fi un cost eficient
Rezultatele obținute pot fi păstrare ș i analizate de mai multe personae
Dezavantajele testării automate :
Costuri ridicate
Crearea script -urilor necesită timp
Anumite tool -uri de automatizare pot avea limitări
1.5.3 Testare semiautomată
Testarea semiautomată este un tip de testare care implică atât testarea manuală cât și testarea
automată. Există cazuri de test care nu pot fi automatizate în totalitate fiind necesară implicarea
testării manuale.
1.6 Passive Start and Entry
Passive Start and Entry (PASE) este un c oncept nou în domeniul automotive și constă în
utilizarea unor funcționalități ale mașinii fără a fi nevoie de folosirea unei chei mecanice clasice,
fara chip criptat . Acest concept se bazează pe utilizarea antenelor LF (Low Frequency) în interior ul
mașini i și a unui modul numit Hand s Free Module .
În figura urmatoare sunt prezentate zonele de interior și de exterior acoperite de antene :
Numărul și poziționarea antenelor sunt diferite de la o marcă de automobil la alta.
În continuare vor fi prezentate 3 funcții care se bazeaz ă pe acest concept :
Easy PASE
Walk Away Locking
Approach Unlock
Figura 1.7 Zone LF
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
25
1.6.1 Easy PASE
Continental Automotive este unul dintre liderii de pe piață în sisteme de acces hands -free,
sistem cunoscut sub numele de PASE. Fiind un sistem standardizat, scalabil și flexibil asigură
costurile minime și o perioadă scurtă de dezvoltare.
În Figura 1.8 este prezentat modulul HFM (Hands Free Module), o cheie criptată și butonul de
start engine . Utilizatorul mașinii care deține o cheie criptată corect poate porni mașina la o simplă
acționare a butonului de start. Condiți a pentru îndeplinirea acestei funcții este existența în interiorul
mașini i a unei chei care să fie validă și criptată corect.
Avantaje și caracteristici :
Posibilitatea ca a utovehiculul să fie închis /deschis automat
Posibilitatea porni rii motorul ui fără folosirea unei chei clasice
Utilizarea mai ușoară a mașinii
Folosirea conceptului de antene flexibile
Date tehnice :
PASE ECU
4-8 antene care sunt scalabile în conformitate cu OEM (Original Equipment Manufacturer)
1.6.2 Walk Away Locking
Funcția Walk Away Locking (WAL) sau Walk Away Closing (WAC) oferă utilizatorului
posibilitatea ca mașina să se închidă automat în momentul în care utilizatorul părăsește mașina,
închide ușa și se depărtează deținând o cheie validă. Mașina este închisă autom at în momentul în
care utilizatorul s -a îndepărtat la o distanță egală cu aproximativ 2 metri.
Două dintre b eneficii le utilizării acestei funcții sunt con fortul și s ecuritate a.
Figura 1 .8 Sistemul PASE [9]
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
26
În continuare este prezentat un scenariu prin care se arată utilizarea fun cției WAC :
1. Motorul este oprit, șoferul și cheia sunt în interiorul mașinii :
2. Șoferul iese din mașină și închide ușa. În acest moment se fac două verificări :
nu există nicio cheie validă în interiorul maș inii
există cel puțin o cheie valid ă în zona WAC
3. Antenele de exterior continuă să verifice informațiile primite de la cheie.
4. În momentul în care dinstanța dintre șofer, care deține cheia, și mașina depașeste doi metri,
mașina se va închide automat.
Figura 1.9 Starea automobilului – cheia în interiorul mașinii
Figura 1 .11 Lock WAC Figura 1.10 Starea automobilului – cheia în afara mașinii [21]
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
27
În Figura 1.12 sunt prezentate zonele funcției WAC :
1.6.3 Approach Unlock
Funcția Approach Unlock este op usă funcției Walk Away Locking. În momentul în care
utilizatorul se apropie de ma șină având asupra lui o cheie validă, cheia trimite o cerere de
deschidere .
În timp ce m așina se află în standby mode , antenele emit frame -uri LF în zona approach unlock,
căutând permanent o cheie validă. În momentul în care utilizatorul intră în zona approach unlock,
mașina detecteaz ă cheia, autentific ă cheia și în caz de succe s trimite unlock reques t. [21]
Figura 1.12 Zone WAC [21]
Figura 1.13 Approach Unlock
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
28
2. IMPLEMENTAREA SOLUȚIEI ADOPTATE
2.1 Descrierea procesului de dezvoltare al unui proiect
Procesul de dezvoltare al unui proiect se realizează în patru pași :
Primul pas în dezvoltarea unui proiect îl reprezintă primirea specificațiilor sau a requirement –
urilor de la client pe baza cărora se începe etapa de implementare. Această etapă se realize ază de
către departamentul de dezvoltare.
Pentru asigurarea calității produsului software este necesa ră etapa de testare, î n urma căr eia se
validează produsul software și se verifică faptul că cerințele clientului au fost îndeplinite în
totalitate . După ce produs ul software a fost testat de către o echipă de testare și rezultatele sunt
pozitive , acesta poate fi livrat client ului.
2.2 Descrierea aplicației
Scopul acestei lucrări este înțelegerea metodelor de testare și aplicarea acestora asupra unor
cazuri de test realizate în urma analizării specificații lor. Datorită faptului că specificațiile clientului
sunt strict confidențiale pentru fiecare proiect, am decis crearea unor specificații fictive care să
scoată în evidență 3 funcționalități importante : WAC, APU și ESCL.
Figura 2.1 Procesul de dezvoltare al unui proiect
Specificații
Implementare
Testare
Livrare
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
29
În etapa de implementa re echipa specializată crează o primă versiune de software. După ce
versiunea inițiala de software a fost finalizată are loc încărcarea soft -ului pe modulul care trebuie
testat, în cazul acesta modulul HFM.
Aplicația are ca obiectiv demonstrarea celor trei tipuri de testare : manuală, automată și
semiautomată utilizând echipamente hardware și o simulare creată cu ajutorul unui tool, numit
CANoe , descris la secțiunea 2.3 . Scopul este testarea unor funcți i din domeniul automotive .
În mod normal , testarea completă a unei funcționalități implică crearea mai multor scenarii
pentru acoperirea tuturor specificațiilor , însă această lucrare are ca scop crearea câtorva scenarii
pentru a arăta comportamentul de bază al funcționalităților ale se.
Pentru testarea manuală s -a ales crearea și executarea de scenarii pentru funcțiile WAC și APU.
Scenariile create se referă la o tehnică nouă de acces din domeniul automotive, bazată pe chei
inteligente, care realizează închiderea automată în momentul îndepărtării d e mașină la o anumită
distanță, iar în momentul apropierii de mașină aceasta se va deschide automat .
Pentru testarea automată și semiauto mată s -a utilizat tool -ului CANoe Testing Tool descris la
secțiune 2.6, și s-a creat un panou cu ajutorul căruia se pot face diferite setări necesare funcționării
corecte . Unul dintre scenariile create se referă la starea în care se află modulul HFM , iar un alt
scenariu se referă la pornirea motorului și seta rea vitezei la 30 km/h din panou . Execuția celui de –
al doilea sce nariu pune în evidență funcționarea modului de blocare a volanului, ESCL aplicând
testarea semiautomată.
2.3 CANoe
Tool-urile CANalyzer și CANoe se bazează pe un li mbaj exclusiv de programare numit CAPL
(CAN Access Programming Language ) asemă nător cu limbajul C. Aceste tool -uri sunt dezvoltate
de o companie renumita din domeniul de testare al ECU -urilor, VECTOR.
Cu ajutorul acestui tool avem posibilitatea de a simula anumite componente ale mașinii , pe
care nu avem cum sa le folosim fizic . Pent ru simularea anumitor componente este necesară crearea
unei baze de date care conține noduri corespunzătoare fi ecărui ECU simulat. Comunicarea între
noduri se face prin intermediul protocoalelor CAN sau LIN cu ajutorul mesajelor, mesaje care
conțin la rândul lor semnale. Figura 2 .2 Descrierea aplicației
Crearea
specificațiilor
Test case design
Test case execution
Testare automată
Testare semiautomată
Testare manual ă
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
30
CAPL poate fi utilizat în aplicații :
analiza mesajelor
analiza traficului datelor
crearea modulelor de testare
crearea filtrelor etc.
2.3.1 Crearea unu i panou utilizând tool -ul CANoe
Panouri le conțin elemente grafice care permit modificarea semnale lor atribuindu -le valorile
dorite, astfel încât utilizatorului să ii fie mai uș or să le controleze. Exemple de elemente care pot fi
adăugate î ntr-un panou creat cu ajutorul Vector Panel Designer sunt : Button, Combo Box, Check
Box, Switch/Indicator, Static Text, Radio Button, Picture Box etc., iar adăugarea elementelor
grafice se face foarte ușor, cu drag and drop .
Rezultatele în urma setă rilor efectuate pot fi observate î n partea de Graphics.
CANoe permite integrarea pano urilor create î n limbajele de programare Visual Basic 6.0,
Visual Basic .NET sau C#.
Pano ul creat în cadrul aplicației conț ine 3 tab -uri :
General Settings
Walk Away Locking
Approach Unlock
Tab-ul General Setting s conține setă ri generale pe care utilizatorul le poate face, cum ar f i
setarea vitezei, deschiderea/închiderea ușilor, apăsarea pedalelor și setarea modului în care să se
afle modulul HFM.
Figura 2 .3 General Settings Tab
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
31
Tab-ul Walk Away Locking con ține zonele func ției WA C :
Inside vehicle
Outside vehicle Z2
Outsi de vehicle Z3
Tab-ul Approach Unloc k conține zonele funcției Approach Unlock :
Approach Unlock
Outsite vehicle
Figura 2 .4 Walk Away Locking Tab
Figura 2 .5 Approach Unlock Tab
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
32
2.4 Diagnoză auto
Cu ajutorul diagnozei auto se pot citi sau se pot configura anumiți parametrii. Prin configurarea
parametrilor se pot face setări pentru anumite funcții ale mașinii. Câteva exemple de setări care se
pot face prin intermediul diagnozei sunt :
Dezactivarea aerului condiționat
Configurarea volanului pe partea dreaptă
Dezacti varea becului de ceață
Dezactivarea airbag -ului
Cu ajutorul diagnozei se pot citi toate problemele întâmpinate , indiferent dacă acestea sunt
pobleme ele ctrice, mecanice sau probleme de comunicare, pe CAN. Partea utilizată pentru găsirea
erorilor prin diag noză se numește DTC (Data Trouble Code).
2.5 Echipamente utilizate în procesul de testare manuală
În continuare sunt prezentate echipamentele ne cesare pentru testarea manuală.
În figura de mai jos este prezentat manual test bench -ul (MTB) și o sursă de tensiune.
MTB -ul este format din input -uri și output -uri.
Input -urile, notate cu I, pot fi setate prin activarea switch -urilor.
Output -urile, notate cu O, pot fi observ ate și int erpretate prin intermediul led -urilor sau
cu ajutorul osciloscopului.
Un exemplu prin care putem observa utilizarea input -urilor și a output -urilor este pornirea
motorului. Pentru a porni motorul este necesară activarea unui input numit I START SW.
Dacă sunt îndeplinite condițiile necesare pornirii și anume :
cheia sa fie în interiorul mașinii
pedal a de ambre iaj este apăsată
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
33
În acel moment se pot observa 3 output -uri ON : O IGN RL2, O PWR IGN și O PWR ACC.
În figura 2.7 este prezentat modulul HFM (Hand s Free Module) :
În figura 2.8 sunt prezentate antenele LF utilizate pentru evidențierea funcțiilor de PASE:
Figura 2 .6 Manual Test Bench
Figura 2 .7 Hands Free Module
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
34
2.5.1 Crearea cazurilo r de test pentru testare manuală
Pentru testarea manuală au fost create două cazuri de test cu ajutorul cărora să fie evidențiate
funcțiile WAC și APU.
În Figura 2.9 este descrisă funcția WA C cu ajutorul unei diagrame. În prima fază, condiția
inițial ă, starea mașinii este : motorul pornit, ușile închise și deblocată . După oprirea motorului ,
utilizatorul părăsește autovehicul ul, iese din mașină și închide ușa (toate ușile autovehiculului
trebuie să fie închise pentru a permite blocarea totală a mașinii ). După acest pas, începe căutare a
cheii în exterior ul mașinii, în zona de siguranță , iar utilizatorul se îndepărtează cu cheia în buzunar .
Căutarea continuă până în momentul în care utilizatorul s -a îndepărtat sufic ient de mașină
(aproximativ 2m) și a ieșit din raza zonei de siguranță, moment în care cheia trimite un semnal de
închidere .
Figura 2 .8 Antene LF
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
35
YES
NO
Legend
Ignition = ON
Doors = Closed
Vehicle Unlocked
Ignition turned to OFF
Door opened
(user exits vehicle)
All doors closed
Vehicle polls for the
key in the exterior
smart range
Customer is walking
away from vehicle
Key replies to vehicle
to show proximity
Does the
key receive
the signal?
Key sends lock signal
to the vehicle
Ignition = OFF
Doors = Closed
User actions
Smart Key Function
Vehicle Locked
Vehicle Unlocked
Figura 2 .9 Descriere func ției Walk Away Locking [11]
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
36
Pentru activarea func ției Walk Away Locking este necesar ă setarea manuală a parametrilor de
configurare din figura 2 .10. Această setare a parametrilor se face cu ajutorul uni tool de diagnoz ă.
În continuare se va prezenta un scenariu prin care se poate observa comportamentul funcției
WAC.
Starea i nițială a mașinii este în modul deblocat , cheia se g ăsește în zona de interior a ma șinii
iar modulu l HFM este în modul Wake Up.
În momentul în care șoferul deschide u șa se începe o verificare și o căutare a cheii at ât în
interior c ât și în exterior, parametrul de diagnoz ă CURRENT_WAC_STATUS trec ând din starea
IDLE în starea de TRACKING. După poziționarea în zona Outside vehicle Z2 la pasul 3) din
procedur ă și dup ă închiderea u șii la pasul 4) cheia va trimite lock request automat în momentul în
care cheia se afl ă în zona Outside vehicle – Z3. Requirement -ul corespuzător acestui scenariu de
test este R EQ_0 1.
REQ_0 1 La trecerea din zona 2 în zona 3 cheia va trimite lock request.
Pentru a realiza scenariul de test este necesară realizarea a trei etape : precondiții, procedură și
rezultate experimentale. În precodiții se specifică setările inițiale, adică starea în ca re se găsește
mașina înainte de execuția pașilor din etapa de procedură.
Scenariul de test prin car e se acoperă requirement -ul REQ_0 1 este TC_0 1 :
TC_01
Precondi ții :
Vehicle State (U nlocked )
Set_PASE_Key_Position ( Inside vehicle)
HFM mode (Wake Up)
Figura 2 .10 Activarea funcției Walk Away Locking
Figura 2 .11 Poziționarea cheii în interiorul mașinii
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
37
Procedur ă și rezultate a șteptate :
Pas 1) SET_CAN : DriverDoor ( Open)
Pas 2) CHECK_DIAG : CURRENT_WAC_STATUS (TRACKING)
CHECK_DIAG : LOCK_BY_WAC_ALLOWED ( FALSE )
CHECK_CAN : HFMRequest (No Request)
Pas 3) Set_PASE_Key_Position ( Outside vehicle – Z2)
CHECK_DIAG : LOCK_BY_WAC_ALLOWED (TRUE)
CHECK_CAN : HFMRequest (No Request)
Pas 4) SET_CAN : DriverDoor ( Close)
CHECK_DIAG : LOCK_BY_WAC_ALLOWED (TRUE)
Pas 5 ) Set_PASE_Key_Position ( Outside vehicle – Z3)
CHECK_CAN : HFMRequest (Lock Request)
CHECK_DIAG : CURRENT_WAC_STATUS (WAC_ST_IDLE)
Rezultatele așteptate se vor compara cu rezultatele obținute după execuția manuală a testului
TC_01, în capitolul „Rezultate Experimentale”.
APU – testare manuală :
În continuare se va prezenta un scenariu prin care se poate observa comportamentul funcției
APU.
Pentru activarea funcției Approach Unlock este necesară setarea manuală a parametrilor din
imaginea de mai jos. Setarea ace stor parametrii se face utilizâ nd un tool de diagnoză.
Inițial mașina este în starea unlocked, cheia se g ăsește în zona de exterior a ma șinii și mod ulul
HFM este în modul Wake Up. În momentul în care șoferul face lock de la cheie începe o căutare a
cheii în exterior, parametrul de diagnoză CAD_APRUN_STATUS fiind
APRUN_CAD_NC_WAIT_APRUN_OR_DEPARTURE. Requirement -ul corespuzător ac estui
scenariu de test este REQ_ 02.
REQ_ 02 La trecerea din zona 2 în zona 1 cheia va trimite unlock request.
Figura 2 .12 Configurare Approach Unlock
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
38
Scenariul de test prin care se acoperă requirement -ul REQ_ 02 este TC_ 02 :
TC_ 02
Precondi ții :
Vehicle State (Un locked )
Set_PASE_Key_Position ( Outside Vehicle )
HFM mode (Wake Up)
Procedur ă și rezultate a șteptate :
Pas 1) SET_RKE_Request (Lock)
Pas 2) CHE CK_CAN : HFMRequest (Lock Request)
CHECK_DIAG: CAD_APRUN_STATUS
(APRUN_CAD_NC_WAIT_APRUN_OR_DEPARTURE)
Pas 3) Set_PASE_Key_Position ( Approach Unlock )
Pas 4) CHECK_DIAG: CAD_APRUN_STATUS (APRUN_CAD_IDLE)
CHECK_CAN : HFMRequ est (Unlock Request)
Rezultatele așteptate se vor compara cu rezultatele ob ținute după e xecuția manuală a testului
TC_0 2, în capitolul „Rezultate Experimentale”.
2.6 CANoe Testing Tool
Pe lângă analiza și simularea diferitelor componente, CANoe este un tool utilizat și pentru
testare automată. Modulele de test conțin secven țe de test care pot fi executate, iar în urma execu ției
se genereaz ă un raport care con ține detalii referitoare la testul rulat. Rezultatul poate fi passed sau
failed. [14]
Figura 2.13 conține setup -ul necesar execuției unui test utilizând tool -ul CANoe. As tfel după
crearea unui modul de test și pornirea simulării de CANoe, în urma căreia are loc comunicarea pe
CAN prin intermediul mesajelor, se poate executa testul și se pot analiza rezultatele salvate în
raport.
Figura 2.13 Test Setup [14]
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
39
În figura 2.14 este prezentat modului de test Test cases Group care conține 3 test cases : HFM
Wake Up, Vehicle Speed și ESCL1.
2.6.1 Automatizarea testelor utiliz ând limbajul de programare CAPL
Automatizarea testelor utiliz ând limbajul de programare CAPL specific pentru CANoe
presupune următorii pa și :
inserarea unui modul de test
editarea unui modul de test
compilarea secven ței de test
salvarea testului pentru utilizare ulterioară
rularea testului
salvarea rezultatelor într-un raport
Rularea și rezultatele vor fi descrise în capitolul „Rezultate Experimentale ”.
Inserarea unui modul de test se face în următorul mod :
View -> Simulation Setup -> Clic k dreapta pe bus -ul de comunicaț ie -> Insert CAPL Test
Module
Figura 2.15 Inserarea unui modul de test CAPL
Figura 2.14 Modul ul de test și cazurile de test
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
40
Pentru editarea modulului de test, se vor respecta următorii pași :
File -> Test Setup -> Test Environment for Test Modules
Pentru realizarea unei secvențe de test se selectează butonul Edit Button din figura 2.16.
În mod normal, o secvență de test conține urmatoarele componente :
testFunction
testcase
MainTest()
În componenta testFunction se cre ează și implementează funcțiile care conțin setările
corespunzătoare testelor.
Secțiune a testcase conține apelul funcțiilor în care s -au implementat setările și totodată se fac
verificările necesare setării corecte .
Funcția MainTest() conține apelul test ca se-ului.
2.6.2 Crearea cazurilor de test pentru testare automată și semiautomată
HFM modes – testare automată :
Modulul de test T C_03 are ca scop verificarea modurilor în care poate să se găsească modulul
HFM. Acest test propune evidențierea testării automate utilizând funcți i specifice pentru testare cu
ajutorul tool -ului CANoe Testing Tool.
REQ_0 3 : Verificarea celor 2 moduri ale modulului HFM.
TC_03
Descriere : Setarea modulului HFM în modul Sleep și Wake U p.
Figura 2 .16 Editarea unui modul de test CAPL
EditButton
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
41
Modulul Hand s free Module se poate afl a în două stări :
Wake up – led-ul corespunzător din figura 2.18 este OFF
Sleep – led-ul corespunzător din figura 2.19 este ON
Pentru a testa cele două modu ri este necesar ă setarea unui parametru de configurare pe valoarea
true, setarea fiind făcută cu ajutorul unui tool de diagnoză.
Figura 2 .18 Modul Wake Up
Figura 2 .17 Wake Up Mode – test case
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
42
Precondiții : CHECK_CAN : HFM Refuse_to_Sleep (Ready to Sleep )
Procedur ă și rezultate așteptate :
Pas 1) SET_CAN : HFMMode (OFF)
Pas 2) SET_CAN : HFMModeStatus (3)
Pas 3) Wait (2s)
Pas 4) CHECK_HW : O_SPARE _RL2 (OFF)
CHECK_CAN : HFM_Refuse _to_Sleep (Refuse To Sleep)
Pas 5) SET_CAN : HFMModeStatus (0)
Pas 6) Wait (10s)
Pas 7) CHECK_HW : O_SPARE_RL2 (ON)
CHECK_CAN : HFM_Refuse _to_Sleep (Ready To Sleep)
Automatizarea testului privind starea în care se afl ă modulul HFM presupune setarea a dou ă
variabile de tip environment care se pot observa în pano ul de mai jos :
Figura 2.20 Setări – HFM mode
Figura 2 .19 Modul Sleep
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
43
În starea i nițială se seteaz ă switch -ul din imagine pe modul OFF (manual) dup ă care se seteaz ă
HFM -ul în starea Wake Up State, adică pe valoarea 3 . Ca urmare a setării acestei valo ri pe 3,
modulul HFM se va trezi. Aceste rezultate se vor observa în capitolul “Rezultate Experimentale”.
Secvența de test corespunzătoare acestei verificări este urmatoarea:
Modul manual fiind setat prin punerea switch -ului pe OFF, se setează HFM -ul pe valoarea 3,
adică Wake Up și se așteaptă 2 secunde. După aceste 2 s ecunde se face o verificare: recepția
semnalul ui HFM_Refuse_to_Sleep din mesajul recepționat de HFM, al cărui id este 0x303.
Această verificare are scopul de a controla daca semnalul s -a setat în mod corect. Dacă răspunsul
este pozitiv testul este considerat „passed” , iar în caz contrar „failed”. La finalul testului H FM
mode se setează pe valoarea inițial ă, 1. Această setare este necesară pentru a nu interfera cu
următoarele teste ce urm ează a fi realizate.
În continuare este descrisă secvența de test utilizată pe ntru automatizarea testului TC_ 03 :
TS_03 :
testcase HFMState()
{
Pentru o înțelegere cat mai bună și o exemplificare cât mai clară a descrierii testului și numelui
acestuia folosim următoarele două funcții: testCaseDescription() și testCaseTitle().
testCaseDescription( "HFM Modes – Wake up and Sleep ");
testCaseTitle ( "","HFM Modes ");
Setarea switch -ului pe poziția OFF se realizează cu funcția HFMMode() :
HFMMode(0);
Setarea valorii 3 pentru modul Wake Up se face apelând funcția HFMModeStatus() :
HFMModeStatus(3);
Se așteaptă 2000 milisecunde (2s) înainte de a se face verificarea recepționării corecte a
mesajului utilizând funcția testWaitForTimeout() :
testWaitForTimeout(2000);
Cu ajutorul funcției TestWaitForTextEvent () se verifică recepționarea mesajului 0x303. Dacă
mesajul a fost recepționat corect și semna lul HFM_Refuse_to_Sleep are valoarea 1 testul este
passed și se apelează funcția testStepPass(). În caz contrar se va apela funcția testStepFail().
if(TestWaitForTextEvent ( "HFMWakeUpMode" , 2000)>0)
{
testStepPass( "","Passed");
}
else
{
testStepFail( "","Check FAIL" );
}
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
44
Pentru setarea valorii 0 pentru modul Sleep apelăm funcția HFMModeStatus() :
HFMModeStatus(0);
Se așteaptă 10 000 milisecunde :
testWaitForTimeout(10000);
Se setează switch -ul pe ON apelând funcția HFMMode( ) :
HFMMode(1);
}
Func țiile create prin care se seteaz ă variabilele de tip environment
EnvBCM_WakeUpSleepCommand_MODE_ și EnvBCM_WakeUpSleepCommand_ sunt create
în secțiunea test function cu ajutorul funcției putValue() :
testfunction HFMMode ( int mode)
{
putValue(EnvBCM_WakeUpSleepCommand_MODE_,mode);
}
testfunction HFMModeStatus ( int status)
{
putValue(EnvBCM_WakeUpSleepCommand_,status);
}
În secțiunea on message se verifică dacă semnalul HFM_Refuse_to_Sleep din mesajul cu id –
ul 0x303 are v aloarea 1. Dacă da, se cre ează un event de tip text prin intermediul căruia se verifică
valoarea semnalului în partea de testcase.
onmessage 0x303
{
if(this.HFM_Refuse_to_Sleep==1)
TestSupplyTextEvent ( "HFMWakeUpMode" );
}
Funcția MainTest() conține apelul testcase -ului HFMState(). Funcțiile testGroupBegin() și
testGroupEnd() specifică începutul și sfârșitul execuției testului HFMState(). În acest caz se
apelează un singur test , însă există posibil itatea execuției mai multor teste în cadrul unui grup din
funcți a MainTest().
void MainTest()
{
testGroupBegin( "","Testare HFM Mode" );
HFMState();
testGroupEnd();
}
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
45
Pentru a putea seta EnvBCM_WakeUpSleepCommand_ pe o valoare este necesar ă setarea
variabilei EnvBCM_WakeUpSleepCommand_MODE_ pe valoarea 0, adică trecerea în modul
manual .
Compilarea codului se realizează apăsând tasta F9 sau selectând icoana de compilare . Dacă
compilarea s -a realizat cu succes se poate t rece la următorul pas, rularea testului , care va fi
prezentată în capitolul „Rezultate Experimentale” .
Setare Vehicle Speed – testare semi automată :
Testul TC_04 are ca scop verificarea pornirii motorului de la o simplă apăsare a butonului de
start în mod manual și setarea vitezei la 30 km/h în mod automat . Pentru acest test se propune
evidențierea testării manuale pentru funcția Easy PASE și totodată a testării automate utilizând
funcții specifice pentru testare cu ajutorul tool-ului CANoe Testing Tool.
REQ_ 03 : Start and stop by PASE
TC_04
Descriere : Start by PASE și s etarea vitezei la 30 km/h, apoi setarea vitezei la 0 km/h după un
timp de așteptare egal cu 10 secunde.
Precondiții : Vehicle unlocked
Key inside
Clutch pedal pressed at maximum
Press start switch (vezi figura 2.22)
Figura 2.21 Vehicle Speed test
case
Figura 2.22 Start Engine
Start Switch
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
46
IgnitionRequest = Ignition Requested
Procedură și rezultate așteptate :
Pas 1) SET_CAN : ClutchSwitchPedal (Press at maximum )
SET_HW : START_SW (ON)
WAIT (2s)
Pas 2) CHECK_HW : O_IGN_RL2 (ON)
CHECK_HW : O_PWR_IGN (ON)
CHECK_HW : O_PWR_ACC (ON)
CHECK_CAN : IgnitionRequest (Ignition Requested)
Pas 3) SET_CAN : Vehicle_Speed (30)
Pas 4) CHECK_DIAG : VEHICLE_SPEED (30)
Pas 5) WAIT (10 s)
Pas 6) SET_CAN : Vehicle_Speed (0 )
Pas 7) CHECK_DIAG : VEHICLE_SPEED (0)
Pas 8) SET_HW : START_SW (OFF)
Pas 9) CHECK_HW : O_IGN_RL2 (OFF)
CHECK_HW : O_PWR_IGN (OFF)
CHECK_HW : O_PWR_ACC (OFF)
CHECK_CAN : IgnitionRequest (No Ignition Requested)
Secven ța de test case presupune apelarea func ției SetSpeed () și verificarea semnalului Ignition
Requested din mesajul cu id -ul 0x303 .
Secven ța testfunction presupune crearea și implementarea unei func ții SetSpeed () utiliz ând
funcția putValue () care va fi apelat ă în secven ța de testcase.
On message con ține mesajul al c ărui id este 0x303 și verific ă dacă semnalul IgnitionRequest
are valoarea egal ă cu 2 sau egal ă cu 1. Dac ă a fost recep ționat mesajul al c ărui semnal
IgnitionRequest este egal cu 2, se seteaz ă un even imen t denumit “IGR” care este verificat în
secven ța de testcase. Dacă semnalul IgnitionRequest este egal cu 1 se setează un event „IGNR”.
Func ția main con ține apelul testcase -ului SetVehicleSpeed() .
Compilare a codului se realizează apăsând tasta F9 sau icoana de compilare . Dacă compilarea
s-a realizat cu succes se poate trece la următorul pas, rularea testului, care va fi prezentată în
capitolul „Rezultate Experimentale”.
Codul corespunzător secvenței de test case TS_0 4, funcțiilor de test și totodată funcția
mainTest() se po ate vizualiza în anexă.
ESCL locked/unlocked – testare semi automată :
Scenariul de test T C_05 are ca scop punerea în evidență a funcțion ării modulului ESCL prin
setarea în mod automat a deschiderii ușii șoferului și pornirea manuală a motorului după închiderea
ușii. Pentru acest test se urmarește evidențierea testării manuale pentru funcția Easy PASE și
totodată a testării automate utilizând f uncții specifice pentru testare cu ajutorul tool -ului CANoe
Testing Tool.
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
47
REQ_ 05 : Verificarea stărilor modulului ESCL locked respectiv unlocked.
TC_05
Descriere : ESCL module – locked și unlocked
Acest modul blochează volanul în momentul în care motorul este oprit și șoferul deschide ușa.
Blocarea volanului este o metodă antifurt. ESCL este unul dintre cele mai importante module din
punct de vedere al securității deoarece trebuie să ne asigurăm că nu se blochează în timpul mersului.
Închiderea, deschiderea u șii șoferului și apăsarea pedalei de ambre iaj la maxim se face în mod
automat iar la finalul testului se așteapt ă recep ționarea mesajului al c ărui id este 0x1F6. Acest mesaj
se recep ționeaz ă în momentul în care ma șina este în starea “engine ru nning”. În cazul în care
mesajul nu se recep ționeaz ă într-o perioad ă de maxim 10 secunde testul va fi failed.
Pentru a fi în starea “engine running” trebuie îndeplinite următoarele condi ții :
Poziționarea cheii – inside vehicle
Pedala de ambre iaj – apăsată la maximum
Pornirea ma șinii se va face utiliz ând func ția Easy PASE descris ă în capitolul 2.3.1
Figura 2.23 reprezintă testul ESCL1 din CANoe Testing Tool :
Precondiții : CHECK_HW : ESCL = Unlocked
Proc edură și rezultate așteptate :
Pas 1) SET_CAN : DriverDoor (Open )
Pas 2) CHECK_CAN : DriverDoorStat e (2)
Pas 3) Wait (10s)
Pas 4) CHECK_HW : ESCL (Locked)
Pas 5) SET_CAN : DriverDoor (Close)
Pas 6) CHECK_CAN : DriverDoorState (1)
Pas 7) SET_CAN : ClutchSwitchPedal (Pressed at maximum)
Pas 8) SET_HW : START_SW (ON)
Pas 9) CHECK_HW : ESCL (Unlocked)
Figura 2.23 ESCL test case
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
48
Secve nța testcase ESCLState() cuprinde setări automate pentru deschiderea ușii șoferului și
apăsarea pedalei de ambre iaj la maxim.
Funcțiile create pentru acest caz de test sunt PressClutchPedal () și SetDriverDoor ().
Mesajul, al cărui id este 0x350, conține semnalul DriverDoorState. În cazul în care acest
semnal s -a recepționat cu succes, în funcție de valoare, 2 sau 1, se va seta un text event care se va
verifica în secțiunea testcase.
Mesajul, al cărui id este 0x1F6, conține semnalul EngineStatus_R. Mesajul este recepționat în
momentul în care pornim mașina în mod manual. Scopul este ca în momentul pornirii să testăm
faptul că modulul ESCL este un locked .
Funcția MainTest() conține apelarea testcase -ului ESCLState() și timp de 10 secunde trebuie
să se recepționeze mesajul cu id -ul 0x1F6 , în caz contra r testul este failed. Pentru recep ționarea
mesajului este necesară acționarea switch -ului din figur a 2.22.
Codul corespunzător secvenței de test case TS_05, funcțiilor de test și totodată funcția mainTest()
se pot vizualiza în anexă.
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
49
3 REZULTATE EXPERIMENTALE
3.1 Rezultate experimenta le pentru testare a manuală
WAC – rezultate obținute :
În urma execuției în mod manual a testul ui TC_0 1, ce urmărește f uncția WAC, se observă
transmiterea de către cheie a unui request de lock în momentul în care șoferul închide ușa și se
îndepărtează de mașină aproximativ 2 metri.
În momentul în care se deschide ușa șoferului la pasul 1) și cheia este detectată în interiorul
mașinii pe diagnoză se verifică parametrul CURRENT_WAC_STATUS care trece din starea IDLE
în starea de TRACKING.
Cu ajutorul osciloscopului se observă polling -ul care este atât în interior cât și în exterior. În
figura 3.2 și 3.3 se observă că pe canalul 1 s-a efectuat măsurarea perioadei pentru ante na de immo
iar pe canalul 2 pentru antena de rear.
Figura 3.1 Parametrii de diagnoză pentru WA C în momentul deschiderii ușii șoferului
Ch1 = IMMO antenna
Ch2 = Rear antenna
Figura 3.2 Polling în interior și exterior – perioada 300 ms
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
50
După o anumită durată de căutare a cheii perioada polling -ului crește de la 300 ms la 500 ms.
Statusul în starea de tracking înseam nă că are loc o căutare a cheii, însă fără a se transmite lock
request.
Ch1 = IMMO antenna
Ch2 = Rear antenna
Figura 3.3 Polling în interior și exterior – perioada 500 ms
Figura 3.4 No request
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
51
După execuția pasului 3), și anume poziționarea cheii în afara mașinii , dar în zona LF, se
observă setarea zonei în panel -ul corespunzător zonei WAC :
După închiderea ușii, l a trecerea din zona 2 în 3, se va trimite lock request.
Figura 3.5 Outside vehicle – zona 2
Figura 3.6 Outside vehicle – zona 3
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
52
În figura 3.7 este reprezentat cu verde semnalul HFMReque st cu valoare Lock by Walk request ,
iar cu mov este reprezentat semnalul VechicleS tate cu valoarea Vehicle Locked . Vizualizarea
semnal elor se face în secțiunea de Graphics din CANoe.
După Lock by WAC request polling -ul continuă în exterior :
Figura 3.7 Lock by Walk Request
Ch1 = IMMO antenna
Ch2 = Rear antenna
Figura 3.8 Polling – Lock by Walk Request
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
53
Verificarea faptului că s -a trimis Lock by Wac request se face și cu ajutorul diagnozei. Astfel
parametrul CURRENT_WAC_STATUS va trece din starea de TRACKING în IDLE , iar
parametrul LAST_WAC_EXIT_TRIG_S_0 va lua valoarea WAC_EXIT_LOCK_BY_WAC_RF.
APU – rezultate obținute :
În urma execuției în mod manual a testul ui TC_0 2 cu privire la corectitudinea funcționării
funcției APU, se observă transmiterea de către cheie a unui request de unlock în momentul în care
șoferul se apropie de mașină.
În panou , la secț iunea Approach Unlock se obser vă detectarea cheii în zona 2.
Figura 3.9 Citirea parametrilor de diagnoză după Lock by Walk request
Figura 3.10 Approach Unlock – zona 2
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
54
Cu ajutorul diagnozei, în momentul în care se trimite lock request prin apăsarea butonului de
la cheie parametrul CAD_APRUN_STATUS va lua valoarea
APRUN_CAD_NC_WAIT_ APRUN _OR_DEPARTURE.
În momentul în care se trimite lock request de la cheie începe o căutare a cheii în exterior , dar
se face o singură căutare și în interior :
La trecerea din zona 2 în zona 1 se va trimit unlock request :
Figura 3.11 Citirea parametrilor de diagnoză înainte de Approach Unlock
Figura 3.12 Polling – înainte de Unlock Request
Figura 3.13 Approach Unlock – zona 1
Ch1 = IMMO antenna
Ch2 = Rear antenna
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
55
În secțiunea de graphics se pot urmări 3 semnale :
Semn alul verde indică mai întâi request -ul de lock de la butonul de la cheie , iar apoi
unlock request -ul trimis în momentul t recerii în zona Approach Unlock
Semnalul alb indică utilizarea cheii , respectiv utilizarea funcției PASE
Semnalul mov indică mai întâi faptul că mașina e locked , iar apoi unlocked
Figura 3.15 Citirea parametrilor de diagnoză după Approach Unlock
Figura 3.14 Lock Request și Unlock Request
Figura 3.16 Polling – după Unlock Request
Ch1 = IMMO antenna
Ch2 = Rear antenna
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
56
3.2 Rezultate experimenta le pentru testare a automată
HFM modes – rezultate obținute :
În urma rulării testcase -ului TC_03 se poate observa , în figura 3.17, la secțiunea Test Cases ,
rezultatul obținut, iar în figura 3.18 , la secțiunea Test Overview se pot observa detalii din timpul
rulării testului. Execuția testului referitor la modurile Wake Up și Sleep în care se poate afla
modulul HFM a durat 12.091s, a fost executat o singură dată iar rezultatul este passed.
În secțiunea Graphics se poate observa trecerea semnalului HFM_Refuse_to_Sleep din modul
Sleep în modul Wake Up.
Figura 3.17 HFM Wake Up test case
Figura 3.18 HFM Wake Up Overview
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
57
În urma rulării testului se generează un raport în ca re se găsesc informații le relevante legate de
Test Setup , dar și informații legate de execuție. În figura de mai jos se po ate observa rapo rtul
generat în urma rulării testului T S_03 :
Figura 3.20 Raport TS_03
Figura 3.19 Semnalul HFM_Refuse_to_Sleep
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
58
3.3 Rezultate experimentale pentru testare a semiautomată
Setare Vehicle Speed – rezultate obținute :
Rezultatul în urma rulării celui de -al doilea testcase TS_04 se poate observa în figura 3.21 la
secțiunea Test Cases , iar în figura 3.22 , la secțiunea Test Overview se pot observa detalii din timpul
rulării testului. Execuția testului referitor la pornirea mașinii și setarea vitezei la 30 km/h a durat
11.135s, a fost executat o singură dată și rezultatul este passed.
Figura 3.21 Set Vehicle Speed test case
Figura 3.22 Set Vehicle Speed overview
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
59
În momentul în care apăsăm butonul de start pe Manual Test Bench se vor observa 3 output –
uri ON iar semna lul IgnitionRequest se setează pe valoarea IgnitionRequested .
În figura 3.2 4 este reprezentat semnalul Ignition Request :
Figura 3.23 Pornire a motorului
a
Figura 3.24 Semnalul Ignition Requ est
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
60
Setarea vitezei se poate observa în panel, în timpul execuției testului. În figura 3.25 a) viteza a
fost setată 30 km/h iar în figura 3.25 b) 0 km/h. În momentul în care setăm viteza egală cu 0 km/h
și apăsăm butonul de Start, cele 3 output -uri vor fi OFF.
O altă verificare se poate face utilizând un tool de diagnoză :
În figura de mai jos se pot observa rapoartele generate în urma rulării testului TS_0 4 :
Figura 3.25 Set Vehicle Speed Panel
Figura 3.26 Citirea vitezei = 30 km/h
Figura 3.27 Citirea vitezei = 0 km/h
a)
b)
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
61
Rezultatul în urma rulării celui de -al treilea testcase T C_05 se poate observa în figura 3. 30 la
secțiunea Test Cases , iar în figura 3. 31, la secțiunea Test Overview se pot observa detalii din timpul
rulării testului. Execuția testului referitor la blocarea și deblocarea volanului a durat 1 4.298 s, a fost
executat o singură dată și rezultatul este passedîn figura 3. 30 respectiv failed în figura 3. 32.
În momentul în care șoferul deschide ușa are loc blocarea volanului iar modului ESCL – locked
este reprezentat în figura 3.29 a). În momentul în care șofe rul intră în mașină, închide ușa și
porneșt e motorul se va debloca volanul, iar modulul ESCL – unlock ed este reprezentat în figura
3.29 b).
Figura 3.28 Raport TS_04
Figura 3.29 Modulul ESCL locked respectiv unlocked
a)
b)
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
62
Dacă în mai pu țin de 10 s ecunde are loc pornirea motorului rezultatul testului este passed :
Figura 3.30 ESCL test cases
Figura 3.31 ESCL overview
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
63
Dacă timp de 10 s nu are loc pornirea motorului rezultatul testului este failed :
Testarea utiliz ând CANoe permite executarea testului cu ajutorul breakpoint -urilor, proces
denumit debugging. În cazul în care un test a picat ș i dorim s ă facem debugging trebuie s ă select ăm
modul debugging și să poziționăm breakpoint -uri în test. Pentru a rula pas cu pas se utilizeaz ă
butonul Step Into.
Figura 3.32 TS_005 test case – failed
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
64
4. CONCLUZII
Procesul de testare este important pentru asigurarea calit ății p rodusul software și trebuie să
fie realizat încă din stadiul incipient ale proiectului.
Lucrarea are ca scop documentarea teoretică cu privire la tehnicile și metodele de testare dar
totodată aprofundarea cunoștințelor cu privire la câteva funcționalități importante din domeniul
automotive. S -a pus accent pe o tehnologie no uă numită Passive Start and Entry, care permite
accesul și pornirea motorului în mod pasiv de către utilizatorul autovehicului. Acest mod presupune
o singură condiție și anume deținerea unei chei valide de către utilizatorul autovehiculului, fără a
fi nece sară o acțiune din partea acestuia. Deblocarea mașinii se face automat în momentul în care
cheia validă este detectată în apropierea mașinii iar blocarea constituie acțiunea inversă, când
utilizatorul se îndepărtează de mașină. Pentru a fi permis modul rem ote pasiv se utilizează
tehnologia LF prin care se identifică poziția cheii valide, adică dacă cheia se află în interiorul sau
în exteriorul mașinii.
Partea de implementare practică presupune descrierea procesului de dezvoltare al unui produs
software și c rearea unor cazuri de test prin care să se pună în evidență comportamentul de bază al
funcționalităților alese utilizând diferite metode de testare : manuală, automată și semiautomată.
Funcționalitățile alese sunt Lock by Walk, Approach Unlock și Electric Steering Column Lock.
Partea de rezultate experimentale conține rezultatele obținute în urma aplicării metodelor de
testare pentru funcționalitățile amintite mai sus . S-a pus accent pe utilizarea testării manuale pentru
sistemul de acces dar s -a arătat ef iciența testării automate utilizând CANoe Testing Tool. Totodată
s-a dorit îmbinarea acestor două tipuri de testare realizându -se astfel testarea semiautomată.
În concluzie lucrarea prezintă concepte utilizate practic în viața de zi cu zi privind domeniul
automotive care este în continuă dezvoltare și toți utilizatorii de automobile doresc un confort și o
siguranța cât mai ridicată pe parcursul condusului. Pentru a asigura o siguranță cât mai mare este
necesar un proces riguros de testare.
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
65
5. BIBLIOGRAFIE
[1] Certified Tester, “Foundation Level Syllabus”, 2011
[2] Byte Craft Limited, “First Steps with Embedded Systems”, 2002
[3] Protocoale de comunicație : http://www.e -automobile.ro/categorie -electronica/11 -protocoale –
comunicatie -automobile.html [05.05.2016]
[4] CANoe Vector, „Programming with CAPL”, 2004
[5] Mircea Vaida, „Software Testing Methodologies”, 2014
[6] Christian Bucanac, “The V -Model”, 1999, University of Karlskrona/Ronneby
[7] Vector Company, “ Hardware for ECU Testing ”, 2008
[8] Aur´elien Francillon, Boris Danev, Srdjan Capkun, „Relay Attack s on Passive Keyless Entry
and Start Systems in Modern Cars”, Department of Computer ScienceETH Zurich,
[9] Continental Automotive, „Product Guide ”, 2014
[10] Asist. Paul POCATILU, „Costurile test ării software”, Catedra de Informatică Economică ,
A.S.E. Bucure ști, Revista Informatic ă Economic ă, nr. 1 (21)/2002
[11]Walk Away Locking, “ Convenience Versus Security ”, 2011
[12] Renault Captur , “ Driver`s Handbook ”
[13] Shivani Acharya, Vidhi Pandya, „Bridge between Black Box and White Box – Gray Box
Testing Technique”, International Journal of Electronics and Computer Science Engineering
[14] Stefan Krauss, “Testing with CANoe ”, Version 1.1, 2009
[15] Black Box și White Box : http://www.softwaretestingclass.com/functional -testing -vs-non-
functional -testing/
[16] Dorothy Graham, Erik van Veenendaal,Isabel Evans, Rex Black, „Foundations Of Software
Testing ISTQB Certification”
[17] Tania Martinez, “Body Control Module (BCM)”, 2009
[18] Testare manuală și automată 1 : http://www.base36.com/2013/03/automated -vs-manual –
testing -the-pros-and-cons-of-each/ [01.06.2016]
[19] Testare manuală și automată 2 :
http://testingbasicinterviewquestions.blogspot.ro/2014/09/manual -testing -vs-automation –
testing.html [03.07.2016]
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
66
[20] Continental Automotive, „Training Introduction to I & BS Product Software / System
Testing”
[21] Continental Automotive, „Body and Security – 4th Generation PASE”
[22] Entry and Exit Criteria in Software Testing : http://www.rishabhsoft.com/blog/entry -and-
exit-criteria -in-software -testing
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
67
6. ANEXE
/*Test case T C_03:
Descriere : Setarea modurilor Sleep HFM si Wak e up HFM.
Conditii initiale : IgnitionRequest = No Ignition Requested
Procedura si rezultate asteptate :
Pas 1) Set : HFMMode = Manual
Pas 2) Set : HFM Value = 3
Pas 3) Check : HFMRefuseToSleep = Refuse to sleep
Pas 4) Wait 3 s
Pas 5) Set : HFM Value = 0
Pas 6) Check : HFMRefuseToSleep = Ready to sleep
*/
testcase HFMState()
{
HFMMode(0);
HFMModeStatus(3);
testWaitForTimeout(2000);
testStep( "","Check Event" );
if(TestWaitForTextEvent ( "HFMWakeUpMode" , 2000)>0)
{
testStep("","Check OK" );
testStepPass( "","A trecut" );
}
else
{
testStepFail( "","Check FAIL" );
}
HFMModeStatus(0);
testWaitForTimeout(10000);
}
testfunction HFMMode ( int mode){
putValue(EnvBCM_WakeUpSleepCommand_MODE_,mode);
}
testfunction HFMModeStatus ( int status){
putValue(EnvBCM_WakeUpSleepCommand_,status);
}
onmessage 0x303
{
if(this.HFM_Refuse_to_Sleep==1)
TestSupplyTextEvent ( "HFMWakeUpMode" );
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
68
}
void MainTest()
{
testGroupBegin( "","Testare HFM Mode" );
HFMState() ;
testGroupEnd();
}
/*Test case T C_04 :
Descriere : Setarea vitezei la 30 km/h si setarea vitezei la 0 km/h dupa 10
secunde.
Conditii initiale : IgnitionRequest = No Ignition Requested
Vehicle unlocked
Procedura si rezultate ast eptate :
Pas 1) Set : VehicleSpeed = 30 (km/h)
Pas 2) Wait : 10 s
Pas 3) Check : IgnitionRequest = Ignition Requested
Pas 4) Set : VehicleSpeed = 0 (km/h) and press start switch
Pas 5) Wait : 1 s
Pas 6) Check : IgnitionRequest = No Ignition Requested
*/
testcase SetVehicleSpeed()
{
testCaseDescription( "Set Vehicle Speed" );
testCaseTitle ( "","Vehicle Speed" );
SetSpeed(30);
testWaitForTimeout(10000);
testStep( "","Check Event" );
if(TestWaitForTextEvent ( "IGR", 2000)>0)
{
testStep( "","Check OK" );
testStepPass( "","Passed" );
}
else
{
testStepFail( "","Check FAIL" );
}
SetSpeed(0);
if(TestWaitForTextEvent ( "IGNR", 2000)>0)
{
testStep( "","Check OK" );
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
69
testStepPass( "","Passed" );
}
else
{
testStepFail( "","Check FAIL" );
}
}
onmessage 0x350
{
if(this.DriverDoorState==2)
TestSupplyTextEvent ( "DriverDoorOpen" );
else
if(this.DriverDoorState==1)
TestSupplyTextEvent ( "DriverDoorClose" );
}
onmessage 0x1F6
{
if(this.EngineStatus_R==2)
TestSupplyTex tEvent ( "Engine is running" );
}
void MainTest()
{
testGroupBegin( "","Testare ESCL" );
ESCLState();
if(TestWaitForTextEvent ( "Engine is running" , 10000)>0)
{
testStep( "","Check OK" );
testStepPass( "","A trecut" );
}
else
{
testStepFail( "","Check FAIL" );
}
testGroupEnd();
}
testfunction SetSpeed ( int speed){
putValue(EnvVehicleSpeed_,speed);
}
onmessage 0x303
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
70
{
write("IG:%d",this.IgnitionRequest);
if(this.IgnitionRequest==2)
TestSupplyTextEvent ( "IGR");
else
if(this.IgnitionRequest==1)
TestSupplyTextEvent ( "IGNR");
}
void MainTest()
{
testGroupBegin( "","Testare Vehicle Speed" );
SetVehicleSpeed();
testGroupEnd();
}
/*Test case TS_0 5 :
Descriere : Modulul ESCL de ESCL se blocheaza in momentul in care soferul
deschide usa
Conditii initiale : IgnitionRequest = No Ignition Requested
Vehicle unlocked
Procedura si rezultate asteptate :
Pas 1) Set : DriverDoor = opened
Pas 2) Wait : 2 s
Pas 3) Check (manual): ESCL = Unlocked
Pas 4) Set : DriverDoor = closed
*/
testcase ESCLState()
{
SetDriverDoor(2);
testWaitForTimeout(10000);
testStep( "","Check Event" );
if(TestWaitForTextEvent ( "DriverDoorOpen" , 2000)>0)
{
testStep( "","Check OK" );
testStepPass( "","A trecut");
}
else
{
testStepFail( "","Check FAIL" );
}
SetDriverDoor(1);
if(TestWaitForTextEvent ( "DriverDoorClose" , 2000)>0)
{
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
71
testStep( "","Check OK" );
testStepPass( "","A trecut" );
}
else
{
testStepFail( "","Check FAIL" );
}
PressClutchPedal(2);
}
testfunction PressClutchPedal ( int max){
putValue(EnvClutchSwitchMaximumTravel_,max);
}
testfunction SetDriverDoor ( int state){
putValue(EnvDriverDoorState_,state);
}
on message 0x350
{
if(this.DriverDoorState==2)
TestSupplyTextEvent ( "DriverDoorOpen" );
else
if(this.DriverDoorState==1)
TestSupplyTextEvent ( "DriverDoorClose" );
}
on message 0x1F6
{
if(this.EngineStatus_R==2)
TestSupplyTextEvent ( "Engine is running" );
}
void MainTest()
{
testGroupBegin( "","Testare ESCL" );
ESCLState();
if(TestWaitForTextEvent ( "Engine is running" , 10000)>0)
{
testStep( "","Check OK" );
testStepPass( "","A trecut" );
}
else
{
testStepFail( "","Check FAIL" );
}
testGroupEnd();
}
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: TEHNICI DE TESTARE APLICATE IN DOMENIUL AUTOMOTIVE LUCRARE DE DISERTAȚIE Autor: Claudiu -Florin PĂUȘIAN Conduc ător științific: Asis.Dr.Ing. Ioan… [610146] (ID: 610146)
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.