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

Apresentação em tema: "SCORE 2009 – aula a convite do Prof. Jaelson Castro Marcelo d’Amorim Testes em 2h."— Transcrição da apresentação:

1 SCORE 2009 – aula a convite do Prof. Jaelson Castro Marcelo d’Amorim damorim@cin.ufpe.br Testes em 2h

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

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

4 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)

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

6 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.

7 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]

8 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]

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

10 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());

11 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:

12 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:

13 Terminologia: Falta e Falha IEEE STD. 982.2-1988 (http://standards.ieee.org/) ‏http://standards.ieee.org/ 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]

14 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] … }

15 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

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

17 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

18 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

19 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.

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

21 Demo JUnit 3 e 4 usando o Eclipse

22 JUnit cheat-sheet http://www.cin.ufpe.br/~damorim/teaching/testing/dem os/junit-README http://www.cin.ufpe.br/~damorim/teaching/testing/dem 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

23 Testes no desenvolvimento

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

25 programadortestador gerente cliente alguns papéis

26 programadortestador gerente requisitos atribuição cliente

27 programadortestador gerente Bug tracker

28 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). http://www.bugzilla.org/

29 Máquina de estados de um bug no Bugzilla

30 Teste contínuo Execução ininterrupta de testes Alternativas Unidade (localmente) ver http://groups.csail.mit.edu/pag/continuoustesting/ Integração (no servidor) ver http://www.javaworld.com/javaworld/jw-11-2006/jw-1101-ci.html Problemas (mais críticos quando usado localmente) Pode impactar performance Pode reportar falso alarmes (devido a modificações incompletas)

31 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.

32 Recomendações

33 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.

34 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

35 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

36 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