Creearea și Testarea Unui Instrument de Bord

Facultatea de Automatică și Calculatoare

Programul de Licență: Ingineria Sistemelor

Creearea și testarea

unui instrument de bord

Proiect de diplomă

Laura PETCOVICIU

Conducător științific:

Prof. dr. ing. Andreea ROBU

Timișoara

CUPRINS

Introducere

Generalități……………………………………………………………………………………..

Stadiul actual………………………………………………………………………………….

Tema proiectului…………………………………………………………………………………..

Testarea instrumentelor de bord

Despre testare……………………………………………………………………………….

Testarea software…………………………………………………………………..

Istoria testarii…………………………………………………………………………

Tehnici de testare……………………………………………………………………………

Tooluri, tehnologii, limbaje……………………………………………………………..

Solutia propusa si metodologia de proiectare/dezvoltare

Prezentarea componentelor folosite:Raspberry Pi, 2 motoare pas cu pas, un screen, butoane, led-uri…………………………………………………………………..

Prezentarea produsului final…………………………………………………………….

Implementare

Arhitectura aplicației Python…………………………………………………………….

Descrierea modulelor Aplicației Python……………………………………………

Interfața grafică…………………………………………………………………………….

Utilizare și rezultate experimentale……………………………………………………….

Concluzii, contribuții și direcții de continuare a dezvoltării…………………….

Bibliografie…………………………………………………………………………………………

1.Introducere

1.1. Generalități

Testarea software este un proces foarte important din ciclul de dezvoltare software și are un rol determinant în obținerea de produse informatice de calitate, cu fiabilitate și mentenanță ridicată. Procesul de testare necesită un volum mare de muncă și resurse financiare. De aceea, identificarea costurilor implicate de testarea software si realizarea de modele de evaluare a costului testării sunt utile în planificarea cât mai exactă a proiectelor software.

Cele mai importante calități care definesc un bun tester sunt următoarele:

Pasiunea pentru analiză și testarea manuala sau automată

Cheia succesului la orice loc de munca este o adevărata pasiune pentru ceea ce faci. Această caracteristică este de multe ori asociată cu persoanele care au studii superioare în domenii cum ar fi matematica și economia, precum și în informatică. În mare masură această pasiune pentru analiză pare a fi una înnăscută mai degrabă, decât o caracteristică dobândită.

Abilități tehnice

Un bun tester trebuie să aibă cunoștințe bazice de scrierea codului, în scopul de a înțelege sistemul care este supus testării, de a comunica cu dezvoltatorii și scrie teste automatizate. Cele mai bune abilități tehnice pot fi învățate prin educație sau din experiență.

Abilități de prioritizare și organizare

Deși este necesar pentru aproape orice loc de munca, aceste talente sunt deosebit de importante pentru testerii de software. Dezvoltarea și testarea software sunt activități extrem de dinamice și fluide, variabilele cheie se pot modifica săptămânal sau chiar zilnic. Abilitatea de a recunoaște, interpreta și de a organiza în jurul acestor factori de mediu la locul de muncă, care se schimbă frecvent este esențială.

Abilitati de adaptare și învațare rapidă
În ingineria software, tehnologiile noi apar cu o viteză incredibilă. Testerii de software trebuie să aibă o înclinație înrădăcinată de a fi elevi în desfășurare și în mod constant să petreacă o parte din fiecare săptămână dedicată upgrade-ului în competențe.

Abilitatea de a fi autonom, fără a avea nevoie de supraveghere și suport continuu 
Aceasta este altă abilitate generică, dar este o caracteristică care este deosebit de importantă pentru testerii de software. Necesitatea de a acționa independent – recunoscând rapid o necesitate tehnică sau de business legată de efortul de testare a software-ului, precum și abilitatea de a ști ce măsuri trebuie sa fie luate, fără a fi nevoie de aprobarea managerilor, este o abilitate esențială.

Comunicare eficientă :
Un tester bun trebuie să aibă puternice abilități scrise și verbale de comunicare. Trebuie să fie capabil să citească și să analizeze documentația produselor, să scrie planuri de testare, să scrie rapoarte clare de bug-uri, sa scrie status-report coerente pentru management (atât rapoarte oficiale și rapoarte ad-hoc sau e-mails).

Abilitatea de întelege cerințele business
Abilitatea de a vedea imaginea de ansamblu a strategiei globale de business a unei companii, este la fel de importantă ca si celelalte abilitati enumerate până acum. Acest lucru permite unui tester software bun, să participe activ și la un nivel mai ridicat decât doar un individ colaborator, în loc de doar găsirea și raportarea severitatii unui bug. Un tester software bun poate identifica punctele strategic tari și slabe ale unui sistem de software care poate în cele din urmă sa conducă la un avantaj competitiv de business.

Abilități-cheie

1.2.Stadiul actual

Identificarea tuturor defectelor prezente într-un produs software nu este posibilă prin niciun proces de testare. În schimb, un astfel de proces poate furniza o viziune critică sau comparativă, care vine 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 tehnice, produse asemănătoare comparabile, versiuni anterioare ale aceluiași produs, așteptari față de produs enunțate de către utilizator sau client, standarde relevante, legi în vigoare, etc.

Un studiu efectuat în anul 2002 a arătat că pierderile anuale pentru economia S.U.A. cauzate de defecte de software se estimează la 59.5 miliarde de dolari. Mai mult de o treime din aceste pierderi ar putea fi evitate dacă s-ar face investiții mai serioase în implementarea procesului de testare.

Principalul scop al procesului de testare este identificarea erorilor de software, izolarea și fixarea/corectarea defectelor care au cauzat aceste erori. Deseori este un exercițiu non-trivial, deoarece testarea nu poate demonstra cu certitudine de 100% că produsul funcționează corect în orice condiții; testarea doar poate demonstra că produsul nu funcționează corect în anumite condiții. În scopul testării deseori se include atât examinarea statică a codului sursă, cât și examinarea codului în execuție în diferite împrejurări și sub diferite condiții. Aspectele de cod ce rămân sub ochiul vigilent al test/software inginerului în timpul acestui exercițiu sunt codul face lucrul care este presupus sa-l facă și codul face lucrul care trebuie sa-l facă. Informația obținută în urma procesului de testare poate fi folosită pentru corectarea și îmbunătățirea procesului conform căruia se dezvoltă produsul software.

Vorbind despre domeniul automotive, procesul de testare este unul foarte important, deoarece un software care nu este testat suficient de serios poate conține bug-uri care pot duce pana la pierderea vieților unor persoane. Din aceasta cauză, în timp s-a urmarit cat mai mult îmbunătățirea procesului de testare pentru instrumentele de bord. Un astfel de dispozitiv dedicat exclusiv testării nu a mai fost creat, doar produse asemanatoare, pentru proiecte mici care includ Raspberry Pi, deci s-ar putea spune ca este un proiect inovativ.

2. Tema proiectului

Cunoștiințele unui om în domeniul testării pot fi foarte ușor interpretate greșit sau de multe ori păcălite printr-un ambalaj frumos. Se întamplă ca oameni care par să fie dedicați unui job care presupune orice fel de testare, sa nu poată avea o viziune clară și de ansamblu asupra produsului și astfel să nu reușească sa observe greșeli majore.

Datorită timpului scurt pe care angajatorul îl petrece cu un viitor sau posibil angajat în timpul unui interviu sau la un târg de job-uri, este foarte mare probabilitatea de a greși în alegerea acestuia pe un post de tester. Din aceste motive, angajatorii au fost nevoiți să își îmbunatățească tehnicile de evaluare a cunoștințelor viitorilor angajați, axându-se pe tehnici care implică o mai mare apropiere cu cerințele job-ului in sine, ca parte practică. De exemplu, intr-un domeniu de testare a contoarelor fabricate de orice companie din Timișoara, la un interviu angajatorul ar putea sa afle mai multe despre candidatul sau daca ar înlocui partea teoretică a interviului cu o parte practica care constă în alegerea unui produs mai simplist, similar cu unul produs de companie, și plantarea unui defect intenționat pentru a observa pe moment dacă acest potențial angajat ar putea să îl descopere. În această situație, angajatorul ar putea să observe și tehnica de abordare a candidatului, timpul necesar pentru a întelege problema, specificațiile, totul bineinteles într-o variantă mult mai simplă decât se întamplă în mod normal în realizarea procesului de testare pentru un produs final, dar totuși suficient de complex pentru a putea trage unele concluzii.

Cele prezentate mai sus reprezinta motivele algerii temei proiectului care constă în creearea unui dispozitiv dedicat pentru testare. Acest dispozitiv este de fapt o variantă simplificată a unui instrument de bord, format din componentele hardware urmatoare: un Raspberry Pi 3 model B, 2 motoare pas cu pas, 2 led-uri, 2 butoane, un LCD . Pe acest dispozitiv va fi instalat un sistem de operare numit Raspbian, unde vor fi stocate mai multe variante de software, scrise in Python. Dispozitivul poate fi controlat printr-o interfață grafică creeată în PyQt. Utilizarea acestuia în scopul testării presupune de fapt inserarea intenționată a unor bug-uri în software-uri, astfel încat pe baza unor specificații scurte, în cadrul unui interviu/work-shop sa se descopere aceste bug-uri.

3.Testarea instrumentelor de bord

