Pular para o conteúdo principal

Selenium IDE

Neste material pretendo abordar de forma prática a ferramenta Selenium. Não se trata de uma introdução teórica. É um hands-on básico. Chega de enrolação e ‘mãos a obra’.

Primeiro, vamos baixar e instalar o Selenium IDE (que só funciona no Mozilla Firefox):


Uma vez baixados e instalados, vamos a eles.

Abra o Firefox e, pelo menu de ferramentas, abra o Selenium IDE:



Certifique-se que o botão de gravação (bolinha vermelha do lado direito da janela do Selenium IDE) esteja clicado.

Criei um Formulário pelo Google Docs para que pudéssemos fazer a interação com o Selenium. Segue o link:

https://spreadsheets.google.com/viewform?formkey=dFRFQm5sYkE1RTR3V25BTlI5NVNHNEE6MQ&ifq

Vamos começar os trabalhos. Em cima desse formulário, vou criar o meu script automatizado.

Ações gravadas:

  • Abri o formulário
  • Digitei “João” no campo ‘Nome’
  • Selecionei “Casado(a)” como ‘Estado Civil‘ do nosso amigo João
  • Marquei que ele ganha entre um e cinco salários mínimos
  • Selecionei como hobbies do mesmo: Esportes, Música e Política
  • Cliquei em ‘Submit’
  • Selecionei o texto de agradecimento e cliquei com o botão direito. Quando fiz isso apareceram algumas opções de comandos do Selenium. Escolhi o verifyTextPresent para assegurar que o texto pós envio apareceu.

O meu script ficou assim:



Agora vou mudar alguns valores. Vou mudar o nome para “Maria” e com o ‘Estado Civil’ igual a “Divorciado(a)”. É só clicar na respectiva linha de comando e mudar o campo value.

Fica desse jeito:



Vou rodar agora. Voltei pra página do formulário e agora é só apertar o Play: o da direita (Play the current test case).

Opa, passou!



Salve seu test case em File > Save Test Case.

Como disse, é um post introdutório para começarmos a brincadeira com o Selenium IDE.

Mais tarde, e aos poucos, vamos abordando outras ferramentas do Selenium. Daí mostrarei como trabalhar com campos parametrizados, rodar o mesmo script em diferentes browsers, integrar o Selenium com outras ferramentas de testes e utilizarmos linguagens de programação para tornarmos nossos scripts cada vez mais robustos.

Sugestões? Mande para nós!

Abraços!

Comentários

Postagens mais visitadas deste blog

Testes no RUP (Parte 2)

Em muitas organizações, os testes começam muito tarde no processo de desenvolvimento de um software. Muitas vezes, começam tão tarde que o produto é lançado com uma quantidade irrisória de testes executados. Para solucionar esse problema, muitas empresas estão começando a adotar testes como um 'mal necessário'. Como contraste a esse panorama, o RUP modifica a abordagem de testes, distribuindo a mesma no decorrer do ciclo de desenvolvimento do software, agregando valor ao invés de arcar com custos excessivos decorrentes da ausência de testes. No post anterior , justificamos a pergunta 'por que testar cedo e com frequência?' com o gráfico de custos. A seguir vocês podem ver um gráfico similar, retirado do site da IBM (detentora da metodologia RUP): Muitas pessoas ainda veem a disciplina de Testes como algo secundário, por que isso acontece? Talvez porque não esteja diretamente ligado ao desenvolvimento do software e por isso é muitas vezes deixado para o final, depois do

O + do FURPS+

Segue a continuação do assunto FURPS: Posteriormente à definição do modelo FURPS, notou-se a necessidade da inclusão de mais atributos para encorpar e aumentar a cobertura do modelo. A partir dessa extensão, o acrônimo passou a ser mais comumente chamado de FURPS+ . Quais são os atributos do “+”? O + do FURPS refere-se a especificação de restrições que definirão determinados limites que deverão ser atendidos quando construímos um sistema. O + é composto dos seguintes requisitos não-funcionais: Design constraints – restrições de design: design nesse caso refere-se ao projeto, diretrizes e não a layout. A definição da utilização um banco de dados relacional no projeto é uma restrição de design, por exemplo. Implementation constraints – restrições de implementação: relacionado a limites impostos a código e construções. Como exemplo podemos citar a linguagem de programação que será utilizada para a codificação de um sistema. Interface constraints – restrições de interface: diretamente l

FURPS

Olá! Nesse post, pretendo falar um pouco sobre o modelo FURPS para ilustrar atributos que estão envolvidos em Qualidade de Software : Vamos começar pela sigla FURPS: o que significa cada uma dessas letras? Do F temos Functionality, traduzimos como Funcionalidade: Representa basicamente os requisitos funcionais do sistema. Do U temos Usability, traduzimos como Usabilidade: Representa basicamente a interface sistema-usuário. Do R temos Reliability, traduzimos como Confiabilidade: Representa basicamente a eficiência e o índice de falhas do sistema. Do P temos Performance, traduzimos como Desempenho: Representa basicamente tempos de resposta e capacidade de processamento do sistema. Do S temos Supportability, traduzimos como Suportabilidade: Representa basicamente esforços necessários para manutenção e configuração do sistema. As definições acima representam o básico de cada uma das letras que compõem a sigla FURPS. A seguir entraremos em detalhes sobre cada uma das categorias, não ante