Cuprins ………………………….. ………………………….. ………………………….. …………………………….. [608316]

1
Cuprins
Cuprins ………………………….. ………………………….. ………………………….. ………………………….. ………………. 1
1. Rezumat -Summary ………………………….. ………………………….. ………………………….. ……………………. 3
2. Planificarea activității ………………………….. ………………………….. ………………………….. ……………………. 8
3. Stadiul actual ………………………….. ………………………….. ………………………….. ………………………….. …… 9
3.1 Apariția și evoluția sistemelor embedded ………………………….. ………………………….. ………………………. 9
3.1.1 Dezvoltarea și importanța tehnologiei informației ………………………….. ………………………….. …………. 9
3.1.2 Testarea software ………………………….. ………………………….. ………………………….. ……………………….. 10
3.1.3 Eșecuri software ………………………….. ………………………….. ………………………….. ………………………… 10
3.1.4 Istoric al dezvoltării testării ………………………….. ………………………….. ………………………….. ………….. 12
3.1.5 Metodologii moderne ………………………….. ………………………….. ………………………….. ………………….. 13
3.2 Importanța testării ………………………….. ………………………….. ………………………….. ………………………. 13
3.2.1 De ce este necesară testarea software? ………………………….. ………………………….. …………………….. 13
3.2.2 Obiectivele testării ………………………….. ………………………….. ………………………….. ……………………… 14
4. Fundamentarea teoretică ………………………….. ………………………….. ………………………….. ……………… 15
4.1 De finiția testării software ………………………….. ………………………….. ………………………….. …………………… 15
4.2 Necesitatea testării. Cauzele și costurile erorilor ………………………….. ………………………….. ……………….. 15
4.3 Metode de testare ………………………….. ………………………….. ………………………….. ………………………….. … 16
4.3.1 Testarea funcțională ………………………….. ………………………….. ………………………….. ……………………. 16
4.3.2 Testarea non -funcțională ………………………….. ………………………….. ………………………….. …………….. 16
4.4 Tehnici de testare ………………………….. ………………………….. ………………………….. ………………………….. …. 16
4.4.1 Testarea Black Box ………………………….. ………………………….. ………………………….. ………………………. 16
Tehnici care pot fi utilizate în proiectarea testelor Black box: ………………………….. ………………………….. …… 17
4.4.2 Testarea White Box ………………………….. ………………………….. ………………………….. …………………….. 17
4.5 Rolul testerului ………………………….. ………………………….. ………………………….. ………………………….. …….. 18
4.6 Testarea Modulelor (Module Testing) ………………………….. ………………………….. ………………………….. ….. 19
4.7 Testarea de integrare (Integration Testing) ………………………….. ………………………….. ………………………. 20
4.8 Software system testing ………………………….. ………………………….. ………………………….. …………………….. 21
4.8.1 Roluri și responsabilități ………………………….. ………………………….. ………………………….. ………………. 22
4.9 Testarea manuală VS Testarea automată ………………………….. ………………………….. …………………………. 22
4.9.1 Ce este testarea manuală? ………………………….. ………………………….. ………………………….. …………… 22

2
4.9.2 Ce este testarea automata? ………………………….. ………………………….. ………………………….. …………. 23
4.9.3 Diferențe între testarea manuală și cea automata ………………………….. ………………………….. ………. 23
4.9.4 Avantaje Testarea Manuală ………………………….. ………………………….. ………………………….. ………….. 26
4.9.5 Dezavantaje Testarea Manuală ………………………….. ………………………….. ………………………….. …….. 26
4.9.6 Avantaje Testarea Automată ………………………….. ………………………….. ………………………….. ………… 26
4.9.7. Dezavantaje Testarea Automată ………………………….. ………………………….. ………………………….. ….. 27
4.9.8 Concluzii ………………………….. ………………………….. ………………………….. ………………………….. ………… 27
4.10 Testarea în Automotive Embedded Systems ………………………….. ………………………….. …………………… 27
4.11 ECU – Electronic Control Unit ………………………….. ………………………….. ………………………….. ……………. 28
4.12 Rețele de comunicații în vehicule (Vehicle network) ………………………….. ………………………….. ………… 28
4.12.1 Controller Area Network (CAN) ………………………….. ………………………….. ………………………….. …… 29
4.12.2 FlexRay ………………………….. ………………………….. ………………………….. ………………………….. ………… 30
4.12.3 MOST and LIN ………………………….. ………………………….. ………………………….. ………………………….. . 31
4.13 CANalyzer and CANoe ………………………….. ………………………….. ………………………….. ……………………… 31
4.14 Limbajul de progrmare CAPL ………………………….. ………………………….. ………………………….. …………….. 33
4.14.1 Mediul de programare CAPL ………………………….. ………………………….. ………………………….. ………. 33
4.14.2 CAPL răspunde la evenimente ………………………….. ………………………….. ………………………….. …….. 34
5. Implementarea solutiei adoptate ………………………….. ………………………….. ………………………….. …… 36
5.1 Crearea și editarea blocurilor ………………………….. ………………………….. ………………………….. ……………… 37
5.2 Crearea bazei de date (Database) ………………………….. ………………………….. ………………………….. ……….. 46
5.3 Definirea nodurilor ………………………….. ………………………….. ………………………….. ………………………….. .. 48
5.4 Definirea mesajelor ………………………….. ………………………….. ………………………….. ………………………….. . 49
5.5 Defini rea semnalelor ………………………….. ………………………….. ………………………….. …………………………. 51
5.6 Editarea codului ………………………….. ………………………….. ………………………….. ………………………….. ……. 51
6. Rezultate experimentale ………………………….. ………………………….. ………………………….. ………………. 56
7. Concluzii ………………………….. ………………………….. ………………………….. ………………………….. ………. 61
8. Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. …… 62
9. Anexe ………………………….. ………………………….. ………………………….. ………………………….. …………… 63

3
1. Rezumat -Summary
Software systems are an integral part of life, from business applications (e.g. banking) to
consumer products (e.g. cars). Most people have had an experience with software that did not work
as expected. Software that does not work correctly can lead to man y problems, including loss of
money, time, or business reputation, and even injury or death. Software testing is a way to assess
the quality of the software and to reduce the risk of software failure in operation.
A common misperception of testing is that it only consists of running tests, executing the
software and checking the results. Software testing is a process which includes many different
activities, test execution (including checking of results) is only one of these activities. The test
process als o includes activities such as test planning, analyzing, designing, and implementing tests,
reporting test progress and results, and evaluating the quality of a test object.
Some testing does involve the execution of the component or system being tested, su ch testing
is called dynamic testing. Other testing does not involve the execution of the component or system
being tested, such testing is called static testing. So, testing also includes reviewing work products
such as requirements, user stories, and sou rce code.
Another common misperception of testing is that it focuses entirely on verification of
requirements, user stories, or other specifications. While testing does involve checking whether the
system meets specified requirements, it also involves vali dation, which is checking whether the
system will meet user and other stakeholder needs in its operational environment.
Test activities are organized and carried out differently in different lifecycles.
In first chapter is described the State of Art. It co nsists in bibliographic documentation aimed
at setting the reference in which the subject is located. It described how the embedded systems
appears and how their evolution. A good part of this chapter is about the development and
importance of information technology. Information technology, over the past decade, has changed
the world as we know it. Today, it forms a fundamental part of almost all sectors, be it industrial,
educational, or any other. Information technology today is essential in ensuring the smooth
functioning of all the departments in a company, such as the human resource department, finance
department, manufacturing department and in security related purposes.
The manufacturing and production companies, such as those in the automobile sector , use IT
and software products to get rid of any sort of errors or mistakes, in the proper functioning of the
tools used for designing and manufacturing purposes. Further, thanks to the developments in the
information technology sector, these companies are able to keep themselves aware of the changes
in the global markets.
An another good part is about errors, defects and failures. A person can make an error
(mistake), which can lead to the introduction of a defect (fault or bug) in the software code or in
some other related work product. An error that leads to the introduction of a defect in one work
product can trigger an error that leads to the introduction of a defect in a related work product. For
example, a requirements elicitation error can lead to a requirements defect, which can result in a
programming error that leads to a defect in the code.
If a defect in the code is executed, this may cause a failure, but not necessarily in all
circumstances. For example, some defects require very specific inputs or preconditions to trigger
a failure, which may occur rarely or never. Errors may occur for many reasons such as: time

4
pressure; human fallibility; inexperienced or insufficiently skilled project participants;
miscommunication between project participant s, including miscommunication about requirements
and design; complexity of the code, design, architecture, the underlying problem to be solved; new,
unfamiliar technologies.
An another part contains the test development history, divided into some parts, st arted at the
beginning from 1945 continuing to nowadays.
The following chapter is the theoretical foundation. This chapter contains all description to
reach the essence of these study: a comparation between manual testing and automatic testing in
automoti ve domain.
It begins with a definition of testing.
• What is software system testing?
Software testing is defined as an activity to check whether the actual results match the expected
results and to ensure that the software system is runs correctly. It involves execution of a software
component or system component to evaluate one or more pr operties of interest.
Software testing also helps to identify errors, gaps or missing requirements in contrary to the actual
requirements. It can be either done manually or using automated tools. Some prefer saying Software
testing as a White Box and Black Box Testing .
• Black Box testing
Black -box testing is a method of software testing that examines the functionality of an
application without peering into its internal structures or workings. This method of test can be applied
virtually to every level of software testing: unit, integration , system and acceptance . It is sometimes
referred to as specification -based testing. Specific knowledge of the application's code, inter nal
structure and programming knowledge in general is not required. The tester is aware of what the
software is supposed to do but is not aware of how it does it. For instance, the tester is aware that a
particular input returns a certain, invariable outpu t but is not aware of how the software produces the
output in the first place.
• White Box testing
White -box testing (also known as clear box testing , glass box testing , transparent box
testing , and structural testing ) is a method of software testing that tests internal structures or
workings of an application, as opposed to its functionality (i.e. black -box testing ). In white -box testing
an internal perspective of the system, as well as programming skills, are used to design test cases. The
tester chooses inputs to exercise paths through the code and determine the expe cted outputs. This is
analogous to testing nodes in a circuit, e.g. in-circuit testing (ICT). White -box testing can be applied
at the unit, integration and system levels of the sof tware testing process. Although traditional testers
tended to think of white -box testing as being done at the unit level, it is used for integration and system
testing more frequently today. It can test paths within a unit, paths between units during integ ration,
and between subsystems during a system –level test. Though this method of test design can uncover
many errors or problems, it has the potential to miss unimplemented parts of the specification or
missing requirements.
Types of testing:
-Module test ing

5
-Integration testing
-System testing

• Module testing
Module testing is defined as a software testing type, which checks individual subprograms,
subroutines, classes, or procedures in a program. Instead of testing whole software program at once,
module testing recommends testing the smaller building blocks of the program. Module testing is
largely a white box oriented. The objective of doing Module, testing is not to demonstrate proper
functioning of the module but to demonstrate the presence of an error in the module. Module level
testing allows to implement parallelism into the testing process by giving the opportunity to test
multiple modules simultaneously.
• Integration testing
Integration Testing is a level of software testing where individual units are combined and tested
as a group. The purpose of this level of testing is to expose faults in the interaction between integrated
units. Test drivers and test stubs are used to assist in Integration Testing.
• System testing
System testing is testing conducted on a complete integrated system to evaluate the system's
compliance with its specified requirements .
System testing takes, as its input, all of the in tegrated components that have passed integration
testing . The purpose of integration testing is to detect any inconsistencies between the units that are
integrated t ogether (called assemblages ). System testing seeks to detect defects both within the "inter –
assemblages" and also within the system as a whole. The actual result is the behavior produced or
observed when a component or system is tested.
System testing is performed on the entire system in the context of either functional
requirement specifications (FRS) or system requirement specification (SRS), or both. System testing
tests not only the design, but also the behaviour and even the believed expectations of the customer. It
is also intended to test up to and beyond the bounds defined in the software or hardware requirements
specification(s).

Manual testing vs Automated testing
• Manual testing
Manual testing is the process of manually testing software for defects. It requires a tester to
play the role of an end user whereby they use most of the application's features to ensure correct
behavior. To guarantee completeness of testing, the tester often follows a written test plan that leads
them through a set of important test cases . Large scale engineering projects that rely on manua l
software testing follow a more rigorous methodology in order to maximize the number of defects that
can be found. A systematic approach focuses on predetermined test cases and generally involves the
following steps.
• Automated testing

6
In software testing , test automation is the use of software separate from the software being
tested to control the executi on of tests and the comparison of actual outcomes with predicted
outcomes.[2] Test automation can automate some repetitive but necessary tasks in a formalized testing
process al ready in place, or perform additional testing that would be difficult to do manually. Test
automation is critical for continuous delivery and continuous testing .
The next chapter is the Implementation. The implementation represent the application, which
test a cluster from a vehicle. The application is edited with CANoe, with Panel editor, ant the code was
written in CAPL ( CAN Access Programming Language ). Based on the C programming language,
CAPL, or CAN Access Programming Languag e, is the programming language used exclusively within
the PC -based tool environments of CANalyzer and CANoe .
Any number of nodes may be simulated in a CANoe environment. Each simulated node has its
own corresponding CAPL program. Dividing a system into i ndividual nodes may provide the
additional advantage of reusability for subsequent system developments.
In addition, CANoe supports multiple CAN network system simulations. If we are using
CANoe on a vehicle that requires four different CAN networks with multiple nodes in each network,
for example, CANoe is capable of simulating all four CAN networks at the same time. If node
simulations are not required, CANoe can be used as a gateway for sharing data from different networks
and can perform cross -network calculations such as verifying data throughput and latency.
Using DataBase with CAPL
What is a database? It is a look -up table that allows decoding of the bus -oriented raw data into
symbolic interpretations. In other words, the database is much like a blue print that categorizes bus data
in symbolic terms. The CANdb++ Editor allows you to define and modify such a database so as to
symbolically represent your CAN bus.
Within the CAPL programming environment, the developer has the ability to access user –
defin ed information in a database. Databases may be used in both CANalyzer and CANoe for network
measurements or custom applications. Either database editor, CANdb or CANdb++, can be used to
create a suitable network or application -specific database. To learn m ore about the database editor, see
Using CANdb++ to Create a Database .
The Panel Editor is used to create graphic panels. Besides an I/O interface using buttons and
switches, the Panel Editor also uses bitmaps for display and for controls to show different graphical
values. After the panels are created, they must be associated to CANoe to be used.
Communication between panels and CAPL involves environment variables. All dynamic
control elements within a panel should be associated with an environment variabl e while the panel is
being created. When the user clicks or adjusts the value of a control, the associated environment
variable’s value will change as an environment variable event procedure is executed in CAPL. These
variables should already be defined in the database, along with messages and signals. If they are
defined in the database, CAPL will have access to them. On the other hand, the value of the
environment variables can also be changed by CAPL. These changes will also affect the displayed
controls on the panel .
Following this step, the application is borned. It contain two main panel. One of them is the
control and another is the display which is correspond with a cluster from a vehicle. The control is

7
devided into two parts: engine control and the lights control. From the engine control can controlled
the Ignition, velocity, engine rotation and the coolant temperature. From Lights control can controlled
the actual light: position light, low beam, high beam, hazard lights and Stop lights, which stop s all the
lamps.
These values which are set from control, can be viewed on display panel. Velocity, rotation
and coolant temperature is displayed both with pointers and digitally. In display exists a car which
lamps state can be modified, and the actual li ght symbol is displayed.
On the experimental results those ones aboves were tested. On the trace the messages were
verified, if the corresponding values are transmitted.
The final parts contains some conclusions about software testing automotive domain: why it is
necessary, which are the costs, etc.

8
2. Planificarea activității

9
3. Stadiul actual
3.1 Apariția și evoluția siste melor embedded
3.1.1 Dezvoltarea și importanța tehnologiei informației
Din punct de vedere istoric, termenul de tehnologia informației se referă la toate tehnologiile
asociate cu colectarea, prelucrarea, stocarea și răspândirea informațiilor. Cu toate acestea, odată cu
trece rea timpului și progresul tehnologiilor, termenul a dobândit conotații diferite. Termenul modern,
tehnologia informației (IT), a intrat în utilizare pe scară largă numai la sfârșitul anilor 1970 și este
acum folosit în general, pentru a cuprinde atât tehno logiile computerizate cât și tehnologiile de
comunicare precum și fundamentul lor comun – tehnologia microelectronică și toate tehnologiile
software asociate.
Până în 1970, tehnologiile computerizate și tehnologiile de telecomunicație erau considerate
ca fiind destul de diferite. Cu toate acestea, schimbări tehnologice puternice în microelectronică,
software, optică și integrarea în continuă creștere a telecomunicațiilor cu tehnologiile informatice au
făcut această distincție din ce în ce mai puțin semnifi cativă. Tehnologia microelectronică a reprezentat
baza comună atât pentru dezvoltarea rapidă cât și pentru convergența tehnologiilor de telecomunicații
cu cele informatice. Trecerea de la tehnologiile analogice la cele digitale în domeniul
telecomunicațiil or a dus la sistemele de comutare și transmisie care seamănă tot mai mult cu
computerele și încorporează o cantitate tot mai mare de software. Numeroase mijloace de comunicare
sunt, în prezent, mai mult sau mai puțin asemănătoare computerelor cu utilizări speciale. În plus, o
dată cu dezvoltarea tehnologiei rețelelor, comunicațiile între computere s -au extins enorm de la
începutul anilor 1960, atunci când s -au dezvoltat pentru prima dată sistemele online computerizate.
Împreună, aceste evoluții au estompat distincțiile tradiționale dintre telecomunicații și tehnologiile
informatice și a dat naștere la definirea contemporană a tehnologiei informației.
Americanul Thomas Watson, unul dintre cei mai importanți oameni de afaceri ai IBM
(International Business Machines) a prezis că doar 5 calculatoare sunt necesare în întreaga
lume. Aceasta precizare a avut la bază folosirea calculatoarelor în doar câteva domenii precum: în
aplicații de guvern și afaceri, domeniul bancar, asigură ri și în efectuarea unui recesământ.
Acum, oricine conduce o mașină, folosește un computer încorporat, nu ca un concept, acesta
conținând mai multă putere de calcul decât computerele folosite, în perioada futuristă a tehnologiei
software, de NASA pentru a trimite anumite misiuni pe Lună.
Există milioane de telefoane mobile, dintre care multe sunt computer portabile care sunt din ce
în ce mai inteligente cu fiecare nou model lansat pe piață.
Cu toate că tehnologia software a prezentat și încă prezintă o e voluție extraordinară, acest
triumf tehnologic nu este perfect. Aproape fiecare persoană din lume a avut tangență cu tehnologia
informației, și de nenumărate ori au apărut frustrare și timp pierdut din cauză că softul a dat greș,
echipamentul nemaifuncțion ând sau prezentând un comportament neașteptat. Unele personae și
companii au experimentat pierderi financiare sau pătarea reputației lor personală sau de afaceri, ca
urmare a softului defect. S -au înregistrat și cazuri în care datorită unor eșecuri softwar e, oameni au
fost răniți sau chiar uciși.

10
3.1.2 Testarea software
Reprezintă o investigație empirică realizată cu scopul de a oferi părților interesate informația
vizavi de calitatea produsului sau a serviciului supus testării, luând în considerație contextul
operațional în care acesta dun urmă va fi folosit. Testarea Software pune la dispoziție o viziune
obiectivă și independentă asupra produsului în dezvoltare, oferind astfel businessului posibilitatea de
a înțelege și evalua riscurile asociate cu implementarea produslui soft. Tehnicile de testare includ, dar
nu sunt limitate la, procesul de execuție a programului sau aplicației în scopul identificării
defectelor/erorilor de software. Testare Software mai poate fidefinită ca un proces de validare și
verificare a faptului că un program/aplicație/produs software corespunde business cerințelor și
cerințelor tehnice care au ghidat proiectarea și implementare lui, și rulează și se comportă
corespunzător așteptărilor.
În dependență de metodolog ia de testare aleasă , Testarea Software poate fi implementată la
orice etapă în cadrul procesului de dezvoltare, deși partea considerabilă a efortului de testare de obicei
este aplicată la etapa de după cizelarea/formalizarea cerințelor și finisarea imple mentării/codării
propriu -zise.
Nu există un astfel de proces de testare ce ar permite identificarea tuturor defectelor posibile
ce le poate conține un produs software. În schimb, un astfel de proces poate furniza o viziune critică
sau comparativă, care vin e să contrapună unele aspecte ale produsului (cum ar fi: starea și
comportamentul actual) și metricile și constrângerile care servesc drept criterii de acceptanță. Aceste
criterii pot fi derivate din specificații , produse asemănătoare comparabile, versiun i anterioare ale
aceluiași produs, așteptări față de produs enunțate de către utilizator sau client, standarde relevante,
legi în vigoare, etc.
Fiecare produs software are o audiență caracteristică. De exemplu, audiența pentru un produs
din industria autom otive este complet diferită de audiență unui produs din sistemul financiar -bancar.
De aceea, când o organizație dezvoltă sau investește în dezvoltarea unui produs software, ea trebuie să
fie capabilă să evalueze acceptabilitatea produsului din perspectiva utilizatorilor finali, audienței țintă,
cumpărătorilor și altor părți interesate. Testarea software este procesul care vine să facă această
evaluare posibilă într -un mod cât mai obiectiv.
Un stidui efectuat în anul 2002 de către NIST a arătat că pierderil e anuale pentru economia
SUA cauzate de defecte de software se estimează la 59,5 miliarede de dolari. Mai mult de treime din
aceste pierderi s -ar fi putut evitate dacă s -ar fi făcut investiții mai serioase în implementarea procesului
de testare.[3]
3.1.3 Eșecuri software
Odată cu dezvoltarea tehnologiei informație i, au apărut și eșecurile sau defectele software. Cu
toate că tehnologia s -a dezvoltat foarte mult prin automatizarea pe scar ă largă în multe domenii,
ingineria software rămâne o activitate inten siv uman ă. Oamenii nu sunt ființe fără greș. Deci software –
ul dă greș deoarece oamenii dau greș. Deci o eroare este o acțiune umană care duce la un rezultat
incorect. O eroare odată apărută într -un program duce la un defect asupra echipamentului în care es te
încorporat softul. Un defect apărut intr -o componentă sau într -un sistem poate face ca sistemul sau
componenta să nu își îndeplinească funcția dorită. Totodată poate provoca o defecțiune sau un
comportament neașteptat, care po ate duce la diverse pagube.
Deci, ființele umane sunt supuse greșelilor, și prin urmare atunci când lucrează, ele introduc
uneori erori. Această introducere de erori nu e ste întâmplătoare, deși unele greșeli sunt introduse

11
aleator. Oamenii fac cele mai multe greșeli atunci când sun t sub presiunea timpului, atunci când
lucrează cu sisteme complexe, interfețe, cod sau atunci când au de -a face cu schimbarea tehnologiei
sau a sistemelor interconectate.
În timp ce oamenii de rând consideră că eșecurile apar datorita erorilor produse în cod, un
număr semnificativ de defecte sunt introduse în diverse etape de proiectare și dezvoltare a produsului,
cum ar fi la etapa în care se trasează cerințele sau etapa care cuprinde specificațiile de proiectare.
Capers Jones spune ca aproximativ 20% di n defecte sunt introduse în cerințe și aproximativ 55 % sunt
introduse în timpul implementării sau a corectării codului. Și alți experți și cercetători au ajuns la
concluzii similare, aceștia constatând că aproximativ 75% din defecte sunt originare din cer ințe și
proiectare.
Ideal, defectele ar trebui eliminate în aceeași fază a ciclului de viață în care acestea sunt
introduse. Măsura în care defectele sunt eliminate în faza de introducere se numește faza de izolare.
Faza de izolare este importantă, deoare ce costul de găsirea și eliminarea al unui defect crește de fiecare
dată când un defect trece la următoarea fază a ciclului de dezvoltare, a produsului.
În figura 1, se poate observa o statistică a costului de reparație în raport cu etapa de dezvoltare
a produsului, în care s -a găsit eroarea.

Figura 1. Costul de reparație a produsului în funcție de etapa în care s -a găsit eroarea

Pe baza acestui grafic se poate observa cu ușurință ce pierderi financiare apar în momentul
apariției unei erori. Astfel, dacă eroarea este găsită în momentul în care se primesc și se analizează
cerințele de la client, implică un cost minim în rezolvarea erorii, dacă se depistează eroarea în etapa
de Design, se poate observa foarte ușor că are loc o creștere a costul ui de reparație. Continuând analiza
pe graficul de mai sus, se ajunge la concluzia că, cu cât avansează produsul în etapele de dezvoltare,
costul de reparație de dublează. În cazul în care erorile sunt găsite după ce produsul a fost lansat pe
piața costuri le pentru repararea lor ajung să fie exorbitante. Au fost nenumărate cazuri, când firmele
au trebuit sa retragă produsele de pe piață din cauza găsirii unor erori târziu, după ce acestea au fost
lansate pe piață. Unele firme chiar au intrat în faliment din cauza găsirii erorilor prea târziu, acestea
implicând niște costuri de reparație peste puterile financiare ale firmei.
Este foarte important ca erorile să fie depistate cât mai devreme în ciclul de dezvoltare a
produsului pentru ca acestea să fie repara te la costuri cât mai mici. [1]

12
3.1.4 Istoric al dezvoltării testării
Gelperin și Hetzel au analizat evoluția conceptului de testare a unui sistem informatic și au
împărțit evoluția acestuia în mai mult etape, în funcție de filozofia care a stat la baza ceonceptului.
• 1945 -1956 – Orientarea spre depanare
În perioada apariției primelor sisteme informatice – 1945 -1956, procesul de testare era în
special orientat către componentele hardware ale sistemului, defectele din software erau în general
considerate ca fiind mai puțin importante. Persoanele care se ocupau cu elaborarea codului se ocupau
și de partea de testare, desi nu o făc eau într -o manieră metodică, și denumeau această activitate
verificare. Din această perioadă timpurie se datează prima referire la conceptul de “bug” într-un sistem
informatic, când un operator al unui calculator descoperă pe un circuit electronic care fun cționa
defectuos o molie, și o atașează în jurnalul de operațiuni, cu mențiunea că a descoperit primul bug
propriu -zis într -un calculator. Termenul de “bug” în sine este mai vechi, datând din perioada lui
Thomas Edison. Primul savant care s -a ocupat de noț iunea de testare a unui program este Alan Turing
care publică în 1949 un articol despre principiile teoretice ale verificării corectitudinii funcționării unui
program. În 1950, Turing publică un alt articol, în care ridică problema inteligenței artificiale .
Definește un test pe care sistemul informatic trebuie să îl treacă, și anume răspunsurile oferite de către
acesta la întrebările adresate de un operator (testerul) să nu poa tă fi diferențiată de către răspunsurile
oferite de un om (etalonul).
• 1957 -1978 – Orientarea spre demonstrație
Pe măsură ce sistemele informatice creșteau în număr, complexitate și cost, procesul de testare
a căpătat o importanță tot mai mare. Testarea pe scară largă a devenit necesară datorită creșterii
impactului economic pe care defe ctele nedetectate le puteau avea. De asemenea, persoanele implicate
în dezvoltarea de programe informatice au devenit mai conștiente de riscurile asociate cu defectele de
programe și au început să pună mai mult accent pe testarea și remedierea defectelor î nainte ca acestea
să afecteze produsul livrat. În această perioadă, termenii de testare și depanare se suprapuneau și se
refereau la eforturile făcute în scopul descoperirii, identificării și remedierii defectelor din sistemel e
informatice. Scopul procesul ui de testare era demonstrarea corectitudinii funcționării programului,
adică absența erorilor.
• 1979 -1982 – Orientarea spre defectare
Conceptele de depanare și testare devin mai riguros separate o dată cu publicarea de către Glenford J.
Myers a lucrării The Art of Software Testing, în 1979. Myers face distincția dintre depanare care este
o activitate care ține de dezvoltarea programului și testarea care este activitatea de rulare a unui
program cu scopul declarat de a descoperi erori. Deasemenea, el susține că în testarea bazată pe
demonstrație există pericolul ca operatorul să aleagă în mod inconștient acel set de parametrii care ar
asigura funcționarea corectă a sistemului, ceea ce creează pericolul ca multe defecte să treacă
neobservate. Myers propune în a bordarea sa și o serie de activități de analiză și control care împreună
cu procesul de testare să crească nivelul de calitate a sistemelor informatice.
• 1983 -1987 – Orientarea spre evaluare
În 1983, Biroul Național de Standarde din Statele Unite ale Americi i publică un set de practici
adresate activităților de verificare, validare și testare a programelor de calculator. Această metodologie,
adresată în mod specific instituțiilor americane federale, cuprinde metode de analiză, evaluare și testare
care să fie aplicate de -a lungul ciclului de viață al aplicației. Ghidul de bune practici sugerează alegerea

13
unor diverse metode de verificare și validare, în funcție de caracteristicile fiecărei proiect în scopul
creșterii calității generale a produsului. În anii 70 nivelul de profesionalism al persoanelor implicate în
activitatea de testare a crescut simțitor. Apar posturile dedicate de tester, manager de teste sau analist
de teste. Apar de asemenea organizații profesionale ale celor care activează în domeniul testăr ii
software, precum și publicații specializate, cărți și articole de specialitate. Mai important, instituțiile
americane ANSI și IEEE încep elaborarea unor standarde care să formalizeze procesul de testare, efort
concretizat în standarde precum ANSI IEEE S TD 829, în 1983, care stabilea anumite formate care să
fie utilizate pentru crearea documentației de testare.
• 1988 -în prezent – Orientarea spre prevenire
Standardele precedente sunt dezvoltate și îmbunătățite începând cu 1987 când IEEE publică o
metodologi e comprehensivă care se aplică în toate fazele ciclului de viață a programului. Testarea
trebuie făcută în toate fazele de lucru, în paralel cu programarea și are următoarele activități principale:
planificare, analiză, proiectare, implementare, execuției și întreținere. Respectarea acestei metodologii
duce la scăderea costurilor de dezvoltare și de întrținere a unui sistem prin scăderea numărului de
defecte care ajung nedetectate în produsul final.[4]
3.1.5 Metodologii moderne
Metodologiile moderne, precum Agile, Scrum, eXtreme Programming și altele pun un accent
deosebit pe procesul de testare pe care îl integrează în profunzime cu celelalte activități care țin de
dezvoltarea programeleor informatice: planificare, proiectare, programare, eva luare și control.
3.2 Importanța testării
3.2.1 De ce este necesară testarea software?
Fiecare dintre noi greșește, peste unele greșeli se poate trece peste altele nu, dar peste greșelile
dintr -un produs soft nu se poate trece cu vederea pentru că asta inseam nă inainte de toate imaginea
firmei care dezvolt ă produsul, pierderea clienților, costuri mari și alte consecințe nedorite. Toate astea
pot fi evitate testând produsul inca din primele faze ale procesului de dezvoltare.
Înainte de a enumera motivele pentru care e necesar să testezi, o să scriu ce este un bug – este
un comportament nedorit al produsului software care afecteaz ă funcționalitățile aplicației, interfața
grafică sau workflow -ul.
Când e momentul să incepi să testezi?
Testarea incepe odată cu scrierea primelor linii de cod și durează pe parcursul intregului proces
de dezvoltare a produsului.

Motivele pentru care este necesară testarea software:
▪ Testarea software este cu adevărat necesară pentru a identifica erorile comise in timpul
develop ment -ului
▪ Este necesar pentru a asigura că sunt indeplinite cerințele clientului
▪ Pentru a asigura dezvoltarea unui produs performant, actual și ușor de utilizat
▪ Testarea descoperă potențialele probleme pe care le poate avea un user când utilizează
aplicați a, ce funcționalități sunt confuze sau care sunt riscurile ce ar putea afecta produsul
livrat.
▪ Ceva ce funcționează perfect pentru un user, poate sa nu funcționeze pentru 10 sau 100 [5]

14
3.2.2 Obiectivele testării
În momentul în care un produs, un soft se testează se urmăresc câteva obiective clar definite, precum :
• Găsirea de erori
• Prevenirea defectelor
• Reducerea impactului defectelor apărute la client, pentru a nu afecta costuril e și
profiturile
• Creșterea fiabilității sistemului
• Câștigarea încrederii cu privire la nivelul de calitate
• Asigurarea că produsul este conform cu cererile clientului

În etapa de testare, care pe baza celor przentate mai sus se poate ajunge la concluzia că testarea
unui produs nu se termină niciodată. Astfel, în timp a apărut întrebarea “Cât timp testăm? ” sau “ Când
ne oprim din testare? ”.
Procesul de testare se încheie atunci când :
• S-a acoperit ceea ce s -a stabi lit
• Rata de găsire a defectelor a scăzut sub o rată stabilită
• Echipele implicate în proiect cad de acord că produsul poate fi livrat
• Managementul decide ca produsul să fie livrat

Întotdeauna când se vorbește de testare, se vorbește, în același timp, de anumite riscuri și
constrângeri, cum ar fi banii, timpul, etc.
Etapa de testare cuprinde trei componente care formează un triunghi, prezentat în figura de mai
jos, fiecare v ârf al acestuia conținând o componentă d e o foarte mare importanță raportată la vremurile
în care trăim .

Figura 2. Raport Calitate, Bani, Timp
Astfel, pe baza acestui triunghi, se poate prezenta logica testării, și anume : în funcție de bugetul
prezent și de timpul alocat pentru etapa de testare, se încearcă să se realizeze un produs la o calitate
cât mai bună.[6]

15
4. Fundamentarea teoretică

4.1 Definiția testării software
“Testarea e procesul prin care se execută un program cu intenția de a găsi erori” (Mayers)
Testarea software reprezint ă o investigație empirică realizată cu scopul de a oferi părților
interesate informații referitoare la calitatea produsului sau serviciului supus testării, luând în
considerație contextul operațional în care acesta din urma va fi folosit. Testarea software pune la
dispoziție o viziune obiectivă și independentă asupra produsului în dezvoltare, oferind astfel
businessului posibilitatea de a înțelege și evalua riscurile asociate cu implementarea produsului soft.
Tehnicile de testare includ, dar nu sunt limitat e la, procesul de execuție a programului sau aplicației
în scopul identificării defectelor/erorilor de software. Testarea software mai poate fi definită ca un
proces de validare și verificare a faptului că un program/aplicație/produs software corespunde
business cerințelor și cerințelor tehnice care au ghidat proiectarea și implementarea lui și rulează, se
comportă corespunzător așteptărilor.
4.2 Necesitatea testării. Cauzele și costurile erorilor
Putem defini prin următoarele necesitatea efectuării întreg ului process de testare:
• satisfacerea cerințelor clientului este cheia reușitei oricărei afaceri
• obținerea încrederii clientului prin oferirea unui soft bun, de calitate
• calitatea softului este indicată doar prin testarea acestuia
Majoritatea dintre erori reprezintă deficiențele din specificații (≈ 60%). O pondere ridicată
reprezintă și erorile de proiectare (≈ 30%). Erorile de programare reprezintă cea mai mica pondere
(uneori sub 15%).
Principala sursă a apariției erorilor este lipsa comunicării înt re membrii echipei care participă
la dezvoltarea produsului software.
Erorile depistate și fixate în faza de descriere a specificațiilor nu costă practic nimic. Erorile
depistate după livrarea produsului mărește costul acestora de la mii la milioane de do lari/euro.
(Figura 3)

Figura 3. Erori “ieftine” vs Erori costisitoare

16
4.3 Metode de testare
4.3.1 Testarea funcțională
Testarea funcțională – se referă la cerințele funcționale ale aplicației și cuprinde faptul c ât de
bine sistemul execută funcțiile sale. Acesta include comenzi de utilizare, manipulare de date, căutări
și procese de afaceri, integrări.
4.3.2 Testarea non -funcțională
Testarea non -funcțională – testarea aplicației față de cerințele non -funcționale și este conceput
pentru a evalua pregătirea unui sistem în funcție de mai multe criterii care nu sunt acoperite prin teste
funcționale.
4.4 Tehnici de testare
4.4.1 Testarea Black Box
Testarea Black box este o tehnică de testare software care se bazează în
întregime pe cerințele software și specificațiile acesteia.
În Testarea Black box ne concentrăm doar asupra intrărilor și ieșirilor ale sistemului și NU suntem
interesați de structura internă a programului software (Figura 4) Din acest motiv mai este denumit
testare de comportament. Această metodă de testare a software -lui nu impune ca testerul să cunoască
structura internă/proiectarea/implementarea elementului testat.

Figura 4. Structura Black Box testing
Această metodă înce arcă să găsească erori în următoarele categorii:
-funcții incorecte sau chiar care lipsesc
-erori de interfațare
-erori în structurile de date sau în accesarea bazei de date externe
-erori de comportament sau de performanță
-erori de inițializare și termin are

17
Un mic exemplu pentru această tehnică: Un tester fără cunoașterea structurii interne ale unui
site web, testează pagina web utilizând un browser, furnizează intrări (click -uri, apăsări de taste) și
verifică rezultatele în raport cu rezultatul așteptat.
Nivelurile la care se aplică această metodă:
– Testarea de integrare (Integration testing)
– Testerea sistemului (System testing)
– Testarea de acceptare (Acceptance testing)
Tehnici care pot fi utilizate în proiectarea testelor Black box:

a) Echivalarea partiționării : Este o tehnică de testare a software -ului care implică împărțirea
intrărilor în partiții valide și nevalide și selectarea valorilor reprezentative din fiecare
partiție ca date de testare.
b) Analiza valorii lim ită: Este o tehnică de testare a software -ului care implică determinarea
limitelor pentru valorile de intrare și selectarea valorilor care sunt la limitele și doar în
interiorul / exteriorul limitelor ca date de testare
c) Cauza efectelor grafice : este o tehn ică de testare a software -ului care implică identificarea
cazurilor (condițiilor de intrare) și a efectelor (condiții de ieșire), producerea unui grafic de
cauzalitate și generarea de cazuri de testare corespunzătoare.
Avantajele testării Black Box:
În pri mul rând testele se fac din punct de vedere al utilizatorului și vor ajuta la expunerea
discrepanțelor din specificații. În al doilea rând testerul nu trebuie să știe limbile de programare sau
modul în care software -ul a fost implementat. În continuare, testele pot fi efectuate de către un grup
independent de dezvoltatori, permițând o perspectivă obiectivă. Nu în ultimul rând cazurile de test pot
fi proiectate de îndată ce specificațiile sunt complete.
Dezavantajele testării Black Box:
Un mare dezavantaj reprezintă faptul că numai un număr mic de intrări posibile pot fi testate
și multe căi de program vor fi lăsate netestate. Fără specificații clare, situație întâlnite în multe proiecte,
cazurile de test vor fi dificil de proiectate. Un alt mar e dezavantaj este faptul că testele pot fi redundante
dacă proiectantul/dezvoltatorul de software a executat deja un test .[7]
4.4.2 Testarea White Box
Testarea White Box (cutia transparentă sau cutia deschisă) – tehnica de creare a cazurilor de test
asupra codului programului pentru a detecta orice scenariu cu potențial de eșec.
Testarea White Box (denumit și Clear Box Testing, Open Box Testing, Glass Box Testing,
Transparent Box Testing, Code -Based Testing or Structural Testing) este o metodă de testare a
software -ului în care structura internă / proiectarea / implementarea elementului testat este cunoscută
de tester (Figura 5). Testerul alege intrările pentru a exercita căile prin cod și determină ieșirile
corespunzătoare. Cunoștințele de programare și cunoștințele de implementare sunt esențiale în acest
mod de testare.

18

Figura 5. Structura White Box testing
Un mic exemplu pentru aceast ă tehnică: un tester, de obicei, studiază codul de implementare al
unui anumit câmp de pe o pagină web, determină toate intrările legale (valide și nevalide) și verifică
ieșirile în raport cu rezultatele așteptate, ceea ce este determinat de studierea codului de implementare.
White Box Testing este ca munca unui mecanic care examinează motorul pentru a vedea de ce mașina
nu se mișcă.
Nivelurile la care se aplică această metodă:
– Unit testing: pentru testarea căilor dintr -o unitate.
– Integration testing: pentru testarea căilor între unități.
– System testing: pentru testarea căilor între subsisteme.
Dintre nivelurile enumerate mai sus se aplică mai mult la Unit testing.
Avantajele testării White Box: testarea poate fi începută înainte de finalizare. Nu este necesar
să așteptăm ca GUI să fie disponibil (GUI – Graphical User Interface). Testarea este mai amănunțită,
cu posibilitatea de a acoperi majoritatea traseelor.
Dezavantajele testării White Box: un mare dezavant aj reprezintă faptul că testele sunt foarte
complexe, necesitatea resurselor umane foarte bine pregătite și calificate, cu cunoștințe aprofundate în
programare și implementare de teste. Un alt mare dezavantaj este datorită faptului că această metodă
de tes tare este strâns legată de aplicația testată și din această cauză există posibilitatea de a nu avea
disponibil imediat toate instrumentele pentru a răspunde la orice tip de implementare. [8]
4.5 Rolul testerului
Testerul este responsabil pentru planificare a detaliilor, proiectarea, realizarea și documentarea
testelor. Se disting diferite nivele de testare pentru a acoperi diferitele aspecte ale software -lui.
Planificarea generală a testelor în cadrul unui proiect este documentată în așa numitul Software Mas ter
Test Plan scris de managerul de testare software (Software Test Manager).
Aptitudini tehnici necesare: cunoașterea metodelor, tehnicilor și instrumentelor și a proceselor
de testare, cunoștințe și experiență privind procesul de verificare și validare a produselor. Alte
aptitudini: planificare și organizare, capabilitate de a iniția, ințelegere și interpretare a așteptărilor

19
clienților sau a subordonaților, capabilitate de a analiza probleme tehnice, comunicare, cunoaștere de
limbi străine (Engleză, Germ ană).
4.6 Testarea Modulelor (Module Testing)
La capitolul 4.4 unde s -au analizat tehnicile de testare, s -a duscutat și de nivelele de testare, așa
că în urmotarele se vor analiza aceste nivele în parte.
Procesul de testare a moduleleor constă în următoarele activități de testare și documente:
(Figura 6)

