IC-UNICAMP
Eliane Martins
INF321
Fases de Testes
QST112
06/2001
IC-UNICAMP
Eliane Martins
Tópicos
• Testes de unidades
• Noção de driver e stubs
• Testes de integração
• Estratégias
• Ordem de integração
• Testes de sistemas
• Requisitos de qualidade
• Testes de aceitação
• Testes de regressão
QST112
06/2001
IC-UNICAMP
Eliane Martins
Testes no Processo de Desenvolvimento
QST112
06/2001
IC-UNICAMP
Eliane Martins
Testes de Unidades e de Integração
Especificação da
arquitetura
Código do
componente
Espec. do
componente
Código do
componente
Espec. do
componente
Testes de
unidade
.
.
.
Testes de
unidade
componente
testado
Testes de
integração
subsistemas
integrados
componente
testado
QST112
06/2001
IC-UNICAMP
Eliane Martins
Testes de Unidades
• Visam exercitar detalhadamente uma
unidade do sistema.
• Uma unidade é uma entidade executável
independente.
– Pode representar:
•
•
•
•
•
•
Uma função.
Uma classe ou um tipo abstrato de dados.
Um grupo pequeno de classes.
Um componente.
Um framework.
Um serviço
QST112
06/2001
IC-UNICAMP
Eliane Martins
Modelos de falhas
• Os Testes de Unidade visam revelar a presença
de falhas em:
– interfaces: parâmetros de entrada e saída
– estruturas de dados: integridade dos dados
armazenados
– condições de limite: a unidade opera adequadamente
nos limites estabelecidos?
– tratamento de erros: a descrição do erro é
inteligível? A descrição corresponde ao erro
encontrado? O tratamento de exceção é adequado?
QST112
06/2001
IC-UNICAMP
Eliane Martins
Componentes de teste
• Driver
– Programa ou classe que aplica os casos de teste ao
componente em teste Faz o papel de cliente do
componente em teste (CeT).
• Stub
– Implementação temporária, mínima, de um componente
usado pelo CeT, com o objetivo de melhorar a
controlabilidade e observabilidade do CeT durante os testes.
Faz o papel de servidor do CeT.
• Ambiente de teste (Test Harness)
– Sistema que compreende os drivers, stubs, CeT e outras
ferramentas de apoio aos testes.
QST112
06/2001
IC-UNICAMP
Eliane Martins
A unidade e suas colaborações
Cliente
Unidade
em
Teste
Servidor 1
Servidor 2
Servidor 3
QST112
06/2001
IC-UNICAMP
Eliane Martins
A unidade e os componentes de teste
Driver
Casos
de teste
Stub 1
Unidade
em
Teste
Stub 2
resultados
Stub 3
QST112
06/2001
IC-UNICAMP
Eliane Martins
Exemplo – componente em teste
CriarTabela( )
LerItem( )
InserirItem( )
RemoverItem( )
MostrarTabela( )
Tabela
QST112
06/2001
IC-UNICAMP
Eliane Martins
Exemplo - Driver
CriarTabela( )
LerItem( )
InserirItem( )
RemoverItem( )
MostrarTabela( )
Driver
Tabela
type TabInt = array [ 1 .. N, 1 ..
M ] of integer;
...
var Tabela: TabInt,
x: integer;
...
criaTab ;
leItem ( x );
insereItem (x );
mostraTab ;
QST112
....
06/2001
IC-UNICAMP
Eliane Martins
Exemplo Driver OO
CasoTeste
CeT
Driver
CasoTeste001
CasoTeste002
CasoTeste003
...
• Contém instâncias dos casos de teste;
• Contém instância da classe em teste
(CeT);
QST112
• Pode herdar de uma
classe abstrata
06/2001
IC-UNICAMP
Eliane Martins
Exemplo - Fitnesse
package fixtures;
import br.unicamp.ic.inf321.funcoes.Operacao;
import fit.ColumnFixture;
public class StringFeatures extends ColumnFixture {
public String entrada;
public String outraEntrada;
!2 Casos de teste para função "Palindromo"public boolean confirmaPalindromo() {
return Operacao.isPalindrome(entrada);
| -!fixtures.Palindromo!- |
| entrada |
isPalindrome() |
| bruno |
| false |
| arara |
| true |
| ana anana ana |
| true |
| null |
| false |
| é |
| false |
| omo ada "oro" ada omo | |true |
}
}
public boolean comecaComDigitoOuMaiuscula() {
boolean result;
result = Operacao.startsWithDigitOrUpper(entrada);
return result;
}
public String eliminaLixo() {
return Operacao.stripGarbage(outraEntrada);
}
QST112
06/2001
IC-UNICAMP
Eliane Martins
Exemplo: stub
Tabela
Stub
type VetorInt = array [1 .. N] of
integer;
...
procedure Ordena_Vetor (a :
VetorInt);
...
begin
write (“Valores fornecidos”);
for i := 1 to N do write (a [ i ] );
write (“Forneça os valores
ordenados”);
for i := 1 to N do read (a [ i ] );
end;
QST112
06/2001
IC-UNICAMP
Eliane Martins
Fases da execução de um caso de teste
• Preparação (set up):
– Cria o que for necessário, configurando os stubs de acordo
para que o caso de teste execute conforme o esperado.
• Execução:
– Interage com o CeT, aplicando os testes gerados e
observando os resultados obtidos.
• Verificação:
– Compara os resultados obtidos com os esperados.
• Término (clean up ou tear down):
– Termina a execução do CeT e deixa o ambiente de execução
de testes no mesmo estado em que estava antes da
realização do caso de teste.
QST112
06/2001
IC-UNICAMP
Eliane Martins
Estrutura de testes (xUnit)
Servidores
caso de teste
Prepara
(set up)
Executa
Verifica
Termina
(clean up)
cria
configura
instala
CeT
Stubs
(ou mocks)
QST112
06/2001
IC-UNICAMP
Eliane Martins
Mock Objects
• Criados pela comunidade XP (em 2000)
– Tim Mackinnon, Steve Freeman, Philip Craig. “Endo-Testing: Unit
Testing with Mock Objects”
(www.cs.ualberta.ca/~hoover/cmput401/XP-Notes/xpconf/Papers/4_4_MacKinnon.pdf), apresentada no evento
XP2000.(disponível emt www.mockobjects.com).
• Objetivo:
– Sistematizar a geração de stubs
– Desenvolver uma infra-estrutura para criação de
mocks e incorporação dos mesmos aos QST112
Testes de
06/2001
Unidade.
IC-UNICAMP
Eliane Martins
Bibliotecas
• Mock Objects (ou mocks) servem para emular ou
instrumentar o contexto (serviços requeridos) de
objetos da CeT.
• Devem ser simples de implementar e não duplicar a
implementação do código real.
• Bibliotecas de mocks podem ser usadas para criar
stubs: existem várias APIs para esse fim:
–
–
–
–
–
MockObjects (www.mockobjects.com)
EasyMock (www.easymock.com)
MockMaker (www.mockmaker.org )
djUnit (http://works.dgic.co.jp/djunit/)
...
QST112
06/2001
IC-UNICAMP
Eliane Martins
Mocks x stubs
• Mocks são voltados para testes classes. Stubs, em
princípio, podem ser usados em qqr linguagem (OO ou
não).
• Segundo Martin Fowler, mocks e stubs não são
sinônimos:
– Mocks podem servir para colocar o objeto da CeT no estado
desejado para os testes.
– Um stub é uma implementação alternativa da interface do objeto
substituído.
– Um stub é mais passivo, geralmente retornando dados préestabelecidos pelos casos de teste para a CeT.
– Mocks podem verificar se o servidor foi chamado adequadamente 
contêm verificação embutida (assertivas)
QST112
06/2001
IC-UNICAMP
Eliane Martins
Exemplo: classe em teste e uma servidora
classe ClasseEmTeste
Servidora serv;
metodo( )
// chama servidora
serv.executa( )
end
end
classe Servidora
executa( )
# código complexo
end
http://www.floehopper.org/articles/2006/09/11/the-difference-between-mocks-and-stubs
QST112
06/2001
IC-UNICAMP
Eliane Martins
Exemplo de stub: pseudo-código
classe ClasseDeTeste implementa Test::Unit::TestCase
classe ServidoraStub
executa( )
retorna X
end
end
// exemplo_uso_Stub
ServidoraStub servidora
classeTeste = ClasseEmTeste.new(servidora)
assert_equal X, classeTeste.metodo
end
end
http://www.floehopper.org/articles/2006/09/11/the-difference-between-mocks-and-stubs
QST112
06/2001
IC-UNICAMP
Eliane Martins
Exemplo de mock: pseudo-código
classe ClasseDeTeste implementa Test::Unit::TestCase
classe ServidoraMock
atributo: call_count
...
call_count = 0
// métodos
execute( )
call_count +=1 // conta nº de chamadas ao método
end
get_call_count ( )
...
end
// exemplo_uso_Mock
servidora = ServidoraMock.new
classeTeste = ClasseEmTeste.new(servidora)
// verifica nº de chamadas ao método servidor
assert_equal 1, servidora.get_call_count
http://www.floehopper.org/articles/2006/09/11/the-difference-between-mocks-and-stubs
end
QST112
end
06/2001
IC-UNICAMP
Eliane Martins
Outro exemplo : o mock
// Usado no teste do método: canUserLogin( User, String ) , para substituir
// o método validatePassword, chamado pelo método em teste.
public class MockUser implements User {
Interface da classe
...
// Prepara o que retornar quando validatePassword for chamado
substituída
public void setValidatePasswordResult( boolean result ) {
expectedCalls++;
Determina nº esperado de chamadas ao
this.returnResult = result; }
método substituído
// Implementação do mock de validatePassword
public boolean validatePassword( String password ) {
actualCalls++;
Conta chamadas ao método substituído
return returnResult; }
public boolean verify() {
return expectedCalls == actualCalls; }
... }
Verifica se chamadas de acordo com oQST112
esperado
06/2001
IC-UNICAMP
Eliane Martins
Uso do mock: o caso de teste
// Caso de teste usando o MockUser criado anteriormente
public void testCanUserLogin() {
MockUser user = new MockUser();
user.setValidatePasswordResult( true );
// usa objeto em teste já criado: ot
boolean result = ot.canUserLogin( user, "foobar" );
preparação
execução
assertTrue("Expected to validate user " + "password \"foobar\"",
result );
verificação
assertTrue("MockUser not used as expected", user.verify());
}
QST112
06/2001
IC-UNICAMP
Eliane Martins
Testes de unidade e de integração
Especificação da
arquitetura
Código do
componente
Espec. do
componente
Código do
componente
Espec. do
componente
Testes de
unidade
.
.
.
Testes de
unidade
componente
testado
Testes de
integração
subsistemas
integrados
componente
testado
QST112
06/2001
IC-UNICAMP
Eliane Martins
Testes de integração
• Integram unidades já testadas
• Objetivo: exercitar interações entre unidades
QST112
06/2001
IC-UNICAMP
Eliane Martins
Modelo de falhas de integração
•
Falhas de interpretação: ocorrem quando a funcionalidade implementada por
uma unidade difere do que é esperado.
– B implementa incorretamente um serviço requerido por A.
– B não implementa um serviço requerido por A.
– B implementa um serviço não requerido por A e que interfere com seu
funcionamento.
•
Falhas devido a chamadas incorretas:
– B é chamado por A quando não deveria (chamada extra).
– B é chamado em momento da execução indevido (chamada incorreta).
– B não é chamado por A quando deveria (chamada ausente).
•
Falhas de interface: ocorrem quando o padrão de interação (protocolo) entre
duas unidades é violado.
–
–
–
–
–
violação da integridade de arquivos e estruturas de dados globais
tratamento de erros (exceções) incorreto
problema de configuração / versões
falta de recursos para atender a demanda das unidades
QST112
objeto incorreto é associado a mensagem (polimorfismo)
06/2001
[Leung
e White; Binder99]
IC-UNICAMP
Eliane Martins
Abordagens de integração
• Não incremental (“big-bang”):
– todas as unidades são integradas de uma só vez
 esforço de preparação menor
 esforço para diagnóstico e correção de falhas é maior
• Incremental
– As unidades são integradas gradualmente
– Existem inúmeras estratégias
•
•
•
•
•
•
Descendente (“top-down”)
Ascendente (“bottom-up”)
Por colaboração
Mista
Por camadas
...
QST112
06/2001
IC-UNICAMP
Eliane Martins
Abordagem incremental
A
T1
T2
T3
B
A
A
T1
T2
T3
T4
T1
B
T2
T3
T4
C
B
C
T5
D
QST112
06/2001
IC-UNICAMP
Eliane Martins
Integração descendente (“top-down”)
• Começa com a unidade principal e vai aos poucos
integrando as unidades subordinadas
• Em OO: classes de controle primeiro
• Utiliza stubs em lugar das unidades subordinadas
QST112
06/2001
IC-UNICAMP
Eliane Martins
Integração ascendente (“bottom-up”)
• Começa a integração pelas unidades subordinadas
• Em OO: começar pelas classes independentes ou
que usam poucas servidoras
• Utiliza drivers em lugar das unidades de controle
• As unidades de mais baixo nível são testadas
primeiro e mais vezes
QST112
06/2001
IC-UNICAMP
Eliane Martins
Integração sanduíche
• Combina estratégia ascendente e descendente
• O sistema pode ser visto como uma arquitetura com 3
camadas:
– Camada-alvo, no meio
– Camada superior, acima da camada alvo
– Camada inferior, abaixo da camada alvo
• Os testes convergem para a camada-alvo
• Como escolher a camada-alvo?
– Objetivo: reduzir nº de stubs e drivers
QST112
06/2001
IC-UNICAMP
Eliane Martins
Ordem de integração
• Ao integrar vários componentes, é importante
determinar a ordem para integrá-los
• Componentes podem depender de outros por várias
razões:
– Classes dependem de outras de diferentes formas:
Composição e agregação, herança, uso de métodos ou
atributos definidos em outras classes
– Chamadas a interfaces (API)
• Dependência  necessidade de stubs
 Análise de dependências:
 Objetivo: determinar uma ordem de integração que reduza o
número de stubs
QST112
06/2001
IC-UNICAMP
Eliane Martins
Exemplo: Diagrama de Classes
 Possui
Possui 
Cliente
1 ..*
0 ..*
Conta
Contém 
2 ..*
Aplicada a 
Serviço
Financeiro
Realizado através de 
0 ..*
Usa 
Transação
Dinheiro
Usa 
1 ..1
Taxas
[inspirado em Binder00, 13.1.3]
QST112
06/2001
IC-UNICAMP
Eliane Martins
Exemplo de dependência: X usa Y
 usa
ServiçoFinanceiro
Transação
Cliente
Taxas
Array [Int]
 Não é usada por nenhuma outra classe
Conta
Dinheiro
Classe de implementação
Por onde começar a
integração para reduzir o
número de stubs?
Por onde começar a
integração para reduzir o
número de drivers?
 Não usa nenhuma outra classe
[inspirado em Binder00, 13.1.3]
QST112
06/2001
IC-UNICAMP
Eliane Martins
Determinação da ordem de testes (1)
• Existem várias propostas com base no
grafo de dependências:
– Caso não existam ciclos:
• Integração ascendente: para reduzir nº de stubs,
começar pelos componentes que não dependem
de outros
• Integração descendente: para reduzir o nº de
drivers, começar pelo componente do qual
nenhum outro depende
QST112
06/2001
IC-UNICAMP
Eliane Martins
Exemplo – Integração Ascendente
ServiçoFinanceiro
Transação
Taxas
Cliente
Conta
Array [Int]
Dinheiro
Testa
Dinheiro
Testa
Conta +
Dinheiro
Testa
Taxas
Testa
Cliente+ Conta+
Dinheiro
Testa
Transação+Conta+
Dinheiro+Taxas
Testa
ServiçoFinanc. +
Transação +
Conta +
Dinheiro +
Taxas
QST112
06/2001
IC-UNICAMP
Eliane Martins
Exemplo – Integração Sanduíche
ServiçoFinanceiro
Transação
Taxas
Camada alvo
Cliente
Conta
Array [Int]
Dinheiro
Testa
Dinheiro
Testa
Conta +
Dinheiro
Testa
Taxas
Testa
ServiçoFinac.
Testa
Cliente+ Conta+
Dinheiro
Testa
Transação+Conta+
Dinheiro+Taxas
Testa
ServiçoFinanc. +
Transação +
Conta +
Dinheiro +
Taxas
QST112
06/2001
IC-UNICAMP
Eliane Martins
Determinação da ordem de testes (2)
• Existem várias propostas com base no grafo de
dependências:
– Caso existam ciclos  componentes fortemente
acoplados
• Uma opção: refatore sua arquitetura, para evitar os ciclos, ou
• “Quebre” os ciclos:
– As propostas variam de acordo com a forma de quebrar
os ciclos
– Ex.: em OO  remover uma associação (herança e
agregação não são “quebráveis”)
 Quebra da dependência  construção de stubs
QST112
06/2001
IC-UNICAMP
Eliane Martins
Exemplo – quebra de ciclos
Integração ascendente:
A
Testa
B+D
C
B
D
Testa
D
Stub
C
Testa
A+B+C+D
Testa
C+D
QST112
06/2001
IC-UNICAMP
Eliane Martins
Análise de dependências
• Existem ferramentas, como por exemplo:
– Class Dependency Analyzer (CDA)
• http://www.dependency-analyzer.org/
– Jdepend
• http://clarkware.com/software/JDepend.html
– Metrics
• http://metrics.sourceforge.net/
– ...
QST112
06/2001
IC-UNICAMP
Eliane Martins
Testes de Sistemas
Especificação de
Requisitos Funcionais
subsistemas
integrados
Especificação de
Requisitos de Qualid.
Manual do
Usuário
Testes de
Sistemas
(funcionais)
funcionalidades
testadas
sistema
aceito
Testes de
Sistemas
(qualidade)
Testes de
Aceitação
sistema
testado
Requisitos
do usuário
QST112
06/2001
IC-UNICAMP
Eliane Martins
Fontes de informação para os testes
• Especificação de requisitos.
• Protótipo, layouts ou modelos da IU.
• Políticas da organização
implementadas como objetos de
negócio, “stored procedures” ou
“triggers”.
• Características do produto descritas
na literatura.
• Características e procedimentos
descritos na documentação, telas de
ajuda ou assistentes de operação
(“wizards”).
• Manual do usuário.
• Padrões.
Especificação
deve ser:
• completa
• consistente
• precisa
 testável
QST112
06/2001
IC-UNICAMP
Eliane Martins
Testes dos requisitos funcionais
• Visam verificar se as funcionalidades especificadas
foram devidamente implementadas

• Uso de métodos de testes caixa-preta :
–
–
–
–
–
–
–
partição de equivalência
valores-limite
tabela de decisão / grafo causa-efeito
modelos de estado
diagramas de casos de uso
cenários
...
QST112
06/2001
IC-UNICAMP
Eliane Martins
Testes dos requisitos de qualidade
• Visam determinar se a implementação do sistema
satisfaz aos requisitos de qualidade (não funcionais)
• Tipos de testes:
–
–
–
–
–
–
configuração e compatibilidade
desempenho
estresse
tolerância a falhas
segurança
...
QST112
06/2001
IC-UNICAMP
Eliane Martins
Testes de desempenho
• Visam determinar se implementação satisfaz aos
requisitos de desempenho especificados:
– configuração de rede
– tempo de CPU
– limitação de memória
– carga do sistema
– taxa de chegada de entradas
 esses requisitos devem ser descritos de forma testável
ex.: nº de transações/seg ou tempo de resposta em seg,
mseg
O sistema é testado em condições reais de operação.
QST112
06/2001
IC-UNICAMP
Eliane Martins
Variações dos testes de desempenho
• Testes de carga
– geralmente associados com sistemas transacionais
– usam simuladores de carga para geração de múltiplas
transações/usuários simultaneamente
• Testes de volume
– geralmente usados para sistemas “batch”
– consistem na transmissão de um grande volume de
informações quando o sistema está com a carga normal ou
– uso de arquivos grandes (maior tamanho possível) ou de
grande número de arquivos
QST112
06/2001
IC-UNICAMP
Eliane Martins
Teste de estresse
• Visa ir além dos limites do sistema: nº máximo de
usuários simultâneos, nº máximo de processos ou de
transações, …:
– verificar se o sistema não apresenta um comportamento de risco
quando submetido a carga elevada e com um ou mais recursos
saturados.
• Importância:
– muitos sistemas apresentam comportamento de risco nessa
situação
– falhas detectadas são sutis
– correções desse tipo de falha podem requerer retrabalho
considerável (e.g., rever arquitetura)
QST112
06/2001
IC-UNICAMP
Eliane Martins
Robustez
• O que é [IEEE Std Glossary]:
– O grau em que um sistema ou componente pode
funcionar corretamente em presença de entradas
inválidas ou sob condições ambientais estressantes.
• Em suma, pode ser interpretado como a
capacidade do sistema em:
– Tratar exceções
– Tolerar falhas
• Como medir robustez?
– proposta de Robustness Benchmark
• Como determinar se um sistema é robusto?
– Realização de testes de robustez
QST112
06/2001
IC-UNICAMP
Eliane Martins
Testes de robustez
• Objetivo:

– Verificar se o comportamento do sistema é
adequado em presença de:
• Entradas inválidas
• Entradas inoportunas
• Condições ambientais anormais
– Abordagens:
• Formais
• Baseadas em injeção de falhas
QST112
06/2001
IC-UNICAMP
Eliane Martins
Injeção de falhas
• O que é
– Técnica de validação de software que consiste em
observar o funcionamento de um sistema em
presença de falhas ou erros.
• Objetivos:
– Verificação – remoção de falhas de software no
sistema em teste.
– Avaliação – obtenção de medidas de atributos de
qualidade: confiabilidade, disponibilidade, entre
outras.
QST112
06/2001
IC-UNICAMP
Eliane Martins
Esquema típico dos testes de robustez
Comportamento
especificado
Normal
Não especificado
Deve retornar
erro
Espaço de
entrada
Entradas
válidas
Entradas
inválidas ou
inoportunas
Espaço de
saída
Software em
Teste
Operação
robusta
Defeito
Falhas de interface
[base: Koopman99]
QST112
06/2001
IC-UNICAMP
Eliane Martins
Falhas de interface: o modelo Ballista
Tipo do dado Valores
Inteiro
0, 1, -1, MaxInt, MinInt
Real
0., 1., -1., DblMin, DblMax
Boolean
Inversão de estado (V F, F  V)
String
Null, string do tamanho da memória virtual, string com
caracteres especiais (fim de arquivo, formatação, etc)
Descritor de
arquivo (tipo
inteiro)
0, 1, -1, MaxInt, MinInt
descritor de: arquivo aberto para leitura, arquivo
aberto para escrita, arquivo vazio, arquivo apagado
após o descritor ter sido atribuído
Fonte: Projeto Ballista - http://www.ece.cmu.edu/~koopman/ballista/
QST112
06/2001
IC-UNICAMP
Eliane Martins
Exemplo de falhas de interface – modelo
Ballista
API: write(int filedesc, const void *buffer, size_t nbytes)
Tipos de
dados
Valores
de teste
Caso de
teste
descritor
de arquivos
FD_CLOSED
FD_OPEN_READ
FD_OPEN_WRITE
FD_DELETED
FD_EMPTYFILE
...
buffer de
memória
BUF_SMALL_1
BUF_LARGE_512M
BUF_HUGE_2G
BUF_NULL
BUF_16
...
tamanho
SIZE_1
SIZE_ZERO
SIZE_NEG
SIZE_MININT
SIZE_MAXINT
...
write(FD_CLOSED, BUF_NULL, SIZE-NEG)
(inspirado em Koopman2008)
QST112
06/2001
IC-UNICAMP
Eliane Martins
Exemplos de resultados da aplicação de Ballista
com Sistemas Operacionais
Sistema operacional
Nº
funções
testadas
Nº de
funções
“system
killers”
Exemplo de
funções “system
killer”
% de defeitos
de robustez
(normalizada)
Linux 2.0.18
190
0
N/a
12,5
Red Hat Linux 2.2.5
183
0
N/a
21,9
Windows 98 SE SP 1
237
7
CreateThread,
DuplicateHandle,
strncpy, ...
17,8
Windos CE 2.11
179
28
Sun JVM 1.3.1-04
(Red Hat Linux
2.4.18-3)
226
0
Nº de funções chamadas que foram a
causa do defeito catastrófico
13,7
N/a
4,7
Funções chamadas que foram a
causa do defeito catastrófico
QST112
Fonte: Philip Koopman, Kobey DeVale, and John DeVale. INTERFACE ROBUSTNESS TESTING: EXPERIENCES AND
06/2001
LESSONS LEARNED FROM THE BALLISTA PROJECT. Relatório, 2008.
IC-UNICAMP
Eliane Martins
Testes de segurança
• Visam verificar a capacidade do sistema de impedir
acesso não autorizado, sabotagem ou outros ataques
intencionais
• Características básicas de segurança são testadas
como as outras funcionalidades (logon/logoff,
permissões)
• Testes são geralmente feitos por especialistas ou
“hackers” contratados
• Testam a capacidade do sistema de resistir a ataques
– Quem realiza os testes deve “pensar” como um atacante
QST112
06/2001
IC-UNICAMP
Eliane Martins
Recomendações para Testes de Segurança
• Critérios e metodologias para testes de segurança
foram propostos por diferentes grupos:
– NIST (National Institute of Standards and Technology)
• Manual descrevendo técnicas a serem usadas nos testes de
segurança
– OSSTMM (Open Source Security Testing Methodology
Manual)
• desenvolvido pela ISECOM (Institute for Security and Open
Methodologies)
• Manual descreve a metodologia proposta para testes e análise
de segurança
– OWASP (Open Web Application Security Project)
• Guia descrevendo melhores práticas para a realização de testes
de penetração para aplicações e serviços Web
QST112
06/2001
IC-UNICAMP
Eliane Martins
Testes de Aceitação
Especificação de
Requisitos Funcionais
subsistemas
integrados
Especificação de
Requisitos de Qualid.
Manual do
Usuário
Testes de
Sistemas
(funcionais)
funcionalidades
testadas
sistema
aceito
Testes de
Sistemas
(qualidade)
Testes de
Aceitação
sistema
testado
Requisitos
do usuário
QST112
06/2001
IC-UNICAMP
Eliane Martins
Testes de Aceitação
• Têm os mesmos objetivos que os testes de sistemas,
só que envolvem a participação do cliente ou usuário
• Escolha dos testes feita pelo cliente
• Referências:
– Manual do Usuário
• Testes alfa:
– realizados por um grupo de usuários no ambiente de
desenvolvimento
– seu objetivo é determinar se o sistema pode ser liberado
• Testes beta
– realizados por um grupo de usuários em ambiente de
operação
QST112
06/2001
IC-UNICAMP
Eliane Martins
Ferramentas
• Testes manuais:
– não recomendável pois número de testes e nº de falhas 
• Ferramentas que podem auxiliar:
– capture/playback: permitem armazenar e re-aplicar conjuntos
de testes
– controle de versões: controlar o sistema e seu histórico de
testes
– comparação entre resultados do delta e da linha básica
– embaralhador de casos de teste: permitem revelar falhas de
seqüência de entradas
– testes embutidos: assertivas permitem revelar falhas de
contrato. Drivers embutidos permitem reduzir custos com
manutenção dos testes.
QST112
06/2001
IC-UNICAMP
Eliane Martins
Referências
R.Binder. Testing OO Systems. Addison Wesley, 1999, c.16-19.
M.Fowler. Mocks aren’t stubs. Postado na Internet em julho/2004.
http://www.theserverside.com/news/thread.tss?thread_id=27209
G.Rothermel, M.J.Harrold. “A Framework for Evaluating Regression Test
Selection Techniques”, Proc. 16th. Int’l Conf on Sw Eng., Sorrento, Itália,
maio/1994, pg. 201-210.
M.J.Harrold. “Testing Evolving Software”. The Journal of Systems and Sw, nº
47, 1999, pp173-181.
L.A Fondazzi Martimiano. “Estudo de Técnicas de Teste de Regressão
Baseado em Mutação Seletiva”. Dissertação de mestrado. Instituto de
Ciências Matemáticas e de Computação - USP/S.Carlos, 1999.
G. Meszaros. : A Pattern Language for Automated Testing of Indirect
Inputs and Outputs using XUnit. PLOP 2004. Obtained in jan/2006
at: http://testautomationpatterns.com/TestingIndirectIO.html
QST112
06/2001