java user-interface testing sikuli

java - ¿Alguien ha usado SIKULI para probar sus aplicaciones basadas en GUI?



user-interface testing (12)

@jordan, Absolutley spot on ''Usar Sikuli correctamente significa que no está siguiendo un modelo de "grabación y reproducción". Por el contrario, tiene que abordar el desarrollo de la automatización de pruebas con Sikuli, como lo necesita con todas las herramientas, como una tarea de desarrollo de software.

Creé una solución de automatización de prueba integral para probar una aplicación de videoconferencia hecha por el fabricante de PC más grande del mundo. No entendieron que era un proyecto de desarrollo completo, no una operación de apuntar y hacer clic que cualquier mono pudiera ejecutar. Tratar de explicar los desafíos de la codificación con un lenguaje de tipado dinámico era imposible.

Desde mi experiencia, el mayor desafío es la gestión de la imagen. Usé el sistema de archivos y el configurador de configuración para la primera iteración de la automatización de prueba. Usar configparser funcionó, sin embargo, fue difícil de implementar. En el futuro, planeo usar blobs. Sikuli no es compatible con la extracción directa de imágenes de una base de datos (aún), aunque sí tengo una solución alternativa.

El uso de un IDE es crítico ya que el IDE de Sikuli no tiene herramientas de desarrollo. Los 2 IDE que he configurado, NetBeans y Eclipse / PyDev tienen su propio conjunto de problemas. Son excelentes para la codificación, sin embargo, los errores falsos, la inyección de espacio en blanco y la pérdida de código no son ideales. Codigo y pruebo en NetBeans, Ejecuto en SikuliIDE y guardo todo en el bloc de notas como copia de seguridad.

A pesar de las dificultades encontradas, soy un gran partidario de Sikuli. Sikuli tiene el potencial de cambiar la automatización de las pruebas, haciéndola accesible a toda la comunidad de QA sin tener que ser un codificador de OO.

SIKULI parece tener una enorme cantidad de potencial. ¿Alguien ha tratado de usar esto como una herramienta para probar? ¿O sería más adecuado para automatizar acciones para los usuarios?

Acabo de publicar mi propio marco para la prueba de aplicaciones GUI usando Skikuli + RobotFramework.

SikuliFramework proporciona una abstracción orientada a objetos sobre Sikuli para ayudar a interactuar con los elementos de la GUI, como conjuntos de botones, casillas de verificación, botones de radio, ventanas y jerarquías de diálogo para la automatización y prueba de GUI. También tiene una estrecha integración con RobotFramework.

https://github.com/smysnk/sikuli-framework

Citando pruebas unitarias para GUI (en la Documentation del proyecto):

Sikuli está diseñado para soportar pruebas unitarias para GUI al integrarse con junit. El panel de pruebas de la unidad se puede abrir haciendo clic en Ver / Prueba unitaria o mediante el acceso directo Cmd-U en Mac (o Ctrl-U en Windows / Linux).

Entonces, aunque tengo entendido que SIKULI está inicialmente dirigido a la automatización de GUI, definitivamente puede usarse para pruebas GUI (que está estrechamente relacionado si se tiene en cuenta la prueba GUI = Automatización GUI + marco de verificación). Eche un vistazo a las pruebas unitarias para GUI (JEdit) para ver un ejemplo completo (y vea el assertXXX en las imágenes).

Y, de hecho, veo un gran potencial en SIKULI para las pruebas, ya que parece hacer que las pruebas de escritura sean muy fáciles, incluso sin una sola línea de la aplicación real escrita (simplemente usando algunas maquetas iniciales, por ejemplo). SIKULI podría convertirse en un gran compañero para varios sabores de pruebas (BDD, pruebas de aceptación, etc.).

Es realmente una increíble pieza de software, muy impresionante.

De hecho, estoy escribiendo un marco para pruebas GUI / manejo de errores con sikuli. Es genial.

