¿Qué problema resuelve la prueba automatizada de la interfaz de usuario?

Actualmente estamos investigando las pruebas automatizadas de la interfaz de usuario (actualmente hacemos pruebas automatizadas de unidades e integración).

Hemos analizado Selenium y Telerik y nos hemos decidido por esta última como la herramienta elegida debido a su grabadora mucho más flexible, y realmente no queremos que los evaluadores escriban demasiado código.

Sin embargo, estoy tratando de entender el beneficio general. ¿Cuáles son las opiniones de las personas y qué tipo de cosas funcionan bien y qué no?

Nuestro sistema está en constante desarrollo y lanzamos regularmente nuevas versiones de nuestra plataforma (basada en la web).

Hasta ahora, el principal beneficio que podemos ver es para las pruebas de regresión, especialmente en las implementaciones de clientes múltiples de nuestra plataforma.

Realmente buscando las opiniones de otras personas. "Pensamos" que es lo correcto, pero en un horario ya ocupado estamos buscando información adicional.

Cuando mi equipo implementó las pruebas automatizadas de IU, sucedieron muchas cosas geniales.

Primero, el equipo de control de calidad se volvió mucho más eficiente en la prueba de la aplicación, así como más competente con la aplicación. El QA principal dijo que fue capaz de poner al día a los nuevos miembros de QA rápidamente al presentarles las suites de prueba para la interfaz de usuario.

En segundo lugar, la calidad de los boletos de control de calidad que regresaron al equipo de desarrollo fue mejor. En lugar de 'La página se rompió cuando hice clic en el botón Enviar', obtuvimos el caso exacto que falló para poder ver lo que se ingresó en el formulario. El equipo de control de calidad también dio un paso más al verificar todos los casos que fallaron y probar otros escenarios alrededor de esa página para darnos una mejor visión de lo que sucedió.

Tercero, el equipo de control de calidad tuvo más tiempo. Con este tiempo extra, pudieron participar en más reuniones de diseño. Esto a su vez les permitió escribir los nuevos casos de la suite de pruebas al mismo tiempo que los desarrolladores codificaban esas nuevas características.

Además, las pruebas de resistencia que el conjunto de pruebas que utilizamos valió su peso en oro. Sinceramente, me ayudó a dormir mejor por la noche sabiendo que nuestra aplicación podría soportar casi cualquier cosa que se le arroje. Encontramos bastantes páginas que resistieron bajo presión que pudimos arreglar antes de lanzarlas. Simplemente perfecto.

Lo último que encontramos fue que con algunos ajustes del equipo de control de calidad, también podríamos hacer algunas pruebas de inyección SQL en nuestra aplicación. Encontramos algunas vulnerabilidades que pudimos solucionar rápidamente.

La configuración del conjunto de pruebas de IU tomó una buena cantidad de tiempo. Pero, una vez allí, se convirtió en una parte central de nuestro proceso de desarrollo.

Las pruebas de IU automatizadas son las pruebas de integración real . Prueban todo el sistema de la forma en que realmente se usa cuando está en vivo. Eso los convierte en las pruebas más significativas. Sin embargo, también tienden a ser los más frágiles y los más lentos de ejecutar.

Esté atento a la relación costo / beneficio (con la fragilidad como parte del costo) y no dude en hacer algunas cosas que se prueban solo manualmente (pero asegúrese de que se prueben). Y si es posible, haga posible que los desarrolladores ejecuten partes específicas del conjunto de pruebas de IU en su versión de la aplicación que se ejecuta localmente, para que puedan beneficiarse de las pruebas durante el desarrollo.

Obviamente, es imprescindible que las pruebas se ejecuten automáticamente en un servidor de compilación (al menos una vez al día).

Realmente no queremos que los evaluadores escriban demasiado código.

OMI, esto es un sueño imposible. Crear pruebas automatizadas es escribir código. Funcionalidad de grabación puede ayudarle a escribir un poco de ese código más rápido y empezar más rápidamente con la escritura de forma manual (y ralentizar mucho si se le pasa el punto en el código de la escritura se vuelve más rápido manualmente), pero en última instancia código escrito manualmente es lo que va a acabar haciendo mucho Espero que su marco de prueba lo admita bien y que su desarrollo no se haya centrado demasiado en el sueño (muy vendible) de permitir que las personas que no pueden escribir código produzcan pruebas automatizadas.

y realmente no queremos que los evaluadores escriban demasiado código

Tomamos el enfoque opuesto. Nos queríamos los probadores de la escritura de código.

Aquí está el flujo de trabajo que comenzamos a adoptar. No es fácil hacer esto porque la administración no depende absolutamente de las pruebas automatizadas del front-end. Están dispuestos a conformarse con "lo suficientemente cerca".

1. Historias de usuarios.

2. Concepto operacional. Cómo funcionaría la historia. Revisión de diseño.

3. Boceto de pantalla: diseño de interfaz de usuario. Cómo se vería.

4. Selenium Scripts. Si todos los scripts funcionan, hemos terminado con el lanzamiento.

5. Codificación y prueba hasta que el guión funcione.

Las pruebas automatizadas son la única forma de demostrar que existe la funcionalidad.

Las pruebas manuales son propensas a errores y están sujetas a la anulación de la administración: "es lo suficientemente bueno, esas pruebas fallidas realmente no importan tanto como lanzar esto a tiempo".

"Cualquier función de programa sin una prueba automatizada simplemente no existe".

La presentación visual es otra historia. La prueba manual de un diseño visual es un caso excepcional porque puede involucrar un juicio estético o examinar problemas específicos (pequeños) en una pantalla de píxeles muy grande y compleja.

Hasta ahora, el principal beneficio que podemos ver es para las pruebas de regresión, especialmente en las implementaciones de clientes múltiples de nuestra plataforma.

Automatizar sus pruebas de regresión es algo bueno. Esto libera a sus evaluadores para hacer un trabajo más interesante, ya sea agregando más pruebas automatizadas, pruebas de esfuerzo de su aplicación o cualquier otra cantidad de cosas.

Además, al automatizarlo, puede hacer que sus desarrolladores ejecuten las pruebas y, por lo tanto, eviten que los problemas solo se descubran más adelante en el proceso.

Hemos analizado Selenium y Telerik y nos hemos decidido por esta última como la herramienta de elección debido a su grabadora mucho más flexible

No estoy seguro de cuánto lo has investigado. Ciertamente, también hay otras opciones. ¿Has mirado a Watir , WatiN , Sikuli por nombrar algunos?

y realmente no queremos que los evaluadores escriban demasiado código.

Me siento mal por las personas que tienen que mantener estos guiones. Con mayor frecuencia, sin un código que pueda modificarse fácilmente, los scripts se vuelven frágiles y comienza a tomar más tiempo modificar el script que volver a grabarlo, lo que desperdicia aún más tiempo.

Sin embargo, estoy tratando de entender el beneficio general. ¿Cuáles son las opiniones de las personas y qué tipo de cosas funcionan bien y qué no?

La automatización de pruebas es algo hermoso cuando se hace correctamente. Ahorra tiempo en las pruebas / verificaciones de regresión para dar a sus evaluadores más tiempo para hacer lo que mejor hacen, prueba. Sin embargo, no crea por un momento que es una bala de plata. Los scripts de automatización requieren mucho tiempo para desarrollarse si la aplicación ya existe pero las pruebas no, y requieren una actualización constante con cada versión. Las pruebas automatizadas también son una excelente manera para que las personas nuevas del equipo vean cómo se supone que debe comportarse el sistema. Además, asegúrese de que sus evaluadores decidan qué necesita ser automatizado. Si es un cheque pequeño que no requiere mucho control, es muy monótono y fácil de automatizar, comience con eso. Siempre comience con las comprobaciones que obtienen más a través de la automatización y trabaje desde allí.

Hasta ahora, el principal beneficio que podemos ver es para las pruebas de regresión, especialmente en las implementaciones de clientes múltiples de nuestra plataforma.

Es el beneficio principal, y si está configurado correctamente, puede probar la mayoría de los navegadores que necesitaría con un pequeño cambio de configuración.

"Pensamos" que es lo correcto, pero en un horario ya ocupado estamos buscando información adicional.

Como dije anteriormente, la automatización de pruebas requiere esfuerzos considerables, sin embargo, cuando se hace correctamente, aún no he conocido a un equipo que haya dicho "Ojalá no hubiéramos configurado nuestra automatización de prueba".

Tienes razón en que la regresión es enorme. También -

• Si sus pruebas están escritas de forma modular, puede obtener más por la combinación de conjuntos de pruebas.

• Hemos reutilizado los scripts de prueba automatizados para la carga de datos para que no tengamos que cargar una base de datos para realizar pruebas de gran tamaño.

• prueba de rendimiento

• pruebas de subprocesos múltiples

• en sistemas web: intercambio entre navegadores e intercambio entre sistemas operativos. Con problemas de consistencia del navegador, alcanzar una base lo más amplia posible es una gran cosa.

Cosas que debe omitir, especialmente en los sistemas web, tenga cuidado con los casos en que los elementos de su pantalla se crean con identificadores dinámicos y cambiantes, a menudo los scripts de prueba automatizados no manejan esto bien, y es posible que necesite un rediseño serio para actualizar esto.

Solo un ejemplo: medir con precisión la duración de la representación de la página web

Usando pruebas de automatización, es mucho más fácil probar el rendimiento del navegador web. Para medir el tiempo de respuesta máximo que es probable que acepte, simplemente establezca una constante en sus scripts de prueba y / o páselo como un parámetro de función, por ejemplo, en este pseudocódigo: $ sel-> wait_for_page_to_load ($ mypage, $ maxtime).

Hacer pruebas en varios navegadores con valores bajos puede ser bastante esclarecedor.

La alternativa sería que los empleados hicieran mediciones de tiempo con un cronómetro.

La prueba automatizada de la interfaz de usuario resuelve la capacidad de:

• repita rápidamente la prueba de una gran cantidad de componentes
• recuerde probar una gran cantidad de funciones cada vez
• compare ejecuciones y tiempos de ejecución de conjuntos de pruebas a medida que la aplicación crece
• configurar ejecuciones con cientos de entradas diferentes y condiciones variables
• permitir que las personas que no escribieron la prueba la ejecuten y vean cualquier problema visual
• Permitir a los usuarios finales ver la aplicación que se utiliza de forma rápida y fácil
• distribuir la IU de prueba se ejecuta a una red, servidor remoto o servicio
• iniciar las pruebas de volumen con máquinas paralelas.

Sin embargo, como otros han señalado:

Telerik ...

la herramienta de elección debido a su grabadora mucho más flexible

Es una bandera roja para muchos de nosotros.

Los scripts grabados de esta manera tienden a no ser una solución a largo plazo porque:

• la base de datos / ID de objeto tiende a cambiar de un caso a otro
• los scripts grabados manualmente a menudo se basan en etiquetas de diseño de página que cambian con frecuencia
• Las acciones comunes deberán escribirse una y otra vez en lugar de permitir la reutilización (consulte el enfoque SitePrism y PageObject)
• a veces necesita usar herramientas como xpath para obtener información adicional basada en la información de la página actual. Un simple guión grabado no hará esto.
• No se animará a los desarrolladores y evaluadores que escriben código a usar clases CSS, ID y atributos de datos HTML5, que son prácticas que conducirán a pruebas más robustas y mantenibles.

Sin embargo, Telerik tiene algunas ventajas que deberían considerarse:

• dirigido a clientes móviles
• herramientas integradas para gestionar el crecimiento
• maneja Android, iOS y Windows Phone

Un enfoque que puede ayudar a cerrar las brechas es registrar la secuencia de comandos inicial utilizando el registrador de páginas de herramientas, pero luego cambiar la secuencia de comandos para que use ID, clases y atributos de datos para que dure con el tiempo. Este es un enfoque que realmente he usado con el complemento de selenio firefox.

Hace que las "Pruebas de expertos" (similares a las "Pruebas exploratorias", pero realizadas por usuarios finales o miembros del equipo con una gran cantidad de conocimiento comercial) sean más fáciles de realizar, registrar resultados, medir y automatizar.

Vengo a esto desde un fondo diferente. En mis antiguos empleadores, desarrollamos herramientas comerciales de pruebas automatizadas (QALoad, QARun, TestPartner, SilkTest, SilkPerfomer).

Vimos que las pruebas automatizadas de IU cumplían dos roles:

1. Prueba de regresión completa

2. Configuración automatizada de entornos de prueba.

Nos apoyamos mucho en las herramientas para realizar pruebas de regresión todas las noches. Simplemente no teníamos el poder humano para probar todos los botones y diálogos para verificar que no hayamos roto nada entre la interfaz de usuario y la lógica de negocios.

Para pruebas más importantes, descubrimos que una sola persona podía activar varias máquinas virtuales y usar scripts para llegar al punto de una prueba real. Les permitió centrarse en los bits importantes y no intentar seguir un caso de prueba de 24 pasos.

El único problema con las pruebas automatizadas era el hábito de arrojar demasiadas pruebas a la caja sin ningún tipo de supervisión para eliminar las pruebas duplicadas o innecesarias. De vez en cuando teníamos que entrar y podar las cosas para que la suite se completara en menos de 12 horas.

