Il y a quelques mois, nous avons décrit nos rapports d'adoption. Ces rapports vous offrent des informations sur les téléchargements, le taux d'adoption, les évaluations des utilisateurs et les taux d'utilisation, autant de données qui vous aident à déterminer la popularité de votre application. Aussi utiles soient-ils, les rapports d'adoption ne constituent qu'une partie des rapports que nous mettons à votre disposition dans le Windows Store. Ainsi, nous proposons également des rapports axés autour de la qualité des applications. Ceux-ci vous aident à mesurer et à améliorer la qualité de votre application. Dans ce billet, Kalyan Venkatasubramanian, chef de projet, décrit les rapports de qualité du Windows Store et explique comment vous pouvez les utiliser pour améliorer vos applications.

-- Antoine Leblond


Pour commencer, nous devons définir ce que nous entendons par « qualité ». En effet, les critères déterminant la qualité d'une application sont nombreux : confort d'utilisation, fiabilité, sécurité, etc. Dans le cas du Windows Store, nous avons choisi d'axer nos rapports de qualité autour de données analytiques basées sur la fiabilité de votre application, telle qu'elle est ressentie par les clients.

Pour accéder aux rapports de qualité, il vous suffit d'afficher la page Statistiques de l'application de votre application. Dans cette page, cliquez sur le lien Qualité pour accéder à l'écran des rapports de qualité.

Rapports de qualité

Exemple d'écran de rapports de qualité, disponible dans le tableau de bord.

Ces rapports vous aident à évaluer la qualité de votre application, en surveillant son taux de défaillance, c'est-à-dire le nombre de défaillances rencontrées par les clients. Une défaillance correspond à la fermeture inattendue d'une application pour l'une des raisons suivantes :

  1. Incident
  2. Non-réactivité de l'application (blocage)
  3. Exception JavaScript non gérée

(Remarque : les exceptions JavaScript non gérées, que nous appelons tout simplement « exceptions JavaScript », ne s'appliquent bien évidemment qu'aux applications écrites en utilisant JavaScript.) )

Grâce à ces rapports, vous pouvez :

  1. Évaluer la qualité des différentes versions de votre application publiées sur le Windows Store. Vous savez ainsi si l'expérience utilisateur des clients de votre application s'améliore au fil des versions.
  2. Améliorer la qualité de votre application. Vous pouvez améliorer la qualité de votre application en identifiant et en comprenant les principales causes des défaillances rencontrées par vos clients avec la dernière version publiée sur le Windows Store. Une fois que vous avez identifié les principales défaillances, vous pouvez les corriger et publier une mise à jour de votre application sur le Windows Store.

Évaluez la qualité de votre application

