Test de base de données - Guide rapide
Les tests de base de données comprennent l'exécution de la validité des données, les tests d'intégrité des données, la vérification des performances liées à la base de données et le test des procédures, des déclencheurs et des fonctions de la base de données.
Exemple
Considérez une application qui capture les détails des transactions quotidiennes pour les utilisateurs et stocke les détails dans la base de données. Du point de vue des tests de base de données, les vérifications suivantes doivent être effectuées -
Les informations transactionnelles de l'application doivent être stockées dans la base de données et doivent fournir des informations correctes à l'utilisateur.
Les informations ne doivent pas être perdues lorsqu'elles sont chargées dans la base de données.
Seules les transactions terminées doivent être stockées et toutes les opérations incomplètes doivent être abandonnées par l'application.
L'autorisation d'accès à la base de données doit être maintenue. Aucun accès non approuvé ou non autorisé aux informations utilisateur ne doit être fourni.
Pourquoi devez-vous effectuer des tests de base de données?
Il existe plusieurs raisons pour lesquelles les tests de base de données sont effectués. Il est nécessaire d'effectuer une vérification de l'intégrité, de la validation et de la cohérence des données sur la base de données, car le système backend est chargé de stocker les données et est accessible à des fins multiples.
Voici quelques raisons courantes pour les tests de base de données -
Pour alléger la complexité des appels au backend de base de données, les développeurs augmentent l'utilisation de View et Stored Procédures.
Celles-ci Stored procédures et Viewscontiennent des tâches critiques telles que l'insertion des détails du client (nom, coordonnées, etc.) et des données de vente. Ces tâches doivent être testées à plusieurs niveaux.
Black-box testingeffectué sur le front-end est important, mais rend difficile d'isoler le problème. Les tests au niveau du système backend augmentent la robustesse des données. C'est pourquoi les tests de base de données sont effectués sur le système principal.
Dans une base de données, les données proviennent de plusieurs applications et il est possible que des données nuisibles ou incorrectes soient stockées dans la base de données. Par conséquent, il est nécessaire de vérifier régulièrement les composants de la base de données. En outre, l'intégrité et la cohérence des données doivent être vérifiées régulièrement.
Test de base de données vs test frontal
Le test de la base de données est différent du test de l'interface utilisateur frontale. Le tableau suivant met en évidence les principales différences -
Test de base de données | Test de l'interface utilisateur |
---|---|
Le test de base de données est connu sous le nom de validation des données et de test d'intégrité ou de test back-end. |
Le test d'interface utilisateur ou test frontal est également appelé test d'application ou test d'interface graphique. |
Le test de la base de données implique le test des composants back-end, qui ne sont pas visibles pour les utilisateurs. Cela inclut les composants de base de données et les systèmes de SGBD tels que My SQL, Oracle. |
Les tests d'interface utilisateur consistent à vérifier les fonctionnalités d'une application et de ses composants tels que des formulaires, des graphiques, des menus, des rapports, etc. Ces composants sont créés à l'aide d'outils de développement frontaux tels que VB.net, C #, Delphi, etc. |
Le test de base de données implique la vérification des procédures stockées, des vues, des schémas dans la base de données, des tables, des index, des clés, des déclencheurs, des validations de données et du contrôle de la cohérence des données. |
Les tests d'interface utilisateur consistent à vérifier la fonctionnalité de l'application, les boutons, les formulaires et les champs, le calendrier et les images, la navigation d'une page à l'autre et la fonctionnalité globale de l'application. |
Pour effectuer des tests de base de données, un testeur a besoin d'une connaissance approfondie du concept de base de données - comme les procédures et fonctions, les vues, les index, les clés et un bon SQL pratique. |
Pour effectuer des tests d'interface utilisateur, un testeur doit avoir une bonne compréhension des exigences métier, des connaissances fonctionnelles des applications, du codage, etc. |
Les données proviennent de plusieurs sources de données hétérogènes sur des applications Web, des applications intranet et diverses autres applications. |
Les données sont saisies manuellement dans les applications. Cela implique des tests fonctionnels des applications frontales. |
Sur la base de la fonction et de la structure d'une base de données, les tests DB peuvent être classés en trois catégories -
Structural Database Testing - Il traite du test des tables et des colonnes, des tests de schéma, des procédures stockées et des tests de vues, de la vérification des déclencheurs, etc.
Functional Testing- Il s'agit de vérifier la fonctionnalité de la base de données du point de vue de l'utilisateur. Les tests fonctionnels les plus courants sont les tests en boîte blanche et en boîte noire.
Nonfunctional Testing - Cela implique des tests de charge, des tests de risque dans la base de données, des tests de résistance, des exigences système minimales et traite des performances de la base de données.
Test de base de données structurelle
Le test de base de données structurelle implique la vérification des composants de la base de données qui ne sont pas exposés aux utilisateurs finaux. Il implique tous les composants du référentiel, qui sont utilisés pour stocker les données et ne sont pas modifiés par les utilisateurs finaux. Les administrateurs de base de données ayant une bonne maîtrise des procédures stockées SQL et d'autres concepts effectuent normalement ces tests.
Sont discutés les composants courants testés en ce qui concerne les tests structurels -
Test de schéma / mappage
Il s'agit de valider les objets de l'application frontale avec le mappage d'objets de base de données.
Dans le test de schéma -
Il arrive parfois que les objets d'application de l'utilisateur final ne soient pas correctement mappés ou compatibles avec les objets de base de données. Par conséquent, il est nécessaire de vérifier la validation des différents formats de schéma associés aux bases de données.
Il est nécessaire de trouver les objets non mappés dans la base de données, comme les tables, les vues, les colonnes, etc.
Il existe divers outils sur le marché qui peuvent être utilisés pour effectuer le mappage d'objets dans les schémas.
Example - Dans Microsoft SQL Server, un testeur peut écrire des requêtes simples pour vérifier et valider les schémas dans la base de données.
Si le testeur souhaite apporter des modifications à la structure d'une table, il doit s'assurer que toutes les stored les procédures ayant cette table sont compatibles avec ce changement.
Test des procédures et vues stockées
Dans ce test, un testeur s'assure que l'exécution manuelle des procédures stockées et des vues génère le résultat requis.
Le testeur garantit -
S'il permet aux déclencheurs requis d'être exécutés comme prévu.
Si l'équipe de développement a couvert toutes les boucles et conditions en transmettant les données aux applications dans les procédures.
S'il existe des procédures stockées inutilisées dans la base de données.
Les opérations TRIM sont appliquées correctement lorsque les données sont extraites des tables requises dans la base de données.
Validation de l'intégration globale des modules de procédure stockée selon les exigences de l'application testée.
Les mécanismes de gestion des exceptions et des erreurs sont suivis.
Les outils les plus courants utilisés pour effectuer des tests de procédures stockées sont LINQ, SP Test tool, etc.
Test de déclenchement
Lors des tests de déclenchement, un testeur doit s'assurer que:
Si les conventions de codage sont suivies pendant la phase de codage des déclencheurs.
Voir les déclencheurs exécutés remplit les conditions requises.
Si le déclencheur met à jour correctement les données, une fois qu'elles ont été exécutées.
La validation de la fonctionnalité de déclenchement de mise à jour / insertion / suppression de l'application testée.
Test des tableaux et des colonnes
Les domaines clés couverts par ces tests sont:
Validation des types de données dans la base de données dans des valeurs de champ dans l'application frontale.
Validation de la longueur du champ de données dans la base de données à la longueur des types de données dans l'application.
Vérifier s'il existe des tables ou des colonnes non mappées dans la base de données à partir d'objets de champ d'application.
Les conventions de dénomination des tables et des colonnes de la base de données sont vérifiées, si elles sont conformes ou non aux exigences métier.
La validation des clés et des index dans la base de données, c'est-à-dire que les clés primaires et étrangères dans les tables sont définies selon les besoins.
Vérifiez si les clés primaires et leurs clés étrangères correspondantes sont identiques dans deux tables.
Vérifiez que les caractéristiques uniques et NOT NULL des clés sont conservées.
La longueur et le type de données des clés et des index sont conservés conformément aux exigences.
Vérification du serveur de base de données
La vérification du serveur de base de données implique la vérification -
Si le serveur de base de données peut gérer le nombre prévu de transactions conformément aux exigences commerciales.
Si les détails de configuration des serveurs de base de données répondent aux exigences de l'entreprise.
Si l'autorisation de l'utilisateur est maintenue conformément aux exigences.
Test fonctionel
Les tests fonctionnels sont effectués en gardant à l'esprit le point de vue de l'utilisateur final; si les transactions et opérations requises exécutées par les utilisateurs finaux sont conformes aux spécifications commerciales.
Test de la boîte noire
Black Box Testing consiste à vérifier l'intégration de la base de données pour vérifier la fonctionnalité. Les cas de test sont simples et sont utilisés pour vérifier les données entrantes et sortantes de la fonction.
Diverses techniques telles que la technique de représentation graphique cause-effet, le partitionnement d'équivalence et l'analyse des valeurs limites sont utilisées pour tester la fonctionnalité de la base de données.
Ses advantages sont comme suit -
- Il est assez simple et est effectué dans les premiers stades de développement.
- Le coût de développement des cas de test est inférieur à celui des tests en boîte blanche.
Ses inconvénients sont les suivants -
- Quelques erreurs ne peuvent pas être détectées
- On ne sait pas combien de programmes doivent être testés.
Test de la boîte blanche
White Box Testing traite de la structure interne de la base de données et les détails des spécifications sont cachés aux utilisateurs. Cela implique le test des déclencheurs de base de données et des vues logiques, qui prendront en charge la refactorisation de la base de données.
Il effectue des tests de module des fonctions de base de données, des déclencheurs, des vues, des requêtes SQL, etc. Ce type de test valide les tables de base de données, les modèles de données, le schéma de base de données, etc. Il vérifie les règles d'intégrité référentielle. Il sélectionne les valeurs de table par défaut pour vérifier la cohérence de la base de données.
Les techniques les plus couramment utilisées pour effectuer des tests en boîte blanche sont la couverture des conditions, la couverture des décisions, la couverture des déclarations, etc.
Les erreurs de codage peuvent être détectées dans les tests en boîte blanche, de sorte que les bogues internes dans la base de données peuvent être éliminés. La limitation des tests en boîte blanche est que les instructions SQL ne sont pas couvertes.
Test non fonctionnel
Les tests non fonctionnels consistent à effectuer des tests de charge, des tests de résistance, la vérification des exigences système minimales pour répondre aux spécifications de l'entreprise, la recherche des risques et l'optimisation des performances de la base de données.
Test de charge
L'objectif principal des tests de charge est de vérifier si la plupart des transactions en cours d'exécution ont un impact sur les performances de la base de données.
Dans le test de charge, le testeur vérifie -
- Le temps de réponse pour exécuter les transactions pour plusieurs utilisateurs distants.
- Temps nécessaire à la base de données pour récupérer des enregistrements spécifiques.
Examples of load testing in different testing types -
- Exécution de la transaction la plus utilisée à plusieurs reprises pour voir les performances du système de base de données.
- Téléchargement d'une série de fichiers volumineux sur Internet.
- Exécution simultanée de plusieurs applications sur un ordinateur ou un serveur.
Test de stress
Des tests de résistance sont effectués pour identifier le point d'arrêt du système. Dans ce test, l'application est chargée de telle manière que le système échoue à un moment donné. Ce point est appelé lebreakpoint du système de base de données.
La détermination de l'état des transactions de base de données implique un effort considérable. Une planification appropriée est nécessaire pour éviter tout problème de temps et de coût.
Les outils de test de résistance les plus couramment utilisés sont LoadRunner et WinRunner.
Prenons un exampledes tests de résistance. Une application CRM peut accepter une charge utilisateur maximale de 50000 utilisateurs simultanés. Supposons que vous augmentiez la charge à 51 000 et effectuez des transactions telles que la mise à jour des enregistrements ou l'ajout d'une entrée. Dès que vous effectuez la transaction, l'application peut se synchroniser avec le système de base de données. Le test suivant consiste donc à effectuer avec une charge utilisateur de 52 000. Parfois, le test de résistance est également appeléFatigue Testing.
Le processus de test de la base de données est similaire au test d'autres applications. Les tests DB peuvent être décrits avec les processus clés indiqués ci-dessous.
- Mettre en place l'environnement
- Lancer un test
- Vérifiez le résultat du test
- Valider selon les résultats attendus
- Rapporter les résultats aux parties prenantes respectives
Diverses instructions SQL sont utilisées pour développer les cas de test. L'instruction SQL la plus courante, utilisée pour effectuer des tests de base de données, est laSelectdéclaration. En dehors de cela, diverses instructions DDL, DML, DCL peuvent également être utilisées.
Example - Créer, insérer, sélectionner, mettre à jour, etc.
Étapes de test de la base de données
Les tests de base de données ne sont pas un processus fastidieux et comprennent diverses étapes du cycle de vie des tests de bases de données conformément aux processus de test.
Les étapes clés des tests de bases de données sont:
- Vérification de l'état initial
- Essai
- Validation des résultats selon le résultat attendu
- Générer les résultats
First stagedans DB Testing consiste à vérifier l'état initial de la base de données avant de démarrer le processus de test. Ensuite, le comportement de la base de données est testé pour des cas de test définis. En fonction des résultats obtenus, les cas de test sont personnalisés.
Pour un test de base de données réussi, le flux de travail ci-dessous est exécuté par chaque test unique.
Cleaning up the database - S'il y a des données testables dans la base de données, elles doivent être vidées.
Set up Fixture - Cela implique de saisir les données dans la base de données et de vérifier l'état actuel de la base de données.
Perform test, verify results and generate results- Le test est exécuté et la sortie est vérifiée. Si la sortie correspond aux résultats attendus, l'étape suivante consiste à générer les résultats conformément aux exigences. Sinon, le test est répété pour trouver les bogues dans la base de données.
Ce chapitre explique les techniques les plus courantes utilisées pour effectuer des tests de base de données.
Test de schéma de base de données
Comme mentionné précédemment, cela implique de tester chaque objet dans le schéma.
Vérification des bases de données et des appareils
- Vérification du nom de la base de données
- Vérification du périphérique de données, du périphérique de journalisation et du périphérique de vidage
- Vérifier si suffisamment d'espace alloué pour chaque base de données
- Vérification du paramètre d'option de base de données
Vérification des règles de tables, colonnes, types de colonnes
Vérifiez les éléments ci-dessous pour découvrir les différences entre les paramètres réels et appliqués.
Nom de toutes les tables de la base de données
Noms de colonne pour chaque table
Types de colonnes pour chaque table
NULL valeur vérifiée ou non
Si une valeur par défaut est liée aux colonnes de table correctes
Définitions de règles pour corriger les noms de table et les privilèges d'accès
Clé et index
Vérifiez la clé et les index dans chaque table -
Clé primaire pour chaque table
Clés étrangères pour chaque table
Types de données entre une colonne de clé étrangère et une colonne dans une autre table Indices, clusterisés ou non clusterisés uniques ou non uniques
Tests de procédure stockée
Il s'agit de vérifier si une procédure stockée est définie et les résultats de sortie sont comparés. Dans un test de procédure stockée, les points suivants sont vérifiés -
Nom de la procédure stockée
Noms de paramètres, types de paramètres, etc.
Output- Si la sortie contient de nombreux enregistrements. Aucune ligne n'est effectuée ou seuls quelques enregistrements sont extraits.
Quelle est la fonction de la procédure stockée et ce qu'une procédure stockée n'est pas censée faire?
Passer des exemples de requêtes d'entrée pour vérifier si une procédure stockée extrait les données correctes.
Stored Procedure Parameters- Appel d'une procédure stockée avec des données de limite et avec des données valides. Rendez chaque paramètre invalide une fois et exécutez une procédure.
Return values- Vérifiez les valeurs renvoyées par la procédure stockée. En cas d'échec, une valeur différente de zéro doit être renvoyée.
Error messages check- Apportez des modifications de manière à ce que la procédure stockée échoue et générez chaque message d'erreur au moins une fois. Vérifiez tous les scénarios d'exception lorsqu'il n'y a pas de message d'erreur prédéfini.
Tests de déclenchement
Dans un test de déclenchement, le testeur doit effectuer les tâches suivantes -
- Assurez-vous que le nom du déclencheur est correct.
- Validez le déclencheur s'il est généré pour une colonne de table spécifique.
- Validation de la mise à jour du déclencheur.
- Mettez à jour un enregistrement avec des données valides.
- Mettez à jour un enregistrement avec des données non valides et couvrez chaque erreur de déclenchement.
- Mettez à jour un enregistrement lorsqu'il est toujours référencé par une ligne dans une autre table.
- Assurez la restauration des transactions en cas de panne.
- Découvrez tous les cas dans lesquels un déclencheur n'est pas censé annuler les transactions.
Scripts de configuration du serveur
Deux types de tests doivent être effectués -
- Configuration de la base de données à partir de zéro, et
- Pour configurer une base de données existante.
Tests d'intégration de SQL Server
Les tests d'intégration doivent être effectués une fois les tests des composants terminés.
Les procédures stockées doivent être appelées de manière intensive pour sélectionner, insérer, mettre à jour et supprimer des enregistrements dans différentes tables afin de détecter tout conflit et incompatibilité.
Tout conflit entre le schéma et les déclencheurs.
Tout conflit entre les procédures stockées et le schéma.
Tout conflit entre les procédures stockées et les déclencheurs.
Méthode de test fonctionnel
Les tests fonctionnels peuvent être effectués en divisant la base de données en modules selon la fonctionnalité. Les fonctionnalités sont des deux types suivants -
Type 1- Dans les tests de type 1, découvrez les caractéristiques du projet. Pour chaque fonctionnalité majeure, découvrez le schéma, les déclencheurs et les procédures stockées responsables de l'implémentation de cette fonction et placez-les dans un groupe fonctionnel. Ensuite, testez chaque groupe ensemble.
Type 2- Dans les tests de type 2, la frontière des groupes fonctionnels dans un back-end n'est pas évidente. Vous pouvez vérifier le flux de données et voir où vous pouvez vérifier les données. Commencez par le front-end.
Le processus suivant a lieu -
Lorsqu'un service a une demande ou enregistre des données, certaines procédures stockées sont appelées.
Les procédures mettront à jour certaines tables.
Ces procédures stockées seront l'endroit où commencer les tests et ces tables seront l'endroit où vérifier les résultats des tests.
Test de stress
Les tests de résistance consistent à obtenir une liste des principales fonctions de la base de données et des procédures stockées correspondantes. Suivez les étapes ci-dessous pour les tests de résistance -
Écrivez des scripts de test pour essayer ces fonctions et chaque fonction doit être vérifiée au moins une fois dans un cycle complet.
Exécutez les scripts de test encore et encore pendant une période de temps spécifique.
Vérification des fichiers journaux pour vérifier les blocages, les pannes de mémoire, la corruption des données, etc.
Tests de référence
Si votre base de données ne présente aucun problème de données ou bogue, les performances du système peuvent être vérifiées. Une mauvaise performance du système peut être trouvée dans les tests de référence en vérifiant les paramètres donnés ci-dessous -
- Performances au niveau du système
- Identifier les fonctions / fonctionnalités les plus utilisées
- Minutage - temps maximum, temps minimum et temps moyen pour exécuter les fonctions
- Volume d'accès
Test d'une base de données via Front-end
Des bogues back-end peuvent également être trouvés parfois en faisant des tests frontaux. Vous pouvez suivre les étapes simples ci-dessous pour détecter les bogues par des tests frontaux.
Écrivez des requêtes depuis le front-end et lancez les recherches.
Prenez un enregistrement existant, modifiez les valeurs de certains champs et enregistrez l'enregistrement. (Cela implique l'instruction UPDATE ou la mise à jour des procédures stockées et des déclencheurs de mise à jour.)
Insérez un nouvel élément de menu dans la fenêtre frontale. Remplissez les informations et enregistrez l'enregistrement. (Cela implique les instructions INSERT ou les procédures stockées d'insertion et les déclencheurs de suppression.)
Prenez un enregistrement existant, cliquez sur le bouton SUPPRIMER ou SUPPRIMER et confirmez la suppression. (Cela implique l'instruction DELETE ou les procédures stockées de suppression et les déclencheurs de suppression.)
Répétez ces cas de test avec des données non valides et voyez comment la base de données répond.
Dans ce chapitre, nous verrons quelques scénarios de test de base de données courants en ce qui concerne diverses méthodes de test.
Test de base de données structurée
Les scénarios de base de données courants en ce qui concerne les tests de base de données structurées sont indiqués ci-dessous
Vérifier le nom de la base de données, vérifier le périphérique de données, le périphérique de journal et le périphérique de vidage, vérifier si suffisamment d'espace alloué pour chaque base de données et vérifier le paramètre d'option de base de données.
Noms de toutes les tables de la base de données, noms de colonnes pour chaque table, types de colonnes pour chaque table, vérification de la valeur nulle ou non. Vérifiez la clé et les index de chaque table: clé primaire pour chaque table, clés étrangères pour chaque table.
Types de données entre une colonne de clé étrangère et une colonne dans d'autres indices de table, clusterisés ou non clusterisés uniques ou non uniques.
Test fonctionnel de base de données
Scénarios de test de base de données courants en ce qui concerne Functional Database Testing sont -
Découvrir le schéma, les déclencheurs et les procédures stockées responsables de la mise en œuvre de cette fonction et de les transformer en un groupe fonctionnel, puis chaque groupe peut être testé ensemble.
Vérifiez le flux de données et voyez où vous pouvez vérifier les données. Commencez par le front-end.
Test de base de données non fonctionnel
Scénarios de test de base de données courants en ce qui concerne Non-Functional Database Testing sont -
Écrivez des scripts de test pour essayer les fonctions principales et chaque fonction doit être vérifiée au moins une fois dans un cycle complet.
Exécutez les scripts de test encore et encore pendant une période de temps spécifique.
Vérification des fichiers journaux pour vérifier tout blocage, panne de mémoire, corruption de données, etc.
Écrivez des requêtes à partir d'un frontal et lancez les recherches. Récupérez un enregistrement existant, modifiez les valeurs de certains champs et sauvegardez l'enregistrement. (Cela implique une instruction UPDATE ou des procédures stockées de mise à jour, des déclencheurs de mise à jour.)
Insérez un nouvel élément de menu dans une fenêtre frontale. Remplissez les informations et enregistrez l'enregistrement. (Cela implique des instructions INSERT ou des procédures stockées d'insertion, des déclencheurs de suppression.)
Prenez un enregistrement existant, cliquez sur le bouton SUPPRIMER ou SUPPRIMER et confirmez la suppression. (Cela implique une instruction DELETE ou des procédures stockées de suppression, des déclencheurs de suppression.)
Répétez ces cas de test avec des données non valides et voyez comment la base de données répond.
Schemas, tables, stored procedures, et Triggerssont des objets clés d'une base de données. Nous avons déjà partagé des types de test de base de données et des scénarios de test pour ces objets de base de données.
Schémas
Un schéma de base de données définit la structure d'un système de base de données dans un format pris en charge par le système de gestion de base de données. Un schéma fait référence à la manière dont une base de données est structurée (composée de tables de base de données dans le cas des bases de données relationnelles).
Le schéma de base de données est un ensemble de formules appelées contraintes d'intégrité imposées à une base de données. Ces contraintes d'intégrité garantissent la compatibilité entre les parties du schéma.
Dans une base de données relationnelle, le schéma se compose de tables, champs, vues, index, packages, procédures, fonctions, déclencheurs, types, vues matérialisées, synonymes, liens de base de données et autres éléments.
Les schémas sont généralement stockés dans un dictionnaire de données. Bien qu'un schéma soit défini dans un langage de base de données texte, le terme est souvent utilisé pour désigner une représentation graphique de la structure de la base de données. En d'autres termes, le schéma est la structure de la base de données qui définit les objets de la base de données.
Les types courants de schémas utilisés dans un entrepôt de données sont:
- Schéma en étoile
- Schéma de flocons de neige
- Schéma de la galaxie
Tables dans la base de données
Dans une base de données relationnelle, une table est utilisée pour organiser les informations en lignes et en colonnes.
Example - Une table Client contient des informations telles que l'identifiant client, les adresses, les numéros de téléphone, etc. sous la forme d'une série de colonnes.
Chaque élément de données est un champ dans le tableau. Une colonne comprend toutes les entrées dans un seul champ, comme les numéros de téléphone de tous les clients. Les champs sont organisés sous forme d'enregistrements, qui sont des ensembles complets d'informations (tels que l'ensemble d'informations sur un client particulier), dont chacun comprend une ligne.
Procédures stockées
Une procédure stockée est une série d'instructions SQL stockées dans la base de données sous une forme compilée et plusieurs programmes peuvent la partager. L'utilisation de procédures stockées peut être utile pour maintenir l'intégrité des données, contrôler l'accès aux données et améliorer la productivité.
Déclencheurs
Un déclencheur de base de données est un code exécuté en réponse à certains événements sur une table ou une vue particulière dans une base de données. Le déclencheur est principalement utilisé pour maintenir l'intégrité des informations de la base de données.
L'intégrité des données est importante dans une base de données. Il inclut la validation des données avant l'insertion, les mises à jour et la suppression. Des déclencheurs doivent être en place pour valider les enregistrements de la table de référence.
Pour vérifier l'intégrité des données, vous devez effectuer les opérations suivantes -
Vous devez vérifier les principales colonnes de chaque table et vérifier s'il existe des données incorrectes. (Caractères dans le champ de nom, pourcentage négatif, etc.)
Découvrez les données incohérentes et insérez-les dans les tableaux appropriés et voyez si un échec se produit.
Insérez une donnée enfant avant d'insérer les données de son parent. Essayez de supprimer un enregistrement qui est toujours référencé par les données dans une autre table.
Si une donnée d'une table est mise à jour, vérifiez si les autres données pertinentes sont également mises à jour. Vous devez vous assurer que les serveurs ou bases de données répliqués sont synchronisés et contiennent des informations cohérentes.
Le mappage des données dans une base de données est l'un des concepts clés qui doit être validé par chaque testeur. Habituellement, les testeurs doivent vérifier le mappage du champ frontal de l'interface utilisateur avec le champ de base de données principal correspondant.
Ces informations sont fournies dans le document SRS / BRS de spécification d'exigence logicielle ou de spécification d'exigence métier. Si le mappage n'est pas fourni, vous devez vérifier la partie de codage.
Lorsque vous effectuez une action dans l'application frontale, une action CRUD correspondante est invoquée, et le testeur doit vérifier que chaque action appelée a réussi ou non.
Aspects clés de la cartographie des données
Vous trouverez ci-dessous les principaux aspects de la cartographie des données -
Pour vérifier les champs dans les formulaires UI / Front end et mappés de manière cohérente avec la table DB correspondante. Ces informations de mappage sont définies dans les documents d'exigences mentionnés ci-dessus.
Pour toute action effectuée dans le front-end d'une application, une action CRUD correspondante «Créer, récupérer, mettre à jour et supprimer» est lancée au back-end.
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.
Étapes des tests de mappage de données
Vous trouverez ci-dessous les étapes suivies pour les tests de mappage de données -
Step 1 - Vérifiez d'abord les erreurs de syntaxe dans chaque script.
Step 2 - Ensuite, vérifiez le mappage de table, le mappage de colonne et le mappage de type de données.
Step 3 - Vérifiez le mappage des données de recherche.
Step 4 - Exécutez chaque script lorsque les enregistrements n'existent pas dans les tables de destination.
Step 5 - Exécutez chaque script lorsque les enregistrements existent déjà dans les tables de destination.
Une application avec un temps de réponse plus long et des performances médiocres peut entraîner d'énormes problèmes. Le test de charge de base de données est utilisé pour rechercher les problèmes de performances avant de déployer vos applications de base de données pour les utilisateurs finaux.
Les tests de charge de base de données vous aident à concevoir une application de base de données pour les performances, la fiabilité et l'évolutivité. Le test de charge des applications de base de données consiste à tester les performances et l'évolutivité de votre application de base de données avec une charge utilisateur variable.
Les tests de charge de base de données impliquent la simulation de la charge utilisateur réelle pour l'application de base de données cible. Il vous aide à déterminer comment votre application de base de données se comporte lorsque plusieurs utilisateurs la touchent simultanément.
Test de charge
L'objectif principal du test de charge est de vérifier si la plupart des transactions en cours d'exécution ont un impact sur les performances de la base de données. Lors des tests de charge, vous devez vérifier les aspects suivants -
Le temps de réponse pour l'exécution des transactions pour plusieurs utilisateurs distants doit être vérifié.
Avec les transactions normales, vous devez inclure une transaction modifiable pour vérifier les performances de la base de données pour ces transactions de type pf.
Avec les transactions normales, vous devez inclure une transaction sans modification pour vérifier les performances de la base de données pour ce type de transactions.
Le temps nécessaire à la base de données pour récupérer des enregistrements spécifiques doit être vérifié.
Test de stress
Des tests de résistance sont effectués pour identifier le système breakpoint. Ici, l'application est chargée de telle manière que le système échoue à un moment donné. Ce point est appelé le point d'arrêt du système de base de données. Les tests de résistance sont également connus sous le nom deFatigue Testing.
La détermination de l'état des transactions de base de données implique un effort considérable. Une planification appropriée est nécessaire pour éviter tout problème lié au temps et aux coûts.
Les outils de test de résistance les plus courants sont LoadRunner et WinRunner.
Il existe divers outils fournis par les fournisseurs qui peuvent être utilisés pour générer des données de test, pour gérer les données de test et effectuer des tests de base de données tels que les tests de charge et les tests de régression.
Quelques outils courants utilisés sont donnés ci-dessous.
Sr.Non | Description de la catégorie | Exemples |
---|---|---|
1 | Load Testing Tools Ces outils sont utilisés pour mettre des charges d'utilisation élevées sur votre base de données, ce qui permet de déterminer si le paysage de votre système répondra aux besoins de votre entreprise. |
Performances Web Vue Rad Mercure |
2 | Data Security Tools Ces outils sont utilisés pour mettre en œuvre la conformité et les normes conformément aux réglementations de sécurité de l'information. |
Confidentialité des données IBM Optim |
3 | Test Data generator tools Un testeur utilise ces outils pour générer les données de test pour un système de base de données. Ceux-ci sont principalement nécessaires lorsque vous avez une énorme quantité de données et que vous avez besoin d'un échantillon pour effectuer des tests de base de données. Il est couramment utilisé pour les tests de charge et de contrainte. |
Usine de données Générateur de données DTM Données Turbo |
4 | Test Data Management Tool Ces outils sont utilisés pour maintenir le contrôle de version des données de test. Vous devez définir les résultats attendus, puis les comparer avec les résultats réels des tests. |
Gestion des données de test IBM Optim |
5 | Tools to perform Unit Testing Ces outils sont utilisés pour effectuer des tests de régression sur votre base de données. |
SQLUnit TSQLUnit DBFit DBUnit |
La partie la plus importante d'une croissance organisationnelle est ses données. En cas de panne du système, il est nécessaire de restaurer les données. La sauvegarde est une copie exacte de la base de données, qui vous aide à restaurer vos données en cas de perte de données.
Prenons l'exemple d'une société de financement qui dispose de données relatives à ses clients, telles que le numéro de climatisation, les noms des clients, le crédit et les débits, la durée, etc.
C'est la raison pour laquelle vous sauvegardez les données afin qu'en cas de panne d'un disque, d'un contrôleur de disque, etc., vous puissiez compter sur la sauvegarde pour les restaurer dans la base de données.
Types de sauvegardes de données
Deux types de sauvegarde peuvent être utilisés -
Physical Backups - La sauvegarde physique comprend la reprise à l'aide d'outils de sauvegarde tiers tels que Veritas Net Back, IBM Tivoli Manager ou les sauvegardes du gestionnaire d'utilisateurs à l'aide des utilitaires du système d'exploitation.
Logical Backups - La sauvegarde logique de la base de données comprend la réalisation de sauvegardes d'objets logiques tels que des tables, des index, des procédures, etc.
Example - L'un des outils courants pour effectuer la sauvegarde des données est Oracle Recovery Manager (RMAN) c'est un utilitaire Oracle pour effectuer une sauvegarde de la base de données.
RMAN se compose de deux composants -
Target database pour lequel une sauvegarde est requise.
RMAN Le client est utilisé pour exécuter des commandes pour effectuer une sauvegarde des données.
BACKUP VALIDATEest utilisé pour tester si vous pouvez effectuer une sauvegarde valide des fichiers de base de données. Il assure -
- Si une sauvegarde est en place pour les objets physiques ou logiques de la base de données.
- Si des sauvegardes régulières sont mises en place pour des données inestimables.
- Si l'outil de sauvegarde répond aux exigences de sauvegarde d'une organisation.
Database recovery testingest utilisé pour garantir que la base de données est restaurée. Les tests de récupération vous permettent de savoir si l'application fonctionne correctement et de vérifier la récupération de données inestimables qui auraient été perdues si votre méthode de récupération n'était pas correctement configurée.
Vous vérifiez également si plusieurs processus critiques fonctionnent correctement pour vous assurer que la récupération des données passera sans heurts à travers la phase de test.
Vous pouvez effectuer les vérifications suivantes pour la récupération de la base de données -
Toute erreur ou erreur dans le logiciel de sauvegarde et vous devez résoudre ces problèmes à un stade plus précoce.
Vous devez effectuer les tests de récupération afin de savoir quoi faire en cas de situation d'urgence.
Vous devez vérifier les besoins de test de récupération afin de pouvoir planifier une stratégie de récupération efficace.
Vous devez également savoir comment récupérer les documents.
Vous devez exécuter les tests de récupération au début du projet. Cela vous permet de supprimer et d'éliminer tous les types d'erreurs du système. Voici une liste de quelques points importants, qui devraient être pris en compte au moment du test -
Durée pendant laquelle des changements ou des modifications se produisent dans le système de base de données.
La période pendant laquelle vous souhaitez que votre plan de récupération soit mené.
La sensibilité des données dans le système de base de données. Plus les données sont critiques, plus vous devrez tester le logiciel régulièrement.
Étapes courantes des tests de sauvegarde et de restauration de base de données
Dans les tests de récupération de base de données, vous devez exécuter le test dans l'environnement réel pour vérifier si le système ou les données peuvent réellement être récupérés en cas de sinistre et de tout autre événement imprévu dans l'environnement commercial.
Vous trouverez ci-dessous les actions courantes effectuées dans les tests de récupération de base de données -
- Test du système de base de données
- Test des fichiers SQL
- Test de fichiers partiels
- Test de la sauvegarde des données
- Test de l'outil de sauvegarde
- Test des sauvegardes de journaux
Les tests de sécurité de la base de données sont effectués pour trouver les failles dans les mécanismes de sécurité et également pour trouver les vulnérabilités ou les faiblesses du système de base de données.
L'objectif principal des tests de sécurité des bases de données est de découvrir les vulnérabilités d'un système et de déterminer si ses données et ses ressources sont protégées contre les intrus potentiels. Les tests de sécurité définissent un moyen d'identifier efficacement les vulnérabilités potentielles, lorsqu'ils sont effectués régulièrement.
Vous trouverez ci-dessous les principaux objectifs de la réalisation de tests de sécurité de base de données -
- Authentication
- Authorization
- Confidentiality
- Availability
- Integrity
- Resilience
Types de menaces sur un système de base de données
Injection SQL
Il s'agit du type d'attaque le plus courant dans un système de base de données où des instructions SQL malveillantes sont insérées dans le système de base de données et sont exécutées pour obtenir des informations critiques du système de base de données. Cette attaque tire parti des failles dans la mise en œuvre des applications utilisateur. Pour éviter cela, les champs de saisie utilisateur doivent être traités avec soin.
Élévation des privilèges dans la base de données
Dans cette attaque, un utilisateur a déjà un certain accès dans le système de base de données et il essaie seulement d'élever ce niveau d'accès plus élevé afin qu'il / elle puisse effectuer certaines activités non autorisées dans le système de base de données.
Déni de service
Dans ce type d'attaque, un attaquant rend un système de base de données ou une ressource d'application indisponible pour ses utilisateurs légitimes. Les applications peuvent également être attaquées de manière à rendre l'application, et parfois la machine entière, inutilisable.
Accès non autorisé aux données
Un autre type d'attaque consiste à obtenir un accès non autorisé aux données d'une application ou d'un système de base de données. L'accès non autorisé comprend -
- Accès non autorisé aux données via des applications basées sur l'utilisateur
- Accès non autorisé à en surveillant l'accès des autres
- Accès non autorisé aux informations d'authentification client réutilisables
Usurpation d'identité
Dans l'usurpation d'identité, un pirate utilise les informations d'identification d'un utilisateur ou d'un appareil pour lancer des attaques contre les hôtes du réseau, voler des données ou contourner les contrôles d'accès au système de base de données. La prévention de cette attaque nécessite une infrastructure informatique et des atténuations au niveau du réseau.
Manipulation de données
Lors d'une attaque de manipulation de données, un pirate informatique modifie les données pour obtenir un avantage ou pour endommager l'image des propriétaires de bases de données.
Techniques de test de sécurité de base de données
Tests de pénétration
Un test d'intrusion est une attaque contre un système informatique dans le but de trouver des failles de sécurité et d'accéder potentiellement à celui-ci, à ses fonctionnalités et à ses données.
Recherche de risques
La recherche de risque est un processus d'évaluation et de décision sur le risque associé au type de perte et à la possibilité d'occurrence de la vulnérabilité. Ceci est déterminé au sein de l'organisation par divers entretiens, discussions et analyses.
Test d'injection SQL
Il s'agit de vérifier les entrées utilisateur dans les champs d'application. Par exemple, entrer un caractère spécial comme "," ou ";" dans toute zone de texte d'une application utilisateur ne doit pas être autorisé. Lorsqu'une erreur de base de données se produit, cela signifie que l'entrée utilisateur est insérée dans une requête, qui est ensuite exécutée par l'application. Dans un tel cas, l'application est vulnérable à l'injection SQL.
Ces attaques constituent une menace importante pour les données car les attaquants peuvent accéder à des informations importantes à partir de la base de données du serveur. Pour vérifier les points d'entrée d'injection SQL dans votre application Web, recherchez le code de votre base de code où des requêtes MySQL directes sont exécutées sur la base de données en acceptant certaines entrées utilisateur.
Les tests d'injection SQL peuvent être effectués pour les crochets, les virgules et les guillemets.
Cracking de mot de passe
Il s'agit de la vérification la plus importante lors du test du système de base de données. Pour accéder aux informations critiques, les pirates peuvent utiliser un outil de craquage de mot de passe ou peuvent deviner un nom d'utilisateur / mot de passe commun. Ces mots de passe courants sont facilement disponibles sur Internet et des outils de craquage de mots de passe existent également librement.
Par conséquent, il est nécessaire de vérifier au moment du test si la politique de mot de passe est maintenue dans le système. Dans le cas des applications bancaires et financières, il est nécessaire de définir une politique de mot de passe stricte sur tous les systèmes de bases de données d'informations critiques.
Audit de sécurité du système de base de données
Un audit de sécurité est un processus d'évaluation des politiques de sécurité de l'entreprise à un intervalle de temps régulier pour déterminer si les normes nécessaires sont respectées ou non. Diverses normes de sécurité peuvent être suivies selon les exigences de l'entreprise pour définir la politique de sécurité, puis l'évaluation des politiques définies par rapport à ces normes peut être effectuée.
Les exemples de normes de sécurité les plus courantes sont ISO 27001, BS15999, etc.
Outils de test de sécurité de base de données
Il existe divers outils de test système disponibles sur le marché, qui peuvent être utilisés pour tester le système d'exploitation et la vérification des applications. Certains des outils les plus courants sont présentés ci-dessous.
Proxy d'attaque Zed
Il s'agit d'un outil de test de pénétration permettant de trouver des vulnérabilités dans les applications Web. Il est conçu pour être utilisé par des personnes ayant une vaste expérience en matière de sécurité et, en tant que tel, est idéal pour les développeurs et les testeurs fonctionnels qui sont nouveaux dans les tests d'intrusion. Il est couramment utilisé pour Windows, Linux, Mac OS.
Paros
Toutes les données HTTP et HTTPS entre le serveur et le client, y compris les cookies et les champs de formulaire, peuvent être interceptées et modifiées à l'aide de ces scanners. Il est utilisé pour Cross-platform, Java JRE / JDK 1.4.2 ou supérieur.
Boîte à outils de l'ingénieur social
C'est un outil open source et les éléments humains sont attaqués plutôt que l'élément système. Il vous permet d'envoyer des e-mails, des applets java, etc. contenant le code d'attaque. Il est préférable pour Linux, Apple Mac OS X et Microsoft Windows.
Skipfish
Cet outil est utilisé pour analyser leurs sites à la recherche de vulnérabilités. Les rapports générés par l'outil sont destinés à servir de base aux évaluations professionnelles de la sécurité des applications Web. Il est préférable pour Linux, FreeBSD, MacOS X et Windows.
Vega
Il s'agit d'un outil de sécurité Web multiplateforme open source utilisé pour rechercher des instances d'injection SQL, de scripts intersites (XSS) et d'autres vulnérabilités dans les applications Web. Il est préférable pour Java, Linux et Windows.
Wapiti
Wapiti est un outil open source basé sur le Web qui analyse les pages Web de l'application Web et vérifie les scripts et les formulaires dans lesquels il peut injecter des données. Il est construit avec Python et peut détecter les erreurs de gestion de fichiers, les injections de base de données, XSS, LDAP et CRLF, la détection d'exécution de commande.
Scarabée Web
Il est écrit en Java et est utilisé pour analyser les applications qui communiquent via les protocoles HTTP / HTTPS. Cet outil est principalement conçu pour les développeurs qui peuvent écrire eux-mêmes du code. Cet outil ne dépend pas du système d'exploitation.
Pour effectuer des tests de base de données avec succès, un testeur doit collecter les exigences de toutes les sources, telles que les exigences techniques et fonctionnelles. Il est possible que quelques exigences soient à un niveau élevé, il est donc nécessaire de répartir ces exigences en petites parties. Le test de la base de données est une tâche complexe et les testeurs sont confrontés à de nombreux défis lors de l'exécution de ces tests. Les défis les plus courants pour les tests de bases de données sont:
La portée du test est trop grande
Un testeur doit identifier les éléments de test dans les tests de base de données, sinon il pourrait ne pas avoir une compréhension claire de ce qu'il testerait et de ce qu'il ne testerait pas. Par conséquent, si vous êtes clair sur l'exigence, vous risquez de perdre beaucoup de temps à tester des objets non critiques dans la base de données.
Lorsque vous avez une liste d'objets à tester, il faut ensuite estimer l'effort requis pour concevoir les tests et exécuter les tests pour chaque élément de test. En fonction de leur conception et de la taille des données, certains tests de base de données peuvent prendre du temps à s'exécuter.
Comme la taille de la base de données est trop grande, il devient difficile de trouver les objets à tester et ceux qui doivent être laissés de côté.
Base de données de test réduite
Normalement, les testeurs reçoivent une copie de la base de données de développement à tester. Cette base de données ne contient que peu de données, ce qui est suffisant pour exécuter l'application. Il est donc nécessaire de tester le système de base de données de développement, de préparation et de production.
Changements dans la structure de la base de données
C'est l'un des défis courants des tests DB. Parfois, il arrive que vous conceviez ou exécutiez un test et que la structure de la base de données ait été modifiée à ce moment-là. Ceci est nécessaire pour que vous soyez conscient des modifications apportées à la base de données pendant le test.
Une fois la structure de la base de données modifiée, vous devez analyser l'impact des modifications et modifier les tests. En outre, si plusieurs utilisateurs utilisent la base de données de test, vous ne serez pas sûr des résultats du test, vous devez donc vous assurer que la base de données de test est utilisée à des fins de test uniquement.
Un autre défi dans les tests DB est que vous exécutez plusieurs tests en même temps. Vous devez exécuter un test à la fois au moins pour les tests de performances. Vous ne voulez pas que votre base de données effectue plusieurs tâches et sous-estime les performances.
Plans de test complexes
La structure de la base de données est normalement complexe et contient d'énormes données, il est donc possible que vous exécutiez des tests incomplets ou identiques à plusieurs reprises. Il est donc nécessaire de créer un plan de test et de procéder en conséquence et de vérifier régulièrement les progrès.
Bonne compréhension de SQL
Pour tester une base de données, vous devez avoir une bonne connaissance des requêtes SQL et des outils de gestion de base de données requis.
Les tests de base de données comprennent l'exécution de la validité des données, les tests d'intégrité des données, le contrôle des performances liées à la base de données et le test des procédures, des déclencheurs et des fonctions de la base de données.
Il existe plusieurs raisons pour lesquelles les tests de base de données sont effectués. Il est nécessaire d'effectuer une vérification de l'intégrité, de la validation et de la cohérence des données sur la base de données, car le système backend est chargé de stocker les données et est accessible à des fins multiples.
Certaines des raisons courantes pour lesquelles il faut effectuer des tests de base de données sont les suivantes:
Pour alléger la complexité des appels au backend de base de données, les développeurs augmentent l'utilisation de View et Stored Procédures.
Celles-ci Stored procédures et Viewscontiennent des tâches critiques telles que l'insertion des détails du client (nom, coordonnées, etc.) et des données de vente. Ces tâches doivent être testées à plusieurs niveaux.
Le test de la boîte noire effectué sur le front-end est important, mais il est difficile d'isoler le problème. Les tests au niveau du système backend augmentent la robustesse des données. C'est pourquoi les tests de base de données sont effectués sur le système principal.
Dans une base de données, les données proviennent de plusieurs applications et il est possible que des données nuisibles ou incorrectes soient stockées dans la base de données. Par conséquent, il est nécessaire de vérifier régulièrement les composants de la base de données. En outre, l'intégrité et la cohérence des données doivent être vérifiées régulièrement.
Les étapes à suivre lors du test de la base de données sont les suivantes:
- Les données contenues dans la base de données doivent être vérifiées.
- Vérifiez si les contraintes sont maintenues.
- La performance des procédures et l'exécution des déclencheurs doivent être vérifiées.
- L'annulation et la validation de la transaction doivent être vérifiées.
Sur la base de la fonction et de la structure d'une base de données, les tests DB peuvent être classés dans les catégories suivantes -
Structural Database testing - Il traite du test des tables et des colonnes, des tests de schéma, des procédures stockées et des tests de vues, de la vérification des déclencheurs, etc.
Functional Testing- Il s'agit de vérifier la fonctionnalité de la base de données du point de vue de l'utilisateur. Les tests fonctionnels les plus courants sont les tests en boîte blanche et en boîte noire.
Nonfunctional Testing - Cela implique des tests de charge, des tests de risque dans la base de données, des tests de résistance, une exigence minimale du système et traite des performances de la base de données.
Les outils les plus courants utilisés pour effectuer des tests de procédures stockées sont LINQ, SP Test tool, etc.
Les jointures sont utilisées pour connecter deux ou plusieurs tables d'une manière logique. Les types courants de jointures incluent: jointure interne, jointure non équidistante, jointure externe, jointure automatique et jointure croisée.
Vous pouvez joindre une seule table à elle-même. Dans ce cas, vous utilisez la même table deux fois.
Step 1 - Connectez-vous à la base de données
db_connect(query1 DRIVER {drivername};SERVER server_name;UID uidname;
PWD password;DBQ database_name );
Step 2 - Exécuter la requête de la base de données -
db_excecute_query (write the required query that is to execute); Specify the appropriate condition
Step 3 - Déconnectez la connexion à la base de données en utilisant
db_disconnect(query);
À l'aide des points de contrôle de la base de données de sortie, les options de requêtes manuelles SQL doivent être sélectionnées. Ici, la requête de sélection peut être écrite.
Tout d'abord, vérifiez l'exigence de la procédure stockée. L'étape suivante consiste à vérifier si les index, jointures, suppressions, mises à jour sont corrects par rapport aux tables mentionnées dans la procédure stockée.
Ensuite, effectuez les tâches suivantes -
Validez le nom de la procédure d'appel, les paramètres d'appel et les réponses attendues pour différents ensembles de paramètres d'entrée.
Exécutez la procédure avec TOAD ou MySQL ou l'Analyseur de requêtes.
Réexécutez les procédures disponibles en envoyant différents paramètres et comparez les résultats aux valeurs attendues.
En conclusion du processus, automatisez les tests avec WinRunner.
Le testeur doit appeler la procédure stockée dans la base de données à l'aide de la commande EXEC. Si des paramètres sont requis, ils doivent être passés. Différentes valeurs de paramètres doivent être transmises pour confirmer si la procédure stockée est exécutée ou non. Lors de l'appel de cette commande, il doit vérifier et vérifier la nature et le comportement de la base de données.
Example - Si la procédure stockée est écrite pour remplir une table, les valeurs de la table doivent être vérifiées.
Nous avons trois types d'instructions SQL -
- Langage de manipulation de données (DML)
- Langage de définition de données (DDL)
- Langage de contrôle des données (DCL)
Les instructions DDL sont utilisées pour définir la structure ou le schéma de la base de données. Quelques exemples -
CREATE - pour créer des objets dans la base de données
ALTER - modifie la structure de la base de données
DROP - supprimer des objets de la base de données
Les opérateurs sont utilisés pour spécifier des conditions dans une instruction SQL et pour servir de conjonctions pour plusieurs conditions dans une instruction.
- Opérateurs arithmétiques
- Comparaison / Opérateurs relationnels
- Opérateurs logiques
- Définir les opérateurs
- Opérateurs utilisés pour annuler les conditions
Union est utilisée pour combiner les résultats de deux ou plusieurs instructions Select. Cependant, cela éliminera les lignes en double. Union est un opérateur fixe.
Unionest utilisé pour combiner les résultats de deux ou plusieurs instructions Select. Cependant, cela éliminera les lignes en double
Union All L'opération est similaire à Union, mais elle montre également les lignes en double.
Les déclencheurs sont utilisés pour maintenir l'intégrité de la base de données. Pour vérifier que le déclencheur est déclenché ou non, vous pouvez archiver les journaux d'audit.
Les déclencheurs ne peuvent pas être appelés à la demande. Ils sont invoqués lorsqu'une action associée (insertion, suppression et mise à jour) se produit sur la table sur laquelle ils sont définis. Les déclencheurs sont utilisés pour appliquer les règles métier, l'audit et également pour les contrôles d'intégrité référentielle.
Tout d'abord, obtenez l'exigence fonctionnelle. Ensuite, comprenez la structure de la table, les jointures, les curseurs et les déclencheurs, la procédure stockée utilisée et d'autres paramètres. Ensuite, vous pouvez écrire un cas de test avec des valeurs différentes comme entrée pour ces objets.
Les tests DB impliquent le test des composants back-end qui ne sont pas visibles par les utilisateurs. Il comprend des composants de base de données et des systèmes de SGBD tels que MySQL et Oracle.
Les tests frontaux consistent à vérifier les fonctionnalités d'une application et de ses composants tels que des formulaires, des graphiques, des menus, des rapports, etc. Ces composants sont créés à l'aide d'outils de développement frontaux tels que VB.net, C #, Delphi, etc.
Le processus de test de la base de données est similaire au test d'autres applications. Les tests DB peuvent être décrits avec les processus clés suivants -
- Mise en place de l'environnement
- Lancer un test
- Vérifiez le résultat du test
- Valider selon les résultats attendus
- Rapporter les résultats aux parties prenantes respectives
Diverses instructions SQL sont utilisées pour développer les cas de test. L'instruction SQL la plus courante utilisée pour effectuer des tests de base de données est l'instruction select. En dehors de ces diverses instructions DDL, DML, DCL peuvent également être utilisées.
Example - Créer, insérer, sélectionner, mettre à jour, etc.
Une vue est une table qui n'existe pas vraiment en soi, mais qui est à la place dérivée d'une ou plusieurs tables de base. En d'autres termes, il n'y a pas de fichier stocké qui représente directement la vue au lieu d'une définition de vue est stockée dans le dictionnaire de données.
La croissance et la restructuration des tables de base ne se reflètent pas dans les vues. Ainsi, la vue peut isoler les utilisateurs des modifications de la base de données. Par conséquent, tient compte de l'indépendance logique des données.
Il spécifie les vues utilisateur et leurs mappages avec le schéma conceptuel.
C'est un processus de décomposition d'une table en plusieurs tables sans perdre aucune information. La normalisation est effectuée pour atteindre les objectifs suivants -
- Pour minimiser la redondance.
- Pour minimiser les anomalies d'insertion, de suppression et de mise à jour.
L'indexation est une technique permettant de déterminer la rapidité avec laquelle des données spécifiques peuvent être trouvées. Il est utilisé pour l'optimisation des performances des requêtes. L'indexation peut être des types suivants -
- Indexation du style de recherche binaire
- Indexation B-Tree
- Indexation de liste inversée
- Table résidente en mémoire
- Indexation de table
SQL est un langage de requête structurée spécialement conçu pour les opérations d'accès aux données sur des structures de base de données relationnelles normalisées.
La principale différence entre SQL et les autres langages de programmation conventionnels est que les instructions SQL spécifient quelles opérations sur les données doivent être effectuées plutôt que comment les exécuter.
Les procédures stockées sont utilisées pour effectuer une opération définie par l'utilisateur. Une procédure stockée peut avoir un ensemble d'instructions SQL composées. Une procédure stockée exécute les commandes SQL et renvoie le résultat au client.
PL / SQL utilise des curseurs pour toutes les instructions d'accès aux informations de base de données. Le langage prend en charge l'utilisation de deux types de curseurs - implicites et explicites.
Cold Backup- Le retour à froid est connu comme la sauvegarde des fichiers de base de données, des journaux de rétablissement et du fichier de contrôle lorsque l'instance est arrêtée. Il s'agit d'une copie de fichier, généralement du disque directement sur bande. Vous devez arrêter l'instance pour garantir une copie cohérente.
Si une sauvegarde à froid est effectuée, la seule option disponible en cas de perte de fichiers de données est de restaurer tous les fichiers de la dernière sauvegarde. Toutes les modifications effectuées après la dernière sauvegarde sont perdues.
Hot Backup- Certaines bases de données ne peuvent pas s'arrêter lors de la création d'une copie de sauvegarde des fichiers, la sauvegarde à froid n'est donc pas une option disponible. Pour ces types de bases de données, nous utilisons une sauvegarde à chaud.
La sous-requête SQL est un moyen d'interroger deux ou plusieurs tables en même temps. La sous-requête elle-même est une instruction SQL SELECT contenue dans la clause WHERE d'une autre instruction SQL SELECT et séparée en étant placée entre parenthèses. Certaines sous-requêtes ont des structures de jointure SQL équivalentes, mais les sous-requêtes corrélées ne peuvent pas être dupliquées par une jointure
Dans un tel cas, vous devez tester les aspects suivants -
- Dépendances à valeurs multiples
- Dépendances fonctionnelles
- Clés des candidats
- Clés primaires
- Clés étrangères
Vous pouvez accéder à la base de données et exécuter une requête SQL appropriée. Dans WinRunner, vous pouvez utiliser la fonction de point de contrôle de base de données. Si l'application fournit une fonction d'affichage, vous pouvez vérifier la même chose depuis le front-end.
Les tests basés sur les données sont définis comme un processus de test d'automatisation où l'application sera testée avec plusieurs données de test. C'est simple et facile que de retester où le testeur est juste assis devant le système et entre différentes nouvelles valeurs d'entrée manuellement à partir de l'interface frontale.
Une fois que vous exécutez les cas de test et trouvez les défauts qui ont déjà été détectés et corrigés. La ré-exécution du même test avec des valeurs d'entrée différentes pour confirmer que le défaut d'origine a été supprimé avec succès est appelée nouveau test.
Le nouveau test est également appelé test basé sur les données avec une petite différence -
Retesting - Il s'agit d'un processus de test manuel tandis que les tests d'application sont effectués avec un nouvel ensemble de données.
Data-driven Testing- Il s'agit d'un processus de test d'automatisation où l'application sera testée avec plusieurs données de test. C'est simple et facile que de retester où le testeur est juste assis devant le système et entre différentes nouvelles valeurs d'entrée manuellement à partir de l'interface frontale.
Il existe quatre types de tests pilotés par les données:
- Soumission dynamique des données de test via le clavier
- Tests pilotés par les données via des fichiers plats .txt, .doc
- Tests pilotés par les données via des objets frontaux
- Tests pilotés par les données via feuille Excel
Le test de performance est une technique de test logiciel permettant de déterminer les performances d'un système en termes de vitesse, de sensibilité et de stabilité sous une lourde charge de travail.
Les points clés suivants doivent être pris en compte lors de l'exécution des tests de récupération de base de données -
Durée pendant laquelle des changements ou des modifications se produisent dans le système de base de données.
La période pendant laquelle vous souhaitez que votre plan de récupération soit mené.
La sensibilité des données dans le système de base de données. Plus les données sont critiques, plus vous devrez tester le logiciel régulièrement.
Les outils suivants sont utilisés pour générer des données de test -
- Usine de données
- Générateur de données DTM
- Données Turbo
Deux types de sauvegarde peuvent être utilisés -
Physical Backups- la sauvegarde physique comprend la prise de retour à l' aide de 3 rd outils de sauvegarde du parti comme le dos net Veritas, IBM Tivoli Manager ou les sauvegardes du gestionnaire d'utilisateur à l' aide des utilitaires OS.
Logical Backups - La sauvegarde logique de la base de données comprend la reprise des objets logiques comme les tables, les index, les procédures, etc.
Un outil courant pour effectuer la sauvegarde des données est Oracle Recovery Manager (RMAN), qui est un utilitaire Oracle permettant de sauvegarder la base de données.
Les actions suivantes sont effectuées lors des tests de récupération de base de données -
- Test du système de base de données
- Test des fichiers SQL
- Test de fichiers partiels
- Test de la sauvegarde des données
- Test de l'outil de sauvegarde
- Test des sauvegardes de journaux
Les tests de sécurité de la base de données sont effectués pour trouver les trous de boucle dans les mécanismes de sécurité et également pour trouver les vulnérabilités ou les faiblesses du système de base de données.
Des tests de sécurité de la base de données sont effectués pour vérifier les aspects suivants -
- Authentication
- Authorization
- Confidentiality
- Availability
- Integrity
- Resilience
La menace d'injection SQL est le type d'attaque le plus courant dans un système de base de données où des instructions SQL malveillantes sont insérées dans le système de base de données et exécutées pour obtenir des informations critiques du système de base de données. Cette attaque tire parti des failles dans la mise en œuvre des applications utilisateur. Pour éviter cela, les champs de saisie utilisateur doivent être traités avec soin.
Les outils suivants peuvent être utilisés pour effectuer des tests de sécurité de base de données: Zed Attack Proxy, Paros, Social Engineer Toolkit, Skipfish, Vega, Wapiti et Web Scarab.
Les défis communs auxquels on est confronté lors de l'exécution des tests de base de données sont les suivants:
- La portée du test est trop grande
- Base de données de test réduite
- Changements dans la structure de la base de données
- Plans de test complexes
- Bonne compréhension de SQL