functional testing vs performance testing
Functioneel testen versus prestatietesten:
Verschillen tussen Prestatietests, belastingtests en stresstests werden uitgelegd met voorbeelden in onze laatste tutorial.
Softwaretests bestrijken een breed scala van gebieden waar elke verificatie of validatie van softwarefunctionaliteit kan plaatsvinden. Af en toe worden niet-functionele aspecten minder met betrekking tot de functionele aspecten. Ze worden praktisch niet uitgevoerd; gelijktijdig tijdens het testen van software.
Klik hier voor een complete serie tutorials over prestatietests
In dit artikel worden de extra voordelen van de kwaliteit van het softwareproduct tijdens verschillende scenario's in de levenscyclus van softwaretests uitgelegd wanneer zowel functioneel als niet-functioneel tegelijkertijd worden genomen.
Wat je leert:
- Snel verschil tussen Performance Testing en Functional Testing
- Waarom moeten functionele tests en prestatietests tegelijkertijd worden uitgevoerd?
- Case study
- Gevolgtrekking
- Aanbevolen literatuur
Snel verschil tussen Performance Testing en Functional Testing
| SL GEEN | Functioneel testen | Prestatietests |
|---|---|---|
| 1 | Om de nauwkeurigheid van de software te verifiëren met welomlijnde invoer ten opzichte van de verwachte uitvoer | Om het gedrag van het systeem bij verschillende belastingsomstandigheden te verifiëren |
| twee | Het kan handmatig of geautomatiseerd zijn | Het kan effectief worden uitgevoerd als het geautomatiseerd is |
| 3 | Eén gebruiker die alle bewerkingen uitvoert | Meerdere gebruikers die gewenste bewerkingen uitvoeren |
| 4 | Betrokkenheid vereist van klant, tester en ontwikkelaar | Betrokkenheid vereist van Klant, Tester, Ontwikkelaar, DBA en N / W Managementteam |
| 5 | Testomgeving op productiegrootte niet verplicht en H / W-vereisten zijn minimaal | Vereisten dicht bij de productietestomgeving en verschillende H / W-faciliteiten om de lading te vullen |
Waarom moeten functionele tests en prestatietests tegelijkertijd worden uitgevoerd?
Functioneel testen wordt veel belangrijker voor elke pre-release van software. Werkelijke resultaten gebaseerd verificatie en validatie in de gerepliceerde productie- of testomgeving zijn waar het testen meestal plaatsvindt.
Lekkage door defecten kan een van de grootste problemen worden:
Testers hebben meer verantwoordelijkheid dan ontwikkelaars in termen van de kwaliteit van het product. In principe willen ze niet dat het geteste product lekken vertoont. Testers voeren over het algemeen alleen functionele tests uit om dit te bereiken.

Het volgende is een gesprek tussen aTestmanager en een tester
(Testmanager wordt ‘TM’ en tester ‘TR’ genoemd)
TM : Hey maatje ... Hoe doen we het bij het testen van het product ‘A’?
TR : Yep… We vorderen op een grotere manier.
TM : Dat is fantastisch ... En wat is onze reikwijdte in termen van prestatietests terwijl functionele tests worden uitgevoerd?
TR : We dekken ze niet, onze resultaten zouden alleen in het functionele gebied moeten zijn en niet in het niet-functionele gebied. Bovendien is de testomgeving die we gebruiken geen exacte replica van de productie.
Er zijn een paar vragen uit het bovenstaande gesprek om in overweging te nemen:
- Heeft functioneel testen een afhankelijke factor ten opzichte van prestaties?
- Wat als de prestaties van de software achteruitgaan, maar de levering van het product gebeurt zonder de prestaties te controleren?
- Prestatietesten - bestaat het naast elkaar binnen het functionele testproces?
Het is voor testers een algemene praktijk geworden om niet aan de niet-functionele aspecten te werken, tenzij ze daarom worden gevraagd. Het is gebruikelijk om te vermijden niet-functionele testen totdat de klant problemen heeft gemeld met de prestaties van de te testen software.
Er zijn dus twee vragen die u moet overwegen:
- Prestaties - heeft dit invloed op functioneel testen?
- Behouden we prestatietests als een afzonderlijk product, ook als de klant zich daar zorgen over maakt?
Prestatietesten is belangrijk
beste servers om te spelen op wow
Software werkt op basis van verschillende architecturen en volgende modellen, waaronder:
- Vereiste antwoordmodellen
- Op transacties gebaseerde systemen
- Op belasting gebaseerde systemen
- Op gegevensreplicatie gebaseerde systemen
Het functionele testgedrag van het bovengenoemde systematische model hangt af van de prestaties van het systeem.

Vanuit het oogpunt van automatisering is er veel aandacht voor prestatietesten.
Het volgende is een gesprek tussen aopdrachtgever en de Test Manager
(Klant wordt ‘CL’ genoemd en Testmanager ‘TM’)
CL : Vandaar dat ik tot de oplossing kom die we hebben gevraagd, ik hoop dat er meerdere iteraties zullen zijn van de tests die momenteel plaatsvinden.
TM : Ja, dit is mogelijk. Zoals u al zei, zal de kans op iteratief testen groter zijn, we willen automatisering voorstellen om het functionele (regressie) testen aan te pakken.
CL : Oké geweldig, stuur ons alsjeblieft je benadering zodat we dit kunnen goedkeuren. Automatisering heeft een veel hogere output met minimale inspanning.
TM : Precies. We werken aan de aanpak en nemen contact met u op met een Proof of Concept.
Uit het bovenstaande gesprek blijkt duidelijk dat de behoefte van de klant is om de efficiëntie te optimaliseren.
Case study
Bedrijf ABC werkt aan een project voor het ontwikkelen van Software A. Het testen van Software A wordt gedaan door het bedrijf XYZ.
Het contract voor bedrijf ABC en XYZ heeft enkele beperkingen voor hun samenwerking. Elk gesprek tussen de twee bedrijven moet één keer per week of drie keer per maand plaatsvinden. Het systeem werkt volgens een model van verzoek-antwoordmodus. De ontwikkelingsfase is afgerond door Bedrijf ABC.
Nu is het tijd voor bedrijf XYZ om de formele functionele tests uit te voeren op software A. XYZ begint te werken aan het testen van software A. Ze hebben een schone lei gekregen over de software en hebben na 2 testcycli de ‘Go’ voor live implementatie gegeven.
Ondanks het kwaliteitscertificaat van het testteam verliep de live implementatie niet goed. Er waren veel bugs na de productie. Er waren veel problemen bij de klanten, waaronder een onderbreking van de functionaliteit voor de end-to-end bedrijfsprocessen.
Dus wat is nu deprobleem

- Is het een probleem met een beperking van de samenwerking tussen het ontwikkel- en testteam?
- Is het dat de vereisten niet voor 100% zijn vastgelegd?
- Is het product niet getest in een geschikte testomgeving?
- Of een andere oorzaak?
Na zorgvuldig onderzoek en analyse, devolgende werden afgeleid

- Er waren maar weinig van de afhankelijke en onderling afhankelijke applicaties die prestatieproblemen hadden bij het ophalen van de antwoorden.
- De gebruikte testinputs waren niet absoluut.
- Aan de robuustheid van de software is niet gelet.
- Veel synchronisatieproblemen tussen de meerdere onafhankelijke applicaties.
- Het testen van de software had meerdere herwerkzaamheden uitgevoerd die niet in overweging werden genomen.
Vandaar dat na decorrigerende maatregelenplanningsteam stapte in, het volgende werd voorgesteld:
- De interactie tussen het ontwikkelteam en het testteam moet worden vergroot.
- Alle afhankelijke applicaties moeten worden aangesloten en opgenomen in de functionele systeemtests
- De time-outwaarde voor verzoeken en reacties moet worden verhoogd om ruimte te geven aan niet-productieomgevingen
- Bij functioneel testen moet verschillende input worden gebruikt, variërend van eenvoudig tot complex
- Niet-functionele tests, met name de prestatie- en belastingtests, moeten worden uitgevoerd zoals geadviseerd door het herstelteam.
- Naast systeemtests moeten ook systeemintegratietests worden uitgevoerd.
- Er moet een minimale tijdspanne tussen twee testiteraties worden voorzien. Dit is om de eerder geïdentificeerde bugs opnieuw te testen.
- Alle bugs die in eerdere iteraties zijn geïdentificeerd, moeten in de huidige iteratie worden opgelost.
Het testteam implementeerde alle voorgestelde acties en er werden in korte tijd een groot aantal defecten ontdekt.
Observaties:
- Het live implementatieschema van de software verbeterde aanzienlijk door de testcyclustijden te optimaliseren.
- Er is goede voortgang geboekt bij het optimaliseren van de softwarekwaliteit. Daarom was er een enorme afname van de supporttickets na de implementatie.
- Herbewerkingen werden verminderd en het was het testen van iteraties in plaats van herwerken. Tussen de verschillende iteraties werden betere kwaliteitsverbeteringen waargenomen.
Gevolgtrekking
Het uitvoeren van niet-functionele tests tijdens het uitvoeren van functionele tests is voordeliger en voegt meer voordelen toe aan de algehele softwarekwaliteit. Dit zal prestatiebugs identificeren (beperkt tot de testomgeving en afhankelijkheid) en zal daarom situaties van aannames over functionele problemen verminderen.
Er moet voldoende planning worden gemaakt voor het uitvoeren van functionele en niet-functionele tests (tot een minimum) om een sterke relatie tussen de andere belanghebbenden van het project te behouden.
Over de auteur: Dit is een artikel geschreven door Nagarajan. Hij werkt als een testleider met meer dan 6 jaar testervaring in verschillende functionele gebieden zoals bankieren, luchtvaartmaatschappijen, telecom op het gebied van zowel handmatig als automatisering.
Onze aanstaande tutorial zal meer uitleggen over Performance Test Plan en Test Strategy.
Bezoek hier voor een complete serie tutorials over prestatietests
PREV-zelfstudie VOLGENDE zelfstudie
Aanbevolen literatuur
- Functioneel testen versus niet-functioneel testen
- Beste softwaretesttools 2021 (QA Test Automation Tools)
- Prestatietests versus belastingtests versus stresstests (verschil)
- Georgia Tech standaardiseert zijn prestatietests op RadView WebLOAD
- Verschil tussen Desktop, Client Server Testing en Web Testing
- Primer eBook downloaden testen
- De verschillen tussen unit-tests, integratietests en functionele tests
- Cloud-prestatietests: cloudgebaseerde serviceproviders voor belastingtests