Cómo automatizar las pruebas de la API REST con grandes cargas útiles de solicitudes

¿Cómo se obtiene un conjunto de unas pocas docenas de casos de prueba de API REST, que tienen cargas útiles de solicitud muy grandes, en cuestión de segundos? Adoptar un enfoque científico para las pruebas ayuda a crear consistencia con Automatización de pruebas de API REST, pero incluso los científicos necesitan una mano de vez en cuando.

Los probadores son la última línea de defensa entre nuestras aplicaciones y sus audiencias cada vez más conocedoras de la tecnología. Si implementamos una aplicación en el mercado que tiene defectos o problemas de rendimiento, nuestros clientes ya no la tolerarán. Como resultado, los evaluadores deben ser inteligentes y capaces de probar aplicaciones modernas de la manera más impactante posible. Pero las pruebas son una ciencia y requieren que adopte un enfoque sistemático para validar una aplicación.

La prueba es una ciencia

Pero incluso con un enfoque científico de las pruebas, las pruebas de software no son tan simples. Los probadores suelen pasar por un proceso como el siguiente:

1. Haga una pregunta, generalmente sobre el comportamiento de la aplicación. (Requiere una cantidad considerable de creatividad).
2. Realice una investigación de antecedentes para comprender las múltiples interfaces (web, móvil, API, etc.), cómo probarlas con precisión y cómo debería funcionar la aplicación.
3. Construya una hipótesis (es decir, pruebas de aserción y regresión). Según su comprensión de cómo "debería funcionar" la aplicación, puede configurar las variables que indiquen sus expectativas.
4. Pruebe su hipótesis construyendo pruebas (de la manera más significativa posible para que pueda probar o refutar su hipótesis (afirmación / regresión).
5. Analiza tus resultados y saca conclusiones. Después de ejecutar sus pruebas y recibir los resultados, puede interpretar manualmente para ver si cumplen con sus expectativas, o puede automatizar la ejecución de la prueba para que solo se le avise de las fallas de la prueba.
6. Comunique sus resultados a la tubería de entrega de software más grande para que la organización pueda tomar una decisión significativa sobre si debe seguir adelante con la aplicación.

Las pruebas no son un asunto simple, por lo que necesitamos todo el apoyo que podamos obtener para crear estos experimentos significativos que puedan proporcionar comentarios significativos para garantizar que nuestras aplicaciones se construyan correctamente. ¡Y es importante para nosotros, como probadores, comunicar entre nosotros cualquier método que hayamos descubierto para facilitar las pruebas! Aquí, uno de esos métodos. A continuación, explicaré un desafío reciente de prueba de API REST que tuve y compartiré cómo pude resolver el problema.

Pruebas de API REST con grandes cargas útiles de solicitudes

Las aplicaciones web modernas envían llamadas RESTful JSON API desde el navegador al servidor porque los datos JSON son fáciles de usar con código JavaScript. Pero crear scripts de automatización de pruebas con esos datos JSON no siempre es tan fácil. Recientemente, encontré un dolor de cabeza con las pruebas debido a las grandes cargas útiles de solicitud JSON en el servicio que estaba probando, y pude usar Prueba SOA de ParasoftEl nuevo generador de pruebas API inteligente para ayudar.

A diferencia de los grandes solicita cargas útiles, grandes respuesta Las cargas útiles son fáciles de manejar para los probadores. Llame al servicio, guarde la respuesta y luego compare las diferencias con las respuestas futuras. Elimine los valores que siempre puedan cambiar, como fechas o marcas de tiempo. Enjuague y repita. Sin embargo, todo esto se basa en llamar al servicio en primer lugar. Con cargas útiles de solicitud grandes, debe configurar una gran cantidad de datos antes de realizar cada llamada de servicio, y debe asegurarse de que todo sea correcto. Claro, puede copiar y pegar desde las herramientas de desarrollo del navegador, pero con muchas llamadas a la API REST, eso significa mucho copiar y pegar. Es por eso que ahora es tan emocionante poder utilizar Smart API Test Generator.

Mi proyecto reciente involucró una página de configuración web para la integración con servidores LDAP y Active Directory. El concepto era simple: configure los ajustes y luego pruebe enumerando las cuentas de usuarios y grupos. El problema era que una configuración LDAP tiene muchas configuraciones, y probar esas configuraciones requiere enviarlas todas en la carga útil de la solicitud. Además, se necesitaron llamadas adicionales para probar la membresía de cada grupo. Cada solicitud terminó siendo cientos de líneas de datos JSON.

Estaba trabajando para agregar apoyo para una nueva estrategia de membresía. Los únicos datos JSON que me importaba probar estaban en la línea 10, pero todas las demás líneas de datos aún eran necesarias para que todo funcionara. Entonces, configuré mi página de configuración para apuntar a un servidor LDAP con datos de prueba y encendí la grabación usando la extensión Parasoft Recorder para Chrome. Hice clic en botones para probar usuarios y grupos, y expandí cada grupo para ver los miembros. Cada vez que hice clic, se realizaron algunas llamadas a la API REST al servidor web.

La hipótesis era que la estrategia de membresía afectaría a los grupos y miembros en la vista previa. Cambié la estrategia de membresía en la página de configuración y volví a hacer clic en los datos de prueba. Visualmente, pude ver diferentes resultados de pertenencia a grupos en el cuadro de diálogo. Estaba satisfecho con mi prueba manual, así que dejé de grabar y generé un conjunto muy inteligente de pruebas API:

Y ahí estaba: en cuestión de segundos tenía un conjunto de algunas docenas de pruebas de API REST que tenían cargas útiles de solicitud muy grandes. Solo algunas propiedades como el nombre del grupo y la estrategia de membresía cambiaron entre las solicitudes, pero fue suficiente para obtener una variación en las respuestas y guardar un control de diferencias para cada una. Incluso fue lo suficientemente inteligente como para extraer los nombres de los grupos de la primera respuesta de vista previa del grupo y almacenarlos en un banco de datos para su uso parametrizado en las siguientes pruebas. Ver pasar todas las pruebas me dio la confianza de que mi nueva función de estrategia de membresía estaba funcionando correctamente.

Todo esto se hizo utilizando un servidor LDAP con datos de prueba en lugar de cuentas de usuario reales. Puedo asegurarme de que los datos de prueba no cambiarán, pero los usuarios reales van y vienen con el tiempo. El cambio de datos puede crear mucho ruido en los controles de regresión de prueba automatizados. Si no tiene datos de prueba estables para su aplicación, le sugiero que consulte el servicio web o la virtualización de bases de datos que ofrece Virtualización de Parasoft.

Mi desafío de prueba, resuelto

Como comenté al principio de esta publicación, adoptar un enfoque científico de las pruebas ayuda a crear coherencia. ¡Pero incluso los mejores científicos necesitan una mano de vez en cuando! La técnica que describí anteriormente es como usar un microscopio de alta potencia en lugar de una lupa. Es un avance significativo en lo que de otra manera sería un proceso muy complicado y, al menos para mí, ayudó a acelerar significativamente mi desafío de prueba. Espero que te haga lo mismo. ¡Feliz prueba!