Partager via

Partie 6 : Test et approbations de l’App Store

  • Article

Test

De nombreuses applications (même les applications Android, sur certains magasins) devront passer un processus d’approbation avant d’être publiées ; le test est donc essentiel pour garantir que votre application atteint le marché (et encore moins qu’elle réussisse avec vos clients). Les tests peuvent prendre de nombreuses formes, du test unitaire au niveau du développeur à la gestion des tests bêta sur un large éventail de matériels.

Tester sur toutes les plateformes

Il existe de légères différences entre ce que .NET prend en charge sur les appareils Windows phone, tablette et de bureau, ainsi que les limitations sur iOS qui empêchent la génération de code dynamique à la volée. Planifiez le test du code sur plusieurs plateformes à mesure que vous le développez, ou planifiez le temps de refactorisation et de mise à jour de la partie modèle de votre application à la fin du projet.

Il est toujours recommandé d’utiliser le simulateur/émulateur pour tester plusieurs versions du système d’exploitation, ainsi que différentes fonctionnalités/configurations d’appareil.

Vous devez également tester sur autant d’appareils matériels physiques différents que possible.

Appareils dans le cloud

L’écosystème des téléphones mobiles et des tablettes ne cesse de croître, ce qui rend impossible le test sur le nombre toujours croissant d’appareils disponibles. Pour résoudre ce problème, un certain nombre de services offrent la possibilité de contrôler à distance de nombreux appareils différents afin que les applications puissent être installées et testées sans avoir à investir directement dans beaucoup de matériel.

App Center Test offre un moyen simple de tester des applications iOS et Android sur des centaines d’appareils différents. Pour plus d’informations, consultez Préparation d’applications Xamarin.Android et Préparation d’applications Xamarin.iOS.

Gestion des tests

Lors du test d’applications au sein de votre organization ou de la gestion d’un programme bêta avec des utilisateurs externes, il existe deux défis :

  • Distribution : gestion du processus d’approvisionnement (en particulier pour les appareils iOS) et obtention de versions mises à jour des logiciels pour les testeurs.
  • Commentaires : collecte d’informations sur l’utilisation de l’application et informations détaillées sur les erreurs qui peuvent se produire.

Il existe un certain nombre de services qui permettent de résoudre ces problèmes, en fournissant une infrastructure intégrée à votre application pour collecter et signaler l’utilisation et les erreurs, et en rationalisant le processus d’approvisionnement pour faciliter l’inscription et la gestion des testeurs et de leurs appareils.

Visual Studio App Center offre une solution à ces problèmes, en fournissant une distribution des versions de test, des rapports sur les incidents et des informations sophistiquées sur l’utilisation des applications.

Automatisation des tests

Xamarin UITest peut être utilisé pour créer des scripts de test d’interface utilisateur automatisés qui peuvent être exécutés localement ou chargés dans App Center Test.

Tests unitaires

Touch.Unit

Xamarin.iOS inclut une infrastructure de test unitaire appelée Touch.Unit qui suit les tests d’écriture de style JUnit/NUnit.

Pour plus d’informations sur l’écriture de tests et l’exécution de Touch.Unit, consultez notre documentation Test unitaire avec Xamarin.iOS .

Andr.Unit

Il existe un équivalent open source de Touch.Unit pour Android appelé Andr.Unit. Vous pouvez le télécharger à partir de github et en savoir plus sur l’outil sur le blog de @spouliot.

approbations App Store

Apple et Microsoft exploitent le seul magasin sur leurs plateformes : le App Store et la Place de marché respectivement. Les deux verrouillent leurs appareils et implémentent un processus rigoureux d’examen des applications pour contrôler la qualité des applications disponibles au téléchargement. La nature ouverte d’Android signifie qu’il existe un certain nombre d’options de magasin allant de Google Play, qui est largement disponible et n’a pas de processus de révision, à l’Appstore d’Amazon pour Android et des efforts spécifiques au matériel comme Les applications Samsung qui ont une distribution plus limitée et implémentent un processus d’approbation.

L’attente d’une révision d’une application peut être très stressante : les pressions commerciales signifient souvent que les demandes sont soumises à l’approbation avec très peu de marge d’erreur avant une date de lancement « ciblée ». Le processus lui-même peut prendre jusqu’à deux semaines et n’est pas nécessairement transparent : les commentaires sur la progression de votre demande sont limités jusqu’à ce qu’elle soit finalement rejetée ou approuvée. Le rejet peut signifier manquer une fenêtre marketing d’opportunité, en particulier s’il se produit plus d’une fois, et des semaines s’écoulent entre votre date de lancement d’origine et le moment où l’application est finalement approuvée.

