Pruebas automatizadas
La versión actual de la página aún no ha sido revisada por colaboradores experimentados y puede diferir significativamente de la
versión revisada el 30 de agosto de 2018; las comprobaciones requieren
6 ediciones .
La prueba de software automatizada es parte del proceso de prueba en la fase de control de calidad del proceso de desarrollo de software . Utiliza herramientas de software para ejecutar pruebas y verificar los resultados de la ejecución, lo que ayuda a reducir el tiempo de prueba y simplifica el proceso de prueba.
Historia
Los primeros intentos de "automatización" aparecieron en la era de los sistemas operativos DOS y CP/M . Luego consistió en dar comandos a la aplicación a través de la línea de comandos y analizar los resultados. Un poco más tarde, se agregaron llamadas remotas a través de la API para trabajar en la red . Primero Las pruebas automatizadas se mencionan en el libro de Frederick Brooks The Mythical Man-Month , que habla sobre las perspectivas del uso de pruebas unitarias . Pero la verdadera automatización de pruebas comenzó a desarrollarse solo en la década de 1980.
Aproximaciones
Hay dos enfoques principales para la automatización de pruebas: pruebas a nivel de código y pruebas de interfaz de usuario (específicamente, pruebas de GUI). El primer tipo incluye, en particular, las pruebas unitarias . Al segundo: imitación de las acciones del usuario : pruebas funcionales (utilizando marcos de prueba especiales ).
Automatización de GUI
La forma más común de automatización es la prueba de aplicaciones a través de una interfaz gráfica de usuario ( GUI ) . La popularidad de este tipo de pruebas se debe a dos factores: en primer lugar, la aplicación se prueba de la misma manera que una persona la usará y, en segundo lugar, es posible probar la aplicación sin tener acceso al código fuente.
La automatización de GUI ha evolucionado a lo largo de 4 generaciones de herramientas y técnicas:
- Las herramientas de captura/ reproducción registran las acciones del probador durante la prueba manual . Le permiten realizar pruebas sin intervención humana directa durante mucho tiempo, aumentando significativamente la productividad y eliminando la repetición "estúpida" de acciones repetitivas durante las pruebas manuales. Al mismo tiempo, cualquier pequeño cambio en el software bajo prueba requiere una reescritura de las pruebas manuales. Por lo tanto, esta primera generación de herramientas no es eficiente ni escalable.
- El scripting , una forma de programación en lenguajes específicamente diseñados para automatizar las pruebas de software, alivia muchos de los problemas de las herramientas de grabación y reproducción. Pero el desarrollo lo realizan programadores de alto nivel que trabajan por separado de los evaluadores que ejecutan directamente las pruebas. Además, los scripts son los más adecuados para probar las GUI y no se pueden inyectar, empaquetar ni combinar en un sistema de ninguna manera. Finalmente, los cambios en el software que se está probando requieren cambios complejos en los scripts correspondientes y, después de todo, mantener una biblioteca cada vez mayor de scripts de prueba se convierte en una tarea insuperable.
- Las pruebas basadas en datos son una metodología que se utiliza en la automatización de pruebas. La peculiaridad es que los scripts de prueba se ejecutan y verifican sobre la base de los datos que se almacenan en un almacén de datos o base de datos central. La función de la base de datos puede ser realizada por recursos ODBC, archivos csv o xls, etc. Las pruebas basadas en datos son la combinación de varios scripts de prueba que interactúan y sus fuentes de datos en un marco utilizado en la metodología. En este marco, las variables se utilizan tanto para valores de entrada como para valores de prueba de salida: en un script de prueba, generalmente se codifica la navegación a través de la aplicación, la lectura de fuentes de datos y las pruebas de registro. Entonces, la lógica que se ejecutará en el script también depende de los datos.
- La automatización de pruebas basadas en palabras clave implica dividir el proceso de creación de casos en 2 etapas: la etapa de planificación y la etapa de implementación . En este caso, la prueba final no es un código de programa, sino una descripción de una secuencia de acciones con sus parámetros (por ejemplo, "crear un usuario en la base de datos con inicio de sesión XXX y contraseña YYY"). En este caso, el marco es responsable de la implementación directa de palabras clave (acciones), y es suficiente que el diseñador de pruebas tenga una idea sobre todo el conjunto de acciones implementadas en el marco. Esto hace posible crear pruebas para personas que no tienen conocimientos de programación.
Problemas
Uno de los principales problemas de las pruebas automatizadas es su complejidad: a pesar de que te permite eliminar algunas de las operaciones de rutina y acelerar la ejecución de las pruebas, se pueden gastar grandes recursos en actualizar las propias pruebas. Esto se aplica a ambos tipos de automatización. Al refactorizar , a menudo también es necesario actualizar las pruebas unitarias, y cambiar el código de prueba puede llevar tanto tiempo como cambiar el código principal. Por otro lado, al cambiar la interfaz de la aplicación, es necesario reescribir todas las pruebas que están asociadas a las ventanas actualizadas, lo que, con una gran cantidad de pruebas, puede consumir importantes recursos.
Aplicaciones
Hay muchas aplicaciones para la automatización de pruebas. El más popular de ellos según los resultados de 2007: [1]
El uso de estas herramientas ayuda a los evaluadores a automatizar las siguientes tareas:
- instalación del producto
- creando datos de prueba
- interacción GUI
- definición del problema
Sin embargo, las pruebas automatizadas no pueden reemplazar por completo las pruebas manuales. La automatización de todas las pruebas es un proceso muy costoso y, por lo tanto, las pruebas automáticas son solo una adición a las pruebas manuales. El mejor caso de uso para las pruebas automatizadas es la prueba de regresión .
Caja de herramientas
Véase también
Notas
- ↑ SoftJournal 'septiembre de 2007/ SoftJournal 'septiembre de 2007 (enlace no disponible) . Consultado el 12 de abril de 2010. Archivado desde el original el 23 de marzo de 2010. (indefinido)
Enlaces