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
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)
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:
Outros:
Sentiu falta de algum? Pode adicionar nos comentários =D
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:
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:
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:
É 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 🙂
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 | Opening | |
| 00:45:00 | Ari Shamash | Evolution from Quality Assurance to Test Engineering | |
| 00:45:00 | James Waldrop | 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 | Webdriver for Chrome | |
| 00:15:00 | Vojta Jina | Karma – Test Runner for JavaScript | |
| 00:15:00 | Patrik Höglund | 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 | 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 | Testable JavaScript – Architecting Your Application for Testability | |
| 00:45:00 | Thomas Knych, Stefan Ramsauer, Valera Zakharov | Breaking the Matrix – Android Testing at Scale | |
| 00:30:00 | Break | ||
| 00:45:00 | Guang Zhu (朱光) and Adam Momtaz | Android UI Automation | |
| 01:00:00 | Lunch | ||
| 00:45:00 | Jonathan Lipps | Sauce Labs | Appium: Automation for Mobile Apps |
| 00:15:00 | Eduardo Bravo | Building Scalable Mobile Test Infrastructure for Google+ Mobile | |
| 00:15:00 | Valera Zakharov | Espresso: Fresh Start to Android UI Testing | |
| 00:15:00 | Michael Klepikov | Web Performance Testing with WebDriver | |
| 00:15:00 | Yvette Nameth, Brendan Dhein | 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 | AddressSanitizer, ThreadSanitizer and MemorySanitizer — Dynamic Testing Tools for C++. | |
| 00:30:00 | Claudio Criscione | Drinking the Ocean – Finding XSS at Google Scale | |
| 00:05:00 |
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.
Olá pessoal, este ano vou começar com uma pequena série de posts e um pouco DIFERENTE dos posts habituais para falar mais uma vez de teste na prática. Obviamente para ser diferente eu vou deixar este primeiro post um desafio para todos assim como eu tive um desafio no final do ano passado para preparar e ministrar uma disciplina de teste de software para uma turma de desenvolvedores que estava participando de um curso de desenvolvimento para Android. Preocupado em deixar as aulas de teste mais interessantes, eu arrisquei adaptar meu material para algo que fosse bastante prático e relevante para essa turma e por isso dei uma estudada no Android e como desenvolver aplicações e criar testes automáticos para o mesmo e acabei descobrindo algumas coisas que o SDK disponibiliza que gostaria de compartilhar com vocês.
Antes de começarmos a desenvolver testes para o Android, preciso passar algumas informações relevantes para que todos possam conseguir ter um entendimento completo de como automatizar alguns testes para aplicações em Android e também consigam completar o desafio que deixarei neste post.
Para podermos automatizar testes para aplicações Android, precisamos entender alguns de seus componentes básicos, que são: Activities, Services, Content Providers e Broadcast Receivers.
Activities – Uma activity é um dos componentes do Android mais usados nas aplicações pois ele é que fornece uma tela com a qual os usuários podem interagir. Por exemplo dicar um número de telefone, escrever uma sms, ou visualizar um mapa. Para cada activity é dada uma “janela” na qual “desenhamos” uma interface de usuário. As “janelas” normalmente preenche toda a tela, mas também podem ser menores do que a tela e flutuar em cima de outras “janelas”.
Services – São componentes de aplicação que podem executar operações de longa duração em segundo plano, portanto não fornecem uma interface de usuário. Um serviço pode ser iniciado por uma aplicação e ele continuará a ser executado em segundo plano, mesmo se o usuário trocar para outra aplicação.
Content Providers – Como o nome já explica, Content Providers é componente responsável por armazenar e recuperar os dados e torna-los acessível para todas as aplicações, ou seja são os provedores de conteúdo. A única forma de compartilhar dados entre aplicações no Android é através de content providers, pois não existe área de armazenamento comum que todos os pacotes Android podem acessar.
Broadcast Receivers – É um componente que responde a anúncios de todo o sistema de broadcast. Muitos brodcast provenientes do sistema, como um broadcast anunciando que a bateria está fraca ou uma sms foi recebida. As aplicações também podem iniciar os broadcast, por exemplo, para permitir que outras aplicações saibam que alguns dados foram disponibilizados para eles usarem. Os broadcast receivers também não possuem interface de usuário, mas eles podem criar uma notificação de barra de status para alertar o usuário quando um evento de broadcast ocorreu.
Nome: Aplicativo Calculadora Fajuta
[REQ001] Tela principal deve possuir dois campos (EditTexts) para inserir valores e um botão (Button) de cada funcionalidade da calculadora, que são:
– SOMAR
– SUBTRAIR
– MULTIPLICAR
– DIVIDIR
[REQ002] A operação SOMAR só efetua soma de números entre 0 e 10, pois a calculadora é fajuta. O resultado deve ser mostrado em um texto (TextView) no canto inferior da tela.
[REQ003] A operação SUBTRAIR é um pouco mais evoluída e consegue efetuar a subtração de números entre 0 e 50. O resultado deve ser mostrado em um texto no canto inferior da tela e caso seja um resultado negativo, o mesmo deve estar na cor vermelha.
[REQ004] A operação MULTIPLICAR deve multiplicar apenas números pares.
[REQ005] A operação DIVIDIR, da mesma forma da operação Somar, só efetua a divisão de números entre 0 e 10.
E claro que qualquer dúvida por mais simples que seja, podem comentar aqui neste post e terei o prazer de responder o mais rápido possível. Para os mais tímidos, podem me mandar um email que tem no meu perfil aqui do Bdb. Boa sorte a todos !!! 🙂
Não restam dúvidas de que automação de testes é uma atividade fundamental no desenvolvimento de sistemas. Desde os testes unitários até os de aceitação precisamos cada vez mais de uma estrutura que permita a entrega de aplicações de maior qualidade num menor espaço de tempo.
Na internet existem diversos materiais e vídeos, que podem nos ajudar a progredir nesse caminho. A indicação de hoje são os vídeos do Google Testing Automation Conference, conferência do google, que reúne os mais respeitados profissionais. Na página da conferência você encontra os vídeos e os slides das palestras realizadas. Buscando um pouco mais você pode encontrar também os vídeos das edições anteriores.
A palestra de abertura da edição de 2011, apresentada por Alberto Savoia, têm como título Test is Dead (Teste está morto), ficou curioso? De forma brilhante, o mesmo passeia pelas metodologias de desenvolvimento de software, finalizando com os motivos que o levam a crer que o teste está morto.
São 35 minutos de palestra, somados a 15 minutos de perguntas. Logo, caso não possa parar agora, guarde o link e assista numa melhor oportunidade, vale bastante a pena.
Quer saber mais sobre como o pessoal testa as aplicações no google? Acesse o blog mantido por eles.
Outros vídeos interessantes do pessoal do google podem ser encontrados na página do youtube – Google Tech Talks.
Na próxima semana, publico a parte dois do post, onde comentarei sobre alguns dos pontos discutidos na palestra acima.
Bytes don't Bite! 