IBM System i (también conocido como AS / 400): cómo realizamos las pruebas automáticas de aplicaciones de pantalla verde

Hola Mi nombre es Anton Vorobyov, soy responsable en Alfa Bank del desarrollo de aplicaciones para un sistema bancario centralizado.

En esta publicación, le contaré sobre qué son las aplicaciones de pantalla verde, por qué son necesarias y cómo hicimos las pruebas automáticas para ellas escribiendo nuestra propia solución para esto, lo que nos permitió acelerar las pruebas automáticas 11 veces.



La plataforma AS / 400 (Application System / 400) nació en 1988. El primer sistema operativo para esta plataforma es OS / 400, luego renombrado a i5 / OS e incluso más tarde a IBM i. No hace mucho tiempo, celebró su trigésimo cumpleaños.

Al sumergirse en el mundo del desarrollo bajo el sistema operativo IBM i, comprende que esto en realidad no es "legado" en el sentido clásico de la palabra. Este es un entorno diferente, completamente diferente, que es poco similar a los sistemas habituales de Windows o Unix. La tarea principal de este sistema operativo es ser lo más productivo posible en el equipo con el que trabaja, y no ser conveniente para el usuario.

En mi humilde opinión, este sistema operativo puede volverte loco por lo ineficaces que son los métodos habituales para escribir código C ++ (hasta decenas de veces la pérdida de CPU), que algunos antipatrones demostrados en los libros de texto son la mejor práctica de código efectivo, y la fuente con la fecha de escritura ¡para 1978 no solo se ensambla sin problemas, sino que también funciona como está diseñado! Todo esto nos hace echar un vistazo a los enfoques modernos para el desarrollo de software.

Introduccion

La cuestión de mejorar la calidad del software en desarrollo excita las mentes de cada equipo de desarrollo. Uno de nuestros equipos de crédito, cuya tarea es desarrollar y desarrollar la parte posterior del módulo para el sistema bancario automatizado Misys Equation, tampoco ha pasado por alto este momento. La peculiaridad de este ABS es que:

• las primeras versiones del ABS funcionaron bajo el predecesor AS / 400 - la plataforma IBM System / 38 (apareció en 1978) bajo el sistema operativo CPF - "Control Program Facility";
• Se ha desarrollado desde los años 70 del siglo XX, y es posible que encuentre un código escrito antes de su nacimiento (muchos códigos antiguos);
• Las características de trabajar con ABS se deben a la estrecha integración con IBM i, y debido a la colosal compatibilidad hacia atrás de este último, parece que está trabajando como arqueólogo en las excavaciones de la Gran Pirámide.

IBM i (logotipo)

El desarrollo de aplicaciones para este ABS (opciones de ABS) se lleva a cabo de acuerdo con el estándar del paquete de desarrollador de Misys ITP, Paquete Técnico del Integrador, que estipula que la opción debe consistir en un programa interactivo para la interacción del terminal con el usuario final e implementar la API utilizando la interfaz instalada para la ejecución en segundo plano. .

Tales programas interactivos desarrollados bajo el sistema operativo IBM i se llaman históricamente aplicaciones de pantalla verde y son la única interfaz de usuario con la que interactúa el usuario de este ABS.

¿Qué es una aplicación de pantalla verde?

La respuesta simple es una aplicación que se ve así:



Más o menos :

¿Por qué aplicaciones de pantalla verde?

Históricamente, las únicas aplicaciones interactivas que se ejecutan en los sistemas de rango bajo y medio de la familia AS / 400 y otros mainframes de IBM que le permitieron solicitar cualquier entrada del usuario son las aplicaciones de pantalla verde. La instalación, administración, configuración y desarrollo en el sistema operativo IBM i (y sus predecesores i5 / OS y AS400) se llevaron a cabo (y todavía se llevan a cabo en algún lugar) utilizando exclusivamente aplicaciones de pantalla verde.

