Discussion :

[Mac LAK]

Je me rend de plus en plus compte que les tests c'est une grosse "science" dans le domaine de l'informatique...trop souvent négligée (et je suis le premier à le faire), surtout dans le domaine "amateur".

Tu veux dire carrément ignorée dans le domaine amateur... ;-)

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 !!

C'est étonnant, c'est très pointu et pourtant j'ai jamais étendu de formation spécifique.

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...

Dès ce cas, faut-il aussi planifier le développement de tests dans la conduite du projet?

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 !!

De plus, qu'est ce qu'une analyse Boite Blanche?

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).
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.

[Caine]

La phase de tests (ou validation) dans des projets professionnels doit suivre un processus établi et rigoureux.

Il est important dès le cahier des charges et au long de la conception de lancer l'analyse, la faisabilité et le codage des outils/modules de test.

Si un projet prend 6 mois de développement, il est très problématique de s'apercevoir à deux mois de sa fin qu'il faut 4 mois pour développer les modules/outils de tests, les délais sont alors définitivement morts.

Pire, dans certains cas, il se peut que certains tests soient remis en question car infaisables.

L'analyse en boîte blanche permet aussi de garantir la cohérence des cas aux limites.

Imagines que ton application SGBD compte ses connexions, qu'elle doit en accepter au maximum jusqu'à 65535. Vu la complexité de ce test, il est évident qu'on se limitera à un sous ensemble de connexion, par exemple jusqu'à 249 connexions.

Maintenant dans le code, il y a un problème de perte de chiffre significatif sur la variable de MaxConnected.

En argument on la passe en "unsigned int", pour la stoquer dans un "unsigned char", les options de warnings étant désactivés par accident.

Le test jusqu'à 249 donne un comportement correct. Un anayse en boîte blanche conclut de rajouter un test à 65536 connexions => il ne passera pas.

Enfin, les programmes de tests doivent aussi être vérifiés, c'est pourquoi je préconise qu'ils soient le plus simple possible, pour que leur preuve soit simple. Attention, ce n'est pas toujours faisable, comme dans le cas de test multithread, multiprocess ...

Enfin, j'ai de quoi écrire un livre sur le sujet (avis aux éditeurs ).

[Neilos]

Enfin, j'ai de quoi écrire un livre sur le sujet (avis aux éditeurs ).

GOOO ! Si tu le fais je serais un des premiers à l'acheter !
Je suis pour l'instant étudiant et passionné. J'ai appris l'informatique sur le tas et je commence seulement à prendre conscience de l'importance des tests et surtout de la tache monumentale qu'ils représentent...bref un sujet qui va mériter de la réflexion !

[say]

re..
sans aller jusqu' à un livre...un tuto ou une première approche pour developpez, ça le fairait grave.

[Caine]

Il faudrait que je prenne le temps, vu votre motivation, ça peut se faire.

Mais ne soyez pas préssés, vu ma charge de travail et mes horaires, ce ne sera pas pour demain non plus

Il serait utile dans un premier temps de borner ce que vous souhaitez y trouver.

Après, ça dépendra de mon emploi du temps.

[Neilos]

Oui c'est sûr que écrire ne serait-ce qu'un simple tuto ça prend du temps.
Pour ma part ce qui m'intéresserait le plus :
les différents types de tests, au cours du post on a parlé des traditionnels cas aux limites, mais aussi les tests où l'on peut tester toutes les valeurs, etc
la prévision des tests dès le début du cahier des charges et la façon dont ils évoluent
les cas à prévoir les plus classiques. Ce qui a été évoqué dans ce post : l'algorithme du singe, une panne réseau...

Ce serait très intéressant, pour ma part l'idée d'un outil assistant la création de programme de test m'a effleuré. Pour l'instant je n'en ai pas le temps et peut être pas le niveau...à étudier.

[Caine]

Les outils de générations de programme de test sont difficiles à rendre génériques.

Mais il existe des moyens d'avoir des programmes simples surtout pour les tests unitaires.

Voici une ébauche du sommaire:

Les objectifs de la validation
Homme ou machine
Les problèmes liés à l'environement de validation.
Tests unitaires
Tests d'intégration
Tests de charge
Tests de déploiement.

ça évoluera bien sûr.

[Neilos]

Ton sommaire constitue un excellent début !

Pour ce qui est de l'écriture d'un outil de test j'ai une petite idée, mais ce n'est vraiment qu'une idée sur laquelle il faudrait que je réfléchisse !

[Caine]

Moi aussi j'ai quelques idées sur le sujet, mais il faut comprendre que ce genre d'outil sera souvent limiter à tester des modules indépendants.

Voici ce qui d'expérience me parait utile:
> L'outil possède une interface graphique. Un edit au milieu permet de visualiser le code source du module à tester (coloration syntaxique)
> Il possède un une vue arborescente qui remonte toute les fonctions privées comme publiques définies dans le module.
>Il permet de définir pour chacune des fonctions un domaine d'entrée de chaque argument et un résultat correct attendu.
>L'outil génère dans le langage cible le code correspondant aux tests définis branche par branche.
Chaque test de fonction consiste à donné aux arguments l'ensemble des valeurs définis et à afficher chaque appels. Egalement afficher le résultat ("Correct" ou "Incorrect") du test.

Par exemple, soit le fonction void Swap(int X, int Y);

L'opérateur peut définir comme domaine de test :
X:10,Y:20 => Correct: X:20, Y:10
X:0,Y:0 => Correct X:0,Y:0
X:65536,Y:50 =>Correct X:50, Y:65535

L'outil génère ceci (en C)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
 
#include <stdlib.h>
 
int main (void) {
 
const char KO[]="Incorrect";
const char OK[]="Correct";
char *Verbose = NULL;
 
int X=0,Y=0;
 
X=10;Y=20;
Swap(X, Y);
if ((X==20)&&(Y==10))
   Verbose = OK;
else
  Verbose = KO;
 
printf("Call to Swap(int X, int Y); X:10,Y:20 \n=> %s with result X:20, Y:10\n", Verbose);
 
X=0;Y=0;
Swap(X, Y);
if ((X==0)&&(Y==0))
   Verbose = OK;
else
  Verbose = KO;
 
printf("Call to Swap(int X, int Y); X:0,Y:0 \n=> %s with result X:0, Y:0\n", Verbose);
 
X=65536;Y=50;
Swap(X, Y);
if ((X==50)&&(Y==65536))
   Verbose = OK;
else
  Verbose = KO;
 
printf("Call to Swap(int X, int Y); X:65536,Y:50\n=> %s with result X:50, Y:65535\n", Verbose);
}

Penche toi sur la problématique de générer le code, rien que pour cet exemple simple. Puis prend tes fichiers sources, regarde quel code il faudrait générer pour les tester.

La difficulté de rendre totalement générique et intelligent ce genre d'outil va te venir à l'esprit.

AU passage, voilà un cahier de charge miniature, comment tu testerais ces exigences ?

Mais ça constitue un projet intéressant tout de même. Si j'avais plus de temps, il y a longtemps que je me serais amusé avec

[Neilos]

Oui je pensais à la même chose que toi (interface graph, domaine des paramètres, vue arborescente) et effectivement c'est très long et dur à mettre en place mais aussi très intéressant.
J'ai quelques projets en cours et une fois ceux-ci bien avancé je me pencherais sur un tel programme