Programação Orientada a Testes

Programação Orientada a
Testes
André Luiz Forchesatto

Ementário
● Compreender as técnicas para teste de
software através da utilização de
ferramentas de testes automatizados.
Avaliação de qualidade do código e
cobertura de testes utilizando ferramentas
automatizadas.

Testes de Software
● A atividade de teste é o processo de
executar um programa com a intenção de
descobrir um erro
● Um bom caso de teste é aquele que tem
uma elevada probabilidade de revelar um
erro ainda não descoberto
● Um teste bem-sucedido é aquele que revela
um erro ainda não descoberto.

Testes de Software
● Se erros facilmente corrigíveis forem
encontrados a qualidade e a confiabilidade
do software estão aceitáveis ou os testes
são inadequados para revelar erros graves
● Se não for encontrado erro a configuração
de teste não foi suficientemente elaborada e
erros estão escondidos no software

Testes de Software
● Projetar testes que descubram
sistematicamente diferentes classes de
erros e façam-no com uma quantidade de
tempo e esforço mínimos.
● Se erros graves forem encontrados com
regularidade a qualidade e a confiabilidade
de software são suspeitas.

Etapas para atividade de testes
Fonte: http://pt.slideshare.net/FabricioFFC/introduo-ao-teste-de-software-uma-abordagem-prtica

O que Testar?
● Normal ISO/IEC 9126/1991 ou NBR 13596

Dependerá do tipo de software

Projeto de casos de teste
Métodos de Projeto de Casos de Teste oferecem uma
abordagem sistemática ao teste e um mecanismo que
ajuda a garantir a mais alta probabilidade de revelar erros
no software com uma quantidade mínima de tempo e
esforço. Utilizado para códigos já existentes.
ABORDAGENS de TESTE:
1. Teste de Caixa Preta
2. Teste de Caixa Branca

Teste Caixa Preta
● Refere-se aos testes que são realizados nas interfaces
do software.
● São usados para demonstrar que as funções dos
softwares são operacionais, que a entrada é
adequadamente aceita e a saída é corretamente
produzida;
● Verifica se a integridade das informações externas é
mantida
● Examina aspectos do sistema sem se preocupar
muito com a estrutura lógica interna do software.

Teste Caixa Preta
● Concentram-se nos requisitos funcionais do
software.
1) funções incorretas ou ausentes
2) erros de interface
3) erros nas estruturas de dados ou no acesso a
bancos de dados externos
4) erros de desempenho
5) erros de inicialização e término

Teste Caixa Branca
● Baseia-se num minucioso exame dos detalhes
procedimentais
● "Status do programa" pode ser examinado em vários
pontos para determinar se o status esperado ou
estabelecido corresponde ao status real
● São testados os caminhos lógicos através do software,
fornecendo-se casos de teste que põem à prova
conjuntos específicos de condições e/ou laços

Teste Caixa Branca
● Um teste de Caixa Branca efetuado de forma muito
cuidadosa levaria a "100% de programas corretos" ?
● Testes exaustivos apresentam certos problemas
logísticos. Mesmo para pequenos programas, o número
de caminhos lógicos possíveis pode ser muito grande.
● É um método de projeto de casos de teste que usa a
estrutura de controle do projeto procedimental para
derivar casos de teste.

Teste Caixa Branca
● Podem ser derivados casos de teste que:
○ garantam que todos os caminhos independentes
dentro de um módulo tenham sido exercitados pelo
menos uma vez.
○ exercitem todas as decisões lógicas para valores
falsos ou verdadeiros.
○ executem todos os laços em suas fronteiras e
dentro de seus limites operacionais.
○ exercitem as estruturas de dados internas para
garantir a sua validade.

Teste Caixa Branca
● Teste de Caminho Básico:
○ O método de caminho básico possibilita que o
projetista do caso de teste derive uma medida de
complexidade lógica de um projeto procedimental e
use essa medida como guia para definir um
conjunto básico de caminhos de execução.
○ GRAFO DE FLUXO ou GRAFO DE PROGRAMA:
uma notação para representar o fluxo de controle.
Cada construção estruturada tem um símbolo de
grafo correspondente.

Teste Caixa Branca
● Caminho Independente:
○ Qualquer caminho através do programa que
introduza pelo menos um novo conjunto de
instruções de processamento ou uma nova
condição.

21
Conjunto Básico
Caminho 1: 1-11
Caminho 2: 1-2-3-4-5-10-1-11
Caminho 3: 1-2-3-6-8-9-10-1-11
Caminho 4: 1-2-3-6-7-9-10-1-11
Teste Caixa Branca