3.1.Despre testare

Cauzele defectelor

Defectele sunt cauzate de erorile umane introduse în timpul dezvoltării unui program. Ele se manifestă fie prin funcționarea incorectă a aplicației la nivel logic, fie prin nefuncționarea sa sau printr-un comportament, să ii spunem, deviant (erori, crash-uri, etc. ). Oricare are fi natura unui defect, el poarta numele de "BUG" (ce NU este un acronim de la "Behaves Usually Good" ). Bug-urile apar datorită faptului că oamenii ce realizeaza aplicatiile sunt, evident, oameni. Indiferent de nivelul de experienta al dezvoltatorilor, design-erilor, arhitecților și a testerilor, erorile sunt ceva natural. Problema care se ridică este "cum procedăm astfel încât produsele software să conțină cât mai puține erori probabile?". Voi încerca prin cele ce urmează să aduc cât mai multe raspunsuri și soluții acestei probleme.

Ce înseamnă "Testarea software / QA Engineering?"

Nimic altceva decât suma tuturor procedurilor, operațiilor și acțiunilor menite să asigure buna funcționare a programelor. Prin "buna funcționare" înțelegem:

Respectarea specificațiilor / cererilor clientului

Implementarea corectă a cerințelor de funcționare (requirements)

Absența erorilor de proiectare logică și algoritmică

Siguranța datelor folosite in cadrul programului

Viteza optimă de rulare a aplicației

Folosirea eficientă a resurselor disponibile

Grad ridicat de utilizare

În accepțiunea generală, testarea se caracterizează prin rularea testelor. Aceasta este, in schimb, doar partea vizibila din exterior. Pentru a asigura toate cele de mai sus, este nevoie de mult mai multe etape până a ajunge în punctul execuției testelor. Din motive de eficiență, planurile de teste trebuie neapărat sa conțina și o perioadă de timp alocată planificarii testelor, design-ului test case-urilor, planificării execuției și, bineințeles, analizei rezultatelor.

Procesul fundamental de testare este alcătuit din urmatoarele activități principale:

Planificare și control

Verificarea misiunii de testare, definirea obiectivelor și specificarea activității de testare astfel încât aceasta să atingă obiectivele și scopul misiunii

Compararea progresului / evoluției actual(e) cu planul inițial și raportarea stării de fapt, inclusiv deviațiile de la plan. Pentru a controla eficient procesul de testare, acesta trebuie monitorizat pe toată durata proiectului.

Analiză și Design

Secțiunea în care obiectivele sunt transformate in test case-uri si condiții de testare tangibile

Implementare și execuție

Sunt definite proceduri de testare și/sau scripturi prin aranjarea test case-urilor într-o anumită ordine și includerea de informații adiționale necesare execuției; se pregatește mediul de test și se execută testele

Evaluarea rezultatelor și raportarea acestora

Analiza rezultatelor execuției testelor și compararea acestora cu obiectivele inițiale; evident, raportarea situației

Finalizarea procesului de testare

Adunarea de date stranse pe parcursul proiectului (cifre, numere, impresii ale membrilor echipei, etc.) in vederea analizei workflow-ului

De ce avem nevoie de testare și cine o poate face? Rolul testării în cadrul dezvoltării și a mentenanței.

Ar trebui să fie evident pentru toată lumea că procesul testării unui produs este privit ca fiind unul distructiv, chiar ofensator către cei ce l-au dezvoltat. Testerii sunt priviți de multe ori cu un soi de ură de către dezvoltatori mai ales și, de multe ori, desconsiderați. Și asta e bine! Personalul responsabil cu calitatea unui produs trebuie să fie acel ghimpe-n coasta dezvoltatorilor, acel om care poate spune cu nonșalanță în ziua unui release public că produsul nu e încă matur și nu trebuie să iasă pe piață daca nu se dorește falimentul proiectului.

Testarea este o activitate constructivă din punct de vedere managerial și al analizei riscurilor. Pentru a căuta defecte și potențiale erori într-un sistem, este nevoie de multă curiozitate, pesimism, mare atenție la detalii, spirit critic și analitic și o fire comunicativă, în special cu dezvoltatorii.

Atâta timp cât defectele și erorile sunt comunicate într-o manieră corespunzătoare, tensiunile dintre tester și dezvoltator pot fi eliminate definitiv. În cele din urma, să nu uităm că interesul comun trebuie să fie întotdeauna calitatea și eficiența produsului oferit, iar sentimentul efortului colectiv trebuie să se regăsească în fiecare. Privind aspectul din urmă, managerii firmelor au o foarte mare influență. Ei pot crea și susține acest sentiment, prin încurajări periodice și obiectivitate.

