Dicas de onde encontrar material sobre testes com Selenium

No post de hoje compartilho com vocês um vídeo da Selenium conference 2014. Na apresentação, Dave Haeffner, um dos profissionais mais atuantes no trabalho com Selenium e autor do livro guia Selenium GuideBook, indica diversas fontes interessantes onde podemos encontrar materiais sobre automação com Selenium para testadores iniciantes, intermediários e avançados.

Vídeo da apresentação

Slides da apresentação

Como capturar um screenshot no Selenium WebDriver

Capturar um screenshot é uma das ações frequentemente desejadas, quando automatizamos um teste com selenium.

A aplicação do screenshot, pode ser útil de diferentes maneiras, como provendo evidências de um problema encontrado ou servindo para análise e comparação do estado da interface, etc.

Abaixo, disponibilizo um exemplo, extremamente simples, utilizando o Selenium WebDriver com Java.

import java.io.File;
import java.io.IOException;
import java.util.Date;

import org.apache.commons.io.FileUtils;
import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.Test;
import org.openqa.selenium.OutputType;
import org.openqa.selenium.TakesScreenshot;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.firefox.FirefoxDriver;

public class SimpleScreenshot {
	private static WebDriver driver;

	/**
	 * Inicialização do driver do firefox
	 */
	@BeforeClass
	public static void beforeClass() {
		driver = new FirefoxDriver();

	}

	/**
	 * Navega para url do bytes don't bite
	 * Captura o Screenshot
	 */
	@Test
	public void testScreenshot() {
		driver.get("http://www.bytesdontbite.com");
		takeScreenshot("teste");
	}

	/**
	 * Método para capturar screenshot
	 * @param fileName - Nome do arquivo
	 */
	public static void takeScreenshot(String fileName){
		File scrFile = ((TakesScreenshot)driver).getScreenshotAs(OutputType.FILE);
		Date data = new Date();
	    try {
			FileUtils.copyFile(scrFile, new File("D:\\SeleniumScreenShots\\"+fileName+ data.getTime()+".jpeg"),true);
		} catch (IOException e) {
			e.printStackTrace();
		}
	}

	/**
	 * Encerra o driver
	 */
	@AfterClass
	public static void afterClass() {
		driver.quit();
	}

}

Como pudemos ver no código acima, a única coisa que precisamos fazer é implementar o método takesScreenshot, e utilizá-lo nos pontos em que julgarmos necessário. No exemplo, simplesmente iniciamos um FirefoxDriver e o nosso “teste” se resumiu a navegar para a url do bytes don’t bite e em seguida chamar a captura do screenshot.
Ainda não conhece o Selenium?
Uma das mais utilizadas ferramentas para automação de testes em aplicações web. Permite interagir com o navegador e simular as operações comumente encontradas nas páginas web.

Deseja conhecer mais sobre o Selenium?

— UPDATE —

Inscrições abertas

O curso de Automação de Testes Para Web com Selenium está disponível na modalidade de Ensino à distância. Contaremos com um material de vídeo-aulas, apostilas e exercícios, além do acompanhamento de um professor/tutor.

Valor: R$250,00 (Pode ser parcelado no cartão de crédito)

promo_banner

Onde encontrar material sobre testes de software?

No primeiro post de 2014, compartilho com vocês uma lista com alguns dos blogs/sites, perfis do twitter e canais do You Tube, que acompanho (ou tento acompanhar) para me manter atualizado sobre testes de software.

Blogs/Sites:

Software Testing Club      Ministry of testing      Jmeter.com.br

Outros:

  

     

Sentiu falta de algum? Pode adicionar nos comentários =D

Aumentando a Velocidade da Execução dos Testes com Selenium

Quando falamos de automação de testes um dos principais benefícios citados é a possibilidade de obtermos a execução de um ciclo completo de execução num espaço de tempo bem inferior aos testes manuais. No entanto, quando começamos a nos aprofundar no assunto vemos que existem diversas práticas que podem ser utilizadas na codificação dos testes para permitir uma eficiência ainda maior.

Uma das possibilidades para o aumento da velocidade de execução é a utilização dos Headless Browsers, tema que inclusive foi abordado pelo Elias Nogueira, do excelente blog Sem Bugs, em sua apresentação sobre CasperJS. Resumindo numa única frase o Headless Browser é um navegador sem a interface gráfica.

Estudando sobre o assunto vi que já existe uma implementação do WebDriver para Selenium, que utiliza o PhantomJS e de maneira bem simples permite que possamos nos beneficiar da utilização de um headless browser. O projeto chamado Ghost Driver funciona perfeitamente e sua integração ao seu projeto é extremamente fácil utilizando o Maven.

Para adicioná-lo ao seu projeto basta seguir as orientações do projeto no github e se ainda tiver dúvidas basta seguir as orientações do post no blog Assert Selenium do Manoj Kumar. Além disso, a excelente apresentação abaixo, realizada pelo Ivan de Marino, um dos responsáveis pelo projeto, resume bem os benefícios da utilização e as orientações básicas.

 

Fiz um teste rápido num dos meus projetos e o ganho de velocidade foi significativo, como exemplificado pela imagem abaixo:

Comparação

Ainda não conhece o Selenium? Em outubro estarei ministrando um curso presencial no CESAR.EDU, onde abordaremos os conceitos básicos para utilização do Selenium WebDriver apoiado por diversas práticas em sala, segue o link para mais informações:

banner_curso2

Como reduzir o tempo gasto em testes?

Teste é sempre um gargalo! Não dá pra estimar quanto tempo é gasto em testes (e certificação),  mas algumas fontes mostram que cerca de 50% do esforço para desenvolver um produto é gasto em testes. Com esse dado, e o senso comum de quem trabalha com desenvolvimento de software, teste de software se torna um excelente alvo para ser estudado com o objetivo de se reduzir o tempo gasto.

Obviamente, muitos estudos já foram feitos nessa direção, e nesse post vamos falar um pouco sobre um artigo que realizou um mapeamento sistemático com o objetivo de identificar todos os trabalhos existentes (acadêmicos) que tratam sobre redução de tempo e esforço de testes. O artigo, publicado em 2012, tem como título “Reducing test effort: A systematic mapping study on existing approaches” e pode ser encontrado aqui.

Primeiramente, é claro que poderíamos reduzir o esforço de testes simplesmente tendo menos testes, mas é claro que reduzir a qualidade do produto final é inadmissível, principalmente quando tratamos de sistemas críticos e safety-relevant.

Diante disso, o artigo identificou 5 categorias que se propõem a diminuir o esforço gasto com testes (consequentemente diminuindo o tempo também na maioria das vezes). As cinco categorias são:

  • Test Automation – 50% dos estudos identificados nesse mapeameanto sistemático abordam essa categoria. Isso não é surpreendente pois automatizando testes muito tempo consegue ser economizado.
  • Prediction – 28% dos estudos abordam predição, no sentido de dar suporte a decisões sobre quanto esforço de teste precisa ser gasto para um dado sistema e como distribuir esse esforço entre as diversas atividades.
  • Test input reduction – 15% dos estudos abordam essa categoria, com o intuíto de ajudar da seleção e priorização  de test cases (essa categoria também é conhecida como redução de suítes de teste)
  • Quality assurance (QA) before testing – Essa categoria (encontrada em 5% dos estudos) lida com atividades executadas antes dos testes propriamente ditos e que ajudam a reduzir os testes. Essas atividades são: análises estáticas, inspeçoes e revisões.
  • Test Strategies – Essa categoria (encontrada em 2% dos estudos) aborda pontos  como a seleção de diferentes técnicas de teste e também seleção de diferentes níveis de teste para economizar tempo e esforço.

É claro que esses pontos são focados em estudos acadêmicos, e que nos projetos reais da vida real podem existir outras abordagens para reduzir esforço dos testes. Você usa/conhece alguma abordagem? Compartilhe conosco 🙂

Vídeos – Google Test Automation Conference 2013

Nos dias 23 e 24 de Abril aconteceu mais uma edição do GTAC – Google Test Automation Conference. Dessa vez também acessível via streaming. Os vídeos das 16 horas de palestras também já estão disponíveis no YouTube, os quais compartilho com vocês no decorrer do post. Ainda não tive tempo de assistir a todas as palestras, mas tenho certeza que o nível do conteúdo é excelente, pois já assisti a vários vídeos dos anos anteriores.

As palestras estão divididas em dois vídeos, referentes a cada um dos dias do evento, porém a partir da agenda você pode saltar para a palestra que mais lhe interessar. Já assisti as 4 primeiras palestras do dia 1 e gostei bastante das duas primeiras.

Segue a lista das palestras e os vídeos.

Dia 1:

Duração Palestrante Empresa Tema
00:15:00 Tony Voellm Google Opening
00:45:00 Ari Shamash Google Evolution from Quality Assurance to Test Engineering
00:45:00 James Waldrop Twitter Testing Systems at Scale @Twitter
00:30:00 Break
00:45:00 David Burns and Malini Das Mozilla How Do You Test a Mobile OS?
01:00:00 Lunch
00:45:00 Igor Dorovskikh and Kaustubh Gawande Expedia Mobile Automation in Continuous Delivery Pipeline
00:15:00 David Röthlisberger YouView Automated Set-Top Box Testing with GStreamer and OpenCV
00:15:00 Ken Kania Google Webdriver for Chrome
00:15:00 Vojta Jina Google Karma – Test Runner for JavaScript
00:15:00 Patrik Höglund Google Automated Video Quality Measurements
00:15:00 Minal Mishra Netflix When Bad Things Happen to Good Applications…
00:30:00 Break
00:45:00 Tao Xie North Carolina State University Testing for Educational Gaming and Educational Gaming for Testing
00:45:00 Simon Stewart Facebook How Facebook Tests Facebook on Android
00:15:00

Dia 2:

Duração Palestrante Empresa Tema
00:15:00 Opening
00:45:00 Mark Trostler Google Testable JavaScript – Architecting Your Application for Testability
00:45:00 Thomas Knych, Stefan Ramsauer, Valera Zakharov Google Breaking the Matrix – Android Testing at Scale
00:30:00 Break
00:45:00 Guang Zhu (朱光) and Adam Momtaz Google Android UI Automation
01:00:00 Lunch
00:45:00 Jonathan Lipps Sauce Labs Appium: Automation for Mobile Apps
00:15:00 Eduardo Bravo Google Building Scalable Mobile Test Infrastructure for Google+ Mobile
00:15:00 Valera Zakharov Google Espresso: Fresh Start to Android UI Testing
00:15:00 Michael Klepikov Google Web Performance Testing with WebDriver
00:15:00 Yvette Nameth, Brendan Dhein Google Continuous Maps Data Testing
00:15:00 Celal Ziftci, Vivek Ramavajjala University of California, San Diego Finding Culprits Automatically in Failing Builds – i.e. Who Broke the Build?
00:30:00 Break
00:45:00 Katerina Goseva-Popstojanova West Virginia University Empirical Investigation of Software Product Line Quality
00:30:00 Kostya Serebryany Google AddressSanitizer, ThreadSanitizer and MemorySanitizer — Dynamic Testing Tools for C++.
00:30:00 Claudio Criscione Google Drinking the Ocean – Finding XSS at Google Scale
00:05:00

Como Automatizar Testes de aplicações Android – Parte 2

Olá pessoal.  Estou de volta para dar continuidade a meu último post sobre automação de testes para aplicações Android e neste post vou detalhar como implementei a nossa calculadora fajuta do Bdb para que possamos entender os conceitos básicos de Android e depois conseguirmos automatizar o testes para esta plataforma.

Primeiramente, como falei no post anterior temos que alinhar o ambiente de desenvolvimento que estamos usando. No meu caso eu uso o Eclipse Classic 3.6.2  instalei o plugin ADT. Para mais detalhes de como configurar seu ambiente, veja aqui.

Como todo começo de projeto, vamos no menu principal do eclipse: File->New->Other… e la na janela wizard temos a opção Android Project que nos leva a seguinte tela que devemos colocar o nome do projeto (Calculadora). Depois de colocar o nome do projeto e clicarmos em Next, vamos para a tela que devemos selecionar o Build Target. Como todos devem saber o Android já evoluiu bastante desde do seu surgimento no mercado  com a versão 1.5 mais conhecida como Cupcake até o mais recente e famosa versão 4.o ou Ice Cream Sandwich que promete integrar todo o ecosistema entre smartphones e tablets, mas isso não vem ao caso aqui. No caso da nossa calculadora, ela foi implementada para a versão 2.3.1 (API Level 9)  e é o que eu recomendo para que todos usem no momento para que possamos ter um alinhamento das atividades aqui no post.

Depois que escolhermos o Build Target, vamos para a seguinte tela na qual definimos o nome do pacote no qual nossa activity principal ficará disponível  e também já vamos ter uma sugestão do nome da activity principal que é o nome do projeto + a palavra Activity no final. Nesta última tela você verá também a opção de criar um projeto de teste para este projeto que você esta criando no momento, mas vamos deixar esta opção desmarcada e no próximo post vou mostrar como criamos um projeto de teste para esta aplicação.

Assim que o  nome do projeto, o Build Target, nome do pacote e o nome da activity principal são definidos, o projeto Calculadora vai ser criado com a seguinte estrutura:

Nosso primeiro passo vai ser no arquivo main.xml dentro de res/layout que é o arquivo responsável pela interface visual da activity que vamos implementar. No Android a estrutura da aplicação é dividida em algumas camadas e a camada de interface com o usuário é mais comumente definida no xml. O primeiro passo é selecionar o layout que vamos trabalhar na nossa aplicação, no nosso projeto a layout definido não vai fazer muita diferença, portando fica de livre escolha de vocês qual usar, no nosso código, definimos o relative layout. Para mais detalhe de cada layout suportando no Android, leiam aqui. No nosso projeto de calculadora vamos trabalhar com duas activities e dois xml de layout o primeiro xml (main.xml) temos um TextView (Nome da aplicação),  dois editText (Campos para usuario digitar os operandos) e 4 buttons (um botão para cada operador básico). O segundo xml (result.xml) de layout temos apenas um textView que é para exibir o resultado da operação selecionada pelo usuário na tela anterior.Obviamente poderíamos exibir o resultado na mesma tela mas fizemos dessa forma com um próposito que veremos no próximo post quando formos falar das 2 maneiras de automatizar os testes dessa calculadora.

Para ver como ficou os arquivos xml  e também os arquivos .java que vou explicar nos parágrafos seguintes, baixe o código da nossa aplicação neste link .

Depois de definido o layout vamos para a implementação em si. Primeiramente, vamos ao básico e criamos uma classe chamada Operators.java com todos os métodos de cada operação básica da nossa calculadora, esta classe será instanciada pela activity principal e seus métodos serão chamados de acordo com os eventos que a nossa activity principal tratar.

Na primeira activity, que é a nossa activity principal (CalculadoraActivity.java) definimos qual layout vamos usar (main.xml) e definimos também alguns atributos que vamos utilizar para pegar as instancias dos Views (componentes visuais, Ex: Buttons) que definimos no main.xml e no qual vamos tratar os eventos que serão gerados pelos usuários ao interagir com estes views,  como por exemplo o clique no botão (OnClick). A nossa segunda activity (ResultActivity.java) é a tela que simplesmente pega o resultado “empacotado” pela primeira activity e exibe no textview que esta definida pelo layout result.xml.

Um último detalhe e não menos importante é o arquivo strings.xml que fica dentro da pasta res/values. Nesse arquivo definimos algumas “variáveis” no qual podemos ter acesso de várias parte do cógido, como nos arquivos de layout, no código das activities, etc…
No nosso caso definimos o o valores para todos os views utilizados pela aplicação, como por exemplo o nome na aplicação que é definido no arquivo mais.xml para o TextView esta setado no arquivo strings.xml como app_name e seu respectivo valor é Calculadora.

Após todo esse trabalho a nossa calculadora fajuta do Bdb vai ficar com essa cara como na imagem aqui abaixo:

Bem, por enquanto já temos o suficiente para nos divertimos um pouco durante a semana e no nosso próximo post eu vou finalmente revelar como podemos fazer alguns testes automáticos para esta nossa calculadora fajuta. Aproveitem o restante da semana para por em prática os conceitos básicos  passados aqui e brinquem de alterar o código para entender um pouco mais como a coisa toda funciona. Uma ótima semana para todos e até o próximo post.