Unified Functional Testing este un tool de testare automată, folosit în testarea funcțională a aplicațiilor desktop, web sau mobile. UFT-ul acoperă o gamă largă de tehnologii, precum: Java, .Net, Oracle, Web Forms, Qt etc. Testarea se bazează pe un limbaj de scripting pentru automatizarea aplicațiilor, numit VBScript. Furnizează atât funcții de record cât și funcții de replay. Poate fi integrat cu tooluri precum ALM Quality Center.
Prin continuous integration înțelegem setul de practici prin care dezvoltatorii software integrează în mod frecvent codul dezvoltat de obicei într-un repository comun. Fiecare integrare de cod este ulterior verificată prin builduri automate, detectând în acest fel, posibilele erori într-un timp foarte scurt.
Practici:
Menținerea unui singur repository;
Automatizarea buildului;
Automatizarea testelor;
Fiecare commit ar trebui să fie builduit pe o mașină de integrare;
Buildul trebuie să se facă rapid;
Testarea se realizează pe o copie a mediului de producție;
Fiecare developer trebuie să aibă acces facil la ultima versiune de cod;
Fiecare developer trebuie să știe tot ceea ce se întâmplă cu codul;
Cum se realizează acesti pași:
Developerii verifică codul în workspace-ul lor privat.
Când sunt gata, modificările sunt comise in repository.
Serverul CI monitorizează repository-ul și verifică modificările atunci când acestea apar.
Serverul CI builduiește sistemul și execută teste unitare și de integrare.
Serverul CI realizează artefacte disponibile pentru testare.
Serverul CI atribuie o versiune codului pe care tocmai l-a construit.
Serverul CI informează developerii cu privire la succesul/eșecul buildului realizat.
În cazul în care buildul sau testele eșuează, developerii rezolvă problema cât mai curând posibil.
Procesele de continuous integration (CI) și continuous delivery (CD) au devenit parte integrantă a seturilor de "best practices", făcând astfel aplicațiile în curs de dezvoltare gata de lansare în orice moment și oferind posibilitatea livrării rapide în producție a noilor feature-uri/schimbări.
Procesul de integrare continuă se referă la modul de integrare a schimbărilor provenite de la mai mulți developeri, chiar și de câteva ori pe zi. Combinat cu testarea automată, integrarea continuă asigură fiabilitatea codului dezvoltat.
Livrarea continuă se referă la modalitatea prin care te asiguri că aplicația dezvoltată este mereu gata de lansare în mediul de producție. Aceasta înseamnă că developerii nu sunt singurii implicați în acest proces de livrare, alături de ei fiind și testeri, administratori de baze de date, administratori de sistem și utilizatori. Procesul de CD reprezintă o extensie a continuous integration, însemnând că pe lângă automatizarea buildului și a testelor, este automatizat și procesul de release, iar aplicația poate fi lansată în orice moment.
Jenkins este un server open-source dezvoltat în Java, care este utilizat pentru automatizarea proceselor de dezvoltare software. Jenkins este de fapt toolul prin care se realizează procesul de continuous integration.
ALM Octane (Application Lifecycle Management) este o platformă web de gestionare a ciclului de viață al aplicațiilor, care permite echipelor să colaboreze cu ușurință, să gestioneze pipeline-ul de livrare a produselor și să vizualizeze impactul schimbărilor realizate. Este un tool care oferă suport în dezvoltarea aplicațiilor de la faza de planificare, preluare cerințe, până la testare și lansare.
Acest plugin realizează integrarea dintre Jenkins și diverse produse Micro Focus. Folosind pluginul, userul poate crea și utiliza servicii virtuale, poate executa teste de performanță cu Performance Center sau LoadRunner, teste funcționale cu ajutorul UFT. De asemenea, execută teste în propriul laborator (ALM Lab Management) și realizează teste pe device-uri mobile. Pluginul permite încărcarea rezultatelor testelor în ALM Octane. De asemenea, utilizatorii ALM Octane pot să urmărească joburile de tip pipeline direct din interfața Jenkins.
Pluginul a fost implementat în Java, fiind un proiect de tip Maven. Cel care lansează UFT-ul pentru a rula testele un tool numit HpToolsLauncher, aplicație de sine stătătoare dezvoltată în C#. Pentru rapoarte UFT din interfața Jenkins, cât și formurile prezente la build step sunt implementate în jelly.
Toate datele introduse la build step, în pagina de configurare a unui job, sunt preluate și salvate într-un fișier text (exemplu de denumire de fișier: props04032019102215010.txt), acesta fiind folosit ca input data de către aplicație. HpToolsLauncher creează un scheduler, lansează UFT-ul, se rulează testele, iar la final, colectează rezultatele acestor teste într-un alt fișier, în format xml (exemplu: Results04032019102215010.xml).
După cum am menționat anterior, fișierul de proprietăți conține setările din interfață completate la build step. Dintre acestea, cea mai importantă proprietate se referă la run type (File system sau ALM), care afectează modul în care se comporta aplicația.
Exemplu de fișier de proprietăți:
RunType=Alm
almRunHost= localhost
almTimeout=-1
almDomain=Default
almProject=Test_project
almPassword=Fov/e1Vq1y+3C/cr2+KtSw\=\=
TestSet1=Root\\Nike\\NikeTS\\OpenNotepad
almRunMode=RUN_LOCAL
almUserName=admin
almServerUrl= http://:8080/qcbin
resultsFilename=Results24022017093804464.xml Fișierul rezultat conține următoarele informații:
Numărul total de teste rulate;
Pathul fiecărui test rulat;
Pathul către raportul fiecărui test;
Timpul consumat de către fiecare test în parte;
Data și ora la care a început rularea fiecărui test;
Perechea fișier de proprietăți-fișier de rezultate se creează simultan, astfel încât ele pot fi identificate prin același timestamp comun: props04032019102215010.txt, Results04032019102215010.xml. Ambele fișiere sunt disponibile în folderul workspace din directorul de instalare Jenkins:
C:\Program Files (x86)\Jenkins\workspace\Job name
Tot în acest workspace este copiat și executabilul. Pentru fișierul rezultat, datele sunt colectate fie din results.xml sau run_results.xml, ambele generate de către UFT (results.xml pentru RunResultsViewer și run_results.xml pentru raportul HTML).
Începând cu versiunea 5.5, acest plugin va suporta numai ultimele cinci versiuni LTS ale Jenkins (actualmente 2.73.3), acest lucru se justifică prin politica Jenkins de a nu mai sprijini versiunile mai vechi.
Instalarea pluginului Micro Focus Application Automation Tools.
Java 8 sau o versiune mai nouă.
Instalarea clientului de ALM QualityCenter pe mașina pe care vor rula testele. Pentru a verifica corectitudinea instalării clientului de ALM urmați instrucțiunile de pe această pagină: http://
Pentru a rula teste UFT din ALM, clientul de ALM trebuie instalat în modul common registration, prin accesarea următorului link într-un browser IE pe mașina pe care este instalat și UFT-ul : http://
Printre feature-urile cele mai interesante ale acestui plugin, referitor la partea de integrare cu UFT-ul, se regăsesc următoarele:
Posibilitatea de a customiza rezultatele testelor;
Posibilitatea de a deschide rapoarte HTML în Jenkins, fără nevoia de a salva arhiva cu rezultate;
Suport pentru parametrizarea testelor, atunci când acestea rulează din ALM Octane;
Diverse opțiuni de filtrare ale testelor dintr-un set de teste;
Rularea testelor în paralel (parallel runner);
Mecanismul de reluare a rulării testelor în caz de eșec al unui job: dacă la rularea unui set de teste, cel puțin un test se termină cu eșec, utilizatorul poate decide dacă aplică mecanismul de rerun și eventual teste de cleanup anterioare rerun-ului.
Abilitatea de a obține rezultatele testelor în Jenkins chiar și atunci când un job a fost oprit anormal.
Exista patru tipuri de teste rulate cu ajutorul acestui plugin: din file system, din ALM Octane, din ALM Lab Management și din ALM Lab Environment Preparation.
În continuare, se vor prezenta fără a se insista asupra detaliilor, două categorii de teste și setările necesare pentru rularea acestor teste: rularea de pe file system și rularea din ALM.
Procesul prin care putem rula teste funcționale de UFT este următorul:
Crearea unui nou job și a unui proiect de tip free-style-project ;
Alegerea tipului de task : Execute Micro Focus tests from file system (Build -> Add build step) ;
Completarea pathului testelor;
Click Apply pentru a salva configurarea aleasă;
a. Salvarea rezultatelor pentru testele care nu au trecut;
b. Salvarea rapoartelor indiferent de rezultatul testelor;
c. Fără salvarea rapoartelor.
6 Rularea sau programarea rulării testelor la fel ca orice alt job de Jenkins.
La test path se poate specifica un singur test, un set de teste sau un fișier de tip mtbx care conține mai multe teste ce urmează a fi rulate.
Un exemplu de astfel de fișier aveți mai jos:
<Mtbx>
<Test name="test1" path="c:\tests\APITest1">
<Parameter name="A" value="abc" type="string"/>
</Test>
<Test name="test2" path="${WORKSPACE}\test2">
<Parameter name="p1" value="123" type="int"/>
<Parameter name="p4" value="123.4" type="float"/>
</Test>
</Mtbx>Acest tip de fișier poate conține și același test multiplicat, dar având parametri diferiți.
Jenkins poate fi configurat astfel încât să ruleze o serie de teste secvențial pe web sau mobil, în mai multe medii în paralel.
Când este configurat, fiecare test este executat secvențial. În timpul executării fiecărui test, environmenturile multiple sunt testate în paralel. Pentru aceasta opțiune se alege la build step ca tip de task "Execute Micro Focus tests from file system" și se selectează opțiunea "UFT parallel running mode". După aceasta, se definesc testele și environmenturile paralele.
Pentru a defini testele paralele:
Specificați calea absolută, un set de teste sau un fișier .mtbx care să conțină unul sau mai multe teste.
Selectarea environmenturilor paralele:
Selectați web sau mobile.
Pentru a vizualiza rezultatele testelor rulate:
În cazul rulării în paralel, raportul include rezultatele tuturor testelor rulate.
Click pe linkul ce conține numele testului rulat:
Raport în format HTML.
Raport de tip Run Results:
rezultatele testelor rulate sunt arhivate.
Pentru a rula teste funcționale din ALM, în secțiunea de build alegeți ca build step opțiunea "Execute Micro Focus functional tests from Micro Focus ALM".
Completați formul cu toate informațiile necesitate de ALM, printre care cele importante sunt: serverul (preconfigurat anterior Jenkins -> Manage Jenkins -> Configure system), credențialele, domeniul și proiectul.
Dacă este specificat și timeoutul, după expirarea acestuia, jobul va eșua. Rularea prin ALM oferă posibilitatea rulării testelor local, remote sau pe un host specificat. În cazul rulării pe un host remote, acesta trebuie să aibă instalat UFT.
Acest plugin oferă o modalitate ușoară de a vă integra testele UFT cu Jenkins, astfel încât să puteți beneficia de toate avantajele integrării continue a rapoartelor testelor și datelor anterioare. De asemenea, vă permite vizualizarea rezultatelor direct in interfață, dar și arhivarea și descărcarea lor.