Menu

Co je testování dlouhověkosti? Jak chytit chyby, než je zákazník najde

what is longevity testing

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Tento článek vysvětluje význam „ Testování dlouhověkosti „A jak pomáhá posoudit stabilitu systému nebo produktu a snížit vady zjištěné zákazníkem, tj. ' Chyťte chyby doma, než je zákazník najde “.

Na konci tohoto článku budou mít QA Managers, Leads and Testers spravedlivé znalosti o:

  • Co je testování dlouhověkosti?
  • Proč je vyžadováno testování dlouhověkosti?
  • Plánování a provádění testů dlouhověkosti
  • Jaké jsou výhody a nevýhody testování dlouhověkosti?

Testování dlouhověkosti

html5 otázky a odpovědi na pohovor pdf

Co se naučíte:

Co je testování dlouhověkosti?

Testování dlouhověkosti je testovací aktivitou:

  • Ověření funkcí stability a provozuschopnosti systému nebo produktu po delší dobu proti příslušnému stavu zátěže a stresu s provozem a aplikacemi v reálném čase
  • Omezit výskyt vad na povrchu zákazníka

Vývojový diagram řešení problémů nahlášených zákazníkem (obr. 1)

Co je testování dlouhověkosti

Pozadí testování dlouhověkosti

# 1) Obvykle vše v prvních týdnech nasazení produktu nebo po upgradu na nejnovější verzi softwaru u zákazníka běží dobře. Během několika týdnů však zákazník začne hlásit problémy.

#dva) Mnoho problémů může být jednoduchých funkcí, protože jsou hlášeny zákazníkem a nejsou snadno reprodukovatelné interně. Potřebují spoustu času a pečlivou analýzu odborným týmem napříč spektrem. Tip: Čas = $$$ !!!

# 3) Pokud zákazník zjistí vadu, dojde k jedné nebo více z následujících situací (obr. 1)

  • Závažnost vady bude mít přímý dopad na podnikání zákazníka, tj. $$$
  • Jakýkoli požadavek na servisní středisko stojí organizaci pro produktové inženýrství $$$
  • Problémy vznesené zákazníkem jsou zřídka vyřešeny týmem technické podpory front-end
  • Takové žádosti nebo lístky jsou předávány týmu podpory eskalace
  • Eskalace zákaznických lístků bude pro organizaci stát více $$$
  • Pokud tým eskalace nedokáže problém vyřešit, bude nyní muset zapojit technický tým (vývoj a QA)
  • Náklady na vyřešení problému by se nyní podstatně zvýšily
  • Čím delší je rozlišení vady, tím vyšší je pravděpodobnost nespokojeného zákazníka (zákazníků), který by nedal opakované objednávky, a nejhorší scénář je, když se zákazník rozhodne ve vhodnou dobu přejít na řešení konkurence. V obou případech však jde o ztrátu příjmů pro jakoukoli organizaci produktového inženýrství

4) Vyšší procento takových problémů hlášených zákazníkem (zákazníky) souvisí s typickou stabilitou systému nebo produktu v kombinaci s topologií zákazníka, infrastrukturou, provozem a aplikací.

Proč je vyžadováno testování dlouhověkosti?

1) Jakýkoli „defekt“, který vznikne na základě nahlášeného problému zákazníkem, je obvykle testovací únik.

dva) Všechny takové vady stojí zákazníka, stejně jako inženýrskou organizaci, která zákazníkům poskytuje řešení a služby, na spodním řádku $$$.

3) V normálním scénáři by si defekt měl všimnout interně během různých testovacích cyklů, včetně regresního testování jedním nebo více testery z testovacího týmu v závislosti na složitosti problému.

4) Nejdůležitější je, že takové vady vzniklé z problémů nahlášených zákazníkem také poukazují na vhodný testovací scénář nebo testovací případ zmeškaný v okamžiku provedení testovacího plánu.

5) Mnoho testerů muselo mít zkušenost s tím, že konkrétní funkce u zákazníka selhává, ale předává se interně v různých testovacích postelích, jako je

  • Vlastnosti
  • Regrese
  • Zatížení
  • Stres
  • Výkon
  • Systém
  • Řešení
  • Alfa
  • Beta

6) Je třeba vzít v úvahu klíčová pozorování -

  • Během jakéhokoli cyklu vydání softwaru jsou Test systému (SUT) nebo Test zařízení (DUT) ve všech testovacích postelích často měkké nebo tvrdé restarty kvůli nedostatkům, jako je načítání nového kódu, ověření chyby atd.
  • Dokonce i sady pro automatický regresní test obvykle restartují nebo resetují spuštění SUT nebo DUT po provedení konkrétního skriptu testovacího případu nebo řady skriptů testovacích případů
  • SUT nebo DUT tedy neběží dostatečně dlouho bez měkkého nebo tvrdého restartu
  • Zatímco u zákazníka je situace úplně jiná. Zákazník si nemůže dovolit časté restartování systému, což má za následek narušení produktivity
  • Zákazníci dodržují osvědčený postup, při kterém oznámí zamýšlené publikum okno pro správnou údržbu a poté provedou upgrade softwaru nebo výměnu hardwaru atd.
  • Taková okna údržby mohou být na konkrétní dobu od čtvrtletní do roční v závislosti na interních pokynech a postupech organizace zákazníka.
  • Ve skutečnosti je skutečný zdravotní stav systému nebo produktu u zákazníka zcela odlišný od stavu testovacích lůžek během daného cyklu vydání softwaru v jakékoli organizaci produktu Engineering.
  • Mnoho zákazníků také hledá autorizovaný dokument kvality, který prošel konkrétním testem vertikálního modelu, zejména finanční, zdravotní a federální

Vzhledem k několika testovacím mezerám, jak je uvedeno výše =>

  • Je zřejmé, že systém nebo produkt by měly podstoupit delší dobu testů nebo testů dlouhověkosti se scénářem end-to-end napodobujícím web zákazníka nebo vertikály
  • Delší doba může být 72–720 hodin. (3–30 dní) nebo vhodné trvání na základě EFD nebo CFD údaje a konkrétní případy zákazníků
  • Doporučenou praxí pro QA manažery, potenciální zákazníky a testery je provádět testování dlouhověkosti jako samostatnou aktivitu v daném cyklu vydání softwaru.
  • Net-Net, testování dlouhověkosti je velmi důležité pro stabilitu systému nebo produktu, protože má přímý vztah ke spodním řádku $$$ organizace

Plánování a provádění testů dlouhověkosti

Je důležité, aby manažeři, vedoucí a testeři QA zahrnuli testování dlouhověkosti jako součást svých celková testovací strategie .

Plánování

Plánování a provádění testů životnosti

  • Inženýrské organizace provádějí interní analýzu únikových testů ( ČAJ ) cvičení čas od času pro mnoho produktů (hardware a software). Někteří dokonce mají integrovaný a automatizovaný mechanismus k vykopávání dat Test Escape, obvykle založených na „Externě nalezených defektech ( EFD ) Nebo „Vady nalezené zákazníkem ( CFD ) “Přihlášený týmem podpory eskalace
  • EFD nebo CFD by měly být pečlivě analyzovány v kontextu nasazení zákazníka naživo z pohledu end-to-end, nejen infrastruktury, ale také koncových uživatelských zařízení, aplikací, vzorců provozu

Porozumění vertikálám zákazníků:

Zákazníci obvykle spadají do jedné z níže uvedených širších vertikál:

  • Zdravotní péče
  • Maloobchodní
  • Finance
  • Vzdělání
  • Přeprava
  • Výrobní
  • Inženýrství
  • Federální (vláda)

Činnosti

# 1) Vypracujte samostatný testovací plán a testovací případ pro testování dlouhověkosti. To také pomůže sledovat provádění testu, protokolování chyb a ověřování

Otázky a odpovědi na rozhovor s j2ee pro starší vývojáře

#dva) Identifikujte testovací případy na základě vstupů Testovací únikové analýzy - obvykle oprava chyb EFD nebo CFD

# 3) Je velmi důležité, aby tým QA napodoboval testovací pracoviště jedné nebo více vertikál v závislosti na oboru podnikání organizace s počtem vertikál

# 4) Vyhrazené testovací zařízení by mělo mít

  • Topologie sítě podobná zamýšlené vertikální nebo více vertikální
  • Infrastruktura mající podobné přepínače, směrovače, servery typu back-end, brány firewall atd
  • Nejčastěji a populárně používané aplikační servery z dané vertikály
  • Nejčastěji a nejoblíbenější gadgety pro koncové uživatele z dané vertikály

# 5) Vhodné nástroje pro generování zátěže, stresu a provozu v reálném čase

# 6) Identifikujte prostředek ručního spuštění

# 7) Určete prostředek / strategii automatizace pro rychlejší a opakované provádění

# 8) Určete START a END of Longevity Testing pro dané vydání

Dva přístupy pro START a END of Longevity Testing:

I) Přístup 1:

  • Softwarový kód nebo hardware by měl být ve stabilním stavu
  • ZAČNĚTE na konci dokončení FUNKCE testu
  • UKONČIT před zmrazením kódu

II) Přístup 2:

  • Udělejte menší zásah povolením mírně nestabilního kódu
  • ZAČNĚTE na 70% dokončení testovacího cyklu FEATURE
  • UKONČIT před zmrazením kódu

# 9) Ověření chyby pro vyřešené vady

# 10) Přesuňte testování dlouhověkosti do regrese pro následné testování regrese

Provedení

  • Nastavte testovací lože tak, aby napodobovaly jedno nebo více zákaznických vertikál
  • Zajistěte, aby všechny back-endové Infra, Aplikace a Databáze včetně příchutí byly podobné jako u zákazníků
  • Zajistěte, aby zařízení koncového uživatele byla podobná zařízením, která používá zákazník, aby byla k dispozici a byla používána během provádění testovacího plánu
  • Zajistěte, aby byly k dispozici vhodné nástroje pro generování mírného stresu a zatížení systému nebo produktu
  • Proveďte celou testovací sadu z plánu testování dlouhověkosti bez měkkého nebo tvrdého restartu SUT nebo DUT, servery typu back-end a další zařízení související s Infra
  • Několik cyklů testů by mělo probíhat výše uvedeným způsobem po definovanou dobu nepřetržitého provozu ze slotu 72–720 hodin.
  • Zaznamenejte výsledky
  • Zaznamenejte všechny identifikované chyby
  • Ověřte všechny chyby

Jaké jsou výhody a nevýhody testování dlouhověkosti?

Profesionálové

  • Pomáhá identifikovat kritické chyby než ji zákazník najde
  • Pomáhá stabilizovat systém nebo produkt pro jeho provozuschopnou funkci, která je zásadní pro produktivitu a podnikání zákazníka
  • Pomáhá zvyšovat spokojenost zákazníků
  • Šetří organizaci spoustu nákladů $$$ - ušetřené peníze jsou vydělané peníze !!!
  • Protokol o testování dlouhověkosti lze také přeměnit na důkaz kvality certifikovaný pro různé vertikály

Nevýhody

  • Počáteční náklady na zahrnutí testování dlouhověkosti a souvisejících aktivit jako součást daného vydání a regresních aktivit
  • Ideální pro Model vodopádu
  • Agilní / Scrum modely potřebují doladit dobu a pokrytí

Závěr

Mnoho z „vad“, které vzniknou v důsledku problémů hlášených zákazníkem, je způsobeno především testovacím únikem. To zase vyžaduje mnoho otázek, jako je vývoj testovacího plánu, kontrola, pokrytí a provedení.

Externě nalezené vady (EFD) nebo vady nalezené zákazníkem (CFD) mají obchodní ($$$) dopad na zákazníka i na organizaci produktu.

sql dotazy příklady s odpověďmi pdf

Testování dlouhověkosti, které je jedinečné, by mělo pomoci kterékoli organizaci produktu zlepšit spokojenost zákazníků způsobem identifikace a řešení vad dříve, než je zákazník zachytí. Testování dlouhověkosti také pomáhá zlepšit stabilitu, což vede k robustnímu kvalitnímu systému nebo produktu.

O autorovi: Tento článek je napsán autorem STH Vinayakem. Má 12 let zkušeností s QA / testováním ve společnostech Fortune 500.

Pokud máte jakékoli dotazy nebo návrhy týkající se tohoto článku, dejte nám vědět.

Doporučené čtení

^