AUTOMAÇÃO DE TESTES FUNCIONAIS NO PROCESSO DE FOTA DE DISPOSITIVOS MÓVEIS

Prévia do material em texto

Lauro de Freitas 
2016 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ISAIAS SANTOS SILVA 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
AUTOMAÇÃO DE TESTES FUNCIONAIS NO PROCESSO DE FOTA 
DE DISPOSITIVOS MÓVEIS 
 
Lauro de Freitas 
2016 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
AUTOMAÇÃO DE TESTES FUNCIONAIS NO PROCESSO DE FOTA 
DE DISPOSITIVOS MÓVEIS 
Trabalho de Conclusão de Curso apresentado 
à UNIME, como requisito parcial para a 
obtenção do título de bacharel em Sistemas de 
Informação 
 
Orientador: Prof. Jorge Farias, Equipe de 
Tutores - AVA 
 
ISAIAS SANTOS SILVA 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
SANTOS SILVA, Isaias. Automação de Testes Funcionais no Processo de FOTA 
de Dispositivos Móveis. 2016. 28. Trabalho de Conclusão de Curso de Sistemas 
de Informação – UNIME, Lauro de Freitas, 2016. 
 
RESUMO 
 
O desenvolvimento deste trabalho foi proposto com o objetivo de resolver e eliminar 
um problema na forma de execução de testes funcionais, durante o processo de 
teste da funcionalidade de FOTA em dispositivos móveis. FOTA é uma feature que 
tem por objetivo validar e testar todos os processos de atualização de software de 
dispositivos móveis, antes, durante e após a sua atualização. Para isso, a atividade 
de customização foi automatizada, resolvendo assim problemas de preenchimento 
manual da checklist, passível de erro do participante e diante da criticidade e 
importância desta feature para o cliente. A automação de testes funcionais foi 
realizada através de uma ferramenta proprietária denominada ATS e aplicada ao 
contexto de uma grande fabricante coreana de dispositivos móveis em atuação no 
Brasil. Para fundamentar o tema, pesquisas bibliográficas sobre teste de software e 
automação foram realizadas e as boas práticas do Syllabus e AQuA foram seguidos. 
Através da prova de conceito realizado em um laboratório de teste independente, foi 
provado que ganhos em tempo, produtividade e qualidade no software pode ser 
obtido através da automação. 
 
Palavras-chave: Teste de software; testes automatizados; Qualidade de software; 
automação; caixa preta. 
 
 
 
 
 
 
 
 
 
 
 
 
SANTOS SILVA, Isaias. Functional Test Automation in the Process FOTA of 
Mobile Devices. 2016. 28. Conclusion Work of Information Systems Course - 
UNIME, Lauro de Freitas, 2016. 
 
ABSTRACT 
 
The development of this work was proposed with the objective of solving and 
eliminating a problem in the execution of functional tests, during the process of 
testing FOTA functionality in mobile devices. FOTA is a feature that aims to validate 
and test all software update processes for mobile devices before, during and after 
their upgrade. For this, the customization activity was automated, thus solving 
problems of manual filling of the checklist, subject to error of the participant and 
before the criticality and importance of this feature for the client. The automation of 
functional tests was performed through a proprietary tool called ATS and applied to 
the context of a large Korean manufacturer of mobile devices operating in Brazil. To 
support the theme, bibliographic research on software testing and automation was 
carried out and the good practices of Syllabus and AQuA were followed. Through the 
proof of concept carried out in an independent test laboratory, it was proved that 
gains in time, productivity and quality in the software can be obtained through 
automation. 
 
Keywords: Software testing; automated testing; Software quality; automation; black 
box. 
 
LISTA DE FIGURAS 
FIGURA 1 - CUSTO DOS DEFEITOS COM PASSAR DO TEMPO DO PROJETO ........................... 14 
FIGURA 2 - MODELO CAIXA PRETA ............................................................................... 17 
FIGURA 3 - MODELO DE CAIXA BRANCA ......................................................................... 19 
FIGURA 4 - PROCESSO DE FOTA .................................................................................. 26 
FIGURA 5 - REPORT ISSUE - FACEBOOK AND TWITTER APP DISAPPEAR ............................. 30 
FIGURA 6 - REPORT ISSUE - VULNERABILITIES ................................................................ 30 
FIGURA 7 - ERROR DURING INSTALLATION ...................................................................... 30 
FIGURA 8 - FRAGMENTAÇÃO DO ANDROID ...................................................................... 34 
FIGURA 9 - EXEMPLO CASO DE TESTE - REMOVE TO BATTERY ......................................... 36 
FIGURA 10 - ATS VERSÕES .......................................................................................... 37 
FIGURA 11 - ATS CONNECTIVITY PANEL ........................................................................ 38 
FIGURA 12 - ATS TEST MANAGER ................................................................................ 39 
FIGURA 13 - AMOSTRAS SELECIONADAS ........................................................................ 40 
FIGURA 14 - ATS CUSTOMIZATION ................................................................................ 41 
FIGURA 15 - ATS SCENARIO ALARM.............................................................................. 42 
FIGURA 16 - ATS COMANDOS ....................................................................................... 42 
FIGURA 17 - ATS AFTER AUTOMAÇÃO ........................................................................... 45 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
https://d.docs.live.net/1f382d5ade128170/TCC%202016.2/AUTOMAÇÃO%20DE%20TESTES%20FUNCIONAIS%20NO%20PROCESSO%20DE%20FOTA%20DE%20DISPOSITIVOS%20MÓVEIS.doc#_Toc474086316
 
 
 
 
 
 
 
LISTA DE GRÁFICOS 
GRÁFICO 1 - COMPARATIVO TEMPO GASTO POR PARTICIPANTE ........................................ 53 
GRÁFICO 2 - COMPARATIVO TEMPO GASTO ADDWIFI PELOS PARTICIPANTES. .................... 54 
GRÁFICO 3 - OPINIÃO DOS PARTICIPANTES SOBRE AS ATIVIDADES .................................... 55 
GRÁFICO 4 - OPINIÃO DOS PARTICIPANTES SOBRE O NÍVEL DE ATITUDE ............................ 56 
GRÁFICO 5 - OPINIÃO - SATISFAÇÃO DO PARTICIPANTE POR AMOSTRA .............................. 57 
 
 
LISTA DE TABELAS 
TABELA 1 - CLASSIFICAÇÃO DE DISPOSITIVOS MÓVEIS .................................................... 33 
TABELA 2 - CARACTERÍSTICAS AMOSTRAS ...................................................................... 40 
TABELA 3 - QUANTIDADE DE CASOS DE TESTE POR FUNCIONALIDADES .............................. 48 
TABELA 4 - PASSOS PARA EXECUÇÃO DOS TESTES POR TIPO ........................................... 49 
TABELA 5 - CRONOGRAMA DE TESTES ........................................................................... 50 
TABELA 6 - TEMPO DE CUSTOMIZAÇÃO POR AMOSTRA .................................................... 50 
TABELA 7 - TEMPO DE EXECUÇÃO MANUAL POR PARTICIPANTE ......................................... 51 
TABELA 8 - TEMPO DE EXECUÇÃO AUTOMATIZADA POR PARTICIPANTE .............................. 52 
TABELA 9 - COMPARAÇÃO TEMPO MANUAL X AUTOMATIZADO ......................................... 54 
TABELA 10 - ERROS NA CUST SINALIZADOS PELO CLIENTE .............................................. 59 
 
 
LISTA DE SIGLAS 
APN ACCESS POINT NAME 
ADT ANDROID DEVELOPMENT TOOLS 
ATS AUTOMATED TEST SYSTEM 
CTFL CERTIFIED TESTER FOUNDATION LEVEL 
ETA EMBEDDED TEST AGENT 
FOTA FIRMWARE OVER THE AIR. 
GDMS GLOBAL DEALER MANAGEMENT SYSTEM 
GUI GRAPHICAL USER INTERFACE 
IDE INTEGRATED DEVELOPMENT ENVIRONMENT 
IMEI INTERNATIONAL MOBILE EQUIPMENT IDENTITY 
ISQTB INTERNATIONAL SOFTWARE TESTING QUALIFICATIONS 
BOARD 
LGUP LG ELECTRONICS UPLOAD 
OS OPERATION SYSTEM 
QA 
 
RST 
QUALITY ASSURANCE 
 
STRATIFIED RANDOM TEST 
USB UNIVERSAL SERIAL BUS 
 
 
 
 
 
 
 
 
 
 
SUMÁRIO 
 
