Aula 05

Prévia do material em texto

TESTES DE APLICATIVOS 
MÓVEIS 
AULA 5 
 
 
 
 
 
 
 
 
 
 
 
 
 
Prof. Felipe Pedroti Raymundo 
 
 
2 
CONVERSA INICIAL 
Bem-vindo a mais uma etapa sobre testes em aplicativos móveis. Já 
conhecemos vários conceitos relacionados ao assunto e também observamos 
diversas vertentes e tipos de testes de software diferentes que podemos realizar 
em um aplicativo (alguns até exclusivos dos aplicativos). 
Porém, até agora nosso trabalho foi todo manual na maioria das vezes, 
desde o planejamento até a execução desses testes, analisando os resultados 
e aplicando mudanças onde for necessário. Aqui, fica a dúvida: será que não 
existe jeito mais prático e rápido de realizá-los, principalmente os que envolvem 
uma interação com a interface gráfica do nosso aplicativo? 
Nesta etapa, vamos conversar e entender como automatizar esses testes 
nos aplicativos, partindo dos conceitos iniciais até conhecer ferramentas e 
frameworks responsáveis por isso. Para finalizar, vamos entender os ambientes 
nos quais eles são executados, dentro de um processo que ficou mais conhecido 
ou que teve maior relevância nos últimos anos. 
Figura 1 – DevOps 
 
