Testcases voorbeeld voor webapplicatie (checklist)

Door: Thomas Hamilton Thomas Hamilton
Hours Bijgewerkt

⚡ Slimme samenvatting

De complete checklist voor het testen van webapplicaties omvat controles op bruikbaarheid, functionaliteit, compatibiliteit, database, API, beveiliging, prestaties en toegankelijkheid. Elk onderdeel hieronder biedt kant-en-klare testscenario's die kwaliteitsborgingsteams direct kunnen kopiëren naar een testmanagementtool.

  • ⚙️ Functionaliteit voorop: Controleer verplichte velden, grenslengtes, schrikjaren, delen door nul en time-outgedrag voordat de cosmetische controle begint.
  • 🧭 Gebruiksvriendelijkheidssignalen: Controleer de uitlijning, tooltips, toetsenbordtoegang, schuifbalken en het herstelproces bij foutmeldingen, zodat een nieuwe gebruiker nooit vast komt te zitten.
  • 🌐 Compatibiliteitsmatrix: Herhaal kritieke workflows in Chrome. FirefoxEdge, Safari en mobiele browsers worden gebruikt om verschillen in lay-out en scripts aan het licht te brengen.
  • ️ Integriteit van de database: Vergelijk de front-endwaarden met de opgeslagen records en controleer sleutels, triggers, opgeslagen procedures en veldlengtes op beide lagen.
  • ???? API-laag: Stel statuscodes, schema's, authenticatie, snelheidslimieten en foutafhandeling in de vervolgprocessen los van de browser in.
  • 🔐 Beveiligingsbasislijn: Dwing HTTPS af, versleutel opgeslagen geheimen, blokkeer accounts na herhaalde fouten en controleer op SQL-injectie en brute force-aanvallen.
  • 🚀 Prestaties en toegang: Laad profielen automatisch in in plaats van handmatig, en controleer vervolgens het WCAG-contrast, de labels en de toetsenbordbediening.
Meer informatie

Bij het testen van de webapplicaties moet rekening worden gehouden met het onderstaande sjabloon. De onderstaande checklist is vrijwel toepasbaar voor alle soorten webapplicaties, afhankelijk van de zakelijke vereisten.

Bovenstaand sjabloon laat zien hoe één pagina scenario's voor elk onderdeel van de checklist kan bevatten. Zie voor meer achtergrondinformatie de testen van webapplicaties Overzicht.

Laten we nu elke checklist in detail bekijken:

Functioneel testen

Wat is functioneel testen?

  • Het testen van de functies en het operationele gedrag van een product om er zeker van te zijn dat ze voldoen aan de specificaties.
  • Testen waarbij het interne mechanisme van een systeem of component wordt genegeerd en uitsluitend wordt gefocust op de outputs die worden gegenereerd als reactie op geselecteerde inputs en uitvoeringsomstandigheden.

Wat is het doel of doel van functioneel testen?

  • Doel van Functioneel testen is om te verifiëren of uw product voldoet aan de beoogde functionele specificaties zoals vermeld in uw ontwikkelingsdocumentatie.

Voorbeeld functionele testscenario's:

  • Test alle verplichte velden moeten worden gevalideerd.
  • Test of het sterretje voor alle verplichte velden moet worden weergegeven.
  • Test het systeem zou het foutbericht voor optionele velden niet moeten weergeven.
  • Test of schrikkeljaren correct zijn gevalideerd en geen fouten/misrekeningen veroorzaken.
  • Test of de numerieke velden de alfabetten niet accepteren en de juiste foutmelding zou moeten verschijnen.
  • Test op negatieve getallen indien toegestaan ​​voor numerieke velden.
  • Testdeling door nul moet op de juiste manier worden gehanteerd voor berekeningen.
  • Test de maximale lengte van elk veld om er zeker van te zijn dat de gegevens niet worden afgekapt.
  • Test het pop-upbericht (“Dit veld is beperkt tot 500 tekens”) dat moet worden weergegeven als de gegevens de maximale grootte van het veld bereiken.
  • Test of er een bevestigingsbericht wordt weergegeven voor update- en verwijderbewerkingen.
  • Test of de bedragwaarden in valutaformaat moeten worden weergegeven.
  • Test alle invoervelden op speciale tekens.
  • Test de time-outfunctionaliteit.
  • Test de sorteerfunctionaliteit.
  • Test de functionaliteit van de beschikbare knoppen
  • Test het privacybeleid en de veelgestelde vragen zijn duidelijk gedefinieerd en moeten beschikbaar zijn voor gebruikers.
  • Test of een functionaliteit mislukt. De gebruiker wordt doorgestuurd naar de aangepaste foutpagina.
  • Test of alle geüploade documenten correct zijn geopend.
  • Test of de gebruiker de geüploade bestanden moet kunnen downloaden.
  • Test de e-mailfunctionaliteit van het systeem.
  • Test de Java script werkt goed in verschillende browsers (IE, Firefox, Chroom, safari en Opera).
  • Test om te zien wat er gebeurt als een gebruiker cookies verwijdert terwijl hij op de site is.
  • Test om te zien wat er gebeurt als een gebruiker cookies verwijdert na een bezoek aan een site.
  • Controleer of alle gegevens in de keuzelijst/combo in chronologische volgorde zijn gerangschikt.

Als de functies eenmaal correct werken, is de volgende vraag of echte gebruikers ze zonder hulp kunnen bedienen.

Usability Testing

Wat is bruikbaarheidstesten?

  • Bruikbaarheidstesten zijn niets anders dan de controle van de gebruiksvriendelijkheid.
  • Bij gebruiksvriendelijkheidstesten wordt de applicatieflow getest, zodat een nieuwe gebruiker de applicatie gemakkelijk kan begrijpen.
  • Kortom, de systeemnavigatie wordt gecontroleerd tijdens bruikbaarheidstesten.

Wat is het doel of doel van bruikbaarheidstesten?

Een bruikbaarheidstest stelt het gebruiksgemak en de effectiviteit van een product vast met behulp van standaard bruikbaarheidstestpraktijken.

Voorbeelden van bruikbaarheidstestgevallen

  • De inhoud van webpagina's moet correct zijn, zonder enige spel- of grammaticafouten
  • Alle lettertypen moeten hetzelfde zijn als volgens de vereisten.
  • Alle tekst moet correct worden uitgelijnd.
  • Alle foutmeldingen moeten correct zijn, zonder spel- of grammaticafouten, en de foutmelding moet overeenkomen met het veldlabel.
  • Tooltiptekst moet voor elk veld aanwezig zijn.
  • Alle velden moeten goed uitgelijnd zijn.
  • Er moet voldoende ruimte zijn tussen veldlabels, kolommen, rijen en foutmeldingen.
  • Alle knoppen moeten een standaardformaat en -formaat hebben.
  • De startlink moet op elke pagina aanwezig zijn.
  • Uitgeschakelde velden moeten grijs zijn.
  • Controleer op verbroken links en afbeeldingen.
  • Er moet een bevestigingsbericht worden weergegeven voor elke update- of verwijderbewerking.
  • Controleer de site op verschillende resoluties (640 x 480, 600×800 etc.?)
  • Controleer of de eindgebruiker het systeem zonder frustratie kan gebruiken.
  • Controleer of het tabblad goed zou moeten werken.
  • De schuifbalk zou alleen moeten verschijnen als dat nodig is.
  • Als er een foutmelding verschijnt bij het indienen, zou de door de gebruiker ingevulde informatie daar moeten zijn.
  • De titel moet op elke webpagina worden weergegeven
  • Alle velden (tekstvakken, vervolgkeuzelijsten, keuzerondjes, enz.) en knoppen moeten toegankelijk zijn via sneltoetsen en de gebruiker moet alle handelingen via het toetsenbord kunnen uitvoeren.
  • Controleer of de vervolgkeuzelijstgegevens niet zijn afgekapt vanwege de veldgrootte. Controleer ook of de gegevens hardgecodeerd zijn of via de beheerder worden beheerd.

Een lay-out die in de ene browser goed wordt weergegeven, kan in een andere browser problemen geven. Zorg er daarom voor dat dezelfde schermen in alle ondersteunde omgevingen correct worden weergegeven.

GERELATEERDE ARTIKELEN

Compatibiliteitstesten

Wat is compatibiliteitstesten?

  • Compatibiliteitstesten worden gebruikt om te bepalen of uw software compatibel is met andere elementen van een systeem waarmee het zou moeten werken, bijvoorbeeld browsers, Operatingsystemen of hardware.

Wat is het doel van compatibiliteitstesten?

  • Het doel van compatibiliteitstests is om te evalueren hoe goed software presteert in een bepaalde browser, Operatingsystemen, hardware of software.

