475 LOUZADA VBF REDUCAO E CONTROLE

Prévia do material em texto

XI SIMPEP - Bauru, SP, Brasil, 08 a 10 de novembro de 2004 
Redução e Controle de Erros para as Atividades de Testes de Software 
 
 
Vivian Bella Ferreira Louzada (UNIP) vivianbella@electra.com.br 
 
 
RESUMO 
 
O artigo inicia o assunto abordando conceitos gerais sobre teste de software, inclusive quais são 
as técnicas existentes que promovem a atividade de teste em produtos de software. 
Sobre projeto de teste, o artigo aborda as falhas mais comuns que ocorrem nessa fase, ilustrando 
com os fatores críticos de sucesso para testes de software. 
Finalmente, o estudo menciona alguns métodos capazes de controlar a atividade de testes, 
envolvendo etapas como: ocorrência de erros, custos de testes, erros de previsão, erros de 
documentação, entre outros. Relata-se também o momento considerado ideal para encerramento 
dos testes de software. 
 
Palavras-chave: teste, projeto, software, erros. 
 
1 - Conceito de Testes de Software 
 
O objetivo principal deste estudo é compreender os motivos pelos quais as atividades de testes 
não funcionam na prática como é proposto na teoria. 
O objetivo dos testes de software é revelar a presença de erros. A falta de testes gera defeitos e 
erros não revelados no momento ideal para correção dos mesmos, implicando em alto custo para 
correção [WEBER&MALDONADO&ROCHA01]. 
Os testes constituem uma fase dispendiosa e trabalhosa do processo de software. 
[SOMMERVILLE03] 
Os testes são indispensáveis para detectar os defeitos que ainda escapam das revisões e para 
avaliar-se o grau de qualidade de um produto e de seus componentes. [PÁDUA03] 
Segundo [MOLINARI03], alguns gerentes de projetos deixam a atividade de testes como a 
última fase, executando os testes apenas com o tempo restante para o término do projeto ou nem 
o fazem, se o custo não permitir ou se o tempo estiver esgotado. Desta maneira, um produto de 
baixa qualidade é enviado para o cliente, que, por sua vez, apostou muito no software e acredita 
que, sem erros, ele será a solução de seu problema. 
A falta de tempo e recursos, bem como a indisponibilidade de ferramentas adequadas para a 
realização dos testes, são os principais problemas enfrentados pelas equipes de teste. Por motivos 
como esse, sugere-se que seja definido um critério para testes, cuja finalidade é selecionar e 
avaliar casos de teste de forma a aumentar as possibilidades de revelar a presença de defeitos. 
[WEBER&MALDONADO&ROCHA01] 
A atividade de teste envolve as etapas de planejamento, projeto de casos de teste, execução e 
avaliação de resultados – que devem ser conduzidas ao longo de todo o processo de 
desenvolvimento do software. Salienta-se que a ausência de planejamento das atividades de 
desenvolvimento é uma das causas da crise do software. [PRESSMAN01] 
 
XI SIMPEP - Bauru, SP, Brasil, 08 a 10 de novembro de 2004 
De acordo com [MOLINARI03], os conceitos vitais para entendimento de testes de software se 
resumem nas fases: 
• Planejamento de testes 
• Plano de testes 
• Requerimento de testes 
• Caso de testes 
• Procedimento de testes 
• Script de testes 
• Ponto de verificação 
 
Testar versus Provar: De acordo com [PFLEEGER04], para provar que um programa está 
correto, a equipe de testes ou o programador considera somente o código e suas condições de 
entrada e saída. O programa é visto em termos das classes de dados e das condições descritas no 
projeto. Logo, a prova pode não envolver a execução do código, mas a compreensão do que está 
acontecendo dentro do programa. 
 
 
2 – Tipos de Teste 
 
Abaixo consta uma tabela com os principais tipos de teste envolvidos. 
 
Tipo de Teste Descrição 
Teste de Unidade Teste em nível de componente ou classe. É o teste cujo objetivo é um “pedaço do código” 
Teste de Integração Garante que um ou mais componentes combinados (ou unidades) funcionem corretamente 
Teste de Sistema A aplicação tem que funcionar como um todo. Neste momento a aplicação tem de “fazer aquilo que diz que faz” 
Teste Operacional Garante que a aplicação pode “rodar” muito tempo sem falhar 
Teste Negativo – 
Positivo 
Garante que a aplicação vai funcionar no “caminho feliz” de sua 
execução e vai funcionar no seu fluxo de exceção 
Teste de Regressão 
Um dos mais importantes testes. “Para irmos para o futuro, 
temos de voltar ao passado, sempre”. Toda vez que formos 
inserir uma característica nova na aplicação, devemos testar toda 
a aplicação. Afinal, podemos, ao “consertar algo, quebrar outro” 
Teste de Caixa Preta Testar todas as entradas e saídas desejadas. Não se está preocupado com o “código” 
Teste de Caixa Branca O objetivo é testar o código. Ás vezes existem partes do código que nunca foram testadas 
Teste Beta O objetivo é testar a aplicação em produção 
Teste de Verificação de 
Versão 
Toda vez que se libera uma nova versão da aplicação, existem 
condições mínimas que validam se a versão liberada está OK. 
Este teste é usado durante o processo de construção da 
aplicação. Pode querer testar às vezes apenas uma parte da 
aplicação 
Teste Funcional Testar se as funcionalidades presentes na documentação 
XI SIMPEP - Bauru, SP, Brasil, 08 a 10 de novembro de 2004 
funcionam como especificado. Incluem-se aws regras de 
negócio. 
Teste de Interface 
Verifica se a navegabilidade e os objetos de tela funcionam 
corretamente, em conformidade com padrões vigentes (em nível 
de interface). 
Teste de Performance Verifica se o tempo de resposta é o desejada para “momento” de utilização da aplicação e suas respectivas telas envolvidas. 
Teste de Carga Verifica se a aplicação suporta a quantidade de usuários simultâneos requeridos. 
Teste de Aceitação do 
Usuário 
É um teste exploratório voltado para validar aquilo que o usuário 
deseja, tendo um objetivo claro: dar o aceite ou não. 
Teste de estresse Testar a aplicação em situações inesperadas. 
Teste de Volume Testar a quantidade de dados envolvidos. 
Teste de Configuração Testa se a aplicação funciona corretamente em diferentes ambientes de hardware e de software. 
Teste de Instalação Verificar se a instalação da aplicação (hardware e software) foi OK. 
Teste de Documentação A documentação existe? Mostra o que o software faz efetivamente? Falta algo na documentação? 
Teste de Integridade O objetivo é testar a integridade dos dados armazenados. 
Teste de Segurança Testar a segurança da aplicação nas mais diversas formas. 
Teste de Monitoração Testes funcionais que visam verificar o status e disponibilidade de diversas funcionalidades e da aplicação em si. 
Teste de Ameaça Semelhante ao de segurança, mas em escala maior em nível de falhas. 
Monkey Test Testa o aplicativo de forma aleatória e inesperada. 
Teste de Módulo Teste de um módulo, porém em nível menor. Semelhante ao de unidade, porém, mais abrangente. 
[Tabela 1 – Adaptada de MOLINARI, Leonardo. Testes de Software, 2003] 
 
 
3 - Projeto de Teste 
 
Testar, conforme [WEBER&MALDONADO&ROCHA01], é examinar o comportamento do 
produto por meio de sua execução. Teste de software é o processo de executar um programa com 
o objetivo de revelar a presença de erros. Contribui para aumentar a confiança de que o software 
desempenha as funções especificadas. 
Teste é um conjunto de atividades que pode ser planejado antecipadamente e realizado 
sistematicamente. [PRESSMAN01] 
Ainda segundo [PRESSMAN01], um bom projeto de teste deve iniciar junto com a programação 
e acompanhar todo o processo de desenvolvimento. A cada etapa pode-se aplicar diferentes 
técnicas de avaliação. O ideal seria existir uma equipe independe para executar esta função, mas 
caso não seja possível um projeto de teste bem elaborado pode auxiliar e garantir uma qualidade 
elevada no software. 
Segundo [MOLINARI03], alguns problemas comuns no planejamento são: 
• Indefinição dos requisitos; 
XI SIMPEP - Bauru, SP, Brasil, 08 a 10 denovembro de 2004 
• Recursos da ferramenta de teste foram desprezados no planejamento; 
• Prazo curto; 
• Planejamento de fraco conhecimento (tratando-se de testes ou do negócio); 
• Planejamento pouco abrangente ; 
• Planejamento com baixo acoplamento; 
• Planejamento de risco alto (Requisitos a serem testados são de alto risco à medida que 
qualquer “bug” será de alta prioridade). 
 
Alguns defeitos comuns no projeto de desenvolvimento, conforme 
[WEBER&MALDONADO&ROCHA01], são: defeitos de origem humana, erros localizados em 
linha de códigos raramente executados, tradução incorreta de informações, entre outros. 
Na figura abaixo podemos verificar a demonstração do projeto de teste durante o 
desenvolvimento do software de forma espiral. O teste se inicia na codificação, com o teste de 
unidade, após esta avaliação é necessária a verificação da integração entre os módulos, ou seja 
avaliar o projeto desenvolvido, em um terceiro momento a validação, conferindo se os requisitos 
foram atendidos, e finalmente o teste do sistema como um todo, para total segurança. 
 
 
 
S
R
D
I
V
ST
C 
U 
Engenharia de
Requisito
Projeto
Código
Teste de Unidade
Teste de Integração 
Teste de Validação 
Teste de Sistema 
[Figura 1 – PRESSMAN, Roger. Engenharia de Software, 2001.] 
 
3.1 - Falhas no projeto de teste 
 
As falhas ocasionadas nos testes podem ter início no planejamento deste teste, ou na falta de 
comunicação entre a equipe de teste e os desenvolvedores. 
No caso do planejamento, podemos considerar a falta de uma equipe de teste, ou na estrutura do 
projeto de desenvolvimento, pois o teste deve fazer parte do projeto inicial. 
 
3.1.1 - Falhas na comunicação 
 
A comunicação existente entre as equipes de desenvolvimento e de teste deve ser clara e objetiva. 
Um dos grandes problemas encontrados é o fato dos seres humanos não ser favorável a avaliação 
constante do seu trabalho, na área de desenvolvimento de software este problema se agrava pelos 
diferentes métodos de programação, lógica e conceitos utilizados. Alguns profissionais acreditam 
ser verdadeiros “artistas” de determinado aplicativo ou linguagem, dificultado uma forma padrão 
de teste e avaliação. 
 
XI SIMPEP - Bauru, SP, Brasil, 08 a 10 de novembro de 2004 
3.1.2 - Falhas de documentação 
 
Um projeto bem desenvolvido deve ter uma documentação significativa e representativa de todas 
as etapas e fases, não gerando dúvidas para nenhum dos membros envolvidos. Caso esta não seja 
uma realidade, a avaliação do mesmo será dificultada pela falta de informação. O próprio 
desenvolvimento do projeto ter falhas decorrentes desta documentação, pois se os requisitos, as 
integrações, os equipamentos necessários a boa execução do software não estiverem claras, o 
resultado final poderá ser prejudicado. 
No caso específico de teste, como será possível avaliar um código sem ter a documentação do 
que este projeto deve fazer. A avaliação dos componentes fica limitada a funcionalidade dos 
mesmos, mas não será possível verificar a integridade dos resultados esperados. 
 
3.1.3 - Falhas na escolha do método aplicado em cada fase 
 
Caso o projeto de teste esteja planejado e previsto, é necessário que a equipe responsável conheça 
os métodos de teste mais adequados para cada fase do desenvolvimento. A falta deste 
conhecimento pode ocasionar resultados inadequados, prejudicando a qualidade esperada. 
 
3.1.4 - Falhas decorrentes do hardware ou bancos de dados (ambiente) 
 
A avaliação do ambiente onde este software dera ser executado é outro grande fator a ser 
considerado. Um teste local para um aplicativo que deverá ser executado em rede, não irá avaliar 
o desempenho do mesmo e também a integridade dos dados que estarão sendo manipulados, 
podendo até mesmo esconder falhas no código em execução, pois os ambientes em redes 
requerem cuidados específicos, de acordo com os aplicativos utilizados e os equipamentos de 
hardware. 
Outra grande falha encontrada está relacionada ao banco de dados, no ambiente de teste existe 
um banco de dados que pode estar “viciado”. O correto é sempre que possível utilizar uma cópia 
do banco de dados real, para avaliação dos resultados e também de desempenho. 
 
4 - Fatores Críticos de Sucesso para Testes de Software 
 
Resultados Previstos A equipe deve saber a finalidade da revisão, e o que deve ser testado. 
Responsabilidades As responsabilidades devem ser atribuídas de forma clara entre todos os participantes. 
Direitos Individuais As opiniões e os sentimentos devem ser consideradas características dos indivíduos, não do grupo. 
Participantes A equipe deve contar com testadores internos e externos. 
Processo Estruturado Os procedimentos devem ser estáveis, bem definidos. 
O Moderador Deve ser hábil e treinado em testes. 
Os Registros Devem ser avaliados e devem estar em relatórios próprios. 
[Tabela 2 – Adaptado de HETZEL, 1988 – The Complete Guide to Software Testing] 
 
Destes sete fatores, os primeiros três são os mais freqüentemente violados. O que se espera da 
revisão e da colaboração de todos os participantes deve ser definida claramente. É importante os 
XI SIMPEP - Bauru, SP, Brasil, 08 a 10 de novembro de 2004 
indivíduos preservarem suas opiniões. Talvez a maneira mais correta seria considerar as revisões 
efetuadas pelo grupo de forma geral. Estes agentes devem ser definidos no projeto do 
desenvolvimento do software. 
 
4.1 – Resultados de Teste que devem ser revisados, conforme [HETZEL88]: 
 
• Plano de Teste 
• Especificações do teste de desenvolvimento 
• Procedimentos de teste 
• Especificações de teste 
• Casos de Testes 
• Relatórios de Testes 
• Inventários 
 
De acordo com [PFLEEGER04], um caso de teste é uma escolha específica dos dados de entrada 
a serem utilizados para testar um programa. Um teste é um conjunto limitado de casos de testes. 
Erros de Teste, de acordo com [MOLINARI03], são erros encontrados no teste que não foram 
reportados por alguma razão. 
 
5 – Controlando as Funções de Teste 
 
5.1 – Testando o Teste 
 
De acordo com [HETZEL88], testar é uma função delicada de suporte, pois fornece informações 
precisas. Sem informações deste porte, a gerência não é capaz de avaliar o progresso do 
desenvolvimento do software ou de avaliar os problemas de forma correta. 
Testar os métodos de teste fornece uma base para o controle do projeto, é duplamente crítico 
controlar os testes de forma eficaz. Testar os mecanismos de teste fornece a informação que serve 
como o gabarito para controlar a função testada, sendo assegurado, desta forma, que o teste esteja 
sendo executando corretamente. 
 
Elementos-chave para o efetivo controle de testes: 
 
a. Ocorrência de erros, falhas de projeto e falhas no custo 
Além a seguir e a analisar freqüências do erro, é recomendado analisar o impacto e os custos. 
Os determinados erros e falhas têm o impacto principal e custam muito mais para corrigir ou 
recuperar. Outros têm poucos impacto e inconveniências menores. Ao analisar o 
desempenho dos testes, o objetivo é detectar e impedir falhas. As contagens simples da 
freqüência não podem mostrar as tendências corretamente. Seguir custos estimados supera o 
impacto direto. 
 
b. Análise de problemas 
Os imprevistos devem ser analisados para responder a diversas perguntas básicas e para 
suportar a fase determinada. Algumas questões que podem ser respondidas que acordo com as 
análises de problemas são: 
 
XI SIMPEP - Bauru, SP, Brasil, 08 a 10 de novembro de 2004 
Se o(s) erro(s) foi(ram) localizado(s)... Se não houve(ram) erro(s) localizado(s)... 
Como o erro foi encontrado? Por que não foram encontrados erros? 
O que foi feito incorretamente? Como poderão ser impedidos? 
Quem fez errado? 
Por que não foi detectado antes? 
Como poderia ter sido impedido? 
[Tabela 3 – Adaptadade HETZEL, Bill. 
The Complete Guide to the Software Testing, 1984] 
 
c. Testes de Custo de Falhas 
Além de analisar freqüências de erros, é recomendado também analisar o impacto e os custos 
dos erros em relação ao desempenho do software. Determinados erros e falhas têm forte 
impacto e custam muitos para corrigir ou recuperar. Outros têm poucos impacto e não são 
muito representativos. Ao analisar o desempenho dos testes, o objetivo fundamental é 
detectar e impedir falhas. As falhas sendo corrigidas antes de acontecerem previnem custos 
maiores do que aqueles orçados. 
 
d. Testes durante as fases do projeto 
Faz parte do conceito de “controle de testes” seguir as fases do trabalho de testes – para a 
gerência do projeto, o acompanhamento traz um resultado muito útil. As fases em análise 
ocorrem fora do projeto e os resultados são relatados como linha de base para os 
desenvolvedores. 
O acompanhamento inicia-se conhecendo-se o que deve ser testado e quais resultados esperar. 
Posteriormente, deve-se conhecer os resultados já emitidos e as barreiras de testes, 
dependendo do fluxo da informação. Esses resultados fornecem base para análise das 
atividades de teste. 
As informações necessárias para testar as fases do projeto são: 
- Trabalho do projeto de teste 
- Análise da especificação do caso de teste 
- Disponibilidade dos casos de teste 
- O que foi testado 
- O que não foi testado 
- Quais as versões do software foram testadas 
- Até quando testar. 
 
