Inleiding tot bug bij het testen van software
Een eenvoudige bug is een fout of een storing in een toepassing die de normale stroom van een toepassing verhindert door het beoogde gedrag van een toepassing niet in overeenstemming te brengen met de daadwerkelijke toepassing. De fout treedt op wanneer een ontwikkelaar een fout maakt tijdens het ontwerpen of bouwen van een applicatie. Als een tester deze fout detecteert, wordt dit een bug genoemd bij het testen van software. Een tester is verantwoordelijk voor het grondig testen van een applicatie om zoveel mogelijk defecten te identificeren zodat een kwalitatief product de klant bereikt. Totdat u naar de workflow en verschillende toestanden van het defect gaat, is het belangrijk om het proces van tekortkoming te begrijpen.
Levenscyclus van fouten bij het testen van software
De Bug Life-cyclus wordt ook wel een Defect Life-cyclus genoemd. Het is een fase van een defect dat de verschillende toestanden tijdens zijn levensduur bezet. Het begint wanneer een testapparaat een nieuw defect vindt en eindigt wanneer het testapparaat dat defect verwijdert en er voor wordt gezorgd dat het defect niet wordt gerepliceerd. Het is nu tijd om, via een basisschema zoals hieronder getoond, de ware workflow van een defectlevenscyclus te begrijpen.
Hieronder is het diagram van de levenscyclus van de bugs:
Status van bug
Laten we elk onderdeel van de levenscyclus van bugs bekijken.
1. Openen
De programmeur begint hier waar mogelijk met het analyseproces van de bugs en werkt aan reparatie. Als het programmeerapparaat denkt dat het defect niet voldoende is, kan een fout, afhankelijk van de specifieke reden, worden doorgegeven aan de volgende vier toestanden, Weigeren of Niet, namelijk Dupliceren.
2. Nieuw
Dit is de eerste status van bugclassificatie in de levenscyclus van de bugs. In de latere fasen van de buglevenscyclus worden deze bugs gevalideerd en getest als er een nieuw defect wordt ontdekt.
3. Toegewezen
Het ontwikkelteam krijgt een nieuw gecreëerde fout toegewezen voor het werken op de fout op dit niveau. Dit wordt gedelegeerd aan een ontwerper door de projectleider of de baas van het team.
4. In afwachting van hertest
Nadat het defect is verholpen, geeft de ontwerper de tester de fout om de fout opnieuw te testen en blijft de status van het defect in afwachting van de nieuwe test totdat de tester de fout opnieuw test.
5. Vast
Als de ontwikkelaar de taak van het repareren van een defect voltooit door de nodige wijzigingen aan te brengen, kan de defectstatus 'Vast' worden genoemd.
6. Geverifieerd
Als de tester geen probleem heeft met het defect nadat de ontwerper het defect is toegewezen aan het testapparaat en dacht dat als het correct werd gerepareerd, de defectstatus wordt toegewezen als "bevestigd".
7. Opnieuw openen
Als er nog steeds een probleem met de fout is, wordt het programmeerapparaat geïnstrueerd om het opnieuw te controleren en wordt de defectstatus opnieuw geopend.
8. Gesloten
Als het defect afwezig is, verandert de tester de status van het defect in 'Gesloten'.
9. Opnieuw testen
De tester begint vervolgens met het opnieuw testen van het defect om te controleren of het defect correct is verholpen door de ontwikkelaar zoals vereist door de vereiste.
10. Dupliceren
Als de ontwikkelaar het defect als een ander defect beschouwt, of als de definitie van het defect overgaat in een ander defect, wordt de status van het defect door de ontwikkelaar gewijzigd in 'dupliceren'.
Parameter van Bug in Software Testing
- Datum van afgifte, goedkeuringen, auteur en status.
- Ernst en prioriteit van incidenten.
- De testcase die het probleem liet zien.
- Incidentdefinitie met reproductieve stappen.
Richtlijnen voor implementatie van de Deficiency Life Cycle
- Het hele team moet de verschillende omstandigheden van een bug duidelijk begrijpen voordat het onderzoek naar de defectlevenscyclus begint.
- Om verwarring in de toekomst te voorkomen, moet de defectlevenscyclus correct worden gedocumenteerd.
- Zorg ervoor dat elke persoon met een taak in verband met de standaardlevenscyclus zijn / haar verantwoordelijkheid voor betere resultaten heel duidelijk begrijpt.
- Elke persoon die de status van een defect wijzigt, moet de status goed kennen, die voldoende informatie moet geven over de status van een defect en de reden ervoor, zodat iedereen die aan dat defect werkt, gemakkelijk de reden voor het defect kan zien.
- Het hulpmiddel voor het volgen van defecten moet met zorg worden behandeld in de workflow van de levenscyclus van het defect om consistentie tussen de defecten te waarborgen.
Conclusie
Ik hoop dat je enige kennis hebt van de levenscyclus van een defect. Dit artikel helpt u ook in de toekomst handig als u met softwarefouten omgaat.
Aanbevolen artikelen
Dit is een gids voor Wat is een fout in het testen van software. Hier bespreken we de levenscyclus van een bug, status, parameter en begeleiding. U kunt ook onze andere gerelateerde artikelen doornemen voor meer informatie -
- Software testen levenscyclus
- Wat is softwaretesten?
- Soorten softwaretests
- Defecte levenscyclus bij het testen van software