Plateformes de test mobiles dans le cloud

Et maintenant, le moment est venu où nos besoins en matière de tests sont devenus trop nombreux sur le bureau du testeur. L'âme a demandé aux nuages. Pas vraiment. Pas vraiment.



Nos buts et objectifs


(lecteur pressé, vous pouvez passer à la section suivante)


Nous développons une application financière pour le marché étranger, disponible en différents formats: pour les navigateurs de bureau (site Web et extension pour Google Chrome), pour les navigateurs mobiles, ainsi qu'une application hybride pour les téléphones. En raison des spécificités de l'application, nous accordons une attention particulière au test de l'application sur différentes configurations et différents appareils. Pour nous, le fonctionnement stable et sûr de l'application est important à la fois sur les navigateurs de bureau de nos clients et sur tous leurs appareils.


La raison pour laquelle nous avons trouvé une batterie de périphériques basée sur le cloud pour les tests pour nous était un changement dans le format de travail du bureau à complètement distant et distribué (entre les villes et les pays). Autrement dit, si auparavant, pour les tests, nous pouvions assembler différents appareils dans un groupe (littéralement) et tester manuellement le prochain assemblage dans une même table en même temps, maintenant il est devenu impossible de le faire. De plus, avec la croissance des fonctionnalités, afin de réduire le travail manuel, nous automatisons les jeux de régression des tests importants, ce qui signifie qu'après l'assemblage, nous devons être en mesure d'appeler des tests sur la configuration et le périphérique souhaités, et il est préférable de le faire dès que l'assemblage passe à la mise en scène.


Dans ce cas, la solution la plus simple et la plus évidente consiste à utiliser des émulateurs pour Android et des simulateurs pour les appareils iOS dans notre pipeline DevOps. Cependant, qui est relativement facile à implémenter sur l'ordinateur de travail du développeur, il devient une tâche difficile et coûteuse à utiliser dans le cloud. Pour que le même émulateur Android fonctionne rapidement, un serveur x86 avec prise en charge HAXVM est requis, et pour un simulateur iOS, seul un appareil MacOS avec xcode est requis. Mais, malheureusement, même après avoir résolu ce problème, la question demeure avec l'écart entre le comportement du logiciel sur les émulateurs et les vrais appareils. Par exemple, à chaque seconde, nous détectons d'étranges bugs sur les appareils Samsung qui ne peuvent pas être lus sur les émulateurs. Eh bien, et, bien sûr, de rares «délices» exotiques «chinois» avec des bogues uniques et que j'aimerais aussi attraper au stade du développement.


En conséquence, nous avons compris la nécessité d'utiliser une batterie de terminaux mobiles pour le cloud, sur laquelle nous pourrions exécuter rapidement nos tests et, si nécessaire, déboguer manuellement. Et auquel toute notre équipe aurait accès depuis n'importe où dans le monde (nous aimons travailler même en voyage).



Nos tests sont écrits en Python 3.7 (ce sera important plus tard), comme la pile que nous utilisons tox + pytest + Selenium + Appium, eh bien, un petit ensemble de bibliothèques python utiles. Nous allons certainement tester des machines sous Windows et MacOS avec les navigateurs Edge, Firefox, Chrome, Safari, ainsi que les appareils Android et iOS avec des navigateurs et une application. Nous n'avons pas beaucoup de tests pour chaque appareil (moins d'un millier), mais lors d'un test dans un seul thread sur les appareils, un ensemble complet prend quelques heures. Par conséquent, le critère de choix d'un service pour nous sera:


  • Test API (Sélénium / Appium)
  • IOS, appareils Android
  • Prend en charge les tests de navigateur mobile
  • Prise en charge du téléchargement et du test des applications
  • Appareil de référence (GooglePixel (Android 9) et iPhone X (iOS 12+))
  • Débogage manuel
  • Journalisation (plus captures d'écran, enregistrement d'une séquence vidéo)
  • Parc d'appareils et disponibilité
  • Délai moyen de test
  • Prix

Souhaitable, mais pas nécessaire:


  • Prise en charge de Python au niveau du service (quoi que cela signifie)
  • Prise en charge des appareils de bureau \ navigateurs

Résultats des études de marché


