Cadrul de automatizare a testelor: ArchiTextură și tipuri

⚡ Rezumat inteligent

Arhitectura cadrului de automatizare a testelor definește standardele de codare, gestionarea datelor de testare și regulile depozitului de obiecte pe care le urmează scripturile de automatizare. Există cinci tipuri stabilite, fiecare tranzacționând efortul de configurare în funcție de reutilizare, costurile de întreținere și scalabilitatea pe termen lung.

  • 📐 Definiția de bază: Un cadru de lucru este un set de îndrumări, nu reguli, care produc reutilizare, portabilitate și costuri de întreținere mai mici.
  • ⏺️ Scriptare liniară: Înregistrarea și redarea sunt cele mai rapide de construit și cele mai greu de întreținut, deoarece datele rămân codificate hardcoded.
  • 🧱 Biblioteca de teste Architectura: Pașii obișnuiți devin funcții reutilizabile apelate de un script de driver, crescând reutilizarea cu prețul timpului de planificare.
  • 📊 Bazat pe date: Logica de testare rămâne în scripturi în timp ce datele sunt mutate în Excel, CSV sau o bază de date, permițând mai multe scenarii per script.
  • 🔑 Condus de cuvinte cheie: Acțiunile sunt stocate ca și cuvinte cheie într-un tabel, ceea ce face ca testele să fie independente atât de instrument, cât și de aplicație.
  • 🔀 Model hibrid: Majoritatea suitelor mature combină tabele de cuvinte cheie cu descompunerea funcțională pentru a echilibra efortul și acoperirea.

Testarea cadrului de automatizare ArchiTextură și tipuri

Ce este Framework in Automation Testing?

A Testarea cadrului de automatizare este un set de linii directoare, cum ar fi standardele de codare, manipularea datelor de testare, tratarea depozitului de obiecte etc... care, atunci când sunt urmate în timpul scriptării automatizării, produce rezultate benefice, cum ar fi reutilizarea crescută a codului, portabilitate mai mare, costul redus de întreținere a scripturilor etc. Acestea sunt doar linii directoare și nu reguli; ele nu sunt obligatorii și puteți în continuare să scrieți scenarii fără a urma instrucțiunile. Dar veți pierde avantajele de a avea un cadru.

De ce ai nevoie de un cadru?

Să luăm în considerare un exemplu pentru a înțelege de ce aveți nevoie de un cadru.

Sunt sigur că ați participat la un seminar/prelecție/conferință la care participanții au fost rugați să respecte următoarele reguli:

  • Participanții trebuie să-și ocupe locurile cu 5 minute înainte de începerea unei prelegeri.
  • Luați cu voi un caiet și un stilou pentru a lua notițe.
  • Citește abdomenultracca să ai o idee despre ce va fi prezentarea.
  • Telefoanele mobile ar trebui să fie setate pe silentios.
  • Utilizați porțile de ieșire de la capătul opus vorbitorului dacă doriți să plecați la mijlocul prelegerii.
  • Întrebările vor fi luate la sfârșitul sesiunii.

Crezi că poți conduce un seminar FĂRĂ respectând aceste îndrumări?

Răspunsul este mare DA! Cu siguranță, puteți desfășura un seminar/prelecție/conferință/demonstrație fără îndrumările de mai sus.. de fapt, unii dintre noi nu le vom respecta, chiar dacă sunt aranjate!

Dar dacă se respectă instrucțiunile, se va obține un rezultat benefic, cum ar fi reducerea interesului publicului.tracțiune în timpul prelegerilor, o retenție sporită a participanților și o înțelegere sporită a subiectului.

Pe baza celor de mai sus, a Cadrul poate fi definit ca un set de linii directoare care, atunci când sunt respectate, produce rezultate benefice.

Testarea cadrului de automatizare ArchiTextură: Componente cheie

