what is longevity testing
Tento článok vysvetľuje význam pojmu „ Testovanie dlhovekosti „A ako pomáha posúdiť stabilitu systému alebo produktu a znížiť chyby zistené zákazníkom, t. „ Chyťte chyby interne skôr, ako ich zákazník nájde “.
Na konci tohto článku budú mať QA manažéri, potenciálni zákazníci a testéri spravodlivé vedomosti o:
- Čo je testovanie dlhovekosti?
- Prečo je potrebné testovanie dlhovekosti?
- Plánovanie a vykonávanie testov dlhovekosti
- Aké sú výhody a nevýhody testovania dlhovekosti?
bezplatný softvér na správu kostolov v plnej verzii
Čo sa dozviete:
Čo je testovanie dlhovekosti?
Testovanie dlhovekosti je testovacia aktivita:
- Na dlhšiu dobu overiť stabilitu a prevádzkyschopnosť systému alebo produktu proti príslušnému stavu zaťaženia a stresu s prevádzkou a aplikáciami v reálnom čase.
- Na zníženie výskytu povrchových vád na mieste zákazníka
Vývojový diagram riešenia problémov nahlásených zákazníkom (obr. 1)
Pozadie testovania dlhovekosti
# 1) Spravidla všetko funguje dobre v prvých niekoľkých týždňoch nasadenia produktu alebo po inovácii na najnovšie vydanie softvéru u zákazníka. Avšak v priebehu niekoľkých týždňov začne zákazník hlásiť problémy.
#dva) Mnoho problémov môže byť jednoduchých funkcií, pretože sú hlásené zákazníkom a nie sú ľahko reprodukovateľné interne. Potrebujú veľa času a dôkladnú analýzu vykonanú tímom odborníkov v celom spektre. Tip: Čas = $$$ !!!
# 3) Keď zákazník zistí poruchu, stane sa jedno alebo viac z nasledujúcich prípadov (obr. 1)
- Závažnosť chyby bude mať priamy dopad na podnikanie zákazníka, tj. $$$
- Akákoľvek žiadosť o servisné stredisko pre technickú podporu stojí organizáciu produktového inžinierstva $$$
- Problémy, na ktoré zákazník upozornil, zriedka vyrieši tím technickej podpory front-end
- Takéto žiadosti alebo lístky sú postúpené tímu podpory eskalácie
- Eskalácia vstupeniek na zákazníka bude pre organizáciu stáť viac $$$
- Ak tím eskalácie nie je schopný problém vyriešiť, bude teraz musieť zapojiť technický tím (vývoj a kontrola kvality)
- Doteraz by sa tiež podstatne zvýšili náklady $$$ na vyriešenie problému
- Čím dlhšie je rozlíšenie chyby, tým vyššia je pravdepodobnosť nespokojného zákazníka (zákazníkov), ktorý by nedal opakované objednávky, a najhorší scenár je, keď sa zákazník rozhodne vo vhodnom čase prejsť na riešenie konkurencie. V obidvoch prípadoch však ide o stratu výnosov pre každú organizáciu produktového inžinierstva
4) Vyššie percento takýchto problémov nahlásených zákazníkom súvisí s typickou stabilitou systému alebo produktu v kombinácii s topológiou zákazníka, infraštruktúrou, prenosom a konkrétnou aplikáciou.
Prečo je potrebné testovanie dlhovekosti?
1) Akýkoľvek „nedostatok“, ktorý vznikne na základe hlásenia problému zákazníkom, je zvyčajne testovacím uniknutím.
dva) Všetky takéto chyby stoja zákazníka v konečnom dôsledku ako aj v technickej organizácii, ktorá zákazníkom poskytuje riešenia a služby.
3) V normálnom scenári si mala byť chyba všimnutá interne počas rôznych testovacích cyklov vrátane testu regresie jedným alebo viacerými testermi z testovacieho tímu v závislosti od zložitosti problému.
inicializácia statických premenných c ++
4) Najdôležitejšie je, že také závady, ktoré vzniknú v dôsledku problémov nahlásených zákazníkom, poukazujú aj na vhodný testovací scenár alebo zmeškanie testovacieho prípadu v čase vykonania testovacieho plánu.
5) Mnoho testerov určite zažilo, že konkrétna funkcia zlyháva u zákazníka, ale prechádza interne v rôznych testovacích posteliach, ako sú
- Funkcia
- Regresia
- Naložiť
- Stres
- Výkon
- Systém
- Riešenie
- Alfa
- Beta
6) Je potrebné vziať do úvahy kľúčové pozorovania -
- Počas ľubovoľného cyklu vydania softvéru sú Test systému (SUT) alebo Test zariadenia (DUT) vo všetkých testovacích posteliach často mäkké alebo tvrdé reštarty pre nedostatok vecí, ako je načítanie nového kódu, overenie chyby atď.
- Dokonca aj sady automatizovaného regresného testu zvyčajne reštartujú alebo resetujú vykonanie konkrétneho skriptu testovacieho prípadu alebo série skriptov testovacieho prípadu po vykonaní testu SUT alebo DUT.
- Takže program SUT alebo DUT nebeží dostatočne dlho bez mäkkého alebo tvrdého reštartu
- Zatiaľ čo situácia u zákazníka je úplne iná. Zákazník si nemôže dovoliť časté reštartovanie systému, čo vedie k narušeniu produktivity
- Zákazníci postupujú podľa osvedčených postupov, keď ohlasujú zamýšľané publikum okno s náležitou údržbou, potom vykonajú aktualizáciu softvéru alebo výmenu hardvéru atď.
- Takéto okná údržby môžu trvať konkrétnu dobu od štvrťročnej do ročnej v závislosti od interných pokynov a postupov organizácie zákazníka.
- Skutočný zdravotný stav systému alebo produktu u zákazníka sa v skutočnosti úplne líši od stavu testovacích postelí počas daného cyklu vydania softvéru v ktorejkoľvek organizácii zaoberajúcej sa výrobou produktu.
- Mnoho zákazníkov tiež hľadá autorizovaný dokument kvality, ktorý prešiel konkrétnym testom vertikálneho modelu, najmä finančným, zdravotným a federálnym
Vzhľadom na niekoľko testovacích medzier, ako je uvedené vyššie =>
- Je zrejmé, že systém alebo produkt by mali podstúpiť dlhšie trvanie testov alebo testov dlhovekosti s kompletným scenárom napodobňujúcim stránky zákazníka alebo vertikály.
- Dlhšie trvanie môže byť 72 - 720 hodín. (3 - 30 dní) alebo vhodné trvanie na základe EFD alebo CFD údaje a konkrétne prípady zákazníkov
- Pre manažérov, potenciálnych zákazníkov a testerov QA je odporúčané vykonávať testovanie životnosti ako samostatnú aktivitu v danom cykle vydania softvéru.
- Net-Net, testovanie dlhovekosti je veľmi dôležité pre stabilitu systému alebo produktu, pretože má priamy vzťah k priemernému výsledku organizácie
Plánovanie a vykonávanie testov dlhovekosti
Je dôležité, aby manažéri QA, potenciálni zákazníci a testeri zahrnuli testovanie dlhovekosti ako svoju súčasť celkovej stratégie testovania .
Plánovanie
- Inžinierske organizácie vykonávajú internú analýzu únikových testov ( ČAJ ) cvičenie príležitostne pre mnoho produktov (hardvér a softvér). Niektoré majú dokonca zavedený integrovaný a automatizovaný mechanizmus na vykopávanie údajov Test Escape, ktoré sú zvyčajne založené na „externe nájdených chybách ( EFD ) Alebo „Vady zistené zákazníkom ( CFD ) “Prihlásený tímom podpory eskalácie
- EFD alebo CFD by sa mali starostlivo analyzovať v kontexte nasadenia zákazníka naživo z pohľadu end-to-end, nielen pokiaľ ide o infraštruktúru, ale aj zariadenia, aplikácie, dopravné vzory koncových používateľov.
Pochopenie vertikály zákazníka:
Zákazníci zvyčajne spadajú do jednej z nižšie uvedených širších vertikál:
- Zdravotná starostlivosť
- Maloobchodné
- Financie
- Vzdelávanie
- Preprava
- Výroba
- Strojárstvo
- Federálna vláda
Činnosti
# 1) Vypracujte samostatný testovací plán a testovací prípad pre testovanie dlhovekosti. Pomôže to tiež sledovať vykonávanie testu, zaznamenávanie chýb a overovanie
#dva) Identifikujte testovacie prípady na základe vstupov Analýza úniku z testu - zvyčajne bug scrub EFD alebo CFD
# 3) Je veľmi dôležité, aby tím QA napodobňoval testovacie pracoviská jednej alebo viacerých vertikál v závislosti od odvetvia organizácie s počtom vertikál
# 4) Vyhradené testovacie zariadenia by mali mať
- Topológia siete je podobná topológii zamýšľanej vertikály alebo viacerých vertikál
- Infraštruktúra s podobnými prepínačmi, smerovačmi, servermi typu back-end, bránami firewall atď
- Najčastejšie a najpopulárnejšie používané aplikačné servery z danej vertikály
- Najčastejšie a najobľúbenejšie gadgety pre koncových používateľov z danej vertikály
# 5) Vhodné nástroje na generovanie záťaže, stresu a prenosu v reálnom čase
# 6) Identifikujte zdroj manuálneho vykonania
# 7) Identifikujte zdroj / stratégiu automatizácie pre rýchlejšie a opakované vykonávanie
# 8) Identifikujte ŠTART a KONIEC testovania dlhovekosti pre dané vydanie
Dva prístupy k testovaniu START a END of Longevity Testing:
I) Prístup 1:
c ++ vstupný výstupný súbor
- Softvérový kód alebo hardvér by mali byť v stabilnom stave
- ŠTART na konci dokončenia testu FEATURE
- UKONČIŤ pred zmrazením kódu
II) Prístup 2:
- Urobte mierny zásah povolením mierne nestabilného kódu
- ZAČNITE 70% dokončením testovacieho cyklu FEATURE
- UKONČIŤ pred zmrazením kódu
# 9) Overenie chyby pre vyriešené chyby
# 10) Presuňte testovanie dlhovekosti na regresiu na následné regresné testovanie
Exekúcia
- Nastavte testovacie lôžka tak, aby napodobňovali jednu alebo viac oblastí zákazníka
- Zaistite, aby všetky back-endové Infra, Aplikácia a Databáza vrátane príchutí boli podobné ako u zákazníka
- Zaistite, aby boli zariadenia koncového používateľa podobné tým, ktoré používa zákazník, a aby boli k dispozícii a používané počas vykonávania plánu testu
- Zaistite, aby boli k dispozícii vhodné nástroje na generovanie mierneho stresu a zaťaženia systému alebo produktu
- Vykonajte celú sadu testov z plánu testovania dlhovekosti bez mäkkého alebo tvrdého reštartu systému SUT alebo DUT, serverov typu back-end a ďalších zariadení súvisiacich s infraštruktúrou
- Vyššie uvedeným spôsobom by sa malo uskutočniť niekoľko testovacích cyklov počas definovaného nepretržitého trvania od slotu 72 - 720 hodín.
- Zaznamenajte výsledky
- Zaznamenajte všetky identifikované chyby
- Overte všetky chyby
Aké sú výhody a nevýhody testovania dlhovekosti?
Pros
- Pomáha identifikovať kritické chyby než ho zákazník nájde
- Pomáha stabilizovať systém alebo produkt kvôli jeho opraviteľným funkciám, ktoré sú rozhodujúce pre produktivitu a podnikanie zákazníka
- Pomáha zvyšovať spokojnosť zákazníkov
- Šetrí organizácii veľa nákladov $$$ - ušetrené peniaze sú zarobené peniaze !!!
- Správu o testovaní dlhovekosti je možné zmeniť aj na certifikáty kvality zabezpečujúce rôzne vertikály
Zápory
- Počiatočné náklady na zahrnutie testovania dlhovekosti a súvisiacich aktivít ako súčasť daného vydania a regresných aktivít
- Ideálne sa hodí pre Model vodopádu
- Agilné / scrum modely potrebujú doladiť trvanie a pokrytie
Záver
Mnohé z „defektov“, ktoré vzniknú v dôsledku problémov nahlásených zákazníkom, sú spôsobené predovšetkým funkciou Test Escape. To si zase vyžaduje veľa otázok, ako je vývoj testovacieho plánu, kontrola, pokrytie a realizácia.
Externe nájdené chyby (EFD) alebo chyby nájdené zákazníkom (CFD) majú dopad na podnikanie ($$$) pre zákazníka aj pre organizáciu produktu.
Testovanie dlhovekosti je jedinečné a malo by pomôcť ktorejkoľvek organizácii produktu zlepšiť spokojnosť zákazníka spôsobom identifikácie a riešenia chýb skôr, ako ich zákazník zachytí. Testovanie dlhovekosti tiež pomáha zlepšiť stabilitu, čo vedie k robustnému systému alebo produktu vysokej kvality.
O autorovi: Tento článok je napísaný autorom STH Vinayakom. Má 12 rokov skúseností s QA / testovaním v spoločnostiach Fortune 500.
Ak máte akékoľvek otázky alebo návrhy týkajúce sa tohto článku, dajte nám vedieť.
Odporúčané čítanie
- Najlepšie nástroje na testovanie softvéru 2021 (QA Test Automation Tools)
- Stiahnutie e-knihy Testing Primer
- Testovanie záťaže s výukovými programami HP LoadRunner
- Rozdiel medzi počítačom, klientskym serverom a webom
- Čo je to testovanie gama? Fáza záverečného testovania
- Čo je Testovanie zhody (Testovanie zhody)?
- Úloha pomocníka QA pri testovaní softvéru
- Kognitívne predsudky v testovaní softvéru: Prečo testerom chýbajú chyby?