Version imprimable
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
Certaines entreprises ont une méthode infaillible pour tester les programmes : ils laissent faire les clients.
Pour ma part, en l'absence de procédures particulières ou de moyen d'en mettre en place, c'est souvent des tests fonctionnels + tests aux limites + tests des cas particuliers identifiés + quand c'est possible déverminage en situation réelle par un non-développeur et si possible quelqu'un qui n'a pas participer au dossier.
Ce système a de très grosses limites mais je n'ai pas trouvé mieux du fait que les commerciaux n'arrivaient pas à intégrer que la phase de test devait se vendre dans la partie développement. C'était un combat au quotidien que je n'ai jamais pu gagner. Du coup c'est effectivement souvent le client qui fait les tests à ses dépends.
merci pour ta reponse.
la procedure de ton entreprise est je pense utilisé par la majorité.
debugage chez le client=> non merci
curieux, pour un sujet si important il n'y a pas foule...8O
Debuggage chez le client, encore. Il y a toujours une phase de mise au point plus ou moins longue chez le client.Citation:
Envoyé par morpheus87
Le problème, à mon avis, c'est quand c'est Debuggage par le client
Je confirme, c'est une horreur.Citation:
Envoyé par sevyc64
Je suis MOA et je ne suis pas développeur (je touche à ça lors de mes temps libres, parce que j'estime que c'est essentiel de comprendre un minimum le métier du développeur dans mon domaine). En tant que MOA, on vérifie que le programme fonctionne correctement suivant une batterie de tests (en gros, on tente de couvrir l'ensemble des situations possibles connaissant les besoins et activités du client). Dans le secteur bancaire, c'est essentiel, je n'ose pas imaginer la catastrophe si on met un truc plein de bugs en production vu les montants en jeu.
Et là, on est assez souvent mal : on a l'impression de faire le boulot des développeurs. Et parfois, on a même l'impression de mieux comprendre d'où vient le problème (étant donné qu'on isole le bug et qu'on teste dans tous les sens pour bien décrire le problème) et parfois on imagine la raison pour laquelle ça foire et on se demande comment c'est possible vu que ça implique, par exemple, d'utiliser deux algo différents pour calculer le même type chose mais dans deux endroits différents (expérience vécue, et après avoir réfléchi sur le problème, les deux algos auraient dû être les mêmes).
Ceci dit, histoire de ne pas paraître pédant, prétentieux, ... (ce que je ne veux pas), il est clair que le progiciel (et donc son développement) est un monstre dans son domaine (gestion des crédits structurés), ensuite ce n'est pas forcément évident de programmer correctement des concepts complexes (parfois, les spec sont mal foutus, et ça, ça vient de chez nous) et enfin, c'est toujours facile de critiquer quand on n'a pas réellement les mains dedans...
le problème des tests "boite noire" est qu'il faut avoir toutes les valeurs possibles...
Mais que les valeurs possibles peuvent être dépassées par la réalité...
Exemple : on prévoit qu'un champ contiendra 8 caractères..
Donc on teste les chaînes ASCII de 8 caractères...
Mais si jamais , au lieu d'un caractère "normal", on entre par exemple une touche de fonction, une flèche, ou je ne sais pas quoi, cela sera peut-être saisi, mais f.utra peut-être le boxon derrière....
Un excellent conseil que j'ai eu d'un ingénieur-agrément en biomédical (celui qui décidait si un logiciel était correct au niveau de l'Assitance Publique) : avant de vérifier la fonctionalité, faire un test d'environ le double du temps en faisant n'importe quoi, sans regarder l'écran... Cliquer au hasard, taper sur le clavier au hasard, etc etc..
Si le logiciel marche toujours et n'a pas provoqué de m.rdes un peu partout ailleurs, on a déà passé plus de 70% : c'est robuste et est contenu...
Ensuite, pour la fonctionalité, il est souvent difficile de fonctionner "boite blanche" (sauf à bas niveau, ou au contraire tout en haut).
Moi personnelement j'effectue toujours une phase de test "crash" (voir plus haut), et ensuite je prend un "client" expert, et je lui demande d'explorer tous les cas les plus saugrenus... Pas besoin de listes exhaustives... Les cas limites suffisent...
bjr, je ss etudiant en informatique M2 et j'ai comme PFE les tests d'intégration sur les logiciels oo je doit le faire en java mai je ss bloqué j'ai pa trouvé assez de documentation je sai pa quel stratégie quel sont les outils a utiliser..si vous pouver m'aidez svp au moins par la documentation car j'ai pa trouvé une bon documentation sur sa...merci d'avance
Salut,
Le type de tests dépend de la qualité qu'on souhaite/doit atteindre.
Qualité pouvant se ramener au nombre et à la gravité des défauts que vous ne voudrez pas voir en production. Dit autrement, on teste pour limiter les risques de dysfonctionnement résultant des éventuels défauts.
De ce fait, le plan de test d'un serveur Web construit pour une petite PME avec un framework où le spécifique se cantonne à la présentation n'aura pas la même teneur que celui du logiciel de contrôle d'une navette spatiale ou d'un Airbus...
Et que si faire faire les tests par ses clients peut paraître discutable "dans l'absolu" il pourra être "justifié" dans certains cas/contextes.
-W
:ccool:
la voix de la sagesse :mrgreen:
Une partie des tests peut effectivement être faite par le client. Cela se fait en accord avec celui-ci, accord généralement conclu dès la signature de la commande et qui s'appelle généralement Phase de Validation.Citation:
Envoyé par wiztricks
C'est justifié par l'expérience et les spécificités métier du client qui a des habitudes de travail ou des procédures à suivre au quotidien que le développeur n'est pas forcément censé connaitre ou maitriser.
Par contre, il est parfaitement discutable et inimaginable (du moins, je ne pouvais l'imaginer avant de l'avoir vécu) de laisser faire Les Tests au sens général par le client et qui-plus-est à l'insu de son plein gré.
Par exemple, il est parfaitement impensable (là encore c'est du vécu) de faire une modification directement chez le client, un vendredi soir à 19h30, sans que personne soit au courant, sans tester, et que cette modification plante dès le lundi matin, toute la chaine de production de l'usine. La personne ayant fait la modif, n'avait, bien sur, rien noté, et était absente dès le lundi matin pour déplacement à l'étranger pour 2 semaines alors qu'une simple compilation du code lui aurait directement mis en évidence qu'elle avait fait n'importe quoi.
A mon sens, ce n'est peut être pas un problème de personne mais surtout un problème d'une organisation qui à défaut d'avoir su sensibiliser ses troupes sur les dangers de certains raccourcis n'est même pas capable de s'en protéger.Citation:
Envoyé par sevyc64
Et en général la capacité d'une organisation a remplir ses missions est de la responsabilité du patron et non des "personnes" qu'il emploie.
Notez que lorsque j'écrivais "on teste pour limiter les risques de dysfonctionnement résultant des éventuels défauts", j'ai volontairement omis de dire que les tests ont un coût.
La décision d'en faire plus ou moins est un arbitrage "politique" et non technique. Le technicien pourra recommander, le politique lui dira "débrouilles toi avec çà" et tant qu'il n'aura pas été viré pour incompétence, il aura la légitimité pour de tels arbitrages.
Une des difficultés est que la non qualité (pas assez de tests) aura peut être un coût plus tard difficile à tracer: l'équipe d'exploit. croulera petit à petit dans le traitements des bugs et incidents parce que l'accumulation de la dette technique devient ingérable.
Par contre si on teste trop, çà coûtera tout de suite et sans certitude d'en mesurer une économie plus tard.
Mettez vous à la place du politique: avec des tests suffisants, il ne pourra réaliser que 5 projets par an et risquer de se mettre les métiers à dos. Par contre, en testant moins, il pourra en faire 10. Mieux, en pleurant un peu, il pourra même convaincre les métiers de faire eux mêmes les tests.
Comme les vrais dégâts de l'accumulation de la non qualité ne seront visibles que dans 2 ans ou plus, çà lui donne le temps de voir venir.
- W
PS: hélas, ce n'est pas de la science fiction.