Teste de Software - UNESP: Câmpus de São José do Rio Preto - Instituto de … · Se a entrada é...
-
Upload
duongthien -
Category
Documents
-
view
214 -
download
0
Transcript of Teste de Software - UNESP: Câmpus de São José do Rio Preto - Instituto de … · Se a entrada é...
UNIVERSIDADE ESTADUAL PAULISTAINSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA
Slide 1
Teste de Software
Engenharia de Software
2o. Semestre de 2006
Slide 2
Testes para a detecção de defeitos
Testar programas para expor defeitos latentes no software antes de ser entregue.
Slide 3
Tópicos
Testes para a detecção de defeitosTestes de integraçãoTestes orientados a objetos
Slide 4
O processo de teste
Testes de componentes Testes de componentes de programas individuais.Usualmente os programadores assumem a responsabilidade pelo teste de seu código (exceto em caso de sistemas críticos).Testes são derivados da experiência do desenvolvedor.
Testes de integraçãoTestes de grupos de componentes integrados para formar subsistemas ou sistemas completos.Uma equipe independente de teste fazem o teste de integração.Os testes são baseados em uma especificação do sistema.
Slide 5
Teste para detecção de defeitos
O objetivo de testes para a detecção de defeitos é revelar defeitos latentes nos programas.Um teste bem sucedido é aquele que revela a presença de um defeito (faz com que o programa se comporte de maneira anômala)Testes mostram a presença e não a ausência de defeitos.
Slide 6
Teste para detecção de defeitosA única maneira de mostrar que um programa está correto é o teste exaustivoteste exaustivo. Contudo, teste exaustivo é impraticávelimpraticável.Testes devem ser baseados em um subconjuntosubconjunto de possíveis casos de teste.Políticas devem ser utilizadas para escolher esse conjunto.
Ex: todas as declarações do programa devem ser testadas pelo menos uma vezTodas as funções de sistema acessados por meio de menus devem ser testadas, etc.
Slide 7
Dados de teste e Casos de teste
Dados de testeDados de teste entradas criadas para testar o sistema.Casos de testeCasos de teste Entradas para testar o sistema e saídas esperadas para essas entradas (quando o sistema opera de acordo com suas especificações) .
Slide 8
Processo de teste para a detecção de defeitos
Design testcases
Prepare testdata
Run programwith test data
Compare resultsto test cases
Testcases
Testdata
Testresults
TestreportsCasos
de teste
Casosde teste Dados
de teste
Dadosde teste Resultados
de teste
Resultadosde teste Relatórios
de teste
Relatóriosde teste
Projetar casosde teste
Projetar casosde teste Preparar dados
de teste
Preparar dadosde teste Executar programa
com dados de teste
Executar programacom dados de teste Comparar resultados
com os casos de teste
Comparar resultados com os casos de teste
Slide 9
Teste de caixa preta
Uma abordagem de teste onde o programa é considerado como uma “caixa-preta”.Os casos de teste para testar o programa são baseados na especificação do sistema.O planejamento dos testes podem começar nos primeiros estágios do processo de software.
Slide 10
Teste Caixa preta
IeEntrada de Dados de teste
Problema: selecionar entradas Ie
Entradas que provocamcomportamento anômalo
Saída dos resultados de teste
Oe
SISTEMASISTEMA
Saídas que revelam apresença de defeitos
Slide 11
Particionamento de equivalência(abordagem sistemática para seleção de dados de teste)
Dados de entrada e resultados de saída se dividem em diferentes classes, por ex: números positivos, números negativos, strings, etc.Cada uma dessas classes é uma partição de equivalência onde o programa se comporta de maneira equivalente para cada membro da classeCasos de teste devem ser escolhidos de cada partição.
Slide 12
(abordagem sistemática para seleção de dados de teste)
Particição de Equivalência
System
Outputs
Invalid inputs Valid inputsEntradas inválidas Entradas válidas
Sistema
Saídas
Slide 13
(abordagem sistemática para seleção de dados de teste)
Particionamento de equivalência
Entradas e saídas do sistema são particionadasem “conjuntos de equivalência”
Se a entrada é um inteiro de 5 dígitos entre 10.000 e 99.999, partições de equivalência são números < 10.000, números entre 10.000 e 99. 999 e números > 99. 999
Escolher casos de teste nos limites das partições:
00000, 09.999, 10.000, 50.0000, 99.999, 100.000
Slide 14
(abordagem sistemática para seleção de dados de teste)
Partições de equivalência
Between 10000 and 99999Less than 10000 More than 99999
999910000 50000
10000099999
Input values
Between 4 and 10Less than 4 More than 10
34 7
1110
Number of input values
O programa aceita entre 4 a 10 entradas, que são números inteiros de cinco dígitos, maiores do que 10.000 e menores que 99.999
Menos de 4 Entre 4 e 10 Mais de 10
Números de valores de entrada
Valores de entrada
Menos de 10 000 Entre 10 000 e 99 999 Mais e 99 999
Slide 15
Especificação de uma rotina de busca
procedure Busca (chave : ELEM ; T: ELEM_ARRAY;Achou : in out BOOLEAN; L: in out ELEM_INDEX) ;
Pré-condição-- a seqüência tem pelo menos um elementoT’FIRST <= T’LAST
Pós-condição-- O elemento é encontrado e é referenciado por L( Achou and T (L) = chave)
ou-- O elemento não está na seqüência( not achou andnot (existe i, T’FIRST <= i <= T’LAST, T (i) =chave ))
Slide 16
Rotina de busca - partições de entrada
Entradas que estão de acordo com a pré condição: seqüência com no mínimo um elemento.Entradas onde a pré condição não vale.Entradas onde o elemento chave é um elemento da seqüência.Entradas onde o elemento chave não é um membro da seqüência.
Slide 17
Diretrizes de testes (no caso do exemplo usado)
Teste o software com seqüências que possuem somente um único valor.Use diferentes seqüências, de diferentes tamanhos, em diferentes testes.Derive testes de maneira que o primeiro, o médio e o último elemento da seqüência sejam acessados.Teste com seqüências de comprimento zero.
Slide 18
Rotina de busca - partições de equivalência
V etor E lem ento V alor ún ico E stá na seqüência
V a lor ún ico N ão está na seqüência
M ais que 1 va lo r P rim e iro e lem ento está na seqüênciaM ais que 1 va lo r Ú ltim o e lem ento está na seqüênc ia M ais que 1 va lo r E lem ento m éd io está na seqüênc ia
M ais que 1 va lo r N ão está na seqüência
Seqüência de entradas (T) Chave (key) Saídas (Found, L)17 17 Verdadeiro, 117 0 Falso, ??17, 29, 21, 23 17 Verdadeiro, 141, 18, 9, 31, 30, 16, 45 45 Verdadeiro, 7
17, 18, 21, 23, 29, 41, 38 23 Verdadeiro, 421, 23, 29, 33, 38 25 Falso, ??
Slide 19
Teste Estrutural
Algumas vezes chamado testes de “caixa branca”.Derivação de casos de teste de acordo com a estrutura do programa. O conhecimento do programa é usado para identificar casos de testes adicionais.
Exemplo: exercitar todas as declarações do programa
Slide 20
Testes caixa branca
Componentcode
Testoutputs
Test data
DerivesTests
Componentcode
Testoutputs
Test data
DerivesTests
Dadosde teste
Dadosde teste
Código decomponente
Código decomponente Saídas
do teste
Saídasdo teste
Testa Deriva
Slide 21
Testes de Caminho
O objetivo dos testes de caminho é garantir que o conjunto de casos de teste é tal que cada caminho do programa é executado no mínimo uma vez. Para o teste de caminho, elabora-se um grafo de fluxo de programa, onde os nós, representam os pontos de decisão do programa, e os arcos representam o fluxo de controle.
Slide 22
Grafos de fluxo de programaModelo em esqueleto de todos os caminhos do programa.Consiste em nós que representam decisões e em ramos que mostram o fluxo de controle.É construído através do código fonte, onde substitui-se os comandos por nósnós e desvios pelos arcosarcos (ou ramos) do grafo.Declarações seqüenciais são ignoradas na construção do grafo de fluxo.
Slide 23
Grafos de fluxo de programa
Em um comando condicional, cada ramo é mostrado como um caminho separado, e laços são indicados por uma seta fazendo o loop de volta para o nó de condição do laço.Usado como base para calcular o número de caminhos independentes no programa.Caminho independente - caminho que atravessa pelo menos um novo ramo no grafo de fluxo.
Slide 24
Complexidade Ciclomática
O número de caminhos independentes no código é igual à complexidade ciclomáticacomplexidade ciclomática.Cálculo da Complexidade ciclomática:
CC = Número de ramos - Número de nós + 2.Complexidade ciclomática determina o número de casos de teste mínimo para testar adequadamente todos os caminhos independentes do programa.
Busca binária (Java)
class BinSearch { // Esse é um encapsulamento de uma função de busca // binária que considera um vetor de objetos ordenados e uma chave // e retorna um objeto com 2 atributos, chamados // index – o valor do índice de vetor // found – um booleano que indica se uma chave está ou não no vetor // A chave será –1 se o elemento não for encontrado public static void Bu ( int key, int [] elemArray, Result r ) { int bottom = 0 ; int top = elemArray.length - 1 ; int mid ; r.found = false ; r.index = -1 ; while ( bottom <= top ) { mid = (top + bottom) / 2 ; if (elemArray [mid] == key) { r.index = mid ; r.found = true ; return ; } // if part else { if (elemArray [mid] < key) bottom = mid + 1 ; else top = mid - 1 ; } } //while loop } // search } //BinSearch
Grafo de fluxo para Busca Binária
1
2
3
4
65
7
while bottom <= top
if (elemArray [mid] == key
(if (elemArray [mid]< key8
9
bottom > top
Slide 27
Caminhos independentes
1, 2, 3, 8, 91, 2, 3, 4, 6, 7, 21, 2, 3, 4, 5, 7, 21, 2, 3, 4, 6, 7, 2, 8, 9Casos de teste devem ser projetados para executar todos esses caminhos.
Exercício: elaborar um conjunto de dados que execute os caminhos independentes acima.
Slide 28
Teste de Caminhos
Útil se usado com cuidado. Não implica que o programa foi adequadamente testado - embora todos os caminhos independentes são executados, todas as combinações possíveis de caminhos não são executadas.
Slide 29
Testes de integração
Testes feitos em sistemas completos ou subsistemas, compostos de componentes integrados.Testes de integração devem ser desenvolvidos a partir da especificação do sistema.A maior dificuldade é a localização de erros descobertos durante o processo.Integração incremental reduz esse problema.
Slide 30
Testes de integração incremental
T3
T2
T1
T4
T5
A
B
C
D
T2
T1
T3
T4
A
B
C
T1
T2
T3
A
B
Test sequence1
Test sequence2
Test sequence3
Seqüência de teste 1
Seqüência de teste 2 Seqüência
de teste 3
Slide 31
Abordagens para o teste de integração
Teste de integração top-downComeça com os componentes de alto nível de um sistema, e a integração se dá de cima para baixo em uma hierarquia de componentes. Componentes individuais em um nível mais baixo na hierarquia são representados por stubs.
Teste de integração bottom-upEnvolve integrar e testar os módulos de nível inferior na hierarquia e, então, subir na hierarquia de módulos, até que o módulo final seja testado.
Na prática, a maioria das integrações envolve a combinação dessas estratégias.
Slide 32
Testes de integração Top-down
Level 2Level 2Level 2Level 2
Level 1 Level 1Testingsequence
Level 2stubs
Level 3stubs
. . .Seqüência de testes
Stubs do nível 2
Stubs do nível 3
Slide 33
Testes de integração bottom-up
Level NLevel NLevel NLevel NLevel N
Level N–1 Level N–1Level N–1
Testingsequence
Testdrivers
Testdrivers
Seqüência de testes
Driversde teste
Driversde teste
Slide 34
Vantagens e desvantagens das abordagens de teste
Validação da arquiteturaOs testes top-down oferecem maior probabilidade de descobrir erros na arquitetura de sistema, em um estágio inicial do processo de desenvolvimento.
Demonstração do sistemaOs testes de integração top-down permite a demonstração de um sistema de trabalho limitado em uma fase inicial do desenvolvimento.
Implementação de testeTestes top-down é necessário a produção de stubs(programas que simulam níveis inferiores).Testes bottom-up necessitam de drives .
Observação de testeProblemas com ambas as abordagens. Código extra são necessários para poder observar os testes.
Slide 35
Testes de interface
Ocorrem quando módulos ou subsistemas são integrados para criar sistemas maiores.Objetivo é detectar erros devido a erros ou suposições inválidas sobre interfaces.Particularmente importante para o desenvolvimento orientado a objeto, uma vez que os objetos são definidos por suas interfaces
Slide 36
Testes de InterfaceTestcases
BA
C
Casos de teste
Slide 37
Diretrizes para os testes de interface
Projete conjunto de testes em que o valor dos parâmetros para os componentes externos esteja nos limites extremos.Sempre teste parâmetros ponteiros com ponteiros nulos.Em sistemas de passagem de mensagem, projete testes que gerem muito mais mensagens que é provável ocorrer na prática (teste de estresse)estresse).Em um sistemas de memória compartilhada, varie a ordem na qual os componentes são ativados.
Slide 38
Testes de estresse
Testam desempenho e confiabilidade:Exercitam o sistema além de sua carga máxima de projeto, até que o sistema falhe. Testa o comportamento de falha do sistema. É importante que a falha não cause a corrupção de dados ou a perda inesperada de serviços do usuário.Particularmente relevantes para sistemas distribuídos com base em redes de processadores, que podem exibir uma degradação severa quando a rede se torna sobrecarregada.
Slide 39
Testes orientados a objetos
Os componentes a serem testados são classes de objetos que são instanciadas como objetos.Diferentes de teste funcional, pois:
Objetos individuais são, muitas vezes, maiores do que funções isoladas. Abordagens de teste de caixa-branca devem ser estendidas.Testadores podem não ter acesso ao código fonte do componente para análise, no caso de reuso de objetosNão existe um nível superior óbvio para integração e teste top-down.
Slide 40
4 Níveis de teste
Testar as operações associadas com os objetos.Testar classes de objetos individuais.Testar agrupamentos de objetos que cooperam entre si.Testar o sistema orientado a objeto completo.
Slide 41
Pontos chaveÉ mais importante testar as partes do sistema mais comumente utilizadas do que as partes que são exercitadas raramente.Partição de equivalênciaPartição de equivalência é uma maneira de derivar casos de teste. Partições são conjuntos de dados onde o programa deve se comportar de maneira equivalente.Teste de caixa pretaTeste de caixa preta é baseado na especificação do sistema. Não precisa analisar o código fonte.Teste estruturalTeste estrutural baseia-se na análise do programa para determinar os caminhos a serem executados e a seleção de casos de teste.
Slide 42
Pontos chaveOs testes de integraçãotestes de integração se concentram no teste das interações entre os componentes.Os testes de interfacetestes de interface procuram descobrir defeitos nas interfaces ou nos módulos. Para testar as classes de objetostestar as classes de objetos, deve-se testar todas as operações, atributos e estados.Sistemas orientados à objetos devem ser integradosintegrados em torno de clustersclusters de objetos.