Minicurso ministrado na XII SemanaTI na UNIVEM - Marília/SP, nos dias 23 e 24 de setembro de 2019. O título do minicurso é Técnicas de Teste e Automatização do Teste de Unidade e o minicurso tratava na teoria sobre algumas técnicas de Teste de Software, bem como a Técnica de Teste Estrutural, Teste Funcional e Teste Baseado em Defeitos, assim como aprendemos sobre a fase do Teste de Unidade, e ali, aplicamos na prática a Técnica de Teste Estrutural e tratamos sobre a teoria e a prática da automação de testes.

1. Técnicas de Teste e
Automatização do Teste de
Unidade
Claudinei Brito Junior
XII Semana TI
21 à 28 de Setembro de 2019

2. Mestrando em Ciência da Computação - ICMC/USP - 2018 / ---
Orientador: Márcio Eduardo Delamaro
Projeto: Uma abordagem para localização de mutantes
minimais baseada na estrutura do código fonte
Bacharel em Ciência da Computação - UNIVEM - 2014 / 2017
Orientador: Maurício Duarte
TCC: Learning 2 Program - Implementação de um interpretador
de algoritmos na linguagem C que irá auxiliar no processo de
aprendizado de programação
Dataplace Business Solution - 2014 / 2018
Suporte técnico (1 ano e 11 meses) | Analista de Teste /
Treinamento e Capacitação (1 ano e 8 meses) |
Desenvolvimento (5 meses)
Claudinei Brito Junior - 22 anos
Claudineibjr.github.io
claudineibjr@hotmail.com
2

3. Repositório
http://tiny.cc/MinicursoUNIVEM
▰ Slides *tem spoiler
▰ Documentação
▰ Binário dos programas utilizados na prática
▰ Código-fonte dos programas utilizados na prática
▰ Páginas HTML referente à sessão de cobertura
▰ Conjunto de casos de teste ideias *tem spoiler
3

4. Agenda
1. Introdução
▰ Teste de Software
▰ Objetivos do Teste de
Software
▰ Nomenclatura utilizada
2. Fases da Atividade de
Teste
▰ Teste de Unidade
▰ Teste de Integração
▰ Teste de Sistemas
▰ Teste de Regressão
4
3. Automatização do
Teste de Unidade
▰ Definições
▰ Ferramentas
▰ Prática
4. Técnicas de Teste
▰ Teste Funcional
▰ Teste Estrutural
▰ Teste Baseado em
Defeitos
5. Aplicando Teste de
Cobertura
▰ Definições
▰ Ferramentas
▰ Prática

5. Guia para o minicuso
▰ O que você vai aprender de teoria: As técnicas e critérios de teste mais
utilizadas.
▰ O que você vai aprender de prático: Desenvolver casos de teste para
identificar defeitos, desenvolver casos de teste para cobrir as instruções
de uma classe.
▰ O que você não vai aprender: Programar.
▰ O que é bom você saber: O básico sobre programação em Java, o básico
sobre orientação a objetos e o básico sobre como analisar um código.
Saber analisar a documentação (JavaDoc) de um programa
▰ O que você precisa saber: ---
▰ As ferramentas que vamos utilizar: Eclipse, Java, Eclemma/Jacoco*,
JUnit 4*
5

6. Introdução
6
1
▰ Teste de Software
▰ Objetivos do Teste de
Software
▰ Nomenclatura utilizada

7. Teste de Software
Teste de Software é uma atividade dinâmica, onde
executa-se o programa ou modelo utilizando algumas
entradas em particular e verifica-se se seu
comportamento está de acordo com o esperado.
7

8. Objetivos do Teste de Software
Para programas reais, é praticamente IMPOSSÍVEL provar
que este software não tem defeitos.
O objetivo do Teste de Software é provar que existem
defeitos.
8

9. Nomenclatura
▰ Defeito (Fault): Um passo, processo ou uma definição de dados incorretos
em um programa de computador;
▰ Engano (Mistake): Uma ação humana que produz um defeito;
▰ Erro (Error): A diferença entre o valor obtido e o esperado, isto é, algum
comportamento inesperado do programa de computador;
▰ Falha (Failure): A incapacidade do sistema de produzir resultados que
condizem com suas especificações. 9

10. Nomenclatura - Exemplo
O Claudinei cometeu um engano e inverteu os operandos na
função de divisão, o que acabou introduzindo um defeito no
software, fazendo com que o sistema tivesse um erro, tal
qual pode levar a uma falha caso a operação aritmética
selecionada seja a divisão.
O teste busca por DEFEITOS 10

