DEV Community

Cover image for Cómo Probar APIs con Postman: Guía Práctica Paso a Paso
Roobia
Roobia

Posted on • Originally published at apidog.com

Cómo Probar APIs con Postman: Guía Práctica Paso a Paso

Postman es una de las herramientas más usadas para enviar solicitudes HTTP y validar el comportamiento de una API. Sirve para comprobaciones rápidas, pruebas con scripts, ejecución de colecciones y validaciones que pueden integrarse en flujos de CI. Si desarrolla o consume APIs, conviene dominar el flujo básico: crear solicitudes, parametrizarlas, escribir aserciones y ejecutarlas como suite.

Prueba Apidog hoy

En esta guía probará una API en Postman con un flujo práctico: enviar una solicitud, revisar la respuesta, escribir pruebas, usar variables para cambiar entre entornos y ejecutar una colección completa con Collection Runner. Los ejemplos usan una API pública, así que puede seguirlos sin preparar un backend propio.

Configure Postman y envíe su primera solicitud

Descargue Postman desde el sitio oficial e instale la aplicación de escritorio. Puede usarla sin cuenta para trabajar localmente, aunque iniciar sesión permite sincronizar colecciones entre dispositivos.

Para crear su primera solicitud:

  1. Abra Postman.
  2. Haga clic en Nuevo.
  3. Seleccione Solicitud HTTP.
  4. Elija el método GET.
  5. Introduzca este endpoint: 
GET https://jsonplaceholder.typicode.com/users/1
Enter fullscreen mode Exit fullscreen mode

Haga clic en Enviar. En el panel de respuesta revise:

  • Código de estado: 200 OK
  • Tiempo de respuesta
  • Tamaño de la respuesta
  • Cuerpo de la respuesta en formato JSON

Cambie entre las vistas Pretty, Raw y Preview para ver el cuerpo formateado o sin procesar.

Para probar un POST:

  1. Cambie el método a POST.
  2. Abra la pestaña Cuerpo.
  3. Seleccione raw.
  4. Elija JSON como formato.
  5. Pegue una carga útil como esta: 
{
  "name": "Maria Chen",
  "email": "maria.chen@example.com"
}
Enter fullscreen mode Exit fullscreen mode

Postman añadirá automáticamente el encabezado:

Content-Type: application/json
Enter fullscreen mode Exit fullscreen mode

Si la API requiere autenticación, agregue encabezados en la pestaña Encabezados, por ejemplo:

Authorization: Bearer {{auth_token}}
Enter fullscreen mode Exit fullscreen mode

Si necesita una referencia sobre qué códigos esperar en una API REST, consulte la guía sobre códigos de estado HTTP que las API REST deberían usar.

Organice las solicitudes en colecciones

Una solicitud aislada sirve para una verificación rápida. Para pruebas reales, agrupe solicitudes relacionadas en una colección.

Ejemplo de flujo de colección:

  1. Crear usuario
  2. Obtener usuario
  3. Actualizar usuario
  4. Eliminar usuario

Para crear una colección:

  1. Abra Colecciones en la barra lateral.
  2. Haga clic en el icono +.
  3. Use un nombre específico, por ejemplo: Pruebas de humo de la API de Usuario.
  4. Guarde cada solicitud con Ctrl/Cmd + S.
  5. Asigne nombres claros a las solicitudes.

Puede usar carpetas dentro de una colección para separar responsabilidades:

Pruebas de humo de la API de Usuario
├── Autenticación
│   └── Login
├── Usuarios
│   ├── Crear usuario
│   ├── Obtener usuario
│   ├── Actualizar usuario
│   └── Eliminar usuario
Enter fullscreen mode Exit fullscreen mode

Las colecciones también son la unidad que se comparte. Puede exportarlas como JSON o compartirlas mediante enlace si usa sincronización en la nube. Esto permite que otros miembros del equipo ejecuten exactamente las mismas solicitudes.

Además, una colección puede tener scripts compartidos:

  • Script de pre-solicitud: se ejecuta antes de cada solicitud.
  • Script de prueba: se ejecuta después de cada respuesta.

Ejemplo de script de pre-solicitud para agregar una marca de tiempo:

pm.variables.set("timestamp", Date.now());
Enter fullscreen mode Exit fullscreen mode

Ejemplo de prueba a nivel de colección para limitar el tiempo de respuesta:

pm.test("Response time is acceptable", function () {
    pm.expect(pm.response.responseTime).to.be.below(1000);
});
Enter fullscreen mode Exit fullscreen mode

Esto evita repetir la misma lógica en cada solicitud.

Escriba pruebas en la pestaña Pruebas

Enviar una solicitud le muestra qué respondió la API. Una prueba le dice automáticamente si esa respuesta es correcta.

En Postman, las pruebas se escriben en el área Scripts de una solicitud. En versiones anteriores, esta sección aparecía como la pestaña Tests. Postman ejecuta estos scripts después de recibir la respuesta.

El patrón principal es:

