X
BLOG

Las pruebas de API son geniales, entonces, ¿por qué no lo hacen todos?

Las pruebas de API son geniales, entonces, ¿por qué no lo hacen todos? Tiempo de leer: 7 minutos
Las pruebas de API proporcionan una gran cantidad de automatización mantenible que se puede extender a pruebas de rendimiento y seguridad, pero es inaccesible para un evaluador promedio. Aprenda a reducir significativamente el tiempo asociado con la creación de escenarios de prueba significativos.

El cambio a microservicios y arquitecturas impulsadas por API está impulsando una innovación significativa en todas las industrias, pero también ha abierto a las empresas a una capa oculta de riesgo. Las interfaces humanas (UI web y móviles) ya no son los principales riesgos comerciales. En cambio, las mayores vulnerabilidades están ocultas en la interfaz no humana de la API.

Por esta razón, las pruebas de API se han convertido cada vez más en un foco, pero todavía escuchamos todo el tiempo, "¿Qué son las pruebas de API de nuevo y por qué las necesito?"

El resumen rápido es que las interfaces de programación de aplicaciones (API) son la forma en que las aplicaciones se comunican entre sí mediante una interfaz común administrada por un contrato definido. La fuerza impulsora detrás de la adopción de las pruebas de API es poder probar la lógica empresarial de la aplicación de una manera estable independiente de la interfaz de usuario. Las pruebas de API permiten pruebas más completas que las pruebas únicamente en el front-end, lo que permite pruebas de rendimiento y seguridad, por ejemplo. Los analistas de la industria y los expertos ágiles, como Martin Fowler y Mike Cohn, están de acuerdo en que las pruebas de API son el camino a seguir. Entonces, ¿qué nos detiene?

El impacto de las pruebas ineficaces

Los equipos de software quieren dedicar la cantidad ideal de tiempo, y nada más, a probar y depurar para maximizar el potencial de proyectos exitosos. Sin embargo, tradicionalmente ha sido difícil disminuir esta cantidad de tiempo dedicado a probar y depurar porque se han encontrado muchos errores graves y vulnerabilidades de seguridad al final del ciclo de vida del software, incluso después del lanzamiento.

El cuadro a continuación ilustra cuándo se introducen defectos en la aplicación y el impacto del tiempo en el costo de reparar un defecto en cada etapa. Como puede ver claramente, el costo de los defectos de ciclo tardío es significativo, y este aumento en el costo proviene de muchos factores (es decir, el tiempo que lleva diagnosticar el problema e identificar la causa raíz, la cantidad de personas involucradas en el proceso, y la creciente complejidad (y por lo tanto, el riesgo) asociado con la corrección de defectos).

Si está pensando para sí mismo, "He visto esto antes" ... ¡probablemente lo haya hecho! En 1996, Capers Jones publicó la investigación detrás de este gráfico e, incluso con los cambios en las prácticas de desarrollo de software durante los últimos 20 años, la investigación actualizada dice que todavía es relevante en la actualidad.

Dónde queremos estar: la pirámide de pruebas

Entonces, ¿dónde vamos mal? Nos estamos equivocando con nuestro enfoque de la calidad: debemos mirar el cuadro anterior y buscar formas de shift-left la detección de defectos y encontrar los defectos antes, cuando son más fáciles de diagnosticar y más fáciles de remediar. Técnicas como el análisis profundo de código pueden descubrir rápidamente problemas de seguridad y confiabilidad incrustados en la base de código tan pronto como se escribe el código, pero para poder validar el tiempo de ejecución o el comportamiento funcional, debemos invertir tiempo en crear y mantener pruebas automatizadas y, en un mundo ágil, necesitamos que esas pruebas se ejecuten continuamente una vez que se hayan creado para que puedan "desplazar hacia la izquierda" la detección y capturar las regresiones tan pronto como se implemente la nueva funcionalidad.

La forma ideal de invertir tiempo y organizar su cartera de pruebas a menudo se representa como la "pirámide de prueba", como se muestra a continuación, al impulsar tanto esfuerzo de prueba lo antes posible en la línea de tiempo de desarrollo. Comienza con una base de pruebas unitarias, donde los errores encontrados son baratos de corregir, y luego API, integración, pruebas de componentes y pruebas de sistemas e IU completan los niveles de la pirámide.

Pero mientras prácticas como el desarrollo impulsado por pruebas (TDD), prueba unitaria en etapa temprana, y una mayor automatización en las pruebas de software se está volviendo más común, los equipos de software todavía pasan demasiado tiempo en la IU de ciclo tardío y las pruebas del sistema. A menudo hemos descrito la situación actual como una pirámide invertida (un cono de helado); sin embargo, al observar más de cerca los datos, vemos una falta significativa de pruebas API en la industria, por lo que una copa de martini es más apropiada:

Prueba de API ¿Por qué nadie lo está haciendo?

Es una lástima que esta capa intermedia de la pirámide de prueba no se utilice en general, porque hay claras ventajas de invertir en pruebas de API. Por ejemplo, las pruebas se pueden realizar antes en el ciclo de vida del desarrollo de software (tan pronto como los contratos / definiciones de API estén disponibles), se pueden automatizar más fácilmente y son fundamentalmente menos frágiles para los cambios entrantes en la UI / UX de la aplicación. .

Es posible crear pruebas a nivel de escenario organizando las pruebas de API en casos de uso comunes, y la automatización de las pruebas de API allana el camino para las pruebas de seguridad y rendimiento basadas en escenarios y en etapas iniciales. En última instancia, la inversión en pruebas de API permite a los equipos gestionar mejor el cambio y obtener la agilidad prometida por los métodos de desarrollo modernos. Probando temprano y con frecuencia, ¿qué puede no gustarme? Desafortunadamente, los equipos están luchando para implementar las pruebas de API por varias razones.

¿Qué restringe las pruebas de API?

El mayor impedimento para una mayor adopción de las pruebas de API es la creación real de las pruebas. No es fácil crear pruebas significativas que funcionen a nivel de API, y mucho menos encadenarlas para crear escenarios de prueba adecuados. Igualmente fundamental para prevenir la adopción de pruebas de API es la brecha de conocimiento que existe entre desarrolladores y evaluadores. Las pruebas de API requieren conocimientos y habilidades de los que los evaluadores a menudo carecen, y los gerentes no quieren asignar desarrolladores para que realicen pruebas de API o de integración.

Los desarrolladores trabajan desde la base de la pirámide hacia arriba y se sienten cómodos trabajando a nivel de unidad. Es su código (o al menos, su ámbito de responsabilidad), y las pruebas unitarias parecen encajar de forma natural en su flujo de trabajo. Creación automática de pruebas unitarias ha mejorado la eficiencia en este nivel, y la industria del software comprende la necesidad de realizar pruebas exhaustivas aquí.

Los evaluadores, por otro lado, trabajan desde la parte superior de la pirámide en el nivel de la interfaz de usuario, donde los casos de uso y las interfaces son intuitivos y fáciles de asignar a los requisitos comerciales originales. Su vista de la aplicación está en el exterior mirando hacia adentro.

pirámide_prueba

Las pruebas de API se encuentran entre estos dos roles y requieren tanto conocimiento del diseño de las interfaces como de cómo se utilizan. Los probadores no suelen trabajar en este nivel, ya que ven la API como código, y aunque los desarrolladores entienden las interfaces y las API, normalmente no tienen una visión completa de cómo se utilizará la interfaz junto con otros subsistemas, por lo tanto, vea las pruebas de API como prueba funcional y fuera de su rol.

Hasta hace poco, ha habido una falta de automatización de herramientas de prueba para ayudar a cerrar esta brecha entre las pruebas de unidades y sistemas, los desarrolladores y los probadores. Para ayudar a la industria del software a acercarse a la pirámide de prueba ideal y evolucionar a partir del vaso de martini que vemos hoy, presentamos el Generador de pruebas de API inteligente a Parasoft SOAtest, nuestra herramienta de automatización de pruebas funcionales que es fácil de adoptar y usar.

Renunciar a la copa de martini

