GOTEST-Aula5-Automacao-Parte2.pdf

JUNHO 2009
JUNHO 2009
Edson Cruz
edsonclj@gmail.com
http://www.applabs.com/uploads/tool.jpg
Automação de Testes

AGENDA
AGENDA
1. Automação de Testes
 Características
 Automação de Testes funcionais
2. Ferramentas de Automação
 Características
 Como escolher a melhor ferramenta
 Comparação entre ferramentas de automação
3. Tendências e avanços em automação
 Geração de testes baseada em modelos

Automação é...
Automação é...
 Testes criados automaticamente?
 Projetar testes para serem executados por máquinas?
 Substituir testes manuais?
 Desejável?
 Impossível?

Automação é...
Automação é...
 Imprescindível?
 Codificar testes manuais?
 Uma atividade que requer ferramentas apropriadas?
 Para substituir os testadores humanos?
 Uma atividade que traz economia para o projeto?
 Um processo?

Automação é...
Automação é...
 Para especialistas?
 Demorada?
 A solução para a aumentar a qualidade dos produtos?

Automação é...
Automação é...
 Para grandes equipes de teste?
 Uma atividade que requer muito esforço e cuidado?
 Financeiramente muito cara?
 Para tornar mais confiáveis a execução de testes complexos?

• Definição
Software que automatiza qualquer aspecto do processo de verificação
e validação de um sistema de aplicações.
É possível incluir ainda nesta definição a capacidade de
gerar entradas e resultados esperados, a execução e a
avaliação das suítes de testes sem a intervenção humana.

Qualquer pessoa que tenha desenvolvido manualmente casos de
testes para um sistema moderadamente complexo, executado-
os em uma versão testável do sistema e posteriormente
produzido o relatório de problemas, deve ter percebido que
não apenas muito desse trabalho é repetitivo e enfadonho,
mas que a quantidade de trabalho envolvida nesse processo é
imensa.
Motivação

• Principais Benefícios
 Permite a rápida e eficiente verificação de conserto de problemas
(bug fixes).
 Aumentam a velocidade de rastreamento de problemas (debugging).
 Geralmente as informações produzidas por testes manuais são
fragmentadas e podem apresentar inconsistências.
 Automação bem planejada pode aumentar a produtividade.
 Suíte automática pode ser executada repetidas vezes sem distração.
 Assegura que o mesmo teste pode ser executado com exatidão várias
vezes.

“Testes automatizados executam uma seqüência de ações sem a intervenção
de humanos”
“Automação ajuda a eliminar erros humanos e promove resultados rápido.”
“Automação de testes conduz para uma economia financeira significativa.”
“Usando automação de testes uma companhia passará do ponto de empate
dos custos após apenas duas ou três rodadas de testes .”
“Pessoas com pouca experiência em programação poderão usar ferramentas
de testes e criar rapidamente um grande conjunto de testes.”
“Ferramentas de testes são fáceis de usar e a manutenção das suítes de
testes não é um problema.”
“Os gerentes de desenvolvimento podem economizar uma grande quantidade
de dinheiro e stress, lançando o software mais rapidamente quando usa
ferramentas de automação de testes.”
“Ferramentas de automação substitui aqueles testadores manuais inócuos
indesejáveis.”
Mitos mais comuns

• Verdade ou Mito?
Na área de teste de software, computadores são mais rápidos, mais baratos
e mais confiáveis que os seres humanos; portanto, automatizar é a solução.
James Bach em “Test Automation Snake Oil” quebra vários mitos
sobre automação:
1. Testes se resume a uma seqüência de ações.
Verdade:
• Teste é uma seqüência de interações intercalada com
avaliações.
• Algumas são complexas, ambíguas, e voláteis.
• O resultado poderá será um limitado e superficial conjunto de
testes se nos pensarmos em testes como seqüência de ações.

