Como Automatizar Testes de aplicações Android – Parte 1 (O desafio)

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.

Bem , depois desta uma breve introdução, vamos por a mão na massa e desenvolver uma calculadora bem simples para que depois possamos automatizar alguns testes para essa aplicação. Quem quiser se aprofundar um pouco mais sobre como desenvolver aplicações para Android pode dar uma olhada neste site para desenvolvedor da Google.
Essa calculadora que desenvolvi possui algumas restrições para cada uma das operações básicas (somar, subtrair, multiplicar e dividir) com o objetivo de exemplificar o uso de algumas técnicas de criação de teste para os alunos da turma e essas técnicas de criação de testes não vem ao caso neste post nem nos seguintes que virão, o nosso objetivo aqui é explicar como desenvolver e automatizar testes para aplicações Android. Outro fator relevante que devo deixar claro é que eu utilizei o eclipse com o plugin ADT para desenvolver meu projeto em Android. Para saber como configurar seu ambiente, veja aqui.
Após configurar o ambiente vamos ao nosso desafio:
Vou deixar alguns requisitos básicos da nossa calculadora para que você possam tentar desenvolver e no próximos post  disponibilizarei o nosso código e explicarei passo a passo como o desenvolvi.  Logo abaixo segue os requisitos da aplicação que vamos automatizar os testes mais na frente:

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 !!! 🙂

Anúncios

#TGIF – Revolução biotecnológica

Nesta sexta vou falar mais um pouco sobre a evolução cientifica mas desta vez com foco na biotecnologia.

Drº Michio mais uma vez diz que estamos fazendo uma transição de meros observadores passivos da dança da natureza para sermos coreográfos ativos da natureza.
A revolução biotecnológica nos permitirá entender como o nosso corpo funciona e como podemos modifica-lo para o nosso favor. Com o projeto Genoma Humano (1990-1995), nós obtivemos o mapeamento de todos os códigos genéticos do ser humano. Num futuro não tão longe, podemos imaginar que cada pessoa vai possuir um manual de instrução pessoal, um manual que diz todo o seu código genético e quais doenças você pode ter e como podemos curá-las.Basicamente é como se nosso corpo fosse um enorme programa extremamente complexo e nós pudéssemos reprograma-lo para corrigir defeitos contido nele.

A terapia genética é um exemplo de como podemos manipular os genes das pessoas e mudar o rumo de uma vida, este video mostra um exemplo real que aconteceu com uma criança chamada Alexander Locke que nasceu com uma doença grave no qual seu corpo não possui um sistema imunológico (conhecido SCID), e quando submetido a uma terapia genética teve uma reversão do quadro clínico em pouquissimo tempo e hoje ele leva uma vida normal com seus pais. VocÊ pode estar se perguntando porque não temos a cura para doenças como câncer, aids, cardíacas, etc. O fato é que a SCID é um defeito genético simples que envolve apenas uma “linha” de gene, enquanto essas outras doenças são causadas por várias linhas de gene interagindo com o ambiente. Mas isso não quer dizer que torna impossível encontrar a cura dessas doenças através de uma terapia genética, mas isso com certeza levará um tempo para que se possa mapear todas as possibilidades de sequencia genética que causam essas doenças para que as mesmas possam ser “reprogramadas”.

Reservem uma hora para assistir esse video do Dr. Michio e surpreenda-se o que o futuro nos pode reservar.

A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo mais divertido, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.

Leia, também, outros artigos já publicados na série:

– Viciado em Redes Sociais?

– Combatendo vírus, defendendo a Internet

#TGIF – Hoje é TGIBF

O TGIF de hoje é especial, principalmente para os americanos e canadenses, que é a sexta seguinte ao dia de Thanksgiving (data criada pelo presidente Abraham Lincoln em 1863, definida como a quarta quinta-feira do mês de novembro).  Nesta quinta feira  a maioria dos americanos definitivamente dedicam o dia para agradecer a Deus pelos bons acontecimentos ocorridos durante o ano.

No dia seguinte, muitos dos americanos e canadenses continuam agradecendo a Deus, mas desta vez por ser o Black Friday, pois isso a data de hoje o TGIF transforma em TGIBF (Thank God is BLACK Friday). Por esta razão muitos correm para as lojas e fazem fila  para  para comprar produtos com descontos realmente agressivos, principalmente os produtos eletrônicos que ganham os maiores descontos.

No Brasil parece que as lojas estão querendo trazer esta ideia para cá, timidamente, mas estão. Muitas lojas se juntam em um único site  e lançam promoções para na tentativa de antecipar as compras de final de ano.  Será que esta moda pega ? O que vocês acham ? Os descontos que as lojas brasileiras estão dando realmente são vantajosos ?

Uma coisa é certa, não dá pra comparar os preços dos produtos lá nos EUA com os do Brasil e dia-a-dia, e no Black Friday muito menos. Caso você esteja pensando em viajar para lá no ano que vem no intuito de passear e comprar, vale a pena se programar para ir na ultima semana de novembro. Veja aqui como se preparar para este dia no qual o comércio vira um verdadeiro carnaval 🙂

A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo mais divertido, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.

Leia, também, outros artigos já publicados na série:

–  Como aprender Algoritmos de Ordenação

– Combatendo vírus, defendendo a Internet

Como avaliar a segurança do seu sistema com testes ?

             Recentemente temos visto diversos tipos de ataques hackers a sites e sistemas de governo e até em sistemas de umas das mais renomadas instituição de investigação do mundo, FBI.  Lulzsec, um grupo ativista de hackers que, apesar do curto período de 50 dias de existência,  conseguiu cumprir o seu principal objetivo: Mostrar o quão vulnerável são os sistemas ao nosso redor, inclusive sistemas de pagamentos digitais bastante usados pelo mundo.

Após ler várias reportagens sobre ataques hackers pelo mundo, fiquei curioso sobre o estado da arte de teste na área de segurança e encontrei um organização chamada OWASP, que tem a missão de fazer com que aplicações de segurança sejam visíveis para que pessoas e organizações possam tomar decisões sobre os verdadeiros riscos de segurança de uma aplicação.  A OWASP é uma organização, que qualquer pessoa pode participar e todo material disponibilizado pela mesma esta sob a licença de software aberta.

Como todo bom engenheiro de teste, sabemos que para garantir a qualidade do software, temos que nos preocupar  e procurar se envolver em todas as fases do desenvolvimento do software. Por isso apesar de muitos princípios definidos pela OWASP estarem voltados para as fase iniciais do desenvolvimento dos sistemas, os considero também relevantes para os engenheiros de testes. Estes princípios recomendados pelas OWASP são coleções de propriedades, comportamentos, design e práticas de implementação para reduzir a probabilidade de ataques e também minimizar os impactos quando os ataques acontecem. São eles:

  1. Aplique a defesa-em-profundidade – Este princípio significa a definição de mecanismos de segurança em camadas, ou seja, se em caso de ataque causar uma falha em um mecanismo de segurança, outros mecanismos devem prover a segurança necessária para proteger o sistema.
  2. Utilizar o modelo de segurança positiva – Comumente conhecida com lista branca, pode ser aplicada em diversas áreas de segurança. Em vez de definir uma lista do que é proibido e permitir o resto, o modelo de segurança positiva consiste em definir uma lista do que é permitido e rejeitar qualquer outra coisa.
  3. Falhar com segurança – Como desenvolvedor, você deve considerar que há apenas 3 possibilidades de saídas em um mecanismos de segurança: Permitir a operação;  Não permitir a operação e exceção. E quando um mecanismos de segurança gerar uma exceção, você deve garantir que ela deve seguir o caminho de não permitir a operação, ou seja, métodos comuns como isAutorized(), isAutenticated, e validate() devem retornar sempre falso caso ocorra alguma exceção.
  4. Rodar com privilegio mínimo – Este princípio recomenda que cada conta tenha o mínimo privilegio necessário para realizar seus processos dentro do sistema.
  5. Evitar a segurança por obscuridade – Segurança através da obscuridade é a confiança no sigilo da implementação de um sistema ou componentes de um sistema para mantê-lo seguro.  Um exemplo seria um sistema de criptografia, apenas a chave precisa continuar em segredo, o algoritmo não precisa ficar em segredo.
  6. Mantenha a segurança simples – Modismos de engenharia de software preferem certas abordagens excessivamente complexas para o que seria relativamente simples. Os desenvolvedores devem evitar o uso de negativos duplos e arquiteturas complexas quando uma abordagem mais simples seria mais rápida.
  7. Detecte intrusões – Detectar intrusões requer 3 elementos básicos: Capacidade de registrar eventos relevantes de segurança em logs; Procedimentos que garantem que os logs são monitorados regularmente; Procedimentos para responder adequadamente quando uma intrusão for detectada;
  8. Não confie na infraestrutura – Este principio reforça o primeiro da lista. Cada mecanismo de segurança está sujeito a falhas e por isso não se deve confiar plenamente em alguns desses mecanismos, incluindo os de infraestrutura.
  9. Não confie em serviços – Muitas organizações utilizam capacidade de processamento  de terceiros, que na maioria das vezes possuem políticas de segurança diferentes. Por isso todos os sistemas externos devem ser tratados de forma semelhantes.
  10. Estabeleça padrões de segurança – Há muitas maneiras de entregar uma experiência “fora do comum” para os usuários. No entanto esta experiência deve ser segura, e deve esta nas mãos do usuário decisão de reduzir sua segurança. Por padrão a expiração e complexidade da senha deve estar habilitada. Os usuários poderão ser autorizados a desabilitar estas duas características para simplificar o uso da aplicação e aumentar o seu risco
             Além dos princípios recomendados, a OWASP também desenvolveu um guia de testes de segurança, neste documento ele ensina algumas técnicas e ferramentas mais usadas por hackers para ataques em sistemas web e que devem ser usadas para avaliar a segurança do sistema web em desenvolvimento.  Espero que gostem e aproveitem !!!

