1) O documento apresenta um curso sobre testes automatizados de software, incluindo objetivos, metodologia, conteúdo e conceitos básicos de teste de software. 2) Serão abordados testes unitários, testes de integração, testes funcionais e testes de carga, além de técnicas como TestNG e Mockito. 3) O curso visa demonstrar tecnologias e boas práticas para a construção de testes automatizados, facilitando o desenvolvimento e melhoria dos processos de teste.

1. Curso de Testes Automatizados de Software
Unidade I
Introdução

2. Agenda
● Apresentação
● Objetivos
● Metodologia
● Pré-requisitos
● Conteúdo Pragmático
● Introdução a teste de software
● Introdução a automação de teste de software
● Básico sobre teste unitário

3. Apresentação
● Curso
● Testes Automatizados de Software - Introdução e
Desenvolvimento
● Realização
● SEPLAG
● Carga horária
● 16 horas
● Frequência
● 23/01, 24/01, 25/01 e 26/01 de 2012
● 08:00 as 12:00

4. Objetivo
● Demonstrar as tecnologias e boas praticas que
envolvem a construção de testes de software.
● Facilitar a construção e melhoramento dos
processos de testes de software
automatizados.

5. Metodologia
● O conteúdo da disciplina será desenvolvido por
meio de aulas expositivas, exercícios e
discussões em sala de aula.

6. Pré-requisitos
● Conhecimentos em Orientação a Objetos
● Conhecimentos em Java
● Ambiente de desenvolvimento instalado
(Eclipse 3.x, Jboss Tools 3.x e Maven 2)

7. Conteúdo Pragmático
● Unidade I
● Introdução a teste de software
● Introdução a automação de teste de software
● Básico sobre teste unitário
● Unidade II
● Técnicas de Teste Unitários
● TestNG
● Mockito
● Unidade III
● Testando com Banco de Dados
● DBUnit
● Testes Funcionais
● Selenium
● Unidade IV
● Princípios e Filosofia de Testes Automatizados
● Introdução ao TDD

8. Algumas Duvidas
● Testes de Software?
● Testes Automatizados?
● Por que testar?
● Quando preciso testar?
● Como testar?

9. Teste de Software
● Definições
● É uma investigação conduzida para fornecer os
interessados informações sobre a qualidade do produto
ou serviço em teste.
● Também pode fornecer uma visão objetiva,
independente do software para permitir identificar e
compreender os riscos na implementação do software.
● 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

10. Quando preciso testar?
● Teste de software, dependendo do método teste empregado
pode ser implementados a qualquer momento no processo
de desenvolvimento.
● Entretanto, a maioria do esforço de teste ocorre depois que
as exigências foram definidas e o processo de codificação foi
concluído. Como tal, a metodologia do teste é regido pela
metodologia de desenvolvimento de software adotado.
● Diferentes modelos de desenvolvimento focalizam o esforço
de teste, em diferentes pontos no processo de
desenvolvimento.

11. Visão geral
● Teste nunca pode identificar completamente todos os
defeitos no software
● Em vez disso, ele fornece uma crítica ou comparação que
compara o estado e o comportamento do produto contra
princípios ou mecanismos pelos quais alguém pode
reconhecer um problema.
● Ex.: Especificações, contratos, versões anteriores, produtos ou
expectativa do usuário
● Um estudo realizado pelo NIST em 2002 relata que os bugs
de software custaram a economia dos EUA, 59,5 bilhões
dólares anualmente. Mais de um terço desse custo poderia
ser evitado se um melhor teste de software foi realizado

12. Conceitos importantes
● Escopo
● Funcional vs Não-Funcional
● Bug e Falha
● Combinações de entradas e pré-condições
● Verificação e Validação
● Garantia de Qualidade de Software (SQA)

13. Escopo
● "Os testes podem apenas mostrar a presença de erros, não sua
ausência", Dijkstra, et al. 1972
● 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 condições específicas.
● O escopo dos testes de software, muitas vezes inclui o exame de
código, bem como a execução desse código em vários
ambientes e condições.

14. Funcional vs Não-Funcional
● Teste funcional
● Refere-se a atividades que verificar uma ação
específica ou função do código.
● Não-funcionais
● Refere-se a aspectos do software que não pode
estar relacionada a uma função específica ou ação
do usuário, tais como escalabilidade, desempenho,
comportamento sob certas restrições, ou de
segurança.

15. Bug e Falha
● Geralmente o processo de falhas de software
segue o seguinte:
● Um programador faz um erro, o que resulta em um
bug no software de código-fonte . Se este defeito é
executado, em certas situações o sistema irá
produzir resultados errados, causando uma falha .
Erro → Bug → Falha
● Mas, nem todos os defeitos de software são
causados por erros de codificação.

16. Combinações e Pré-condições
● Um problema fundamental com teste de software é que
os testes com todas as combinações e pré-condições
(estado inicial) não é viável, mesmo com um simples
produto.
● Isto significa que o número de defeitos em um produto
de software pode ser muito grande e defeitos que
ocorrem com pouca frequência são difíceis de
encontrar.
● Mais significativamente os que envolvem requisitos
não-funcionais: usabilidade , escalabilidade ,
desempenho , compatibilidade , confiabilidade.

17. Verificação e Validação
● Verificação
● “Estamos construindo o produto corretamente?”
● O software está de acordo com suas
especificações
● Validação
● “Estamos construindo o produto corretamente?”
● O sistema atende às expectativas do usuário
● As especificações nem sempre estão de
acordo com as expectativas dos usuários.

18. Garantia de Qualidade de Software
(SQA)
● Teste de software é uma tarefa destinada a
detectar defeitos de software.
● QA (Garantia de qualidade) é implementação
de políticas e procedimentos destinados a
prevenir a ocorrência de defeitos em primeiro
lugar.
● Teste de software faz parte do processo de
SQA.

19. Tipos de Testes de Software
● Testes de Componente
● Testes de Unidade
● Testes de Sistema
● Testes de Integração
● Testes Funcionais
● Testes de Carga
● Testes de Aceitação
● Testes do cliente

20. Processos de Testes
● Tradicional CMMI ou Modelo Waterfall
● Comumente os testes são realizados por um grupo
independente de testadores após o
desenvolvimento da funcionalidade.
● Agile ou Extreme Programing
● Nestes processos geralmente adotam o TDD (Test
Driving Development) onde os testes unitários são
escritos e primeiro lugar.

21. Teste de Software
● Motivação
● Garantir software que funciona conforme
especificado e que atenda as expectativas do
usuário
● Ocorrência de falhas humanas no processo de
desenvolvimento é considerável
● Os custos na correção de falhas, justificam um
processo de testes cuidadoso e bem planejado

22. Teste de Software
● Finalidade
● Averiguar se todos os requisitos foram
corretamente implementados
● Assegurar qualidade e corretude do software
● Reduzir custos de manutenção corretiva e
retrabalho.

23. O que é Testar?
●Testar é a maneira de obter feedback do software. Por estão razão é
um elemento essencial no desenvolvimento “ágil” e “limpo”.

24. Visão Tradicional de Testes
● N° de Bugs determina a qualidade do software

25. Teste de Desenvolvedores
● Frist time, every time

26. Testes Automatizados

27. Testes Automatizados
● Todos buscam automatizar os testes
principalmente com objetivo de evitar
retrabalho e reduzir custos. Mas recentemente
a experiência de muitos Testadores e Gerente
de Testes com ferramentas de automação, os
deixaram menos que satisfeito. A causa é os
autos custos de Manutenção devido ao
problema de "Fragile Test".

28. Fragile Test
● Testes automatizados usando ferramentas
"recod and playback" ou "robot user", vem
ganhado uma reputação ruim pelos seu
primeiros usuários por não conhecerem suas
limitações, são elas:
● Sensibilidade de comportamento
● Sensibilidade de interface
● Sensibilidade de dados
● Sensibilidade de contexto

29. Sensibilidade de Comportamento
● Se determinada funcionalidade for alterado,
provavelmente todos os testes desta
funcionalidade iram falhar

30. Sensibilidade de interface
● Testar logica de negocio via usuário de
interface é uma má ideia!
● Mesmo pequenas mudanças na interface
podem fazer os testes falhar

31. Sensibilidade dos Dados
● Todo teste assume um estado inicial dos
dados, se e teste sofrem ao menos uma
pequena alteração, os testes podem falhar.
● Manter os testes imune as dados requer um
grade esforço.

32. Sensibilidade do Contexto
● O comportamento ou estado de coisas fora do
sistema, podem afetar o seu comportamento e
consequentemente ocasionar falha nos testes.

33. É Fato
● As quatro sensibilidades existem,
independentemente de qual tecnologia que
usamos para automatizar os testes. Claro,
algumas tecnologias podem nos dar maneiras
de contornar esses problema, enquanto outros
nos força para um caminho particular. A família
xUnit (Junit, TestNG, ...) nos dá um grande
grau de controle, só temos de aprender como
usá-lo efetivamente.

34. Automação de Testes
● Muito se fala sobre testes automatizados de
unidade e aceitação como parte do
desenvolvimento ágil de software
● Escrever bons testes de código é difícil, e
mantelos limpo e claro é mais difícil ainda.
● O Principal causa disso é o fato de ser opcional
( o cliente não paga por isso) e com o tempo os
teste vão sendo abandonados devido ao
aumento de complexidade e/ou custo de
manutenção.

35. Custos
● O custo de escrever e manter conjuntos de
testes tem sido um desafio particular.

36. Soluções
● Mas felizmente, muitas equipes tem
desenvolvido soluções que ajudam a enfrentar
esses desafios.

37. Economia com Automação de
Testes
● Evidente, que sempre há custos construção e manutenção de
uma suíte de testes.
● Nosso objetivo deve ser o de tomar a decisão de fazer a
automação de testes assegurando o não aumento nos custos
de desenvolvimento de software.
● Assim, o custo adicional de construção e manutenção de
testes automatizados devem ser compensados com a redução
na depuração/resolução de problemas diminuindo os custos
de remediação dos defeitos que possam ter passado
despercebidos até a fase de teste formal do projeto ou uso de
produção.
● A figura 1.0 mostra como o custo da automação é
compensado pelos benefícios recebidos.

38. Economia com Automação de
Testes
Figura 1.0 - Um projeto de teste unitários automatizado com um bom
retorno sobre o investimento. O custo-benefício quanto ao custo total é
reduzido por boas práticas de teste.

39. Economia com Automação de
Testes
● Devemos ressaltar que, se os testes são
difíceis de escrever, são difíceis de
compreender, e necessitam de manutenção
frequente, o custo total de desenvolvimento é
caro.
● E os benefícios podem não equilibrar o esforço
despendido para manter os testes
automatizados, a figura 1.1 demostra isso.

40. Economia com Automação de
Testes
Figura 1.1 Um projeto de teste unitário automatizado com um baixo
retorno do investmeno e custo-benefício quanto ao custo total é
aumentada por práticas de teste pobres.

41. Teste Automatizados
● Objetivos para atingir a economia esperada:
● Os testes devem nos ajudar a melhorar a
qualidade.
● Os testes devem nos ajudar a entender o SUT
(system under test).
● Os testes devem reduzir (e não introduzir) riscos.
● Os testes devem ser fáceis de executar.
● Os testes devem ser fáceis de escrever e manter.
● Os testes devem requerer o mínimo de
manutenção.

42. Os testes devem nos ajudar a
melhorar a qualidade.
● A razão tradicional para testarmos é garantir
qualidade (QA). Procuramos responder as
seguintes perguntas: O software é feito
corretamente? O software faz a coisa certa?
● Como:
● Testes como especificação
● Prevenir Bugs
● Localizar defeitos

43. Os testes devem nos ajudar a
entender o SUT
● Os teste podem mostrar como o código deve
funcionar.
● Como:
● Testes como documentação
– Sem testes automatizados temos que estudar o código
tetando responder à pergunta: “Qual deve ser o
resultado se …?”
– Se quisermos saber como o sistema faz alguma coisa,
só precisamos executar os teste especifico e depurar se
necessário

44. Os testes devem reduzir (e não
introduzir) riscos.
● Testes devem melhorar a qualidade do nosso software,
ajuda-nos a documentar melhor os requisitos e evitar
lentidão no desenvolvimento incremental. Esta é
certamente uma forma de redução de riscos.
● Outra forma de ajudar é verificar comportamento em
situações que não podem ser identificada nos testes de
caixa preta.
● Como:
● Testes como Rede de Segurança
● Não causar danos
– Mantenha a logica de produção fora do código de produção

45. Os testes devem ser fáceis de
executar
● O que torna fácil de executar testes? Quatro objetivos
específicos respondem a esta pergunta:
● Testes devem ser totalmente automatizado para que eles
possam ser executados sem qualquer esforço.
● Testes devem ser auto-verificáveis para que eles possam
detectar e relatar quaisquer erros sem inspeção manual.
● Testes devem ser repetíveis para que eles possam ser
executados várias vezes com o mesmo resultado.
● Idealmente, cada teste deve ser um teste independente que
pode ser executado por si só.
● O feedback deve está a um clique de distância

46. Os testes devem ser fáceis de
escrever e manter
● Testes de tornar-se complicada por duas razões:
● Tentamos verificar muitas funcionalidades em um único teste.
● Existem um “gap de expressividade” muito grande entre a
linguagem de testes (ex. Java) e as relações e conceitos do
domínio que estamos tentando expressar no teste.
● Como:
● Testes simples
– Uma condição para verificar por teste
● Testes expressivos
● Separação de interesses

47. Devem requerer o mínimo de
manutenção.
● A mudança é um fato da vida. E na verdade
escrevemos software para facilitar as
mudanças.
● Sistema evolui em torno dos testes
● Como:
● Testes robustos

48. Testes Automatizados – Metas
Projeto Construção de Testes
Testes como Especificação Total automatização
Testes como Documentação Alto verificação
Testes como Rede de Segurança Teste que se pode repetir
Localizador de Defeitos Tete Robusto
Fácil de escrever ou manter Teste Simples
Prover Qualidade Teste Expressivo
Reduzir risco Separação de interesses
Prevenir Bug Não cause danos

50. Básico de Testes Unitários
● Definindo Testes Unitários
● Explorando um simples exemplo
● Um pouco de TDD

51. Definição
● Testes Unitários não é um conceito novo em
desenvolvimento de software
● Kent Beck itroduzio o conceito de teste uninitario
em Samalltalk.
● Um teste de unidade é um pedaço de um código
(normalmente um método) que invoca uma outra
pedaço de código e verifica a veracidade de alguns
pressupostos pós-ala. Se os pressupostos vir a ser
errado, o teste de unidade falhou. A "unidade" é um
método ou função.

52. Definição
● A importância de escrever bons testes unitários
● Todos nos já escrevemos testes unitários

53. Definição
● Em testes clássicos, os
desenvolvedores usam
uma GUI (graphical user
interface) para
desencadear uma ação
sobre a classe que eles
querem para testar. Em
seguida, verificam os
resultados.

54. Propriedades de um “bom” teste
unitário
● Um teste unitário deve ter as seguintes
propriedades:
● Deve ser automatizados e repetíveis.
● Deve ser fácil de implementar.
● Uma vez que é escrito, ele deve permanecer para
uso futuro.
● Deve funcionar com o pressionar de um botão.
● Deve funcionar rapidamente.

55. Propriedades de um “bom” teste
unitário
● Muitas pessoas confundem ato de testar software com o conceito de teste
unitário Então pergunte a si mesmo sobre os testes que escreveu até agora:
● Posso executar e obter resultados de um teste de unidade que eu escrevi duas semanas
ou meses ou anos atrás?
● Qualquer membro de minha equipe pode executar e obter os resultados dos testes que
eu escrevi há dois meses?
● Posso executar todos os testes unitários que eu escrevi em não mais do que alguns
minutos?
● Posso executar todos os testes unitários que eu escrevi com um botão?
● Posso escrever um teste unitário básico em não mais do que alguns minutos?
● Se você respondeu “Não” a alguma das questões acima, provavelmente você
não está implementando testes unitários É algum outro tipo de teste tão
importante quanto os testes unitários

56. Diferenças
● Você pode perguntar, “O que eu estava
fazendo até agora?”. Provavelmente testes de
integração
● Exite uma grande duvida sobre a diferença de
testes unitários e testes de integração

57. Testes de Integração
● Teste de integração consiste em testar dois ou
mais módulos de softwares como um grupo.

58. Bom Teste Unitário
● A definição
● Um teste unitário é uma parte automatizada de
código que chama o método ou classe que está
sendo testado e, em seguida, verifica algumas
suposições sobre a lógica e comportamento desse
método ou classe. Um teste de unidade é quase
sempre escrito usando uma estrutura de testes
unitário Pode ser escrito de forma fácil e executa
rapidamente. É totalmente automatizado, confiável,
legível e de fácil manutenção.

59. Um teste unitário simples
● É possível escrever teste unitário automatizado
sem usar um framework de teste.

60. SUT

61. Classe de Teste

62. Executando o Teste

63. Melhorando um pouco

64. Melhorando um pouco

65. Primeiro teste unitário
● Frameworks de testes unitários (xUnit)
● Escrevendo o primeiro teste unitário com Junit
● Trabalhando com atributos do Junit
● Compreendendo o estado dos testes

66. Frameworks para testes unitários
● O frameworks de testes oferecem facilidades
semelhantes ao que as IDEs nós
proporcionam

67. Como os frameworks ajudam.
Pratica de teste unitário Como o framework ajuda
Escrever testes facilmente e Fornece ao desenvolvedor uma
de forma estruturada. biblioteca com:
• Classes ou interfaces para herdar.
• Atributos para colocar em seu código
para observar seus testes
para ser executado.
• Classes de acessão que possuem
métodos especiais que você invoca
para verificar seu código.
Execute um ou todos os testes - Quadro prevê um console ou Ferramenta GUI
que:
de unidade. • Identifica os testes em seu código.
• Executa testes automaticamente.
• Indica o estado durante a execução.
• Pode ser automatizada por linha de comando.

68. Como os frameworks ajudam.
Pratica de teste unitário Como o framework ajuda
Analisar os resultados do teste é Os consoles geralmente fornecem
executado. informações, tal como:
• quantos testes correu.
• quantos testes não foi executada.
• quantos testes falharam.
• quais testes falharam.
• os testes de razão, não.
• A mensagens de assert que você
escreveu
• o local de código que falhou.
• possivelmente um rastreamento de
pilha completa de todas as exceções
que fez com que o teste falhar.

69. xUnit
● CppUnit para C++
● JUnit para Java
● Nunit para .Net
● HUnit para Haskell
● …

70. Projeto LogAn
● Uma determinada empresa possui um vários
sistemas que geram logs num formato privado.
Estes logs devem ser lidos e determinados
comportamentos identificados e notificados aos
resposaveis.
● Para resolver este problema daremos inicio ao
projeto LogAn que começara bem simples.

71. Junit 4
● O JUnit (junit.org) é um framework muito simples para
facilitar a criação destes testes unitários e em especial
sua execução. Ele possui alguns métodos que tornam
seu código de teste bem legível e fácil de fazer as
asserções.
● Uma asserção é uma afirmação: alguma invariante que
em determinado ponto de execução você quer garantir
que é verdadeira. Se aquilo não for verdade, o teste deve
indicar uma falha, a ser reportada para o programador,
indicando um possível bug.
● Escrito originalmente por Kent Beck (Extreme
Programming) e Erich Gamma (Design Patterns)

72. Junit API
● Principais Anotações
● @Test – Marca uma classe ou metodo como sendo
parte de um teste.
● @BeforeClass – Executa um método antes da classe
iniciar
● @AfterClass – Executa um metodo depois da classe
iniciar
● @Before – Executa um método antes de qualquer
metodo de teste
● @After – Executa um método depois de qualquer
metodo de teste.

73. Junit API Resumida

74. Exercícios

76. Referências
● Osherove, Roy. The art of unit testing : with
examples in .NET. 2009
● Meszaros, Gerard. XUnit test patterns :
refactoring test code. 2007
● http://en.wikipedia.org/wiki/Software_testing