11. Critérios de agrupamento de teste de
software
1. Quanto ao conhecimento sobre o
software
2. Quanto à natureza do teste
3. Testes não-funcionais
4. Testes automatizados
12. 1. Quanto ao conhecimento sobre o
software
Teste de caixa branca
Quando se avalia o funcionamento
interno do software. Por exemplo, se
determinados métodos executam
corretamente.
13. 1. Quanto ao conhecimento sobre o
software
Teste de caixa preta
Quando se avalia o comportamento do
software, através de suas interfaces. Por
exemplo, quando o usuário usa o
sistema para ver se ele retorna valores
esperados após um cálculo.
14. 2. Quanto à natureza do teste
Teste Unitário ou de Unidade
testa partes específicas do sistema,
como classes e seus métodos.
15. 2. Quanto à natureza do teste
Teste de Integração
testa vários componentes de um sistema
funcionando em conjunto.
16. 2. Quanto à natureza do teste
Teste de Sistema ou Homologação
execução do sistema do ponto de vista
do usuário, embora não realizado pelo
usuário final.
17. 2. Quanto à natureza do teste
Teste de Aceitação
teste realizado pelo usuário para verificar
se o software está de acordo com o que
foi contratado.
18. 2. Quanto à natureza do teste
Teste de Regressão
testes já realizados são executados
novamente após modificações no
software para garantir que não houve um
efeito colateral inesperado.
19. 3. Testes não-funcionais
Teste de Desempenho (Performance)
verifica o desempenho do sistema com
uma carga normal de usuários. Por
exemplo, o tempo de resposta médio é
de 2 segundos com até mil usuários.
20. 3. Testes não-funcionais
Testes de Carga (Volume)
verifica a capacidade máxima do
sistema, ou seja, o ponto onde ele trava
ou deixa de responder em tempo
adequado.
21. 3. Testes não funcionais
Teste de Resiliência (Stress)
verifica o comportamento do sistema e
sua capacidade de se recuperar de
falhas inesperadas, como queda de
energia, falha em banco de dados, picos
de acesso, etc.
39. Joãozinho desenvolveu o software x na
linguagem PHP que já está produção.
Um usuário relatou um erro e Joãozinho
foi logo tentar corrigir. Ele então
percebeu que a parte do código que deu
erro é um método usado em várias
partes do sistema. Sendo assim, não
seria tão simples uma mudança no
método pois poderia gerar outros erros.
41. Escrever um novo método que corrige o
problema especificado pelo usuário
deixando o método problemático intacto
já que ele é usado em outras partes do
sistema.
44. Verificar em todo sistema onde o método
problemático é usado e escrever um
teste para cada parte onde ele é
chamado se baseando na expectativa do
que ele deve fazer.
45.
46. Joãozinho desenvolveu um sistema na
versão 5.1 do Laravel. O tempo passou
e o Laravel chegou à versão 5.4.
Joãozinho, por algum motivo, viu a
necessidade de atualizar o projeto da
versão 5.1 para a 5.4 do Laravel.
Joãozinho não sabe por onde começar
pois teme que ocorram muitos erros
após a atualização.
54. Clonar o projeto atual no servidor de
homologação (testes) e fazer nele a
atualização do projeto para identificar os
eventuais erros. Escrever testes que
cubram boa parte do sistema a fim de
eliminar erros por conta da atualização.