Préparez-vous

Premier conseil : planifiez le lancement de votre application bien à l’avance et prévoyez un éventuel rejet et une nouvelle soumission. Pour chaque magasin, vous devez créer un compte avant d’envoyer votre application. Faites-le le plus tôt possible. Alors que l’inscription à Google Play ne prend que quelques minutes si vos applications sont gratuites, le processus devient beaucoup plus impliqué si vous les vendez et avez besoin de fournir des informations bancaires et fiscales. Les processus d’Apple et Microsoft sont tous deux beaucoup plus impliqués que ceux de Google, il peut prendre une semaine ou plus pour que votre compte soit approuvé, donc tenez compte de cette fois dans vos plans de lancement.

Une fois votre compte approuvé, vous êtes prêt à envoyer une application. Le processus réel d’envoi d’applications est décrit dans la documentation suivante :

Le reste de cette section décrit les éléments à prendre en compte pour vous assurer que votre application est approuvée sans aucun problème.

Qualité

Cela semble évident, mais les applications seront souvent rejetées parce qu’elles ne répondent pas à un certain niveau de qualité: après tout, c’est la raison pour laquelle les magasins organisés ont un processus d’approbation en premier lieu!

Les plantages sont une raison courante de rejet. S’il est trop facile de faire planter votre application, elle est garantie d’être rejetée. La plupart des développeurs ne soumettent pas leurs applications en s’attendant à ce qu’elles se bloquent, mais ils le font souvent. Testez soigneusement votre application avant de l’envoyer, en vous concentrant non seulement sur vous assurer que tout fonctionne, mais également sur le fait que vous gérez les scénarios d’erreur mobile courants tels que les problèmes réseau et les contraintes de ressources telles que la mémoire ou l’espace de stockage. Utilisez à la fois le simulateur et les appareils physiques pour tester : quelle que soit l’exécution du code dans un simulateur, seul un appareil peut démontrer les performances réelles d’une application. Utilisez autant d’appareils différents que vous pouvez trouver et inscrivez une équipe de bêta-testeurs si vous le pouvez . Les services tiers peuvent vous aider à gérer la distribution bêta et les commentaires.

Tous les systèmes d’exploitation mobiles vont tuer une application qui ne démarre pas assez rapidement. La durée autorisée varie, mais en général, les applications doivent s’efforcer d’être réactives en quelques secondes et d’utiliser des tâches en arrière-plan pour effectuer tout travail qui prendrait plus de temps. Les applications qui prennent trop de temps à charger ou qui ne sont pas suffisamment réactives en utilisation régulière seront rejetées. Fournissez toujours des commentaires de l’utilisateur lorsque quelque chose se produit en arrière-plan, ou que l’application semble s’être plantée et, une fois de plus, être rejetée.

Vérifier vos cas edge

Un piège courant pour les développeurs consiste à ne pas résoudre les cas de périphérie, en particulier ceux qui nécessitent une nouvelle configuration de leur simulateur ou de leur appareil pour effectuer un test correct. Il peut être facile d’oublier que tous les clients ne vont pas « autoriser » votre application à accéder à leur emplacement, car une fois que le développeur a accepté la demande une seule fois, ils ne seront plus jamais invités. Les autorisations et l’utilisation du réseau sont spécifiquement axées sur pendant le processus d’approbation, ce qui signifie qu’une légère surveillance dans ces domaines peut entraîner un rejet.