Tester-ul nu este ultima linie de apărare a clientului! El nu are rolul de a ține produsul departe de client și nici doar rolul de a gasi bug-uri la nesfârșit! Daca se întâmplă asta, problema este mult mai adâncă.

Tester-ul trebuie să raporteze problemele într-un mod neutru, evitând criticarea persoanei ce a dezvoltat modulul/programul în cauză!

Întotdeauna, tester-ul trebuie să înțeleagă persoanele din jur și, mai ales, motivele ce le fac să reacționeze într-un anumit fel (mai ales în condiții de stres)

Asigurați-vă că persoana căreia vă adresați înțelege exact ceea ce ați spus! Clarificați orice aspect inainte de a trece la acțiune!

3.1.1. Testarea software

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 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 produsului 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. Testarea software mai poate fi definită ca un proces de validare și verificare a faptului că un program/aplicație/produs software (1) corespunde business cerințelor și cerințelor tehnice care au ghidat proiectarea și implementarea lui; și (2) rulează și se comportă corespunzător așteptărilor.

În dependență de metodologia de testare aleasa, testarea software poate fi implementată la orice etapă în cadrul procesului de dezvoltare, deși partea considerabilă a efortului de testare este aplicată de obicei la etapa de după cizelarea/formalizarea cerințelor și finisarea implementă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 vine sa 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 tehnice, produse asemănătoare comparabile, versiuni anterioare ale aceluiași produs, așteptari 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 jocurilor video este complet diferită de audiența 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 sa facă această evaluare posibilă într-un mod cât mai obiectiv.

3.1.2. Istoria testarii

Un studiu efectuat în anul 2002 de către NIST a arătat că pierderile anuale pentru economia S.U.A. cauzate de defecte de software se estimează la 59.5 miliarde de dolari. Mai mult de o treime din aceste pierderi ar putea fi evitate dacă s-ar face investiții mai serioase în implementarea procesului de testare.

Gelperin și Hetzel au analizat evoluția conceptului de testare a unui sistem informatic și au împărțit evoluția acestuia în mai multe etape, în funcție de filozofia care a stat la baza conceptului:

1945 – 1956 – Orientarea spre depanare

Testarea programelor informatice este o activitate care a apărut o dată cu procesul de dezvoltare a acestora. În perioada apariției primelor sisteme informatice – 1945-1956, procesul de testare era în special orientat către componentele hardware ale sistemului, iar defectele din software erau în general considerate ca fiind mai puțin importante. Persoanele care elaborau codul se ocupau și de partea de testare, deși nu o făceau într-o manieră metodică, și denumeau această activitate verificare. Pentru mulți dintre oamenii de știință care se ocupau de scrierea programelor informatice nu exista o distincție clară între activitățile de scriere a codului, testare și depanare. Din această perioadă timpurie datează prima referire la conceptul de "bug" într-un sistem informatic, când un operator al unui calculator descoperă pe un circuit electronic care funcționa defectuos o molie, și o atașează în jurnalul de operațiuni, cu mențiunea ca 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, și 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 poată fi diferențiate de către răspunsurile oferite de un om (etalonul). Această lucrare poate fi considerată a fi prima care se ocupă de conceptul de testare, considerat distinct de activitățile de elaborare a codului respectiv de depanare.

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șterea impactului economic pe care defectele nedetectate le puteau avea. De asemenea, persoanele implicate în dezvoltarea de programe informatice au devenit mai conștiente de riscurile asociate cu defectele din 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 sistemele informatice. Scopul procesului de testare era demonstrarea corectitudinii funcționării programului, adică absența erorilor.

1979 – 1982 – Orientare 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. De asemenea, el susține că în testarea bazată pe demonstrație există pericolul ca operatorul să aleagă în mod inconștient acel set de parametri care ar asigura funcționarea corectă a sistemului, ceea ce creează pericolul ca multe defecte să treacă neobservate. Myers propune în abordarea 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 Americii 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 unor diverse metode de verificare și validare, în funcție de caracteristicile fiecărui 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ării 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 STD 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 metodologie 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ție și întreținere. Respectarea acestei metodologii duce la scăderea costurilor de dezvoltare și de întreținere a unui sistem prin scăderea numărului de defecte care ajung nedetectate în produsul final.

3.2 Tehnici de testare

Metode de testare

Metoda "White Box"

Este opusul metodei Black box. În acest caz, se presupune că tester-ul are acces în sursele programului (structuri, cod, algoritmi). De multe ori, testarea prin această metodă implică scrierea de cod sau cel puțin, urmărirea celui existent. Practic, luând la cunoștință construcția programului și modul său de lucru, se testeaza fiecare metodă în parte inițial, cât și interoperarea metodelor.Această metodă este aproape identică cu testarea unitară.

Metoda "Gray Box"

Pe parcursul anilor, această metodă a apărut din nevoie și practicabilitate. Este, dupa cum ii spune si numele, etapa intermediară intre "White box" si "Black box". Ca mod de lucru, având acces la sursele programului, se construiesc test case-urile. După care, acestea sunt executate în mod Black box ca și user simplu, neaxandu-ne în momentul executarii testului pe structura internă a programului.

Metoda "Black Box"

Presupune testarea programului la nivelul user-ului, plecand de la premisa ca nu cunoaștem modul în care acesta funcționează. Practic, nu luăm în calcul modul în care programul este construit și metodele sale, ci pur si simplu noi ii cerem ORICE, iar programul trebuie să ne dea un răspuns. Pentru acest tip de testare, tester-ul trebuie să cunoască rezultatele ce se asteaptă din partea programului pentru fiecare caz în parte.

(Inlocuit cu mai multe tehnici de testare sau dezvoltare despre black-box testing)

Nivele de testare

Testarea componentei / Component testing

Testarea integrării / Integration testing

Testarea unui sistem / System testing

Teste de acceptanță / Acceptance testing

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 programelor informatice: planificare, proiectare, programare, evaluare și control.

Scopul

Scopul primordial pentru procesul de testare este (1) identificarea erorilor de software, (2) izolarea și fixarea/corectarea defectelor care au cauzat aceste erori. Deseori este un exercițiu non-trivial, deoarece testarea nu poate demonstra cu certitudine de 100% ca produsul funționează corect în orice condiții; testarea doar poate demonstra că produsul nu funcționează corect în anumite condiții. În scopul testării deseori se include atât examinarea statică a codului sursă, cât și examinarea codului în execuție în diferite împrejurări și sub diferite condiții. Aspectele de cod ce rămân sub ochiul vigilent al test/software inginerului în timpul acestui exercițiu sunt (1) codul face lucrul care este presupus sa-l facă și (2) codul face lucrul care trebuie sa-l facă. Informația obținută în urma procesului de testare poate fi folosită pentru corectarea și îmbunătățirea procesului conform căruia se dezvoltă produsul software.

Defecte și eșuări

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 designerul programului.[9] Cerințele non-funcționale precum ar fitestabilitatea, 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 proces: 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.[10] 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 care 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.

Compatibilitatea

Deseori aplicațiile software cad din cauza problemelor de compatibilititate cauzate atât de interacțiunea lor cu alte aplicații sau sisteme de operare, cât și de non-conformitățile ce apar de la o versiune a programului la alta într-un proces inceremental de dezvoltare a produsului. Incompatibilitățile ce apar între versiuni se datorează faptului că la momentul scrierii codului programatorul a considerat, sau a testat, produsul doar pentru un singur sistem de operare (sau un set restrâns de sisteme de operare), fară a lua în calcul problemele ce pot apărea la schimbarea contextului de execuție. Un rezultat nedorit al acestui fapt poate fi următorul: ultima versiune a programului poate să nu mai fie compatibilă cu acea combinație de software/hardware folosită mai devreme, sau poate să nu mai fie compatibilă cu un alt sistem, compatibilitate extrem de importantă. Deci, testarea de compatibilitate este o "strategie orientată spre prevenire", fapt ce o asociază clar cu ultima din fazele de testare propuse de Dave Gelperin și William C. Hetzel.

Combinări de date de intrare și precondiții

O problema fundamentală a testării software a fost și rămâne imposibilitatea de a testa un produs utilizând toate combinațiile posibile de date de intrare și precondiții (starea inițială). Aceasta este adevărat chiar și în cazul produselor simple.

3.3 Tool-uri, Tehnologii, Limbaje

Sistemul de operare Raspbian

Raspbian este un sistem de operare care se găsește gratis pe internet, bazat pe tehnologia Debian și optimizat pentru hardware-ul Raspberry Pi-ului. Acest sistem de operare reprezintă de fapt un set de programe de bază și utilități care fac Raspberry Pi-ul sa ruleze. Totuși, Raspbian aduce mai mult decât un simplu sistem de operare: acesta vine împreună cu peste 35000 de pachete, software precompilat, puse într-un format care ajută la ușoara instalare a acestuia pe Raspberry Pi.

Varianta inițială compilată cu peste 35000 de pachete Raspbian, optimizată pentru cea mai buna performanță a Raspberry Pi-ului, a fost finalizată în Iunie 2012. De fapt, sistemul de operare Raspbian este încă în curs de dezvoltare cu o focusare pe îmbunătățirea stabilității și a performanței a cat mai multe pachete Debian posibile.

Raspbian nu este afiliat la fundația Raspberry Pi. Raspbian a fost creat de o echipă mică și dedicată de dezvoltatori, fani ai hardware-ului Raspberry Pi-ului, a scopurilor educaționale a fundației Raspberry Pi și desigur a proiectului Debian.

Sistemul de operare instalat pe Raspberry Pi este Raspbian Jessie, versiunea din Martie 2016, data release-ului fiind pe 18 Martie 2016.

Imagine desktop Raspbian

Terminal pe Raspberry Pi

Terminalul (sau command-line) pe un computer permite utilizatorului un foarte mare control asupra sistemului ( în acest caz asupra Raspberry-ului ). Utilizatorii de windows s-ar putea deja să fi folosit Comand Prompt sau PowerShell, iar utilizatorii de Mac OS sunt mai familiari cu Terminal. Toate aceste unelte permit unui utilizator să manipuleze direct sistemul lor prin folosirea unor comenzi. Aceste comenzi pot fi combinate în scripturi mai complexe care pot realiza task-uri mult mai eficient decat pachetele tradiționale de software. Pe Raspberry Pi (rulând Raspbian) aplicația de bază a terminalului se numește LXTerminal. Acesta este cunoscut ca ‘terminal emulator‘.

PYTHON

Python este un limbaj de programare dinamic multi-paradigmă, creat în 1989 de programatorul olandez  Guido van Rossum. Van Rossum este și în ziua de astăzi un lider al comunității de dezvoltatori de software care lucrează la perfecționarea limbajul Python și implementarea de bază a acestuia, CPython, scrisă în C. Python este un limbaj multifuncțional folosit de exemplu de către companii ca Google sau Yahoo! pentru programarea aplicațiilor web, însă există și o serie de aplicații științifice sau de divertisment programate parțial sau în întregime în Python. Popularitatea în creștere, dar și puterea limbajului de programare Python au dus la adoptarea sa ca limbaj principal de dezvoltare de către programatori specializați și chiar și la predarea limbajului în unele medii universitare. Din aceleași motive, multe sisteme bazate pe Unix, inclusiv Linux,BSD și Mac OS X includ din start interpretatorul CPython.

Python pune accentul pe curățenia și simplitatea codului, iar sintaxa sa le permite dezvoltatorilor să exprime unele idei programatice într-o manieră mai clară și mai concisă decât în alte limbaje de programare ca C. În ceea ce privește paradigma de programare, Python poate servi ca limbaj pentru software de tipul object-oriented, dar permite și programarea imperativă, funcțională sau procedurală. Sistemul de tipizare este dinamic iar administrarea memoriei decurge automat prin intermediul unui serviciu „gunoier” (garbage collector). Alt avantaj al limbajului este existența unei ample biblioteci standard de metode.

Implementarea de referință a Python este scrisă în C și poartă deci numele de CPython. Această implementare este software liber și este administrată de fundația Python Software Foundation.

Python este un limbaj multi-paradigmă, concentrându-se asupra programării imperative, orientate pe obiecte și funcționale, ceea ce permite o flexibilitate mai mare în scrierea aplicațiilor. Din punctul de vedere al sintaxei, Python are un număr de construcții și cuvinte cheie cunoscute oricărui programator, dar prezintă și un concept unic: nivelul de indentare are semnificație sintactică. Blocurile de cod sunt delimitate prin simplă indentare.

În C un astfel de blocuri sunt deseori desemnte prin acolade, {<cod>}, dar în Python nu este nevoie de astfel de construcții. Nivelele de indentare îndeplinesc această funcție. Această importanță a indentării este foarte suprinzătoare pentru mulți utilizatori noi ai limbajului Python, chiar dacă sunt programatori cu experiență. Dar o astfel de utilizare a indentării permite codului să fie mai ușor de citit și mai compact. Programatorii cu experiență vor indenta implicit codul sursă, oricare ar fi limbajul, fiindcă astfel se permite structurarea codului sursă și evidențierea funcționalității. Python face din această deprindere folositoare în acest sens o cerință strictă.

Includerea tuturor acestor structuri, precum și a funcțiilor ce permit manipularea și prelucrarea lor, precum și multe alte biblioteci de funcții sunt prezente datorită conceptului “Batteries Included”, ce poate fi explicat prin faptul că Guido van Rossum și comunitatea ce s-a format în jurul limbajului cred că un limbaj de programare nu prezintă utilitate practică dacă nu are un set de biblioteci importante pentru majoritatea dezvoltatorilor.

Din acest motiv Python include bibioteci pentru lucrul cu fișiere, arhive, fișiere XML și un set de biblioteci pentru lucrul cu rețeaua și principalele protocoale de comunicare pe internet (HTTP, Telnet, FTP). Un număr mare de platforme Web sunt construite cu Python. Abilitățile limbajului ca limbaj pentru programarea CGI sunt în afara oricăror dubii. De exemplu YouTube, unul din site-urile cu cea mai amplă cantitate de trafic din lume, este construit pe baza limbajului Python.

Totuși, Python permite extinderea funcționalității prin pachete adiționale programate de terți care sunt axate pe o anumită funcționalitate. De pildă, pachetul wxPython conține metodele și structurile necesare creării unei interfețe grafice.

Popularitatea limbajului este în creștere începând cu anul 2000, datorită faptului că Python permite crearea mai rapidă a aplicațiilor care nu cer viteze înalte de procesare a datelor. De asemenea este util ca limbaj de scriptare, utilizat în cadrul aplicațiilor scrise în alte limbaje. Modulele (bibliotecile) Python pot fi de asemenea scrise în C, compilate și importate în Python pentru a mări viteza de procesare.

IDLE

Mediul de dezvoltare pentru Python care vine odata cu sistemul de operare Raspbian, se numește IDLE și se gasește în meniul pentru Programming al interfeței Desktop. IDLE oferă un REPL (Read-Evaluate-Print-Loop) care este un prompt unde se pot introduce comenzi Python. Fiind un REPL poți chiar sa vezi ieșirile comenzilor pe ecran fără să fie nevoie să folosești print.

PyQt

PyQt este o platformă pentru creearea de interfețe grafice atașată limbajului Python. La fel ca și Qt, PyQt este un software care se gasește gratis. PyQt este dezvoltat de o firmă britanică numită RiverBank Computing. Este disponibil sub diferite forme pentru orice versiune de Qt mai veche de 4.5. PyQt suportă Microsoft Windows precum și diferite variante de Unix, incluzând Linux și OS X.

PyQt implementează in jur de 440 de clase și peste 6000 de funcții și metode inclusiv:

Un set substanțial de widget-uri pt GUI, widget însemnând orice control care poate fi atașat pe interfață

Clase pentru accesarea unei baze de date SQL (ODBC, MySQL, PostgreSQL, Oracle, SQLite)

Widget-uri de date care sunt automat populate dintr-o bază de date

Un parser XML

Suport SVG

…Find more about PyQt…

4. Soluția propusă și metodologia de proiectare/dezvoltare

4.1.Prezentarea componentelor folosite:Raspberry Pi, 2 motoare pas cu pas, un screen, butoane, led-uri

Raspberry Pi 3

Raspberry Pi 3 este un SBC (Single-Board Computer) de dimensiunile unui card de credit, produs în Marea Britanie de către Raspberry Pi Foundation cu scopul de a promova învățarea noțiunilor de bază din domeniul informaticii în școli.

Pentru noua generație de micro-computere, Raspberry Pi Foundation a folosit un nou chipset Broadcom, modelul BCM 2837, cu arhitectură pe 64 de biți. Acesta integrează un CPU quad-core Cortex-A53 la 1,2 GHz, 1 GB memorie RAM (aceeași cantitate de pe modelul cu numărul 2) și un GPU VideoCore IV la 400 MHz.

Procesorul oferă o creștere a frecvenței cu 33%, care se manifestă în utilizare reală în viteză cu 50-60% mai mare în aplicații pe 32 de biți în comparație cu cel de pe Raspberry Pi 2.

Marea noutate este însă integrarea unor module wireless 802.11n și Bluetooth 4.1, care duce la eliberarea port-urilor USB pentru cei care foloseau adaptoare pentru conectare la rețea sau la alte dispozitive.

Componentele Raspberry Pi-ului sunt prezentate in tabelul de mai jos:

Motoarele pas-cu-pas

Motoarele pas-cu-pas sunt motoare de current continuu care împart o rotație completă într-un numar de pași egali. Poziția motorului poate fi comandată astfel încât acesta să se miște sau să se oprească la unul din acești pași fără niciun senzor de poziție, atâta timp cât motorul este dimensionat corespunzător în circuitul în care se folosește.

Motoarele de curent continuu au o rotație continuă atâta timp cât sunt alimentate. Motorul pas-cu-pas știe din construcția sa să convertească o serie de impulsuri de intrare într-o deplasare pană la o poziție anume a axului. Fiecare impuls mișcă astfel axul cu un unghi fix.

Motoarele pas-cu-pas au mai mulți electromagneți dințați aranjați în jurul unei roți centrală. Electromagneții sunt alimentați de un driver extern sau de un microcontroller. Ca să facă motorul să se miște, prima dată, un electromagnet este alimentat, iar acesta atrage magnetic dintele rotiței. Când dinții rotiței sunt aliniați cu primul electromagnet, ei sunt ușor defazați față de urmatorul electromagnet. Asta înseamnă că atunci când cel de-al doilea electromagnet este stimulat iar primul nu, roata se deplasează ușor către următorul electromagnet. De aici procesul este repetat. Fiecare dintre aceste rotații este denumit pas, iar cu un numar întreg de pași se formează o rotație completa. În acest fel, motorul poate fi pus în mișcare cu un unghi precis.

Sunt 4 tipuri mari de motoare pas cu pas:

Motor pas-cu-pas cu magnet permanent

Motor pas-cu-pas hibrid sincron

Motor pas-cu-pas cu rezistență variabilă

Motor pas-cu-pas de tip Lavet

Motoarele pas-cu-pas în 2 faze

Exista 2 tipuri de bază de aranjamente pentru bobinele electromagnetice într-un motor pas cu pas în 2 faze: bipolar și unipolar.

Motoarele unipolare

Un motor pas-cu-pas unipolar are un bobinaj cu priză mediană pe fiecare fază. Fiecare secțiune de bobinaj este activată pentru fiecare direcție a câmpului magnetic. Luând în considerare ca in acest aranjament un pol magnetic poate fi inversat fără a schimba direcția curentului, comutația circuitului poate fi facută foarte simplu pentru fiecare înfășurare. De obicei, pentru o fază, punctul central al fiecărei înfășurări se face comun: oferind 3 fire pentru fiecare fază și 6 fire pentru motor cu 2 faze tipice. De obicei 2 faze sunt unite intern, iar motorul are doar 5 fire extern.

Un microcontroller poate fi folosit pentru a activa o grupare de tranzistoare într-o ordine corectă, iar tocmai din această cauză motoarele unipolare sunt foarte populare în rândul pasionațiilor: sunt probabil varianta cea mai ieftină pentru a obține deplasări unghiulare precise.

Motoarele bipolare

Motoarele bipolare au o singură înfășurare pe fază. Curentul printr-o fază trebuie reversat astfel încât un pol magnetic să fie reversat, prin urmare circuitul este mai complicat decât la motoarele unipolare. De obicei se folosește o punte H pentru controlul motoarelor bipolare. Pentru fiecare fază sunt 2 fire, iar niciunul dintre ele nu este folosit pentru faza comună. Pentru că înfășurările sunt mai bine folosite, acestea sunt mai puternice decât la un motor unipolar de aceeași dimensiune. Acest lucru se datorează spațiului fizic ocupat de înfășurări.

Motorul folosit pentru proiect este un motor unipolar, indicat pentru proiectele mici și care are în construcția lui un suport cu 2 găuri pentru a fi montat în diferite circuite. Acest motor permite 513 de pași pe rotație.

Detalii tehnice:

Motor stepper unipolar cu cu un conector de cablu cu 5 pini distanțați la 0.1”

513 pași pe rotație

Reducție de 1/16

Alimentare la o tensiune de 5V

Greutate:37 de grame

Dimensiuni: 28 mm diametru, 20mm înălțime excluzând axul de 9 mm înălțime și 5 mm diametrul

Cablul de lungime de 23 de cm

Cuplu de forță: 150 gram-forță*cm, 15 N*mm/2 oz-forță*in

Ax: cu diametrul de 5 mm aplatizat

O impedanță aproximativă de 42 de ohmi pe bobinaj

LCD

LCD-ul poate să afișeze 16  caractere pe 2 randuri, are backlight de culoare albastră, și dispune de un backpack care permite ajustarea luminozitatii și conectarea la Raspberry Pi utilizând 8 fire mamă-mamă.

2 Butoane

Butonul brick este o componentă care sesizează apăsarea.

2 Led-uri

Led-ul brick este o componentă care emite lumină atunci când portul la care este conectată trece în HIGH.

Driver-ul L293D folosit pentru controlul motoarelor

4.2. Prezentarea produsului final

Poza

Produsul final reprezintă un instrument de bord care va putea fi ușor utilizat împreună cu un laptop si o alimentare de 2A. Am numit produsul intrumentul de bord A01 și este format dintr-o parte fizică obținută din interconectarea componentelor prezentate anterior, și o interfață GUI(graphic user interface) din care se poate foarte ușor controla acest dispozitiv. In anexa SPECIFICAȚII_01 sunt prezentate specificațiile de funcționare a dispozitivului. Dispozitivul va fi folosit pentru testare, astfel ca acest mod de funcționare al sistemului va fi parțial compromis prin inserarea intenționată de bug-uri. Scopul practic al lucrarii este obținerea unui dispozitiv care să permită testarea rapida a unui intrument care se apropie foarte mult de un instrument de bord real care se integrează intr-o mașina funcțională.

Poză printscreen gui

5.Implementare

5.1.Arhitectura aplicației Python