La función más básica de Postman se utiliza para reproducir la solicitud y coopera con una buena herramienta de formato de respuesta.
Para un uso avanzado, puede utilizar Postman para generar scripts en varios idiomas y también puede capturar paquetes, autenticar y transferir archivos.
Simplemente hacer esto no es suficiente para el desarrollo de un sistema, o es demasiado trivial. Aún necesita alternar entre el entorno de desarrollo, el entorno de prueba y el entorno de producción con frecuencia. Una sola solicitud no es suficiente. Debe mantener todas las solicitudes de API del sistema, y cada solicitud también tiene una cadena de consulta y un cuerpo diferentes.
Colección
Todas las solicitudes en el lado del servidor están organizadas por función o módulo comercial. Utilice el descuento para agregar descripciones adecuadas a todas las solicitudes y ejemplos. En este momento, se utiliza la Colección. Las siguientes son algunas de la terminología del cartero y sugerencias para solicitudes de organización.
-
La colección corresponde a una aplicación y cada miembro (servidor, cliente, control de calidad) del grupo comparte una colección. Puede agregar pruebas y documentos a toda la Colección. Para las aplicaciones que no organizaban las solicitudes en cartero al principio, puede configurar Proxy, ejecutar la aplicación nuevamente y capturar todas las solicitudes de la aplicación.
-
Carpeta (ItemGroup) corresponde a un módulo o subrutas de cada nivel. Si
router.use('/users')todas las solicitudes están en una carpeta, las carpetas se pueden anidar entre sí de acuerdo con el enrutamiento. -
Solicitud (elemento) corresponde a una solicitud y puede agregar información de autenticación. También puede configurar un proxy para capturar paquetes.
-
El ejemplo corresponde a una solicitud con diferentes parámetros y respuestas, y se usa para Mock Server y documentos.
Postman puede generar documentos y Mock Server de acuerdo con la estructura de la Colección. Pero todas son funciones de pago, y la versión gratuita tiene un límite en el número de veces.
Documentación
Postman genera automáticamente documentos para ayudar a la colaboración en equipo y resuelve los principales errores de redacción manual de documentos y actualizaciones inoportunas.
Para solicitudes GET, se puede agregar una descripción del campo en Postman para generar un documento.
Para solicitudes POST y PUT, si el tipo de contenido es form-data o x-www-form-urlencoded , puede agregar una descripción para generar un documento. Sin embargo, pasar json es más conveniente y flexible hoy en día, por lo que application/json habrá muchos y no se puede comentar json. Si necesita agregar documentación a json, puede agregar campos redundantes para _{key}.comment indicar comentarios
{
"id": 128,
"_id.comment": "id",
"page": 10,
"_page.comment": "页数"
"pageSize": 15,
"_pageSize.comment": "每页条数"
}
Sin embargo, hay demasiados campos redundantes y una mejor solución es realizar la verificación json en la solicitud en la prueba y, al mismo tiempo, servir como parte de la función del documento. Después de todo, json-schema se usa para describir datos para hacerlos más legibles.
Hablando de la solicitud anterior, para el documento de respuesta, puede verificar el esquema json o la descripción de cada campo, y más casos de prueba representan más detalles.
Burlarse de
Cuando el servidor no ha escrito la API, el cliente puede generar Mock Server de acuerdo con los Ejemplos.
Se recomienda que el cliente haga su propio Mock, lo integre con el proyecto e incorpore el control de versiones, lo cual es conveniente y flexible.
prueba
Para cada solicitud, se requiere un caso de prueba. Verifique si la respuesta es exitosa, si el tiempo de respuesta es demasiado largo o si el tipo de datos del json de respuesta es correcto.
La prueba se puede utilizar pm.expect para BDD realizar pruebas y el estilo es chai muy similar. Si está familiarizado con chai ella, es fácil comenzar.
Postman tiene algunas bibliotecas de terceros integradas. Si lo prefiere chai , puede usarlo directamente o usar la pm.expect implementación de chai subyacente, que es consistente con la API de chai BDD.
Postman también tiene algunas API de prueba relacionadas con http, como código de estado, encabezado, cuerpo y también proporciona algunos fragmentos.
// 响应成功
pm.test('Status code is 200', () => {
pm.response.to.have.status(200)
})
// 响应成功 chai.expect
pm.test('Status code is 200', () => {
chai.expect(pm.response).to.have.property('code', 200)
})
// 校验响应数据
pm.test('Page is 100', () => {
const jsonData = pm.response.json()
chai.expect(jsonData.page).to.eql(100)
})
Esquema Json
json-schema se puede usar para describir información json, hacer que json sea más legible y también se puede usar para verificar la legitimidad de json. Los principales lenguajes tienen bibliotecas que implementan json-schema.
Se recomienda realizar la verificación del esquema json en todas las respuestas GET, en primer lugar para verificar los datos, en segundo lugar, también se puede usar como un documento, use tv4 para verificar json
pm.test("User info", () => {
const jsonData = pm.response.json()
const schema = {
title: 'UserInfo',
discription: '用户信息',
type: 'object',
required: ['age', 'email', 'name'],
properties: {
age: {
description: '年龄',
type: 'number',
mininum: 0,
},
email: {
description: '邮箱',
type: 'string'
},
name: {
description: '姓名',
type: 'string'
}
}
}
pm.expect(tv4.validate(jsonData, schema)).to.eql(true)
})
También puede agregar la verificación json a la solicitud, pero es más complicado, porque el cartero no proporciona directamente la API para obtener todos los parámetros de la solicitud, debe analizarla y calcularla usted mismo.
// 获取 application/json 中的数据
const json = JSON.stringify(pm.request.body.raw)
// 获取 GET query string 的数据
const qs = pm.request.url.query.toObject()
Sería genial si el cartero pudiera generar automáticamente datos basados en el esquema json de los parámetros de solicitud ...
Parámetros de solicitud de prueba
Una solicitud con un número de parámetros, tales como GET el querystring(search) así como POST los bodydiferentes parámetros tienen respuesta diferente.
Suponiendo que el esquema json devuelto por diferentes parámetros de una solicitud es completamente diferente, puede escribir dos solicitudes para probar por separado. Si el esquema json devuelto es el mismo, pero el valor es diferente, debe considerar qué parámetros se pasan y cuántos son.
En un escenario clásico, la lista calificada se filtra según el filtro. Tome la lista de usuarios como ejemplo, el pseudocódigo es el siguiente
const url = '/api/users'
const query = {
name: 'san',
age: 12,
sex: 'MALE'
}
// 注意query数据需要校验，防止 SQL 注入
const sql = `select * from users where name = ${query.name} and age = ${query.age} and sex = ${query.sex}`
Una idea es probar de acuerdo con los parámetros solicitados. Un snipet importante es obtener la cadena de consulta en cartero. La consulta es un tipo PropertyList de datos definido en cartero-colección-PropertyList. como sigue
const name = pm.request.url.query.get('name')
const age = pm.request.url.query.get('age')
if (name) {
pm.test('Items should match the name', () => {
const jsonData = pm.response.json()
expect(_.uniq(jsonData.rows.map(row => row.name))).to.eql([name])
})
}
// 冗余代码有些多，postman不知道支不支持自建 snipets
if (age) {
pm.test('Items should match the age', () => {
const jsonData = pm.response.json()
expect(_.uniq(jsonData.rows.map(row => row.age))).to.eql([age])
})
}
Por supuesto, el filtro anterior solo contiene el escenario más simple, que solo involucra la prueba de igualdad. Pero existen relaciones de disparidad e inclusión.
const query = {
name: 'san',
age: 12,
sex: 'MALE'
}
const sql = `select * from users where name like ${query.name} and age < ${query.age} and sex = ${query.sex}`
Este tipo de parámetro de solicitud depende de la negociación y comunicación entre los front-end y back-end, por supuesto, es muy poco amigable para las pruebas o un desarrollo desconocido.
Por supuesto, no es amigable con el backend, porque necesita procesar cada consulta que pasa y necesita cambiarla manualmente cada vez que agregue un campo de filtro en el futuro.
Depende del front-end determinar los datos que se filtrarán, por ejemplo, si se usa una sintaxis de búsqueda similar a mongo.
graphql es genial, vale la pena intentarlo
const query = {
name: {
$like: 'san'
},
age: {
$lt: 12
},
sex: 'MALE'
}
Sin embargo, esto requiere capacidades de desarrollo de pruebas relativamente altas, y los probadores necesitan analizar parámetros e interfaces de prueba.
Pruebe varias solicitudes
Cuando se realiza una prueba unitaria de una función, se requieren muchas entradas y salidas esperadas. En cartero, se puede usar data para simular múltiples entradas
data es una variable que solo se puede usar en Runner. Es necesario establecer un archivo de datos relacionado para cada carpeta y agregar control de versión
- usando archivos csv y json en el corredor de colección de cartero
Pruebas de integración
Después de pasar una única prueba de API, todas las solicitudes deben integrarse para la prueba. En este momento hay dos problemas
- Cómo garantizar la dependencia de la API
- Cómo pasar datos entre API
Es el orden de su petición de que inició la solicitud con el fin colección, y si es necesario a la fuerza para cambiar el orden, puede utilizar setNextRuest()tres alcance de los datos en el cartero, data, environment, global. {
{}} Reemplazar con marcadores de posición en la solicitud .
environment Se puede utilizar para cambiar HOSTpara evitar cambios manuales frecuentes del entorno local, el entorno de desarrollo y el entorno de producción en la URL. También se puede utilizar para transferir datos.
Un escenario común es que el proyecto usa un token para guardar la información de inicio de sesión y cada solicitud debe llevar el token. La variable de entorno del token se puede configurar en el código de prueba de inicio de sesión
const url = 'http://{
{HOST}}/api/login'
pm.test('There is a token', () => {
const jsonData = pm.response.json()
pm.expect(jsonData.token).to.a('string')
pm.environment.set('token', jsonData.token)
})
const urlNext = 'http://{
{HOST}}/api/profile?token={
{token}}'
Colección de prueba
Después de asegurar las dependencias, puede crear un nuevo corredor para la colección e introducir un archivo de datos para probar todas las solicitudes. También puede utilizar Runner y datos para probar la carpeta parcial.
La última versión de cartero ya es compatible, cree nuevas variables y pruebas para cada cartero
Todas las solicitudes tendrán algunas pruebas comunes, como si la interfaz de prueba responde correctamente y el filtro de prueba mencionado anteriormente
pm.test('Response is right', () => {
// status code: 2XX
pm.response.to.be.success
})
pm.test('Filter is matching', () => {
// ...
})
Integración continua
Cuando pueda probar la Colección, debe agregar el control de versiones a la prueba, integrarlo con el proyecto y mantener registros de prueba para localizar errores a tiempo. Se puede newman integrar con las herramientas oficiales del cartero , pero un inconveniente es que la integración continua solo puede guardar registros, no restaurar registros.
newman run https://api.getpostman.com/collections/{
{collection_uid}}?apikey={
{postman-api-key-here}} --environment https://api.getpostman.com/environments/{
{environment_uid}}?apikey={
{postman-api-key-here}}
Pruebas de automatización de UI de contraste
Según tengo entendido, el propósito de las pruebas de automatización de la interfaz de usuario es probar si el proceso es fluido, como iniciar sesión, registrarse y cerrar sesión, y hacer capturas de pantalla si falla el caso de uso. Sin embargo, los cambios constantes en los requisitos de front-end, junto con varios marcos de front-end ahora, hacen que los selectores no sean particularmente fáciles de obtener y que el proceso sea fácil de cambiar.
La prueba automatizada de API se utiliza para probar si los datos son correctos. Y la mayoría de los problemas son problemas de datos, por lo que las pruebas automatizadas de API son más rentables.
Si intercambia experiencia en pruebas de software, pruebas de interfaz, pruebas automatizadas y entrevistas. Si está interesado, puede agregar comunicación de prueba de software: 1085991341, y habrá intercambios técnicos con colegas.
para resumir
- Cómo escribir casos de prueba
[chai.js]La gramática bdd usada al final de postman se usa como una biblioteca de aserciones y se agregan algunas gramáticas únicas.
- Cómo depurar
Haga clic en la barra de menú Ver -> Mostrar herramientas de desarrollo (Mostrar consola de cartero) para ver la respuesta y verificar el resultado, pero no puede interrumpir el punto. Para una sola solicitud del sistema, puede usar Proxy para monitorear la solicitud de depuración.
- Cómo utilizar bibliotecas de terceros js para preprocesar y posprocesar solicitudes
Por ejemplo: al enviar una solicitud, el servidor requiere timestmap(unix) el formato de la hora , pero la legibilidad de la interfaz es demasiado débil durante la depuración, ¿se puede utilizar la moment hora de conversión? Cuando recibe una respuesta, también debe moment analizar el tiempo para obtener una mejor presentación. O utilice lodash algunas funciones para el procesamiento de datos.
Puede escribir secuencias de comandos en Pruebas y secuencias de comandos de solicitud previa para procesar algunas solicitudes y respuestas. Pero no puede formatear datos, como fechas. Se recomienda utilizar cadenas con formato ISO al comunicar la fecha entre el anverso y el reverso. Tanto el anverso como el reverso son fáciles de analizar y leer.
- Cómo administrar las dependencias de solicitudes
Por ejemplo: dos API deben tener una relación de dependencia. Por ejemplo, cuando se crea un usuario (se registra), se obtiene su información personal. Para obtener información personal, debe confiar en la API para crear un usuario.
Use variables de entorno para administrar dependencias
- Cómo establecer parámetros de solicitud uniformes
Por ejemplo: la mayoría de las interfaces requieren token parámetros uniformes .
Parece que no hay manera
- Cómo integrarse en proyectos del lado del servidor
Si la versión posterior del sistema no pasa la prueba de API, es importante mantener el registro de la prueba, y el control de versiones puede conocer los cambios de código durante este período de tiempo. Tome git como ejemplo, debe ejecutar la prueba después de cada envío y conservar los resultados de la prueba.
Puede usar el paquete npm newman para integrarse en el proyecto
El contenido anterior es el contenido completo de este artículo. El contenido anterior espera ser útil para usted. Los amigos que han sido ayudados son bienvenidos a dar me gusta y comentar.