Comment testez-vous les programmes qui nécessitent des données d'entrée complexes?

Question

Nous avons une suite de convertisseurs qui prennent des données complexes et les transforment. Généralement, l'entrée est EDI et la sortie XML, ou vice-versa, bien qu'il existe d'autres formats.

Il existe de nombreuses interdépendances dans les données. Quelles sont méthodes ou logiciel sont disponibles qui peuvent générer des données d'entrée complexes comme ceci?

Actuellement, nous utilisons deux méthodes: (1) une suite de fichiers exemples que nous avons construits au fil des années principalement à partir de fichiers bugs et d'échantillons dans la documentation et (2) générer des données de test pseudo-aléatoires. Mais le premier ne couvre qu'une fraction des cas, et le second a beaucoup de compromis et ne teste qu'un sous-ensemble des champs. Avant d'aller plus loin dans la mise en œuvre (réinventant?) D'un générateur de données complexe piloté par une table, quelles options avez-vous réussi?

Answer 1

Eh bien, la réponse est dans votre question. À moins de mettre en œuvre un générateur de données complexe piloté par une table, vous faites les choses correctement avec (1) et (2).

(1) couvre la règle de "1 bogue vérifié, 1 nouveau cas de test". Et si la structure des données de test pseudo-aléatoires de (2) correspond quoi que ce soit dans les situations de la vie réelle, c'est bien.

(2) peut toujours être amélioré, et il va s'améliorer principalement au fil du temps, en pensant à de nouveaux cas de bord. Le problème avec les données aléatoires pour les tests est que cela ne peut être aléatoire qu'au point où il devient si difficile de calculer la sortie attendue des données aléatoires dans le cas de test, que vous devez fondamentalement réécrire l'algorithme testé dans le cas de test.

Donc (2) correspondra toujours à une fraction des cas. Si un jour il correspond à tous les cas, ce sera en fait une nouvelle version de votre algorithme.

Answer 2

1. Je vous conseille de ne pas utiliser des données aléatoires car il peut rendre difficile sinon impossible de reproduire l'erreur qui a rapporté (je sais que vous avez dit « pseudo-aléatoire », tout simplement pas sûr de ce que vous entendez par là exactement).

2. L'exploitation sur des fichiers entiers de données prendrait probablement en compte les tests fonctionnels ou d'intégration. Je suggère de prendre votre ensemble de fichiers avec des bogues connus et de les traduire en tests unitaires, ou du moins le faire pour tous les bugs que vous rencontrerez. Ensuite, vous pouvez également étendre ces tests unitaires pour inclure la couverture pour les autres conditions erronées selon lesquelles vous n'avez pas de 'données d'échantillon'. Cela sera probablement plus facile que d'arriver avec un nouveau fichier de données chaque fois que vous pensez à une violation de condition/règle que vous voulez vérifier.

3. Assurez-vous que votre analyse du format de données est encapsulée à partir de l'interprétation des données dans le format. Cela rendra les tests unitaires décrits ci-dessus beaucoup plus faciles. Si vous avez absolument besoin de conduire vos tests, vous pouvez envisager d'obtenir une description lisible par machine du format de fichier et d'écrire un générateur de données de test qui analysera le format et générera des fichiers valides/invalides basés dessus. Cela permettra également à vos données de test d'évoluer comme le font les formats de fichiers.