Pendant une semaine, j'ai surfé sur Internet et essayé une douzaine de services différents. La plupart d'entre eux offrent du temps libre pour tester les opportunités. Les résultats de mes recherches, plus les conclusions sont subjectives. Votre opinion et vos résultats peuvent différer des miens.


Sur Habré, j'ai trouvé un article pour 2017 consacré au même sujet, mais depuis, de nouveaux services sont apparus, et notre tâche est un peu plus stricte. Ainsi, par exemple, les services «savoureux» comme Samsung Remote Test Lab, Firebase Test Lab, Xamarin Test Cloud, hélas, ne nous conviennent pas.


Hors du jeu


Samsung Remote Test Lab



Lien


Le service offre la possibilité gratuitement d'essayer de travailler avec divers appareils Samsung, y compris les plus récents, y compris les téléviseurs ou les montres intelligentes sur Tizen (la limitation est d'un maximum de 10 heures par jour, par jour, le service donne 10 crédits gratuitement, ce qui équivaut à 2,5 heures par jour , la session minimale est d'une demi-heure (2 crédits)). C'est très bon pour le débogage et pour trouver les causes profondes des erreurs sur certains appareils, le service permet même d'accéder au débogage à distance (pont de débogage à distance, accès à la console et aux journaux système), mais, malheureusement, le service ne fournit pas d'accès API aux appareils. La seule façon d '«automatiser» consiste à enregistrer les actions des utilisateurs, puis à les lire dans votre outil d'automatisation local.


Laboratoire de test Firebase



Lien


Un service de Google vous permet de tester votre application sur des appareils fonctionnant sous Android et iOS gratuitement (pas tout à fait). Mais il y a une mise en garde - le service nécessite l'utilisation soit d'outils d'automatisation natifs (UIAtomator2 et Espresso pour Android et XCTest pour iOS), soit d'utiliser des araignées automatiques (robot) pour Android - Robo Test et Game Loop Test. Autrement dit, utiliser UIAutomator et Selenium hélas, ne fonctionnera pas. Quant à la gratuité - le package gratuit est limité à 10 tests sur des émulateurs et cinq sur des appareils réels par jour. Si vous en avez besoin de plus, vous devrez payer pour chaque heure supplémentaire 1 $ et 5 $ respectivement. En général, pour nos tâches, ce serait un bon choix si nous écrivions des tests à partir de zéro, mais je ne veux pas vraiment traiter plusieurs centaines de tests - c'est tout simplement cher. Et il s'avère que nous devrons diverger considérablement dans les tests entre les versions de bureau et les mobiles, ce qui compliquerait considérablement le support.


Centre d'applications Visual Studio



Lien


Ancien nuage de test Xamarin. Ce service prend enfin en charge Appium et permet de tester sur des milliers d'appareils différents. Mais, comme dans le cas d'autres produits Microsoft, il est fermement cloué sur la pile native, ce qui signifie que pour utiliser ce service, vous aurez besoin à la fois de la présence de VisualStudio et de la nécessité d'écrire le projet et les tests exclusivement en Java. Mais si vous avez soudainement une pile Java (avec MS VS), le prix est de 99 $ par emplacement d'appareil par mois, ce qui est relativement libéral.


Services au choix


Batterie de périphériques AWS



Lien


Peut-être la batterie de serveurs la plus puissante pour les tests sur des appareils virtuels et réels aujourd'hui (plus de 2500 appareils). Pour nous, c'était un service prioritaire, car nos services viennent d'être déployés dans le cloud AWS, en plus, les prix par minute de l'appareil à partir de 17 cents. AWS vous permet de travailler avec des frameworks natifs ainsi qu'avec Appium, Calabash et d'autres frameworks de test automatisés. En plus des tests automatisés, le service offre la possibilité de déboguer manuellement. Eh bien, 1000 minutes «d'essayer» sont très tentantes. Cependant, le diable, comme d'habitude, est dans les détails. En termes de tests, AWS a plusieurs fonctionnalités.


