Curso de Engenharia de Computação

PROCESSOS DE TESTE DE SOFTWARE

Elio Trevisan Junior

Itatiba – São Paulo – Brasil

Novembro de 2007
 ii

Curso de Engenharia de Computação

PROCESSOS DE TESTE DE SOFTWARE

Elio Trevisan Junior

Monografia apresentada à disciplina: Trabalho de

Conclusão de Curso, do Curso de Engenharia de
Computação da Universidade São Francisco, sob a
orientação do Prof. Ms/Adalberto Nobiato Crespo, como
exigência parcial para conclusão do curso de graduação.

Orientador: Prof. Dr./Ms. Adalberto Nobiato Crespo

Co-orientador: Prof. Dr./Ms. Alencar de Melo Junior

Itatiba – São Paulo – Brasil

Novembro de 2007
 iii

Processos de Teste de Software

Elio Trevisan Junior

Monografia defendida e aprovada em 12 de Dezembro de 2007 pela Banca

Examinadora assim constituída:

Prof Ms/Dr Adalberto Nobiato Crespo (Orientador)

USF – Universidade São Francisco – Itatiba – SP.

Prof Ms/Dr Alencar de Melo Junior (Co-Orientador)

USF – Universidade São Francisco – Itatiba – SP.

Prof Ms/Dr Rodrigo Prado (Membro Interno)

USF – Universidade São Francisco – Itatiba – SP.

Prof Ms/Dr Thales Cezare (Membro Interno)

USF – Universidade São Francisco – Itatiba – SP.

.
 iv

Agradecimentos

Agradeço primeiramente aos meus familiares, minha namorada, e em especial aos meus pais
que sempre acreditaram no meu potencial e me incentivaram nas horas mais difíceis.

Agradeço também ao Professor Adalberto Nobiato Crespo, meu orientador, que acreditou em
mim e incentivou-me para a conclusão deste trabalho.

Agradeço também ao Professor e Coordenador do curso de Engenharia de Computação,

Alencar de Melo Junior, um companheiro de percurso pelo convívio, pelo apoio, pela
compreensão e pela amizade.

Eu agradeço fraternalmente a todos.

 v

Sumário

Resumo......................................................................................................................................vi

Abstract.....................................................................................................................................vi

1 Introdução...........................................................................................................................1
1.1 Objetivo .........................................................................................................................2
1.2 Metodologia...................................................................................................................2

2 Processo de teste .................................................................................................................2

2.1 Definição de processo de teste.......................................................................................2
2.2 Caracterização do processo de teste ..............................................................................3
2.3 Níveis de teste................................................................................................................4
2.4 Tipos de testes ...............................................................................................................5
2.5 Técnicas de teste............................................................................................................6

3 Documentação do Processo de Teste ................................................................................8

4 Um Processo Genérico de Teste ......................................................................................11

4.1 Preparação para o teste de software.............................................................................12
4.2 Execução do teste de software.....................................................................................14
4.3 Fluxograma de execução do teste de software ............................................................15

5 Processo de Teste do Método PRAXIS...........................................................................18

5.1 Planejamento dos testes ...............................................................................................21
5.2 Desenho dos testes.......................................................................................................21
5.3 Implementação dos testes ............................................................................................21
5.4 Execução dos testes .....................................................................................................22
5.5 Verificação do término dos testes................................................................................22
5.6 Balanço final dos testes ...............................................................................................22

6 Ferramentas para Auxílio no Gerenciamento de Casos de Teste................................22

6.1 Testlog .........................................................................................................................23
6.2 Testlink ........................................................................................................................26

7 Conclusão ..........................................................................................................................30

Referências Bibliográficas......................................................................................................31
 vi

Resumo

Este trabalho tem como objetivo o estudo em detalhes do processo de teste de

software. Desta forma, define – se o processo de teste de software e caracteriza – se o
processo, descrevendo – se os níveis de teste de software, os tipos de teste de software, as
técnicas de teste de software e a documentação do processo de teste. Apresenta – se um
modelo abrangente de processo de teste associado ao processo de desenvolvimento de
software. No modelo apresentado (Modelo V), são consideradas as fases e os níveis de teste
do software. Apresenta – se também um exemplo de modelo de processo de teste encontrado
na literatura. Para apoiar o processo de teste são apresentadas algumas ferramentas para
auxílio no gerenciamento de casos de teste.

Abstract

This work aims to study in detail the process of testing software. Thus, defined as the
process of testing software and features is the process, describing it is the levels of test
software, the types of test software, the techniques of software testing and documentation of
the test. It presents a model comprehensive process of testing associated with the process of
developing software. In the model presented (Model V), are considered the stages and levels
of testing of the software. It is also an example of model test procedure found in the literature.
To support the process of testing are presented some tools to help in the management of cases
of test.
 1

1 INTRODUÇÃO

O desenvolvimento de sistemas de software envolve uma série de atividades de

produção em que as oportunidades para injetar a falibilidade humana são enormes. Erros
podem vir a ocorrer até no início do processo, onde os objetivos podem ser errôneos ou
imperfeitamente especificados. Além disso, erros podem ocorrer em estágios posteriores de
projeto e desenvolvimento. Por causa da inabilidade humana de realizar e de se comunicar
com perfeição, o desenvolvimento é acompanhado por uma atividade de garantia de
qualidade. [PRESSMAN,2002]
Teste de software é o processo de executar o software de uma maneira controlada com
o objetivo de avaliar se o software se comporta conforme especificado. O teste é uma
atividade fundamental para assegurar que o software atende aos requisitos do usuário e é a
avaliação final da qualidade do produto desenvolvido.
Teste de software é um elemento crítico da garantia de qualidade de software e
representa a revisão final da especificação, projeto e geração de código. [PRESSMAN,2002]
Para todo e qualquer processo do desenvolvimento de software, o teste, realizado
durante ou após o desenvolvimento do software, requer um processo bem definido que oriente
a sua realização.
Este documento tem como propósito descrever as atividades que compõem um
processo de teste de software, abordar as técnicas de teste, os tipos de teste, critérios de teste.
O processo descrito pode ser instanciado para diversos domínios de aplicação, não estando
restrita sua utilização a tamanho, complexidade ou criticalidade do software.
Nunca se deu tanto valor à qualidade do software como hoje e os testes nunca foram
levados tão a sério. Todas as grandes empresas, se já não tem, estão montando seus
laboratórios de teste e investindo na especialização de mão de obra qualificada.
 2

