En Alfastrakhovanie, utilizamos SAP ERP como un sistema de liquidación de pérdidas de proceso. Y sucedió que lo estamos finalizando un poco, esto inevitablemente conduce a errores en el código. Si los errores alcanzan un sistema productivo, esto es malo. Esto debe evitarse, una forma es la prueba de regresión. En este artículo hablaré exactamente sobre cómo llevamos a cabo la "regresión" para SAP, porque lo hacemos (¡oh!) No estándar.
Todo comenzó hace unos años. En esos años, ya utilizamos activamente las pruebas de regresión, pero no pudimos hacerlo en SAP: las herramientas utilizadas no funcionaban con SAP, el equipo de prueba no quería estudiar las herramientas "afiladas" para SAP. No recuerdo exactamente por qué, pero lo tomé como un desafío (fue incluso antes de cambiar a ingeniería de fecha) y decidí "estudiar" el problema.
Los resultados del estudio (además de "hacer"): en este artículo (a continuación), diré brevemente esto: probamos automáticamente SAP (y su entorno inmediato), lo hacemos con bastante eficacia (en todos los sentidos), no gastamos un solo rublo en licencias y formación, nuestro enfoque es simple y totalmente reproducible. Y no utilizamos ninguna herramienta de SAP para las pruebas automáticas de SAP (excepto en el lugar donde incorporamos su sistema de transporte).
Grandes trazos
Existe el peligro de entrar en detalles y perder lectores, intentaré no hacerlo (como autor, conozco todos los detalles).
Todo comenzó con el estudio, la comunicación con SAP, nuestros socios y el Sr. Google.
El resultado de esta comunicación fue el siguiente:
- SAP tiene herramientas para probar la automatización (analizamos eCATT, de cerca SAP CBTA)
- requieren una inmersión sustancial (especialmente SAP CBTA)
- pueden ser necesarias restricciones, si es necesario, ir más allá de los límites de SAP (él no está en un "vacío" con nosotros)
- hay productos de terceros (por ejemplo, HP), pero no tenemos competencias para ellos, al igual que compramos licencias
- hay una manera de "administrar" SAP desde el exterior (la empresa Convista me contó esta idea, muchas gracias por ello)
Como personalmente no tenía conocimiento de SAP, decidí intentar cavar en la última dirección: administrar SAP no es de SAP. El Sr. Google proporcionó rápidamente el documento "API de secuencias de comandos GUI de SAP para las plataformas Windows y Java", que sirvió como un gran comienzo para esta iniciativa. Una prueba rápida en mi python favorita mostró que funciona.
Luego, era un asunto pequeño: encontrar un marco adecuado para la automatización de pruebas. Dado que Python era mi lenguaje favorito, Robot Framework se puso rápidamente en consideración. Y, de hecho, después de que entró en la lista y fue juzgado, solo él permaneció en la lista. Sobornado por el hecho de que "eso" funcionó de inmediato (mirando hacia el futuro, y todavía funciona, no me arrepiento ni un minuto de mi elección).
Un pequeño piloto mostró que SAP está perfectamente "controlado" por un robot (llamaré Robot Framework esa palabra rusa): de forma rápida, sincrónica, predecible y confiable. Al mismo tiempo, enfatizo, utilizamos la forma documentada de SAP de interactuar con la GUI de SAP (no una especie de "muletas").
Arquitectura
(sí, déjame usar esta palabra aquí)
Cómo funciona
- el script se ejecuta en el servidor (la palabra "servidor" se usa aquí en el sentido de que esta computadora atiende nuestras solicitudes de prueba. En este caso particular, es más correcto usar la palabra "cliente" porque es el script que controla el proceso de prueba)
- a través del mecanismo estándar del robot Remote, el script interactúa con el componente del servidor del robot que se ejecuta en SUT (sistema bajo prueba)
- este componente del servidor llama a los métodos de la biblioteca de administración de SAP
- SAP GUI procesa estas solicitudes (sincrónicamente, esto es importante)
- los resultados de la ejecución de consultas o simplemente "latidos" se devuelven al script en el "servidor", donde se utilizan en las pruebas
Técnicamente
- "servidor" es una máquina virtual bajo Ubuntu
- SUT: la estación de trabajo donde está instalada y configurada la estación de trabajo SAP (en nuestro caso, es una computadora con Windows o una máquina virtual)
- la biblioteca de administración de SAP está escrita en python (hay algunas, un par de cientos de líneas)
- "script" es un "programa" en un lenguaje entendido por Robot Framework
- el robot (como tal) implica una línea de comando, ya que los desarrolladores de ABAP no están acostumbrados, hice una interfaz WEB que proporciona, en particular, trabajo colectivo (al respecto un poco más tarde).
Que es maravilloso
En realidad, ¿qué obtuvimos, excepto por la falta de carga de licencias?
Muchas cosas, aunque brevemente y sobre lo principal:
Idioma ruso
El guión se parece a esto:
Al comienzo del viaje (probablemente durante el piloto), pensé, ¿y que vamos a romper la lengua y encontrar algunas palabras incomprensibles, incluso para nosotros mismos? El robot implica la creación de sus propias palabras clave (perdón por la terminología, esto es lo que él llama). Entonces, ¿por qué no los inventamos de inmediato en ruso? Preguntó en la comunidad de probadores (en algún lugar de las entrañas de Internet): me "molestaron": es peligroso, por qué, quién lo dijo, etc. Seguí mi propio camino: tenemos todo en ruso (las variables, las palabras, solo las estructuras de control del robot permanecen, pero deben estar ocultas dentro de las palabras clave; si ves inglés, entonces es hora de refactorizar).
¿Qué tiene de bueno el idioma ruso? (Excepto por la comprensibilidad sin un diccionario): el script se puede mostrar a un especialista que no sea de TI, una persona de negocios. Puedes escribir este script directamente con él (ni siquiera intentaré entrar en el tema ATDD aquí; esta es una publicación separada y grande, la escribiré algún día).
Control total y total y extensibilidad
Sé exactamente lo que sucede durante el proceso de prueba. No hay magia en absoluto, todo está extremadamente claro. No sé cómo alguien, eso me gusta.
Acerca de la extensibilidad: la funcionalidad se puede desarrollar en cualquier dirección, que utilizamos activamente:
- Me las arreglé para crear mi propio "lenguaje" de scripts de prueba, comprensible para los negocios
- fue posible verificar automáticamente si los campos en la interfaz se completaron correctamente al final de la prueba (para esto, en particular, dividimos las variables del robot en parámetros de inicio y parámetros de interfaz, permitimos determinar qué elemento de interfaz debería tener qué parámetro de inicio)
- se pueden agregar puntos de interrupción a las pruebas; durante los puntos de interrupción, observe los valores de las variables
- Implementamos un mecanismo para crear plantillas de archivos y ponerlas en el proceso de ejecución; sin esto, probar un animal como un VLP sería imposible (y lo probamos en un modo completamente automático, desde generar una aplicación hasta analizar un extracto)
La presencia de nuestra propia interfaz web agregó más opciones de expansión, por ejemplo, podemos permitirnos modificar el lenguaje del robot (se nos ocurrió, por ejemplo, nuestro operador condicional, a nosotros y a nuestros usuarios comerciales no nos gustó la palabra clave "Ejecutar palabra clave si"). Esto fue posible porque una aplicación web genera archivos con código fuente de prueba para el robot.
Facilidad de entrada
Como regla, los evaluadores no tienen conocimiento de la infraestructura de SAP y, especialmente, de la programación de SAP. Se las arreglan para dominar el robot y nuestras mejoras en un par de semanas.
Instrucciones de uso
También recurrimos a "Nuestro William ..." - a la documentación. No es ningún secreto para nadie: por lo general, no hay documentación para el sistema, e incluso si la hay, se vuelve obsoleta rápidamente. Los usuarios pasan las reglas de trabajo con el sistema "boca a boca". Si el código de prueba automática es una descripción de cómo usar el sistema según el autor, entonces ¿por qué no convertirlo en una instrucción?
Por supuesto, los detalles son difíciles de ver en este fragmento, es importante que la instrucción se genere y actualice en un modo totalmente automático, incluidas las capturas de pantalla. La instrucción siempre está actualizada (porque las pruebas automáticas siempre funcionan). En el caso de SAP, las capturas de pantalla generalmente son bien recibidas: en SAP siempre puede encontrar un elemento de interfaz, un rectángulo cuyas coordenadas serán relevantes para el lugar actual en el código de prueba, este control (invisible para el ojo) se usa como parámetro de la palabra clave "tomar una captura de pantalla" (esta palabra , por supuesto, solo funciona con el modo de inicio de prueba apropiado, ¿por qué gastar electricidad así?
Formateamos las instrucciones usando Sphinx (estoy seguro de que muchos han aprendido el esquema de color), por lo tanto, están disponibles tanto en el manual en línea como en forma impresa.
Un poco sobre Robot Framework
Sin embargo, no se puede decir nada sobre el robot: resultará demasiado incomprensible y superficial. Lo intentaré brevemente.
La idea principal de este marco es la capacidad de crear su propio lenguaje de prueba (en la terminología del robot, la unidad ejecutable es la palabra clave: la palabra clave). El marco proporciona
- entorno de ejecución del programa (programadores - no se ofenda) en este lenguaje
- bibliotecas funcionalmente ricas (desde trabajar con cadenas y listas hasta ssh y selenium)
- informes (en el proceso de uso, ni siquiera se pensó en escribir ningún tipo de informe)
- un paradigma simple de formar un programa a partir de palabras clave (un poco peculiar, pero puede acostumbrarse a él), existen variables, parámetros y resultados de "llamadas" (palabras clave)
- extensibilidad simple y potente: es muy simple crear su propia biblioteca en python (por ejemplo, trabajamos de esta manera con Excel), tanto local (es decir, ejecutada en el mismo lugar que el código de prueba) como remota (por ejemplo, que controla la GUI de SAP)
El proceso de crear una prueba es bastante sencillo
- formamos una secuencia de acciones y la traducimos a términos de un robot (un poco más abajo será específico sobre la interacción con el sistema bajo prueba)
- secuencias repetitivas refactorizadas en sus (nuevas) palabras clave
- ejecutar la prueba, ver cómo funciona, arreglar, mejorar
- la depuración es proporcionada por puntos de interrupción (con la capacidad de ver variables - es proporcionada por la arquitectura, más precisamente - el uso de la biblioteca remota del robot)
El resultado ni siquiera es un programa (ver ejemplos anteriores), sino más bien una secuencia formal de acciones, que, por cierto, describe el uso del programa en la forma que el autor pretendía (ver ATDD arriba).
Interacción con el sistema bajo prueba.
En nuestro caso, probamos en el nivel de la interfaz de usuario (es decir, nuestras pruebas interactúan con el SAP en el nivel de la GUI: hacen clic en los botones, completan los campos de texto, etc.). En general, se acepta que esta forma de escribir exámenes no es la mejor. Estoy parcialmente de acuerdo con esto, pero estoy listo para escuchar y discutir cómo probar las aplicaciones SAP GUI (como nuestro SAP FS CM).
Existe tal gurú, Robert Martin (también conocido como "tío Bob", el autor de "Codificador limpio", si alguien leyó), nos correspondimos un poco sobre esto. Acordaron que si no es muy difícil de hacer, no cambia con mucha frecuencia (pruebas de ruptura), entonces está bien, también puede probar a través de la interfaz.
Por mi parte, puedo decir esto: en el caso de la GUI de SAP, no hay muchas opciones para implementar la interfaz de usuario. Si necesita agregar la capacidad, por ejemplo, para rastrear el código IMEI, puede hacerlo de casi una manera: agregando el campo apropiado a uno de los marcadores. Así que creo que todos los matices de esta "adición" pueden y deben ser pensados por el cliente (cómo se llamará a este campo en la interfaz, ancho, orden de uso, etc.). Y puede hacerlo directamente en un script, que luego lo probará automáticamente. Si no puede pensar en una revisión hasta el final (como dicen, bueno, hágalo y ya veremos), entonces es mejor no hacer esta revisión. Y hacer lo que puedas pensar. Bueno, me metí en ATDD otra vez ...
Volviendo a la interacción con la GUI de SAP: gestionamos, como ya escribí, unas 200 líneas en python y unas 10 funciones de gestión de interfaz diferentes (como "ir al marcador", "completar el campo", "presionar el botón"). Este conjunto se formó casi en los primeros días y posteriormente no se expandió mucho. Para crédito de SAP, observo que todo funciona muy rápido: el ojo no tiene tiempo para realizar un seguimiento de cómo la interfaz "parpadea", se insertaron retrasos en el ciclo de control para disminuir la velocidad (en casos en los que es necesaria la supervisión visual). También noto las ventajas de la operación síncrona: en ninguna parte del código tiene que esperar nada, si, por ejemplo, se presiona el botón, entonces la acción correspondiente al clic del botón se ha completado (por ejemplo, la pérdida se ha guardado).
def get_ctrl_attr ( self, uid, attr ): """ ( ) ( ) exception = ( log) """ ctrl = self._get_ctrl(uid) try: retText = getattr( ctrl, attr ) except: raise AssertionError(" {1} {0}".decode("utf-8").format(attr,uid)) return retText
Algunos comentarios sobre el código
- fragmento de la biblioteca de gestión SAP GUI
- la biblioteca es un objeto, los métodos están directamente disponibles en las pruebas (en palabras clave), por ejemplo, el método anterior se puede llamar así: "res = get ctrl attr $ {UID} text" (usando notación de robot)
- en caso de error, el texto de excepción será visible en el registro del robot (no necesita hacer nada para esto, solo "matar" la excepción
El código es muy simple, le agrada.
Ejecutando pruebas
Siguiendo la lógica del robot, las pruebas individuales se combinan en nuestros proyectos. Una prueba o proyecto se puede iniciar manualmente desde la interfaz web. El proceso de prueba de regresión también está integrado en el sistema de transporte de SAP:
- el propietario del producto al final de la fase de prueba comercial aprueba las solicitudes de transporte para la transferencia
- las solicitudes aprobadas "se trasladan" una a la vez al entorno de preproducción, donde, de acuerdo con la configuración, uno u otro conjunto de pruebas (más precisamente, proyectos)
- Si el resultado de la prueba es positivo, la solicitud se libera y "va" al entorno de producción.
- Cuando se producen errores, al autor de la solicitud se le envía una carta con un enlace al informe de prueba (generado por el robot), la solicitud no va más allá
Importante: la interfaz web reduce significativamente el umbral para ingresar al proceso de prueba: para comenzar la prueba es simple: haga clic en el botón "Inicio". Al mismo tiempo (debido al uso de Robot Framework), se conservan todas las ventajas de la representación de archivos de las pruebas (control de versiones, línea de comandos y automatización relacionada, etc.).
No sap om
Aplicamos con éxito nuestro desarrollo para probar no solo la GUI de SAP, tuve un pequeño desarrollo (interfaz de registro de pérdida simplificada) en python y django. Como ya habíamos implementado todos los puntos básicos, todo lo que tenía que hacer era escribir una biblioteca de administración del navegador (lo mismo que tenía que administrar la GUI de SAP, solo a través de Selenium). Y resultó genial:
- las pruebas aún funcionan en la máquina virtual Linux (en la misma, las pruebas SAP y no las pruebas SAP viven en la misma "instancia")
- el navegador "parpadea" en el lugar de trabajo del probador (control visual completo sin ningún truco)
- informes estándar, herramientas familiares
En las pruebas de este sistema, fui más allá (hacia ATDD): inicialmente se formaron elementos visualmente visibles (etiquetas y marcadores de posición) en las pruebas, allí acordaron con el negocio y desde allí "cayeron" en el código fuente del sistema en sí (resultó un poco SECO): no se puede escriba el código sin escribir primero la prueba. Genial
Por supuesto, se han desarrollado muchas herramientas para aplicaciones web, pero no puedo decir que haya tenido inconvenientes durante el trabajo. Resultó bien aquí ...
Para resumir
El mundo de SAP es grande y parece tener todo lo necesario para la felicidad completa de los desarrolladores. Pero esto no significa en absoluto que deba caminar solo por los caminos que SAP y su ecosistema han "recorrido". Es útil al comienzo del camino hacerse la pregunta: ¿definitivamente quiero hacer "como todos los demás"? Nosotros en Alfastrakhovanie le preguntamos a nosotros mismos, y no solo en TI.
Y, una vez más, todo es posible en la programación, la pregunta es solo tiempo y dinero (motivación).