{"id":5299,"date":"2019-11-06T08:00:59","date_gmt":"2019-11-06T10:00:59","guid":{"rendered":"http:\/\/www.rcodigital.com.br\/blog\/?p=5299"},"modified":"2023-10-23T13:12:45","modified_gmt":"2023-10-23T13:12:45","slug":"12-erros-de-teste-de-api","status":"publish","type":"post","link":"https:\/\/www.intergate.net.br\/blog\/12-erros-de-teste-de-api\/","title":{"rendered":"12 erros de teste de API"},"content":{"rendered":"\n

Os desenvolvedores devem ficar atentos para evitar que todo o trabalho duro e os recursos dispon\u00edveis por tr\u00e1s do desenvolvimento da API n\u00e3o sejam desperdi\u00e7ados, se o software n\u00e3o for testado corretamente. Como \u00e9 o caso de qualquer aplicativo da Web ou m\u00f3vel, testes cuidadosos s\u00e3o cr\u00edticos para APIs<\/em><\/strong>. Aqui, listamos alguns erros comuns de teste de API que voc\u00ea deve evitar:<\/p>\n\n\n\n\n\n\n\n

1.Teste de API como uma atividade aut\u00f4noma.<\/h2>\n\n\n\n

Uma API deve trabalhar e agregar valor \u00e0 configura\u00e7\u00e3o de TI existente dos neg\u00f3cios. Portanto, test\u00e1-lo no v\u00e1cuo – sem considerar como a interface funcionaria no ecossistema – seria bastante in\u00fatil<\/em><\/strong> . Os provedores de API devem ter em mente que todos os erros de API n\u00e3o s\u00e3o gerados pelas mesmas causas, e o ambiente em que \u00e9 implementado tem um papel a desempenhar. Idealmente, \u00e9 necess\u00e1rio garantir que todas as partes interessadas<\/em><\/strong> (as equipes relacionadas \u00e0 API em quest\u00e3o) recebam notifica\u00e7\u00f5es<\/em><\/strong> sobre os resultados do teste. Isso dar\u00e1 uma id\u00e9ia clara de qu\u00e3o bem ou n\u00e3o, a nova API fica no fluxo de trabalho geral da organiza\u00e7\u00e3o. Testar uma API por conta pr\u00f3pria provavelmente dar\u00e1 uma imagem m\u00edope e enganosa.<\/p>\n\n\n\n

2. Realizando apenas testes de GUI
( Interface Gr\u00e1fica do Usu\u00e1rio<\/em> ) <\/h2>\n\n\n\n

Testar a GUI ( Interface Gr\u00e1fica do Usu\u00e1rio<\/em> ) \u00e9 uma parte essencial do teste da API<\/a> – mas est\u00e1 longe de ser tudo o que voc\u00ea precisa verificar. Normalmente, as ferramentas de teste da GUI n\u00e3o mostram se a API pode ser perfeitamente integrada em um aplicativo m\u00f3vel<\/em><\/strong> ou em qualquer outro software de destino. De acordo com desenvolvedores de API profissionais, os testes de GUI representam apenas cerca de 10%<\/em><\/strong> do est\u00e1gio geral de testes de API. <\/p>\n\n\n\n

3. Considerar o desempenho do aplicativo como prova da qualidade da API <\/h2>\n\n\n\n

Pode ser que uma API possa ser facilmente integrada no servidor back-end de um aplicativo m\u00f3vel, garantindo que o \u00faltimo funcione corretamente. No entanto, isso n\u00e3o descarta as possibilidades de erros b\u00e1sicos estarem presentes na API subjacente. N\u00e3o fa\u00e7a a loucura de aceitar o fator de qualidade de uma API, simplesmente porque o aplicativo do usu\u00e1rio final alimentado por ela est\u00e1 funcionando bem. <\/em><\/strong>Os erros podem surgir posteriormente, causando falhas no aplicativo e for\u00e7ando os desenvolvedores a verificar se h\u00e1 erros em todos os elementos da cadeia de chamadas. <\/p>\n\n\n\n

\"12<\/figure>\n\n\n\n

4. N\u00e3o verificando a escalabilidade <\/h2>\n\n\n\n

Com o tempo, \u00e9 prov\u00e1vel que a base de usu\u00e1rios de uma API aumente. \u00c0 medida que a frequ\u00eancia de solicita\u00e7\u00f5es de rede aumenta ( mesmo que voc\u00ea tenha implementado ‘limites de taxa’)<\/em> , a API precisa aumentar<\/em><\/strong> . Se a verifica\u00e7\u00e3o de escalabilidade n\u00e3o aparecer na sua rotina de testes de API, as chances de ‘ sobrecarga do usu\u00e1rio<\/em><\/strong> ‘ permanecer\u00e3o, juntamente com problemas financeiros e legais. Certifique-se de que sua API seja escal\u00e1vel adequadamente e estabele\u00e7a um mecanismo de governan\u00e7a de API.<\/p>\n\n\n\n

5.Testando m\u00e9todos separados isoladamente <\/h2>\n\n\n\n

Muitos novos desenvolvedores de API cometem esse erro. Eles configuram testes para verificar se uma interface funciona bem com m\u00e9todos diferentes (por exemplo, verificar invent\u00e1rio e adicionar itens ao carrinho de compras, com GET e POST<\/em> ) isoladamente. Embora esses testes possam dar resultados positivos, a API pode falhar quando \u00e9 usada em v\u00e1rios m\u00e9todos<\/em><\/strong> – como \u00e9 prov\u00e1vel que seja usada pelos usu\u00e1rios finais. Um provedor de API respons\u00e1vel precisa verificar se uma nova API ret\u00e9m a funcionalidade desejada enquanto trabalha com uma combina\u00e7\u00e3o de m\u00e9todos<\/em><\/strong> . <\/p>\n\n\n\n

6. O teste da API n\u00e3o \u00e9 uma atividade \u00fanica <\/h2>\n\n\n\n

Mesmo ap\u00f3s a publica\u00e7\u00e3o de um aplicativo da Web ou m\u00f3vel, suas APIs subjacentes precisam ser testadas. Se o teste for interrompido ap\u00f3s o lan\u00e7amento da vers\u00e3o final do aplicativo, poder\u00e3o surgir problemas de compatibilidade e \/ ou funcionais<\/em><\/strong> – quando o aplicativo for portado em dispositivos e sistemas operacionais mais recentes. Al\u00e9m do mais, fazer altera\u00e7\u00f5es na API aleatoriamente pode ter s\u00e9rios efeitos adversos nos clientes da API. Uma porcentagem significativa de problemas de desempenho<\/em><\/strong> do aplicativo pode ser rastreada at\u00e9 os problemas em suas APIs<\/em><\/strong> (com o pr\u00f3prio aplicativo n\u00e3o sendo com erros). Continue testando APIs, mesmo depois de integrado<\/a> em um aplicativo e o \u00faltimo ter sido lan\u00e7ado. <\/p>\n\n\n\n

7. Ser liberal com SDKs e DevKits <\/h2>\n\n\n\n

\u00c0 primeira vista, tentar aumentar a integrabilidade das APIs com a ajuda de kits de desenvolvimento<\/em><\/strong> de software (SDKs)<\/em><\/strong> e bibliotecas – para linguagens de programa\u00e7\u00e3o separadas – parece uma estrat\u00e9gia perfeitamente adequada. Uma inspe\u00e7\u00e3o mais detalhada, no entanto, revela dois problemas<\/em><\/strong> . Em primeiro lugar, \u00e9 praticamente imposs\u00edvel cobrir todas as linguagens de codifica\u00e7\u00e3o usadas para criar APIs (PHP, .NET, Node.js, Delphi, Java etc.) – e \u00e9 prov\u00e1vel que haja incompatibilidades entre seus SDKs e o sistema de codifica\u00e7\u00e3o de uma empresa<\/em><\/strong> (o cliente da API) . Al\u00e9m disso, quanto maior o n\u00famero de bibliotecas do SDK, maior a responsabilidade do provedor de API<\/em><\/strong>. 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\u00e3o. <\/p>\n\n\n\n

8. Falta de antecipa\u00e7\u00e3o sobre amea\u00e7as e ataques <\/h2>\n\n\n\n

J\u00e1 destacamos como a falta de previs\u00e3o sobre escalabilidade pode prejudicar uma API. Um provedor de API<\/a> precisa ser bem versado com m\u00e9todos de ataque de software comum, como ‘shell scripts’, ‘inje\u00e7\u00e3o SQL’, ataques de engenharia social, e ‘bombas XML’<\/em><\/strong> . Al\u00e9m do mais, erros de iniciantes na codifica\u00e7\u00e3o do lado do cliente podem levar a ataques DDoS (Denial of Service)<\/em><\/strong> – resultado de volumes de solicita\u00e7\u00f5es inesperadamente altos. Ataques em interfaces digitais tamb\u00e9m podem ser iniciados passando certos dados XML \/ JSON na forma de anexos<\/em><\/strong> . <\/p>\n\n\n\n

9. Ignorando falhas pouco frequentes <\/h2>\n\n\n\n

Uma API deve funcionar corretamente o tempo todo e n\u00e3o a maior parte do tempo. Geralmente, \u00e9 uma op\u00e7\u00e3o “conveniente”<\/em> para os desenvolvedores de API ignorarem os problemas que ocorrem apenas de forma intermitente. Um argumento comumente usado para justificar isso \u00e9 que todo o log de tr\u00e1fego da API deve ser verificado – para descobrir as causas principais dessas falhas. O que esses desenvolvedores n\u00e3o percebem \u00e9 que esses “pequenos problemas” podem se transformar em problemas completos para os usu\u00e1rios finais. <\/em><\/strong>Nenhum problema relacionado \u00e0 usabilidade, por menor que seja, deve ser encoberto. Esses problemas podem se tornar mais frequentes posteriormente, e a depura\u00e7\u00e3o da interface ser\u00e1 muito mais dif\u00edcil.<\/p>\n\n\n\n

A InterGATE<\/a> \u00e9 especialista em integra\u00e7\u00f5es via APIs. Fale conosco… <\/p>\n\n\n\n

10. N\u00e3o est\u00e1 realizando teste de regress\u00e3o <\/h2>\n\n\n\n

Esse erro geralmente decorre da cren\u00e7a equivocada de que, a menos que uma API seja alterada, ela continuar\u00e1 funcionando da mesma maneira em um aplicativo. Com os casos de uso de aplicativos cada vez mais variados, e os m\u00e9todos de desenvolvimento \u00e1gil sendo cada vez mais adotados – a l\u00f3gica e as principais fun\u00e7\u00f5es dos aplicativos geralmente precisam se expandir<\/em><\/strong> . As APIs, por sua vez, precisam ser revalidadas<\/em><\/strong> , para continuar suportando as plataformas \/ aplicativos como antes. A menos que a integridade<\/em><\/strong> da API<\/em><\/strong> seja constantemente testada por meio de conjuntos de testes de regress\u00e3o, eles podem n\u00e3o permanecer compat\u00edveis com os aplicativos de r\u00e1pida evolu\u00e7\u00e3o para os quais foram criados.<\/p>\n\n\n\n

11. Falha ao verificar as depend\u00eancias da API <\/h2>\n\n\n\n

As interfaces do programa de aplicativo s\u00e3o criadas para fornecer conectividade da web de back-end perfeita para aplicativos (lado do servidor). No entanto, a API que voc\u00ea cria geralmente depende de determinados c\u00f3digos \/ software de parceiros<\/em><\/strong> , para fornecer a funcionalidade desejada. Ignorar essas depend\u00eancias durante o teste da API pode ser um erro grave. Voc\u00ea precisa descobrir se o seu c\u00f3digo funciona a) de forma consistente eb) de maneira confi\u00e1vel<\/em> , com todos os outros softwares \/ servi\u00e7os \/ recursos dos quais ele depende. Pense al\u00e9m de testar apenas suas APIs – voc\u00ea precisa verificar todo o ecossistema<\/em><\/strong> onde ser\u00e1 implementado.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

12. Confian\u00e7a excessiva em testes manuais<\/h2>\n\n\n\n

Isso torna as coisas mais lentas, mais estressantes – e o mais importante, pode levar a que v\u00e1rios bugs e erros permane\u00e7am sem serem detectados<\/em><\/strong> . Atualmente, existem v\u00e1rias ferramentas automatizadas confi\u00e1veis \u200b\u200bpara testes de API e os desenvolvedores precisam us\u00e1-las extensivamente. Depois de conclu\u00edda<\/em><\/strong> a codifica\u00e7\u00e3o, ela pode ser importada para o Swagger ou no Postman<\/a> e os testes da API podem ser criados diretamente a partir dos arquivos e de outras defini\u00e7\u00f5es<\/em><\/strong> no seu c\u00f3digo. Desde a cria\u00e7\u00e3o e modifica\u00e7\u00e3o de testes detalhados da API at\u00e9 o agendamento de testes – todas as tarefas importantes podem ser executadas por ferramentas.<\/p>\n\n\n\n\t\t\t\t\t\t