11. Nomenclatura
▰ Domínio de entrada: Conjunto de todos os possíveis valores
que podem ser utilizados para executar um dado programa.
▰ Domínio de saída: Conjunto de todos os possíveis resultados
produzidos pelo programa.
11

12. Nomenclatura - Exemplo
O domínio de entrada de um programa que devolve a
situação de aprovação do aluno com base em sua nota, são
todos os números ponto flutuantes possíveis, enquanto o
domínio de saída é um texto com a situação de aprovação
daquele aluno, podendo ser “Entrada inválida”, “Reprovado”,
“Exame” ou “Aprovado”.
12

13. Nomenclatura
▰ Dado de teste: Elemento do domínio de entrada do programa
▰ Caso de teste: Par formado por um dado de teste e o
resultado esperado (pertencente ao domínio de saída) para a
execução do programa com aquele dado de teste
▰ Oráculo: Mecanismo que permite identificar se a saída
produzida pelo programa está correta ou não.
13

14. Nomenclatura - Exemplo
Um dado de teste para um programa que devolve a situação
de aprovação do aluno com base em sua nota, é a nota de
um aluno, podendo ser 10, e um caso de teste para aquele
programa, é a nota de um aluno, podendo ser 10 e a situação
de aprovação correspondente àquela nota, no caso,
“Aprovado”. O oráculo pode ser o testador que vai observar
o resultado do programa ou um sistema automatizado.
14

15. Fases da Atividade de
Teste
15
2
▰ Teste de Unidade
▰ Teste de Integração
▰ Teste de Sistemas
▰ Teste de Regressão

16. Fases do Teste de Software
O Teste de Software deve ocorrer durante todo o ciclo de
desenvolvimento do software e inclusive, após o
desenvolvimento, durante a manutenção do Software.
16

17. Fases do Teste de Software
▰ Teste de unidade
▰ Teste de integração
▰ Teste de sistemas
▰ Teste de regressão
17

18. Teste de Unidade
▰ Unidades mínimas de um programa (funções, procedimentos,
métodos ou classes)
▰ Erros na escolha ou na implementação de algoritmos
▰ Enganos na entrada ou saída de métodos
▰ Erros sintáticos ou semânticos
▰ Pode ser realizado antes do desenvolvimento do Software
18

19. Teste de Integração
▰ Construção arquitetural do sistema
▰ Erros podem ser revelados na conexão das unidades
▰ O responsável deve conhecer toda a estrutura do sistema
19

20. Teste de Sistemas
▰ Verifica as funcionalidades requeridas estão corretamente
implementadas
▰ Requisitos não funcionais: segurança, performance, robustez, etc.
▰ Inclui o teste de aceitação. O usuário é responsável por utilizar o
software em seu ambiente real.
20

21. Teste de Regressão
▰ É executado sempre durante a manutenção do software
▰ Identificar possíveis falhas que podem ter sido introduzidas
durante o desenvolvimento de novas funcionalidades
21

22. Automatização do
Teste de Unidade
22
3
▰ Definições
▰ Ferramentas
▰ Prática

23. Objetivo
▰ O objetivo da automatização de teste é permitir que a maior
quantidade de testes seja realizada em menor tempo.
▰ Atividades intelectuais: testadores.
▰ Atividades repetitivas: framework informatizado.
23

24. Vantagens e desvantagens
Vantagens
▰ Economizar tempo
▰ Eliminação de tarefas
repetitivas
24
Desvantagens
▰ Tempo dispendido na seleção
de casos de teste
▰ Programação

25. Ferramentas
▰ Java: JUnit
▰ .NET: NUnit
▰ Python: Unit Testing Framework
https://en.wikipedia.org/wiki/List_of_unit_testing_frameworks
25

26. JUnit
26
Passo a passo para criação de um caso de teste
▰ Instanciar o objeto da classe cujos métodos se deseja testar
▰ Invocar o método em teste com a entrada desejada e armazenar o
resultado de sua execução
▰ Utilizar um dos métodos de assertivas oferecidos pelo JUnit, disponíveis
na classe org.junit.Assert, para comparar o resultado esperado com o
resultado obtido

27. JUnit
27
File >>
New >>
Junit Test Case

28. JUnit - Anotações e Assertivas
Anotações
▰ @Before
▰ @BeforeClass
▰ @After
▰ @AfterClass
▰ @Test
▰ @Ignore
▰ @Test(timeout=500)
▰ @Test(expected=IllegalArgumentEx
ception.class)
28
Assertivas
▰ assertArrayEquals
▰ assertEquals
▰ assertFalse
▰ assertNotNull
▰ assertNotSame
▰ assertNull
▰ assertSame
▰ assertThat
▰ assertTrue
▰ fail

