complete non functional testing guide
Een complete gids voor niet-functionele tests: het doel, de typen, de tool, testcases met voorbeelden
Wat is niet-functioneel testen?
Er worden niet-functionele tests uitgevoerd om de niet-functionele vereisten van de applicatie te verifiëren, zoals prestaties, bruikbaarheid, enz.
Het controleert of het gedrag van het systeem voldoet aan de vereisten of niet. Het omvat alle aspecten die niet worden behandeld functioneel testen Bij ons dagelijks testen wordt veel aandacht besteed aan functionele testen en functionele eisen.
De opdrachtgevers zijn ook geïnteresseerd in het vervullen van de functionele eisen die direct verband houden met de functionaliteit van een applicatie. Maar in de feitelijke fase, d.w.z. wanneer u functioneel wordt getest, komt de software op de markt en wordt deze gebruikt door de echte eindgebruikers, en zijn er kansen dat het enkele problemen met de prestaties tegenkomt.
Deze problemen hebben geen betrekking op de functionaliteit van het systeem, maar kunnen de gebruikerservaring op een negatieve manier beïnvloeden. Daarom is het belangrijk dat de software of applicatie ook wordt getest op niet-functionele vereisten om een negatieve klantervaring te voorkomen.
Testen wordt grofweg ingedeeld in twee typen:
- Functioneel testen
- Niet-functionele testen
Wat je leert:
- Belang
- Doel
- Voorbeeld
- Voordelen
- Hoe niet-functionele vereisten vast te leggen?
- Verschil in functionele en niet-functionele vereisten
- Wordt deze Black Box of White Box getest?
- Checklist voor niet-functionele testcases
- Aanpak Document
- Niet-functionele testtypen
- Niet-functionele testtools
- Gevolgtrekking
- Aanbevolen literatuur
Belang
Deze test ontbrak de nodige aandacht aangezien dit de functionaliteit van het systeem niet beïnvloedt.
Ook aan de niet-functionele eisen werd in de eerdere testcycli onvoldoende aandacht besteed. Dit is nu echter veranderd. Niet-functionele tests zijn nu het belangrijkst, omdat ze tegenwoordig rekening houden met alle prestatie- en beveiligingsproblemen van applicaties.
Deze tests hebben een grotere impact op applicaties als het gaat om de prestaties van de applicatie bij veel gebruikersverkeer. Deze testen zorgen ervoor dat uw applicatie stabiel is en onder extreme omstandigheden belast kan worden.
Zoals de naam al aangeeft, concentreert deze test zich op het niet-functionele aspect van de applicatie. Dus wat zijn de niet-functionele aspecten? Of moet ik zeggen wat de features zijn die geen verband houden met de functionaliteit van de applicatie?
Welnu, hier zijn de antwoorden op die:
- Hoe presteert de applicatie onder normale omstandigheden?
- Hoe gedraagt de applicatie zich als er te veel gebruikers tegelijkertijd inloggen?
- Kan de applicatie stress aan?
- Hoe veilig is de applicatie?
- Kan de applicatie herstellen van een ramp?
- Kan de applicatie zich op dezelfde manier gedragen in een andere omgeving of besturingssysteem?
- Hoe gemakkelijk is om de applicatie in een ander systeem te porten?
- Zijn de documenten / gebruikershandleiding die bij de applicatie worden geleverd, gemakkelijk te begrijpen?
De lijst gaat maar door. Maar het punt hier is dat - zijn deze functies niet bijgedragen aan de kwaliteit van de applicatie? Het antwoord is ja. Deze kenmerken zijn even belangrijk.
Stel je voor dat een applicatie perfect voldoet aan alle gebruikersvereisten, maar dat een niet-geautoriseerde gebruiker gemakkelijk de door de gebruiker in de applicatie ingevoerde gegevens kraakt, of de applicatie sterft wanneer meer dan 5BB van een bestand wordt geüpload. Dus zou je zeggen dat de applicatie van goede kwaliteit is? Blijkbaar niet goed !!
Doel
Het enige doel van dit type testen is om ervoor te zorgen dat de niet-functionele aspecten van de applicatie worden getest en dat de applicatie goed werkt in de context daarvan.
Het doel is om het testen van alle kenmerken van de applicatie te dekken die helpen om een applicatie te leveren die voldoet aan de zakelijke verwachting.
Voorbeeld
Dit is een belangrijk testtype.
Functioneel testen test de functionaliteit van de applicatie en zorgt ervoor dat het werkt zoals verwacht, maar het niet-functionele testen zorgt ervoor dat de applicatie goed genoeg werkt om aan de zakelijke verwachtingen te voldoen.
Laten we een eenvoudig voorbeeld nemen om het belang ervan te begrijpen:
Een applicatie wordt ontwikkeld en volledig getest op functionaliteit, maar niet-functionele testen worden daarop niet uitgevoerd.
Ondertussen, wanneer de applicatie live gaat, kan dit leiden tot kritieke of grote problemen, zoals wanneer de belasting van de applicatie wordt verhoogd, deze te traag wordt en veel tijd kost om te openen.
De reactietijd kan toenemen of wanneer de belasting enigszins wordt verhoogd, kan de toepassing crashen. Dit laat zien hoe belangrijk het is om de niet-functionele aspecten van een applicatie te testen.
Voordelen
Hieronder enkele van de voordelen van een niet-functionele test:
- Het omvat de tests die niet kunnen worden gedekt door functionele tests.
- Het zorgt ervoor dat de applicatie efficiënt draait en betrouwbaar genoeg is.
- Het zorgt voor de veiligheid van de applicatie.
Hoe niet-functionele vereisten vast te leggen?
Terwijl we testen uitvoeren, ligt de focus vooral op functionele testen die de functionaliteit van het product testen. Maar niet-functionele tests zijn net zo belangrijk als functionele tests en er moet vanaf het begin van het product rekening mee worden gehouden.
Niet-functionele vereisten worden gebruikt om niet-functionele tests uit te voeren. Deze vereisten omvatten de prestatie-output die wordt verwacht van de applicatie of de te testen software. Dit omvat in feite de tijd die de software nodig heeft om een bepaald systeem te bedienen.
Niet-functionele vereisten leggen ook het gedrag vast wanneer een groot aantal mensen de software tegelijkertijd gebruikt. Meestal wordt ervaren dat de servers bezet of niet beschikbaar zijn vanwege zware belasting (d.w.z. dat er meer mensen tegelijkertijd gebruik van maken). Online treinkaartjes boeken kan de beste zijn voorbeeld van een dergelijke situatie.
Daarom zal het goed documenteren van de niet-functionele vereiste en het correct uitvoeren van de tests zorgen voor hoge tevredenheid in termen van bruikbaarheid door de potentiële klanten.
Hoewel dit testen geen directe zakelijke impact heeft op de functionaliteit van het systeem, kan het wel de gebruikerservaring en gebruikersvriendelijkheid in hogere mate verhogen, wat weer een grotere impact zal hebben op de kwaliteit van de software.
Voorbeeld:
Beschouw hetzelfde voorbeeld van de Facebook-inlogpagina. In dit geval is het doel van niet-functionele tests om de tijd te noteren die het systeem nodig heeft om in te loggen op Facebook na het invoeren van de geldige inloggegevens.
Het kan ook worden getest als (laten we zeggen 100) de gebruikers tegelijkertijd inloggen, hoeveel tijd kost het om de gebruiker in te loggen op Facebook.
Dit zorgt ervoor dat het systeem belasting en verkeer aankan, wat op zijn beurt een goede gebruikerservaring heeft.
In agile moet de niet-functionele vereiste worden vastgelegd met behulp van inputs.
Een niet-functionele vereiste moet worden vastgelegd als:
- Gebruikers- / technische verhalen
- In Acceptatiecriteria
- In Artifact
9
# 1) Gebruikers- / technische verhalen
Een niet-functionele vereiste kan worden vastgelegd met gebruikersverhalen of technische verhalen. Het vastleggen van niet-functionele vereisten als gebruikersverhaal is hetzelfde als het vastleggen van andere vereisten. Het enige verschil tussen de gebruiker en een technisch verhaal is dat het gebruikersverhaal discussie vereist en zichtbaarheid heeft.
# 2) Acceptatiecriteria
Acceptatiecriteria is het punt dat is gedefinieerd voor het accepteren van het product door de klant, d.w.z. om het product geaccepteerd te krijgen op de gedefinieerde punten, moet het in de staat zijn.
Een niet-functionele vereiste zou in de acceptatiecriteria moeten worden opgenomen, maar soms is het niet mogelijk om de niet-functionele vereisten bij elk verhaal, dus bij elke iteratie, te testen. Daarom moeten de vereisten worden toegevoegd of getest met alleen de relevante iteratie.
# 3) In artefacten
Een apart artefact moet worden voorbereid voor de niet-functionele vereisten, dit zou op zijn beurt helpen om een beter idee te krijgen van wat er moet worden getest en hoe dit in iteraties kan worden gedaan.
Verschil in functionele en niet-functionele vereisten
Er zijn verschillende verschillen tussen de functionele en niet-functionele vereisten en er worden er hieronder een paar genoemd:
S.No. | Functionele eis | Niet-functionele vereiste |
---|---|---|
Prestatie | Prestatietesters via een tool die de operatie behandelt als een transactie die wordt uitgevoerd door een bepaald aantal gelijktijdige gebruikers terwijl de tester alle logistiek analyseert | Reactietijd |
1 | Functionele eis is klantgericht. | Niet-functionele vereiste is gebaseerd op ontwikkelaars en technische kennis van het team. |
twee | Functional Requirement specificeert met welke functionaliteit rekening moet worden gehouden, d.w.z. wat moet worden getest. | Niet-functionele vereisten specificeren hoe het moet worden getest. |
3 | Functionele tests worden uitgevoerd voordat de applicatie live gaat. | Niet-functionele vereisten omvatten het onderhoudstesten, het testen van documentatie die niet vereist zijn terwijl de uitvoering aan de gang is, maar de applicatie is live gegaan. |
4 | Het staat alleen bekend als functionele vereiste. | Ook wel kwaliteitseisen genoemd. |
5 | Het implementatieplan voor functionele vereisten wordt gedefinieerd in het systeemontwerpdocument. | Het implementatieplan voor niet-functionele vereisten is gedefinieerd in de systeemarchitectuur. |
6 | Functionele eis omvat het testen van de technische functionaliteit van het systeem. | Niet-functionele vereisten omvatten eigenschappen als veiligheid, bruikbaarheid enz. |
Verder lezen => Verschillen tussen functioneel en niet-functioneel testen
Wordt deze Black Box of White Box getest?
De niet-functionele test valt onder a black box testen techniek.
Deze techniek beperkt zich niet alleen tot het testen van de functionaliteiten, maar kan ook worden gebruikt voor het testen van de niet-functionele vereisten, evenals de prestaties, bruikbaarheid, etc. Black box testtechniek vereist geen kennis van het interne systeem, dwz het vereist geen de kennis van code voor de tester.
Checklist voor niet-functionele testcases
Er wordt een checklist gebruikt om ervoor te zorgen dat geen enkel belangrijk aspect zonder testen wordt gelaten.
Een checklist wordt doorgaans gebruikt als er geen tijd is voor documentatie en het product moet worden getest of als er een tijdsdruk is, een checklist kan worden gebruikt om ervoor te zorgen dat alle belangrijke aspecten zijn afgedekt.
Laten we eens kijkenvoorbeeldchecklist voor het testen van prestaties, beveiliging en documentatie.
Checklist voor prestatietests
- De reactietijd van de applicatie moet worden geverifieerd, d.w.z. hoe lang duurt het om de applicatie te laden, elke invoer die aan de applicatie wordt gegeven, levert de uitvoer in hoeveel tijd, het vernieuwen van de browser, enz.
- Doorvoer moet worden geverifieerd voor het aantal transacties dat tijdens een belastingtest is voltooid.
- Milieu De opzet moet hetzelfde zijn als de live-omgeving, anders zijn de resultaten niet hetzelfde.
- Procestijd - Procesactiviteiten zoals import & export van Excel, eventuele berekeningen in de applicatie moeten worden getest.
- Interoperabiliteit moet worden geverifieerd, d.w.z. software moet kunnen samenwerken met de andere software of systemen.
- ETL tijd moet worden geverifieerd, d.w.z. de tijd die nodig is voor het extraheren, transformeren en laden van de gegevens van de ene database naar de andere.
- Toenemende belasting op de applicatie moet worden geverifieerd.
Checklist voor beveiligingstests
- Authenticatie: Alleen een authentieke gebruiker mag inloggen.
- Geautoriseerd: De gebruiker mag alleen inloggen op die modules waarvoor hij geautoriseerd is of waartoe de gebruiker toegang heeft gekregen.
- Wachtwoord: Wachtwoordvereiste moet worden geverifieerd, d.w.z. wachtwoord moet overeenkomen met hoe de vereiste definieert, d.w.z. lengte, speciale tekens, cijfers, enz.
- Time-out: Als de toepassing inactief is, zou deze binnen een bepaalde tijd moeten onderbreken.
- Reservekopie van gegevens: De gegevensback-up moet op een bepaald tijdstip worden gemaakt en naar een beveiligde locatie worden gekopieerd.
- Interne links naar de webapplicatie mag niet toegankelijk zijn als deze rechtstreeks in de browser wordt geplaatst.
- Alle communicatie moet versleuteld zijn.
Checklist voor het testen van documentatie
- Gebruikers- en systeemdocumentatie.
- Documenten voor trainingsdoeleinden.
Aanpak Document
Ontwikkel een specifiek benaderingsdocument voor de prestatietestfase door de algehele teststrategie te verfijnen. Deze testaanpak is leidend bij de planning en uitvoering van alle prestatietesttaken.
hoe u solarmovie gebruikt zonder u aan te melden
- Testbereik
- Teststatistieken
- Test Tools
- Belangrijke datums en resultaten
Testbereik
Voer prestatietests uit vanuit verschillende perspectieven, zoals gebruikersprestaties, bedrijfsprocessen, systeemstabiliteit, resourceverbruik, enzovoort. Typen prestatietests die moeten worden uitgevoerd, worden besproken in het bovenstaande gedeelte van het artikel (zoals belastingstest, stresstest, enz.)
Teststatistieken
De testaanpak verfijnt de meetgegevens die tijdens het testen moeten worden gemeten en gerapporteerd, zoals:
- Reactietijd (online)
- Batchvenster (batch)
- Doorvoer ( Bijvoorbeeld , het aantal transacties per tijdseenheid)
- Gebruik ( Bijvoorbeeld , het percentage van de gebruikte middelen)
Test Tools
Meestal vereist prestatietesten het gebruik van de juiste tools:
- Tools voor het genereren van lasten
- Tools voor prestatiebewaking
- Tools voor prestatieanalyse
- Tools voor applicatieprofilering
- Gereedschap voor basisbekleding.
Belangrijke datums en resultaten
Het prestatietestbenaderingdocument moet het volgende beschrijven:
- Datum en tijd van elke verrichtingstest.
- Typen tests en functionaliteitsmix die in elke prestatietest moeten worden opgenomen.
- Voltooiingsdatums voor prestatietests.
Niet-functionele testtypen
De volgende afbeelding toont de soorten niet-functionele tests:
Prestatietesten:
Evalueert de algehele prestaties van het systeem
De belangrijkste elementen zijn:
- Valideert dat het systeem voldoet aan de verwachte reactietijd.
- Evalueert dat de significante elementen van de applicatie voldoen aan de gewenste reactietijd.
- Het kan ook worden uitgevoerd als onderdeel van integratietests en systeemtests.
Laadtesten:
Evalueert of de prestaties van het systeem zijn zoals verwacht onder normale en verwachte omstandigheden.
Kernpunten zijn:
- Valideert dat het systeem presteert zoals verwacht wanneer gelijktijdige gebruikers de applicatie openen en de verwachte responstijd krijgen.
- Deze test wordt herhaald met meerdere gebruikers om de responstijd en doorvoer te krijgen.
- Op het moment van testen moet de database realistisch zijn.
- De test moet worden uitgevoerd op een speciale server die de daadwerkelijke omgeving stimuleert.
Stress testen:
Evalueert of de prestaties van het systeem zijn zoals verwacht wanneer er weinig bronnen beschikbaar zijn.
Kernpunten zijn:
- Test op weinig geheugen of weinig schijfruimte op clients / servers die defecten aan het licht brengen die onder normale omstandigheden niet kunnen worden gevonden.
- Meerdere gebruikers voeren dezelfde transacties uit op dezelfde gegevens.
- Meerdere clients zijn verbonden met de servers met verschillende workloads.
- Verkort de denktijd tot 'nul' om de servers maximaal te belasten.
Denk aan tijd: Net als het tijdsinterval tussen het typen van uw gebruiker en wachtwoord.
Volume testen:
Evalueert het gedrag van de software wanneer het om een grote hoeveelheid gegevens gaat.
Kernpunten zijn:
- Als de software onderhevig is aan grote hoeveelheden gegevens, controleert u de limiet waar de software faalt.
- Er wordt een maximale databasegrootte gemaakt en meerdere klanten zoeken in de database of maken een groter rapport.
- Voorbeeld - Als de toepassing de database verwerkt om een rapport te maken, zou een volumetest zijn om een grote resultatenset te gebruiken en te controleren of het rapport correct is afgedrukt.
Bruikbaarheidstesten:
Evalueert het systeem voor menselijk gebruik of controleert of het geschikt is voor gebruik.
Kernpunten zijn:
- Is de output correct en zinvol en is deze hetzelfde als verwacht volgens het bedrijf?
- Zijn de fouten correct gediagnosticeerd?
- Is de GUI correct en consistent met de standaard?
- Is de applicatie gemakkelijk te gebruiken?
Gebruikersinterface testen:
Evalueert de GUI.
Kernpunten zijn:
- GUI moet hulp en tooltips bieden om het gebruik gemakkelijk te maken.
- Consistent voor zijn uiterlijk?
- Gegevens worden correct van de ene pagina naar de andere overgebracht?
- GUI mag de gebruiker niet irriteren of moeilijk te begrijpen worden.
Compatibiliteitstesten:
Evalueert of de applicatie compatibel is met andere hardware / software met minimale en maximale configuratie.
Kernpunten zijn:
- Test elke hardware met een minimale en maximale configuratie.
- Test met verschillende browsers.
Testgevallen zijn dezelfde als die werden uitgevoerd tijdens functionele testen. - In het geval dat het aantal hardware en software te groot is, dan kunnen we OATS-technieken gebruiken om tot de testcases te komen met maximale dekking.
Hersteltesten:
Evalueert dat de toepassing correct wordt beëindigd in geval van een storing en dat de gegevens op de juiste wijze worden hersteld na hardware- en softwarefouten.
De tests zijn niet beperkt tot de onderstaande punten:
- Stroomonderbreking, naar de klant tijdens het uitvoeren van CURD-activiteiten.
- Ongeldige database-pointers en sleutels.
- Databaseproces wordt afgebroken of voortijdig beëindigd.
- Aanwijzers, velden en sleutels in de database worden handmatig en rechtstreeks binnen de database beschadigd.
- Koppel de communicatie fysiek los, schakel de stroom uit, schakel de routers en netwerkservers uit.
Instabiliteitstesten:
Evalueert en bevestigt of de software correct wordt geïnstalleerd en verwijderd.
hoe bin-bestanden te openen op Windows 7
Kernpunten zijn:
- Valideert dat de systeemcomponenten correct zijn geïnstalleerd op de aangewezen hardware.
- Valideert dat de navigatie op de nieuwe computer de bestaande installatie en oudere versies bijwerkt.
- Valideert dat er bij onvoldoende schijfruimte geen onaanvaardbaar gedrag is.
Documentatie testen:
Evalueert de documenten en andere gebruikershandleidingen.
De belangrijkste punten zijn:
- Valideert dat de vermelde documenten aanwezig zijn in het product.
- Valideert alle gebruikershandleidingen, installatie-instructies, leesmij-bestanden, release-opmerkingen en online hulp.
Failover-testen:
Failover-tests worden uitgevoerd om te controleren of het systeem in geval van een systeemstoring capabel genoeg is om extra bronnen zoals servers te verwerken.
Om een dergelijke situatie te voorkomen, spelen back-uptests een grote rol. Het maken van een back-upsysteem is waar het allemaal om draait. Als de back-up beschikbaar is, helpt het om het systeem terug te krijgen.
Beveiligingstests:
Beveiligingstesten wordt gedaan om ervoor te zorgen dat de applicatie geen mazen in de wet heeft die kunnen leiden tot gegevensverlies of bedreigingen. Het is een van de belangrijke aspecten van niet-functionele tests en als het niet goed wordt uitgevoerd, kan het leiden tot beveiligingsbedreigingen.
Het omvat het testen van authenticatie, autorisatie, integriteit en beschikbaarheid.
Schaalbaarheidstesten:
Schaalbaarheidstests worden uitgevoerd om te controleren of de applicatie capabel genoeg is om meer verkeer, aantal transacties, datavolume, enz. Te verwerken. Het systeem zou moeten werken zoals verwacht wanneer het datavolume of de verandering in de datagrootte is voltooid.
Nalevingstesten:
Er wordt een conformiteitstest uitgevoerd om te controleren of de gedefinieerde normen worden gevolgd of niet. Audits worden gedaan om hetzelfde te verifiëren.
Voor Voorbeeld Er worden audits uitgevoerd om het proces van het maken van testcases / testplannen te verifiëren en deze op de gedeelde locatie te plaatsen met de standaardnaam die wordt gedaan of niet. In QC wordt bij het benoemen van de testgevallen de standaard naam van de testcase gevolgd of niet. Documentatie is compleet en goedgekeurd of niet.
Dit zijn de paar tips die worden behandeld tijdens auditing.
Duurzaamheidstesten:
Duurzaamheidstesten wordt gedaan om het gedrag van het systeem te verifiëren wanneer een belasting gedurende lange tijd enigszins wordt verhoogd.
Het wordt ook wel Soak-testen en capaciteitstesten genoemd. Het helpt om te controleren of er geheugenlekken in het systeem zijn. Duurzaamheidstests zijn een subset van belastingtests.
Lokalisatie testen:
Lokalisatie testen wordt gedaan om de toepassing in verschillende talen, d.w.z. verschillende landinstellingen, te verifiëren. De aanvraag moet worden geverifieerd voor een bepaalde cultuur of locatie. De belangrijkste focus is om de inhoud, GUI van de applicatie te testen.
Internationaliseringstesten:
Internationaliseringstesten wordt ook wel i18n-testen genoemd.
I18n staat voor I-achttien letters- N. Het wordt gedaan om te controleren of de applicatie werkt zoals verwacht in alle taalinstellingen. Het controleert of enige functionaliteit of applicatie zelf niet kapot gaat, d.w.z. de applicatie moet voldoende capabel zijn om alle internationale instellingen te verwerken.
Het controleert ook of de applicatie zonder problemen wordt geïnstalleerd.
Betrouwbaarheidstesten:
Betrouwbaarheidstests worden gedaan om te controleren of de applicatie betrouwbaar is en gedurende een bepaalde periode in de gedefinieerde omgeving wordt getest. Een applicatie moet elke keer dezelfde output geven als verwacht, alleen dan kan deze als betrouwbaar worden beschouwd.
Draagbaarheid testen:
Er worden portabiliteitstests uitgevoerd om te controleren of in het geval een software / applicatie op een ander systeem of op een ander platform wordt geïnstalleerd, deze zou moeten kunnen werken zoals verwacht, d.w.z. dat er geen functionaliteit mag worden beïnvloed door een verandering in de omgeving.
Tijdens het testen is het ook vereist om de wijziging te testen met de hardwareconfiguratie zoals de ruimte op de harde schijf, de processor en ook met verschillende besturingssystemen om ervoor te zorgen dat het juiste gedrag van de applicatie en de verwachte functionaliteit intact zijn.
Basislijntesten:
Baseline-testen worden ook wel benchmarktesten omdat het een basis vormt voor elke nieuwe applicatie die moet worden getest.
Bijvoorbeeld: In de eerste iteratie was de responstijd voor een applicatie 3 seconden. Dit is nu ingesteld als maatstaf voor de volgende iteratie en in de volgende iteratie verandert de responstijd in 2 seconden. Het is in feite een validatiedocument dat wordt gebruikt als basis voor toekomstige referenties.
Efficiëntie testen:
Efficiëntietests worden uitgevoerd om te controleren of de applicatie efficiënt werkt en het aantal benodigde middelen, benodigde tools, complexiteit, klantvereisten, vereiste omgeving, tijd, wat voor soort project het is, enz.
Dit zijn enkele van de aanwijzingen die zouden helpen om te bepalen hoe efficiënt een toepassing zou werken als alle beschouwde parameters werken zoals verwacht.
Testen voor noodherstel:
Deze tests worden uitgevoerd om het succespercentage van het herstel van een applicatie of systeem te verifiëren als er een kritieke storing optreedt en of het systeem in staat is om de gegevens en applicatie te herstellen of dat het systeem het gemakkelijk aankan om terug te keren naar de manier waarop het eerder werkte, dwz van het operationele front.
Onderhoudbaarheidstesten:
Zodra de applicatie / het product live gaat, is er een kans dat er een probleem opduikt in de live-omgeving of wil de klant een verbetering voor de applicatie die al live is.
In dit geval is er een onderhoudstestteam beschikbaar om de bovengenoemde scenario's te testen. Zodra de applicatie live gaat, heeft deze nog steeds onderhoud nodig waarvoor het onderhoudstestteam werkt.
Niet-functionele testtools
Er zijn verschillende tools op de markt beschikbaar voor het testen van prestaties (belasting en stress).
Weinigen van hen worden hieronder vermeld:
- JMeter
- Loadster
- Loadrunner
- Loadstorm
- Neoload
- Voorspelling
- Laden voltooid
- Webserver Stress Tool
- WebLoad Professional
- Loadtracer
- vPerformer
Worden niet-functionele tests altijd uitgevoerd zonder documentatie en testcases? Waarom?
“We leren altijd functionele testcases te schrijven. Waarom is dat? Worden ‘niet-functionele tests’ uitgevoerd zonder documentatie (met andere woorden, op ad-hocbasis) of is dat een afzonderlijk proces dat veel moeilijker te begrijpen is? Hoe worden testcases geschreven voor verschillende soorten tests die in een applicatie plaatsvinden? '
Dit is een van de meest originele, onderscheidende en out-of-the-box vragen die mij de afgelopen tijd zijn gesteld. Laten we het antwoord zoeken.
Hoe komt het dat we nooit zien en oefenen met het schrijven van niet-functionele testcases?
Laten we beginnen met wat we weten en zoals altijd een praktisch scenario.
Voorbeeld Hieronder volgen de stappen die moeten worden uitgevoerd op een applicatie voor online bankieren om een overboeking uit te voeren. Laten we dat als onze test ter referentie gebruiken.
- Log in op de site.
- Kies de bankrekening.
- Kies de begunstigde (deze begunstigde kan tot dezelfde bank behoren of een andere bank. Dit hangt af van uw gegevenskeuze om deze stap uit te voeren. Kies er in ieder geval een. We gaan er ook vanuit dat de begunstigde al is toegevoegd). .
- Voer het over te schrijven bedrag in (positieve waarde, binnen de limiet, correct formaat, enz.).
- Klik op Overboeking en controleer of er een bevestiging is ontvangen, het rekeningsaldo is bijgewerkt en zo.
Dit is de functionele testcase, toch?
Laten we op dezelfde applicatie, op dezelfde overdrachtspagina, zeggen dat we presteren Testen van prestaties, beveiliging en bruikbaarheid Dit zijn niet-functionele typen, toch?
Hoe zouden we de testcases schrijven?
# 1) Testcases voor bruikbaarheidstests
Bruikbaarheidstesten is een genre van softwaretesten dat zich bezighoudt met gebruikerservaring. Dit zijn enkele van de vragen die we proberen te beantwoorden.
- Hoe gemakkelijk is de applicatie te gebruiken?
- Hoe bevredigend is de ervaring met het gebruik van het systeem?
- Als het niet meteen bekend is, hoe gemakkelijk is het dan te leren?
Meer informatie hierover is hier: Gids voor bruikbaarheidstests
Hoe zou een gebruiker de antwoorden op de bovenstaande vragen bepalen in de context van bruikbaarheidstests?
De gebruiker zou exact dezelfde stappen uitvoeren als in de functionele testcase. Heb ik gelijk?
# 2) Prestatietests Testgevallen
Er zijn verschillende variaties op prestatietests, maar in de kern wordt het gebruikt om statistieken te krijgen over het systeem, het gebruik van bronnen, responstijd, netwerkverbruik, enz. Op verschillende laadpunten.
Bekijk onze Tutorials voor prestatietests om er meer over te weten.
Als ik de prestaties van de overdrachtstransactie zou testen, zou ik 10, 20, 30, 100 ... 1000 ... enz. Gebruikers de overdrachtsoperatie gelijktijdig of incrementeel laten uitvoeren, afhankelijk van waar ik me op wil richten en gegevens over wil verzamelen.
Welke stappen zou elke gebruiker uitvoeren om de overdracht te gebruiken terwijl de prestatietest aan de gang is?
Precies dezelfde stappen als de functionele test, toch?
# 3) Testcases voor beveiligingstests
Security Testing is een tak van QA die helpt om de softwaresystemen hack-proof te maken. Het identificeert kwetsbaarheden (mogelijke probleemgebieden in het softwaresysteem), exploiteert deze door middel van penetratie of white-hat-testtechniek en wanneer lacunes worden gevonden, wordt eraan gewerkt.
Wanneer wil ik controleren of de overdrachten hack-proof zijn en correct gericht zijn op de beoogde ontvangers en of er geen black spots zijn in het hele proces? Ik zou de overdracht uitvoeren terwijl het bewakingsproces voor beveiligingslekken parallel verloopt.
Daarom voer ik in feite exact dezelfde stappen uit die ik normaal zou doen in het geval van een functionele testcase.
Ik denk dat we genoeg hebben om vast te stellen dat de stappen in alle situaties hetzelfde zijn. De methode en de bedoeling achter het proces zijn wat anders is.
Laten we eens kijken:
Type testen | WHO? | Waarom? Voornemen |
---|---|---|
Functioneel testen | QA-testers | Nauwkeurigheid |
Efficiëntie | ||
Zakelijke toepasbaarheid | ||
Bruikbaarheid | QA-testers of realtime gebruikers | Makkelijk te gebruiken |
Gemakkelijk te leren | ||
Efficiëntie | ||
Netwerkgebruik etc. | ||
Veiligheid | Scantools en ander monitoringsysteem door gespecialiseerde beveiligingsexperts | Hack veilig |
Bescherming van de identiteit van de begunstigde en de betaler enz. |
Wat interessant is om op te merken, is dat ongeacht welke vorm van testen we willen doen, alle stappen zijn hetzelfde
Het echte verschil is dat:
- Wie voert deze stappen uit?
- Wat is de bedoeling, of met andere woorden: wat probeer ik te bereiken met deze test?
- De gebruikte tools en technieken.
Terugkomend op onze vraag: waarom leren we nooit om niet-functionele testcases te schrijven met alle gedetailleerde stappen die erbij komen kijken?
Het is omdat in de kern zijn teststappen voor een variatie op testtypen voor een bepaalde functie allemaal hetzelfde, functioneel of niet. Het is de bedoeling die het verschil maakt en misschien de methode.
Gevolgtrekking
Voordat u niet-functionele tests uitvoert, is het essentieel om de teststrategie correct te plannen om een goede test te garanderen. Er zijn verschillende tools op de markt om dit soort tests uit te voeren, zoals Load Runner, RPT, etc.
Dit testen speelt een grote rol bij het succes van een applicatie en het opbouwen van een goede klantrelatie en mag daarom niet over het hoofd worden gezien. Dit is een van de belangrijke onderdelen van het testen van software en testen kunnen zonder dit niet als compleet worden beschouwd.
We kunnen niet-functionele testdetails opnemen in het testplan of er een aparte strategie voor maken. In beide gevallen is het doel om de niet-functionele aspecten van de software goed te dekken.
We hopen dat dit proces van diep in dit onderwerp verdiepen voor jullie net zo leuk is geweest als voor jullie allemaal. We horen graag uw feedback en mening over dit onderwerp.
Hoe ga je om met niet-functionele testen in je teams? En zoals altijd, laat het ons weten als u het eens of oneens bent of iets toe te voegen heeft aan wat we hier aan de hand hebben.
Aanbevolen literatuur
- Functioneel testen versus niet-functioneel testen
- Alfatesten en bètatesten (een complete gids)
- Handleiding voor het testen van webapplicaties
- Complete functionele testgids met zijn typen en voorbeelden
- Build Verification Testing (BVT Testing) Complete Guide
- Beste softwaretesttools 2021 (QA Test Automation Tools)
- Beginnershandleiding voor penetratietesten van webapplicaties
- Load Testing complete gids voor beginners