Postman.pdf

Introducción
• Postman es la herramienta líder del sector del testing
para peticiones de la API
• Gratuita (con versiones de pago)
• Multiplataforma
• Escrita en lenguaje Electron
4

Introducción
• Existe la posibilidad de instalar Postman como un
complemento de Google Chrome, pero esta
instalación tendrá muchas limitaciones
• Conviene instalar la versión completa de escritorio
para explorar todas sus funcionalidades
6

Introducción
7
Header bar
Side bar
Builder

Introducción
• La misma página web de Postman nos proporciona unos servicios
web de ejemplo que nos permitirán probar la herramienta:
8

Introducción
• Podemos “llevarnos” estos servicios directamente a
la aplicación para probarlos:
9

Introducción
• Esto nos creará una colección con 37 servicios web
de prueba (peticiones web)
10

Introducción
• Hay listados de aplicaciones públicas desde las que
podemos obtener todo tipo de información para
crear nuestros servicios web:
11

Introducción
• API sobre el universo de Star Wars:
12

Introducción
• Esta web nos permite probar peticiones sobre sus datos:
13

Introducción
• Podemos abrir Postman, crear una colección y realizar
peticiones de datos sobre esta API:
14

Introducción
• Creamos la petición y probamos otras peticiones:
15

Introducción
• API de datos sobre fútbol (crear una cuenta):
16

Introducción
• Hay versiones gratuitas y de pago:
17

Introducción
• Al registrarnos nos envían un token que nos
permitirá obtener los datos de las peticiones a esta
API:
18

Introducción
• Nos logueamos con el APIToken:
19

Introducción
• La cuenta gratuita permite obtener datos de 12
competiciones:
20

Introducción
• En la documentation tenemos toda la información necesaria
para usar esta API:
• Vemos que hay un botón de Run in Postman:
21

Introducción
• Nos llevará una serie de peticiones de ejemplo al entorno de
Postman:
22

Introducción
• Para algunas peticiones tenemos que usar elToken que nos
han proporcionado, si no lo usamos no podríamos obtener los
datos:
23

Introducción
• Insertamos el Token en el Header y al ejecutar obtendremos
los datos de la petición:
24

Introducción
• Vamos a crearnos nuestra primera colección de servicios web:
25

Introducción
• Definimos una primera petición, una llamada a un servicio web:
26

Introducción
• Hacemos clic en Send y vemos que el servicio existe, y nos
devuelve información:
27

Introducción
• Podemos guardar esta primera petición en nuestra colección:
29

Introducción
• Duplicamos esa petición para incluir algunos parámetros:
30

Introducción
• Podemos sincronizar nuestro trabajo para poder consultarlo en
la versión online de Postman:
31

Introducción
• Verificamos los settings de la aplicación (podemos cambiar el theme):
32

Introducción
• Explorar las opciones del botón New y de los comandos inferiores
(find y consola):
33

API REST
• Una API REST es lo que estamos acostumbrados a
hacer a la hora de realizar peticiones a alguna API
desarrollada por una empresa.
• Algunos ejemplos de llamadas API REST son las
típicas llamadas de GET, POST, PUT y DELETE.
• GET para consultar y leer, POST para crear, PUT
para editar y DELETE para eliminar.
35

API REST
• El término REST (Representational State Transfer) se
originó en el año 2000, descrito en la tesis de Roy
Fielding, padre de la especificación HTTP.
• Un servicio REST no es una arquitectura software,
sino un conjunto de restricciones con las que
podemos crear un estilo de arquitectura software, la
cual podremos usar para crear aplicaciones web
respetando HTTP.
36

API REST
• Hoy en día la mayoría de las empresas utilizan API
REST para crear servicios.
• Esto se debe a que es un estándar lógico y eficiente
para la creación de servicios web.
• Por poner algún ejemplo tenemos los sistemas de
identificación de Facebook, la autenticación en los
servicios de Google (hojas de cálculo, Google
Analytics, …).
37

Ejemplo GET
• Vamos a añadir una nueva petición:
38

Ejemplo GET
• Las peticiones de tipo GET son para obtener datos, habitualmente van
acompañado de parámetros después del símbolo “?”
39

Ejemplo POST
• Para enviar información al servidor y añadir datos a
una BBDD usamos POST
• Creamos una nueva petición en la colección:
40

Ejemplo POST
• En las peticiones POST enviamos los datos mediante el Body para
que no puedan ser interceptados, en este caso un texto raw:
41

Ejemplo POST
• Podemos enviar datos mediante un formulario:
42

