SCORE 2009 – aula a convite do Prof. Jaelson Castro Marcelo d’Amorim Testes em 2h.

Slides:



Advertisements
Apresentações semelhantes
Teste de Software 01: Introdução
Advertisements

Teste de Software 11: Teste baseado em falhas
Boas Práticas Adotadas em um Projeto de Design de Testes – Um relato de experiência
Desenvolvimento de Plug-ins Orientado a Testes
Adélia Barros Testes de Software Adélia Barros
Fundamentos de Engenharia de SW
Débora da Silva Orientadora: Maria Inés Castiñeira
Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 8 Defeitos e falhas de software Especificação errada: pode não.
Processos de Software Introdução
Tópicos Motivação para teste Por que algumas empresas não testam
Professor Sílder Lamas Vecchi
Desenvolvimento Guiado por Testes
Run Time Safety Checking MO828 – Tópicos em Engenharia de Software II Profa. Eliane Martins.
APRESENTAÇÃO DE ESTÁGIO
Processo Desenvolvimento de Software Tradicional
Test Driven Development
Revisões de Software Parte 1
Abordagem Estratégica ao Teste de Software
TIPOS DE TESTES APLICÁVEIS E NÃO APLICÁVEIS AO PROJETO
Testes – visão geral Vanilson Burégio.
Visão Geral do Desenvolvimento de Sistemas e Papéis no Desenvolvimento de Software Marcely Dias
Escopo do teste.
Introdução ao Teste Unitário com JUnit
Projetar Serviços Vítor Braga –
Slides preparados por Bruno Monteiro e Marcelo dAmorim Execução simbólica - 24/09/2009.
Teste de Software Introdução
DBUnit Framework Componentes: Fábio Gomes Claver Pari Eni Conde
Prof. Esp. Fernando Barreto
IEEE Std IEEE Melhores Práticas para Especificações de Requisitos de Software (ERS)
Prof. Alexandre Vasconcelos
Um Framework Para Testes
How to Break Software Capítulo 3 Taíse Dias Testing from the user Interface.
Teste de Software 03: Teste e o processo de desenvolvimento
Teste de Sistemas de Software
Otimizando sua TI, maximizando seus negócios
Aspect Oriented Programming (AOP)
Aulas 2 e 3 – Java – Prof. Marcelo Heitor # O método main e argumentos na linha de comando; # Fluxo padrão de entrada e saída; # A classe JOptionPane;
Teste de Software Conceitos iniciais.
O que é? É o processo de investigação técnica com intuito de identificar a qualidade, a segurança e a exatidão do software desenvolvido. A validação do.
Gestão de defeitos.
Paulo Borba e Augusto Sampaio Centro de Informática Universidade Federal de Pernambuco Especificação de Sistemas Distribuídos.
Visão de testes em Software Rogério Monteiro, CIn UFPE 02 – Maio
Processos de Software.
Análise e Especificação de Requisitos © 2001 Jaelson CastroInformações Gerais 1 Análise e Especificação de Requisitos - IF119 Centro de Informática Jaelson.
Teste de Sistemas de Software
Teste de Software 14: Geração de teste baseado em modelos: MBT
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE AULA 5
April 05 Prof. Ismael H. F. Santos - 1 Modulo II Verifier Professor Ismael H F Santos –
Ferramenta de Modelagem de Requisitos e Agentes (TAOM4e) Laís Xavier Prof.: Jaelson Castro.
Teste Simbólico Marcelo d’Amorim
Data Flow Testing. Vários critérios de adequação até aqui Baseado em entradas de função (funcional)‏ Baseado na estrutura do programa (estrutural)‏ Baseado.
Critérios de adequação e os diversos tipos de teste
CIn-UFPE Modelos de Maturidade de Testes
April 05 Prof. Ismael H. F. Santos - 1 Modulo I Princípios e Padrões de Projeto de SW em Java Professores Eduardo Bezerra –
Testes de SW Aula 24.
Teste de Software 06: Adequação do Teste Marcelo d’Amorim
Data Flow Testing. Vários critérios de adequação até aqui Baseado em entradas de função (funcional)‏ Baseado na estrutura do programa (estrutural)‏ Baseado.
Antonio Nascimento Roteiro Introdução Objetivos Áreas de Conhecimento Certificações Conclusões Referências.
Estimativa, Teste e Inspeção de Software
André Drummond RA Danilo Benzatti RA
SBMF 2008, Salvador-BA, Brasil Marcelo d'Amorim Fundamentos do Teste de Software.
Um Modelo de Subcontratação de Desenvolvimento de Software
1 Identificando Riscos em Projetos de IP-cores Aluno: Tiago Lins Orientador: Hermano Perrelli 29/03/2007.
Lenylda Albuquerque ISO Processos de Ciclo de Vida de Software Universidade Federal de Pernambuco.
Romeu de Andrade Guimarães 06/12/2008.
Estimativa, Teste e Inspeção de Software
Introdução 1.
Processos de Software Ludimila Monjardim Casagrande 1º Semestre Desenvolvimento e Qualidade.
Teste de Software 04: Que parte devo testar? Marcelo d’Amorim
TESTES DE SOFTWARE – AULA 1 Prof. Me. Ronnison Reges Vidal
Transcrição da apresentação:

