Testi automatiseerimise raamistik: mis on ArchiTektuur ja tüübid

Mis on automatiseerimise testimise raamistik?

A Testi automatiseerimise raamistikku on juhiste kogum, nagu kodeerimisstandardid, testandmete töötlemine, objektihoidla töötlemine jne, mida automatiseerimisel skriptimisel järgides saavutatakse kasulikke tulemusi, nagu suurem koodi korduskasutus, suurem kaasaskantavus, väiksemad skripti hoolduskulud jne. Need on vaid juhised ja mitte. reeglid; need ei ole kohustuslikud ja saate siiski skriptida ilma juhiseid järgimata. Kuid jääte kasutamata raamistiku eelistest.

Miks vajate raamistikku?

Vaatleme näidet, et mõista, miks teil raamistikku vaja on.

Olen kindel, et olete osalenud seminaril/loengul/konverentsil, kus osalejatel paluti järgida järgmisi juhiseid:

• Osalejad peavad oma kohad hõivama 5 minutit enne loengu algust.
• Märkmete tegemiseks võtke kaasa märkmik ja pliiats.
• Lugege kokkuvõtet, et saaksite aimu, millest esitlus räägib.
• Mobiiltelefonid tuleks häälestada.
• Kui soovite keset loengut lahkuda, kasutage kõneleja vastaspoolses otsas olevaid väljapääsuväravaid.
• Seansi lõpus esitatakse küsimused.

Kas arvate, et saate seminari läbi viia? ILMA järgides neid juhiseid👍

Vastus on suur JAH! Kindlasti saab seminari/loengu/konverentsi/demonstratsiooni läbi viia ka ilma ülaltoodud juhisteta... tegelikult ei järgi mõned meist neid, kuigi need on paika pandud!

Kui aga juhiseid järgitakse, on selle tulemuseks kasulikud tulemused, nagu väheneb kuulajate tähelepanu hajutamine loengute ajal, suurem osalejate püsivus ja teema mõistmine.

Eeltoodust lähtuvalt a Raamistiku võib määratleda kui juhiste kogumit, mille järgimine annab kasulikke tulemusi.

Testimise automatiseerimise raamistike tüübid

Allpool on eri tüüpi automatiseeritud testimise raamistikud.

• 1) Lineaarne skriptimine
• 2) Test Library Architecture Framework.
• 3) Andmepõhine Testimine Raamistik.
• 4) Märksõnapõhine või tabelipõhine testimise raamistik.
• 5) Hübriidtesti automatiseerimise raamistik.

Vaatame neid üksikasjalikult -

1) Lineaarne skriptimine – salvestamine ja taasesitus

See on testimise automatiseerimise raamistikest lihtsaim ja tuntud ka kui "Salvestamine ja taasesitus". Selle Automatiseerimise testimine Framework, Tester salvestab käsitsi iga sammu (navigeerimine ja kasutaja sisendid), lisab kontrollpunktid (valideerimisetapid) esimeses voorus. Seejärel esitab ta salvestatud stsenaariumi järgmistes voorudes.

Näide: Kaaluge sisselogimist Lennu broneerimise taotlus ja kontrollige, kas rakendus on edukal sisselogimisel laaditud. Siin salvestab testija lihtsalt sammud ja lisab valideerimisetapid.

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")

Eelised

• Kiireim viis skripti loomiseks
• Automatiseerimisalased teadmised pole vajalikud
• Lihtsaim viis testimistööriista funktsioonide õppimiseks

Puudused

• Vähene skriptide taaskasutus
• Testi andmed on skripti sisse kodeeritud
• Hooldus õudusunenägu

2) Test Library Architecture Framework

Seda tuntakse ka kui "Struktureeritud skriptimine" or "Funktsionaalne lagunemine".

Selles automatiseerimise testimise raamistikus salvestab testskriptid algselt "Salvestamine ja taasesitus”Meetod. Later, tuvastatakse skriptides levinud ülesanded ja rühmitatakse need funktsioonideks. Neid funktsioone kutsub esile kutsutud peamine testskript juht erinevatel viisidel testjuhtumite loomiseks.

Näide: Kasutades ülaltoodud näidet, näeb lennubroneeringusse sisselogimise funktsioon välja selline .

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

Nüüd kutsute seda funktsiooni põhiskriptis järgmiselt

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

Eelised

• Struktureeritud skriptimise puhul saavutatakse kõrgem koodi taaskasutamise tase võrreldes funktsiooniga "Salvestamine ja taasesitus"
• Automatiseerimisskriptide arendamine on koodi suurema taaskasutuse tõttu odavam
• Lihtsam skripti hooldus

Puudused

• Skriptide kirjutamiseks Test Library Frameworki abil on vaja tehnilisi teadmisi
• Testskriptide planeerimiseks ja ettevalmistamiseks on vaja rohkem aega.
• Testi andmed on skriptides kõvasti kodeeritud

3) Andmepõhise testimise raamistik

Selles raamistikus, samas Testjuhtum loogika asub testskriptides, testandmed eraldatakse ja hoitakse väljaspool testskripte. Testandmeid loetakse välistest failidest (Exceli failid, tekstifailid, CSV-failid, ODBC-allikad, DAO-objektid, ADO-objektid) ja laaditakse testskripti muutujatesse. Muutujaid kasutatakse nii sisendväärtuste kui ka kinnitusväärtuste jaoks. Testskriptid ise valmistatakse ette kas lineaarse skriptimise või testteegi raamistiku abil.

Näide: Lennu broneerimise sisselogimise skripti arendamine selle meetodi abil hõlmab kahte etappi.

Step 1) Looge test – andmefail, mis võib olla Excel , CSV või mõni muu andmebaasi allikas.

Agendi nimi	Parool
Jimmy	Mercury
Tina	ELAVHÕBE
Bill	Merkuur

Step 2) Töötage välja testskript ja viige oma testandmete allikale.

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.

Eelised

• Testskriptide muudatused ei mõjuta testandmeid
• Testjuhtumeid saab teostada mitme andmekogumiga
• Erinevaid teststsenaariume saab käivitada, muutes lihtsalt välises andmefailis olevaid testandmeid

Puudused

• Nii testskriptide kui ka testandmete kavandamiseks ja ettevalmistamiseks on vaja rohkem aega

4) Märksõnapõhine või tabelipõhine testimise raamistik

Märksõnapõhise või tabelipõhise automatiseerimisraamistiku arendamiseks on vaja andmetabeleid ja märksõnu, sõltumatu testimise automatiseerimise tööriist kasutatakse nende teostamiseks. Teste saab koostada koos rakendusega või ilma. Märksõnapõhises testis dokumenteeritakse testitava rakenduse funktsionaalsus tabelis ja iga testi jaoks samm-sammult juhistes.

Märksõnapõhisel raamistikul on kolm põhikomponenti, nimelt. Märksõna , rakenduste kaart , komponendi funktsioon.

Mis on märksõna?

Märksõna on toiming, mida saab teha GUI komponendiga. Nt. GUI komponendi tekstikasti puhul oleksid mõned märksõnad (tegevus) InputText, VerifyValue, VerifyProperty ja nii edasi.

Mis on rakenduskaart?

Rakenduse kaart sisaldab GUI komponentide nimelisi viiteid. Rakenduste kaardid pole midagi muud kui "Objektide hoidla"

Mis on komponendi funktsioon?

Komponendi funktsioonid on need funktsioonid, mis GUI komponenti aktiivselt manipuleerivad või küsitlevad. Funktsiooni näide oleks klõpsa veebinupul koos kogu veakäsitlusega , sisestage andmed veebiredigeerimisse koos kõigi vigade käsitlemisega. Komponentide funktsioonid võivad olla rakendusest sõltuvad või sõltumatud.

Näide: Märksõnavaate mõistmiseks võtame sama näite. See hõlmab 2 sammu

Samm 1: Andmetabeli loomine (erineb andmepõhises raamistikus loodud testandmete tabelist). See andmetabel sisaldab GUI objektidega tehtavaid toiminguid ja vastavaid argumente, kui neid on. Iga rida tähistab ühte testietappi.

objekt	tegevus
(Rakenduse MAP)	(MÄRKSÕNAD)	Argument
WinEdit (agendi nimi)	komplekt	Guru99
WinEdit (parool)	komplekt	Mercury
WinButton (OK)	Click
Aken (lennu broneerimine)	Kontrollima	Olemas

Samm 2: Koodi kirjutamine komponentfunktsioonide kujul.

Kui olete oma andmetabeli(d) loonud, kirjutage lihtsalt programm või skriptide komplekt, mis loeb iga sammu, käivitab sammu väljal Action sisalduva märksõna alusel, teostab veakontrolli ja logib kogu asjakohase teabe. See programm või skriptide komplekt näeks välja sarnane alloleva pseudokoodiga:

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

See on märksõnapõhise raamistiku jaoks kõik.

