Gotta Test ’Em All: Comment tester les applications mobiles OutSystems

Il y a quelque temps, j'ai écrit un article dans lequel je discutais du rôle crucial des tests d'applications mobiles dans l'amélioration de la qualité des applications et de son incidence sur l'adoption et la satisfaction des utilisateurs. J'ai passé en revue la complexité des tests d'applications mobiles en raison de la vaste gamme de périphériques mobiles, de versions de systèmes d'exploitation et de conditions de réseau. Aujourd'hui, je souhaite vous guider dans le test d'applications mobiles avec OutSystems et AWS Device Farm.

Le nombre de variables lors du test des applications mobiles OutSystems, comme pour toute autre technologie mobile, est énorme, même à la surface. Cela dit, vous devriez toujours envisager de regarder plus en profondeur. Après tout, une application défectueuse demande simplement à être désinstallée sur-le-champ.

Vous ne pouvez tester qu’un nombre limité de choses sans rechercher ce qui est redoutable et qui peut détruire un scénario parfaitement construit: un véritable appareil. Tester sur des appareils réels est une boîte logistique de Pandora et hante les rêves de tout développeur mobile. Mon équipe et moi avons beaucoup dormi. Nous devions trouver une solution, un moyen de tester sans être ensevelis sous une montagne de téléphones portables.

Il existe de nombreuses solutions telles que Visual Studio App Center, Perfecto ou Saucelabs. Mais Amazon Device Farm s’est avéré l’antidote de nos cauchemars. Une infrastructure de test AWS qui permet aux développeurs de télécharger et d’exécuter des tests sur de vrais périphériques Android et iOS dans le cloud AWS, Device Farm vous permet de réaliser des tests automatisés et d’organiser des sessions d’accès à distance sur des périphériques spécifiques avec leurs propres configurations. l'appareil, nous pouvons configurer son état.

AWS fournit également un SDK pouvant être utilisé pour interagir avec tous les services AWS. De cette façon, nous pouvons connecter la batterie de périphériques (ou tout autre service) à nos tableaux de bord internes.

AWS a également lancé l'accès direct au périphérique pour les périphériques privés. Avec cette nouvelle fonctionnalité, les développeurs peuvent utiliser des périphériques individuels dans leur ensemble de test privé comme s'ils étaient directement connectés à leur ordinateur local via USB.

Device Farm prend également en charge une large gamme de structures d'automatisation des tests, telles qu'Appium, Calabash, XCTest et de nombreux autres, où vous pouvez écrire vos propres tests.

Alors oui, c’est un outil assez impressionnant, surtout quand on le voit fonctionner.

Mettre la main à la pâte: Amazon Device Farm et OutSystems

Je vais donc maintenant vous expliquer comment utiliser AWS Device Farm pour tester les applications OutSystems. Pour le voir en action, nous devons d'abord créer les tests! Nous allons utiliser une simple application OutSystems et tester la page de connexion sur un appareil Android. Pour plus de détails techniques sur la configuration de vos tests, consultez ces échantillons de test sur GitHub; vous pouvez également suivre d'autres didacticiels de test.

1. Configuration de la machine

Installez la structure de test d'automatisation qui vous convient le mieux. Pour cet article, nous allons nous en tenir à Appium. Comme Appium, certains frameworks prennent en charge plusieurs langages de programmation. Donc, assurez-vous d'installer tout. Nous avons choisi Python comme langage de programmation.

2. Configuration de test

Commencez par créer votre projet de test. Avant d’envoyer tous vos tests à la batterie de périphériques, il est fortement recommandé de commencer par exécuter les tests exacts dans votre environnement de test local. Il est plus facile de trouver la cause première d’un problème localement. C’est aussi moins cher. Donc, dans votre fichier de test principal, ajoutez les fonctionnalités suivantes à votre test.

desire_caps ['platformName'] = 'Android'
desire_caps ['deviceName'] = 'aPhone'
désirée_caps ['appPackage'] = '
désirés_caps ['appActivity'] = ".MainActivity"

3. Planification des tests et mise en phase

En règle générale, vous ne créez pas de test pour tout. Idéalement, vous isolerez chaque partie de l'application que vous souhaitez tester. Donc, avant de commencer à coder votre test, vous devez élaborer un plan. Asseyez-vous, détendez-vous et testez votre application en recherchant les principales fonctions que vous souhaitez tester.

4. Création de test

Maintenant que vous avez un plan, vous êtes prêt à commencer à configurer vos tests. Commençons par créer un fichier de test dans le dossier de tests et coder un scénario de test. Lorsque vous codez votre test, préfixez votre méthode de test avec le mot «test»; cela aide le framework de test à identifier la méthode que notre test contient.

Nous mettons en place des tests d’interaction, donc tout est séquentiel. Tout d’abord, nous allons commencer le test. Ensuite, nous attendrons qu’un événement ou un élément s’affiche à l’écran. Lorsque celui que nous attendions est affiché, nous le cliquons, puis nous attendons à nouveau que le suivant apparaisse à l'écran. Vous avez l’idée: commencez le test, attendez, cliquez, attendez. Parfois, il peut être nécessaire d’utiliser une condition de veille pour s’assurer qu’un événement spécifique se produit ou qu’un élément spécifique apparaît à l’écran; sinon, nous pourrions ne pas le remarquer.

importation os
importer unittest
depuis le webdriver importation appium
from selenium.webdriver.common.by importer par
depuis selenium.webdriver.support.ui importer WebDriverWait
depuis selenium.webdriver.support, importation attendu_conditions en tant que CE
Classe TestClass (unittest.TestCase):
  
  def setUp (auto):
   self.driver = webdriver.Remote ('http://127.0.0.1:4723/wd/hub', {})
  def test_case (auto):
   ...
  def tearDown (auto):
   self.driver.quit ()
       
  si __name__ == '__main__':
   unittest.main ()

