Teste de Software Apresentação

Transcrição

1 Teste de Software Apresentação Prof Daves Martins Msc Computação de Alto Desempenho

2 Agenda Teste de Software VV&T e Defeitos de Software Inspeção de Software Teste Unitário Análise do Valor Limite Teste com Objetos Mock Teste de Cobertura Teste em Banco de Dados Teste de Mutação Teste de Integração Teste Funcional Particionamento em Classes de Equivalência Teste de Desempenho Teste em Web Services Desenvolvimento Dirigido pelo Teste Integração Contínua Controle de Defeitos

3 Considerações Importantes Disciplina 72h/a Faltas - 25% - 18 faltas;

4 Avaliação T1 - Trabalhos: (10 trabalhos práticos) (100 pts) TF - Trabalho Final (120 pts) S - Seminários (80 pts) A - Artigos (10 Artigos) Leitura e Resumo (10 pts extra) Nota Final = (T1 + TF + S ) 3

5 Referências Bibliográficas DELAMARO, M.E.; MALDONADO, J.C.; JINO, M. Introdução ao Teste de Software. Elsevier Editora, MYERS, G., BADGETT, T., THOMAS, T., SANDLER, C., The Art of Software Testing. Wiley; 3rd Edition, ISBN

6 Metodologia Aulas teóricas e práticas, idealmente alternadas Seminários ministrados pelos alunos Projeto de disciplina

7

8

9

10

11 Pensamentos Importantes!!!

12 Pensamentos Importantes!!!

13

14 Teste de Software O software sempre será testado. Pode ser testado por você ou será testado pelo seu cliente/usuário.

15 Teste de Software Problemas ocorridos na utilização de produtos de software, percebidos muitas vezes pelo usuário final, podem ser decorrentes de falta de qualidade no processo de desenvolvimento, onde técnicas de inspeção e de testes são fortes aliadas na identificação precoce dos defeitos, melhorando a satisfação do usuário e minimizando os elevados custos associados a manutenções corretivas Uma das formas de melhorar a qualidade na construção de software é a implementação de procedimentos de teste em todas as fases de seu ciclo de vida

16 Teste de Software Entretanto, esta é uma prática pouco utilizada nas empresas, pois normalmente necessita de grande mão-de-obra e um esforço desregrado com resultados pouco favoráveis em muitos casos Isso acontece, pois testes devem ser embasados em fundamentos lógicos, e não simplesmente voltados para execução de funcionalidades aleatoriamente, em tentativas tendenciosas de encontrar defeitos

17 Teste de Software Não é possível aplicá-los exaustivamente Para aumentar sua eficácia, deve ser executado por equipes independentes Um bom teste: Possui alta probabilidade de encontrar um defeito Não é redundante É abrangente o suficiente Possui um nível adequado de complexidade

18 Teste de Software O teste é uma atividade destrutiva, ao contrário do desenvolvimento de software, que é uma atividade construtiva Inexistência de falhas: o software é de alta qualidade ou o teste é de baixa qualidade? Tipos de teste: unidade, cobertura, integração, regressão, funcional, desempenho Teste Homologação (ou de Aceitação): aceite pelo usuário final

19 Teste de Software Poucos programadores e analistas gostam de Teste Teste Alfa: executado na instalação do desenvolvedor pelo cliente Teste Beta: executado na instalação de um ou mais clientes pelo usuário final do software Casos de Uso devem considerar criticalidade e freqüência (Alta, Média, Baixa) para definir a prioridade do teste

20 Teste de Software Técnica Funcional (Caixa-Preta): baseia-se na especificação do software para derivar os casos de teste Particionamento em Classes de Equivalência Análise do Valor Limite Técnica Estrutural (Caixa-Branca): baseia-se no conhecimento da estrutura interna da implementação Complexidade Ciclomática

21 Teste de Software

22 Teste de Software Defeitos no Processo de Desenvolvimento A maior parte é de origem humana Quanto antes a presença de um defeito for revelada, menor o custo de sua correção e maior a probabilidade de corrigi-lo corretamente Deve-se introduzir atividades de VV&T (Verificação, Validação e Teste) ao longo de todo o ciclo de desenvolvimento

25 :.: O Processo de Testes de Software A estratégia de testes faz parte da Metodologia dos testes!!! Verificação de Diagramas UML Testes de regressão Validação de modelos ER Testes de Carga e Stress Validação/Verificação de requisitos Inspeção de Artefatos Doc. Régua de Avaliação Fornecedores Testes caixa preta Testes de vulnerabilidades Estratégia de testes Testes exploratórios Testes caixa branca Testes Funcionais Testes unitários Testes automatizados Testes baseados em cenários Testes negativos 25

26 Slide: 26 :.: Certificação Profissional O programa de certificação do Quality Assurance Institute (QAI) é um dos mais aceitos internacionalmente. Existem dois tipos de certificação: 1. CSTE ( produto ): preparação do ambiente de testes; planejamento de testes; test design; execução de testes; automação; ferramentas; elaboração de relatórios; etc. 2. CSQA ( processo ): estrutura de modelos de qualidade; definição de padrões de prática e controle de qualidade; construção, implementação e melhoria dos processos de qualidade; métricas. Outras instituições outorgantes: International Software Testing Institute e American Society for 26 Quality

27 Slide: 27 :.: Papéis & Responsabilidades Papel Responsabilidades Gerente, Coordenador ou Viabiliza os recursos necessários para Líder de testes um esforço de testes; conduz as atividades e as monitora em conformidade com o planejamento; Realoca recursos ao longo do ciclo. Analistas de Testes Planeja a estratégia e elabora casos de testes, baseando-se nos requisitos de negócio do SUT. Arquiteto de Testes Prepara toda infra estrutura necessária para se executar a estratégia de testes. Instala ferramenta, gera massa de dados, mede performance, etc. Executor de Testes Executa tudo o que está planejado. Figura-chave do ciclo de testes pois as ocorrências encontradas por ele são os indicadores da qualidade do produto inspecionado. 27

28 Teste de Software Outras categorias de testes em sistemas Recuperação: força o software a falhar em diversas situações e verifica a capacidade de recuperação do Produto Segurança: verifica se os mecanismos de proteção construídos para o sistema irão de fato protegê-lo de alguma utilização ou intrusão imprópria Stress: executa o sistema de forma a exigir recursos em quantidade, freqüência ou volume anormais Desempenho: avalia o desempenho do software quando integrado ao sistema. Normalmente está associado ao teste de Stress

31 Planejamento dos Testes Objetivo: Planejar e definir o que será feito ao longo dos testes antes que comece a sua realização efetiva Definir objetivos Definir Cronograma Alocar Pessoas Definir Riscos Especificar Casos e Procedimentos de Teste

32 Planejamento dos Testes

33 Atividade 1 Planejar Testes Ponto chave para o sucesso dos testes Deve estar relacionada ao planejamento do projeto Envolve muitas tomadas de decisões que devem ser analisadas buscando-se encontrar as melhores opções, dado o contexto de um projeto Sub-atividades: Caracterização dos testes (escopo e objetivo) Definição dos Itens de Teste e Critérios de Aprovação dos Itens Planejar estratégia a ser seguida (técnicas, métodos e ferramentas) Planejar Recursos Humanos e necessidade de treinamentos Planejar Recursos Físicos Definir Cronograma (em conformidade ao cronograma do projeto) Estimar Custos Identificar Riscos

34 Artefato - 1 Planejar Testes (IEEE829)

36 Atividade 2 Projetar Testes Objetivo: Especificar um refinamento da(s) abordagem(ns) de teste definida(s) no planejamento Identificar as características a serem testadas para cada item Projetar seus testes, identificando o conjunto de casos e procedimentos de teste a serem executados Sub-atividades: Detalhar estratégia de teste para cada item de teste e característica a ser testada Identificar casos de procedimentos de teste Priorizar procedimentos de teste Especificar critérios de aprovação para cada característica/item

37 Artefato - 2 Projetar Testes (IEEE829)

39 Atividade 3 Especificar caso de Teste Um caso de teste descreve uma condição particular a ser testada e é definido por valores de entrada, restrições de uso e um resultado esperado Nessa atividade, cada caso de anteriormente deve ser especificado Sub-atividades (para cada caso de teste): Caracterizar o caso de teste Especificar Entradas e Resultados Esperados Definir Recursos para o Caso de Teste Especificar Restrições de Uso Definir Dependências entre Casos de Teste

40 Artefato - 3 Especificar Caso de Teste (IEEE829)

42 Atividade 4 Definir procedimento de teste Um procedimento de teste descreve os passos necessários para a execução de um ou mais casos de teste Cada procedimento precisa ser caracterizado com informações sobre o seu objetivo e requisitos para a sua execução, além dos passos a serem seguidos durante os testes Sub-atividades (para cada procedimento de teste) Definir objetivos do procedimento de teste Definir Requisitos para a Execução do Procedimento Descrever Passos Construir Procedimento de Teste

43 Artefato - 4 Definir procedimento de teste (IEEE829)

45 Execução dos Testes Objetivo: Executar os testes a partir do que foi estabelecido durante o planejamento Monitorar as atividades realizadas Registrar os incidentes detectados, e Apresentar ao final os resultados dos testes

47 Atividade 5 Execução de testes Execução dos testes deve incorporar os princípios básicos de experimentação cientifica tudo feito durante os testes deve ser realizado e documentado claramente permitindo que outras pessoas possam repetir os mesmos resultados Os testes devem ser realizados de acordo com os procedimentos planejados Sub-atividades: Configurar Ambiente de Teste Executar Procedimentos de Teste Registrar Incidentes de Teste

48 Artefato 5.1 Log dos testes

49 Artefato 5.1 Log dos testes

51 Atividade 6 Analisar o resultado dos testes Os resultados dos testes devem ser avaliados para determinar se os testes obtiveram sucesso Na maioria dos casos, sucesso significa que o sistema funcionou conforme o esperado de acordo com os critérios do teste, e não apresentou resultados inesperados Permite a uma organização prover um entendimento sobre os seus processos identificando pontos de falhas durante o desenvolvimento, e consequentemente prover melhorias nos seus processos. Deve-se obter métricas de teste específicas Sub-atividades: Resumir Testes Registrar Dados dos Testes

52 Artefato 6 Resultado

53 Inspeção de Código Fonte Normalmente associa-se inspeção a código fonte, visando melhorar sua qualidade Utilizada para verificar: Padrões de codificação Estrutura dos algoritmos Para padrões de codificação, diversas ferramentas podem apoiar essa atividade: Checkstyle, PMD, FindBugs, Dependency Finder, SQE Existem plugins para algumas dessas ferramentas em diferentes IDEs

54 Inspeção de Código Fonte

55 Inspeção de Requisitos Tem sido o tipo de revisão de software mais estudado e utilizado Objetivos Identificar erros específicos em documentos e em sistemas Identificar erros sistemáticos no processo de desenvolvimento Identificar desvios em relação às especificações e padrões

56 Inspeção de Requisitos Benefícios Provê ganhos significativos em relação a prazos e custos. Tende a achar mais defeitos que qualquer outro processo, e a um custo menor No início, era aplicado apenas a código fonte. Atualmente são amplamente utilizadas É um método eficaz para o controle da qualidade e aumento da produtividade

57 Inspeção de Software Benefícios e Custo de Inspeções: Inspeções vêm sendo utilizadas há mais de três décadas; Existe evidência experimental de sua usabilidade e adequabilidade; Provêem um bom meio para o gerente do projeto monitorar a qualidade e progresso do projeto; Apresentam baixo custo devido ao fato do revisor não precisar investir muito tempo ou mesmo não demandar ferramentas sofisticadas para realizá-las. Uma alta taxa de atividades de inspeção ao longo do processo pode representar de 5% a 10% do esforço de desenvolvimento.

58 Inspeção de Software Inspeções em requisitos e projeto, conduzidas no JPL Nasa Jet Propulsion Laboratory (Miller,1990);

59 Inspeção de Software

60 Defeitos em Requisitos

65 Processo de inspeção de software

66 Inspeção Ad-Hoc

67 Inspeção com Checklists

68 Lista de Verificação de Inspeção de Requisitos 1)Os requisitos exibem uma clara distinção entre funções e dados? 2)Os requisitos definem todas as informações a serem exibidas aos usuários? 3)Os requisitos definem as respostas ao sistema e ao usuário às condições de erro? 4)É cada requisito indicado claramente, conciso, e não ambíguo? 5)É cada requisito testável? 6)Há requisitos ambíguos ou inconsistentes? 7)Há conflitos de requisitos? 8)Existem áreas não identificadas na especificação de requisitos de software que necessitam ser? 9)Os requisitos de desempenho (tais como o tempo de resposta, requisitos de armazenamento de dados) são indicados? 10)Se os requisitos envolverem complexas cadeias de decisão, estão expressos em um formato que facilite sua compreensão (isto é, tabelas de decisão, árvores da decisão, etc..)? 11)Os requisitos para executar melhorias do software foram especificados? 12)Há requisitos que contém um nível desnecessário de detalhe do projeto? 13)As restrições de tempo real foram especificadas em detalhe suficiente? 14)A precisão e a exatidão dos cálculos foram especificadas? 15)É possível desenvolver um conjunto completo de testes baseados nas informações contidas nas especificações de requisito do software? Se não, que informação falta? As suposições e as dependências foram indicadas claramente? 1)O documento contém toda a informação identificada no escopo para a especificação de requisitos do software?

69 Tipos de Defeitos de Inspeção

70 Relato de Defeitos em Inspeção de Requisitos

71 Teste Unitário Possibilita o teste de métodos de cada classe É uma técnica caixa-branca, onde o conhecimento da estrutura interna do sistema deve ser conhecida Necessita de um bom planejamento de testes A utilização de ferramentas é fundamental A utilização de testes automatizados é pré-requisito para a realização de testes de regressão

72 Base de Consulta: Slides - Marco Antônio Pereira Araújo, D.Sc OBRIGADO!