Figura 6. Activități de testare și documente în testarea modulelor
Tabelul 1 cuprinde o sinteză despre obiectivele Module Testing -lui și acțiunile necesare:
Obiectivele Module Testing -lui Acțiuni
• Funcționalitatea descrisă
• Comportamentul determinist și
reproductibil
• Robustitate față de valorile de
intrare neașteptate • Definirea ca zurilor de test din
specificațiile de testare a modulelor
• Definirea inițializării
• Configurarea corectă
• Integrarea ușoară in sistem • Testarea in sistemul standard sau țintă
• Absența efectelor secundare • Nu este posibilă verificarea
sistematică, se urmărește în timpul
testelor
Tabelul 1
Aceste obiective trebuie să fie adaptate pentru fiecare modul și trebuie să fie descrise în Module
Test Specification. În orice caz, trebuie să se asigure acoperirea completă a testelor cu privire la
funcționalitatea completă, pe baza cerințelor de specificații.
Obiectivul testării modulelor este de a găsi erori prin executarea cazurilor de test și compararea
comportamentului modului (sau subsistemului) testat cu rezultatele așteptate. Analiza datelor de
testare stat istice urmărite,precum numărul de erori constatate pe un test sau timpul necesar pentru
fiecare test, poate îmbunătăți procesul de testare.

20
Este o recomandare pentru a avea persoane diferite pentru rolul dezvoltatorului și rolul module
software testerulu i, folosind "principiul 4 ochi"(4 -eye-principle). Apoi, este posibil să se dezvolte
testele în paralel cu punerea în aplicare, iar execuția testului poate începe când codarea a fost terminată.
Este important să se testeze toate configurațiile relevante, de oarece un modul sau un subsistem este
adesea utilizat în diferite configurații în diverse sisteme software. Acest lucru conduce la teste specifice
proiectului.
Software Test Manager -ul selectează modulele pentru testare din ghidul de planificare a
modulelo r de testare (Planning of Module Tests Guidelines).
La testarea modulelor se pot folosi diferite tehnici de testare: testare funcțională, testare
structurală. Utilizarea tehnicilor de testare funcțională este foarte recomandată. Metodele de testare a
claselor de echivalență (Equivalence Class Test Methods) cu testul suplimentar al valorilor limită (Test
of Boundary Values) se folosește foarte des. Pentru domeniile de intrare mai mari se folosește metoda
arborelui de clasificare (Classification Tree Met hod) ca o prelungire a metodei de testare a clasei de
echicalență (Equivalence Class Test Method).
Tehnicile de testare structurale nu testează neapărat implementarea corectă a cerințelor
funcționale, ci doar structura codului, astfel încât acestea ar trebui folosite numai suplimentar față de
tehnicile de testare funcționale.
Pentru a testa acoperirea, se utilizează metoda analiza de acoperire a testelor(Test Coverage
Analysis).
Pentru o testare automată, se folosește metoda testarii automate (Automated Testing).
4.7 Testarea de integrare (Integration Testing)
Procesul de testare de integrare constă în următoarele activități și documente: (Figura 7)

Figura 7. Activități de testare și documente în testarea de integrare
Testul de integrare este nivelul d e testare după terminarea testelor pentru module. În timpul
integrării, software -ul va fi alcătuit pas cu pas în conformitate cu strategia de integrare descrisă în

21
planul de integrare a produsului ( Product Integration Plan ) și testată în conformitate cu sp ecificația de
testare a integrării ( Integration Test Specification. ). Înainte de integrarea unui modul software, testul
său pentru module trebuie finalizat. De asemenea, testul de integrare poate fi testat automat.
Scopul testului de integrare este de a ve rifica dacă software -ul integrat reflectă în mod
corespunzător proiectarea software -ului, ceea ce înseamnă în primul rând descoperirea erorilor în
interacțiunea și comunicarea dintre module.
Aceste teste acoperă următoarele:
• operații de interfațare
• managem entul resurselor: utilizarea stivei, utilizarea memoriei
• aspecte de rulare: timpul de procesare μController -lui, timpii de răspuns, latențele
• starea sistemului și tranzițiile
• moduri de operare
• comportamente de on/off
• verificări de stabilitate
• teste de stres
• teste de robustețe
• manipularea erorilor.
4.8 Software system testing
Testerul de software este responsabil pentru realizarea și documentarea testelor de sistem
software. Într -un întreg proces de testare sunt implicate mai multe persoane, fiecare cu
responsabilitățile lui. Acest proces de testare constă în următoarele activi tăți și documente: (Figura 8)

Figura 8. Activități de testare și documente în testarea de software system

22
4.8.1 Roluri și responsabilități
a) Software System Test Manager Software System Test Manager: este responsabil de
următoarele: crează documentul SW System Test Plan care include proiectarea testelor de sistem
software în domeniul testului calitativ/funcțional, coordonează diferitele faze de testare, distribuie
rapoartele de testare SW Test Managerului, SW Project Managerului și Project Managerului, s e asigură
de disponibilitatea sample -lor la diferite faze de test, pregătește mediul de testare, coordonează
activitatea de testare, examinează condițiile de testare: partea de hardware și de tool să fie suficient,
clarifică toate neclaritățile tehnice apă rute între echipa de testare și dezvoltatori.
b) Echipa de testare (Test Team): analizează cerințele, creează testele, dacă este cazul
actualizează testele conform noilor cerințe apărute. Dacă ceva este neclar în ceea ce privește cerințele
este recomandat cunsultarea FR -lui (Function Responsible) pentru clarificări. Revizuiește documentul
de testare dacă este cazul și nu în ultimul rând execută testele. Creează raportul final după executarea
testelor. Tot procesul de testare este împărțită pe funcționalităț i pentru a avea o eficiență cât mai mare
in testare.
c) 4 Software Project Manager (SWPM): Atribuții ale SWPM -lui: împreună cu System Test
Managerul și SW Test Managerul planifică testele necesare și scopul testării în toată activitatea de
testare, distri buie din timp programul, etapele și planul proiectului (cu cel puțin o lună înainte de
începerea testării), furnizeză programul (planificarea) de testare, clarifică toate problemele deschise
între echipele de testare și dezvoltare, se asigură că toate inst rumentele și documentațiile sunt
disponibile înainte de lansarea primei faze de test. [9]
4.9 Testarea manuală VS Testarea automată
Testarea software -ului poate fi făcută atât cu metoda de testării automate, cât și manual, dar
depinde în totalitate de cerința proiectului, de bugetul asociat proiectului și de metoda de testare care
va fi mai eficientă pentru proiect. În următoarele se va face o comparație intre testarea manuală și
testarea automată, punând mai mult accent pe testarea autom ată, tinzând spre aplicațiile pe testare
automată în domeniul automotive.[10]
4.9.1 Ce este testarea manuală?

Testarea manuală este testarea software -ului, unde testele sunt executate manual de către un
analist QA. Se efectuează cu scopul de a descoperi bug-uri (erori) în software -ul în curs de dezvoltare.
În testarea manuală, testerul verifică toate caracteristicile esențiale ale aplicației sau ale
software -ului dat. În acest process se execută cazurile de testare și generează rapoartele de testare fără
ajutorul unor instrumente de testare automate a software -ului. Este o metodă clasică a tuturor tipurilor
de testare și ajută la găsirea de erori în sistemele software. În general, acesta este realizat de un tester
experimentat pentru a îndepli ni procesele de testare a software -ului.
Există multe tipuri de testare manuală care sunt efectuate manual și automat. Acestea sunt
următoarele:
• Black Box Testing – Este o metodă de testare pentru a testa funcționalitățile și cerințele
sistemului. Nu testează partea internă a sistemului

23
• White Box Testing – Este o metodă de testare bazată pe informații despre logica internă a
codului unei aplicații și, de asemenea, cunoscută sub numele de Testarea cutiei de sticlă.
Funcționează pe codul d e lucru intern al sistemului. Testele se bazează pe acoperirea cu
declarații de cod, ramuri, căi, condiții.
• Integration Testing – Metoda integrată de testare a modulelor pentru a verifica funcționalitatea
comună după integrare. Modulele sunt în mod tipic m odule de cod, aplicații individuale,
aplicații client și server într -o rețea etc. Acest tip de testare se aplică în mod special sistemelor
client / server și sistemelor distribuite.
• System testing – Este o tehnică de testare a întregului sistem.
• Unit testi ng – Metoda de testare pentru a testa componenta specifică a software -ului sau a
modulului. Este făcut special de către programatori și nu de către testeri, pentru că are nevoie
de cunoștințe aprofundate despre designul intern de programare și cod.
• Accepta nce testing – Acest tip de testare verifică dacă sistemul îndeplinește cerințele specificate
de client sau nu. Utilizatorul sau un client face acest test pentru a decide dacă se acceptă
aplicația sau nu.
4.9.2 Ce este testarea automata?
În testarea automa tă a software -ului, testerii scriu cod / scripturi de testare pentru a
automatiza execuția testului. Testerii utilizează instrumente de automatizare adecvate pentru a dezvolta
scripturile de testare și pentru a valida software -ul. Scopul este de a finaliza execuția testului într -o
perioadă mai mică de timp .
Testarea automată se bazează în întregime pe testul pre -scenarizat care rulează automat
pentru a compara rezultatul real cu rezultatele așteptate. Acest lucru ajută testerul să determine dacă o
aplicați e are sau nu o performanță conform așteptărilor.
Testarea automată permite să se efectueze un test repetitiv de sarcină și de regresie fără
intervenția manuală a testerului. Chiar dacă toate procesele sunt efectuate automat, automatizarea
necesită un efort manual pentru a crea scenarii de testare inițiale.
4.9.3 Diferențe între testarea manuală și cea automata

Figura 9. Testare manuală vs Testare automată
În următoarele se realizează o comparație între cele 2 metode de testare folosind un tabel, pe
baza unor parametrii. Vezi Tabel 2.[11]

24
Testarea automată Testarea manuală
Definiție Testarea automată utilizează
instrumente de automatizare pentru
a executa cazuri de testare.
În testarea manuală, cazurile de
testare sunt executate de un
tester uman și de software.
Timpul de
procesare Testarea automată este semnificativ
mai rapidă decât o abordare
manual. Testarea manuală necesită mult
timp și un numar mare de
oameni.
Testarea
experimentală Automatizarea nu permite testarea
aleato rie Testarea experimentală este
posibilă în testarea manuală
Investiția
inițială Investiția inițială în testarea
automată este mai mare. Deși ROI
este mai bună pe termen lung Investiția inițială în testarea
manuală este relativ mai mică.
Rentabilitatea in vestiției este
mai mică comparativ cu testarea
automatizării pe termen lung.
Fiabilitate Testarea automată este o metodă
sigură, deoarece este realizată prin
instrumente și scripturi.
Testarea manuală nu este la fel
de precisă din cauza posibilității
erorilor umane
Schimbarea
interfeței (UI) Pentru cea mai mică modificare în
interfața de utilizare, scripturile
automate de testare trebuie
modificate pentru o funcționare
conform așteptărilor.
Modificările mici cum ar fi: un
ID, o clasă, u n buton, nu ar
trebui să împiedice un tester în
executarea testelor.
Investiție Investiția este necesară pentru
instrumentele de testare, precum și
pentru inginerii de automatizare.
Sunt necesare investiții pentru
resursele umane.

Eficiențe cost Nu este rentabil pentru teste de
regresie mai ales cu volum redus. Nu este rentabil pentru teste de
regresie mai ales cu volum mare.
Vizibilitatea
raportului de
testare Cu ajutorul testelor automatizate,
toate părțile interesate se pot
conecta la sistemul de automatizare
și pot verifica rezultatele testării
Testele manuale sunt de obicei
înregistrate într -un Excel sau
Word și rezultatele testelor nu
sunt ușor de accesate.
Observație
umană Testarea manuală nu implică
considerație umană. Deci, nu poate
oferi niciodată asigurări de utilizare
prietenoasă și de experiență
pozitivă a clienților. Metoda de testare 24annual
permite observația umană, care
poate fi utilă pentru a oferi un
sistem ușor de utilizat
Testarea
performanțelor Testele de performanță, cum ar fi
testarea încărcării, testarea stresată,
testarea Spike etc. există
obligatoriu un tool de testare.
Testarea performanței nu este
fezabilă manual
Execuția
paralelă Acesta este un test care poate fi
efectuat în paralel. Testul manua l poate fi executat
în paralel, dar va trebui să

25
mărească resursele umane, ceea
ce este costisitor.
Testarea
loturilor Putem grupa mai multe scripturi de
testare pentru execuția pe timp de
noapte. Testele manual nu pot fi grupate.
Cunoștințe de
programare Cunoștințele de programare sunt o
necesitate în testarea automatizării. Nu este nevoie de cunoștințe
programare în testarea manuală.

Set up -ul Testare automata nu necesită o
configurare complexă. Necesitățile în testarea manuală
au o configurare mai simplă
pentru execuția testului
Angajement Realizat de instrumente. Este exact
și nu ne plictisește niciodată. Testul executat manual este
repetitive și uneori plictisitor și
predispus la erori.
Abordare
ideală Testarea automatizării este utilă
atunci când se execută frecvent
același set de cazuri de testare Testarea manuală se dovedește
utilă atunci când testul trebuie să
funcționeze doar o dată sau de
două ori.
Construcția
verificării
testării Verificarea testelor auto mate este
utilă în construcția verificării
testării. (Build Verification Testing
(BVT)) Executarea c onstrucția
verificării testării (BVT) este
foarte dificilă și consumatoare
de timp în timpul testelor
manuale.
Termenele
limită
(Deadline) Testele automat e au riscuri zero de
lipsă a unui test pre -decis. Testarea manuală are un risc mai
mare de a pierde termenul limită
de testare stabilit în prealabil.
Cadru Testarea automatizării utilizează
cadre ca Data Drive, Keyword,
Hybrid pentru a accelera procesul
de automatizare. Testarea manuală nu utilizează
cadre, dar poate utiliza linii
directoare, liste de verificare,
procese stricte pentru a schița
anumite cazuri de testare
Documentație Testele automate acționează ca un
document care oferă valoare de
instruire, în special pentru cazurile
automate de testare a unităților. Un
dezvoltator nou poate analiza
cazuri de testare a unității și poate
înțelege rapid baza de cod. Cazurile de testare manuală nu
oferă valoare de instruire

Testarea
designului
Unitatea automată de testare
impune / conduce testele de
dezvoltare în proiectare. Analizele manuale ale unităților
nu conduc la proiectarea în
procesul de codificare
Cănd se
utilizează? Testarea automată este potrivită
pentru testarea regresivă, testarea
performanțelor, testarea încărcării
sau cazuri de testare funcționale
foarte repetabilă. Testarea manuală este potrivită
pentru explorarea, utilizarea și
testarea Adhoc. De asemenea, ar
trebui să fie utilizat în cazul în
care automatizarea se schimbă
frecvent.

26
Tabel 2
4.9.4 Avantaje Testarea Manuală

a) Se obține feedback vizual. Scripturile nu pot oferi opinii și informații despre modul în care
interfața ( UI-User Interface) arată și se simte ca o persoană.
b) Elementul uman – se obține exact tipul de feedback pe care o persoană poate să aibă și asta
poate fi de neprețuit. A fi capabil de a prezice ceea ce vor sau nu vor clienții – sunt lucruri pe
care un comp uter nu le poate oferi ca feedback în avans.
c) Mai puțin costisitor pe termen scurt – dacă se testează o singură aplicație simplă o singură dată
și nu se așteaptă la multe actualizări, testarea manuală nu necesită investiții instrumente sau
software scumpe.
d) Testare flexibilă, “în timpul zborului” (On -The-Fly testing) – Testarea necesită scrierea,
programarea și examinarea cazurilor de testare pentru software -ul de testat. Dar, dacă într –
adevăr trebuie doar să test ăm o mică schimbare, putem să o testăm manual c hiar atunci.
4.9.5 Dezavantaje Testarea Manuală
a) Mai puțin amănunțit decât testarea automată – Întotdeauna trebuie să ținem cont de eroarea
umană. Când un script rulează testul, este mai puțin probabil să se sare sau să piardă lucrurile
sau anumite informaț ii.
b) Oboseala în testare: Într-un proiect mai amplu este necesar ca să se implice și o echipă de
testare. Dace ne -am pune în locul developerilor nu ne -ar plăcea ca altcineva să ni -l testeze
munca noastră, pentru că uneori un tester poate fi mai bun cunascător al aplicației ca cel care
scrie codul. De multe ori din cauza sarcinii repetitive testerii se obosesc, nu mai sunt la fel
atenți fiind predispuși să greșească și să scape erori.
c) Nu sunt reutibilizabile – Dacă se anticipează o mulțime de modifică ri și actualizări ale aplicației
în viitor, va trebui să încercăm manual din nou, pentru a ne asigura că nu au apărut modificări
noi.
4.9.6 Avantaje Testarea Automată
a) Se găsesc mai multe erori decât manual – Scripturile pot fi mult mai amănunțite, captura rea
unor bug -uri pe care oamenii le -ar putea pierde – fie datorită volumului, fie monotoniei
sarcinii.
b) Se obține viteză și eficiența datorită calculatoarelor – Scripturile sunt mai rapide decât
oamenii, deci se poate face mai multe în mai puțin timp.
c) Teste sunt reutilizabile pentru coduri care se actualizează frecvent – Dacă se face în mod
constant actualizări, nu trebuie rescrise scripturile de test de fiecare dată, se pot reutiliza în
testele de regresie.
d) Oferă echipei o pauză – Există șanse mai mari ca echipa de dezvoltare să se obosească și să
fie obosită dacă testează manual o aplicație după ce o codifică. Testul de automatizare le va
oferi o șansă să se concentreze mai mult pe imaginea de ansamblu a proiectului.

27
e) O mai bună vizibilitate în performa nța aplicațiilor. – Cu testele automatizate este mai ușor
pentru întreaga echipă interpretarea rezultatelor față de o persoană care interpretează singur
testele sale manuale.
4.9.7. Dezavantaje Testarea Automată
a) Lipseste elementul uman – cum s -a mai menț ionat și mai sus elemental uman prin testare
manuală acumulează cunoștințe teimenice despre proiect.
b) Mai puțin feedback despre interfață – Fără elementul uman, de asemenea, nu se obține o
perspectivă asupra elementelor vizuale ale interfeței UI, cum ar fi opțiunile de culoare, dimensiunea
fontului, contrastul sau dimensiunile butoanelor .
c) Poate fi scump – instrumentele (și chiar timpul inițial) pentru a executa testele automat pot fi
scumpe, dar factor de reutilizare și timpul de economisire.
4.9.8 Concluzii
• Testarea manuală este testarea software -ului, unde testele sunt executate manual de către un
analist QA.
• În testarea automată a software -ului, testerele scriu coduri / scripturi de testare pentru a
automatiza execuția testului
• Testarea manuală ajută să obținem un feedback vizual rapid și precis
• Testarea automată ajută să găsim mai multe bug -uri comparativ cu un tester uman.
• Testarea manuală este o metodă de testare mai puțin fiabilă, deoarece este efectuată de un
om. Prin urmare , este întotdeauna predispus la greșeli și erori.
• Instrumentele pentru rularea testelor de automatizare pot fi costisitoare, ceea ce poate crește
costul proiectului de testare.
• Testarea manuală necesită mult timp și necesită un număr mare de resurse umane.
• Testarea automată este semnificativ mai rapidă decât o abordare manuală.[12]
4.10 Testarea în Automotive Embedded Systems
Embedded System în domeniul automotive este un sistem foarte complicat, imens în care s -au
înregistrat progrese enorme în ultimele de cenii. Nu doar hardware -ul a fost îmbunătățit ci partea de
soft putem zice că a explodat, s -au implementat funcționalități care să fie benefice utilizatorului uman.
Acest soft ajută la controlul electronicii în mașină, o electronică care funcționează pa ba za unor date
citite de niște senzori montate în diferite părți al vehiculului.
Tot softul este executat de așa numitele ECU (Electronic Control Unit). Un ECU este un
dispozitiv electronic încorporat, care controlează diferite sisteme sau subsisteme electronice într -un
vehicul. Dispozitivul de comandă cu componentele sale electronice sunt amplasate pe hardware -ul care
conține un microcontroler și memorii. Software -ul de control stocat în acele memorii și prelucrat de
microcontroler, este un cod de programare la nivel inferior, care poate citi semnale de la senzori, să
evalueze semnalele și să reacționeze la un set de evenimente bazate pe semnalele recepționate în
actuatori. În consecință ECU -urile în vehicule funcționează ca niște calculatoa re digitale.
Câteva exemple de ECU -uri:

28
• Engine Control Module (ECM)
• Electronic Brake Control Module (EBCM)
• Vehicle Control Module (VCM)
• Body Control Module (BCM)
• Powertrain Control Module (PCM)
• Transmission ControlModule (TCM)
• Central Control Module (CCM)
• Central Timing Module (CTM)
• General Electronic Module (GEM)
În vehiculele moderne sunt distrubuite în diferite părți al utilajului peste 100 de ECU -uri.
Complexitatea și sofisticarea lor, a software -lui este de așteptat ca să crească în continuare în viitor.
4.11 ECU – Electronic Control Unit
În secțiunea anterioară s -a făcut o mică introducere despre ECU -uri. Cu toții folosim mașini în
viața de zi cu zi, și observăm în jurul nostru cum apar modele mai noi, mai atrăgătoare. Putem pune
întrebarea : Eu nu pot sa modific prin soft? Reprogramând ECU -rile? Răspunsul este: da, se poate.
Prin furnizarea unei descărcări de software pe toate ECU -urile se pot adăuga noi funcții, chiar
și după producție și costul corectării erorilor poate fi redus semnificativ. Descărcarea software -ului se
face printr -un modul software numit bootloader în ECU. Există două tipuri de bootloadere, bootloader
primar (PBL) și bootloader secundar (SBL).
Bootloader -ul principal este prezent permanent în memoriile non -volatile și este activat
lapornirea sau resetarea ECU -ului. Cu toate acestea, din motive de securitate nu are acces la ștergerea
sau programarea memoriei nevolatile și poate numai să scrie în memoria volatilă.
Bootloader -ul secundar este descărcat de bootloa der-ul principal în memoria volatilă de
fiecare dată când descărcarea software -ului este efectuată. SBL poate efectua toate operații care pot
fi efectuate de bootloader -ul primar și în plus poate șterge sau scrie memoria nevolatilă. Deci, este
folosit pent ru a efectuarea descărcării software -lui și după terminarea descărcării SBL este șters de la
memorie volatile
4.12 Rețele de comunicații în vehicule (Vehicle network)
Rețeaua de comunicații a vehiculelor trebuie să satisfacă cerințele de comunicare în timp
real. Atât diferitele cerințe de performanță în cadrul unui vehicul, cât și concurența între companiile
din industria automobilelor a condus la proiectare a unui număr mare de rețele de comunicații.
În următoarele vom analiza diferite r ețele de comunicații: CAN, Flexary, LIN and MOST,
care sunt utilizată intr -o mașina modern. Aceste rețele au fost dezvoltate de către companii care chiar
au fost nevoiți să folosească astfel de rețele. Inginerii de testare de la firma respectivă trebuie să aibă
o bună cunoaștere a modului în care mesajele traversează prin aceste rețele la diferite ECU -uri, un
lucru esențial pentru a testa funcționalitatea implementată în platforma auto.

29
4.12.1 Controller Area Network (CAN)

Controler Area Network (CAN) a fost dezvoltată de Bosch în 1980 si pe departe este cea mai
utilizată rețea de comunicare în acest domeniu. În 1994 a devenit un standard ISO. Succesul acestei
rețele se poate datora la mai mulți factori. CAN oferă o rețea ieftină, du rabilă, care permite
cumunicarea cu mai multe dsipozitive CAN în aceeași timp.

Un avantaj al acestui lucru este faptul că unitățile electronice de control (ECU) pot avea mai
degrabă o singură interfață CAN decât intrări analogice și digitale pe fiecare dispozitiv din sistemul.
Aceasta duce la o scădere globală a costurilor. Chiar dacă totalitatea a datelor care urmează să fie
transmise a crescut, CAN este încă standardul principal. Acest lucru se datorează în principal faptului
că numărul canalelor CAN poate fi mărit atunci când există mai multe date care trebuie transmise.

Pe CAN, datele sunt segmentate sub formă de cadre (frame -uri). Aceste cadre pot fi trimise
periodic sau aperiodic. Fiecare cadru CAN este etichetat cu un număr numit identificator, care
determină prioritatea cadrului în timpul transmiterii. Topologia rețelei CAN este dată de Figura 10.
Rețeaua CAN are o structură descentralizată și toate nodurile de rețea pot accesa BUS -ul în orice
moment.

Figura 10. Topologia rețel ei CAN

Pentru a susține această comunicare pe o magistrală multi -master fiecare nod are un transceiver
și un controler. CAN este un protocol de comunicare bazat pe evenimente. Pentru a sprijini
comportamentul în timp real și creșterea timpului de reacție la evenimente se folosesc 2 tehnici de
accesare a BUS -lui. Aceste tehnici de acces cu BUS -ul sunt CSMA / CA (Carrier Sense Multiple
Access/Collision Avoidance) și tehnica arbitrajului.
În tehnica CSMA / CA ori de câte ori un nod din rețeaua CAN dorește să transmită un mesaj
verifică mai întâi dacă orice alt nod transmite pe magistrală. Dacă există alt nod care comunică, atunci
se abține de la trimiterea mesajului pentru o perioadă de timp și apoi verifică din nou disponibilitatea
BUS -lui. În ciuda folosirii acestei tehnici, dacă există încă o coliziune, atunci schema de arbitraj este
folosită pentru a acorda prioritate mesajului trimis.
În baza schemei de arbitraj în cazul în care mai multe noduri transmit mesajul la același timp,
atunci nodul cu ce a mai mare prioritate va continua să trimită mesajul. Nodurile cu prioritate mai mică
opresc trimiterea mesajelor .

30
Principalul avantaj al CAN este că e o rețea “ușoară” și ieftină. De asemenea, toate dispozitivele
din rețea au un chip de controler CAN, ast fel încât să poată vedea toate mesajele transmise și să decidă
dacă să le filtreze sau nu.

4.12.2 FlexRay
CAN este un protocol dominant pentru rețeaua de vehicule, dar nu poate oferi în timp real
performanță, care este esențială în aplicațiile critice de siguranță, cum ar fi X -by-wire sistem și sistem
avansat de asistență pentru șoferi.
Pentru a rezolva această problemă, FlexRay a fost proiectat folosind un mecanism de acces
multiplu (TDMA) pentru sistemele critice de siguranță. FlexRay este o rețea de comunicații declanșată
în timp, adică activitățile sunt conduse pe măsură ce progresează timpul. FlexRay a fost dezvoltat de
către un consorțiu de companii majore. În prezent, multe companii de automobile folosesc ambele:
CAN și FlexRay împreună.
Rețeaua FlexRay are o topologie destul de flexibilă și poate fi folosită ca BUS, star sau multi –
star. În topologia star toate nodurile comunică printr -un nod central. BUS -urile și topologiile star pot
fi combinate pentru a forma topologia hibridă.
FlexRay are capacitatea de a lua locul mai multor magistrale CAN de mare viteză, reducând
complexitatea și costurile. FlexRay oferă suport pentru determinism, comunicare și lărgimea de bandă
mai mare comparativ cu CAN. Standardul FlexRay gestionează comuni carea mai multor noduri sau
ECU prin intermediul unui canal. Aceasta este realizat cu un ciclu de comunicare prestabilit care oferă
un spațiu predefinit pentru datele statice și dinamice. Ciclul de comunicare este prezentat în Figura
11.

Figura 11. Cicl ul de comunicare

Porțiunea albastră a cadrului prezentată în Figura 2. reprezintă segmente statice care sunt
utilizate pentru comunicarea deterministă. Segmentul static este împărțit în diferite intervale de timp.
De fiecare dată un slot este dedicat un ui anumit ECU. Fiecare ECU transmite mesaje într -un timp
particular într -un slot, numai într -un ciclu de comunicare. În caz că ratează intervalul de timp, așteaptă
până la intervalul de timp alocat în următoarea ciclu de comunicare. Aceasta ajută programul să
determine cât de vechi sunt datele transmise.

31
În rețelele de comunicații ale vehiculelor există o mare varietate de date care trebuie
transmise cum ar fi mesajele de mare viteză și mesajele cu viteză redusă. FlexRay oferă segmente
dinamice pentru a pr eveni încetinirea ciclului de comunicare prin mai multe sloturi statice.
Segmentul dinamic este de lungime fixă și poate fi trimisă doar o cantitate fixă de date. Segmentul
dinamic este împărțit în mini -sloturi care sunt pre -atribuite unui cadru de da te. Mini -sloturile au o
lungime de 1 microsecundă. Mesajele cu prioritate mai mare sunt transmise în mini -sloturile mai
aproape de începutul segmentului dinamic. Fereastra de simbol, așa cum este arătată cu galben în
figură, este utilizată pentru mentenanț a ciclurilor speciale. Este, de asemenea, utilizat pentru
semnalizarea pornirii rețelei. Timpul inactiv al rețelei în alb în figura este utilizat pentru a menține
sincronizarea între ceasurile nodurilor.
4.12.3 MOST and LIN

