Fundamentos de Engenharia de SW

Apresentação em tema: "Fundamentos de Engenharia de SW"— Transcrição da apresentação:

1 Fundamentos de Engenharia de SW
Estratégias de Teste de SW

2 Características genéricas
Desde nível de componentes até o sistema; Técnicas distintas para momentos diferentes; Executados tanto pelo desenvolvedor como por grupo independente; depuração deve fazer parte de qualquer estratégia de teste.

3 Verificação e validação
Teste faz parte de uma atividade mais ampla conhecida como V & V; V & V trata de: atividades de controle de qualidade do software revisões formais, simulação, análise de algoritmo, testes de desenvolvimento, etc.); Testes constituem o último mecanismo para garantir a qualidade ; A qualidade é incorporada ao longo de um processo certificada durante os testes.

4 Verificação e validação
Estamos produzindo o produto de forma correta? “Are we building the product right?” Validação: Estamos produzindo o produto correto? “Are we building the right product ?”

5 Organizando os testes Conflito de interesses: desenvolvedores testam para mostrar que o programa funciona e não para encontrar erros. Psicologicamente: desenvolver é construtivo e testar é destrutivo; O desenvolvedor deve ser o responsável pelos testes individuais dos componentes; A função do grupo independente de teste (ITG) é eliminar o conflito de interesses. São pagos para encontrar erros; O ITG deve trabalhar em conjunto com a equipe desenvolvimento do projeto.

6 Uma Estratégia 4 etapas executadas sequencialmente: Testes de unidade:
Foco em cada componente individual, garantindo que a função apropriada de cada componente está sendo realizada; Testes de integração: Foco na verificação e construção do programa, resultado da integração dos componentes; Testes de validação: Foco na validação dos requisitos funcionais, de comportamento, e de desempenho; Testes de sistema: Uma vez validado, o software deve ser combinado com outros elementos (hardware, pessoas, dados). Verifica que a função/desempenho do sistema como um todo é alcançada.

7 Critério de finalização dos testes
Como saber que os testes executados foram suficientes? Algumas respostas: Os testes nunca terminam. Apenas ocorre uma transferência do ônus de testar, do desenvolvedor para o usuário; Os testes terminam quando acaba o prazo e/ou o dinheiro; Aproximações empíricas buscam modelar falhas como uma função do tempo de execução. A idéia é prever o tempo total necessário para a execução de testes, de modo a atingir um nível de confiabilidade aceitável.

8 Questões fundamentais
Quantificar os requisitos do produto antes do início dos testes; Explicitar os objetivos dos testes; Desenvolver um perfil para cada categoria de usuário; Desenvolver um plano de testes que enfatize ciclos curtos; Construir software robusto que seja capaz de se auto-testar; Utilizar revisões formais como um filtro antes dos testes; Realizar revisões formais de modo a garantir a própria estratégia de teste; Aplicar melhorias contínuas ao processo de testes.

9 Testes de Unidade (1) Tem como foco a menor unidade do software (componente ou módulo); testes caixa branca podem ser executados em paralelo para vários módulos; Tipos de testes: Interface do módulo (fluxo de informação que entra e sai da unidade); Dados locais devem manter a sua integridade durante toda a execução do algoritmo; Condições de contorno são testadas para garantir a operação do módulo dentro dos limites e restrições estabelecidas; Todos os caminhos possíveis na estrutura de controle devem ser executados ao menos uma vez; Os tratamentos de erros devem ser testados.

10 Testes de Unidade (2) Procedimentos
Criação dos casos de teste e feita após codificacao. caso de teste deve especificar os resultados esperados; Módulos não são programas stand-alone desenvolver “drivers” e “stubs”; O teste de unidade é simplificado quando um componente possui alta coesão.

11 Testes de Integração (1)
construir a estrutura de uma programa, ao mesmo tempo que são executados testes de interface; integração incremental. testar em pequenos incrementos torna mais fácil isolar e corrigir erros.

12 Integração top-down Módulos são integrados a partir de um programa principal, em direção aos sub-módulos. O processo de integração: O módulo principal é utilizado como um Driver e stubs são substituídos para todos os componentes diretamente subordinados Stubs subordinados são substituídos, um por vez, pelos componentes reais; Testes são realizados em cada componente integrado; Testes de regressão garantir que novos erros não tenham sido introduzidos.

13 Integração top-down (2)
Problema: processamento em níveis inferiores é necessário para testar níveis superiores. 3 escolhas: Postergar os testes, até que os stubs possam ser substituídos pelos módulos reais (dificulta identificação das causas de erros); Desenvolver stubs que simulem o módulo real (trabalhoso); Passar para estratégia Bottom-up.

14 Integração bottom-up Inicia com os módulos atômicos.
elimina a necessidade dos stubs; Etapas: Componentes de baixo nível são agrupados; Driver é desenvolvido para testar entrada/saída; O agrupamento é testado; Drivers são removidos e os agrupamentos combinados.

15 Regressão Repetição de um conjunto de testes já realizado
visa garantir que mudanças no software não introduzam efeitos indesejados ou erros adicionais; 3 categorias: Um conjunto representativo para testar todas as funções do software; Testes para as funções mais afetadas pelas alterações Testes para os componentes que sofreram modificações.

16 Smoke Testing Estratégia para o teste de integração muito usada em projetos com prazos críticos. atividades: Componentes codificados são integrados em um “pacote”. O pacote inclui todos os componentes necessários para implementar uma ou mais funções do produto; Testes são criados para identificar erros que vão impedir os “pacotes” de executarem as suas funções; Pacotes são integrado a outros “pacotes” e o produto é testado diariamente. Benefícios: Mnimiza riscos de Integração; Melhora a qualidade do produto final; Facilita o diagnóstico e a correção de erros ; Facilta estimativa de progresso.

17 Documentação Plano de testes Procedimento de testes Histórico
descreve a estratégia de integração como um todo, incluindo o cronograma de integração, a descrição de overhead (stubs e drivers), o ambiente de testes, recursos envolvidos, bem como ferramentas e técnicas utilizadas Procedimento de testes a sequência de integração e os testes correspondentes a cada fase da integração são descritos. Uma lista de todos os casos de teste e os resultados esperados deve ser incluída; Histórico resultados dos testes, problemas, ou peculiaridades devem ser registrados

18 Testes de Validação Objetivo: demonstrar a conformidade com os requisitos. Após validação: Existe conformidade com a especificação; Desvios são descobertos e uma lista de defeitos é criada. Erros nesta fase raramente são corrigidos antes da entrega do produto. É necessário negociar com o cliente um método para resolver os problemas. Testes Alfa e Beta: usados para identificar erros que apenas os usuários estão aptos a descobrir.

19 Testes de Sistema Recuperação; Segurança; Carga; Desempenho.
Após validação software deve ser combinado com outros elementos: hardware, pessoas, dados. Verifica que a função/desempenho do sistema como um todo é alcançada. Tipos de testes de Sistema: Recuperação; Segurança; Carga; Desempenho.

20 Depuração A depuração tem como objetivo encontrar e corrigir as causas dos erros de um software. Depurar não é testar, mas sim uma consequência dos mesmos. Formas de depuração: Força bruta; “Backtracking”; Eliminação da causa.