salut!
je suis a la recherche d'un outil efficace et pas trop compliquer pour
detecter les fuites memoires dans mes softs.
quelqu'un en aurais il un bien a me conseiller?
merci
Il y a des cas où la durée de vie des objets est difficile à déterminer. Et il peut arriver, lorsqu'on étend du code, d'oublier de gérer la durée de vie d'objets dont il fallait s'occuper.
Il ne faut pas oublier. C'est simple :-)
Par ailleurs, dans ma boîte, on fait des bibliothèques et non des produits finaux. Et là, la palette possible d'utilisations est beaucoup plus grande que dans une application compilée une bonne fois pour toute. Tester tous les cas peut devenir particulièrement délicat.
Donne-moi vite le nom de ta boîte. Si vous ne faites pas l'effort de faire le maximum de tests alors que vous fournissez des bibliothèques, je ne veux pas devenir testeur en achetant vos produits !
En plus de ça, il n'est pas rare que la conception d'un logiciel ne soit pas parfaite au départ. Ensuite, il faut faire avec car il est très rarement possible de dire « on doit tout refaire parce que c'est sale ».
C'est sûr. Je rappelle quand même que je disais que faire la vérification de tout en trois jours était impossible. Si la conception du logiciel laisse à désirer en plus, j'en suis encore plus sûr. Ceci n'empêche pas de passer trois jours à améliorer les choses, puis trois autres jours, puis trois autres jours, ...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans le message 42dd267f$0$7322$636a15ce@news.free.fr,
Il y a des cas où la durée de vie des objets est difficile à
déterminer. Et il peut arriver, lorsqu'on étend du code, d'oublier
de gérer la durée de vie d'objets dont il fallait s'occuper.
Il ne faut pas oublier. C'est simple :-)
Par ailleurs, dans ma boîte, on fait des bibliothèques et non des
produits finaux. Et là, la palette possible d'utilisations est
beaucoup plus grande que dans une application compilée une bonne
fois pour toute. Tester tous les cas peut devenir particulièrement
délicat.
Donne-moi vite le nom de ta boîte. Si vous ne faites pas l'effort
de faire le maximum de tests alors que vous fournissez des
bibliothèques, je ne veux pas devenir testeur en achetant vos
produits !
En plus de ça, il n'est pas rare que la conception d'un logiciel ne
soit pas parfaite au départ. Ensuite, il faut faire avec car il est
très rarement possible de dire « on doit tout refaire parce que
c'est sale ».
C'est sûr. Je rappelle quand même que je disais que faire la
vérification de tout en trois jours était impossible. Si la
conception du logiciel laisse à désirer en plus, j'en suis encore
plus sûr. Ceci n'empêche pas de passer trois jours à améliorer les
choses, puis trois autres jours, puis trois autres jours, ...
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Il y a des cas où la durée de vie des objets est difficile à déterminer. Et il peut arriver, lorsqu'on étend du code, d'oublier de gérer la durée de vie d'objets dont il fallait s'occuper.
Il ne faut pas oublier. C'est simple :-)
Par ailleurs, dans ma boîte, on fait des bibliothèques et non des produits finaux. Et là, la palette possible d'utilisations est beaucoup plus grande que dans une application compilée une bonne fois pour toute. Tester tous les cas peut devenir particulièrement délicat.
Donne-moi vite le nom de ta boîte. Si vous ne faites pas l'effort de faire le maximum de tests alors que vous fournissez des bibliothèques, je ne veux pas devenir testeur en achetant vos produits !
En plus de ça, il n'est pas rare que la conception d'un logiciel ne soit pas parfaite au départ. Ensuite, il faut faire avec car il est très rarement possible de dire « on doit tout refaire parce que c'est sale ».
C'est sûr. Je rappelle quand même que je disais que faire la vérification de tout en trois jours était impossible. Si la conception du logiciel laisse à désirer en plus, j'en suis encore plus sûr. Ceci n'empêche pas de passer trois jours à améliorer les choses, puis trois autres jours, puis trois autres jours, ...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Jean-Marc Bourguet
"Michel Michaud" writes:
Dans le message ,
"Michel Michaud" writes:
S'il y a des fuites importantes et difficiles à détecter, je crois que tout le reste du programme ne doit pas être bien meilleur. Alors je ne fais pas ce travail en trois jours. Il faut tout revoir et, à chaque étape, tout tester et s'occuper, entre autres, des fuites. Pas très difficile, mais ça prendra le temps qu'il faut.
Il y a un problème que tu oublies: garder la boîte en vie pendant ce temps. Il faut donc fournir des choses et c'est justement ce dont tu es chargé.
S'il n'y a que des fuites, alors on peut fournir le produit tel quel...
Le problème du départ ce n'est pas "il y a des fuites", c'est: l'exemple utilisé par le client lors de l'évaluation ne passe pas dans la version 32 bits (ou sans swapper excessivement quand on n'a que XXX de mémoire) et ça passe chez les concurrents. Il y a un contrat de 50 millions sur 3 ans à la clef.
S'il y autre chose, il faut prendre le temps. Il n'y a pas d'alternative.
Si, combiner les trois types d'actions:
- fixer immédiatement les symptomes reportés si ce n'est pas trop coûteux tout en sachant que le problème reste là, (c'est du très court terme, mais le client a son changement dans le mois)
- fixer le fond pour ce qui est possible sans restructuration majeure (cad en ne touchant que l'implémentation d'un composant) (c'est du moyen terme, objectif les mises à jour mineures)
- prévoir les remplacement des composants par quelque chose de mieux, composant par composant (ce qui veut dire qu'il va falloir vivre avec certains composants fortement problèmatique pendant longtemps) et pas tout d'un coup (c'est beaucoup trop risqué et ça prendrait trop de temps) (c'est du long terme: objectif les mises à jour majeure).
Tu parlais de changer d'employeur... sans parler des problèmes autres que cela pose, tant que les troix axes sont utilisés je n'en vois pas réellement de raison.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
"Michel Michaud" <mm@gdzid.com> writes:
Dans le message 877jfmajrd.fsf@news.bourguet.org,
"Michel Michaud" <mm@gdzid.com> writes:
S'il y a des fuites importantes et difficiles à détecter,
je crois que tout le reste du programme ne doit pas être
bien meilleur. Alors je ne fais pas ce travail en trois
jours. Il faut tout revoir et, à chaque étape, tout tester
et s'occuper, entre autres, des fuites. Pas très
difficile, mais ça prendra le temps qu'il faut.
Il y a un problème que tu oublies: garder la boîte en vie
pendant ce temps. Il faut donc fournir des choses et c'est
justement ce dont tu es chargé.
S'il n'y a que des fuites, alors on peut fournir le
produit tel quel...
Le problème du départ ce n'est pas "il y a des fuites",
c'est: l'exemple utilisé par le client lors de l'évaluation
ne passe pas dans la version 32 bits (ou sans swapper
excessivement quand on n'a que XXX de mémoire) et ça passe
chez les concurrents. Il y a un contrat de 50 millions sur
3 ans à la clef.
S'il y autre chose, il faut prendre le temps. Il n'y a pas
d'alternative.
Si, combiner les trois types d'actions:
- fixer immédiatement les symptomes reportés si ce n'est
pas trop coûteux tout en sachant que le problème reste
là, (c'est du très court terme, mais le client a son
changement dans le mois)
- fixer le fond pour ce qui est possible sans
restructuration majeure (cad en ne touchant que
l'implémentation d'un composant) (c'est du moyen terme,
objectif les mises à jour mineures)
- prévoir les remplacement des composants par quelque
chose de mieux, composant par composant (ce qui veut
dire qu'il va falloir vivre avec certains composants
fortement problèmatique pendant longtemps) et pas tout
d'un coup (c'est beaucoup trop risqué et ça prendrait
trop de temps) (c'est du long terme: objectif les mises
à jour majeure).
Tu parlais de changer d'employeur... sans parler des
problèmes autres que cela pose, tant que les troix axes sont
utilisés je n'en vois pas réellement de raison.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
S'il y a des fuites importantes et difficiles à détecter, je crois que tout le reste du programme ne doit pas être bien meilleur. Alors je ne fais pas ce travail en trois jours. Il faut tout revoir et, à chaque étape, tout tester et s'occuper, entre autres, des fuites. Pas très difficile, mais ça prendra le temps qu'il faut.
Il y a un problème que tu oublies: garder la boîte en vie pendant ce temps. Il faut donc fournir des choses et c'est justement ce dont tu es chargé.
S'il n'y a que des fuites, alors on peut fournir le produit tel quel...
Le problème du départ ce n'est pas "il y a des fuites", c'est: l'exemple utilisé par le client lors de l'évaluation ne passe pas dans la version 32 bits (ou sans swapper excessivement quand on n'a que XXX de mémoire) et ça passe chez les concurrents. Il y a un contrat de 50 millions sur 3 ans à la clef.
S'il y autre chose, il faut prendre le temps. Il n'y a pas d'alternative.
Si, combiner les trois types d'actions:
- fixer immédiatement les symptomes reportés si ce n'est pas trop coûteux tout en sachant que le problème reste là, (c'est du très court terme, mais le client a son changement dans le mois)
- fixer le fond pour ce qui est possible sans restructuration majeure (cad en ne touchant que l'implémentation d'un composant) (c'est du moyen terme, objectif les mises à jour mineures)
- prévoir les remplacement des composants par quelque chose de mieux, composant par composant (ce qui veut dire qu'il va falloir vivre avec certains composants fortement problèmatique pendant longtemps) et pas tout d'un coup (c'est beaucoup trop risqué et ça prendrait trop de temps) (c'est du long terme: objectif les mises à jour majeure).
Tu parlais de changer d'employeur... sans parler des problèmes autres que cela pose, tant que les troix axes sont utilisés je n'en vois pas réellement de raison.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Michel Michaud
Dans le message ,
"Michel Michaud" writes:
S'il y autre chose, il faut prendre le temps. Il n'y a pas d'alternative.
Si, combiner les trois types d'actions: [...]
Je rappelle le problème posé par Loïc :
« voilà 5000 fichiers de code source, le développeur initial est parti aux bahamas, rien ne marche, tu as 3 jours avant qu'on livre au client. »
Tu parlais de changer d'employeur... sans parler des problèmes autres que cela pose, tant que les troix axes sont utilisés je n'en vois pas réellement de raison.
Relis le problème.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans le message 87vf368z8a.fsf@news.bourguet.org,
"Michel Michaud" <mm@gdzid.com> writes:
S'il y autre chose, il faut prendre le temps. Il n'y a pas
d'alternative.
Si, combiner les trois types d'actions:
[...]
Je rappelle le problème posé par Loïc :
« voilà 5000 fichiers de code source, le développeur initial est
parti aux bahamas, rien ne marche, tu as 3 jours avant qu'on livre
au client. »
Tu parlais de changer d'employeur... sans parler des
problèmes autres que cela pose, tant que les troix axes sont
utilisés je n'en vois pas réellement de raison.
Relis le problème.
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
S'il y autre chose, il faut prendre le temps. Il n'y a pas d'alternative.
Si, combiner les trois types d'actions: [...]
Je rappelle le problème posé par Loïc :
« voilà 5000 fichiers de code source, le développeur initial est parti aux bahamas, rien ne marche, tu as 3 jours avant qu'on livre au client. »
Tu parlais de changer d'employeur... sans parler des problèmes autres que cela pose, tant que les troix axes sont utilisés je n'en vois pas réellement de raison.
Relis le problème.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
kanze
Michel Michaud wrote:
Dans le message dbijeq$f7b$,
Michel Michaud wrote:
[...]
Même sur une seule utilisation le temps gagné sur la recherche de fuite compense celui pour télécharger les fichiers et les ajouter à son projet par rapport à cette solution intégrée.
J'en doute pour moi... Je n'ai jamais de fuite :-)
Plus sérieusement, même si c'est très proche de la vérité en fait, même mes élèves n'ont pas de problèmes majeurs avec les fuites et cet outil semble leur suffire. Je ne sais pas vraiment comment faire pour programmer assez mal pour réaliser qu'il y a des fuites très complexes à trouver. Les tests unitaires dès le départ devraient permettre d'éviter les problèmes majeurs non ? Si la structure du programme (au niveau de la gestion mémoire) est très complexe, il faut dès le départ s'appuyer sur des outils et techniques prévus pour éviter les problèmes...
En effet. Si je conseille souvent Purify, ce n'est pas seulement à cause des leaks, mais parce qu'il trouve un tas d'autres erreurs aussi.
Je dois manquer d'imagination pour comprendre comment on peut avoir une fuite et ne pas facilement savoir d'où elle vient...
C'est pourtant simple. Tu codes sans avoir fait la moindre conception.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Michel Michaud wrote:
Dans le message dbijeq$f7b$1@reader1.imaginet.fr,
Michel Michaud wrote:
[...]
Même sur une seule utilisation le temps gagné sur la
recherche de fuite compense celui pour télécharger les
fichiers et les ajouter à son projet par rapport à cette
solution intégrée.
J'en doute pour moi... Je n'ai jamais de fuite :-)
Plus sérieusement, même si c'est très proche de la vérité en
fait, même mes élèves n'ont pas de problèmes majeurs avec les
fuites et cet outil semble leur suffire. Je ne sais pas
vraiment comment faire pour programmer assez mal pour réaliser
qu'il y a des fuites très complexes à trouver. Les tests
unitaires dès le départ devraient permettre d'éviter les
problèmes majeurs non ? Si la structure du programme (au
niveau de la gestion mémoire) est très complexe, il faut dès
le départ s'appuyer sur des outils et techniques prévus pour
éviter les problèmes...
En effet. Si je conseille souvent Purify, ce n'est pas seulement
à cause des leaks, mais parce qu'il trouve un tas d'autres
erreurs aussi.
Je dois manquer d'imagination pour comprendre comment on peut
avoir une fuite et ne pas facilement savoir d'où elle vient...
C'est pourtant simple. Tu codes sans avoir fait la moindre
conception.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Même sur une seule utilisation le temps gagné sur la recherche de fuite compense celui pour télécharger les fichiers et les ajouter à son projet par rapport à cette solution intégrée.
J'en doute pour moi... Je n'ai jamais de fuite :-)
Plus sérieusement, même si c'est très proche de la vérité en fait, même mes élèves n'ont pas de problèmes majeurs avec les fuites et cet outil semble leur suffire. Je ne sais pas vraiment comment faire pour programmer assez mal pour réaliser qu'il y a des fuites très complexes à trouver. Les tests unitaires dès le départ devraient permettre d'éviter les problèmes majeurs non ? Si la structure du programme (au niveau de la gestion mémoire) est très complexe, il faut dès le départ s'appuyer sur des outils et techniques prévus pour éviter les problèmes...
En effet. Si je conseille souvent Purify, ce n'est pas seulement à cause des leaks, mais parce qu'il trouve un tas d'autres erreurs aussi.
Je dois manquer d'imagination pour comprendre comment on peut avoir une fuite et ne pas facilement savoir d'où elle vient...
C'est pourtant simple. Tu codes sans avoir fait la moindre conception.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Arnaud Meurgues
Michel Michaud wrote:
Donne-moi vite le nom de ta boîte. Si vous ne faites pas l'effort de faire le maximum de tests alors que vous fournissez des bibliothèques, je ne veux pas devenir testeur en achetant vos produits !
Ce que je dis, c'est que « le maximum de tests », ce n'est pas suffisant parce qu'on ne maitrise pas la manière dont sera utilisée une bibliothèque.
Arnaud
Michel Michaud wrote:
Donne-moi vite le nom de ta boîte. Si vous ne faites pas l'effort
de faire le maximum de tests alors que vous fournissez des
bibliothèques, je ne veux pas devenir testeur en achetant vos
produits !
Ce que je dis, c'est que « le maximum de tests », ce n'est pas suffisant
parce qu'on ne maitrise pas la manière dont sera utilisée une bibliothèque.
Donne-moi vite le nom de ta boîte. Si vous ne faites pas l'effort de faire le maximum de tests alors que vous fournissez des bibliothèques, je ne veux pas devenir testeur en achetant vos produits !
Ce que je dis, c'est que « le maximum de tests », ce n'est pas suffisant parce qu'on ne maitrise pas la manière dont sera utilisée une bibliothèque.
Arnaud
Michel Michaud
Dans le message 42df61a2$0$7841$,
Michel Michaud wrote:
Donne-moi vite le nom de ta boîte. Si vous ne faites pas l'effort de faire le maximum de tests alors que vous fournissez des bibliothèques, je ne veux pas devenir testeur en achetant vos produits !
Ce que je dis, c'est que « le maximum de tests », ce n'est pas suffisant parce qu'on ne maitrise pas la manière dont sera utilisée une bibliothèque.
Je ne vois pas en quoi cela empêche de tout tester ce que *vous* avez écrit. Tu peux élaborer ?
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans le message 42df61a2$0$7841$626a14ce@news.free.fr,
Michel Michaud wrote:
Donne-moi vite le nom de ta boîte. Si vous ne faites pas l'effort
de faire le maximum de tests alors que vous fournissez des
bibliothèques, je ne veux pas devenir testeur en achetant vos
produits !
Ce que je dis, c'est que « le maximum de tests », ce n'est pas
suffisant parce qu'on ne maitrise pas la manière dont sera utilisée
une bibliothèque.
Je ne vois pas en quoi cela empêche de tout tester ce que *vous*
avez écrit. Tu peux élaborer ?
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Donne-moi vite le nom de ta boîte. Si vous ne faites pas l'effort de faire le maximum de tests alors que vous fournissez des bibliothèques, je ne veux pas devenir testeur en achetant vos produits !
Ce que je dis, c'est que « le maximum de tests », ce n'est pas suffisant parce qu'on ne maitrise pas la manière dont sera utilisée une bibliothèque.
Je ne vois pas en quoi cela empêche de tout tester ce que *vous* avez écrit. Tu peux élaborer ?
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Matthieu Moy
"Michel Michaud" writes:
Je ne vois pas en quoi cela empêche de tout tester ce que *vous* avez écrit. Tu peux élaborer ?
Si tu as une methode pour faire du test exhaustif en temps raisonnable, tu devrais venir en parler à mon labo, ça nous intéresse.
Sinon, ne nous fait pas croire que tu n'as pas quelques notions de fiabilité des logiciels. Un logiciel sans bugs, c'est grosso-modo impossible. A la limite, si tu fais de la preuve formelle dessus, tu commences à avoir des garanties, mais il faut faire confiance à ton compilo, à ton OS, au matériel, à la libstdc++ puisqu'on parle de C++, ... Donc, on peut raisonnablement supposer que pour tout programme (même les tiens, oui oui), il existe un cas qui le fait planter.
Toute personne qui s'est posée sérieusement la question de la fiabilité d'un logiciel a entendu parler du profil utilisateur. Si on prend le cas le plus simple d'un programme transformationnel, tu as un ensemble d'entrées possibles (infini ou au moins très grand sauf pour un programme trivial), et la fiabilité est la part des entrées pour laquelle la sortie n'est pas celle attendue. Étant donné que cet ensemble d'entrées est trop grand pour être dénombré, tu ne peux mesurer la fiabilité qu'en tirant des entrées selon une certaine distribution. Cette distribution est ce qu'on appelle le profil utilisateur. Un des éléments qui fait la particularité des logiciels en terme de fiabilité est que le profil change *énormémént* d'un utilisateur à l'autre (c'est beaucoup moins vrai en mécanique par exemple).
Au final, avec n'importe quelle politique de test, il y aura toujours des cas non testés (oui oui, encore une fois, même dans tes programmes, à moins que tu ne travailles sur un domaine d'entrées fini et petit et sur un programme entièrement déterministe), et donc forcément, il est possible de trouver un client qui a un profil utilisateur pour lequel ces cas arrivent souvent. Le tout est de minimiser la probabilité pour que cela arrive.
-- Matthieu
"Michel Michaud" <mm@gdzid.com> writes:
Je ne vois pas en quoi cela empêche de tout tester ce que *vous*
avez écrit. Tu peux élaborer ?
Si tu as une methode pour faire du test exhaustif en temps
raisonnable, tu devrais venir en parler à mon labo, ça nous intéresse.
Sinon, ne nous fait pas croire que tu n'as pas quelques notions de
fiabilité des logiciels. Un logiciel sans bugs, c'est grosso-modo
impossible. A la limite, si tu fais de la preuve formelle dessus, tu
commences à avoir des garanties, mais il faut faire confiance à ton
compilo, à ton OS, au matériel, à la libstdc++ puisqu'on parle de
C++, ... Donc, on peut raisonnablement supposer que pour tout
programme (même les tiens, oui oui), il existe un cas qui le fait
planter.
Toute personne qui s'est posée sérieusement la question de la
fiabilité d'un logiciel a entendu parler du profil utilisateur. Si on
prend le cas le plus simple d'un programme transformationnel, tu as un
ensemble d'entrées possibles (infini ou au moins très grand sauf pour
un programme trivial), et la fiabilité est la part des entrées pour
laquelle la sortie n'est pas celle attendue. Étant donné que cet
ensemble d'entrées est trop grand pour être dénombré, tu ne peux
mesurer la fiabilité qu'en tirant des entrées selon une certaine
distribution. Cette distribution est ce qu'on appelle le profil
utilisateur. Un des éléments qui fait la particularité des logiciels
en terme de fiabilité est que le profil change *énormémént* d'un
utilisateur à l'autre (c'est beaucoup moins vrai en mécanique par
exemple).
Au final, avec n'importe quelle politique de test, il y aura toujours
des cas non testés (oui oui, encore une fois, même dans tes
programmes, à moins que tu ne travailles sur un domaine d'entrées fini
et petit et sur un programme entièrement déterministe), et donc
forcément, il est possible de trouver un client qui a un profil
utilisateur pour lequel ces cas arrivent souvent. Le tout est de
minimiser la probabilité pour que cela arrive.
Je ne vois pas en quoi cela empêche de tout tester ce que *vous* avez écrit. Tu peux élaborer ?
Si tu as une methode pour faire du test exhaustif en temps raisonnable, tu devrais venir en parler à mon labo, ça nous intéresse.
Sinon, ne nous fait pas croire que tu n'as pas quelques notions de fiabilité des logiciels. Un logiciel sans bugs, c'est grosso-modo impossible. A la limite, si tu fais de la preuve formelle dessus, tu commences à avoir des garanties, mais il faut faire confiance à ton compilo, à ton OS, au matériel, à la libstdc++ puisqu'on parle de C++, ... Donc, on peut raisonnablement supposer que pour tout programme (même les tiens, oui oui), il existe un cas qui le fait planter.
Toute personne qui s'est posée sérieusement la question de la fiabilité d'un logiciel a entendu parler du profil utilisateur. Si on prend le cas le plus simple d'un programme transformationnel, tu as un ensemble d'entrées possibles (infini ou au moins très grand sauf pour un programme trivial), et la fiabilité est la part des entrées pour laquelle la sortie n'est pas celle attendue. Étant donné que cet ensemble d'entrées est trop grand pour être dénombré, tu ne peux mesurer la fiabilité qu'en tirant des entrées selon une certaine distribution. Cette distribution est ce qu'on appelle le profil utilisateur. Un des éléments qui fait la particularité des logiciels en terme de fiabilité est que le profil change *énormémént* d'un utilisateur à l'autre (c'est beaucoup moins vrai en mécanique par exemple).
Au final, avec n'importe quelle politique de test, il y aura toujours des cas non testés (oui oui, encore une fois, même dans tes programmes, à moins que tu ne travailles sur un domaine d'entrées fini et petit et sur un programme entièrement déterministe), et donc forcément, il est possible de trouver un client qui a un profil utilisateur pour lequel ces cas arrivent souvent. Le tout est de minimiser la probabilité pour que cela arrive.
-- Matthieu
Matthieu Moy
"Michel Michaud" writes:
Dans le message ,
[...] test exhaustif [...]
Ce n'est pas ce que je demande. Arnaud disait
Un peu quand même, non ? ...
[...] Tester tous les cas peut devenir particulièrement délicat. ^^^^^^^^^^^^
(et dans le message auquel je réponds, tu parles de « tout tester », ce qui est clairement impossible).
Je demande simplement pourquoi il serait plus difficile de tester (normalement, le mieux possible, selon l'art, etc.) dans son cas que dans le cas général.
Je ne sais pas ce que fait Arnaud, donc je risque de répondre à coté, mais il y a quand même des cas ou le profil utilisateur est plus prédictible que d'autres. Si tu fais un serveur web, tu peux raisonnablement supposer que l'utilisateur s'en servira comme serveur web. Si tu fais un traitement de texte, tu peux raisonnablement supposer que l'utilisateur s'en servira comme d'un traitement de texte (quoique ...). Si tu fais une bibliothèque de composants un peu génériques, tu peux difficilement savoir pour quoi elle sera utilisée, donc, tu as plus de chances de tomber sur un client qui a un « mauvais » profile utilisateur.
-- Matthieu
"Michel Michaud" <mm@gdzid.com> writes:
Dans le message vpqd5pc9slb.fsf@ecrins.imag.fr,
[...] test exhaustif [...]
Ce n'est pas ce que je demande. Arnaud disait
Un peu quand même, non ? ...
[...] Tester tous les cas peut devenir particulièrement délicat.
^^^^^^^^^^^^
(et dans le message auquel je réponds, tu parles de « tout tester »,
ce qui est clairement impossible).
Je demande simplement pourquoi il serait plus difficile de tester
(normalement, le mieux possible, selon l'art, etc.) dans son cas
que dans le cas général.
Je ne sais pas ce que fait Arnaud, donc je risque de répondre à coté,
mais il y a quand même des cas ou le profil utilisateur est plus
prédictible que d'autres. Si tu fais un serveur web, tu peux
raisonnablement supposer que l'utilisateur s'en servira comme serveur
web. Si tu fais un traitement de texte, tu peux raisonnablement
supposer que l'utilisateur s'en servira comme d'un traitement de texte
(quoique ...). Si tu fais une bibliothèque de composants un peu
génériques, tu peux difficilement savoir pour quoi elle sera utilisée,
donc, tu as plus de chances de tomber sur un client qui a un
« mauvais » profile utilisateur.
[...] Tester tous les cas peut devenir particulièrement délicat. ^^^^^^^^^^^^
(et dans le message auquel je réponds, tu parles de « tout tester », ce qui est clairement impossible).
Je demande simplement pourquoi il serait plus difficile de tester (normalement, le mieux possible, selon l'art, etc.) dans son cas que dans le cas général.
Je ne sais pas ce que fait Arnaud, donc je risque de répondre à coté, mais il y a quand même des cas ou le profil utilisateur est plus prédictible que d'autres. Si tu fais un serveur web, tu peux raisonnablement supposer que l'utilisateur s'en servira comme serveur web. Si tu fais un traitement de texte, tu peux raisonnablement supposer que l'utilisateur s'en servira comme d'un traitement de texte (quoique ...). Si tu fais une bibliothèque de composants un peu génériques, tu peux difficilement savoir pour quoi elle sera utilisée, donc, tu as plus de chances de tomber sur un client qui a un « mauvais » profile utilisateur.
-- Matthieu
Matthieu Moy
"Michel Michaud" writes:
Je ne demande pas de tester tous les cas d'utilisation, mais bien de tout tester *ce qu'on a écrit*. Et tester ce qu'on a écrit ne signifie évidemment pas de faire tous les tests possibles, ce qui est, oui, clairement impossible.
Ça veut dire quoi, « tester ce qu'on a écrit » ?
-- Matthieu
"Michel Michaud" <mm@gdzid.com> writes:
Je ne demande pas de tester tous les cas d'utilisation, mais bien
de tout tester *ce qu'on a écrit*. Et tester ce qu'on a écrit ne
signifie évidemment pas de faire tous les tests possibles, ce qui
est, oui, clairement impossible.
Je ne demande pas de tester tous les cas d'utilisation, mais bien de tout tester *ce qu'on a écrit*. Et tester ce qu'on a écrit ne signifie évidemment pas de faire tous les tests possibles, ce qui est, oui, clairement impossible.
Ça veut dire quoi, « tester ce qu'on a écrit » ?
-- Matthieu
Matthieu Moy
"Michel Michaud" writes:
Ça veut dire quoi, « tester ce qu'on a écrit » ?
Vérifier que dans les conditions d'utilisation habituelle le code qu'on a écrit se comporte normalement.
Et c'est quoi, les « conditions d'utilisation habituelle » ?
(indice: si tu parviens à répondre à la question, tu comprendras aussi ce que disait Arnaud, à qui tu reprochais justement de ne pas assez tester ses bibliothèques dans des conditions inhabituelles quelques messages plus haut)
-- Matthieu
"Michel Michaud" <mm@gdzid.com> writes:
Ça veut dire quoi, « tester ce qu'on a écrit » ?
Vérifier que dans les conditions d'utilisation habituelle le code
qu'on a écrit se comporte normalement.
Et c'est quoi, les « conditions d'utilisation habituelle » ?
(indice: si tu parviens à répondre à la question, tu comprendras aussi
ce que disait Arnaud, à qui tu reprochais justement de ne pas assez
tester ses bibliothèques dans des conditions inhabituelles quelques
messages plus haut)
Vérifier que dans les conditions d'utilisation habituelle le code qu'on a écrit se comporte normalement.
Et c'est quoi, les « conditions d'utilisation habituelle » ?
(indice: si tu parviens à répondre à la question, tu comprendras aussi ce que disait Arnaud, à qui tu reprochais justement de ne pas assez tester ses bibliothèques dans des conditions inhabituelles quelques messages plus haut)
