Proiectarea Si Implementarea Unei Solutii de Testare Automata Bazata pe Cuvinte Cheie

LUCRARE DE LICENȚĂ

Proiectarea și implementarea unei soluții de testare automată bazată pe cuvinte cheie.

Cuprins

Introducere

Capitolul 1. Fundamentarea teoretică

1.1 Analiza bibliografică a soluției dorite

1.2 Deschiderea către testare(Open2Test)

1.3 Descrierea și utilizarea Centrului de calitate(Quality Center)

1.4 Instrumentul de testare profesională rapidă automată(QuickTest Professional)

1.5 Platforma de dezvoltare a aplicației(C#)

Capitolul 2. Specificațiile aplicației

2.1. Salvarea testelor pe Local/Centrul de Calitate

2.2. Rularea testelor stocate pe Centrul de Calitate (sau a întregului test set)

2.3. Rularea testelor direct de pe Centrul de Calitate

2.4. Crearea de valori multiple de intrări de date pentru teste

Capitolul 3. Proiectarea de detaliu

3.1. Arhitectura aplicației

3.2. Implementarea Centrului de Calitate la nivelul aplicației

3.3. Utilizarea Instrumentului de testare automată rapid QTP în aplicație

3.4 Tehnologia XML

Capitolul 4. Utilizarea aplicației

4.1 Pre-rechizite necesare

4.2 Rularea aplicației si conectarea la centrul de calitate

4.3 Configurarea aplicației

4.4 Crearea testelor

4.5 Salvarea testelor

4.6 Deschiderea testelor

4.7 Generarea de date de intrare

4.8 Rularea testului curent

4.9 Vizualizarea rezultatelor testului rulat curent

4.10 Rularea unui Test Set

Capitolul 5. Realizarea practică a aplicației

5.1 Instrumente necesare pentru începerea dezvoltării

5.2 Rezolvarea problemelor întâmpinate

Concluzii

Bibliografie

Introducere

La tot ce necesită efort uman în zilele noastre s-a ajuns la o dorință acerbă de a găsii soluții de automatizare. Impactul automatizării este din ce în ce mai mare în viața de zi cu zi, asupra societății noastre și a modului în care aceasta își desfășoară activitatea.

Sistemele de testare automată sunt o tehnologie în plină dezvoltare care au ca scop descoperirea și raportarea eventualelor defecte, mărirea longevității produsului și reducerea costurilor procesului de întreținere.

Mai mulți factori trebuie luați în calcul atunci când se pune problema automatizării testelor manuale.

Cu toate că costurile pentru realizarea testelor automate este mai mare decât în cazul testării manuale, tot mai multe instituții aleg testarea automată deoarece aceasta reprezintă soluția mai puțin costisitoare în timp dar și pentru a mări progresul și eficacitatea testării.

Testarea e una din cele mai importante etape din realizarea unui produs software, dacă nu cel mai important. Obiectivul testării este de a evidenția concordanța dintre produsul soft finit și specificațiile produsului. Există mai multe metode de testare, dintre care cele care au la bază experiența, structura produsului finit se dovedesc a fi cele mai eficiente.

Principala problemă a testării este că este atât de eficientă pe cât sunt datele de testare. Construirea manuală a datelor de test nu este ceva dificil dar rezolvarea manuală cu un grad de rigurozitate a rezultatelor intermediare sau chiar finale este însoțită de riscuri majore.

Unei etape superioare este caracteristică testarea automată. Testarea automată presupune,

conform [MYER79] :

existența unui produs soft complex care să dezvolte astfel de procese

definirea la intrare a programului care face obiectul testării;

realizarea unei varietăți de mecanisme de testare care să acopere o gamă cât mai variată de programe

identificarea de criterii de evaluare a rezultatului testării care să stea la baza revizuirilor ulterioare

prezentarea de procese ale prelucrărilor inverse care să permită verificarea în mod independent a calității soluțiilor produsului testat.

Testarea automată permite executarea scenariilor de teste ajutând la testele de regresie și rularea de teste pe mai multe mașini simultan scăzând astfel timpul de testare și amortizând costurile inițiale.

Următoarele beneficii le putem considera a fii cele mai importante ale testării automate:

posibilitatea repetării testelor

creșterea siguranței în produs

posibilitate simulării testelor cu mai mulți utilizatori

reducerea costurilor testelor repetate

Documentul de planificare al unui test descrie domeniul de aplicare, de abordare, de resurse cât și programul de activități de testare destinate produsul de testare. Acesta identifică printre altele elementele de testare, caracteristicile de testare, mediul de testare, tehnicile de proiectare și criteriile de ieșire care urmează să fie date spre procesare precum și justificarea alegerilor făcute și riscurile asumate ale planificării. Acesta este de fapt o înregistrare a procesului de planificare a testării. Toate aceste specificații de planificare al unui test sunt specificate și în standardul IEEE 829.[HTTP 3].

Testarea automată este încă un domeniu în plină dezvoltare, care poate atrage beneficii maxime cu un minim de efort. Printre beneficiile sale se numără și creșterea eficienței resurselor, a gradului de acoperire a testării, a calității și a fiabilității produsului.

Testarea automată reprezintă o modalitate eficientă de a testa componentele unui produs oferind o modalitate atractivă de utilizare printr-o interfață ușor de utilizat precum și capacitatea de aflare rapidă a rezultatelor testelor.

Testarea automată înseamnă într-o abordare mai detaliată, planificarea cazurilor de test, construcția scripturilor de test, execuția scenariilor de rulare a scripturilor și documentarea permanentă a stadiului curent al proiectului.

Datorită numărului mare de tehnologii de dezvoltare soft, testarea automată a devenit pe atât de costisitoare, conform [POCA02] , cât de necesară. Implementarea de teste automate necesită un număr mare de ingineri specializați în testare automată.

Testarea automată bazată pe cuvinte cheie permite inginerilor specializați în automatizare să se concentreze pe aspectele specifice tehnologiilor folosite oferind astfel un limbaj de automatizare accesibil întregii echipe[HTTP4].

Această lucrare își propune să analizeze progresele făcute în acest domeniu până în momentul de față, soluții sursă deschisă și comerciale. Totodată lucrarea va prezentă și soluția proprie care implementează o infrastructură bazată pe cuvinte cheie. Infrastructura va conține o bază de date centralizată, un editor vizual și va fi compatibilă cu instrumentul de testare automată rapidă consacrat QTP.

Pe piața tehnologiei de automatizare a testelor manuale există o întreagă gamă de instrumente de automatizare însă au dezavantajul că pentru folosirea lor este necesară cunoașterea limbajului de programare și a metodologia de utilizare a acestora.

Această aplicație vine în ajutorul experților de produs, celor care nu au cunoștințe despre tehnologia și limbajul de programare necesar instrumentului de programare.

Prin tema aleasă se cere proiectarea unei aplicații care să fie bazată pe utilizarea cuvintelor cheie în testarea automată ,care să nu necesite abilități de programare pentru automatizarea testelor sau cunoașterea instrumentului de automatizare folosit și care să implementeze următoarele funcționalități:

elaborarea de teste

deschiderea testelor deja existente

salvarea testelor

rularea testelor selectate folosind instrumentul de automatizare QTP

rularea testelor de pe centrul de calitate Quality Center

stocarea resurselor pe Quality Center

vizualizarea rezultatelor testelor după rularea acestora

generator de creare de date de intrare care să adauge valori adiționale la parametrii de intrare ai testului

integrarea cu Quality Center ( testele sunt stocate pe Quality Center și pot fi rulate direct din Quality Center sau pot si executate din aplicația de automatizare iar rezultatele testului vor fi actualizate în Quality Center)

configurarea locației resurselor și versiunii cadrului de testare ce vor fi folosite

posibilitatea inserării și ștergerii cuvintelor cheie din cadrul unui test

o minimă manipulare a cuvintelor cheie invalide (necompletarea valorilor parametrilor cuvintelor cheie va colora cuvintele cheie în roșu și vizualizarea parametrilor unui cuvânt cheie prin selectarea acestuia prin dublu clic)

Capitolul 1. Fundamentarea teoretică

Analiza bibliografică a soluției dorite

Conform documentației găsite pe internet,[Http11] există foarte multe instrumente pe piața instrumentelor de automatizare a testelor, dar fiecare dintre aceste necesită cunoștințe de programare și de utilizare a acestora. Conform [Http12], le folosesc. Aplicațiile similare găsite pe internet sunt orientate spre testarea automată anumitor componente, necesitând Test Studio, de exemplu [Http13] testează aplicațiile de funcționalitate Desktop și internet, aplicațiile de performanță pe internet.

Soluția descrisă în lucrarea de față necesită doar cunoașterea produsului de automatizat și o scurtă introducere de utilizare a aplicației de automatizare cu cuvinte cheie.

Pentru realizarea temei de proiect am apelat la resursele bibliografice ale unor discipline studiate pe parcursul facultății cât și la informațiile găsite în cărți de specialitate și în cea mai mare măsură la documentația găsită online sau la documentația disponibilă din cadrul firmei.

Soluția este realizată în mediul de programare Visual C# integrat în Microsoft Visual Studio 2005, aceasta fiind versiunea cu licență din cadrul firmei.

Pentru lucrul cu Quality Center am folosit documentația OTA API oferită de către Centrul de Calitate[Http5]

Am găsit de asemenea proiecte, [Http8], [Http9], orientative care ne-au ajutat la implementarea codului pentru crearea de noi date de intrare pentru teste și pentru a atașa imagini diferite testelor de dosarelor obișnuite pe CodeProject. [Http6]

Pentru a accesa un folder din C# a fost nevoie de implementarea unui cod care să reanalizeze starea directoarelor, iar pentru asta am găsit ajutor pe acest forum[Http7].

Acestea sunt doar câteva exemple. Alte probleme întâmpinate precum și rezolvările acestora vor fi menționate pe parcursul lucrării.

1.2 Deschiderea către testare(Open2Test)

Testarea automată este un câmp emergent care atrage beneficii maxime cu efort minim. Beneficiul testării automate este capacitatea sa de a crește eficiența resurselor, creșterea acoperirii de teste și de a crește calitatea și fiabilitatea software-ului.

În timp ce există mai multe cadre care oferă suport pentru testarea software automatizată, deschiderea către testare introduce un tip deosebit de eficient: Un cadru de testare automată cu sursă deschisă.

În acest cadru, elementele funcționale care alcătuiesc o aplicație sunt descrise folosind cuvinte cheie. Această abordare încurajează reutilizarea codului , utilizarea optimă a instrumentului și o mai mare productivitate.

Pentru a beneficia de performanțe maxime testarea automată are nevoie de o abordare bine definită bazată pe un cadru de lucru corespunzător.

Un cadru de testare este o structură ierarhică care înglobează resurse comune, cum ar fi librării dinamice comune, imagini, traduceri localizate, fișiere antet și ă documentație de referință într-un singur pachet.

Există mai multe tipuri de asemenea cadre pentru automatizare dar cel folosit în continuare este Cadru de automatizare bazat pe cuvinte cheie(Keyword Driven Automation Framework).

Testarea automată bazată pe cuvinte cheie este bazată pe ideea că funcționalitatea aplicației poate fi descrisă folosind cuvinte cheie. Prin crearea de cuvinte cheie care descriu funcționalitatea testării încep să creeze o librărie comună de cuvinte cheie care pot fi utilizate să creeze script-uri de testare.

Cadrul de testare automat bazat pe cuvinte cheie lucrează cu instrumentul de testare automată profesionala (HP QuickTest Professional). Acest cadru permite testărilor să creeze scenarii de test utilizând Microsoft Excel și o listă de cuvinte cheie. Când testul este executat cadrul procesează registrul de lucru Excel și apelează funcțiile asociate cuvintelor cheie definite în registrul de lucru Excel. Aceste funcții ale cuvintelor cheie execută acțiuni specifice în aplea codului , utilizarea optimă a instrumentului și o mai mare productivitate.

Pentru a beneficia de performanțe maxime testarea automată are nevoie de o abordare bine definită bazată pe un cadru de lucru corespunzător.

Un cadru de testare este o structură ierarhică care înglobează resurse comune, cum ar fi librării dinamice comune, imagini, traduceri localizate, fișiere antet și ă documentație de referință într-un singur pachet.

Există mai multe tipuri de asemenea cadre pentru automatizare dar cel folosit în continuare este Cadru de automatizare bazat pe cuvinte cheie(Keyword Driven Automation Framework).

Testarea automată bazată pe cuvinte cheie este bazată pe ideea că funcționalitatea aplicației poate fi descrisă folosind cuvinte cheie. Prin crearea de cuvinte cheie care descriu funcționalitatea testării încep să creeze o librărie comună de cuvinte cheie care pot fi utilizate să creeze script-uri de testare.

Cadrul de testare automat bazat pe cuvinte cheie lucrează cu instrumentul de testare automată profesionala (HP QuickTest Professional). Acest cadru permite testărilor să creeze scenarii de test utilizând Microsoft Excel și o listă de cuvinte cheie. Când testul este executat cadrul procesează registrul de lucru Excel și apelează funcțiile asociate cuvintelor cheie definite în registrul de lucru Excel. Aceste funcții ale cuvintelor cheie execută acțiuni specifice în aplicație pe care se testează. Cadrul interceptează cuvântul cheie și execută un set de declarații în program.

După setarea cadrului de testare aplicația poate fi testată automat fără a începe de la zero, testării trebuie doar să utilizeze cuvintele cheie independente ale aplicație și să creeze noi cuvinte cheie specifice aplicației.

Dintre caracteristicile cadrului putem enumera[HTTP1]:

utilizarea variabilelor: variabilele pot fi definite și utilizate în scripturile de test generate

verificare condițională: utilizarea instrucțiunii “if” poate fi implementată utilizând cuvinte cheie

testare bazată pe date: cadrul suportă tastarea bazată pe date prin importarea datelor dintr-un registru extern

raportare: rapoarte personalizate pot fi utilizate pentru o analiză eficientă

apelarea de funcții și reutilizarea acțiunilor: funcții și acțiuni comune pot fi apelate prin cuvinte cheie

introducerea de date de la tastatura

funcții de dată/timp

tratarea excepțiilor

tratarea obiectelor.

Beneficiile cadrului de testare automat sunt următoarele:

Reutilizabilitatea: cadrul de testare automată cu sursă deschisă este un cadru independent de aplicație care tratează cu toate posibilele acțiuni și cu verificări care pot fi aplicate pe un obiect. Deci codul pentru același obiect poate fi utilizat pe aplicații diferite. Duplicarea muncii este minimizată la orice nivel.

Utilizarea optimă a instrumentului: cadrul are avantajul de a utiliza cuvinte cheie ca date de intrare pentru a executa o acțiune. Acest cadru folosește caracteristicile instrumentului eficient. De exemplu QTP folosește un depozit comun de obiecte unde toate obiectele pot fi adăugate și reutilizate in scripturi pentru aplicația supusă testării.

Mai puțin efort depus: efortul necesar pentru a programa și a revizui este minim comparat cu alte cadre pentru că programarea se face direct în cadru. Testerul doar trebuie să introducă cuvintele cheie, reducând timpul necesar programării. Înregistrarea nu este de asemenea necesară pentru că un depozit global este utilizat.

Calitate sporită: scripturile vor avea aceeași calitate pentru că utilizează același cod.

Productivitate sporită: cadrul de testare automată cu sursă deschisă oferă atât beneficii calitative cât și cantitative pentru automatizare și sunt foarte productive comparate cu alte cadre. Acest cadru adresează mentenanța continuă a scripturilor într-o manieră rentabilă

Mentenanță: simple modificări ale aplicației pot fi ușor manipulate in cod. Schimbările vor fi efectuate doar în fișierul extern care conține codul și scripturile nu trebuie schimbate. Prin urmare este ușor să menții scripturile de test și furnizează o soluție rentabilă pentru testarea automată.

Nu sunt necesare de utilizatorul final: nu sunt necesare aptitudini pentru a crea și revizui scripturile automate. Scripturile pot fi interpretate ușor de către o persoană care nu deține cunoștințe complete ale instrumentului.

Întoarcerea investiției este ridicată: cu toate că investiția inițială pentru a crea cadrul este mare, în termen lung întoarcerea investiției va fi mare datorită reutilizării și utilizării optime a instrumentului.

Un cadrul de lucru este compus din următoarele componente:

Cadrul care este compus din următoarele sub componente:

Librăria de funcții

Funcții comune.

Stratul abstract care este compus din următoarele sub componente:

Depozitul de obiecte

Scriptul de conducere

Cuvinte cheie.

Date externe care este compus din următoarele sub componente:

Registre de date

Variabile globale

Fig. 1 Arhitectura cadrului de testare automat

Scriptul de conducere ghidează execuția scripturilor. Este format din doar câteva linii de cod in fereastra principală a instrumentului de testare rapidă care invocă sincronizarea cuvintelor cheie cu cadrul și depozitul de obiecte. Acest script apelează funcții din librăria de funcții, care citește cuvintele cheie, obiectele și parametri și execută acțiunile adecvate per funcțiile din librăria de funcții. Incorporând scriptul de conducere cu cadrul într-o funcție separată efortul necesar de creare a scriptului de conducere este redus. O apelare a funcției va înlocui scriptul de conducere.

Librăria de funcții este de fapt coloana vertebrală a cadrului de automatizare. Toată logica din cod este într-o formă de script VB creat de utilizator. Toate aceste funcții sunt stocate in librăria de funcții. Este locul unde majoritatea scripturilor sunt situate și locul unde se pot personaliza în scripturile pentru proiect. Librăria de funcții este singura componentă a cadrului care trebuie schimbată în cazul în care aplicația se migrează de pe o platformă pe alta. Adăugarea și ștergerea de funcții face cadrul destul de flexibil pentru a fi folosit de orice altă aplicație.

Funcțiile comune sunt funcțiile care se pot reutiliza pe toate platformele. Aceste funcții sunt independente de aplicații și nu depind de tehnologia care a fost utilizată pentru a crea aplicația. Separarea funcțiilor comune de librăria de funcții asigură utilizarea maximă a scripturilor reutilizabile și reduce efortul de mentenanță a scripturilor. Unele din funcțiile comune pot include funcții condiționale, funcții repetitive etc.

Depozitul de obiecte este locul unde instrumentul profesional rapid de testare recunoaște ;i stochează informația ca proprietăți, valori etc. Instrumentul învață interfața unei aplicații prin recunoașterea obiectelor aplicației și valorile proprietăților corespondente și descrierea lor. Cu depozitul de obiecte, instrumentul identifică aplicația și execută scenariile ca și funcțiile din scriptul de test. Dacă una sau mai multe proprietăți în aplicație diferă fațade valorile stocate în depozitul de obiecte instrumentul nu va identifica obiectul și scriptul va eșua. Prin urmare este necesar să schimbi valorile proprietăților în depozitul de obiecte dacă diferă de cele din aplicație.

Aceste obiecte pot fi stocate în două tipuri de depozite de obiecte:

Depozit de obiecte partajat – obiectele stocate într-un fișier care pot fi partajate și accesate de teste multiple (doar pentru citire)

Depozit de obiecte local – obiectele sunt stocate într-un fișier care sunt legate de o singură acțiune, așadar doar o acțiune(script) poate accesa obiectele stocate.

O combinație între cele două tipuri de depozite poate fi de asemenea utilizată. Se recomandă să se păstreze un depozit de obiecte partajat care sa fie utilizat de mai multe cazuri de testare.

Cuvintele cheie declanșează funcții specifice în cadru să execute o operație specifică pe obiectul dorit în aplicație. Aceste cuvinte cheie sunt introduse în tabelul de date ale instrumentului profesional rapid de testare care apoi va fi introdus de scriptul de conducere. Tabelul de date conține cuvintele cheie care descriu acțiunile dorite. Ideal cuvintele cheie ar trebui scrie în așa mod ca să fie recunoscute și potrivite pentru testarea manuală. Obținând această capabilitate putem crea un caz de testare pentru testele și manuale și automate. Această proprietate face cadrul de testare bazat pe cuvinte cheie puternic.

Variabile globale trebuie utilizate de toate cazurile de testare și trebuie să fie definite și păstrate într-un loc comun și trebuie furnizate ca intrare pentru cadru de testare.

1.3 Descrierea și utilizarea Centrului de calitate(Quality Center)

Centrul de calitate (Quality Center) simplifică și organizează gestionarea sistematică asupra produsului. Fiind accesibil pe internet, acesta sprijină nivelul ridicat de comunicare între diferite părți interesate (analiști de afaceri, programatori, testări, etc ), acesta este la nivel mondial cel mai eficient și eficace proces de testare. Se pot integra instrumente de automatizare cum ar fi QTP, Ranorex, Selenium cu QC-ul, dar se pot crea de asemenea rapoarte și grafice de analiză și de urmărire pentru procesele de testare.

Fig2. Arhitectura comunicării Centrul de Calitate cu utilizatorii

Pentru a deschide Centrul de Calitate trebuie să[Http10]:

1.Deschide navigatorul tău de internet și tastează adresa pentru CC

http://<Quality Center server name>[<:port number>]/qcbin

Fereastra de opțiuni HP CC se va deschide

2. Selectează adresa pentru Centrul de Calitate

La prima deschidere a Centrului de Calitate pe mașină se vor descărca fișiere necesare lucrului cu CC-ul:

Fig3. Interfața Centrului de Calitate

3 Furnizează numele în căsuța de utilizator (Login Name)

4 În căsuța de parolă(Password) tastează parola

5 Acționează butonul de autentificare. Centrul de calitate va verifica numele și parola pentru a determina proiectul și domeniul care poate fi accesat.

6 Selectează un Domeniu din lista afișată

7 Din lista proiectelor selectează un proiect

8 Acționează butonul de autentificare (Login) pentru a te conecta la QC

Fig4. Fereastra de conectare la Centrul de Calitate

Centrul de Calitate este un proces complex, acesta presupune măsuri corelate de proiectare și validare a testelor, monitorizarea și raportarea defectelor.

Acesta simplifică și organizează gestionarea produsului, definește și menține o bază de date a proiectului, oferă o metodă intuitivă și eficientă pentru programarea și executarea seturilor de teste, rezultatele testelor, precum și analiza datelor

Fig5. Interfața Centrului de Calitate

Centrul de calitate are, de asemenea, un sistem sofisticat de urmărire a defectelor, permițând monitorizarea îndeaproape de la detectarea inițială a acestora până la soluționarea lor.

Acesta oferă integrarea cu instrumentele de testare HP(WinRunner,QuickTest Professional, LoadRunner, și Visual API-XP ). El comunică cu instrumentul de testare ales oferind o soluție completă de automatizare a testului.

Procesul de management al CC-ului implică următoarele faze:

Fig.6 Arhitectura Centrului de Calitate

Specify Releases: Dezvoltarea unui plan de eliberare a managementului

Specify Requirements: Analizarea, crearea și determinarea cerințele asociate

Plan Tests: Crearea un plan de testare bazat pe cerințele date

Execute Tests: Creare seturi de teste și rularea acestora

Track Defects: Raportarea erorile detectate și urmărirea evoluției acestora

1.4 Instrumentul de testare profesională rapidă automată(QuickTest Professional)

Avansata soluție de testare automată pentru testarea funcțională și de regresie. Acest instrument de testare de ultimă generație implementează conceptul de testare bazat pe cuvinte cheie pentru a spori crearea de teste și întreținere testelor. Testarea pe bază de cuvinte cheie este o tehnică care separă o mare parte din munca de programare de la etapele de efective de încercare, astfel încât etapele de testare pot fi dezvoltate mai devreme și pot fi adesea menținută cu modificări minore, chiar și atunci când există schimbări semnificative în aplicație sau în nevoile tale de testare.

Instrumentul oferă următoarele funcționalități :

Folosind abordarea bazată pe cuvinte cheie , experți de automatizare de testare au acces total la cele care stau la baza de testare și proprietățile obiectelor, printr-o abordare integrată codare și mediu de depanare, care este tur-retur sincronizat cu ecranul de cuvinte cheie.

Satisface nevoile atât tehnice cât și cele ale utilizatorilor non-tehnici. Acesta funcționează integrat cu HP Business Process. Testarea aduce într-un mod important pe experții non-tehnici în procesul de calitate. În plus se împuternicește întreaga echipă să creeze cazuri de testare sofisticate.

Oferă integrare cu soluții care permit să testăm obiecte (de control), create în medii de dezvoltare utilizate în mod obișnuit.

Cele 6 etape ale procesului de testare sunt afișate în figura 7.

Aceste etape sunt:

Etapa 1: Analizarea aplicației

Etapa 2: Pregătirea infrastructurii de testare

Etapa 3: Adăugarea de pași la acțiuni

Etapa 4: Dezvoltarea testelor

Etapa 5: Rularea și depanarea testelor

Etapa 6: Analizarea rezultatelor și raportarea defectelor.[VIN12]

Fig.7 Etapele procesului de testare

1.5 Platforma de dezvoltare a aplicației(C#)

În luna iulie anul 2000 Microsoft introducea pentru prima dată limbajul C#, acesta făcând parte a platformei .Net. Această platformă în esență era un nou cadru de dezvoltare care oferea o nouă interfață API de programare aplicațiilor.[Lib02]. Limbajul e este unu simplu, modern orientat pe obiecte și conceput pentru dezvoltarea aplicațiilor care să ruleze pe platforma .Net. Limbajul C# combină productivitatea limbajelor de dezvoltare rapidă cu puterea brută a limbajului C++.

Codul C# beneficiază de serviciile CLR ceea ce înseamnă că este compilat ca și cod de bază. Aceste servicii includ interoperabilitatea limbajelor, colecționarul de gunoi, securitate ridicată și suportul versiunilor îmbunătățite.

Două categorii de date principale există în C# și anume :tipuri referință și tipuri valoare. Diferența dintre ele este că variabilele de tip referință conțin referințe spre datele propriu-zise, care se află situate în memoria heap, pe când variabilele de tip valoare conțin normal valorile lor efective. La apeluri de funcții sau la atribuiri aceste deosebiri se observă. Conținutul unei variabile este duplicat în variabila destinație la atribuirile care implică tipuri valoare. Structurile și enumerările sunt tipuri valoare. Clasele, interfețele, tablourile și delegările sunt tipuri referință.

Referința spre un obiect este duplicată la o atribuire care implică tipuri referință dar obiectul este doar unu, are loc fenomenul cunoscut sub numele de leasing și anume mai multe nume pentru același obiect. Conținutul unei variabile este duplicat în variabila destinație la o atribuire care implică tipuri valoare.

Surprinzător sau nu unele din tipurile cu care eram obișnuiți din C cum ar fi int sunt tot structuri iar altele, string de exemplu sunt clase. În C# sunt mai speciale pentru că la compilare textul din codul sursă este convertit și identificat automat în instanțe ale acelor tipuri. Există cuvinte cheie în C# pentru aceste tipuri prin care sunt descrise, dar și clase în .Net care reprezintă implementarea propriu zisă.

Am ales acest mediu de programare deoarece oferă o abordare nouă în programarea orientată pe obiecte și facilitează crearea rapidă de aplicații sistem și până la aplicații comerciale de nivel înalt. Un alt motiv este designul elegant a mediului de programare și a facilităților aduse de acesta față de alte medii de programare.

Capitolul 2. Specificațiile aplicației

Pentru fiecare proiect este foarte importantă alegerea unor instrumente de automatizare. În realitate însă, un singur instrument de automatizare nu poate acoperi toate cerințele fiecărui proiect, motiv pentru care sunt luate în considerare mai multe instrumente de automatizare pentru a crea un test automat în cadrul unui proiect.

Pentru fiecare instrument de automatizare, testerul are nevoie sa stăpânească următoarele:

– Limbajul de programare utilizat

– Condițiile de utilizare impuse de instrument.

Altfel spus testerul trebuie să cunoască cea mai bună metodă de a folosi eficient fiecare instrument de automatizare.

Aplicația TestEditor&Executor oferă un limbaj comun de automatizare de testare și un set de instrumente comune (cuvinte cheie de conducere), independent de dezvoltarea tehnologiei și de instrumentul de testare automată, oferind testărilor non-tehnici capacitatea de a crea teste automate. Aceasta acționează ca o interfață comună care poate fi folosită pentru a opera fiecare instrument, având același flux de lucru pentru crearea, deschiderea, salvarea sau rularea testelor.

Logica acestei aplicații se bazează pe faptul că fiecare eveniment într-o aplicație poate fi descris folosind o descriere scurtă (cuvinte cheie) și o listă de valori asociate parametrilor (argumente). De exemplu cele mai multe aplicații necesită un utilizator pentru autentificare. În acest caz "Login User" poate fi definit de următoarele argumente: UserID și UserPassword.

Controlul și punerea în aplicare a cuvintelor cheie necesită definirea unui cadru de testare (limbajul) care va reprezenta baza creării testelor automate.

Deoarece aplicația de automatizare ce folosește cuvinte cheie de conducere separă activitatea de programare de cea de automatizarea de teste, de la actualul design de testare se pot identifica doua tipuri de roluri:

– rolul expertului de automatizare care dezvoltă, menține și extinde cadrul de cuvinte cheie

– rolul expertului în produs care utilizează doar cadrul de lucru pentru a crea scenarii de teste automate.

Rolurile identificate sunt prezentate în următoarea figură:

Fig.8 Rolurile prezente în aplicație

Aplicația TestEditor&Executor oferă mijloacele pentru a:

– îmbunătăți comunicarea dintre testări( având un limbaj comun)

– începerea automatizării mai devreme

– menține și gestionează testele automate

2.1. Salvarea testelor pe Local/Centrul de Calitate

Scenariu:

Precondiții:

1. Utilizatorul trebui să aibă acces și drepturi la proiectul de pe Centrul de Calitate

2. Trebuie realizată Configurarea

Pași de urmat:

1. Testerul trebuie să se autentifice la instrumentul de automatizare

1.1 El/Ea poate alege să descarce resursele pentru cuvintele cheie sau pot alege să folosească resursele deja disponibile

2. Optează pentru a crea un nou test

3.Din acest moment, arhitectura cuvintelor cheie este disponibilă în GUI și poate fi folosită pentru a crea teste (cuvintele cheie pot fi adăugate, editate sau șterse din cadrul unui test)

4. După ce testul a fost creat trebuie salvat fie pe mașina locală fie direct pe Centrul de Calitate

5. Numai după ce un test a fost salvat acesta poate fi rulat

6. După rularea testului rezultatele acestuia pot fi vizualizate

Fig.9 Structurarea pașilor pentru crearea unui test

2.2. Rularea testelor stocate pe Centrul de Calitate (sau a întregului test set)

Scenariu:

Precondiții:

1. Testul ce conține cuvintele cheie trebuie să fie stocat pe Centrul de Calitate

2. Testerul trebuie să fie înregistrat în aplicație

Pași de urmat:

1. Testerul alege să facă operațiuni pe testul salvat în fila de Test Plan de pe Centrul de Calitate, poate deschide sau rula teste direct din fereastra de Centrul de Calitate)

2. El/Ea trebuie să adauge testul creat anterior în fila de TestLab într-un folder care conține un set de test

3.În acest moment testele selectate din test set pot fi bifate/nebifate și se poate schimba gazda pentru fiecare test set

4. Testerul poate fie să ruleze testele selectate fie să ruleze întreg test setul (fiecare test va fi rulat pe gazda specificată)

5. Vizualizarea rezultatelor testelor rulate poate fi accesată din GUI și va fi stocată pe Centrul de Calitate

Fig.10 Structurarea pașilor necesari pentru identificarea oportunităților de operare cu testele stocate pe Centrul de Calitate

2.3. Rularea testelor direct de pe Centrul de Calitate

Scenariu:

Precondiții:

1. Utilizatorul trebuie să fie înregistrat pe Centrul de Calitate

2. Testul ce conține cuvintele cheie trebuie să fie salvat în fila de testLab din Centrul de Calitate

Pași de urmat:

1. Testerul trebuie să selecteze testele

2. Testerul acționează butonul de Pornire

3. Rularea testului începe iar după încheierea acesteia rezultatele testului vor fi actualizate pe Centrul de Calitate

4. Un raport detaliat al testului rulat va putea fi vizualizat deschizând atașamentul asociat testului rulat

Fig.11 Structurarea pașilor necesari pentru rularea testelor direct de pe Centrul de Calitate

2.4. Crearea de valori multiple de intrări de date pentru teste

Scenariu:

Precondiții:

1. Un test ce conține cuvinte cheie trebuie să fie deja creat

2. Testerul trebuie să fie înregistrat la aplicație

Pași de urmat:

1. Testerul trebuie să deschidă testul

2. Acționează butonul de Data Input Generator

3. Din acest moment el/el poate administra seturile de intrări de date pentru test( poate adaugă un set de date, edita un set creat anterior sau poate șterge un set de date)

4. După ce această operațiune a fost salvată testul este pregătit pentru executare și poate fi rulat pentru fiecare set de date disponibil testului

5. Se pot vizualiza rezultatele pentru fiecare set de date disponibil

Fig.12 Structurarea pașilor necesari pentru a crea noi seturi de date de intrare pentru un test

Capitolul 3. Proiectarea de detaliu

Nucleul aplicației este partea care se ocupă cu realizarea interfeței și chemarea celorlalte clase cu scopul de a crea, rula noi teste.

Pentru a evita utilizarea de variabile globale s-au implementat mai multe clase și funcții care să înlocuiască această necesitate.

Pentru a considera un folder ca fiind un test de cuvinte cheie acesta trebuie să conțină un fișier text care să conțină numele tuturor cuvintelor cheie din cadrul testului, un fișier Excel care va conține informații despre numele cuvintelor cheie din test împreună cu informații despre parametrii funcției(acest fișier va conține atâtea file câte inputuri de intrări de date se vor crea pentru test) și un fișier xml sau mai multe, în funcție de numărul de set-uri de intrări de date corespunzătoare testului.

Aceste funcții sunt:

• public void SaveXLS(String Path, RichTextBox command_rtb, int x, int y, Test test, bool deleteLocal) –parametrii funcției reprezintă calea unde va fi salvat, o variabilă ce va identifica cuvântul cheie inserat, coordonatele acestuia, informații detaliate despre cuvântul cheie inserat și o variabilă logică care va oferi informații referitoare la starea fișierului(salvat sau nu) ce creează fișiere Excel de forma:

• public void SaveXML(String Path, Test test)- parametrii reprezintă calea unde se va salva fișierul și o variabilă de tipul Test ce conține informații referitoare la lista de cuvinte cheie inserate in test

• public void SaveTXT(String Path, RichTextBox command_rtb, int rtb_CommandsBox_RowsCount, bool value) – parametrii funcției reprezintă calea unde va fi salvat fișierul, o variabilă de tipul RichTextBox cu ajutorul căreia se vor citi cuvintele cheie introduse, o variabilă ce va număra indexul cuvântului cheie și o variabilă de tipul logic care va conține starea fișierului, salvat sau nu.

În realizarea aplicației s-au folosit mai multe clase dar cele mai importante dintre ele cât și legătura acestora și legătura cu instrumentul de automatizare și cel de gestionare este prezentată în schema de mai jos:

Fig13. Structurarea claselor principale și comunicarea cu instrumentele de automatizare

Astfel că MainUI reprezintă liantul dintre clasele utilizate, aici realizându-se comunicațiile dintre acestea, definirea fișierelor ce vor defini testul bazat pe cuvinte cheie. Clasa Configuration configurează testul, punându-i calea, instrumentul de automatizare folosit cât și crearea de noi tipuri de date; XML Generator se regăsește în clasa CreateXML care pregătește resursele de pe Quality Center pentru a putea fi utilate de către aplicație, adică transformă fișierele de extensie vbs sau qfl în fișiere xml.

Clasa Test deține informații despre conținutul testului(informații despre parametrii funcțiilor și cuvintelor cheie utilizate) și despre tipul locației, local sau pe Quality Center.

Comunicarea cu instrumentele de automatizare se face în cadrul clasei MainUI acestea fiind apelate la rularea de teste. Distingerea instrumentelor de automatizare este făcută la nivelul clasei Configuration, la alegerea instrumentului de automatizare.

3.1. Arhitectura aplicației

Aplicația este un editor de teste și executor de instrumente care asigură comunicarea între instrumentul de gestionare, instrumentul actual de automatizare și cadrul de testare Open2Test, folosit pentru a rula cuvintele cheie.

Fig14.a) Arhitectura instrumentelor utilizate

