Cómo realizar pruebas de API

¿Qué es la API?

API (Application Programming Interface) es un conjunto de procedimientos y funciones que permiten la interacción entre dos componentes de una aplicación de software. Permite la comunicación y el intercambio de datos entre dos sistemas. Un sistema de software que implementa una API contiene funciones / subrutinas que pueden ser ejecutadas por otro sistema de software.

Fuera del modelo clásico de arquitectura de tres niveles:

  • Nivel de datos : la base de datos o el sistema de archivos desde donde se recuperan / almacenan los datos.
  • Nivel lógico : el cerebro de la aplicación, procesa los datos entre las capas, coordina la aplicación, procesa los comandos y toma decisiones lógicas.
  • Nivel de presentación : la interfaz de usuario, que traduce las tareas en algo que el usuario comprende.

El nivel lógico es la API. Aquí es donde pertenece toda la lógica de negocios. Es responsable de tomar información de las diferentes interfaces de usuario (UI), realizar cálculos y transacciones en la capa de la base de datos y luego presentar los resultados a la interfaz de usuario. En ciertos casos, el nivel lógico de la aplicación tiene más complejidad, y no es raro que múltiples tecnologías (servidor web, cola de mensajes, etc.) compongan este nivel.

Un ejemplo del mundo real : reserva un Ola Share o un grupo de Uber con una dirección de destino, sin conocer la ruta, el tráfico y las condiciones climáticas. Estas aplicaciones de uso compartido de viajes deben comunicarse con el servicio de mapas, los servicios de tráfico y meteorológicos y otras aplicaciones especializadas para guiar las reservas y su viaje perfecto. En el mundo moderno e interconectado, damos por sentado que todos estos sistemas diferentes pueden comunicarse entre sí sin problemas, en realidad, eso no sería posible sin las API.

El proveedor de API define el conjunto de operaciones, formatos de datos y protocolos que espera, y el consumidor de la API (llamado el cliente) usará esas reglas en el entendimiento de que, siempre que siga las reglas, el cliente siempre estará capaz de usar la API sin tener que preocuparse por las partes internas de la API en sí. Hay situaciones en las que la API es el producto final: una API pública. Una simple búsqueda en Internet revelará que hay miles de API públicas para cualquier cosa, desde GPS y soluciones de mapeo hasta localizar una estación de radio.

  • API de Google Maps : están diseñados principalmente para uso móvil y de escritorio con la ayuda de la interfaz flash y JavaScript.
  • API de publicidad de Amazon : Amazon es conocido por sus productos y, por lo tanto, su API de publicidad accede a su producto para descubrir su funcionalidad y, por lo tanto, anunciarse en consecuencia.
  • Twitter : la API para Twitter generalmente se divide en dos categorías, una para acceder a los datos y la otra para interactuar con la búsqueda de Twitter.
  • YouTube : esta API utilizada para YouTube incluye varias funcionalidades que incluyen videos, transmisión en vivo, reproductor, etc.

¿Qué son las pruebas de API?

En palabras simples: prueba del nivel lógico (la interfaz API) para determinar si cumple con las expectativas de funcionalidad, confiabilidad, rendimiento y seguridad.

Las pruebas de API se utilizan para determinar,

  • Funcional : las API devuelven la respuesta correcta (en el formato esperado) para una amplia gama de solicitudes factibles, es decir, la salida de la primera aplicación / base de datos es correcta y está bien estructurada y es útil para otra aplicación. La respuesta puede ser un estado Pasa / Falla, Datos o información o una llamada a otra API.
  • Carga : API puede manejar una gran cantidad de llamadas y reaccionar adecuadamente ante casos extremos como fallas y entradas inesperadas / extremas.
  • Rendimiento : entregar respuestas en un período de tiempo aceptable.
  • Seguridad : tipo de autenticación requerida, permisos, controles de acceso, si los datos confidenciales se transmiten de forma segura a través de la red y responden de manera segura a posibles ataques de seguridad.
  • Prueba de documentación de API: también llamada prueba de descubrimiento, la documentación de API guía fácilmente al usuario.

La prueba de API implica probar las API directamente (de forma aislada) y como parte de las transacciones de extremo a extremo ejercidas durante las pruebas de integración. Más allá de las API RESTful, estas transacciones incluyen múltiples tipos de puntos finales, como servicios web, ESB, bases de datos, mainframes, IU web y ERP. Las pruebas de API se realizan en las API que produce el equipo de desarrollo, así como en las API que el equipo consume dentro de su aplicación (incluidas las API de terceros). La virtualización de servicios se utiliza junto con las pruebas de API para aislar los servicios bajo prueba y expandir el acceso al entorno de prueba mediante la simulación de API / servicios que no son accesibles para la prueba.

