• Lista de titoriais de proba de API
• Visión xeral dos titoriais desta serie de probas de API
  • • (ii) Probas de carga e rendemento
  • Como introducir probas de API na túa organización
  • Desafíos comúns e formas de mitigalos
    • #1) Escoller a ferramenta correcta
    • #2) Faltan especificacións de proba
    • #3) Curva de aprendizaxe
    • #4) Conxunto de habilidades existentes
  • Estudo de caso
• Conclusión
• Titorial de probas de API
  • Probas de quendas á esquerda
  • Ciclo de vida do desenvolvemento de software (SDLC) antes da proba de Shift Left
  • Fases da proba de desprazamento á esquerda
  • API web
  • Como funciona unha API?
  • Servizos web
  • Servizos web vs. API web
• Presentación das probas da API na súa organización
  • Cambio de enfoque ás probas da API
  • Espectro completo de probas de API
    • (i) Probas funcionais

Este titorial de probas de API en profundidade explica todo sobre as probas de API, os servizos web e como introducir as probas de API na túa organización:

Obtén unha visión profunda das probas de API xunto co concepto de proba de desprazamento á esquerda e servizos web deste titorial introdutorio.

Conceptos como a API web, como funciona a API (con exemplos do mundo real) e en que se diferencia dos servizos web explícanse ben con exemplos neste titorial.

Lista de titoriais de proba de API

Tutorial #1: Titorial de probas de API: unha guía completa para principiantes

Tutorial #2: Titorial de servizos web: compoñentes, arquitectura, tipos e amp; Exemplos

Tutorial n.º 3: As 35 principais preguntas de entrevistas de ASP.Net e Web API con respostas

Tutorial n.º 4: POSTMAN Titorial: probas de API Usando POSTMAN

Tutorial #5: Probas de servizos web usando o cliente HTTP Apache

Visión xeral dos titoriais desta serie de probas de API

