Qu'est-ce que le test de fumée ?
⚡ Résumé intelligent
Les tests de fumée permettent de déterminer si une nouvelle version est suffisamment stable pour être testée. Cette page explique quand les exécuter, qui les exécute, comment fonctionne le cycle et comment les suites automatisées contrôlent les pipelines de livraison modernes.
Qu'est-ce que le test de fumée ?
Test de fumée est un processus de test logiciel qui détermine si la version logicielle déployée est stable ou non. Les tests de fumée sont une confirmation pour l'équipe d'assurance qualité de procéder à d'autres tests logiciels. Il consiste en un ensemble minimal de tests exécutés sur chaque version pour tester les fonctionnalités du logiciel. Les tests de fumée sont également appelés « tests de vérification de construction » ou « tests de confiance ».
En termes simples, les tests de fumée consistent à vérifier que les fonctionnalités importantes fonctionnent correctement et qu'aucun problème majeur ne bloque la version testée. Il s'agit d'un test de régression rapide et minimal des fonctionnalités principales. Cela permet de déterminer si la version présente des défauts susceptibles de rendre tout test ultérieur inutile et coûteux en temps et en ressources.
Comparer Tests de fumée et de santé mentale
Pourquoi effectuons-nous des tests de fumée ?
Les tests de fumée jouent un rôle important dans le développement logiciel car ils garantissent le bon fonctionnement du système dès les premières étapes. Ils permettent ainsi de réduire les efforts de test. Ce n'est qu'une fois les tests de fumée terminés que l'on peut commencer les tests fonctionnels.
- Tous les points critiques de la construction seront identifiés grâce à des tests de fumée.
- Grâce aux tests de fumée, la plupart des défauts sont identifiés aux premiers stades de leur apparition. développement de logiciels.
- Avec les tests de fumée, nous simplifions la détection et la correction des défauts majeurs.
- Grâce à des tests de fumée, l'équipe d'assurance qualité peut détecter des défauts dans la fonctionnalité de l'application qui peuvent avoir été révélés par le nouveau code.
- Les tests de fumée détectent les défauts de gravité majeurs.
Exemple 1: Fenêtre de journalisation : possibilité de passer à la fenêtre suivante avec un nom d'utilisateur et un mot de passe valides en cliquant sur le bouton Soumettre.
Exemple 2: L'utilisateur ne parvient pas à se déconnecter de la page Web.
Quand effectuons-nous les tests de fumée ?
Ces avantages ne se concrétisent que si le contrôle est déclenché au bon moment. Les tests de fumée sont effectués lors du développement et de l'intégration de nouvelles fonctionnalités logicielles à une version existante déployée en environnement de test/préproduction. Ils permettent de vérifier le bon fonctionnement de toutes les fonctionnalités critiques. Le schéma ci-dessous illustre le parcours d'une version jusqu'à l'environnement de test avant le début des tests de fumée.
Dans cette méthode de test, l'équipe de développement déploie la version en environnement de test. Un sous-ensemble de cas de test est sélectionné et exécuté par les testeurs sur les fonctionnalités critiques de la version. Ces cas de test sont conçus pour révéler les erreurs présentes dans la version. Si ces tests sont concluants, l'équipe d'assurance qualité poursuit le processus. Essais fonctionnels.
Tout échec indique la nécessité de renvoyer le système à l'équipe de développement. Chaque fois qu'il y a un changement dans la construction, nous effectuons des tests de fumée pour garantir la stabilité.
Exemple: -Un nouveau bouton d'inscription est ajouté dans la fenêtre de connexion et la build est déployée avec le nouveau code. Nous effectuons des tests de fumée sur une nouvelle construction.
Les tests de fumée valident la version en vue de tests formels plus approfondis et visent à démontrer la stabilité du système et sa conformité aux exigences. Leur principal objectif est de détecter rapidement les problèmes majeurs. Une version inclut tous les fichiers de données, bibliothèques, modules réutilisables et composants techniques nécessaires à la mise en œuvre d'une ou plusieurs fonctions du produit.
Que se passe-t-il si nous n'effectuons pas de test de fumée ?
Si nous n'effectuons pas de tests de fumée dès les premières étapes, des défauts risquent d'être constatés ultérieurement, ce qui peut s'avérer coûteux. Défaut Découvert à des stades ultérieurs, un problème peut constituer un obstacle majeur et affecter la livraison des produits.
Qui effectuera les tests de fumée ?
Après avoir publié la version dans l'environnement QA, les tests de fumée sont effectués par les ingénieurs QA/responsable QA. Chaque fois qu'il y a une nouvelle version, l'équipe d'assurance qualité détermine les principales fonctionnalités de l'application pour effectuer des tests de fumée. L'équipe d'assurance qualité vérifie les obstacles dans l'application en cours de test.
Comment réaliser un test de fumée ?
Les tests de fumée sont généralement effectués manuellement, bien qu'il soit possible de réaliser la même chose grâce à l'automatisation. Cela peut varier d’une organisation à l’autre.
Test de fumée manuel
Des tests de fumée sont effectués pour vérifier que la navigation dans les chemins critiques se déroule comme prévu et n'entrave pas le bon fonctionnement du système. Les cas de tests fonctionnels prioritaires sont sélectionnés et exécutés afin de détecter les défauts critiques. Si le test est concluant, les tests fonctionnels se poursuivent. En cas d'échec, la version est rejetée et renvoyée à l'équipe de développement pour correction.
L'équipe d'assurance qualité (AQ) a repris les tests de non-régression avec une nouvelle version. Ces tests sont effectués sur la nouvelle version et seront intégrés aux versions précédentes afin de garantir le bon fonctionnement du système. Avant de procéder aux tests de non-régression, l'équipe AQ doit vérifier que les versions utilisées sont correctes.
Tests de fumée automatisés
Tests d'automatisation est utilisé pour Les tests de régressionCependant, nous pouvons également utiliser un ensemble de tests automatisés pour effectuer des tests de fumée. Grâce à ces tests automatisés, les développeurs peuvent vérifier immédiatement la compilation, dès qu'une nouvelle version est prête pour le déploiement.
Au lieu de procéder à des tests répétés manuellement chaque fois que la nouvelle version du logiciel est déployée, des cas de tests de fumée enregistrés sont exécutés sur la version. Il vérifie si les principales fonctionnalités fonctionnent toujours correctement. Si le test échoue, ils peuvent alors corriger la version et la redéployer immédiatement. Ainsi, nous pouvons gagner du temps et garantir une construction de qualité de l’environnement d’assurance qualité.
À l'aide d'un outil automatisé, l'ingénieur de test enregistre toutes les étapes manuelles effectuées dans la version logicielle.
Cycle de test de fumée
Le diagramme ci-dessous illustre le déroulement des tests de fumée. Une fois la version déployée en assurance qualité et les tests de fumée validés, nous procédons aux tests fonctionnels. En cas d'échec d'un test de fumée, les tests sont interrompus jusqu'à la résolution du problème dans la version.
Meilleures pratiques pour la conception de cas de tests de fumée
Connaître le cycle est une chose ; garderping La suite logicielle qui assure sa fiabilité est une autre affaire. Une suite logicielle de gestion des fumées n'est efficace que si elle reste compacte, rapide et reproductible.
- Commencez par cartographier les chemins critiques : Décrivez les flux de travail qui rendent le produit commercialement exploitable, tels que la connexion, la recherche, la saisie de données, le paiement et la déconnexion. Si l'un d'eux est défaillant, la version testée est inutilisable.
- Veillez à ce que la suite soit peu profonde mais large : Il est préférable de parcourir chaque module principal une seule fois plutôt que d'explorer un seul module en profondeur. Les valeurs limites, les données négatives et la formulation des messages d'erreur relèvent des tests fonctionnels, et non d'ici.
- Limiter le temps d'exécution : La plupart des équipes limitent la durée de la course à une vingtaine ou une trentaine de personnes et la durée de la suite à environ vingt ou trente minutes. cas de testUne course qui prend une heure cesse d'être une porte et devient un goulot d'étranglement.
- Exécutez les mêmes tests sur chaque build : La cohérence permet d'attribuer un échec au code plutôt qu'à une modification de la sélection des tests.
- Supprimer les cas instables et comportant de nombreuses dépendances : Un cas qui réussit et échoue sans aucune modification du code détruit la confiance dans le système. Il faut simuler ou remplacer les services tiers instables là où… cadre d'automatisation des tests permet.
- Consignez un verdict sans équivoque : Chaque cas nécessite un résultat attendu unique afin que la configuration puisse être acceptée ou rejetée sans discussion.
- Versionnez la suite avec la build : Stockez les cas de test dans le même dépôt que le code de l'application afin que la validation corresponde toujours à la version testée.
RevRevoir la suite à chaque version : supprimer les cas concernant les fonctionnalités qui ne sont plus importantes et ajouter de nouveaux flux de travail critiques.
Tests de fumée dans les pipelines CI/CD
Une suite conçue de cette manière est suffisamment peu coûteuse pour être exécutée à chaque commit, ce qu'exige la livraison moderne. intégration continue serveur tel que Jenkins Le processus compile le code, le déploie dans un environnement de préproduction, puis déclenche la suite de tests de fumée comme première étape automatisée. En cas de succès, l'artefact passe aux phases de tests fonctionnels et de régression, tandis qu'en cas d'échec, le pipeline échoue et le développeur responsable est notifié en quelques minutes.
Deux exécutions sont courantes. Une exécution avant fusion protège la branche principale en validant chaque demande de fusion, et une exécution après déploiement confirme que l'environnement déployé est accessible et correctement configuré. Les équipes pratiquant le déploiement continu ajoutent souvent une troisième exécution, allégée, sur la production immédiatement après la mise en production.
Étant donné que le pipeline exécute la suite de tests plusieurs fois par jour, les cas doivent être non interactifs, autonettoyants et indépendants. Tout cas nécessitant une décision humaine ou laissant des données de test en attente bloquera le pipeline.
Avantages des tests de fumée
Voici quelques avantages répertoriés pour les tests de fumée.
- Facile à utiliser et rapide.
- Les erreurs et défauts critiques sont faciles à détecter et à corriger dès les premiers stades.
- Améliore la qualité du système
- Réduit le risque
- Les progrès sont plus faciles à évaluer.
- Gain de temps et d'efforts de test
- Minimise les risques d’intégration
⚠ Limitation à noter : Un test de fumée réussi indique seulement que la version est testable. Il n'évalue que superficiellement les fonctionnalités principales, laissant ainsi les défauts mineurs, les cas limites et les fonctionnalités rarement utilisées masqués jusqu'à l'exécution des tests fonctionnels et de régression. Un résultat de fumée vert ne doit jamais être considéré comme un signe d'absence de défauts dans la version.
Tests de fumée vs tests de cohérence vs tests de régression
Ces trois fonctions s'exécutent après une modification du code, ce qui explique la confusion fréquente entre elles. Elles diffèrent par leur portée, leur profondeur et la question à laquelle chacune répond.
Les tests effectués dans un environnement de développement sur le code afin de garantir le bon fonctionnement de l'application avant sa mise en production sont appelés tests de validation. Il s'agit d'un processus qui vérifie que l'application en cours de développement répond à ses exigences fonctionnelles de base.
Les tests d'intégrité déterminent l'achèvement de la phase de développement et prennent la décision de réussir ou non le produit logiciel pour une phase de tests plus approfondie.
| BASE | TESTS DE FUMÉE | TESTS DE BON SENS | TEST DE RÉGRESSION |
|---|---|---|---|
| Domaine | Large et peu profond | Étroit et profond | Large et profond |
| Réponse à la question | Cette version est-elle suffisamment stable pour être testée ? | Cette solution spécifique fonctionne-t-elle ? | Est-ce que quelque chose qui fonctionnait auparavant est devenu défectueux ? |
| Séquence | Tout d'abord, sur chaque construction | Après réussite du test de fumée | Après les tests de cohérence |
| Durée typique | 10 à quelques minutes 15 | 30 à quelques minutes 60 | Hours à jours |
| Automatisation adaptée | Très élevé | Modéré, souvent manuel | Très élevé |
En pratique, ils s'exécutent en séquence : tests de fumée pour accepter la version, tests de cohérence pour vérifier la modification apportée et tests de régression lorsque le planning le permet.
Exemples de cas de test de fumée
Le tableau ci-dessous présente un bref aperçu des résultats, une ligne par chemin critique.
| T.ID | SCÉNARIOS DE TEST | DESCRIPTION | ÉTAPE DE TEST | RÉSULTAT ATTENDU | RÉSULTAT ACTUEL | STATUT |
|---|---|---|---|---|---|---|
| 1 | Identifiants de connexion valides | Testez la fonctionnalité de connexion de l'application Web pour vous assurer qu'un utilisateur enregistré est autorisé à se connecter avec son nom d'utilisateur et son mot de passe. | 1.Lancez l'application 2.Naviguez sur la page de connexion 3.Entrez un nom d'utilisateur valide 4.Entrez un mot de passe valide 5.Cliquez sur le bouton de connexion |
La connexion devrait être un succès | comme prévu | Passé |
| 2 | Ajout de fonctionnalités d'élément | Possibilité d'ajouter un article au panier | 1.Sélectionnez la liste des catégories 2.Ajoutez l'article au panier |
L'article devrait être ajouté au panier | L'article n'est pas ajouté au panier | Échoué |
| 3 | Fonctionnalité de déconnexion | Vérifier la fonctionnalité de déconnexion | 1. sélectionnez le bouton de déconnexion | L'utilisateur doit pouvoir se déconnecter. | L'utilisateur ne peut pas se déconnecter | Échoué |



