TESTE DE SOFTWARE - TEORIA

Propsito: Avaliar se o software

Cumpre os requisitos;
Responde corretamente s entradas;
Desempenha as funes em tempo aceitvel;
Possu boa usabilidade;
compatvel com o ambiente alvo;
Atinge os objetivos estabelecidos pelos stakeholders.
Tcnicas:

Testes estticos: Feitos sem que o programa seja rodado: Ex: reviso de cdigo.
Testes dinmicos: Feitos rodando o programa.
Caixa-branca: Teste de estruturas internas do programa.
Caixa-preta: Testa funcionalidades externas do programa, sem conhecimentos
da estrutura interna.
Testes no-funcionais: Teste de requisitos no-funcionais como desempenho,
usabilidade, confiabilidade, etc.

Nveis:

Processos:

Unidade/Componente: Verifica a funcionalidade de uma parte especfica do

cdigo. No caso de Orientao a Objeto, essa parte geralmente uma classe ou
um mtodo.
Integrao: Testa as interaes entre os componentes.
Sistema: Testa o sistema inteiro em funcionamento, usando o mtodo de caixapreta.
Aceitao: Teste feito pelo usurio/cliente.
Operao: Teste no ambiente final do software. Pode incluir testes de instalao,
compatibilidade, desempenho, etc.

Bottom Up: de testes de unidade a teste do sistema.

Top Down: de teste de sistema a testes de unidade.
Cascata: Testes realizados aps o desenvolvimento da funcionalidade.
Desenvolvimento orientado a testes (TDD): Testes de unidade so escritos
antes da funcionalidade.
etc...

Ferramentas de automao de testes:

Teste Unitrio e de Integrao: JUnit, DBUnit, TestNG
Teste de Carga e Desempenho: JMeter, JUnitPerf
Teste de Interface Web: Selenium
Gesto de issues: Bugzilla, JIRA, Mantis
Deteco de Erros: FindBugs, PMD
etc...

XP Programming

Utiliza o Desenvolvimento orientado a testes (Test-driven development ou TDD).

Etapas do TDD:
1. O prprio desenvolvedor da funcionalidade deve escrever os testes (antes da
funcionalidade!) utilizando a documentao (casos de uso e user stories).
2. Executar todos os testes (teste dos testes).
3. Escrever o cdigo da funcionalidade.
4. Executar novamente os testes.
5. Refatorar, corrigir e limpar o cdigo.
6. Repetir o ciclo para outras funcionalidades.
Testes de integrao realizados posteriormente por time de teste.
Prticas de integrao continuada so freqentemente usadas com o TDD. Nela, um
servidor configurado para rodar automaticamente testes de unidade e verifica todo o
cdigo enviado para o repositrio. No usaremos pois necessrio muito tempo para
configurar esse sistema.
Ferramentas de automao de teste que iremos usar:
JUnit: Realiza testes unitrios e de integrao
JMeter: Realiza testes de carga e desempenho

JUNIT - plataforma para teste de unidade

Para cada classe classe.java a ser testada, uma classe classeTest.java deve ser criada para
test-la. Para fazer isso, no Eclipse, ir em File->New->Other, Java->Junit->JUnit Test Case,
que gerar a classe classeTest.java.
Exemplo de cdigo a ser testado (Fibonacci.java) e cdigo para o JUnit (FibonacciTest.java):
Fibonacci.java
packagefibonacci;
publicclassFibonacci{

staticlongfibo(intn){
intF=0;//atual
intant=0;//anterior

for(inti=1;i<=n;i++){

if(i==1){
F=1;
ant=0;
}else{
F+=ant;
ant=Fant;
}

returnF;
}

publicstaticvoidmain(String[]args){

//testedoprograma.Imprimeos30primeirostermos
for(inti=0;i<30;i++){
System.out.print("("+i+"):"+Fibonacci.fibo(i)+"\t");
}

FibonacciTest.java:
package fibonacci;

importstaticorg.junit.Assert.*;
importorg.junit.Test;
importorg.junit.Before;
importorg.junit.After;

publicclassFibonacciTest{


//Introduzvaloresdeentrada

intvalor1;

intvalor2;

@Before

publicvoidsetUp(){

valor1=9;

valor2=11;

@After

publicvoidtearDown(){

valor1=0;

valor2=0;

@Test

publicvoidtest(){

//Executaafunocomovalordeentradadetesteerecebeovalorde
retorno

longretornofeito=Fibonacci.fibo(valor1);

//Comparaovalorderetornocomoesperado

assertEquals("falhouprimeiro",34,retornofeito,0);

retornofeito=Fibonacci.fibo(valor2);

assertEquals("falhousegundo",89,retornofeito,0);

Ao rodar o cdigo acima:

Alterando a linha:
assertEquals("falhouprimeiro",34,retornofeito,0);
por
assertEquals("falhouprimeiro",33,retornofeito,0);
(ouseja,colocandoumvalorincorreto):

Teste de exceo:
Tambm possvel testar a ocorrncia de uma exceo no cdigo, evitando a proliferao de
try/catchs no mesmo. Por exemplo, caso eu inclua um int testException = 1 / n em
Fibonacci.java, e mande n=0 como parmetro, isso retornar um RuntimeException por causa
da diviso por zero. Em FibonacciTest.java, o seguinte teste verifica essa exceo:

@Test(expected=RuntimeException.class)
publicvoidTESTRuntimeException()throwsException{
FibonaccimyClass=newFibonacci();
myClass.fibo(0);
}
}

Asserts:
Alm do assertEquals que foi usado, existem outras formas de asserts:
assertEquals("failure - strings are not equal", expected, actual ,
tolerance);
assertArrayEquals("failure - byte arrays not same", expected, actual);
assertTrue(true, boolean condition);
assertFalse("failure - should be false", boolean condition);
assertNull("should be null", Object);
assertNotNull("should not be null", Object);
assertSame("should be same", aObject, aObject);
assertNotSame("should not be same Object", expected, actual);
assertThat(Arrays.asList("one", "two", "three"), hasItems("one", "three"));

Annotations:
Nocdigodeexemplo,asannotations@Beforee@Afterforamusadasapenaspara
mostrarcomouslas.ElasssorealmentenecessriascasovocforusarumaLista
ououtroobjetonoseumtododeteste,paraqueelesejainicializadoe

posteriormentelimpadodamemria.Almde@Test,@Beforee@After,existemtambmas
seguintesAnnotations:

Annotation

Description

@Test
public void method()

The @Test annotation identifies a method as a test method.

@Test (expected =
Exception.class)

Fails if the method does not throw the named exception.

@Test(timeout=100)

Fails if the method takes longer than 100 milliseconds.

@Before
public void method()

This method is executed before each test. It is used to prepare the test
environment (e.g., read input data, initialize the class).

@After
public void method()

This method is executed after each test. It is used to cleanup the test
environment (e.g., delete temporary data, restore defaults). It can also
save memory by cleaning up expensive memory structures.

@BeforeClass
public static void
method()

This method is executed once, before the start of all tests. It is used to
perform time intensive activities, for example, to connect to a
database. Methods marked with this annotation need to be defined as
static to work with JUnit.

@AfterClass
public static void
method()

This method is executed once, after all tests have been finished. It is
used to perform clean-up activities, for example, to disconnect from a
database. Methods annotated with this annotation need to be defined
as static to work with JUnit.

@Ignore

Ignores the test method. This is useful when the underlying code has
been changed and the test case has not yet been adapted. Or if the
execution time of this test is too long to be included.

Regras de boa prtica com JUnit:

Use apenas dados suficientes (no teste 10 condies se trs forem suficientes)
No teste mtodos triviais, tipo get e set.
Achou um bug? No conserte sem antes escrever um teste que o pegue.
Comece pelas mais simples e deixe os testes complexos para o final.

JMeter - plataforma para teste de desempenho

O JMeter permite avaliar o desempenho dos sistemas de cliente-servidor simulando diversas
condies de carga no servidor.
Para se utilizar o JMeter, primeiramente deve se fazer o download do binrio no site:
https://jmeter.apache.org/download_jmeter.cgi
No caso do Windows, baixe o zip, descompacte-o e rode jmeter.bat que est na pasta bin.
Exemplo simples:
Faremos um exemplo simples utilizando em conjunto com o Apache Server, configurado em
localhost 127.0.0.1 porta 80.
Com o boto direito no Plano de Teste escolher a opo Add-> Threads(Users) -> Thread
Group.

Nessa aba pode se fazer a configurao do teste que ser feito.

No teste exemplo, utilizaremos as seguintes configuraes:
Number of Threads (Users): 30
Ramp-Up Period (in seconds): 3

Essa configurao significa que ser executado 10 threads a cada segundo. Caso queira
repetir essa requisio basta alterar o Loop Count (Contador de iterao).
Aps configurado, com o boto direito sobre o Thread Group escolher Add -> Sampler -> HTTP
Request
No HTTP Request, alterar o Server Name or IP para localhost (caso esteja fazendo esse teste
exemplo no localhost), a porta para 80 (ou qualquer outra que estiver configurada no servidor)
e alterar o Path para ./example.php

Nesse exemplo ser feito o teste com o uso de um arquivo php por ser bem simples. O
contedo do arquivo exemplo :
example.php
<html>
<head>
<title>PHP Test</title>
</head>
<body>
<?php

for ($sum = $i = 0; $i < 10000000; $i++)

{
$sum += $i;
}
echo $sum;

?>
</body>
</html>

Na pasta htdocs (Da ferramenta que foi utilizada para subir o servidor em localhost) adicionar o
arquivo example.php.
Novamente sobre o Thread Group, escolher Add -> Listener -> View Results in Table (ou outra
forma que achar conveniente para se visualizar os resultados)
Aps salvo as alteraes, basta executar.

Mais informaes:
https://pt.wikipedia.org/wiki/Test_Driven_Development
http://www.devmedia.com.br/testes-de-unidade-com-junit/4637
http://www.devmedia.com.br/junit-implementando-testes-unitarios-em-java-parte-i/1432
http://www.devmedia.com.br/usando-o-jmeter-para-teste-de-performance/20302
http://www.decom.ufop.br/imobilis/?p=1146
http://junit.org/
https://jmeter.apache.org/index.html