Automatización de pruebas

En el campo de las pruebas de software , la automatización de pruebas es el uso de software independiente del software que se está probando para controlar la ejecución de las pruebas y la comparación de los resultados reales con los resultados previstos. ^[1] La automatización de pruebas puede automatizar algunas tareas repetitivas pero necesarias en un proceso de prueba formalizado que ya está en marcha, o realizar pruebas adicionales que serían difíciles de hacer manualmente. La automatización de pruebas es fundamental para la entrega continua y las pruebas continuas . ^[2]

Existen muchos enfoques para la automatización de pruebas, sin embargo, a continuación se presentan los enfoques generales más utilizados:

• Pruebas de interfaz gráfica de usuario . Un marco de pruebas que genera eventos de interfaz de usuario, como pulsaciones de teclas y clics del mouse, y observa los cambios que resultan en la interfaz de usuario para validar que el comportamiento observable del programa sea correcto.
• Pruebas impulsadas por API . Un marco de pruebas que utiliza una interfaz de programación para la aplicación a fin de validar el comportamiento que se está probando. Normalmente, las pruebas impulsadas por API pasan por alto por completo la interfaz de usuario de la aplicación. También pueden ser pruebas de interfaces públicas (por lo general) para clases, módulos o bibliotecas que se prueban con una variedad de argumentos de entrada para validar que los resultados que se devuelven sean correctos.

Una forma de generar casos de prueba automáticamente es mediante pruebas basadas en modelos a través del uso de un modelo del sistema para la generación de casos de prueba, pero se continúa investigando sobre una variedad de metodologías alternativas para hacerlo. ^{[ cita requerida ]} En algunos casos, el enfoque basado en modelos permite a los usuarios no técnicos crear casos de prueba comerciales automatizados en un lenguaje sencillo, de modo que no se necesita ningún tipo de programación para configurarlos para múltiples sistemas operativos, navegadores y dispositivos inteligentes. ^[3]

Algunas tareas de prueba de software (como las pruebas de regresión de interfaz de bajo nivel ) pueden ser laboriosas y requerir mucho tiempo si se realizan manualmente. Además, un enfoque manual puede no ser siempre eficaz para detectar ciertas clases de defectos. La automatización de pruebas ofrece la posibilidad de realizar este tipo de pruebas de manera eficaz.

Una vez que se han desarrollado pruebas automatizadas, se pueden ejecutar de forma rápida y repetida muchas veces. Este puede ser un método rentable para realizar pruebas de regresión de productos de software que tienen una larga vida útil de mantenimiento. Incluso pequeños parches a lo largo de la vida útil de la aplicación pueden provocar que se estropeen funciones existentes que funcionaban en un momento anterior.

Los evaluadores de software también utilizan ampliamente las pruebas de API , ya que les permiten verificar los requisitos independientemente de su implementación de GUI, comúnmente para probarlos en una etapa anterior del desarrollo y para asegurarse de que la prueba en sí se adhiere a los principios de código limpio, especialmente el principio de responsabilidad única . Implica probar directamente las API como parte de las pruebas de integración , para determinar si cumplen con las expectativas de funcionalidad, confiabilidad, rendimiento y seguridad. ^[4] Dado que las API carecen de una GUI , las pruebas de API se realizan en la capa de mensajes . ^[5] Las pruebas de API se consideran críticas cuando una API sirve como interfaz principal para la lógica de la aplicación . ^[6]

Muchas herramientas de automatización de pruebas ofrecen funciones de grabación y reproducción que permiten a los usuarios grabar de forma interactiva las acciones del usuario y reproducirlas tantas veces como deseen, comparando los resultados reales con los esperados. La ventaja de este enfoque es que requiere poco o ningún desarrollo de software . Este enfoque se puede aplicar a cualquier aplicación que tenga una interfaz gráfica de usuario . Sin embargo, la dependencia de estas funciones plantea importantes problemas de fiabilidad y mantenimiento. Reetiquetar un botón o moverlo a otra parte de la ventana puede requerir que se vuelva a grabar la prueba. La grabación y reproducción también suele añadir actividades irrelevantes o registrar incorrectamente algunas actividades. ^{[ cita requerida ]}

Una variante de este tipo de herramienta es la que se utiliza para probar sitios web. En este caso, la "interfaz" es la página web. Sin embargo, este tipo de marco utiliza técnicas completamente diferentes, ya que procesa HTML y escucha eventos DOM en lugar de eventos del sistema operativo. Para este propósito se utilizan normalmente navegadores sin interfaz gráfica o soluciones basadas en Selenium Web Driver . ^{[7] [8] [9]}

Otra variante de este tipo de herramienta de automatización de pruebas es la que se utiliza para probar aplicaciones móviles. Esto resulta muy útil dada la cantidad de tamaños, resoluciones y sistemas operativos diferentes que se utilizan en los teléfonos móviles. Para esta variante, se utiliza un marco de trabajo para instanciar acciones en el dispositivo móvil y recopilar los resultados de las acciones.

Otra variación es la automatización de pruebas sin script, que no utiliza grabación ni reproducción, sino que construye un modelo ^{[ aclaración necesaria ]} de la aplicación y luego permite al evaluador crear casos de prueba simplemente insertando parámetros y condiciones de prueba, lo que no requiere habilidades de scripting.

La automatización de pruebas, principalmente mediante pruebas unitarias, es una característica clave de la programación extrema y el desarrollo de software ágil , donde se conoce como desarrollo impulsado por pruebas (TDD) o desarrollo de prueba primero. Las pruebas unitarias se pueden escribir para definir la funcionalidad antes de escribir el código. Sin embargo, estas pruebas unitarias evolucionan y se extienden a medida que avanza la codificación, se descubren problemas y el código se somete a refactorización. ^[10] Solo cuando pasan todas las pruebas para todas las características demandadas, el código se considera completo. Los defensores argumentan que produce software que es más confiable y menos costoso que el código que se prueba mediante exploración manual. ^{[ cita requerida ]} Se considera más confiable porque la cobertura del código es mejor y porque se ejecuta constantemente durante el desarrollo en lugar de una vez al final de un ciclo de desarrollo en cascada . El desarrollador descubre defectos inmediatamente después de realizar un cambio, cuando es menos costoso arreglarlo. Finalmente, la refactorización de código es más segura cuando se utilizan pruebas unitarias; Transformar el código en una forma más simple con menos duplicación de código , pero con un comportamiento equivalente, tiene muchas menos probabilidades de introducir nuevos defectos cuando el código refactorizado está cubierto por pruebas unitarias.

Las pruebas continuas son el proceso de ejecutar pruebas automatizadas como parte del proceso de entrega de software para obtener retroalimentación inmediata sobre los riesgos comerciales asociados con un candidato a lanzamiento de software. ^{[11] [12]} Para las pruebas continuas, el alcance de las pruebas se extiende desde la validación de requisitos de abajo hacia arriba o historias de usuario hasta la evaluación de los requisitos del sistema asociados con los objetivos comerciales generales. ^[13]

Qué automatizar, cuándo automatizar o incluso si realmente se necesita la automatización son decisiones cruciales que el equipo de pruebas (o desarrollo) debe tomar. ^[14] Una revisión de la literatura de 52 profesionales y 26 fuentes académicas con múltiples voces encontró que cinco factores principales a considerar en la decisión de automatización de pruebas son: 1) Sistema bajo prueba (SUT), 2) los tipos y números de pruebas, 3) herramienta de prueba, 4) temas humanos y organizacionales, y 5) factores transversales. Los factores individuales más frecuentes identificados en el estudio fueron: necesidad de pruebas de regresión, factores económicos y madurez del SUT. ^[15]

Si bien las empresas de desarrollo de software valoran la reutilización de las pruebas automatizadas, esta propiedad también puede considerarse una desventaja. Conduce a la llamada "paradoja de los pesticidas" , donde los scripts ejecutados repetidamente dejan de detectar errores que van más allá de sus marcos. En tales casos, las pruebas manuales pueden ser una mejor inversión. Esta ambigüedad conduce una vez más a la conclusión de que la decisión sobre la automatización de las pruebas debe tomarse de forma individual, teniendo en cuenta los requisitos y las peculiaridades del proyecto.

Las herramientas de prueba pueden ayudar a automatizar tareas como la instalación del producto, la creación de datos de prueba, la interacción con la GUI, la detección de problemas (considere analizar o sondear agentes equipados con oráculos de prueba ), el registro de defectos, etc., sin necesariamente automatizar las pruebas de un extremo a otro.

Al pensar en la automatización de pruebas, es necesario seguir satisfaciendo los requisitos populares:

• Independencia de plataforma y sistema operativo
• Capacidad basada en datos (datos de entrada, datos de salida, metadatos )
• Informes de personalización ( Acceso a bases de datos de BD , Crystal Reports )
• Fácil depuración y registro
• Compatible con control de versiones : archivos binarios mínimos
• Extensible y personalizable ( API abiertas para poder integrar con otras herramientas)
• Controlador común (por ejemplo, en el ecosistema de desarrollo de Java, esto significa Ant o Maven y los IDE populares ). Esto permite que las pruebas se integren con los flujos de trabajo de los desarrolladores .
• Admite ejecuciones de pruebas sin supervisión para la integración con procesos de compilación y ejecuciones por lotes. Los servidores de integración continua lo requieren.
• Notificaciones por correo electrónico como mensajes de rebote
• Admite un entorno de ejecución distribuido ( banco de pruebas distribuido )
• Soporte de aplicaciones distribuidas ( SUT distribuido )

Las herramientas de automatización de pruebas pueden ser costosas y, por lo general, se emplean en combinación con pruebas manuales. La automatización de pruebas puede resultar rentable a largo plazo, especialmente cuando se utiliza repetidamente en pruebas de regresión . Un buen candidato para la automatización de pruebas es un caso de prueba para el flujo común de una aplicación, ya que se requiere que se ejecute (prueba de regresión) cada vez que se realiza una mejora en la aplicación. La automatización de pruebas reduce el esfuerzo asociado con las pruebas manuales. Se necesita un esfuerzo manual para desarrollar y mantener controles automatizados, así como para revisar los resultados de las pruebas.

En las pruebas automatizadas, el ingeniero de pruebas o el encargado de control de calidad del software debe tener la capacidad de codificar software, ya que los casos de prueba se escriben en forma de código fuente que, cuando se ejecuta, produce un resultado de acuerdo con las afirmaciones que forman parte de él. Algunas herramientas de automatización de pruebas permiten que la creación de pruebas se realice mediante palabras clave en lugar de codificación, lo que no requiere programación.

Una estrategia para decidir la cantidad de pruebas a automatizar es la pirámide de automatización de pruebas. Esta estrategia sugiere escribir tres tipos de pruebas con diferente granularidad. Cuanto mayor sea el nivel, menor será la cantidad de pruebas a escribir. ^[16]

• Como base sólida, las pruebas unitarias aportan solidez a los productos de software. Probar partes individuales del código facilita la escritura y ejecución de las pruebas. Los desarrolladores escriben pruebas unitarias como parte de cada historia y las integran con CI. ^[17]
• La capa de servicio se refiere a probar los servicios de una aplicación por separado de su interfaz de usuario, estos servicios son cualquier cosa que la aplicación hace en respuesta a alguna entrada o conjunto de entradas.
• En el nivel superior tenemos las pruebas UI que tienen menos pruebas debido a los diferentes atributos que las hacen más complejas de ejecutar, por ejemplo la fragilidad de las pruebas, donde un pequeño cambio en la interfaz de usuario puede romper muchas pruebas y agregar esfuerzo de mantenimiento. ^{[16] [18]}

Una concepción de la pirámide de pruebas incluye pruebas unitarias, de integración y de extremo a extremo. Según el blog de pruebas de Google , las pruebas unitarias deberían constituir la mayor parte de la estrategia de pruebas, con menos pruebas de integración y solo una pequeña cantidad de pruebas de extremo a extremo. ^[19]

• Pruebas unitarias: son pruebas que prueban componentes individuales o unidades de código de forma aislada. Son rápidas, confiables y aíslan las fallas en pequeñas unidades de código.
• Pruebas de integración: estas pruebas comprueban cómo funcionan juntas las distintas unidades de código. Aunque las unidades individuales pueden funcionar correctamente por sí solas, las pruebas de integración garantizan que funcionen juntas de forma coherente.
• Pruebas de extremo a extremo: prueban el sistema en su totalidad, simulando escenarios de uso del mundo real. Son las pruebas más lentas y complejas.

Un marco de automatización de pruebas es un sistema integrado que establece las reglas de automatización de un producto específico. Este sistema integra las bibliotecas de funciones, las fuentes de datos de prueba, los detalles de los objetos y varios módulos reutilizables. Estos componentes actúan como pequeños bloques de construcción que deben ensamblarse para representar un proceso empresarial. El marco proporciona la base de la automatización de pruebas y simplifica el esfuerzo de automatización.

