Tutorial de testare a bazei de date (date).

GUI-ului i se acordă de obicei cel mai mare accent de către membrii echipei de testare și dezvoltare, deoarece interfața grafică cu utilizatorul se întâmplă să fie cea mai vizibilă parte a aplicației. Cu toate acestea, ceea ce este, de asemenea, important este să validăm informațiile care sunt inima aplicației, aka BAZĂ DE DATE.

Să luăm în considerare o aplicație bancară în care un utilizator efectuează tranzacții. Acum, din punctul de vedere al Testării bazei de date sau al Testării bazei de date, lucrurile sunt importante:

1. Aplicația stochează informațiile despre tranzacție în baza de date a aplicației și le afișează corect utilizatorului.
2. Nicio informație nu se pierde în acest proces.
3. Aplicația nu salvează informații despre operațiunile parțial efectuate sau anulate.
4. Nicio persoană neautorizată nu are voie să acceseze informațiile utilizatorului.

Pentru a asigura toate aceste obiective de mai sus, trebuie să folosim validarea sau testarea datelor.

Diferențele dintre testarea interfeței cu utilizatorul și testarea datelor

Testarea interfeței cu utilizatorul	Baza de date sau testarea datelor
Acest tip de testare este cunoscut și sub denumirea de testare a interfeței grafice cu utilizatorul sau testare front-end.	Acest tip de testare este cunoscut și sub denumirea de testare backend sau testare a datelor.
Acest tip de testare se ocupă în principal cu toate elementele testabile care sunt deschise utilizatorului pentru vizionare și interacțiune, cum ar fi Formulare, Prezentare, Grafice, Meniuri și Rapoarte etc. (create prin VB, VB.net, VC++, Delphi – Instrumente front-end)	Acest tip de testare se ocupă în principal cu toate elementele testabile care sunt în general ascunse utilizatorului pentru vizionare. Acestea includ procese interne și stocare, cum ar fi Assembly, DBMS ca Oracle, SQL Server, MYSQL etc.
Acest tip de testare include validarea casete text selectați meniuri derulante calendare și butoane Navigare în pagină afișarea imaginilor Aspectul general al aplicației	Acest tip de testare presupune validarea: schema tabele bazei de date coloane chei și indexuri declanșează procedurile stocate validări de server de baze de date validarea dublării datelor
Testerul trebuie să cunoască temeinic cerințele de afaceri, precum și utilizarea instrumentelor de dezvoltare și utilizarea cadrelor și instrumentelor de automatizare.	Pentru a putea efectua testarea backend, testatorul trebuie să aibă o experiență solidă în serverul de baze de date și conceptele Structured Query Language.

Tipuri de testare a bazelor de date

Cele 3 tipuri de testare a bazelor de date sunt

1. Testarea structurală
2. Functional Testing
3. Testare nefuncțională

În acest tutorial de testare a bazei de date, vom analiza fiecare tip și subtipurile sale unul câte unul.

Ce este Schema Testing?

Testarea Schemei testarea bazei de date validează diverse formate de schemă asociate cu baza de date și verifică dacă formatele de mapare ale tabelelor/vizualizărilor/coloanelor sunt compatibile cu formatele de mapare ale interfeței cu utilizatorul. Scopul principal al testării schemei este de a se asigura că maparea schemei dintre front-end și back-end este similară. Astfel, este denumită și testarea cartografierii.

Să discutăm cele mai importante puncte de control pentru testarea schemei.

1. Validarea diferitelor formate de schemă asociate bazelor de date. De multe ori este posibil ca formatul de mapare al tabelului să nu fie compatibil cu formatul de mapare prezent la nivelul interfeței cu utilizatorul a aplicației.
2. Este nevoie de verificare în cazul tabelelor/vizualizărilor/coloanelor nemapate.
3. De asemenea, este necesar să se verifice dacă bazele de date eterogene dintr-un mediu sunt în concordanță cu maparea generală a aplicației.

Să ne uităm și la unele dintre instrumentele interesante de testare a bazelor de date pentru validarea schemelor bazelor de date.

• DBUnit care este integrat cu Ant este foarte potrivit pentru testarea cartografierii.
• SQL Server permite testerilor să poată verifica și interoga schema bazei de date prin scrierea de interogări simple și nu prin cod.

De exemplu, dacă dezvoltatorii doresc să modifice o structură de tabel sau să o ștergă, testatorul ar dori să se asigure că toate procedurile stocate și vizualizările care folosesc acel tabel sunt compatibile cu modificarea respectivă. Un alt exemplu ar putea fi acela că, dacă testerii doresc să verifice modificările schemei între 2 baze de date, pot face asta folosind interogări simple.

Tabelul bazei de date, Testarea coloanelor

Să ne uităm la diferite verificări pentru testarea bazei de date și a coloanelor.

1. Dacă maparea câmpurilor și coloanelor bazei de date din backend este compatibilă cu acele mapări din front-end?
2. Validarea lungimii și convenției de denumire a câmpurilor și coloanelor bazei de date, conform cerințelor.
3. Validarea prezenței oricăror tabele/coloane de baze de date neutilizate/nemapate.
4. Validarea compatibilității

• datatype
• lungimi de câmp

a coloanelor bazei de date back-end cu cea a celor prezente la front-end-ul aplicației.

5. Dacă câmpurile bazei de date permit utilizatorului să furnizeze intrările dorite de utilizator, conform cerințelor documentelor cu specificațiile cerințelor de afaceri.

Testarea cheilor și indexurilor

Verificări importante pentru chei și indexuri –

1. Verificați dacă este necesar

• Cheia principala
• Cheie externă

au fost create constrângeri pe tabelele necesare.

2. Verificați dacă referințele pentru cheile străine sunt valide.
3. Verificați dacă tipul de date al cheii primare și cheile străine corespunzătoare sunt aceleași în cele două tabele.
4. Verificați dacă au fost respectate convențiile de denumire necesare pentru toate cheile și indecșii.
5. Verificați dimensiunea și lungimea câmpurilor și indecșilor obligatorii.
6. Fie că este necesar

• Clusterindici ed
• Nu Clusterindici ed

au fost create pe tabelele necesare, conform cerințelor de afaceri.

Testarea procedurilor stocate

Testele importante pentru verificarea procedurilor stocate sunt:

1. Dacă echipa de dezvoltare a adoptat convențiile standard de codificare necesare, A) și B) gestionarea excepțiilor și erorilor. Pentru toate procedurile stocate pentru toate modulele pentru aplicația testată.
2. Dacă echipa de dezvoltare a acoperit toate condițiile/buclele aplicând datele de intrare necesare aplicației testate?
3. Dacă echipa de dezvoltare a aplicat corect operația TRIM ori de câte ori au fost preluate date din tabelele necesare din baza de date?
4. Dacă executarea manuală a procedurii stocate oferă utilizatorului final rezultatul necesar?
5. Dacă execuția manuală a procedurii stocate asigură că câmpurile tabelului sunt actualizate conform cerințelor aplicației testate?
6. Dacă executarea Procedurilor stocate permite invocarea implicită a declanșatorilor necesari?
7. Validarea prezenței oricăror proceduri stocate neutilizate.
8. Validarea pentru condiția Allow Null care se poate face la nivel de bază de date.
9. Validarea faptului că toate Procedurile și Funcțiile stocate au fost executate cu succes atunci când baza de date testată este goală.
10. Validarea integrării globale a modulelor de proceduri stocate conform cerințelor aplicației testate.

Unele dintre instrumentele utile de testare a bazelor de date pentru testarea procedurilor stocate sunt LINQ, instrumentul de testare SP etc.

Testarea declanșatorului

1. Dacă convențiile de codare necesare au fost respectate în timpul fazei de codare a declanșatorilor?
2. Verificați dacă declanșatoarele executate pentru tranzacțiile DML respective au îndeplinit condițiile cerute.
3. Dacă declanșatorul actualizează datele corect odată ce acestea au fost executate?
4. Validarea Actualizarii/Inserării/Ștergerii necesare declanșează funcționalitatea în domeniul aplicației testate.

Validare server baze de date

1. Verificați configurațiile serverului de baze de date, așa cum sunt specificate de cerințele de afaceri.
2. Verificați autorizarea utilizatorului necesar pentru a efectua numai acele niveluri de acțiuni care sunt cerute de aplicație.
3. Verificați dacă serverul de baze de date este capabil să răspundă nevoilor numărului maxim permis de tranzacții utilizator, așa cum este specificat de specificațiile cerințelor de afaceri.

Testarea bazelor de date funcționale

Testarea bazelor de date funcționale este un tip de testare a bazei de date care este utilizat pentru a valida cerințele funcționale ale unei baze de date din perspectiva utilizatorului final. Scopul principal al testării bazei de date funcționale este de a testa dacă tranzacțiile și operațiunile efectuate de utilizatorii finali care au legătură cu baza de date funcționează conform așteptărilor sau nu.

Următoarele sunt condițiile de bază care trebuie respectate pentru validările bazei de date.

• Dacă câmpul este obligatoriu, permițând valori NULL în acel câmp?
• Dacă lungimea fiecărui câmp este de dimensiune suficientă?
• Dacă toate câmpurile similare au aceleași nume în tabele?
• Dacă există câmpuri calculate prezente în baza de date?

Acest proces special este validarea mapărilor câmpului din punctul de vedere al utilizatorului final. În acest scenariu particular, testerul ar efectua o operație la nivel de bază de date și apoi ar naviga la elementul relevant al interfeței cu utilizatorul pentru a observa și valida dacă validările de câmp corespunzătoare au fost efectuate sau nu.

Ar trebui făcută și condiția inversă prin care prima operațiune este efectuată de către tester la interfața cu utilizatorul, iar apoi aceeași este validată din back-end.

Verificarea integrității și consecvenței datelor

Următoarele verificări sunt importante

1. Dacă datele sunt bine organizate din punct de vedere logic?
2. Dacă datele stocate în tabele sunt corecte și conform cerințelor afacerii?
3. Dacă există date inutile în aplicația testată?
4. Dacă datele au fost stocate conform cerințelor în ceea ce privește datele care au fost actualizate din interfața cu utilizatorul?
5. Dacă operațiunile TRIM au fost efectuate asupra datelor înainte de inserarea datelor în baza de date testată?
6. Dacă tranzacțiile au fost efectuate conform specificațiilor cerințelor de afaceri și dacă rezultatele sunt corecte sau nu?
7. Dacă datele au fost angajate în mod corespunzător dacă tranzacția a fost executată cu succes?
8. Dacă datele au fost retrocedate cu succes dacă tranzacția nu a fost executată cu succes de către utilizatorul final?
9. Dacă datele au fost retrocedate dacă tranzacția nu a fost executată cu succes și mai multe baze de date eterogene au fost implicate în tranzacția în cauză?
10. Dacă toate tranzacțiile au fost executate utilizând procedurile de proiectare necesare, așa cum sunt specificate de cerințele de afaceri ale sistemului?

Logare și securitatea utilizatorului

Validarea acreditărilor de conectare și de securitate a utilizatorului trebuie să ia în considerare următoarele lucruri.

1. Dacă aplicația împiedică utilizatorul să continue în aplicație în cazul a

• nume de utilizator invalid, dar parolă validă
• nume de utilizator valid, dar parolă nevalidă.
• nume de utilizator nevalid și parolă nevalidă.

2. Dacă utilizatorului i se permite să efectueze numai acele operațiuni specifice care sunt specificate de cerințele de afaceri?
3. Dacă datele sunt protejate împotriva accesului neautorizat?
4. Dacă există roluri de utilizator diferite create cu permisiuni diferite?
5. Dacă toți utilizatorii au necesare niveluri de acces la baza de date specificată, conform specificațiilor de afaceri?
6. Verificați dacă datele sensibile, cum ar fi parolele, numerele cărților de credit sunt criptate și nu sunt stocate ca text simplu în baza de date. Este o practică bună să vă asigurați că toate conturile ar trebui să aibă parole care sunt complexe și nu sunt ușor de ghicit.

Testare nefuncțională

Testare nefuncțională în contextul testării bazei de date pot fi clasificate în diferite categorii, conform cerințelor de afaceri. Acestea pot fi teste de încărcare, testare de stres, Testarea securității, Testarea utilizabilității și Testarea compatibilității, și așa mai departe. Testarea de sarcină, precum și testarea de stres, care pot fi grupate în gama Testării performanței, servesc două scopuri specifice când vine vorba de rolul testării nefuncționale.

Cuantificarea riscului– Cuantificarea riscului ajută părțile interesate să stabilească diferitele cerințe privind timpul de răspuns al sistemului la nivelurile necesare de încărcare. Aceasta este intenția originală a oricărui de asigurare a calității sarcină. Trebuie să remarcăm că testarea sarcinii nu atenuează riscul în mod direct, ci prin procesele de identificare și cuantificare a riscului, prezintă oportunități corective și un impuls pentru remediere care va atenua riscul.

Cerința minimă de echipare a sistemului– Configurația minimă a sistemului care va permite sistemului să îndeplinească așteptările de performanță declarate oficial ale părților interesate. Astfel că hardware-ul, software-ul străin și costul de proprietate asociat pot fi minimizate. Această cerință particulară poate fi clasificată ca cerință generală de optimizare a afacerii.

