Verificação e Validação

Comienza Ya. Es Gratis
ó regístrate con tu dirección de correo electrónico
Verificação e Validação por Mind Map: Verificação e Validação

1. Teste de software

1.1. Objetivo

1.1.1. Tem como principal objetivo revelar falhas/bugs para que sejam corrigidas até que o produto final atinja a qualidade desejada / acordada.

1.2. Algumas ferramentas

1.2.1. Selenium, TestComplete, Telerik Test Studio, Robotium, Watir, HPE Unified Functional Testing, Ranorex.

1.3. Exemplo de técnicas

1.3.1. Caixa branca

1.3.1.1. Avalia o comportamento interno do componente de software. Como: teste de condição, teste de fluxo de dados, teste de ciclos, teste de caminhos lógicos, códigos nunca executados.

1.3.2. Caixa-preta

1.3.2.1. Avalia o comportamento externo do componente de software, sem se considerar o comportamento interno. Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido.

1.3.3. Caixa-cinza

1.3.3.1. Mescla as técnicas de caixa-preta e de caixa-branca. Assim tem acesso a estruturas de dados e algoritmos do componente a fim de desenvolver os casos de teste.

1.3.4. Regressão

1.3.4.1. Aplicar, a cada nova versão do software ou a cada ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema.

1.3.5. Técnicas não funcionais

1.3.5.1. Verificam atributos que não se relacionam com a funcionalidade (confiabilidade, eficiência, usabilidade, manutenibilidade e portabilidade)

1.4. Fases ou níveis

1.4.1. Teste de Unidade

1.4.1.1. Teste em um nível de componente ou classe. É o teste cujo objetivo é um “pedaço do código”.

1.4.2. Teste de integração

1.4.2.1. Garante que os componentes combinados funcionam. É composto por diversos testes de unidade.

1.4.3. Teste operacional

1.4.3.1. Garante que a aplicação pode rodar muito tempo sem falhar.

1.4.4. Teste de Aceitação do usuário

1.4.4.1. Testa se a solução será bem vista pelo usuário. Ex: caso exista um botão pequeno demais para executar uma função, isso deve ser criticado em fase de testes.

1.4.5. Teste Positivo-negativo

1.4.5.1. Garante que a aplicação vai funcionar corretamente na sua execução e vai funcionar no seu fluxo de exceção.

1.5. Processo de teste

1.5.1. Planejamento

1.5.1.1. Elaborar a Estratégia de Teste e o Plano de Teste.

1.5.2. Especificação

1.5.2.1. Elaborar/ Revisar casos de testes.

1.5.3. Execução

1.5.3.1. Os testes são executados.

1.5.4. Encerramento

1.5.4.1. Elaborar evidências de bugs e conforme os bugs forem corrigidos, elaborar evidências comprovando que os bugs foram corrigidos.

2. Verificação

2.1. Fizemos o que foi proposto?

2.1.1. Os requisitos e funcionalidades implementadas atendem o que foi documentado?

2.1.2. Na especificação de sistemas avaliar se os requisitos estão sendo documentados como deveriam, prever falhas e inconsistências.

2.2. Atividades de verificação

2.2.1. Revisões de requisitos

2.2.1.1. Garantir que os seguintes atributos de qualidade foram adotados: compreensibilidade, redundância, completude, consistência, organização, conformidade com as normas, rastreabilidade.

2.2.2. Revisões de modelos

2.2.2.1. Avaliar a consistência de cada modelo e a consistência entre os vários modelos do sistema. Verificar se estes modelos realmente representam os requisitos reais dos stakeholders.

2.2.3. Inspeções de código

2.2.3.1. É uma revisão, um highlevel checkout, você lê e tenta achar erros óbvios de lógica ou gramática/digitação.

2.2.4. Revisões e inspeções técnicas em geral

2.2.4.1. É um tipo particular de revisão que pode ser aplicado a todos os artefatos de software, possui um processo de detecção de defeitos rigoroso e bem definido.

3. Validação

3.1. Fizemos o software correto?

3.1.1. O que foi entregue atende as expectativas do cliente?

3.1.2. Os requisitos estão sendo implementados para atender a necessidade do cliente?

3.1.3. O sistema é realmente o que o cliente quer e está pagando?

4. Tipos

4.1. Estática

4.1.1. Não requer a execução ou existência de um programa ou modelo executável para ser realizada.

4.2. Dinâmica

4.2.1. Se baseia na execução de um programa ou modelo.

5. Objetivos

5.1. Verificar se o sistema atende as especificações.

5.2. Verificar se os requisitos foram atendidos.

5.3. Encontrar bugs, erros e falhas.