Ce contenu vous est offert gratuitement, il ne vous reste plus de contenu à consulter.
Créez votre compte pour consulter 3 contenus gratuits supplémentaires par jour.
Sylvain Hallé est titulaire de la Chaire de recherche du Canada en spécification, test et vérification de systèmes informatiques, et professeur au département d’informatique et de mathématique de l’UQAC depuis 2010.
Sylvain Hallé est titulaire de la Chaire de recherche du Canada en spécification, test et vérification de systèmes informatiques, et professeur au département d’informatique et de mathématique de l’UQAC depuis 2010.

Bataille navale dans vos logiciels

Page UQAC
Le Quotidien
Article réservé aux abonnés
CHRONIQUE / La prochaine fois que vous ferez une partie de Battleship avec l’un de vos amis, ayez une pensée pour tous les développeurs informatiques qui fabriquent les logiciels que vous utilisez.

Sylvain Hallé est titulaire de la Chaire de recherche du Canada en spécification, test et vérification de systèmes informatiques, et professeur au département d’informatique et de mathématique de l’UQAC depuis 2010.

Quel rapport, me direz-vous ? Repensez à tous les appareils, applications et logiciels que vous avez utilisés récemment. Ont-ils tous fonctionné parfaitement, ou avez-vous été la victime malchanceuse d’un pépin technique fortuit que l’on pourrait qualifier de bogue  ? Si tel est le cas, félicitations : dans ce jeu de bataille navale bien particulier, vous avez vécu l’équivalent informatique d’un navire coulé !

Lorsqu’on les étudie un peu, on découvre que les logiciels actuels sont d’une impressionnante complexité. Composés d’instructions à l’usage des machines qui les exécutent (les fameuses lignes de codes), ces programmes accomplissent des fonctions extrêmement diverses. Cela fait le bonheur des consommateurs, mais s’avère un sérieux casse-tête pour ceux qui sont chargés de les écrire – nos valeureux programmeurs de tout acabit.

Comment en effet s’assurer qu’un logiciel remplisse exactement la fonctionnalité attendue, et ce, peu importe ce que l’utilisateur puisse en faire ? Pour illustrer la difficulté de cette tâche, imaginez un appareil très simple ne proposant qu’un levier et deux boutons : un rouge et un vert. Son utilisateur doit appuyer sur les boutons, puis actionner le levier. De combien de manières différentes peut-on utiliser ce système ? Calculons ensemble.

Examinons d’abord ce qui se passe si l’utilisateur appuie sur un seul bouton avant d’actionner le levier. Il peut s’agir soit du bouton vert (V), soit du bouton rouge (R) : il y a donc deux manières différentes d’interagir avec le système. Que se passe-t-il si l’utilisateur a le droit d’appuyer deux fois sur un bouton ? La première fois, il peut s’agir du vert ou du rouge, tout comme la deuxième : on a donc 2×2=4 manières possibles de choisir deux boutons : R-R, R-V, V-R et V-V. Et pour trois boutons ? Je vous épargne l’énumération des 2×2×2=8 manières possibles de le faire.

Deux, quatre, huit ; on réalise que, plus l’utilisateur appuie sur des boutons, plus le nombre de combinaisons possibles augmente – en fait, il double chaque fois qu’on allonge la séquence d’une nouvelle action. Pour 10 « clics », on en est déjà à 1024 séquences possibles ; après 30 clics, on dépasse le milliard. Et rappelons que nous avons affaire à un système absolument simpliste, où l’utilisateur ne peut actionner que deux boutons !

Transposez ce calcul à une application réelle composée de dizaines de menus, de boîtes de texte et de choses à cliquer, et vous comprendrez mieux le fardeau colossal reposant sur les épaules des développeurs informatiques, pour lesquels tester un logiciel ressemble bel et bien à un combat naval d’un genre très spécial. Ils voient devant eux la grille d’un immense océan virtuel, où chaque minuscule case représente l’une des myriades de manières différentes d’exécuter leur programme.

Sous certaines de ces cases se trouvent certainement (nécessairement !) des bogues : des situations où le programme réalisé ne fait pas exactement ce que l’on attend de lui. Mais lesquelles ? On ne peut le savoir qu’en lançant une torpille – c’est-à-dire un test – sur l’une d’elles. Coup dans l’eau ? Le programme fonctionne comme prévu. Touché ? On a trouvé un bogue, que l’on s’attelle ensuite à comprendre et à corriger.

Qu’il reste des recoins inexplorés où des bogues ayant échappé aux testeurs est pratiquement inévitable. Tout comme à Battleship, un bon programmeur doit faire preuve de logique et d’intuition afin de choisir intelligemment les tests qu’il souhaite exécuter. C’est précisément le sujet de mes travaux de recherche à l’UQAC : inventer de nouvelles techniques visant à faire de nos développeurs des marins compétents pouvant voguer avec confiance à travers l’océan des bogues.

Venez en discuter le mercredi 28 avril dès midi sur Zoom.