180+ voorbeeldtestcases voor het testen van webapplicaties (voorbeeldchecklist)

180 web application testing example test cases

Voorbeeldtestcases voor het testen van webapplicaties: dit is een complete testchecklist voor zowel webgebaseerde als desktoptoepassingen.

Dit is een zeer uitgebreide lijst van testcases / scenario's voor het testen van webapplicaties. Ons doel is om een ​​van de meest uitgebreide testchecklists ooit geschreven te delen en dit is nog niet gedaan.

We zullen dit bericht ook in de toekomst blijven updaten met meer testcases en scenario's. Als u nu geen tijd heeft om het te lezen, kunt u dit met uw vrienden delen en er een bladwijzer voor maken voor later.

Maak een testchecklist als integraal onderdeel van het schrijfproces van uw testcase. Met behulp van deze checklist kunt u gemakkelijk honderden Testgevallen voor het testen van web- of desktopapplicaties.

Dit zijn allemaal algemene testcases en zouden toepasbaar moeten zijn op bijna alle soorten toepassingen. Verwijs deze tests door terwijl u testcases voor uw project schrijft en ik weet zeker dat u de meeste van de typen testen behalve de toepassingsspecifieke bedrijfsregels die in uw SRS-documenten worden vermeld.

Hoewel dit een gebruikelijke checklist is, raad ik aan om een ​​standaardtestchecklist op te stellen die is afgestemd op uw specifieke behoeften met behulp van onderstaande testcases naast toepassingsspecifieke tests.

Aanbevolen tool:

Voordat u doorgaat met het schrijven van testcases, raden we u aan deze Testcase Management-tool te downloaden. Dit vergemakkelijkt het schrijfproces van uw testplan en testcase dat in deze tutorial wordt genoemd.

​ Download TestRail Test Case Management Tool

Belang van het gebruik van een checklist voor testen

# 1) Het onderhouden van een standaardrepository van herbruikbare testcases voor uw applicatie zorgt ervoor dat de meest voorkomende bugs sneller worden opgemerkt.
#twee) Een checklist helpt om het schrijven van testcases snel af te ronden voor nieuwe versies van de applicatie.
# 3) Door de testcases opnieuw te gebruiken, kunt u geld besparen op middelen om repetitieve tests te schrijven.
# 4) Belangrijke testgevallen komen altijd aan bod, waardoor het bijna onmogelijk is om ze te vergeten.
# 5) De testchecklist kan door ontwikkelaars worden doorverwezen om te controleren of de meest voorkomende problemen in de ontwikkelingsfase zelf worden opgelost.

Opmerkingen:

• Voer deze scenario's uit met verschillende gebruikersrollen, bijv. admin-gebruiker, gastgebruiker etc.
• Voor webapplicaties zijn deze scenario's moet worden getest op meerdere browsers zoals IE, FF, Chrome en Safari met versies die zijn goedgekeurd door de klant.
• Test met verschillende schermresoluties zoals 1024 x 768, 1280 x 1024, etc.
• Een toepassing moet worden getest op verschillende beeldschermen, zoals LCD, CRT, notebooks, tablets en mobiele telefoons.
• Test de applicatie op verschillende platforms zoals Windows, Mac, Linux-besturingssystemen enz.

Wat je leert:

• 180+ voorbeeldtestcases voor het testen van webapplicaties
  • Algemene testscenario's
  • GUI en bruikbaarheidstestscenario's
    • Testscenario's voor filtercriteria
    • Testscenario's voor resultatenraster
    • Testscenario's voor een raam
  • Testscenario's voor het testen van databases
    • Testscenario's voor het uploaden van afbeeldingen
    • Testscenario's voor het verzenden van e-mails
    • Testscenario's voor Excel-exportfunctionaliteit
  • Testscenario's voor prestatietests
  • Testscenario's voor beveiligingstests
• 100+ Ready-To-Execute Test Cases (checklists)
  • De complete checklist (testcases) voor de meest voorkomende componenten van AUT
    • Checklist nr. 1: checklist voor mobiel testen
    • Checklist 2: Checklist voor het testen van formulieren / schermen
    • Checklist # 3: Checklist voor het testen van tekstvakken
    • Checklist nr. 4: Checklist voor het testen van keuzelijsten of vervolgkeuzelijsten
    • Checklist 5: checkbox checklist veldtesten
    • Checklist # 6: Checklist voor het testen van keuzerondjes
    • Checklist # 7: Scenario's voor het testen van datumvelden
    • Controlelijst # 8: scenario's voor het testen van knoppen opslaan
    • Controlelijst # 9: Knoptestscenario's annuleren
    • Controlelijst # 10: testpunten voor knoppen verwijderen
    • Controlelijst # 11: getroffen gebieden verifiëren na opslaan of bijwerken
    • Checklist # 12: Testlijst voor gegevensrasters
  • Aanbevolen literatuur

180+ voorbeeldtestcases voor het testen van webapplicaties

Veronderstellingen: Stel dat uw applicatie de volgende functionaliteiten ondersteunt

• Formulieren met verschillende velden
• Kindervensters
• De applicatie werkt samen met de database
• Diverse zoekfiltercriteria en weergaveresultaten
• Afbeelding uploaden
• Stuur e-mailfunctionaliteit
• Data export functionaliteit

Algemene testscenario's

1. Alle verplichte velden moeten worden gevalideerd en aangegeven met een asterisk (*) symbool.
2. Validatiefoutmeldingen moeten correct op de juiste positie worden weergegeven.
3. Alle foutmeldingen moeten in dezelfde CSS-stijl worden weergegeven ( Bijvoorbeeld, met rode kleur)
4. Algemene bevestigingsberichten moeten worden weergegeven in een andere CSS-stijl dan de stijl voor foutberichten ( Bijvoorbeeld, groene kleur gebruiken)
5. Tooltips-tekst moet zinvol zijn.
6. Vervolgkeuzelijsten moeten de eerste invoer leeg hebben of tekst zoals ‘Selecteren’.
7. ‘Verwijder functionaliteit’ voor elk record op een pagina moet om bevestiging vragen.
8. Selecteer / deselecteer alle records optie moet worden verstrekt als de pagina functionaliteit voor het toevoegen / verwijderen / bijwerken van records ondersteunt
9. Bedragwaarden moeten worden weergegeven met de juiste valutasymbolen.
10. Er moet een standaard paginasortering worden opgegeven.
11. De functionaliteit van de resetknop moet standaardwaarden voor alle velden instellen.
12. Alle numerieke waarden moeten correct worden opgemaakt.
13. Invoervelden moeten worden gecontroleerd op de maximale veldwaarde. Invoerwaarden groter dan de opgegeven maximale limiet mogen niet worden geaccepteerd of opgeslagen in de database.
14. Controleer alle invoervelden op speciale tekens.
15. Veldlabels moeten standaard zijn, bijv. veld waarin de voornaam van de gebruiker wordt geaccepteerd, moet correct worden gelabeld als ‘Voornaam’.
16. Controleer de functionaliteit voor het sorteren van pagina's na het toevoegen / bewerken / verwijderen van een record.
17. Controleer op time-outfunctionaliteit. Time-outwaarden moeten configureerbaar zijn. Controleer het toepassingsgedrag na de time-out van de bewerking.
18. Controleer cookies die in een applicatie worden gebruikt.
19. Controleer of downloadbare bestanden naar de juiste bestandspaden verwijzen.
20. Alle bronsleutels moeten configureerbaar zijn in configuratiebestanden of database in plaats van harde codering.
21. De standaardconventies moeten overal worden gevolgd voor het benoemen van bronsleutels.
22. Valideer de markup voor alle webpagina's (valideer HTML en CSS op syntaxisfouten) om er zeker van te zijn dat ze voldoen aan de standaarden.
23. Applicatiecrash of niet-beschikbare pagina's moeten worden omgeleid naar de foutpagina.
24. Controleer de tekst op alle pagina's op spelfouten en grammaticale fouten.
25. Controleer numerieke invoervelden met tekeninvoerwaarden. Een correct validatiebericht zou moeten verschijnen.
26. Controleer op negatieve getallen indien toegestaan ​​voor numerieke velden.
27. Controleer het aantal velden met decimale getallen.
28. Controleer de functionaliteit van de knoppen die op alle pagina's beschikbaar zijn.
29. De gebruiker mag een pagina niet twee keer indienen door snel achter elkaar op de verzendknop te drukken.
30. Bij alle berekeningen moet rekening worden gehouden met fouten bij delen door nul.
31. Invoergegevens met de eerste en laatste positie blanco moeten correct worden behandeld.

hoe je een .bin

GUI en bruikbaarheidstestscenario's

1. Alle velden op een pagina ( Bijvoorbeeld, tekstvak, radio-opties, vervolgkeuzelijsten) moeten correct zijn uitgelijnd.
2. Numerieke waarden moeten correct worden gerechtvaardigd, tenzij anders aangegeven.
3. Er moet voldoende ruimte zijn tussen veldlabels, kolommen, rijen, foutmeldingen, enz.
4. De schuifbalk mag alleen worden ingeschakeld als dat nodig is.
5. Lettergrootte, stijl en kleur voor kop, beschrijvende tekst, labels, infield-gegevens en rasterinformatie moeten standaard zijn zoals gespecificeerd in SRS.
6. Het tekstvak met de beschrijving moet meerdere regels bevatten.
7. Uitgeschakelde velden moeten grijs worden weergegeven en gebruikers zouden de focus niet op deze velden moeten kunnen zetten.
8. Na het klikken op een invoertekstveld, zou de muispijlaanwijzer moeten veranderen in de cursor.
9. De gebruiker mag niet in vervolgkeuzelijsten kunnen typen.
10. Informatie die door gebruikers wordt ingevuld, moet intact blijven als er een foutmelding op de pagina wordt verzonden. De gebruiker moet het formulier opnieuw kunnen verzenden door de fouten te corrigeren.
11. Controleer of de juiste veldlabels worden gebruikt in foutmeldingen.
12. Vervolgkeuzeveldwaarden moeten in de gedefinieerde sorteervolgorde worden weergegeven.
13. Tab en Shift + Tab-volgorde zouden correct moeten werken.
14. Standaard radio-opties moeten vooraf worden geselecteerd bij het laden van de pagina.
15. Veldspecifieke helpberichten en helpberichten op paginaniveau moeten beschikbaar zijn.
16. Controleer bij fouten of de juiste velden zijn gemarkeerd.
17. Controleer of de vervolgkeuzelijstopties leesbaar zijn en niet worden afgekapt vanwege limieten voor de veldgrootte.
18. Alle knoppen op een pagina moeten toegankelijk zijn via sneltoetsen en de gebruiker moet alle bewerkingen met een toetsenbord kunnen uitvoeren.
19. Controleer alle pagina's op gebroken afbeeldingen.
20. Controleer alle pagina's op verbroken links.
21. Alle pagina's moeten een titel hebben.
22. Bevestigingsberichten moeten worden weergegeven voordat u een update- of verwijderbewerking uitvoert.
23. Zandloper moet worden weergegeven als de toepassing bezig is.
24. Paginatekst moet links worden uitgelijnd.
25. De gebruiker moet in staat zijn om slechts één radio-optie en elke combinatie voor selectievakjes te selecteren.

Testscenario's voor filtercriteria

1. De gebruiker moet resultaten kunnen filteren met alle parameters op de pagina.
2. De verfijnde zoekfunctionaliteit moet de zoekpagina laden met alle door de gebruiker geselecteerde zoekparameters.
3. Als er ten minste één filtercriterium vereist is om de zoekbewerking uit te voeren, zorg er dan voor dat het juiste foutbericht wordt weergegeven wanneer de gebruiker de pagina verzendt zonder filtercriteria te selecteren.
4. Als ten minste één selectie van filtercriteria niet verplicht is, moet de gebruiker de pagina kunnen indienen en moeten de standaardzoekcriteria worden gebruikt om de resultaten op te vragen.
5. De juiste validatieberichten moeten worden weergegeven voor alle ongeldige waarden voor filtercriteria.

Testscenario's voor resultatenraster

1. Het symbool voor het laden van pagina's moet worden weergegeven als het meer dan de standaardtijd duurt om de resultatenpagina te laden.
2. Controleer of alle zoekparameters worden gebruikt om gegevens op te halen die in het resultatenraster worden weergegeven.
3. Het totale aantal resultaten moet in het resultatenraster worden weergegeven.
4. Zoekcriteria die worden gebruikt voor het zoeken, moeten in het resultatenraster worden weergegeven.
5. Resultaat-rasterwaarden moeten worden gesorteerd op de standaardkolom.
6. Gesorteerde kolommen moeten worden weergegeven met een sorteerpictogram.
7. Resultaatrasters moeten alle opgegeven kolommen met de juiste waarden bevatten.
8. De oplopende en aflopende sorteerfunctionaliteit zou moeten werken voor kolommen die worden ondersteund door gegevenssortering.
9. Resultaatrasters moeten worden weergegeven met de juiste kolom- en rijafstand.
10. Paginering moet worden ingeschakeld als er meer resultaten zijn dan het standaard aantal resultaten per pagina.
11. Controleer de paginering van de volgende, vorige, eerste en laatste pagina.
12. Dubbele records mogen niet in het resultatenraster worden weergegeven.
13. Controleer of alle kolommen zichtbaar zijn en indien nodig een horizontale schuifbalk is ingeschakeld.
14. Controleer de gegevens voor dynamische kolommen (kolommen waarvan de waarden dynamisch worden berekend op basis van de andere kolomwaarden).
15. Voor resultaatrasters die rapporten tonen, vinkt u de rij 'Totalen' aan en verifieert u het totaal voor elke kolom.
16. Voor resultaatrasters die rapporten tonen, vinkt u de rijgegevens van ‘Totalen’ aan wanneer paginering is ingeschakeld en de gebruiker wordt naar de volgende pagina genavigeerd.
17. Controleer of de juiste symbolen worden gebruikt voor het weergeven van kolomwaarden, bijv. Het% -symbool moet worden weergegeven voor het berekenen van het percentage.
18. Controleer de gegevens van het resultatenraster om te weten of het datumbereik is ingeschakeld.

Testscenario's voor een raam

1. Controleer of de standaard venstergrootte correct is.
2. Controleer of de grootte van het onderliggende venster correct is.
3. Controleer of er een veld op de pagina staat met de standaardfocus (in het algemeen moet de focus worden ingesteld op het eerste invoerveld van het scherm).
4. Controleer of onderliggende vensters worden gesloten bij het sluiten van het bovenliggende / opener-venster.
5. Als het onderliggende venster wordt geopend, mag de gebruiker geen enkel veld in het achtergrond- of bovenliggende venster kunnen gebruiken of bijwerken
6. Controleer de functionaliteit voor het minimaliseren, maximaliseren en sluiten van vensters.
7. Controleer of het venster kan worden aangepast.
8. Controleer de schuifbalkfunctionaliteit voor bovenliggende en onderliggende vensters.
9. Controleer de annuleerknopfunctionaliteit voor het onderliggende venster.

Testscenario's voor het testen van databases

1. Controleer of de juiste gegevens in de database worden opgeslagen na een succesvolle pagina-verzending.
2. Controleer de waarden op kolommen die geen null-waarden accepteren.
3. Controleer de gegevensintegriteit. Gegevens moeten op basis van het ontwerp in enkele of meerdere tabellen worden opgeslagen.
4. Indexnamen moeten worden gegeven volgens de normen, bijv. IND__
5. Tabellen moeten een primaire sleutelkolom hebben.
6. Tabelkolommen moeten beschrijvende informatie beschikbaar hebben (behalve controlekolommen zoals aanmaakdatum, aangemaakt door, etc.)
7. Voor elke database moet een logboek voor het toevoegen / bijwerken van databases worden toegevoegd.
8. Vereiste tabelindexen moeten worden gemaakt.
9. Controleer of de gegevens pas in de database zijn vastgelegd als de bewerking is voltooid.
10. Gegevens moeten worden teruggedraaid in het geval van mislukte transacties.
11. De databasenaam moet worden opgegeven volgens het applicatietype, d.w.z. test, UAT, sandbox, live (hoewel dit geen standaard is, is het handig voor databaseonderhoud)
12. Logische namen van databases moeten worden opgegeven in overeenstemming met de databasenaam (ook dit is niet standaard, maar nuttig voor DB-onderhoud).
13. Opgeslagen procedures mogen geen voorvoegsel 'sp_' krijgen
14. Controleer of waarden voor tabelauditkolommen (zoals aanmaakdatum, aangemaakt door, bijgewerkt, bijgewerkt door, is verwijderd, verwijderde gegevens, verwijderd door, enz.) Correct ingevuld.
15. Controleer of de invoergegevens niet worden afgekapt tijdens het opslaan. De veldlengte die op de pagina en in het databaseschema aan de gebruiker wordt getoond, moet hetzelfde zijn.
16. Controleer numerieke velden met minimum-, maximum- en zwevende waarden.
17. Controleer numerieke velden met negatieve waarden (voor zowel acceptatie als niet-acceptatie).
18. Controleer of het keuzerondje en de vervolgkeuzelijst correct zijn opgeslagen in de database.
19. Controleer of de databasevelden zijn ontworpen met het juiste gegevenstype en de juiste gegevenslengte.
20. Controleer of alle tabelbeperkingen zoals een primaire sleutel, externe sleutel, enz. Correct zijn geïmplementeerd.
21. Test opgeslagen procedures en triggers met voorbeeldinvoergegevens.
22. Voorloop- en volgspaties van invoervelden moeten worden afgekapt voordat gegevens in de database worden vastgelegd.
23. Null-waarden mogen niet worden toegestaan ​​voor de kolom Primaire sleutel.

Testscenario's voor het uploaden van afbeeldingen

(Ook van toepassing op andere bestandsuploadfunctionaliteit)
1. Controleer het geüploade afbeeldingspad.
2. Controleer het uploaden van afbeeldingen en wijzig de functionaliteit.
3. Controleer de uploadfunctionaliteit van afbeeldingen met afbeeldingsbestanden met verschillende extensies ( Bijvoorbeeld, JPEG, PNG, BMP, enz.)
4. Controleer de uploadfunctionaliteit van afbeeldingen met afbeeldingen met spatie of een ander toegestaan ​​speciaal teken in de bestandsnaam.
5. Controleer dubbele naam afbeelding uploaden.
6. Controleer het uploaden van afbeeldingen met een grotere afbeeldingsgrootte dan de maximaal toegestane grootte. Het juiste foutbericht moet worden weergegeven.
7. Controleer de uploadfunctionaliteit van afbeeldingen met andere bestandstypen dan afbeeldingen ( Bijvoorbeeld, txt, doc, pdf, exe, enz.). Er moet een correct foutbericht worden weergegeven.
8. Controleer of afbeeldingen met een gespecificeerde hoogte en breedte (indien gedefinieerd) worden geaccepteerd, anders worden ze afgewezen.
9. De voortgangsbalk voor het uploaden van afbeeldingen zou moeten verschijnen voor afbeeldingen van groot formaat.
10. Controleer of de knop Annuleren werkt tussen het uploadproces in.
11. Controleer of het dialoogvenster voor bestandsselectie alleen de ondersteunde bestanden weergeeft.
12. Controleer de uploadfunctionaliteit voor meerdere afbeeldingen.
13. Controleer de beeldkwaliteit na het uploaden. De beeldkwaliteit mag na het uploaden niet worden gewijzigd.
14. Controleer of de gebruiker de geüploade afbeeldingen kan gebruiken / bekijken.

Testscenario's voor het verzenden van e-mails

(Testcases voor het opstellen of valideren van e-mails zijn hier niet opgenomen)
(Zorg ervoor dat u dummy-e-mailadressen gebruikt voordat u e-mailgerelateerde tests uitvoert)
1. De e-mailsjabloon moet standaard CSS gebruiken voor alle e-mails.
2. E-mailadressen moeten worden gevalideerd voordat e-mails worden verzonden.
3. Speciale tekens in de sjabloon voor de hoofdtekst van de e-mail moeten correct worden verwerkt.
4. Taalspecifieke tekens ( Bijvoorbeeld, Russische, Chinese of Duitse taaltekens) moeten correct worden verwerkt in de hoofdtekst van de e-mail.
5. Onderwerp van e-mail mag niet leeg zijn.
6. Plaatsaanduidingsvelden die in de e-mailsjabloon worden gebruikt, moeten worden vervangen door werkelijke waarden, bijvoorbeeld {Firstname} {Lastname} moet worden vervangen door de voor- en achternaam van een persoon, correct voor alle ontvangers.
7. Als rapporten met dynamische waarden in de hoofdtekst van de e-mail zijn opgenomen, moeten de rapportgegevens correct worden berekend.
8. De naam van de afzender van een e-mail mag niet leeg zijn.
9. E-mails moeten worden gecontroleerd in verschillende e-mailclients zoals Outlook, Gmail, Hotmail, Yahoo! mail, enz.
10. Vink aan om e-mailfunctionaliteit te verzenden met behulp van de velden TO, CC en BCC.
11. Controleer e-mails in platte tekst.
12. Controleer e-mails in HTML-indeling.
13. Controleer de koptekst en voettekst van de e-mail voor het bedrijfslogo, het privacybeleid en andere links.
14. Controleer e-mails met bijlagen.
15. Schakel dit selectievakje in om e-mailfunctionaliteit naar één of meerdere ontvangers of ontvangers van distributielijsten te verzenden.
16. Controleer of een antwoord op het e-mailadres juist is.
17. Vink aan om het grote aantal e-mails te verzenden.

Testscenario's voor Excel-exportfunctionaliteit

1. Het bestand moet worden geëxporteerd in de juiste bestandsextensie.
2. De bestandsnaam voor het geëxporteerde Excel-bestand moet voldoen aan de normen, Bijvoorbeeld, als de bestandsnaam de tijdstempel gebruikt, zou deze correct moeten worden vervangen door een werkelijke tijdstempel op het moment dat het bestand wordt geëxporteerd.
3. Controleer het datumnotatie als het geëxporteerde Excel-bestand de datumkolommen bevat.
4. Controleer de getalnotatie op numerieke waarden of valutawaarden. De opmaak moet hetzelfde zijn als op de pagina.
5. Het geëxporteerde bestand moet kolommen hebben met de juiste kolomnamen.
6. De standaard paginasortering moet ook in het geëxporteerde bestand worden uitgevoerd.
7. Excel-bestandsgegevens moeten correct zijn opgemaakt met kop- en voettekst, datum, paginanummers, enz. Waarden voor alle pagina's.
8. Controleer of de gegevens die op een pagina worden weergegeven en het geëxporteerde Excel-bestand hetzelfde zijn.
9. Controleer de exportfunctionaliteit wanneer paginering is ingeschakeld.
10. Controleer of de exportknop het juiste pictogram weergeeft volgens het geëxporteerde bestandstype, Bijvoorbeeld, Excel-bestandspictogram voor xls-bestanden
11. Controleer de exportfunctionaliteit voor bestanden met een zeer grote omvang.
12. Controleer de exportfunctionaliteit voor pagina's met speciale tekens. Controleer of deze speciale tekens correct worden geëxporteerd in het Excel-bestand.

Testscenario's voor prestatietests

1. Controleer of de laadtijd van de pagina binnen het acceptabele bereik valt.
2. Controleer het laden van de pagina bij langzame verbindingen.
3. Controleer de reactietijd voor elke actie onder lichte, normale, gemiddelde en zware belasting.
4. Controleer de prestaties van in de database opgeslagen procedures en triggers.
5. Controleer de uitvoeringstijd van de databasequery.
6. Controleer op belastingtests van de applicatie.
7. Controleer de stresstest van de applicatie.
8. Controleer het CPU- en geheugengebruik onder piekbelasting.

Testscenario's voor beveiligingstests