Voorbeeldcompatibiliteitstestscenario's:

  • Test de website in verschillende browsers (IE, Firefox, Chroom, Safari en Opera) en zorg ervoor dat de website correct wordt weergegeven.
  • Test of de gebruikte HTML-versie compatibel is met de juiste browserversies.
  • Test of de afbeeldingen correct worden weergegeven in verschillende browsers.
  • Test of de lettertypen bruikbaar zijn in verschillende browsers.
  • Test of de Java-scriptcode bruikbaar is in verschillende browsers.
  • Test de geanimeerde GIF's in verschillende browsers.

Een consistente weergave zegt niets over de gegevens achter het scherm. cross-browser testen Matrix zorgt ervoor dat dit gebied beheersbaar blijft.

Databasetesten

Wat is databasetesten?

  • In Database testen backend-records worden getest die via internet of desktopapplicaties zijn ingevoegd. De gegevens die in de webapplicatie worden weergegeven, moeten overeenkomen met de gegevens die zijn opgeslagen in de database.

Om de databasetest uit te voeren, moet de tester op de hoogte zijn van de onderstaande punten:

  • De tester moet de functionele vereisten, bedrijfslogica, applicatiestroom en databaseontwerp grondig begrijpen.
  • De tester moet uitzoeken welke tabellen, triggers, opslagprocedures, weergaven en cursors voor de toepassing worden gebruikt.
  • De tester moet de logica begrijpen van de gecreëerde triggers, opslagprocedures, weergaven en cursors.
  • De tester moet achterhalen welke tabellen worden beïnvloed wanneer DML-bewerkingen (insert, update en delete) worden uitgevoerd via de web- of desktoptoepassingen.

Met behulp van bovenstaande punten kan de tester eenvoudig de testscenario’s voor Database testen schrijven.

Voorbeeldtestgevallen voor het testen van databases:

  • Controleer de databasenaam: De databasenaam moet overeenkomen met de specificaties.
  • Controleer de tabellen, kolommen, kolomtypen en standaardwaarden: alles moet overeenkomen met de specificaties.
  • Controleer of de kolom een ​​nul toestaat of niet.
  • Controleer de primaire en externe sleutel van elke tabel.
  • Controleer de opgeslagen procedure:
  • Test of de opgeslagen procedure is geïnstalleerd of niet.
  • Controleer de naam van de opgeslagen procedure
  • Controleer de parameternamen, typen en aantal parameters.
  • Test de parameters of ze vereist zijn of niet.
  • Test de opgeslagen procedure door enkele parameters te verwijderen
  • Test wanneer de uitvoer nul is, de nulrecords moeten worden beïnvloed.
  • Test de opgeslagen procedure door eenvoudig te schrijven SQL queries.
  • Test of de opgeslagen procedure de waarden retourneert
  • Test de opgeslagen procedure met voorbeeldinvoergegevens.
  • Controleer het gedrag van elke vlag in de tabel.
  • Controleer of de gegevens na elke pagina-inzending correct in de database worden opgeslagen.
  • Controleer de gegevens als de DML-bewerkingen (bijwerken, verwijderen en invoegen) worden uitgevoerd.
  • Controleer de lengte van elk veld: De veldlengte in de backend en frontend moet hetzelfde zijn.
  • Controleer de databasenamen van QA, UAT en productie. De namen moeten uniek zijn.
  • Controleer de gecodeerde gegevens in de database.
  • Controleer de databasegrootte. Test ook de responstijd van elke uitgevoerde query.
  • Controleer of de gegevens die aan de voorkant worden weergegeven, overeenkomen met de gegevens aan de achterkant.
  • Controleer de geldigheid van de gegevens door de ongeldige gegevens in de database in te voegen.
  • Controleer de triggers.

Checklist voor API-testen

De meeste bedrijfsregels bevinden zich tegenwoordig achter REST- of GraphQL-endpoints, waardoor browsercontroles alleen niet meer bewijzen dat het systeem werkt. Het rechtstreeks testen van endpoints legt kwetsbaarheden bloot.tract en autorisatiefouten veel eerder dan de gebruikersinterface dat kan.

Doorloop de volgende scenario's voordat een eindpunt wordt goedgekeurd:

