Meniu

Ce este testarea longevității? Cum să prinzi erorile înainte ca clientul să le găsească

what is longevity testing

Acest articol explică semnificația „ Testarea longevității ”Și modul în care ajută la evaluarea stabilității sistemului sau a produsului și la reducerea defectelor constatate de client, adică ' Prindeți erorile în interior înainte ca clientul să le găsească ”.

Până la sfârșitul acestui articol, managerii, clienții potențiali și testerii QA vor avea cunoștințe corecte despre:

  • Ce este testarea longevității?
  • De ce este necesar testarea longevității?
  • Planificarea și executarea testelor de longevitate
  • Care sunt avantajele și dezavantajele testării longevității?

Testarea longevității

Ce veți învăța:

care site oferă o recenzie despre software-ul de curățare a registrului

Ce este testarea longevității?

Testarea longevității este o activitate de testare:

  • Pentru a valida caracteristicile de stabilitate și întreținere a sistemului sau a produsului pe o perioadă mai lungă de timp împotriva stării adecvate de încărcare și solicitare cu trafic și aplicații în timp real
  • Pentru a reduce apariția defectelor la fața locului pe site-ul Clientului

Diagrama fluxului de gestionare a problemelor raportate de clienți (Fig. 1)

Ce este testarea longevității

Contextul testării longevității

# 1) De obicei, în primele câteva săptămâni de implementare a produsului sau după o actualizare la cea mai recentă versiune de software de pe site-ul clientului, toate lucrurile funcționează bine. Cu toate acestea, pe o perioadă de câteva săptămâni, un client începe să raporteze problemele.

#Două) Multe dintre probleme pot fi caracteristici simple, deoarece acestea sunt raportate de către client și nu sunt ușor de reprodus intern. Au nevoie de mult timp și de o analiză atentă de către echipa de experți din întreaga gamă. Sugestie: Timp = $$$ !!!

# 3) Una sau mai multe dintre următoarele se întâmplă atunci când clientul (clienții) găsesc defectul (Fig. 1)

  • Severitatea defectului va avea un impact direct asupra afacerii Clientului, adică $$$
  • Orice solicitare de service către Centrul de Asistență Tehnică costă $$$ Organizației de Inginerie a Produselor
  • Rareori problemele ridicate de client sunt rezolvate de echipa de asistență tehnică front-end
  • Astfel de cereri sau bilete sunt trimise către Echipa de asistență pentru escaladare
  • Escalarea biletelor clientului va costa mai mult $ $ $ pentru organizație
  • Dacă echipa Escalation nu poate rezolva problema, va trebui acum să implice echipa de ingineri (dezvoltare și QA)
  • Până acum, costul de $$$ pentru rezolvarea problemei ar fi crescut substanțial
  • Cu cât rezoluția defectelor este mai lungă, probabilitatea clientului (clienților) nemulțumiți care nu ar da comenzi repetate și cel mai grav scenariu este atunci când clientul decide să treacă la soluția unui concurent la momentul oportun. Cu toate acestea, în ambele cazuri este o pierdere de venituri pentru orice organizație de inginerie a produselor

4) Procentul mai mare de astfel de probleme raportate de un client (clienți) este legat de stabilitatea tipică a sistemului sau a produsului, în combinație cu topologia clientului, infrastructura, traficul și aplicațiile specifice.

De ce este necesar testarea longevității?

1) Orice „Defect” care apare din partea Clientului a raportat problema este de obicei un Test Escape.

Două) Orice astfel de defecte costă în linie de jos $$$ Clientului, precum și Organizației de Inginerie care oferă soluții și servicii clienților.

3) Într-un scenariu normal, defectul ar fi trebuit să fie observat intern în timpul diferitelor cicluri de testare, inclusiv testarea de regresie de către unul sau mai mulți testeri din echipa de testare, în funcție de complexitatea problemei.

4) Cel mai important, astfel de defecte apărute din problemele raportate de clienți indică, de asemenea, un scenariu de testare adecvat sau un caz de testare care a fost ratat la punctul de execuție a planului de testare.

5) Mulți dintre testeri trebuie să fi experimentat că o anumită caracteristică eșuează la site-ul clientului, dar trece în interior în diverse bancuri de testare, cum ar fi

  • Caracteristică
  • Regresie
  • Sarcină
  • Stres
  • Performanţă
  • Sistem
  • Soluţie
  • Alfa
  • Beta

6) Observații cheie care trebuie luate în considerare -

cum se creează o matrice de șiruri java
  • În timpul oricărui ciclu de lansare a software-ului, System Under Test (SUT) sau Device Under Test (DUT) în toate Testbeds sunt frecvent repornite ușor sau greu pentru lipsa unor lucruri precum încărcarea unui nou cod, verificarea erorilor etc.
  • Chiar și suitele de testare de regresie automată repornesc sau resetează SUT sau DUT după executarea unui anumit script de caz de testare sau a unei serii de scripturi de caz de testare
  • Deci SUT sau DUT nu funcționează suficient de mult fără o repornire ușoară sau dură
  • Întrucât situația este complet diferită la site-ul clientului. Clientul nu își poate permite să repornească sistemul în mod frecvent, rezultând astfel întreruperi ale productivității
  • Clienții urmează o practică dovedită în care anunță o fereastră adecvată de întreținere către publicul vizat și apoi efectuează actualizarea software-ului sau înlocuirea hardware etc.
  • Astfel de ferestre de întreținere pot avea o durată specifică de la trimestrial la anual, în funcție de liniile directoare și procedurile interne ale organizației clientului
  • În realitate, imaginea reală a stării sistemului sau a produsului la site-ul clientului este complet diferită de cea a testelor în timpul unui anumit ciclu de lansare a software-ului în orice organizație de inginerie a produselor.
  • Mulți clienți caută, de asemenea, un document de calitate autorizat, care a trecut testarea modelului vertical, în special financiar, medical și federal

Luând în considerare câteva goluri de testare, așa cum s-a menționat mai sus =>

  • Este evident că sistemul sau produsul ar trebui să fie supuse unei durate mai lungi de teste sau teste de longevitate, cu un scenariu de la cap la cap, care imită site-ul clientului sau verticale.
  • Durata mai lungă poate fi de 72-720 ore. (3-30 zile) sau o durată adecvată pe baza EFD sau CFD date și cazuri specifice clienților
  • Este o practică recomandată pentru managerii, clienții potențiali și testerii QA să efectueze testarea longevității ca activitate separată într-un anumit ciclu de lansare a software-ului.
  • Net-Net, testarea longevității este foarte relevantă pentru stabilitatea sistemului sau a produsului, deoarece are o relație directă cu linia de jos $$$ a organizației

Planificarea și executarea testelor de longevitate

Este important ca managerii, clienții potențiali și testerii QA să includă testarea longevității ca parte a lor Strategia generală de testare .

Planificare

Planificarea și executarea testelor de longevitate

  • Organizațiile inginerești efectuează analize interne de evadare a testelor ( CEAI ) exercitați din când în când pentru multe produse (hardware și software). Unii au chiar un mecanism integrat și automat pentru a sapa datele Test Escape bazate de obicei pe „Defecte găsite extern ( EFD ) Sau „Defecte găsite de clienți ( CFD ) 'Înregistrat de echipa de asistență pentru escalada
  • EFD-urile sau CFD-urile ar trebui să fie analizate cu atenție în contextul implementării în timp real a clientului din perspectiva end-to-end, nu doar a infrastructurii, ci și a dispozitivelor utilizatorului final, a aplicațiilor, a modelelor de trafic

Înțelegerea verticalelor clienților:

Clienții se încadrează de obicei într-una dintre verticalele de mai jos:

  • Sănătate
  • Cu amănuntul
  • Finanţa
  • Educaţie
  • Transport
  • de fabricație
  • Inginerie
  • Federal (guvern)

Activități

# 1) Elaborați un plan de testare separat și un caz de testare pentru testarea longevității. Acest lucru vă va ajuta, de asemenea, să urmăriți execuția testului, înregistrarea erorilor și verificarea

#Două) Identificați cazurile de test pe baza intrărilor de analiză de evadare a testului - de obicei, curățarea erorilor de EFD sau CFD

# 3) Este foarte important ca echipa QA să imite paturile de testare pentru una sau mai multe verticale, în funcție de linia de activitate a organizației, cu numărul de verticale

