SIKULI parece tener un enorme potencial. ¿Alguien ha tratado de usar esto como una herramienta para probar? ¿O sería más adecuado para automatizar acciones para los usuarios?¿Alguien ha usado SIKULI para probar sus aplicaciones basadas en GUI?
Citando Unit Testing for GUI (en el proyecto Documentation):
Sikuli está diseñado para soportar la unidad de pruebas para GUI mediante la integración 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).
Así, mientras que mi entendimiento es que Sikuli está dirigida inicialmente a la automatización de interfaz gráfica de usuario, que sin duda puede ser utilizado para las pruebas de interfaz gráfica de usuario (que está estrechamente relacionado, si tenemos en cuenta que las pruebas de interfaz gráfica de usuario GUI + = automatización marco de verificación). Eche un vistazo a Unit testing for GUI (JEdit) para ver un ejemplo completo (y vea assertXXX en las imágenes).
Y de hecho, veo un gran potencial en SIKULI para las pruebas, ya que parece hacer las pruebas de escritura 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.
Este video menciona que "tolera un poco de cambio [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.
También, ver el documento: http://groups.csail.mit.edu/uid/projects/sikuli/sikuli-chi2010.pdf
registró 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 usando find() en combinación con 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.
Estoy utilizando Sikuli ampliamente 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, he utilizado TestQuest y EggPlant para la automatización de pruebas UI. 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.
Uso Sikuli correctamente es decir que son no 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 del 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.
Porque Sikuli se basa en OpenCV (for image recognition) y tesseract-ocr (for text recognition), tiene una increíble cantidad de potencia y flexibilidad.
@jordan, Absolutamente en el lugar "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 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.
Según 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 cuenta con 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 seguidor 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.
He aquí mi opinión sobre la maravilla de Sikuli para la automatización de pruebas: http://pculture.org/devblogs/mirotesting/2011/06/24/using-sikuli-to-automate-miro-testing/
Tengo un conjunto de pruebas multi-plataforma fiable para Miro.
De hecho estoy escribiendo un marco para la prueba GUI/manejo de errores con sikuli. Es genial.
¿Cuál es el estado de este marco? –
Para una menor automatización de prueba centrada en desarrollador para Sikuli, también consulte RobotFramework.org. Hay un tutorial sobre cómo hacer una biblioteca de prueba (personalizado) Sikuli para Robot Framework
http://blog.mykhailo.com/2011/02/how-to-sikuli-and-robot-framework.html
y he creado una versión genérica simple también
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 de mouse y 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.
He utilizado sikuli para pruebas GUI, también he podido integrarlo con HUDSON.
Acabo de publicar mi propio marco para la prueba de aplicaciones GUI usando Skikuli + RobotFramework.
SikuliFramework proporciona una abstracción orientada a objetos en la parte superior de 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 GUI. También tiene una estrecha integración con RobotFramework.
Sikuli se basa en la comparación 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.
Bueno, mi entendimiento es que es el uso de reconocimiento de patrones, así que supongo que más de un "pequeño" cambio requerirá cambiar la correspondiente captura de pantalla de la GUI en consecuencia. No esperaría nada más. (Estoy de acuerdo en que la refactorización no será una fortaleza de la herramienta). –
En la herramienta es muy fácil cambiar el nivel de tolerancia, simplemente haga clic en la imagen y use la GUI para ajustar el número de coincidencias y ajustar el control deslizante para tolerancia, de 1 (coincidencia perfecta) a 0, que es una coincidencia excepcionalmente difusa. Un 0.82 por ejemplo ignorará el efecto de pista caliente de la barra de tareas de Windows 7. –
El nivel de coincidencia predeterminado es 0,7, pero puede cambiarlo mediante una prueba completa agregando la configuración global: 'Settings.MinSimilarity = 0.9' en la parte superior de su código. Más información [aquí] (http://sikuli.org/docx/globals.html#Settings). –