Créditos: ZinetroN/Shutterstock. 
TEMA 1 – TESTES AUTOMATIZADOS 
Vimos, anteriormente, que todos os testes que aprendemos e realizamos 
devem ser executados de forma manual. Um teste unitário, por exemplo, era feito 
 
 
3 
pelo próprio programador dentro do projeto, validando um código 
independentemente de qual fosse. Uma interface deveria ser testada por alguém 
para poder confirmar se um toque em um botão executa a ação necessária para 
o qual ele foi configurado. 
Isso faz com que o processo de testar um software tenha um pequeno 
gargalo no tempo de entrega, pois alguém vai ter que validar isso antes de 
passar à próxima fase. Para que isso seja minimizado, existe o que chamamos 
de automatização dos testes. Uma dica importante: guarde bem essa palavra, 
pois nem tudo pode nem deve ser automatizado. 
1.1 Automatizar um teste 
De acordo com o Dicionário Brasileiro da Língua Portuguesa Michaelis 
([s.d.]), automatizar significa “tornar automático (um sistema, linha de produção, 
um atendimento bancário, telefônico etc.) por meio de máquinas ou dispositivos 
eletrônicos”. Isso significa que automatizar um teste de software é fazer com que 
ele seja executado por um software e/ou framework de modo autônomo, sem 
necessidade de uma interação direta a ele, auxiliando na revisão e validação de 
um software. 
Rehkopf ([s.d.]) diz que “o teste automatizado coloca as responsabilidades 
de propriedade nas mãos da equipe de engenharia”. Não entendamos como 
transferir a tarefa dos testes para outra equipe que não a de garantia da 
qualidade, mas sim facilitar seu trabalho. Os planos de teste são desenvolvidos 
normalmente no processo e depois delegados a ferramentas que vão executar 
esses scripts. Isso faz com que a equipe de qualidade seja mais enxuta e foque 
os pontos mais importantes. 
1.2 Qual é a importância de automatizar os testes? 
Se pensarmos em um ambiente de entrega contínua, no qual a liberação 
de novas versões deve ser feita da forma mais rápida possível, o teste 
automatizado é fundamental, pois não existe automação de entrega se houver 
uma etapa manual de teste. 
A entrega contínua faz parte de um processo maior, a integração contínua. 
Os testes automatizados são executados por essa camada de integração, 
fazendo a garantia da qualidade e checando se as alterações inseridas não 
 
 
4 
quebram funcionalidades e se novos bugs surgem. Somente depois de todos os 
forem bem-sucedidos, a camada de entrega é acionada. 
1.3 O que automatizar? 
Podemos até pensar “partiu automatizar tudo”, mas será que realmente 
devemos fazer isso? Vimos que muitas coisas podem ser automatizadas, mas 
nem tudo deve ser (ou melhor, pode ser) feito por ferramentas. Portanto, vamos 
priorizar os tipos de testes que devem ser automatizados de forma que 
aproveitemos os resultados de maneira satisfatória. 
Começaremos com os testes de ponta a ponta, que simulam uma 
experiência no nível de usuário de uso do software como um todo. Juntamente 
com seu planejamento, eles abrangem ações no nível de usuário do tipo: 
“usuário pode fazer login”, “usuário pode comprar um produto” ou “usuário altera 
configurações”. Isso permite que a garantia de qualidade seja mantida e que o 
cliente não receba um produto com bugs ou outros problemas devido a novas 
adições de código. 
Para esse fim há ferramentas de teste ponta a ponta que capturam e 
reproduzem ações feitas por usuários no aplicativo, de modo que os planos de 
teste sejam reproduções desse passo a passo capturado, em que o valor maior 
a ser agregado ao processo é quando esses testes validam fluxos mais críticos 
do software. Por outro lado, esses testes agregam um custo maior ao projeto, 
principalmente na fase de criação e gravação dos planos de testes; portanto, 
vale avaliar se não é mais vantajoso ter uma equipe humana trabalhando neles. 
O segundo tipo de teste que deve ser priorizado é são os unitários. Já 
vimos que eles validam uma unidade de código (ou função, como alguns autores 
gostam de chamar), usado para confirmar que uma entrada produz uma saída 
correta correspondente, e a automação deles não agrega um valor considerável 
ao projeto, sendo baratos e de implementação rápida (algumas vezes já até 
implementados se a metodologia utilizada priorizar o Test Driven Development 
– ou TDD), proporcionando um alto retorno. 
Há ainda os testes de integração, que simulam e validam a integração da 
base de código do projeto em questão com outros softwares ou serviços 
externos, em que não temos o controle do que está sendo executado. São, em 
parte, semelhantes aos testes unitários quando relacionamos as ferramentas e 
a forma como são implementados; além disso, podem ser uma alternativa mais 
 
 
5 
em conta se comparados aos de ponta a ponta, porém o custo deles é 
questionável quando já existem planos de testes ponta a ponta combinados com 
os unitários. 
Por fim, temos os testes de desempenho. Relembramos que, quando 
usados no conceito de software, servem para descrever a velocidade, a 
capacidade de processamento e a resposta dele. Podemos entender como 
métricas de desempenho o tempo para carregar uma página e também o tempo 
para processar um cálculo ou relatório complexo. Esses testes vão criar 
parâmetros de comparação para os casos citados. Os testes automatizados 
asseguram que esses parâmetros estejam sempre constantes e que qualquer 
nuance ou modificação desses valores serão notificados à equipe. 
1.4 O que não automatizar? 
Aqui adentramos em um ponto que para alguns pode ser altamente 
discutível. E não é para menos, pois automatizar uma rotina ou plano de teste 
gera um ganho de valor enorme se comparado à execução manual de algumas 
tarefas; porém, há momentos em que os resultados e ganhos não valem tanto a 
pena quanto um teste manual. 
Vamos citar primeiro os testes exploratórios. Automatizar um teste 
significa criar um script de execução e segui-lo do início ao fim, validando cada 
etapa com os resultados esperados. Os testes exploratórios não utilizam essa 
lógica, muitas vezes alteram passos desses scripts visando detectar falhas no 
fluxo como um todo. Apesar de existirem ferramentas que fazem esse tipo de 
trabalho, nada melhor do que a própria criatividade do ator de garantia de 
qualidade para tentar “quebrar” o software que está testando. 
Os testes de regressão visual também podem ser feitos manualmente. 
Isso ocorre quando há alguma quebra na interface do software para o usuário, 
envolvendo desde alinhamentos a elementos mal posicionados. Assim como 
ocorre com os testes exploratórios, existem ferramentas de captura e análise de 
imagens para comparar estados e fazer as validações, porém isso impõe um 
custo muito alto ao projeto, e o olhar humano pode detectarisso rapidamente. 
 
 
 
6 
Figura 2 – Automatização de processos 
 