La liste suivante est un bon point de départ pour la vérification des cas de périphérie qui ont peut-être été manqués :

  • Les clients peuvent « refuser » l’accès aux services . En particulier dans iOS, l’accès aux données telles que les informations de géolocalisation n’est fourni que si l’utilisateur accorde l’autorisation à votre application. Les testeurs d’application doivent fréquemment réinstaller l’application dans son état initial et interdire toute demande d’autorisation pour s’assurer que l’application se comporte correctement. Activez et désactivez l’autorisation pour vérifier le comportement correct lorsque les clients changent d’avis.
  • Les clients sont partout : ne supposez pas qu’une application ne sera utilisée que dans la ville ou le pays où elle a été développée ! Le code qui fonctionne avec les coordonnées GPS, les valeurs de date et d’heure et les devises peut tous être affecté par les paramètres de localisation et de paramètres régionaux du client. Toutes les plateformes proposent un simulateur qui vous permet de spécifier des emplacements et des paramètres régionaux différents . Utilisez-le pour tester des emplacements dans d’autres hémisphères et avec des cultures qui mettez en forme des dates et des devises différemment. Les valeurs de latitude et de longitude peuvent être positives ou négatives, le séparateur décimal peut être un point ou une virgule, et les dates peuvent être mises en forme de plusieurs façons - traitez-le!
  • Connexions réseau lentes : les développeurs d’applications travaillent souvent dans un « monde idéal » de connectivité réseau rapide et toujours opérationnelle, ce qui n’est évidemment pas le cas dans le monde réel. Les tests avec une connectivité réseau lente (par exemple, une connexion 3G médiocre) et sans accès réseau sont essentiels pour vous assurer que vous n’expédiez pas d’application buggy. Le processus d’approbation inclut toujours un test avec l’appareil en mode avion. Assurez-vous donc que vous l’avez testé par vous-même.
  • Le matériel varie : n’oubliez pas de tester le matériel le plus ancien et le plus lent que vous prévoyez de prendre en charge. Deux aspects peuvent affecter votre application : les performances, qui peuvent être inutilisables sur un appareil plus ancien, et la prise en charge des fonctionnalités matérielles telles qu’une caméra, un microphone, un GPS, un gyroscope ou un autre composant facultatif. Les applications doivent se dégrader correctement (et ne pas se bloquer) lorsqu’un composant n’est pas disponible.

Les recommandations sont plus qu’un simple « guide »

Apple est célèbre pour être strict quant à l’adhésion à ses directives d’interface humaine, car l’une des forces clés de sa plateforme est la cohérence (et l’augmentation perçue de la facilité d’utilisation). Microsoft a adopté une approche similaire avec les applications Windows implémentant le Système Fluent Design. Le processus d’approbation des deux plateformes implique que votre application soit évaluée pour son adhésion à la philosophie de conception pertinente.

Cela ne veut pas dire que l’innovation de l’interface utilisateur n’est pas prise en charge ou encouragée, mais il y a certaines choses que vous ne devez pas faire ou que votre application sera rejetée.

Sur iOS, cela inclut l’utilisation incorrecte des icônes intégrées ou l’utilisation d’autres métaphores bien établies de manière non cohérente ; par exemple, l’utilisation de l’icône « composer » pour autre chose que la création de contenu.

Les développeurs Windows doivent faire preuve de la même prudence ; une erreur courante consiste à ne pas prendre correctement en charge le bouton Retour matériel conformément aux instructions de Microsoft.

Encouragez vos concepteurs à lire et à suivre les instructions de conception pour chaque plateforme.

Implémentation des fonctionnalités de Platform-Specific

Les choses sont un peu plus strictes lorsqu’il s’agit d’implémenter des services spécifiques à la plateforme, en particulier sur iOS. Pour éviter le rejet automatique par Apple, il existe certaines règles à suivre avec les fonctionnalités iOS suivantes :

  • Achats dans l’application : les applications ne doivent PAS implémenter de mécanismes de paiement externes pour les produits numériques, y compris la devise du jeu, les fonctionnalités de l’application, les abonnements aux magazines et bien plus encore. Les applications iOS doivent utiliser le service iTunes d’Apple pour ce type de fonctionnalité. Il existe une faille : les applications telles que le lecteur Kindle et certaines applications basées sur un abonnement vous permettent d’acheter du contenu ailleurs qui est attaché à un « compte » auquel vous pouvez ensuite accéder via l’application, mais dans ce cas, l’application ne doit pas contenir de liens ou de références au processus d’achat hors application (ou, une fois de plus, elle sera rejetée).
  • Sauvegarde iCloud : avec l’avènement d’iCloud, les réviseurs d’Apple sont beaucoup plus stricts quant à la façon dont les applications utilisent le stockage (pour s’assurer que l’expérience de sauvegarde à distance du client est agréable). Les applications qui gaspillent de l’espace de stockage pouvant être sauvegardé peuvent être rejetées. Par conséquent, utilisez le dossier Cache de manière appropriée et suivez les autres instructions relatives au stockage d’Apple.
  • Kiosque à journaux : les applications de journaux et de magazines conviennent parfaitement au kiosque à journaux d’Apple, mais les applications doivent implémenter au moins un abonnement de renouvellement automatique et prendre en charge le téléchargement en arrière-plan pour être approuvées.
  • Cartes : il est de plus en plus courant d’ajouter des superpositions et d’autres fonctionnalités à des cartes mobiles, mais veillez à ne pas masquer les informations sur les « crédits » de la carte (telles que le logo Google dans iOS5), car cela entraînerait un rejet.

Gérer vos métadonnées

Outre les problèmes techniques évidents qui peuvent entraîner le rejet d’une application, il existe des aspects plus subtils de votre soumission qui pourraient entraîner un rejet, en particulier en ce qui concerne les métadonnées (description, mots clés et images marketing) que vous envoyez avec votre application pour affichage dans le App Store ou la Place de marché.

  • Imagerie : suivez les instructions de la plateforme pour les icônes d’application et les images de stockage. N’utilisez pas d’images déposées, nous avons vu les applications être rejetées parce que leurs icônes comportaient un dessin d’un iPhone!
  • Marques commerciales : évitez d’utiliser des marques commerciales autres que les vôtres. Les applications ont été refusées pour avoir mentionné des marques dans la description de l’application ou même dans les mots clés sur les App Store d’Apple.
  • Description : n’utilisez pas le mot « bêta » ou n’indiquez en aucune façon que l’application n’est pas prête pour les heures de grande écoute. Ne mention pas d’autres plateformes mobiles (même si votre application est multiplateforme). Plus important encore, assurez-vous que l’application fait exactement ce que vous dis-le fait. Si vous répertoriez un ensemble de fonctionnalités dans votre description, il vaut mieux voir comment utiliser chacune de ces fonctionnalités ou vous obtiendrez un rejet « la fonctionnalité mentionnée dans la description de l’application n’est pas implémentée ».

Mettez autant d’efforts dans les métadonnées de l’application que dans le développement et le test. Les demandes SONT rejetées pour les infractions mineures dans les métadonnées, il est donc utile de prendre le temps de bien les faire.

Magasins d’applications : pas pour tout le monde

L’objectif principal des magasins sur chaque plateforme est la distribution des consommateurs, à savoir la possibilité d’atteindre autant de clients que possible. Bien que toutes les applications ne soient pas destinées aux consommateurs, il existe une base croissante d’applications internes et extranet qui nécessitent une distribution limitée aux employés, aux fournisseurs ou aux clients. Ces applications ne sont pas « à vendre » et n’ont pas besoin d’approbation, car le développeur contrôle la distribution à un groupe fermé d’utilisateurs. La prise en charge de ce type de déploiement varie selon la plateforme.

Android offre la plus grande flexibilité à cet égard : les applications peuvent être installées directement à partir d’une URL ou d’une pièce jointe d’e-mail (tant que la configuration de l’appareil le permet). Cela signifie qu’il est trivial de créer et de distribuer des applications d’entreprise internes ou de publier des applications à des clients ou fournisseurs spécifiques.

Apple fournit une option de déploiement interne aux développeurs inscrits au programme iOS Developer Enterprise, qui contourne le processus d’approbation App Store et permet aux entreprises de distribuer des applications internes à leurs employés. Malheureusement, cette licence ne répond pas au besoin de distribution d’applications de type extranet à d’autres groupes fermés de clients ou de fournisseurs. Déploiement d’entreprise (et ad hoc)

résumé App Store

Le processus de révision peut être intimidant, mais comme le reste du cycle de vie du développement, vous pouvez vous aider à garantir la réussite avec une planification et une attention aux détails. Tout se résume à quelques étapes simples : lire et comprendre les instructions d’interface utilisateur auxquelles vous devez adhérer, suivre les règles si vous implémentez des fonctionnalités spécifiques à la plateforme, tester minutieusement (puis tester d’autres) et enfin vérifier que les métadonnées de votre application sont correctes avant de les soumettre.

Un dernier conseil aux développeurs qui publient sur Google Play : l’absence de processus d’approbation peut sembler faciliter votre travail, mais vos clients seront encore plus exigeants qu’une équipe de révision. Suivez ces instructions comme si votre application pouvait être rejetée, sinon ce seront vos clients qui effectuent le rejet.