Test d'endurance

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.

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."

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

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.