Comment puis-je savoir qu'il y a quelque chose à l'écran? Comment puis-je cliquer dessus? Ok, c'est la partie la plus délicate. Vous vous souvenez de l'article que j'ai écrit sur la création d'applications natives avec OutSystems MABS il y a quelque temps? Si oui, vous savez déjà que les applications OutSystems sont hybrides. Cela signifie que certaines modifications apportées lors de la création de nos applications OutSystems sont mappées en HTML. Ainsi, si vous définissez toujours un attribut de données avec une étiquette, cela vous aidera à identifier les éléments de votre application dans le scénario de test, et il sera plus facile de trouver l’élément avec XPATH.

Comme dans les exemples suivants, dans le premier scénario, nous essayons de trouver une image. Nous avons ajouté un attribut avec une valeur représentant l’image (ici, c’est «SuccessImg») et nous l’avons recherché avec XPATH (// img [@ data-test-id = «SuccessImg»]). Lorsque vous traitez avec une liste, nous devons faire très attention. Pour trouver un élément spécifique dans une liste, par exemple le troisième, nous devons nous assurer que nous avons l'index de la valeur. Ici, nous devons rechercher l’attribut «data-test-id» avec la valeur «MyAttrId-2».

Je sais je sais; Dans certains cas de figure, nous ne pouvons pas tester une fonction spécifique de notre application mobile OutSystems dans un navigateur Web Chrome. La plupart de ces cas se produisent parce qu'il existe une dépendance directe à un plug-in natif, qui doit être installé dans l'application. Pour ce scénario spécifique, nous devons connecter notre appareil mobile à notre ordinateur, ouvrir Chrome et saisir chrome: // inspect / # devices dans l'URL. Cela ouvrira une page qui montre tous les périphériques connectés à votre ordinateur.

Maintenant, inspectez votre appareil et commencez à creuser votre code HTML. Recherchez les boutons, les ancres ou les liens dont vous aurez besoin pour naviguer dans votre application. Un bon moyen d’identifier vos boutons d’application consiste à utiliser le champ Id HTML, mais si, pour une raison quelconque, ce bouton spécifique n’a pas d’identifiant, vous pouvez utiliser XPATH à la place.

N'oubliez pas: les périphériques iOS ne peuvent être inspectés qu'à l'aide de Safari sur Mac et en activant l'inspecteur Web sur le périphérique. Android peut être inspecté par PC et Mac à l'aide de Chrome et de l'activation des outils de développement sur l'appareil.

5. Test de groupement

Nous avons créé notre test et nous sommes maintenant prêt à le soumettre à Amazon Device Farm. Comment peut-on le faire? C’est simple: en exécutant une commande, nous pouvons créer un fichier zip contenant notre ensemble de tests. Ce bundle de test est important car il contient le test et les bibliothèques qui seront exécutées par AWS Device Farm. Pour soumettre les tests:

1. Dans la console AWS, créez le projet dans lequel vous allez effectuer vos tests et une nouvelle exécution. Une exécution représente une application spécifique avec un ensemble spécifique de tests sur un ensemble spécifique de périphériques. Le travail de base est terminé.

2. Ensuite, vous devez télécharger votre package d’application et vos tests. Si vous n'en avez pas, AWS vous couvrira avec deux tests intégrés. Dans cet exemple, nous utiliserons le nôtre.

3. Le divertissement commence maintenant: sélectionnez les périphériques que vous souhaitez tester et spécifiez l'état du périphérique (WiFi, NFC, GPS, Bluetooth). AWS Device Farm compte actuellement 178 périphériques Android et 162 iOS. Pour Android, il existe 139 appareils distincts (Motorola, Samsung, Wiko, etc.) fonctionnant sous 23 versions Android différentes. Pour iOS, il existe 26 appareils distincts (iPad 2, iPhone 8, iPod Touch 6e génération, etc.) fonctionnant sous 26 versions iOS différentes.

4. Allez le temps! Examinez, exécutez et affichez les résultats! Chaque exécution génère un rapport avec les journaux de périphérique, les journaux de test, les captures d'écran, les vidéos, etc.

Emballer

Device Farm est tellement utile. Nous pouvons désormais fournir en permanence de nouvelles fonctionnalités, améliorations et corrections de bugs avec un niveau de confiance élevé. Nos développeurs développent maintenant de nouvelles fonctionnalités et les testent immédiatement.

Cet outil nous a également aidé avec nos cas de support. Comme vous le savez peut-être, il est impossible d’avoir tous les différents périphériques et différentes versions de système d’exploitation. Avec cet outil, nous n’avons pas à perdre une nuit de sommeil à cause de cela; chaque année, AWS Device Farm ajoute de nouveaux périphériques à son service. Ainsi, chaque fois que nous recevons une demande d'assistance pour quelque chose qui ne fonctionne pas comme prévu sur un appareil Lava Iris, Ulefone ou Mlais, nous pouvons demander un accès à distance à Device Farm, et accéder à notre application et la tester en temps réel. .

Je vous mets au défi d'essayer, et maintenant c'est à vous de jouer! Ce n’est pas aussi simple que du code bas, mais ce n’est pas aussi compliqué que cela puisse paraître. Le retour sur vos efforts en vaudra la peine. Et n'oubliez pas que nous avons utilisé AWS Device Farm avec Appium, mais vous pouvez utiliser d'autres batteries de serveurs. En outre, comme je l'ai mentionné précédemment, vous avez tout expliqué ici, ici et ici. Dites-nous comment cette solution a fonctionné pour vous!