A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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

Apresentações semelhantes


Apresentação em tema: "Fundamentos de Engenharia de SW Estratégias de Teste 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 –Verificaçã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 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 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.


Carregar ppt "Fundamentos de Engenharia de SW Estratégias de Teste de SW."

Apresentações semelhantes


Anúncios Google