180+ testeksempler på nettapplikasjonstester (prøvesjekkliste)

180 web application testing example test cases

Test av nettapplikasjon Eksempel på testtilfeller: Dette er en komplett testsjekkliste for både nettbaserte og stasjonære applikasjoner.

Dette er en veldig omfattende liste over eksempler på testtilfeller / scenarier. Målet vårt er å dele en av de mest omfattende testsjekklistene som noensinne er skrevet, og dette er ikke gjort ennå.

Vi vil fortsette å oppdatere dette innlegget i fremtiden, med flere testtilfeller og scenarier. Hvis du ikke har tid til å lese den nå, kan du gjerne dele dette med vennene dine og legge det til bokmerke for senere.

Lag en testsjekkliste som en integrert del av testprosessen. Ved hjelp av denne sjekklisten kan du enkelt lage hundrevis av Test tilfeller for testing av nett- eller stasjonære applikasjoner.

Dette er alle generelle testtilfeller og bør gjelde for nesten alle slags applikasjoner. Henvis til disse testene mens du skriver testtilfeller for prosjektet ditt, og jeg er sikker på at du vil dekke det meste testtyper bortsett fra de applikasjonsspesifikke forretningsreglene gitt i SRS-dokumentene.

Selv om dette er en vanlig sjekkliste, anbefaler jeg at du utarbeider en standard testsjekkliste som er skreddersydd til dine spesifikke behov, ved å bruke nedenstående testtilfeller i tillegg til applikasjonsspesifikke tester.

Anbefalt verktøy:

Før du fortsetter skriveprosessen, anbefaler vi at du laster ned dette testsaksbehandlingsverktøyet. Dette vil lette testplanen og testprosessen som er nevnt i denne veiledningen.

=> Last ned TestRail Test Case Management Tool

Viktigheten av å bruke en sjekkliste for testing

#1) Ved å opprettholde et standardregister med gjenbrukbare testtilfeller for applikasjonen din, vil du sikre at de vanligste feilene blir fanget raskere.
#to) En sjekkliste hjelper deg med å fullføre skrivetestsaker raskt for nye versjoner av applikasjonen.
# 3) Gjenbruk av testsakene bidrar til å spare penger på ressurser til å skrive repetitive tester.
# 4) Viktige testsaker vil alltid bli dekket, og dermed blir det nesten umulig å glemme.
# 5) Testsjekklisten kan henvises av utviklere for å sikre om de vanligste problemene løses i selve utviklingsfasen.

Merknader:

• Utfør disse scenariene med forskjellige brukerroller, f.eks. admin bruker, gjest bruker etc.
• For webapplikasjoner, disse scenariene bør testes på flere nettlesere som IE, FF, Chrome og Safari med versjoner godkjent av klienten.
• Test med forskjellige skjermoppløsninger som 1024 x 768, 1280 x 1024, etc.
• En applikasjon skal testes på en rekke skjermer som LCD, CRT, bærbare datamaskiner, nettbrett og mobiltelefoner.
• Test applikasjon på forskjellige plattformer som Windows, Mac, Linux operativsystemer etc.

Hva du vil lære:

• 180+ eksempler på testtilfeller for nettapplikasjoner
  • Generelle testscenarier
  • GUI og brukervennlighetstest scenarier
    • Testscenarier for filterkriterier
    • Test scenarier for resultatgitter
    • Test scenarier for et vindu
  • Database Testing Test Scenarios
    • Test scenarier for funksjonalitet for bildeopplasting
    • Test scenarier for sending av e-post
    • Test scenarier for Excel-eksportfunksjonalitet
  • Ytelsestesting Testscenarier
  • Sikkerhetstesting Testscenarier
• 100+ ferdige testtilfeller (sjekklister)
  • Den komplette sjekklisten (testtilfeller) for de vanligste komponentene i AUT
    • Sjekkliste 1: Sjekkliste for mobil testing
    • Sjekkliste nr. 2: Sjekkliste for skjemaer / skjermtesting
    • Sjekkliste # 3: Sjekkliste for felttesting av tekstboks
    • Sjekkliste nr. 4: Sjekkliste for listeboks eller rullegardinliste
    • Sjekkliste 5: Sjekkliste Sjekkliste for felttesting
    • Sjekkliste 6: Sjekkliste for radioknapptesting
    • Sjekkliste 7: Scenarier for datofelt
    • Sjekkliste 8: Lagre knappes testscenarier
    • Sjekkliste 9: Avbryt knappescenarier
    • Sjekkliste # 10: Slett knappeprøver
    • Sjekkliste 11: Å verifisere berørte områder etter lagring eller oppdatering
    • Sjekkliste 12: Data Grid Testing List
  • Anbefalt lesing

