Testes Orientação Visão Conceitual em Testes Versão 0.3

(1)

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

(2)

PD-DATAPREV

Histórico de Revisões

Data Versão Descrição Autor

23/04/2010 0.1 Versão inicial Fernanda Monteiro

07/10/10 0.2 Verificação ortográfica Ana Eckel

22/10/2014 0.3 Verificação ortográfica 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

(3)

PD-DATAPREV

6 Princípios de Teste... 8 7 Referências... 10

(4)

PD-DATAPREV

1 Finalidade

Definir Abordagens, Níveis e Tipos de Testes. Também tem por finalidade apresentar os principais mitos e princípiosexistentes 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 funciona-lidades 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 tes-tes que conhecem a estrutura de implementação do software e são geralmente aplicados a unida-des pequenas de programas (unidaunida-des não integradas) [3]. Geralmente é unida-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 comporta-mento 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 programado-res já têm o hábito de executarem testes de caixa branca em seus códigos.

Esse tipo de teste precisa garantir [4]:

(5)

PD-DATAPREV

• 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, en-tre 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 necessida-de necessida-de todos os componentes estarem terminados. Os testes necessida-de integração necessida-devem ser necessida- desempe-nhados o mais cedo possível, logo após terem sido aplicados testes de unidade. Testes de inte-graçã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]. Geral-mente durante esse teste são verificados alguns requisitos não funcionais como performance, car-ga, confiabilidade, etc. São aplicados após os testes de unidade e integração terem sido executa-dos e o sistema já tenha em um estado estável. Aqui são aplicaexecuta-dos testes Caixa Preta.

(6)

PD-DATAPREV

Teste baseado em requisitos de alto nível. Os testes de aceitação servem para identificar dis-cordâ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 cla-ras ao analista podem ser não tão clacla-ras ao usuário em campo). Têm como objetivo testar a apli-caçã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 é conduzi-do em um ambiente controlaconduzi-do. Já no teste Beta, o desenvolveconduzi-dor não está presente. O cliente re-gistra todos os problemas encontrados e os relata ao desenvolvedor que fará as modificações ne-cessá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.

(7)

PD-DATAPREV

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

(8)

PD-DATAPREV

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:

(9)

PD-DATAPREV

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.

(10)

PD-DATAPREV

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 Bos-ton, 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. Massa-chusetts: Charles River media, Inc, 2005.