29. JUnit
Caso de teste básico
▰ @Test
▰ Faz o papel de oráculo
29

30. JUnit
Definindo contextos
▰ @BeforeClass: executado só
uma vez, antes de iniciar os
testes
▰ @Before: executado uma vez
para cada caso de teste, antes
de cada caso de teste
30

31. JUnit
Definindo contextos
▰ @AfterClass: executado só
uma vez, depois de finalizar os
testes
▰ @After: executado uma vez
para cada caso de teste,
depois de cada caso de teste
31

32. JUnit
Testes temporizados
▰ @Test(timeout=?)
▰ Faz com que um teste, que por algum motivo entrou em loop infinito,
pare de ser executado no tempo estipulado (em milissegundos)
32

33. JUnit
Teste de exceções
▰ @Test(expected=NomeDaExcecao.class)
▰ Permite a execução de vários testes de uma vez
33

34. JUnit
Ignorando casos de teste
▰ @Ignore
34

35. JUnit
Conjunto de testes
▰ @RunWith
▰ @Suite
▰ Permite a execução de
vários testes de uma vez
35

36. JUnit
Quando o caso de teste falha!
36

37. JUnit
37

38. Exemplo para utilização
38
A função notaFinal recebe um número inteiro entre 0 e 10, que
corresponde à nota de um aluno. Como retorno, o programa
devolve o resultado final desse aluno, que é Reprovado caso a
nota seja menor que 5, Exame caso a nota seja maior ou igual a 5
e menor que 7 e Aprovado caso a nota seja maior que 7. Caso
alguma das notas digitadas seja inválida, a saída do programa
deve exibir Entrada inválida.

39. JUnit - Mãos à obra
39

40. 40
▰ Crie um projeto Java Project
▰ Clique com o botão direito sobre o nome do projeto
e vá em Build Path >> Configure Build Path >>
Libraries >> Add External JARs...
▰ Selecionar o arquivo .jar do repositório
Prática

41. Prática
Projetar casos de teste para as classes abaixo. Identifique
defeitos.
▻ Notas (1 e “oficial”)
▻ Calculator (1 e “oficial”)
▻ Identifier (1 e “oficial”) 41

42. 42
Notas
▰ Considerando 0 e 10 como entradas inválidas
Prática - Bugs identificados

43. 43
Calculator
▰ Não faz prioridade de operadores (*, /)
▰ Não eram lançadas exceções em operações indevidas
(divisão por 0, mais operadores que o necessário, mais
operandos que o necessário, operação vazia)
Prática - Bugs identificados

44. 44
Identifier
▰ Não permitia identificadores com 6 caracteres
▰ Lançava exceção indevida quando passava um identificador
nulo ao invés de retornar falso
▰ Lançava exceção indevida quando passava um identificador
em branco ao invés de retornar falso
Prática - Bugs identificados

45. Técnicas de Teste
45
4
▰ Teste Funcional
▰ Teste Estrutural
▰ Teste Baseado em Defeitos

46. Técnicas e critérios de Teste
▰ O que difere uma técnica da outra é a informação utilizada
para guiar a atividade de teste, podendo ser:
▻ Código-fonte
▻ Estrutura do código-fonte
▻ Defeitos típicos
▻ Especificação de requisitos
▻ Modelo formal
46

47. Exemplo para utilização
47
O programa recebe um número inteiro entre 0 e 10, que
corresponde à nota de um aluno. Como retorno, o programa
devolve o resultado final desse aluno, que é Reprovado caso a
nota seja menor que 5, Exame caso a nota seja maior ou igual
à 5 e menor que 7 e Aprovado caso a nota seja maior que 7.
Caso alguma das notas digitadas seja inválida, a saída do
programa deve exibir Entrada inválida

48. Teste Funcional
Teste de caixa preta
▰ Avalia o software do ponto de vista do usuário
▰ Visão externa, sem conhecimento da estrutura interna
▰ É possível identificar todos os possíveis defeitos através do teste
exaustivo, expondo o software à todas as possíveis entradas,
porém, é infactível
48

49. Teste Funcional
Particionamento em classes de equivalência
49
▰ Seleciona e agrupa as
entradas que de acordo
com as especificações do
programa, tem
comportamento iguais.
Entrada Saída
< 0 ou > 10 Entrada inválida
>= 0 e < 5 Reprovado
>= 5 e < 7 Exame
>= 7 e <= 10 Aprovado

50. Teste Funcional
Análise do valor limite
50
▰ Busca explorar os valores
que estão exatamente
sobre ou imediatamente
subsequentes às
fronteiras das classes de
equivalência
Entrada Saída
-1, 11 Entrada inválida
0, 4 Reprovado
5, 6 Exame
7, 10 Aprovado

51. Teste Funcional
Grafo causa-efeito
51
▰ Explora as combinações dos dados de entrada.
▰ Linguagem formal, grafo

52. Teste Funcional
Error guessing
52
▰ Abordagem ad-hoc
▰ Casos de teste criados a partir de experiências e
intuições

53. Teste Baseado em Defeitos
▰ Consiste na introdução de defeitos típicos, criando mutantes
▰ Os mutantes são diferentes do programa original, sendo assim, os
casos de teste devem revelar essas diferenças
▰ Mede a qualidade do conjunto de casos de teste. Mede o quanto
aquele conjunto de de casos de teste é bom em revelar defeitos.
53

54. Teste Estrutural
Teste de caixa branca
▰ Define os requisitos de teste baseados na implementação do
software
▰ Leva em consideração o conhecimento da estrutura interna
do programa
▰ Mede a qualidade do conjunto de casos de teste. Mede o
quanto aquele conjunto de de casos de teste cobrem o
programa.
54

55. Teste Estrutural
Grafo de fluxo de controle
55
▰ Abstração da codificação do programa
▰ Grafo = (E, N, S)
▻ E é o conjunto de vértices
▻ N é o conjunto de arestas
▻ S é o vértice inicial

56. Teste Estrutural
Grafo de fluxo de controle
56

57. Teste Estrutural
Critérios baseados em complexidade
57
▰ Criam os requisitos de teste com base nas
informações sobre a complexidade ciclomática do
programa

58. Teste Estrutural
Critérios baseados em fluxo de dados
58
▰ Derivam os casos de teste a partir das relações que
tratam das definições de variáveis e as posteriores
referências a essas definições
▰ Critérios de Rapps e Weyuker
▰ Critérios Potenciais-usos

59. Teste Estrutural
Critérios baseados em fluxo de controle
59
▰ Utilizam características inerentes à execução do
programa. Desvios e comandos como determinantes
na decisão de quais organizações são necessárias.
▰ Todos-nós
▰ Todas-arestas
▰ Todos-caminhos

60. Aplicando Teste de
Cobertura
60
5
▰ Definições
▰ Ferramentas
▰ Prática

61. Definições
Desvios
Instruções 61

62. Ferramentas
▰ Eclemma/Jacoco: Java
62

63. Teste Estrutural - Mãos à obra
Ao rodar os
casos de teste
63

64. Teste Estrutural - Mãos à obra
Resultado
Todas as
instruções
e todos os
desvios
foram
cobertos
64

65. Teste Estrutural - Mãos à obra
Ao rodar os
casos de teste
ignorando 3
casos de teste
65

66. Teste Estrutural - Mãos à obra
66
Resultado
Não é coberto o
desvio verdadeiro
notaFinal > 10
(test_8). Não é
coberto o desvio
verdadeiro notaFinal
< 7 (test_5). Não é
coberta a instrução
resultado = “Exame”
(test_4 e test_5)

67. 67
▰ Utilize o mesmo projeto criado anteriormente
▰ Descompacte o conteúdo do arquivo src.zip do
repositório na pasta src do seu projeto
▰ Atualize seu projeto (F5) no Eclipse
Prática

68. Prática
Projetar casos de teste para as classes abaixo. Cubra 100% de
instruções e 100% de desvios.
▻ Notas (“oficial”)
▻ Calculator (“oficial”)
▻ Identifier (“oficial”) 68

69. 69
▰ Para cada classe, visualizar os arquivos index.html
>> MiniCursoUnivem >> src >> {{classe}} >>
{{classe}}
Prática - Resultado esperado

70. Referências e Links úteis
▰ Guias para utilização da JUnit https://www.javaguides.net/p/junit-4.html
▰ PIT - Mutação https://github.com/pitest/pitclipse
▰ CFG Generator (Grafo de fluxo de controle) http://eclipsefcg.sourceforge.net/
70

71. Isso é tudo pessoal
MUITO OBRIGADO!
▰ Avalie o minicurso: https://bit.ly/2kvoOnO
*Isso não vai mudar em nada na SemanaTI, mas é importante para que eu melhore meus próximos
minicursos/treinamentos.
71

72. Técnicas de Teste e
Automatização do Teste de
Unidade
Claudinei Brito Junior
XII Semana TI
21 à 28 de Setembro de 2019