Les équipes disent souvent qu’elles « utilisent l'automatisation » comme si cela réglait la question de la façon dont leurs tests sont organisés. Ce n'est pas le cas. Deux suites peuvent toutes deux être automatisées et pourtant être structurées de manières complètement différentes, avec des coûts de maintenance radicalement différents. La structure est le framework, et le type de framework que vous choisissez détermine la vitesse de croissance des tests, la facilité avec laquelle les non-développeurs peuvent y contribuer, et l'ampleur des répercussions d'un petit changement d'interface utilisateur sur votre code.
Cet article passe en revue les six types classiques de frameworks de tests d'automatisation : linéaire, modulaire, axé sur les données (data-driven), axé sur les mots-clés (keyword-driven), hybride et axé sur le comportement (behavior-driven). Il explique ce qu'est chacun d'eux, ses points forts et ses points faibles, afin que vous puissiez adapter une structure à votre équipe au lieu d'hériter de ce que le dernier ingénieur a mis en place. Les concepts s'appliquent aussi bien aux tests d'interface utilisateur (UI), d'API que unitaires.
Qu'est-ce qu'un framework de tests d'automatisation ?
Un framework de tests d'automatisation est un ensemble de lignes directrices, de conventions et de composants réutilisables qui définit la manière dont les tests automatisés sont écrits, organisés et exécutés. Ce n'est pas un outil que vous installez. C'est l'architecture dans laquelle vivent vos tests.
Un framework répond à des questions structurelles avant même que quiconque n'écrive un test. Où résident les données de test ? Comment les étapes réutilisables sont-elles partagées ? Qui peut contribuer, seulement les développeurs ou aussi les analystes ? Comment les résultats sont-ils rapportés ? Les différents types de frameworks répondent à ces questions différemment, et c'est ce qui les distingue. Si vous êtes novice sur l'idée plus large, notre aperçu de ce qu'est le test automatisé fournit un contexte utile avant la ventilation des types ci-dessous.
La raison pour laquelle cela compte est la maintenance. Écrire les cent premiers tests automatisés est facile. Maintenir un millier d'entre eux alors que l'application change chaque semaine est difficile, et le type de framework est le facteur le plus important dans le coût de cette maintenance.
Considérez un exemple concret. Un écran de connexion modifie les étiquettes de ses champs. Dans une suite, ce changement casse deux tests et prend dix minutes à corriger. Dans une autre suite testant exactement la même application, il casse deux cents tests et prend deux jours. L'application est identique ; seule la structure du framework diffère. Cet écart est la seule raison pour laquelle il vaut la peine de réfléchir au type de framework avant d'écrire du code, et non après.
Les six types de frameworks
1. Linéaire (enregistrement et relecture)
Un framework linéaire enregistre vos actions et les rejoue comme un script. Chaque test est une séquence plate d'étapes sans fonctions partagées et sans séparation des données et de la logique. Les outils génèrent le script pour vous, donc la barrière à l'entrée est presque nulle.
L'attrait est la rapidité pour les petits projets, les démonstrations rapides ou un contrôle ponctuel de "smoke test". Le coût apparaît rapidement. Comme rien n'est réutilisé, les mêmes étapes de connexion sont copiées-collées dans chaque test. Lorsque la page de connexion change, vous modifiez cinquante scripts. Les frameworks linéaires ne sont pas évolutifs, et la plupart des équipes les dépassent en quelques semaines.
2. Modulaire
Un framework modulaire divise l'application en petits modules indépendants et écrit une fonction réutilisable pour chacun. Un test est alors une composition de ces fonctions : se connecter, rechercher, ajouter au panier, commander. Lorsque l'écran de connexion change, vous corrigez une fonction et tous les tests en bénéficient.
C'est la première structure qui est véritablement évolutive. Le compromis est la conception initiale. Quelqu'un doit décider des limites des modules et construire la couche d'abstraction avant que les tests ne s'exécutent rapidement. Pour la plupart des équipes d'ingénierie, le modulaire est le choix par défaut sensé, et il s'accorde bien avec la discipline décrite dans notre guide sur la rédaction de scripts de tests automatisés.
3. Axé sur les données (Data-driven)
Un framework axé sur les données sépare la logique de test des données de test. Une fonction de test s'exécute plusieurs fois sur des lignes d'entrée stockées dans un fichier CSV, JSON, une feuille de calcul ou une base de données. La couverture augmente en ajoutant des lignes, et non en écrivant du code.
Ce type est idéal lorsque le même flux de travail doit être vérifié avec des dizaines de combinaisons d'entrées : connexions valides, connexions invalides, valeurs limites, variations locales. Pour les API spécifiquement, une approche de test axée sur les données avec CSV et JSON transforme une requête en des centaines de cas. Le compromis est que la logique de test elle-même est fixe ; la structure axée sur les données étend les entrées, pas les comportements.
4. Axé sur les mots-clés (Keyword-driven)
Un framework axé sur les mots-clés abstrait les actions en mots-clés nommés comme Login, SearchProduct ou VerifyTotal. Les tests sont écrits sous forme de tableaux de mots-clés et d'arguments, souvent dans une feuille de calcul, de sorte qu'un non-programmeur peut assembler des tests sans toucher au code.
La force est l'accessibilité. Les analystes QA et le personnel commercial peuvent construire et lire les tests directement. Le coût est la bibliothèque de mots-clés : les ingénieurs doivent construire et maintenir l'implémentation derrière chaque mot-clé, et un ensemble de mots-clés mal conçu devient un fardeau de maintenance en soi. La structure axée sur les mots-clés convient aux équipes où la création de tests et la plomberie des tests sont réparties entre différents rôles.
5. Hybride
Un framework hybride combine deux ou plusieurs des types ci-dessus, le plus souvent la réutilisation modulaire, les entrées axées sur les données et l'abstraction par mots-clés. Il s'agit moins d'un type distinct que d'une reconnaissance pragmatique selon laquelle les projets réels ont besoin de structures différentes à différents endroits.
La plupart des suites de tests matures sont hybrides lorsqu'elles atteignent quelques milliers de tests. Le risque est l'incohérence : si la combinaison n'est pas conçue délibérément, vous obtenez le coût de maintenance de chaque type et la clarté d'aucun. Un framework hybride fonctionne lorsque le mélange est intentionnel et documenté.
6. Axé sur le comportement (BDD)
Un framework axé sur le comportement exprime les tests en langage quasi naturel en utilisant le modèle Given-When-Then (Étant donné-Quand-Alors), généralement écrit en Gherkin et exécuté par des outils comme Cucumber. Un scénario se lit comme une phrase : étant donné un utilisateur enregistré, quand il soumet des identifiants valides, alors il atteint le tableau de bord.
La valeur du BDD est une compréhension partagée. Le produit, l'assurance qualité et l'ingénierie lisent la même spécification, ce qui réduit l'écart entre ce qui a été demandé et ce qui a été construit. Le coût est double : le Gherkin lisible et les définitions d'étapes qui l'implémentent. Si le personnel produit ne lit jamais réellement les scénarios, vous payez le prix du BDD sans en récolter les avantages. Notre guide Gherkin pour les tests d'API BDD montre le modèle appliqué aux API.
Comparaison des types de frameworks
| Type de framework | Réutilisation | Les non-codeurs peuvent créer | Coût de configuration | Évolutivité |
|---|---|---|---|---|
| Linéaire | Aucune | Oui, via l'enregistrement | Très faible | Médiocre |
| Modulaire | Élevée | Non | Moyen | Bonne |
| Axé sur les données | Moyenne | Partiellement | Moyen | Bonne pour les entrées |
| Axé sur les mots-clés | Élevée | Oui | Élevé | Bonne |
| Hybride | Élevée | Parfois | Élevé | Très bonne |
| BDD | Élevée | Oui, pour lire et créer | Élevé | Bonne |
Le tableau clarifie le modèle. Une configuration moins chère signifie généralement une évolutivité moindre, et les structures qui incluent des non-codeurs nécessitent plus d'investissement en ingénierie en coulisses. Il n'y a pas d'option gratuite, seulement une option adaptée à vos contraintes.
Erreurs courantes dans les frameworks
Même les équipes qui choisissent un type sensé le minent souvent en pratique. Trois erreurs se répètent sans cesse.
La première est l'abstraction prématurée. Une équipe adopte une structure axée sur les mots-clés ou hybride pour une suite qui contient quinze tests. La couche d'abstraction coûte plus cher à construire et à maintenir que les tests qu'elle dessert. La structure doit suivre l'échelle ; laissez la duplication réelle justifier la prochaine couche de réutilisation.
La seconde est l'inverse : refuser d'évoluer. Une suite linéaire qui fonctionnait avec vingt tests est toujours linéaire à quatre cents, et chaque changement d'application déclenche désormais un balayage douloureux de scripts copiés-collés. Le coût de rester linéaire s'accumule tranquillement jusqu'à ce qu'un seul petit changement anéantisse une journée. Repérez le signal, qui est la modification de nombreux tests pour un seul changement de produit, et refactorisez vers le modulaire avant que la douleur ne devienne routinière.
La troisième est de choisir un type pour un public qu'il n'a pas. Le BDD ne porte ses fruits que lorsque les non-ingénieurs lisent réellement le Gherkin. Le "keyword-driven" ne porte ses fruits que lorsque les analystes créent réellement des tests. Si ces personnes ne touchent jamais à la suite, vous supportez le coût de la couche supplémentaire sans aucun avantage. Adaptez le type à ceux qui participent réellement, et non à ceux qui pourraient le faire en théorie.
Comment choisir un type de framework
Choisissez en fonction de votre équipe et de votre projet, pas de la mode.
- Taille et durée de vie. Un script jetable peut être linéaire. Tout ce qui est maintenu pendant plus d'un trimestre devrait être modulaire au minimum.
- Qui écrit les tests. Tous les ingénieurs orientent vers le modulaire ou l'hybride. Les rôles mixtes orientent vers le "keyword-driven" ou le BDD.
- Variété des entrées. De nombreuses combinaisons d'entrées par rapport à des flux de travail stables orientent vers le "data-driven".
- Lacunes de communication. Des malentendus fréquents entre le produit et l'ingénierie orientent vers le BDD, car la spécification partagée est son principal avantage.
- Compétences existantes. Le meilleur type de framework est celui que votre équipe peut réellement maintenir. Une structure élégante que personne ne comprend échoue plus rapidement qu'une structure simple que tout le monde comprend.
La plupart des équipes optent pour un hybride : une réutilisation modulaire comme épine dorsale, des entrées axées sur les données pour les cas à forte variation, et le BDD là où la collaboration est la plus importante. Commencez simple et laissez la douleur réelle, et non la théorie, justifier l'ajout de structure. Pour une stratégie de test au-delà du type de framework, la distinction dans notre guide scénario de test versus cas de test vous aide à délimiter ce que chaque test doit couvrir.
Où une plateforme aide
Choisir un type de framework est une décision d'architecture. L'exécuter correctement nécessite toujours les bons outils. Pour les tests d'API en particulier, Apidog prend en charge la réutilisation modulaire via des requêtes partagées et paramétrées, des exécutions axées sur les données à partir de fichiers CSV et JSON, et un constructeur de tests visuel qui permet aux non-développeurs d'assembler des tests, ce qui est l'esprit d'une structure axée sur les mots-clés sans bibliothèque de mots-clés construite à la main.
C'est important car un type de framework n'est aussi bon que la capacité de l'équipe à le suivre de manière cohérente. Une plateforme qui intègre la structure maintient la cohérence des tests à mesure que la suite grandit et que les gens rejoignent et partent. Vous pouvez télécharger Apidog pour voir comment ces modèles fonctionnent en pratique, puis décider de la quantité de code de framework personnalisé dont vous avez encore besoin. La réponse honnête est généralement moins que ce que vous attendez, car Apidog gère déjà les couches de requête, de données et de rapports qu'un framework construit à la main réimplémenterait autrement.
Foire aux questions
Quelle est la différence entre un outil d'automatisation et un framework de tests d'automatisation ?
Un outil exécute les tests, comme un pilote de navigateur ou un client HTTP. Un framework est la structure autour de ces outils : les conventions pour organiser les tests, partager la logique, fournir des données et rapporter les résultats. Vous pouvez avoir un outil sans framework, mais les tests seront difficiles à maintenir. Le framework est ce qui rend l'automatisation durable.
Quel type de framework de tests d'automatisation est le meilleur ?
Il n'y a pas de meilleur universel. Le linéaire convient aux scripts jetables, le modulaire à la plupart des équipes d'ingénierie, le "data-driven" aux grandes variétés d'entrées, le "keyword-driven" et le BDD aux équipes aux compétences mixtes, et l'hybride aux grandes suites matures. Adaptez le type aux compétences de votre équipe et à la durée de vie du projet plutôt que de choisir l'option la plus populaire.
Le BDD est-il uniquement pour les tests d'API ou uniquement pour les tests d'interface utilisateur ?
Ni l'un ni l'autre. Le BDD est un modèle structurel, pas une couche. Le format Given-When-Then fonctionne pour les tests unitaires, d'API et d'interface utilisateur. Sa véritable exigence n'est pas la couche de test, mais le public : le BDD ne porte ses fruits que lorsque les non-ingénieurs lisent ou écrivent réellement les scénarios.
Puis-je changer de type de framework après avoir construit une suite ?
Oui, mais cela coûte un effort proportionnel à la taille de la suite. Passer du linéaire au modulaire signifie extraire des fonctions réutilisables des scripts copiés-collés. La leçon est de choisir une structure évolutive dès le début, car l'adaptation d'un type de framework à des milliers de tests est bien plus difficile que de commencer avec le bon.
Les petits projets ont-ils besoin d'un framework ?
Un projet véritablement éphémère peut fonctionner sur un script linéaire enregistré sans véritable framework. Mais les « petits » projets ont l'habitude de grandir. Si une suite doit vivre plus de quelques semaines ou être touchée par plus d'une personne, même une structure modulaire légère est rapidement rentable.