escola superior aberta do brasil – esab pÓs … · escola superior aberta do brasil – esab...
TRANSCRIPT
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
Aprovada em ....... de .................. de 2008
VILA VELHA – ES
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
14
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.
15
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.
16
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
1980
Primeiros conceitos de qualidade de software, criação dos padrões: • 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.
17
Quadro 3 - Evolução do processo de qualidade e de t estes 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 qualidade
Pequeno Algum Significante
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.
18
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.
19
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.
20
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.
Performance Médio impacto Checa o desempenho do programa, ou seja, verifica se ele 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).
Segurança Essencial Simula invasões com o intuito de obter informações sigilosas ao que possam prejudicar o funcionamento do sistema.
Carga e Concorrência
Alto impacto
Também conhecido como teste de stress ele funciona simulando situações atípicas no sistema, como aumento no tráfego da rede, transações sucessivas e simultâneas, entre outras.
Usabilidade Médio impacto Verifica a navegação nas telas, clareza das mensagens, 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.
Configuração Baixo impacto Também conhecido como teste de portabilidade, testa o 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.
Instalação Médio impacto
Analisa o comportamento do sistema, durante o processo de instalação, nas mais diversas possibilidades, por exemplo: nova instalação, reinstalação, variação de alternativas para instalação.
Volume Alto impacto
É semelhante ao teste de carga, porém esse não trabalha com oscilações e sim com o crescimento contínuo da base 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.
21
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? 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.?
Funcionalidade (satisfaz as necessidades?)
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 É fácil entender o conceito e a aplicação? Apreensibilidade É fácil aprender a usar?
Usabilidade (é fácil de usar?)
Operacionalidade É fácil de operar e controlar?
Tempo Qual é o tempo de resposta, a velocidade de execução?
Eficiência (é rápido e "enxuto"?) Recursos Quanto recurso usa? Durante quanto tempo?
Analisabilidade É fácil de encontrar uma falha, quando ocorre? Modificabilidade É fácil modificar e adaptar? Estabilidade Há grande risco quando se faz alterações?
Manutenibilidade (é fácil de modificar?)
Testabilidade É fácil testar quando se faz alterações? Adaptabilidade É fácil adaptar a outros ambientes? Capac. para ser instalado
É fácil instalar em outros ambientes?
Conformidade Está de acordo com padrões de portabilidade?
Portabilidade (é fácil de usar em outro ambiente?)
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.
22
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 homologador1, 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.
23
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.
Teste:Sistema Teste:
Categoria: AceitaçãoFuncional
CargaPerformace Categoria:Instalação Beta-testeSegurança
Em desenvolvimento
Em produção
Ambiente de desenvolvimentoAmbiente de teste e
homologaçãoAmbiente de produção
Em teste Em homologação
Desenvolvimento
FontesEstrutura interna
Teste: Unidade
Integração
Categoria: Funcional
Usabilidade
Teste: Aceitação
Categoria: Aceite formal Alpha-teste
Produção
Figura 2 – Ambientes Fonte: Bartié (2002, p.166-167)
24
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.
25
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.
26
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
27
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.
28
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
29
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
30
• 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:
Quadro 6 – Normas de qualidade em desenvolvimento d e software Norma 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)
NBR ISO 9000-3 Gestão de qualidade e garantia de qualidade. Aplicação da norma ISO 9000 para 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 15504
Projeto da ISO/IEC para avaliação de processo de desenvolvimento de software. Ainda não é uma norma oficial ISO, mas o processo está em andamento.
Fonte: Oshiro (2007, p.151)
31
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ÇOAMENTOOTIMIZADO DO PROCESSO
NÍVEL 4 PROCESSO MEDIDO EGERENCIADO CONTROLADO
NÍVEL 3 PROCESSO CARACTERIZADO EDEFINIDO BEM ENTENDIDO
NÍVEL 2 TAREFAS "MESTRAS" PODEM SERREPETITIVO REPETIDAS CONTINUAMENTE
NÍVEL 1 PROCESSO IMPREVISÍVEL EINICIAL POUCO CONTROLADO
ANÁRQUICO
OTIMIZADO
MENSURÁVEL
PADRONIZADO
CULTURAL
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).
32
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).
33
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
34
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:
Window.Localizar.ProcurarPor.TypeText(“automação”); Window.Localizar.Diferenciar.Click(); Window.Localizar.Localizar.Click(); MainWindows.Document.ChechSelText(“automação”);
Figura 5 – Exemplo de script Fonte: Argollo (2008)
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,
35
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 fo car em teste manual? Para valer a pena, devemos observar as seguintes questões: • Os testes que usarem técnicas de regressão
ou de confirmação. Quando precisa constan-temente do trabalho de repetir.
• Quando se faz uso de testes aleatórios (random ou monkeys testes) que utilizam caminhos aleatórios gravados por dentro da aplicação e de grande quantidade de dados de testes.
• Testes de carga, volume, capacidade. Como responder se o sistema funcionará com 50 mil usuários simultâneos?
• Performance e confiabilidade. Com a “chega-da” dos sistemas web, cada vez mais vemos este tipo de sistema fazer uso de ferramen-tas de performance.
• Quando se faz teste de componentes (unida-de) os quais devem ser retestados várias vezes.
Para valer a pena focar em testes manuais, devemos observar as questões seguintes: • Quando se faz uso de testes de instalação,
setup, operações muito específicas, como, por exemplo, que envolvam hardware (ex.: instalação de componentes de equipamen-tos). Isto inclui manutenções em geral.
• Faz uso de testes de configuração e de com-patibilidade. Este tipo de teste geralmente requer muita intervenção humana.
• O mesmo vale para testes de error handing (tratamento de erros) e de recuperação. No-vamente este tipo de teste trabalha com er-ros forçados de maneira que repeti-los pode ficar caro.
• Testes de usabilidade. Mais um caso em que é preciso intervenção humana para o devido julgamento e validação dos testes.
• O mesmo anterior vale para documentação e help.
Fonte: Molinari (2003, p.105)
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.
36
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.
0
100
200
300
400
500
600
700
Design P
hase
Release
1
Release
2
Release
3
Release
4
Release
5
Release
6
Release
7
Release
8
Release
9
Release
10
Manual
CaptureReplay
Scripts
ActionWord
ModelBased
Gráfico 1 – Custo hipotético (em horas) para diferentes processos de teste Fonte: Mark Utting (apud ARGOLLO, 2008)
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 Prom oções Tipo de métrica Teste manual Teste automatizado Número de casos de teste executados 930 1644
Cobertura funcional dos casos de teste1 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)
37
-
1.200,00
2.400,00
3.600,00
4.800,00
6.000,00
7.200,00
Evolu
ção
Re-exe
cuçã
o 1
Re-exe
cuçã
o 2
Re-exe
cuçã
o 3
Re-exe
cuçã
o 4
Re-exe
cuçã
o 5
Re-exe
cuçã
o 6
Re-exe
cuçã
o 7
Re-exe
cuçã
o 8
Re-exe
cuçã
o 9
Re-exe
cuçã
o 10
Manual
Automático
Ganho
Gráfico 2 – Teste manual x teste automatizado do módulo de Promoções Fonte: Fantinato (2004, p.11)
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.
38
Tabela 3 – Métricas coletadas para o módulo de Aten dimento 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
(estimado) 4 h
Análise dos resultados e registro de erros 100 h
(estimado) 62 h
Fonte: Fantinato (2004, p.12)
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.
-
200,00
400,00
600,00
800,00
1.000,00
1.200,00
1.400,00
1.600,00
1.800,00
Projet
o
Execu
ção
inicia
l
Re-exe
cuçã
o 1
Re-exe
cuçã
o 2
Re-exe
cuçã
o 3
Re-exe
cuçã
o 4
Re-exe
cuçã
o 5
Re-exe
cuçã
o 6
Re-exe
cuçã
o 7
Re-exe
cuçã
o 8
Re-exe
cuçã
o 9
Re-exe
cuçã
o 10
Manual
Automático
Ganho
Gráfico 3 – Teste manual x teste automatizado do módulo de Atendimento a Clientes Fonte: Fantinato (2004, p.12)
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.
39
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
40
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 funcionalida-des 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
41
(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:
55%
35%
20%
10%
5%
0%
10%
20%
30%
40%
50%
60%
1 2 3 4 5
Nível de maturidade
Esf
orço
de
corr
eção
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:
42
0%
25%
15%
10%
5%
0%
5%
10%
15%
20%
25%
30%
1 2 3 4 5
Nível de maturidade
Esf
orço
ger
enci
al
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.
43
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.
1
10
100
1000
10000
Requisitos Análise emodelagem
Código Teste desoftware
Produção
Gráfico 6 – Regra de 10 de Myers Fonte: Bartié (2002, p.31)
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.
44
-
2.000,00
4.000,00
6.000,00
8.000,00
10.000,00
12.000,00
14.000,00
16.000,00
Requisitos Projetos Codificação Teste Manutenção
Fases de desenvolvimento
Gráfico 7 – Custo de correção de defeitos Fonte: Argollo (2008)
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á
45
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 autom atizados
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.
46
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
Teste Manual
• Baixo risco de não-cobertura • Alto custo de execução • Execução lenta • Reutilização zero • Interferências humanas
• Alto risco de não cobertura • Custo de execução menor • Execução lenta • Reutilização zero • Interferências humanas
Teste Automatizado
• Baixo risco de não-cobertura • Baixo custo de execução • Execução rápida • Reutilização total • Sem interferências humanas
• Alto risco de não cobertura • Menor custo de execução possível • Execução mais rápida possível • Reutilização total • 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).
0
5
10
15
20
25
Funcio
nalid
ade
Perfo
rmanc
e
Segur
ança
Usabil
idade
Dispon
ibilidad
e
Opera
bilida
de
Gráfico 8 – Risco de teste numa aplicação de TI tradicional Fonte: Molinari (2003, p.180)
Como já mencionamos anteriormente, o nível de importância de cada categoria pode
mudar em função do projeto e dos riscos envolvidos.
47
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.
0
2
4
6
8
10
12
14
Funcio
nalid
ade
Perfo
rmanc
e da R
esid
ência
Segur
ança
Itens
de
Perfo
rmace
do
Site
Inte
graçã
o
Infra
-estr
utur
a
Usabil
idade
Loca
lizaç
ão
Dispon
ibilidad
e Pós
-ent
rega
Gráfico 9 – Risco de teste numa aplicação web Fonte: Molinari (2003, p.181)
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.
48
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
Percentual de Esforço
Percentual de 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
28% 30%
Execução e evidenciação de teste de Aceite de um 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 10% 10%Fonte: Carvalho (2008, s.16)
Atividade
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 (impl antaçã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 legado
40%
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,002 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).
49
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:
(nº de pessoas envolvidas * nº de dias gastos) * custo por pessoa-dia Custo médio do defeito =
(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
50
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 zero3, 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
51
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 • Maior custo de re-execução • Execução mais lenta • Reutilização zero • Com interpretações humanas
• Planejamento mais complexo • Menor custo de re-execução • Execução mais rápida • Reutilização total • Sem interpretações humanas
Fonte: Bartié (2002, p.198)
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?)
52
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
comerciais4 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.
53
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:
Quadro 10 – Tipos de automação Paradigma Vantagens Desvantagens Baseado na Interface Gráfica
Não requer modificações na aplicação para criar os testes automatizados. Também não é necessário tornar a aplicação mais fácil de testar (testabilidade) porque os testes se baseiam na mesma interface utilizada pelos usuários.
Existe uma forte dependência da estabilidade da interface gráfica. Se a interface gráfica mudar, os testes falham. Baixo desempenho para testes automatizados que exigem centenas de milhares de repetições, testes de funcionalidades que realizam cálculos complexos, integração entre sistemas diferentes e assim por diante.
Baseado na Lógica de Negócio
Foco na camada onde existe maior probabilidade de existir erros. Independência das mudanças da interface gráfica. Alto desempenho para testes automatizados que exigem centenas de milhares de repetições, testes de funcionalidades que realizam cálculos complexos, integração entre sistemas diferentes e assim por diante.
Requer grandes modificações na aplicação para expor as funcionalidades ao mundo exterior. Exige profissionais especializados em programação para criar os testes automatizados. Existem poucas ferramentas/frameworks que suportam essa abordagem (normalmente é necessário criar soluções caseiras).
Fonte: Caetano (2007)
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).
54
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
55
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.
56
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.
57
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.
58
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
59
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).
60
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
61
possibilitou um melhor gerenciamento dos resultados e a obtenção de relatórios
mais específicos e detalhados.
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).
3.2.5 Teste de estresse
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?
0
2
4
6
8
10
12
14
16
1 2 3 4 5 6 7 8 9 10
Número de usuários
Tem
po d
e re
spos
ta (
segu
ndos
)
Gráfico 10 – Tempo de resposta x nº de usuários (como descobrir gargalos) Fonte: Molinari (2003, p.188)
Gargalo
62
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
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).
As principais suites são:
• SilkTest : pertence a Segue, mas a empresa é controlada pela Borland (qua.16);
63
• 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.
64
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
65
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 JUnit8 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
66
realizando 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).
67
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).
68
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++.
69
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
70
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.
71
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 pro gramas concorrentes
FerramentaFluxo de
dadosFluxo de controle
Execução controlada
Depuração
TDC Adaa �ConAnb �Della Pastac � � �Xabd �Visitd �MDBd � �STEPSd � � �Astrald � �XMPIe �Umpiree �ValiPard, e � � � �aAda, bJava, cShmem, dPVM, eMPI 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
72
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 <IMG
SCR=”arquivo.gif”> será sempre a mesma.
73
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/).
74
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: <http://www.borland.com/br/solutions/lifecycle-quality-management/test-automati on.html>. Acesso em: 10 ago. 2008, 12:13:40. ______. Gerenciamento da qualidade do ciclo de vida . [S.l.]: Borland, 2008. Disponível em: <http://info.borland.com.br/silk/>. 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: <http://www.linhadecodigo.com.br/Artigo.asp x?id=1566>. Acesso em: 10 ago. 2008, 12:12:24. ______. Introdução à automação de testes funcionais . [S.l.]: TestExpert, 2007. Disponível em: <http://www.testexpert.com.br/?q=node/178>. Acesso em: 10 ago. 2008, 12:02:26. CALLERI, Mário. Qualidade de software no desenvolvimento de sistema s 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: <http://isg.inesc-id.pt/alb/static/papers/2004/n12-sc-Quatic2004.pdf>. 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: <http://www.testexpert.com.br/?q=node/990>. Acesso em: 14 set. 2008, 21:52:12.
75
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: <http://www.sbc.org.br/bibliotecadigital/download.php?paper=2 55>. 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: <http://www-142.ibm.com/software/dre/ecatalog/list.wss?locale=pt_BR&subcatego ry=J107030V33347X46>. Acesso em: 31 ago. 2008, 11:56:30. MENDES, Alvaro. Novo ASC [mensagem pessoal]. Mensagem recebida por <[email protected]> em 25 ago. 2008. MICROSOFT. Test Edition . [S.l.]: Microsoft, 2008. Disponível em: <http://msdn.mi crosoft.com/pt-br/library/ms182409.aspx>. Acesso em: 31 ago. 2008, 11:54:30. ______. Usando automação de interface do usuário para test es automatizados . [S.l.]: Microsoft, 2008. Disponível em: <http://msdn.microsoft.com /pt-br/library/aa348551.aspx>. 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: <http://josepaulopapo.blogspot.com/2005/11/ferramen tas-para-automao-de-testes.html>. Acesso em: 10 ago. 2008, 11:59:28. RSI Informática. Uso da ferramenta QA-Teste para controlar massas d e teste . Rio de Janeiro: REDEA/RJ, dez. 2005. UNGARELLI, Adriano. Teste de software como controle de qualidade . [S.l.]: Via6, 2007. Disponível em: <http://www.via6.com/topico.php?tid=90539&cid=6042>. Acesso em: 31 ago. 2008, 12:00:20. WIKIPÉDIA. Código aberto . [S.l.]: Wikipédia, 2008. Disponível em: <http://pt.wikipedia.org/wiki/Open_source>. Acesso em: 17 ago. 2008, 13:56:44.
76
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).
77
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.
78
ANEXO A – ESTRATÉGIAS DE TESTE
CAIXA-BRANCA CAIXA-PRETA
Figura 7 – Estratégias de testes caixa-branca e caixa-preta
79
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
• 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
80
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 Técnicas de testes de condição o Teste baseado em probabilidade de
erro � Teste de ramos
o Teste de comparação � Teste de domínio
� 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
81
ANEXO D – PROCESSO DE TESTES
Figura 8 – Visão do modelo de processo de qualidade de software em “U”. Fonte: Bartié (2002, p.36)
82
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)
83
ANEXO F – FUNCIONAMENTO DA FERRAMENTA DE TESTE
Dados de teste
Resultadosesperados
Scripts
Ferramenta
Scripts
Programa emTeste
Inte
rfac
e G
ráfic
a
Relatórios
Dados
Resultados
Figura 9 – Funcionamento de uma ferramenta de testes Fonte: Argollo (2008)
84
ANEXO G – DISTRIBUIÇÃO DO ESFORÇO - PROJETOS NOVOS
Tabela 9 – Custo/esforço em projetos novos
Fonte: REDEA/RJ
85
ANEXO H – DISTRIBUIÇÃO DO ESFORÇO - MANUTENÇÃO
Tabela 10 – Custo/esforço na manutenção de sistemas
Fonte: REDEA/RJ
86
ANEXO I – DISTRIBUIÇÃO DO ESFORÇO - AMBIENTE
Tabela 11 – Custo/esforço na montagem em ambiente d e homologação
Fonte: REDEA/RJ
87
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 (3x). Este tipo de técnica reflete mais facilmente os
pesos de itens que serão avaliados.
Tabela 12 – Exemplo de requerimento num quadro comp arativo 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)
88
ANEXO K – TIPOS DE FERRAMENTAS SEGUNDO MOLINARI
Quadro 13 - Visão Comercial Test Design 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 & Test Managers
Ferramentas de automação de execução dos testes com uma interface gráfica. Podem trabalhar com grandes suites de testes.
Test Implementation Ferramentas que ajudam na implementação dos testes. Um exemplo 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)
Quadro 15 – Novas Tendências Ferramenta de testes funcional e regressão (caixa-preta)
Captura os comandos executados por usuários e os executam.
Ferramenta de teste de performance e carga
Testar performance e carga de um sistema torna-se cada vez necessário.
Ferramenta de planejamento de testes
Planejar testes torna-se cada vez mais necessário.
Ferramenta de testes de monitoração
Testes em tempo real da aplicação em produção, verificando sua disponibilidade. O seu SLA se tornou necessário.
Ferramentas de testes estrutural (caixa-branca)
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.
Fonte: Molinari (2003, p.108)
89
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)
90
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 Gerenciamento de qualidade por meio do alinhamento entre requisitos e objetivos de negócios
Fonte: Borland (2008)
Quadro 17 - Ferramentas da IBM para a automação de testes de software
Rational Functional Tester Testes funcionais automatizados avançados de aplicativos Java, da Web e VS.NET baseados em WinForm.
Rational Functional Tester Extension for Terminal-based Applications
Estende o Rational Functional Tester para suportar o teste de aplicativos baseados em terminal.
Rational Manual Tester Aprimora os esforços de autoria e execução de testes manuais utilizando novas técnicas de design de testes.
Rational Purify for Linux and UNIX
Fornece detecção de fuga de memória e de corrupção de memória para Linux e UNIX.
Rational Purify for Windows
Fornece detecção de fuga de memória e de corrupção de memória para Windows.
Rational PurifyPlus Enterprise Edition
Fornece análise de tempo de execução para Windows, Linux e UNIX.
Rational PurifyPlus for Linux and UNIX
Conjunto de ferramentas de análise de tempo de execução para desenvolvimento em Java e C/C++ baseado em Linux e UNIX.
Rational PurifyPlus for Windows
Análise do tempo de execução para desenvolvimento em Java, C/C++, Visual Basic e .NET gerenciado baseado em Windows.
Rational Robot Rational Robot
Ferramenta de automatização de testes de uso geral para aplicativos cliente/servidor.
Rational Test RealTime Permite o teste de componentes e a análise em tempo de execução para software integrado e de tempo real de plataformas cruzadas.
Fonte: IBM (2008)
91
ANEXO N – SOLUÇÕES COMERCIAIS
Quadro 18 – Ferramentas comerciais
Ferramenta Informações
WinRunner 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 Para as linguagens AdaTEST, Cantata, Cantata++, geração automática dos casos de teste baseadas em código fonte, IPL (http://www.iplbath.com/)
LDRA Ltd Geração automática dos casos de teste baseadas em código fonte, LDRA Testbed (http://www.ldra.com/)
Testwell 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)
ADL Translation System
Geração automática dos casos de teste baseadas em especificação formal
92
ANEXO O – SOLUÇÕES COMERCIAIS
Quadro 19 – Características apresentadas pelas ferr amentas de teste OO
Ferramentas de teste de software
Tes
te d
e un
idad
e
Tes
te d
e in
tegr
ação
Tes
te d
e si
stem
a
Crit
ério
s fu
ncio
nais
Crit
ério
s de
flux
o de
con
trol
e
Crit
ério
s de
flux
o de
dad
os
Crit
ério
s ba
sead
os e
m m
utaç
ão
Ling
uage
m s
upor
tada
Exi
gênc
ias
de c
ódig
o-fo
nte
Ativ
idad
e de
dep
uraç
ão
Tes
te d
e re
gres
são
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 � � JavaCobertura � � JavaJaBUTi � � � � Java �CTB � � � Java/C/C++Parasoft JTest � � � � Java � �Glass JAR Toolkit � � � � JavaObject Mutation Engine � � Java �Ferramenta de Chevalley � � Java �Ferramenta de Ma et al � � Java �Mutation Testing System � � Java � Fonte: Delamaro et al (2007, p.174)
93
ANEXO P – FERRAMENTAS DE TESTE GRATUITAS
Quadro 20 - Melhores ferramentas Open Source para g estão e automação
Categoria Ferramenta
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/
Gestão de projetos
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-439e-a67d-75a89aa36495&DisplayLang=en
Webload - http://www.webload.org/
Testes de performance
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/
Gestão de testes
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/
Gestão de defeitos
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/
Gestão de requisitos
REM (REquisite Management) - http://www.lsi.us.es/descargas/descarga_programas.php?id=3
94
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
Testes funcionais
FitNesse - http://fitnesse.org/
Estimativas Construx Estimate - http://www.construx.com/Page.aspx?nid=68
TortoiseCVS http://www.tortoisecvs.org/
WinCVS - http://www.wincvs.org/
Subversion - http://subversion.tigris.org/
Controle de versões
Darcs - http://darcs.net/
Fonte: Caetano (2007)