Automatización de pruebas
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 que ya existe, o realizar pruebas adicionales que serían difíciles de realizar manualmente. La automatización de pruebas es fundamental para la entrega continua y las pruebas continuas . [2]
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 comerciales 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 uno realmente necesita automatización son decisiones cruciales que debe tomar el equipo de pruebas (o desarrollo). [4] Una revisión de la literatura multivocal de 52 profesionales y 26 fuentes académicas encontró que los 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 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 COU. [5]
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 las pruebas que deben ejecutarse en el programa para verificar que el programa se ejecuta como se esperaba.
La automatización de pruebas, principalmente mediante pruebas unitarias, es una característica clave de la programación extrema y el desarrollo ágil de software , donde se conoce como desarrollo basado en 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 amplían a medida que avanza la codificación, se descubren problemas y el código se refactoriza. [6] Solo cuando todas las pruebas para todas las características exigidas pasan, 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 los 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 las pruebas extensas de regresión de interfaz de bajo nivel ) pueden ser laboriosas y llevar mucho tiempo si se realizan manualmente. Además, es posible que un enfoque manual no siempre sea efectivo para encontrar ciertas clases de defectos. La automatización de pruebas ofrece la posibilidad de realizar este tipo de pruebas de manera efectiva.