Înainte de a compara tipurile, este util să vedem ce conține fiecare cadru. ArchiTextura descrie modul în care aceste părți sunt stratificate astfel încât o modificare a unui strat să nu le distrugă pe celelalte.

  • Stratul scriptului de testare: Conține cazurile de testare. Scripturile rămân scurte deoarece apelează funcții reutilizabile în loc să repete pașii de navigare.
  • Bibliotecă de funcții: Stochează acțiuni partajate precum conectarea, căutarea și deconectarea, astfel încât o modificare a fluxului de lucru să se facă o singură dată.
  • Depozit de obiecte: Mapează nume prietenoase cu localizatoarele de elemente GUI. Când interfața se modifică, se editează doar acest strat.
  • Stratul de date de testare: Păstrează datele de intrare și valorile așteptate în Excel, CSV sau surse de baze de date, mai degrabă decât în ​​interiorul codului.
  • Stratul de configurare: Conține mediul URLs, opțiunile browserului, timeout-urile și acreditările.
  • Stratul de raportare: Produce rapoarte de execuție, capturi de ecran ale erorilor și jurnale de diagnosticare.
  • Stratul de execuție: Declanșează suite de pe un server de compilare, conectând automatizarea la integrare continuă.

Tipurile de cadre de mai jos diferă în principal prin cât de strict separă aceste straturi.

Tipuri de cadre de automatizare a testelor

Mai jos sunt diferitele tipuri de cadre de testare automată:

  1. Scriptare liniară
  2. Biblioteca de teste ArchiCadrul de tectură.
  3. Bazat pe date Testarea Cadru.
  4. Cadrul de testare bazat pe cuvinte cheie sau pe tabele.
  5. Cadrul de automatizare a testelor hibride.

Să le privim în detaliu -

1) Linear Scripting – Înregistrare și redare

Este cel mai simplu dintre toate cadrele de automatizare de testare și, de asemenea, cunoscut ca „Înregistrare și redare”. În acest Testarea automatizării Framework, Tester înregistrează manual fiecare pas (Navigație și intrări utilizator), Inserează puncte de control (Pași de validare) în prima rundă. Apoi , Redă scenariul înregistrat în rundele ulterioare.

Exemplu: Luați în considerare autentificarea Aplicație de rezervare a zborului și verificând dacă aplicația s-a încărcat la conectarea cu succes. Aici, testerul va înregistra pur și simplu pașii și va adăuga pașii de validare.

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
Dialog("Login").WinEdit("Password:").Set "Mercury"
Dialog("Login").WinButton("OK").Click
'Check Flight Reservation Window has loaded after successful log-on
Window("Flight Reservation").Check CheckPoint("Flight Reservation")

Avantaje

  • Cel mai rapid mod de a genera un script
  • Expertiza în automatizare nu este necesară
  • Cel mai simplu mod de a învăța caracteristicile Instrumentului de testare

Dezavantaje

  • Puțină reutilizare a scripturilor
  • Datele de testare sunt codificate în script
  • Coșmar de întreținere

2) Biblioteca de teste ArchiCadrul de tectură

Este cunoscut și ca „Scriptare structurată” or „Descompunere funcțională”.

În acest cadru de testare a automatizării, scripturile de testare sunt inițial înregistrate de „Înregistrați și redați”Metoda. Later, sarcinile comune din interiorul scripturilor sunt identificate și grupate în Funcții. Aceste funcții sunt apelate de scriptul de testare principal numit Şofer în moduri diferite pentru a crea cazuri de testare.

Exemplu: Folosind același exemplu ca mai sus, funcția de autentificare la Rezervare zbor va arăta ca .

Function Login()
  SystemUtil.Run "flight4a.exe","","","open"
  Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
  Dialog("Login").WinEdit("Password:").Set "Mercury"
  Dialog("Login").WinButton("OK").Click
End Function

Acum, veți apela această funcție în scriptul principal, după cum urmează

Call Login()
---------------------------
'Other Function calls / Test Steps.
---------------------------

Avantaje

  • Un nivel mai ridicat de reutilizare a codului este atins în Structured Scripting în comparație cu „Înregistrare și redare”
  • Scripturile de automatizare sunt mai puțin costisitoare de dezvoltat datorită reutilizării mai mari a codului
  • Întreținere mai ușoară a scriptului

Dezavantaje

  • Expertiza tehnică este necesară pentru a scrie Scripturi folosind Test Library Framework
  • Este nevoie de mai mult timp pentru planificarea și pregătirea scripturilor de testare.
  • Datele de testare sunt codificate greu în scripturi