SCORE 2009 – aula a convite do Prof. Jaelson Castro Marcelo d’Amorim Testes em 2h

SCORE 2009 – aula a convite do Prof. Jaelson Castro Marcelo d’Amorim Testes em 2h Nota particular: foco de pesquisa é automação de testes (model checking de programas) e depuração.

SCORE 2009 – aula a convite do Prof. Jaelson Castro Marcelo d’Amorim Testes em 2h Mas o foco da aula é a atividade de teste no desenvolvimento de software. Relato de experiência.

Motivação econômica Teste e depuração é responsável por + de 50% do custo total de desenvolvimento [Myers-1979, NIST-report-2002] Defeitos escapados podem ter consequências desastrosas Exemplo: Mars Orbiter (1999), Ariane 5 (2001)

Verificação e Validação (V&V) Theorem proving Static analysis Testing Inspection Walkthroughs

Limitações de Teste Não prova corretude como theorem proving Não é automático como análise estática Porém... É técnica de V&V dominante na indústria Documenta intenções e designs Pode ser combinada com técnicas formais para encontrar erros de forma mais sistemática. Por exemplo, Kernel do Linux [Cadar et al., 2006], Protocolos de rede [d´Amorim et al., 2005], Escalonador de tempo real [Penix et al., 2000], etc.

Definição: Teste (artefato) “A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement” [IEEE, do178b]

Definição: Teste (artefato) “A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement” [IEEE, do178b]

Exemplo public class Customer { String getName() {…} } public class Bank{ static Bank createBank() {…} Customer createCustomer(String name) {…} }

Exemplo public class Customer { String getName() {…} } public class Bank{ static Bank createBank() {…} Customer createCustomer(String name) {…} } Bank bank = Bank.createBank(); String name = “customer1“; Customer cust = bank.createCustomer(name); Assert.assertEquals(name, cust.getName());

Exemplo public class Customer { String getName() {…} } public class Bank{ static Bank createBank() {…} Customer createCustomer(String name) {…} } Bank bank = Bank.createBank(); String name = “customer1“; Customer cust = bank.createCustomer(name); Assert.assertEquals(name, cust.getName()); Entrada e resultado esperado:

Exemplo public class Customer { String getName() {…} } public class Bank{ static Bank createBank() {…} Customer createCustomer(String name) {…} Customer search(String name) {…} } Bank bank = Bank.createBank(); String name = “customer1“; Customer cust = bank.search(name); if (cust == null) { Customer cust = bank.createCustomer(name); Assert.assertEquals(name, cust.getName()); } Condições de execução:

Terminologia: Falta e Falha IEEE STD ( ‏ Fault (falta, bug ou defeito) ‏ : problema Failure (falha, ou erro) ‏ : manifestação do problema Mais detalhes… Software Metrics and Reliability [Rosenberg et al., ISSRE’98]

Quiz: Localize falta e falha no pgm. abaixo // pre condicao: v != null public static void sort(int[] v) { for (int i = 0; i <= v.length; i++) { …v[i] … }

Quiz: Localize falta e falha no pgm. abaixo // pre condicao: v != null public static void sort(int[] v) { for (int i = 0; i <= v.length; i++) { …v[i] … } defeito manifestação do defeito

Teste e Depuração Teste é atividade de localizar falhas! Depuração é atividade de localizar faltas!

Teste e Depuração Teste é atividade de localizar falhas! Depuração é atividade de localizar faltas! No exemplo anterior Atividade de teste revela um erro no uso de v[i]. E.g., com sort(new int[]{}); Depuração localiza o defeito na condição de parada do loop: i <= v.length

Terminologia: suíte e regressão Suíte de testes é o mesmo que conjunto de testes Regressão é o evento de uma falha em um teste que já passou Suíte de regressão serve para capturar falhas com origem na modificação contínua do programa

Integração Drivers Stubs X S1 S2 main Driver SUT Stubs Existem ferramentas para apoiar a substituição de componentes incompletos por stubs (mock). Por exemplo, jmockit.

Enquete: Voce já usou? JUnit3 JUnit4 NUnit Ant Make

Demo JUnit 3 e 4 usando o Eclipse

JUnit cheat-sheet os/junit-README os/junit-README Recomendações Crie diretório fonte separado facilita build Use na classe de teste o mesmo pacote do SUT facilita acesso a campos e localização dos testes Use asserções para confirmar resultado do teste. Não use saída padrão! confirmação automática não comete erros

Testes no desenvolvimento

Gerência de bugs (E.g., bugzilla) Teste contínuo

programadortestador gerente cliente alguns papéis

programadortestador gerente requisitos atribuição cliente

programadortestador gerente Bug tracker

Sistema de bug tracking Objetivo: gerenciar ciclo de vida de bugs Programadores e testadores modificam status de bugs Gerentes tem acesso a informação valiosa Exemplo: frequência de erro por módulo Exemplo: Bugzilla (open-source).

Máquina de estados de um bug no Bugzilla

Teste contínuo Execução ininterrupta de testes Alternativas Unidade (localmente) ver Integração (no servidor) ver Problemas (mais críticos quando usado localmente) Pode impactar performance Pode reportar falso alarmes (devido a modificações incompletas)

Resumo Ferramenta de gerência de erros E.g., bugzilla, clearquest, etc. Ferramenta de integração contínua E.g., continuum, cruisecontrol, etc. Controle de versão E.g., cvs, svn, etc. Ferramenta de build E.g., ant, make, maven, etc.

Recomendações

Recomendações de ferramentas Fortes Controle de versão (svn, cvs, etc.) Build automatizado (make, ant, etc.) Testes automatizados (Junit, Nunit, etc.) Equipes com M desenvolvedores Integração contínua Equipes com N desenvolvedores Bug tracking M > N. Sugestão: M>3 e N>5.

Recomendações de práticas Teste freqüente de regressão (integração contínua ajuda) Antecipa correção de defeito (evita propagação) Ao menos diário e automático (use ant, make, maven, etc.) Construa logo teste de sistema. A seguir, integração e unidade. Use objetos mock para facilitar integração! Documenta intenções e designs (arquitetura) sistema > integração > unidade Custo de manutenção unidade > integração > sistema

Recomendações de práticas Teste freqüente de regressão Ao menos diário Automático (use ant, make, maven, etc.) Antecipa correção de defeito Construa logo teste de sistema. A seguir, integração e unidade. Use objetos mock para facilitar integração! Documenta intenções e designs (arquitetura) sistema > integração > unidade Custo de manutenção unidade > integração > sistema automação pode ajudar

Outras recomendações (implementação) Pair Programming Principalmente em fases iniciais amadurecimento de arquitetura Alternação Cada desenvolvedor deve entender bem cada módulo do sistema