PD-DATAPREV

Processo de Desenvolvimento de Software da Dataprev

Orientao Viso Conceitual em Testes

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

Orientao Viso Conceitual em Testes

Histrico de Revises

Data Verso Descrio Autor

23/04/2010 0.1 Verso inicial Fernanda Monteiro
07/10/10 0.2 Verificao ortogrfica Ana Eckel
22/10/2014 0.3 Verificao ortogrfica Samuel Portela e
Anlia Lima

Sumrio
1 Finalidade.................................................................................................................................................... 4

2 Tcnicas para Projeto de Casos de Teste (ou Abordagens de Teste).........................................................4

2.1 Testes de Caixa Preta (Black Box)........................................................................................................... 4
2.2 Testes de Caixa Branca (White Box)........................................................................................................ 4
3 Nveis de Testes de Software (ou Estgios de Teste).................................................................................5
3.1 Teste de Unidade..................................................................................................................................... 5
3.2 Teste de Integrao.................................................................................................................................. 5
3.3 Teste de Sistema...................................................................................................................................... 5
3.4 Teste de Aceitao (ou Homologao)..................................................................................................... 5
3.4.1 Testes Alfa e Beta 6
4 Tipos de Testes........................................................................................................................................... 6
4.1 Teste de Sanidade.................................................................................................................................... 6
4.2 Teste Funcional........................................................................................................................................ 6
4.3 Teste de Recuperao de Falhas............................................................................................................. 6
4.4 Teste de Segurana e Controle de Acesso.............................................................................................. 6
4.5 Teste de Performance.............................................................................................................................. 7
4.6 Teste de Volume (carga).......................................................................................................................... 7
4.7 Teste de Estresse..................................................................................................................................... 7
4.8 Teste de Configurao ou Portabilidade................................................................................................... 7
4.9 Teste de Interface com o Usurio............................................................................................................. 7
4.10 Teste de Regresso................................................................................................................................ 7
4.11 Reteste................................................................................................................................................... 8
5 Mitos sobre Teste........................................................................................................................................ 8

ori_Visao_Conceitual_Testes.odt 2 de 10

Modelo 2.0
 PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev

Orientao Viso Conceitual em Testes

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

Orientao Viso Conceitual em Testes

1 Finalidade
Definir Abordagens, Nveis e Tipos de Testes. Tambm tem por finalidade apresentar os principais
mitos e princpios existentes sobre testes.

2 Tcnicas para Projeto de Casos de Teste (ou Abordagens de Teste)

As tcnicas de projeto de casos de teste so classificadas em Caixa Branca ou Caixa Preta [3] e
sero apresentadas a seguir.

2.1 Testes de Caixa Preta (Black Box)

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.

2.2 Testes de Caixa Branca (White Box)

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

Orientao Viso Conceitual em Testes

O exerccio de todos os laos em suas fronteiras e dentro de seus limites operacionais;

O exerccio de estruturas de dados internas para garantir a sua qualidade.

3 Nveis de Testes de Software (ou Estgios de Teste)

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.

3.1 Teste de Unidade

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).

3.2 Teste de Integrao

Tem a finalidade de encontrar falhas quando pedaos de cdigo so integrados, principalmente

falhas de interface [2]. Podem ser aplicados de acordo com duas estratgias [1]:
Bottom up: integrao de mdulos de baixo nvel para a formao de mdulos maiores;
Top down: integrao de mdulos de alto nvel substituindo mdulos de baixo nvel com
stubs de teste para simular interfaces;
Mista: mesclagem das duas estratgias.
Essas estratgias so necessrias para que testes possam ser desempenhados sem a necessida-
de de todos os componentes estarem terminados. Os testes de integrao devem ser desempe-
nhados o mais cedo possvel, logo aps terem sido aplicados testes de unidade. Testes de inte-
grao geralmente aplicam testes de Caixa Preta [1].

3.3 Teste de Sistema

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.

3.4 Teste de Aceitao (ou Homologao)

ori_Visao_Conceitual_Testes.odt 5 de 10

Modelo 2.0
 PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev

Orientao Viso Conceitual em Testes

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.

3.4.1 Testes Alfa e Beta

So processos de teste de validao bastante usados pelos desenvolvedores de software para

descobrir erros que s o usurio final parece ser capaz de descobrir (instrues de uso podem ser
mal interpretadas, combinaes estranhas de dados podem ser usadas, sadas que pareciam cla-
ras ao analista podem ser no to claras ao usurio em campo). Tm como objetivo testar a apli-
cao em um produto.
O teste Alfa realizado nas instalaes do desenvolvedor. O produto usado pelo cliente com o
desenvolvedor observando e registrando erros e problemas de uso. Esse tipo de teste conduzi-
do em um ambiente controlado. J no teste Beta, o desenvolvedor no est presente. O cliente re-
gistra todos os problemas encontrados e os relata ao desenvolvedor que far as modificaes ne-
cessrias e entrega o produto final ao cliente.

4 Tipos de Testes

4.1 Teste de Sanidade

Com esse tipo de teste possvel avaliar se o build est estvel o suficiente para ser submetido a
testes mais detalhados, projetados e implementados para a demanda de testes da iterao (Teste
Funcional). Este tipo de teste tambm conhecido como Smoke test e tem o propsito de evitar
que se desperdicem recursos de testes com um build no suficientemente estvel para testes.

4.2 Teste Funcional

Com esse tipo de teste a funcionalidade geral do sistema em termos de regras de negcio
testada. Devem ser testadas condies vlidas e invlidas. Como exemplo, pode-se citar testar o
Cadastro de um usurio no sistema.

4.3 Teste de Recuperao de Falhas

Com esse tipo de teste o software forado a falhar de diversas maneiras para que seja
verificado o seu comportamento, bem como a adequao dos procedimentos de recuperao. A
recuperao pode ser automtica ou exigir iterao humana. Como exemplo podemos citar a
interrupo de uma impresso por falta de energia. O sistema deve ser capaz de retornar e
informar ao usurio da impresso pendente.

4.4 Teste de Segurana e Controle de Acesso

ori_Visao_Conceitual_Testes.odt 6 de 10

Modelo 2.0
 PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev

Orientao Viso Conceitual em Testes

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.

4.5 Teste de Performance

Verifica o tempo de resposta e o processamento (para diferentes configuraes, cargas de
trabalho, nmero de usurios, tamanho do BD, etc.). Exemplo, recuperar uma conta de usurio
em x segundos ou processar a transao y em x segundos.

4.6 Teste de Volume (carga)

Verifica o comportamento do sistema sob condies de carga de trabalho diferente do normal. O
teste de volume submete grandes quantidades de dados ao sistema para determinar se limites
que causam a falha do software so alcanados.

4.7 Teste de Estresse

Verifica a funcionalidade do sistema em situaes limite de transaes ou fora da tolerncia
esperada. Exemplos so: alta competio por recursos compartilhados como vrios acessos/
transaes no BD ou rede.

4.8 Teste de Configurao ou Portabilidade

Verifica o funcionamento do sistema em diferentes configuraes de hardware e software. Devem
ser testadas:
Compatibilidade do software hardware
Configurao do servidor
Tipos de conexo com a internet
Compatibilidade com o browser

4.9 Teste de Interface com o Usurio

Devem ser testadas:
Aparncia e comportamento da interface
o Como a informao apresentada ao usurio
o Quais controles da interface sero testados (caixa de dilogo, botes, menu)
o Se os nomes das caixas e dilogos so intuitivos e consistentes
Navegao
Adequao a padres
Tempo para aprender como usar o programa

4.10 Teste de Regresso

Reexecuo dos testes feita aps uma manuteno corretiva ou evolutiva. Existem duas
abordagens de testes de regresso: a total, que executa todos os testes desenvolvidos

ori_Visao_Conceitual_Testes.odt 7 de 10

Modelo 2.0
 PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev

Orientao Viso Conceitual em Testes

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.

5 Mitos sobre Teste

Em [1] so encontrados alguns mitos sobre testes de software. Esses mitos so:

Mito 1: preciso testar todas as possibilidades de entradas em um software.

Essa afirmao falsa pelo seguinte motivo: a combinao de todas as possveis entradas de um
software pode resultar em milhares ou milhes de possibilidades. Com isso, a aplicao dessas
combinaes para o exerccio de um software torna o teste invivel. O que se busca com a
atividade de teste de software encontrar a maior quantidade de falhas utilizando um mnimo de
esforo e tempo. Para isso so usadas algumas tcnicas de projeto de casos de testes de
softwares.

