Geen software kan ooit perfect zijn. Maar is dat een vergunning om afval te maken? Het ontbrekende ingrediënt is onze terughoudendheid om de kwaliteit te kwantificeren. Om de kwaliteit te verhogen, is het zeer belangrijk om de effectieve prestaties van software-applicatie te waarborgen. Software testen is vereist om ervoor te zorgen dat de toepassing loopt zonder storingen. In deze Software Testing tutorial, zal ik je alles wat je moet weten over het testen van aspecten vertellen. In vervolg op de vorige blog over wat is software testen, hier zal ik dieper duiken en de hieronder genoemde onderwerpen te behandelen.
- Inleiding tot het Testen van Software
- Software Testen Basis
- Software Development Life Cycle
- Verificatie en Validatie Model
- Software testmethoden
- Software Testen Niveaus
- het Testen van Software Artefacten Documentatie
- Bug Life Cycle
- Uitdagingen van Handmatig Testen
- Automatisering van het Testen versus Handmatige Testen
U kunt ook gaan door de opname van het testen van software tutorial waar onze Software Testing Training experts hebben verklaard de concepten diepgaand.
Software testen handleiding voor Beginners / handleiding & automatiseringstests
in deze video wordt gesproken over verschillende soorten testen, d.w.z. handmatige tests en automatiseringstests.
Inleiding tot het testen van Software
de huidige wereld van de technologie wordt volledig gedomineerd door machines, en hun gedrag wordt gecontroleerd door de software die het aandrijft. Software testen biedt een kosteneffectieve oplossing voor al onze zorgen. Wat is Software testen? Software testen is een proces van het evalueren van de functionaliteit van een software applicatie om eventuele software bugs te vinden. Het controleert of de ontwikkelde software aan de gespecificeerde eisen voldoet en identificeert elk defect in de software om een kwaliteitsproduct te bereiken. Het is in principe het uitvoeren van een systeem om eventuele hiaten, fouten, of ontbrekende eisen in strijd met de werkelijke eisen te identificeren.
het wordt ook vermeld als het proces van het verifiëren en valideren van een software product. Het controleert of het softwareproduct:
- voldoet aan de zakelijke en technische vereisten die het ontwerp en de ontwikkeling hebben geleid
- werken volgens de eis
- kunnen met dezelfde kenmerken worden geïmplementeerd
nu, laten we verder gaan in de Software Testing tutorial artikel en krijgen een aantal inzichten over de basisprincipes van Software testen.
Software Testing Basics
eerst zal ik u vertellen wat de levenscyclus van de softwareontwikkeling is?
Software Development Life Cycle
(SDLC), afgekort als Software Development Life Cycle, is een proces dat door de software-industrie wordt gebruikt voor het ontwerpen, ontwikkelen en testen van hoogwaardige software. Het is gericht op het produceren van hoogwaardige software die voldoet aan of overtreft de verwachtingen van de klant, bereikt voltooiing binnen de tijd en kostenramingen. Onderstaand diagram toont diverse fasen betrokken bij SDLC.
Fig.: Software Development Life Cycle-Software Testing Tutorial
vereiste fase
vereiste verzamelen en analyseren is de belangrijkste fase in de software development lifecycle. Business analist verzamelt de eis van de klant / klant volgens de klanten zakelijke behoeften en documenteert de eisen in de business requirement specificatie (document naam varieert afhankelijk van de organisatie).
analysefase
zodra de vereisten zijn verzameld en geanalyseerd, is de volgende stap het definiëren en documenteren van de productvereisten en deze door de klant laten goedkeuren. Dit wordt vastgelegd door middel van het SRS (Software Requirement Specification) document. Het bestaat uit alle productvereisten die moeten worden ontworpen en ontwikkeld gedurende de levenscyclus van het project
ontwerpfase
Deze fase bestaat uit twee stappen:
- HLD-High-Level Design-het geeft de architectuur van het te ontwikkelen softwareproduct en wordt gedaan door architecten en senior ontwikkelaars
- LLD – Low-Level Design – het wordt uitgevoerd door senior ontwikkelaars. Hier, het geeft u inzicht over hoe elke functie in het product moet werken en hoe elk onderdeel moet werken.
het resultaat van deze fase is het document op hoog niveau en het document op laag niveau dat als input voor de volgende fase werkt.
ontwikkelingsfase
ontwikkelaars van alle niveaus (Senioren, Junioren, freshers) zijn betrokken bij deze fase. Dit is de fase waarin je begint met het bouwen van de code voor de software.
testfase
wanneer de software klaar is, wordt deze naar de testafdeling gestuurd, waar zij de software grondig testen op verschillende defecten. Het testen van een software wordt handmatig of met behulp van geautomatiseerde testtools uitgevoerd en ervoor zorgen dat elk onderdeel van de software werkt prima. Zodra de software foutloos is, gaat het naar de volgende fase, die implementatie is.
implementatie & onderhoudsfase
zodra het product foutloos is, wordt het geleverd / geïmplementeerd aan de klant voor gebruik. De implementatie wordt gedaan door de Deployment/Implementation engineers. Als de klanten beginnen met het ontwikkelde systeem, dan de werkelijke problemen komen en moet worden opgelost van tijd tot tijd. Het opsporen en oplossen van deze problemen gevonden door de klant komt in de onderhoudsfase.
dit ging allemaal over de levenscyclus van softwareontwikkeling. Als u wilt weten over de verschillende stadia die betrokken zijn bij software testing proces, dan kunt u deze blog te lezen op Software Testing Life Cycle. Na dit te hebben begrepen, laten we verder gaan met deze Software testing tutorial en zien wat het v & V model is.
V model is nu een van de meest gebruikte softwareontwikkelingsprocessen. De invoering van het V-model heeft eigenlijk bewezen dat de implementatie van testen vanaf de vereiste fase. Het wordt ook wel als verificatie en validatie model
Wat is verificatie en validatie in Software testen?
verificatie: verificatie is een statische analysetechniek. Hier wordt getest zonder de code uit te voeren. Voorbeelden zijn-reviews, inspectie, en lopen door.
validatie: validatie is een proces van dynamische analyse waarbij we testen uitvoeren door de code uit te voeren. Voorbeelden hiervan zijn functionele en niet-functionele testtechnieken.
in het V-model worden de ontwikkelings-en KWALITEITSBORGINGSACTIVITEITEN gelijktijdig uitgevoerd. Hier begint het testen vanaf de vereiste fase. De verificatie-en valideringsactiviteiten vinden gelijktijdig plaats. Laten we eens kijken naar de onderstaande figuur om te begrijpen V model
in een typisch ontwikkelingsproces toont de linkerkant de ontwikkelingsactiviteiten en de rechterkant toont de testactiviteiten. Het zou niet verkeerd zijn als ik zeg dat in de ontwikkelingsfase zowel verificatie als validatie worden uitgevoerd samen met de eigenlijke ontwikkelingsactiviteiten.
LHS
Zoals eerder vermeld, zijn linksactiviteiten ontwikkelingsactiviteiten. Normaal voelen we, wat testen kunnen we doen in de ontwikkelingsfase? Maar dit is de essentie van dit model dat illustreert dat testen ook in alle ontwikkelingsfasen kan worden gedaan.
RHS
de testactiviteiten of de valideringsfase worden uitgevoerd aan de rechterkant van het model.
aangezien u hier wat inzichten over hebt opgedaan, laten we verder gaan met deze Software testing tutorial en kijken wat de verschillende methoden zijn waarin de software kan worden getest.
testmethoden voor Software
er zijn drie methoden voor het testen van software en deze zijn als volgt::
- Black Box Testing
- White Box Testing
- Grey Box Testing
Black Box Testing: het is een methode voor het testen van software waarbij de interne structuur/ het ontwerp/ de uitvoering van het te testen item niet bekend is bij de tester.
White Box Testing: het is een methode voor het testen van software waarbij de interne structuur/ het ontwerp/ de uitvoering van het te testen item bekend is bij de tester.
Grey Box Testing: het is een testtechniek die wordt uitgevoerd met beperkte informatie over de interne functionaliteit van het systeem.
Ik hoop dat u de belangrijkste aanwijzingen over de verschillende methoden van software testen begrepen. Nu, laten we verder gaan in deze Software Testing Tutorial artikel en begrijpen Software Testen niveaus.
niveaus voor het testen van Software
een niveau voor het testen van software is een proces waarbij elke eenheid of component van een software/systeem wordt getest. Er zijn verschillende testniveaus die helpen om gedrag en prestaties te controleren voor het testen van software. Deze testniveaus zijn ontworpen om ontbrekende gebieden en verzoening tussen de ontwikkeling van levenscyclusstaten te herkennen. In het levenscyclusmodel van de softwareontwikkeling, zijn er kenmerkende fasen zoals vereiste het verzamelen, analyse, ontwerp, codering of uitvoering, het testen, en implementatie.
al deze fasen doorlopen het proces van het testen van software niveaus. Er zijn hoofdzakelijk vier testniveaus en zij zijn:
- Unit Testing
- Integration Testing
- System Testing
- Acceptance Testing
in principe begint het met de Unit Testing fase en eindigt het met Acceptance Testing.
in de volgende sectie van deze Software testing tutorial zal ik dieper ingaan op het volgende onderwerp en uitleggen wat de verschillende documentatie artefacten zijn in software testing.
documentatie voor het testen van Software artefacten
het documenteren van de testgevallen zal u helpen om de testinspanning te schatten die u nodig hebt, samen met de dekking van de test en de vereisten voor tracking en tracing. Sommige algemeen toegepaste documentatie artefacten geassocieerd met software testen zijn:
- testplan
- testscenario
- testcase
- Traceerbaarheidsmatrix
laten we elk van hen in het kort bespreken.
- testplan: het geeft u de algemene strategie die zal worden geïmplementeerd voor het testen van de toepassing.
- testscenario: testscenario kan worden beschouwd als een enkele regel die het gebied aangeeft waarin uw aanvraag zal worden geëxperimenteerd. Dit artefact is nodig voor het waarborgen van de algemene procedure Getest van het begin tot het einde.
- testcase: testcase is niets anders dan een reeks voorwaarden of variabelen waaronder een tester zal bepalen of een te testen systeem voldoet aan de eisen of correct werkt. Hieronder genoemde testgevallen worden gecontroleerd tijdens het testen.
- functionele testgevallen
- negatieve-fouttestgevallen
- logische testgevallen
- fysische testgevallen
- UI-testgevallen
- Traceability Matrix: het is ook bekend als een Requirement Traceability Matrix (RTM). Het bevat een tabel die de vereisten schetst wanneer het SDLC-model van uw product wordt gemaakt. Deze documenterende artefacten kunnen worden toegepast voor voorwaartse het traceren die van het ontwerpen aan het coderen moet gaan of voor achterwaarts het traceren ook kan worden uitgevoerd die het omgekeerde van het voorwaartse het traceren is.
dit brengt ons bij het einde van Software Test documentatie artefacten. Nu, laten we verder gaan in deze Software testen tutorial artikel en leren wat is Defect Management?
Wat is het Defectbeheerproces?
Defectmanagement is een proces om bugs op te sporen en op te lossen. Aangezien bugs deel uitmaken van de software-industrie, komen ze voortdurend voor in het proces van softwareontwikkeling. De teamleden moeten elke dag grote stukjes code schrijven, en ze hebben meestal geen tijd om na te denken over hoe ze bugs kunnen vermijden. Daarom vereist elk softwareontwikkelingsproject een proces dat helpt om de defecten op te sporen en op te lossen.
het Defectbeheerproces wordt uitgevoerd in het stadium van de producttest. Zonder dit te beseffen, zou het moeilijk zijn om de aard van defectmanagement te begrijpen.. Meestal testen de ontwikkelaars hun product zelf. Ook, Er is ook een soort van testen die is gebaseerd op de betrokkenheid van de gebruiker. De eindgebruikers worden vaak voorzien van een mogelijkheid om te rapporteren over de bugs die ze hebben geïdentificeerd. Toch is dit niet de beste manier van testen, omdat de gebruikers niet in staat zijn om alle bugs te vinden.
het defectbeheerproces omvat gewoonlijk vier stappen.
- de eerste stap is het stadium van het detecteren van fouten
- de tweede stap is gewijd aan het opstellen van foutrapporten
- de derde stap is het oplossen van de fout.
- in de laatste stap wordt de bug list aangemaakt
nu, laten we verder gaan in Software testing tutorial artikel en begrijpen het bug detectie proces met behulp van de bug levenscyclus.
levenscyclus van een defect
een levenscyclus van een defect is een proces waarbij een defect gedurende zijn gehele levensduur verschillende fasen doorloopt. Het begint wanneer een defect wordt gevonden en eindigt wanneer een defect wordt gesloten, na ervoor te zorgen dat het niet wordt gereproduceerd. Een defect levenscyclus is gerelateerd aan de bug gevonden tijdens het testen.
De levenscyclus van een Bug of defect omvat de stappen zoals weergegeven in de onderstaande figuur:
- Nieuw: In deze stap, als een defect wordt gelogd en gepost voor de eerste keer, de status wordt gegeven als nieuw.
- toegewezen: nadat de tester de bug heeft geplaatst, keurt de leiding van de tester goed dat de bug echt is en wijst hij de bug toe aan een overeenkomstige ontwikkelaar en het ontwikkelingsteam. Het staat gegeven zoals toegewezen.
- Open: in deze toestand is de ontwikkelaar begonnen met het analyseren en werken aan de foutoplossing.
- opgelost: als de ontwikkelaar de nodige wijzigingen in de code maakt en de wijzigingen verifieert, kan hij / zij de bug-status als ‘opgelost’ maken en wordt de bug doorgegeven aan het testteam.
- Test: in dit stadium test de tester de gewijzigde code die de ontwikkelaar hem heeft teruggegeven om te controleren of het defect al dan niet is verholpen.
- geverifieerd: hier test de tester de bug opnieuw nadat deze door de ontwikkelaar is opgelost. Als er geen bug in de software, hij keurt dat de bug is opgelost en verandert de status naar “geverifieerd”.
- heropenen: in het geval dat de bug nog steeds bestaat, zelfs nadat de bug is opgelost door de ontwikkelaar, verandert de tester de status in “heropend”. In deze toestand gaat de bug opnieuw door de levenscyclus.
- gesloten: zodra de bug is opgelost, wordt deze door de tester getest. In het geval dat de tester van mening is dat de bug niet meer bestaat in de software, verandert hij de status van de bug in “gesloten”. Het impliceert dat de bug is opgelost, getest en goedgekeurd.
- dupliceren: als de bug in de levenscyclus van de bug tweemaal wordt herhaald of als de twee bugs hetzelfde concept van de bug vermelden, wordt de status van één bug gewijzigd in “duplicate”.
- afgewezen: als de ontwikkelaar van mening is dat de bug niet echt is, wijst hij de bug af. Vervolgens wordt de toestand van de bug gewijzigd in”afgewezen”.
- uitgesteld: als de bug wordt gewijzigd in uitgestelde staat betekent dat de bug naar verwachting zal worden opgelost in de volgende releases.
dit ging allemaal over de levenscyclus van de Bug en het Defectbeheerproces. Laten we nu eens kijken wat de uitdagingen zijn met handmatige tests.
uitdagingen met handmatig testen
het handmatig testen van een toepassing door QA-testers staat bekend als handmatig testen. Hier moeten alle tests handmatig worden uitgevoerd in elke omgeving, met behulp van een andere dataset en het succes/ falen van elke transactie moet worden geregistreerd.
in de bovenstaande figuur kunt u een man zien die de geregistreerde transacties handmatig verifieert. U kunt gemakkelijk de uitdagingen die hij wordt geconfronteerd kan leiden tot vermoeidheid, verveling, vertraging in het werk, fouten en fouten als gevolg van handmatige inspanning. Dit leidde tot de opkomst van automatiseringstests.
nu, laten we ons verdiepen in het laatste onderwerp van software testing tutorial artikel en zien hoe automatisering testen verslaat handmatige testen.
automatiseringstests Versus handmatige tests
automatiseringstests overwinnen elke keer handmatige tests. Waarom? Omdat het supersnel, vereist zeer minder investeringen in human resource, niet gevoelig voor fouten, frequente uitvoering van tests is mogelijk, ondersteunt regressie testen en ook functionele testen.
laten we een voorbeeld nemen en dit begrijpen. Stel dat je een inlogpagina hebt en je moet controleren of alle inlogpogingen succesvol zijn, dan zal het heel gemakkelijk zijn om een stukje code te schrijven die zal valideren of alle transactie/ inlogpogingen een succes zijn of niet (geautomatiseerde testcase uitvoering).
Al deze tests kunnen zo worden geconfigureerd dat ze in verschillende omgevingen en webbrowsers worden getest. Niet alleen dat, ook kunt u het genereren van resultaatbestand automatiseren, door het te plannen voor een bepaalde tijd gedurende de dag. Dan kunt u ook automatiseren het genereren van rapporten op basis van die resultaten en wat niet.
belangrijk punt hier is dat automation testing het werk van een tester een stuk eenvoudiger maakt. Raadpleeg de bovenstaande afbeelding die een meer ontspannen omgeving toont waarin dezelfde tester werkt. Als u meer wilt weten over Automation Testing en de veelgebruikte Automation Testing tool Selenium, kunt u verwijzen naar deze selenium Tutorial.
dit ging over de manier waarop automatiseringstests hun weg vinden op het gebied van softwaretests. Het brengt ons naar het einde van het artikel over Software testen Tutorial. Ik hoop dat je vond het informatief en het heeft geholpen bij het toevoegen van waarde aan uw kennis.
als u deze “Software Testing Tutorial” relevant vond, bekijk dan de live-online Selenium Certification Training van Edureka, een vertrouwd online leerbedrijf met een netwerk van meer dan 250.000 tevreden leerlingen verspreid over de hele wereld.