Cómo utilizar el marco Robot para escribir excelentes casos de prueba
Para obtener más información sobre este tema, puede consultar estos fantásticos recursos:
Escribir pruebas de aceptación automatizadas y mantenibles por Dale H. Emery
Cómo estructurar una Conjunto de pruebas de aceptación escalable y mantenible Por Andreas Ebbert-Karroum
Denominación
Denominación de un conjunto de pruebas
El nombre del conjunto de pruebas debe describir el propósito del conjunto lo más cerca posible.
Los nombres pueden ser relativamente largos, pero cualquier valor superior a 40 caracteres es demasiado largo.
Recuerde que los nombres de los paquetes de Robotframework se convierten directamente a partir de los nombres de archivos/directorios. Se eliminan las extensiones de archivo, los guiones bajos se convierten en espacios y, si se utiliza una palabra en minúscula, la primera letra se convierte en mayúscula. Por ejemplo, login_test.txt se convertirá en prueba de inicio de sesión y DHCP_and_DNS se convertirá en DHCP y DNS.
Nombre de los casos de prueba
El nombre del caso de prueba debe ser similar a la descripción del nombre de la suite.
Si un conjunto contiene varios casos de prueba similares y los propios conjuntos de pruebas tienen buenos nombres, entonces los nombres de los casos de prueba pueden ser cortos.
Los nombres en los archivos de casos de prueba deben expresar exactamente lo que necesita hacer.
Nomenclatura de palabras clave
Del mismo modo, los nombres de las palabras clave deben ser claros y específicos.
Debería poder expresar qué hace la palabra clave, no cómo lo hace.
Las palabras clave deben tener distintos niveles de abstracción (por ejemplo, "ingresar caracteres" o "el usuario inicia sesión en el sistema").
Generación y descomposición de nombres
Intenta utilizar nombres para describir el trabajo realizado por los pasos.
Tal vez puedas usar una palabra clave ya existente.
Si la generación o descomposición contiene pasos no relacionados, puedes usar un nombre más abstracto.
Enumerar pasos en nombres implica problemas de duplicación y mantenimiento (por ejemplo, iniciar sesión en el sistema, agregar usuarios, activar alertas y consultar saldos).
Tal vez use algún nombre común como "Sistema de inicialización".
Todos los que utilicen estos casos de prueba deben comprender qué hacen estas operaciones de generación o descomposición.
Documentación
Documentación del conjunto de pruebas
Suele ser una buena idea agregar documentación al nivel más bajo del conjunto que contiene los casos de prueba.
Los paquetes de alto nivel no requieren documentación frecuente.
La documentación debe contener la información general necesaria, como los motivos para crear estos casos de prueba, puntos clave a los que se debe prestar atención en el entorno de prueba, etc.
La documentación no debe repetir simplemente el nombre del paquete.
Si no tienes documentación real, es mejor que no la agregues.
La documentación no debe contener demasiados detalles sobre los casos de prueba.
Los casos de prueba en sí deben ser lo suficientemente claros y fáciles de entender.
La información duplicada genera desperdicio y es incómoda de mantener.
Puedes añadir enlaces a determinados detalles del documento.
Si necesita agregar algunos grupos de "nombre-valor" al documento, como (versión: 1.0 o sistema operativo: Linux), considere usar metadatos del conjunto de pruebas.
Documentación de casos de prueba
Los casos de prueba generalmente no requieren documentación.
Los nombres de la suite y la documentación y los nombres de los casos de uso ya proporcionan suficiente información general.
La estructura de los casos de prueba debe ser lo suficientemente clara sin documentación ni otros comentarios.
Las etiquetas son generalmente más flexibles y proporcionan más funcionalidad que los documentos.
Cuando la documentación del caso de prueba sea útil, no se preocupe por no agregarla.
Documentación de palabras clave definidas por el usuario
Si la palabra clave es muy simple y directa, no se necesita documentación.
Un buen nombre y una estructura clara lo dicen todo.
Un uso importante de los documentos de palabras clave definidas por el usuario es registrar información sobre parámetros y valores de retorno.
Libdoc.py genera la documentación que aparece en RIDE (como dónde se completa la palabra clave) y en los archivos de recursos.
La estructura del conjunto de pruebas
Los casos de prueba del conjunto deben estar relacionados entre sí.
Si los casos de prueba tienen las mismas partes de generación o descomposición, deberían pertenecer a una suite.
No tenga más de 10 casos de prueba en una suite a menos que estén basados en datos.
Los casos de prueba deben ser independientes.
Inicializarlos por generación y descomposición.
A veces, si los casos de prueba están inevitablemente relacionados entre sí
Por ejemplo, esto puede deberse a que lleva demasiado tiempo hacer que todos los casos sean independientes durante la inicialización.
Solo unos pocos casos de prueba son relevantes (4 o 5 como máximo)
El siguiente caso de prueba se utiliza para verificar los resultados del anterior. (Utilice la variable ${PREV TEST STATUS})
Estructura de los casos de prueba
Los casos de prueba deben ser fáciles de entender.
Un caso de prueba sólo prueba una cosa.
Por supuesto, este asunto en sí puede ser grande o pequeño.
Elige un nivel de abstracción adecuado.
Utilizar consistentemente niveles de abstracción (Principio de nivel único de abstracción)
Incluir solo información relevante para la prueba.
Los casos de uso se pueden dividir en dos tipos
Casos de prueba de flujo de trabajo
Casos de prueba basados en datos
Casos de prueba de flujo de trabajo
Suele tener las siguientes secciones:
Condiciones previas (opcional, normalmente en la sección de generación)
Operaciones (realizar determinadas operaciones en el sistema bajo prueba)
Validación (¡debe tener una parte de validación!
Limpieza (opcional, generalmente en la parte de descomposición para garantizar que el caso de uso se haya ejecutado)
Las palabras clave se utilizan para describir la función de este caso de uso
Utilice nombres de palabras clave claros y un nivel apropiado de abstracción
Debe contener suficiente información para iniciar la ejecución manual
Nunca se requiere documentación. O comunicarse para decirle qué está haciendo el caso de uso.
Los diferentes casos de uso pueden tener diferentes niveles de abstracción.
Las pruebas funcionales detalladas son más precisas. abstracción.
Un caso de prueba solo puede usar un nivel de abstracción.
Diferentes estilos
Se deben usar los casos de prueba subyacentes detallados y de integración. a detalles técnicos
La "definición ejecutable" está relacionada con los requisitos
Usar el idioma del dominio (¿terminología?
Todos (incluidos los clientes y propietarios de productos) debería poder entender
Lógica sin complicaciones
Sin bucles for o construcciones if/else /p>
Tenga cuidado al asignar valores a las variables
Los casos de prueba no deberían ser tan difíciles de leer como los scripts
No más de 10 pasos, cuantos menos, mejor p>Casos de prueba basados en datos
Cada caso de prueba. tiene una palabra clave avanzada
Diferentes parámetros crearán diferentes pruebas
Palabras clave normalmente Contiene un proceso similar al descrito por el caso de prueba del flujo de trabajo en el mismo archivo de caso de uso
Se recomienda utilizar la función de plantilla de prueba.
No es necesario revisar las palabras clave varias veces. >
Es más fácil probar múltiples variantes en un caso de uso.
Se recomienda nombrar los encabezados de las columnas cuando sea posible.
Si realmente necesita una gran cantidad de casos de prueba, considere configurarlos como modelos de dependencia externa.
Las palabras clave definidas por el usuario
deben ser fáciles de entender
Los mismos criterios que los casos de prueba del flujo de trabajo.
Diferentes niveles de abstracción.
Puede contener cierta lógica de programación (bucle for, juicio if, etc.)
Específicamente para las palabras clave subyacentes.
La lógica compleja debe colocarse en bibliotecas, no en palabras clave definidas por el usuario.
Variables
Encapsula constantes o valores complejos.
Pasar información desde la línea de comando.
Transferir información entre palabras clave.
Nombre de las variables
De forma clara, pero no demasiado larga.
Las anotaciones se pueden utilizar en formas variables.
Sea coherente en cada caso de uso:
Las variables locales en minúsculas solo están disponibles dentro del caso de uso o palabra clave actual.
Las variables globales o las variables a nivel de casos de uso y conjuntos deben escribirse en mayúscula.
Puedes utilizar espacios o guiones bajos para separar palabras en variables.
Se recomienda que las variables configuradas como dinámicas también aparezcan en la tabla de variables.
Utilice la palabra clave Set Global/Suite/Test variable para nombrar variables.
El valor inicial de una variable debe indicar cuál es su valor verdadero.
Pasar y devolver valores
La forma habitual de devolver un valor es establecer una palabra clave para él, asignarla a una variable y luego pasarla como parámetro a otras palabras clave.
Sigue este método de forma clara y sencilla.
Parece programación.
Una alternativa es utilizar la palabra clave set test variable
No se requiere ningún estilo de programación a nivel de caso de prueba.
Este método es más complicado y difícil de reutilizar palabras clave.
Evite la siguiente jerarquía de casos de prueba.
Evita dormir
El sueño es muy frágil.
En promedio, los márgenes seguros resultan en largos tiempos de "sueño".
Reemplace Dormir con una palabra clave que contenga un desencadenante para una acción específica
Esperar requiere un valor de tiempo de espera.
Las palabras clave pueden comenzar con Esperar hasta...
Utilice la palabra clave incorporada Esperar hasta que la palabra clave tenga éxito siempre que sea posible para encapsular otras palabras clave.
A veces, "hibernar" es la solución más sencilla.
Siempre tenga cuidado de no utilizar "hibernar" para palabras clave personalizadas u otras palabras clave de uso frecuente.
Aunque DialogsLibrary suele ser más adecuado para este propósito.
La hibernación es muy útil en la depuración.