3) Cadrul de testare bazat pe date

În acest cadru, în timp ce Caz de testare Logica se află în scripturile de testare, datele de testare sunt separate și păstrate în afara scripturilor de testare. Datele de testare sunt citite din fișierele externe (fișiere Excel, fișiere text, fișiere CSV, surse ODBC, obiecte DAO, obiecte ADO) și sunt încărcate în variabilele din interiorul scriptului de testare. Variabilele sunt utilizate atât pentru valorile de intrare, cât și pentru valorile de verificare. Scripturile de testare în sine sunt pregătite fie folosind scripturi liniare, fie Test Library Framework. Tehnica este explicată mai detaliat în testare bazată pe date tutorial.

Exemplu: Developing Scriptul de conectare la rezervarea zborului folosind această metodă va implica doi pași.

Pas 1) Creați un test - fișier de date care ar putea fi Excel , CSV sau orice altă sursă de bază de date.

Numele agentului Parolă
Jimmy Mercury
Tina MERCUR
Bill Mercur

Pas 2) Dezvoltați Scriptul de testare și faceți referințe la sursa dvs. de date de testare.

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set DataTable("AgentName", dtGlobalSheet)
Dialog("Login").WinEdit("Password:").Set DataTable("Password", dtGlobalSheet)
Dialog("Login").WinButton("OK").Click
'Check Flight Reservation Window has loaded
Window("Flight Reservation").Check CheckPoint("Flight Reservation")
'Note "dtGlobalSheet" is the default excel sheet provided by QTP.

Avantaje

  • Modificările aduse scripturilor de testare nu afectează datele de testare
  • Cazurile de testare pot fi executate cu mai multe seturi de date
  • O varietate de scenarii de testare pot fi executate prin simpla modificare a datelor de testare din fișierul de date extern

Dezavantaje

  • Este nevoie de mai mult timp pentru a planifica și pregăti atât scripturile de testare, cât și datele de testare

4) Cadrul de testare bazat pe cuvinte cheie sau bazat pe tabel

Bazat pe cuvinte cheie sau dezvoltarea unui framework de automatizare bazat pe tabele necesită tabele de date și cuvinte cheie, independent de instrument de testare automată folosit pentru a le executa. Testele pot fi proiectate cu sau fără Aplicație. Într-un test bazat pe cuvinte cheie, funcționalitatea aplicației în curs de testare este documentată într-un tabel, precum și în instrucțiuni pas cu pas pentru fiecare test.

Există 3 componente de bază ale unui cadru bazat pe cuvinte cheie și anume. Cuvânt cheie , Harta aplicației , Funcție componente.

Cuvântul cheie este o acțiune care poate fi efectuată pe o componentă GUI. Ex. Pentru GUI Component Textbox, unele cuvinte cheie (Acțiune) ar fi InputText, VerifyValue, VerifyProperty și așa mai departe.

Ce este harta aplicației?

O hartă a aplicației oferă referințe denumite pentru componentele GUI. Hărțile aplicațiilor nu sunt altceva decât „Depozit de obiecte

Ce este Component Function?

Funcțiile componente sunt acele funcții care manipulează sau interoghează în mod activ componenta GUI. Un exemplu de funcție ar fi faceți clic pe butonul web cu toate gestionarea erorilor, introduceți datele într-o editare web cu toate gestionarea erorilor. Funcțiile componentelor pot fi dependente de aplicație sau independente.

Exemplu: Pentru a înțelege Vizualizarea cuvintelor cheie, să luăm același exemplu. Aceasta presupune 2 pași

Etapa 1: Crearea tabelului de date (diferit de tabelul de date de testare creat în Data Driven Framework). Acest tabel de date conține acțiuni care trebuie efectuate asupra obiectelor GUI și argumentele corespunzătoare, dacă există. Fiecare rând reprezintă un pas de testare.

Obiect Acțiune
(HARTA aplicației) (CUVINTE CHEIE) Argument
WinEdit(Numele agentului) set Guru99
WinEdit(parolă) set Mercury
WinButton(OK) Clic
Fereastra (rezervarea zborului) Verifica Exista

