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

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

QST112 06/2001 IC-UNICAMP Eliane Martins INF321 Fases de Testes.

Apresentações semelhantes


Apresentação em tema: "QST112 06/2001 IC-UNICAMP Eliane Martins INF321 Fases de Testes."— Transcrição da apresentação:

1

2 QST112 06/2001 IC-UNICAMP Eliane Martins INF321 Fases de Testes

3 QST112 06/2001 IC-UNICAMP Eliane Martins Tópicos Testes de unidades Noção de driver e stubs Testes de integração Estratégias Ordem de integração Testes de sistemas Requisitos de qualidade Testes de aceitação Testes de regressão

4 QST112 06/2001 IC-UNICAMP Eliane Martins Testes no Processo de Desenvolvimento

5 QST112 06/2001 IC-UNICAMP Eliane Martins Testes de Unidades e de Integração Testes de unidade Código do componente Espec. do componente Testes de unidade Código do componente Espec. do componente Testes de integração Especificação da arquitetura componente testado componente testado subsistemas integrados......

6 QST112 06/2001 IC-UNICAMP Eliane Martins Testes de Unidades Visam exercitar detalhadamente uma unidade do sistema. Uma unidade é uma entidade executável independente. –Pode representar: Uma função. Uma classe ou um tipo abstrato de dados. Um grupo pequeno de classes. Um componente. Um framework. Um serviço

7 QST112 06/2001 IC-UNICAMP Eliane Martins Modelos de falhas Os Testes de Unidade visam revelar a presença de falhas em: –interfaces: parâmetros de entrada e saída –estruturas de dados: integridade dos dados armazenados –condições de limite: a unidade opera adequadamente nos limites estabelecidos? –tratamento de erros: a descrição do erro é inteligível? A descrição corresponde ao erro encontrado? O tratamento de exceção é adequado?

8 QST112 06/2001 IC-UNICAMP Eliane Martins Componentes de teste Driver –Programa ou classe que aplica os casos de teste ao componente em teste Faz o papel de cliente do componente em teste (CeT). Stub –Implementação temporária, mínima, de um componente usado pelo CeT, com o objetivo de melhorar a controlabilidade e observabilidade do CeT durante os testes. Faz o papel de servidor do CeT. Ambiente de teste (Test Harness) –Sistema que compreende os drivers, stubs, CeT e outras ferramentas de apoio aos testes.

9 QST112 06/2001 IC-UNICAMP Eliane Martins A unidade e suas colaborações Cliente Unidade em Teste Servidor 1Servidor 2 Servidor 3

10 QST112 06/2001 IC-UNICAMP Eliane Martins A unidade e os componentes de teste Casos de teste Driver Unidade em Teste Stub 1Stub 2 resultados Stub 3

11 QST112 06/2001 IC-UNICAMP Eliane Martins Exemplo – componente em teste Tabela CriarTabela( ) LerItem( ) InserirItem( ) RemoverItem( ) MostrarTabela( )

12 QST112 06/2001 IC-UNICAMP Eliane Martins Exemplo - Driver type TabInt = array [ 1.. N, 1.. M ] of integer;... var Tabela: TabInt, x: integer;... criaTab ; leItem ( x ); insereItem (x ); mostraTab ;.... Tabela CriarTabela( ) LerItem( ) InserirItem( ) RemoverItem( ) MostrarTabela( ) Driver

13 QST112 06/2001 IC-UNICAMP Eliane Martins Exemplo Driver OO CasoTeste001 CasoTeste002 CasoTeste CeT Contém instâncias dos casos de teste; Contém instância da classe em teste (CeT); Pode herdar de uma classe abstrata CasoTeste Driver

