Artefacts de test de logiciel - Guide détaillé

30 octobre 2021

Table des matières

5. Données d'essai

Qu'est-ce que les données de test ?

Données de test

La manipulation des données nécessaires aux tests logiciels est ignorée.

Cependant, les testeurs oublient souvent que sans données de test appropriées, le développement et les tests de logiciels pourraient échouer considérablement.



Un ensemble de données excellent et représentatif est essentiel pour créer des cas de test pratiques.

Les données de test sont les données préchargées dans le système en tant qu'entrées par le testeur pour effectuer l'exécution des tests logiciels.

Il peut s'agir de simples ensembles de noms d'utilisateur et de mots de passe ou de millions d'enregistrements de données complexes.

L'exigence essentielle pour les données d'essai est qu'elles doivent être précises et exactes.

Dans les tests positifs, les données de test vérifient les fonctions qui produisent les résultats attendus, et dans les tests négatifs, elles vérifient les fonctions qui produisent des résultats exceptionnels ou inhabituels par rapport aux résultats attendus.

Importance des données de test

Selon les recherches d'IBM en 2016, env. 30 à 60 % du temps d'un testeur est investi dans la recherche, la génération ou la maintenance des données de test.

Ainsi, l'importance des données de test est :

1. Quantité excessive de données

La production est comme une botte de foin de données à partir de laquelle les données de test seront compilées.

Les cas exceptionnels sont difficiles à trouver parmi les téraoctets de données disponibles pour effectuer des tests utiles.

2. Pas d'accès à la source de données

GDPR, HIPAA, PCI et d'autres réglementations de sécurité ont limité l'accès à la source de données.

Bien que ces politiques aient considérablement réduit les risques de violation de données, les équipes de test deviennent dépendantes des quelques employés. Ils ont accès aux données afin de procéder à la formulation des cas de test.

3. Les temps de rafraîchissement sont longs

La possibilité d'auto-rafraîchissement des données n'étant pas donnée aux équipes de test, la nécessité de contacter le DBA est la même.

C'est un long processus qui peut parfois prendre des jours ou des semaines pour que le rafraîchissement soit fait.

4. Délai d'accès aux données de production

Étant donné que les tests agiles ne sont pas encore largement utilisés dans les organisations, lorsque plusieurs équipes travaillent sur le même projet et accèdent aux mêmes bases de données, cela entraîne des conflits.

Il arrive souvent que l'ensemble de données lorsqu'il atteint une équipe ait déjà été modifié en raison des opérations effectuées dessus par l'équipe précédente.

Types de données d'essai

1. Données aux limites

Ce sont les données valides qui satisfont les conditions aux limites.

Si les données sont correctement définies, le logiciel donne la sortie attendue en fonction de l'entrée.

2. D'énormes données

Les tests de performance utilisent un grand ensemble de données appelées données volumineuses, qui testent si le système tombe en panne ou non dans différentes conditions.

3. Données vierges

Comme son nom l'indique, il ne contient aucune donnée ou simplement un fichier vierge.

Le résultat attendu de ces données est que le logiciel ne tombe pas en panne et que les exceptions générées sont correctement gérées à l'aide de messages d'erreur appropriés.

4. Données valides

Des données valides sont prises en charge ou sont attendues par le logiciel, ce qui donne le résultat attendu pour une saisie correcte.

5. Données invalides

Ce type de données n'est ni pris en charge ni attendu par le logiciel et teste si le système s'arrête lorsqu'un ensemble de données non valide est transmis.

Il vérifie également si les exceptions sont bien gérées ou non en utilisant des messages d'erreur appropriés.

Données de test dans les tests

1. Dans les tests de sécurité

Tests de sécurité est responsable de la protection globale du système contre les intentions malveillantes.

Ainsi, les données de test conçues pour la sécurité doivent être conçues pour tester de manière approfondie la sécurité du logiciel :

    Confidentialité:Les données de test doivent être conçues pour conserver les données du client en toute sécurité et ne sont partagées avec aucun autre tiers.Intégrité:Après avoir examiné en profondeur la conception du système, la base de données, le code et les structures de fichiers, des données de test appropriées peuvent être conçues pour vérifier si les informations fournies par le système sont correctes ou non.Authentification:Une variété de données de test avec différents noms d'utilisateur et mots de passe peuvent être conçues pour vérifier si seules les personnes authentifiées peuvent se connecter au système ou non. L'authentification est le processus qui établit l'identité de l'utilisateur.Autorisation:Pour vérifier les droits ou privilèges d'un utilisateur spécifique, des données de test contenant une combinaison d'utilisateurs, d'opérations, ainsi que leurs rôles et conceptions.

