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
» Blog sur le test logiciel
Mar 31 Jan - 10:59 par ehbientestezmaintenant

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

» Testeuse HP !
Mar 31 Jan - 2:04 par Rules7

» Nouvelle testeuse !
Mar 24 Jan - 14:10 par rachidos_2017

» Nouveau Testeur
Mar 24 Jan - 14:09 par rachidos_2017

» Installation HP QC 12.5
Mar 24 Jan - 13:53 par rachidos_2017

» Un petit nouveau
Mar 8 Nov - 20:41 par RegisK

» A newbie in the domain
Ven 29 Avr - 10:47 par Roundcat

» Blocage de version
Mer 20 Avr - 15:37 par Clément Robion

Rechercher
 
 

Résultats par :
 


Rechercher Recherche avancée


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

Test d'endurance

Voir le sujet précédent Voir le sujet suivant Aller en bas  Message [Page 1 sur 1]

1 Test d'endurance le 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

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

edno

avatar
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

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

TheTestMakerManager

avatar
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é


Voir le sujet précédent Voir le sujet suivant Revenir en haut  Message [Page 1 sur 1]

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