Încărcarea testelor

Scopul oricărui test de sarcină trebuie să fie clar înțeles și documentat. Următoarele tipuri de configurații sunt obligatorii testarea sarcinii.

1. Tranzacțiile utilizatorului cel mai frecvent utilizate au potențialul de a afecta performanța tuturor celorlalte tranzacții dacă acestea nu sunt eficiente.
2. Cel puțin o tranzacție de utilizator fără editare ar trebui inclusă în suita finală de testare, astfel încât performanța unor astfel de tranzacții să poată fi diferențiată de alte tranzacții mai complexe.
3. Tranzacțiile mai importante care facilitează obiectivele de bază ale sistemului ar trebui incluse, deoarece eșecul sub o încărcare a acestor tranzacții are, prin definiție, cel mai mare impact.
4. Ar trebui inclusă cel puțin o tranzacție editabilă, astfel încât performanță a unor astfel de tranzacții pot fi diferențiate de alte tranzacții.
5. Timp de răspuns optim sub un număr mare de utilizatori virtuali pentru toate cerințele potențiale.
6. Timp efectiv pentru preluarea diferitelor înregistrări.

Instrumentele importante de testare a sarcinii sunt LoadRunner Professional, câștigă alergător și JMeter.

Instrumentele importante de testare a stresului sunt LoadRunner Professional si JMeter.

Cele mai frecvente probleme care apar în timpul testării bazei de date

A significant amount of overhead could be involved to determine the state of the database transactions

Soluţie: Planificarea generală a procesului și calendarul trebuie organizate astfel încât să nu apară probleme bazate pe timp și costuri.

New test data have to be designed after cleaning up of the old test data.

Soluţie: Ar trebui să existe un plan și o metodologie prealabilă pentru generarea datelor de testare.

An SQL generator is required to transform SQL validators in order to ensure the SQL queries are apt for handling the required database test cases.

Soluţie: Menținerea interogărilor SQL și actualizarea lor continuă reprezintă o parte semnificativă a procesului general de testare, care ar trebui să facă parte din strategie de testare.

The above mentioned prerequisite ensure that the set-up of the database testing procedure could be costly as well as time consuming.

Soluţie: Ar trebui să existe un echilibru fin între calitate și durata generală a programului proiectului.

Mituri sau concepții greșite legate de testarea bazelor de date

Database Testing requires plenty of expertise and it is a very tedious job

Realitate: Testarea eficientă și eficientă a bazelor de date în testarea software-ului oferă stabilitate funcțională pe termen lung pentru aplicația generală, prin urmare, este necesar să se depună o muncă grea în spatele acesteia.

Database testing adds extra work bottleneck

Realitate: Dimpotrivă, testarea bazelor de date adaugă mai multă valoare lucrării generale prin descoperirea problemelor ascunse și astfel contribuind în mod proactiv la îmbunătățirea aplicației generale.

Database testing slows down the overall development process

Realitate: O cantitate semnificativă de testare a bazei de date ajută la îmbunătățirea generală a calității aplicației de bază de date.

Database testing could be excessively costly

Realitate: Orice cheltuială pentru testarea bazelor de date este o investiție pe termen lung care duce la stabilitatea și robustețea aplicației pe termen lung. Astfel cheltuielile pentru testarea bazei de date sau SQL Testarea este necesară.

Cele mai bune practici

• Toate datele, inclusiv metadatele, precum și datele funcționale, trebuie validate în conformitate cu maparea lor de către documentele de specificare a cerințelor.
• Verificarea date de testare care a fost creat de/în consultare cu echipa de dezvoltare trebuie validat.
• Validarea datelor de ieșire prin utilizarea atât a procedurilor manuale, cât și a celor de automatizare.
• Implementarea diferitelor tehnici, cum ar fi tehnica de graficare a cauzei efect, tehnica de partiționare echivalență și tehnica de analiză a valorii la limită pentru generarea condițiilor necesare pentru datele de testare.
• Trebuie validate și regulile de validare a integrității referențiale pentru tabelele de baze de date necesare.
• Selectarea valorilor implicite ale tabelului pentru validarea conformității bazei de date este un concept foarte important Dacă evenimentele de jurnal au fost adăugate cu succes în baza de date pentru toate evenimentele de conectare necesare
• Lucrările programate se execută în timp util?
• Faceți backup în timp util al bazei de date.

De asemenea, verifica- Întrebări și răspunsuri la interviu pentru testarea bazei de date