Tutorial #	O que aprenderás
Tutorial_#1:	Titorial de probas de API : Unha guía completa para principiantes Este titorial de probas de API en profundidade explicará todo sobre as probas de API e os servizos web en detalle e tamén che informará sobre como introducir as probas de API na túa organización.
Tutorial_#2:	Titorial de servizos web: compoñentes, arquitectura, tipos e amp; Exemplos Esta webA corrección das respostas da API para respostas válidas e non válidas é realmente crucial. Se se recibe un código de estado de 200 (que significa que todo está ben) como resposta da API de proba, pero se o texto da resposta indica que se atopou un erro, isto é un defecto. Ademais, se a mensaxe de erro aparece. é incorrecto, entón iso pode ser moi enganoso para o cliente final que está tentando integrarse con esta API. Na captura de pantalla que aparece a continuación, o usuario introduciu un peso non válido, que é superior aos 2267 kg aceptables. A API responde co código de estado de erro e a mensaxe de erro. Non obstante, a mensaxe de erro menciona incorrectamente as unidades de peso como libras en lugar de KG. Este é un defecto que pode confundir ao cliente final. (ii) Probas de carga e rendemento As API están destinadas a ser escalables por deseño. Isto, á súa vez, fai que as probas de carga e rendemento sexan imprescindibles, especialmente se se espera que o sistema que se está a deseñar atende a miles de solicitudes por minuto ou por hora, dependendo do requisito. Realizar probas de carga e rendemento de forma habitual na API pode axudar a facer unha comparativa do rendemento, as cargas máximas e o punto de ruptura. Estes datos son útiles cando planeas ampliar unha aplicación. Ter esta información dispoñible axudará a apoiar as decisións e a planificación, especialmente se a organización planea engadir máis clientes, o que significaría máis entradas.solicitudes. Como introducir probas de API na túa organización O proceso para introducir probas de API en calquera organización é similar ao proceso utilizado para implementar ou lanzar calquera outra ferramenta e marco de probas. A seguinte táboa resume os pasos principais xunto co resultado esperado de cada paso. Fase Paso Resultado esperado Selección de ferramentas Reúna requisitos e identifique restricións Comprende os requisitos para investigar mercado para a ferramenta de proba de API axeitada. Por exemplo, Que tipo de API se está a probar: SOAP ou REST? Necesitamos contratar probadores para este rol ou adestrar probadores existentes? Que tipo de probas se realizarán: probas funcionais, probas de rendemento, etc. Cal é o orzamento para a execución? Avaliar as ferramentas dispoñibles Compara as ferramentas dispoñibles e selecciona 1 ou 2 ferramentas que mellor cumpran os requisitos. Proba de concepto Implementar un subconxunto de probas coa ferramenta preseleccionada. Presentar os resultados ás partes interesadas. Finalizar a ferramenta que se vai implementar. Implementación Inicio Dependendo da ferramenta que elixas, terás que instalar a ferramenta necesaria nun PC, máquina virtual ou servidor. Se a ferramenta que elixes está baseada nunha subscrición. , crea o equipo necesariocontas. Adestrar ao equipo se é necesario. Poñer en marcha Crear probas Executar probas Informar de defectos Desafíos comúns e formas de mitigalos Imos comentar algúns dos desafíos comúns dos equipos de control de calidade enfrontarse ao tentar implementar un marco de proba de API nunha organización. #1) Escoller a ferramenta correcta Seleccionar a ferramenta correcta para o traballo é o desafío máis común. Hai varias ferramentas de proba de API dispoñibles no mercado. Pode parecer moi atractivo implementar a ferramenta máis recente e máis cara dispoñible no mercado, pero se non obtén os resultados desexados, esa ferramenta. non serve de nada. Por iso, escolle sempre a ferramenta que responda aos requisitos "imprescindibles" en función das túas necesidades organizativas. Aquí tes unha matriz de avaliación da ferramenta de mostra para o Ferramentas da API dispoñibles Ferramenta Prezos Notas Soap UI Versión gratuíta dispoñible para SoapUI Open Source (probas funcionais) * REST, SOAP e outros protocolos populares de API e IoT. * Incluído na versión gratuíta Probas ad-hoc SOAP e REST Afirmación da mensaxe Arrastre e amp; Creación de probas de eliminación Rexistros de probas Configuración de probas Proba a partir de gravacións Informes de unidades. * Pódese consultar a lista completa de funcións. atopados nos seussitio web. Postman A aplicación Postman gratuíta dispoñible * A máis utilizada para REST. * As funcións pódense atopar no seu sitio web. Parasoft É unha ferramenta de pago, require a compra dunha licenza e despois a instalación antes de que se poida utilizar a ferramenta. * Probas de API completas: probas funcionais, de carga, de seguridade, xestión de datos de proba vREST Baseado no número de usuarios * Probas automatizadas da API REST. * Gravación e reprodución. * Elimina a dependencia do frontend e do backend mediante simulacións de API. * Potente validación de respostas. * Funciona para aplicacións de proba implantadas en localhost/intranet/internet. * Integración JIRA, Importacións de integración de Jenkins de Swagger, Postman. HttpMaster Edición Express: descarga gratuíta Versión profesional: en función do número de usuarios * Axuda nas probas de sitios web, así como nas probas de API. * Outras características inclúen a capacidade de definir parámetros globais, proporciona ao usuario a posibilidade de crear comprobacións para a validación da resposta de datos mediante o gran conxunto de tipos de validación que é compatible. Runscope En función do número de usuarios e dos tipos de plan * Para supervisar e probar as API. * Pódese usar para a validación de datos para garantir que se devolvan os datos correctos. * Contén función deseguimento e notificación en caso de falla na transacción da API (se a súa aplicación require a validación do pago, esta ferramenta pode resultar unha boa opción). LoadFocus En función do número de usuarios e dos tipos de plan * Pódese usar para probas de carga da API: permite realizar poucas probas para coñecer o número de usuarios que pode admitir unha API. * Fácil de usar: permite realizar probas no navegador. PingAPI Gratis para 1 proxecto (1.000 solicitudes) ) * Beneficioso para probas e monitorizacións automatizadas da API. #2) Faltan especificacións de proba Como probadores, necesitamos saber os resultados esperados para probar eficazmente unha aplicación. Adoita ser un reto, xa que para coñecer os resultados esperados, necesitamos ter requisitos claros e precisos, que non é o caso. Por exemplo , considere os requisitos que se indican a continuación: "A aplicación só debe aceptar unha data de envío válida e todos os requisitos non válidos deben ser rexeitados" A estes requisitos faltan detalles clave e son moi ambiguos. Como estamos a definir unha data válida? E o formato? Devolvemos algunha mensaxe de rexeitamento ao usuario final, etc.? Exemplo de requisitos claros: 1) A aplicación só debería acepta unha data de envío válida. A data de envío considérase válida se é asíé Non no pasado Maior ou igual á data de hoxe Está nun formato aceptable: DD/MM/AAAA 2) Código de estado da resposta = 200 Mensaxe: OK 3) A data de envío que non cumpre os criterios anteriores debe considerarse non válido. Se un cliente envía unha data de envío non válida, debe responder coas seguintes mensaxes de erro: 3.1 Código de estado de resposta NON 200 Erro: a data de envío proporcionada non é válida; asegúrese de que a data estea no formato DD/MM/AAAA 3.2 Código de estado da resposta NON 200 Erro: sempre que a data de envío estea en o pasado #3) Curva de aprendizaxe Como se mencionou anteriormente, o enfoque para as probas da API é diferente cando se compara co enfoque seguido ao probar aplicacións baseadas na GUI. Se están contratando especialistas internos ou consultores para probas de API, entón a curva de aprendizaxe do enfoque de proba da API ou da ferramenta de proba da API pode ser mínima. Calquera curva de aprendizaxe, neste caso, estaría asociada coa adquisición do coñecemento do produto ou da aplicación. Se se asigna a un membro do equipo existente para aprender probas da API, entón, dependendo da ferramenta que elixa, a curva de aprendizaxe pode ser medio a alto, xunto con cambiar o enfoque da proba. A curva de aprendizaxe do produto ou da propia aplicación pode ser baixa-media dependendo de se este probador realizou a probaesa aplicación antes ou non. #4) Conxunto de habilidades existentes Isto enlaza directamente co punto anterior sobre a curva de aprendizaxe. Se un probador estaba a pasar de Probas baseadas na GUI, entón o probador debería cambiar o enfoque de proba e aprender a nova ferramenta ou marco segundo sexa necesario. Por exemplo. Se a API acepta as solicitudes en formato JSON, o probador terá que aprender o que é JSON para comezar a crear as probas. Estudo de caso Tarefa Para ampliar unha aplicación existente, unha empresa quería ofrecer un produto en API así como unha aplicación GUI estándar. Pediuse ao equipo de control de calidade que proporcionase un plan de cobertura das probas para asegurarse de que están preparados para realizar probas de API máis aló das probas habituais baseadas na GUI. Retos Ningún dos outros produtos de software tiñan unha arquitectura baseada na API, polo que para acomodar as probas nesta tarefa, o equipo debe establecer o proceso de proba da API desde cero. Isto significa que as ferramentas debían ser avaliadas, preseleccionadas, finalizadas e o equipo tiña que ser adestrado para as probas. Non houbo orzamento adicional para adquirir e implementar a ferramenta. Isto significa que o equipo tivo que escoller unha ferramenta de proba de API gratuíta ou de código aberto e que alguén do equipo existente tivo que ser adestrado para levar a cabo esta tarefa. Non había requisitos para os campos e datos da API.validación. Os requisitos eran "debería funcionar igual que a aplicación GUI correspondente". O enfoque seguido polo equipo para mitigar os riscos e solucionar os retos O equipo de control de calidade traballou co equipo do proxecto para identificar os seguintes requisitos: Tipo de API (REST/SOAP): REST Probas necesarias (funcional, Carga, Seguridade): Só probas funcionais Probas automatizadas necesarias (Si/Non): Opcional por agora Informes de probas (Si/Non) ): Obrigatorio O equipo de control de calidade realizou unha avaliación das ferramentas das ferramentas de proba da API dispoñibles en función dos requisitos imprescindibles. A ferramenta Postman API finalizouse como unha ferramenta da súa elección xa que era gratuíta e tamén fácil de usar, polo que se minimizaba a curva de aprendizaxe e tiña o potencial de automatizar as probas e incluía bos informes integrados. O mesmo probador que probou a aplicación foi adestrado para usar Postman para crear probas iniciais, eliminando así as lagoas de coñecemento do produto. Para facer fronte aos requisitos que faltaban, o equipo do proxecto elaborou a documentación de alto nivel de campo usando Swagger. . Non obstante, isto deixou algunhas lagoas en termos de formatos de datos aceptables e isto foi abordado co equipo do proxecto e acordáronse e documentáronse os formatos esperados. Conclusión As aplicacións baseadas na API teñen gañou popularidade nos últimos tempos. Estas aplicacións son máisescalable en comparación coas aplicacións/software tradicionais e permite unha integración máis sinxela coas outras API ou aplicacións. Este tutorial de probas de API explicounos todo sobre as probas de API, as probas de Shift Left, os servizos web e as API web en detalle. Tamén exploramos as diferenzas entre os servizos web e as API web con exemplos. Na segunda parte do titorial, discutimos o espectro completo das probas de API, como introducir as probas de API na túa organización e algúns retos comúns en este proceso xunto con solucións para eles. Consulta o noso próximo tutorial para saber máis sobre os servizos web xunto con exemplos!! SEGUINTE Titoría O titorial de servizos explica a arquitectura, tipos e amp; Compoñentes dos servizos web xunto con terminoloxías importantes e as diferenzas entre SOAP e REST.
Tutorial_#3:	As 35 principais preguntas de entrevistas de ASP.Net e Web API con respostas Podes explorar a lista das preguntas máis populares de entrevistas de ASP.Net e Web API con respostas & exemplos para principiantes e profesionais con experiencia neste titorial.
Tutorial_#4:	Tutorial de POSTMAN: probas de API usando POSTMAN Este titorial paso a paso explicará a proba de API usando POSTMAN xunto cos conceptos básicos de POSTMAN, os seus compoñentes e a solicitude de mostra & Resposta en termos sinxelos para facilitar a súa comprensión.
Tutorial_#5:	Probas de servizos web usando o cliente HTTP Apache Este titorial de API trata de realizar varias operacións CRUD en servizos web e probar servizos web usando o cliente HTTP Apache

Titorial de probas de API

Esta sección axudarache a obter unha comprensión básica dos servizos web e da API web, que, á súa vez, serán útiles para comprender os principais conceptos dos próximos titoriais desta serie de probas de API.

API ( Interface de programación de aplicacións) é un conxunto de todos os procedementos e funcións que nos permiten crear unha aplicación accedendo aos datos ou funcións dosistema operativo ou plataformas. As probas deste tipo de procedementos coñécense como probas de API.

Probas de quendas á esquerda

Un dos tipos importantes de probas que se solicitan hoxe en día nas entrevistas de probas de API é as probas de quendas á esquerda. Este tipo de probas practícanse en case todos os proxectos que seguen unha metodoloxía áxil.

Antes de que se introduciu a proba Shift Left, as probas de software só apareceron despois de completar a codificación e entregar o código aos probadores. Esta práctica provocou o apuro de última hora para cumprir o prazo e tamén dificultou en gran medida a calidade do produto.

Ademais, os esforzos realizados (cando se notificaron defectos na última fase antes da produción) foron enorme xa que os desenvolvedores tiveron que pasar de novo pola fase de deseño e codificación.

Ciclo de vida do desenvolvemento de software (SDLC) antes da proba de Shift Left

O fluxo SDLC tradicional foi: Requisito: > Deseño –> Codificación –> Probas.