180+ eksempler på testtilfeller for nettapplikasjoner

Antagelser: Anta at applikasjonen din støtter følgende funksjoner

• Skjemaer med forskjellige felt
• Barne vinduer
• Søknaden samhandler med databasen
• Ulike søkefilterkriterier og vise resultater
• Bildeopplasting
• Send e-postfunksjonalitet
• Dataeksportfunksjonalitet

Generelle testscenarier

1. Alle obligatoriske felt skal valideres og angis med et stjerne (*) symbol.
2. Valideringsfeilmeldinger skal vises riktig i riktig posisjon.
3. Alle feilmeldinger skal vises i samme CSS-stil ( For eksempel, bruker rød farge)
4. Generelle bekreftelsesmeldinger skal vises ved hjelp av en annen CSS-stil enn feilmeldingsstil ( For eksempel, bruker grønn farge)
5. Tekst fra verktøytips skal være meningsfull.
6. Nedtrekksfelt skal ha den første oppføringen som blank eller tekst som 'Velg'.
7. 'Slett funksjonalitet' for alle poster på en side bør be om bekreftelse.
8. Velg / fjern merket for alle poster, alternativet skal gis hvis siden støtter funksjoner for legg til / slett / oppdater
9. Beløpsverdiene skal vises med riktige valutasymboler.
10. Standardsidesortering skal oppgis.
11. Tilbakestill knappfunksjonalitet bør angi standardverdier for alle felt.
12. Alle numeriske verdier skal være riktig formatert.
13. Inndatafelt bør sjekkes for maksimal feltverdi. Inndataverdier som er større enn den angitte maksimale grensen, skal ikke aksepteres eller lagres i databasen.
14. Sjekk alle inndatafelt for spesialtegn.
15. Feltetiketter skal være standard f.eks. felt som godtar brukerens fornavn, skal merkes riktig som 'Fornavn'.
16. Sjekk sidesorteringsfunksjonalitet etter at du har lagt til / redigert / slettet operasjoner på alle poster.
17. Se etter tidsavbruddsfunksjonalitet. Timeout-verdier skal kunne konfigureres. Kontroller applikasjonsadferd etter tidsavbrudd for operasjonen.
18. Sjekk informasjonskapsler som brukes i et program.
19. Sjekk om nedlastbare filer peker mot riktige filbaner.
20. Alle ressursnøkler skal være konfigurerbare i konfigurasjonsfiler eller database i stedet for hard koding.
21. Standardkonvensjoner bør følges hele veien for å navngi ressursnøkler.
22. Valider markering for alle websider (valider HTML og CSS for syntaksfeil) for å sikre at den er i samsvar med standardene.
23. Søknadskrasj eller utilgjengelige sider bør omdirigeres til feilsiden.
24. Sjekk teksten på alle sider for stavefeil og grammatiske feil.
25. Sjekk numeriske inndatafelt med tegninntastingsverdier. En riktig valideringsmelding skal vises.
26. Se etter negative tall hvis tillatt for numeriske felt.
27. Sjekk antall felt med desimalverdier.
28. Sjekk funksjonaliteten til knappene som er tilgjengelige på alle sider.
29. Brukeren skal ikke kunne sende inn en side to ganger ved å trykke på send-knappen raskt etter hverandre.
30. Divisjon med null feil skal håndteres for alle beregninger.
31. Inngangsdata med den første og siste posisjonen blank skal håndteres riktig.

c ++ tegn til streng

GUI og brukervennlighetstest scenarier

