Automação do Teste de Sanidade para Dispositivos Móveis com o Auxílio da Ferramenta Robotium Lucas de B. Gomes 1, Erbett Hinton R. Oliveira 2, Kátia Cilene N. da Silva 1 1 Departamento de Computação Fundação Centro de Análise, Pesquisa e Inovação Tecnológica (Fucapi) CEP 69.075-351 Manaus AM Brasil 2 Departamento 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 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 Conhecimento da aplicação O que realmente testar Criar casos de teste Pensar em cenários alternativos Automação de teste Saber desenvolver Como automatizar o teste Criar scripts de teste Programar de forma robusta e mais completa possível O que é possível automatizar Aplicar diferentes técnicas de teste Adicionar, reescrever ou modificar casos de teste O que realmente automatizar 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: 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 testadordesenvolvedor. 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. 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 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; 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 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. 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. 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: 6. Conclusão Figura 8. Demonstração da métrica obtida pelo framework JUnit 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. 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. Manaus, 25 a 27 de abril de 2013 10 ISSN 2238-5096 (CDR)