¿Por qué pruebas de API?

Las API ahora sirven como la interfaz principal para la lógica de la aplicación. Los equipos ágiles y DevOps que trabajan con iteraciones cortas y bucles de retroalimentación rápidos encuentran que las pruebas de GUI requieren un trabajo considerable para mantenerse al día con los cambios frecuentes. Las pruebas en la capa API son menos frágiles y más fáciles de mantener. Es por eso que vemos que ‘Pruebas de API’ está ganando impulso como una de las descripciones de trabajo hoy en día.

El tipo de API

A lo largo de los años, las API han evolucionado desde simples bibliotecas de códigos que las aplicaciones podrían usar para ejecutar código en la misma computadora, hasta API remotas que pueden usarse para permitir que el código en una computadora llame al código alojado en otro lugar. Aquí hay una lista rápida de las tecnologías API más comunes que existen en orden cronológico aproximado:

  • TCP / IP Sockets
  • Llamada a procedimiento remoto (RPC)
  • Arquitectura de agente de solicitud de objeto común (CORBA)
  • Invocación de método remoto de Java (RMI) y Enterprise Java Beans (EJB)
  • Modelo de objetos componentes distribuidos de Microsoft (DCOM), también conocido como ActiveX
  • Servicios web (SOAP luego REST)

Los servicios web SOAP utilizan el lenguaje de definición de servicios web (WSDL) y se comunican mediante solicitudes HTTP POST. Son esencialmente una serialización de llamadas a objetos RPC en XML que luego se pueden pasar al servicio web. El XML pasado a los servicios web SOAP debe coincidir con el formato especificado en el WSDL.

Una API web RESTful (también llamada servicio web RESTful) es una API web implementada utilizando los principios HTTP y REST. A diferencia de los servicios web basados ​​en SOAP, no existe un estándar “oficial” para las API web RESTful. Esto se debe a que REST es un estilo arquitectónico, a diferencia de SOAP, que es un protocolo. Por lo general, los servicios web REST exponen sus operaciones como una serie de “recursos” únicos que corresponden a una URL específica. Cada uno de los métodos HTTP estándar (POST, GET, PUT y DELETE) luego se asigna a las cuatro operaciones básicas CRUD (Crear, Leer, Actualizar y Eliminar) en cada recurso. Los servicios web REST pueden usar diferentes métodos de serialización de datos (XML, JSON, RSS, etc.).

¿Cómo realizar pruebas de API?

Como las API carecen de una GUI, las pruebas de API se realizan en la capa de mensajes. Las pruebas de API comúnmente incluyen pruebas de API REST o servicios web SOAP con cargas de mensajes JSON o XML que se envían a través de HTTP, HTTPS, JMS y MQ. También puede incluir formatos de mensajes como SWIFT, FIX, EDI y formatos similares de longitud fija, CSV, ISO 8583 y Protocol Buffers que se envían a través de transportes / protocolos como TCP / IP, ISO 8583, MQTT, FIX, RMI, SMTP, TIBCO Rendezvous, y FIX.

Las pruebas de API son diferentes a otros tipos de pruebas, ya que la GUI no está disponible y, sin embargo, debe configurar el entorno inicial que invoca la API con el conjunto de parámetros necesarios y luego finalmente examina el resultado de la prueba. En lugar de usar entradas y salidas de usuario estándar (teclado), en las pruebas de API, usamos software para enviar llamadas a la API, obtener salidas y anotar la respuesta del sistema. API Testing requiere una aplicación para interactuar con API. Para probar una API, necesitamos usar una herramienta de prueba para conducir la API.

  • Documente los requisitos de prueba de API : ¿Cuál es el propósito de API? ¿Cuál es el flujo de trabajo de la aplicación? ¿Cuáles son las integraciones compatibles con la API? ¿Cuáles son las características y funciones de la API? Documentar todos estos requisitos de prueba de API es lo primero que necesitamos implementar. Esto nos ayudará a planificar las pruebas de API durante todo el proceso de prueba.
  • Entorno de prueba : la configuración del entorno de prueba implica la configuración de la base de datos y el servidor para los requisitos de la aplicación. Una vez configurado, es bueno hacer una llamada a la API de inmediato para asegurarse de que nada se rompa antes de continuar para comenzar pruebas más exhaustivas.
  • Funcional : el objetivo principal de las pruebas de API es garantizar la lógica y la funcionalidad de los componentes de API con respecto al paquete de software en su conjunto. Con eso en mente, se debe hacer una cantidad significativa del esfuerzo de prueba para señalar los defectos funcionales que probablemente causarán problemas en la producción, y también proporcionará a todo el equipo medidas de referencia sobre cómo funciona la API en condiciones regulares.
  • Pruebas negativas : las pruebas exhaustivas de API también deben incluir pruebas de límites suficientes y pruebas de estrés más altas para ver cómo reacciona la API a condiciones no ideales. Las suites de prueba deberían incluir idealmente al menos algunos casos inusuales, como caracteres no ASCII, tipos de datos incorrectos o un número muy grande. Otra área que no debe pasarse por alto es la prueba de errores, ya que es vital que la API en la prueba no se rompa o bloquee en respuesta a datos de entrada mal formados.
  • Datos enmascarados : comience a combinar los datos de la aplicación con las pruebas de la API para garantizar que la API funcione como se espera frente a las posibles configuraciones de entrada conocidas.

