En las pruebas de software , la automatización de pruebas es el uso de software separado 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 ya implementado, 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]
Hay muchos enfoques para la automatización de pruebas, sin embargo, a continuación se muestran los enfoques generales que se utilizan ampliamente:
- Prueba de interfaz gráfica de usuario . Un marco de prueba que generaeventos 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 es correcto.
- Pruebas impulsadas por API . Un marco de prueba que utiliza una interfaz de programación para la aplicación para validar el comportamiento bajo prueba. Normalmente, las pruebas impulsadas por API pasan por alto la interfaz de usuario de la aplicación por completo. También se pueden probar interfaces públicas (generalmente) para clases, módulos o bibliotecas que se prueban con una variedad de argumentos de entrada para validar que los resultados que se devuelven son correctos.
Una forma de generar casos de prueba automáticamente es la prueba basada en modelos mediante el uso de un modelo del sistema para la generación de casos de prueba, pero la investigación continúa en 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 de negocios automatizados en un lenguaje sencillo, de modo que no se necesita programación de ningún tipo para configurarlos para múltiples sistemas operativos, navegadores y aplicaciones inteligentes. dispositivos. [3]
Qué automatizar, cuándo automatizar o incluso si realmente se necesita automatización son decisiones cruciales que debe tomar el equipo de pruebas (o desarrollo). [4] Una revisión de literatura multi-vocal de 52 profesionales y 26 fuentes académicas 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) prueba -herramienta, 4) temas humanos y organizativos, 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 IVU. [5]
Una tendencia creciente en el desarrollo de software es el uso de marcos de prueba unitarios 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 las pruebas que deben ejecutarse en el programa para verificar que el programa se ejecuta como se espera.
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. Se pueden escribir pruebas unitarias para definir la funcionalidad antes de escribir el código. Sin embargo, estas pruebas unitarias evolucionan y se amplían a medida que avanza la codificación, se descubren problemas y el código se somete a refactorización. [6] Sólo cuando pasan todas las pruebas para todas las características solicitadas, 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 repararlo. 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, es mucho menos probable que introduzca nuevos defectos cuando el código refactorizado está cubierto por pruebas unitarias.
Algunas tareas de prueba de software (como pruebas extensivas de regresión de interfaz de bajo nivel ) pueden ser laboriosas y llevar mucho tiempo realizarlas manualmente. Además, es posible que un enfoque manual no siempre sea eficaz para encontrar determinadas clases de defectos. La automatización de pruebas ofrece la posibilidad de realizar este tipo de pruebas de forma eficaz.
Una vez que se han desarrollado las pruebas automatizadas, se pueden ejecutar rápida y repetidamente. Muchas veces, este puede ser un método rentable para las pruebas de regresión de productos de software que tienen una larga vida de mantenimiento. Incluso los parches menores durante la vida útil de la aplicación pueden hacer que se rompan las funciones existentes que estaban funcionando en un momento anterior.
Si bien las empresas de desarrollo de software valoran la reutilización de las pruebas automatizadas, esta propiedad también puede verse como 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 pruebas debe tomarse de forma individual, teniendo en cuenta los requisitos y peculiaridades del proyecto.
Las herramientas de automatización de pruebas pueden ser caras 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 debe ejecutarse (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 verificaciones automatizadas, así como para revisar los resultados de las pruebas.
En las pruebas automatizadas, el ingeniero de pruebas o la persona que garantiza la calidad del software debe tener la capacidad de codificar el software, ya que los casos de prueba se escriben en forma de código fuente que, cuando se ejecutan, producen resultados 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, que no requieren programación.
Prueba de API
Las pruebas de API también están siendo ampliamente utilizadas por los probadores de software, ya que les permite verificar los requisitos independientemente de su implementación de GUI, comúnmente para probarlos antes en el desarrollo, y para asegurarse de que la prueba en sí se adhiera a los principios del 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. [7] Dado que las API carecen de GUI , las pruebas de API se realizan en la capa de mensajes . [8] Las pruebas de API se consideran críticas cuando una API sirve como interfaz principal para la lógica de la aplicación . [9]
Prueba continua
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. [10] [11] Para las pruebas continuas, el alcance de las pruebas se extiende desde la validación de los requisitos ascendentes o las historias de los usuarios hasta la evaluación de los requisitos del sistema asociados con los objetivos comerciales generales. [12]
Prueba de interfaz gráfica de usuario (GUI)
Muchas herramientas de automatización de pruebas proporcionan 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 desee, 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 características plantea importantes problemas de fiabilidad y mantenimiento. Volver a etiquetar 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 a menudo agrega actividades irrelevantes o registra incorrectamente algunas actividades. [ cita requerida ]
Una variación de este tipo de herramienta es para probar sitios web. Aquí, la "interfaz" es la página web. Sin embargo, tal marco utiliza técnicas completamente diferentes porque está renderizando HTML y escuchando eventos DOM en lugar de eventos del sistema operativo. Los navegadores sin cabeza o las soluciones basadas en Selenium Web Driver se utilizan normalmente para este propósito. [13] [14] [15]
Otra variación de este tipo de herramienta de automatización de pruebas es para probar aplicaciones móviles. Esto es muy útil dada la cantidad de tamaños, resoluciones y sistemas operativos diferentes que se utilizan en los teléfonos móviles. Para esta variación, se utiliza un marco 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 secuencias de comandos que no utiliza grabación y reproducción, sino que crea un modelo [se necesita aclaración ] 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 creación de secuencias de comandos. .
Pruebas a diferentes niveles
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 para escribir. [dieciséis]
Niveles
- Como base sólida, las pruebas unitarias proporcionan solidez a los productos de software. Probar partes individuales del código facilita la escritura y ejecución de las pruebas.
- 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 de IU que tienen menos pruebas debido a los diferentes atributos que lo hacen más complejo de ejecutar, por ejemplo, la fragilidad de las pruebas, donde un pequeño cambio en la interfaz de usuario puede romper muchas pruebas y agrega mantenimiento. esfuerzo. [16] [17]
Enfoque marco en la automatización
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 brindan soporte para las pruebas de software automatizadas es el bajo costo de mantenimiento . Si hay algún cambio en cualquier caso de prueba , solo es necesario actualizar el archivo del caso de prueba y el script del controlador y el script de inicio seguirán siendo los mismos. Idealmente, no es necesario actualizar los scripts en caso de cambios en la aplicación.
La elección del marco o la técnica de creación de scripts adecuados ayuda a reducir los costes. Los costos asociados con las secuencias de comandos de prueba se deben a los esfuerzos de desarrollo y mantenimiento. El enfoque de secuencias de comandos utilizado durante la automatización de pruebas tiene un efecto sobre los costos.
Generalmente se utilizan varias técnicas de framework / scripting:
- Lineal (código de procedimiento, posiblemente generado por herramientas como las que usan grabación y reproducción)
- Estructurado (utiliza estructuras de control, normalmente condiciones / declaraciones 'if-else', 'switch', 'for', 'while')
- Basado en datos (los datos se conservan fuera de las pruebas en una base de datos, hoja de cálculo u otro mecanismo)
- Impulsado por palabras clave
- Híbrido (se utilizan dos o más de los patrones anteriores)
- Marco de automatización ágil
El marco de pruebas es responsable de: [18]
- definir el formato en el que expresar expectativas
- Crear un mecanismo para conectar o impulsar la aplicación bajo prueba.
- ejecutando las pruebas
- informes de resultados
Interfaz de automatización de pruebas
Las interfaces de automatización de pruebas son plataformas que proporcionan un único espacio de trabajo para incorporar múltiples herramientas de prueba y marcos para las pruebas de integración / sistema de la aplicación bajo prueba. El objetivo de la interfaz de automatización de pruebas es simplificar el proceso de asignación de pruebas a los criterios comerciales sin que la codificación se interponga en el proceso. Se espera que la interfaz de automatización de pruebas mejore la eficiencia y la flexibilidad de mantener los scripts de prueba. [19]
La interfaz de automatización de pruebas consta de los siguientes módulos principales:
- Motor de interfaz
- Entorno de interfaz
- Repositorio de objetos
Motor de interfaz
Los motores de interfaz se basan en el entorno de interfaz. El motor de interfaz consta de un analizador y un corredor de pruebas. El analizador está presente para analizar los archivos de objetos que provienen del repositorio de objetos en el lenguaje de secuencia de comandos específico de la prueba. El corredor de pruebas ejecuta los scripts de prueba utilizando un arnés de prueba . [19]
Repositorio de objetos
Los repositorios de objetos son una colección de datos de objetos de IU / Aplicación registrados por la herramienta de prueba mientras explora la aplicación bajo prueba. [19]
Definición de límites entre el marco de automatización y una herramienta de prueba
Las herramientas están diseñadas específicamente para apuntar a un entorno de prueba en particular, como Windows y herramientas de automatización web, etc. Las herramientas sirven como un agente impulsor de un proceso de automatización. Sin embargo, un marco de automatización no es una herramienta para realizar una tarea específica, sino una infraestructura que brinda 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.
Hay varios tipos de marcos. Se clasifican en función del componente de automatización que aprovechan. Estos son:
- Pruebas basadas en datos
- Pruebas impulsadas por la modularidad
- Pruebas basadas en palabras clave
- Pruebas híbridas
- Pruebas basadas en modelos
- Pruebas basadas en código
- Desarrollo impulsado por el comportamiento
Que probar
Las herramientas de prueba pueden ayudar a automatizar tareas como la instalación de productos, la creación de datos de prueba, la interacción de la GUI, la detección de problemas (considere agentes de análisis o sondeo equipados con oráculos de prueba ), registro de defectos, etc., sin necesidad de automatizar las pruebas de un extremo a otro. .
Uno debe seguir satisfaciendo los requisitos populares cuando se piensa en la automatización de pruebas:
- Independencia de la plataforma y el sistema operativo
- Capacidad impulsada por datos (datos de entrada, datos de salida, metadatos )
- Informes de personalización ( acceso a la base de datos DB , Crystal Reports )
- Fácil depuración y registro
- Control de versiones amigable: archivos binarios mínimos
- Extensible y Personalización ( API abiertas para poder integrarse con otras herramientas)
- Controlador común (por ejemplo, en el ecosistema de desarrollo de Java, eso 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 prueba desatendidas 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 )
Ver también
- Lista de herramientas de prueba de GUI
- Lista de herramientas de prueba web
- Prueba continua
- Fuzzing
- Navegador sin cabeza
- Pruebas de software
- Prueba del sistema
- Prueba de unidad
Referencias
- ^ Kolawa, Adam; Huizinga, Dorota (2007). Prevención automatizada de defectos: mejores prácticas en la gestión de software . Prensa de la Sociedad de Computación Wiley-IEEE. pag. 74. ISBN 978-0-470-04212-0.
- ^ O'Connor, Rory V .; Akkaya, Mariye Umay; Kemaneci, Kerem; Yilmaz, Murat; Poth, Alexander; Messnarz, Richard (15 de octubre de 2015). Mejora de procesos de sistemas, software y servicios: 22ª Conferencia Europea, EuroSPI 2015, Ankara, Turquía, del 30 de septiembre al 2 de octubre de 2015. Actas . Saltador. ISBN 978-3-319-24647-5.
- ^ Proceedings from the 5th International Conference on Software Testing and Validation (ICST). Centro de competencia de software Hagenberg. "Diseño de pruebas: lecciones aprendidas e implicaciones prácticas . Doi : 10.1109 / IEEESTD.2008.4578383 . ISBN 978-0-7381-5746-7.
- ^ Brian Marick. "¿Cuándo se debe automatizar una prueba?" . StickyMinds.com . Consultado el 20 de agosto de 2009 .
- ^ Garousi, Vahid; Mäntylä, Mika V. (1 de agosto de 2016). "¿Cuándo y qué automatizar en las pruebas de software? Una revisión de literatura multi-vocal". Tecnología de la información y el software . 76 : 92-117. doi : 10.1016 / j.infsof.2016.04.015 .
- ^ Vodde, Bas; Koskela, Lasse (2007). "Desarrollo basado en pruebas de aprendizaje contando líneas". Software IEEE . 24 (3): 74–79. doi : 10.1109 / ms.2007.80 . S2CID 30671391 .
- ^ Las API de prueba protegen las aplicaciones y la reputación , por Amy Reichert, SearchSoftwareQuality marzo de 2015
- ^ Todo sobre las pruebas de API: una entrevista con Jonathan Cooper , por Cameron Philipp-Edmonds, Stickyminds 19 de agosto de 2014
- ^ Produzca un mejor software mediante el uso de una estrategia de pruebas en capas , por Sean Kenefick, Gartner 7 de enero de 2014
- ^ Parte de la canalización: por qué las pruebas continuas son esenciales , por Adam Auerbach, TechWell Insights agosto de 2015
- ^ La relación entre el riesgo y las pruebas continuas: una entrevista con Wayne Ariola , por Cameron Philipp-Edmonds, Stickyminds, diciembre de 2015
- ^ DevOps: ¿Está enviando errores a los clientes más rápido ?, Por Wayne Ariola y Cynthia Dunlop, PNSQC, octubre de 2015
- ^ Pruebas sin cabeza con navegadores; https://docs.travis-ci.com/user/gui-and-headless-browsers/
- ^ Prueba sin cabeza con PhantomJS; http://phantomjs.org/headless-testing.html
- ^ Prueba de interfaz de usuario automatizada; https://www.devbridge.com/articles/automated-user-interface-testing/
- ^ a b c Mike Cohn (2010). Triunfar con Agile . Raina Chrobak. ISBN 978-0-321-57936-2.
- ^ La pirámide de la prueba práctica , por Ham Vocke
- ^ "Reunión de selenio 20/04/2010 Elisabeth Hendrickson en Robot Framework 1of2" . Consultado el 26 de septiembre de 2010 .
- ^ a b c "Conquista: interfaz para el diseño de automatización de pruebas" (PDF) . Consultado el 11 de diciembre de 2011 .
Referencias generales
- Elfriede Dustin; et al. (1999). Pruebas de software automatizadas . Addison Wesley. ISBN 978-0-201-43287-9.
- Elfriede Dustin; et al. (2009). Implementación de pruebas de software automatizadas . Addison Wesley. ISBN 978-0-321-58051-1.
- Mark Fewster y Dorothy Graham (1999). Automatización de pruebas de software . Prensa ACM / Addison-Wesley. ISBN 978-0-201-33140-0.
- Roman Savenkov: Cómo convertirse en un probador de software. Consultoría Roman Savenkov, 2008, ISBN 978-0-615-23372-7
- Hong Zhu; et al. (2008). AST '08: Actas del 3er Taller Internacional sobre Automatización de Pruebas de Software . Prensa ACM. doi : 10.1145 / 1370042 . ISBN 978-1-60558-030-2.
- Mosley, Daniel J .; Posey, Bruce (2002). Automatización de pruebas de software suficiente . ISBN 978-0130084682.
- Hayes, Linda G., "Manual de pruebas automatizadas", Instituto de pruebas de software, segunda edición, marzo de 2004
- Kaner, Cem, " Architectures of Test Automation ", agosto de 2000
enlaces externos
- Experiencia práctica en pruebas automatizadas
- Automatización de pruebas: entrega de valor comercial
- Test Automation Snake Oil por James Bach
- ¿Cuándo se debe automatizar una prueba? por Brian Marick
- Directrices para el marco de automatización de pruebas
- Automatización de pruebas avanzada
- Factores de éxito para las pruebas basadas en palabras clave de Hans Buwalda
- Automatización que aprende: hacer que su computadora funcione para usted por Jeremy Carey-Dressler
- Recursos y mejores prácticas de pruebas de automatización por Joe Colantonio