Verificação e Validação de Software

Começar. É Gratuito
ou inscrever-se com seu endereço de e-mail
Verificação e Validação de Software por Mind Map: Verificação e Validação de Software

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.