Următoarea schemă reprezintă pe culori tehnologia implementată și utilizată de către aplicație din lucrare. Astfel cu albastru reprezintă componentele implementate de către aplicația TestEditor and Executor, cu mov instrumentul de automatizare, roșu reprezentată produsul testat, iar gri reprezintă instrumentul de management împreună cu librăriile de funcții necesare și interpretorul de rezultate generat de către instrumentul de automatizare și reinterpretat în aplicația prezentată.

Fig14.b) Schema bloc a componentei de automatizare a interfeței vizuale

3.2. Implementarea Centrului de Calitate la nivelul aplicației

Pentru a utiliza aplicația la nivel global a fost nevoie de păstrarea resurselor și a scripturilor necesare pentru utilizarea instrumentului de automatizare, QTP, pe Quality Center. Astfel în cadrul aplicației se vor regăsi funcții care vor imita modul de lucru găsit pe Quality Center și care se vor realiza accesul utilizatorul la un proiect la care are acces.

public static TDAPIOLELib.TDConnection con = new TDAPIOLELib.TDConnection();

– clasa TDAPIOLELib reprezintă obiectul de lucru cu QC-ul, iar TDAPIOLELib.TDConnection conține câmpurile necesare pentru conectarea la Quality Center

Câteva exemple de funcții și butonae care implementează modul de lucru cu QC-ul sunt:

