Em testes funcionais, I deve comparar todos os dados tabulares prestados no navegador com o que vem a partir do DB?

Question

Eu estou trabalhando em um plano de teste para um site onde alguns testes estão a tomar o seguinte caminho:

1. Acertar o URI solicitado e se os dados prestados dentro de alguma mesa (20 linhas por página).
2. Faça uma consulta de banco de dados para obter os dados que é suposto ser prestados nesse tabela.
3. Compare a linha 2 de dados por linha, eles devem corresponder.

Isso é uma maneira correta de fazer o teste funcional? Se esse pedido foi uma solicitação do Ajax, o que vai ser a resposta também? A resposta diferente para testes de integração?

Eu tenho alguma razão que me faz acreditar que isso é errado de alguma forma .... ainda precisam suas opiniões guys!

Answer 1

Sim, isso poderia ser um teste produtivo. Ou você tem um conjunto de dados fixos ou não.

Se você tem um conjunto de dados fixo, este é muito mais fácil de teste, porque tudo que você está fazendo é comparar contra uma saída fixa.

Se você não tem um conjunto de dados fixo, então você precisa para duplicar a lógica de negócios, duplicando efetivamente o trabalho já realizado pelo desenvolvedor. Então você tem dois conjuntos de lógica para manter.

O segundo é a melhor abordagem, porque você tem duas maneiras de fazer a mesma coisa, efetivamente uma revisão por pares da especificação e código. É também muito caro em termos de tempo e recursos, razão pela qual a maioria das pessoas optam por ter um conjunto de dados fixo.

Para responder à sua pergunta, se a sua lógica de negócios na consulta é simples, então você pode obter um teste muito facilmente. No entanto, o valor que o teste traz não é grande, porque você não está testando muito.

Se a lógica do negócio é complexo, você está recebendo mais valor do teste, mas que vai ser mais difícil de manter a longo prazo.

Para mim, o seu teste traz é um teste de integração simples que prova que o sistema lê corretamente a partir do banco de dados e exibe os dados corretamente. Este é um teste bom, ainda melhor se for automatizado.

Answer 2

Este parece bem para testes funcionais. testes de integração em minha mente tem a ver com o teste de diferentes tecnologias ou componentes que são supostamente para juntos trabalho que geralmente é mais amplo do que o teste funcional. Mas de testes de integração claro que este tipo de teste também pode ser considerado, dependendo de como o aplicativo é colocado juntos e onde o teste está acontecendo no ciclo de vida do seu desenvolvimento. Por exemplo, pode ser que para que este site funcione você tem que colocar juntos alguns componentes que foram desenvolvidos de forma independente; isso pode ser um dos testes para validar que os trabalhos de integração.

Não vejo como esta sendo Ajax ou não tem nada a ver com fazer a resposta diferente.

Answer 3

Eu provavelmente será uma opinião divergente aqui, mas eu não considero que este seja um teste produtivo. O que você está fazendo é simplesmente duplicar o código que produz a página. E qualquer hora que introduzir código duplicado (mesmo entre departamentos) você vai estar a olhar para os defeitos surgindo a longo prazo.

É muito melhor para carregar o banco de dados com dados conhecidos (por meio do app, ou diretamente) e depois verificar que as partidas de saída o que você esperaria. Isso também garante que sua camada de DB, ou a própria DB, não modificou os dados de uma forma que você não espera.

Isto é:

1. dados de carga conhecida (de preferência através do próprio app)
2. Coloque o URI solicitado
3. Verifique se os dados exibidos corresponda aos seus dados conhecidos

Answer 4

Este tipo de teste pode ser bom para testar um grande conjunto de dados com relativamente pouco esforço testador, se não há muita lógica desenvolvedor entre o banco de dados e o visor para o usuário final. Nossa equipe tem feito isso em um número de ocasiões, e é especialmente útil para a execução de grandes quantidades de dados de produção real através de nossos testes para ter certeza de que os cenários reais são tratados como esperado. Do certifique-se de fazer pelo menos um pouco fixo testes de entrada para cenários raros que podem ser especialmente susceptíveis de ser tratadas de forma diferente no DB e na página web - valores nulos, caracteres especiais, e outras esquisitices.

Pessoalmente, eu chamaria isso de "testes de integração", uma vez que está a testar a integração do DB e do site, e não "testes funcionais". Para "teste funcional", eu provavelmente quer fazer um mock da fonte de dados (por exemplo, o banco de dados) que irá fornecer conjuntos pré-escrita de dados no formato que você espera.

Dito isto, se eu tivesse alta confiança na validade dos dados DB e se a lógica entre a consulta DB e a exibição da página web era muito pequeno e de baixo risco, eu provavelmente não iria se preocupar com o mock e faria deixe que o teste de integração cobrir a funcionalidade também. Eu não sei o que testar a funcionalidade e integração separadamente seria uma vitória qualidade grande neste caso, e há provavelmente melhores coisas que você poderia fazer com o tempo de teste disponíveis. Se houver muita lógica em torno esses dados, você provavelmente deve testar a integração separadamente da funcionalidade. testes de integração adicional provavelmente incluem coisas como: "E se o banco de dados não pode ser alcançado?" e "E se o banco de dados é lenta?".

Embora essa técnica irá trabalhar com Ajax, certifique-se de suas ferramentas de teste irá trabalhar com Ajax. Especificamente, pense sobre como você irá capturar os resultados da consulta de banco de dados e como você vai reunir os resultados exibidos na página web.

Estou assumindo que a validade dos dados na consulta está sendo testado em outro lugar, desde que você mencionou que este era apenas um tipo de teste no plano de teste. Eu também estou apenas discutindo a integração com o o banco de dados e este relatório e não outras características ou componentes, e não outros aspectos do teste (desempenho, segurança. Etc.), uma vez que foi o alcance da sua pergunta.