Tutoriel de test de base de données (données)

Les membres de l'équipe de test et de développement accordent généralement la plus grande importance à l'interface graphique, car l'interface utilisateur graphique se trouve être la partie la plus visible de l'application. Cependant, ce qui est également important, c'est de valider les informations qui sont au cœur de l'application, c'est-à-dire la BASE DE DONNÉES.

Considérons une application bancaire dans laquelle un utilisateur effectue des transactions. Maintenant, du point de vue des tests de base de données ou des tests de base de données, les choses sont importantes :

1. L'application stocke les informations de transaction dans la base de données de l'application et les affiche correctement à l'utilisateur.
2. Aucune information n'est perdue dans le processus.
3. Aucune information d'opération partiellement exécutée ou abandonnée n'est enregistrée par l'application.
4. Aucune personne non autorisée n'est autorisée à accéder aux informations de l'utilisateur.

Pour assurer tous ces objectifs ci-dessus, nous devons utiliser la validation des données ou le test des données.

Différences entre les tests d'interface utilisateur et les tests de données

Test de l'interface utilisateur	Test de base de données ou de données
Ce type de test est également appelé test d'interface utilisateur graphique ou test frontal.	Ce type de test est également connu sous le nom de test backend ou test de données.
Ce type de test concerne principalement tous les éléments testables ouverts à l'utilisateur pour la visualisation et l'interaction, tels que les formulaires, les présentations, les graphiques, les menus et les rapports, etc. (créés via VB, VB.net, VC++, Delphi – Outils frontaux)	Ce type de test porte principalement sur tous les éléments testables qui sont généralement cachés à l'utilisateur pour la visualisation. Ceux-ci incluent les processus internes et le stockage comme Assembly, un SGBD comme Oracle, Serveur SQL, MYSQL, etc.
Ce type de test comprend la validation des zones de texte sélectionner les listes déroulantes calendriers et boutons Navigation de page affichage des images Apparence et convivialité de l'application globale	Ce type de test consiste à valider : le schéma table de base de données colonnes clés et index déclencheurs de procédures stockées validations de serveur de base de données validation de la duplication des données
Le testeur doit bien connaître les exigences de l'entreprise ainsi que l'utilisation des outils de développement et l'utilisation des cadres et des outils d'automatisation.	Pour être en mesure d'effectuer des tests backend, le testeur doit avoir une solide expérience dans les concepts de serveur de base de données et de langage de requête structuré.

Types de test de base de données

Les 3 types de test de base de données sont

1. Test structurel
2. Essais fonctionnels
3. Tests non fonctionnels

Dans ce didacticiel de test de base de données, nous examinerons chaque type et ses sous-types un par un.

Qu'est-ce que le test de schéma ?

Test de schéma dans les tests de base de données, valide divers formats de schéma associés à la base de données et vérifie si les formats de mappage des tables/vues/colonnes sont compatibles avec les formats de mappage de l'interface utilisateur. L'objectif principal des tests de schéma est de s'assurer que le mappage de schéma entre le front-end et le back-end est similaire. Ainsi, il est également appelé test de cartographie.

Discutons des points de contrôle les plus importants pour les tests de schéma.

1. Validation des différents formats de schéma associés aux bases de données. Souvent, le format de mappage de la table peut ne pas être compatible avec le format de mappage présent au niveau de l'interface utilisateur de l'application.
2. Une vérification est nécessaire dans le cas de tables/vues/colonnes non mappées.
3. Il est également nécessaire de vérifier si les bases de données hétérogènes dans un environnement sont cohérentes avec le mappage global de l'application.

Examinons également certains des outils de test de base de données intéressants pour valider les schémas de base de données.

• DBUnit qui est intégré à Ant est très approprié pour les tests de mappage.
• SQL Server permet aux testeurs de pouvoir vérifier et interroger le schéma de la base de données en écrivant des requêtes simples et non via du code.

Par exemple, si les développeurs veulent modifier une structure de table ou la supprimer, le testeur voudra s'assurer que toutes les procédures stockées et vues qui utilisent cette table sont compatibles avec la modification particulière. Un autre exemple pourrait être que si les testeurs veulent vérifier les changements de schéma entre 2 bases de données, ils peuvent le faire en utilisant des requêtes simples.

Table de base de données, test de colonne

Examinons divers contrôles pour les tests de base de données et de colonne.

1. Si le mappage des champs et des colonnes de la base de données dans le backend est compatible avec ces mappages dans le front-end ?
2. Validation de la longueur et de la convention de dénomination des champs et des colonnes de la base de données comme spécifié par les exigences.
3. Validation de la présence de toutes les tables/colonnes de base de données inutilisées/non mappées.
4. Validation de la compatibilité du

• Type de données
• longueurs de champ

des colonnes de la base de données back-end avec celle de celles présentes sur le front-end de l'application.

5. Indique si les champs de la base de données permettent à l'utilisateur de fournir les entrées utilisateur souhaitées, comme l'exigent les documents de spécification des exigences métier.

Test des clés et des index

Vérifications importantes des clés et des index –

1. Vérifiez si le nécessaire

• Clé primaire
• Clé étrangère

des contraintes ont été créées sur les tables requises.

2. Vérifiez si les références des clés étrangères sont valides.
3. Vérifiez si le type de données de la clé primaire et les clés étrangères correspondantes sont identiques dans les deux tables.
4. Vérifiez si les conventions de nommage requises ont été respectées pour toutes les clés et tous les index.
5. Vérifiez la taille et la longueur des champs et des index requis.
6. Que ce soit le nécessaire

• Clusterindex ed
• Non Clusterindex ed

ont été créés sur les tables requises, comme spécifié par les exigences de l'entreprise.

Test de procédures stockées

Les tests importants pour vérifier les procédures stockées sont :

1. Si l'équipe de développement a adopté les conventions standard de codage requises, A) et B) la gestion des exceptions et des erreurs. Pour toutes les procédures stockées de tous les modules de l'application testée.
2. L'équipe de développement a-t-elle couvert toutes les conditions/boucles en appliquant les données d'entrée requises à l'application testée ?
3. L'équipe de développement a-t-elle correctement appliqué l'opération TRIM chaque fois que des données sont extraites des tables requises dans la base de données ?
4. L'exécution manuelle de la procédure stockée fournit-elle à l'utilisateur final le résultat requis ?
5. L'exécution manuelle de la procédure stockée garantit-elle que les champs de la table sont mis à jour conformément aux exigences de l'application testée ?
6. L'exécution des procédures stockées permet-elle l'invocation implicite des déclencheurs requis ?
7. Validation de la présence d'éventuelles procédures stockées non utilisées.
8. Validation de la condition Allow Null qui peut être effectuée au niveau de la base de données.
9. Validation du fait que toutes les Procédures Stockées et Fonctions ont été exécutées avec succès lorsque la Base de données testée est vide.
10. Validation de l'intégration globale des modules de procédure stockée selon les exigences de l'application testée.

Certains des outils de test de base de données utiles pour tester les procédures stockées sont LINQ, l'outil de test SP, etc.

Test de déclenchement

1. Les conventions de codage requises ont-elles été respectées lors de la phase de codage des déclencheurs ?
2. Vérifiez si les déclencheurs exécutés pour les transactions DML respectives ont rempli les conditions requises.
3. Le déclencheur met-il correctement à jour les données une fois qu'elles ont été exécutées ?
4. Validation de la fonctionnalité requise des déclencheurs de mise à jour/insertion/suppression dans le domaine de l'application testée.

Validations du serveur de base de données

1. Vérifiez les configurations du serveur de base de données conformément aux exigences de l'entreprise.
2. Vérifiez l'autorisation de l'utilisateur requis pour effectuer uniquement les niveaux d'actions requis par l'application.
3. Vérifiez que le serveur de base de données est en mesure de répondre aux besoins du nombre maximal autorisé de transactions utilisateur tel que spécifié par les spécifications des exigences métier.

Test de base de données fonctionnelle

Test de base de données fonctionnelle est un type de test de base de données utilisé pour valider les exigences fonctionnelles d'une base de données du point de vue de l'utilisateur final. L'objectif principal des tests de base de données fonctionnels est de tester si les transactions et les opérations effectuées par les utilisateurs finaux qui sont liées à la base de données fonctionnent comme prévu ou non.

Voici les conditions de base qui doivent être respectées pour les validations de base de données.

• Si le champ est obligatoire tout en autorisant les valeurs NULL sur ce champ ?
• La longueur de chaque champ est-elle suffisante ?
• Tous les champs similaires ont-ils les mêmes noms dans les tables ?
• Existe-t-il des champs calculés présents dans la base de données ?

Ce processus particulier est la validation des mappages de champs du point de vue de l'utilisateur final. Dans ce scénario particulier, le testeur effectuerait une opération au niveau de la base de données, puis naviguerait vers l'élément d'interface utilisateur approprié pour observer et valider si les validations de champ appropriées ont été effectuées ou non.

La condition inverse selon laquelle la première opération est effectuée par le testeur au niveau de l'interface utilisateur, puis la même chose est validée à partir du back-end doit également être effectuée.

Vérification de l'intégrité et de la cohérence des données

Les vérifications suivantes sont importantes

1. Si les données sont logiquement bien organisées ?
2. Les données stockées dans les tables sont-elles correctes et conformes aux exigences de l'entreprise ?
3. Existe-t-il des données inutiles présentes dans l'application testée ?
4. Les données ont-elles été stockées conformément aux exigences concernant les données mises à jour à partir de l'interface utilisateur ?
5. Les opérations TRIM ont-elles été effectuées sur les données avant d'insérer des données dans la base de données testée ?
6. Les transactions ont-elles été effectuées conformément aux spécifications des besoins de l'entreprise et les résultats sont-ils corrects ou non ?
7. Si les données ont été correctement validées si la transaction a été exécutée avec succès ?
8. Si les données ont été restaurées avec succès si la transaction n'a pas été exécutée avec succès par l'utilisateur final ?
9. Si les données ont été restaurées si la transaction n'a pas été exécutée avec succès et si plusieurs bases de données hétérogènes ont été impliquées dans la transaction en question ?
10. Toutes les transactions ont-elles été exécutées en utilisant les procédures de conception requises telles que spécifiées par les exigences commerciales du système ?

Connexion et sécurité des utilisateurs

Les validations des identifiants de connexion et de sécurité de l'utilisateur doivent tenir compte des éléments suivants.

1. Si l'application empêche l'utilisateur d'aller plus loin dans l'application en cas de

• nom d'utilisateur invalide mais mot de passe valide
• nom d'utilisateur valide mais mot de passe invalide.
• nom d'utilisateur invalide et mot de passe invalide.

2. Si l'utilisateur est autorisé à effectuer uniquement les opérations spécifiques qui sont spécifiées par les exigences de l'entreprise ?
3. Les données sont-elles sécurisées contre tout accès non autorisé ?
4. Existe-t-il différents rôles d'utilisateur créés avec différentes autorisations ?
5. Tous les utilisateurs disposent-ils des niveaux d'accès requis sur la base de données spécifiée, comme l'exigent les spécifications commerciales ?
6. Vérifiez que les données sensibles telles que les mots de passe, les numéros de carte de crédit sont cryptées et ne sont pas stockées en texte brut dans la base de données. Il est recommandé de s'assurer que tous les comptes doivent avoir des mots de passe complexes et difficiles à deviner.

Tests non fonctionnels

Tests non fonctionnels dans le contexte des tests de base de données peuvent être classés en différentes catégories selon les besoins de l'entreprise. Il peut s'agir de tests de charge, de tests de résistance, Test de sécurité, Tests d'utilisabilité et Test de compatibilité, et ainsi de suite. Les tests de charge, ainsi que les tests de résistance, qui peuvent être regroupés sous la gamme des tests de performance, servent deux objectifs spécifiques en ce qui concerne le rôle des tests non fonctionnels.

Quantification des risques– La quantification des risques aide les parties prenantes à déterminer les différentes exigences de temps de réponse du système sous les niveaux de charge requis. C'est l'intention initiale de tout assurance de la qualité tâche. Nous devons noter que les tests de charge n'atténuent pas directement les risques, mais à travers les processus d'identification et de quantification des risques, présentent des opportunités correctives et une impulsion pour la remédiation qui atténuera les risques.

Configuration minimale requise pour l'équipement du système– La configuration minimale du système qui permettra au système de répondre aux attentes de performance formellement énoncées des parties prenantes. Ainsi, le matériel, les logiciels et les coûts de possession associés peuvent être minimisés. Cette exigence particulière peut être classée comme l'exigence globale d'optimisation de l'entreprise.

test de charge

Le but de tout test de charge doit être clairement compris et documenté. Les types de configurations suivants sont indispensables pour test de charge.

1. Les transactions utilisateur les plus fréquemment utilisées peuvent avoir un impact sur les performances de toutes les autres transactions si elles ne sont pas efficaces.
2. Au moins une transaction utilisateur non éditrice doit être incluse dans la suite de tests finale, afin que les performances de ces transactions puissent être différenciées de celles d'autres transactions plus complexes.
3. Les transactions les plus importantes qui facilitent les objectifs fondamentaux du système doivent être incluses, car l'échec sous une charge de ces transactions a, par définition, le plus grand impact.
4. Au moins une transaction modifiable doit être incluse afin que performant de ces transactions peut être différenciée des autres transactions.
5. Temps de réponse optimal sous un grand nombre d'utilisateurs virtuels pour toutes les exigences potentielles.
6. Heures effectives pour la récupération de divers enregistrements.

Les outils de test de charge importants sont LoadRunner Professionnel, gagner coureur et JMeter.

Les principaux outils de test de résistance sont LoadRunner Professionnel et JMeter.

Problèmes les plus courants lors des tests de base de données

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

Solution: La planification et le calendrier du processus global doivent être organisés de manière à ce qu'aucun problème lié au temps et au coût n'apparaisse.

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

Solution: Un plan et une méthodologie préalables pour la génération de données de test doivent être à portée de main.

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.

Solution: La maintenance des requêtes SQL et leur mise à jour continue est une partie importante du processus de test global qui devrait faire partie de l'ensemble stratégie de test.

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

Solution: Il doit y avoir un juste équilibre entre la qualité et la durée globale du projet.

Mythes ou idées fausses liés aux tests de bases de données

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

Réalité: Des tests de base de données efficaces et efficients dans les tests de logiciels offrent une stabilité fonctionnelle à long terme à l'application globale, il est donc nécessaire de travailler dur derrière.

Database testing adds extra work bottleneck

Réalité: Au contraire, les tests de base de données ajoutent plus de valeur au travail global en découvrant les problèmes cachés et en aidant ainsi de manière proactive à améliorer l'application globale.

Database testing slows down the overall development process

Réalité: Une quantité importante de tests de base de données contribue à l'amélioration globale de la qualité de l'application de base de données.

Database testing could be excessively costly

Réalité: Toute dépense consacrée aux tests de bases de données est un investissement à long terme qui conduit à la stabilité et à la robustesse à long terme de l'application. Ainsi, les dépenses consacrées aux tests de bases de données ou SQL Des tests sont nécessaires.

Meilleures pratiques

• Toutes les données, y compris les métadonnées ainsi que les données fonctionnelles, doivent être validées en fonction de leur mappage par les documents de spécification des exigences.
• Vérification de la données de test qui a été créé par / en consultation avec l'équipe de développement doit être validé.
• Validation des données de sortie en utilisant à la fois des procédures manuelles et automatisées.
• Déploiement de diverses techniques telles que la technique de représentation graphique de cause à effet, la technique de partitionnement d'équivalence et la technique d'analyse des valeurs limites pour la génération des conditions de données de test requises.
• Les règles de validation de l'intégrité référentielle des tables de base de données requises doivent également être validées.
• La sélection des valeurs de table par défaut pour la validation de la cohérence de la base de données est un concept très important Si les événements du journal ont été ajoutés avec succès dans la base de données pour tous les événements de connexion requis
• Les tâches planifiées s'exécutent-elles en temps voulu ?
• Effectuez une sauvegarde rapide de la base de données.

Vérifiez également Questions et réponses d'entrevue de test de base de données