INTRODUÇÃO ............................................................................................................9 
1.1 APRESENTAÇÃO DO TEMA ......................................................................... 11 
1.2 PROBLEMA .................................................................................................... 11 
1.3 OBJETIVO ...................................................................................................... 12 
1.3.1 Objetivos Específicos .............................................................................. 12 
FUNDAMENTAÇÃO TEÓRICA ................................................................................ 13 
2.1 A IMPORTÂNCIA DE TESTAR UM SOFTWARE ........................................... 13 
2.2 TESTES FUNCIONAIS ................................................................................... 15 
2.2.1 Teste de Caixa Preta (black box) .......................................................... 16 
2.2.2 Teste de Aceitação ................................................................................ 17 
2.2.3 Teste de Regressão ............................................................................... 18 
2.3 TESTES NÃO FUNCIONAIS .......................................................................... 18 
2.3.1 Teste de Caixa Branca (white box) ...................................................... 18 
2.3.2 Teste de Desempenho/Performance .................................................... 19 
2.3.3 Teste de Carga ........................................................................................ 20 
2.3.4 Teste de Stress ...................................................................................... 20 
2.3.5 Teste de Segurança ............................................................................... 20 
2.3.6 Teste de Portabilidade .......................................................................... 21 
2.4 AUTOMAÇÃO DE TESTE .............................................................................. 21 
2.4.1 Quando Não Automatizar? ................................................................... 22 
2.4.2 Dificuldades no Processo de Automação dos Testes ....................... 22 
2.4.2 Técnicas de Automação de Software .................................................. 23 
FOTA (FIRMWARE/SOFTWARE OVER THE AIR) .................................................. 25 
3.2 TIPOS DE FOTA ............................................................................................... 26 
3.3 VANTAGENS E DESVANTAGENS DO FOTA ........................................................... 28 
3.4 PRINCIPAIS BUGS DE FOTA ............................................................................... 29 
AUTOMAÇÃO DE TESTES FUNCIONAIS NO PROCESSO DE FOTA .................. 32 
4.2 TESTES EM DISPOSITIVOS MÓVEIS ...................................................................... 32 
4.3 VISÃO GERAL ................................................................................................... 32 
4.4 AMBIENTE DE TESTE ......................................................................................... 33 
4.5 CRITÉRIOS DE TESTE EM DISPOSITIVOS MÓVEIS .................................................. 34 
4.6 FERRAMENTA UTILIZADA .................................................................................... 36 
4.7 PROVA DE CONCEITO (AUTOMAÇÃO) ................................................................... 39 
ESTUDO DE CASO .................................................................................................. 47 
5.2 SELEÇÃO DOS PARTICIPANTES ........................................................................... 47 
5.3 MÉTRICAS ........................................................................................................ 47 
5.4 ANÁLISE E EXECUÇÃO DO ESTUDO ...................................................................... 48 
5.4.1 Análise Quantitativa ................................................................................. 49 
5.4.2 Análise Qualitativa ................................................................................... 55 
RESULTADOS .......................................................................................................... 58 
CONCLUSÃO E TRABALHOS FUTUROS .............................................................. 61 
REFERÊNCIAS ......................................................................................................... 63 
 9 
INTRODUÇÃO 
Nos dias atuais os dispositivos móveis têm obtido sucesso de vendas 
quando comparados com computadores de mesa (desktops) e notebooks. São 
diversos modelos de aparelhos celular e tablets lançados, acompanhados das mais 
novas versões dos softwares (Android, iOS e Windows Phone), funcionalidades e 
recursos. Um aparelho lançado há dois anos, já pode ser considerado velho e 
defasado, uma vez que novas implementações de melhorias, correções de bugs ou 
path de segurança no software são realizados e disponibilizados aos usuários. 
Aplicativos são lançados e baixados constantemente e a alta concorrência no mundo 
mobile tem agradado ao público de uma forma extraordinária, tornando a aquisição 
de dispositivos algo quase que obrigatório. 
Para chegar a esse nível de gratidão, centenas e milhares de defeitos no 
software são encontrados, analisados e corrigidos. É bastante comum os usuários 
encontrarem defeitos e bugs durante a utilização do seu dispositivo. Mas a maioria 
destes bugs são classificados como baixo impacto devido ao pouco impacto que ele 
irá causar em outros módulos do software. Um erro no aplicativo de calculadora por 
exemplo não irá impactar o uso de outros aplicativos utilizados pelo usuário, porém 
um erro no aplicativo de chamadas, no volume das músicas ou vídeos, sons, tela e 
no processo de atualização do software (FOTA) que podem inviabilizar o uso do 
dispositivo e estressar o usuário. Um bug crítico de FOTA pode fazer com que o 
usuário acione a assistência técnica do aparelho, podendo tornar o aparelho 
inutilizável devido a sua não inicialização, ficar em loop de reinicio, apresentar 
crashes e tornar o uso do aparelho como algo desagradável. Softwares não testados 
ou mal testados são propícios para causar problemas financeiros, manchar a 
reputação da empresa e a integridade física do usuário. É durante os testes que os 
principais bugs são encontrados. 
Quando um bug é encontrado e reportado para correção por parte da equipe 
de desenvolvimento, novas versões do software é lançada com as devidas 
correções e assim um novo ciclo de teste é iniciado para validar os bugs reportados 
anteriormente e outros que possam surgir ou não identificados na fase anterior. 
Casos de testes, checklists, testes exploratórios dentre outros devem ser executados 
para cobrir o máximo de cenários possíveis em um software. 
 10 
Uma outra alternativa para a identificação de falhas no software é através da 
automação de teste. A automação do teste é quando uma atividade realizada 
manualmente é repassada e programada em um computador para que este possa 
realiza-la automaticamente. A automação dos testes funcionais é realizada através 
de uma ferramenta na qual scripts são desenvolvidos para automatizar a interface do 
dispositivo, simulando assim as ações do usuário. 
A automação de teste realizada neste trabalho consiste na criação de scripts 
ou códigos que identifique os valores defaults ou originais do dispositivo móvel a ser 
testado e alimente uma planilha excel com tais valores; em seguida o script deve 
efetuar uma modificação em todos os valores encontrados anteriormente para outros 
valores quaisquer, simulando assim uma customização realizada pelo usuário. Após 
a atualização é necessário que o script verifique através de uma análise comparativa 
se os valores foram modificados ou se permaneceram. Portanto, justifica-se a 
automação de atividades simples e repetitivas, onde o participante passa a focar e 
dedicar-se a execução de outras atividades de tomada de decisão e na realizaçãode casos de testes mais críticos e de alta prioridade. 
Para que o objetivo deste trabalho fosse alcançado algumas etapas 
precisaram ser superadas. Na primeira etapa foi realizado um estudo sobre teste de 
software funcionais e não funcionais e, suas principais técnicas, processos e 
metodologias que possam auxiliar, embasar e instruir o participante na identificação 
do bug. Foram buscados na internet artigos, dissertações, teses e cases de sucesso 
sobre teste e automação de software. O livro base de conhecimento de teste de 
software de Aderson Bastos, Emerson Rios, Ricardo Cristalli e Trayahú Moreira foi 
fundamental para iniciação deste trabalho e o mesmo é utilizado como a principal 
base de consultas. Como fruto da pesquisa, aprendizado e execução diária dos 
testes uma certificação internacional CTFL foi obtida, corroborando ainda mais com 
os conhecimentos adquiridos. Além disso cursos, workshops e palestras 
relacionadas ao tema foram acompanhadas. Todos os testes foram executados no 
maior laboratório de teste de software da américa latina de uma grande fabricante 
sul coreana de dispositivos móveis e um know-how entre diversos outros 
participantes de teste foi possível para o enriquecimento deste trabalho. (ISQTB, 
2016) 
Na segunda etapa deste trabalho é explicado o que é FOTA e detalhado 
todo seu processo de teste. Na terceira etapa dois casos de teste de automação 
 11 
foram realizados, objetivando-se demonstrar como foi feito todo o processo de 
automação desta feature aplicada a dispositivos móveis. Uma coleta e análise de 
métricas aplicadas no estudo de caso corroboram na comparação entre a execução 
do teste manual e automatizado. Pretende-se no dia da defesa desta monografia 
demonstrar a automação realizado pelo PC e realizada no dispositivo móbile. 
Por fim, o êxito deste trabalho está relacionado na aplicação das técnicas de 
testes de software por meio da automação de processos que mantenham a 
qualidade do produto, minimizem erros e tragam ganhos de tempo e produtividade 
para a organização e conhecimento e satisfação para o autor deste trabalho. 
1.1 APRESENTAÇÃO DO TEMA 
O tema proposto é um estudo do processo de teste da funcionalidade FOTA 
(firmware-over-the-air) em dispositivos móveis seguindo os padrões e técnicas de 
testes que mantenham a qualidade do software. Pretende-se responder e comparar 
o esforço e tempo gasto para testar um software de forma manual. Como hipótese 
inicial levantada questionou-se alguns processos e ou funcionalidades podem ser 
automatizados. Neste sentido, o ganho de tempo e produtividade entre o teste 
automatizado em relação ao manual pode ser percebível. 
1.2 PROBLEMA 
No mundo mobile, existe uma funcionalidade utilizada por diversas 
fabricantes de smartphones e tablets, denominada de FOTA, na qual diversos 
processos são executados para testar e validar essa funcionalidade. Devido à alta 
criticidade desta feature e de seus diversos processos os testes são executados no 
dispositivo e os resultados obtidos são inseridos em uma planilha do excel. Esses 
valores são preenchidos durante três momentos distintos do teste: 
 Preencher o valor default encontrado no dispositivo; 
 Simular a customização (Customization) realizada pelo usuário, 
modificando valores default para outros valores quaisquer; 
 Efetuar o processo de FOTA, inserir e checar se os valores 
personalizados pelo usuário permaneceram ou se sofreram modificações 
após o FOTA. 
 12 
Esse processo manual de anotar valores na planilha apesar de simples e 
bastante repetitivo, tornou essa atividade extremamente desgastante e suscetível a 
erro inerentes ao ser humano como: humor, memória, capacidade de concentração, 
relacionamento e saúde física pode influenciar negativamente na qualidade do 
produto ou na inserção de valores errados ou diferente do esperado. Outro fator 
negativo é o incremento de novas funcionalidades passiveis de customização ao 
longo do lançamento das novas versões de OSs Android como: o KitKat, Lollipop, 
Marshmallow e Nuget. 
Diante disso, este trabalho propõe discutir e propor soluções de como 
otimizar o tempo gasto na execução do processo de FOTA?; como melhorar a 
confiabilidade do teste? E como substituir as tarefas realizadas manualmente, 
suscetíveis a erros inerentes do ser humano. 
1.3 OBJETIVO 
Esse trabalho tem como objetivo automatizar o processo de customização 
da feature de FOTA, eliminando a execução de atividades manuais e repetitiva, além 
de evitar que fatores humanos e pessoais possam interferir negativamente para esse 
processo tão crítico. 
1.3.1 Objetivos Específicos 
 Explorar, avaliar e testar a feature de FOTA por meio de uma ferramenta 
proprietária denominada ATS; 
 Entender a importância do teste de software, suas principais técnicas e 
processos; 
 Compreender o porquê a automação pode resolver o problema proposto; 
 Analisar as métricas comparativa entre o teste feito anteriormente sem a 
automação e posteriormente com a automação. 
 13 
