Il est difficile de surestimer l'importance des tests, en particulier lorsqu'il s'agit d'une plate-forme d'intégration pour l'interaction des systèmes de convoyeurs de crédit. Dans cet article, nous voulons parler de la façon dont notre équipe a d'abord conçu un tel bus, puis lancé des tests automatiques pour celui-ci.
Qu'est-ce qu'une plateforme d'intégration et pourquoi est-elle nécessaire?
Dans les grands systèmes d'entreprise, il existe souvent des problèmes d'interaction entre les sous-systèmes internes. En raison de connexions et de demandes sans fin, un tel enchevêtrement au fil du temps devient de plus en plus confus et compliqué. Il devient difficile de se
détendre pour le maintenir et le gérer.
Chaque sous-système a son propre cycle de publication: certains sont mis à jour une fois par an, et certains - une fois par semaine. Ces changements doivent également être pris en compte et intégrés dans le canevas global du système. Pour ce faire, vous avez besoin d'un intermédiaire qui échange des données entre tous les sous-systèmes de l'entreprise. Cet intermédiaire est la plateforme d'intégration.
A la recherche d'un artiste pour son développement, le client a préparé une tâche de test qui devait être implémentée et protégée. C'était une description de tâche assez simple avec plusieurs systèmes sélectionnés: base de données, service, répertoires de fichiers, etc. En une semaine, il a fallu créer et démontrer une solution tolérante aux pannes, ainsi que décrire la plateforme de développement. Dans la mise en œuvre de tels projets, nous avons acquis une expérience décente, et selon les résultats de la défense, nous avons été choisis comme exécuteurs testamentaires.
À cette époque, le client utilisait dans la plupart des cas un schéma d'intégration point à point: chaque système était intégré à un autre. C'était gênant et difficile à entretenir. Nous avons trois tâches:
- remplacer l'intégration existante via une plateforme d'intégration;
- intégrer de nouveaux systèmes bancaires;
- Automatisez l'échange de données entre eux.
Après avoir réussi la tâche de test, nous avons commencé le projet. Son phasage pour eux-mêmes a été déterminé de cette façon:
- effectuer un audit;
- trouver des employés clients qui comprennent l'état cible des processus métier (et pas seulement l'actuel);
- formuler des exigences commerciales pour les systèmes informatiques et fournir une feuille de route pour la transition vers l'état cible des processus métier.
Implémentation
Pour la mise en œuvre, ils ont choisi la plate-forme d'intégration modulaire Red Hat JBoss Fuse.
Architecture de fusible JBossUn peu plus sur les outils de base qui sont prêts à l'emploi:
Apache Camel , construit sur des modèles d'intégration d'entreprise (EIP), fournit le routage des messages, dispose d'un grand nombre d'adaptateurs prêts à l'emploi pour travailler avec des systèmes externes: bases de données, fichiers, courtiers de messages, service d'annuaire, courrier, etc.
Apache ActiveMQ , qui organise l'échange de messages, et assure également leur transmission et leur stockage jusqu'à ce que l'abonné les récupère.
Le processus d'intégration lui-même (flux) est un ensemble d'actions séquentielles. Par exemple: pour recevoir un message du système source via un adaptateur développé / existant, convertir les données du message, ajouter, filtrer, transmettre plus loin aux systèmes récepteurs via leurs adaptateurs.
Processus d'intégrationDans le même temps, vérification des données, leur livraison garantie, traitement des erreurs avec la possibilité de collecter un système de surveillance, informer les exécuteurs responsables des erreurs, etc.
Exemple
Prenez le processus d'émission de prêts dans une banque. Un client de la banque Internet remplit une application, envoie les données du formulaire et attend le résultat. Que se passe-t-il à l'intérieur: via les api restantes fournies à la banque Internet, le bus accepte la demande avec les données principales. De plus, il demande via l'interface soap du système MDM des informations supplémentaires sur le client, combine les informations reçues dans un ensemble commun et les transfère via la file d'attente dédiée ActiveMQ au système RTDM pour formuler une offre dans les produits de prêt existants. Ensuite, le résultat de RTDM est retourné en retour, et le bus retransmet l'offre pour le client à la banque Internet.
Test
Lorsque le bus d'intégration est passé aux testeurs, la question des tests de produits a été initialement décidée manuellement. Cependant, au cours du processus, il a été décidé d'automatiser l'ensemble du processus et de créer une plate-forme de test.
Nous avons écrit des émulateurs pour tous les systèmes bancaires. Les clients ne fournissent pas toujours un accès pour les tests sur les données et les systèmes fonctionnels à la fois, donc les émulateurs ont été développés pour chaque projet séparément. La complexité de ce travail est comparable au développement de la solution d'intégration elle-même. La plateforme de test avait une tâche: collecter, déployer, exécuter le test et envoyer les résultats à TestRail.
Nous avons créé deux ensembles de scripts qui ont été exécutés lors de chaque build (CI / CD). Selon l'engagement, l'assemblée a été initiée et déployée sur le stand. Après la procédure de déploiement, un court script (test de fumée) a été exécuté, ce qui nous a permis de savoir qu'aucune interaction d'intégration n'a été interrompue.
Nous recherchions un scénario étendu pour les assemblées de nuit, ce qui nous a donné une réponse complète à la question: qu'est-ce que le bus et comment interagit-il avec les systèmes externes? Dans le rapport du matin, nous avons vu des tests réussis ou des problèmes qui sont apparus. Cependant, nous n'avons pas automatisé les tests de la plate-forme d'intégration avec des systèmes externes, car il est très difficile de vérifier les résultats de ces tests. Par conséquent, ils ont quitté les tests manuels: les employés du client ont effectué des tests d'acceptation de leurs systèmes, et notre spécialiste a vérifié par journaux si les informations se sont correctement passées.
En conséquence, il a été possible d'obtenir une automatisation des tests à 100% sur les émulateurs. Lors de la mise à jour de l'un des systèmes externes, le bus a pris en charge la maintenance de l'opérabilité du processus métier; en conséquence, des modifications lui ont été apportées directement. Cela vous a permis de tester rapidement toutes les modifications.
Au lieu d'une conclusion
Une fois toutes les étapes franchies, notre équipe a mis en place des processus rapides et transparents avec les entrepreneurs et les clients, et les processus de développement, de test, de mise en œuvre et de support se sont déroulés simplement. En conséquence, 12 processus commerciaux ont été automatisés, qui, par essence, combinaient le travail des principaux systèmes de la banque: ABS, MDM, traitement, RTDM, etc. Dans de tels projets, nous essayons toujours uniquement avec des tests automatisés, pratiquement sans impliquer des testeurs fonctionnels. Cela réduit le coût final du développement et de l'intégration du projet, réduit les délais de commercialisation et nivelle le facteur humain.
Alexander Sadykov, chef adjoint du département des tests, Center for Software Solutions, Jet Infosystems
Pavel Ivanov, chef de l'équipe de développement, Center for Software Solutions, Jet Infosystems