Herramientas de prueba de API

Dado que API Testing está ganando popularidad, tenemos muchas herramientas disponibles para lo mismo. Por cierto, Selenium es solo para pruebas basadas en el navegador, como resultado tenemos diferentes herramientas para usar para las pruebas API / basadas en el servicio web Rest and Soap. Estas son algunas de las principales herramientas de prueba de API que se pueden usar para las pruebas de servicio web de descanso y jabón.

  • SOAPUI : la herramienta de código abierto más popular para pruebas API en el mundo, SoapUI le permite probar las API REST y SOAP con facilidad, ya que se ha creado específicamente para pruebas API. Puede automatizar las pruebas funcionales, de regresión, de cumplimiento y de carga de los servicios web SOAP y REST. Viene con una interfaz gráfica fácil de usar y admite tecnologías y estándares líderes en la industria para burlarse y estimular el comportamiento de los servicios web.
  • Cartero : envíe una solicitud de publicación a su servidor web y obtenga la respuesta. Ejecutar en aplicaciones Mac, Windows, Linux y Chrome, le permite configurar todos los encabezados y cookies que su API espera, y luego verificar la respuesta. Úselo tanto para pruebas automatizadas como exploratorias. Integraciones incorporadas como soporte para formatos Swagger y RAML, es compatible con Run, Test, Document y Monitoring.
  • Tricentis Tosca : admite una amplia gama de protocolos, incluidos HTTP (s) JMS, AMQP, Rabbit MQ, TIBCO EMS, SOAP, REST, IBM MQ, NET TCP. Utiliza la automatización de pruebas basada en modelos que facilita el mantenimiento de scripts. Permite pruebas de extremo a extremo, ya que las pruebas de API se pueden usar en dispositivos móviles, entre navegadores, aplicaciones empaquetadas, etc.
  • HttpMaster : una herramienta de desarrollo y prueba web para automatizar las pruebas de sitios web y servicios: servicios web RESTful y aplicaciones API. HttpMaster también le permite monitorear las respuestas de la API.
  • Rest-Assured : lenguaje de código abierto específico de dominio de Java (DSL) que simplifica la prueba del servicio REST. Simplifica las cosas al eliminar la necesidad de usar código de placa de caldera para probar y validar respuestas complejas. También es compatible con XML / JSON Request / Responses.
  • Parasoft : herramienta de pago, automatice las pruebas de API con Parasoft utilizando su soporte para múltiples plataformas como Java, C, C ++, http://or.NET. Admite pruebas de extremo a extremo y tiene una interfaz muy fácil de usar.
  • vRest : proporciona una solución en línea para pruebas automáticas, simulacros, grabación automatizada y especificación de API REST / HTTP / API RESTful. Esta herramienta se puede utilizar para probar aplicaciones alojadas localmente, intranet o Internet. Algunas de sus buenas características incluyen el apoyo a la integración de Jira y Jenkins y también permite las importaciones de Swagger y Postman. Los simulacros de API se pueden crear en vREST con la ayuda de Mock Server Functionality. El usuario puede comenzar directamente a desarrollar frontend utilizando solicitudes HTTP simuladas
  • Apache JMeter : admite pruebas de rendimiento para servicios web (SOAP / REST).
  • HP QTP / UFT : proporciona un marco extensible útil para ejecutar y desarrollar la funcionalidad del sistema sin cabeza que no tiene una interfaz de usuario. Ayuda a probar las tecnologías sin cabeza como bases de datos y servicios web, JMS, etc.
  • Rapise : una herramienta de automatización robusta con características potentes y extensibles. Se basa en una arquitectura abierta y flexible para pruebas funcionales rápidas de servicios web REST / SOAP. Utiliza métodos estándar HTTP como POST, GET, PUT y DELETE. Rapise también proporciona soporte para probar aplicaciones web creadas en Java, .NET, Ajax, Silverlight y Flash.
  • WebInject : herramienta gratuita para pruebas automáticas funcionales, de aceptación y regresión de servicios web y web. Es una herramienta de línea de comandos y se basa en Perl, lo que simplifica la ejecución de las pruebas, ya que no requiere pasar tiempo en el símbolo del sistema. Además, no tiene IDE como la interfaz de usuario, lo que significa que las pruebas se escriben fuera de la interfaz de usuario de WebInject. Se puede ejecutar en plataformas que tienen intérprete Perl.
  • Herramienta SDK de Eclipse para pruebas de API automatizadas.

