Lancement de la couverture des appels d'UI pour les tests de sécurité dynamiques

Cet été, l'équipe Ostorlab a été très active et nous sommes ravis de lancer une série d'annonces sur diverses nouvelles capacités et fonctionnalités dans les semaines à venir. La première est la sortie de la UI call coverage (couverture des appels d'UI) et d'une nouvelle version améliorée de notre Monkey Tester.

La nouvelle fonctionnalité affiche le parcours d'interface exercé pendant l'analyse dynamique. Elle offre aussi un moyen simple de valider la couverture de l'application et de s'assurer que les cas d'usage critiques sont bien couverts.

Cette nouvelle version apporte de nombreuses améliorations à la logique du monkey tester : une meilleure compréhension des composants d'interface et la génération d'événements pertinents, qui offrent une couverture élevée de la logique de l'application.

Monkey testing et automatisation des interactions avec l'UI

Le monkey testing est une technique de test automatisé dans laquelle un exécuteur de tests injecte des entrées et déclenche des clics ou des événements à différents endroits de l'application, afin de tester plusieurs aspects : détecter des plantages ou des erreurs, suivre les performances ou trouver des problèmes de sécurité.

Pendant l'analyse dynamique, le scanner d'Ostorlab utilise de vrais appareils sur lesquels le monkey tester génère une série d'événements pour interagir avec l'application. Les entrées peuvent être des interactions directes de l'utilisateur, comme un balayage, un clic sur un bouton ou la saisie dans un champ de texte, ou des interactions système, comme l'activation ou la désactivation du Wifi, du Bluetooth ou du GPS, ou l'envoi d'un IPC.

Notre technologie prend en charge les plateformes Android et iOS et couvre les applications natives ainsi que les frameworks multiplateformes comme Xamarin, Cordova, Ionic et Flutter.

Il existe peu d'outils open source d'automatisation des tests d'UI, et ceux-ci présentaient plusieurs difficultés :

• Ils se concentrent sur une seule plateforme et n'offrent pas de moyen commun d'exécuter ou d'exprimer les tests
• Ils prennent mal en charge plusieurs plateformes et frameworks courants. Certains frameworks, en particulier, ont des approches très singulières pour créer les composants d'UI, comme Xamarin et Flutter.
• Ils couvrent mal les schémas d'usage clés, comme l'inscription avec acceptation d'une politique ou le remplissage d'un menu de paiement.

Pour surmonter ces difficultés et maximiser la couverture de l'application sur toutes les plateformes, nous nous appuyons sur trois stratégies d'exploration :

• Stratégie aléatoire
• Stratégie basée sur des règles
• Stratégie évolutionnaire

Stratégies d'exploration

L'utilisation de stratégies similaires n'est pas propre à Ostorlab. Plusieurs outils open source et articles de recherche ont implémenté des stratégies comparables. La plus notable est Sapienz, de Facebook. La version open source n'est pas maintenue, mais Facebook a fait plusieurs présentations sur les améliorations apportées à la version interne.

Une première différence de conception clé avec la plupart de ces implémentations est que ces stratégies ne sont pas exécutées séparément, mais font partie d'une stratégie d'ensemble qui les combine. Cela permet de transformer plusieurs stratégies peu performantes en une seule stratégie performante.

La seconde différence clé est que ces stratégies ne génèrent pas des cas de test rigides, qui peuvent s'appliquer ou non, car la reproductibilité des tests n'est souvent pas garantie. Elles génèrent plutôt des test minions dotés d'un ensemble de paramètres qui modifient la façon dont le minion interagit avec l'application, ainsi que le type d'action ou de succession à privilégier.

Stratégie aléatoire

La Random-based strategy (stratégie aléatoire) est la technique la plus basique pour interagir avec l'application. Elle génère une série aléatoire d'événements et convient aux vues comportant plusieurs composants indépendants. Par exemple, une vue avec différents éléments cliquables, des articles de texte et des vidéos.

Pour illustrer le fonctionnement de la stratégie aléatoire et mesurer son efficacité, voici une vue simple de 6 composants d'UI. Dans cette vidéo, nous pouvons voir les différents événements générés par le monkey tester et la façon dont il les exerce :

Pour une stratégie aléatoire avec 4 types d'événements (balayage, clic, toucher et vérification), il faut en moyenne 30 événements pour interagir avec les 6 composants d'UI différents. Pour interagir selon une séquence précise, comme Fill Textbox + Enable Checkbox + Click button 2, il faut en moyenne 95 événements.

Les stratégies aléatoires sont simples, mais peuvent prendre très longtemps (voire ne jamais aboutir) à couvrir des schémas logiques complexes.

Stratégie basée sur des règles

La Rule-based strategy (stratégie basée sur des règles) met en corrélation l'interaction de l'utilisateur et le composant d'UI de l'application. Elle utilise des mécanismes de recherche pour identifier des typologies de composants précises et peut appliquer une logique avancée à ces composants. Cette technique convient aux vues dont les actions sont prévisibles d'après la typologie des composants. Par exemple, une vue de formulaire avec des champs de texte à remplir, plusieurs cases à cocher et un bouton cliquable.

Voici l'exemple d'une vue de connexion simple avec un nom d'utilisateur, un mot de passe et un bouton de connexion.

Dans cet exemple, une règle vérifie s'il y a un champ de mot de passe dans la vue courante, ou effectue une vérification plus sophistiquée pour identifier une carte bancaire ou un composant de carte géographique

Le monkey tester parcourt d'abord toutes les règles pour déterminer celles qui correspondent à la vue courante, puis en sélectionne une au hasard. Dans l'exemple ci-dessus, le monkey tester a d'abord identifié plusieurs champs de texte et a commencé à les remplir avec des valeurs factices, dans le cadre de l'interaction de la stratégie aléatoire. Il a ensuite appliqué une règle de connexion en injectant le nom d'utilisateur et le mot de passe, puis en cliquant sur le bouton de connexion.

Stratégie évolutionnaire

La Search-based strategy (stratégie basée sur la recherche) utilise des algorithmes de recherche méta-heuristiques reposant sur un algorithme génétique.

Les algorithmes génétiques servent à optimiser les paramètres des test minions pour maximiser la couverture. La stratégie garde la trace des entrées et de la couverture de l'application. À chaque itération, les paramètres sont mutés pour augmenter cette couverture et écarter les minions peu performants.

Cette stratégie convient aux applications dont les vues suivent des chemins différents selon les entrées de l'utilisateur. Par exemple, un questionnaire dont les réponses peuvent mener à des vues différentes selon les réponses fournies.

Résumé

Si chaque stratégie a montré une bonne couverture sur des types de vues précis, la couverture complète de chaque stratégie prise séparément, testée sur plus de 1000 applications mobiles, est restée relativement faible.

La couverture moyenne la plus élevée atteinte était de 35 % pour la stratégie aléatoire, de 27 % pour la stratégie basée sur des règles et de 38 % pour la stratégie basée sur la recherche. En revanche, réunir ces stratégies dans une stratégie d'ensemble qui combine toutes les précédentes a offert une couverture nettement plus élevée, de 52 %, en moins de temps.

Globalement, le monkey tester repensé et la nouvelle visibilité sur la couverture des cas de test offriront une couverture plus élevée et faciliteront la visualisation et la compréhension de ce qui a été fait en coulisses.