Chapitre 3 - Préconisations
3. Evolution des conventions au-delà de ce qui est nécessaire à la mise en conformité
As medições que são apresentadas a seguir, pertencem ao aplicativo e-SUS AB
Atividade Coletiva, desenvolvido com o processo de Integração Contínua e testes
automatizados. Nas tabelas 6 e 7, pode-se visualizar os resultados de medições de
picos de percentual da CPU do dispositivo e de memória RAM. Esses testes foram
aplicados no mesmo dispositivo e utilizando-se das principais telas do aplicativo.
Tabela 6 - Percentuais máximos de uso de CPU do e-SUS AB Atividade Coletiva
Tela Tentativa 1 Tentativa 2 Tentativa 3
ListaAtividadeActivity 60,9% 49,9% 48,5%
SelecionarCidadaosActivity 49,6% 49,8% 50,1%
LoginActivity 35% 47,7% 55,8%
CadastroCidadaoActivity 54,8% 47,1% 54% GrupoAtividadesActivity 46,4% 60% 54,7% SincroniaProgressoActivity 65% 65,1% 62,5% SelecionarProfissionaisActivity 63,3% 48,6% 54,4% SincronizacaoActivity 47,6% 42,4% 57,9% RevisaoFinalizadaActivity 54,9% 48,6% 58% CadastroServidorActivity 46,9% 51,2% 39,9% ChangeLogActivity 61,3% 62,4% 41,6% SelecionarLotacaoActivity 50% 50,9% 49,2% SobreActivity 40,7% 42,9% 44,4% AtividadesNaoFinalizadasActivity 47,5% 55% 50,5% AtividadesFinalizadasActivity 50,1% 44,7% 46,9%
Fonte: Compilação do autor
Tabela 7 - Percentuais máximos de uso de RAM do e-SUS AB Atividade Coletiva
Tela Tentativa 1 Tentativa 2 Tentativa 3
ListaAtividadeActivity 139,7MB 147,8MB 147,9MB SelecionarCidadaosActivity 226,3MB 229,1MB 235,3MB LoginActivity 139MB 127,3MB 247,1MB CadastroAtividadeColetivaActivity 185,1MB 205,9MB 262 MB CadastroCidadaoActivity 244,8MB 238,9MB 251MB GrupoAtividadesActivity 215MB 228,4MB 236,1MB SincroniaProgressoActivity 146,2MB 174,3MB 178,5MB SelecionarProfissionaisActivity 267,4MB 231,4MB 234,3MB SincronizacaoActivity 144,4MB 247,8MB 282,7MB RevisaoFinalizadaActivity 233MB 234,9MB 226MB CadastroServidorActivity 93,3MB 106,7MB 105,1MB ChangeLogActivity 137,8MB 245,5MB 213MB SelecionarLotacaoActivity 226MB 227,7MB 229MB SobreActivity 234,3MB 204MB 214,6MB
AtividadesNaoFinalizadasActivity 231MB 246,2MB 212,1MB AtividadesFinalizadasActivity 216MB 215,6MB 220,4MB
Fonte: Compilação do autor
Analisando os dados das medições de picos de uso de CPU e memória,
observa-se que a tela que mais consumiu recursos de CPU foi a
SincroniaProgressoActivity, com pico de 65,1% dentre as 3 tentativas de acesso. Na
imagem 29 é exibido um gráfico que mostra a medição de uma das três tentativas de
acesso a tela.
Figura 29 - Pico de uso de CPU do e-SUS AB Atividade Coletiva
Fonte: Compilação do autor
No quesito memória, o maior pico de uso foi de 282,7 MB da tela
SincronizacaoActivity. A figura 30 mostra a tentativa de acesso a tela que registrou
Figura 30 - Pico de uso de Memória RAM do e-SUS AB Atividade Coletiva
Fonte: Compilação do autor.
4 CONCLUSÃO
A literatura da área de qualidade de software recomenda fortemente o uso de
testes automatizados em projetos de software, afirmando que obtém-se muitos
ganhos após sua implementação. Nesse sentido, o foco principal desta pesquisa
aplicada foi o de mostrar ao leitor comparações de dois aplicativos mobile
desenvolvidos no Laboratório Bridge da Universidade Federal de Santa Catarina e o
impacto que os testes automatizados têm sobre a qualidade dos aplicativos.
Para alcançar o objetivo principal foi necessário, inicialmente, descrever as
ferramentas utilizadas para a organização do trabalho da equipe e no
desenvolvimento de código das novas implementações e testes automatizados.
Nesse sentido, foram apresentadas ferramentas que facilitam o trabalho através da
databases. Também foram apresentadas ferramentas de integração contínua, de
revisão automática de código e a plataforma Firebase, responsável pelo
armazenamento dos dados coletados para comparação dos aplicativos.
Foi descrito o fluxo de trabalho da equipe utilizando a metodologia ágil Scrum,
durante o desenvolvimento dos aplicativos e-SUS AB Território e e-SUS AB
Atividade coletiva, detalhando os papéis preconizados por essa metodologia. Dentro
das atividades de desenvolvimento, especificou-se como foram implementados os
testes automatizados unitários no aplicativo e-SUS AB Atividade Coletiva e como foi
configurado um servidor de Integração Contínua utilizado no seu desenvolvimento.
Por fim, foi detalhada a adição da API do Firebase no código dos aplicativos para a
coleta das informações de falhas, desempenho e usuários.
Ao se tratar de falhas, sabe-se que os problemas de estabilidade podem
comprometer a qualidade de uma aplicação. Falhas constantes podem afetar a
usabilidade e até influenciar na perda de dados cadastrados. Nos aplicativos
abordados neste estudo, os profissionais utilizam dispositivos fornecidos pelas UBS,
que na grande maioria dos casos possuem acesso à Internet somente pela rede wi-
fi. Nesse cenário, os profissionais realizam a sincronização com o servidor e enviam
suas produções diárias somente no final do dia, ou até mesmo ao final da semana.
Sendo assim, caso haja alguma falha no aplicativo que comprometa os dados
cadastrados, o profissional poderá perder toda sua produção diária ou até semanal.
Dentre as métricas coletadas, a de falhas é a que pode ser considerada como a
mais relevante, pois reflete diretamente o impacto que os testes automatizados
possuem sobre um projeto de software, uma vez que esses testes auxiliam na
mostraram uma redução considerável do número de falhas por usuário e na
quantidade de usuários afetados no aplicativo e-SUS AB Atividade Coletiva. Com
isso, pode-se afirmar que a aplicação desenvolvida com o uso de testes
automatizados chegou com melhor estabilidade para o usuário final.
A reputação de um aplicativo desenvolvido para mobile é medida através das
avaliações dos usuários na loja em que o mesmo está disponível para download.
Essa informação impacta diretamente na escolha do usuário: no caso de más
avaliações, o mesmo poderá optar por não utilizá-la e buscar outra aplicação que
corresponda às mesmas necessidades. Através da coleta das avaliações dos
usuários na loja Google Play Store, foi possível verificar uma reputação melhor para
o aplicativo e-SUS AB Atividade Coletiva, que apresenta um número de estrelas
superior em relação ao e-SUS AB Território.
Outro fator que pode levar aos usuários deixarem de usar uma aplicação é a
lentidão para acessar as suas funcionalidades e informações. Nesse sentido, foram
coletados dados através do módulo Firebase Performance, que mostra informações
de telas da aplicação que demoram tempo excessivo para inicializarem e serem
mostradas ao usuário. Em relação ao tempo de inicialização, o aplicativo e-SUS AB
Atividade Coletiva, desenvolvido com testes automatizados, obteve um melhor
desempenho, com menor tempo para tornar-se disponível ao usuário. Já nos dados
de tempo de renderização de todas as telas e frames congelados, o aplicativo e-
SUS AB Atividade Coletiva obteve pior desempenho nas renderizações de tela,
porém apresentou melhor desempenho quanto a presença de frames congelados,
ao contrário do aplicativo Território, que obteve menos problemas com renderização
Ainda nas análises de desempenho, foram coletados dados de uso de
memória RAM e CPU pelas duas aplicações, através das ferramentas Memory
Profiler e CPU Profiler, ambas da IDE Android Studio. Picos de uso dos recursos de
um dispositivo podem torná-lo indisponível e também causar falhas nos aplicativos
em uso. Destas métricas, concluiu-se que o aplicativo e-SUS AB Território obteve
vantagem, visto que utilizou uma menor quantidade de memória RAM e CPU nas
telas testadas. Sendo assim, o uso de testes automatizados e revisão automática de
código não mostrou melhora no desempenho da aplicação desenvolvida com esses
processos.
Para trabalhos futuros, pode-se sugerir que sejam realizadas comparações de
outros itens da ferramenta Profile da IDE Android Studio, como medições do uso de
rede. Também sugere-se coletar informações do Firebase de aplicações que
utilizem o Sistema Operacional iOS, ou para plataforma Web, uma vez que o
REFERÊNCIAS BIBLIOGRÁFICAS
[1] FIGUEIREDO, C. M. S.; NAKAMURA, E. Computação Móvel: Novas Oportunidades e Novos Desafios. UFMG. Belo Horizonte, p. 28. 2003.
[2] MAZLAN, M. A. Stress test on J2ME compatible mobile device. Innovations in Information Technology, IEEE, p. 1-5, 2006.
[3] ALMEIDA, C. Introdução ao teste de software. Linha de Código, 2010. Disponível em: <http://www.linhadecodigo.com.br/artigo/2775/introducao-ao-teste- de-software.asp>. Acesso em 03/06/2018.
[4] BRAZILIAN SYMPOSIUM ON SYSTEMATIC AND AUTOMATED SOFTWARE TESTING, 1., 2016, Maringá - Pr. AutoFun: An Automated Model-based Functional Testing Tool. New York, Ny, Usa: Acm, 2016. 10 p.
[5] GASPERIN, Carlos Alberto. Firebase: O que é e Como Funciona. Disponível em: <http://micreiros.com/firebase-o-que-e-e-como-funciona/>. Acesso em: 26 abr. 2019.
[6] BARTIÉ, Alexandre. Garantia da qualidade de software: As melhores práticas de engenharia de software aplicadas à sua empresa. 22. ed. Rio de Janeiro:
Elsevier, 2002.
[7] BASTOS, Anderson et al. Base de conhecimento em teste de software. 3. ed. São Paulo: Martins Fontes, 2012.
[8] LABORATÓRIO BRIDGE (Florianópolis) (Org.). Quem somos. 2016. Disponível em: <https://bridge.ufsc.br/quem-somos>. Acesso em: 15 jun. 2018.
[9] LABORATÓRIO BRIDGE (Florianópolis) (Org.). Portfólio. 2016. Disponível em: <https://bridge.ufsc.br/portfolio>. Acesso em: 06 jul. 2018.
[10] GOOGLE (Org.). E-SUS AD. 2018. Disponível em:
<https://play.google.com/store/apps/details?id=br.gov.saude.ad2>. Acesso em: 26 nov. 2018.
[11] GOOGLE. E-SUS AB Território. 2018. Disponível em: <https://play.google.com/ store/apps/details?id=br.gov.saude.acs>. Acesso em: 26 nov. 2018.
[12] BRASIL. DEPARTAMENTO DE ATENÇÃO BÁSICA. (Org.). Manual de Uso do
Sistema com Prontuário Eletrônico do Cidadão: PEC v2.2.0. 2017. Disponível
em: <http://dab.saude.gov.br/portaldab/esus/manual_pec_2_2/index.php? conteudo=capitulo7/capitulo7#h.3jr3lg2ejdmq>. Acesso em: 26 nov. 2018.
Florianópolis: Elsevier, 2013.
[14] LECHETA, R. R. Google Android - 3ª Edição: Aprenda a criar aplicações
para dispositivos móveis com o Android SDK. Novatec, 2013.
[15] OLIVER, E. A survey of platforms for mobile networks research”. ACM
SIGMOBILE Mobile Computing and Communications Review, v. 12, n. 4, p. 56-
63, 2009.
[16] ACKER, E. V.; WEBER, T. S.; CECHIN, S. L. Injeção de falhas para validar
aplicações em ambientes móveis. Workshop de Testes e Tolerância a Falhas,
2010.
[17] RAPOZA, J. First Class Mobile Application Performance Management. The Aberdeen Group, 2012. – Disponível em
http://info.soasta.com/rs/soasta/images/aberdeen-first-class-mobileapplication- performance-management.pdf, acessado em 10 de janeiro de 2019.
[18] PRADHAN, T. Mobile Application Testing. White Paper, 2011. – Disponível em
http://www.tcs.com/SiteCollectionDocuments/White%20Papers/Mobility_Whitepaper_ Mobile-Application-Testing_1012-1.pdf, acessado em 07 de fevereiro de 2019.
[19] SPINELLIS, Diomidis. Version control, part 1. IEEE Software, 22(5):107–107, 2005
[20] SPINELLIS, Diomidis. Version control, part 2. IEEE Software, 22(6):c3–c3, 2005.
[21] FOWLER, Martin and Matthew Foemmel. Continuous integration. Technical report, Thought-Works, 2006.
[22] BERG, Alan. Jenkins Continuous Integration Cookbook. Packt Publishing, Birmingham, 2012.
[23] Lakshitha de Silva and Dharini Balasubramaniam. Controlling software architecture erosion: A survey. Journal of Systems and Software, 85(1):132–151, 2012.
[24] FIORETTI, Marco. Jenkins Continuous Integration Server: An Essencial Development Tool. Disponível em:
<http://www.openlogic.com/wazi/bid/188132/Jenkins-Continuous-IntegrationServer- An-Essential-Software-Development-Tool > Acesso em 10 de fevereiro de 2019. [25] ALMEIDA, Lucas Mariano Galdino de. Minerando exceções Runtime não documentadas em bibliotecas Java a partir do GitHub: um estudo exploratório / Lucas Mariano Galdino de Almeida. - 2018.
_Jenkins>. Acesso em: 25 mar. 2019.
[27] GOOGLE. Firebase Crashlytics. Disponível em:
<https://firebase.google.com/docs/crashlytics?hl=pt-br>. Acesso em: 05 ago. 2019. [28] GOOGLE. Monitoramento de desempenho do Firebase. Disponível em: <https://firebase.google.com/docs/perf-mon?hl=pt-br>. Acesso em: 08 set. 2019. [29] GOOGLE. Criar um perfil de desempenho do seu app. Disponível em: <https://developer.android.com/studio/profile>. Acesso em: 10 set. 2019.
[30] GOOGLE. Inspecionar atividades de CPU com o CPU Profiler. Disponível em: <https://developer.android.com/studio/profile/cpu-profiler?hl=pt_br>. Acesso em: 12 set. 2019.
[31] GOOGLE. Ver as alocações de heap e memória do Java com o Memory
Profiler. Disponível em: <https://developer.android.com/studio/profile/memory-
profiler?hl=pt_br>. Acesso em: 15 set. 2019.
[32] SIMPÓSIO BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO, 26., 2015, Curitiba. Ferramenta de Apoio ao Ensino de Estimativa de Software com
Planning Poker. Curitiba: Cbie, 2015. 10 p.
[33] Mahnic, V. and Hovelja, T. (2011) “On using planning poker for estimating user stories”. Journal of Systems and Software, 85(9):2086 - 2095. Selected papers from 2011 Joint Working IEEE/IFIP Conference on Software Architecture (WICSA 2011).
[34] PINTO, Samuel Vieira; ARAÚJO, Marco Antônio Pereira. Análise comparativa
de ferramentas para testes em aplicativos Android. 2015. 20 f. TCC (Graduação)
- Curso de Sistemas de Informação, Centro de Ensino Superior de Juiz de Fora, Juiz de Fora, 2015.
[35] SÁ, Eduardo Corrêa de; SILVA, Rodrigo. Automação de teste para
dispositivos móveis e execução dos scripts de teste automatizados na nuvem.
2016. 91 f. TCC (Graduação) - Curso de Sistemas de Informação, Universidade do Sul de Santa Catarina, Florianópolis, 2016.
[36] NUNES, R. D. A implantação das metodologias ágeis de desenvolvimento
de software Scrum e Extreme Programming (XP): uma alternativa para
pequenas empresas do setor de tecnologia da informação. ForScience: revista
científica do IFMG, Formiga, v. 4, n. 2, e00117, jul./dez. 2016.
[37] FOWLER, Martin; FOEMMEL, Matthew. Continuous integration, 2006. URL http://www. martinfowler. com/articles/continuousIntegration. html, 2012.
[38] SONARQUBE Documentation. Disponível em:
[39] ARCHITECTURE and Integration. Disponível em:
<https://docs.sonarqube.org/latest/architecture/architecture-integration/>. Acesso em: 26 set. 2019.
[40] LIMITAÇÕES DIGITAIS, CAUSAS E CONSEQUÊNCIAS NA EFETIVIDADE DO USO DO SITE TRELLO NO PLANEJAMENTO ESTRATÉGICO DE UMA SECRETARIA DE EDUCAÇÃO A DISTÂNCIA DE UMA UNIVERSIDADE FEDERAL. Porto Alegre: Unirede, 26 fev. 2019.
[41] MOCKITO testes de unidade: Mockito: como isolar seus testes de unidade no Java. Mockito: como isolar seus testes de unidade no Java. Disponível em:
<http://www.codeatest.com/mockito-isolamento-testes-unidade/>. Acesso em: 28 set. 2019.
[42] DIEDRICH, Cristiano. Docker. Disponível em:
<https://www.mundodocker.com.br/o-que-e-docker/>. Acesso em: 30 set. 2019. [43] SILVA, Edna Lúcia, MENEZES, Estera Muszkat. Metodologia da pesquisa e
elaboração de dissertação. UFSC, 4 Edição. Florianópolis, 2005.
[44] GIL, Antônio Carlos. Métodos e técnicas de pesquisa social. 6. ed. - São Paulo: Atlas, 2008.
[45] NETO, Arilo. Introdução ao Teste de Software. Revista Engenharia de Software, Rio de Janeiro,v. 1, n.1, 2007. Disponível em: <
http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-teste-de- software/8035>. Acesso em 08 out. 2019.
[46] SOMMERVILLE, Ian. Engenharia de Software. 9a. Ed. São Paulo: Pearson Prentice Hall, 2011.
[47] WANG, S.; OFFUTT, J. Comparison of unit-level automated test generation
tools. In: Software Testing, Verification and Validation Workshops, 2009. ICSTW ’09.
International Conference on. [S.l.: s.n.], 2009. p. 210–219
[48] LAGES, D. S. Gestão de ti: Reportando de forma simples os resultados dos
testes. Engenharia de Software Magazine, p. 40–48, 2010. ISSN 1983127-7.
[49] GOOGLE. Activities. Disponível em:
<https://developer.android.com/guide/components/activities/>. Acesso em: 16 out. 2019.
[50] MASSOL, Vicente; HUSTED, Ted. JUnit em Ação. Rio de Janeiro: Ciência Moderna, 2005.
[51] Jenkins. Jenkins User Documentation. Disponível em: <https://jenkins.io/doc/>. Acesso em: 15 out. 2019
[52] LIMA, Jackson. O que é integração Contínua? 2018. Disponível em:
<https://blog.schoolofnet.com/o-que-e-integracao-continua/>. Acesso em: 20 out. 2019.
APÊNDICE A - ARTIGO
Análise comparativa do uso de testes automatizados de
software em um ambiente com Integração Contínua: Estudo
de caso do aplicativo e-SUS AB Atividade Coletiva
Fabricio Matos1
1Departamento de Informática e Estatística – Universidade Federal de Santa
Catarina(UFSC). Caixa Postal 476 – 88.040-900 – Florianópolis – SC - Brasil
Abstract. Automated testing is considered key to adding quality during
application development. Continuous Integration processes, with test automation, provide greater security for development teams to make code modifications. Therefore, this paper aims to compare two similar applications developed for the Android operating system, through stability metrics, startup times and rendering of the main screens and the use of device resources by the applications.
Resumo. Testes automatizados são considerados fundamentais para agregar
qualidade durante o desenvolvimento de aplicações. Processos de Integração Contínua, com automação de testes, fornecem uma maior segurança para as equipes de desenvolvimento efetuarem modificações no código. Nesse sentido, este trabalho tem como objetivo comparar dois aplicativos semelhantes e desenvolvidos para o sistema operacional Android, através de métricas de estabilidade, tempos de inicialização e renderização das principais telas e o uso de recursos do dispositivo pelas aplicações.
1. Introdução
A demanda por sistemas de informação cresce cada vez mais com o passar dos anos. Paralelo a isso, a complexidade dos sistemas também aumenta, devido a fatores como a melhoria do hardware, maior quantidade de informações para processar ou necessidade por softwares que tratam conteúdos multidisciplinares.
O crescente uso de dispositivos móveis, aliado a necessidade por informações, levou ao avanço tecnológico no desenvolvimento de aplicativos para as mais variadas funções, sejam elas para uso pessoal ou profissional, com o objetivo de facilitar a vida dos usuários, melhorando a comunicação, organização de tarefas e lazer.
Por existir uma facilidade cada vez maior para o acesso a informações, independente do lugar e momento em que o usuário encontre-se, a quantidade de novas aplicações e serviços deverá ser maior com o passar do tempo. Para a construção de novas aplicações e serviços de computação móvel, existe uma grande variedade de ambientes e ferramentas que auxiliam uma equipe de desenvolvimento nesse processo
[1], sendo imprescindível a atividade de teste de software para garantir uma melhor qualidade dos produtos e serviços.
O teste manual de software é uma tarefa sujeita a erros, uma vez que o testador precisa, além de executar testes das novas funcionalidades, também repetir os testes das que já existem no sistema após estas serem implementadas, o que torna essa uma tarefa monótona e que pode fazer com que o profissional adquira uma confiança excessiva, deixando de testar adequadamente.
Nesse sentido, entram os testes automatizados, que realizam essas tarefas de forma automática, com frequência de execução estipulada pela equipe e utilizando-se de boas práticas de projeto. Bartié (2002) afirma que os testes automatizados são a utilização de ferramentas de testes que possibilitam simular cenários ou atividades humanas de forma a não requerer procedimentos manuais no processo de execução dos testes. O autor ainda conclui que a automação exige um esforço inicial de criação, porém possibilita entregar um produto com maior confiabilidade quando comparado com procedimentos manuais [2].
Por ser oneroso, muitas empresas ainda deixam de investir recursos de forma adequada na área de qualidade, principalmente em testes automatizados, fazendo com que seus produtos sejam entregues com baixa qualidade ou que não atendam aos requisitos especificados pelo cliente.
O objetivo deste trabalho é realizar um estudo comparativo do uso de testes automatizados em um projeto de software, detalhando o ciclo de vida de desenvolvimento de um aplicativo pela equipe mobile do Laboratório Bridge, da Universidade Federal de Santa Catarina, dando ênfase no processo de automação dos testes em ambiente de desenvolvimento ágil com integração contínua, e comparar com outro aplicativo semelhante, desenvolvido sem o uso de testes automatizados.
O estudo de caso deseja mostrar a diferença, em quantidade de falhas e desempenho de um aplicativo desenvolvido com testes automatizados comparado com outro, desenvolvido somente com testes manuais e sem nenhuma automação.
2. Fundamentação Teórica 2.1 Teste de software
Testar é a atividade que realiza a verificação e a validação do software, sendo que a maioria dos testes são realizados para o processo de verificação, restando poucas atividades para o teste de validação[3].
Segundo Bartié (2002), a atividade de testar não deve ser somente atrelada a um conjunto de cenários “positivos” básicos e com o objetivo de provar que as coisas funcionam. Ela deve também estender-se aos cenários “negativos e positivos estendidos”, sendo o analista de testes responsável por elaborar tais cenários estendidos[2].
Conforme Sommerville (2011), o teste tem como finalidade mostrar que um programa faz o que é proposto a fazer e para descobrir defeitos em um programa antes
do seu uso [4]. O autor afirma que os testes devem ser aplicados em três etapas: testes de release, de usuário e de desenvolvimento. Testes de relase são aqueles realizados pela equipe de qualidade após a geração de um release, enquanto que os testes de usuário são feitos através de possíveis entradas e conselhos relatados pelos usuários finais da aplicação. Os testes de desenvolvimento são aqueles executados pela equipe de desenvolvimento, e podem ocorrer em três níveis:
Teste unitário: possui a finalidade de testar as unidades individuais do programa, e devem ser automatizados sempre que possível;
Teste de componentes: também conhecido como testes de integração, consiste em integrar várias unidades individuais e criar componentes para serem testados; Teste de sistema: testes aplicados no sistema como um todo, após a integração