12 erros de teste de API que você precisa evitar - Blog ERP Brasil
Publicado em 06/11/2019 05/11/2019 por Monica Nietsche
1.Teste de API como uma atividade autônoma.
Uma API deve trabalhar e agregar valor à configuração de TI existente dos negócios. Portanto, testá-lo no vácuo – sem considerar como a interface funcionaria no ecossistema – seria bastante inútil . Os provedores de API devem ter em mente que todos os erros de API não são gerados pelas mesmas causas, e o ambiente em que é implementado tem um papel a desempenhar. Idealmente, é necessário garantir que todas as partes interessadas (as equipes relacionadas à API em questão) recebam notificações sobre os resultados do teste. Isso dará uma idéia clara de quão bem ou não, a nova API fica no fluxo de trabalho geral da organização. Testar uma API por conta própria provavelmente dará uma imagem míope e enganosa.
2. Realizando apenas testes de GUI
( Interface Gráfica do Usuário )
Testar a GUI ( Interface Gráfica do Usuário ) é uma parte essencial do teste da API – mas está longe de ser tudo o que você precisa verificar. Normalmente, as ferramentas de teste da GUI não mostram se a API pode ser perfeitamente integrada em um aplicativo móvel ou em qualquer outro software de destino. De acordo com desenvolvedores de API profissionais, os testes de GUI representam apenas cerca de 10% do estágio geral de testes de API.
3. Considerar o desempenho do aplicativo como prova da qualidade da API
Pode ser que uma API possa ser facilmente integrada no servidor back-end de um aplicativo móvel, garantindo que o último funcione corretamente. No entanto, isso não descarta as possibilidades de erros básicos estarem presentes na API subjacente. Não faça a loucura de aceitar o fator de qualidade de uma API, simplesmente porque o aplicativo do usuário final alimentado por ela está funcionando bem. Os erros podem surgir posteriormente, causando falhas no aplicativo e forçando os desenvolvedores a verificar se há erros em todos os elementos da cadeia de chamadas.
4. Não verificando a escalabilidade
Com o tempo, é provável que a base de usuários de uma API aumente. À medida que a frequência de solicitações de rede aumenta ( mesmo que você tenha implementado 'limites de taxa') , a API precisa aumentar . Se a verificação de escalabilidade não aparecer na sua rotina de testes de API, as chances de ' sobrecarga do usuário ' permanecerão, juntamente com problemas financeiros e legais. Certifique-se de que sua API seja escalável adequadamente e estabeleça um mecanismo de governança de API.
5.Testando métodos separados isoladamente
Muitos novos desenvolvedores de API cometem esse erro. Eles configuram testes para verificar se uma interface funciona bem com métodos diferentes (por exemplo, verificar inventário e adicionar itens ao carrinho de compras, com GET e POST ) isoladamente. Embora esses testes possam dar resultados positivos, a API pode falhar quando é usada em vários métodos – como é provável que seja usada pelos usuários finais. Um provedor de API responsável precisa verificar se uma nova API retém a funcionalidade desejada enquanto trabalha com uma combinação de métodos .
6. O teste da API não é uma atividade única
Mesmo após a publicação de um aplicativo da Web ou móvel, suas APIs subjacentes precisam ser testadas. Se o teste for interrompido após o lançamento da versão final do aplicativo, poderão surgir problemas de compatibilidade e / ou funcionais – quando o aplicativo for portado em dispositivos e sistemas operacionais mais recentes. Além do mais, fazer alterações na API aleatoriamente pode ter sérios efeitos adversos nos clientes da API. Uma porcentagem significativa de problemas de desempenho do aplicativo pode ser rastreada até os problemas em suas APIs (com o próprio aplicativo não sendo com erros). Continue testando APIs, mesmo depois de integrado em um aplicativo e o último ter sido lançado.
7. Ser liberal com SDKs e DevKits
À primeira vista, tentar aumentar a integrabilidade das APIs com a ajuda de kits de desenvolvimento de software (SDKs) e bibliotecas – para linguagens de programação separadas – parece uma estratégia perfeitamente adequada. Uma inspeção mais detalhada, no entanto, revela dois problemas . Em primeiro lugar, é praticamente impossível cobrir todas as linguagens de codificação usadas para criar APIs (PHP, .NET, Node.js, Delphi, Java etc.) – e é provável que haja incompatibilidades entre seus SDKs e o sistema de codificação de uma empresa (o cliente da API) . Além disso, quanto maior o número de bibliotecas do SDK, maior a responsabilidade do provedor de API. Em caso de falhas, o desenvolvedor precisa se aprofundar em empresas de terceiros – para detectar e remover problemas. No momento do teste, determine quantos SDKs e DevKits terão.
8. Falta de antecipação sobre ameaças e ataques
Já destacamos como a falta de previsão sobre escalabilidade pode prejudicar uma API. Um provedor de API precisa ser bem versado com métodos de ataque de software comum, como 'shell scripts', 'injeção SQL', ataques de engenharia social, e 'bombas XML' . Além do mais, erros de iniciantes na codificação do lado do cliente podem levar a ataques DDoS (Denial of Service) – resultado de volumes de solicitações inesperadamente altos. Ataques em interfaces digitais também podem ser iniciados passando certos dados XML / JSON na forma de anexos .
9. Ignorando falhas pouco frequentes
Uma API deve funcionar corretamente o tempo todo e não a maior parte do tempo. Geralmente, é uma opção "conveniente" para os desenvolvedores de API ignorarem os problemas que ocorrem apenas de forma intermitente. Um argumento comumente usado para justificar isso é que todo o log de tráfego da API deve ser verificado – para descobrir as causas principais dessas falhas. O que esses desenvolvedores não percebem é que esses "pequenos problemas" podem se transformar em problemas completos para os usuários finais. Nenhum problema relacionado à usabilidade, por menor que seja, deve ser encoberto. Esses problemas podem se tornar mais frequentes posteriormente, e a depuração da interface será muito mais difícil.
A InterGATE é especialista em integrações via APIs. Fale conosco…
10. Não está realizando teste de regressão
Esse erro geralmente decorre da crença equivocada de que, a menos que uma API seja alterada, ela continuará funcionando da mesma maneira em um aplicativo. Com os casos de uso de aplicativos cada vez mais variados, e os métodos de desenvolvimento ágil sendo cada vez mais adotados – a lógica e as principais funções dos aplicativos geralmente precisam se expandir . As APIs, por sua vez, precisam ser revalidadas , para continuar suportando as plataformas / aplicativos como antes. A menos que a integridade da API seja constantemente testada por meio de conjuntos de testes de regressão, eles podem não permanecer compatíveis com os aplicativos de rápida evolução para os quais foram criados.
11. Falha ao verificar as dependências da API
As interfaces do programa de aplicativo são criadas para fornecer conectividade da web de back-end perfeita para aplicativos (lado do servidor). No entanto, a API que você cria geralmente depende de determinados códigos / software de parceiros , para fornecer a funcionalidade desejada. Ignorar essas dependências durante o teste da API pode ser um erro grave. Você precisa descobrir se o seu código funciona a) de forma consistente eb) de maneira confiável , com todos os outros softwares / serviços / recursos dos quais ele depende. Pense além de testar apenas suas APIs – você precisa verificar todo o ecossistema onde será implementado.
12. Confiança excessiva em testes manuais
Isso torna as coisas mais lentas, mais estressantes – e o mais importante, pode levar a que vários bugs e erros permaneçam sem serem detectados . Atualmente, existem várias ferramentas automatizadas confiáveis ​​para testes de API e os desenvolvedores precisam usá-las extensivamente. Depois de concluída a codificação, ela pode ser importada para o Swagger ou no Postman e os testes da API podem ser criados diretamente a partir dos arquivos e de outras definições no seu código. Desde a criação e modificação de testes detalhados da API até o agendamento de testes – todas as tarefas importantes podem ser executadas por ferramentas.