FUNDAMENTAÇÃO TEÓRICA 
Um teste é executado para encontrar erros. Segundo Pressman, para obter 
êxito neste objetivo, uma série de passos de testes é planejada e executada 
(PRESSMAN, 2006). Testar um software mobile com qualidade é um desafio diante 
da particularidade destes devices e da complexidade de diversos modelos lançados 
no mercado. Os clientes não esperam apenas um dispositivo que faça o basicão, 
mas eles esperam que sejam seguros, eficientes, bonitos, rápido etc. 
2.1 A IMPORTÂNCIA DE TESTAR UM SOFTWARE 
O teste de software pertence a uma das etapas do ciclo de desenvolvimento 
de software e tem como objetivo principal reportar possíveis defeitos encontrados no 
sistema para que o desenvolvedor possa soluciona-los. Segundo Molinari, o principal 
objetivo da realização do teste de software é reduzir a probabilidade de ocorrência 
de erros quando o sistema estiver em produção (MOLINARI, 2012). 
Antigamente, na década de 70 os testes possuíam pouca importância e 
eram realizados pelos próprios desenvolvedores, porém com o passar do tempo, 
devido à alta concorrência no mercado e ao aumento da complexidade dos novos 
sistemas desenvolvidos, o nível de exigência do cliente por qualidade aumentou e 
com isso a necessidade de testes mais eficazes. Para (PRESSMAN, 2006), "teste 
de software é um elemento crítico da garantia de qualidade de software e representa 
a revisão final da especificação, projeto e geração de código". 
Hoje em dia a atividade de teste deve ser iniciada nas primeiras etapas do 
processo de desenvolvimento do software e serem realizados simultaneamente, até 
a entrega do software ao usuário, para que os resultados de qualidade sejam 
atingidos (RIOS, 2012). O teste nas fases iniciais do desenvolvimento reduz os 
custos do projeto consideravelmente, pois, segundo Rios (2012), “os defeitos 
detectados quando o sistema ainda está nos seus estágios iniciais de 
desenvolvimento, podem ser mais baratos do que aqueles corrigidos quando o 
sistema já está em produção”. 
Conforme apresentado na Figura 1 e segundo a “Regra 10 de MYERS e 
SANDLER, o custo de correção dos defeitos cresce exponencialmente à medida que 
 14 
desenvolvimento vai avançando dentro do ciclo de vida do sistema” (RIOS, 2012). 
Portanto quanto mais cedo o defeito é identificado, menor é seu custo de correção. 
 
Figura 1 - Custo dos defeitos com passar do tempo do projeto 
 
Fonte: (Custo de correção de defeitos: Extraído de Bastos; Cristalli; Moreira; Rios, 2007) 
O teste de software não é uma atividade barata e fácil, normalmente o valor 
gasto com teste varia de 30% a 40% do valor total do projeto, dependendo das 
técnicas de teste que foram utilizadas e da tolerância a falhas exigidas pelo projeto 
(BASTOS; CRISTALLI; MOREIRA; RIOS, 2007). 
Outro fator levado em consideração para a produção de um software com 
qualidade é o alto risco em se produzirum software com defeitos. Esse risco justifica 
a utilização de testes. Testar reduz e mitiga os riscos. Os riscos e os defeitos em um 
código ou produto sempre existirão e testar exaustivamente afim de evitar esses 
riscos não é recomendável, uma vez que é quase impossível verificar todas as 
entradas e saídas possíveis. O recomendável para minimizar os riscos é o teste 
independente pois é realizado por uma pessoa, equipe ou organização 
independente da equipe de desenvolvimento. 
Percebe-se que existe uma tendência no mercado em fazer com que os 
testes de software sejam realizados de forma independente do desenvolvimento e 
 15 
que as evidências de qualidade sejam realizadas por empresas especializadas em 
testes (BERTOLINO, 2007). 
Portanto testar um software é fundamental no processo de desenvolvimento 
de um software, pois correspondem a um último momento de corrigir eventuais 
problemas no produto antes da sua entrega ao usuário final (PRESSMAN, 2006). 
2.2 TESTES FUNCIONAIS 
A partir da década de 70 que o teste de software ganhou destaque e 
começou a crescer, assim automaticamente os sistemas foram tendo mais qualidade 
e eficiência. Os testes de caixa preta, também conhecidos como testes funcionais 
são frequentemente utilizados para validação do software, pois é o comportamento 
ou a funcionalidade da aplicação sem a necessidade de conhecimento de uma 
linguagem de programação para testa-lo. (VIANA, 2007). 
O teste funcional evolve a identificação das funções que o software deve 
executar e em seguida a criação de casos de testes capazes de verificar se o 
resultado encontrado é conforme o resultado esperado. As funções são identificadas 
pela documentação ou especificação do software. Além disso alguns critérios de 
testes funcionais são utilizados na especificação e descritos abaixo: 
Particionamento de Equivalência - É o processo que identifica um 
conjunto de classes de domínios que equivalem a condições de entrada a ser 
testado, onde o objetivo é minimizar os casos de teste de testes necessários de 
forma a cobrir as condições de entrada. Segundo (PRESSMAN, 2006) as seguintes 
diretrizes devem ser utilizadas para definir um caso de teste: 
 Se uma condição de entrada especifica uma faixa de valores ou requer 
um valor específico, uma classe de equivalência válida (dentro do limite) e 
duas inválidas (acima e abaixo dos limites) são definidas; 
 Se uma condição de entrada especifica um membro de um conjunto ou é 
lógica, uma classe de equivalência válida e uma inválida são definidas. 
 Se uma condição de entrada do programa é booleana, uma classe de 
equivalência válida e uma inválida devem ser definidas. 
Análise de Valor Limite - Com base em experiências obtidas é possível 
afirmar que casos de testes que exploram as condições de fronteiras apresentam um 
maior retorno de incidentes em relação a outros casos de teste. Tais condições são 
 16 
valores acima ou abaixo dos limites das classes de equivalência de entrada ou de 
saída. O objetivo desta técnica é testar e saber que o software funcionará no limite 
de sua capacidade, sendo aprovado nesse teste ele provavelmente funcionará bem 
sob condições normais. Segundo (MYERS e SANDLER, 2004), essa análise de 
valor limite que os elementos de suas fronteiras e limites iniciais e finais seja 
submetido ao teste. 
Teste Exploratório/Suposição do Erro - Método de uma abordagem ad 
hoc, baseado na intuição e na experiência dos profissionais, afim de identificar 
testes e casos de testes que provavelmente mostrará erros. 
2.2.1 Teste de Caixa Preta (black box) 
Segundo (MYERS e SANDLER, 2004), o teste de caixa preta, possui esse 
nome devido ao conteúdo a ser testado ser desconhecido, assim como o conteúdo 
em uma caixa preta, onde só é possível visualizar o lado externo da caixa, bem 
como da aplicação. O teste consiste no fato de analisar o comportamento de um 
objeto, sem se preocupar como é seu funcionamento interno. Na pratica o testador 
não precisa ter conhecimentos avançados sobre a arquitetura, código ou linguagem 
de programação que o software foi desenvolvido, uma vez que o mesmo não possui 
acesso ao código fonte do software. Sua interação ocorre apenas com a interface do 
dispositivo, na qual ele insere as entradas de dados e obtém as saídas. Através da 
Figura 2, é possível identificar os valores de entrada e saída de uma aplicação, 
porém não é possível visualizar ou ter contato com o código fonte daquela aplicação. 
Segundo (KOSCIANSKI, 2006), o teste é particularmente útil para revelar 
problemas tais como: Funções incorretas ou omitidas, erros na interface, erros de 
comportamento ou baixo desempenho e erros de iniciação e término. 
 
 
 
 
 
 
 17 
Fonte: Modelo de Caixa Preta: autoria Própia 
2.2.2 Teste de Aceitação 
Nesta etapa o teste é conduzido pelos usuários finais do sistema e tem por 
objetivo verificar se o software está de acordo com os padrões documentais da 
especificação. O software é disponibilizado ao cliente para que este interaja com o 
sistema verificando se as funcionalidades requisitadas no início do projeto estão 
corretas (BARTIÉ, 2002). Segundo o mesmo autor, se essa fase apresentar muitas 
falhas, é sinal de que os processos de detecção de erros anteriormente executados 
não estão sendo implementados corretamente (BARTIÉ, 2002). 
Normalmente os testes de aceitação são executados após os testes 
funcionais e não funcionais, uma vez que durante esses testes bugs serão 
encontrados e corrigidos. Diz-se que é um dos últimos testes antes da liberação do 
software comercial. Há dois tipos de testes que se enquadram nos testes de 
aceitação. 
Testes Alfa: Teste de aceitação realizado por um número restrito de 
usuários. Na maioria dos casos o teste é executado na própria empresa e utilizado 
num ambiente real com a presença do desenvolvedor que registra erros e problemas 
de uso (PRESSMAN, 2006); 
Testes Beta: Teste de aceitação realizado em maior escala, sem restrição 
ou limitação de quantidade de usuários, na maioria das vezes são os próprios 
usuários que identificam issues e reportam diretamente ao desenvolvedor, apesar da 
quantidade de problemas encontrados serem bem reduzidas. O usuário registra os 
problemas encontrados e relata-os ao desenvolvedor (PRESSMAN, 2006). 
Figura 2 - Modelo Caixa Preta 
 18 
2.2.3 Teste de Regressão 
O teste de regressão, também chamados de teste de confirmação é uma 
estratégia de teste que visa reduzir possíveis efeitos colaterais. A cada nova versão 
de software lançada, todos os bugs encontrados em versões anteriores são 
verificados afim de confirmar ou não sua reprodução. Os testes de regressão podem 
ser aplicados em qualquer fase do teste. 
Conforme (PAULA FILHO, 2005), o teste de regressão, tem por objetivo 
evitar que o desenvolvedor ao modificar ou efetuar a correção de erros detectados 
acabe introduzindo outros erros em partes do software previamente testadas. Por 
ser executado diversas vezes em cada lançamento de versão ou na confirmação de 
cada bug encontrado, os testes de regressão são considerados testes longos, 
tornando-se assim um dos maiores argumentos para a automação deste tipo de 
teste. 
2.3 TESTES NÃO FUNCIONAIS 
Diferentemente dos testes funcionais, os não-funcionais tem por objetivo 
verificar o funcionamento do sistema em condições extremas e incomuns. Apesar de 
não ser o escopo deste trabalho, abaixo são descritos alguns testes não-funcionais 
que podem ser aplicados aos dispositivos móveis. 
 
2.3.1 Teste de Caixa Branca (white box) 
SOMMERVILLE, define como teste de caixa branca aqueles que possibilitam 
avaliar, estudar, implementar e desenvolver testes baseado na estrutura interna do 
software, desde sua codificação, execução dos componentes elementares, onde tais 
informações são utilizadas para criar, executar e depurar casos de testes 
(SOMMERVILLE, 2007). Para sua execução é necessáriode conhecimento técnicos 
e avançados em desenvolvimento e da arquitetura interna do software, uma vez que 
a interação com o código será constante. Conforme a Figura 3, é possível visualizar 
os dados de entrada e saída da aplicação, além de visualizar, ter acesso e 
manipular o código fonte, estrutura, módulos e arquitetura do código. 
 19 
 
Figura 3 - Modelo de Caixa Branca 
 
Fonte: Modelo de Caixa Branca: autoria Própia 
 
Existem ainda o teste de caixa cinza que basicamente uma adequação entre 
os testes de caixa preta e branca. 
2.3.2 Teste de Desempenho/Performance 
Como o próprio nome diz, o teste de desempenho visa identificar o 
desempenho do dispositivo diante de vários cenários propostos, como por exemplo: 
execução de diversos aplicativos rodando em background, execução de um game 
pesado, recepção e envio de mensagens instantâneas, navegação em redes sociais 
e pela internet. O teste tem como objetivo verificar como o software reagirá em 
citações descritas acima. Em dispositivos móveis o teste está condicionado a 
percepção e experiência do tester em identificar delay excessivo, atraso ou 
travamentos. Conforme (BARTIÉ, 2002), os testes podem ser executados da 
seguinte forma: 
 Validar todos os requisitos de desempenho identificados; 
 Simular número de usuários acessando simultaneamente a mesma 
informação; 
 Simular número de usuários processando simultaneamente a mesma 
transação; 
 20 
 Simular número de usuários no tráfego de rede; 
 Aumentando o número de usuários simultâneos; 
 Combinar todos esses elementos. 
2.3.3 Teste de Carga 
Verificar o comportamento do sistema diante de uma grande carga de dados 
de entrada. Os dados de entrada podem ser simulados em situações normais ou em 
situações de pico, como por exemplo: verificar se um formulário de inscrição aceita 
50 mil inscrições em um curto período estipulado sem sair do ar. Algumas 
ferramentas de teste de carga bastante conhecidas são: IBM Rational Performance, 
Tester, Apache JMeter, Silk Performer, Visual Studio Load Test etc. Segundo 
(BARTIÉ, 2002), os testes podem ser executados da seguinte forma: 
 Elevando e reduzindo o número de transações simultâneas; 
 Aumentando e reduzindo o tráfego de rede; 
 Aumentando o número de usuários simultâneos; 
 Combinando todos esses elementos. 
2.3.4 Teste de Stress 
Verificar o comportamento do software em condições anormais é o objetivo 
deste teste. Este teste possui estreita relação com o teste de carga, diferenciando-se 
na aplicação de valores anormais ou cargas acima do especificado nos requisitos. 
Segundo (BARTIÉ, 2002), alguns cenários do teste de stress são: conexões 
intermitentes com a rede e o banco de dados ou aplicação de cargas de dados em 
diferentes processos responsáveis por consumir memória e processamento no 
servidor do dispositivo. 
2.3.5 Teste de Segurança 
Teste que visa expor ou procurar expor todas as vulnerabilidades que o 
sistema possa possuir, assim sendo pode-se determinar se informações sigilosas 
dos usuários estão devidamente protegidas de ataques. Existem diversas formas de 
ataque ao sistema, sucessivamente passa a existir diversas provas de protege-lo. 
 21 
Segurança de redes wifi, do firmware, hardware, de aplicações que rodam no cliente 
e de aplicações que rodam diretamente no servidor são as principais áreas de 
ataques e de testes de segurança que devem ser desenvolvidos. Segundo (BARTIÉ, 
2002), os testes podem ser executados da seguinte forma: 
 Acessar funcionalidades e informações que requerem perfil avançado; 
 Tentar invadir/derrubar o servidor de dados/internet; 
 Tentar extrair backups de informações sigilosas; 
 Tentar descobrir senhas e quebrar protocolos de segurança; 
 Tentar processar transações geradas de fontes inexistentes; 
 Tentar simular comportamento/infecção por vírus. 
2.3.6 Teste de Portabilidade 
Verifica-se o aplicativo ou software desenvolvido consegue rodar em 
diferentes sistemas operacionais. Se um sistema em sua fase inicial não for 
desenvolvido pensando na portabilidade, é bem provável que o aplicativo criado não 
seja portável ou outros sistemas operacionais. Abaixo (BARTIÉ, 2002), descreve 
alguns a transferência de software de um computador para outro, execução do 
executável em diferentes plataformas e utilização de diferentes navegadores para 
testar uma aplicação como exemplos do teste de portabilidade. 
2.4 AUTOMAÇÃO DE TESTE 
Segundo Molinari, existem duas razões básicas para a automatização dos 
testes: O grande crescimento das aplicações e sistemas e o elevado grau de 
complexidade dos sistemas. Segundo as razões citadas por Molinari, e devido ao 
crescimento exponencial do mercado mobile, dos aplicativos desenvolvidos e dos 
dispositivos lançados, uma solução viável para a execução dos testes é a 
automação dos mesmos, levando em consideração o tipo de teste que será 
realizado e da função a ser realizada, tornando assim algumas vezes a execução do 
teste manual inviável (MOLINARI, 2008). 
Hoje em dia o participante de automação necessita entender a programação 
do sistema desenvolvido e sua lógica de implementação. Há também a necessidade 
do conhecimento e as características da ferramenta a utilizar na automatização, que 
 22 
muitas vezes possuem linguagens próprias para o seu desenvolvimento (MOLINARI, 
2008). 
Existem várias soluções propostas para melhorar a eficiência e eficácia de 
atividades executadas no dia a dia, sem dúvida a automação é a principal delas. Na 
automação de testes, tarefas antes realizadas manualmente e suscetíveis a erros de 
cunho pessoal, são repassadas ao computador através de ferramentas de 
automação. A automação é uma das maneiras mais eficiente de reduzir e melhorar o 
tempo de teste durante o ciclo de vida do software, e sucessivamente reduzir custos, 
aumentar a produtividade e qualidade do software. Tais resultados são obtidos 
através do teste de regressão e substituição de testes manuais e repetitivos pela 
automação. 
2.4.1 Quando Não Automatizar? 
A automação reduz significativamente o tempo e esforço na execução de 
atividades repetitivas, porém nem tudo deve ser automatizado. Há uma necessidade 
de planejamento e analise da quantidade e volume de teste que o software 
necessita e o tempo gasto para sua execução. Caso o projeto de software possuir 
baixa complexidade, onde poucos testes seriam necessários para cobrir todo o 
escopo do projeto, o esforço na implantação de uma metodologia de testes 
automatizados poder sair mais custosos e trabalhosos que os testes manuais. 
Uma outra situação em que a automação não é recomendável diz respeito a 
interfaces quer sofrem constantes modificações. O teste automatizado, comunica-se 
por meio de uma ferramenta de teste, efetuando assim modificações na interface do 
dispositivo. Caso essa interface sofra alterações, a automação perde-se sentido uma 
vez que modificações durante o teste deve ser realizada pela automação e não pelo 
usuário. (ALMEIDA, 2016). Os custos iniciais no processo de automação podem ser 
elevados, e deve ser analisado antes da tomada de decisão. 
2.4.2 Dificuldades no Processo de Automação dos Testes 
Equipe despreparada, sem experiência, alto custo inicial e de manutenção, 
mão de obra não especializada ou certificada, dificuldade no entendimento dos 
casos de testes e de lógica de programação do software, são algumas dificuldades 
 23 
encontradas ao longo do desenvolvimento do software, e podem ocorrer desde a 
fase inicial até a fase final do projeto. (KOSCIANSKI, 2006) 
Nas grandes organizações e fabricas de teste de software a principal 
dificuldade é o processo de implantação de testes automatizados, uma vez que, 
inicialmente a automação dos testes possui um custo elevado, devido a aquisição de 
ferramentas, treinamento da equipe, contratação de um especialista para orientação 
inicial, e entre outros. Inicialmente uma empresadevem levar em consideração que 
no princípio da implementação do teste o retorno será mínimo, porém ao longo prazo 
ela colherá os frutos, não só de uma base de dados de scripts de automação já 
prontos como de participantes treinados e capacitados, gerando como consequência 
um teste realizado com qualidade e em um menor tempo. (MOBIZOO, 2016) 
Como exemplo prático das dificuldades encontrada no processo de 
automação dos testes, diz respeito a uma grande empresa de teste de software 
independente com cerca de 200 participantes em quatro estados do Brasil, onde a 
ideia de automação dos testes da feature de FOTA foi proposta, idealizada e 
realizada pelo autor deste trabalho. 
2.4.2 Técnicas de Automação de Software 
As quatro principais técnicas de automação existentes são apresentadas a 
seguir. 
1. A técnica record & playback utiliza uma ferramenta de gravação de 
todas as ações executadas pelo usuário na interface do dispositivo, onde 
essas ações são convertidas em scripts, que por sua vez é executado 
quantas vezes for necessário durante os testes. Para cada caso de teste da 
checklist, a técnica record & playback é executada e nos casos de teste é 
incluído uma description do teste (passo a passo para execução do teste), os 
dados de entrada, os dados de saída e as ações do tester sobre o dispositivo. 
Entretanto por ter um alto custo, baixa taxa de reuso, dificuldade de 
manutenção, curto tempo de vida e por sofrer alta sensibilidade a mudanças 
no software acaba tornando o uso desta técnica desnecessária. Por exemplo, 
uma alteração, inclusão ou remoção de um aplicativo na interface do 
dispositivo pode exigir uma refatoração em todos casos de testes e 
regravação de todos scripts. (FEWSTER, 2001). 
 24 
