Est-il possible pour un programme ne peut pas trouver l'échec en utilisant des tests dynamiques, mais ont une faute?

Question

Est-il possible qu'un programme ne trouve pas l'échec en utilisant un test dynamique, mais est en faute? un exemple simple?

Aidez s'il vous plaît! Merci.

Answer 1

Oui. Les tests ne peuvent prouver l'absence de bugs pour ce que vous avez testé. Les tests dynamiques ne peuvent pas couvrir toutes les entrées et sorties possibles dans tous les environnements avec toutes les dépendances.

Tout d'abord, il suffit de ne pas tester le code en question. Cela peut être vérifié en vérifiant le coverage de votre test. Même si vous obtenez une couverture de 100%, il peut toujours y avoir des défauts.

La prochaine étape consiste à ne pas vérifier tous les types et toutes les plages d'entrées possibles. Par exemple, si vous avez une fonction qui analyse un mot dans une chaîne, vous devez vérifier ...

• Le mot au début de la chaîne.
• Le mot à la fin de la chaîne.
• Le mot au milieu de la chaîne.
• Une chaîne sans le mot.
• La chaîne vide.

Ceux-ci sont connus comme boundary conditions et comprennent des choses comme:

• Les nombres négatifs
• Les chaînes vides
• Null
• très grandes valeurs
• Décimales
• Unicode
• fichiers vides
• fichiers très volumineux

Si le code en question maintient l'état, peut-être dans un objet, peut-être dans des variables globales, vous devez vérifier que l'état ne soit pas corrompu ou interférer avec les courses suivantes.

Si vous effectuez un traitement en parallèle, vous devez tester un nombre illimité de possibilités d'interblocages ou de corruption résultant d'une tentative de faire la même chose en même temps. Par exemple, deux processus essayant d'écrire dans le même fichier. Ou deux processus en attente d'un verrou sur la même ressource. Est-ce qu'ils verrouillent seulement ce dont ils ont besoin? Est-ce qu'ils abandonnent leurs serrures dès que possible? Une fois que vous avez testé toutes les façons dont le code est censé fonctionner, vous devez tester toutes les failles dans lesquelles il peut échouer, qu'il échoue gracieusement avec une exception (au lieu de la poubelle), qu'une erreur le laisse corrompu état, et ainsi de suite. Comment gère-t-il les échecs de ressources, comme ne pas se connecter à une base de données? Cela devient particulièrement important de travailler avec des bases de données et des fichiers pour s'assurer qu'un échec ne laisse pas les choses partiellement altérées.

Par exemple, si vous transférez l'argent d'un compte à un autre, vous pouvez écrire:

my $from_balance = get_balance($from); 
my $to_balance = get_balance($to); 

set_balance($from, $from_balance - $amount); 
set_balance($to, $to_balance + $amount); 

Qu'advient-il si le programme se bloque après le premier set_balance? Que se passe-t-il si un autre processus modifie l'un ou l'autre solde entre get_balance et set_balance? Ces types de problèmes de concurrence doivent être pensés et testés.

Il existe différents environnements dans lesquels le code peut s'exécuter. Différents systèmes d'exploitation. Différents compilateurs. Différentes dépendances Différentes bases de données Et tous avec des versions différentes. Tout cela doit être testé.

Le test peut simplement être erroné. Cela peut être une erreur dans le test. Cela peut être une erreur dans la spécification. Généralement, on teste le même code de différentes manières pour éviter ce problème.

Le test peut être correct, la spécification peut être bonne, mais la fonction est incorrecte. Ce pourrait être un mauvais design. Ce pourrait être une mauvaise idée. Vous pouvez argumenter que ce n'est pas un "bug", mais si les utilisateurs ne l'aiment pas, il doit être corrigé.

Si vos tests utilisent beaucoup de moqueurs, il se peut que vos mocks ne reflètent pas la façon dont se comporte réellement ce qui est en train de se moquer.

Et ainsi de suite.

Pour tous ces défauts, les tests dynamiques restent les meilleurs que nous ayons pour tester plus de quelques dizaines de lignes de code.