Dans cet article, nous comparerons les capacités de test des applications natives et multiplateformes. Je vais partager mes impressions sur le travail avec Flutter et vous dire quels outils nous utilisons dans Surf lors des tests, pourquoi Flutter est pratique et quels problèmes nous avons rencontrés.
Les capacités de test de Flutter sont comparables à celles natives
Lorsqu'une entreprise change son approche du développement ou qu'une nouvelle technologie émerge, il est important que les capacités de test ne soient pas gravement affectées. Idéalement, lorsqu'ils travaillent avec un nouveau langage ou un nouveau cadre, les spécialistes de l'assurance qualité continuent d'utiliser la pile familière d'outils et de technologies qui ont fait leurs preuves de la meilleure façon.
Lors du test d'applications natives, chez Surf, nous utilisons l'autotest et lisons et remplaçons les packages. Nulle part sans autotests, notamment avec régression, et sans l'aide d'un proxy, la variabilité de l'application et la couverture de nombreux cas diminuent.
Il était important pour nous que les fonctionnalités familières restent lors du test des applications Flutter.
Test automatique
Surf fonctionne avec les frameworks Calabash et Ruby pour le test automatique des applications natives. Lorsque Flutter est apparu, la première chose que nous nous sommes demandée était: est-il possible de ne pas utiliser Calabash, mais en même temps de travailler pleinement avec des autotests comme nous en avons l'habitude - ou même plus cool.
Il s'est avéré que ce n'est pas seulement possible - mais même sans services tiers: dans Flutter, les tests d'intégration et les tests de widgets dans la console sont disponibles immédiatement. Notre développeur Flutter en a parlé plus en détail dans l'article sur l'autotest sur Flutter .
Les autotests sur Flutter sont à la fois multiplateformes et natifs: vous pouvez écrire des tests à l'intérieur du projet d'application, et ils fonctionneront sur les deux plates-formes. Lorsque tout le projet est devant vos yeux, vous pouvez ajouter des id-schnicks manquants ou même trouver des bogues et les corriger - c'est une autre occasion d'améliorer la qualité de l'application.
Flutter prend également en charge l'approche Behavior Driven Development - BDD. Nous l'utilisons pour les tests d'interface utilisateur. Nous avons choisi Gherkin comme langue: vous pouvez y utiliser des fichiers de fonctionnalités, écrire des scripts en anglais et en russe. C'est compréhensible, il a l'implémentation d'actions de script sans arguments supplémentaires à l'intérieur ou avec eux, la possibilité de personnaliser le lancement des autotests: par exemple, exécuter certains scripts par balises, et pas tous les tests écrits dans leur ensemble.
Pour utiliser Gherkin lors du test des applications Flutter, nous avons connecté le framework open source flutter_gherkin .
Lorsque nous avons réalisé qu'il y avait des autotests sur Flutter, nous nous sommes demandé quelles étaient les différences entre les technologies Calabash et Dart + Gherkin, quelle approche est la meilleure. Comparons-les ensemble.
1. Les fichiers de fonctionnalités sont absolument identiques pour les deux approches.
Par exemple, le script d'autorisation par code PIN sera correctement interprété à la fois dans Dart et Ruby en utilisant Calabash:
: ( )
Les deux technologies prennent en charge le russe, l'anglais et d'autres langues.
2. Les étapes de mise en œuvre sont différentes.
| Fléchette + flutter_gherkin
|
Calebasse
|
|
|
3. Flutter utilise un fichier .dart supplémentaire pour configurer et travailler avec les tests. Avec Calabash, aucun fichier unique n'existe.
À notre avis, il est impossible de dire qu'il s'agit d'un flottement à l'intérieur de Flutter ou Calabash - ce ne sont que les spécificités du travail avec des outils et des technologies spécifiques.
4.Pour la commodité de travailler avec des éléments dans l'application, il est nécessaire que chaque élément ait son propre identifiant. Lorsque vous travaillez avec des tests automatiques avec Calabash, vous devez vous assurer à l'avance que les deux plates-formes ont un identifiant dans les applications testées. Sur Dart, vous pouvez ajouter un identifiant lors du processus d'écriture des autotests, sans recharger séparément les fichiers des applications iOS et Android - c'est pratique et permet de gagner du temps.
Notre conclusion: les autotests sur Dart ne sont pas inférieurs aux autotests utilisant le framework Calabash.
Proxies
Pour augmenter la couverture des applications par cas, Surf utilise des programmes pour lire et usurper le trafic - par exemple, Charles. L'analyse de l'interaction client-serveur permet:
- Déterminez s'il existe une interaction réelle avec le backend.
- Découvrez de quel côté se situe le problème: sur le client ou sur le serveur.
- , .
- : , , . Charles , , , .
Dart a son propre client pour travailler avec le réseau. Étant donné que toutes les demandes le traversent, les paramètres nécessaires pour travailler avec un proxy doivent être saisis dans l'application. Pour la commodité des testeurs, tous les paramètres nécessaires sont placés sur un écran séparé: dans Surf, nous utilisons l'écran de débogage, que nous avons développé nous-mêmes.
L'écran de débogage est un écran de paramètres supplémentaire qui n'est disponible qu'à partir de la version de débogage et facilite les tests. Dans celui-ci, vous pouvez sélectionner le serveur requis, activer l'utilisation de la lecture et de l'enregistrement des requêtes http dans l'application, afficher le jeton fcm de l'appareil et plus encore - il existe de nombreuses possibilités de test.
L'écran de débogage est personnalisé: les développeurs y ajoutent des éléments supplémentaires à la demande des testeurs - par exemple, des champs pour configurer les proxys de l'application. Par conséquent, nous avons toutes les opportunités de travailler avec Charles: vous pouvez connecter un serveur proxy à Debug Screen sans redémarrer l'application.
Comme vous pouvez le voir, les possibilités de tester les applications Flutter ne sont pas limitées. Tout ce avec quoi nous sommes habitués à travailler en natif est pratique et facile à utiliser. C'est une bonne nouvelle.
Problèmes: bogues de framework, failles dans les bibliothèques tierces, comportement natif attendu
Les problèmes auxquels nous sommes confrontés lors du test des applications Flutter sont également natifs. On ne peut pas dire que ce sont les lacunes spécifiques de Flutter: dans toute technologie, la résolution de problèmes n'est pas toujours évidente et simple.
Voyons ce qu'il faut rechercher lors du test des applications Flutter. Averti est prévenu.
Bugs du framework Flutter
Lors des tests, nous avons rencontré un problème d'affichage et de formatage des polices sur iOS: l'espacement des lettres sur la plateforme iOS était nettement plus large que sur Android. Cela a causé beaucoup de bugs visuels.
Il s'est avéré que le problème résidait dans le cadre lui-même. Lorsque nos développeurs d'applications mobiles ont contacté les membres de la communauté des développeurs du framework Flutter pour leur demander de corriger un bug aussi désagréable, le framework a été mis à jour rapidement et l'affichage du texte sur iOS a été corrigé.
De telles situations se reproduiront sûrement. Mais cela ne peut pas être qualifié de gros problème: les membres de la communauté Flutter répondent rapidement aux problèmes, soutiennent et développent le cadre.
Failles dans les bibliothèques tierces
Sur les versions 10 et 11 d'iOS, il y avait des failles d'implémentation dans les bibliothèques tierces. Par exemple, nous corrigeions un bug lorsque l'autorisation d'accès aux notifications apparaît immédiatement au lancement de l'application, et non sur le bouton, comme prévu par la spécification technique et la conception.
De tels problèmes peuvent survenir à la fois dans la multiplate-forme et dans le natif. Ils sont résolus par des correctifs dans le projet ou en collaboration avec les développeurs de la bibliothèque.
Gérer le comportement natif attendu
Avec une utilisation et des tests à long terme des applications natives sur iOS et Android, il est facile de prédire les attentes des utilisateurs pour différents comportements d'application. Ainsi, par exemple, revenir en arrière avec un backwipe sur iOS est un geste standard. Et sur Android, vous n'en avez pas besoin.
Les boîtes de dialogue système sur les deux plates-formes sont différentes: sous iOS, vous devez demander l'autorisation d'accéder aux notifications, et sur Android, cet accès est donné par défaut.
Ce sont ces parties des spécificités du système d'exploitation qui doivent souvent être terminées manuellement. Et parfois - pour couper, si tout à coup le comportement attendu de la plate-forme iOS migrait vers Android, comme ce fut le cas avec le backwipe.
Dans les applications natives, les problèmes tels que l'actualisation de l'écran, la minimisation incorrecte des applications, le fonctionnement de l'application inhabituel pour le système d'exploitation actuel sont rares: les outils et technologies de développement d'une application pour une plate-forme spécifique visent évidemment à couvrir toutes les versions et capacités d'un système spécifique.
Lors du test de l'une des applications Flutter, nous avons été confrontés à une situation intéressante: la possibilité de mettre à jour l'écran n'était pas disponible sur les appareils iOS avec une frange - à commencer par l'iPhoneX et plus. Dans le même temps, les appareils iOS sans frange et Android fonctionnaient correctement.
Nous avons rencontré un autre bug sur la version 6 d'Android: une fois minimisée, l'application était complètement déchargée de la mémoire.
Ces bogues ont été corrigés par nos développeurs à l'intérieur du projet.
iOS est bien conscient de leurs appareils et systèmes, des puces qu'ils publient avec la nouvelle version du système d'exploitation et qui ne fonctionneront plus dans les versions précédentes, sur quoi se concentrer lors de la mise à jour du même Swift. Android comprend qu'ils doivent cibler un grand nombre d'appareils et des tailles d'écran complètement différentes, et ils connaissent également leurs spécificités.
J'aimerais que la multiplateforme contienne toutes les subtilités d'implémentation issues du développement natif. Bien sûr, il y a quelques lacunes lorsque vous travaillez avec Flutter, mais ce n'est pas un problème: vous avez juste besoin de votre propre approche de la multiplateforme.
Avantages: une base de code, une équipe de développement
Une seule base de code réduit le temps de test.
La raison des bogues peut être des spécifications techniques floues, le manque d'états rendus dans la conception, la compatibilité descendante lors de la mise à jour du back-end. Il est plus facile de créer de tels bogues, car vous devez créer deux fois moins de tâches, ce qui fait déjà gagner du temps.
Vous pouvez rechercher des bogues et vérifier les fonctionnalités sur une seule plate-forme: avec un degré de probabilité élevé, ils sont répétés sur les deux plates-formes - après tout, il y a une implémentation.
La logique des nouvelles fonctionnalités sur les deux plates-formes est également la même, puisque le même code est écrit: tester des processus complexes au sein d'une application revient à les tester sur une plate-forme et à les confirmer sur une autre. Nous effectuons un cycle complet d'activités sur une seule plate-forme: nous effectuons des tests exploratoires, des exécutions de fonctionnalités, de la fumée / santé mentale / complet, analysons les commentaires. Après cela, il ne reste plus qu'à confirmer la qualité par des tests exploratoires sur une autre plateforme. Cette approche permet de gagner environ 1,3 fois le temps de test logique.
, , , : , . , .
, (, iOS), , (Android), event .
Si les assemblages pour les deux plates-formes doivent être livrés au client le même jour, ils sortent en même temps et il n'y a qu'un seul ingénieur QA sur le projet, il se peut que le temps de vérification en développement natif ne soit pas suffisant: le cycle de test doit être effectué sur les deux plates-formes séparément. Nous gagnons du temps en testant des applications multiplateformes: les tests de régression des deux plates-formes se déroulent en un seul cycle.
Nous avons essayé d'évaluer grossièrement les tests de deux projets similaires - l'un sur Android natif et iOS, le second sur Flutter - et les avons comparés de manière apicale.
L'analyse et les tests ont été effectués sur un appareil iOS et un appareil de la plate-forme Android. Comme vous pouvez le voir dans la pratique, Flutter donne vraiment un gain de temps, mais pas deux fois. Cela est compréhensible: vous ne pouvez pas supprimer complètement les tests sur l'une des deux plates-formes. Quoi qu'on en dise, ils ont des spécificités différentes et se concentrent sur l'utilisateur.
|
|
IOS natif
|
Android natif
|
Flutter Android + iOS
|
| Récupération de mot de passe
|
2h
|
2h
|
3 h 20 min
|
| Autorisation
|
1h 30m
|
1h 30m
|
2 h 20 min
|
| Notifications push
|
2h
|
2h
|
4h
|
Lors du test d'une fonctionnalité prête à l'emploi qui n'affecte pas complètement les spécificités du système d'exploitation et n'est pas écrite de manière personnalisée pour chaque plate-forme séparément, le temps de vérification d'une application Flutter sur les deux plates-formes est réduit d'environ 1,3 à 1,5 fois. Par exemple, les fonctionnalités d'autorisation et de récupération de mot de passe qui n'ont pas de comportement spécifique sur différentes plates-formes réduisent le temps de test de la version Flutter de 1,3 fois.
En ce qui concerne les fonctionnalités qui nécessitent un comportement personnalisé de chaque plateforme, il ne faut pas s'attendre à une réduction du temps. Le comportement pour iOS et Android devrait être différent, ce qui signifie que les deux plates-formes doivent être testées complètement et séparément l'une de l'autre. Par exemple, il est souvent nécessaire de tester les notifications push en cycle complet sur les deux plates-formes en raison des différences d'autorisations, de travailler avec la connexion aux notifications, les paramètres de poussoir pour l'envoi de notifications sur iOS et Android, ainsi que d'autres subtilités de mise en œuvre - afin que le travail habituel de l'utilisateur avec les notifications soit pris en charge. Les savoirs traditionnels et la conception ont été respectés.
Il est plus facile d'organiser la communication au sein de l'équipe
Quand il y a beaucoup de monde dans le projet, il est difficile d'organiser le processus pour que même les plus petites subtilités ne passent pas. Surtout s'il y a beaucoup d'améliorations à venir, des implémentations de nouvelles fonctionnalités et des changements en général. La plupart des problèmes sont résolus lorsque l'équipe de développement en est une.
Premièrement, il est plus facile de tester une application en implémentant une seule commande que de travailler avec deux implémentations différentes sur deux plates-formes. Le professionnel de l'assurance qualité souhaite bien entendu disposer d'informations complètes sur l'état de l'application, à la fois sur la plateforme iOS et sur la plateforme Android. C'est plus facile lorsque vous travaillez avec Flutter.
Deuxièmement, il y a un point important dans le développement natif: concernant les changements qu'une plate-forme a appris et acceptés, il est nécessaire de notifier l'autre plate-forme, qui est parfois oubliée ou perdue au cours de changements importants et intensifs. Il n'y a pas de tel problème lors du développement d'applications Flutter: il n'y a qu'une seule équipe - c'est-à-dire qu'une tâche de révision s'applique aux deux plates-formes.
Nous adorons tester les applications Flutter
Faire partie d'une communauté sympa
Pour nous, un nouveau framework est un plus: résoudre des problèmes non standard, nous élargissons nos horizons. Nous trouvons de nombreux bogues intéressants et uniques qui développent nos compétences et nos capacités lors du test d'applications.
Dans le même temps, les développeurs de la communauté Flutter-framework donnent rapidement des retours sur les problèmes identifiés, améliorent la librairie et nous permettent de contribuer au projet: nous avançons ensemble, et c'est bien.
Soyez un spécialiste
Lorsque vous travaillez avec des applications multiplateformes, il est important de garder à l'esprit les différences entre les systèmes d'exploitation et de ne pas perdre de vue la spécificité de la plateforme. Rechercher et voir les différences là où elles devraient être minimes en théorie, apprendre quelque chose que vous n'avez jamais rencontré auparavant - un tel travail augmente le professionnalisme.
Lors du développement et du test d'applications natives, il est impossible de créer une application iOS à partir, par exemple, d'Android Studio ou de Visual Studio Code. Lorsque vous travaillez avec Flutter, l'EDI est le même pour Android et iOS. C'est super.
Soyez indépendant
En travaillant avec Flutter, nous sommes confrontés chez Surf à des projets très différents: du e-commerce à la banque. La pratique a montré qu'un ingénieur QA peut tester à lui seul les deux plates-formes. Il est nécessaire de connecter un autre spécialiste uniquement plus près de la version, lorsque le rythme de travail augmente et que le temps d'exécution des tâches est épuisé.
Flutter - un pas en avant
Tester des applications multiplateformes n'est pas difficile. Parfois, c'est encore plus rapide et plus pratique que de travailler avec des natifs. Toutes les difficultés auxquelles on peut faire face ne chevauchent pas la commodité et les avantages.
L'expérience du développement et du test des applications Flutter a montré à Surf que ce framework est un grand pas en avant.