stringtranslate.com

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 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]

Enfoques generales

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

Otros enfoques

Pruebas basadas en modelos

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]

Prueba de regresión

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.

Pruebas de API

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]

Prueba de interfaz gráfica de usuario (GUI)

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 de 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.

Metodologías

Desarrollo basado en pruebas

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.

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. [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]

Consideraciones

Factores a considerar para la decisión de implementar la automatización de pruebas

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]

Efecto meseta

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.

Qué probar

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:

Roles

Herramientas de automatización de pruebas

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.

Ingeniero de 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.

Pruebas en 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 a escribir. [16]

Niveles de unidad, servicio e interfaz de usuario

La pirámide de automatización de pruebas propuesta por Mike Cohn [16]

Unidad, integración y niveles de extremo a extremo

Diagrama triangular que representa la "pirámide de pruebas" de Google. Progresa desde la sección más pequeña "E2E" en la parte superior, pasando por "Integración" en el medio, hasta la sección más grande "Unidad" en la parte inferior.
La pirámide de pruebas de Google [19]

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]

Enfoque de 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 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

Marcos de pruebas unitarias

Una tendencia creciente en el desarrollo de software es el uso de marcos de trabajo 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.

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 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]

Modelo de interfaz de automatización de pruebas

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

Motor de interfaz

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]

Repositorio de objetos

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]

Definición de límites entre un marco de automatización y una herramienta de prueba

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

Pruebas basadas en datos

Las pruebas basadas en datos (DDT), también conocidas como pruebas basadas en tablas o pruebas parametrizadas, son una metodología de pruebas de software que se utiliza en las pruebas de software informático para describir las pruebas realizadas utilizando una tabla de condiciones directamente como entradas de prueba y salidas verificables, así como el proceso en el que las configuraciones y el control del entorno de prueba no están codificados de forma rígida. [22] [23] En la forma más simple, el evaluador proporciona las entradas de una fila de la tabla y espera las salidas que aparecen en la misma fila. La tabla normalmente contiene valores que corresponden a espacios de entrada de límites o particiones. En la metodología de control, la configuración de la prueba se "lee" desde una base de datos.

Pruebas basadas en modularidad

La prueba basada en modularidad es un término que se utiliza en las pruebas de software . El marco de trabajo de modularidad de los scripts de prueba requiere la creación de scripts pequeños e independientes que representan módulos, secciones y funciones de la aplicación que se está probando. Estos pequeños scripts se utilizan luego de manera jerárquica para construir pruebas más grandes, que implementan un caso de prueba en particular. [24]

Pruebas basadas en palabras clave

Las pruebas basadas en palabras clave , también conocidas como pruebas basadas en palabras de acción (que no deben confundirse con las pruebas basadas en acciones), son una metodología de pruebas de software adecuada tanto para pruebas manuales como automatizadas . Este método separa la documentación de los casos de prueba  (incluidos tanto los datos como la funcionalidad a utilizar) de la prescripción de la forma en que se ejecutan los casos de prueba. Como resultado, separa el proceso de creación de pruebas en dos etapas distintas: una etapa de diseño y desarrollo, y una etapa de ejecución. La subetapa de diseño cubre el análisis y la evaluación de requisitos y el análisis, la definición y la población de datos.

Pruebas híbridas

La mayoría de los marcos de trabajo evolucionan o se desarrollan con el tiempo y en múltiples proyectos. Los marcos de trabajo de automatización más exitosos generalmente tienen en cuenta tanto la gramática y la ortografía como la entrada de información. Esto permite que la información proporcionada se verifique con información existente y confirmada. Esto ayuda a evitar que se publique información falsa o engañosa. Sin embargo, permite que otros publiquen información nueva y relevante en publicaciones existentes, lo que aumenta la utilidad y la relevancia del sitio. Dicho esto, ningún sistema es perfecto y es posible que no funcione según este estándar en todos los temas todo el tiempo, pero mejorará con un mayor aporte y uso.

Pruebas basadas en modelos

Configuración de prueba basada en modelos generales
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.

Desarrollo impulsado por el comportamiento

El desarrollo impulsado por el comportamiento (BDD) implica nombrar las pruebas de software utilizando el lenguaje del dominio para describir el comportamiento del código .

Véase también

Referencias

  1. ^ Kolawa, Adam; Huizinga, Dorota (2007). Prevención automatizada de defectos: mejores prácticas en la gestión de software . Wiley-IEEE Computer Society Press. pág. 74. ISBN 978-0-470-04212-0.
  2. ^ 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, 30 de septiembre - 2 de octubre de 2015. Actas. Springer. ISBN 978-3-319-24647-5.
  3. ^ Actas de la 5.ª Conferencia internacional sobre pruebas y validación de software (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.
  4. ^ Probar las API protege las aplicaciones y la reputación, por Amy Reichert, SearchSoftwareQuality, marzo de 2015
  5. ^ Todo sobre las pruebas de API: entrevista con Jonathan Cooper, por Cameron Philipp-Edmonds, Stickyminds 19 de agosto de 2014
  6. ^ Produzca un mejor software mediante una estrategia de pruebas por capas, por Sean Kenefick, Gartner 7 de enero de 2014
  7. ^ Pruebas sin interfaz gráfica con navegadores; https://docs.travis-ci.com/user/gui-and-headless-browsers/
  8. ^ Pruebas sin interfaz gráfica con PhantomJS; http://phantomjs.org/headless-testing.html
  9. ^ Pruebas automatizadas de interfaz de usuario; https://www.devbridge.com/articles/automated-user-interface-testing/
  10. ^ Vodde, Bas; Koskela, Lasse (2007). "Aprendizaje del desarrollo basado en pruebas mediante el conteo de líneas". IEEE Software . 24 (3): 74–79. doi :10.1109/ms.2007.80. S2CID  30671391.
  11. ^ Parte del proceso: Por qué las pruebas continuas son esenciales, por Adam Auerbach, TechWell Insights, agosto de 2015
  12. ^ La relación entre el riesgo y las pruebas continuas: una entrevista con Wayne Ariola, por Cameron Philipp-Edmonds, Stickyminds, diciembre de 2015
  13. ^ DevOps: ¿Está enviando errores a los clientes más rápidamente?, por Wayne Ariola y Cynthia Dunlop, PNSQC, octubre de 2015
  14. ^ Brian Marick. "¿Cuándo se debe automatizar una prueba?". StickyMinds.com . Consultado el 20 de agosto de 2009 .
  15. ^ 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 la literatura con múltiples voces". Tecnología de la información y el software . 76 : 92–117. doi :10.1016/j.infsof.2016.04.015.
  16. ^ abc Mike Cohn (2010). Cómo tener éxito con Agile . Raina Chrobak. ISBN 978-0-321-57936-2.
  17. ^ "Full Stack Testing por Gayathri Mohan". www.thoughtworks.com . Consultado el 13 de septiembre de 2022 .
  18. ^ La pirámide de pruebas prácticas, por Ham Vocke
  19. ^ ab "Dígale simplemente no a más pruebas de extremo a extremo". Blog de pruebas de Google . Consultado el 11 de febrero de 2023 .
  20. ^ "Selenium Meet-Up 20/04/2010 Elisabeth Hendrickson on Robot Framework 1of2". YouTube . 28 de abril de 2010 . Consultado el 26 de septiembre de 2010 .
  21. ^ abc "Conquest: Interface for Test Automation Design" (PDF) . Archivado desde el original (PDF) el 26 de abril de 2012 . Consultado el 11 de diciembre de 2011 .
  22. ^ "golang/go Pruebas basadas en tablas". GitHub .
  23. ^ "Guía del usuario de JUnit 5". junit.org .
  24. ^ DESAI, SANDEEP; SRIVASTAVA, ABHISHEK (30 de enero de 2016). PRUEBAS DE SOFTWARE: Un enfoque práctico (en árabe). PHI Learning Pvt. Ltd. ISBN 978-81-203-5226-1.

Referencias generales