Eksempel på testtilfeller for nettapplikasjon (sjekkliste)

by: Thomas Hamilton Thomas Hamilton
Hours oppdatert

⚡ Smart oppsummering

En komplett sjekkliste for testing av webapplikasjoner dekker brukervennlighet, funksjonalitet, kompatibilitet, database, API, sikkerhet, ytelse og tilgjengelighetskontroller. Hver seksjon nedenfor inneholder bruksklare testscenarier som kvalitetssikringsteam kan kopiere direkte inn i et testadministrasjonsverktøy.

  • ⚙️ Funksjonell først: Valider obligatoriske felt, grenselengder, skuddår, divisjon med null og tidsavbruddsvirkemåte før noen kosmetisk gjennomgang starter.
  • 🧭 Brukervennlighetssignaler: Sjekk justering, verktøytips, tastaturtilgang, rullefelt og gjenoppretting av feilmeldinger, slik at en førstegangsbruker aldri blir sittende fast.
  • 🌐 Kompatibilitetsmatrise: Gjenta kritiske flyter på Chrome, Firefox, Edge, Safari og mobilnettlesere for å avdekke forskjeller i layout og skript.
  • 🗄️ Databaseintegritet: Match frontend-verdier mot lagrede poster, bekreft nøkler, utløsere, lagrede prosedyrer og feltlengder på begge lag.
  • 🔌 API-lag: Angi statuskoder, skjemaer, autentisering, hastighetsgrenser og håndtering av nedstrøms feil separat fra nettleseren.
  • 🔐 Sikkerhetsgrunnlag: Tving HTTPS, krypter lagrede hemmeligheter, lås kontoer etter gjentatte feil og undersøk for SQL-injeksjon og brute force.
  • 🚀 Ytelse og tilgang: Skript laster inn profiler med automatisering i stedet for manuell innsats, og bekreft deretter WCAG-kontrast, etiketter og tastaturoperasjoner.
Les mer

Mens du tester nettapplikasjonene, bør du vurdere malen nedenfor. Sjekklisten nedenfor er nesten aktuelt for alle typer nettapplikasjoner avhengig av forretningskravene.

Malen ovenfor viser hvordan ett ark kan inneholde scenarioer for hvert sjekklisteområde. For bakgrunn, se testing av webapplikasjoner oversikt.

La oss nå se hver sjekkliste i detalj:

Funksjonell testing

Hva er funksjonstesting?

  • Testing av funksjonene og funksjonaliteten til et produkt for å sikre at de samsvarer med spesifikasjonene.
  • Testing som ignorerer den interne mekanismen til et system eller en komponent og fokuserer utelukkende på utgangene generert som svar på utvalgte innganger og utførelsesforhold.

Hva er hensikten eller målet med funksjonstesting?

  • Målet med Funksjonell testing er å verifisere om produktet ditt oppfyller de tiltenkte funksjonsspesifikasjonene nevnt i utviklingsdokumentasjonen.

Eksempel på funksjonstestscenarier:

  • Test alle de obligatoriske feltene bør valideres.
  • Test stjernetegnet skal vises for alle de obligatoriske feltene.
  • Test systemet skal ikke vise feilmeldingen for valgfrie felt.
  • Test at skuddår er korrekt validert og ikke forårsaker feil/feilberegninger.
  • Test de numeriske feltene skal ikke akseptere alfabetene og riktig feilmelding skal vises.
  • Test for negative tall hvis det er tillatt for numeriske felt.
  • Testdeling med null bør håndteres riktig for beregninger.
  • Test makslengden på hvert felt for å sikre at dataene ikke er avkortet.
  • Test popup-meldingen ("Dette feltet er begrenset til 500 tegn") skal vises hvis dataene når den maksimale størrelsen på feltet.
  • Test at en bekreftelsesmelding skal vises for oppdatering og sletting.
  • Test beløpsverdiene skal vises i valutaformat.
  • Test alle inndatafelt for spesialtegn.
  • Test funksjonaliteten for tidsavbrudd.
  • Test sorteringsfunksjonaliteten.
  • Test funksjonaliteten til de tilgjengelige knappene
  • Test personvernreglene og vanlige spørsmål er klart definert og bør være tilgjengelig for brukere.
  • Test om noen funksjonalitet mislykkes, blir brukeren omdirigert til den egendefinerte feilsiden.
  • Test at alle opplastede dokumenter er åpnet riktig.
  • Test brukeren skal kunne laste ned de opplastede filene.
  • Test e-postfunksjonaliteten til systemet.
  • Test Java skriptet fungerer som det skal i forskjellige nettlesere (IE, Firefox, Chrome, safari og Opera).
  • Test for å se hva som skjer hvis en bruker sletter informasjonskapsler mens han er på nettstedet.
  • Test for å se hva som skjer hvis en bruker sletter informasjonskapsler etter å ha besøkt et nettsted.
  • Test alle dataene i kombinasjons-/listeboksen er ordnet i kronologisk rekkefølge.