1. Controleer op SQL-injectie-aanvallen.
2. Beveiligde pagina's moeten het HTTPS-protocol gebruiken.
3. Paginacrash mag geen applicatie- of serverinformatie onthullen. Hiervoor moet de foutpagina worden weergegeven.
4. Escape speciale tekens in de invoer.
5. Foutmeldingen mogen geen gevoelige informatie onthullen.
6. Alle inloggegevens moeten worden overgedragen via een gecodeerd kanaal.
7. Test de wachtwoordbeveiliging en de handhaving van het wachtwoordbeleid.
8. Controleer de uitlogfunctionaliteit van de applicatie.
9. Controleer op aanvallen met brute kracht.
10. Cookie-informatie mag alleen in gecodeerd formaat worden opgeslagen.
11. Controleer de duur van de sessiecookie en de beëindiging van de sessie na een time-out of uitloggen.
11. Sessietokens moeten via een beveiligd kanaal worden verzonden.
13. Het wachtwoord mag niet in cookies worden opgeslagen.
14. Test op Denial of Service-aanvallen.
15. Test op geheugenlekkage.
16. Test ongeautoriseerde applicatietoegang door variabele waarden in de adresbalk van de browser te manipuleren.
17. Test het overhandigen van bestandsextensies zodat exe-bestanden niet worden geüpload en uitgevoerd op de server.
18. Gevoelige velden zoals wachtwoorden en creditcardgegevens hoeven niet automatisch te worden aangevuld.
19. De functionaliteit voor het uploaden van bestanden moet bestandstypebeperkingen en ook antivirus gebruiken voor het scannen van geüploade bestanden.
20. Controleer of directoryvermelding verboden is.
21. Wachtwoorden en andere gevoelige velden moeten tijdens het typen worden gemaskeerd.
22. Controleer of de functionaliteit voor het vergeten van een wachtwoord is beveiligd met functies zoals het tijdelijk verlopen van wachtwoorden na bepaalde uren en er wordt een beveiligingsvraag gesteld voordat u een nieuw wachtwoord wijzigt of vraagt.
23. Controleer CAPTCHA-functionaliteit.
24. Controleer of belangrijke gebeurtenissen zijn vastgelegd in logbestanden.
25. Controleer of toegangsrechten correct zijn geïmplementeerd.

Testcases voor penetratietesten - Ik heb ongeveer 41 testcases voor penetratietesten opgesomd deze pagina ​

Ik zou heel graag willen bedanken Devanshu lavaniya (Sr. QA Engineer werkzaam voor I-link Infosoft) om mij te helpen bij het opstellen van deze uitgebreide testchecklist.

Ik heb geprobeerd om bijna alle standaard testscenario's voor web- en desktopapplicatiefunctionaliteit te behandelen. Maar toch weet ik dat dit geen volledige checklist is. Testers op verschillende projecten hebben hun eigen testchecklist op basis van hun ervaring.

Bijgewerkt:

100+ Ready-To-Execute Test Cases (checklists)

U kunt deze lijst gebruiken om de meest voorkomende componenten van AUT te testen

Hoe test je de meest voorkomende componenten van je AUT, elke keer weer effectief?

Dit artikel is een lijst met algemene validaties op de meest algemeen gevonden elementen van AUT - die is samengesteld voor het gemak van testers (vooral in de agile omgeving waar frequente korte-termijn releases plaatsvinden).

Elke AUT (Application Under Test) is uniek en heeft een heel specifiek zakelijk doel. De individuele aspecten (modules) van de AUT spelen in op verschillende operaties / acties die cruciaal zijn voor het succes van het bedrijf dat de AUT ondersteunt.

Hoewel elke AUT anders is ontworpen, zijn de afzonderlijke componenten / velden die we op de meeste pagina's / schermen / applicaties tegenkomen hetzelfde met min of meer vergelijkbaar gedrag.

Enkele gemeenschappelijke componenten van AUT:

• Opslaan, bijwerken, verwijderen, resetten, annuleren, OK - links / knoppen - waarvan de functionaliteit het label van het object aangeeft.
• Tekstvak, vervolgkeuzemenu's, selectievakjes, keuzerondjes, datumcontrolevelden - die werken elke keer op dezelfde manier.
• Datarasters, getroffen gebieden, enz. Om rapporten te vergemakkelijken.

De manier waarop deze individuele elementen bijdragen aan de algehele functionaliteit van de applicatie kan verschillen, maar de stappen om ze te valideren zijn altijd dezelfde.

Laten we doorgaan met de lijst met de meest voorkomende validaties voor Web- of desktopapplicatie pagina's / formulieren.

Opmerking : Het daadwerkelijke resultaat, het verwachte resultaat, de testgegevens en andere parameters die typisch deel uitmaken van een testcase, worden eenvoudigheidshalve weggelaten - Er wordt een algemene checklistbenadering gebruikt.

hoe u een testplan maakt

Doel van deze uitgebreide checklist:

Het primaire doel van deze checklists (of testcases) is om een ​​maximale testdekking op veldniveau-validaties te garanderen zonder al te veel tijd te besteden, en tegelijkertijd de kwaliteit van het testen ervan niet in gevaar te brengen.

Vertrouwen in een product kan immers alleen worden bereikt door elk onderdeel zo goed mogelijk te testen.

De complete checklist (testcases) voor de meest voorkomende componenten van AUT

Notitie:U kunt deze checklists gebruiken zoals ze zijn in Microsoft Excel-formaat (download vindt u aan het einde van het artikel). U kunt zelfs de testuitvoering in hetzelfde bestand volgen met pass / fail-resultaten en status.

Dit zou een alles-in-één hulpmiddel kunnen zijn voor QA-teams om de meest voorkomende componenten van AUT te testen en te volgen.U kunt testgevallen toevoegen of bijwerken die specifiek zijn voor uw toepassingen maak er een nog uitgebreidere lijst van.

Checklist nr. 1: checklist voor mobiel testen

Checklist 2: Checklist voor het testen van formulieren / schermen

Checklist # 3: Checklist voor het testen van tekstvakken

Tekstvak:

BVA (grootte) voor tekstvak:

Min -> -> Pass
Min-1 -> -> Mislukt
Min + 1 -> -> Pass
Max-1 -> -> Pass
Max + 1 -> -> Mislukt
Max -> -> Pass

ECP voor tekstvak:

Checklist nr. 4: Checklist voor het testen van keuzelijsten of vervolgkeuzelijsten

Lijstvak / vervolgkeuzelijst:

Checklist 5: checkbox checklist veldtesten

CheckBox:

Checklist # 6: Checklist voor het testen van keuzerondjes

Radio knop:

Checklist # 7: Scenario's voor het testen van datumvelden

Datum veld:

Controlelijst # 8: scenario's voor het testen van knoppen opslaan

Opslaan / bijwerken:

Controlelijst # 9: Knoptestscenario's annuleren

Annuleren:

Controlelijst # 10: testpunten voor knoppen verwijderen

Verwijderen:

Controlelijst # 11: getroffen gebieden verifiëren na opslaan of bijwerken

Na het opslaan / bijwerken:

Checklist # 12: Testlijst voor gegevensrasters

Data rooster:

Bewerk de linkfunctionaliteit

Hoewel deze lijst misschien niet volledig is, is hij wel degelijk uitgebreid.

DOWNLOADEN==> U kunt al deze checklists downloaden in MS Excel-formaat: Download in Excel-formaat

Aandachtspunten:

1. Afhankelijk van uw behoefte kunnen extra tests onder elke categorie / voor elk veld worden toegevoegd of kunnen bestaande velden worden verwijderd. Met andere woorden, deze lijsten zijn volledig aanpasbaar.
2. Als u validaties op veldniveau aan uw testsuites wilt toevoegen, hoeft u alleen maar de respectieve lijst op te halen en deze te gebruiken voor het scherm / de pagina die u wilt testen.
3. Houd de checklist bij door de pass / fail-status bij te werken om dit een one-stop-shop te maken voor het aanbieden van functies, deze te valideren en de testresultaten vast te leggen.

Voel je vrij om dit een complete checklist te maken door meer testcases / scenario's of negatieve testcases toe te voegen in de comments hieronder.

Ik zou het ook op prijs stellen als je dit met je vrienden zou delen!

PREV-zelfstudie ​ VOLGENDE zelfstudie

Aanbevolen literatuur

• Testcases schrijven: de ultieme gids met voorbeelden
• Website Cookie Testing & Test Cases voor het testen van webapplicatie cookies
• Voorbeeldtestcase-sjabloon met voorbeelden van testcases (Download)
• Beste softwaretesttools 2021 (QA Test Automation Tools)
• Handleiding voor het testen van webapplicaties
• Applicatie testen - In de basis van softwaretesten!
• Installeer uw applicatie op het apparaat en begin met testen vanuit Eclipse
• TDD versus BDD - Analyseer de verschillen met voorbeelden