Meny

Vad är Longevity Testing? Hur man fångar buggarna innan kunden hittar det

what is longevity testing

Prova Vårt Instrument För Att Eliminera Problem

Den här artikeln förklarar innebörden av “ Test av livslängd ”Och hur det hjälper till att bedöma systemets eller produktens stabilitet och minska de fel som kunden har upptäckt, dvs. ' Fånga buggarna internt innan kunden hittar det ”.

I slutet av denna artikel kommer QA Managers, Leads and Testers att ha en rättvis kunskap om:

  • Vad är Longevity Testing?
  • Varför krävs testning av livslängd?
  • Planering och genomförande av livslängdstester
  • Vilka är för- och nackdelarna med test av livslängd?

Test av livslängd

stora dataanalysverktyg öppen källkod

Vad du kommer att lära dig:

Vad är Longevity Testing?

Longevity Testing är en testaktivitet:

  • För att validera system- eller produktstabilitet och användbarhetsfunktioner över en längre period mot lämpligt belastnings- och påfrestningsförhållande med realtidstrafik och applikationer
  • För att minska förekomsten av defekter som dyker upp på kundens webbplats

Flödesdiagram över hantering Kundrapporterade problem (fig. 1)

Vad är Longevity Testing

Bakgrund till Longevity Testing

# 1) Vanligtvis, under de första veckorna av produktdistributionen eller efter en uppgradering till den senaste programvaruversionen på kundwebbplatsen, går allt bra. Under en period på några veckor börjar en kund dock rapportera problemen.

#två) Många av problemen kan vara enkla funktioner eftersom de rapporteras av kunden och inte är lätta att reproducera internt. De behöver mycket tid och noggrann analys av Expert Team över hela spektrumet. Tips: Tid = $$$ !!!

# 3) Ett eller flera av följande händer när kund (er) hittar defekten (fig. 1)

  • Felens allvar kommer att ha en direkt inverkan på kundens verksamhet, dvs $$$
  • Varje serviceförfrågan till Technical Support Center kostar $$$ för Product Engineering Organization
  • Sällan löses de problem som tas upp av kunden av den tekniska supportteamet
  • Sådana förfrågningar eller biljetter eskaleras till Escalation Support Team
  • Eskalering av kundbiljett kostar mer $$$ för organisationen
  • Om Escalation-teamet inte kan lösa problemet, måste det nu involvera Engineering Team (utveckling och kvalitetssäkring)
  • Nu skulle kostnaden $$$ för att lösa problemet också ha höjts väsentligt
  • Längre felupplösning ökar sannolikheten för missnöjda kunder som inte skulle ge upprepade beställningar och det värsta scenariot är när kunden väljer att flytta till en konkurrents lösning vid en lämplig tidpunkt. I båda fallen är det dock en intäktsförlust för någon produktteknikorganisation

4) Den högre procentandelen av sådana problem som rapporterats av en eller flera kunder är relaterad till typiska system- eller produktstabilitet i kombination med kundtopologi, infrastruktur, trafik och applikationsspecifik.

Varför krävs testning av livslängd?

1) Varje ”defekt” som uppstår från kunden rapporterade problemet är vanligtvis en testflykt.

två) Alla sådana brister kostar i grund och botten $$$ för kunden liksom ingenjörsorganisationen som tillhandahåller lösningar och tjänster till kunderna.

3) I ett normalt scenario borde defekten ha upptäckts internt under olika testcykler inklusive regressionstestning av en eller flera testare från testteamet beroende på problemets komplexitet.

4) Viktigast av allt är att sådana defekter som härrör från kundrapporterade problem också påpekar att ett lämpligt testscenario eller att ett testfall missas vid den tidpunkt då testplanen genomförs.

5) Många av testarna måste ha upplevt att en viss funktion misslyckas på kundens webbplats men passerar internt i olika testbäddar som

  • Funktion
  • Regression
  • Ladda
  • Påfrestning
  • Prestanda
  • Systemet
  • Lösning
  • Alfa
  • Beta

6) Viktiga observationer som ska övervägas -

  • Under varje programutgivningscykel, är System Under Test (SUT) eller Device Under Test (DUT) i alla testbäddar ofta mjuka eller hårda omstartade på grund av saker som laddning av ny koddropp, felverifiering etc.
  • Även automatiserade regressionstestpaket startar om eller återställer SUT- eller DUT-postkörningen vanligen för ett visst testfallskript eller en serie testfallskript
  • Så SUT eller DUT går inte tillräckligt länge utan en mjuk eller hård omstart
  • Situationen är helt annorlunda på kundplatsen. Kunden har inte råd att fortsätta att starta om systemet ofta, vilket resulterar i produktivitetsstörningar
  • Kunder följer en beprövad praxis där de tillkännager ett korrekt underhållsfönster för den avsedda publiken och sedan utför programuppgradering eller maskinvarubyte etc.
  • Sådana underhållsfönster kan vara under en viss tid från kvartalsvis till årligen beroende på de interna riktlinjerna och procedurerna i kundens organisation
  • I själva verket är den faktiska hälsobilden av systemet eller produkten på kundwebbplatsen helt annorlunda än den för testbäddar under en viss programutgivningscykel i någon produktteknikorganisation
  • Många kunder letar också efter ett auktoriserat kvalitetsdokument som har klarat en viss testning av vertikala modeller, särskilt ekonomi, hälso- och sjukvård och Federal Verticals

Med tanke på några få testgap som nämnts ovan =>

  • Det är uppenbart att systemet eller produkten borde genomgå längre tester eller livslängdstester med slut-till-slut-scenario som efterliknar kundens webbplats eller vertikaler
  • Längre varaktighet kan vara 72-720 timmar. (3-30 dagar) eller lämplig varaktighet baserat på EFD eller CFD uppgifter och specifika kundärenden
  • Det är en rekommenderad praxis för QA Managers, Leads och Testers att utföra Longevity Testing som en separat aktivitet i en given programvaruutgivningscykel.
  • Net-Net, Longevity Testing är väldigt relevant för systemets eller produktens stabilitet eftersom det har direkt relation till organisationens sista linje $$$

Planering och genomförande av livslängdstester

Det är viktigt att QA-chefer, Leads och Testers inkluderar Longevity Testing som en del av deras övergripande teststrategi .

Planera

Planering och genomförande av livslängdstester

bästa webbplatser att titta på anime online
  • Ingenjörsorganisationer genomför intern testanalys ( TE ) övning då och då för många produkter (hårdvara och programvara). Vissa har till och med en integrerad och automatiserad mekanism för att gräva Test Escape-data vanligtvis baserat på 'Externalally Found Defects ( EFD ) 'Eller' Kundfel ( CFD ) 'Loggad av Support Escalation Team
  • EFD: er eller CFD: er bör analyseras noggrant i samband med kundens Live-distribution från slut-till-slut-perspektiv, inte bara infrastrukturen utan även slutanvändarens enheter, applikationer, trafikmönster

Förstå kundvertikaler:

Kunder faller vanligtvis i en av nedanstående bredare vertikaler:

  • Sjukvård
  • Detaljhandeln
  • Finansiera
  • Utbildning
  • Transport
  • Tillverkning
  • Teknik
  • Federal (regering)

Aktiviteter

# 1) Utveckla en separat testplan och testfall för test av lång livslängd. Detta kommer också att hjälpa till att spåra testkörning, felloggning och verifiering

#två) Identifiera testfall baserat på ingångar för Test Escape-analys - vanligtvis bug-scrub av EFD eller CFD

# 3) Det är mycket viktigt att QA-teamet efterliknar testbäddar för en eller flera vertikaler beroende på organisationens bransch med antal vertikaler

# 4) Dedikerad testbädd (ar) borde ha

  • Nätverkstopologi liknar den för en avsedd vertikal eller flera vertikaler
  • Infrastruktur med liknande switchar, routrar, back-end servrar, brandväggar etc.
  • Oftast använda och populära applikationsservrar från en viss vertikal (er)
  • Oftast använda och ofta använda slutanvändarprylar från en viss vertikal (er)

# 5) Lämpliga verktyg för att skapa belastning, stress och trafik i realtid

# 6) Identifiera manuell körningsresurs

kasta char till sträng c ++

# 7) Identifiera automatiseringsresurs / strategi för snabbare och upprepad körning

# 8) Identifiera START och END för Longevity Testing för en given release

Två tillvägagångssätt för START och SLUT av Longevity Testing:

I) Metod 1:

  • Programvarukod eller hårdvara ska vara i ett stabilt skick
  • Börja i slutet av Färdigställande av testet
  • SLUT före kodfrysning

II) Metod 2:

  • Ta en mindre träff genom att tillåta något instabil kod
  • Börja vid 70% av testcykeln för FEATURE
  • SLUT före kodfrysning

# 9) Felverifiering för lösta defekter

# 10) Flytta livslängdstestning till regression för efterföljande regressionstestning

Avrättning

  • Ställ in testbäddarna för att efterlikna en eller flera kundvertikaler
  • Se till att alla back-end-infra-, applikations- och databas inklusive smaker liknar kundens
  • Se till att slutanvändarenheterna liknar den som kunden använder är tillgängliga och används under körning av testplanen
  • Se till att lämpliga verktyg finns tillgängliga för att generera måttlig stress och belastning på systemet eller produkten
  • Kör hela testpaketet från Longevity-testplanen utan mjuk eller hård omstart av SUT eller DUT, back-end-servrar och andra Infra-relaterade enheter
  • Flera testkörningar bör köras på ovanstående sätt under en definierad oavbruten varaktighet från kortplats 72-720 timmar.
  • Spela in resultaten
  • Logga alla identifierade buggar
  • Verifiera alla buggar

Vilka är för- och nackdelarna med test av lång livslängd?

Fördelar

  • Hjälper identifiera kritiska buggar innan kunden hittar det
  • Hjälper till att stabilisera systemet eller produkten för dess användbara funktion som är avgörande för kundens produktivitet och verksamhet
  • Hjälper till att öka kundnöjdheten
  • Sparar massor av kostnader $$$ till organisationen - sparade pengar är tjänade pengar !!!
  • Testrapporten för livslängd kan också förvandlas till ett kvalitetscertifieringssäkert för olika vertikaler

Nackdelar

  • Initial kostnad för att inkludera Longevity Testing och dess relaterade aktiviteter som en del av en given release- och regressionsaktiviteter
  • Perfekt för Vattenfall modell
  • Agile / Scrum-modeller behöver justeras av varaktighet och täckning

Slutsats

Många av de ”defekter” som uppstår på grund av kundrapporterade problem beror främst på Test Escape. Detta i sin tur ber om många frågor som testplanutveckling, granskning, täckning och utförande.

Externally Found Defects (EFD) eller Customer Found Defects (CFD) har en affärseffekt ($$$) för kunden såväl som för produktorganisationen.

Livslängdstestning är unik och bör hjälpa alla produktorganisationer att förbättra kundnöjdheten genom att identifiera och lösa brister innan kunden får dem. Longevity Testing hjälper också till att förbättra stabiliteten och resulterar i robust kvalitetssystem eller produkt.

Om författaren: Denna artikel är skriven av STH-författaren Vinayak. Han har 12 års QA / testerfarenhet i Fortune 500-företag.

Låt oss veta om du har några frågor eller förslag om den här artikeln.

Rekommenderad läsning

^