URL: https://linuxfr.org/news/code-trouver-les-erreurs Title: [code] Trouver les erreurs Authors: Jiehong BAud, Snark, Benoît Sibaud, palm123, RoPP, M5oul, ZeroHeure, rootix, TBTB et Nicolas Boulay Date: 2015年01月12日T15:34:00+01:00 License: CC By-SA Tags: tests, ingénierie, génie_logiciel, bug, ada, firefox et c++ Score: 70 Le récent problème d'OpenSSL et de ses failles peut nous avoir rendu dubitatifs quant à la _supposée_ meilleure qualité des logiciels libres. Cette dépêche se veut un petit rappel sur ce qui impacte la qualité d'un programme informatique, et de ce que l'on peut en déduire pour la communauté libre, et *open source*. ---- [Heartbleed : petit florilège des journalistes](http://linuxfr.org/users/perdu/journaux/heartbleed-petit-best-of-des-journalistes) [Buts de LibreSSL](http://www.openbsd.org/libressl/goals.html) [Code Reviews: Just Do It](http://blog.codinghorror.com/code-reviews-just-do-it/) [Journal DLFP sur le rapport Coverity 2013 (et le rapport Trustwave Global Security 2013)](http://linuxfr.org/users/khivapia/journaux/qualite-du-logiciel-le-logiciel-libre-est-bien-meilleur-que-le-proprietaire) ---- ## État des lieux des méthodes utilisées dans l'industrie Depuis que l'informatique existe (soit environ 40 ans), les erreurs ont toujours existé. L'eau coulant sous les ponts, des méthodes informelles, puis formelles ont vu le jour : tests de non-régression, tests unitaires, revue de code informelle, prototypes, etc. Ces dernières années, les tests unitaires se généralisent, et le programmeur moyen se sent bien plus à l'aise pour changer son code quand les tests unitaires disent que tout va bien. Est-ce la panacée ? Est-ce suffisant ? L'industrie s'est posé la question depuis longtemps (tels qu'IBM, Microsoft, la NASA, etc.). Voici un graphique[1] récapitulant le taux d'erreurs détectées grâce à plusieurs méthodes (NdM: données antérieures à 2004). Les noms sont masqués dans le graphique, mais ils sont détaillés en dessous de celui-ci : cela permet de deviner et surtout d'être surpris : ![Taux d'erreurs par méthode](https://www.anonimg.com/img/3db1b49f4c7813cae9b4d7e15aed7933.png) ``` A: Revues de conception (informel) B: Inspection de conception (formel) C: Revue de code (informel) D: Inspection de code (formel) E: Prototypage F: Vérification personnelle de code G: Tests unitaires H: Test d'une nouvelle fonction (ou d'un nouveau composant) I: Tests d'intégration J: Tests de régression K: Tests systèmes L: Béta test à faible volume (moins de 10 sites) M: Béta test à haut volume (plus de 1000 sites) ``` ## Combien d'erreurs ? À partir de combien d'erreurs peut-on dire qu'un logiciel est de bonne qualité ? De manière générale, ce taux varie entre 1 et 25 défauts pour 1 000 lignes de code. La plupart des projets sont dans cette plage, mais certains projets sont mieux ficelés que d'autres : le taux de défauts au sein du code de la navette spatiale américaine est estimé à zéro sur 500 000 lignes de codes [2]. ## Répartition des erreurs Avec de telles données, il est possible de supposer, en première approximation, qu'un projet a un niveau de défaut de dix pour 1 000 lignes de code. De fait, il semble naturel de penser qu'il y a sûrement un défaut de caché toutes les 100 lignes. L'erreur de ce raisonnement est l'hypothèse d'équirépartition des erreurs, qui est malheureusement fausse. En effet, on retrouve l'adage du « 80/20 », c'est-à-dire que 80 % des défauts se retrouvent dans 20 % des classes ou fonctions [3]. Par exemple, Carpers Jones a identifié 31 classes sur les 425 du code de l'*Information Management System* d'IBM qui étaient un nid d'erreurs particulier. Elles ont été corrigées ou ré-écrites, ce qui a diminué les coûts de maintenance de 45 % et divisé par dix le taux de plaintes (pas juridiques) venant des utilisateurs. ## Combos Le graphique précédent montre que certaines méthodes sont meilleures que d'autres, tels qu'une bêta très distribuée, le prototypage, l'inspection de code formelle, l'inspection de la conception de manière formelle ou encore les tests unitaires. Néanmoins, chaque méthode ne va pas détecter les mêmes défauts qu'une autre. Certaines ont des lieux communs, d'autres se complètent. ## Conclusions Grâce à ces quelques informations, on peut en tirer quelques conclusions pour les projets que l'on peut trouver dans la communauté. ### Le projet écrit par une seule personne Développer seul n'est pas simple, car la majorité des méthodes qui marchent le mieux demandent la participation d'autres personnes. Néanmoins, prototyper son architecture (et le publier), ainsi que des tests unitaires permettent de se distinguer et de sauver les meubles (si la couverture des tests est proche de 100 %, en terme de lignes testées, non de fonctions). Quelques utilisateurs peuvent également grandement améliorer le taux de détection d'erreurs, ce qui encourage à faire des versions assez rapidement. Néanmoins, écrire des tests unitaires est gourmand en temps, pour un résultat plutôt contrasté : passer plus de temps à prototyper et écrire quelques tests mieux choisis est à considérer. ### Le projet par une équipe réduite, mais viable (moins de 10 personnes) En plus des points précédents, il devient possible de mettre en place une inspection de code formelle (basée sur des listes de choses à vérifier, avec retours d'information et amélioration des dites listes) sur la conception et le code. L'idée étant que l'algorithme est soumis aux autres, dont les retours sont pris en compte, de même avec le code. Ce n'est pas forcément plus lent, puisque le nombre de défauts à corriger sera plus réduit par la suite et corriger tardivement est souvent long et coûteux [4]. ### Projets de grande envergure C'est exactement pareil, mais les choses peuvent tourner plus facilement. ### Code déjà écrit, tout le monde peut le lire ! La lecture de code déjà écrit n'est que très rarement aussi efficace que l'inspection formelle avant publication de code par plusieurs personnes. La NASA a déterminé que cela permettait de trouver environ 3 défauts par heure d'effort. On peut supposer qu'un programmeur moyen n'est pas aussi bon qu'un programmeur moyen de la NASA, ce qui tend à demander énormément de temps et d'envie. Mais, l'histoire d'OpenSSL nous a montré que le temps et l'envie ne semblent pas vraiment être là, une fois le code écrit. ### *Fuzzing* ou test de résilience En sécurité informatique, il est possible de tester un logiciel dans des conditions non prévues lors de la conception et d'en observer le fonctionnement, c'est ce que l'on appelle des [tests à conditions aléatoires](https://fr.wikipedia.org/wiki/Fuzzing), mais il peut être préférable de les nommer *tests de résilience*. Tester la résilience d'un logiciel est relativement simple et ne demande pas d'en connaitre les moindres rouages, mais ce n'est pas toujours quelque chose de voulu. Voici deux exemples opposés qui permettent de comprendre que c'est plus un choix de conception, mais pas nécessairement une manière d'améliorer la qualité du code (cela reste un test automatique, avec ses avantages et défauts). Firefox 35 vient de sortir, et tester sa résilience est bienvenu : si une page html est mal-formée, il est plus sain d'essayer de l'afficher tout de même, que de planter en perdant les onglets de l'utilisateur. De manière générale, les algorithmes de cryptographie se veulent résilients aux attaques et, pourquoi pas, aux défauts d'implémentation. À l'opposé, une machine à découpe plasma a tout intérêt à s'arrêter si une donnée non conforme se présente : il en va de la sécurité de l'opérateur. De manière générale, dans le domaine de la médecine, il est préférable que le programme soit correct plutôt que résilient. On voit ici la mise en exergue de ce que « qualité » signifie d'un projet à l'autre. ### Mot de la fin Cette dépêche vous apporte simplement quelques chiffres pour y voir plus clair dans le monde de la qualité des logiciels en général. Pour en savoir plus, il vous est conseillé de lire [« Code Complete » par Steve McConnel (en anglais)](https://en.wikipedia.org/wiki/Code_Complete). ## Notes [1] : Mise en forme de la table 20-2 de *Code Complete* par Steve McConnel, deuxième édition (2004). Les barres d'incertitudes représentent le minimum et le maximum d'erreurs détectées pour chaque méthode, ce qui n'est pas forcément symétrique (réalisé avec [matplotlib](http://matplotlib.org/)) [2] : d'après Fishman, en 2006 [3] : Endres 1975, Gremillion 1984, Boehm 1987b, Shull et al 2002 [4] : *Code Complete* par Steve McConnel, deuxième édition (2004), p. 474.

AltStyle によって変換されたページ (->オリジナル) /