Descrição da Ferramenta FREVO

De acordo com Melo [4], a ferramenta FREVO se enquadra no contexto de aproveitar todos os artefatos providos pela execução de um teste do framework FREVO, podendo

proporcionar aos testadores uma interface gráfica para visualização de resultados de casos de teste, tornando o processo de análise de resultados mais intuitivo, objetivo e usual.

Para Melo [4], devido ao foco no aproveitamento dos artefatos gerados pelo fra-

mework FREVO e na solução dos problemas existentes no gerenciamento e execução

de testes UI Automator, a ferramenta FREVO consegue apresentar um processo de gerenciamento e execução de testes maduro e consistente.

A arquitetura da ferramenta será apresentada nas seções seguintes, explicando melhor como acontece a conexão entre o framework e a ferramenta FREVO.

2.9.2.1 Arquitetura

A arquitetura da ferramenta FREVO é ilustrada pela Figura2.10.

Figura 2.10 – Diagrama de pacotes da ferramenta FREVO.

Fonte: FREVO - Um Framework e uma Ferramenta para Automação de Testes [4].

A ferramenta FREVO é agrupada em seis pacotes de classes, como descrito por [4]. • gui: Contém as classes responsáveis por compor a interface gráfica da ferramenta. • util: Contém um conjunto de classes utilitárias usadas pela ferramenta.

• service: Contém as classes responsáveis pela realização da comunicação com ferra- mentas externas de gerenciamento de testes.

• dao: Contém as classes responsáveis pela leitura dos bancos de dados provenientes do framework FREVO.

• model: Contém as classes das entidades fundamentais da ferramenta.

• execution: Contém as classes responsáveis pelo controle e gerenciamento da execução dos testes UI Automator.

As seções a seguir detalham as informações e características mais importantes para cada uma desses pacotes.

2.9.2.2 Pacote gui

A Figura 2.11 ilustra o diagrama das principais classes contidas no pacote gui.

Figura 2.11 – Diagrama de classes contendo as principais classes do pacote gui.

Fonte: FREVO - Um Framework e uma Ferramenta para Automação de Testes [4].

De acordo com Melo [4], o pacote gui contém a classe MainWindow. Essa classe representa a tela principal da ferramenta e funciona como um contêiner de componentes gráficos. As principais funcionalidades da ferramenta estão contidas no subpacote panels. O subpacote dialogs contém classes que não estão embutidas no contêiner principal da ferramenta. Os subpacotes controls, listeners e mediator contém classes utilitárias que usadas para diversos fins. Os subpacotes docs, images e strings referem-se a documentos, imagens e textos, respectivamente, e são usadas por todo o sistema.

2.9.2.3 Pacote util

A Figura 2.12 ilustra o diagrama das principais classes contidas no pacote util. Melo [4] define que o pacote util contém a classe TimeoutTestConfig. Essa classe é a fonte de entrada para a configuração do timeout dos testes que serão executados pela ferramenta. A classe Logger captura o log de prováveis erros na ferramenta.

2.9.2.4 Pacote dao

Figura 2.12 – Diagrama de classes contendo as principais classes do pacote util.

Fonte: FREVO - Um Framework e uma Ferramenta para Automação de Testes [4].

Figura 2.13 – Diagrama de classes contendo as principais classes do pacote dao.

Fonte: FREVO - Um Framework e uma Ferramenta para Automação de Testes [4].

De acordo com Melo [4], o pacote dao tem dois subpacotes, sqlite e xml. A classe

DriverScriptDAOFactory é responsável por converter o banco de dados proveniente da

execução de um teste doframework FREVO. As principais funções das classes do subpacote

sqlite são converter o banco de dados resultante de uma execução em objetos e disponibilizar

uma interface de acesso a esses objetos. A classe AutoTestCaseExecutionDAO agrupa os dados das tabelasSubTest, SubTestResult e TestCaseResult também definidas no framework. O subpacote xml é usado para criar, editar e salvar dados locais no formato eXtensible

Markup Language (XML). A classe LocaleDAO gerencia uma lista de idiomas suportadas pela ferramenta na execução de testes.

2.9.2.5 Pacote model

Figura 2.14 – Diagrama de classes contendo as principais classes do pacote model.

Fonte: FREVO - Um Framework e uma Ferramenta para Automação de Testes [4].

De acordo com Melo [4] o pacote model engloba todas as entidades básicas do sistema. Algumas classes desse pacote são utilizadas pelas classes do pacote dao para repre- sentar os objetos de cada tabela definida no framework FREVO. Por exemplo, as classes

Build, ExecInfo, ScriptType, Locale e AutoTestCase são utilizadas pelas classes BuildDAO, ExecInfoDAO, ScriptTypeDAO, LocaleDAO e AutoTestCaseDAO, respectivamente.

2.9.2.6 Pacote execution

A Figura2.15ilustra o diagrama das principais classes contidas no pacote execution.

Figura 2.15 – Diagrama de classes contendo as principais classes do pacote execution.

Fonte: FREVO - Um Framework e uma Ferramenta para Automação de Testes [4].

O pacoteexecution contém todas as classes utilitárias responsáveis pela execução de

scripts UI Automator do framework FREVO. Segundo Melo [4], umas das principais classes do sistema é a classe TestExecution, que é responsável pela orquestração da execução de uma suíte de testes criada usando a ferramenta. Além de definir a ordem de execução, ela também monitora a execução capturando o log de execução dos testes e, no final

da execução de uma suíte de testes, captura todas as informações da execução (banco de dados, screenshots, logs de execução, etc.). A classe DeviceManager é responsável pelo reconhecimento de dispositivos conectados na máquina, disponibilizando-os para a classe TestExecution iniciar a execução de uma suíte de testes. A classe ProcessWrapper é responsável por enviar comandosADBpara serem executados em um dispositivo conectado. 2.9.2.7 Integração Ferramenta-Framework

O projeto da ferramenta FREVO contempla a execução dos scripts desenvolvidos em UI Automator através do framework FREVO. Essa execução é concebida através da geração do arquivo JAR que contém os scripts UI Automator e do banco de dados gerado pelo framework FREVO contendo o mapeamento desses scripts no arquivo JAR.

A Figura 2.16 ilustra os artefatos mínimos para realizar a integração entre o

framework e a ferramenta.

Figura 2.16 – Artefatos necessários para realizar a integração entre o framework

e a ferramenta FREVO.

Fonte: FREVO - Um Framework e uma Ferramenta para Automação de Testes [4].

A integração entreframework e a ferramenta torna possível a execução de scripts UI Automator por meio de uma interface gráfica amigável e intuitiva, trazendo vários benefícios ao usuário. Dentre esses benefícios, destacam-se a possibilidade de execução de um conjunto de casos de testes e uma análise de resultados detalhada, contendo todas as informações sobre as validações realizadas.

2.10

Testes de Voz

Recursos de voz têm se tornado cada vez mais presentes nos dispositivos móveis. Essa característica permite que o usuário interaja com o dispositivo sem o uso das mãos, tornando possível a execução de diversos tipos de ações: desde as mais simples como uma consulta sobre a previsão do tempo, passando pela realização ou recebimento de chamadas enquanto se está dirigindo, até tarefas mais complexas como a adição de um lembrete no calendário contendo horário, lugar e convidados.

A simplicidade que esse tipo de interação proporciona ao usuário final não se reflete durante seu processo de desenvolvimento, uma vez que a realização de testes para recursos de voz muitas vezes é dispendiosa, sendo necessária uma intervenção manual massiva visando garantir que o comportamento esperado das funcionalidades.

Algumas das principais dificuldades enfrentadas durante a realização de testes de voz podem ser destacadas:

• Diferentes idiomas: Assim como os dispositivos são desenvolvidos de maneira locali- zada [43], ou seja, são projetados para suportar diversos idiomas, os recursos de voz também são. Dessa forma, é necessário que o testador conheça o idioma no qual irá executar o caso de teste de voz, uma vez que ele irá precisar falar para o dispositivo os comandos no idioma em que o telefone está configurado. Dessa maneira, caso o testador não seja fluente em determinado idioma, a execução de testes no idioma especificado fica inviabilizada.

• Readout ou saída de áudio: De maneira semelhante ao ponto destacado anteriormente, a saída de áudio emitida pelo dispositivo (readout) durante a execução de um comando de voz também precisa ser validada. Por exemplo, é necessário verificar que uma resposta emitida pelo dispositivo está correta (se está no idioma esperado ou coerente e contextualizada). Além disso, por se tratar de testes, o readout é considerado um artefato de saída da execução.

• Qualidade e variedade de ambiente: Por se tratar de tipo de interação por voz, espera-se que o ambiente onde o teste será executado tenha o mínimo possível de ruídos para que os comandos sejam reconhecidos. Por outro lado, faz-se necessário que exista uma variedade de ambientes para execução, visto que em ambientes reais dos usuários finais, essas interações irão acontecer em situações encontradas em diversos momentos do cotidiano, como em casa, num bar e no carro.

• Repetição dos testes: Como acontece com os demais tipos de teste, o teste de voz precisa ser executado diversas vezes, em diferentes momentos e com variados propósitos.

Diante desses fatores, a realização de testes de voz de maneira manual se torna complexa e exaustiva, podendo ser considerada como impraticável dependendo do nível de interações desejadas bem como da geração de todos os artefatos da execução. Uma vez que o testador precisa de inúmeras ferramentas de suporte à execução, como por exemplo, a utilização de tradutores e geradores de arquivos de áudio baseados em texto Text-to-Speech (TTS) [44] para então realizar a utilização de equipamentos de reprodução e gravação de

2.11

Considerações Finais

Neste capítulo, foram introduzidos os principais conceitos para o entendimento deste trabalho, que se encontra na sub-área de Engenharia de Software, Testes de Soft- ware. Apresentando algumas definições acerca de teste de software, desde conceitos sobre verificação e validação de software, passando pelas abordagens e fases de testes e, por fim, chegando no tema principal onde esse trabalho está desenvolvido, a automação de testes. Vimos que oframework e a ferramenta FREVO funcionam de maneira harmoniosa proporcionando inúmeras facilidades aos usuários. Esses benefícios podem ser analisados de duas perspectivas: desenvolvedores de scripts automáticos e testadores.

Os desenvolvedores de scripts automáticos que usam o framework no dia a dia tomam vantagem de possuírem um ambiente de desenvolvimento consolidado, que permite se ater apenas em desenvolver os scripts de maneira rápida e segura, sem precisar se preocupar com configurações manuais de ambiente e/ou complexa análise e manipulação de resultados. Por outro lado, os maiores beneficiados com o desenvolvimento da ferramenta FREVO são os usuários finais: neste caso, os testadores. Estes apenas se preocupam em conectar um dispositivo Android ao computador e selecionar quais testes desejam executar. Em seguida, terão a possibilidade de analisar com riqueza os detalhes da execução automática, onde podem-se observar evidências para cada validação, contendo resultados esperados e atuais bem como screenshots de cada uma dessas validações.

Apesar da significativa contribuição do framework FREVO ao framework UI Automator, ainda existem muitos tipos de interação que estesframeworks não dão suporte (gestos, orientação, voz, imagens, etc). Em particular, o tipo de interação humana que esses

frameworks não dão suporte e que iremos desenvolver neste trabalho é o de voz, tendo em

vista que a interação com dispositivos móveis através da utilização da voz humana é um recurso relativamente novo. Esse tipo de interação ainda é pouco explorado e encontrado na literatura de testes de software. Adicionalmente, ainda não se encontram frameworks ou ferramentas no mercado que possibilitem a plena automação desse tipo de interação humana, o que torna essa área um desafio para os desenvolvedores de scripts automáticos que precisam lidar com esse tipo de cenário.

Desse modo, a extensão doframework e ferramenta FREVO através desse trabalho, intitulado como FREVoz - Um Framework para Automação de Testes de Voz -, herda as características do FREVO bem como aquelas já herdadas dos frameworks de testes do Android, JUnit e UI Automator. O principal objetivo de FREVoz visa acrescentar uma característica extremamente inovadora e necessária no âmbito atual de automação de testes, que é a interação de voz.

Sendo assim, o framework FREVoz proporciona o desenvolvimento de teste de software do tipo caixa-preta, uma vez que o desenvolvedor dos scripts automáticos não

precisa ter acesso ao código fonte das aplicações que fazem interação de voz para poder elaborar os scripts automáticos. Esses testes por sua vez serão executados pela ferramenta FREVO na fase de teste de sistemas, onde o software que será testado já contem todos os módulos necessários integrados, proporcionando o completo funcionamento da aplicação que se deseja testar, de modo a permitir validar as características funcionais e de desempenho do mesma. A utilização da ferramenta FREVO para executar os testes de voz desenvolvidos no

framework FREVoz é fundamental, uma vez que a ferramenta irá proporcionar a realização

de testes de regressão durante o ciclo de desenvolvimento do software conforme novas funcionalidades ou modificações no software ocorrerem.

3 FREVoz

Frameworks de automação de teste para dispositivos móveis dão suporte à execução e desenvolvimento de scripts focados em interações com a interface gráfica. Isto é, os

frameworks disponibilizam classes utilitárias focadas na simulação de ações tradicionais de

um usuário, como toques, cliques e arrastes. Entretanto, como visto no Capítulo 2, pelos exemplos de UI Automator e JUnit, não existem mecanismos que promovam a interação com dispositivos móveis por meio de novas interações como a voz humana.

Neste capítulo, descreveremos como estendemos oframework e a ferramenta FREVO para suportar o conceito de automação de testes de voz. Decidimos estender o framework FREVO por ser totalmente baseado na arquitetura padrão definida pelo Android, que solucionou uma série das limitações existentes no framework UI Automator, e por possuir uma integração completa com uma ferramenta de execução de testes. Esta extensão é chamada de FREVoz.

3.1

Objetivos

Este trabalho tem por objetivo principal a extensão doframework e ferramenta FREVO com a adição de recursos que permitem a utilização de arquivos de áudio na automação de testes caixa-preta. Uma vez que o FREVO é uma extensão do framework UI Automator e este não possui suporte nativo para esse tipo de interação, tão necessária nos dias atuais, FREVoz estende o FREVO da seguinte maneira:

• Desenvolvimento de umframework para a criação de scripts automáticos com suporte à utilização de áudios;

• Desenvolvimento de um novo módulo na ferramenta FREVO que permite o gerencia- mento e execução dos testes automáticos com áudios sem a necessidade de interação humana.

Esses dois itens são essenciais para a elaboração deste trabalho, uma vez que o primeiro está diretamente associado com o desenvolvimento dos scripts automáticos e o segundo com a execução dos mesmos. Dessa forma, FREVoz também adiciona:

• Biblioteca de áudios que possibilita a composição e execução de uma sequência de áudios pré-definidos;

• Análise de resultados de execuções de testes com áudio que permite, além da visualização das validações de UI através de screenshots (nativo do FREVO), a re-execução dos áudios que vieram a ser utilizados e gravados durante a execução do

script; isto permite o testador ter total entendimento do resultado de um teste de

voz.

Essas adições permitem a inserção de recursos de áudio durante o desenvolvimento dos scripts automáticos, além de tornar simples a sua execução e posterior análise dos resultados, tanto de forma visual pela visualização dos screenshots, como também de forma auditiva, através da reprodução dos áudios provenientes durante a execução, ou seja, os áudios falados pelo celular em resposta a um comando de voz.