FREVoz – Um Framework para Automação de
Testes de Voz
Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br <www.cin.ufpe.br/~posgraduacao>
Recife
2017
FREVoz – Um Framework para Automação de Testes de
Voz
Este trabalho foi apresentado à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Fe-deral de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.
Orientador: Prof. Juliano Manabu Iyoda, Ph.D.
Recife
2017
Catalogação na fonte
Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217
S586f Silva, Alex Antônio Cândido
FREVoz: um framework para automação de testes de voz / Alex Antônio Cândido Silva. – 2017.
111 f.:il., fig., tab.
Orientador: Juliano Manabu Iyoda.
Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn, Ciência da Computação, Recife, 2017.
Inclui referências.
1. Engenharia de software. 2. Teste de software. I. Iyoda, Juliano Manabu (orientador). II. Título.
005.1 CDD (23. ed.) UFPE- MEI 2017-174
ALEX ANTÔNIO CÂNDIDO SILVA
FREVoz - Um Framework para Automação de Testes de Voz
Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Mestre em Ciência da Computação
Aprovado em: 07/03/2017.
BANCA EXAMINADORA
____________________________________________ Prof. Dr. Alexandre Cabral Mota
Centro de Informática / UFPE
__________________________________________ Prof. Dr. Lucas Albertins de Lima
Departamento de Estatística e Informática/DEINFO __________________________________________
Prof. Dr. Juliano Manabu Iyoda Centro de Informática / UFPE
Primeiramente, gostaria de agradecer a Deus por estar sempre presente em minha vida, me iluminando com sua luz e sabedoria tão necessárias para enfrentar e superar os desafios diários. Onde sem Ele e por meio Dele nada disso seria possível. Obrigado Senhor por mais uma etapa vencida!
Com carinho, agradeço a minha mãe, Marluce Candido Silva, fruto imensurável de toda minha admiração, carinho e respeito. Por toda sua dedicação e garra não medindo esforços para me ver sempre feliz. A meu pai, Antônio Fernando, pela sua genuinidade, proporcionando momentos de descontração e bom humor que se fazem necessário.
Também gostaria de agradecer a amizade e parceria durante esses mais de 13 anos de convívio diário, que se estende desde os tempos de infância, passando por escola, graduação, perdurando até hoje na pós-graduação e vida profissional, ao meu amigo-irmão Robert Gomes Melo. Sua presença foi muito importante durante a conclusão deste ciclo. Agradeço à minha namorada pelo incentivo, paciência e apoio incondicional. Agra-deço a todos os meus amigos e familiares pelas demonstrações de apoio.
Gostaria de agradecer de maneira especial ao meu professor orientador, Juliano Iyoda, pela compreensão, disposição e amizade. Além de todo o suporte e atenção que me foi dado, ajudando, motivando e sempre acreditando na elaboração deste trabalho. Pela confiança e ajuda, meu sincero Muito Obrigado!
Agradeço também ao Convênio CIn/UFPE Motorola pela oportunidade de poder contribuir para a otimização das atividades de teste realizadas no projeto. Agradeço aos meus colegas de trabalho pelo incentivo e a saudável convivência diária. Em especial, gostaria de agradecer pela flexibilidade e incentivo contínuo que me foi dado por duas pessoas bastante especiais na minha vida profissional e pessoal, dois grandes amigos que o trabalho me deu, Eduardo Tavares e Gergana Angelova, que foram muito mais que gerentes durante a elaboração desse trabalho, estando sempre ao meu lado, apoiando e de acordo com o desenvolvimento dessa solução.
Espero que esse esforço possa vir a colaborar no desempenhar das atividades diárias de diversos profissionais da área. Afinal, segundo Albert Einstein "A ciência, como um
todo, não é nada mais do que um refinamento do pensar diário", desse modo, que a ciência
desenvolvida através deste trabalho possa estar à disposição do homem facilitando sua vida.
a mais baixa, tenha sempre como meta muita força, muita determinação e sempre faça tudo com muito amor e com muita fé em Deus, que um dia você chega lá. De alguma maneira você chega lá."
Teste de software é uma das atividades desempenhadas durante o ciclo de desenvolvimento de um software. Ele é o principal responsável por garantir a qualidade do produto sob desenvolvimento. Essa atividade está presente nos diversos tipos de produtos de software desenvolvidos, desde aplicações desenvolvidas em plataformas para desktop, web e disposi-tivos móveis. A tecnologia presente nos disposidisposi-tivos móveis tem facilitado cada vez mais a vida do usuário final enquanto as possibilidades de interação tem se tornado mais natural através de novos tipos de interfaces de interação por gestos e voz. As interações mais tradicionais como o toque na tela não são mais consideradas desafiadoras, uma vez que são amplamente suportadas pelos frameworks de automação de teste disponíveis no mercado, diferentemente das interações através da voz humana, que não possuem ferramentas com tal suporte. Diante desse cenário, esse tipo de teste acaba sendo executado de forma manual, onde o testador precisa interagir diretamente com o dispositivo através da voz, ou então manipular em tempo real ferramentas que possibilitem a execução de arquivos de áudio com gravações dos comandos de voz. O trabalho proposto, FREVoz – Um Framework para Automação de Testes de Voz, adiciona uma nova camada de comunicação ao framework FREVO, estendendo-o e permitindo-o o desenvolvimento de casos de teste com suporte a manipulação de áudios. Através dessa extensão, o desenvolvedor de testes automáticos consegue desenvolver e executar casos de teste de voz de maneira automática. FREVoz apresenta-se como uma alternativa viável para o desenvolvimento de scripts de automação de testes baseado em UI Automator, apesar de ser possível aplicar seus conceitos para outros tipos de tecnologias de automação de testes. Um estudo de caso foi realizado através da automação de uma suíte de testes de voz com o objetivo de comparar o tempo total gasto na execução através das duas abordagens, manual e automática. Também foi realizado um experimento com 3.840 execuções de casos de teste, possibilitando exercitar a aplicação de reconhecimento de voz disponível nos dispositivos móveis na plataforma Android, o Google Voice Search, para 16 comandos válidos contendo 3 variações de áudios com qualidade e entonação diferentes. Cada uma dessas variações foi executada 10 vezes em 8 idiomas suportados, com o propósito de avaliarmos o comportamento da aplicação
Google Voice Search perante o reconhecimento desses comandos, bem como realizarmos
uma avaliação da qualidade dos recursos de áudio utilizados. Neste experimento, simulamos alguns dos testes de voz realizados dentro do contexto do convênio entre o Centro de Informática da Universidade Federal de Pernambuco e a Motorola.
Palavras-chave: Engenharia de Software. Teste de Software. Automação de Testes. Teste
Software testing is one of the activities performed during the software development cycle. It is primarily responsible for ensuring the quality of the product under development. Testing is present in the various types of software products developed, from applications developed for desktop and web up to mobile platforms. The technology present in mobile devices has increasingly facilitated the life of the end user. For instacne, the ways of interaction have become more natural through new types of interfaces like gestures and voice. More traditional interactions such as touch screen are no longer considered challenging, since they are widely supported by the test automation frameworks available in the market. Differently, interactions through the human voice, which do not have tools with such support, are still a challenge. Given this scenario, this kind of test is executed manually, where the tester needs to interact directly with the device through her voice, or to manipulate real time tools to play audio files containing the commands that will exercise the voice feature. This work introduces FREVoz – A Framework for Automation of Voice Testing. FREVoz extends the framework FREVO by adding a new layer of communication that allows the development of test cases with support for audio manipulation. Through this extension, test developer can automatically program and execute voice test cases.FREVoz is presented as a viable alternative to the development of test automation scripts based on UI Automator, although it may be possible to apply its concepts to other types of test automation technologies. A case study was carried out through the automation of a suite of voice tests with the objective of comparing the total time spent in execution through the two approaches, manual and automatic. An experiment was also carried out with 3,840 test cases, making it possible to exercise the speech recognition application available on mobile devices on the Android platform, Google Voice Search, for 16 valid commands containing 3 variations of audios with different quality and intonation. Each of these variations was performed 10 times in 8 supported languages in order to evaluate the Google Voice Search application behavior in recognizing of these commands, as well as to perform an evaluation of the quality of the audio resources used. Thus, we have simulated some of the voice tests made within the context of the cooperation project between the Center of Informatics of Federal University of Pernambuco and Motorola.
Keywords: Software Engineering. Software Testing. Test Automation. Voice Testing. UI
Figura 1.1 – FREVoz: antes da execução. . . 20
Figura 1.2 – FREVoz: depois da execução. . . 20
Figura 2.1 – Diferença entre Erro, Defeito e Falha. . . 23
Figura 2.2 – Modelo "V"contendo as fases do ciclo de desenvolvimento × fases de teste. 27 Figura 2.3 – Inspeção de interface gráfica através do UI Automator Viewer. . . 33
Figura 2.4 – Processo de execução de scripts UI Automator em um dispositivo móvel. 36 Figura 2.5 – Processo de execução de scripts UI Automator em um dispositivo móvel. 38 Figura 2.6 – Diagrama de pacotes do framework FREVO. . . . 40
Figura 2.7 – Diagrama de classes do framework FREVO. . . . 41
Figura 2.8 – Diagrama de estados da execução de um caso de teste desenvolvido no framework FREVO. . . . 42
Figura 2.9 – Diagrama de classes de BaseTestCase e sua conexão com os demais integrantes do framework FREVO. . . . 43
Figura 2.10–Diagrama de pacotes da ferramenta FREVO. . . 46
Figura 2.11–Diagrama de classes contendo as principais classes do pacote gui. . . . 47
Figura 2.12–Diagrama de classes contendo as principais classes do pacote util. . . . 48
Figura 2.13–Diagrama de classes contendo as principais classes do pacote dao. . . . 48
Figura 2.14–Diagrama de classes contendo as principais classes do pacote model. . . 49
Figura 2.15–Diagrama de classes contendo as principais classes do pacote execution. 49 Figura 2.16–Artefatos necessários para realizar a integração entre o framework e a ferramenta FREVO. . . 50
Figura 3.1 – Pacote Definitions com a nova classe inserida pelo framework FREVoz. 56 Figura 3.2 – Diagrama de classes com os principais atributos e métodos da classe VoiceTestCase do framework FREVoz. . . . 57
Figura 3.3 – Diagrama de estados da execução de um teste de voz no framework FREVoz continua semelhante ao do framework FREVO. . . . 65
Figura 3.4 – Diagrama de pacotes da ferramenta FREVO com a introdução das funcionalidades do FREVoz. . . 65
Figura 3.5 – Diagrama de classes resumido do pacote voice. . . . 66
Figura 3.6 – Arquitetura cliente-servidor na classe VoiceService . . . 67
Figura 3.7 – Diagrama de classe resumido da classe VoiceService. . . . 68
Figura 4.1 – Configuração dos componentes durante execução de um teste de voz. . 73
Figura 4.2 – Configuração real dos componentes durante execução de um teste de voz. 74 Figura 4.3 – Tela principal da ferramenta FREVO listando os casos de teste de voz. 75 Figura 4.4 – Status da execução de um teste contido na suíte de testes. . . 75
Figura 4.7 – Detalhes da execução são exibidos na tela Test Result Details. . . . 78
Figura 4.8 – Execução bem sucedida do Código 3.5. . . 79
Figura 4.9 – Execução com falha do Código 3.5. . . 80
Figura 5.1 – Ilustração do experimento realizado. . . 89
Tabela 1 – Análise de execuções de testes de voz manuais. . . 18
Tabela 2 – Principais asserts disponíveis no JUnit.. . . 32
Tabela 3 – Principais métodos asserts disponíveis na classe UiDevice. . . . 34
Tabela 4 – Principais Classes disponíveis no UI Automator. . . 35
Tabela 5 – Principais características do framework e ferramenta FREVO. . . . 40
Tabela 6 – Relação entre os métodos padrões nos frameworks UI Automator e FREVO.. . . 44
Tabela 7 – Métodos dos providos pela classe VoiceTestCase. . . . 58
Tabela 8 – Principais métodos providos pela classe VoiceService. . . . 68
Tabela 9 – Comparação entre o tempo gasto da execução manual e automática em minutos. . . 81
Tabela 10 – Relação das categorias de comandos disponíveis no Google Voice Search e os comandos selecionados para realização do experimento. . . 87
Tabela 11 – Idiomas utilizados no experimento. . . 87
Tabela 12 – Resultados das execuções realizadas do comando 1 - "call alex". . . . . 90
Tabela 13 – Resultados das execuções realizadas do comando 2 - "send contact text long msg". . . . 91
Tabela 14 – Resultados das execuções realizadas do comando 3 - "send contact text short msg". . . . 91
Tabela 15 – Resultados das execuções realizadas do comando 4 - "send text". . . . . 92
Tabela 16 – Resultados das execuções realizadas do comando 5 - "send whatsapp". . 92
Tabela 17 – Resultados das execuções realizadas do comando 6 - "send whatsapp contact long msg". . . . 92
Tabela 18 – Resultados das execuções realizadas do comando 7 - "send whatsapp contact short msg". . . . 93
Tabela 19 – Resultados das execuções realizadas do comando 8 - "find item in youtube". 94 Tabela 20 – Resultados das execuções realizadas do comando 9 - "play beethoven on youtube". . . . 94
Tabela 21 – Resultados das execuções realizadas do comando 10 - "play on youtube". 95 Tabela 22 – Resultados das execuções realizadas do comando 11 - "open calendar". 95 Tabela 23 – Resultados das execuções realizadas do comando 12 - "remind me to pick up milk tonight". . . . 96
Tabela 24 – Resultados das execuções realizadas do comando 13 - "set alarm". . . . 96
Tabela 25 – Resultados das execuções realizadas do comando 14 - "take photo". . . 96
moon?". . . . 97
Tabela 28 – Ranking por comandos. . . 98
ADB Android Device Bridge pp.36,49, 68
API Application Programming Interface pp.32–34, 100, 101, 107,
108
FREVO Faster Results, Execution and Visualization pp.39, 68
JAR Java ARchive pp.35, 36, 50,69
SDK Software Development Kit pp.36, 101
STT Speech-to-Text p.108
TCP Transmission Protocol Information pp.67,68
TTS Text-to-Speech pp.51, 80,85, 107
V&V Verificação e Validação p.22
1 INTRODUÇÃO . . . 17
2 REFERENCIAL TEÓRICO . . . 22
2.1 Verificação e Validação de Software . . . 22
2.2 Teste de Software . . . 23 2.3 Abordagens de Testes . . . 25 2.4 Fases de Testes . . . 26 2.5 Tipos de Testes . . . 29 2.5.1 Teste funcional . . . 29 2.5.2 Teste de regressão . . . 29 2.5.3 Teste de desempenho . . . 29 2.6 Automação de Testes . . . 30 2.7 JUnit . . . 31 2.8 UI Automator . . . 33
2.8.1 Características do funcionamento do UI Automator . . . 35
2.9 FREVO – Um Framework e uma Ferramenta para Automação de Testes . . . 39
2.9.1 Descrição do Framework FREVO. . . 39
2.9.1.1 Arquitetura . . . 40
2.9.1.2 Classe BaseTestCase . . . 41
2.9.2 Descrição da Ferramenta FREVO . . . 45
2.9.2.1 Arquitetura . . . 46 2.9.2.2 Pacote gui . . . 47 2.9.2.3 Pacote util . . . 47 2.9.2.4 Pacote dao . . . 47 2.9.2.5 Pacote model . . . 48 2.9.2.6 Pacote execution . . . 49 2.9.2.7 Integração Ferramenta-Framework . . . 50 2.10 Testes de Voz . . . 50 2.11 Considerações Finais . . . 52 3 FREVOZ . . . 54 3.1 Objetivos . . . 54
3.2 Descrição do Framework FREVoz . . . 55
3.2.1 Arquitetura . . . 55
3.3.1 Arquitetura . . . 65 3.3.2 Pacote gui . . . 66 3.3.3 Pacote voice . . . 66 3.3.3.1 Classe VoiceService . . . 67 3.3.4 Pacote execution . . . 68 3.3.5 Integração FREVO-FREVoz . . . 69 3.4 Considerações finais . . . 69 4 ESTUDO DE CASO . . . 71 4.1 Configuração do ambiente . . . 71 4.2 Funcionamento passo-a-passo . . . 72 4.3 Visualização de resultados. . . 75
4.4 Automação de uma Suíte de Testes . . . 79
4.5 Considerações finais . . . 83
5 ANÁLISE DE QUALIDADE DE TESTES DE VOZ COM FREVOZ 85 5.1 Contexto . . . 85
5.2 Descrição do experimento . . . 86
5.3 Resultado do experimento. . . 90
5.4 Análise dos resultados . . . 98
5.5 Considerações finais . . . 99
6 TRABALHOS RELACIONADOS . . . 100
6.1 Soluções encontradas na indústria . . . 100
6.1.1 UI Automator . . . 100
6.1.2 Selendroid . . . 100
6.1.3 Robotium . . . 101
6.1.4 Appium . . . 101
6.2 Soluções encontradas na academia . . . 102
6.2.1 Zygon . . . 102
6.2.2 Reconhecimento de voz baseado em computador como uma alternativa à transcrição médica . . . 102
6.2.3 Uso de um telefone celular no controle de voz do robô móvel . . . 103
6.2.4 Avaliação de software educativo com reconhecimento de fala em indivíduos com desenvolvimento normal e atraso de linguagem . . . 104
6.3 Considerações finais . . . 104
1 INTRODUÇÃO
A atividade de teste de software é fundamental para a garantia da qualidade do software desenvolvido. Como afirma Molinari [1], ao investirmos em testes, estamos investindo diretamente em qualidade de software. Segundo Maldonado et al. [2], o teste de software pode ser considerado como uma atividade que permite a verificação e validação de um software. Tal verificação é alcançada através da análise dinâmica do sistema, ou seja, por sua execução com o intuito de encontrar possíveis erros ou aumentar a credibilidade de que o software está funcionando corretamente.
Dada sua importância, testes de software são executados nos mais variados tipos de software, desde aplicativos desenvolvidos para desktop, aplicativos web para sites e, por fim, aplicativos desenvolvidos para dispositivos móveis.
Os dispositivos móveis evoluíram drasticamente nas formas de interação com o usuário em comparação com os computadores. Enquanto os computadores continuam restritos a cliques e arrastes de mouse, os dispositivos móveis permitem interações via
multi-touch, movimentos de pinça (pinches), rotações, translações, voz, gestos e reconhecimento
de imagem. Cada vez mais os aplicativos desenvolvidos para essa plataforma tomam vantagem destas diversas opções de interação disponíveis, criando assim aplicações cada vez mais interativas.
Essa variação de interações torna cada vez mais desafiadora as atividades de teste de software, principalmente no que diz respeito à automação de testes do tipo caixa-preta, uma vez que com esse tipo de teste deseja-se realizar ações semelhantes a de um usuário. A tecnologia utilizada no desenvolvimento de frameworks para automação de testes não evolui no mesmo ritmo que a tecnologia para desenvolver a aplicação, dificultando assim a automação de alguns cenários de interação. Algumas ferramentas mais tradicionais para automação de testes, como Selenium [3], lidam muito bem com interfaces clássicas, simulando sem dificuldades interações como toques simples do mouse ou a inserção de dados por meio do teclado, mas ao se deparar com os novos tipos de interação, esse
framework tem seu domínio reduzido.
Este trabalho se encontra diante desse desafio para automação onde praticamente não existem frameworks ou ferramentas que suportam os novos tipos de interação, como por exemplo a interação através da voz. Ou seja, como fazer para automatizar testes sob interfaces não clássicas como voz?
As funcionalidades providas pela interface de voz presente nos dispositivos móveis recentes têm, cada vez mais, ganho espaço no nosso cotidiano. É bastante comum a realização de ligações telefônicas sem o uso das mãos enquanto se dirige, por exemplo, ou
até a realização de pesquisas na internet através da voz, onde o usuário passa a conversar com o dispositivo ao invés de tocá-lo.
Dessa forma, os testes de voz precisam ser realizados a fim de garantir que esse recurso esteja funcionando como desejado. Insere-se nesse contexto o projeto de pesquisa realizado dentro do convênio entre a Motorola Mobility e o Centro de Informática da Universidade Federal de Pernambuco. Esse projeto é responsável pela execução de diversos tipos de teste nos dispositivos móveis, e o teste de voz é uma das atividades que tem demandado bastante esforço manual, exigindo assim uma atenção especial para possíveis possibilidades de automação.
A Tabela 1 ilustra informações extraídas de 12 suítes de execuções manuais de testes de voz no período compreendido entre dezembro de 2015 até dezembro de 2016 no contexto do convênio entre o Centro de Informática da UFPE e a Motorola. A Tabela 1 é composta pelas seguintes colunas:
• Suíte: um conjunto de casos de testes de voz;
• Qtd de Testes: a quantidade de casos de testes contidos em cada suíte; • Data: o período em que a suíte foi executada;
• Duração (h)1: a quantidade de tempo (em horas) gastas para executar a suíte manualmente por um testador experiente no domínio de testes de voz;
Tabela 1 – Análise de execuções de testes de voz manuais.
Suíte Qtd de Testes Data Duração (h)
A1 145 Dez/2015 11:00 A2 145 Dez/2015 11:00 B1 153 Jan/2016 11:00 B2 153 Jan/2016 11:00 C1 128 Mai/2016 08:00 D1 180 Jun/2016 12:00 D2 180 Jun/2016 12:00 C2 128 Out/2016 08:50 E1 120 Nov/2016 08:00 D3 180 Nov/2016 12:00 F1 62 Dez/2016 06:00 C3 128 Dez/2016 08:00 - 1702 - 118:50
Fonte: Elaborado pelo autor.
1 Durante a execução da suíte o testador executa outras atividades em paralelo, de modo a não
cronometrar o tempo exato gasto na execução de cada teste. Desse modo, o tempo de duração dessa execução poderia ser menor caso a essa fosse a única atividade realizada pelo testador.
Neste projeto desenvolvemos FREVoz, umframework e ferramenta para execução automática de testes de voz em dispositivos móveis. Com o FREVoz, o celular sob teste e um computador conversam entre si, onde o computador simula um ser humano (o microfone do computador são os ouvidos e as caixas de som, a voz). Esta execução automática reduz consideravelmente o tempo de interação humana na execução de testes de voz, uma vez que o testador precisa interagir com o dispositivo em dois momentos apenas: inicialmente é necessário apenas configurar fisicamente o ambiente de execução, como a disposição dos componentes bem como definir a suíte a ser executada e em seguida após o término da execução, o testador precisa realizar a análise dos casos de testes que necessitam intervenção manual na definição do resultado final, por exemplo analisando os áudios gravados pela execução (readout). As horas de execução de testes com voz mostradas na Tabela1 inclui a execução dos comandos de voz em si e a análise dos defeitos (se o teste passou ou falhou). Com o FREVoz, a execução e análise são na maioria dos casos de testes automáticas. Apenas nos casos de testes em que o resultado é definido explicitamente no corpo do script para ter seu resultado como indeterminado, se faz necessário uma análise mais detalhada por parte do testador a fim de validar o que aconteceu na execução.
Diante do contexto atual, onde a execução de casos de testes de voz é realizada de maneira manual, o desenvolvimento de FREVoz se faz necessária para prover uma solução que dê suporte a teste de voz. O FREVoz foi desenvolvido como uma extensão conservadora do FREVO [4], este é um framework e ferramenta que estende o principal
framework do Android para desenvolvimento de testes de interface gráfica do usuário, UI Automator [5], com diversas facilidades para automação de execução de suítes de teste.
O FREVoz faz questão de manter toda a compatibilidade e usabilidade existente no FREVO, permitindo ao usuário realizar o desenvolvimento e execução de scripts de voz automáticos, bem como fornece com riqueza de detalhes os artefatos resultantes da execução da suíte. Estes artefatos servem para posterior análise manual (atividade opcional) e contém os resultados obtidos e esperados (sejam eles imagens de screenshots ou áudios falados pelo celular). As Figuras 1.1 e 1.2 mostram as telas do FREVoz antes e depois da execução de uma suíte.
Por se tratar de um tema bastante atual, não encontramos na literatura muitos tra-balhos com as mesmas características, ou seja, que relacionem teste de software e interfaces de voz. O trabalho relacionado mais próximo é o Zygon (originalmente Automano) [6,7]. Zygon é uma ferramenta de capture and replay baseado em UI Automator que tem como principal característica a possibilidade dos usuários gravarem os comandos de toque, bem como a gravação de comandos de voz para posterior execução (replay). Os demais trabalhos apresentam automação de teste via frameworks (Selendroid [8], Robotium [9] e Appium [10]), mas nenhum lidam com comandos de voz. Outros trabalhos mais periféricos, executam experimentos com comandos de voz com fins médicos [11], de robótica [12] e
Figura 1.1 – FREVoz: antes da execução.
Fonte: Elaborado pelo autor.
Figura 1.2 – FREVoz: depois da execução.
Fonte: Elaborado pelo autor.
educacionais [13].
Em resumo, as principais contribuições deste trabalho estão listadas abaixo. • Projeto e implementação do framework e ferramenta FREVoz, uma solução para
suportar o desenvolvimento de scripts de voz automáticos no framework e ferramenta FREVO;
• Apresentação de um passo a passo que ilustra como FREVoz é usado para execução de testes de voz;
• Um experimento que utiliza FREVoz para analisar a qualidade das suítes de áudios usadas nos testes de voz no convênio do Centro de Informática da UFPE com a Motorola. Neste experimento, foram executados 3.840 testes de voz contendo 16 comandos diferentes sendo pronunciados por 3 áudios diferentes em 8 línguas. Os resultados mostraram que nenhum dos comandos testados obtiveram 100% de sucesso em seu reconhecimento, o idioma com melhor percentual de sucesso foi o italiano.
Os capítulos a seguir estão organizados na seguinte forma. No Capítulo 2, é apresentado o levantamento teórico fundamental para o entendimento e elaboração desse trabalho. Os principais objetivos do trabalho são apresentados em detalhes no Capítulo 3, as mudanças introduzidas tanto na ferramenta FREVO, como noframework são exibidas. O Capítulo 4apresenta como acontece uma execução de um teste de voz usando oframework FREVoz integrado no FREVO e um estudo de caso que realiza a automação de uma suíte de testes de voz, demonstrando as vantagens da execução automática em relação à execução manual. O Capítulo 5 descreve um experimento mostrando como FREVoz pode ser utilizado para avaliação da qualidade de suítes de áudios. O Capítulo 6apresenta os principais frameworks e ferramentas disponíveis no mercado e na academia que possuem relação com o trabalho proposto. Finalmente, no Capítulo 7são apresentadas as principais conclusões bem como possíveis evoluções ou desdobramentos desse trabalho no futuro.
2 REFERENCIAL TEÓRICO
Neste capítulo iremos apresentar uma visão geral acerca dos principais conceitos relacionados ao tema Teste de Software e Automação de Testes.
2.1
Verificação e Validação de Software
Segundo Wallace e Fujii [14], uma das importantes disciplinas de Engenharia de software é conhecida como Verificação e Validação (V&V), que tem como objetivo principal possibilitar a construção de software com qualidade. Tal disciplina pode ser constituída como um conjunto de atividades responsáveis por realizar a análise e testes durante um ciclo de desenvolvimento de um software, permitindo a constatação se o mesmo atende corretamente e apenas às funções para o qual foi planejado, bem como possibilita também a medição da qualidade e confiabilidade do produto.
Para um melhor entendimento desta disciplina, a seguinte divisão pode ser feita para explicar melhor as definições, de modo que:
- Verificação corresponde ao conjunto de atividades que garantem que o soft-ware, ou uma funcionalidade específica do software está sendo implementada corretamente. Geralmente a seguinte pergunta é realizada para se concluir sobre essa questão: "Estamos construindo o produto corretamente?".
- Validação corresponde a uma análise de uma maneira mais ampla com o objetivo de saber se o sistema ou um componente satisfaz os requisitos desejados pelo cliente. Tal questionamento pode ser efetuado durante o processo de desenvolvimento ou ao término. Geralmente a seguinte pergunta é realizada para se concluir essa questão: "Estamos construindo o produto certo?".
De acordo com Perez [15], para realizar essa disciplina de V&V, duas técnicas de análise de software podem ser adotadas: estáticas e dinâmicas. O foco das técnicas estáticas de V&V é encontrar defeitos sem executar o software em questão, através de técnicas como a revisão e inspeção do código fonte. As técnicas dinâmicas de V&V têm o mesmo objetivo de encontrar defeitos, mas diferente das técnicas estáticas, essa abordagem prega pela execução do sistema com o intuito de exercitar o software em seus principais fluxos e casos de uso, permitindo analisar o comportamento do mesmo e possivelmente relatar problemas encontrados.
Teste de Software é a principal técnica dinâmica de V&V, a qual possibilita a execução do software permitindo a análise e levantamento de defeitos.
2.2
Teste de Software
Antes de começarmos a entrar em detalhes técnicos sobre o tema Teste de Software, se faz necessário definir melhor alguns termos comumente utilizados quando se está discutindo esse tema. O padrão IEEE 829-1990 [16] ajuda a esclarecer alguns desses termos: erro(mistake) ação humana que produz resultados incorretos, como por exemplo, a implementação errada de um algoritmo; Defeito (fault, bug): falha em um sistema que pode ocasionar uma anomalia ao tentar desempenhar sua devida função. Por exemplo, omissão de informações e cálculos incorretos; e Falha: ação inesperada no software. Por exemplo, o sistema apresenta resultados diferentes do planejado. A Figura 2.1ilustra esses conceitos.
Figura 2.1 – Diferença entre Erro, Defeito e Falha.
Fonte: Diferença entre Erro, Defeito e Falha, disponível em: <http://www.devmedia.com.br/ gestao-de-defeitos-no-teste-de-software-revista-java-magazine-94/21940>
Durante o desenvolvimento de uma aplicação, seu código precisa ser testado a fim de tentar descobrir a maior quantidade possível de erros que tenham ocorrido durante sua implementação. Essa verificação deve ser realizada desde as primeiras etapas do ciclo de desenvolvimento, até mesmo quando não se tem código pronto, as validações devem ser realizadas em requisitos e documentações com o intuito de evitar a propagação dos defeitos, tendo em vista que, quanto mais cedo, mais barato sua correção. Para Molinari [1], além de garantir que o produto planejado está sendo entregue de acordo com as especificações e necessidades, consegue-se maior satisfação do usuário, melhoria da imagem da empresa, maior redução das incertezas que cercam o software e redução do custo de manutenção do produto em produção.
Molinari [1] ainda conclui que a atividade de teste é um fator fundamental para garantia da qualidade de software e que, ao investirmos em testes, estamos investindo diretamente em qualidade de software.
O teste de software é composto por um conjunto de atividades que, quando plane-jadas com antecedência e conduzidas de maneira organizada, inevitavelmente aumentam e
garantem a qualidade do produto que está sendo analisado.
Segundo Pressman [17], "o teste de software é um elemento crítico da garantia de qualidade de software e representa a última revisão da especificação, do projeto e da codificação". Desse modo, percebe-se que o processo de teste ideal precisa ser executado não apenas ao término do ciclo de desenvolvimento, mas em todo o projeto de desenvolvimento, garantindo assim qualidade de ponta a ponta no projeto.
Os testes não podem ser considerados úteis apenas para identificação e posterior-mente correção dos erros encontrados em um produto, mas também através de testes é possível garantir que o sistema funciona de acordo com o seu projeto inicial, para o qual ele foi projetado, ou seja, de acordo com seus requisitos. Através dos testes, pode-se validar aspectos funcionais ou não funcionais do software.
Para Myers [18], teste de software é o processo de executar um programa com o objetivo de encontrar defeitos. Outra definição acerca do assunto é descrita pelo padrão IEEE 829-1983 [19], na qual teste de software é o processo de analisar um dado item de software para detectar as diferenças entre as condições existentes e as requeridas e avaliar as características deste item de software.
Myers [20] e Hazel [21] têm conceitos bem semelhantes acerca de teste de software, onde o primeiro descreve que teste de software é um processo, ou uma série de processos, desenvolvido para certificação de que o software faz o que ele foi projetado para fazer e nada além disso. Já Hazel descreve que testar é considerado o processo de certificar que o programa faz o que era suposto fazer.
O conceito sobre teste de software em que esse trabalho está baseado é definido por Maldonado et al. [2], o teste de software pode ser considerado como uma atividade que permite a verificação e validação de um software. Tal verificação é alcançada através da análise dinâmica do sistema, ou seja, por sua execução com o intuito de encontrar possíveis erros ou aumentar a credibilidade de que o software está funcionando corretamente.
Em seguida alguns outros conceitos encontrados na literatura da área são destaca-dos.
Pressman [17] afirma que 40% do esforço de desenvolvimento é gasto em teste e que, em projetos de software crítico (por exemplo, controle de voo ou monitoramento de reatores nucleares), o seu custo pode chegar a três vezes o custo de todas as outras fases de desenvolvimento. Ainda falando sobre custos, segundo Myers [18], aproximadamente 50% do tempo e mais de 50% do custo total de desenvolvimento de um produto de software é gasto em teste. De acordo com Harrold [22], nos casos em que o sistema desenvolvido é de nível crítico, o percentual é ainda maior.
Outros importantes conceitos de teste destacados por Pressman [23] e Pfleeger [24] são descritos a seguir. Mesmo que o sistema em questão seja de pequeno ou de médio
porte, testar o mesmo em sua totalidade, ou seja de maneira exaustiva, é algo impossível. Como nem sempre é factível exercitar todos os possíveis caminhos que um teste simples possa derivar durante sua execução, o mesmo se torna impraticável em um cenário de teste mais complexo.
Em testes de caixa-preta, é preferível que os testes seja conduzidos por terceiros, ou seja, pessoas que não realizaram o design (projeto) dos casos de teste. Quando os testes são executados por diferentes pessoas, a chance de se encontrar defeitos é maior que pela pessoa que criou o sistema sendo testado. A pessoa que desenhou aquele cenário, por estar mais envolvida com o mesmo, pode não notar alguns comportamentos inesperados, deixando-os passar despercebidos. Ao contrário do que acontece em testes de caixa-branca, onde em geral são criados pelos próprios desenvolvedores.
Os testes, quando são planejados com antecedência, no momento de sua execução, tem uma chance razoável de encontrar mais defeitos, bem como explorar melhor a aplicação. Assim, um plano de testes bem elaborado deve apoiar as atividades de testes incluindo os objetivos de cada tipo de teste, desde testes de unidade, integração e sistema, descrevendo como devem ser executados e quais são os resultados esperados para cada um, podendo determinar quando um dado teste é considerado como suficiente.
Assim que os primeiros requisitos da aplicação são definidos, e que uma parte do software apresenta as condições mínimas para se testar, os testes podem ser elaborados e iniciados, uma vez que, devido a evolução dinâmica do software, é praticamente inviável esperar para testar um produto quando o mesmo estiver pronto. Desse modo, novos testes devem ser elaborados e adicionados conforme o progresso do processo de desenvolvimento do produto, caracterizado pela adição ou modificação de requisitos seguidos da implementação de novas funcionalidades.
2.3
Abordagens de Testes
Encontramos na literatura as atividades de testes de software divididas entre duas abordagens: Testes Caixa-Preta (Black-Box Testing) e Testes Caixa-Branca (White-Box
Testing). A seguir iremos detalhar cada uma delas com conceitos encontrados na literatura.
• Teste Caixa-Preta: O termo "caixa-preta"é atribuído para essa abordagem de testes pois nela não se considera como o sistema está construído, de maneira a não ser possível enxergar como o software é por dentro. Durante esse tipo de teste, é levada apenas em consideração a especificação do software, de modo a identificar seus requisitos, bem como entradas e saídas esperadas. Beizer [25] afirma que, nessa abordagem, deve-se levar em consideração apenas as funcionalidades e características do software e não aspectos de implementação. Para Myers [18] e Pressman [26], os
testes dessa abordagem devem ser desenvolvidos para encontrar divergências entre o que o software faz e o que era esperado que o software fizesse (especificações). Para Molinari [27], o objetivo dos testes nessa abordagem é principalmente garantir que os requisitos funcionais, ou seja, os comportamentos do software estejam corretos. Também é possível realizar verificações a cerca dos requisitos não funcionais, como a performance de uma dada operação. Já Pressman [26] tem um conceito semelhante ao de Beizer [25], onde afirma que os testes caixa-preta são realizados nas interfaces do software com o intuito de demonstrar que as funcionalidades do mesmo estão corretas, de modo que os testes são desenvolvidos e realizados para garantir que a maior parte das entradas são adequadamente aceitas e as saídas são corretamente produzidas. Além disso, que a integridade dos dados é mantida durante o funcionamento do sistema. Pressman [26] conclui também que os testes caixa-preta não se preocupam com a estrutura interna do software enquanto valida seu funcionamento.
• Teste Caixa-Branca: Ao contrário do termo definido anteriormente, Pressman [26] define que a expressão "caixa-branca"é atribuída para a abordagem que se preocupa em uma minuciosa verificação dos detalhes de implementação. São realizados testes em caminhos lógicos como, por exemplo, testes em condições ou laços de repetição, tentando exercitar o software de várias perspectivas a fim de validar se o mesmo se comporta como esperado. Para Molinari [27], nessa abordagem, o objetivo é percorrer todas as linhas de código e suas variadas condições pelo menos uma vez, tentando garantir que as mesmas estejam corretas. Diversos testes devem ser realizados para garantir esse validação, como testes de decisões lógicas, laços, fronteiras, etc. Todos os caminhos devem ser exercitados, bem como as estruturas de dados utilizadas no código. É essencial que o encarregado por essa validação seja um engenheiro de testes com bom conhecimento da linguagem de programação utilizada no sistema. Pressman [26] define que os testes de caixa-branca são conhecidos também como testes estruturais que se encarregam de exercitar estruturas internas do software. Para isso, os testes são desenvolvidos com base no código do programa e têm como objetivo executar seus caminhos, condições, ciclos e estruturas de dados. A abordagem de teste caixa-branca é mais utilizada nas fases iniciais do teste, principalmente nos testes de unidades e um pouco nos testes de integração.
2.4
Fases de Testes
Para se testar um software durante o seu desenvolvimento é necessário organizar a atividade de testes de acordo com as etapas do ciclo de desenvolvimento de modo a permitir o melhor alinhamento possível entre as respectivas etapas. Tal abordagem é defendida por Pressman [26].
Um modelo bastante conhecido no desenvolvimento de software é o modelo V. Ele caracteriza-se pela realização de atividades de testes durante o ciclo de desenvolvimento de software. O modelo V é apresentado na Figura 2.2. Ele deve ser interpretado a partir da realização das atividades básicas do desenvolvimento e de testes, começando na parte superior esquerda (requisitos) avançando até a parte inferior (codificação - testes de unidade) e, em seguida voltando e terminando na extremidade superior direita (teste de aceitação).
Figura 2.2 – Modelo "V"contendo as fases do ciclo de desenvolvimento × fases
de teste.
Fonte: Elaborado pelo autor, baseado em Myers [18].
Dessa forma, é importante que os testes iniciais sejam feitos nas unidades mais básicas do software assim que a codificação inicie para que seja possível assegurar que unidades de mais baixo nível estejam funcionando adequadamente. E, posteriormente, se sua integração através de testes de interfaces entre as unidades e seus relacionamentos também funcionam corretamente, validando assim suas integrações básicas. Esses testes são bons exemplos de abordagem de testes de caixa-branca, uma vez que exercitam o código fonte da aplicação. Em seguida, os testes avançam para as camadas superiores de mais alto nível que, consequentemente, englobam as unidades menores anteriormente testadas. Neste momento, os testes funcionais são realizados com o intuito de verificar se os requisitos funcionais e não funcionais estão sendo alcançados. Esses testes podem ser considerados como testes de caixa-preta, já que validam as funcionalidades da aplicação sem analisar o código fonte. Dessa forma, as etapas de testes vão evoluindo de maneira segura, tendo em vista que, a partir de teste de unidades básicas, é possível avançar com
segurança para testes funcionais mais robustos.
A seguir, cada uma das fases de testes são exemplificadas em detalhes:
1. Teste de unidade: É a primeira fase de teste de um software onde os testes são focados em elementos menores do software, como pequenos trechos de código, tais como funções, procedimentos, métodos e classes, buscando verificar se essas unidades estão funcionando como esperado. São testes caixa-branca e geralmente esse tipo de teste é executado pelos próprios desenvolvedores. Copeland [28] define unidade como "o menor pedaço de software que um desenvolvedor cria". E Tian [29] reafirma que “uma unidade pode corresponder a uma função, um procedimento ou uma sub-rotina para linguagens de programação estruturadas tradicionais como C, PASCAL ou FORTRAN, ou corresponder a um método numa linguagem orientada a objeto como C++, Java e Smalltalk”.
2. Teste de integração: É a segunda fase de testes de um software onde os testes são focados nas interfaces entre os módulos e unidades testadas anteriormente, ou seja, na verificação se, quando os elementos são combinados ou integrados, funcionam como desejado. Ainda são considerados como testes caixa-branca por serem realizados no código fonte e por desenvolvedores. Rainsberger [30] afirma que estes testes não se preocupam com um comportamento de uma unidade específica como o teste de unidade descrito anteriormente. E Burnstein [31] destaca que, apesar dos testes isolados das unidades terem sido realizados com sucesso, apenas a execução dos mesmos não garante que quando combinadas irão se comportar como esperado. 3. Teste de sistema: É a terceira fase de testes de um software onde os testes são focados
em características funcionais e não funcionais, tais como validações de desempenho, hardware e base de dados a fim de verificar o comportamento do software sob a ótica de um sistema com diversos módulos integrados. De acordo com Elfriede [32], contrariamente aos testes unitários e de integração, é desejável que testes de sistemas sejam executados em um ambiente diferente do qual ele foi desenvolvido, mas que possua uma configuração semelhante ao ambiente que será submetido em produção no cliente. Para Burnstein [31], é interessante que esse tipo de teste seja realizado por uma equipe que não conheça as funcionalidades do sistema (requisitos funcionais), podendo também avaliar questões de desempenho (requisitos não funcionais). 4. Teste de aceitação: É a quarta e última fase de testes de um software onde os
testes são focados na validação por parte dos clientes que determinam se o software corresponde aos requisitos inicialmente elicitados. Como conclui Myers [20], o teste de aceitação é realizado para determinar se o produto satisfaz as necessidades do cliente, podendo ser divididos em testes funcionais e não funcionais.
2.5
Tipos de Testes
A seguir os principais tipos de testes abordados nesse trabalho serão apresentados. Cada um desses tem um objetivo de validação diferente, sendo assim categorizados em diferentes tipos e propósitos.
2.5.1
Teste funcional
Um dos principais e mais importantes tipos de teste de software é o teste funcional, uma vez que esse está diretamente relacionado com as exigências e expectativas de quem solicitou seu desenvolvimento, como os stakeholders. O teste funcional como o nome já diz é concentrado e elaborado para verificar se os requisitos funcionais do software estão de acordo com o esperado, como afirma Pfleeger [24].
2.5.2
Teste de regressão
Devido à constante evolução que o software é submetido, onde diariamente o mesmo passa por inúmeras modificações, faz-se necessário a realização de testes que verificam se tais mudanças não vieram a danificar seu funcionamento. Para Pressman [33] em um contexto de uma estratégia de teste de integração, o teste de regressão é a reexecução do mesmo subconjunto de testes que já foram executados, para assegurar que as alterações não tenham propagado efeitos colaterais indesejados. Os testes de regressão irão colaborar para que o software continue funcionando corretamente durante o ciclo de desenvolvimento. Pressman [33] também destaca que os testes de regressão podem ser executados manualmente através da reexecução de um subconjunto de todos os casos de testes disponíveis, ou se possível de maneira automática através de ferramentas de captura e reexecução ou de outras formas de automação existentes.
2.5.3
Teste de desempenho
Na maioria das vezes o software é desenvolvido em um ambiente isolado que muitas vezes não possui ou não se consegue simular algumas das características presentes no ambiente ou no cotidiano do usuário final. Devido a essa limitação os testes de desempenho são necessários para tentar cobrir algumas características não funcionais que os softwares apresentam e que precisam serem avaliadas quanto a sua resposta. Num contexto recente de dispositivos móveis, Pressman [33] comenta que durante os testes de desempenho, os testadores verificam os requisitos não funcionais como por exemplo, tempos de download, velocidade do processador, capacidade de armazenamento bem como da disponibilidade de energia da bateria. A fim de verificar se os requisitos de desempenho preestabelecidos estão dentro do limite aceitável.
2.6
Automação de Testes
As atividades de testes podem muitas vezes se tornar exaustivas e laboriosas, principalmente quando se deseja executar uma grande quantidade de casos de testes manualmente, dificultando assim a execução dos testes, bem como análise e controle de falhas, podendo assim impactar na qualidade do software. Segundo Sommerville [34], a fim melhorar a qualidade dos produtos desenvolvidos, bem como diminuir o tempo de execução dos testes, foram criados os testes automatizados, que proporcionam ao mesmo tempo um aumento na cobertura e a redução no tempo e consequentemente no custo da execução dos testes.
Dentre as vantagens de se utilizar automação de testes, Bernardo e Kon [35] comentam sobre a vantagem de se poder re-executar os testes quando desejar. Isto acontece, por exemplo, quando uma característica é acrescentada ao software ou acontece uma modificação em uma funcionalidade já existente. Neste caso, testes de regressão devem ser executados e, se tiverem sido automatizados, o custo de re-execução é baixíssimo em comparação com a re-execução manual. A utilização de automação pode diminuir o esforço, bem como o tempo gasto, além de também evitar erros que possam vir a acontecer devido à intervenção humana na condução dos testes.
Molinari [36] destaca que, devido à complexidade dos sistemas e o seu crescimento, torna-se inviável executar alguns tipos de testes manualmente. Também é preciso ressaltar que, dependendo do tipo de teste automático que está sendo desenvolvido, por exemplo tipo caixa-branca, é interessante que o engenheiro de automação tenha conhecimento a cerca da linguagem de programação no qual o sistema foi desenvolvido, a lógica de funcionamento do sistema e dessa linguagem, que ele conheça a ferramenta e a tecnologia que será utilizada para desenvolver os scripts automáticos. Ao desenvolver um caso de teste automático do tipo caixa-preta, não é necessário o conhecimento da linguagem na qual o sistema foi desenvolvido, apenas é necessário o conhecimento do framework que será utilizado para construção dos testes automáticos. Tais conhecimentos são essenciais para conseguir desempenhar essa atividade com propriedade.
Para se ter sucesso em um projeto de automação, é necessário que o mesmo seja bem elaborado, que seu plano seja definido com bastante organização para que não acabe gerando uma expectativa muito distante das reais possibilidades.
James [37] e Pettichord [38] concluem que o fracasso de muitas empresas quando adotam algumas soluções de automação se dá pela falta de atenção e comprometimento com os projetos de automação de testes quando comparados com projetos de sucesso de desenvolvimento de software dentro da mesma organização, levando-nos a perceber o descaso com esses projetos. Fatores como definição de requisitos e a construção de um projeto organizado com boas práticas de programação são muitas vezes deixados de lado,
acarretando em projetos mal sucedidos.
Reforçando a ideia de Molinari [36] quando destaca o conhecimento necessário para trabalhar com automação, Pettichord [39] comenta sobre a importância de ter a atividade de automação de testes de maneira dedicada e não dividida com outras tarefas. Kaner [40] destaca que o sucesso dessa atividade está diretamente relacionada com a capacidade técnica dos responsáveis por desempenhá-las, sugerindo que a mesma deveria ser encarada realmente como um projeto de desenvolvimento de software, e se possível, realizada por programadores seniores.
A automação de testes pode ser configurada em dois momentos. No primeiro, se faz necessário a criação automática de casos de teste e então a execução dos testes gerados, que pode ser de maneira automática ou manual. O segundo momento é responsável pela execução automática dos testes gerados anteriormente. Para Molinari [1], a diferença é que, no primeiro momento, o foco é apenas em testar, enquanto que, no segundo momento, uma ferramenta pode ser utilizado com o intuito de simular uma interação de um ser humano com a aplicação que está sendo testada. O mesmo ainda destaca três dimensões que podem ser usadas para distinguir um teste manual de um automático:
1. Dimensão efetiva: os testes, independente de como tenham sido implementados (manual ou automático), quando executados, devem alcançar os mesmos objetivos. 2. Dimensão evolutiva: é inevitável que um teste manual irá evoluir mais rápido que o mesmo teste automático, isso é justificável devido a ser conduzido diretamente por um ser humano.
3. Dimensão econômica: o teste automático é mais econômico quando começa a ser executado a partir da segunda vez, sendo, a partir daí, mais barato que o mesmo teste executado manualmente. Outro fator que contribui para a economia é que quanto mais o teste automático for reutilizado, menor será seu custo.
2.7
JUnit
Louridas [41] explica de maneira bem objetiva que o JUnit é uma biblioteca Java [42] de código aberto que objetiva tornar os testes de unidade mais simples de serem desenvol-vidos. A ideia é conseguir testar e codificar simultaneamente, para isso pequenos testes unitários são elaborados antes mesmo do código desejado ser implementado. A medida que os testes são realizados nos primeiros fragmentos de código existente, os programadores vão evoluindo o software, novos testes vão sendo desenvolvidos e executados. Se o teste falhar, os desenvolvedores prontamente corrigem o defeito. Caso o teste passe, o desenvolvimento continua e mais testes são desenvolvidos dentro do ciclo de desenvolvimento.
Todos os testes são mantidos com o código, de modo que, se o código em desen-volvimento sofrer modificações, é fácil realizar testes de regressão que garantem que as alterações não quebraram o software.
Nos testes unitários, nós exercitamos o código provendo entradas, quando necessário, e examinando o comportamento do código, geralmente na forma de sua saída. Uma maneira simples de fazer isso, e que os programadores têm usado há muito tempo, emprega um conjunto de instruções que comparam um determinado dado com o seu resultado esperado.
Um teste geralmente precisa de uma especificação, uma maneira de inicializar variáveis e criar objetos. No JUnit, a preparação ou configuração que antecede a execução de um teste é chamada de setup. Essa configuração inicial é independente das asserções, de modo que a mesma pode ser aplicada a vários testes individuais.
Quando um teste termina, a especificação pode exigir algumas ações de limpeza. No JUnit, essa ação é chamada de teardown. Essa ação garante que, ao término de cada teste, o mesmo volte ao estado inicial. Ou seja, qualquer configuração que tenha sido realizada pelo teste seja desfeita. Em seguida, se outro teste for realizado, a configuração (setup) será executada corretamente. Ambos os métodos de configuração (setup) e de limpeza (teardown) são chamadas fixas estabelecidas pelo JUnit.
Os testes individuais são chamados de casos de teste (test cases). Quando um projeto realiza testes unitários da maneira adequada, ele irá acumular uma grande coleção de casos de teste. Comumente, os programadores parecem executar alguns desses casos de teste juntos. Nas vezes em que isso ocorre, os testes podem ser combinados em conjuntos de teste (suítes) para serem executados dentro do mesmo e único grupo.
Um teste de unidade é uma porção de código escrita por um desenvolvedor com o objetivo de executar uma funcionalidade específica no sistema a fim de verificar um determinado comportamento ou estado. Na literatura, essa afirmação ou validação é chamada de assert. Um assert é basicamente uma comparação entre uma entrada variável (sistema a ser testado) e uma saída pré-definida. A Tabela 2 apresenta uma lista com
alguns dos asserts que são disponibilizados pelo JUnit.
Tabela 2 – Principais asserts disponíveis no JUnit.
Assert Ação
assertEquals(expected, actual) Assegurar que duas entradas são iguais.
assertNotEquals(expected, actual) Assegurar que duas entradas não são iguais. assertTrue(condition) Assegurar que uma condição é verdadeira.
assertFalse(condition) Assegurar que uma condição é falsa.
assertNull(object Assegurar que um objeto é nulo/inválido.
assertNotNull(object) Assegurar que um objeto não é nulo/inválido.
2.8
UI Automator
A biblioteca padrão de suporte para testes do Android (Android Testing Support
Library) fornece uma estrutura abrangente para testar aplicativos Android. Essa biblioteca
fornece um conjunto de APIs - Application Programming Interface (API) que permitem a rápida criação e execução de scripts de teste para seus aplicativos, incluindo JUnit 4 para testes de unidade e UI Automator [5] para testes de interface gráfica do usuário, compreendendo assim os testes funcionais.
Oframework UI Automator fornece um conjunto deAPIs que possibilita criar testes de interface do usuário em qualquer aplicativo do sistema. As APIs do UI Automator permitem executar um conjunto de operações como abrir aplicações ou arrastar um aplicativo para a tela inicial. Ou seja, ele permite a realização de algumas interações humanas de forma automática. A estrutura de testes do UI Automator é adequada para desenvolver testes automatizados de caixa-preta, no qual o código do teste não depende de detalhes internos de implementação do aplicativo que está sendo testado.
Os principais recursos doframework de teste do UI Automator incluem:
• UI Automator Viewer: Um visualizador que permite inspecionar a hierarquia dos componentes gráficos exibidos na interface de um dispositivo (Figura 2.3);
Figura 2.3 – Inspeção de interface gráfica através do UI Automator Viewer.
• Acesso ao estado do dispositivo: UmaAPI que permite recuperar informações acerca do estado do dispositivo que será utilizado na execução dos testes. Através da classe
UiDevice do framework de teste UI Automator, é possível acessar e executar algumas
operações no dispositivo que será utilizado na execução dos testes. Estes métodos são bastante úteis e permitem acessar propriedades do dispositivo, tais como verificar se o dispositivo está com a tela acesa, ou detectar a orientação atual do dispositivo. A Tabela3 apresenta algumas das inúmeras operações disponíveis na classe UiDevice.
Tabela 3 – Principais métodos asserts disponíveis na classe UiDevice.
Método Ação
wakeUp() Simula o pressionamento da tecla liga/desliga caso o dispositivo esteja com a tela desativada ou apagada.
isScreenOn() Verifica se a tela do dispositivo está ativada ou acesa.
getDisplayRotation() Retorna a atual rotação da tela do dispositivo. getProductName() Recupera o nome do produto do dispositivo.
openNotification Abre a notificação do dispositivo.
Fonte: Elaborado pelo autor.
• APIs do UI Automator: As APIs são capazes de interagir com diferentes elementos de interfaces gráficas sem a necessidade de conhecer detalhes da implementação dos aplicativos que se deseja testar. A Tabela 4 apresenta as principais classes que compõem a API do UI Automator. Através dessas classes é possível manipular os mais variados componentes gráficos entre os aplicativos desenvolvidos no Android.
Tabela 4 – Principais Classes disponíveis no UI Automator.
Classe Descrição
UiDevice Permite acessar informações de estado sobre o dis-positivo, como também possibilita simular ações do usuário no dispositivo, como pressionar o botões
Home e Menu.
UiObject É a representação de uma view que não está vin-culada diretamente com uma referência de objeto presente na tela.
UiObject2 É a representação de um elemento da UI, que ao contrário doUiObject, está vinculado a uma instância de exibição específica na tela, de modo que pode ficar obsoleto caso o objeto da interface seja destruído.
By É uma classe utilitária que possibilita a criação de seletores do tipo BySelector de uma maneira con-cisa. Seletores são formados pela especificação das características de um dado objeto (text, id, package,
etc), estabelecendo assim os critérios de busca para
encontrá-lo na tela.
BySelector É um seletor que especifica critérios para a identifi-cação de elementos de UI durante a chamada de um método como ofindObject(BySelector).
UiSelector Representa uma consulta para um ou mais elementos de UI.
UiScrollable Permite procurar por elementos em uma lista de rolagem.
UiCollection Enumera os elementos de UI com a finalidade de
contar ou acessar sub-elementos.
Configurator Permite definir parâmetros-chave para execução de
testes do UI Automator.
Until Fornece métodos para a construção de condições comuns, como por exemplo aguardar por a ocorrência de um evento.
Fonte: Elaborado pelo autor.
2.8.1
Características do funcionamento do UI Automator
Ao desenvolver scripts no framework UI Automator, um arquivo no formato Java
ARchive (JAR) é gerado como resultado da compilação de todos os scripts contidos em um determinado projeto de testes. Esse arquivo irá conter todas as classes que foram utilizadas durante o desenvolvimento do projeto de scripts. Após a geração desse arquivo, o mesmo precisa ser enviado para o dispositivo Android onde se deseja executar os scripts desenvolvidos. A Figura 2.4, adaptada de Melo [4], ilustra melhor esse processo.
Figura 2.4 – Processo de execução de scripts UI Automator em um dispositivo
móvel.
Fonte: Adaptado de FREVO - Um Framework e uma Ferramenta para Automação de Testes [4].
As ações ilustradas na Figura 2.4só podem ser executadas com o auxílio de uma ferramenta chamada Android Device Bridge (ADB), que é responsável por estabelecer uma ponte entre o computador e o dispositivo móvel. Essa ferramenta é disponibilizada juntamente com o kit de desenvolvimento do Android, conhecido como Android Software
Development Kit (SDK) que, em conjunto, permitem ao usuário realizar diversos tipos de interação com o dispositivo Android conectado ao computador. Através do console de comandos de qualquer sistema operacional, é possível instanciar o ADB e realizar a comunicação entre o computador e o dispositivo conectado à maquina. A Figura 2.4
apresenta os comandos mais importantes, bem como as ações necessárias para se iniciar uma execução de um script armazenado em um arquivo JAR gerado por um projeto UI Automator.
O Código2.1 ilustra um caso de teste desenvolvido usando algumas das principais classes e métodos disponíveis no framework UI Automator.
Código 2.1 – Exemplo de implementação de um script no framework UI
Automator.
public class LaunchSettings extends UiAutomatorTestCase {
public void testDemo() throws UiObjectNotFoundException {
// Inicia a execucao partindo da tela inicial Home getUiDevice().pressHome();
// Cria o objeto da bandeja de aplicativos contendo a descricao "Apps"
UiObject allAppsButton = new UiObject(new
UiSelector().description("Apps"));
// Clica no objeto Apps e aguarda por uma nova janela ser aberta allAppsButton.clickAndWaitForNewWindow();
// Cria uma colecao de objetos com a propriedade scrollable
UiScrollable appViews = new UiScrollable(new
UiSelector().scrollable(true));
// Define a colecao criada como do tipo vertical appViews.setAsVerticalList();
// Cria o objeto Settings buscando-o na colecao
UiObject settingsApp = appViews.getChildByText(new
UiSelector().className(android.widget.TextView.class.getName()),
"Settings");
// Clica no objeto Settings e aguarda por uma nova janela ser aberta settingsApp.clickAndWaitForNewWindow();
// Cria um objeto que contenha o pacote esperado da tela de Settings
UiObject settingsValidation = new UiObject(new
UiSelector().packageName("com.android.settings"));
// Realiza a validacao se existe um objeto contendo com o pacote esperado do app de Settings
assertTrue("Unable to detect Settings", settingsValidation.exists()); }
}
Ao término da execução do script, o resultado e outras informações da execução são exibidos no console de comandos do sistema operacional como mostrado na Figura 2.5.
Como é possível observar, a saída proveniente de uma execução de scripts UI Automator não é muito amigável e legível, fazendo com que o usuário tenha que analisar o
log resultante das execuções para poder extrair os resultados das validações inseridas nos
casos de teste. Ou seja, o usuário precisa percorrer o log buscando mensagens como as listadas abaixo, que irão informar o resultado ou o que aconteceu durante a execução:
Figura 2.5 – Processo de execução de scripts UI Automator em um dispositivo
móvel.
Fonte: Adaptado de FREVO - Um Framework e uma Ferramenta para Automação de Testes [4].
• Teste passou:OK (1 test)
• Teste falhou: FAILURES!!! Test Run: 1, Failures: 1, Errors: 0
• Erro durante a execução: FAILURES!!! Test Run: 1, Failures: 0, Errors: 1
Além da dificuldade na identificação dos resultados por ser necessário realizar a leitura e análise de um extenso log, o framework possui algumas outras características ausentes como:
• Re-execução: Não é possível realizar a re-execução automática de um script quando ele falha ou acontece algum erro durante sua execução. Ou seja, o framework por si só não possui nenhum tipo de configuração nativa que possibilite a re-execução automática dos scripts que não tiveram sucesso durante sua execução, como nos casos onde ele falhou ou enfrentou algum erro.
• Suítes de teste: Assumindo que cada script seja considerado um caso de teste único e independente, o framework não possibilita elaborar/organizar de maneira prática e/ou nativa a execução de uma suíte de casos de teste. Para suprir essa necessidade, é necessário que o testador elabore manualmente uma linha de comando que contenha o caminho para todos os scripts contidos no projeto UI Automator para que seja possível executar mais de um script em sequência. Uma outra maneira de simular a execução de uma suíte de casos de testes é implementando a suíte como sendo
um único caso de teste. Neste caso, cada caso de teste da suíte seria um método do script que será executado, o que poderia acabar por deixar o código bastante extenso e dificultando sua manutenção.
Tais características podem ser consideradas como limitações para o desenvolvimento e execução em escala de scripts automáticos, uma vez que se espera o máximo possível de agilidade e independência ao se automatizar casos de teste. Diante disso, o trabalho de Melo [4] destacado na Seção 2.9 adiciona algumas melhorias para esses pontos do
framework UI Automator.
2.9
FREVO – Um Framework e uma Ferramenta para Automação
de Testes
Faster Results, Execution and Visualization (FREVO) é um trabalho bastante recente desenvolvido por Melo [4], no qual é composto por dois componentes integrados (framework e ferramenta) que separam de maneira coesa as atividades de desenvolvimento descripts de testes individuais das atividades de automação e gerenciamento da execução de suítes de testes. O framework proposto fundamentalmente adiciona novas propriedades ao
framework UI Automator e cria um padrão na escrita de testes automáticos. A ferramenta
integra-se com esse framework, criando um ambiente de gerenciamento de execução de testes maduro e consistente, combinado a uma visualização de resultados de casos de teste intuitiva e usual por meio de uma interface gráfica.
Dessa forma o FREVO propõe resolver as principais lacunas encontradas no
framework de automação de testes UI Automator, através da extensão das funcionalidades
e adição de novas no âmbito do framework, além da construção de uma ferramenta que possibilita a manipulação e gerenciamento da execução dos casos de teste. A Tabela 5
contém as funcionalidades acrescentadas pelo FREVO tanto no nível do framework como na ferramenta.
As seções a seguir pretendem descrever de maneira objetiva as principais caracterís-ticas do framework e ferramenta FREVO que são base fundamental para o desenvolvimento desse trabalho.
2.9.1
Descrição do Framework FREVO
Segundo Melo [4], o framework caracteriza-se como uma evolução do framework UI Automator. A proposta do framework FREVO está centrada na solução das limitações existentes no UI Automator e na adição de novas características, incrementando a capaci-dade do framework UI Automator. Visando a integração com a ferramenta FREVO, o
