database testing complete guide why
Una guia completa de proves de bases de dades amb consells i exemples pràctics:
Actualment, les aplicacions informàtiques són més complexes amb tecnologies com Android i també amb moltes aplicacions per a telèfons intel·ligents. Com més complexes són les puntes anteriors, més complicades són les puntes posteriors.
Per tant, és molt més important conèixer les proves de base de dades i poder validar les bases de dades de manera eficaç per garantir bases de dades de seguretat i qualitat.
En aquest tutorial, aprendreu tot sobre la prova de dades: per què, com i què provar?
La base de dades és una de les parts inevitables d’una aplicació de programari.
No importa si es tracta d'un web, d'escriptori o mòbil, client-servidor, peer-to-peer, empresa o empresa individual; la base de dades és necessària a tot arreu al backend.
De la mateixa manera, tant si es tracta de salut, finances, arrendament, venda al detall, aplicació de correu o controlant una nau espacial; una base de dades sempre està en acció darrere de l’escena.
A mesura que augmenta la complexitat de l'aplicació, apareix la necessitat d'una base de dades més forta i segura. De la mateixa manera, per a les aplicacions amb una alta freqüència de transaccions ( Per exemple, Aplicació bancària o financera), s’uneix la necessitat d’una eina de base de dades completa.
Avui en dia, tenim dades de grans dimensions i complexes que les bases de dades tradicionals no poden gestionar.
Hi ha diversos Eines de bases de dades estan disponibles al mercat Per exemple, MS-Access, MS SQL Server, SQL Server, Oracle, Oracle Financial, MySQL, PostgreSQL, DB2, Toad, Admirer, etc. Aquestes eines varien en cost, robustesa, funcions i seguretat. Cadascun d’aquests té els seus propis avantatges i inconvenients.
Què aprendreu:
- Per què provar la base de dades?
- Què cal provar (llista de comprovació de proves de bases de dades)
- Com provar la base de dades (procés pas a pas)
Per què provar la base de dades?
A continuació, veurem per què s’han de validar els aspectes següents d’un DB:
# 1) Assignació de dades
En sistemes de programari, les dades sovint viatgen d'anada i tornada des de la interfície d'usuari (interfície d'usuari) fins a la base de dades del backend i viceversa. Aquests són alguns aspectes que cal tenir en compte:
- Comproveu si els camps dels formularis d’interfície d’usuari / frontend s’assignen de manera coherent amb els camps corresponents de la taula de bases de dades. Normalment, aquesta informació de mapatge es defineix als documents de requisits.
- Sempre que es realitza una acció determinada a la part frontal d'una aplicació, s'invoca una acció CRUD (Crea, Recupera, Actualitza i Suprimeix) corresponent a la part posterior. Un provador haurà de comprovar si s’invoca l’acció correcta i si l’acció invocada en si és correcta o no.
# 2) Validació de propietats ACID
Atomicitat, consistència, aïllament i durabilitat. Totes les transaccions que realitza una base de dades han de complir aquestes quatre propietats.
- Atomicitat significa que una transacció falla o passa. Això significa que, fins i tot si falla una sola part de la transacció, significa que ha fallat tota la transacció. Normalment, això s’anomena la regla del “tot o res”.
- Coherència : Una transacció sempre donarà lloc a un estat vàlid de la base de dades
- Aïllament : Si hi ha diverses transaccions i s'executen alhora, el resultat / estat de la base de dades hauria de ser el mateix que si s'executessin una darrere l'altra.
- Durabilitat : Un cop feta i compromesa una transacció, cap factor extern com la pèrdua d'energia o el bloqueig haurien de poder canviar-la
Lectura suggerida = >> Tutorial de transaccions MySQL
# 3) Integritat de dades
Per a qualsevol dels fitxers Operacions CRUD , els valors / estat actualitzats i més recents de les dades compartides haurien d'aparèixer a tots els formularis i pantalles. El valor no s’ha d’actualitzar en una pantalla i mostrar-ne un de més antic en una altra.
Quan l'aplicació està en execució, el fitxer l'usuari final utilitza principalment les operacions 'CRUD' facilitades per l'eina DB .
C: Crea - Quan l'usuari 'Desa' qualsevol transacció nova, es realitza l'operació 'Crea'.
R: Recupera - Quan l'usuari 'Cerca' o 'Mostra' qualsevol transacció desada, es realitza l'operació 'Recupera'.
U: Actualització - Quan l'usuari 'Edita' o 'Modifica' un registre existent, es realitza l'operació 'Actualitza' del DB.
D: Suprimeix - Quan un usuari 'Elimina' qualsevol registre del sistema, es realitza l'operació 'Suprimeix' del DB.
Qualsevol operació de base de dades realitzada per l'usuari final sempre és una de les quatre anteriors.
Així doncs, creeu els vostres casos de prova de DB de manera que inclogui la comprovació de les dades en tots els llocs on sembli per veure si són sempre iguals.
# 4) Conformitat de la norma empresarial
Més complexitat a les bases de dades significa components més complicats com restriccions relacionals, activadors, procediments emmagatzemats, etc. Per tant, els verificadors hauran de fer consultes SQL adequades per validar aquests objectes complexos.
Què cal provar (llista de comprovació de proves de bases de dades)
# 1) Transaccions
En provar transaccions, és important assegurar-se que compleixen les propietats ACID.
Aquestes són les afirmacions que s’utilitzen habitualment:
- COMENÇA LA TRANSACCIÓ TRANSACCIÓ #
- FINALITZAR LA TRANSACCIÓ TRANSACCIÓ #
La declaració Rollback garanteix que la base de dades es mantingui en un estat coherent.
- TRANSACCIÓ ROLLBACK #
Un cop executades aquestes sentències, utilitzeu una selecció per assegurar-vos que els canvis s'han reflectit.
- SELECCIÓ * DEL TABLENAME
# 2) Esquemes de bases de dades
Un esquema de base de dades no és res més que una definició formal de com s’organitzaran les dades dins d’una base de dades. Per provar-ho:
- Identifiqueu els requisits en funció dels quals funciona la base de dades. Requisits de mostra:
- Claus primàries que s'han de crear abans de crear qualsevol altre camp.
- Les claus estrangeres s’han d’indexar completament per facilitar-ne la cerca i la cerca.
- Noms de camps que comencen o acaben amb certs caràcters.
- Camps amb la restricció que determinats valors es poden inserir o no.
- Utilitzeu un dels mètodes següents segons la rellevància:
- Consulta SQL DESC
per validar l’esquema.
- Expressions regulars per validar els noms dels camps individuals i els seus valors
- Eines com SchemaCrawler
# 3) Desencadenants
Quan es produeix un esdeveniment determinat en una taula determinada, es pot instruir automàticament un fragment de codi (un activador) per executar-lo.
Per exemple, un nou alumne es va unir a una escola. L’estudiant està cursant 2 classes: matemàtiques i ciències. L'estudiant s'afegeix a la 'taula d'estudiants'. Un activador podria afegir l'estudiant a les taules d'assignatures corresponents un cop s'afegeixi a la taula d'estudiants.
El mètode habitual per provar és executar primer la consulta SQL incrustada al Trigger de forma independent i registrar el resultat. Seguiu això amb l'execució del Trigger en conjunt. Compareu els resultats.
Aquests es proven tant en les fases de proves de Black-box com de White-box.
la millor manera de descarregar de YouTube a mp3
- Proves de caixa blanca : Els controladors i els controladors s’utilitzen per inserir o actualitzar o suprimir dades que donarien lloc a la invocació del disparador. La idea bàsica és provar la base de dades sola fins i tot abans que es faci la integració amb la interfície (UI).
- Proves de caixa negra :
a) Des de la IU i el DB, la integració ja està disponible; podem inserir / suprimir / actualitzar dades des de la portada de manera que s’invoque el disparador. A continuació, es poden utilitzar sentències Select per recuperar les dades de la base de dades per veure si el desencadenant va realitzar correctament l'operació prevista.
b) La segona manera de provar-ho és carregar directament les dades que invocaran el Trigger i veure si funciona com es volia.
# 4) Procediments emmagatzemats
Els procediments emmagatzemats són més o menys similars a les funcions definides per l'usuari. Es poden invocar mitjançant instruccions de procediment de trucada / procediment d'execució i la sortida sol ser en forma de conjunts de resultats.
Aquests s’emmagatzemen al RDBMS i estan disponibles per a aplicacions.
Aquests també es posen a prova durant:
- Proves de caixa blanca: Els talons s’utilitzen per invocar els procediments emmagatzemats i, a continuació, es validen els resultats en funció dels valors esperats.
- Proves de caixa negra: Realitzeu una operació des de la portada (IU) de l'aplicació i comproveu l'execució del procediment emmagatzemat i els seus resultats.
# 5) Restriccions de camp
El valor per defecte, el valor únic i la clau externa:
- Realitzeu una operació frontal que exerceixi la condició de l'objecte de base de dades
- Valideu els resultats amb una consulta SQL.
Comprovar el valor per defecte d’un determinat camp és molt senzill. Forma part de la validació de regles de negoci. Podeu fer-ho manualment o utilitzar eines com QTP. De forma manual, podeu realitzar una acció que afegirà un valor diferent del valor per defecte del camp des de la part frontal i veure si es produeix un error.
El següent és un exemple de codi VBScript:
Function VBScriptRegularexpressionvlaidation(pattern , string_to_match) Set newregexp = new RegExp newregexp.Pattern = “” newregexp.Ignorecase = True newregexp.Global = True VBScriptRegularexpressionvlaidation = newregexp.Test(string_to_match) End Function Msgbox VBScriptRegularexpressionvlaidation(pattern , string_to_match) El resultat del codi anterior és True si existeix el valor predeterminat o False si no existeix.
La comprovació del valor únic es pot fer exactament de la mateixa manera que ho vam fer per als valors predeterminats. Proveu d'introduir valors de la IU que infringeixin aquesta regla i comproveu si es mostra un error.
El codi de seqüència de comandaments VB pot ser:
Function VBScriptRegularexpressionvlaidation(pattern , string_to_match) Set newregexp = new RegExp newregexp.Pattern = “” newregexp.Ignorecase = True newregexp.Global = True VBScriptRegularexpressionvlaidation = newregexp.Test(string_to_match) End Function Msgbox VBScriptRegularexpressionvlaidation(pattern , string_to_match) Per alClau estrangeraLa validació de restriccions utilitza càrregues de dades que introdueixen directament dades que infringeixen la restricció i comproven si l'aplicació les restringeix o no. Juntament amb la càrrega de dades de la part posterior, realitzeu també les operacions de la interfície d’usuari de manera que infringeixin les restriccions i comproveu si es mostra l’error rellevant.
Activitats de proves de dades
El provador de la base de dades s'hauria de centrar en les següents activitats de prova:
# 1) Assegureu-vos de l'assignació de dades:
El mapatge de dades és un dels aspectes clau de la base de dades i ha de ser provat amb rigor per tots els provadors de programari.
Assegureu-vos que l’assignació entre diferents formes o pantalles d’AUT i la seva base de dades no només sigui precisa, sinó també segons els documents de disseny (SRS / BRS) o el codi. Bàsicament, heu de validar l'assignació entre tots els camps front-end amb el seu camp de base de dades corresponent.
Per a totes les operacions CRUD, comproveu que les taules i els registres respectius s’actualitzen quan l’usuari fa clic a 'Desa', 'Actualitza', 'Cerca' o 'Suprimeix' de la GUI de l'aplicació.
Què heu de verificar:
- Assignació de taules, assignació de columnes i assignació de tipus de dades.
- Cerca de mapatge de dades.
- S'invoca l'operació CRUD correcta per a cada acció de l'usuari a la IU.
- L'operació CRUD té èxit.
# 2) Assegureu-vos de les propietats ACID de les transaccions:
Les propietats ACID de les transaccions de base de dades fan referència a la secció ' A tomicitat ',' C persistència ',' Jo solació 'i' D urabilitat ’. Cal fer proves adequades d’aquestes quatre propietats durant l’activitat de prova de la base de dades. Heu de verificar que cada transacció compleixi les propietats ACID de la base de dades.
Prenem un exemple senzill a través del codi SQL següent:
CREATE TABLE acidtest (A INTEGER, B INTEGER, CHECK (A + B = 100));La taula de proves ACID tindrà dues columnes: A & B. Hi ha una restricció d’integritat que la suma de valors en A i B sempre ha de ser 100.
Prova d’atomicitat s'assegurarà que qualsevol transacció realitzada en aquesta taula sigui total o nul·la, és a dir, no s'actualitzin registres si es produeix un error en qualsevol pas de la transacció.
Prova de consistència s’assegurarà que sempre que s’actualitzi el valor de la columna A o B, la suma continuï sent 100. No permetrà la inserció / supressió / actualització a A o B si la suma total és diferent de 100.
Prova d’aïllament s'assegurarà que si es produeixen dues transaccions al mateix temps i que intenten modificar les dades de la taula de proves ACID, aquestes traccions s'estan executant de manera aïllada.
Prova de durabilitat s'assegurarà que un cop realitzada una transacció sobre aquesta taula, continuarà sent així, fins i tot en cas de pèrdua d'energia, fallades o errors.
Aquesta àrea requereix proves més rigoroses, exhaustives i exhaustives si la vostra aplicació utilitza la base de dades distribuïda.
# 3) Assegureu la integritat de les dades
Tingueu en compte que diferents mòduls (és a dir, pantalles o formes) d’aplicació utilitzen les mateixes dades de maneres diferents i realitzen totes les operacions CRUD de les dades.
En aquest cas, assegureu-vos que l’últim estat de dades es reflecteixi a tot arreu. El sistema ha de mostrar els valors actualitzats i els més recents o l’estat d’aquestes dades compartides a tots els formularis i pantalles. Això s’anomena integritat de dades.
Casos de prova per validar la integritat de les dades de la base de dades:
- Comproveu si hi ha tots els activadors activats per actualitzar els registres de la taula de referència.
- Comproveu si hi ha dades incorrectes / no vàlides a les columnes principals de cada taula.
- Intenteu inserir dades incorrectes a les taules i observeu si es produeix algun error.
- Comproveu què passa si intenteu inserir un fill abans d’inserir-ne el pare (proveu de jugar amb les tecles primàries i externes).
- Comproveu si es produeix un error si suprimiu un registre que encara fa referència a les dades de qualsevol altra taula.
- Comproveu si els servidors i les bases de dades replicats estan sincronitzats.
# 4) Assegureu-vos de la precisió de les regles de negoci implementades:
Avui en dia, les bases de dades no estan destinades només a emmagatzemar els registres. De fet, les bases de dades s’han convertit en eines extremadament potents que proporcionen un ampli suport als desenvolupadors per implementar la lògica empresarial a nivell de base de dades.
Alguns exemples senzills de funcions potents són 'Integritat referencial', restriccions relacionals, activadors i procediments emmagatzemats.
Així, utilitzant aquestes i moltes altres funcions que ofereixen les bases de dades, els desenvolupadors implementen la lògica empresarial a nivell de base de dades. El comprovador ha de garantir que la lògica empresarial implementada sigui correcta i funcioni amb precisió.
Els punts anteriors descriuen els quatre 'Què fer' més importants de la prova de DB. Ara, passem a la part 'Com fer-ho'.
Com provar la base de dades (procés pas a pas)
La base de dades de proves generals de processos de proves no és molt diferent de cap altra aplicació.
A continuació es detallen els passos bàsics:
Pas 1) Prepareu l’entorn
Pas 2) Feu una prova
Pas 3) Comproveu el resultat de la prova
Pas 4) Valideu segons els resultats esperats
Pas 5) Informeu dels resultats a les parts interessades respectives
Normalment, s’utilitzen consultes SQL per desenvolupar les proves. L'ordre més utilitzat és 'Selecciona'.
Seleccioneu * des d'on
A part de Select, SQL té 3 tipus d’ordres importants:
- DDL: llenguatge de definició de dades
- DML: llenguatge de manipulació de dades
- DCL: llenguatge de control de dades
Vegem la sintaxi de les afirmacions més utilitzades.
Llenguatge de definició de dades Utilitza CREATE, ALTER, RENAME, DROP i TRUNCATE per gestionar taules (i índexs).
Llenguatge de manipulació de dades Inclou declaracions per afegir, actualitzar i suprimir registres.
Llenguatge de control de dades: Es tracta d’atorgar autorització als usuaris per a la manipulació i accés a les dades. Grant i Revoke són les dues afirmacions utilitzades.
Concedeix la sintaxi:
Atorgar selecció / actualització
Encès
A;Revoca la sintaxi:
Revoca la selecció / actualització
encès
des de;Alguns consells pràctics
# 1) Escriviu vosaltres mateixos consultes:
Per provar la base de dades amb precisió, el comprovador hauria de tenir molt bon coneixement de les sentències SQL i DML (Data Manipulation Language). El comprovador també ha de conèixer l'estructura de base de dades interna d'AUT.
Podeu combinar la GUI i la verificació de dades en taules respectives per obtenir una millor cobertura. Si utilitzeu el servidor SQL, podeu fer servir SQL Query Analyzer per escriure consultes, executar-les i recuperar resultats.
Aquesta és la forma més bona i robusta de provar una base de dades quan l’aplicació té un nivell de complexitat petit o mitjà.
Si l'aplicació és molt complexa, pot ser difícil o impossible que el provador escrigui totes les consultes SQL necessàries. Per a consultes complexes, heu de rebre ajuda del desenvolupador. Sempre recomano aquest mètode, ja que us proporciona confiança en les proves i també millora les vostres habilitats SQL.
# 2) Observeu les dades de cada taula:
Podeu fer la verificació de dades utilitzant els resultats de les operacions CRUD. Això es pot fer manualment mitjançant la interfície d’usuari de l’aplicació quan coneixeu la integració de la base de dades. Però aquesta pot ser una tasca feixuga i feixuga quan hi ha dades enormes en diferents taules de bases de dades.
Per a la prova manual de dades, el provador de bases de dades ha de tenir un bon coneixement de l'estructura de la taula de bases de dades.
# 3) Obteniu consultes dels desenvolupadors:
Aquesta és la forma més senzilla de provar la base de dades. Realitzeu qualsevol operació CRUD des de la GUI i verifiqueu-ne els impactes executant les respectives consultes SQL obtingudes del desenvolupador. Ni requereix un bon coneixement de SQL ni requereix un bon coneixement de l’estructura de base de dades de l’aplicació.
Però cal utilitzar aquest mètode amb precaució. Què passa si la consulta del desenvolupador és semànticament incorrecta o no compleix correctament els requisits de l’usuari? El procés simplement no validarà les dades.
# 4) Feu servir eines de proves d'automatització de bases de dades:
Hi ha diverses eines disponibles per al procés de proves de dades. Heu de triar l'eina correcta segons les vostres necessitats i fer-ne el millor ús.
=> Aquí teniu la llista de les eines de proves TOP DB que heu de comprovar
Conclusió
Amb totes aquestes característiques, factors i processos per provar en una base de dades, hi ha una demanda creixent perquè els verificadors siguin tècnicament competents en els conceptes clau de la base de dades. Malgrat algunes de les creences negatives que provar una base de dades crea nous colls d'ampolla i suposa una despesa addicional: aquest és un àmbit de proves que està cridant l'atenció i la demanda.
Lectura suggerida = >> Què és la prova de seguretat de bases de dades
Espero que aquest tutorial us hagi ajudat a centrar-vos en els motius per què és així i també us hagi proporcionat els detalls bàsics del que passa a provar una base de dades.
Si us plau, feu-nos saber els vostres comentaris i compartiu les vostres experiències personals si esteu treballant en proves de DB.
Lectura recomanada
- Proves de bases de dades amb JMeter
- 40+ millors eines de proves de bases de dades: solucions populars de proves de dades
- Un enfocament senzill per a la prova XML a la base de dades
- Tutorial de proves de magatzem de dades de proves ETL (una guia completa)
- Tutorial de proves de migració de dades: una guia completa
- Top 10 eines de disseny de bases de dades per crear models de dades complexos
- Tutorial de proves de magatzem de dades amb exemples | Guia de proves ETL
- Com provar la base de dades Oracle
^
- Consulta SQL DESC