pm.test("nombre de la prueba", function () {
    // aserción
});
Enter fullscreen mode Exit fullscreen mode

Ejemplos útiles:

// Verificar código de estado
pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

// Verificar tiempo de respuesta
pm.test("Response is under 500ms", function () {
    pm.expect(pm.response.responseTime).to.be.below(500);
});

// Verificar un campo del cuerpo JSON
pm.test("User has the expected email", function () {
    const body = pm.response.json();
    pm.expect(body.email).to.eql("maria.chen@example.com");
});

// Verificar un encabezado
pm.test("Content-Type is JSON", function () {
    pm.expect(pm.response.headers.get("Content-Type"))
      .to.include("application/json");
});
Enter fullscreen mode Exit fullscreen mode

Postman usa sintaxis de Chai para las aserciones, por lo que puede usar expresiones como:

pm.expect(value).to.eql(expected);
pm.expect(value).to.include("text");
pm.expect(value).to.be.above(10);
pm.expect(value).to.be.below(500);
Enter fullscreen mode Exit fullscreen mode

Después de hacer clic en Enviar, revise la pestaña Resultados de la prueba. Cada prueba aparecerá en verde o rojo.

Buenas prácticas al escribir pruebas:

  • Nombre cada pm.test según el comportamiento que valida.
  • Verifique lo que realmente rompería a un consumidor de la API.
  • Valide código de estado, estructura del cuerpo y campos importantes.
  • Evite depender de valores volátiles, como timestamps generados por el servidor.
  • Use el panel Snippets para insertar aserciones comunes rápidamente.

Ejemplo de prueba más robusta para una respuesta de usuario:

pm.test("Response has a valid user shape", function () {
    const body = pm.response.json();

    pm.expect(body).to.have.property("id");
    pm.expect(body).to.have.property("name");
    pm.expect(body).to.have.property("email");
    pm.expect(body.email).to.include("@");
});
Enter fullscreen mode Exit fullscreen mode

Para profundizar en el diseño de aserciones, consulte las aserciones de API y cómo escribirlas bien. Para estructurar validaciones como casos de prueba, revise el ejemplo de caso de prueba de API.

Use entornos y variables

No conviene codificar una URL como esta en todas las solicitudes:

https://api.staging.example.com
Enter fullscreen mode Exit fullscreen mode

Si luego necesita apuntar a producción, tendría que editar cada endpoint. Para evitarlo, use entornos.

Un entorno es un conjunto de variables con nombre.

Cree un entorno de staging:

  1. Abra el gestor de entornos.
  2. Cree un entorno llamado Staging.
  3. Agregue una variable base_url.
  4. Asigne este valor: 
https://jsonplaceholder.typicode.com
Enter fullscreen mode Exit fullscreen mode

Luego cambie su solicitud a:

GET {{base_url}}/users/1
Enter fullscreen mode Exit fullscreen mode

Ahora puede crear otro entorno llamado Production con otro valor para base_url. Al cambiar el entorno activo desde el menú superior derecho, la misma colección apuntará a otro servidor.

Las variables también sirven para pasar datos entre solicitudes. Por ejemplo, una solicitud de login puede guardar un token:

pm.test("Save the auth token", function () {
    const token = pm.response.json().token;
    pm.environment.set("auth_token", token);
});
Enter fullscreen mode Exit fullscreen mode

Después, cualquier solicitud puede usarlo así:

Authorization: Bearer {{auth_token}}
Enter fullscreen mode Exit fullscreen mode

Este patrón permite probar flujos encadenados:

  1. Iniciar sesión.
  2. Guardar token.
  3. Crear recurso autenticado.
  4. Consultar recurso.
  5. Eliminar recurso.

Postman ofrece varios alcances de variables:

Alcance Uso recomendado
Variables de entorno Valores que cambian entre staging, producción o local
Variables de colección Valores compartidos por una colección
Variables globales Valores disponibles en todas partes
Variables locales Valores temporales durante una ejecución

Use el alcance más limitado posible. Esto reduce errores al cambiar de entorno o ejecutar colecciones compartidas.

Ejecute una colección completa con el Collection Runner

Hacer clic en Enviar en cada solicitud no escala. Para ejecutar una suite completa, use Collection Runner.

Pasos:

  1. Abra una colección.
  2. Haga clic en Ejecutar.
  3. Seleccione el entorno.
  4. Defina el número de iteraciones.
  5. Adjunte un archivo de datos si lo necesita.
  6. Haga clic en Ejecutar.

Postman ejecutará las solicitudes de arriba hacia abajo y mostrará un resumen de:

  • Solicitudes ejecutadas
  • Pruebas aprobadas
  • Pruebas fallidas
  • Errores por solicitud

El orden de las solicitudes importa. Para flujos autenticados, coloque primero la solicitud de login:

1. Login
2. Crear usuario
3. Obtener usuario
4. Actualizar usuario
5. Eliminar usuario
Enter fullscreen mode Exit fullscreen mode

Así, Login puede guardar auth_token y las demás solicitudes pueden reutilizarlo.

También puede preparar y limpiar datos durante la ejecución:

1. Crear recurso de prueba
2. Ejecutar validaciones
3. Eliminar recurso de prueba
Enter fullscreen mode Exit fullscreen mode

Esto convierte la colección en un recorrido automatizado de extremo a extremo.

Pruebas basadas en datos

Collection Runner permite adjuntar archivos CSV o JSON. Cada fila se convierte en una iteración.

Ejemplo CSV:

email,password,expected_status
user@example.com,correct-password,200
user@example.com,wrong-password,401
missing@example.com,password,404
Enter fullscreen mode Exit fullscreen mode

En la solicitud puede usar:

{
  "email": "{{email}}",
  "password": "{{password}}"
}
Enter fullscreen mode Exit fullscreen mode

Y en la prueba:

pm.test("Status code matches expected result", function () {
    pm.response.to.have.status(Number(pm.iterationData.get("expected_status")));
});
Enter fullscreen mode Exit fullscreen mode

Este enfoque evita duplicar solicitudes para probar muchas combinaciones de entrada.

El artículo sobre pruebas de API basadas en datos con CSV y JSON cubre el patrón con más detalle. Para ejecutar la misma colección en CI sin interfaz gráfica, Postman proporciona Newman, descrito en la comparación Newman versus Postman.

Donde Postman se vuelve pesado y qué considerar

Postman funciona bien para pruebas exploratorias y suites pequeñas o medianas. A medida que el proyecto crece, suelen aparecer dos fricciones:

  1. Las aserciones viven en JavaScript, lo que puede dificultar el trabajo de QA o perfiles no desarrolladores.
  2. El diseño de API, las pruebas, el mocking y la documentación pueden quedar separados, aumentando el riesgo de divergencia entre contrato y pruebas.

Apidog es una plataforma API todo en uno que aborda esos puntos. Importa colecciones de Postman directamente, permite construir aserciones visuales sin código y también admite scripts cuando se necesitan. Al centralizar diseño, depuración, mocking, pruebas y documentación sobre una misma fuente de verdad, ayuda a mantener las pruebas alineadas con la especificación real de la API.

Si está evaluando alternativas, el resumen de alternativas a Postman para pruebas de API compara ventajas y desventajas. También puede descargar Apidog e importar una colección existente para compararlo con su flujo actual.

Esto no significa que deba abandonar Postman. Sigue siendo una opción sólida para comprobaciones rápidas y equipos que ya lo usan. Lo importante es elegir la herramienta adecuada para el tamaño del flujo, el perfil del equipo y el nivel de automatización que necesita.

Preguntas frecuentes

¿Necesito escribir código para probar APIs en Postman?

Para enviar solicitudes y leer respuestas, no. Para aserciones automatizadas, sí. La pestaña de pruebas usa JavaScript y el objeto pm.

Puede empezar copiando snippets integrados de Postman, por ejemplo:

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});
Enter fullscreen mode Exit fullscreen mode

Si necesita un constructor visual de aserciones sin código, una plataforma dedicada como Apidog puede cubrir ese flujo.

¿Cuál es la diferencia entre una colección de Postman y un entorno?

Una colección agrupa solicitudes y pruebas. Un entorno contiene variables como base_url, auth_token o user_id.

Ejemplo:

GET {{base_url}}/users/{{user_id}}
Enter fullscreen mode Exit fullscreen mode

La colección define qué se envía. El entorno define contra qué valores se ejecuta.

¿Cómo ejecuto las pruebas de Postman automáticamente en CI?

Use Newman, el ejecutor de línea de comandos de Postman.

Exporte su colección y entorno, y ejecute:

newman run collection.json -e environment.json
Enter fullscreen mode Exit fullscreen mode

Newman devuelve un código distinto de cero si alguna prueba falla, lo que permite fallar el pipeline de CI.

La guía sobre cómo automatizar pruebas de API en CI/CD explica cómo integrarlo en un pipeline.

¿Puede Postman probar más que APIs REST?

Sí. Postman soporta GraphQL, gRPC, WebSocket y SOAP, además de HTTP y REST. La configuración cambia según el protocolo, pero el enfoque general sigue siendo el mismo: enviar solicitud, inspeccionar respuesta y validar con pruebas.

¿Cuántas aserciones debería tener una solicitud?

Las suficientes para confirmar que la respuesta es correcta, sin volver la prueba frágil.

Una base práctica:

  • Código de estado
  • Tiempo de respuesta
  • Estructura del cuerpo
  • Campos críticos para el consumidor

Ejemplo:

pm.test("User response is valid", function () {
    const body = pm.response.json();

    pm.response.to.have.status(200);
    pm.expect(body).to.have.property("id");
    pm.expect(body).to.have.property("email");
});
Enter fullscreen mode Exit fullscreen mode

Mantenga cada pm.test enfocado en una expectativa clara para que una falla indique exactamente qué se rompió.

Top comments (0)