Buenas prácticas
Nombres, escenarios, notas, una descripción y un entorno de pruebas dedicado: lo que hace que las pruebas duren.
Una prueba se lee más veces de las que se escribe
Una grabación le da una prueba que funciona en unos minutos.Unos minutos más en GUI Test Studio la convierten en una prueba que todo su equipo puede leer: en la línea de tiempo, en el Informe de confianza, y en los informes de defecto que produce.
Todo lo que sigue aparece en el informe.Un informe que dice «Comprobar botón Guardar falló en Pago» le indica a un desarrollador qué se rompió antes de que abra nada.
Dar nombre a lo que importa
Cada paso recibe un nombre por sí solo, como «Clic» o «Aserción visual».Dé a los importantes un nombre propio: seleccione el bloque y pulse F2.
| En lugar de | Llámelo |
|---|---|
| Aserción visual | Comprobar botón Nuevo ticket |
| Aserción de texto | Comprobar mensaje de pedido confirmado |
| Escribir texto | Escribir nombre del cliente |
| Clic | Clic en Validar |
Agrupar los pasos en escenarios
Seleccione los pasos de una parte del recorrido y pulse Ctrl+G: «Iniciar sesión», «Añadir al carrito», «Pagar».Una prueba larga se convierte en unos pocos capítulos de colores, el informe indica en cuál se detuvo una ejecución, y un escenario como «Iniciar sesión» puede reutilizarse en otras pruebas.
Más información en Escenarios: reutilice grupos de pasos.
Dejar notas
Un marcador es una nota en la línea de tiempo (M).Úselo para lo que la siguiente persona no puede adivinar: por qué una comprobación es más flexible, qué datos necesita el paso, qué hacer cuando falla.
Describir la prueba
Abra Configuración, Configuración del proyecto y escriba la descripción: qué cubre la prueba, de qué estado parte, qué datos necesita.
«Pago con una tarjeta guardada.Inicio: sesión cerrada, en la página de inicio, usuario de prueba qa-01 con el carrito vacío.Necesita la pasarela de pago de pruebas.»
Usar un entorno de pruebas dedicado
Las pruebas son tan estables como aquello sobre lo que se ejecutan.Ejecútelas en una máquina y con datos reservados para las pruebas, no en el equipo en el que usted trabaja.
Un entorno dedicado
- Una máquina de pruebas o una máquina virtual con un tamaño de pantalla y una escala fijos
- Una copia de pruebas de su aplicación, con datos que se restablecen antes de cada ejecución
- Cuentas de prueba que nadie más usa
- Sin notificaciones, actualizaciones ni ventanas emergentes durante una ejecución
Uno compartido o personal
- Su propio escritorio, donde las ventanas y la configuración cambian cada día
- Datos de producción que otras personas modifican
- Una cuenta compartida cuya cesta o cuyo historial no dejan de cambiar
- Una máquina que se suspende, se bloquea o instala actualizaciones en plena ejecución
Mantener las pruebas pequeñas e independientes
Una prueba, un recorrido.Diez pruebas cortas le dicen exactamente qué se rompió; una prueba larga solo le dice que algo se rompió, y todo lo que viene tras su primer fallo queda sin comprobar.
Cada prueba debe preparar su propio estado de partida, con un paso Ejecutar aplicación o Ejecutar script Python al principio, y no depender nunca de que otra prueba se haya ejecutado antes.
Una lista de verificación antes de compartir una prueba
- La prueba tiene una descripción: qué cubre y de dónde parte
- Sus pasos están agrupados en escenarios con nombre
- Cada comprobación tiene un nombre que un desarrollador entendería
- Los valores que cambian (fechas, totales, números de pedido) se comprueban por su tipo, no por su valor
- Parte de un estado conocido, por sí sola
- Se superó dos veces seguidas en la máquina de pruebas
¿Sigue con problemas?Díganos qué intentaba hacer, y respondemos en un día laborable.Ask our team