Når funksjoner oppfører seg som de skal, er neste spørsmål om ekte brukere kan betjene dem uten hjelp.

Brukervennlighetstesting

Hva er brukervennlighetstesting?

  • Brukervennlighetstesting er ingenting annet enn brukervennlighetssjekken.
  • I brukervennlighetstesting testes applikasjonsflyten slik at en ny bruker enkelt kan forstå applikasjonen.
  • I utgangspunktet sjekkes systemnavigasjon i brukervennlighetstesting.

Hva er hensikten eller målet med brukervennlighetstesting?

En brukervennlighetstest fastslår brukervennligheten og effektiviteten til et produkt ved å bruke standard brukbarhetstestpraksis.

Eksempler på brukervennlighetstest

  • Innholdet på nettsiden skal være korrekt uten stave- eller grammatiske feil
  • Alle fonter skal være de samme i henhold til kravene.
  • All tekst skal være riktig justert.
  • Alle feilmeldingene skal være korrekte uten stave- eller grammatiske feil, og feilmeldingen skal samsvare med feltetiketten.
  • Verktøytipstekst bør være der for hvert felt.
  • Alle feltene skal være riktig justert.
  • Det bør gis nok plass mellom feltetiketter, kolonner, rader og feilmeldinger.
  • Alle knappene skal være i standard format og størrelse.
  • Hjemlinken skal være der på hver eneste side.
  • Deaktiverte felt skal være nedtonet.
  • Se etter ødelagte lenker og bilder.
  • Bekreftelsesmelding skal vises for enhver form for oppdatering og sletting.
  • Sjekk siden på forskjellige oppløsninger (640 x 480, 600×800 osv.?)
  • Sjekk at sluttbrukeren kan kjøre systemet uten frustrasjon.
  • Sjekk at fanen skal fungere som den skal.
  • Rullefelt skal bare vises hvis nødvendig.
  • Hvis det er en feilmelding ved innsending, skal informasjonen fylt ut av brukeren være der.
  • Tittelen skal vises på hver nettside
  • Alle felt (tekstboks, rullegardin, alternativknapp osv.) og knapper skal være tilgjengelige med hurtigtaster, og brukeren skal kunne utføre alle operasjoner ved å bruke tastaturet.
  • Sjekk om rullegardindataene ikke er avkortet på grunn av feltstørrelsen. Sjekk også om dataene er hardkodet eller administrert via administrator.

Et oppsett som leses godt i én nettleser kan svikte i en annen, så spill av de samme skjermbildene på tvers av alle støttede miljøer.

RELATERTE ARTIKLER

Test av kompatibilitet

Hva er kompatibilitetstesting?

  • Kompatibilitetstesting brukes til å avgjøre om programvaren din er kompatibel med andre elementer i et system som den skal fungere med, for eksempel nettlesere, Operating systemer eller maskinvare.

Hva er hensikten eller målet med kompatibilitetstesting?

  • Formålet med kompatibilitetstesting er å evaluere hvor godt programvare fungerer i en bestemt nettleser, Operating systemer, maskinvare eller programvare.