2. Dans les tests en boîte blanche

Les données de test examinent directement le code à tester dans les tests en boîte blanche. Les éléments suivants sont pris en compte lors de sa conception :

  • Dans le cadre des tests de chemin, les données de test doivent être conçues pour couvrir le nombre maximum de cas de test couvrant tous les chemins dans le code source du programme.
  • En négatif Test d'API , le test peut consister en des types de paramètres non valides ou en une combinaison d'arguments pour appeler différentes méthodes dans un programme.
  • Les données de test peuvent être conçues de manière à tester toutes les branches du code source d'un programme au moins une fois.

3. Dans les tests de boîte noire

Les données de test dans les cas de test fonctionnels des tests de boîte noire peuvent avoir les critères suivants :

    Ensemble de données sur les conditions aux limites :Tester les données qui répondent aux conditions de valeur limite.Utiliser les données de test de cas :Cas d'utilisation des données de test synchronisées.Données valides :Données pour vérifier la réponse du système pour une entrée de données valide.Données invalides:Données pour vérifier la réponse du système à une entrée de données non valide.Ensemble de données de partition d'équivalence :Tester les données qui qualifient les partitions d'équivalence.Ensemble de données de test de transition d'état :Données de test qui répondent à la stratégie de test pour les transitions d'état.Format de données illégal :Lorsque les données de test sont illégales, les performances du système doivent être vérifiées.Ensemble de données de table de décision :Testez les données qui se qualifient pour la stratégie de test de la table de décision.

4. Dans les tests de performance

Pour déterminer la charge de travail maximale sous laquelle un système peut répondre rapidement aux requêtes soulevées s'appelle Test de performance .

Habituellement, les données réelles ou en direct obtenues des clients sont utilisées pour générer des données de test et des cas de test pour les tests de performance.

Ce test n'est pas utilisé pour trouver des bogues mais sert uniquement à éliminer les goulots d'étranglement.

Les clients fournissent les données déjà existantes ou les nouvelles données en retour d'information sur l'apparence des données dans le monde réel.

Bonnes propriétés des données de test

Une donnée de test utile doit être précise et doit posséder les qualités suivantes :

1. Polyvalent

Les données de test doivent être choisies pour assurer une couverture d'aspect maximale d'un scénario unique avec un ensemble de données minimal.

2. Réaliste

Les données de test doivent être exactes et doivent se situer dans le contexte de scénarios réels.

L'utilisation réaliste des données rend le logiciel plus robuste, car la plupart des bogues seront capturés en raison des conditions réelles.

L'utilisation réaliste des données permet également d'économiser le temps et les efforts investis dans la création de nouvelles données encore et encore.

3. Données exceptionnelles

Les données de test peuvent également être générées pour des scénarios exceptionnels, le cas échéant ou requis par le système.

Ces scénarios exceptionnels sont ceux qui se produisent moins fréquemment et demandent une attention particulière.

4. Pratiquement valable

Ces types de données sont similaires à réalistes mais ne sont pas les mêmes. Il est davantage lié à la logique métier d'AUT.

Techniques de préparation ou de génération de données de test

Il existe deux techniques pour préparer les données de test :

1. Insérer

En cela, les données de test sont insérées selon les besoins des cas de test dans une base de données qui peut ne pas être vide.

Préoccupations :

  • Comme les tables de base de données ont des interdépendances, l'insertion de données dans une base de données vide est difficile pour le testeur.
  • Dans le cas de test de performance ou de charge , les données de test insérées peuvent ne pas être suffisantes.
  • L'aide des développeurs de la base de données sera nécessaire car des requêtes ou des procédures complexes peuvent être utilisées pour insérer des données de test dans la base de données.
  • Comme l'ensemble de données de test est limité, il peut masquer certains bogues qui auraient pu être trouvés, étant donné qu'un ensemble de données plus complet a été fourni.

Avantages :

  • L'insertion de nouvelles données réduit le temps requis pour les tests et la comparaison des résultats.
  • Étant donné que la base de données ne contient qu'un ensemble de données limité, l'exécution des cas de test devient plus efficace.
  • En raison de la disponibilité des données de test, le processus de test devient sans encombrement.
  • L'isolement des bogues prend moins de temps car seules les données spécifiées dans les cas de test sont présentes dans la base de données.

2. Choisissez un exemple de sous-ensemble de données

Cette option est plus faisable et pratique dans l'approche pour la préparation des données de test.

La méthode consiste à copier et à utiliser les données de production en remplaçant les valeurs de champ par des valeurs fictives.

Pour mettre en œuvre cette technique, de bonnes compétences techniques et une connaissance détaillée du schéma de base de données et SQL est requis.

Bien que cette technique soit le meilleur sous-ensemble de données pour les tests, elle n'est pas toujours réalisable en ce qui concerne les problèmes de sécurité et de confidentialité des données.

Approches pour tester la génération de données

    Injection de données back-end :Avec l'aide de SQL requêtes, la base de données existante peut être facilement mise à jour. Cette approche est rapide et efficace mais doit être soigneusement mise en œuvre pour éviter la corruption de la base de données.Génération manuelle des données de test :Cette méthode chronophage et sujette aux erreurs implique la saisie manuelle des données de test par les testeurs en fonction des exigences du cas de test.Utilisation d'outils tiers :Sur le marché, certains outils sont adaptés aux besoins commerciaux des clients, mais sont coûteux. Ils peuvent être personnalisés pour s'adapter au scénario de test afin de générer ou d'injecter des données afin de fournir une couverture de test complète.Génération automatisée des données de test :Cette méthode est plus coûteuse que la génération manuelle de données de test, mais fournit des données rapides et précises. Il utilise les outils de génération de données de test.

Outils de génération de données de test

ProduitVendeur
Générateur de données EMS SME
Base de données de test IBM DB2 IBM
E-Naxos DataGen E-Naxos
Générateur de données DTM SQLModifier
Générateur de données SQL Porte Rouge

Gestion des données de test (TDM)

La gestion des données de test est un processus complet impliquant la planification, la conception, le stockage et la récupération de données de test hors production qui imitent les données réelles d'une organisation afin que les développeurs et les testeurs puissent effectuer les tests appropriés en les utilisant.

L'importance de la gestion des données de test (TDM) est :

    Sécurité:En raison d'une réglementation stricte imposée par le gouvernement et d'autres autorités, le TDM met également en œuvre le masquage des données, la sécurité des données et la sécurité en tant que partie intégrante de la génération des données de test.Confiance:TDM fournit des données de qualité utiles et une couverture des données qui aident à démêler les bogues rapidement et efficacement pendant la phase de test. TDM fournit aux clients un logiciel hautement stable et de haute qualité avec un minimum de défauts, augmentant ainsi la confiance de l'organisation.Couverture des données de test :La traçabilité des données de test implémentée dans TDM offre une meilleure couverture des données de test et une meilleure identification des modèles de défauts.Réutilisabilité :La réutilisabilité des données réduit les coûts car les données réutilisables sont archivées et peuvent être consultées au fur et à mesure des besoins par l'équipe de test.Détection précoce des bogues :Grâce à une meilleure couverture et traçabilité des tests, les bugs peuvent être trouvés et résolus plus tôt, réduisant ainsi le coût de production.Données provisionnées :Dans TDM, les données sont gérées en un seul endroit et peuvent être provisionnées pour différents types de tests tels que les tests fonctionnels, de performance, d'intégration, etc. Cela entraîne également une réduction des coûts de redondance et de stockage.Réduire la copie :TDM conserve toutes les données dans le même référentiel qui peut être utilisé par toutes les équipes, et donc aucune équipe n'est nécessaire pour faire plusieurs copies des mêmes données pour des usages individuels. Ainsi, TDM garantit une utilisation diligente de l'espace de stockage.

Limites des données de test

  • Les données de test ne doivent pas contenir de données confidentielles ou d'informations personnelles identifiables (PII).
  • Les règles de confidentialité spécifiées dans la loi HIPAA (Health Insurance Portability and Accountability Act), la norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS) et le règlement général sur la protection des données (RGPD) ont limité l'utilisation des données privées à des fins de test.
  • Les données anonymisées peuvent être utilisées à des fins de test et de développement.
  • Un testeur peut également créer des données synthétiques, mais cela s'accompagne de certaines limitations, telles que la possibilité limitée de génération de fausses données, les limitations de temps, de coût et de qualité.

L'équipe de test est responsable de la génération des données de test ; cependant, ils peuvent ou non avoir un accès direct aux données de production.

La production est constituée de données brutes qui ne conviennent pas à une utilisation directe dans les tests et nécessitent des efforts considérables pour trier, gérer et adapter les données en fonction des besoins du testeur.

Des données de haute qualité sont nécessaires pour créer un logiciel de haute qualité avec moins de défauts, et à cette fin, la gestion des données de test est la meilleure solution.

Conclusion

Voici quelques-uns des artefacts de test de logiciels importants qui sont préparés pour tous les projets de test de logiciels en général. Ces documents fournissent une image claire de ce qui a été testé ainsi que le résultat des résultats des tests.