Phenquestions
Testen van een eenheid
Unit Testing is onafhankelijk testen op een individuele functie, klasse of module dan het testen van volledig werkende software. Met behulp van een raamwerk voor unit-testing kan de programmeur testgevallen maken met input en verwachte output. Wanneer u honderden, duizenden of tienduizenden unit-testcases voor een groot softwareproject hebt, zorgt u ervoor dat alle afzonderlijke units werken zoals verwacht terwijl u de code blijft wijzigen. Bij het wijzigen van een eenheid die testgevallen heeft, moeten de testgevallen voor die module worden bestudeerd en bepalen of nieuwe testgevallen nodig zijn, de output is gewijzigd of de huidige testgevallen kunnen worden verwijderd omdat ze niet langer relevant zijn. Het creëren van een groot aantal eenheidstests is de gemakkelijkste manier om een hoge testcasedekking voor een softwarecodebasis te bereiken, maar zal er niet voor zorgen dat het eindproduct als een systeem werkt zoals verwacht.
Functioneel testen
Functioneel testen is de meest voorkomende vorm van testen. Wanneer mensen zonder veel details verwijzen naar softwaretests, bedoelen ze vaak functioneel testen. Functionele tests zullen controleren of de primaire functies van de software werken zoals verwacht. Er zou een testplan kunnen worden geschreven om alle functionele testgevallen te beschrijven die zullen worden getest, wat overeenkomt met de belangrijkste functies en mogelijkheden van de software. Het testen van de primaire functionaliteit zal zijn "gelukkig pad” testen, waarbij niet wordt geprobeerd de software te breken of te gebruiken in uitdagende scenario's. Dit zou het absolute absolute minimum aan testen moeten zijn voor elk softwareproject.
Integratie testen
Na unit-testen en functionele testen kunnen er meerdere modules zijn of het hele systeem dat nog niet als geheel is getest. Of er kunnen componenten zijn die grotendeels onafhankelijk zijn, maar af en toe samen worden gebruikt. Telkens wanneer componenten of modules onafhankelijk worden getest, maar niet als een geheel systeem, moeten integratietests worden uitgevoerd om te valideren dat de componenten samen als een werkend systeem functioneren volgens de eisen en verwachtingen van de gebruiker.
Stress testen
Denk aan stresstesten alsof je een spaceshuttle of een vliegtuig test. Wat betekent het om uw software of systeem onder "STRESS" te plaatsen? Stress is niets meer dan een intense belasting van een specifiek type dat je systeem waarschijnlijk zal breken. Dit kan vergelijkbaar zijn met "Load Testing" in de zin dat uw systeem onder hoge mate van gelijktijdigheid wordt geplaatst met veel gebruikers die toegang hebben tot het systeem. Maar het benadrukken van een systeem kan ook op andere vectoren gebeuren. Bijvoorbeeld het uitvoeren van firmware op een hardwarecomponent wanneer de hardware fysieke verslechtering heeft ondergaan en in gedegradeerde modus werkt. Stress is uniek voor alle soorten software, en bij systemen en het ontwerpen van stresstests moet rekening worden gehouden met welke natuurlijke of onnatuurlijke oorzaken uw software of systeem het meest waarschijnlijk belasten.
Belasting testen
Load-testing is een specifiek type stresstest, zoals hierboven besproken, waarbij grote aantallen gelijktijdige gebruikersverbindingen en -toegangen worden geautomatiseerd om de simulatie te genereren van het effect van een groot aantal authentieke gebruikers die tegelijkertijd toegang hebben tot uw softwaresysteem. Het doel is om erachter te komen hoeveel gebruikers tegelijkertijd toegang hebben tot uw systeem zonder dat uw softwaresysteem kapot gaat. Als uw systeem normaal verkeer van 10.000 gebruikers gemakkelijk aankan, wat gebeurt er dan als uw website of software viraal gaat en 1 miljoen gebruikers krijgt? Zal dit onverwacht? "LADEN" breek je website of systeem? Load testing simuleert dit, dus u bent vertrouwd met de toekomstige toename van gebruikers omdat u weet dat uw systeem de verhoogde belasting aankan.
Prestatietests
Mensen kunnen volkomen gefrustreerd en wanhopig raken als de software niet aan hun prestatie-eisen voldoet. Prestaties betekent in het algemeen hoe snel belangrijke functies kunnen worden voltooid. Hoe complexer en dynamischer de functies beschikbaar zijn in een systeem, hoe belangrijker en niet voor de hand liggend het wordt om de prestaties te testen, laten we een eenvoudig voorbeeld nemen, Windows- of Linux-besturingssysteem. Een besturingssysteem is een zeer complex softwareproduct en prestatietests op het systeem kunnen de snelheid en timing van functies inhouden, zoals opstarten, een app installeren, naar een bestand zoeken, berekeningen uitvoeren op een GPU en/of andere de miljoenen acties die kunnen worden uitgevoerd. Voorzichtigheid is geboden bij het selecteren van de prestatietestgevallen, om zeker te zijn van de belangrijke en waarschijnlijk defecte prestatiekenmerken die zijn getest.
Schaalbaarheid testen
Testen op je laptop is goed, maar niet echt goed genoeg als je een sociaal netwerk, een e-mailsysteem of supercomputersoftware aan het bouwen bent. Als het de bedoeling is dat uw software op 1000 servers wordt geïmplementeerd, die allemaal tegelijk werken, zullen de tests die u lokaal op één systeem uitvoert, niet de bugs aan het licht brengen die optreden wanneer de software "op schaal" wordt geïmplementeerd op honderdduizenden instanties. In werkelijkheid zullen uw tests waarschijnlijk nooit op volledige schaal kunnen worden uitgevoerd voordat ze voor productie worden vrijgegeven, omdat het veel te duur en niet praktisch zou zijn om een testsysteem te bouwen met 1000 servers die miljoenen dollars kosten. Daarom worden schaalbaarheidstests uitgevoerd op meerdere servers, maar meestal niet op het volledige aantal productieservers om te proberen enkele van de defecten te ontdekken die kunnen worden gevonden als uw systemen worden gebruikt op een grotere infrastructuur.
Statische analyse testen
Statische analyse is testen die wordt gedaan door de softwarecode te inspecteren zonder deze daadwerkelijk uit te voeren. Om statische analyse uit te voeren, zou je over het algemeen een tool gebruiken, er zijn er veel, een beroemde tool is Coverity. Statische analyse is eenvoudig uit te voeren voordat u uw software vrijgeeft en er kunnen veel kwaliteitsproblemen in uw code worden gevonden die kunnen worden opgelost voordat u deze vrijgeeft. Geheugenfouten, verwerkingsfouten van het gegevenstype, null-pointer-dereferenties, niet-geïnitialiseerde variabelen en nog veel meer defecten kunnen worden gevonden. Talen zoals C en C++ profiteren enorm van statische analyse omdat de talen grote vrijheid bieden aan programmeurs in ruil voor grote kracht, maar dit kan ook grote bugs en fouten veroorzaken die kunnen worden gevonden met behulp van statische analysetests.
Foutinjectie testen
Sommige foutcondities zijn erg moeilijk te simuleren of te activeren, daarom kan de software worden ontworpen om kunstmatig een probleem of fout in het systeem te injecteren zonder dat het defect natuurlijk optreedt. Het doel van foutinjectietests is om te zien hoe de software omgaat met deze onverwachte fouten. Reageert het gracieus op de situatie, crasht het of levert het onverwachte en onvoorspelbare problematische resultaten op?? Laten we bijvoorbeeld zeggen dat we een banksysteem hebben en dat er een module is om intern geld over te boeken van ACCOUNT A naar ACCOUNT B. Deze overdrachtsbewerking wordt echter pas aangeroepen nadat het systeem al heeft geverifieerd dat deze accounts bestonden voordat de overdrachtsbewerking werd aangeroepen. Hoewel we aannemen dat beide accounts bestaan, heeft de overdrachtsbewerking een foutgeval waarbij één doel- of bronaccount niet bestaat en een fout kan veroorzaken. Omdat we deze fout onder normale omstandigheden nooit krijgen vanwege het vooraf testen van invoer, dus om het systeemgedrag te verifiëren wanneer de overdracht mislukt vanwege een niet-bestaand account, injecteren we een nepfout in het systeem die een niet-bestaand account retourneert voor een overdracht en test hoe de rest van het systeem in dat geval reageert. Het is erg belangrijk dat de foutinjectiecode alleen beschikbaar is in testscenario's en niet wordt vrijgegeven voor productie, waar deze schade kan veroorzaken.
Geheugen overschrijding testen
Bij het gebruik van talen zoals C of C++ heeft de programmeur een grote verantwoordelijkheid om het geheugen direct aan te spreken, en dit kan fatale fouten in de software veroorzaken als er fouten worden gemaakt. Als een aanwijzer bijvoorbeeld null is en er geen verwijzingen naar zijn, zal de software crashen. Als geheugen aan een object wordt toegewezen en vervolgens een tekenreeks wordt gekopieerd over de geheugenruimte van het object, kan het verwijzen naar het object een crash of zelfs niet-gespecificeerd verkeerd gedrag veroorzaken. Daarom is het van cruciaal belang om een tool te gebruiken om geheugentoegangsfouten op te sporen in software die talen zoals C of C++ gebruikt, die deze potentiële problemen kunnen hebben. Tools die dit soort testen kunnen doen, zijn onder meer Open Source Valgrind of propriëtaire tools zoals PurifyPlus. Deze tools kunnen de dag redden wanneer het niet duidelijk is waarom de software crasht of zich misdraagt en direct verwijzen naar de locatie in de code met de bug. Geweldig, toch?
Testen van grensgevallen
Het is gemakkelijk om fouten te maken bij het coderen wanneer u zich op een zogenaamde grens bevindt. Een bankautomaat zegt bijvoorbeeld dat u maximaal $ 300 . kunt opnemen. Stel je dus voor dat de programmeur de volgende code op natuurlijke wijze heeft geschreven bij het bouwen van deze vereiste:
Als (amt < 300)startWithdrawl()
anders
error(“Je kunt %s opnemen”, amt);
Kun je de fout zien?? De gebruiker die $ 300 probeert op te nemen, krijgt een foutmelding omdat het niet minder dan $ 300 is. Dit is een fout. Daarom wordt grenstesten op natuurlijke wijze gedaan. Eisgrenzen zorgen er vervolgens voor dat aan beide zijden van de grens en de grens de software naar behoren functioneert.
Fuzz-testen
Snelle generatie van invoer naar software kan zoveel mogelijke invoercombinaties produceren, zelfs als die invoercombinaties totale onzin zijn en nooit door een echte gebruiker zouden worden geleverd. Met dit type fuzz-tests kunnen bugs en beveiligingskwetsbaarheden worden gevonden die niet op andere manieren worden gevonden vanwege het grote aantal invoer en scenario's die snel worden getest zonder handmatige testcasegeneratie.
Verkennende testen
Sluit je ogen en visualiseer wat het woord "Verkennen" betekent. Je observeert en onderzoekt een systeem om erachter te komen hoe het echt werkt. Stel je voor dat je een nieuwe bureaustoel per postorder ontvangt, en het heeft 28 onderdelen, allemaal in aparte plastic zakken zonder instructies. Je moet je nieuwe aankomst verkennen om erachter te komen hoe het werkt en hoe het in elkaar zit. Met deze geest kun je een verkennende tester worden. Je hebt geen goed gedefinieerd testplan van testgevallen. Je zult je software verkennen en onderzoeken op zoek naar dingen die ervoor zorgen dat je het prachtige woord zegt: "INTERESSANT"!”. Nadat je hebt geleerd, onderzoek je verder en vind je manieren om de software te breken waar de ontwerpers nooit aan hadden gedacht, en lever je vervolgens een rapport met talloze slechte aannames, fouten en risico's in de software. Lees hier meer over in het boek Explore It.
Penetratietesten
In de wereld van softwarebeveiliging is penetratietesten een van de belangrijkste manieren om te testen. Alle systemen, of ze nu biologisch, fysiek of softwarematig zijn, hebben grenzen en grenzen. Deze grenzen zijn bedoeld om alleen specifieke berichten, mensen of componenten het systeem binnen te laten. Meer concreet, laten we eens kijken naar een systeem voor online bankieren dat gebruikersauthenticatie gebruikt om de site te betreden. Als de site kan worden gehackt en in de backend kan worden ingevoerd zonder de juiste authenticatie, zou dat een penetratie zijn, die moet worden beschermd tegen. Het doel van penetratietesten is om bekende en experimentele technieken te gebruiken om de normale beveiligingsgrens van een softwaresysteem of website te omzeilen. Penetratietesten omvatten vaak het controleren van alle poorten die luisteren en proberen een systeem binnen te komen via een open poort. Andere veelgebruikte technieken zijn onder meer SQL-injectie of het kraken van wachtwoorden.
Regressietesten
Nadat u werkende software in het veld hebt geïmplementeerd, is het van cruciaal belang om te voorkomen dat bugs worden geïntroduceerd in functionaliteit die al werkte. Het doel van softwareontwikkeling is om de mogelijkheden van uw product te vergroten, bugs te introduceren of ervoor te zorgen dat oude functionaliteit niet meer werkt, wat een REGRESSIE wordt genoemd. Regressie is een bug of defect dat werd geïntroduceerd toen de mogelijkheid eerder werkte zoals verwacht. Niets kan de reputatie van uw software of merk sneller ruïneren dan regressiebugs in uw software te introduceren en echte gebruikers deze bugs te laten vinden na een release.
Regressietestcases en testplannen moeten worden gebouwd rond de kernfunctionaliteit die moet blijven werken om ervoor te zorgen dat gebruikers een goede ervaring hebben met uw applicatie. Alle kernfuncties van uw software waarvan gebruikers verwachten dat ze op een bepaalde manier werken, moeten een regressietest hebben die kan worden uitgevoerd om te voorkomen dat de functionaliteit bij een nieuwe release kapot gaat. Dit kunnen 50 tot 50.000 testgevallen zijn die de kernfunctionaliteit van uw software of applicatie dekken.
Broncode bisectie testen
Er is een bug in de software geïntroduceerd, maar het is niet duidelijk in welke versie van de release de nieuwe bug is geïntroduceerd. Stel je voor dat er 50 software-commits waren vanaf de laatst bekende tijd dat de software werkte zonder de bug, tot nu, wanneer..
Lokalisatie testen
Stelt u zich een weerapplicatie voor die het huidige en verwachte weer op uw locatie laat zien, evenals een beschrijving van de weersomstandigheden. Het eerste deel van lokalisatietests is ervoor te zorgen dat de juiste taal, het alfabet en de tekens correct worden weergegeven, afhankelijk van de geolocatie van de gebruiker. De app in het Verenigd Koninkrijk moet worden weergegeven in het Engels met Latijnse karakters; dezelfde app in China moet worden weergegeven in Chinese karakters in de Chinese taal. Meer uitgebreide lokalisatietests gedaan, het grotere aantal mensen van verschillende geolocaties zal communiceren met de applicatie.
Toegankelijkheidstests
Sommige burgers in onze gemeenschap hebben een handicap en kunnen daarom problemen hebben met het gebruik van de software die wordt gemaakt. Daarom worden toegankelijkheidstests uitgevoerd om ervoor te zorgen dat populaties met een handicap nog steeds toegang hebben tot de functionaliteit van het systeem. Als we bijvoorbeeld aannemen dat 1% van de bevolking kleurenblind is en onze software-interface ervan uitgaat dat gebruikers onderscheid kunnen maken tussen rood en groen, maar die kleurenblinde personen KUNNEN het verschil NIET zien. Daarom zal een goed-software-interface extra aanwijzingen hebben naast de kleur om de betekenis aan te geven. Andere scenario's naast kleurenblindheidstests zouden ook worden opgenomen in het testen van softwaretoegankelijkheid, zoals volledige visuele blindheid, doofheid en vele andere scenario's. Een goed softwareproduct moet toegankelijk zijn voor een maximaal percentage potentiële gebruikers.
Upgrade testen
Eenvoudige apps op een telefoon, besturingssystemen zoals Ubuntu, Windows of Linux Mint en software die nucleaire onderzeeërs bestuurt, moeten regelmatig worden geüpgraded. Het proces van de upgrade zelf kan bugs en defecten introduceren die niet zouden bestaan bij een nieuwe installatie omdat de toestand van de omgeving anders was en het proces van het introduceren van de nieuwe software bovenop de oude bugs zou kunnen hebben geïntroduceerd. Laten we een eenvoudig voorbeeld nemen, we hebben een laptop met Ubuntu 18.04, en we willen upgraden naar Ubuntu 20.04. Dit is een ander proces van het installeren van het besturingssysteem dan het direct opschonen van de harde schijf en het installeren van Ubuntu 20.04. Daarom, nadat de software is geïnstalleerd of een van de afgeleide functies ervan, werkt deze mogelijk niet 100% zoals verwacht of hetzelfde als toen de software vers was geïnstalleerd. We moeten dus eerst overwegen de upgrade zelf te testen onder veel verschillende gevallen en scenario's om ervoor te zorgen dat de upgrade werkt tot voltooiing. En dan moeten we ook overwegen om het daadwerkelijke systeem na de upgrade te testen om er zeker van te zijn dat de software is geïnstalleerd en functioneert zoals verwacht. We zouden niet alle testgevallen van een pas geïnstalleerd systeem herhalen, wat tijdverspilling zou zijn, maar we zullen met onze kennis van het systeem goed nadenken over wat KAN kapot gaan tijdens een upgrade en strategisch testgevallen toevoegen voor die functies.
Black Box & White Box-testen
Black box en white box zijn minder specifieke testmethodologieën en meer categorisatietypes van testen. In wezen black box-testen, waarbij wordt aangenomen dat de tester niets weet over de innerlijke werking van de software en een testplan en testcases maakt die alleen van buitenaf naar het systeem kijken om de functie ervan te verifiëren. White box-testen worden uitgevoerd door software-architecten die de interne werking van een softwaresysteem begrijpen en de cases ontwerpen met kennis van wat zou kunnen, zou, zou moeten en waarschijnlijk zal breken. Zowel black- als white-boxtesten zullen waarschijnlijk verschillende soorten defecten vinden.
Blogs en artikelen over softwaretesten
Softwaretesten is een dynamisch veld en er zijn veel interessante publicaties en artikelen die de gemeenschap op de hoogte houden van state-of-the-art denken over softwaretesten. We kunnen allemaal profiteren van deze kennis. Hier is een voorbeeld van interessante artikelen uit verschillende blogbronnen die u misschien wilt volgen:
- 7 tips om te volgen voordat u zonder vereisten test; http://www.testjournalen.com/
- 60 beste testtools voor automatisering: de ultieme lijstgids; https://testguild.com/
- Testtools voor open source databases; https://www.softwaretestmagazine.com/
- 100 procent testdekking is niet genoeg; https://www.kleverige geesten.com/
- Schilferige tests bij Google en hoe we ze verminderen; https://testen.googleblog.com/
- Wat is regressietesten?? ; https://test.io/blog/
- 27 beste Chrome-extensies voor ontwikkelaars in 2020; https://www.lamsvlees.com/
- 5 belangrijke stappen voor het testen van software die elke ingenieur zou moeten uitvoeren; https://techbeacon.com/
Producten voor softwaretests
De meeste waardevolle testtaken kunnen worden geautomatiseerd, dus het zou geen verrassing moeten zijn dat het een goed idee is om tools en producten te gebruiken om de talloze taken van softwarekwaliteitsborging uit te voeren. Hieronder zullen we enkele belangrijke en zeer waardevolle softwaretools voor het testen van software opsommen die u kunt verkennen en kijken of ze kunnen helpen.
JUnit
Voor het testen van op Java gebaseerde software biedt JUnit een uitgebreide testsuite voor unit- en functionele testen van de code die vriendelijk is voor de Java-omgeving.
Selenium
Voor het testen van webapplicaties biedt Selenium de mogelijkheid om interacties met webbrowsers te automatiseren, inclusief cross-browser compatibiliteitstesten. Dit is een eersteklas testinfrastructuur voor automatisering van webtests.
Komkommer
Een gedragsgestuurd testraamwerk stelt zakelijke gebruikers, productmanagers en ontwikkelaars in staat om de verwachte functionaliteit in natuurlijke taal uit te leggen en dat gedrag vervolgens in testcases te definiëren. Dit zorgt voor beter leesbare testgevallen en een duidelijke toewijzing aan de verwachte gebruikersfunctionaliteit.
Zuiveren
Vind geheugenlekken en geheugenbeschadigingen tijdens runtime door uw software uit te voeren met de ingebouwde Purify Plus-instrumentatie die uw geheugengebruik bijhoudt en fouten in uw code aanwijst die niet gemakkelijk te vinden zijn zonder instrumentatie.
Valgrind
Open source-tools die uw software uitvoeren en u ermee laten communiceren, terwijl ze wijzen op een foutenrapport van coderingsfouten zoals geheugenlekken en corrupties. Het is niet nodig om instrumentatie opnieuw te compileren of toe te voegen aan het compilatieproces, aangezien Valgrind de intelligentie heeft om uw machinecode dynamisch te begrijpen en instrumentatie naadloos te injecteren om codeerfouten te vinden en u te helpen uw code te verbeteren.
dekking
Statische analysetool die codeerfouten in uw software vindt voordat u uw code zelfs maar compileert en uitvoert. Coverity kan beveiligingskwetsbaarheden, schendingen van codeerconventies, evenals bugs en defecten vinden die uw compiler niet kan vinden. Dode code kan worden gevonden, niet-geïnitialiseerde variabelen en duizenden andere soorten defecten. Het is van vitaal belang om uw code op te schonen met statische analyse voordat u deze vrijgeeft voor productie.
JMeter
Een open-source framework voor prestatietests gericht op Java-gebaseerde ontwikkelaars, vandaar de J in de naam. Het testen van websites is een van de belangrijkste gebruiksscenario's voor JMeter, naast het testen van de prestaties van databases, e-mailsystemen en vele andere servergebaseerde toepassingen.
Metasploit
Voor beveiligings- en penetratietesten is Metasploit een generiek raamwerk met duizenden functies en mogelijkheden. Gebruik de interactieconsole om toegang te krijgen tot vooraf gecodeerde exploits en probeer de beveiliging van uw toepassing te verifiëren.
Academisch onderzoek naar softwaretests
- Onderzoeksgroep voor testen van de Universiteit van Sheffield
- Softwareverificatie- en validatielab van de Universiteit van Kentucky
- Onderzoeksgroep voor softwaretests van de North Dakota State University
- Systeem testen Intelligent Lab; Tsjechische Technische Universiteit Praag
- NASA: Jon McBride Software Testen en Onderzoek (JSTAR)
- McMaster-universiteit; Onderzoekslaboratorium voor softwarekwaliteit
- Technische Universiteit van Ontario; Onderzoekslaboratorium voor softwarekwaliteit
- De Universiteit van Texas @ Dallas; STQA
Conclusie
De rol van software in de samenleving blijft groeien en tegelijkertijd wordt de software van de wereld complexer. Om de wereld te laten functioneren, moeten we methoden en strategieën hebben voor het testen en valideren van de software die we maken door de functies uit te voeren die het bedoeld is om uit te voeren. Voor elk complex softwaresysteem moet er een teststrategie en een testplan zijn om de functionaliteit van de software te blijven valideren naarmate ze beter worden en de functie ervan blijven vervullen.
