Si ha estado utilizando Postman para probar el rendimiento de la API web o supervisar el tráfico de Postman con Dotcom-Monitor,la tarea de recopilación de carteros puede ser una herramienta muy rápida y eficaz para configurar una prueba de carga en LoadView. Para empezar con la configuración de una prueba de carga, todo lo que tiene que hacer es crear una colección a partir de las llamadas a la API web existentes en Postman y cargarla en Dotcom-Monitor.

  • ¿Qué es Postman?

    ¿Qué es Postman?

    Postman es todo sobre el desarrollo de API. Es un cliente de API que permite a los desarrolladores y equipos crear, probar, compartir y documentar las API a través de una sola plataforma. Proporciona varias características, como pruebas manuales y automated, colaboraciónde iony documentación decreating para sus API. Postman incluso incluye la capacidad de configurar servidores y monitores ficticios,para que losdesarrolladores puedan realizar solicitudes que puedan devolver datos de prueba para garantizar la funcionalidad antes de pasar a producción.

    Tener estas características en una plataforma permite a los equipos de desarrollo agilizar el proceso de desarrollo de API y ofrecer una forma más refinada y de mayor calidad. API en un ciclo corto de desarrolloelopment . Postman es compatible con una plétora de llamadas API, incluyendo REST, SOAP y HTTP, Y Idiomas de API Como OpenAPI, GraphQL, y RAML. Es also Soporta Varios Autenticación y autorización Métodos incluyendo OAuth, claves de API, autenticación básica, tokens de portador y más para garantizar que la solicitud de API se envíe de forma segura. La mejor parte para los desarrolladores es que ofrecen una cuenta gratuita para empezar. Los equipos más grandes pueden aprovechar los planes de pago que permitenCess to más características y funcionalidades.

    En Postman, los usuarios pueden realizar solicitudes para recuperar o enviar datos desde puntos finales de API sin tener que crear código o un terminal. Estas solicitudes se realizan utilizando los métodos HTTP estándar, como GET, POST, PATCH, PUT y DELETE, sin embargo, hay tipos adicionales de tipos de solicitud ofrecidos que los usuarios podrían aprovechar dentro de la interfaz Postman.

    Además de crear solicitudes, cada solicitud se puede nombrar individualmente, dependiendo de la acción que se solicite. Por ejemplo, si está enviando una solicitud GET solicitando un país o estado, puede nombrar esa solicitud “país GET” o “estado GET”, lo que facilita su búsqueda más adelante. Después de que se haya realizado la solicitud, Postman también mostrará a los usuarios el código de estado HTTP, como una respuesta OK 200, y cuánto tiempo tomó para esa solicitud.

Cuándo elegir la tarea HTTP en lugar de la tarea de recogida de carteros

Hay un aspecto que debe tener en cuenta al configurar una prueba de carga utilizando una colección Postman,pero first, vamos ahablar un poco sobre lo que es una colección de carteros y algunos de los antecedentes detrás de esta característica Postman.

Unaollección de Postman Ces una colección de salvados Solicitudes que los desarrolladores usan para crear para un caso de uso específico que luego pueden organizar en carpetas y acceso siempre que lo necesiten. Por ejemplo, se podría crear una colección para obtener recursos de usuario específicos o información después de que un usuario haya iniciado sesión una API. En lugar de tener que volver para encontrar todas estas diferentes solicitudes individualmente, puede ponerlas en una colección. Esto facilita la agrupación de todas sus solicitudes en un solo plas y acceder rápidamente a ellos más tarde. Además, los usuarios pueden especificar los detalles de autenticación para una colección completa o establecerlos individualmente por solicitud.

