Lorsqu’un jeu de tests devient volumineux et doit être lancé régulièrement, les équipes d’ingénierie logicielle ressentent le besoin d’automatiser ces tests. Les tests boîte-blanche (comme les tests unitaires par exemple), sont en général écrits dans un langage de programmation qui propose un framework de test et seront donc faciles à automatiser. Leur lancement consistera simplement à exécuter une commande dans un IDE ou un shell. Les tests fonctionnels en mode boite-noire sont un sujet plus délicat. Ils dépendent beaucoup du type de logiciel sous test (SUT). Un logiciel d’analyse d’images et une application mobile de réseau social ne seront pas testés fonctionnellement de la même manière, les exigences en matière d’outil d’automatisation seront donc différentes.

Dans cet article, nous allons voir comment automatiser les tests fonctionnels d’un logiciel similaire au produit d’analyse d’images utilisé comme exemple dans notre précédent article. Ce type de logiciel peut être testé avec des tests de type boîte-noire qui accèdent au SUT sous l’interface graphique (tests également appelés sous-cutanés). Ces tests sont principalement basés sur les données : entrée et sortie attendue. Pour une description plus détaillée de ce type de test fonctionnel, voir notre article « How to Approach Functional Testing« .

guy staring at wall

Pour passer des tests manuels aux tests automatisés, vous devez:

  • décrire le comportement de vos tests
  • stocker vos données de test (entrée, sortie attendue et résultats d’exécution du test).
  • exécuter vos tests sur du matériel / logiciel spécifique.
  • monitorer l’exécution des tests.
  • analyser les résultats des tests et surveiller / rendre compte des tendances en matière de qualité.

Voyons chacun de ces éléments un par un.

Décrire le comportement de vos tests

Vous allons donc devoir décrire les étapes de vos tests fonctionnels. Pour un SUT de traitement de données, le scénario doit suivre ce modèle :

  • Charger des données qui seront utilisées comme entrée pour le SUT.
  • Executer le SUT en utilisant les données d’entrée et enregistrer les données de sortie.
  • Charger les données qui seront utilisées comme sortie attendue du SUT.
  • Comparer les données attendues avec les données de sortie réelles du SUT.
  • Renvoyer un statut en fonction de la comparaison précédente.

Pour exprimer ces étapes, vous pouvez utiliser un langage générique tel que Java, C # ou Python, ainsi qu’un framework de test associé. Une autre option consiste à utiliser un DSL (Domain Specific Language) comme ceux proposés par Cucumber ou Robot Framework. Ces deux solutions offrent des possibilités infinies mais nécessitent des compétences de programmation spécifiques. Le risque ici est de finir par re-créer un framework de test personnalisé au-dessus de celui fourni avec ces langages pour répondre aux besoins particuliers de l’entreprise.

Une autre option consiste à utiliser des solutions de test commerciales offrant une automatisation fonctionnelle sans code / sans script. La plupart de ces solutions proposent une automatisation via l’interface graphique, ce qui n’est pas ce que vous recherchez. Comme indiqué précédemment, vous souhaitez créer des tests sous l’interface graphique et peu de fournisseurs proposent de telles fonctionnalités.

Stocker les données des tests

Vos tests fonctionnels nécessitent des données d’entrée et de sortie attendues. Ces données peuvent être lourdes (image, sons, vidéo, etc.) et nombreuses. De plus, ces données évolueront avec le SUT de plusieurs manières :

  • Le format des données (entrée ou sortie) de la v2 de votre SUT peut différer de celui utilisé dans la v1.
  • Le contenu des données changera également (les données de référence utilisées comme sortie attendue dans v1 pourraient être différentes dans v2).

Cela signifie que vous devrez conserver les différentes versions de ces données. Par conséquent, la quantité totale de données que vous aurez besoin de stocker peut devenir considérable.

Pour stocker ces données, il existe essentiellement trois possibilités:

  • Ajouter vos données à votre SCM (par exemple, git). Cela fonctionne bien lorsque vous utilisez des données texte de taille raisonnable, mais lorsque vous utilisez des fichiers très volumineux ou binaires, le modèle SCM n’est pas bien adapté.
  • Investissir dans des infrastructures privées et ajouter de la capacité de stockage en fonction des besoins. Cela signifie des disques RAID, un réseau local à haut débit, un onduleur, des sauvegardes régulières, etc. Cependant, cette configuration matérielle requise n’est que la partie visible de l’iceberg. L’effort le plus important sera de personnaliser ou de créer une solution logicielle adaptée à vos besoins d’organisation et de gestion de versions. Lorsque vous construisez votre propre installation de stockage, cela nécessitera beaucoup de maintenance logicielle et matérielle, ce qui pourrait être le cas pour votre projet d’automatisation.
  • Utilisez une infrastructure cloud. Il y en a de très bonnes aujourd’hui, mais ces services sont principalement des briques techniques qui doivent être connectées au reste de votre solution d’automatisation. Cela nécessite une expertise spécifique dans laquelle vous pourriez être peu enclin à investir.

De plus, chaque exécution de test générera des données que vous voudrez peut-être conserver pendant un laps de temps plus court (e.g. pour le débogage) ou pour toujours (e.g. pour une future release). Vous devrez mettre en œuvre une solution complexe pour gérer automatiquement ces données afin d’optimiser l’utilisation de votre espace disque.

Exécuter les tests

Lorsque vos tests sont automatisés, vous aurez besoin au moins d’un ordinateur que vous pourrez utiliser pour les exécuter. En pratique, vous en aurez probablement besoin de plusieurs ! Comme mentionné précédemment, il existe de nombreux tests, et chaque test peut durer longtemps. La durée totale d’exécution de tous ces tests risque d’être trop longue pour être tolérable. Étant donné que les tests sont indépendants, le choix de les lancer en parallèle est évident, mais cela signifie que vous aurez besoin d’un cluster de machines.

Même si le parallélisme n’est pas requis, vous devrez peut-être tester le SUT sur plusieurs plates-formes:

  • Matériel différent (cœurs, processeur, mémoire, etc.)
  • Différents OS (Windows, Linux, MacOS, etc. et éventuellement chacun en plusieurs versions)

Quelle que soit la situation, vous aurez certainement besoin d’une petite batterie de serveurs. En ce qui concerne le stockage de données, vous devez choisir entre des serveurs auto-hébergés ou des services en ligne. Depuis l’avènement des services fournissant des machines virtuelles en ligne (AWS ouvrant la voie à de nombreuses autres), ces services sont devenu un choix évident au détriment de la gestion de serveurs internes. Les serveurs internes peuvent avoir un coût total qui peut ne pas valoir la peine pour la plupart des organisations. Dans le cas des tests fonctionnels, vous aurez peut-être besoin de nombreuses machines et leur utilisation peut être non continue avec des pics d’activité lors des phases où les tests doivent être lancés plus souvent. Choisir une solution en ligne est presque une évidence. Cependant, après vos premières expériences réussies, si vous décidez d’investir dans une telle solution, vous devrez engager ou former des spécialistes pour l’administration et l’optimisation des coûts. Comme nous l’avons mentionné pour les services de stockage en ligne, la connexion de cette infrastructure à votre solution d’automatisation risque de ne pas être aussi simple que prévu.

Monitorer l’exécution des tests

L’élément suivant de votre solution d’automatisation est l’outil à partir duquel vous pouvez lancer et suivre l’exécution des tests. Les tâches de lancement associées au génie logiciel sont généralement attribuées à un serveur d’intégration continue (CI). Si vous utilisez déjà un serveur de CI (pour builder ou releaser), vous pouvez choisir de l’utiliser pour gérer l’exécution de vos tests fonctionnels. Toutefois, les possibilités des serveurs de CI en termes de tests fonctionnels risque d’être limitées. Les principales fonctionnalités sont généralement les suivantes: lancement d’un travail, suivi de la sortie standard lors de l’exécution et affichage d’un simple graphique des résultats.

Si vous n’utilisez pas actuellement de serveur de CI (et n’en avez pas besoin), vous pourriez éventuellement écrire votre propre tableau de bord avec votre propre ensemble de scripts et de programmes. Comme d’habitude avec des outils personnalisés, le démarrage sera simple et facile, mais avec l’évolition des attentes de l’équipe utilisant cet outil, cela deviendra de plus en plus compliquées à gérer.

Analyser les résultats des tests et dégager des tendances qualité

L’élément final de notre solution d’automatisation est un tableau de bord où les résultats et les tendances peuvent être analysés. Les résultats d’une campagne doivent être affichés de manière à vous permettre de faire une analyse détaillée du statut global d’une campagne jusqu’aux tests individuels ayant échoué. Pour chaque test, vous devez également avoir accès à l’historique d’exécution afin de pouvoir facilement identifier quand il a commencé à échouer. En cas d’échec, vous devez avoir accès aux logs des tests pour vous aider à comprendre son origine. Lorsque l’échec est lié à une régression dans le SUT, le tableau de bord doit vous permettre de qualifier le test de «bug connu» et de le connecter à votre logiciel de suivi d’anomalie (par exemple, Jira) afin de pouvoir y ouvrir automatiquement un ticket.

Vous souhaitez également avoir accès aux tendances générales en matière de qualité (pourcentage de succès, durée des tests, etc.). Idéalement, vous regrouperez ces résultats de test fonctionnel avec des données provenant d’autres activités de test (tests unitaires, tests de performance, etc.) pour transformer votre tableau de bord en un tableau de bord complet sur la qualité. Si vous utilisez un serveur de CI, vous trouverez quelques éléments de rapport (souvent via des plugins), mais le plus souvent, ils ne sont pas centraux dans ces solutions et il est difficile d’obtenir une vue globale de la qualité sans développement personnalisé.

Il existe de nombreuses raisons pour lesquelles vous voulez produire des résultats de test ou des rapports de qualité. Par exemple, vous devrez peut-être fournir le statut qualité d’une version spécifique à un client, les résultats des tests à des auditeurs externes dans le cas d’un logiciel certifié, informer la direction du statut qualité, etc. La possibilité de personnaliser votre rapport, tant dans le contenu que dans le format, deviendra certainement nécessaire à terme.

Challenges pour construire une solution d’automatisation de tests fonctionnels

Nous avons vu qu’il y a plusieurs éléments nécessaire pour répondre à vos besoins d’automatisation. Nous pouvons les illustrer avec notre exemple d’analyse d’image:

  • Un langage pour exprimer les étapes de chargement des images utilisées en entrée du SUT, exécuter le programme et vérifier la sortie : langage générique, DSL, logiciel de test
  • Un système de stockage en ligne pour la gestion de toutes les données d’entrée, de sortie attendues et générées par test
  • Un service de machines virtuelles en ligne avec suffisamment de puissance de calcul et de RAM (pouvant nécessiter beaucoup de ressources) pour exécuter l’analyse: auto-hébergé ou en ligne
  • Un outil pour contrôler et surveiller les exécutions: serveur CI ou développement ad-hoc
  • Un tableau de bord pour analyser les résultats des tests et surveiller les tendances de la qualité : accès au résultat produit par le SUT quand celui-ci ne correspond pas à l’attendu, log d’exécution, etc.

Cependant, ces différents éléments devront être connectés ensemble. Les élément mentionné dans la liste précédente devront communiquer entre eux et c’est loin d’être le travail le plus simple ! Par exemple, le déplacement de données de votre installation de stockage vers votre infrastructure d’exécution nécessitera un script. De même, la sauvegarde de certaines données de sortie en cas d’échec du test depuis la VM d’exécution à l’installation de stockage ne sera pas simple. En fait, les défis que nous avons énumérés sont englobés dans une question encore plus grande : quel effort de programmation et de scripting sera nécessaire pour créer et maintenir un framework de test cohérent ?

Si vous êtes déjà à la recherche d’une solution d’automatisation des tests fonctionnels, consultez ce que nous proposons et contactez-nous afin d’explorer comment elle pourrait répondre à vos besoins. Et pour rester à jour avec notre produit, suivez-nous sur Twitter et LinkedIn

Share