IBM System i (alias AS / 400) - Comment nous avons effectué les tests automatiques des applications sur écran vert

Salut Je m'appelle Anton Vorobyov, je suis responsable chez Alfa Bank du développement d'applications pour un système bancaire centralisé.

Dans cet article, je vais vous expliquer ce que sont les applications d'écran vert, pourquoi elles sont nécessaires et comment nous leur avons fait des autotests en écrivant notre propre solution pour cela, ce qui nous a permis d'accélérer 11 fois les autotests.



La plateforme AS / 400 (Application System / 400) est née en 1988. Le premier OS de cette plate-forme est OS / 400, renommé plus tard en i5 / OS et encore plus tard en IBM i. Il n'y a pas si longtemps, elle a fêté son trentième anniversaire.

En plongeant dans le monde du développement sous le système d'exploitation IBM i, vous comprenez qu'il ne s'agit en fait pas d '«héritage» au sens classique du terme. Il s'agit d'un environnement différent, complètement différent, qui est peu similaire aux systèmes Windows ou Unix habituels. La tâche principale de ce système d'exploitation est d'être aussi productif que possible sur l'équipement avec lequel il fonctionne et de ne pas être pratique pour l'utilisateur.

À mon humble avis, ce système d'exploitation peut vous rendre fou de l'inefficacité des approches habituelles d'écriture de code C ++ (jusqu'à des dizaines de fois la perte de processeur), que certains anti-modèles démontrés dans les manuels sont la meilleure pratique d'un code efficace et la source avec la date d'écriture pour 1978 non seulement assembler sans problème, mais aussi travailler comme prévu! Tout cela nous fait jeter un regard neuf sur les approches modernes du développement logiciel.

Présentation

La question de l'amélioration de la qualité des logiciels en développement excite l'esprit de chaque équipe de développement. Une de nos équipes de crédit, dont la tâche est de développer et développer la partie Back du module du système bancaire automatisé Misys Equation, n'a pas non plus ignoré ce moment. La particularité de cet ABS est que:

• les premières versions de l'ABS fonctionnaient sous le prédécesseur AS / 400 - la plate-forme IBM System / 38 (apparue en 1978) sous le système d'exploitation CPF - «Control Program Facility»;
• Il a été développé depuis les années 70 du XXe siècle, et vous pouvez rencontrer du code écrit avant votre naissance (beaucoup d'ancien code);
• les caractéristiques du travail avec ABS sont dues à une intégration étroite avec IBM i, et en raison de la compatibilité ascendante colossale de ce dernier, il semble que vous travaillez comme archéologue dans les fouilles de la Grande Pyramide.

IBM i (logo)

Le développement d'applications pour cet ABS (options ABS) est effectué conformément à la norme du package technique de l'intégrateur Misys ITP, qui stipule que l'option doit consister en un programme interactif pour l'interaction du terminal avec l'utilisateur final et implémenter l'API en utilisant l'interface installée pour l'exécution en arrière-plan .

Ces programmes interactifs développés sous le système d'exploitation IBM i sont historiquement appelés applications d'écran vert et sont la seule interface utilisateur avec laquelle l'utilisateur de cet ABS interagit.

Qu'est-ce qu'une application écran vert?

La réponse simple est une application qui ressemble à ceci:



Ou alors :

Pourquoi des applications d'écran vert?

Historiquement, les seules applications interactives fonctionnant sur les systèmes bas et milieu de gamme de la famille AS / 400 et d'autres ordinateurs centraux IBM qui vous permettaient de demander une entrée utilisateur sont les applications d'écran vert. L'installation, l'administration, la configuration et le développement sur le système d'exploitation IBM i (et ses prédécesseurs i5 / OS et AS400) ont été effectués (et sont toujours en cours quelque part) exclusivement à l'aide d'applications d'écran vert.

L'image d'application de l'écran vert a deux tailles - 24x80 et 27x132 caractères et 16 couleurs possibles. Dans cette échelle, la plupart du travail des développeurs et des utilisateurs de ce système d'exploitation est effectué.

De telles tailles d'écran sont le résultat de l'évolution des «postes de travail» qui étaient connectés aux progéniteurs AS400 des segments bas de gamme et milieu de gamme des ordinateurs professionnels IBM System / 32, System / 34, System / 36 et System / 38. Ces postes de travail étaient appelés terminaux et constituaient un écran dans un boîtier métallique avec un clavier et un équipement supplémentaire sous la forme d'un stylo lumineux. Initialement, seules deux couleurs d'écran étaient prises en charge - le vert et le vert vif, c'est pourquoi la phrase établie «application d'écran vert» (application d'écran vert dans la littérature anglaise) a disparu. Dans les années 1970, le nombre de couleurs prises en charge est passé à 16.


Station d'affichage 5251 modèle 11

Les options de terminal les plus courantes étaient le 5251 Display Station modèle 1 (960 caractères à l'écran) et le modèle 11 (1920 caractères à l'écran) avec des dimensions Largeur / Profondeur / Hauteur égales à 530/400/400 mm, respectivement, et pesant 34 kg. La résolution d'écran du modèle 1 était de 12x80, modèle 11 - 24x80. Le terminal était connecté directement au système hôte.

Les terminaux 5251 Display Station modèle 2 (960 caractères à l'écran) et modèle 12 (1920 caractères à l'écran) avec de grandes dimensions et un poids de 45 kg étaient également assez courants. Ils se distinguent du modèle 1 et du modèle 11 par la possibilité de transmettre la connexion en amont par eux-mêmes à la machine hôte à partir de clients moins chers sous la forme de terminaux modèle 1 (ou 11) avec des imprimantes de bureau ou une imprimante au sol séparée. Ainsi, les modèles 2 et 12 agissaient comme un concentrateur, procurant la connexion à l'hôte à partir de périphériques nécessitant une connexion directe à la machine hôte, et coûtaient beaucoup plus cher.

Les terminaux de la série 5252 Dual Display Station sembleront également inhabituels au profane moderne.


Image promotionnelle de la brochure IBM System / 38 Equipment and Programs (5252 Dual Display Station)

Le prix d'un kit terminal avec une imprimante connectée pourrait atteindre plusieurs milliers de dollars américains.

Les terminaux ont été connectés via un câble twinax à la machine hôte avec une topologie de bus en mode semi-duplex avec une vitesse de transmission allant jusqu'à 1 Mbps. Le nombre maximum de terminaux pris en charge par twinaxial est jusqu'à 6 terminaux, et le terminal le plus éloigné de l'hôte doit être situé à une distance maximale de 1500 mètres.

Le nombre de chaque terminal est défini lors de l'installation par trois commutateurs, de sorte qu'une adresse unique est déterminée dans le bus. En présence d'un réseau coaxial existant, il est possible d'utiliser des adaptateurs d'un câble twinax à un câble coaxial et un ensemble approprié de terminaisons de câble pour le sertissage. Avec ce schéma, il était possible de connecter seulement deux appareils sur le bus avec une longueur de segment maximale allant jusqu'à 30 mètres. Le nombre total d'appareils connectés variait d'une dizaine à plusieurs dizaines, selon les modèles.

Avec le développement des systèmes de bureau et des réseaux d'accès, les terminaux encombrants ont été remplacés par des postes de travail, où diverses cartes d'extension de sociétés tierces ont été utilisées comme moyen d'accès à la machine hôte, prenant en charge la connexion directe via twinax. Après le développement de la technologie Token Ring par IBM en 1984, des solutions logicielles pour accéder à la machine, y compris via cette interface, sont apparues.


Adaptateur 5250 vers bus ISA (fabricant inconnu)


Cartes d'adaptateur Blackbox 5250 (PC470C, PC471C, PC472C, PC473C, PC478C)

Les émulateurs pour MS-DOS et MS Windows apparaissent à la fois d'IBM et de fabricants tiers, y compris les implémentations OpenSource (par exemple, tn5250j.sourceforge.net). Au milieu des années 90, la pile TCP / IP arrive dans le milieu du monde -machines professionnelles bas de gamme. Pour prendre en charge l'accès à l'hôte via le nouveau protocole, IBM développe des émulateurs de terminaux de la série 5250.

Afin de créer un protocole hôte, IBM développe
Extensions de protocole Telnet (RFC 854, RFC 855, RFC 856, RFC 860, RFC 885, RFC 1091, RFC 1205, RFC 1572, RFC 2877), collectivement appelées Telnet5250 (TN5250), qui décrit le processus de réception et de transmission de flux 5250 flux de données (5250 flux de données) via le protocole Telnet standard.


Programme d'installation IBM Client Access / 400 pour Windows 3.1

Quelle est la particularité de l'IBM 5250?

Une caractéristique des terminaux IBM 5250 (et, par conséquent, du protocole TN5250) est son orientation de bloc, contrairement aux terminaux * nix habituels, qui sont orientés symboles . Cela signifie que les flux de données 5250 par lesquels l'hôte communique avec le terminal sont transmis par des blocs de données, et un symbole distinct sans le contexte du bloc transmis n'a pas de sens.

Par exemple, la machine hôte transmet au terminal un bloc de données contenant les informations statiques affichées à l'écran ainsi que les attributs et coordonnées des champs de saisie et une indication du décalage dans ce bloc, où écrire le résultat de la saisie de l'utilisateur dans les champs. Après cela, la machine hôte attend des messages du terminal et ne participe pas au processus d'entrée utilisateur.


Écran de connexion pour l'hôte IBM i RZKH.de (pub400.com)

En outre, la tâche de l'émulateur de terminal est d'interpréter le bloc de données de la machine et de former l'écran de saisie pour l'utilisateur, où il a la possibilité d'entrer n'importe quelle information dans les champs autorisés. De plus, les tâches de l'émulateur de terminal incluent une réaction aux actions de l'utilisateur. Les touches F1-F24 (les touches F13-F24 sont simulées via SHIFT + Fx), Enter, Home, End, PageUp, PageDn et certaines autres touches spéciales qui ne sont pas disponibles sur les claviers modernes sont considérées comme des clés hôtes. Cela signifie qu'en appuyant sur cette touche, un tampon de flux contenant les informations des champs de saisie et la position du curseur à l'écran, préalablement rempli avec l'émulateur de terminal, sera envoyé à l'hôte pour traitement.


Vidage de tentative de connexion au flux de données WIreshark 5250 sur pub400.com

L’hôte reçoit le tampon, l’analyse et le résultat saisi est transmis au programme qui a demandé la réaction de l’utilisateur pour une validation supplémentaire des données et l’application continue de fonctionner, tandis que l’application reçoit le code de la touche hôte enfoncée.

Pourquoi l'autotest ici

Nous avons pensé à automatiser le test manuel des applications d'écran vert lorsque nous avons été confrontés à la nécessité de tester des centaines d'écrans d'un module développé, où jusqu'à quatre-vingt contrôles commerciaux différents (validations) pouvaient se produire sur un écran.

La douleur particulière de l'équipe a été l'absence presque complète pour 2017 d'outils d' auto-test d' écran vert, à l'exception de la solution propriétaire UIPath . Même aujourd'hui, il n'y a pas beaucoup de solutions similaires, l'auteur connaît Automate from HelpSystems et l'extension JMeter pour BlazeMeter (je serai heureux de connaître d'autres produits similaires).

Les premières recherches sur le problème

L'émulateur standard du terminal TN5250 installé sur les lieux de travail de la banque est IBM Personal Communications for Windows 6.0 (PCOMM 6.0). Des collègues ont constaté que ce produit dispose de moyens d'automatisation réguliers de sa gestion sous la forme d'une API diversifiée, à savoir:

1. Interface de programme d'application linguistique de haut niveau (HLLAPI);
2. HLLAPI amélioré;
3. Windows HLLAPI
4. Bibliothèque du client d'accès à l'hôte (HACL).

Les trois premières interfaces sont les plus anciennes et sont prises en charge depuis les versions DOS et 16 bits de Windows. Le travail sur l'interface EHLLAPI est implémenté en appelant une seule fonction selon le prototype suivant:

long hllapi (LPWORD, LPSTR, LPWORD, LPWORD); 

où le premier paramètre est un pointeur sur le numéro numérique de la fonction en cours d'exécution, les deux autres sont ses arguments contextuels à la fonction appelée et le dernier est le résultat de la fonction. Autrement dit, pour demander l'état de connexion 'A' (les sessions dans l'émulateur sont numérotées avec une lettre latine de la plage de 'A' à 'Z'), vous devez exécuter le code suivant (tiré de la documentation IBM):

  #include "hapi_c.h" struct HLDQuerySessionStatus QueryData; int Func, Len, Rc; long Rc; memset(QueryData, 0, sizeof(QueryData)); // Init buffer QueryData.qsst_shortname = 'A'; // Session to query Func = HA_QUERY_SESSION_STATUS; // Function number Len = sizeof(QueryData); // Len of buffer Rc = 0; // Unused on input hllapi(&Func, (char *)&QueryData, &Len, &Rc); // Call EHLLAPI if (Rc != 0) { // Check return code // ...Error handling } 

Le nombre de fonctions disponibles pour appeler de cette manière est d'environ 60.

L'interface WinHLLAPI étend légèrement cette fonctionnalité avec plusieurs fonctions supplémentaires qui permettent d'enregistrer des fonctions de rappel pour les appels asynchrones afin de notifier les événements d'établissement d'une connexion avec l'hôte, de déconnexion de l'hôte, de modification des données sur l'écran du terminal, etc.

L'interface HACL (Host Access Client Library) semblait être plus conviviale, car, contrairement à l'appel de la "fonction du même nom", une variante de la hiérarchie orientée objet des classes a été fournie, qui imitait complètement toute action de l'utilisateur.


Hiérarchie des classes de la bibliothèque de classes de l'émulateur HACL (C ++)

Il existe des implémentations HACL pour C ++, Java, LotusScript et un serveur d'automatisation COM pour Windows (pratique pour Visual Basic et .NET).

Premier prototype

En raison de l'énorme complexité du protocole de flux de données 5250 et des informations extrêmement rares sur son appareil interne avec des liens vers des publications payantes fermées d'IBM, il est devenu évident que développer votre propre émulateur est extrêmement simple et chronophage. À cet égard, l'idée est venue d'utiliser une couche de middleware qui vous permettra de contrôler l'émulateur de terminal dans les fonctionnalités minimales requises, en particulier «entrez une valeur dans le champ», «comparez une partie de l'écran avec la norme» ou «appuyez sur la touche d'hôte F22».

Des collègues qui utilisaient auparavant des interfaces HACL ont affirmé (et une recherche sur StackOverflow a confirmé) que l'objet COM avait des problèmes de stabilité et pouvait se bloquer après l'exécution d'un certain nombre de commandes. Seul le redémarrage du processus du serveur d'automatisation a aidé. Une analyse rapide de la version Java a montré que Wrapper est utilisé sur l'interface C ++ via JNI. Par conséquent, le choix s'est porté sur l'interface C ++. Les fichiers d'en-tête et les fichiers .lib correspondants étaient disponibles dans le répertoire d'installation de Personal Communications For Windows lui-même.

Le premier prototype était basé sur Qt5, où il était possible d'exécuter du code JavaScript via QtScript. Dans l'environnement du script exécutable, un objet a été enregistré avec un petit nombre de méthodes qui permettaient d'exécuter des commandes dans l'émulateur de terminal comme si elles étaient exécutées par une personne (entrer dans un champ, appuyer sur les touches hôtes, attendre qu'une ligne apparaisse à l'écran). Nous avons fait une démonstration en direct, où nous avons scénarisé un cas d'utilisation pour le lancement d'une application d'écran vert à partir d'ABS Equation avec un test de la réaction de l'application à une entrée incorrecte dans les champs. La démonstration a montré que le prototype a réussi et que nous pouvons avancer.

L'apparition d'un voisin

Parallèlement à la démonstration du premier prototype, des collègues d'un autre département ont assemblé un tas de modules Ruby + Cucumber + Quick3270 + Ruby ( cheeze / te3270 ). L'option proposée utilise un module Ruby qui interagit avec l'émulateur de terminal DN32 Computing Quick3270 via ses objets COM spécialisés (incompatible avec les interfaces HACL). C'était une solution complète pour les applications de test automatique d'écran vert de style BDD, avec quelques étapes pré-décrites. Cependant, dans la solution proposée, nous avons été alarmés par ce qui suit:

1. Nous avons utilisé un émulateur tiers payé non d'IBM (tous les émulateurs fonctionnent un peu différemment, mais nous devons vérifier le travail sur les émulateurs standard utilisés dans la banque, le prix de l'erreur est incroyablement élevé);
2. Les implémentations des étapes de Cucumber pour Quick3270 utilisaient un grand nombre de périodes d'attente pour attendre une réponse de la machine;
3. Très mauvaises performances de Quick3270 via l'interface d'automatisation (travailler avec HACL dans le prototype via l'interface C ++ semblait beaucoup plus dynamique).

Émulateur de terminal Quick3270

Sur la base du prototype, nous avons décidé d'essayer d'implémenter notre propre serveur d'automatisation afin de connecter Cucumber à Personal Communications for Windows et de concevoir les étapes afin que le temps d'arrêt entre les actions sur l'écran de l'émulateur soit minimal.

Digression lyrique . Malgré le fait qu'il existe un grand nombre de problèmes techniques autour d'IBM soi-disant «hérités», qui, semble-t-il, auraient déjà dû être résolus pour les systèmes de niveau moyen et d'entreprise, la pertinence d'adapter et de transférer des solutions techniques existantes est très élevée simplement en raison de leur absence sur la plateforme. Souvent, l'absence est liée aux caractéristiques mêmes de cet OS, qui est fondamentalement différent des modernes * nix, Windows ou MacOS X, qui nécessitent une optimisation significative du logiciel pour cette pile.

Propre décision

Comme notre propre solution, nous avons créé un serveur d'automatisation en tant que développement du prototype précédemment démontré. Ce serveur exécute des commandes pour automatiser l'interaction des consommateurs via un serveur RPC (Qt5 WebSocket). Il interagit avec Personal Communications for Windows, qui fait partie de l'image du système d'exploitation Windows d'entreprise, et vous permet de:

• démarrer / arrêter les sessions d'émulation de terminal;
• Effectuer l'écran vert de grattage d'écran;
• rechercher des champs de saisie à l'écran;
• contrôler le curseur et simuler les frappes (y compris l'hôte);
• et autres

Démarrez Automation Server

Cependant, pour tous les avantages de l'API HACL, elle présente un inconvénient: elle ne sait pas comment travailler avec le SGBD DB2 for i intégré au système d'exploitation et ne permet pas d'exécuter des commandes essentielles à la création d'un environnement simulé dans lequel un script de test serait exécuté. Si le client DB2 pour Ruby existe depuis IBM, alors le client pour le serveur de commandes distantes et d'appels de programme distribué est uniquement pour Java sous la forme de la bibliothèque JTOpen : la version Open Source d'IBM Toolbox for Java (également appelée jt400 ) Nous avons «aperçu» la solution à ce problème chez IBM lui-même en analysant le comportement de ses produits avec des fonctionnalités similaires (en particulier, Personal Communications for Windows Data Transfer, iSeries to PC / PC to iSeries Transfer, etc.). Il s'est avéré que ces produits, par leur implémentation, exécutent IBM JRE 6 ou 8, selon la version de l'application, et utilisent la bibliothèque jt400.

Pour le serveur d'automatisation, nous avons décidé de faire de même. Le JNI lance IBM JVM, fourni avec Personal Communications for Windows. À l'aide de méthodes d'encapsulation spéciales, les commandes du serveur RPC provenant de l'extérieur sont exécutées en les procurant par proxy des appels à la fonctionnalité jt400 nécessaire. Comme ce dernier contient également un pilote JDBC pour DB2, il a été décidé de l'utiliser pour accéder au SGBD sur IBM i.

Il est important de noter que vous ne pouvez pas utiliser Oracle JVM lorsque vous utilisez HACL. Si vous exécutez une session d'émulateur de terminal, la tentative de création d'une instance de la machine virtuelle se bloquera. De même, si vous exécutez la JVM Oracle dans l'espace d'adressage d'un processus interagissant avec la HACL, cette dernière se bloque sans explication.

Au fil du temps, la solution a été mise en œuvre sur un nombre croissant d'emplois. Cela a fonctionné plus rapidement que la solution avec Quick3270. La popularité a augmenté, tout comme le nombre d'autotests. Cependant, pendant le fonctionnement, des difficultés supplémentaires sont apparues:

1. Le terminal se bloque occasionnellement;
2. Impossibilité de travailler sur un stand de régression en raison du refus de l'émulateur de terminal de démarrer si le bureau de l'utilisateur sous lequel l'émulateur démarre est bloqué ou que sa session RDP est bloquée;
3. Windows uniquement;
4. Une procédure complexe pour l'installation, la configuration et la mise à jour des outils (via un package msi);
5. Notre cycle de régression pour 130 autotests (environ 4000 étapes) a commencé à prendre 7 à 8 heures.

Il faut faire quelque chose ...

En analysant les journaux de trace de nombreux lancements d'autotests, en découvrant des goulots d'étranglement dans les performances des étapes fréquemment utilisées, le temps total d'exécution de la régression a été réduit à 4-5 heures. Mais il était clair que l'utilisation de la couche middleware sous la forme d'un serveur RPC d'automatisation en conjonction avec l'interface HACL, qui a également des erreurs «flottantes» qui s'accumulent sur la durée de l'ensemble du système, n'aidera pas à améliorer les performances de la solution.

D'autre part, comme alternative à IBM Personal Communications pour Windows, le fournisseur fournit une solution multiplateforme appelée IBM i Access - Client Solutions.


IBM i Access - Solutions client

L'analyse de sa structure interne le samedi et le dimanche matin autour de tasses de café a montré que sa base de code est basée sur un autre produit IBM appelé IBM Host on-Demand (IBM HOD). Il s'agit d'une solution à part entière pour accéder à IBM i, développée en Java 6, qui a non seulement la mise en œuvre complète des différents protocoles de communication utilisés dans les machines IBM (TN3270, TN5250, VTxxx, etc.), mais aussi des composants d'interface utilisateur Java-swing de haut niveau, utilisé pour construire leurs propres émulateurs de terminaux sous la forme d'un constructeur, qui peut être assemblé à partir de la documentation IBM limitée. Une étude plus détaillée du IBM HOD a montré que les composants de l'interface utilisateur sont basés sur l'implémentation Java de l'interface HACL, dont la documentation est ouverte. Leur comportement coïncide avec seulement de légères différences par rapport à la documentation C ++ HACL.


IBM Host On-Demand (logo)

Ensuite, nous avons créé une bibliothèque Java à usage interne, qui implémente la même interface que le serveur d'automatisation C ++ RPC, mais utilise en interne IBM HOD. Pour réduire la surcharge lors de l'exécution des étapes d'autotest, nous avons migré de Ruby Cucumber vers cucumber-jvm avec la réimplémentation de toutes les étapes similaires aux options Ruby. En présence d'une interface logicielle similaire au serveur RPC, ce n'était pas un gros problème, d'autant plus que nous avons essayé de freiner la croissance incontrôlée du nombre d'étapes elles-mêmes et que nous avions cette valeur aux alentours de 30 unités.

Quel est le résultat

En conséquence, nous avons atteint l'opérabilité de tous les autotests sans les modifier, et la vitesse de travail est devenue si élevée que nous avons dû introduire un délai artificiel entre les étapes afin que lors du développement d'un autotest, vous puissiez observer son travail, sinon l'interface utilisateur n'a pas eu le temps de tirer l'écran jusqu'à la fin.

Déjà 180 autotests existants avec plus de 16 000 étapes avec un délai défini de 60 ms entre les étapes ont commencé à s'exécuter environ 30 minutes contre 5 heures 30 minutes, ce qui correspond à une augmentation de onze fois des performances du stand de régression.

Les résultats ont dépassé toutes les attentes. Nous sommes proches des limites physiques du protocole TN5250.

À ce jour, la décision a été publiée dans toute la banque et des collègues d'autres villes se sont joints à l'amélioration. Parmi les changements récents, les collègues intègrent la solution avec Jenkins, dans la version de test, le test du lancement sur un serveur Linux avec Xvfb a été achevé et la phase d'opération pilote d'exécution des autotests a commencé.

Merci d'avoir lu jusqu'au bout!
Tout succès!

PS En décembre 2018, la prochaine conférence des développeurs IBMi a eu lieu, au cours de laquelle un rapport a été rédigé sur le sujet de cet article.

Jusqu'à présent, nous avons organisé la conférence chaque année uniquement pour les employés de la Banque. À partir de 2019, nous inviterons des participants d'autres entreprises. Il est très intéressant d'élargir le cercle de la communication professionnelle et personnelle, de partager les émotions, les connaissances et l'expérience.