Fatos e falácias de Engenharia de Software - Testes de Software
Autor: Lucas Vegi | Publicado: 2011-11-07T19:42:00-02:00





Bom pessoal, após mais uma curta temporada sem atualizações por aqui, estou retornando para dar continuidade a série de discussões a respeito de pontos importantes da engenharia de software. O tema abordado na discussão dessa postagem divide opiniões e talvez traga comentários interessantes a respeito de experiências pessoais. Pois bem, hoje falaremos a respeito de Testes de Software.



Essa é a penúltima postagem da série inicial de discussões planejada, sendo assim aproveitem pois está acabando. =)




Universidade Federal de Viçosa
Departamento de Informática
Mestrado em Ciência da Computação
INF 622 - Engenharia de Software
Resumo nº 05               

Fatos

31 -&nbsp;Remoção de erro é a fase mais demorada do ciclo de vida.

32 - Software que um típico programador acredita ser testado várias vezes, tinha apenas cerca de 55 a 60% dos caminhos de sua lógica executada. Utilizar o suporte automatizado, como os analisadores de cobertura, pode aumentar para cerca de 85 a 90%. É quase impossível testar 100% dos caminhos lógicos de software.

33 - Mesmo se uma cobertura de 100% de teste fosse possível, isso não seria um critério suficiente para o teste. Cerca de 35% de defeitos de software emerge da falta de caminhos lógicos, e outros 40% da execução de uma combinação única de caminhos lógicos. Eles não vão ser apanhados por uma cobertura de 100%.

34 - É quase impossível fazer um bom trabalho de remoção de erro sem ferramentas. Depuradores são comumente utilizados, mas outros, como os analisadores de cobertura, não são.



Discussão

Os fatos estudados analisam os principais problemas relacionados aos testes de software. O fato 31 trata do tempo demandado para a remoção de erros de software. Muitos autores chamam essa fase do processo de desenvolvimento de software por nomes diferentes. Os nomes mais comuns de se ver são Teste, Verificação e Validação. Glass prefere chamar essa fase pelo nome de Remoção de erros, pois considera esse o nome que melhor descreve a atividade.


Segundo Glass [1], a fase de remoção de erros de software é a que gasta mais tempo em todo o processo, podendo gastar até o dobro do tempo gasto em cada uma das outras fases do processo de software (Análise de requisitos, projeto e implementação). Isso geralmente causa grandes surpresas aos desenvolvedores, pois de certa maneira, é possível mensurar o tempo demandado em um projeto para recolher requisitos, projetá-los e codificá-los, porém o tempo gasto na remoção de erros de software é muito relativo, pois este vai depender da qualidade do trabalho realizado nas outras fases do processo. Portanto, quanto pior forem executadas as fases anteriores, maior será o tempo demandado na remoção de erros.


Uma maneira eficiente para diminuir o tempo demandado para remoção de erros de software é enfatizar mais a essência do problema a ser resolvido, ou seja, quanto mais atenção for dada para a análise dos requisitos e o projeto, menor será o tempo gasto com remoção de erros, pois erros de codificação são muito mais simples e menos custosos de serem resolvidos do que erros de requisitos.

Considerando que o desenvolvimento de software seja iterativo, a remoção de erros é conseqüentemente feita também de forma iterativa durante todo o processo.

O fato 32 é relacionado à cobertura dos testes de software. Como sua própria descrição já fala, é praticamente impossível testar 100% de um software. Glass julga como ingênuas as pessoas que acreditam nessa possibilidade.

O autor classifica as abordagens de testes de software em quatro diferentes tipos:

Testes orientados a requisitos;
Testes orientados a estruturas;
Testes orientados a estatísticas;
Testes orientados a riscos;

Os dados citados pelo autor são baseados em testes estruturais, que são aqueles que verificam os caminhos lógicos de programação. Segundo Glass [1], os testes estruturais de software normalmente cobrem apenas de 55 a 60% dos caminhos lógicos de um software. Com o auxílio de analisadores automáticos de cobertura de testes fica mais fácil identificar as partes do software que ainda não foram abrangidas pelos testes, sendo assim a utilização dos mesmos aumentam a cobertura dos testes para entorno de 85 a 90% dos caminhos lógicos. É praticamente impossível atingir aos 100% de cobertura devido às obscuridades advindas da natureza do software.

É essencial a realização de testes em software utilizando as abordagens que forem relevantes ao projeto em execução, porém dificilmente as baterias de testes na qual os softwares são submetidos irão retirar todos os seus erros.

O fato 33 mostra que mesmo que fosse possível realizar testes de software com 100% de cobertura dos caminhos lógicos, isso ainda não daria garantia da criação de um software livre de erros.

Esse fato é gerado a partir da pesquisa pessoal de Glass. Ao analisar uma série de relatório de erros na indústria aeroespacial, Glass chegou à conclusão de que 35% dos erros encontrados na base de dados analisada eram erros de omissão de lógica, ou seja, requisitos que possivelmente não foram levantados e conseqüentemente não foram implementados. Esse tipo de erro não seria identificado em testes estruturais, pois esse tipo de teste é feito baseando-se na especificação do software.

Outro tipo de erro que não seria identificado mesmo com a execução de testes com 100% de cobertura seriam os erros de análise combinatória. Esses são os erros ocasionados pela combinação de caminhos lógicos. Geralmente os testes estruturais testam os caminhos lógicos separadamente, mas não a combinação deles. Esse tipo de erro de analise combinatória representaram 40% dos erros encontrados por Glass na base de dados analisada. 

Em suma, se fosse possível realizar testes de software com 100% de cobertura dos caminhos lógicos, ainda assim, apenas 25% dos erros de software seriam detectados com certeza.

O fato 34 diz respeito à falta de uso de ferramentas para as fases de back-end do desenvolvimento de software. Ao contrário das fases de front-end, onde um grande número de ferramentas para análise e projeto são difundidas e usadas, nas fases de back-end a maioria dos desenvolvedores utiliza apenas ferramentas depuradoras, ignorando analisadores automáticos de cobertura de testes e outras ferramentas.

Há vários fatores que contribuem para a falta de atenção despendida pelos desenvolvedores às ferramentas de back-end. Dentre esses fatores, a super atenção dada às ferramentas de front-end é um dos motivos, pois ao atacar a essência do software no front-end e codificarem seguindo padrões, alguns desenvolvedores acreditam ser desnecessário despender atenção às fases de testes e manutenção.

Em estudo realizado por Zhao e Elhaum [4], foi demonstrado que em apenas 39,6% dos projetos de software-livre, alguma ferramenta de teste foi utilizada e a grande maioria dessas ferramentas eram depuradores. Muito provavelmente esses dados refletem de forma semelhante à situação de projetos de software de uma forma geral, não apenas de software-livre. Porém o motivo principal desse acontecimento em projetos de software livre é a crença na “Lei de Linus”, descrita por Raymond [5] da seguinte maneira: “Dado uma base grande o suficiente de beta-testers e co-desenvolvedores, praticamente todo problema será caracterizado rapidamente e a solução será óbvia para alguém”. 

Isso pode ser uma verdade em projetos de software livre detentores de comunidades ativas, entretanto não tem como os desenvolvedores garantirem a existência de uma grande quantidade de pessoas interessadas em colaborar com a evolução do software para fazer assim valer a Lei de Linus. Dessa maneira é muito perigosa essa falta de atenção à utilização de ferramentas nas fases de back-end do desenvolvimento.

Controvérsia
No fato 31 a maior controvérsia está relacionada à descrença de que a remoção de erros gaste tanto tempo do processo de software. Porém, segundo Glass [1], em média 20% do tempo do processo é gasto com a análise de requisitos, outros 20% projetando, mais 20% codificando e impressionantes 40% removendo erros. O dobro gasto em cada uma das outras fases.

Considerando que desenvolver software é uma tarefa complexa e propensa a erros, é muito improvável que surjam técnicas para a construção de software que o livre de erros a serem removidos nos testes, porém fica claro pelos estudos de Glass que ao focar mais atenções na essência do problema a ser resolvido, o número de erros cai consideravelmente.

No fato 32, a maior controvérsia está relacionada à noção de softwares isentos de erros. Muitos especialistas consideram ser possível isso ser feito, embora na prática isso só aconteça geralmente para software de pouca complexidade. O objetivo ideal para projetos de software complexos é realização de testes que garantam que o software esteja isento de erros críticos.

Muitas equipes não dão a atenção adequada para a fase de testes de software e a grande maioria não utiliza nenhuma ferramenta que analise automaticamente a cobertura dos testes já realizados na estrutura. Essa falta de motivação para utilizar ferramentas que automatizem a analise de cobertura geralmente ocorre por não acharem viável investir recursos para isso ou até mesmo pelo desconhecimento dessas ferramentas.

O Emma é uma ferramenta open source que ajuda nesta tarefa, fazendo a análise da cobertura de testes de um projeto Java e gerando um relatório em formato texto ou HTML. Esse relatório representa um feedback importante para os desenvolvedores, pois indica quais áreas do projeto ainda não estão sendo cobertas por testes automatizados e portanto devem ser tratadas prioritariamente [2]. 

A figura 1 apresenta um exemplo de relatório gerado pela ferramenta Emma. Esse relatório informa a porcentagem de cobertura de teste em cada parte da estrutura de um software.&nbsp;



Figura 1: Relatório HTML para cobertura de teste
no Apache Velocity 1.4

Para maiores informações sobre a ferramenta Emma, consulte o site oficial da mesma em [3].

A controvérsia ao fato 33 é referente ao desconhecimento da informação dada pelo mesmo. A pesquisa realizada por Glass que o proporcionou chegar a tal conclusão não foi devidamente divulgada, sendo assim muitos pesquisadores discordaram desse fato por desconhecerem a pesquisa.

Não existe bala de prata capaz de proporcionar o desenvolvimento de um software isento de erros, porém a combinação das abordagens de testes, juntamente com uma maior atenção demandada à essência do software, proporciona softwares com o menor número de erros.

Existem poucas controvérsias a respeito do fato 34. Talvez o motivo disso não seja relacionado à concordância ou discordância com o fato, mas sim com a falta de interesse nele.

Referências
[1] Glass, Robert L. 1992. Software Quality Building. Englewood Cliffs, NJ: Prentice-Hall. Englewood Cliffs, NJ: Prentice-Hall.

[2] TELES, V. M. Cobertura de Testes na Prática. Disponível em : http://www.devmedia.com.br/articles/viewcomp.asp?comp=8973. Acesso em 22 Maio. 2010.

[3] EMMA: a free Java code coverage tool. Disponível em: http://emma.sourceforge.net/index.html. Acesso em 22 Maio. 2010.

[4] Zhao, Luyin e Elbaum Sebastian. "A Survey on Quality Related Activities in Open Source." Software Engineering Notes, May. 2000.

[5] RAYMOND, E.S. The Cathedral and Bazaar. O’Reilly Books, 1999.