Création de robots (RPA) avec les outils AutoTest

Auteurs: Lebedev A., Nazarova E. Le

besoin d'utiliser la robotique se pose pour diverses raisons: le besoin de nouvelles applications pour échanger des données avec des applications qui n'ont pas d'API, l'intégration rapide d'applications hétérogènes, l'automatisation des processus de routine avec un minimum de coûts, etc.

Traditionnellement, les robots ou RPA (Robotic Process Automation) sont construits sur la base de frameworks prêts à l'emploi. Ici, les leaders sont, à notre avis, des produits d'UiPath, Automation Anywhere, Blue Prism, NICE. Ce sont des plateformes éprouvées qui vous permettent de prendre des décisions de qualité. Cependant, pas bon marché. Vous devez payer pour les licences dans le nombre de travaux futurs, payer pour la personnalisation de votre tâche spécifique et la mise en service. Dans certains cas, vous pouvez obtenir moins cher. Nous avons réussi et sommes prêts à partager notre expérience.

Il y a quelque temps, dans l'une des banques, la transformation Agile a commencé. Nouvelles approches pour développer des applications pour les besoins de la banque. Pour montrer la voie aux autres, ils ont formé des équipes pilotes pour développer de nouveaux produits.

La banque dispose de systèmes clés traditionnels pour mener les activités comptables et opérationnelles. Le travail avec les produits des nouvelles équipes a été mis en œuvre sous forme de microservices, qui devraient échanger des données avec des systèmes clés. Et le développement en équipe a commencé assez rapidement. Mais le problème est que les approches traditionnelles de la politique de publication des systèmes clés ne cadraient pas avec ce rythme. Et l'API pour les nouveaux microservices était dans le plan pour l'avenir.

Il se trouve, comme Pechkin, "Je vous ai apporté un paquet, mais je ne vous le donnerai pas." Dans ces conditions, des représentants des équipes pilotes se sont adressés à notre équipe d'autotests avec l'idée d'utiliser des autotests d'interface utilisateur de processus similaires pour créer des robots.

Naturellement, nous avons d'abord discuté des risques. Le fait que, lors de l'utilisation d'outils d'autotest, ce soit le cas, que la fiabilité des solutions logicielles pour les exigences de test soit inférieure à celle des applications de système de paiement, cela a été annoncé immédiatement. Mais portées par la vague Agile, les équipes ont pris des risques.

La boîte à outils a été utilisée de façon traditionnelle et gratuite: Java pour le développement, assemblage via Maven. Pour travailler avec le navigateur, Selenium a été utilisé (l'application où il était nécessaire de saisir des données a une interface Web).

Les principales caractéristiques distinctives du robot par rapport à l'autotest de l'interface utilisateur du même processus sont la nécessité de gérer correctement les situations d'erreur et les exceptions, l'intégration en tant que sous-système via l'échange de fichiers.

Pour que le robot fonctionne, un serveur virtuel a été alloué, un compte de domaine technique et un utilisateur distinct a été créé dans le système où les données ont été saisies. Avec autorité, comme un employé vivant qui effectue des actions similaires.

Un agent Jenkins a été installé sur ce serveur, ce qui vous permet d'exécuter le robot. Le rapport sur le travail du robot a été formé à la fois sous la forme d'un journal d'exécution et sous la forme d'un rapport Allure. Les deux sont disponibles dans Jenkins et ne nécessitent pas d'autorisation spéciale pour accéder aux ressources réseau.

Le travail du robot a été structuré comme suit: un fichier avec des données pour entrer dans le système est placé dans le dossier d'entrée sur une ressource réseau et le robot est lancé via Jenkins; il compare les enregistrements du fichier d'entrée par le champ clé avec le fichier de service, où tous les enregistrements déjà traités sont stockés, et sélectionne uniquement ceux qui n'ont pas encore été traités. Ensuite, le tableau d'enregistrements est traité en boucle. De plus, à chaque étape de traitement de chaque enregistrement, les exceptions et les erreurs sont traitées (essayez ... rattraper) et les «abandons» de processus sont notés dans le fichier résultant. En même temps, le traitement du tableau d'entrée ne s'arrête pas, nous passons simplement à l'enregistrement suivant. Par conséquent, lorsque le traitement de l'ensemble du tableau est terminé, le fichier d'entrée est supprimé, dans la sortie, il y a tous les enregistrements traités avec le résultat et l'exécution. Allure Report s'affiche sous forme d'informations sur le traitement de chaque enregistrement,et une liste générale avec les résultats de traitement de chaque enregistrement. Cela facilite l'évaluation du résultat et la localisation des problèmes, le cas échéant.



De plus, dans le processus d'utilisation du robot, il s'est avéré que le flux d'applications les jours de pointe est assez important et afin de respecter le temps de traitement acceptable, un plus grand nombre d'utilisateurs simultanés est requis.

Le système a créé plusieurs autres utilisateurs. L'exécution parallèle a été implémentée à l'aide de threads (Thread). L'ensemble des enregistrements d'entrée est réparti également entre les flux, dans chacun desquels le traitement est effectué sous son propre utilisateur. Les résultats sont consignés dans un seul fichier et le rapport est également unique. C'est confortable. Dans le même temps, un seul serveur Selenium a été lancé, ce qui permet de faire face au lancement parallèle de plusieurs navigateurs (selon le nombre d'utilisateurs actifs). Nous avons travaillé avec le navigateur Chrome, respectivement, chromedriver a été utilisé.

Cela est surprenant, mais pendant les neuf mois de fonctionnement, les problèmes n'étaient dus qu'à des données d'entrée incorrectes. Des problèmes techniques ne sont survenus qu'au stade de la mise en service et ont été associés à la coordination des encodages dans le journal et à l'extension de la mémoire utilisée lors du démarrage de Selenium Server (livré 1G).

Après un certain temps, pour la même équipe Agile, un autre robot a été développé. Sa caractéristique est qu'il ne démarre pas à la demande, mais fonctionne en continu en analysant le dossier d'entrée. Lorsqu'un fichier entrant apparaît, il le prend en traitement. Par conséquent, l'agent Jenkins n'est pas utilisé. Si le processus réussit, le fichier d'entrée est déplacé vers le dossier contenant les fichiers traités avec succès, sinon, vers le dossier contenant les fichiers erronés. Contrairement au robot précédent, Allure Report est absent, mais les journaux d'exécution sont écrits dans un fichier séparé pour analyse en cas de problème. Et une autre fonctionnalité - le navigateur est fermé de force à la fin du traitement et démarre lorsque l'utilisateur doit se connecter.

Ainsi, dans certains cas, lors de la création d'un RPA, vous pouvez vous en tirer de manière nettement moins chère en utilisant les outils d'autotest.