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