14 QST112 06/2001 IC-UNICAMP Eliane Martins Exemplo - Fitnesse package fixtures; import br.unicamp.ic.inf321.funcoes.Operacao; import fit.ColumnFixture; public class StringFeatures extends ColumnFixture { public String entrada; public String outraEntrada; public boolean confirmaPalindromo() { return Operacao.isPalindrome(entrada); } public boolean comecaComDigitoOuMaiuscula() { boolean result; result = Operacao.startsWithDigitOrUpper(entrada); return result; } public String eliminaLixo() { return Operacao.stripGarbage(outraEntrada); } !2 Casos de teste para função "Palindromo" | -!fixtures.Palindromo!- | | entrada | isPalindrome() | | bruno || false | | arara | | true | | ana anana ana | | true | | null | | false | | é | | false | | omo ada "oro" ada omo | |true |

15 QST112 06/2001 IC-UNICAMP Eliane Martins Exemplo: stub Tabela Stub type VetorInt = array [1.. N] of integer;... procedure Ordena_Vetor (a : VetorInt);... begin write (Valores fornecidos); for i := 1 to N do write (a [ i ] ); write (Forneça os valores ordenados); for i := 1 to N do read (a [ i ] ); end;

16 QST112 06/2001 IC-UNICAMP Eliane Martins Fases da execução de um caso de teste Preparação (set up): –Cria o que for necessário, configurando os stubs de acordo para que o caso de teste execute conforme o esperado. Execução: –Interage com o CeT, aplicando os testes gerados e observando os resultados obtidos. Verificação: –Compara os resultados obtidos com os esperados. Término (clean up ou tear down): –Termina a execução do CeT e deixa o ambiente de execução de testes no mesmo estado em que estava antes da realização do caso de teste.

17 QST112 06/2001 IC-UNICAMP Eliane Martins Estrutura de testes (xUnit) Prepara (set up) Executa Verifica Termina (clean up) CeT Servi- dores Stubs (ou mocks) cria configura instala caso de teste

18 QST112 06/2001 IC-UNICAMP Eliane Martins Mock Objects Criados pela comunidade XP (em 2000) –Tim Mackinnon, Steve Freeman, Philip Craig. Endo-Testing: Unit Testing with Mock Objects (www.cs.ualberta.ca/~hoover/cmput401/XP-Notes/xp- conf/Papers/4_4_MacKinnon.pdf), apresentada no evento XP2000.(disponível emt Objetivo: –Sistematizar a geração de stubs –Desenvolver uma infra-estrutura para criação de mocks e incorporação dos mesmos aos Testes de Unidade.

19 QST112 06/2001 IC-UNICAMP Eliane Martins Bibliotecas Mock Objects (ou mocks) servem para emular ou instrumentar o contexto (serviços requeridos) de objetos da CeT. Devem ser simples de implementar e não duplicar a implementação do código real. Bibliotecas de mocks podem ser usadas para criar stubs: existem várias APIs para esse fim: –MockObjects (www.mockobjects.com) –EasyMock (www.easymock.com) –MockMaker (www.mockmaker.org ) –djUnit (http://works.dgic.co.jp/djunit/) –...

20 QST112 06/2001 IC-UNICAMP Eliane Martins Mocks x stubs Mocks são voltados para testes classes. Stubs, em princípio, podem ser usados em qqr linguagem (OO ou não). Segundo Martin Fowler, mocks e stubs não são sinônimos: –Mocks podem servir para colocar o objeto da CeT no estado desejado para os testes. –Um stub é uma implementação alternativa da interface do objeto substituído. –Um stub é mais passivo, geralmente retornando dados pré- estabelecidos pelos casos de teste para a CeT. –Mocks podem verificar se o servidor foi chamado adequadamente contêm verificação embutida (assertivas)

21 QST112 06/2001 IC-UNICAMP Eliane Martins Exemplo: classe em teste e uma servidora classe ClasseEmTeste Servidora serv; metodo( ) // chama servidora serv.executa( ) end classe Servidora executa( ) # código complexo end

22 QST112 06/2001 IC-UNICAMP Eliane Martins Exemplo de stub: pseudo-código classe ClasseDeTeste implementa Test::Unit::TestCase classe ServidoraStub executa( ) retorna X end // exemplo_uso_Stub ServidoraStub servidora classeTeste = ClasseEmTeste.new(servidora) assert_equal X, classeTeste.metodo end

23 QST112 06/2001 IC-UNICAMP Eliane Martins Exemplo de mock: pseudo-código classe ClasseDeTeste implementa Test::Unit::TestCase classe ServidoraMock atributo: call_count... call_count = 0 // métodos execute( ) call_count +=1 // conta nº de chamadas ao método end get_call_count ( )... end // exemplo_uso_Mock servidora = ServidoraMock.new classeTeste = ClasseEmTeste.new(servidora) // verifica nº de chamadas ao método servidor assert_equal 1, servidora.get_call_count end

24 QST112 06/2001 IC-UNICAMP Eliane Martins Outro exemplo : o mock // Usado no teste do método: canUserLogin( User, String ), para substituir // o método validatePassword, chamado pelo método em teste. public class MockUser implements User {... // Prepara o que retornar quando validatePassword for chamado public void setValidatePasswordResult( boolean result ) { expectedCalls++; this.returnResult = result; } // Implementação do mock de validatePassword public boolean validatePassword( String password ) { actualCalls++; return returnResult; } public boolean verify() { return expectedCalls == actualCalls; }... } Interface da classe substituída Determina nº esperado de chamadas ao método substituído Conta chamadas ao método substituído Verifica se chamadas de acordo com o esperado

25 QST112 06/2001 IC-UNICAMP Eliane Martins Uso do mock: o caso de teste // Caso de teste usando o MockUser criado anteriormente public void testCanUserLogin() { MockUser user = new MockUser(); user.setValidatePasswordResult( true ); // usa objeto em teste já criado: ot boolean result = ot.canUserLogin( user, "foobar" ); assertTrue("Expected to validate user " + "password \"foobar\"", result ); assertTrue("MockUser not used as expected", user.verify()); } preparação execução verificação

26 QST112 06/2001 IC-UNICAMP Eliane Martins Testes de unidade e de integração Testes de unidade Código do componente Espec. do componente Testes de unidade Código do componente Espec. do componente Testes de integração Especificação da arquitetura componente testado componente testado subsistemas integrados......

27 QST112 06/2001 IC-UNICAMP Eliane Martins Testes de integração Integram unidades já testadas Objetivo: exercitar interações entre unidades

28 QST112 06/2001 IC-UNICAMP Eliane Martins Modelo de falhas de integração Falhas de interpretação: ocorrem quando a funcionalidade implementada por uma unidade difere do que é esperado. –B implementa incorretamente um serviço requerido por A. –B não implementa um serviço requerido por A. –B implementa um serviço não requerido por A e que interfere com seu funcionamento. Falhas devido a chamadas incorretas: –B é chamado por A quando não deveria (chamada extra). –B é chamado em momento da execução indevido (chamada incorreta). –B não é chamado por A quando deveria (chamada ausente). Falhas de interface: ocorrem quando o padrão de interação (protocolo) entre duas unidades é violado. –violação da integridade de arquivos e estruturas de dados globais –tratamento de erros (exceções) incorreto –problema de configuração / versões –falta de recursos para atender a demanda das unidades –objeto incorreto é associado a mensagem (polimorfismo) [Leung e White; Binder99]

29 QST112 06/2001 IC-UNICAMP Eliane Martins Abordagens de integração Não incremental (big-bang): –todas as unidades são integradas de uma só vez esforço de preparação menor esforço para diagnóstico e correção de falhas é maior Incremental –As unidades são integradas gradualmente –Existem inúmeras estratégias Descendente (top-down) Ascendente (bottom-up) Por colaboração Mista Por camadas...

30 QST112 06/2001 IC-UNICAMP Eliane Martins Abordagem incremental A B T1 T2 T3 A B T1 T2 T3 T4 C A B T1 T2 T3 T4 T5 C D

31 QST112 06/2001 IC-UNICAMP Eliane Martins Integração descendente (top-down) Começa com a unidade principal e vai aos poucos integrando as unidades subordinadas Em OO: classes de controle primeiro Utiliza stubs em lugar das unidades subordinadas

32 QST112 06/2001 IC-UNICAMP Eliane Martins Integração ascendente (bottom-up) Começa a integração pelas unidades subordinadas Em OO: começar pelas classes independentes ou que usam poucas servidoras Utiliza drivers em lugar das unidades de controle As unidades de mais baixo nível são testadas primeiro e mais vezes

33 QST112 06/2001 IC-UNICAMP Eliane Martins Integração sanduíche Combina estratégia ascendente e descendente O sistema pode ser visto como uma arquitetura com 3 camadas: –Camada-alvo, no meio –Camada superior, acima da camada alvo –Camada inferior, abaixo da camada alvo Os testes convergem para a camada-alvo Como escolher a camada-alvo? –Objetivo: reduzir nº de stubs e drivers

34 QST112 06/2001 IC-UNICAMP Eliane Martins Ordem de integração Ao integrar vários componentes, é importante determinar a ordem para integrá-los Componentes podem depender de outros por várias razões: –Classes dependem de outras de diferentes formas: Composição e agregação, herança, uso de métodos ou atributos definidos em outras classes –Chamadas a interfaces (API) Dependência necessidade de stubs Análise de dependências: Objetivo: determinar uma ordem de integração que reduza o número de stubs

35 QST112 06/2001 IC-UNICAMP Eliane Martins Exemplo: Diagrama de Classes Cliente Serviço Financeiro Transação Taxas Dinheiro Conta Possui 1..* 0..* Realizado através de 0..* Aplicada a 2..* Usa Contém Usa 1..1 [inspirado em Binder00, ]

36 QST112 06/2001 IC-UNICAMP Eliane Martins Exemplo de dependência: X usa Y Cliente ServiçoFinanceiro Transação Taxas Dinheiro Conta [inspirado em Binder00, ] Array [Int] usa Classe de implementação Não é usada por nenhuma outra classe Não usa nenhuma outra classe Por onde começar a integração para reduzir o número de stubs? Por onde começar a integração para reduzir o número de drivers?

37 QST112 06/2001 IC-UNICAMP Eliane Martins Determinação da ordem de testes (1) Existem várias propostas com base no grafo de dependências: –Caso não existam ciclos: Integração ascendente: para reduzir nº de stubs, começar pelos componentes que não dependem de outros Integração descendente: para reduzir o nº de drivers, começar pelo componente do qual nenhum outro depende

38 QST112 06/2001 IC-UNICAMP Eliane Martins Exemplo – Integração Ascendente Cliente ServiçoFinanceiro Transação Taxas Dinheiro Conta Array [Int] Testa Dinheiro Testa Taxas Testa Conta + Dinheiro Testa Transação+Conta+ Dinheiro+Taxas Testa Cliente+ Conta+ Dinheiro Testa ServiçoFinanc. + Transação + Conta + Dinheiro + Taxas

39 QST112 06/2001 IC-UNICAMP Eliane Martins Exemplo – Integração Sanduíche Cliente ServiçoFinanceiro Transação Taxas Dinheiro Conta Array [Int] Testa Dinheiro Testa Taxas Testa Conta + Dinheiro Testa Transação+Conta+ Dinheiro+Taxas Testa Cliente+ Conta+ Dinheiro Testa ServiçoFinanc. + Transação + Conta + Dinheiro + Taxas Camada alvo Testa ServiçoFinac.

40 QST112 06/2001 IC-UNICAMP Eliane Martins Determinação da ordem de testes (2) Existem várias propostas com base no grafo de dependências: –Caso existam ciclos componentes fortemente acoplados Uma opção: refatore sua arquitetura, para evitar os ciclos, ou Quebre os ciclos: –As propostas variam de acordo com a forma de quebrar os ciclos –Ex.: em OO remover uma associação (herança e agregação não são quebráveis) Quebra da dependência construção de stubs

41 QST112 06/2001 IC-UNICAMP Eliane Martins Exemplo – quebra de ciclos A B C D Testa D Testa B+D Testa C+D Testa A+B+C+D Stub C Integração ascendente:

42 QST112 06/2001 IC-UNICAMP Eliane Martins Análise de dependências Existem ferramentas, como por exemplo: –Class Dependency Analyzer (CDA) –Jdepend –Metrics –...

43 QST112 06/2001 IC-UNICAMP Eliane Martins Próximas do pacote mas pertencem ao Metrics: [http://metrics.sourceforge.net/] Linhas que ligam o pacote a suas classes

44 QST112 06/2001 IC-UNICAMP Eliane Martins Testes de Sistemas Testes de Sistemas (funcionais) Especificação de Requisitos Funcionais funcionalidades testadas subsistemas integrados Manual do Usuário Testes de Sistemas (qualidade) Especificação de Requisitos de Qualid. Testes de Aceitação Requisitos do usuário sistema testado sistema aceito

45 QST112 06/2001 IC-UNICAMP Eliane Martins Fontes de informação para os testes Especificação de requisitos. Protótipo, layouts ou modelos da IU. Políticas da organização implementadas como objetos de negócio, stored procedures ou triggers. Características do produto descritas na literatura. Características e procedimentos descritos na documentação, telas de ajuda ou assistentes de operação (wizards). Manual do usuário. Padrões. Especificação deve ser: completa consistente precisa testável

46 QST112 06/2001 IC-UNICAMP Eliane Martins Testes dos requisitos funcionais Visam verificar se as funcionalidades especificadas foram devidamente implementadas Uso de métodos de testes caixa-preta : –partição de equivalência –valores-limite –tabela de decisão / grafo causa-efeito –modelos de estado –diagramas de casos de uso –cenários –...

47 QST112 06/2001 IC-UNICAMP Eliane Martins Testes dos requisitos de qualidade Visam determinar se a implementação do sistema satisfaz aos requisitos de qualidade (não funcionais) Tipos de testes: –configuração e compatibilidade –desempenho –estresse –tolerância a falhas –segurança –...

48 QST112 06/2001 IC-UNICAMP Eliane Martins Testes de desempenho Visam determinar se implementação satisfaz aos requisitos de desempenho especificados: –configuração de rede –tempo de CPU –limitação de memória –carga do sistema –taxa de chegada de entradas esses requisitos devem ser descritos de forma testável ex.: nº de transações/seg ou tempo de resposta em seg, mseg O sistema é testado em condições reais de operação.

49 QST112 06/2001 IC-UNICAMP Eliane Martins Variações dos testes de desempenho Testes de carga –geralmente associados com sistemas transacionais –usam simuladores de carga para geração de múltiplas transações/usuários simultaneamente Testes de volume –geralmente usados para sistemas batch –consistem na transmissão de um grande volume de informações quando o sistema está com a carga normal ou –uso de arquivos grandes (maior tamanho possível) ou de grande número de arquivos

50 QST112 06/2001 IC-UNICAMP Eliane Martins Teste de estresse Visa ir além dos limites do sistema: nº máximo de usuários simultâneos, nº máximo de processos ou de transações, …: –verificar se o sistema não apresenta um comportamento de risco quando submetido a carga elevada e com um ou mais recursos saturados. Importância: –muitos sistemas apresentam comportamento de risco nessa situação –falhas detectadas são sutis –correções desse tipo de falha podem requerer retrabalho considerável (e.g., rever arquitetura)

51 QST112 06/2001 IC-UNICAMP Eliane Martins Robustez O que é [IEEE Std Glossary]: –O grau em que um sistema ou componente pode funcionar corretamente em presença de entradas inválidas ou sob condições ambientais estressantes. Em suma, pode ser interpretado como a capacidade do sistema em: –Tratar exceções –Tolerar falhas Como medir robustez? –proposta de Robustness Benchmark Como determinar se um sistema é robusto? –Realização de testes de robustez

52 QST112 06/2001 IC-UNICAMP Eliane Martins Testes de robustez Objetivo: –Verificar se o comportamento do sistema é adequado em presença de: Entradas inválidas Entradas inoportunas Condições ambientais anormais –Abordagens: Formais Baseadas em injeção de falhas

53 QST112 06/2001 IC-UNICAMP Eliane Martins Injeção de falhas O que é –Técnica de validação de software que consiste em observar o funcionamento de um sistema em presença de falhas ou erros. Objetivos: –Verificação – remoção de falhas de software no sistema em teste. –Avaliação – obtenção de medidas de atributos de qualidade: confiabilidade, disponibilidade, entre outras.

54 QST112 06/2001 IC-UNICAMP Eliane Martins Esquema típico dos testes de robustez Comportamento especificado Espaço de entrada Software em Teste Espaço de saída Entradas válidas Entradas inválidas ou inoportunas Normal Não especificado Deve retornar erro Operação robusta Falhas de interface Defeito [base: Koopman99]

55 QST112 06/2001 IC-UNICAMP Eliane Martins Falhas de interface: o modelo Ballista Tipo do dadoValores Inteiro0, 1, -1, MaxInt, MinInt Real0., 1., -1., DblMin, DblMax Boolean Inversão de estado (V F, F V) StringNull, string do tamanho da memória virtual, string com caracteres especiais (fim de arquivo, formatação, etc) Descritor de arquivo (tipo inteiro) 0, 1, -1, MaxInt, MinInt descritor de: arquivo aberto para leitura, arquivo aberto para escrita, arquivo vazio, arquivo apagado após o descritor ter sido atribuído Fonte: Projeto Ballista -

56 QST112 06/2001 IC-UNICAMP Eliane Martins Exemplo de falhas de interface – modelo Ballista API: write(int filedesc, const void *buffer, size_t nbytes) Tipos de descritor buffer de tamanho dados de arquivos memória Valores de teste FD_CLOSED FD_OPEN_READ FD_OPEN_WRITE FD_DELETED FD_EMPTYFILE... BUF_SMALL_1 BUF_LARGE_512M BUF_HUGE_2G BUF_NULL BUF_16... SIZE_1 SIZE_ZERO SIZE_NEG SIZE_MININT SIZE_MAXINT... Caso de teste write(FD_CLOSED, BUF_NULL, SIZE-NEG) (inspirado em Koopman2008)

57 QST112 06/2001 IC-UNICAMP Eliane Martins Exemplos de resultados da aplicação de Ballista com Sistemas Operacionais Fonte: Philip Koopman, Kobey DeVale, and John DeVale. INTERFACE ROBUSTNESS TESTING: EXPERIENCES AND LESSONS LEARNED FROM THE BALLISTA PROJECT. Relatório, Sistema operacionalNº funções testadas Nº de funções system killers Exemplo de funções system killer % de defeitos de robustez (normalizada) Linux N/a12,5 Red Hat Linux N/a21,9 Windows 98 SE SP 12377CreateThread, DuplicateHandle, strncpy,... 17,8 Windos CE ,7 Sun JVM (Red Hat Linux ) 2260N/a4,7 Nº de funções chamadas que foram a causa do defeito catastrófico Funções chamadas que foram a causa do defeito catastrófico

58 QST112 06/2001 IC-UNICAMP Eliane Martins Testes de segurança Visam verificar a capacidade do sistema de impedir acesso não autorizado, sabotagem ou outros ataques intencionais Características básicas de segurança são testadas como as outras funcionalidades (logon/logoff, permissões) Testes são geralmente feitos por especialistas ou hackers contratados Testam a capacidade do sistema de resistir a ataques –Quem realiza os testes deve pensar como um atacante

59 QST112 06/2001 IC-UNICAMP Eliane Martins Recomendações para Testes de Segurança Critérios e metodologias para testes de segurança foram propostos por diferentes grupos: –NIST (National Institute of Standards and Technology) Manual descrevendo técnicas a serem usadas nos testes de segurança –OSSTMM (Open Source Security Testing Methodology Manual) desenvolvido pela ISECOM (Institute for Security and Open Methodologies) Manual descreve a metodologia proposta para testes e análise de segurança –OWASP (Open Web Application Security Project) Guia descrevendo melhores práticas para a realização de testes de penetração para aplicações e serviços Web

60 QST112 06/2001 IC-UNICAMP Eliane Martins Testes de Aceitação Testes de Sistemas (funcionais) Especificação de Requisitos Funcionais funcionalidades testadas subsistemas integrados Manual do Usuário Testes de Sistemas (qualidade) Especificação de Requisitos de Qualid. Testes de Aceitação Requisitos do usuário sistema testado sistema aceito

61 QST112 06/2001 IC-UNICAMP Eliane Martins Testes de Aceitação Têm os mesmos objetivos que os testes de sistemas, só que envolvem a participação do cliente ou usuário Escolha dos testes feita pelo cliente Referências: –Manual do Usuário Testes alfa: –realizados por um grupo de usuários no ambiente de desenvolvimento –seu objetivo é determinar se o sistema pode ser liberado Testes beta –realizados por um grupo de usuários em ambiente de operação

62 QST112 06/2001 IC-UNICAMP Eliane Martins Ferramentas Testes manuais: –não recomendável pois número de testes e nº de falhas Ferramentas que podem auxiliar: –capture/playback: permitem armazenar e re-aplicar conjuntos de testes –controle de versões: controlar o sistema e seu histórico de testes –comparação entre resultados do delta e da linha básica –embaralhador de casos de teste: permitem revelar falhas de seqüência de entradas –testes embutidos: assertivas permitem revelar falhas de contrato. Drivers embutidos permitem reduzir custos com manutenção dos testes.

63 QST112 06/2001 IC-UNICAMP Eliane Martins Referências R.Binder. Testing OO Systems. Addison Wesley, 1999, c M.Fowler. Mocks arent stubs. Postado na Internet em julho/ G.Rothermel, M.J.Harrold. A Framework for Evaluating Regression Test Selection Techniques, Proc. 16th. Intl Conf on Sw Eng., Sorrento, Itália, maio/1994, pg M.J.Harrold. Testing Evolving Software. The Journal of Systems and Sw, nº 47, 1999, pp L.A Fondazzi Martimiano. Estudo de Técnicas de Teste de Regressão Baseado em Mutação Seletiva. Dissertação de mestrado. Instituto de Ciências Matemáticas e de Computação - USP/S.Carlos, G. Meszaros. : A Pattern Language for Automated Testing of Indirect Inputs and Outputs using XUnit. PLOP Obtained in jan/2006 at:

64 QST112 06/2001 IC-UNICAMP Eliane Martins Detecção de Ciclos Um aspecto importante do Grafo de Dependências é a possibilidade de detectar ciclos, isto é, elementos que estão fortemente acoplados Elementos que precisam ser refatorados clusters

65 QST112 06/2001 IC-UNICAMP Eliane Martins Eliminação de Ciclos Dependências entre classes: –Dividir a classe, criando uma interface Dependências entre pacotes: –Juntar pacotes –Dividir as classes fortemente acopladas em outro pacote C A A A A B D E A B C D E


Carregar ppt "QST112 06/2001 IC-UNICAMP Eliane Martins INF321 Fases de Testes."

Apresentações semelhantes


Anúncios Google