1. Alle felt på en side ( For eksempel, tekstboks, radioalternativer, rullegardinlister) skal justeres riktig.
2. Numeriske verdier bør rettferdiggjøres riktig med mindre annet er spesifisert.
3. Det bør gis nok plass mellom feltetiketter, kolonner, rader, feilmeldinger osv.
4. Rullefeltet skal bare være aktivert når det er nødvendig.
5. Skriftstørrelse, stil og farge for overskrift, beskrivelsestekst, etiketter, infieldata og rutenettinformasjon skal være standard som spesifisert i SRS.
6. Tekstboksen for beskrivelsen skal være flerlinjet.
7. Deaktiverte felt skal være nedtonet, og brukere skal ikke kunne sette fokus på disse feltene.
8. Når du klikker på et inntastingsfelt, skal musepilepekeren endres til markøren.
9. Brukeren skal ikke kunne skrive inn rullegardinlistene.
10. Informasjon fylt av brukere skal forbli intakt når det er en feilmelding på siden som sendes inn. Brukeren skal kunne sende inn skjemaet på nytt ved å rette feilene.
11. Sjekk om riktige feltetiketter brukes i feilmeldinger.
12. Verdier for rullegardinfelt skal vises i definert sorteringsrekkefølge.
13. Tab og Shift + Tab rekkefølge skal fungere ordentlig.
14. Standard radioalternativer bør velges på forhånd ved sideinnlasting.
15. Feltspesifikke og meldingsnivåer på sidenivå bør være tilgjengelige.
16. Sjekk om riktige felt er uthevet i tilfelle feil.
17. Sjekk om alternativene for rullegardinlisten er lesbare og ikke avkortet på grunn av feltstørrelsesbegrensninger.
18. Alle knapper på en side skal være tilgjengelige med hurtigtaster, og brukeren skal kunne utføre alle operasjoner ved hjelp av et tastatur.
19. Sjekk alle sidene for ødelagte bilder.
20. Sjekk alle sidene for ødelagte lenker.
21. Alle sider skal ha en tittel.
22. Bekreftelsesmeldinger skal vises før du utfører en oppdatering eller sletting.
23. Timeglass skal vises når applikasjonen er opptatt.
24. Sidetekst skal være venstrejustert.
25. Brukeren skal kunne velge bare ett radioalternativ og hvilken som helst kombinasjon for avkrysningsruter.

Testscenarier for filterkriterier

1. Brukeren skal kunne filtrere resultatene ved hjelp av alle parametere på siden.
2. Avgrens søkefunksjonaliteten skal laste søkesiden med alle brukervalgte søkeparametere.
3. Når det er minst ett filterkriterium som kreves for å utføre søkeoperasjonen, må du sørge for at riktig feilmelding vises når brukeren sender inn siden uten å velge noen filterkriterier.
4. Når minst ett valg av filterkriterier ikke er obligatorisk, bør brukeren kunne sende inn siden, og standardsøkekriteriene skal venne seg til å søke resultater.
5. Korrekte valideringsmeldinger skal vises for alle ugyldige verdier for filterkriterier.

Test scenarier for resultatgitter

1. Symbolet for sideinnlasting skal vises når det tar mer enn standard tid å laste inn resultatsiden.
2. Sjekk om alle søkeparametrene brukes til å hente data som vises i resultatrutenettet.
3. Totalt antall resultater skal vises i resultatrutenettet.
4. Søke kriterier som brukes for søking skal vises i resultatrutenettet.
5. Verdier for resultatrutenett skal sorteres som standardkolonne.
6. Sorterte kolonner skal vises med et sorteringsikon.
7. Resultatnettene skal inneholde alle de angitte kolonnene med riktige verdier.
8. Stigende og synkende sorteringsfunksjonalitet skal fungere for kolonner som støttes av datasortering.
9. Resultatnett skal vises med riktig kolonne- og radavstand.
10. Paginering bør aktiveres når det er flere resultater enn standard resultatantall per side.
11. Se etter funksjoner for paginering på neste, forrige, første og siste side.
12. Dupliserte poster skal ikke vises i resultatrutenettet.
13. Sjekk om alle kolonnene er synlige, og om nødvendig er en vannrett rullefelt aktivert.
14. Sjekk dataene for dynamiske kolonner (kolonner hvis verdier beregnes dynamisk basert på de andre kolonneverdiene).
15. For resultatnett som viser rapporter, sjekk 'Totals' -raden og verifiser summen for hver kolonne.
16. For resultatnett som viser rapporter, sjekk 'Totals' raddata når paginering er aktivert og brukeren blir navigert til neste side.
17. Sjekk om riktige symboler brukes til å vise kolonneverdier, f.eks. % -symbolet skal vises for prosentberegning.
18. Sjekk resultatdata for å vite om datoperioden er aktivert.

Test scenarier for et vindu

1. Sjekk om standardvindusstørrelsen er riktig.
2. Sjekk om barnets vindusstørrelse er riktig.
3. Sjekk om det er noe felt på siden med standardfokus (generelt sett bør fokus settes på det første inndatafeltet på skjermen).
4. Sjekk om barnevinduer lukkes når foreldre- / åpningsvinduet lukkes.
5. Hvis barnevinduet åpnes, skal ikke brukeren kunne bruke eller oppdatere noe felt i bakgrunnen eller foreldrevinduet
6. Kontroller at vinduet minimerer, maksimerer og lukker funksjonalitet.
7. Sjekk om vinduet kan endres.
8. Sjekk funksjonen for rullefeltet for foreldre- og barnevinduer.
9. Kontroller funksjonen for avbryt-knapp for barnevinduet.

Database Testing Test Scenarios

1. Sjekk om riktige data blir lagret i databasen når en vellykket side er sendt.
2. Sjekk verdier for kolonner som ikke godtar nullverdier.
3. Se etter dataintegritet. Data skal lagres i enkle eller flere tabeller basert på designet.
4. Indeksnavn skal gis i henhold til standardene, f.eks. IND__
5. Tabeller skal ha en hovednøkkelkolonne.
6. Tabellkolonner bør ha beskrivelsesinformasjon tilgjengelig (unntatt revisjonskolonner som opprettet dato, opprettet av osv.)
7. For hver database skal det legges til / oppdateres operasjonslogg.
8. Nødvendige tabellindekser bør opprettes.
9. Sjekk om data er forpliktet til databasen bare når operasjonen er fullført.
10. Data bør rulles tilbake i tilfelle mislykkede transaksjoner.
11. Databasenavn skal gis i henhold til applikasjonstypen, dvs. test, UAT, sandkasse, live (selv om dette ikke er en standard, er det nyttig for databasevedlikehold)
12. Logiske navn på databaser skal gis i henhold til databasenavnet (igjen er dette ikke standard, men nyttig for DB-vedlikehold).
13. Lagrede prosedyrer skal ikke navngis med prefikset “sp_”
14. Sjekk om verdier for tabellrevisjonskolonner (som opprettet dato, opprettet av, oppdatert, oppdatert av, er slettet, slettede data, slettet av osv.) Er fylt ut riktig.
15. Sjekk om inndata ikke er avkortet mens du lagrer. Feltlengden som vises til brukeren på siden og i databaseskjemaet, skal være den samme.
16. Sjekk numeriske felt med minimums-, maksimums- og flottørverdier.
17. Sjekk numeriske felt med negative verdier (for både aksept og ikke aksept).
18. Sjekk om alternativknappene og rullegardinlistealternativene er lagret riktig i databasen.
19. Sjekk om databasefeltene er utformet med riktig datatype og datalengde.
20. Sjekk om alle tabellbegrensninger som primærnøkkel, fremmednøkkel osv. Er implementert riktig.
21. Test lagrede prosedyrer og utløsere med prøveinndata.
22. Feltledende og etterfølgende mellomrom skal avkortes før data overføres til databasen.
23. Nullverdier skal ikke være tillatt for kolonnen Primær nøkkel.

Test scenarier for funksjonalitet for bildeopplasting

(Gjelder også for annen filopplastingsfunksjonalitet)
1. Se etter opplastede bildebaner.
2. Sjekk bildeopplasting og endre funksjonalitet.
3. Kontroller funksjonen for bildeopplasting med bildefiler med forskjellige utvidelser ( For eksempel, JPEG, PNG, BMP, etc.)
4. Sjekk funksjonaliteten for bildeopplasting med bilder som har plass eller et annet tillatt spesialtegn i filnavnet.
5. Sjekk duplikatopplasting av navnebilde.
6. Kontroller bildeopplasting med bildestørrelse større enn maks. Tillatt størrelse. Riktig feilmelding skal vises.
7. Sjekk funksjonen for opplasting av bilder med andre filtyper enn bilder ( For eksempel, txt, doc, pdf, exe, etc.). En riktig feilmelding skal vises.
8. Sjekk om bilder med spesifisert høyde og bredde (hvis definert) aksepteres ellers avvist.
9. Fremdriftslinjen for bildeopplasting skal vises for bilder i stor størrelse.
10. Sjekk om funksjonen for avbryt-knappen fungerer mellom opplastingsprosessen.
11. Sjekk om dialogboksen for filvalg bare viser støttede filer som er oppført.
12. Kontroller at flere bilder lastes opp.
13. Sjekk bildekvaliteten etter opplasting. Bildekvaliteten skal ikke endres etter opplasting.
14. Sjekk om brukeren er i stand til å bruke / se de opplastede bildene.

Test scenarier for sending av e-post

(Test tilfeller for å komponere eller validere e-post er ikke inkludert her)
(Sørg for å bruke dummy-e-postadresser før du utfører e-postrelaterte tester)
1. E-postmalen skal bruke standard CSS for alle e-postmeldinger.
2. E-postadresser bør valideres før du sender e-post.
3. Spesialtegn i e-posttekstmalen skal håndteres riktig.
4. Språkspesifikke tegn ( For eksempel, Russiske, kinesiske eller tyskspråklige tegn) bør håndteres riktig i e-postkroppsmalen.
5. E-postemnet skal ikke være tomt.
6. Plassholderfelt som brukes i e-postmalen, bør erstattes med faktiske verdier, f.eks. {Fornavn} {Etternavn} skal erstattes med en persons for- og etternavn riktig for alle mottakerne.
7. Hvis rapporter med dynamiske verdier er inkludert i e-postdelen, og rapportdataene skal beregnes riktig.
8. Navnet på e-postavsenderen skal ikke være tomt.
9. E-post skal sjekkes i forskjellige e-postklienter som Outlook, Gmail, Hotmail, Yahoo! post osv.
10. Merk av for å sende e-postfunksjonalitet ved å bruke TO-, CC- og BCC-felt.
11. Sjekk e-post med vanlig tekst.
12. Sjekk e-post i HTML-format.
13. Sjekk topptekst og bunntekst for e-post for firmalogo, personvernregler og andre lenker.
14. Sjekk e-post med vedlegg.
15. Merk av for å sende e-postfunksjonalitet til mottakere av enkelt-, flere eller distribusjonslister.
16. Sjekk om svaret på e-postadressen er riktig.
17. Merk av for å sende det høye e-postvolumet.

Test scenarier for Excel-eksportfunksjonalitet

1. Filen skal eksporteres til riktig filtype.
2. Filnavnet for den eksporterte Excel-filen skal være i samsvar med standardene, For eksempel, Hvis filnavnet bruker tidsstempelet, bør det erstattes riktig med et faktisk tidsstempel når filen eksporteres.
3. Se etter datoformat hvis eksportert Excel-fil inneholder datakolonnene.
4. Sjekk tallformatering for numeriske eller valutaverdier. Formateringen skal være den samme som vist på siden.
5. Den eksporterte filen skal ha kolonner med riktige kolonnenavn.
6. Standardsidesortering bør også føres i den eksporterte filen.
7. Excel-fildata skal være formatert riktig med topp- og bunntekst, dato, sidetall, etc. verdier for alle sider.
8. Sjekk om dataene som vises på en side og eksportert Excel-fil er de samme.
9. Kontroller eksportfunksjonalitet når paginering er aktivert.
10. Sjekk om eksportknappen viser riktig ikon i henhold til den eksporterte filtypen, For eksempel, Excel-filikon for xls-filer
11. Sjekk eksportfunksjonalitet for filer med veldig stor størrelse.
12. Kontroller eksportfunksjonaliteten for sider som inneholder spesialtegn. Sjekk om disse spesialtegnene eksporteres riktig i Excel-filen.

Ytelsestesting Testscenarier

1. Sjekk om sidetiden er innenfor akseptabelt område.
2. Kontroller sidelastningen på langsomme tilkoblinger.
3. Kontroller responstiden for handling under lette, normale, moderate og tunge belastningsforhold.
4. Kontroller ytelsen til databaselagrede prosedyrer og utløsere.
5. Sjekk gjennomføringstiden for databasesøket.
6. Se etter belastningstesting av applikasjonen.
7. Se etter stresstestingen av applikasjonen.
8. Sjekk CPU- og minnebruk under toppbelastningsforhold.

