Teste de caixa preta/cinza de API REST e UI

Question

Estamos escolhendo qual sistema de testes de aceitação automatizados começaremos a usar (trocar) em nossa empresa.Atualmente, a maioria dos casos de teste de back-end são escritos por nosso ex-testador em Python e para novos testadores é difícil usá-los e mantê-los;para UI usamos o Estrutura do robô.

Eu gostaria de usar algo padrão para que novos "testadores típicos de rua" possam começar a usar e ainda assim deve ser bastante flexível.

Em meus trabalhos anteriores, os testadores usaram SoapUI ou até mesmo Apache JMeter com scripts Groovy, mas por algum motivo as pessoas na minha empresa atual não gostam disso.

Estamos considerando Fitness ou estrutura do robô.

Requisitos:

• deve ser usado tanto para backend (API REST, algumas verificações de banco de dados) quanto para testes de UI
• deve usar uma linguagem simples para que mesmo não programadores/testadores possam entender os casos de teste (os proprietários do produto devem ser capazes de ver se todos os critérios de aceitação foram cobertos)
• deve suportar integração com Jenkins
• Ele deve suportar o versão de casos de teste para que, para uma versão específica do produto, também possamos conferir casos de teste relevantes no momento, usamos o testrail (gerenciamento de casos de teste SW);então seria bom se ele se integrasse a ele (pelo menos é possível programá-lo para enviar os resultados dos testes para lá) ou substituí-lo completamente

Joguei rapidamente com o Fitnesse e para mim a forma tabular parece muito feia.Além disso, à primeira vista, o documento não é ótimo (não encontrei "comandos" possíveis, por ex.asserções, alguns loops) e documentação para, por exemplo,o RestFixture é ainda pior (nenhum).

Além disso, não vi nenhum acessório para verificações de banco de dados.Portanto, no final, um desenvolvedor precisa estar envolvido para programar e manter alguns acessórios personalizados, o que para mim parece pior do que usar nosso conjunto de testes Python desenvolvido internamente.

Alguma ideia, experiência?

Obrigado, Radek

PS:Fiz essa pergunta também no fórum de controle de qualidade, mas é muito menos ativo que o StackOverflow, desculpe pela duplicação.

Answer 1

Não posso falar sobre o uso do fitness, mas estrutura do robô atende a todas as coisas que você pede e muito mais.Eu o escolho para meus projetos pelos seguintes motivos:

1. Você pode usar uma única ferramenta (e, portanto, um único formato de relatório) para SABÃO- e DESCANSARserviços baseados em dados, validação de banco de dados, teste de UI baseado na web, e até mesmo teste de aplicativos de desktop.Ele também pode ser usado para integração e testes unitários, embora muitas vezes existam ferramentas melhores para esse trabalho.
2. Você pode usar testes de robô para implementar testes manuais usando o Diálogos biblioteca ou uma biblioteca personalizada.Tenho visto uma aceleração significativa no rendimento do testador quando eles executam testes manuais escritos em robô do que quando executam testes semelhantes escritos no Microsoft Word.Infelizmente não há muito escrito na web sobre esse recurso poderoso, mas você pode obter o mesmo tipo de relatório, controle de versão, marcação, etc.recursos para todos os seus testes de aceitação, tanto manuais quanto automatizados.
3. Se você investir tempo na criação de uma boa biblioteca de palavras-chave, os testes poderão ser facilmente lidos (e graváveis!) por não testadores
4. Existe um plugin de robô para jenkins que facilita a navegação nos resultados dos testes
5. Os conjuntos de testes da estrutura do robô são arquivos de texto simples, para que possam ter controle de versão junto com seu código.
6. A saída do teste é um arquivo XML muito simples de entender e analisar.Também pode gerar saída estilo xunit para integração com outras ferramentas.O Robot também vem com ferramentas para converter esse xml em logs e relatórios amigáveis.O interface do ouvinte facilita a captura ou transmissão de resultados de testes ao vivo.
7. Há um número crescente de ferramentas e plug-ins de edição que funcionam com o Robot, para que os membros da sua equipe possam usar as ferramentas com as quais se sentem mais confortáveis.
8. Robô é muito extensível - bibliotecas de palavras-chave podem ser escritas em quase qualquer linguagem - nativamente em python, bem como em java se você executar com jython, ou em linguagens .NET se você executar com IronPython.E com o interface de biblioteca remota, você pode escrever palavras-chave em qualquer linguagem que possa abrir um soquete e atuar como servidor.

Quanto aos fixtures para testes de banco de dados, existe um genérico biblioteca de banco de dados baseada em java, e um genérico biblioteca de banco de dados baseada em python que pode se conectar a praticamente qualquer banco de dados comum.Há também uma biblioteca específica para conversar com MongoDB.

Relacionado à pergunta que você tinha sobre versionamento, o robô tem uma ferramenta muito poderosa mecanismo de marcação que você pode achar útil.Você pode, por exemplo, marcar todos os testes com a versão do produto que os acompanha.Aí é só conferir tudo menos usar robôs opções de linha de comando para selecionar apenas os testes marcados com uma versão específica.Como benefício colateral da marcação, os relatórios detalham as estatísticas de aprovação/reprovação por tag.

Robot não é um sistema de teste perfeito, mas é muito bom.Eu diria que existem muitas estruturas de teste igualmente boas, mas não tenho certeza se há alguma que seja objetivamente melhor.Certamente para as coisas que você listou que são importantes para você, o robot framework faz tudo que você precisa.

Answer 2

Eu estava em um cenário quase semelhante antes. Tivemos que decidir entre RF, Fitness e IBM's STAF / STAX

Nós escolhemos o framework do robô e funcionou bem.

.
1. deve ser usado tanto para backend (repouso API, algumas verificações DB) e UI Testando - para descanso, RF's Solicitações Biblioteca junto com várias bibliotecas DB podem ser usadas em conjunto.
2. deve usar uma linguagem simples, portanto, mesmo não-programadores / testador entender os casos de teste (os proprietários de produtos devem ser capazes de ver Se todos os critérios de aceitação são cobertos) - RF destina-se a fazer com precisão isso.
3. deve apoiar a integração com o Jenkins - RF tem um Jenkins plugin
4. deve apoiar a versão de casos de teste para que, para um determinado Versão do produto Nós também podemos conferir os casos de teste relevantes agora - RF's tags

   Existe um framework robô API , então é muito programável os requisitos de integração.