Automação de testes para aplicações móveis em Android – Parte 1

Artigo no estilo: Curso

A computação móvel é constituída por um modelo computacional no qual os usuários fazem uso de dispositivos portáteis que acessam, na grande maioria do tempo, serviços de informação por meio de uma infraestrutura descentralizada e que deve estar disponível independentemente da localização física do usuário e a qualquer momento. A introdução de novas funcionalidades e a melhoria dos recursos providos pela computação móvel, tais como texto, voz, navegação Web, câmera, música e áudio e sensores tem criado novas demandas por aplicações móveis e contribuído para seu uso em diversas áreas. Assim sendo, é preciso que as soluções desenvolvidas passem por testes de software para reduzir a quantidade de defeitos presentes na aplicação e aumentar, consequentemente, a qualidade do software.

O teste de software, cada vez mais presente em ambientes industriais, é uma técnica dinâmica que objetiva executar a aplicação a partir de um conjunto de entrada de dados e, com base nas saídas obtidas, a conformidade é verificada em relação ao que é considerado como correto. Portanto, a atividade de teste deve ser conduzida durante todo um processo de desenvolvimento de software, incluindo-se as fases inicias de concepção. Dessa forma, evidências devem ser identificadas para demonstrar a confiabilidade entre os requisitos e funcionalidades desenvolvidas na aplicação.

Entretanto, testar é uma atividade custosa e maçante que demanda um grande esforço de tempo e, em alguns casos mais específicos e mais complexos, também de pessoas. Uma alternativa que tem sido a principal escolha por empresas é a automação de teste. A automação de teste de software traz algumas vantagens, entre elas (i) a definição de um conjunto extenso de casos de teste que podem ser rapidamente executados por inúmeras vezes, como no tipo de teste de regressão, (ii) a diminuição da chance de erro humano e (iii) a redução do esforço de testadores com tarefas repetitivas.

O foco desta primeira parte, de outras duas desta série de artigos, é apresentar os fundamentos do teste de software na Engenharia de Software, com o objetivo de introduzir o leitor em uma das mais importantes fases de um projeto de software. Apesar de serem expostos de maneira ampla, tais conceitos permitirão compreender a necessidade de testar as funcionalidades das aplicações desenvolvidas. Após essa introdução, o teste de software no contexto de mobilidade será discutido, destacando as principais características e dificuldades existentes para garantir a qualidade de uma aplicação móvel. Na etapa prática deste artigo, as ferramentas de automação de teste Monkey e MonkeyRunner serão empregadas para executar simulações de interações reais em aplicações móveis desenvolvidas, especificamente, para a plataforma Google Android. Para isso, uma aplicação de agenda de contatos, chamada AddressBook, será utilizada no processo de automação de testes.

Teste de Software

O processo de desenvolvimento de software é composto por atividades que, independentemente de quais técnicas, métodos ou ferramentas são empregadas durante um projeto, não garantem que o produto final esteja totalmente protegido de defeitos. Ao longo dos anos, a Engenharia de Software tem buscado introduzir atividades caracterizadas como Qualidade de Software e, entre elas, comumente se ouve sobre Verificação, Validação e Teste (VV&T). As atividades definidas por VV&T objetivam minimizar a existência de defeitos, permitindo que equipes de desenvolvimento sejam capazes de identificar se a evolução e implementação de funcionalidades no software estão corretas (conceitos de verificação) e, não menos importante, se a solução desenvolvida está adequada em relação às necessidades do cliente (conceitos de validação).

Neste contexto, o “T” de Teste é apresentado como um dos elementos mais utilizados para fornecer evidências da confiabilidade de requisitos e funcionalidades em um software. Além disso, têm sido constantemente aplicados junto a outras atividades como revisões de documentos de levantamento de requisitos, aplicação de técnicas formais para a criação de documentos de especificação (funcional e técnica) e, inclusive, na prototipação inicial com a participação dos envolvidos na análise da usabilidade provida pela interface proposta.

Com a finalidade de padronizar a terminologia adotada nas técnicas de teste de software, esforços por parte da IEEE visam diferenciar termos como (i) defeitos, (ii) erros e (iii) falhas. O padrão IEEE 610.12, de 1990, apresenta as seguintes definições:

• Defeito: passo, processo ou definição de dados incorreta como, por exemplo, uma instrução ou fragmento de código fonte incorreto;
• Erro: diferença entre os resultados obtidos quando comparado às saídas desejadas, ou seja, qualquer valor diferente ou inesperado na execução da funcionalidade;
• Falha: produção de uma saída incorreta em relação aos requisitos definidas no documento de especificação.

Para complementar, é comum que os termos “engano”, “defeito” e “erro” estejam sendo referenciados como “erros” (causa), enquanto que o termo “falha” a um comportamento incorreto do software (consequência).

Na Figura 1 é ilustrada a terminologia padronizada pela IEEE 610.12 com a separação dos termos em “universos”. O Universo Físico é representado pelo próprio escopo da aplicação e sofre influência ou alterações causadas por pessoas como, por exemplo, o mau uso da tecnologia utilizada como linguagem de programação ou plataforma de desenvolvimento. A existência de defeitos na aplicação pode resultar na manifestação de erros no software, contribuindo para o que o software desenvolvido esteja não conforme segundo o que foi especificado. Dá-se o nome, deste domínio, de Universo da Informação. Por fim, afirma-se que os erros presentes no software irão gerar falhas, ou seja, comportamentos inesperados que afetarão o usuário final, podendo, até mesmo, inviabilizar o uso do software. Neste último, como há a consequência direta ao usuário final, o universo é definido como Universo do Usuário.

Para simplificar sua adoção, o teste de software é dividido em quatro etapas que devem ser executadas ao longo do processo de software. Na primeira etapa, descrita como Planejamento de Teste, um planejamento deve dispor os objetivos, critérios que definem que uma fase do teste foi completada, cronogramas, responsabilidades, padrões para casos de teste, relação de ferramentas, configurações de hardware, rastreabilidade, procedimentos para depuração e teste de regressão. Na segunda etapa, descrita como Projeto de Casos de Teste, técnicas são utilizadas para ajudar a garantir a integridade dos testes e proporcionar uma maior chance na detecção de defeitos de software. Na terceira etapa, descrita como Execução de Teste, os casos de testes construídos são executados conforme o plano de teste especificado na primeira etapa. Por fim, a quarta e última etapa, descrita como Coleta e Avaliação dos Resultados de Teste, objetiva registrar, organizar e apresentar os artefatos resultantes a partir dos testes executados.

O estudo de abordagens e técnicas de teste, assim como outros tópicos relacionados à Engenharia de Software, envolve conteúdos extensos e bem detalhados. Portanto, é natural que, num só artigo, uma conceituação mais abrangente seja apresentada, fornecendo uma base limitada, porém essencial para qualquer pesquisa na área de qualidade de software.

Teste de Aplicações Móveis

Diferentemente de anos atrás, os dispositivos móveis deixaram de ser utilizados apenas para entretenimento, como jogos, filmes e aplicações gráficas, e passaram a ocupar um importante espaço no cenário corporativo e empresarial.

Nota-se que as aplicações móveis têm sido desenvolvidas para diversos domínios, tais como jogos, livros, comunicação, finanças, música e áudio, notícias, transportes e outros contextos. É importante destacar que, mesmo em domínios críticos como saúde, financeiro e industrial, muitas aplicações móveis têm sido desenvolvidas, reforçando a necessidade de ferramentas de teste, principalmente as que possibilitam um processo automatizado.

Alguns trabalhos mencionam que abordagens especializadas para testes de aplicações móveis devem ser propostas e pesquisas realizadas para identificar características de podem influenciar a atividade de teste no contexto de mobilidade. Inicialmente, algumas dessas particularidades são conhecidas, destacando-se conectividade, recursos limitados, autonomia, interface com o usuário, sensibilidade ao contexto, adaptação, novas linguagens de programação e sistemas operacionais, diversidade de configurações e telas de toque. A construção de aplicações móveis tem sido simplificada, pois ambientes de desenvolvimento, ferramentas de apoio e plataformas de computação móvel estão cada vez mais robustas. Entretanto, existem alguns fatores que tornam a engenharia de software para aplicações móveis diferente em relação à tradicional:

• Integração com outras aplicações móveis: é comum que aplicações móveis troquem dados com aplicações Web e Mobile por meio da Internet e, na atualidade, pela invocação de serviços na nuvem;
• Uso de sensores e componentes de hardware: os dispositivos móveis mais atuais dispõem de um conjunto de sensores, tais como acelerômetro, GPS, sensores de luz e outros;
• Aplicações nativas e híbridas: algumas aplicações móveis descentralizam seus processamentos e grande parte delas consome serviços de rede de telefonia. Além disso, atualmente há meios de desenvolver uma aplicação Web que se adapta a um dispositivo móvel;
• Segurança: graças à portabilidade e conectividade, as aplicações móveis podem ou devem acessar redes de dados externas e públicas que não são confiáveis. A segurança também deve ser considerada em mobilidade, pois o número de aplicações móveis instaladas é alto;
• Interação com usuário: com diversas plataformas e versões de um sistema operacional móvel, a interface de interação com o usuário final pode possuir inúmeras configurações. Ademais, limitações como tamanho e resolução do dispositivo móvel criam novos meios de interagir com a aplicação móvel.

O foco desta série de artigos é explorar e aplicar ferramentas de teste em aplicações móveis, especificamente as desenvolvidas na plataforma Google Android. Uma pesquisa recente, divulgada pela Gartner (2014), revela que a venda de dispositivos móveis baseados na plataforma Android tivera um aumento de 127% quando comparado os anos de 2013 e 2012. A quantidade de dispositivos móveis vendida foi de aproximadamente 121 milhões de unidades, fazendo com que a plataforma Google Android assumisse a liderança na lista de sistemas operacionais móveis e ambientes de desenvolvimento com 62%, bem à frente do iOS da Apple e do Windows Phone da Microsoft.

Ferramentas para automação de testes em Google Android

Mesmo com técnicas que diminuem o esforço de teste, sua execução manual pode ser um “gargalo” no cronograma de um projeto de software. Por esse e outros motivos, busca-se ferramentas para automatizar os testes com o intuito de diminuir seus tempos de criação e execução. Algumas dessas ferramentas se baseiam na capacidade de identificar quais eventos estão sendo lançados ou invocados durante o uso real de uma aplicação que se deseja testar e, dessa forma, pode-se criar dinamicamente um script de teste que repita o que manualmente foi executado. Essa modalidade de teste automatizado é definida como “capture-and-replay” e requer pouco ou nenhum desenvolvimento, além do necessário para capturar os eventos dentro do contexto daquela aplicação.

Outra forma de alcançar a automação do teste em aplicações móveis é por meio da escrita manual ou da geração de scripts de teste sem que seja necessário executar, previamente, a aplicação. Assim, podem-se elaborar diversos casos de teste para validar as situações válidas e inválidas para uma determinada aplicação móvel Android.

Nativamente, a plataforma Google Android provê recursos para o teste de aplicações móveis, destacando-se Instrumentation, UIAutomator, Monkey e MonkeyRunner. Há também ferramentas que podem ser integradas ao ambiente de desenvolvimento Android ou diretamente a uma solução móvel, tais como Espresso, Robolectric, Robotium, Selendroid, Calabash e Appium.

Estudo de caso: uma nova abordagem para AddressBook

Com o objetivo de contribuir com a parte prática deste artigo, tornou-se necessário implementar uma aplicação móvel na plataforma Google Android a ser utilizada nas fases de projeto, criação e execução dos testes automatizados. Para isso, a aplicação AddressBook é uma agenda de contatos simples que faz uso do banco de dados SQLite para armazenar informações como nome, telefone, e-mail e endereço, enquanto que sua interface gráfica é composta pelos seguintes componentes utilizados em aplicações Android: TextView, EditText, Button, Menu, ListView e AlertDialog.

Além desses componentes, foram acrescentados novos atributos ao contato como (i) um CheckBox para saber se o contato está ativo ou inativo, (ii) um RadioGroup para identificar o sexo do contato, (iii) um campo de EditText e um ImageButton que permite definir ou selecionar uma data de nascimento, (iv) dois campos de EditText que representam os números de telefone residencial e celular, (v) um Spinner para seleção da unidade federativa e, por fim, (vi) dois campos de EditText para informar, respectivamente, o logradouro e CEP. Além disso, foram incluídas validações na aplicação para garantir que os valores informados pelo usuário da nova versão de AddressBook estejam corretos considerando as regras:

• O campo nome é obrigatório.
  • Caso o campo nome não seja preenchido, a mensagem “O campo nome deve ser preenchido” será exibida.
• O campo data de nascimento é opcional, porém, se informado, deverá estar no formato “dia/mês/ano” e não poderá ser maior ou igual à data atual.
  • Caso o campo data de nascimento não possua um valor correto, a mensagem “O campo data de nascimento deve ser preenchido corretamente” será exibida;
  • Caso o campo data de nascimento seja maior ou igual à data atual, a mensagem “O campo data de nascimento não deve ser maior que a data atual” será exibida.
• Pelo menos um dos campos de telefone, residencial e/ou celular, deve estar corretamente preenchido.
  • Caso nenhum dos campos esteja preenchido, a mensagem “O campo telefone residencial ou celular deve ser preenchido” será exibida;
  • Os valores informados para qualquer um dos campos de telefone, residencial ou celular, não devem possuir caracteres nem espaços. Em caso de existem valores incorretos, a mensagem “O campo telefone não deve possuir caracteres nem espaços” será exibida.
• O campo e-mail é opcional, porém, se informado, deverá estar no formato correto.
  • Caso o campo e-mail não possua um valor correto, a mensagem “O campo e-mail deve ser preenchido corretamente” será exibida.

Estes novos componentes e regras foram inseridos para incrementar a interação do usuário com a aplicação AddressBook e expandir o uso dos recursos disponíveis nas ferramentas de automação de teste que serão estudadas neste artigo e nas demais partes, como Monkey, MonkeyRunner, Espresso, Robolectric e Robotium. Na Figura 2 é ilustrada a tela que exibe uma listagem dos contatos cadastrados na aplicação AddressBook e, pressionando o botão “Menu” do dispositivo móvel ou até mesmo do emulador Android, pode-se selecionar a opção “Adicionar Contato” para iniciar a inclusão de um novo registro.

" [...] continue lendo...