Desenvolvendo a atividade de teste de software – parte 1

Conforme definido por Sommerville, um processo de produção de software estabelece procedimentos sistemáticos que possibilitam a construção de um produto caracterizado como software. O processo pode ser dividido em atividades (ou subprocessos). Essas atividades também podem ser subdivididas, gerando assim, as tarefas. A partir desta definição podemos concluir que a tarefa é a menor unidade de execução dentro de um processo. Geralmente, todo processo de software possui as seguintes atividades: Levantamento de requisitos, modelagem de negócio (análise de sistemas), projeto de software, programação, teste, implantação e manutenção.

A atividade de teste é dividida em teste de caixa preta e teste de caixa branca. No primeiro a equipe de teste não tem a acesso ao código fonte do programa. Para executar o teste de caixa preta é necessário definir os casos de testes, definir os dados de teste, executar os testes e verificar os resultados (temos aqui 4 tarefas).

A definição dos casos de teste tem como objetivo delimitar o que deve ser testado, os recursos necessários para execução do teste (hardware e software) e as técnicas a serem utilizadas na definição dos dados de teste.

Delamaro et. al. enumera uma série de técnicas, neste post vou apresentar 4 delas: teste exaustivo, particionamento em classe de equivalência, análise do valor limite e o teste funcional.

No teste exaustivo, todas as possibilidades são testadas, ou seja, eu testo todos os possíveis dados de entrada. Para exemplificar esta técnica parta do princípio que você tem que testar um programa com duas entradas numéricas inteiras. A linguagem de programação que você utiliza delimita que o número inteiro possui 32 bits. Neste caso teríamos que executar o teste de 232 * 232, ou seja, 264 entradas. Vamos supor também que a máquina utilizada no teste  processa o referido programa em 1 milissegundo. Transformando 264 milissegundos em séculos, chegaríamos à casa de 5.849.424.

Ao analisar o exemplo acima podemos concluir que o teste exaustivo é inviável na definição dos dados de teste. Com base nesta afirmação, Delamaro et. al. apresenta a utilização da técnica de particionamento em classe de equivalência.

Para exemplificar esta técnica, vamos supor que o testador tem como tarefa definir os dados para executar o teste de um programa que deve verificar se um número inteiro encontra-se no intervalo fechado de 0 a 10. Ao aplicar o particionamento em classes de equivalência a quantidade de entradas e, conseqüentemente, de execução para este programa é 3 (3 classes – entrada negativa, entrada dentro do intervalo, entrada positiva superior ao limite do intervalo). A tabela abaixo apresenta os dados de entrada e a saída que deve ser emitida pelo programa em questão.

Dados                   Saída

-3                           número fora o intervalo

4                             número dentro do intervalo

15                           número fora do intervalo

A técnica de análise do valor limite possibilita que dados próximos a fronteira das entradas sejam inseridos na folha de teste. Neste caso a tabela para execução das entradas e a saída a ser emitida pelo programa anterior deve possuir a seguinte configuração:

Dados                   Saída

-3                           número fora o intervalo

4                             número dentro do intervalo

15                           número fora do intervalo

-1                           número fora do intervalo

0                             número dentro do intervalo

1                             número dentro do intervalo

9                             número dentro do intervalo

10                           número dentro do intervalo

11                           número fora do intervalo

Ao analisar a definição e a tabela apresentada para a técnica em questão é possível concluir que:

1 – A técnica de analise do valor limite está baseada na técnica de particionamento em classes de equivalência, pois o referido teste levou em consideração os números dentro e fora (duas classes) do intervalo.

2 – Números próximos e imediatamente superiores ao limite das variáveis também devem ser testados. Supondo que a linguagem de programação utilizada para construção do referido programa estabelece que o número inteiro possua 16 bits. Teríamos que incluir na folha de teste os seguintes dados: –32769, -32768, -32767, 32766, 32767, 32768. O primeiro e o último número da seqüência estão fora do limite da variável. Esta informação deve ser validada e informada ao usuário quando um dado como este for digitado.