LIN sau rețeaua locală de inte rconectare ( Local Interconnect Network ) a fost dezvoltată
pentru a fi utilizată în aplicații care nu necesită o viteză mare de transfer de date și caracteristici robuste
ale rețelei CAN. Acest lucru reduce costurile inutile. Câteva exemple de utilizare a LIN: scaunul, ușa
și controlul oglinzilor.

Media Oriented Systems Transport sau MOST este un standard de comunicații folosit în
aplicatii auto. Este optimizat pentru aplicații multimedia și infotainment care necesită rate ridicate de
transfer de date. MOST a fost dezvoltat pentru a oferi un nivel redus, o interfață low -cost pentru
dispozitive simple, cum ar fi difuzoare și microfoane.
4.13 CANalyzer and CANoe
Instrumentele CANalyzer si CAN au fost dezvoltate pentru a satisface nevo ile esențiale al
protocolului de comunicare CAN, bazat pe module, combinând o serie de capabilități de măsurare cu
cele de simulare.
Atât CANalyzer, cât și CANoe pot interfața cu mai multe rețele CAN (sau cu alte mici
protocoale comune de rețea) și pot fur niza măsurători exacte în timp pentru toate transferurile de
comunicații, incluzând atât mesajele de comincare cât și mesajele de eroare în comunicare. Operațiile
de redare și de înregistrare sunt standard.
Ambele instrumente funcționează practic ca un os ciloscop cu mai multe canale, ca un analizor
logic multicanal sau ca o unitate de afișare alfanumerică personalizată – toate folosind o bază de date
integrată.
În plus, ambele instrumente sunt capabile să creeze orice tip de generare de mesaj, la fel ca un
generator de funcții programabile, cu un control complet al tuturor variabilelor (sau semnalelor),
datelor din rețea. După cum se poate vede și in Figura 12, ambele instrumente împart o parte importantă
a aceleiași interfețe de analiză a rețelei.
Deoarece de obicei un instrument întotdeauna este mai bun decât celalalt pentru majoritatea
aplicațiilor, trebuie să ințelegem diferențele cheie dintre CANalyzer și CANoe înainte de a începe un
proiect.
O diferență cheie – Nivelul de control al nodurilor

32
O diferență cheie între CANalyzer și CANoe este în nivelul de control al nodurilor. În esență, un singur
instrument CANalyzer poate acționa ca un singur membru al rețelei, dar CANoe nu are nicio limită în
ceea ce privește numărul de module pe care le poate î nlocui.
Așa cum se arată și în Figura 13, CANalyzer suportă controlul unui singur nod (un singur tester
sau un singur modul), în timp ce CANoe sprijină controlul unei colecții de noduri multiple (Orice
număr de simulări sau număr de testere).

Figura 12. Interfața de analiză al rețelelor

Figura 13. Deosebirea nivelelor de control al nodurilor între CANalyzer și CANoe
Tablourile grafice – o altă diferență majoră.
Cea de -a doua diferență destul de distinctivă între CANalyzer și CANoe reprezintă faptul că
Canoe suportă "panouri grafice" atât pentru intrări, cât și pentru ieșiri. Acest lucru permite
utilizatorului să construiască comportamentul "la nivel superior" pentru a simula intrările și ieșirile
efective. De exemplu, să presupunem că noul proiect ni se cere să construim un tester. În mod
tradițional, evem de a alege între două alternative :

33
• Construim un modul electronic personalizat – proiectăm singuri hardware -ul și
software -ul.
• Construim un sistem semi -personalizat bazat pe PC – alegem un anumit hardware
compatibil cu PC -ul și softul creăm singuri.
Cu toate acestea, este acum disponibilă o altă opțiune – putem construi întregul tester în CANoe
și scriem întreaga aplicație în CAPL.
CANoe ne permite să construim interfețele panoului de testare pentru a furniza intrări și ieșiri.
Putem adăuga software -ul CAPL necesar pentru a interconecta deviceurile noastre pentru o transmisie
corespunzătoare a mesajelor CAN pe care dorim ca testerul să le trimită. De asemenea, este ușor să
conectăm mesajele primite de la CAN să primească mesaje către dispozitivele grafice de pe panoul
frontal. În plus, contoarele în mișcare, luminile intermitente și grafica numerică a afișajului sunt ușor
de creat (se poate vedea Figura 14). [13]

Figura 14. Exemplu de grafică CANoe utilizat atât pentru intrarea, cât și pentru ieșirea
panoului frontal.

4.14 Limbajul de progrmare CAPL
Este un limbaj de programare pentru rețelele, modulele și sistemele distribuite CAN,
(Programarea aplicațiilor de comunicare -Communication Application Programming Language).
Limbajul CAPL, face posibilă programarea aplicației CANalyzer pentru aplicațiile specifice pentru
dezvoltatori care utilizează CAN protocol. CAPL poate fi, de asemenea, utilizat în instrumentul
CANoe pentru d ezvoltarea distribuită a produselor.
4.14.1 Mediul de programare CAPL
Chiar dacă CAPL poate fi considerat un limbaj de programare procedural, CAPL poate fi, de
asemenea, considerat ca un mediu de programare.

34
În acest mediu de programare un utilizator poat e crea, modifica și menține programe CAPL
care pot interfața cu o mare varietate de intrări, ieșiri și alte funcții. Evenimente start -stop, evenimente
de intrare în tastatură, abilitatea de a transmite și să primească mesaje CAN, interacțiunea cu portul
serial și portul paralel, utilizarea temporizatorilor și capacitatea de a interconectarea cu DLL specifice
clientului sunt câteva dintre opțiunile de interfață disponibile în cadrul programării în mediul CAPL.
Majoritatea programelor sunt dezvoltate folosind browserul CAPL, care oferă un proces de
dezvoltare ușor de folosit numit “editare -prin-compilare”. Chiar dacă este furnizat ca o componentă
integrată a CANalyzer sau CANoe, browser -ul CAPL programul de aplicații poate fi folosit separate.
(Figura 15- Interfețele CAPL).

Figura 15- Interfețele CAPL
4.14.2 CAPL răspunde la evenimente
În general, programele CAPL sunt concepute simplu pentru a detecta evenimentele și apoi
pentru a executa procedura asociată evenimentului.
De exemplu, ați putea face ca ieșire textul "Start Test" în fereastra Scrieți când facem clic pe
butonul de pornire al CANalyzer utilizând următorul program:
on start
{
Write (“Start test”);
}

Tipurile de evenimente care pot fi detectate în CAPL include:
• Apăsarea butonului pornire

35
• Butonul Stop
• Intrare de la tastatură
• Recepționarea mesajelor CAN
• Întreruperea unui Timer
• Utilizator prin intermediul unui panou graphic (disponibil doar în CANoe)
Pe baza acestei tehnici de "activitate cauzată de activitatea procedurală", programele CAPL sunt
construite și organizate ca atare colectarea procedurilor de eveniment.

Browserul CAPL este structurat convenabil în diferite grupări ale procedurilor de eveniment.
Aceste evenimente așa -numite grupurile de proceduri sau clasele de evenimente includ sistemul,
controlerul CAN, mesajul CAN, cronometrul, tastatura și eroarea CAN.[14]

36
5. Implementarea solutiei adoptate
Ca și o evidențiere practică a teoriilor menționate la capitolul 4 ,la Fundamentarea teoretică , s-
a ales o mică aplicație creat in C ANoe, care simulează și testează anumite funcționalități pe partea de
display (bord) a unui autovehicul. Se verifică atât partea de display cât si partea de semnale prin care
se transmit anumite valori.
Dacă se evaluează aplicația după cele menționate la capitolul anterior, se poate încadra în
următoarele:
– Black Box testing
– System Testing (Software System Testing)
– Teastare Manuală cât și Testarea Automată
– Rețeaua de comunicare în vehicule: CAN (Controller Area Network)
– Programul utilizat: CANoe
– Mediul de programare: Programare CAPL

În Fugura 16 se poate vedea interfața completă a aplicației cu cele 2 chenare: unul creat in
scopul controlului, iar celălalt pentru afișaul (display -ul).

Figura 16. Interfața completă a aplicației
După cum se poate vedea în figura de mai sus există 2 părți: o parte a controlului, iar o parte a
afișajului. Controlul este impărțit tot in două părți: blocul de control a luminilor și blocul de control al
motorului.
În blocul de control al luminilor putem controla următoarele lumini: luminile de staționare
(pozițiile), luminile de drum (faza scurtă și faza lungă), avariile și există și un buton de oprire a tuturor
luminilor.

37
În blocul de control a mo torului pentru a putea seta ceva există a condiție generală: acel ignition
sa fie pe ON. În viața reală acest buton este echivalentul contactului dintr -un autovehicul. Din acest
bloc se mai pot regla: viteza, rotația pe minut a motorului (în viața de zi cu zi se mai numește și turație)
și tem peratura motorului sau a lichidului de răcire.
Afișajul (display -ul) tot așa este împărțit in două: afișarea datelor primite de la funcționarea
motorului și afișarea venită de la blocul de lumini. În afișajul pentru m otor există o iconiță cu mașinuță.
Acea mașinuță dacă apare cu un text “running” în verde, inseamnă că motorul este pornit. Viteza,
rotația pe minut și temperatura lichidului de răcire sunt afișea te atăt mecanic (prin intermediul acelor)
cât și digital. I n colțul dreapta jos a indicatorului de temperatură a lichidului de răcire apare iconița de
avertizare a temperaturii prea ridicate , în caz în care temperatura trece de un anumit prag.
La afișarea luminilor există o mașinuță care în față are 2 faruri. Acele faruri vor fi aprinse in
caz in care avem aprinse luminile de poziție, faza scurtă sau faza lungă, și vor avea o apariție
intermitentă în caz în care avem pornite avariile. Sub acea mașinuță vom avea un indicator care ne v a
indica prin iconiț ele corespunz ătoare luminile ce avem apri nse momentan sau dacă sunt oprite. Un
comportament asemănător avem în cazul avariilor.
5.1 Crearea și editarea blocurilor
În domeniul ingineriei auto este întotdeauna util să putem vizualiza munca. CANoe oferă
ocazia de a lucra cu noduri de rețele simulate. Nodurile create în fereastra Simulation Setup care se
crează in CAPL este capabilă să reacționeze la evenimente externe, cum ar fi acționarea unui
comutator. CANoe oferă de asemenea opțiunea de a crea propriile interfețe definite de utilizator numite
panouri și integrarea acestora în program.
Panourile grafice sunt o caracteristică importantă și utilă a programului CANoe, deoarece
funcționează ca panouri de control în care utilizatorul poate schimba valorile va riabilelor în timpul
unei simulări sau a unei măsurători.
Ce este un Panou?
Un panou este o interfață grafică configurabilă de utilizator. Fiecare control care poate fi plasat
pe un panou este numit element. Aceste elemente – butoane, comutatoare, glisoare și așa mai departe
– pot fi plasate oriunde pe panou pentru a crea aspectul și simțul panourilor de comandă pentru
autovehicule.
Editorul de panouri. (Panel Editor)
Editorul de panouri este mediul utilizat pentru creareași aranjarea elementelor, pentru afișarea
și controlul variabilelor care trebuie modificate, și pentru atribuirea variabilelor (fie variabile de
mediu, fie semnale) tuturor elementelor de control și de afișare.
Se poate interacționa și modifica valorile acestor variabi le în timpul măsurării prin manipularea
elementelor de pe panouri. Modelele nodurilor de rețea reacționează la modificările valorilor
variabilelor și apoi execută acțiunile corespunzătoare (de exemplu, trimiterea unui mesaj)
Nu numai că utilizatorul poate modifica valorile variabilelor; dar programele CAPL pot fi, de
asemenea, folosite pentru a schimba valorile variabilelor asociate atunci când apar anumite

38
evenimente. Această schimbare de valoare poate fi apoi vizualizată pe panou folosind elemente de
afișare.

În primul rând se creează o confugurație nouă prin: File -> New -> Configuration. Urm ând
acești pași ar trebui să ajungem la o interfață ca în Figura 17.

Figura 17. Configurație nouă

În Simulation Setup putem observa că încă nu este nimic adăugat (niciun ECU), se pot vedea
conectorii albastru și rosu nelegați la nimic. Pentru a ad ăuga in nou nod, se procedează ca în Figura
18.

Figura 18. Inserare nod (ECU) nou
După nodul nou creat ar trebui sa avem pe ecram , în parte a de Simulation Setup următoarea
configurație (vezi Figura 19). Nodul se poate modifica: click dreapta p e nodul nou și se acceseaz ă
Configuration.

39

Figura 19. Configurație cu un nod nou
Aplicația mea conține în total 3 noduri (3 ECU -uri). Un ECU este responsabil de controlul
luminilor, celălalt este responsabil de partea de control a motorului, iar ultimul de partea de afișaj (de
bord) Figura 20. Un autovehicul modern din zilele noastre bineînțeles că are în componență mai multe
ECU -uri, mai ales modelele care sunt con striute urmând conceptul de autonomus driving (mașinile
care merg singure).

Figura 20. Nodurile proiectului
Din opțiunea Tools -> Panel Designer se creeaza blocurile. În cazul de față am două blocuri: car și
car_display: car reprezintă blocul de control iar car_display blocul de afișaj.
• Blocul car: (Figura 21)

40

Figura 21: Blocul Car
După cum se poate observa în figura de mai sus acest bloc este împărțit în două: Light Control
și Engine. Prin Light Control se reglează luminile: luminile de staționare – Position_Lights (pozițiile),
faza scurtă – Low Beam, faza lungă – High Beam, avariile – Hazard Light și o opțiune de a opri faruril e
– Stop Lights.
Înainte de a merge mai departe cu explicarea implementării ,trebuie remarcat cele 2 opțiuni ale
Panel Designer -lui, care de fapt reprezintă baza acestei metode. În toate blocurile menționate mai sus
noi adăugăm toate elementele: unul cu un ul. Figura 23 reprezintă prima mare opțiune, denumit
Toolbox, care de fapt este o listă cu toate elementele ce se pot adăuga. Figura 24 reprezintă a doua
mare opțiune care este denumit proprietăți (Properties). De aici pe fiecare element ad ăugat putem
personaliza dup ă placul nostru, fiecare element din lista Toolbox are propritățile sale.
După aceste clarificări putem continua explicarea implementării. Fiecare control este
reprezentat de un Check Box din list a Toolbox -lui. Caracteristica principală al acestui control este
faptul că are cele două stări: când este selectat (checked) avand valoarea logică „1” și când este
deselectat (unchecked) având valoarea logică „0” Figura 22.