• public void btnLogin_Click(object sender, EventArgs e)

{…

xmlDoc.Load(Directory.GetCurrentDirectory() +"\\Resources\\configuration.xml");

XmlNode node = xmlDoc.SelectSingleNode("Configuration/LocalFolder");

whereToDownload = node.InnerText;

pass = txtBoxPassword.Text;

…

con.ConnectProjectEx(cboDomain.SelectedItem.ToString(), cboProject.SelectedItem.ToString(), txtBoxUser.Text, txtBoxPassword.Text);

..

if (checkBox1.Checked == true)

{

downloadResources(whereToDownload);

}

…..

– în cadrul acestui buton se realizează conexiunea la QC, se citește xml-ul de configurare al testului pentru a ști calea unde se vor descărca resursele și se ulterior se vor și descărca resursele

• private void fillTreeTestLab(TreeNode FolderParentNode, TreeNode TestSetNode, List SubNodes, List TestSetList) {

foreach (TestSetFolder tf in SubNodes)

{

TreeNode FolderKidNode = FolderParentNode.Nodes.Add(tf.Name);

TestSetNode = FolderKidNode;

.…

fillTreeTestLab(FolderKidNode, TestSetNode, tf.SubNodes, TestSetList);

– este o funcție recursivă care caută în fila de TestLab din Quality Center directoarele și subdirectoare pentru ca întreg arborele de directoare să fie vizibil în TreeView-ul din aplicație. Se face o căutare succesivă în toate nodurile și sub-nodurile arborelui din Quality Center și se adaugă rezultatele în nodurile arborelui(TreeNode)

• private void buttonRefreshTestPlan(object sender, EventArgs e)

{

string path = "Subject";

TreeNode rootNode = treeView2.Nodes.Add(path);

bool isConnected = Connect.con.Connected;

if (isConnected)

{

TreeManager TreeMgr = (TreeManager)Connect.con.TreeManager;

SubjectNode tpFolder = (SubjectNode)TreeMgr.get_NodeById(2);

fillTreeTestPlan(rootNode, tpFolder);- la acționarea acestui buton se actualizează rezultatele afișate in TreeView-ul aplicației apelând funcția fillTreeTestPlan explicată mai sus. Se inițializează calea cu primul nod din lista de TestPlan și daca conexiunea la Quality Center este încă validă atunci se vor căuta copii nodului Subject cu ajutorul funcției fillTreeTestPlan

• private void fillTreeTestPlan(TreeNode currentTreeFolder, SubjectNode currentTPFolder)

{

TestFactory objTF = (TestFactory)currentTPFolder.TestFactory;

foreach (TDAPIOLELib.Test objTest in objTF.NewList(""))

{

TreeNode tn = new TreeNode();

tn.Text = objTest.Name.ToString();

tn.Tag = objTest;

string Field = (string)objTest["TS_USER_01"];

if (Field == "Yes")

{

currentTreeFolder.Nodes.Add(tn);

}

}

… fillTreeTestPlan(nodSubFolder,(SubjectNode)currTPFolder.get_Child(i));

– această funcție recursivă caută testele din Quality Center care sunt bazate pe cuvinte cheie, caută de fapt valoarea câmpul keyword, codificat în QC ca "TS_USER_01", iar testele care îndeplinesc această condiție vor fi afișate în TreeView-ul relaționat cu fila de TestPlan din QC.

• private void treeViewBeforeExpand(object sender, TreeViewCancelEventArgs e)

{……

foreach (TreeNode tn in treeView2.SelectedNode.Nodes)

{

if (tn.Text == objTest.Name)

{

string Field = (string)objTest["TS_USER_01"];

if (Field == "Yes")

{

tn.ImageIndex = 2;

tn.SelectedImageIndex = 2;

}

else

{

tn.ImageIndex = 3;

tn.SelectedImageIndex = 3;

-acest eveniment verifică daca testul este unul bazat pe cuvinte cheie, iar in caz pozitiv îi va asocia o imagine de test în TreeView, iar în caz contra îi va asocia o imagine de folder obișnuit

3.3. Utilizarea Instrumentului de testare automată rapid QTP în aplicație

Pentru rularea testelor selectate se va crea un obiect de tip QTP care va deschide instrumental de automatizare și va crea un nou test căruia îi vor fi adăugate obiectele din depozit și funcțiile din librăria de funcții, stocate pe Quality Center. Apoi se vor face anumite setări de QTP pentru o maximizare de performanța.

Utilizarea QTP s-a realizat într-un VBScript care conține funcții pentru fiecare pas de execuție al testului cât și pentru resursele necesare acestuia[BHA13]:

• Public Function ApplyXSL(ByVal inputXML, ByVal inputXSL, ByVal outputFile)

…

xslDoc.load inputXSL

xmlDoc.load inputXML

outputText = xmlDoc.transformNode(xslDoc.documentElement)

Set FSO = CreateObject("Scripting.FileSystemObject")

Set outFile = FSO.CreateTextFile(outputFile,True)

– această funcție încarcă în QTP fișierele xml și xls ale testului și creează un fișier text secvențial cu ajutorul căruia generează un nume testului[THO13]

• Sub AttachLibrary(Folder,qtpLibraries)

For Each objFile in Folder.Files

If ((InStr(1,objFile.Name,"vbs",1) <> 0) Or (InStr(1,objFile.Name,"qfl",1) <> 0)) Then

If qtpLibraries.Find(objFile.Path) = -1 Then

qtpLibraries.Add objFile.Path, 1 – această procedură este folosită pentru a atașa testului funcțiile din librăria de funcții disponibilă pe Quality Center

• Sub AddRepository(Folder,qtpRepositories)

For Each objFile in Folder.Files

If (InStr(1,objFile.Name,"tsr",1) <> 0) Then

If qtpRepositories.Find(repositoryName) = -1 Then

qtpRepositories.Add objFile.Path, 1 – procedura descarcă de pe Quality Center depozitele de obiecte aflate în directorul de resurse

• Public Function StartTemplateTest(strFolder,actionName1,actionName2)

Dim qtpObj

Dim qtpLibraries

Dim qtpRepositories

Set objFSO = CreateObject("Scripting.FileSystemObject")

Set qtpObj = CreateObject("QuickTest.Application") – aceasta este funcția care rulează efectiv testul după ce toate resursele necesare acestuia au fost adăugate în QTP. Primul parametru reprezintă testul selectat, al doilea și al treilea parametri sunt folosiți pentru a folosi cadrul de test Open2Test, creează de fapt cele două file necesare acestui, Action1 și Global cu ajutorul cărora se vor itera acțiunile testului și se vor încărca cuvintele cheie împreună cu parametrii acestuia

3.4 Tehnologia XML

Pentru a lucra mai ușor cu fluxul de date necesar în aplicație s-a implementat convertirea extensiilor fișierelor de lucru, .qfl și .vbs în extensii .xml.

Fișierele xml nu au o structură specific, însă folosesc un set de reguli de bază. Regulile xml pot fi folosite să restricționeze structura tipurilor de date. Structura este de tip descriptivă și fiecare dată are asociat un antet pentru descrierea acesteia.

În cazul de fată resursele utilizate necesită un antet pentru a putea fi convertii în fișiere de tip xml.

‘@===========================================================

‘@Keyword:Keyword_Name

‘@Description:A short description of the keyword

‘@associatedFunction:FunctionName

‘@Param:Type->Name (or empty if there are no parameters)

‘@Return:Type(or empty if there is no return)

‘@===========================================================

Unde” keyword” reprezintă numele cheie după care va fi recunoscută funcția ce va fi utilizată, “Description” reprezintă descrierea funcției, “associatedFunction” reprezintă numele real al funcției utilizate, “Param” reprezintă parametrii utilizați de către funcție(Type¬- tipul parametrului și Name- numele acestuia), iar “Return” reprezintă valoarea rezultată în urma apelării funcției.

Xml-ul rezultat pe baza antetului va avea următoarea structură:

<?xml version=”1.0” encoding=”UTF-8”?>

<keywords>

<ConcatTwoStrings Description=”Function that shows in a messagebox the text provided as a parameter” category=”GeneralUse”>

<signature associatedFunction=”ShowTextFromConcat” Return=”string”>

<Params>

<text>string</text>

<var>string</var>

</Params>

</signature>

</ConcatTwoStrings>

</keywords>

Funcția de creare de fișiere xml testează dacă resursele nu fac parte din lista de constante pentru a selecta cuvintele cheie necesare creării unui test :

public void XML()

{ XmlDocument doc = new XmlDocument();

s5 = Path.GetFileNameWithoutExtension(s12);

bool constant = s5.Contains("Const");

if (s5.Contains(" "))

{

s5.Replace(" ", "_");

}

if (constant == false)

{

XmlNode docNode = doc.CreateXmlDeclaration("1.0", "UTF-8", null); doc.AppendChild(docNode);

XmlNode productsNode = doc.CreateElement("keywords");

doc.AppendChild(productsNode);

….

Capitolul 4. Utilizarea aplicației

4.1 Pre-rechizite necesare

Pre-rechizite

Pentru a crea un mediu de testare adecvat trebuie urmărită o lista de măsuri:

1. Pe mașina locală :

– asigurați-vă că utilizatorul care folosește aplicația are drepturi administrative

– asigurați-vă că programul implicit pentru rularea scripturilor este wscript

– instalați Microsoft Office Word și Microsoft Office Excel pe mașina utilizată

– instalați instrumentele de rularea necesare (QTP)

– deschideți Quality Center ( pentru a avea OTAClient.dll )

2. Pentru instrumentul de teste bazate pe cuvinte cheie:

– configurați instrumentul folosit pentru automatizarea efectivă și care cadru de testare al cuvintelor cheie va fi folosit

3. Pentru Quality Center:

– trebuie definite patru câmpuri (acestea sunt folosite de către aplicația de automatizare pentru a putea identifica dacă testul este unul bazat pe cuvinte cheie si care pe care instrument va rula testul actual și cu ce versiune de cadru de testare a fost creat)

Fig15. Tabelul câmpurilor necesare pentru identificarea unui

test bazat pe cuvinte cheie în Centrul de Calitate

Fig16. Personalizarea câmpurilor unui test în cadrul unui proiect

– resursele testului vor fi stocate pe Quality Center în fila Test Resources; dosarul de resurse trebuie să fie configurat în instrumentul de automatizare

– resursele cadrului de testare Open2Test și instrumentul care procesează resursele trebuie să fie de asemenea stocate în fila de Test Resources ( fișierele ce trebuie încărcate pe Quality Center sunt următoarele: CreateXML.exe pentru creare de fișiere xml ,QTP_Windows_v1.01.vbs și User_Defined_Functions_v1.00.vbs pentru utilizarea cadrului de testare)

Fig17. Relaționarea structurii ierarhice de dosare de resurse

din Centrul de Calitate cu aplicația de automatizare

– fiecare funcție din fișierele de resurse reprezintă un cuvânt cheie dacă are un antet asociat; antetul are următoarea structură:

'@===========================================================

'@Keyword:Keyword_Name

'@Description:A short description of the keyword

'@associatedFunction:FunctionName

'@Param:Type->Name (or empty if there are no parameters)

'@Return:Type(or empty if there is no return)

'@===========================================================

– o resursă care conține constante trebuie să aibă un nume care să conțină cuvântul "constant" pentru ca aplicația de automatizare a testelor să poată utiliza constantele definite în interiorul unei resurse

4.2 Rularea aplicației si conectarea la centrul de calitate

Rularea aplicației se poate face doar după ce pre-rechizitele au fost efectuate.

Lista funcționalităților disponibile este restricționată de o înregistrare validă. Pentru a realiza acest lucru trebuie prevăzute informații valide pentru conectare cu Quality Center.

După ce primul set de informații a fost introdus corect (Quality Center URL, numele utilizatorului, parola) și butonul de connect a fost acționat o listă cu domeniile si proiectele la care utilizatorul are acces vor fi disponibile în câmpul corespunzător).

După ce un domeniu și un proiect au fost alese corect utilizatorul trebuie să acționeze butonul de Login pentru a fi înregistrat în aplicația de automatizare și pentru a avea acces la caracteristicile acestuia.

Fig18. Reprezentarea butonul de conectare din bara de instrumente

Fig19. Interfața ferestrei de conectare la centrul de calitate

4.3 Configurarea aplicației

Această caracteristică trebuie utilizată înainte de realizarea conexiunii cu Quality Center pentru a face legătura între resursele cuvintelor cheie stocate pe Quality Center și aplicația de automatizare:

– instrumentul de automatizare a testelor trebuie specificat

– trebuie specificată versiunea cadrului de testare care se dorește pentru utilizare

– locația unde se dorește ca resursele să fie salvate

Al doilea panou din fereastra de adresare a Configurării se referă la facilitatea creării de date. Pentru fiecare proiect personalizat se pot defini pentru tipuri de date uzuale pentru a restrânge lista de valori care poate fi aplicată la un parametru/variabilă( de exemplu, orientarea nu este necesar să fie un sir, deoarece aceasta are numai portret și peisaj ca valori)

Fig20. Reprezentarea butonului de configurare în bara de instrumente

Fig21. Interfața configurării aplicației

4.4 Crearea testelor

Pentru a crea noi test trebuie doar apăsat pe primul buton din bara de instrumente.

Fig22. Reprezentarea butonului de creare a unui nou test din bara de instrumente

GUI-ul pentru creare testelor este simplu. Lista cuvintelor cheie disponibile este împărțită în două câmpuri:

– comboboxul Category are două opțiuni: Generic sau ProjectSpecific

– câmpul de SubCategory conține resursele disponibile asociate câmpului Category

După ce au fost alese valori pentru aceste câmpuri lista cuvintelor cheie disponibile (din lista afișată în comboboxul Keywords) este restricționată de alegerile făcute.

GUI-ul principal este alcătuit din două file: una este cea de Workflow care conține doar lista cuvintelor cheie utilizate în creare testului, iar a doua este cea de Parameter care conține informații privind argumentele cuvintelor cheie utilizate. Pentru testele care conțin mai mult de un cuvânt cheie, dacă este selectată a doua filă va fi furnizată o listă cu argumente( pentru cuvintele cheie disponibile).

Cu un dublu click pe un cuvânt cheie deja adăugat pot fi vizualizate informații specifice (va fi afișată o fereastră cu toți parametrii cuvântului cheie selectat inclusiv cu tipul de întoarcere al cuvântului cheie).

Fig23. Reprezentarea creării unui nou test bazat pe cuvinte cheie

Adăugarea/Ștergerea cuvintelor cheie la un test se poate realiza folosind butonul Insert/Delete.

Pentru inserarea unui cuvânt cheie poziția inserării noului cuvânt cheie trebuie precizată printr-un click în fata cuvântului cheie unde se dorește inserare în fila de Workflow, iar pentru ștergere este necesar un click stânga urmat de un click dreapta pentru a selecta cuvântul cheie ce se dorește a fi șters.

Fig24. Reprezentarea inserării unui cuvânt cheie

Fig25. Reprezentarea ștergerii unui cuvânt cheie

Pentru fiecare parametru al unui cuvânt cheie există trei posibilități de alegere a valorii dorite:

– Manual Input – pentru cazul în care testerul dorește să introducă manual valoarea dorită

– Link – pentru cazul în care valoarea necesită utilizarea valorii de întoarcere a unui alt cuvânt cheie sau necesită utilizarea unei constante din lista de constante

– Random – în cazul în care este necesară folosirea unei valori aleatorii

Fig26. Reprezentarea alegerii valorii parametrului

Fig27. Interfața tipurilor de date introduse de utilizator Linking(Legătură)

4.5 Salvarea testelor

După ce un test a fost creat sau actualizat acesta poate fi salvat acționând butonul de Save, alegând apoi salvarea lui pe mașina locală sau pe Quality Center.

Fig28. Reprezentarea butonului de salvare pe bara de instrumente

Fig29. Reprezentarea dialogului de salvare

4.6 Deschiderea testelor

Numai testele bazate pe cuvinte cheie deja salvate pot fi deschise din locația lor(mașina locală sau Quality Center).

Fig30. Reprezentarea butonului de deschidere a testelor

Fig31. Fereastra de deschidere a unui test

4.7 Generarea de date de intrare

Caracteristica generatorul de date de intrare permite adăugarea de seturi de date multiple pentru același test. Aceasta înseamnă că la executarea testului acesta va rula același flux de lucru dar cu diferite set-uri de intrări de date.

Operațiile ce pot fi realizate pentru un test deja salvat sunt:

– definirea unui nou set de intrări de date

– editarea unui set de date

– ștergerea unui set de date

Tipurile de valori ce pot fi alocate sunt aceleași ca și pentru parametri cuvintelor cheie:

– Manual Input

– Link (Variabile, Constant)

– Random

Fig32. Reprezentarea butonului de generare de date din bara de instrumente

Fig33. Interfața pentru generarea de date de intrare pentru teste

4.8 Rularea testului curent

Testul curent se poate executa direct din aplicația de automatizare care va declanșa instrumentul de automatizare să ruleze testul. GUI-ul va aștepta până când procesul de rulare se va încheia.

Fig34. Reprezentarea butonului de rulare a testului curent

4.9 Vizualizarea rezultatelor testului rulat curent

După ce testul curent a fost executat rezultatele sale pot fi vizualizate (o pagina html va fi deschisă) acționând butonul de ViewTestResults din bara de instrumente.

Rezultatele testului vor fi scrise fie cu verde(testul a fost executat fără erori) sau cu roșu (în căzut în care au apărut erori la rularea testului sau există erori în librăriile utilizate).

Fig35. Reprezentarea butonului de vizualizare a rezultatelor unui test

Fig36. Pagina de internet a rezultatelor testului

4.10 Rularea unui Test Set

Această opțiune permite utilizatorilor să facă operații în fila de Test Lab din Quality Center și să ruleze testele/ testul de set-uri din Quality Center.

Îi permite utilizatorului următoarele:

– rularea doar a testelor selectate

– rularea întregul test set

– opțiunea de a rula toate testele pe mașina locală sau nu

– schimbarea host-ului unde se dorește ca testul să fie rulat

– crearea unui nou folder de teste în fila de Test Lab

– crearea unui nou test set în fila de Test Lab

– ștergerea unui test set selectat sau a unui folder din fila de Test Lab

– adăugarea de teste din Test Plan într-un test set.

Fig37. Reprezentarea butonului de rulare a unui test set

Următoarea interfață reprezintă o replică fidelă a operațiilor ce se pot realiza din Quality Center asupra dosarelor și seturilor de teste.

Fig.38. Interfața replicii operațiilor din centrul de calitate(QC) în aplicația prezentată

Capitolul 5. Realizarea practică a aplicației

5.1 Instrumente necesare pentru începerea dezvoltării

Pentru începerea lucrului efectiv sunt necesare următoarele:

Un calculator pe care sa fie instalate următoarele:

Microsoft Visual Studio

Quick Test Professional

Produsul pe care se vor efectua testele

Suita Microsoft Office (în special Microsoft Excel și Microsoft Word)

Să se ruleze dată a Quality Center(Centrului de Calitate) pentru obținerea dll-urilor necesare(ex. OTAClient.dll)

5.2 Rezolvarea problemelor întâmpinate

Majoritatea problemelor întâmpinate au fost legate de lucrul din program cu centrul de calitate(Quality Center) datorită lipsei de documentație disponibile. Rezolvarea acestor probleme a necesitat o muncă asiduă de cercetare pe internet și în cărțile de specialitate.[THO14]

Convertirea codului VBScript în cod POO a rezolvat o altă problemă legată de rularea testelor cu Instrumentul profesional de testare rapidă automată(QuickTest Professional), problema fiind datorită lipsei de documentație necesare în legătura cu interoperabilitatea cu librăriile din C# dar după o cercetare mai amănunțită am reușit să rezolvăm.

Implementarea unei clase RepairePoint care reanaliza starea dosarelor a rezolvat problema schimbării imaginilor dosarelor obișnuite de teste C# pentru că accesul la acestea nu era permis, dosarele fiind create cu atributul doar pentru citire(Read-Only)

Moștenirea claselor necesare și implementarea unor funcții care să rețină valorile dorite a fost soluția la problema transmiterii informațiilor de la o fereastră la alta, în C# fiecare fereastră(form) are o inițializare proprie de variabile și componente care sunt private ferestrei.

Structura de tipul:

Try{

catch(Exception e){

}

} – a rezolvat problema erori ce intervin la pierderea conexiunii cu centrul de calitate(Quality Center), atunci când aplicația nu mai era utilizată mai mult de 15 minute, sau când nu era bifată la conexiunea cu Quality Center opțiunea de descărcare de resurse, iar pe mașina de lucru dosarul de resurse nu exista. Același procedeu s-a aplicat și în cazul introducerii la conectare în aplicație cu date invalide. Astfel că au fost afișate două mesaje corespunzătoare:

Fig39. Erori la ne depistarea resurselor și la identificare

De asemenea în cadrul generatorului de date de intrare există o opțiune de ștergere a seturilor de date, problema în acest caz a intervenit atunci când această opțiune se putea aplica și în cazul unui singur set de date de intrare pentru un test. Această problem a fost rezolvată prin numărarea seturilor din grid-ul din această utilitate,[Http2], și utilizând un TabControl s-a putut restricționa ștergerea seturilor de date în cazul în care exista unul singur.

S-a evidențiat acest lucru prin afișarea unui mesaj corespunzător.

Fig40. Eroarea la încercarea de ștergere a singurului set de date de intrare

Concluzii

“Profesionalismul în testare constă în abilitatea de a selecta numărul minim de cazuri de testare eficientă ce va fi capabil să verifice numărul maxim de funcții ale sistemului”. Găsirea erorilor cât mai rapid este necesar pentru a aduce produsul software la un nivel calitativ cât mai ridicat, pentru că cu cât se găsesc erori în aplicație erori mai târziu cu atât vor fi mai scump de rezolvat, de aceea dezvoltarea scenariilor de test este crucială precum și implementarea testării automate.

Pentru introducerea testării automate este necesară o fază de analiză care este consumatoare de timp inițial. Cu toate acestea, pe termen lung, timpul petrecut în această fază va fi util în faza de testării regresiei. Pentru a ține pasul cu ritmul alert de dezvoltare a produsului software și de livrare este absolut necesar să se pună în aplicare soluții eficiente, care pot fi reutilizate de automatizare dar în același timp soluțiile găsite să fie ușor de depanat și utilizat

Procesul de testare automată pare mai costisitor din punct de vedere al timpului și al resurselor dar amortizarea investiției nu întârzie, iar profitul va apărea și el.

Deși testarea automată este un proces laborios care necesită o cercetare aprofundată a problemelor ce urmează a fi rezolvate prin programele care se scriu, este necesară o abordare sistematică a întregului ansamblu și un mod deschis de tratare a fiecărei probleme în parte.

Elaborarea unei metodologii unice destinate testării automate și crearea unui software, general valabil, dedicat testării este foarte dificil să se considere.

Scopul aplicației este acela de a crea un limbaj comun de automatizare, de testare și un set de instrumente comune, cuvinte cheie, independente de tehnologia de dezvoltare și de instrumentul, tool-ul, de testare automată folosit, oferind celor fără cunoștințe de programare capacitatea de a crea totuși si ei teste automate.

Aplicația a fost concepută ca o interfață comună care să poată fi folosită pentru a utiliza orice instrument de automatizare, având același proces de lucru pentru crearea, deschiderea, salvarea și rularea de teste.

Editorul și executorul de teste sunt un instrument absolut necesar și foarte ușor de utilizat pentru crearea și rularea de teste automate, mai ales în cazul în care se dorește a se crea teste automate de persoane care nu cunosc limbaje de programare necesare instrumentului de automatizare.

Printr-o minimă pregătire a unei persoane se ajunge ca aceasta să creeze teste automate, această persoană trebuind în schimb să știe ce întrebuințare are fiecare cuvânt cheie, aceasta nefiind o piedică în folosirea aplicației pentru că persoana în cauză trebuie să știe produsul pentru care se dorește a se crea teste automate.

Bibliografie

[BHA13] Bhargava, Ashish –Designing and Implementing Test Automation Frameworks with QTP, Packt Publishing Ltd., 2013

[Lib02] Jesse Liberty – Programing C#, Second edition”, 2002

[MYER79] Myers, Glenford J. – The Art of SoftwareTesting, John Wiley & Sons,

NewYork, 1979

[POCA02] Pocatilu, Paul – Costurile testării software în Informatica Economică vol. VI,

nr. 1, 2002, pag. 90-93

[THO14] Thomas, Susan – Keyword Driven Framework in QTP, Amazon Digital Services Inc., 2014

[THO13] Thomas, Susan – VBScript for QTP, Amazon Digital Services Inc., 2014

[VIN12] Vinnakota, Ravi Sankar – QuickTest Professional: Covers QTP 9.2, 9.5, 10.00 and 11.00, Tata McGraw-Hill, 2012

[HTTP1] http://www.open2test.org

[HTTP2] http://www.codeproject.com/Articles/13058/Data-Binding-with-Windows-Forms-2-0-Programming-Sm#5

[HTTP3] http://en.wikipedia.org/wiki/IEEE_829

[HTTP4] http://support.smartbear.com/articles/testcomplete/benefits-of-keyword-testing-for-automated-testing/

[HTTP5] http://jawedm.blogspot.com/2010/12/download-qc-ota-api-reference-handbook.html

[HTTP6] http://www.codeproject.com/Articles/2986/FolderTreeView-Control

[HTTP7] http://stackoverflow.com/questions/332397/what-is-the-best-way-to-check-for-reparse-point-in-net-c

[HTTP8] http://www.codeproject.com/

[HTTP9] http://www.codeproject.com/Articles/23961/LeerGridView-an-Editable-ListView

[HTTP10] http://help.tasktop.com/help=QC_Connect

[HTTP11] http://en.wikipedia.org/wiki/Test_automation#References

[HTTP12] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools

[HTTP13] http://www.telerik.com/automated-testing-tools/

Bibliografie

[BHA13] Bhargava, Ashish –Designing and Implementing Test Automation Frameworks with QTP, Packt Publishing Ltd., 2013

[Lib02] Jesse Liberty – Programing C#, Second edition”, 2002

[MYER79] Myers, Glenford J. – The Art of SoftwareTesting, John Wiley & Sons,

NewYork, 1979

[POCA02] Pocatilu, Paul – Costurile testării software în Informatica Economică vol. VI,

nr. 1, 2002, pag. 90-93

[THO14] Thomas, Susan – Keyword Driven Framework in QTP, Amazon Digital Services Inc., 2014

[THO13] Thomas, Susan – VBScript for QTP, Amazon Digital Services Inc., 2014

[VIN12] Vinnakota, Ravi Sankar – QuickTest Professional: Covers QTP 9.2, 9.5, 10.00 and 11.00, Tata McGraw-Hill, 2012

[HTTP1] http://www.open2test.org

[HTTP2] http://www.codeproject.com/Articles/13058/Data-Binding-with-Windows-Forms-2-0-Programming-Sm#5

[HTTP3] http://en.wikipedia.org/wiki/IEEE_829

[HTTP4] http://support.smartbear.com/articles/testcomplete/benefits-of-keyword-testing-for-automated-testing/

[HTTP5] http://jawedm.blogspot.com/2010/12/download-qc-ota-api-reference-handbook.html

[HTTP6] http://www.codeproject.com/Articles/2986/FolderTreeView-Control

[HTTP7] http://stackoverflow.com/questions/332397/what-is-the-best-way-to-check-for-reparse-point-in-net-c

[HTTP8] http://www.codeproject.com/

[HTTP9] http://www.codeproject.com/Articles/23961/LeerGridView-an-Editable-ListView

[HTTP10] http://help.tasktop.com/help=QC_Connect

[HTTP11] http://en.wikipedia.org/wiki/Test_automation#References

[HTTP12] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools

[HTTP13] http://www.telerik.com/automated-testing-tools/