La robustesse des tests logiciels automatisés

par Christophe Cressend | 10 décembre 2020

Qu’est-ce qu’un système robuste ?

La robustesse d’un système peut être définie comme « la stabilité de la performance », « la capacité à reproduire un comportement attendu », quand les conditions externes auxquelles il est soumis varient, parfois de façon inattendue.
On peut l’associer à la « performance », qui peut être définie comme « la capacité à reproduire un comportement attendu » uniquement dans une plage réduite de fonctionnement prédéfinie.
Il y a aussi les systèmes non performants, et donc non robustes, qui ne sont pas l’objet de cet article.

La robustesse d’un logiciel, c’est quoi ?

Dans le domaine des tests logiciels, la notion de « plage de fonctionnement » est primordiale puisqu’elle va permettre de faire la distinction entre un fonctionnement nominal et performant et un fonctionnement où la robustesse du logiciel sera nécessaire pour qu’il assure le fonctionnement attendu.

Il y a d’ailleurs un domaine des tests logiciels qui adresse les problématiques de robustesse et qui permet de définir plus complètement sa plage de fonctionnement : par exemple le nombre d’utilisateurs simultanés qui utilisent le même serveur, ou l’utilisation de volumes de données en dehors des conditions d’utilisations recommandées. L’objectif de ces tests est de pousser le système à bout de façon à déterminer les limites de sa plage de fonctionnement.

La définition de la plage de fonctionnement permet alors de faire des préconisations en termes de prérequis matériels et logiciels (OS) qui assureront un fonctionnement nominal.

Comment définir la robustesse d’un test automatisé

Dans la domaine du test logiciel fonctionnel automatisé, si l’on veut faire simple, on ne devrait pas devoir faire appel à un fonctionnement « robuste » des tests : tout doit se dérouler de façon nominale afin d’éviter des flaky tests, faux-négatifs, ou tests en échec sans raison apparente.

Si vous rejouez vos tests en intégration continue, il va falloir analyser ces flaky tests régulièrement pour comprendre que les causes d’échec ne sont pas dues à des bugs du logiciel testé, mais bien aux conditions de réalisation des tests, et vous aurez perdu votre temps.

Comment assurez que les tests soient robustes ?

Pour assurez que vos tests seront performants, il est nécessaire d’agir à plusieurs niveaux:

  • assurez vous que vos tests soient déterministes : que leur déroulement soit le résultat d’un scénario prédéfini et prévu, cela évite les sorties en échec au premier comportement inatendu.
  • assurez vous que les données sur lesquels ils agissent soient identifiées : soit en demandant à chaque tests de créer ses propres données, soit créant un référentiel de données commun dans lequel chaque test pourra trouver les données sur lesquelles il agit sans importuner les autres tests. Cela sera d’autant plus efficace si vous envisagez de paralélliser vos tests.
  • assurez vous que les conditions matérielles de rejeu des test soient identiques : par exemple le temps de réponse des serveurs peut générer des flaky tests, et donc la charge des serveurs et donc les horaires peuvent être important. Si vous faites des tests utilisant la reconnaissance graphique, les environnements matériels sont aussi importants.

La robustesse des tests selon Agilitest

Le parti pris initial d’Agilitest est d’essayer de limiter au maximum les activités de maintenance des tests, et donc les analyses de flaky tests inutiles.

C’est pourquoi nous avons dès le début mis au centre de nos priorités le fait de pouvoir assurer un fonctionnement optimal des tests, même quand les conditions de réalisation sortent de la plage de fonctionnement, mais en s’assurant qu’un test doit être déclaré KO le soit effectivement.

Nous avons par ailleurs tout un ensemble de fonction qui vont vous permettre de créer des données randomisées qui seront ensuite utilisées dans tout votre test, et uniquement par celui-ci.

Vous pourrez constater qu’Agilitest est rapide, mais va prendre son temps avant de déclarer une condition d’échec, par exemple

  • contrôler plusieurs fois qu’une valeur différente de celle attendue a bien toujours la même valeur dans l’application.
  • s’assurer que le serveur a bien renvoyé les données attendues.
  • s’assurer qu’un élément sur lequel nous devons réaliser une opération est bien présent.

Atteindre zéro flaky tests est le graal vers lequel nous tendons, c’est un enjeu important puisqu’à la clé, il y a la possibilité de délivrer une version qualifiée de votre logiciel à tout moment en ayant la certitude que vous avez couvert la majorité, si ce n’est la totalité, des fonctions importantes.

Crédit photo : Reimund Bertrams de Pixabay