2. Testes significa repetir a mesma ações mais e mais.
Verdade:
• Se um teste específico é executado uma única vez, e nenhum
erro foi encontrado, há pouca chance que este mesmo caso de
teste venha encontrar um erro.
• Se houver variações nos casos de teste, existe uma maior
probabilidade de revelar problemas tanto novos quanto antigos.
• Variabilidade é uma das grandes vantagens da execução manual
em relação a execução de script de testes do tipo playback.

3. Todas as ações dos testes podem ser automatizadas.
Verdade:
• Algumas tarefas fáceis para as pessoas podem ser muito custosas
para computadores.
• Provavelmente a parte mais difícil de automação é interpretar
os resultados dos testes.
• É muito difícil de detectar, automaticamente, todas as
categorias de problemas significativos e ao mesmo tempo ignorar
os problemas insignificantes para softwares que possui uma
sofisticada GUI.
• Ter um grade número de incertezas e mudanças em um típico
projeto inovador é como dirigir um carro de passeio por uma
floresta sem trilha: você pode fazê-lo, mas terá que ir muito
lento, vários recuos serão necessários, além de que alguns pneus
poder acabar furando.

4. Um teste automático é mais rápido, porque não necessita de intervenção
humana.
Verdade:
• Todas suítes de testes automatizados exigem intervenção de
humanos. nem que seja apenas para diagnosticar os resultados ou
consertar bugs nos testes.
• Executar uma suíte de testes complexos sem tropeços é muito
difícil, devido as constantes alterações de código, problemas de
memória e sistema de arquivos, falhas na rede e os bugs inerentes
a própria ferramenta de automação.

5. Automação reduz erros humanos.
• Essa hipótese é correta, alguns erros relacionados a atividades
mentais repetitivas são reduzidos.
• Entretanto, outros erros podem ser amplificados.
• Os scrips de testes são escritos por humanos que cometem erros.
De forma que precisa se testar os scripts de teste da aplicação.
Verdade:

6. Podemos quantificar claramente os custos e benefícios do testes manuais
vs testes automáticos.
Verdade:
• Testes manuais e testes automatizados são realmente dois
diferentes processos, em vez de duas formas diferentes para
executar o mesmo processo.
• Os bugs que tendem a revelar são diferentes.
• Uma comparação direta dos mesmos, em termos de custo
monetário ou número de bugs não faz qualquer sentido.

7. Normalmente numa empresa, o ponto de empate (break-even point) em
relação ao capital investido na automação vai acontecer depois de apenas
dois ou três ciclos de execução de uma suíte de teste automatizado.
Verdade:
• O custo envolvido na automação de testes é composto de várias
partes:
 O custo do desenvolvimento da automação.
 Os custos de funcionamento do testes automatizados.
 O custo de manutenção da automação como o produto mudanças.
 O custo de quaisquer outras novas tarefas exigiram.
• A evolução destes custos vai depender de vários fatores, incluindo a
tecnologia a ser testada, as ferramentas de teste utilizadas, a
habilidade do desenvolvedores dos testes e a qualidade da suíte de
testes.

• Quando automatizar e quando não automatizar
Uso de Testes Automáticos
• Quando há uma grande quantidade de testes a serem executados
repetidas vezes. Repetitividade é o primeiro aspecto, embora não
seja a único, que justifique o custo da automação.
• Nos testes de carga ou performance, é bom ter a ajuda de um
computador para simular as condições de stress onde o sistema
deverá ser usado.
• Hoje em dia é muito comum as aplicações necessitarem suportar
várias GUIs, redes, sistemas operacionais ou banco de dados
diferentes. Ou seja, mesmo teste rodado várias vezes.
Sem dúvida automação de testes pode trazer vários benefícios ao processo de
testes, No entanto, é preciso conhecer as situações onde se indica o uso de
testes automáticos e onde os testes manuais são de mais valia.

Uso de Testes Automáticos –
• Quando é necessário repetir uma longa e complexa lista de ações
com exatidão é preferível usar automação. Algumas seqüência de
testes podem envolver centenas e até milhares de invocações ao
sistemas. Estes tipo de testes torna o setup e a execução manual
impraticável.
• Comparação automática é a única maneira eficiente de avaliar uma
grande quantidade de saída repetidamente. Pois, até os mais
dedicados testadores se cansarão depois de algumas vezes
rastreando saídas muito longas, traces ou dumps.

Uso de Testes Manuais –
• Quando não se tem muito tempo - um testador experiente pode
se valer de seu conhecimento das características do produto e
improvisar alguns testes de forma muito eficiente.
• Testadores experientes podem desenvolver um “sentimento” do
comportamento da aplicação que está sendo testada e sugerir novos
cenários a partir respostas do próprio sistema.
• Em situações que se necessita de criatividade, reconhecimento e
avaliação de padrões, os seres humanos conseguem superar os
computadores. Nestes casos testadores manuais produzem facilmente
generalizações e avaliações adaptativas que seria muito difícil realizar
com o computador. Imagine a complexidade de um teste automático
para decidir se uma imagem ou um som está sendo tocado
corretamente por um dispositivo multimídia.

Uso de Testes Manuais –
• Tipicamente, automação de testes é mais caro que apenas
executar a aplicação. Se há a evidência que não existe a
necessidade de muitas rodadas de testes, talvez o custo do
desenvolvimento dos testes automático não se justifique.
• Componentes novos é o foco característico para a realização dos
testes manuais. Um código instável pode sofrer várias alterações,
demandando muito trabalho para atualizações dos casos de testes.
Nestes casos, é mais indicado o uso de testes manuais escritos de
maneira genérica (high-level), deixando para o testador discernir o
comportamento mais corretos dos detalhes da aplicação.
• O custo de manutenção dos scripts automáticos de testes pode ser
alto quando os requisitos do sistema em teste mudar com muita
freqüência. Caso os testes automáticos não tiverem uma
manutenção adequada, eles não poderão ser usados e o esperado
retorno pode não acontecer.

A combinação das duas técnicas: testes automatizados e testes
manuais, é uma prática eficiente e comum. Não há uma
abordagem simples, melhor ou pior. Existem situações que
favorecem testes manuais e outras a completa automação dos
testes.

• Exercícios –
1 – Avalie os projetos abaixo quando devemos usar testes manuais ou
automáticos e justifique com argumentos consistentes
A) Projeto de um produto que deverá sofrer manutenções periódicas.
Possui um nível de documentação de requsitos consistente.
B) Projeto de curta duração com algumas áreas críticas, com equipe
experiente, que usa metodologia ágil XP.
C) Projeto de longa duração com releases quinzenais, equipe
experiente, porém com poucos recursos financeiros.

• Exercícios –
D) Projeto de um produto baseado em Web que precisa atender a
centenas de requisições simultâneas. Possui um nível de
documentação de requisitos consistente. Cronograma apertado,
porém com possibilidade de ter recursos extras.
E) Projeto com linha de produto, sendo necessário testar as várias
possíveis combinações de código.

Automação de Testes Funcionais
• Testes Funcionais – sob a perspectiva do usuário
 Enquanto os testes unitários dizem ao desenvolvedor que o código
deve fazer as coisas direito, os testes funcionais dizer que o código
deve fazer as coisas certas.
 Estes testes confirmam que o sistema deve fazer o que os usuários
estão à espera dele.
 A construção de uma casa pode ser usada como métáfora para
explicar o desenvolvimento de um sistema computacional
 Teste de unidade se assemelha a um inspetor de obras visitando
uma casa em construção. Ele está focado nos diversos sistemas
internos da casa, a fundação, o sistema hidráulico, rede elétrica,
canalização, etc.
 Ele assegura (por meio de verificação), que as partes da casa irá
funcionar corretamente e com segurança, ou seja, corresponde ao
requisitos do projeto da construção.

 Testes funcionais neste cenário são análogos a visitação do
dono da casa a esta mesma construção.
 Ele assume que os sistemas internos irão comportar-se
adequadamente, já que o inspetor de construção realizou bem sua
tarefa.
 Ele, como o dono da casa, entretanto, está focado em como ela
