Dans la programmation informatique et les tests de logiciels, le “Smoke testing” sont des tests préliminaires pour révéler des défaillances simples suffisamment graves pour, par exemple, rejeter une version potentielle du logiciel.
le “Smoke testing” sont un sous-ensemble de cas de test qui couvrent les fonctionnalités les plus importantes d’un composant ou d’un système, utilisés pour aider à évaluer si les fonctions principales du logiciel semblent fonctionner correctement.
Objectif :
Chaque année, de plus en plus d’éditeurs de logiciels passent à une architecture de microservices utilisant des interfaces de programmation d’applications (API), car les API permettent aux différentes équipes d’un projet d’accéder facilement aux ressources des autres.
Les API permettent également aux éditeurs de logiciels ou aux particuliers d’obtenir des données les uns des autres : par exemple, Twitter dispose d’une API qui est utilisée par de nombreuses petites entreprises pour récupérer des tweets liés à leur entreprise pour les afficher sur la page Web de l’entreprise.
Si vous êtes intéressez sur l’utilisation de l’API Twitter, voici une vidéo qui parle du sujet :
Une autre grande caractéristique des API est qu’elles sont plus petites qu’une application monolithique, ce qui signifie qu’elles peuvent être déployées fréquemment.
Imaginons dans une entreprise on dispose de plusieurs API et on déploies plusieurs environnements différents. Chaque jours des tests de non régression sont fait, les tests seront fastidieux, répétitifs et complexe si fait à la main. le problème peut être résolu en configurant des “smoke testing” d’API automatisés qui s’exécutent avec chaque déploiement, dans chaque environnement.
Dans cet article, on verra comment on peut tester en utilisant des “smoke testing”. On peut utilisé des logiciel comme Postman, Newman et Powershell par exemple pour configurer nos “smoke testing” automatisés.
On va décrire ce que nous pouvons faire avec ces outils. Cependant, ces stratégies pourraient être adoptées pour n’importe quel pipeline de déploiement continu (CD).
1) Décidez quoi tester
L’objectif principal des “smoke testing” est d’effectuer des tests simples et de haut niveau pour s’assurer que le déploiement a réussi. Ce n’est pas l’endroit pour tester tout ce que votre API peut faire. Lorsque on choisi quoi mettre dans les “smoke testing”, voici ce qu’on peut considéré:
- On peut mettre en place à chaque point de terminaison un test réussi. Par exemple, une requête GET pour une ressource avec un ID spécifique devrait renvoyer cette ressource. Vous voudrez tester chaque point de terminaison une fois pour vérifier que chacun fonctionne comme prévu.
- S’il y avait des variations majeures dans la façon dont un paramètre spécifique serait utilisé, on peut ajouté un ou plusieurs tests pour vérifier ces variations. Par exemple, une API de récupération de fichiers où un fichier peut être récupéré par deux méthodes différentes. Le point de terminaison semble identique, mais les corps des requêtes sont différents. On peut donc ajouter un test pour chaque méthode.
- Pour les points de terminaison qui nécessitaient un certain niveau de sécurité, on peut ajouter un test pour valider qu’une demande sans l’authentification appropriée ne renverrait PAS d’informations et renverrait à la place une erreur de niveau 400.
- On peut se passer d’ajouter d’autre test négatif, comme une requête POST avec des données en dehors des paramètres autorisés, si ce n’est pas nécessaires pour garantir le fonctionnement de l’API. On peut plutôt exécuté ces tests dans le cadre d’une suite de régression nocturne.
2) Exportez vos tests
On peut utiliser Postman pour créer vos tests d’API, donc lorsque les tests ont été créés, On peut exporter à la fois la collection de tests et le fichier d’environnement de test dans des fichiers JSON.
Pour ceux qui ne sont pas familiers avec Postman, vous pouvez voir notre vidéo sur le Postman :
3) Rédigez un script pour exécuter vos tests
Postman a un outil de commande appelé Newman qui peut être utilisé pour exécuter une collection de tests, on peut l’utilisé pour exécuter les tests. On peut créé un script Powershell qui exécuterait la commande Newman.
4) Créer une étape de déploiement pour appeler votre script
Une fois le script Powershell prêt, on peut mettre en place une étape de déploiement dans chaque projet de déploiement d’API qui exécuterait le script de test. Si le script échouait, le déploiement échouerait.
5) Organisez vos variables
Les variables sont souvent à prendre en compte lors de l’exécution de smoke testing dans différents environnements. Par exemple, dans un environnement QA, l’utilisateur test peut avoir un ID de 1000, mais dans l’environnement préproduction, l’utilisateur test peut avoir un ID de 3450.
Un autre problème avec les variables est que parfois, pour des raisons de sécurité, vous n’avez peut-être pas accès aux mots de passe ou aux clés dans les environnements de préproduction. On peut utilisé un outil pour passer les valeurs dont on a besoin au script de test pour exécuter nos test en préproduction.
Il y avait trois différents types de variables nécessaires pour notre smoke testing :
- Variables qui peuvent être inchangées pour chaque environnement de test, Comme le nom. Ces variables pouvaient être placées directement dans l’environnement Postman, plus rien à faire donc après ça.
- Variables qui changent pour chaque environnement de test, mais qui n’ont pas besoin d’être sécurisées, telles que l’ID de l’utilisateur par exemple 160.
- Variables qui changent pour chaque environnement de test et devaient être sécurisées, telles que Token API: “b20628a9-3c00-4dad-b38c-0a4d2d85fXXX”.
On peut récupérer ces valeurs avec le script afin de pouvoir les passer à nos test dans notre environnent de production.
Conclusion :
Dans cet article, on a pu voir une méthode que vous pouvez ajouter “Smoke testing” dans votre pipeline de déploiement continu. Cet article n ‘est pas un tutorial mais un descriptif global d’une méthodologie pour mettre en œuvre le “Smoke testing”.
