how write test cases
I denne grundige, praktiske veiledningen om hvordan jeg skriver testtilfeller, har jeg dekket detaljene om hva som er en testkasse, dens standarddefinisjon og testkassedesignteknikker.
Hva er en testsak?
En testsak har komponenter som beskriver innspill, handling og forventet respons, for å avgjøre om en funksjon i en applikasjon fungerer som den skal.
En testtilfelle er et sett med instruksjoner om “HVORDAN” for å validere et bestemt testmål / mål, som når det følges vil fortelle oss om den forventede oppførselen til systemet er tilfredsstilt eller ikke.
Liste over opplæringer dekket i denne testcase-skriveserien:
Hvordan skrive:
Opplæring # 1: Hva er en prøvesak og hvordan du skriver testsaker (denne opplæringen)
Opplæring nr. 2: Eksempel på testsaksmal med eksempler (Last ned) (må lese)
Opplæring # 3: Skrive testtilfeller fra SRS-dokument
Opplæring # 4: Hvordan skrive testsaker for et gitt scenario
Opplæring # 5: Hvordan forberede deg på prøveskriving
Opplæring # 6: Hvordan skrive negative testtilfeller
Eksempler:
Opplæring # 7: 180+ prøvesaker for nett- og skrivebordsprogrammer
Opplæring # 8: 100+ ferdige testscenarier (sjekkliste)
Skriveteknikker:
Opplæring 9: Årsaks- og virkningsgraf - Dynamisk teknikk for skrivesaker
Opplæring # 10: State Transition Testing Technique
Opplæring # 11: Orthogonal Array Testing Technique
Opplæring # 12: Feil ved gjetningsteknikk
Opplæring # 13: Field Validation Table (FVT) Test Design Technique
Test Case Vs Test Scenarier:
Opplæring # 14: Test tilfeller mot testscenarier
Opplæring # 15: Forskjellen mellom testplan, teststrategi og testtilfelle
Automasjon:
Opplæring nr. 16: Hvordan velge riktige testtilfeller for automatiseringstesting
Opplæring nr. 17: Hvordan oversette manuelle testtilfeller til automatiseringsskript
Testhåndteringsverktøy:
Opplæring # 18: Beste testhåndteringsverktøy
Opplæring # 19: TestLink for håndtering av testsaker
Opplæring nr. 20: Opprette og administrere testsaker ved hjelp av HP Quality Center
Opplæring # 21: Gjennomføring av testtilfeller ved bruk av ALM / QC
Domenespesifikke tilfeller:
Opplæring # 22: Test tilfeller for ERP-applikasjon
Opplæring # 23: JAVA-applikasjonstesttilfeller
Opplæring # 24: Grenseverdianalyse og ekvivalenspartisjonering
La oss fortsette med den første veiledningen i denne serien.
Anbefalte verktøy:
Før du fortsetter til prosessskrivingsprosessen, anbefaler vi at du laster ned dette testsaksbehandlingsverktøyet. Dette vil lette skriveprosessen for testsaker som er nevnt i denne opplæringen:
# 1) TestRail
=> Last ned TestRail Test Case Management Tool
# 2) TestMonitor
Toppnivå online testledelse. Revolusjonerende enkelt.
TestMonitor er et end-to-end testadministrasjonsverktøy for alle organisasjoner. En enkel, intuitiv tilnærming til testing. Enten du implementerer bedriftsprogramvare, trenger kvalitetssikring, bygger en kvalitetsapp eller bare trenger en hjelpende hånd i testprosjektet ditt, har TestMonitor deg dekket.
=> Besøk TestMonitor-nettstedet
Hva du vil lære:
- Hva er en testsak og hvordan skriver jeg testtilfeller?
- Tips for skrivetester
- Hvordan oppnå fremragende kvalitet i testdokumentasjon
- Nyttige tips og triks
- # 1) Er testdokumentet ditt i god form?
- # 2) Ikke glem å dekke de negative sakene
- # 3) Har trinn med atomprøver
- # 4) Prioriter testene
- # 5) Sekvens Matters
- # 6) Legg til tidsstempel og testernavn i kommentarene
- # 7) Inkluder nettleserdetaljer
- # 8) Oppbevar to separate ark - 'Bugs' og 'Summary' i dokumentet
- Nyttige tips og triks
- Hvordan IKKE å skrive tester
- Hvordan forbedre testkassens effektivitet
- Viktigheten av å standardisere testtilfellene
Hva er en testsak og hvordan skriver jeg testtilfeller?
Å skrive effektive saker er en ferdighet. Og du kan lære det av erfaring og kunnskap om applikasjonen som testes.
For grunnleggende instruksjoner om hvordan du skriver tester, vennligst sjekk følgende video:
Ovennevnte ressurser skal gi oss grunnleggende om testskrivingsprosessen.
Nivåer av testskriveprosessen:
- Nivå 1: På dette nivået vil du skrive grunnleggende saker fra den tilgjengelige spesifikasjonen og brukerdokumentasjon.
- Nivå 2: Dette er praktisk stadium hvor skrivesaker avhenger av den faktiske funksjonen og systemflyten til applikasjonen.
- Nivå 3: Dette er stadiet der du vil gruppere noen saker og skriv en testprosedyre . Testprosedyren er bare en gruppe små saker, kanskje maksimalt 10.
- Nivå 4: Automatisering av prosjektet. Dette vil minimere menneskelig interaksjon med systemet, og dermed kan kvalitetssikringen fokusere på de nåværende oppdaterte funksjonene for å teste i stedet for å være opptatt med regresjonstesting.
Hvorfor skriver vi tester?
Det grunnleggende målet med å skrive saker er for å validere testdekningen til en søknad.
Hvis du jobber i en hvilken som helst CMMi-organisasjon, følges teststandardene nærmere. Å skrive saker gir en slags standardisering og minimerer ad-hoc-tilnærmingen i testingen.
Hvordan skriver jeg testtilfeller?
Enger:
- Prøvesak-ID
- Enhet å teste: Hva skal verifiseres?
- Antagelser
- Testdata: Variabler og deres verdier
- Fremgangsmåte som skal utføres
- forventet resultat
- Egentlige resultatet
- Bestått / ikke bestått
- Kommentarer
Grunnleggende format for uttalelse om prøvesaker
Bekrefte
Ved hjelp av (verktøynavn, taggenavn, dialog osv.)
Med (betingelser)
Til (det som returneres, vises, demonstreres)
Bekrefte: Brukes som det første ordet i testuttalelsen.
Ved hjelp av: Å identifisere hva som testes. Du kan bruke 'å angi' eller 'velge' her i stedet for å bruke, avhengig av situasjonen.
For alle applikasjoner må du dekke alle typer tester som:
- Funksjonelle saker
- Negative tilfeller
- Grenseverdi tilfeller
Mens du skriver disse alle dine TC-er skal være enkle og lette å forstå .
***********************************************
Tips for skrivetester
En av de hyppigste og viktigste aktivitetene til en Software Tester (SQA / SQC person) er å skrive testscenarier og saker.
Det er noen viktige og kritiske faktorer som er relatert til denne store aktiviteten. La oss få et fugleperspektiv på disse faktorene først.
Viktige faktorer som er involvert i skriveprosessen:
a) TC er utsatt for regelmessig revisjon og oppdatering:
Vi lever i en stadig skiftende verden, og det samme gjelder også for programvare. Programvarekrav endrer direkte på sakene. Når kravene endres, må TC-ene oppdateres.
Likevel er det ikke bare endringen i kravet som kan forårsake revisjon og oppdatering av TC-er. Under utførelsen av TC-er oppstår mange ideer i tankene, og mange underforhold for en enkelt TC kan identifiseres. Alt dette fører til en oppdatering av TC-er, og noen ganger fører det til og med til tillegg av nye TC-er.
Videre, under regresjonstesting, krever flere reparasjoner og / eller krusninger reviderte eller nye TC-er.
b) TC-er er utsatt for distribusjon blant testere som skal utføre disse:
Selvfølgelig er det knapt en slik situasjon der en enkelt tester utfører alle TC-ene. Normalt er det flere testere som tester forskjellige moduler i en enkelt applikasjon. Så TCene er delt mellom testerne i henhold til deres eide områder av applikasjonen som testes.
Noen TC-er som er relatert til integrasjonen av applikasjonen kan kjøres av flere testere, mens de andre TC-ene bare kan kjøres av en enkelt tester.
c) TC-er er utsatt for klynging og batching:
Det er normalt og vanlig at TC-er som tilhører et enkelt testscenario, vanligvis krever kjøring i en bestemt rekkefølge eller i form av en gruppe. Det kan være visse forutsetninger for en TC som krever kjøring av andre TCer før de kjører selv.
På samme måte, i henhold til forretningslogikken til AUT, kan en enkelt TC bidra til flere testbetingelser, og en enkelt testtilstand kan bestå av flere TC.
d) TC har en tendens til inter-avhengighet:
Dette er også en interessant og viktig oppførsel fra TC-ene som angir at de kan være avhengige av hverandre. Fra middels til store applikasjoner med kompleks forretningslogikk, er denne tendensen mer synlig.
Det klareste området i ethvert program der denne oppførselen definitivt kan observeres, er interoperabiliteten mellom forskjellige moduler med samme eller til og med forskjellige applikasjoner. Enkelt sagt, uansett hvor de forskjellige modulene en enkelt applikasjon eller flere applikasjoner er avhengige av hverandre, gjenspeiles den samme oppførselen også i TC-ene.
e) TC-er er utsatt for distribusjon blant utviklerne (spesielt i testdrevet utviklingsmiljø):
Et viktig faktum om TC-er er at disse ikke bare skal brukes av testerne. I normal tilfelle, når en feil er under reparasjon av utviklerne, bruker de indirekte TC for å fikse problemet. På samme måte, hvis den testdrevne utviklingen følges, så brukes TC-er direkte av utviklerne for å bygge logikken og dekke alle scenariene i koden som adresseres av TC-er.
Tips for å skrive effektive tester:
Med tanke på de ovennevnte 5 faktorene, her er noen tips for å skrive effektive TC-er.
La oss begynne!!!
# 1) Hold det enkelt, men ikke for enkelt; gjør det komplisert, men ikke for komplisert:
Denne uttalelsen virker et paradoks. Men jeg lover at det ikke er slik. Hold alle trinnene i TC-ene atomare og presise. Nevn trinnene med riktig sekvens og riktig kartlegging til forventede resultater. Testsaken skal være selvforklarende og lett å forstå. Dette er hva jeg mener for å gjøre det enkelt.
Nå gjør det til et komplekst middel å gjøre det integrert med testplanen og andre TC-er. Henvis til de andre TC-ene, relevante artefakter, GUI-er osv. Der og når det er nødvendig. Men gjør dette på en balansert måte. Ikke lag en tester for å flytte frem og tilbake i bunken med dokumenter for å fullføre et enkelt testscenario.
På den annen side, ikke la testeren dokumentere disse TC-ene på en veldig kompakt måte. Mens du skriver TC-er, må du alltid huske at du eller noen andre må revidere og oppdatere disse.
# 2) Etter å ha dokumentert testsakene, gjennomgå en gang som Tester:
Tror aldri at jobben er gjort når du har skrevet den siste TC i testscenariet. Gå til start og gjennomgå alle TC-ene en gang, men ikke med tankegangen til en TC-skribent eller Testing Planner. Gjennomgå alle TC-er med tankene til en tester. Tenk rasjonelt og prøv å tørke kjøre TC-ene dine.
Evaluer at alle trinnene og se om du har nevnt disse tydelig på en forståelig måte, og at de forventede resultatene er i harmoni med disse trinnene.
Sørg for at testdata spesifisert i TC-er er mulig ikke bare for faktiske testere, men er også i samsvar med sanntidsmiljøet. Forsikre deg om at det ikke er noen avhengighetskonflikt mellom TC-er, og kontroller at alle referanser til andre TC-er / artefakter / GUIer er nøyaktige. Ellers kan testerne være i store problemer.
# 3) Bundet så vel som lettere testere:
Ikke la testdataene ligge på testere. Gi dem en rekke innganger, spesielt der beregninger skal utføres eller applikasjonens oppførsel er avhengig av innganger. Du kan la dem bestemme verdiene for testdataelementene, men aldri gi dem frihet til å velge testdataelementene selv.
Fordi de med vilje eller utilsiktet kan bruke de samme testdataene igjen og igjen, og noen viktige testdata kan bli ignorert under utførelsen av TC-er.
Hold testerne rolige ved å organisere TC-ene i henhold til testkategoriene og de relaterte områdene i en applikasjon. Instruer og nevn tydelig hvilke TC-er som er innbyrdes avhengige og / eller grupperte. Angi også eksplisitt hvilke TC-er som er uavhengige og isolerte slik at testeren kan styre sin samlede aktivitet i samsvar med dette.
På dette punktet kan det hende du er interessert i å lese om analyse av grenseverdier, som er en test case design strategi som brukes i black box testing. Klikk her å vite mer om det.
# 4) Vær en bidragsyter:
Godta aldri FS eller designdokumentet slik det er. Din jobb er ikke bare å gå gjennom FS og identifisere testscenariene. Å være en QA-ressurs, ikke nøl med å bidra til virksomheten og gi forslag hvis du føler at noe kan forbedres i applikasjonen.
Foreslå også utviklere, spesielt i TC-drevet utviklingsmiljø. Foreslå rullegardinlistene, kalenderkontrollene, utvalgslisten, gruppeknappene, mer meningsfylte meldinger, advarsler, instruksjoner, forbedringer knyttet til brukervennlighet, etc.
Å være en kvalitetssikring, ikke bare test, men gjør en forskjell!
hvordan sjekke pakketap i nettverket
# 5) Glem aldri sluttbrukeren:
Den viktigste interessenten er 'Sluttbruker' som til slutt vil bruke applikasjonen. Så, glem ham aldri på noe stadium av skriving av TC. Faktisk bør ikke sluttbrukeren ignoreres på noe tidspunkt i hele SDLC. Likevel er min vekt så langt bare relatert til emnet mitt.
Så, under identifiseringen av testscenarier, må du aldri overse de sakene som mest vil bli brukt av brukeren eller sakene som er forretningskritiske, selv om de blir mindre hyppig brukt. Hold deg i slutten av brukerne, og gå gjennom alle TC-ene og vurder den praktiske verdien av å utføre alle de dokumenterte TC-ene dine.
***********************************************
Hvordan oppnå fremragende kvalitet i testdokumentasjon
Å være en programvaretester, vil du sikkert være enig med meg i at det å komme opp med et perfekt testdokument er virkelig en utfordrende oppgave.
Vi gir alltid litt muligheter for forbedring i vårt Test saksdokumentasjon . Noen ganger klarer vi ikke å gi 100% testdekning gjennom TC-ene, og til tider er testmalen ikke på nivå, eller vi mangler god lesbarhet og klarhet i testene våre.
Når du blir testet, må du ikke bare starte på en ad hoc måte når du blir bedt om å skrive testdokumentasjon. Det er veldig viktig å forstå formålet med å skrive testsaker i god tid før du jobber med dokumentasjonsprosessen.
Testene skal alltid være klare og klare. De skal skrives på en måte som gjør det lettere for testeren å utføre fullstendig testing ved å følge trinnene som er definert i hver av testene.
I tillegg bør testdokumentet inneholde så mange saker som kreves for å gi fullstendig testdekning . For eksempel , bør du prøve å dekke testene for alle mulige scenarier som kan oppstå i programvaren.
Med tanke på de ovennevnte punktene, la meg nå ta deg gjennom en omvisning om hvordan du oppnår fremragende kvalitet i testdokumentasjon.
Nyttige tips og triks
Her skal jeg gi deg noen nyttige retningslinjer som kan gi deg et poeng i testdokumentasjonen fra de andre.
# 1) Er testdokumentet ditt i god form?
Den beste og enkle måten å organisere testdokumentet ditt er å dele det opp i mange nyttige seksjoner. Del hele testingen i flere testscenarier. Del deretter hvert scenario i flere tester. Til slutt, del hvert tilfelle i flere testtrinn.
Hvis du bruker excel, skal du dokumentere hver testtilfelle på et eget ark i arbeidsboken der hvert testtilfelle beskriver en komplett testflyt.
# 2) Ikke glem å dekke de negative sakene
Som programvaretester må du tenke utenfor boksen og tegne opp alle mulighetene som applikasjonen din kommer over. Vi, som testere, må bekrefte at hvis et uautentisk forsøk på å gå inn i programvaren eller ugyldige data som skal strømme over applikasjonen, skal stoppes og rapporteres.
Dermed er en negativ sak like viktig som en positiv sak. Forsikre deg om at for hvert scenario du har to testtilfeller - en positiv og en negativ . Den positive skal dekke den tiltenkte eller normale strømmen, og den negative skal dekke den utilsiktede eller eksepsjonelle strømmen.
# 3) Har trinn med atomprøver
Hvert teststrinn skal være atomisk. Det bør ikke være noen ytterligere trinn. Jo enklere og tydeligere et teststrinn er, jo lettere vil det være å fortsette med testingen.
# 4) Prioriter testene
Vi har ofte strenge tidslinjer for å fullføre testingen av en applikasjon. I dette tilfellet kan vi gå glipp av å teste noen av de viktige funksjonene og aspektene ved programvaren. For å unngå dette, bør du merke en prioritet med hver test mens du dokumenterer den.
Du kan bruke hvilken som helst koding for å definere prioriteten til en test. Det er generelt bedre å bruke et av de tre nivåene, høy, middels og lav , eller 1, 50 og 100. Når du har en streng tidslinje, bør du fullføre alle testene med høy prioritet først og deretter gå til medium og lav prioritet.
For eksempel - for et shoppingnettsted kan det være en sak med høy prioritet å verifisere tilgangsnektelse for et ugyldig forsøk på å logge på appen. Verifisering av visning av relevante produkter på brukerskjermen kan være mellomprioriterte tilfeller og verifisering av fargen på teksten som vises på skjermknappene kan være en lavprioritetstest.
# 5) Sekvens Matters
Bekreft om trinnrekkefølgen i testen er helt korrekt. En feil sekvens av trinn kan føre til forvirring. Trinnene bør fortrinnsvis også definere hele sekvensen fra å komme inn i appen til den går ut av appen for et bestemt scenario som testes.
# 6) Legg til tidsstempel og testernavn i kommentarene
Det kan være et tilfelle der du tester en applikasjon, noen gjør endringer parallelt med den samme appen, eller noen kan oppdatere appen etter at testen er ferdig. Dette fører til en situasjon der testresultatene kan variere med tiden.
Så det er alltid bedre å legge til en tidsstempel med testerenes navn i testkommentarene, slik at et testresultat (bestått eller ikke bestått) kan tilskrives tilstanden til en applikasjon på det aktuelle tidspunktet. Alternativt kan du ha en Utført dato ’Kolonne lagt til separat i testsaken, som eksplisitt vil identifisere teststempelet.
# 7) Inkluder nettleserdetaljer
Som du vet, hvis det er et webapplikasjon, kan testresultatene variere basert på nettleseren som testen utføres på. For å gjøre det lettere for andre testere, utviklere eller den som vurderer testdokumentet, bør du legge til nettleserens navn og versjon i saken, slik at feilen enkelt kan replikeres.
# 8) Oppbevar to separate ark - 'Bugs' og 'Summary' i dokumentet
Hvis du dokumenterer i et excel, skal de to første arkene i arbeidsboken være Sammendrag og Feil. Oppsummeringsarket skal oppsummere testscenariet, og feilarket skal liste opp alle problemene som oppstod under testing. Betydningen av å legge til disse to arkene er at det vil gi en klar forståelse av testingen til leseren / brukeren av dokumentet.
Så når tiden er begrenset, kan disse to arkene vise seg å være veldig nyttige for å gi en oversikt over testingen.
Testdokumentet skal gi best mulig testdekning, utmerket lesbarhet og skal følge ett standardformat gjennomgående.
Vi kan oppnå fremragende testdokumentasjon ved å bare ha noen viktige tips i tankene når vi organiserer testdokumenter, prioritere TC-ene, ha alt i riktig rekkefølge, inkludert alle obligatoriske detaljer for å utføre en TC, og gi klare og klare testtrinn, etc. som diskutert ovenfor.
***********************************************
Hvordan IKKE å skrive tester
Vi bruker mesteparten av tiden vår på å skrive, gjennomgå, gjennomføre eller vedlikeholde disse. Det er ganske uheldig at tester også er de mest feilutsatte. Forskjellene i forståelse, organisasjonsprøving, mangel på tid osv. Er noen av grunnene til at vi ofte ser tester som lar mye være å ønske.
Det er mange artikler på nettstedet vårt om dette emnet, men her vil du se Hvordan IKKE å skrive testsaker - noen tips som vil være medvirkende til å skape særegne, kvalitet og effektive tester.
La oss lese videre, og vær oppmerksom på at disse tipsene er for både nye og erfarne testere.
3 De vanligste problemene i testsaker
- Sammensatte trinn
- Søknadsadferd tas som forventet atferd
- Flere forhold i ett tilfelle
Disse tre må være på topp 3-listen over vanlige problemer i testskriveprosessen.
Det som er interessant er at disse skjer med både nye og erfarne testere, og vi fortsetter å følge de samme feilprosessene uten å innse at noen få enkle tiltak lett kan løse ting.
La oss komme til det og diskutere hver enkelt i detalj:
# 1) Sammensatte trinn
Først av alt, hva er et sammensatt trinn?
For eksempel gir du anvisninger fra punkt A til punkt B: hvis du sier at 'Gå til XYZ-sted og deretter til ABC', vil dette ikke gi mye mening, for her finner vi oss selv å tenke - 'Hvordan kan jeg komme til XYZ i utgangspunktet ”- i stedet for å begynne med“ Ta til venstre herfra og gå 1 mil, og ta deretter til høyre på Rd. nr. 11 for å komme til XYZ ”kan oppnå bedre resultater.
Nøyaktig de samme reglene gjelder også for tester og trinnene.
For eksempel Jeg skriver en test for Amazon.com - bestill et produkt.
Følgende er testtrinnene mine (Merk: Jeg skriver bare trinnene og ikke alle de andre delene av testen som forventet resultat osv.)
til . Start Amazon.com
b . Søk etter et produkt ved å skrive inn produktnøkkelordet / navnet i 'Søk' -feltet øverst på skjermen.
c . Velg den første fra søkeresultatene som vises.
d . Klikk på Legg i handlekurven på siden med produktdetaljer.
er . Kasse og betaling.
f . Sjekk siden for ordrebekreftelse.
Nå, kan du identifisere hvilke av disse som er et sammensatt trinn? Høyre trinn (e)
Husk at tester alltid handler om 'Hvordan' å teste, så det er viktig å skrive de nøyaktige trinnene i 'Hvordan sjekke ut og betale' i testen.
Derfor er saken ovenfor mer effektiv når den skrives som nedenfor:
til . Start Amazon.com
b . Søk etter et produkt ved å skrive inn produktnøkkelordet / navnet i 'Søk' -feltet øverst på skjermen.
c . Velg den første fra søkeresultatene som vises.
d . Klikk på Legg i handlekurven på siden med produktdetaljer.
er . Klikk på Checkout i handlekurven.
f . Angi informasjon om CC, forsendelse og fakturering.
g . Klikk på Kassen.
h . Sjekk siden for ordrebekreftelse.
Derfor er et sammensatt trinn det som kan deles inn i flere individuelle trinn. La oss alle ta hensyn til denne delen neste gang vi skriver tester, og jeg er sikker på at du er enig med meg i at vi gjør dette oftere enn vi vet.
# 2) Søknadsadferd tas som forventet atferd
Flere og flere prosjekter må takle denne situasjonen i disse dager.
Mangel på dokumentasjon, ekstrem programmering, raske utviklingssykluser er få grunner som tvinger oss til å stole på at applikasjonen (en eldre versjon eller så) enten skriver testene eller baserer selve testingen på. Som alltid er dette en bevist dårlig praksis - ikke alltid egentlig.
Det er ufarlig så lenge du holder et åpent sinn og holder forventningen om at - “AUT kan være feil”. Det er bare når du ikke tror at det er, ting fungerer dårlig. Som alltid vil vi la eksemplene snakke.
Hvis følgende er siden du skriver / designer teststrinnene for:
Sak 1:
Hvis trinnene mine er som følger:
- Start shoppingområdet.
- Klikk på Frakt og retur- Forventet resultat: Frakt- og retursiden vises med “Legg informasjonen din her” og “Fortsett” -knappen.
Da er dette feil.
Sak 2:
- Start shoppingområdet.
- Klikk på Frakt og returner.
- Skriv inn bestillingsnummeret i tekstfeltet ‘Angi bestillingsnr.’ I dette skjermbildet.
- Klikk Fortsett - Forventet resultat: Detaljer om bestillingen relatert til frakt og retur vises.
Tilfelle 2 er en bedre testtilfelle fordi selv om referansesøknaden oppfører seg feil, tar vi den bare som en retningslinje, undersøker videre og skriver forventet oppførsel i henhold til forventet riktig funksjonalitet.
Bunnlinjen: Søknad som referanse er en rask snarvei, men den kommer med sine egne farer. Så lenge vi er forsiktige og kritiske, gir det fantastiske resultater.
# 3) Flere forhold i ett tilfelle
Nok en gang, la oss lære av Eksempel .
Ta en titt på testtrinnene nedenfor: Følgende er teststrinnene i en test for en påloggingsfunksjon.
en. Skriv inn gyldige detaljer og klikk Send.
b. La brukernavnfeltet være tomt. Klikk på Send.
c. La passordfeltet være tomt og klikk på Send.
d. Velg et allerede innlogget brukernavn / passord og klikk Send.
Det som måtte være 4 forskjellige saker kombineres til en. Du tenker kanskje - Hva er galt med det? Det sparer mye dokumentasjon, og hva jeg kan gjøre i 4, gjør jeg det i 1 - er ikke det bra? Vel, ikke helt. Grunner?
Les videre:
- Hva om en av betingelsene mislykkes - vi må merke hele testen som 'mislykket'. Hvis vi merker at hele saken er “mislykket”, betyr det at alle de fire forholdene ikke fungerer, noe som ikke er sant.
- Testene må ha en flyt. Fra forutsetning til trinn 1 og gjennom trinnene. Hvis jeg følger denne saken, i trinn (a), hvis den lykkes, blir jeg logget inn på siden der alternativet “login” ikke lenger er tilgjengelig. Så når jeg kommer til trinn (b) - hvor skal testeren angi brukernavnet? Ser du, strømmen er ødelagt.
Derfor, skrive modulære tester . Det høres ut som mye arbeid, men alt som trengs for deg er å skille ting og bruke våre beste venner Ctrl + C og Ctrl + V for å jobbe for oss. :)
***********************************************
Hvordan forbedre testkassens effektivitet
Programvaretesterne bør skrive testene sine fra det tidligere stadiet av programvarens utviklingslivssyklus, best i programvarekravsfasen.
Testansvarlig eller en kvalitetssikringsleder skal samle inn og utarbeide maksimalt mulige dokumenter i henhold til listen nedenfor.
Dokumentsamling for testskriving
# 1) Dokument for brukerkrav
Det er et dokument som lister opp forretningsprosessen, brukerprofiler, brukermiljø, interaksjon med andre systemer, erstatning av eksisterende systemer, funksjonelle krav, ikke-funksjonelle krav, lisensiering og installasjonskrav, ytelseskrav, sikkerhetskrav, brukervennlighet og samtidige krav osv. .,
# 2) Dokument for forretningsbruk
Dette dokumentet beskriver brukstilfelle scenario med funksjonskravene fra forretningsperspektivet. Dette dokumentet dekker forretningsaktørene (eller systemet), mål, forutsetninger, etterbetingelser, grunnleggende flyt, alternativ flyt, opsjoner, unntak for hver forretningsstrøm i systemet under krav.
# 3) Dokument om funksjonelle krav
Dette dokumentet beskriver funksjonskravene til hver funksjon for systemet under kravene.
Normalt fungerer funksjonelle kravsdokument som et felles lager for både utviklings- og testteamet samt for prosjektets interessenter, inkludert kundene for de forpliktende (noen ganger frosne) kravene, som bør behandles som det viktigste dokumentet for all programvareutvikling.
# 4) Prosjektplan for programvare (valgfritt)
Et dokument som beskriver detaljene i prosjektet, mål, prioriteringer, milepæler, aktiviteter, organisasjonsstruktur, strategi, fremdriftsovervåking, risikoanalyse, forutsetninger, avhengigheter, begrensninger, opplæringskrav, klientansvar, prosjektplan etc.,
# 5) QA / testplan
Dette dokumentet beskriver kvalitetsstyringssystem, dokumentasjonsstandarder, endringskontrollmekanisme, kritiske moduler og funksjoner, konfigurasjonsstyringssystem, testplaner, mangelfølgning, akseptkriterier etc.
De testplan dokumentet brukes til å identifisere funksjonene som skal testes, funksjoner som ikke skal testes, testing av teamallokeringer og deres grensesnitt, ressurskrav, testplan, testskriving, testdekning, testleveranser, forutsetning for testutførelse, feilrapportering og sporing mekanisme, testmålinger etc.,
Virkelig eksempel
La oss se hvordan vi effektivt kan skrive testsaker for et kjent og enkelt 'Login' -skjermbilde i henhold til figuren nedenfor. De tilnærming av testing vil være nesten det samme selv for komplekse skjermer med mer informasjon og kritiske funksjoner.
#1) Den første tilnærmingen for en testprosess vil være å få en skjermprototype (eller wire-frames) som ovenfor, hvis tilgjengelig. Dette er kanskje ikke tilgjengelig for noen av funksjonene og avhenger av kritikken ved å designe en prototype i de tidligere utviklingsstadiene.
Men hvis en SRS (Spesifikasjon av programvarekrav) er tilgjengelig for prosjektet, er de fleste skjermprototypene utviklet av prosjektgruppen. Denne typen skjerm forenkler testers jobb og øker effektiviteten til testene.
#to) Neste, den spesifikasjoner for funksjonelle krav . Det avhenger av organisasjonsprosessen, den vil være tilgjengelig i en serie med flere dokumenter.
Så bestem det beste dokumentet for å skrive saker, enten det kan være et brukerkravsdokument eller funksjonelle kravspesifikasjoner (eller til og med et SRS-dokument hvis det kan forstås komfortabelt av testteamet) som vil gi en fullstendig funksjonell flyt av det valgte funksjonen som skal testes.
# 3) Når skjermprototypen og funksjonelle spesifikasjoner er på plass, bør testeren begynne å skrive sakene med følgende tilnærming og kriterier.
- UI-tester :Kontrollene / feltene som er synlige for brukeren. Det er statisk kontroll og dynamiske kontroller tilgjengelig for funksjonen som skal testes. For eksempel, i påloggingsskjermen ovenfor er 'User Name & Password' tekstene statiske felt som ikke krever brukerinteraksjon, bare for å vise teksten.
- Funksjonelle saker :På den annen side er påloggingsknappen og hyperkoblingene (glemt passord? Og registrering) dynamiske felt som krever brukerinteraksjon ved å klikke på kontrollene, som vil gjøre noe etterpå.
- Databasesaker :Når brukeren har angitt brukernavnet og passordet, kan testene skrives for å sjekke den relaterte databasen for, om brukernavnet og passordet er sjekket i riktig database og tabell, og brukeren har også tillatelse til å logge inn på applikasjonen som testes.
- Behandle tester :Dette er relatert til prosessen (ikke handlingene knyttet til de synlige kontrollene som er tilgjengelige på skjermen) knyttet til funksjonen og funksjonaliteten. For eksempel, ved å klikke Glemt passord-koblingen i eksemplet ovenfor, kan det hende at du sender en e-post til brukeren. Så, kanskje en e-post må testes for riktig prosess og bekreftelse.
4) Til slutt, hold “ BAOE mantra ', midler i) Grunnleggende flyt ii) Alternativ strømning iii) Alternativer og iv) Unntak for fullstendig dekning av funksjonell flyt og funksjon som skal testes. Hvert konsept skal brukes på positive og negative tester.
For eksempel, la oss se den enkle BAOE-tilnærmingen for påloggingsskjermbildet ovenfor.
- Grunnleggende flyt: Skriv inn URL-stien til påloggingen i en hvilken som helst nettleser, og skriv inn nødvendig informasjon og logg inn på applikasjonen.
- Alternativ flyt: Installer applikasjonen på en mobil enhet, og skriv inn nødvendig informasjon og logg inn på applikasjonen.
- Alternativer: Hvilke alternativer er tilgjengelige for å komme til samme påloggingsskjerm? For eksempel, etter pålogging til applikasjonen, kan det å klikke på ‘Logout’ føre til det samme skjermbildet, eller hvis øktens timeout eller økten utløp, kan brukeren komme til påloggingsskjermen.
- Unntak: Hva er unntak hvis testene mine er negative? For eksempel, hvis feil legitimasjon er angitt i påloggingsskjermen, om brukeren får en feilmelding eller ingen handling tilknyttet.
Med all denne informasjonen i hånden, la oss begynne å skrive TC-ene for påloggingsskjermen, i et format med full dekning og sporbarhet og med detaljert informasjon. Den logiske sekvensen og nummereringen av å identifisere Test Case ID ’ vil være veldig nyttig for en rask identifiseringshistorikk for testsaker.
Les også=> 180+ prøve klar til bruk testtilfeller for nett- og skrivebordsprogrammer.
Test saksdokument
Merk : Testkolonnene er ikke begrenset til eksemplet under testdokumentet nedenfor, som kan opprettholdes i et Excel-ark for å ha så mange kolonner som kreves for en komplett sporbarhetsmatrisevis, prioritet, testens formål, testtype, feilskjermbildeplassering etc.,
Les også=> Eksempel på test case mal med eksempler.
For å gjøre det enkle og enkle å lese av dette dokumentet, la oss skrive trinnene for å reprodusere, forventet og faktisk oppførsel av testene for påloggingsskjermen i detalj nedenfor.
Merk : Legg til faktisk atferdskolonne på slutten av denne malen.
Nei. | Steg for å reprodusere | Forventet atferd |
---|---|---|
7. | Klikk på registreringskoblingen | Ved å klikke på lenken, skal brukeren komme til det relaterte skjermbildet. |
1. | Åpne en nettleser og skriv inn URL-en for påloggingsskjermen. | Påloggingsskjermen skal vises. |
2. | Installer appen på Android-telefonen og åpne den. | Påloggingsskjermen skal vises. |
3. | Åpne påloggingsskjermen og sjekk at de tilgjengelige tekstene er riktig stavet. | 'Brukernavn' og 'Passord' -tekst skal vises før den relaterte tekstboksen. Påloggingsknappen skal ha bildeteksten ‘Login’. ‘Glemt passord?’ Og ‘Registrering’ skal være tilgjengelig som lenker. |
Fire. | Skriv inn teksten i Brukernavn-boksen. | Tekst kan legges inn med museklikk eller fokus ved å bruke fanen. |
5. | Skriv inn teksten i passordboksen. | Tekst kan legges inn med museklikk eller fokus ved å bruke fanen. |
6. | Klikk på Glemt passord? Link. | Ved å klikke på lenken, skal brukeren komme til det relaterte skjermbildet. |
8. | Skriv inn brukernavn og passord, og klikk på Logg inn-knappen. | Hvis du klikker på Logg inn-knappen, skal du gå til den relaterte skjermen eller applikasjonen. |
9. | Gå til databasen og sjekk at riktig tabellnavn er validert i forhold til inngangsinformasjonen. | Tabellnavnet skal valideres, og et statusflagg bør oppdateres for vellykket eller mislykket pålogging. |
10. | Klikk på påloggingen uten å skrive inn noen tekst i boksen Brukernavn og Passord. | Klikk på Logg inn-knappen for å varsle en meldingsboks ‘Brukernavn og passord er obligatorisk’. |
elleve. | Klikk på Logg inn uten å skrive inn tekst i boksen Brukernavn, men skriv inn tekst i passordboksen. | Klikk på Logg inn-knappen for å varsle en meldingsboks 'Passord er obligatorisk'. |
12. | Klikk på Logg inn uten å skrive inn tekst i passordboksen, men skriv inn tekst i Brukernavn-boksen. | Klikk på Logg inn-knappen for å varsle en meldingsboks ‘Brukernavn er obligatorisk’. |
1. 3. | Skriv inn den maksimalt tillatte teksten i boksen Brukernavn og passord. | Bør godta maksimalt 30 tegn. |
14. | Skriv inn brukernavnet og passordet med spesialtegnene. | Bør ikke godta teksten som begynner med spesialtegn, som ikke er tillatt i Registrering. |
femten. | Skriv inn brukernavnet og passordet med tomme mellomrom. | Bør ikke godta teksten med blanke mellomrom, noe som ikke er tillatt i Registrering. |
16. | Skriv inn teksten i passordfeltet. | Skal ikke vise den faktiske teksten i stedet for å vise stjerne * symbol. |
17. | Oppdater påloggingssiden. | Siden skal oppdateres med både brukernavn og passordfelt blanke. |
18. | Skriv inn brukernavnet. | Avhengig av innstillingene for automatisk fylling av nettleseren, skal tidligere oppgitte brukernavn vises som en rullegardinmeny. |
19. | Skriv inn passordet. | Avhengig av innstillingene for automatisk fylling av nettleseren, skal tidligere angitte passord IKKE vises som en rullegardin. |
tjue. | Flytt fokuset til glemt passordkoblingen ved hjelp av Tab. | Både museklikk og enter-tasten skal kunne brukes. |
tjueen. | Flytt fokuset til registreringskoblingen ved hjelp av Tab. | Både museklikk og enter-tasten skal kunne brukes. |
22. | Oppdater påloggingssiden og trykk Enter-tasten. | Påloggingsknappen skal være fokusert og den relaterte handlingen skal utløses. |
2. 3. | Oppdater påloggingssiden og trykk Tab-tasten. | Det første fokuset på påloggingsskjermen bør være Brukernavn-boksen. |
24. | Skriv inn bruker og passord og la påloggingssiden være inaktiv i 10 minutter. | Meldingsboksvarsel ‘Session utløpt, skriv inn brukernavn og passord igjen’ skal vises med begge brukernavnet og passordfeltene fjernet. |
25. | Skriv inn påloggings-URL i nettlesere Chrome, Firefox og Internet Explorer. | Samme påloggingsskjerm skal vises uten mye avvik på utseendet og følelsen og justeringen av tekst- og skjemakontroller. |
26. | Angi påloggingsinformasjonen og sjekk påloggingsaktiviteten i Chrome, Firefox og Internet Explorer. | Handlingen med påloggingsknappen skal være en og samme i alle nettlesere. |
27. | Sjekk at glemt passord og registrering ikke er ødelagt i Chrome, Firefox og Internet Explorer. | Begge lenkene skal ta til de relative skjermene i alle nettlesere. |
28. | Sjekk at påloggingsfunksjonaliteten fungerer som den skal i Android-mobiltelefoner. | Påloggingsfunksjonen skal fungere på samme måte som den er tilgjengelig i nettversjonen. |
29. | Sjekk at påloggingsfunksjonaliteten fungerer som den skal i Tab og iPhones. | Påloggingsfunksjonen skal fungere på samme måte som den er tilgjengelig i nettversjonen. |
30. | Kontroller påloggingsskjermen som tillater samtidige brukere av systemet, og alle brukerne får påloggingsskjermen uten forsinkelser og innen den definerte tiden på 5-10 sekunder. | Dette bør oppnås ved å bruke mange kombinasjoner av operativsystem og nettlesere, enten fysisk eller virtuelt, eller kan oppnås ved hjelp av noe ytelses- / belastningstestverktøy. |
Testdatainnsamling
Når testsaken skrives, er den viktigste oppgaven for enhver tester å samle inn testdataene. Denne aktiviteten hoppes over og overses av mange testere med forutsetningen om at testsakene kan utføres med noen eksempeldata eller dummy-data og kan mates når dataene virkelig er nødvendige. Dette er en kritisk misforståelse om å mate eksempler på data eller legge inn data fra sinnsminnet på tidspunktet for utførelse av testsaker.
Hvis dataene ikke samles inn og oppdateres i testdokumentet når testene skrives, vil testeren bruke unormalt mer tid på å samle inn dataene på tidspunktet for testutførelsen. Testdataene skal samles for både positive og negative tilfeller fra hele perspektivet til funksjonens flyt av funksjonen. Dokumentet om forretningsbruk er veldig nyttig i denne situasjonen.
Finn et testdokument for prøvene som er skrevet ovenfor, som igjen vil være nyttig for hvor effektivt vi kan samle inn dataene som vil lette jobben vår på tidspunktet for testutførelsen.
Ja Nei | Formål med testdata | Faktiske testdata |
---|---|---|
7. | Test brukernavnet og passordet med alle små tegn | administrator (admin2015) |
1. | Test riktig brukernavn og passord | Administrator (admin2015) |
2. | Test maksimal lengde på brukernavn og passord | Administrator av hovedsystemet (admin2015admin2015admin2015admin) |
3. | Test de tomme feltene for brukernavn og passord | Angi tomme mellomrom ved å bruke mellomromstasten for brukernavn og passord |
Fire. | Test feil brukernavn og passord | Administrator (aktivert) (digx ## $ taxk209) |
5. | Test brukernavnet og passordet med ukontrollerte mellomrom mellom. | Admin istrator (admin 2015) |
6. | Test brukernavnet og passordet med spesialtegn | $% # @ # $ Administrator (% # * # ** # admin) |
8. | Test brukernavnet og passordet med alle store bokstaver | ADMINISTRATOR (ADMIN2015) |
9. | Test påloggingen med samme brukernavn og passord med flere systemer samtidig samtidig. | Administrator (admin2015) - for Chrome i samme maskin og annen maskin med operativsystem Windows XP, Windows 7, Windows 8 og Windows Server. Administrator (admin2015) - for Firefox på samme maskin og annen maskin med operativsystem Windows XP, Windows 7, Windows 8 og Windows Server. Administrator (admin2015) - for Internet Explorer på samme maskin og annen maskin med operativsystem Windows XP, Windows 7, Windows 8 og Windows Server. |
10. | Test påloggingen med brukernavnet og passordet i mobilapplikasjonen. | Administrator (admin2015) - for Safari og Opera i Android-mobiler, iPhones og nettbrett. |
***********************************************
Viktigheten av å standardisere testtilfellene
I denne travle verdenen kan ingen gjøre repeterende ting dag ut og dag med samme nivå av interesse og energi. Spesielt brenner jeg ikke for å gjøre den samme oppgaven igjen og igjen på jobben. Jeg liker å administrere ting og spare tid. Alle i IT skal være det.
Alle IT-selskaper utfører forskjellige typer prosjekter. Disse prosjektene kan enten være produktbaserte eller tjenestebaserte. Av disse prosjektene jobber de fleste rundt nettsteder og nettstedstesting . Den gode nyheten om det er at alle nettsteder har mange likheter. Og hvis nettstedene er for samme domene, har de også flere vanlige funksjoner.
Spørsmålet som alltid forvirrer meg er at: 'Hvis de fleste applikasjoner er like, for eksempel: for eksempel detaljhandelnettsteder, som har blitt testet tusen ganger før,' Hvorfor trenger vi å skrive testtilfeller for enda et detaljhandelnett fra bunnen av? ” Vil det ikke spare mye tid ved å trekke ut de eksisterende testskriptene som ble brukt til å teste et tidligere detaljhandelnettsted?
Visst, det kan være noen små tilpasninger som vi kanskje må gjøre, men generelt er det lettere, effektivt, tid og penger å spare også, og hjelper dermed alltid å holde testnivåene til testere høye. Hvem liker å skrive, gjennomgå og vedlikeholde de samme testsakene gjentatte ganger, ikke sant? Gjenbruk av eksisterende tester kan løse dette i stor grad, og kundene dine vil også finne dette smart og logisk.
Så logisk begynte jeg å hente eksisterende skript fra lignende nettbaserte prosjekter, gjorde endringer og gjorde en rask gjennomgang av dem. Jeg brukte også fargekoding for å vise endringene som ble gjort, slik at anmelderen bare kan fokusere på den delen som er endret.
Grunner til å gjenbruke testsaker
#1) De fleste funksjonelle områder på et nettsted er nesten - pålogging, registrering, legg i handlekurven, ønskeliste, kasse, fraktalternativer, betalingsalternativer, innhold på produktsiden, nylig sett, relevante produkter, kampanjekoder osv.
#to) De fleste av prosjektene er bare forbedringer eller endringer i eksisterende funksjonalitet.
# 3) Innholdsstyringssystemer som definerer sporene for bildeopplasting med statiske og dynamiske måter er også vanlig for alle nettsteder.
# 4) Detaljhandel nettsteder har CSR (Kundeservice) system også.
# 5) Backend-system og lagerapplikasjon ved bruk av JDA brukes også av alle nettsteder.
# 6) Konseptet med informasjonskapsler, tidsavbrudd og sikkerhet er også vanlig.
# 7) Nettbaserte prosjekter er ofte utsatt for kravendringer.
# 8) De typer testing behov er vanlige som nettleser kompatibilitetstesting , ytelsestesting , sikkerhetstesting
Du skjønner, det er mye som er vanlig og lignende.
Når det er sagt at gjenbrukbarhet er veien å gå, noen ganger kan endringene selv ta mer eller mindre tid. Noen ganger kan man føle at det er bedre å starte fra bunnen av enn å endre så mye.
Dette kan enkelt håndteres ved å lage et sett med standard testtilfeller for hver av de vanlige funksjonalitetene.
Hva er en standard test i nettesting?
- Lag testtilfeller som er komplette - trinn, data, variabel, etc. Dette vil sikre at ikke-lignende data / variabel ganske enkelt kan erstattes når en lignende testtilfelle er nødvendig.
- Inngangs- og utgangskriteriene bør være riktig definert.
- De modifiserbare trinnene eller utsagnet i trinnene bør fremheves i en annen farge for raskt å finne og erstatte.
- Språket som brukes til å lage standard testtilfelle bør være generisk.
- Alle funksjonene på hvert nettsted skal dekkes i testtilfellene.
- Navnet på testsakene skal være navnet på funksjonaliteten eller funksjonen som testsaken dekker. Dette vil gjøre det lettere å finne prøvesaken fra settet.
- Hvis det er noen grunnleggende eller standard prøve eller GUI-fil eller skjermbilde av funksjonen, bør den legges ved med de relevante trinnene.
Ved å bruke ovennevnte tips kan man lage et sett med standardskripter og bruke dem med små eller nødvendige modifikasjoner for forskjellige nettsteder.
Disse standard testtilfellene kan også automatiseres, men igjen er det alltid et pluss å fokusere på gjenbrukbarhet. Også hvis automasjon er basert på en GUI, å gjenbruke skriptene på tvers av flere nettadresser eller nettsteder er noe jeg personlig aldri har funnet effektivt.
Å bruke et standardsett med manuelle testtilfeller for forskjellige nettsteder med mindre modifikasjoner er den beste måten å gjennomføre et nettstedstesting. Alt vi trenger er å lage og vedlikeholde testsakene med riktig standard og bruk.
Konklusjon
Forbedring av effektivitet i testtilfeller er ikke et enkelt definert begrep, men det er en øvelse og kan oppnås gjennom en modnet prosess og regelmessig praksis.
Testteamet skal ikke være lei av å bli involvert i forbedring av slike oppgaver, da det er det beste verktøyet for større prestasjoner i kvalitetsverdenen. Dette er bevist i mange av testorganisasjonene over hele verden på oppdragskritiske prosjekter og komplekse applikasjoner.
Håper du ville ha fått enorm kunnskap om begrepet Test Cases. Se vår opplæringsserie for å vite mer om testtilfeller, og uttrykk gjerne tankene dine i kommentarfeltet nedenfor!
Anbefalt lesing
- Funksjonstesting mot ikke-funksjonell testing
- Bærbarhetstestveiledning med praktiske eksempler
- Typer programvaretesting: Ulike testtyper med detaljer
- Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
- Alpha Testing og Beta Testing (En komplett guide)
- Hva er systemtesting - en Ultimate Beginner's Guide
- ISTQB Testing Certification Sample Question Papers With Answers
- Hvordan skrive programvaretesting ukentlig statusrapport