#TGIF – A era da revolução científica

Na seção de comentários do meu penúltimo TGIF que fala sobre conceitos, protótipos e ficção científica, recomendei um livro chamado Visões do futuro do fisíco teórico americano Michio Kaku, e no momento que estava procurando informações na internet sobre este autor, encontrei no youtube um vídeo muito interessante da BBC na qual Drº Michio participa como locutor principal, esta matéria é chamada Revolução da inteligência, e parte de uma série da BBC na qual tenho certeza que é baseado nesse livro de Visões do Futuro do Drº Michio Kaku, as outras matérias da série chamam-se respectivamente de revolução biotecnológica e revolução quântica .

Para não estender o post vamos apenas falar sobre a primeira matéria da série (Revolução da inteligência), que já levanta diversos pontos de discussão. Nesta primeira parte, Drº Michio explica como a ciência está avançando tão rapidamente a partir do momento que descobrimos o segredo da matéria (Átomo), revelamos a molécula da vida (DNA) e criamos uma forma de inteligência artificial (Computador). Ele argumenta que a descoberta das leis fundamentais da natureza no século 20, abre portas para um número imensurável de possibilidades no século 21 no qual nós estamos fazendo parte desta transição histórica de uma era de descobertas científicas para uma era de domínio científico.

Inicialmente esta revolução que estar por vir parece um pouco assustadora, mas se pararmos um pouco e voltarmos para mais de 70 anos atrás quando tivemos umas das primeiras cirurgias cardíacas de sucesso feitas pelo Dr. Alfred Blalock em parceria com Vivien Thomas, muito bem contada no filme Quase Deuses, percebemos que todos nós naturalmente resistimos um pouco à uma revolução desse tipo e sempre questionamos qual será o limite para isso tudo.

Para se ter uma idéia do tamanho do impacto social que esta revolução está por fazer, posso destacar alguns questionamentos que os cientistas estão imaginando que possam vir junto com esta revolução:

– Na evolução da realidade virtual e redes sociais virtuais, surge a questão de o que acontecerá se nós começarmos a preferir nossa redes sociais virtuais do que a nossa rede social real ? Isso surge porque hoje já temos mais de 30 milhões de pessoas no mundo que passa em média 20 horas por semana no mundo virtual, por exemplo World of Warcraft.

– Na área de inteligência artificial, onde teremos um evolução tão grande que as máquinas cada vez mais terão a capacidade de agir como a inteligência humana, surge a questão de como nós vamos nos relacionar com estas máquinas ?

– Uma última e intrigante pergunta surge com o avanço das tecnologias biológicas e eletrônicas na qual nos próximos 50 anos poderemos ter máquinas com mais componentes biológicos e pessoas com mais componentes eletrônicos. Daí surge a questão de como vamos categorizar o que é pessoa e o que  é máquina ?

Assistam o vídeo abaixo, tem quase uma hora de duração e infelizmente não está com legendas, e vamos discutir o que vocês que podem acontecer quando esta nova realidade estiver mais próxima ao nosso cotidiano.

No futuro conversaremos sobre as outras matérias da série bastante interessante da BBC.

A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo menos técnico, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.

Leia, também, outros artigos já publicados na série:

– Steve Jobs e seu legado

– “Tudo” sobre o iPhone 5

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

Cobertura de código, como ?

No meu ultimo post falei sobre a importância da cobertura de código e o quanto ele é comumente utilizado com critério de saída nas primeiras fases de um projeto de software. Lá eu falei das duas técnicas de medição de cobertura de código mais usadas, são elas a Statement Coverage e Decision Coverage. Agora venho escrever este post para cumprir a promessa que deixei no ultimo post, que é mostrar na prática como utilizar uma ferramenta para fazer a medição da cobertura dos testes, neste exemplo, unitários.

A ferramenta que utilizei para exemplificar as duas técnicas acima foi um plugin para o Eclipse chamada CodeCover.
CodeCover é uma ferramenta de teste glass-box grátis e desenvolvido em 2007 na Universidade do Stuttgart.

Para iniciarmos o exemplo, vou mostrar uma classe (Example.java) com dois métodos bastante simples para facilitar o entendimento das técnicas utilizadas.

public class Example {

	public void firstExample(int a, int b) {
		int c =  a + (2*b);
		if (c>50){
			System.out.println(c);
		}
		System.out.println("Fim 1");
	}
}

Abaixo temos os primeiros testes unitários escritos na classe ExampleTest.java para verificar o funcionamento do método firstExample(int a, int b).

	@Test
	public void testFirstExample() {
		try {
			ex.firstExample(20, 15);
		} catch (final Exception e) {
			Assert.fail();
		}
		Assert.assertTrue(true);
	}

	@Test
	public void testFirstExample1() {
		try {
			ex.firstExample(20, 25);
		} catch (final Exception e) {
			Assert.fail();
		}
		Assert.assertTrue(true);
	}

Para medir a cobertura dos testes acima apenas precisamos marcar as classes Example e ExampleTest para ser usado pela ferramenta de Medição de Cobertura ( Figura 1)

Tela 1 - Clique para ampliar

Após marcar as classes envolvidas (classe de teste e classe a ser testada), iniciamos a execução dos testes no modo CodeCover para JUnit. Ao finalizar a execução dos testes, aparecerá uma aba chamada Test Sessions, no qual podemos marcar os teste unitários executados e visualizar as linhas de código da classe testada que foram exercitado pelo teste. Na tela 2 abaixo podemos ver que o teste testFirstExample exercitou apenas 3 linhas de código de um método que possue 4 linhas de código.

Tela 2 – Clique para ampliar
Tela 3 – Clique para ampliar

Na tela 3, quando marcamos apenas o teste testFirstExample1, verificamos que o mesmo possui uma cobertura completa do método firtExample(int a, int b). Isso quer dizer que apenas o segundo teste (testFirstExample1) é suficiente para se ter 100% de Statement Coverage, ou seja todas as linhas de código foram exercitadas.

Mas se prestar atenção na tela 3 a linha de código numero 8 da classe: if (c>50) {”  está pintada de amarelo, isto quer dizer que essa linha de código não está completamente exercitada, ou seja, esta estrutura condicional ainda precisa ser estimulada por mais teste para que outro fluxo seja tomado, e isso a gente consegue garantir quando testamos esse método com os dois teste anteriores. Olhando para tela 4 abaixo, percebemos que quando marcamos os dois testes (testFirstExample e testFirstExample1), temos 100% de cobertura  de Decision Coverage, pois ambos os teste exercitaram a linha 8 para que o fluxo fosse tomado tando para que C fosse maior que 50 e C fosse menor que 50, exercitando assim a estrutura condicional (if) pode completo.

Tela 4 – Clique para ampliar

Analisando direitinho, podemos perceber que toda suíte de teste que cobre 100% de decision coverage, também cobre 100% de statement coverage, no entanto o inverso nem sempre  é verdade.

Espero ter esclarecido melhor o conceito de Statement e Decision coverage com os exemplos acima. O que vocês acharam ? Caso tenham dúvidas relacionadas a este tema, por favor utilizem o espaço de comentário para que possamos discutir mais sobre o assunto.

Obrigado e até breve !!!

#TGIF – Steve Jobs e seu legado

O TGIF de hoje não poderia ser indiferente ao triste acontecimento que ocorreu essa semana. O mundo perdeu um dos maiores visionários da história, muitos já o comparam com da Vinci, Henry Ford, Thomas Edison entre outras personalidades importantes da história da humanidade.

Para conhecer um pouco mais desse cara que foi um ícone de algumas gerações, existem alguns livros e filme que de um forma ou de outra falam de sua vida e sua personalidade. São eles:

A segunda vinda de Steve Jobs – Sinopse: Baseado em dezenas de relatos de pessoas que conviveram com o executivo nas últimas três décadas, este livro é a biografia do personagem que melhor representa o sonho americano de Silicon Valley. Autor de perfis para as revistas Vanity Fair e GQ e correspondente da Fortune, o jornalista Alan Deutschman inicia a narrativa em 1985, no momento em que Jobs sai da Apple acusado de roubar segredos da   empresa. Seguem-se a ascensão e queda de sua própria empresa, a Next, o enorme sucesso de seu estúdio de animação, a Pixar, produtor dos filmes Toy Story e Vida de inseto, e, no final dos anos 90, seu retorno triunfal à empresa que o    havia demitido. O livro tem como fio condutor os altos e baixos da vida profissional de Jobs, mas mostra também o          lado reservado do empresário – a relação de amor e ódio com Bill Gates, as negociações com Michael Eisner e Jeffrey Katzenberg, da  Disney, seus métodos de administração e seu contato com a imprensa.

A Cabeça de Steve Jobs – Sinopse: É difícil acreditar que um homem revolucionou os computadores nos anos 1970 e 1980, o cinema deanimação e a música digital nos anos 1990. Por outro lado, são lendárias as histórias de seus repentinos acessos de raiva, revelando o verdadeiro Steve Jobs. Então, o que há, realmente, dentro do cérebro de Steve? Segundo o autor, é um feixe de contradições. O autor destila os princípios que guiam Jobs ao lançar produtos arrasadores, ao atrair compradores fiéis e ao administrar a sua empresa. O resultado é este livro sobre Steve Jobs que é, ao mesmo tempo, uma biografia e um guia sobre liderança.

Steve Jobs – Sinopse: Este livro, baseado em mais de quarenta entrevistas com Steve Jobs e entrevistas com familiares, amigos, colegas, adversários e concorrentes -, narra a vida deste empresário, cuja paixão pela perfeição e cuja energia contribuíram para seis indústrias – a computação pessoal, o cinema de animação, a música, a telefonia celular, a computação em tablet e a edição digital.

Também existe um filme clássico chamado Piratas do Vale do Silício, que fala basicamente sobre a história dos dois principais personagens da tecnologia do mundo: Bill Gates e Steve Jobs na década de 70 e início da década de 80.

Vamos deixar aqui um vídeo nesse post, que com certeza esta sendo visto milhares de vezes nos últimos dias, uma palesta famosa que o próprio fala um pouco de sua vida na formatura de uma turma da universidade de Standford. Isto é para deixar registrado em mais um lugar na grande rede a importância que esse cara representa para toda a nossa geração.  Descanse em paz Steve.

A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo menos técnico, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.

Leia, também, outros artigos já publicados na série:

– “Tudo” sobre o iPhone 5

– Conceitos, protótipos e ficção científica – Os primeiros passos para evolução.

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.