KVTP-Tutorial # 18-datadrevne og hybride rammer forklaret med KVTP-eksempler

KVTP-Tutorial # 18-datadrevne og hybride rammer forklaret med KVTP-eksempler

vi arbejder os gennem at finde ud af, hvordan vi udleder en Automatiseringsramme, der fungerer bedst til et bestemt testprojekt og også definerer visse rammer, der allerede findes.

det eksempel, som vi brugte i den forrige RAMMEARTIKEL, var at oprette en ny Gmail-konto.

til at begynde med kodede vi oprettelsen af et nyt kontoscenarie bare ved optagelse og afspilning på en lineær måde. Da vi så, hvor meget det manglede i modularitet, læsbarhed og genanvendelighed, brød vi det ned i funktioner, der ville blive henvist til som nøgleord fremad.

=> Klik her for at læse mere om

vi opnåede modularitet, læsbarhed og genanvendelighed gennem denne metode, men vi var nødt til at gøre programmet endnu mere robust, så det kan tage forskellige sæt værdier uden at skulle ændre selve scriptet.

det er præcis, hvad vi skal opnå ved data, der kører testene.

datadrevet Automatiseringsramme ved hjælp af ktp

oprettelse af flere Google-brugerkonti er en opgave, som vi vil forsøge at udføre ved hjælp af denne ramme.

i det tidligere eksempel hardkodede vi fornavn, efternavn, bruger-id-detaljer osv. ind i vores kode, mens du prøver at oprette en konto. Vi bliver nødt til at adskille koden fra dataene, hvis vi skal opnå datakøringsaspektet for dette script.

dataene skal komme fra en kilde, der ikke er selve programmet.

typisk Data input kan være noget:

• filer
• Database
• tekstfiler
• ….osv.

er dem, der bliver brugt oftest. Selve det faktum, at hver handling er integreret med et eget datablad, forklarer, hvorfor det er sådan.

du kan bruge en eller flere datakilder til et enkelt script. Det ark, der følger med handlingen, kan bruges, eller du kan også bruge et eksternt ark. Grundlæggende kan et datablad være enhver relevant ekstern fil.

for eksempel,

her er den kode, vi har brug for til datadrev:

Browser("Gmail: Email from Google").Page("GoogleAccounts").WebEdit("FirstName").Set "swati"Browser("Gmail: Email from Google").Page("Google Accounts").WebEdit("LastName").Set "s"Browser("Gmail: Email from Google").Page("Google Accounts").WebEdit("GmailAddress").Set "test"

alle data lige nu er hardcoded. Lad os nu se, hvordan vi kan tage disse værdier fra databladet.

gå til ekspertvisningen for sætningen i KTP, og klik på kolonnen Værdi for et trin.

følgende vindue åbnes:

Vælg parameterindstillingen, Vælg et navn til parameteren (dette vil være kolonnenavnet i dataarket), og vælg, om du vil bruge det globale ark eller det lokale ark (globalt ark er tilgængeligt for alle handlingerne i en test, men det lokale ark er specifikt for den aktuelle handling).

for feltet” Navn ” på skærmen giver ktp en standardværdi. Brugeren har mulighed for at holde det samme eller ændre det.

når du klikker på OK, oprettes en ny kolonne i datatabellen.

Sådan ser det dataark, der indeholder 3 sæt fornavn, efternavn og konto-id ud:

når parameteriseret, ser koden ud som vist nedenfor:

Browser("Gmail: Email from Google").Page("Google Accounts").WebEdit("FirstName").Set DataTable("G_First_Name", dtGlobalSheet)Browser("Gmail: Email from Google").Page("Google Accounts").WebEdit("LastName").Set DataTable("G_Last_Name", dtGlobalSheet)Browser("Gmail: Email from Google").Page("Google Accounts").WebEdit("GmailAddress").Set DataTable("gmail_address", dtGlobalSheet)

hvis vi skal oprette disse 3 bruger-id ‘ er med dataene i arket, skal vi have 3 iterationer. Iteration er intet andet end en testkørsel.

når dataene er konfigureret, bliver vi nødt til at instruere CTP om, hvor mange gange denne kode skal køre, eller hvor mange iterationer.

Sådan gør vi det: gå til fil – > Indstillinger og kør

på ovenstående skærm skal du indstille iterationsegenskaberne efter behov.

Alternativt kan du instruere iterationerne programmatisk. Som altid giver dette mulighed for mere kontrol såvel som programmeringsevner. Så det er virkelig op til testerens komfortniveau at vælge en af disse metoder.

komponenterne i den datadrevne ramme er:

1. Test script
2. datafiler
3. delt funktionelt bibliotek (hvis det findes eller kunne være et lineært program).
4. Objektlager (igen vil denne komponent ikke eksistere, hvis beskrivende programmering blev brugt til at oprette objekter).

testresultaterne viser en “bestået’ eller ‘mislykket’ status for hver testkørsel.

bortset fra den datatabel, der kommer som standard, kan vi bruge enhver ekstern fil som et inputark.

Hybrid ramme

i ovenstående eksempel brugte du nøgleord (navne på de funktioner, som brugeren har oprettet) og har datadrevet testen for at sikre, at forskellige brugere oprettes på samme tid. Dette er intet andet end en hybrid ramme.

kombinationen af to eller flere rammer, som vi hidtil har diskuteret, er en hybrid ramme. Efter min erfaring fungerer ingen rammer effektivt for et bestemt projekt. Hybridrammen er det, der bliver brugt oftest.

få vigtige punkter om rammer:

• rammen er bare en løsning, der fungerede bedst i en bestemt situation, men bør ikke fortolkes som et sæt regler, der skal følges definitivt. Det skal ses mere som retningslinjer.
• der kan være mange andre rammer i brug, Vi har kun listet og forklaret de fælles.
• nomenklatur – forskellige mennesker adresserer deres rammer med forskellige navne. Så hvis navnene er lidt forskellige fra en applikation til en anden, så er det normalt.
• de fleste rammer kan bruges sammen med hinanden, når en af dem ikke kan give en allround løsning til dine testmål.

konklusion

af hensyn til let forståelse har vi virkelig forenklet begreberne i rammen her.

hvis du har rammerelaterede problemer, som du står over for, men ikke er dækket af disse artikler, så lad os det vide. Vi vil helt sikkert forsøge at besvare dine spørgsmål. Du er velkommen til at sende dine spørgsmål.

=> besøg her for at se serien med KVALITETSUDDANNELSESVEJLEDNINGER