Modèles CI / CD et anti-modèles. 2e partie

Bon après-midi Aujourd'hui, nous partageons avec vous la traduction de la deuxième partie de l'article «Modèles et anti-modèles CI / CD» , dédiée au lancement d'un nouveau flux sur le cours «DevOps Practices and Tools» . La première partie de cet article peut être lue ici .

1.3 Modèles et antipatterns dans les tests

1.3.1 Automatisation des tests

• Modèle: automatisez la validation et la validation des logiciels en incluant les unités de test, les composants, la capacité, la fonctionnalité et le déploiement.
• Anti-patterns: test manuel des unités, composants, déploiement, etc.
• Unité - Automatisation des tests sans dépendances.
• Composant - Automatisation des tests avec des dépendances sur d'autres composants, bases de données et systèmes de fichiers.
• Déploiement - Automatisez les tests pour vérifier le déploiement et la configuration réussis. Ceci est parfois appelé test de «fumée».
• Fonctionnel - Automatisation des tests pour vérifier le comportement du logiciel du point de vue de l'utilisateur.
• Capacité - Automatisation des tests de charge et de performance dans des conditions proches de l'exploitation.

1.3.2 Isolement des données de test

• Modèle: utilisez les transactions pour les tests dépendants de la base de données (par exemple, test des composants) et annulez les transactions une fois terminées. Utilisez un petit sous-ensemble de données pour tester efficacement le comportement.
• Anti-patterns: utilisation d'une copie des données de production pour les tests de validation. Exécution de tests sur une base de données commune.

1.3.3 Tests parallèles

• Modèle: en parallèle, exécutez plusieurs tests sur des instances matérielles pour réduire le temps passé.
• Anti-patterns: exécution de tests sur une seule machine ou instance. Exécution de tests dépendants qui ne peuvent pas être exécutés en parallèle.

1.3.4 Stabilité du système

• Modèle: utilisez des stubs pour simuler des systèmes externes afin de réduire la complexité du déploiement.
• Anti-patterns: installation et configuration manuelles de systèmes interdépendants pour la construction et le déploiement de Commit Stage.

1.3.5 Tests de bout en bout considérés comme nuisibles

La livraison continue est un ensemble de principes et de pratiques holistiques visant à réduire les délais de commercialisation. Il est basé sur un retour rapide et fiable grâce à des tests. La livraison continue nécessite toute modification du code, de la configuration, des données ou de l'infrastructure pour subir un ensemble de tests automatisés et exploratoires dans le pipeline de déploiement afin d'évaluer la préparation opérationnelle. Par conséquent, si l'organisation souhaite atteindre des délais plus courts, le temps d'exécution du test doit être faible et les résultats du test sans équivoque.

Par exemple, considérons le service Payments Company, dans lequel les paiements à la fin de l'année sont envoyés au service Payments suivant.

Le comportement du service de paiement de l'entreprise peut être vérifié pendant le temps d'assemblage en effectuant les types de tests automatiques suivants:

• Tests unitaires: comparer l'objectif et l'implémentation lors de la vérification des modules de code individuels.
• Tests d'acceptation: comparaison de l'implémentation et des exigences lors de la vérification de la partie fonctionnelle du système.
• Tests de bout en bout: comparaison de l'implémentation et des exigences lors de la vérification de la partie fonctionnelle du système, y compris les services dépendants sans propriétaire.

Alors que les tests unitaires et d'acceptation diffèrent par leur objectif et leur portée, les tests d'acceptation et de bout en bout ne diffèrent qu'en volume. Les tests d'acceptation n'incluent pas les services dépendants sans propriétaire.Par conséquent, le test d'acceptation du voyage de l'utilisateur des paiements de l'entreprise utilisera le système de test , qui se compose du code de la dernière version des paiements de l'entreprise et du paiement Stab .

Les tests de bout en bout incluent les services dépendants sans propriétaire, par conséquent, le test de voyage de bout en bout de l'utilisateur des paiements de l'entreprise utilisera le système de test comprenant le code le plus récent des paiements de l'entreprise et la version de travail des paiements.

Si la stratégie de test est compatible avec la livraison continue, elle doit avoir un ratio approprié d'unité, d'acceptation et de tests de bout en bout qui équilibre le besoin d'informations et un retour rapide et sans ambiguïté. Si les tests n'apportent pas de nouvelles informations, les défauts passent inaperçus. Mais si les tests prennent trop de temps, la livraison sera lente et les pertes de revenus augmenteront.

La fin de la deuxième partie.

Selon la tradition établie, nous attendons vos commentaires et nous vous invitons à une journée portes ouvertes . La troisième partie de l'article est déjà disponible ici .