PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev
Orientação – Visão Conceitual em Testes
Testes
Orientação – Visão Conceitual em Testes
Versão 0.3
ori_Visao_Conceitual_Testes.odt
Modelo 2.0
1 de 10
PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev
Orientação – Visão Conceitual em Testes
Histórico de Revisões
Data
23/04/2010
07/10/10
22/10/2014
Versão
0.1
0.2
0.3
Descrição
Versão inicial
Verificação ortográfica
Verificação ortográfica
Autor
Fernanda Monteiro
Ana Eckel
Samuel Portela e
Anália Lima
Sumário
1 Finalidade.................................................................................................................................................... 4
2 Técnicas 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 Níveis de Testes de Software (ou Estágios de Teste).................................................................................5
3.1 Teste de Unidade..................................................................................................................................... 5
3.2 Teste de Integração.................................................................................................................................. 5
3.3 Teste de Sistema...................................................................................................................................... 5
3.4 Teste de Aceitação (ou Homologação)..................................................................................................... 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 Recuperação de Falhas............................................................................................................. 6
4.4 Teste de Segurança 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 Configuração ou Portabilidade................................................................................................... 7
4.9 Teste de Interface com o Usuário............................................................................................................. 7
4.10 Teste de Regressão................................................................................................................................ 7
4.11 Reteste................................................................................................................................................... 8
5 Mitos sobre Teste........................................................................................................................................ 8
ori_Visao_Conceitual_Testes.odt
Modelo 2.0
2 de 10
PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev
Orientação – Visão Conceitual em Testes
6 Princípios de Teste...................................................................................................................................... 8
7 Referências................................................................................................................................................ 10
ori_Visao_Conceitual_Testes.odt
Modelo 2.0
3 de 10
PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev
Orientação – Visão Conceitual em Testes
1
Finalidade
Definir Abordagens, Níveis e Tipos de Testes. Também tem por finalidade apresentar os principais
mitos e princípios existentes sobre testes.
2
Técnicas para Projeto de Casos de Teste (ou Abordagens de Teste)
As técnicas de projeto de casos de teste são classificadas em Caixa Branca ou Caixa Preta [3] e
serão apresentadas a seguir.
2.1
Testes de Caixa Preta (Black Box)
Também conhecido como um teste funcional, pois é desempenhado apenas através das funcionalidades do sistema: o testador não está preocupado com o código. O testador fornece as entradas
ao componente ou ao sistema e examina uma saída (que falharão se não estiverem de acordo
com os requisitos do sistema). Acontece quando a codificação termina em alguma fase, e esse
código vai para o grupo de testes. Os defeitos investigados pelos testes Caixa Preta estão em
uma classe de defeitos que os testes Caixa Branca não estão aptos a encontrar. Esses defeitos,
de acordo com [3] são:
•
Funções incorretas ou ausentes;
•
Defeitos de interface;
•
Defeitos de desempenho;
•
Defeitos de inicialização e término.
2.2
Testes de Caixa Branca (White Box)
Também conhecidos como testes estruturais, testes caixa de vidro ou testes caixa clara, são testes que conhecem a estrutura de implementação do software e são geralmente aplicados a unidades pequenas de programas (unidades não integradas) [3]. Geralmente é desempenhado pelo
próprio programador durante a programação.
Esse tipo de teste tem alguns benefícios como: o programador pode testar pequenas partes do
programa (isso faz com que a depuração seja mais fácil); o programador conhece o comportamento esperado do sistema (dessa forma pode identificar melhor as falhas); enfim, conhecendo
melhor o código, ele pode identificar falhas que seriam mais difíceis aos olhos de outros.
Essa prática é considerada complementar ao processo de programação, pois muitos programadores já têm o hábito de executarem testes de caixa branca em seus códigos.
Esse tipo de teste precisa garantir [4]:
•
Que todos os caminhos independentes dentro de um módulo de software tenham sido
exercitados pelo menos uma vez;
•
O exercício de todas as decisões lógicas para valores verdadeiros e falsos;
ori_Visao_Conceitual_Testes.odt
Modelo 2.0
4 de 10
PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev
Orientação – Visão Conceitual em Testes
•
O exercício de todos os laços em suas fronteiras e dentro de seus limites operacionais;
•
O exercício de estruturas de dados internas para garantir a sua qualidade.
3
Níveis de Testes de Software (ou Estágios de Teste)
Um plano de teste, bem como a escolha do grupo de testes, deve ser desenvolvido de acordo, entre outras coisas, com os níveis de teste escolhido para o projeto. Os testes de software podem
ser aplicados no ciclo de desenvolvimento de software através de vários níveis. Esses níveis vão
desde o mais elementar, o de unidade, até o mais geral, o nível de aceitação. Os níveis serão
apresentados em detalhes a seguir. Como os nomes são diferentes dependendo do autor, vamos
utilizar os nomes encontrados no padrão 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 à implementação. Nesse tipo de teste
são geralmente aplicados testes Caixa Branca, mas podem também ser aplicados Testes Caixa
Preta (caso se deseje testar funcionalmente a unidade ou componente).
3.2
Teste de Integração
Tem a finalidade de encontrar falhas quando pedaços de código são integrados, principalmente
falhas de interface [2]. Podem ser aplicados de acordo com duas estratégias [1]:
•
Bottom up: integração de módulos de baixo nível para a formação de módulos maiores;
•
Top down: integração de módulos de alto nível substituindo módulos de baixo nível com
stubs de teste para simular interfaces;
•
Mista: mesclagem das duas estratégias.
Essas estratégias são necessárias para que testes possam ser desempenhados sem a necessidade de todos os componentes estarem terminados. Os testes de integração devem ser desempenhados o mais cedo possível, logo após terem sido aplicados testes de unidade. Testes de integração 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]. Geralmente durante esse teste são verificados alguns requisitos não funcionais como performance, carga, confiabilidade, etc. São aplicados após os testes de unidade e integração terem sido executados e o sistema já tenha em um estado estável. Aqui são aplicados testes Caixa Preta.
3.4
Teste de Aceitação (ou Homologação)
ori_Visao_Conceitual_Testes.odt
Modelo 2.0
5 de 10
PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev
Orientação – Visão Conceitual em Testes
Teste baseado em requisitos de alto nível. Os testes de aceitação servem para identificar discordâncias do software de acordo com esses requisitos. Esse tipo de teste é mais efetivo quando
desempenhado por usuários ou seus representantes em um ambiente mais realístico possível.
Aqui são aplicados testes Caixa Preta.
3.4.1 Testes Alfa e Beta
São processos de teste de validação bastante usados pelos desenvolvedores de software para
descobrir erros que só o usuário final parece ser capaz de descobrir (instruções de uso podem ser
mal interpretadas, combinações estranhas de dados podem ser usadas, saídas que pareciam claras ao analista podem ser não tão claras ao usuário em campo). Têm como objetivo testar a aplicação em um produto.
O teste Alfa é realizado nas instalações do desenvolvedor. O produto é usado pelo cliente com o
desenvolvedor observando e registrando erros e problemas de uso. Esse tipo de teste é conduzido em um ambiente controlado. Já no teste Beta, o desenvolvedor não está presente. O cliente registra todos os problemas encontrados e os relata ao desenvolvedor que fará as modificações necessárias e entrega o produto final ao cliente.
4
Tipos de Testes
4.1
Teste de Sanidade
Com esse tipo de teste é possível avaliar se o build está estável o suficiente para ser submetido a
testes mais detalhados, projetados e implementados para a demanda de testes da iteração (Teste
Funcional). Este tipo de teste também é conhecido como “Smoke test” e tem o propósito de evitar
que se desperdicem recursos de testes com um build não suficientemente estável para testes.
4.2
Teste Funcional
Com esse tipo de teste a funcionalidade geral do sistema em termos de regras de negócio é
testada. Devem ser testadas condições válidas e inválidas. Como exemplo, pode-se citar testar o
Cadastro de um usuário no sistema.
4.3
Teste de Recuperação de Falhas
Com esse tipo de teste o software é forçado a falhar de diversas maneiras para que seja
verificado o seu comportamento, bem como a adequação dos procedimentos de recuperação. A
recuperação pode ser automática ou exigir iteração humana. Como exemplo podemos citar a
interrupção de uma impressão por falta de energia. O sistema deve ser capaz de retornar e
informar ao usuário da impressão pendente.
4.4
Teste de Segurança e Controle de Acesso
ori_Visao_Conceitual_Testes.odt
Modelo 2.0
6 de 10
PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev
Orientação – Visão Conceitual em Testes
Com esse tipo de teste o software é forçado a quebrar um mecanismo de proteção de acesso.
Como exemplo temos: tentar logar no sistema através de um teclado virtual com usuário não
autorizado. O sistema não deve permitir que usuários não autorizados acessem dados sigilosos.
4.5
Teste de Performance
Verifica o tempo de resposta e o processamento (para diferentes configurações, cargas de
trabalho, número de usuários, tamanho do BD, etc.). Exemplo, recuperar uma conta de usuário
em x segundos ou processar a transação y em x segundos.
4.6
Teste de Volume (carga)
Verifica o comportamento do sistema sob condições 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 são alcançados.
4.7
Teste de Estresse
Verifica a funcionalidade do sistema em situações limite de transações ou fora da tolerância
esperada. Exemplos são: alta competição por recursos compartilhados como vários acessos/
transações no BD ou rede.
4.8
Teste de Configuração ou Portabilidade
Verifica o funcionamento do sistema em diferentes configurações de hardware e software. Devem
ser testadas:
• Compatibilidade do software hardware
• Configuração do servidor
• Tipos de conexão com a internet
• Compatibilidade com o browser
4.9
Teste de Interface com o Usuário
Devem ser testadas:
• Aparência e comportamento da interface
o Como a informação é apresentada ao usuário
o Quais controles da interface serão testados (caixa de diálogo, botões, menu)
o Se os nomes das caixas e diálogos são intuitivos e consistentes
• Navegação
• Adequação a padrões
• Tempo para aprender como usar o programa
4.10
Teste de Regressão
Reexecução dos testes feita após uma manutenção corretiva ou evolutiva. Existem duas
abordagens de testes de regressão: a total, que executa todos os testes desenvolvidos
ori_Visao_Conceitual_Testes.odt
Modelo 2.0
7 de 10
PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev
Orientação – Visão Conceitual em Testes
anteriormente sempre que existir uma alteração; a parcial, que executa apenas um subconjunto
de testes somente para as dependências das áreas modificadas.
4.11
Reteste
Execução de testes falhos (somente os falhos) novamente após seu conserto.
5
Mitos sobre Teste
Em [1] são encontrados alguns mitos sobre testes de software. Esses mitos são:
Mito 1: É preciso testar todas as possibilidades de entradas em um software.
Essa afirmação é falsa pelo seguinte motivo: a combinação de todas as possíveis entradas de um
software pode resultar em milhares ou milhões de possibilidades. Com isso, a aplicação dessas
combinações para o exercício de um software torna o teste inviável. O que se busca com a
atividade de teste de software é encontrar a maior quantidade de falhas utilizando um mínimo de
esforço e tempo. Para isso são usadas algumas técnicas 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 também é falso. O motivo é que,
visto que não são testadas todas as possibilidades de entradas em um software, o que se pode
afirmar é que para aquele determinado conjunto de entradas não existem falhas, mas, para
aquelas entradas que não foram testadas, nada se pode afirmar.
Mito 3: Testes são usados para mostrar que o software não tem falhas.
A atividade de teste de software tem a finalidade de encontrar falhas e não a sua ausência. Esse
mito cai no mito 2, já que se encontram falhas com um conjunto de dados de teste. A ausência de
falhas só poderia ser afirmada utilizando-se todas as combinações possíveis 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 correção
for aplicada. Isso acontece porque, além de precisar testar se aquela correção contém falha,
também é necessário testar se aquela correção afetou outra parte do software.
6
Princípios de Teste
Em [5][6] encontram-se alguns princípios que devem ser levados em consideração na hora de se
projetar e desenvolver uma tarefa de teste. Esses princípios podem ser vistos a seguir:
Princípio 1: Uma parte essencial do caso de teste é a definição da saída ou resultado
esperado.
O princípio 1 pode induzir a erros quando não acontece. Pode ser óbvio que os resultados
ori_Visao_Conceitual_Testes.odt
Modelo 2.0
8 de 10
PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev
Orientação – Visão Conceitual em Testes
esperados devem aparecer no caso de teste, mas muitas vezes não é isso que acontece. Pode
acontecer um desconhecimento das saídas esperadas e o testador usar o bom senso na análise.
Princípio 2: Um programador deveria evitar testar seu próprio código.
O princípio 2 é importante no sentido de que o próprio desenvolvedor pode se viciar em seu
código. Isso faz com que ele não mais perceba falhas que para outras pessoas parecem óbvias.
Outro motivo para o cumprimento desse princípio é que o próprio desenvolvedor pode não querer
encontrar falhas em seu código para que não precise fazer correções. Por esse mesmo motivo é
sugerido o princípio 3, tomando agora a aplicação do princípio 2 para um grupo de pessoas. Vale
ressaltar que o princípio 2 vale apenas para testes de alto nível, ou seja, um desenvolvedor pode
e deve executar e implementar testes de baixo nível em seu próprio código.
Princípio 3: Uma organização desenvolvedora de software deveria ter uma equipe própria
para os testes de alto nível.
Princípio 4: Os resultados dos testes deveriam ser meticulosamente analisados.
O princípio 4 é importante para a detecção dos sintomas das falhas. É necessário para se
conhecer de onde vieram essas falhas e o motivo de sua existência. Isso ajuda na prevenção de
novos defeitos.
Princípio 5: Casos de teste devem ser escritos para entradas esperadas bem como não
esperadas.
O princípio 5 diz respeito à robustez do caso de teste. Com as entradas esperadas, busca-se
testar se o programa não faz o que é preciso fazer. Com as entradas não 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 caímos também no princípio 6, que verifica que mesmo que uma entrada seja
absurda, o programa tem que ser robusto o suficiente para suportar.
Princípio 6: É necessário verificar se um programa não faz o que ele não foi designado a
fazer.
Princípio 7: É necessária a documentação do processo de teste.
O princípio 7 é necessário para que, caso haja uma falha do sistema na hora dos testes, aquele
esforço de invenção dos testes seja guardado e executado outra vez. Esse princípio é importante
também no que diz respeito a testes que precisam ser executados novamente, como testes de
regressão, logo após terem sido consertados alguns defeitos.
Princípio 8: Não se deve planejar um esforço de teste assumindo que erros não vão ser
encontrados.
Os testes devem ser planejados com um cronograma que leva em consideração que algumas
falhas vão ser descobertas e que levam um tempo para serem corrigidas. Isso é a importância do
princípio 8. Deve-se sempre considerar que falhas sempre vão existir.
Princípio 9: A probabilidade da existência de mais falhas numa seção do programa é
ori_Visao_Conceitual_Testes.odt
Modelo 2.0
9 de 10
PD-DATAPREV
Processo de Desenvolvimento de Software da Dataprev
Orientação – Visão Conceitual em Testes
proporcional ao número de falhas já encontradas naquela seção.
O princípio 9 é um fenômeno citado nas referências e que não se sabe ao certo o porquê dele. A
probabilidade de encontrar erros é mostrada no gráfico abaixo:
Princípio 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, não precisando esperar até o final. Isso facilita a depuração dos erros encontrados e é o
que fala o princípio 10.
7
Referências
[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 Boston, London: 2002.
[3] Pressman, Roger S. Engenharia de Software. Tradução de José Carlos Barbosa dos Santos.
São Paulo: Pearson Education do Brasil, 1995.
[4] Loveland, Scott et al. Software testing techniques: Finding the Defects that Matter. Massachusetts: 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
Modelo 2.0
10 de 10