Guide d’un QA pour les tests de bases de données en 2026

À lire aussi : LES RÉSULTATS POSITIFS DES TESTS NÉGATIFS

Qu’est-ce qu’un schéma de base de données ?

Un schéma de base de données est une structure logique qui définit l’organisation et la relation des données au sein d’une base de données. Il trace le plan directeur de la façon dont les données sont stockées, consultées et manipulées dans un SGBD. Le schéma décrit les types de données, les contraintes, et les relations entre les entités de la base, comme les tables, les vues, les index et les triggers.

Le schéma de base de données est essentiel pour garantir l’intégrité et la cohérence des données dans une base. Il offre aux développeurs et administrateurs de bases de données un cadre pour organiser et structurer les données de façon cohérente. Il contribue également à garantir que les données stockées dans la base répondent à des exigences spécifiques comme la validation, la sécurité et l’accessibilité des données. Les organisations peuvent utiliser un schéma de base de données pour garantir une organisation et une optimisation de leurs bases de données, permettant une gestion efficace des données et améliorant les opérations et la prise de décisions en entreprise.

Pourquoi les tests de base de données sont-ils importants ?

Les tests de base de données sont importants car

1.  Certains bugs ne peuvent être découverts qu’au travers de tests de base de données
2.  Certaines conditions d’utilisation ne peuvent être testées que côté base de données
3.  Les tests de base de données améliorent la stabilité et la sécurité 
4.  Les tests de base de données garantissent la cohérence

Exemple de fonction de base de données

Imaginez ouvrir une application de banque en ligne sur votre téléphone (ou ouvrez-la réellement). Maintenant, transférez une petite somme d’argent de votre compte courant vers votre compte d’épargne.  Une fois terminé, pensez à tout ce qui a dû se passer en quelques secondes en coulisse.

1. L’application a envoyé les informations de la transaction à la base de données.
2. Aucune de vos informations (c’est-à-dire votre ARGENT) n’a été perdue en cours de route.
3. L’application ne s’est pas bloquée et n’a pas échoué lors du transfert.
4. La transaction s’est déroulée de façon sécurisée.
5. Votre argent est maintenant en sécurité sur votre compte d’épargne (félicitations !)

Toutes ces fonctions s’effectuent au sein de la base de données. Le processus de test est important car si un système de base de données échoue de manière critique, tout le système se bloque. Il n’est plus possible d’envoyer, recevoir, transférer ou sécuriser des données. L’application peut sembler fonctionner superficiellement (vous pouvez naviguer dans les fenêtres et vous préparer à faire des transactions) mais rien d’impactant ne se produira.

Tout semble normal à l’extérieur, mais à l’intérieur c’est la catastrophe.

Les tests de base de données évitent toute catastrophe. Pas de feu, pas d’arrêt, pas d’argent manquant. Il est dans l’intérêt de tous d’effectuer ces tests. J’ai donc rédigé un guide complet pour vous aider à être sûr que tout aura été entièrement vérifié.

Principes des tests de base de données

Le mot « principes » peut sonner davantage comme « pourquoi » que « comment ». Croyez-moi, il s’agit de deux concepts importants et pratiques. 

1. Propriétés ACID
   • Atomicité
   • Cohérence
   • Isolation
   • Durabilité
2. Intégrité des données

Qu’est-ce que les propriétés ACID ?

C’est la version la plus sûre d’acide que vous utiliserez jamais. Pas besoin de gants ici, les propriétés ACID représentent l’Atomicité, la Cohérence, l’Isolation et la Durabilité. Chaque transaction dans les tests de base de données doit respecter ces principes. 

Une transaction est un groupe de tâches. Même une transaction réelle simple, comme le virement bancaire que j’ai mentionné précédemment, implique plusieurs tâches de plus bas niveau. Les propriétés ACID sont là pour confirmer que chaque transaction est menée à bien avec exactitude, intégralité et intégrité.

JOIN THE COMMUNITY

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

Sign up with LinkedIn

Or sign up with email:

Instagram

This field is for validation purposes and should be left unchanged.

Name*

First name Last name

Business email*

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

LinkedIn profile

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Company's AI adoption maturity*

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

Propriétés ACID

• L’atomicité stipule que chaque transaction doit être considérée comme une unité atomique. En termes non moléculaires, cela signifie que chaque transaction doit être réalisée en totalité ou alors elle échoue. Traiter chaque transaction de cette manière évite la situation délicate d’un virement d’argent seulement partiellement effectué. Rien que d’y penser, c’est stressant, n’est-ce pas ? Avec l’atomicité, si la transaction est interrompue à mi-parcours en cas de problème, l'ensemble de la transaction échoue. Argent remboursé. Pas de stress.
• La cohérence impose que la base de données reste cohérente après une transaction. Aucune transaction ne doit nuire à une autre donnée de la base. En déposant de l’argent sur votre compte bancaire, vous ne retirerez pas d’argent du compte de quelqu’un d’autre.
• L’isolement évite les croisements de flux. Il garantit que, lorsqu’il y a plusieurs transactions en même temps, chacune est traitée comme si elle était la seule dans la base de données. Personne ne mélange ses informations avec celles d’autrui.
• La durabilité exige que la base de données soit assez robuste pour conserver toutes les transactions les plus récentes, même en cas de panne du système. Là aussi, il y a des raisons pratiques à demander une telle durabilité à une base de données. Si vous effectuez un virement et que la base de données tombe en panne dix minutes plus tard, comment sauriez-vous qu’il faut refaire le virement ? Des exigences aussi strictes préviennent la confusion pour les utilisateurs finaux.

Intégrité des données

L’intégrité des données consiste à vérifier que toutes les données récentes sont mises à jour partout. Il existe quatre éléments distincts qui, ensemble, garantissent l’intégrité des données. Pour obtenir une grande intégrité des données, un testeur qualité doit vérifier que :

1. Les données sont vérifiables
2. Les données sont récupérables
3. Les données sont exactes
4. Les données sont complètes

Si les données ne remplissent pas ces quatre exigences, elles ne répondent probablement pas au standard de l’intégrité des données. Les outils de gestion de données peuvent vous aider à cet égard, mais il vous revient en dernier ressort de garantir la meilleure qualité de données.

Comme l’a souligné Huw Price dans l’épisode du podcast The QA Lead intitulé Your Data Quality Sucks, s’assurer que vos systèmes reposent sur des données fiables et sécurisées prend de plus en plus d’importance à mesure que de plus en plus d’entreprises accumulent leurs propres pools de données.

Langage de manipulation de base de données

Un langage de manipulation de base de données (DML) est un langage de programmation utilisé pour manipuler les données dans un système de gestion de base de données. Le DML sert principalement à effectuer des tâches telles que l’insertion, la mise à jour, la suppression et la récupération des données d’une base. En substance, le DML fournit tout un ensemble de commandes et de fonctions permettant aux utilisateurs d’interagir avec les données d’une base et de modifier ou récupérer celles-ci selon des critères spécifiques. Le DML est un composant essentiel de tout système de base de données, car il permet à l’utilisateur de travailler sur les données sans avoir à comprendre la structure ou la technologie sous-jacente à la base de données.

Les commandes du DML sont généralement utilisées conjointement avec le langage de définition de base de données (DDL), qui sert à créer et modifier les objets de base tels que les tables, vues et index. Le DDL et le DML constituent le cœur d’un système de gestion de base de données, offrant la possibilité de créer, modifier et manipuler les données de manière sécurisée, efficace et fiable. L’utilisation du DML au sein de la gestion de bases de données permet aux organisations de stocker, gérer et analyser de grands volumes de données, en faisant ainsi un outil crucial pour une entreprise à l’ère actuelle axée sur la donnée.

Types de tests de base de données

Maintenant que nous avons étudié deux principes essentiels des tests de bases de données, nous pouvons passer aux différents types de tests. Vous avez probablement déjà entendu parler de ces approches. Je l’ai dit plus tôt : si vous comprenez les tests QA, vous maîtriserez les tests de base de données sans souci. Je vais vous expliquer comment chacun de ces concepts s’applique aux tests de base de données.

Il existe trois types de tests de base de données :

1. Structurels
2. Fonctionnels
3. Non fonctionnels

Chacun de ces grands types de tests de base de données comporte des sous-catégories. Pas d’inquiétude, je vais vous les détailler aussi.

Tests structurels

Les tests structurels valident les éléments internes du référentiel de données utilisés pour le stockage des données. Ces éléments sont cachés aux utilisateurs finaux et opèrent entièrement en coulisses. Les testeurs de bases de données les vérifient en rédigeant des requêtes SQL.

Tests de cartographie des données

La cartographie des structures de données consiste à établir des connexions entre deux modèles de données différents. Appelé aussi test de schéma, le test de cartographie des données valide le front-end et le back-end. Il vérifie que les deux communiquent correctement.

Par exemple, si vous remplissez un formulaire d’inscription sur un site web, une cartographie des données correcte prendra le formulaire web et le transférera vers la base de données. Votre nom, votre e-mail et votre mot de passe seront stockés là où ils doivent l’être. Les tests de cartographie des données confirment que ce processus fonctionne. 

Il existe plusieurs outils de cartographie des données avec lesquels un testeur QA travaillera. Voici une liste succincte d’outils de cartographie des données :

• Oracle Data Integrator
• Microsoft SQL Server 
• IBM InfoSphere
• webMethods
• CloverDX

Test des tables de base de données

Le test des tables effectue plusieurs vérifications sur la structure de cartographie des données. Il vérifie que les champs du front-end et du back-end sont compatibles entre eux. Il valide la longueur des champs de la base de données. Et il confirme s’il existe des tables ou des colonnes de base de données non cartographiées auxquelles vous devez vous attaquer. 

Validations du serveur de base de données

Les validations du serveur s’assurent que la configuration du serveur répond aux exigences. Elles garantissent aussi que toute personne essayant d’accéder à certaines zones du serveur de base de données dispose des autorisations appropriées. C’est une étape importante pour assurer la sécurité de la base de données et de ses utilisateurs. Enfin, la validation du serveur vérifie que le serveur peut gérer le nombre maximal de transactions simultanées. 

Par exemple, une validation de serveur pour une application bancaire vérifierait que le serveur peut gérer les transactions financières d’un nombre donné d’utilisateurs et que chacun ne peut accéder qu’à ses propres informations. 

Tests fonctionnels

Nous allons rendre les tests fonctionnels amusants à nouveau. Vraiment, promis. Les tests fonctionnels consistent à vérifier que la base de données répond aux spécifications du client, et que les actions de l’utilisateur final sont cohérentes avec ces exigences. Cela signifie qu’il faut souvent se faire passer pour l’utilisateur final. N’est-ce pas amusant ? Personnellement, je trouve cela amusant. 

Test en boîte noire

Le test en boîte noire est une stratégie de test logiciel où le testeur ne connaît pas la conception du système logiciel testé. Sans une compréhension intime de la conception du logiciel, le testeur abordera l’application avec des attentes similaires à celles de l’utilisateur final. 

Les tests en boîte noire sont réalisés lors des tests de bases de données car ils permettent de détecter les bugs sur les parcours que l’utilisateur final est susceptible d’emprunter. C’est le test ultime du point de vue de l’utilisateur final. 

Nous avons traité le test en boîte noire en détail dans notre guide Les 9 types de tests logiciels que tout analyste QA doit connaître. 

Test en boîte blanche

Le test en boîte blanche est le parfait opposé du test en boîte noire. Lors d’un test en boîte blanche, le membre de l’équipe QA comprend parfaitement la structure interne et la conception du logiciel testé. 

Ils abordent le test comme des inspecteurs. Le test en boîte blanche est parfois aussi appelé test "boîte transparente" car le testeur observe les interactions entre les différentes unités pendant l’évaluation du logiciel. Contrairement au test en boîte noire, le testeur en boîte blanche se préoccupe beaucoup moins de l’expérience utilisateur. 

Test unitaire

Le test unitaire est une technique de test logiciel qui consiste à tester les unités ou composants individuels d’une application isolément du reste du système. Ce type de test permet de tester des objets de base de données individuels tels que les tables, les vues, les procédures stockées et les fonctions. En testant ces objets de manière isolée, les développeurs peuvent s’assurer que chaque objet fonctionne comme prévu.

