Professional Documents
Culture Documents
Introduo
Na medida em que a complexidade na atividade de desenvolvimento de software vem crescendo, aumenta a demanda por profissionais especializados em engenharia de software, tecnologias da informao e qualidade de software; Destaca-se sobretudo a necessidade de profissionais capazes de verificar se o software funciona de acordo com o que foi especificado e de detectar problemas que eventualmente no tenham sido previstos na especificao;
Introduo
Equipes
de teste devem ser capazes de, a qualquer momento durante o ciclo de desenvolvimento de um sistema, apresentar relatrios sobre os problemas atuais do sistema, cobertura dos testes e situao em aberto;
No
possvel eliminar todos os problemas de um sistema baseado em testes, mas possvel reduzir significativamente a sua ocorrncia;
Tcnicas
Introduo
Determinadas
as reas do produto so extremamente importantes para o usurio ou to propensas a falhas que necessrio test-las com extremo cuidado? o risco envolvido em deixar alguns bugs no resolvidos? componentes to sem importncia que podemos no testar?
Qual
Existem
Introduo
Em
que momento o produto pode ser considerado como adequadamente testado e pronto para ir ao mercado? tempo o produto pode ficar em testes de maneira que o custo dos testes no tenha impacto significativo no retorno financeiro esperado?
Quanto
Descobrir Testar
porque sabemos que somos falveis e isso especialmente verdade no domnio de desenvolvimento de software;
Produtivos e com Qualidade mais defeitos corrigidos a tempo (antes da entrega para o cliente/mercado);
Muito
menos RETRABALHO!
Melhorar
[MYE79], teste o processo de executar o programa com a inteno de encontrar erros, e no de mostrar que ele est correto;
Um
teste que obteve sucesso um teste que encontrou erros no programa analisado;
Princpios de Teste
Uma
Princpios de Teste
Os
de verificar se o programa faz o que deveria fazer, deve-se verificar tambm se o programa faz o que ele no deveria fazer;
10
Princpios de Teste
Casos O O
de teste devem ser cuidadosamente elaborados e documentados; teste no deve ser realizado esperando-se no encontrar erros; teste uma atividade extremamente criativa e intelectualmente desafiadora.
11
Erros de interface com o usurio; Erro no tratamento de erros; Erros de limites; Erro de clculo; Estados iniciais e finais; Controle de Fluxo; Erros de Interpretao dos dados; Erros na relao com o hardware; Fontes e verses; Erros de teste.
12
14
15
Verificao e Validao
A atividade de teste de software um elemento de um tema mais amplo chamado Verificao e Validao (V&V); (V&V); Verificao: refere-se ao conjunto de atividades que garante que o software implementa corretamente um funo especfica (Estamos construindo certo o
produto?);
16
Verificao e Validao
Validao: refere-se ao conjunto de atividades que garante que o software que foi construdo rastrevel s exigncias do cliente (Estamos construindo o produto
certo?)
17
A Atividade de Teste
n
construo dos casos de teste execuo do programa P com os casos de teste construdos anlise do comportamento de P
18
Selecionar o que deve ser medido (quantificado) pelo teste. Antes de desenvolver um teste, preciso identificar as metas do mesmo. Tais metas poderiam ser diferentes (por exemplo, teste de confiabilidade, teste de fidedignidade dos requisitos);
19
Decidir como tudo que est sendo testado deve ser testado. Uma vez conhecido o que deve ser testado, preciso decidir como efetuar um teste relevante. Isso significa que preciso decidir sobre o teste mais apropriado e os itens deste necessrios a serem utilizados;
20
Desenvolver os casos de teste. Para o tipo de itens de teste j aceito, preciso criar uma coleo de casos de teste (situao de teste) para exercitar o sistema sob testes; Determinar quais so os resultados esperados do teste e formar o orculo de teste. Estes so resultados previstos (orculos de teste) para um conjunto de testes;
21
Executar os casos de teste. Durante esta etapa, a pessoa pode utilizar um tipo de software especializado, que ajuda a executar o cdigo e a reunir os resultados do teste; Comparar os resultados do teste com o orculo de teste, documentar os resultados e tomar as devidas providncias.
22
Dvidas?
23
Tcnicas de Teste
Existe uma quantidade bastante grande de tcnicas de teste propostas na literatura. A fim de oferecer uma viso geral, optou-se por apresent-las divididas em trs tipos:
Tcnicas baseadas na anlise esttica no auxiliada por computador; Tcnicas baseadas na especificao do programa (teste caixa-preta ou teste funcional); Tcnica baseada na estrutura do programa (teste caixa-aberta).
24
Anlise Esttica
As tcnicas deste tipo no tm interferncia direta do computador; Argumentam que programas devem ser lidos por pessoas, sendo este um processo revelador de erros e que possibilita o entendimento pleno do programa;
25
Anlise Esttica
Devido natureza informal desses mtodos, verifica-se uma certa incredulidade em relao sua eficincia; Entretanto, baseando-se em uma srie de experincias realizadas por [MYE79], pode-se afirmar que estes mtodos, quando bem aplicados, so responsveis por encontrar de 30% a 70% da quantidade total de erros do programa;
26
Anlise Esttica
Walkthroughs
realizado de forma bastante similar ao processo de inspeo de cdigo; Os participantes do grupo recebem a listagem do programa com alguns dias de antecedncia, a fim de fazer um prconhecimento do mesmo; Os participantes simulam a tarefa do computador;
29
Anlise Esttica
Walkthroughs
Uma pessoa designada anteriormente como testador deve utilizar um conjunto de casos de teste previamente selecionado, com os dados de sada esperados; Estes casos de teste so utilizados para a execuo acompanhada do programa, enquanto que o estado do programa (valores de variveis, arquivos, etc.) so monitorados no papel, por exemplo; Os erros encontrados devem ser registrados, e a soluo no deve ser procurada.
30
Dvidas?
31
Tcnica Funcional
Dados dois nmeros inteiros X e Y, construir um programa que calcule e imprima o valor de X y + 1.
void main() { int x, y, pow; float z, ans; scanf(%d, %d, &x &y); if ( y <= 0 ) pow = y; else pow = -y; z = 1; while (pow-- > 0) z = z*x; if ( y < 0 ) z = 1 / z; ans = z + 1; printf(%-5.2f,ans); }
33
34
Teste Funcional
Teste Funcional
Anlise dos Limites do Domnio
Devem ser considerados valores que esto dentro das classes de equivalncia do domnio de entrada, acima e abaixo deste, considerando sempre dados muito prximos aos limites; Por exemplo, se a classe possui dados que representam valores que devem ser maiores do que 0 e menores ou iguais a 100, dados escolhidos seriam: 0, 1, 100 e 101, j que estes estariam nos limites desta classe;
36
Teste Funcional
Anlise dos Limites do Domnio
Para valores contnuos, escolher dados que representem o maior e o menor valor deste intervalo; Para valores discretos, escolher dados que representem o primeiro e o ltimo valor da lista; Escolher dados que ocasionaro a gerao de dados de sada dentro do domnio de sadas vlidas, mas prximo do limite, bem como dados que geraro sadas fora do domnio, mas prximos do limite.
37
38
Teste Funcional
Anlise dos Limites do Domnio
Caso do tringulo:
Tringulo eqiltero vlido: 2, 2, 2 Tringulo issceles vlido: 3,3,4-3,4,3-4,3,3 Tringulo escaleno vlido: 2,4,3 Tringulo com lado nulo: 3,3,0 mensagem de erro Tringulo com lado negativo: -1, 3, 3 mensagem de erro Tringulo invlido: 1,2,3-30,12,15-10,60,80 mensagem de erro (soma de dois lados < 3o. lado) Tringulo com todos os lados nulos: 0,0,0 mensagem de erro Tringulo com lados no inteiros: 3.3,3.3,4.5 mensagem de erro Omitindo um dos valores: 2,4, ...-...,2,4-2,...,4 mensagem de erro Usando entradas que no so nmeros: 4,b,6-a,b,5,+,*,& mensagem de erro
39
Dvidas?
40
Tcnica Estrutural
Dados dois nmeros inteiros X e Y, construir um programa que calcule e imprima o valor de X y + 1.
void main() { int x, y, pow; float z, ans; scanf(%d, %d, &x &y); if ( y <= 0 ) pow = y; else pow = -y; z = 1; while (pow-- > 0) z = z*x; if ( y < 0 ) z = 1 / z; ans = z + 1; printf(%-5.2f,ans); }
Casos de Teste:
Executar o ramo then de cada comando if Executar o ramo else de cada comando if Executar pelo menos uma vez o lao do comando while Passar pelo comando while sem entrar no lao
42
Tcnica Estrutural
Para a realizao do teste de determinado mdulo, as seguintes etapas devem ser seguidas:
Escolha de um critrio de seleo de caminhos (todosnodos, todos-caminhos); Instrumentao do cdigo fonte; Execuo do programa instrumentado, para determinado conjunto de dados; Avaliao do caminho executado, verificando quais os subcaminhos selecionados constam neste caminho. Os subcaminhos que no foram executados, devem servir de base para a escolha de dados, pois subcaminhos no testados podem representar erros no descobertos.
43
Seqncia
If
While
Repeat
Case
O teste estrutural de mdulo realizado utilizando critrios de seleo de caminhos para a unidade; Estes critrios sugerem uma lista de subcaminhos no grafo de fluxo de controle, que devem ser executados para que o critrio seja satisfeito, ou seja, casos de testes so selecionados, e, atravs de vrias execues do mdulo, avalia-se quais os subcaminhos percorridos nestas execues;
44
Notao
Seqncia
If
While
Repeat
Case
45
Seqncia
If
While
Repeat
Case
46
Seqncia
If
While
Repeat
Case
47
Seqncia
If
While
Repeat
Case
Ou
n n n n
Complexidade Ciclomtica
Seqncia
If
While
Repeat
Case
A complexidade ciclomtica uma mtrica de software que proporciona uma medida quantitativa da complexidade lgica de um programa; Quando usado no contexto do mtodo de teste de caminho bsico, o valor computado da complexidade ciclomtica define o nmero de caminhos independentes do conjunto bsico de um programa e oferece-nos um limite mximo para o nmero de testes que deve ser realizado para garantir que todas as instrues sejam executadas pelo menos uma vez;
49
Complexidade Ciclomtica
Seqncia
If
While
Repeat
Case
Um caminho independente qualquer caminho atravs do programa que introduza pelo menos um novo conjunto de instrues de processamento ou uma nova condio.
50
Complexidade Ciclomtica
Seqncia
If
While
Repeat
Case
Exemplo 1
1
Ramo
2 4 6 7a 7b 8 5 3
51
Complexidade Ciclomtica
Seqncia
If
While
Repeat
Case
os caminhos 1, 2, 3 e 4 (abaixo) compreendem um conjunto bsico para o grafo de fluxo do exemplo 1. Ou seja, se testes puderem ser projetados para forar a execuo desses caminhos, cada instruo do programa ter a garantia de ser executada pelo menos uma vez e cada condio ter sido executada com resultado verdadeiro e falso. Caminho 1: 1-8 Caminho 2: 1-2-3-7b-1-8 Caminho 3: 1-2-4-5-7a-7b-1-8 Caminho 4: 1-2-4-6-7a-7b-1-8
52
Complexidade Ciclomtica
Seqncia
If
While
Repeat
Case
Como saber quantos caminhos procurar? O clculo da complexidade ciclomtica, V(G), para um grafo de fluxo G, oferece uma resposta:
V(G) = E N + 2
onde E o nmero de ramos do grafo de fluxo e N o nmero de ns do grafo de fluxo; Empregado no exemplo o clculo da complexidade ciclomtica pode ser obtida da seguinte forma: V(G) = 11 ramos 9 ns + 2 = 4 Obs.: 4 o nmero de caminhos a serem testados.
53
Uma questo bastante importante a ser considerada a maneira atravs da qual os mdulos sero combinados para o teste do sistema; Mtodo no incremental: o programa completo testado como um todo e o resultado o caos. Quando erros so encontrados, a correo difcil porque o isolamento das causas complicado pela vasta amplitude do programa inteiro; O mtodo incremental realizado de forma top-down e bottomup para a integrao dos mdulos, atravs da utilizao de mdulos drivers e stubs;
54
Estes mdulos especiais (drivers e stubs) so esqueletos dos mdulos do sistema real, utilizados para que a ateno, durante o teste, esteja concentrada em um mdulo especfico, fazendo com que, caso seja encontrado algum erro no teste, este erro necessariamente estar localizado no mdulo sendo testado;
55
Diminui-se consideravelmente o escopo do programa fonte para a depurao mais objetiva dos erros; Um mdulo stub um mdulo chamado pelo mdulo sendo testado; O stub deve conter apenas comandos para o recebimento dos parmetros de entrada e a devoluo de valores, quando for necessrio;
56
Um mdulo driver um mdulo que chama o mdulo que est sendo testado, devendo conter apenas as inicializaes das variveis globais e dos parmetros que sero utilizados para a chamada do mdulo testado;
57
58
Os mdulos so integrados movimentando-se de cima para baixo, atravs da hierarquia de controle, inicinado-se do mdulo de controle principal; Os mdulos subordinados ao mdulo de controle principal so incorporados estrutura de uma maneira depth-first (primeiro pela profundidade) ou breadth-first (primeiramente pela largura);
59
60
O teste de sistema no possui o objetivo de testar funes do sistema completo, mas sim comparar o sistema com seus objetivos originais; O teste de sistema enfatiza a anlise do comportamento da estrutura hierrquica de chamadas de mdulos, verificando se os parmetros esto seguindo o fluxo normal e se seus valores coincidem com os valores esperados;
61
So analisados os valores assumidos pelas variveis globais, considerando, para isso, o fluxo de dados interprocedural do sistema; Esta fase do teste considerada a fase mais complexa, apesar de j se ter acesso a mdulos testados individualmente;
62
Esta complexidade devido ao grande volume de informaes que deve ser gerenciado, bem como o tamanho do cdigo analisado, que, obviamente, maior do que nas etapas de teste de mdulo e de teste de integrao (subsistema).
63
Teste Estrutural
Utiliza informaes sobre os tipos mais comuns de erros cometidos durante o processo de desenvolvimento de software para realizao da Atividade de Teste
64
Teste Estrutural
A nfase da tcnica est fundamentada nos erros que os desenvolvedores podem cometer durante o processo de desenvolvimento do software.
65
Anlise de Mutantes
n
Surgiu na dcada de 70 na YALE University e Georgia Institute of Technology; Filosofia bsica: Hiptese do Programador Competente
66
Anlise de Mutantes
n
A anlise de mutantes um critrio para medir a adequao de casos de teste, onde um conjunto de casos de teste dito adequado se o programa funciona corretamente quando executado com esse conjunto e se todos os programas incorretos tm um comportamento no esperado com alguns desses casos de teste;
67
Anlise de Mutantes
n
O objetivo desse critrio verificar a adequao de um conjunto de casos de teste T em relao a um programa P; Se P funciona corretamente, ento esse sofre pequenas perturbaes, gerando seus mutantes que so executados com T;
68
Anlise de Mutantes
n
Caso o comportamento de P seja diferente de P, ento esse mutante dito morto ou distinguido; Caso contrrio, esse mutante est vivo devido a um entre dois motivos:
69
Anlise de Mutantes
1.
2.
T no suficiente para distinguir o comportamento de P e P e, com isso novos casos de teste devem ser includos em T; P dito equivalente a P, ou seja, para qualquer dado do domnio de entrada o comportamento dos dois programas no difere;
70
Concluses
n
Uma abordagem sistemtica a atividade de teste essencial para aumentar a qualidade do software; Os diversos critrios de teste devem funcionar de forma complementar;
71
Dvidas?
72
A Arte da Depurao
Debugging
O objetivo primordial da depurao descobrir e corrigir a causa de um erro de software. A depurao ocorre em conseqncia de testes bem sucedidos. Embora a depurao possa e deva ser ser um processo disciplinado, ela ainda tem muito de arte.
73
A Arte da Depurao
Debugging
74
O Processo de Depurao
Durante a depurao, encontram-se erros que variam de brandamente perturbadores a catastrficos. medida que as conseqncias de um erro aumentam, a presso para descobrir a causa tambm aumenta.
75
O Processo de Depurao
POR QUE A DEPURAO TO DIFCIL? 1) O sintoma e a causa podem ser geograficamente remotos. Estruturas altamente acopladas agravam essa situao. 2) O sintoma pode desaparecer (temporariamente) quando outro erro corrigido.
76
O Processo de Depurao
3) O sintoma pode, de fato, ser causado por no erros (por exemplo, imprecises de arredondamento). 4) O sintoma pode ser causado por um erro humano que no facilmente rastreado. 5) O sintoma pode ser resultado de problemas de timing, e no problemas de processamento.
77
O Processo de Depurao
6) O sintoma pode ser devido a causas que esto distribudas por uma srie de tarefas que so executadas em diferentes processadores.
78
Depurao
Abordagens Depurao
1- FORA BRUTA: BRUTA: A categoria de depurao por fora bruta provavelmente o mtodo mais comum e menos eficiente de isolar a causa de um erro de software. Aplica-se o mtodo de fora bruta quando tudo o mais falha.
79
Depurao
Abordagens Depurao
1- FORA BRUTA: BRUTA: Usa-se uma filosofia do tipo "deixe que o computador descubra o erro". Por exemplo, so feitas listagens de memria (memory dumps), so inseridas instrues WRITE, etc. Espera-se encontrar, em algum lugar do emaranhado de informaes, uma pista que possa levar causa de um erro.
80
Depurao
Abordagens Depurao
1- FORA BRUTA: BRUTA: No obstante, a massa de informaes produzida possa levar ao sucesso, mais freqentemente ela conduz a tempo e esforo desperdiados.
81
Depurao
Abordagens Depurao
2- BACKTRACKING: uma abordagem que pode ser usada com sucesso em pequenos programas. Iniciando-se no local em que o sintoma foi descoberto, o cdigo fonte rastreado para trs (manualmente) at que o local da causa seja encontrado.
82
Depurao
Abordagens Depurao
2- BACKTRACKING: Infelizmente, medida que o nmero de linhas de cdigo aumenta, o nmero de potenciais caminhos de backtracking pode tornar-se incontrolavelmente alto.
83
Depurao
Abordagens Depurao
3- ELIMINAO DA CAUSA: CAUSA: Os dados relacionados ocorrncia de erros so organizados para isolar potenciais causas. Uma "hiptese de causa" imaginada e os dados so usados para provar ou refutar a hiptese.
84
Depurao
Abordagens Depurao
3- ELIMINAO DA CAUSA: CAUSA: Alternativamente, uma lista de todas as causas possveis desenvolvida e testes so realizados para eliminar cada uma. Se os testes iniciais indicarem que uma hiptese de causa apresenta possibilidades, os dados so refinados, numa tentativa de isolar o bug.
85
Depurao
Concluses
As abordagens de depurao podem complementadas com ferramentas depurao:
ser de
Depurao
Concluses
Um poderoso aliado depurao so "outras pessoas". O conceito de "programao no egostica"de Weinberg deve ser ampliado para "depurao no egostica".
87
Depurao
Concluses
Assim que um erro encontrado, ele deve ser corrigido, porm a correo de um erro pode introduzir outros erros. Assim, deve-se fazer 3 perguntas simples, sempre que se realizar uma "correo" que remover a causa de um erro:
1- A causa do bug reproduzida em outra parte do programa? 2- Qual "bug seguinte" poderia ser introduzido pelo reparo que se est prestes a fazer? 3- O que poderia ter sido feito para eliminar este bug desde o princpio?
88
Dvidas?
89
92