TESTES DE SOFTWARE – CONCEITOS GERAIS

O processo de teste tem dois objetivos distintos:

1. Demonstrar ao desenvolvedor e ao cliente que o software atende a seus requisitos; e

Leva a testes de validação, nos quais se espera que o sistema execute corretamente usando
determinado conjunto de casos de teste que refletem o uso esperado do sistema.

2. Descobrir situações em que o software se comporta de maneira incorreta, indesejável ou de forma

diferente das especificações
Leva a testes de defeitos, nos quais os casos de teste são projetados para expor os defeitos. Estes
testes podem ser deliberadamente obscuros e não precisam refletir com precisão a maneira como o
sistema costuma ser usado.

“Os testes mostram apenas a presença de erros, mas não são capazes
de mostrar a ausência deles. Assim, se o software não passar no teste,
sabe-se que ele possui erros. Contudo, se passar, isso não significa
necessariamente que não exista nenhum erro, mas apenas que não foi
possível detectar todos os defeitos.”

VALIDAÇÃO E VERIFICAÇÃO

O objetivo da Verificação é checar se o software atende a seus requisitos funcionais e não funcionais.

O objetivo da Validação é garantir que o software atenda às expectativas do cliente. Ele vai além da
simples verificação de conformidade com as especificações, pois tenta demonstrar que o software faz o
que o cliente espera que ele faça.

Inspeções e Revisões

As inspeções centram-se principalmente no código-fonte de um sistema, mas qualquer representação

legível do software, como seus requisitos ou modelo de projeto, pode ser inspecionada.

1. Inspeções não são influenciadas por erros de execução

2. Versões incompletas de um sistema podem ser inspecionadas sem custos adicionais.
3. Pode considerar atributos de qualidade de um programa, como conformidade com padrões,
manutenibilidade, código “sujo” entre outros.

Modelo V
O modelo V é um modelo de desenvolvimento no qual se dá muita atenção aos testes.
 ESTÁGIOS DE TESTES

• Geralmente, o sistema de software comercial tem de passar por três estágios de teste:

1) Testes em desenvolvimento: em que o sistema é testado durante o desenvolvimento para descobrir

bugs e defeitos.

2) Testes de release: em que uma equipe de teste independente testa uma versão completa do sistema
antes que ele seja liberado para os usuários.

3) Testes de usuário: em que os usuários ou potenciais usuários de um sistema testam o sistema em

seu próprio ambiente.

Estágio Tipo Finalidade

Desenvolvimento Unitário Ocorre durante o desenvolvimento para

Componentes descobrir bugs e defeitos
Sistema

Release Baseado em Requisitos Equipe de teste independente testa uma

Cenário versão completa do sistema antes que ele
Desempenho seja liberado para os usuários.

Usuário Alfa Usuários ou potenciais usuários de um

Beta sistema testam o sistema em seu próprio
Aceitação ambiente

TESTE EM DESENVOLVIMENTO

• Realizado pelo próprio programador.

• Pode ser realizado em pares.
• Para sistemas críticos são usadas equipes específicas para testes.

Teste Unitário:
– As unidades individuais de programa ou classes de objetos são testadas individualmente.

Teste de Componentes:
– Várias unidades individuais são integradas para criar componentes compostos.

Testes de Sistemas:
– Alguns ou todos os componentes de um sistema estão integrados e o sistema é testado como um todo.

Modelo Tradicional de Testes

 TESTE DE RELEASE

Existem duas diferenças entre o teste de release e sistema:

1) Uma equipe separada, que não esteve envolvida no desenvolvimento do sistema, deve ser
responsável pelo teste de release.
2) Testes de sistema feitos pela equipe de desenvolvimento devem centrar-se na descoberta de bugs no
sistema (teste de defeitos). O objetivo do teste de release é verificar se o sistema atende a seus
requisitos e é bom o suficiente para uso externo (teste de validação).

CAIXA-PRETA E CAIXA-BRANCA

Caixa-preta: não é necessário nenhum conhecimento de como funciona o sistema.

Caixa-branca: o código é visto e considerado durante os testes.

Obs: O teste de release costuma ser um processo de teste de caixa preta, no qual os testes são
derivados da especificação de sistema; também chamado de teste funcional, onde a preocupação é a
funcionalidade e não a implementação.

Testes baseados em requisitos:

– É uma abordagem sistemática para projeto de casos de teste em que você considera cada requisito e
deriva um conjunto de testes para eles; são mais uma validação do que um teste de defeitos.

Testes de cenário:
– Teste de cenário é uma abordagem de teste de release em que você imagina cenários típicos de uso e
os usa para desenvolver casos de teste para o sistema.

Testes de desempenho:
– Uma vez que o sistema tenha sido totalmente integrado, é possível testá-lo para propriedades
emergentes (RNF), como desempenho e confiabilidade.

TESTE DE USUÁRIO

Após passar pelas fases de desenvolvimento e release iniciam-se os testes de usuário, que são muito
importantes, pois os softwares são desenvolvidos para os usuários. Então, é imprescindível que exista o
momento de envolvê-lo nos testes.

Teste Alfa
– Tipo de teste onde os usuários do software trabalham com a equipe de desenvolvimento para
testar o software no local do desenvolvedor.

Teste Beta
– Um release do software é disponibilizado aos usuários para que possam experimentar e levantar os
problemas que eles descobriram com os desenvolvedores do sistema.

Teste de Aceitação
– É um tipo de teste de usuário, no qual o cliente testa, formalmente, o sistema para decidir se ele deve
ser aceito por parte do fornecedor do sistema ou se é necessário um desenvolvimento adicional.
 TIPOS

Modelo V