ARRAY mediante POST
• Cuando se realiza un pedido en una tienda online,
habitualmente se envía un array de datos:
44
Probemos a quitar
alguna coma y a
enviar
Mirar el JSON
generado

Creación de carpetas
• Dentro de la colección podemos crear carpetas para
organizar mejor nuestras peticiones (arrastramos las
peticiones a las carpetas):
45

Ejemplo PUT
• Cuando queremos actualizar un registro de la BBDD
podemos utilizar las peticiones de tipo PUT
• Al igual que POST, los datos se envían mediante un
body para evitar que sean interceptados
46

Ejemplo PUT
• Por ejemplo queremos cambiar el nombre de un
producto en nuestra base de datos:
47

Ejemplo DELETE
• Para borrar algún registro de nuestra BBDD
podemos usar la petición de tipo DELETE:
48

HEADER
• Más allá de enviar datos por la URL o por el Body,
podemos enviar datos por la cabecera (HEADER), la
cual suele contener información especial relacionada
con diferentes aspectos de mi servicios web
49

HEADER
• Abramos la petición GET “Ejemplo de ID” y
añadimos un header:
50

Variables de Entorno
• Podemos crear entornos para organizar nuestro
trabajo (sería como una especie de contenedor de
nuestras colecciones y de nuestras variables de
entorno):
51

• Una vez creado el entorno vamos a su gestión para
crear variables válidas para dicho entorno
52

• Ahora podemos utilizar dicha variable para la prueba
de nuestros servicios web:
53

• De esta forma, cuando pasemos a probar con
nuestro servidor real, tendremos que cambiar
exclusivamente nuestra variable de entorno y no
realizar dicho cambio en todas las peticiones
54

Variables Globales
• Si cambiamos de entorno y probamos la anterior petición,
obtendríamos un fallo, al no reconocer dicha variable:
55

Variables Globales
• Podemos crear variables válidas para todos los
entornos (globales):
56

Variables Globales
• Creamos la variable global:
57

Variables Globales
• Ahora podemos probar en ambos entornos y
veremos que funciona:
58

Variables Globales
• Guardamos esa petición en la Collection1 – Servicios
GET:
59

Variables Dinámicas
• Vamos a crear una nueva carpeta llamadaVariables
Dinámicas y dentro creamos una nueva petición
llamada GUID:
60

• Utilizamos una de las variables (dinámicas) de
postman para generar una clave única cada vez que
enviamos la petición (es útil para simular inserciones
únicas en BBDD):
61

• Creamos una segunda petición en esta carpeta con
otra variable dinámica que me genera un número
aleatorio entre 0 y 1000:
62

• Creamos otra petición para calcular tiempos entre
llamadas a servicios (segundos):
63

• Creamos otra petición de tipo POST donde podremos ver que
podemos usar las variables dinámicas en el body del envío:
64

Autenticación y Autorización
65

Autenticación básica
• La misma documentación de Postman nos
proporciona una guía sobre los diferentes métodos
de autenticación de nuestros servicios web:
66

Autenticación básica
• Probamos la autenticación básica en una nueva petición,
dentro de una nueva carpeta:
67

Autenticación porToken
• Existen otros servicios similares a postman-echo
como por ejemplo httpbin.org, con el cual podemos
probar otro tipo de autenticación mediante tokens:
68

• En primer lugar podemos crear una nueva variable de
entorno:
69

• Creamos la nueva petición:
70

Autenticación OAuth1
• Otro sistema de
autenticación
bastante usado es el
OAuth1, el cual se
basa en una
combinación de
claves mucho más
robusto que los dos
métodos anteriores:
71

• Creamos una nueva petición:
72

• Si modificamos algún valor del Consumer Secret, la
autenticación fallaría:
73

Operaciones sobre colecciones
• Podemos realizar diferentes
operaciones sobre las colecciones:
renombrar, duplicar, exportar,
borrar, etc.
75

Exportar JSON
• Podemos exportar una colección como un JSON que
posteriormente podríamos importar en otro espacio
de trabajo:
76

Exportar Link
• Es posible compartir mi colección mediante un
enlace público:
77

Importar
• Podemos importar el fichero JSON o el link:
78

Ver colección enWeb
• Podemos ver la web de nuestra colección sobre la que
podemos añadir comentarios:
79

Control de versiones
• Puedo crear forks de las colecciones (habitualmente
para que alguien más trabaje independientemente
sobre la colección y posteriormente se haga el
respectivo merge):
80

• Creamos una nueva petición (cualquiera) en la
colección padre:
81

• Desde la colección hijo hacemos un merge changes,
se nos abre una página web:
82

• Podemos elegir el tipo de merge (sólo el destino o
los cambios en las dos colecciones):
83

Creamos una petición (vacía) en cada una de las colecciones, simulando
el trabajo de dos personas. Hacemos el merge en la colección hijo:
84

• Hacemos los pull:
85

• Y finalmente el merge:
86

• Al volver a Postman, veremos
todas las peticiones en ambas
colecciones:
87

Comentarios
• Podemos ir añadiendo comentarios sobre nuestras
peticiones con el fin de generar una mejor
documentación:
89

Código
• Postman me genera el código del servicio web de
forma automática y para muchos lenguajes de
programación:
90

Utilidades
• Vamos a crear una nueva carpeta dentro de la
colección:
91

Status
• Dentro de esta carpeta creamos una nueva petición
que nos permitirá realizar diferentes pruebas en base
al código del estado que nos devuelva un servicio
web:
92

Status
• Podemos utilizar la utilidad status y probar con los
diferentes códigos de estado que podría devolver un
servicio web: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
93

Stream
• Si queremos dividir la
respuesta de un servicio
web en varias cadenas de
texto podemos usar otra
utilidad llamada Stream.
Nos permite crear
aplicaciones que por
ejemplo van recogiendo
un valor concreto en
cada uno de los
resultados obtenidos
94

Stream
• Podemos modificar el número de divisiones:
95

Delay
• Existe otra utilidad que nos permite añadir un
retraso al servicio web antes de efectivamente
devolver el resultado del servicio
• Creamos otra petición:
96

Delay
• Muchos servicios utilizan esta utilidad para mostrar
mensajes publicitarios antes de enviar los resultados
al usuario:
97

UTF8
• Si creamos una aplicación web multilenguaje podríamos
utilizar caracteres diferentes a los utilizados en inglés (tildes, ñ,
etc.), con lo cual podría ser útil comprobar si las respuestas de
nuestros servicios web se comportan correctamente ante
caracteres de este tipo
98

UTF8
• Probamos la utilidad:
99

IP
• Si queremos saber la IP de la máquina que está
enviando la solicitud podemos probar la utilidad IP:
100

Parámetros en llamada a servicios
• Podemos utilizar parámetros en las llamadas a los
servicios con el uso de los dos puntos (:)
101

Utilidades de fecha y hora
102

Utilidades fecha y hora
• Vamos a crear una nueva carpeta en nuestra
colección:
103

Now
• En muchas servicios web es necesario saber la fecha
y hora en la que se ejecuta o solicita el servicio
• Hay una utilidad para obtener esos datos:
104

Valid
• La siguiente utilidad nos permite validar si el formato de
una fecha es correcto o no (probamos con un día 32):
105

Unit
• Utilidad para saber el día de la semana de una fecha
en concreto:
106

Add
• Utilidad para añadir tiempo a una fecha en concreto
(years, months, days, hours, minutes, seconds):
107

Subtract
• Duplicamos la anterior petición y modificamos el add
por el subtract para restar tiempo a una fecha:
108

Object
• Utilidad para dividir la fecha y hora en cada una de
sus unidades (meses cuentan desde el 0):
109

Before
• Utilidad para saber si una fecha es anterior a otra:
110

After
• Utilidad para saber si una fecha es posterior a otra:
111

Between
• Utilidad para saber si una fecha está entre dos fechas:
112

Leap
• Utilidad para saber si una fecha pertenece a un año
bisiesto:
113

Primer test básico
• Postman está hecho principalmente para realizar test
sobre nuestros servicios web (en Javascript):
115

Primer test básico
• Al probar la petición (send) veremos una nueva
pestaña que nos muestra si el test se ha realizado
con éxito:
116

Primer test básico
• Si por ejemplo, escribimos un servicio que no existe,
el status no será 200 si no 404 y el test nos indicará
el fallo:
117

Test de JSON
• Podemos realizar más de una prueba en cada
petición. Por ejemplo:
118

Test de JSON
• Modificamos el test:
119

Test de JSON
• Agregamos alguna otra comprobación:
120

Test de JSON
• Podemos probar a cometer errores para ver el
resultado:
121

Test de JSON
• Es posible imprimir en la consola un log de lo que
queramos, por ejemplo:
122

Test de JSON
• Hacemos un clear de la consola, y si ejecutamos de
nuevo vemos el contenido de la variable llamada
jsonData:
123

Test de Delay
• Simulemos que queremos verificar que nuestro
servicio web no puede tardar más de X milisegundos
en devolver lo que haya pedido el usuario:
124

