La qualité mobile est le plus grand défi que les développeurs mobiles rencontrent, leurs développeurs traitant de la complexité des applications, de la fragmentation des périphériques, du cycle de publication rapide, des sessions utilisateur courtes et des attentes plus élevées des utilisateurs pour les applications mobiles. Dans cet article, Sean Sparkman vous explique les bases des tests automatisés d'interface utilisateur.
L'époque des applications mobiles à écran unique est révolue – les applications deviennent chaque jour plus complexes. Ces fonctionnalités complexes doivent être testées. Les fonctionnalités existantes doivent être testées de nouveau même lors de modifications mineures d'une autre partie de l'application. Cela peut prendre un temps précieux en termes de développement et de réduction des temps de publication.
Dans les applications mobiles grand public, les utilisateurs veulent pouvoir ouvrir une application mobile et effectuer rapidement une tâche. Si les utilisateurs ne peuvent pas démarrer leur tâche dans les trois secondes qui suivent l’application de l’icône de l’application, ils trouveront une autre application. Si un développeur d'application trouve une bonne idée, il ne faudra pas longtemps avant que quelqu'un d'autre la copie.
Tout le monde connaît la fragmentation de version sur Android. Certains fabricants ne vous permettent pas de passer à la version plus récente d’Android. Oréo a seulement un taux d'adoption de 12,1% au 23 juillet 2018, selon Google . Cela fait un an et quatre mois après sa publication.
|
Version |
Nom de code |
API |
Distribution |
||||
|
2.3.3-2.3.7 |
Pain d’épice |
10 |
0.2% |
||||
|
4.0.3-4.0.4 |
Sandwich à la crème glacée |
15 |
0.3% |
||||
|
4.1.x |
Jelly Bean |
16 |
1.2% |
||||
|
4.2. x |
17 |
1,9% |
|||||
|
4,3 |
18 |
0,5% |
|||||
|
4,3 |
KitKat |
19 |
9,1% |
||||
|
. |
Sucette |
21 |
4,2% |
||||
|
5.1 |
22 |
16,2% |
|||||
|
6 |
Marshmallow |
23 |
23.5 |
23.5 |
Nougat |
24 |
21,2% |
|
7.1 |
25 |
9,6% |
|||||
|
8 |
Oreo |
26 |
10.1 |
10.1% |
|||
|
10.1 |
27 |
2,0% |
La fragmentation du dispositif complique davantage ce problème. Il existe six densités d'écran différentes sur Android. Sur ce marché en croissance constante, vous devez être en mesure de tester votre application sur plus qu'un périphérique personnel.
Les applications Web ont plus de marge de manœuvre pour les utilisateurs. Les utilisateurs attendent plus de leurs applications mobiles. Les temps de chargement lents et les performances des applications Web sont souvent attribuables à la lenteur du réseau. Les applications mobiles étant installées sur l'appareil, les utilisateurs s'attendent à ce que l'application s'exécute plus rapidement. Même sans connexion réseau, l'application doit toujours fonctionner, même si un simple message d'erreur est affiché. Ceci est effectivement testé lors de l'examen Apple App Store. Aucune connexion réseau n'est généralement testée, mais les connexions lentes ne le sont pas. L'interface utilisateur doit toujours être réactive tout en extrayant les données d'une API, même avec une connexion lente.
Le test d'applications dans des conditions de connexion lentes et sans conditions de connexion est une bonne première étape. La prochaine étape est le test du chemin d'erreur. La gestion des conditions d'erreur peut faire ou défaire une application. Crashing est un non-non majeur. Les erreurs non gérées dans un navigateur Web ne planteront généralement pas la fenêtre du navigateur. Les applications natives plantent en cas d'erreur, arrêt complet. Si l'API est en service mais que la base de données est en panne, des erreurs inattendues peuvent survenir. De nombreux utilisateurs cesseront d'utiliser ou même de désinstaller une application si celle-ci se bloque. Si l'utilisateur est suffisamment frustré, il rédigera une critique avec une étoile basse ou nulle. Il est très difficile de revenir des critiques d’étoiles basses. L'erreur la plus courante que j'ai rencontrée est lorsqu'un développeur accède à un élément d'interface utilisateur à partir d'un thread en arrière-plan. Sur un simulateur iOS, rien ne se passera. L'élément d'interface utilisateur ne sera pas mis à jour et aucune erreur ne sera générée. Cependant, lors de l'exécution sur un périphérique physique, cela provoquera un crash. Si le développeur ne teste que sur des simulateurs, il ne découvrira jamais son erreur critique.
Les différentes méthodes de test des applications
Il existe plusieurs façons de tester une application. Les tests bêta avec les utilisateurs sont intéressants dans la mesure où ils testent avec de vrais utilisateurs, mais il est difficile d'obtenir de bons commentaires. Les tests manuels sont très lents, limitent le nombre de périphériques que vous pouvez utiliser et ne constituent pas un test réaliste. Les tests unitaires doivent toujours être effectués, mais ils doivent être complétés par des tests intégrés et sont loin d'être réalistes.
Alors, comment tester rapidement, sur un large éventail de périphériques et avec chaque version? Le test automatisé de l'interface utilisateur est la solution. Mon ensemble d'outils préféré pour automatiser les tests d'interface utilisateur est Xamarin.UITest. Il peut être écrit rapidement et facilement avec C #. Les tests peuvent appuyer sur, faire défiler, glisser, pincer, saisir du texte, etc., au sein d’une application native, qu’elle soit ou non Xamarin. Ces tests peuvent ensuite être exécutés localement sur des simulateurs et des appareils. Une fois que l'application est prête à être testée sur un ensemble plus large de périphériques physiques, ces mêmes tests peuvent être exécutés à l'intérieur de l'App Center de Microsoft sur la plupart des périphériques les plus courants sur un certain nombre de versions différentes d'iOS et d'Android.
pour commencer à écrire des tests d’UI est avec le REPL intégré de Xamarin.UITest. Si vous n’êtes pas familier avec REPL, c’est un acronyme qui signifie Read-Evaluate-Print-Loop. REPL est un excellent moyen de commencer à apprendre une nouvelle langue ou un nouveau cadre. Il vous permet d'écrire rapidement du code et de voir les résultats. La REPL de Xamarin.UITest peut être ouverte en appelant app.Repl ().
[ Test ]
public null ReplTest ()
{
app.Repl () ;
}
L'exécution d'un test avec l'appel de la méthode REPL ouvrira une console. La console est équipée de l'auto-complétion. Les développeurs peuvent suivre les étapes de la console pour tester leur application. Une fois le test terminé, la commande de copie reprend toutes les étapes utilisées dans le REPL et les place dans le presse-papiers. Enfin, le développeur peut prendre les commandes copiées et les coller dans une nouvelle méthode de test de leur projet UITest.
public null ReplTest ()
{
app .WaitForElement ( "FirstName" );
app.EnterText (a => a.Marked ( "FirstName" ), "Sean" );
app.EnterText (a => a.Marked ( "Nom" ), "Sparkman" );
app.DismissKeyboard ();
app. Tap (a => a.Marked ( "OnOff" ));
app.Tap (a => a.Marked ( "Submit" ));
. app.WaitForElement ( "Résultat" );
var label = app.Query (a => a.Marked ( "résultat" ));
Assert .AreEqual ( 1 label.Length);
Assert .AreEqual ( " Success "label [ 0 ]. Texte);
}
L'enregistrement est un excellent exemple de test permettant d'automatiser. Ce flux de travail doit être testé avec chaque version, mais un test manuel ne devrait pas être nécessaire. Un développeur peut créer plusieurs tests d’enregistrement réussis et échoués. Les tests qui échouent peuvent inclure, s’ils ne sont pas connectés à Internet, des données non valides dans les champs ou une tentative d’enregistrement en tant qu’utilisateur existant. Celles-ci sont importantes à tester avec chaque version mais prennent un temps précieux qui pourrait être utilisé pour tester de nouvelles fonctionnalités.
Une fois rédigés, les UITests peuvent être exécutés localement avec un simulateur, un émulateur ou un périphérique physique branché sur l'ordinateur d'exécution. Toutefois, cela limite le nombre de périphériques sur lesquels ces tests peuvent être exécutés. La prochaine étape consiste à télécharger dans Visual Studio App Center de Microsoft, ce qui augmente le nombre de périphériques testés. Une fois téléchargés, les appareils utilisés pour les tests peuvent être sélectionnés. Microsoft permet de tester sur des milliers d'appareils iOS et Android dans le nuage. Chaque étape du processus peut être documentée visuellement avec la méthode Screenshot. Capture d'écran permet de donner à une chaîne un nom significatif pour la capture d'écran. Cette méthode peut également fonctionner localement pour donner un aperçu de ce qui se passe avec les tests.
Source link