Engenharia de Software
com o RUP Workflow de Testes
Parte I
Alexandre Vasconcelos, André Santos,
Augusto Sampaio, Hermano Moura,
Paulo Borba
© Centro de Informática
Universidade Federal de Pernambuco
Objetivos:


Entender os conceitos básicos do workflow de Testes
Entender como ler e interpretar os artefatos gerados
por este workflow
Tópicos Cobertos










Motivação
Introdução
Objetivo dos Testes
Abordagens de Testes
Estratégia de Testes
Estágios de Teste
Ferramentas de Teste
Responsabilidades sobre a Execução dos Testes
Teste x Depuração
Abordagens para a Depuração
Motivação



Existe grande possibilidade de injeção de
falhas humanas no processo de
desenvolvimento de software;
A atividade de teste faz parte da garantia de
qualidade de software (SQA);
Os custos associados às falhas de software
justificam uma atividade de teste cuidadosa e
bem planejada.
Introdução



A atividade de testes pode ser vista como
“destrutiva” ao invés do desenvolvimento que é
“construtivo”;
O engenheiro de software tenta elaborar casos
de teste que têm a intenção de “demolir” o
software (descobrir erros);
É impossível mostrar a ausência de erros.
Objetivo dos Testes



Produzir casos de teste que têm elevada
probabilidade de revelar um erro ainda não
descoberto com uma quantidade mínima de
tempo e esforço;
Comparar o resultado dos testes com os
resultados esperados a fim de produzir uma
indicação da qualidade e da confiabilidade do
software.
O objetivo pode ser alcançado de forma
automática e/ou manual
Abordagens de Teste

Existem basicamente duas abordagens que podem
ser aplicadas a diferentes tipos de teste:
Abordagem funcional (“caixa preta”) - os casos de
teste são gerados a partir de uma análise dos
relacionamentos entre os dados de entrada e saída,
com base nos requisitos levantados com os usuários;
 Abordagem estrutural (“caixa branca”) - os casos de
teste são gerados a partir de uma análise dos
caminhos lógicos possíveis de serem executados, de
modo a conhecer o funcionamento interno dos
componentes do software. No entanto, é impossível
gerar casos de teste para todos os caminhos lógicos.

Estratégia de Teste

Descreve:
 os
passos a serem dados como parte da atividade
de teste;
 quando esses passos serão planejados e
executados;
 esforço, tempo e recursos exigidos.

Incorpora:
 planejamento
de testes;
 projeto de casos de teste;
 execução de teste;
 coleta e avaliação de dados.
Estágios de Teste




Teste de unidades: componentes individuais são
testados para assegurar que os mesmos operam
de forma correta;
Teste de integração: a interface entre as unidades
integradas é testada;
Teste de sistema: os elementos de software
integrados com outros componentes (hardware,
pessoas, etc.) são testados como um todo;
Teste de aceitação (homologação): o software é
testado pelo usuário final.
Teste de Unidade

São testados:
A interface com a unidade para garantir que as
informações fluem para dentro e para fora da mesma;
 Estruturas de dados locais (digitação inconsistente ou
imprópria, inicialização com valores default/outros
valores, overflow/underflow e corretude dos tipos de
dados);
 Caminhos de controle importantes e de tratamento de
erros dentro das fronteiras da unidade (“teste caixa
branca”);
 Condições de limite para garantir que a unidade opera
adequadamente nos limites estabelecidos para
demarcarem ou restringirem o processamento.

Teste de Unidade

O procedimento para teste de unidades pode
ser:
 top-down: as unidades são testadas a partir do topo da
hierarquia. O teste usa software driver (aceita dados do
caso de teste, ativa a unidade a ser testada e imprime
dados relevantes) e stubs (substituem as unidades
subordinadas simulando o acesso às suas interfaces);
 bottom-up: as unidades são testadas a partir do nível
mais básico da hierarquia. O teste usa software driver
para ativar a unidade a ser testada. As unidades já
testadas num nível inferior podem então ser usadas para
testar uma unidade específica no nível superior.
Teste de Integração


Unidades testadas em separado não são
garantidas de funcionarem em conjunto;
A integração deve ser de forma incremental, ou
seja, o programa é construído e testado em
pequenos segmentos.
Teste de Integração

Integração top-down:
 As
unidades são integradas movimentando-se
de cima para baixo na hierarquia de controle,
iniciando-se na unidade de controle principal.

Integração bottom-up:
 As
unidades são integradas movimentando-se
de baixo para cima na hierarquia de controle.
Teste de Sistema


A integração dos componentes de software
com o ambiente operacional é testada;
Tipos de teste:
Teste funcional - a funcionalidade geral do sistema é
testada.
 Teste de recuperação - o software é forçado a falhar de
diversas maneiras para que seja verificado se a
recuperação é adequada. A recuperação pode ser
automática ou exigir intervenção humana;
 Teste de segurança - tenta verificar se todos os
mecanismos de proteção a acesso indevido estão
funcionando satisfatoriamente;

Teste de Sistema

Tipos de Teste (cont.):

Teste de Estresse - o sistema é testado no seu limite
(número de acessos/transações, sobrecarga da
memória/disco);

Exemplo: pode-se desejar saber se um sistema de transações
bancárias suporta uma carga de 100 transações por segundo ou
se um sistema operacional pode manipular 200 terminais
remotos.
Teste de Desempenho - tenta avaliar a performance do
software (principalmente em software de tempo real);
 Teste de Portabilidade - são testes que verificam o grau
de portabilidade do software em diferentes ambientes de
harware/software.

Teste de Aceitação (homologação)

Testes de “caixa preta”que demonstram a
conformidade com os requisitos obtidos do
cliente:
 Requisitos
funcionais;
 Documentação;
 etc.
Teste de Aceitação (homologação)

São realizados pelo usuário. Podem ser de
dois tipos:
 Testes
alfa: feito pelo cliente nas instalações do
desenvolvedor, que observa e registra erros
e/ou problemas;
 Testes beta: feito pelo cliente em suas próprias
instalações, sem a supervisão do
desenvolvedor. Os problemas detectados são
então relatados para o desenvolvedor.
Ferramentas de Teste







Ferramentas de geração de massa de dados;
Ferramentas de teste de API;
Ferramentas de teste de GUI;
Ferramentas de teste de cobertura;
Ferramentas de teste de carga;
Ferramentas de detecção de deadlocks;
Ferramentas de teste de
desempenho/detecção de gargalos
Estágio de Testes x Ferramentas

Teste de unidade/Teste de integração
Ferramenta de teste de API
 Ferramenta de teste de cobertura


Teste de sistema
Ferramenta de teste de carga
 Ferramenta de detecção de deadlocks
 Ferramenta de geração de massa de dados
 Ferramenta de teste de desempenho/gargalos


Teste de homologação

Geralmente é feito de forma manual, e eventualmente
com o auxílio da ferramenta de teste de GUI
Responsabilidades sobre a
Execução dos Testes

Grupo de Desenvolvimento:
Teste de unidades;
 Teste de integração;
 Correção de erros;
 Assessoria ao grupo de teste.


Grupo de Independente de Teste:
Teste de sistema;
 Elaboração de casos de teste;
 Preparação de relatórios sobre a qualidade do software.


Usuário

Teste de aceitação
Teste x Depuração



Quando um caso de teste ou o uso revela um
erro, a depuração é o processo que resulta na
remoção do erro;
Muitas vezes a manifestação externa do erro
não tem uma relação óbvia com a sua causa;
A remoção de um erro pode inserir outros
erros.
Abordagens para a Depuração




Força bruta:
 Exames de listagens de dump;
 Exame de traços de run-time;
 Inserção de instruções “WRITE”.
Backtracking: o programa é rastreado para traz a partir
do local onde apareceu o erro;
Eliminação da causa: Os dados relacionados à uma
provável causa do erro são gerados. Uma hipótese da
causa é formulada e os dados são usados para provar
ou refutar a hipótese;
Ajuda externa.