> Station d'outils n°9
返回列表
Sac paresseux / GUIDE 2026-03-07

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é.

Assurance qualité CI/CD Actions GitHub stratégie de test Niveau de qualité DevOps
· 最後更新 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

分享 LINE Threads X
ℹ️

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.

Retour