Você está na página 1de 181

Pós-graduação em Análise e Gerência de Sistemas.

Testes de Software

Por: Guilherme Motta – MSC / PMP / CTFL


gmotta@skydome.com.br
Boas Vindas

• Qual o seu nome?


• Qual a sua atividade profissional?
• Já trabalhou com Testes de Software?

Guilherme Motta 2
Programação do Curso

Aula Data Programação


1 27/02/2010 1 - Fundamentos de Teste de Software:
(manhã) 2 - Verificação e Validação;
3 - Teste de Software e o Ciclo de Vida do Software;
2 06/03/2010 4 - Técnicas para Testes Estáticos;
(manhã) 5 - Fundamentos do Processo de Testes de Software;
6 - Técnicas de Modelagem de Testes de Software;
3 06/03/2010 7 - Gerenciamento de Testes de Software;
(tarde) 8 - Ferramentas de Suporte aos Testes de Software;
9 - Desenvolvimento Baseado em Testes (TDD – Test Driven Development);
4 13/03/2010 10 - Central de Testes;
(manhã) 11 - Modelos de Maturidade em Testes de Software;
12 – Prova Final.

Guilherme Motta
1 – Fundamentos de Testes de Software

Guilherme Motta 4
Qual o objetivo dos testes?

• Executar o produto de software com o intuito de detectar a presença


de falhas.

 [Myers]

• Mostrar a presença de falhas em um software, mas nunca a sua


ausência.

 [Dijkstra]

• Executar um sistema ou componente sob condições especificas para


detectar diferenças entre os resultados obtidos e os esperados.

 [IEEE]

Guilherme Motta 5
Quando começam os testes?

• As atividades de testes devem ser integradas às atividades de


desenvolvimento.

• As atividades de teste devem ser iniciadas junto as atividades de


desenvolvimento.

• Procedimentos de teste devem ser descritos desde a fase de


especificação.

Guilherme Motta 6
Quando terminam os testes?

Quando realizamos testes, como saber se já testamos o suficiente?


Respostas pragmáticas:
• Você jamais terá completado a atividade de teste, a carga
simplesmente transfere-se do projetista para o cliente.
• Quando estiver sem tempo ou sem dinheiro.

Respostas analíticas:
• Com planejamento, identificando as funções de maior impacto
para o cliente e executando todo o ciclo de testes para essas
funções.
• Avaliando e priorizando os riscos referentes aos Testes de
Software.

Guilherme Motta 7
Quando terminam os testes?

Modelo Logarítmico do Tempo de Execução de Poisson.


A intensidade de erros real pode ser traçada em relação a curva prevista.

Guilherme Motta 8
Motivação para realização de Testes de Software

• Existe grande possibilidade de injeção de falhas humanas no processo


de desenvolvimento de software;

• O processo de testes faz parte da garantia de qualidade de software


(SQA);

• Os custos associados às falhas de software justificam um processo de


testes cuidadoso e bem planejado;

• Do ponto de vista psicológico, o teste de software é uma atividade com


um certo viés destrutivo, ao contrário de outras atividades do processo
de software.

Guilherme Motta 9
Finalidade dos Testes de Software

• Verificar se todos os requisitos do sistema foram corretamente implementados;

• Assegurar, na medida do possível, a qualidade do software produzido;

• Reduzir custos de manutenção corretiva e retrabalho;

• Assegurar a satisfação do cliente com o produto desenvolvido;

• Produzir casos de teste que tenham 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;

• Verificar a correta integração entre todos os componentes do software.

Guilherme Motta 10
Princípios [Myers79]

• Caso de teste = entrada (dados de teste) + saída esperada;

• Dados de teste devem ser definidos para dados válidos, inválidos e


inoportunos;

• Evite testar seus próprios programas, a menos que seja com auxílio
de uma ferramenta;

• Determine se o software faz o que é esperado, mas também se não


faz algo indesejável;

• Nunca planeje testes assumindo que falhas não serão encontradas.

Guilherme Motta 11
Princípios [Myers79]

• Nunca jogue fora casos de teste, a não ser que esteja jogando o
software fora também;

• A probabilidade de detectar falhas em uma parte do software é


proporcional ao nº de falhas já detectadas;

• Um bom caso de teste é aquele que tem alta probabilidade de


detectar novas falhas;

• Verifique cuidadosamente os resultados de cada caso de teste;

• Testes devem ser planejados desde o início do desenvolvimento.

Guilherme Motta 12
Perspectiva de Teste
• Bons testadores necessitam de um conjunto especial de habilidades.
Um testador deve abordar um software com a atitude de questionar
tudo sobre ele (McGregor e Sykes, 2001).

• A perspectiva de teste é, um modo de olhar qualquer produto de


desenvolvimento e questionar a sua validade.

• Habilidades requeridas na perspectiva de teste:


 Querer prova de qualidade,

 Não fazer suposições,

 Não deixar passar áreas importantes,

 Procurar ser reproduzível.

Guilherme Motta 13
Perspectiva de Teste

• A perspectiva de teste requer que um fragmento de software


demonstre não apenas que ele executa de acordo com o
especificado, mas que executa apenas o especificado
(McGregor e Sykes, 2001).

• O software faz o que deveria fazer e somente isso?

Guilherme Motta 14
Prática 1 – Fundamentos de Teste de Software

1 – No contexto de Fundamentos de Teste de Software conceitue, ou responda, os itens


abaixo relacionados:
 Testes de Software;
 Casos de Teste;
 Resultado Esperado;
 Falha e Defeito (Qual a diferença?);
 Visão Construtiva e Visão Destrutiva (Qual a diferença?);
 Dados de Teste:
 Válidos;
 Inválidos;
 Inoportunos.
 Testes Positivos e Testes Negativos (Qual a diferença?);
 Perspectiva de Teste.

Guilherme Motta 15
2 – Verificação e Validação – V&V

Guilherme Motta 16
Verificação & Validação

• A atividade de teste de software é um elemento de um tema mais amplo


chamado Verificação e Validação (V&V).

• As atividades de Verificação e Validação (V&V) visam garantir,


respectivamente, que:

Verificação - o software está sendo desenvolvido corretamente,


Validação - o software que está sendo desenvolvido é o software
correto.

Guilherme Motta 17
V&V: Estática x Dinâmica
• As atividades de V&V costumam ser divididas em estáticas e dinâmicas:

 As estáticas não requerem a execução ou mesmo a existência de um programa


ou modelo executável para serem realizadas.

 As dinâmicas se baseiam na execução de um programa ou modelo (Delamaro et


al., 2007).

• Inspeções de software (V & V estática):

 Análise da documentação e código fonte do software;

 Pode ser auxiliado por ferramentas de depuração.

• Testes de software (V & V dinâmica):

 O programa ou um protótipo devem ser executados;

 Casos de testes deve ser elaborados: dados de entrada e comportamento


esperado.

Guilherme Motta 18
V&V: Estática x Dinâmica

Guilherme Motta 19
Plano de V&V

Guilherme Motta 20
Prática 2 – Verificação e Validação

1 – No contexto da Verificação e Validação conceitue, ou responda, os itens abaixo


relacionados:

 Verificação;

 Validação;

 Atividade Dinâmicas e Estáticas;

 Quando deve ocorrer a Verificação e a Validação?

 O que deve ser Verificado e Validado?

Guilherme Motta 21
3 – Teste de Software e o Ciclo de Vida do Software

Guilherme Motta 22
Modelo em V

Guilherme Motta 23
Ciclo de Desenvolvimento e Ciclo de Testes de Software

Os itens abaixo indicam as características para um bom teste para


qualquer modelo de ciclo de vida:
• Para todas as atividades do desenvolvimento há uma atividade de
teste correspondente.
• Cada nível de teste tem um objetivo específico daquele nível.
• A análise e modelagem do teste para um dado nível de teste devem
começar durante a atividade de desenvolvimento correspondente.
• Testadores devem se envolver na revisão de documentos o mais
cedo possível utilizando as primeiras versões disponíveis ao longo
ciclo de desenvolvimento.

Guilherme Motta 24
Ciclo de Desenvolvimento e Ciclo de Testes de Software

Guilherme Motta 25
Classificação dos Testes de Software
• Podemos classificar os métodos de teste de acordo com suas
características básicas.
• Existem testes :
• Caixa Preta e Caixa Branca;
• Estáticos e Dinâmicos;
• Testes Estruturais e Funcionais;
• Testes de Unidade e Integração;
• Testes de Validação;
• Testes Alfa e Beta;
• Testes de Recuperação;
• Testes de Segurança;
• Testes de Regressão;
• Testes de Estresse e Testes de Desempenho.

Guilherme Motta 26
Descrição (1)
Pode-se descrever cada um destes testes de software da seguinte
forma:

• Testes Caixa Branca (White Box)


• Visam avaliar o código, a lógica interna do componente
codificado, as configurações e outros elementos técnicos.

• Testes Caixa Preta (Black Box)


• Visam verificar a funcionalidade e a aderência aos requisitos,
em uma ótica externa ou do usuário, sem se basear em
qualquer conhecimento do código e da lógica do componente
testado.

Guilherme Motta 27
Descrição (2)
• Testes Estáticos ou Testes Humanos
 Não são feitos através da execução real do programa, mas sim
através da execução conceitual do mesmo.
 Métodos classificados como estáticos são o de walkthrough,
inspeções e peer rating.
 São utilizados principalmente para validar as primeiras etapas do
projeto, como o de elicitação de requisitos, projeto preliminar e projeto
detalhado, podendo ser usados para validar o código também.

• Testes Dinâmicos
 Requerem que o programa seja executado, e por isso seguem o
modelo tradicional de teste de programa, no qual o programa é
executado com alguns casos de teste e os resultados da execução
são examinados para verificar se o programa operou de acordo com o
esperado.
 São usados principalmente na validação do código em módulos e na
integração geral do sistema.

Guilherme Motta 28
Descrição (3)
• Testes Funcionais
 Características do domínio do negócio são examinados, para que se tente
descobrir formas de derivar um conjunto de dados de teste representativo que
consiga exercitar completamente a estrutura do sistema.
 Os dados de teste precisam ser derivados de uma análise dos requisitos
funcionais e incluir elementos representativos de todas as variáveis do
domínio.
 Este conjunto deve incluir tanto dados de entrada válidos quanto inválidos.
• Testes Estruturais
 Diferentemente dos testes funcionais, que se preocupam com a função que o
programa desempenha sem se preocupar com como a função foi
implementada, o teste estrutural enfoca a implementação e a estrutura da
função.
 Embora geralmente usado durante a fase de codificação, testes estruturais
devem ser usados em todas as fase do ciclo de vida do software nas quais o
software é representado formalmente. A intenção do teste estrutural é
encontrar dados de teste que terão cobertura suficiente de todas as estruturas
presentes na representação formal.

Guilherme Motta 29
Descrição (4)
• Testes de Unidade
 O Teste de Unidade concentra-se no esforço de verificação da menor unidade de
projeto de software, o módulo (Classe, Componente, Função ...)
 Através do uso da descrição do projeto detalhado como guia, caminhos de
controle importantes são testados para descobrir erros dentro das fronteiras do
módulo. Este teste baseia-se sempre em caixa branca, e esse passo pode ser
realizado em paralelo para múltiplos módulos. Nos testes de unidade são
verificados:
1. A interface com o módulo é testada para ter a garantia de que as informações fluem para dentro e para
fora do módulo que se encontra em teste;
2. A estrutura de dados local é examinada para ter a garantia de que os dados armazenados
temporariamente mantêm sua integridade durante todos os passos de execução de um algoritmo;
3. As condições de limite são testadas para ter a garantia de que o módulo opera adequadamente nos
limites estabelecidos para demarcarem ou restringirem o processamento;
4. Todos os caminhos independentes através da estrutura de controle são exercitados para ter a garantia
de que todas as instruções de um módulo foram executadas pelo menos uma vez;
5. Todos os caminhos de tratamento de erros são testados.
6. O procedimento comumente utilizado para teste de unidade envolve o desenvolvimento de um
software driver e/ou stub para cada unidade de teste.
• Driver é um programa principal que aceita dados de caso de teste, passa tais dados para o módulo a ser testado e imprime os dados relevantes.
• Os stubs servem para substituir módulos que estejam subordinados ao módulo a ser testado. Um stub ou programa simulado, usa a interface do
módulo subordinado, pode fazer manipulação de dados mínima, imprime verificação de entrada e retorna.

Guilherme Motta 30
Descrição (5)
• Testes de Integração
 O teste de integração é uma técnica sistemática para a construção da
estrutura de programa, que ao mesmo tempo procura descobrir erros
relacionados à interface.
 O objetivo é, a partir dos módulos testados no nível de unidade, construir
a estrutura do programa que foi determinada pelo projeto.
 A integração pode ser incremental ou não-incremental:
A integração não-incremental, executada através da abordagem do big-bang,
combinando-se antecipadamente todos os módulos não costuma ser eficaz,
dada a amplitude de um teste do programa como um todo.
Já a integração incremental é mais eficiente, podendo seguir a abordagem
top-down ou a bottom-up:

Guilherme Motta 31
Descrição (5)
• Testes de Integração Incremental

Guilherme Motta 32
Descrição (6)
• Testes de Integração
 Já a integração incremental é mais eficiente, podendo seguir a
abordagem top-down ou a bottom-up:
Top-down - o processo de integração se dá em uma série de cinco passos:
– 1) o módulo de controle principal é usado como um driver de teste e os stubs são subtituídos
para todos os módulos diretamente subordinados ao módulo de controle principal;
– 2) dependendo da abordagem de integração escolhida, os stubs subordinados são substituídos,
um de cada vez, por módulos reais;
– 3) testes são realizados à medida que cada módulo é integrado;
– 4) durante a conclusão de cada conjunto de testes, outro stub é substituído pelo módulo real;
– 5) teste de regressão (isto é, a realização de todos ou de alguns dos testes anteriores) pode ser
realizado a fim de garantir que novos erros não tenham sido introduzidos.

A maior desvantagem da integração top-down é a necessidade de ter stubs e


as dificuldades de teste resultantes que podem estar associadas a eles e o
overhead causado pela necessidade de desenvolvimento de stubs e drivers.

Guilherme Motta 33
Descrição (6)
• Testes de Integração Incremental Top Down

Guilherme Motta 34
Descrição (7)
• Testes de Integração
 Já a integração incremental é mais eficiente, podendo seguir a
abordagem top-down ou a bottom-up:
Bottom-up - inicia a construção e os testes com módulos atômicos, ou seja,
módulos localizados nos níveis mais baixos da estrutura do programa.
Uma vez que os módulos são integrados de baixo para cima, o
processamento exigido para os módulos subordinados em determinado nível
está sempre disponível, e a necessidade de stubs é eliminada.
Uma estratégia de integração bottom-up pode ser implementada com os
seguintes passos:
– 1) módulos de baixo nível são combinados em clusters (ou construções) que executam uma
subfunção de software específico;
– 2) Um driver (um programa de controle para teste) é escrito para coordenar a entrada e a saída
do caso de teste;
– 3) O cluster é testado;
– 4) Os drivers são removidos e os clusters são combinados ao se dirigir para cima na estrutura de
programa.

A principal desvantagem da integração bottom-up é que o programa não


existe como entidade até que o último módulo seja adicionado.

Guilherme Motta 35
Descrição (7)
• Testes de Integração Incremental Botton-up

Guilherme Motta 36
Descrição (7)
• Testes de Validação
 O teste de validação pode ser considerado bem sucedido quando
o software funciona da maneira esperada pelo cliente.
 Ou seja verifica-se se o produto certo foi construído, seguindo a
especificação de requisitos do software.
 A validação do software, na fase de testes, é realizada por meio
de uma série de testes de caixa preta que demonstram a
conformidade com os requisitos.
 Testes de validação podem e devem ser feitos na etapa de
projeto, podendo ser usada uma técnica formal e estática para as
fases iniciais.
 Um plano de teste esboça as classes de teste a serem realizadas
e um procedimento de teste define os casos de teste específicos
que serão usados para demonstrar a conformidade com os
requisitos.

Guilherme Motta 37
Descrição (8)
• Testes Alfa e Beta
 São os testes de aceitação, feitos pelo usuário, que dificilmente opera o
sistema da forma prevista, e visam descobrir erros cumulativos que
poderiam deteriorar o sistema no decorrer do tempo.
 O teste alfa é executado por um cliente nas instalações do
desenvolvedor. Esse teste é usado num ambiente natural com o
desenvolvedor acompanhando e registrando erros e problemas de uso,
em ambiente controlado.
 Já o teste beta é realizado em uma ou mais instalações do cliente pelo
usuário final do software.
 Geralmente o desenvolvedor não está presente. Assim, o teste beta é
uma aplicação viva do software, num ambiente que não pode ser
controlado pelo desenvolvedor
 Os problemas são registrados pelo usuário e repassados regularmente
ao desenvolvedor, que corrige o software antes de lançar o produto para
venda.

Guilherme Motta 38
Descrição (9)
• Teste de Segurança
 O teste de segurança tenta verificar se todos os mecanismos de proteção
embutidos em um sistema o protegerão de acessos indevidos.
 Todas as formas de ataque devem ser simuladas, o analista pode tentar adquirir
senhas via contatos externos, atacar o sistema com software customizado
projetado para derrubar quaisquer defesas que tenham sido construídas, pode
desarmar o sistema negando serviço a outros, etc...
 O papel do projetista é tornar o acesso indevido às informações mais caro do que
o valor da informação que será obtida.
• Teste de Regressão
 A cada novo módulo adicionado ou alterado, o software se modifica. Essas
modificações podem introduzir novos defeitos, inclusive em funções que
previamente funcionavam corretamente.
 Assim, é necessário verificar se as alterações efetuadas estão corretas e,
portanto, deve-se reexecutar algum subconjunto de testes que já foi conduzido
para garantir que as modificações não estão propagando efeitos colaterais
indesejados (Pressman, 2006).

Guilherme Motta 39
Descrição (10)
• Testes de Estresse
 O teste de estresse é feito para confrontar o sistema com situações
anormais. O teste de estresse executa o sistema de forma que exige
recursos de infraestrutura em quantidade, freqüência ou volume
anormais.

• Teste de Desempenho
 O teste de desempenho é idealizado para testar o desempenho de run-
time do software dentro do contexto de um sistema integrado.
 O teste de desempenho ocorre dentro do contexto de um sistema
integrado e ao longo de todos os passos do processo de teste.
 Algumas vezes os testes de desempenho são combinados com os de
estresse e freqüentemente utiliza-se instrumentação de hardware e de
software, para medição dos recursos com ciclo de processador, por
exemplo.

Guilherme Motta 40
Fases de Teste

• De uma forma geral, pode-se estabelecer como fases testes de


software (Delamaro et al., 2007):

 Teste Estático;
 Teste Funcional;
 Teste de Unidade;
 Teste de Integração;
 Teste de Sistema;
 Teste de Homologação (Aceitação).

Guilherme Motta 41
Quadro Resumo
Fases Tipos de Testes Características

Testes Teste Unitário •Estrutura Interna; • Caixa Branca e Caixa Preta;


de •Funcionalidade; • Testa partes do software;
•Usabilidade; • Requer conhecimento da estrutura interna;
Baixo •Segurança. • Executada pelo desenvolvedor.
Nível
Teste Integrado •Interfaces; • Caixa Branca e Caixa Preta;
•Dependências entre componentes. • Testa integrações entre partes do software;
• Requer conhecimento da arquitetura interna do software;
• Executada pelo desenvolvedor.

Testes Teste Funcional •Requisitos Funcionais; • Caixa Preta;


de Alto •Usabilidade. • Os testes são aplicados em partes funcionais do software;
• Não requer conhecimento da estrutura interna do software;
Nível •Requer ambiente próprio (ambiente de teste), semelhante ao de
produção;
• Executada pelo Analista de Qualidade.
Teste de Sistema •Requisitos Funcionais; • Caixa Preta;
•Requisitos Não Funcionais: • Os testes são aplicados no software como um todo;
oCarga (estresse); • Não requer conhecimento da estrutura interna do software;
oPerformance; • Requer ambiente muito semelhante ao da produção (Ambiente de
oSegurança; Homologação);
oInstalação; • Executada pelo Analista de Teste e Responsáveis Técnicos do
oetc. projeto / manutenção.

Homologação •Requisitos Funcionais; • Caixa Preta;


•Usabilidade; • Os testes são aplicados no software como um todo;
•Requisitos Não Funcionais: • Não requer conhecimento da estrutura interna do software;
oCarga (estresse); • Requer ambiente muito semelhante ao da produção (Ambiente de
oPerformance; Homologação);
oSegurança; • Executada pelo Cliente e Analista de Negócio.
oInstalação;
oetc.
Guilherme Motta 42
Prática 3 – Teste e o Ciclo de Vida do Software

1 – Qual o principal objetivo da representação do Modelo em V?

2 – Ciclo de Vida de Teste – Além de identificar defeitos e falhas, informe qual outro objetivo
pode ser atribuído ao Ciclo de Vida de Teste?

3 – Qual a diferença entre Testes “Caixa Preta” e “Caixa Branca”? Cite exemplos.

4 – Apresente um exemplo prático, para cada um dos tipos de teste apresentados, que
comprove a real necessidade de execução.

5 – Cite as características principais dos Testes de Integração Incremental.

6 – Analise a situação abaixo e responda:

Guilherme Motta 43
4 – Técnicas para Testes Estáticos

Guilherme Motta 44
Técnicas de Teste Estático

• As técnicas de teste estático se diferem dos testes de software por


não requerem a execução do software que está sendo testado.
• Este tipo de verificação representa a forma de testar (revisar)
artefatos gerados ao longo do ciclo de vida do software (incluindo o
código) antes e/ou após a execução dos testes de software (testes
dinâmicos).
• Defeitos detectados durante os testes estáticos ocorrem normalmente
nas etapas iniciais do processo de desenvolvimento, desta forma,
requerem menor esforço de retrabalho.
• Menor esforço de retrabalho significa correções a um custo bem
inferior, do que quando o defeito é detectado e removido durante os
testes dinâmicos.

Guilherme Motta 45
Tipos de Técnicas Estáticas

• Diversos tipos de testes estáticos são encontrados na literatura especializada


e, na prática, é comum que o mesmo documento (artefato) seja objeto de mais
de um tipo de verificação estática.
• Por exemplo, uma revisão informal pode ser conduzida antes de uma
revisão técnica, ou uma inspeção pode ser executada em uma especificação
de requisitos antes de um acompanhamento (“walkthrough”) com clientes.

Guilherme Motta 46
Tipo: Revisão Informal

• Não existe processo formal;


• Discussão informal de um problema técnico, o que muitas vezes é
efetivo;
• Pode haver revisão em pares, onde um técnico (ou um líder técnico)
revisa a modelagem e/ou o código feito por outro técnico;
• A documentação é opcional, não requer registros dos resultados da
revisão;
• Principal propósito: uma forma de obter algum benefício a um baixo
custo.

Guilherme Motta 47
Tipo: Acompanhamento - Walkthrough

• Reunião conduzida pelo autor do artefato que está sendo revisado;


• Cenários, grupos de discussão e exercícios práticos, podem ser
utilizados para facilitar o entendimento por parte dos revisores (ex:
clientes);
• Opcionalmente há uma reunião preparatória com os revisores, com
orientações sobre a dinâmica da revisão;
• As sessões de Walkthrough devem contar com um redator diferente
do autor, nessas sessões deverão ser produzidos: relatórios de
revisão, lista de defeitos encontrados, além do registro de toda
informação útil produzida;
• Na prática as sessões de Walkthrough podem variar de informal para
muito formal;
• Principal propósito: aprendizagem, obter entendimento e encontrar
defeitos.

Guilherme Motta 48
Tipo: Revisões Técnicas (Peer Review)

• Deve ser documentado, processo de identificação de defeitos que inclui