Smart API Test Generator es un complemento para el navegador web Google Chrome que supervisa las pruebas manuales y utiliza inteligencia artificial para crear pruebas de escenarios de API automatizadas, lo que reduce las habilidades técnicas necesarias para adoptar las pruebas de API y lo ayuda a crear una estrategia integral de pruebas de API que se adapte a todos el equipo y la organización. Funciona así:

El generador de pruebas de API inteligente monitorea el tráfico en segundo plano mientras ejecuta pruebas manuales y lo envía a su motor de inteligencia artificial, que identifica las llamadas de API, descubre patrones, analiza las relaciones entre las llamadas de API y genera automáticamente escenarios de prueba de API completos y significativos. no solo una serie de pasos de prueba de API.

Hacer que las pruebas de API sean más accesibles

Smart API Test Generator hace que las pruebas de API sean más accesibles para los equipos de prueba porque estos escenarios de prueba de API se crean utilizando prácticas de prueba que ya están haciendo. Y a diferencia de las pruebas de IU manuales o incluso automatizadas, la actividad de la API registrada ayuda a los evaluadores a colaborar mejor con los desarrolladores, con un único artefacto que ambos equipos pueden compartir y comprender fácilmente, y es mejor para diagnosticar la causa raíz de los defectos que una prueba de IU compleja. que requiere el montaje de toda la aplicación.

Por otro lado, con solo pruebas de IU, los desarrolladores y evaluadores tienden a permanecer aislados en sus técnicas de comunicación y depuración, lo que a menudo conduce a largos tiempos de espera e iteraciones entre la introducción de defectos, la detección de defectos y la resolución de defectos.

El poder de los escenarios de prueba de API

Las interacciones de API registradas durante las pruebas de IU requieren algún tipo de organización en escenarios o casos de uso. La inteligencia artificial de SOAtest Smart API Test Generator ayuda a crear escenarios basados ​​en las relaciones entre las diferentes llamadas a la API.

Sin el Smart API Test Generator, que aprovecha, los usuarios tendrían que dedicar tiempo a investigar sus casos de prueba, buscar patrones y construir manualmente las relaciones para formar cada escenario de prueba. Además, Parasoft SOAtest proporciona un método intuitivo impulsado por la interfaz de usuario para describir afirmaciones, lo que permite a los evaluadores realizar una lógica de afirmación compleja sin tener que escribir ningún código. Sin esto, los usuarios codifican cada afirmación a mano y pueden pasar por alto una o construirla incorrectamente. Estas pruebas de API se pueden ampliar utilizando herramientas visuales y lógica asistida por herramientas para crear conjuntos de pruebas a mayor escala.

Conclusión

Aunque los equipos de software reconocen el deseo de alcanzar una distribución ideal de pruebas unitarias, API y UI, la realidad es que su equipo promedio está haciendo un trabajo promedio de pruebas unitarias y aún confía en las últimas etapas de UI y pruebas del sistema. Las pruebas de API proporcionan un mecanismo de comunicación ideal entre desarrolladores y probadores con un alto nivel de automatización mantenible que puede extenderse a pruebas de rendimiento y seguridad.

Cambiar estas pruebas a la izquierda y ejecutarlas más temprano en el ciclo de vida del software significa detectar temprano los defectos críticos de seguridad y arquitectura, donde son más fáciles de diagnosticar y menos riesgosos de corregir. Aprovechando la automatización proporcionada por Parasoft SOAtestGenerador de pruebas de API inteligente, Las pruebas de API son más accesibles y el tiempo asociado con la creación de escenarios de prueba significativos se puede reducir significativamente.

Acelere la creación de pruebas de API con inteligencia artificial

Escrito por

Mark Lambert

Mark, vicepresidente de productos de Parasoft, es responsable de garantizar que las soluciones de Parasoft brinden un valor real a las organizaciones que las adoptan. Mark ha estado con Parasoft desde 2004, trabajando con una amplia variedad de clientes de Global 2000, desde implementaciones de tecnología específicas hasta iniciativas de mejora de procesos SDLC más amplias.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft