database testing complete guide why
Un guide complet des tests de bases de données avec des conseils pratiques et des exemples:
Les applications informatiques sont plus complexes de nos jours avec des technologies comme Android et aussi avec de nombreuses applications pour smartphones. Plus les extrémités avant sont complexes, plus les extrémités arrière deviennent complexes.
Il est donc d'autant plus important de se renseigner sur les tests DB et de pouvoir valider efficacement les bases de données pour garantir la sécurité et la qualité des bases de données.
Dans ce didacticiel, vous apprendrez tout sur les tests de données - pourquoi, comment et quoi tester?
La base de données est l'une des parties inévitables d'une application logicielle.
Peu importe qu'il s'agisse d'une entreprise Web, de bureau ou mobile, client-serveur, peer-to-peer, d'entreprise ou individuelle; la base de données est requise partout sur le backend.
De même, qu'il s'agisse de soins de santé, de finances, de crédit-bail, de vente au détail, d'application de courrier ou de contrôle d'un vaisseau spatial; une base de données est toujours en action dans les coulisses.
Au fur et à mesure que la complexité de l'application augmente, le besoin d'une base de données plus solide et sécurisée apparaît. De la même manière, pour les applications avec une fréquence de transactions élevée ( Par exemple, Application bancaire ou financière), la nécessité d'un outil de base de données complet est couplée.
De nos jours, nous disposons de mégadonnées volumineuses et complexes que les bases de données traditionnelles ne peuvent pas gérer.
Il y a plusieurs Outils de base de données sont disponibles sur le marché Par exemple, MS-Access, MS SQL Server, SQL Server, Oracle, Oracle Financial, MySQL, PostgreSQL, DB2, Toad, Admirer, etc. Ces outils varient en coût, robustesse, fonctionnalités et sécurité. Chacun de ces a ses propres avantages et inconvénients.
Ce que vous apprendrez:
- Pourquoi tester la base de données?
- Que tester (liste de contrôle des tests de base de données)
- Comment tester la base de données (processus étape par étape)
Pourquoi tester la base de données?
Ci-dessous, nous verrons pourquoi les aspects suivants d'une base de données doivent être validés:
# 1) Cartographie des données
Dans les systèmes logiciels, les données voyagent souvent de l'interface utilisateur (interface utilisateur) vers la base de données principale et vice versa. Voici donc quelques aspects à surveiller:
- Vérifiez si les champs des formulaires d'interface utilisateur / frontend sont mappés de manière cohérente avec les champs correspondants dans la table DB. En général, ces informations de mappage sont définies dans les documents d'exigences.
- Chaque fois qu'une certaine action est exécutée au front end d'une application, une action CRUD correspondante (Create, Retrieve, Update and Delete) est appelée au backend. Un testeur devra vérifier si la bonne action est invoquée et si l'action invoquée en elle-même réussit ou non.
# 2) Validation des propriétés ACID
Atomicité, cohérence, isolation et durabilité. Chaque transaction effectuée par une base de données doit respecter ces quatre propriétés.
- Atomicité signifie qu'une transaction échoue ou réussit. Cela signifie que même si une seule partie de la transaction échoue, cela signifie que la transaction entière a échoué. Habituellement, c'est ce qu'on appelle la règle du «tout ou rien».
- Cohérence : Une transaction entraînera toujours un état valide de la base de données
- Isolement : S'il y a plusieurs transactions et qu'elles sont exécutées toutes en même temps, le résultat / l'état du DB doit être le même que si elles étaient exécutées l'une après l'autre.
- Durabilité : Une fois qu'une transaction est effectuée et validée, aucun facteur externe comme une panne de courant ou un crash ne devrait pouvoir la changer
Suggestion de lecture = >> Tutoriel sur les transactions MySQL
# 3) Intégrité des données
Pour l'un des Opérations CRUD , les valeurs / statuts mis à jour et les plus récents des données partagées doivent apparaître sur tous les formulaires et écrans. La valeur ne doit pas être mise à jour sur un écran et afficher une valeur plus ancienne sur un autre.
Lorsque l'application est en cours d'exécution, le l'utilisateur final utilise principalement les opérations «CRUD» facilitées par l'outil DB .
C: Créer - Lorsque l’utilisateur «enregistre» une nouvelle transaction, l’opération «Créer» est effectuée.
R: récupérer - Lorsque l’utilisateur «recherche» ou «affiche» une transaction enregistrée, une opération de «récupération» est effectuée.
U: mise à jour - Lorsque l’utilisateur «édite» ou «modifie» un enregistrement existant, l’opération de «mise à jour» de la base de données est effectuée.
D: Supprimer - Lorsqu'un utilisateur «supprime» un enregistrement du système, une opération de «suppression» de la base de données est effectuée.
Toute opération de base de données effectuée par l'utilisateur final est toujours l'une des quatre opérations ci-dessus.
Concevez donc vos cas de test de base de données de manière à inclure la vérification des données à tous les endroits où il apparaît pour voir si elles sont toujours les mêmes.
# 4) Conformité aux règles commerciales
Plus de complexité dans les bases de données signifie des composants plus complexes comme les contraintes relationnelles, les déclencheurs, les procédures stockées, etc. Les testeurs devront donc proposer des requêtes SQL appropriées afin de valider ces objets complexes.
Que tester (liste de contrôle des tests de base de données)
# 1) Transactions
Lors du test des transactions, il est important de s'assurer qu'elles satisfont aux propriétés ACID.
Voici les déclarations couramment utilisées:
- COMMENCER LA TRANSACTION NUMÉRO DE TRANSACTION
- FIN DE LA TRANSACTION NUMÉRO DE LA TRANSACTION
L'instruction Rollback garantit que la base de données reste dans un état cohérent.
- N ° DE TRANSACTION ROLLBACK
Une fois ces instructions exécutées, utilisez une sélection pour vous assurer que les modifications ont été prises en compte.
- SELECT * FROM TABLENAME
# 2) Schémas de base de données
Un schéma de base de données n'est rien de plus qu'une définition formelle de la façon dont les données vont être organisées dans une base de données. Pour le tester:
- Identifiez les exigences en fonction desquelles la base de données fonctionne. Exemple d'exigences:
- Clés primaires à créer avant la création de tout autre champ.
- Les clés étrangères doivent être complètement indexées pour une extraction et une recherche faciles.
- Noms de champs commençant ou se terminant par certains caractères.
- Champs avec une contrainte selon laquelle certaines valeurs peuvent ou ne peuvent pas être insérées.
- Utilisez l'une des méthodes suivantes en fonction de la pertinence:
- Requête SQL DESC
pour valider le schéma.
- Expressions régulières pour valider les noms des champs individuels et leurs valeurs
- Des outils comme SchemaCrawler
# 3) Déclencheurs
Lorsqu'un certain événement a lieu sur une certaine table, un morceau de code (un déclencheur) peut être auto-chargé d'être exécuté.
Par exemple, un nouvel élève a rejoint une école. L'élève suit 2 cours: mathématiques et sciences. L'élève est ajouté à la «table des étudiants». Un déclencheur peut ajouter l'étudiant aux tables de matières correspondantes une fois qu'il est ajouté à la table des étudiants.
La méthode courante de test consiste à exécuter la requête SQL intégrée dans le déclencheur indépendamment d'abord et à enregistrer le résultat. Suivez ceci en exécutant le déclencheur dans son ensemble. Comparez les résultats.
Ceux-ci sont testés à la fois dans les phases de test Black-box et White-box.
commandes unix avec exemples et syntaxe
- Test de la boîte blanche : Les stubs et les pilotes sont utilisés pour insérer, mettre à jour ou supprimer des données qui entraîneraient l'appel du déclencheur. L'idée de base est de simplement tester la base de données seule avant même que l'intégration avec le frontal (UI) ne soit faite.
- Test de la boîte noire :
à) Depuis l'interface utilisateur et la base de données, l'intégration est désormais disponible; nous pouvons insérer / supprimer / mettre à jour les données du front-end de manière à ce que le déclencheur soit appelé. Ensuite, les instructions Select peuvent être utilisées pour récupérer les données de la base de données afin de voir si le déclencheur a réussi à effectuer l'opération prévue.
b) La deuxième façon de tester cela est de charger directement les données qui invoqueraient le déclencheur et de voir si cela fonctionne comme prévu.
# 4) Procédures stockées
Les procédures stockées sont plus ou moins similaires aux fonctions définies par l'utilisateur. Celles-ci peuvent être appelées par des instructions Call Procedure / Execute Procedure et la sortie est généralement sous la forme d'ensembles de résultats.
Ceux-ci sont stockés dans le SGBDR et sont disponibles pour les applications.
Ceux-ci sont également testés lors:
- Test de la boîte blanche: Les stubs sont utilisés pour appeler les procédures stockées, puis les résultats sont validés par rapport aux valeurs attendues.
- Test de la boîte noire: Effectuez une opération à partir du frontal (UI) de l'application et vérifiez l'exécution de la procédure stockée et de ses résultats.
# 5) Contraintes de champ
La valeur par défaut, la valeur unique et la clé étrangère:
- Effectuer une opération frontale qui exerce la condition d'objet de base de données
- Validez les résultats avec une requête SQL.
Vérifier la valeur par défaut d'un certain champ est assez simple. Cela fait partie de la validation des règles métier. Vous pouvez le faire manuellement ou vous pouvez utiliser des outils comme QTP. Manuellement, vous pouvez effectuer une action qui ajoutera une valeur autre que la valeur par défaut du champ à partir du front-end et voir si cela entraîne une erreur.
Voici un exemple de code 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) Le résultat du code ci-dessus est True si la valeur par défaut existe ou False si ce n'est pas le cas.
La vérification de la valeur unique peut être effectuée exactement comme nous l'avons fait pour les valeurs par défaut. Essayez de saisir des valeurs de l'interface utilisateur qui enfreindront cette règle et voyez si une erreur s'affiche.
Le code de script Automation VB peut être:
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) Pour leClé étrangèreLa validation de contrainte utilise des charges de données qui entrent directement des données qui violent la contrainte et voient si l'application les restreint ou non. Parallèlement au chargement des données back-end, effectuez également les opérations d'interface utilisateur frontale de manière à violer les contraintes et voir si l'erreur appropriée est affichée.
Activités de test des données
Database Tester devrait se concentrer sur les activités de test suivantes:
# 1) Assurer le mappage des données:
La cartographie des données est l'un des aspects clés de la base de données et elle doit être testée rigoureusement par chaque testeur de logiciel.
Assurez-vous que le mappage entre les différents formulaires ou écrans d'AUT et de sa base de données est non seulement précis, mais également conforme aux documents de conception (SRS / BRS) ou au code. Fondamentalement, vous devez valider le mappage entre chaque champ frontal avec son champ de base de données backend correspondant.
Pour toutes les opérations CRUD, vérifiez que les tables et les enregistrements respectifs sont mis à jour lorsque l'utilisateur clique sur «Enregistrer», «Mettre à jour», «Rechercher» ou «Supprimer» dans l'interface graphique de l'application.
Ce que vous devez vérifier:
- Mappage de table, mappage de colonne et mappage de type de données.
- Mappage de données de recherche.
- Une opération CRUD correcte est appelée pour chaque action de l'utilisateur dans l'interface utilisateur.
- L'opération CRUD a réussi.
# 2) Assurez-vous des propriétés ACID des transactions:
Les propriétés ACID des transactions DB font référence au « À tomicité »,« C onsistency »,« je solation »et« ré urabilité ». Un test approprié de ces quatre propriétés doit être effectué pendant l'activité de test de la base de données. Vous devez vérifier que chaque transaction satisfait les propriétés ACID de la base de données.
Prenons un exemple simple à travers le code SQL ci-dessous:
CREATE TABLE acidtest (A INTEGER, B INTEGER, CHECK (A + B = 100));La table de test ACID aura deux colonnes - A et B. Il existe une contrainte d'intégrité selon laquelle la somme des valeurs de A et B doit toujours être de 100.
Test d'atomicité s'assurera que toute transaction effectuée sur cette table est tout ou rien, c'est-à-dire qu'aucun enregistrement n'est mis à jour si une étape de la transaction échoue.
Test de cohérence garantit que chaque fois que la valeur de la colonne A ou B est mise à jour, la somme reste toujours 100. Elle ne permettra pas l'insertion / la suppression / la mise à jour dans A ou B si la somme totale est autre que 100.
Test d'isolement s'assurera que si deux transactions se produisent en même temps et tentent de modifier les données de la table de test ACID, ces tractions s'exécutent de manière isolée.
Test de durabilité s'assurera qu'une fois qu'une transaction sur cette table a été validée, elle le restera, même en cas de coupure de courant, de plantages ou d'erreurs.
Ce domaine nécessite des tests plus rigoureux, approfondis et approfondis si votre application utilise la base de données distribuée.
# 3) Assurer l'intégrité des données
Considérez que différents modules (c'est-à-dire des écrans ou des formulaires) d'application utilisent les mêmes données de différentes manières et effectuent toutes les opérations CRUD sur les données.
Dans ce cas, assurez-vous que le dernier état des données est reflété partout. Le système doit afficher les valeurs mises à jour et les plus récentes ou l'état de ces données partagées sur tous les formulaires et écrans. C'est ce qu'on appelle l'intégrité des données.
Scénarios de test pour valider l'intégrité des données de la base de données:
- Vérifiez si tous les déclencheurs sont en place pour mettre à jour les enregistrements de la table de référence.
- Vérifiez si des données incorrectes / non valides existent dans les principales colonnes de chaque table.
- Essayez d'insérer des données erronées dans les tableaux et observez si un échec se produit.
- Vérifiez ce qui se passe si vous essayez d'insérer un enfant avant d'insérer son parent (essayez de jouer avec les clés primaires et étrangères).
- Testez si un échec se produit si vous supprimez un enregistrement qui est toujours référencé par des données dans une autre table.
- Vérifiez si les serveurs et bases de données répliqués sont synchronisés.
# 4) Assurer l'exactitude des règles commerciales mises en œuvre:
Aujourd'hui, les bases de données ne sont pas uniquement destinées à stocker les enregistrements. En fait, les bases de données ont évolué pour devenir des outils extrêmement puissants qui fournissent un soutien suffisant aux développeurs pour implémenter la logique métier au niveau de la base de données.
Quelques exemples simples de fonctionnalités puissantes sont «l'intégrité référentielle», les contraintes relationnelles, les déclencheurs et les procédures stockées.
Ainsi, en utilisant ces fonctionnalités et bien d'autres proposées par les bases de données, les développeurs implémentent la logique métier au niveau de la base de données. Le testeur doit s'assurer que la logique métier implémentée est correcte et fonctionne avec précision.
Les points ci-dessus décrivent les quatre «What To» les plus importants pour tester DB. Maintenant, passons à la partie 'Comment faire'.
Comment tester la base de données (processus étape par étape)
La base de données générale des tests de processus de test n'est pas très différente de toute autre application.
Voici les étapes principales:
Étape 1) Préparez l'environnement
Étape 2) Lancer un test
Étape 3) Vérifier le résultat du test
Étape 4) Valider selon les résultats attendus
Étape # 5) Rapporter les résultats aux parties prenantes respectives
Habituellement, les requêtes SQL sont utilisées pour développer les tests. La commande la plus couramment utilisée est «Sélectionner».
Sélectionnez * d'où
Outre Select, SQL propose 3 types de commandes importants:
- DDL: langage de définition des données
- DML: langage de manipulation de données
- DCL: langage de contrôle des données
Voyons la syntaxe des instructions les plus couramment utilisées.
Langage de définition des données Utilise CREATE, ALTER, RENAME, DROP et TRUNCATE pour gérer les tables (et les index).
Langage de manipulation des données Comprend des instructions pour ajouter, mettre à jour et supprimer des enregistrements.
Langue de contrôle des données: Traite de l'autorisation des utilisateurs pour la manipulation et l'accès aux données. Grant et Revoke sont les deux instructions utilisées.
Syntaxe des subventions:
Sélection de subvention / mise à jour
Sur
À ;Révoquer la syntaxe:
Révoquer la sélection / la mise à jour
sur
de;Quelques conseils pratiques
# 1) Écrivez des requêtes vous-même:
Pour tester la base de données avec précision, le testeur doit avoir une très bonne connaissance des instructions SQL et DML (Data Manipulation Language). Le testeur doit également connaître la structure DB interne de AUT.
Vous pouvez combiner l'interface graphique et la vérification des données dans les tableaux respectifs pour une meilleure couverture. Si vous utilisez le serveur SQL, vous pouvez utiliser l'Analyseur de requêtes SQL pour écrire des requêtes, les exécuter et récupérer les résultats.
C'est le moyen le meilleur et le plus robuste de tester une base de données lorsque l'application est d'un niveau de complexité faible ou moyen.
Si l'application est très complexe, il peut être difficile ou impossible pour le testeur d'écrire toutes les requêtes SQL requises. Pour les requêtes complexes, vous prenez l'aide du développeur. Je recommande toujours cette méthode car elle vous donne confiance dans les tests et améliore également vos compétences SQL.
# 2) Observez les données de chaque tableau:
Vous pouvez effectuer une vérification des données à l'aide des résultats des opérations CRUD. Cela peut être fait manuellement à l'aide de l'interface utilisateur de l'application lorsque vous connaissez l'intégration de la base de données. Mais cela peut être une tâche fastidieuse et lourde lorsqu'il y a d'énormes données dans différentes tables de base de données.
Pour le test manuel des données, le testeur de base de données doit posséder une bonne connaissance de la structure des tables de la base de données.
# 3) Obtenez des requêtes des développeurs:
C'est le moyen le plus simple de tester la base de données. Effectuez toute opération CRUD à partir de l'interface graphique et vérifiez ses impacts en exécutant les requêtes SQL respectives obtenues du développeur. Il n’exige ni une bonne connaissance de SQL ni une bonne connaissance de la structure de base de données de l’application.
Mais cette méthode doit être utilisée avec prudence. Que faire si la requête fournie par le développeur est sémantiquement fausse ou ne répond pas correctement aux exigences de l'utilisateur? Le processus échouera tout simplement à valider les données.
# 4) Utilisez les outils de test d'automatisation de base de données:
Il existe plusieurs outils disponibles pour le processus de test des données. Vous devez choisir le bon outil selon vos besoins et en faire le meilleur usage.
=> Voici la liste des meilleurs outils de test DB que vous devriez vérifier
Conclusion
Avec toutes ces fonctionnalités, facteurs et processus à tester sur une base de données, il y a une demande croissante pour les testeurs d'être techniquement compétents dans les concepts clés de la base de données. Malgré certaines croyances négatives selon lesquelles le test d'une base de données crée de nouveaux goulots d'étranglement et représente beaucoup de dépenses supplémentaires - il s'agit d'un domaine de test qui attire une attention et une demande importantes.
Suggestion de lecture = >> Qu'est-ce que le test de sécurité de la base de données?
J'espère que ce tutoriel vous a aidé à vous concentrer sur les raisons pour lesquelles il en est ainsi et vous a également fourni les détails de base de ce qui se passe dans le test d'une base de données.
Faites-nous part de vos commentaires et partagez également vos expériences personnelles si vous travaillez sur des tests DB.
lecture recommandée
- Test de base de données avec JMeter
- 40+ meilleurs outils de test de base de données - Solutions de test de données populaires
- Une approche simple pour les tests de bases de données XML
- Didacticiel de test de l'entrepôt de données de test ETL (un guide complet)
- Tutoriel de test de migration de données: un guide complet
- Top 10 des outils de conception de base de données pour créer des modèles de données complexes
- Tutoriel de test de l'entrepôt de données avec des exemples | Guide de test ETL
- Comment tester Oracle Database
^
- Requête SQL DESC
