Testes de software

Ian Sommerville

O que faz?
Mostra que um programa faz e o que é proposto a fazer.
Descobrir defeitos do programa antes do uso.

Tem 2 objetivos

 Testes de validação: Demonstrar que o software atende os requisitos do

desenvolvedor para o cliente.

Para...
Software customizados: É feito pelo menos um teste para cada requisito
Softwares genéricos: Testes são feitos para todas as características do sistemas e as
combinações incorporadas aos releases.

 Testes de defeitos: Descobrir situações em que o software se comporta de maneira

incorreta, indesejável e diferente das especificações.
Preocupa-se com a eliminação de comportamentos indesejáveis no sistema.

“Os testes podem mostrar apenas a presença de erros e não sua ausência”

Testes fazem parte do processo de – Validação e verificação (V & V)

Validação: Estamos construindo o produto certo?

Verificação: Estamos construindo o produto da maneira certa?

Objetivos finais da verificação e validação:

Finalidade de software – Importante que seja confiável

Expectativas de usuários – Por causa de softwares defeituosos e não confiáveis usuárias tem
baixas expectativas acerca de qualidade.

Ambiente de marketing – Vendedores levam em conta os produtos concorrentes, preços que

clientes estão dispostos a pagar e prazo necessário para entrega.
 Inspeções
Mais conhecidas como técnica estática de V & V

São usados no código-fonte ou qualquer representação legível do software como requisitos ou

modelos de projeto. Podem ser usados em qualquer estágio do em que técnicas são usadas.

São mais eficazes na descoberta de defeitos do que testes de programas. Mas não podem
substituir os testes porque não consegue-se descobrir defeitos que surgem em interações
inesperadas em diferentes partes do programa, problemas de timing e desempenho do
sistema.

Softwares comerciais tem 3 estágios:

Testes de desenvolvimento:
O sistema é testado durante desenvolvimento para descobrir bugs e defeitos

Testes de release:
Uma equipe de teste independente testa uma versão completa do sistema antes de ser
liberado aos usuários.

Testes de usuário:
Potenciais usuários testam um sistema em seu próprio ambiente. Usado em produtos de
software e para testes de aceitação.

Os processos de testes envolvem uma mistura de testes manuais e automatizados

Teste manual:
o Executa o programa com alguns dados de teste.
o Compara resultados com as expectativas.
o Anota e reporta discrepâncias aos desenvolvedores do programa.

Teste automatizado:
São codificados em um programa que é executado cada vez que o sistema é testado.

Regressão: Reexecução de testes anteriores para verificar se as alterações do programa não

introduziram novos bugs.

Existe:
Casos de teste – Que são especificações das entradas para o teste e a saída esperada do
sistema (resultados do teste), além de uma declaração do que está sendo testado.
Dados de teste – São entradas criadas para testar um sistema.
 Testes de desenvolvimento

Incluem todas as atividades de teste que são realizadas pela equipe de desenvolvimento
do sistema.
Para sistemas críticos, um processo mais forma é usado por um grupo de testes
independente dentro da equipe de desenvolvedores.

Ocorre em 3 níveis de granularidade:

Testes unitários – As unidades individuais do programa ou classes de objetos são testadas
individualmente. Centra-se em testar funcionalidades de objetos ou métodos.

Testes de componentes – Várias unidades individuais são integradas para criar componentes
compostos. Centra-se em testar interfaces dos componentes.

Teste de sistema – Alguns ou todos os componentes de um sistema estão integrados e o

sistema é testado com um todo. Centra-se em testar interações entre os componentes.

Testes unitários
Para fazer precisa-se:
 Testar todas as operações associadas ao objeto.
 Definir e verificar o valor de todos os atributos associados ao objeto.
 Colocar o objeto em todos os estados possíveis, o que significa simular todos os
eventos que causam mudanças de estado.

Estratégias eficazes para o caso de testes:

Teste de partição (Domínio de equivalência): Onde você identifica os grupos de entradas que
possuem características comuns e devem ser tratadas da mesma maneira.

Testes baseados em diretrizes: Você usa as diretrizes de testes para escolher casos de testes.
Refletem experiência anterior dos tipos de erros ocorridos no desenvolvimento de
componentes.

Diretrizes gerais usadas no caso de testes:

 Escolha entradas que forcem o sistema a gerar todas as mensagens de erro;
 Projete entradas que causem overflow de buffers de entrada;
 Repita a mesma entrada ou uma série de entrada inúmeras vezes.
 Obrigue a geração de entradas inválidas.
 Obrigue os resultados de cálculos a serem muito grandes ou muito pequenos.

Testes de componente
Componentes são compostos de vários objetos que se interagem.
Casos de testes normalmente não são aplicados a componentes individuais, mas sim a
interface de componente criada pela combinação de todos eles.
Os tipos de interfaces existentes são:
Interfaces de parâmetro: São interfaces nas quais as referências de dados ou, às vezes,
funções são passadas de um componente para outro. Normalmente métodos de objetos.

Interfaces de memória compartilhada: São interfaces nas quais um bloco de memória é

compartilhado entre os componentes. Os dados são colocados na memória por um subsistema
e recuperados a partir dais por outros subsistemas. Normalmente em sistemas embutidos.

Interfaces de procedimento: São interfaces nas quais um componente encapsula um conjunto

de procedimentos que podem ser chamados por outros componentes. Normalmente objetos e
componentes reusáveis.

Interfaces de passagem de mensagem: São interfaces nas quais um componente solicita um

serviço de outro componente, passando-lhe uma mensagem. Normalmente sistemas
orientado a objetos.

Erros mais comuns no uso de interfaces:

 Mau uso de interface
 Mau entendimento de interface
 Erros de timing.

Teste de sistema
Durante o desenvolvimento, envolve integração de componentes para criação de uma
versão do sistema, em seguida, o teste do sistema integrado. Verifica se os componentes são
compatíveis, se interagem corretamente e transferem dados certos no momento certo.
Teste de sistema centra-se em testar interações entre os componentes e objetos que
compõem o sistema.
E por causa desse foco de interação, teste baseado em caso de uso é uma abordagem
eficaz.

Desenvolvimento dirigido a testes (TDD)

Test-Drive Development é uma abordadem para o desenvolvimento de programas que

se intercalam testes e desenvolvimento de códigos.
Onde é desenvolvido um código de forma incremental e um teste para cada
incremento. E para ir ao próximo incremento o código desenvolvido tem que passar no teste.

O processo para fazer TDD é:

 Comece indentificando o incremento da funcionalidade necessário. Este deve ser
pequeno e implementado em poucas linhas de código.
 Escreva um teste para essa funcionalidade e o implmenta como um teste
automatizado. Relatar se passou ou falhou.
 Execute o teste, junto com todos os outros testes implementados. Inicialmente como
não é implementado a funcionalidade o teste falhará.
  Implemente a funcionalidade e execute novamente o teste. Isso vai envolver
refatoração do código existente.
 Depois de todos os testes executados com sucesso. Caminhe para implementar a
próxima parte da funcionalidade.

Os benefícios do desenvolvimento dirigido a testes:

 Cobertura de código: Em todo segmento de código que foi escrito deve-se ter pelo
menos um teste associado. Para ter certeza que todo o código do sistema foi
executado.
 Teste de regressão: Um conjunto de teste é desenvolvido de forma incremental
enquanto um programa é desenvolvido. Verifica se mudanças no programa
introduziram novos bugs.
 Depuração simplificada: Quando um teste falha, a localização do problema deve ser
óbvia. O código recém-escrito precisa ser modificado e verificado.
 Documentação do sistema: Os testes em si mesmo agem como uma forma de
documentação que descreve o que o código está fazendo.

Teste de release

É o processo de testar uma release em particular de um sistema que se destina para uso
fora da equipe de desenvolvimento.
Centra-se em teste de defeitos – Descobrir bugs no sistema
E teste de validação – Verificar se sistema atende aos requisitos e é bom suficiente para
uso externo.

Testes baseado em requisitos

Princípios de boas práticas de Engenharia de requisitos visa fazer com que os
requisitos sejam testáveis, ou seja, escrito de modo que um teste possa ser projetado para
ele.

Testes de cenários
É uma abordagem de teste de release que você imagina cenários típicos de uso e os
usa para desenvolver casos de teste para o sistema. Um cenário é uma história que
descreve uma maneira de usar o sistema. Deve ser realista e usuários devem se relacionar
com eles.

Testes de desempenho
Uma vez que o sistema tenha sido integrado, é possível testá-lo para propriedades
emergentes, como desempenho e confiabilidade. Precisam ser projetado para assegurar que
sistema possa processar a carga a que se destina.
Suas funções são feitas da seguinte forma:
 Testando o comportamento da falha do sistema. Importante que a falha não cause
corrupção de dados ou perda inesperada de serviços de usuários.
 Estressar o sistema e trazer à luz defeitos que normalmente não são descobertos.

Testes de usuário

É um estágio no processo de teste em que os usuários ou clientes fornecem entradas e

conselhos sobre o teste de sistema.
Pode ser processo formal onde o sistema é aprovado por um fornecedor externo ou
processo informal onde os usuários experimentam um produto de software para ver se
gostam e verificar se faz o que eles precisam.

Existem 3 tipos de teste de usuário:

 Teste alfa – Os usuários do software trabalham com a equipe de desenvolvimento
para testar o software no local do desenvolvedor.
 Teste beta – O 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 – Os clientes testam um sistema para decidir se está ou não pronto
para ser aceito pelos desenvolvedores de sistema e implantar no ambiente do cliente.

Os estágios do teste de aceitação:

 Definir critérios de aceitação: Ocorre no inicio do processo antes do contrato entre
cliente e desenvolvedor.
 Planejar testes de aceitação: Decidir sobre os recursos, tempo e orçamento para os
testes e aceitação bem como estabelecer um cronograma para os testes.
 Derivar testes de aceitação: Depois desses testes tenham sido estabelecidos, eles
precisam ser projetos para verificar se existe ou não um sistema aceitável.
 Executar testes de aceitação: Os testes acordados são executados no sistema. Isso
ocorre no ambiente real que sistema será usado.
 Negociar resultado de tão testes: Se todos os testes de aceitação passarem e não
ocorram problemas no sistema. O teste está completo e sistema pode ser entregue.
 Rejeitar/aceitar sistema: Envolve uma reunião entre os desenvolvedores e o cliente
para decidir se o sistema deve ser aceito. Se não será feito novo desenvolvimento para
corrigir problemas identificados.