Discussion :

[say]

Bonjour,
j'ai une appli au bord de la livraison.
Je voudrais pouvoir lancer une batterie de tests.
A savoir, multiplier les connexions au sgbd, et simuler des enchainements d'op�rations.

j'ai une id�e mais je voudrais savoir s'il n'existe pas des logiciels sp�cifiques � BCB ou des m�thodes de prog pour faire tout �a.

merci d'avance

[j.p.mignot]

la soci�t� PolySpace ( http://www.polyspace.com/ ) fourni de tels sofwares.
Il en existe d'autres dont je n'ai pas les noms en t�te.

[Mac LAK]

la soci�t� PolySpace ( http://www.polyspace.com/ ) fourni de tels sofwares.

Faut voir le prix des softs PolySpace, aussi !! Ils sont g�niaux, mais durs � encaisser pour une PME... :-(
De plus, si ma m�moire est bonne, PolySpace se comporte comme un "super-Lint" dynamique (ex�cution du code en environnement �mul�), qui va d�tecter le code mort, les conditions jamais r�alis�es, les dur�es/port�es/domaines des variables, etc...
Mais il ne fait que valider le code, il n'est pas capable de simuler une charge ou m�me une simple contrainte de temps : il v�rifie que le code est correct, ni plus, ni moins (m�me si c'est d�j� beaucoup !).


say : Mis � part automatiser ton programme (�ventuellement en incluant tout ou partie de ses modules dans un programme de test), je ne vois pas comment tu peux simuler �a... Il faut en effet que le SGBD r�ponde r�ellement, donc il faut le faire fonctionner "pour de vrai".

Par exemple, pour tester des DLL, j'ai l'habitude de cr�er un projet parall�le qui utilise les modules de la DLL au sein d'un projet "tentaculaire", qui permet de tester toutes les fonctions de mani�re unitaire... Ce dernier est, bien entendu, hautement automatisable. Ca permet de valider les fonctions unitaires, et m�me les fonctions "publiques". Une fois le test concluant dans ce cas d'utilisation, j'utilise la batterie automatique de tests sur l'interface de la DLL, mais en tapant r�ellement dans la DLL ce coup-ci : bien entendu, les r�sultats doivent �tre identiques.

Ne peux-tu pas faire un syst�me similaire avec ton application ? Profites du fait que partager une fiche/module de BCB entre deux projets (via un groupe de projets) soit une op�ration ultra simple ! ;-)

[j.p.mignot]

C'est vrai qu'ils sont chers!!! Mais ils offrent aussi des prestations de service.
Hors mis les points cit�s, j'ai utilis� ce soft pour �muler les cas de prises de donn�es via des electroniques externes dans des cas que jamais un banc de test n'aurrait pu faire ( trop de cas possible pour des dizaines voir des centaines d'entr�es ). Cerains risques potentiels ont �t� mis en �vidence.
Certain cas de variables non prot╬g�es ont aussi pu �tre r�v�l�s dans le cas d'interrupt externes assynchrone avec le process.
Il est vrai que je n'ai jamais eu � travailler avec les baques de donn�es.

[say]

Bonjour,

merci de vos r�ponses � vous deux. En effet, le co�t de logiciels de tests va �tre un vrai frein. Mon boss (PME) m'a � peu pr�t ouvert les cordons de le bourse mais l�, il va tiquer, je pr�f�res me r�server du budget pour d'autres achats (hard ou soft).

say : Mis � part automatiser ton programme (�ventuellement en incluant tout ou partie de ses modules dans un programme de test), je ne vois pas comment tu peux simuler �a... Il faut en effet que le SGBD r�ponde r�ellement, donc il faut le faire fonctionner "pour de vrai".

Ne peux-tu pas faire un syst�me similaire avec ton application ? Profites du fait que partager une fiche/module de BCB entre deux projets (via un groupe de projets) soit une op�ration ultra simple ! ;-)

en revanche, je pensais bien que modifier le prog en format test pouvait �tre une solution.je me demandais s'il existait des m�thodes particuli�res, des points clefs � v�rifier, en dehors du comportement du sgbd.

merci

[Mac LAK]

en revanche, je pensais bien que modifier le prog en format test pouvait �tre une solution.

Au moins, tu en as la confirmation : c'est non seulement possible, mais en plus, �a marche tr�s bien : du moins avec les compilateurs Borland, c'est parfois un peu moins simple avec Visual C++ par exemple.

je me demandais s'il existait des m�thodes particuli�res, des points clefs � v�rifier, en dehors du comportement du sgbd.

De mani�re g�n�rale, les points suivants sont � v�rifier :
- Comportement en cas d'absence de ressources critiques (DLL, programmes annexes, version Windows incompatible, version WinSock, etc...) : le programme doit pr�venir sans se crasher.
- Initialisation/destruction : toutes les ressources doivent �tre rendues (fuites m�moire par exemple). Je crois que "MemCheck" est compatible avec BCB, fais une recherche sur cet outil (Delphi � l'origine).
- "Algo du singe" : cliquer n'importe o�, n'importe comment et de pr�f�rence avec des valeurs d�biles. Le programme doit tenir le choc.
- Rupture de c�ble r�seau : d�tection de timeout imp�rative (d�branche le hub Ethernet, de mani�re � avoir la liaison mais plus de communication possible avec le serveur).
- V�rification des fonctions unitaires, suivant leurs sp�cifications.
- V�rification des fonctions export�es/publiques, en fonction des sp�cifications g�n�rales et/ou du CdC.

De mani�re g�n�rale, il ne faut pas tester ce que tu as cod�, mais ce qui �tait pr�vu. Comme un r�seau est en jeu, il te faut aussi simuler toutes les pannes possibles, et tester le cas o� plusieurs cartes r�seau sont install�es et/ou la tentative de connexion via un modem/VPN, ou au travers d'un proxy.

As-tu besoin de plus d'informations ?

[say]

Ok, �a me fait d�j� une bonne base.

En ce qui concerne les tests de la charge du SGBD...est-ce qu'une classe lan�ant des requ�tes SQL types, et des simultations d'�venements peut coller?

[Caine]

D'exp�rience la bonne approche d'une proc�dure de test est la suivante:
- 1) Oublier le code, repartir des sp�cifications, si la r�daction des cas de test n'a pas �t� faite en amont.

Qu'est-ce qu'un cas de test: V�rifier une fonctionnalit� de mani�re macorscopique. Par exemple, pour l'exigences suivante d'un �ditieur de texte: L'�diteur doit recona�tre la syntaxe du langage utilis� sur une statistique de mots cl�s et non simplement sur type d'extension" donnera les au moins les cas de tests suivants:

a) Cas nominal : Ouverture d'un fichier d'extension C++ contenant un source ADA. R�sultat, le langage ADA sera reconnu.

b)Cas d�grad� connu: Ouverture d'un fichier d'extension PAS, contenant un m�lange de sources ADA, C++ et HTML. Aucun langage n'est reconnu.

c)Cas d�grad� connu: Ouverture d'un fichier inexistant, ouverture d'un ficher autre que textuel (Word, binaire...): D�tection d'un type non support�.

Cette �tape suit les sp�cifications des fonctionnalit�s. Test des valeurs aux limites et des cas d�grad�s connus.

Une autre �tape vient apr�s la conception d�taill�, au pire arp�s l'analyse des sources, en bo�te blanche. Elle vise � garantir que l'int�gralit� des chemins algorithmique sont pass�s aux tests.

Enfin, une fois tous les tests unitaires d�roul�s, bien s�r viennent les tests d'int�gration de chaque module entre eux.

Quoi qu'il en soit, il vaut mieux privil�gier les test automatiques avec le moins d'int�raction humaine dans un maximum de tests. Si ce n'est pas possible, effectivement, il faut une intervention humaine.
Les tests automatiques doivent �tre le plus simple possible, pas de futilit� dans le code des ex�cutables de test.

Contre exemple pour tester un module de liste simplement chain�e:
Une mauvaise approche consiste � avoir un menu pour choisir le nombre d�l�ments � remplir, chaque champs � renseigner, les �l�ments � supprimer ... Il y a 80 % de chance qu'un tel ex�cutables de test rende obscur les cas nominaux, d�grad�s ... de plus, il peut lui m�me �tre bugu�.

Plus les tests automatiques sont simple dans leur syntaxe, plus il sera dans l'avenir facile de d�montrer la compl�tude des tests envers les exigences du logiciel.

Le cahier de test doit d�crire pour chaque tests, la proc�dure associ�es, la sp�cification en entr�e, le r�sultat attendue et correct.

Parmis les tests:
-Tests unitaires
-Tests d'int�gration: Respect des interfaces entre module et des pr� et post conditions.
-Tests de charges: Comment le logiciel r�agit � une utilisation intensive, qu'elle soit nominale ou erron�e ? Les ressources sont-elles lib�r�es et r�-utilisables?...

[say]

Tr�s bien.
Merci infiniment pour les infos, je vais m'organiser � partir de tout �a.

Bonne continuation.

[Mac LAK]

Pour r�pondre � ta question : oui, le but est de "charger" le SGBD, de pr�f�rence de la m�me mani�re que va le faire ton programme, mais "en pire"...

Ex :
- Si les requ�tes sont d�clench�es par une op�ration humaine, � une fr�quence maximale de 2 requ�tes par seconde, tu fais un test � 20 requ�tes/seconde...
- Si ton appli est pr�vue pour fonctionner sur maximum 3 postes, tu la d�ploie sur 6 (et tu charges la mule).
- Etc...

Le point important est de voir si tu tiens tes limites : si tu tiens "mieux", sans trop plomber le syst�me, tu peux raisonnablement �mettre un verdict favorable sur le comportement de l'application en mode nominal.
Si tu ne les tiens pas, il faut voir le "facteur limitant" (BP r�seau ? Charge CPU ? RAM ?), ce qui te permettra normalement de trouver les limites "acceptables", ou de d�finir les besoins mat�riels requis (ex : 512 Mo de RAM, r�seau 100 Mbits/s, etc...).

[say]

oki...mais comment synchroniser tous les progs de test.
je veux dire que par exemple, je soup�onne un probl�me de BP (because un VPN sur DSL). donc � moins de se mettre des beta-testeurs et de les synchroniser � la voix...je me vois pas d�velopper des sockets de synchro juste pour des tests..

mais sinon, j'ai confirmation que j'�tais sur la bonne voie, c'est cool

[Neilos]

- Initialisation/destruction : toutes les ressources doivent �tre rendues (fuites m�moire par exemple). Je crois que "MemCheck" est compatible avec BCB, fais une recherche sur cet outil (Delphi � l'origine).

Pour cela tu as aussi CodeGuard int�gr� � BCB (dans les options de ton projet). Mais seulement � partir de la version 6 Pro je crois.

Sinon je suis tr�s int�ress� par les tests automatiques. J'ai du �crire des programmes de tests unitaire pour un projet scolaire mais je souhaiterais appliquer ces m�thodes � mes d�veloppement. Le probl�me c'est que je ne vois pas trop comment "automatiser" les tests...

[say]

Pour cela tu as aussi CodeGuard int�gr� � BCB (dans les options de ton projet). Mais seulement � partir de la version 6 Pro je crois.

Ok, je testes de suite!!

[Mac LAK]

oki...mais comment synchroniser tous les progs de test.
je veux dire que par exemple, je soup�onne un probl�me de BP (because un VPN sur DSL). donc � moins de se mettre des beta-testeurs et de les synchroniser � la voix...je me vois pas d�velopper des sockets de synchro juste pour des tests..

H�las, pas trop le choix... Par contre, tu peux d�marrer sur un "top horaire" (d�but des tests � 10h00 tapantes par exemple), sur apparition d'un fichier r�seau/internet (page HTML), r�ception d'un datagramme UDP (tr�s simple � faire, �a !), etc...
Des solutions, il y en a des milliers : faut juste en choisir une que tu sais faire rapidement, m�me si ce n'est pas forc�ment la meilleure ! ;-)
Si t'as besoin qu'un op�rateur humain (toi, par exemple) d�marre tous les programmes "manuellement", puis que tu doives lancer la synchro manuellement, et alors ? C'est toujours mieux qu'aucun test, non ?

mais sinon, j'ai confirmation que j'�tais sur la bonne voie, c'est cool

Dans le domaine des tests, c'est m�me d�j� beaucoup.

[Mac LAK]

Le probl�me c'est que je ne vois pas trop comment "automatiser" les tests...

D�j�, �a commence par analyser quelques �l�ments :
- Peux-tu "extraire" la fonction unitairement, ou conna�tre � l'avance ses d�pendances ? Une simple documentation Doxygen te permet de savoir �a, par exemple.
- Peux-tu essayer toutes les combinaisons possibles de param�tres ? Si ta fonction prend au maximum l'�quivalent de 16 bits maximum en param�tres, la r�ponse est "oui". Si elle prend 12 param�tres r�els et 23 cha�nes de caract�res, �a va �tre dur ! ;-)
- Peux-tu d�terminer, d'apr�s les specs, quelles sont les valeurs critiques � tester ? Si non, quelles sont les valeurs critiques li�es � l'impl�mentation ? (cas des cha�nes valant NULL, des buffers non-allou�s, etc...) Tu vas en d�duire un jeu de test nominal (valeurs produisant des r�sultats connus � l'avance, pouvant �tre compar�s aux r�sultats de la fonction), et un jeu de test "d'erreur" (valeurs produisant des erreurs connues � l'avance).
- Peux-tu d�terminer les compatibilit�s requises ou interdites de ta fonction ? Par exemple, fonctionnement thread-safe, process-safe ? Si oui, il faudra cr�er une situation de concurrence pour valider cet aspect (ou, au contraire, prouver qu'il y a incompatibilit�).
- Connais-tu des invariants, pr�conditions et postconditions de ta fonction ? Si oui, ils devront �tre test�s � chaque jeu de test.

Une fois tous ces �l�ments connus, il "suffit" (!) de cr�er un programme impl�mentant tous ces tests, et de consigner le r�sultat sur un support neutre pour ta fonction (ex : ne pas utiliser un fichier de log si ta fonction manipule les fichiers, ne pas utiliser un "telnet RS-232" pour un objet de communication RS-232, etc...).

De m�me, en fonction des tests unitaires et des d�pendances, tu peux devoir valider tes fonctions dans un certain ordre (de la moins d�pendante � la plus d�pendante, bien s�r), et surtout t'appuyer sur une validation r�ussie pour "acc�l�rer" les autres validations : mais �a, par contre, �a d�pend beaucoup de ton projet et du d�coupage fonctionnel que tu as choisi.

Au minimum, en tout cas, toutes les fonctions publiques du module devront �tre test�es. M�me les macros "tellement simples qu'elles ne peuvent �chouer" : fais quand m�me un test fonctionnel, par s�curit� (test anti-"erreur de frappe").

Est-ce un peu plus clair pour toi ? As-tu besoin d'explications suppl�mentaires ?

[say]

Merci de toutes ces infos. Je pensais qu'il existait des m�thodes moins empiriques, plus m�thodiques

ben on va les faire � la minime les tests alors

merci encore

[Mac LAK]

Plus s�rieusement...merci de toutes ces infos. Je pensais qu'il existait des m�thodes moins empiriques, plus m�thodiques

De rien. Sinon, oui, il y a des m�thodes plus "m�thodiques" justement, mais elles sont rarement "� post�riori"... Elles sont plut�t intrins�quement li�es au processus de d�veloppement dans son ensemble, et le faire apr�s coup, c'est presque impossible... :-(

Bonne chance, pour tes tests comme pour ton retour � Toulouse ! ;-)

[Caine]

Bonjour,
Pour appliquer avec m�thode la conception de la phase de test, il faut la commencer d�s le cahier des charges, la raffiner au fur et � mesure de la conception d�taill�e.

L'analyse boite blanche permet surtout de montrer que si une fonctionnalit� est test�e en nominal, il est possible d'exclure certaines branches algorithmiques qui passent par cette fonctionnalit�. On fera simplement un test sur les conditions d'appel.

De mani�re g�n�rale, automatiser des tests est plus simple dans une architecture modulaire et bien pens�e. On automatise les modules les plus ind�pendants pour conna�tre leurs r�ponses aux contraintes d'appel et v�rifier qu'ils tiennent leur cahier des charges. Puis on augmente d'un niveau, on teste quelques modules qui les utilisent, l� encore en commen�ant par les plus ind�pendants.

Lorsqu'il y a une forte connexion entre modules, afin de se mettre dans des cas connus, on "stube" le module que l'on ne teste pas.

Exemple: Un programme prend ses trames sur une liaison s�rie RS232, il v�rifie la conformit� des trames suivant un protocole. On va stuber le driver RS232: La fonction de cr�ation renvoie toujours EXIT_SUCCESS, la fonction de lecture d'un octet renvoie un octet d�finit d'une trame cod�e en DUR et connue, conforme au protocole � tester. La fonction de fermeture de la com renvoie toujours EXIT_SUCCESS...

Il est alors facile de v�rifier que le programme appelant d�tecte bien les cas nominaux.

Plus vicieux cette fois, on cr�e un stub param�trable: Suivant un param�tre toutes les fonction sont dans un cas nominal ou dans un cas d�grad� connue. Refus d'ouverture ou de fermeture, r�ception d'un trame tronqu�e et Timeout, r�ception d'un trame dans un autre protocole...

On v�rifie que le programme appelant d�tecte ces cas.

Lors de l'int�gration avec le driver RS232, on est sur que le module appelant est correct, s'il y a une erreur, elle est dans le driver.

Evidement, le Stub suit les sp�cifications exactes du module � stuber.

[Neilos]

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

Il va falloir que je me penche l� dessus, merci pour les infos tout le monde et merci pour ton post say qui m'a permis d'apprendre pas mal de choses.

[say]

Et bien..on en apprend des choses.C'est �tonnant, c'est tr�s pointu et pourtant j'ai jamais �tendu de formation sp�cifique.

D'apr�s vous, (et je vous crois sur paroles), il faut pr�voir les tests d�s le cahier des charges. D�s ce cas, faut-il aussi planifier le d�veloppement de tests dans la conduite du projet?


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

Neilos>> U're welcome, c'�tait le but