automação do teste de sanidade para dispositivos …...automação do teste de sanidade para...
Post on 07-Jun-2020
7 Views
Preview:
TRANSCRIPT
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
katia.silva@fucapi.br, {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:
Anais do Encontro Regional de Computaۥo e Sistemas de Informaۥo
Manaus, 25 a 27 de abril de 2013 2 ISSN 2238-5096 (CDR)
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.
Anais do Encontro Regional de Computaۥo e Sistemas de Informaۥo
Manaus, 25 a 27 de abril de 2013 3 ISSN 2238-5096 (CDR)
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
Anais do Encontro Regional de Computaۥo e Sistemas de Informaۥo
Manaus, 25 a 27 de abril de 2013 4 ISSN 2238-5096 (CDR)
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;
Anais do Encontro Regional de Computaۥo e Sistemas de Informaۥo
Manaus, 25 a 27 de abril de 2013 5 ISSN 2238-5096 (CDR)
• 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
Anais do Encontro Regional de Computaۥo e Sistemas de Informaۥo
Manaus, 25 a 27 de abril de 2013 6 ISSN 2238-5096 (CDR)
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.
Anais do Encontro Regional de Computaۥo e Sistemas de Informaۥo
Manaus, 25 a 27 de abril de 2013 7 ISSN 2238-5096 (CDR)
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.
Anais do Encontro Regional de Computaۥo e Sistemas de Informaۥo
Manaus, 25 a 27 de abril de 2013 8 ISSN 2238-5096 (CDR)
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.
Anais do Encontro Regional de Computaۥo e Sistemas de Informaۥo
Manaus, 25 a 27 de abril de 2013 9 ISSN 2238-5096 (CDR)
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.
Anais do Encontro Regional de Computaۥo e Sistemas de Informaۥo
Manaus, 25 a 27 de abril de 2013 10 ISSN 2238-5096 (CDR)
top related