Bonjour,
Comment tester qu'un programme est fiable?
merci infiniment
Version imprimable
Bonjour,
Comment tester qu'un programme est fiable?
merci infiniment
Tout dépend ce que tu entends par fiabilité :
- Assurer que les données ne sont pas perdues ?
- Invariance des résultats ?
- Consommation mémoire ?
- Vitesse d'exécution ?
- Tolérance aux pannes de l'environnement (réseau, bdd) ?
- Capacité à monter en charge ?
- Capacité à tourner pendant plusieurs semaines sans planter ?
.........
Bref, c'est hyper vaste.
Si tu ne nous en dit pas un peu plus, on ne pourra pas t'aider...
euh, si je peux me permettre :)
Pour moi, il faut faire la nuance entre :
Test de fiabilité et test de robustesse :)
Je joue peut-etre sur les mots, mais pour moi, la fiabilité d'un logiciel est un facteur de confiance que l'on peut accorder au logiciel par rapport aux informations qu'il fournit !!!
Dire que ton logiciel est fiable est pour moi, prouver que dans toutes les situations d'utilisation, les données produites seront exactes :)
Après, je distinguerais cela avec la robustesse, qui est la capacité de ton programme à resister à toutes les situations "imprévues", la robustesse des sauvegardes en cas de plantage, etc... (je ne reprends pas les arguments de Gold bug car ils sont "excellents" et pertinents :)
voilà
Sinon un bon moyen pour tester la robustesse : passer le programme à quelqu'un de la famille, lui expliquer en gros ce qu'on peut faire avec et le lâcher sur le chef d'oeuvre. Les testeurs totalement externes au projet finissent toujours par tomber sur une situation que l'on n'avais absolument pas prévu. :roll:
De préférence un bébé, c'est plus drôle... ou même le chat :aie:Citation:
Envoyé par smyley
+2 je rejoins totalement Smyley et Tomlev ( et blague a part ca marche tres bien !):mouarf:
Car en plus de demontrer qu'il y a pleins de truc auquel on n'avait pas pensé qui marchent pas comme on veut
On a souvent droit a la bete question "Comment je peux faire ca" dont la reponse sera généralement "heeeu'" je n'y avais pas pensé non plus
Quiter le monde codé pour le monde reel est une experience passionante riche en aventure mais parfois douloureuse
Si on se réfère aux normes qui se rapportent à la conception de logiciels "fiables", par exemple pour l'aéronautique, le spatial ou le médical, la fiabilité est essentiellement une conséquence de la tracabilité des besoins à travers toutes les étapes de la conception jusqu'au code source, tests unitaires et tests fonctionnels.
Cette traçabilité est sensée garantir que l'on a tout testé. Dans certains cas, les niveaux d'exigence sont élevés : par exemple, les tests devront passer sur TOUTES les lignes du code. Pire, il faudra apporter la preuve que toute bibliothèque utilisée (y compris l'OS ou les bibli du compilateur) satisfont aux mêmes exigences !!!
Salut Grafito
Rien à faire ces notions académique me font toujours un peu sourire en ce qui concerne la fiabilité d'un logiciel !
Je pense qu'il y a autant de distance entre un logiciel et un Airbus qu'entre un humain et une poupée gonflable !
Quels que soient les review effectues (et souvent extremements lourds comme tu le signale tres bien) RIEN ne vaut le test du chat !
Et pour un logiciel il est souvent plus efficace de faire d'abord le test du chat avant de plonger dans des review for ever !
Mais tu a raison il existe des methodes de test qu'on ne doit pas négliger !
cela dit, j'aimerais pas trop que l'airbus soit testé par un chat :)
Mais, j'y vais de ma petite expérience ayant travaillé pour Airbus à Toulouse sur un calculateur principal de l'A340 500/600 dans les années 1998 :)
je peux te dire que les phases de tests sont nombreuses :
1 - Phase de test unitaire ==> Toutes les fonctions sont testées avec les cas extrèmes, robustesse, variable null, etc, paramètres aberrant, etc..
2 - Phase de test fonctionnel sur baie ==> Là, on test que le comportement correspond à ce qu'on attend.. on prend parfois un tournevis (à l'époque on le faisait) pour faire un bug dans le calculateur et voir si on part bien dans le mode adéquate... on va modifier la table d'allocation du code segment (en mode protégé pour ceux à qui ca parle) pour vérifier que sur des segments fault, on part bien dans le code qui gère l'exception etc...
3 - Phase de test en simulation ==> ON envoie le logiciel (ou le code mis sur une OBRM (carte mémoire pour simplifier) au département simu, et il teste cela avec son simulateur...
4 - Test avion
Bref, comme tu peux le voir, les tests sont suffisement lourds pour qu'un minimum de bug passe aux travers :)
Evidemment, processus de test dans l'embarqué et processus de test dans le logiciel "non" embarqué sont différents... A partir du moment ou la vie de quelqu'un est potentiellement en danger du fait de l'utilisation d'un logiciel, il est préférable d'avoir un minimum de test (genre le test pour le problème du regulateur de vitesse bloqué il y a quelques années :)
Voila pour la participation du matin "au débat" :)
Le terme "académique" s'applique à la conception de la norme.Citation:
Olibara : Rien à faire, ces notions académique me font toujours un peu sourire en ce qui concerne la fiabilité d'un logiciel !
Malheureusement, dans certains cas, tu dois appliquer la norme et subir un audit externe qui en contrôle l'application.
Ces normes imposant un processus de développement si lourd qu'il faut multiplier les coûts d'un facteur supérieur à 10, on peut légitimement se demander si l'énergie dépensée pour se conformer à la norme ne serait pas mieux employée pour améliorer la qualité du design et du codage et celle des procédures de tests.
:king:Citation:
Ces normes imposant un processus de développement si lourd qu'il faut multiplier les coûts d'un facteur supérieur à 10, on peut légitimement se demander si l'énergie dépensée pour se conformer à la norme ne serait pas mieux employée pour améliorer la qualité du design et du codage et celle des procédures de tests.
Tu a parfaitement exprimé ce que je voulais dire !
+1 Graffito
Sauf que ceux qui décide de faire ce genre de choix (plein d'argent pour la qualité, test, validation etc), ne sont pas les développeurs ni meme rarement chef de projet... et qu'en France, on considère les développeurs dans les grosses entreprises comme des "connards" de base qui ne sont bons qu'à pisser du code... et que seuls les postes de chef de projet et d'encadrement ont une certaine valeur à leur yeux :) , hélas :)
Mais je me bats au quotidien pour rétablir l'ordre des choses.. à savoir, sans développeur, les autres ne servent à rien :)
J'aime beaucoup l'image jointe ! :mouarf:
Ouais, bien dit ! c'est nous qu'on est les meilleurs :mouarf:Citation:
Envoyé par theMonz31
En attendant, vous avez fait peur à abbd, il est pas revenu :aie: