Contenido

• ¿Qué es una API?
  
  • API - conjunto de características
  • ¿Cómo se compila el conjunto de características?
  • ¿Qué significa la palabra "interfaz"
• Cómo se llama la API
  
  • Llamada API directamente
  • Llamada indirecta a la API
• ¿Qué significa API Testing?
• Resumen

La palabra "API" parpadea en las vacantes, incluso para los evaluadores principiantes. O REST API, luego SOAP API, luego solo una API. ¿Qué tipo de animal es este? ¡Vamos a resolverlo!

"¿Por qué necesito esto?" En realidad estoy probando la web! Ahora, si entro en la automatización, entonces sí ... Bueno, también lo están probando en la empresa, escuché ...

Y no! Es bueno que cualquier probador sepa sobre la API. Porque en él los sistemas interactúan entre sí. Y ves esta interacción todos los días, incluso en los sitios más simples y cutres.

Cualquier pago pasa por la API del sistema de pago. ¿Compró un boleto de cine? ¿Una camiseta en una tienda en línea? Un libro? Tan pronto como haga clic en "pagar", el sitio lo conecta con el sistema de pago.

Pero incluso si no tiene integración con otros sistemas, ¡todavía tiene una API! Porque el sistema dentro de sí mismo también se comunica a través de la API. Y mientras el desarrollador frontal está cortando mucho la GUI (interfaz gráfica), puede:

• aburrirse mientras espera;
• comprobar la lógica de trabajo de la API

¡Por supuesto, estoy para la segunda opción! Entonces, comprendamos qué es la API. Puede ver el video en youtube o leerlo como un artículo.

¿Qué es una API?

API (interfaz de programación de aplicaciones) es un contrato que proporciona un programa. "Puedo ser contactado de esta manera y otra, me comprometo a hacer esto y aquello".

Si se traduce al ruso, sería la palabra "contrato". Un acuerdo entre dos partes, como un acuerdo para comprar un automóvil:

• mis responsabilidades son hacer tal cantidad
• El deber del vendedor es entregar el automóvil.

Puedes traducir, sí. Pero nadie hace eso ¯ \ _ (ツ) _ / ¯

Todos usan la palabra "contrato". Tan aceptado Además, esta palabra se incluye en el nombre del estilo de desarrollo:

• Primero el código: primero escribimos el código y luego generamos un contrato.
• Contrato primero: primero creamos un contrato, luego escribimos o generamos código en él (en este artículo hablaré sobre este estilo)

¿No decimos "un contrato para la venta de un automóvil"? Entonces los desarrolladores no dicen "contrato". Acuerdo tácito.

API - conjunto de características

Cuando compra un automóvil, elabora un contrato en el que prescribe todos los puntos que son importantes para usted. Del mismo modo, los contratos deben redactarse entre programas. Indican cómo se puede acceder a uno u otro programa.

En consecuencia, la API responde a la pregunta "¿Cómo puedo contactar mi sistema?", E incluye:

• la operación en sí misma que podemos realizar
• datos de entrada
• datos de salida (contenido de datos o mensaje de error).

Aquí puedes decirme:

- Hmm, espera. La operación, los datos de entrada, los datos de salida, de alguna manera, ¡todo esto se parece mucho a una descripción de función!

Si alguna vez se ha encontrado con el desarrollo o acaba de aprender un lenguaje de programación, probablemente sepa qué es una función. De hecho, tenemos datos de entrada, hay datos de salida y algo de magia que convierte uno en otro.

Y si! Tendrá razón en que las definiciones son similares. Por qué Sí, porque la API es un conjunto de funciones. Esta puede ser una función, o puede ser muchas.

¿Cómo se compila el conjunto de características?

Si, no importa como. Como el desarrollador quiera, se agrupará. Por ejemplo, puede agrupar la API por funcionalidad. Eso es:

• API separada para ingresar al sistema, donde estará el registro y la autorización;
• API separada para informes: informe 1, informe 2, informe 3 ... informe N. Para diferentes informes tenemos diferentes fórmulas = diferentes funciones. Y todos los recopilamos en un conjunto, api para informar.
• API de sistema de pago independiente: hay una función para trabajar con cada banco.
• ...

No puedes agrupar en absoluto, pero crea una API común.

Se puede hacer una API común, y el resto se puede hacer a pedido. Si tiene un producto en caja, generalmente incluye un conjunto de características estándar. Y cualquier cliente de lista de deseos se hace por separado.



Resulta que en nuestro sistema hay varias API diferentes, para cada una de las cuales tenemos un contrato escrito. Cada contrato explica claramente qué operaciones se pueden realizar, qué funciones estarán allí



Y, por supuesto, las funciones pueden reutilizarse. Es decir, la misma función se puede incluir en diferentes conjuntos, en diferentes API. Nadie lo prohíbe.



Resulta que al desarrollador se le ocurre qué tipo de API tendrá. O lo general, o distribuye de acuerdo con la funcionalidad o algunos de sus propios criterios, y en cada api agrega el conjunto de funciones que necesita.

¿Qué significa la palabra "interfaz"

- ¡Espera un momento, Olya! Usted mismo escribió anteriormente que la API es una interfaz de programación de aplicaciones. ¿Por qué estás hablando del contrato, aunque existe la palabra interfaz?

Sí, porque en la programación un contrato es la interfaz. En la descripción clásica de OOP (Programación Orientada a Objetos) hay 3 ballenas:

1. Encapsulación
2. Herencia
3. Polimorfismo

La encapsulación es cuando ocultamos la implementación. Para el usuario, todo es fácil y claro. Hice clic en el botón, recibí un informe. Y cómo funciona desde adentro, no le importa. ¿Qué base de datos está oculta debajo del capó? Oráculo? MySQL? ¿En qué lenguaje de programación está escrito el programa? ¿Cómo se organiza exactamente el código? No es el punto. El programa proporciona una interfaz y la usa.

No siempre el programa proporciona una interfaz gráfica. Puede ser un SOAP, una interfaz REST u otra API. Para usar esta interfaz, debe comprender:

• que entrar
• lo que sale
• qué excepciones deben manejarse.

Los usuarios trabajan con la GUI - interfaz gráfica de usuario . Los programas funcionan con API: interfaz de programación de aplicaciones . No necesitan gráficos, solo un contrato.

Cómo se llama la API

Puede llamar a api directa o indirectamente.

Directamente:

1. El sistema llama a funciones dentro de sí mismo.
2. El sistema llama al método de otro sistema
3. El hombre llama a un método
4. Métodos de extracción de pruebas automáticas

Indirectamente:

1. El usuario trabaja con GUI

Llamada API directamente

1. El sistema llama a funciones dentro de sí mismo

Las diferentes partes del programa de alguna manera se comunican entre sí. Lo hacen a nivel de programa, es decir, a nivel de API.

Esta es la forma más fácil de usar, porque el autor de la API que se llama es el desarrollador. ¡Y él es su consumidor! Por lo tanto, no hay problemas con la documentación irrelevante =)

Es broma, siempre hay problemas con la documentación. Solo en este caso, como documentación, habrá comentarios en el código. Pero ellos, por desgracia, también son irrelevantes. O los desarrolladores son diferentes, o uno, pero ya olvidé cómo hice la API original y cómo debería funcionar ...

2. El sistema llama al método de otro sistema

Pero este es un caso típico que los probadores prueban en integradores. O probadores que prueban la integración de su sistema con el de otra persona.

Un sistema extrae api algún método de otro sistema. Puede intentar obtener datos de otro sistema. O viceversa, envíe datos a este sistema.

Supongamos que decidí conectar las indicaciones de Dadata a mi tienda en línea, para que el usuario ingrese fácilmente la dirección de entrega.

Estoy conectando sugerencias de API. Y ahora, cuando el usuario comienza a ingresar la dirección en mi sitio, ve las indicaciones de Dadata . Cómo resulta:

• Él ingresa una carta en mi sitio
• Mi sitio envía una solicitud a las indicaciones de API Dadat
• Dadata devuelve la respuesta
• Mi sitio lo procesa y muestra el resultado al usuario.

¡Hay tantos pasos! Y así para cada personaje ingresado. El usuario no ve esta interacción, pero lo es.

Y, por supuesto, no se olvide del caso cuando desarrollemos el método API. Que solo se puede llamar a través de SOAP, no se encuentra en ninguna parte de la interfaz. Lo que ordenó el cliente, lo hicimos ¯ \ _ (ツ) _ / ¯

Un ejemplo se puede encontrar en Usuarios. El método MagicSearch se basa en hechos reales. Aunque debo admitir que, en la lógica original era aún más sofisticada, lo ajusté a mi sitio.

Pero el truco aquí es que en el sistema mismo en la interfaz de usuario solo hay una búsqueda regular, solo una línea de entrada. Bueno, tal vez un par de filtros. Pero la integración necesitaba un montón de características adicionales, que se realizó a través del método SOAP.

La funcionalidad de súper búsqueda solo está disponible por API, el usuario en la interfaz no la siente.

En este caso, generalmente tiene TK, según el cual funciona el método API. Su tarea es verificarlo. Una tarea típica de un probador, solo agregue a las pruebas de diseño de prueba estándar las características de las pruebas API, ¡y todo se trata del sombrero!

(qué es exactamente lo que debe probarse en la API; lo contaré en un artículo separado un poco más adelante)

3. La persona llama al método

Los motivos son diferentes:

1. Para acelerar el trabajo
2. Para localizar el error (¿dónde está el problema? ¿En el servidor o cliente?)
3. Para probar la lógica sin giros de borde

Si el sistema proporciona una API, generalmente es más fácil tirar de ella que hacer lo mismo a través de una interfaz gráfica. Además, la llamada a la API se puede guardar en la herramienta. Una vez guardado, se aplica en cualquier base, incluso si se limpia 10 veces al día.

Para ver un ejemplo, volvemos a Usuarios . Si queremos crear un usuario, ¡necesitamos completar muchos campos!



Por supuesto, esto se puede hacer usando complementos especiales como Form Filler . Pero, ¿qué sucede si necesita datos de prueba adecuados para su sistema? ¿Y en ruso?

¡Completar los campos manualmente es triste y deprimente! Y si necesita repetir esto cada semana o día en una base de prueba limpia, generalmente es una pesadilla. Esta es inmediatamente la primera prioridad en la automatización de acciones rutinarias.

Y en este caso, el papel de la automatización realiza ... Cartero. Se puede crear un usuario a través de una solicitud REST CreateUser . Una vez registrados los datos normales "como reales", cada vez que los usamos. Beneficio!

En lugar de llenar manualmente el formulario (1 minuto de llenar los campos sin pensar con los valores "lprulpk"), obtenemos 1 segundo de presionar el botón "Enviar". En este caso, los valores serán mucho más adecuados.

Y en cartero puede hacer una carpeta separada para preparar la base de prueba, llenar una docena de solicitudes allí. ¡Y ahora en cualquier base en un par de segundos obtienes tantos datos como conducirías manualmente durante horas!

Si encuentra un error y no entiende en quién colgarlo: desarrollador front-end o back-end, elimine todo lo innecesario. Llame al método sin una interfaz gráfica. Y puede probar la lógica del programa hasta que la interfaz esté lista o rota.

4. Métodos de extracción de Autotests

Hay una pirámide de automatización típica:

• Las pruebas de GUI son una prueba honesta, "cómo lo haría el usuario".
• Pruebas API: descendemos al nivel inferior, arrojando superfluos.
• Pruebas unitarias: pruebas para una sola función

La palabra API sugiere lo que se usará en las pruebas ツ

Digamos que tenemos:

• operación : descarga de informes;
• en la entrada : datos de ajustes manuales o automáticos o de otros lugares;
• salida : un informe construido de acuerdo con ciertas reglas

Informe las reglas de construcción:

• Celda 1 : X - Y
• Celda 2 : Z * 6
• ...

Las pruebas de GUI son una prueba honesta, el robot hace todo lo que el usuario haría. Abre el navegador, presiona los botones ... Pero si algo cae, descubrirás exactamente dónde durante mucho tiempo.

Las pruebas de API son las mismas, solo sin un navegador. Simplemente enviamos datos a la entrada y verificamos los datos en la salida. Por ejemplo, puede ingresar la respuesta final en Excel y dejar que el robot la concilie, ¿se completaron correctamente los datos? Localizar el problema se vuelve más fácil.

Las pruebas unitarias son cuando probamos cada función por separado. Observamos por separado el cálculo para la celda 1, por separado para la celda 2, y así sucesivamente. Tales pruebas se persiguen más rápidamente y los errores son fáciles de localizar en ellas.

Llamada indirecta a la API

Cuando el usuario trabaja con la GUI, de hecho, también trabaja con la API. Simplemente no lo sabe, simplemente no lo necesita.

Es decir, cuando el usuario abre el sistema e intenta descargar el informe, no importa cómo funciona el sistema, qué tipo de magia hay dentro. Tiene un botón "descargar informe", en el que hace clic. El usuario trabaja a través de la GUI (interfaz gráfica de usuario).



Pero, de hecho, hay una API debajo de esta interfaz gráfica de usuario. Y cuando el usuario hace clic en el botón, el botón llama a la función de construcción del informe.



Y la función de creación de informes ya puede llamar a otras 10 funciones diferentes, si es necesario.

Y ahora el usuario ve un informe listo frente a él. ¡Llamó a la API compleja sin siquiera saberlo!

¿Qué significa API Testing?

En primer lugar, nos referimos a probar VIA API. "Prueba de API" es un término de uso común, realmente lo dicen, pero técnicamente el término es incorrecto. No probamos la API, no probamos la GUI (interfaz gráfica). Estamos probando algún tipo de funcionalidad a través de una interfaz gráfica o de software.

Pero esta es una expresión establecida. Puede usarlo y decir "Prueba de API". Y cuando hablamos de eso, queremos decir:

• Autoevaluaciones de nivel API
• o integración entre dos sistemas diferentes.

Integración: cuando un sistema se comunica con otro a través de algún tipo de protocolo de transferencia de datos. Esto se llama API remota, es decir, comunicación a través de la red, a través de algún protocolo (HTTP, JMS, etc.). En contraste con esto, también hay una API local (también conocida como "API de memoria compartida"): esta es la API mediante la cual el programa se comunica consigo mismo o se comunica con otro programa dentro de la misma memoria virtual.



Cuando hablamos de probar API, a menudo nos referimos a probar API remotas. Cuando tenemos dos sistemas ubicados en diferentes computadoras que de alguna manera se comunican entre sí.

Y si ve "Prueba de API" en la vacante, lo más probable es que esto implique la capacidad de llamar a un servicio SOAP o REST y probarlo. ¡Aunque siempre vale la pena aclararlo!

Resumen

API (interfaz de programación de aplicaciones) es un contrato que proporciona un programa. "Puedo ser contactado de esta manera y otra, me comprometo a hacer esto y aquello".

El contrato incluye:

• la operación en sí misma que podemos realizar
• datos de entrada
• datos de salida (contenido de datos o mensaje de error). ".