Tu veux dire carrément ignorée dans le domaine amateur... ;-)Envoyé par Neilos
De toutes façons, un soft sans bugs, ça n'existe pas : le but des tests est de garantir que les bugs les plus critiques (les "évènements redoutés") ont une probabilité d'apparition acceptable (genre <10e-13) sur la durée d'utilisation du système. Ni plus, ni moins.
Prenons le cas d'une pompe médicale (genre pompe à morphine) : un évènement redouté peut être "non-délivrance d'une dose". C'est triste pour le patient, mais (heureusement ou hélas, suivant le point de vue) il peut toujours crier et se manifester, et donc avoir son médicament. Bref, c'est grave, mais non critique. Si ça arrive mettons une fois sur 10.000 demandes, c'est "acceptable", car ça ne met pas la vie du patient en jeu même si ça a d'autres effets néfastes. N'oublions pas que ce genre de pompe est utilisée par des patients conscients.
Par contre, un autre évènement redouté est "délivrance d'une dose trop forte" : là, c'est critique, car le patient peut en mourir ! Si le risque est d'une fois sur un milliard, c'est tolérable s'il n'existe qu'une seule pompe : si l'on délivre au maximum une dose par heure, ça revient à un accident tous les 1000 siècles d'utilisation. Mais avec l'augmentation du nombre de pompes en service, ça devient inacceptable : si 1 million de pompes sont en service, il y a un risque d'accident tous les 1,2 mois !!
Tu vois quelques bases en génie logiciel, puis le reste, c'est sur le tas. C'est la preuve aussi que ce n'est pas encore vraiment "implanté" dans les moeurs...Envoyé par say
Bien sûr ! En découpant "à la louche", tu as 1/3 du dev en specs, 1/3 en codage, 1/3 en tests. Suivant la criticité du projet, les tests peuvent même être beaucoup plus importants que les specs et le codage réunis !!Envoyé par say
Ca consiste à tester en connaissant l'implémentation, et en vérifiant tous les flux d'exécution possibles d'une fonction/module donné(e).Envoyé par say
En gros, si ta fonction possède 3 cas d'exécution, ça fait 3 jeux de test à dérouler, chaque jeu déclenchant une branche d'exécution particulière. Ca permet également d'éliminer des cas de tests inutiles (ex : branche déclenchée sur une intervalle de valeurs).
Ce n'est en général applicable que sur des fonctions plus ou moins élémentaires, et ça peut être complété par d'autres éléments de test supplémentaires.
En analyse boîte noire, tu ne sais pas COMMENT est codée la fonction ou le module, et tu t'en moques (d'ailleurs, la personne écrivant les tests boite noire ne doit JAMAIS avoir vu le code). Tu testes suivant les spécifications prévues, y compris les cas dégradés connus.
Partager