# 4) Ar trebui să aibă paturi de testare dedicate

  • Topologie de rețea similară cu cea a unei verticale intenționate sau a mai multor verticale
  • Infrastructură care are comutatoare, routere, servere back-end similare, firewall-uri etc.
  • Servere de aplicații utilizate cel mai frecvent și cel mai frecvent dintr-o anumită verticală
  • Cele mai frecvent utilizate gadgeturi pentru utilizatorii finali dintr-o anumită verticală

# 5) Instrumente adecvate pentru generarea de încărcare, stres și trafic în timp real

algoritmul dijkstra java folosind coada prioritară

# 6) Identificați resursa de execuție manuală

# 7) Identificați resursa / strategia de automatizare pentru o execuție mai rapidă și repetată

# 8) Identificați START și END de testare a longevității pentru o anumită versiune

Două abordări pentru START și END pentru testarea longevității:

I) Abordarea 1:

  • Codul software sau Hardware-ul ar trebui să fie într-o stare stabilă
  • ÎNCEPE la sfârșitul finalizării testului FEATURE
  • ÎNCHEI înainte de Înghețarea codului

II) Abordarea 2:

  • Faceți o lovitură minoră permițând un cod ușor instabil
  • ÎNCEPE la finalizarea cu 70% a ciclului de testare FUNCȚIONARE
  • ÎNCHEI înainte de Înghețarea codului

# 9) Verificarea erorilor pentru defecte rezolvate

# 10) Mutați testarea longevității în regresie pentru testarea de regresie ulterioară

Execuţie

  • Configurați panoul (testele) pentru a imita una sau mai multe verticale ale clienților
  • Asigurați-vă că toate aplicațiile de bază, aplicațiile și baza de date, inclusiv arome, sunt similare cu cele ale clientului
  • Asigurați-vă că dispozitivele utilizatorului final sunt similare cu cele utilizate de client sunt disponibile și utilizate în timpul executării planului de testare
  • Asigurați-vă că sunt disponibile instrumente adecvate pentru a genera stres și încărcare moderată a sistemului sau a produsului
  • Executați întreaga suită de teste din planul de testare a longevității fără repornirea ușoară sau dură a SUT sau DUT, servere back-end alte dispozitive legate de Infra
  • Mai multe teste ar trebui să fie efectuate în modul de mai sus pentru o durată definită non-stop din slotul 72-720 ore.
  • Înregistrați rezultatele
  • Înregistrați toate erorile identificate
  • Verificați toate erorile

Care sunt avantajele și dezavantajele testării longevității?

Pro

  • Ajută identificați erorile critice înainte ca clientul să o găsească
  • Ajută la stabilizarea sistemului sau a produsului pentru funcționalitatea sa de service care este esențială pentru productivitatea și afacerea clientului
  • Ajută la creșterea satisfacției clienților
  • Economisește o mulțime de costuri $ $ $ pentru organizație - banii economisiți sunt bani câștigați !!!
  • Raportul de testare a longevității poate fi, de asemenea, transformat într-o certificare de calitate, care să satisfacă diferite verticale

Contra

  • Costul inițial pentru includerea testării longevității și a activităților sale conexe ca parte a unei versiuni date și a activităților de regresie
  • Ideal pentru Model cascadă
  • Modelele Agile / Scrum necesită modificări ale duratei și acoperirii

Concluzie

Multe dintre „Defectele” care apar din problemele raportate de Client se datorează în primul rând Test Escape. Acest lucru, la rândul său, cere multe întrebări, cum ar fi dezvoltarea, revizuirea, acoperirea și executarea Planului de testare.

Defectele găsite extern (EFD) sau Defectele găsite de clienți (CFD) au un impact comercial ($$$) atât pentru client, cât și pentru organizația produsului.

Testarea longevității, fiind unică, ar trebui să ajute orice organizație de produse să îmbunătățească satisfacția clienților prin identificarea și rezolvarea defectelor înainte ca clientul să le prindă. Testarea longevității ajută, de asemenea, la îmbunătățirea stabilității, rezultând un sistem sau un produs de calitate robustă.

Despre autor: Acest articol este scris de autorul STH Vinayak. Are 12 ani de experiență QA / testare în companiile Fortune 500.

Spuneți-ne dacă aveți întrebări sau sugestii cu privire la acest articol.

Lectură recomandată

^