Bonjour à tous,
tout est dans le titre, j'aimerai savoir si vous utilisez une méthode particuliere pour valider un logiciel.
boite noire pour les fonctions (test de toutes les valeurs possible et analyse des résultats)?
boite blanche pour les procedures (ex : void toto(void)) ?
ecrivez vous un code de test par fonction?
merci
curieux pour un sujet aussi important il n'y a pas foule
Bonjour.Envoyé par morpheus87
curieux pour un sujet aussi important il n'y a pas foule
C'est plutôt un sujet tellement vaste qu'il dépend du domaine d'application.
Exemple: un programme de contrôle de trajectoire n'a rien à voir un programme de comptabilité.
Et aussi de la façon de programmer: un esprit tordu fera des programmes tordus.
Alors, quels tests?...
A+
Il n'y a que dans le dictionnaire où 'réussite' vient avant 'travail'.
Une technique classique et très utile (mais très chiante...) consiste à préparer tous les jeux de tests "simples" possibles et à les tourner avec une procédure de vérification à chaque fois.
En Java, c'est le principe de JUnit, si j'ai bon souvenir.
C'est extra pour tester rapidement la non-régression suite à des modifs, etc. Mais c'est vraiment un travail titanesque quand le projet est un peu grand et/ou interconnecté.
merci pour vos reponses
abracadabra75, à ton stade de reflexion tu testes un produit fini...
moi je parle de debugger les fonctions, passage d'argument...
Faith, oui et en C y a Cunit, tu as vu dans le mille c'est çà qui m'interesse.
Re.
Leur limite immédiate est qu'on ne peut tester que les cas déjà connus et ce qu'on peut raisonnablement imaginer.
Certes, ce n'est pas inutile: cela dégrossit le problème, et évite les coup bas triviaux.
Mais la complexité des applications empêche de prévoir toutes les combinaisons qui conduisent au 'unpredictable result'.
Quant aux tests en cours de rédaction d'un programme, à moins d'être borné, on voit bien lors de la mise au point si le résultat obtenu est celui attendu. Ou alors, je ne comprends pas ce que tu veux dire.
A+
Dernière modification par abracadabra75 ; 05/02/2011 à 10h01.
Il n'y a que dans le dictionnaire où 'réussite' vient avant 'travail'.
De toute façon un test de validation ne peut se faire que sur un logiciel suffisamment fini pour être fonctionnel (version bêta voire alpha très avancée) : attention je n'ai pas dit exempte de bugs, mais capable de faire les tâches pour lesquelles il est prévu dans les cas "normaux" ; par là, j'entends sans chercher à provoquer le bug (par exemple : une valeur en entrée qui conduirait à une division par 0 ; même si ce cas est bien sûr à tester pour la validation du logiciel).
Le test de fonction en cours de développement est bien entendu possible (et utile) mais avoir toutes les fonctions de ton logiciel qui fonctionnent (c'est le cas de le dire) de façon autonome ne signifie pas que ton programme fonctionnera dans sa globalité.
Si tu parles des tests de non-régression, je t'assure que c'est très difficile à voir dès que ton appli est un peu complexe (et ça nécessite des heures de test).
Personnellement, à chaque fois que c'est possible, j'essaye d'écrire mes tests avant le code. Bien sûr, parfois, le projet n'est pas adapté à l'écriture de tests (réaliser une interface graphique ou Web, notamment).
bon d'accord
merci
