Test fonctionnel des fichiers de sortie, lorsque la sortie est non déterministe (ou avec un contrôle faible)

Question

Il y a longtemps, j'ai dû tester un programme générant une image de fichier postscript. Un moyen rapide de déterminer si le programme produisait la sortie correcte et attendue était de faire un md5 du résultat à comparer avec le md5 d'une sortie «bien connue» que j'ai vérifiée auparavant.

Malheureusement, Postscript contient l'heure actuelle dans le fichier. Ce temps est, bien sûr, différent en fonction du moment où le test s'exécute, modifiant ainsi le md5 du résultat même si la sortie attendue est obtenue. Comme une solution, j'ai juste enlevé la date avec sed.

Ceci est un scénario agréable et simple. Nous ne sommes pas toujours aussi chanceux. Par exemple, maintenant je suis en train de programmer un programme d'écriture, qui crée un gros fichier RDF contenant un tas de nœuds anonymes et d'uuids. Il est fondamentalement impossible de vérifier la fonctionnalité de l'ensemble du programme avec un simple md5, et le seul moyen serait de lire le fichier avec un lecteur, puis de valider la sortie à travers ce lecteur. Comme vous le savez probablement, cela ouvre une nouvelle boîte de Pandore: d'abord, vous devez écrire un lecteur (ce qui peut prendre beaucoup de temps), deuxièmement, vous supposez que le lecteur est fonctionnellement correct et en même temps en phase avec l'auteur. Si le lecteur et l'auteur sont synchronisés, mais sur des suppositions incorrectes, le lecteur dira "pas de problème", mais le format du fichier est réellement faux.

Il s'agit d'un problème général lorsque vous devez effectuer des tests fonctionnels d'un format de fichier et que le format de fichier n'est pas complètement reproductible par l'entrée que vous fournissez. Comment gérez-vous cette affaire?

Answer 1

Dans le passé, j'ai utilisé une application tierce pour valider une telle sortie (de préférence en la convertissant dans un autre format qui peut être vérifié mécaniquement). L'utilisation d'un tiers garantit que mes hypothèses sont au moins partagées par d'autres, si ce n'est pas strictement correct. À tout le moins, cette approche peut être utilisée pour vérifier la syntaxe. L'exactitude sémantique nécessitera probablement la création d'un consommateur pour les données de test qui seront probablement toujours sujettes à l'écueil "suppositions incorrectes" que vous mentionnez.

Answer 2

L'aléatoire est-il toujours aux mêmes endroits? C'est à dire. La plupart des fichiers sont-ils corrigés, mais certaines parties changent-elles toujours? Si c'est le cas, vous pourriez être en mesure de prendre plusieurs sorties et d'utiliser un diff programmatique pour déterminer les parties non déterministes. Une fois que ceux-ci sont connus, vous pouvez utiliser l'information pour dériver un masque et ensuite faire une comparaison (MD5 ou juste une comparaison directe). Pensez à pré-traiter le fichier pour supprimer (ou écraser avec des données déterministes) les parties qui ne sont pas déterministes.

Si le fichier entier n'est pas déterministe, vous devrez trouver une autre solution. J'ai fait des tests de décodeurs MPEG-2 qui ne sont pas déterministes. Dans ce cas, nous étions en mesure de faire un PSNR et échouer si elle dépassait un certain seuil. Cela peut ou peut ne pas fonctionner selon vos données, mais quelque chose de similaire pourrait être possible.