Menu

Verschil tussen prestatietestplan en prestatieteststrategie

  • Hoofd
  • Andere
  • Verschil tussen prestatietestplan en prestatieteststrategie

difference between performance test plan

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Wat is het verschil tussen Performance Test Plan en Test Strategy?

In deze Prestaties testen serie , onze vorige tutorial, uitgelegd over Functioneel testen versus prestatietesten in detail.

​ Klik hier voor een complete serie tutorials over prestatietests

In deze zelfstudie leert u over het verschil tussen Prestatietestplan en Teststrategie en de inhoud die als onderdeel van deze documenten moet worden opgenomen.

Prestatietestplan versus teststrategie

Laten we het verschil tussen deze twee documenten begrijpen.

Wat je leert:

Strategie voor prestatietests

Prestatieteststrategiedocument is een document op hoog niveau dat ons informatie geeft over hoe prestatietests tijdens de testfase kunnen worden uitgevoerd. Het vertelt ons hoe we een zakelijke vereiste moeten testen en welke aanpak nodig is om het product met succes aan de eindklant te leveren.

Hierdoor is alle informatie over het bedrijfsproces op een zeer hoog niveau.

Dit document is meestal geschreven door Performance Test Managers op basis van hun eerdere ervaring, aangezien er slechts beperkte informatie beschikbaar zal zijn aangezien dit document wordt opgesteld tijdens de beginfase van het project, d.w.z. tijdens de Vereiste Analyse fase of na de Vereiste Analyse fase.

Met andere woorden, een Prestatieteststrategiedocument is niets anders dan een richting die u aan het begin van het project uitzet met de aanpak die u gaat volgen om de Prestatietestdoelen te behalen.

Een typisch prestatieteststrategiedocument bevat het algemene doel van prestatietests, zoals wat er wordt getest? welke omgeving wordt gebruikt? welke tools worden gebruikt? welke soorten testen worden er uitgevoerd? Instap- en uitstapcriteria, welke risico's van een belanghebbende worden beperkt? en nog een paar die we in detail zullen bekijken terwijl we verder gaan in deze tutorial.

Strategie voor prestatietests

Het bovenstaande diagram legt uit dat het document Prestatieteststrategie wordt gemaakt tijdens of na de Vereiste-analysefase van het project.

Prestatietestplan

Het Performance Test Plan-document wordt in een later stadium van het project geschreven wanneer de vereisten en ontwerpdocumenten bijna bevroren zijn. Het Prestatietestplan-document bevat alle details van het schema om de strategie of aanpak te implementeren die werd beschreven tijdens de fase van de behoefteanalyse.

Vanaf nu zijn de ontwerpdocumenten bijna klaar, het Performance Test Plan bevat alle details over de te testen scenario's. Het bevat ook meer details over de omgevingen die worden gebruikt voor prestatietestruns, hoeveel cycli van testruns, bronnen, entry-exit criteria en meer. Het Performance Test Plan is geschreven door de Performance Manager of de Performance Test Lead.

Prestatietestplan

Het bovenstaande diagram legt duidelijk uit dat het Prestatietestplan wordt gemaakt tijdens het projectontwerp of na de ontwerpfase op basis van de beschikbaarheid van de ontwerpdocumenten.

Inhoud van het prestatieteststrategiedocument

Laten we nu eens kijken wat er allemaal moet worden opgenomen in een prestatieteststrategiedocument:

#1. Inleiding: Geef een kort overzicht van wat een prestatieteststrategiedocument voor dat specifieke project zal bevatten. Vermeld ook de teams die dit document zullen gebruiken.

hoe vind ik de netwerkbeveiligingssleutel

# 2) Toepassingsgebied: Het definiëren van de scope is erg belangrijk omdat het ons vertelt wat precies de geteste prestatie zal zijn. We moeten heel specifiek zijn bij het definiëren van de scope of een andere sectie.

Schrijf nooit iets gegeneraliseerd. Scope vertelt ons wat er precies voor het hele project wordt getest. We hebben In scope en Out of scope als onderdeel van de scope, In scope beschrijft alle functies die op prestatie getest zullen worden en Out of scope beschrijft de features die niet getest zullen worden.

# 3) Test Nadering: Hier moeten we vermelden over de aanpak die we gaan volgen voor onze prestatietests, zoals elk script zal worden uitgevoerd met een enkele gebruiker om een ​​basislijn te maken en vervolgens zullen deze basislijntests worden gebruikt als referentie voor benchmarking op een later punt van tijd tijdens testruns.

Bovendien wordt elk onderdeel afzonderlijk getest voordat ze samen worden geïntegreerd, enzovoort.

# 4) Test Soorten: Hier noemen we de verschillende soorten tests die moeten worden uitgevoerd, zoals belastingtest, stresstest, duurtest, volumetest enz.

# 5) Test Deliverables: Geef aan wat alle resultaten zullen worden geleverd als onderdeel van prestatietests voor het project, zoals het testrapport, het samenvattingsrapport enz.

# 6) Omgeving: Hier moeten we de details van de omgeving noemen. Omgevingsdetails zijn erg belangrijk omdat hierin wordt beschreven welke besturingssystemen zullen worden gebruikt voor prestatietests.

Als de omgeving een replica van de productie zal zijn of zal het groter of kleiner worden dan de productie en ook de verhouding tussen het vergroten en verkleinen van de afmetingen, dwz zal het de helft van de productie zijn of zal het dubbel zo groot zijn als de productie ?

We moeten ook duidelijk alle patches of beveiligingsupdates vermelden om te worden beschouwd als onderdeel van de ingestelde omgeving en ook tijdens de prestatietest.

# 7) Gereedschap: Hier moeten we alle tools vermelden die zullen worden gebruikt, zoals tools voor het opsporen van defecten, Management tools , Prestatietests en monitoringtools. Sommige Voorbeelden van tools voor het opsporen van defecten is JIRA , Voor beheer van documenten zoals Confluence, voor prestatietests Jmeter en voor monitoring Nagios ​

# 8) Bronnen: Details van de middelen die nodig zijn voor het prestatietestteam worden in deze sectie gedocumenteerd. Bijvoorbeeld , Performance Manager, Performance Test Lead, Performance Testers etc.

# 9) Binnenkomst ​ Uitgang Criteria: In- en uitstapcriteria worden in deze sectie beschreven.

c en c ++ interviewvragen

Bijvoorbeeld,

Toelatingscriteria - De applicatie moet functioneel stabiel zijn voordat de build wordt geïmplementeerd voor prestatietests.

Criteria afsluiten - Alle grote gebreken zijn gesloten en aan de meeste SLA's is voldaan.

# 10) Risico's en risicobeperking: Alle risico's die van invloed zijn op de prestatietests, moeten hier worden vermeld, samen met het beperkingsplan daarvoor. Dit helpt eventuele risico's die zich voordoen tijdens prestatietests of er wordt in ieder geval ruim van tevoren een tijdelijke oplossing voor het risico gepland. Dit zal helpen om de prestatietestschema's op tijd af te ronden zonder de te leveren prestaties te beïnvloeden.

# 11) Afkortingen: Gebruikt voor afkortingen. Bijvoorbeeld, PT - Prestatietest.

# 12) Documentgeschiedenis: Dit bevat de documentversie.

Inhoud van het Prestatietestplan-document

Laten we eens kijken wat er allemaal in een Prestatietestplan-document moet worden opgenomen:

#1. Inleiding: Het is allemaal hetzelfde als vermeld in het Performance Test Strategy-document, in plaats daarvan noemen we alleen Performance Test Plan in plaats van Performance Test Strategy.

# 2) Doelstelling: Wat is het doel van deze prestatietests, wat wordt bereikt door prestatietests uit te voeren, d.w.z. wat zijn de voordelen van prestatietests, moeten hier duidelijk worden vermeld.

# 3) Reikwijdte : Scope van Performance Testing, zowel in scope als buiten scope, wordt hier het bedrijfsproces gedefinieerd.

# 4) Aanpak: De algemene aanpak wordt hier beschreven, hoe prestatietests worden uitgevoerd? Wat zijn de voorwaarden voor het inrichten van de omgeving? etc zijn inbegrepen.

# 5) Architectuur: Details van de applicatie-architectuur moeten hier worden vermeld, zoals het totale aantal applicatieservers, webservers, databaseservers, firewalls, 3rdd party applicatie Load generator machines etc.

# 6) Afhankelijkheden: Alle pre-performance testacties moeten hier worden vermeld, zoals de componenten die getest moeten worden, zijn functioneel stabiel, de omgeving wordt geschaald naar een productie zoals een en is beschikbaar of niet, de testdatum is beschikbaar of niet, er zijn tools voor prestatietests beschikbaar met licenties indien aanwezig, enzovoort.

# 7) Omgeving: We moeten alle details van het systeem vermelden, zoals IP-adres, hoeveel servers enz. We moeten ook duidelijk vermelden hoe de omgeving moet worden ingesteld, zoals de vereisten, eventuele patches die moeten worden bijgewerkt enz.

# 8) Testscenario's: De lijst met te testen scenario's wordt in deze sectie vermeld.

# 9) Mix van werkbelasting: De werkbelastingmix speelt een cruciale rol bij de succesvolle uitvoering van de prestatietest en als de werkbelastingmix de realtime actie van de eindgebruiker niet voorspelt, worden alle testresultaten tevergeefs en eindigen we met slechte prestaties in de productie wanneer de applicatie live gaat.

Daarom is het noodzakelijk om de werklast goed in te richten. Begrijp hoe de gebruikers toegang krijgen tot de applicatie in productie en of de applicatie al beschikbaar is of probeer anders meer details te krijgen van het zakelijke team om het applicatiegebruik goed te begrijpen en de werklast te definiëren.

# 10) Cycli voor uitvoering van prestaties: Details van het aantal prestatietestruns worden in deze sectie beschreven. Bijvoorbeeld, Basislijntest, cyclus 1 50 gebruikerstest enz.

# 11) Prestatieteststatistieken: De details van de verzamelde statistieken worden hier beschreven, deze metrieken zouden in acceptatiecriteria met de afgesproken prestatie-eisen.

# 12) Testresultaten: Noem de deliverables en neem waar mogelijk ook de links naar de documenten op.

# 13) Beheer van defecten: Hier moeten we vermelden hoe de defecten worden behandeld, de ernstniveaus en prioriteitsniveaus moet ook worden beschreven.

# 14) Risicobeheer: Noem de risico's die aan het mitigatieplan zijn verbonden, bijvoorbeeld als de applicatie niet stabiel is en als functionele defecten met hoge prioriteit nog steeds open zijn, dit van invloed zal zijn op de planning van de prestatietestruns en zoals eerder vermeld, helpt dit eventuele risico's die optreden tijdens prestatietests of er wordt in ieder geval ruim van tevoren een tijdelijke oplossing voor het risico gepland.

# 15) Bronnen: Noem de teamdetails samen met hun rollen en verantwoordelijkheden.

# 16) Versiegeschiedenis: Houdt de documentgeschiedenis bij.

# 17) Documentbeoordelingen en goedkeuringen: Dit bevat de lijst met mensen die het definitieve document zullen beoordelen en goedkeuren.

Dus in feite heeft Performance Test Strategy een benadering van Performance Testing en Performance Test Plan heeft de details van de aanpak, daarom gaan ze samen. Sommige bedrijven hebben alleen een prestatietestplan waaraan Approach is toegevoegd, terwijl andere zowel het strategie- als het plandocument afzonderlijk hebben.

Tips om deze documenten te ontwikkelen

Volg de onderstaande richtlijnen bij het ontwerpen van de strategie of een plandocument voor het succesvol uitvoeren van prestatietests.

  • Onthoud altijd dat bij het definiëren van een prestatieteststrategie of testplan we ons moeten concentreren op het testdoel en de reikwijdte. Als onze teststrategie of -plan niet in overeenstemming is met de vereisten of scope, zijn onze tests ongeldig.
  • Probeer je te concentreren en die statistieken op te nemen die belangrijk zijn om vast te leggen tijdens de testrun om eventuele knelpunten in het systeem te identificeren of om de prestaties van de applicatie te zien.
  • Plan de testruns zo dat u niet alle scenario's tegelijk test en het systeem crasht. Voer een aantal testruns uit en verhoog geleidelijk de scenario's en gebruikersbelasting.
  • Probeer in uw aanpak alle apparaten toe te voegen van waaruit uw applicatie wordt benaderd, dit is meestal van toepassing op mobiele apparaten.
  • Zorg altijd voor een sectie Risico's en risicobeperking in uw Strategiedocument, aangezien de vereisten van tijd tot tijd blijven veranderen en deze veranderingen veel impact zullen hebben op de uitvoeringscycli en deadlines die ruim van tevoren aan de klant moeten worden geadresseerd.

Gevolgtrekking

Ik ben er zeker van dat deze tutorial je de verschillen zou hebben geïnformeerd tussen een prestatieteststrategie en -plan, samen met de inhoud ervan, Approach for Mobile Application Performance Testing & Cloud application performance testing op een gedetailleerde manier met voorbeelden.

Bekijk onze aanstaande tutorial voor meer informatie over de manieren om uw prestatietests een boost te geven.

​ Bezoek hier voor een complete serie tutorials over prestatietests

PREV-zelfstudie ​ VOLGENDE zelfstudie

Aanbevolen literatuur

^