deverá estar quando ele começar a viver lá. Se os vários cômodos
possuem dimensões confortáveis, se as necessidades de sua família
serão satisfeitas a contento, ou ainda se as janelas possui uma boa
quantidade de sol pela manhã, etc..
 Fazendo a relação com os testes, pode-se imaginar que o dono está
realizando os testes funcionais na casa, já que a enxerga na
perspectiva do usuário.

 Como os testes de unidade, projetar uma suíte manutenível de
testes funcionais automatizado sem o uso de um framework de
testes é praticamente impossível.
 JUnit é muito bom para teste de unidade; no entanto, ao tentar
escrever testes funcionais, o código produzido pode se tornar
bastante confuso e embaraçado.
 Testes funcionais pode ser encarado como a parte mais importante
do desenvolvimento.

• Como escrever testes funcionais automáticos
eficientemente
 Os testes funcionais sempre tiveram sua importância reconhecida.
Geralmente, há um exército de pessoas em constante interação
com o sistema para determinar se este se comporta corretamente.
 Entretanto essa abordagem ou grupo de configuração está
equivocada segundo Jeff Canna.
 Deve-se descrever os testes assim que haja a possibilidade de
produzir algum código com qual o usuário possa interagir, ou até
antes.
 É indicado o uso de um usuário para descrever testes funcionais a
fim de capturar os requisitos do ponto de vista dele.

eficientemente
 Sempre que se iniciar uma nova tarefa, é importante descrever a
tarefa no framework de testes funcionais.
 Seu esforço de desenvolvimento então deve continuar no sentido da
verificação dos testes de unidade quando se adiciona um novo
código.
 Quando todos os testes de unidade estiver passando, execute o
teste funcional correspondente para verificar se ele está passando
ou se precisa de algum ajuste.
 Idealmente, o conceito de um grupo de testes funcionais deverá
desaparecer. Desenvolvedores deve projetar os testes funcionais
com ajuda dos usuários.

eficientemente
 Depois que existir uma suíte de testes funcionais para o sistema, os
membros da equipe responsável pelo desenvolvimento dos testes
funcionais devem bombardear o sistema com as variações dos
testes iniciais.
 Muitas vezes não fica claro onde traçar a linha de distinção entre os
testes de unidade e os testes funcionais.

eficientemente
 existem algumas orientações para decidir se o determinado teste de
unidade que está sendo escrito é na verdade um teste funcional:
1. Se o de teste de unidade atravessa classe de fronteiras, ele
pode ser um teste funcional.
2. Se o de teste de unidade ficar muito complexo, ele pode ser um
teste funcional.
3. Se o de teste de unidade é frágil (ou seja, é um teste válido,
mas é necessário atualizá-lo continuamente para lidar com
diferentes mudanças do usuário), ele pode ser um teste
funcional.
4. Se o de teste de unidade é mais difícil de escrever do que o
código que deverá ser testado, ele pode ser um teste funcional.

eficientemente
 Existe uma sintonia entre o teste unitários e os testes funcionais, e
decidir onde está a linha de separação entre um e outro depende
de caso a caso.
 Quanto mais confortável se estiver com os testes unitários, mais
claro será perceber quando um determinado teste está cruzando a
linha de unidade para funcional.

• Gerenciamento de Automação de testes
 Uma suíte de testes automatizados é, em essência, um sistema
computacional e possui os mesmos problemas que o sistema que se
pretende testar
 Quando se está testando qualquer sistema com scripts de testes
automáticos, em verdade se precisa lidar com dois sistemas os
quais precisam de manutenção
 Em alguns casos os problemas com a manutenção dos testes chegam
a ser maior que a manutenção do próprio sistemas sob teste
 Com linhas de produtos, ainda existe o problema de ter que portar
os testes para os diferentes tipos de produto existentes

 A manutenção das suítes de testes automáticos pode se transformar
em uma atividade de tempo integral.
 Isto é particularmente verdade quando um simples módulo de
interface pode ter centenas de scripts de teste.
 A manutenção começa muito cedo no processo de automação de
testes. É sempre desejável começar a pensar no projeto e na
implementação dos scripts de testes assim que se tenha algum
informação que já se possa automatizar.
 Por outro lado, o problema que isso acarreta é que scripts de testes
assim como os casos de testes devem ser revisados sempre que os
desenvolvedores alterarem o software.

 Se houver pouco ou nenhum controle sobre como os
desenvolvedores inserem mudanças nas fases de análise e projeto
dos processos, a atividade de automação de scripts pode tornar-se
inviável.
 Uma solução para isso é começar o projeto e não a construção o
mais cedo possível.
 Dessa forma, pode-se reduzir pela metade a sobre-carga de
manutenção, pois apenas o projeto necessita ser atualizado, já que
os scripts ainda não forma codificados.
 Claro que em algum ponto, quando a data dos testes reais se
aproxima será necessária a construção dos scripts. Entretanto é
bom ter em mente que quanto mais postergar a implementação,
menos manutenção nos pré testes será necessária.

 Esta abordagem pode causar um outro problema, o qual acontece
freqüentemente, já que os desenvolvedores costumam entregar os
módulos funcionais do software apenas pouco tempo antes de
começar a execução propriamente dita.
 Como é possível, assim, construir scripts automáticos de testes sem
um protótipo executável do software?
 Tendo os casos de teste projetados e atualizados o quanto for
possível, é mais fácil construir a implementação dos scripts a
tempo.

Ferramentas de apoio a testes
• Motivação
 Testes é uma parte do processo de software que demanda muito
trabalho e possui um custo financeiro elevado. Por isso, ferramentas de
testes estão entre as primeiras desenvolvidas, desde os primórdios do
desenvolvimento de software.
 Uma boa dose de prudência é necessária, pois os benefícios e o
sucesso de uma automação pode depender sobremaneira da escolha
correta de uma ferramenta para casa tipo de situação.
 Uma ferramenta eficiente dentro de um certo contexto ou
finalidade pode não se aplicar a necessidades específicas. A seleção de
uma ferramenta inadequada pode acarretar investimentos
desnecessários de treinamentos, tempo e dinheiro.
 Há um variado leque de facilidades e seu uso pode reduzir
significantemente o custo do processo de teste.

• Potenciais Benefícios
 Redução do tempo gasto em trabalhos repetitivos .
 Avaliação objetivas dos resultados esperados.
 Fácil acesso e sem esforço as informações relativas aos testes e ao
processo de verificação.
 Aumenta a consistência nos trabalhos enfadonhos ou muito
difíceis para humanos;

• Como Selecionar
Muitas das ferramentas poderia se descartadas sem mesmo nunca
chegar a ser realmente avaliada em execução, apenas examinando
criticamente o manual usuários ou assistindo a uma apresentação
Comercial.
1. Habilidade
Será que a ferramenta tem todas as características essenciais
que se necessita, sobretudo na área de validação dos
resultados dos teste e teste gestão da suíte de testes?
James Bach sugerem alguns fatores a considerar ao selecionar um
teste ferramenta:
2. Robustez
Será que a ferramentatrabalhar durante longos períodos sem
falha, ou é cheio de bugs? Muitos são ferramentas de teste
desenvolvido por pequenas empresas que fazem um mau
trabalho de validação?

• Como Selecionar
3. Capacidade
Além de exemplos triviais e demonstrações, a ferramenta
funcionar sem falha em um ambiente industrial? Ele pode
manipular grande escala teste suítes, que funcionam durante
horas ou dias e envolverá milhares de scripts?
4. Aprendizagem
A ferramenta pode ser dominada em um curto espaço de
tempo? Existem treinamentos ou livros disponíveis para
ajudar nesse processo?
5. Operabilidade
Os recursos da ferramenta são difíceis de usar, ou têm a
tendência de levar o usuário ao erro?

• Como Selecionar
6. Performance
A ferramenta é rápida o suficiente para permitir umaeconomia
substancial no tempo de desenvolvimento e execução teste versus
testes manuais.
7. Compatibilidade
A ferramenta funciona apropriadamente com a tecnologia
particular que precisamos testar?

• Tipos de Ferramentas
• Ferramentas de apoio a execução de testes
esse é o grupo que sem dúvidas possui o maior número de
ferramentas. São essas ferramentas que vão atuar na real
execução dos testes cases, além de poder diminuir a sobrecarga
da criação de testes automáticos:
 Simuladores para usuários finais
Desde de automação de interface gráfica (GUI) até carga
e stress de grandes sistemas, estas ferramentas fornecem uma
maneira de automatizar grande parte do trabalho de entrada de
dados dos sistemas de uma forma muito próxima da situação real
de uso das aplicações.
Estas simulações de cliques e digitações solicita transações
reais, as quais realizam chamadas à aplicações reais que por
sua vez acessam dados reais. Simulando milhares desses
usuários, a ferramenta pode encher as pilhas do sistema alvo
com dados significativos.

• Tipos de Ferramentas
• Ferramentas de apoio a automação de testes
 Frameworks
algumas das mais eficientes ferramentas não fazem nada. Claro
que esta é uma caracterização injusta, mas ilustra muito bem a
natureza dos frameworks.
Eles provêem serviços, encapsulamento ou funções que podem
invocar os casos ou scripts de testes.
Eles eliminam muito do trabalho enfadonho da automação de
testes para que os testadores possam se concentrar na criação
apenas do código necessário para exercitar os item a que se
deseja testar.
Framework fornece a fundação para a criação dos testes
automáticos, oferecendo serviços que reduzem a
complexidade da implantação de certos ambientes.

• Comparação entre Ferramentas
Com o objetivo se fazer um comparativo entre ferramentas que dão
suporte a confecção de testes funcionais automáticos veremos algumas
das principais marcas de ferramentas de automação presentes no
mercado:
 Compuware QARun [16],
 HP Mercury QuickTest Professional [17],
 Rational Functional Tester [19] e
 Borland Segue SilkTest [18].
Os critérios a partir dos quais a ferramenta foi avaliada foram: Record &
Playback, Web Testing, Mapeamento de Objetos, Extensibilidade,
Suporte a Ambiente, Integração.

• Comparação entre Ferramentas - Critérios
Record e Playback:
Este critério trata de quão fácil é gravar e reproduzir um teste. Será que
a ferramenta da suporte a gravação de baixo nível (arrasta do mouse,
localização exata tela)? Existe reconhecimento objeto ao gravar e
reproduzir? O quão fácil é a leitura dos script gravado.
Eventualmente gravar e reproduzir torna-se cada vez menos parte do
processo de automatização, pois para um processo mais robusto,
geralmente usa-se as funções built-in diretamente para testar objetos,
bases de dados etc.

Testes Web:
Na maioria das aplicações, funcionalidade baseada em Web, são parte do
nosso cotidiano. Como tal, ferramenta de teste deve fornecer boa
funcionalidade para os teste baseado em Web, além de funções cliente-
servidor. Alguns dos questionamentos que deve se ter em mente são:
 Existem funções que avise-nos quando a página tiver terminado
de carregar?
 Será que podemos dizer a ferramenta teste para esperar até que
uma imagem seja carregada?
 Será que podemos testar se os links são válidos ou não?
 Podemos extrair dados como o título da página, um elemento
escondido, etc., a partir da própria página web?

Mapeamento de objeto :
Um grande número de aplicações personalizadas usa objetos. A maioria
dos objetos personalizados comporta como um padrão de controle
semelhante como: botões, checkboxes, radio buttons, etc.
Para aplicações que utilizam objetos personalizados, precisamos ter a
certeza se somos capazes de mapeá-los (dizer a ferramenta de teste que
o controle personalizado comporta-se como um padrão ).
Será que suportam todos os métodos padrões de controle? Será que
podemos adicionar controle personalizados a nossa própria classe de
controle?

Extensibilidade:
Este critério está relacionado com a possibilidade de extensão da
ferramenta.
Se a ferramenta não suportar determinada funcionalidade e é possível
criar uma?
Este geralmente é um assunto avançado e requer um bom conhecimento
em linguagem de programação.
Algumas ferramentas provêem extensões permitindo criar funções
métodos e classes, porém apenas utilizando tipos e funções já pré-
definidas pela ferramenta ao invés de permitir a extensão da ferramenta
além das suas funcionalidades.

Suporte a Ambiente :
A ferramenta suporta a última versão de Java, Oracle, WAP, etc.?
Muitas ferramentas permitem criar classes, DLL`s, etc. para se
comunicar com ambientes não suportados.
Esta é uma importante parte da automação, se a ferramenta não suporta
o ambiente da aplicação sob teste isto pode ser um grande problema, e
provavelmente será melhor utilizar testes manuais.

Integração:
A funcionalidade de integração é uma característica muito importante. A
maioria das organizações têm grande variedade de ferramentas de vários
fornecedores em seus softwares organizacionais.
É essencial para uma ferramenta de testes a integração adequada com
outras ferramentas. Este critério verifica o quão bem a ferramenta
consegue fazer a integração com outras ferramentas. Será possível
executar a ferramenta a partir das ferramentas de gerenciamento de
suítes de testes?
É possível registrar um bug diretamente na ferramenta e alimentá-lo
com informações recolhidas a partir dos arquivos de log de teste? Será
que ela se integra com produtos como editores de texto, ou planilhas ou
Gestão de requisitos?

• Comparação entre Ferramentas - Resultados
A matriz produzida é apresentada abaixo:
Ferramenta
Record &
Playback
Teste
Web
Mapeamento
de obj.
Extensib
ilidade
Suporte a
ambiente Integração
Total de
pontos
Mercury
QuickTest 2 1 1 2 1 1 8
Compuware QA
Run 1 2 1 2 2 1 9
Borland Silk Test 1 2 1 1 2 3 10
Rational
Integration
Tester 3 2 2 2 2 2 13

Exemplos de outras
Ferramentas

FIT/FITNESSE
FIT/FITNESSE
• Framework de testes de aceitação
• É também um Wiki e um Web server
• Testes são expressos como tabelas
– Tabelas são armazenadas como páginas no Wiki
– Podem ser organizadas em suites de teste
hierarquicas

FIT/FITNESSE
FIT/FITNESSE
• Arquitetura

FIT/FITNESSE
FIT/FITNESSE
• Exemplo de possível formato de tabela
– Entradas
– Resultado esperado

SELENIUM
SELENIUM
• Plug-in do firefox utilizado para testar sistemas
Web
• Ferramenta de captura e replay

BADBOY
BADBOY
• Ferramenta de captura e replay para Web sites
• Possui recursos interessantes e é bem simples
de usar

Testes Não Funcionais
Testes Não Funcionais
• Desempenho
• Carga
• Uso de memória
• Etc.

Testes de Carga e Performance
Testes de Carga e Performance
• Verificam:
– Tempo de resposta de um sistema
– Quantidade de usuários usando o sistema ao mesmo
tempo
– Volume máximo de dados
– Etc.
• JMeter
• OpenSTA

Tendências e Avanços em
Automação de Teste

Model-based Testing
Model-based Testing
• Geração automática de
casos de teste
Geração de Casos de Teste Funcional
para Aplicações de Celulares
Emanuela Cartaxo
Dissertação de mestrado, UFCG, 2006

Especificação de Entrada
• Usualmente em notações formais, como UML

• Mais recentemente, também em linguagem
natural

Critérios de teste
Critérios de teste

Redução da Suíte de Testes gerada
Redução da Suíte de Testes gerada

Similaridade entre Testes
Similaridade entre Testes

Priorização de Testes
Priorização de Testes

GOTEST-Aula5-Automacao-Parte2.pdf

Mais conteúdo relacionado

Semelhante a GOTEST-Aula5-Automacao-Parte2.pdf

Mais de RodolphoCesar2

GOTEST-Aula5-Automacao-Parte2.pdf