Testes de Interface por Robô

Prévia do material em texto

Testes de interface por robô
Apresentação
O teste de software automatizado é uma etapa muito importante no processo de desenvolvimento. 
As atividades de teste têm como objetivo descobrir erros e defeitos de aplicações, a fim de produzir 
produtos confiáveis para o mercado. Para isso, a equipe de garantia de qualidade deve realizar 
testes manuais ou de automação adequados.
Nesta Unidade de Aprendizagem, você vai estudar a utilização do Robot Framework para 
desenvolver scripts de automação usando o Selenium para testar a interface gráfica do usuário 
(GUI). Vai aprender a personalizar seus scripts automatizados e também entender como o Robot 
Framework realiza testes de automação.
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
Conceituar testes de interface por robô com Selenium.•
Identificar o teste de interface por robô com Selenium por meio de suas características.•
Prever a aplicação do teste de interface por robô com Selenium.•
Desafio
O teste de aplicativos da web apresenta nova gama de desafios para testes em comparação com a 
testagem de aplicativos de desktop. Atualmente, são utilizados sistemas dinâmicos, que consistem 
em um back-end e um front-end e são geralmente heterogêneos, ou seja, são compostos de vários 
componentes desenvolvidos em diferentes linguagens de programação. Os aplicativos da web 
geralmente suportam vários usuários e operam em um ambiente muito mais aberto do que os 
aplicativos de desktop.
Você é analista de testes e foi designado para implementar a automação de testes de uma aplicação 
web. Essa aplicação tem uma enorme quantidade de possíveis interações com a interface do 
usuário (GUI), pois cada sequência de comandos da GUI pode resultar em um estado diferente. 
Além disso, um comando da GUI pode precisar ser avaliado em todos esses estados, o que resulta 
em um grande número de permutações de entrada.
Você foi recomendado a realizar o trabalho com a automação desses testes utilizando Selenium 
com Robot Framework, conforme imagem abaixo:
O Selenium é um conjunto de quatro diferentes ferramentas de software. Cada ferramenta tem 
uma abordagem diferente no suporte à automação de testes baseado na web.
I. Selenium IDE (Integrated Development Environment) 
II. Selenium RC (Remote Control) 
III. Selenium WebDriver 
IV. Selenium Grid
Com a finalidade de compreender a utilização das ferramentas para automação de testes e concluir 
a tarefa que lhe foi designada na empresa, responda a questões a seguir:
a) Qual a diferença entre cada um dos componentes do Selenium?
b) Considerando a resposta da questão anterior, qual é a ferramenta mais indicada para ser utilizada 
neste cenário? Justifique sua resposta.
Infográfico
O Selenium é geralmente a primeira ferramenta de automação de testes a ser mencionada, 
especialmente para testes baseados na web. Essa popularidade tem muita relação com o fato de ser 
de código aberto, livre para começar a usar e experimentar e por ter compatibilidade com quase 
todos os navegadores existentes. Para criação rápida de script de prova de conceito, o Selenium 
tem um ambiente de desenvolvimento integrado (IDE) que suporta ações de gravação na interface 
do usuário e, em seguida, as reproduz.
No Infográfico, você vai ver o detalhamento de cada umas das dimensões para desenvolvimento de 
testes automatizados usando o Selenium.
Aponte a câmera para o 
código e acesse o link do 
conteúdo ou clique no 
código para acessar.
https://statics-marketplace.plataforma.grupoa.education/sagah/26313ca2-c3a6-49b6-ad9d-1848cab14266/2c4728cc-c355-46e0-b186-8a8cc385ebca.png
 
 
Conteúdo do livro
A automação de testes exige o design, a criação e a manutenção de diferentes níveis de testes, 
incluindo o ambiente em que os testes serão executados, as ferramentas usadas, as bibliotecas de 
código que fornecem funcionalidade, os scripts e as cadeias de teste, as estruturas de registro e os 
relatórios de resultados do teste. Dependendo das ferramentas usadas, monitorar e controlar a 
execução dos testes pode ser uma combinação de processos manuais e automatizados.
No capítulo Testes de interface por robô, da obra Testes de software e gerência de configuração, que 
é base teórica desta Unidade de Aprendizagem, você vai saber mais detalhes sobre Robot 
Framework, que é uma estrutura de automação de teste genérica para testes de aceitação e 
desenvolvimento orientada a testes de aceitação (ATDD) e suas bibliotecas de suporte.
Boa leitura.
TESTES DE 
SOFTWARE E 
GERÊNCIA DE 
CONFIGURAÇÃO
Karine Birnfeld
Testes de interface por robô
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Conceituar testes de interface por robô com Selenium.
  Identificar o teste de interface por robô com Selenium por meio de 
suas características.
  Aplicar o teste de interface por robô com Selenium.
Introdução
Automatizar testes é uma forma de exercitar e verificar o software de-
senvolvido sem que haja participação humana. A integração das ferra-
mentas de automatização de testes nos processos de desenvolvimento 
de software contribui para que o ciclo de vida do projeto seja reduzido, 
assim como o seu custo. Além disso, essas ferramentas apresentam maior 
eficácia. Dessa forma, elas encontram maior quantidade de falhas e erros 
no sistema em desenvolvimento. 
Com a identificação de mais erros e a sua correção, a chance de a 
aplicação ter falhas ao ser entregue ao cliente é reduzida (MESZAROS, 
2007). Com o objetivo de apoiar a estratégia de automação de testes, 
neste capítulo, você vai estudar a implantação de testes automatizados 
com Selenium.
Testes com Selenium
O Robot Framework é um framework de código aberto para automação de 
testes. Ele é usado para testes de aceitação e para desenvolvimento orientado 
a testes de aceitação (Acceptance Test-Driven Development — ATDD). O 
Robot Framework tem uma sintaxe de dados de teste tabular e usa a abordagem 
de teste orientada por palavras-chave. Como a estrutura do robô segue uma 
arquitetura modular, a capacidade de teste pode ser estendida por bibliotecas 
de teste programadas com Python ou Java.
Esse framework é considerado uma estrutura de automação de testes de 
terceira geração. A configuração dos dados de teste da estrutura do robô não 
requer necessariamente programação ou script, mas apenas alteração de dados. 
O conceito de teste orientado por palavra-chave facilita a criação de dados de 
teste que direcionam a execução do teste.
A estrutura central do Robot Framework é implementada com Python, 
tornando-o independente do sistema operacional e do aplicativo. Ele também é 
executado em Jython (JVM) e IronPython (.NET). A possibilidade de executá-
-lo em qualquer sistema operacional que suporta Python o torna altamente 
flexível (ROBOT FRAMEWORK, 2019).
O Robot Framework processa os dados de teste quando é iniciado. A 
estrutura não precisa conhecer o sistema de destino, mas utiliza bibliotecas 
de teste para interagir com ele. As bibliotecas usam interfaces de aplicativos 
ou ferramentas de teste separadas como drivers.
Como você pode ver na Figura 1, a estrutura real se baseia nos dados de 
teste criados e, em seguida, utiliza os dados com a ajuda de diferentes biblio-
tecas. As bibliotecas, em seguida, usam ferramentas e interfaces para levar o 
sistema em teste a executar várias funções.
Figura 1. Arquitetura Robot Framework.
Fonte: Robot Framework Foundation (c2016, documento 
on-line).
Test Data
Robot Framework
Test Libraries
Test Tools
Test library API
Test data syntax
Application interfaces
System Under Test
Por sua vez, o Selenium é um conjunto de ferramentas que permite auto-
matizar testes de diferentes formas. Ele faz isso por meio de um conjunto de 
Testes de interface por robô2
funções que possibilitam a localização de elementos de interface do usuário 
e a comparação entre os resultados previstos para o teste e o comportamento 
real daaplicação (SELENIUMHQ, 2013).
As estratégias de automação simulam o usuário interagindo com o sistema 
em desenvolvimento. Em geral, os profissionais de testes aprendem a usar duas 
estratégias para automatizar os testes funcionais de interface com o usuário: 
codificar scripts de testes e utilizar ferramentas de captura/reprodução para 
gravar as ações do usuário com a aplicação.
Gravação
O Selenium IDE (Integrated Development Environment) é uma ferramenta 
para a construção de scripts de teste por meio de um plug-in para o navegador 
Firefox, que fornece uma interface amigável para o desenvolvimento dos testes 
automatizados. O Selenium IDE usa uma abordagem record-and-playback, 
capturando as ações executadas pelo testador em um script que permite re-
produzir o caso de teste posteriormente. Com os passos gravados, é possível 
reproduzi-los novamente em testes futuros e verifi car se as funcionalidades 
da aplicação estão funcionando corretamente.
Entre as vantagens da ferramenta, você pode considerar a facilidade 
de uso, já que ela não exige um nível alto de conhecimento técnico ou 
experiência (KOVALENKO, 2014). Além disso, o Selenium IDE é uma 
ferramenta de uso rápido e intuitivo: basta você acionar o botão de gravar e 
utilizar a aplicação que deseja testar como um usuário comum; a ferramenta 
identificará os elementos acessados na interface e gravará as suas ações. 
Já as desvantagens ficam por conta da inflexibilidade dos testes criados, 
pois existe a limitação de usar apenas o Firefox como browser para gravar 
e reproduzir os testes.
Existe também a dificuldade de esses testes automatizados se adaptarem 
às mudanças. A técnica de gravar e reproduzir as ações do usuário é afe-
tada quando ocorrem mudanças na interface ou no código do sistema. Essa 
dificuldade de se adaptar às mudanças compromete o reuso desses testes 
automatizados gravados. Segundo Kovalenko (2014), de forma geral, é baixo o 
nível de reuso dos testes funcionais de interface com o usuário automatizados 
via gravação.
Observe, na Figura 2, a seguir, os passos para a criação dos scripts com 
o Selenium IDE.
3Testes de interface por robô
Figura 2. Fluxo de gravação com a utilização do Selenium IDE.
A seguir, veja a descrição de cada um dos passos mostrados na Figura 2.
  Capturar os passos do caso de teste: o testador interage diretamente 