técnicos ou colegas especialistas, atuando em pares;
• Pode ser feito por um colega, de mesmo perfil técnico, com ou sem a
participação da gerência;
• Idealmente são conduzidas por um moderador treinado (que não seja o autor);
• Dependendo do contexto, uma reunião preparatória pode ser necessária;
• As revisões técnicas devem ser executadas com apoio de checklists;
• Como boa prática deve-se gerar relatório final da revisão, incluindo a lista de
defeitos e plano de ação para as correções. A participação do Gestor do
Projeto (ou gerência imediata) também é visto como fator de sucesso;
• Na prática, as revisões técnicas podem variar de informal para muito formal;
• Principais propósitos: discussão, tomada de decisões, avaliar alternativas,
encontrar defeitos, resolver problemas técnicos e checar a conformidade da
padronização das especificações.

Guilherme Motta 49
Tipo: Inspeções (Revisão Técnica Formal)

• Técnica com maior grau de formalidade do que a Revisão Técnica,


tem como objetivo principal identificar e remover defeitos;
• Conduzida por um técnico moderador (que não seja o autor), onde
todos os participantes tem seus papéis definidos;
• Recomenda-se reuniões de preparação antes das inspeções;
• Recomenda-se a utilização de métricas;
• Processo formal baseado em regras e utilização de checklist com
critérios de entrada e saída, além da obrigatoriedade de gerar
relatórios de inspeção, lista dos defeitos encontrados e plano de ação
para correção dos defeitos;
• Principal propósito: controle de qualidade, ou seja, encontrar
defeitos.

Guilherme Motta 50
Tipo: Análise Estática
• O objetivo da análise estática é encontrar defeitos no código fonte do software
e na modelagem.
• Análise estática é feita sem a execução do software examinado pela
ferramenta; já o teste dinâmico executa o software.
• Como as revisões, a análise estática encontra defeitos ao invés de falhas.
• Ferramentas de análise estática analisam o código do programa (ex: fluxo de
controle e fluxo de dados), gerando, como saída, arquivos do tipo HTML e
XML, por exemplo.

• Os benefícios da análise estática são:


 Detecção de defeitos antes da execução do teste.
 Conhecimento antecipado sobre aspectos suspeitos no código ou programa através
de métricas, por exemplo, na obtenção de uma medida da alta complexidade.
 Identificação de defeitos dificilmente encontrados por testes dinâmicos.
 Detecção de dependências e inconsistências em modelos de software, como links
perdidos.
 Aprimoramento da manutenibilidade do código e construção.
 Prevenção de defeitos, se as lições forem aprendidas pelo desenvolvimento.

Guilherme Motta 51
Tipo: Análise Estática – Ferramentas

Guilherme Motta 52
Prática 4 – Técnicas para Testes Estáticos

1 – Quais são as técnicas para Teste Estático? O que diferencia cada uma delas?

2 – Qual a vantagem de utilizar “checklists” nos Testes Estáticos?

3 – Para uma especificação de Casos de Uso, por exemplo, quais critérios (pelo menos 3
critérios) você colocaria em um checklist?

4 – Leia os artigos: “Inspeções_software_aplicadas_roteiros_teste_funcionais.pdf” e


“Ferramentas_para_Analise_Estatica_de_Codigos_Java.pdf”. Faça suas
considerações.

5 – Comentar o diagrama abaixo:

Guilherme Motta 53
5 – Fundamentos do Processo de Testes de Software

Guilherme Motta 54
Definição do Processo de Testes

• O processo de teste pode ser definido como um processo separado,


mas intimamente ligado, ao processo de desenvolvimento. Isso
porque eles têm metas e medidas de sucesso diferentes.

• Por exemplo, quanto menor a taxa de defeitos (razão entre o no de


casos de teste que falham pelo total de casos de teste), mais bem
sucedido é considerado o processo de desenvolvimento.

• Por outro lado, quanto maior a taxa de defeitos, considera-se mais


bem sucedido o processo de teste (McGregor e Sykes, 2001).

Guilherme Motta 55
Objetivos do Processo de Testes

O objetivo da atividade de teste pode ser entendido da seguinte forma:


• No início de cada fase verificar se esta etapa do projeto reflete exatamente os
requisitos e definições da fase imediatamente anterior, para com isso garantir
que o produto encomendado e o gerado pela atividade de desenvolvimento do
software será o mesmo através dos diferentes níveis de refinamento do
projeto;
• Verificar se não existem erros de lógica no projeto e código, no fluxo de dados,
no entendimento de requisitos, de codificação, tipográficos ou de interface em
todas as fases do projeto;
• Identificar e interferir na presença do erro, iniciando-se a depuração, sendo que
quanto antes for descoberta a falha, menos custoso será para adequá-la;
• Ter em mente que, uma vez que errar é humano e atividade de
desenvolvimento de software é um exercício bastante complexo, os erros
existem e devem ser descobertos, portanto o sucesso em um teste consiste
em descobrir os erros e corrigi-los.

Guilherme Motta 56
Etapas do Processo de Testes

• Independentemente da fase de teste, o processo de teste


inclui as seguintes etapas:

 Planejamento;
 Análise de Requisitos de Teste;
 Projeto de Casos de Teste;
 Implementação de Casos de Teste;
 Execução ;
 Análise de Resultados e Defeitos.

Guilherme Motta 57
Visão Geral Atividades de Teste

Guilherme Motta 58
Automatização do Processo de Teste

• É um ponto importante para o sucesso no teste de um software.

• O processo de teste tende a ser extremamente dispendioso e é muito


importante utilizar ferramentas de apoio ao teste para buscar
aumentar a produtividade.

• Há diversos tipos de ferramentas de teste. Ainda assim, muito


trabalho humano é necessário para criar os casos de teste
adequados ao critério utilizado (Delamaro et al., 2007).

• Uma análise criteriosa deve ser feita para identificar o que deve e não
deve ser automatizado no Processo de Testes de Software.

Guilherme Motta 59
Estratégia de Testes (1)

• Teste é um conjunto de atividades que pode ser planejado


antecipadamente e realizado sistematicamente.

• O planejamento e a realização das atividades de teste definem a


estratégia de testes de software.

• Define técnicas de projeto de casos de teste e métodos de teste


específicos para cada etapa do processo de engenharia de software.

• Deve acomodar testes de baixo nível e testes de alto nível.

• Oferecer orientação ao profissional, além de um conjunto de marcos


de referência ao administrador.

• Deve ser mensurável.

Guilherme Motta 60
Estratégia de Testes (2)

• A atividade de teste inicia-se no nível de módulos e prossegue


"para fora", na direção da integração de todo o sistema
• Diferentes técnicas de teste são apropriadas a diferentes pontos de
tempo.
• A atividade de teste deve ser realizada pela equipe de
desenvolvimento do software e por um grupo de teste
independente.
• As atividades de teste e de depuração são atividades diferentes,
mas a depuração deve ser acomodada em qualquer estratégia de
teste.

Guilherme Motta 61
Estratégia de Testes (3)

• A formulação de uma estratégia de teste envolve a definição dos tipos


de teste que deverão ser realizados, assim como, a identificação das
funcionalidades prioritárias para cada um dos tipos de teste definidos.

• Isto não quer dizer que as funcionalidades não relacionadas não


devam ser testadas, mas apenas que elas não são prioritárias.

Guilherme Motta 62
Processo de Teste Genérico (01)

Planejar Projetar Implementar Executar Analisar


Testes Testes Testes Testes Resultados

Gerenciar
Defeitos

Guilherme Motta
Etapas do Processo de Teste Genérico (02)

Planejar Projetar Implementar Executar Analisar


Testes Testes Testes Testes Resultados

• Planejar os testes adequados ao Projeto (Plano de Testes);


• Identificar e mitigar os Riscos em relação aos Testes;
• Cronograma dos Testes compatível com o cronograma do
Projeto;
Gerenciar
• Equipe de Teste (recursos). Defeitos

Guilherme Motta
Etapas do Processo de Teste Genérico (03)

Planejar Projetar Implementar Executar Analisar


Testes Testes Testes Testes Resultados

• Elaborar Roteiros de Teste (Casos de Teste);


• Definir Massa de Teste;
• Fazer a modelagem dos Testes, identificando as
varíáveis, ações, resultados etc.
Gerenciar
Defeitos

Guilherme Motta
Etapas do Processo de Teste Genérico (04)

Planejar Projetar Implementar Executar Analisar


Testes Testes Testes Testes Resultados

• Preparar ambientes de Teste;


• Especificar a sequencia de
ações para execução dos Teste
Manuais;
•Especificar a sequencia de Gerenciar
ações para os Testes Defeitos
Automatizados;
• Construir os scripts de teste.

Guilherme Motta
Etapas do Processo de Teste Genérico (05)

Planejar Projetar Implementar Executar Analisar


Testes Testes Testes Testes Resultados

•Executar Teste Unitário / Integrado (Referência


Roteiro de Teste);
•Executar Teste Funcional (Referência Roteiro de
Teste);
•Executar Testes de Sistema (Referência Roteiro Gerenciar
de Teste); Defeitos
•Executar Homologação;
•Coletar Resultados de Teste (Medições).

Guilherme Motta
Etapas do Processo de Teste Genérico (05)

Planejar Projetar Implementar Executar Analisar


Testes Testes Testes Testes Resultados

• Definir ciclo de vida dos defeitos; Gerenciar


• Priorizar os defeitos; Defeitos

• Classificar os defeitos;
• Analisar defeitos;
• Gerar Relatórios de Defeitos.

Guilherme Motta
Etapas do Processo de Teste Genérico (05)

• Gerar resultados dos Testes;


• Indicar a Qualidade do Produto;
•Avaliar a Produtividade do Processo;
• Realimentar Dados para Estimativa.

Planejar Projetar Implementar Executar Analisar


Testes Testes Testes Testes Resultados

Gerenciar
Defeitos

Guilherme Motta
Prática 5 – Fundamentos do Processo de Testes de Software

1 – Quais são os objetivos do Processo de Testes de Software?

2 – Quais são as etapas do Processo de Testes de Software? Qual a principal característica


de cada etapa?

3 – O que significa: “Os testes devem ser mensuráveis …”

4 - Leia o artigo: “PBQP_Processo de Teste de Software Dataprev_2007.pdf”. Faça suas


considerações.

5 – Considerando o Processo de Testes Genérico, informe qual (ou quais) artefato é gerado
em cada uma das etapas?

Planejar Projetar Implementar Executar Analisar


Testes Testes Testes Testes Resultados

Gerenciar
Defeitos

Guilherme Motta 70
6 – Técnicas de Modelagem de Testes de Software

Guilherme Motta 71
Categoria das Técnicas de Modelagem de Testes (1)

• Técnicas de Caixa_Preta ou baseada em especificação:


• Forma de derivar e selecionar as condições e casos de testes
baseados na análise da documentação seja funcional ou não-
funcional, para um componente ou sistema sem levar em
consideração a sua estrutura interna.
• Características comuns das técnicas baseadas em especificação:
• Modelos, formais ou informais, são utilizados para especificação
de um problema a ser resolvido, o software ou seu componente.
• Os casos de testes podem ser derivados sistematicamente
destes modelos.

Guilherme Motta 72
Categoria das Técnicas de Modelagem de Testes (2)

• Técnicas de Caixa-Branca (também chamadas de técnicas


estruturais ou baseadas em estrutura interna de um componente ou
sistema):
• Características comuns das técnicas baseadas em estrutura:
• Informações sobre como o software é construído é utilizada para
derivar os casos de testes. Por exemplo: código e modelagem.
• A extensão da cobertura de código pode ser medida pelos casos
de testes.
• Além disto, os casos de testes podem ser derivados
sistematicamente para aumentar a cobertura.

Guilherme Motta 73
Categoria das Técnicas de Modelagem de Testes (3)

• Técnicas Baseadas em Experiência


• Características comuns das técnicas baseadas em experiência:
• Conhecimento e experiência de pessoas são utilizados para
derivar os casos de testes.
• Conhecimento de testadores, desenvolvedores, usuários, outros
interessados (stakeholders) responsáveis pelo software, seu uso
e ambiente.
• Conhecimento sobre defeitos prováveis e sua distribuição.

Guilherme Motta 74
Técnicas Baseadas em Especificação (1)

Partição de Equivalência:
• As entradas do software ou sistema são divididas em grupos que tenham
um comportamento similar, podendo ser tratados da mesma forma.
• Partições (ou classes) de equivalência podem ser encontradas em dados
válidos e inválidos (por exemplo, valores que deveriam ser rejeitados).
• Partições podem também ser identificadas para valores de saídas, valores
internos e valores relacionados a tempo, (antes e após um evento) e para
parâmetros de interface (durante teste de integração).
• Testes podem ser elaborados para cobrir as partições.
• Partição de Equivalência é aplicável a todos os níveis de testes.
• A técnica de Partição de Equivalência pode ser usada para atingir a
cobertura dos valores de entrada e saída.
• Pode ser aplicada em uma entrada manual, interface entrada de sistema ou
como parâmetro de interface num teste de integração.

Guilherme Motta 75
Técnicas Baseadas em Especificação (2)

Exemplo de Partição de Equivalência


Função:
Considere uma função que aceita como entradas de 4 a 6 valores inteiros
de 2 dígitos maiores do que 10.
Identificação das variáveis de entrada e das condições que estas devem
satisfazer:
• nro_entradas: pertence ao conjunto - [ 4, 6 ]
• Valor: pertence ao conjunto - [ 10, 99 ]

Guilherme Motta 76
Técnicas Baseadas em Especificação (3)

Exemplo de Partição de Equivalência


Determinação das Partições (Classes) de Equivalência

Variável Classes Válidas Classes inválidas


nro_entradas C1: 4 <= nro_entradas <= 6 C3: nro_entradas < 4
C4: nro_entradas > 6

Valor C2: 10 <= valor <= 99 C5: valor < 10


C6: valor > 99

Guilherme Motta 77
Técnicas Baseadas em Especificação (4)

Exemplo de Partição de Equivalência


Casos de teste:
• Selecionar casos de testes cobrindo as classes válidas das diferentes variáveis.

Variáveis Classes de Equivalência Casos de teste

nro_entradas C1 C2 C3 C4 C5 C6 CT nro_entradas valores

4 ... 6 X 1 5 11; 12; 45; 78; 95

<4 2

>6 3

valor

10 ... 99 X 4

< 10 5

> 99

Guilherme Motta 78
Técnicas Baseadas em Especificação (5)

Exemplo de Partição de Equivalência


Casos de teste:
• Para cada classe inválida escolha um caso de teste que cubra 1 e somente 1 de cada vez.

Variáveis Classes de Equivalência Casos de teste

nro_entradas C1 C2 C3 C4 C5 C6 CT nro_entradas valores

4 ... 6 X 1 5 11; 12; 45; 78; 95

<4 X 2 3 11; 12; 45

>6 3

valor

10 ... 99 X 4

< 10 5

> 99

Guilherme Motta 79
Técnicas Baseadas em Especificação (6)

Exemplo de Partição de Equivalência

Casos de teste:
• Para cada classe inválida escolha um caso de teste que cubra 1 e somente 1 de cada vez.

Variáveis Classes de Equivalência Casos de teste

nro_entradas C1 C2 C3 C4 C5 C6 CT nro_entradas valores

4 ... 6 X 1 5 11; 12; 45; 78; 95

<4 X 2 3 11; 12; 45

>6 X 3 8 11, 12, 45, 78, 95,


67, 77, 54
valor

10 ... 99 X 4 5 5, 11, 12, 45, 6

< 10 X 5 5 110, 45, 78, 340, 95

> 99 X
Guilherme Motta 80
Técnicas Baseadas em Especificação (7)
Análise do Valor Limite
• O comportamento nos limites de uma partição de equivalência é onde existe
maior probabilidade de estar incorreto. Portanto, limites são áreas onde testes
estão mais propensos a indicar defeitos.
• Os valores limites de uma partição são seu máximo e seu mínimo.
• Um valor limite para uma partição válida é um valor limite válido.
• O limite de partição inválida é um valor limite inválido.
• Testes podem ser projetados para cobrir tanto valores inválidos como válidos.
• Quando os casos de testes são projetados, um valor em cada limite é escolhido.
•Análise do valor limite pode ser aplicada em todos os níveis de teste.
• É relativamente fácil aplicá-la, sua capacidade de encontrar defeitos é alta e
especificações detalhadas podem ser úteis em sua elaboração.
• Esta técnica é muitas vezes considerada uma extensão da partição de
equivalência e pode ser aplicada para entradas manuais como, por exemplo, em
escalas de tempo ou tabela de limites.
• Valores limites podem também ser usados para selecionar dados de testes.
Guilherme Motta 81
Técnicas Baseadas em Especificação (8)

Exemplo de Análise do Valor Limite


Critério de seleção que identifica valores nos limites das classes de equivalência, exemplos:

• Valor mínimo (máximo) igual ao mínimo (máximo) válido;


• Uma unidade abaixo do mínimo;
• Uma unidade acima do máximo;
• Arquivo vazio
• Arquivo maior ou igual à capacidade máxima de armazenamento;
• Cálculo que pode levar a “overflow” (“underflow”);
• Erro no primeiro (último) registro

Mesma função do exemplo anterior:


Considere uma função que aceita como entradas de 4 a 6 valores inteiros de 2 dígitos
maiores do que 10.
Identificação das variáveis de entrada e das condições que estas devem satisfazer:
• nro_entradas: pertence ao conjunto - [ 4, 6 ]
• Valor: pertence ao conjunto - [ 10, 99 ]

Guilherme Motta 82
Técnicas Baseadas em Especificação (9)

Exemplo de Análise do Valor Limite


Casos de teste:
• Para cada classe inválida escolha um caso de teste que cubra 1 e somente 1 de cada vez.

Variáveis Classes de Equivalência Casos de teste

nro_entradas C1 C2 C3 C4 C5 C6 CT nro_entradas valores

4 ... 6 X 1 4 10, 11, 98, 99

Valores Limite
<4 X 2 6 10, 11, 50, 55, 98, 99

>6 X 3 3 10, 11, 98

valor

10 ... 99 X 4 7 10, 11, 50, 55, 98, 99, 45

< 10 X 5 4 9, 10, 11, 99

> 99 X 6 4 10, 11, 100, 101

Guilherme Motta 83
Técnicas Baseadas em Especificação (10)

Limitações das técnicas baseadas em Partições de Equivalência e


Análise de Valores-Limite:
• Consideram cada valor de entrada isoladamente;

• Se existirem combinações de valores que constituam situações


interessantes a serem testadas?

Guilherme Motta 84
Técnicas Baseadas em Especificação (11)
Tabela de Decisão
• A tabela de decisão é considerada uma boa alternativa para capturar requisitos de sistemas
que contém condições lógicas e para documentar o comportamento interno do sistema.
• Elas podem ser utilizadas para registrar regras de negócio complexas a serem
implementadas.
• A especificação é analisada e as condições e ações do sistema são identificadas.
• As condições de entrada e ações são declaradas de uma forma que possam ser
entendidas, como verdadeiras ou falsas (Booleano).
• A tabela de decisão contém as condições que disparam as ações, muitas vezes
combinações verdadeiras e falsas para todas as condições de entrada, e ações resultantes
para cada combinação de condições.
• Cada coluna da tabela corresponde a uma regra de negócio que define uma única
combinação de condições que resulta na execução de ações associadas com aquela regra.
• A cobertura padrão comumente usada em uma tabela de decisão é ter no mínimo um teste
por coluna cobrindo todas as combinações de condições apresentadas.
• O grande ganho na utilização da tabela de decisão é que ela cria combinações de
condições que geralmente não foram exercitadas durante os testes.
• Pode ser aplicada a todas as situações quando a execução do software depende de muitas
decisões lógicas.
Guilherme Motta 85
Técnicas Baseadas em Especificação (12)
Tabela de Decisão
• A tabela decisão pode ser utilizada para Análise de Causa e Efeito, quando se
deseja testar combinações de entrada.
• Árvores de Decisão é outra técnica que também pode ser utilizada, quando se
deseja testar combinações de entrada.

Definições:
• Causas = Condições (combinações) de entrada (valor lógico);
• Efeitos = Ações realizadas em resposta às diferentes condições de entrada.
Exemplo:
• Causa: Preço ≥ 50 e 0 ≤ Quantidade ≤ 99;
• Efeito: fornecer 5% de desconto.

Guilherme Motta 86
Técnicas Baseadas em Especificação (13)
Árvore de Decisão >= 50
Dar desconto

Preço
Pertence a [0, 99]

< 50
Cobrar preço normal
Quantidade

Não pertence a [0, 99]


Emitir mensagem de erro

Tabela de Decisão Combinações (booleanas)

Condição Preço >= 50 V F #


(Causa)
0 <= Quantidade <= 99 V V F

Ações Dar desconto X


(Efeitos)
Cobrar preço normal X

Emitir mensagem
Regras de erro
de Negócio X

Guilherme Motta 87
Técnicas Baseadas em Especificação (14)
Teste de Transição de Estados
• Um sistema pode exibir respostas diferentes dependendo da sua condição atual ou de
estado anterior. Neste caso, o comportamento do sistema pode ser representado como um
diagrama de transição de estados.
• Permite ao testador visualizar o software em termos de estados, transições entre estados,
as entradas ou eventos que disparam as mudanças de estado (transição) e as ações que
podem resultar daquelas transições.
• Os estados do sistema, ou objetos sob teste, são isolados, identificáveis e finitos.
• Uma tabela de estado exibe a relação entre estados e entradas, e pode destacar possíveis
transições inválidas.
• Os testes podem ser construídos para cobrir uma seqüência típica de status, cobrir todos os
estados, exercitar todas as transições, exercitar uma seqüência específica de transições ou
testar transições inválidas.
• Teste de transição de status é muito utilizada em softwares industriais embarcados e
automações técnicas em geral.
• No entanto, a técnica é também adequada para modelar um objeto de negócio tendo estado
específico ou para testar fluxos de telas de diálogos (exemplo: aplicação de internet e
cenários de negócios).

Guilherme Motta 88
Técnicas Baseadas em Especificação (15)
Exemplo de Teste de Transição de Estados
Diagrama de Transição de Estados de um Livro (biblioteca)

Guilherme Motta 89
Técnicas Baseadas em Especificação (16)
Exemplo de Teste de Transição de Estados
Tabela de Estados

Estados Entradas / Eventos / Ações


Emprestar Reservar Devolver Atualizar Retornar

E1 E2
Disponível
E2 E2 E4 E1; E3[ ]
Emprestado
E3 E2 E1
Reservado
E4 E1; E3[ ]
Atrasado

[ ] – A transição entre estados depende do atendimento à condição.

Guilherme Motta 90
Técnicas Baseadas em Especificação (17)
Exemplo de Teste de Transição de Estados
A especificação do Software de Telecomando em máquina de estados (MEF) , composta por 6 estados,
46 entradas e um total de 233 transições.

Guilherme Motta 91
Técnicas Baseadas em Especificação (18)
Teste de Caso de Uso
• Testes podem ser especificados a partir de casos de uso ou cenários de negócios.
• Um caso de uso descreve interações entre os atores (usuários e o sistema) que produz um
resultado relevante para um usuário do sistema.
• Cada caso de uso tem pré-condições, que precisam ser garantidas para que o caso de uso
funcione com sucesso.
• Cada caso de uso é finalizado com uma pós-condição que representa os resultados
observados e o estado final do sistema após o término do caso de uso.
• Um caso de uso normalmente tem um cenário mais comum (mais provável), e algumas
vezes ramificações.
• Caso de uso descreve o fluxo de processo de um sistema baseado nas suas possibilidades
de utilização.
• Os casos de testes derivados de casos de uso são muito úteis na descoberta de defeitos no
fluxo do processo durante a utilização do sistema no mundo real.
• Casos de uso muitas vezes são tratados como cenários, e úteis para construir testes de
aceite com a participação do usuário final.
• Eles podem ajudar a descobrir defeitos de integração causados pela interação e
interferência de diferentes componentes, que testes individuais de componentes podem não
ter detectado.
Guilherme Motta 92
Técnicas Baseadas em Especificação (19)
Exemplo Teste de Caso de Uso

