Informe de la automatización de pruebas

Pruebas de integración

Estas pruebas verifican cómo las diferentes unidades de código funcionan juntas. Aunque las unidades individuales pueden funcionar correctamente individualmente, las pruebas de integración aseguran que funcionen juntas. PRUEBAS DE ENTER-END: Estas pruebas prueban el sistema en su conjunto, simulando escenarios de uso del mundo real. son las pruebas más lentas y complejas ... un enfoque para Generar automáticamente la prueba Los casos son a través de pruebas basadas en modelos que utilizan modelos del sistema para la generación de casos de prueba, pero la investigación continúa investigando varias alternativas. En algunos casos, un enfoque basado en modelos permite a los usuarios no técnicos crear casos de prueba comercial automatizados en inglés simple como que no se requiere programación de ningún tipo para configurar para múltiples sistemas operativos, navegadores y dispositivos inteligentes.Qué automatizar, cuándo automatizar e incluso si la automatización es realmente necesaria son decisiones clave que el equipo de prueba (o desarrollo) debe tomar. Una revisión de literatura multipartidista de 52 profesionales y 26 fuentes académicas encontraron que cinco factores principales a considerar en Las decisiones de automatización de pruebas son:

1) El sistema bajo prueba (Sut).

2) El tipo y la cantidad de pruebas.

3) Herramientas de prueba.4) Sujetos humanos y organizativos

5) Factores de cruce, los factores individuales más comunes identificados en el estudio fueron: necesidad de pruebas de regresión, factores económicos y madurez de la SUT.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 realizar pruebas unitarias para determinar si varias partes del código se comportan como se esperaba en varias circunstancias. Los casos de prueba describen las pruebas que deben ejecutarse en el programa para verificar que el programa funcione como se esperaba.La automatización de pruebas, utilizando principalmente pruebas unitarias, es una característica clave de la programación extrema y el desarrollo de software ágil, conocido como desarrollo basado en pruebas (TDD) o desarrollo de prueba primero. Las pruebas unitarias se pueden escribir para definir la funcionalidad antes de escribir código. Sin embargo, estas pruebas unitarias evolucionan y se expanden a medida que avanza la codificación, se descubren problemas y se refactora el código. El código se considera completo solo cuando todas las pruebas para todas las funciones requeridas pasan. Eso se puede probar a través de pruebas exploratorias manuales. Se considera más confiable debido a una mejor cobertura de código, y porque se ejecuta continuamente durante el desarrollo en lugar de una vez al final de un ciclo de desarrollo de cascadas. Los desarrolladores descubren defectos tan pronto como realizan cambios, cuando el costo de arreglarlos es más bajo. Finalmente, la refactorización del código es más segura cuando se usa pruebas unitarias; Convertir el código a una forma más simple con menos duplicación de código pero comportamiento equivalente, y cuando el código refactorizado está cubierto por pruebas unitarias, es mucho menos probable que se introduzcan nuevos defectos.

Algunas tareas de prueba de software, como las extensas pruebas de regresión de interfaz de bajo nivel, pueden ser laboriosas y que requieren mucho tiempo manualmente. Además, los métodos manuales pueden no ser siempre efectivos para encontrar ciertas clases de defectos. La automatización de la prueba ofrece la posibilidad de realizar este tipo de pruebas de manera eficiente.Una vez que se desarrollan las pruebas automatizadas, se pueden ejecutar rápida y repetidamente. Muchas veces este puede ser un método rentable de prueba de regresión para productos de software con largas vidas de mantenimiento. Incluso un pequeño parche en el ciclo de vida de la aplicación puede causar una ruptura en la funcionalidad existente que aún era válida 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 lo que se conoce como la "paradoja de pesticidas", donde un script ejecutado repetidamente deja de detectar errores más allá de su marco. En este caso, las pruebas manuales pueden ser una mejor inversión. Esta ambigüedad nuevamente lleva a la conclusión de que las decisiones sobre la automatización de las pruebas deben tomarse individualmente, teniendo en cuenta los requisitos del proyecto e idiosincrasias.Las herramientas de automatización de pruebas pueden ser costosas y a menudo se usan junto con pruebas manuales. La automatización puede ser rentable a largo plazo, especialmente cuando se usa repetidamente en las pruebas de regresión. Un buen candidato para la automatización de pruebas es los casos de prueba para el general Flujo de la aplicación, ya que debe ejecutarse cada vez que se realiza una mejora en la aplicación (prueba de regresión). La automatización de la prueba reduce el esfuerzo asociado con las pruebas manuales. Los humanos son necesarios para desarrollar y mantener cheques automatizados, y para revisar los resultados de las pruebas .

En pruebas automatizadas, los ingenieros de pruebas o el personal de garantía de calidad del software deben tener capacidades de codificación de software, porque los casos de prueba están escritos en forma de código fuente, y la salida se genera de acuerdo con las afirmaciones en TI en tiempo de ejecución. Algunas herramientas de automatización de pruebas permiten que la autorización de pruebas se realice a través de palabras clave en lugar de codificación, lo que no requiere programación.