Figura 22. Proprietatea principală a Check Boc -lui

41

Fig 23. Toolbox Fig 24. Proprietățile controlului Lichidului de
răcire

Prin Engine se controlează anum ite proprietăți ale motorului: viteza, rotația pe minut (turația),
temperatura lichidului de răcire și nu în ultim ul rând prin Ignition contactul. Toate caracteristicile nu
se pot aplica dacă nu avem contactul pus: Ignition este pe „1”. Viteza, rotația pe minut și temperatura
lichidului de răcire este reprezentat de un Track Bar din Toolbox. Un Track Bar are următoar ele
proporietăți (Figura 25):

42

Figura 25. Proprietățile unui Track Bar
Ignition este un Switch Indicator, care are următoarele proprietăți (Figura 26).

Figura 26. Proprietățile unui Switch Indicator
La proprietățile acestui element trebuie remarcate două caracteristici importante: Image – cu
acastă opțiune ii putem atașa o imagine și Switch Values – în funcție de această valoare este divizată
imaginea pe orizontală. Figura 27 reprezintă imaginea completă și cea ce apare după ce se adaugă și
se dau valori la switch values.

43

Figura 27. Switch values imagine
• Blocul car_display2: (Figura 28)

Figura 28. Blocul car_display

La fel ca blocul car, conține 2 părți mari: partea de afișaj a motorului și partea cu afișaj a
luminii. În momentul în c are din blocul control Ignition este setat pe “1”, iconița cu mașina se schimbă:
apare o altă iconiță tot cu mașina respective , doar ca apare in plus textul “Running” in verde. Vezi
Figura 29.

Figura 29. Ignition on, iconi ța running

44
Proprietățile de control ale motorului: viteza, rotația pe minut a motorului și temperatura
lichidului de racire fiind setate sunt și afișate. Afișarea acestor valori se face atât analogic: prin ceasuri
cu ace, cât și digital. La afișarea analogică din too lbox s -a folosit controlul Analog Gauge (Figura 30).

Figura 30. Controlul Analog Gauge

Bineînțeles că și acest control ale proprietățile lui. În figura 31 se pot vedea proprietățile
afișajului vitezei:

Fig. 31. Proprietățile afișajului vitezei

45
La fel se afișează și rotația pe minut a motorului (turația) și temperatur a lichidului de răcire.
Doar domeniile valorilor diferă de viteză. Pentru afișarea digitală a tuturor valorilor s -a folosit din
Toolbox câte un Input/Output Box.
La o temperatură mai ridicată a lichidului de răcire apare o iconiță de avertizare. Acesta s -a
inserat în colțul drep jos al afișajului (Figura 32)

Figura 32. Iconiță de avertizare a temperaturii înalte a lichidului de răcire

Acesta s -a înserat cu ajutorul unui Picture B ox din Toolbox, având următoarele caracteristici
(Figura 33)

Figura 33. Caracteristici Picture Box

Fiecare element din afișajul analogic: viteza, rotația pe minut a motorului și temperatura
lichidului de răcire are dedesubt o iconiță în gri. Această i coniță are rolul de a afișa și digital valoarea
setată prin acele ace. Din Toolbox s -a folosit element ul Input/Output Box, despre caracteristicile lui s –
a discutat mai anterior. De exemplu caracteristicile afișajului vitezei în digital sunt următoarele (Fi gura
34).

46

Figura 34. Caracteristicile afisajului digital al vitezei

5.2 Crearea bazei de date (Database)
Mesajele dintr -o rețea pot fi ușor organizate și modificate de o bază de date. Distribuția și
reutilizarea sunt două avantaje majore, deoarece specificațiile sunt conținute într -o bază de date ușor
de gestionat. Grupul de proiectare a sistemelor la multe companii utilizează platforma de baze de date
Vector cunoscută sub numele de CANdb pentru a dezvolta fișiere de baze de date. Aceste fi șiere de
baze de date sunt apoi disponibile la nivel corporativ, ceea ce sporește considerabil compatibilitatea și
funcționalitatea sistemelor CAN.
Pașii de bază pentru crearea bazei de date și asocierea acestuia cu CANoe sunt după cum
urmează:
1. Porniți programul CANdb ++ din CANoe
2. Definiți atributele (opțional)
3. Definiți tabelele de valori (opțional)
4. Definirea nodurilor (Nodes)

47
5. Definirea mesajelor (Messages)
6. Definirea semnalelor (Signals)
7. Stabilirea asociațiilor
8. Definirea variabil elor de mediu (Environment Variables)
9. Salvarea bazei de date cu un anumit nume de fișier
10. Asociați baza de date cu CANoe

CANdb ++ Editor arată toate obiectele de bază de date grupate în fereastra Overview, unde
sunt executate aproape toate operațiil e bazei de date. CANdb ++ Editor la aplicația mea arată ca în
Figura 35.

Figura 35. CANdb ++ Editor

În figura de mai sus după cum se poate vedea focusul este setat pe variabilele de mediu
(Environment Variables). Fiecare variablă este creat manual și e ste asociat căt re unui element din
panelurile create. Crearea acestor variabile este una foarte simplă, doar cu un click dreapta pe
Environment variables și cu op țiunea New apare o ferestră unde putem defini numele variabilei. După
ce s-au creat aceste var iabile, se pot assigna elementelor din ferestrele de control. Acest lucru se face
în felul următor: în Figura 36 se poate vedea practic cum s -a assignat varaibila corespunzatoare
elementului Ignition. În fereastra de editare în Panel Designer ne întoarcem la proprietățile fiecărei
element, și în list a ce apare există o propri etate numit ă Symbol, în dreptul căreia dacă se face click pe
cele trei puncte putem assigna semnalul corespunz ător definit în Environment Variables.

48

Figura 36. Assignarea variabilei elementului Ignition

5.3 Definirea nodurilor

Pentru a defini un nod, se folosesc de obicei acronime scurte pentru a înlocui numele. De
exemplu, TCM este acronimul utilizat frecvent pentru modulul de control al transmisiei (Transmission
Control Module). Acronimul utilizat depinde de utilizator.
Pentru a defini un nod în CANdb ++:
1. Faceți clic dreapta pe fereastra Overview în care se afișează nodurile de rețea
2. Se selectează New
În aplicația mea s -au definit 3 noduri: Car_Display, Car_Engine, Car_Lights. Aceste noduri
corespund de fapt ECU -rilor (Electronic Control Unit). Vezi Figura 37.

Figura 37. Nodurile aplicației

49
5.4 Definirea mesajelor
La definirea unui mesaj trebuie să fie cunoscuți trei parametri: identificatorul numer ic (se mai
numește si ID), dimensiunea identificatorului (11 biți sau 29 de biți) și codul lungimii datelor. Alte
proprietăți ale mesajelor sunt uneori ușor ignorate, dar esențiale pentru o bază de date: nodul de
transmisie și recepție a mesajelor, atribut ele mesajelor și semnalele. Asociațiile de semnal nu sunt de
obicei făcute în acest stadiu deoarece nu au fost create încă.
Pentru a defini un mesaj în CANdb ++:
1. Faceți clic dreapta pe fereastra Overview în care se afișează mesajele (Messages)
2. Se selectează adăugare (Add)
La definirea unui mesaj nou, apare următoarea ferestră (Figura 38):

Figura 38 Definirea unui mesaj nou

La căsuța Name se definește un nume symbolic, ID -ul este un identificator de mesaj, iar DLC
este lungimea mesajului. De obicei se folosește valoarea maximă, adică 8 care este echivalent cu
reprezentarea unei valor i transmise pe 8 bytes. Aceste sunt caracteristicile de definiție a semnalului.
Există și un parte de Signals, unde selectând New putem selecta semnalul dorit, valoarea căruia
va fi transmis pe semnal. Vezi Figura 39.

50

Figura 39. Adăugarea unui semnal la mesajul transmis
La un mesaj putem adăuga mai multe semnale. De exemplu unui mesaj al carui DLC este 8
putem adăuga 4 semnale, fi ecare să fie reprezentate de 2 bytes. La partea de Layout putem noi defin i
pe care b ytes să fie reprezentată. În Figura 40 se poate vedea Layoutul semnalului Msg_Speed din
aplicație:

Figura 40. Layoutul semnalului Msg_Speed

51
5.5 Definirea semnalelor
Un s emnal este de la 1 bit până la 64 de biți în dimensiune; prin urmare, un mesaj poate varia
de la date care nu conțin semnale (DLC = 0) sau până la 64 de semnale (câte un bit pentru DLC = 8).
Din păcate, majoritatea aplicațiilor permit numai maximum 32 de b iți pentru un semnal .
Când se definește un semnal, trebuie să îi dăm un nume simbolic, să definim dimensiunea
acest uia în număr de biți, să alegem fie formatul Intel sau Motorola, cât și tipul de valoare (tipul de
date). Proprietățile opționale includ un factor și o compensare pentru a converti valoarea primei
semnale într -o valoare de inginerie, valoarea sa maximă și minimă pentru afișare și un tab el de valori
pentru afișarea valorii semnalului numeric în formă simbolică . În Figura 41 se poate vedea definiția
semnalului Signal_Coolant_Value

Figura 41. Definiția semnaluli Signal_Coolant_Value.

5.6 Editarea codului
După cum s -a mai discutat, codul a fost editat în limbajul de programare CAPL, un limbaj
specific pentru programul de simulare CANoe.
Pentru a ajunge la fereastra de editare a codului în Simulation Setup să dă click dreapta pe
nodul (ECU -ul) pentru care vrem să edităm cod ul și click pe Edit. După efectuarea acestor pași ar
trebui să ne apare fereastra din figura următoare:

52

Figura 42 . Fereastra de editare a codului
În aplicația prezentată tot codul este definit pe nodul Car_Engine, fiindcă aplicația nu
reprezintă o compl exitate prea mare, părțile controlate din autovehicul se pot urmări dintr -un singur
nod.
În primul rând la partea de variabile se defines c mesajele, timerele și semnalel globale.
Aplicația conține 5 mesaje, din astea rezultă că ar trebui să conțină și 5 t imere, plus c onține câteva
variabile globale. Aceste a sunt următoarele (fiecare elem ent definit are un nume simbolic care
sugerează o legătură cu partea gafică: afișaj și control):
message Msg_Engine M1;
message Msg_Speed M2;
message Msg_Engine_RPM M3;
message MSG_Coolant M4;
message MSG_Lights M5;
msTimer T1;
msTimer T2;
msTimer T3;
msTimer T4;
msTimer T5;
byte global_time_to_sleep=0;
int global_Speed;
int global_RPM;
int global_Coolant;
int global_hazard=1;
int global_position_light;
int global_low_beam;
int global_high_beam;

În structura codului urmează lucrul cu timerele, si anume ce mesaj se trimite pe fiecare timer.
Se știe din aplicațiile reale din domeniul inginerie i auto, că nu toate mesajele se transmit cu aceeași
frecvență, cu aceeași tim ing. Unele au o animtă întârziere până ce încep să se transmit ă din momentul
trimiterii sau a activării. Din acest motiv s -au folosit mai multe timere. De exemplu timerul T4 are
următoarea str uctură:
on timer T4
{

53
char temp[255];
M4.Signal_Coolant_Value=global_Coolant ;
output(M4);
setTimer(T4,1000);
}
Din secundă în secundă se trimite pe pesajul M4.Signal_Coolant_Value valoarea curentă a
temperaturii lichidului de răcire. Valoarea curentă este dat ă de semnalul global_Coolant care conține
întotdeauna valoarea cea mai nou ă setată, iar în cod apare în felul următor:
on envVar env_Coolant
{
global_Coolant=getValue( this);
putvalue(env_Coolant_Display,global_Coolant);

if (global_Coolant>90)
SetControlVisibility( "car_display" , "Coolant_Warning" , 1);
else
SetControlVisibility( "car_display" , "Coolant_Warning" , 0);
}
envCoolant corespunde elementului de reglaj a temperaturii motorului din parte de a control a
motorului. Prin if -ul respectiv apare martorul de temperatură ridicată dacă temperatura lichidului de
răcire depășește 90 de grade.
Toate mesajele care se află pe timerele T1, T2, T3, T4 incep să fie tr ansmise după 200 de
milisecunde doar după ce ignition este pe “1”. Ignition setat pe 1 inseamnând că avem motorul pornit.
Din cod este realizat în felul următor:
on envVar env_Ignition
{
char temp[255];

if(getValue( this) == 1)
{
setTimer(T1,200);
setTimer(T3,200);
setTimer(T4,2 00);
putvalue(env_Running,1);

}
else
{
putvalue(env_Running,0);
cancelTimer(T1);
cancelTimer(T3);
cancelTimer(T4);
setTimer(T2,500);

return ;
}

54
}
După ce ignition este pus pe “0”, adic ă motorul este oprit, mesaj ele se opresc din transmitere,
doar mesajul de ignition se mai transmite 5 cicli. Acest lucru este realizat în felul următor:
on timer T2
{
char temp[255];

M1.Engine_ON_OFF=0;
global_time_to_sleep++;
output(M1);

if(global_time_to_sleep!=5)
{
setTimer(T2,500);
}
else
{
global_time_to_sleep=0;
cancelTimer(T2);
}
}
Blocul de lumini tot așa este organizat prin cod, doar că ele nu depind de Ignition. Fiecare mod
a luminii este controlat în acel ași fel:
on envVar env_Position_Lights
{
if(getValue( this) == 1)
{
putvalue(env_Actual_active_light_display,2);
putvalue(env_Stop_Lights,0);
putValue(env_Hazard,4);
}
else
{
putvalue (env_Actual_active_light_display,0);
putValue(env_Hazard,0);
}
}
Dacă sunt selectate luminile de poziție, atunci o sa ne indice martorul pe bord ca avem pozițiile
aprinse, poziție de stop automat trebuie să fie deselectată, deoarece nu putem avea și lumini pornite și
să fie a cționat butonul de oprire deodată, iar mașinuța o să aibă aprinsă luminile de drum. În caz
contrar, dacă se opresc pozițiile, indicatorul o sa dispară de pe afișaj, iar și luminile mașinuței o să fie
oprite.
Starea luminilor s e transmit pe aceeași mesaj în felul următor (pe M5 -MSG_Lights):
on timer T5
{
global_position_light=getValue(env_Position_Lights);

55
global_low_beam=getValue(env_Low_Beam);
global_high_beam=getValue(env_High_Beam);

M5.Signal_Position_ Light=global_position_light;
M5.Signal_Low_Beam=global_low_beam;
M5.Signal_High_Beam=global_high_beam;
M5.Signal_Hazard_Light=global_hazard;
output(M5);

global_hazard=!global_hazard;

if(global_hazard)
{
putValu e(env_Hazard,3);
}
else
{
putValue(env_Hazard,2);
}
setTimer(T5,1000);

}
Luminile de avarii fac o mica excepție, deoarece ele o jumatate de secundă transmit valoarea
1 – cât sunt aprinse, iar o jumătate de secundă 0 – cât sunt stinse.

56

6. Rezultate experimentale
După cum s -a mai discutat și la părțile anterioare ale ecestei lucrări, s -a creat o aplicație in
programul CANoe, care încercă să simuleze bordul unei mașini. Toată aplicația este controlată dintr –
o fereastră ca în Figura 43. Tot ce este setat din control se poate observa și grafic în fereastra de
Display având forma ca în Figura 44.

Figura 43. Fereastra de control al aplicației

57
Figura 44. Fereastra cu afișajul aplicației

Rulând aplicația putem controla elemntele din feresatra de Control. Ferestra de cont rol este
împărțit in două: există un control al motorului și un alt control al luminilor. La partea de control a
motorului putem controla Ignition -ul, care din viața reală corespunde cu contactul de cheie, viteza,
rotația pe minut al motorului și temperatura lichidului de răcire. Pentru a putes seta viteza, turația sau
temperatura este necesară ca motorul sa fie pornit, adică Ignition să fie pe ON. În figura 45 se setează
o viteză de 41 de km/h, o rotație a motorului de 2859 de rotații pe minut și o temperatura de 64 de
grade.

Figura 45.
Afișajul este ca cel din figura 46 . Valorile setate anterior sunt afișate atât analogic, prin
intermediul ceasurilor, cât și digital, efectiv afișând rezultatele in numere decimale. Ignition -ul fiind
pe ON, mai a pare o iconiță cu o mașinuță cu un text “running”.

58
Figura 46. Afișajul conform valorilor setate.

Se verific ă dacă toate aceste valori se transmit și pe mesaje. Figura 47 reprezintă mesajele cu
valorile transmise. Aceste valori sunt reprezentate în hexaz ecimal.

Figura 47. Mesajele transmise
Mesajul MSG_Engine este setat pe “1”, (byte 2 = 01), ceea ce înseamnă că Ignition este setat
pe “1”, adică motorul este pornit.
Mesajul MSG_speed pe byte -ul 3 afișează 29 în hexazecimal, valoare care în decimal este 41,
adică viteza setată din control și cea afișată.
Mesajul MSG_Engine_RPM pe byte -ul 5 și 6 afișează valoarea 2B 0B în hexazecimal, care în
decimal este 2859, adică valoarea setată pentru turația motorului.
MSG_Coolnat pe primul byte are afișat 40 in hexa, valoare care este 64 in decimal, adică
valoarea setată in controlul motorului pentru temperatura lichidului de răcire.
După ce se oprește motorul, mesajele nu se mai transmit, doar MSG_Engine se mai transmite
5 cicli, vezi Figu ra 48.

Figura 48. Mesajul MSG_Engine se opreste dup a 5 cicli după ce motorul este o prit

59

Dacă temperatur a lichidului de răcire depășește 90 de grade Celsius, pe ceasul ce afișeză
temperatur a, în colțul de dreapta jos apare martorul de avertizare a temp eraturii ridicate (Vezi Figura
49).

Figura 49. Martorul de avertizare pentru temperatura ridicată a lichidului de răcire.
Din blocul de lumini putem selecta l umina dorită: luminile de staționare (Position Lights),
lumin ile de drum: faza scurtă și faza l ungă (Low Beam și Hihg Beam) și luminile de avarie (Hazard
Lights). Din ferestra de control putem selecta opțiunile enumerate pe baza unor Check Box -uri. În
panoul de afișare a luminilor, pe mașinuța se vor aprinde luminile în fuincție de opțiunile select ate,
doar că aceste lucruri se pot observa doar în momentul rulării programului. Actual active light arată
simbolul luminii curente aprinse, iar Hazard Lights se schimbă în verde în momentul activării luminilor
de avarie. În Figura 50 putem vedea un scenar iu când sunt aprinse avariile și faza lungă.

Figura 50. Avarii + Faza lungă aprinse.

60
În momentul ce opțiunea de Stop Lights este selectată toate lumin ile se sting.
Tot așa se transmit valorile și pe Trace prin intermediul mesajului MSG_Lights, care are în
componență mai multe semnale, fiecare semnal corezpunzând stării fiecărei limini în parte. Pentru
scenariul prezentat în Figura 50 avem următorul trace (Figura 51):

Figura 51. Mesajul de lumini in momentul ce sunt aprinse avariile și faza lungă
Trebuie precizat faptul că Signal Hazard Light își schimbă starea între 0 și 1 din secundă în
secundă (conform funcționării luminilor de avarii).

61

7. Concluzii
Trăim într -o lume care evoluează zi de zi, mai ales în domeniul tehnologiei informatice. Destul
de des auzim de termenul “SMART”: locuință smart, oraș smart, telefon smart, etc. La bazele acestora
stă însă munca unor ingineri: programatori, testeri, arhitect i, opticieni etc.
În această lucrare s -a discuat despre testare în domeniul ingineriei auto. Ingineria auto acum
este într -o schimbare mare, toți constructorii de mașini investind foarte mult în dezvoltare. Cred că nu
mințim dacă spunem că acest domeniu este într -o tranziție, tinzând de la ceea ce cunoaștem noi
momentan în acest domeniu, spre autonomus driving.
De ce s -a ales testarea?
S-a pus accent foarte mare pe testare în ultima perioadă. Scopul este de a detect a erorile de
software . Deseori este un exercițiu non -trivial, deoarece testarea nu poate demonstra cu certitudine de
100% ca produsul funționează corect în orice condiți ,; testarea doar poate demonstra că produsul nu
funcționează corect în anumite condiții .
Nu toate defectele software sunt cauzate de greșeli în cod. O sursă răspândită de defecte
costisitoare sunt lacunele și neclaritățile la nivel de cerințe, de exemplu, cerințele "ascunse" sau
incomplete pot să rezulte într -un set de erori introduse încă în faza de proiectare de către desig nerul
programului. Cerințele non -funcționale precum ar fi testabilitatea, scalabilitatea, mentenabilitatea,
usabilitatea, performanța și securitatea, sunt o sursă raspândită de astfel de erori.
Defectele software se manifestă ca rezultat al următorului pro ces: un programator comite o
eroare (greșeală), care la rândul ei rezultă într -un defect (bug) la nivel de codul sursă al programului;
dacă acest defect este executat, în anumite condiții sistemul va produce un rezultat greșit, ceea ce
ulterior va duce la o eșuare a programului. Nu toate defectele pot duce la eșuarea programului. De
exemplu, defectele ce se conțin într -o secțiune de cod "mort" niciodată nu vor duce la eșuarea
programului. Defectele se pot manifesta ca eșuări la schimbarea împrejurimii în ca re rulează
programul. Exemplele de astfel de modificări includ: trecerea pe o platformă hardware nouă, alterări
în sursa de date sau interacțiunea cu software diferit. Un singur defect poate rezulta într -un spectru larg
de simptome prin care se manifestă c ăderile .

62

8. Bibliografie
[1] http://unpan1.un.org/intradoc/groups/public/documents/un -dpadm/unpan044156.pdf
[2] Testarea automobilului, Melnic Alina, Maniu Camelia, An 2008, Pag. 5
[3]
https://www.academia.edu /7336420/TEHNICI_DE_TESTARE_SOFTWARE_Banu_Alexandru_Gr
upa_441A_Cuprins_Definitie_Testare_Software_1_Generalitati_1
[4]
https://www.academia.edu/7336420/TEHNICI_DE_TESTARE_SOFTWARE_Banu_Alexandru_Gr
upa_441A_Cuprins_Definitie_Testare_Software_1_Generalitati_1
[5] http://cezara.iftodi.com/de -ce-este-necesara -testarea -software/
[6] https://www.istqb.org/downloads/send/2 -foundation -level -documents/3 -foundation -level –
syllabus -2011.html
[7] http://softwaretestingfundamentals.com/black -box-testing/
[8] http://softwaretestingfundamentals.com/white -box-testing/
[9] http://info5.conti.de/app6/passengerCars/SW/SMK/start.htm
[10] https://www.guru99.com/difference -automated -vs-manual -testing.html
[11] https://www.upwork.com/hiring/development/manual -testing -vs-automated -testing/
[12] https://www.softwaretestingclass.com/automation -testing -vs-manual -testing/
[13]
https://www.academia.edu/32993234/Programming_with_CAPL_CANalyzer_CANoe?fbclid=IwAR
2DUOXQBIDpcyGUeSCaRcBuNad0CZfww7rDQvIe_Sc0dhtLj9ga_54gd90
[14] https://can -newsletter.org/assets/files/media/raw/a456e3078f907a0482182ce831912427.pdf

63
9. Anexe
Codul aplicației scris în CAPL:
/*@!Encoding:1252*/
includes
{

}

variables
{
message Msg_Engine M1;
message Msg_Speed M2;
message Msg_Engine_RPM M3;
message MSG_Coolant M4;
message MSG_Lights M5;
msTimer T1;
msTimer T2;
msTimer T3;
msTimer T4;
msTimer T5;
byte global_time_to_sleep=0;
int global_Speed;
int global_RPM;
int global_Coolant;
int global_hazard=1;
int global_position_light;
int global_low_beam;
int global_high_beam;
}

on timer T1
{
char temp[255];

M1.Engine_ON_OFF=1;
//M1.byte(0) = M1.byte(0) + 1; // asignare semnal – valoare hex
output(M1);

M2.Signal_Speed_Value=global_Speed;
output(M2);
// snprintf(temp,255,"Message 1 has been sent");
// putValue(env_Status,temp);

M4.Signal _Coolant_Value=global_Coolant;
output(M4);

setTimer(T1,500);

}

on timer T2
{
char temp[255];

64
M1.Engine_ON_OFF=0;
global_time_to_sleep++;
output(M1);

if(global_time_to_sleep!=5)
{
setTimer(T2,500);
}
else
{
global_time_to_sleep=0;
cancelTimer(T2);

}
}

on timer T3
{
char temp[255];
M3.Signal_RPM_Value=global_RPM;
output(M3);
setTimer(T3,1000);
}

on timer T4
{
char temp[255];
M4.Signal_Coolant_Value= global_Coolant;
output(M4);
setTimer(T4,1000);
}

on timer T5
{
global_position_light=getValue(env_Position_Lights);
global_low_beam=getValue(env_Low_Beam);
global_high_beam=getValue(env_High_Beam);

M5.Signal_Position_Li ght=global_position_light;
M5.Signal_Low_Beam=global_low_beam;
M5.Signal_High_Beam=global_high_beam;
M5.Signal_Hazard_Light=global_hazard;
output(M5);

global_hazard=!global_hazard;

if(global_hazard)
{
putValue(env_Hazard,3);
}
else
{
putValue(env_Hazard,2);
}
setTimer(T5,1000);

}

65
on envVar env_Ignition
{
char temp[255];

if(getValue( this) == 1)
{
setTimer(T1,200);
setTimer(T3,200);
setTimer(T4,200);
putvalue(env_Running,1);

}
else
{
putvalue(env_Running,0);
cancelTimer(T1);
cancelTimer(T3);
cancelTimer(T4);
setTimer(T2,500);

return;
}
}

on envVar env_Speed
{
global_Speed= getValue( this);
putvalue(env_Speed_Display,global_Speed);

}

on envVar env_RPM
{
global_RPM=getValue( this);
putvalue(env_RPM_Display,global_RPM);
}

on envVar env_Coolant
{
global_Coolant=getValue( this);
putvalue(env_Coolant_ Display,global_Coolant);

if (global_Coolant>90)
SetControlVisibility( "car_display" , "Coolant_Warning" , 1);
else
SetControlVisibility( "car_display" , "Coolant_Warning" , 0);
}

on envVar env_Hazard_Light
{
if (getValue( this)==1)
{
setTimer(T5,1000);
putValue (env_Hazard_Display,1);
putvalue(env_Stop_Lights,0);
}
else
{
cancelTimer(T5);

66
putValue (env_Hazard_Display,0);
}
}

on envVar env_Position_Lights
{
if(getValue( this) == 1)
{
putvalue(env_Actual_active_ light_display,2);
putvalue(env_Stop_Lights,0);
putValue(env_Hazard,4);
}
else
{
putvalue(env_Actual_active_light_display,0);
putValue(env_Hazard,0);
}
}

on envVar env_Low_Beam
{
if(getValue( this) == 1)
{
putvalue (env_Actual_active_light_display,3);
putvalue(env_Stop_Lights,0);
putValue(env_Hazard,4);
}
else
{
putvalue(env_Actual_active_light_display,0);
putValue(env_Hazard,0);
}
}

on envVar env_High_Beam
{
if(getValue( this) == 1)
{
putvalue(env_Actual_active_light_display,4);
putvalue(env_Stop_Lights,0);
putValue(env_Hazard,4);
}
else
{
putvalue(env_Actual_active_light_display,0);
putValue(env_Hazard,0);
}
}

on envVar env_Stop_Lights
{
if(getValue( this) == 1)
{
putvalue(env_Hazard_Display,0);
putvalue(env_Hazard_Light,0);
putvalue(env_Hazard,0);
putvalue(env_Actual_active_light_display,0);
putvalue(env_High_Beam,0);
putvalue(env_Low_Beam,0);

67
putvalue(env_Position_Lights,0);
}

}

on start
{
SetControlVisibility( "car_display" , "Coolant_Warning" , 0);
putvalue(env_Hazard,0);
putvalue(env_Actual_active_light_display,0);
putvalue(env_Position_Lights,0);
putvalue (env_Low_Beam,0);
putvalue(env_High_Beam,0);
putvalue(env_Stop_Lights,0);
}