Guilherme Motta 93
Técnicas Baseadas em Especificação (20)
Exemplo Teste de Caso de Uso
Nome: Registrar contrato 8- O sistema registra as cotas de pagamento do
contrato (com base nas informações fornecidas pelo
Ator: Vendedor
vendedor referentes a quantidade de cotas, data
Evento: Vendedor fecha novo contrato base de pagamento e pesquisando o valor de
manutenção de cada tipo de equipamento o sistema
Descrição: Este caso de uso é responsável pelo cadastramento de
calcula e registra o valor das cotas de pagamento do
novos contratos no sistema.
contrato);
Curso Normal:
1 - O vendedor informa o CNPJ do cliente;
2 - O sistema verifica que o cliente está cadastrado e apresenta seu Curso Alternativo Passo 2:
nome;
Evento: O cliente não está cadastrado.
3 - O sistema apresenta os tipos de equipamentos cadastrados;
O sistema gera um aviso de cliente não cadastrado;
4 - O vendedor informa os equipamentos que farão parte do contrato
ESTENDER Cadastrar Cliente;
(para cada equipamento, o vendedor seleciona um tipo de
equipamento apresentado e informa seu número de série e data de O sistema apresenta o nome do cliente;
fabricação);
Retornar ao passo 3.
5 - Vendedor informa dados básicos do contrato (o vendedor deve
informar a data de início, data de término e a quantidade de cotas
de pagamento);
6 - O sistema registra o contrato (o sistema faz o registro do
contrato, informando sua data de inicio e data de término, e gera um
número seqüencial único independente do cliente);
7 - O sistema registra os equipamentos do contrato (cada
equipamento registrado no contrato recebe um número de
manutenção gerado pelo sistema);

Guilherme Motta 94
Técnicas Baseadas em Especificação (21)
Exemplo Teste de Caso de Uso
Casos de Teste 1

Guilherme Motta 95
Técnicas Baseadas em Especificação (21)
Exemplo Teste de Caso de Uso
Casos de Teste 2

Guilherme Motta 96
Técnicas Baseadas em Especificação (22)
Exemplo Teste de Caso de Uso
Casos de Teste 3

Guilherme Motta 97
Técnicas Baseadas em Estrutura (1)
Níveis:
• Nível de Componente:
• A estrutura é o próprio código, ex: comandos, decisões e desvios.
• Nível de Integração:
• A estrutura pode ser uma árvore de chamadas (um diagrama em que
um módulo chama outros módulos).
• Nível de Sistema:
• A estrutura pode ser uma estrutura de menu, processos de negócios
ou estruturas das páginas Web.

Guilherme Motta 98
Técnicas Baseadas em Estrutura (2)
• Testes baseados em estrutura, no nível componente, são baseados no código e visam
exercitar estruturas de controle (instruções) e de dados de um programa.
• Esses testes, na verdade, exercitam o caminho (Testes de Caminho) com objetivo de
garantir que o conjunto de casos de teste atenda aos caminhos realizados pelo programa,
verificando se os caminhos são executados pelo menos uma vez.
• Para o Teste de Caminho, elabora-se um Grafo de Fluxo de Programa, onde os nós,
representam os blocos de comando do programa, e os arcos (arestas ou ramos) representam
os fluxos de controle.

Guilherme Motta 99
Técnicas Baseadas em Estrutura (3)
Exemplo de Grafo de Fluxo de Controle

Guilherme Motta 100


Técnicas Baseadas em Estrutura (4)
Teste e Cobertura de Comandos
• No teste de componente, cobertura de comando é avaliado pela porcentagem de
comandos executáveis que foram exercitados por um conjunto de casos de testes.
• No teste de comandos deriva-se os casos de teste para executar comandos
específicos, normalmente para se aumentar a cobertura.
Normalmente são utilizadas ferramentas para dar o suporte aos testes de estrutura
do código.

Guilherme Motta 101


Técnicas Baseadas em Estrutura (5)
Exemplo de Grafo de Fluxo para Testes e Cobertura de Comandos (Instruções)

Guilherme Motta 102


Técnicas Baseadas em Estrutura (6)
Teste e Cobertura de Decisão
• Cobertura de decisão, também chamada de teste de ramificação, é avaliada pela
porcentagem dos resultados da decisão (por exemplo, as opções “Verdadeiro” ou
“Falso” de uma expressão condicional - IF) que foram exercitados em um conjunto
de casos de teste.
• No teste de decisão derivam-se os casos de testes para executar decisões
específicas, normalmente para se aumentar a cobertura.
• Teste de decisão é uma forma de teste de controle de fluxo, já que ele gera um
fluxo específico através dos pontos de decisões.
• A cobertura de decisão é mais eficiente que a cobertura de comandos: 100% da
cobertura de decisão garante 100% da cobertura de comandos, mas não vice-
versa.

Normalmente são utilizadas ferramentas para dar o suporte aos testes de estrutura
do código.

Guilherme Motta 103


Técnicas Baseadas em Estrutura (7)
Exemplo de Grafo de Fluxo para Testes e Cobertura de Decisão

Guilherme Motta 104


Técnicas Baseadas em Estrutura (8)
Complexidade Ciclomática (McCabe)

• O número de caminhos independentes no código é igual à complexidade


ciclomática.

• Cálculo da Complexidade Ciclomática:


CC = Número de ramos - Número de nós + 2 (Número de Componentes Ligados)
• Complexidade Ciclomática determina o número de casos de teste mínimo para
testar adequadamente todos os caminhos independentes do programa.

• Fórmula Mágica (McCabe) de Complexidade Ciclomática:


CC = Quantidade de Decisões + 1
OBS: Considerando a análise de um programa que tenha apenas um ponto de entrada e um de saída.

Guilherme Motta 105


Técnicas Baseadas em Estrutura (9)
Exemplo de Cálculo de Complexidade Ciclomática (McCabe)
• Cálculo da Complexidade Ciclomática:
CC = Número de ramos - Número de nós + 2 (Número de Componentes Ligados)

Cálculo:
• Número de Ramos = 12
• Número de Nós = 10
• Número de Componentes Ligados = 1 (único componente)

CC = 12 – 10 + 2 = 4 Casos de Teste

Guilherme Motta 106


Técnicas Baseadas em Experiência (Teste Exploratório)
• Possivelmente a técnica mais amplamente aplicada é a de supor (adivinhar) onde estão os
erros.
• Os testes derivam da intuição e conhecimento dos testadores com sua experiência em
aplicações e tecnologia similares.
• Quando usado para aumentar a técnica sistemática, testes intuitivos podem ser úteis para
identificar testes específicos que não são facilmente identificados pelas técnicas formais.
• Especialmente quando aplicado após ter estabelecido o processo mais formal. No entanto,
esta técnica pode produzir amplas variedades e graus de eficiência, dependendo da
experiência do testador.
• Uma abordagem estruturada da técnica de dedução de erros é enumerar uma lista de
possíveis erros e construir testes com objetivo de atacar/cobrir estes erros.
• Estas listas de defeitos e falhas podem ser construídas com base na experiência, dados de
defeitos/falhas disponíveis e do conhecimento comum de como o software falha.
•Teste exploratório ocorre simultaneamente à modelagem, execução e registro de teste, e
baseia-se nos objetivos de teste, onde é realizado em um tempo predefinido.
• É uma abordagem muito usual, em locais onde a especificação é rara ou inadequada e
existe grande pressão por conta de prazo, ou para aprimorar/complementar um teste mais
formal.

Guilherme Motta 107


Técnicas Baseadas em Experiência (Teste Exploratório)
Exemplo Teste Exploratório

Guilherme Motta 108


Prática 6 – Técnicas de Modelagem de Testes de Software

1 – Quais são as categorias das técnicas de modelagem


de testes? E qual o objetivo de fazer a modelagem
de testes?
2 – Escolha uma das técnicas baseadas em especificação
e outra baseada em estrutura. Crie um exemplo
para cada uma delas, diferentes dos apresentados
em sala, que comprove a utilidade dessas técnicas.
3 – Leia o artigo:
“Metodologia_Criacao_Massa_Testes_Rastreaveis.
pdf”. Faça suas considerações.
4 - Para o Caso de Uso descrito ao lado, desenvolva
Casos de Teste que verifiquem:
• A funcionalidade de Verificar a Validade da Conta Corrente
– item 4 do Fluxo Básico;
• A funcionalidade de Validar senha para autorização de
transferência – item 8 Fluxo Básico.
• A funcionalidade de Verificar Saldo de Conta – item 7 do
Fluxo Básico.

Guilherme Motta 109


7 – Gerenciamento de Testes de Software

Guilherme Motta 110


As Organizações e o Teste de Software (1)
• A eficácia na procura por defeitos e falhas, em revisões e testes, pode ser
aperfeiçoada em função do grau de dependência dos testadores e analistas de
teste de uma organização.
• Os graus de dependência são:
• Nenhum testador independente. Os desenvolvedores testam seu próprio
código.
• Testadores independentes provenientes da própria equipe de
desenvolvimento.
• Equipe de teste independente ou grupo dentro da organização, reportando a
um gerente de projeto ou diretor executivo.
• Testadores independentes da organização do negócio, dos usuários e da
área de TI.
• Especialistas em teste independente para um objetivo específico de teste,
como testes de usabilidade, segurança ou certificação (que certifica se o
software está em conformidade com as normas e padrões).
• Equipe de teste terceirizada ou independente da organização.

Guilherme Motta 111


As Organizações e o Teste de Software (2)
• Para projetos longos, complexos e críticos, normalmente é melhor ter vários níveis de
teste, com algum ou todos os níveis efetuados por equipes independentes de teste.
• A equipe de desenvolvimento pode participar do teste, especialmente para os testes de
baixo nível, mas sua falta de objetividade muitas vezes limita a efetividade do teste.
• Equipes independentes de teste devem ter a autoridade para requisitar e definir os
processos de teste e suas regras, mas os testadores teriam que exercer estas funções
somente sob um claro gerenciamento.
• Os benefícios da independência da equipe de testes são:
• Testadores independentes conseguem enxergar outros defeitos e são imparciais.
• Um testador independente é capaz de verificar concepções pessoais criadas durante a
especificação e implementação de um sistema.
• As desvantagens incluem:
• Isolamento da equipe de desenvolvimento (se for tratado com independência total).
• Equipe pode se tornar um gargalo, considerando-se o último ponto de controle.
• Os desenvolvedores podem perder o senso da responsabilidade pela qualidade.
• A atividade do teste deve ser realizada por pessoas com uma função específica de teste.

Guilherme Motta 112


Profissionais de Teste de Software (1)
• Para garantir que o Processo de Teste de Software seja adotado de forma Corporativa, é
necessário que a atuação dos profissionais especializados em testes tenham “focos”
diferenciados, visando não somente a execução dos projetos de testes, mas também na
evolução do processo como um todo, seja na forma de otimização dos trabalhos
(automações e simuladores) como na criação de novos controles e artefatos.
• A divisão em grupos, com atuações diferenciadas, proporcionaria à empresa uma maior
eficiência na condução e melhoria dos projetos de testes de software, além de estabelecer
objetivos e desafios a serem alcançados pelos profissionais, muito mais bem definidos e
segregados.

Guilherme Motta 113


Profissionais de Teste de Software (2)
Grupo: Gerenciamento dos Serviços de Testes
• Responsável em atender as demandas de testes de software geradas pelas mudanças solicitadas pelos
Clientes.
• Estas demandas devem ser priorizadas para que os esforços sejam direcionados de acordo com as
expectativas das áreas Clientes (internas ou externas) e as estratégias da organização (oportunidades ou
ameaças).
• A limitação da equipe de testes e a produtividade do grupo estabelecem qual o número máximo de
projetos que a equipe poderá suportar sem a necessidade de empregar a terceirização do processo.
• Nas terceirizações, conduz e apóia os projetos de testes nas negociações com os fornecedores, sendo
responsável pela elaboração dos contratos, estabelecendo os níveis de serviços a serem contratados, os
produtos a serem entregues durante o projeto, bem como as premissas de padrões de artefatos e
controles exigidos pelo modelo de testes da organização.
• Responde pelo acompanhamento e visibilidade dos projetos de testes para toda a organização e seus
Clientes, mantendo todos informados sobre os riscos do projeto, etapas finalizadas e em realização,
indicadores de produtividade e qualidade alcançados pelo projeto. Além de garantir que os projetos de
testes empreguem o padrão corporativo estabelecido.
• Seguem os principais serviços sob sua responsabilidade:
• Gerenciamento de Projetos e Recursos de Testes de Software;
• Gerenciamento de Métricas de Qualidade e Produtividade;
• Gerenciamento de Estimativas de Testes.

Guilherme Motta 114


Profissionais de Teste de Software (3)
Grupo: Execução dos Serviços de Testes
• Responde diretamente pela “execução” dos projetos de testes, pois direcionam seus esforços
“exclusivamente” na aplicação dos casos de testes e simulações que avaliarão o “comportamento
esperado” dos diversos sistemas modificados para suportar todos os requisitos estabelecidos pelos
Clientes.
• Exercita continuamente o Processo de Teste de Software, estabelecendo um nível de Garantia de
Qualidade diferenciado para cada sistema, respeitando os acordos de qualidade estabelecidos pelos
critérios de importância e risco que uma falha de implementação poderá provocar nas operações.
• Profissionais com alta especialização nos processos de negócios e produtos gerenciados pela empresa,
de forma a garantir que os aplicativos construídos comportam-se adequadamente com as regras de
negócios exigidas pelos Clientes.
• Combinam conhecimento específico com o de negócio, complementado pelo uso de ferramentas e
técnicas de testes, proporcionando reduzir esforços em cobrir um maior volume de testes num menor
espaço de tempo possível.
• Principais serviços:
• Condução da Fábrica de Testes e Homologações de Sistemas;
• Montagem e Monitoração de Ambientes de Testes e Homologação;
• Gerenciamento de Revisão de Artefatos;
• Gerenciamento de Prevenção de Defeitos de Software.

Guilherme Motta 115


Profissionais de Teste de Software (4)
Grupo: Inovação dos Serviços de Testes
• Direciona integralmente seus esforços na contínua “Evolução do Processo de Testes” de forma a
possibilitar que os serviços de testes tenham maior controle e desempenho, proporcionando testes em
maior velocidade, volume e precisão nos resultados, refletindo na redução de prazos, custos e no
aumento da qualidade do processo.
• Exercita a “Melhoria Contínua do Processo de Teste de Software”, estabelecendo novos controles,
artefatos, indicadores, possibilitando uma evolução na forma e condução dos projetos de testes.
• Responderá pela “Melhoria Contínua das Arquiteturas de Testes”, mantendo a evolução das automações
e ferramentas empregadas nos serviços de testes, buscando agregar novas funcionalidades e facilidades
operacionais, reduzindo esforços e retrabalhos nos projetos de testes.
• Principais serviços:
• Consultoria em Fábrica de Testes, Homologação e Qualidade de Software;
• Automação de Testes e Arquiteturas Automatizadas;
• Treinamento e Certificação de Profissionais e Empresas;
• Vendas e Suporte de Ferramentas de Testes e Qualidade.

Guilherme Motta 116


Planejamento de Teste de Software (1)

• O planejamento pode ser documentado em um plano de teste mestre ou de


projeto separado em vários planos de testes para diferentes níveis, assim como
teste de aceite ou teste de sistemas.
• A essência dos documentos de planejamento de teste é coberta pelo “Padrão de
Documentação de Teste de Software” (IEEE 829).
• O planejamento é influenciado pela política de teste da organização, o escopo,
objetivo, riscos, obstáculos, críticas e disponibilidade de recursos.
• Quanto maior for o projeto e o progresso do planejamento do testes, mais
informações estarão disponíveis e mais detalhes podem ser incluídos no plano.
• Planejamento do teste é uma atividade contínua realizada durante todo o
processo do ciclo de vida do software.
• O retorno (feedback) da atividade do teste é utilizado para identificar riscos de
mudanças, para que ajustes no planejamento sejam efetuados.

Guilherme Motta 117


Planejamento de Teste de Software (2)

As atividades no planejamento dos testes podem incluir:


• Determinação do escopo e risco, identificando os objetivos do teste.
• Definição completa da abordagem do teste (estratégia de teste), incluindo a definição do
nível de testes, dos critérios de entrada e saída.
• Integração e coordenação da atividade de teste no ciclo de vida do software (aquisição,
fornecimento, desenvolvimento, operação e manutenção).
• Tomar a decisão sobre o que testar, quais as funções executarão as atividades de teste,
quando e como as atividades podem ser realizadas, como o resultados dos testes serão
avaliados e quando parar o teste (critério de saída).
• Programar as atividades de análise e planejamento dos testes.
• Programar a implementação, execução e validade dos testes.
• Designar recursos para as diferentes tarefas definidas.
• Definir o nível de detalhe, estrutura e modelos para a documentação dos testes.
• Escolher métricas para monitorar, controlar a preparação e execução do teste, resolver
efeitos e apontar os riscos.
• Configurar o nível de detalhe para os procedimentos de teste de forma a prover
informações suficientes para que o suporte possa reproduzir o incidente.

Guilherme Motta 118


Planejamento de Teste de Software (3)

Critério de Saída
• O objetivo do critério de saída é definir quando parar de testar.
• Por exemplo: ao final de um nível de teste ou quando um conjunto de testes tem um alvo
específico.

Os critérios de encerramento podem ser constituídos de:


• Métricas como a cobertura de código, riscos ou funcionalidades.
• Estimativa da densidade de defeitos ou segurança nas medições.
• Custos.
• Riscos residuais, como defeitos não solucionados ou falta de cobertura de teste em
algumas áreas.
• Cronograma, como os baseados na data de entrega do produto.

Guilherme Motta 119


Planejamento de Teste de Software (4)

Estimativa dos Testes


• Algumas abordagens:
• Estimativa do esforço do teste baseado em métricas de projetos anteriores ou
similares, ou baseado em valores típicos.
• Estimativas das tarefas pelo próprio executor ou por especialistas.
• Estimativa de duração de testes utilizando a técnica TPA® (Test Point Analysis).
• Uma vez que a estimativa do esforço do teste é efetuada, recursos podem ser alocados e
um cronograma pode ser elaborado.
• O esforço do teste pode depender de inúmeros fatores que incluem:
• Características do produto: a qualidade da especificação ou outra informação usada
por projetos de teste, o tamanho do produto, a complexidade do problema, os requisitos
para segurança e os requisitos para documentação.
• Características do processo de desenvolvimento: A estabilidade da organização,
ferramentas usadas, processos de teste, experiência das pessoas envolvidas e pressão
no prazo.
• As saídas do teste: o número de defeitos e a quantidade de re-trabalho necessária.

Guilherme Motta 120


Planejamento de Teste de Software (5)

Abordagens dos Testes


•Uma maneira de classificar a abordagem do teste ou estratégia é baseando-se no ponto em
que começa aparecer o volume de trabalho da modelagem de teste, a saber:
• Abordagem Peventiva, na qual os testes são construídos o mais cedo possível.
• Abordagem Reativa, nas quais os testes são construídos após o software e /ou
sistemas estarem prontos.
Estratégias ou abordagens típicas incluem:
• Analítica: nas quais os testes são direcionados nas áreas do software ou sistema onde
apresentem maiores riscos.
• Baseada em modelos: nas quais os testes são baseados em dados informais
estatísticos sobre taxa de erros (tais como erros operacionais e de segurança).
• Abordagem metódica: como a baseada em falhas (incluindo dedução de erros e injeção
de falhas), baseadas em check-list, e baseadas em característica de qualidade.
• Compatível com processos ou padrões: como algumas especificadas por padrões da
indústria ou as várias metodologias ágeis.
• Dinâmica e heurística: tais como os testes exploratórios onde a atividade de testar é
mais reativa do que pré-planejada e onde a execução e avaliação são tarefas
concorrentes.

Guilherme Motta 121


Planejamento de Teste de Software (6)

Abordagens dos Testes


• Baseada em conselhos: como os testes em que a cobertura é dirigida por conselhos
de especialistas em tecnologia ou negócio fora do time de teste.
• Regressão: como aqueles em que há o reuso do material de teste, automação
extensiva dos testes funcionais de regressão, e um conjunto de testes padrão.
•Diferentes abordagens para montar uma estratégia podem ser utilizadas como, por exemplo,
abordagem baseada em risco.
•A escolha da estratégia do teste deverá considerar o contexto, incluindo:
• Risco de falha do projeto, perigo do produto em caso de falhas do software a afetar as
pessoas, ambiente e a empresa.
• Experiência das pessoas nas técnicas propostas, ferramentas e métodos.
• Os objetivos do teste, esforço e a missão da equipe de teste.
• Aspectos regulamentares, tais como alterações internas e externas no processo de
desenvolvimento.
• A natureza do produto e do negócio.

Guilherme Motta 122


Monitoramento e Controle dos Teste de Software (1)
•O propósito da monitoração do progresso do teste é permitir uma visibilidade sobre as
atividades do teste. As informações a serem monitoradas podem ser coletadas manualmente
ou automaticamente e serem utilizadas para medir os critérios de saída, como cobertura.
•Métricas podem ser usadas para avaliar o progresso em relação ao orçamento e
cronogramas planejados. As métricas mais comuns incluem:
• Porcentagem de trabalho na preparação do caso de teste (ou porcentagem de casos
de testes devidamente planejados).
• Porcentagem de trabalho na preparação do ambiente.
• Execução dos testes (números de teste executados, testes com resultados ok e não
ok).
• Informações dos defeitos (densidade do defeito, defeitos encontrados e resolvidos,
taxas de falha e resultado da re-execução).
• Cobertura de requisitos, riscos ou código.
• Confiança subjetiva do testador sob o produto
• Datas dos pontos de controle.
• Custo do teste, incluindo o custo comparado ao benefício de encontrar o próximo erro
ou de executar o próximo teste.

Guilherme Motta 123


Monitoramento e Controle dos Teste de Software (2)

Relatório do Teste
•O relatório do teste é constituído de informações resumidas sobre o esforço do teste,
incluindo:
• O que aconteceu durante a o período do teste, e qual o melhor momento de parar.
• Informações e métricas para dar suporte na tomada de decisão e recomendações
sobre futuras ações, tais como avaliação dos defeitos persistentes, vantagem
econômica da continuação dos testes e dos riscos consideráveis apontados além do
nível de confiança no software testado.
•A essência de um relatório de teste é tratada no “Padrão de Documentação de Teste de
Software” (IEEE 829).
•As métricas podem ser coletadas durante ou ao final do teste:
• A adequação dos objetivos do teste com o nível do teste.
• A adequação da abordagem/estratégia do teste.
• A eficiência dos testes em respeito a seus objetivos.

Guilherme Motta 124


Monitoramento e Controle dos Teste de Software (3)

Controle do Teste
•O controle do teste descreve uma orientação ou ação corretiva tomada como um
resultado de informações e métricas obtidas e relatadas.
•Ações podem cobrir qualquer atividade do teste e qualquer atividade em um ciclo
de vida de um software.
•Exemplos de controle de teste:
• Tomar decisões baseadas em informações adquiridas na monitoração dos
testes.
• Re-priorizar os teste quando riscos são identificados.
• Mudar o cronograma de acordo com disponibilidade do ambiente de teste.
• Definir um critério de entrada para se iniciar o re-teste de bugs resolvidos
pelo desenvolvedor antes de aceitá-lo em uma build.

Guilherme Motta 125


Gerenciamento de Configuração

•O propósito do gerenciamento de configuração é estabelecer e manter a integridade dos


produtos (componentes, dados e documentação) do software ou sistema durante todo o
projeto ou ciclo de vida do produto.

•Para o teste, o gerenciamento de configuração pode garantir que:


• Todos os itens do software são identificados, controladas as mudanças, seus
relacionamentos, facilitando manutenção e a rastreabilidade durante todo o processo
de teste.
• Todos os documentos e itens do software são referenciados sem ambigüidade na
documentação do teste.