Inconvenientes das probas tradicionais

• As probas están na extrema dereita. Cando se identifica un erro no último minuto lévanse moitos custos.
• O tempo que se consume para resolver o erro e probalo de novo antes de promocionalo á produción é enorme.

Por iso, xurdiu unha nova idea para cambiar a fase de proba cara á esquerda, o que levou á proba de desprazamento á esquerda.

Lectura suxerida => Proba de desprazamento á esquerda: AMantra secreto para o éxito do software

Fases da proba de desprazamento á esquerda

As probas de desprazamento á esquerda levaron a unha migración satisfactoria da detección de defectos á prevención de defectos. Tamén axudou ao software a fallar rapidamente e a corrixir todos os fallos como antes.

API web

En termos xerais, unha API web pódese definir como algo que recibe a solicitude dun cliente sistema a un servidor web e devolve a resposta dun servidor web a unha máquina cliente.

Como funciona unha API?

Voñamos un escenario moi común de reservar un voo en www.makemytrip.com, que é un servizo de viaxes en liña que agrega información de varias compañías aéreas. Cando buscas unha reserva de voo, introduces información como a data da viaxe/data de regreso, a clase, etc. e fai clic en buscar.

Isto amosarache o prezo de varias compañías aéreas e a súa dispoñibilidade. Neste caso, a aplicación interactúa coas API de varias compañías aéreas e, polo tanto, dá acceso aos datos da compañía aérea.

Outro exemplo é www.trivago.com que compara e enumera o prezo, dispoñibilidade, etc. de diferentes hoteis. dunha cidade concreta. Este sitio web comunícase con API de varios hoteis para acceder á base de datos e enumera os prezos e a dispoñibilidade do seu sitio web.

Así, unha API web pódese definir como “unha interface que facilita a comunicación entre unha máquina cliente e oservidor web”.

Servizos web

Os servizos web son (como a API web) os servizos que serven dunha máquina a outra. Pero a principal diferenza que xorde entre a API e os servizos web é que os servizos web usan unha rede.

É seguro dicir que todos os servizos web son API web pero que non son servizos web (explicado no última parte do artigo). Así, os servizos web son un subconxunto da API web. Consulte o seguinte diagrama para obter máis información sobre a API web e os servizos web.

API web e servizos web

Servizos web vs. API web

Tanto a API web como os servizos web úsanse para facilitar a comunicación entre o cliente e o servidor. A principal diferenza vén só na forma en que se comunican.

Cada un deles require un corpo de solicitude que sexa aceptable nun idioma específico, as súas diferenzas ao proporcionar unha conexión segura, a súa velocidade de comunicación co servidor e de resposta. ao cliente, etc.

A continuación móstranse as diferenzas entre os servizos web e a API web para a súa referencia.

Servizo web

• Os servizos web xeralmente usan XML (Extensible Markup Language), o que significa que son máis seguros.
• Os servizos web son máis seguros xa que tanto os servizos web como as API proporcionan SSL (capa de conexión segura) durante a transmisión de datos. , pero tamén ofrece WSS (Web Services Security).
• O servizo web é un subconxunto da API web. Por exemplo, os servizos web baséanse só en tres estilos de uso, é dicir, SOAP, REST e XML-RPC.
• Os servizos web sempre necesitan unha rede para funcionar.
• Os servizos web admiten “Aplicacións diferentes dun código”. Isto significa que se escribe un código máis xenérico en diferentes aplicacións.

Web API

• Unha API web normalmente usa JSON (JavaScript Object Notation), o que significa que a API web é máis rápida.
• A API web é máis rápida xa que JSON ten un peso lixeiro, a diferenza de XML.
• As API web son o superconxunto dos servizos web. Por exemplo, Os tres estilos de servizos web tamén están presentes na API web, pero ademais diso, usa outros estilos como JSON – RPC.
• A API web non precisa necesariamente unha rede para operar.
• A API web pode admitir ou non a interoperabilidade dependendo da natureza do sistema ou da aplicación.

Presentación das probas da API na súa organización

No noso día a día, todos estamos tan afeitos a interactuar coas aplicacións con API e, aínda así, nin sequera pensamos nos procesos de fondo que impulsan a funcionalidade subxacente.

Por exemplo. , Consideremos que estás navegando polos produtos en Amazon.com e ves un produto/oferta que che gusta moito e que queres compartilo coa túa rede de Facebook.

No momento en que fai clic na icona de Facebook na sección de compartir da páxina e introduce o teuAs credenciais da conta de Facebook para compartir, estás interactuando cunha API que conecta perfectamente o sitio web de Amazon con Facebook.

Cambio de enfoque ás probas da API

Antes de falar máis sobre as probas da API, imos discutir os motivos. polo que as aplicacións baseadas na API gañaron popularidade nos últimos tempos.

Hai varias razóns polas que as organizacións están a pasar a produtos e aplicacións baseados na API. E algunhas delas están listadas a continuación para a súa referencia.

#1) As aplicacións baseadas na API son máis escalables en comparación coas aplicacións/software tradicionais. O ritmo de desenvolvemento do código é máis rápido e a mesma API pode atender máis solicitudes sen ningún cambio importante de código ou de infraestrutura.

#2) Os equipos de desenvolvemento non precisan comezar a codificar desde cero cada vez. momento en que comezan a traballar no desenvolvemento dunha función ou aplicación. As API reutilizan a maioría das veces funcións repetibles, bibliotecas, procedementos almacenados, etc. existentes e, polo tanto, este proceso pode facelos máis produtivos en xeral.

Por exemplo, Se es un programador que traballa nun sitio web de comercio electrónico e queres engadir Amazon como procesador de pagos; entón non tes que escribir o código desde cero.

Todo o que tes que facer é configurar a integración entre o teu sitio web e a API de Amazon usando Chaves de integración e chame á API de Amazon para procesar os pagos durante a compra.

#3) As API permitenintegración sinxela cos outros sistemas tanto para aplicacións autónomas compatibles como con produtos de software baseados en API.

Por exemplo , consideremos que queres enviar un envío desde Toronto a Nova York. . Vai en liña, navega a un sitio web de carga ou loxística coñecido e introduce a información requirida.

Despois de proporcionar a información obrigatoria, cando fai clic no botón Obter tarifas, no fondo, este sitio web de loxística pode estar conectado con varias API e aplicacións de operadores e provedores de servizos para obter as tarifas dinámicas para a combinación de localizacións de orixe a destino.

Espectro completo de probas de API

As probas de API non se limitan ao envío dunha solicitude. a API e analizando a resposta só para a súa corrección. Hai que probar o seu rendemento das API baixo diferentes cargas para detectar vulnerabilidades.

Comentemos isto en detalle.

(i) Probas funcionais

As probas funcionais poden ser unha tarefa difícil debido á falta dunha interface GUI.

Vexamos como é diferente o enfoque das probas funcionais das API da aplicación baseada na GUI e tamén comentaremos algúns exemplos ao seu redor.

a) A diferenza máis obvia é que non hai unha GUI coa que interactuar. Os probadores que adoitan facer probas funcionais baseadas en GUI resúltalles un pouco máis difícil pasar a probas de aplicacións non GUI en comparación conalguén que xa estea familiarizado con el.

Inicialmente, mesmo antes de comezar a probar a API, terás que probar e verificar o propio proceso de autenticación. O método de autenticación variará dunha API a outra e implica algún tipo de chave ou token para a autenticación.

Se non podes conectarte á API correctamente, non podes continuar coas probas. Este proceso pódese considerar comparable á autenticación de usuario nas aplicacións estándar nas que precisa credenciais válidas para iniciar sesión e utilizar a aplicación.

b) É moi importante probar as validacións de campo ou a validación dos datos de entrada. durante a proba de API. Se estivese dispoñible unha interface baseada en formularios (GUI), as validacións de campo poderían implementarse na interface ou no backend, garantindo así que un usuario non teña permitido introducir valores de campo non válidos.

Por exemplo, Se unha aplicación precisa que o formato de data sexa DD/MM/AAAA, podemos aplicar esta validación ao formulario que recolle información para asegurarnos de que a solicitude está a recibir e procesar unha data válida.

Non obstante, isto non é o mesmo para as aplicacións API. Debemos asegurarnos de que a API está ben escrita e é capaz de facer cumprir todas estas validacións, distinguir entre datos válidos e non válidos e devolver o código de estado e a mensaxe de erro de validación ao usuario final mediante unha resposta.

c) Probando o