Forum des testeurs
Vous souhaitez réagir à ce message ? Créez un compte en quelques clics ou connectez-vous pour continuer.
Forum des testeurs

Forum pour se réunir entre testeurs logiciels et parler des méthodes mais aussi des logiciels de management (TestLink, Salomé,Test Director...), et d'automatisation (Auto-it, Sélénium, Quick Test Pro...).

Derniers sujets
» Club Qualité Logicielle 2020, plus que quelques jours pour vous inscrire !
Test d'endurance EmptyMar 10 Nov - 18:50 par TLNX

» Blog sur le test logiciel
Test d'endurance EmptyMar 31 Jan - 10:59 par ehbientestezmaintenant

» Exporter des données d'ALM vers Excel (Add-in)
Test d'endurance EmptyMar 31 Jan - 2:16 par Rules7

» Testeuse HP !
Test d'endurance EmptyMar 31 Jan - 2:04 par Rules7

» Nouvelle testeuse !
Test d'endurance EmptyMar 24 Jan - 14:10 par rachidos_2017

» Nouveau Testeur
Test d'endurance EmptyMar 24 Jan - 14:09 par rachidos_2017

» Installation HP QC 12.5
Test d'endurance EmptyMar 24 Jan - 13:53 par rachidos_2017

» Un petit nouveau
Test d'endurance EmptyMar 8 Nov - 20:41 par RegisK

» A newbie in the domain
Test d'endurance EmptyVen 29 Avr - 10:47 par Roundcat

Rechercher
 
 

Résultats par :
 


Rechercher Recherche avancée

Le Deal du moment : -50%
-50% Baskets Nike Air Huarache
Voir le deal
64.99 €

Vous n'êtes pas connecté. Connectez-vous ou enregistrez-vous

Test d'endurance

3 participants

Aller en bas  Message [Page 1 sur 1]

1Test d'endurance Empty Test d'endurance Ven 28 Mai - 18:35

dmereaux


Modérateur
Modérateur

Bonjour,

Ma hiérarchie m'a demandé si on pouvait éviter les fuites mémoires en augmentant le nombre de tests. J'ai répondu qu'il était impossible de tout tester à cause de la combinatoire (configuration, use case, combinaison de use case, coût) et qu'il valait mieux être plus dans le préventif, comme des règles de codage, des tests à des niveaux plus bas (ensemble de composants), revue de code, outils dédiés etc ... Bien entendu les tests d'endurance sont à faire avec des cas d'utilisations réalistes.
Pouvez-vous me dire comment vos sociétés respectives abordent cette problématique?

Cordialement.
Dominique.

http://www.qualifiez.fr

2Test d'endurance Empty Re: Test d'endurance Ven 28 Mai - 19:23

edno

edno
Testeur junior
Testeur junior

Bonjour,

Faire la chasse aux fuites mémoire n'est pas une des tâche les plus aisée pour les testeurs.
Il convient avant tout de bien identifier le périmètre du produit, car les fuites mémoires sont caractéristique de l'architecture et du langage de programmation choisi.
Comme vous l'indiquez, le mieux est de prévenir les fuites mémoire par des bonnes pratiques et une bonne maitrise de sa conception.
Dans un premier temps, lors de votre campagne de test vous pouvez peut être mettre des compteurs de performance en place pour évaluer le profil d'utilisation des ressources, s'il n'y a pas de comportement choquant. Il n'est peut être pas utile d'aller investiguer plus loin.
Selon moi, une bonne façon de faire apparaître une fuite mémoire, c'est de faire monter l'application en charge. Car les fuites mémoires sont issues d'un problème de désallocation des données manipulées par le programme, celle-ci restent allouées en mémoire alors que le traitement correspondant est terminé et la prochaine exécution dudit traitement aura donc besoin d'un nouvel emplacement mémoire qui sera à son tour abandonné... ainsi de suite.
Lorsqu'un système ne permet pas de réaliser facilement une montée en charge, la seconde solution est celle que vous proposer à savoir l'endurance sur un cas d'utilisation le plus complet possible (éventuellement une suite de CU correspond au workflow métier complet).
Une fois la présence de fuite mémoire prouvée, il faut être capable de cibler la source du problème et identifier son risque sur l'utilisation du système. En effet, est-ce que le jeu en vaut la chandelle ? à savoir est-ce que l'investissement test/forensic/debug sert à quelque chose.
Pour exemple : Sur un projet passé, un système d'analyse et de traitement vidéo fonctionnant 24/24h (théoriquement) déjà gourmand en ressource avait une fuite mémoire. Nous savions la reproduire dans notre environnement de test, nous avions la tendance de la fuite et pouvions prédire le moment du seuil critique (4 jours de fonctionnement), détecté en test d'endurance (5j). Malheureusement, après de multiples discussions avec les développeurs sur ce sujet, ils étaient incapables d'identifier ou de reproduire le problème. Côté test, nous avons finalement isolé le problème qui était du à un comportement spécifique à une architecture définie qui n'était pas nécessairement la cible de production. Donc le problème a été classé sans suite, bien que latent et prouvé. Il a été décider d'ajouter une recommandation d'exploitation qui est de redémarrer quotidiennement les serveurs de traitement à titre préventif... Et la réponse finale pour clore le débat : "de toute façon l'architecture et le coeur seront revus, donc la fuite est hors sujet pour la prochaine version." Cool

En espérant vous avoir fourni quelques éléments de réponse.

http://www.factoryconsulting.com

3Test d'endurance Empty Re: Test d'endurance Jeu 5 Mar - 16:05

TheTestMakerManager

TheTestMakerManager
Testeur junior
Testeur junior

Si ce sont des programmes en .Net, il est assez facile de voir les fuites mémoires  par l'utilisation d'outils comme .Net memory profiler .
Cela peut se faire en live ou en différé avec un Dump de la mémoire.
L'idée est de prendre une image (premier dump)  au début puis a la fin des tests. Ensuite il suffit de comparer. Si des objets restes en mémoire  (une différence positive) c'est vraisemblablement une fuite.... 
De plus comme c'est du .Net, l'outil  donne directement les objets concernés.

http://thetestmakermanager.free.fr

Contenu sponsorisé



Revenir en haut  Message [Page 1 sur 1]

Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum