INF321 Fases de Testes.

Apresentação em tema: "INF321 Fases de Testes."— Transcrição da apresentação:

1 INF321 Fases de Testes

2 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

3 Testes no Processo de Desenvolvimento

4 Testes de Unidades e de Integração
Especificação da arquitetura Testes de unidade Código do componente Espec. do componente testado subsistemas integrados . Testes de integração Testes de unidade Código do componente Espec. do componente testado

5 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

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

7 Componentes de teste Driver Stub Ambiente de teste (Test Harness)
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.

8 A unidade e suas colaborações
Cliente Unidade em Teste Servidor 1 Servidor 2 Servidor 3

9 A unidade e os componentes de teste
Driver Casos de teste Unidade em Teste resultados Stub 1 Stub 2 Stub 3

10 Exemplo – componente em teste
CriarTabela( ) LerItem( ) InserirItem( ) RemoverItem( ) MostrarTabela( ) Tabela O driver é um programa específico que implementa um caso de teste.

11 Exemplo - Driver Tabela
type TabInt = array [ 1 .. N, 1 .. M ] of integer; ... var Tabela: TabInt, x: integer; criaTab ; leItem ( x ); insereItem (x ); mostraTab ; .... CriarTabela( ) LerItem( ) InserirItem( ) RemoverItem( ) MostrarTabela( ) Driver Tabela

12 Exemplo Driver OO ... CasoTeste CeT Driver CasoTeste001 CasoTeste002
Contém instâncias dos casos de teste; Contém instância da classe em teste (CeT); Pode herdar de uma classe abstrata ...

13 Exemplo - Fitnesse !2 Casos de teste para função "Palindromo"
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 | Driver: forma tabular + fixtures

14 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; Stub

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

16 Estrutura de testes (xUnit)
Servi- dores caso de teste Stubs (ou mocks) cria Prepara (set up) Executa Verifica Termina (clean up) configura instala CeT

17 Mock Objects Criados pela comunidade XP (em 2000) Objetivo:
Tim Mackinnon, Steve Freeman, Philip Craig. “Endo-Testing: Unit Testing with Mock Objects” ( 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.

18 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 ( EasyMock ( MockMaker ( ) djUnit ( ...

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

20 Exemplo: classe em teste e uma servidora
classe ClasseEmTeste Servidora serv; metodo( ) // chama servidora serv.executa( ) end classe Servidora executa( ) # código complexo

21 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

22 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 ( ) // 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

23 Outro exemplo : o mock Interface da classe substituída
// 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

24 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

25 Testes de unidade e de integração
Especificação da arquitetura Testes de unidade Código do componente Espec. do componente testado subsistemas integrados . Testes de integração Testes de unidade Código do componente Espec. do componente testado

26 Testes de integração Integram unidades já testadas
Objetivo: exercitar interações entre unidades

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

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

29 Abordagem incremental

30 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

31 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

32 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

33 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

34 Exemplo: Diagrama de Classes
Cliente Serviço Financeiro Transação Taxas Dinheiro Conta  Possui Possui  1 ..* 0 ..* Realizado através de  Aplicada a  2 ..* Usa  Contém  Usa  1 ..1 [inspirado em Binder00, ]

35 Exemplo de dependência: X usa Y
ServiçoFinanceiro  Não é usada por nenhuma outra classe Por onde começar a integração para reduzir o número de stubs? Transação Cliente Taxas Conta Por onde começar a integração para reduzir o número de drivers? Array[Int]: classe genérica usada para conter as taxas aplicáveis. Essa classe não aparece no diagrama pois é considerada detalhe de implementação, mas aparece no código. Array [Int] Dinheiro  Não usa nenhuma outra classe [inspirado em Binder00, ] Classe de implementação

36 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

37 Exemplo – Integração Ascendente
Cliente ServiçoFinanceiro Transação Taxas Dinheiro Conta Array [Int] Testa Cliente+ Conta+ Dinheiro Testa Conta + Dinheiro Testa Dinheiro Testa ServiçoFinanc. + Transação + Conta + Dinheiro + Taxas Ver no diretório Transpar/VV&T/testing_integration_udallas Testa Transação+Conta+ Dinheiro+Taxas Testa Taxas

38 Exemplo – Integração Sanduíche
Cliente ServiçoFinanceiro Transação Taxas Dinheiro Conta Array [Int] Camada alvo Testa Cliente+ Conta+ Dinheiro Testa Conta + Dinheiro Testa Dinheiro Testa ServiçoFinanc. + Transação + Conta + Dinheiro + Taxas Testa Transação+Conta+ Dinheiro+Taxas Testa Taxas Testa ServiçoFinac.

39 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 As propostas ainda são experimentais, portanto ainda não têm ferramentas de apoio.

40 Exemplo – quebra de ciclos
Integração ascendente: A B C D Testa D B+D C+D A+B+C+D Stub C

41 Análise de dependências
Existem ferramentas, como por exemplo: Class Dependency Analyzer (CDA) Jdepend Metrics ...

42 Metrics: [http://metrics.sourceforge.net/]
 “Próximas” do pacote  mas pertencem ao  Linhas que ligam o pacote a suas classes  Metrics: [

43 Requisitos Funcionais
Testes de Sistemas Especificação de Requisitos de Qualid. Especificação de Requisitos Funcionais Manual do Usuário subsistemas integrados Testes de Sistemas (funcionais) funcionalidades testadas Testes de Sistemas (qualidade) sistema testado sistema aceito Testes de Aceitação Requisitos do usuário

44 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

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

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

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

48 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

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

50 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

51  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

52 Injeção de falhas O que é Objetivos:
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.

53 Esquema típico dos testes de robustez
Comportamento especificado Espaço de entrada Espaço de saída Operação robusta Normal Não especificado Deve retornar erro Entradas válidas Entradas inválidas ou inoportunas Software em Teste Defeito Falhas de interface [base: Koopman99]

54 Falhas de interface: o modelo Ballista
Tipo do dado Valores Inteiro 0, 1, -1, MaxInt, MinInt Real 0., 1., -1., DblMin, DblMax Boolean Inversão de estado (V F, F  V) String Null, 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 Existem várias propostas para inj de falhas de interface. Muito utilizado: modelo Ballista Fonte: Projeto Ballista -

55 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 SIZE_1 SIZE_ZERO SIZE_NEG SIZE_MININT SIZE_MAXINT ... 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 ... Valores de teste Na metodologia Ballista, os dados de teste são obtidos de acordo com o tipo do dado Caso de teste write(FD_CLOSED, BUF_NULL, SIZE-NEG) (inspirado em Koopman2008)

56 Exemplos de resultados da aplicação de Ballista com Sistemas Operacionais
Sistema operacional Nº funções testadas Nº de funções “system killers” Exemplo de funções “system killer” % de defeitos de robustez (normalizada) Linux 190 N/a 12,5 Red Hat Linux 2.2.5 183 21,9 Windows 98 SE SP 1 237 7 CreateThread, DuplicateHandle, strncpy, ... 17,8 Windos CE 2.11 179 28 13,7 Sun JVM (Red Hat Linux ) 226 4,7 “system killer”: testes de robustez que causaram defeito catastrófico: colapso (crash) ou bloqueio (hang) do S.Op. Em alguns casos conseguiram localizar a falha, e geralmente a falha estava em uma função, designada como “system killer function”. Nº de funções chamadas que foram a causa do defeito catastrófico Funções chamadas que foram a causa do defeito catastrófico Fonte: Philip Koopman, Kobey DeVale, and John DeVale. INTERFACE ROBUSTNESS TESTING: EXPERIENCES AND LESSONS LEARNED FROM THE BALLISTA PROJECT. Relatório, 2008.

57 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

58 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

59 Requisitos Funcionais
Testes de Aceitação Especificação de Requisitos de Qualid. Especificação de Requisitos Funcionais Manual do Usuário subsistemas integrados Testes de Sistemas (funcionais) funcionalidades testadas Testes de Sistemas (qualidade) sistema testado sistema aceito Testes de Aceitação Requisitos do usuário

60 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

61 Ferramentas Testes manuais: Ferramentas que podem auxiliar:
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.

62 Referências R.Binder. Testing OO Systems. Addison Wesley, 1999, c M.Fowler. Mocks aren’t stubs. Postado na Internet em julho/ G.Rothermel, M.J.Harrold. “A Framework for Evaluating Regression Test Selection Techniques”, Proc. 16th. Int’l 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, 1999. G. Meszaros. : A Pattern Language for Automated Testing of Indirect Inputs and Outputs using XUnit. PLOP Obtained in jan/2006 at:

63 Detecção de Ciclos Elementos que precisam ser refatorados
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

64 Eliminação de Ciclos A A’’ 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’ B D E