Los términos "escenario de prueba" y "caso de prueba" se utilizan como si significaran lo mismo. No es así. Confundirlos es lo que hace que los planes de prueba terminen siendo demasiado vagos para ejecutarse o demasiado detallados para leerse. Uno describe qué probar; el otro describe exactamente cómo. Si la relación es correcta, su cobertura será tanto auditable como ejecutable.
Esta guía define cada término, expone las diferencias lado a lado y muestra cómo ambos funcionan juntos en un flujo de trabajo real de pruebas de API utilizando Apidog.
¿Qué es un escenario de prueba?
Un escenario de prueba es una declaración de alto nivel de algo que vale la pena probar. Nombra un comportamiento o condición sin especificar los pasos exactos, las entradas o los valores esperados.
Piense en ello como un encabezado. Para el proceso de pago de un comercio electrónico, los escenarios podrían ser:
- Verificar el pago para un usuario registrado con una tarjeta guardada
- Verificar el pago para un usuario invitado
- Verificar el pago cuando un artículo se agota en medio de la compra
- Verificar el pago cuando se rechaza el pago
Cada línea le dice qué validar y por qué es importante para el negocio. Ninguna de ellas le dice qué endpoint llamar o qué payload enviar. Un escenario se escribe desde el punto de vista del usuario o del requisito, por lo que sigue siendo legible tanto para los gerentes de producto como para los ingenieros.
Los escenarios responden a una pregunta: ¿hemos pensado en todo lo que debería funcionar? Son el mapa de cobertura. Si falta un escenario, ninguna cantidad de casos de prueba detallados cubrirá esa laguna.
¿Qué es un caso de prueba?
Un caso de prueba es la verificación concreta y ejecutable que se encuentra debajo de un escenario. Especifica la entrada exacta, la precondición, la acción y el resultado esperado, con la suficiente precisión para que dos personas que lo ejecuten obtengan el mismo resultado.
Tomemos el escenario "verificar el pago para un usuario invitado". Se descompone en casos como:
POST /orderscon un payload de invitado válido devuelve201y unorder_idPOST /orderssin una dirección de envío devuelve400y unvalidation_errorPOST /orderscon un SKU agotado devuelve409yerror: out_of_stock
Cada caso nombra el endpoint, el cuerpo, el estado esperado y los campos de respuesta esperados. Es lo suficientemente específico como para automatizarse. Si desea la anatomía completa campo por campo de un caso, cómo escribir casos de prueba de API cubre la plantilla en detalle, y caso de prueba vs script de prueba aclara dónde encaja el código ejecutable.
El rasgo definitorio de un caso de prueba es la precisión. "El pago funciona" es, en el mejor de los casos, un fragmento de escenario. "POSTear un pedido de invitado válido, esperar 201 con un order_id no vacío" es un caso de prueba.
Las diferencias clave
Los dos conceptos difieren en varias dimensiones. Esta tabla es la versión resumida.
| Dimensión | Escenario de prueba | Caso de prueba |
|---|---|---|
| Nivel | Alto nivel, qué probar | Bajo nivel, cómo probar |
| Detalle | Breve, una línea | Paso a paso con datos |
| Enfoque | Objetivo comercial o funcional | Ejecución técnica |
| Entradas | No especificadas | Payloads y parámetros exactos |
| Resultado esperado | Implícito | Declarado con precisión (estado, cuerpo, tiempo) |
| Audiencia | Producto, QA, ingeniería | Probadores y herramientas de automatización |
| Cantidad | Pocos por característica | Muchos por escenario |
| Creado | Durante la planificación de la prueba | Después de acordar los escenarios |
La relación es jerárquica. Un escenario genera varios casos. El escenario controla la amplitud de la cobertura; los casos controlan la profundidad y el rigor. Un modo de fallo común es escribir docenas de casos detallados sin un mapa de escenarios por encima de ellos, lo que hace imposible saber si la característica está totalmente cubierta o simplemente ha sido probada intensamente en un rincón.
Otra forma de verlo: un escenario puede marcarse como "cubierto" o "no cubierto". Un caso de prueba solo puede marcarse como "aprobado" o "fallido". Se necesitan ambos estados para gestionar la calidad.
Cómo trabajan juntos escenarios y casos
Un flujo de trabajo práctico se mueve de lo general a lo específico en cinco pasos.
1. Identificar escenarios a partir de los requisitos. Lea la especificación o la documentación de la API y enumere cada comportamiento que valga la pena verificar, incluidos los "caminos infelices". Aquí es donde se detecta la cobertura faltante, así que dedique tiempo real a esto.
2. Definir el objetivo de cada escenario. Establezca lo que significa "hecho". Para "verificar el pago de invitado", el objetivo es que un invitado pueda realizar un pedido y reciba una confirmación, mientras que los pedidos no válidos sean rechazados limpiamente.
3. Escribir casos de prueba bajo cada escenario. Expanda cada escenario en casos concretos con entradas y resultados esperados. Cubra el "camino feliz", cada fallo de validación y las condiciones de borde relevantes.
4. Revisar la completitud. Vuelva a subir por el árbol. ¿Cada escenario tiene al menos un caso de "camino feliz" y un caso negativo? ¿Aparece cada código de estado documentado en algún resultado esperado? Las lagunas encontradas aquí son baratas; las lagunas encontradas en producción no lo son.
5. Ejecutar y rastrear los resultados. Ejecute los casos, registre el éxito y el fallo por caso, y agrupe los resultados a nivel de escenario para que los interesados vean la cobertura, no solo un recuento de marcas verdes.
Para los equipos orientados al comportamiento, los escenarios se mapean naturalmente al formato Given-When-Then de Gherkin; la guía de Gherkin para las pruebas de API BDD muestra cómo esa estructura mantiene los escenarios legibles sin dejar de ser ejecutables.
Un ejemplo práctico: del escenario a los casos
Tomemos una API para una aplicación de notas, con un único comportamiento que vale la pena probar: un usuario puede crear una nota. Ese es el escenario.
Escenario: un usuario puede crear una nota. Una línea. Pertenece al plan de prueba, legible por cualquiera. No menciona endpoints, payloads ni códigos de estado, y no debería hacerlo.
Ahora expándalo en casos. Cada caso es una verificación ejecutable con entradas exactas y un resultado esperado exacto.
- Caso 1, camino feliz.
POST /notescon{"title": "Groceries", "body": "milk, eggs"}y un token válido. Esperar201, un cuerpo de respuesta con unidno vacío,titleigual aGroceries, y una marca de tiempocreated_at. Respuesta en menos de 600 ms. - Caso 2, campo requerido faltante.
POST /notescon{"body": "milk, eggs"}y un token válido. Esperar400,errorigual avalidation_error, ydetailsnombrando el campotitle. - Caso 3, no autenticado.
POST /notescon un cuerpo válido y sin token. Esperar401y ningúniden la respuesta. - Caso 4, payload demasiado grande.
POST /notescon unbodyde 2 MB. Esperar413y un mensaje de error claro.
Un escenario, cuatro casos. El escenario le dijo qué; los casos le dijeron cómo, con la suficiente precisión para que cualquier probador o ejecutor automatizado produzca el mismo veredicto. Si luego añade "un usuario puede adjuntar un archivo a una nota", ese es un nuevo escenario, y genera su propio conjunto de casos. El plan crece de una manera estructurada y auditable en lugar de convertirse en una pila plana de verificaciones.
Construyendo escenarios y casos en Apidog
Apidog modela esta jerarquía directamente, de modo que la estructura de su plan de prueba coincide con la estructura de sus herramientas.
Un escenario de prueba en Apidog es una secuencia ordenada de solicitudes API, cada una con sus propias aserciones. Se construye visualmente: se añaden los endpoints involucrados en el comportamiento, se encadenan para que la salida de una solicitud alimente la siguiente (un inicio de sesión devuelve un token, la siguiente solicitud lo usa), y se establecen aserciones en cada paso.
Cada bloque de solicitud-más-aserciones es efectivamente un caso de prueba. Se afirman códigos de estado, campos del cuerpo de la respuesta, conformidad del esquema y tiempo de respuesta haciendo clic, sin escribir un script. Las pruebas basadas en datos permiten que un caso se ejecute contra muchas filas de entrada de un archivo CSV o JSON, por lo que un solo caso negativo cubre cada combinación no válida.
Los escenarios se agrupan luego en suites de prueba para ejecuciones organizadas y repetibles en toda una API. Puede ejecutar una suite localmente, según un horario o dentro de CI, y Apidog produce un informe que muestra los resultados tanto a nivel de caso como a nivel de escenario. Esa vista dual es la recompensa: los ingenieros ven qué caso falló y los líderes ven qué escenario está ahora en riesgo.
Descargue Apidog para construir su primer escenario y ver el resumen de casos a escenarios en la práctica.
Por qué necesita ambos, no solo uno
Los equipos a veces intentan saltarse una capa. Omitir los escenarios y escribir solo casos produce una lista larga y plana sin mapa de cobertura; no se puede responder "¿probamos completamente el pago de invitados?" sin releer cada caso. Omitir los casos y mantener solo los escenarios produce un plan que nadie puede ejecutar de manera consistente, porque "verificar el pago" significa algo diferente para cada probador.
Las dos capas también sirven a diferentes lectores. Un gerente de producto lee los escenarios para confirmar que se están probando las cosas correctas. Un ingeniero de automatización lee los casos para construir los ejecutores. Un informe de prueba que solo muestra casos aprobados no le dice nada a la dirección sobre la cobertura; uno que agrupa los casos en escenarios les dice exactamente qué características son seguras para lanzar.
Mantenga los escenarios estables y los casos actualizados. Los escenarios cambian solo cuando cambia la intención de la característica. Los casos cambian cada vez que cambia el contrato de la API. Cuando los trata como artefactos separados con ciclos de vida separados, su plan de prueba se mantiene preciso y fácil de mantener.
Preguntas frecuentes
¿Es un escenario de prueba lo mismo que una suite de prueba? No. Un escenario describe un comportamiento a probar. Una suite es una colección de pruebas ejecutables agrupadas para una ejecución. Una suite puede contener los casos de muchos escenarios. Vea suite de prueba vs caso de prueba.
¿Cuántos casos de prueba debe tener un escenario? Suficientes para cubrir el "camino feliz" más cada modo de fallo que el escenario implica. Un escenario simple puede necesitar tres o cuatro casos; uno complejo necesita más.
¿Quién escribe los escenarios y quién los casos? Los escenarios a menudo se redactan junto con producto y QA, ya que codifican la intención. Los casos suelen ser escritos por QA o desarrolladores, ya que codifican detalles técnicos. El formato de especificación de casos de prueba ayuda a mantener la consistencia en la redacción de casos.
¿Necesito escenarios si mis pruebas están automatizadas? Sí. La automatización ejecuta casos, pero los escenarios aún responden si existen los casos correctos. La automatización sin un mapa de cobertura solo falla más rápido.