Ce sunt datele de testare? Testarea tehnicilor de pregătire a datelor cu exemplu

what is test data test data preparation techniques with example

Aflați ce sunt datele de testare și cum să pregătiți datele de testare pentru testare:

La epopeea actuală a creșterii revoluționare a informației și tehnologiei, testerii experimentează de obicei un consum extins de date de testare în ciclul de viață al testării software-ului.

Testerii nu colectează / întrețin doar date din sursele existente, ci și generează volume imense de date de testare pentru a asigura contribuția lor în plină expansiune la livrarea produsului pentru utilizare reală.

Prin urmare, noi, ca testeri, trebuie să explorăm, să învățăm și să aplicăm în permanență cele mai eficiente abordări pentru colectarea, generarea, întreținerea, automatizarea și gestionarea cuprinzătoare a datelor pentru orice tip de testare funcțională și nefuncțională.

În acest tutorial, vă voi oferi sfaturi despre cum să pregătiți datele de testare, astfel încât orice caz de testare important să nu fie ratat de date necorespunzătoare și de configurarea incompletă a mediului de testare.

Ce veți învăța:

• Ce sunt datele de testare și de ce sunt importante
  • Testați Provocările de aprovizionare a datelor
  • Strategii pentru pregătirea datelor de testare
  • Date de testare corupte
  • Date de testare pentru cazul testului de performanță
  • Cum să pregătiți date care să asigure acoperirea maximă a testelor?
  • Date pentru testarea cutiei negre
  • Exemplu de date de test pentru Open EMR AUT
  • Crearea datelor manuale pentru testarea aplicației Open EMR
• Proprietățile unui bun test de date
  • Testează proprietățile datelor
  • Testarea tehnicilor de pregătire a datelor
  • Abordări de generare a datelor de testare:
  • Concluzie
  • Lectură recomandată

Ce sunt datele de testare și de ce sunt importante

Referindu-se la un studiu realizat de IBM în 2016, căutarea, gestionarea, întreținerea și generarea datelor de testare cuprind 30% -60% din timpul testerilor. Este o dovadă incontestabilă că pregătirea datelor este o fază care necesită mult timp pentru testarea software-ului.

Figura 1: Testeri Timp mediu petrecut pe TDM

Cu toate acestea, în multe discipline, este un fapt că majoritatea oamenilor de știință de date petrec 50% -80% din timpul de dezvoltare al modelului lor în organizarea datelor. Și acum, luând în considerare legislația, precum și informațiile de identificare personală (PII) face angajamentul testerilor covârșitor de decent în procesul de testare.

Astăzi, credibilitatea și fiabilitatea datelor de testare sunt considerate un element necompromis pentru proprietarii de afaceri. Proprietarii de produse văd copiile fantomă ale datelor de testare ca fiind cea mai mare provocare, ceea ce reduce fiabilitatea oricărei aplicații în acest moment unic al cererii / cerințelor clienților pentru asigurarea calității.

Având în vedere semnificația datelor de testare, proprietarii de programe de marea majoritate nu acceptă aplicațiile testate cu date false sau mai puțin în măsuri de securitate.

În acest moment, de ce nu ne amintim despre ce sunt datele de testare? Când începem să scriem cazurile noastre de testare pentru a verifica și valida caracteristicile date și scenariile dezvoltate ale aplicației în cadrul testului, avem nevoie de informații care sunt utilizate ca intrare pentru a efectua testele pentru identificarea și localizarea defectelor.

cel mai bun editor de text pentru python mac

Și știm că aceste informații trebuie să fie precise și complete pentru identificarea erorilor. Este ceea ce numim date de testare. Pentru a fi exacte, pot fi nume, țări, etc ..., care nu sunt sensibile, unde datele referitoare la informațiile de contact, SSN, istoricul medical și informațiile despre cardul de credit sunt sensibile.

Datele pot fi sub orice formă, cum ar fi:

• Date de testare a sistemului
• Date de testare SQL
• Date de testare a performanței
• Date de testare XML

Dacă scrieți cazuri de testare, atunci aveți nevoie de date de intrare pentru orice tip de test. Testatorul poate furniza aceste date de intrare în momentul executării cazurilor de testare sau aplicația poate alege datele de intrare necesare din locațiile de date predefinite.

Datele pot fi orice tip de intrare în aplicație, orice fel de fișier care este încărcat de aplicație sau intrări citite din tabelele bazei de date.

Pregătirea corectă a datelor de intrare face parte din configurarea testului. În general, testerii îl numesc a pregătirea patului de testare . În testbed, toate cerințele software și hardware sunt setate folosind valorile de date predefinite.

Dacă nu aveți abordarea sistematică pentru construirea datelor în timp ce scrierea și executarea cazurilor de testare atunci există șanse să lipsească unele cazuri importante de testare. Testerii își pot crea propriile date în funcție de nevoile de testare.

Nu vă bazați pe datele create de alți testeri sau pe datele standard de producție. Creați întotdeauna un set nou de date în funcție de cerințele dvs.

Uneori nu este posibil să creați un set complet nou de date pentru fiecare construcție. În astfel de cazuri, puteți utiliza date de producție standard. Dar nu uitați să adăugați / inserați propriile seturi de date în această bază de date existentă. Unul dintre cele mai bune moduri de a crea date este să utilizați eșantionul de date existent sau testbed și să adăugați noile date de caz de test de fiecare dată când obțineți același modul pentru testare. În acest fel, puteți crea un set de date cuprinzător pe parcursul perioadei.

Testați Provocările de aprovizionare a datelor

Unul dintre domeniile generării de date de testare pe care testatorii îl consideră este cerința de aprovizionare a datelor pentru subset. De exemplu, aveți peste un milion de clienți și aveți nevoie de o mie dintre ei pentru testare. Și aceste eșantioane de date ar trebui să fie consistente și să reprezinte statistic distribuția adecvată a grupului vizat. Cu alte cuvinte, ar trebui să găsim persoana potrivită pentru a testa, care este una dintre cele mai utile metode de testare a cazurilor de utilizare.

Și aceste eșantioane de date ar trebui să fie consistente și să reprezinte statistic distribuția adecvată a grupului vizat. Cu alte cuvinte, ar trebui să găsim persoana potrivită pentru a testa, care este una dintre cele mai utile metode de testare a cazurilor de utilizare.

În plus, există unele constrângeri de mediu în proces. Una dintre ele este cartografierea politicilor PII. Deoarece confidențialitatea este un obstacol semnificativ, testerii trebuie să clasifice datele PII.

Instrumentele de gestionare a datelor de testare sunt concepute pentru a aborda problema menționată. Aceste instrumente sugerează politici bazate pe standardele / catalogul pe care îl au. Cu toate acestea, nu este un exercițiu foarte sigur. Încă oferă posibilitatea de a audita ceea ce face cineva.

Pentru a ține pasul cu abordarea provocărilor actuale și chiar viitoare, ar trebui să punem întotdeauna întrebări precum Când / de unde ar trebui să începem desfășurarea TDM? Ce ar trebui automatizat? Cât de multă investiție ar trebui să aloce companiile pentru testarea în domenii ale dezvoltării continue a resurselor umane și utilizarea instrumentelor TDM mai noi? Ar trebui să începem testarea cu teste funcționale sau nefuncționale? Și întrebări mult mai probabile ca ele.

Unele dintre cele mai frecvente provocări ale aprovizionării cu date de testare sunt menționate mai jos:

• Este posibil ca echipele să nu aibă cunoștințe și abilități adecvate pentru instrumentele de generare a datelor de testare
• Acoperirea datelor de testare este adesea incompletă
• Mai puțină claritate în cerințele de date care acoperă specificațiile de volum în timpul fazei de colectare
• Echipele de testare nu au acces la sursele de date
• Întârziere în acordarea de date producției acces la testeri de către dezvoltatori
• Este posibil ca datele privind mediul de producție să nu fie pe deplin utilizabile pentru testare pe baza scenariilor de afaceri dezvoltate
• Este posibil să fie nevoie de volume mari de date într-o perioadă scurtă de timp
• Dependențe de date / combinații pentru a testa unele dintre scenariile de afaceri
• Testerii petrec mai mult timp decât este necesar pentru a comunica cu arhitecții, administratorii de baze de date și BA-uri pentru colectarea datelor
• În principal, datele sunt create sau pregătite în timpul executării testului
• Mai multe aplicații și versiuni de date
• Cicluri de eliberare continuă în mai multe aplicații
• Legislație pentru a avea grijă de informațiile de identificare personală (PII)

Pe partea de casetă albă a testării datelor, dezvoltatorii pregătesc datele de producție. Acolo este nevoia QA de a lucra cu touch-base-ul cu dezvoltatorii pentru a continua acoperirea testării AUT. Una dintre cele mai mari provocări este de a încorpora toate scenariile posibile (100% caz de testare) cu fiecare caz negativ posibil.

În această secțiune, am vorbit despre provocările legate de datele de testare. Puteți adăuga mai multe provocări pe măsură ce le-ați rezolvat în consecință. Ulterior, să explorăm diferite abordări pentru gestionarea proiectării și gestionării datelor de testare.

Strategii pentru pregătirea datelor de testare

Știm, prin practica de zi cu zi, că jucătorii din industria testării se confruntă continuu cu diferite modalități și mijloace de a spori eforturile de testare și, cel mai important, eficiența costurilor. Pe parcursul evoluției scurte a informației și tehnologiei, am văzut când instrumentele sunt încorporate în mediile de producție / testare, nivelul de producție a crescut substanțial.

Când vorbim despre completitudinea și acoperirea completă a testării, depinde în principal de calitatea datelor. Deoarece testarea este coloana vertebrală pentru obținerea calității software-ului, datele de testare sunt elementul de bază în procesul de testare.

Figura 2: Strategii pentru gestionarea datelor de testare (TDM)

Crearea fișierelor plate pe baza regulilor de mapare. Este întotdeauna practic să creați un subset de date de care aveți nevoie din mediul de producție în care dezvoltatorii au proiectat și codat aplicația. Într-adevăr, această abordare reduce eforturile testatorilor de pregătire a datelor și maximizează utilizarea resurselor existente pentru a evita cheltuieli suplimentare.

De obicei, trebuie să creăm datele sau cel puțin să le identificăm pe baza tipului de cerințe pe care fiecare proiect le are la început.

Putem aplica următoarele strategii pentru gestionarea procesului TDM:

1. Date din mediul de producție
2. Preluarea interogărilor SQL care extrag date din bazele de date existente ale Clientului
3. Instrumente automate de generare a datelor

Testerii trebuie să susțină testarea cu date complete, luând în considerare elementele prezentate în figura-3 aici. Restul echipelor de dezvoltare agile generează datele necesare pentru executarea cazurilor de testare. Când vorbim despre cazuri de testare, ne referim la cazuri pentru diferite tipuri de testare, cum ar fi caseta albă, caseta neagră, performanța și securitatea.

În acest moment, știm că datele pentru testarea performanței ar trebui să poată determina cât de rapid răspunde sistemul sub o anumită sarcină de lucru pentru a fi foarte aproape de un volum mare real sau viu de date cu o acoperire semnificativă.

Pentru testarea casetei albe, dezvoltatorii își pregătesc datele necesare pentru a acoperi cât mai multe ramuri posibil, toate căile din codul sursă al programului și interfața de program de aplicație (API) negativă.

Figura 3: Activități de generare a datelor de testare

În cele din urmă, putem spune că toată lumea care lucrează în ciclul de viață al dezvoltării software-ului ( SDLC ) ca BA, dezvoltatorii și proprietarii de produse ar trebui să fie bine angajați în procesul de pregătire a datelor de testare. Poate fi un efort comun. Și acum să vă ducem la problema datelor de test corupte.

Date de testare corupte

Înainte de executarea oricărui caz de testare a datelor noastre existente, ar trebui să ne asigurăm că datele nu sunt corupte / depășite și că aplicația testată poate citi sursa de date. De obicei, atunci când mai mult decât un tester lucrează la diferite module ale unui AUT în mediul de testare în același timp, șansele ca datele să fie corupte sunt atât de mari.

În același mediu, testerii modifică datele existente conform nevoilor / cerințelor lor din cazurile de testare. În cea mai mare parte, atunci când testerii au terminat cu datele, ei lasă datele așa cum sunt. De îndată ce următorul tester preia datele modificate și el / ea efectuează o altă execuție a testului, există posibilitatea ca respectivul eșec al testului să nu fie eroarea de cod sau defectul.

