Automatisation des tests d'applications mobiles: comparaison d'outils

L'automatisation des tests permet de résoudre plusieurs problèmes à la fois, y compris en ce qui concerne les applications mobiles. Au lieu d'effectuer manuellement des procédures de routine à forte intensité de main-d'œuvre, les spécialistes peuvent en déléguer une partie importante aux cadres. L'automatisation simplifie les tests et permet d'accélérer les tests de régression, et permet également d'utiliser des types de tests auparavant inaccessibles.

Nous comparerons plusieurs outils qui se sont établis sur le marché et continuent de se développer. Ces connaissances vous aideront à choisir la solution à utiliser pour tester une application mobile particulière.



Il est peu probable que cet article ouvre de nouveaux horizons pour les professionnels, mais il peut être utile pour les débutants qui ont décidé d'apprendre les bases des tests mobiles et, dans une certaine mesure, les spécialistes de niveau intermédiaire.

Classification des outils


La première chose que vous devez construire est la plate-forme sur laquelle l'application s'exécute. Sur cette base, nous classons la liste des outils comme suit:

Android

  • Espresso
  • UI Automator

iOS

  • XCUITest
  • Earlgrey

Universel

  • Detox
  • Appium
  • Ranorex
  • TestComplete Mobile

Automatisation des tests d'applications Android


UI Automator


Outil de test puissant avec intégration externe avancée. Cela signifie que ce cadre vous permet non seulement de tester l'application elle-même, mais est également capable de «communiquer» avec le système d'exploitation et d'autres applications - par exemple, activer et désactiver le Wi-Fi, le GPS, ouvrir le menu des paramètres pendant le test et effectuer d'autres interactions externes.

Le but d'UI Automator est de tester la boîte noire. Cela signifie que l'analyse est effectuée à partir de la position d'un utilisateur externe sans accès au code.

Les fonctionnalités clés incluent:

  • UI Automator Viewer pour suivre et analyser les composants affichés à l'écran pendant le test. Il fournit des informations sur les éléments et leurs propriétés, ce qui facilite la création de tests plus pertinents.
  • API pour obtenir des informations sur l'état de l'appareil et exécuter des processus sur celui-ci.
  • API UI Automator pour les tests multiplateformes.

Lien vers la documentation .

Espresso


Un outil plus léger que UI Automator, non adapté pour interagir avec des applications externes, mais pratique pour tester une boîte blanche avec accès au code source d'une application particulière ou tester une boîte grise, qui a accès à certains processus et structures internes.

Cependant, Espresso se démarque avec sa puissante API https://github.com/hamcrest . L'interface ajoute des méthodes pratiques pour les contrôles dans les autotests, par exemple:
assert_that (1, less_or_equal (2)). Pour tester la vue Web, des méthodes spéciales sont utilisées.

UI Automator et Espresso sont complémentaires et peuvent être utilisés en combinaison dans le même projet.

Lien vers la documentation .

Automatisation des tests pour les applications iOS


XCUITest


Un outil pour tester la boîte noire sans accéder au code de l'application. Cela ne fonctionne qu'avec des produits natifs - malheureusement, les tests inter-applications ne fonctionneront pas.

D'un autre côté, la nature native du framework est un avantage du point de vue que lors de l'utilisation de XCUITest, le degré de compréhension mutuelle des développeurs et des testeurs est à un niveau beaucoup plus élevé que dans les cas où l'un et l'autre utilisent des langages différents.

Un ajout utile est l'enregistreur de test, qui permet d'écrire des tests en enregistrant des actions dans l'application même pour ceux qui ne travaillent pas avec le code.

L'outil vous permet d'éviter les erreurs courantes et les manipulations inutiles, inaccessibles à l'utilisateur, avec le code. Cependant, XCUITest présente également certains inconvénients.

XCUITest, contrairement à Espresso, fonctionne dans un fil séparé, pendant les tests, vous devez attendre l'apparition de certains éléments et paramètres. L'état actuel de l'application n'est pas lu et les retards dans la mise à jour des données peuvent entraîner l'impossibilité de détecter les éléments demandés.

Documentation XCTest et XCUITest .

Earlgrey


EarlGrey met l'accent sur la reproduction de l'expérience utilisateur. Tant que les éléments à l'écran ne sont pas présentés visuellement, la simulation du travail avec l'application ne démarre pas.

Dans le même temps, un certain nombre de commodités et d'avantages sont notés. Tout d'abord, les experts apprécient la façon dont le framework synchronise les requêtes, les interfaces utilisateur et les threads. Aucune attente et attente ne sont nécessaires.

Deuxièmement, comme déjà mentionné, une attention particulière est accordée au suivi de la visibilité des éléments. L'outil dispose d'une couche supplémentaire pour vérifier le chargement de l'interface et reproduit les gestes de l'utilisateur - glisser, cliquer - directement au niveau de l'événement d'application.

Liens vers le référentiel: github.com/google/EarlGrey et google.imtqy.com/EarlGrey .

Outils universels


Les outils universels (ou «combine») vous permettent de ne pas limiter votre choix uniquement à Android ou iOS, mais de travailler avec les deux plateformes.

Ces outils sont applicables pour tester des applications des types suivants:

  • Applications natives (applications natives) - écrites directement sous le SDK Android, iOS et Windows.
  • Applications Web mobiles - Disponibles via un navigateur mobile, tel que Safari ou Chrome.
  • Applications hybrides (applications hybrides) - l'utilisateur travaille avec le shell de l'application Web, c'est-à-dire qu'il interagit avec le contenu Web via l'interface de l'application native.

Detox


À notre avis, Detox est pratique pour les applications écrites en React Native. Les tests sont écrits en JavaScript, tandis que les applications iOS et Android sont générées à partir du même code JavaScript et sont aussi similaires que possible. Cela vous permet d'utiliser les mêmes tests pour les deux plates-formes.

Une des principales caractéristiques de Detox est le test en boîte grise. Dans ce cas, le framework a un certain accès aux mécanismes internes, ce qui vous permet de corréler le comportement externe de l'application avec ce qui se passe à un niveau plus profond.

Detox peut accéder à la mémoire et suivre les processus en cours. Le principe de la boîte grise aide à lutter contre l'instabilité, ce qui se reflète dans le fait que lors des tests de bout en bout:

  • Le test peut se bloquer de manière aléatoire même sans modification du code;
  • Les résultats ne sont pas déterministes - en raison du grand nombre de fonctionnalités et de processus hétérogènes au sein de l'application, les résultats de chaque lancement peuvent différer de manière imprévisible les uns des autres.
  • Les testeurs sont obligés de se synchroniser manuellement, ce qui entraîne une diminution de la fiabilité et de la qualité des résultats.

Curieusement, la «boîte grise» présente non seulement une meilleure stabilité, mais également une vitesse plus élevée par rapport à la «boîte noire». En évitant toutes sortes de pauses, attendez jusqu'à ce que la boîte grise soit 5 à 10 fois plus rapide.

Detox n'a pas besoin de WebDriver, travaillant avec le pilote natif via JSON. Il utilise des méthodes natives directement sur l'appareil. Dans ce cadre, EarlGrey pour iOS et Espresso pour Android sont utilisés.

Le cadre fonctionne avec des émulateurs et des périphériques physiques.

Lien vers la documentation .

Appium


L'avantage d'Appium est qu'il est possible d'écrire des tests pour chaque plate-forme à l'aide d'une seule API, sans avoir recours à la conversion de l'application sous une forme spéciale compatible avec le framework.

Lors des tests, des cadres de fournisseurs sont utilisés, c'est-à-dire que vous travaillez avec l'application d'origine. Pour Android 4.2+, respectivement, UiAutomator / UiAutomator2 est utilisé, et pour iOS 9.3+ - XCUITest. WebDriver (alias Selenium WebDriver) est utilisé comme framework de framework.

Principes d'Appium:

  • Pas besoin de recompiler l'application ou de la modifier pour automatiser les tests.
  • Il n'est pas nécessaire d'être attaché à un seul langage ou cadre.
  • Il n'est pas nécessaire de réinventer la roue en ce qui concerne les API d'automatisation.

L'utilisation d'Appium est justifiée lorsque vous avez besoin d'un outil pour automatiser les tests sur plusieurs plateformes à la fois. Elle est utile si vous avez des spécialistes ayant une expérience dans le test d'applications Web, mais aucune expérience dans l'automatisation des tests d'applications mobiles.

En général, il s'agit d'un outil flexible qui peut être modifié pour s'adapter aux besoins du projet sans avoir besoin de s'adapter à un ensemble limité de langages de développement.

Lien vers la documentation .

Ranorex


Outil complet payant pour tester les applications de bureau, mobiles et Web. Il permet de tester à la fois en utilisant la programmation et sans utiliser de scripts du tout. Offre la possibilité de tester non seulement via des émulateurs, mais également sur des appareils en direct.

L'outil vous permet de créer et de configurer des tests, ainsi que de les gérer de manière centralisée. Vous pouvez créer un test dans le centre de contrôle et l'exécuter dans divers environnements externes et sur n'importe quel appareil.

S'intègre facilement à votre environnement CI existant: avec des systèmes de gestion d'applications tels que Jira et TFS, ainsi que des systèmes de contrôle de version tels que Git et SVN.

Ranorex propose des tests basés sur les données avec chargement de données à partir de SQL, CSV et Excel.

L'outil convient à absolument n'importe quel appareil, prend en charge les tests parallèles sur chacun d'eux.

Il combine les trois approches de test: boîte noire, boîte blanche et boîte grise.

Lien vers la documentation .

Testcomplete


Environnement payant pour tester l'automatisation des applications mobiles, Web et de bureau. Il prend en charge Android et iOS, et dans le contexte des types d'applications: natives, applications Web et hybrides.

Axé principalement sur les tests fonctionnels et unitaires, l'outil offre également la possibilité d'effectuer de nombreux autres types de tests:

  • Régression;
  • Tests basés sur les données;
  • Tests distribués et plus encore.

Il y a un enregistreur dans TestComplete - des tests y sont créés en enregistrant des actions et en définissant des commandes dans l'éditeur. Ils peuvent ensuite être lancés directement dans l'outil lui-même ou exportés vers des applications tierces.

Cet outil reconnaît les objets et les contrôles en proposant des commandes spéciales pour émuler l'interaction de l'utilisateur avec eux. S'intègre à Jenkins, Git et Jira, vous permettant d'exécuter des tests continus et continus.

Lien vers la documentation .

Pour résumer


Lorsque vous prévoyez de tester telle ou telle application mobile, faites attention aux outils répertoriés ci-dessus. Chacun d'eux a ses propres caractéristiques, et parfois des limites.

Regardons un exemple. Si vous êtes confronté à la tâche de tester une petite application en peu de temps, vous devez tout d'abord tenir compte de facteurs tels que le type d'application à tester et l'expérience de vos spécialistes. Si un développeur écrit des tests, il est préférable de choisir une langue native et un outil pour sa plateforme (voir le tableau ci-dessous). Si les tests sont effectués par des spécialistes SDET qui connaissent bien d'autres langages (Java, JavaScript, Python, etc.) et qui ont travaillé avec Selenium, il est pratique d'utiliser Appium. S'il n'y a pas de SDET expérimenté dans l'équipe et que des experts en assurance qualité rédigeront des tests, il est préférable de choisir des frameworks payants, car ils ont des utilitaires pour enregistrer les tests et un support technique plus stable que les frameworks open source.

De notre pratique:
Nous avons travaillé avec une boutique en ligne, qui avait deux applications mobiles - sur iOS et Android. Pour tester les principaux scénarios utilisateurs avec des tests, nous avons choisi Appium pour plusieurs raisons:

  • multi-plateforme, la possibilité de réutiliser partiellement le code
  • adapté aux tests de bout en bout, peut fonctionner avec le web
  • la présence dans l'équipe de spécialistes qui connaissent bien le sélénium, qui sert d'enveloppe à ce cadre.

En conséquence, Appium a pleinement répondu aux attentes, nous avons mené avec succès des tests pour iOS et Android. Il convient de garder à l'esprit que de tels tests de bout en bout avec Appium ne sont pas effectués sur chaque demande de fusion, car cela prend beaucoup de temps.

En conclusion, nous portons à votre attention un tableau qui vous aidera à choisir l'outil pour votre projet. Il convient de noter que dans certains cas, la division dans le tableau est conditionnelle. Quelque part par souci de simplicité, une généralisation est faite et seuls les paramètres les plus élémentaires sont donnés. Les outils de test évoluent constamment, donc lors du choix d'un framework, il est important de vérifier la documentation actuelle.



Merci de votre attention!

Source: https://habr.com/ru/post/fr459292/


All Articles