Selenium Tutorial – Part II

Partindo do princípio que que a instalação dos recursos necessários correu bem, vamos começar a desenvolver os testes em Ruby usando o Selenium. Para consultar os detalhes sobre como preparar um ambiente para testar consultar o post anterior aqui.

Operações mais comuns com o selenium

Efetuar a inicialização do driver e navegação para uma página web deve ser efectuado usando o seguinte pedaço de código. A linha um têm como objectivo efetuar a inicialização do webdriver para utilização do Firefox, enquanto por outro lado a linha dois indica-nos para acedermos à página inicial do google.

  1:       driver = Selenium::WebDriver.for :firefox
  2:       driver.get "http://google.com"

Para efetuar a localização os elementos gráficos existem várias opções. Podemos identificar os mesmos por

ID – Podemos usar a localização por ID quando temos uma estrutura html em que o elemento procurado seja semelhante ao exemplo mostrado abaixo.

   1: <button id="buttonid">...</button>

Aqui usaríamos o método find_element de modo a encontrar o elemento procurado do seguinte modo

  1: element = driver.find_element(:id, "buttonid")

A partir daqui o elemento web fica guardado na variável element, para efetuarmos o tipo de operações que desejarmos. Estas operações podem ser clicks, asserts, entre outras. Do mesmo modo estão ainda disponíveis os seguintes modos de localização Classname, Tagname, Name, Link Text ou Partial Link Text, Css e Xpath. As duas últimas referências possuem uma sintaxe própria e mais detalhes sobre essa sintaxe podem ser encontrados aqui para o caso do XPath e aqui para o caso dos CSS selectors. O modo mais rápido de identificar estes valores é usando o utilitário FirePath que nos devolve estas duas expressões de forma automática.

De seguida apresentam-se alguns exemplos de como identificar e efetuar operações sobre as:

Escrever Texto em Caixas de Texto

Quando na página em questão temos um excerto de html, semelhante a que se apresenta em baixo

   1: <form>

   2: First name: <input type="text" name="firstname"><br>

   3: </form>

que tipicamente resulta em algo semelhante

First name:

o que queremos tipicamente fazer é escrever texto na caixa que nos é apresentada. Podemos fazer isto do seguinte modo.

  1: element = driver.find_element(:name, "firstname")
  2: element.set 'Joe'

 

Outra situação bastante comum é clicar em Botões, quando encontramos o seguinte elemento.

   1: <button id="mybutton">Click Me!</button>

o que resulta no seguinte

clicar no botão pode ser feito do seguinte modo

  1: element = driver.find_element(:id, "mybutton")
  2: element.click

 

Muitos mais elementos existem, mas os acima apresentados são os mais comuns. Para o próximo post contínuo a iterar pelos forms existentes.

 

Bom, até à próxima.

Selenium Tutorial – Part I

Selenium é uma framework para testes de software que permite a automação de aplicações Web. Este pode ser descarregado a partir da sua página aqui. A ideia deste post é mostrar como montar um ambiente e começar a desenhar testes sobre aplicações Web. Para começar a criar testes automatizados vamos primeiro montar um ambiente de desenvolvimento destes mesmos testes. Começamos por apresentar o conjunto de utilitários usados.

Começemos pelos Browsers, vamos precisar deles para aceder às aplicações Web. Pelo menos serão necessários o Firefox e Chrome.

Para nos ajudar a encontrar as informações das páginas sobre as quais vamos automatizar testes vamos precisar do

Firebug - Firebug é uma ferramenta de desenvolvimento web que facilita o debuging, edição e monitorização de CSS de qualquer site, HTML, DOM, XHR e JavaScript;
FirePath - FirePath é uma extensão para o Firefox que adiciona uma ferramenta de desenvolvimento para inspecionar, e gerar expressões XPath, seletores CSS assim como seletores JQuery (usando o sizzle selector engine).

Além disso vamos precisar do Ruby e de um IDE minimamente decente para trabalhar. Existem várias opções como por exemplo o Eclipse, Aptana e o IntelliJ Community Edition. Qualquer um deles serve, não existindo nenhum ponto que me pareça mais benéfico num deles, em relação aos restantes para o que se pretende fazer.

Depois de termos instalado um IDE vamos precisar do Ruby que pode ser obtido a partir daqui. Depois de instalado acedam à linha de comandos e verifiquem que o mesmo está instalado usando

ruby --version

Deverão obter uma linha com um resultado deste género

ruby 1.9.2p180 (2011-02-18) [i386-mingw32]

Caso tenham problemas com a execução desta instrução experimentam verificar que a pasta dos binários foi adicionada corretamente às variáveis de ambiente. Caso contrário adicionem o caminho ás variáveis de ambiente. Para facilitar podem usar o Rapid Environment Editor que é um interface gráfico que facilita a edição das variáveis de ambientes no Windows substituindo o interface gráfico do Windows.

Após a instalação do ruby vamos instalar as gems necessários para criação de testes com o selenium-webdriver. Para tal executar as seguintes instruções

gem install selenium

gem install selenium-webdriver

gem install test-unit

no final a sua instalação pode ser verificada utilizando o comando gem list. A partir daqui, e se tudo correu bem, basta apenas abrir o IDE e começar a escrever testes. Para deixar aqui apenas um exemplo do aspecto que teria um teste em que verifiquemos por exemplo se o blog Software@test é o primeiro hint quando se pesquisa por “softwareattest” no google. Não se preocupem muito em perceber o código, o seu objectivo e explicação será alvo de posts futuros.

   1: #!/bin/env ruby

   2: # encoding: utf-8

   3:  

   4: require 'rubygems'

   5: require 'selenium-webdriver'

   6: require "test/unit"

   7:  

   8: class Hello < Test::Unit::TestCase

   9:   def blog_first_in_google

  10:     begin

  11:       #Inicialização do driver e definição do browser a usar

  12:       driver = Selenium::WebDriver.for :firefox

  13:       driver.get "http://google.com"

  14:       

  15:       #Identificação da caixa de pesquisa do google e respectiva submissão

  16:       element = driver.find_element :name => "q"

  17:       element.send_keys "softwareattest"

  18:       #Expressão Xpath para o botão "feeling luck" (popup)

  19:       submit = driver.find_element(:xpath, ".//*[@id='gsr']/table/tbody/tr/td[2]/table/tbody/tr[11]/td/div/div/span[2]/span/input")

  20:       submit.click

  21:     

  22:       #verifiação se o resultado era o que esperavamos.

  23:       assert_equal("Software@test", driver.title)

  24:     ensure

  25:       driver.close

  26:       driver.quit

  27:     end

  28:   end

  29: end

Este teste pode ser corrido a partir da linha de comandos do seguinte modo

ruby Hello.rb

Este tutorial foi feito baseando-se no ruby, mas facilmente poderia de ser adaptado a outras linguagens como Java, C#, etc. No caso de Java podem seguir um conjunto de tutoriais bastante pormenorizados para a criação de um ambiente de trabalho. Este tutorial pode ser encontrado aqui. Para melhor compreender o selenium sugiro que deem uma vista de olha na documentação oficial que pode ser encontrada aqui. Outro bom recurso é o livro Selenium Simplified do Alan Richardson.

Bom, até à próxima.

Automação Web

Existem vários aplicativos para efectuar scipting de modo a automatizar as acções sobre um página web. Cada um deles com vários pontes fortes e com as suas falhas. Neste post vou abordar um “utilitário” que tenho usado nos últimos tempos com bastante frequência.

O watin pode ser obtido gratuitamente por enquanto a partir daqui Watin Homepage.

Efectuando o download da aplicação criamos um projecto no Visual C# Express Edition.

1. Criar projecto no Visual C# Express Edition

Para isto basta aceder ao C# Express Edition e criar um novo projecto. Um projecto do tipo “Console Application” serve perfeitamente o propósito aqui pretendido.

2. Efectuar o import da(s) bibliotecas existentes.

Extrair as dlls obtidas a partir do download do watin efectuado e adicionar as mesmas a uma sub pasta do projecto. Após esta operação importar como referência para o projecto. Esta operação pode ser efectuada acedendo ao menu de contexto das referências do projecto e adicionar uma nova referência. Para este exemplo em concreto basta adicionar a dll watin.core.dll.

3. Criar o script de automação

A partir deste momento temos o projecto pronto para arrancarmos com a codificação.

Adicionando um

   1:  using Watin.Core;

ao parte das referências da aplicação.

De seguida, e como este post funcionará apenas como um “Hello World” do watin apenas se irá aceder á página da google e pesquisar pelo blogue.

   1:  FireFox ff = new FireFox(http://www.google.com);

   2:  ff.TextField(Find.ByName(“f”)).TypeText(“http://softwareattest.blogspot.com/”)

   3:  ff.Button(Find.ByName(“q”)).Click();

A api desta aplicação pode ser consultada a partir da página da aplicação que pode ser consultada aqui.

A medida que for experimentando mais detalhes sobre esta api, vou publicando os aspectos importantes dessa experiência(s).

Bom, até à próxima.

Entre a execução manual e a automática

Automação de testes é o uso de aplicações de software, scripts e/ou outros aplicativos de modo a  controlar a execução dos testes. Estes permitem a comparação dos resultados reais com os resultados previstos. Normalmente  usa-se  a automação de testes com o objectivo de automatizar um processo manual já existente de modo a eliminar que tarefas repetitivas e aborrecidas sejam feitas por humanos. 

Testes com execuções Manuais

O Tester tem a necessidade de executar todas as etapas do teste de modo manual e informar o sistema do resultado obtido. Existem várias ferramentas para gestão de testes que incluem uma interface gráfico que permite aligeirar a tarefa de cada utilizador.

Algumas vantagens de efectuar testes manuais são:

• O teste manual é preferível para produtos com ciclos de vida curtos.
• O teste manual é preferível para os produtos que possuem interfaces gráficas que mudam constantemente.
• Requerem menos tempo e dinheiro para começar o teste manual produtivo, i.e., têm um retorno mais rápido.
• A automação não consegue substituir a intuição e o raciocínio humano.
• Com um teste automatizado não é possível mudar de rumo no meio de um teste para examinar algo que anteriormente não haviam sido considerado, ou um qualquer pormenor estranho que não faz parte do plano original.

Testes Automáticos

Existem inúmeros modos se implementar inúmeros testes automatizados. Para tal é necessário que a ferramenta de gestão de testes seja compatível com os próprios testes. Para isso, as ferramentas de gestão de testes podem propor estruturas de automação de propriedades ou APIs para interface com terceiros. De modo a que o utilizador consiga cumprir o objectivo pretendido.

Benefícios da Automação de Testes

• Fiabilidade – O teste efectua exactamente a mesma operação cada vez que é executado.
• Velocidade – Sendo o processo automático não é necessária a presença humana para a sua execução, pelo que esta pode ser desviada para outras tarefas acelerando assim o processo. Além disso ferramentas automáticas tendem a executar mais rapidamente do que humanos.
• Reutilização – O teste pode ser utilizado inúmeras vezes entre diferentes versões do software.
• Melhor Qualidade do Software – Como é possível correr mais testes com o mesmo conjunto de recurso o que irá levar a um aumento da cobertura do software e a uma consequente melhoria da qualidade do software.

Contras da Automação de Testes

Embora a automação de testes traga muitas vantagens, a mesma também possui um conjunto de desvantagens. Algumas das desvantagens são:

• È necessária bastante proficiência para se criar scripts automatizados, pois estes por norma exigem bons conhecimentos de programação assim como do domínio da aplicação.
• A correcção do script de teste é algo também bastante importante e que pode ser uma fonte de dores de cabeça. Com a automação começam a surgir problemas de termos testes falhados não porque o comportamento da aplicação está incorrecto mas porque o script foi mal codificado. Por outro lado também podemos ter situações de falsos positivos. Automatizar é na prática escrever código para ser executado que está, obviamente, sujeito a erros tal como o código desenvolvido e alvo de testes.
• Testes a interfaces gráficos podem se tornar bastante caros. Porque uma pequena mudança no interface da aplicação irá obrigar à correcção do script de teste.
• A gestão de dados de testes torna-se complexa quando se possui um modelo de dados em “constante movimento”.

Linhas de Guia para a construção de testes automatizados

Cada requisito especificado é passível de ser automatizado. Idealmente todos os testes poderiam ser automatizados. Seria muito bom ter sempre tudo automatizado, mas infelizmente a automação é processo lento e complexo e pondo, para cada caso, em cima da mesa a relação custo/benefício de automatizar um caso de teste rapidamente chegamos à conclusão que existem inúmeros testes que ficam muito mais caros se forem automatizados do que corridos manualmente. Isto porque a automação desse caso pode ser complexa ou demorada, ou porque apenas precisamos de correr o teste uma vez, ou ainda porque o interface da aplicação vai sofrer alterações na distribuição seguinte. Sendo assim deixo alguns critérios para ajudar a escolher de forma mais adequada quais os testes a automatizar.

As seguintes áreas devem ser automatizados em primeiro lugar:

• Tarefas repetitivas e redundantes que são aborrecidas e que tendem a causar erros humanos com facilidade.
• Partes mais estáveis da aplicação. Não vale a pena automatizar partes que sabemos que vão ser modificadas um pouco depois.
• Funcionalidades mais críticas. Estando estas funcionalidades automatizadas é possível correr estes testes mais vezes.

A criação de testes automatizados deve seguir, sempre que possível, o seguinte conjunto de critérios:

• Conciso – Deve ser o mais simples quanto possível e não mais simples.
• Auto-Verificação – Efectua a verificação dos seus próprios resultados de teste sem a necessidade de intervenção humana.
• Repetitivo - O teste têm de poder ser executado várias vezes.
• Robusto – Várias execuções do mesmo teste devem devolver o mesmo resultado, desde que as condições do software se mantêm as mesmas.
• Claro – Cada instrução do script deve ter um objectivo fácil de entender.
• Específico – Cada teste deve efectuar uma verificação a uma funcionalidade específica do software.
• Independente - Cada teste deve correr individualmente ou como parte de uma suite mais alargada com uma ordem de execução arbitrária.
• Sustentável - Os testes devem ser fáceis de compreender, de modificar e melhorar.
• Rastreáveis – Deve ser possível ligar cada teste aos requisito e ao código coberto.

Alguns critérios para decidir se um teste deve ou não ser automatizado:

• Quantidade de vezes que se pretende executar o teste.
• Complexidade necessário para automatizar o teste.
• Importância da função alvo de teste.

Observações:

• Se a empresa ou instituição nunca teve qualquer tipo de processo de testes até ao momento, não será recomendável partir logo para a automação. Os resultados obtidos provavelmente não iram ser os melhores o que pode levar a frustrações e a conclusões erradas de que um processo de testes não trás vantagens.

Bom, até à próxima.