Postman es una de las herramientas más utilizadas para enviar solicitudes HTTP y verificar el comportamiento de una API. Comenzó como una extensión de navegador y se convirtió en una aplicación de escritorio completa que maneja todo, desde una solicitud GET rápida hasta suites de pruebas con scripts que se ejecutan en CI. Si construye o consume APIs, es casi seguro que se encontrará con ella.
Esta guía le mostrará cómo probar una API en Postman de la manera en que lo haría día a día. Enviará una solicitud, inspeccionará la respuesta, escribirá aserciones en la pestaña Pruebas, configurará entornos para poder alternar entre staging y producción, y ejecutará una colección completa a la vez con el Collection Runner. Los ejemplos utilizan una API pública para que pueda seguir el proceso sin necesidad de configurar nada previamente.
Configure Postman y envíe su primera solicitud
Descargue Postman desde el sitio oficial e instale la aplicación de escritorio. Puede usarla sin una cuenta para trabajar localmente, aunque iniciar sesión sincroniza sus colecciones entre dispositivos. Abra la aplicación y haga clic en el botón Nuevo, luego elija Solicitud HTTP.
Una solicitud necesita al menos tres cosas: un método, una URL y, a veces, un cuerpo. Elija GET del menú desplegable de métodos e introduzca un endpoint real. El servicio JSONPlaceholder es útil para practicar:
GET https://jsonplaceholder.typicode.com/users/1
Haga clic en Enviar. El panel de respuesta se llenará con el cuerpo, el código de estado (200 OK), el tiempo de respuesta y el tamaño. Cambie la vista del cuerpo entre Pretty, Raw y Preview para ver el JSON formateado o tal como lo envió el servidor.
Para un POST, cambie el método, abra la pestaña Cuerpo, elija raw y seleccione JSON del menú desplegable de formato. Pegue una carga útil como esta:
{
"name": "Maria Chen",
"email": "maria.chen@example.com"
}
Los encabezados como Content-Type: application/json se añaden automáticamente al elegir el tipo de cuerpo JSON. La pestaña Encabezados le permite añadir cualquier otra cosa que la API necesite, como un encabezado Authorization. Si es nuevo en cuanto a los códigos de respuesta que debe esperar, la guía sobre códigos de estado HTTP que las API REST deberían usar es una referencia útil.
Organice las solicitudes en colecciones
Una sola solicitud está bien para una verificación rápida. Las pruebas reales implican muchas solicitudes que van juntas: crear un usuario, obtener ese usuario, actualizarlo, eliminarlo. Postman las agrupa en colecciones.
Haga clic en Colecciones en la barra lateral, luego en el icono + para crear una. Nómbrela de forma concreta, como "Pruebas de humo de la API de Usuario". Guarde cada solicitud en la colección con Ctrl/Cmd + S y dele un nombre claro. Puede anidar carpetas dentro de una colección para separar, por ejemplo, las solicitudes de autenticación de las solicitudes de recursos.
Las colecciones también son la unidad que se comparte. Exporte una como archivo JSON, o comparta un enlace si sincroniza con la nube. Los compañeros de equipo la importan y tienen exactamente las mismas solicitudes que usted. Esta es la base de todo lo demás, porque el Collection Runner y las pruebas automatizadas operan sobre colecciones en lugar de solicitudes sueltas.
Una colección también puede llevar un comportamiento compartido. Postman le permite adjuntar scripts a nivel de colección o carpeta, no solo a una única solicitud. Un script de pre-solicitud en la colección se ejecuta antes de cada solicitud dentro de ella, lo cual es útil para refrescar un token o añadir una marca de tiempo. Un script de prueba a nivel de colección se ejecuta después de cada solicitud, lo cual es útil para una aserción que desea en todas partes, como "el tiempo de respuesta es razonable". Definir esto una vez mantiene sus solicitudes individuales enfocadas en lo que es único para ellas.
Escriba pruebas en la pestaña Pruebas
Enviar una solicitud le dice lo que recibió. Una prueba le dice si lo que recibió es correcto, automáticamente, cada vez. Postman ejecuta JavaScript en el área Scripts de una solicitud (versiones anteriores lo llamaban la pestaña Tests) después de que llega la respuesta.
Postman expone un objeto pm para escribir aserciones. El patrón principal es pm.test(name, callback), donde el callback lanza un error si una expectativa falla. Aquí hay aserciones que usará constantemente:
// Check the status code
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});
// Check response time
pm.test("Response is under 500ms", function () {
pm.expect(pm.response.responseTime).to.be.below(500);
});
// Check a field in the JSON body
pm.test("User has the expected email", function () {
const body = pm.response.json();
pm.expect(body.email).to.eql("maria.chen@example.com");
});
// Check a header
pm.test("Content-Type is JSON", function () {
pm.expect(pm.response.headers.get("Content-Type"))
.to.include("application/json");
});
La sintaxis de las aserciones proviene de Chai, por lo que pm.expect admite .to.eql, .to.include, .to.be.above y el resto. Haga clic en Enviar y los resultados aparecerán en la pestaña Resultados de la prueba, cada prueba en verde o rojo.
Algunos hábitos mantienen las pruebas útiles. Nombre cada bloque pm.test según el comportamiento que verifica, no el endpoint, para que un mensaje de error se lea como una oración. Verifique las cosas que realmente romperían a un consumidor de la API: el código de estado, la forma del cuerpo y los campos de los que depende un cliente. Evite afirmar sobre valores que no controla, como una marca de tiempo generada por el servidor, porque estos producen fallas inestables que acostumbran a las personas a ignorar los errores. Postman también incluye un panel de Snippets junto al editor con aserciones predefinidas que puede hacer clic para insertar, que es la forma más rápida de aprender la API pm. Si desea una mirada más profunda al diseño de aserciones, consulte el desglose de las aserciones de API y cómo escribirlas bien. Para la idea más amplia de estructurar las verificaciones en casos nombrados, la guía de ejemplo de caso de prueba de API vale la pena leerla junto con esta.
Use entornos y variables
Codificar https://api.staging.example.com en cada solicitud es un problema en el momento en que necesita apuntar a producción. Los entornos resuelven esto. Un entorno es un conjunto nombrado de variables.
Haga clic en el icono de entornos en la barra lateral y cree uno llamado "Staging". Agregue una variable base_url con el valor https://jsonplaceholder.typicode.com. Cree un segundo entorno llamado "Production" con un base_url diferente. Ahora haga referencia a la variable en sus solicitudes usando dobles llaves:
GET {{base_url}}/users/1
Elija el entorno activo del menú desplegable en la parte superior derecha, y cada solicitud que use {{base_url}} cambiará con él.
Las variables también transportan datos entre solicitudes. Una solicitud de inicio de sesión puede capturar un token de su respuesta y almacenarlo para que las solicitudes posteriores lo utilicen:
pm.test("Save the auth token", function () {
const token = pm.response.json().token;
pm.environment.set("auth_token", token);
});
Cualquier solicitud posterior puede enviar Authorization: Bearer {{auth_token}}. Esta encadenación es la forma en que se prueban flujos que dependen del estado, como crear un recurso y luego verificar que existe.
Postman tiene dos alcances de variables relacionados que vale la pena conocer. Las variables de entorno pertenecen al entorno seleccionado y cambian cuando se cambia de entorno. Las variables de colección pertenecen a una colección independientemente del entorno, lo que es adecuado para valores constantes para esa API. También hay variables globales, que se aplican en todas partes, y variables locales de corta duración que existen solo para una ejecución. Elegir el alcance correcto mantiene un valor donde debe estar y evita sorpresas al cambiar de objetivo.
Ejecute una colección completa con el Collection Runner
Hacer clic en Enviar en cada solicitud se vuelve tedioso rápidamente. El Collection Runner ejecuta cada solicitud de una colección en orden, ejecuta todas sus pruebas y le proporciona un resumen de aprobado/fallado.
Abra una colección, haga clic en el botón Ejecutar (o en el menú de tres puntos, luego en Ejecutar colección). El runner muestra sus solicitudes en secuencia. Elija el entorno, configure cuántas iteraciones ejecutar y, opcionalmente, adjunte un archivo de datos. Haga clic en Ejecutar y Postman dispara cada solicitud, de arriba a abajo, ejecutando las pruebas de cada solicitud.
La página de resultados enumera cada aserción en cada solicitud, con totales para las aprobadas y las fallidas. Esta es su verificación de regresión. Ejecútela después de un despliegue y sabrá en segundos si la API sigue funcionando. El runner también mantiene un historial de ejecuciones pasadas, para que pueda comparar el resultado de hoy con el de ayer y detectar cuándo una suite que antes estaba en verde comenzó a fallar.
El orden importa en el runner. Debido a que las solicitudes se ejecutan de arriba a abajo, puede colocar una solicitud de inicio de sesión primero para que complete un auth_token, y luego permitir que cada solicitud debajo de ella use ese token. Lo mismo se aplica a la configuración y limpieza: crear un recurso cerca del inicio, usarlo en el medio, eliminarlo al final. Una colección bien ordenada efectivamente scripta un viaje completo del usuario.
Para pruebas basadas en datos, adjunte un archivo CSV o JSON en el runner. Cada fila se convierte en una iteración, y usted hace referencia a las columnas como variables como {{username}}. Esto permite que una solicitud pruebe docenas de combinaciones de entrada sin duplicar la solicitud. Un endpoint de inicio de sesión, por ejemplo, puede ser golpeado con una fila de credenciales válidas y varias filas de credenciales incorrectas, cada fila afirmando el código de estado que espera. El artículo sobre pruebas de API basadas en datos con CSV y JSON cubre el patrón en detalle. Para ejecutar la misma colección en CI sin la GUI, Postman proporciona la herramienta de línea de comandos Newman, descrita en la comparación Newman versus Postman.
Donde Postman se vuelve pesado, y qué considerar
Postman es excelente para pruebas exploratorias y suites pequeñas a medianas. Dos puntos de fricción aparecen a medida que los proyectos crecen. Primero, las aserciones viven en JavaScript, por lo que los no desarrolladores y los profesionales de QA que prefieren un enfoque visual tienen una curva de aprendizaje. Segundo, Postman mantiene el diseño de API, las pruebas, el mocking y la documentación en lugares separados, lo que significa que sus datos de prueba y su contrato de API pueden divergir.
Apidog es una plataforma API todo en uno que aborda ambos. Importa colecciones de Postman directamente, por lo que la migración no es una reescritura. Las aserciones se pueden construir visualmente sin código, permitiendo scripts cuando los necesite. Debido a que el diseño, la depuración, el mocking, las pruebas y la documentación comparten una única fuente de verdad, sus pruebas se mantienen alineadas con la especificación real de la API. Si está sopesando opciones, el resumen de alternativas a Postman para pruebas de API expone las ventajas y desventajas. Puede descargar Apidog e importar una colección existente para comparar directamente.
Nada de esto significa que deba abandonar Postman. Sigue siendo una opción sólida, especialmente para verificaciones rápidas y equipos que ya han invertido en ella. El objetivo es saber dónde encaja cada herramienta.
Preguntas frecuentes
¿Necesito escribir código para probar APIs en Postman?
Para enviar solicitudes y leer respuestas, no. Para aserciones automatizadas, sí, al menos un poco. La pestaña Pruebas de Postman ejecuta JavaScript y utiliza el objeto pm. Los patrones son simples y puede copiarlos del panel de fragmentos integrado de Postman, pero sigue siendo JavaScript. Si desea un constructor de aserciones visuales sin código, una plataforma dedicada como Apidog lo maneja.
¿Cuál es la diferencia entre una colección de Postman y un entorno?
Una colección es un conjunto de solicitudes agrupadas, a menudo con sus pruebas. Un entorno es un conjunto nombrado de variables, como base_url o auth_token. Las colecciones contienen lo que se envía. Los entornos contienen los valores que cambian entre staging, producción y local. Se apunta una colección a diferentes entornos para probar las mismas solicitudes contra diferentes servidores.
¿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, luego ejecute newman run collection.json -e environment.json. Newman sale con un código no cero si alguna prueba falla, que es lo que verifica su pipeline de CI. La guía sobre cómo automatizar pruebas de API en CI/CD explica cómo integrar esto en un pipeline.
¿Puede Postman probar más que APIs REST?
Sí. El Postman moderno soporta solicitudes GraphQL, gRPC, WebSocket y SOAP, además de HTTP y REST planos. La pestaña de Pruebas y las aserciones funcionan en la mayoría de estos, aunque la configuración exacta de la solicitud difiere por protocolo.
¿Cuántas aserciones debería tener una solicitud?
Suficientes para confirmar que la respuesta es correcta, no tantas que un solo cambio rompa una docena de pruebas. Una línea base común es el código de estado, el tiempo de respuesta y los dos o tres campos que importan para ese endpoint. Mantenga cada bloque pm.test enfocado en una expectativa para que una falla le diga exactamente qué se rompió.