En LoadView, cada script de una prueba de Postman se ejecuta mediante un proceso dedicado. Debido a las particularidades en la asignación de carga en los servidores de inyectores de carga,LoadView puede ejecutar hasta 30 procesos a la vez en un único servidor de inyector de carga. Por lo tanto, puede configurar el sistema para que ejecute hasta 30 usuarios simultáneos por inyector de carga. En términos de carga útil, esto significa que cuantos más usuarios simultáneos desee ejecutar mientras prueba cuantos más inyectores de carga necesita usar para la prueba de carga. Esto puede aumentar el costo total de las pruebas de carga de gran tamaño (consulte Precios del inyector de carga).

En el caso de que necesite escalar verticalmente muchos usuarios simultáneos, considere la posibilidad de convertir la colección Postman en la prueba de carga HTTP de varias solicitudes como se describe para las pruebas de carga de Rest Web API. Dado que una prueba HTTP no se ejecuta en un solo proceso, no requiere tantos recursos de Load Injector como la tarea de recopilación de carteros. Por lo general, para la prueba HTTP, puede ejecutar de 500 a 1000 usuarios simultáneos en un solo servidor de inyección de carga. Por lo tanto, puede escalar la carga útil en números mucho más altos que con tarea de recolección de carteros sin un aumento significativo en el costo total.

Crear una prueba

Antes de comenzar la configuración de la tarea, prepare la colección Postman que se va a importar a Dotcom-Monitor como se describe en Carga de la colección de postmanes a Dotcom-Monitor.

Para configurar el escenario de prueba de carga, consulte Pruebas de carga de API web con Postman Collection para obtener algunas sugerencias especiales.

Una vez que haya seleccionado la tarea Colección de carteros, se le pedirá que importe una colección de carteros y ajuste la configuración de la tarea.

Importación

Haga clic en Importar y seleccione una opción adecuada para cargar la colección. Puede cargar el archivo JSON con la colección Postman o proporcionar el vínculo público a la colección (si se publicó). El script de colección se mostrará en la sección Solicitudes de colección.

De forma predeterminada, importamos la configuración de la colección desde Postman. Si es necesario, puede cambiar los valores correspondientes en la configuración de prueba de LoadView. Tenga en cuenta que los valores de las variables de entorno no se pasan junto con la configuración de la colección. Si utiliza variables en la colección importada, consulte Cómo trabajar con variables de entorno de cartero en Dotcom-Monitor.

Retraso entre solicitudes

Un retraso (en segundos) entre cada solicitud de la colección. El tiempo de retardo se considera en el cálculo del tiempo de respuesta. De forma predeterminada, el sistema utiliza un retraso aleatorio de entre 3 y 6 segundos que simula el retraso normal del usuario. Puede establecer un retraso personalizado entre solicitudes en el siguiente paso de la configuración de la prueba de carga: en la página Configuración de prueba de carga , haga clic en
Ajustar comportamiento del usuario
y especifique un retraso personalizado entre solicitudes.

Ignorar errores de red

De forma predeterminada, Dotcom-Monitor comprueba las solicitudes de red del Postman sobre errores de red. Si los errores de red no son su preocupación, puede configurar el sistema para filtrar este tipo de error. Si la opción Ignorar errores de red está establecida en , Dotcom-Monitor no generará un error en las solicitudes fallidas del remitente. Sin embargo, podrá ver los errores HTTP en el informe de sesión de prueba relacionado.

Umbral de validación de tiempo

Un intervalo de tiempo en segundos la tarea debe esperar a que se completen las solicitudes y la ejecución de la colección antes de finalizar la tarea y devolver un error. En el caso de tiempo de espera, se generará un error de validación en la validación del dispositivo de prueba.

Tiempo de espera de solicitud

Intervalo de tiempo en segundos, la tarea debe esperar una respuesta en una sola solicitud de la colección.

Tiempo de espera del script

Un intervalo de tiempo en segundos la tarea debe esperar a que se complete el script de aserción antes de finalizar la tarea y devolver un error. El tiempo de espera máximo del script es de 30 segundos.

Limitaciones de las pruebas de rendimiento de API con cartero

