Testes Funcionais;Testes Funcionais Automatizados; Introdução ao Selenium suas ferramentas; Tecnicas para utilização do Selenium

1. Curso de Testes Automatizados
Unidade IV
Boas Praticas

2. Agenda
● Testes de Software
● Testes Funcionais
● Automação de Teste Funcionais
● Selenium
● Exemplos
● Exercícios

3. Testes de Software
● Defininições
● Atividade que tem como objetivo verificar se o software
construido está de acordo com sua especificação e
atende as expectativas do usuario.
● É uma investigação conduzida para fornecer os
interessados informações sobre a qualidade do produto
ou serviço em teste.
● Processo de validação e verificação de que um
programa de software (aplicativo ou produto).
– Cumpre com os requisitos que o orientaram na concepção e
desenvolvimento
– Funciona conforme esperado

4. Aumentando a Qualidade
● Ao realizarmos testes durante
o desenvolvimento de software
adicionamos valor ao produto,
uma vez que o teste
corretamente executado tende
a descobrir defeitos, que
devem ser corrigidos,
aumentando assim a qualidade
e confiabilidade de um sistema.

5. Tipos de Testes
● Teste de Unidade
● Teste a menor unidade possível do software
● Teste de Integração
● Teste de vários componentes dependentes
● Teste Funcionais
● Verifica se as especificações funcionais estão corretamente implementadas
● Teste de Desempenho
● Pode verificar se o desempenho do Software está dentro do aceitável
● Teste de Estresse
● Verifica funcionamento sobre condição anormal de demanda.
● Teste de Usabilidade
● Verifica se o software é adequado ao uso

6. Tipo de Testes
● Teste de Aceitação
● Teste realizado pelo usario para decidir sobre a aceitação do
produto
● Teste de Segurança
● Verificar nível de segurança
● Teste de Regressão
● Mostrar que o software continua funcionando após alguma
alteração
● Teste de Instalação
● Verifica se os procedimentos de instalação são corretos e
bem documentados

7. Tipo de Testes
● Teste Alfa
● Liberação do produto para pequenos grupos de
usuário em um ambiente controlado
● Teste Beta
● Ambiente não controlado

8. Testes Funcionais
● O teste funcional é um teste para avaliar o
quanto o comportamento observado do
software está em conformidade com as
especificações Isso significa que esse teste é
baseado na análise da especificação de
funcionalidades do software testado

9. Engenharia de Software
● Princípios
● Planejamento dos Testes
● Granularidade dos Testes
● Abordagens de Teste

10. Princípios
● Princípio 1: Testes demonstram a presença de
defeitos, não a ausência.
● Princípio 2: Teste exaustivo é impossível.
● Princípio 3: A atividade de teste deve começar o
mais cedo possível.
● Princípio 4: Defeitos tendem a estar agrupados.
● Princípio 5: O paradoxo do pesticida
● Princípio 6: Testes dependem do contexto.
● Princípio 7: A ilusão da ausência de falhas.

11. Princípio 1
● A principal finalidade do teste é
detectar falhas de software de
modo que os defeitos poção ser
descobertos e corrigidos. Teste
não pode estabelecer que um
produto funciona corretamente
em todas as condições, mas só
pode demonstrar que ela não
funciona adequadamente em
"Os testes podem apenas mostrar condições específicas.
a presença de erros, não sua
ausência", Dijkstra, et al. 1972

12. Princípio 2
● Teste exaustivo é impossível, Testar todos os
valores possíveis para todas as entradas,
efetuando todas as formas de combinação e
levando em conta diferentes precondições é
geralmente impossível.
● Na prática, na maioria das vezes os softwares
requerem números astronomicamente altos de
casos de testes. Assim, em vez do teste
exaustivo, o testador deve levar em conta os
riscos e prioridades do sistema sob teste para
focar os casos dos testes.

13. Princípio 3
● A atividade de teste deve começar o mais
cedo possível. E deve ser focado em objetivos
definidos.

14. Princípio 4
● Defeitos tendem a estar agrupados.
Geralmente a maioria dos defeitos são
encontrados em algumas partes do software
sob teste, ou seja, é muito pouco provável que
os defeitos estejam uniformemente distribuídos
pelo software

15. Princípio 5
● O paradoxo do pesticida Pode ocorrer de um
mesmo conjunto de testes que são repetidos várias
vezes não encontrarem novos defeitos após um
determinado momento.
● Para superar este “paradoxo do pesticida”, os casos
de testes necessitam ser frequentemente revisados
e atualizados.
● Um conjunto de testes novo e diferente precisa ser
escrito para exercitar diferentes partes do software
ou sistema com objetivo de aumentar a
possibilidade de encontrar mais falhas.

16. Princípio 6
● Testes dependem do contexto. Os testes
devem ser adaptados aos riscos e ambientes
inerentes da aplicação.
● Softwares de segurança crítica, como por
exemplo o do computador de bordo de
aeronaves, são testados diferentemente de
softwares do comércio eletrônico

17. Princípio 7
● A ilusão da ausência de falhas. Encontrar e
consertar defeitos não ajuda se o sistema
construído não atende às expectativas e
necessidades dos usuários.

18. Planejamento dos Testes
● Os testes devem ser planejados com base no objetivo
principal que é revelar a existência de defeitos
● O Desenho de dos casos de testes e a preparação dos dados
de teste constituem atividades fundamentais do testador.
● Um caso de teste é constituído por um conjunto de dados de
entrada, condições de execução de uma ou mais operações e
resultados esperados ou dados de saída, desenvolvidos com
um objectivo particular.
● É preciso determinar quais os testes mais importantes devem
ser executados

19. Planejamento dos Testes
● Principais técnicas para implementar casos de
testes.
● Partição de equivalência
– Divide o domínio da entrada em categorias de dados
– Cada categoria agrupa os dados que possuem as
mesma categoria.
● Analise do valor Limite
– Os casos de testes são escolhidos próximos ou na
fronteiras dos domínios da entrada.
– Boa parte das falhas tendem a se concentrar próximo a
esses valores

20. Granularidade dos Testes
● Devido a complexidade do sistema as atividades de
teste devem ser feitas em diferentes estágios.

21. Abordagens de Teste
● Testes Black Box ou Testes Funcionais e Testes
White Box ou Testes Estruturais representam as
principais abordagens.
● A abordagem funcional
● Melhor aplicada a componentes do sistema
● Realizada por equipe de testes
● Abordagem Estrutural
● Melhor aplicada a componentes individuais ou
coleções de componentes dependentes
● Realizada pela equipe de desenvolvimento

22. Testes Manuais vs Testes
Automáticos

23. Testes Manuais vs Testes
Automáticos
● Teste Manual
● Baseado em casos e procedimentos de testes
● Em geral são cansativos e de difícil repetição
● Teste Automatizado
● Baseado em casos e procedimentos de testes
● Exige maior esforço para implementar
● Em geral são mais fáceis de executar e repeti-los

24. Testes Manuais vs Testes
Automáticos
● Antes de decidir em automatizar ou não os
testes, é preciso analisar a aplicação testada e
quais testes serão construídos
● A principal razão para automação dos testes é
a necessidade de reexecução dos mesmos.

25. Testes Manuais vs Testes
Automáticos
● A automação geralmente demanda bem mais
esforço que sua execução manual.
● Em determinadas situações, automatizar é a
melhor maneira de economizar tempo e
dinheiro.
● Contudo, nem sempre é vantajoso automatizar
os testes. Existem situações em que realizar os
testes manualmente é mais adequado.

26. Testes Manuais vs Testes
Automáticos
● Recomendações
● A identificação, seleção e desenho dos casos de
testes funcionais devem ser feitos por um testador
que domine o domínio da aplicação.
● O automatizador de testes pode ser ou não um
testador, devendo sempre ter habilidades em
programação.
● A habilidade do automatizador ditará a qualidade da
automação, mas será a habilidade do testador quem
ditará a eficácia dos testes realizados.

27. Automatização da Atividade de
Teste

28. Automatização da Atividade de
Teste
● Identificação
● O testador determinará o que será testado
identificando as condições de teste (itens ou
eventos) que precisam ser verificados por cada
teste.

29. Automatização da Atividade de
Teste
● Desenho
● O desenho dos casos de teste determinará como
as condições de testes serão testadas.

30. Automatização da Atividade de
Teste
● Construção
● Nesta atividade os casos de teste são
transformados em scripts de teste que quando
utilizados durante uma execução manual do teste,
é também chamado de procedimento de teste

31. Automatização da Atividade de
Teste
● Execução
● Nesta atividade o sistema é executado utilizando os
scripts de teste. Para testes manuais, esta fase
pode consistir de testadores a seguirem as
instruções existentes em um procedimento de
teste.

32. Automatização da Atividade de
Teste
● Comparação
● Os resultados obtidos do sistema sob testes são
usados para determinação do resultado do teste.
Existem dois possíveis resultados: Sucesso ou
Falha.

33. Selenium
● O Selenium é um conjunto de ferramentas
OpenSource que pode ser usada para criação de
testes funcionais automatizados para aplicações
Web.
● Principais vantagens
● Possibilidade de executar os testes em qualquer
navegador com suporte a JavaScript .
● Ferramentas que compõem o Selenium provêm um
rico conjunto de funções específicas para a
implementação de testes.
● Gera Scripts para Java, C#, Pytho e Ruby

34. Ferramentas Selenium
● Atualmente as principais ferramentas que compõem o
Selenium são: Selenium-IDE, Selenium RC, Selenium
WebDriver e Selenium-GRID.
● O Selenium-IDE
● É um ambiente de desenvolvimento integrado para construção de
casos de testes. Ele opera como plug-in do Firefox e provê
interfaces amigáveis para o desenvolvimento e execução de suítes
de testes (conjunto de testes).
● É uma ferramenta do tipo record-and-playback, ou seja, ela captura
as ações executadas pelo testador e gera um script que permite a
reexecução das ações feitas, e assim automatizando o teste.

35. Ferramentas Selenium
● Selenium RC (Remote-Control).
● Possibilita uma maior flexibilidade ao testador,
permitindo a construção de lógicas de teste mais
complexas, a partir do uso de uma linguagem de
programação.
● Para isso, ele provê uma API (Application
Programming Interface) e bibliotecas para cada
uma das linguagens suportadas: HTML, Java, C#,,
Python, e Ruby.

36. Ferramentas Selenium
● Selenium WebDriver
● Pode chamar o navegador atraves de driver nativo
da maquina local ou remota
● É o substituto do Selenium RC
● A inclusão do API WebDriver foi declarda pela
equioe do Selenium a mas recente grande
mudança.
● “A chamada de um browser nativamente como um
usuário local ou em uma máquina remota usando o
Servidor Selenium marca um salto em frente em
termos de automação browser”.

37. Ferramentas Selenium
● Selenium-Grid
● Permite distribuir os testes em múltiplas máquinas,
reduzindo assim o tempo gasto na execução de
uma suíte de testes. Ele é ideal para escalonar
grandes suítes de testes ou suítes de testes que
devem ser executadas em múltiplos ambientes.
● O Selenium-Grid atua executando múltiplas
instâncias do Selenium-RC em paralelo de forma
transparente, fazendo com que os testes não
precisem se preocupar com a infraestrutura
utilizada.

38. Introdução a API
● Selenium permite realizar uma série de ações
necessárias para execução de testes em
páginas web, tais como, entrar com valores em
campos da página, selecionar itens de uma
lista de opções, clicar em botões, clicar em
links e realizar asserções com base nos
resultados exibidos da página.
● Os comandos que realizam essas ações são
divididas em três grupos, veremos a seguir:

39. Comandos
● Actions
● São comandos que geralmente causam uma
mudança no estado da aplicação. Eles
representam operações realizadas pelo usuário
durante a execução de um sistema web, tais como
o comando “click” que indica um clique em um
determinado botão ou link. A maioria desses
comandos pode conter o sufixo “AndWait”, o que
indica que a ação fez uma chamada ao servidor e
que o Selenium deve esperar a página carregar
para executar o próximo passo.

40. Comandos
● Accessors
● Examinam o estado da aplicação e armazenam o
resultado em variáveis, como o comando
“storeTitle” que armazena o titulo da página em
uma variável determinada por parâmetro.

41. Comandos
● Assertions
● São como os Accessors, mas verificaram se o estado da
aplicação está conforme o esperado. Todas as asserções do
Selenium podem ser usadas de três modos:
– “assert”, “verify” e “waitFor”.
● Para verificar a presença de um certo texto em um
determinado local, por exemplo, pode-se usar o comando
“assertText”, “verifyText” ou “waitForText”.
● Com o “assert”, se a verificação falhar o teste para,
enquanto que com o “verify” a ferramenta acusa a falha mas
o teste continua executando. Já no modo “waitFor”, que é
muito útil para testar aplicações com Ajax, o Selenium
espera o texto aparecer para prosseguir a execução.

42. Comandos Específicos
● open: abre uma página usando uma URL que é
fornecida como parâmetro;
● click/clickAndWait: executa o clique em um
botão, link ou imagem;
● verifyTextPresent/assertTextPresent: verifica
a presença de um texto em qualquer lugar da
página;
● verifyText/assertText: verifica se um texto
aparece em um determinado local;

43. Comandos Específicos
● waitForPageToLoad : pausa uma execução
do teste até que uma nova página seja
carregada. Esse comando é chamado
automaticamente pelos comandos com
terminação “AndWait”;
● type: entra com um valor em um determinado
campo da página;
● select: seleciona um elemento dentre uma lista
de opções.

44. Convenções
● Quanto aos parâmetros utilizados pelos
comandos do Selenium, eles tipicamente são:
● i) uma identificação para algum elemento da
página;
● ii) um texto para verificar se ele aparece na página
ou para colocá-lo em algum campo da página.
● O número de parâmetros usados varia de
acordo com o comando. Alguns exigem dois
parâmetros, outros exigem somente um, e
existem aqueles que não utilizam parâmetros.

45. Exemplo de Script HTML
● <body>
● <table cellpadding="1" cellspacing="1" border="1">
● <thead>
<tr><td rowspan="1" colspan="3">New Test</td></tr>
</thead><tbody>
<tr>
<td>open</td>
<td>/</td>
<td></td>
● </tr>
● <tr>

46. Exemplo de Script HTML
● <td>clickAndWait</td>
● <td>link=Plugins</td>
● <td></td>
● </tr>
● <tr>
● <td>type</td>
● <td>css=#pluginSearch &gt;
input[name=&quot;q&quot;]</td>
● <td>appengine</td>
● </tr>

47. Exemplo de Script HTML
● <td>clickAndWait</td>
<td>css=input.searchButton</td>
<td></td>
● </tr>
● <tr>
<td>verifyTextPresent</td>
<td>Grails AppEngine plugin</td>
● <tr>
● <td></td>
● </tr>
● </tbody></table></body>

48. Selenium-IDE
● Exemplos
● Exercicio

49. Livros

50. Referências
● Santos Ismayle, Neto, Perdo. Automação de
testes funcionais com o Selenium. 2008
● Correia, Simone Silva Alberto.Tecnicas de
Contrução de Testes Funcionais. 2006
● Osherove, Roy. The art of unit testing : with
examples in .NET. 2009
● Meszaros, Gerard. XUnit test patterns :
refactoring test code. 2007