Etapa 2: Scrisul Code sub formă de funcții componente.

Odată ce ați creat tabelele de date, pur și simplu scrieți un program sau un set de scripturi care citește în fiecare pas, execută pasul pe baza cuvântului cheie conținut în câmpul Acțiune, efectuează verificarea erorilor și înregistrează orice informații relevante. Acest program sau set de scripturi ar arăta similar cu pseudocodul de mai jos:

Function main()
{
  Call ConnectTable(Name of the Table) { //Calling Function for connecting to the table.
  while (Call TableParser() != -1) //Calling function for Parsing and extracting values from the table.
  {
    Pass values to appropriate COMPONENT functions. Like Set(Object Name, Argument) ex. Set(Agent Name, Guru99).
  }
}
  Call CloseConnection() //Function for Closing connection after all the operation has been performed.
} //End of main

Asta se referă la Cadrul bazat pe cuvinte cheie.

Avantajul cadrului bazat pe cuvinte cheie este că cuvintele cheie sunt reutilizabile. Pentru a înțelege acest lucru, considerați că doriți să verificați operațiunea de conectare pentru un site web, spune YAHOO MAIL. Tabelul va arăta așa -

Obiect Acțiune
(HARTA APLICAȚILOR) (CUVANT-CHEIE) Argument
WebEdit(Nume utilizator) set abc@yahoo.com
WebEdit(parolă) set xxxxx
WebButton(OK) Clic
Fereastra (Yahoo Mail) Verifica Loturile

Dacă observați în acest caz, cuvintele cheie Set, Click, Verify rămân aceleași, pentru care funcțiile componentelor corespunzătoare sunt deja dezvoltate. Tot ce trebuie să faceți este să modificați Harta Aplicației.ping (Depozit de obiecte) din rezervarea anterioară de zbor către Yahoo Mail , cu o schimbare a valorilor argumentului și același script va funcționa!

Avantaje

  • Oferă o reutilizare ridicată a codului
  • Instrument de testare independent
  • Independent de aplicația în curs de testare, același script funcționează pentru AUT (cu unele limitări)
  • Testele pot fi proiectate cu sau fără AUT

Dezavantaje

  • Investiția inițială fiind destul de mare, beneficiile acestui lucru pot fi realizate doar dacă aplicația este considerabil de mare și scripturile de testare urmează să fie menținute pentru câțiva ani.
  • Este necesară o expertiză înaltă în automatizare pentru a crea cadrul bazat pe cuvinte cheie.

NOTA: Chiar dacă OpenText UFT One (fostul Micro Focus) UFT) se promovează ca un framework bazat pe cuvinte cheie, nu puteți obține independență completă față de instrumentele de testare și aplicații folosindu-l.

5) Cadrul de automatizare a testelor hibride

După cum sugerează și numele, acest cadru este o combinație a unuia sau mai multor cadre de automatizare discutate mai sus, trăgând din punctele lor forte și încercând să le atenueze punctele slabe. Cadrul hibrid de automatizare QA test este ceea ce majoritatea cadrelor de automatizare a testelor evoluează în timp și în mai multe proiecte. Maximum Industry folosește Keyword Framework într-o combinație de metoda de descompunere a funcției.

PS: Alte cadre de automatizare care merită menționate sunt

Testarea cadrului de modularitate

În acest cadru, o sarcină comună în scriptul de testare este grupată ca module.

ExempluUtilizarea acțiunilor în QTP utilizarea poate crea scripturi modulare

Exemplu de script pentru autentificare

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
Dialog("Login").WinEdit("Password:").Set "Mercury"
Dialog("Login").WinButton("OK").Click
'End of Script

Acum puteți apela această acțiune în scriptul principal, după cum urmează -

RunAction ("Login[Argument]", oneIteration)

Testarea proceselor de afaceri (BPT)

Aceste cadre de automatizare descompun procesele mari de afaceri în Componente care pot fi reutilizate de mai multe ori în scripturi de testare identice sau diferite. De exemplu, procesul de afaceri de rezervare a unui zbor este împărțit în componente precum Conectare , Găsire zboruri , Rezervare , Plată și deconectare, care pot fi reutilizate în același proces de afaceri sau în procese diferite. De asemenea, BPT facilitează o coordonare mai strânsă între IMM-uri și inginerii de automatizare.