Eksempel på kompatibilitetstestscenarier:

  • Test nettstedet i forskjellige nettlesere (IE, Firefox, Chrome, Safari og Opera) og sørg for at nettstedet vises riktig.
  • Test HTML-versjonen som brukes er kompatibel med aktuelle nettleserversjoner.
  • Test bildene som vises riktig i forskjellige nettlesere.
  • Test at skriftene er brukbare i forskjellige nettlesere.
  • Test java-skriptkoden er brukbar i forskjellige nettlesere.
  • Test de animerte GIF-ene på tvers av forskjellige nettlesere.

Konsekvent gjengivelse beviser ingenting om opptegnelsene bak skjermen. testing på tvers av nettlesere matrise holder dette området håndterbart.

Databasetesting

Hva er databasetesting?

  • In Databasetesting backend-poster er testet som er satt inn via web- eller skrivebordsapplikasjoner. Dataene som vises i webapplikasjonen skal samsvare med dataene som er lagret i databasen.

For å utføre databasetestingen, bør testeren være klar over punktene nedenfor:

  • Testeren bør forstå funksjonelle krav, forretningslogikk, applikasjonsflyt og databasedesign grundig.
  • Testeren bør finne ut tabeller, utløsere, lagringsprosedyrer, visninger og markører som brukes for applikasjonen.
  • Testeren bør forstå logikken til utløsere, lagringsprosedyrer, visninger og markører som er opprettet.
  • Testeren bør finne ut hvilke tabeller som blir påvirket når innsettingsoppdatering og sletting (DML)-operasjoner utføres gjennom web- eller skrivebordsapplikasjoner.

Ved hjelp av de ovennevnte punktene kan testeren enkelt skrive testscenarioene for databasetesting.

Eksempel på testtilfeller for databasetesting:

  • Bekreft databasenavnet: Databasenavnet må samsvare med spesifikasjonene.
  • Bekreft tabeller, kolonner, kolonnetyper og standardinnstillinger: Alle ting skal samsvare med spesifikasjonene.
  • Bekreft om kolonnen tillater en null eller ikke.
  • Bekreft primær- og fremmednøkkelen til hver tabell.
  • Bekreft den lagrede prosedyren:
  • Test om Lagret prosedyre er installert eller ikke.
  • Bekreft navnet på den lagrede prosedyren
  • Bekreft parameternavnene, typene og antall parametere.
  • Test parametrene om de er nødvendige eller ikke.
  • Test den lagrede prosedyren ved å slette noen parametere
  • Test når utgangen er null, nullpostene skal påvirkes.
  • Test den lagrede prosedyren ved å skrive enkelt SQL spørringer.
  • Test om den lagrede prosedyren returnerer verdiene
  • Test den lagrede prosedyren med eksempelinndata.
  • Bekreft oppførselen til hvert flagg i tabellen.
  • Kontroller at dataene blir lagret riktig i databasen etter hver sideinnsending.
  • Bekreft dataene hvis DML-operasjonene (Oppdater, slett og sett inn) utføres.
  • Sjekk lengden på hvert felt: Feltlengden i bakenden og frontenden må være lik.
  • Bekreft databasenavnene til QA, UAT og produksjon. Navnene skal være unike.
  • Bekreft de krypterte dataene i databasen.
  • Bekreft databasestørrelsen. Test også responstiden for hvert utførte spørring.
  • Bekreft dataene som vises på forsiden, og sørg for at de er like i bakenden.
  • Bekreft dataens gyldighet ved å sette inn de ugyldige dataene i databasen.
  • Bekreft utløserne.

Sjekkliste for API-testing

De fleste forretningsregler ligger nå bak REST- eller GraphQL-endepunkter, så nettleserkontroller alene kan ikke bevise at systemet fungerer. Testing av endepunkter avslører direkte svindel.tract- og autorisasjonsfeil mye tidligere enn brukergrensesnittet kan.

Dekk følgende scenarier før et endepunkt signeres:

Eksempel på testscenarioer for API-testing:

  • Bekreft dokumenterte statuskoder for suksess, valideringsfeil, uautorisert tilgang og serverfeil.
  • Bekreft at svarnyttelasten samsvarer med det publiserte skjemaet, inkludert feltnavn og datatyper.
  • Verifisering av manglende eller feilformede parametere returnerer en lesbar melding i stedet for en stakk trace.
  • Bekreft at autentiseringstokener utløper, oppdateres riktig og ikke kan spilles av på nytt etter utlogging.
  • Bekreft rollebasert autorisasjon, slik at en standardkonto ikke kan nå administratorens endepunkter ved å endre en identifikator.
  • Bekreft grenseverdier på hver parameter, inkludert tomme strenger og maksimale lengder.
  • Bekreft at hastighetsbegrensning returnerer riktig reguleringsrespons i stedet for å feile stille.
  • Bekreft at endepunktet degraderes sakte når en tredjepartstjeneste tidsavbrytes.
  • Kontroller at det ikke vises passord, tokener eller interne stier i svar eller feilmeldinger.

Kjør denne listen i alle miljøer, siden oppsetning og produksjon ofte eksponerer forskjellige tillatelsessett. Se API-testing oversikt og teste et REST API manuelt.

Flere av disse kontrollene overlapper med sikkerhetsarbeid.

Sikkerhetstesting

Sikkerhetstesting involverer testen for å identifisere eventuelle feil og hull fra et sikkerhetssynspunkt.

Eksempel på testscenarier for sikkerhetstesting:

  • Bekreft at nettsiden som inneholder viktige data som passord, kredittkortnumre, hemmelige svar på sikkerhetsspørsmål osv. sendes via HTTPS (SSL).
  • Kontroller at viktig informasjon som passord, kredittkortnumre osv. skal vises i kryptert format.
  • Kontroller at passordregler er implementert på alle autentiseringssider som registrering, glemt passord, endre passord.
  • Kontroller at om passordet er endret, skal brukeren ikke kunne logge på med det gamle passordet.
  • Kontroller at feilmeldingene ikke skal vise viktig informasjon.
  • Bekreft om brukeren er logget av systemet eller brukerøkten var utløpt, brukeren skal ikke kunne navigere på nettstedet.
  • Bekreft for å få tilgang til sikre og ikke-sikrede nettsider direkte uten pålogging.
  • Kontroller at "Se kildekode"-alternativet er deaktivert og ikke skal være synlig for brukeren.
  • Bekreft at brukerkontoen blir låst ute hvis brukeren skriver inn feil passord flere ganger.
  • Kontroller at informasjonskapslene ikke skal lagre passord.
  • Kontroller at om noen funksjonalitet ikke fungerer, skal systemet ikke vise noen applikasjons-, server- eller databaseinformasjon. I stedet skal den vise den egendefinerte feilsiden.
  • Bekreft SQL-injeksjonsangrepene.
  • Bekreft brukerrollene og deres rettigheter. For eksempel skal rekvirenten ikke ha tilgang til admin-siden.
  • Bekreft at viktige operasjoner er skrevet i loggfiler, og at informasjonen skal tracmulig.
  • Kontroller at øktverdiene er i et kryptert format i adressefeltet.
  • Kontroller at informasjonskapselinformasjonen er lagret i kryptert format.
  • Bekreft søknaden om Brute Force Attacks

En herdet applikasjon som bukker seg under belastning er fortsatt ubrukelig, så neste passering måler skala.

Ytelsestesting

Ytelsestesting utføres for å evaluere samsvaret til et system eller en komponent med spesifiserte ytelseskrav.

Generelle testscenarier:

  • For å bestemme ytelsen, stabiliteten og skalerbarheten til en applikasjon under forskjellige belastningsforhold.
  • For å finne ut om den nåværende arkitekturen kan støtte applikasjonen på topp brukernivåer.
  • For å bestemme hvilken konfigurasjonsstørrelse som gir det beste ytelsesnivået.
  • For å identifisere applikasjons- og infrastrukturflaskehalser.
  • For å finne ut om den nye versjonen av programvaren hadde negativ innvirkning på responstiden.
  • For å evaluere produkt og/eller maskinvare for å finne ut om det kan håndtere projiserte lastvolumer.

Hvordan gjøre ytelsestesting? Ved manuell testing eller ved automatisering

Det er praktisk talt ikke mulig å utføre ytelsestesten manuelt på grunn av noen ulemper som:

  • Flere ressurser vil være nødvendig.
  • Samtidige handlinger er ikke mulig.
  • Riktig systemovervåking er ikke tilgjengelig.
  • Ikke lett å utføre den repeterende oppgaven.

Derfor bør vi bruke ytelsestestverktøyet for å overvinne problemene ovenfor. Nedenfor er listen over noen populære testverktøy.

Én målgruppe mangler fortsatt: brukere som når disse skjermene via hjelpeteknologi.

Sjekkliste for tilgjengelighetstesting

Tilgjengelighetstesting bekrefter at personer som bruker skjermlesere, navigasjon med bare tastatur eller forstørrelse kan gjennomføre de samme reisene som alle andre. Det er også et anskaffelseskrav, siden bedrifter kantracts refererer vanligvis til WCAG 2.2 nivå AADisse feilene er strukturelle og koster mye mindre å utbedre tidlig.

Eksempel på testscenarioer for tilgjengelighetstesting:

  • Bekreft at meningsfulle bilder har beskrivende alt-tekst og at dekorative bilder er skjult fra hjelpeteknologi.
  • Kontroller at alle skjemakontroller har en programmatisk tilknyttet etikett, ikke bare tilstøtende plassholdertekst.
  • Bekreft at siden fungerer bare med tastaturet, med en synlig fokusindikator ved hvert stopp.
  • Bekreft at tekst og interaktive elementer oppfyller minimumskontrastforholdet mot bakgrunnen.
  • Bekreft at overskriftene følger en logisk rekkefølge uten å hoppe over nivåer, slik at skjermlesernavigasjonen fungerer.
  • Kontroller at feilmeldinger varsles til hjelpeteknologien og identifiser feltet som er feil.
  • Bekreft at siden fortsatt er brukbar med 200 prosent zoom uten horisontal rulling.
  • Bekreft at tilpassede widgeter som modaler, faner og trekkspill eksponerer riktige roller og tilstander.

Automatiserte skannere fanger bare opp deler av disse problemene, så legg til et manuelt tastatur- og skjermleserpassord. tilgjengelighetstesting Referansen dekker verktøyet.

Spørsmål og svar

En testplan er et formelt dokument som dekker omfang, tidsplan, ressurser, risiko og avslutningskriterier for en utgivelse. En sjekkliste er en enkel påminnelse om dekning som viser betingelsene som skal verifiseres. Planen styrer prosjektet, mens sjekklisten styrer den enkelte testøkten.

Revse den etter hver større utgivelse, ny integrasjon eller produksjonshendelse. Hver unnslippet feil bør legge til én linje slik at den samme feilen ikke kan gjenta seg. En sjekkliste som aldri revideres raskt, slutter å gjenspeile hvordan applikasjonen faktisk oppfører seg.

De fleste lag forankrer sikkerhetsdekning til OWASP-veiledning for testing av nettsikkerhet, tilgjengelighet til WCAG 2.2, og generell prosessterminologi til ISTQB. Disse referansene gjør en sjekkliste reviderbar i stedet for utelukkende basert på teamvaner.

Ja. Å mate krav, brukerhistorier eller API-spesifikasjoner inn i en stor språkmodell gir et solid førsteutkast av scenarier. En tester må fortsatt fjerne duplikater, legge til forretningsregler som modellen ikke kan utlede, og bekrefte at hvert element er genuint verifiserbart.

Selvreparerende lokaliseringsverktøy identifiserer elementer på nytt etter endringer i markup, og fjerner dermed de ustabile feilene som dominerer vedlikeholdsarbeidet. AI grupperer også dupliserte feil og rangerer hvilke pakker som skal kjøres først, slik at regresjonssyklusene forblir korte etter hvert som sjekklisten vokser.

Oppsummer dette innlegget med: