QTP/UFT Automatiseringsrammeverk: Datadrevet, nøkkelord og hybrid
⚡ Smart oppsummering
Automatiseringsrammeverk i QTP/UFT organisere testskript, data og gjenbrukbare funksjoner slik at én test kan dekke mange tilfeller. Datadrevne, nøkkelorddrevne og hybride design passer hver for seg til en ulik blanding av input og gjenbrukbar logikk.
Datadrevet rammeverk
Et datadrevet rammeverk er et rammeverk som er drevet av ulike kombinasjoner av input- og outputdata.
En måte å sende forskjellige datakombinasjoner på er ved å ParametriseringI denne metoden bruker vi forskjellige funksjoner ved QTP.
Men i DDF er skript skrevet for å gjøre parameterisering. Denne typen rammeverk er nyttig når AUTs funksjonalitet må testes med flere innganger og fange opp de respektive utgangene. Disse inndataene kan leses fra en ekstern fil som Database, Excel, Outlook, Tekstfil osv., og de respektive utgangene skrives tilbake til den tilsvarende eksterne kilden, som illustrert nedenfor.
De generelle trinnene som er involvert i det datadrevne rammeverket er:
- Forbered Testsak for applikasjonen under test
- Legg til objektene fra AUT til OR
- Skriv skriptene basert på Test Case
I dette UFT tutorial, vil vi utvikle et datadrevet rammeverksdesign for et eksempel på en testtilfelle ved å bruke Excel som en ekstern kilde for testdataene.
Trinn 1) Forbered testtilfellet for applikasjonen som testes
Testsak: Åpne ordrenummeret og få kundenavnet for den bestillingen. Gjenta samme prosess for forskjellige ordrenummer
Ekstern kilde: Excel-fil
Den eksterne kilden for dette eksemplet er en Excel-fil. VB-skriptet i OpenText Funksjonell testing (UFT En, tidligere Micro Focus UFT) må skrives for å åpne en Excel-fil for å kunne lese testdataene. Dette kan oppnås på en hierarkisk måte.
1. En Excel-fil åpnes først og som applikasjon
2. Deretter må arbeidsboken åpnes fra det angitte stedet
3. Arket der testdataene finnes.
4. Til slutt må cellen leses.
Trinn 2) Legg til objektene fra AUT til OR
Når testsaken er klar, begynn å legge til alle nødvendige objekter til depotet. I vårt testtilfelle er objektene som må legges til som følger
1. "Åpne mappe"-ikonet i Søknad om flyreservasjon:
2. Avmerkingsboksen «Ordrenummer» som dukker opp når du klikker på ikonet «Åpne mappe»:
3. WinEdit-boksen for ordrenummeret (der numrene skrives inn):
4. OK-knappen:
5. «Navn»-feltet, som er en WinEdit-boks. Dette feltet fylles ut med et navn når du klikker på OK-knappen for et bestemt ordrenummer:
Når alle nødvendige objekter er lagt til, vil objektlageret vises som følger:
Trinn 3) Skriv skriptene basert på testtilfellet
Før du kjører skriptet, sørg for at Excel-filen som inneholder testdataene er lagret og lukket.
Nedenfor script er å lese ordrenummeret fra Excel og tilordne det til applikasjonen gjennom variabelen "vOrder" og skrive kundenavnet fra applikasjonen gjennom variabelen "vName".
Excel navn: FlightDDF.xlsx
Arknavn: Ark1
Produksjon
Når skriptet ovenfor er kjørt, kan utdata hentes fra Excel som følger:
Det datadrevne rammeverket kan også utvikles ved å skrive beskrivende programmering.
Bruke database som en ekstern kilde for DDF
Den samme testsaken kan utføres hvis den eksterne kilden er en database ved å bruke følgende trinn
- Skriv VBScript for å etablere databaseforbindelsen
- VBScript for å åpne et postsett eller en tabell.
- VBScript for å åpne ønsket felt
- Den bestemte cellen leses fra feltet.
Script
To Establish a Microsoft Database connection
Driver = {Microsoft Access Driver (*.mdb)}; DBQ =
Navn på postsett: OpenOrder
Feltnavn: Ordrenummer, kundenavn
PS: Microsoft Access 2010 kan ikke kobles til ved hjelp av skriptet nedenfor.
Produksjon
Fordeler med DDF
- Et stort antall testdata kan leses og skrives inn i den eksterne filen i en enkelt test
- Loop statement brukes til å gjenta de samme trinnene for flere iterasjoner. Derfor reduseres kodeinnsatsen
- Siden dataene leses og skrives direkte inn i den eksterne filen, er det ikke nødvendig å kopiere, lime inn eller eksportere data for å bruke dem
- Testdata kan leses fra en ekstern fil og utdataene kan skrives inn i en hvilken som helst annen ekstern fil
Ulemper med DDF
- Manuskunnskap er nødvendig for å utvikle dette rammeverket
- Noen ganger kan et antall eller kombinasjoner av data fra en ekstern kilde, som en database, redusere hastigheten eller til og med krasje systemet. QTP
Nøkkelorddrevet rammeverk
Et søkeorddrevet rammeverk er et rammeverk der søkeord styrer testen. Her nøkkelordet refererer til brukerdefinerte funksjoner. I dette rammeverket opprettes nøkkelord for å utføre et bestemt testtrinn eller en testcase. Disse nøkkelordene blir deretter kalt inn i førertesten for å kjøre flere testtilfeller i samme test.
Generelt kan rammeverkene utvikles på tre måter for å prøves ut.
- Opptak og kjøring testen
- Legg til objekter til det lokale depotet og skriv skriptene for alle testtrinn
- Skriv beskrivende programmering for alle testtrinn
I denne opplæringen er KDF utviklet ved å ta opp og kjøre testen.
Vårt mål er å kjøre en enkelt test for fem forskjellige testtilfeller, for eksempel innlogging i applikasjonen, legge inn en bestilling, åpne en bestilling, slette en bestilling og lukke applikasjonen. Derfor vil vi registrere testtrinnene for disse testtilfellene og lage funksjonene med nøkkelordene Login, InsertOrder, OpenOrder, DeleteOrder og CloseApp.
Test Case1: Logg på applikasjonen
søkeord: Logg inn ()
Innspilt skript:
Testtilfelle2: Sett inn bestillingen
søkeord:InsertOrder()
Innspilt skript:
Testtilfelle3: Åpne bestillingen
søkeord:OpenOrder()
Innspilt skript:
Testtilfelle 4: Slett bestillingen
søkeord:DeleteOrder()
Innspilt skript:
Testtilfelle 5: Lukk applikasjonen
søkeord:CloseApp()
Innspilt skript:
Funksjonene som lages for ulike testtilfeller lagres i et funksjonsbibliotek og er knyttet til hovedtesten. Det er nok å kalle nøkkelordene for de nødvendige testtilfellene i hovedtesten og dermed redusere størrelsen på driverskriptet i hovedtesten.
Driverskriptet for dette enkle rammeverket ser slik ut:
Ved å kjøre skriptet ovenfor kan det faktiske resultatet for alle de fem testtilfellene fås fra en enkelt test.
Fordeler
- Et hvilket som helst antall testtilfeller kan kjøres på en enkelt test bare ved å kalle deres respektive nøkkelord
- Å skrive generell beskrivende programmering for alle web-/Windows-objekter og kalle dem som nøkkelord vil hjelpe deg med å kjøre den samme testen for forskjellige dynamiske applikasjoner
- Reduserer størrelsen på driverskriptet
Ulemper
- Tiden det tar å utvikle disse rammeverkene er svært høy hvis det er svært få antall testcaser å kjøre
- Registrering av trinnene brukes ikke alltid når du designer KDF for mange applikasjoner på samme test.
Hybrid rammeverk
Et hybrid rammeverk er en kombinasjon av datadrevet rammeverk (DDF) og nøkkelorddrevet rammeverk (KDF) der flere testtilfeller med flere input kan kjøres i samme test.
I denne artikkelen vil de samme testtilfellene som brukes i KDF bli utført i én enkelt test. Nøkkelordene og skriptene for alle testtilfellene er de samme som i KDF. TC3: Åpne ordren er imidlertid parametrisert. Derfor er skriptet for denne testtilfellet skrevet for å motta ordrenummeret fra en Excel-fil og skrive kundenavnet inn i Excel-filen.
Test Case1: Logg på applikasjonen
søkeord: Logg inn ()
Testtilfelle2: Sett inn bestillingen
søkeord:InsertOrder()
Testtilfelle3: Åpne bestillingen for flere bestillingsnumre
søkeord:OpenOrder()
Description: Her brukes det samme skriptet som brukes til å utvikle en DDF, og oppnår dermed testcasen for flere iterasjoner.
Manus:
Testtilfelle 4: Slett bestillingen
søkeord:DeleteOrder()
Testtilfelle 5: Lukk applikasjonen
søkeord:CloseApp()
Ved å følge denne enkle metoden oppnås parameteriseringen av TC3. Hvis det er aktuelt, kan alle de andre testtilfellene også parameteriseres i samme test.
Eksemplet ovenfor er en veldig enkel måte å designe et hybridrammeverk på. Det samme rammeverket kan også oppnås med beskrivende programmering.
Fordeler
- Tiden det tar å kjøre testen designet med et hybrid rammeverk er relativt kortere sammenlignet med andre rammeverk
- Dette kan brukes når vi trenger alle testtilfellene og inngangene som er knyttet til en bestemt testsak, i samme testsuite.
Ulempe
- Det kreves klar kunnskap om det å kombinere ulike rammeverk.




















