test coverage software testing
Software testen Testdekking Volledige gids: Hoe u meer kunt testen, tijd kunt besparen en betere testresultaten kunt behalen:
Het testen van software is een essentiële activiteit in de levenscycli van softwareontwikkeling en -onderhoud. Het is een praktijk die vaak wordt gebruikt om de softwarekwaliteit te bepalen en te verbeteren.
Ontwikkeling is tegenwoordig meer systematisch en organisaties zoeken naar maatregelen om de volledigheid en effectiviteit van tests te meten om criteria voor het voltooien van tests aan te tonen. Van allemaal wordt dekking als bijzonder waardevol beschouwd.
Wat je leert:
- Wat is testdekking?
- Testdekking en codedekking
- Mijn ervaring
- Test dekking betekenis
- Hoe een juiste testdekkingsmethode toepassen?
- Hoe zorg je ervoor dat alles wordt getest?
- Kritieke gebieden en methoden voor effectief testen
- Voordelen van het testen van dekkingsbewustzijn voor een tester:
- Gevolgtrekking
- Aanbevolen literatuur
Wat is testdekking?
Simpel gezegd, de dekking is 'Wat testen we en hoeveel testen we?'
Testdekking helpt de kwaliteit van testen te bewaken en helpt testers om tests te maken die gebieden dekken die ontbreken of niet gevalideerd zijn.
De meeste teams baseren hun dekkingsberekeningen alleen op functionele vereisten. Het is ook eerlijk omdat een applicatie eerst en vooral moet doen wat hij moet doen. Zo niet, dan zijn snelheid, veiligheid of gebruiksgemak - het maakt allemaal niet uit.
Echter, als toegewijd en onafhankelijk niet-functionele testen teams werken aan prestaties, beveiliging, bruikbaarheidstests, enz., dan zullen ze hun vereisten tot uitvoering moeten volgen door middel van testdekkingsanalyses.
Testdekking en codedekking
Testdekking wordt vaak verward met codedekking. Ook al zijn de onderliggende principes hetzelfde, het zijn twee verschillende dingen.
Code dekking heeft het echt over unit-testpraktijken die zich ten minste één keer op alle gebieden van de code moeten richten en wordt gedaan door ontwikkelaars.
arrays gebruiken in functies c ++
Testdekking, aan de andere kant, is testen van elke vereiste minstens één keer en het is duidelijk een QA-teamactiviteit.
Wat echt kwalificeert om een gedekte vereiste te zijn, hangt af van de interpretatie van elk team.
Bijvoorbeeld Sommige teams noemen een vereiste gedekt als er ten minste één testcase tegen is. Soms is het gedekt als er ten minste één teamlid aan is toegewezen. Of, als alle bijbehorende testcases zijn uitgevoerd.
- Als er 10 vereisten en 100 tests zijn gemaakt - wanneer deze 100 tests zich richten op alle 10 vereisten en er geen weglaten - noemen we dit voldoende testdekking op ontwerpniveau.
- Wanneer slechts 80 van de gemaakte tests worden uitgevoerd en zich richten op slechts 6 van de vereisten. We zeggen dat 4 vereisten niet worden gedekt, ook al is 80% van de tests gedaan. Dit zijn dekkingsstatistieken op uitvoeringsniveau.
- Wanneer slechts 90 tests met betrekking tot 8 vereisten testers hebben toegewezen en de rest niet, zeggen we dat de dekking van de testopdracht 80% is (8 van de 10 vereisten).
Het is ook belangrijk wanneer de dekking moet worden berekend.
Als je dit te vroeg in het proces doet, zul je veel hiaten zien omdat dingen nog niet compleet zijn. Dus het wordt over het algemeen aangeraden wacht tot de laatste build d.w.z. Final Regression Build. Dit geeft een correcte dekking van de tests die zijn uitgevoerd voor de gegeven vereisten.
Lees ook => Beheerproces voor release en implementatie
Mijn ervaring
Scene 8 jaar geleden: Toen ik 2 jaar ervaring had in de softwaretestindustrie, dacht ik dat het goed was als ik geen basiskennis over softwaretesten ken, iets wat je kunt leren met ervaring en dat ik ook zal doen.
Ik had gelijk - en ook ongelijk.
Juist omdat je met ervaring leert een groter plaatje te zien, de echte betekenis van 'kritieke situatie' begrijpt en de eindgebruiker beter begrijpt.
Fout omdat geen van de genoemde dingen ervaring vereist, maar vroeg leren, wat ik pas heel laat begreep. Dat is de aanmoedigende factor om dit bericht te schrijven.
Hier is mijn ervaring uit een van de interviews op dat moment:
Hoe zorg je ervoor dat de testdekking volledig of maximaal is? Werd mij gevraagd.
Ummmm …… Ik zorg ervoor dat ik elke functionaliteit test , Ik zei.
S o je zegt dat als je eenmaal alle functionaliteiten hebt getest, je het gevoel hebt dat je een maximum aan applicatie / product hebt gedekt, in termen van testen , mislukte de interviewer.
Ummm ... nou ... .ummm ... .ja, want als je alle functionaliteiten test, heb je vertrouwen in het gedrag van de applicatie / het product, Ik steunde mijn antwoord
Ik ben het ermee eens, maar mijn vraag is: geeft het u het vertrouwen dat uw testdekking maximaal of volledig is? de interviewer was niet in de stemming om me te laten gaan.
Nu werd ik ongeduldig, onbekend over het feit dat ik een van de belangrijkste onderwerpen over softwaretesten zou leren - Testdekking '
In plaats van de fragmenten uit het interview te reproduceren, vat ik hier samen wat ik die dag heb geleerd over Testing Coverage. Maar laten we eerst op één punt duidelijk zijn: het testen van dekking betekent nooit dat u weet of u voldoende test of niet, en het betekent ook niet dat u perfect test of niet.
Test dekking betekenis
Testdekking kan in een andere context een andere betekenis hebben. Laten we die contexten een voor een bekijken:
Productdekking - Naar welke aspecten van het product heeft u gekeken?
Ja, wanneer de testdekking wordt gemeten in termen van product, is het belangrijkste aandachtsgebied: welke delen van het product hebt u getest en welke zijn nog niet getest?
Voorbeeld 1:
Als 'mes' een product is, bent u aan het testen; concentreer je gewoon niet op het controleren of het de groenten / fruit goed snijdt. Er zijn andere aspecten waarnaar moet worden gezocht, zoals - de gebruiker moet er comfortabel mee om kunnen gaan.
Voorbeeld 2:
Als 'kladblok' een applicatie is, bent u aan het testen, het controleren van relevante functies is een must.
Maar andere aspecten waar u op moet letten zijn: de applicatie reageert correct terwijl andere applicaties tegelijkertijd worden gebruikt, de applicatie crasht niet wanneer de gebruiker iets ongewoons probeert te doen , krijgt de gebruiker de juiste waarschuwings- / foutmeldingen, kan de gebruiker de applicatie gemakkelijk begrijpen en gebruiken, is helpinhoud beschikbaar wanneer dat nodig is.
Als u de genoemde scenario's niet onderzoekt, kunt u niet beweren dat de testdekking voor de aanvraag volledig is.
Risicodekking - Op welke risico's heeft u getest?
Risicodekking is een ander aspect om volledige testdekking te hebben. U kunt het product of de applicatie pas als 'getest' taggen als u ook de bijbehorende risico's hebt getest. De dekking van de bijbehorende risico's is een belangrijke factor bij de algehele testdekking.
beste gratis video-omzetter voor Windows 10
Voorbeeld 1:
Als een tester u tijdens het testen van een vliegtuig vertelt dat hij / zij het interne systeem van het vliegtuig volledig heeft getest en dat het prima werkt, maar alleen de vliegcapaciteit van het vliegtuig werd tijdens het testen niet gedekt, wat zou dan uw reactie zijn?
Nou, dat is wat risicodekking betekent. Risico's identificeren voor de toepassing / het product en het grondig testen is altijd een goede gewoonte.
Voorbeeld 2:
Bij het testen van een e-commercesite nam de tester elke effectieve factor in overweging, maar hij hield geen rekening met het risico dat het aantal gebruikers de website tegelijkertijd en op de Super OFFER-dag zou bezoeken, het niet overwogen risico bleek een grote vergissing te zijn.
Aanbevolen lectuur
Vereiste dekking - Op welke vereisten heeft u getest?
Als een product of applicatie heel goed is ontwikkeld maar niet overeenkomt met de eisen van de klant, heeft het geen zin. Vereiste dekking tijdens het testen is net zo belangrijk als productdekking.
Voorbeeld 1:
Enthousiast over de familiefunctie, vroeg je de kleermaker om je jurk te naaien en die pauwblauwe showknopen op de halslijn aan te trekken.
Bij het naaien van de jurk dacht de kleermaker dat het er niet goed uit zou zien om die knopen op de halslijn te zetten, dus naaide hij in plaats daarvan een goudkleurige rand. Op de proefdag schreeuwde de ontevreden klant absoluut naar de kleermaker omdat hij zich niet aan de vereisten hield.
Voorbeeld 2:
Tijdens het testen van een chattoepassing zorgde de tester voor alle belangrijke punten, zoals meerdere gebruikers die in een groep chatten, twee gebruikers die onafhankelijk chatten, alle soorten emoticons beschikbaar, updates onmiddellijk naar de gebruiker gestuurd enz. Maar vergat het vereiste document te bekijken, wat duidelijk vermeld dat wanneer twee gebruikers onafhankelijk chatten, de optie voor videogesprekken moet worden ingeschakeld.
De klant bracht de chattoepassing op de markt en beweerde dat het mogelijk was om te bellen, terwijl twee gebruikers onafhankelijk chatten. U kunt zich voorstellen wat er met de chattoepassing zou zijn gebeurd.
Ook lezen Hoe u een traceerbaarheidsmatrix voor vereisten maakt
Hoe een juiste testdekkingsmethode toepassen?
Bewustzijn is alles:
Allereerst moet het QA-team weten hoeveel werk er komt kijken en waar de ontwerptaken zich bevinden. Op deze manier zullen ze weten of er meer tests moeten worden toegevoegd. Om dit te doen, kunt u een RTM gebruiken, zoals gebruikelijk is.
=> Bekijk dit artikel om er meer over te weten en hoe u het kunt gebruiken: Hoe u een traceerbaarheidsmatrix voor vereisten maakt - exact proces met voorbeeldsjabloon
Controleer ten tweede de toewijzing van middelen en test uitvoeringsproces om te zien of alles op de effectievere manier wordt getest.
Een tabel zoals hieronder kan handig zijn:
| Testtype | Totaal aantal gevallen | Uitgevoerde zaken | Toestand | Opmerkingen |
|---|---|---|---|---|
| Functioneel | 100 | 80 | 50 slagen, 30 mislukken | |
| Compatibiliteit | 100 | vijftig | 45 slagen, 5 mislukken | |
| Bruikbaarheid | 100 | 100 | 98 slagen, 2 mislukken | |
| Final Regressie | 100 | 100 | 99 slagen, 1 mislukt |
Hoe zorg je ervoor dat alles wordt getest?
- Elke tester moet op de hoogte zijn van de vereisten en testmethoden
- Geef prioriteit aan uw vereisten en concentreer uw energie waar deze het meest nodig is
- Wees geïnformeerd over hoe een bepaalde release verschilt van de vorige, zodat u kritieke vereisten nauwkeuriger kunt identificeren en u kunt concentreren op maximale positieve dekking
- Pas testautomatisering aan
- Gebruik testbeheertools om altijd op de hoogte te blijven
- Slimme werktoewijzing - Gebruik uw beste middelen voor kritieke taken en laat nieuwe testers meer ontdekken voor een nieuw perspectief
- Een checklist voor alle taken en diverse activiteiten
- Communiceer meer met uw Dev / Scrum / BA-teams om inzicht te krijgen in het applicatiegedrag
- Houd al uw bouwcycli en fixes bij
- Identificeer de meest impacterende problemen in de eerste builds zelf (indien mogelijk), zodat de latere kunnen werken voor betere stabiliteit en die gebieden kunnen bereiken die geblokkeerd zijn door eerdere problemen
Kritieke gebieden en methoden voor effectief testen
# 1)Bronnen door elkaar halen: Wissel taken uit tussen uw teamleden. Dit helpt de betrokkenheid te verbeteren en kennisconcentratie te voorkomen.
#twee)Compatibiliteitsdekking: Zorg ervoor dat u op de hoogte bent en het verschillende browsers en platforms om uw applicatie te testen.
# 3)Eigendom: Maak testers aanspreekbaar en geef ze (uiteraard met monitoring en ondersteuning) de vrije hand voor de module / taak waar ze aan werken. Dit helpt bij het opbouwen van verantwoordelijkheid en laat hen creatieve manieren proberen in plaats van de gebaande paden te volgen.
# 4)Deadlines: Het kennen van de releasedatums voordat de testfase begint, helpt bij een effectieve planning
# 5)Communicatie Blijf in contact met de ontwikkelaar en andere teams tussen release-cycli om te weten wat er aan de hand is.
# 6)Onderhoud een RTM: Fungeert als een goede afgeleide van de Belanghebbenden of klanten , op basis waarvan het releaseschema kan worden bevestigd
Voordelen van het testen van dekkingsbewustzijn voor een tester:
- Het helpt vooral bij het testen van taakprioritering
- Het helpt bij het bereiken van 100% dekking van de vereisten of met andere woorden, het voorkomt lekkage van vereisten
- Effectenanalyse wordt gemakkelijker
- Handig bij het bepalen van de EXIT-criteria
- Hiermee kan een testleiding een clear test afsluitingsrapport
Gevolgtrekking
Testdekking houdt niet op bij de genoemde contexten. Er zijn veel andere punten waarmee u rekening moet houden als het gaat om het testen van de dekking.
Het is niet altijd waar dat wanneer u meer test, de resultaten beter zijn. Als u meer test zonder duidelijke strategie, zult u waarschijnlijk veel tijd investeren.
Met een meer gestructureerde aanpak, een streven naar 100% dekking van de vereisten en effectieve testmethoden, doet u geen concessies aan kwaliteit.
We hopen dat de technieken die in dit artikel worden beschreven, u enkele tips zullen geven.
hoofdoorzaakanalyse bij het testen van software
Voeg uw opmerkingen en meningen over het bericht toe. Zoals gewoonlijk horen we graag van je.
Aanbevolen literatuur
- Beste softwaretesttools 2021 (QA Test Automation Tools)
- Software testen QA Assistant Job
- Software Testing-cursus: bij welk Software Testing Institute moet ik meedoen?
- Softwaretests kiezen als uw carrière
- Softwaretest Schrijver van technische inhoud Freelancer-baan
- Is het testen van software een emotionele taak?
- Enkele interessante sollicitatievragen voor het testen van software
- Feedback en recensies over softwaretestcursussen