Voorbeelden van testscenario's voor API-testen:

  • Controleer de gedocumenteerde statuscodes voor succes, validatiefout, ongeautoriseerde toegang en serverfout.
  • Controleer of de responspayload overeenkomt met het gepubliceerde schema, inclusief veldnamen en gegevenstypen.
  • Controleer of ontbrekende of onjuist geformuleerde parameters een leesbaar bericht retourneren in plaats van een stapelfout. trace.
  • Controleer of de authenticatietokens verlopen, correct worden vernieuwd en niet opnieuw kunnen worden gebruikt na het uitloggen.
  • Controleer of de autorisatie op basis van rollen werkt, zodat een standaardaccount geen toegang krijgt tot beheerdersinterfaces door een identificatiecode te wijzigen.
  • Controleer de grenswaarden voor elke parameter, inclusief lege tekenreeksen en maximale lengtes.
  • Controleer of de snelheidsbeperking de juiste reactie geeft in plaats van stilzwijgend te falen.
  • Controleer of het eindpunt op een gecontroleerde manier terugvalt wanneer een service van een derde partij een time-out bereikt.
  • Controleer of er geen wachtwoorden, tokens of interne paden voorkomen in reacties of foutmeldingen.

Voer deze lijst in elke omgeving uit, aangezien staging- en productieomgevingen vaak verschillende machtigingensets hanteren. Zie de API-testen overzicht en Een REST API handmatig testen.

Een aantal van die controles overlapt met beveiligingswerkzaamheden.

Beveiligingstests

Beveiligingstests omvat de test om eventuele gebreken en hiaten vanuit veiligheidsoogpunt te identificeren.

Voorbeeldtestscenario's voor beveiligingstests:

  • Controleer of de webpagina met belangrijke gegevens zoals wachtwoorden, creditcardnummers, geheime antwoorden op beveiligingsvragen etc. via HTTPS (SSL) moet worden verzonden.
  • Controleer of belangrijke informatie, zoals wachtwoorden, creditcardnummers etc., in gecodeerde vorm worden weergegeven.
  • Controleer of de wachtwoordregels zijn geïmplementeerd op alle authenticatiepagina's, zoals Registratie, wachtwoord vergeten, wachtwoord wijzigen.
  • Controleer of het wachtwoord is gewijzigd. De gebruiker zou niet moeten kunnen inloggen met het oude wachtwoord.
  • Controleer of de foutmeldingen geen belangrijke informatie mogen weergeven.
  • Controleer of de gebruiker is afgemeld bij het systeem of dat de gebruikerssessie is verlopen. De gebruiker zou niet door de site moeten kunnen navigeren.
  • Verifieer om rechtstreeks toegang te krijgen tot de beveiligde en niet-beveiligde webpagina's zonder in te loggen.
  • Controleer of de optie “Broncode bekijken” is uitgeschakeld en niet zichtbaar mag zijn voor de gebruiker.
  • Controleer of het gebruikersaccount wordt geblokkeerd als de gebruiker meerdere keren het verkeerde wachtwoord invoert.
  • Controleer of de cookies geen wachtwoorden mogen opslaan.
  • Controleer of een functionaliteit niet werkt; het systeem mag geen applicatie-, server- of database-informatie weergeven. In plaats daarvan zou de aangepaste foutpagina moeten worden weergegeven.
  • Controleer de SQL-injectieaanvallen.
  • Controleer de gebruikersrollen en hun rechten. De aanvrager mag bijvoorbeeld geen toegang hebben tot de beheerderspagina.
  • Controleer of de belangrijke bewerkingen in logbestanden worden vastgelegd en of die informatie aanwezig is. traceetbaar.
  • Controleer of de sessiewaarden gecodeerd zijn in de adresbalk.
  • Controleer of de cookie-informatie in gecodeerd formaat is opgeslagen.
  • Controleer de aanvraag voor Brute Force-aanvallen

Een geharde constructie die onder belasting doorbuigt, is nog steeds onbruikbaar, dus bij de volgende meting wordt de schaal aangepast.

Performance Testing

Performance Testing wordt uitgevoerd om de conformiteit van een systeem of component met gespecificeerde prestatie-eisen te evalueren.

Algemene testscenario's:

  • Om de prestaties, stabiliteit en schaalbaarheid van een applicatie onder verschillende belastingsomstandigheden te bepalen.
  • Om te bepalen of de huidige architectuur de applicatie op piekgebruikersniveaus kan ondersteunen.
  • Om te bepalen welke configuratiegrootte het beste prestatieniveau biedt.
  • Om knelpunten in applicaties en infrastructuur te identificeren.
  • Om te bepalen of de nieuwe versie van de software een nadelige invloed heeft gehad op de responstijd.
  • Om het product en/of de hardware te evalueren om te bepalen of het de verwachte belastingsvolumes aankan.