Les tests unitaires pour bases de données consistent généralement à écrire des tests automatisés qui exécutent des commandes SQL spécifiques sur un objet ou module de base de données et vérifient que les résultats attendus sont retournés. Par exemple, un test unitaire pour une procédure stockée peut consister à passer un ensemble de paramètres d’entrée à la procédure et à vérifier que la sortie est correcte. Grâce à l’utilisation de tests unitaires de cette manière, les développeurs peuvent s’assurer que chaque objet de la base de données se comporte comme prévu et que toute modification du schéma ou du code applicatif ne crée pas de conséquence ou d’erreur non désirée.

Tests non fonctionnels

Les tests non fonctionnels ne s’intéressent pas à l’utilisateur final. Non pas que l’utilisateur final ne soit pas important, mais ils ont d’autres préoccupations. Les tests non fonctionnels évaluent la performance de la base de données sous charge, lors de pics de sollicitation, et cherchent des possibilités d’optimisation des performances.

Test de charge 

Le test de charge de base de données est un type de test de performance qui vérifie que la charge utilisateur n’aura pas d’impact négatif important sur les performances de la base de données. Le testeur QA exécute une série de requêtes de charge, répétées de nombreuses fois afin de simuler une base d’utilisateurs active. 

Test de résistance

Les tests de résistance sont des tests de charge, mais en plus poussé. Le but n’est pas de voir si la base de données ralentit, mais bien de déterminer jusqu’où elle peut casser. C’est beaucoup plus destructeur. Voilà, c’est amusant. 

Avez-vous déjà attendu avec impatience la sortie d’un nouveau jeu vidéo ou d’un téléphone ? Si oui, vous connaissez peut-être l’expérience de charger le site web ou d’ouvrir l’application pour faire votre achat et d’être accueilli par des temps de chargement anormalement longs, des codes d’erreur inattendus et l’incapacité à traiter vos informations. Voilà précisément une base de données sous pression.

Cela diffère des tests de charge car il s’agit de soumettre la base de données à un pic soudain et inattendu de trafic. 

Tests automatisés de base de données

Les tests automatisés de base de données sont devenus plus populaires ces dernières années. Obliger la base de données à être testée manuellement prendrait trop de temps, nécessiterait trop de personnes et coûterait tout simplement trop cher.

Il existe de nombreuses façons de réaliser des tests automatisés. Voici une liste de certains outils de gestion de bases de données qui proposent des fonctionnalités de test.

Liste des outils de gestion de bases de données

Tester une base de données avec une API

Une API (Interface de Programmation d’Applications) est un ensemble de protocoles et de normes permettant à différentes applications logicielles de communiquer entre elles. Pour le test de bases de données, une API peut se connecter à une base et réaliser diverses opérations telles qu’ajouter, mettre à jour, supprimer et récupérer des données.

La relation entre une API et le test de base de données est qu’une API peut être utilisée pour automatiser et rationaliser le processus de test. En utilisant une API pour se connecter à une base de données, les testeurs peuvent automatiser des tâches telles que l’insertion, la mise à jour et la suppression de données, ainsi qu’effectuer des requêtes pour récupérer et valider les résultats. Cela peut considérablement réduire le temps et l’effort nécessaires aux tests manuels et améliorer la précision et la cohérence des résultats des tests.

Ressources complémentaires

Après avoir lu cet article, vous devriez comprendre comment effectuer des tests sur une base de données. Bien sûr, il est impossible de tout couvrir dans un seul article. Voici deux ressources complémentaires qui pourraient vous aider à surmonter certains problèmes spécifiques.

1. Comment faire un test de régression sur une base de données relationnelle
2. Comment réaliser un test de performance sur une instance SQL Server

Qu’en pensez-vous ?

Être chargé de tester une base de données peut sembler représenter beaucoup de responsabilités. J’ai confiance en votre capacité à y arriver. Vous sentez-vous plus sûr dans votre approche du test de base de données ? Dites-le-moi dans les commentaires !