Categorias amplas para minha mente seriam:
Teste de caixa preta . Você não consegue ver o código e está apenas testando às cegas até certo ponto, pois o que está no aplicativo ou no sistema está oculto. Portanto, neste caso, as pessoas não conhecem todos os casos de erro e precisam adivinhar com várias condições de contorno que podem ou não ser óbvias para encontrar todos os casos.
Teste de caixa branca . Você consegue ver o código e pode verificar quais caminhos de código estão sendo usados para que a cobertura do código possa ser usada como uma métrica para garantir que toda a lógica esteja sendo usada no sistema. A idéia aqui é saber como é o código para ajudar a guiar os testes, para que não seja tão misterioso quanto o teste de caixa preta.
O teste de caixa cinza é um híbrido dos dois anteriores.
Os casos de limite tendem a ser algo que se pode ver nos testes de caixa branca, pois existem várias condições para ver no código que se escreve os testes a serem atingidos, por exemplo, se você tiver um programa que solicite um número e alguém digitar X como isso é tratado deve ser visto em algum lugar do código.
As classificações gerais dos testes seriam:
Testes unitários . Esses geralmente são os menores testes que testam algo bastante específico; por exemplo, esse método lida com esse caso de fronteira? Observe que a injeção de dependência pode ser usada aqui para casos que envolvem objetos simulados para reduzir quaisquer dependências para os testes.
Testes de integração . São testes nos quais alguns componentes estão conectados e testes são executados para garantir que os componentes funcionem bem juntos. Observe que, embora os testes de unidade possam funcionar de forma independente, é aqui que é feito o teste de quão bem as coisas se reúnem, pois pode haver falta de comunicação entre as camadas que fazem com que esses testes sejam úteis na captura de várias dicas. O termo testes de ponta a ponta é usado para testes de integração em que uma cadeia completa de componentes é testada de "um ponto final do aplicativo para outro" (o que isso significa).
Testes de regressão . Estes seriam testes feitos no passado e feitos novamente para garantir que o que foi corrigido permaneça corrigido e que os bugs não sejam reintroduzidos no código.
Testes de usabilidade . Seriam testes feitos para ver até que ponto os usuários finais podem trabalhar com o software para concluir várias tarefas. Onde algo poderia ser automatizado para tornar algo mais rápido ou ajustar a interface do usuário para que algo seja mais fácil de usar.
Testes de aceitação do usuário . Esses seriam testes feitos pelos usuários finais, para que eles possam ver em primeira mão como algo funciona e concordar que o software atende às necessidades de negócios que o solicitaram em primeiro lugar.
Testes funcionais são todos os tipos de testes baseados na especificação funcional do software em teste. Estes são sempre testes de caixa preta.
Testes de performance. Estes seriam testes feitos para garantir que um sistema possa lidar com uma certa quantidade de carga sem ficar muito lento. Por exemplo, testar um novo farm de servidores da Web poderia lidar com 100 usuários que acessam um site ao mesmo tempo, seria um exemplo de teste de desempenho. Eles também podem ser chamados de "testes de carga" ou "testes de estresse", pois geralmente a idéia aqui é levar o sistema ao limite ou verificar se o sistema pode lidar com alguma projeção de outro departamento. A justificativa para esses testes é que geralmente existem inúmeras definições de configuração a serem otimizadas, que podem levar mais do que um pouco de trabalho para descobrir gargalos e solucionar problemas com isso. O gargalo aqui pode ser memória, E / S, CPU ou largura de banda da rede que faz com que o sistema não seja tão responsivo quanto o esperado.
O Test Driven Development é uma metodologia e não se refere a um tipo específico de teste, mas sim que os testes são escritos antes do código, de modo que os testes são o que impulsiona o desenvolvimento, e não o comportamento , domínio ou recurso, sendo alguns outros exemplos em termos de processo.
Integração Contínua é uma prática de executar regularmente alguns testes, como testes de unidade, integração e regressão, para que, se uma alteração interromper um teste, ele seja capturado o mais cedo possível.