what is longevity testing
In dit artikel wordt de betekenis van ' Levensduur testen ”En hoe het helpt om de stabiliteit van het systeem of het product te beoordelen en de door de klant gevonden defecten te verminderen, d.w.z. Vang de bugs intern op voordat de klant ze vindt
Aan het einde van dit artikel hebben QA-managers, leads en testers een behoorlijke kennis over:
- Wat is een lange levensduur testen?
- Waarom is testen op lange levensduur vereist?
- Planning en uitvoering van levensduurtests
- Wat zijn de voor- en nadelen van langleven testen?
beste gratis hulpprogramma voor het opschonen van Windows 10
Wat je leert:
Wat is een lange levensduur testen?
Levensduur testen is een testactiviteit:
- Om systeem- of productstabiliteits- en onderhoudsfuncties over een langere periode te valideren tegen de juiste belastings- en stressconditie met realtime verkeer en toepassingen
- Om het voorkomen van defecten die opduiken op de site van de klant te verminderen
Stroomschema voor het afhandelen van door de klant gemelde problemen (afb.1)
Achtergrond bij het testen van de levensduur
# 1) Gewoonlijk loopt alles goed in de eerste paar weken van de implementatie van het product of na een upgrade naar de nieuwste softwareversie op de locatie van de klant. Over een periode van enkele weken begint een klant echter de problemen te melden.
#twee) Veel van de problemen kunnen eenvoudige kenmerken zijn, aangezien ze door de klant worden gerapporteerd en niet gemakkelijk intern kunnen worden gereproduceerd. Ze hebben veel tijd nodig en een zorgvuldige analyse door een expertteam over het hele spectrum. Hint: Tijd = $$$ !!!
# 3) Een of meer van de volgende situaties gebeuren wanneer de klant (en) het defect constateert (Fig.1)
- Ernst van het defect heeft een directe impact op het bedrijf van de klant, d.w.z. $$$
- Elke serviceverzoek aan het technische ondersteuningscentrum kost $ $ aan de Product Engineering Organization
- Zelden worden de door de klant aangekaarte problemen opgelost door het frontend technische ondersteuningsteam
- Dergelijke verzoeken of tickets worden geëscaleerd naar het Escalation Support Team
- Klantticket-escalatie kost de organisatie meer $ $ $
- Als het Escalatieteam het probleem niet kan oplossen, moet het nu het Engineering Team (Ontwikkeling en QA) erbij betrekken
- Inmiddels zouden de kosten $ $ om het probleem op te lossen ook aanzienlijk zijn gestegen
- Hoe langer de defectoplossing, hoe groter de kans op ontevreden klant (en) die geen herhaalbestellingen zouden geven en het ergste scenario is wanneer de klant besluit om op een geschikt moment over te stappen naar de oplossing van een concurrent. In beide gevallen is het echter een inkomstenverlies voor elke productengineeringorganisatie
4) Het hogere percentage van dergelijke problemen dat door een klant (en) wordt gemeld, houdt verband met typische systeem- of productstabiliteit in combinatie met klanttopologie, infrastructuur, verkeer en applicatiespecifiek.
Waarom is testen op lange levensduur vereist?
1) Elk ‘defect’ dat voortkomt uit de door de klant gerapporteerde kwestie, is meestal een testvlucht.
twee) Dergelijke defecten kosten de klant uiteindelijk $ $ $, evenals de technische organisatie die oplossingen en diensten aan de klanten levert.
3) In een normaal scenario zou het defect intern opgemerkt moeten zijn tijdens verschillende testcycli, inclusief regressietesten door een of meer testers van het testteam, afhankelijk van de complexiteit van het probleem.
4) Het belangrijkste is dat dergelijke defecten die voortkomen uit door de klant gerapporteerde problemen ook wijzen op een geschikt testscenario of een testcase die wordt gemist op het moment dat het testplan wordt uitgevoerd.
5) Veel van de testers moeten hebben ervaren dat een bepaalde functie op de locatie van de klant niet werkt, maar intern doorgaat in verschillende testbanken, zoals
- Voorzien zijn van
- Regressie
- Laden
- Spanning
- Prestatie
- Systeem
- Oplossing
- Alpha
- Bèta
6) Belangrijkste opmerkingen die in overweging moeten worden genomen
- Tijdens elke softwarereleasecyclus worden System Under Test (SUT) of Device Under Test (DUT) in alle testbeds vaak zacht of hard opnieuw opgestart bij gebrek aan zaken als het laden van nieuwe codering, bugverificatie enz.
- Zelfs geautomatiseerde regressietestsuites starten meestal de SUT of DUT opnieuw op of resetten na uitvoering van een bepaald testcase-script of een reeks testcase-scripts
- Dus de SUT of DUT loopt niet lang genoeg zonder een zachte of harde herstart
- Terwijl de situatie bij de klant heel anders is. De klant kan het zich niet veroorloven om het systeem regelmatig opnieuw op te starten, waardoor de productiviteit wordt verstoord
- Klanten volgen een beproefde praktijk waarbij ze een goed onderhoudsvenster aankondigen aan het beoogde publiek en vervolgens een software-upgrade of hardwarevervanging enz. Uitvoeren.
- Dergelijke onderhoudsvensters kunnen voor een specifieke duur zijn, van Kwartaal tot Jaarlijks, afhankelijk van de interne richtlijnen en procedures van de organisatie van de Klant
- In werkelijkheid is het werkelijke gezondheidsbeeld van het systeem of het product op de locatie van de klant geheel anders dan dat van testbeds tijdens een bepaalde softwarereleasecyclus in een productengineeringorganisatie
- Veel klanten zoeken ook naar een geautoriseerd kwaliteitsdocument dat bepaalde verticale modeltests heeft doorstaan, met name financiële, medische en federale branches
Gezien enkele test-hiaten zoals hierboven vermeld =>
- Het is duidelijk dat het systeem of het product een langere duur van tests of levensduurtests moet ondergaan met een end-to-end-scenario dat de klantensite of de branches nabootst
- Een langere duur kan 72-720 uur zijn. (3-30 dagen) of passende duur op basis van EFD of CFD gegevens en specifieke klantcases
- Het is een aanbevolen praktijk voor QA Managers, Leads en Testers om Longevity Testing uit te voeren als een aparte activiteit in een bepaalde softwarereleasecyclus
- Net-Net, Longevity Testing is zeer relevant voor de stabiliteit van het systeem of het product aangezien het een directe relatie heeft met de bottom-line $$$ van de organisatie
Planning en uitvoering van levensduurtests
Het is belangrijk dat QA-managers, leads en testers Longevity Testing opnemen als onderdeel van hun algemene teststrategie
Planning
- Engineering-organisaties voeren in-house Test Escape Analysis uit ( THEE ) oefening van tijd tot tijd voor veel producten (hardware en software). Sommige hebben zelfs een geïntegreerd en geautomatiseerd mechanisme om Test Escape-gegevens te graven, meestal gebaseerd op 'Extern gevonden defecten ( EFD ) ’Of‘ Door de klant gevonden gebreken ( CFD ) 'Vastgelegd door Support Escalation Team
- EFD's of CFD's moeten zorgvuldig worden geanalyseerd in de context van de Live-implementatie van de klant vanuit end-to-end-perspectief, niet alleen de infrastructuur, maar ook de apparaten, applicaties en verkeerspatronen van de eindgebruiker
Inzicht in klantvertalingen:
Klanten vallen meestal in een van de onderstaande bredere branches:
vriend functies in c ++
- Gezondheidszorg
- Kleinhandel
- Financiën
- Onderwijs
- Vervoer
- Productie
- Engineering
- Federaal (Govt)
Activiteiten
# 1) Ontwikkel een afzonderlijk testplan en testcase voor het testen van de levensduur. Dit zal ook helpen om de testuitvoering, het loggen van bugs en verificatie bij te houden
#twee) Identificeer testcases op basis van Test Escape Analysis-invoer - meestal bugscrub van EFD's of CFD's
# 3) Het is erg belangrijk dat het QA-team testbedden van een of meer branches nabootst, afhankelijk van de branche van de organisatie met het aantal branches
# 4) Eigen testbed (den) zouden moeten hebben
- Netwerktopologie vergelijkbaar met die van een beoogde verticale of meerdere branches
- Infrastructuur met vergelijkbare switches, routers, back-endservers, firewalls enz
- De meest frequent en in de volksmond gebruikte applicatieservers van een bepaalde branche (s)
- Meest gebruikte en meest gebruikte gadgets voor eindgebruikers van een bepaalde branche (s)
# 5) Passende tools voor het genereren van belasting, stress en realtime verkeer
# 6) Identificeer de bron voor handmatige uitvoering
# 7) Identificeer Automation-resource / -strategie voor snellere en herhaalde uitvoering
# 8) Identificeer START en EINDE van Longevity Testing voor een bepaalde release
Twee benaderingen voor START en EINDE van Longevity Testing:
I) Benadering 1:
- Softwarecode of hardware moet in een stabiele toestand verkeren
- BEGIN aan het einde van FEATURE Test Voltooiing
- EINDE voor code bevriezen
II) Benadering 2:
- Neem een kleine treffer door enigszins onstabiele code toe te staan
- BEGIN bij de 70% voltooiing van de FEATURE-testcyclus
- EINDE voor code bevriezen
# 9) Bugverificatie voor opgeloste defecten
# 10) Verplaats Longevity Testing naar Regressie voor daaropvolgende regressietests
Uitvoering
- Stel de testbed (den) in om een of meer klantverticals na te bootsen
- Zorg ervoor dat alle back-end Infra, Applicatie en Database inclusief smaken vergelijkbaar zijn met die van de klant
- Zorg ervoor dat apparaten van eindgebruikers vergelijkbaar zijn met die van de klant, beschikbaar zijn en worden gebruikt tijdens de uitvoering van het testplan
- Zorg ervoor dat de juiste tools beschikbaar zijn om een matige belasting en belasting van het systeem of product te genereren
- Voer de volledige testsuite uit vanuit het Longevity-testplan zonder soft of hard reboot van SUT of DUT, back-end servers en andere Infra-gerelateerde apparaten
- Meerdere tests moeten op de bovenstaande manier worden uitgevoerd voor een gedefinieerde non-stop duur vanaf het slot 72-720 uur.
- Noteer de resultaten
- Log alle geïdentificeerde bugs
- Verifieer alle bugs
Wat zijn de voor- en nadelen van testen op een lange levensduur?
Voordelen
- Helpt identificeer kritieke bugs voordat de klant het vindt
- Helpt het systeem of product te stabiliseren vanwege de bruikbare functie die essentieel is voor de productiviteit en het bedrijf van de klant
- Helpt de klanttevredenheid te verhogen
- Bespaart veel kosten $$$ voor de organisatie - bespaard geld is verdiend !!!
- Het testrapport voor de levensduur kan ook worden omgezet in een kwaliteitscertificeringsbewijs voor verschillende branches
Nadelen
- Initiële kosten voor het opnemen van Longevity Testing en de gerelateerde activiteiten als onderdeel van een bepaalde release en regressieactiviteiten
- Uitermate geschikt voor Waterval model
- Agile / Scrum-modellen moeten worden aangepast aan duur en dekking
Gevolgtrekking
Veel van de ‘Defecten’ die voortkomen uit door de klant gemelde problemen, zijn voornamelijk te wijten aan Test Escape. Dit roept op zijn beurt veel vragen op, zoals de ontwikkeling, beoordeling, dekking en uitvoering van testplannen.
beste gratis mp3-downloader voor pc
Extern gevonden defecten (EFD) of door de klant gevonden defecten (CFD) hebben een zakelijke ($$$) impact voor zowel de klant als de productorganisatie.
Omdat Longevity Testing uniek is, zou het elke productorganisatie moeten helpen om de klanttevredenheid te verbeteren door defecten te identificeren en op te lossen voordat de klant ze opmerkt. Longevity Testing helpt ook de stabiliteit te verbeteren, wat resulteert in een robuust kwaliteitssysteem of product.
Over de auteur: Dit artikel is geschreven door STH-auteur Vinayak. Hij heeft 12 jaar ervaring met QA / testen bij Fortune 500-bedrijven.
Laat het ons weten als u vragen of suggesties heeft over dit artikel.
Aanbevolen literatuur
- Beste softwaretesttools 2021 (QA Test Automation Tools)
- Primer eBook downloaden testen
- Laadtests met HP LoadRunner-zelfstudies
- Verschil tussen Desktop, Client Server Testing en Web Testing
- Wat is gammatesten? De laatste testfase
- Wat is conformiteitstesten (conformiteitstesten)?
- Software testen QA Assistant Job
- Cognitieve bias bij het testen van software: waarom missen testers bugs?