Résumé des tests multicouches
Je pense qu'un système de test automatisé bien conçu et une culture de développement axée sur les tests peuvent conduire à une augmentation considérable de la qualité et à une réduction des défauts de production. Une approche du développement logiciel axée sur les tests et bien structurée garantira que tous les niveaux de fonctionnalité (de la logique programmatique aux scénarios fonctionnels, en passant par les règles commerciales) sont capturés de manière exécutable et automatisée.
En outre, les bogues qui atteignent la production peuvent être diagnostiqués, enveloppés dans des tests et libérés afin qu'ils ne réapparaissent pas.
Enfin, l'intégration de l'exécution automatisée de ces tests dans le pipeline de construction les rendra rapides, lisibles et fiables pour tous les membres de l'organisation.
Couches de tests automatisés
Il existe de nombreux articles en ligne couvrant les différents types de tests dans le cycle de vie du développement logiciel, ainsi que les détails de leur mise en œuvre et les raisons pour lesquelles il faut privilégier certains types par rapport à d'autres.
Dans ce blog, je vais tenter de décrire les trois niveaux de tests qui, lorsqu'ils sont mis en œuvre à l'unisson, avec le bon objectif et au bon endroit dans le pipeline de déploiement, peuvent.. :
conduire à une augmentation de la qualité globale du code et de la conception
Attraper les bogues avant la mise en production (ou classer les bogues sournois qui parviennent à la production)
servir de documentation sur le projet
Accroître la confiance dans l'équipe de développement pour qu'elle publie un produit de la meilleure qualité possible.
Le niveau de test le plus bas que la plupart des développeurs connaissent est le suivant le test unitaire. Le deuxième niveau de test, souvent négligé, est le test d'intégration. les tests d'intégration. Le dernier niveau de test que la plupart des gens imaginent lorsqu'ils entendent parler de tests automatisés est le test au niveau du système. Test de l'interface graphique.
Tests unitaires
La plupart des développeurs connaissent les tests unitaires, qui font aujourd'hui partie intégrante du cycle de développement des logiciels. L'objectif premier de ces tests est de vérifier la fonctionnalité de bouts de code contenant une logique simple ou complexe. L'objectif secondaire des tests unitaires est de servir de suite de régression pour les modifications futures des bouts de code qui pourraient accidentellement altérer la fonctionnalité.
Les tests unitaires prennent de plus en plus de valeur dans les efforts de développement importants car ils aident les développeurs à documenter la fonctionnalité des différentes unités de code qui pourraient ne pas être capturées au niveau de la fonctionnalité ou dans une histoire d'utilisateur. D'après ma propre expérience, l'écriture d'un code entièrement testé à l'unité permet d'obtenir des unités de fonctionnalité mieux conçues, lisibles et susceptibles d'être étendues à l'avenir.
La plupart des systèmes de compilation récupèrent et exécutent automatiquement les tests unitaires situés au bon endroit dans le projet. L'exécution de ces tests en tant que dans le cadre de la construction est cruciale dans le cycle de vie du développement logiciel, car elle permet d'informer les développeurs de la présence de fonctionnalités défectueuses avant que les défauts n'atteignent l'environnement d'assurance qualité.
Les outils de couverture de code sont des extensions précieuses des outils de test unitaire dont tous les efforts de développement devraient tirer parti. Ces outils indiquent les parties du code qui ne sont pas couvertes par les tests unitaires et peuvent grandement aider les développeurs à voir où des tests supplémentaires sont nécessaires. Bien qu'il ne soit pas nécessaire de viser une couverture de code de 100 % avec ces outils, une entreprise peut choisir un seuil de couverture de code avec lequel elle se sent à l'aise. Ensuite, de la même manière que les tests unitaires doivent être réussis pour que le processus de construction se termine avec succès, les outils de couverture du code peuvent être intégrés dans le processus de construction et un certain seuil doit être atteint pour que la construction soit réussie.
QUAND ET OÙ LES EXÉCUTER :
Ces tests doivent être intégrés et exécutés dans chaque projet et un échec dans les tests unitaires doit entraîner l'échec de la construction.
Tests d'intégration (tests API)
Le test d'intégration est un niveau de test souvent négligé car il n'est pas aussi largement discuté que le test d'unité et il n'est pas aussi intuitif ou tape-à-l'œil que le test d'interface graphique. La valeur des tests d'intégration ne peut cependant pas être sous-estimée. Ces tests doivent être utilisés pour capturer et exercer pleinement les exigences commerciales de manière exécutable.
L'objectif de ces tests est d'épuiser les règles commerciales positives et négatives qui sont demandées au système. Un élément clé de la création de ces tests pour maximiser leur valeur consiste à de faire en sorte que l'ensemble de l'équipe de les créer en tant que groupe. Le travail en groupe permet à l'ensemble de l'équipe de comprendre la portée et la couverture des tests.
Des outils tels que Cucumber qui utilisent la syntaxe Gherkin sont un excellent moyen d'exprimer vos règles de gestion d'une manière compréhensible pour l'entreprise et nécessitent un minimum de codage pour transformer chaque ligne en un extrait de code exécutable pour effectuer les tests. Si possible, le BA et le QA écrivent les tests ensemble dans le cadre des exigences de l'histoire de l'utilisateur, puis les développeurs écrivent l'implémentation des cas de test qui communiquent avec le système.
En outre, ces tests n'ont pas d'interface avec une interface graphique et communiquent par des canaux plus directs, ils sont donc beaucoup plus rapides à exécuter que les tests d'interface graphique. Les tests d'intégration doivent s'interfacer avec un système déployé Les tests d'intégration doivent s'interfacer avec l'API d'un système déployé par paires requête/réponse, ce qui permet aux tests d'intégration de s'exécuter suffisamment rapidement pour fournir un retour d'information en temps réel sur l'état et la validité du système déployé.
Une façon de mettre en œuvre ce niveau de test est d'écrire un programme de test personnalisé qui prend les cas de test Gherkin, construit une requête web basée sur les entrées de test, envoie la requête au serveur et capture la réponse, puis vérifie la réponse par rapport aux sorties de test attendues. Les projets utilisant des outils tels que Cucumber pour Java ou SpecFlow pour .NET remplissent bien cette tâche. En outre, il existe des outils tels que SoapUI Pro qui disposent de suites de programmes complètes pour s'adapter au niveau de test.
Enfin, pour maximiser la valeur de ces tests, il est essentiel de les intégrer dans un pipeline CI/CD. Mettre en place un environnement de test d'intégration et exécuter les tests dans cet environnement avant de les déployer dans un environnement d'assurance qualité est un moyen efficace de valider la fonctionnalité du système. Le déploiement d'un environnement de test d'intégration autonome permet d'exécuter les tests dans un environnement de type production, de déployer une application de type production et de se connecter à des services et à des sources de données en direct, ce qui a pour effet de augmentent la confiance dans les résultats des tests. Cet environnement supplémentaire permet également d'interrompre le déploiement en cas d'échec des tests d'intégration.
QUAND ET OÙ LES EXÉCUTER :
Ces tests doivent être intégrés dans le pipeline de construction et exécutés comme condition préalable au déploiement dans un environnement d'assurance qualité. En cas d'échec, le déploiement dans l'environnement QA doit être interrompu.
Test du système (test de l'interface graphique)
À partir de la même interface qu'un utilisateur (personne ou processus) du système, ces tests vérifient qu'une nouvelle fonctionnalité de l'entreprise fonctionne comme prévu. Ils devraient inclure tous les scénarios positifs et négatifs que l'entreprise souhaiterait voir, mais pas toutes les permutations de données qui permettraient de réaliser ce scénario. En outre, s'il existe une logique métier dans la couche de présentation, les tests de l'interface graphique doivent également couvrir tous les scénarios. Il existe de nombreux outils pour automatiser cette étape, tels que WebDriverpour tester l'interface d'un navigateur et TestComplete pour tester les applications Windows.
Cette étape doit également être intégrée au système CI/CD, et le test doit être exécuté contre l'environnement QA immédiatement après le déploiement. Ces tests servent à automatiser les tests simples et efficaces qui prouvent que la nouvelle fonctionnalité de l'entreprise est correctement représentée dans le système jusqu'à la couche d'interface graphique.
L'automatisation de ces tests et leur exécution après chaque déploiement de l'environnement d'assurance qualité renforcent le fait que la fonctionnalité correcte est en place, renforcent la confiance dans la suite de tests de régression et libèrent le processus d'assurance qualité manuel pour un cas limite et des tests exploratoires.
UN MOT D'AVERTISSEMENT :
Soyez prudent lorsque vous écrivez ces tests. N'essayez pas de tester le système de manière exhaustive à partir de l'interface utilisateur pour des raisons de performance et de stabilité. Vous ne voulez PAS que les coûts de maintenance de ces tests deviennent un fardeau.
QUAND ET OÙ LES EXÉCUTER :
Ces tests doivent être intégrés dans le pipeline de construction et exécutés automatiquement dans un environnement d'assurance qualité fraîchement déployé. Les rapports doivent être générés automatiquement et envoyés aux développeurs qui ont apporté des modifications au code.
