Teste de software - texto

Prévia do material em texto

INSTITUTO FEDERAL GOIANO - CAMPUS IPORÁ 
Curso: Tecnologia em Análise e Desenvolvimento de Sistemas 
Disciplina: Engenharia de Software II Prof.ª: Luciana Recart Cardoso 
 
 
Teste de Software 
 
Introdução 
A crescente dependência da sociedade atual pelos sistemas informatizados é 
cada vez maior. As instituições financeiras, medicina e atividades que podem oferecer 
risco a vida humana tem softwares como importantes ferramentas de apoio. 
A necessidade de produzir softwares que possuam garantia de qualidade, ou 
seja, com a menor probabilidade de respostas indesejáveis possível é uma 
preocupação que deu origem a uma subárea da Engenharia de Software, que é a de 
teste de software. 
 
Por que testar? 
Leis de Murphy: 
• Se uma coisa pode sair errado, sairá. 
• Se tudo parece estar indo bem, é porque você não olhou direito. 
A natureza sempre está a favor da falha oculta. 
• Exigência de qualidade 
• Economia; 
• Segurança; 
• Confiabilidade; 
• Teste agrega valor ao produto 
 
Alguns erros de software tornaram-se históricos 
Estação climática de Marte 
• Objetivo – enviar sinais à Terra 
• Desastre – desintegrou-se 
• Motivo – BUG! 
• Prejuízo – US$ 165 milhões 
Airbus A320 
• Desastre – USS Vicennes derrubou um A320 em 1988 
• Motivo – BUG! – confundiu um A320 com um F-14 
• Prejuízo – 290 mortes 
Máquinas de radiação 
Sistema de ambulância de Londres 1992 
Fogo amigo na guerra das Malvinas 
Trem parado no meio do nada – erro ao detectar a estação 
Míssil Scud na guerra do golfo – erro em tempo real de 36s – 30 mortos 
 
Por que investir em testes? 
• Testes unitários podem remover entre 30% e 50% dos defeitos do 
programas; 
• Testes de sistema podem remover entre 30% a 50% dos defeitos 
remanescentes; 
• Desta forma os sistemas podem ir para produção ainda com 
aproximadamente 49% de defeitos. 
• Por último, afirma que revisões de código podem ainda reduzir entre 
20% e 30% desses defeitos. 
 
Porque as empresas não testam? 
• O teste de software é um processo caro; 
• Desconhecimento sobre a relação custo/benefício; 
• Falta de profissionais especializados; 
• Dificuldade em implantar um processo de teste; 
• Desconhecem um procedimento de teste adequado; 
• Desconhecem as técnicas de testes adequadas; 
• Desconhecem como planejar a atividade de teste; 
• Só se preocupam com teste na fase final do projeto. 
• Cronograma atrasado 
• Prazos Curtos 
• Pressão do cliente 
• Muito estresse 
 
Custo da correção dos defeitos 
Quanto antes a presença do defeito for descoberta, menor o custo de correção 
do defeito e maior a probabilidade de corrigi-lo corretamente. 
Entre 70 e 80% do custo de desenvolvimento de software envolve atividades 
de teste e depuração. 
A Figura 1 mostra o crescimento dos custos na correção de defeitos em relação 
a sua realização dentro do processo de desenvolvimento de software. 
 
Figura 1 - Custos na correção de defeitos 
 
O que é teste de software? 
“Processo de executar um programa com o objetivo de revelar a presença de 
falhas” 
“Processo de executar o software de uma maneira controlada com o objetivo 
de avaliar se o mesmo se comporta conforme o especificado”. 
“Testes de software devem nunca mostrar a ausência de erros, somente sua 
presença.” 
 
Objetivos do teste de software 
• Verificar se todos os requisitos do sistema foram corretamente 
implementados 
• Reduzir custos de manutenção corretiva 
• Assegurar a satisfação do cliente com o produto desenvolvido 
• Reduzir a probabilidade da ocorrência de uma falha quando o software 
estiver em produção, minimizando os riscos para o negócio e garantindo 
que as necessidades do cliente estão sendo atendidas. 
O objetivo principal desta tarefa é encontrar o número máximo de erros 
dispondo do mínimo de esforço, ou seja, mostrar aos que desenvolvem se os 
resultados estão ou não de acordo com os padrões estabelecidos. 
 
Natureza do teste de software é destrutiva e não construtiva: 
Sucesso das atividades de teste indica o insucesso do processo de 
desenvolvimento. 
Um processo de teste visa ocasionar falhas em um produto e não contribui 
diretamente para a sua construção, por isso é chamado de “destrutivo”. 
Exemplo: 
O baixo nível de defeitos encontrados indica um fracasso dos testes. Por outro 
lado, um alto nível de defeitos indica o sucesso do teste, pois atingiu seu objetivo. 
 
Terminologia - Defeito, Erro e Falha 
As definições usadas aqui seguem a terminologia padrão para Engenharia de 
Software do Institute of Electrical and Electronics Engineers (IEEE) (IEEE 610, 1990). 
Defeito é um ato inconsistente cometido por um indivíduo ao tentar entender 
uma determinada informação, resolver um problema ou utilizar um método ou uma 
ferramenta. Por exemplo, uma instrução ou comando incorreto. Está relacionado a um 
problema oculto nos artefatos gerados durante o processo de desenvolvimento. 
Normalmente se encontram nos produtos de trabalho antes mesmo do executável, 
tais como: documentação de requisitos (ex. requisitos ambíguos ou incorretos), código 
fonte (ex. erros de precedência lógica), modelos de dados (ex. omissão de tipagem), 
etc. Desta forma, pode ser mapeado antes mesmo da codificação e dos testes. 
Erro é uma manifestação concreta de um defeito num artefato de software. 
Diferença entre o valor obtido e o valor esperado, ou seja, qualquer estado 
intermediário incorreto ou resultado inesperado na execução de um programa constitui 
um erro. 
Falha é o comportamento operacional do software diferente do esperado pelo 
usuário. Uma falha pode ter sido causada por diversos erros e alguns erros podem 
nunca causar uma falha. Está normalmente relacionada a um comportamento 
resultante de um defeito. Ou seja, é um evento inesperado que ocorre durante a 
execução do software. Por exemplo, o usuário não se autentica, pois o campo de 
senha aceita apenas 6 caracteres, e no cadastro ele se registrou com uma senha de 
8 caracteres. 
A Figura 2 expressa a diferença entre esses conceitos. Defeitos fazem parte do 
universo físico (a aplicação propriamente dita) e são causados por pessoas, por 
exemplo, através do mal uso de uma tecnologia. 
Defeitos podem ocasionar a manifestação de erros em um produto, ou seja, a 
construção de um software de forma diferente ao que foi especificado (universo de 
informação). Por fim, os erros geram falhas, que são comportamentos inesperados 
em um software que afetam diretamente o usuário final da aplicação (universo do 
usuário) e pode inviabilizar a utilização de um software. 
 
 
Figura 2 - Defeito x erro x falha 
 
 
Quando, como e o que testar? 
Estas questões são respondidas com o planejamento dos testes de software, 
que definirão os tipos, estratégias e técnicas de teste. 
 
Tipos de Teste (O que testar) 
O Rational Unified Process (RUP) categoriza qualidade utilizando o modelo 
FURPS (Functionality, Usability, Reliability, Performance and Supportability). A 
Tabela 1 apresenta os Tipos de Teste, agrupados por Dimensões de Qualidade, e 
as características correspondentes a cada grupo: 
 
Categoria Tipos de Teste Requisitos 
Funcionalidade 
Teste Funcional 
Teste de Volume 
Teste de Segurança 
Teste de Acessibilidade 
Conjunto de características; 
Capacidade; 
Segurança. 
Usabilidade Teste de Usabilidade 
Fator humano e estética; 
Consistência da Interface 
do usuário; 
Help online e assistentes. 
Confiabilidade 
Teste de Estresse 
Teste de Regressão 
Frequência e severidade de 
falhas; 
Teste de Integridade 
Teste de Estrutura 
Confiança nos resultados; 
Recuperação de falhas; 
Tempo entre falhas 
Desempenho 
Teste de Desempenho 
Teste de Carga 
Teste de Contenção 
Teste de Perfil de 
Desempenho 
Vazão; 
Eficiência; 
Tempo de Resposta; 
Consumo de recursos. 
Suportabilidade 
Teste de Instalação 
Teste de Configuração 
Facilidade de instalação; 
Requisitos de configuração; 
Requisitos de 
adaptabilidade;Requisitos de 
Compatibilidade. 
Tabela 1 - Tipos de Teste por Dimensões de Qualidade 
 
Técnicas de Teste (Como testar) 
Atualmente existem muitas maneiras de se testar um software. Mesmo assim, 
existem as técnicas que sempre foram muito utilizadas em sistemas desenvolvidos 
sobre linguagens estruturadas que ainda hoje têm grande valia para os sistemas 
orientados a objeto. Apesar de os paradigmas de desenvolvimento ser completamente 
diferentes, o objetivo principal destas técnicas continua a ser o mesmo: encontrar 
falhas no software. Abaixo estão descritas as três técnicas mais conhecidas. 
 
Caixa-Branca 
Técnica de teste, também chamada de Teste Estrutural, que avalia o 
comportamento interno do componente de software. Essa técnica trabalha 
diretamente sobre o código-fonte do componente de software para avaliar aspectos 
tais como: teste de condição, teste de fluxo de dados, teste de ciclos e teste de 
caminhos lógicos. 
Os aspectos avaliados nesta técnica de teste dependerão da complexidade e 
da tecnologia que determinarem à construção do componente de software, cabendo 
portanto, avaliação de mais aspectos que os citados anteriormente. O testador tem 
acesso ao código fonte da aplicação e pode construir códigos para efetuar a ligação 
de bibliotecas e componentes. 
Este tipo de teste é desenvolvido analisando-se o código fonte e elaborando-
se casos de teste que cubram todas as possibilidades do componente de software. 
Dessa maneira, todas as variações originadas por estruturas de condições são 
testadas. Um exemplo bem prático desta técnica de teste é o uso da ferramenta livre 
JUnit para desenvolvimento de classes de teste (test cases) para testar classes ou 
métodos desenvolvidos em Java. Também se enquadram nessa técnica testes 
manuais ou testes efetuados com apoio de ferramentas para verificação de aderência 
a boas práticas de codificação reconhecidas pelo mercado de software. 
A aderência a padrões e boas práticas visa principalmente a diminuição da 
possibilidade de erros de codificação e a busca de utilização de comandos que gerem 
a melhor performance de execução possível. Apesar de muitos desenvolvedores 
alegarem que não haverá ganhos perceptíveis com essa técnica de teste aplicada 
sobre unidades de software, devemos lembrar que, no ambiente produtivo, cada 
programa pode vir a ser executado milhares ou milhões de vezes em intervalos de 
tempo pequenos. É na realidade de produção que a soma dos aparentes pequenos 
tempos de execução e consumo de memória de cada programa poderá levar o 
software a deixar de atender aos objetivos esperados. 
 
 
 
 
 
 
 
 
 
 
Figura 3 – Teste de caixa branca 
 
A técnica de teste de Caixa Branca é recomendada para as fases de Teste da 
Unidade e Teste da Integração, cuja responsabilidade principal fica a cargo dos 
desenvolvedores do software, que por sua vez conhecem bem o código-fonte 
produzido. 
 
Caixa-Preta 
Técnica de teste, também chamada de Teste Funcional, em que o componente 
de software a ser testado é abordado como se fosse uma caixa-preta, ou seja, não se 
considera o seu comportamento interno. Dados de entrada são fornecidos, o teste é 
executado e o resultado obtido é comparado a um resultado esperado previamente 
conhecido. 
 
 
 
 
 
Figura 4 -Técnica de Teste Funcional. 
 
O componente de software a ser testado pode ser um método, uma função 
interna, um programa, um componente, um conjunto de programas e/ou componentes 
ou mesmo uma funcionalidade. A técnica de teste de Caixa-Preta é aplicável a todas 
as fases de teste - fase de teste de unidade (ou teste unitário), fase de teste de 
integração, fase de teste de sistema e fase de teste de aceitação. 
A aplicação de técnicas de teste leva o testador a produzir um conjunto de 
casos de teste (ou situações de teste). A aplicação combinada de outra técnica - 
Técnica de Particionamento de Equivalência (ou uso de Classes de Equivalência) 
permite avaliar se a quantidade de casos de teste produzida é coerente. A partir das 
classes de equivalência identificadas, o testador irá construir casos de teste que 
atuem nos limites superiores e inferiores destas classes, de forma que um número 
mínimo de casos de teste permita a maior cobertura de teste possível. 
 
Outras Técnicas 
Outras técnicas de teste podem e devem ser utilizadas de acordo com 
necessidades de negócio ou restrições tecnológicas. Alguns autores chegam a definir 
uma técnica de Teste Caixa Cinza, que seria um mesclado do uso das técnicas de 
Caixa Preta e Caixa Branca, mas, como toda execução de trabalho relacionado à 
atividade de teste utilizará simultaneamente mais de uma técnica de teste, é 
recomendável que se fixem os conceitos primários de cada técnica. 
Estratégias de teste de software (quando testar) 
O planejamento dos testes deve ocorrer em diferentes níveis e em paralelo ao 
desenvolvimento do software (Figura 5). Os principais níveis de teste de software são: 
Teste de Unidade: também conhecido como testes unitários. Tem por objetivo 
explorar a menor unidade do projeto, procurando provocar falhas ocasionadas por 
defeitos de lógica e de implementação em cada módulo, separadamente. O universo 
alvo desse tipo de teste são os métodos dos objetos ou mesmo pequenos trechos de 
código. 
Teste de Integração: visa provocar falhas associadas às interfaces entre os 
módulos quando esses são integrados para construir a estrutura do software que foi 
estabelecida na fase de projeto. 
Teste de Sistema: avalia o software em busca de falhas por meio da utilização 
do mesmo, como se fosse um usuário final. Dessa maneira, os testes são executados 
nos mesmos ambientes, com as mesmas condições e com os mesmos dados de 
entrada que um usuário utilizaria no seu dia-a-dia de manipulação do software. 
Verifica se o produto satisfaz seus requisitos. 
Teste de Aceitação: são realizados geralmente por um restrito grupo de 
usuários finais do sistema. Esses simulam operações de rotina do sistema de modo a 
verificar se seu comportamento está de acordo com o solicitado. 
Teste de Regressão: Teste de regressão não corresponde a um nível de teste, 
mas é uma estratégia importante para redução de “efeitos colaterais”. Consiste em se 
aplicar, a cada nova versão do software ou a cada ciclo, todos os testes que já foram 
aplicados nas versões ou ciclos de teste anteriores do sistema. Pode ser aplicado em 
qualquer nível de teste. 
Dessa forma, observando-se a Figura 5, o planejamento e projeto dos testes 
devem ocorrer de cima para baixo, ou seja: 
1. Teste de aceitação - a partir do documento de requisitos; 
2. Teste de sistema - a partir do projeto de alto nível do software; 
3. Teste de integração - a partir o projeto detalhado; 
4. Teste de unidade - a partir da codificação. 
Já a execução ocorre no sentido inverso. 
As principais técnicas de teste de software existentes que podem ser aplicadas 
nos diferentes níveis abordados. 
 
 
Figura 3 - Modelo V descrevendo o paralelismo entre as atividades de 
desenvolvimento e teste de software