2. A técnica de programação de scripts é uma extensão da técnica anterior 
onde os scripts gerados são modificados e programados a desempenharem 
um comportamento especifico. Desta forma, os scripts alterados podem 
contemplar outros cenários e verificar os resultados esperados. Essa técnica 
possui a vantagem de possuir uma alta taxa de reuso, uma vez que um caso 
de teste similar por exemplo, pode ter seu script copiado e em seguida 
implementar as particularidades deste novo caso de teste baseado no caso 
de teste anterior, uma outra vantagem é a manutenção dos scripts que se 
adequam facilmente a mudanças na interface, a desvantagem da técnica 
ficaria pela quantidade de scripts de testes criados e a compreensão do que 
faz cada script. (FEWSTER, 2001). 
3. Na técnica data-driven (técnica orientada a objeto) os scripts de teste são 
extraídos e armazenados em arquivos. Os scripts agora passam a conter a 
lógica de execução e as ações de teste sobre a aplicação. Assim, os dados 
de testes não ficam no próprio código e sim em arquivos separados. A 
principal vantagem desta técnica é sem dúvida a facilidade de adicionar, 
modificar ou remover dados de teste com apenas pequenas modificações no 
script de dados. Essa técnica possibilita que o projeto e a implementação do 
teste possam trabalhar em diferentes níveis de abstração, uma vez que, o 
participante apenas projeta os dados de teste, sem se preocupar com a lógica 
interna ou questões técnicas de como funciona a automação daquele 
processo. (FEWSTER, 2001). 
4. A técnica keyword-driven (técnica orientada a palavras chaves) é 
semelhante à anterior, onde os scripts extraídos passam a conter ações 
especificas do teste sobre a aplicação e identificados através de palavras 
chaves. Tais ações podem recebem parâmetros ativados através das 
palavras chaves, e os dados são armazenados em arquivos separados na 
forma de um conjunto ordenado de palavras chaves com seus respectivos 
parâmetros. A principal vantagem da técnica keyword-driven é a possibilidade 
de adição, modificação e remoção de passos de execução do teste e a 
mínima manutenção dos scripts de teste. (FEWSTER, 2001). 
 
 25 
FOTA (FIRMWARE/SOFTWARE OVER THE AIR) 
Segundo a LG, Firmware/Software Over-The-Air (FOTA) é um recurso 
tecnológico que permite que o usuário atualize o software de seu aparelho para uma 
versão mais recente de forma simples e prática, sem a necessidade de conexão de 
um cabo USB, através apenas de uma rede wifi ou rede de dados. Esse recurso 
serve para melhorar o desempenho do software em vários aspectos, como a 
correção de falhas do OS, melhorar a conectividade dos aplicativos com os demais 
recursos do dispositivo móbile, inserir ou remover funções do aparelho entre outros 
benefícios. (FOTA LG, 2016) 
A atualização do software possibilita aos fabricantes inserirem novas 
funcionalidades, corrigir bugs, modificar a UI (User Interface) o que aumenta a 
satisfação do cliente e reduz a necessidade de suporte técnico. Os anúncios de 
atualização de software podem estar localizados em local de suporte do site do 
fabricante, fóruns de tecnologia ou em uma na data pré-programada pela fabricante, 
onde um popup aparece no dispositivo informando ao usuário sobre a atualização. 
O processo de FOTA tem sido amplamente utilizado no mercado de celulares 
desde meados da década de 2000. É um conceito comprovado em bilhões de 
telefones celulares e outros dispositivos móveis e possibilita a interação da 
fabricante com seus clientes, mesmo após o dispositivo ser vendido. (FOTA LG, 
2016) 
Quando há um pacote de atualização aprovado disponível, somente as 
alterações (isto é, as diferenças) entre versões de software são enviados ao 
dispositivo destino, economizando assim largura de banda da rede, wifi e tempo de 
execução dos serviços. Essa técnica algorítmica chamada de “Diff” e identifica de 
forma eficiente as diferenças entre as versões do software. (ROMEYKE, 2007) 
Para os dispositivos mobile o processo de teste de FOTA é tratado como 
prioridade “high”, uma vez que visto que modificações e erros durante esse processo 
afeta diretamente em dados e informações pessoais do usuário. Na Figura 4 é 
descrito passo a passo para o usuário possa executar a atualização do software em 
seu dispositivo. 
 26 
Figura 4 - Processo de FOTA 
 
Fonte: O que é FOTA? : (FOTA LG, 2016) 
 
Toque em Aplicativos [ ] e selecione a opção (1). Ajustes [ ]; 
selecione a opção (2) Sobre o telefone > (3) Atualização de Software (4) Clique 
em Instalar Agora para iniciar a instalação. O aparelho será reiniciado neste 
momento). (5) Popup, informando que a atualização foi realizada com sucesso. 
3.2 TIPOS DE FOTA 
Devido a criticidade a respeito do teste de FOTA, sua importância para o 
mercado e os benefícios alcançados com essa tecnologia, faz-se necessário simular 
cenários que cubra o máximo caso de testes possíveis, para isso o teste de FOTA é 
dividido em cinco tipos: 
 27 
 FOTA BASIC – Testa-se a UI (User Interface) do dispositivo antes do 
FOTA, afim de checar seu respectivo comportamento e depois do FOTA, 
afim de checar mudanças devido a atualização, também se testa a 
FUNCTION depois do FOTA. 
 FOTA FULL – Testa-se as mesmas coisas do FOTA BASIC, e o 
dispositivo recebe uma customização de valores e configurações, afim de 
checar a persistência dos mesmos após o FOTA, através de uma 
minuciosa comparação. 
 FOTA MR – Testa-se as mesmas coisas do FOTA FULL, bem como o 
teste de versões anteriores do software, até a sua versão mais recente. 
 FOTA DUMMY – Testa-se se o dispositivo possui a versão mais recente e 
verifica-se o link com o servidor de atualização está funcionando 
corretamente. 
 FOTA OS – Valida-se a atualização de um sistema operacional para 
outro. 
Para qualquer tipo de teste a ser realizado, é necessário o levantamento 
prévio de algumas informações como: qual a versão SOURCE (fonte)? Para qual 
versão TARGET (alvo) o software deverá ficar o dispositivo após o FOTA? Todos os 
pré-requisitos estão aprovados? Após o levantamento dessas informaçõesé 
necessário cadastrar tais informações no sistema GDMS (Global Device 
Management System), que é um sistema da LG, que gerencia todos os pacotes de 
FOTA, IMEI, RST, WEB-Download, através de poucos cliques o usuário pode 
comunicar-se com o sistema, verificando assim se há pacotes de atualizações 
disponíveis e a devida atualização do seu software de uma maneira segura e 
eficiente. 
O processo de comunicação do dispositivo com o servidor dar-se através do 
IMEI, que é um código único de quinze caracteres que cada aparelho possui, o 
sistema identifica primeiramente a versão atual do aparelho e em seguida verifica a 
existência de versões posteriores, existindo fica ao cargo do usuário efetuar a 
atualização ou não. Todo esse processo de atualização é a prova de falhas, ou seja, 
caso ocorra algum problema durante o FOTA o dispositivo precisa se recuperar e ser 
restaurado para o estado anterior antes de quando a falha ocorreu, e o teste de 
FOTA é o responsável pela verificação dessa checagem. Depois que a atualização 
 28 
for concluída com êxito, uma mensagem é enviada para o GDMS, afim de fornecer 
informações sobre o recém - versão de software instalada no dispositivo. 
3.3 VANTAGENS E DESVANTAGENS DO FOTA 
O Android é o OS mobile mais utilizado no mundo, ele domina o mercado 
mundial de dispositivos móveis marcando presença em mais de 80% dos 
smartphones. (TUDO CELULAR, 2016). A soberania do Android é inegável, bem 
como suas vantagens como: 
É código aberto e possibilita a liberdade de customização pelo 
desenvolvedor; 
É utilizado por grandes fabricantes (Samsung, LG, HTC, Lenovo, Asus); 
Grande variedade de dispositivos roda Android; 
Maior integração entre os serviços da Google e sua Loja de aplicativos. 
A atualização do software está relacionada com as vantagens citadas acima, 
uma vez que quando um problema no aplicativo ou no software é resolvido, é a 
atualização a responsável por tornar um produto já lançado melhor, otimizado e 
seguro. Abaixo ISABEL, 2013) descreve algumas vantagens e desvantagens do 
FOTA. 
Torna a interface do dispositivo mais atraente através da inserção de temas, 
fotos, vídeos, cores e papeis de parede; 
Inserir novos recursos que facilitarão o uso do dispositivo pelo usuário. Ex: 
Knock On, permite ligar o dispositivo com apenas dois toques na tela; 
Corrigi bugs em aplicativos e de bugs de segurança ou vulnerabilidade; 
Permite remover aplicativos e personalizações da operadora. Há situações 
em que o dispositivo é vendido com games, aplicativos embarcados e aplicativos da 
operadora, que após o FOTA desaparecem tornando o software mais puro e limpo. 
(MOBIZOO, 2016). 
 
Apesar das inúmeras vantagens em ter o dispositivo com a versão do 
software mais recente, a desvantagem está associada aos riscos e erros da 
ausência do teste sobre o software. É exatamente para minimizar essas 
desvantagens que o teste de software se torna tão necessário. Ainda segundo 
(ISABEL, 2013) a principal desvantagem do FOTA é descrita abaixo: 
 29 
 A depender do tamanho do pacote da versão lançada pode ocupar mais 
espaço no dispositivo; há situações que a atualização deixa o 
sistema mais lento e mais pesado; 
 O dispositivo pode ser danificado, uma vez que a mudança de firmware 
está relacionada a partes essenciais para o bom funcionamento do 
aparelho. Caso alguma dado falhe durante o processo de atualização, o 
aparelho pode não ligar, apresentar tela preta, e seu funcionamento pode 
ficar comprometido. 
 Dados pessoais podem ser perdidos. A Integridade de informações 
pessoais é de extrema importância. 
 A atualização pode comprometer a segurança abrindo brechas para 
invasão de crackers no dispositivo. 
 Idioma pode mudar para outro diferente do escolhido pelo usuário. 
 Como pode ser observado o Android e o FOTA apesar de possuírem suas 
vantagens e agradarem os usuários, necessitam ser testados afim de 
minimizar e eliminar diversos problemas ocasionados por uma atualização 
de software inconveniente. 
3.4 PRINCIPAIS BUGS DE FOTA 
Após um período de tempo, o Google libera o código fonte das versões 
Android para desenvolvedores e fabricantes efetuarem uso. Nesta fase o OS possui 
diversos bugs. São bugs do OS, aplicativos e de atualização entre essas versões 
fragmentadas. Todos esses cenários de testes devem ser validados afim de 
identificar não somente bugs do processo de FOTA, mas também do Android. Nas 
Figuras 5, 6 e 7 os três bugs mais comum em FOTA e o report destes bugs é 
descrito. (ANDROIDPIT, 2016) 
 30 
 
Figura 5 - Report Issue - Facebook and Twitter app disappear 
 
Fonte: Report Issue: autoria Própia 
 
Figura 6 - Report Issue - Vulnerabilities 
 
Fonte: Report Issue Vulnerabilities: autoria Própia 
 
Figura 7 - Error during installation 
 
Fonte: Error during installation: autoria Própia 
 
 31 
Analisando os três bugs citados é possível identificar a quantidade de 
problemas que foram minimizados através do teste de software. Bugs de segurança 
e vulnerabilidade do OS fazem com que muitos usuários evitem fazer 
movimentações financeiras em seu dispositivo, enquanto bugs em aplicativos de 
redes sociais desagradam a maior parte dos usuários que se relacionam, navegam e 
se divertem por meio destas aplicações. Por outro lado, um bug no processo de 
atualização do software pode inviabilizar o uso do dispositivo. 
 
 32 
AUTOMAÇÃO DE TESTES FUNCIONAIS NO PROCESSO DE FOTA 
A seguir é descrito como foi realizado os testes funcionais no processo de 
FOTA. 
4.2 TESTES EM DISPOSITIVOS MÓVEIS 
Teste em dispositivos móveis (do inglês, Mobile Testing) é aplicado para 
smartphones, tablet, notebooks, smartwatches e smartbands nada mais é que um 
computador de bolso e portátil. Teste nestes dispositivos é efetuado utilizando 
diversas ferramentas que possam garantir qualidade, funcionalidade, desempenho, 
comportamento frente a situações extremas, que possa garantir as características de 
mobilidade, interoperabilidade, conectividade, usabilidade, segurança e privacidade 
(Gao et al., 2014). 
Aplicações em dispositivos móveis possuem características especificas, tais 
como a necessidade de avaliar o software em diferentes sistemas operacionais 
android ou não levando em consideração a possível fragmentação do OS em 
versões menores, possuem uma diversidade de tamanho de telas, tipos de 
comunicação em rede, tamanho da memória, capacidade de processamento, 
diversidade de fabricantes, diversidade de modelos lançados etc. Dessa forma, 
cobrir todas as combinações possíveis de teste de software em dispositivos móveis 
pode tornar-se inviável. 
4.3 VISÃO GERAL 
Conforme descrito por (Carsten, 1989) prova de conceito é um modelo que 
possui como objetivo principal a provar o conceito (teórico) de uma pesquisa. Para a 
execução da prova de conceito, foram separados os seguintes tópicos de estudo: o 
ambiente de teste, o critério de teste a ser executado e a execução de casos de 
testes do processo de FOTA a ser executado. Após a execução é a análise dos 
resultados. 
Foram selecionadas quatro amostras para o teste, com sistemas 
operacionais android diferentes e executados sessenta e cinco casos de teste de 
 33 
customização para cada amostra utilizada. Em seguida, diversas análises foram 
realizadas, com o objetivo de verificar o tempo de execução manual e automatizada 
entre os dispositivos é provar a viabilidade de introduzir a automação dos testes de 
customização no estudo proposto na pesquisa. 
4.4 AMBIENTE DE TESTE 
Todos os testes foram realizados e controlado no maior laboratório de teste 
de software independente da america latina. O ambiente utilizado foi um Ultra book 
Dell, rodando Windows 8.1, processador i7, 8GB de RAM e 2 Terabites de HD. 
Foram utilizadas três amostras com diferentes versões de OS Android, tamanhos de 
tela, capacidade, processamento, armazenamento etc. As ferramentas, ATS 6,LGUP, TestManager, Connectivity Panel, Eclipse, ADT (Android Development 
Tools), Java, Microsoft Office 2013 foram previamente instaladas e configuradas. 
Para que um uso eficiente das ferramentas obtivesse sucesso no 
desenvolvimento do projeto e baseando-se no que diz (Kirubakaran e Karthikeyani, 
2013), os testes foram divididos em três categorias de dispositivos móveis conforme 
suas características principais. As listas destas categorias são ilustradas na Tabela 
1. 
 
Tabela 1 - Classificação de Dispositivos Móveis 
 
Fonte: Classificação de dispositivos móveis: autoria Própia 
 
Além da classificação usada por (Kirubakaran e Karthikeyani, 2013) e de 
acordo com os desenvolvedores da Google (DEVELOPER, 2016), responsáveis pelo 
lançamento de versões do sistema operacional Android, e por sua fragmentação, o 
Android Lollipop 5.0 está presente hoje em cerca de 35% dos smartphones. O 
Lollipop é uma das versões de OS que mais apresentaram bugs, que vai deste ao 
https://marketplace.eclipse.org/content/android-development-tools-eclipse
https://marketplace.eclipse.org/content/android-development-tools-eclipse
 34 
alto consumo da bateria, problemas com o microfone e respectivamente com as 
chamadas, problemas com Wifi, reprodução de vídeos, falhas na lanterna, reinicio 
frequente de aplicativos e atraso no sistema etc. Na Figura 8, é possível identificar 
que o Android Lollipop e Marshmallow possuem uma enorme fatia de dispositivos 
instalados, enquanto o recém lançado Android Nouget ainda possui poucos 
dispositivos que fazem uso do seu OS. (ANDROIDPIT, 2016). 
 
Figura 8 - Fragmentação do Android 
 
Fonte: Fragmentação do Android: (Developer, 2016) 
 
Baseado na fragmentação e uso do android coletadas na página dedicada 
aos desenvolvedores do Android no ano de 2016 e no ambiente de teste, foi definido 
que serão utilizados os dispositivos (LG-G5, LG-X Screen, LG-K4 e LG-G3 Stylus) 
para serem usados como prova de conceito. 
4.5 CRITÉRIOS DE TESTE EM DISPOSITIVOS MÓVEIS 
Ciente da particularidade dos dispositivos móveis e da diversidade de 
fabricantes e modelos, foi necessário definir critérios de testes para este tipo de 
dispositivo. Um grupo de desenvolvedores e empresas denominados Aqua (em 
inglês, App Quality Aliance), se uniram para estabelecerem critérios para testes em 
aplicativos móveis. Aqua é um grupo sem fins lucrativos, liderada por membros das 
principais indústrias de eletrônicos - AT&T, LG Eletronics, Motorola/Lenovo, Nokia, 
 35 
Positivo Informática, Oracle Samsung e Sony Mobile. As diretrizes definidas pelo 
Aqua, servem como base para que desenvolvedores independentes e empresas 
possam garantir a qualidade das aplicações desenvolvidos dentro dos padrões pré-
estabelecidos, facilitando assim o entendimento e manutenção destes apps. (Aqua, 
2016). 
Os critérios da Aqua para a plataforma android, sugerem passos que os 
desenvolvedores precisam seguir, para que suas aplicações sejam aprovadas nos 
testes realizados. Um caso de teste de FOTA por exemplo contém: um título, 
descrição detalhada do teste, pré-condições, passos a serem executados, resultados 
que se esperam, resultado obtido no teste e finalmente o resultado final do teste 
indicando se o mesmo passou (em inglês, Pass) ou falhou (em inglês, Fail). A Figura 
9 apresenta um exemplo de um caso de teste definido pela Aqua que define alguns 
critérios como: 
 Instalação e Desinstalação de Aplicação deve ocorrer com sucesso; 
 Inicialização de Aplicação não deve demorar mais que 2~3 segundos; 
 Deve permitir download de Pacotes e atualizações; 
 Uso de Memória durante execução; 
 Tratar a suspensão e reinicialização do aplicativo; 
 Cancelar operação (caso o usuário deseje); 
 Permitir efetuar download de aplicações pela PlayStore ou Browsers; 
 Manipulação de Eventos; 
 Mensagens e Ligações devem ser realizadas com sucesso; 
 Enviar e Receber Mensagens devem ser realizadas com sucesso; 
 Deve permitir a múltipla entrada de dados (teclado qwerty, teclado 
virtual...); 
 Seleção Manual de linguagem (internacionalização); 
 Tarefas de background devem ser realizadas 
 36 
Figura 9 - Exemplo Caso de Teste - Remove to battery 
 
Fonte: Exemplo Caso de teste: Autoria Própia 
 
 Diante dos desafios dos testes em dispositivos móveis e as 