22
● Complexidade Ciclomática
○ É uma métrica de software que proporciona uma
medida quantitativa da complexidade lógica de um
programa.
○ Define o número de caminhos independentes do
conjunto básico de um programa e oferece um
limite máximo para o número de testes que deve
ser realizado para garantir que todas as
instruções sejam executadas pelo menos uma
vez.
Teste de Caixa Branca
Teste de Caminho Básico

23
● Complexidade Ciclomática
○ É computada numa das 3 formas seguintes:
1. o número de regiões do gráfico de fluxo
2. V(G) = E-N+2, onde E é o número de ramos do
grafo e N o número de nós do grafo de fluxo G
3. V(G) = P+1, onde P é o número de nós
predicativos (nós que contém uma condição)
contidos no grafo de fluxo G

24
Complexidade Ciclomática
O grafo de fluxo tem 4 regiões
V(G) = 11 ramos - 9 nós + 2 = 4
V(G) = 3 nós predicativos + 1 = 4
do grafo de fluxo é 4.
Grafo de Fluxo
região1
região2
região3
região4
Ramos
Nós

25
O valor de V(G) oferece um limite máximo no
número de testes que deve ser projetado e
executado para garantir a cobertura de todas as
instruções de programa.

26
Derivando Caso de Testes - Passos do
Método
1. Usando o projeto ou o código como base trace
um grafo de fluxo correspondente

4
8
1,2
3
7 5,6
9
10
Procedimento MAIOR(A:VETOR; T:inteiro;
var MAX:inteiro);
variáveis I,M:inteiro
Inicio
1 M<- A[1];
2 I<-2;
3 enquanto I < T faça
4 se A[I] > M
5 então M<- A[I]
6 I<- I+1
7 senão I<- I+1
8 fim se
9 fim enquanto
10 MAX<-M;
fim do procedimento

28
Método
2. Determine a Complexidade Ciclomática do
grafo de fluxo resultante

29
1. O grafo de fluxo tem 3 regiões
2. V(G) = 9 ramos - 8 nós + 2 = 3
3. V(G) = 2 nós predicativos + 1 = 3
A Complexidade Ciclomática é 3.
4
8
1,2
3
7 5,6
9
10
R2
R1
R3

30
Derivando Caso de Testes - Passos do Método
3. Determine um conjunto básico de caminhos
linearmente independentes (3 caminhos)

31
Caminhos
Caminho 1: 1, 2, 3, 9, 10
Caminho 2: 1, 2, 3, 4, 5, 6, 8, 3, 9, 10
Caminho 3: 1, 2, 3, 4, 7, 8, 3, 9, 104
8
1,2
3
7 5,6
9
10
R2
R1
R3

32
Método
4. Prepare os casos de teste que forcem a
execução de cada caminho no conjunto
básico.

Caminhos
Caminho 1: 1, 2, 3, 9, 10
A=(1,3) T=0
Resultado Esperado => Max=1
Caminho 2: 1, 2, 3, 4, 5, 6, 8, 3, 9,10
A=(1,3) T=3
Caminho 3: 1, 2, 3, 4, 7, 8, 3, 9, 10
A=(3,1) T=3
Procedimento MAIOR(A:VETOR; T:inteiro;
var MAX:inteiro);
variáveis I,M:inteiro
Inicio
1 M<- A[1];
2 I<-2;
3 enquanto I < T faça
4 se A[I] > M
5 então M<- A[I]
6 I<- I+1
7 senão I<- I+1
8 fim se
9 fim enquanto
10 MAX<-M;
fim do procedimento

Ferramenta: EclEmma
● http://www.eclemma.org/
● Plug-in do eclipse para métricas de teste,
cobertura e complexidade.
● Pode ser instalado pelo Eclipse MarketPlace

Ferramenta: EclEmma

Estratégias de Testes
● Teste de Unidade: É a verificação de um módulo único
de programa isolado dos outros módulos.
● Teste de Integração: É a verificação das interfaces
(comunicações) entre os módulos do sistema.
● Teste de Validação: É a verificação das funções do
sistema conforme o que consta na sua especificação
(requisitos do software).
● Teste de Sistema: É a verificação das funções do
sistema no ambiente real, integrado com outros
sistemas, conforme a definição do(s) usuário(s).

Ferramentas e frameworks para
testes
Ferramenta Finalidade
JUnit, Hamcrest Teste unitário, automatiza a criação básica dos
testes.
Selenium Testes de aceitação, simula o comportamento do
usuário utilizando o sistema.
JMetter Teste de stress, simula uma quantidade de usuário
para o sistema.
Mockito Testes unitário, auxiliar na hora de isolar rotinas
que não devem ser testadas.
DBunit Teste de integração, popula bases de dados com
informações de exemplo.
Spring-test Teste de integração, auxiliar a construção dos
testes que dependem do framework.
SonarQube Ferramenta de análise de qualidade de código e
cobertura de testes
Jenkins Ferramenta para integração continua.

JUnit
● Junit é um framework que facilita o desenvolvimento e
execução de testes
○ API para construção dos testes
○ Plugin e ferramentas para execução e visualização
dos resultados
● API
○ Métodos: assertTrue(), assertEquals(), fail() entre
outros, são responsáveis por verificar os resultados
do teste
● Donwload
○ www.junit.org

Para que serve?
● 'Padrão' para testes de unidade em Java
○ Desenvolvido por Kent Beck (o guru do XP) e Erich
Gamma (o G do GoF "Design Patterns")
○ Testar é bom mas é chato; JUnit torna as coisas
mais agradáveis, facilitando
■ A criação e execução automática de testes
■ A apresentação dos resultados
● JUnit pode verificar se cada método de uma classe
funciona da forma esperada
○ Permite agrupar e rodar vários testes ao mesmo
tempo
○ Na falha, mostra a causa em cada teste

Como utilizar
● Criar uma classe de Test em seu projeto,
e anotar os métodos com @Test
import org.junit.Test;
import static org.junit.Assert.*;
public class AppTest{
@Test
public void testSoma(){
App ap = new App();
assertEquals(new Float(10), ap.soma(5f, 5f));
}
}

Como utilizar
...
private Float valor1;
private Float valor2;
@Before
public void setUp(){
valor1 = 5f;
valor2 = 5f;
}
@After
public void tearDown(){
//Libera recursos
}
...
Antes de iniciar cada
método de teste
Após execução de cada
método de teste

Algumas checagens
● assertEquals
● assertArrayEquals
● fail
● assertFalse
● assertTrue
● assertNull
● assertNotNull
● assertThat

Uso das checagens
Valor Esperado Valor Obtido

Hamcrest
● Frameworks que melhora a legibilidade dos
testes.
● Simplifica a criação dos Asserts
● Retorna mensagens de falha mais legíveis
● https://code.google.com/p/hamcrest/wiki/Tutorial

Hamcrest
fonte: http://blog.caelum.com.br/melhorando-a-legibilidade-dos-seus-testes-com-o-hamcrest/

Hamcrest - Matches
● Collections
○ array
○ hasEntry, hasKey, hasValue
○ hasItem, hasItems
○ hasItemInArray
● Object
○ equalTo
○ hasToString
○ instanceOf, isCompatibleType
○ notNullValue, nullValue

Hamcrest - Matches
● Number
○ closeTo
○ greaterThan, greaterThanOrEqualTo, lessThan,
lessThanOrEqualTo
● Text
○ equalToIgnoringCase
○ equalToIgnoringWhiteSpace
○ containsString
○ endsWith
○ startsWith

Hamcrest - Matches
● Core
○ anything
○ describedAs
○ is
● Logical
○ allOf
○ anyOf
○ not

Hamcrest - Matches
● Matcher Personalizado:
○ Devemos extender de TypeSafeMatcher e
passar o tipo do objeto a ser avaliado
○ Depois implementar os métodos:
■ void describeTo(Description desc)
■ boolean matchesSafely(T objeto)

Hamcrest - Matches
fonte: http://blog.caelum.com.br/melhorando-a-legibilidade-dos-seus-testes-com-o-hamcrest/

Prática
Criar projetos para exercitar os testes

TDD
● Test-Driven Development
● Desenvolvimento guiado pelos Testes
● Publicado pela primeira vez no livro TDD: By
Example por Kent Beck em 2002
● Uma das técnicas para receber feedback
rápido

TDD - Vantagens
● Foco no teste e não na implementação
● Código nasce testado
● Simplicidade
● Melhor reflexão sobre o designer da classe

Prática
Fazer exercício sugerido no livro
Test-Driven Development da casa do código,
página 21 capítulo 3.

Mock
● Objetos Dublês, ou objetos "falso"
● Simulam o comportamento das
dependências

Mock
● Frameworks:
○ Mockito
○ jmockit
○ EasyMock
○ JMock
○ MockCreator
○ MockLib
○ HibernateMock

Mockito
● Framework open-source que auxilia na
construção de Mocks
● Possui uma API fluente de fácil
aprendizagem
● http://mockito.org/
● https://github.com/mockito/mockito

Mockito
● @Mock
● @RunWith(MockitoJUnitRunner.class)
● when
● thenReturn
● thenReturn
● verify
● doReturn(Object)
● doThrow(Throwable)
● doThrow(Class)
● doAnswer(Answer)
● doNothing()
● doCallRealMethod()
● spy

Prática
Mockar objetos com Mockito

Testes de integração
● São testes que avaliam toda infra-estrutura
do programa, desde a base de dados até os
sistemas integrados;
● Geralmente levam muito mais tempo para
serem executados;
● Frameworks úteis:
○ DBUnit
○ Spring-test

Spring-boot-test
● Simplifica o start dos testes de integração
que dependem do contexto do Spring
● Já traz os frameworks Spring Test, JUnit,
Hamcrest and Mockito com dependência
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>

Spring - Teste Integração web
● Simplifica através do MockMVC a
comunicação com o Controller, simulando
um requisição HTTP real.

Spring - Teste Integração web
● Simplifica a construção do teste, através de
uma interface fluente

Prática
Criar testes para aplicação web

DbUnit Teste Integração BD
● Framework para automatizar carga de base
de dados
● Importa ou exporta dados para diferentes
SGDB
● Se integra ao Spring
● http://dbunit.sourceforge.net/
● http://springtestdbunit.github.io/spring-test-dbunit/

DbUnit Teste Integração BD
● Dependências
<dependency>
<groupId>com.github.springtestdbunit</groupId>
<artifactId>spring-test-dbunit</artifactId>
<version>1.1.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.dbunit</groupId>
<artifactId>dbunit</artifactId>
<scope>test</scope>
</dependency>

Spring-test + DBUnit
● Utiliza o mesmo dataSource que o Spring
cria;
● Integração com o sistema de Transação e
Listeners do Spring;
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
@TestExecutionListeners({
DependencyInjectionTestExecutionListener.class,
DirtiesContextTestExecutionListener.class,
TransactionalTestExecutionListener.class,
DbUnitTestExecutionListener.class })

Spring-test + DBUnit
● @DatabaseSetup("sampleData.xml")
○ Inicializa a base de dados
● @DatabaseTearDown
○ Reseta a base de dados
● @ExpectedDatabase("expectedData.xml")
○ Resultado esperado após insert, update, delete

DBUnit - sample.xml
<dataset>
<tabela1 coluna1="valorcoluna1" coluna2="valorcoluna2"/>
<tabela1 coluna1="valor2coluna1" coluna2="valor2coluna2"/>
<tabela1 coluna1="valor3coluna1" coluna2="valor3coluna2"/>
</dataset>

Prática
Utilizar o DBUnit para popular uma base para
testes.

Testes de aceitação - Selenium
● Conjunto de softwares diferentes para
automatização de testes para web;
● Automatização do teste realizado pelo
usuário;
● Avaliação com base nas tags HTML geradas
pelo sistema;

Selenium
fonte: http://pt.slideshare.net/hugs/selenium2mobilewebtesting

Vantagens Selenium
● Testes de regressão freqüente
● Feedback rápido para os desenvolvedores
● Iterações virtualmente ilimitado de execução do
caso de teste
● Disciplinado documentação de casos de teste
● Relatórios defeito personalizado
● Encontrar defeitos perdidos por testes manuais

WebDriver
● É uma API orientada a objetos que facilita a
construção de testes para páginas web;
● Provê comandos para navegar em páginas
web, localizar e manipular elementos html.
http://docs.seleniumhq.org/docs/03_webdriver.jsp
Tutorial com lista de comandos: http://www.devmedia.com.br/introducao-aos-
testes-funcionais-automatizados-com-junit-e-selenium-webdriver/28037

Comandos Comum
● get()
● findElement()
● click()
● submit()
● sendKeys()
● isDisplayed()

Localização de elementos
● class
● css seletor
● id
● xPath

Selenium - Download
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
</dependency>

Prática
Criar sistema web e testes com Selenium.

Programação Orientada a Testes

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Programação Orientada a Testes

Similaire à Programação Orientada a Testes (20)

Plus de André Luiz Forchesatto

Plus de André Luiz Forchesatto (13)

Programação Orientada a Testes