La principal ventaja de un marco de supuestos, conceptos y herramientas que brinden soporte para las pruebas de software automatizadas es el bajo costo de mantenimiento . Si se produce un cambio en algún caso de prueba , solo es necesario actualizar el archivo del caso de prueba y el script del controlador y el script de inicio permanecerán iguales. Lo ideal es que no sea necesario actualizar los scripts en caso de que se produzcan cambios en la aplicación.

La elección del marco de trabajo o la técnica de creación de scripts adecuados ayuda a mantener los costos más bajos. Los costos asociados con la creación de scripts de prueba se deben a los esfuerzos de desarrollo y mantenimiento. El enfoque de creación de scripts utilizado durante la automatización de pruebas tiene efecto sobre los costos.

Generalmente se utilizan varias técnicas de framework/scripting:

1. Lineal (código de procedimiento, posiblemente generado por herramientas como las que utilizan grabación y reproducción)
2. Estructurado (utiliza estructuras de control, generalmente condiciones o declaraciones 'if-else', 'switch', 'for', 'while')
3. Basado en datos (los datos se conservan fuera de las pruebas en una base de datos, hoja de cálculo u otro mecanismo)
4. Impulsado por palabras clave
5. Híbrido (se utilizan dos o más de los patrones anteriores)
6. Marco de automatización ágil

El marco de pruebas es responsable de: ^[20]

1. definir el formato en el que expresar las expectativas
2. Crear un mecanismo para conectarse o controlar la aplicación bajo prueba.
3. ejecutando las pruebas
4. reportando resultados

Una tendencia creciente en el desarrollo de software es el uso de marcos de pruebas unitarias como los marcos xUnit (por ejemplo, JUnit y NUnit ) que permiten la ejecución de pruebas unitarias para determinar si varias secciones del código están actuando como se espera en diversas circunstancias. Los casos de prueba describen pruebas que deben ejecutarse en el programa para verificar que el programa se ejecuta como se espera.

Las interfaces de automatización de pruebas son plataformas que proporcionan un único espacio de trabajo para incorporar múltiples herramientas y marcos de prueba para las pruebas de integración y del sistema de la aplicación en prueba. El objetivo de la interfaz de automatización de pruebas es simplificar el proceso de asignación de pruebas a criterios comerciales sin que la codificación interfiera en el proceso. Se espera que la interfaz de automatización de pruebas mejore la eficiencia y la flexibilidad del mantenimiento de los scripts de prueba. ^[21]

La interfaz de automatización de pruebas consta de los siguientes módulos principales:

• Motor de interfaz
• Entorno de interfaz
• Repositorio de objetos

Los motores de interfaz se construyen sobre el entorno de interfaz. El motor de interfaz consta de un analizador y un ejecutor de pruebas. El analizador está presente para analizar los archivos de objetos que provienen del repositorio de objetos en el lenguaje de script específico de la prueba. El ejecutor de pruebas ejecuta los scripts de prueba utilizando un arnés de prueba . ^[21]

Los repositorios de objetos son una colección de datos de objetos de interfaz de usuario/aplicación registrados por la herramienta de prueba mientras explora la aplicación bajo prueba. ^[21]

Las herramientas están diseñadas específicamente para un entorno de prueba en particular, como herramientas de automatización web y de Windows, etc. Las herramientas sirven como un agente impulsor para un proceso de automatización. Sin embargo, un marco de automatización no es una herramienta para realizar una tarea específica, sino más bien una infraestructura que proporciona la solución donde diferentes herramientas pueden hacer su trabajo de manera unificada. Esto proporciona una plataforma común para el ingeniero de automatización.

Existen varios tipos de marcos de trabajo que se clasifican en función del componente de automatización que utilizan. Estos son:

1. Pruebas basadas en datos
2. Pruebas basadas en modularidad
3. Pruebas basadas en palabras clave
4. Pruebas híbridas
5. Pruebas basadas en modelos
6. Pruebas basadas en código
7. Desarrollo impulsado por el comportamiento

Las pruebas basadas en modelos son una aplicación del diseño basado en modelos para diseñar y, opcionalmente, ejecutar artefactos para realizar pruebas de software o pruebas de sistemas . Los modelos se pueden utilizar para representar el comportamiento deseado de un sistema bajo prueba (SUT) o para representar estrategias de prueba y un entorno de prueba. La imagen de la derecha muestra el primer enfoque.

• Comparación de herramientas de prueba de GUI
• Lista de herramientas de pruebas web
• Pruebas continuas
• Pelusa
• Navegador sin interfaz gráfica
• Pruebas de software
• Prueba del sistema
• Prueba unitaria