Cum să alegi framework-ul potrivit de automatizare a testelor

Niciun tip nu câștigă de fiecare dată. Alegerea corectă depinde de abilitățile echipei, de dimensiunea aplicației și de cât timp trebuie să supraviețuiască suita. Tabelul de mai jos compară cele cinci tipuri în funcție de factorii care decid rezultatul.

Tip cadru Efort de configurare Code Reutilizare Costul întreținerii Cel mai potrivit pentru
Scriptare liniară Foarte jos Foarte jos Foarte inalt Demonstrații și verificări unice ale fumului
Biblioteca de teste Architectură Mediu Mediu Mediu Aplicații stabile cu fluxuri de lucru repetate
Pe bază de date Mediu Mediu Scăzut Formulare și calcule care necesită mai multe seturi de date de intrare
Bazat pe cuvinte cheie Înalt Foarte inalt Scăzut Suite mari întreținute de echipe tehnice mixte
Hibrid Înalt Foarte inalt Scăzut Programe de lungă durată pentru întreprinderi

Lucrează la aceste întrebări înainte de a te angaja:

  1. Cât timp va rezista suita? Ani de întreținere justifică investiția inițială mare într-un design bazat pe cuvinte cheie sau hibrid. Un proiect scurt nu o face.
  2. Cine scrie testele? Dacă testerii manuali contribuie cu cazuri, un tabel de cuvinte cheie le permite să lucreze fără a învăța limbajul de scripting.
  3. Cât de volatilă este interfața? Schimbarea frecventă a ecranului face esențială existența unui depozit separat de obiecte, altfel fiecare script necesită editare.
  4. Câtă variație a datelor este necesară? Multe combinații de intrări indică direct un design bazat pe date.
  5. Ce instrument este deja utilizat? Cadrul trebuie să se potrivească cu cele alese instrument de automatizare și o limbă pe care echipa o cunoaște, cum ar fi Selenium implementate cu Java or Cucumber.

Majoritatea echipelor încep cu o abordare bazată pe biblioteci sau date, apoi evoluează către un model hibrid pe măsură ce regres suita se extinde.

Beneficiile cadrului de automatizare a testelor Architectură

Următoarele sunt beneficiile arhitecturii cadru de automatizare a testelor:

  • Un cadru de automatizare a testelor ajută la reducerea riscurilor și a costurilor
  • Îmbunătățește eficiența testelor
  • Ajută la reducerea costurilor de întreținere
  • Permite reutilizarea codului
  • Permite realizarea unei acoperiri maxime de testare
  • Maximizează funcționalitatea aplicației
  • Ajută la reducerea dublării cazurilor de testare
  • Ajută la îmbunătățirea eficienței și performanței testului cu automatizarea testului

Întrebări frecvente

Un instrument execută comenzi împotriva unei aplicații. Un framework este setul înconjurător de convenții, structuri de foldere și biblioteci reutilizabile care decid modul în care aceste comenzi sunt scrise, organizate și întreținute.

Nu. Modelul de Obiecte de Pagină este un model de design pentru stratul depozitului de obiecte. Este utilizat în mod obișnuit în cadrul bibliotecilor, al framework-urilor bazate pe date și al celor hibride, în loc să le înlocuiască.

IA adaugă localizatori de auto-reparare și comparații vizuale la stratul depozitului de obiecte. Arhitectura stratificată rămâne aceeași, dar scripturile se întrerup mai rar atunci când interfața utilizator se modifică ușor.

Da. Asistenții inteligenți artificiali convertesc pașii scriși în rânduri de obiecte, acțiuni și argumente. Un recenzent trebuie să confirme în continuare că numele obiectelor corespund cu repozitoriul, altfel rândurile generate eșuează la momentul execuției.

Track ore de mentenanță a scriptului per versiune, procentul de erori instabile și timpul de la compilare până la rezultat. Un framework sănătos arată o scădere a efortului de mentenanță, în timp ce acoperirea automatizată continuă să crească.

Rezumați această postare cu: