Para as pessoas da área de
testes que usam o QTP (QuickTest
Professional) como ferramenta para a criação de testes automatizados,
certamente esta é uma questão recorrente, em especial quando se está iniciando
um novo projeto ou um suite de
regressão para uma aplicação existente.
Afinal, o que é melhor?
Utilizar um repositório de objetos global, onde todos os scripts vão compartilhar os mesmos objetos ou deixar um repositório
sendo utilizado localmente, para cada script
criado?
O uso de um repositório
local pode parecer mais fácil, especialmente se você estiver desenvolvendo seu script através da função Record/Playback. Você clica no botão de
gravar, segue os passos definidos na aplicação e, ao final, todos os objetos
com os quais você interagiu estarão gravados no repositório daquele script. Grosso modo, bastaria clicar no play para que o QTP executasse
automaticamente as mesmas ações gravadas previamente. Sua única preocupação
seria ajeitar o código VBScript
gerado, parametrizar algumas entradas e pronto: utilizar o script sempre que precisar.
Conheço muita gente que
utiliza a ferramenta dessa forma. Mas, a meu ver, há dois problemas com esse
tipo de abordagem que podem aparecer individualmente ou simultaneamente,
dependendo de como estiver o seu projeto:
1 - Manutenção: a menos que exista apenas um script
interagindo naquela aplicação, haverá um grande trabalho com a manutenção dos
objetos. E é bem fácil entender por que: à medida que o suite vai crescendo e dezenas de scripts passam pelas mesmas telas, qualquer mudança em um objeto em
comum ou nas suas propriedades significa cada um dessas dezenas de scripts terá de ser acessado para que
sejam feitas as mudanças necessárias nos seus repositórios de objetos locais.
Especialmente em aplicações web, é
comum os desenvolvedores alterarem características de objetos em uma página ou
formulário. Imagine que uma dropdown
utilizada em todos os seus scripts
tenha mudado alguma propriedade usada na verificação? O QTP não vai reconhecer
o novo objeto durante a execução a menos que este seja capturado de novo. E essa
alteração teria de ser feita em todos os scripts,
pois o objeto foi gravado uma vez em cada um deles. Isso certamente demandaria
algumas horas de trabalho. Utilizar programmatic
descriptions também não resolve, pois, embora essa técnica não precise de
objetos físicos gravados no repositório, ela requer que as propriedades dos
objetos que foram escolhidas para a validação não mudem. Se a página mudar,
você não precisa alterar nos repositórios, mas terá de alterar o código VBScript de cada teste. Ou seja, dá na
mesma, praticamente.
2 - Um repositório local pode jogar contra a organização do processo: com os mesmos objetos repetidos em
vários lugares, fica difícil ter uma ideia do tamanho do repositório, da
quantidade de objetos manipulados até de se estabelecer um padrão de
nomenclatura ou classificação, por exemplo. Isso fica ainda mais difícil quando
há várias pessoas envolvidas na criação dos scripts,
pois elas podem seguir padrões distintos. E mesmo que um sistema de
nomenclatura ou classificação exista e seja seguido por todos, ainda assim não
se terá a visualização nem as características globais de todos os objetos.
Também pode acontecer de as pessoas terem capturado objetos diferentes entre os
scripts para uma mesma página da
aplicação, pois cada uma delas interagiu com aquela tela de forma diferente.
Particularmente, considero
que a abordagem de se ter um repositório global, compartilhado por todos os scripts, seja mais adequada. Ela tem
algumas limitações, mas me parece melhor do que manter um repositório para cada
script, desde que bem feita. Algumas
coisas que eu pude notar com o tempo e que podem ajudar bastante:
Defina alguns padrões mínimos antes de tudo: É muito importante, antes de começar
qualquer script ou capturar os
objetos, estabelecer os padrões a serem utilizados. Há muitas formas de criar
padrões e muitas opções de critérios. Eu diria que, no mínimo, deva-se
considerar:
· Local
de armazenamento: A partir da versão 10, o Quality Center introduziu uma aba
chamada “Test Resources”, onde podem
ser criados e armazenados, por exemplo, bibliotecas de funções, recovery scenarios e repositórios de
objetos. Você pode estabelecer uma estrutura de pastas internas e armazenas
esses dados ali, diretamente no servidor. O QTP pode ser integrado ao Quality Center
e aproveitar a mesma estrutura;
· Padrões
de nomenclatura dos objetos: os objetos ficam ordenados no repositório primeiramente
por tipo. Portanto, todos os objetos de mesmo tipo ficarão agrupados um abaixo
do outro ao se visualizar o repositório. Nem sempre os desenvolvedores se
preocupam com algum sistema para nomear ou classificar os objetos ou então não
há no projeto algo que considere isso. Vê-se de tudo nesses ambientes! Então,
ter um padrão de nomenclatura facilita a identificação e utilização. Renomeie os
objetos capturados para um padrão estabelecido, de preferência por tipo. Você
pode até aproveitar o nome original, mas ponha um prefixo que identifique o seu
tipo, ao menos. Por exemplo, use “img“ para imagens, “dpw” para dropdowns, “edt” para editboxes, etc. No caso de sistemas web,
não se esqueça de estabelecer um padrão para nomear cada página armazenada
também, pois elas serão como diretórios que conterão os demais objetos.
Capture todos os objetos antes de iniciar a criação dos scripts: Essa é uma parte importante do processo que vai
gastar um tempo considerável no começo, mas que certamente irá economizar muito
mais tempo lá na frente. Definidos local de armazenamento e padrões de
nomenclatura, acesse a aplicação e utilize o QTP para capturar e renomear todos
os objetos possíveis, não apenas aqueles que você acredita que irá precisar. Só
depois que o repositório estiver com todos os objetos capturados, associe o script a ele. Assim, ao gravar os passos
pelo QTP, a ferramenta já vai identificar e reconhecer os objetos do
repositório (sem ficar adicionando-os como se fossem novos) e irá colocá-los no
código VBScript automaticamente e da
forma como você os definiu. Isso é muito útil especialmente em aplicações web, que possuem diversas páginas e as usam
para separar os objetos. Uma vez feito isso, você só precisará adicionar novos
objetos quando e se a aplicação mudar, o que é uma manutenção razoavelmente
pequena.
Mantenha os objetos do tipo checkpoint
localmente. Diferentemente dos demais tipos de
objetos, os checkpoints só dizem
respeito ao script que estão
validando e, portanto, não faz sentido enviá-los para o repositório global. E,
no caso de ser usado o controle de versão (QTP 10 ou superior), você não
precisa ficar fazendo check-out/check-in
do servidor cada vez que precisar atualizá-los. Basta abrir o objeto e alterar
manualmente ou rodar o script em update mode, para que os novos valores
sejam atualizados. Resumindo: ao final, haverá um repositório com todos os
objetos interativos vindos do servidor (repositório global) e apenas os checkpoints do script corrente como objetos locais.
Como nem tudo é perfeito, e
sempre algo pode sair diferente do que se espera, há algumas observações que
considero importantes serem feitas para o bom funcionamento dessas dicas:
1 – Até a versão 9.2,
quando ainda era uma ferramenta da Mercury,
o QTP não mostrava os objetos tipo checkpoint
no repositório. Você só conseguia editá-los se fosse direto ao código, clicasse
com o botão direito em cima do nome do checkpoint
e selecionasse a opção “checkpoint
properties”. Se por acaso o seu checkpoint
estivesse escrito em forma de variável parametrizada (utilizando-se a
referência da data table em vez do
nome), você simplesmente não teria como acessá-lo. A partir da versão 9.5 (já
como produto da Hewlett-Packard), os checkpoints passaram a ser tratados como
qualquer outro objeto, estando disponíveis no repositório, visualmente. Dessa
forma, ficou muito mais fácil editá-los ou renomeá-los, bastando um click em cima deles para isso. Portanto,
a utilização de alguns padrões mencionados antes pode depender muito da versão
do QTP que você está utilizando.
2 – Uma coisa que notei é
que a migração de versões pode causar certa incompatibilidade ao converter os
repositórios de objetos. Uma vez migramos da versão 9.2 direto para a versão 10
(sem passar pela 9.5). Acontece que os repositórios criados na versão 9.2 não
eram prontamente reconhecidos pela versão 10. Ao tentar gravar um script em uma página cujos objetos já
estavam no repositório, o esperado era que o código VBScript utilizasse esses objetos. Mas o QTP sempre os adicionava
localmente, como se fossem novos. Em alguns casos, o simples fato de editar o
repositório e excluir e incluir um objeto novamente já fazia o QTP reconhecer
normalmente os demais. Mas houve casos em que isso não funcionou. Daí o jeito
foi gravar o código e editar manualmente cada objeto não reconhecido. É uma
grande mão-de-obra, mas é necessário. Da versão 10 para a 11 isso não aconteceu
mais.
3 – A versão 10 apresenta
um bug no gerenciamento de alterações
nos objetos locais de diferentes actions,
quando feitas diretamente pela janela do repositório. Se você possui um script com mais de uma action e abre o repositório de objetos,
notará que há uma dropdown onde é
possível escolher a action cujos
objetos devem ser mostrados. Suponha que o script
esteja aberto na Action1. Abre-se a
janela do repositório e, como padrão, a Action1,
que estava sendo utilizada, aparece com seus objetos. Se por acaso a Action2 for selecionada na dropdown, for feita qualquer mudança em
um checkpoint, por exemplo, e acionado
o botão de salvar, essa alteração não fica gravada. Só funciona se for alterada
a mesma action que estava sendo usada
na tela do script. Se você quiser
alterar alguma coisa nos objetos da Action2,
deve fechar o repositório, voltar para a tela principal do script, selecionar a Action2
e só então abrir o repositório e alterar os objetos dela. O pior é que, no meu
caso, só descobri isso depois de alterar dezenas de checkpoints. Por isso, preste atenção nesse detalhe se estiver
usando a versão 10. A partir da 11 isso não acontece mais.
Essas dicas são oriundas da
minha experiência com a ferramenta, espero que sejam úteis de alguma forma para
quem trabalha com ela e que resolva algumas dúvidas que vocês tenham. São
sugestões apenas, mas funcionaram bem no meu caso e creio que podem ser úteis
para outras pessoas. Prometo que tentarei colocar mais algumas dicas aqui no blog referente à utilização do QTP como
ferramenta de automação de testes. Fiquem ligados!
0 comentários:
Postar um comentário