types automation testing
Conozca los diferentes tipos de pruebas de automatización con algunos conceptos erróneos sobre la automatización de pruebas:
En esta segunda parte de serie de tutoriales de automatización de pruebas , Describiré brevemente los tipos de pruebas automatizadas y luego, lo más importante, aclararé algunos conceptos erróneos sobre la automatización de pruebas.
¿Qué son las pruebas de automatización?
Las pruebas de automatización se pueden definir como una forma de ejecutar un conjunto de pruebas una y otra vez sin tener que ejecutarlas manualmente. La introducción de pruebas de automatización en su estrategia de pruebas es una forma de ahorrar dinero y tiempo.
Lo que vas a aprender:
Tipos de pruebas de automatización
Los tipos de pruebas de automatización definen qué tipo de conjuntos de pruebas se pueden automatizar. Muchos evaluadores confunden este tema con los tipos de marcos de automatización que definen cómo diseñará su suite de pruebas en un paquete de automatización que se puede ejecutar convenientemente.
En este artículo, analizaremos de cerca los tipos de pruebas de automatización y, al final, analizaremos brevemente los marcos de automatización.
Entendamos las clasificaciones anteriores en detalle:
Automatización basada en el tipo de prueba
Automatización de pruebas funcionales:
Las pruebas funcionales se escriben para probar la lógica empresarial detrás de una aplicación. Automatizar estos significa escribir scripts para validar la lógica empresarial y la funcionalidad que se espera de la aplicación.
prueba unitaria vs ejemplo de prueba de integración
Automatización de pruebas no funcionales:
Las pruebas no funcionales definen los requisitos no comerciales de la aplicación. Estos son los requisitos relacionados con el rendimiento, la seguridad, las bases de datos, etc. Estos requisitos pueden permanecer constantes o se pueden escalar según el tamaño del software.
Automatización basada en la fase de prueba
Automatización de pruebas unitarias:
Estas pruebas se ejecutan durante la fase de desarrollo en sí, idealmente por parte del desarrollador después de completar el desarrollo y antes de entregar el sistema a los probadores para que lo prueben.
Automatización de pruebas API:
Las pruebas de API se ejecutan durante la fase de integración. Estos pueden ser ejecutados por el equipo de desarrollo o prueba y pueden ejecutarse antes o después de que se construya la capa de IU para la aplicación. Estas pruebas se dirigen a las pruebas en función de la solicitud y la respuesta sobre las que se construye la aplicación.
Automatización de pruebas basadas en UI:
Las pruebas basadas en la interfaz de usuario se ejecutan durante la fase de ejecución de la prueba. Estos son ejecutados específicamente por los probadores y solo se ejecutan una vez antes de que se les entregue la interfaz de usuario de la aplicación. Éstos prueban la funcionalidad y la lógica empresarial de la aplicación desde el front-end de la aplicación.
Automatización basada en el tipo de pruebas
Pruebas unitarias:
Las pruebas unitarias son las pruebas que se crean para probar el código de una aplicación y generalmente están integradas en el código mismo. Apuntan a los estándares de codificación, como la forma en que se escriben los métodos y funciones.
Estas pruebas las escriben con mayor frecuencia los propios desarrolladores; sin embargo, en el mundo actual, también se puede pedir a los probadores de automatización que las escriban.
La ejecución de estas pruebas y no obtener errores de ellas significará que su código se compilará y se ejecutará sin problemas de código. Por lo general, estas pruebas no se dirigen a los aspectos funcionales de la aplicación y, dado que se dirigen al código, es más apropiado automatizarlas para que puedan ejecutarse como y cuando lo requiera el desarrollador.
Pruebas de humo:
La prueba de humo es una prueba famosa que se realiza en el ciclo de vida de la prueba. Estas son pruebas posteriores a la compilación, se ejecutan inmediatamente después de que se proporciona cualquier compilación fuera de la aplicación para garantizar que la aplicación siga funcionando una vez finalizada la compilación.
Este es un pequeño conjunto de pruebas y es algo que se ejecutará varias veces y, por lo tanto, tiene sentido automatizarlo. Estas pruebas suelen ser de naturaleza funcional y, según el tipo de aplicación, se puede elegir una herramienta para ellas.
Pruebas API:
Las pruebas de API se han vuelto muy famosas en los últimos años. Las aplicaciones creadas en la arquitectura API pueden realizar esta prueba.
En las pruebas de API, los evaluadores validan la capa empresarial de la aplicación comprobando las combinaciones de solicitud y respuesta de las distintas API en las que está construida la aplicación. Las pruebas de API también se pueden realizar como parte de las pruebas de integración a continuación.
Pruebas de integración:
Prueba de integración, como su propio nombre sugiere, significa probar la aplicación integrando todos los módulos y verificando la funcionalidad de la aplicación.
Las pruebas de integración se pueden realizar mediante pruebas de API o mediante la capa de interfaz de usuario de la aplicación.
Pruebas de IU:
Las pruebas de IU se realizan desde la capa de IU o la interfaz de la aplicación. Estos pueden tener como objetivo probar la funcionalidad o simplemente probar los elementos de la interfaz de usuario de una aplicación.
Automatizar la interfaz de usuario para probar la funcionalidad es una práctica común. Sin embargo, la automatización de las funciones de la GUI es una de las automatizaciones más complicadas.
Pruebas de regresión:
Uno de los conjuntos de pruebas automatizados más comúnmente es el conjunto de pruebas de regresión. La regresión, como ya sabrá, es la prueba que se realiza al final de probar un nuevo módulo para asegurarse de que ninguno de los módulos existentes se haya visto afectado por él.
Se repite después de cada nueva iteración de prueba y los casos de prueba principales permanecen fijos con algunas adiciones nuevas después de una nueva iteración. Como se ejecuta con frecuencia, casi todos los equipos de prueba intentan automatizar este paquete.
Automatización como integración continua:
La integración continua puede volver a ejecutarse en las pruebas de regresión automatizadas en sí, sin embargo, para lograr IC, habilitamos la regresión o el conjunto de pruebas identificado para que se ejecute cada vez que se realiza una nueva implementación.
Pruebas de seguridad:
Las pruebas de seguridad pueden ser tanto funcionales como no funcionales, lo que implica probar la aplicación en busca de vulnerabilidades. Las pruebas funcionales se compondrán de pruebas relacionadas con la autorización, etc., mientras que los requisitos no funcionales pueden probar la inyección de SQL, secuencias de comandos entre sitios, etc.
Pruebas de rendimiento y control de calidad:
Las pruebas de rendimiento son pruebas no funcionales que se enfocan en los requisitos como pruebas de carga, estrés y escalabilidad de la aplicación.
Prueba de aceptacion:
Las pruebas de aceptación nuevamente caen bajo pruebas funcionales que generalmente se realizan para asegurar si se cumplen los criterios de aceptación dados por el cliente.
Hasta ahora, hemos descrito el tipo de pruebas que se pueden automatizar y varias clasificaciones de las mismas, todas las clasificaciones eventualmente conducirán a los mismos resultados finales de una suite de pruebas que se está automatizando. Como dijimos anteriormente, se requiere un poco de comprensión sobre en qué se diferencian de los marcos.
Una vez que haya identificado las pruebas que desea automatizar a partir de la clasificación anterior, deberá diseñar su lógica de manera que ejecute estas pruebas sin problemas, sin mucha intervención manual. Este diseño de un conjunto de pruebas manual en un conjunto de pruebas automatizado es donde entran los marcos.
Ahora exploraremos los 3 tipos principales de automatización de pruebas
- Examen de la unidad
- Prueba de API
- Pruebas de GUI
#1) Pruebas unitarias automatizadas
Pruebas unitarias automatizadas están escritos para probar el nivel de código. Los errores se identifican en las funciones, métodos y rutinas escritas por los desarrolladores.
cual es el mejor limpiador de pc
Algunas empresas solicitan a los desarrolladores que realicen las pruebas unitarias ellos mismos y otras contratan recursos de automatización de pruebas especializados. Estos recursos tienen acceso al código fuente y escriben pruebas unitarias para descifrar el código de producción.
Debido a la presencia de pruebas unitarias, siempre que el código se compila, todas las pruebas unitarias se ejecutan y nos dicen el resultado si todas las funciones están funcionando. Si falla alguna prueba unitaria, significa que ahora hay un error presente en el código de producción.
Algunas de las herramientas más populares presentes en el mercado incluyen NUnit y JUnit . Microsoft también proporciona su propio marco para pruebas unitarias llamado MSTest . Visite los sitios web de estas herramientas y le proporcionarán más ejemplos y tutoriales sobre cómo escribir pruebas unitarias.
#2) Pruebas de API / servicio web automatizadas
Una interfaz de programación de aplicaciones (API) hace posible que el software se comunique con otras aplicaciones de software. Al igual que cualquier otro software, las API deben probarse. En este tipo de pruebas, la GUI generalmente no está involucrada.
Lo que probamos aquí suele ser la funcionalidad, el cumplimiento y los problemas de seguridad. En aplicaciones web, podemos probar la Solicitud y Respuesta de nuestra aplicación si son seguras y encriptadas o no.
Este es uno de los ejemplos en los que podemos utilizar API Testing. La herramienta más popular para las pruebas de API es JABÓN que tiene versiones gratuitas y de pago. También hay otras herramientas que puede utilizar según sus necesidades.
#3) Pruebas de GUI automatizadas.
Este tipo de prueba automatizada es la forma más difícil de automatización, ya que implica la prueba de una interfaz de usuario de la aplicación.
Es difícil ya que las GUI están muy sujetas a cambios. Pero este tipo de pruebas también se acerca más a lo que harán los usuarios con nuestra aplicación. Como el usuario utilizará el mouse y el teclado, las pruebas de GUI automatizadas también imitan el mismo comportamiento al hacer uso del mouse y el teclado para hacer clic o escribir en los objetos presentes en la interfaz de usuario.
Debido a esto, podemos encontrar errores temprano y se puede usar en muchos escenarios, como pruebas de regresión o completar formularios, lo que lleva demasiado tiempo.
Las herramientas de prueba de GUI más populares incluyen Pruebas funcionales unificadas de Micro Focus (UFT) , Selenio , Prueba completa y Interfaz de usuario codificada de Microsoft (que forma parte de las ediciones Ultimate y Premium de Visual Studio).
Al igual que los tipos de pruebas de automatización, también existen varios tipos de marcos.
Marcos de automatización
Algunos marcos de automatización de uso común incluyen:
- Lineal (grabación y reproducción)
- Impulsado por palabras clave
- Impulsado por datos
- Modelo de objeto de página
- Modular
Lectura adicional => Marcos de automatización
Como puedes ver el primer paso en el proceso de automatización es identificar el tipo de automatización, luego puedes identificar el marco a diseñar y teniendo esto en cuenta puedes seleccionar las herramientas que se adapten a tus necesidades.
Herramientas de automatización
Según el tipo de prueba a la que se dirige y el tipo de marco que puede desear construir en torno a él, las siguientes herramientas están disponibles para usar:
- Selenio : Herramienta muy poderosa para probar aplicaciones web. Proporciona soporte para múltiples navegadores.
- Junit y Nunit: Herramientas que los desarrolladores utilizan principalmente para las pruebas unitarias.
- QTP : Excelente herramienta para aplicaciones no web y viene con un repositorio de objetos integrado.
- Sikuli: Herramienta de código abierto para pruebas de GUI.
- UI de jabón: Herramienta para pruebas de API.
- Está seguro: Biblioteca para crear un marco de prueba de API.
- appium : Herramienta que admite pruebas móviles, pruebas de aplicaciones nativas, pruebas de aplicaciones web híbridas y móviles.
- Jmeter : Una herramienta que se utiliza para pruebas de rendimiento.
- TestNG: TestNG no es una herramienta de automatización en sí misma, sin embargo, brinda un gran soporte a los marcos de automatización construidos con selenio, appium, tenga la seguridad, etc.
Lectura adicional => Herramientas de automatización de pruebas
Conceptos erróneos sobre las pruebas de automatización
A lo largo de los años, he escuchado algunos conceptos erróneos sobre la automatización de pruebas. Creo que también debería eliminarlos en este artículo.
Concepto erróneo # 1. La automatización está aquí para reemplazar a los probadores manuales.
La automatización de pruebas sirve para ayudar a los evaluadores a realizar pruebas de forma más rápida y fiable. Nunca podrá reemplazar a los humanos.
Piense en la automatización de pruebas como un automóvil. Si caminas, tardarás unos 20 minutos en llegar a tu casa. Pero si usa un automóvil, llegará en dos minutos. El conductor del automóvil sigue siendo usted, un ser humano, pero ... el automóvil ayuda al ser humano a lograr su objetivo más rápido. Además, se ahorra la mayor parte de su energía, ya que no caminaba. Por lo tanto, puede utilizar esta energía para realizar cosas más importantes.
Lo mismo ocurre con las pruebas de automatización. Lo usa para probar rápidamente la mayoría de sus pruebas repetidas, largas y aburridas y ahorrar tiempo y energía para concentrarse y probar funciones nuevas e importantes.
Como James Bach dijo una cita maravillosa:
'Las herramientas no prueban. Solo la gente prueba. Las herramientas solo realizan acciones que 'ayudan' a las personas a realizar pruebas. '
Las herramientas pueden hacer clic en los objetos. Pero un tester manual siempre indicará dónde hacer clic. Creo que ahora entiendes mi punto.
Concepto erróneo # 2 . Todo bajo el sol se puede automatizar
Si intenta automatizar el 100% de sus casos de prueba, tal vez pueda hacerlo, pero si pudiera hacerlo, entonces nuestro primer punto se vuelve falso. Si todo está automatizado, ¿qué hará un probador manual?
¿Confundido? ¿Correcto?
En realidad, el punto es que no puede automatizar el 100% de sus casos de prueba. Porque nosotros, como probadores, creemos que ninguna aplicación puede probarse al 100%. Siempre habrá algunos escenarios que extrañaremos. Siempre habrá errores que se producirán solo cuando los clientes usen su aplicación.
Si la aplicación no se puede probar al 100%, ¿cómo puede prometer una automatización del 100%?
Además, existe una pequeña posibilidad de que pueda automatizar todos sus casos de prueba existentes. Siempre hay escenarios que son difíciles de automatizar y más fáciles de hacer manualmente.
Por ejemplo , Un usuario ingresará los datos, el segundo usuario aprobará los datos, el tercer usuario verá los datos y el cuarto usuario tiene prohibido ver los datos. Estos escenarios pueden automatizarse, pero requerirán mucho tiempo y esfuerzo. Por lo tanto, será más fácil si lo hace manualmente.
Recuerde, usamos automóviles para recorrer distancias, pero puede haber señales largas en el camino, habrá consumo de combustible, habrá problemas con el espacio de estacionamiento, cargos por estacionamiento y mucho más dolor de cabeza. En algunos escenarios, simplemente caminamos y llegamos a nuestro destino :) .
Por lo tanto, no debe intentar automatizar todo. Automatice solo aquellos escenarios que sean importantes y aquellos que requieran mucho tiempo para hacerlo manualmente.
Concepto erróneo # 3 . La automatización solo implica grabación y reproducción.
Por favor, no vivas en un mundo de fantasía. Esta fantasía en realidad es creada por anuncios falsos de diferentes proveedores de herramientas de automatización. Dicen que solo graba y reproduce sus pasos y sus casos de prueba se automatizarán. Bueno, ¡eso es una gran mentira!
La automatización lo es todo y no solo la grabación y reproducción. Los ingenieros de automatización pura normalmente no utilizan la función de grabación y reproducción en absoluto. La grabación y la reproducción se utilizan generalmente para tener una idea de cómo la herramienta genera un guión para nuestros pasos.
Una vez que conocemos las secuencias de comandos, siempre las usamos para crear pruebas automatizadas. Recuerda, debes saber programación si quieres hacer pruebas de automatización . Por otro lado, no se desanime si no sabe programación. Como cualquier otra tarea, la programación también se puede aprender con práctica y dedicación.
Conozco personas que ni siquiera tienen experiencia en informática, pero que aprenden a programar y ahora son increíbles ingenieros de automatización. En Microsoft, contratan probadores que pueden hacer programación. Se les llama SDET (Ingenieros de desarrollo de software para prueba). La primera línea de la descripción del trabajo dice 'SDET's escribe mucho código ...'.
Aprenda a programar, no se escape. Te convertirá en un probador increíble .
Conclusión
Espero que este artículo te haya ayudado a aclarar algunos conceptos relacionados con la automatización de pruebas.
Hemos cubierto un alto nivel de varios tipos de pruebas de automatización, con varias formas de clasificar.
Las principales clasificaciones incluyen:
- Automatización basada en el tipo de prueba (funcional o no funcional).
- Automatización basada en la Fase de prueba (Unidad, API o UI).
- Automatización basada en los distintos tipos de pruebas (múltiples tipos de pruebas).
También hemos enumerado las diversas herramientas que se pueden utilizar para este tipo de pruebas automatizadas.
En nuestro próximo artículo, discutiremos el procedimiento paso a paso de cómo iniciar la automatización de pruebas en su organización .
PREV Tutorial #1 | SIGUIENTE Tutorial # 3
Lectura recomendada
- Pruebas de carga con tutoriales de HP LoadRunner
- Mejores herramientas de prueba de software 2021 [Herramientas de automatización de pruebas de control de calidad]
- ¿Los probadores están perdiendo el control sobre las pruebas debido a la automatización?
- Desafíos de las pruebas manuales y de automatización
- Proceso de prueba de automatización de 10 pasos: cómo iniciar las pruebas de automatización en su organización
- ¿Es usted un experto en pruebas manuales o de automatización? ¡Trabaja a tiempo parcial para nosotros!
- Las 11 mejores herramientas de automatización para probar aplicaciones de Android (herramientas de prueba de aplicaciones de Android)
- Los 10 mejores libros de pruebas de software (libros de pruebas manuales y de automatización)