Este video menciona que "tolera un poco de cambios [sic] en su apariencia". Soy cauteloso del esfuerzo requerido cuando los cambios exceden "un poco". La interfaz es impresionante, pero un número excesivo de falsos positivos podría retrasar fácilmente las pruebas.

Estoy utilizando Sikuli extensivamente para la automatización de la prueba de IU. Llego "tarde" a la fiesta de Sikuli, habiéndolo descubierto en enero de 2011. De hecho, me alegro de haberlo descubierto tarde, porque si bien fue prometedor antes, no creo hasta que Sikuli x1.0-rc1 (lo que ocurrió en diciembre) ) fue lanzado que estaba listo para el horario estelar.

Anteriormente, utilicé TestQuest y EggPlant para la automatización de pruebas de IU. En mi opinión, Sikuli les gana a ambos con las manos hacia abajo. Realmente creo que tiene el potencial de cambiar drásticamente la forma en que la gente realiza la automatización de la prueba UI para mejor y la evangelizará a las personas que me rodean.

Usar Sikuli correctamente significa que no está siguiendo un modelo de "grabación y reproducción". Por el contrario, tiene que abordar el desarrollo de la automatización de pruebas con Sikuli, como lo necesita con todas las herramientas, como una tarea de desarrollo de software.

Actualmente estamos en el proceso de portar un DSL de automatización de IU (lenguaje específico de dominio) que creamos para EggPlant a Sikuli. Una de las características clave que aprovecharemos en nuestra DSL es la capacidad de reconocimiento de texto de Sikuli. Esto nos permitirá ejecutar el mismo script en varias versiones localizadas de nuestro producto.

Debido a que Sikuli se basa en OpenCV (para reconocimiento de imágenes) y tesseract-ocr (para reconocimiento de texto) , tiene una increíble cantidad de potencia y flexibilidad.

Grabado un flujo de trabajo con una aplicación web Flex. Tomó un tiempo descubrir una estrategia confiable para crear capturas de pantalla, pero una vez que lo hice, el script siguió funcionando incluso después de que cambié mi combinación de colores de escritorio. Sin embargo, la sintaxis se torna un poco incómoda cuando necesita hacer clic en un control específico en una colección de controles similares, es decir, casillas de verificación, campos de entrada. Parece que la única forma de hacerlo es mediante el uso de find() en combinación con right(); left(); inside() right(); left(); inside() right(); left(); inside() . Parece que cuanto más pequeñas son las capturas de pantalla, más confiablemente se detectan. Una buena práctica sería incluir solo objetos significativos en capturas de pantalla, y hacerlos tan atómicos como sea posible, pero sin comprometer su singularidad.

Para una menor automatización de prueba centrada en desarrollador para Sikuli, también echa un vistazo a RobotFramework.org. Hay un tutorial sobre cómo hacer una biblioteca de pruebas Sikuli (personalizada) para Robot Framework

http://blog.mykhailo.com/2011/02/how-to-sikuli-and-robot-framework.html

y también creé una versión genérica simple

http://code.google.com/p/simplesikuli

Y si alguna vez hubo limitaciones para Sikuli en términos de manejo de ventanas, controles de GUI, interacción con el mouse y el teclado, siempre puedes complementarlo con otra gran herramienta gratuita de prueba: AutoIt. AutoIt por sí solo también tiene limitaciones, cuando se combina con Sikuli, compensan las deficiencias de cada herramienta, para reemplazar las herramientas de prueba GUI de grado comercial.

Sikuli se basa en la coincidencia de imágenes estáticas. Por lo tanto, solo es adecuado para situaciones en las que la GUI es suficientemente estable. Para la GUI dinámica, como la animación o la GUI, que incluye algún tipo de aleatoriedad, no es aplicable.

Y Sikuli solo cubre la parte visual de la prueba. No tiene idea si el estado interno es de hecho como se esperaba.

Utilicé sikuli para las pruebas GUI, también pude integrarlo con HUDSON.