3.3 Teste de Software

Prévia do material em texto

Teste de Software
© Prof. Raul Sidnei Wazlawick
UFSC-CTC-INEUFSC-CTC-INE
2010
Fator Humano
• Por melhores que sejam as técnicas de 
modelagem e especificação e software, por mais 
disciplinada e experiente que seja a equipe 
sempre haverá um fator que faz com que o teste sempre haverá um fator que faz com que o teste 
de software seja necessário: o erro humano. 
• Beizer (1990) menciona que é um mito pensar 
que bons desenvolvedores bem concentrados 
com boas ferramentas serão capazes de 
desenvolver software sem erros.
Lei de Murphy na 
Indústria de Software
• Se alguma coisa pode sair errado, sairá.
– no pior momento possível.
• Se tudo parece estar indo bem é porque você 
não olhou direito.não olhou direito.
• A natureza sempre está a favor da falha 
oculta.
• Durante muitos anos a tarefa de teste de 
software foi considerada como um castigo 
para os programadores. 
• O teste era considerado como uma tarefa • O teste era considerado como uma tarefa 
ingrata porque se esperava justamente que os 
desenvolvedores construíssem software de 
boa qualidade. 
• A necessidade de testes declarava justamente 
esta incapacidade que era indesejada.
Caricatura de Disciplina de Teste
• “depois eu testo”;
• “na minha máquina funcionou...”;
• “vamos deixar os testes para a próxima fase”;
• “temos que entregar o produto na semana • “temos que entregar o produto na semana 
que vem”, etc.
Porém, as coisas mudaram
• Conforme visto em alguns modelos de ciclo de 
vida, a disciplina de teste passou a ser 
considerada importante e parte integrante do 
processo de desenvolvimento de software. 
• Os métodos ágeis também incorporaram o 
teste de software como uma atividade crítica, 
propondo inclusive que os casos de teste 
passassem a ser escritos antes das unidades 
de software que iriam testar.
• Além disso, grandes empresas 
desenvolvedoras de software passaram a 
contratar o teste de software de forma 
independente, ou seja, os responsáveis pelo independente, ou seja, os responsáveis pelo 
teste não são mais apenas os 
desenvolvedores, mas equipes especialmente 
preparadas para executar esta tarefa.
Teste e Depuração
• Convém distinguir teste de depuração: 
– O teste consiste em identificar que o software 
contém um erro; 
– A depuração consiste em localizar a causa do erro. – A depuração consiste em localizar a causa do erro. 
• essa identificação nem sempre é simples.
Objetivos do teste
• Os objetivos dos testes podem variar bastante e vão 
desde verificar se as funções mais básicas do software 
estão bem implementadas até validar os requisitos 
junto ao cliente. 
• A classificação de testes mais empregada considera 
que existem testes de:que existem testes de:
– Unidade
– Integração
– Sistema
– Aceitação
– Operação
– Regressão.
Famílias de Teste
• Testes caixa-branca: 
– são testes que são executados com conhecimento 
do código implementado, ou seja, eles testam a 
estrutura do programa em si.estrutura do programa em si.
• Testes caixa-preta: 
– são testes executados sobre a funcionalidade do 
programa sem que se tenha necessariamente 
conhecimento sobre o código fonte.
Teste Caixa-branca
• Os primeiros testes aos quais um sistema é 
normalmente submetido são os testes de 
unidade, que tem como objetivo verificar se as 
funções mais simples do sistema estão 
corretamente implementadas. corretamente implementadas. 
• Usualmente esse tipo de teste pode ser 
conduzido como um teste do tipo caixa-branca, 
ou teste estrutural, pois o que se deseja é 
analisar a estrutura interna do código 
implementado.
Teste é indecidível
• Um dos problemas com testes de programas é 
que é impossível definir um procedimento 
algorítmico que certifique que um programa 
qualquer está livre de erros. qualquer está livre de erros. 
• Este problema é computacionalmente 
indecidível. 
• Então os testes precisam ser feitos de certa 
forma por amostragem.
• Mas não se trata de amostragem aleatória. 
• As técnicas de teste indicam como os 
programas devem ser testados para que se 
possa com um número razoável de tentativas possa com um número razoável de tentativas 
avaliar se um programa contém erros.
Complexidade Ciclomática
• Uma primeira técnica de teste caixa-branca pode 
ser definida assim: 
– cada estrutura de seleção (“if” ou “case”) ou repetição 
(“while” ou “repeat”) deve ser testada em pelo menos 
duas situações: quando a condição é verdadeira e 
quando a condição é falsa. quando a condição é falsa. 
– No caso do “for” deve-se testar os casos limites, isso é 
quando a variável que limita o número de repetições 
assume um valor mínimo e quando ela assume um 
valor máximo. 
– Se esse valor máximo for indefinido, então se pode 
testar com um número arbitrariamente grande.
Complexidade Ciclomática
• Assim, uma medida de complexidade de 
programa bastante utilizada é a complexidade 
ciclomática (McCabe, 1972), a qual pode ser 
definida de forma simplificada assim: definida de forma simplificada assim: 
– se n é o número de estruturas de seleção e 
repetição no programa, então a complexidade 
ciclomática do programa é n+1.
Complexidade e Risco
• Assume-se usualmente que programas com 
complexidade ciclomática:
– menor ou igual a 10 são simples e fáceis de ser 
testadostestados
– de 11 a 20 são de médio risco em relação ao teste
– de 21 a 50 são de alto risco 
– acima de 50 não são testáveis.
• Fonte: SEI – Software Engineering Institute. 
http://www.sei.cmu.edu/
Exemplo 
(complexidade ciclomática = 4)
• Outra forma de calcular a complexidade 
ciclomática de um programa (que dará o 
mesmo resultado) é contando o número de 
regiões do grafo de fluxo do programa. regiões do grafo de fluxo do programa. 
Grafo de Fluxo
• O grafo de fluxo de um programa é obtido 
colocando-se todos os comandos em nodos e 
os fluxos de controle em arestas. 
• Comandos em sequência podem ser • Comandos em sequência podem ser 
colocados em um único nodo, e estruturas de 
seleção e repetição devem ser representadas 
através de nodos distintos com arestas que 
indicam a decisão e a repetição, quando for o 
caso.
Exemplo
Detalhando a motivação para o grafo
• Os comandos, por exemplo, das linhas 11 até 14 
podem ser colocados em um único nodo. 
• O comando da linha 1 deve ter duas saídas possíveis: 
– uma para o nodo que contém a linha 2 e 
– outra para o nodo que contém a linha 4. Já no caso da 
estrutura “repeat-until” entre linhas 10 a 15.
– outra para o nodo que contém a linha 4. Já no caso da 
estrutura “repeat-until” entre linhas 10 a 15.
• O nodo que contém a linha 10 tem uma única saída 
para o nodo que contém a linha 11.
• Mas o nodo que contém a linha 15, que é o nodo de 
decisão, deve ter uma saída possível para o nodo que 
contém a linha 16 e outra de volta para o nodo que 
contém a linha 11. 
• Além disso, pode-se observar que as linhas 3 e 4, bem 
como as linhas 16 a 18 foram unidas em um único nodo. 
• Isso porque essas linhas podem ser consideradas 
sequências estritas: 
– se a linha 3 for executada a linha 4 será necessariamente 
executada em seguida. 
• O mesmo vale para as linhas 16 a 18. 
• No caso da sequência entre as linhas 10 e 11 essa norma 
também vale, pois após a linha 10 a linha 11 é 
necessariamente executada. necessariamente executada. 
• Mas como o comando da linha 11 está dentro de uma 
estrutura “repeat” ele também pode ser executado após a 
linha 15. 
• Então, neste caso, o fluxo de controle da linha 15 não 
retorna para a linha 6, mas para a linha 11. 
• Assim, é preferível, embora não faça diferença em termosde complexidade ciclomática, que os nodos 6-10 e 11-14 
sejam representados separadamente.
• Outra forma ainda de calcular a complexidade 
ciclomática, caso se tenha dúvida com as duas 
anteriores, é calcular o número de arestas do 
grafo de fluxo, subtrair o número de nodos e grafo de fluxo, subtrair o número de nodos e 
somar 2. 
• No caso anterior, o grafo possui 10 arestas e 8 
nodos. Portanto, sua complexidade 
ciclomática é 10-8+2 = 4.
• O valor da complexidade ciclomática é então a medida 
do número máximo de execuções necessárias para 
exercitar todos os comandos do programa. 
• Neste caso seriam 4. 
• Porém, a execução de todos os comandos (nodos) não • Porém, a execução de todos os comandos (nodos) não 
vai necessariamente testar os valores verdadeiro e 
falso de todas as condições possíveis. 
• Por exemplo, o caminho que vai do 
nodo 15 ao nodo 11-14 não vai ser 
necessariamente testado por este 
critério.
Caminhos Independentes
• Assim, uma abordagem mais adequada para o 
teste seria exercitar não apenas todos os 
nodos, mas todas as arestas do grafo de fluxo.
• Isso é feito pela determinação dos caminhos • Isso é feito pela determinação dos caminhos 
independentes do grafo, que são possíveis 
navegações do início ao fim do 
grafo (do nodo 1 ao nodo 16-18). 
Determinação do conjunto de 
caminhos independentes
• Inicialize o conjunto dos caminhos 
independentes com um caminho qualquer do 
início ao fim do grafo (usualmente pode ser o 
caminho mais curto).
• Enquanto for possível adicione ao conjunto 
dos caminhos independentes outros caminhos 
que passem por pelo menos uma aresta na 
qual nenhum dos caminhos anteriores ainda 
passou.
• c1 = <1, 2, 16-18>
• c2 = <1, 3-4, 5, 16-18>
• c3 = <1, 3-4, 6-10, 11-14, 15, 16-18>
• c4 = <1, 3-4, 6-10, 11-14, 15, 11-14, 15, 16-18>
• A complexidade ciclomática é definida como o 
número máximo de testes porque nada 
impede que mais testes sejam feitos. 
• Mas com 4 testes, como mostrado acima, é • Mas com 4 testes, como mostrado acima, é 
possível exercitar todos os comandos e todas 
as possíveis condições das estruturas de 
seleção e repetição.
• Além disso, esse número define a quantidade máxima 
de testes necessários, o que significa que 
possivelmente um conjunto menor de testes pode 
verificar todos os comandos. 
• Por exemplo, no caso acima, o caminho c4 exercita os • Por exemplo, no caso acima, o caminho c4 exercita os 
mesmos comandos e condições do caminho c3, pois ao 
final da repetição a condição do “until” será verdadeira 
(e isso é testado no caminho c3). 
• Mas convém manter o caminho c3 visto que ele trata 
uma condição limite da estrutura de repetição, quando 
ela é executada apenas uma única vez.
Casos de teste
• Resta ainda definir os casos de teste (Myers, 
2004), ou seja, quais dados de entrada levam 
o programa a executar cada um dos caminhos 
independentes e qual a saída esperada do independentes e qual a saída esperada do 
programa para cada um destes casos. 
• A única entrada do programa exemplo é a 
variável “num”, da qual se deseja obter o 
número de Fibonacci correspondente. 
Exemplo
• Para exercitar o caminho c1: num=0. 
– Dará verdadeiro na condição da linha 1.
• Para exercitar o caminho c2: num=1. 
– Dará falso na linha 1 e verdadeiro na linha 4.
• Para exercitar o caminho c : num=2. • Para exercitar o caminho c3: num=2. 
– Dará falso nas linhas 1 e 4 e verdadeiro na primeira 
vez que passar pela linha 15.
• Para exercitar o caminho c4: num>2. 
– Dará falso nas linhas 1, 4 e na primeira vez que passar 
pela linha 15. 
– Em seguida dará verdadeiro na linha 15.
Exemplo de caso de teste
• Poderiam ser definidos outros testes para 
valores de “num” superiores a 3, mas estariam 
exercitando os mesmos nodos e arestas do 
caminho c4, ou seja, a mesma lógica.caminho c4, ou seja, a mesma lógica.
Múltiplas condições
O critério de cobertura de todas as arestas, conforme 
visto anteriormente, pode ser insuficiente para certas 
situações.
• Neste caso, embora o grafo de fluxo tenha 
apenas duas regiões, um simples teste com a 
condição do “while” verdadeira e outro teste 
com a condição falsa pode não ser razoável com a condição falsa pode não ser razoável 
como garantia de correção deste programa.
• O critério de cobertura de múltiplas condições 
então exige que nestes casos se realize um caso 
de teste para as combinações dos valores 
verdade de cada uma das condições da linha 05, 
ou seja:ou seja:
– Para (anos[coluna] <> 1996) verdadeiro e (coluna < 6) 
verdadeiro. 
– Para (anos[coluna] <> 1996) verdadeiro e (coluna < 6) 
falso.
– Para (anos[coluna] <> 1996) falso e (coluna < 6) 
verdadeiro.
– Para (anos[coluna] <> 1996) falso e (coluna < 6) falso.
Casos de teste
• Pode-se observar que a execução do programa 
com as entradas definidas na tabela vai 
exercitar todas as combinações possíveis dos 
valores verdade das condições pelo menos valores verdade das condições pelo menos 
uma vez. 
• O problema desta técnica é que o número de 
testes cresce exponencialmente em relação ao 
número de condições na decisão.
Limitações
• Note-se que o teste caixa-branca usualmente 
é aplicado para verificar erros de programa. 
• Este tipo de teste não é capaz de identificar, 
por exemplo, se o requisito foi bem por exemplo, se o requisito foi bem 
especificado. 
• Ou seja, o teste vai verificar se o programa se 
comporta de acordo com a especificação 
dada, não necessariamente de acordo com a 
especificação esperada.
• Outra limitação deste tipo de teste é que ele não 
necessariamente cobre potenciais problemas 
com estruturas de dados como arrays e listas. 
• Além disso, ele não necessariamente trata • Além disso, ele não necessariamente trata 
situações típicas de programas orientados a 
objetos, especialmente quando se usa herança e 
polimorfismo. 
• Para essas situações existem técnicas de teste 
específicas (Delamaro, Maldonado, & Jino, 2007).
• Outras limitações conhecidas do teste caixa-
branca são o fato de que funcionalidades 
ausentes não são testadas, pois a técnica 
preconiza apenas o teste daquilo que existe 
no programa. no programa. 
• Além disso, algumas vezes o programa pode 
estar produzindo o resultado correto para 
uma entrada por mera coincidência, não 
significando que esteja correto.
• Apesar dessas limitações a técnica é relevante 
e seu uso é importante para a detecção de 
vários tipos de defeitos no software, 
especialmente nas suas unidades mais especialmente nas suas unidades mais 
básicas.
Ferramentas
• Uma ferramenta para automatização de testes 
desenvolvida para Java, mas também adaptada 
para outras linguagens é o JUnit. 
• Trata-se de um framework distribuído 
gratuitamente. gratuitamente. 
• O framework permite inserir comandos 
específicos de verificação no programa que 
acusarão os erros caso venham a ser 
encontrados.
– http://junit.wikidot.com/
Bibliografia
• Beizer, B. (1990). Software Testing Techniques,
2nd Ed., Van Nostrand Reinhold.
• Bloch, A. (1977). Murphy's Law and other 
reasons why things go wrong. Methuen.reasons why things go wrong. Methuen.
• Delamaro, M. E., Maldonado, J. C., & Jino, M. 
(2007). Introdução ao Teste de Software. Rio 
de Janeiro, RJ, Brasil: Elsevier.
• Myers, G. J. (2004). The Art of Software 
Testing. (2 Ed.) New Jersey: John Wiley & Sons.