escola superior aberta do brasil – esab pós-graduação em ...

ESCOLA SUPERIOR ABERTA DO BRASIL – ESAB
PÓS-GRADUAÇÃO EM ENGENHARIA DE SISTEMAS
PERON REZENDE DE SOUSA
AUTOMAÇÃO DE TESTES EM SOFTWARES E SITES WEB
VILA VELHA – ES
2008

PERON REZENDE DE SOUSA
AUTOMAÇÃO DE TESTES EM SOFTWARES E SITES WEB
Monografia apresentada à ESAB – Escola
Superior Aberta do Brasil, sob orientação
do Dr. Jaime Roy Doxsey e da Me.
Beatriz Christo Gobbi.
VILA VELHA – ES
2008

PERON REZENDE DE SOUSA
AUTOMAÇÃO DE TESTES EM SOFTWARES E SITES WEB
VILA VELHA – ES
2008
Aprovada em ....... de .................. de 2008

Dedico este trabalho à DEUS por me
proteger em todos os meus caminhos;
À minha adorável esposa por sua paciência,
compreensão e amor;
À minha mãe por me orientar e motivar
desde a infância;
E à minha tia por ter possibilitado, há 16
anos atrás, o inicio dos meus estudos na
área da informática.

AGRADECIMENTOS
À minha esposa, pela revisão ortográfica e
gramatical deste trabalho.
Aos meus orientadores, Dr. Jaime Roy
Doxsey e Me. Beatriz Christo Gobbi; aos
colaboradores Bruno Otero, Alvaro Mendes,
Cláudio Carvalho e Mario Calleri, da
REDEA/RJ, e a Helio Leão, da RSI
Informática.

“Somos o que repetidamente fazemos.
A excelência, portanto, não é um feito, mas
um hábito.”
(Aristóteles)

RESUMO
Este trabalho faz uma breve apresentação da disciplina de testes, citando os tipos,
comentando o processo e o vinculo de testes com a qualidade, passando por
questões relacionadas ao ambiente, controle de versionamento e diversas questões
envolvendo o equilíbrio entre custos, prazos e qualidade, chegando a um roteiro
para aquisição de ferramentas destinadas a automação, que evita equívocos
gerados pela grande variedade de contratos de venda. Também apresenta os tipos
e técnicas de automatização e uma grande variedade de ferramentas comerciais,
livres e orientação sobre a construção de uma ferramenta própria. Evidencia a
importância das ferramentas para geração automática de casos, massa e para os
testes de stress. Conclui que, para obter a máxima eficiência no processo é
necessário combinar as técnicas de automação; em alguns casos pode ser
preferível o teste manual; e que os custos do processo automatizado podem estar
concentrados em fatores diversos, como a montagem e manutenção de um
ambiente, e não nas ferramentas.

LISTA DE FIGURAS
Figura 1 – Gestão de ambientes ..........................................................................23
Figura 2 – Ambientes ...........................................................................................23
Figura 3 – Baseline ..............................................................................................26
Figura 4 – Possíveis níveis de maturidade previstos no modelo CMM ...............31
Figura 5 – Exemplo de script ...............................................................................34
Figura 6 – Aplicação da técnica keyword-driven .................................................60
Figura 7 – Estratégia de testes caixa-branca e caixa-preta .................................78
Figura 8 – Visão do modelo de processo de qualidade de software em “U” ........81
Figura 9 – Funcionamento de uma ferramenta de testes ....................................83

LISTA DE GRÁFICOS
Gráfico 1 – Custo hipotético (em horas) para diferentes processos de teste ........36
Gráfico 2 – Teste manual x teste automatizado do módulo de Promoções ..........37
Gráfico 3 – Teste manual x teste automatizado do módulo de Atend. a Clientes ..38
Gráfico 4 – Esforço dedicado à correção de defeitos ............................................41
Gráfico 5 – Esforço gerencial para alcançar níveis maiores de maturidade .........42
Gráfico 6 – Regra de 10 de Myers ........................................................................43
Gráfico 7 – Custo de correção de defeitos ............................................................44
Gráfico 8 – Risco de teste numa aplicação de TI tradicional ................................46
Gráfico 9 – Risco de teste numa aplicação web ...................................................47
Gráfico 10 – Tempo de resposta x nº de usuários (como descobrir gargalos) ........61

LISTA DE TABELAS
Tabela 1 – Métricas coletadas para o módulo de Promoções .............................36
Tabela 2 – Linha ilustrativa de “Ganho” ...............................................................37
Tabela 3 – Métricas coletadas para o módulo de Atendimento a Clientes ...........38
Tabela 4 – Comparativo entre testes manuais e automatizados .........................45
Tabela 5 – Distribuição do esforço em testes .......................................................48
Tabela 6 – Distribuição do esforço em legados (implantação) .............................48
Tabela 7 – Custos das atividades de uma revisão ...............................................50
Tabela 8 – Teste por palavras-chave ...................................................................59
Tabela 9 – Custo/esforço em projetos novos .......................................................84
Tabela 10 – Custo/esforço na manutenção de sistemas ........................................85
Tabela 11 – Custo/esforço na montagem em ambiente de homologação .............86
Tabela 12 – Exemplo de requerimento num quadro comparativo ..........................87
Tabela 13 – Cadastro de clientes ...........................................................................89
Tabela 14 – Transferência ......................................................................................89
Tabela 15 – Verificação de saldo ...........................................................................89

LISTA DE QUADROS
Quadro 1 – Histórico dos testes de software .........................................................16
Quadro 2 – Evolução dos conceitos de qualidade .................................................16
Quadro 3 – Evolução do processo de qualidade e de testes de software .............17
Quadro 4 – Exemplo de priorização das categorias de testes ...............................20
Quadro 5 – Características para um software de qualidade ..................................21
Quadro 6 – Normas de qualidade em desenvolvimento de software .....................30
Quadro 7 – Automação x teste manual .................................................................35
Quadro 8 – Alternativas na execução dos testes ..................................................46
Quadro 9 – Alternativas na conferência dos testes ...............................................51
Quadro 10 – Tipos de automação ...........................................................................53
Quadro 11 – Ferramentas de teste/depuração para programas concorrentes ........71
Quadro 12 – O que automatizar? .............................................................................82
Quadro 13 – Visão Comercial ..................................................................................88
Quadro 14 – Visão Acadêmica ................................................................................88
Quadro 15 – Novas Tendências ..............................................................................88
Quadro 16 – Ferramentas da Borland para a automação de testes de software .....90
Quadro 17 – Ferramentas da IBM para a automação de testes de software ...........90
Quadro 18 – Ferramentas comerciais .....................................................................91
Quadro 19 – Características apresentadas pelas ferramentas de teste OO ...........92
Quadro 20 – Melhores ferramentas Open Source para gestão e automação .........93

LISTA DE SIGLAS
ANSI American National Standards Institute
BSTQB Brazilian Software Testing Qualifications Board
CAST Computer-Aided Software Testing
CLI Command Line Interface
CMM Capability Maturity Model
CMMi Modelo integrado que poderá substituir o CMM no futuro
DLL Dynamic Link Library
DoD Departamento de Defesa Norte-Americano
EPD Evolução do Processo de Desenvolvimento
FSW Fábrica de Software
FTS Fábrica de Testes
GE Grava/Executa
GUI Graphical User Interface
HP Hewlett-Packard
IEEE Institute of Electrical and Electronics Engineers
ISO International Standards Organization
MDS Metodologia de Desenvolvimento de Sistemas
MFC Microsoft Foundation Class Library
MPI Message Passing Interface
OLE Object Linking and Embedding
POO Programação Orientada a Objetos
OSI Open Source Initiative
PF Pontos de função
PQS Processo de Qualidade de Software
PSM Pratical Software Measurement
PVM Parallel Virtual Machine
QA Quality Assurance
QAI Quality Assurance International
RAD Rapid Application Development

REDEA/RJ Representação de desenvolvimento de aplicativos do Rio de Janeiro
ROI Returno of Investiment
SBQS Simpósio Brasileiro de Qualidade de Software
SDLC Software Development Life Cycle
SEI Software Engineering Institute
SLA Service Level Agreement
SPICE Software Process Improvement and Capability dEtermination
SWEBOK Software Engineering Body of Knowledge
TSL Test Script Language
UAT User Acceptance Test
UML Unified Modeling Language
XML eXtensible Markup Language
XP eXtreme Programming

SUMÁRIO
INTRUDUÇÃO .......................................................................................14
CAPÍTULO I – CONCEITOS BÁSICOS DE TESTES .......................15
1.1 HISTÓRICO ..............................................................................15
1.2 ESTRATÉGIAS .........................................................................18
1.3 PROGRESSIVIDADE E REGRESSIVIDADE ...........................18
1.4 CATEGORIAS ..........................................................................19
1.5 TIPOS .......................................................................................21
1.6 AMBIENTES ............................................................................22
1.7 MASSA ....................................................................................24
1.8 VERSIONAMENTO ..................................................................25
CAPÍTULO II – O PROCESSO DE TESTES ......................................28
2.1 PADRÕES DE QUALIDADE ....................................................29
CAPÍTULO III – AUTOMAÇÃO DE TESTES ......................................33
3.1 CUSTOS E PRAZOS ................................................................39
3.1.1 Adquirindo uma ferramenta ..................................................51
3.2 TIPOS DE AUTOMAÇÃO .........................................................53
3.2.1 Capture/Playback (Captura e executa) ................................56
3.2.2 Scripts estruturados ..............................................................58
3.2.3 Data-Driven (Técnica orientada a dados) ............................58
3.2.4 Keyword-Driven (Técnica orientada a palavras-chave) …..59
3.2.5 Teste de estresse ...................................................................61
3.3 FERRAMENTAS ......................................................................62
3.3.1 Suites .......................................................................................62
3.3.2 Software ..................................................................................63
3.3.3 Sites web .................................................................................65

3.3.4 Estrutural .................................................................................66
3.3.5 Mutação ...................................................................................67
3.3.6 Orientados a objetos e de componentes .............................68
3.3.7 Orientados a aspectos ..........................................................70
3.3.8 Concorrentes ............................................................................70
3.3.9 Open Source ...........................................................................71
3.3.10 Faça você mesmo ..................................................................72
CONSIDERAÇÕES FINAIS ..................................................................73
REFERÊNCIAS BIBLIOGRÁFICAS .....................................................74
GLOSSÁRIO...........................................................................................76
ANEXOS ................................................................................................78

INTRODUÇÃO
Palavras-chave: automação, testes, software.
Em 2008, o mercado tem consolidado o “ideal de qualidade” seja por força da
competitividade ou até pela necessidade de redução de custos. Porém, o
desenvolvimento e a manutenção de aplicações corretas, confiáveis e seguras têm
enfrentado a escassez de profissionais qualificados em testes, de publicações na
área e a falta de divulgação das ferramentas de automação.
A maioria das suites de linguagens de programação não traz em seus pacotes
ferramentas para automatizar os testes e o fornecedor, talvez por falha no
treinamento da equipe de vendas, não costuma divulgar a existência delas aos
compradores da suite e não patrocinam a divulgação junto aos autores que
escrevem sobre suas linguagens. O resultado desse quadro é uma grande
quantidade de informações dispersas em vários lugares, obrigando o desenvolvedor
a um verdadeiro “garimpo” para achar as ferramentas que possam atender as suas
necessidades e não ter que “reinventar a roda”. Isso quando o desenvolvedor já
ouviu falar sobre o assunto, pois muitos nem tem conhecimento sobre a existência
das ferramentas para automatizar testes.
Por essas razões escolhemos este tema. Desejamos examinar as técnicas atuais de
automação de testes em software e sites web, além de fazer um levantamento das
aplicações disponíveis no mercado. Queremos conhecer as dificuldades
encontradas no processo e as vantagens da automação de testes quanto a redução
de custos, prazos e aumento de qualidade do produto final. Apresentaremos um
breve resumo sobre a disciplina de testes, sobre todas as implicações financeiras
envolvidas no processo, as principais técnicas e uma rápida referência sobre o que é
oferecido pelo mercado.
Este trabalho foi elaborado com base nas metodologias de pesquisa exploratória e
bibliográfica.
14

CAPÍTULO I – CONCEITOS BÁSICOS DE TESTES
Abordaremos neste capitulo a disciplina de testes e sua evolução, mas sem maiores
detalhes, antes de entrarmos no tema central deste trabalho.
Também apresentaremos algumas “boas práticas” que são válidas tanto para a
execução manual dos testes quanto na automação e veremos o que considerar
durante o processo, para a garantia da qualidade no desenvolvimento de software e
sites web.
1.1 HISTÓRICO
Podemos definir os testes como uma atividade, que tem como objetivo verificar se o
software construído está de acordo com sua especificação e se satisfaz as
expectativas do cliente e/ou utilizador do sistema. Testes é parte integrante do
processo de Validação e Verificação (V & V) da Engenharia de Software (Anexo D),
sendo considerada a técnica dinâmica que exercita a implementação, Sommerville
(apud CORREIA, 2004, p.1).
Para complementar a definição acima, vejamos o que um dos guias de “boas
praticas”, na área de engenharia de software, o SWEBOK (http://www.swebok.org/),
define como teste:
Teste de software consiste na verificação dinâmica do comportamento de
um programa, através de um conjunto finito de casos de teste,
adequadamente selecionado a partir de um conjunto infinito de
possibilidades, contra um comportamento esperado especificado. SWEBOK
(apud ARGOLLO, 2008).
Esse guia traz diversas orientações sobre a organização de todo o processo de
desenvolvimento, inclusive sobre testes e qualidade.
É interessante ressaltar que às vezes os termos teste e qualidade se confundem e
nesse guia podemos identificar facilmente que existe diferença entre qualidade de
software e teste de software.
15

Tanto a qualidade quanto os testes devem estar presente em todo o processo de
construção da aplicação, mas a qualidade se estende por todas as outras
disciplinas, sendo seu escopo mais abrangente em diversos aspectos se comparado
ao de testes.
O estudo da qualidade se aperfeiçoava por meio dos processos industriais (qua.2)
antes mesmo de se imaginar o conceito de software. O estudo dos testes de
software tem pouco mais de 50 anos, mas só começou a ganhar uma maior atenção
do mercado nos últimos 10 anos. Veja o quadro a seguir:
Quadro 1 – Histórico dos testes de software
1957 O teste de software torna-se um processo
1970 Com a engenharia de software aumenta a importância da disciplina de testes
1972 Ocorre a primeira conferência sobre testes na Universidade da Carolina do Norte
1979 Myers produz um dos primeiros trabalhos sobre o processo de testes
Primeiros conceitos de qualidade de software, criação dos padrões:
1980
•
•
IEEE (Institute of Electrical and Electronics Engineers)
ANSI (American National Standards Institute)
• ISO (International Standards Organization)
1990 Começam a ser desenvolvidas as ferramentas de teste
Fonte: Bartié (2002, p.3-4)
O interesse pela qualidade só começou a se intensificar devido ao crescimento
exponencial dos programas em linhas de código e também pelos níveis de
complexidade que estavam sendo alcançados a cada dia.
Quadro 2 – Evolução dos conceitos de qualidade
1900 Inspeção pós-produção Avalia o produto final, depois de pronto
1940 Controle estatístico da produção Avalia os subprodutos das etapas de produção
1950 Procedimento de produção Avalia todo o procedimento de produção
1960 Educação das pessoas Avalia as pessoas envolvidas no processo
1970 Otimização dos processos Avalia e otimiza cada processo
1980 Projeto robusto Avalia o projeto de produção
1990 Engenharia simultânea Avalia a própria concepção do produto
Fonte: Oshiro (2007, p.148-149)
A principio, técnicas foram utilizadas para separar os códigos em módulos menores,
mas em pouco tempo os analistas estavam se vendo envolvidos com centenas,
algumas vezes até milhares, de módulos que dificultavam a “visão do todo” (qua.3).
Com o tempo ficou difícil prever se uma simples alteração na funcionalidade de um
dos módulos, causaria problemas em cascata em outras.
16

Quadro 3 - Evolução do processo de qualidade e de testes de software
Características 1960 1980 2000
Tamanho do software Pequeno Médio Muito grande
Complexidade do software Baixa Média Alta
Tamanho da equipe de desenvolvimento Pequeno Médio Grande
Padrões e metodologias de
desenvolvimento
Interno Moderado Sofisticado
Padrões e metodologias de qualidade e
testes
Interno Moderado Sofisticado
Organizações de qualidade e testes Bem poucas Algumas Muitas
Reconhecimento da importância da
Pequeno Algum Significante
qualidade
Tamanho da equipe de qualidade e testes Pequeno Pequeno Grande
Fonte: Bartié (2002, p.5)
Depois se seguiram às incompatibilidades decorrentes de sistemas operacionais,
versões de DLL, erros no uso do polimorfismo, hardware, etc.
Atualmente muitas empresas ainda não amadureceram a idéia de que é necessário
investir na disciplina de testes, apesar de todas essas questões. Algumas só
investem nos testes manuais, alegando que testes automatizados é um luxo
desnecessário, pois conhecem casos em que a automação não representou ganho
para o processo de desenvolvimento.
Certamente o problema se encontra mais na definição dos processos do que na
automação em si.
[...] as empresas acabam atuando na automação de teste sem a definição
de objetivos e expectativas claros e reais e sem a aplicação de técnicas
apropriadas. Por conseqüência, têm-se constatado um grande número de
insucessos nos esforços para a automação de teste [...] (FANTINATO,
2004, p.2)
Independente da forma como os testes devem ser feitos, insistir em considerá-los
uma atividade que não agrega valor e que é cara, só ira comprometer a
sobrevivência da empresa em um mercado que se apresenta cada vez mais
competitivo.
Quanto ao dilema de automatizar ou não, voltaremos a esse assunto mais a frente.
17

1.2 ESTRATÉGIAS
A estratégia de testes caixa-branca (testes estruturais) verifica o software
internamente, seu código fonte, estrutura de banco de dados, seqüência lógica de
execução de tarefas, etc. Trata-se, portanto de um procedimento complexo que
exige do testador um bom conhecimento sobre as tecnologias usadas no
desenvolvimento do sistema, Bartié (2002, p.104-106).
Na estratégia de caixa-preta (testes funcionais) trabalha somente com os dados de
entradas e os resultados produzidos pelo sistema (Anexo A), sem se preocupar em
como o programa chegou àqueles resultados. Nesse caso o testador não precisa
saber como o sistema foi construído. Essa estratégia é utilizada pelos testes
baseados em requisitos e é responsável pela maioria das ferramentas de automação
disponíveis no mercado.
Antes de se falar em automação podemos concluir que os testes caixa-branca são
realizados pelo desenvolvedor e que os testes caixa-preta podem ser realizados por
qualquer pessoa, pois trata se apenas do uso da aplicação.
Atualmente, a automação que trabalha com o conceito de caixa-preta pode exigir
que o testador tenha conhecimentos em programação.
O testador comum deve continuar existindo, só que fora do ambiente de
desenvolvimento. As maiorias das MDS enxergam esse testador na fase de
homologação, na figura do cliente e/ou do usuário final.
1.3 PROGRESSIVIDADE E REGRESSIVIDADE
Progressividade consiste em avaliar um sistema novo ou apenas a parte nova de um
sistema antigo. Todos os programas novos passam por testes de progressão,
somente quando algo é modificado que podemos realizar um teste de progressão ou
de regressão.
18

O teste de regressão consiste em avaliar todo o sistema após uma modificação de
código e/ou configuração de ambiente, podendo ser uma nova versão ou release,
pois aplicar somente o teste de progressão pode ocultar problemas gerados em
outras partes do sistema em decorrência da ultima alteração.
A automação de testes mostra-se com maior eficiência quando utilizada nos testes
de regressão. Principalmente, quando pouco esforço é necessário na adaptação dos
scripts antigos, para rodar novamente todos os casos de testes antigos e novos.
Com testes manuais o tempo para realizá-los seria muito maior e ainda estaríamos
expostos às falhas de um processo moroso e cansativo, Bartié (2002, p.107-108).
Em resumo, seu principal objetivo é verificar que o sistema continua a realizar as
mesmas funções e da mesma maneira que na versão anterior, Pfleeger (apud
CORREIA, 2004, p.2).
1.4 CATEGORIAS
A separação dos testes em categorias, descrita por Bartié (2002, p.109-110), não se
trata apenas de uma conceituação acadêmica.
Essa separação realmente ajuda na elaboração de casos mais abrangentes.
Evitando com isso que, no momento do levantamento sobre “o que” testar, alguns
itens acabem esquecidos.
A importância de cada categoria (qua.4) varia de um projeto para o outro. Por
exemplo, não temos uma preocupação acentuada no quesito “Carga e
Concorrência” para um projeto de editor de texto, onde somente um usuário usa o
editor por vez. Até podemos nos preocupar com “Volume” relacionando-o ao
trabalho com textos extensos. Apesar das possíveis divergências, a importância
definida por Bartié adequa-se perfeitamente a grande maioria dos sistemas.
19

Quadro 4 – Exemplo de priorização das categorias de testes
Tipo Importância Descrição da categoria
Funcional Essencial
Visa garantir que não haverá diferença entre os requisitos
funcionais e o software desenvolvido.
Checa o desempenho do programa, ou seja, verifica se ele
Performance Médio impacto mantém um tempo de resposta aceitável mesmo em
condições extremas.
Confiabilidade e
Disponibilidade
Alto impacto
Monitora o programa por um tempo para identificar
interrupções (confiabilidade) e mensurar o tempo para
solucionar o problema (disponibilidade).
Simula invasões com o intuito de obter informações
Segurança Essencial sigilosas ao que possam prejudicar o funcionamento do
sistema.
Também conhecido como teste de stress ele funciona
Carga e
Concorrência
Alto impacto
simulando situações atípicas no sistema, como aumento no
tráfego da rede, transações sucessivas e simultâneas, entre
outras.
Verifica a navegação nas telas, clareza das mensagens,
Usabilidade Médio impacto facilidade para obter ajuda, entre outros itens relacionados à
interação com o usuário.
Compatibilidade Essencial
Testa o comportamento em função de alterações no
versionamento de componentes de hardware e software.
Também conhecido como teste de portabilidade, testa o
Configuração Baixo impacto comportamento do programa em ambientes diferentes, tanto
de hardware quanto de software.
Contingência Alto impacto
Analisa os procedimentos que a equipe deve adotar em
caso de falhas.
Analisa o comportamento do sistema, durante o processo de
Instalação Médio impacto
instalação, nas mais diversas possibilidades, por exemplo:
nova instalação, reinstalação, variação de alternativas para
instalação.
É semelhante ao teste de carga, porém esse não trabalha
com oscilações e sim com o crescimento contínuo da base
Volume Alto impacto até o limite suportado e com isso verificar o funcionamento
do programa nessas condições. Alguns autores chamam
esse teste de teste de distribuição.
Recuperação Alto impacto
Avalia a capacidade do sistema em poder voltar a operar
normalmente após a ocorrência de um erro.
Fonte: Bartié (2002, p.120)
Verificando o conteúdo da NBR 13596 (qua.5), que é a versão brasileira da
ISSO/IEC 9126, vimos que esse padrão de qualidade relaciona itens a serem
observados no desenvolvimento de aplicações, para a obtenção de um produto de
qualidade, que são muito semelhantes às categorias descritas por Bartié.
Entre as diferenças vale observar o item “Testabilidade”, da característica
“Manutenibilidade”, pois aumenta nossa visão do produto final para além da
percepção do usuário.
20

Quadro 5 - Características para um software de qualidade
Característica Sub-característica Pergunta chave para a sub-característica
Adequação Propõe-se a fazer o que é apropriado?
Funcionalidade
(satisfaz as
necessidades?)
Acurácia Faz o que foi proposto de forma correta?
Interoperabilidade Interage com os sistemas especificados?
Conformidade Está de acordo com as normas, leis, etc.?
Segurança de acesso Evita acesso não autorizado aos dados?
Maturidade Com que freqüência apresenta falhas?
Tolerância à falhas Ocorrendo falhas, como ele reage?
Confiabilidade
(é imune a falhas?)
Recuperabilidade É capaz de recuperar dados em caso de falha?
Inteligibilidade
Usabilidade
Apreensibilidade
(é fácil de usar?)
Operacionalidade
É fácil entender o conceito e a aplicação?
É fácil aprender a usar?
É fácil de operar e controlar?
Eficiência
Tempo
(é rápido e
Qual é o tempo de resposta, a velocidade de
execução?
"enxuto"?) Recursos Quanto recurso usa? Durante quanto tempo?
Analisabilidade
Manutenibilidade
Modificabilidade
(é fácil de
modificar?)
Estabilidade
Testabilidade
É fácil de encontrar uma falha, quando ocorre?
É fácil modificar e adaptar?
Há grande risco quando se faz alterações?
É fácil testar quando se faz alterações?
Adaptabilidade É fácil adaptar a outros ambientes?
Portabilidade Capac. para ser
(é fácil de usar em instalado
É fácil instalar em outros ambientes?
outro ambiente?) Conformidade Está de acordo com padrões de portabilidade?
Capac. para substituir É fácil usar para substituir outro?
Fonte: NBR 13596 (apud OSHIRO, 2007, p.152-153)
1.5 TIPOS
Existe uma infinidade de tipos de testes, cada um com suas respectivas técnicas.
Alguns se misturam, outros são apenas sinônimos. Cada autor costuma ter sua lista
particular “dos mais importantes”, mas os principais conjuntos de teste são os de
unidade, integração, sistema e validação.
Não é o objetivo desse trabalho discorrer sobre todos os tipos possíveis de testes.
Apenas apresentaremos alguns conceitos, durante a apresentação de alguns temas,
conforme sua relevância para o contexto desse estudo.
Como podemos ver nos Anexos B e C, a muito para considerar quando da
elaboração de um plano de testes.
21

Com a crescente complexidade da disciplina de testes o mercado já começa a exigir
“especialistas” para essa tarefa. Os cursos que se propõe a capacitação profissional
e as certificações começam a se proliferar.
Algumas pesquisas argumentam que esta será uma das áreas com maior demanda
de emprego num futuro próximo e, conseqüentemente, maior valorização salarial. A
Computer World dedicou um post para falar das 6 áreas de TI que são a prova de
recessão, com base em uma pesquisa, da JobFox, realizada em julho deste ano. O
documento faz uma ressalva na área de testes: “Especially good for those with
automated testing expertise”, ou seja, especialmente bom para aqueles com
conhecimento em automação de testes, Eudescosta (2008).
1.6 AMBIENTES
O ambiente de testes pode ser do tipo ativo ou por demanda. Quando construímos
um ambiente e o mantemos, mesmo depois do término do projeto que o originou
(sempre disponível para simular a produção, através de rotinas eventuais, diárias,
quinzenais, mensais, anuais), estamos utilizando o tipo ativo. Esse tipo também é o
melhor para testes de interfaces por parte do homologador 1 , pois não o colocamos
em contato com o ambiente de desenvolvimento (fig.1) e não corremos o risco de
comprometer o ambiente de produção. Outra vantagem é que ele promove a
integração entre plataformas sem que se tenha o trabalho de reinstalar todos os
sistemas envolvidos e reproduzir as massas de testes de cada um a cada novo
projeto ou evolução de aplicação. Esse ambiente também nos possibilita aperfeiçoar
um controle rígido de acessos.
Uma vez preparado, o ambiente ativo proporciona uma redução nos custos a médio
e longo prazo, além de possibilitar uma melhora na performance do processo.
O ambiente por demanda é construído de acordo com os pedidos e conforme a
necessidade. Em termos de hardware, a disponibilidade dos equipamentos pode
1 Cliente e/ou usuário final.
22

tornar esse custo tão alto quanto o do ambiente ativo, mas é comum apenas a
requisição de espaço em disco em máquinas já existente, tanto do ambiente de
desenvolvimento quanto do ambiente de produção, para a realização dos testes. Em
alguns casos não chega nem a ser um ambiente, apenas um “quebra-galho”.
Figura 1 – Gestão de ambientes
Fonte: Bartié (2002, p.165)
Na construção de um ambiente de testes separado do ambiente de produção e de
desenvolvimento devemos ter em mente o seguinte: quando implantamos um
sistema nesse ambiente devemos nos questionar se existe algum tipo de integração
com outros sistemas (seja ela do tipo real-time, on-line e/ou batch) e se eles também
estão implantados nesse mesmo ambiente.
A realização dos testes no ambiente de homologação é conhecida como teste alpha
(fig.2). Quando os testes ocorrem no ambiente de produção recebem o nome de
teste beta.
Ambiente de desenvolvimento
Desenvolvimento
Fontes
Estrutura interna
Teste:
Unidade
Integração
Categoria:
Funcional
Usabilidade
Ambiente de teste e
homologação
Teste:
Ambiente de produção
Sistema Teste:
Teste:
Categoria: Aceitação
Aceitação
Funcional
Carga
Performace
Instalação
Segurança
Categoria:
Aceite formal
Alpha-teste
Categoria:
Beta-teste
Produção
Em
desenvolvimento
Figura 2 – Ambientes
Fonte: Bartié (2002, p.166-167)
Em teste Em homologação
Em
produção
23

Bartié (2002, p.159) também lembra que, outra característica do teste alpha é
realização em ambiente simulado da empresa desenvolvedora da aplicação,
fisicamente separado do ambiente de desenvolvimento.
A equipe encarregada da preparação também deve observar todas as questões
relativas à compatibilidade entre o ambiente de homologação e o de produção, para
evitar o funcionamento incorreto da aplicação devido a problemas de versionamento,
portabilidade, recursos de hardware, etc.
1.7 MASSA
Em algumas livrarias virtuais, quando informamos nossos dados para realizar uma
compra, após digitarmos o CEP, a aplicação web se encarrega de preencher
automaticamente no endereço o nome da rua, bairro, município e UF. As
informações que constam no banco de dados da aplicação antes de qualquer
pessoa te-la utilizado são conhecidas como carga inicial.
Muitas vezes, para testar uma aplicação em todo o seu potencial, é necessário que
o sistema já contenha dados que vão além da carga inicial e que simulem o uso por
parte do usuário, ao longo de algum tempo. Esses dados são chamados de massa
de testes.
Incluir manualmente esses dados, além de ser uma tarefa demorada, é muito
monótono para qualquer pessoa. Já existem diversas ferramentas que se
encarregam de gerar a massa de testes e que utilizam técnicas de redução, para
uso de um registro de cada tipo (file-aid rdx), e descaracterização, para proteger
dados pessoais e evitar que, em caso de algum acidente, esses dados sejam
revelados (data solution).
Em qualquer um dos casos é recomendável que utilizem apenas dados fictícios ou
de domínio público para compor essas massas.
24

Com relação ao uso de ferramentas para automação do processo testes, tenha
preferência pelas que possibilitem o retorno da massa ao “momento zero”, ou seja,
quando terminamos de testar a aplicação pode ser interessante fazer a massa de
testes retornar ao seu estado inicial, para poder reproduzir os mesmos testes com a
garantia de obter os mesmos resultados.
1.8 VERSIONAMENTO
Quando as aplicações começaram a “conversar” entre si, principalmente na
interação entre aplicações via automação OLE, começaram a ocorrer problemas
decorrentes da incompatibilidade de versões, devido às muitas variações de rotinas,
que em tese deveriam atender tanto as chamadas que utilizam as novas
características quanto as antigas.
Esses problemas também se estenderam aos sistemas operacionais, as DLL de uso
geral, sobre recursos da própria aplicação, polimorfismo de POO, hardware, etc.
Já os browsers (navegadores para internet) são um caso a parte, pois sofrem com a
variabilidade dos padrões e das interpretações dadas aos mesmos.
Todos esses fatores obrigam os desenvolvedores a atentar para um rigoroso
controle de configuração em caso de mudanças, seja pela simples instalação em
computadores diferentes ou pelo upgrade da aplicação.
A utilização de um processo automatizado de testes pode garantir uma considerável
economia de recursos, quando é necessário testar o produto em diversos tipos de
configuração. Na atualização também podemos ter uma boa economia, quando
pouca coisa é modificada ao nível da interface, mas convêm avaliar todo o software
novamente (teste de regressão).
Quem já adquiriu um software e checou antes a “configuração mínima” percebe a
importância desses procedimentos.
25

Mesmo quando é utilizado ferramentas para automação dos testes, muito tempo
pode ser perdido quando não se tem o cuidado de guardar a baseline, como
veremos a seguir.
As idéias defendidas pelas categorias “Compatibilidade” e “Configuração” (qua.4)
devem ser adotadas e seus registros acompanhados e controlados. Tanto projetos
novos quanto as mudanças corretivas e/ou evolutivas devem possuir registros da
configuração do ambiente, artefatos, hardware, etc.
Decorrente do controle do versionamento surgiu à expressão baseline. Baseline é
“[...] o resultado do esforço de criação de um ambiente inicial pronto para sofrer o
processamento dos testes planejados.” (BARTIÉ, 2002, p.169).
A IBM desenvolveu uma ferramenta chamada ClearCase, que faz parte da suite do
Rational. Ela trabalha com o seguinte entendimento sobre baseline: imagine quatro
artefatos sendo desenvolvidos paralelamente, que foram evoluindo e recebendo
cada um versões particulares. Neste caso, baseline seria o conjunto de artefatos,
com versões especificas, para que uma aplicação maior pudesse funcionar a
contento. A figura a seguir ilustra melhor essa definição:
Figura 3 – Baseline
26

Para implantar o projeto e documentá-lo devemos considerar o Pacote 1 V.2, Pacote
2 V.1, Pacote 3 V.3 e Pacote 4 V.2, conforme determina a baseline.
O objetivo do baseline é “[...] validar a cópia dos componentes do ambiente de
produção para o ambiente de homologação.” (BRITO, 2000, p.43).
No exemplo anterior citamos artefatos, mas o conceito de baseline também é
utilizado em outros casos, como ambiente e hardware.
O baseline torna-se muito útil quando precisamos restabelecer um sistema para
testes corretivos e/ou evolutivos. Pensando nisso, Ungarelli (2007) definiu baseline
como sendo a configuração tomada em um momento estratégico do projeto com o
objetivo de servir como referência para as atividades posteriores identificadas
conforme o plano de gestão de configuração. Quanto às modificações ele também
lembra que, quando uma ocorrência é resolvida, o teste que deu origem à mesma
deverá ser novamente executado sendo que, para isso, deve ser gerado um novo
baseline com a versão corrigida do documento ou sistema.
O controle do versionamento também ajuda a evitar problemas derivados da falta de
equalização entre ambientes. Essa falta de equalização geralmente ocorre quando
uma solicitação emergencial provoca uma mudança diretamente no ambiente de
produção, e por falta de acompanhamento, não se efetua o acerto nos ambientes de
desenvolvimento e homologação.
27

CAPÍTULO II – O PROCESSO DE TESTES
O processo de testes deve ser iniciado junto com o projeto e deve acompanhá-lo no
decorrer das demais etapas do desenvolvimento, isso garante uma redução nos
custos em virtude da prevenção de problemas já no inicio do desenvolvimento.
Plano, estratégia, cenário, roteiro, casos, massa e evidências de testes são os
principais artefatos elaborados e revistos ao longo do processo de avaliação (Anexo
D). Nesse processo também encontramos as atividades de inspeção e auditoria de
código-fonte, que, inclusive, podem utilizar ferramentas de automatização.
Quanto aos artefatos, a automação tem sido mais utilizada junto aos casos e a
massa de testes. Como já falamos sobre a massa de testes, vejamos os casos.
Segundo Ungarelli (2007) os casos de teste especificam entradas, resultados
esperados e condições de execução estabelecendo o que será testado. Para
Correia (2004, p.2) a qualidade de um caso de teste é descrita através de quatro
atributos:
1. Capacidade de encontrar defeitos;
2. Capacidade em exercitar mais de um aspecto reduzindo assim a quantidade de
casos de teste requeridos;
3. Baixo custo necessário para a realização do caso de teste incluindo o esforço de
desenho, execução e análise dos resultados de teste;
4. Baixo esforço de manutenção necessário sobre o caso de teste a cada alteração
do sistema.
Estes quatro atributos devem ser balanceados de forma a ter casos de testes com
boa qualidade.
Os dois primeiros atributos independem da forma de teste (automática ou manual).
Quanto aos dois últimos veremos mais a frente diversas situações que demonstram
em que casos uma forma é melhor que a outra. O esforço de construção e de
28

manutenção requerido para um teste automático é normalmente maior do que para
um teste manual equivalente, mas uma vez construído, o automático tende a ser
mais econômico que o manual. O esforço de execução e de verificação de
resultados será uma pequena fração do esforço de construção e consideravelmente
menores que a forma manual.
2.1 PADRÕES DE QUALIDADE
Igualmente ao que ocorre na indústria, o segmento de TI vem sendo contemplado
com diversos tipos de certificações para quem se propõe a garantir ao mercado a
qualidade dos processos usados no desenvolvimento de suas aplicações.
Adotar um padrão de qualidade não é uma tarefa simples, mas é possível colher
bons frutos. Veja a seguir alguns comentários sobre os problemas e benefícios
referentes a implantação de uma cultura de qualidade, segundo Bartié (2002, p.50-
64):
Problemas enfrentados:
• Ausência de gerência de qualidade independente
• Ausência de procedimentos de testes automatizados
• Qualidade é sempre aplicada tardiamente no desenvolvimento
• Ausência de profissionais capacitados em qualidade de software
• Falta de um modelo corporativo de qualidade
• Foco em testes progressivos aumenta os riscos
• Deficiência no planejamento dos testes
• Sob pressão, os testes são sacrificados
• Ausência de um ambiente de testes isolado
• Transferir o planejamento ao analista de sistemas
• Dificultar o acesso do analista de testes ao software
Benefícios alcançados:
• Torna o ciclo de desenvolvimento confiável
29

• Garante ações corretivas no ciclo de desenvolvimento
• Evita a ingerência do projeto de software
• Amplia as chances de sucesso do projeto de software
• Amplia a produtividade do desenvolvimento
o Fator desorganização
o Fator retrabalho
• Evitam a propagação de erros
• Automação de testes reduz custos do projeto
Citamos abaixo os principais órgãos certificadores de qualidade no desenvolvimento
de software:
• IEEE (Institute of Eletrical and Electronics Engineers)
• ANSI (American National Stantards Institute)
• ISO (International Stantards Organization)
Na seqüência veja um quadro com algumas das normas definidas por estas
instituições:
Norma
Quadro 6 – Normas de qualidade em desenvolvimento de software
Comentário
ISO 9126 Características da qualidade de produtos de software.
NBR 13596 Versão brasileira da ISO 9126
ISO 14598
Guias para a avaliação de produtos de software, baseados na utilização prática
da norma ISO 9126
ISO 12119
Características de qualidade de pacotes de software (software de prateleira,
vendido com um produto embalado)
IEEE P1061 Standard for Software Quality Metrics Methodology (produto de software)
ISO 12207
Software Life Cycle Process. Norma para a qualidade do processo de
desenvolvimento de software.
NBR ISO 9001
Sistemas de qualidade - Modelo para garantia de qualidade em Projeto,
Desenvolvimento, Instalação e Assistência Técnica (processo)
Gestão de qualidade e garantia de qualidade. Aplicação da norma ISO 9000 para
NBR ISO 9000-3
o processo de desenvolvimento de software.
NBR ISO 10011 Auditoria de Sistemas de Qualidade (processo)
CMM
Capability Maturity Model. Modelo da SEI (Instituto de Engenharia de Software
do Departamento de Defesa dos EEUU) para avaliação da qualidade do
processo de desenvolvimento de software. Não é uma norma ISO, mas é muito
bem aceita no mercado.
SPICE ISO Projeto da ISO/IEC para avaliação de processo de desenvolvimento de software.
15504
Ainda não é uma norma oficial ISO, mas o processo está em andamento.
Fonte: Oshiro (2007, p.151)
30

O CMM (Capability Maturity Model) da Software Engineering Institute esta se
tornando o padrão no mercado, sua classificação em níveis possibilita ao mercado
um visão sobre o que esperar de determinada empresa.
Por exemplo, a SEI (Software Engineering Institute) estima que as empresas que se
encontram no Nível 1 (fig.4) do modelo CMM gastam cerca de 55% (gra.4) dos
esforços em correção de defeitos oriundos do projeto de desenvolvimento.
NÍVEL 5 FOCO NO APERFEIÇOAMENTO
OTIMIZADO
OTIMIZADO DO PROCESSO
NÍVEL 4 PROCESSO MEDIDO E
MENSURÁVEL
GERENCIADO CONTROLADO
NÍVEL 3 PROCESSO CARACTERIZADO E
PADRONIZADO
DEFINIDO BEM ENTENDIDO
NÍVEL 2 TAREFAS "MESTRAS" PODEM SER
CULTURAL
REPETITIVO REPETIDAS CONTINUAMENTE
NÍVEL 1 PROCESSO IMPREVISÍVEL E
ANÁRQUICO
INICIAL POUCO CONTROLADO
Figura 4 – Possíveis níveis de maturidade previstos no modelo CMM
Fonte: Bartié (2002, p.9)
Existem outros dois modelos de qualidade em software que ainda não atingiram uma
maior popularidade: O PSM e o SPICE.
O PSM (Pratical Software Measurement) é um modelo para mensuração de projetos
de software. Criado em 1994 sob o patrocínio do DoD (Departamento de Defesa
Norte-Americano), o PSM foi publicado pela primeira vez 1997. O modelo vem
sendo atualizado por profissionais da área de Software Process Improvement e foi
utilizado como base para a elaboração da Process Area Measurement and Analysis
do CMMi (modelo integrado que poderá substituir o CMM no futuro), Calleri (2005,
p.20).
31

O SPICE (Software Process Improvement and Capability dEtermination) teve
desenvolvimento iniciado em 1993 e sua primeira versão foi liberada em 1995. Ele
não foi proposto como modelo de qualidade ou de implementação, e sim como meio
adequado à avaliação do processo de desenvolvimento de software, Spice Project
(apud CALLERI, 2005, p.30).
Seu projeto visava o desenvolvimento de uma norma internacional para avaliação de
software; coordenação e análise de sua utilização; aprimoramento e sua
consolidação como norma. Como resultado, foi criada a norma internacional ISO/IEC
(International Electrotechnical Commision) 15504, Sepin (apud CALLERI, 2005,
p.30).
32

CAPÍTULO III – AUTOMAÇÃO DE TESTES
A crescente complexidade nos sistemas informáticos juntamente com os
métodos de desenvolvimento rápido e incremental – como por exemplo,
Rapid Application Development e Extreme Programming, que prometem
intervalos de entrega mais freqüentes – requerem testes de qualidade que
possam ser rapidamente executados sempre que necessário. Em tal
cenário os testes manuais são pouco vantajosos, visto que muitos testes
são re-executados a cada release do sistema. (CORREIA, 2004, p.1).
Podemos até falar em qualidade utilizando testes manuais, mas só o uso de
ferramentas de automação pode fazer com que alta produtividade e qualidade
andem juntas.
As funcionalidades mais propícias à automação são aquelas que envolvem a
execução de tarefas repetitivas e cansativas, facilmente suscetíveis a erros, ou
impossíveis de serem realizadas manualmente, Fantinato (2004, p.14).
Segundo Argollo (2008), a automação de testes tem como principais características:
• Diminuição do esforço;
• O foco não é repetir um teste bem sucedido, mas melhorá-lo;
• Repetir quando algo é alterado (software e/ou ambiente).
Não é possível automatizar tudo, mas podemos atingir um bom nível de automação
quando utilizamos as ferramentas basicamente para controlar a execução dos testes
e comparar os resultados obtidos com os resultados esperados, além de relatar os
resultados obtidos.
Como veremos mais adiante algumas ferramentas podem oferecer suporte às
linguagens que manipulam scripts, com o objetivo de apoiar o processo de
automação. Esses scripts servem, principalmente, para simular ações, alterar
valores e verificar o conteúdo dos objetos da interface gráfica. Eles também contam
com recursos similares aos oferecidos pelas linguagens de programação como C,
Java e Delphi. Um desses recursos é a possibilidade de incluir comandos para
33

controle de fluxo (if, while, case) e com isso diminuir o tamanho do código de
controle.
Veja a seguir um exemplo de script e seu resultado na tela:
Figura 5 – Exemplo de script
Fonte: Argollo (2008)
34
Window.Localizar.ProcurarPor.TypeText(“automação”);
Window.Localizar.Diferenciar.Click();
Window.Localizar.Localizar.Click();
MainWindows.Document.ChechSelText(“automação”);
Para Argollo (2008), os scripts também apresentam algumas limitações, como por
exemplo:
• Scripts são dependentes dos elementos da interface gráfica: Se a interface
mudar, o script para de funcionar;
• As linguagens de testes normalmente reconhecem somente os elementos básicos
da interface gráfica.
Algumas ferramentas ainda apresentam um terceiro fator negativo que é a
impossibilidade de reaproveitamento do código em outro caso de teste. Voltaremos
a falar de scripts e como superar essas limitações mais adiante.
Já mencionamos que nem tudo pode ser automatizado, no entanto podem ocorrer
casos em que determinada ferramenta de automação existe, mas não deve ser
utilizada, ou seja, não devemos apenas atentar para “o que pode ser
automatizado?”, mas também para “o que deve ser automatizado?”.
Essa decisão deve envolver os desenvolvedores e os gerentes de projeto. No Anexo
E, segue um roteiro com questões que podem orientar a decisão.
Tanto as questões do Anexo E, quanto os apontamentos a seguir, tratam sobre a
escolha entre os testes manuais e os automatizados, e servem apenas para orientar,

pois ainda que se tenha a consciência de que um determinado procedimento de
teste automatizado deva ser adotado o equilíbrio com os custos e os prazos acabam
se tornando o ponto crucial de toda a questão. O próximo tópico tem como foco
justamente isto e vai apresentar diversos fatores que muitas vezes fazem com que
algumas palavras diferentes pareçam sinônimas, como custo, investimento e
economia.
Quadro 7 – Automação x teste manual
Quando a automação de testes faz sentido? Quando focar em teste manual?
Para valer a pena, devemos observar as Para valer a pena focar em testes manuais,
seguintes questões:
devemos observar as questões seguintes:
• Os testes que usarem técnicas de regressão • Quando se faz uso de testes de instalação,
ou de confirmação. Quando precisa constan- setup, operações muito específicas, como,
temente do trabalho de repetir.
por exemplo, que envolvam hardware (ex.:
• Quando se faz uso de testes aleatórios instalação de componentes de equipamen-
(random ou monkeys testes) que utilizam tos). Isto inclui manutenções em geral.
caminhos aleatórios gravados por dentro da • Faz uso de testes de configuração e de com-
aplicação e de grande quantidade de dados patibilidade. Este tipo de teste geralmente
de testes.
requer muita intervenção humana.
• Testes de carga, volume, capacidade. Como • O mesmo vale para testes de error handing
responder se o sistema funcionará com 50 (tratamento de erros) e de recuperação. No-
mil usuários simultâneos?
vamente este tipo de teste trabalha com er-
• Performance e confiabilidade. Com a “chegaros forçados de maneira que repeti-los pode
da” dos sistemas web, cada vez mais vemos ficar caro.
este tipo de sistema fazer uso de ferramen- • Testes de usabilidade. Mais um caso em que
tas de performance.
é preciso intervenção humana para o devido
• Quando se faz teste de componentes (unida- julgamento e validação dos testes.
de) os quais devem ser retestados várias • O mesmo anterior vale para documentação e
vezes.
Fonte: Molinari (2003, p.105)
help.
No gráfico a seguir (gra.1) podemos ver que os testes manuais tornam-se mais
dispendiosos que os diversos tipos de automação, porém a opção pelo teste manual
pode ser determinada pelo tempo disponível e pela complexidade do teste, Molinari
(2003, p.105).
Aconselhamos aos que irão implantar a automação de testes, que busquem definir
estratégias de coleta e análises métricas relacionadas ao processo de teste de
software, isso ajudará a justificar o investimento aplicado e a otimizar cada etapa,
Fantinato (2004, p.8).
Vejamos um caso prático, o uso do framework AutoTest que foi desenvolvido sobre
a plataforma IBM Rational Functional Tester for Java and Web.
35

O processo foi utilizado em um sistema desenvolvido pela empresa CPqD Telecom
& IT Solutions, por meio da DSB – Diretoria de Soluções em Billing. A equipe de
desenvolvimento era formada por cerca de 160 pessoas, das quais 25 trabalhavam
na atividade de teste.
700
600
500
400
300
200
100
0
Design Phase
Release 1
Release 2
Release 3
Release 4
Release 5
Release 6
Release 7
Release 8
Release 9
Release 10
Gráfico 1 – Custo hipotético (em horas) para diferentes processos de teste
Fonte: Mark Utting (apud ARGOLLO, 2008)
Manual
CaptureReplay
Scripts
ActionWord
ModelBased
Analisaremos apenas os dados colhidos nos módulos “Promoções” e “Atendimento a
Clientes”.
Do total de casos de teste projetados, primeiramente foram executados apenas os
casos de teste mais críticos de forma manual.
Tabela 1 – Métricas coletadas para o módulo de Promoções
Tipo de métrica Teste manual Teste automatizado
Número de casos de teste executados 930 1644
Cobertura funcional dos casos de teste 1 65% 88%
Erros detectados 174 + 33
Tempo de projeto de teste 101 h 101 h
Tempo de uma execução completa dos casos de teste 123 h 14 h
Análise dos resultados e registro de erros 34 h 28 h
Fonte: Fantinato (2004, p.10)
36

7.200,00
6.000,00
4.800,00
3.600,00
2.400,00
1.200,00
-
Evolução
Re-execução 1
Re-execução 2
Re-execução 3
Re-execução 4
Re-execução 5
Re-execução 6
Re-execução 7
Re-execução 8
Re-execução 9
Re-execução 10
Gráfico 2 – Teste manual x teste automatizado do módulo de Promoções
Fonte: Fantinato (2004, p.11)
Manual
Automático
Ganho
Analisando primeiramente os resultados do módulo “Promoções” e comparando as
formas (tab.1), vemos que o aumento na identificação de erros (+33) pode estar
relacionado ao aumento do escopo, mas não há como ignorar o fato de que o teste
automatizado é realizado 15 vezes mais rápido que o manual. Essa diferença se
torna mais evidente quando consideramos a repetição dos testes (gra.2).
Tabela 2 – Linha ilustrativa de “Ganho”
Gráfico 7 Gráfico 6
Serviço Ganho Serviço Ganho
Projeto 0% Evolução -68%
Execução inicial -131% Re-execução 1 2%
Re-execução 1 -61% Re-execução 2 30%
Re-execução 2 -28% Re-execução 3 45%
Re-execução 3 -9% Re-execução 4 55%
Re-execução 4 4% Re-execução 5 62%
Re-execução 5 13% Re-execução 6 66%
Re-execução 6 20% Re-execução 7 70%
Re-execução 7 25% Re-execução 8 73%
Re-execução 8 29% Re-execução 9 75%
Re-execução 9 32% Re-execução 10 77%
Re-execução 10 35%
Fonte: Fantinato (2004, p.11-12)
A linha que representa o “Ganho” (gra.2 e gra.3) é apenas ilustrativa (tab.2), serve
para mostrar o desempenho do teste automatizado em relação ao teste manual.
37

Tabela 3 – Métricas coletadas para o módulo de Atendimento a Clientes
Tipo de métrica Teste manual Teste automatizado
Número de casos de teste executados - 246
Cobertura funcional dos casos de teste - 71%
Erros detectados - 18
Tempo de projeto de teste - 718 h
Tempo de uma execução completa dos casos de teste
525 h
4 h
Análise dos resultados e registro de erros
Fonte: Fantinato (2004, p.12)
(estimado)
100 h
(estimado)
Quanto ao módulo “Atendimento a Clientes”, por se tratar de um módulo em
evolução (tab.3), as planilhas de teste não foram criadas durante a atividade de
projeto de teste, mas apenas adaptadas a partir do projeto anterior para cobrir as
funcionalidades adicionadas ou alteradas.
1.800,00
1.600,00
1.400,00
1.200,00
1.000,00
800,00
600,00
400,00
200,00
-
Projeto
Execução inicial
Re-execução 1
Re-execução 2
Re-execução 3
Re-execução 4
Re-execução 5
Re-execução 6
Re-execução 7
Re-execução 8
Re-execução 9
Re-execução 10
Gráfico 3 – Teste manual x teste automatizado do módulo de Atendimento a Clientes
Fonte: Fantinato (2004, p.12)
62 h
Manual
Automático
Ganho
A diferença de 525 horas para 4, no tempo de execução, é justificada por se tratar
de um módulo com uma grande quantidade de operações, que demandam muitos
acessos ao banco de dados, via SQL, tanto para preparar os testes quanto para
analisar resultados.
38

Não houve teste manual para este módulo, por isso que apenas foram estimados os
valores para efeito de comparação.
Outros autores também realizaram comparações entre os testes manuais e os
automatizados, para Linz e Daigl (apud CORREIA, 2004, p.2), após investimentos
iniciais de criação de infra-estrutura, o gasto em testes automáticos representa 40%
do gasto com testes manuais.
3.1 CUSTOS E PRAZOS
“Não pense em automação como um mecanismo para diminuir o prazo da realização
dos testes, mas como uma forma de aproveitar melhor o tempo para obter um
produto mais confiável.” (ARGOLLO, 2008).
As palavras de Argollo nos lembrar da filosofia Kaizen, que prega a melhora
continua dos processos. Também encontramos esse ideal nas empresas de nível 5
do CMM (fig.4).
Todas as pessoas envolvidas com testes devem ter esse “horizonte” como meta,
pois a simples repetição dos mesmos de forma automática não é suficiente para
extrair um verdadeiro ganho econômico nas atividades de teste, é necessário uma
melhoria contínua, para que possam ser executadas rotinas que não foram
consideradas anteriormente. Por isso é importante adquirir ferramentas que
possibilitem a reutilização de casos de testes, seja por meio de scripts ou por outra
técnica qualquer.
Devemos buscar a reutilização, porque esse é um dos grandes benefícios da
automação. Ela possibilita a execução de um teste de regressão completo em todo o
programa com um mínimo de esforço e o máximo em qualidade. As empresas que
fazem uso dos testes manuais tendem a fazer apenas testes de progressão, devido
ao alto custo dos testes de regressão quando realizados manualmente. Como
39

podemos ver a seguir Bartié (2002, p.45 e 193) reconhece o custo, mas é um dos
que enfatizam a importância dos testes de regressão:
O risco de que as novas alterações tenham comprometido as funcionalidades
anteriores tende a aumentar ainda mais à medida que o software vai se
tornando mais complexo.
...
Os custos relativos à execução dos testes de progressão não são
importantes. São importantes os custos de execução dos testes de
regressão, pois estes devem ser continuamente executados ao longo da
vida do software.
Por outro lado, não investir na qualidade do software pode gerar prejuízos de
diversas ordens. Conforme estudos apresentados por Bartié (2002, p.6):
• Mais de 30% dos projetos são cancelados antes de serem finalizados.
• Mais de 70% dos projetos falham nas entregas das funcionalidades
esperadas.
• Os custos extrapolam em mais de 180% os valores originalmente
previstos.
• Os prazos excedem em mais de 200% os cronogramas originais.
Não podemos generalizar, considerando que todos esses problemas têm sua origem
na deficiência do processo de testes. Requisitos mal elaborados, falhas no
acompanhamento do cronograma ou sub-estimativas de prazos e custos, também
são fatores que causam problemas ao projeto, mas o processo de verificar antes
para depois validar (Anexo D) ajuda a minimizar esses efeitos além de toda uma
cultura de qualidade.
Também não podemos ignorar o fato de que a atividade de teste é cara e repetitiva.
Dependendo do risco e da complexidade da aplicação, a parcela do esforço de
desenvolvimento alocada ao teste varia entre 30% e 50%. O custo do teste na
maioria dos sistemas comerciais varia entre 40% e 50% do custo total de
desenvolvimento, Argollo (2008).
Até o processo de obtenção de uma certificação, em um órgão internacional de
qualidade, costuma ser bem caro.
O CMM (Capability Maturity Model) é um desses padrões de qualidade. Para
defender a tese de que vale a pena investir em um padrão de qualidade a SEI
40

(Software Engineering Institute) realizou uma pesquisa, com base nos dados e em
sua experiência ela estimou alguns valores para as empresas que adotam o CMM.
Inclusive já citamos essa pesquisa, quando mencionamos que as empresas que se
encontram no Nível 1, do modelo CMM, gastam cerca de 55% dos esforços em
correção de defeitos oriundos do projeto de desenvolvimento. Veja agora o gráfico
completo:
Esforço de correção
60%
50%
40%
30%
20%
10%
0%
55%
35%
20%
10%
1 2 3 4 5
Nível de maturidade
Gráfico 4 – Esforço dedicado à correção de defeitos
Fonte: Bartié (2002, p.14)
“Muitos gerentes vêem o processo de automação de testes de software como algo
que pouco agrega valor.” (MOLINARI, 2003, p.102).
Por que será que, mesmo diante do gráfico anterior, os gerentes continuam
tendenciosos a dispensar investimentos em testes? Provavelmente esse fato esta
relacionado ao alto grau de investimentos e esforços necessários no inicio da
implantação de um programa de qualidade. Veja o próximo gráfico com mais alguns
dados levantados pelo SEI:
5%
41

Esforço gerencial
30%
25%
20%
15%
10%
5%
0%
0%
25%
15%
10%
1 2 3 4 5
Nível de maturidade
Gráfico 5 – Esforço gerencial para alcançar níveis maiores de maturidade
Fonte: Bartié (2002, p.15)
Não há gerente que não se pergunte “A empresa está preparada para receber uma
nova cultura? Será que isso vai dar resultado?”.
Podemos considerar que o gerente deve observar os seguintes custos, associados à
implantação de um processo de testes automatizado:
• Aquisição da tecnologia, hardware gasto na instalação das ferramentas;
• Recursos necessários à escolha dos tipos de ferramentas (planejamento,
performance, teste de regressão, funcional, de monitoração, etc);
• Recursos necessários à compra e instalação das ferramentas;
• Treinamento;
• Custos de uso da tecnologia. Licenças / quantidade de usuários das mesmas
ferramentas;
• Recursos necessários à automação (desenvolvimento de scripts);
• Recursos necessários à manutenção dos scripts;
• Suporte do fornecedor.
5%
42

Para piorar o quadro a experiência mostra que o esforço necessário para criar,
verificar e documentar um teste automático é de 3 a 10 vezes maior do que o
necessário para criar e executar o teste manualmente, Argollo (2008).
Seja o teste manual ou automatizado, o custo associado à definição, documentação
e execução de um processo de teste é recuperado ao permitir a detecção e correção
dos defeitos nas fases iniciais do desenvolvimento de um sistema, diminuindo os
ciclos de desenvolvimento.
Seguindo o modelo de PQS em “U” (Anexo D), identificamos as atividades de
verificação no inicio do ciclo. Essas verificações são importantes na redução dos
custos ao longo do processo, tanto que resultaram na regra de 10, formulada por
Myers (gra.6). Segundo Myers um erro não identificado nas fases iniciais do
desenvolvimento ocasiona prejuízos exponenciais à medida que o projeto avança.
10000
1000
100
10
1
Requisitos Análise e
modelagem
Gráfico 6 – Regra de 10 de Myers
Fonte: Bartié (2002, p.31)
Código Teste de
software
Produção
Veja a seguir um gráfico que apresenta levantamento feito por Argollo, sobre os
custos da propagação dos defeitos e quanto foi gasto nas correções em cada fase
do projeto.
43

16.000,00
14.000,00
12.000,00
10.000,00
8.000,00
6.000,00
4.000,00
2.000,00
-
Requisitos Projetos Codificação Teste Manutenção
Gráfico 7 – Custo de correção de defeitos
Fonte: Argollo (2008)
Fases de desenvolvimento
Não chega a ser igual ao idealizado por Myers, mas podemos notar que ele se
aproximou muito da realidade.
Esses gráficos mostram a importância da qualidade e que ela não se aplica apenas
a fase de testes. Ela deve existir em todas as etapas, verificando a conformidade
dos trabalhos realizados.
Quanto à opção por um teste manual ou automatizado, vamos ver a seguir um caso
apresentado por Argollo na SBQS 2008. O relato envolve o desenvolvimento de um
sistema da área de seguros, a gerência teve que decidir entre qual esforço empregar
no processo de testes, veja os dados disponibilizados a gerência:
• Execução dos testes manuais: 5 p/m (5 pessoas x 4 semanas)
• Automação dos testes: 18 p/m (3 pessoas x 6 meses)
Podemos ver que o esforço para os testes automáticos é bem maior que a
realização dos testes manuais, porém devemos perceber que esse esforço só será
44

feito uma única vez e o tempo necessário à execução automatizada dos mesmos é
de apenas uma semana, exigindo um esforço de 1,25 p/m.
Os gerentes também consideraram a possibilidade de repetir a avaliação, nesse
caso o investimento seria recuperado em cinco ciclos e a diferença poderia ser
reinvestida no aprimoramento dos testes.
A escolha foi pela automação e o resultado foi o seguinte:
• O número de incidentes no sistema em produção caiu de 80% a 90%;
• A economia para empresa ao término de um ano foi superior ao orçamento anual
do departamento de teste.
Continuaremos a comparar os testes manuais e os automatizados. Veja a próxima
tabela, ela apresenta os custos de testes referentes à preparação do ambiente, de
execução e de conferência:
Tabela 4 – Comparativo entre testes manuais e automatizados
Etapas dos testes Teste manual
Teste
automatizado
Melhoria
(%)
Planejamento 32 40 -25%
Definição dos casos de testes 262 117 55%
Execução dos testes 466 23 95%
Conferência dos testes 117 58 50%
Gerenciamento do erro 117 23 80%
Relatórios finais 96 16 83%
Duração total (em horas) 1.090 277 75%
Fonte: The Newsletter of the Quality Assurance (apud BARTIÉ, 2002, p.64)
Esta tabela demonstra um estudo que envolveu 1.750 casos de testes e 700 defeitos
existentes. À medida que re-executamos os testes, o ganho de tempo, controle e
confiabilidade fica claro.
A mera repetição não deve ser o único fator para a opção pelos testes
automatizados e a adoção destes sem aplicá-los em testes de regressão total
também é algo que deixa a desejar.
45

Podemos ver no quadro a seguir que a regressão parcial usando testes
automatizados não reduz o risco de não cobertura, apenas reduz o custo e em
alguns casos nem isso.
Quadro 8 – Alternativas na execução dos testes
Regressão Total Regressão Parcial
• Baixo risco de não-cobertura • Alto risco de não cobertura
• Alto custo de execução
• Custo de execução menor
Teste Manual • Execução lenta
• Execução lenta
• Reutilização zero
• Reutilização zero
• Interferências humanas
• Interferências humanas
• Baixo risco de não-cobertura • Alto risco de não cobertura
Teste
Automatizado
• Baixo custo de execução
• Execução rápida
• Reutilização total
• Menor custo de execução possível
• Execução mais rápida possível
• Reutilização total
• Sem interferências humanas • Sem interferências humanas
Fonte: Bartié (2002, p.196)
A equipe responsável pelos testes deve ter a preocupação de reduzir os riscos ao
máximo e em cada uma das categorias (qua.4).
25
20
15
10
5
0
Funcionalidade
Performance
Segurança
Usabilidade
Gráfico 8 – Risco de teste numa aplicação de TI tradicional
Fonte: Molinari (2003, p.180)
Disponibilidade
Operabilidade
Como já mencionamos anteriormente, o nível de importância de cada categoria pode
mudar em função do projeto e dos riscos envolvidos.
46

Essas diferenças podem estar no formato da aplicação em si, ou seja, se é um
projeto de software ou site web.
Mesmo na escolha do titulo deste trabalho tivemos a preocupação de enfatizar essa
diferença.
Molinari (2003, p.180) realça essa diferença ao apresentar uma maior distribuição
dos riscos nos projetos web (gra.8 e gra.9).
Quando comparamos uma aplicação web com uma aplicação que funciona sobre
uma estrutura cliente/servidor as diferenças na distribuição dos riscos diminuem.
14
12
10
8
6
4
2
0
Funcionalidade
Performance da Residência
Segurança
Itens de Performace do Site
Integração
Gráfico 9 – Risco de teste numa aplicação web
Fonte: Molinari (2003, p.181)
Infra-estrutura
Usabilidade
Localização
Disponibilidade Pós-entrega
Uma “boa pratica” em testes é separar a equipe que testa da equipe que
desenvolve. Pensando nisso muitas empresas contratam uma FSW (fábrica de
software) para desenvolver e uma FTS (fábrica de testes) para testar. Isso não
significa que a FSW não vai fazer testes, ela inclusive se preocupa bem mais com os
erros em uma situação assim, pois, caso a FTS ache erros, a FSW, além de ter o
custo de consertá-los, arca com o custo de reenvio a FTS para o re-teste.
47

A FSW é responsável, principalmente, pelos testes de unidade, integrado e de
sistemas. Esses testes não são feitos pela FTS, mas podem passar pela inspeção
desta. Segue abaixo um quadro com um exemplo de distribuição de esforço para as
atividades da FTS:
Tabela 5 – Distribuição do esforço em testes
PROJETO MANUTENÇÕES
Atividade
Percentual de Percentual de
Esforço
Esforço
Auditoria de Código-Fonte --- ---
Inspeção de artefatos de teste 5% 5%
Planejamento de Teste 32% 15%
Execução e Evidenciação de Teste sobre uma
entrega parcial de software
Execução e evidenciação de teste de Aceite de um
28% 30%
Serviço de Desenvolvimento e/ou Manutenção de
Software
22% 35%
Publicação de Ocorrências de Teste 3% 5%
Automatização de teste
Fonte: Carvalho (2008, s.16)
10% 10%
Quando a empresa contratante resolve adotar um ambiente ativo para homologação,
a FTS pode ser contratada para a tarefa de montar nesse ambiente os mesmos
sistemas que se encontram em produção. A distribuição de esforço para essa tarefa
pode ser visto a seguir:
Tabela 6 – Distribuição do esforço em legados (implantação)
Atividade Percentual de Esforço
Planejamento de Teste 20%
Acompanhamento da montagem do sistema no
ambiente de homologação
30%
Execução e evidenciação de teste sobre sistema
40%
legado
Automatização de teste 10%
Fonte: Carvalho (2008, s.17)
Consideremos o seguinte exemplo: A FSW vai desenvolver um projeto 700 PF
(pontos de função). Considerando que a FTS cobra R$ 50,00 2 para uma
produtividade de 3 pf/h (pontos de função por hora) em caso de projetos novos,
teremos um custo total, com um processo automatizado de testes, de R$ 93.340,00,
veja o Anexo G. No Anexo H e I, apresentamos exemplos de cálculos sobre serviços
2 Os valores são fictícios, mas muito próximos do que é cobrado no mercado atualmente (Set/08).
48

de manutenção e preparação de ambiente, respectivamente. Os valores calculados
em horas podem ser utilizados facilmente na montagem de cronogramas em
programas como o MS Project da Microsoft.
Vimos até aqui diversas razões para optar pelo processo de testes automatizado,
mas quando nos deparamos com um custo de quase cem mil reais é natural ter
certo receio. Afinal sabemos agora quanto custa, mas não sabemos quanto dinheiro
economizamos ao adotar essa prática.
Molinari (2003, p.40) propôs a seguinte fórmula para medir o custo de um defeito
encontrado:
Custo médio do defeito =
(nº de pessoas envolvidas * nº de dias gastos) * custo por pessoa-dia
(nº de defeitos resolvidos)
Esta fórmula pode ajudar a complementar as avaliações de custos futuros com base
em dados históricos e estimar uma produtividade em pontos de função, mas não
chega a dizer quanto economizamos com o uso dos testes. Isso não significa que
este tipo de informação não deva ser registrada, podemos inclusive usar
ferramentas bug tracking para esse trabalho, conforme aconselha Ungarelli (2007):
É desejável, para o acompanhamento e controle dos bugs registrados, a
utilização de uma ferramenta de bug tracking assim, características
importantes de um registro poderão ser facilmente resgatadas. Seguem
algumas características importantes: gravidade do bug, prioridade do bug,
status, versão do software ou artefato, a fase que bug ocorreu, histórico,
relator e responsável pela resolução, etc.
Da mesma forma que acreditamos que não é possível automatizar tudo também
acreditamos que não é preciso medir tudo, para não tornar essa tarefa burocrática e
cara demais.
Todo o esforço para encontrar, mensurar, quantificar e analisar falhas em uma
aplicação só vai fazer sentido se o erro for corrigido, Molinari (2003, p.52) lembra
bem o caso do processador Pentium da Intel que apresentou um Bug em 1994. A
Intel havia descoberto o problema através de seus engenheiros de teste, antes do
chip ser lançado, porém, por decisão gerencial, houve o lançamento do produto, pois
49

havia o entendimento que o problema não era severo. Por exemplo, ao tentar fazer o
cálculo:
(4.195.835 / 3.145.727) * 3.145.727 / 4.195.835
Se a resposta fosse zero 3 , o computador funcionava; caso contrário, aparecia um
“bug” no chip que travava a máquina.
No dia 30 de outubro de 1994, Dr. Thomas R. Nicely do Lynchburg College (Virginia
- EUA) rastreou um resultado inesperado devido a problemas de divisão. O
problema foi jogado na internet, mas a Intel não considerava um “bug” de fato e ela
tentou vender isso a imprensa, mas acabou amargando um prejuízo de mais de US$
400 milhões com reposição de chips.
Queremos ilustrar com essa história que os testes feitos pelos engenheiros da Intel,
certamente, custaram bem menos que os milhões gastos na substituição dos
processadores.
O custo dos testes pode ter sido mais baixo do que se imagina, caso a falha tenha
sido identificada no inicio do processo, conforme principio de Myers (gra.6), pois não
ficou claro em que momento o erro foi encontrado nos laboratórios da Intel.
Brito (2000, p.47), chama a atenção para o simples ato de fazer uma conferência do
que foi realizado em determinada etapa. Ela cita um caso em que uma revisão de
requisitos foi efetuada com a participação do seguinte quadro de funcionários:
Tabela 7 – Custos das atividades de uma revisão
Profissional Quantidade Custo/Hora Tempo Estimado Total
Analista Pleno 3 28,11 04:30 379,49
Programador 1 21,48 04:30 96,66
Líder de Projeto 1 36,28 06:00 217,68
Total 693,83
Fonte: Brito (2000, p.47)
3 O cálculo dessa equação retorna 1 nos processadores atuais
50

Essa tabela tem o objetivo de fornecer rapidamente a informação sobre os custos
despendidos com uma revisão. Ainda que fossem realizadas 5 revisões, um número
exagerado, para uma única especificação de requisitos, o custo de R$ 3.469,05 é
aceitável se comparado ao valor do projeto que estava em questão (R$ 827.608,20),
pois as revisões evitam que, no momento da homologação, sejam descobertos erros
de requisitos funcionais que inviabilizam sua implantação. Causando assim um
prejuízo maior na forma de retrabalho, caso o cliente ainda deseje o produto e
concorde em aguardar sua correção.
Brito não cita como essa verificação foi feita, pois ainda podemos encontrar
diferenciais entre a forma manual e automática nessa questão. Veja o quadro a
seguir:
Quadro 9 – Alternativas na conferência dos testes
Conferências Manuais Conferências Automatizadas
• Planejamento mais simples
• Planejamento mais complexo
• Maior custo de re-execução
• Menor custo de re-execução
• Execução mais lenta
• Execução mais rápida
• Reutilização zero
• Reutilização total
• Com interpretações humanas
Fonte: Bartié (2002, p.198)
• Sem interpretações humanas
Nas fases iniciais pode ser preferível adotar conferências manuais, como a revisão
de requisitos. Principalmente quando não temos a intenção de fazer uma nova
verificação.
3.1.1 Adquirindo uma ferramenta
Existem opções para empresa de qualquer porte, desde caríssimos “elefantes
brancos” até as chamadas Open Source. Quando a dúvida aparece Molinari (p.109-
114) sugere fazer o seguinte:
• Definir requerimentos iniciais (Quais problemas a ferramenta deve resolver? Que
recursos a ferramenta precisa ter para ser efetiva no seu ambiente? Quais são
suas regras de utilização, custo, etc?)
51

o Itens de compatibilidade (sistema operacional, linguagem de programação,
outros softwares)
o Audiência com a ferramenta (Solicitar uma apresentação da ferramenta; Quem
usará a ferramenta no dia-a-dia? Quanto é necessário em tempo e energia
para treinamento? Como se espera que a automação de testes seja paga?)
o Regra financeira (Determinar o budget (orçamento) antes de ir as compras;
Inclui quantas licenças, treinamento, manutenção e implementação?;
Necessidade de aquisição de máquinas exclusivas para testes; Quais os
benefícios esperados, são quantificáveis e mensuráveis? Qual o ROI (returno
of investiment))
o Requerimento de negócio (veja Anexo J)
• Investigar as opiniões (Internet, NewsGroups, literatura disponível, veja o que
outras pessoas adotaram, em que a ferramenta é melhor ou pior que a
concorrência?)
• Refinar os seus requerimentos (discuta com quem vai usar)
• Refinar a lista (selecione as três melhores com base na lista de requerimentos)
• Avaliar os finalistas (ver os softwares de demonstrações ou hands-on)
• Implantação da ferramenta escolhida (treinamento, piloto, inicie medições,
acompanhe o processo, comunicação clara)
As ferramentas Open Source tem como positivo o preço, mas as soluções
comerciais 4 se defendem argumentando que as ferramentas gratuitas não oferecem
integração.
Entre as ferramentas Open Source o OpenSta da Cyrano tem oferecido alguma
integração, mas ainda é limitado. Apesar dessas limitações o Watir (Web Application
Testing in Ruby) e o Selenium tëm ganhado força no mercado.
Entre os grandes fornecedores de soluções comerciais temos a integração como
ponto positivo e negativo o preço e adequação.
Outras ferramentas serão mencionadas mais adiante.
4 Vamos chamar de solução comercial as ferramentas que não são gratuitas.
52

3.2 TIPOS DE AUTOMAÇÃO
Da mesma forma que não há um consenso entre os autores sobre os tipos de
testes, suas classificações e inter-relações, o mesmo ocorre com os tipos de
automação, mas concordamos em dizer que “As principais técnicas de automação
de teste apresentadas na literatura são: record & playback, programação de scripts,
data-driven e keyword-driven.” (FANTINATO, 2004, p.2).
Vamos apresentar também a visão de outros autores.
Caetano (2007) agrupou os tipos de automação em dois paradigmas, os testes
baseados na interface gráfica e os baseados na lógica de negócio. Veja o quadro a
seguir que apresenta as vantagens e desvantagens de cada um:
Paradigma Vantagens
Quadro 10 – Tipos de automação
Desvantagens
Baseado na Não requer modificações na aplicação Existe uma forte dependência da
Interface Gráfica para criar os testes automatizados. estabilidade da interface gráfica. Se a
Também não é necessário tornar a interface gráfica mudar, os testes
aplicação mais fácil de testar
falham. Baixo desempenho para testes
(testabilidade) porque os testes se automatizados que exigem centenas de
baseiam na mesma interface utilizada milhares de repetições, testes de
pelos usuários.
funcionalidades que realizam cálculos
complexos, integração entre sistemas
diferentes e assim por diante.
Baseado na Foco na camada onde existe maior Requer grandes modificações na
Lógica de probabilidade de existir erros.
aplicação para expor as
Negócio Independência das mudanças da funcionalidades ao mundo exterior.
interface gráfica. Alto desempenho para Exige profissionais especializados em
testes automatizados que exigem programação para criar os testes
centenas de milhares de repetições, automatizados. Existem poucas
testes de funcionalidades que realizam ferramentas/frameworks que suportam
cálculos complexos, integração entre essa abordagem (normalmente é
sistemas diferentes e assim por diante.
Fonte: Caetano (2007)
necessário criar soluções caseiras).
Molinari (2003, p.107-108) reconhece que não há uma unanimidade no mercado em
relação aos tipos de ferramentas de teste existentes e que não existe uma
classificação “mínima”, mas ele defende a existência de duas correntes. Uma
comercial, que foca as funcionalidades, e outra acadêmica, que foca a forma básica
de concepção (Anexo K).
53

Segundo Bartié (2002, p.181) a automação, que é desenvolvida em paralelo ao
desenvolvimento da aplicação principal, pode ser classificada em dois tipos de
componentes de testes fundamentais: controladores e simuladores.
Os controladores de testes (Test-drivers) servem para testar uma unidade de
software, disparando chamadas com os mais variados cenários existentes. Já os
simuladores (Stubs) testam tanto software quanto hardware, criando artificialmente
“respostas simuladas” que imitam conversas entre aplicativos, como, por exemplo, o
teste de uma máquina que faz cálculos com base na velocidade do vento, ao invés
de produzir o vento é melhor alimentar a máquina com as mais variadas velocidades
do ar para concluir os testes mais rapidamente e de forma mais completa, pois
poderemos simular todas as possibilidades.
Bartié (2002, p.185-192) separa componentes de ferramentas de testes (que ele
também chama de CAST, Computer-Aided Software Testing), para ele as
ferramentas de testes podem ser classificadas em cinco categorias, com suas
respectivas características:
• Planejamento de testes
o Análise de criticidade – prioriza testes, estima tempo, custo e equipes;
o Gerador de documentos – gestão de versão, organiza work-flow de prepara-
ção, elaboração, inspeção e aceite de documentos.
• Revisões e inspeções
o Análise de complexidade – auxiliam na identificação de áreas complexas, a
experiência diz que em 20% está 80% dos problemas;
o Compreensão de código – auxilia a inspeção de código-fonte;
o Análise sintática e de semântica – localiza erros de sintaxe que o compilador
não detecta.
• Modelagem e automação
o Modelagem de testes – planeja e constrói os testes identificando os cenários
de teste;
o Gerador de massa de dados;
o Automatizador de scripts.
• Execução e conferência
54

o Executor de scripts;
o Análise de cobertura – usado nos testes caixa branca para identificar áreas do
código não cobertas pelos testes em execução;
o Testadores de memória – detecta problemas de uso e alocação de memória;
o Simuladores e medidores de performance – destinam-se aos testes de carga,
volume e performance.
• Suporte aos testes
o Gerenciamento de defeitos – produz indicadores diversos de qualidade;
o Gerenciamento de configurações – controla mudanças em documentação, fon-
tes e ambientes físicos.
Carvalho e Filho (2005) fazem distinção entre ferramentas usadas em plataforma
alta (mainframe) e plataforma baixa (Windows e Sun). Ambas são semelhantes na
automação que executa as mesmas ações de um usuário on-line e na necessidade
de programação. Quanto às diferenças, podemos citar que o teste automatizado na
plataforma alta pode ser executado em batch, ou seja, não há necessidade de uma
estação dedicada ao teste e os objetos a serem automatizados na plataforma alta
obedecem a padrões rígidos, característicos dessa plataforma, enquanto que os da
plataforma baixa estão em constante processo de evolução.
Caetano (2007) também faz referência à filosofia apresentada pelo "Guide to the
CSTE Common Body of Knowledge" do QAI que diz: apesar de não existir uma
categorização amplamente difundida das ferramentas de teste, a experiência tem
mostrado que elas são normalmente agrupadas em 8 áreas distintas:
1. Ferramentas de automação de testes de regressão;
2. Ferramentas para gestão de defeitos;
3. Ferramentas para testes de performance/stress;
4. Ferramentas manuais;
5. Ferramentas de rastreabilidade;
6. Ferramentas de cobertura de código;
7. Ferramentas para gestão de testes;
8. Ferramentas de apoio à execução dos testes.
55

Argollo (2008) defende ainda os testes baseados em modelos. Neste tipo os casos
são derivados de um modelo que descreve as propriedades e características do
sistema em teste. Este modelo fornece uma descrição do comportamento do sistema
em avaliação.
Conforme estimativa da Mark Utting, apresentada por Argollo, os testes baseados
em modelos podem ser mais eficientes que as outras técnicas (gra.1) e no futuro ela
pode se tornar uma das principais técnicas utilizadas pelo mercado.
Caetano (2007) cita ainda os testes do tipo Interface de Linha de Comando
(Command Line Interface - CLI) onde a interação ocorre através de um prompt ou
shell do sistema operacional.
A lógica de negócio da aplicação pode ser exercitada por meio da execução de um
conjunto de comandos e parâmetros pré-determinados. Talvez você esteja
pensando nos arquivos BAT do DOS, mas não é esse o caso. O objetivo da CLI é
fornecer uma interface para o mundo exterior que não seja dependente da interface
gráfica da aplicação, controlar a execução dos testes e apresentar os resultados.
3.2.1 Capture/Playback (Captura e executa)
Quem já utilizou “macros” no Word ou Excel, tem uma boa idéia de como a técnica
de Capture/Playback funciona.
Ao acionar o recurso de gravação/captura (Record/Playback ou Capture/Playback)
a ferramenta passa a fazer o registro de todos os passos do usuário, nesse
momento devemos executar os casos de testes e interromper o processo de
gravação quando desejarmos incluir verificações.
Internamente a ferramenta terá criado um script com essas ações.
56

Da mesma forma que ocorre com as macros no Word e no Excel, podemos repetir
todas as ações gravadas bastando executar o script criado.
Podemos ver que a geração dos scripts é feita de forma rápida e fácil. Possibilitando
que o automatizador não detenha conhecimento de programação e não onere a
primeira execução dos testes trabalhando horas em scripts complexos (gra.3).
Porém com o decorrer do tempo essa técnica não se mostra tão eficiente (gra.1).
Quando optamos por um testador que não vai manipular os scripts ou até pelo fato
da ferramenta não permitir essa manipulação, estamos condicionando a criação de
novos scripts toda vez que precisarmos de novos testes ou quando algo for mudado
na interface.
Devido à falta de comandos de controle de fluxo e pela impossibilidade do uso de
tabelas, um testador, que conhece programação, pode se deparar com uma
quantidade muito grande de scripts para manipular.
Segundo Correia (2004, p.6), a maioria das ferramentas que utilizam essa técnica
interage com o standard Microsoft Foundation Class Library (MFC), ou seja, caso o
sistema a ser testado esteja usando uma tecnologia diferente como, por exemplo, a
Java Foundation Class Library, a ferramenta pode não funcionar. Por isso que
algumas ferramentas também trabalham com o reconhecimento dos objetos através
das coordenadas espaciais do ecrã.
Correia também lembra que é possível usar essas ferramentas para testar stored
procedures PL-SQL, a WebServices, aplicações servidoras ou um componente
através de uma DLL, a solução passa pela criação de uma camada de interface
gráfica standard simples, que possibilita a invocação dos serviços a serem testados.
Através deste recurso, podemos dizer que essa técnica permite a execução e
comparação automática de testes em todos os níveis: unidade, módulo, integração,
sistema ou aceitação.
57

3.2.2 Scripts estruturados
A técnica dos scripts estruturados permite a redução do código e sua reutilização,
como também a possibilidade de organizar seu funcionamento em um framework
que forneça funções básicas de automação.
Necessita-se de um maior esforço do automatizador no início para a criação dos
scripts, a compensação vem com a manutenção que é simples em caso de mudança
na interface ou na adição de novos casos.
O automatizador deve ter conhecimento de programação.
Algumas ferramentas não possibilitam o uso de tabelas, ou seja, o conteúdo da ação
do usuário deve estar no script (hard-coded).
3.2.3 Data-Driven (Técnica orientada a dados)
Nesta técnica os casos de teste são armazenados em tabelas (Anexo L). A
ferramenta usa scripts para ler os dados dessas tabelas e processar os casos de
teste de acordo com o cenário definido (Anexo F).
A grande vantagem desta técnica está em usar o mesmo script, sem alteração, para
executar novos casos de teste semelhantes.
Dependendo de como o script é escrito, as alterações na interface não causam
grandes problemas, pois as ferramentas costumam usar “mapas de interface”.
Segundo Fantinato (2004, p.7) esse mapa é um arquivo que contém nomes fictícios
dos componentes da interface gráfica (GUI) da aplicação e as propriedades que os
identificam unicamente. Este mapa é utilizado para que todo componente da GUI
seja referenciado nos scripts e nas planilhas de teste por um nome que independa
de mudanças da aplicação, com o objetivo de que as alterações introduzidas na
58

interface gráfica da aplicação impliquem, apenas, em atualizações no mapa de
interface, preservando e tornando o teste mais robusto.
O esforço necessário para desenvolvimento dos scripts aumenta devido a maior
complexidade dos mesmos.
3.2.4 Keyword-Driven (Técnica orientada a palavras-chave)
Essa técnica usa tabelas para armazenar os casos de teste e os scripts para ler as
informações da tabela e processar os casos de teste. Cada tabela também contém
dados de diversos cenários de teste. O diferencial está no uso de palavras-chave
para referenciar scripts específicos (tab.8), isso possibilita uma maior flexibilidade
para a definição de novos cenários de teste. Os testes também são definidos em
termos de processos de negócios.
Exige-se do testador um pouco mais de conhecimento em desenvolvimento de
software do que a técnica anterior, data-driven, pois os scripts desenvolvidos são
mais complexos.
Tabela 8 - Teste por palavras-chave
Cadastro Silva José 30.123-A 12.700,00
Cadastro Moraes Carlos 40.456-B 8.200,00
Transferência 30.123-A 40.456-B 500,00
VerificaSaldo 30.123-A 12.200,00
VerificaSaldo 40.456-B 8.700,00
Fonte: Argollo (2008)
Na tabela keyword-driven anterior, à primeira coluna possui as palavras que fazem
referência aos procedimentos (scripts, também conhecidos como scripts de suporte)
previamente construídos para executar determinada rotina de teste. As colunas
seguintes possuem os “parâmetros” que serão usados pela rotina (script). Por
exemplo, “Transferência” é uma rotina encarregada de passar dinheiro de uma conta
para outra e, para realizar essa tarefa, ela recebe como parâmetro a conta de
origem (30.123-A), a conta de destino (40.456-B) e o valor a ser transferido (500,00).
59

Figura 6 - Aplicação da técnica keyword-driven
Fonte: Adaptada de Fewster e Grahm (apud Correia, 2004, p.6)
Na técnica keyword-driven temos portanto três estruturas básicas que são: o script
de controle, os ficheiros de teste e os scripts de suporte (fig.6).
Dentre as técnicas para a construção de testes automáticos as mais evoluídas são
as data-driven e keyword-driven, que permitem reutilização (inclusive em sistemas
diferentes) e flexíbilidade.
Como mencionamos no tópico scripts estruturados é possível, a partir dos scripts,
elaborar frameworks. Fantinato apresentou em seu trabalho o AutoTest, que usa
uma técnica mista de automação de teste, chamada de técnica keyword-data-driven,
definida a partir de duas outras técnicas de automação conhecidas, dessa forma ele
aproveita o que há de melhor em cada uma delas.
Neste framework também foi necessário usar o IBM Rational Test Manager, que é
uma ferramenta de gerenciamento de projeto de teste que possibilita a integração
com as demais ferramentas da suite de desenvolvimento da IBM Rational. Seu uso
60

possibilitou um melhor gerenciamento dos resultados e a obtenção de relatórios
mais específicos e detalhados.
3.2.5 Teste de estresse
O framework AutoTest foi desenvolvido sobre a plataforma IBM Rational
Functional Tester for Java and Web, uma ferramenta de automação de teste
que oferece suporte somente à programação e a execução de scripts de
teste. Apesar de dar suporte nativo à técnica “record & playback” de
automação de testes, o Functional Tester usa Java como linguagem dos
scripts de teste, permitindo a aplicação de técnicas mais avançadas de
programação de scripts – como a técnica keyword-data-driven.
(FANTINATO, 2004, p.6).
Podemos dizer que atualmente é impensável realizar um teste de stress de forma
manual.
Mas como funciona? Como é possível “imitar” o comportamento de centenas ou até
milhares de usuários?
Tempo de resposta (segundos)
16
14
12
10
8
6
4
2
0
Gargalo
1 2 3 4 5 6 7 8 9 10
Número de usuários
Gráfico 10 – Tempo de resposta x nº de usuários (como descobrir gargalos)
Fonte: Molinari (2003, p.188)
61

Molinari (2003, p.187) afirma que no teste automatizado de stress a ferramenta cria
usuários virtuais (Vu ou Vusers – Virtual User) e as situações de testes passam a ser
cenários (Scenarios). Nos cenários de teste simula-se, por exemplo, uma carga de
10 usuários virtuais a cada 30 segundos até 1000 usuários e com o teste durando no
máximo uma hora.
Enquanto a avaliação ocorre a ferramenta registra diversas informações que podem
indicar a presença de problemas durante a execução do teste, como por exemplo o
aparecimento de gargalos (gra.10).
Pode ser necessário um investimento adicional em hardware, dependendo da
“potência” que se deseja atingir com o teste. Mas atenção para não confundir o
desempenho do programa testado com o do servidor onde ele se encontra instalado.
3.3 FERRAMENTAS
Neste tópico citaremos as ferramentas de teste e apresentaremos informações
adicionais em alguns casos.
3.3.1 Suites
As principais suites são:
JProbe Suite (http://www.quest.com/jprobe/) é um conjunto de três
ferramentas, composto por: JProbe Profiler and Memory Debugger que
ajuda a eliminar gargalos de execução causados por algoritmos ineficientes
em códigos Java e aponta as causas de perdas de memória nessas
aplicações, rastreando quais objetos seguram referências para outros;
JProbe Threadalyzer, que monitora interações entre threads e avisa o
testador quando essa interação representar perigo, bem como identifica
potenciais perigos de concorrências e deadlocks; e JProbe Coverage, que
localiza códigos não testados e mede quanto do código está sendo
exercitado, permitindo ao testador estimar a confiança dos testes
executados. Delamaro et al (2007, p.170).
• SilkTest: pertence a Segue, mas a empresa é controlada pela Borland (qua.16);
62

• Rational: IBM (qua.17);
• QADirector: Compuware;
• JProbe Suite: Quest Software;
3.3.2 Software
Comentaremos agora as ferramentas de automação. Algumas, além de automatizar
testes em software também trabalham com sites web. Começaremos por uma que
apresenta essa característica.
A WinRunner é desenvolvida pela Mercury Interactive, mas a empresa é controlada
pela HP (Hewlett-Packard). Essa ferramenta cria uma lista com as propriedades
físicas juntamente com os respectivos valores de atribuição, usados para
identificação de cada objeto gráfico, formando o que é chamado de “descrição física”
do objeto. A relação entre a descrição física e o nome lógico é mantida em arquivos
chamados de GuiMap (veja a razão para a criação desses mapas no item 3.2.3
Data-Driven).
A WinRunner utiliza a técnica Capture/Playback, mas as limitações referentes ao uso
da MFC são resolvidas através de add-ins, isso é que possibilita o uso do
WinRunner em aplicações Java, PowerBuilder, Visual Basic e aplicações Web.
A ferramenta WinRunner também faz uso da técnica de script estruturado, ela possui
uma linguagem estruturada, semelhante a C, chamada TSL (Test Script Language),
Correia (2004, p.4).
O HiperStation grava telas em seqüência num arquivo PDS que recebe um
tratamento com uma linguagem de programação Rex. Ele é usado em plataforma
alta e funciona com o EXTRA! Enterprise, da Attachmate Corporation.
Os scripts criados no HiperStation são cadastrados no Control–M.
63

O Control-M é responsável por iniciar e controlar todo o fluxo de jobs (processos)
que serão executados dentro da periodicidade e dependências que foram
cadastradas dentro dele. Carvalho (2005).
A QA-Teste, desenvolvida pela empresa brasileira RSI Informática, é utilizada em
plataforma baixa, para auxiliar os processos de planejamento, criação,
documentação e manutenção de massa de testes. Essa ferramenta é focada no
planejamento e arquitetura de teste. Ela se integra as ferramentas de automação,
em particular a QA-Run, da Compuware. O uso em conjunto dessas ferramentas
ocorre da seguinte forma:
• Geração de Massas de Dados e “Scripts Padrões” (QA-Teste);
• “Filmagem” e Automatização (QA-Run);
Dois scripts são gerados pelo QA-Teste. No primeiro estão as definições das
variáveis conforme definidas na massa de testes e o caminho do arquivo de massa
de testes gerado pelo QA-Teste. Nesse arquivo também existe um loop para
executar cada caso.
No segundo estão às referências das variáveis definidas no primeiro. Esse é o script
usado para filmagem, e posteriormente para a automatização.
As ferramentas QA Wizard e e-Test podem ser utilizadas exclusivamente com a
técnica Record/Playback. Já as ferramentas Functional Tester, Robot, WinRunner,
QuickTestPro, TestSmith 5 , QA-Run e SilkTest, além da funcionalidade de gravação
de scripts de teste, oferecem uma linguagem de programação permitindo que a
técnica de programação de scripts seja utilizada. Nenhuma delas oferecem suporte
nativo às técnicas de automação de teste data-driven e keyword-driven, não
trabalham diretamente com o conceito de mapa de interface. Apesar disso, algumas
dessas ferramentas oferecem certa facilidade, em diferentes níveis, no uso da
técnica data-driven, Fantinato (2004, p.6).
5 http://qualityforge.com/testsmith/index.html
64

Vale lembrar que Fantinato usou as técnicas data-driven e keyword-driven com a
ferramenta IBM Rational Functional Tester for Java and Web através do framework
AutoTest.
TestMentor 6 e JFunc 7 (uma extensão funcional da ferramenta JUnit 8 usada para a
automação do teste de unidade) são ferramentas de suporte a automação de teste,
ambas oferecem suporte por meio da criação de classes de teste que devem
interagir diretamente com as classes do sistema, sendo compiladas e ligadas juntas,
Fantinato (2004, p.14).
O Visual Studio Team System, da Microsoft, permite automatizar a gerência da
qualidade e o SDLC (Software Development Life Cycle). Ele “profissionaliza” o
processo de testes com um pacote de ferramentas integradas de testes unitários,
cobertura de código, análise estática de código e carga, além dos recursos de
gerenciamento, Microsoft (2008).
3.3.3 Sites web
O Watir tem se destacado entre as ferramentas para automação de testes em sites
web. Existem vários fóruns na internet com milhares de participantes que interagem
entre si tirando dúvidas e trocando dicas sobre a operação da ferramenta e da
linguagem Ruby (linguagem de scripts utilizada pelo Watir).
Esta popularização é um fator a mais para as empresas escolherem essa
ferramenta, pois se torna mais fácil encontrar profissionais qualificados no mercado,
dispensando assim o custo com treinamento.
O Watir pode ser melhorado com o add-on Test-Report e a extensão WET, ambos
servem para gerar relatórios dos testes. Diferente de frameworks Java, como o
HttpUnit e o JWebUnit, o Watir realmente abre um browser Internet Explorer e vai
6 http://www.javatesting.com/Product/java/stm/index.html
7 JUnit Functional Testing Extension (http://jfunc.sourceforge.net/)
8 Ferramenta para execução de testes unitários e integrados em JAVA
65

ealizando ações, ele ainda não funciona com outros browsers. O Firefox, da Mozilla,
possui uma extensão chamada Web Developer que ajuda a implementar os testes
funcionais, Papo (2005).
A ferramenta ReWeb é usada para obter e analisar as páginas da aplicação web,
gerando a instância do metamodelo UML.
O TestWeb gera e executa o conjunto de casos de teste, conforme a instância do
metamodelo UML gerado pela ReWeb e o critério de teste que será empregado.
Após a execução dos casos de teste, o testador avalia os resultados obtidos, isto é,
verifica se a saída obtida está correta para determinada entrada. A ferramenta
também fornece uma saída numérica especificando o nível de cobertura alcançado
pelo conjunto de teste.
A ferramenta denominada WAT (Web Application Testing), implementa as funções
necessárias à geração de casos de teste, execução do conjunto gerado e avaliação
dos resultados obtidos com o processamento. A WAT utiliza a análise estática de
uma aplicação web resultante da execução da ferramenta WARE, que realiza
engenharia reversa da aplicação. Delamaro et al (2007, p.227-228).
O Fitnesse liga uma página web de um wiki ao seu sistema sob teste, através de
classes de negócio ou da interface do usuário. Esse modo de trabalho aumenta a
colaboração entre clientes e os desenvolvedores do sistema.
Um projeto que possui a filosofia data-driven e não a record/playback é o da
ferramenta Canoo WebTest. Ela utiliza como fundamento o HtmlUnit e os testes
são escritos através de arquivos XML, Papo (2005).
3.3.4 Estrutural
“A aplicação de critérios de teste sem o apoio de ferramentas automatizadas tende a
ser uma atividade propensa a erros e limitada a programas muito simples.”
(DELAMARO ET AL, 2007, p.65).
66

A RXVP80 e a TCAT, apóiam a aplicação de critérios estruturais baseados somente
no Grafo de Fluxo de Controle. A ferramenta RXVP80, distribuída pela General
Research Corporation, é um sistema que realiza basicamente a análise de cobertura
do teste de arcos em programas escritos em Fortran.
A ferramenta TCAT (Test-Coverage Analysis Tool), distribuída pela Software
Research Corporation, realiza o teste de unidades segundo o critério Teste de
Ramos Lógicos (arcos).
A ferramenta SCORE apóia o teste de arcos de programas escritos em Pascal,
tendo sido desenvolvida na Hitachi.
A POKE-TOOL (Potential Uses Criteria Tool for Program Testing) apóia a aplicação
de critérios no teste de unidade de programas escritos na linguagem C e encontra-
se disponível em ambiente UNIX. A versão mais recente está disponível na
Incubadora Virtual da FAPESP (http://incubadora.fapesp.br/projects/poketool/),
Delamaro et al (2007, p.65-69).
3.3.5 Mutação
Para apoiar o teste de mutação em POO, Alexander et al (apud DELAMARO ET AL,
2007, p.172), propuseram a arquitetura de uma ferramenta, denominada Object
Mutation Engine – OME, que implementa um subconjunto dos operadores de
mutação no teste de classes Java.
A Mutation Testing System implementa parte do conjunto de operadores de
mutação. A ferramenta utiliza o framework JUnit para documentar e executar de
forma automática os casos de teste, determinando o número de mutantes mortos e o
escore de mutação obtido, Delamaro et al (2007, p.173).
67

A ferramenta Mothra foi desenvolvida por pesquisadores da Purdue University e do
Georgia Institute of Technology e é utilizada em programas Fortran 77, Delamaro et
al (2007, p.97).
A Proteum é similar à Mothra, porém destina-se a linguagem C e possui algumas
facilidades para processamento bacth, Delamaro et al (2007, p.98-99).
3.3.6 Orientados a objetos e de componentes
A seguir será apresentada uma breve descrição, parcialmente extraída do trabalho
de Domingues (apud DELAMARO, 2007, p.169-173), é uma série de ferramentas
comerciais e não comerciais que se encontram disponíveis para o teste de POO e
algumas também destinadas ao teste de componentes, principalmente para o teste
de programas escritos em C++ e Java.
A ferramenta de teste PiSCES (Coverage Tracker for Java) é utilizada em teste de
applets Java. PiSCES é uma ferramenta de medida de cobertura (comandos e
decisões) que identifica quais partes do código-fonte já foram exercitadas durante a
avaliação e quais ainda precisam ser.
TCAT/Java e JCover servem para cobertura de comandos e decisões para applets
Java.
Parasoft C++ Test é utilizada em teste de unidade para códigos C/C++.
Parasoft Insure++ trabalha na detecção de defeitos em tempo de execução para
códigos C/C++ e acelera as tarefas de depuração.
ProLint Advanced Graphical Lint verifica os módulos de uma aplicação com o
objetivo de encontrar defeitos e inconsistências para mais de 600 tipos de
problemas, proporcionando maior confiabilidade e portabilidade de códigos C/C++.
68

Rational PureCoverage faz análise de cobertura (comandos e decisões) para
códigos C++ e Java.
Rational Purify detecta defeitos em tempo de execução para códigos C/C++. Como
a Rational PureCoverage, essa ferramenta permite ao testador escolher o nível de
verificação por módulos.
JaBUTi seu diferencial é a não-exigência da disponibilidade do código-fonte para a
realização dos testes. A ferramenta trabalha diretamente com bytecode Java e apóia
a aplicação dos critérios Todos-Nós, Todas-Arestas, Todos-Usos e Todos-
Potenciais-Usos no teste intramétodos.
Component Test Bench (CTB), pode ser utilizada no teste de componentes de
software. A ferramenta fornece um padrão genérico que permite ao desenvolvedor
do componente especificar o conjunto de teste utilizado na avaliação de um dado
componente. O conjunto de teste é armazenado em um arquivo XML (eXtensible
Markup Language) e executado por meio de uma ferramenta que compõe o CTB,
denominada IRTB (Instrumented runtime system), ou eles podem ser executados
invocando-se a execução de uma máquina virtual Java, ou ainda, compilando e
executando programas em C ou C++.
Parasoft JTest testa classes para códigos Java. A principal diferença entre JTest e
CTB é que JTest utiliza o framework JUnit para armazenar e executar os casos de
teste automaticamente, enquanto CTB armazena os casos em arquivos XML.
Glass JAR Toolkit (GJTK) é uma ferramenta de teste de cobertura que opera
diretamente no bytecode Java e não requer o código-fonte para aplicar critérios de
fluxo de controle (cobertura de comandos e decisões) em bytecode Java.
Nas ferramentas que permitem avaliação de cobertura de código por meio de
critérios estruturais, todas apóiam somente o teste de fluxo de controle (cobertura de
comandos e decisão) em POO. Nenhuma delas apóia a aplicação de algum critério
de fluxo de dados, seja para o teste de unidade, integração ou sistema. Com
exceção da ferramenta GlassJAR e as que apóiam o teste funcional, todas as
69

demais necessitam do código-fonte para a aplicação dos critérios, dificultando sua
utilização no teste estrutural de componentes de software por parte dos clientes, que
em geral, não têm acesso ao código-fonte.
3.3.7 Orientados a aspectos
A ferramenta JaBUTi/AJ é uma extensão da ferramenta Java Bytecode
Understanding and Testing (JaBUTi) proposta para o teste de POO escritos em
Java. JaBUTi/AJ foi estendida para testar a estrutura das unidades de programas
OA (orientados a aspectos) escritos em AspectJ, utilizando os modelos e critérios
descritos na seção anterior, Delamaro et al (2007, p.198).
3.3.8 Concorrentes
Segundo Delamaro et al (2007, p.246-249), a maioria das ferramentas existentes
auxilia a análise, a visualização, o monitoramento e a depuração de um programa
concorrente. Exemplos dessas ferramentas são: TDCAda que apóia a depuração de
programas na linguagem ADA, utilizando execução determinística; ConAn
(ConcurrencyAnalyser), que gera drivers para o teste de unidade de classes de
programas concorrentes Java; e Xab, MDB e Paragraph para programas escritos
em ambiente de passagem de mensagens. Xab e Paragraph objetivam o
monitoramento de programas PVM e MPI, respectivamente.
A ferramenta Della Pasta (Delaware Parallel Software Testing Aid) permite o teste
de programas concorrentes com memória compartilhada.
STEPS e Astral são ferramentas que apóiam a visualização e a depuração de
programas PVM. Ambas geram caminhos para cobrir elementos requeridos por
critérios estruturais baseados em fluxo de controle.
70

ValiPar permite que programas em diferentes ambientes de passagem de
mensagens sejam testados. Atualmente, a ferramenta encontra-se configurada para
PVM e MPI.
Quadro 11 – Ferramentas de teste/depuração para programas concorrentes
Ferramenta
Fluxo de
dados
Fluxo de
controle
Execução
controlada Depuração
TDC Ada a
ConAn b
Della Pasta c
Xab d
Visit d
MDB d
STEPS d
Astral d
XMPI e
Umpire e
d, e
ValiPar
a b c d e
Ada, Java, Shmem, PVM, MPI
Fonte: Delamaro et al (2007, p.249)
O quadro 17 sintetiza as principais características das ferramentas existentes para
apoiar a atividade de teste de programas concorrentes.
3.3.9 Open Source
Nos tópicos anteriores também foram citadas ferramentas gratuitas para automação
de testes. Citaremos mais algumas, adicionando comentários as já citadas.
PMD é utilizada para auditoria de código fonte Java; Selenium é uma ferramenta
GE para sites web; Fitnesse e o Watir, trabalham respectivamente com tabelas e
palavras-chave; Jmeter faz avaliação de desempenho.
JUnit é um framework de teste que vem sendo muito utilizado e viabiliza a
documentação e a execução automática de casos de teste. Quando se analisa o
Anexo O observa-se que o framework JUnit é uma das ferramentas que pode ser
utilizada tanto para o programa quanto para o teste de componentes de software
71

desenvolvidos em Java, mas tal ferramenta apóia apenas a execução automática de
casos de teste e realização de testes funcionais, sem apoio de nenhum critério de
teste específico e não fornecendo informação sobre a cobertura de código obtida por
determinado conjunto de teste. Outra ferramenta que também apóia somente o teste
funcional é a CTB, Delamaro et al (2007, p.171 e 173).
3.3.10 Faça você mesmo
Não existindo a intenção de produzir um produto melhor para o mercado, não há
motivo para “reinventar a roda”. Além dos custos com o desenvolvimento da
aplicação outros gastos irão surgir, como por exemplo, os gastos com treinamento,
pois não há conhecimento no mercado sobre a ferramenta e também não haverá
fóruns na internet com dicas sobre o produto.
Caso a empresa decida optar pelo desenvolvimento de uma nova ferramenta, ela
pode começar pelo estudo da API (Application Programming Interface ou Interface
de Programação de Aplicativos) que representa um conjunto de operações expostas
por uma aplicação, a fim de permitir que outras aplicações possam acessar ou
consumir as suas funcionalidades, esse recurso será útil na criação de ferramentas
captura/executa. A técnica de automação OLE também pode ser usada, porém esse
recurso necessita que o desenvolvedor especifique com qual aplicação a ferramenta
deve estabelecer um vínculo.
O objetivo de uma API é fornecer uma interface para o mundo exterior que
não seja dependente da interface gráfica da aplicação. A automação de
testes baseada na API faz uso dessa característica para orquestrar a
execução dos testes. Uma das vantagens advindas do uso de uma API é
que a aplicação externa que consome as operações expostas, não precisa
conhecer em detalhes como essas operações são implementadas.
(CAETANO, 2007).
Caso a ferramenta seja desenvolvida para avaliar sites web é mais adequado
analisar o resultado do conteúdo do arquivo e não o que é apresentado na tela. Por
exemplo, um GIF pode ficar mudando sua aparência, mas uma instrução será sempre a mesma.
72

CONSIDERAÇÕES FINAIS
Com o resultado dessa pesquisa passamos a conhecer os problemas da imprecisão
e morosidade dos testes manuais em contra ponto ao aumento do tamanho e da
complexidade dos programas. Conhecemos também os vários tipos de testes e
examinamos as principais técnicas utilizadas na automação. Identificamos que a
muito a se considerar em um processo de testes e que devemos planejá-los desde o
início do projeto de desenvolvimento, como também a necessidade de uma prévia
estruturação de todo o processo (técnicas, frameworks, ambientes, baselines, etc).
Esperamos que essa pesquisa tenha contribuído para orientação daqueles que
estão iniciando seu caminho em testes e que ela possa poupar seus esforços na
busca pela informação.
Fizemos um levantamento sobre ferramentas para todos os bolsos, mas esperamos
tê-lo conscientizado de que nem sempre esse é o principal custo de toda a operação
e a busca pelo equilíbrio entre os pilares custo, prazo e qualidade irá acompanhá-lo
em seu dia-a-dia na área de testes.
Vimos que a oferta das ferramentas, sob a estratégia caixa-branca, é determinada
pela linguagem usada no desenvolvimento e que a estratégia caixa-preta pode
oferecer soluções conjuntas para software e sites web. Também recomendamos a
escolha de ferramentas que possam combinar as técnicas de capture/playback,
data-driven, keyword-driven e scripts, seja com ou sem o uso de frameworks, além
de chamar a atenção para o refinamento e reutilização dos scripts e dos casos de
testes, como também para o futuro da técnica “modelo de dados”. Identificamos a
importância das ferramentas para geração automática de casos e massa de teste e
para os testes de stress.
Por último, sugerimos uma visita ao BSTQB (http://www.bstqb.org.br/), este órgão
apresenta em seu site o material necessário à certificação de profissionais de teste,
e leitura dos artigos sobre testes da Java Magazine e da recém lançada revista
Testing Experience (http://www.testingexperience.com/).
73

REFERÊNCIAS BIBLIOGRÁFICAS
ARGOLLO, Miguel. Automação de testes: Características, vantagens e limitações.
Trabalho apresentado durante o SBQS 2008 – VII SIMPÓSIO BRASILEIRO DE
QUALIDADE DE SOFTWARE, Florianópolis, jun. 2008.
BARTIÉ, Alexandre. Garantia da qualidade de software: Adquirindo maturidade
organizacional. Rio de Janeiro: Elsevier, 2002.
BORLAND. Automação de testes de software. [S.l.]: Borland, 2008. Disponível em:
. Acesso em: 10 ago. 2008, 12:13:40.
______. Gerenciamento da qualidade do ciclo de vida. [S.l.]: Borland, 2008.
Disponível em: . Acesso em: 31 ago. 2008, 11:50:45.
BRITO, Rosane Deganeli de. Do ambiente de desenvolvimento ao ambiente de
produção: Os testes de software como garantia da qualidade. Osasco: Universidade
Cândido Mendes, 2000.
CAETANO, Cristiano. Automação e gerenciamento de testes: Aumentando a
produtividade com as principais soluções Open Source e gratuitas (2a edição). [S.l.]:
Linha de Código, 2007. Disponível em: . Acesso em: 10 ago. 2008, 12:12:24.
______. Introdução à automação de testes funcionais. [S.l.]: TestExpert, 2007.
Disponível em: . Acesso em: 10 ago.
2008, 12:02:26.
CALLERI, Mário. Qualidade de software no desenvolvimento de sistemas
corporativos. Rio de Janeiro: Centro Educacional de Realengo, 2005.
CARVALHO, Cláudio et al. Apresentação EPD: Disciplina de teste. Rio de Janeiro:
REDEA/RJ, 31 mar. 2008.
CARVALHO, Cláudio; FILHO, Francisco de J.R. Automação dos processos de
testes. Rio de Janeiro: REDEA/RJ, 16 nov. 2005.
CORREIA, Simone; SILVA, Alberto. Técnicas para construção de testes
funcionais automáticos. [S.l.]: Instituto Português de Qualidade, 2004. Disponível
em: . Acesso
em: 13 set. 2008, 14:58:32.
DELAMARO, Márcio Eduardo; MALDONADO, José Carlos; JINO, Mario. Introdução
ao teste de software. Rio de Janeiro: Elsevier, 2007.
EUDESCOSTA. Automação de testes, uma tendência. [S.l.]: TestExpert, 2008.
Disponível em: . Acesso em: 14 set.
2008, 21:52:12.
74

FANTINATO, Marcelo et al. AutoTest – Um framework reutilizável para a automação
de teste funcional de software. [S.l.]: SBC – Sociedade Brasileira de Computação,
2004. Disponível em: . Acesso em: 10 ago. 2008, 12:03:26.
HETZEL, William. Guia completo ao teste de software. Rio de Janeiro: Campus,
1987.
IBM. Gerenciamento de qualidade de software. [S.l.]: IBM, 2008. Disponível em:
. Acesso em: 31 ago. 2008, 11:56:30.
MENDES, Alvaro. Novo ASC [mensagem pessoal]. Mensagem recebida por
em 25 ago. 2008.
MICROSOFT. Test Edition. [S.l.]: Microsoft, 2008. Disponível em: . Acesso em: 31 ago. 2008, 11:54:30.
______. Usando automação de interface do usuário para testes automatizados.
[S.l.]: Microsoft, 2008. Disponível em: .
Acesso em: 16 ago. 2008, 19:57:40.
MOLINARI, Leonardo. Testes de software: Produzindo sistemas melhores e mais
confiáveis. São Paulo: Érica, 2003.
OSHIRO, Ângela dos Santos. Gerência de projetos. Vila Velha: Escola Superior
Aberta do Brasil, 2007.
PAPO, José Paulo. Ferramentas para automação de testes. [S.l.]: José Papo
Weblog, 2005. Disponível em: . Acesso em: 10 ago. 2008, 11:59:28.
RSI Informática. Uso da ferramenta QA-Teste para controlar massas de teste.
Rio de Janeiro: REDEA/RJ, dez. 2005.
UNGARELLI, Adriano. Teste de software como controle de qualidade. [S.l.]: Via6,
2007. Disponível em: .
Acesso em: 31 ago. 2008, 12:00:20.
WIKIPÉDIA. Código aberto. [S.l.]: Wikipédia, 2008. Disponível em:
. Acesso em: 17 ago. 2008, 13:56:44.
75

GLOSSÁRIO
Varias das definições a seguir foram extraídas do site Wikipédia
(http://pt.wikipedia.org/).
Add-On ou Add-In – é o nome que se dá a um recurso ou acessório que melhora ou
aperfeiçoa a coisa à qual ele é acrescentado em utensílios eletrônicos. A expressão
é usada para softwares e hardwares em geral, mas é bastante típica de jogos para
computador (ou videogames) e consolas para videojogos.
Análise estática – a idéia é a mesma da auditoria de código, trata-se de uma
verificação da estrutura do código e das nomenclaturas de variáveis, funções,
objetos, entre outras atividades.
Bug – Defeito, falha no software ou site.
Engenharia reversa – elaborar a documentação de um sistema a partir dele próprio
(da operação do programa concluído).
Framework – captura a funcionalidade comum a várias aplicações. Elas devem
pertencer ao mesmo domínio de problema.
Grafo de Fluxo de Controle – é a representação usual para a relação de fluxo de
controle de um programa. Essas relações de dependências determinam a seqüência
necessária entre operações.
Hands-On - usar o programa propriamente dito.
Hard-Coded – é a inserção de dados diretamente pelo usuário em um programa.
Kaizen - significa de melhoria contínua, gradual, na vida em geral (pessoal, familiar,
social e no trabalho).
76

NewsGroups – são grupos de discussão on-line, o mesmo que fóruns, onde os
internautas com interesses em comum se juntam para falar de tudo, desde software
até política.
Open Source – Código Aberto. Software gratuito. O termo código aberto, ou open
source em inglês, foi cunhado pela OSI (Open Source Initiative) e se refere ao
mesmo software também chamado de software livre, ou seja, aquele que respeita as
quatro liberdades definidas pela Free Software Foundation.
Polimorfismo – permite que métodos apresentem várias formas, de acordo com seu
contexto. Por exemplo, quando podemos usar sorvete.cobertura(caldadechocolate)
no lugar do comando sorvete.cobertura(caldadechocolate, granulados) e vice-versa.
Post - essa palavra aparece no texto com o mesmo sentido de blog, Blog é uma
página web atualizada freqüentemente, composta por pequenos parágrafos
apresentados de forma cronológica.
REDEA/RJ – Uma das divisões da Caixa Econômica Federal responsável por
desenvolver e manter as soluções tecnológicas da instituição financeira.
Release – pequena atualização do programa.
Wiki – são utilizados para identificar um tipo específico de coleção de documentos
em hipertexto ou o software colaborativo usado para criá-lo.
77

ANEXO A – ESTRATÉGIAS DE TESTE
CAIXA-BRANCA CAIXA-PRETA
Figura 7 – Estratégias de testes caixa-branca e caixa-preta
78

ANEXO B – TIPOS DE TESTES (MOLINARI)
Segundo Molinari (2003, p.160-162) os tipos de teste são:
• Teste de unidade • Teste de integração
• Teste de sistema • Teste operacional
• Teste negativo-positivo • Teste de regressão
• Teste de caixa-preta (Black-Box Test) • Teste de caixa-branca (White-Box Test)
• Teste beta • Teste de verificação de versão
• Teste funcional • Teste de performance
• Teste de carga
• Teste de estresse
79
• Teste de aceitação do usuário ou UAT
(user acceptance test)
• Teste de volume • Teste de instalação
• Teste de configuração • Teste de integridade
• Teste de documentação • Teste de aplicações Mainframe
• Teste de segurança • Teste de aplicações Server
• Teste de aplicações Client • Teste de aplicações Web
• Teste de aplicações Network • Teste de ameaça ou Thread
• Teste de monitoração • Teste de módulo
• Monkey Test

ANEXO C – COMPLEMENTO DE TIPOS (BRITO)
A seguir apresentamos parte da lista de Rosane Brito, apenas com tipos não citados
anteriormente no Anexo B.
Classificando alguns tipos de teste dentro das estratégias de testes (caixa-branca e
caixa-preta) temos o seguinte, Brito (2000, p.23-34):
• Caixa-preta • Caixa-branca
o Teste de partição de equivalência o Teste de caminhos básicos
o Teste dos valores limites o Testes de condição
o Teste baseado em probabilidade de
o Técnicas de testes de condição
erro Teste de ramos
o Teste de comparação Teste de domínio
80
Teste de ramos e operadores
relacionais
Teste de laço simples
Teste de laço aninhado
Teste de laços concatenados
Teste de laços não estruturados

ANEXO D – PROCESSO DE TESTES
Figura 8 – Visão do modelo de processo de qualidade de software em “U”.
Fonte: Bartié (2002, p.36)
81

ANEXO E – AQUISIÇÃO DE FERRAMENTAS
Quadro 12 – O que automatizar?
Razões para o desenvolvedor
1. Quantas vezes você repete o teste de uma mesma funcionalidade até retirar todos os “bugs”
existentes?
2. E quanto tempo isto representa em relação ao tempo de escrita de código e compilação? Você
concordaria em dizer que pelo menos 50% do tempo em que você está na frente do
computador, está re-testando alguma coisa que não funcionou na primeira compilação como
deveria, ou que estava funcionando e parou de funcionar?
3. Quando você corrige um “bug”, garante que não introduziu outro?
4. Para garantir que tudo está funcionando em uma aplicação, após cada compilação, é preciso
repetir todos os testes?
5. Como você faria para testar o comportamento da sua aplicação quando dois ou mais usuários
executassem, exatamente no mesmo instante, funcionalidades que podem influenciar uma na
outra? E se fossem 50 usuários? A sua aplicação vai perder performance? Vai funcionar
errado?
6. Já aconteceu de você atender a reclamações de seu usuário dizendo que uma funcionalidade
não está funcionando e ela estava perfeita na versão anterior?
7. Imagine que, quando você testou uma parte da aplicação pela primeira vez, uma “câmera de
vídeo inteligente” estava atrás de você e decorou exatamente como repetir esse teste mais
tarde e apenas lhe diz o que funcionou da mesma forma e o que mudou de comportamento.
Imagine agora que sempre que recompilar sua aplicação esse robô pode repetir todos os testes
que você já fez enquanto toma um café?
Razões para o gerente
8. Quanto você gastou no último projeto entre a aparente conclusão da aplicação e a efetiva
conclusão de toda a fase de testes e ajustes? Quanto isso representou de tempo no seu
cronograma? E de dinheiro?
9. Sua equipe de programação certamente não trabalhava 24 horas por dia. O desenvolvedor
precisa descansar. Enquanto isto, como aproveitar da melhor forma possível a máquina
parada? Não seria útil que ela ficasse executando sozinha alguma atividade mecânica em vez
de ficar desligada? Que tal se enquanto seu desenvolvedor dorme, um robô executasse todos
os testes que precisam ser executados para verificar se a aplicação está funcionando
corretamente?
10. E que tal se no dia seguinte cada desenvolvedor tivesse em cima de sua mesa, ou na sua caixa
postal eletrônica, uma lista de todas as mudanças de comportamento da aplicação em relação a
uma versão anterior? Não seria bom também que ao registrar, o defeito tivesse sido corrigido, o
usuário fosse imediatamente avisado através de caixa postal?
11. O que você acha de poder deixar o desenvolvedor só desenvolvendo e retirar dele a
responsabilidade de testar a aplicação? E se a “câmera de vídeo inteligente” que havia gravado
seus testes, além de na manhã do dia seguinte distribuir todos os possíveis defeitos
identificados para os desenvolvedores responsáveis, que tal se lhe entregasse periodicamente
estatísticas como, tipos de defeito mais encontrados, número de defeitos encontrados no
período de responsabilidade do desenvolvedor, tempo médio de solução dos defeitos, etc.
12. E sua equipe de suporte é sempre igual à que desenvolveu o sistema? Quando um
desenvolvedor assume o suporte de um módulo desenvolvido por outro, quanto tempo em
média ele leva para conhecer todos os detalhes sobre as funcionalidades da aplicação? Em
algum lugar existe um script detalhado sobre todos os testes que devem ser feitos no aplicativo
para garantir que a nova versão está livre de problemas?
Fonte: Molinari (2003, p.103-104)
82

ANEXO F – FUNCIONAMENTO DA FERRAMENTA DE TESTE
Dados de teste
Resultados
esperados
Scripts
Ferramenta
Scripts
Relatórios
Figura 9 – Funcionamento de uma ferramenta de testes
Fonte: Argollo (2008)
Dados
Resultados
Interface Gráfica
Programa em
Teste
83

ANEXO G – DISTRIBUIÇÃO DO ESFORÇO - PROJETOS NOVOS
Fonte: REDEA/RJ
Tabela 9 – Custo/esforço em projetos novos
84

ANEXO H – DISTRIBUIÇÃO DO ESFORÇO - MANUTENÇÃO
Fonte: REDEA/RJ
Tabela 10 – Custo/esforço na manutenção de sistemas
85

ANEXO I – DISTRIBUIÇÃO DO ESFORÇO - AMBIENTE
Tabela 11 – Custo/esforço na montagem em ambiente de homologação
Fonte: REDEA/RJ
86

ANEXO J – COMPARANDO FERRAMENTAS
Neste quadro foram usados notas de 1 a 10. Os pesos escolhidos foram 1, 3 e 9,
pois eles são de base cúbica (3 x ). Este tipo de técnica reflete mais facilmente os
pesos de itens que serão avaliados.
Tabela 12 – Exemplo de requerimento num quadro comparativo
Fornecedor Empr A Empr B
Ferramenta Soft A Soft B
Critérios Peso/Notas Ideal Nota Nota
Facilidade de Uso 1 10 9 7
Produtividade 1 10 9 7
Confiabilidade 1 10 9 8
Recursos de monitoração em geral 1 10 9 7
Recursos de gráficos em geral 1 10 9 7
Recursos de relatórios em geral 1 10 9 7
Recursos de customização 3 10 9 7
Suporte a gráficos atuais 3 10 8 5
Monitoração local (ex: REP em prod.) 3 10 8 7
Documentação disponível 1 10 8 5
Monitoração app Web 3 10 8 7
Monitoração app Client Server 3 10 10 5
Monitoração app Siebel 3 10 8 10
Monitoração app Magellan 3 10 7 5
Integração com BD Oracle 3 10 7 8
Integração com outros BD 1 10 8 7
Integração horizontal/vertical 1 10 9 5
Política de licença 3 10 10 10
Força do fabricante 1 10 8 7
Popularidade HOJE 1 10 10 9
Representação no Brasil 1 10 10 8
Representação no RJ 3 10 7 5
Serviços de suporte 3 10 8 10
TCO (avaliado inversamente) 1 10 7 7
Suporte - Profissionais disponíveis 1 10 5 8
Suporte - Custo (avaliado inversamente) 9 10 9 6
Custo - Produto (avaliado inversamente) 9 10 8 9
TOTAL 650 542 471
Percentual relativo ao ideal 0,83384615 0,72461538
Fonte: Molinari (2003, p.111-112)
87

ANEXO K – TIPOS DE FERRAMENTAS SEGUNDO MOLINARI
Test Design
Quadro 13 - Visão Comercial
Ajuda na decisão da escolha do teste que precisa ser executado.
GUI Test Drivers &
Capture/Replay
Ajudam na execução de testes que façam uso de uma GUI (graphical
user interface), independente se a aplicação é Web, Client-Server, Java,
etc.
Load & Performance
Ferramentas especializadas em dar “uma carga pesada de dados” ao
sistema. Também conhecido como ferramentas do “test-driver”.
Non-GUI Test Drivers Ferramentas de automação de execução dos testes com uma interface
& Test Managers gráfica. Podem trabalhar com grandes suites de testes.
Ferramentas que ajudam na implementação dos testes. Um exemplo
Test Implementation típico seria a geração automática de sub-rotinas para tratamento de
falhas óbvias no programa.
Test Evaluation
Ferramenta que ajuda a avaliar a qualidade dos seus testes A ferramenta
de análise de cobertura de código (“code coverage”) seria um exemplo.
Static Analysis
Ferramentas que analisam o programa sem executá-lo. Ferramentas de
métricas pertencem a esta categoria.
Defect Tracking
Ferramentas que ajudam a gerenciar um “banco de dados” com os
defeitos encontrados.
Fonte: Molinari (2003, p.107)
Quadro 14 - Visão Acadêmica
Capture/Replay Captura os comandos executados por usuários e os executam.
Code Auditors Análise e auditoria de código que está sendo testado.
Debuggers
Ferramentas típicas dos programadores, que visam retirar erros básicos
do código desenvolvido.
Standards Checkers Ferramentas que permitem verificar padrões de interface.
Structural Analyzers
Ferramentas que permitem analisar a estrutura de aplicação-alvo de
teste.
Test Coverage
Analyzers
Análises de cobertura de código.
Test Data Extraction Ferramentas de extração e verificação de dados para teste.
Test Data Generators Ferramentas de geração de massas de dados para teste.
Test Management Ferramenta de gerenciamento de teste.
Fonte: Molinari (2003, p.107-108)
Ferramenta de testes
funcional e regressão
(caixa-preta)
Ferramenta de teste de
performance e carga
Ferramenta de planejamento
de testes
Ferramenta de testes de
monitoração
Ferramentas de testes
estrutural (caixa-branca)
Fonte: Molinari (2003, p.108)
Quadro 15 – Novas Tendências
Captura os comandos executados por usuários e os executam.
Testar performance e carga de um sistema torna-se cada vez
necessário.
Planejar testes torna-se cada vez mais necessário.
Testes em tempo real da aplicação em produção, verificando sua
disponibilidade. O seu SLA se tornou necessário.
Testar o código quando ele está em sua concepção tem se tornado
extremamente útil para melhorar a qualidade do código em si.
88

ANEXO L – EXEMPLOS DE TABELAS DATA-DRIVEN
Tabela 13 - Cadastro de clientes
Sobrenome Nome Conta Depósito
Silva José 30.123-A 12.700,00
Moraes Carlos 40.456-B 8.200,00
Fonte: Argollo (2008)
Tabela 14 - Transferência
Conta Conta Valor
30.123-A 40.456-B 500,00
Fonte: Argollo (2008)
Tabela 15 - Verificação de saldo
Conta Saldo
30.123-A 12.200,00
40.456-B 8.700,00
Fonte: Argollo (2008)
89

ANEXO M – SUITES SEGUE (BORLAND) E IBM
Quadro 16 - Ferramentas da Borland para a automação de testes de software
Borland Gauntlet Integração contínua e cobertura de código para desenvolvimento ágil
Borland SilkPerformer Automação de teste de performance e carga para software
Borland SilkTest Automação de teste funcional e de regressão
SilkCentral Test Manager
Fonte: Borland (2008)
Gerenciamento de qualidade por meio do alinhamento entre requisitos
e objetivos de negócios
Quadro 17 - Ferramentas da IBM para a automação de testes de software
Rational Functional Tester
Rational Functional Tester
Extension for Terminalbased
Applications
Rational Manual Tester
Rational Purify for Linux
and UNIX
Rational Purify for
Windows
Rational PurifyPlus
Enterprise Edition
Rational PurifyPlus for
Linux and UNIX
Rational PurifyPlus for
Windows
Rational Robot Rational
Robot
Rational Test RealTime
Fonte: IBM (2008)
Testes funcionais automatizados avançados de aplicativos Java, da
Web e VS.NET baseados em WinForm.
Estende o Rational Functional Tester para suportar o teste de
aplicativos baseados em terminal.
Aprimora os esforços de autoria e execução de testes manuais
utilizando novas técnicas de design de testes.
Fornece detecção de fuga de memória e de corrupção de memória
para Linux e UNIX.
Fornece detecção de fuga de memória e de corrupção de memória
para Windows.
Fornece análise de tempo de execução para Windows, Linux e UNIX.
Conjunto de ferramentas de análise de tempo de execução para
desenvolvimento em Java e C/C++ baseado em Linux e UNIX.
Análise do tempo de execução para desenvolvimento em Java, C/C++,
Visual Basic e .NET gerenciado baseado em Windows.
Ferramenta de automatização de testes de uso geral para aplicativos
cliente/servidor.
Permite o teste de componentes e a análise em tempo de execução
para software integrado e de tempo real de plataformas cruzadas.
90

ANEXO N – SOLUÇÕES COMERCIAIS
Ferramenta Informações
WinRunner
Quadro 18 – Ferramentas comerciais
Automação de software e sites web, desenvolvida pela Mercury Interactive
(http://www.mercuryinteractive.com/)
QuickTest Pro Mercury Interactive (http://www.mercuryinteractive.com/)
TestComplete AutomatedQA (http://www.automatedqa.com/)
Ap Test Manager ApTest (http://www.aptest.com/resources.html)
e-Test Empirix (http://www.empirix.com/)
TestArchitect LogiGear (http://www.logigear.com/)
Eccox Auditoria de código fonte (Cobol/DB2), Eccox (http://www.eccox.com.br/)
XPediter Compuware (http://www.compuware.com/)
QA-Load
Ferramenta usada para teste de stress, Compuware
(http://www.compuware.com/)
QA-Run Automatização de plataforma baixa, Compuware (http://www.compuware.com/)
HiperStation
Automatização de plataforma alta (on-line), Compuware
(http://www.compuware.com/)
Devpartner Auditoria de código fonte (JAVA), Compuware (http://www.compuware.com/)
Família File-Aid Controle de confiabilidade, Compuware (http://www.compuware.com/)
QA-Teste
Estruturação e controle dos casos e da massa de teste, RSI Informática
(http://www.rsinet.com.br/)
Control-M Controle de produtividade, BMC Software (http://www.bmc.com/)
QA-Wizard Seapine (http://www.seapine.com/qawizard.html)
IPL
LDRA Ltd
Testwell
ADL Translation
System
Para as linguagens AdaTEST, Cantata, Cantata++, geração automática dos
casos de teste baseadas em código fonte, IPL (http://www.iplbath.com/)
Geração automática dos casos de teste baseadas em código fonte, LDRA
Testbed (http://www.ldra.com/)
Para C, C++ e Java, geração automática dos casos de teste baseadas em
código fonte, Testwell (http://www.testwell.sci.fi/homepage.html)
Geração automática dos casos de teste baseadas em especificação formal
91

ANEXO O – SOLUÇÕES COMERCIAIS
Quadro 19 – Características apresentadas pelas ferramentas de teste OO
Ferramentas de
teste de software
Teste de unidade
Teste de integração
Teste de sistema
Critérios funcionais
PiSCES Java
SunTest Java
xSuds Toolsuite C/C++
JProbe Developer Suite Java
TCAT/Java Java
JCover Java
Parasoft C++ Test C/C++
Parasoft Insure++ C/C++
ProLint C/C++
Rational PureCoverage C++/Java
Rational Purify C/C++
JUnit Java
Cobertura Java
JaBUTi Java
CTB Java/C/C++
Parasoft JTest Java
Glass JAR Toolkit Java
Object Mutation Engine Java
Ferramenta de Chevalley Java
Ferramenta de Ma et al Java
Mutation Testing System Java
Fonte: Delamaro et al (2007, p.174)
Critérios de fluxo de controle
Critérios de fluxo de dados
Critérios baseados em mutação
Linguagem suportada
Exigências de código-fonte
Atividade de depuração
Teste de regressão
92

ANEXO P – FERRAMENTAS DE TESTE GRATUITAS
Quadro 20 - Melhores ferramentas Open Source para gestão e automação
Categoria Ferramenta
Gestão de
projetos
Testes de
performance
Gestão de testes
Gestão de
defeitos
Gestão de
requisitos
ProjectKoach - http://www.projectkoach.com/
PHP-Collab - http://www.php-collab.org/
GanttProject - http://ganttproject.biz/
Project-Open - http://www.project-open.com/
OpenWorkbench - http://www.openworkbench.org/
XPlanner - http://www.xplanner.org/
WebCollab - http://webcollab.sourceforge.net/
Mindquarry - http://www.mindquarry.com/
OpenSTA - http://www.opensta.org/
JMeter - http://jakarta.apache.org/jmeter/index.html
Microsoft WEB Application Stress Tool -
http://www.microsoft.com/downloads/details.aspx?FamilyID=e2c0585a-062a-439ea67d-75a89aa36495&DisplayLang=en
Webload - http://www.webload.org/
The Grinder - http://grinder.sourceforge.net/
TestLink - http://www.teamst.org/
QaManager - http://qamanager.sourceforge.net/
RTH - http://www.rth-is-quality.com/
TestMaster - http://testmaster.sourceforge.net/
Testitool - http://majordojo.com/testitool/
Test Case Web (TCW) - http://tcw.sourceforge.net/
Testopia - http://www.mozilla.org/projects/testopia/
Mantis - http://www.mantisbt.org/
Bugzilla - http://www.bugzilla.org/
Scarab - http://scarab.tigris.org/
BugNET - http://www.bugnetproject.com/
TRAC - http://trac.edgewall.org/
OSRMT - http://www.osrmt.com/
Tiger PRO - http://www.seecforum.unisa.edu.au/seectools.html
Xuse - http://xuse.sourceforge.net/
REM (REquisite Management) -
http://www.lsi.us.es/descargas/descarga_programas.php?id=3
93

Testes
funcionais
TRUC - http://sourceforge.net/projects/truc
Plandora - http://plandora.sourceforge.net/
Jeremia - http://jeremia.sourceforge.net/
Selenium (WEB) - http://www.openqa.org/selenium/
actiWATE (WEB) - http://www.actiwate.com/
Marathon (Java Swing) - http://www.marathontesting.com/marathon/
Watir (WEB) - http://wtr.rubyforge.org/
Canoo WEBTest (WEB) - http://webtest.canoo.com/
Apodora (WEB) - http://www.apodora.org/
Abbot (Java Swing) - http://abbot.sourceforge.net/
SoapUI (WEBServices) - http://www.soapui.org/
SOAPSonar Personal Edition (WEBServices) - http://www.crosschecknet.com/
LISA WS-Testing (WEBServices) -
http://www.itko.com/site/products/lisa/ws_testing.jsp
Squish for KDE (Linux) - http://www.froglogic.com/
SharpRobo (WinForm .NET) -
http://confluence.public.thoughtworks.org/display/SHRO/Home
FitNesse - http://fitnesse.org/
Estimativas Construx Estimate - http://www.construx.com/Page.aspx?nid=68
Controle de
versões
Fonte: Caetano (2007)
TortoiseCVS http://www.tortoisecvs.org/
WinCVS - http://www.wincvs.org/
Subversion - http://subversion.tigris.org/
Darcs - http://darcs.net/
94