Test de Delay
• Modificamos el código proporcionado por el snippet:
125

Test de Delay
• Si disminuimos el tiempo puede que no se supere el
test:
126

Test de búsqueda
• Otro test podría ser el de comprobar si en la
respuesta a la petición, hay una palabra en concreto:
127

Test de búsqueda
• Modificamos el código para que busque una palabra:
128

Test de respuesta exacta
• Podemos verificar si se obtiene la respuesta completa
de la petición según lo esperado:
129

• La respuesta de esta petición es:
• Modificamos el código del test:
• Ojo con las comillas dobles y simples!
130

• Ejecutamos y vemos el resultado
131

Otros test
• Podemos verificar prácticamente cualquier valor
relacionado con la respuesta del servicio, header,
código del status, tiempos, tamaños, etc.
132

Assertions
• Funciones que podemos utilizar en nuestros tests:
134

Assertions
• Por ejemplo, comprobar el tipo de dato de un valor:
135

Assertions
• Comprobar si es string o number:
136

Assertions
• Otro tipos de test:
137

XML
• Podríamos tener respuestas en diferentes formatos:
139

XML
• Si recibimos valores en XML podemos convertirlos a
JSON y realizar el tipo de pruebas vistas antes:
140

Texto
• Si recibimos texto:
141

Texto
• Si recibimos texto, podemos realizar nuestros test de esta forma:
142

Variables en ejecución
• Podemos crear variables globales o de entorno en
ejecución. Creamos una nueva petición en POST:
144

Pre-request Script
• Podemos crear variables y ejecutar código en general
antes de llevar a cabo la ejecución de la petición:
146

Pre-request Script
• Estas variables las podemos usar luego en la petición:
147

Pre-request Script
• En el Pre-request podemos también enviar peticiones
para recuperar valores de estas peticiones:
148

Pre-request Script
• Dichos valores podemos usarlos en la petición actual:
149

Pre-request Script
• Es habitual tener test comunes en todas las
peticiones, como por ejemplo el estado y el tiempo:
150

Pre-request Script
• Una vez guardados los tests en una variable,
podemos usarlo de esta forma:
151

Pre-request Script
• Y podemos re-utilizarlos en cualquier otra petición:
152

Runner
• Postman tiene una herramienta que nos permite
ejecutar todos los tests presentes en una carpeta o
en una colección completa:
154

Runner
• Seleccionamos la
carpeta y
ejecutamos los
tests:
155

Runner
• Vemos el resultado
de la ejecución de
los test:
• Esto es muy útil
para probar todos
nuestros servicios
web con una sola
instrucción.
156

Flujos de trabajo
• El runner nos permite ejecutar los tests, pero
también nos permite simplemente ejecutar las
peticiones que tengamos en una carpeta o colección
• Las peticiones se ejecutan según el orden presente
en la carpeta, pero podemos modificar ese
comportamiento
158

Flujos de trabajo
• Vamos a crear una subcarpeta llamada Workflow con
4 peticiones básicas de tipo GET:
159

Flujos de trabajo
• Al ejecutarlas con el runner, se ejecutan según el
orden en el que están en la carpeta:
160

Flujos de trabajo
• Podemos cambiar el orden de esta forma:
161

Flujos de trabajo
• Volvemos a ejecutar el runner y vemos que después
del Req2 se ejecuta el Req4 (el Req3 no se llega a
ejecutar):
162

Flujos de trabajo
• Podemos indicar que después del Req 4 se ejecute el
Req3:
163

Flujos de trabajo
• Al ejecutar el Runner se crea un bucle infinito:
164

Flujos de trabajo
• Tenemos que indicar que al ejecutar el Req3 se
detenga la ejecución global:
165

Flujos de trabajo
• Al volver a ejecutar el Runner, vemos el flujo que
hemos definido:
166

Monitor
• Postman nos permite automatizar periódicamente la
ejecución de un conjunto de peticiones mediante su
herramienta llamada Monitor (1000 peticiones al mes
de forma gratuita)
168
• Creamos una nueva colección
llamada MonitorTest,
duplicamos la carpeta
Workflow y la arrastramos a la
nueva colección:

Monitor
• Creamos un nuevo Monitor:
169

Monitor
• Definimos la configuración y la frecuencia:
170

Monitor
• Las ejecuciones se llevarán a cabo en los servidores
de Postman y podremos consultar los resultados en
nuestra Web Dashboard:
171

Monitor
• Web Dashboard:
172

Postman.pdf

Más contenido relacionado

Similar a Postman.pdf (20)

Último (20)

Postman.pdf