e. Documentação de teste 
Um aspecto do controle da atividade de testes é documentação. O ciclo de vida do 
desenvolvimento é caracterizado pelos desenvolvimento de cada fase do trabalho. Na mesma 
maneira, o ciclo de vida de testes pode ser definido e controlado pelos trabalhos produzidos 
durante cada uma das atividades de teste. 
A documentação de teste é totalmente ignorada em muitas empresas. Os padrões para 
escrever o projeto ou para relatar resultados de teste são desiguais. Em muitas organizações a 
documentação de teste não é produzida simplesmente. Em outras, as documentações de teste 
são criadas conforme a prática. 
A documentação de teste deve conter: 
- Plano de testes 
XI SIMPEP - Bauru, SP, Brasil, 08 a 10 de novembro de 2004 
- Especificação do teste do projeto 
- Especificação de casos de teste 
- Métodos para testes 
- Teste de itens 
- Histórico de testes 
- Relatório de erros 
 
 
O primeiro elemento que controla o teste de função deve localizar eficazmente erros, falhas no 
projeto e falhas no orçamento. Isto envolve a captura da informação nos problemas detectados 
durante o teste e então a análise dessa informação ajuda de modo que as tendências e os eventos 
significativos sejam reconhecidos. 
 
6 – Quando encerrar os testes 
 
Conforme [PFLEEGER04], se há muitos defeitos em um componente, queremos encontrá-lo o 
quanto antes, durante o processo de teste. Entretanto, se encontrarmos um grande número de 
defeitos no início, provavelmente, ainda existe um grande número de defeitos que não foram 
detectados. De qualquer maneira, os resultados apurados tornam difícil saber quando parar de 
procurar por defeitos durante o teste. É necessário estimar o número de defeitos remanescentes, 
não somente para saber quando interromper a procura, mas também para obtermos um grau de 
confiança no código que está sendo produzido. O número de defeitos também indica o provável 
esforço de manutenção necessário, se os defeitos forem deixados para serem detectados depois 
que o sistema for entregue. 
 
 
CONCLUSÕES 
 
Conforme as referências citadas, concluo que algumas empresas desenvolvedoras de software, 
seja de pequeno, médio ou grande porte, não deslocam profissionais para a atividade de teste do 
produto de software. Muitos gerentes de projeto acreditam que a fase de testes é um sinônimo de 
custos desnecessários, envolvendo engenheiros de testes que fazem as mesmas rotinas dos 
usuários, quando a aplicação está na fase de produção. 
Dependendo da atividade desenvolvida pelo software, é muito arriscado colocá-lo em produção 
sem uma bateria de testes exaustivos. Imaginemos um software que possa gerenciar qualquer 
aparelho da área médica, que necessite precisão em suas respostas. Caso aquela aplicação não 
tenha sido testada exaustivamente, muito provavelmente erros na resposta poderão ocorrer e, 
conseqüentemente, falhas médicas. Na verdade, são erros no software que, por confiança dos 
profissionais, acarretam em erro médico. Esse é apenas um exemplo muito próximo da nossa 
realidade. 
Podemos contar com, praticamente, mais de 25 tipos de testes que podem ser aplicados no 
produto de software. De todos esses tipos, sabemos que não são todos que envolvem 
necessariamente profissionais de fábrica de testes. Caso eles sejam aplicados, os erros e custos 
futuros serão certamente minimizados. 
 
 
XI SIMPEP - Bauru, SP, Brasil, 08 a 10 de novembro de 2004 
REFERÊNCIAS BIBLIOGRÁFICAS 
 
[HETZEL88] HETZEL, Bill. The Complete Guide to Software Testing. John Wiley & Sons, Inc, 
1988. 
 
[MOLINARI03] MOLINARI, Leonardo. Testes de Software. Editora Érica, 2003. 
 
[PÁDUA03] PÁDUA, Wilson de. Engenharia de Software – Fundamentos, Métodos e Padrões. 
LTC, 2001. 
 
[PFLEEGER04] PFLEEGER, Shari Lawrence. Engenharia de Software – Teoria e Prática. 
Prentice Hall, 2004. 
 
[PRESSMAN01] PRESSMAN, Roger S. Software Engineering – A Pratctitioner´s Approach – 
Mc Graw Hill, 2001. 
 
[SOMMERVILLE] SOMMERVILLE, Ian. Engenharia de Software. Editora Makron Books, 
2003. 
 
[WEBER&MALDONADO&ROCHA01] WEBER, Kival Chaves. ROCHA, Ana Regina 
Cavalcanti da. MALDONADO, Jose Carlos . Qualidade de Software – Teoria e Prática. Prentice 
Hall, 2001.