com o sistema, seguindo um caso de teste específico. Para cada ação 
feita pelo testador, a ferramenta cria um passo no script de testes.
  Definir critérios de validação: para validar as condições de saída 
do caso de teste, o Selenium IDE fornece vários mecanismos que 
permitem ao testador verificar o resultado da execução. Baseando-
-se nos critérios do caso de teste, o testador seleciona determinado 
elemento da página e faz asserções para verificar se os valores 
presentes naqueles componentes atendem aos resultados esperados 
para o caso de teste.
  Executar script: a execução do script de teste serve para verificar se o 
script gerado capturou todos os passos do caso de teste e se as verifica-
ções correspondem aos resultados esperados. Essa execução reproduz 
todas as ações e entradas informadas pelo testador durante a gravação 
do script. Ao final da execução, o critério de validação é avaliado 
informando ao usuário sobre o sucesso ou a falha do caso de teste.
Após a criação do script, é possível exportá-lo para uma das linguagens de 
programação suportadas, o que permite ao testador aprimorar o caso de teste 
de forma programática. Essa é uma característica importante do Selenium 
Testes de interface por robô4
IDE, já que ele é uma ferramenta de prototipagem rápida que não fornece 
recursos mais avançados como iterações e instruções condicionais. Para uma 
estratégia de automação mais robusta, recomenda-se o Selenium WebDriver 
(SELENIUMHQ, 2013).
Codificação
O Selenium WebDriver é uma API (Application Programming Interface) 
orientada a objetos, disponível para as linguagens de programação Java, C#, 
Ruby, Phyton e Javascript (SELENIUMHQ, 2013). Além da fl exibilidade 
proporcionada pela programação, a ferramenta suporta vários navegadores; 
entre eles: Google Chrome, Internet Explorer, Firefox e Opera. Além disso, 
ela permite testes em plataformas móveis, como Android e IOS.
Os componentes da tela são identificados por atributos do HTML (Hyper-
Text Markup Language), como o ID, ou por CSS e XPATH (ZHAN, 2015). 
O CSS (Cascading Style Sheets) é uma linguagem voltada para a forma ou o 
estilo como os componentes de tela são apresentados em um arquivo escrito 
em linguagem de marcação, como o HTML. Já o XPATH é uma linguagem de 
caminho XML e está voltada para a hierarquia dos itens de marcação contidos 
no HTML. Dessa forma, ele monta o caminho (path) partindo do item de mais 
alto nível até chegar ao elemento que deseja identificar. A verificação é feita 
utilizando frameworks de teste como JUnit, NUnit ou TestNG. O framework 
a ser usado depende da linguagem utilizada para codificar os scripts de testes, 
já que o Selenium WebDriver suporta diversas linguagens de programação 
(ZHAN, 2015).
Entre as vantagens de automatizar os testes funcionais de interface com 
o usuário via codificação está a melhor resposta às mudanças que afetam os 
testes. O código pode ser ajustado para que os testes automatizados voltem a 
funcionar corretamente, o que aumenta o seu poder de reuso. Outra impor-
tante vantagem é a possibilidade de executar os testes em diversos browsers 
(GUNDECHA, 2012).
A desvantagem é que, por ser feito via codificação, esse meio de automatizar 
testes funcionais de interface com o usuário exige um bom conhecimento 
sobre lógica de programação e sobre a linguagem que será utilizada. Além 
disso, há a necessidade de uma configuração antes de se iniciar a codificação 
e a execução dos testes automatizados. Na Figura 3, a seguir, você pode ver 
o processo de criação de um teste automatizado.
5Testes de interface por robô
Figura 3. Fluxo de codificação com a utilização do Selenium WebDriver.
Você pode buscar mais informações sobre a utilização do Selenium WebDriver no 
link a seguir.
https://qrgo.page.link/NL4Lo
Link
Características do teste com Selenium
Todos os recursos mencionados a seguir garantem que o Robot Framework 
seja usado para automatizar os casos de teste de maneira rápida e profi ciente.
Sintaxe tabular
Como você pode ver na Figura 4, o Robot Framework se baseia em arquivos 
de confi guração que seguem uma formatação específi ca do documento. Esse 
formato é chamado de “sintaxe de dados de teste tabular”. Isso signifi ca que, 
após o início de uma seção, toda nova linha de texto precisa ser planejada com 
dois ou mais espaços. Dados de teste são defi nidos em arquivos de confi guração, 
usando uma sintaxe específi ca. Vários casos de teste em um arquivo criam 
Testes de interface por robô6
um conjunto de testes, e vários arquivos em um diretório criam uma estrutura 
aninhada de suítes de teste (ROBOT FRAMEWORK, 2019).
Figura 4. Arquivo de dados de teste.
Fonte: Robot Framework (2019, documento on-line).
O Robot Framework suporta quatro formatos de arquivo diferentes. O 
formato tabular pode ser definido usando HTML, valores separados por 
tabulações (TSV), texto simples ou reStructuredText (reST). De acordo com o 
guia do usuário do Robot Framework, o formato de arquivo de texto simples 
é recomendado. A Figura 4 descreve um exemplo de um arquivo de dados de 
teste de texto simples. Os arquivos de dados de teste de texto simples devem 
ter uma extensão de arquivo .txt ou .robot (ROBOT FRAMEWORK, 2019).
A estrutura do script é simples e pode ser dividida em quatro seções. Veja 
a seguir.
  Settings: aqui, você configura as bibliotecas que serão utilizadas, os 
caminhos para arquivos auxiliares (page objects, por exemplo), os 
contextos e os hooks.
  Variables: é a lista das variáveis a serem usadas (de preferência com 
descrição) e a definição dos valores de algumas dessas variáveis.
  Test cases: essaé a seção mais importante, pois sem ela o seu teste 
não roda. É aqui que ficam os cenários/casos de teste, com ou sem 
implementação.
  Keywords: aqui, você pode definir palavras-chave ou implementar os 
cenários de teste descritos anteriormente.
7Testes de interface por robô
Todas as seções que você acabou de ver são opcionais e dependem de 
como o seu código foi escrito, exceto a test cases. A utilização dessas seções 
é importante para a melhor organização do código. 
Os rótulos a seguir não são obrigatórios, mas também ajudam na organização.
  [DOCUMENTATION]: essa palavra-chave precede a descrição da 
funcionalidade ou do cenário de teste. Fique atento: se a documentação 
é feita na seção settings, ela não deve estar entre colchetes. Estes só são 
usados dentro dos test cases.
  [TAGS]: esse é um rótulo mais simples para o cenário, caso você queira ou 
precise rodar somente um ou poucos casos. É possível fazer isso chamando 
pelo título dos cenários na linha de comando, mas, como geralmente eles 
são grandes, no geral as tags acabam sendo a melhor opção.
O Python é uma linguagem indentada, ou seja, blocos de comando são sepa-
rados por espaços ou tabulações, formando uma indentação visual obrigatória. 
Não existem símbolos de “abre” e “fecha”; o Robot herda essa formatação.
As variáveis no Robot são representadas por ${variavel}. O Robot tem a peculiaridade 
de ignorar um espaço entre palavras. Assim, ${nome_da_variavel} é igual a ${nome 
da variavel}. Elas também são case insensitive. As divisões dos argumentos são feitas 
por, no mínimo, dois espaços. Por exemplo:
comando (dois espaços) argumento1 (dois espaços) argumento 2…
Repare que o espaço no “argumento 2” é ignorado. O sinal de atribuição (=) também 
é opcional. Valores podem ser atribuídos das seguintes formas:
${valor} valor
${valor} = valor
Testes de interface por robô8
Palavras-chave
Testes orientados por palavras-chave ou testes orientados por tabela são 
amplamente aplicados a automações independentes de aplicativos. O testador 
precisa desenvolver tabelas de dados com palavras-chave, independente-
mente da estrutura de automação de teste ou de qualquer outra ferramenta 
usada para executá-la. Em seguida, é necessário codifi car o script de teste, 
que “direcionará” o aplicativo testado e os dados. As tabelas em um teste 
orientado por palavra-chave contêm as informações sobre a funcionalidade 
do aplicativo testado e as instruções passo a passo para cada teste. No geral, 
pode-se falar de:
  palavras-chave de nível superior, usadas para testar um aspecto es-
pecífico do sistema;
  palavras-chave de nível inferior, utilizadas para manter os casos 
de teste mínimos e concisos (o teste de funcionalidade necessário é 
separado em várias palavras-chave de nível inferior);
  palavras-chave técnicas, implementadas no teste para acessar real-
mente o sistema e executar os testes.
O framework inicia a execução com a análise dos arquivos de dados de teste. 
Em seguida, ele usa palavras-chave definidas nos arquivos de dados de teste 
e começa a interagir com o sistema de destino. As bibliotecas se comunicam 
diretamente com o sistema, mas outras ferramentas de teste também podem 
ser utilizadas como drivers (ROBOT FRAMEWORK, 2019).
Como você pode ver na Figura 5, as palavras-chave atuam como coman-
dos para o framework saber o que deve ser executado no sistema de destino. 
É possível utilizar palavras-chave predefinidas encontradas em bibliotecas 
existentes; além disso, novas palavras-chave podem ser definidas para novas 
bibliotecas.
9Testes de interface por robô
Figura 5. Arquivo de dados de teste com palavras-chave.
Fonte: Robot Framework (2019, documento on-line).
Seções diferentes (tabelas de dados de teste) de um arquivo de dados de 
teste são separadas por uma linha de texto começando e terminando com um 
ou mais caracteres de asterisco (*). Além disso, as seções devem ser separadas 
por uma quebra de linha, para manter os dados legíveis. Variáveis globais 
são inicializadas na seção Variáveis. Uma variável começa com um sinal de 
dólar ($) e o nome pode ser qualquer coisa, desde que descreva a finalidade 
da variável e esteja cercado por um par de chaves ({}). Ao definir palavras-
-chave, a primeira linha de cabeçalho deve ser deixada sem identificação. 
Testes de interface por robô10
Cada palavra deve começar com uma letra maiúscula e ser separada por um 
espaço. Ao se aprofundar na definição da palavra-chave, o recuo deve ter pelo 
menos dois caracteres de espaço.
Na Figura 5, há quatro caracteres de espaço no recuo. Recomenda-se 
manter a largura do recuo consistente em todos os arquivos de dados de teste 
em um conjunto de testes. Especialmente no formato de texto simples, o uso 
de caracteres de espaço é recomendado em vez de um caractere tabular. Além 
disso, ao se referir a uma variável entre palavras-chave, pelo menos dois 
caracteres de espaço devem ser usados antes da variável para o analisador do 
Robot Framework separar as variáveis das palavras-chave usuais.
Aplicação do teste com Selenium
Um processo de automação coerente deve englobar atividades prévias ao 
desenvolvimento de scripts. Essas atividades incluem, por exemplo, a defi ni-
ção da estratégia de automação e a análise dos benefícios e da viabilidade do 
processo para a aplicação ou o sistema em teste.
Nem todos os testes manuais devem ser automatizados. Como um script 
automatizado requer mais análise, mais design, mais engenharia e mais manu-
tenção do que um script manual, você deve calcular o custo de criá-lo. Além 
disso, assim que criar o script automatizado, você tem de mantê-lo para sempre, 
e isso também deve ser considerado. Quando o sistema a ser testado muda, 
geralmente os scripts automatizados precisam ser alterados simultaneamente.
A análise prévia à automatização deve levar em conta os pontos listados 
a seguir.
  Complexidade da aplicação: é necessário investigar a complexidade 
da aplicação a ser automatizada e a sua integração com a ferramenta 
de automação. Aplicações complexas podem exigir elevado esforço 
na codificação dos scripts de automação, ou mesmo ser incompatíveis 
com determinadas ferramentas de automação, o que pode inviabilizar 
a iniciativa.
  Estabilidade da aplicação: caso a aplicação não esteja suficientemente 
madura (sobretudo no início do seu ciclo de vida) e seja previsível que 
venha a sofrer constantes alterações, a automação é dificultada pelo 
grande esforço de manutenção dos scripts e pode se revelar pouco 
compensadora.
11Testes de interface por robô
  Ciclo de vida da aplicação: caso o ciclo de vida da aplicação em questão 
seja curto — por exemplo, um sistema desenvolvido para uma situação 
específica que terá seu uso descontinuado em breve —, é improvável 
que a automação seja viável.
Inevitavelmente, você vai identificar novas maneiras pelas quais um script 
automatizado pode falhar: simplesmente obter um valor de retorno nunca visto 
antes fará com que a automação falhe, por exemplo. Quando isso acontecer, 
você vai ter de alterar, testar e implantar novamente o script. Esses problemas 
geralmente não ocorrem com testes manuais.
Um caso de negócio precisa ser feito antes e enquanto você automatiza 
os seus testes. Você deve analisar se o custo total da automação do teste será 
retornado, podendo ser executado N vezes nos próximos M meses. Muitas 
vezes, a resposta obtida por meio dessa análise é que a automatização não 
vale a pena. Dessa forma, alguns testes permanecerão manuais porque não 
há retorno positivo sobre o investimento (Return On Investment — ROI) para 
automatizá-los.
Alguns testes manuais simplesmente não podem ser automatizados porque o pro-
cesso de pensamento do testador manual é essencial para o sucesso do teste. Testes 
exploratórios, ataques de falhas e alguns outros tipos de testes manuais ainda são 
necessários para o sucesso de um esforço de teste.
Uma vez que uma iniciativa de automação seja considerada viável para 
dadosistema, deve-se inicialmente realizar uma análise dos testes candidatos 
à automação. Essa análise permite identificar quais são os testes que, uma 
vez automatizados, gerarão maior retorno em relação ao esforço requerido 
para a sua automação.
Existem testes cuja automatização é mais aconselhável. A seguir, veja 
alguns exemplos.
Testes de interface por robô12
  Testes de carga e desempenho: testes automáticos são um pré-requisito 
para esse tipo de teste. É impraticável economicamente utilizar cem ou 
mais usuários, durante um teste, para acessar um sistema simultanea-
mente a fim de avaliar a sua qualidade sob tais condições.
  Testes de regressão: representam uma das melhores aplicações da au-
tomação de testes. Testes de regressão usualmente custam muito tempo 
para serem executados manualmente e são muito suscetíveis a erro hu-
mano, devido ao seu nível de repetitividade. Ao automatizar, reduz-se 
drasticamente a possibilidade de o sistema ser produzido com a inserção 
de um novo defeito em uma funcionalidade antiga. Além disso, o ganho 
em tempo de execução dos testes geralmente justifica a sua utilização.
  Tarefas repetitivas: nesses casos, a grande vantagem do teste automá-
tico se deve à redução de erros. Testes manuais repetitivos normalmente 
exigem um grande nível de concentração do testador, que não deve se 
distrair, apesar do cansaço psicológico da repetição. Assim, justifica-
-se a automação nos casos em que se verifica que os testes têm obtido 
resultados não verdadeiros devido a falhas humanas.
  Smoke tests: são testes básicos aplicados às principais funcionalidades 
do sistema. Esse tipo de teste visa a identificar defeitos nas funciona-
lidades com o intuito de avaliar se a versão liberada pode continuar 
sendo testada pela equipe de testes.
  Testes de unidade: com a existência de tantas ferramentas gratuitas de 
testes unitários para quase todas as linguagens, não utilizá-las é con-
traprodutivo. O ganho em tempo ao utilizar essas ferramentas justifica 
a sua utilização na maioria dos casos.
  Cálculos matemáticos: o objetivo desse tipo de texto é evitar erros 
humanos.
  Funcionalidades críticas: como seres humanos são influenciados 
pelo seu humor ao executarem uma tarefa, funcionalidades críticas 
não deveriam depender de um testador, que pode esquecer-se de testar 
algo importante.
  Preparação de pré-condições: ferramentas de automação de testes 
podem e devem ser usadas para preparar ambientes de teste, como 
condições iniciais ou entradas que serão utilizadas nos testes. É claro 
que esse jamais será o primeiro passo a ser dado quando se pretende 
automatizar um software; porém, uma vez que se possua a ferramenta, 
deve-se utilizá-la de modo a maximizar a produtividade.
13Testes de interface por robô
Por outro lado, a automação não é recomendada para os casos listados a 
seguir.
  Funcionalidades novas: essas funcionalidades têm uma grande pro-
babilidade de mudanças, então o ideal seria criar o teste quando se 
alcança certa estabilidade.
  Funcionalidades pouco usadas: haverá um custo e um esforço des-
necessários, já que os testes serão pouco aplicados em decorrência da 
pouca utilização da funcionalidade.
  Funcionalidades que exigem inspeção visual: não existe uma maneira 
de avaliar a interface de um sistema e a sua usabilidade. Para isso, é 
necessária a visão de um testador.
  Protótipos: o protótipo é utilizado momentaneamente no início de um 
projeto de software, para ser exibido para clientes ou para a própria 
organização. Por isso, não há a necessidade de automatizar testes em 
um protótipo, já que ele ainda não é o software propriamente dito.
A automação de testes de software não possui competências isoladas. Para 
o sucesso e o bom uso da automação de testes, deve haver testabilidade no 
software. A testabilidade examina as diferentes probabilidades e características 
comportamentais que levam o código a falhar se alguma coisa estiver incorreta. 
Assim, a testabilidade está alinhada e engajada com a qualidade da aplicação.
Os níveis de testabilidade de uma aplicação podem ser definidos e enten-
didos conforme a apresentação de falhas durante a execução de testes. Um 
programa tem alta testabilidade se ele tende a expor as suas falhas durante os 
testes com entradas que geram defeitos. Um programa tem baixa testabilidade 
se ele tende a ocultar as falhas detectadas durante os testes, produzindo saídas 
corretas para entradas que geram defeitos.
Seja por execuções manuais ou execuções automatizadas de testes, é impor-
tante e indispensável ter requisitos bem documentados, detalhados, objetivos 
e alinhados com o que se espera do software enquanto produto final. É com 
esses requisitos e documentos que o testador ou automatizador de testes vai 
desenvolver os testes manuais e os scripts de testes automatizados.
Tanto em aplicações já desenvolvidas quanto em novas a serem criadas, 
algumas alterações serão pertinentes e necessárias para que se tenha testabili-
dade. Normalmente, é preciso realizar modificações na aplicação para torná-la 
mais fácil de ser testada. Essas modificações têm o objetivo de incorporar um 
conjunto de mecanismos que facilitam a observação e o controle do estado 
dos componentes internos da aplicação.
Testes de interface por robô14
GUNDECHA, U. Selenium testing tools cookbook: over 90 recipes to build, maintain, and 
improve test automation with selenium webdriver. Birminghan: Packt, 2012.
KOVALENKO, D. Selenium design patterns and best practices. Birmingham: Packt, 2014.
MESZAROS, G. xUnit test patterns: refactoring test code. Upper Saddle River: Addison-
-Wesley, 2007.
ROBOT FRAMEWORK. [Site]. [2019]. Disponível em: http://robotframework.
org/#introduction. Acesso em: 24 jun. 2019.
ROBOT FRAMEWORK FOUNDATION. Robot framework user guide: version 3.1.2. c2016. 
Disponível em: https://robotframework.org/robotframework/latest/RobotFrameworkU-
serGuide.html. Acesso em: 24 jun. 2019.
SELENIUMHQ. Selenium webdriver. 2013. Disponível em: http://docs.seleniumhq.org/
docs/03_webdriver.jsp. Acesso em: 24 jun. 2019.
ZHAN, Z. Selenium webdriver recipes in C#. 2nd ed. New York: Apress Media, 2015.
Leituras recomendadas
A4Q. Alliance for qualification. 2018. Disponível em: https://cdn.website-editor.net/0
fa31c5707954e47832ceaaddbdfde76/files/uploaded/A4Q_SeleniumTesterFounda-
tion_Syllabus.pdf. Acesso em: 24 jun. 2019.
PRASAD, R. Learning selenium testing tools. 3rd ed. Birmingham: Packt, 2015.
PUGH, K. Lean-agile acceptance test-driven development: better software through colla-
boration. Upper Saddle River: Addison-Wesley, 2011.
SELENIUM2LIBRARY. [2019]. Disponível em: https://rtomac.github.io/robotframework-
-selenium2library/doc/Selenium2Library.html. Acesso em: 24 jun. 2019.
15Testes de interface por robô
Dica do professor
Uma classe geralmente usada para a automatização de testes é a classe Java.awt.Robot. Ela é usada 
para assumir o controle do mouse e do teclado. Uma vez que você obtém o controle, pode fazer 
qualquer tipo de operação relacionada a esses dispositivos por meio do código Java.
Na Dica do Professor você vai saber o que é Java Robot, qual o processo de instalação e como 
pode trabalhar com a classe de robô no webdriver de Selenium. Também aprenderá as vantagens e 
desvantagens da classe e da estrutura do robô Java, além dos métodos da classe do robô em 
detalhes.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
https://fast.player.liquidplatform.com/pApiv2/embed/cee29914fad5b594d8f5918df1e801fd/17edab55c21da774b4916466ed825d06
Exercícios
1) Selenium IDE é uma ferramenta para a construção de scripts de teste por meio de um plugin 
para o navegador Firefox, que fornece uma interface amigável para o desenvolvimento de 
testes automatizados. O Selenium IDE usa abordagem record-and-playback.
O que é a abordagem record-and-playback?
A) Uma função em uma biblioteca de software.
B) A interface na qual os testes do Seleniumsão escritos.
C) A representação das camadas, componentes e interfaces de uma arquitetura de automação 
de testes.
D) Uma abordagem de automação de testes que permite gravar, salvar e reproduzir scripts de 
teste.
E) Uma fonte para determinar o resultado esperado de um caso de teste.
2) O Robot Framework utiliza uma sintaxe tabular, pois se baseia em arquivos de configuração 
que seguem uma formatação específica. A estrutura do script pode ser dividida em seções. 
Qual dessas seções necessita, obrigatoriamente, constar no seu arquivo de automatização? 
A) Settings.
B) Variables.
C) Test cases.
D) Keywords.
E) Documentation.
Selenium é um conjunto de ferramentas usadas para automatizar testes por meio de um 
conjunto de funções que permitem a localização de elementos de interface do usuário e a 
comparação entre os resultados previstos para o teste e o comportamento real da aplicação. 
Cada ferramenta tem uma abordagem diferente no suporte ao teste de automação baseado 
na web.
3) 
Para qual das ferramentas do Selenium a sua aplicação está correta?
A) Selenium IDE (Integrated Development Environment) é uma API (Application Programming 
Interface) orientada a objetos; disponível para as linguagens de programação Java, C#, Ruby, 
Phyton e Javascript.
B) Selenium RC (Remote Control) é um plugin do Firefox. É a estrutura mais simples da Suíte 
Selenium e permite gravar e reproduzir scripts.
C) Selenium WebDriver é uma estrutura de automação de navegador que aceita comandos e os 
envia para um navegador. Ele é implementado por meio de um driver específico do 
navegador.
D) Selenium Grid usa uma abordagem record-and-playback, capturando as ações executadas pelo 
testador em um script que permite reproduzir o caso de teste posteriormente.
E) Selenium WebDriver é uma ferramenta usada em conjunto com o Selenium RC para executar 
testes em diferentes máquinas e navegadores em paralelo.
4) Na seção VARIABLES são listadas as variáveis a serem usadas (de preferência com 
descrição) e a definição dos valores de algumas dessas variáveis.
Qual é a forma correta de declaração das variáveis nos dados de teste do Robot?
A) $(nome_da_variavel).
B) ${nome_da_variavel}.
C) &{nome_da_variavel}.
D) @(nome_da_variavel).
E) @{nome_da_variavel}.
5) Alguns testes manuais simplesmente não podem ser automatizados porque o processo de 
pensamento do testador manual é essencial para o sucesso do teste. Testes exploratórios, 
ataques de falhas e alguns outros tipos de testes manuais ainda são necessários para o 
sucesso de um esforço de teste. 
Qual das alternativas abaixo é correta em relação à indicação para automação de testes?
A) É aconselhável a automação de testes de carga e desempenho.
B) Não é recomendada a automatização de testes com tarefas repetitivas.
C) Testes automatizados são imprescindíveis para as funcionalidades novas do sistema.
D) Funcionalidades pouco usadas precisam ser automatizadas, já que nem sempre são acessadas 
por outros testes.
E) Não é aconselhado o processo de automatização para testes de regressão, já que os testes 
manuais são executados de maneira mais rápida.
Na prática
O Robot é um framework para automação de testes de aceitação (acceptance test-driven 
development). É open source e independente de sistema operacional. Nativamente implementado 
para Python e Java, mas também roda em Jython (JVM) e IronPython (.NET). Sua sintaxe é tabular, 
como o Python, e usa uma abordagem de palavras-chave (keyword driven). Essa abordagem permite 
a escrita de cenários com linguagem totalmente natural.
Confira, Na Prática, como fazer uma busca simples no Google utilizando testes automatizados com 
Robot Framework.
Aponte a câmera para o 
código e acesse o link do 
conteúdo ou clique no 
código para acessar.
https://statics-marketplace.plataforma.grupoa.education/sagah/541c7f5c-7eae-45a7-b3f9-ef1101d08b4c/0fb481a8-ae34-4299-a187-b54cc4e067cb.jpg
Saiba +
Para ampliar o seu conhecimento a respeito desse assunto, veja abaixo as sugestões do professor:
Rebot Framework user guide
Leia a documentação oficial do Robot Framework, que traz um guia do usuário com descrição bem 
completa de todas as funcionalidades desta ferramenta.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
Rebot Framework demo
Acesse um aplicativo de demonstração que se trata de uma calculadora muito simples 
implementada com o Python (calculator.py). Ele contém apenas lógica de negócios e nenhuma 
interface de usuário.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
Automação de testes de aplicações móveis sem necessidade de 
programação
Leia o artigo no qual é demonstrado o desenvolvimento de um framework de monitorização e teste 
de aplicações Android com base em especificações, capaz de testar aplicações com suporte 
multiplataforma sem necessidade de alterar ou conhecer o seu código fonte.
http://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html
https://github.com/robotframework/RobotDemo
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
Caso de demonstração de uma framework para automatização 
do teste de APIs de aplicações SaaS
Leia a dissertação que está enquadrada num contexto real em que é realizada a seleção de 
ferramentas de teste de APIs, para posteriormente escolher a mais adequada e utilizá-la na 
automatização de um conjunto de casos de teste inserido na cloud.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
Automação de testes utilizando ferramentas open source em 
ambiente ágil de desenvolvimento com SCRUM
Leia o artigo no qual os autores compartilham experiências sobre a automação do processo de 
teste de um sistema web desenvolvido utilizando SCRUM.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
Applying test automation in usability testing
Leia a tese que estuda a aplicabilidade da automação de testes no contexto de testes de 
usabilidade.
https://repositorio-aberto.up.pt/handle/10216/85797
https://repositorium.sdum.uminho.pt/handle/1822/39595
https://www.academia.edu/10000636/Automa%C3%A7%C3%A3o_de_Testes_utilizando_ferramentas_Open_Source_em_Ambiente_%C3%81gil_de_Desenvolvimento_com_SCRUM
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
https://www.theseus.fi/bitstream/handle/10024/169365/Automation_in_usabilitytesting_Virtanen_Final_publ.pdf?sequence=2