La imagen de la aplicación de pantalla verde tiene dos tamaños: 24x80 y 27x132 caracteres y 16 colores posibles. Dentro de esta escala, se realiza la mayor parte del trabajo de los desarrolladores y usuarios de este sistema operativo.

Tales tamaños de pantalla son el resultado de la evolución de las "estaciones de trabajo" que se conectaron a los progenitores AS400 de los segmentos de gama baja y media de las computadoras comerciales IBM System / 32, System / 34, System / 36 y System / 38. Estas estaciones de trabajo se llamaron terminales y consistían en una pantalla en una caja de metal con un teclado y equipo adicional en forma de un bolígrafo ligero. Inicialmente, solo se admitían dos colores de la pantalla: verde y verde brillante, lo que condujo a la conocida frase "aplicación de pantalla verde" (aplicación de pantalla verde en la literatura inglesa). En la década de 1970, el número de colores admitidos aumentó a 16.


5251 Display Station Modelo 11

Las opciones de terminal más comunes fueron 5251 Display Station Modelo 1 (960 caracteres en la pantalla) y Modelo 11 (1920 caracteres en la pantalla) con dimensiones Ancho / Profundidad / Altura igual a 530/400/400 mm, respectivamente, y un peso de 34 kg. La resolución de pantalla del Modelo 1 era 12x80, Modelo 11 - 24x80. El terminal estaba conectado directamente al sistema host.

Los terminales 5251 Display Station Model 2 (960 caracteres en la pantalla) y Model 12 (1920 caracteres en la pantalla) con grandes dimensiones y un peso de 45 kg también fueron bastante comunes. Se distinguen del Modelo 1 y el Modelo 11 por la posibilidad de reenviar la conexión aguas arriba a la máquina host desde clientes más baratos en forma de terminales Modelo 1 (u 11) con impresoras de escritorio o una impresora de piso separada. Por lo tanto, los modelos 2 y 12 actuaron como un concentrador, representando la conexión al host desde dispositivos que requieren una conexión directa a la máquina host, y cuestan significativamente más.

Los terminales de la serie 5252 Dual Display Station también le parecerán inusuales al lego moderno.


Imagen promocional del folleto de IBM System / 38 Equipment and Programs (5252 Dual Display Station)

El precio de un kit de terminal con una impresora conectada podría alcanzar varios miles de dólares estadounidenses.

Los terminales se conectaron mediante un cable twinaxial a la máquina host con una topología de bus en modo semidúplex con una velocidad de transmisión de hasta 1 Mbps. El número máximo de terminales admitidos por twinaxial es de hasta 6 terminales, y el terminal más alejado del host debe ubicarse a una distancia de no más de 1500 metros.

El número de cada terminal se establece durante su instalación mediante tres interruptores, por lo que se determina una dirección única dentro del bus. En presencia de una red coaxial existente, es posible usar adaptadores de un cable twinaxial a un cable coaxial y un conjunto apropiado de terminaciones de cable para engarzar. Con este esquema, era posible conectar solo dos dispositivos en el bus con una longitud máxima de segmento de hasta 30 metros. El número total de dispositivos conectados varió de una docena a varias docenas, según el modelo.

Con el desarrollo de los sistemas de escritorio y las redes de acceso, los terminales voluminosos fueron reemplazados por estaciones de trabajo, donde se utilizaron varias tarjetas de expansión de compañías externas como medios de acceso a la máquina host, lo que permite la conexión directa a través de twinaxial. Después de que IBM desarrolló la tecnología Token Ring en 1984, aparecieron soluciones de software para acceder a la máquina, incluso a través de esta interfaz.


Adaptador 5250 al bus ISA (fabricante desconocido)


Tarjetas adaptadoras Blackbox 5250 (PC470C, PC471C, PC472C, PC473C, PC478C)

Los emuladores para MS-DOS y MS Windows aparecen tanto de IBM como de terceros, incluidas las implementaciones de OpenSource (por ejemplo, tn5250j.sourceforge.net). A mediados de los 90, la pila TCP / IP llega a la mitad del mundo -máquinas comerciales de gama baja y baja. Para admitir el acceso de host a través del nuevo protocolo, IBM está desarrollando emuladores de terminal de la serie 5250.

