Menu

Hvad er Longevity Testing? Sådan fanges fejlene, før kunden finder det

what is longevity testing

Prøv Vores Instrument Til At Fjerne Problemer

Denne artikel forklarer betydningen af ​​“ Test af levetid ”Og hvordan det hjælper med at vurdere systemets eller produktets stabilitet og reducere de mangler, som kunden har fundet, dvs. ' Fang bugs internt, før kunden finder det ”.

I slutningen af ​​denne artikel vil QA Managers, Leads og Testers have en god viden om:

  • Hvad er Longevity Testing?
  • Hvorfor kræves test af levetid?
  • Planlægning og udførelse af levetidstests
  • Hvad er fordele og ulemper ved test af lang levetid?

Test af levetid

den bedste spilfremstillingssoftware til begyndere

Hvad du lærer:

Hvad er Longevity Testing?

Test af lang levetid er en testaktivitet:

  • At validere system- eller produktstabilitet og servicefunktioner over en længere periode mod passende belastning og stresstilstand med realtids trafik og applikationer
  • For at reducere forekomsten af ​​mangler, der vises på kundens websted

Flowdiagram over håndtering af kunde rapporterede problemer (fig. 1)

Hvad er Longevity Testing

Baggrund for test af lang levetid

# 1) Normalt kører alle ting i de første par uger af produktimplementeringen eller efter en opgradering til den seneste softwareudgivelse på kundens websted. Men over en periode på få uger begynder en kunde at rapportere problemerne.

#to) Mange af problemerne kan være enkle funktioner, da de rapporteres af kunden og ikke er lette at reproducere internt. De har brug for meget tid og omhyggelig analyse af Expert Team på tværs af spektret. Tip: Tid = $$$ !!!

# 3) Ét eller flere af følgende sker, når kunde (r) finder manglen (fig. 1)

  • Fejlens sværhedsgrad vil have en direkte indvirkning på kundens forretning, dvs. $$$
  • Enhver serviceanmodning til Technical Support Center koster $$$ for Product Engineering Organization
  • Sjældent løses de problemer, som kunden rejser, af det tekniske supportteams frontend
  • Sådanne anmodninger eller billetter eskaleres til Escalation Support Team
  • Eskalering af kundebilletter koster mere $$$ for organisationen
  • Hvis eskaleringsteam ikke er i stand til at løse problemet, bliver det nu nødt til at involvere Engineering Team (Udvikling og QA)
  • På nuværende tidspunkt ville omkostningerne $$$ til at løse problemet også have rejst sig væsentligt
  • Jo længere fejlopløsningen er større, er sandsynligheden for utilfredse kunder, der ikke giver gentagne ordrer, og det værste scenarie er, når kunden beslutter at flytte til en konkurrents løsning på et passende tidspunkt. I begge tilfælde er det dog et tab af indtægter for enhver Product Engineering Organization

4) Den højere procentdel af sådanne problemer rapporteret af en eller flere kunder er relateret til typisk system- eller produktstabilitet i kombination med kundetopologi, infrastruktur, trafik og applikationsspecifik.

Hvorfor kræves test af levetid?

1) Enhver 'defekt', der opstår som følge af kunden, rapporterede problemet er normalt en testflyvning.

to) Enhver sådan mangel koster bundlinjen $$$ for kunden såvel som ingeniørorganisationen, der leverer løsninger og tjenester til kunderne.

3) I et normalt scenarie skulle defekten have været bemærket internt under forskellige testcyklusser, herunder regressionstest af en eller flere testere fra testteamet afhængigt af problemets kompleksitet.

4) Vigtigst er det, at sådanne mangler, der opstår som følge af kunderapporterede problemer, også påpeger, at et passende testscenarie eller en testtilfælde bliver savnet på tidspunktet for udførelsen af ​​testplanen.

5) Mange af testerne skal have oplevet, at en bestemt funktion mislykkes på kundens websted, men passerer internt i forskellige testbeds som

  • Funktion
  • Regression
  • belastning
  • Stress
  • Ydeevne
  • System
  • Opløsning
  • Alpha
  • Beta

6) Nøgleobservationer, der skal overvejes -

  • Under enhver softwareudgivelsescyklus genstartes System Under Test (SUT) eller Device Under Test (DUT) i alle testbeds ofte blødt eller hårdt, fordi der mangler ting som indlæsning af nyt kodefald, fejlbekræftelse osv.
  • Selv automatiserede regressionstestpakker genstarter eller nulstiller normalt SUT eller DUT efter udførelse af et bestemt test case script eller en række test case scripts
  • Så SUT eller DUT kører ikke længe nok uden en blød eller hård genstart
  • Mens situationen er en helt anden på kundens websted. Kunden har ikke råd til at fortsætte med at genstarte systemet ofte, hvilket resulterer i produktivitetsforstyrrelser
  • Kunder følger en velprøvet praksis, hvor de annoncerer et korrekt vedligeholdelsesvindue til det tilsigtede publikum og derefter udfører softwareopgradering eller udskiftning af hardware osv.
  • Sådanne vedligeholdelsesvinduer kan have en bestemt varighed fra kvartalsvis til årligt afhængigt af de interne retningslinjer og procedurer i kundens organisation
  • I virkeligheden er det faktiske helbredsbillede af systemet eller produktet på kundens websted helt anderledes end det for testbeds under en given softwareudgivelsescyklus i enhver produktteknikorganisation
  • Mange kunder ser også efter et autoriseret kvalitetsdokument, der har bestået en bestemt test af lodret model, især økonomi, sundhedsvæsen og føderale lodret

I betragtning af få testhuller som nævnt ovenfor =>

  • Det er åbenlyst, at systemet eller produktet skal gennemgå længere varighed af tests eller levetidstest med end-to-end-scenarie, der efterligner kundesite eller vertikaler
  • Længere varighed kan være 72-720 timer. (3-30 dage) eller passende varighed baseret på EFD eller CFD data og specifikke kundesager
  • Det er en anbefalet praksis for QA Managers, Leads og Testers at udføre Longevity Testing som en separat aktivitet i en given softwareudgivelsescyklus
  • Net-Net, Longevity Testing er meget relevant for systemets eller produktets stabilitet, da det har direkte relation til bundlinjen $$$ i organisationen

Planlægning og udførelse af levetidstests

Det er vigtigt, at QA Managers, Leads og Testers inkluderer Longevity Testing som en del af deres overordnede teststrategi .

Planlægning

Planlægning og udførelse af levetidstest

hvordan man fjerner et element fra en matrix i java
  • Ingeniørorganisationer udfører intern testanalyseanalyse ( TE ) træning fra tid til anden for mange produkter (hardware og software). Nogle har endda en integreret og automatiseret mekanisme til at grave Test Escape-data normalt baseret på 'Eksternt fundne defekter ( EFD ) 'Eller' Kundefundne mangler ( CFD ) ’Logget af Support Escalation Team
  • EFD'er eller CFD'er bør analyseres omhyggeligt i sammenhæng med kundens Live-implementering fra ende til slut perspektiv, ikke kun infrastrukturen, men også slutbrugerenheder, applikationer, trafikmønstre

Forståelse af kundevertikaler:

Kunder falder normalt ind i en af ​​nedenstående bredere vertikaler:

  • Sundhedspleje
  • Detailhandel
  • Finansiere
  • Uddannelse
  • Transport
  • Fremstilling
  • ingeniørarbejde
  • Føderal (regering)

Aktiviteter

# 1) Udvikl en separat testplan og testkasse til lang levetidstest. Dette hjælper også med at spore testudførelsen, bugglogging og verifikation

#to) Identificer testsager baseret på input fra Test Escape-analyse - normalt bug scrub af EFD'er eller CFD'er

# 3) Det er meget vigtigt, at QA-team efterligner testborde med en eller flere lodrette sider afhængigt af organisationens forretningsområde med antal lodrette

# 4) Dedikeret testseng (er) skal have

  • Netværkstopologi svarende til en bestemt vertikal eller flere vertikale
  • Infrastruktur med lignende switche, routere, back-end-servere, firewalls osv
  • Ofte anvendte og mest populære applikationsservere fra en given lodret (e)
  • Ofte og mest populære slutbruger-gadgets fra en given lodret (e)

# 5) Passende værktøjer til generering af belastning, stress og trafik i realtid

# 6) Identificer manuel udførelsesressource

c ++ fejl udefineret henvisning til

# 7) Identificer automatiseringsressource / -strategi til hurtigere og gentagen udførelse

# 8) Identificer START og END for Longevity Testing for en given frigivelse

To tilgange til START og END af Longevity Testing:

I) Fremgangsmåde 1:

  • Softwarekode eller hardware skal være i en stabil tilstand
  • START ved afslutningen af ​​FÆRDIGHED Testafslutning
  • SLUT før kodefrysning

II) Fremgangsmåde 2:

  • Tag et mindre hit ved at tillade let ustabil kode
  • START ved 70% afslutning af FEATURE testcyklus
  • SLUT før kodefrysning

# 9) Fejlbekræftelse for løste mangler

# 10) Flyt test af levetid til regression for efterfølgende regressionstest

Udførelse

  • Opsæt testbed (e) til at efterligne en eller flere kundevertikaler
  • Sørg for, at alle back-end-infra-, applikations- og databaser inklusive smag svarer til kundens
  • Sørg for, at slutbrugerenheder svarer til kundens brug, er tilgængelige og bruges under udførelse af testplan
  • Sørg for, at passende værktøjer er tilgængelige til at generere moderat stress og belastning af systemet eller produktet
  • Udfør hele testpakken fra Longevity-testplanen uden blød eller hård genstart af SUT eller DUT, back-end-servere til andre Infra-relaterede enheder
  • Flere testkørsler skal køres på ovenstående måde i en defineret non-stop-varighed fra slot 72-720 timer.
  • Optag resultaterne
  • Log alle identificerede fejl
  • Bekræft alle fejlene

Hvad er fordele og ulemper ved test af lang levetid?

Fordele

  • Hjælper identificer kritiske fejl inden kunden finder det
  • Hjælper med at stabilisere systemet eller produktet for dets servicefunktion, der er kritisk for kundens produktivitet og forretning
  • Hjælper med at øge kundetilfredsheden
  • Sparer masser af omkostninger $$$ til organisationen - sparede penge er tjente penge !!!
  • Langtidsprøvningsrapport kan også omdannes til et kvalitetscertificeringssikkert, der passer til forskellige vertikaler

Ulemper

  • Startomkostninger til inkludering af Longevity Testing og dets relaterede aktiviteter som en del af en given frigivelses- og regressionsaktiviteter
  • Ideel til Vandfaldsmodel
  • Agile / Scrum-modeller har brug for tilpasning af varighed og dækning

Konklusion

Mange af de 'defekter', der opstår som følge af kunderapporterede problemer, skyldes primært Test Escape. Dette beder igen om mange spørgsmål som testplanudvikling, gennemgang, dækning og udførelse.

Eksternt fundne mangler (EFD) eller kundefundne mangler (CFD) har en forretningsmæssig ($$$) indvirkning for kunden såvel som for produktorganisationen.

Test af lang levetid, der er unik, skal hjælpe enhver produktorganisation med at forbedre kundetilfredsheden ved at identificere og løse mangler, før kunden fanger dem. Test af lang levetid hjælper også med at forbedre stabiliteten, hvilket resulterer i robust kvalitetssystem eller produkt.

Om forfatteren: Denne artikel er skrevet af STH-forfatter Vinayak. Han har 12 års QA / test-erfaring i Fortune 500-virksomheder.

Fortæl os, hvis du har spørgsmål eller forslag til denne artikel.

Anbefalet læsning

^