Instructions: Données de test
Ces instructions offrent une introduction à la conception d'ensembles de données de test.
Relations
Eléments connexes
Description principale

Explication

Pour la tâche de conception de tests, deux artefacts importants ont été identifiés et décrits : les scripts de test et les jeux d'essai. Sans les données de test, l'implémentation et l'exécution de ces deux artefacts sont impossibles. Il s'agit simplement de descriptions de conditions, de scénarios et de chemins sans valeurs concrètes permettant de les identifier. Les données de test ne sont pas à proprement parler un artefact et sont déterminantes pour l'échec ou l'aboutissement d'un test. Les tests ne peuvent être implémentés et exécutés sans données de test, ces dernières étant requises pour :

  • l'entrée afin de créer une condition,
  • la sortie afin d'évaluer une exigence,
  • la prise en charge (condition préalable du test).

Par conséquent, l'identification des valeurs est un effort important qui a lieu lorsque des jeux d'essai sont identifiés (voir produit : jeu d'essai et instruction : jeu d'essai).

Quatre attributs de données de test doivent être pris en compte lors de l'identification des données de test réelles :

  • profondeur - volume ou quantité de données dans les données de test.
  • largeur - degré de variation dans les données de test.
  • portée - importance des données de test par rapport à l'objectif du test.
  • architecture - structure physique des données de test.

Ces caractéristiques sont présentées en détail dans les sections qui suivent.

Profondeur

La profondeur est le volume ou la quantité de données utilisées dans un test. Elle constitue un aspect important, sachant qu'un nombre insuffisant ne reflète éventuellement pas la réalité et que trop de données sont difficiles à gérer. Idéalement, les tests doivent commencer par un petit ensemble de données prenant en charge les jeux d'essai importants (généralement positifs). La confiance augmentant au fil des tests, les données de test doivent aussi augmenter, jusqu'à ce que la profondeur de données soit représentative de l'environnement déployé (ou de ce qui est approprié et faisable).

Largeur

La largeur désigne le degré de variation des valeurs des données de test. Il suffit de créer des enregistrements pour augmenter la profondeur des données de test. Bien que cette solution soit souvent bonne, cette opération ne prend pas en compte les véritables variations des données réellement attendues. Sans ces variations des données de test, des incidents peuvent vous échapper (après tout, tout les retraits d'un guichet automatique ne sont pas de 50 €). Par conséquent, les valeurs des données de test reflètent les valeurs figurant dans l'environnement déployé, comme le retrait de 10 ou de 120 €. Par ailleurs, les données de test doivent refléter des informations réelles, comme :

  • Des noms, dont des titres, des valeurs numériques, des ponctuations et des suffixes :
    • Dr James Bandlin, Mme Susan Smith, Msgr Joseph P. Mayers
    • James Johnson III, M. Charles James Ellsworth
    • Ellen Jones-Smythe, Brian P. Tellstor
  • Des adresses sur plusieurs lignes :
    • 6500 Broadway Street
      Suite 175
    • 1550 Broadway
      Floor 17
      Mailstop 75A
  • Des indicatifs (ville et pays) et des numéros de téléphone réels et qui correspondent
    • Lexington, MA, Etats-Unis + 01 781 676 2400
    • Kista, Suède +46 8 56 62 82 00
    • Paris, France +33 1 30 12 09 50

Les valeurs des données de test peuvent être une représentation physique ou statistique des données réelles pour obtenir une largeur suffisante. Les deux méthodes sont intéressantes et recommandées.

Pour créer des données de test à partir d'une représentation physique des données déployées, identifiez les valeurs (ou plages) à allouer pour chaque élément dans la base de données déployée. Vérifiez ensuite qu'au moins un enregistrement dans les données de test contient chaque valeur à allouer.

Par exemple :

  Numéro de compte (plage) Code confidentiel
(entier)
Solde du compte
(décimal)
Type de compte
(chaîne)
(S) 0812 0000 0000 à
0812 9999 9999

© 0829 0000 0000 à
0829 9999 9999

(X) 0799 0000 0000 à
0799 9999 9999

0000 - 9999 -999 999,99 à 999 999,99 S, C, X
enregistrement 1 0812 0837 0293 8493 -3 123,84 S
enregistrement 2 0812 6493 8355 3558 8 438,53 S
enregistrement 3 0829 7483 0462 0352 673,00 C
enregistrement 4 0799 4896 1893 4896 493 498,49 X

La matrice ci-dessus contient le nombre minimum d'enregistrements qui représenteraient physiquement les valeurs de données acceptables. Pour le numéro de compte, il existe un enregistrement pour chacune des trois plages, tous les codes confidentiels se trouvent dans la plage indiquée, il y a différents soldes du compte (dont un négatif) et il existe des enregistrements pour chaque type de compte. La matrice ci-dessus correspond aux données minimum et il est recommandé d'avoir des valeurs de données à la limite de chaque plage ainsi qu'à l'intérieur (voir Instruction : jeu d'essai).

L'avantage d'une représentation physique est que les données de test sont limitées en taille et gérables, car cantonnées aux valeurs acceptables. Toutefois, l'inconvénient est que les données réelles ne sont pas complètement aléatoires. Les données réelles ont tendance à avoir des profils statistiques pouvant altérer les performances, ce qui n'est pas visible lors d'une représentation physique.

La représentation statistique de données de test illustre un échantillon statistique (des mêmes pourcentages) des données de production. Par exemple, avec les mêmes données que précédemment, si vous analysez la base de données de production et découvrez ce qui suit :

  • Nombre total d'enregistrements : 294 031
  • Nombre total de types de compte S : 141 135 (48 % du total)
  • Nombre total de types de compte C : 144 075 (49 %)
  • Nombre total de types de compte X : 8 821 (3 %)
  • Les numéros de comptes et les codes confidentiels sont répartis de façon égale.

Vos données de test basées sur l'échantillon statistique compteraient 294 enregistrements (par rapport aux quatre mentionnés ci-dessus) :

  Données de test (à 0,1 % de production)
Nombre d'enregistrements Pourcentage
Nombre total d'enregistrements 294 100
Numéros de comptes
(S) 0812 0000 0000 à
0812 9999 9999
141 48
Numéros de comptes
© 0829 0000 0000 à
0829 9999 9999
144 49
Numéros de comptes
(X) 0799 0000 0000 à
0799 9999 9999
9 3

La matrice ci-dessus prend uniquement en compte les types de compte. Lors du développement des meilleures données de test par rapport à la représentation statistique, vous devez inclure les données principales. Dans l'exemple précédent, il s'agirait de refléter les soldes réels des comptes.

L'inconvénient de la représentation statistique est qu'elle ne reflète pas toujours la plage complète de valeurs acceptables.

En général, les deux méthodes d'identification de données de test sont employées pour que les données prennent en compte toutes les valeurs et tous les problèmes de performances/remplissage.

La largeur des données de test est essentielle pour les données utilisées comme entrée ou comme prise en charge de tests (dans les données préexistantes).

Portée

La portée correspond à la pertinence des données de test par rapport à l'objectif du test et est liée à la profondeur et à la largeur. Même si vous possédez beaucoup de données, elles ne sont pas forcément appropriées. Comme pour la largeur, vous devez vérifier que les données de test sont pertinentes par rapport à l'objectif du test, à savoir qu'elles permettent de l'atteindre.

Par exemple, dans la matrice ci-dessous, les quatre premiers enregistrements de données de test prennent en compte les valeurs acceptables pour chaque élément. Cependant, il n'existe pas d'enregistrement pour évaluer les soldes négatifs pour les types de compte C et X. Par conséquent, même si les données de test incluent correctement des soldes négatifs (largeur valide), la portée des données qui suivent sera insuffisante pour prendre en charge des tests avec des soldes négatifs pour chaque type de compte. Il serait nécessaire d'étendre ces données afin d'inclure d'autres enregistrements, y compris des soldes négatifs pour chaque type de compte, et donc régler cet oubli.

Numéro de compte (plage) Code confidentiel
(entier)
Solde du compte
(décimal)
Type de compte
(chaîne)
(S) 0812 0000 0000 à
0812 9999 9999

© 0829 0000 0000 à
0829 9999 9999

(X) 0799 0000 0000 à
0799 9999 9999

0000 - 9999 -999 999,99 à 999 999,99 S, C, X
enregistrement 1 0812 0837 0293 8493 -3 123,84 S
enregistrement 2 0812 6493 8355 3558 8 438,53 S
enregistrement 3 0829 7483 0462 0352 673,00 C
enregistrement 4 0799 4896 1893 4896 493 498,49 X
Nouvel enregistrement 1 0829 3491 4927 0352 -995 498,34 C
Nouvel enregistrement 2 0799 6578 9436 4896 -64 913,87 X

La portée des données de test est essentielle pour les données utilisées comme entrée ou comme prise en charge de tests (dans les données préexistantes).

Architecture

La structure physique des données de test n'est importante que pour les données préexistantes utilisées par la cible de test pour les tests, comme la base de données d'une application ou un tableau de règles.

Les tests ne sont pas exécutés une seule fois. Ils sont répétés dans et entre des itérations. Afin d'effectuer un test d'exécution de façon cohérente, fiable et efficace, les données de test doivent revenir à leur état initial avant l'exécution du test. Ceci se vérifie notamment dans le cas de tests automatisés.

Par conséquent, pour garantir un test cohérent, fiable et efficace, il faut que les données de test soient libres de toutes les influences externes et que leur état soit connu au début, pendant et à la fin de l'exécution du test. Deux aspects doivent être traités pour atteindre cet objectif :

Chacun de ces aspects affectera le mode de gestion de la base de données de test, la conception du modèle de test et l'interaction avec d'autres rôles.

Instabilité / Ségrégation

Les données de test peuvent devenir instables pour les raisons suivantes :

  • des influences externes indépendantes du test modifient les données ;
  • d'autres testeurs ne savent pas quelles données sont utilisées.

Pour garantir la fiabilité et la cohérence du test, les données de test doivent faire l'objet d'un contrôle poussé et être protégées de ces influences. Les stratégies de protection sont :

  • Chaque testeur d'environnements de test possède son propre environnement de test physiquement séparé de celui des autres. Les testeurs ne partagent rien et disposent de leur cible de test et de leurs données propres. Par exemple, chaque testeur travaille sur son propre PC.
  • Chaque testeur d'instance de base de données de test possède sa propre instance de données isolées des autres influences. L'environnement physique et éventuellement la cible de test sont partagés, mais chaque testeur possède sa propre instance des données, ce qui limite le risque d'altération des données de test.
  • Chaque testeur de partitionnement de base de données/données de test partage la base de données et sait quelles données sont utilisées par les autres (il évite donc d'employer les données d'un autre testeur). Par exemple, un testeur peut utiliser les enregistrements 0 - 99, un autre les enregistrements 100 - 199 ; de la même façon, un testeur peut utiliser les clients dont l'initiale du nom est Aa - Kz, alors qu'un autre s'occupe des noms La - Zz.

Etat initial

L'autre aspect de l'architecture des données de test à régler est l'état initial des données au début de l'exécution du test. Ceci est notamment le cas pour des tests automatisés. De la même façon que la cible de test doit commencer l'exécution du test dans un état connu et souhaité, les données de test doivent en faire autant. Ainsi, vous avez la garantie que chaque exécution de test est identique à la précédente.

Quatre stratégies servent habituellement à traiter cet aspect :

  • régénération des données
  • réinitialisation des données
  • redéfinition des données
  • restauration des données

Chaque stratégie est décrite ci-après en détail.

La méthode employée dépend de plusieurs facteurs, dont les caractéristiques physiques de la base de données, la compétence technique des testeurs, la disponibilité des rôles externes (hors test) et la cible de test.

Régénération des données

La méthode la plus souhaitable pour restaurer l'état initial des données de test est une régénération. Cette méthode implique la création et le stockage d'une copie de la base de données dans son état initial. Au terme de (ou avant) l'exécution du test, la copie archivée de la base de données de test est copiée dans l'environnement de test. De cette façon, l'état initial des données de test est identique au début de chaque exécution de test.

L'avantage de cette méthode est que les données peuvent être archivées dans plusieurs états initiaux. Par exemple, les données de test peuvent être archivées dans l'état de fin de journée, de fin de semaine, de fin de mois, etc. Le testeur peut ainsi régénérer rapidement les données à un état précis pour le test (par exemple, des cas d'utilisation de fin de mois).

Réinitialisation des données

S'il est impossible de régénérer les données, la méthode suivante la plus appropriée est la restauration à leur état initial par programmation. La réinitialisation des données s'appuie sur des cas d'utilisation et des outils pour faire revenir les données de test à leur état initial.

Prenez garde que l'ensemble des données, relations et valeurs clés soient ramenées à la valeur initiale appropriée, afin d'éviter l'introduction d'erreurs dans les données.

L'avantage de cette méthode est qu'elle permet de tester des valeurs incorrectes dans la base de données. Dans des conditions normales, les valeurs incorrectes seraient prises au piège et interdites d'accès aux données (par exemple, avec une règle de validation dans le client). Cependant, un autre acteur pourrait affecter les données (comme une mise à jour électronique depuis un autre système). Le test doit vérifier que des données incorrectes sont identifiées et gérées comme il se doit, indépendamment de ce qui se produit.

Redéfinition des données

Une méthode simple pour restaurer des données à leur état initial consiste à "inverser les changements" effectués lors du test. Cette méthode se sert de la cible de test pour insérer des entrées contraires, à savoir ajouter des enregistrements/valeurs ayant été supprimés, annuler les modifications apportées aux enregistrements/valeurs et supprimer les données ajoutées.

Certains risques sont toutefois associés à cette méthode, dont :

  • toutes les actions doivent être inversées, et pas seulement une partie ;
  • elle repose sur des cas d'utilisation dans la cible de test, qui doit être testée pour vérifier sa fonction avant d'être employée pour réinitialiser des données ;
  • des clés, des index et des points peuvent ne pas être réinitialisés.

S'il s'agit de la seule méthode disponible dans votre environnement de test, évitez d'utiliser des clés, des index et des pointeurs de la base de données comme cibles principales de la vérification. Par exemple, utilisez le champ Nom du patient pour savoir si le patient a été ajouté à la base de données au lieu d'employer un numéro d'ID de patient généré par le système.

Restauration des données

La restauration des données est la méthode la moins souhaitable pour ramener des données de test à leur état initial. En fait, elle ne traite pas vraiment cet aspect. L'état des données au terme de l'exécution du test devient à la place le nouvel état initial. En général, vous devez alors modifier les données de test utilisées pour l'entrée et/ou les jeux d'essai et les données de test servant à évaluer les résultats.

Ceci est nécessaire pour certaines instances, comme la fin de mois. Si aucune donnée n'est archivée juste avant la fin du mois, les données et les scripts de test de chaque jour et chaque semaine doivent être exécutés en vue de restaurer les données à l'état requis pour le test du traitement de fin de mois.

Les risques associés à cette méthode sont :

  • Des clés, des index et des points peuvent ne pas être réinitialisés et utilisés pour vérification.
  • Les données changent constamment.
  • Vous devez encore intervenir pour certifier la vérification des résultats.