Base de tests de scénarios d'erreur avec Application Verifier

Présentation du cas

Cette intervention ne s’est pas limitée à corriger un défaut isolé. Nous avons utilisé Application Verifier pour mettre en place la base de tests des scénarios d’erreur elle-même. L’objectif n’était pas seulement de trouver l’incident présent, mais de préparer un système dans lequel le prochain défaut serait plus facile à détecter et à analyser.

Symptôme

• Les tests du fonctionnement normal exposaient difficilement les défauts des chemins d’erreur
• Les anomalies liées au manque de ressources ou aux handles n’apparaissaient que dans des conditions proches de la production
• Les procédures d’analyse risquaient de dépendre de la personne qui les menait

Contraintes

• Épuiser réellement les ressources d’une machine est coûteux et risqué
• Il fallait faire apparaître en amont les défauts aux frontières natives et Win32
• La base devait pouvoir être réutilisée lors de futurs incidents

Ce que nous avons observé

• Les réglages d’Application Verifier tels que Handles, Heaps et Low Resource Simulation
• Les traces des chemins d’erreur, notamment !htrace et page heap
• La correspondance entre nos journaux de cycle de vie et les informations d’arrêt de Verifier

Comment nous l’avons réduit

Nous avons d’abord distingué ce qui pouvait être suivi avec les journaux ordinaires de ce qui ne devenait visible qu’avec Application Verifier. Nous avons ensuite appliqué Verifier à un chemin d’exécution placé dans un banc de test, afin de faire apparaître plus tôt les anomalies difficiles à reproduire.

Comment nous l’avons amélioré

• Mise en place d’une base réutilisable pour provoquer volontairement les chemins d’erreur
• Observation des anomalies de handles et de tas dans des boucles beaucoup plus courtes
• Organisation des points d’observation pour les réinjecter dans les revues de conception et la prévention des régressions

Services associés à cette étude de cas

Cette étude relève directement de l’analyse de dysfonctionnements et de la recherche de cause, pour reproduire et expliquer des défauts difficiles. Elle rejoint aussi le conseil technique et la revue de conception, lorsqu’il faut décider jusqu’où intégrer les tests d’erreur et les points d’observation dans l’architecture du système.

Articles connexes

Contactez-nous

Si cette page correspond à votre situation, décrivez-nous le contexte actuel et le type d’aide dont vous avez besoin.