Mon travail implique des tests de performance au niveau du système avec des outils tiers dont je n'ai pas les sources. Je suis également en train de tester Windows, et je peux utiliser des symboles de débogage mais pas de code source Windows. Je voudrais une façon quantitative de décrire les zones de l'OS hôte mes tests couvrent. Il y a deux grandes étapes à cela: identifier quelles DLL et fonctions je veux regarder, et ensuite déterminer comment profiler les appels à ceux-ci.Comment mesurer la couverture du code API Windows des tests de niveau d'application
Idées pour la couverture:
- Toutes les fonctions de kernel.dll, ntdll.dll, user.dll, etc ... Le principal construit en modules. Cela pourrait être une énorme quantité d'overkill et identifiera probablement beaucoup de lacunes qui ont seulement à faire avec des fonctionnalités obsolètes.
- Juste les noms de modules pour toutes les DLL utilisées par l'application cible. Pas aussi détaillé, mais aussi moins susceptible de manquer des fonctionnalités clés dans l'application cible.
- Modules spécifiques à l'application comme d3d10.dll pour les applications DirectX 10.
- Blocs de base. Je suppose que ce serait une quantité de travail de thèse de doctorat.
idées de profilage:
- analyse graphique appel Run VTune sur tous mes tests. Ce genre de travaux, mais semble fournir une vue limitée de quelles fonctions intégrées sont appelées.
- Instrumentation dynamique de l'application avec quelque chose comme Pin ou DynamoRIO. Possible con: lent. Intercepter les appels avec WinDbg.
- Je ne sais pas si cela serait plus facile ou plus rapide que Pin.
- Analyse statique à l'aide d'un outil de démontage comme IDA Pro.
Existe-t-il des travaux publiés dans ce sens sous Windows? Avez-vous déjà utilisé un de ces outils pour accrocher ou enregistrer assez que vous pourriez le recommander?