Verificação e Validação de Software

登録は簡単!. 無料です
または 登録 あなたのEメールアドレスで登録
Rocket clouds
Verificação e Validação de Software により 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. Teste x Depuração

2.1. Teste busca por falhas ou erros exercitando o software como um todo ou partes dele

2.1.1. Depuração busca e corrige defeitos que são responsáveis por falhas ou erros do software

2.1.2. Teste caixa branca x caixa preta

2.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

2.1.3. Teste de fumaça

2.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)

2.1.4. Testes de unidade

2.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!!!

2.1.4.1.1. Para viabilizar o teste de unidade, é necessário construir drivers e stubs

2.1.5. Teste de sistema

2.1.5.1. Transcende o software • Ocorre depois dos demais teste • Visa garantir que o software funciona corretamente com os demais elementos do sistema

2.1.6. Teste de regressão

2.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

2.1.7. Testes de aceitação

2.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

2.1.8. Teste Alfa

2.1.8.1. Ambiente controlado

2.1.8.1.1. O desenvolvedor observa o sistema sendo usado pelos cliente em numero reduzido, atento a possíveis erros.

2.1.9. Teste Beta

2.1.9.1. Ambiente real

2.1.9.1.1. O cliente usa o sistema, e reporta problemas se ouve-los.

3. • Verificação

3.1. – Estamos fazendo corretamente o software?

3.2. Aderência aos requisitos especificados

3.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

4. Validação

4.1. Estamos fazendo o software correto?

4.2. Aderência aos requisitos desejados do usuário