•Para o testador, o gerenciamento de configuração ajuda na identificação única (e a


reprodução) do item testado, documentos de testes, aos testes e aos scripts de execução de
testes.
•Durante o planejamento do teste a ferramenta e processos de gerenciamento de
configuração devem ser escolhidos, documentados e implementados.

Guilherme Motta 126


Riscos em Testes de Software (1)

Risco de Software
• Risco é a possibilidade de sofrer perdas (impacto na qualidade do produto final,
no atraso do cronograma,no aumento de custos ou mesmo na falha do
projeto). (SEI - Software Engineering Institute)

Gerência de Riscos
•De acordo com o SEI, Gerenciamento de Risco (Risk Management) é uma prática
com processos, métodos, e ferramentas para gerenciar riscos em um projeto.
•Ele fornece um ambiente disciplinado para a tomada de decisão a fim de:
• Avaliar continuamente o que poderia dar errado (riscos).
• Determinar quais riscos são importantes de tratar.
• Implementar estratégias para tratar aqueles riscos.

Guilherme Motta 127


Riscos em Testes de Software (2)

Classificação
• Riscos de Projeto:
• Engloba os eventos que comprometem ou impedem a realização de um
dado projeto.
• Exemplo: Problemas com orçamento, cronograma, pessoal, recursos,
cliente e requisitos.
• Riscos de Produto (ou Técnicos):
• Afetam a qualidade ou desempenho do software que é desenvolvido.
• Exemplo: Problemas com implementação, interface, ambigüidade de
especificação.
Os riscos técnicos podem ser mitigados através de testes de software!!!!
• Riscos de Negócios:
• Afetam a organização que está desenvolvendo ou adquirindo o produto.
• Exemplo: Problemas com o mercado, com as estratégias da empresa, com
a gerência e com orçamentos.

Guilherme Motta 128


Riscos em Testes de Software (3)

Teste Baseado em Riscos


•O teste baseado em risco (risk-based testing) consiste em um conjunto de
atividades que favorecem a identificação de fatores de riscos associados aos
requisitos do produto de software.
•Uma vez identificados, os riscos são priorizados e casos de testes gerados com
base nas estratégias para tratamento e acompanhamento dos fatores de riscos
identificados.
•Focar em testes baseados em risco significa fazer julgamento sobre:
• Cobertura de teste;
• O número de testes a ser conduzido;
• Escolhas dos tipos de testes e de revisões;
• Uso e balanceamento entre testes, revisões e inspeções, dentre outros
problemas;
• Priorização dos testes (planejamento e execução).

Guilherme Motta 129


Riscos em Testes de Software (4)

Teste Baseado em Riscos


•Etapas / Atividades

Guilherme Motta 130


Riscos em Testes de Software (5)

Teste Baseado em Riscos


•Dificuldades:
• Análise de risco é algo abstrato e necessita de conhecimento/treinamento
para sua aplicação.
• Engenheiros de teste não possuem formação em gerenciamento de riscos.
• Não existe processo formal com atividades, papéis e artefatos definidos
que guie os engenheiros de testes.
• Não foram encontradas ferramentas específicas para a abordagem, o que,
provavelmente, dificulta sua aplicação e disseminação.

Guilherme Motta 131


Riscos em Testes de Software (6)

Modelo de Processo de Teste Baseado em Riscos

Guilherme Motta 132


Gerenciamento de Incidentes (1)

•Levando em consideração que um dos objetivos do teste é encontrar defeitos, as


discrepâncias entre o resultado atual e o esperado precisam ser registradas como incidentes.
•Incidente deve ser rastreável desde a descoberta, classificação até à correção e
confirmação da resolução.
•Para gerenciar os incidentes, a empresa deve estabelecer processos e regras para
classificá-los.
•Incidentes podem ser descobertos durante o desenvolvimento, o teste e a utilização do
software.
•Eles podem se revelar por problemas no código, por funções do sistema, documentação de
desenvolvimento, documentação de teste, manual de instalação ou manual do usuário.
•O Relatório de Incidentes tem os seguintes objetivos:
• Prover aos desenvolvedores e outros envolvidos um retorno sobre o problema para
permitir a identificação, isolamento e correção se necessário.
• Prover aos líderes de teste um meio para se rastrear a qualidade do sistema sob
teste e o progresso do teste.
• Prover idéias para aprimorar o processo de testes.

Guilherme Motta 133


Gerenciamento de Incidentes (2)

Os detalhes de um relatório de incidente podem incluir:


•Data da emissão, autor, status e organização.
•Resultados esperados e resultados atuais.
•Identificação ou item de configuração do software ou sistema.
•Processo do ciclo de vida do sistema ou software em que o incidente foi descoberto.
•Descrição da anomalia para permitir a resolução.
•Grau de impacto para os interessados (stakeholder) e severidade do impacto no sistema.
•Urgência / Prioridade na correção.
•Estado (status) do incidente (aberto, aceito, duplicado, aguardando resolução, aguardando
reteste ou fechado).
•Comentários gerais, tais como outras áreas que podem ser afetadas por uma mudança
resultante de um incidente.
• Mudança no histórico, como a seqüência de ações tomadas pela equipe envolvida no projeto
com respeito ao isolamento do incidente, reparo e confirmação da resolução.
•Referências, incluindo a identificação da especificação do caso de teste que revelou o
problema.
A estrutura de um relatório de incidente pode ser encontrada no “Padrão de Documentação de Teste de
Software”) IEEE 829, conhecido como relatório de irregularidades (anomaly report).
Guilherme Motta 134
Prática 7 – Gerenciamento de Testes de Software

1 – Ler os artigos: “Analise_das_Tecnicas_Estimativas_de_Esforco.pdf”;


“Documentation_Testing_In_Document_We_Trust.pdf”;
“Modelo_Processo_Teste_Software_Baseado_Riscos.pdf”;
“QTest_Metodologia_Teste_Qualidade_Processo_Software.pdf”. Faça seus
comentários.

2 – Monte um exemplo de Plano de Teste.

3 – Faça avaliação de risco do estudo de caso Marketing.

4 – Analise a planilha de estimativa TPA. Faça seus comentários.

5 – Analise o Relatório de Cobertura de Testes. Faça seus comentários.

Guilherme Motta 135


8 – Ferramentas de Suporte aos Testes de Software

Guilherme Motta 136


Ferramentas de Suporte aos Testes de Software (1)

Classificação das Ferramentas de Suporte aos Testes


Ferramentas para Gerenciamento de Testes:
• As ferramentas de gerência aplicam-se a todas as atividades do teste sobre o ciclo de
vida do software;
As características das ferramentas de Gerenciamento de Testes são:
• Dar suporte ao gerenciamento de testes e a suas atividades.
• Fazer a interface entre as ferramentas de execução, ferramentas de gerenciamento de
defeitos e ferramentas de gerenciamento de requisitos.
• Controle de versão independente ou uma interface com o gerenciador de configuração.
• Dar suporte a rastreabilidade do teste, resultados, e incidentes aos documentos de
origem, como especificação de requisitos.
• Registrar os resultados e gerar o relatório de progresso do teste.
• Análise quantitativa (métricas), relacionadas aos testes (ex: testes executados e testes
que passaram) e aos objetos de teste (ex: incidentes levantados), visando fornecer
informações sobre o objeto de teste e para controlar e melhorar o processo.

Guilherme Motta 137


Ferramentas de Suporte aos Testes de Software (2)

Ferramentas de Gerenciamento de Requisitos


•Armazenam, consistem, verificam a ausência e priorizam os requisitos, permitindo que os
testes sejam individualmente rastreáveis com relação aos requisitos, funções e/ou
funcionalidades.
•A cobertura dos requisitos, funcionalidade e funções por um conjunto de testes pode também
ser reportada.
Ferramentas de Gerenciamento de Incidentes
•Esta ferramenta funciona como o repositório e gestão dos incidentes (ex: defeitos, falhas,
problemas e
anomalias) e suporte para gerenciar tais incidentes incluindo:
• Facilidade na priorização dos incidentes.
• Facilidade na atribuição de tarefas (ex: corrigir o erro ou executar um teste de
confirmação).
• Atribuição de status (rejeitado, pronto para teste, movido para o próximo release).
• Estas ferramentas permitem que o progresso do incidente seja monitorado durante o
projeto.
• Muitas vezes provêem o suporte para análises estatísticas e relatórios.
• São conhecidas também como ferramentas de rastreamento de defeitos.
Guilherme Motta 138
Ferramentas de Suporte aos Testes de Software (3)
Ferramentas de Gerenciamento de Configuração
•Ferramentas de gerenciamento de configuração não são estritamente ferramentas de teste,
mas são necessárias para manter o controle da versão de diferentes builds de softwares e
testes.
As Ferramentas de Gerenciamento de Configuração:
• Armazenam todas as informações sobre as versões dos softwares e testware.
• Permitem a rastreabilidade entre testware, software e outros produtos relacionados.
• São particularmente úteis quando existem múltiplas configurações de ambiente
(hardware/software) (ex: diferentes sistemas operacionais, bibliotecas e compiladores,
diferentes browsers ou diferentes computadores.)
Ferramentas para Testes Estáticos
• As ferramentas de suporte ao processo de revisão podem armazenar as informações
sobre a revisão dos processos, comentários, relatarem os defeitos e esforço, gerenciar
as referências para revisar as regras ou check-lists, e manter o controle da
rastreabilidade entre os documentos e o código fonte.
• Pode também ajudar na revisão online, muito comum quando as equipes estão
distantes geograficamente.
• Ferramentas de análise estática ajudam os desenvolvedores, testadores e os
envolvidos com a qualidade a encontrar defeitos antes dos testes dinâmicos.
Guilherme Motta 139
Ferramentas de Suporte aos Testes de Software (4)

Ferramenta de suporte para especificação de teste


Ferramenta de Modelagem de Teste
• Ferramentas de modelagem de teste geram entradas de teste ou testes a partir dos
requisitos, de uma interface gráfica do usuário, dos diagramas de modelagem (estado,
dados ou objetos) ou do código.
• Este tipo de ferramenta pode gerar resultados esperados também.
• Os testes gerados de um modelo de estado ou objeto são úteis para verificar a
implementação do modelo no software, mas são raramente suficientes para verificar
todos os aspectos do software ou sistema.
• Outras ferramentas desta categoria podem ajudar no suporte da criação do teste
disponibilizando templates estruturados, algumas vezes chamados de test frames, que
geram testes ou simuladores de teste, agilizando a modelagem de teste.
Ferramentas para preparação de dados de teste
• Ferramentas que preparam os dados para testes manipulam a base de dados, arquivos
ou transmissão de dados, extraindo-os para serem utilizados em uma determinada
execução do teste.
• O benefício destas ferramentas é assegurar que a existência de dados transferidos a
um ambiente de teste é feita de forma a garantir a integridade destes dados.

Guilherme Motta 140


Ferramentas de Suporte aos Testes de Software (5)

Ferramenta de suporte para execução dos testes


• Ferramentas de execução do teste permitem que o teste seja executado
automaticamente, ou semi-automaticamente, usando dados de entradas e
resultados esperados através de um script.
Alguns tipos:
• Ferramentas de teste de unidade.
• Comparadores - determinam as diferenças entre os arquivos, banco de
dados ou resultado de testes.
• Ferramentas de medição de cobertura.
• Ferramentas de Segurança.
• Ferramentas de teste de performance, carga e estresse.

Guilherme Motta 141