Postman se puede utilizar para automatizar muchos de los tipos de pruebas diarias que los desarrolladores llevan a cabo manualmente, como pruebas unitarias, pruebas funcionales, pruebas de integración, pruebas de regresión, pruebas simuladas y mucho más. Los desarrolladores y equipos también pueden automatizar las pruebas integrandoherramientasde CI/CD populares, como Jenkins, para probar sus compilaciones.

Sin embargo, para llevar a cabo pruebas de rendimiento con cientos o miles de usuarios simultáneos, los usuarios de Postman tendrán que utilizar una solución de pruebas de carga y rendimiento de terceros. Aquí es donde el La solución LoadView puede ser realmente una excelente manera de llevar a cabo rápida y fácilmente pruebas de rendimiento para sus API. Hasta este punto en el proceso de desarrollo, se ha dedicado mucho trabajo y tiempo a garantizar la funcionalidad. No deje que eso se desperdicie al renunciar a las pruebas de rendimiento.

Las pruebas de rendimiento llevan las pruebas funcionales al siguiente nivel para asegurarse de que sus API soportarán condiciones del mundo real. Usted no quiere empujar ciegamente el código a la producción withopruebas de ut primero. Corre el riesgo de que los usuarios se encuentren con un menos de lo deseable Experiencia. Por testing API tiempos de respuesta y fiabilidad mientras está bajo carga, puede comprender mejor cómo reaccionará y funcionará su API en condiciones de tráfico pico Y ajustar los recursos y la capacidad según sea necesario. Cartero ofrece una característica llamada Postman Collection Runner, pero no es un sustituto de verdaderas pruebas de rendimiento de extremo a extremo.

El objetivo principal del corredor de la colección Postman es mostrar si sus solicitudes superan o fallan a medida que se ejecutan consecutivamente. Postman no tiene la funcionalidad para ejecutar pruebas de carga grandes y de gran volumen dentro de la plataforma. Es ideal para probar la funcionalidad de la API y verificar si las solicitudes resultan en respuestas válidas o no, pero si su API finalmente será utilizada por un gran número de usuarios simultáneos, querrá asegurarse de que sus sistemas y servicios van a ser capaces de manejar la carga esperada a la API.

Escenario y ejecución de prueba de LoadView

Una vez que haya terminado de importar su Postman Colleconfiguración de la prueba, puede comenzar el proceso final de configuración de su scenario y la ejecución de su prueba de carga. LoadView proporciona múltiples opciones de curva de prueba para adaptarse mejor a sus objetivos de prueba. Las opciones incluyen la carga estándar Paso curva, curva basada en objetivos y dinámicamente ajustable Curva. Cada tipo de curva de carga le proporciona la capacidad de establecer varios niveles de usuario simultáneos y tasas de transacciones durante la duración de sus pruebas.

  • Curva de paso de carga: le permite establecer su plan de ejecución de pruebas de rendimiento con un número inicial de usuarios,así como acciones adicionales, como la cantidad de tiempo que se debe mantener o aumentar el número de usuarios simultáneos
  • Curva basada enobjetivos: Ajusta los usuarios simultáneos para cumplir una tasa predefinida de transaccioness.
  • Curva ajustable dinámica: Esto le permite aumentar o disminuir el número de usuarios simultáneos mientras se ejecuta la prueba, para que pueda ver cómo responde su sistema.

Obtenga más información sobre estas curvas de carga yla configuración adicional del escenario de prueba de LoadView.

Uno de los últimos pasos en el escenario de pruebas de carga es elegir dónde para ejecutar su prueba de. Tla plataforma LoadView ofrece más de 20 ubicaciones en todo el mundo que mejor coinciden con el lugar donde se encuentran sus usuarios para tener una mejor idea del rendimiento por ubicación.

La plataforma LoadView tiene como objetivo optimizar los objetivos y procesos de pruebas de performance. LoadView no requiere ningún hardware o red adicional para administrar, lo que permite a sus equipos establecer rápidamente y ejecutar suspruebas porformance sin las molestias que otras plataformasrequieren.