comment tester les tests d'automatisation des microservices

Lorsque les tests automatisés de vos microservices commencent à « abandonner la chaîne »

Imaginez ceci : la nouvelle fonction que vous venez de lancer a fonctionné sans problème, mais quelques jours plus tard, le traitement des commandes a soudainement ralenti d'un demi-temps. Au bout d'un moment, l'interface de paiement a signalé une erreur inexplicable. Après avoir vérifié encore et encore, nous avons constaté qu'il n'y avait pas de problème avec le code lui-même, mais qu'il y avait un problème avec la collaboration entre les différents microservices : un service a été mis à jour et l'autre n'a pas réussi à suivre ; une interface changeait ses paramètres et le module qui l'appelait utilisait toujours les anciennes règles. À ce stade, vous pensez peut-être à quel point vous vous inquiéteriez moins si vous pouviez détecter le problème avant qu’il ne survienne.

C’est à cela que servent les tests automatisés de microservices. Il ne s’agit pas seulement d’écrire quelques scripts et de les exécuter, mais comme si vous connaissiez votre propre cuisine, vous devez savoir quel rôle joue chaque service dans l’ensemble du système et comment communiquer entre eux. Plus important encore, le test doit "évoluer" avec le service - chaque fois qu'il y a une mise à jour, le test peut automatiquement vérifier la réaction en chaîne, n'attendez pas que l'utilisateur le rencontre et panique ensuite.

Alors, qu’est-ce que la « mesure en place » ?

Certaines personnes pensent qu'exécuter l'interface plusieurs fois pour vérifier la valeur de retour est considéré comme un test. En fait, il s’agit plutôt de confirmer que le service est toujours « vivant ». Les véritables tests automatisés doivent aller plus loin : par exemple, simuler la chaîne complète d'une commande, de la génération à l'achèvement, pour voir si chaque service perdra des informations ou changera de format lors de la transmission des données ; ou ajoutez délibérément un peu de retard à un service pour observer si d'autres services attendent patiemment ou expirent directement et tombent en panne. Ce type de test s’apparente à un examen physique régulier de l’ensemble du système, qui ne se limite pas à examiner les organes individuels, mais vérifie également leur fonctionnement ensemble.

kpuissanceLorsque nous aidons les clients à trier de tels tests, nous rencontrons souvent deux pièges dans lesquels il est facile de tomber : Premièrement, les scripts de test sont trop « durs » et les scripts devront être considérablement modifiés une fois le service mis à niveau ; Deuxièmement, la couverture des tests est incomplète et il y a toujours des scènes de coin qui ne sont pas prises en compte, et ce sont les endroits où les problèmes sont les plus susceptibles de survenir. Plus tard, ils ont ajusté leur réflexion : diviser les cas de test pour être plus flexibles, comme assembler des Lego, changer un peu le service, changer simplement les modules correspondants ; dans le même temps, simuler délibérément des situations « étranges » qui ne se produisent pas souvent, telles que des interruptions de réseau ou une simultanéité élevée instantanée, peut révéler à l'avance des vulnérabilités cachées.

Quelle est la différence entre « peut fonctionner » et « fonctionner régulièrement » ?

Par exemple, si vous assemblez un bras robotique avec un mécanisme de direction et un servomoteur, quelle que soit la précision de rotation des moteurs individuels, si le timing n'est pas réglé correctement, le mouvement global trébuchera toujours. Il en va de même pour les microservices. Si les tests automatisés se concentrent uniquement sur un seul service, cela revient à calibrer un seul moteur et à ignorer la coordination globale. Un bon cadre de test permettra aux services de « se vérifier mutuellement », par exemple en simulant automatiquement le trafic réel circulant régulièrement à travers tous les services et en enregistrant les endroits où la réponse est lente et ceux où les données ne correspondent pas. L'accumulation de ces données permet non seulement de localiser rapidement les problèmes, mais également de vous rappeler : quels services peuvent être nécessaires et quelles interfaces sont trop étroitement dépendantes.

Un jour, lors d'un chat, on m'a demandé : « Nous n'avons pas beaucoup de services, avons-nous besoin de tests aussi détaillés ? En fait, le nombre de services n'est pas la clé, ce qui est important c'est leur « adhérence ». Même s'il n'y a que trois ou quatre services, si les appels entre eux sont complexes et s'il existe de nombreuses liaisons de transfert de données, il sera difficile de les couvrir tous par des tests manuels. Les tests automatisés s’apparentent davantage à la mise en place d’un réseau de surveillance intelligent, qui reste généralement discret en arrière-plan. Dès qu'il y a une mise à jour ou une anomalie du service, il peut immédiatement donner un retour d'information et vous indiquer si le changement est sain ou "un peu froid".

Laissez le test « grandir » tout seul

L'écriture manuelle de cas de test prend du temps et la post-maintenance est également fatigante.kpuissancePlus tard, j'ai essayé de générer automatiquement certains cas de test - sur la base des journaux d'appels d'interface réels et des modèles de trafic, le système recommandera des scénarios de test courants et construira même automatiquement des cas d'utilisation de pointe. Il ne s’agit pas de remplacer complètement la conception manuelle, mais de libérer les ingénieurs du travail répétitif pour se concentrer sur une logique de test qui demande plus de créativité. Par exemple, comment simuler une augmentation des commandes pendant les vacances et comment tester les performances de compatibilité de nouveaux services après leur connexion, ceux-ci doivent encore être conçus en fonction de l'expérience.

Le rapport de test est également rendu aussi clair que possible. Il ne s'agit plus d'une pile de chiffres et de journaux, mais plutôt d'une histoire : cette fois, le service utilisateur a été modifié, ce qui a également affecté les commandes et les paiements, l'évolution du temps de réponse global des liens et les liens auxquels il convient de prêter attention. Les personnes qui lisent le rapport peuvent rapidement en saisir les points clés au lieu de se perdre dans les détails.

Il n’y a rien de mystérieux dans les tests automatisés des microservices. C'est essentiellement une habitude permanente. Tout comme vous vérifiez chaque jour si les portes et les fenêtres sont fermées lorsque vous rentrez chez vous, il doit également y avoir un mécanisme « d'inspection » régulier du système en fonctionnement. Plus ce mécanisme est automatique et plus il correspond aux données réelles qui circulent, plus vous serez en sécurité lorsque vous dormirez la nuit - après tout, qui sait où se trouvera le prochain utilisateur et de quelle manière inattendue, déclenchant une série d'interactions de service auxquelles vous n'avez jamais pensé ?

Pour commencer, vous pouvez commencer petit : choisir d'abord un lien métier principal, lister clairement les services qui transitent, les interfaces appelées et les données attendues, puis simuler différentes intrigues possibles sur ce lien comme un metteur en scène répétant une pièce de théâtre. Une fois que tout se passe bien, élargissez progressivement la portée. Au fil du temps, vous constaterez que les tests automatisés ne servent pas seulement à détecter des bogues, ils vous aident également à mieux comprendre votre système : comment fonctionne chaque service, comment il communique entre eux, quels domaines sont solides et quels domaines doivent être renforcés. Cette compréhension elle-même est la meilleure garantie.

Créé en 2005,kpuissancea été dédié à un fabricant professionnel d'unités de mouvement compactes, dont le siège est à Dongguan, dans la province du Guangdong, en Chine. Tirant parti des innovations en matière de technologie d'entraînement modulaire, Kpower intègre des moteurs hautes performances, des réducteurs de précision et des systèmes de contrôle multiprotocoles pour fournir des solutions de systèmes d'entraînement intelligents efficaces et personnalisées. Kpower a fourni des solutions de systèmes d'entraînement professionnelles à plus de 500 entreprises clientes dans le monde avec des produits couvrant divers domaines tels que les systèmes de maison intelligente, l'électronique automatique, la robotique, l'agriculture de précision, les drones et l'automatisation industrielle.