1. Ciclo de Propagação
1.1. 1- Desenvolvedor comete um engano
1.2. 2- SoJware com defeito
1.3. 3- Defeito é exercitado e gera um erro
1.4. 4- Software falha
1.5. 5-Usuário sofre as consequências
2. • Verificação
2.1. – Estamos fazendo corretamente o software?
2.2. Aderência aos requisitos especificados
2.3. • Verificação não precisa ser feita somente quando existe código – Inspeções são técnicas efetivas para identificação de defeitos, mesmo antes de ter código
3. Validação
3.1. Estamos fazendo o software correto?
3.2. Aderência aos requisitos desejados do usuário
4. Teste x Depuração
4.1. Teste busca por falhas ou erros exercitando o software como um todo ou partes dele
4.1.1. Depuração busca e corrige defeitos que são responsáveis por falhas ou erros do software
4.1.2. Teste caixa branca x caixa preta
4.1.2.1. Duas estratégias distintas para elaboração de testes • Teste caixa branca – Também conhecido como teste estrutural – Conhece o interior do produto – Utiliza esse conhecimento na definição da estratégia de teste – Encontra erros • Teste caixa preta – Também conhecido como teste funcional – Não conhece o interior do produto – Utiliza somente os requisitos na definição da estratégia de teste – Encontra falhas
4.1.3. Teste de fumaça
4.1.3.1. Metáfora a fumaça gerada por circuito eletrônico com defeito na sua primeira execução • Consiste em fazer um teste superficial que indica a viabilidade de rodar os demais testes – Todas as partes são combinadas e é gerado um build do software – Esse build é submetendo a testes básicos – Esse processo é repeMdo frequentemente (e.g., diariamente)
4.1.4. Testes de unidade
4.1.4.1. Foco em testar caminhos específicos do produto (caixa branca) • Visa ter 100% de cobertura – Neste caso, 100% de cobertura representando a execução de todas as linhas do código – Já vimos que é impossível ter 100% de cobertura para todos os caminhos possíveis de execução!!!
4.1.4.1.1. Para viabilizar o teste de unidade, é necessário construir drivers e stubs
4.1.5. Teste de sistema
4.1.5.1. Transcende o software • Ocorre depois dos demais teste • Visa garantir que o software funciona corretamente com os demais elementos do sistema
4.1.6. Teste de regressão
4.1.6.1. Não é mais um tipo de teste, mas sim um papel que pode ser empenhado por diferentes Mpos de teste • Visa evitar que defeitos já corrigidos retornem ao produto • Muito usado em testes de integração, onde testes anteriores são aplicados
4.1.7. Testes de aceitação
4.1.7.1. Foco em apresentar o produto ao usuário para que o produto seja homologado • Visa estabelecer critérios para aceitação – Funcionais – Comportamentais – De desempenho • Tipos de teste de aceitação – Alfa – Beta
4.1.8. Teste Alfa
4.1.8.1. Ambiente controlado
4.1.8.1.1. O desenvolvedor observa o sistema sendo usado pelos cliente em numero reduzido, atento a possíveis erros.
4.1.9. Teste Beta
4.1.9.1. Ambiente real
4.1.9.1.1. O cliente usa o sistema, e reporta problemas se ouve-los.