Conteúdo

• O que é uma API?
  
  • API - conjunto de recursos
  • Como o conjunto de recursos é compilado
  • O que a palavra "interface"
• Como a API é chamada
  
  • Chamada de API diretamente
  • Chamada indireta da API
• O que significa o teste da API?
• Sumário

A palavra "API" pisca nas vagas, mesmo para testadores iniciantes. API REST, API SOAP e apenas uma API. Que tipo de animal é esse? Vamos descobrir!

"Por que eu preciso disso?" Na verdade, estou testando a web! Agora, se eu entrar na automação, sim ... Bem, eles também estão testando na empresa, ouvi dizer ...

E não! É bom para qualquer testador saber sobre a API. Porque nele os sistemas interagem entre si. E você vê essa interação todos os dias, mesmo nos sites mais simples e decadentes.

Qualquer pagamento passa pela API do sistema de pagamento. Comprou um ingresso de cinema? Uma camiseta em uma loja online? Um livro? Assim que você clicar em "pagar", o site conectará você ao sistema de pagamento.

Mas mesmo se você não tiver integração com outros sistemas, ainda terá uma API! Porque o sistema dentro de si também se comunica via API. E enquanto o desenvolvedor frontal está vendo a GUI (interface gráfica), você pode:

• ficar entediado enquanto espera;
• verifique a lógica de trabalho da API

Claro, sou a favor da segunda opção! Então, vamos entender o que é a API. Você pode assistir ao vídeo no youtube ou ler como um artigo.

O que é uma API?

API (interface de programação de aplicativos) é um contrato que um programa fornece. "Eu posso ser contatado dessa maneira e daquilo, comprometo-me a fazer isso e aquilo."

Se traduzido para o russo, seria a palavra "contrato". Um acordo entre duas partes, como um contrato para comprar um carro:

• minhas responsabilidades são fazer tal quantia
• o dever do vendedor é dar o carro.

Você pode traduzir sim. Mas ninguém faz isso ¯ \ _ (ツ) _ / ¯

Todo mundo usa a palavra "contrato". Tão aceito. Além disso, esta palavra está incluída no nome do estilo de desenvolvimento:

• Código primeiro - primeiro escrevemos o código e depois geramos um contrato nele
• Contrato primeiro - primeiro criamos um contrato e depois escrevemos ou geramos código (neste artigo, falarei sobre esse estilo)

Não dizemos "um contrato para a venda de um carro"? Portanto, os desenvolvedores não dizem "contrato". Acordo tácito.

API - conjunto de recursos

Ao comprar um carro, você elabora um contrato no qual prescreve todos os pontos importantes para você. Da mesma forma, os contratos devem ser estabelecidos entre os programas. Eles indicam como um ou outro programa pode ser acessado.

Consequentemente, a API responde à pergunta "Como posso entrar em contato com meu sistema?" E inclui:

• a operação em si que podemos executar
• dados de entrada
• dados de saída (conteúdo dos dados ou mensagem de erro).

Aqui você pode me dizer:

- Hmm, espere. A operação, os dados de entrada, os dados de saída - de alguma forma, tudo isso é muito parecido com uma descrição de função!

Se você já se deparou com o desenvolvimento ou apenas aprendeu uma linguagem de programação, provavelmente sabe o que é uma função. De fato, temos dados de entrada, existem dados de saída e alguma mágica que se converte em outra.

E sim! Você estará certo de que as definições são semelhantes. Porque Sim, porque a API é um conjunto de funções. Essa pode ser uma função ou muitas.

Como o conjunto de recursos é compilado

Sim, não importa como. Como o desenvolvedor deseja, ele se agrupará. Por exemplo, você pode agrupar a API por funcionalidade. Isto é:

• API separada para entrar no sistema, onde estarão o registro e a autorização;
• API separada para relatórios - relatório 1, relatório 2, relatório 3 ... relatório N. Para relatórios diferentes, temos diferentes fórmulas = funções diferentes. E todos nós os coletamos em um conjunto, API para relatórios.
• API do sistema de pagamento separado - existe uma função para trabalhar com cada banco.
• ...

Você não pode agrupar nada, mas crie uma API comum.

Uma API comum pode ser feita e o restante pode ser feito por encomenda. Se você tiver um produto in a box, ele geralmente inclui um conjunto de recursos padrão. E todos os clientes da lista de desejos são feitos separadamente.



Acontece que em nosso sistema existem várias APIs diferentes, para cada uma das quais temos um contrato escrito. Cada contrato especifica claramente quais operações podem ser executadas, quais funções estarão lá



E, é claro, as funções podem ser reutilizadas. Ou seja, a mesma função pode ser incluída em conjuntos diferentes, em APIs diferentes. Ninguém proíbe isso.



Acontece que o desenvolvedor cria que tipo de API ele terá. O general ou distribui de acordo com a funcionalidade ou com alguns de seus próprios critérios, e em cada API adiciona o conjunto de funções necessárias.

O que a palavra "interface"

- Espere um pouco, Olya! Você escreveu acima que a API é uma interface de programação de aplicativos. Por que você está falando sobre o contrato, embora exista a palavra interface?

Sim, porque na programação um contrato é a interface. Na descrição clássica de OOP (Object Oriented Programming), existem 3 baleias:

1. Encapsulamento
2. Herança
3. Polimorfismo

Encapsulamento é quando ocultamos a implementação. Para o usuário, tudo é fácil e claro. Cliquei no botão - recebi um relatório. E como funciona por dentro - ele não se importa. Qual banco de dados está oculto sob o capô? Oracle? MySQL? Em que linguagem de programação o programa está escrito? Como exatamente o código está organizado? Não é o ponto. O programa fornece uma interface e a utiliza.

Nem sempre o programa fornece uma interface gráfica. Pode ser um SOAP, uma interface REST ou outra API. Para usar essa interface, você deve entender:

• o que entrar;
• o que sai;
• quais exceções precisam ser tratadas.

Os usuários trabalham com a interface gráfica do usuário . Os programas funcionam com API - interface de programação de aplicativos . Eles não precisam de gráficos, apenas um contrato.

Como a API é chamada

Você pode chamar a API diretamente ou indiretamente.

Diretamente:

1. O sistema chama funções dentro de si.
2. O sistema chama o método de outro sistema
3. O homem chama um método
4. Métodos de extração de autoteste

Indiretamente:

1. O usuário trabalha com GUI

Chamada de API diretamente

1. O sistema chama funções dentro de si

Diferentes partes do programa de alguma forma se comunicam. Eles fazem isso no nível do programa, ou seja, no nível da API!

Essa é a maneira mais fácil de usar, porque o autor da API que está sendo chamada é o desenvolvedor. E ele é seu consumidor! Portanto, não há problemas com a documentação irrelevante =)

Brincadeirinha, sempre há problemas com a documentação. Apenas neste caso, como documentação, haverá comentários no código. Mas eles também são irrelevantes. Os desenvolvedores são diferentes, ou um, mas eu já esqueci como fiz a API original e como ela deveria funcionar ...

2. O sistema chama o método de outro sistema

Mas este é um caso típico que os testadores testam em integradores. Ou testadores que testam a integração de seus sistemas com os de outra pessoa.

Um sistema puxa através da API algum método de outro sistema. Ela pode tentar obter dados de outro sistema. Ou vice-versa, envie dados para este sistema.

Suponha que eu decidisse conectar os prompts do Dadata à minha loja online, para que o usuário inserisse facilmente o endereço de entrega.

Estou conectando dicas de API. E agora, quando o usuário começa a digitar o endereço no meu site, ele vê as instruções do Dadata . Como fica:

• Ele escreve uma carta no meu site
• Meu site envia uma solicitação nas dicas da API Dadat
• Dadata retorna a resposta
• Meu site processa e exibe o resultado para o usuário.

Existem tantos passos! E assim, para cada caractere digitado. O usuário não vê essa interação, mas é.

E, é claro, não se esqueça do caso quando desenvolvemos o método API. O qual só pode ser chamado através do SOAP, não é encontrado em nenhum lugar na interface. O que o Cliente encomendou, fizemos ¯ \ _ (ツ) _ / ¯

Um exemplo pode ser encontrado em Usuários. O método MagicSearch é baseado em eventos reais. Embora eu deva admitir, na lógica original era ainda mais sofisticada, eu a ajustei no meu site.

Mas o truque aqui é que, no próprio sistema, na interface do usuário, há apenas uma pesquisa regular, apenas uma linha de entrada. Bem, talvez alguns filtros. Mas a integração precisava de um monte de recursos adicionais, que eram feitos pelo método SOAP.

A funcionalidade de super busca está disponível apenas pela API, o usuário na interface não sente isso.

Nesse caso, você geralmente tem TK, de acordo com o qual o método API funciona. Sua tarefa é verificar isso. Uma tarefa típica de um testador, basta adicionar ao projeto de teste padrão os recursos dos testes de API, e tudo se resume a isso!

(o que exatamente precisa ser testado na API - contarei em um artigo separado um pouco mais tarde)

3. A pessoa chama o método

Os motivos são diferentes:

1. Para acelerar o trabalho
2. Para localizar o bug (onde está o problema? No servidor ou cliente?)
3. Para testar a lógica sem giros de borda

Se o sistema fornece uma API, geralmente é mais fácil puxá-la do que fazer o mesmo através de uma interface gráfica. Além disso, a chamada da API pode ser salva na ferramenta. Depois de salvo - você aplica em qualquer base, mesmo que seja limpo 10 vezes por dia.

Por exemplo, vamos novamente para Usuários . Se queremos criar um usuário, precisamos preencher muitos campos!



Obviamente, isso pode ser feito usando plug-ins especiais, como o Form Filler . Mas e se você precisar de dados de teste adequados para o seu sistema? E em russo?

Preencher os campos manualmente é triste e deprimente! E se você precisar repetir isso toda semana ou dia em uma base de teste limpa - geralmente um pesadelo. Essa é imediatamente a primeira prioridade na automação de ações de rotina.

E, neste caso, o papel da automação desempenha ... Postman. Um usuário pode ser criado através de uma solicitação REST CreateUser . Uma vez registrados os dados "reais" normais, toda vez que os usamos. Lucro!

Em vez de preencher manualmente o formulário (1 minuto sem preencher os campos com os valores "lprulpk"), obtemos 1 segundo ao pressionar o botão "Enviar". Nesse caso, os valores serão muito mais adequados.

E no carteiro, você pode criar uma pasta separada para preparar a base de teste, atendendo uma dúzia de solicitações lá. E agora, em qualquer base, em alguns segundos, você obtém tantos dados quanto faria manualmente por horas!

Se você encontrar um bug e não entender em quem pendurar - desenvolvedor front-end ou back-end, remova todos os itens desnecessários. Chame o método sem uma interface gráfica. E você pode testar a lógica do programa até que a interface esteja pronta ou quebrada.

4. Métodos de extração de autoteste

Existe uma pirâmide de automação típica:

• Os testes da GUI são um teste honesto, "como o usuário faria".
• Testes de API - descemos para o nível abaixo, jogando fora supérfluos.
• Testes unitários - testes para uma única função

A palavra API indica o que será usado nos testes.

Digamos que temos:

• operação : download de relatório;
• na entrada : dados de ajustes manuais ou automáticos ou de outros locais;
• output : um relatório construído de acordo com certas regras

Regras de criação de relatórios:

• Célula 1 : X - Y
• Célula 2 : Z * 6
• ...

Os testes da GUI são honestos, o robô faz tudo o que o usuário faria. Ele abre o navegador, aperta os botões ... Mas se algo cair, você descobrirá exatamente por um longo tempo.

Os testes de API são os mesmos, apenas sem um navegador. Simplesmente enviamos dados para a entrada e verificamos os dados na saída. Por exemplo, você pode inserir a resposta final no Excel e deixar o robô reconciliá-la. Os dados foram preenchidos corretamente? Localizar o problema se torna mais fácil.

Os testes de unidade são quando testamos cada função separadamente. Analisamos separadamente o cálculo da célula 1, separadamente a célula 2 e assim por diante. Esses testes são perseguidos mais rapidamente e os bugs são fáceis de localizar neles.

Chamada indireta da API

Quando o usuário trabalha com a GUI, de fato, ele também trabalha com a API. Ele simplesmente não sabe disso, ele simplesmente não precisa disso.

Ou seja, quando o usuário abre o sistema e tenta baixar o relatório, não importa como o sistema funcione, que tipo de mágica existe. Ele tem um botão "download report", no qual clica. O usuário trabalha através da GUI (interface gráfica do usuário).



Mas, de fato, há uma API sob essa interface gráfica do usuário. E quando o usuário clica no botão, o botão chama a função de construção de relatório.



E a função de criação de relatório já pode chamar 10 outras funções diferentes, se necessário.

E agora o usuário vê um relatório pronto na frente dele. Ele chamou a API complexa sem nem mesmo saber!

O que significa o teste da API?

Antes de tudo, queremos dizer testar a API VIA. "Teste de API" é um termo comumente usado, eles realmente dizem isso, mas tecnicamente o termo está incorreto. Não testamos a API, não testamos a GUI (interface gráfica). Estamos testando algum tipo de funcionalidade por meio de uma interface gráfica ou de software.

Mas esta é uma expressão estabelecida. Você pode usá-lo e dizer "teste de API". E quando falamos sobre isso, queremos dizer:

• Autotestes no nível da API
• ou integração entre dois sistemas diferentes.

Integração - quando um sistema se comunica com outro através de algum tipo de protocolo de transferência de dados. Isso é chamado de API remota, ou seja, comunicação pela rede, por algum protocolo (HTTP, JMS, etc.). Ao contrário, também existe a API local (também conhecida como "API de memória compartilhada") - essa é a API pela qual o programa se comunica consigo mesmo ou se comunica com outro programa na mesma memória virtual.



Quando falamos sobre o teste de APIs, na maioria das vezes queremos dizer o teste de APIs remotas. Quando temos dois sistemas localizados em computadores diferentes que de alguma forma se comunicam.

E se você vir "teste da API" na vaga, provavelmente isso implica a capacidade de chamar um serviço SOAP ou REST e testá-lo. Embora sempre valha a pena esclarecer!

Sumário

API (interface de programação de aplicativos) é um contrato que um programa fornece. "Eu posso ser contatado dessa maneira e daquilo, comprometo-me a fazer isso e aquilo."

O contrato inclui:

• a operação em si que podemos executar
• dados de entrada
• dados de saída (conteúdo dos dados ou mensagem de erro). "