1.1 Objetivo
O objetivo deste trabalho de conclusão de curso é estudar em detalhes o processo de
teste de software. Compreender as técnicas de teste de software mais utilizadas. Estudar a
documentação necessária ao se testar um produto de software, desde a preparação do teste até
o registro dos resultados do teste. Finalmente, apresentar algumas ferramentas que apóiam o
processo de teste de software.
Este trabalho está organizado da seguinte maneira. O Capítulo 2 contém a definição de
processo de teste, caracterização de processo de teste de software, descrição dos níveis de
teste, descrição dos tipos de teste e das técnicas de teste. O Capítulo 3 contém a descrição da
documentação do processo de teste. O Capítulo 4 contém a descrição de um modelo
abrangente de processo de teste de software. O Capítulo 5 traz um exemplo de processo de
teste de software. O Capítulo 6 traz alguns exemplos de ferramentas para auxílio no
gerenciamento de casos de teste.

1.2 Metodologia
O estudo do processo de teste de software será realizado seguindo as seguintes etapas:
levantamento da bibliografia inicial, estudo da bibliografia inicial, desenvolvimento do plano
inicial, entrega e apresentação do plano inicial, levantamento e estudo da bibliografia
complementar, desenvolvimento do TCC e da apresentação, estudo das técnicas de teste,
conclusão dos estudos das bibliografias, desenvolvimento da monografia, desenvolvimento da
apresentação e entrega da monografia e apresentação.

2 PROCESSO DE TESTE

2.1 Definição de processo de teste

Um processo de teste de software é um conjunto de passos parcialmente ordenados
constituídos por atividades, métodos e práticas, usadas para testar um produto de software.
Um processo de teste de software possui como subprocessos o planejamento, o projeto, a
execução e o registro do teste, e tem as seguintes características: utiliza recursos; está sujeito a
um conjunto de restrições; gera artefatos (plano, projeto, casos de teste, relatórios de
execução); pode ser definido como uma hierarquia de subprocessos, organizados de tal
 3

maneira que cada subprocesso tenha seu próprio modelo de processo; cada subprocesso é
composto de atividades; cada subprocesso tem critérios de início e término; e as atividades de
um subprocesso são organizadas em uma seqüência.

2.2 Caracterização do processo de teste

Em qualquer desenvolvimento de software a atividade de teste deve ser realizada
segundo um processo de teste previamente caracterizado. Para caracterizar um processo de
teste é necessário especificar os seus elementos segundo a visão associada ao processo de
software, composta pelos níveis de teste correspondentes às fases do desenvolvimento, pelos
tipos de teste e pelas técnicas e critérios de teste. A figura 1 ilustra os elementos dessa visão.
A caracterização do processo de teste é completada pelo detalhamento das atividades
de planejamento, projeto, execução e registro do teste, considerando os elementos
anteriormente especificados.

Teste de Funcionalidade
Teste de Interface
O que testar Teste de Desempenho
Tipo de Teste Teste de Carga (Stress)
Teste de Usabilidade
2a.
Teste de Volume
Teste de Segurança Particion. de Equivalencia
Análise de Valores Limites
Baseado em Casos de Uso
Como testar
3a.
Técnica de Teste Teste Funcional
Critérios
Teste Estrutural
Quando testar
1a.
Fase do Níveis de Teste
Desenvolvimento Teste de Unidade Teste de Caminhos
de Software Teste de Integração Teste de Comandos
Teste de Sistema Teste de Ramos
Teste de Aceitação Teste de Condições
Teste de Regressão Teste de Cond. Múltiplas

Figura 1: Visão do Processo de Teste segundo Níveis, Tipos e Técnicas e Critérios de Teste.

A caracterização do processo de teste de software depende da política de teste adotada

pela empresa. Uma empresa pode caracterizar um processo de teste de uma única maneira, ser
aplicado em qualquer produto de software por ela desenvolvido, ou seja, o seu modelo de
processo de teste de software é fixo. Uma outra empresa pode caracterizar seus processos de
 4

teste de acordo com vários tipos de produtos de software desenvolvidos por ela, ou seja, o
modelo de processo de software da empresa é configurável.
O processo de teste a ser aplicado em produto de software específico deve ser
caracterizado de acordo com o modelo de processo de software adotado pela empresa. Cada
modelo de processo de software define seus subprocessos e produtos correspondentes, que
serão utilizados para estabelecer os requisitos de teste do produto final. Exemplos: a análise
de requisitos produz os requisitos que serão utilizados para projetar os casos de teste de
aceitação; o projeto da arquitetura do software produz a arquitetura do programa que será
utilizada para projetar os casos de teste de integração.

2.3 Níveis de teste