Já o teste funcional provê subsídios para que o testador possa inserir dados de tipos diferentes daqueles definidos no documento de especificação. Neste caso além de testar os dados apresentados na tabela 2 é necessário:

1 – testar o comportamento do programa quando a entrada for uma letra.

2 – testar o comportamento do programa quando a entrada for um caractere especial ex: {!   ;   – }.

3 – Testar o programa quando a entrada for nula.

4 – Testar o programa quando a entrada for um espaço em branco.

Em todos os testes acima, a saída emitida pelo programa é: “entrada inválida”.

Por fim, o teste de caixa branca está ligado à idéia de inspeção de código. Seu objetivo é verificar anomalias no referido artefato. Este texto apresenta alguns itens a ser inspecionado em qualquer código fonte:

1 – O código fonte segue as prerrogativas estabelecidas pelo padrão de código. Se o processo norteia a utilização do Java Code Convention o código deve seguir a referida convenção.

2 – Verificar se todas as variáveis declaradas estão sendo utilizadas durante o processamento das informações.

É importante salientar que atividade de teste possui uma grande gama de conceitos, este texto apresentou alguns que podem (de imediato) ser implementados pelo setor produtivo de software. No próximo post apresentarei como institucionalizo tais conceitos em uma empresa produtora de software.

Abraços

José Augusto Fabri

fabri@femanet.com.br

Referências:

Delamaro, et. al. Introdução ao teste de software. Campus. 2007.

Sommerville. I. Engenharia de Software.

2 Responses to “Desenvolvendo a atividade de teste de software – parte 1”

  1. Felipe Fernandes Says:

    Olá GUTO, legal esse post, pois muita gente não sabe que a disciplina de teste EXISTE e está crescendo muito no mercado de trabalho e é uma disciplina tão importante quanto o desenvolvimento(programação), pois reduz muitos o custo de um sistema na fase de produção e na qualidade.

    Para quem quiser saber mais sobre esse mercado, certificações, ferraments de automatização é só falar.

    Abração…

  2. Prof. Guto, muito legal este relato sobre Teste de Software, por que é um das tarefas principais para verificação de erro por parte dos desenvolvedores.

    Para este post, gostaria de passar uma visão geral do MANTIS, que é uma ferramenta de gestão de defeitos muito utilizada pelas empresas que adotam uma política de controle de testes e qualidade.

    São 6 níveis de usuários, (Visualizador, Relator, Atualizador, Desenvolvedor, Gerente e Administrador) cada qual possui diferentes níveis de atribuições e permições dentro do sistema, um Visualizador por exemplo pode apenas ver os registros de erros efetuados, e o Administrador tem poderes completos.

    Os casos reportados (issues) são separados por projetos e sub-projetos, dessa forma ficam bem organizados dentro do sistema. Assim que são salvos, os casos são designados a um usuário, que receberá um email notificando-o como responsável pela resolução do bug. Após solucionar o erro, o responsável terá que responder ao remetente que avaliará se o caso pode ser encerrado ou não. Todas as ações são gravadas em logs que irão gerar relatórios consistentes sobre o andamento dos casos dentro de um projeto.

    Com o Mantis, um gerente de projetos por exemplo, poderá ter um controle total dos erros encontrados pelos testadores e o tempo de resposta por parte dos desenvolvedores e quais desenvolvedores estão com quais erros. Existe também uma opção que permite a um usuário acompanhar um caso e ser avisado sobre qualquer alteração no seu registro.

    Estas são apenas algumas das diversas funcionalidades do sistema.

    Grato,

    Jedson
    Instituto Tecnológico de Aeronáutica – ITA

    Referência:

    [1] Disponível em: http://www.testexpert.com.br/?q=node/677. Acesso em 19/05/2009.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: