3.2 Descrição do Framework FREVoz
3.2.2 Classe VoiceTestCase
A principal classe doframework FREVoz é a VoiceTestCase, que estende a classe
BaseTestCase do framework FREVO. Esta extensão acontece para acrescentar novas
características que possibilitam o desenvolvimento e, principalmente, a execução automática dos testes de voz. As principais características adicionadas pela classe VoiceTestCase à
BaseTestCase são:
• Instanciação de bibliotecas utilitárias e de suporte à execução dosscripts de voz; • Ativação e desativação da gravação dos áudios gerados durante uma execução;
Figura 3.1 – Pacote Definitions com a nova classe inserida pelo framework
FREVoz.
Fonte: Adaptado de FREVO - Um Framework e uma Ferramenta para Automação de Testes [4].
• Disponibilização de métodos básicos para a comunicação entre os scripts e o fra-
mework FREVoz;
• Habilitação e desabilitação dewatchers que possibilitam o script automaticamente identificar e ignorar situações inusitadas durante uma execução. Por exemplo, muitas vezes ao lançar uma aplicação pela primeira vez é necessário pular as telas inicias. Desse modo, caso isso aconteça e o script não esteja esperando por isso, muito prova- velmente ele irá acusar algum erro ou no pior caso ficar aguardando indefinidamente até o atingir o timeout da execução. Mas se um watcher tenha sido registrado com alguns dos possíveis botões (ex: skip/ok/after/next), ele tenta sair dessa situação e continua normalmente com a execução.
A Figura 3.2 exibe em detalhes os principais atributos e métodos da classe Voi-
ceTestCase, bem como suas ligações com as demais entidades do framework FREVO,
como as classes BaseTestCase, TimeCounter e FrevoTestCase. Mais detalhes acerca do comportamento e necessidade de cada uma dessas classes são encontradas na dissertação de Melo [4].
Figura 3.2 – Diagrama de classes com os principais atributos e métodos da
classe VoiceTestCase do framework FREVoz.
Fonte: Adaptado de FREVO - Um Framework e uma Ferramenta para Automação de Testes [4].
Ao observar o diagrama de classes destacado na Figura 3.2, referente à classe
VoiceTestCase, nota-se a apresentação das características principais e necessárias para o
desenvolvimento dosscripts de voz. Na Tabela7descrevemos apenas os principais métodos disponíveis para o usuário no momento da criação descripts de voz, tais métodos permitem manipulação de arquivos de áudios bem como auxiliam no controle de ações do framework FREVoz.
Tabela 7 – Métodos dos providos pela classe VoiceTestCase.
Metódo Ações
trigger() Executa o trigger, o comando de áudio padrão para ativação do reconhecimento de voz.
send() Solicita que um determinado comando seja executado, ou seja um arquivo de áudio seja reproduzido.
startRecord() Inicia a gravação do readout, ou seja os áudios pro- venientes da execução (áudios falados pelo celular como resposta a um comando de voz).
finishRecord() Termina a gravação do readout, ou seja os áudios provenientes da execução (áudios falados pelo celular como resposta a um comando de voz).
waitTimeToReply() Aguarda o momento exato para responder com um novo comando de voz.
enableLogCatWatcher() Monitora o Android Logcat buscando a ocorrência
de uma dada tag e/ou texto com significância na interação por voz.
waitLogCatItem() Aguarda pela ocorrência de um determinado item no Android LogCat.
enableWatchers() Habilita a verificação da ocorrência de um determi- nado item inesperado na interface gráfica durante a execução de um script.
disableWatchers() Desabilita a verificação da ocorrência de um deter- minado item inesperado na interface gráfica durante a execução de um script.
Fonte: Elaborado pelo autor.
A seguir serão apresentados alguns dos principais métodos utilizados no desenvolvi- mento de scripts de voz, em seguida um script completo utilizando esses métodos será apresentado. O trecho de Código 3.1ilustra a implementação do método enableWatchers() onde é realizada a definição de alguns botões que deseja-se ignorar caso sejam encontrados durante o fluxo de execução dos casos de teste de voz.
Código 3.1 – Implementação do método enableWatchers.
public void enableWatchers(){
UiWatcher UnexpectedButtonsWatcher = new UiWatcher() {
BySelector unexpectedSelector =
By.res(Pattern.compile(".*next.*|.*skip.*|.*ok.*|.*after.*"));
@Override
public boolean checkForCondition() {
if (mDevice.hasObject(unexpectedSelector)) {
execution."); // Clica no objeto
mDevice.findObject(unexpectedSelector).click();
// Retorna true quando o objeto desaparece da tela
return mDevice.findObject(unexpectedSelector).wait( Until.gone(unexpectedSelector), 10000); } return false; } }; // Registra o watcher UiDevice.getInstance().registerWatcher(UNEXPECTEDWATCHER, UnexpectedButtonsWatcher); // Executa o watcher UiDevice.getInstance().runWatchers(); }
O trecho de Código 3.2 ilustra a implementação do método disableWatchers() onde o watcher registrado anteriormente com o nome de UNEXPECTEDWATCHER é desativado, e consequentemente a verificação dos botões indesejados não é mais verificada durante o fluxo de execução dos casos de teste de voz.
Código 3.2 – Implementação do método disableWatchers.
public void disableWatchers(){
// Desabilita o watcher
UiDevice.getInstance().removeWatcher(UNEXPECTEDWATCHER); }
O trecho de Código 3.3 ilustra a implementação do método waitTimeToReply() onde são definidos os parâmetros com significância para a interação por voz através das variáveistag e text. Essas variáveis são passadas para o método enableLogCatWatcher() que irá iniciar a busca por a ocorrência desses parâmetros no Android Logcat.
Código 3.3 – Implementação do método waitTimeToReply.
public void waitTimeToReply(VoiceCommandEnum... commandArgs) throws
Exception {
long waitTime = 300;
String text = "#startListening"; enableLogCatWatcher(tag, text); if (waitLogCatItem(waitTime)) { this.send(commandArgs); } }
Por sua vez, o Código3.4 apresenta a implementação do método enableLogCatWat-
cher() . Esse método inicia uma thread que irá monitorar a ocorrência do texto "#star- tListening" na tag "GoogleRecognitionService", determinando assim o momento em que o
sistema está pronto para escutar a execução de um novo comando.
Código 3.4 – Implementação do método enableLogCatWatcher.
private void enableLogCatWatcher(final String tag, final String text) {
logCatThread = new Thread(new Runnable() {
@Override
public void run() {
String FILTERED_LOGCAT_COMMAND = String.format("logcat %s:V
*:S", tag);
String CLEAR_LOGCAT_COMMAND = "logcat -c";
String line;
Scanner scanner = null;
try {
runCommand(CLEAR_LOGCAT_COMMAND); ParcelFileDescriptor descriptor =
runCommand(FILTERED_LOGCAT_COMMAND);
scanner = new Scanner(new
FileInputStream(descriptor.getFileDescriptor()));
while (scanner.hasNextLine()) {
line = scanner.nextLine();
if (line.contains(text)) {
Logger.logInfo("The Text was found on LogCat !!!");
isTextFound = true;
break;
} }
} catch (Exception e) { Logger.logInfo(e.getMessage()); } } }); logCatThread.start(); }
Por fim, o Código 3.5 apresenta a implementação um teste de voz usando o fra-
mework FREVoz. Note que a classe de teste ExemploVoiceTestCase estende VoiceTestCase,
que por sua vez estende BaseTestCase do framework FREVO.
Código 3.5 – Exemplo de implementação de um script de voz.
public class ExemploVoiceTestCase extends VoiceTestCase {
private final String DIALER_APP_PKG = "com.android.dialer";
private static final String CONTACT_NAME = "Alex";
private static final long WAIT_TIME_FIVE_SECONDS = 5000;
@Override
public void init() throws Exception {
// Define a descricao do caso de teste
mTestCase.setDescription("Ligar para Alex usando o comando de voz do
Google Now");
// Define o tipo de script a ser desenvolvido
mTestCase.setScriptTypeId(ScriptTypeEnum.VOICE.getId());
// Define a versao do sistema operacional no qual o script desenvolvido mTestCase.setBuildId(BuildEnum.LOLLIPOP.getId());
}
@Override
public void setUpTestCase() throws Exception {
// Ativando watcher para ignorar elementos indesejaveis durante a execucao
this.enableWatchers();
@Override
public void tearDownTestCase() throws Exception {
// Desativando watcher
this.disableWatchers();
}
@Override
public void main() throws Exception {
// Executa o trigger padrao: "Ok Google!" this.trigger(true);
// Aguarda pelo momento correto para dizer o proximo comando
this.waitTimeToReplay();
// Solicita a execucao de um novo comando: "Ligar Alex"
this.send(VoiceCommandEnum.CALL_ALEX);
// Define o seletor que indica o sucesso ou nao da acao anterior BySelector callScreen = By.pkg(DIALER_APP_PKG);
// A 1a condicao de sucesso foi satisfeita com a existencia um objeto // na tela dentro do intervalo de 5 segundos
// com o pacote esperado da aplicacao de DIALER
if (mDevice.wait(Until.hasObject(callScreen), WAIT_TIME_FIVE_SECONDS))
{
// 1a validacao (automatica): Tela de ligacao eh exibida
mSubTestDescription = "1. Observe que a tela de ligacao foi
invocada atraves do comando de voz.";
mActualResult = mDevice.getCurrentPackageName(); mExpectedResult = DIALER_APP_PKG;
this.assertValidateEquals(mSubTestDescription, mExpectedResult,
mActualResult);
// 2a validacao (automatica): Nome do contato eh exibido
mSubTestDescription = "2. Observe que a ligacao foi feita para o
contato esperado";
mActualResult = mDevice.findObject(By.text(CONTACT_NAME)).getText(); mExpectedResult = CONTACT_NAME;
mActualResult);
// 3a validacao (manual): O audio falado pelo celular como // resposta ao comando de voz (readout) da execucao estah de // acordo com o esperado para a acao solicitada. Esta validacao // manual eh opcional e eh feita apos o termino de todas as // execucoes, na fase de analise dos resultados. Serve para o // testador ter maior confianca que o celular respondeu
// aos comandos com um audio correto.
mSubTestDescription = "3. Verifique que o audio readout ou que
mensagem de audio esperada foi tocada corretamente.";
this.setIndeterminate(mSubTestDescription); BySelector endCallButton = By.res(Pattern.compile(".*floating_end_call_action_button")); if (mDevice.hasObject(endCallButton)) { mDevice.findObject(endCallButton).click(); } } else {
// O teste nao eh executado caso a 1a condicao de sucesso nao for satisfeita
this.forceFailResult("O Comando de ligacao nao foi reconhecido e a
ligacao nao aconteceu."); }
} }
A classe de teste necessita implementar os mesmos métodos obrigatórios oriundos da classe base (init(), setUpTestCase(), tearDownTestCase() e main()). E então, durante o desenvolvimento do caso de teste de voz, a classe de teste incorpora em sua lógica os métodos necessários ao desenvolvimento dos scripts de voz fornecidos pela classe
VoiceTestCase.
O caso de teste exibido acima tem por objetivo principal realizar uma ligação para um determinado contato (Alex) que possui seu nome gravado em um arquivo de áudio (previamente criado) com um áudio semelhante ao de uma pessoa interagindo com os recursos de voz presentes nos smartphones atuais. Se fôssemos descrever de maneira textual, esse script seria composto pelo seguinte conjunto de passos:
1. Invocar o comando de voz do telefone através de um trigger ou comando pré-definido, por exemplo: "Ok Google Now!";
2. Aguardar o momento correto de falar o próximo comando; 3. Falar o próximo comando, por exemplo: "Ligar para Alex";
4. Observar se o comando foi reconhecido e então continuar com a ligação; 5. Encerrar a ligação.
Observe que cada um desses passos é representado por um verbo (invocar, aguardar,
falar, observar, encerrar). Tais ações são implementadas pelos métodos existentes nos
dois frameworks. O framework FREVO continua responsável por realizar algumas dessas ações, principalmente às visuais (observar) e gestuais (encerrar), enquanto a FREVoz fica responsável pelas ações que se relacionam com interações de voz como (invocar, aguardar,
falar).
Uma limitação existente noframework FREVoz não é falta de capacidade de validar se o readout está corretamente localizado (traduzido para o idioma da execução) ou mesmo se a frase de resposta faz sentido no contexto do teste. Através de outros tipos de inferência é possível realizar boa parte da validação se um caso de teste passou ou falhou (ou seja, se o dispositivo reconheceu corretamente os comandos) como, por exemplo, se uma determinada tela ou identificador foi alcançado, ou se um artefato como uma foto foi gerada ao término da execução de um caso de teste de voz, uma vez que esses são artefatos esperados de serem gerados durante essa execução (isto é feito de forma totalmente automática pela segunda validação no Código 3.5). O testador poderá validar o áudio gerado durante a execução após a conclusão da execução da suíte de teste na tela de análise de resultados de forma manual (terceira validação). Esta análise é opcional e tem como objetivo escutar o áudio falado pelo celular durante o teste para ver se ele foi falado na língua certa ou se a frase dita foi correta. Vale destacar que nem todos os scripts automáticos precisam ser validados manualmente após a sua execução, tendo em vista que muitos deles não possuem um readout, sendo assim o framework é capaz de definir seu resultado sem a necessidade de intervenção humana. O tempo gasto nessa etapa irá depender da quantidade de testes executados que precisam de intervenção e quando necessária acontece de maneira bastante veloz, pois o papel do usuário se restringe apenas a escutar um pequeno readout que em sua grande maioria tal áudio tem duração de segundos, acrescentando assim pouco tempo a etapa de análise de resultados de uma execução.
Apesar da adição dessas novas características, o fluxo de um caso de teste executado sob a classe VoiceTestCase no framework FREVoz (Figura 3.3), continua tendo o mesmo fluxo original do framework FREVO (Figura 2.8).
Figura 3.3 – Diagrama de estados da execução de um teste de voz no framework
FREVoz continua semelhante ao do framework FREVO.
Fonte: Adaptado de FREVO - Um Framework e uma Ferramenta para Automação de Testes [4].
3.3
Descrição da Ferramenta FREVO com a extensão FREVoz
Nas seções seguintes serão apresentadas as modificações introduzidas na arquitetura de software da ferramenta FREVO a partir da integração proposta pelo framework FREVoz. Além disso, algumas telas contendo as novas funcionalidades serão exibidas para proporcionar um melhor entendimento das extensões feitas.
3.3.1
Arquitetura
A Figura 3.4 ilustra o agrupamento dos pacotes de classes (gui, util, dao, model e
execution) que compõem a estrutura original do FREVO com o destaque para a adição do
novo pacote voice que representa implementações significativas referentes ao framework FREVoz.
Figura 3.4 – Diagrama de pacotes da ferramenta FREVO com a introdução
das funcionalidades do FREVoz.
Fonte: Adaptado de FREVO - Um Framework e uma Ferramenta para Automação de Testes [4].
A introdução de FREVoz também acaba ocasionando algumas pequenas modifica- ções nos demais pacotes e classes da ferramenta FREVO. As modificações mais relevantes
serão destacadas nas subseções que seguem abaixo.
3.3.2
Pacote gui
Na Seção 2.9.2.1, vimos que o pacotegui contém todas as classes que compõem a interface gráfica da ferramenta. Vimos também na Seção 2.10 que o framework FREVoz fornece um novo artefato de saída (readout), referente aos áudios provenientes da execução de um teste de voz. Assim sendo, fez-se necessário editar algumas classes do subpacote
dialogs, de modo a suportar a visualização e reprodução deste novo tipo de teste automático.
Vale ressaltar que não foi necessário adicionar novos componentes relacionadas à interface gráfica do usuário. Ou seja, o usuário da ferramenta FREVO consegue usar FREVoz sem perceber grandes impactos na sua utilização.
3.3.3
Pacote voice
A Figura 3.5 apresenta um diagrama resumido das classes do pacote voice.
Figura 3.5 – Diagrama de classes resumido do pacote voice.
Fonte: Elaborado pelo autor.
O pacote voice tem cinco subpacotes: media, model, protocol, socket e service. O pacote media contém todas as classes relacionadas ao gerenciamento de áudio (gravação e reprodução). O pacote model engloba as entidades que definem a representação de um comando de voz. Por exemplo, a classe VoiceCommand modela aqueles comandos de voz que são disparados em um script (veja ExemploVoiceTestCase na Seção 3.2.2). As classes dos subpacotes protocol e socket são responsáveis pela definição de um protocolo de comunicação entre o dispositivo e a máquina em que a ferramenta FREVO está sendo executada. Por fim, temos o subpacote service, que utiliza todas as classes dos subpacotes
mencionados anteriormente a fim de estabelecer uma estrutura de aplicação distribuída sob o modelo cliente-servidor. Essa arquitetura cliente-servidor foi concebida através da classe VoiceService, que veremos a seguir.
3.3.3.1 Classe VoiceService
A Figura3.6ilustra o funcionamento da arquitetura cliente-servidor implementada na classe VoiceService.
Figura 3.6 – Arquitetura cliente-servidor na classe VoiceService .
Fonte: Elaborado pelo autor.
Assim como a classe VoiceTestCase habilita os desenvolvedores criarem scripts de testes de voz, a classe VoiceService habilita a execução de scripts destes testes de voz na ferramenta FREVO.
As principais atribuições da classeVoiceService são:
1. Estabelecer e orquestrar a comunicação entre o dispositivo e a máquina através do protocolo de rede Transmission Protocol Information (TCP) sem que oscript seja encerrado;
2. Interpretar as mensagens recebidas;
3. Executar ações específicas de acordo com as mensagens recebidas.
Dentre as ações específicas mencionadas no item 3, podemos destacar a reprodução de arquivos de áudio, bem como a gravação do readout ou áudio de saída.
A Figura 3.7 exibe os principais atributos e métodos da classe VoiceService. Ao observar o diagrama referente à classe VoiceService, nota-se a presença de características essenciais para a execução dos scripts de voz. Descrevemos os principais métodos na Tabela 8.
Figura 3.7 – Diagrama de classe resumido da classe VoiceService.
Fonte: Elaborado pelo autor.
Tabela 8 – Principais métodos providos pela classe VoiceService.
Metódo Ações
generateTCPCommand() Gera um comando ADB utilizado para configurar o protoco TCP de cada dispositivo conectado.
setupAllDevices() Configura as portasTCP dos dispositivos conectados na máquina que executa a ferramentaFREVO, uma vez que mais de um dispositivo pode estar conectado ao computador no momento de iniciar a execução, sendo assim as portas precisam estar configuradas para que o usuário escolha em qual dispositivo pre- tende realizar a execução.
run() Inicia a execução do serviço, isto é, iniciam-se as principais atribuições (orquestração, interpretação e execução de ações).
actionPlayAudioCommand() Inicia a reprodução de um arquivo de áudio.
stopService() Encerra o funcionamento do serviço, paralisando to- das as operações existentes.
Fonte: Elaborado pelo autor.
3.3.4
Pacote execution
Na Seção2.9.2.6, vimos que o pacoteexecution contempla todas as classes responsá- veis pela execução descripts. Mais especificamente, o pacote contém a classe TestExecution,
responsável pelo gerenciamento (orquestração, execução e monitoramento) dos scripts FREVO. Consequentemente, para habilitar a execução de scripts de teste de voz, fez-se necessária a adição de um módulo na classeTestExecution. O módulo incorpora as seguintes atribuições:
1. Verificar a existência de recursos de áudio antes de iniciar a execução de testes de voz (caso contrário, a execução não poderá ser iniciada);
2. Iniciar o serviço local responsável por estabelecer a comunicação cliente-servidor e executar as requisições recebidas (ativar o funcionamento da classe VoiceService); 3. Recuperar os artefatos de saída das execução de testes de voz;
4. Encerrar o serviço responsável pela comunicação cliente-servidor (encerrar o funcio- namento da classe VoiceService).
Adicionalmente, não foi necessário introduzir novos componentes e/ou classes relacionadas ao controle da execução de scripts.
3.3.5
Integração FREVO-FREVoz
No que diz respeito a integração da ferramenta FREVO com oframework FREVoz, como sabemos que FREVoz é uma extensão do framework FREVO, podemos afirmar que os artefatos necessários para execução dos scripts desenvolvidos (arquivo JAR e banco de dados - vide Figura 2.16) permanecem inalterados. A única ressalva está exposta no item 1, onde a ferramenta precisa conter o mapeamento dos recursos de áudios utilizados nos scripts.
Portanto, os usuários poderão continuar se beneficiando de todas as características providas pela ferramenta. Logicamente, dentre as novidades, destaca-se a possibilidade de análise de resultados detalhada, contendo todas as informações sobre as validações realizadas, inclusive dos recursos de áudio.
3.4
Considerações finais
Diante desse ambiente coeso, as modificações introduzidas por FREVoz são bastante sutis de maneira a impactar o mínimo possível a experiência dos usuários dessas duas perspectivas. Tanto os desenvolvedores descripts como os testadores irão continuar usando o ambiente FREVO da mesma maneira que antes, apenas com novas funcionalidades que irão permitir o desenvolvimento e a execução de testes de voz.
Ao combinar as novas características providas por FREVoz com as funcionalidades já existentes no ambiente FREVO, é notória a ampliação do escopo de automação de
testes através da cobertura de testes de voz, viabilizando, consequentemente, um nível de automação de teste ainda pouco explorado por frameworks de automação existentes.
4 ESTUDO DE CASO
Este capítulo está divido em duas seções. Na seção4.1é apresentada a configuração de ambiente necessária bem como o funcionamento da ferramenta FREVoz durante a execução de testes de voz, mostrando como se dá a experiência do testador desde a preparação do ambiente, o passo-a-passo da execução e por fim a análise dos resultados. Na Seção 4.4é apresentado uma comparação entre a execução manual (sem FREVoz) e automática (com FREVoz) de uma suíte de testes de voz, mostrando o esforço gasto para realizar a atividade.
4.1
Configuração do ambiente
Os testes de voz são classificados aqui como testes do tipo caixa-preta, onde iremos exercitar características do software no que diz respeito à detecção de comandos de voz sem a necessidade de conhecer a estrutura interna da aplicação. A maioria dos testes de interface gráfica são projetados e executados através da simulação de toques na tela do dispositivo sob teste, de modo que esse contexto de execução funciona isolado de interferências externas. Diferentemente, um projeto de testes voltado para a realização de testes de voz em um dispositivo móvel é extremamente sensível ao contexto externo, uma vez uma vez que o barulhos e ruídos do ambiente exercem influência direta na execução correta dos testes.
Desse modo, faz-se necessária a adoção de algumas ações no que diz respeito à configuração do ambiente, para que se tenha uma execução satisfatória, ou seja com o mínimo possível de problemas causados pelo ambiente onde o teste é executado. Sendo assim, as características listadas a seguir são necessárias:
• Quiet-room: Possuir uma quiet-room, ou seja, uma sala silenciosa que forneça uma boa qualidade acústica é fundamental ao executar testes de voz, dada a sensibilidade dos microfones presentes nos dispositivos móveis, a ocorrência do menor ruído durante a execução de um teste pode ocasionar em problemas na detecção dos comandos de