Hay muchas otras herramientas de API Testing disponibles en el mercado de control de calidad. Al mirar una herramienta de prueba de API, es importante comprender qué tecnologías de API usará y la mejor manera de probarlas. Hoy en día, la mayoría de las API que encontrará serán de la variedad de servicios web (REST o SOAP), pero puede encontrar otras tecnologías como Java EJB o Microsoft DCOM / ActiveX DLL.

Desafíos de las pruebas API

  • No hay una GUI disponible para probar la aplicación, lo que dificulta proporcionar valores de entrada: combinación de parámetros, selección de parámetros, categorización y secuencia de llamadas.
  • Se requiere un conocimiento profundo de las aplicaciones internas para probar suficientemente la API. Algunas API pueden interactuar con el núcleo del sistema operativo, otras API, con otro software para ofrecer su funcionalidad.
  • Habilidades de programación adecuadas : las pruebas de API generalmente tienen la forma de secuencias de llamadas, a saber, programas. Cada probador debe poseer experiencia en los lenguajes de programación a los que apunta la API.
  • Sin documentación : las API desarrolladas difícilmente tendrán disponible la documentación adecuada. Sin la documentación, es difícil para el diseñador de pruebas comprender el propósito de las llamadas, los tipos de parámetros y los posibles valores válidos / no válidos, sus valores de retorno, las llamadas que realiza a otras funciones y los escenarios de uso.
  • Por lo general, los gerentes de proyecto no se preocupan por asignar tiempo específicamente para desarrollar una API rica y detallada, y mucho menos probarla.
  • Limitaciones de tiempo : las pruebas exhaustivas de las API requieren mucho tiempo, requieren una sobrecarga de aprendizaje y recursos para desarrollar herramientas y diseñar pruebas.
  • El manejo de excepciones debe ser probado a fondo.

Algunas mejores prácticas para pruebas de API

  • En primer lugar, pruebe la funcionalidad: la solicitud-respuesta básica funciona de manera constante.
  • Agrupar casos de prueba por categoría de prueba.
  • Para una cobertura de prueba completa, cree casos de prueba para todas las combinaciones posibles de entrada de API.
  • Pruebe la falla y los parámetros no válidos de cómo maneja problemas y cargas imprevistos asegurándose de que la API falle correctamente.
  • Agregue estrés al sistema a través de una serie de pruebas de carga API.
  • La selección de parámetros debe mencionarse explícitamente en el caso de prueba en sí.
  • Priorice las llamadas a la función API para que sea fácil para los evaluadores realizar pruebas de manera oportuna.
  • Automatice la creación de documentación de API con un estándar como Swagger, pero luego ejecute las pruebas, asegurándose de que la documentación tenga sentido para todos los niveles de experiencia del usuario.
  • Automatiza todo lo que puedas.

Si alguna API no funciona de manera eficiente y efectiva, nunca se adoptará, independientemente de si es una API abierta y gratuita. Si una API se rompe, no solo podría romper una sola aplicación, sino que también dependería de una cadena de procesos comerciales. Poner más esfuerzo en las pruebas de API conduce a un producto final mucho más saludable. Garantizar que todo el acceso a los datos (lectura y escritura) pase solo a través de la API simplifica significativamente las pruebas de seguridad y cumplimiento y, por lo tanto, la certificación, ya que solo hay una interfaz. Asegurarse de que la API ofrece una funcionalidad completa permite una fácil expansión futura de la aplicación a medida que surgen nuevas necesidades comerciales.

Las pruebas de API son bastante cruciales y son muy necesarias. Es una de las áreas donde las pruebas de automatización son muy recomendables, particularmente en el mundo de DevOps, desarrollo ágil y ciclos de entrega continuos. La forma en que nuestra generación se está moviendo hacia la Inteligencia Artificial, la computación en la nube y el IoT , pronto habrá una mayor demanda de pruebas rigurosas de API. Muchos de los servicios que utilizamos todos los días se basan en cientos de API interconectadas diferentes, si alguno de ellos falla, entonces el servicio no funcionará. La prueba de API es una necesidad. Si eres un probador de software, las pruebas de API son una habilidad imprescindible que debes tener en tu arsenal.

Related Content

¿Cuál es la principal diferencia entre el modelo incremental y el modelo RAD en las pruebas de software?

¿Cómo un usuario nuevo de Mac personaliza un Macbook Pro para aprovecharlo al máximo?

¿Qué es una arquitectura de microservicios y cuáles son sus buenos usos?

¿Cuáles son los problemas con las API actuales en este momento?

¿Puedo hacer la transición al campo de la gestión de productos en software después de 2 años de experiencia en el desarrollo de productos de software y un MBA?

Pruebas continuas. En todas las aplicaciones web de las que he formado parte, ha habido un tema común de prueba: comprobar manualmente que todo funciona después de la implementación. Las pruebas continuas resuelven esto, y es la mejor manera de ejecutar pruebas automatizadas en el momento más importante de la vida de su API, después de impulsar nuevos cambios.

Recientemente comencé Assertible, un servicio de pruebas continuas para API y sitios web. (También tenemos una nueva integración de comprobaciones de estado y despliegues de GitHub).

La prueba continua significa ejecutar sus pruebas (en este caso, solicitudes HTTP reales en un entorno de preparación / producción) cada vez que inserta un nuevo código. Digamos, por ejemplo, que tiene un punto final de API `/ users`; usted afirmaría que siempre devuelve un código de estado 200.

En una configuración básica: comenzará a ejecutar sus solicitudes después de que se haya implementado una nueva versión de su aplicación. Para algunos equipos esto es varias veces al día, para otros es una o dos veces por semana. La parte importante de esto es que ejecuta las mismas pruebas en entornos de producción y preparación.

Este método de prueba es altamente efectivo por algunas razones:

  • Las pruebas automatizadas pueden cubrir mucho más terreno que cualquier desarrollador individual.
  • Las pruebas continuas explican el hecho de que las cosas se pierden. Es crucial probar sus aplicaciones en la organización y producción.
  • En equipos grandes, es imposible que un desarrollador determinado (o probador de control de calidad) sepa cómo funciona alguna otra parte de la aplicación. Las pruebas continuas aseguran que todos los puntos finales se prueben antes de fusionar los cambios.

Si está trabajando con repositorios de GitHub, así es como se verían las comprobaciones de estado:

TestingExcellence también tiene una buena lista de razones por las cuales las pruebas continuas deberían ser parte de cada ciclo de desarrollo: Mejores prácticas para pruebas continuas en Agile: excelencia en las pruebas

Rutwick Gangurde

La API (interfaz de programación de aplicaciones) permite la comunicación y el intercambio de datos entre dos sistemas de software separados. Es donde se prueba la funcionalidad de extremo a extremo y los probadores no pueden acceder al código fuente. (Fuente – Guru99)

Es importante ya que ayuda a garantizar la funcionalidad, el rendimiento y la confiabilidad sin problemas de diferentes aplicaciones y sistemas basados ​​en datos mediante comunicaciones entre aplicaciones, sistemas, bases de datos y redes.

La prueba API debe cubrir los siguientes métodos de prueba:

  • Prueba de descubrimiento
    El grupo de prueba debe ejecutar manualmente el conjunto de llamadas documentadas en API
  • Pruebas Usablitiy Verifica si la API es funcional y fácil de usar y si se integra con otra plataforma
  • Pruebas de seguridad

Incluye tipo de autenticación y cifrado de datos confidenciales.

  • Pruebas automatizadas Debería crear la creación de scripts o herramientas establecidas que se pueden utilizar para ejecutar regularmente

Herramientas para realizar pruebas de API

  • IU de jabón Es la herramienta más popular para pruebas de API en el mundo. Permite probar las API REST y SOAP. Existe una funcionalidad de apuntar y hacer clic, arrastrar y soltar que se simplifica.
  • Cartero Es un complemento en Google Chrome, donde se pueden extraer todos los datos modernos de API web. Puede haber una colección de llamadas REST y guardar cada llamada como parte de una ejecución. Para transmitir y recibir la información REST, cartero es uno de los más confiables.

Aparte de estos, hay otras herramientas múltiples disponibles en el mercado como Fiddler, Rest, HttpMaster Express, Karate DSL.

Consulte este seminario web, ‘El futuro de las pruebas API: tendencias y cómo impulsar sus pruebas’, que se llevará a cabo el martes 27 de marzo de 2018 a las 11:30 a.m. PST.

Para registrarse gratis, haga clic aquí: El futuro es la prueba de API – Seminario web gratuito

Rutwick Gangurde

Esta pregunta del trazador de líneas tiene una respuesta masiva, pero la mantendré breve y simple.

Antes de realizar las pruebas de API, debe comprender algunos tipos comunes de pruebas de API que se realizan

Pruebas de funcionalidad: para verificar si la API funciona

Pruebas de usabilidad : para comprobar lo fácil que es trabajar con la API

Pruebas de confiabilidad : la API se puede conectar de manera consistente y generar resultados consistentes.

Prueba de carga : la API puede manejar una gran cantidad de solicitudes.

Pruebas de seguridad : la API ha definido requisitos de seguridad que incluyen autenticación, permisos y controles de acceso. Consulte algunos consejos de seguridad de API para proteger datos vitales.

Después de elegir qué pruebas necesita realizar, debe comprender los casos de prueba básicos. He mencionado algunos de los casos de prueba básicos.

Comprobación de los valores de retorno de la API en función de la condición de entrada.

Verificar si la API no devuelve nada o los resultados son incorrectos.

Verificar si la API activa algún otro evento o llama a otra API.

Verificar si la API está actualizando alguna estructura de datos.

Después de esto, decide si desea probarlo manualmente o si desea realizar pruebas de automatización

Pruebas manuales: puede usar algo como cartero (extensión de Chrome para pruebas de funcionalidad API)

Pruebas de automatización : aquí es donde deberá escribir scripts de back-end para realizar pruebas funcionales

Nota: hay muchas formas de pruebas de API y existen diferentes herramientas para diferentes tipos de pruebas, decidir que la automatización o las pruebas manuales de hoy dependen de la frecuencia de los cambios en el código y la arquitectura del producto.

Espero que responda tu consulta.

Ram Chennale

La prueba de API es una forma de prueba de caja negra; es decir, interactuar con una función sin saber lo que sucede dentro.

Excepto que, dado que la API (interfaz del programa de aplicación) no es una interfaz de usuario, los evaluadores deben usar herramientas especializadas o escribir algunos fragmentos de código. Las respuestas en este hilo proporcionan muchos ejemplos de las herramientas y el código, por lo que en mi respuesta me concentro en los riesgos y el diseño de las pruebas.

Los riesgos son preguntas que debemos aclarar. Suelen tratarse de algo no deseado o que tiene un impacto negativo. Un impacto negativo es un resultado directo o indirecto de algunos cambios en el código, o problemas de compilación y promoción.

El diseño de la prueba se trata de cumplir con las preguntas. Diseñamos y simulamos varias interacciones con una API para explorar e investigar su comportamiento.

Si organizamos nuestras preguntas de prueba de básicas a profundas, terminamos con algo como las siguientes categorías.

Cobertura básica

  • Comprobando si una función API particular (o algunas de ellas) podría estar inactiva

Cobertura superficial pero amplia

  • Comprobar si una secuencia de llamadas a la API destinadas a funcionar en un escenario podría no estar disponible o comportarse de manera incorrecta
  • Comprobar si las llamadas típicas (“ruta feliz” – datos válidos, respuesta genérica) producen una respuesta no válida o son incorrectas en algunos aspectos.