Märksõnapõhise raamistiku eeliseks on see, et märksõnad on taaskasutatavad. Selle mõistmiseks kaaluge, kas soovite veebisaidile sisselogimistoiminguid kontrollida, öelge YAHOO MAIL. Tabel näeb välja selline -

objekt	tegevus
(RAKENDUSKAART)	(MÄRKSÕNA)	Argument
WebEdit (kasutajanimi)	komplekt	abc@yahoo.com
WebEdit (parool)	komplekt	xxxxx
WebButton (OK)	Click
Aken (Yahoo Mail)	Kontrollima	Saadetised

Kui jälgite antud juhul märksõnade komplekti , klõpsamist , kontrollimist, jäävad samaks, mille jaoks vastavad komponendi funktsioonid on juba välja töötatud. Kõik, mida pead tegema, on rakenduse kaardistamise (objektihoidla) muutmine varasemast lennureserveeringust Yahoo-le Mail , argumendi väärtuste muutmisega ja sama skript töötab!

Eelised

• Pakub koodi kõrget taaskasutatavust
• Testtööriist Sõltumatu
• Sõltumata testitavast rakendusest töötab sama skript AUT-i jaoks (mõningate piirangutega)
• Teste saab koostada AUT-ga või ilma

Puudused

• Kuna esialgne investeering on üsna suur, saab sellest kasu realiseerida ainult siis, kui rakendus on märkimisväärselt suur ja testskripte tuleb säilitada päris mitu aastat.
• Märksõnapõhise raamistiku loomiseks on vaja kõrgeid automatiseerimise oskusi.

NOTE: Kuigi Micro Focus UFT reklaamib end märksõnapõhise raamistikuna, ei saa te HP UFT-i kasutades saavutada täielikku testitööriista ja rakenduste sõltumatust.

5) Hübriidtesti automatiseerimise raamistik

Nagu nimigi viitab, on see raamistik kombinatsioon ühest või mitmest eespool käsitletud automatiseerimisraamistikust, mis lähtub nende tugevustest ja püüab leevendada nende nõrkusi. Hübriidtesti kvaliteedi tagamise automatiseerimisraamistik on see, milleks enamik testimise automatiseerimise raamistikke areneb aja jooksul ja mitme projekti käigus. Maksimaalne tööstus kasutab märksõnade raamistikku funktsioonide lagunemise meetodi kombinatsioonis.

PS: Muud mainimist väärivad automatiseerimisraamistikud

Modulaarsuse raamistiku testimine

Selles raamistikus on testskripti ühised ülesanded rühmitatud mooduliteks.

Näide: Toimingute kasutamine QTP-s võib luua moodulskripte

Sisselogimise näidisskript

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

Nüüd saate seda toimingut põhiskriptis nimetada järgmiselt -

RunAction ("Login[Argument]", oneIteration)

Äriprotsesside testimine (BPT)

Need automatiseerimisraamistikud jagavad suured äriprotsessid komponentideks, mida saab samades või erinevates testskriptides mitu korda uuesti kasutada. Näiteks lennu broneerimise äriprotsess on jagatud sellisteks komponentideks nagu sisselogimine , lendude otsimine , broneerimine , maksmine ja väljalogimine , mida saab uuesti kasutada samas äriprotsessis või erinevates protsessides. Samuti hõlbustab BPT VKEde ja automaatikainseneride vahelist tihedamat koordineerimist.

kokkuvõte

• Raamistik on juhiste kogum, nagu kodeerimisstandardid, testandmete käitlemine, objektihoidla töötlemine jne, mida automatiseerimise skriptimise ajal järgides saavutatakse kasulikke tulemusi, nagu suurem koodi korduskasutus, suurem kaasaskantavus, väiksemad skripti hoolduskulud jne.
• Lineaarne skriptimine on kõigist automatiseerimisraamistikest lihtsaim ja tuntud ka kui "Salvestamine ja taasesitus".
• Testi raamatukogu Architecture Framework on tuntud ka kui "struktureeritud skriptimine" või "funktsionaalne lagunemine".
• Andmepõhise testimise raamistikus on testjuhtumi loogika testskriptides ning testandmed eraldatakse ja hoitakse väljaspool testskripte.
• Märksõnapõhine või tabelipõhine raamistik nõuab andmetabelite ja märksõnade väljatöötamist, sõltumata nende täitmiseks kasutatavast testimise automatiseerimise tööriistast .
• Hybrid Automation Framework on see, milleks enamik testimise automatiseerimise raamistikke areneb aja jooksul ja mitme projekti käigus.