• Aceitação: conduzido pelo cliente voltado para empregar todos os fatores e funções requisitados.

• Sistema: avalia se os requisitos foram atendidos para o sistema completo (ou incremento de software)

• Integração: realizado à medida que o sistema é construído, analisando a integração entre os

componentes compostos.

• Unidade: menor unidade, métodos, funções ou componentes simples.

PSEUDOCONTROLADOR
Devido ao fato de um componente não ser um programa independente (stand-alone), deve ser
desenvolvido um pseudocontrolador (driver) e/ou um pseudocontrolado (stub) para cada teste de
unidade.

TESTE DE INTEGRAÇÃO

É uma técnica sistemática para construir a arquitetura de software ao mesmo tempo que conduz testes
para descobrir erros associados com as interfaces.

O teste de integração funciona melhor quando são feitos incrementos, isto é, ao desenvolver uma nova
unidade, já roda o teste de integração.

Integração Incremental
É o oposto da abordagem big bang. O programa é construído e testado em pequenos incrementos, em
que os erros são mais fáceis de isolar e corrigir.
Teste de Regressão
Sempre que o software é corrigido, algum aspecto da configuração do software (o programa, sua
documentação, ou os dados que o suportam) é alterado.

Ajuda a garantir que as alterações (devido ao teste ou por outras razões) não introduzem
comportamentos indesejados ou erros adicionais.

Teste Fumaça
É projetado como um mecanismo de marca-passo, ou seja, ele monitora constantemente e avisa
sobre a ocorrência de problemas graves, para projetos com prazo crítico, permitindo que a equipe de
software avalie o projeto frequentemente.
Pode ser caracterizado como uma estratégia de integração rolante.

O software é recriado (com novos componentes acrescentados) e o teste de fumaça é realizado todos os
dias. A finalidade deverá ser descobrir erros “bloqueadores” (showstopper) que apresentam a mais alta
probabilidade de atrasar o cronograma.

Contexto de Orientação a Objetos

O teste de classe para software OO é o equivalente ao teste de unidade para software convencional.

Teste de Validação
Como todas as outras etapas de teste, a validação tenta descobrir erros, mas o foco está no nível de
requisitos — em coisas que ficarão imediatamente aparentes para o usuário final.

Teste Alfa ocorre com alguns usuários selecionados dentro do ambiente do desenvolvedor e Beta são
versões beta do software para um público no ambiente do usuário e tem como finalidade encontrar erros
nas diversas plataformas onde o software irá funcionar.

TESTE DE SISTEMA

Uma série de diferentes testes cuja finalidade primária é exercitar totalmente o sistema. Embora cada um
dos testes tenha uma finalidade diferente, todos funcionam no sentido de verificar se os elementos do
sistema foram integrados adequadamente e executam as funções a eles alocadas.

Recuperação: força o software a falhar de várias formas e verifica se a recuperação é executada

corretamente. Se a recuperação for automática (executada pelo próprio sistema), a reinicialização, os
mecanismos de verificação, recuperação de dados e reinício são avaliados quanto à correção. Se a
recuperação requer intervenção humana, o tempo médio de reparo (mean-time-to-repair-MTTR) é
avaliado para determinar se está dentro dos limites aceitáveis.

Segurança: tenta verificar se os mecanismos de proteção incorporados ao sistema vão de fato

protegê-lo contra acesso indevido. O papel do criador do sistema é tornar o custo da invasão maior do
que o valor das informações que poderiam ser obtidas.

Esforço (estresse): servem para colocar os programas em situações anormais. Essencialmente, o

testador que executa teste por esforço pergunta: “Até onde podemos forçar o sistema até que ele falhe?”

Desempenho: para sistemas em tempo real e embutidos, um software que execute a função necessária,
mas não esteja em conformidade com os requisitos de desempenho é inaceitável. Isto é, frequentemente
é necessário medir a utilização dos recursos (por exemplo, ciclos de processador) de forma precisa.
Disponibilização (configuração): examina todos os procedimentos de instalação e software
especializado de instalação (por exemplo, os “instaladores”) que serão usados pelos clientes e toda a
documentação que será usada para fornecer o software para os usuários finais.

Processo de depuração
O processo de depuração é a análise do código em pontos específicos para poder identificar onde estão
os erros.

DEFINIÇÕES
Os termos teste funcional e teste estrutural são às vezes usados em lugar de teste caixa-preta e teste
caixa-branca, respectivamente.

TESTE CAIXA BRANCA

Caminho Básico
Casos de teste criados para exercitar o conjunto básico. Executam com certeza todas as instruções de
um programa pelo menos uma vez durante o teste.

Estrutura de Controle

1 – Condição Método de projeto de caso de teste que exercita as condições lógicas contidas em um
módulo de programa. Uma condição simples é uma variável booleana ou uma expressão relacional.

2 – Fluxo de Dados Uma estratégia simples de teste de fluxo de dados é requerer que toda cadeia
“Definição-Uso (DU)” seja coberta pelo menos uma vez. É irreal supor que o teste de fluxo de dados será
usado extensivamente ao se testar um grande sistema. No entanto, ele pode ser usado especificamente
em áreas do software que sejam suspeitas.

3 – Ciclo O teste de ciclo é uma técnica de teste caixa-branca que focaliza exclusivamente a validade
das construções de ciclo, quando há o loop.

TESTE CAIXA PRETA

Com base em grafo - Começa criando um grafo de objetos importantes e suas relações e então
imaginando uma série de testes que abrangerá o grafo de forma que cada objeto e relação sejam
exercitados e os erros sejam descobertos.

Particionamento de equivalência - Método de teste caixa-preta que divide o domínio de entrada de um

programa em classes de dados a partir das quais podem ser criados casos de teste.