Comprendre les principaux tests de bases de données
La plupart des testeurs de logiciels vérifient les propriétés ACID lors de tests de bases de données. Mais ils ne doivent pas négliger les tests fonctionnels et non fonctionnels en plus des audits de conformité et de sécurité.
Il existe trois grandes familles de tests de bases de données : les tests fonctionnels, de validation ACID et de performance.
Les tests fonctionnels et la cartographie des relations associent les bases de données à la fois aux sources d'information front-end et à l'utilisation back-end de ces informations, afin de garantir la cohérence du formatage et des opérations de lecture et d’écriture. La vérification de l’atomicité, de la cohérence, de l’isolation et de la durabilité (ACID) d’un gestionnaire de transactions s’effectue après une batterie de tests fonctionnels. Enfin, les bases de données doivent subir des épreuves de performance : test de débit, montée en charge, usage CPU, RAM et I/O, etc. Certaines organisations placent les tests de sécurité et de conformité dans cette dernière catégorie ou créent un quatrième ensemble pour les réunir.
Pourquoi les tests de bases de données sont-ils importants ?
Peu d’applications en production (voire aucune) fonctionnent sans base de données.
Les tests de bases de données et d’applications sont liés. Certaines DSI et équipes IT les réalisent de concert, par exemple au moment d’effectuer des tests unitaires. Cependant, l’interdépendance croissante des composants applicatifs est également vraie pour les bases de données qui les supportent. Souvent vu comme un monolithe, le SGBD dépend de plusieurs éléments techniques. Pour ces raisons, les équipes de développement doivent tester les databases, ainsi que tenir compte de leurs propriétés et exigences uniques lors de l’écriture de la méthodologie de tests.
Les équipes de développement doivent tester les databases, ainsi que tenir compte de leurs propriétés et exigences uniques lors de l’écriture de la méthodologie de tests.
Plusieurs questions animent les débats relatifs aux tests de bases de données. Faut-il appliquer ces épreuves par fournisseur ou par produit ? Doit-on réaliser ces opérations en utilisant directement les fonctions d’interrogation (SQL) ou les API ? Pour les entreprises qui ne dépendent que d’un seul fournisseur de SGBD, la première question est sans objet. Lorsqu’il y a plusieurs bases de données en place, envisagez de tester chaque produit avec des outils différents. Cela permet souvent d’obtenir une meilleure évaluation.
En ce qui concerne la deuxième question, les vérifications s’appuyant sur le langage de requête (SQL est le plus commun, mais un SGBD NoSQL peut avoir son propre langage) sont généralement plus faciles à mener par les administrateurs (DBA) et plus proches d’une utilisation réelle des applications que l’approche guidée par les API. Par exemple, c’est la première réponse à apporter à ceux qui veulent savoir commenter tester une base de données MySQL.
En outre, les bases de données sont de plus en plus souvent distribuées entre des applications et les organisations. Afin d’éviter les évaluations incomplètes ou redondantes, il est préférable de ne pas réaliser des essais individualisés, pour une application spécifique. Cela signifie que les développeurs et les équipes Q&A doivent partager un même référentiel méthodologique et manipuler des outils communs.
Tests fonctionnels
Les tests fonctionnels valident que les utilisateurs et les applications peuvent accéder aux données de la base de données et les mettre à jour. Certains testeurs préfèrent valider les fonctionnalités en manipulant l’application ou les applications qui reposent sur le SGBD. Cette approche présente un risque lorsque les tests applicatifs ne parviennent pas à manipuler tous les champs et conditions de la base de données.
Pour s’assurer que chaque fonction du SGBD est bien mise à l’épreuve, employez un générateur de tests et veillez à piloter directement la base de données. Cette approche n’est pas non plus sans risque : les données de tests peuvent fausser une analyse. Il est facile de passer à côté de problèmes liés à la taille des champs ou au format des données si l’exercice ne s’appuie pas sur des entrées bel et bien réelles.
Pour garantir la qualité de la base de données, choisissez le meilleur outil de test fonctionnel pour le projet, puis complétez-le avec d’autres méthodes.
Outils de test fonctionnel. Les services IT peuvent employer des outils de test fonctionnel généralistes ou spécifiques aux bases de données. Certaines équipes examinent les SGBD via SQL, en utilisant des outils tels que SeLite.
Les produits généralistes comprennent :
SolarWinds Database Performance Analyzer
MockupData
DTM Test Data Generator
Les outils spécifiques aux bases de données comprennent :
SolarWinds Orion
Oracle SQL Developer pour Oracle
tSQLt pour Microsoft SQL Server
Tests ACID
Les tests ACID sont probablement les plus pratiqués par les professionnels de l’IT. Le respect des propriétés ACID valide l’intégrité globale de la base de données, ce que l’on pourrait appeler l’intégrité logique : la capacité fondamentale du SGBD à refléter les conditions d’enregistrement des données, sans ambiguïté ni duplication.
La plupart des approches de tests ACID utilisent le langage SQL pour valider chacune des quatre exigences :
La transaction est complète en elle-même, et elle réussit ou échoue dans son ensemble.
L’activité ne provoque pas d’action inattendue de la base de données. Soit une transaction réussit et crée un nouvel état, soit elle échoue et la base de données revient à son état précédent.
Les transactions se produisent simultanément ou séquentiellement sans créer un état incohérent pour la base de données.
Les opérations du SGBD résistent aux pannes de courant et autres interruptions.
Les tests, procédures et outils ACID sont largement disponibles et établis dans l’industrie du logiciel. Grâce à la prévalence des tests ACID, les équipes logicielles disposent probablement des informations existantes pour définir leur approche sans difficulté. Cela peut toutefois masquer un problème. De nombreux usagers se concentrent uniquement sur l’examen des propriétés ACID et, par conséquent, passent à côté d’erreurs qui peuvent créer des problèmes majeurs.
Outils de test ACID. DTM Data Generator et MockupData sont populaires pour ce type de test, ainsi que pour les tests fonctionnels. De nombreux utilisateurs préfèrent des outils plus spécifiques aux tests ACID, tels que ceux de Microsoft et d’Oracle pour le développement SQL. La plupart des entreprises utilisent des générateurs de données de masse pilotant un script SQL pour valider le bon fonctionnement des bases de données.
Tests non fonctionnels
Les tests de charge et autres benchmarks de performance vérifient si la base de données est capable de supporter les opérations des utilisateurs en production. De nombreuses organisations ont historiquement testé les bases de données et les applications ensemble, lorsque les bases de données étaient liées à un seul logiciel et non partagées entre plusieurs microservices. Ces équipes peuvent encore regrouper tous les tests de performance, mais à l’ère de l’interdépendance et de la fragmentation des composants logiciels, c’est un piège.
Ces tests de la base de données dans diverses situations peuvent être biaisés par d’autres problèmes. Pour tester les performances, exécutez les examens localement sur la base de données, et non à distance, où les délais du réseau pourraient fausser le résultat. Un bon test de performance peut nécessiter une combinaison d’outils. Les testeurs peuvent utiliser un outil approprié pour générer une charge de travail spécifique, et un autre pour surveiller les performances.
Outils de test de performance. Parmi les outils populaires pour les tests non fonctionnels, citons :
SolarWinds Database Performance Analyzer
Data Factory sur SourceForge
MockupData
Database Performance Analyzer est un exemple de vaste analyseur in situ des performances des bases de données. Data Factory et MockupData sont des générateurs de données de test pour les tests directs.
