how translate manual test cases into automation scripts
Dette vil være den grunnleggende 'hvordan' -artikkelen og er ikke spesifikk for automatiseringsverktøyet. I utgangspunktet er det jeg prøver å gjøre her, å sette ord på tankeprosessen som går ut på å lage en automatiseringstest. Som alltid håper jeg dette vil være nyttig for dere alle.
Hvordan lage et automatiseringsprøvesak eller skript?
Automatisering følger alltid manuell testing. Vanligvis vil en eller flere runder med manuell testing allerede bli utført på AUT. Dette innebærer at manuelle testtilfeller allerede eksisterer og har blitt utført minst en gang.
For eksempel, anta at følgende er din Manuell prøvesak . Det er bare å logge på Gmail.com-nettstedet. Nå ser dette enkelt ut, ikke sant? Hvordan blir dette et automatiseringsskript? (klikk på bildet for å forstørre)
Hva du vil lære:
Hvordan oversette denne manuelle testsaken til et automatiseringsskript?
Følgende er retningslinjene vi skal følge for å oppnå oversettelsen til et automatiseringsskript:
# 1) Tilstand for AUT: Kolonnens forutsetning er bare en bestemt tilstand av bakgrunnen som skal settes for at et bestemt trinn skal utføres. Dette er spesielt viktig i to scenarier:
- For å starte testen: I dette tilfellet trenger vi nettleseren tilgjengelig og lansert. (Brukernavnet og passordtilgjengeligheten blir behandlet om en liten stund). Nå, hvordan skriver jeg det samme i automatiseringsverdenen? Vurder QTP. Du har muligheten til å enten starte nettleseren ved hjelp av programmatiske setninger, eller du kan bruke dialogboksen 'registrer og kjør innstilling' for å angi egenskapene. Det er veldig viktig å sette disse egenskapene riktig. Ofte er dette grunnen til at et bestemt stykke kode fungerer i en maskin og ikke fungerer i de andre.
- Å utføre et bestemt trinn : For at trinn 2 skal utføres, trenger vi trinn 1 som skal gjøres og fullføres. For å gjøre det manuelt, kan vi bare vente til trinnkjøringen er ferdig og siden lastes inn fullstendig. Bruk synkroniseringen eller vent på at utsagnene i automatiseringsskriptet ditt venter til ønsket tilstand blir oppfylt.
Merk: Når du kjører den samme koden for flere datasett, vil du forsikre deg om at du returnerer AUT til tilstanden som den burde være før neste iterasjonsstart.
# 2) Teststrinn
Vi kan kategorisere de manuelle testtrinnene i tre kategorier:
- Dataregistrering : Datainnføringstrinn er der du skriver inn litt informasjon som inndata til AUT.
- Endring av AUT-tilstandstrinn : disse trinnene er de som vil få en endring til å skje med AUT. Det kan omfatte å gå til en ny side, et bestemt felt er synlig, en redigeringsboks som kan redigeres, etc.
- Kombinasjon : som navnet antyder, er dette kombinasjonen av begge typene ovenfor. Ta saken i boksen, når den er slått på vil det gjøre et bestemt felt aktivt. I så fall skriver du inn verdien 'Sann' for avkrysningsfeltet, og det resulterer også i en tilstand av AUT.
I ovenstående testtilfelle eksisterer bare trinn 1 og 2.
- Type 1: testtrinn 2 og 3
- Type 2: Test trinn 1 og 4
Forutsetningen for å lage et automatiseringsskript ved hjelp av hvilket som helst verktøy er å bruke litt tid på å analysere verktøyet så vel som AUT. Prøv å se hvordan begge samhandler med hverandre. For eksempel, QTP har tre opptaksmåter, og hver fungerer på en annen måte.
Hvis du vet hvordan den identifiserer objekter, vil du vite hvilken du skal bruke og bruke dem bedre. Hvis du har en webapp der QTP enkelt kan identifisere objektene, kan du bruke normalmodus. Hvis ikke, må du kanskje bruke de analoge eller lavnivåmetodene.
Trinn for automatisering:
- Trinn for datainnføring er ikke veldig forskjellige i automatiserings- og manuelle metoder. Alt du gjør er å legge inn dataene. Måten du refererer til feltet er annerledes. Siden det vil være maskin som utfører trinnene, må vi bare sørge for at vi refererer til feltene i AUT på en måte som verktøyet forstår. Det betyr at du må bruke det logiske navnet som det brukes i koden.
- For endring av AUT / kombinasjonstrinn i et manuelt scenario utfører du handlingen (klikker eller sjekker eller skriver inn) og verifiserer endringen på en gang. Men i et automatiseringsscenario er det ikke mulig. Så vi må sørge for at vi legger til trinn for handling og validering / verifisering.
- Kommentarer for lesbarhet.
- Feilsøkingsuttalelser - disse er spesielt viktige der du lager og tester selve testen. Prøv å bruke meldingsbokser ofte for å sende ut forskjellige verdier på forskjellige stadier av testutførelsen. Dette vil gi deg innsyn i testen som ingenting annet ville gjort.
- Uttalelser - til skriv til resultater eller andre eksterne steder som et notisblokk eller excel-ark.
# 3) Bekreftelse og validering
Uten bekreftelse og validering går testintensjonen tapt. Vanligvis må du bruke et kontrollpunkt (betyr ikke nødvendigvis de innebygde). Så du må bruke mange betingede utsagn og også sløyfesetninger for å bygge logikken.
En viktig ting å vurdere er - attributtet som du baserer din V&V på, skal ikke være tvetydig. For eksempel, for vellykket pålogging, se etter innbokssidevisningen, ikke etter antall nye e-poster, fordi det ikke er en konstant verdi.
Så du må velge noe som er sant hver gang et sett med operasjoner skjer - uten feil.
beste systemvedlikeholdsprogramvare for Windows 10
# 4) Testdata
Følgende er noen av spørsmålene du kan vurdere å svare på for dine krav til testdata:
- Hvor skal du plassere den?
- Til hardcode eller ikke?
- Sikkerhetsproblemer?
- Bekymringer for gjenbrukbarhet?
Når du ser tilbake på det manuelle testskriptet, vil du legge merke til at det å ha testdata, brukernavn og passord er en av forutsetningene for å til og med starte testen.
# 5) Resultater
For en manuell testtilfelle kan du legge resultatet av hvert trinn i kolonnen 'Faktisk resultat'. Resultatfilen til et automatiseringsverktøy inneholder resultatet av hvert trinn når det kjøres.
Automatiseringsverktøy i disse dager har veldig robuste rapporteringsfunksjoner. Du kan imidlertid fremdeles trenge å skreddersy Testresultater . Så inkluder trinnene for å skrive ofte til resultatfilen, slik at du vet nøyaktig hva som skjedde mens kjøringen skjedde.
Hvis verktøyet du bruker ikke støtter skriving til resultatfilen det genererer, er det en god ide å ha minst et Excel-ark eller et notisblokk tilknyttet hver test for å legge inn kommentarer om utførelsesstatus mens du går.
# 6) Postoperasjoner
Når du er ferdig med å teste, behøver det ikke å være eksplisitt nevnt i din manuelle testtilfelle for å lukke nettleseren eller lukke AUT osv. Som tester vil du gjøre det flittig. Når det gjelder Automation-testtilfelle, kan du inkludere disse trinnene i skriptet ditt. Rydde opp - er det jeg kaller disse aktivitetene. Drep alle tilkoblingene du opprettet. Lukk alle appene. Slipp minnet.
Ved å bruke disse retningslinjene oversetter jeg vår manuelle testtilfelle til et QTP-testskript som bruker VB-skripting. Følgende er resultatet: (klikk på bildet for å forstørre)
Gå gjennom hvert trinn
Trinn 1: Forutsetning. Vi lanserer IE med Gmail.com URL programmatisk.
Trinn 2 og 7: Synkroniseringsuttalelse. Som vi diskuterte ovenfor, er disse viktige for å sikre at AUT kommer til ønsket tilstand før neste trinns utførelse følger.
Trinn 3 og 4: Dataregistrering. All data er hardkodet i skriptet. Selv om det ikke er tilrådelig, er det en start.
Trinn 5: Endring av AUT trinn. Trinn 5 inkluderer å klikke på Logg på-knappen. Du trenger ikke V&V når denne uttalelsen blir utført. Det er fordi det er en påfølgende uttalelse, og hvis den kan løpe; det betyr den før den har vært vellykket. Men hvis du er ekstra flittig, kan du ta med en her.
Trinn 6 og 8: Kommentarer
Trinn 9 og 11: Betinget uttalelse. V & V / Kontrollpunkt. Vi prøver å se om innloggingen er vellykket ved å sjekke om det er en innbokslenke på den resulterende siden. Hvis du merker deg nøye, kobler du til indre tekst, 'innboks. *' Er sett etter. Så uansett antall nye e-poster (som er variabel) mottatt, hvis du har en innboks-lenke (som alltid er en konstant) tilgjengelig, betyr det at kontrollpunktet passerte.
Trinn 10: Meldingsboks. For synlighet
Trinn 12 og 13: Dette er oppryddingsaktivitetene. Du logger av fra kontoen og lukker nettleseren.
Konklusjon
Så du ser hvor lett et automatiseringsskript utfolder seg når du har et velskrevet manuelt skript og et sett med grunnleggende retningslinjer å følge. Siden dette ikke er en artikkel som gjelder rammer , Jeg holdt meg klar fra funksjoner, gjenbrukbarhetsfaktorer, parameterisering osv. Testskript er den grunnleggende byggesteinen, det er lett å improvisere på et skript når du har det grunnleggende riktig.
Er det noen andre faktorer du vurderer, en annen metode du finner enklere eller noen retningslinjer du synes er vanskelig å følge? Gi meg beskjed om tilbakemeldingene dine i kommentarene.
Dette innlegget er skrevet av STH-teammedlem Swati Seela. Hun har mer enn 9 års erfaring med manuell og automatisering av å jobbe med forskjellige MNC-er. Hun er også instruktøren vår for Software Testing QA Training kurs . Hvis du er interessert i dette kurset for å sjekke kommende batchplan her .
PREV Opplæring | NESTE veiledning
Anbefalt lesing
- 10-trinns automatiseringstestprosess: Slik starter du automatiseringstesting i organisasjonen din
- Hvorfor trenger vi rammeverk for testautomatisering?
- Manuelle og automatiseringstestutfordringer
- Hvordan er testplanlegging forskjellig for manuelle og automatiseringsprosjekter?
- Hvordan bestemme hvilken type testing som kreves for et prosjekt? - Manuell eller automatisering
- Hva er automatiseringstesting (Ultimate Guide to Start Test Automation)
- QTP Frameworks - Test Automation Frameworks - Keyword Driven and Lineær Framework Eksempler - QTP Tutorial # 17
- Topp 10 testautomatiseringsstrategier og beste praksis