Discussion :

[l'indien]

comment vous vous y prenez pour tester et valider un gros programme, quels sont les tests que vous mettez en place???

[Anomaly]

Le mieux, ce sont les tests automatiques, réalisés avant (ou pendant l'écriture du programme), à lancer après chaque modification, afin de laisser le programme "dans le bon chemin". Ceci vient de la méthode XP. Gros défaut : presque inapplicable pour un programme en interface graphique

[Metal Tom]

Ca dépend du programme, du langage dans lequel il est écrit, etc. En CAML par exemple tu peux faire des démnstrations de ton programme.

[toto_titi]

Salut,

Une bonne solution est de faire de senario de tests et de savoir quelle partie du code n'a pas ete teste. IL y a une soft tres bien mais proprietaire chez Rational tu peux dl une version d'essai, le nom c'est Purify.

Sinon tu peux aussi tester le comportement de ton programme.
Il exite est utilitaire gnu pour tester la memoire utilisee par les differents processus et fonction (sur le site du gnu : VALGRIND). Sur un gros projet ca permet de prevenir des segfaults ou des fuites de menoires. Il exite aussi des utilitaires pour tester la charge CPU utilisee par les fonctions de ton programme ca peut te permettre d'optimiser ton programme (Gprof sur le site du gnu).


A+

[Anomaly]

Bonjour toto_titi,

Purify est à ma connaissance un outil pour déceler les fuites de mémoires, les utilisations incorrectes d'API etc... Il permet de voir ainsi si le programme n'aura pas de problème de fonctionnement suite à des défaillances du programmeur dans la gestion de sa mémoire et de l'appel des APIs, mais à ma connaissance, ce n'est pas un outil destiné à valider un programme (valider dans le sens : vérifier que le programme fait ce qui a été dit dans le cahier des charges).

[sylvain114d]

Pour verifier la liberation memoire, tu peux utiliser des macros :

Tu mets ce code dans un ficher d'entete que tu inclus dans tous tes fichiers.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
int MDbgAl;
#define malloc(x) (MDbgAl++,malloc(x))
#define calloc(x,y) (MDbgAl++,calloc(x,y))
#define free(x) {\
			if(x)\
				{\
				MDbgAl--;\
				free(x);\
				}\
			}

Juste avant de quitter ton prog, tu verifis si la valeur de la variable globlale est bien egale a 0.

ATTENTION de ne jamais include ce hearder avant malloc.h par exemple car là ça ne compile pas (normal )

[fd]

3 phases :

1 - tu teste les cas droits
2 - tu teste les cas limites
3 - tu teste les cas faux

[HRS]

si vous avez découpé votre programme en fonctions, vous pouvez tester
chacune de vos fonctions isolément

Code :

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

1
2
3
4
5
6
7
8
9
 
type_retour Fonction_A_Tester (type1 arg1, type2 arg2, ...) {
// le code de votre fonction
}
void main (void) {
// alimentation des paramètres d'entrée
// appel de la fonction
// vérification des résultats
}

[l'indien]

je vois que c'est un sujet qui scuccite beaucoup de reflexion et pour cause, il s'agit d'un point important de notre domaine.

sur ce sujet, voilà la reflexion la plus interessante faite par un ami, qui résume unpeu tout ce que vous avez pu dire:

methode 1- si ton programme est court c'est-a-dire quelques lignes
(ce n'est pas ton cas!) tu peux utiliser
des systemes de preuves (du type le systeme COQ),
c'est tres long sur des petits programmes impossible pour des grands
mais c'est tres sur

methode 2-sinon, tout depend de ton application, la solution la plus utilisee
est de construire toi meme une "test-suite" c'est-a`-dire des jeux
de donnees pour ton programme qui visitent toutes les branches de ton programme
(ouais je sais c'est ultra lourd, ca peut etre considerablement plus long a
faire que le programme lui-meme), une fois la test suite validee
la validation de ton programme depend de .... ta test-suite
(donc il vaut mieux beaucoup de rigueur et de temps)

-methode 3-Dans tout les cas, la meilleure solution (a mon avis) est de
valider ton algorithme grace a l'utilisation d'antecedents et de consequents
pendant l'ecriture de ton algorithme
mais cette methode peut vite devenir tres delicate
(par exemple, si tu fais des operations arithmetiques IEEE dans ton programme
il faut verifier que tu ne jamais avoir des underflow ou overflow ce qui
revient en gros a utiliser la methode 1)

Merci et A+