Sikkerhetstesting Testscenarier

1. Se etter SQL-injeksjonsangrep.
2. Sikre sider skal bruke HTTPS-protokollen.
3. Sidekrasj skal ikke avsløre applikasjons- eller serverinfo. Feilsiden skal vises for dette.
4. Unnslippe spesialtegn i inngangen.
5. Feilmeldinger skal ikke avsløre sensitiv informasjon.
6. All legitimasjon skal overføres over en kryptert kanal.
7. Test passordsikkerhet og passordhåndhevelse.
8. Sjekk programavloggingsfunksjonaliteten.
9. Se etter Brute Force-angrep.
10. Informasjon om informasjonskapsler skal bare lagres i kryptert format.
11. Kontroller sesjonens informasjonskapselvarighet og øktavslutning etter tidsavbrudd eller avlogging.
11. Øktemerket skal overføres over en sikret kanal.
13. Passordet skal ikke lagres i informasjonskapsler.
14. Test for denial of service-angrep.
15. Test for minnelekkasje.
16. Test uautorisert applikasjonstilgang ved å manipulere variable verdier i nettleserens adressefelt.
17. Test utlevering av filtypen slik at exe-filer ikke lastes opp og kjøres på serveren.
18. Følsomme felt som passord og kredittkortinformasjon trenger ikke å være fullstendig aktivert.
19. Filopplastingsfunksjonalitet bør bruke filtypebegrensninger og også antivirus for skanning av opplastede filer.
20. Sjekk om katalogoppføring er forbudt.
21. Passord og andre sensitive felt skal maskeres mens du skriver.
22. Sjekk om glemt passordfunksjonalitet er sikret med funksjoner som midlertidig passordutløp etter angitte timer, og sikkerhetsspørsmål blir spurt før du endrer eller ber om et nytt passord.
23. Bekreft CAPTCHA-funksjonalitet.
24. Sjekk om viktige hendelser er logget inn i loggfiler.
25. Sjekk om tilgangsrettigheter er implementert riktig.

Penetrasjonstesting testtilfeller - Jeg har listet rundt 41 testsaker for Penetration Testing på denne siden .

Jeg vil virkelig takke Devanshu lavaniya (Sr. QA Engineer som jobber for I-link Infosoft) for å hjelpe meg med å utarbeide denne omfattende testsjekklisten.

Jeg har prøvd å dekke nesten alle standard testscenarier for funksjonalitet for nett- og skrivebordsprogrammer. Men likevel vet jeg at dette ikke er en komplett sjekkliste. Testere på forskjellige prosjekter har sin egen testsjekkliste basert på deres erfaring.

Oppdatert:

100+ ferdige testtilfeller (sjekklister)

Du kan bruke denne listen til å teste de vanligste komponentene i AUT

Hvordan tester du de vanligste komponentene i AUT effektivt, hver eneste gang?

Denne artikkelen er en liste over vanlige valideringer på mest funnet elementer av AUT - som er satt sammen for å gjøre det lettere for testere (spesielt i det smidige miljøet der hyppige kortsiktige utgivelser skjer).

Hver AUT (Application Under Test) er unik og har et veldig spesifikt forretningsformål. De individuelle aspektene (modulene) av AUT imøtekommer forskjellige operasjoner / handlinger som er avgjørende for suksessen til virksomheten som AUT støtter.

Selv om hver AUT er utformet annerledes, er individuelle komponenter / felt som vi møter på de fleste sider / skjermer / applikasjoner de samme med mer eller mindre lignende oppførsel.

Noen vanlige komponenter i AUT:

• Lagre, oppdater, slett, tilbakestill, avbryt, OK - lenker / knapper - hvis funksjonalitet er merket for objektet.
• Tekstboks, rullegardin, avkrysningsruter, radioknapper, datostyringsfelt - som fungerer på samme måte hver gang.
• Datanettverk, berørte områder osv. For å lette rapporter.

Måten disse individuelle elementene bidrar til den generelle funksjonaliteten i applikasjonen kan være annerledes, men trinnene for å validere dem er alltid de samme.

La oss fortsette med listen over vanligste valideringer for Web- eller skrivebordsprogram sider / skjemaer.

Merk : Det faktiske resultatet, forventet resultat, testdata og andre parametere som vanligvis er en del av en testtilfelle er utelatt for enkelhets skyld - En generell sjekklistetilnærming benyttes.

utvalg sorteringsalgoritme c ++

Formålet med denne omfattende sjekklisten:

Hovedformålet med disse sjekklistene (eller testtilfellene) er å sikre maksimal testdekning på feltnivåvalidering uten å bruke for mye tid, samtidig som det ikke går ut over kvaliteten på å teste dem.

Tross alt kan tillit til et produkt bare oppnås ved å teste hvert enkelt element i best mulig grad.

Den komplette sjekklisten (testtilfeller) for de vanligste komponentene i AUT

Merk:Du kan bruke disse sjekklistene som de er i Microsoft Excel-format (nedlasting gitt på slutten av artikkelen). Du kan til og med spore testutførelsen i den samme filen med pass / fail-resultater og status.

Dette kan være en alt-i-ett-ressurs for QA-team for å teste og spore de vanligste komponentene i AUT.Du kan legge til eller oppdatere testsaker som er spesifikke for applikasjonen dinog gjøre det til en enda mer omfattende liste.

Sjekkliste 1: Sjekkliste for mobil testing

Sjekkliste nr. 2: Sjekkliste for skjemaer / skjermtesting

Sjekkliste # 3: Sjekkliste for felttesting av tekstboks

Tekstboks:

BVA (størrelse) for tekstboks:

Min —>—> Pass
Min-1 -> -> Feil
Min+1 —> —> Pass
Max-1 -> -> Bestått
Maks + 1 -> -> Mislykkes
Maks -> -> Bestått

ECP for tekstboks:

Sjekkliste nr. 4: Sjekkliste for listeboks eller rullegardinliste

Listeboks / rullegardin:

Sjekkliste 5: Sjekkliste Sjekkliste for felttesting

Sjekkboks:

Sjekkliste 6: Sjekkliste for radioknapptesting

Radioknapp:

Sjekkliste 7: Scenarier for datofelt

Datofelt:

Sjekkliste 8: Lagre knappes testscenarier

Lagre / oppdater:

Sjekkliste 9: Avbryt knappescenarier

Avbryt:

Sjekkliste # 10: Slett knappeprøver

Slett:

Sjekkliste 11: Å verifisere berørte områder etter lagring eller oppdatering

Etter lagring / oppdatering:

Sjekkliste 12: Data Grid Testing List

Datarutenett:

Rediger lenkefunksjonalitet

Selv om denne listen kanskje ikke er uttømmende, er den virkelig omfattende.

NEDLASTING==> Du kan laste ned alle disse sjekklistene i MS Excel-format: Last ned i Excel-format

Poeng å merke seg:

1. Avhengig av ditt behov kan tilleggstester under hver kategori / for hvert felt legges til eller eksisterende felt kan fjernes. Disse listene er med andre ord helt tilpassbare.
2. Når du har behov for å inkludere validering på feltnivå til testseriene dine, er alt du trenger å gjøre å plukke opp den aktuelle listen og bruke den til skjermen / siden du vil teste.
3. Vedlikehold sjekklisten ved å oppdatere pass / fail-statusen for å gjøre dette til en one-stop-shop for å liste opp funksjoner, validere dem og registrere testresultatene.

Du kan gjerne gjøre dette til en fullstendig sjekkliste ved å legge til flere testsaker / scenarier eller negative testsaker i kommentarfeltet nedenfor.

Jeg vil også sette pris på om du vil dele dette med vennene dine!

PREV Opplæring | NESTE veiledning

Anbefalt lesing

• Hvordan skrive testsaker: Den ultimate guiden med eksempler
• Testing og testtilfeller for nettsider for testing av webapplikasjonskapsler
• Eksempel på prøvesaksmal med eksempler på prøvesaker (Last ned)
• Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
• Veiledning for testing av webapplikasjoner
• Applikasjonstesting - inn i det grunnleggende om programvaretesting!
• Installere applikasjonen din på enheten og start testing fra Eclipse
• TDD vs BDD - Analyser forskjellene med eksempler