particularidades do processo de teste do FOTA, aliado aos critérios definidos pelo 
Aqua, foi realizado a análise das quatro principais atividades do FOTA, como: 
customization, ui (user interface), function e mr versions. Baseado no 
conhecimento empírico da equipe sobre a feature FOTA, estudos e reuniões, foi 
definido que a atividade de customization é a única das quatro atividades que 
consomem um tempo excessivo para ser executada, está sujeita a erros de 
preenchimento se comparada com as demais, é altamente repetitiva e cansativa na 
sua execução diária e absolutamente passível de ser automatizada. Para isso foi 
proposto que todos os 65 casos de teste de customization fosse automatizado. 
4.6 FERRAMENTA UTILIZADA 
ATS é uma ferramenta proprietária especifica para desenvolver scripts de 
teste automatizado para dispositivos móveis, desenvolvido e mantido por uma 
grande fabricante de software e hardware para dispositivos móveis com atuação no 
Brasil. O ATS foi concebido e disponibilizado para que diversos modelos de telefone 
 37 
celular que possuem as mesmas funcionalidades e uma elevada quantidade de 
casos de testes em comum sejam aplicados para todos os dispositivos. (RECHIA, 
2005). Os scripts são desenvolvidos no ATS baseado em casos de testes que após 
a automação poderão ser reutilizados em diversos outras amostras que 
implementam as mesmas funcionalidades. Essa automação reduz o tempo gasto no 
ciclo de desenvolvimento dos softwares e permite a eliminação de execução manual 
de diversos casos de testes. 
A ferramenta permite enviar comandos para o dispositivo, basta para isso 
conectar o dispositivo via interface USB (Universal Serial Bus) e provê funções que, 
por exemplo, retornam o conteúdo que está sendo mostrado na tela e que simulam o 
pressionamento de teclas do telefone (ESIPCHUK; VALIDOV, 2006). Através do 
plugin do pyhton é possível o próprio usuário criar seus próprios comandos no 
projeto. Ao desenvolver um projeto de teste na ferramenta, é necessário o uso da 
IDE eclipse, onde através desta é possível desenvolver os scripts. Conforme a 
Figura 10, a ferramenta vem evoluindo acompanhando a evolução do Android e dos 
seus novos recursos. A evolução vem passando desde o seu núcleo feito em C++ 
até a linguagem Pyhton. 
 
Figura 10 - ATS Versões 
 
Fonte: ATS Versões: autoria Própia 
 
Para uma comunicação de sucesso entre o dispositivo e a ferramenta é 
necessário que um aplicativo denominado ETA esteja instalado no dispositivo e ser 
testado e esteja ativado. O ETA (Embedded Test Agent), interpreta os comandos 
enviados pelo ATS para o dispositivo Android. Além de ativar o ETA, a depuração 
USB também deve estar ativada e dispositivo reconhecido no painel de 
conectividade. 
 38 
Conforme visto na Figura 11, o ATS Connectivity é um painel aberto no 
Windows, que registra e gerencia as conexões com o dispositivo de destino. Quando 
o ETA e a depuração USB estão ativados ao abrir o Connectivity os dispositivos são 
automaticamente reconhecidos. 
 
Figura 11 - ATS Connectivity Panel 
 
Fonte: ATS Connectivity Panel: autoria Própia 
 
Uma vez que a conexão foi bem-sucedida é necessário utilizar o ambiente 
Test Manager que roda diretamente no navegador. O Test Manager é um ambiente 
de execução de pacotes de testes, onde as configurações de todos elementos 
relacionados para a automação como: (dispositivos conectados, parâmetros do 
cenário, interações, quantidade de execuções etc.) são realizadas diretamente no 
dispositivo e os resultados (registros de testes) são colhidos e visualizados no 
dispositivopor meio da automação e após o término da automação, colhidos através 
da geração de uma planilha excel para análise e tomada de decisão posterior por 
parte dos gestores. A Figura 12 mostra a tela inicial do Test Manager. O Test 
Manager roda diretamente no navegador web, e com ele é possível personalizar 
determinados valores passado por parâmetro, para isso é necessário que o 
desenvolvedor do script tenha passado esse parâmetro e escrito o script de forma 
dinâmica, atendendo assim o desejo do usuário e não de forma estática, onde o 
valor pré-determinado ficará no código fonte. 
 39 
 
Figura 12 - ATS Test Manager 
 
Fonte: ATS – Test Manager: autoria Própia 
4.7 PROVA DE CONCEITO (AUTOMAÇÃO) 
Segundo (Carsten, 1989) prova de conceito tem como seu principal objetivo 
provar o conceito (teórico) de uma pesquisa através de um experimento prático. 
Para a execução da prova de conceito, foram definidos os seguintes procedimentos: 
 Definir em que ambiente o teste será executado; 
 Definir o critério de teste a ser executado 
 Definir quais os modelos, softwares ou aplicações serão testados. 
A fabricante disponibilizou quatro modelos (amostras) já disponíveis no 
mercado mobile para o teste de automação. Para cada amostra os 65 casos de 
testes de customização foram executados. Essas amostras possuem configurações 
e características diferentes, inclusive o sistema operacional android. O Objetivo é 
verificar o comportamento da automação em diferentes softwares, amostras, 
características, performance, sistema operacional Android e verificar o 
comportamento da automação do processo de FOTA diante destas caracteristicas. A 
 40 
Figura 13 mostra as amostras selecionadas e a Tabela 4 as características principais 
dos modelos selecionados. 
Figura 13 - Amostras selecionadas 
 
Fonte: http://www.tudocelular.com/compare 
 
Tabela 2 - Características amostras 
Fonte: http://www.tudocelular.com/compare/ 
 Após a seleção das amostras, um único script de automação foi desenvolvido 
para ser executado nos quatro modelos testados. Durante o desenvolvimento do 
script houve a necessidade de contemplar os 65 casos de testes da customização 
do FOTA. 
A Customização é um processo de identificação das configurações e valores 
default encontrados no dispositivo e em seguida modificar esses valores para outros 
valores quaisquer. Podemos destacar alguns valores que sofrem modificações 
como: quantidade de gravações de voz, mensagens recebidas, alarmes, eventos no 
http://www.tudocelular.com/compare
 41 
calendário, games baixados, linguagem do aparelho, total de estações de rádios 
salvas etc. são adicionados em uma planilha do excel. Normalmente esses valores 
são zero. A Figura 14 mostra a planilha excel com alguns valores possíveis de 
customização. As configurações default para cada funcionalidade é selecionado e 
preenchido na coluna rosa com título “Default value After factory reset”. 
 
Figura 14 - ATS Customization 
 
Fonte: ATS Customization: autoria Própia 
 
Após a customização dos 65 casos de testes o software deve ser atualizado e 
os valores encontrados após a atualização é inserido em uma terceira coluna desta 
planilha. O objetivo deste processo é validar a integridade das informações do 
usuário após o processo de atualização de software. Caso a atualização efetue 
modificações para outros valores quaisquer ou retorne ao valor default o teste é 
falhado e um bug deve ser reportado para correção do desenvolvedor. Caso o valor 
encontrado após o FOTA seja o mesmo valor da customização o teste é aprovado. 
Esse processo quando realizado manualmente, demanda um tempo 
considerável, é repetitivo, e suscetível a erro humano. Devido a esse problema 
houve a necessidade de automação de todo esse processo, para isso scripts foram 
 42 
escritos para simular esses cenários. Por fazer uso de uma ferramenta proprietária, 
o ATS identifica facilmente o comando android que executa o alarme (clock) por 
exemplo, para isso basta selecionar a tecla space do teclado que várias dicas da 
feature é mostrado. As Figuras 15 e 16 demonstra as vantagens de uso do ATS. 
 
Figura 15 - ATS Scenario Alarm 
 
Fonte: ATS Scenario Alarm: autoria Própia 
 
 
Figura 16 - ATS Comandos 
 
Fonte: ATS Comandos: autoria Própia 
 43 
def getscenarioparameters(): 
 scenarioparameter = 0 
 
 aux = system.getscenarioparameter('number of 
wi-fi to add') 
 if aux != '': 
 try: 
 scenarioparameter = int(aux) 
 setnumberofwifis(scenarioparameter) 
 
 except valueerror: 
 system.finish(t_failed, 'failed to get 
number of wi-fi to add', job_stop) 
def setnumberofwifis(scenarioparameter): 
 global numberofwifis 
 
 numberofwifis = cenarioparameter 
def getnumberofwifis(): 
 global numberofwifis 
 return numberofwifis 
 
def skiptutorial(): 
 if dev1.uiclickbytext('cancel') == 
at_success: 
 if dev1.uiclickbytext('no') == 
at_success: 
 dev1.uiclickbytext('close tutorial') 
 
 dev1.sleep(2) 
 
A automação do AddWifi, visa cadastrar cerca de (100) cem redes APN 
(Access Point Name) no dispositivo. O APN é extremamente importante para a 
conexão entre o dispositivo e a operadora. Como essa tarefa é árdua, chata de ser 
executada e repetitiva, o ato de criar manualmente para cada projeto diferente cem 
redes APNs é bastante cansativo, devido a isso o seguinte script foi desenvolvido no 
ATS. 
 44 
def setStateByTypeIndex(type, index, state): 
result = DEV1.UISetStateCheckableObjectByTypeIndex(type, index, state) 
 if result != AT_SUCCESS: 
 index = 0 
 for i in range(0, 3): 
 result, actual = DEV1.UIGetStateCheckableObjectByTypeIndex(type, i) 
 if result == AT_SUCCESS: 
 if actual: 
 result = DEV1.UISetStateCheckableObjectByTypeIndex(type, i, state) 
 if result == AT_SUCCESS: 
 break 
 else: 
 System.Finish(T_FAILED, 'Failed to activate Wi-Fi', JOB_STOP) 
 
 
 DEV1.debugMessage('Start creation of Wi-Fi') 
 for i in range(0, getNumberOfWifis()): 
 DEV1.KeyPressByAlias('menu') 
 DEV1.sleep(2) 
 DEV1.UIClickByText(DEV1.regexParser('Add'), 0, UITarget.Popup) 
 DEV1.sleep(2) 
 text = 'Wi-Fi ' + str(i + 1) 
 DEV1.UISetTextByHint(DEV1.regexParser('SSID'), text, True) 
 DEV1.sleep(1) 
 DEV1.UIClickByTypeIndex('avwSpinner', 0) 
 DEV1.sleep(1) 
 DEV1.UIClickByText(DEV1.regexParser('PSK'), 0, UITarget.Popup) 
 DEV1.sleep(1) 
 DEV1.UIClickByText('Done', 0, UITarget.SoftKeyPad) 
 DEV1.sleep(1) 
 DEV1.UISetTextByName('password', '12345678', True) 
 DEV1.sleep(1) 
 DEV1.UIClickByText('Connect') 
 DEV1.debugMessage(text + ' created') 
 DEV1.sleep(1) 
 DEV1.debugMessage('Wi-Fi creation finished') 
 
 No código acima no método “setNumberOfWifis” a variável global 
“numberOfWifis” recebe por parâmetro o valor digitado pelo participante no 
TestManager. No método “getNumberOfWifis” essa variável é retornada. O prefixo 
DEV1, corresponde ao dispositivo móvel conectado no momento. Ainda no primeiro 
quadro negro é apresentado um menu que possibilita o usuário ao clicar no texto 
cancelar o processo de adição de APNs. No método “getScenarioParameters” a 
variável “aux” irá contar e mostrar no TestManager os números de APNs que forem 
adicionados em tempo real, caso ocorra algum erro uma exceção será lançada. No 
segundo quadro do código o método “setStateByTypeIndex” recebe três parâmetros 
do dispositivo: “type” “index” e “state”, enquanto um destes três parâmetros não 
forem preenchidos com sucesso, ocorrerá um erro na execução da automação, 
porém a automação tentará três vezes a checagem do preenchimento destes três 
parâmetrosaté a obtenção do sucesso dos mesmos, caso isso não ocorra o código 
é finalizado e uma mensagem de erro é apresentada. Caso os três parâmetros 
passados e as pré-condições como idioma em inglês estejam atingidas a automação 
 45 
iniciará no método main. Para identificar os APNs adicionados de 0 a 100 a função 
STR é utilizada para adicionar o texto “Wi-Fi” com o número de APNs adicionados. 
A codificação no ATS é bastante simples, em determinadas situações os 
valores que não sofrem modificações são adicionados estaticamente no código e 
valores que podem variar são solicitados via parâmetro pelo TestManager, que roda 
diretamente no navegador web. 
Após a codificação do script, o participante importa o código desenvolvido no 
ATS/Eclipse para o TestManager e executa a automação. Finalmente após o término 
da automação, o ATS gera uma planilha excel mostrando os valores default, valores 
que sofreram customização e os valores obtidos após o processo de FOTA, 
respondendo inclusive se o teste foi aprovado PASSED quando os valores não 
sofreram modificações ou FAILED (falha) quando sofreram modificações. A Figura 
17 mostra a planilha de customização completa após todo o processo de automação 
e com os resultados que serão enviados para o cliente. 
 
Figura 17 - ATS After Automação 
 
Fonte: ATS after automação: autoria Própia 
 
 46 
Há quatro bugs identificados pela ferramenta ATS e grifado na planilha em 
vermelho como como “Failed”: 
1. O usuário escolheu uma foto de família como wallpaper e após o FOTA foi 
modificada para o wallpaper default do dispositivo; 
2. A fonte escolhida foi Purewhite e o tamanho foi small, após o FOTA foi 
modificado para NewSmartGothic e o tamanho médium; 
3. A Linguagem escolhida foi o English e após o FOTA foi modificado para o 
Coreano; 
4. O Time Zone escolhido foi o Argentina Standard Time e após o FOTA foi 
modificado para o Coreano Standard Time. 
 
Estes bugs serão reportados para que o desenvolvedor possa corrigi-los. 
Devido a diversidade de modelos, tamanhos de telas, recursos e funcionalidades 
existentes nos dispositivos móveis o script desenvolvido não conseguiu cobrir com 
perfeição três funcionalidades, sinalizando assim como: Check Manually. Portanto 
para trabalhos futuros há uma necessidade de desenvolver novos scripts para cobrir 
esses novos recursos inseridos. Uma outra limitação da ferramenta ocorre quando 
uma nova versão do Android é disponibilizada pelos desenvolvedores da google, na 
qual torna necessário a revisão e refatoração do script de automação afim de validar 
as novas funcionalidades inseridas no OS. 
 
 
 47 
ESTUDO DE CASO 
Baseando-se na prova de conceito, ambiente de teste, ferramenta ATS, 
critérios utilizados na automação, técnicas de teste de software aplicadas e amostras 
selecionadas, o seguinte estudo de caso visa obter dos usuários que executam os 
testes de FOTA sua percepção de utilidade na execução, tempo de execução, 
eficiência e produtividade da feature após todo o processo de automação. 
5.2 SELEÇÃO DOS PARTICIPANTES 
Os participantes para esse estudo foram obtidos através de uma lista de 100 
participantes de uma empresa especializada em teste de software. Entretanto, para 
participarem do estudo os participantes tiveram que: 
 
 Manifestar interesse em participar do estudo; 
 Possuir certificação internacional do ISQTB; 
 Ter mais de três anos de experiência de teste de software; 
 Ter conhecimento em automação de software; 
 Ter executado os testes da feature FOTA pelo menos uma vez. 
 
Os cinco requisitos propostos foram solicitados pela fabricante, afim de 
viabilizar e validar ou não a automação da feature FOTA. Sete participantes foram 
selecionados para executarem a automação dos testes funcionais no processo de 
FOTA de dispositivos móveis. Entre os sete participantes apenas o autor deste 
trabalho participou na criação dos scripts de automação, enquanto os demais 
participaram na execução da automação. 
5.3 MÉTRICAS 
Os 65 casos de teste da feature de customization foram automatizados, para 
isso foi analisado o tempo de execução dos casos de testes em duas partes: 
 48 
1. Tempo de Execução (TE), é o tempo de execução gasto em um 
conjunto de casos de testes segundo a sua funcionalidade. A Tabela 5, 
separa as sete funcionalidades e o total de casos de teste por funcionalidade. 
 
Tabela 3 - Quantidade de casos de teste por funcionalidades 
APP CALL MM MSG AV CONN PIM 
8 5 12 7 13 7 13 
Fonte: Quantidade de casos de testes por funcionalidades: autoria Própia 
 
2. Tempo de Execução Total (TT), é o tempo total dos 65 casos de testes 
e considera todo o processo de teste, desde a configuração dos ambientes, 
instalação do ETA, e execução do script no teste manager até a apresentação 
dos resultados. 
 
Foi analisado também o número de caso de testes que falharam nos dois 
ambientes de testes (manual x automatizado) 
5.4 ANÁLISE E EXECUÇÃO DO ESTUDO 
Os participantes selecionados obtiveram um pequeno treinamento para 
definir a ordem de execução da automação. Foi instruído os passos a serem 
seguidos ao executarem os testes de forma manual e de forma automatizada. Os 
únicos pré-requisitos antes do início dos testes foram que as amostras estivessem 
com o nível de bateria acima de 70%, para garantir que a mesma não irá 
descarregar no decorrer dos testes, o segundo pré-requisito é que a amostra já 
esteja com o software instalado. Os passos para cada execução foram definidos 
conforme a Tabela 6 e os tempos TE e TT foram colhidos. 
Durante a execução dos testes manuais algumas técnicas de teste de 
software podem ser utilizadas, como por exemplo o teste exploratório. Um exemplo 
do teste exploratório é quando não é possível customizar uma determinada feature 
devido a algum bug na mesma, por exemplo: se o bluetooth estiver com o bug de 
crash ou overlap ao modificar o seu nome o teste não poderá ser executado 
justamente devido a esse bug. Para contornar este problema é aplicado um N/A 
(Não Aplicável) no teste e o mesmo é encaminhado ao participante responsável pelo 
reporte deste tipo de bug. 
Na Tabela 4 é possível observar o ganho de tempo, entendimento e 
 49 
produtividade nos passos a serem realizados para executar a mesma tarefa. 
Enquanto no teste manual foram necessários 17 passos, no teste automatizado 
apenas 4 passos foram utilizados. A seguir outros dados colhidos e analisados são 
mostrados corroborando assim a prova de conceito em relação as vantagens obtidas 
após a automação. 
 
Tabela 4 - Passos para execução dos testes por tipo 
TIPO PASSOS 
MANUAL 1° Registrar data e hora de início dos testes; 
2° Abrir a planilha de FOTA, na aba de customization. 
3° Iniciar o contador de tempo, marcando a data e hora do 
início do teste. 
3° Executar os 8 casos de teste de APP 
4° Anotar a hora de término dos 8 casos de teste de APP. 
5° Executar os 5 casos de teste de CALL 
6° Anotar a hora de término dos testes de CALL. 
7° Executar os 12 casos de teste de MM; 
8° Anotar a hora de término dos testes de MM. 
9° Executar os 7 casos de teste de MSG; 
10° Anotar a hora de término dos testes de MSG. 
11° Executar os 13 casos de teste de AV; 
12° Anotar a hora de término dos testes de AV. 
13° Executar os 7 casos de teste de CONN; 
14° Anotar a hora de término dos testes de CONN. 
15° Executar os 13 casos de teste de PIM 
16° Anotar a hora de término dos testes de PIM. 
17° Registrar data e hora de finalização dos testes; 
AUTOMA
TIZADA 
1° Registrar data e hora de início dos testes; 
2° Acessar o Test Manager e selecionar onde a planilha será 
salva. 
3° Iniciar a automação. 
4° Registrar data e hora de finalização dos testes; 
Fonte: Passos para execução dos testes por tipo: autoria Própia 
 
5.4.1 Análise Quantitativa 
Neste estudo foi realizado uma análise quantitativa em cima dos dados 
obtidos. Os dados de tempo foram coletados separadamente, primeiro