Cobertura enfocada y profunda

  • Entrada: cubre todas las variaciones de entrada de datos
  • Todas las clases de equivalencia de entrada válida
  • Entrada no válida (fuera de los límites, formato no válido, faltante, etc.)
  • Salida: reproduce todas las variaciones de salida
    • Todos los códigos de respuesta previstos
    • Verificar la corrección de la salida
    • Comprobar formato de salida
    • Reproduzca casos especiales (ninguno, uno, máximo)
  • Estado: si la llamada a la API produce un cambio de estado del sistema
    • Reproduzca todas las consecuencias previstas e investigue si hay consecuencias no intencionadas.
  • Flujo: simule variaciones de flujo y volumen
    • Tiempos de espera e interrupciones
    • Rechazos y retrocesos
    • Entrada y salida de datos de alto volumen.
    • Alto rendimiento continuo

    La lista de arriba puede parecer aterradora. Eso es porque di un ejemplo muy amplio con el objetivo de muchos tipos de riesgos. En la práctica, su nivel de cobertura es limitado y debe ser guiado.

    Es aconsejable probar cosas más importantes antes y dedicar más tiempo a los aspectos más importantes de un producto. Eso requiere tener un modelo estructurado de un producto. Y por tener riesgos y prioridades identificados y monitoreados. Esta es una pregunta de gestión de prueba.

    ¡Gracias por leer!

    • Si te gustó esta respuesta, vota y sígueme
    • Si lo encuentra útil, por favor comparta con otros
    • ¿No estás de acuerdo o no te gustó? ¡Dispárame un comentario! Estoy seguro de que hay un margen de mejora.
    Christopher Reichert

    Tenemos herramientas para realizar pruebas API manualmente, como

    • soapui
    • cartero,
    • Newman y
    • jmeter.

    Las herramientas anteriores se utilizan tanto para manual como para automatización. Jmeter será útil para las pruebas de rendimiento de la API.

    Si no desea usar ninguna herramienta y es bueno en la programación, Apache http para Java y la biblioteca de solicitudes para Python serán útiles para probar las API.

    Apeksha Pawar

    Hay varias herramientas diferentes disponibles en el mercado para las pruebas de API que elegimos en función de nuestros requisitos y tipo de API.

    Primero veamos qué es API: significa interfaz de programación de aplicaciones que tiene un conjunto de funciones que permite construir una aplicación mediante la cual también podemos acceder a los datos de la aplicación y otros datos de servicios.

    En general, podemos decir que es como un medio que ayuda a transportar los datos hacia y desde la web a la aplicación y viceversa.

    Tenemos dos tipos de API que elegimos según nuestros requisitos

    1. API RESTfull.

    2. API SOAP.

    Para ambos tenemos diferentes herramientas como

    1. POSTMAN: Complemento de Chrome: se utiliza para probar la API RESTfull y, para más detalles, Postman Interceptor

    2. SOAP UI: código abierto – Se utiliza para probar la API SOAP y para más detalles SoapUI | Pruebas funcionales para API SOAP y REST

    Cody Reichert

    Las pruebas de API se pueden hacer de dos maneras: –

    1. Prueba de API manualmente (utilizando POSTMAN o RESTful Web Services)
    2. Prueba de API utilizando Automatización
    1. Automatización de API con Google GSON
    2. Automatización de API utilizando REST Assured
    Keshav Kashyap

    Hola amigo

    Visite mi blog. Definitivamente lo ayudará a comenzar las pruebas de API.

    Enfoque manual API

    ¿Cómo probar manualmente las API REST?

    Enfoque de automatización de API

    ¿Cómo automatizar los casos de prueba de API de descanso?

    Mahesh Kanniah

    Según mi experiencia, realmente depende de cuál se adapta mejor según el proyecto. Hay varias formas de hacer pruebas de API:

    1. Usando Postman o cualquier complemento del navegador
    2. Usando Selenium, pocas personas hacen pruebas de API
    3. Usar marcos estables como RestAssured, etc.
    4. Al escribir código en Java / C # / PHP / Python
    5. A mano

    Avísame si me perdí alguna

    Keshav Kashyap

    La prueba de API no es muy diferente de cualquier prueba de aplicación web, ya que utiliza el protocolo HTTP como transporte subyacente, por lo que básicamente necesita simular solicitudes y verificar las respuestas para verificar su integridad y coherencia. Hay una variedad de herramientas diseñadas para pruebas de API, la más popular es SoapUI | Pruebas funcionales para API SOAP y REST

    Otros son: Cartero, RESTClient, un depurador de servicios web RESTful, y si planea realizar algunas Pruebas de carga en su API, también puede considerar Apache Jmeter; consulte Prueba de servicios web SOAP / REST con JMeter para obtener más información.

    Christopher Reichert

    Puede escribir pruebas usando código, o usar herramientas como API Fortress, SoapUI, Runscope o Postman. Básicamente, estas herramientas llaman a la API y luego validan la respuesta.

    Este video muestra cómo hacerlo usando API Fortress, pero también hay muchas otras opciones.

    ¡Espero que esto ayude!

    Aniruddha Patil

    Secreto : hay algo llamado documentación de la API.
    Sugerencia: el enlace a la documentación está mayormente oculto en la misma página donde encontró la API.

    La mayoría de las API tienen una demostración funcional o un código listo para hola mundo que le mostrará cómo funcionan las cosas. Es posible que deba ingresar su autenticación y ponerla en funcionamiento.

    Ejemplo: freegeoip.net
    freegeoip.net/{format}/{IP_or_hostname}

    El propósito de esta IP es darle información sobre una dirección IP.
    La información que envía a esta API es a) la dirección IP b) el formato en el que desea obtener el resultado (xml / json / coma separado)

    Si observa en su sitio, la API viene con ciertas restricciones. Se llama estrangulamiento.

    Entonces
    a) la API aceptará algo (por ejemplo, direcciones IP)
    b) api devolverá algo (Ej. json feed)
    c) la API tendrá límites (Ej. 10,000 consultas por día)
    d) la API puede tener autenticación (por ejemplo, una cadena de token)

    Keshav Kashyap

    He usado Swagger en muchos de mis proyectos para documentación y pruebas de API.
    Ventajas:
    1. La interfaz de usuario es bastante fácil de entender.
    2. Tiene una estructura de entrada de muestra frente a usted para probar.
    3. La documentación de API ayuda a comprender su funcionalidad.
    4. Fácil de configurar
    Demostración en vivo: Swagger UI

    Ram Chennale

    Si desea obtener más información sobre las pruebas API, Smartbear Software tiene muchos libros electrónicos y seminarios web gratuitos sobre el tema.

    ¡Listo! Recursos API | Software SmartBear

    Rutwick Gangurde

    Una API es más que solo el código con el que la implementa; La documentación de la API es igualmente importante. ¿Pueden los desarrolladores entender su API? Es posible que quieran usarlo de formas que no anticipó. Considere patrocinar un hackathon con un premio por el uso más innovador de su API. Luego observe cómo los desarrolladores pueden usar su API.

    Christopher Reichert

    Para probar sus API utilizo las pruebas funcionales / de integración. Estos le permiten probar toda la arquitectura con una llamada API (no solo el método / función).

    Algunos lenguajes y marcos tienen bibliotecas para realizar pruebas de integración y, si tiene uno, le sugiero que lo use.

    Las pruebas unitarias en API no tienen ningún valor (en mi humilde opinión), pero las pruebas de integración son invaluables y deben hacerse al menos para probar la viabilidad del sistema como mínimo.

    Apeksha Pawar

    Es posible que le interese un seminario web sobre las pruebas de API, que se realizará en septiembre: “Acelere su automatización con las pruebas de API”. Servicios de pruebas de API

    Cody Reichert

    Depende de qué API sea. Las API gratuitas se pueden probar directamente visitando las URL en el navegador. Algunos requieren que se registre para obtener una clave y envíe la clave junto con las solicitudes. Es posible que deba escribir un código para hacerlo. Los famosos tienen envoltorios escritos a su alrededor que facilitan su trabajo.

    Mahesh Kanniah

    Existen diferentes herramientas que puede usar para las pruebas de API:

    1. Jmeter
    2. Cartero
    Rutwick Gangurde

    More Interesting

    ¿Cómo está su organización actualmente haciendo un seguimiento de sus políticas y procedimientos? ¿Cuáles son sus principales problemas con su sistema actual?

    Trabajo con muchos lenguajes de programación todos los días. ¿Leer un montón de código y ajustarlo para mis propósitos sería un método de aprendizaje efectivo?

    ¿Cómo entrar en el desarrollo de software de las pruebas? ¿Puede sugerir qué habilidades se necesitan en función de la tendencia actual en la industria de TI?

    Me mudo a Cork, Irlanda, para trabajar como ingeniero de software. ¿Cómo puedo persuadir MS y más tarde doctorado en informática?

    ¿Cuáles son los diferentes modelos de desarrollo de software?

    ¿A qué estudios avanzaría después de B.Sc en ingeniería de software?

    ¿Se puede evitar quedar atrapado con software sin licencia usando Linux?

    ¿Todas las herramientas de software finalmente se basarán en la nube y se utilizarán a través de un navegador?

    ¿Qué hace PricewaterhouseCoopers?

    ¿Qué especialidad tiene la mayor demanda de trabajo, CS o ingeniería de software? ¿Cuál crees que tendrá la mayor demanda en 2020?

    ¿Cuáles son algunas formas en que un ingeniero de software puede ofrecer voluntariamente su trabajo calificado?

    ¿Es un buen salario de $ 110ka en el área de la bahía de SF para un nuevo graduado de MS con dos años de experiencia laboral como ingeniero de software?

    Dado que JavaScript no está particularmente orientado a objetos, ¿existe otro paradigma de desarrollo de software que pueda usarse para crear JavaScript organizado y mantenible?

    ¿Es una mala práctica usar las declaraciones 'continuar' o 'siguiente' al programar?

    Entre una ingeniería y desarrollo de integración de software, ¿cuál debo elegir en una empresa de software empresarial?