Академический Документы
Профессиональный Документы
Культура Документы
Testes
Orientao Viso Conceitual em Testes
Verso 0.3
ori_Visao_Conceitual_Testes.odt 1 de 10
Modelo 2.0
PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev
Histrico de Revises
Sumrio
1 Finalidade.................................................................................................................................................... 4
ori_Visao_Conceitual_Testes.odt 2 de 10
Modelo 2.0
PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev
6 Princpios de Teste...................................................................................................................................... 8
7 Referncias................................................................................................................................................ 10
ori_Visao_Conceitual_Testes.odt 3 de 10
Modelo 2.0
PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev
1 Finalidade
Definir Abordagens, Nveis e Tipos de Testes. Tambm tem por finalidade apresentar os principais
mitos e princpios existentes sobre testes.
As tcnicas de projeto de casos de teste so classificadas em Caixa Branca ou Caixa Preta [3] e
sero apresentadas a seguir.
Tambm conhecido como um teste funcional, pois desempenhado apenas atravs das funciona-
lidades do sistema: o testador no est preocupado com o cdigo. O testador fornece as entradas
ao componente ou ao sistema e examina uma sada (que falharo se no estiverem de acordo
com os requisitos do sistema). Acontece quando a codificao termina em alguma fase, e esse
cdigo vai para o grupo de testes. Os defeitos investigados pelos testes Caixa Preta esto em
uma classe de defeitos que os testes Caixa Branca no esto aptos a encontrar. Esses defeitos,
de acordo com [3] so:
Funes incorretas ou ausentes;
Defeitos de interface;
Defeitos de desempenho;
Defeitos de inicializao e trmino.
Tambm conhecidos como testes estruturais, testes caixa de vidro ou testes caixa clara, so tes-
tes que conhecem a estrutura de implementao do software e so geralmente aplicados a unida-
des pequenas de programas (unidades no integradas) [3]. Geralmente desempenhado pelo
prprio programador durante a programao.
Esse tipo de teste tem alguns benefcios como: o programador pode testar pequenas partes do
programa (isso faz com que a depurao seja mais fcil); o programador conhece o comporta-
mento esperado do sistema (dessa forma pode identificar melhor as falhas); enfim, conhecendo
melhor o cdigo, ele pode identificar falhas que seriam mais difceis aos olhos de outros.
Essa prtica considerada complementar ao processo de programao, pois muitos programado-
res j tm o hbito de executarem testes de caixa branca em seus cdigos.
Esse tipo de teste precisa garantir [4]:
Que todos os caminhos independentes dentro de um mdulo de software tenham sido
exercitados pelo menos uma vez;
O exerccio de todas as decises lgicas para valores verdadeiros e falsos;
ori_Visao_Conceitual_Testes.odt 4 de 10
Modelo 2.0
PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev
Um plano de teste, bem como a escolha do grupo de testes, deve ser desenvolvido de acordo, en-
tre outras coisas, com os nveis de teste escolhido para o projeto. Os testes de software podem
ser aplicados no ciclo de desenvolvimento de software atravs de vrios nveis. Esses nveis vo
desde o mais elementar, o de unidade, at o mais geral, o nvel de aceitao. Os nveis sero
apresentados em detalhes a seguir. Como os nomes so diferentes dependendo do autor, vamos
utilizar os nomes encontrados no padro IEEE.
Testes de pequenos elementos ou unidades do sistema [1]. Geralmente desempenhado pelo pr-
prio programador como sendo uma atividade complementar implementao. Nesse tipo de teste
so geralmente aplicados testes Caixa Branca, mas podem tambm ser aplicados Testes Caixa
Preta (caso se deseje testar funcionalmente a unidade ou componente).
Tipo de teste de software que tem a finalidade de testar hardware e software integrados [2]. Geral-
mente durante esse teste so verificados alguns requisitos no funcionais como performance, car-
ga, confiabilidade, etc. So aplicados aps os testes de unidade e integrao terem sido executa-
dos e o sistema j tenha em um estado estvel. Aqui so aplicados testes Caixa Preta.
ori_Visao_Conceitual_Testes.odt 5 de 10
Modelo 2.0
PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev
Teste baseado em requisitos de alto nvel. Os testes de aceitao servem para identificar dis-
cordncias do software de acordo com esses requisitos. Esse tipo de teste mais efetivo quando
desempenhado por usurios ou seus representantes em um ambiente mais realstico possvel.
Aqui so aplicados testes Caixa Preta.
4 Tipos de Testes
ori_Visao_Conceitual_Testes.odt 6 de 10
Modelo 2.0
PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev
Com esse tipo de teste o software forado a quebrar um mecanismo de proteo de acesso.
Como exemplo temos: tentar logar no sistema atravs de um teclado virtual com usurio no
autorizado. O sistema no deve permitir que usurios no autorizados acessem dados sigilosos.
ori_Visao_Conceitual_Testes.odt 7 de 10
Modelo 2.0
PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev
anteriormente sempre que existir uma alterao; a parcial, que executa apenas um subconjunto
de testes somente para as dependncias das reas modificadas.
4.11 Reteste
Execuo de testes falhos (somente os falhos) novamente aps seu conserto.
6 Princpios de Teste
Em [5][6] encontram-se alguns princpios que devem ser levados em considerao na hora de se
projetar e desenvolver uma tarefa de teste. Esses princpios podem ser vistos a seguir:
ori_Visao_Conceitual_Testes.odt 8 de 10
Modelo 2.0
PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev
esperados devem aparecer no caso de teste, mas muitas vezes no isso que acontece. Pode
acontecer um desconhecimento das sadas esperadas e o testador usar o bom senso na anlise.
Princpio 3: Uma organizao desenvolvedora de software deveria ter uma equipe prpria
para os testes de alto nvel.
Princpio 5: Casos de teste devem ser escritos para entradas esperadas bem como no
esperadas.
O princpio 5 diz respeito robustez do caso de teste. Com as entradas esperadas, busca-se
testar se o programa no faz o que preciso fazer. Com as entradas no desejadas, busca-se
testar se o programa resulta em uma falha absurda. Como exemplo podemos citar uma entrada
incorreta em um programa que faz com que ele trave ou que o programa simplesmente feche.
Desse exemplo camos tambm no princpio 6, que verifica que mesmo que uma entrada seja
absurda, o programa tem que ser robusto o suficiente para suportar.
ori_Visao_Conceitual_Testes.odt 9 de 10
Modelo 2.0
PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev
7 Referncias
[1] Ross, Kelvin. Pratical Guide to Software System Testing. K.J. Ross & Associates Pty.
Ltd:1998.
[2] Craig, Rick D.; Jaskiel, Stefan P. Systematic Software Testing. Artech House Publishers Bos-
ton, London: 2002.
[3] Pressman, Roger S. Engenharia de Software. Traduo de Jos Carlos Barbosa dos Santos.
So Paulo: Pearson Education do Brasil, 1995.
[4] Loveland, Scott et al. Software testing techniques: Finding the Defects that Matter. Massa-
chusetts: Charles River media, Inc, 2005.
[5] Myers, Glenford J. The Art of Software Testing. New Jersey: John Wiley & Sons, Inc, 2004 .
[6] Burnstein, Ilene. Practical Software Testing: A Process-oriented Approach.
New York: Springer, 2003.
ori_Visao_Conceitual_Testes.odt 10 de 10
Modelo 2.0