Las pruebas automatizadas, de cualquier tipo, proporcionan pruebas de regresión; Al ejecutar la prueba que solía funcionar, verifica que todavía funciona (o no) independientemente de cualquier otra cosa que haya agregado. Esto es cierto independientemente de si la prueba es una prueba de integración (que generalmente no toca la interfaz de usuario) o una AAT (que generalmente requiere la interfaz de usuario).

Las pruebas de IU automatizadas permiten que el sistema se pruebe como si un usuario estuviera haciendo clic en los botones. Dichas pruebas se pueden utilizar para verificar la navegación a través del sistema, la corrección de las etiquetas y / o mensajes, el rendimiento y / o los tiempos de carga en un entorno de prueba particular, etc. al igual que la integración y las pruebas unitarias para el programador. Puede configurar una prueba una vez (generalmente registrando sus propios clics del mouse y las entradas de datos en un script), y una vez que la prueba funciona correctamente, todo lo que debe hacer para verificar la corrección del sistema bajo prueba es ejecutarla nuevamente. Algunos marcos, como Selenium, permiten migrar las pruebas entre navegadores, lo que permite probar varios entornos en los que el sitio debería funcionar correctamente.

Sin pruebas automatizadas, está limitado por el número y la velocidad de sus evaluadores de control de calidad; literalmente deben tener manos a la obra en el sistema, probando que su nueva función cumple con los requisitos y (igual de importante) que no rompió nada de lo que ya estaba allí.

Las pruebas determinan muchas cosas diferentes. Muchas de estas pruebas se pueden automatizar, para permitir la eliminación de trabajos pesados ​​y para hacer más. Para determinar si sus pruebas se pueden automatizar, primero debe ver si la pregunta que hacen es adecuada para ello.

• ¿Está determinando si un componente funciona de acuerdo con las especificaciones?
• ¿Desea probar todas las diferentes entradas y salidas posibles?
• prueba de esfuerzo del componente?
• ¿O estás tratando de probar que "funciona"?

La mayoría de estos pueden ser automatizados, porque son de naturaleza mecánica. La nueva función acepta entradas, entonces, ¿qué sucede cuando le arrojamos datos aleatorios? Pero algunos, como probar si el sistema funciona, requieren que alguien lo use realmente . Si no lo hacen, nunca sabrá si las expectativas de sus usuarios son las mismas que las del programa. Hasta que, es decir, el sistema se "rompe".

En mi experiencia, las pruebas automatizadas de la interfaz de usuario cubren muchas lagunas, que incluyen:

• Falta de documentación (ejemplo: uso del corredor de prueba automatizado para demostrar la funcionalidad existente)
• Requisitos desactualizados debido al desplazamiento del alcance (ejemplo: identificación de la brecha entre los requisitos y el código capturando la pantalla durante las ejecuciones de prueba)
• Alta rotación de desarrolladores y probadores (ejemplo: JavaScript heredado de ingeniería inversa al capturar la pantalla durante las ejecuciones de prueba con la herramienta de desarrollador abierta)
• Identificar violaciones de las convenciones de nomenclatura estándar a través de pruebas de regresión XPath (ejemplo: buscar en todos los nodos de atributo DOM nombres en camello)
• Reconocer los agujeros de seguridad que solo una computadora puede descubrir (ejemplo: cerrar sesión en una pestaña y al mismo tiempo enviar un formulario en la otra)

Me gustaría compartir la experiencia de nuestro equipo. Hemos estado utilizando nuestra propia herramienta de prueba de interfaz de usuario, Screenster, para probar nuestras aplicaciones web y las de nuestros clientes. Ha demostrado ser una alternativa útil a Selenium para tareas de prueba visual / CSS. Screenster es una herramienta de automatización de prueba que realiza una comparación basada en capturas de pantalla de diferentes versiones de sus páginas web. Primero crea una línea de base visual para una página, tomando una captura de pantalla para cada acción del usuario. Durante la próxima ejecución, toma una nueva captura de pantalla en cada paso, la compara con la de la línea de base y resalta las diferencias.

En resumen, Screenster tiene las siguientes ventajas: Línea de base visual: las capturas de pantalla se capturan para cada paso del usuario durante la grabación de prueba Comparación basada en captura de pantalla: Screenster compara las imágenes capturadas durante una reproducción con las de la línea de base y resalta todas las diferencias Selectores de CSS inteligentes: el probador puede seleccionar Elementos CSS en las capturas de pantalla y realice acciones con ellos, por ejemplo, márquelos como regiones ignoradas para excluir de futuras comparaciones