Créditos: Olivier Le Moal/Shutterstock. 
TEMA 2 – FERRAMENTAS PARA AUTOMATIZAÇÃO DE TESTES 
Até agora falamos sobre automatizar os testes, porém sabemos que 
“automatizar” significa delegar a alguma ferramenta ou sistema que execute 
esse processo sozinho e sem interferência externa. Dentre essas ferramentas 
existem tanto as gratuitas quanto as pagas (e caríssimas, diga-se de passagem), 
as antigas e as recém-chegadas ao mercado; cada uma delas apresenta 
características, formas de trabalho e personalizações únicas. 
Essa grande variedade traz certa dificuldade na hora de selecionar as 
mais adequadas para cada tipo de projeto. O maior problema é que não existe a 
certa; geralmente ela tem tudo para aquele trabalho, menos a funcionalidade “x” 
requerida. 
2.1 O que considerar na hora de escolher uma ferramenta? 
Para tornar os testes automatizados eficazes e, além de tudo, rentáveis 
ao projeto, podemos seguir alguns passos para definir o que levar em conta na 
hora de selecionar uma ferramenta para esse fim. Primeiramente, devemos ter 
e mente o software e o projeto que estamos trabalhando para determinar os 
 
 
7 
testes que serão automatizados. Não é uma decisão que deve ser feita com base 
no fato de que “ferramenta A é melhor” ou “ferramenta B é gratuita”; temos que 
verificar o que necessitamos automatizar para ter um norte do que precisaremos. 
Em segundo lugar, os requisitos dos testes automatizados precisam estar 
bem formulados para que possamos nos apropriar das ferramentas disponíveis 
e alinhar cada uma aos objetivos. Estudar aquelas que estão à disposição e que 
façam a automatização dos testes é um terceiro passo, pois selecionar a mais 
adequada é mais fácil do que se basear na metodologia “acerto e erro”. Feito 
isso, discutir as escolhas com o time do projeto é a penúltima etapa, de forma 
que os motivos por que determinada ferramenta foi selecionada estejam bem 
claros, favorecendo o alinhamento de todos quanto às expectativas. Somente 
após tudo isso devemos efetivamente implementar e aplicar a automação. 
Figura 3 – Ferramentas automatizadas 
 
Créditos: Besjunior/Shutterstock. 
2.2 Tudo isso por um bem maior 
Pode até parecer que os passos que indicamos são executados sempre, 
mas grande parte dos projetos de software falham nessa hora. Isso gera 
dificuldades e problemas não apenas financeiros ao projeto, mas afeta as 
 
 
8 
equipes por causa de retrabalho e reestruturação. Por que tais passos são tão 
necessários? 
Imagine que hoje em dia há muitos tipos diferentes de computador, bem 
como inúmeros dispositivos móveis que, em alguns casos, superam um 
computador pessoal, tanto em suas características e formas quanto condições 
de interação. Portanto, tais dispositivos exigem aplicativos móveis que diferem 
dos comuns vistos no desktop, e encontrar uma ferramenta que se encaixe 
perfeitamente a todos os tipos de aplicativo é realmente impossível. 
Vamos conhecer a seguir ferramentas que podemos utilizar nos mais 
variados tipos de aplicativos para as principais plataformas de desenvolvimento 
existentes no mundo mobile, Android, iOS e desenvolvimento híbrido. 
TEMA 3 – FERRAMENTAS DE AUTOMAÇÃO PARA ANDROID 
Primeiramente, vamos olhar para as ferramentas disponíveis no ambiente 
Android, por ser um dos mais utilizados atualmente e o que tem maior gama de 
variedade de aparelhos compatível. 
3.1 Robotium 
Robotium foi uma das primeiras e mais utilizadas ferramentas para 
automatização suportadas pelo Android. Gratuita, é empregada em testes de 
interface e recomendada para automação de testes em diversas versões; muitos 
até a comparam com o Selenium (ferramenta para teste automatizado na web) 
para Android. Os testes são escritos em Java, mas a desvantagem é de que a 
necessidade de se trabalhar com código-fonte para automatizar os testes 
demanda muito tempo e esforço. Além disso, é inadequada para interação com 
o sistema em geral, e não pode, por exemplo, bloquear e desbloquear o sistema. 
 
 
 
 
 
 
 
 
 
 
9 
Figura 4 – Robotium – Reprodução 
 
Fonte: Robotium. 
3.2 Robo 
Robo é uma ferramenta de teste integrada ao Firebase, serviço de 
aplicativos do Google, e analisa a estrutura da interface de usuário do aplicativo, 
simulando ações dele naquela interface. A ferramenta gera logs, screenshots e 
vídeos simulando as ações realizadas para evidenciar esses testes. 
Além disso, é possível criar scripts para customizar o que a ferramenta vai 
avaliar nos testes (chamado de crawls). Robo se baseia na API Android para 
executar os testes de interface, porém quando não é possível acessar essa API 
ou validar elementos que não sejam widgets-padrão do Android, ele utiliza outro 
framework chamado Monkey para poder validar as ações de interface. 
 
 
 
 
 
 
 
 
10 
Figura 5 – Tela do Firebase Robo Test 
 
Fonte: Sutanto, 2019. 
3.3 Espresso 
Espresso é um framework utilizado para fazer testes de interface de forma 
extremamente rápida, de fácil aprendizagem e que sejam confiáveis. É utilizado 
pelo Google para teste de interface, além de fazer parte do repositório de suporte 
do Android; é de fácil implementação e perfeito para testes do tipo caixa-preta. 
Por ser parte integrante do próprio framework do Android, é possível 
utilizar o Android Studio para gravar testes com o Espresso e depois utilizar os 
scripts criados (que por limitação do framework devem ser escritos em Java ou 
Kotlin) para reproduzir de forma automatizada as ações. Infelizmente, somente 
é compatível com o Android. 
 
 
 
11 
Figura 6 – Tela do Espresso Recorder 
 
Fonte: Developers, 2020. 
TEMA 4 – FERRAMENTAS DE AUTOMATIZAÇÃO PARA IOS 
4.1 Appium 
O Appium é um dos frameworks mais populares disponíveis para o iOS, 
que também pode ser utilizado para aplicações Android, funcionando em 
aplicações nativas, híbridas e web. É uma ferramenta open-source e também 
cross-platform, permitindo que o mesmo teste escrito para iOS funcione para 
Android pois este compartilha a API desenvolvida para isso. 
Para o iOS, a ferramenta utiliza os drivers de teste de UI nativos do iOS 
(que veremos adiante). Ela funciona por meio de um webserver, em que uma 
API é disponibilizada e os comandos são executados no aplicativo por estas 
chamadas REST, onde os retornos de sucesso e falha são registrados. 
 
 
 
 
 
 
 
12 
Figura 7 – Tela de uma das ferramentas GUI para o Appium 
 
4.2 XCTest / XCUITest 
O XCTest e o XCUITest são os dois frameworks nativos para automação 
de testes no iOS. O XCTest permite que os desenvolvedores escrevam testes 
de qualquer nível para os componentes da aplicação e disponibiliza um 
framework para que os testes de UI possam ser executados (XCUITest). 
O XCUITest geralmente é utilizado para criação de testes funcionais, 
automação de testes de fluxos, sequências de demonstração ou validação de 
fluxos de componentes visuais, oferecendo uma ferramenta de gravação desses 
testes para facilitar a criação e automatização deles. Os testes são escritos e 
compatíveis tanto com Objective-C quanto com Swift. 
 
 
 
13 
Figura 8 – Exemplo de teste escrito no iOS utilizando XCTests 
 
4.3 EarlGrey 
De certa forma, a comunidade trata o EarlGrey como sendo o “Espresso 
para iOS”. Também desenvolvido e tornado open-source pelo Google, é o 
framework de teste utilizado para teste dos aplicativos da gigante da web para 
iOS, como o Google Calendar, YouTube entre outros. Há muitas similaridades 
entre ele e o Espresso. 
Atualmente na versão 2.X.X, já integra recursos e API do XCUITest para 
facilitar a escrita dos testes. Pode ser utilizado nativamente com o XCode, 
podendo ser empregado para criar tanto testes de caixa-preta como de caixa-
branca. 
 
 
 
14 
Figura 9 – Exemplo de teste com EarlGrey 
 
TEMA 5 – AUTOMATIZAÇÃO + INTEGRAÇÃO CONTÍNUA= DEVOPS 
Para encerrar esta etapa, não temos como não tratar de automatização 
se não abordarmos integração contínua. Nos projetos de softwares atuais, muito 
se fala em ganhar tempo com integração e automatização, mas pouco sobre a 
relevância disso. 
Vamos imaginar o seguinte cenário: estamos em uma equipe de vários 
desenvolvedores que estão entregando features e correções a todo momento. 
Se um responsável ficasse designado por executar os testes, depois liberar a 
versão para testes e tudo o mais, isso gerando vários builds toda vez que uma 
nova tarefa fosse finalizada por alguém da equipe, essa pessoa já estaria louca 
faz tempo. Brincadeiras à parte, de um ambiente onde tudo isso seja feito 
sozinho e de forma implícita para o usuário surgem os ambientes de DevOps. 
5.1 O que é DevOps? 
O DevOps é um composto de Dev (desenvolvimento) e Ops (operações), 
portanto uma união de pessoas, processos e tecnologias para, de forma 
automática e contínua, fornecer valor aos interessados. Para as equipes de 
projetos de software, o DevOps faz com que as funções, que antes eram isoladas 
dentro das equipes de projeto, desenvolvimento, qualidade, infraestrutura etc., 
 
 
15 
se realizem de forma integrada, coordenada e colaborativa visando gerar 
artefatos de software de qualidade e confiáveis. 
Porém, o DevOps não é somente a adoção de tecnologias, ferramentas e 
processos voltados à automatização e otimização por meio de tecnologia, mas 
sim uma mudança de cultura da organização e dos colaboradores, para que 
quando comprometidos, criem um ambiente de alto desempenho. 
Várias práticas compõem um ambiente de DevOps e fazem com que se 
determine o ciclo de vida do aplicativo. A primeira delas é o que chamamos de 
Integração Contínua e Entrega Contínua (CI/CD), em que são utilizados meios 
de gerenciamento de estados e recursos a fim de que as equipes implementem 
alterações de maneira controlada e sistemática. A segunda faz referência ao 
controle de versão, que possibilita gerenciar código por meio de versionamento, 
acompanhando revisões e históricos de alterações para facilitar a revisão e a 
recuperação dele. Geralmente utiliza um controle de versão (como o Git), que 
permite colaboração de vários desenvolvedores no código, mas não fica restrita 
ao código-fonte. 
Outra prática aplicada nesses ambientes é a abordagem de 
desenvolvimento ágil, que enfatiza a colaboração da equipe, comentários dos 
interessados e alta capacidade de adaptação, propiciando mudanças, 
aprimoramentos e correções contínuos aos clientes. O Kanban e o Scrum são 
duas metodologias comuns nos ambientes de desenvolvimento ágil. 
Há ainda a prática de infraestrutura como código, em que recursos e 
topologias do sistema são definidos de maneira descritiva, permitindo que a 
gerência desses recursos seja feita como se as equipes os codificassem. Isso 
torna possível que essas definições sejam versionadas e possam ser revertidas 
e revisadas, ajudando as equipes a implantarem os recursos do sistema de 
maneira que seja confiável, reutilizável e controlável, o que vai auxiliar na 
automatização da implantação de ambientes. 
A penúltima prática diz respeito ao gerenciamento de configuração, termo 
conhecido dos processos de qualidade. Refere-se ao gerenciamento de estados 
de todos os recursos do software, incluindo os de infraestrutura. Aliados com a 
infraestrutura como código, tornam fácil automatizar e padronizar a definição e 
configuração de sistemas. 
Por último, temos a prática do monitoramento contínuo, que faz com que 
haja visibilidade total e em tempo real do desempenho e da integridade de toda 
 
 
16 
a infraestrutura de aplicativos, desde as estruturas mais internas que estão 
sustentando o aplicativo aos componentes de alto nível. Isso pode definir alertas 
e automatizações a serem executadas se algum parâmetro estiver fora do 
normal. 
5.2 E onde os testes automatizados entram? 
Com o DevOps, podemos dizer que os testes passam a ter 
responsabilidade compartilhada pela equipe, e a automação deles permite que 
os desenvolvedores lancem melhorias e correções mais rapidamente, tendo um 
respaldo na garantia da qualidade. Sabendo-se que os desenvolvedores são 
responsáveis por escrever testes de unidade e que profissionais da qualidade 
criam os testes de interface automatizados, isso vai validar uma solução de ponta 
a ponta. O ambiente e cultura de DevOps vai fazer com que esses testes sejam 
executados o quanto antes e com a maior frequência possível dentro do 
ambiente de CI/CD. Essa automação vai possibilitar que, sem a interação de 
ninguém, o próprio ambiente valide a solução conforme os padrões definidos 
pela equipe de forma autônoma – qualquer violação do padrão determinado vai 
ser comunicado à equipe de forma rápida e sem intervenção, além de garantir 
que um artefato de software com problema chegue ao cliente gerando calor e 
estresse desnecessário com um produto defeituoso. 
Portanto, o papel da qualidade no processo, que antes se concentrava 
principalmente nas atividades de testes (manuais na maioria dos casos), agora 
passa a permitir que esses profissionais dediquem mais tempo às funções 
estratégicas da qualidade. 
Os testes automatizados são considerados essenciais nas práticas de 
DevOps. Pode até parecer uma grande responsabilidade e que vai ser de difícil 
execução, porém após isso temos os seguintes benefícios disponíveis aos 
usuários: velocidade sem sacrificar qualidade, melhor colaboração da equipe, 
confiabilidade do produto, escala, segurança e satisfação do cliente. 
FINALIZANDO 
Nesta etapa, acompanhamos o processo de automação dos testes e os 
benefícios que traz para a equipe do projeto como um todo. Apesar de parecer 
 
 
17 
tentador, nem tudo pode e deve ser automatizado. Pudemos observar no Tópico 
1 o que podemos ou não automatizar e o porquê dessa postura. 
No Tópico 2, introduzimos o assunto das ferramentas de automatização 
de teste e os motivos que as tornam necessárias. No Tópico 3 e no Tópico 4 
aprendemos como proceder esses testes automatizados nos ambientes Android 
e iOS, respectivamente, e conhecemos algumas ferramentas e frameworks que 
podemos utilizar para fazer isso acontecer. Por fim, no Tópico 5 tratamos da 
cultura de DevOps e como ela está integrada aos testes automatizados com suas 
práticas. 
 
 
 
18 
REFERÊNCIAS 
AUTOMATIZAR. In: Dicionário Brasileiro da Língua Portuguesa Michaelis. 
[S.d.]. Disponível em: <https://michaelis.uol.com.br/moderno-
portugues/busca/portugues-brasileiro/automatizar/>. Acesso em: 9 fev. 2023. 
CRIAR testes de IU com o Espresso Test Recorder. Developers, 28 dez. 2020. 
Disponível em: <https://developer.android.com/studio/test/espresso-test-
recorder?hl=pt-br>. Acesso em: 9 fev. 2023. 
REHKOPF, M. Testes de software automatizados. Atlassian. [S.d.]. Disponível 
em: <https://www.atlassian.com/br/continuous-delivery/software-
testing/automated-testing#>. Acesso em: 2 out. 2022. 
SILVA, A. 5 melhores ferramentas de automação para testar aplicativos Android 
(Android App Testing Tools). LinkedIn, 26 fev. 2019. Disponível em: 
<https://www.linkedin.com/pulse/5-melhores-ferramentas-de-automação-para-
testar-android-alan-silva/?originalSubdomain=pt>. Acesso em: 5 nov. 2022. 
SUTANTO, M. Android Application Testing with Firebase Tobo Test. Medium, 22 
jul. 2019. Disponível em: <https://medium.com/wantedly-engineering/android-
application-testing-with-firebase-robo-test-c674e1754298>. Acesso em: 6 nov. 
2022. 
	Conversa inicial
	FINALIZANDO
	REFERÊNCIAS