Stratégie de tests en CI/CD : garantir la qualité de chaque déploiement
Partagez comment planifier des stratégies de test dans le pipeline CI/CD, quels tests doivent être exécutés à chaque étape, de la validation au déploiement, et comment définir les niveaux de qualité.
最後更新：2026-03-07
Cet article utilise les actions GitHub comme exemple. Les paramètres des autres outils CI/CD peuvent être différents.
目錄
1. Pourquoi CI/CD a-t-il besoin d'un contrôle qualité ?
Il n'y a pas de CI/CD pour les tests automatisés, il suffit de « déployer rapidement les bogues en production ». Le niveau de qualité est l’âme du CI/CD.
2. Étape 1 : étape de validation (déclenchée à chaque poussée)
Objectif de temps d’exécution : < 5 minutes
-
analyse statique
ESLint, Pylint, SonarQube
-
Tests unitaires
Rapide, indépendant, pas de dépendances externes
-
couverture du code
Fixer un seuil minimum (par exemple 80 %)
3. Étape 2 : étape de test d'intégration
Objectif de temps d’exécution : < 15 minutes
-
Tests d'API
Vérifier les interactions entre les services
-
Test de base de données
Migration, intégrité des données
-
Simulation de service tiers
Ne dépend pas de services externes
4. Étape 3 : étape de test E2E
Objectif de temps d’exécution : < 30 minutes
-
Tests de processus de base
Chemins clés tels que la connexion, l'achat, le paiement, etc.
-
Tests multi-navigateurs
Chrome, Firefox, Safari
-
Tests de régression visuelle
Percy, Chromatique
5. Étape 4 : Niveau de pré-déploiement
La dernière ligne de défense de la qualité :
-
Tests de performances
Garantir aucune dégradation des performances
-
analyse de sécurité
OWASPZAP、Snyk
-
Révision manuelle
Approbation manuelle si nécessaire
6. Paramètres du portail de qualité
Quand le déploiement doit-il être bloqué : échecs des tests unitaires (tolérance zéro), couverture inférieure au seuil, vulnérabilités de sécurité de haute gravité, dégradation des mesures de performances supérieure à 10 %, échecs des tests E2E de base.
7. Pièges courants des tests CI/CD
Évitez ces problèmes courants :
-
Test trop lent
Déplacer les tests lents vers des builds nocturnes non bloquants
-
Test feuilleté
Les tests instables doivent être réparés ou isolés immédiatement, sinon l'équipe s'habituera à ignorer les feux rouges.
-
environnement incohérent
Utiliser Docker pour garantir la cohérence de l'environnement CI avec la production
-
Teste seulement le chemin heureux
Les tests négatifs sont tout aussi importants que les cas extrêmes
相關懶人包
API 測試入門：用 Postman 和 pytest 打造你的第一個 API 測試
API 測試是現代 QA 必備技能。從 HTTP 基礎概念到實際用 Postman 和 pytest 寫測試，帶你踏出 API 測試的第一步。
Comment rédiger un cas de test de manière professionnelle ? Démontage complet des exigences aux cas de test
De bons cas de test sont l’arme principale du contrôle qualité. Partagez une approche systématique allant de l'analyse des exigences à la rédaction de cas de test, y compris des techniques pratiques telles que la segmentation équivalente et l'analyse des valeurs limites.
L'art du rapport de bogues : comment rédiger des rapports de bogues que les développeurs peuvent comprendre en quelques secondes
Un bon rapport de bug peut considérablement accélérer le processus de réparation. Partagez les meilleures pratiques en matière de signalement de bogues, notamment les modèles, les évaluations de gravité et la manière de communiquer efficacement avec les développeurs.
Déclaration générale
Les informations fournies sur ce site sont fournies à titre indicatif uniquement et leur exhaustivité et leur exactitude ne sont pas garanties. Les utilisateurs doivent porter leur propre jugement sur l'applicabilité des informations.