O nível de teste é determinado pelo artefato de software utilizado para derivar os
requisitos de teste; ou seja, a cada fase inicial do processo de software, corresponde um nível
de teste.
Os níveis de teste são:
Teste de Unidade: É o nível de teste cujos requisitos são derivados do projeto dos
módulos e é aplicado para verificar se o módulo corresponde ao seu projeto.
Teste de Integração: É o nível de teste cujos requisitos são derivados da arquitetura do
sistema e é aplicado para verificar se os módulos executam corretamente quando integrados.
Teste de Sistema: É o nível de teste cujos requisitos são derivados da especificação de
requisitos funcionais e não funcionais e é aplicado para verificar se o software e o hardware
executam corretamente quando integrados ao ambiente de operação.
Teste de Aceitação: É o nível de teste cujos requisitos são derivados da especificação
de requisitos do usuário e é aplicado para verificar se o sistema satisfaz as expectativas do
usuário.
Teste de Regressão: É o nível de teste normalmente aplicado durante a fase de
manutenção do software; consiste na reaplicação de casos de teste após qualquer tipo de
alteração do software. Pode ser eventualmente aplicado após a correção do software
provocada por defeitos encontrados durante qualquer outro nível de teste.
 5

2.4 Tipos de testes

O tipo de teste define a característica do software que deve ser testada.
Os tipos de testes são:
Teste de Funcionalidade: objetivo é a validação das funcionalidades requeridas nos
serviços, métodos e use cases.
Teste de Interface: Os testes de interfaces ocorrem quando módulos ou subsistemas
são integrados para criar sistemas maiores. O teste de interface tem como objetivo detectar
erros que possam ter sido introduzidos no sistema, em razões de erros ou suposições inválidas
sobre as interfaces.
Teste de Desempenho: tem como objetivo testar o desempenho de execução do
software dentro de um contexto de um sistema integrado. O teste de desempenho é, às vezes,
combinado com teste de estresse e freqüentemente existe instrumentação de hardware e de
software. O teste de desempenho preocupa-se com tempo de resposta, rendimento e
capacidade (principalmente com a capacidade do banco de dados).
Teste de Carga: Também conhecido com teste de estresse consiste em aumentar a
carga do sistema até que o desempenho do sistema se torne inaceitável (falhe). O teste de
carga tem duas funções: Primeira testa o comportamento de falha do sistema, podem surgir
circunstâncias por meio de uma combinação inesperada de eventos, quando a carga colocada
no sistema excede a carga máxima prevista. A segunda causa estresse no sistema e pode
acarretar a detecção de defeitos que, não se manifestariam. Os testes de cargas são relevantes
para sistemas distribuídos, com base em rede de processadores.
Teste de Usabilidade: é um processo em que participantes representativos avaliam o
grau que um produto se encontra em relação a critérios específicos de usabilidade. Foca nos
fatores humanos, estética, consistência da interface com o usuário, help on-line e agentes,
manual e material de treinamento. Testes de usabilidade são mais eficientes quando
implementados como parte do processo de desenvolvimento de um produto.
Teste de Volume: objetivo do teste de volume é submeter grandes quantidades de
dados ao sistema para determinar limites que causam a falha do software, ele também
identifica a carga ou volume máximo persistente que o sistema suporta por um determinado
período.
Teste de Segurança: visa verificar se todos os mecanismos de proteção embutidos no
sistema o protegerão de fato de acesso indevidos. Objetivo é garantir que o sistema se
comporte adequadamente mediante tentativas ilegais de acesso.
 6

2.5 Técnicas de teste

Técnica de Teste é uma técnica que abrange os critérios de teste cujos elementos
requeridos são derivados a partir dos mesmos aspectos do software.

As técnicas de teste são:

Teste Funcional: É uma técnica de teste que abrange os critérios de teste cujos
elementos requeridos são derivados a partir da especificação de requisitos funcionais do
software. O sistema é uma caixa preta e seu comportamento pode ser determinado estudando
as entradas e saídas relacionadas, também é chamado de testes de “caixa preta”. O teste
funcional procura descobrir funções incorretas ou ausentes, erros de interface, erros nas
estruturas de dados ou no acesso a banco de dados externo, erros de desempenho, erros de
inicialização e término.
Exemplos de teste funcional:
Teste de Partições de Equivalência: técnica que baseia-se em identificar todas as
partições de equivalência que tenham de ser manuseadas por um programa, os casos
de testes são projetados de modo que as entradas e as saídas fiquem dentro dessas
partições.

Teste de Valores Limites: técnica que leva à seleção de casos de teste que exercitam os
valores limítrofes. Análise de valor de limite é uma técnica que completa o
particionamento de equivalência, em vez de selecionar qualquer elemento de uma
classe de equivalência, a análise de valor limite leva a seleção de casos de teste nas
“bordas” da classe, elas focalizam nas condições de entrada e nas condições de saída.

Teste Baseado em Casos de Uso: técnica que direciona o testador a construir casos de
teste de maneira que os casos de uso associados aos requisitos sejam testados. Casos
de uso incorporam informações importantes para a geração de casos de teste
Teste Estrutural: É uma técnica de teste que abrange os critérios de teste cujos
elementos requeridos são derivados a partir da implementação do software, também é
chamado de testes de “caixa branca”. O teste estrutural objetiva verificar se a estrutura interna
da unidade está correta. É efetuada para todos os casos de teste que visam percorrer todos os
caminhos internos possíveis da unidade. São aplicados a unidades de programa pequenas,
como sub – rotinas, ou às operações associadas com um objeto. Exemplos de teste estrutural:
 7

Teste de Ramos: técnica que direciona o testador a construir casos de teste de tal forma
que cada condição do programa seja executada pelo menos uma vez. O teste de ramos
é um critério mais forte que o teste de comandos, no sentido de exercitar o programa.
Teste de Comandos: técnica que direciona o testador a construir casos de teste de tal
forma que cada comando do programa seja executado pelo menos uma vez. A
cobertura de comandos é um dos critérios menos exigentes no sentido de exercitar o
programa.

Teste de Caminhos: o objetivo desta técnica é exercitar cada caminho de execução

independente, por meio de um componente ou programa. Se cada caminho
independente for executado, todas as declarações no componente devem ter sido
executadas pelo menos uma vez. Todas as declarações são testadas para casos
verdadeiros e os falsos. Os testes de caminhos são utilizados nos estágios de teste de
unidades e teste de módulo do processo de teste.

Teste de Condições: método que exercita as condições lógicas contidas em um módulo

de programa, o teste de condições focaliza o teste de cada condição do programa, as
estratégias de teste de condição tem geralmente duas vantagens: primeira a medida da
cobertura de teste de uma condição é simples e a segunda a cobertura de teste das
condições de um programa das diretrizes para a geração de testes adicionais para o
programa.

O objetivo do teste de condição é detectar não apenas erros nas condições de um

programa, mas também outros erros de programas.

Teste de Condições Múltiplas: tem como objetivo construir casos de teste em que
todas as condições sejam executadas e cada alternativa numa condição múltipla seja
executada pelo menos uma vez. A cobertura de condição múltipla é um critério mais
forte do que a cobertura de condições.
Caracterizar processo de teste é definir em que fase do desenvolvimento o software
será testado. Faz parte da caracterização especificar quais tipos de teste serão aplicados e qual
técnica de teste será adotado. Finalmente definidas as fases de teste, o tipos de teste, e a
técnica, escolhe – se os critérios para a geração dos casos de testes.
 8

3 DOCUMENTAÇÃO DO PROCESSO DE TESTE

A documentação do processo de teste está dividida em duas partes. Os documentos

que tratam da preparação para o teste e documentos que tratam do registro dos resultados do
teste.
Os documentos para a preparação do teste estão associados ao ramo esquerdo do
modelo V do processo de teste, exemplificado na figura 3.
Essa documentação é baseada na Norma IEEE – 829, criada em 1998 pelo DoD,
Departamento de Defesa Americano.
Esses documentos são:

Plano de Teste: descreve o planejamento de todas as atividades envolvidas no teste de

um software. Além das atividades, o Plano de Teste deve conter a extensão do teste, a
abordagem utilizada no teste, os recursos necessários, o cronograma das atividades de
teste e a definição do ambiente operacional para a execução dos testes. O Plano de
Teste identifica os itens do software a serem testados, o nível em que os itens devem
ser testados, a abordagem utilizada para testar cada um dos itens, as tarefas envolvidas
em cada atividade de teste, as pessoas responsáveis por cada atividade e os riscos
associados ao plano de teste.

Projeto de Teste: conjunto de atividades para: 1 - Refinar a abordagem de teste de

software definida no planejamento; 2 - Definir e especificar os casos de teste; 3 -
Estabelecer requisitos de ambiente de teste; 4 - Definir e especificar os procedimentos
de teste. Os resultados dessas atividades são registrados no documento denominado
Especificação de Projeto de Teste.
Casos de Teste: conjunto de dados de entrada e os respectivos resultados esperados da
execução. Identificar todas as bases de dados, arquivos, mensagens de terminais, áreas
de memória residente e valores passados pelo sistema operacional, associados à
execução de cada caso de teste.

Relatório de Encaminhamento de Item de Teste

Os documentos para o registro dos testes estão associados ao ramo da direita do modelo V do
processo de teste, exemplificado na figura 3.
Esses documentos são:
 9

Diário de Teste: registra detalhadamente o andamento das atividades de execução do

teste e contém Descrição do Teste; e Registros de Atividades e Eventos.
Relatório de Incidente de Teste: registra cada incidente de teste e contém Resumo do
Incidente de Teste e Descrição do Impacto do Incidente de Teste.

Relatório Resumo de Teste: é uma síntese dos resultados das atividades de teste e
contém Resumo dos Itens de Teste; Desvios das Especificações; Avaliação da
Abrangência do Teste; Resumo de Resultados; Avaliação dos Itens de Teste; e
Resumo de Atividades.
A Figura 2 ilustra os vários documentos gerados na fase de preparação do teste e na fase de
registro dos resultados do teste.
 10

Plano
de
Teste

Especificação de Especificação de
Especificação de
Projeto de Teste Projeto de Teste
Projeto de Teste
Preparação
do Teste

Especificação de
Casos de Teste
Relatório de
Especificação de
Encaminhamento
Procedimentos de
de Item de Teste
Teste

Execução
do Teste Execução do Teste

Diário Diário
de de
...
Teste Teste

Registro
Relatório de Relatório de
...
Incidentes de Teste Incidentes de Teste

do Teste

Relatório-Resumo
de
Teste

Figura 2: Atividades do Processo de Teste e Documentos Associados

 11

4 UM PROCESSO GENÉRICO DE TESTE

Nesta etapa é apresentado um modelo abrangente de processo de teste que considera

vários níveis de teste e de atividades. O modelo apresentado é genérico, pois não está
associado ao teste de um tipo de software em particular nem a um específico processo de
desenvolvimento de software.
O modelo apresentado é o Modelo V um dos mais adotados para o teste de software.
Esse modelo considera as principais fases do processo de software, associando a cada nível de
teste de software correspondente. A figura 3 traz uma ilustração do Modelo V. O ramo
esquerdo do modelo correspondente à preparação do teste de software, tendo como referência
das fases do processo de desenvolvimento de software.

Fases do Processo Níveis do Teste de

de Software Software

Especificação de Requisitos do Usuário Teste de

Requisitos Aceitação

Especificação do Especificações Funcional e Teste de Sistema

Sistema Não Funcional

Projeto do Arquitetura do Teste de

Sistema Sistema Integração

Projeto de Projeto Teste de

Unidade Unidade

Codificação de
Unidade

Figura3: Modelo V de Teste de Software

 12

O ramo direito corresponde à execução e registro do teste, tendo como referência os

níveis de teste de software.
Durante as etapas iniciais do processo de software é feita a preparação do teste
compreendendo o planejamento e o projeto de teste.
A fase de Especificação de Requisitos: produz os requisitos do usuário que são
utilizados para a determinação dos requisitos do Teste de Aceitação. O teste de aceitação
verifica se o sistema satisfaz os requisitos do usuário.
A fase de Especificação do Sistema: produz as especificações Funcionais e Não
Funcionais que são utilizadas para a determinação dos requisitos do Teste de Sistema. O teste
de sistema verifica se as funções estão implementadas no sistema e as características estão
satisfeitas.
A fase de Projeto do Sistema: produz a arquitetura do sistema que estabelece os
relacionamentos entre os componentes do sistema utilizados para a determinação dos
requisitos do Teste de Integração. O teste de integração verifica se esses relacionamentos
estão implementados corretamente.
A fase de Projeto de Unidade: produz o projeto dos módulos do sistema utilizado para
a determinação dos requisitos do Teste de Unidade. O teste de unidade verifica se esses
módulos estão codificados corretamente.

4.1 Preparação para o teste de software

Preparação para o Teste de Software do Modelo V, ilustra os artefatos de teste que são
gerados a partir dos artefatos de especificação e projeto de software produzido nas fases
iniciais do processo de desenvolvimento do software.
O Plano de Teste: é elaborado inicialmente a partir dos requisitos do usuário; as
especificações funcionais e não funcionais são utilizadas para detalhar o plano de teste, que
pode ser mais refinado a partir da definição da arquitetura do sistema. Ou seja, o plano de
teste é produzido a partir dos artefatos que foram gerados nas fases de especificação de
requisitos, especificação do sistema e projeto do sistema e é complementado com informações
geradas nas especificações de projeto de teste.
 13

Fases do
Processo Especificação Especificação Projeto do Projeto de
de Software de Requisitos do Sistema Sistema Unidade

Artefatos de Requisitos Especificações Arquitetura do

Software do Usuário Funcional e Não Sistema
Projeto
Funcional

Planejamento e
Projeto de Teste
Artefatos de Projeto do Teste Projeto do Teste Projeto do Teste Projeto do Teste
Teste de Aceitação de Sistema de Integração de
Unidade

Plano Legenda:

de : atualização

Teste : geração

Figura4: Preparação para o Teste de Software

O Projeto de Teste de Aceitação: é elaborado em sua versão inicial a partir dos

requisitos do usuário. Nesta fase, os requisitos do usuário definidos não contêm informações
suficientes para a especificação dos casos de teste nem para a especificação dos
procedimentos de teste, que devem ser completamente especificadas em fases posteriores. No
entanto, podem ser estabelecidos os critérios de Teste de Aceitação do Sistema.
O Projeto de Teste de Sistema: é elaborado a partir das especificações funcional e não
funcional do sistema, incluindo as informações da especificação de casos de teste e da
especificação de Procedimentos de Teste.
O Projeto de Teste de Integração: é elaborado a partir da arquitetura do sistema,
incluindo as informações da especificação de casos de teste e da especificação de
procedimentos de teste.
O Projeto de Teste de Unidade: é elaborado a partir do projeto de Unidade, incluindo
as informações da especificação de casos de teste e da especificação de procedimentos de
teste.
 14

A Figura 4 ilustra os artefatos que são gerados na fase de preparação para o teste de
software.

4.2 Execução do teste de software

O ramo Execução do Teste de Software do Modelo V, ilustra as atividades de
execução do teste em que os artefatos durante a preparação do teste são utilizados; além disso,
ilustra também os artefatos resultantes dessas atividades. Na execução de cada um dos níveis
de teste os projetos de teste correspondentes são utilizados para direcionar a atividade de teste.
Na execução de cada um dos níveis de teste os projetos de teste correspondentes são
utilizados para direcionar a atividade de teste.
Cada um dos níveis de teste pode ser iterado em ciclos de: detecção de defeitos,
depuração e correção de defeitos, e a reaplicação dos casos de teste. Além disso, pode ocorrer
a necessidade de se retornar a um nível anterior de teste, por exemplo, no teste de aceitação
detectar-se um problema que requeira a re-execução do teste de integração ou de unidade.
O andamento das atividades de execução do teste é registrado detalhadamente no
Diário de Teste. Os eventos que mereçam registro especial e os resultados do teste são
registrados no Relatório de Incidentes de Teste.
O Relatório Resumo de Teste é uma síntese dos resultados das atividades de teste.
Pode ser gerado um único documento contendo os resultados de todos os níveis de teste
aplicados.
A Figura 5 ilustra os artefatos gerados na fase de execução dos testes.
 15

Artefatos Projeto do Projeto do Projeto do Projeto do

de Teste de Teste de Teste de Teste de
Teste Unidade Integração Sistema Aceitação

Ciclos Ciclos Ciclos Ciclos

Execução Teste de Teste de Teste de Teste de

Unidade Integração Sistema Aceitação

Registro
Registro
do
Teste

Artefatos Relatório
de Diário Relatório de Resumo de
Teste de Incidentes de Teste
Teste Teste

Figura 5: Execução do Teste de Software

4.3 Fluxograma de execução do teste de software

A Figura 6 ilustra o fluxo de execução do teste de software de um processo genérico
de teste, onde estão inseridos os níveis de teste.
O teste de uma unidade inicia-se após o término de sua codificação e processa-se
através de ciclos de detecção de falhas e de alterações para corrigi-las.
Para o teste de unidade são aplicadas as seguintes técnicas de teste:
Técnica Estrutural: nesta técnica, os seguintes critérios para a geração dos casos de
teste podem ser adotados: Teste de Comandos, Teste de Ramos, Teste de Caminhos,
Teste de Caminhos Básicos, Teste de Condições, Teste de Condições Múltiplas, Teste
de Laços, Teste de Fluxo de Dados.
Técnica Funcional: nesta técnica, os seguintes critérios para a geração dos casos de
teste podem ser adotados: Particionamento de Equivalência, Análise de Valores
Limites, Teste Baseado em Casos de Uso, Grafo de Causas e Efeito, Teste Baseado em
Tabelas de Decisão, Teste Baseado em Máquinas de Estados.
Dependendo das características da unidade em teste e dos objetivos do teste os
seguintes tipos de teste podem ser aplicados: Teste de Funcionalidade, Teste de Desempenho,
Teste de Confiabilidade, Teste de Usabilidade, etc.
 16

O teste de integração inicia-se com unidades já testadas e também se processa através

de ciclos de detecção de falhas e de alterações para corrigi-las.
Para o teste de integração, no processo de interconexão das unidades são aplicados os
seguintes técnicas de testes:
Técnica Estrutural: nesta técnica, os seguintes critérios para a geração dos casos de
teste podem ser adotados: Teste de Comandos, Teste de Ramos, Teste de Caminhos,
Teste de Caminhos Básicos, Teste de Fluxo de Dados.
Técnica Funcional: nesta técnica, os seguintes critérios para a geração dos casos de
teste podem ser adotados: Particionamento de Equivalência, Análise de Valores
Limites, Teste Baseado em Casos de Uso, Grafo de Causas e Efeito, Teste Baseado em
Tabelas de Decisão, Teste Baseado em Máquinas de Estados.
Dependendo das características das unidades sob integração e dos objetivos do teste os
seguintes tipos de teste podem ser aplicados: Teste de Funcionalidade, Teste de Desempenho,
Teste de Confiabilidade, Teste de Usabilidade, etc.
 17

Codificação da
Unidade

Teste de Unidade

Falha Sim
Alterações

Não Ciclo de Teste de Unidade

Teste de
Integração

Sim
Falha Alterações

Não Ciclo de Teste de Integração

Teste de Sistema

Sim
Falha Alterações

Não Ciclo de Teste de Sistema

Teste de
Aceitação

Sim
Falha Alterações

Não Ciclo de Teste de Aceitação

Encerramento
Legenda
do teste
: retorno a ciclos anteriores

Figura 6: Fluxograma de Execução do Teste de Software

 18

O teste de sistema tem início depois de concluído o teste de integração e também se

processa através de ciclos de detecção de falhas e de alterações.
Para o teste de sistema são aplicadas as seguintes técnicas de teste:
Técnica Funcional: Particionamento de Equivalência, Análise de Valores Limites,
Teste Baseado em Casos de Uso, Grafo de Causas e Efeito, Teste Baseado em Tabelas
de Decisão, Teste Baseado em Máquinas de Estados.
Dependendo das características das unidades sob integração e dos objetivos do teste os
seguintes tipos de teste podem ser aplicados: Teste de Desempenho, Teste de Confiabilidade,
Teste de Usabilidade, Teste de Segurança, Teste de Carga, Teste de Volume, Teste de
Instalação, Teste de Recuperação, etc.
O teste de aceitação tem inicio depois de concluído o teste de sistema e se processa
através de detecção de problemas e de alterações.
Para o teste de aceitação são aplicados todas as técnicas de teste e todos os tipos de
teste aplicados no teste de sistema.
Um processo de teste não precisa necessariamente incluir todos os níveis de teste.

5 PROCESSO DE TESTE DO MÉTODO PRAXIS

O Método Praxis - Processo para Aplicativos Extensíveis Interativos – é um processo

de software com ênfase no desenvolvimento de aplicativos gráficos interativos, baseados na
tecnologia orientada a objetos. O processo de teste PRAXIS é uma simplificação do modelo V
e aborda os seguintes níveis de teste: Teste de Unidade, Teste de Integração e Teste de
Aceitação. A figura 7 ilustra o processo de teste do PRAXIS.
O processo compreende dois grupos de atividades: Preparação e Realização.
Na Preparação são elaborados o plano de teste e as especificações de teste de
aceitação, teste de integração e teste de unidade.
São produzidos os documentos de descrição dos testes, que servem de entrada para as
atividades de realização do teste.
Na Realização os testes são aplicados, os defeitos encontrados são corrigidos e os
relatórios de teste são escritos, produzindo-se os relatórios de teste.
 19

PREPARAÇÃO REALIZAÇÃO

Testes de Descrição Testes de Relatórios

Aceitação dos Testes Aceitação dos Testes
de Aceitação de Aceitação

Testes de Descrição Testes de Relatórios

Integração dos Testes Integração dos Testes
de Integração de Integração

Testes de Descrição Testes de Relatórios

Unidade dos Testes Unidade dos Testes
de Unidade de Unidade

Figura 7: Estrutura em V do Fluxo de Testes

A Preparação e Realização dos testes correspondem a uma passada completa pelo

fluxo de testes. Este fluxo completo é composto pelas atividades de Planejamento dos Testes,
Desenho dos Testes, Implementação dos Testes, Execução dos Testes, Verificação do
Término dos Testes e Balanço Final dos Testes.
A Figura 8 ilustra as atividades de teste do método PRAXIS. As atividades do método
PRAXIS são: Planejamento dos Testes; Desenho dos Testes; Implementação dos Testes;
Execução dos Testes; Verificação do Término dos Testes; e Balanço Final dos Testes.
 20

Plano
Planejamento dos
Testes de
Testes

Itens de Especificações
Desenho
Testes dos Testes dos
Testes

Implementação dos
Testes

Registro Relatórios de
Execução dos
dos Testes Incidentes de
Testes Testes

Verificação do
Término dos Testes

LEGENDA

Atividade

Relatório
Balanço Final
dos Testes Resumo dos
Testes
Artefato

Figura 8: Atividades e Artefatos do Fluxo de Testes

 21

5.1 Planejamento dos testes

O planejamento dos testes envolve muitos aspectos técnicos e gerenciais.
Os produtos dessa atividade são os planos de testes.
O Plano de Testes de Aceitação é único e obrigatório dentro do PRAXIS. Ele será
normalmente preenchido durante o projeto inicial do desenvolvimento do software. Sua base é
a Especificação de Requisitos do Software.
No PRAXIS o produto é desenvolvido de um modo iterativo e incremental, resultando
na liberação sucessiva de várias versões operacionais do produto. Cada Liberação é o
resultado de um processo de integração de funcionalidades implementadas. Os Planos de
Testes de Integração são preenchidos no inicio do desenvolvimento de cada Liberação.
Os testes escolhidos para cada liberação partem de um subconjunto dos testes de
aceitação correspondentes aos casos de uso implementados nessa Liberação.
Cada Plano de Testes de Unidade são preenchidos durante a respectiva
implementação. Os testes de unidade requerem a construção de componentes de testes-drives
e “stubs”.

5.2 Desenho dos testes

Essa atividade tem como produto as especificações dos testes, que incluem a
especificação dos casos de teste e as especificações dos procedimentos de teste.
Cada especificação de teste contém:
Procedimentos de teste, que descrevem a seqüência de ações que devem ser
executadas para realizar um grupo de testes. Cada procedimento de teste corresponde a
um roteiro importante de um caso de uso. Um procedimento pode ser executado de
manualmente ou automaticamente.
Casos de Teste, que especificam os valores de entrada e os resultados esperados para
cada teste. Os valores de entrada devem ser escolhidos de acordo com critérios que
determinam o rigor do teste de software.

5.3 Implementação dos testes

Essa atividade consiste em preparar o ambiente em que os testes serão realizados,
disponibilizando todos os recursos necessários. Os itens a testar são instalados e configurados,
assim como as ferramentas e componentes de teste. Os problemas encontrados são
registrados.
 22

5.4 Execução dos testes

Execução dos Testes consiste na execução do produto em teste com a aplicação dos
casos de teste especificados, conforme os procedimentos definidos. Os produtos dessa
atividade são: o registro da execução de cada caso de teste e o registro dos incidentes de teste.
Podem resultar dos problemas encontrados nesta atividade, solicitações de correção dos itens
sob teste assim como alterações nos planos e nas especificações dos próprios testes.

5.5 Verificação do término dos testes

A Verificação do Término dos Testes determina se as condições de completude e de
sucesso dos testes estão satisfeitas. Testes complementares podem ser projetados caso sejam
necessários para atingir a cobertura desejada do teste. Eventuais problemas encontrados
durante esta atividade devem ser registrados.

5.6 Balanço final dos testes

Consiste em realizar uma avaliação geral dos testes registrando as lições aprendidas
com a elaboração do relatório resumo dos testes.

6 FERRAMENTAS PARA AUXÍLIO NO GERENCIAMENTO DE

CASOS DE TESTE

Uma ferramenta de teste é um tipo de software que auxilia no processo de teste de um

software, contribuindo com a automatização e melhora no desempenho do teste. Ferramentas
de auxílio ao teste de software facilitam a transferência de conhecimento e a compreensão da
organização do projeto de teste, assim como a gerência dos casos de teste. Ferramentas de
gerenciamento e controle de “bugs” facilitam a organização dos “bugs” encontrados nos
testes, cobrindo todo o seu ciclo de vida.
As ferramentas de gerenciamento de casos de teste possuem as seguintes
funcionalidades:
Registro dos casos de teste: um caso de teste é registrado e gerenciado pela ferramenta
dentro de uma determinada estrutura e com um conjunto pré-definido de informações;
 23

Registro dos resultados da execução dos casos de teste: os casos de teste gerenciados
pela ferramenta possuem um conjunto de estados possíveis, que variam de acordo com
a ferramenta. Exemplos: executado, não-executado, falhou, passou;
Relatórios em lista ou gráficos das tarefas realizadas no teste: possibilidade de gerar
relatórios diversificados sobre o estágio atual de um projeto de teste;
Algumas ferramentas para auxílio no gerenciamento de casos de testes estudadas são:
TestLink e TestLog.

6.1 Testlog
Testlog é uma ferramenta para gerenciamento do processo de teste de um software.
O testlog fornece um ambiente de gerenciamento integrado para testes casuais e
projetos de software, fornece relatórios e estatísticas que mostram o progresso do projeto.
A ferramenta funciona em Microsoft Windows e utiliza banco de dados próprio,
criado na definição de um projeto. Sua instalação é a partir de um arquivo executável, e não
existem configurações especiais a serem realizadas. Esta ferramenta não é gratuita, e sua
licença expira em 90 dias. A Figura 9 ilustra a tela principal do testlog.
 24

Figura 9 - Tela Principal do TestLog

O testlog possui um projeto de teste que cria e gerencia os projetos podendo

especificar sua amplitude de início e de término, gera relatórios e projetos específicos de
casos de teste. A Figura 10 ilustra o plano de projeto de teste.

Figura 10: Plano de Projeto de Teste do Testlog

O software organiza as suítes de teste em ordem alfabética, e pode-se visualizar a

estrutura na forma expandida, mostrando os casos de teste na raiz da suíte correspondente a
eles através do teste suítes.
No testlog os casos de testes são armazenados em suítes de teste e podem ter uma ou
mais configurações associadas, com requisitos necessários para a execução de um caso de
teste. Os seguintes campos descrevem um caso de teste: “Test-ID”, “Expected Duration”,
“Title”, “Test Type”, “Test Phase”, “Created”, “Last Update”, “Created By”, “Last Update
By”, “Recommended Config ID’s”, “Resource ID’s Required”, “Config to Add”, “Resource to
Add”, “Prerequisites and Initial Condition”, “Test Description and Steps”, “Expected
Results”, “Notes Field 1”, “Notes Field 2”, “External Description Link”. A Figura 11 ilustra
os suítes de teste.
 25

Figura 11: Suítes de Teste do Testlog

Os casos de testes são executados individualmente, selecionando o caso de teste e o

resultado. A Figura 12 ilustra os casos de teste.

Figura 12: Tela de criação de um caso de teste no TestLog

 26

A política de segurança do testlog permite a criação de usuários sem permissão ou

restrição, registra qual usuário realizou a última modificação, exibe a data e hora das
modificações realizadas.
No testlog existem 4 tipos de relatórios que podem ser obtidos, e um “Report
Wizard”, gera o relatório desejado, de acordo com alguns critérios. Os tipos de relatórios que
a ferramenta apresenta são: “Progress Report”; “Status Report”; “Test Case Report”; “Test
List Report”;

6.2 Testlink
Testlink é uma ferramenta de gerenciamento de testes e um sistema de execução de
testes escrita em apache, mysql, php que permite a criação, gerencia, execução e tracking de
casos de testes e planos de teste.
O testlink funciona em Microsoft Windows ou Linux. Requer PHP e servidor WEB
instalados e configurados. Utiliza banco de dados MySQL. Após instalação e configuração
dos programas necessários (PHP – Servidor WEB – MySQL), basta inicializar o TestLink
através da barra do navegador de internet. Testlink pode ser integrada com as ferramentas de
controle de bugs “Bugzilla” e “Mantis”. A Figura 16 ilustra a tela principal do testlink.

Figura 16 - Tela Principal do TestLink

 27

Alguns conceitos implementados pela ferramenta testlink são:

Especificação de Requisitos: onde os analistas de testes registram os requisitos que
serão testados e alocam os casos de testes relacionados a cada um dos requisitos.
Produto, Componente e Categoria: O Sistema sob teste e seus módulos. Uma forma de
organizar os casos de testes de cada Produto.
Plano de Testes: Onde são adicionados os casos de testes de produtos relacionados a
um plano de testes de um projeto específico.
Casos de Teste: Onde são registradas as informações de cada um dos procedimentos
de testes das funcionalidades do sistema.
“Build”: Uma versão específica de software gerado por um projeto. O “Build” está
relacionado a um plano de testes específico.
O testlink organiza os “Componentes” em ordem alfabética. Para as “Categorias”,
existe a opção de reordenar os nomes de acordo com o desejado. Componentes possuem as
seguintes informações associadas: Nome do Componente, Introdução, Escopo, Referência,
Metodologia e Limitações. Categorias possuem as seguintes informações associadas: Nome
de Categoria, Objetivo, Configuração, Data e “Tools”. Pode-se visualizar os componentes na
forma compacta ou expandida, mostrando as categorias e casos de teste na estrutura do
projeto.
TestLink permite a criação de palavras-chave usadas para facilitar a importação de
casos de testes para um determinado projeto. Os casos de testes são organizados dentro de
uma categoria, que fica dentro de um componente, que está relacionado ao produto a ser
testado. Os seguintes campos descrevem um caso de teste: “Test Case Title”, “Summary”,
“Steps”, “Expected Result”. A Figura 17 ilustra a tela de criação de um caso de teste.
 28

Figura 17: Tela de criação de um caso de teste no TestLink

Para executar os casos de testes, é necessário importar os casos de teste de um plano

de teste, onde os casos de teste serão executados. A Figura 18 ilustra a tela de importação dos
casos de teste.

Figura 18: Tela de importação de casos de testes.

Na política de segurança do testlink existem 5 diferentes tipos de “Papéis” que podem
ser atribuídos aos usuários:
“Guest” - O usuário só tem permissão para ver casos de teste e consultar relatórios do
projeto.
“Otester” - O usuário só pode executar testes definidos a ele.
“Tester” - O usuário pode consultar, criar, editar, apagar e também executar os casos
de teste. Não tem permissão para administrar planos de teste, administrar produtos ou
atribuir direitos.
 29

“Lead” - Mesmas permissões do “Tester”, incluindo permissão para administrar

planos de teste e atribuir direitos.
Admin - Mesmas permissões de “Lead”, incluindo permissão para administrar
Produtos.
No testlink existem 8 tipos de relatórios e um “Report Wizard”, que gera relatórios
através de filtros já criados, ou utilizando outros conceitos de filtro. Os tipos de relatórios que
a ferramenta apresenta são: “View Project Status Across All Builds”; “View Status by an
individual Build”; “View the Overall Build Status”; “View Status By Individual Test Cases”;
“Blocked Test Cases”; “Failed Test Cases”; “Total Bugs For Each Test Cases”; “Email Test
Plan Info”.
 30

7 Conclusão

De acordo com a realização deste trabalho o processo de teste de software deve ser
tratado como mais um processo de software, deve estar integrado junto ao desenvolvimento
do software e também deve iniciar com o projeto para propiciar realimentação.
Todo o processo de teste de software tem que estar bem definido e caracterizado para
que o desenvolvimento do software tenha um bom andamento e no final tenha qualidade.
Um processo de software é conjunto de atividades e resultados associados que geram
um produto de software.
Ferramentas de gerenciamento de casos de teste e de controle de “bugs” são
importantes auxílios na melhoria do processo de teste de software: contribuem grandemente
para a documentação e gerência do processo.
As ferramentas auxiliam o teste, e cada uma delas possui recursos que podem ser
aproveitados em um projeto de teste, diferenciando-as das demais ferramentas.
 31

Referências Bibliográficas

Cenpra – Divisão de Melhoria de Processos de Software – DMPS. Processo de Teste de Software.

Pressman, Roger S.. Engenharia de Software. Makron Books, São Paulo, 2002.

Sommerville, Ian. Engenharia de Software. Pearson / Prentice Hall, 6ª edição, 2003.

http://www.testlog.com/products/testlog.htm

http://sourceforge.net/projects/testlink/
This document was created with Win2PDF available at http://www.win2pdf.com.
The unregistered version of Win2PDF is for evaluation or non-commercial use only.
This page will not be added after purchasing Win2PDF.