how translate manual test cases into automation scripts
Dette vil være den grundlæggende 'how-to' -artikel og er ikke nogen automatiseringsværktøjsspecifik. Grundlæggende er det, jeg prøver at gøre her, at sætte tankeprocessen, der går i at skabe en automatiseringstestsag, ord. Som altid håber jeg, at dette vil være nyttigt for jer alle.
Hvordan man designer en automatiseringstest eller script?
Automatisering følger altid manuel testning. Typisk vil en eller flere runder af manuel testning allerede blive udført på AUT. Dette indebærer, at manuelle testsager allerede findes og er blevet udført mindst én gang.
For eksempel, antag, at følgende er din Manuel test sag . Det logger simpelthen på Gmail.com-webstedet. Nu ser det simpelt nok ud, ikke? Hvordan bliver dette et automatiseringsscript? (klik på billedet for at forstørre det)
Hvad du vil lære:
Sådan oversættes denne manuelle testkasse til et automatiseringsscript?
Følgende er de retningslinjer, vi skal følge for at opnå oversættelsen til et automatiseringsskript:
# 1) Tilstand for AUT: Kolonnens forudsætning er intet andet end en bestemt tilstand af baggrunden, der skal indstilles for, at et bestemt trin udføres. Dette er især vigtigt i to scenarier:
- For at starte testen: I dette tilfælde har vi brug for browseren tilgængelig og startet. (Tilgængeligheden af brugernavnet og adgangskoden behandles om et stykke tid). Nu, hvordan man skriver det samme i automatiseringsverdenen? Overvej QTP. Du har en mulighed for enten at starte browseren ved hjælp af programmatiske udsagn, eller du kan bruge dialogen 'optag og kør indstilling' til at indstille egenskaberne. Det er meget afgørende at indstille disse egenskaber korrekt. Ofte er dette grunden til, at et bestemt stykke kode fungerer i en maskine og ikke fungerer i de andre.
- At udføre et bestemt trin : For at trin 2 skal udføres, skal trin 1 være udført og gennemført. For at gøre det manuelt kan vi bare vente, indtil trinudførelsen er færdig, og siden indlæses fuldt ud. Brug synkroniseringen, eller vent på, at udsagn i dit automatiseringsscript venter, indtil den ønskede tilstand går i opfyldelse.
Bemærk: Når du kører den samme kode til flere datasæt, vil du sørge for, at du returnerer AUT til den tilstand, som det skulle være inden næste iterationsstart.
# 2) Teststrin
Vi kan kategorisere de manuelle testtrin i 3 kategorier:
- Indtastning af data : Dataindtastningstrin er hvor du indtaster nogle oplysninger som input til din AUT.
- Ændring af AUT-tilstandstrin : disse trin er dem, der får en ændring til din AUT. Det kan omfatte at gå en ny side, et bestemt felt er synligt, et redigeringsfelt, der kan redigeres osv.
- Kombination : som navnet antyder, er dette kombinationen af begge ovenstående typer. Tag tilfældet med et afkrydsningsfelt, når det er slået til vil det gøre et bestemt felt aktivt. I så fald indtaster du værdien 'Sand' for afkrydsningsfeltet, og det resulterer også i en tilstand af din AUT.
I ovenstående testtilfælde findes der kun trin 1 og 2.
- Type 1: testtrin 2 & 3
- Type 2: Testtrin 1 & 4
Forudsætningen for at oprette et automatiseringsskript ved hjælp af ethvert værktøj er at bruge lidt tid på at analysere værktøjet såvel som AUT. Prøv at se, hvordan de begge interagerer med hinanden. For eksempel, QTP har 3 optagemåder, og hver fungerer på en anden måde.
Hvis du ved, hvordan det identificerer objekter, ved du, hvilken der skal bruges og bruger dem bedre. Hvis du har en webapp, hvor QTP nemt kan identificere objekterne, kan du bruge den normale tilstand. Hvis ikke er du muligvis nødt til at bruge de analoge eller lave niveauer.
Automatiseringstrin:
- Trin for indtastning af data er ikke meget forskellige i automatiserings- og manuelle metoder. Alt hvad du gør er at indtaste dataene. Den måde, du henviser til feltet på, er anderledes. Da det vil være maskine, der udfører trinnene, skal vi bare sørge for, at vi henviser til felterne i AUT på en måde, som værktøjet forstår. Det betyder, at du skal bruge dets logiske navn som brugt i koden.
- Til ændring af AUT / kombinationstrin i et manuelt scenarie udfører du handlingen (klikke eller kontrollere eller indtaste) og bekræfte ændringen på én gang. Men i et automatiseringsscenarie er det ikke muligt. Så vi er nødt til at sikre, at vi tilføjer trin til handling og validering / verifikation.
- Kommentarer for læsbarhed.
- Fejlfindingserklæringer - disse er især vigtige, hvor du opretter og tester selve testen. Prøv at bruge meddelelsesbokse ofte til at udlæse forskellige værdier på forskellige stadier af testudførelsen. Dette giver dig synlighed i testen, som intet andet ville.
- Output-erklæringer - til skriv til resultater eller ethvert andet eksternt sted som et notesblok eller excel-ark.
# 3) Bekræftelse og validering
Uden verifikation og validering mistes testens hensigt. Typisk bliver du nødt til at bruge et kontrolpunkt (betyder ikke nødvendigvis de indbyggede). Så du bliver nødt til at bruge mange betingede udsagn og også loop-udsagn for at opbygge logikken.
En vigtig ting at overveje er - attributten, som du baserer din V&V på, skal ikke være tvetydig. For eksempel, for vellykket login skal du kigge efter indbakke-sidevisningen ikke efter antallet af nye e-mails, fordi det ikke er en konstant værdi.
Så du skal vælge noget, der er sandt, hver gang et sæt operationer sker - uden fejl.
# 4) Testdata
Følgende er nogle af de spørgsmål, som du måske overvejer at besvare til dine testdatakrav:
- Hvor skal man placere det?
- Til hardcode eller ej?
- Sikkerhedsmæssige bekymringer?
- Bekymringer vedrørende genanvendelighed?
Når du ser tilbage på det manuelle testscript, vil du bemærke, at det at have testdataene, brugernavnet og adgangskoden til rådighed er en af forudsætningerne for endda at starte testen.
# 5) Resultater
For en manuel testsag kan du placere resultatet af hvert trin i kolonnen 'Faktisk resultat'. Et automatiseringsværktøjs resultatfil indeholder resultatet af hvert trin, når det udføres.
Automatiseringsværktøjer har i disse dage meget robuste rapporteringsfunktioner. Du skal dog muligvis stadig skræddersy Test resultater . Så inkluder trinene til at skrive ofte til resultatfilen, så du ved præcis, hvad der skete, mens udførelsen foregik.
Hvis det værktøj, du bruger, ikke understøtter skrivning til den resultatfil, det genererer, er det en god ide at have mindst et excelark eller notesblok tilknyttet hver test for at indsætte kommentarer om udførelsesstatus, mens du går.
# 6) Postoperationer
hvordan man udpakker .7z-filer på mac
Når du er færdig med at teste, behøver det ikke udtrykkeligt at blive nævnt i din manuelle testtilfælde for at lukke browseren eller lukke AUT osv. Som tester ville du gøre det flittigt. I tilfælde af Automation-testsagen kan du medtage disse trin i dit script. Oprydning - er hvad jeg kalder disse aktiviteter. Dræb alle de forbindelser, du oprettede. Luk alle apps. Slip hukommelsen.
Ved hjælp af disse retningslinjer oversætter jeg vores Manual Test case til et QTP Test Script, der bruger VB Scripting. Følgende er resultatet: (klik på billedet for at forstørre det)
Gå gennem hvert trin
Trin 1: Forudsætning. Vi lancerer IE med Gmail.com URL programmatisk.
Trin 2 og 7: Synkroniseringserklæring. Som vi diskuterede ovenfor er disse vigtige for at sikre, at AUT kommer til den ønskede tilstand, før udførelsen af næste trin følger.
Trin 3 & 4: Indtastning af data. Alle data er hårdkodet i scriptet. Selvom det ikke anbefales, er det en start.
Trin 5: Ændring af AUT-trin. Trin 5 inkluderer at klikke på knappen Log ind. Du har ikke brug for en V&V, når denne erklæring bliver udført. Det er fordi der er en efterfølgende erklæring, og hvis den kan køre; det betyder den, før den har haft succes. Men hvis du er ekstra flittig, kan du medtage en her.
Trin 6 & 8: Kommentarer
Trin 9 og 11: Betinget erklæring. V & V / kontrolpunkt. Vi forsøger at se, om login har været vellykket ved at kontrollere, om der er et indbakke-link på den resulterende side. Hvis du bemærker omhyggeligt, skal du linke til den indre tekst, 'indbakke. *' Ledes efter. Så uanset hvor mange nye e-mails der er modtaget (som er variabel), hvis du har et indbakke-link (som altid er konstant), betyder det, at kontrolpunktet er bestået.
Trin 10: Beskedfelt. For synlighed
Trin 12 og 13: Disse er oprydningsaktiviteterne. Du logger ud fra kontoen og lukker browseren.
Konklusion
Så du kan se, hvor let et automatiseringsscript udfolder sig, når du har et velskrevet manuelt script og et sæt grundlæggende retningslinjer, du skal følge. Da dette ikke er en artikel, der vedrører rammer , Jeg forblev fri for funktioner, genbrugsfaktorer, parametrering osv. Test script er den grundlæggende byggesten, det er let at improvisere på et script, når du har det grundlæggende i orden.
Er der andre faktorer, du overvejer, en anden metode, du finder lettere, eller en retningslinje, som du har svært ved at følge? Fortæl mig venligst din feedback i kommentarerne.
Dette indlæg er skrevet af STH-teammedlem Swati Seela. Hun har mere end 9 års test- og manuel testserfaring med at arbejde med forskellige MNC'er. Hun er også vores instruktør for Software Testing QA træningskursus . Hvis du er interesseret i dette kursus for at tjekke kommende batchplan her .
PREV-vejledning | NÆSTE vejledning
Anbefalet læsning
- 10-trins automatiseringstestproces: Sådan starter du automatiseringstest i din organisation
- Hvorfor har vi brug for rammer til testautomatisering?
- Manuel og automatiseringstestudfordringer
- Hvordan adskiller testplanlægning sig for manuelle projekter og automatiseringsprojekter?
- Hvordan beslutter jeg, hvilken type test der kræves for et projekt? - Manuel eller automatisering
- Hvad er automatiseringstest (ultimativ guide til start af testautomatisering)
- QTP Frameworks - Test Automation Frameworks - Eksempler på søgeordsdrevne og lineære rammer - QTP Tutorial # 17
- Top 10 testautomatiseringsstrategier og bedste praksis