Eksempel på testsager for webapplikation (tjekliste)

Af: Thomas Hamilton Thomas Hamilton
Hours Opdateret

⚡ Smart opsummering

En komplet tjekliste til test af webapplikationer dækker brugervenlighed, funktionalitet, kompatibilitet, database, API, sikkerhed, ydeevne og tilgængelighedstjek. Hvert afsnit nedenfor indeholder brugsklare testscenarier, som kvalitetssikringsteams kan kopiere direkte ind i et teststyringsværktøj.

  • 🇧🇷 Funktionel først: Valider obligatoriske felter, grænselængder, skudår, division med nul og timeout-adfærd, før en kosmetisk gennemgang påbegyndes.
  • 🧭 Brugervenlighedssignaler: Kontroller justering, værktøjstip, tastaturadgang, rullepaneler og gendannelse af fejlmeddelelser, så en førstegangsbruger aldrig sidder fast.
  • 🌐 Kompatibilitetsmatrix: Gentag kritiske flows i Chrome, Firefox, Edge, Safari og mobilbrowsere for at afdække layout- og scriptforskelle.
  • 🗄️ Databaseintegritet: Match frontend-værdier med gemte poster, verificer nøgler, triggere, gemte procedurer og feltlængder på begge lag.
  • 🔌 API-lag: Angiv statuskoder, skemaer, godkendelse, hastighedsgrænser og håndtering af downstream-fejl separat fra browseren.
  • 🔐 Sikkerhedsgrundlag: Gennemtving HTTPS, krypter gemte hemmeligheder, lås konti efter gentagne fejl, og undersøg for SQL-injektion og brute force.
  • 🚀 Ydeevne og adgang: Indlæs profiler i scripts med automatisering i stedet for manuel indsats, og bekræft derefter WCAG-kontrast, etiketter og tastaturbetjening.
Læs mere

Mens man tester webapplikationerne, bør man overveje nedenstående skabelon. Nedenstående tjekliste er næsten anvendelig for alle typer webapplikationer afhængigt af forretningskravene.

Skabelonen ovenfor viser, hvordan ét ark kan indeholde scenarier for hvert tjeklisteområde. For baggrund, se test af webapplikationer oversigt.

Lad os nu se nærmere på hver tjekliste:

Funktionstest

Hvad er funktionel test?

  • Test af et produkts egenskaber og funktionsadfærd for at sikre, at de svarer til dets specifikationer.
  • Test, der ignorerer den interne mekanisme i et system eller en komponent og udelukkende fokuserer på de output, der genereres som svar på udvalgte input og udførelsesbetingelser.

Hvad er formålet eller målet med funktionstest?

  • Målet Funktionstest er at verificere, om dit produkt opfylder de tilsigtede funktionelle specifikationer, der er nævnt i din udviklingsdokumentation.

Eksempler på funktionelle testscenarier:

  • Test alle de obligatoriske felter skal valideres.
  • Test stjernetegnet skal vises for alle de obligatoriske felter.
  • Test systemet bør ikke vise fejlmeddelelsen for valgfrie felter.
  • Test at skudår er valideret korrekt og ikke forårsager fejl/fejlberegninger.
  • Test de numeriske felter bør ikke acceptere alfabeterne, og den korrekte fejlmeddelelse skal vises.
  • Test for negative tal, hvis det er tilladt for numeriske felter.
  • Testdeling med nul skal håndteres korrekt til beregninger.
  • Test den maksimale længde af hvert felt for at sikre, at dataene ikke er afkortet.
  • Test pop op-meddelelsen ("Dette felt er begrænset til 500 tegn") skal vises, hvis dataene når feltets maksimale størrelse.
  • Test, at en bekræftelsesmeddelelse skal vises for opdatering og sletning.
  • Test beløbsværdierne skal vises i valutaformat.
  • Test alle inputfelter for specialtegn.
  • Test timeout-funktionen.
  • Test sorteringsfunktionaliteten.
  • Test funktionaliteten af ​​de tilgængelige knapper
  • Test privatlivspolitikken og ofte stillede spørgsmål er klart defineret og bør være tilgængelige for brugere.
  • Test, hvis nogen funktionalitet fejler, bliver brugeren omdirigeret til den tilpassede fejlside.
  • Test, at alle de uploadede dokumenter er åbnet korrekt.
  • Test brugeren skal være i stand til at downloade de uploadede filer.
  • Test e-mail-funktionaliteten af ​​systemet.
  • Test Java script fungerer korrekt i forskellige browsere (IE, Firefox, Chrome, safari og Opera).
  • Test for at se, hvad der sker, hvis en bruger sletter cookies, mens han er på webstedet.
  • Test for at se, hvad der sker, hvis en bruger sletter cookies efter at have besøgt et websted.
  • Test alle data i kombinations-/listeboksen er arrangeret i kronologisk rækkefølge.

Når funktionerne fungerer korrekt, er det næste spørgsmål, om rigtige brugere kan betjene dem uden hjælp.

Usability Testing

Hvad er Usability Testing?

  • Usability test er intet andet end brugervenlighedskontrollen.
  • I brugervenlighedstestning testes applikationens flow, så en ny bruger nemt kan forstå applikationen.
  • Grundlæggende kontrolleres systemnavigation i Usability-test.

Hvad er formålet eller målet med Usability-testning?

En Usability-test fastslår brugervenligheden og effektiviteten af ​​et produkt ved hjælp af en standard Usability-testpraksis.

Eksempel Usability Test Cases

  • Websideindhold skal være korrekt uden stave- eller grammatiske fejl
  • Alle skrifttyper skal være de samme i henhold til kravene.
  • Al tekst skal være korrekt justeret.
  • Alle fejlmeddelelser skal være korrekte uden stave- eller grammatiske fejl, og fejlmeddelelsen skal stemme overens med feltetiketten.
  • Værktøjstiptekst skal være der for hvert felt.
  • Alle felter skal være korrekt justeret.
  • Der skal være tilstrækkelig plads mellem feltetiketter, kolonner, rækker og fejlmeddelelser.
  • Alle knapper skal være i standardformat og -størrelse.
  • Hjemlink skal være der på hver eneste side.
  • Deaktiverede felter skal være nedtonede.
  • Tjek for ødelagte links og billeder.
  • Bekræftelsesmeddelelsen skal vises for enhver form for opdatering og sletning.
  • Tjek siden på forskellige opløsninger (640 x 480, 600×800 osv.?)
  • Tjek, at slutbrugeren kan køre systemet uden frustration.
  • Kontroller, at fanen skal fungere korrekt.
  • Rullebjælken skal kun vises, hvis det er nødvendigt.
  • Hvis der er en fejlmeddelelse ved indsendelse, skal de oplysninger, som brugeren har udfyldt, være der.
  • Titlen skal vises på hver webside
  • Alle felter (tekstboks, dropdown, alternativknap osv.) og knapper skal være tilgængelige via tastaturgenveje, og brugeren skal kunne udføre alle handlinger ved at bruge tastaturet.
  • Tjek, om dropdown-dataene ikke er afkortet på grund af feltstørrelsen. Tjek også, om dataene er hårdkodede eller administreres via administrator.

Et layout, der læser godt i én browser, kan gå i stykker i en anden, så afspil de samme skærmbilleder på tværs af alle understøttede miljøer.

RELATEREDE ARTIKLER

Test af kompatibilitet

Hvad er kompatibilitetstest?

  • Kompatibilitetstest bruges til at afgøre, om din software er kompatibel med andre elementer i et system, som den skal fungere med, f.eks. browsere, Operating systemer eller hardware.

Hvad er formålet eller målet med kompatibilitetstestning?

  • Formålet med kompatibilitetstest er at evaluere, hvor godt software fungerer i en bestemt browser, Operating Systemer, hardware eller software.

Eksempel på kompatibilitetstestscenarier:

  • Test hjemmesiden i forskellige browsere (IE, Firefox, Chrome, Safari og Opera) og sørg for, at webstedet vises korrekt.
  • Test den HTML-version, der bruges, er kompatibel med passende browserversioner.
  • Test billederne, der vises korrekt i forskellige browsere.
  • Test skrifttyperne er brugbare i forskellige browsere.
  • Test java script-koden er brugbar i forskellige browsere.
  • Test de animerede GIF'er på tværs af forskellige browsere.

Konsekvent gengivelse beviser intet om optagelserne bag skærmen. test på tværs af browsere matrix holder dette område håndterbart.

Database test

Hvad er databasetestning?

  • In Database test Der testes backend-poster, som er blevet indsat via internettet eller desktop-applikationer. De data, der vises i webapplikationen, skal matche de data, der er gemt i databasen.

For at udføre databasetesten skal testeren være opmærksom på nedenstående punkter:

  • Testeren bør forstå de funktionelle krav, forretningslogik, applikationsflow og databasedesign grundigt.
  • Testeren skal finde ud af de tabeller, triggere, butiksprocedurer, visninger og markører, der bruges til applikationen.
  • Testeren bør forstå logikken i de oprettede triggere, butiksprocedurer, visninger og markører.
  • Testeren bør finde ud af de tabeller, der bliver påvirket, når indsæt opdatering og sletning (DML)-operationer udføres gennem web- eller desktopapplikationer.

Ved hjælp af ovennævnte punkter kan testeren nemt skrive testscenarier til databasetest.

Eksempler på testsager til databasetest:

  • Bekræft databasenavnet: Databasenavnet skal stemme overens med specifikationerne.
  • Bekræft tabellerne, kolonnerne, kolonnetyperne og standardindstillingerne: Alle ting skal stemme overens med specifikationerne.
  • Bekræft, om kolonnen tillader en null eller ej.
  • Bekræft den primære og fremmede nøgle for hver tabel.
  • Bekræft den lagrede procedure:
  • Test, om den lagrede procedure er installeret eller ej.
  • Bekræft navnet på den lagrede procedure
  • Bekræft parameternavne, typer og antal parametre.
  • Test parametrene, om de er nødvendige eller ej.
  • Test den lagrede procedure ved at slette nogle parametre
  • Test, når outputtet er nul, bør nulposterne blive påvirket.
  • Test den lagrede procedure ved at skrive enkelt SQL forespørgsler.
  • Test om den lagrede procedure returnerer værdierne
  • Test den lagrede procedure med eksempelinputdata.
  • Bekræft opførselen af ​​hvert flag i tabellen.
  • Bekræft, at dataene bliver korrekt gemt i databasen efter hver sideindsendelse.
  • Bekræft dataene, hvis DML-operationerne (Opdater, slet og indsæt) udføres.
  • Tjek længden af ​​hvert felt: Feltlængden i bagenden og forenden skal være den samme.
  • Bekræft databasenavnene på QA, UAT og produktion. Navnene skal være unikke.
  • Bekræft de krypterede data i databasen.
  • Bekræft databasestørrelsen. Test også responstiden for hver forespørgsel, der udføres.
  • Bekræft de data, der vises på forsiden, og sørg for, at de er de samme i bagenden.
  • Bekræft dataens gyldighed ved at indsætte de ugyldige data i databasen.
  • Bekræft triggerne.

API-testtjekliste

De fleste forretningsregler ligger nu bag REST- eller GraphQL-slutpunkter, så browsertjek alene kan ikke bevise, at systemet fungerer. Test af slutpunkter afslører direkte problemertract- og godkendelsesfejl langt tidligere end brugergrænsefladen kan.

Dæk følgende scenarier, før et slutpunkt godkendes:

Eksempel på testscenarier til API-testning:

  • Bekræft dokumenterede statuskoder for succes, valideringsfejl, uautoriseret adgang og serverfejl.
  • Bekræft, at svarets nyttelast matcher det publicerede skema, inklusive feltnavne og datatyper.
  • Bekræft manglende eller forkert udformede parametre returnerer en læsbar besked i stedet for en stak trace.
  • Bekræft, at godkendelsestokens udløber, opdateres korrekt og ikke kan afspilles igen efter logout.
  • Bekræft rollebaseret godkendelse, så en standardkonto ikke kan nå administratorens slutpunkter ved at ændre et identifikator.
  • Bekræft randværdier for hver parameter, inklusive tomme strenge og maksimale længder.
  • Bekræft, at hastighedsbegrænsning returnerer det korrekte throttling-svar i stedet for at fejle lydløst.
  • Bekræft, at slutpunktet nedbrydes korrekt, når en tredjepartstjeneste udløber.
  • Bekræft, at der ikke vises adgangskoder, tokens eller interne stier i svar eller fejlmeddelelser.

Kør denne liste i alle miljøer, da staging og produktion ofte eksponerer forskellige tilladelsessæt. Se API-test oversigt og manuel test af et REST API.

Flere af disse kontroller overlapper med sikkerhedsarbejde.

Sikkerhedstest

Sikkerhedstest involverer testen for at identificere eventuelle fejl og huller ud fra et sikkerhedssynspunkt.

Eksempel på testscenarier til sikkerhedstest:

  • Bekræft, at websiden, som indeholder vigtige data som adgangskode, kreditkortnumre, hemmelige svar på sikkerhedsspørgsmål osv. skal sendes via HTTPS (SSL).
  • Kontroller, at vigtige oplysninger som adgangskode, kreditkortnumre osv. skal vises i krypteret format.
  • Bekræft adgangskoderegler er implementeret på alle godkendelsessider som registrering, glemt adgangskode, skift adgangskode.
  • Kontroller, at hvis adgangskoden er ændret, skal brugeren ikke kunne logge på med den gamle adgangskode.
  • Kontroller, at fejlmeddelelserne ikke skal vise vigtige oplysninger.
  • Bekræft, om brugeren er logget ud af systemet eller brugersessionen var udløbet, brugeren skulle ikke være i stand til at navigere på webstedet.
  • Bekræft for at få adgang til de sikrede og ikke-sikrede websider direkte uden login.
  • Kontroller, at "Se kildekode"-indstillingen er deaktiveret og ikke bør være synlig for brugeren.
  • Bekræft, at brugerkontoen bliver låst ude, hvis brugeren indtaster den forkerte adgangskode flere gange.
  • Bekræft, at cookies ikke skal gemme adgangskoder.
  • Kontroller, at hvis en funktionalitet ikke virker, skal systemet ikke vise nogen applikations-, server- eller databaseinformation. I stedet skal den vise den tilpassede fejlside.
  • Bekræft SQL-injektionsangrebene.
  • Bekræft brugerrollerne og deres rettigheder. For eksempel bør anmoderen ikke være i stand til at få adgang til administratorsiden.
  • Bekræft, at de vigtige handlinger er skrevet i logfiler, og at disse oplysninger skal tracmulig.
  • Kontroller, at sessionsværdierne er i et krypteret format i adresselinjen.
  • Bekræft, at cookieoplysningerne er gemt i krypteret format.
  • Bekræft ansøgningen om Brute Force Attacks

En hærdet applikation, der bukker under belastning, er stadig ubrugelig, så den næste gennemgang måler skala.

Test af ydeevne

Test af ydeevne udføres for at evaluere et systems eller komponents overensstemmelse med specificerede ydeevnekrav.

Generelle testscenarier:

  • For at bestemme ydeevnen, stabiliteten og skalerbarheden af ​​en applikation under forskellige belastningsforhold.
  • For at afgøre, om den aktuelle arkitektur kan understøtte applikationen på højeste brugerniveau.
  • For at bestemme, hvilken konfigurationsstørrelse, der giver det bedste ydelsesniveau.
  • At identificere applikations- og infrastrukturflaskehalse.
  • For at afgøre, om den nye version af softwaren havde en negativ indvirkning på responstiden.
  • At evaluere produkt og/eller hardware for at afgøre, om det kan håndtere forventede belastningsmængder.

Hvordan laver man præstationstest? Ved manuel test eller ved automatisering

Det er praktisk talt ikke muligt at udføre ydelsestesten manuelt på grund af nogle ulemper som:

  • Der kræves flere ressourcer.
  • Samtidige handlinger er ikke mulige.
  • Korrekt systemovervågning er ikke tilgængelig.
  • Ikke let at udføre den gentagne opgave.

Derfor bør vi bruge værktøjet til præstationstest for at overvinde ovenstående problemer. Nedenfor er listen over nogle populære testværktøjer.

Én målgruppe mangler stadig: brugere, der når disse skærme via hjælpeteknologi.

Tjekliste til tilgængelighedstest

Tilgængelighedstest bekræfter, at personer, der bruger skærmlæsere, tastaturnavigation eller forstørrelse, kan gennemføre de samme rejser som alle andre. Det er også et indkøbskrav, da virksomheder kantracts refererer almindeligvis til WCAG 2.2 Niveau AADisse defekter er strukturelle og koster langt mindre at udbedre tidligt.

Eksempler på testscenarier for tilgængelighedstest:

  • Bekræft, at meningsfulde billeder indeholder beskrivende alt-tekst, og at dekorative billeder er skjult for hjælpeteknologi.
  • Bekræft, at alle formularkontrolelementer har en programmatisk tilknyttet etiket, ikke kun tilstødende pladsholdertekst.
  • Bekræft at siden fungerer udelukkende med tastaturet, med en synlig fokusindikator ved hvert stop.
  • Bekræft, at tekst og interaktive elementer overholder minimumskontrastforholdet i forhold til deres baggrund.
  • Bekræft, at overskrifter følger en logisk rækkefølge uden oversprungne niveauer, så skærmlæsernavigationen fungerer.
  • Bekræft, at fejlmeddelelser meddeles til hjælpeteknologien, og identificer det felt, der er fejlbehæftet.
  • Bekræft, at siden stadig kan bruges ved 200 procent zoom uden vandret rulning.
  • Bekræft, at brugerdefinerede widgets såsom modaler, faner og harmonikaer viser korrekte roller og tilstande.

Automatiserede scannere fanger kun en del af disse problemer, så tilføj et manuelt tastatur og en skærmlæser. tilgængelighedstest Referencen dækker værktøjet.

Ofte Stillede Spørgsmål

En testplan er et formelt dokument, der dækker omfang, tidsplan, ressourcer, risiko og exitkriterier for en release. En tjekliste er en let påmindelse om dækning, der angiver de betingelser, der skal verificeres. Planen styrer projektet; tjeklisten styrer den enkelte testsession.

RevSe den efter hver større udgivelse, ny integration eller produktionshændelse. Hver undsluppet fejl bør tilføje én linje, så den samme fejl ikke kan gentage sig. En tjekliste, der aldrig revideres hurtigt, holder op med at afspejle, hvordan applikationen rent faktisk opfører sig.

De fleste hold forankrer sikkerhedsdækningen til OWASP websikkerhedstestvejledning, adgang til WCAG 2.2 og den overordnede procesterminologi til ISTQB. Disse referencer gør en tjekliste auditerbar i stedet for udelukkende baseret på teamvaner.

Ja. At indføre krav, brugerhistorier eller API-specifikationer i en stor sprogmodel giver et solidt første udkast af scenarier. En tester skal stadig fjerne dubletter, tilføje forretningsregler, som modellen ikke kan udlede, og bekræfte, at hvert element virkelig er verificerbart.

Selvreparerende lokaliseringsværktøjer genidentificerer elementer efter ændringer i markup, hvilket fjerner de ustabile fejl, der dominerer vedligeholdelsesindsatsen. AI grupperer også duplikerede defekter og rangerer, hvilke pakker der skal køres først, så regressionscyklusser forbliver korte, efterhånden som tjeklisten vokser.

Opsummer dette indlæg med: