how write test cases
In deze diepgaande hands-on tutorial over het schrijven van testcases, heb ik de details behandeld van wat een testcase is, de standaarddefinitie ervan en testcase-ontwerptechnieken.
Wat is een testcase?
Een testcase heeft componenten die input, actie en een verwachte respons beschrijven om te bepalen of een feature van een applicatie correct werkt.
Een testcase is een set instructies over 'HOE' om een bepaald testdoel / -doel te valideren, die ons, wanneer gevolgd, zal vertellen of aan het verwachte gedrag van het systeem wordt voldaan of niet.
Lijst met tutorials die in deze testcase-schrijfserie aan bod komen:
Hoe te schrijven:
Tutorial # 1: Wat is een testcase en hoe u testcases schrijft (deze tutorial)
Tutorial # 2: Voorbeeldtestcase-sjabloon met voorbeelden [Download] (moet lezen)
Tutorial # 3: Testcases schrijven vanuit SRS-document
Tutorial # 4: Hoe u testcases schrijft voor een bepaald scenario
Tutorial # 5: Hoe u zich kunt voorbereiden op het schrijven van testcases
Tutorial # 6: Negatieve testcases schrijven
Voorbeelden:
Tutorial # 7: 180+ voorbeeldtestcases voor web- en desktopapplicaties
Tutorial # 8: 100+ kant-en-klare testscenario's (checklist)
gratis dvd-kopieerapparaat voor Windows 10
Schrijftechnieken:
Tutorial # 9: Oorzaak en gevolg-grafiek - Dynamische schrijftechniek voor testcases
Tutorial # 10: Testtechniek voor staatstransitie
Tutorial # 11: Orthogonale array-testtechniek
Tutorial # 12: Fout bij het raden van techniek
Tutorial # 13: Field Validation Table (FVT) Testontwerptechniek
Testcase versus testscenario's:
Tutorial # 14: Testcases versus testscenario's
Tutorial # 15: Verschil tussen testplan, teststrategie en testcase
Automatisering:
Tutorial # 16: Hoe u de juiste testcases selecteert voor automatiseringstests
Tutorial # 17: Hoe handmatige testcases te vertalen naar automatiseringsscripts
Test Management Tools:
Tutorial # 18: Beste testbeheertools
Tutorial # 19: TestLink voor het beheer van testgevallen
Tutorial # 20: Testcases maken en beheren met HP Quality Center
Tutorial # 21: Testcases uitvoeren met ALM / QC
Domeinspecifieke gevallen:
Tutorial # 22: Testcases voor ERP-applicatie
Tutorial # 23: JAVA Application testcases
Tutorial # 24: Grenswaardeanalyse en equivalentiepartitionering
Laten we doorgaan met de eerste tutorial in deze serie.
Aanbevolen hulpmiddelen:
Voordat u doorgaat met het schrijven van testcases, raden we u aan deze tool voor het beheren van testcases te downloaden. Dit vergemakkelijkt het schrijfproces van uw testcases dat in deze tutorial wordt genoemd:
#1) TestRail
Download TestRail Test Case Management Tool
# 2) TestMonitor
Online testbeheer op topniveau. Revolutionair eenvoudig.
TestMonitor is een end-to-end testmanagementtool voor elke organisatie. Een eenvoudige, intuïtieve benadering van testen. Of u nu bedrijfssoftware implementeert, kwaliteitscontrole nodig heeft, een kwaliteitsapp bouwt of gewoon een helpende hand nodig heeft bij uw testproject, TestMonitor heeft u gedekt.
Bezoek de TestMonitor-website
Wat je leert:
- Wat is een testcase en hoe schrijf je testcases?
- Tips voor het schrijven van toetsen
- Hoe u excellentie bereikt in de documentatie van testgevallen
- Handige tips en trucs
- # 1) Is uw testdocument in goede staat?
- # 2) Vergeet niet de negatieve gevallen te behandelen
- # 3) Voer atoomteststappen uit
- # 4) Geef prioriteit aan de tests
- # 5) Volgorde is belangrijk
- # 6) Voeg een tijdstempel en de testernaam toe aan de opmerkingen
- # 7) Inclusief browsergegevens
- # 8) Bewaar twee aparte bladen - ‘Bugs’ en ‘Samenvatting’ in het document
- Handige tips en trucs
- Hoe u GEEN toetsen schrijft
- Hoe u de efficiëntie van testcases kunt verbeteren
- Belang van standaardisering van de testcases
Wat is een testcase en hoe schrijf je testcases?
Effectieve cases schrijven is een vaardigheid. En u kunt het leren van ervaring en kennis van de te testen applicatie.
Raadpleeg de volgende video voor basisinstructies voor het schrijven van tests:
De bovenstaande bronnen zouden ons de basis van het schrijfproces moeten geven.
Niveaus van het testschrijfproces:
- Niveau 1: In dit niveau schrijf je het basisscases uit de beschikbare specificatie en gebruikersdocumentatie.
- Level 2: Dit is de praktische fase waarin schrijfcases afhangen van de daadwerkelijke functionele en systeemstroom van de applicatie.
- Niveau 3: Dit is de fase waarin u enkele gevallen en schrijf een testprocedure De testprocedure is niets anders dan een groep kleine gevallen, misschien een maximum van 10.
- Niveau 4: Automatisering van het project. Dit minimaliseert de menselijke interactie met het systeem en dus kan de QA zich concentreren op de momenteel bijgewerkte functionaliteiten om te testen in plaats van bezig te blijven met regressietesten.
Waarom schrijven we tests?
Het basisdoel van het schrijven van cases is om de testdekking van een applicatie te valideren.
Als je in een CMMi-organisatie werkt, worden de testnormen beter gevolgd. Het schrijven van cases brengt een soort standaardisatie met zich mee en minimaliseert de ad-hocbenadering bij het testen.
Hoe testcases schrijven?
Velden:
- Testcase-ID
- Te testen eenheid: Wat moet worden gecontroleerd?
- Veronderstellingen
- Testgegevens: Variabelen en hun waarden
- Uit te voeren stappen
- verwacht resultaat
- Werkelijke resultaat
- Pass / Fail
- Opmerkingen
Basisformaat van testcaseverklaring
Verifiëren
Gebruik makend van [toolnaam, tagnaam, dialoogvenster, enz.]
Met [voorwaarden]
Naar [wat wordt teruggegeven, getoond, aangetoond]
Verifiëren: Wordt gebruikt als het eerste woord van de testverklaring.
Gebruik makend van: Om te bepalen wat er wordt getest. U kunt hier ‘invoeren’ of ‘selecteren’ gebruiken in plaats van te gebruiken, afhankelijk van de situatie.
Voor elke toepassing moet u alle soorten tests dekken, zoals:
- Functionele gevallen
- Negatieve gevallen
- Grenswaarde gevallen
Tijdens het schrijven van al uw TC's moeten eenvoudig en gemakkelijk te begrijpen zijn
Tips voor het schrijven van toetsen
Een van de meest voorkomende en belangrijkste activiteiten van een Software Tester (SQA / SQC-persoon) is het schrijven van testscenario's en cases.
Er zijn enkele belangrijke en kritische factoren die verband houden met deze belangrijke activiteit. Laten we eerst die factoren in vogelvlucht bekijken.
Belangrijke factoren die betrokken zijn bij het schrijfproces:
a) TC's zijn vatbaar voor regelmatige herziening en update:
We leven in een continu veranderende wereld en dat geldt ook voor software. Wijzigingen in softwarevereisten hebben direct invloed op de cases. Telkens wanneer vereisten worden gewijzigd, moeten TC's worden bijgewerkt.
Toch is het niet alleen de verandering in de vereiste die herziening en update van TC's kan veroorzaken. Tijdens de uitvoering van TC's komen veel ideeën in de geest op en kunnen veel subvoorwaarden van een enkele TC worden geïdentificeerd. Dit alles zorgt voor een update van TC's en soms zelfs voor het toevoegen van nieuwe TC's.
Bovendien vragen verschillende fixes en / of rimpelingen tijdens regressietests om herziene of nieuwe TC's.
b) TC's zijn vatbaar voor distributie onder de testers die deze zullen uitvoeren:
Er is natuurlijk nauwelijks een situatie waarin één enkele tester alle TC's uitvoert. Normaal gesproken zijn er meerdere testers die verschillende modules van één applicatie testen. De TC's zijn dus verdeeld over de testers op basis van hun eigendom van de te testen applicatie.
Sommige TC's die verband houden met de integratie van de applicatie, kunnen worden uitgevoerd door meerdere testers, terwijl de andere TC's mogelijk alleen door één tester worden uitgevoerd.
c) TC's zijn vatbaar voor clustering en batching:
Het is normaal en gebruikelijk dat TC's die tot een enkel testscenario behoren, gewoonlijk hun uitvoering in een bepaalde volgorde of in de vorm van een groep eisen. Er kunnen bepaalde voorwaarden aan een TC zijn verbonden die de uitvoering van andere TC's vereisen voordat ze zichzelf uitvoeren.
Evenzo, volgens de bedrijfslogica van de AUT, kan een enkele TC bijdragen aan verschillende testcondities en kan een enkele testconditie uit meerdere TC's bestaan.
d) TC's hebben de neiging tot onderlinge afhankelijkheid:
Dit is ook een interessant en belangrijk gedrag van de TC's, wat aangeeft dat ze onderling afhankelijk van elkaar kunnen zijn. Van middelgrote tot grote applicaties met complexe bedrijfslogica, deze tendens is beter zichtbaar.
Het duidelijkste gebied van elke applicatie waar dit gedrag zeker kan worden waargenomen, is de interoperabiliteit tussen verschillende modules van dezelfde of zelfs verschillende applicaties. Simpel gezegd, waar de verschillende modules, een enkele applicatie of meerdere applicaties, onderling afhankelijk zijn, wordt hetzelfde gedrag ook weerspiegeld in de TC's.
e) TC's zijn vatbaar voor distributie onder de ontwikkelaars (vooral in een testgestuurde ontwikkelomgeving):
Een belangrijk feit over TC's is dat deze niet alleen door de testers worden gebruikt. In het normale geval, wanneer een bug wordt opgelost door de ontwikkelaars, gebruiken ze indirect de TC om het probleem op te lossen. Evenzo, als de testgestuurde ontwikkeling wordt gevolgd, worden TC's rechtstreeks door de ontwikkelaars gebruikt om hun logica te bouwen en alle scenario's in hun code te dekken die door TC's worden geadresseerd.
Tips om effectieve tests te schrijven:
Rekening houdend met de bovenstaande 5 factoren, volgen hier een paar tips om effectieve TC's te schrijven.
Laten we beginnen!!!
# 1) Houd het simpel maar niet te simpel; maak het complex maar niet te complex:
Deze verklaring lijkt een paradox. Maar ik beloof je dat het niet zo is. Houd alle stappen van TC's atomair en nauwkeurig. Noem de stappen met de juiste volgorde en correcte toewijzing aan de verwachte resultaten. De testcase moet voor zichzelf spreken en gemakkelijk te begrijpen zijn. Dit is wat ik bedoel om het simpel te maken.
Nu, het een complex middel maken om het te integreren met het testplan en andere TC's. Raadpleeg de andere TC's, relevante artefacten, GUI's enz. Waar en wanneer nodig. Maar doe dit op een evenwichtige manier. Maak geen tester die heen en weer beweegt in de stapel documenten voor het voltooien van een enkel testscenario.
Aan de andere kant, laat de tester deze TC's zelfs niet op een zeer compacte manier documenteren. Onthoud bij het schrijven van TC's altijd dat u of iemand anders deze moet herzien en bijwerken.
# 2) Beoordeel, na het documenteren van de testgevallen, eenmaal als tester:
Denk nooit dat de klus geklaard is als je de laatste TC van het testscenario hebt geschreven. Ga naar het begin en bekijk alle TC's één keer, maar niet met de mindset van een TC-schrijver of testplanner. Bekijk alle TC's met de geest van een tester. Denk rationeel en probeer uw TC's droog te laten lopen.
Evalueer alle stappen en kijk of u deze duidelijk en op een begrijpelijke manier hebt genoemd en of de verwachte resultaten in overeenstemming zijn met die stappen.
Zorg ervoor dat het testgegevens gespecificeerd in TC's is niet alleen haalbaar voor echte testers, maar ook volgens de real-time omgeving. Zorg ervoor dat er geen afhankelijkheidsconflict is tussen TC's en controleer of alle verwijzingen naar andere TC's / artefacten / GUI's correct zijn. Anders kunnen de testers in grote problemen komen.
# 3) Zowel gebonden als gemak van de testers:
Laat de testgegevens niet achter op testers. Geef ze een scala aan invoer, vooral als er berekeningen moeten worden uitgevoerd of het gedrag van de toepassing afhankelijk is van invoer. U kunt hen de waarden van testgegevensitems laten bepalen, maar geef hen nooit de vrijheid om zelf de testgegevensitems te kiezen.
Omdat ze, opzettelijk of onbedoeld, dezelfde testgegevens keer op keer kunnen gebruiken en sommige belangrijke testgegevens kunnen worden genegeerd tijdens de uitvoering van TC's.
Houd de testers op hun gemak door de TC's te ordenen per testcategorieën en de gerelateerde gebieden van een applicatie. Geef duidelijk aan en vermeld welke TC's onderling afhankelijk en / of gegroepeerd zijn. Geef ook expliciet aan welke TC's onafhankelijk en geïsoleerd zijn, zodat de tester zijn algehele activiteit dienovereenkomstig kan beheren.
Op dit punt bent u wellicht geïnteresseerd om te lezen over grenswaardeanalyse, een ontwerpstrategie voor testcases die wordt gebruikt bij het testen van zwarte dozen. Klik hier om er meer over te weten.
# 4) Wees een bijdrager:
Accepteer nooit het FS- of ontwerpdocument zoals het is. Het is niet jouw taak om alleen de FS te doorlopen en de testscenario's te identificeren. Aarzel als QA-bron nooit om bij te dragen aan het bedrijfsleven en suggesties te doen als u denkt dat er iets kan worden verbeterd in de toepassing.
Stel ook voor aan ontwikkelaars, vooral in door TC gestuurde ontwikkelomgeving. Stel de vervolgkeuzelijsten, agendaknoppen, selectielijst, groepsradioknoppen, meer betekenisvolle berichten, waarschuwingen, prompts, verbeteringen met betrekking tot bruikbaarheid, enz. Voor.
Test niet alleen, maar maak een verschil!
# 5) Vergeet nooit de eindgebruiker:
De belangrijkste stakeholder is de ‘Eindgebruiker’ die de applicatie uiteindelijk gaat gebruiken. Dus vergeet hem nooit tijdens het schrijven van TC's. In feite mag de eindgebruiker in geen enkel stadium tijdens de SDLC worden genegeerd. Toch heeft mijn nadruk tot dusver alleen betrekking op mijn onderwerp.
Dus, tijdens het identificeren van testscenario's, mag u nooit die cases over het hoofd zien die het meest door de gebruiker zullen worden gebruikt of de cases die bedrijfskritisch zijn, zelfs als ze minder vaak worden gebruikt. Blijf in de schoenen van de eindgebruiker en doorloop vervolgens alle TC's en beoordeel de praktische waarde van het uitvoeren van al uw gedocumenteerde TC's.
Hoe u excellentie bereikt in de documentatie van testgevallen
Als softwaretester zul je het zeker met me eens zijn dat het bedenken van een perfect testdocument echt een uitdagende taak is.
We laten altijd wat ruimte voor verbetering in onze Testcase documentatie Soms zijn we niet in staat om 100% testdekking te bieden via de TC's en soms is het testsjabloon niet in orde, of ontbreekt het ons aan goede leesbaarheid en duidelijkheid aan onze tests.
Wanneer u als tester wordt gevraagd om testdocumentatie te schrijven, moet u niet zomaar ad hoc beginnen. Het is erg belangrijk om het doel van het schrijven van testcases goed te begrijpen voordat u aan het documentatieproces gaat werken.
De tests moeten altijd duidelijk en helder zijn. Ze moeten zo worden geschreven dat het de tester het gemak biedt om de volledige test uit te voeren door de stappen te volgen die in elk van de tests zijn gedefinieerd.
Bovendien moet het testcase-document zoveel cases bevatten als nodig is om volledig te zijn test dekking Bijvoorbeeld , moet u proberen om alle mogelijke scenario's die binnen uw softwaretoepassing kunnen voorkomen, te testen.
Met de bovenstaande punten in gedachten, wil ik u nu een rondleiding geven over hoe u excellentie kunt bereiken in testdocumentatie.
Handige tips en trucs
Hier ga ik u enkele nuttige richtlijnen geven die u een voorsprong kunnen geven in uw testdocumentatie van de anderen.
# 1) Is uw testdocument in goede staat?
De beste en eenvoudigste manier om uw testdocument te ordenen, is door het op te splitsen in vele afzonderlijke nuttige secties. Verdeel de volledige test in meerdere testscenario's. Verdeel vervolgens elk scenario in meerdere tests. Verdeel ten slotte elke case in meerdere teststappen.
Als u Excel gebruikt, documenteer dan elke testcase op een apart blad van de werkmap waarin elke testcase een volledige testflow beschrijft.
# 2) Vergeet niet de negatieve gevallen te behandelen
Als softwaretester moet je out of the box denken en alle mogelijkheden die je applicatie tegenkomt, uittekenen. Wij, als testers, moeten controleren of elke niet-authentieke poging om de software binnen te gaan of ongeldige gegevens die door de applicatie stromen, moet worden gestopt en gerapporteerd.
Een negatief geval is dus net zo belangrijk als een positief geval. Zorg ervoor dat voor elk scenario dat u heeft twee testgevallen - een positief en een negatief De positieve moet de bedoelde of normale stroom dekken en de negatieve moet de onbedoelde of uitzonderlijke stroom dekken.
# 3) Voer atoomteststappen uit
Elke teststap moet een atomaire stap zijn. Er mogen geen verdere tussenstappen zijn. Hoe eenvoudiger en duidelijker een teststap is, hoe gemakkelijker het zou zijn om door te gaan met het testen.
# 4) Geef prioriteit aan de tests
We hebben vaak strikte tijdlijnen om het testen voor een applicatie af te ronden. In dit geval missen we het testen van enkele van de belangrijke functionaliteiten en aspecten van de software. Om dit te voorkomen, moet u bij elke test een prioriteit markeren terwijl u deze documenteert.
U kunt elke codering gebruiken om de prioriteit van een test te definiëren. Het is over het algemeen beter om een van de 3 niveaus te gebruiken, hoog, gemiddeld en laag , of 1, 50 en 100. Dus als je een strikte tijdlijn hebt, moet je eerst alle tests met hoge prioriteit voltooien en dan naar de tests met gemiddelde en lage prioriteit gaan.
Bijvoorbeeld - voor een winkelwebsite kan het verifiëren van toegangsweigering voor een ongeldige poging om in te loggen bij de app een geval met hoge prioriteit zijn, kan het verifiëren van de weergave van relevante producten op het gebruikersscherm een geval van gemiddelde prioriteit zijn en het verifiëren van de kleur van de tekst die wordt weergegeven op de schermknoppen kunnen een test met lage prioriteit zijn.
# 5) Volgorde is belangrijk
Controleer of de volgorde van de stappen in de test absoluut correct is. Een verkeerde volgorde van stappen kan tot verwarring leiden. Bij voorkeur moeten de stappen ook de hele reeks definiëren vanaf het openen van de app tot het verlaten van de app voor een bepaald scenario dat wordt getest.
# 6) Voeg een tijdstempel en de testernaam toe aan de opmerkingen
Er kan een geval zijn waarin u een applicatie test, iemand wijzigingen parallel aan dezelfde app aanbrengt of iemand de app kan updaten nadat uw tests zijn voltooid. Dit leidt tot een situatie waarin uw testresultaten in de loop van de tijd kunnen variëren.
Het is dus altijd beter om een tijdstempel toe te voegen met de naam van de tester in de testopmerkingen, zodat een testresultaat (geslaagd of niet geslaagd) kan worden toegeschreven aan de status van een applicatie op dat specifieke moment. Als alternatief kunt u een ‘ Uitgevoerde datum ’Kolom afzonderlijk toegevoegd aan de testcase die expliciet het tijdstempel van de test identificeert.
# 7) Inclusief browsergegevens
Zoals u weet, kunnen testresultaten, als het een webapplicatie is, verschillen afhankelijk van de browser waarop de test wordt uitgevoerd. Voor het gemak van andere testers, ontwikkelaars of degene die het testdocument beoordeelt, moet u de browsernaam en -versie aan de case toevoegen, zodat het defect gemakkelijk kan worden gerepliceerd.
# 8) Bewaar twee aparte bladen - ‘Bugs’ en ‘Samenvatting’ in het document
Als u in Excel documenteert, moeten de eerste twee bladen van de werkmap Samenvatting en Bugs zijn. Het overzichtsblad moet het testscenario samenvatten en het bugblad moet alle problemen vermelden die tijdens het testen zijn opgetreden. Het belang van het toevoegen van deze twee bladen is dat het de lezer / gebruiker van het document een duidelijk inzicht geeft in het testen.
Dus als de tijd beperkt is, kunnen deze twee bladen zeer nuttig blijken te zijn om een overzicht van de tests te geven.
Het testdocument moet de best mogelijke testdekking en uitstekende leesbaarheid bieden en moet overal één standaardformaat volgen.
We kunnen excellentie bereiken in testdocumentatie door slechts enkele essentiële tips in gedachten te houden, zoals de organisatie van het testcase-document, prioriteit geven aan de TC's, alles in de juiste volgorde hebben, inclusief alle verplichte details om een TC uit te voeren, en duidelijke en duidelijke teststappen te bieden, etc. zoals hierboven besproken.
Hoe u GEEN toetsen schrijft
We besteden de meeste tijd aan het schrijven, beoordelen, uitvoeren of onderhouden hiervan. Het is nogal jammer dat tests ook de meest foutgevoelige zijn. De verschillen in begrip, testpraktijken van organisaties, tijdgebrek etc. zijn enkele van de redenen waarom we vaak tests zien die veel te wensen overlaten.
Er zijn veel artikelen op onze site over dit onderwerp, maar hier zullen we zien Hoe je GEEN testcases schrijft - een paar tips die behulpzaam zullen zijn bij het creëren van onderscheidende, kwalitatieve en effectieve tests.
dimensionale modellering in datawarehouse met voorbeeld
Laten we verder lezen en houd er rekening mee dat deze tips voor zowel nieuwe als ervaren testers zijn.
3 meest voorkomende problemen in testgevallen
- Samengestelde stappen
- Applicatiegedrag wordt beschouwd als verwacht gedrag
- Meerdere voorwaarden in één geval
Deze drie moeten op mijn top 3 lijst staan met veelvoorkomende problemen bij het schrijven van toetsen.
Wat interessant is, is dat dit gebeurt met zowel nieuwe als ervaren testers en dat we gewoon dezelfde gebrekkige processen blijven volgen zonder te beseffen dat een paar eenvoudige maatregelen dingen gemakkelijk kunnen oplossen.
Laten we er verder op ingaan en ze allemaal in detail bespreken:
# 1) Samengestelde stappen
Allereerst, wat is een samengestelde stap?
U geeft bijvoorbeeld aanwijzingen van punt A naar punt B: als u zegt: 'Ga naar XYZ-plaats en dan naar ABC', zal dit niet logisch zijn, want hier denken we: 'Hoe kan ik ga in de eerste plaats naar XYZ ”- in plaats daarvan te beginnen met“ Sla vanaf hier linksaf en ga 1 mijl, en sla dan rechtsaf op Rd. nr. 11 om bij XYZ te komen ”zou betere resultaten kunnen opleveren.
Precies dezelfde regels zijn ook van toepassing op tests en de bijbehorende stappen.
Bijvoorbeeld Ik schrijf een test voor Amazon.com - plaats een bestelling voor elk product.
De volgende zijn mijn teststappen (Opmerking: ik schrijf alleen de stappen en niet alle andere delen van de test zoals het verwachte resultaat enz.)
naar Lancering Amazon.com
b Zoek naar een product door het trefwoord / de productnaam in te voeren in het veld 'Zoeken' bovenaan het scherm.
c Kies de eerste uit de weergegeven zoekresultaten.
d Klik op Toevoegen aan winkelwagen op de pagina met productdetails.
is Afrekenen en betalen.
f Kijk op de orderbevestigingspagina.
Nu, kunt u bepalen welke van deze een samengestelde stap is? Right-Step (e)
Onthoud dat tests altijd gaan over 'hoe' te testen, dus het is belangrijk om de exacte stappen van 'afrekenen en betalen' in uw test te noteren.
Daarom is het bovenstaande geval effectiever wanneer het wordt geschreven zoals hieronder:
naar Lancering Amazon.com
b Zoek naar een product door het trefwoord / de productnaam in te voeren in het veld 'Zoeken' bovenaan het scherm.
c Kies de eerste uit de weergegeven zoekresultaten.
d Klik op Toevoegen aan winkelwagen op de pagina met productdetails.
is Klik op Afrekenen op de winkelwagenpagina.
f Voer de CC-gegevens, verzend- en factuurgegevens in.
g Klik op Afrekenen.
h Kijk op de orderbevestigingspagina.
Daarom is een samengestelde stap degene die kan worden opgesplitst in verschillende afzonderlijke stappen. Laten we de volgende keer dat we tests schrijven allemaal aandacht besteden aan dit deel en ik weet zeker dat u het met me eens zult zijn dat we dit vaker doen dan we ons realiseren.
# 2) Applicatiegedrag wordt beschouwd als verwacht gedrag
Steeds meer projecten hebben tegenwoordig te maken met deze situatie.
Gebrek aan documentatie, extreme programmering en snelle ontwikkelingscycli zijn enkele redenen die ons dwingen te vertrouwen op de applicatie (een oudere versie of zo) om de tests te schrijven of om de tests zelf te baseren. Zoals altijd is dit een bewezen slechte gewoonte, niet altijd echt.
Het is onschadelijk zolang u een open geest houdt en de verwachting houdt dat de - 'AUT mogelijk gebrekkig is'. Alleen als je denkt dat het niet zo is, werken de dingen slecht. Zoals altijd laten we de voorbeelden spreken.
Als het volgende de pagina is waarvoor u de teststappen schrijft / ontwerpt:
Zaak 1:
Als mijn testcase-stappen zijn zoals hieronder:
- Start de winkelsite.
- Klik op Verzenden en retourneren - Verwacht resultaat: De pagina Verzenden en retourneren wordt weergegeven met 'Plaats hier uw info' en een knop 'Doorgaan'.
Dit is dan onjuist.
Geval 2:
- Start de winkelsite.
- Klik op Verzenden en retourneren.
- Voer in het tekstvak ‘Voer het bestelnummer in’ in dat aanwezig is in dit scherm het bestelnummer in.
- Klik op Doorgaan - Verwacht resultaat: de details van de bestelling met betrekking tot verzending en retouren worden weergegeven.
Case 2 is een betere testcase, want hoewel de referentietoepassing zich niet correct gedraagt, nemen we deze alleen als richtlijn, doen we verder onderzoek en schrijven we het verwachte gedrag volgens de verwachte correcte functionaliteit.
Bottom line: Toepassing als referentie is een snelle snelkoppeling, maar het heeft zijn eigen gevaren. Zolang we voorzichtig en kritisch zijn, levert het verbluffende resultaten op.
# 3) Meerdere voorwaarden in één geval
Nogmaals, laten we ervan leren Voorbeeld
Bekijk de onderstaande teststappen: Hieronder staan de teststappen binnen één test voor een inlogfunctie.
een. Voer geldige gegevens in en klik op Verzenden.
b. Laat het veld Gebruikersnaam leeg. Klik op Verzenden.
c. Laat het wachtwoordveld leeg en klik op Verzenden.
d. Kies een reeds aangemelde gebruikersnaam / wachtwoord en klik op Verzenden.
Wat 4 verschillende gevallen moesten zijn, wordt gecombineerd tot één. Je denkt misschien: wat is daar mis mee? Het bespaart veel documentatie en wat ik kan doen in 4, ik doe het in 1, is niet zo geweldig? Nou, niet helemaal. Redenen?
Lees verder:
- Wat als een van de voorwaarden faalt - we moeten de hele test markeren als 'mislukt'. Als we de hele casus ‘mislukt’ markeren, betekent dit dat alle vier de voorwaarden niet werken, wat niet echt waar is.
- Tests moeten een stroom hebben. Van voorwaarde tot stap 1 en doorheen de stappen. Als ik dit geval volg, in stap (a), als het lukt, word ik ingelogd op de pagina waar de 'login' -optie niet langer beschikbaar is. Dus als ik bij stap (b) kom - waar gaat de tester de gebruikersnaam invoeren? Zie je, de stroom is verbroken.
Vandaar, modulaire tests schrijven Het klinkt als een hoop werk, maar je hoeft alleen maar dingen te scheiden en onze beste vrienden Ctrl + C en Ctrl + V te gebruiken om voor ons te werken.
Hoe u de efficiëntie van testcases kunt verbeteren
De softwaretesters moeten hun tests schrijven vanuit de eerdere fase van de levenscyclus van softwareontwikkeling, het beste tijdens de fase van softwarevereisten.
De testmanager of een QA-manager moet de maximaal mogelijke documenten verzamelen en voorbereiden volgens de onderstaande lijst.
hoe bestanden te openen met java
Documentverzameling voor het schrijven van tests
# 1) Document met gebruikersvereisten
Het is een document dat het bedrijfsproces, gebruikersprofielen, gebruikersomgeving, interactie met andere systemen, vervanging van bestaande systemen, functionele vereisten, niet-functionele vereisten, licentie- en installatievereisten, prestatie-eisen, beveiligingseisen, bruikbaarheid en gelijktijdige vereisten, enz. Vermeldt. .,
# 2) Case-document voor zakelijk gebruik
Dit document beschrijft de use case scenario van de functionele eisen vanuit zakelijk perspectief. Dit document behandelt de bedrijfsactoren (of het systeem), doelen, randvoorwaarden, postvoorwaarden, basisstroom, alternatieve stroom, opties, uitzonderingen van elke bedrijfsstroom van het systeem onder vereisten.
# 3) Document met functionele vereisten
Dit document beschrijft de functionele vereisten van elke functie voor het systeem onder vereisten.
Normaal gesproken dient het document met functionele vereisten als een gemeenschappelijke opslagplaats voor zowel het ontwikkel- en testteam als voor de belanghebbenden van het project, inclusief de klanten, voor de toegewijde (soms bevroren) vereisten, die moeten worden behandeld als het belangrijkste document voor elke softwareontwikkeling.
# 4) Softwareprojectplan (optioneel)
Een document dat de details van het project, doelstellingen, prioriteiten, mijlpalen, activiteiten, organisatiestructuur, strategie, voortgangsbewaking, risicoanalyse, aannames, afhankelijkheden, beperkingen, opleidingseisen, verantwoordelijkheden van de klant, projectplanning enz. Beschrijft,
# 5) QA / testplan
Dit document beschrijft het kwaliteitsmanagementsysteem, documentatiestandaarden, wijzigingscontrolemechanisme, kritische modules en functionaliteiten, configuratiemanagementsysteem, testplannen, defecttracering, acceptatiecriteria enz.
De testplan document wordt gebruikt om de functies te identificeren die moeten worden getest, functies die niet moeten worden getest, testteamtoewijzingen en hun interface, resourcevereisten, testschema, testschrijven, testdekking, testresultaten, vereiste voor testuitvoering, bugrapportage en tracking mechanisme, teststatistieken enz.,
Echt voorbeeld
Laten we eens kijken hoe we efficiënt testcases kunnen schrijven voor een bekend en eenvoudig ‘Login’ -scherm, zoals in de onderstaande afbeelding. De aanpak van testen zal bijna hetzelfde zijn, zelfs voor complexe schermen met meer informatie en kritieke functies.
# 1) De eerste benadering voor elk testproces is om een schermprototype (of draadframes) te krijgen zoals hierboven, indien beschikbaar. Dit is mogelijk niet beschikbaar voor sommige functionaliteiten en hangt af van het belang van het ontwerpen van een prototype in de eerdere ontwikkelingsstadia.
Maar als een SRS (Specificatie softwarevereisten) document beschikbaar is voor het project, worden de meeste schermprototypes ontwikkeld door het projectteam. Dit soort scherm vereenvoudigt het werk van de tester en verhoogt de efficiëntie van tests.
#twee) Vervolgens de functionele eisen specificaties Het hangt af van het organisatieproces, het zal beschikbaar zijn in een reeks van meerdere documenten.
Bepaal dus het beste document voor het schrijven van cases, of het kan een gebruikersvereisten document zijn of een functionele vereisten specificatie (of zelfs een SRS-document als het gemakkelijk begrijpelijk kan zijn voor het testteam) dat een volledige functionele stroom van de geselecteerde zal geven. functie die moet worden getest.
# 3) Zodra het schermprototype en de functionele specificaties aanwezig zijn, moet de tester beginnen met het schrijven van de cases met de volgende aanpak en criteria.
- UI-tests De bedieningselementen / velden die zichtbaar zijn voor de gebruiker. Er zijn statische controle en dynamische controles beschikbaar voor de functie die moet worden getest. Bijvoorbeeld in het bovenstaande inlogscherm zijn de ‘Gebruikersnaam & Wachtwoord’ -teksten statische velden die geen gebruikersinteractie vereisen, alleen om de tekst weer te geven.
- Functionele gevallen Aan de andere kant zijn de aanmeldknop en de hyperlinks (Wachtwoord vergeten? & Registratie) dynamische velden die gebruikersinteractie vereisen door op de bedieningselementen te klikken, die daarna enige actie zullen ondernemen.
- Databasecases Zodra de gebruiker de gebruikersnaam en het wachtwoord invoert, kunnen de tests worden geschreven om de gerelateerde database te controleren, of de gebruikersnaam en het wachtwoord zijn gecontroleerd in de juiste database en tabel en ook heeft de gebruiker toestemming om in te loggen op de te testen applicatie.
- Procestests Dit houdt verband met het proces (niet de acties die zijn gekoppeld aan de zichtbare bedieningselementen die beschikbaar zijn op het scherm) dat is gekoppeld aan de functie en de functionaliteit. Bijvoorbeeld Als u op de link Wachtwoord vergeten in het bovenstaande voorbeeldscherm klikt, kan een e-mail naar de gebruiker worden verzonden. Dus misschien moet een e-mail worden getest op het juiste proces en bevestiging.
4) Houd ten slotte de “ BAOE mantra ', middelen i) Basisstroom ii) Alternatieve stroom iii) Opties en iv) Uitzonderingen voor de volledige dekking van de functionele stroom en de te testen functie. Elk concept moet worden toegepast op positieve en negatieve tests.
Bijvoorbeeld Laten we eens kijken naar de eenvoudige BAOE-benadering voor het bovenstaande voorbeeldinlogscherm.
- Basisstroom: Voer het URL-pad van de login in een willekeurige browser in en voer de vereiste informatie in en log in op de applicatie.
- Alternatieve stroom: Installeer de applicatie op een mobiel apparaat en voer de vereiste informatie in en log in op de applicatie.
- Opties: Welke opties zijn beschikbaar om naar hetzelfde inlogscherm te gaan? Bijvoorbeeld na het inloggen op de applicatie, kan het klikken op ‘Uitloggen’ hetzelfde scherm openen of als de sessietime-out of sessie is verlopen, kan de gebruiker naar het inlogscherm gaan.
- Uitzonderingen: Wat zijn uitzonderingen als mijn tests negatief zijn? Bijvoorbeeld als er verkeerde inloggegevens worden ingevoerd in het aanmeldingsscherm, of de gebruiker een foutmelding krijgt of geen bijbehorende actie.
Met al deze informatie bij de hand, kunnen we beginnen met het schrijven van de TC's voor het inlogscherm, in een formaat met volledige dekking en traceerbaarheid en met gedetailleerde informatie. De logische volgorde en nummering van het identificeren van de ‘ Testcase-ID ’ zal erg handig zijn voor een snelle identificatie-uitvoeringsgeschiedenis van testgevallen.
Lees ook 180+ voorbeelden gebruiksklare testcases voor web- en desktopapplicaties.
Test Case Document
Opmerking : De testkolommen zijn niet beperkt tot het onderstaande voorbeeldtestdocument, dat kan worden bijgehouden in een Excel-sheet om zoveel kolommen te hebben als nodig is voor een volledige traceerbaarheidsmatrix, namelijk prioriteit, testdoel, type test, fout screenshot locatie enz.,
Lees ook Voorbeeldtestcase-sjabloon met voorbeelden.
Laten we voor het gemak en de leesbaarheid van dit document de stappen beschrijven om het verwachte en werkelijke gedrag van de tests voor het inlogscherm hieronder in detail te reproduceren.
Opmerking : Kolom Werkelijk gedrag toevoegen aan het einde van deze sjabloon.
Niet doen. | Stappen om te reproduceren | Verwacht gedrag |
---|---|---|
7. | Klik op de registratielink | Als u op de link klikt, moet de gebruiker naar het gerelateerde scherm gaan. |
1. | Open een browser en voer de URL voor het inlogscherm in. | Het aanmeldingsscherm moet worden weergegeven. |
twee. | Installeer de app op een Android-telefoon en open deze. | Het aanmeldingsscherm moet worden weergegeven. |
3. | Open het inlogscherm en controleer of de beschikbare teksten correct zijn gespeld. | ‘Gebruikersnaam’ en ‘Wachtwoord’ tekst moeten vóór het gerelateerde tekstvak worden weergegeven. De aanmeldingsknop moet het bijschrift ‘Inloggen’ hebben. ‘Wachtwoord vergeten?’ En ‘Registratie’ zouden beschikbaar moeten zijn als links. |
Vier. | Typ de tekst in het veld Gebruikersnaam. | Tekst kan worden ingevoerd door muisklik of focus met tab. |
5. | Typ de tekst in het veld Wachtwoord. | Tekst kan worden ingevoerd door muisklik of focus met tab. |
6. | Klik op Wachtwoord vergeten? Koppeling. | Als u op de link klikt, moet de gebruiker naar het gerelateerde scherm gaan. |
8. | Voer de gebruikersnaam en het wachtwoord in en klik op de knop Inloggen. | Als u op de knop Login klikt, gaat u naar het gerelateerde scherm of de applicatie. |
9. | Ga naar de database en controleer of de juiste tabelnaam is gevalideerd met de invoergegevens. | De tabelnaam moet worden gevalideerd en een statusvlag moet worden bijgewerkt voor succesvol of mislukt aanmelden. |
10. | Klik op Aanmelden zonder tekst in de vakken Gebruikersnaam en Wachtwoord in te voeren. | Als u op de knop Inloggen klikt, wordt een berichtvenster weergegeven ‘Gebruikersnaam en wachtwoord zijn verplicht’. |
elf. | Klik op Aanmelden zonder tekst in het vak Gebruikersnaam in te voeren, maar tekst in het vak Wachtwoord in te voeren. | Klik op de Login-knop om een berichtvenster te laten verschijnen ‘Wachtwoord is verplicht’. |
12. | Klik op Aanmelden zonder tekst in het vak Wachtwoord in te voeren, maar tekst in het vak Gebruikersnaam in te voeren. | Als u op de knop Inloggen klikt, wordt een berichtvenster weergegeven ‘Gebruikersnaam is verplicht’. |
13. | Typ de maximaal toegestane tekst in de velden Gebruikersnaam en wachtwoord. | Moet de maximaal toegestane 30 tekens accepteren. |
14. | Voer de gebruikersnaam en het wachtwoord in, te beginnen met de speciale tekens. | Moet de tekst die begint met speciale tekens niet accepteren, wat niet is toegestaan in Registratie. |
vijftien. | Voer de gebruikersnaam en het wachtwoord in, te beginnen met spaties. | Moet de tekst met lege spaties niet accepteren, wat niet is toegestaan in Registratie. |
16. | Typ de tekst in het wachtwoordveld. | Als de werkelijke tekst niet wordt weergegeven, moet het asterisk-symbool * worden weergegeven. |
17. | Vernieuw de aanmeldingspagina. | De pagina moet worden vernieuwd met lege velden voor gebruikersnaam en wachtwoord. |
18. | Voer de gebruikersnaam in. | Afhankelijk van de instellingen voor automatisch invullen van de browser, moeten eerder ingevoerde gebruikersnamen worden weergegeven als een vervolgkeuzelijst. |
19. | Voer het wachtwoord in. | Afhankelijk van de instellingen voor automatisch invullen van de browser, mogen eerder ingevoerde wachtwoorden NIET als vervolgkeuzelijst worden weergegeven. |
twintig. | Verplaats de focus naar Wachtwoord vergeten link met Tab. | Zowel muisklik als enter-toets moeten bruikbaar zijn. |
eenentwintig. | Verplaats de focus naar de registratielink met Tab. | Zowel muisklik als enter-toets moeten bruikbaar zijn. |
22. | Vernieuw de aanmeldingspagina en druk op de Enter-toets. | De inlogknop moet worden gefocust en de gerelateerde actie moet worden geactiveerd. |
2. 3. | Vernieuw de aanmeldingspagina en druk op de Tab-toets. | De eerste focus in het aanmeldingsscherm moet het veld Gebruikersnaam zijn. |
24. | Voer de gebruiker en het wachtwoord in en laat de aanmeldingspagina 10 minuten inactief. | Berichtvensterwaarschuwing ‘Sessie verlopen, voer gebruikersnaam en wachtwoord opnieuw in’ moet worden weergegeven met de velden Gebruikersnaam en wachtwoord leeg. |
25. | Voer de inlog-URL in de browsers Chrome, Firefox en Internet Explorer in. | Hetzelfde aanmeldingsscherm moet worden weergegeven zonder veel afwijking op het uiterlijk en de uitlijning van tekst- en formulierbesturingen. |
26. | Voer de inloggegevens in en controleer de inlogactiviteit in de browsers Chrome, Firefox en Internet Explorer. | De actie van de Login-knop moet in alle browsers hetzelfde zijn. |
27. | Controleer of de link Wachtwoord vergeten en registratie niet verbroken is in de browsers Chrome, Firefox en Internet Explorer. | Beide links moeten naar de relatieve schermen in alle browsers gaan. |
28. | Controleer of de aanmeldingsfunctionaliteit correct werkt op mobiele Android-telefoons. | De aanmeldingsfunctie zou op dezelfde manier moeten werken als deze beschikbaar is in de webversie. |
29. | Controleer of de inlogfunctionaliteit correct werkt in Tab en iPhones. | De aanmeldingsfunctie zou op dezelfde manier moeten werken als deze beschikbaar is in de webversie. |
30. | Controleer of het aanmeldingsscherm de gelijktijdige gebruikers van het systeem en alle gebruikers het aanmeldingsscherm zonder vertragingen en binnen de gedefinieerde tijd van 5-10 seconden laat zien. | Dit moet worden bereikt met behulp van veel combinaties van besturingssysteem en browsers, fysiek of virtueel, of kan worden bereikt met behulp van een prestatie- / belastingtesttool. |
Test gegevensverzameling
Wanneer de testcase wordt geschreven, is de belangrijkste taak voor elke tester het verzamelen van de testgegevens. Deze activiteit wordt door veel testers overgeslagen en over het hoofd gezien, in de veronderstelling dat de testgevallen kunnen worden uitgevoerd met enkele voorbeeldgegevens of dummy-gegevens en kunnen worden ingevoerd wanneer de gegevens echt nodig zijn. Dit is een kritische misvatting dat het invoeren van voorbeeldgegevens of invoergegevens uit het geheugen van de geest tijdens het uitvoeren van testgevallen.
Als de gegevens niet worden verzameld en bijgewerkt in het testdocument op het moment dat de tests worden geschreven, zou de tester abnormaal meer tijd besteden aan het verzamelen van de gegevens op het moment dat de test wordt uitgevoerd. De testgegevens moeten worden verzameld voor zowel positieve als negatieve gevallen vanuit het hele perspectief van de functionele stroom van de functie. Het business use case document is in deze situatie erg handig.
Zoek een voorbeeld van een testgegevensdocument voor de hierboven beschreven tests, die op hun beurt weer nuttig zullen zijn om te zien hoe effectief we de gegevens kunnen verzamelen die ons werk op het moment van testuitvoering vergemakkelijken.
Ja nee | Doel van testgegevens | Werkelijke testgegevens |
---|---|---|
7. | Test de gebruikersnaam en het wachtwoord met allemaal kleine tekens | beheerder (admin2015) |
1. | Test de juiste gebruikersnaam en wachtwoord | Beheerder (admin2015) |
twee. | Test de maximale lengte van gebruikersnaam en wachtwoord | Beheerder van het hoofdsysteem (admin2015admin2015admin2015admin) |
3. | Test de lege ruimtes voor de gebruikersnaam en het wachtwoord | Voer lege spaties in met de spatiebalk voor gebruikersnaam en wachtwoord |
Vier. | Test de onjuiste gebruikersnaam en wachtwoord | Admin (geactiveerd) (digx ## $ taxk209) |
5. | Test de gebruikersnaam en het wachtwoord met ongecontroleerde spaties ertussen. | Beheerder (admin 2015) |
6. | Test de gebruikersnaam en het wachtwoord, beginnend met speciale tekens | $% # @ # $ Beheerder (% # * # ** # admin) |
8. | Test de gebruikersnaam en het wachtwoord met hoofdletters | ADMINISTRATOR (ADMIN2015) |
9. | Test de login met dezelfde gebruikersnaam en wachtwoord met meerdere systemen tegelijk. | Administrator (admin2015) - voor Chrome op dezelfde machine en een andere machine met besturingssysteem Windows XP, Windows 7, Windows 8 en Windows Server. Administrator (admin2015) - voor Firefox op dezelfde machine en een andere machine met besturingssysteem Windows XP, Windows 7, Windows 8 en Windows Server. Administrator (admin2015) - voor Internet Explorer op dezelfde machine en een andere machine met besturingssysteem Windows XP, Windows 7, Windows 8 en Windows Server. |
10. | Test de login met de gebruikersnaam en het wachtwoord in de mobiele applicatie. | Administrator (admin2015) - voor Safari en Opera in Android Mobiles, iPhones en tablets. |
Belang van standaardisering van de testcases
In deze drukke wereld kan niemand dag in dag uit repetitieve dingen doen met dezelfde interesse en energie. Vooral ben ik niet gepassioneerd om dezelfde taak keer op keer op het werk te doen. Ik hou ervan om dingen te beheren en tijd te besparen. Iedereen in IT zou zo moeten zijn.
Alle IT-bedrijven voeren verschillende soorten projecten uit. Deze projecten kunnen zowel productgebaseerd als servicegebaseerd zijn. Van deze projecten werken de meeste rond websites en website testen Het goede nieuws is dat alle websites veel overeenkomsten hebben. En als de websites voor hetzelfde domein zijn, hebben ze ook verschillende gemeenschappelijke kenmerken.
De vraag die me altijd verbijstert is: “Als de meeste applicaties vergelijkbaar zijn, bijvoorbeeld: zoals winkelsites, die al duizend keer eerder zijn getest:” Waarom moeten we vanaf nul testcases schrijven voor weer een andere winkelsite? ' Bespaart het niet veel tijd door de bestaande testscripts te verwijderen die werden gebruikt om een eerdere winkelsite te testen?
Natuurlijk zijn er misschien enkele kleine aanpassingen die we moeten doen, maar over het algemeen is het gemakkelijker, efficiënter, bespaart het ook tijd en geld en helpt het daardoor altijd om de interesse van de testers hoog te houden. Wie vindt het leuk om dezelfde testcases herhaaldelijk te schrijven, beoordelen en onderhouden, toch? Hergebruik van de bestaande tests kan dit voor een groot deel oplossen en uw klanten zullen dit ook slim en logisch vinden.
Logischerwijs begon ik de bestaande scripts uit vergelijkbare webgebaseerde projecten te halen, wijzigingen aan te brengen en ze snel te herzien. Ik heb ook kleurcodering gebruikt om de aangebrachte wijzigingen weer te geven, zodat de recensent zich alleen kan concentreren op het gedeelte dat is gewijzigd.
Redenen om testcases te hergebruiken
# 1) De meeste functionele gebieden van een website zijn bijna: inloggen, registreren, toevoegen aan winkelwagentje, verlanglijstje, afrekenen, verzendopties, betalingsopties, inhoud van productpagina's, recent bekeken, relevante producten, promocodefaciliteiten enz.
#twee) De meeste projecten zijn slechts verbeteringen of wijzigingen in de bestaande functionaliteit.
# 3) Contentbeheersystemen die de slots voor het uploaden van afbeeldingen op statische en dynamische manieren definiëren, zijn ook gebruikelijk voor alle websites.
# 4) Retailwebsites hebben CSR (Klantenservice) systeem ook.
# 5) Backend-systeem en magazijnapplicatie die JDA gebruiken, worden ook door alle websites gebruikt.
# 6) Het concept van cookies, time-out en beveiliging zijn ook gebruikelijk.
# 7) Webgebaseerde projecten zijn vaak onderhevig aan wijzigingen in de vereisten.
# 8) De soorten testen nodig zijn gebruikelijk zoals browser compatibiliteitstesten prestatie testen beveiligingstesten
Zie je, er is genoeg dat gebruikelijk en vergelijkbaar is.
Dat gezegd hebbende, is herbruikbaarheid de beste keuze, soms vergen de aanpassingen zelf al dan niet meer of minder tijd. Soms denkt men misschien dat het beter is om helemaal opnieuw te beginnen dan zoveel te wijzigen.
Dit kan eenvoudig worden afgehandeld door een set standaardtestcases te maken voor elk van de algemene functionaliteit.
Wat is een standaardtest bij webtests?
- Maak testcases die compleet zijn - stappen, gegevens, variabele, etc. Dit zorgt ervoor dat de niet-vergelijkbare data / variabele eenvoudig kan worden vervangen wanneer een vergelijkbare testcase vereist is.
- De ingangs- en uitgangscriteria moeten correct worden gedefinieerd.
- De aanpasbare stappen of de verklaring in de stappen moeten in een andere kleur worden gemarkeerd voor snel zoeken en vervangen.
- De taal die wordt gebruikt voor het maken van de standaardtestcase moet algemeen zijn.
- Alle functies van elke website moeten in de testcases worden behandeld.
- De naam van de testcases moet de naam zijn van de functionaliteit of de functie die de testcase behandelt. Dit maakt het vinden van de testcase uit de set veel gemakkelijker.
- Als er een basis- of standaardvoorbeeld of GUI-bestand of schermafbeelding van de functie is, moet deze worden bijgevoegd met de relevante stappen.
Door gebruik te maken van bovenstaande tips kan men een set standaardscripts maken en deze met weinig of noodzakelijke aanpassingen gebruiken voor verschillende websites.
Ook deze standaard testcases zijn te automatiseren, maar opnieuw focussen op herbruikbaarheid is altijd een pluspunt. Ook als automatisering is gebaseerd op een GUI, hergebruik van de scripts op meerdere URL's of sites is iets dat ik persoonlijk nooit effectief heb gevonden.
Het gebruik van een standaardset handmatige testcases voor verschillende websites met kleine aanpassingen is de beste manier om een website te testen. Alles wat we nodig hebben, is het maken en onderhouden van de testcases met de juiste normen en gebruik.
Gevolgtrekking
Het verbeteren van de efficiëntie van testcases is niet een eenvoudig gedefinieerde term, maar het is een oefening en kan worden bereikt door middel van een volwassen proces en regelmatig oefenen.
Het testteam moet niet moe zijn om betrokken te raken bij de verbetering van dergelijke taken, aangezien het de beste tool is voor grotere prestaties in de kwaliteitswereld, dit is bewezen in veel van de testorganisaties wereldwijd bij missiekritieke projecten en complexe applicaties.
Ik hoop dat je een enorme kennis zou hebben opgedaan over het concept van testcases. Bekijk onze reeks tutorials om meer te weten te komen over testcases en voel je vrij om je mening te geven in de comments hieronder!
Aanbevolen literatuur
- Functioneel testen versus niet-functioneel testen
- Gids voor het testen van draagbaarheid met praktische voorbeelden
- Soorten softwaretests: verschillende testtypen met details
- Beste softwaretesttools 2021 [QA Test Automation Tools]
- Alfatesten en bètatesten (een complete gids)
- Wat is systeemtesten - een ultieme beginnershandleiding
- ISTQB-testcertificering Voorbeeldvragen met antwoorden
- Een wekelijks statusrapport voor softwaretests schrijven