Marco de automatización de pruebas: ¿Qué es? Architectura y tipos
¿Qué es el marco en las pruebas de automatización?
A Marco de automatización de pruebas es un conjunto de pautas como estándares de codificación, manejo de datos de prueba, tratamiento de repositorios de objetos, etc., que cuando se siguen durante la creación de scripts de automatización producen resultados beneficiosos como una mayor reutilización del código, mayor portabilidad, menor costo de mantenimiento de scripts, etc. Estas son solo pautas y no reglas; no son obligatorias y aún puede crear scripts sin seguir las pautas. Pero se perderá las ventajas de tener un marco.
¿Por qué necesitas un marco?
Consideremos un ejemplo para comprender por qué necesita un marco.
Estoy seguro de que ha asistido a un seminario/conferencia/conferencia en el que se pidió a los participantes que cumplieran las siguientes pautas:
- Los participantes deberán ocupar sus asientos 5 minutos antes del inicio de una conferencia.
- Lleve consigo una libreta y un bolígrafo para tomar notas.
- Lea el resumen para tener una idea de de qué se tratará la presentación.
- Los teléfonos móviles deben estar en silencio.
- Utilice las puertas de salida en el extremo opuesto al orador si necesita salir en medio de la conferencia.
- Las preguntas se tomarán al final de la sesión.
¿Crees que puedes realizar un seminario? SIN observando estas pautas👍
la respuesta es un gran ¡SÍ! Ciertamente, puedes llevar a cabo un seminario/conferencia/conferencia/demostración sin las pautas anteriores... de hecho, ¡algunos de nosotros no las seguiremos aunque estén establecidas!
Pero si se siguen las pautas, se obtendrán resultados beneficiosos, como una menor distracción de la audiencia durante las conferencias, una mayor retención de los participantes y una mayor comprensión del tema.
Con base en lo anterior, una El marco se puede definir como un conjunto de pautas que, cuando se siguen, producen resultados beneficiosos.
Tipos de marcos de automatización de pruebas
A continuación se muestran los diferentes tipos de marcos de pruebas automatizados:
- 1) secuencias de comandos lineales
- 2) La biblioteca de pruebas ArchiMarco de tecnología.
- 3) El basado en datos Pruebas Marco de referencia.
- 4) El marco de pruebas basado en palabras clave o basado en tablas.
- 5) El marco de automatización de pruebas híbridas.
Veámoslos en detalle –
1) Secuencias de comandos lineales: grabación y reproducción
Es el más simple de todos los marcos de automatización de pruebas y también se conoce como “Grabar y reproducir”. En este Pruebas de automatización Framework, Tester registra manualmente cada paso (navegación y entradas del usuario), inserta puntos de control (pasos de validación) en la primera ronda. Luego, reproduce el guión grabado en las rondas siguientes.
Ejemplo: Considere iniciar sesión en Solicitud de reserva de vuelo y comprobar si la aplicación se ha cargado al iniciar sesión correctamente. Aquí, el evaluador simplemente registrará los pasos y agregará pasos de validación.
SystemUtil.Run "flight4a.exe","","","open" Dialog("Login").WinEdit("Agent Name:").Set "Guru99" Dialog("Login").WinEdit("Password:").Set "Mercury" Dialog("Login").WinButton("OK").Click 'Check Flight Reservation Window has loaded after successful log-on Window("Flight Reservation").Check CheckPoint("Flight Reservation")
Ventajas
- La forma más rápida de generar un script
- No se requiere experiencia en automatización
- La forma más sencilla de conocer las funciones de la herramienta de prueba
Desventajas
- Poca reutilización de guiones
- Los datos de prueba están codificados en el script.
- Pesadilla de mantenimiento
2) La biblioteca de pruebas Archimarco de tecnología
También se le conoce como “Secuencias de comandos estructuradas” or "Descomposición funcional".
En este marco de pruebas de automatización, los scripts de prueba se registran inicialmente mediante "Grabar y reproducir"Método. Later, las tareas comunes dentro de los scripts se identifican y agrupan en Funciones. Estas funciones son llamadas por el script de prueba principal llamado Destornillador de diferentes maneras para crear casos de prueba.
Ejemplo: Usando el mismo ejemplo anterior, la función para iniciar sesión en Reserva de vuelos se verá así.
Function Login() SystemUtil.Run "flight4a.exe","","","open" Dialog("Login").WinEdit("Agent Name:").Set "Guru99" Dialog("Login").WinEdit("Password:").Set "Mercury" Dialog("Login").WinButton("OK").Click End Function
Ahora, llamará a esta función en el script principal de la siguiente manera
Call Login() --------------------------- Other Function calls / Test Steps. ---------------------------
Ventajas
- Se logra un mayor nivel de reutilización de código en secuencias de comandos estructuradas en comparación con "Grabación y reproducción"
- Los scripts de automatización son menos costosos de desarrollar debido a una mayor reutilización del código.
- Mantenimiento de scripts más sencillo
Desventajas
- Se necesita experiencia técnica para escribir scripts utilizando el marco de la biblioteca de pruebas.
- Se necesita más tiempo para planificar y preparar guiones de prueba.
- Los datos de prueba están codificados dentro de los scripts
3) El marco de pruebas basado en datos
En este marco, si bien Caso de prueba La lógica reside en los scripts de prueba, los datos de prueba se separan y se mantienen fuera de los scripts de prueba. Los datos de prueba se leen desde archivos externos (archivos Excel, archivos de texto, archivos CSV, fuentes ODBC, objetos DAO, objetos ADO) y se cargan en las variables dentro del script de prueba. Las variables se utilizan tanto para valores de entrada como para valores de verificación. Los propios scripts de prueba se preparan utilizando Linear Scripting o Test Library Framework.
Ejemplo: Desarrollar el script de inicio de sesión de reserva de vuelo utilizando este método implicará dos pasos.
Paso 1) Cree una prueba: archivo de datos que podría ser Excel, CSV o cualquier otra fuente de base de datos.
Nombre del agente | Contraseña |
---|---|
Jimmy | Mercury |
Tina | MERCURIO |
Bill | Mercurio |
Paso 2) Desarrolle un script de prueba y haga referencias a su fuente de datos de prueba.
SystemUtil.Run "flight4a.exe","","","open" Dialog("Login").WinEdit("Agent Name:").Set DataTable("AgentName", dtGlobalSheet) Dialog("Login").WinEdit("Password:").Set DataTable("Password", dtGlobalSheet) Dialog("Login").WinButton("OK").Click 'Check Flight Reservation Window has loaded Window("Flight Reservation").Check CheckPoint("Flight Reservation") **Note "dtGlobalSheet" is the default excel sheet provided by QTP.
Ventajas
- Los cambios en los scripts de prueba no afectan los datos de prueba.
- Los casos de prueba se pueden ejecutar con múltiples conjuntos de datos
- Se puede ejecutar una variedad de escenarios de prueba simplemente variando los datos de prueba en el archivo de datos externos.
Desventajas
- Se necesita más tiempo para planificar y preparar tanto los guiones de prueba como los datos de prueba.
4) El marco de pruebas basado en palabras clave o basado en tablas
El desarrollo del marco de automatización basado en palabras clave o tablas requiere tablas de datos y palabras clave, independiente de la herramienta de automatización de prueba utilizado para ejecutarlos. Las pruebas se pueden diseñar con o sin la Aplicación. En una prueba basada en palabras clave, la funcionalidad de la aplicación bajo prueba se documenta en una tabla, así como en instrucciones paso a paso para cada prueba.
Hay tres componentes básicos de un marco impulsado por palabras clave, a saber: palabra clave, mapa de aplicación y función del componente.
¿Qué es una palabra clave?
Una palabra clave es una acción que se puede realizar en un componente de la GUI. Por ejemplo, para un cuadro de texto de un componente de la GUI, algunas palabras clave (acción) serían InputText, VerifyValue, VerifyProperty, etc.
¿Qué es el Mapa de Aplicación?
Un mapa de aplicación proporciona referencias con nombre para componentes GUI. Los mapas de aplicaciones no son más que “Repositorio de objetos"
¿Qué es la función de los componentes?
Las funciones de componentes son aquellas funciones que manipulan o interrogan activamente el componente GUI. Un ejemplo de una función sería hacer clic en el botón web con todo el manejo de errores, ingresar datos en una edición web con todo el manejo de errores. Las funciones de los componentes pueden depender o ser independientes de la aplicación.
Ejemplo: Para comprender la Vista de palabras clave, tomemos el mismo ejemplo. Implica 2 pasos
Paso 1: Creación de una tabla de datos (diferente de la tabla de datos de prueba creada en el marco basado en datos). Esta tabla de datos contiene la acción que se realizará en los objetos de la GUI y los argumentos correspondientes, si los hubiera. Cada fila representa un paso de prueba.
Objeto | Acción | |
---|---|---|
(MAPA de aplicación) | (PALABRAS CLAVE) | Argumento |
WinEdit (nombre del agente) | Set | Guru99 |
WinEdit(Contraseña) | Set | Mercury |
Botón Win(OK) | Hagan clic | |
Ventana (Reserva de vuelo) | Verificar | Existe |
Paso 2: Escritura de código en forma de funciones de componentes.
Una vez que haya creado su(s) tabla(s) de datos, simplemente escriba un programa o un conjunto de scripts que lea cada paso, ejecute el paso según la palabra clave contenida en el campo Acción, realice una verificación de errores y registre cualquier información relevante. Este programa o conjunto de scripts sería similar al pseudocódigo siguiente:
Function main() { Call ConnectTable(Name of the Table) { //Calling Function for connecting to the table. while (Call TableParser() != -1) //Calling function for Parsing and extracting values from the table. { Pass values to appropriate COMPONENT functions.Like Set(Object Name, Argument) ex.Set(Agent Name, Guru99). } } Call CloseConnection() //Function for Closing connection after all the operation has been performed. } //End of main
Eso es todo en el marco basado en palabras clave.
La ventaja de Keyword Driven Framework es que las palabras clave se pueden reutilizar. Para entender esto, supongamos que desea verificar la operación de inicio de sesión para un sitio web, por ejemplo, YAHOO MAIL. La tabla se verá así:
Objeto | Acción | |
---|---|---|
(MAPA DE APLICACIÓN) | (PALABRA CLAVE) | Argumento |
WebEdit(Nombre de usuario) | Set | abc@yahoo.com |
WebEdit(Contraseña) | Set | xxxxx |
Botón Web(Aceptar) | Hagan clic | |
Ventana (Yahoo Mail) | Verificar | Cargas |
Si observa que en este caso el conjunto de palabras clave, el clic y la verificación siguen siendo los mismos para los cuales las funciones de los componentes correspondientes ya están desarrolladas. Todo lo que necesita hacer es cambiar el mapeo de aplicaciones (repositorio de objetos) de la reserva de vuelo anterior a Yahoo. Mail , con un cambio en los valores de los argumentos y el mismo script funcionará.
Ventajas
- Proporciona una alta reutilización del código
- Herramienta de prueba independiente
- Independientemente de la aplicación bajo prueba, el mismo script funciona para AUT (con algunas limitaciones)
- Las pruebas se pueden diseñar con o sin AUT
Desventajas
- Como la inversión inicial es bastante alta, los beneficios sólo se pueden obtener si la aplicación es considerablemente grande y los scripts de prueba se van a mantener durante bastantes años.
- Se requiere alta experiencia en automatización para crear el marco basado en palabras clave.
NOTA: Aunque Micro Focus UFT se anuncia como KeyWord Driven Framework, no es posible lograr una completa independencia de la herramienta de prueba y de la aplicación utilizando HP UFT.
5) El marco de automatización de pruebas híbridas
Como sugiere el nombre, este marco es la combinación de uno o más marcos de automatización discutidos anteriormente, aprovechando sus fortalezas y tratando de mitigar sus debilidades. El marco de automatización de control de calidad de pruebas híbridas es en lo que evolucionan la mayoría de los marcos de automatización de pruebas con el tiempo y múltiples proyectos. La industria máxima utiliza el marco de palabras clave en una combinación del método de descomposición de funciones.
PS: Otros marcos de automatización que vale la pena mencionar son
Marco de modularidad de prueba
En este marco, una tarea común en el script de prueba se agrupa como Módulos.
Ejemplo: El uso de acciones en QTP puede crear scripts modulares
Script de muestra para iniciar sesión
SystemUtil.Run "flight4a.exe","","","open" Dialog("Login").WinEdit("Agent Name:").Set "Guru99" Dialog("Login").WinEdit("Password:").Set "Mercury" Dialog("Login").WinButton("OK").Click 'End of Script
Ahora puedes llamar a esta acción en el script principal de la siguiente manera:
RunAction ("Login[Argument]", oneIteration)
Pruebas de procesos de negocio (BPT)
Estos marcos de automatización dividen grandes procesos comerciales en componentes que pueden reutilizarse varias veces en los mismos scripts de prueba o en diferentes. Por ejemplo, el proceso comercial de reservar un vuelo se divide en componentes como inicio de sesión, búsqueda de vuelos, reserva, pago y cierre de sesión, que se pueden reutilizar en el mismo proceso comercial o en procesos diferentes. Además, BPT facilita una coordinación más estrecha entre las PYME y los ingenieros de automatización.
Beneficios del marco de automatización de pruebas Architectura
Los siguientes son los beneficios de la arquitectura del marco de automatización de pruebas:
- Un marco de automatización de pruebas ayuda a reducir los riesgos y los costos.
- Mejora la eficiencia de las pruebas.
- Ayuda a reducir el coste de mantenimiento.
- Permite la reutilización de código.
- Permite alcanzar la máxima cobertura de prueba.
- Maximiza la funcionalidad de la aplicación.
- Ayuda a reducir la duplicación de casos de prueba.
- Ayuda a mejorar la eficiencia y el rendimiento de las pruebas con la automatización de pruebas.
Resumen
- Un marco es un conjunto de pautas como estándares de codificación, manejo de datos de prueba, tratamiento del repositorio de objetos, etc. que, cuando se siguen durante la automatización de scripts, producen resultados beneficiosos como una mayor reutilización de código, mayor portabilidad, reducción del costo de mantenimiento de scripts, etc.
- Linear Scripting es el más simple de todos los marcos de automatización y también se conoce como "Grabación y reproducción".
- Biblioteca de pruebas Architecture Framework también se conoce como "Scripting estructurado" o "Descomposición funcional".
- En el marco de pruebas basadas en datos, la lógica del caso de prueba reside en los scripts de prueba y los datos de la prueba se separan y se mantienen fuera de los scripts de prueba.
- El marco basado en palabras clave o basado en tablas requiere el desarrollo de tablas de datos y palabras clave, independientemente de la herramienta de automatización de pruebas utilizada para ejecutarlas.
- El marco de automatización híbrida es en lo que evolucionan la mayoría de los marcos de automatización de pruebas con el tiempo y múltiples proyectos.