Ferramentas de Suporte aos Testes de Software (6)
Os princípios para introduzir uma ferramenta em uma organização são:
• Avaliação da maturidade da organização, pontos fracos e pontos fortes na identificação de oportunidades para um
aperfeiçoamento do processo de teste com uso de uma ferramenta.
• Avaliação frente a requisitos claros e os critérios objetivos.
• A prova de conceito para avaliar a funcionalidade e determinar se a ferramenta atende os objetivos.
• Avaliação do fornecedor (incluindo treinamento, suporte e aspectos comerciais).
• Identificação dos requisitos internos para acompanhamento (mentoring e coaching) no uso da ferramenta.
Um projeto piloto tem os seguintes objetivos:
• Aprender mais detalhes sobre a ferramenta.
• Ver como a ferramenta poderá se adequar aos processos e práticas e como necessitariam mudar.
• Decidir as formas e padrões de uso, gerenciamento, arquivamento e manutenção da ferramenta e
artefatos de testes (ex: decidir a convenção dos nomes de arquivos, criação de bibliotecas e decidir a
modularidade dos grupos de teste).
• Estimar se os benefícios serão atingidos a um custo razoável.
Os fatores de sucesso para a permanência de uma ferramenta em uma organização incluem:
• Fazer o revezamento na utilização da ferramenta para os recursos da empresa (área de TI) de forma incremental.
• Adaptar e aprimorar o processo para combinar com o uso da ferramenta.
• Providenciar treinamentos para novos usuários.
• Definir um guia de usuários (de acordo com o processo estabelecido).
• Implementar um modo de aprender lições com o uso da ferramenta.
• Monitorar o uso e os benefícios da ferramenta.

Guilherme Motta 142


Prática 8 – Ferramentas de Suporte aos Testes de Software

1 – As ferramentas de suporte aos Testes pode ser classificadas em?

2 – Ler o artigo: “Ferramentas_Testes.pdf”. Faça suas considerações.

Guilherme Motta 143


9 – Desenvolvimento Baseado em Testes
TDD – Test Driven Development

Guilherme Motta 144


TDD – Test Driven Development (1)

•O que é?
• É orientar o desenvolvimento aos testes;
• Implementar o teste antes da funcionalidade;
• É uma mudança de comportamento.
•O ciclo do TDD é formado pelos seguintes passos [Beck 2003]:
• Adicione um pequeno teste;
• Execute todos os testes, mesmo que falhem;
• Faça uma mudança;
• Execute todos os testes e eles não devem falhar;
• Refatore o código para tirar duplicações.

Guilherme Motta 145


TDD – Test Driven Development (2)

TDD Mantra
• Costuma-se resumir esses passos no :

• Vermelho / Verde / Refatore - (Red / Green / Refactor):


1. Vermelho: Faça um pequeno teste que pode até não funcionar;
2. Verde: Faça o teste funcionar rapidamente;
3. Refatore: Elimine toda duplicação criada para fazer o teste funcionar;

Guilherme Motta 146


TDD – Test Driven Development (3)

Práticas do TDD
• Os testes devem ser fáceis e rápidos de se fazer, mas para isso, os sistemas
testados devem ser pouco acoplados e coesos, levando à necessidade de
refatoramentos em alguns casos;
• Ao se refatorar, sugere-se o uso de ferramentas que automatizem esse
processo para evitar que os testes sejam quebrados sem necessidade;
• Antes de testar, deve ser feita uma lista do que deve ser testado e das
condições que os testes irão verificar;
• Os testes feitos usando TDD não substituem testes de sistemas,
desempenho, estresse e usabilidade;
• Deve-se escrever o teste antes de escrever o código;
• Só é escrito algum código novo quando existir um teste automático falhando;
• Só fazer refactoring quando os testes forem de fato suficientes e quando ao
executá-los nenhum erro acontece (green bar);

Guilherme Motta 147


TDD – Test Driven Development (4)

Práticas do TDD
• Os testes devem ser capazes de ignorar uns aos outros completamente,
inclusive com relação a ordem de execução;
• Os dados utilizados nos testes devem torná-los fáceis de ler e seguir;
• Inclua resultados esperados e os reais nos testes e tente fazer bem aparente
essa relação (dados evidentes);
• Quando um erro for encontrado, a primeira coisa a fazer é escrever um teste
o mais simples possível que falhe;
• Uma vez que ele seja executado sem problemas, melhore-o.

Guilherme Motta 148


TDD – Test Driven Development (5)

Alguns argumentos para se utilizar TDD


•"TDD melhora a velocidade de desenvolvimento e a eficiência, porque encontrar
erros mais cedo torna-se barato e rápido."[Rohrl];
•"Se Programação Extrema parece extrema demais, inicie com o desenvolvimento
orientado a testes“ [Rohrl];
•O estilo de programação Vermelho / Verde / Refatore traz;as seguintes vantagens
[Beck 2003]:
• Reduz dramaticamente a densidade de defeitos do código;
• A garantia de qualidade passa de um trabalho reativo a um trabalho pró-ativo;
• Reduzem-se as surpresas, ajudando o gerente de projeto a estimar de forma
mais segura;
• É possível obter versões sendo entregues diariamente.
•"Executar testes imediatamente antes de fazer uma alteração e após ela faz a
pessoa se sentir bem e reduz o número de erros que ela pode cometer".

Guilherme Motta 149


TDD – Test Driven Development (6)

Referências

Guilherme Motta 150


Prática 9 – Desenvolvimento Baseado em Testes

1 – O que é TDD?

2 – Quais são as etapas do ciclo TDD?

3 – O que significa a figura abaixo?

Guilherme Motta 151


10 – Central de Testes

Guilherme Motta 152


Central de Testes (1)

Testes Independentes
•São realizados em ambientes maduros ou buscando maturidade;
•É um trabalho gerenciado, seguindo as mesmas práticas de gerenciamento de
projetos;
•CMMI nível 3 já considera a necessidade de certo nível de independência: pode
variar de um time dedicado até uma Organização Inteira somente para testes;
•Ajudam a diminuir riscos e aumentar a qualidade em:
• Empresas que terceirizam projetos de desenvolvimento e têm dificuldades em
homologá-los;
• Projetos grandes e/ou de alto risco;
• Gerenciamento de Níveis de Serviço (SLAs);
• Empresas com problemas com teste de homologação: Baixo envolvimento ou
preparo do usuário/ atrito entre TI e Negócios/ Falta de planejamento.

Guilherme Motta 153


Central de Testes (2)

Testes Independentes

Guilherme Motta 154


Central de Testes (3)

Modelo Operacional

Guilherme Motta 155


Central de Testes (4)

Modelo Operacional Detalhado

Guilherme Motta 156


Central de Testes (5)

Equipe

Guilherme Motta 157


Central de Testes (5)

Serviços

Guilherme Motta 158


Prática 10 – Central de Testes

1 – Esquematize (desenhe) uma Central de Testes.

2 – O que significa “Testes Independentes”? E por que contribuem no


gerenciamento dos Níveis de Serviço (SLAs)?

3 – Cite alguns serviços que podem ser prestados por uma Central de Testes.

Guilherme Motta 159


11 – Modelos de Maturidade em Testes

Guilherme Motta 160


Modelos de Maturidade em Testes (1)

•O que é um Modelo de Maturidade de Testes?


•Os modelos de maturidade surgiram para avaliar e melhorar o nível de
qualidade dos processos de testes aplicados numa organização
desenvolvedora de software ou em um bureau de testes;

•Avalia:
• Atividades executadas;
• Métodos utilizados;

•Define:
• Papéis e responsabilidades;
• Melhores práticas em Testes de Software.

Guilherme Motta 161


Modelos de Maturidade em Testes (2)

•Principais Modelos:
• Test Improvement Model (TIM);
• Test Process Improvement (TPI);
• Test Maturity Model (TMM).

•Outros Modelos:
• Maturity Model for Automated Software Testing (MMAST);
• Testing Capability Maturity Model (TCMM);
• Testability Support Model (TSM);
• Test Organization Maturity Model (TOM).

Guilherme Motta 162


Modelos de Maturidade em Testes (3)

TIM - Test Improvement Model


• Objetivos Principais:
• Identificação do estado atual do processo de testes;
• Guia para implementação de pontos fortes;
• Avaliação dos pontos fracos para Eliminar e Melhorar.

Guilherme Motta 163


Modelos de Maturidade em Testes (4)

TIM: Processo de Avaliação


1. Explicação sobre o modelo e sobre o processo de avaliação;
2. Entrevistas com pessoas chave:
• Questões : Sim/Não;
• Discussão sobre ausência de resposta.
3. Análise:
• Identificação do perfil de maturidade.
4. Identificação de melhorias:
• Sugestões de melhoria.
5. Análise da solução proposta:
• Alinhamento com necessidade da organização;
• Custo x Tempo x Recursos.
6. Apresentação da estratégia geral de melhoria

Guilherme Motta 164


Modelos de Maturidade em Testes (5)

TPI - Test Process Improvement


• É o modelo mais utilizado na Europa;
• Trabalha com 20 áreas-chave de conhecimento:
• Estratégia de teste (Test Strategy);
• Modelo de ciclo de vida (Lyfe-cicle model);
• Planejamento e estimativas (Estimation and Planning)
• etc.

• As áreas-chave podem ser classificadas em níveis de A – D.

Guilherme Motta 165


Modelos de Maturidade em Testes (6)

TPI - Test Process Improvement


Níveis de Classificação

Guilherme Motta 166


Modelos de Maturidade em Testes (6)

TPI - Níveis de Maturidade >> Área x Nível da Área-Chave


Controlado
• Todo o processo é executado de acordo com uma estratégia de testes, técnicas
de especificação de casos de testes são utilizadas, defeitos são registrados e
reportados.
• O testware (artefatos, ferramanetas, etc.) e o ambiente de testes são bem
controlados.
Eficiente
• A automação do processo de testes pode ser uma forma de alcançar a eficiência.
Em otimização
• O objetivo deste nível é garantir uma melhoria contínua.

Guilherme Motta 167


Modelos de Maturidade em Testes (7)

TPI - Níveis de Maturidade >> Área x Nível da Área-Chave

Guilherme Motta 168


Modelos de Maturidade em Testes (7)

TPI – Processo de Avaliação

Guilherme Motta 169


Modelos de Maturidade em Testes (8)

TMM – Test Maturity Model

Guilherme Motta 170


Modelos de Maturidade em Testes (9)

TMM – Test Maturity Model – Visão Geral

Guilherme Motta 171


Modelos de Maturidade em Testes (10)

TMM – Test Maturity Model – Nível 1

Guilherme Motta 172


Modelos de Maturidade em Testes (11)

TMM – Test Maturity Model – Nível 2

Guilherme Motta 173


Modelos de Maturidade em Testes (13)

TMM – Test Maturity Model – Nível 3

Guilherme Motta 174


Modelos de Maturidade em Testes (14)

TMM – Test Maturity Model – Nível 4

Guilherme Motta 175


Modelos de Maturidade em Testes (15)

TMM – Test Maturity Model – Nível 5

Guilherme Motta 176


Modelos de Maturidade em Testes (16)

Análise Comparativa entre Modelos

Guilherme Motta 177


Modelos de Maturidade em Testes (17)

Considerações

Guilherme Motta 178


Prática 11 – Modelos de Maturidade em Testes

1 – O que vem a ser um Modelo de Maturidade?

2 – Quais são os principais Modelos de Maturidade em Testes no momento?

Guilherme Motta 179


Prova Final

Guilherme Motta 180


Referências Bibliográficas

• Pezze, M., Young, M., Teste e Análise de Software: Processos, Princípios e Técnicas,
Bookman, 2008.
• B.Beizer. Software Testing Techniques. International Thomson Computer Press, 2ª ed,
1990.
• R.Binder. Testing OO Systems. Addison Wesley, 2000.
• G.J.Myers. The Art of Software Testing. John Wiley & Sons, 1979.
• W. de Pádua Paula Fº. Engenharia de Software. Ed. LTC, 2ª edi., 2002.
• I. Sommerville. “Software Engineering”. 6ª ed, 2000.
• Delamaro, M.E., Maldonado, J.C., Jino, M., Introdução ao Teste de Software, Série
Campus – SBC, Editora Campus, 2007.
• Koscianski, A., Soares, M.S., Qualidade de Software, Editora Novatec, 2006.
• Myers, G.J., The Art of Software Testing, 2nd edition, John Wiley & Sons, 2004.
• McGregor, J.D., Sykes, D.A., A Practical Guide to Testing Object-Oriented Software,
Addison-Wesley, 2001.
• Pressman, R.S., Engenharia de Software. 6a edição, McGrawHill, 2006.
• Base de Conhecimento para Certificação em Teste Foundation Level Syllabus - ISTQB.
• Bartie, A., Garantia da Qualidade de Software. 1ª edição, Campus / Elsevier, 2002.

Guilherme Motta 181

Você também pode gostar