how develop test scripts using top 5 most popular test automation frameworks
Când începeți să aflați despre automatizarea testelor, trebuie să întâlniți termenul „cadru de automatizare a testelor”. Poate că unii dintre voi se simt incomod cu acest termen și încep să simtă că este ceva greu de înțeles și chiar mai dificil de implementat.
Acest tutorial este scris cu scopul de a vă ajuta să înțelegeți cadrele de automatizare a testelor cât mai simplu posibil. Citiți toate tutorialele din aceasta ' Seria Tutoriale de testare automată aici .
Cadrul de automatizare a testelor (într-un limbaj foarte simplu) este „set de reguli”. Regulile ne ajută să scriem scripturi în așa fel încât să conducă la „o întreținere mai redusă”.
Pentru a înțelege complet conceptul cadrului, trebuie mai întâi să învățăm cum scriem scripturi simple și apoi cum să implementăm un cadru pe ele.
În automatizarea testelor, scriem scripturi. Scripturile sunt în principiu aproximativ trei „A”:
- ARANJAMENT
- ACȚIUNE
- AFIRMAŢIE
Mai jos sunt detaliile fiecărui A, cu exemple:
# 1.ARANJAMENTsau Identificarea obiectelor
tehnici de eliberare a cerințelor în ingineria software
Identificăm obiecte (butoane, meniuri drop-down etc.) fie după ID-urile, numele sau după titlurile lor de ferestre etc.
În cazul aplicației web, ne identificăm după ID-ul de utilizator, sau după XPath sau prin CSS sau după numele clasei etc. Dacă nimic nu funcționează, atunci identificăm obiecte folosind coordonatele mouse-ului (dar nu este o metodă fiabilă de identificare a obiectelor)
Luați acest exemplu de Selenium WebDriver (cu C #) în care identificăm obiecte folosind id-ul. (Aplicatie web)
IWebElement txtServer = _webDriver.FindElement(By.Id('tfsServerURL'));
Un alt exemplu din MS Coded UI (aplicație desktop)
WinButton btnAdd = new WinButton(calWindow); btnAdd.SearchProperties[WinButton.PropertyNames.Name] = 'Add';
După identificare, aranjăm sau stocăm aceste obiecte în UIMaps sau în Depozitul de obiecte pentru a le reutiliza în scripturile noastre. De aceea acest pas se numește ARANJAMENT.
#Două.ACȚIUNEpe obiectul identificat
Când obiectele sunt identificate, executăm un fel de acțiuni asupra acestuia fie cu mouse-ul, fie cu tastatura.De exemplu, fie facem clic, fie facem dublu clic, fie trecem cu mouse-ul peste el sau uneori tragem-plasăm. Uneori scriem pe casete de text. Deci, orice fel de acțiune pe care o executăm asupra acestor obiecte este acoperită în acest al doilea pas.
Exemplul 1 : (Selenium WebDriver cu C #)
txtServer.Clear(); txtServer.SendKeys(“Some sample text”);
Exemplul 2 : (UI codat MS cu C #)
Mouse.Click(buttonAdd);
# 3.AFIRMAŢIE
Afirmația verifică practic obiectul cu un rezultat așteptat. De exemplu, dacă apăsăm 2 + 3 pe calculator, ecranul ar trebui să afișeze 5. În acest caz, rezultatul nostru așteptat este 5. Acest concept este deja explicat în primul nostru tutorial.
Aici oferim un exemplu de afirmație:
Assert.AreEqual('5', txtResult.DisplayText);
Aproape fiecare script scris în automatizarea testului conține aceste trei lucruri: Aranjament, Acțiune și Afirmare.
Acum aruncați o privire la un script complet care conține toți acești pași. Scriptul va deschide un calculator, apăsați 1 + 6 și apoi verificați dacă ecranul afișează 7 sau nu.
Exemplul A:
[TestMethod] [TestMethod] public void TestCalculator() { var app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //Object identification part (ARRANGEMENT) //----*Calculator Window----*// WinWindow calWindow = new WinWindow(app); calWindow.SearchProperties[WinWindow.PropertyNames.Name] = 'Calculator'; calWindow.SearchProperties[WinWindow.PropertyNames.ClassName] = 'CalcFrame'; //----*Button1 ----*// WinButton btn1 = new WinButton(calWindow); btn1.SearchProperties[WinButton.PropertyNames.Name] = '1'; //----*Button Add ----*// WinButton btnAdd = new WinButton(calWindow); btnAdd.SearchProperties[WinButton.PropertyNames.Name] = 'Add'; //----*Button 6 ----*// WinButton btn6 = new WinButton(calWindow); btn6.SearchProperties[WinButton.PropertyNames.Name] = '6'; //----*Button Equals ----*// WinButton btnEquals = new WinButton(calWindow); btnEquals.SearchProperties[WinButton.PropertyNames.Name] = 'Equals'; //----*Text Box Results----*// WinText txtResult = new WinText(calWindow); txtResult.SearchProperties[WinText.PropertyNames.Name] = 'Result'; //(ACTIONS Part) // Click '1' button Mouse.Click(btn1); // Click 'Add' button Mouse.Click(btnAdd); // Click '6' button Mouse.Click(btn6); // Click 'Equals' button Mouse.Click(btnEquals); //evaluate the results (ASSERTIONS) Assert.AreEqual('7', txtResult.DisplayText, “Screen is not displaying 7); //close the application app.Close(); }
Ce veți învăța:
- Ce este în neregulă cu acel script?
- Există cinci cadre populare în automatizarea testelor:
- # 1. Cadrul liniar:
- # 2. Cadrul de modularitate:
- # 3. Cadru bazat pe date:
- # 4. Cadru bazat pe cuvinte cheie:
- # 5. Cadrul de automatizare a testelor hibride:
- Concluzie
- Lectură recomandată
Ce este în neregulă cu acel script?
Scenariul este ușor de înțeles și sper că veți obține conceptul de trei „A” în exemplul de mai sus. Dar totul nu este în regulă cu acest scenariu.
Acest script nu permite o întreținere ușoară. Luați din nou exemplul calculatorului, dacă trebuie să scriem cazuri de testare pentru fiecare funcție a calculatorului, vor exista multe cazuri de testare. Dacă există 10 cazuri de testare și în fiecare test, trebuie să definim același obiect, atunci dacă apare o modificare în numele sau ID-ul obiectului, trebuie să schimbăm partea de identificare a obiectului în 10 cazuri de testare.
De exemplu, luați exemplul butonului ADAUGĂ în script.
WinButton btnAdd = new WinButton(calWindow); btnAdd.SearchProperties[WinButton.PropertyNames.Name] = 'Add';
Să presupunem că această linie este utilizată în 10 cazuri de testare. Acum, în următoarea versiune a calculatorului, dezvoltatorul a schimbat numele butonului din „Adăugare” în „Plus”. Acum, când rulăm cazurile noastre de testare, acestea vor eșua și trebuie să schimbăm linia de mai sus cu aceasta în 10 cazuri de testare.
btnAdd.SearchProperties[WinButton.PropertyNames.Name] = 'Plus';
Deci, trebuie să îmbunătățim acest caz de testare. Ar trebui să urmăm celebrul principiu DRY în codificarea noastră. DRY înseamnă „Nu te repeta”. Ar trebui să scriem partea de identificare a obiectului în așa fel încât obiectul ar trebui identificat doar într-un singur loc și ar trebui să fie chemat peste tot.
Aruncați o privire la scriptul îmbunătățit.
Exemplul B:
//defining the objects outside the script and only once. ApplicationUnderTest app = null; public WinWindow calWindow { get { WinWindow _calWindow = new WinWindow(app); _calWindow.SearchProperties[WinWindow.PropertyNames.Name] = 'Calculator'; _calWindow.SearchProperties[WinWindow.PropertyNames.ClassName] = 'CalcFrame'; return _calWindow; } } public WinText txtResult { get { WinText _txtResult = new WinText(calWindow); _txtResult.SearchProperties[WinText.PropertyNames.Name] = 'Result'; return _txtResult; } } //making functions for similar kind of tasks public void ClickButton(string BtnName) { WinButton button = new WinButton(calWindow); button.SearchProperties[WinButton.PropertyNames.Name] = BtnName ; Mouse.Click(button); } public void AddTwoNumbers(string number1, string number2) { ClickButton(number1); ClickButton('Add'); ClickButton(number2); ClickButton('Equals'); } //Test case becomes simple and easy to maintain. [TestMethod] public void TestCalculatorModular() { app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //do all the operations AddTwoNumbers('6', '1'); //evaluate the results Assert.AreEqual('7', txtResult.DisplayText, “screen is not displaying 7”); //close the application app.Close(); }
În exemplul de mai sus, am separat fișierul calWindow și txtResult obiectelor și deplasați-le în partea de sus, astfel încât să poată fi utilizate în diferite metode de testare. Le-am definit o singură dată și le putem folosi în câte teste dorim.
De asemenea, am creat două funcții. ClickButton () care acceptă un nume de buton și faceți clic pe acesta și AddTwoNumbers () care ia orice două numere și le adaugă folosind faceți clic pe buton funcționează în interiorul său.
cel mai bun software de spionaj mobil pentru Android
În momentul în care începem să ne „îmbunătățim” codul și să-l facem reutilizabil și mentenabil, înseamnă că facem uz de orice cadru de automatizare. Acum devine interesant.
Vezi si=> De ce avem nevoie de cadrul pentru automatizarea testelor?
Sunt cinci cadre populare în automatizarea testelor :
- Liniar
- Modularitate
- Date Driven
- Cuvânt cheie condus
- Hibrid
Vom explica acum fiecare cadru cu ajutorul caracteristicilor sale.
# 1. Cadrul liniar:
Caracteristici
- Tot ceea ce ține de un script este definit în interiorul scripturilor.
- Nu-i pasă de abstractizare și de duplicarea codului
- Înregistrarea și redarea generează în mod normal cod liniar
- Ușor de început
- Coșmar de întreținere.
Citind cele 5 caracteristici de mai sus ale Linear Framework, putem relaționa cu ușurință Exemplul nostru A cu acestea. Acest exemplu utilizează practic cadrul liniar, orice lucru legat de un script este definit în interiorul scriptului. fereastra de apel și TxtResult sunt definite în interiorul scriptului. Scriptului nu îi pasă de abstractizare și de duplicarea codului. Este, de asemenea, un coșmar de întreținere, așa cum am explicat mai devreme.
Deci, de ce ar trebui să folosim acest cadru?
Acest cadru poate fi utilizat în proiecte la scară mică, unde nu există multe ecrane UI. De asemenea, atunci când folosim orice instrument de automatizare pentru prima dată, acesta generează în mod normal cod în formă liniară. Deci, putem afla despre ce cod este generat de instrumentul de automatizare pentru acțiuni specifice. În afară de aceste motive, acest cadru ar trebui evitat în scriptarea dvs.
=> Vezi aici exemplul cadrului liniar și al cuvintelor cheie cu QTP.
# 2. Cadrul de modularitate:
Caracteristici
- Obiectele sunt definite o singură dată și reutilizabile în toate metodele de testare.
- Metode mici și la obiect sunt create pentru funcționalități individuale
- Cazul de testare este colectarea acestor mici metode și obiecte reutilizabile
- Acest lucru ne permite să scriem cod care poate fi întreținut.
Citind caracteristicile de mai sus, putem lega Exemplul nostru B de aceste caracteristici. În acest exemplu, am creat o abstractizare prin deplasarea calWindow în partea de sus și definiți-l în interiorul unei proprietăți care poate fi folosită peste tot. Am creat două funcții mici și independente numite ClickButton () și AddTwoNumbers () . Combinăm aceste două funcții mici pentru a crea scriptul final care testează funcționalitatea „Adăugare” a calculatorului.
Acest lucru are ca rezultat o întreținere mai ușoară. Dacă apare o modificare în interfața de utilizare a calculatorului, trebuie să schimbăm doar funcțiile. Scripturile noastre vor rămâne intacte. Acest cadru este foarte utilizat în automatizare. Celebrul Page Object Framework (care este utilizat cu Selenium) este, de asemenea, un fel de cadru de modularitate. Distribuim întreaga aplicație web în pagini separate. Butoanele, meniurile derulante și casetele de selectare ale fiecărei pagini sunt definite în clasa acelei pagini. Dacă are loc o modificare pe site-ul web, trebuie să ne schimbăm numai în acea clasă de pagini, iar alte pagini rămân intacte. Acest lucru are ca rezultat o mai bună întreținere și o mai ușoară lizibilitate a scripturilor.
Singurul dezavantaj al acestui cadru este că necesită concepte bune orientate pe obiecte și abilități puternice de dezvoltare. Dacă aveți aceste, acest cadru este foarte recomandat.
# 3. Cadru bazat pe date:
Caracteristici:
- Datele de testare (valorile de intrare și ieșire) sunt separate de script și stocate în fișiere externe. Acesta poate fi un fișier CSV, o foaie de calcul Excel sau o bază de date.
- Când se execută scriptul, aceste valori sunt selectate din fișiere externe, stocate în variabile și înlocuiesc valorile codificate în mod dur, dacă sunt prezente.
- Foarte util în locuri în care același caz de testare trebuie rulat cu intrări diferite.
Exemplul C:
Vrem să rulăm cazul de testare a adăugării cu trei intrări diferite.
Datele sunt
7 + 2 = 9
5 + 2 = 7
3 + 2 = 5
Am stocat aceste date (atât de intrare cât și de ieșire) într-un fișier CSV extern.
[DataSource('Microsoft.VisualStudio.TestTools.DataSource.CSV', '|DataDirectory|\data.csv', 'data#csv', DataAccessMethod. Sequential ), DeploymentItem('TestCalc\data.csv'), TestMethod] public void TestCalculatorDataDrivsen() { app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //do all the operations AddTwoNumbers(FromCSV.ADD1, FromCSV.ADD2); //evaluate the results Assert.AreEqual(FromCSV.Sum, txtResult.DisplayText); //close the application app.Close(); }
În scriptul de mai sus, ne definim sursa de date în partea de sus a scriptului, care este un fișier .csv.
Am dat calea fișierului that.CSV și am spus scriptului să-l analizeze „Secvențial”. Aceasta înseamnă că scriptul va rula de câte ori există rânduri prezente în fișierul CSV. În cazul nostru, scriptul va rula de 3 ori. În fiecare rundă, va adăuga cele două numere definite în primele două coloane și va verifica dacă suma acestor două numere se potrivește cu numărul prezent în a treia coloană.
Există diferite avantaje ale acestui cadru. Toate valorile sunt stocate în afara scriptului, deci dacă va apărea o modificare în următoarea versiune, trebuie doar să schimbăm datele din fișierul extern și scriptul va rămâne intact.
Al doilea avantaj este că același script poate fi rulat pentru intrări diferite. Luați exemplul unui ERP în care trebuie să testați înregistrarea a 100 de angajați. Puteți scrie un script și puteți stoca numele și alte date legate de angajați într-un fișier extern. Veți executa un script și va rula de 100 de ori. De fiecare dată cu date diferite ale angajaților. Puteți detecta cu ușurință, pe ce date scriptul nu reușește să înregistreze angajatul. Va fi un avantaj suplimentar atunci când efectuați teste negative.
=> Vedeți aici exemplul cadrului bazat pe date și Hybrid cu QTP.
# 4. Cadru bazat pe cuvinte cheie:
Caracteristici:
- Atât datele, cât și acțiunile sunt definite în afara scriptului.
- A necesitat dezvoltarea de cuvinte cheie pentru diferite tipuri de acțiuni.
- Funcționalitatea pe care trebuie să o testăm este scrisă pas cu pas în formă tabelară folosind cuvintele cheie pe care le dezvoltăm și datele de testare. Stocăm acest tabel în fișiere externe la fel ca cadrul bazat pe date.
- Scriptul va analiza acest tabel și va efectua acțiunile corespunzătoare.
- Permite testerului manual care nu știe despre codificare să facă parte într-o oarecare măsură din automatizare.
Exemplul D:
Am definit datele (de exemplu, 1 + 3 = 4), precum și acțiunile (de exemplu, faceți clic, ștergeți etc.) într-un fișier Excel în formă tabelară.
Scriptul va deveni ceva de genul acesta (codul de mai jos este scris doar în scopul înțelegerii)
Exemplu de tabel hash c ++
[TestMethod] public void TestCalculator() { app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); Table tb = ReadFromExcel(); Foreach(WinRow row in tb) { WinCell Window = row.Cells[“Window”]; WinCell Control = row.Cells[“Control”]; WinCell Action = row.Cells[“Action”]; WinCell Arguments = row.Cells[“Arguments”]; UITestControl c = GetControl(Control.Text,Window.Text); If(Action.Text == “Click”) Mouse.Click (c); If (Action.Text == “Clear”) c.Clear(); if(Action.Text == “Verify Result”) Assert.AreEqual(c.Text, Arguments.Text) //….and so on } }
Scriptul de mai sus este doar un analizor al fișierului Excel. Analizează fișierul Excel linie cu linie și caută cuvinte cheie pentru a efectua acțiuni respective. Dacă găsește cuvântul cheie „Click”, va face clic pe obiectul definit. Dacă găsește „Verificați rezultatul”, va efectua afirmația.
Există diferite avantaje ale utilizării cadrului bazat pe cuvinte cheie.
Primul avantaj este că acest cadru este foarte util în acele scenarii în care există șanse mari de modificări în cazurile de testare. Dacă vreun pas se modifică într-un caz de testare, nu este necesar să atingem codul. Trebuie doar să actualizăm fișierul Excel, iar scriptul va fi actualizat.
Puteți defini toate scripturile într-un fișier Excel și puteți preda acest fișier Excel testerelor manuale pentru a adăuga noi scripturi sau pentru a le actualiza pe cele existente. În acest fel, testerele manuale pot deveni, de asemenea, parte a automatizării testelor, deoarece nu trebuie să codeze nimic. Vor actualiza acest fișier Excel atunci când este nevoie și scripturile vor fi actualizate automat.
Al doilea avantaj este că scriptul dvs. devine independent de instrument. Puteți să vă mențineți scripturile într-un fișier Excel și dacă trebuie să schimbați instrumentul de automatizare la un moment dat, îl puteți schimba cu ușurință scriind un analizor Excel într-un alt instrument.
Dezavantajul acestui cadru este că trebuie să inventați cuvinte cheie pentru diferite tipuri de acțiuni. În proiectele la scară largă, vor exista atât de multe cuvinte cheie încât trebuie să vă amintiți și să vă organizați scripturile și cuvintele cheie. Aceasta în sine devine o sarcină greoaie la un moment dat.
În unele scenarii complexe, în care obiectele nu pot fi ușor identificate și trebuie să folosim coordonatele mouse-ului și alte tehnici, acest cadru nu este foarte util.
Cuvântul cheie este încă un cadru preferat pentru mulți testeri de automatizare. Cadrul robotului by Google este un cadru popular bazat pe cuvinte cheie, care este susținut de o comunitate activă.
# 5. Cadrul de automatizare a testelor hibride:
Caracteristici:
- Combinația a două sau mai multe dintre tehnicile de mai sus, luând din punctele lor forte și minimizând punctele slabe ale acestora.
- Cadrul poate utiliza abordarea modulară împreună cu un cadru bazat pe date sau bazat pe cuvinte cheie.
- Cadrul poate utiliza scripturi pentru a efectua unele sarcini care ar putea fi prea dificil de implementat într-o abordare pură bazată pe cuvinte cheie.
În cuvinte simple, cadru hibrid, utilizați combinația tehnicilor menționate mai sus. Putem folosi un cadru bazat pe date, care este, de asemenea, de natură modulară. Pentru unele cazuri de testare, putem folosi o abordare bazată pe cuvinte cheie, iar pentru restul putem folosi modular. Deci, de fiecare dată când amestecăm două sau mai multe tehnici menționate în acest articol, folosim de fapt o abordare hibridă.
Concluzie
Sper că cadrul de automatizare a testelor nu mai este un termen înfricoșător pentru dvs. acum. Am încercat să explic cele mai populare cadre cât mai simplu posibil.
Cadrele sunt aici pentru a vă ușura viața. Acestea vă ajută să scrieți scripturi de întreținere și de încredere. Fără a utiliza cadre, câmpul automatizării testelor este un coșmar. Pentru fiecare mică modificare a aplicației, trebuie să vă schimbați codul în sute de locuri.
Deci, o înțelegere a acestor cadre este o necesitate pentru fiecare tester care dorește un gust al automatizării testelor.
În a noastră următorul tutorial în această serie, vom învăța „Executarea și raportarea automatizării testelor”.
Dacă mi-a fost dor de ceva din acest articol sau trebuie să puneți orice întrebare, vă rugăm să nu ezitați să întrebați în secțiunea de comentarii.
PREV Tutorial # 4 | URMATORUL Tutorial nr. 6
Lectură recomandată
- Cadruri QTP - Cadruri de automatizare de testare - Exemple de cadru liniar și bazat pe cuvinte cheie - Tutorial QTP # 17
- Comenzile de automatizare SeeTest: o explicație detaliată cu exemple
- Cele mai populare instrumente RPA de automatizare a proceselor robotice în 2021
- În ce diferă planificarea testelor pentru proiectele manuale și de automatizare?
- Cele mai populare cadre de automatizare a testelor cu avantajele și dezavantajele fiecăruia - Selenium Tutorial # 20
- Cadrul de automatizare a testelor fără scripturi: instrumente și exemple
- Automatizarea testelor - Este o carieră specializată? Testatorii normali pot face și automatizarea?
- Cele mai bune 25 de cadre de testare Java și instrumente pentru testarea automatizării (partea 3)