Mito 2: Um sistema testado perfeito.

Partindo da inverdade do mito 1, podemos perceber que o mito 2 tambm falso. O motivo que,
visto que no so testadas todas as possibilidades de entradas em um software, o que se pode
afirmar que para aquele determinado conjunto de entradas no existem falhas, mas, para
aquelas entradas que no foram testadas, nada se pode afirmar.

Mito 3: Testes so usados para mostrar que o software no tem falhas.

A atividade de teste de software tem a finalidade de encontrar falhas e no a sua ausncia. Esse
mito cai no mito 2, j que se encontram falhas com um conjunto de dados de teste. A ausncia de
falhas s poderia ser afirmada utilizando-se todas as combinaes possveis de entrada.

Mito 4: Testes precisam ser executados apenas uma ou duas vezes.

Os testes precisam ser repetidos sempre que forem encontradas falhas e algum tipo de correo
for aplicada. Isso acontece porque, alm de precisar testar se aquela correo contm falha,
tambm necessrio testar se aquela correo afetou outra parte do software.

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:

Princpio 1: Uma parte essencial do caso de teste a definio da sada ou resultado

esperado.
O princpio 1 pode induzir a erros quando no acontece. Pode ser bvio que os resultados

ori_Visao_Conceitual_Testes.odt 8 de 10

Modelo 2.0
 PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev

Orientao Viso Conceitual em Testes

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 2: Um programador deveria evitar testar seu prprio cdigo.

O princpio 2 importante no sentido de que o prprio desenvolvedor pode se viciar em seu
cdigo. Isso faz com que ele no mais perceba falhas que para outras pessoas parecem bvias.
Outro motivo para o cumprimento desse princpio que o prprio desenvolvedor pode no querer
encontrar falhas em seu cdigo para que no precise fazer correes. Por esse mesmo motivo
sugerido o princpio 3, tomando agora a aplicao do princpio 2 para um grupo de pessoas. Vale
ressaltar que o princpio 2 vale apenas para testes de alto nvel, ou seja, um desenvolvedor pode
e deve executar e implementar testes de baixo nvel em seu prprio cdigo.

Princpio 3: Uma organizao desenvolvedora de software deveria ter uma equipe prpria
para os testes de alto nvel.

Princpio 4: Os resultados dos testes deveriam ser meticulosamente analisados.

O princpio 4 importante para a deteco dos sintomas das falhas. necessrio para se
conhecer de onde vieram essas falhas e o motivo de sua existncia. Isso ajuda na preveno de
novos defeitos.

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.

Princpio 6: necessrio verificar se um programa no faz o que ele no foi designado a

fazer.

Princpio 7: necessria a documentao do processo de teste.

O princpio 7 necessrio para que, caso haja uma falha do sistema na hora dos testes, aquele
esforo de inveno dos testes seja guardado e executado outra vez. Esse princpio importante
tambm no que diz respeito a testes que precisam ser executados novamente, como testes de
regresso, logo aps terem sido consertados alguns defeitos.

Princpio 8: No se deve planejar um esforo de teste assumindo que erros no vo ser

encontrados.
Os testes devem ser planejados com um cronograma que leva em considerao que algumas
falhas vo ser descobertas e que levam um tempo para serem corrigidas. Isso a importncia do
princpio 8. Deve-se sempre considerar que falhas sempre vo existir.

Princpio 9: A probabilidade da existncia de mais falhas numa seo do programa

ori_Visao_Conceitual_Testes.odt 9 de 10

Modelo 2.0
 PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev

Orientao Viso Conceitual em Testes

proporcional ao nmero de falhas j encontradas naquela seo.

O princpio 9 um fenmeno citado nas referncias e que no se sabe ao certo o porqu dele. A
probabilidade de encontrar erros mostrada no grfico abaixo:

Princpio 10: Os testes deveriam ser integrados num processo de desenvolvimento de

software.
Os testes deveriam ser executados ao longo de todo ciclo de vida de desenvolvimento do
software, no precisando esperar at o final. Isso facilita a depurao dos erros encontrados e o
que fala o princpio 10.

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