Automação do Teste de Sanidade para Dispositivos Móveis ... · (Metodologia do Ciclo de vida do Teste Automatizado) na qual o analista de teste é incluído logo no início do

Automação do Teste de Sanidade para Dispositivos Móveis

com o Auxílio da Ferramenta Robotium

Lucas de B. Gomes1, Erbett Hinton R. Oliveira

2, Kátia Cilene N. da Silva

1

1Departamento de Computação – Fundação Centro de Análise, Pesquisa e Inovação

Tecnológica (Fucapi)

CEP 69.075-351 – Manaus – AM – Brasil

2Departamento de Computação – Centro Universitário do Norte (Uninorte) – Manaus,

AM – Brasil

[email protected], {lucas.gomes, erbett.oliveira}@fpf.br

Abstract. The agile processes for software development and the rapid growth

of mobile applications require the testing phase follow this dynamism to

ensure product quality. In Iterative and Incremental model, the realization of

Sanity Test each new cycle allows an initial assessment before the software is

released for further testing. With automation, in particular with the tool

Robotium, the repetitive task of running tests becomes more effective, fast and

reliable, releasing the test analyst for more detailed tasks.

Resumo. Os processos ágeis de desenvolvimento de software e o rápido

crescimento de aplicativos para dispositivos móveis exigem que a fase de

testes acompanhe esse dinamismo a fim de garantir a qualidade do produto.

No modelo Iterativo e Incremental, a realização do Teste de Sanidade a cada

novo ciclo permite uma avaliação inicial antes do software ser liberado para

testes mais aprofundados. Com a automação, em especial com a ferramenta

Robotium, a tarefa repetitiva de execução de testes torna-se mais efetiva,

rápida e confiável, liberando o analista de teste para tarefas mais minuciosas.

1. Introdução

Um teste é dito automatizado quando se desenvolve um programa ou um script que

executará os testes (Ramesh & Desikan, 2006). A automação tem como objetivo

otimizar o tempo do analista de teste, diminuindo a necessidade de testes manuais,

especialmente aqueles que são repetidos com frequência. Testes manuais repetitivos

podem ser considerados maçantes e propensos a falhas humanas.

Por outro lado, muitas empresas têm a ilusão que produzir scripts de testes

automatizados possibilitará que o analista tenha um ganho imediato de tempo, uma

eficácia melhor nos testes e uma cobertura mais completa do software. Partindo desse

pressuposto, rapidamente adquirem ferramentas de automação de alto custo, sendo que

o processo de teste destas não é bem definido e os testes manuais não são maduros

(Caetano, 2008).

Uma boa prática diz que antes de começar o processo de automatização dentro

de uma empresa deve ser feito um projeto piloto para que seja retirada uma prova de

Anais do Encontro Regional de Computa€•o e Sistemas de Informa€•o

Manaus, 25 a 27 de abril de 2013 1 ISSN 2238-5096 (CDR)

conceito (Hayes, 1996). A escolha da ferramenta de automação também é feita

juntamente com a prova de conceito já a descartando se não atender as expectativas do

analista de teste. Adaptando o comparativo descrito por Hayes (1996), existe uma

diferença de pensamentos ao se fazer testes e automação de testes, conforme descrito na

Tabela 1:

Tabela 1. Comparativo entre os termos “Testes” e “Automação de Testes”

Testes Automação de teste

Conhecimento da aplicação Saber desenvolver

O que realmente testar Como automatizar o teste

Criar casos de teste Criar scripts de teste

Pensar em cenários alternativos Programar de forma robusta e mais

completa possível

O que é possível automatizar

Aplicar diferentes técnicas de teste O que realmente automatizar

Adicionar, reescrever ou modificar casos de teste Criar um código manutenível

Pode-se considerar, como uma das grandes vantagens da automação, a

aproximação do analista de teste com o desenvolvedor do software, possibilitando a

previsão e mitigação de erros para alcançar a melhoria da qualidade da aplicação.

Uma metodologia que promove essa simbiose é denominada MCTA

(Metodologia do Ciclo de vida do Teste Automatizado) na qual o analista de teste é

incluído logo no início do ciclo de vida do sistema, durante a análise de negócios, em

toda a fase de requisitos, construção e desenvolvimento do software. Essa aproximação

gera cenários de testes automatizados mais robustos (Dustin; Rhaska; Paul,1999). A

metodologia MCTA prima por alguns critérios de avaliação das funcionalidades que são

revisadas pela equipe de automação de teste, dentre os quais:

• Completude. Avaliar se o requisito é bem definido.

• Consistência. Garantir que requisitos não se contradigam com outros.

• Viabilidade. Avaliar se o requisito pode realmente ser implementado com a

tecnologia disponível, especificações de hardware, orçamento do projeto, cronograma e

o nível dos recursos humanos.

• Testabilidade do software. Avaliar o grau em que um método de teste pode

provar que um requisito foi implementado com sucesso.

Em uma visão macro, a MCTA contempla seis processos primários (ou

componentes) em seu ciclo de vida, conforme ilustrado na Figura 1:



Figura 1. Os seis processos da MCTA (Metodologia do Ciclo de vida do Teste

Automatizado)

Fonte: DUSTIN, E., RHASKA, J., PAUL, J. (1999). (Adaptado pelo autor).

Segundo Caetano (2008), o analista que fará a automação dos testes é

denominado um “testador-desenvolvedor” ou apenas um “automatizador” e tem que ter

um interesse grande na área da programação, já que a atividade de automação é

programação pura. O analista responsável pela automação deve ter interesse em

conhecer as ferramentas ou frameworks que irão auxiliar na tarefa de implementar os

scripts de teste e procurar aperfeiçoamento contínuo nesta técnica de teste. Vale

ressaltar que nem sempre um bom analista de teste se tornará um bom “testador-

desenvolvedor”. Certos testes, como o Teste de Sanidade, são repetidos a cada nova

entrega, por isso, este tipo de teste é um forte candidato a sofrer automação.

2. Estado da Arte

O campo de testes automatizados em dispositivos móveis incluem trabalhos como o

Teste de Integração para Android (Jeon, 2012) e Testes de Regressão utilizando o

Robotium (Knott, 2011). Segundo Talwar, Bhushan e Gupta (2012), um Teste de

Sanidade é um teste básico para avaliar rapidamente a validade de uma afirmação ou

cálculo. Com a efetiva repetição desse tipo de teste, Caetano (2008) estabelece papéis e

ferramentas para tal tarefa. Contudo, a automação mobile exige frameworks distintos

dos utilizados pelas aplicações web. Por isso, o trabalho de Reda (2012) no

desenvolvimento do Robotium — que automatiza aplicações Android — tem sido de

suma importância no desenvolvimento de novas possibilidades na área de teste de

software.



3. Teste de Sanidade

Teste de Sanidade (Sanity Test) é o teste realizado quando se deseja verificar o

comportamento principal da funcionalidade e a aplicação é considerada “sã”, para que

se possa prosseguir com outros testes mais completos (Limaye, 2009).

As vantagens de se utilizar os Testes de Sanidade incluem sua abrangência, bem

mais amplo que os demais, além de ser rápido para ser executado. Segundo Rabia

(2011), o uso desse tipo de teste aumenta muito a qualidade do software e reduz os

esforços requeridos no processo de validação.

O desenvolvimento para dispositivos móveis, especialmente alavancados pelo

sistema operacional Android, também pode usufruir das vantagens do Teste de

Sanidade, pois o seu ciclo de desenvolvimento não foge à regra do utilizados em outras

plataformas.

4. Android

Segundo Pereira & Silva (2009), o Android é uma plataforma para tecnologia

móvel completa, envolvendo um pacote de programas para diversos dispositivos, já com

sistema operacional, middleware, aplicativos e interface do usuário. A plataforma tem a

característica de ser desenvolvido com código-aberto e baseado no sistema operacional

Linux. A Figura 2 mostra como está definida a arquitetura Android.

Figura 2. Arquitetura Android

Fonte: Pereira, L., Silva, M. Android para Desenvolvedores (2009). (Adaptado pelo autor).

No intuito de obter uma participação no mercado de software para dispositivos

móveis, a Google uniu-se a um grupo de empresas líderes do mercado de telefonia tais

como LG, Motorola, Samsung, dentre outras. Esse grupo é denominado de Open



Handset Alliance (OHA) e tem por objetivo padronizar a plataforma, de modo esta

atenda às expectativas do usuário frente às tendências do mercado.

Com o uso de um SDK (Software Development Kit), criar aplicativos na

plataforma tornou-se uma opção para empresas e desenvolvedores independentes. A

qualidade do software, contudo, depende de testes na aplicação, como os testes

unitários, isto é, testes aplicados nas menores unidades do código (métodos, classes etc),

que podem ser realizados com o framework JUnit.

4.1 JUnit

O JUnit é um framework de teste unitário capaz de testar e validar o funcionamento uma

unidade do código isoladamente, ou seja, seu comportamento interno. Foi criado em

1997 por Kent Beck e Erich Gamma tendo em mente que um componente não pode ser

provado que funcione até ser testado. O JUnit é open source, liberado sob a Common

Public License Version 1.0 da IBM. É considerado uma ferramenta para o Java simples,

mas poderosa e efetiva (Massol e Husted, 2004).

Para testes que avaliem o comportamento externo da aplicação móvel, foi criado

um framework denominado Robotium. Unindo-se ao JUnit, ambos fornecem recursos

capazes de automatizar e validar as entradas e saídas.

4.2 Robotium

O Robotium é um framework capaz de fazer testes de caixa-preta automatizados para

Android. Suas funcionalidades incluem a simulação de eventos como toques, cliques,

entrada/modificação de texto e demais ações reproduzidas pelo usuário (Knott, 2011).

Os testes escritos no Robotium podem ser simulados no Android por meio da AVD

(Android Virtual Machine) — que é um emulador de um dispositivo — ou em um

equipamento real, dando ao analista um resultado instantâneo do processo de automação

(Knott, 2011).

O Robotium foi desenvolvido em Java e os scripts podem ser executados no

framework de testes JUnit. Assim, tem-se toda a flexibilidade do Robotium com o poder

de rastreabilidade que o JUnit oferece, apresentando resultados compreensíveis para o

analista.

Apesar da simplicidade do Robotium, o seu arcabouço de métodos permite que o

analista escreva scripts robustos para cenários complexos. Para que o framework

funcione é necessária a importação de apenas um arquivo JAR (Java Archive) no

classpath do projeto de teste.

Pode-se dizer que o Robotium é uma evolução dos testes de instrumentação

antes feitos de uma forma bem complexa que requeriam que o analista soubesse a fundo

o código implementado pelos desenvolvedores para que um teste pudesse ser feito e

sendo que os testes de instrumentação eram lentos, não era adequado utilizá-los em

TDD (Test-Driven Development ou Desenvolvimento Orientado a Testes) e aplicativos

complexos eram difíceis de automatizar (Reda, 2010).

Segundo Reda (2012) pode-se citar os benefícios do Robotium:

• Fácil escrita scripts de teste;



• Delays automáticos nos testes;

• Automaticamente segue a Activity atual;

• Views achadas automaticamente;

• Nenhuma modificação feita na plataforma Android.

5. Estudo de Caso

O objetivo deste estudo de caso é demonstrar, através da implementação e execução dos

casos de teste (de forma manual e automatizada), as vantagens do processo de

automação em um dispositivo móvel. Para obter os resultados, foram aplicados Testes

de Sanidade manuais e automatizados no aplicativo “Lista de Compra”, conforme

ilustrado na Figura 3. Nesse sistema, o usuário pode cadastrar uma lista de compras e

itens nesta lista.

Figura 3. Aplicativo “Lista de Compra”

Foram usados quatro dispositivos, com diferentes versões do Android, conforme

descrito na Tabela 2:

Tabela 2. Dispositivos usados

Dispositivos usados Fabricante Versão do Android

Galaxy Mini Samsung 2.3.6

Galaxy S2 Samsung 4.0.3

Galaxy S3 Samsung 4.1.1

Galaxy Tab 7 Samsung 2.3.5



Foram criados cinco casos de teste de forma objetiva — o que caracteriza o

Teste de Sanidade — na ferramenta TestLink (uma ferramenta de gerenciamento de

testes) para testar as funcionalidades principais do aplicativo. Foram especificados testes

para incluir lista e seus itens, editar itens e, por final, excluir a lista. A Figura 4

demonstra como foi feita a especificação do caso de teste para incluir um item na lista.

Figura 4. Demonstração do caso de teste

Com o auxílio do framework Robotium foi criado um método para cada caso de

teste especificado no TestLink correspondente com o seu objetivo, seus passos e

resultado esperado como é demonstrado na Figura 5 o script utilizado para testar o caso

de teste.

Figura 5. Demonstração do script utilizado para testar a inclusão de um novo item na

lista

Para a validação e coleta de métrica dos testes executados de forma

automatizada todos os scripts foram executados em conjunto pelo framework JUnit. A

Figura 6 demonstra o framework validando o script.



Figura 6. Demonstração do framework JUnit validando o script

5.1 Resultados Obtidos e Análise dos Resultados

Para obter a quantidade de tempo que um analista de teste gasta executando os testes de

sanidade foi executado os cinco casos de teste e toda a atividade foi cronometrada para

cada dispositivo e a Tabela 3 demonstra os resultados:

Tabela 3. Tempo gasto de teste manual para cada dispositivo

Execução dos testes manuais

Dispositivos Tempo de execução

Galaxy Mini 4 min. e 02 seg.

Galaxy S2 3 min. e 54 seg.

Galaxy S3 3 min. e 44 seg.

Galaxy Tab 7 3 min. e 40 seg.

Analisando a Tabela 3, o analista de teste gastaria, em média, a soma de quinze

minutos para executar os cinco testes de sanidade especificados no TestLink nos quatro

dispositivos distintos. Executando os mesmos testes de forma automatizada temos os

resultados demonstrados na Tabela 4:

Tabela 4. Tempo gasto de teste automatizado para cada dispositivo

Execução dos testes automatizados

Dispositivos Tempo de execução

Galaxy Mini 43 seg.

Galaxy S2 43 seg.

Galaxy S3 43 seg.

Galaxy Tab 7 44 seg.

Ao comparar as duas tabelas, fica nítida a diferença de tempo na execução entre

o teste manual e o automatizado. Apesar desse resultado ser previsível, há de se

considerar que a curva de esforço para a implementação dos testes automatizados é

muito superior a dos testes manuais, o que dá a esse último maior velocidade nas fases

iniciais. Essa vantagem, entretanto, é transposta pelos testes automatizados,

principalmente quando há a necessidade de nova execução dos testes, como no caso do

Teste de Sanidade. A Figura 7 demonstra o ganho de tempo que o analista de teste terá

ao executar de forma automatizada, notável a partir do ciclo 3.



Figura 7. Demonstração do ganho de tempo

Analisando a Tabela 4, o analista de teste gastaria em média dois minutos para a

execução dos cinco testes. O resultado do tempo relatado na Tabela 4 é a soma feita na

métrica do framework JUnit apresentado na Figura 8:

Figura 8. Demonstração da métrica obtida pelo framework JUnit

6. Conclusão

Com o grande crescimento do mercado de dispositivos móveis a quantidade de testes

manuais pode ser extensos devido à divergência de configuração e resolução dos

dispositivos submetidos aos testes e a automação vem auxiliar o analista de teste lhe

dando agilidade nos testes, resultados rápidos e garantir com mais precisão as

funcionalidades do aplicativo.



Quando se é aplicado à automação de forma correta desde o início do projeto o

analista de teste poderá ter um ganho significativo de tempo, no qual pode ser investido

em testes adicionais ou testes exploratórios com o objetivo de achar a quantidade

máxima de falhas e cobrir o máximo de cenários possíveis.

Referências

Gopalaswany, R. e Srinivasan, D. (2006) “Software Testing - Principles and Practices”,

Dorling Kindersley (India) Pvt. Ltd.; 1a. edição.

Caetano, C. (2008) “Engenharia de Software Magazine”, DevMedia Revista Digital; 5a.

edição.

Jeon, J. e Foster, J. (2012) "Troyd: Integration Testing for Android", Technical Report

CS-TR-5013, ago 2012.

Dustin, E., Rhaska, J. e Paul, J. (2008) “Automated Software Testing – Intruduction,

Management and Performance”, Addison Wesley Ltd.; 13a. edição.

Hayes, L. (1996) “The Automated Testing Handbook”, Software Testing Institute; 2a

edição.

Limaye, M. (2009) “Software Testing: Principles, Technics and Tools”, Tata McGraw

Hill Education Private Limited; 1a edição.

Zain, J. M., Mohd, W. M. W., El-Qawasmeh Eyas, Software Engineering and Computer

Systems: Second International Conference, 181., 2011. Kuantan, Pahang, Malaysia.

Anais... Kuantan, Pahang, Malaysia, 2011, 829 p.

Knott, D. (2011), “The magazine for Agile Developers and Agile Testers”, Agile Record

– Free Digital Version; 7a. edição.

Talwar, R., Bhusnan, B., Gupta, R., “International Journal of Research in IT &

Management”, v.2, n.2, p.6, fev 2012.

Reda, R. e Josefson, H. (2010), “Robotium – Easy Black-box Testing for Android”,

http://swdc-central.com/androidonly/dl/ao2010-hugo-josefson.pdf, mar.

Reda, R. (2012), “Methods & Tools – Practical knowledge for the software developer,

tester and project manager”, http://www.methodsandtools.com, mar.

Pereira, L. e Silva, M. (2009) “Android para Desenvolvedores”, Brasport Livros e

Multimídia Ltda.; 1a. edição.

Massol, V. e Husted, T.(2004), “JUnit In Action”, Manning Publications Co.; 1a.

edição.



Documents

Automação do Teste de Sanidade para Dispositivos Móveis ... · (Metodologia do Ciclo de vida do Teste Automatizado) na qual o analista de teste é incluído logo no início do