Hoe prestatietesten uitvoeren? Door handmatig testen of door automatisering

In de praktijk is het niet mogelijk om de prestatietests handmatig uit te voeren vanwege een aantal nadelen, zoals:

  • Er zullen meer middelen nodig zijn.
  • Gelijktijdige acties zijn niet mogelijk.
  • Goede systeemmonitoring is niet beschikbaar.
  • Het is niet eenvoudig om de repetitieve taak uit te voeren.

Om de bovenstaande problemen te overwinnen, moeten we daarom de Performance Testing-tool gebruiken. Hieronder vindt u een lijst met enkele populaire testtools.

Eén doelgroep ontbreekt nog: gebruikers die deze schermen bereiken met behulp van ondersteunende technologie.

Checklist voor toegankelijkheidstesten

Toegankelijkheidstesten bevestigen dat mensen die gebruikmaken van schermlezers, toetsenbordnavigatie of vergroting dezelfde processen kunnen doorlopen als alle anderen. Het is tevens een inkoopvereiste, aangezien bedrijventracts verwijst vaak naar WCAG 2.2 Niveau AADeze gebreken zijn structureel en het is veel goedkoper om ze vroegtijdig te verhelpen.

Voorbeelden van testscenario's voor toegankelijkheidstesten:

  • Controleer of betekenisvolle afbeeldingen beschrijvende alt-tekst hebben en of decoratieve afbeeldingen verborgen zijn voor ondersteunende technologie.
  • Controleer of elk formulierbesturingselement een programmatisch gekoppeld label heeft, en niet alleen naastgelegen placeholdertekst.
  • Controleer of de pagina werkt met alleen het toetsenbord, waarbij bij elke stop een zichtbare focusindicator verschijnt.
  • Controleer of tekst en interactieve elementen voldoen aan de minimale contrastverhouding ten opzichte van de achtergrond.
  • Controleer of de kopjes een logische volgorde hebben zonder niveaus over te slaan, zodat de navigatie voor schermlezers werkt.
  • Controleer of foutmeldingen worden voorgelezen aan ondersteunende technologie en identificeer het veld waar de fout optreedt.
  • Controleer of de pagina bruikbaar blijft bij 200 procent zoom zonder horizontaal te scrollen.
  • Controleer of aangepaste widgets zoals modals, tabs en accordions de juiste rollen en statussen weergeven.

Geautomatiseerde scanners detecteren slechts een deel van deze problemen, dus voeg een handmatige controle met toetsenbord en schermlezer toe. toegankelijkheidstesten De referentie heeft betrekking op het gereedschap.

Veelgestelde vragen

Een testplan is een formeel document waarin de reikwijdte, planning, benodigde middelen, risico's en exitcriteria voor een release worden beschreven. Een checklist is een beknopt overzicht van de te controleren voorwaarden. Het plan is leidend voor het project; de checklist is leidend voor de individuele testsessie.

RevBekijk de checklist na elke belangrijke release, nieuwe integratie of incident in de productieomgeving. Voeg voor elk opgelost defect een regel toe, zodat dezelfde fout zich niet kan herhalen. Een checklist die nooit wordt herzien, weerspiegelt al snel niet meer hoe de applicatie zich daadwerkelijk gedraagt.

De meeste teams baseren hun beveiligingsdekking op de OWASP-gids voor het testen van webbeveiliging, toegankelijkheid tot WCAG 2.2 en algemene procesterminologie volgens ISTQB. Deze referenties zorgen ervoor dat een checklist controleerbaar blijft in plaats van puur gebaseerd te zijn op teamgewoonten.

Ja. Het invoeren van vereisten, gebruikersverhalen of API-specificaties in een groot taalmodel levert een solide eerste versie van scenario's op. Een tester moet echter nog steeds duplicaten verwijderen, bedrijfsregels toevoegen die het model niet kan afleiden en controleren of elk item daadwerkelijk verifieerbaar is.

Zelfherstellende locators identificeren elementen opnieuw na wijzigingen in de markering, waardoor de onbetrouwbare fouten die het onderhoud domineren, worden verminderd. AI groepeert ook dubbele defecten en rangschikt welke suites als eerste moeten worden uitgevoerd, zodat regressiecycli kort blijven naarmate de checklist groeit.

Vat dit bericht samen met: