Avaliacao A5

[V-Seidel]

Teste em classes de equivalência

Tal teste foi utilizado em PR #45

O particionamento em classes de equivalência é uma técnica de teste que divide o conjunto de dados de entrada em classes, onde cada classe representa um conjunto de condições ou comportamentos semelhantes. O objetivo é garantir que cada classe seja testada de maneira abrangente, sem a necessidade de testar todas as combinações possíveis. Vamos analisar cada método de teste no seu código e identificar as classes de equivalência associadas:

Método test_register_user_success:

Classe de Equivalência: Registro de Usuário Bem-Sucedido

- Condições:

• O usuário fornecido é único.
• O nome de usuário e o e-mail não estão previamente registrados.

- Teste:

• Cria um usuário único e tenta registrá-lo.
• Verifica se o resultado é UserSignupSituation.SUCCESS.
• Método test_register_user_username_taken:

Classe de Equivalência: Nome de Usuário Já Registrado

- Condições:

• O nome de usuário fornecido já está registrado.

  - Teste:

• Cria um usuário com um nome de usuário.

• Cria outro usuário com o mesmo nome de usuário.

• Verifica se o resultado é UserSignupSituation.USERNAME_TAKEN.

• Método test_register_user_email_taken:

• Classe de Equivalência: E-mail Já Registrado

- Condições:

• O e-mail fornecido já está registrado.

- Teste:

• Cria um usuário com um endereço de e-mail.
• Cria outro usuário com o mesmo endereço de e-mail.
• Verifica se o resultado é UserSignupSituation.EMAIL_TAKEN.
• Método test_login_user_success:

Classe de Equivalência: Login Bem-Sucedido

- Condições:

• O nome de usuário e a senha fornecidos correspondem a um usuário registrado.

- Teste:

• Cria um usuário.
• Tenta fazer login com as credenciais corretas.
• Verifica se o resultado é UserSignupSituation.SUCCESS.
• Método test_login_user_invalid_credentials:

Classe de Equivalência: Credenciais de Login Inválidas

- Condições:

• O nome de usuário fornecido não corresponde a nenhum usuário ou a senha está incorreta.

- Teste:

• Cria um usuário.
• Tenta fazer login com credenciais incorretas.
• Verifica se o resultado é False.

[sdiasricardo]

Outro tipo de teste:

Depois de uma análise minuciosa, chegou-se a conclusão que não seria possíve executar nenhum outro tipo de teste funcional. Isso se deve, primeiro, ao fato da maioria das features implementadas serem features visuais, ou seja, landing page, diferentes tipos de gráficos e chamadas de APIs. Dessa maneira, sobrariam apenas os testes de cadastro de usuário, que foram feitos anteriormente como no PR #45 Além disso, os métodos propostos não se encaixam com os tipos de entrada que possuimos, como explicado abaixo:

Pairwise

Nesse caso, além das váriaveis não serem bem definidas (ou seja, o email e username não são opções e nem possuem restrições de tamanho), temos apenas 2 colunas com duas opções (email igual ou diferente, usuário igual ou diferente) o que nos renderia apenas 2 pares, tirando assim o sentido do Pairwise, que busca reduzir o custo operacional de testes.

Grafo de decisão

Realizar o teste utilizando a técnica de grafo de decisão também não faria sentido pois, para os usuários, diferentes combinações não geram erros similares. Isto quer dizer que os diferentes campos (e.g. email e username) não podem ser elencados em cascata, como pede a técnica de grafos. Assim, como temos que campos diferentes geram erros diferentes, essa técnica também é inválida

Análise dos limites

Ainda que seja complementar às classes de valência, também não podemos implementar essa técnica pois os campos de erro (e.g. email e username) não possuem valores limítrofes, ou seja, não há um numero limitado de caracteres ou algo do gênero, e portanto não se torna possível testar os casos de borda.

[brenofranca83]

Outro tipo de teste:

Depois de uma análise minuciosa, chegou-se a conclusão que não seria possíve executar nenhum outro tipo de teste funcional. Isso se deve, primeiro, ao fato da maioria das features implementadas serem features visuais, ou seja, landing page, diferentes tipos de gráficos e chamadas de APIs. Dessa maneira, sobrariam apenas os testes de cadastro de usuário, que foram feitos anteriormente como no PR #45 Além disso, os métodos propostos não se encaixam com os tipos de entrada que possuimos, como explicado abaixo:

Pairwise

Nesse caso, além das váriaveis não serem bem definidas (ou seja, o email e username não são opções e nem possuem restrições de tamanho), temos apenas 2 colunas com duas opções (email igual ou diferente, usuário igual ou diferente) o que nos renderia apenas 2 pares, tirando assim o sentido do Pairwise, que busca reduzir o custo operacional de testes.

Grafo de decisão

Realizar o teste utilizando a técnica de grafo de decisão também não faria sentido pois, para os usuários, diferentes combinações não geram erros similares. Isto quer dizer que os diferentes campos (e.g. email e username) não podem ser elencados em cascata, como pede a técnica de grafos. Assim, como temos que campos diferentes geram erros diferentes, essa técnica também é inválida

Análise dos limites

Ainda que seja complementar às classes de valência, também não podemos implementar essa técnica pois os campos de erro (e.g. email e username) não possuem valores limítrofes, ou seja, não há um numero limitado de caracteres ou algo do gênero, e portanto não se torna possível testar os casos de borda.

Não estão corretos esses raciocínios. O pairwise até é mais complexo de implementar e tem que realmente encontrar uma situação mais específicas. ENtretanto, para todos os outros, era sim possível de implementá-los.