Comme je l'ai déjà mentionné, nous utilisons Python 3.7, mais AWS Device Farm fonctionne toujours avec Python 2.7.6 (voir le manuel ici ). Et hors de la boîte ne sait rien de tox. Pour nous, cela signifie l'absence d'un certain nombre de capacités et la nécessité de traiter une partie des tests pour assurer la compatibilité descendante, ainsi que la création d'un environnement contournant tox. De plus, un mécanisme assez étrange pour télécharger un package de test (archive) implique également le téléchargement de l'application pour le test. Dans notre cas, si nous testons notre service via un navigateur mobile, le téléchargement de l'application est une étape supplémentaire. Cependant, vous pouvez remplacer l'application par un "stub", et créer un venv avec Python 3.7 dans l'environnement Python 2.7, puis créer un environnement contenant tox, ce qui ...



Amazon ne serait pas Amazon si tout reposait sur d'anciennes versions. Comme alternative (et aucun service n'aura une telle opportunité ci-dessous), AWS suggère d'utiliser AWS Device Farm via l'AWS CLI (interface de ligne de commande) (voir le manuel ici ). Autrement dit, nous pouvons connecter l'appareil du cloud en tant que véritable appareil à notre ordinateur en mode de débogage à distance, cependant, après avoir remplacé adb par le correctif (il n'y a pas de binaire pour linux dans la liste des binaires, mais je suis sûr qu'il existe dans la nature). Autrement dit, lors de la configuration de l'AWS CLI, pour les tests, nous devrons exécuter seulement quelques commandes (car nous n'allons pas utiliser l'interface graphique comme une application AWS Device Farm).



Exemple de code
import boto3 #  AWS SDK https://pypi.org/project/boto3/ aws_client = boto3.client('devicefarm') response = aws_client.list_devices() #     device_arn = '' for phone in response["devices"]: if phone['name'] == "Google Pixel XL": #      (  ) device_arn = phone['arn'] #   Amazon Resource Name break project_arn = aws_client.list_projects()['projects'][0]['arn'] #        #      ,    SSH    response = aws_client.create_remote_access_session(projectArn=project_arn, deviceArn=device_arn, remoteDebugEnabled=True, ssh-public-key=SSH_KEY) #     adb devices     uuid Google Pixel XL  AWS Device Farm,   iOS #     ... RUN_TESTS() ... #    ( )    aws_client.stop-remote-access-session(arn=response['remoteAccessSession']['arn']) aws_client.delete_remote_access_session(arn=response['remoteAccessSession']['arn']) 

Si nous voulons tester l'application, elle peut également être téléchargée via le SDK AWS.


Mais je n'ai pas dit une nuance clé ici. Nous tombons à nouveau sur le diable en détail. Le fait est que l'option de débogage distant n'est disponible que si nous utilisons le plan Périphériques privés pour AWS. Premièrement, cette fonctionnalité est disponible uniquement sur demande (vous devez écrire une lettre à Amazon), deuxièmement, l'option est disponible pour la région us-west-2, et troisièmement, en fait, cette option nous renvoie au scénario lorsque nous avons un serveur pour test avec un ensemble (ou au moins un) d'appareils connectés. Les avantages sont évidents - nous pouvons utiliser cet appareil exclusivement, ce qui est évidemment plus sûr et plus rapide, d'autre part, nous perdons le principal avantage - le choix et la variété des appareils.


J'ai aimé le service dans son ensemble, mais pour notre équipe, hélas, il contient trop de «mais».


Bitbar



Lien


Cette ferme mobile basée sur le cloud est la première à tomber sur les moteurs de recherche. Et pas en vain. Pour l'avenir, je dirai que ce service propose le meilleur choix d'appareils (uniquement des appareils réels) et les meilleures performances en termes d'un test par rapport aux autres. Bitbar propose des services de test manuel et automatisé à distance (à l'aide d'Appium et d'autres frameworks) et, si vous le souhaitez, vous permet également d'utiliser quelque chose de similaire au robot du Firebase Test Lab (Robot Test) - AI TestBot. Le principal avantage de BitBar est un nombre illimité de threads de test (c'est-à-dire que vous pouvez immédiatement tester votre application sur des centaines d'appareils) en sélectionnant à l'avance le pool d'appareils requis. Si le périphérique est occupé, un autre sera sélectionné de la même manière ou la session sera mise en file d'attente. À la fin du test, un journal est généré, un enregistrement de test, les résultats sont enregistrés et la notification est envoyée par courrier. Bien qu'il existe des possibilités de configurer l'interaction avec différents outils CI / CD. Le service offre également la possibilité de tester les navigateurs de bureau dans différentes résolutions et, si vous le souhaitez, de créer, comme dans AWS, vos appareils privés. Certes, vous devez payer pour toutes ces puces - chaque minute de test coûtera 0,29 $.



Le processus d'installation est simple, comme l'interaction de deux doigts avec l'asphalte:


Exemple de code
 from appium import webdriver """ ... """ com_executor = 'https://appium.bitbar.com/wd/hub' desired_capabilities = { 'deviceName': 'Motorola Google Nexus 6', 'deviceId': 'FA7AN1A00253', 'newCommandTimeout': 12000, 'browserName': 'Chrome', #     Chrome,    app 'bitbar_apiKey': 'BITBAR_API_KEY', 'bitbar_project': 'Software Testing', 'bitbar_testrun': 'Test run #N', 'bitbar_device': 'Motorola Google Nexus 6', 'bitbar_app': '23425235' } driver = webdriver.Remote(com_executor, desired_capabilities) """ ... """ 

Kobiton



Lien


Un autre service qui fournit des services de test sur des appareils réels. Le choix des appareils est plus modeste que Bitbar (350+), la disponibilité des appareils est également moindre. En général, il est très similaire dans sa fonctionnalité de base à BitBar, il permet des tests manuels et automatiques (en utilisant Appium - ici sans choisir de frameworks). Il n'y a aucun moyen de tester sur les navigateurs de bureau. Le service vous permet également d'organiser les tests avec un nombre illimité de sessions et d'appareils, mais vous ne pouvez pas créer de pool d'appareils ici. Le prix du service est très libéral - à partir de 0,10 $ par minute supplémentaire de test, mais pendant la période d'essai, j'ai attiré l'attention sur une certaine instabilité du service - Internet tombait souvent sur les appareils, une fois l'appareil suspendu. De plus, si l'appareil est occupé ou réservé, tous vos tests en cours échoueront. Autrement dit, contrairement à Bitbar, il n'y a pas de files d'attente de sessions. Certes, il peut être organisé à faible coût. Kobiton possède sa propre petite API.



La configuration est également très simple, contrairement à la bitbar, presque l'Appium d'origine.


Exemple de code
 import base64 from time import sleep from appium import webdriver import requests """ ... """ #  base64EncodedBasicAuth = base64.b64encode(bytes(f'{USERNAME}:{API_KEY}', 'utf-8')) headers = { 'Authorization': f'Basic {base64EncodedBasicAuth}' } reply = requests.get(f'https://api.kobiton.com/v1/apps', params={ }, headers = headers) #     deviceId headers = { 'Authorization': base64EncodedBasicAuth, 'Accept': 'application/json' } reply = requests.get(f'https://api.kobiton.com/v1/devices/{deviceId}/status', params={ }, headers = headers) #   ,      while (reply['isOnline'] == False or reply['isBooked'] == True): sleep(60) #   com_executor = f'https://{USERNAME}:{API_KEY}@api.kobiton.com/wd/hub' desired_capabilities = { 'browserName': 'Chrome', # The generated session will be visible to you only. 'sessionName': 'Automation test session', 'sessionDescription': '', 'deviceOrientation': 'portrait', 'captureScreenshots': True, 'deviceGroup': 'KOBITON', # For deviceName, platformVersion Kobiton supports wildcard # character *, with 3 formats: *text, text* and *text* # If there is no *, Kobiton will match the exact text provided 'deviceName': 'Pixel 2', 'platformName': 'Android', 'platformVersion': '9' } driver = webdriver.Remote(com_executor, desired_capabilities) """ ... """ #   RUN_TESTS() """ ... """ #       ,     (   ) headers = { 'Authorization': {base64EncodedBasicAuth} } requests.delete(f'https://api.kobiton.com/v1/sessions/{sessionId}/terminate', params={ }) """ ... """ 

Browserstack



Lien


Bon vieux BrowserStack. Beaucoup de choses ont été écrites sur lui et beaucoup de ceux qui l'utilisent. Oui, il permet de tester non seulement sur différents navigateurs, mais également sur différents appareils. Tant en mode manuel qu'en utilisant Selenium / Appium. Selon vos besoins - sur les navigateurs mobiles ou en utilisant votre application. En termes de capacités, tout est identique aux deux services en haut, mais contrairement à eux, il y a déjà des restrictions sur le nombre de sessions simultanées. Certes, au contraire, payez 199 $ par mois et testez pour une durée illimitée. Il existe des plugins pour Jenkins, Travis CI, TeamCity, sa riche API, d'excellents journaux et une large sélection d'appareils et de navigateurs de bureau sur différentes configurations. Certes, en fonction de ce que vous testez, les paramètres varient - pour tester les navigateurs (même mobiles), un concentrateur Selenium est utilisé, et pour les applications - un concentrateur Appium. De plus, pour tester l'application, vous devrez payer séparément. Autrement dit, pour tester à la fois les navigateurs et les applications mobiles, vous devez payer 199 $ et 159 $ de plus (le prix d'un appareil pour les tests en même temps).



Exemple de code pour l'application
 from appium import webdriver """ ... """ com_executor = 'https://USERNAME:API_KEY@hub-cloud.browserstack.com/wd/hub' desired_capabilities = {'device': 'Google Pixel', 'deviceName': 'Google Pixel', 'app': app_name, 'realMobile': 'true', 'os_version': '8.0', 'name': 'Bstack-[Python] Sample Test' } driver = webdriver.Remote(com_executor, desired_capabilities) """ ... """ 

Exemple de code pour un navigateur mobile
 from selenium import webdriver """ ... """ com_executor = 'http://USERNAME:API_KEY@hub.browserstack.com:80/wd/hub' desired_capabilities = {'device': 'Google Pixel', 'deviceName': 'Google Pixel', 'browserName': 'Chrome', 'realMobile': 'true', 'os_version': '8.0', 'name': 'Bstack-[Python] Sample Test' } driver = webdriver.Remote(com_executor, desired_capabilities) """ ... """ 

Expérimental



Lien


Un autre service qui offre la possibilité de tester à la fois manuellement et automatiquement les appareils mobiles et les navigateurs de bureau en utilisant Appium, Selenium et d'autres cadres. Comme dans le cas de BrowserStack, le nombre de sessions simultanées est limité, mais les prix sont légèrement différents - pour tester les applications mobiles, le service demande 199 $ par mois, et pour les tests multi-navigateurs seulement 39 $ (pour une session simultanée). De plus, comme Bitbar avec AWS, vous pouvez créer votre propre laboratoire privé avec des appareils qui, cependant, peuvent être mélangés avec un cloud public de milliers d'appareils, d'émulateurs et de navigateurs de différentes versions et plates-formes (MacOS, Windows), si vous le souhaitez. Parmi les fonctionnalités intéressantes - la disponibilité des extensions pour IntelliJ et Eclipse, son propre outil Appium Studio, qui vous permet d'utiliser les fonctionnalités avancées d'appareils tels que l'interaction avec FaceID, la commande vocale, la numérisation de codes-barres, la définition de la qualité de la communication, la géolocalisation et plus encore. Parmi les inconvénients, je peux nommer un étrange ensemble d'appareils pour la période d'essai, une tarification draconienne pour la période d'essai, ainsi que l'obligation d'utiliser le courrier d'entreprise (gmail ne fonctionnera pas).



Exemple de code
 from appium import webdriver """ ... """ com_executor = 'https://Uhttps://cloud.seetest.io/wd/hub' desired_capabilities = {"deviceName": "iPhone X", "accessKey": API_KEY, "platformName": "ios", "deviceQuery": "'@os='ios' and @version='12.1.3' and @category='PHONE'", } driver = webdriver.Remote(com_executor, desired_capabilities) """ ... """ 

Saucelabs



Lien


L'un des plus anciens services de test cloud. Près de 400 appareils réels différents, une large sélection de simulateurs et d'émulateurs, y compris des émulateurs atypiques d'appareils Samsung, il existe des navigateurs de bureau pour différents systèmes d'exploitation, y compris Linux. Automatisation sur Appium / Selenium et frameworks natifs. Le principal avantage du service est la présence d'une vaste collection de configurations, y compris d'anciens systèmes d'exploitation, navigateurs, appareils. SauceLabs a également une limite sur le nombre de sessions simultanées, mais ici l'option la moins chère comprend non pas une, mais deux sessions simultanées. Ce qui est inhabituel: les plans tarifaires sur les appareils réels et sur les émulateurs sont différents. Ainsi, les options les moins chères, qui incluent deux sessions avec 2000 minutes de test par mois sur des émulateurs, coûteront 149 $, et sur des appareils réels déjà 349 $. Il y a une intégration avec CI / CD, Slack. Malheureusement, je n'ai pas pu essayer SauceLabs en direct, car hélas, l'enregistrement échoue, peut-être à cause de la région, mais je ne peux pas en être sûr.


Perfecto



Lien


Le dernier fournisseur de tests cloud est le plus visuellement similaire à Experitest, mais sans fonctionnalité avancée. Il existe un langage de script simple. C'est très étrange, mais dans le service pour les tarifs non-entreprise (entreprise), il n'est pas proposé de tester sur les navigateurs de bureau, il est également impossible de surveiller l'exécution des tests en temps réel (uniquement s'il ne s'agit pas de tests manuels). Une centaine d'appareils différents sont disponibles pour les tests. Il y a intégration avec Jenkins, et aussi, fait intéressant, avec des outils de gestion de test comme HP ALM, IBM Rational, TFS. Des plans tarifaires très étranges sont également disponibles, comme 5 heures de test par mois (en termes de minutes autant que 0,33 $ (c'est le service le plus cher)), bien qu'avec la possibilité d'acheter un forfait avec des heures supplémentaires, mais encore une fois, il est étrange qu'il n'y ait pas par minute ou au moins une facturation horaire après coup. En ce qui concerne la facilité d'utilisation, pendant la période d'essai, seuls des tests manuels sont disponibles, ainsi qu'un laboratoire commun, de sorte que tous les lancements d'utilisateurs différents tombent dans un seul tas. Il est donc impossible de juger exactement de la commodité et de la rapidité du service. On peut voir que le service est principalement axé sur les grandes entreprises clientes, alors que, au moins selon les informations disponibles, les capacités de ce fournisseur sont les plus modestes de tous que j'ai testées.




Résumé des résultats


Selon tous les critères de sélection, les services sont très similaires, la différence entre les services dans leurs performances et leur prix (s'il n'y a pas de fonctionnalités, par exemple, comme dans le cas d'AWS). Par conséquent, nous résumerons les données de recherche dans un tableau, examiner la vitesse des services (en tenant compte de la connexion via US VPN), ainsi que le prix, pour plus de commodité, en comparant le temps de test mensuel moyen sur les appareils (5 versions par mois, 2 heures de test sur les appareils Android et iOS = 20 heures). Comme valeurs de référence, j'utilise les données de mon ordinateur local avec un émulateur, me connectant à nouveau pour la pureté de l'expérience via un VPN aux USA).



Conclusions


C'était très intéressant pour moi de rechercher et de choisir le bon service pour notre équipe. En général, il existe des solutions pour tous les goûts et pour toutes les tâches, et les services se sont avérés très similaires en termes de caractéristiques et de mise en œuvre. Par conséquent, selon vos tâches, je recommanderais le choix suivant:


Option A : si la vitesse de vérification est importante pour vous et que vous devez vérifier immédiatement des dizaines d'appareils différents - votre choix est Bitbar .


Option B : si vous avez la priorité sur les résultats des appareils de référence et que les tests de configuration sont secondaires (mais nécessaires) - votre choix est BrowserStack . C'est juste notre cas, car statistiquement - 90% de toutes les erreurs sont des erreurs de plates-formes et d'appareils de référence (le plus souvent, les bogues sont communs à toutes les plates-formes de référence à la fois). Les 8% restants sont des erreurs MS IE, avec le refus de la prise en charge IE - 2% d'erreurs MS Edge et 0,5% d'erreurs sur des configurations spécifiques.


Option B : Si vous souhaitez vérifier des conditions spéciales, telles que des communications de mauvaise qualité, la géolocalisation ou Touch / FaceID, votre choix est Experitest .


Mais à long terme, si votre entreprise occupe un grand bureau, votre travail est à temps plein, alors, en règle générale, organiser vos propres, même des mini-laboratoires avec un serveur pour émulateurs avec 2-3 appareils connectés, coûtera moins et sera plus pratique que d'utiliser des services spécialisés services.

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


All Articles