Comme nous l'avons expliqué dans le paragraphe ci-dessus, vous pouvez déterminer la qualité d'une application à partir du nombre de défaillances. Les taux de défaillance sont calculés pour chaque type de défaillance : incidents, blocages et exceptions JavaScript non gérées (dans le cas d'applications JavaScript). Les données permettant de calculer les taux de défaillance sont collectées à partir d'un échantillon aléatoire d'ordinateurs (constituant le panel de qualité) sur lesquels votre application est utilisée. Pour que l'échantillon soit suffisamment représentatif et permette de calculer les taux de défaillance avec fiabilité, le panel de qualité doit comporter au moins 500 ordinateurs. Si le panel de qualité comporte moins de 500 ordinateurs, le rapport contient un avertissement indiquant que les données affichées sont issues d'un échantillon qui n'est pas représentatif d'un point de vue statistique. Nous continuerons à ajuster ce seuil afin de mettre à votre disposition des informations précises le plus rapidement possible.

Ces taux de défaillance correspondent au nombre moyen de défaillances rencontrées sur un ordinateur au cours des 15 premières minutes d'utilisation active. En examinant les données issues de toutes les applications de l'écosystème PC, nous avons réalisé que la fiabilité mesurée d'une application tend à se stabiliser au fil du temps : dès lors que l'application passe un certain temps d'utilisation, les taux de défaillance évoluent peu. Dans le cas des applications de style Metro de la Consumer Preview, cette stabilisation intervient après environ 15 minutes d'utilisation. Ce délai nous permet de vous fournir des données à la fois précises et opportunes. Si nous allongions cette durée, nous serions obligés d'attendre plus longtemps avant de vous fournir des rapports. Comme pour la taille du panel de qualité, nous continuerons à ajuster ce seuil en fonction de l'évolution du marché des applications de style Metro. En outre, lorsque nous calculons les taux de défaillance, nous supprimons les éventuelles aberrations, de façon à ce qu'elles ne faussent pas les résultats.

Voici un exemple de graphique de taux de défaillance.

Exemple de graphique de taux de défaillance

Améliorez la qualité de votre application

Dans les paragraphes précédents, nous avons expliqué comment vous pouvez suivre l'évolution de la qualité de votre application d'une version à l'autre. Nous savons également que vous souhaitez connaître les principales défaillances rencontrées par vos clients dans la dernière version de votre application. Ainsi, nous fournissons également une liste des défaillances courantes survenant dans la dernière version de votre application, classées par fréquence. La fréquence des défaillances correspond au nombre total d'occurrences de cette défaillance rencontrées par vos clients.

N'oubliez pas que les taux de défaillance sont calculés à partir des ordinateurs composant le panel et qu'ils répondent à des critères bien précis concernant l'utilisation active initiale de votre application. Les données figurant dans la liste des défaillances les plus courantes sont recueillies auprès de tous les clients de votre application. Cependant, que se passe-t-il si la majorité des clients de votre application n'ont pas pu atteindre les critères d'utilisation en raison des défaillances qu'ils rencontrent ? Dans une telle situation, le taux de défaillance est nul, mais vous continuez à voir les principales défaillances rencontrées par votre application, comme indiqué ici :

Exemple de rapport montrant les défaillances les plus courantes.

En mettant à votre disposition la liste des défaillances courantes rencontrées par vos clients, indépendamment du calcul des taux de défaillance (par exemple pour les incidents, comme sur l'image ci-dessus) et en élargissant le périmètre de chaque collecte de données, nous vous permettons d'identifier et de corriger les défaillances rencontrées par l'ensemble de vos clients. En outre, vous pouvez ainsi être tenu au courant des défaillances survenant dans votre application rapidement après la publication et prendre les mesures nécessaires.

Incidents et blocages

Dans le cas des incidents et des blocages, nous vous indiquons les cinq défaillances les plus courantes survenant dans la dernière version de votre application. Les chiffres correspondent au nombre total d'occurrences de chaque défaillance rencontrées par tous les clients de votre application. Le lien Télécharger vous permet de télécharger un fichier .cab contenant le vidage de processus de la défaillance en question.

Exemple montrant les incidents les plus courants survenant dans une application

Une défaillance est identifiée de façon unique par un nom de défaillance. Voici un exemple de nom de défaillance, dans le cas d'un incident ou d'un blocage :

NULL_CLASS_PTR_READ_c0000005_mydll.dll!myfunc::DoOp

Le nom de la défaillance se compose de plusieurs éléments :

  • Classe du problème (NULL_CLASS_PTR_READ)
  • Code d'erreur (c0000005)
  • Symbole (mydll.dll!myfunc::DoOp)

Remarque : pour en savoir plus sur la façon dont nous déterminons la cause première d'une défaillance, cliquez ici. Même si ce billet de blog ne porte pas spécialement sur les applications de style Metro, il est très utile pour comprendre en détail les opérations de collecte et de traitement des défaillances.

Vous pouvez déterminer la raison de l'incident ou du blocage survenant dans votre application en téléchargeant le fichier .cab correspondant. Le fichier .cab contient le vidage de processus correspondant à la défaillance survenue dans votre application. Ainsi, vous disposez de l'arborescence des appels de procédure et d'autres informations détaillées concernant la défaillance.

Voici les éléments indispensables pour traiter le fichier .cab et extraire les arborescences d'appels de procédure :

  1. Installez WinDbg.exe sur votre ordinateur.
    WinDbg.exe est l'outil de débogage recommandé pour obtenir les arborescences d'appels de procédure issues du vidage de processus. Si WinDbg.exe n'est pas installé sur votre ordinateur, vous pouvez l'obtenir ici.
  2. Symboles de l'application.
    Pour obtenir les arborescences d'appel de procédure issues du vidage de processus, vous devez disposer des symboles correspondant à la version actuelle de votre application dans le Windows Store.

Accès aux arborescences d'appel de procédure dans le cas des incidents et des blocages

La procédure décrite ici n'est pas un didacticiel de débogage approfondi. Néanmoins, elle vous permet d'obtenir les arborescences d'appel de procédure relatives aux défaillances de votre application.

  1. Cliquez sur le lien Télécharger figurant près du nom de la défaillance pour l'une des défaillances rencontrées dans votre application (incident ou blocage). Supposons que le nom de la défaillance soit le suivant :
    STATUS_INTEGER_DIVIDE_BY_ZERO_c0000094_FaultoidEx.Engine.dll!?__abi_FaultoidEx_Engine___IEngineServerPublicNonVirtuals____abi_DivideByZero
  2. Enregistrez le fichier .cab à l'emplacement de votre choix.
  3. Exécutez WinDbg.exe.
  4. Cliquez sur File (Fichier) > Open Crash Dump (Ouvrir un vidage sur incident).

    Écran principal de WinDbg.
  5. Dans la boîte de dialogue Open Crash Dump (Ouvrir un vidage sur incident), indiquez l'emplacement du fichier enregistré à l'étape 2, puis ouvrez-le.

    Exemple d'ouverture de fichier dans WinDbg.
  6. Cliquez sur File (Fichier) > Symbol File Path (Chemin du fichier de symboles) et saisissez le chemin d'accès des symboles correspondant à la version disponible sur le Windows Store. Cochez la case Reload (Recharger), puis cliquez sur OK.

    Exemple de définition du chemin des symboles dans WinDbg.

    Si vous souhaitez indiquer le chemin des symboles publics de Microsoft (pour les fichiers binaires autres que ceux de votre application), utilisez le format suivant :
    Srv*;<<chemin d'accès de vos symboles>>
    Si le chemin d'accès de vos symboles est c:\symbols, le chemin d'accès équivalent conforme aux consignes ci-dessus est
    Srv*;c:\symbols
  7. Dans l'invite de la fenêtre Commande, saisissez !analyze –v et appuyez sur Entrée.

    Exemple d'accès à une arborescence d'appels de procédure dans WinDbg.

    Les erreurs figurant dans la capture d'écran ci-dessus sont dues au fait que les symboles de certaines DLL ne correspondent pas. Le fait de définir le chemin d'accès aux symboles (voir l'étape 7) réduit le nombre d'erreurs visibles, mais si l'erreur correspond aux DLL et aux fichiers EXE de votre application, vous devez être vigilant. Si les erreurs et les avertissements concernent les fichiers binaires de votre application, cela signifie que le débogueur n'a pas trouvé les symboles corrects de votre application. Vous devez identifier le chemin d'accès correct de l'emplacement de stockage de vos symboles et l'indiquer comme expliqué à l'étape 7.
  8. L'arborescence des appels de procédure s'affiche comme ceci dans la fenêtre Commande :

    Exemple d'arborescence d'appels de procédure dans WinDbg.


Au vu de l'arborescence d'appels de procédure, vous pouvez constater que la défaillance est une exception de type « division par zéro », survenant dans une fonction appelée DivideByZero dans FaultoidEx.Engine.dll. Cela correspond au nom de la défaillance identifiée à l'étape 1, ce qui vous permet de mieux comprendre la défaillance et de savoir comment la corriger.

Exceptions JavaScript

Le taux de défaillance et les exceptions JavaScript les plus courantes concernent uniquement les applications qui utilisent JavaScript. Dans le cas des exceptions JavaScript, vous avez accès aux 15 défaillances les plus fréquentes survenant dans la dernière version de votre application. Nous avons décidé de présenter dans la liste un nombre plus important de défaillances JavaScript, car d'après nos données télémétriques, les exceptions JavaScript sont plus fréquentes que les autres types de défaillances. En vous proposant ainsi une liste plus fournie de défaillances liées aux exceptions JavaScript, nous vous aidons à améliorer la qualité de votre application avec la même cohérence que les incidents et les blocages.

Exemple de rapport montrant les exceptions JavaScript courantes

Par défaut, nous commençons par afficher la liste des cinq défaillances principales liées à des exceptions JavaScript. Le bouton Tout afficher élargit la liste de façon à afficher jusqu'à 15 défaillances.

Voici un exemple de nom de défaillance liée à une exception JavaScript :

WinRT error_8007007E_msappx://Contoso.ContosoApp8wekyb3d8bbwe/ContosoApp/program.js!scenario1Run

Dans le cas des exceptions JavaScript, voici de quoi se compose le nom de l'exception :

  • Valeur ErrorTypeText (WinRT error)
  • Valeur ErrorNumber (8007007E)
  • Valeur Filename_FunctionName (program.js!scenario1Run)

Accès aux arborescences d'appel de procédure dans le cas des exceptions JavaScript

Vous pouvez identifier la raison de l'exception JavaScript associée à une défaillance en suivant la procédure ci-dessous :

  1. Cliquez sur le lien Télécharger figurant près du nom d'une défaillance associée à votre application (exception JavaScript).
  2. Enregistrez le fichier .cab à l'emplacement de votre choix.
  3. Le fichier contient un fichier dont le nom commence par ErrorInfo (le fichier ErrorInfo). Procédez à l'extraction du fichier et enregistrez-le à l'emplacement de votre choix.
  4. Ouvrez le fichier ErrorInfo à l'emplacement choisi à l'étape 3, à l'aide du Bloc-notes.
  5. Le fichier texte ErrorInfo text contient les arborescences d'appels de procédure associées à la défaillance. Voici un exemple :
    Exemple de fichier ErrorInfo.

Dans cet exemple, l'erreur est due à une fonction non définie. La pile d'appels conduisant à la défaillance figure également dans le fichier ErrorInfo.

Conclusion

Nous sommes convaincus que pour que votre application soit un succès, vous devez comprendre ses points faibles et améliorer sa qualité. Les rapports de qualité ont été conçus pour vous fournir des informations utiles, que vous pouvez exploiter pour améliorer votre application. Nous pensons que ces rapports vous aideront à hiérarchiser les améliorations à apporter à votre application, et à proposer rapidement des mises à jour sur le Windows Store.

Nous sommes impatients de recueillir vos impressions au sujet des rapports de qualité et des autres rapports disponibles par le biais du portail analytique.

--Venkat