În majoritatea cazurilor, acesta este modul în care datele devin corupte și / sau depășite, ceea ce duce la eșec. Pentru a evita și a minimiza șansele de discrepanță a datelor, putem aplica soluțiile după cum urmează. Și, desigur, puteți adăuga mai multe soluții la sfârșitul acestui tutorial în secțiunea de comentarii.

1. Aveți backupul datelor dvs.
2. Reveniți la datele modificate la starea inițială
3. Împărțirea datelor între testeri
4. Păstrați actualizat administratorul depozitului de date pentru orice modificare / modificare a datelor

Cum să vă păstrați datele intacte în orice mediu de testare?

De cele mai multe ori, mulți testeri sunt responsabili pentru testarea aceleiași versiuni. În acest caz, mai mulți testeri vor avea acces la date comune și vor încerca să manipuleze setul de date comune în funcție de nevoile lor.

Dacă ați pregătit date pentru unele module specifice, atunci cel mai bun mod de a păstra intact setul de date este să păstrați copii de rezervă ale acestora.

Date de testare pentru cazul testului de performanță

Testele de performanță necesită un set de date foarte mare. Uneori, crearea manuală a datelor nu va detecta unele erori subtile care pot fi surprinse doar de datele reale create de aplicația testată. Dacă doriți date în timp real, care este imposibil de creat manual, atunci solicitați-i conducătorului / managerului să le facă disponibile din mediul live.

Aceste date vor fi utile pentru a asigura buna funcționare a aplicației pentru toate intrările valide.

Care sunt datele de testare ideale?

Se poate spune că datele sunt ideale dacă pentru dimensiunea minimă a datelor setate toate erorile aplicației pentru a fi identificate. Încercați să pregătiți date care vor încorpora toate funcționalitățile aplicației, dar care nu depășesc constrângerea de cost și timp pentru pregătirea datelor și efectuarea testelor.

Cum să pregătiți date care să asigure acoperirea maximă a testelor?

Proiectați-vă datele luând în considerare următoarele categorii:

1) Fără date: Rulați cazurile de test pe date goale sau implicite. Vedeți dacă sunt generate mesaje de eroare adecvate.

2) Set de date valide: Creați-l pentru a verifica dacă aplicația funcționează conform cerințelor și dacă datele de intrare valide sunt salvate corect în baza de date sau fișiere.

3) Set de date nevalide: Pregătiți un set de date nevalide pentru a verifica comportamentul aplicației pentru valori negative, intrări de șir alfanumeric.

4) Format de date ilegal: Creați un set de date în format de date ilegal. Sistemul nu trebuie să accepte date într-un format nevalid sau ilegal. De asemenea, verificați dacă sunt generate mesajele de eroare corespunzătoare.

5) Set de date pentru condiții limită: Set de date care conține date în afara intervalului. Identificați cazurile la limita aplicației și pregătiți un set de date care să acopere condițiile limită inferioară și superioară.

6) Setul de date pentru testarea performanței, sarcinii și stresului: Acest set de date ar trebui să aibă un volum mare.

Astfel, crearea seturilor de date separate pentru fiecare condiție de testare va asigura o acoperire completă a testului.

Date pentru testarea cutiei negre

Testerii de asigurare a calității efectuează teste de integrare, testare a sistemului și teste de acceptare, care este cunoscut sub numele de testare cutie neagră. În această metodă de testare, testerii nu au nicio activitate în structura internă, proiectarea și codul aplicației supuse testului.

Scopul principal al testerilor este identificarea și localizarea erorilor. Procedând astfel, aplicăm testări funcționale sau nefuncționale folosind diferite tehnici de testare a cutiei negre.

Figura 4: Metode de proiectare a datelor din cutia neagră

În acest moment, testerii au nevoie de datele de testare ca date de intrare pentru executarea și implementarea tehnicilor de testare a cutiei negre. Și testerii ar trebui să pregătească datele care vor examina toate funcționalitățile aplicației fără a depăși costul dat și timpul.

Putem proiecta datele pentru cazurile noastre de testare luând în considerare categoriile de seturi de date, cum ar fi lipsa datelor, date valide, date nevalide, format de date ilegal, date privind condițiile de graniță, partiție de echivalență, tabel de date de decizie, date de tranziție de stare și date de caz de utilizare Înainte de a intra în categoriile de seturi de date, testerii inițiază colectarea de date și analiza resurselor existente ale aplicației sub tester (AUT).

algoritmul dijkstra java folosind coada prioritară

Conform punctelor anterioare menționate despre menținerea actualizată a depozitului dvs. de date, ar trebui să documentați cerințele de date la nivelul cazului de testare și să le marcați ca utilizabile sau care nu pot fi reutilizate atunci când vă creați cazurile de testare. Vă ajută ca datele necesare testării să fie bine clarificate și documentate de la bun început, pe care să le puteți consulta ulterior pentru utilizarea ulterioară.

Exemplu de date de test pentru Open EMR AUT

Pentru tutorialul nostru actual, avem Open EMR ca aplicație sub test (AUT).

=> Vă rugăm să găsiți link pentru aplicația Open EMR aici pentru referință / practică.

Tabelul de mai jos ilustrează destul de mult un eșantion al colectării cerințelor de date care poate face parte din documentația cazului de testare și care este actualizat atunci când scrieți cazurile de testare pentru scenariile dvs. de testare.

( NOTĂ : Clic pe orice imagine pentru o vizualizare mărită)

Crearea datelor manuale pentru testarea aplicației Open EMR

Să facem un pas înainte către crearea de date manuale pentru testarea aplicației Open EMR pentru categoriile de seturi de date date.

1) Fără date: Testerul validează adresa URL a aplicației Open EMR și funcțiile „Căutare sau adăugare pacient” fără a furniza date.

Două) Date valide: Testerul validează adresa URL a aplicației Open EMR și funcția „Căutare sau adăugare pacient”, oferind date valide.

3) Date nevalide: Testerul validează adresa URL a aplicației Open EMR și funcția „Căutare sau adăugare pacient”, oferind date nevalide.

4) Format de date ilegal: Testerul validează adresa URL a aplicației Open EMR și funcția „Căutare sau adăugare pacient”, oferind date nevalide.

Date de testare pentru 1-4 categorii de seturi de date:

5) Set de date privind condițiile limită: Este pentru a determina valorile de intrare pentru limite care sunt fie în interiorul, fie în afara valorilor date ca date.

6) Set de date partiție echivalență: Este tehnica de testare care împarte datele de intrare în valorile de intrare valide și invalide.

Date de testare pentru 5^ași 6^acategorii de seturi de date, care este pentru numele de utilizator și parola Open EMR:

7) Set de date tabel decizional: Este tehnica pentru calificarea datelor dvs. cu o combinație de intrări pentru a produce rezultate variate. Această metodă de testare a cutiei negre vă ajută să vă reduceți eforturile de testare în verificarea fiecărei combinații de date de testare. În plus, această tehnică vă poate asigura acoperirea completă a testului.

Vă rugăm să consultați mai jos setul de date din tabelul de decizii pentru numele de utilizator și parola aplicației Open EMR.

Calculul combinațiilor efectuate în tabelul de mai sus este descris pentru informații detaliate, după cum urmează. Este posibil să aveți nevoie de el când faceți mai mult de patru combinații.

• Număr de combinație = Numărul de condiții 1 valori * Numărul de condiții 2 valori
• Număr de combinații = 2 ^ Numărul de condiții adevărate / false
• Exemplu: Număr de combinații - 2 ^ 2 = 4

8) Set de date de testare a tranziției de stat: Este tehnica de testare care vă ajută să validați tranziția de stare a aplicației sub test (AUT) oferind sistemului condițiile de intrare.

De exemplu, ne conectăm la aplicația Open EMR furnizând numele de utilizator și parola corecte la prima încercare. Sistemul ne oferă acces, dar dacă introducem datele de conectare incorecte, sistemul refuză accesul. Testarea tranziției de stat validează câte încercări de conectare puteți face înainte de închiderea Open EMR.

Tabelul de mai jos indică modul în care răspund fie încercările corecte, fie incorecte de autentificare

9) Data testului cazului de utilizare: Metoda de testare este cea care identifică cazurile noastre de testare care surprind testarea de la capăt la cap a unei anumite caracteristici.

Exemplu, Deschideți autentificarea EMR:

Citește și => Tehnici de gestionare a datelor de date

Proprietățile unui bun test de date

În calitate de tester, trebuie să testați modulul „Rezultate examinare” de pe site-ul unei universități. Luați în considerare faptul că întreaga aplicație a fost integrată și că se află în starea „Pregătit pentru testare”. „Modulul de examinare” este legat de modulele „Înregistrare”, „Cursuri” și „Finanțe”.

Să presupunem că aveți informații adecvate despre aplicație și că ați creat o listă cuprinzătoare de scenarii de testare. Acum trebuie să proiectați, să documentați și să executați aceste cazuri de testare. În secțiunea „Acțiuni / pași” sau „Intrări de testare” din cazurile de testare, va trebui să menționați datele acceptabile ca intrări pentru testare.

Datele menționate în cazurile de testare trebuie selectate corect. Acuratețea coloanei „Rezultate efective” din documentul cazului de testare depinde în principal de datele de testare. Deci, pasul pentru pregătirea datelor de test de intrare este semnificativ important. Astfel, iată rezumatul meu despre „DB Testing - Test Data Preparation Strategies”.

Testează proprietățile datelor

Datele testului trebuie selectate cu precizie și trebuie să posede următoarele patru calități:

1) Realist:

Prin realism, înseamnă că datele ar trebui să fie corecte în contextul scenariilor din viața reală. De exemplu, pentru a testa câmpul „Vârstă”, toate valorile ar trebui să fie pozitive și 18 sau mai mari. Este destul de evident că candidații pentru admitere la universitate au de obicei 18 ani (acest lucru ar putea fi definit diferit în ceea ce privește cerințele de afaceri).

Dacă testarea se face folosind datele de testare realiste, atunci aceasta va face aplicația mai robustă, deoarece majoritatea posibilelor erori pot fi capturate folosind date realiste. Un alt avantaj al datelor realiste este reutilizarea sa, care ne economisește timp și efort pentru crearea de date noi din nou și din nou.

Când vorbim despre date realiste, aș dori să vă introduc conceptul setului de date de aur. Un set de date auriu este cel care acoperă aproape toate scenariile posibile care apar în proiectul real. Prin utilizarea GDS, putem oferi o acoperire maximă a testelor. Folosesc GDS pentru a face teste de regresie în organizația mea și acest lucru mă ajută să testez toate scenariile posibile care pot apărea dacă codul intră în caseta de producție.

Există o mulțime de instrumente de generare a datelor de testare disponibile pe piață, care analizează caracteristicile coloanelor și definițiile utilizatorilor din baza de date și pe baza acestora, acestea generează date de test realiste pentru dvs. Puține dintre exemplele bune de instrumente care generează date pentru testarea bazelor de date sunt Generator de date DTM , Generator de date SQL și Mockaroo .

2. Practic valabil:

Acest lucru este similar cu cel realist, dar nu același lucru. Această proprietate este mai mult legată de logica de afaceri a AUT, de ex. valoarea 60 este realistă în domeniul vârstei, dar practic invalidă pentru un candidat la absolvire sau chiar programe de masterat. În acest caz, un interval valid ar fi de 18-25 de ani (acest lucru ar putea fi definit în cerințe).

3. Versatil pentru a acoperi scenarii:

cum se creează un proiect Java în eclipsă

Pot exista mai multe condiții ulterioare într-un singur scenariu, deci alegeți datele cu înțelepciune pentru a acoperi aspectele maxime ale unui singur scenariu cu setul minim de date, de ex. în timp ce creați date de testare pentru modulul de rezultate, nu luați în considerare doar cazul studenților obișnuiți care își finalizează fără probleme programul. Acordați atenție studenților care repetă același curs și aparțin semestrelor diferite sau chiar programe diferite. Setul de date poate arăta astfel:

S-ar putea să existe și alte câteva condiții interesante și complicate. De exemplu. limita de ani pentru a finaliza un program de diplomă, promovarea unui curs premis pentru înregistrarea unui curs, maxim nr. de cursuri pe care un student se poate înscrie într-un singur semestru etc. etc. Asigurați-vă că acoperiți toate aceste scenarii cu înțelepciune cu un set finit de date.

4. Date excepționale (dacă este cazul / necesar):

Pot exista anumite scenarii excepționale care apar mai rar, dar necesită o atenție ridicată atunci când au avut loc, de ex. probleme legate de studenții cu dizabilități.

O altă explicație bună și un exemplu de set de date excepțional este văzut în imaginea de mai jos:

La pachet:

Datele de testare sunt cunoscute ca date de testare bune dacă sunt realiste, valide și versatile. Este un avantaj suplimentar dacă datele oferă acoperire și pentru scenarii excepționale.

Testarea tehnicilor de pregătire a datelor

Am discutat pe scurt proprietățile importante ale datelor de testare și am elaborat, de asemenea, modul în care selecția datelor de testare este importantă în timp ce efectuăm testarea bazei de date. Acum să discutăm despre ' tehnici de pregătire a datelor de testare ' .

Există doar două moduri de a pregăti datele de testare:

Metoda nr. 1) Introduceți date noi

Obțineți un DB curat și introduceți toate datele așa cum se specifică în cazurile de testare. Odată ce toate datele necesare și dorite au fost introduse, începeți să executați cazurile de testare și completați coloanele „Trecere / nereușită” comparând „Ieșire reală” cu „Ieșire așteptată”. Sună simplu, nu? Dar așteaptă, nu este atât de simplu.

Puține preocupări esențiale și critice sunt următoarele:

• Este posibil ca o instanță goală a bazei de date să nu fie disponibilă
• Datele de testare inserate pot fi insuficiente pentru testarea unor cazuri, cum ar fi testarea performanței și a sarcinii.
• Introducerea datelor de test necesare în DB gol nu este o sarcină ușoară datorită dependențelor tabelului bazei de date. Datorită acestei restricții inevitabile, inserarea datelor poate deveni o sarcină dificilă pentru tester.
• Introducerea de date de testare limitate (în funcție de nevoile cazului de testare) poate ascunde unele probleme care ar putea fi găsite numai cu setul mare de date.
• Pentru inserarea datelor, pot fi necesare interogări complexe și / sau proceduri, iar pentru aceasta ar fi necesară asistență suficientă sau ajutor din partea dezvoltatorilor de baze de date.

Cele cinci aspecte menționate mai sus sunt cele mai critice și cele mai evidente dezavantaje ale acestei tehnici pentru pregătirea datelor de testare. Dar, există și câteva avantaje:

• Executarea TC devine mai eficientă, întrucât DB are doar datele necesare.
• Izolarea erorilor nu necesită timp, deoarece doar datele specificate în cazurile de testare sunt prezente în DB.
• Mai puțin timp necesar pentru testare și compararea rezultatelor.
• Proces de testare fără dezordine

Metoda # 2) Alegeți un eșantion de subset de date din datele DB reale

Aceasta este o tehnică fezabilă și mai practică pentru pregătirea datelor de testare. Cu toate acestea, necesită abilități tehnice solide și necesită cunoștințe detaliate despre DB Schema și SQL. În această metodă, trebuie să copiați și să utilizați datele de producție prin înlocuirea unor valori de câmp cu valori fictive. Acesta este cel mai bun subset de date pentru testare, deoarece reprezintă datele de producție. Dar este posibil ca acest lucru să nu fie fezabil tot timpul din cauza problemelor de securitate și confidențialitate a datelor.

La pachet:

În secțiunea de mai sus, am discutat mai sus tehnicile de pregătire a datelor de testare. Pe scurt, există două tehnici - fie creați date noi, fie selectați un subset din datele deja existente. Ambele trebuie făcute astfel încât datele selectate să ofere acoperire pentru diferite scenarii de testare, în principal teste valide și nevalide, test de performanță și test nul.

În ultima secțiune, permiteți-ne să facem un tur rapid de abordări de generare a datelor, de asemenea. Aceste abordări sunt utile atunci când trebuie să generăm date noi.

Abordări de generare a datelor de testare:

• Generarea manuală a datelor de testare: În această abordare, datele de testare sunt introduse manual de testeri conform cerințelor cazului de testare. Este un timp care durează procesul și, de asemenea, predispus la erori.
• Generare automată de date de testare: Acest lucru se face cu ajutorul instrumentelor de generare a datelor. Principalul avantaj al acestei abordări este viteza și acuratețea sa. Cu toate acestea, are un cost mai mare decât generarea manuală a datelor de testare.
• Injecție de date back-end : Acest lucru se face prin interogări SQL. Această abordare poate actualiza și datele existente în baza de date. Este rapid și eficient, dar trebuie implementat foarte atent, astfel încât baza de date existentă să nu fie deteriorată.
• Utilizarea instrumentelor terță parte : Există instrumente disponibile pe piață care înțeleg mai întâi scenariile dvs. de testare și apoi generează sau injectează date în consecință pentru a oferi o acoperire largă a testelor. Aceste instrumente sunt exacte, deoarece sunt personalizate conform nevoilor afacerii. Dar sunt destul de costisitoare.

La pachet:

Există 4 abordări pentru testarea generării datelor:

1. Manual,
2. automatizare,
3. injectare de date back-end,
4. și instrumente terță parte.

Fiecare abordare are propriile sale argumente pro și contra. Ar trebui să selectați abordarea care vă satisface afacerea și nevoile de testare.

Concluzie

Crearea datelor complete de testare a software-ului în conformitate cu standardele din industrie, legislația și documentele de bază ale proiectului întreprins se numără printre responsabilitățile de bază ale testerilor. Cu cât gestionăm mai eficient datele de testare, cu atât putem implementa produse rezonabile fără erori pentru utilizatorii din lumea reală.

Gestionarea datelor de testare (TDM) este procesul care se bazează pe analiza provocărilor și introducerea plus aplicarea celor mai bune instrumente și metode pentru a aborda bine problemele identificate fără a compromite fiabilitatea și acoperirea completă a rezultatului final (produs).

Întotdeauna trebuie să venim cu întrebări pentru a căuta metode inovatoare și mai rentabile pentru analiza și selectarea metodelor de testare, inclusiv utilizarea instrumentelor pentru generarea datelor. Este dovedit pe scară largă că datele bine concepute ne permit să identificăm defectele aplicației supuse testului în fiecare fază a unui SDLC multifazic.

Trebuie să fim creativi și să participăm cu toți membrii din și în afara echipei noastre agile. Vă rugăm să ne împărtășiți feedback-ul, experiența, întrebările și comentariile, astfel încât să putem continua discuțiile noastre tehnice în continuare, pentru a ne maximiza impactul pozitiv asupra AUT prin gestionarea datelor.

Pregătirea corectă a datelor de testare este o parte esențială a „configurării mediului de testare a proiectului”. Nu putem rata pur și simplu cazul de testare spunând că datele complete nu erau disponibile pentru testare. Testatorul ar trebui să își creeze propriile date de test în plus față de datele de producție standard existente. Setul dvs. de date ar trebui să fie ideal în termeni de cost și timp.

Fii creativ, folosește-ți propriile abilități și judecăți pentru a crea seturi de date diferite în loc să te bazezi pe date de producție standard.

Part II – A doua parte a acestui tutorial este pe ' Testați generarea datelor cu instrumentul online GEDIS Studio ”.

V-ați confruntat cu problema datelor de testare incomplete pentru testare? Cum ai reușit? Vă rugăm să împărtășiți sfaturile, experiența, comentariile și întrebările dvs. pentru a îmbogăți în continuare acest subiect de discuție.

Lectură recomandată

• Tutorial de testare a depozitului de date ETL (ghid complet)
• Ce este testarea mutației: Tutorial cu exemple
• Cum se efectuează testarea bazată pe date folosind instrumentul TestComplete
• Testare bazată pe date sau parametrizată cu Spock Framework
• Cei 4 pași pentru testarea Business Intelligence (BI): Cum să testați datele de afaceri
• Tutorial de testare a volumului: exemple și instrumente de testare a volumului
• Un mod excelent de testare a datelor folosind tehnologiile XML (Cartea albă)
• Top 10 instrumente de testare și validare a datelor structurate pentru SEO