Pruebas automatizadas de GUI: Nos encontramos a medio camino

https://stackoverflow.com/questions/822275

03-07-2019
|

Pregunta

Se me ha encomendado el desarrollo de un sistema para realizar pruebas de GUI automáticas y podría dar algunos consejos. Afortunadamente, estamos en medio de un importante rediseño de nuestra GUI y los desarrolladores que hacen el trabajo están abiertos a hacer que su código sea más fácil de automatizar. Mi problema es que no estoy seguro de qué pedirles que agreguen. Los enlaces que se agreguen no pueden afectar la funcionalidad, apariencia o seguridad de la interfaz y no deberían tener un impacto notable en el rendimiento. Aparte de eso, ¡el cielo es el límite!

La aplicación en cuestión es una aplicación Java basada en web a la que se accede a través de AJAX. La mayoría de las funciones existentes están codificadas con jsp, Javascript y un poco de Flash 8. La siguiente oleada de funciones se realizará con YUI Javascript library . Estoy bastante decidido a utilizar Selenium como herramienta de prueba debido a su flexibilidad y precio (gratis). Punto importante: mi objetivo es la reutilización de las pruebas y la facilidad de mantenimiento. Mi preferencia es escribir código que detecte, valide y ejerza los elementos de la página en lugar de usar un sistema de grabación y reproducción para el desarrollo de pruebas.

¿Puede alguien proporcionar orientación sobre qué ganchos se pueden colocar en el código o sobre algunas de las mejores prácticas para facilitar el desarrollo de las pruebas y que las pruebas sean más sólidas?

Solución

Principio guía básico: si quieren que pruebes algo, los evaluadores necesitan una forma de llevar la aplicación a ese estado, y una vez en ese estado, una forma de validar que el estado es correcto.

Entonces, lo primero es asegurarse de que entiendan que la automatización es la programación y que la UI es su API.

Acuerdo para no cambiar arbitrariamente la interfaz de usuario: si el probador Bob ve que el componente cambió de un botón a un enlace y coincide con la especificación, hace clic y continúa. Si bien es un cambio de código relativamente fácil en la automatización, es un cambio que debe realizarse en varias ubicaciones. (su trabajo como evaluador es comprender que ocurre un cambio y minimizar el costo de mantenimiento; su trabajo es realizar solo cambios importantes y comprender el impacto)
Una forma de determinar en qué página se encuentra ... Bob puede distinguir la diferencia entre el inicio de sesión y la entrada del pedido, pero ¿cómo lo sabrá la automatización? Si es un campo de ingreso con la etiqueta 'Nombre de usuario', la página de inicio de sesión Si un campo de entrada con número de pedido, el campo de orden.

No es bueno: una mejor práctica es un elemento de IU consistente para identificar la página: título de la página, componente oculto, etc.

Una forma de identificar de manera única todos los elementos con los que necesitas interactuar (hacer clic, escribir, verificar, etc.) y no INPUT_42 ....
Pregunte a los desarrolladores qué información pueden proporcionarles los evaluadores para acelerar su depuración, y pídales que los pongan en un archivo de registro
Capacidad para volcar el estado del programa
Control de errores coherente & amp; informes (también un buen diseño de interfaz de usuario)

Otros consejos

Como con la mayoría de las preguntas, depende. Sobre todo en cómo se ve tu sitio y qué tipo de controles hay en las páginas, ¿hay muchos elementos repetidos, etc.?

He tenido mucho éxito con Selenium RC y Selenium IDE. Lo principal es acostumbrarse a usar Selenium y sus comandos. También es útil acostumbrarse a localizar objetos en la página (XPaths y selectores CSS, así como la función 'contiene'). Lo que no desea es un montón de elementos que tienen la misma ruta de selección. Si las tablas y divs a continuación no tienen una parte exclusiva, puede agregar complejidad adicional a sus pruebas.

<html>
  <body>
    <table>
      <tr>
        <td>
          <div></div>
          <div></div>
          <div></div>
        </td>
      </tr>
    </table>
    <table>
      <tr>
        <td>
          <div></div>
          <div></div>
          <div></div>
        </td>
      </tr>
    </table>
  </body>
</html>

Para probar imágenes, es bueno poder verificar su existencia basándose en algo distinto al nombre del archivo de imagen, para que no tenga que cambiar sus pruebas cuando se actualice la imagen. Si necesita probar objetos Flash, visite este sitio .

Más allá de eso, no hay mucho de lo que haya notado que pueda incorporarse en el lado del desarrollo. Una vez que comience a configurar las pruebas y la ubicación de los elementos en la página, probablemente verá rápidamente lo que los desarrolladores deben hacer para ayudarlo.

Un consejo: mantenga su código de prueba en al menos dos capas de abstracción :

capa superior : debe ser una especie de fachada orientada hacia la terminología / acciones específicas de la aplicación, etc. Esta capa no usa directamente la biblioteca de Selenium RC . En el fondo utiliza el ...
... capa inferior : una biblioteca con algunos patrones de prueba comunes (ejemplo: " afirma que se eligió el valor X del control del botón de opción ") , que utiliza la biblioteca de Selenium RC.

De esta manera, sus pruebas serán más limpias de mantener y más comprensibles en términos de lo que se está probando. Incluso probamos un enfoque de tres capas, la tercera capa (la superior) siendo las pruebas especificadas utilizando XML . Esto fue para que nuestros evaluadores no programadores puedan especificar pruebas de aceptación sin profundizar en el código C #.

Agregando a los comentarios de McWafflestix y s_hewitt - los elementos gui deben estar correctamente etiquetados, ser únicos Y predecibles para el éxito con la automatización de gui. Si los identificadores de elementos no son predecibles, se encontrará con problemas. Predecible no significa necesariamente estática. Para elementos de página estáticos como un campo de nombre de usuario o un botón de inicio de sesión, esperaría que el nombre / id de estos sean estáticos de compilación a compilación y de ejecución a ejecución. Para casillas de verificación, botones de radio, contenido dinámico, espero que sean dinámicos, pero predecibles. Por ejemplo, podría tener un div con una clase = " contentdetail " y un id = " 12345 " ;. Siempre que pueda diseñar su xpath para encontrar el objeto con el que necesita interactuar de manera confiable, debe ser bueno.

EDITAR: una gran manera para que los desarrolladores admitan la automatización de pruebas es con la configuración de prueba. Dependiendo de su aplicación, la configuración automatizada de las pruebas y el desmontaje pueden ser problemáticos. Por ejemplo, en una aplicación de flujo de trabajo de almacén, las pruebas al principio del flujo de trabajo (aceptar artículos en el almacén) son fáciles de configurar, pero las pruebas al final del flujo de trabajo (enviar un artículo del almacén al cliente) tienen muchas dependencias (el artículo debe estar en el almacén, con la cantidad suficiente, en la ubicación de inventario correcta, etc.) que la mayoría de su código de automatización puede tratar simplemente con navegar e ingresar a través de la aplicación para llegar al punto donde puede realizar una prueba. En estos casos, puede ser beneficioso tener algún tipo de utilidad externa (fuera de la aplicación, por lo que la interfaz gráfica principal no se ve afectada) para inyectar dependencias o restablecer la base de datos a algún estado conocido. En mi ejemplo de almacén, su utilidad podría configurar el escenario a través del nivel de api, de modo que la prueba gui automática pueda continuar en el punto relevante.

Es muy poco lo que los desarrolladores pueden agregar al código para ayudar.

El problema es que si desea probar la ejecución de las rutas de código y la validez de esas rutas de código, eso debe hacerse en Pruebas de unidad, y éstas deben estar completamente separadas de su GUI. Pero si realmente quieres probar tu GUI, entonces solo tienes que simular la entrada del usuario. Lo único que puede ayudar con esto es tener sus objetos y controles correctamente etiquetados para que su marco de prueba los pueda detectar y ejercitar. Aparte de eso, no hay mucho que se pueda hacer (aunque eso puede ayudar bastante en sí mismo).

Soy bastante verde para las pruebas de unidad (adecuadas), pero he encontrado algunas menciones que debes probar y evitar probar tu GUI. Por lo general, omiten razones específicas, por lo que realmente no puedo hacer una copia de seguridad de ellas.

El enfoque que tomo (y creo que el enfoque sugerido por Juval Lowy en "Programación .NET Componentes") es tratar de abstraer el código real de la GUI a través de una interfaz, que me permite escribir pruebas unitarias para todos los la lógica de negocios activada por la GUI sin probar realmente la GUI en sí misma.

Funciona bastante bien y ha resultado en un código mucho más limpio con una gran separación de la lógica empresarial de la GUI y también hace que las modificaciones de la GUI sean mucho menos estresantes.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow