♓️ 🤙🏿 🐅 Software de prueba de automatización terminales QIWI 👩‍❤️‍💋‍👩 😜 ✌🏻

Hola Habr!

Hoy hablaremos sobre un tema específico: la automatización de pruebas de software para terminales de autoservicio QIWI.

Hay áreas en el tema de la automatización de pruebas que se escanean varias veces, por ejemplo, probar servicios web. Para tales áreas, existen herramientas, patrones y mejores prácticas separadas. No necesita inventar nada, los riesgos son mínimos, lo toma y lo hace.

Hay situaciones inversas. El área temática es específica, nadie tiene un vistazo a las soluciones preparadas, no hay herramientas, la pila tecnológica del producto es peculiar. Tienes que sumergirte profundamente en el área del tema, desde palos y uh ... otros materiales improvisados para crear herramientas para ti y simultáneamente recolectar muchos, muchos rastrillos de diferentes tamaños y fuerza letal.

Quería hablar sobre algo como esto hoy. El artículo es adecuado para aquellos involucrados en el desarrollo y prueba de software para terminales bancarias o máquinas de autoservicio. Y también para aquellos que desean expandir sus horizontes técnicos con ejemplos de "pero también sucede así". Terminal QIWI en 2020. En el fondo, puede ver su llenado.

Problema

El primer terminal QIWI apareció en 2004 y luego pudo reponer la cuenta de un teléfono móvil. Desde entonces, ha fluido mucha agua y las ASO (máquinas de autoservicio) han cambiado mucho. Ahora, con la ayuda de ellos, puede reponer las tarjetas bancarias, realizar transferencias, pagar los servicios de varios proveedores (proveedores): servicios de vivienda y comunales, multas de la policía de tránsito, organizaciones de crédito, nuestros propios productos QIWI (billetera QIWI, tarjeta de pago sin intereses Conciencia). Los terminales QIWI también pueden operar en el modo de postamata (puntos de entrega automatizados para tiendas en línea).

¿Cómo es una terminal?

El terminal ASO, desde el punto de vista del hierro, es un escritorio ordinario con periféricos específicos, como aceptadores de billetes y aceptadores de monedas, impresoras de recibos, dispensadores, terminales POS (que reciben tarjetas de plástico), etc.

Y aquí está el primer problema.

Esta famosa fotografía fue tomada en el condado de Sonoma, California. Dicen que estos son colores naturales, sin ningún procesamiento. Por cierto, fue en el territorio del condado de Sonoma donde se ubicó la colonia rusa más meridional de América.

Sí, esa es ella. El sistema operativo, que se suspendió en 2014, es Windows XP. La versión POSReady se lanzó hasta 2019, pero ... No es tan simple.

El hecho es que los terminales no son propiedad de QIWI. Pertenecen a socios, los llamados Los agentes, empresarios individuales y entidades legales que firman un acuerdo con QIWI compran terminales, alquilan espacio en centros comerciales y reciben ingresos casi pasivos.

En consecuencia, el 90% de la flota de terminales QIWI (y hay más de 100k en Rusia y países extranjeros) están ejecutando Windows XP en una variedad de hardware, desde 512 MB a 4 GB de RAM, una variedad de CPU (desde Pentium 4, cero cero profundo a más) Core i5 menos moderno) y diferente calidad y velocidad de Internet. Terminales de diferentes edades, algunos de ellos se actualizan regularmente y otros no se han actualizado durante mucho tiempo (funciona, ¡no lo toque!). Nuestra tarea es suministrar regularmente las últimas actualizaciones de software de terminal (se llama MarATL) y mantener la compatibilidad con toda esta variedad de coberturas y periféricos.

Sistema operativo de soporte caducado

Imagine un simple circuito de automatización de prueba. Tenemos un servidor CI, por ejemplo, TeamCity o Jenkins. Nuestro software de terminal se recopila de raws por evento (commit o heap), el archivo binario recopilado se presenta en algún lugar. El software se instala automáticamente, se inician las pruebas automáticas funcionales nocturnas ... Uh, ¡para! ¿A dónde va la instalación del software? ¿Y cómo?

Como dije anteriormente, el 90 por ciento de los terminales están ejecutando Windows XP, que finalizó en 2014. Esto significa que este sistema operativo ya no cumple con las políticas de seguridad durante mucho tiempo, no se publican actualizaciones para él, no hay un software nuevo que funcione, e incluso el Microsoft Visual Studio nativo compila C ++ solo después de bailar con una pandereta, o más bien con la versión de la cadena de herramientas para el colector MSBuild.

En general, ejecutar pruebas y algún tipo de software en un terminal o máquina virtual con Windows XP es una muy mala idea. No puede aumentar Buildagent TeamCity en XP, no puede configurar una máquina de este tipo en el libro de jugadas de Ansible, tampoco hay contenedores allí. Las plantillas de virtualización para Windows XP tampoco son tanto. En cualquier empresa grande que piense en la seguridad de la información, una máquina con Windows XP se mantendrá alejada de la red corporativa, o incluso menos del dominio. Es decir, toda interacción con el terminal (o la máquina virtual que finge serlo) debe ocurrir de forma remota, el terminal en sí debe tener un mínimo de software de terceros.

Decisión

Algunas personas se sorprenden cuando escuchan sobre un montón de OpenSSH y Windows XP. En una versión moderna de Microsoft, el soporte OSH se incluye directamente en el sistema. En los no tan modernos (Windows 7), hay instaladores SSH que usan PowerShell. C Windows XP, la situación es un poco peor, pero solo un poco. Existe una versión antigua del instalador que se ejecuta sin software adicional.

SSH es una forma antigua, buena y confiable de controlar remotamente un host, una tecnología bien conocida. Debe implementar clases de conectores SSH que puedan hacer varias cosas en paralelo. Por ejemplo, en el modo en línea, cargue registros nuevos desde la terminal, ejecute algunos comandos (copiar archivos, ejecutar scripts, emitir derechos, obtener una lista de procesos, monitorear la hora del sistema de la terminal, etc.).

El monitoreo del tiempo del sistema es especialmente interesante. Mediante herramientas de línea de comandos estándar, Windows XP muestra el tiempo solo en un formato formateado horas-minutos-segundos, etc., sin tiempo UNIX para usted. La emboscada, por ejemplo, es que XP no ha recibido actualizaciones de zona horaria durante mucho tiempo, y nuestro gobierno ruso es conocido por sus constantes juegos con la cancelación del horario de verano o invierno.

Por ejemplo, el Windows XP SP3 estándar en la zona horaria de Moscú muestra la hora una hora antes que la hora real de Moscú. En consecuencia, las marcas de tiempo de los registros de terminal en cualquier caso no coinciden con el tiempo en el circuito de prueba.

Pagos-Pagos-Pagos ...

La interfaz del terminal QIWI es esencialmente una web que se ejecuta en un motor de navegador, que generalmente es bastante antiguo. Según el protocolo websocket, interactúa con MarATL, en realidad un software de terminal. Al elegir un pago en el terminal (por ejemplo, pagar por comunicaciones celulares) usando una serie de comandos, se selecciona un proveedor de pago, se determina la cantidad de comisiones, se restringen las restricciones para aceptar facturas, se crea un pago para un proveedor específico, que luego se envía a través del procesamiento del terminal de pago a los pagos.

Interactuar con la interfaz web de forma remota es una idea regular, especialmente las pruebas de interfaz, otra tarea. Puede crear una página web de prueba que se basará en el tiempo de prueba en lugar del index.html estándar. La página ejecuta un script JS que funciona con software de terminal y, por otro lado, crea un cliente de socket web que mira hacia el host en el que se ejecutan las pruebas.

En el lado de las pruebas automáticas, debe implementar un servidor de socket web que espere al inicio de la conexión del cliente desde el terminal y envíe comandos que no se modifiquen a través de la página de prueba al software del terminal. Las respuestas de software también se envían al servidor de socket web de prueba.

Es decir, puede describir el conjunto de comandos para la prueba de pago en forma de JSON, que describe sucesivamente qué comandos debe enviar y qué tipo de respuesta debe esperar.

Página de prueba de interfaz. Muestra los comandos que lo atraviesan.

¿Y dónde está el dinero?

La tarea técnica más insidiosa es simular los dispositivos periféricos del terminal. La impresora de recibos se simula trivialmente, se crea una impresora virtual en el sistema operativo que imprime los datos en un archivo. Puede obtener esta verificación desde el terminal (o su copia, formada por el propio software del terminal) y decodificarla, verificando simultáneamente, por ejemplo, que todos los campos necesarios estén presentes en esta verificación.

Más complicado con dispositivos que aceptan dinero: aceptadores de billetes y aceptadores de monedas. Está claro que si queremos probar el escenario de pago, debemos emular de alguna manera la presencia del aceptador de facturas en el terminal, admitir la funcionalidad de aceptar facturas, devolver, simular varios problemas (por ejemplo, devolver una factura arrugada).

La mayoría de los dispositivos receptores de dinero funcionan con el protocolo CashCode NET. Este protocolo define los escenarios de interacción entre el aceptador de billetes y el controlador (en nuestro caso, el controlador es nuestro software de terminal).

Un ejemplo de la interacción del controlador y el validador de billetes utilizando el protocolo CashCode. Con cierta frecuencia, el controlador solicita el estado del dispositivo.

El tamaño mínimo del comando CashCode es de 6 bytes. Para obtener una descripción de los comandos, consulte la especificación del protocolo CashCode NET.

El aceptador de billetes estándar está conectado al terminal a través del puerto COM. Existen utilidades de terceros que le permiten crear un puerto serie virtual en la máquina, por ejemplo, VSPE . Incluso los scripts para reenviar este puerto a través de una conexión TCP son compatibles.

Nuestro caso es más simple, necesitamos una herramienta que pueda aferrarse al puerto usando WinAPI y que tenga una interfaz conveniente arbitraria, por ejemplo, el stdin / stdout más simple, que se puede conectar usando SSH.

Tula en una secuencia separada se comunica con el controlador a través de un puerto serie y, si es necesario, imita situaciones de recibir supuestamente "dinero". También es necesario tener algún tipo de grupo de cuentas o proveedores de prueba, cuyos pagos no serán procesados de verdad, pero en algún momento serán rechazados. O, para casos más complejos, el dinero realmente pasa por un procesamiento real, pero llega a cuentas especiales, de las cuales nuevamente se debitarán las pruebas de pago.

Tal es el ciclo del dinero en la naturaleza.

Impresora de recibos (arriba) y aceptador de facturas (abajo).

24/7

El software para terminales y cajeros automáticos debe ser extremadamente resistente a diversas situaciones de emergencia: falta de Internet, problemas con un aceptador de billetes, etc. Dado que dicho software se ejecuta en un terminal con una prioridad y derechos muy altos, esencialmente intercepta todo el control del sistema operativo. No puede simplemente contraerlo o cerrarlo con Alt-F4. El software puede reiniciarse y el terminal, incl. En un bucle También es necesario verificar estos escenarios estresantes, por ejemplo, la falta de conexión con el procesamiento de pagos. El terminal responde a esto con reinicios periódicos, debe verificar que lo hace correctamente y correctamente cada vez que carga el software del terminal.

Instalación desde cero y actualización

El software del terminal instalado se actualiza centralmente mediante el procesamiento de pagos. Processing planea actualizar un terminal específico y determina el perfil de actualización para él, es decir, qué archivos y dónde cargar. Para actualizar, es necesario realizar una serie de procedimientos en la base de datos de procesamiento y luego monitorear el terminal. Compruebe mediante registros que la descarga de los archivos necesarios haya comenzado y que la actualización se haya completado con éxito y que el software del terminal haya aumentado.

Una instalación limpia desde cero es más difícil. Por lo general, una persona lo hace en los campos simplemente copiando el archivo de instalación en el terminal e ingresando la configuración y los datos de autorización en los formularios del instalador, que generalmente es una aplicación WinAPI con controladores estándar de Windows (TextBox, CheckBox, etc.).

En nuestras pruebas automáticas para una secuencia de comandos de instalación limpia, se adjunta una secuencia de comandos Python al terminal, que el instalador inicia, interactúa con los controladores con la biblioteca pywinauto y escribe su propio registro de instalación. Una vez que se completa la primera etapa de la instalación, el script finaliza y el software del terminal pasa la autorización en el proceso, recibe rutas al perfil de instalación y descarga todos los archivos necesarios. Aquí, en tiempo real, debe monitorear los registros en el terminal a través de SSH. Se escriben todas las situaciones anormales durante la instalación (por ejemplo, datos de autorización incorrectos), debe leer estos registros en línea y, si es necesario, considerar que la prueba de instalación limpia falló.

Instalación limpia desde cero MarATL

Conclusión

Repasamos las descripciones generales sobre los principales aspectos técnicos de la creación de pruebas automáticas para software de terminal. Sin sumergirnos profundamente en la tecnología, clasificamos una gran tarea en aspectos separados. Haga preguntas en los comentarios, si el tema es interesante, puede resaltar algunos puntos en un artículo separado con más detalle. ¡Gracias por la atención!

Software de prueba de automatización terminales QIWI