Para crear un protocolo de host, IBM está desarrollando
Extensiones de protocolo Telnet (RFC 854, RFC 855, RFC 856, RFC 860, RFC 885, RFC 1091, RFC 1205, RFC 1572, RFC 2877), colectivamente denominado Telnet5250 (TN5250), que describe el proceso de recepción y transmisión de flujos Flujos de datos 5250 (flujos de datos 5250) a través del protocolo Telnet estándar.


IBM Client Access / 400 para el instalador de Windows 3.1

¿Qué tiene de especial el IBM 5250?

Una característica de los terminales IBM 5250 (y, en consecuencia, el protocolo TN5250) es su orientación de bloque, en contraste con los terminales habituales * nix, que están orientados a símbolos . Esto significa que los flujos de datos 5250 por los cuales el host se comunica con el terminal son transmitidos por bloques de datos, y un símbolo separado en él sin el contexto del bloque transmitido no tiene sentido.

Por ejemplo, la máquina host transmite al terminal un bloque de datos que contiene la información estática que se muestra en la pantalla junto con los atributos y coordenadas de los campos de entrada y una indicación del desplazamiento en este bloque, donde escribir el resultado de la entrada del usuario en los campos. Después de eso, la máquina host espera mensajes del terminal y no participa en el proceso de entrada del usuario.


Pantalla de inicio de sesión para IBM i host RZKH.de (pub400.com)

Además, la tarea del emulador de terminal es interpretar el bloque de datos de la máquina y formar la pantalla de entrada para el usuario, donde se le da la oportunidad de ingresar cualquier información en los campos permitidos. Además, las tareas del emulador de terminal incluyen una reacción a las acciones del usuario. Las teclas F1-F24 (F13-F24 se simulan mediante SHIFT + Fx), Enter, Home, End, PageUp, PageDn y algunas otras teclas especiales que no están disponibles en los teclados modernos se consideran teclas de host. Esto significa que al presionar esta tecla, un búfer de flujo con información de los campos de entrada y la posición del cursor en la pantalla, previamente llena con el emulador de terminal, se enviará al host para su procesamiento.


WIreshark 5250 Data Stream intento de inicio de sesión volcado en pub400.com

El host recibe el búfer, lo analiza y el resultado de entrada se pasa al programa que solicitó la respuesta del usuario para una validación de datos adicional y la aplicación continúa funcionando, mientras la aplicación recibe el código de la tecla de host presionada.

¿Por qué es autotesting aquí?

Pensamos en automatizar las pruebas manuales de las aplicaciones de pantalla verde cuando nos enfrentamos a la necesidad de probar cientos de pantallas de un módulo desarrollado, donde podrían ocurrir hasta ochenta comprobaciones comerciales diferentes (validaciones) en una pantalla.

El dolor particular del equipo fue la ausencia casi completa en 2017 de herramientas de prueba automática de pantalla verde, a excepción de la solución patentada UIPath . Incluso hoy en día no hay muchas soluciones similares, el autor sabe Automatizar desde HelpSystems y la extensión JMeter para BlazeMeter (estaré encantado de recibir información sobre otros productos similares).

La primera investigación sobre el problema.

El emulador estándar del terminal TN5250 instalado en los lugares de trabajo en el banco es IBM Personal Communications para Windows 6.0 (PCOMM 6.0). Los colegas descubrieron que este producto tiene medios regulares para automatizar su administración en forma de una API diversa, a saber:

1. Interfaz de programa de aplicación de lenguaje de alto nivel (HLLAPI);
2. HLLAPI mejorado;
3. Windows HLLAPI
4. Host Client Client Library (HACL).

Las tres primeras interfaces son las más antiguas y se admiten desde las versiones de DOS y Windows de 16 bits. El trabajo en la interfaz EHLLAPI se implementa llamando a una única función de acuerdo con el siguiente prototipo:

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

donde el primer parámetro es un puntero al número numérico de la función que se ejecuta, los otros dos son sus argumentos sensibles al contexto de la función que se llama, y ​​el último es el resultado de la función. Es decir, para solicitar el estado de conexión 'A' (las sesiones en el emulador están numeradas con una letra latina del rango de 'A' a 'Z'), debe ejecutar el siguiente código (tomado de la documentación de 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 } 

El número de funciones disponibles para llamar de esta manera es de aproximadamente 60.

La interfaz WinHLLAPI expande ligeramente esta funcionalidad con varias funciones adicionales que permiten registrar funciones de devolución de llamada para llamadas asíncronas para notificar sobre eventos de establecer una conexión con el host, desconectarse del host, cambiar datos en la pantalla del terminal, etc.

La interfaz de Host Access Client Library (HACL) parecía ser más fácil de usar porque, en contraste con llamar a la "función del mismo nombre", se proporcionó una variante de la jerarquía de clases orientada a objetos que imitaba completamente cualquier acción del usuario.


HACL Emulator Class Library Jerarquía de clases (C ++)

Hay implementaciones de HACL para C ++, Java, LotusScript y un servidor de automatización COM para Windows (conveniente para Visual Basic y .NET).

Primer prototipo

Debido a la enorme complejidad del protocolo de flujo de datos 5250 y la información extremadamente escasa sobre su dispositivo interno con enlaces a literatura paga cerrada de IBM, se hizo evidente que desarrollar su propio emulador es extremadamente no trivial y consume mucho tiempo. En este sentido, surgió la idea de utilizar una capa de middleware que le permita controlar el emulador de terminal dentro de la funcionalidad mínima requerida, en particular "ingrese un valor en el campo", "compare parte de la pantalla con el estándar" o "presione la tecla host F22".

Los colegas que anteriormente usaban interfaces HACL afirmaron (y una búsqueda en StackOverflow confirmó) que el objeto COM tenía problemas de estabilidad y podía bloquearse después de que se ejecutara un cierto número de comandos. Solo reiniciar el proceso del servidor de automatización ayudó. Un análisis rápido de la versión de Java mostró que Wrapper se usa sobre la interfaz C ++ a través de JNI. Por lo tanto, la elección recayó en la interfaz C ++. Los archivos de encabezado y archivos .lib correspondientes estaban disponibles en el directorio de instalación de Personal Communications para Windows.

El primer prototipo se basó en Qt5, donde fue posible ejecutar código JavaScript a través de QtScript. En el entorno de la secuencia de comandos ejecutable, se registró un objeto con una pequeña cantidad de métodos que permitieron ejecutar comandos en el emulador de terminal como si fueran ejecutados por una persona (ingresando un campo, presionando las teclas del host, esperando que aparezca una línea en la pantalla). Demostramos una "demostración" en vivo, donde escribimos un guión de un caso de usuario para iniciar una aplicación de pantalla verde desde ABS Equation con una prueba de la reacción de la aplicación a la entrada incorrecta en los campos. La demostración mostró que el prototipo fue exitoso y que podemos seguir adelante.

La aparición de un vecino.

Junto con la demostración del primer prototipo, los colegas de otro departamento reunieron un grupo de módulos Ruby + Pepino + Quick3270 + Ruby ( cheeze / te3270 ). La opción propuesta utiliza un módulo Ruby que interactúa con el emulador de terminal Quick3270 Computing DN32 a través de sus objetos COM especializados (incompatible con las interfaces HACL). Era una solución completa para aplicaciones de prueba automática de pantalla verde estilo BDD, con unos pocos pasos descritos previamente. Sin embargo, en la solución propuesta nos alarmó lo siguiente:

1. Utilizamos un emulador pago de terceros que no es de IBM (todos los emuladores funcionan de manera un poco diferente, pero necesitamos verificar el trabajo en los estándares utilizados en el banco, el precio del error es increíblemente alto);
2. Las implementaciones de los pasos de Cucumber para Quick3270 utilizaron una gran cantidad de durmientes para esperar una respuesta de la máquina;
3. Muy mal rendimiento de Quick3270 a través de la interfaz de automatización (trabajar con HACL en el prototipo a través de la interfaz C ++ parecía mucho más dinámico).

Emulador de terminal Quick3270

Con base en el prototipo, decidimos intentar implementar nuestro propio servidor de automatización para conectar Cucumber a Personal Communications para Windows y diseñar los pasos para que el tiempo de inactividad entre las acciones en la pantalla del emulador sea mínimo.

Digresión lírica . A pesar del hecho de que hay una gran cantidad de problemas técnicos en torno al supuesto "legado" de IBM, que, al parecer, ya debería haberse resuelto para sistemas de nivel medio y empresarial, la relevancia de adaptar y transferir las soluciones técnicas existentes es muy alta simplemente por su ausencia en la plataforma. A menudo, la ausencia está relacionada con las características de este sistema operativo, que es fundamentalmente diferente de las modernas * nix, Windows o MacOS X, que requieren una optimización significativa del software para esta pila.

Decisión propia

Como nuestra propia solución, creamos un servidor de automatización como desarrollo del prototipo previamente demostrado. Este servidor ejecuta comandos para automatizar la interacción de los consumidores a través de un servidor RPC (Qt5 WebSocket). Interactúa con Personal Communications para Windows, que es parte de la imagen corporativa del sistema operativo Windows, y le permite:

• iniciar / detener sesiones del emulador de terminal;
• Realizar Screen Scraping Green Screen;
• buscar campos de entrada en la pantalla;
• controlar el cursor y simular pulsaciones de teclas (incluido el host);
• y otros

Iniciar servidor de automatización

Sin embargo, para todas las ventajas de la API HACL, tiene un inconveniente: no sabe cómo trabajar con DB2 para i DBMS integrado en el sistema operativo y no permite ejecutar comandos que son vitales para crear un entorno simulado donde se ejecutaría un script de prueba. Si el cliente de DB2 para Ruby existe de IBM, entonces el cliente para el servidor de comando remoto y de llamada de programa distribuido es solo para Java en forma de biblioteca JTOpen : la versión de código abierto de IBM Toolbox para Java (también conocida como jt400 ) "Observamos" la solución a este problema en IBM al analizar el comportamiento de sus productos con una funcionalidad similar (en particular, Comunicaciones personales para Windows Data Transfer, iSeries a PC / PC a iSeries Transfer, etc.). Resultó que estos productos, por su implementación, ejecutan IBM JRE 6 u 8, dependiendo de la versión de la aplicación, y utilizan la biblioteca jt400.

Para el servidor de automatización, decidimos hacer lo mismo. JNI lanza IBM JVM, que se entrega con Personal Communications para Windows. Usando métodos de envoltura especiales, los comandos del servidor RPC que provienen del exterior se ejecutan mediante proxy en llamadas a la funcionalidad jt400 necesaria. Como este último también contiene un controlador JDBC para DB2, se decidió utilizarlo para acceder al DBMS en IBM i.

Es importante tener en cuenta que no puede usar Oracle JVM cuando usa HACL. Si ejecuta una sesión de emulador de terminal, se bloqueará el intento de crear una instancia de la máquina virtual. Del mismo modo, si ejecuta Oracle JVM en el espacio de direcciones de un proceso que interactúa con el HACL, este último se bloquea sin explicación.

Con el tiempo, la solución se implementó en un número creciente de trabajos. Funcionó más rápido que la solución con Quick3270. La popularidad creció, al igual que el número de autotests. Sin embargo, durante la operación, surgieron dificultades adicionales:

1. Congelaciones terminales ocasionales;
2. Incapacidad para trabajar en un soporte de regresión debido a que el emulador de terminal se niega a iniciarse si el escritorio del usuario bajo el cual se inicia el emulador está bloqueado o su sesión RDP está bloqueada;
3. Solo para Windows;
4. Un procedimiento complejo para instalar, configurar y actualizar herramientas (a través de un paquete msi);
5. Nuestro ciclo de regresión para 130 pruebas automáticas (aproximadamente 4000 pasos) comenzó a tomar de 7 a 8 horas.

Algo debe hacerse ...

Al analizar los registros de seguimiento de numerosos lanzamientos de pruebas automáticas, buscando cuellos de botella en el desempeño de los pasos utilizados con frecuencia, el tiempo total de ejecución de la regresión se redujo a 4-5 horas. Pero estaba claro que usar la capa de middleware en forma de un servidor RPC de automatización junto con la interfaz HACL, que también tiene errores "flotantes" que se acumulan durante todo el sistema, no ayudará a mejorar el rendimiento de la solución.

Por otro lado, como alternativa a IBM Personal Communications para Windows, el proveedor proporciona una solución multiplataforma llamada IBM i Access - Soluciones de cliente.


IBM i Access - Soluciones de cliente

El análisis de su estructura interna los sábados y domingos por la mañana con una taza de café mostró que su código base se basa en otro producto de IBM llamado IBM Host on-Demand (IBM HOD). Esta es una solución completa para acceder a IBM i, desarrollada en Java 6, que no solo tiene la implementación completa de varios protocolos de comunicación utilizados en máquinas IBM (TN3270, TN5250, VTxxx, etc.), sino también componentes de interfaz de usuario java-swing de alto nivel, solían construir sus propios emuladores de terminal en forma de constructor, que pueden ensamblarse a partir de la escasa documentación de IBM. Un estudio más detallado de IBM HOD mostró que los componentes de la interfaz de usuario se basan en la implementación de Java de la interfaz HACL, cuya documentación está abierta. Su comportamiento coincide con solo ligeras diferencias con respecto a la documentación de C ++ HACL.


IBM Host On-Demand (logotipo)

A continuación, creamos una biblioteca Java para uso interno, que implementa la misma interfaz que el servidor de automatización C ++ RPC, pero internamente utiliza IBM HOD. Para reducir la sobrecarga durante la ejecución de los pasos de la prueba automática, migramos de Ruby Cucumber a cucumber-jvm con la reimplementación de todos los pasos similares a las opciones de Ruby. En presencia de una interfaz de software similar al servidor RPC, esto no fue un gran problema, especialmente teniendo en cuenta que tratamos de frenar el crecimiento incontrolado en el número de pasos en sí mismos y teníamos este valor en la región de 30 unidades.

Cual es el resultado

Como resultado, logramos la operatividad de todas las pruebas automáticas sin cambiarlas, y la velocidad del trabajo se hizo tan alta que tuvimos que introducir un retraso artificial entre los pasos para que al desarrollar una prueba automática, pudieras observar su trabajo, de lo contrario la interfaz de usuario no tuvo tiempo de dibujar la pantalla hasta el final.

Las 180 pruebas automáticas ya existentes con más de 16,000 pasos con un retraso establecido de 60 ms entre pasos comenzaron a ejecutarse aproximadamente 30 minutos contra 5 horas 30 minutos, lo que corresponde a un aumento de once veces en el rendimiento del soporte de regresión.

Los resultados excedieron todas las expectativas. Estamos cerca de los límites físicos del protocolo TN5250.

Hasta la fecha, la decisión se ha publicado en todo el banco, y colegas de otras ciudades se han unido a la mejora. De los cambios recientes, los colegas están integrando la solución con Jenkins, en la versión de prueba, la prueba del lanzamiento en un servidor Linux con Xvfb se completó y comenzó la etapa de operación piloto de ejecución de pruebas automáticas.

¡Gracias por leer hasta el final!
Todo el exito!

PD En diciembre de 2018, se celebró la próxima Conferencia de desarrolladores de IBMi, en la que se realizó un informe sobre el tema de este artículo.

Hasta ahora, hemos celebrado la Conferencia anualmente solo para empleados del Banco. A partir de 2019, invitaremos a participantes de otras empresas. Es muy interesante ampliar el círculo de comunicación profesional y personal, compartir emociones, conocimientos y experiencias.