[MOSS] Validation de développements Sharepoint et stress tool
2 réponses
TSC
Bonjour,
Nous travaillons avec une soci=E9t=E9 qui d=E9veloppe nos mod=E8les de site=
s
et autres webparts Sharepoint.
>> Comment nous assurer, sachant que nous ne disposons pas toujours du code=
source, que les d=E9veloppements effectu=E9s sont corrects ? (c'est =E0 di=
re que les objets sont bien lib=E9r=E9s, qu'il n'y a pas de fuite m=E9moire=
, ou que les mod=E8les de site sont correctement impl=E9ment=E9s)
A priori, la seule chose que l'on puisse faire sont des tests de
mont=E9e en charge, non ? (sharepoint stress tool )
Je crois avoir vu qu'il existe des outils permettant de valider des
d=E9veloppements...
>> lesquels utilisez vous ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Lognoul Marc [MVP]
Bonjour,
Nous travaillons avec une société qui développe nos modèles de sites et autres webparts Sharepoint.
Comment nous assurer, sachant que nous ne disposons pas toujours du code source, que les développements effectués sont corrects ? (c'est à dire que les objets sont bien libérés, qu'il n'y a pas de fuite mémoire, ou que les modèles de site sont correctement implémentés)
A priori, la seule chose que l'on puisse faire sont des tests de montée en charge, non ? (sharepoint stress tool )
Je crois avoir vu qu'il existe des outils permettant de valider des développements...
lesquels utilisez vous ?
On pourrait écrire un livre sur les bonnes pratiques en ce qui concerne les tests ;) mais en version courte voilà comment moi je vois les choses.
Un stress-test ne permet pas de tester une solution sur le plan technique ou fonctionnel, il permettra de mesure la charge que peut supporter votre infrastrcture sous des conditions données. Evidemment, une des conséquence peut-être de faire ressortir de manière flagrante une consommation anormale de mémoire MAIS sans vous en donner la cause réelle. Encore faut-il reconnaitre une utilisation anormale de mémoire ;) et sa non-libération
Donc pour valider du code sans en posséder la source, il faut en passer par: - Effectuer des tests unitaires toute en utilisant Le tracing asp.net + SharePoint et/ou en attacheant un debugger au processus w3wp.exe et en analysant le comportment - Si vous souhaitez détecter les memory leak an particulier, vous pouvez tester, sans garantie de résultats toutefois, l'outil SPDisposecheck. Lisez le blog de l'auteur, il contient des infos très utiles: http://blogs.msdn.com/rogerla/archive/2008/02/12/sharepoint-2007-and-wss-3-0-dispose-patterns-by-example.aspx - Utiliser des outils de type procmon (sysinternals) afin de tracer le comportement au niveau système d'exploitation
L'idéal est, à priori, de passer par un cahier des charges assez détaillé qui spécifie la manière donc les solutions sharepoint doivent de comporter de manière fonctionnelle et technique ainsi que la manière de les délivrer par ex.
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
__________ Information from ESET NOD32 Antivirus, version of virus signature database 3961 (20090325) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
Bonjour,
Nous travaillons avec une société qui développe nos modèles de sites
et autres webparts Sharepoint.
Comment nous assurer, sachant que nous ne disposons pas toujours du code
source, que les développements effectués sont corrects ? (c'est à dire
que les objets sont bien libérés, qu'il n'y a pas de fuite mémoire, ou
que les modèles de site sont correctement implémentés)
A priori, la seule chose que l'on puisse faire sont des tests de
montée en charge, non ? (sharepoint stress tool )
Je crois avoir vu qu'il existe des outils permettant de valider des
développements...
lesquels utilisez vous ?
On pourrait écrire un livre sur les bonnes pratiques en ce qui concerne les
tests ;) mais en version courte voilà comment moi je vois les choses.
Un stress-test ne permet pas de tester une solution sur le plan technique ou
fonctionnel, il permettra de mesure la charge que peut supporter votre
infrastrcture sous des conditions données. Evidemment, une des conséquence
peut-être de faire ressortir de manière flagrante une consommation anormale
de mémoire MAIS sans vous en donner la cause réelle. Encore faut-il
reconnaitre une utilisation anormale de mémoire ;) et sa non-libération
Donc pour valider du code sans en posséder la source, il faut en passer par:
- Effectuer des tests unitaires toute en utilisant Le tracing asp.net +
SharePoint et/ou en attacheant un debugger au processus w3wp.exe et en
analysant le comportment
- Si vous souhaitez détecter les memory leak an particulier, vous pouvez
tester, sans garantie de résultats toutefois, l'outil SPDisposecheck. Lisez
le blog de l'auteur, il contient des infos très utiles:
http://blogs.msdn.com/rogerla/archive/2008/02/12/sharepoint-2007-and-wss-3-0-dispose-patterns-by-example.aspx
- Utiliser des outils de type procmon (sysinternals) afin de tracer le
comportement au niveau système d'exploitation
L'idéal est, à priori, de passer par un cahier des charges assez détaillé
qui spécifie la manière donc les solutions sharepoint doivent de comporter
de manière fonctionnelle et technique ainsi que la manière de les délivrer
par ex.
--
Marc [MCSE, MCTS, MVP]
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
__________ Information from ESET NOD32 Antivirus, version of virus signature database 3961 (20090325) __________
Nous travaillons avec une société qui développe nos modèles de sites et autres webparts Sharepoint.
Comment nous assurer, sachant que nous ne disposons pas toujours du code source, que les développements effectués sont corrects ? (c'est à dire que les objets sont bien libérés, qu'il n'y a pas de fuite mémoire, ou que les modèles de site sont correctement implémentés)
A priori, la seule chose que l'on puisse faire sont des tests de montée en charge, non ? (sharepoint stress tool )
Je crois avoir vu qu'il existe des outils permettant de valider des développements...
lesquels utilisez vous ?
On pourrait écrire un livre sur les bonnes pratiques en ce qui concerne les tests ;) mais en version courte voilà comment moi je vois les choses.
Un stress-test ne permet pas de tester une solution sur le plan technique ou fonctionnel, il permettra de mesure la charge que peut supporter votre infrastrcture sous des conditions données. Evidemment, une des conséquence peut-être de faire ressortir de manière flagrante une consommation anormale de mémoire MAIS sans vous en donner la cause réelle. Encore faut-il reconnaitre une utilisation anormale de mémoire ;) et sa non-libération
Donc pour valider du code sans en posséder la source, il faut en passer par: - Effectuer des tests unitaires toute en utilisant Le tracing asp.net + SharePoint et/ou en attacheant un debugger au processus w3wp.exe et en analysant le comportment - Si vous souhaitez détecter les memory leak an particulier, vous pouvez tester, sans garantie de résultats toutefois, l'outil SPDisposecheck. Lisez le blog de l'auteur, il contient des infos très utiles: http://blogs.msdn.com/rogerla/archive/2008/02/12/sharepoint-2007-and-wss-3-0-dispose-patterns-by-example.aspx - Utiliser des outils de type procmon (sysinternals) afin de tracer le comportement au niveau système d'exploitation
L'idéal est, à priori, de passer par un cahier des charges assez détaillé qui spécifie la manière donc les solutions sharepoint doivent de comporter de manière fonctionnelle et technique ainsi que la manière de les délivrer par ex.
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
__________ Information from ESET NOD32 Antivirus, version of virus signature database 3961 (20090325) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
TSC
On 25 mar, 16:41, "Lognoul Marc [MVP]" wrote:
Bonjour,
> Nous travaillons avec une société qui développe nos modèles de sites > et autres webparts Sharepoint.
>>> Comment nous assurer, sachant que nous ne disposons pas toujours du c ode >>> source, que les développements effectués sont corrects ? (c'est à dire >>> que les objets sont bien libérés, qu'il n'y a pas de fuite mémo ire, ou >>> que les modèles de site sont correctement implémentés)
> A priori, la seule chose que l'on puisse faire sont des tests de > montée en charge, non ? (sharepoint stress tool )
> Je crois avoir vu qu'il existe des outils permettant de valider des > développements... >>> lesquels utilisez vous ?
On pourrait écrire un livre sur les bonnes pratiques en ce qui concerne les tests ;) mais en version courte voilà comment moi je vois les choses.
Un stress-test ne permet pas de tester une solution sur le plan technique ou fonctionnel, il permettra de mesure la charge que peut supporter votre infrastrcture sous des conditions données. Evidemment, une des conséq uence peut-être de faire ressortir de manière flagrante une consommation an ormale de mémoire MAIS sans vous en donner la cause réelle. Encore faut-i l reconnaitre une utilisation anormale de mémoire ;) et sa non-libérati on
Donc pour valider du code sans en posséder la source, il faut en passer par: - Effectuer des tests unitaires toute en utilisant Le tracing asp.net + SharePoint et/ou en attacheant un debugger au processus w3wp.exe et en analysant le comportment - Si vous souhaitez détecter les memory leak an particulier, vous pouve z tester, sans garantie de résultats toutefois, l'outil SPDisposecheck. L isez le blog de l'auteur, il contient des infos très utiles:http://blogs.msd n.com/rogerla/archive/2008/02/12/sharepoint-2007-and-... - Utiliser des outils de type procmon (sysinternals) afin de tracer le comportement au niveau système d'exploitation
L'idéal est, à priori, de passer par un cahier des charges assez dé taillé qui spécifie la manière donc les solutions sharepoint doivent de comp orter de manière fonctionnelle et technique ainsi que la manière de les d élivrer par ex.
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog:http://www.marc-antho-etc.net/blog/]
__________ Information from ESET NOD32 Antivirus, version of virus signat ure database 3961 (20090325) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
(re) Merci Marc pour cette réponse express
C'est bien à SPDisposeCheck que je pensais... (mais il me semble qu'il ne verifie pas tout non plus) Pour le reste, il faut donc relever les manches et se lancer :)
On 25 mar, 16:41, "Lognoul Marc [MVP]" <logno...@hotmail.com> wrote:
Bonjour,
> Nous travaillons avec une société qui développe nos modèles de sites
> et autres webparts Sharepoint.
>>> Comment nous assurer, sachant que nous ne disposons pas toujours du c ode
>>> source, que les développements effectués sont corrects ? (c'est à dire
>>> que les objets sont bien libérés, qu'il n'y a pas de fuite mémo ire, ou
>>> que les modèles de site sont correctement implémentés)
> A priori, la seule chose que l'on puisse faire sont des tests de
> montée en charge, non ? (sharepoint stress tool )
> Je crois avoir vu qu'il existe des outils permettant de valider des
> développements...
>>> lesquels utilisez vous ?
On pourrait écrire un livre sur les bonnes pratiques en ce qui concerne les
tests ;) mais en version courte voilà comment moi je vois les choses.
Un stress-test ne permet pas de tester une solution sur le plan technique ou
fonctionnel, il permettra de mesure la charge que peut supporter votre
infrastrcture sous des conditions données. Evidemment, une des conséq uence
peut-être de faire ressortir de manière flagrante une consommation an ormale
de mémoire MAIS sans vous en donner la cause réelle. Encore faut-i l
reconnaitre une utilisation anormale de mémoire ;) et sa non-libérati on
Donc pour valider du code sans en posséder la source, il faut en passer par:
- Effectuer des tests unitaires toute en utilisant Le tracing asp.net +
SharePoint et/ou en attacheant un debugger au processus w3wp.exe et en
analysant le comportment
- Si vous souhaitez détecter les memory leak an particulier, vous pouve z
tester, sans garantie de résultats toutefois, l'outil SPDisposecheck. L isez
le blog de l'auteur, il contient des infos très utiles:http://blogs.msd n.com/rogerla/archive/2008/02/12/sharepoint-2007-and-...
- Utiliser des outils de type procmon (sysinternals) afin de tracer le
comportement au niveau système d'exploitation
L'idéal est, à priori, de passer par un cahier des charges assez dé taillé
qui spécifie la manière donc les solutions sharepoint doivent de comp orter
de manière fonctionnelle et technique ainsi que la manière de les d élivrer
par ex.
--
Marc [MCSE, MCTS, MVP]
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog:http://www.marc-antho-etc.net/blog/]
__________ Information from ESET NOD32 Antivirus, version of virus signat ure database 3961 (20090325) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
(re) Merci Marc pour cette réponse express
C'est bien à SPDisposeCheck que je pensais... (mais il me semble
qu'il ne verifie pas tout non plus)
Pour le reste, il faut donc relever les manches et se lancer :)
> Nous travaillons avec une société qui développe nos modèles de sites > et autres webparts Sharepoint.
>>> Comment nous assurer, sachant que nous ne disposons pas toujours du c ode >>> source, que les développements effectués sont corrects ? (c'est à dire >>> que les objets sont bien libérés, qu'il n'y a pas de fuite mémo ire, ou >>> que les modèles de site sont correctement implémentés)
> A priori, la seule chose que l'on puisse faire sont des tests de > montée en charge, non ? (sharepoint stress tool )
> Je crois avoir vu qu'il existe des outils permettant de valider des > développements... >>> lesquels utilisez vous ?
On pourrait écrire un livre sur les bonnes pratiques en ce qui concerne les tests ;) mais en version courte voilà comment moi je vois les choses.
Un stress-test ne permet pas de tester une solution sur le plan technique ou fonctionnel, il permettra de mesure la charge que peut supporter votre infrastrcture sous des conditions données. Evidemment, une des conséq uence peut-être de faire ressortir de manière flagrante une consommation an ormale de mémoire MAIS sans vous en donner la cause réelle. Encore faut-i l reconnaitre une utilisation anormale de mémoire ;) et sa non-libérati on
Donc pour valider du code sans en posséder la source, il faut en passer par: - Effectuer des tests unitaires toute en utilisant Le tracing asp.net + SharePoint et/ou en attacheant un debugger au processus w3wp.exe et en analysant le comportment - Si vous souhaitez détecter les memory leak an particulier, vous pouve z tester, sans garantie de résultats toutefois, l'outil SPDisposecheck. L isez le blog de l'auteur, il contient des infos très utiles:http://blogs.msd n.com/rogerla/archive/2008/02/12/sharepoint-2007-and-... - Utiliser des outils de type procmon (sysinternals) afin de tracer le comportement au niveau système d'exploitation
L'idéal est, à priori, de passer par un cahier des charges assez dé taillé qui spécifie la manière donc les solutions sharepoint doivent de comp orter de manière fonctionnelle et technique ainsi que la manière de les d élivrer par ex.
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog:http://www.marc-antho-etc.net/blog/]
__________ Information from ESET NOD32 Antivirus, version of virus signat ure database 3961 (20090325) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
(re) Merci Marc pour cette réponse express
C'est bien à SPDisposeCheck que je pensais... (mais il me semble qu'il ne verifie pas tout non plus) Pour le reste, il faut donc relever les manches et se lancer :)
