testesdesoftware-091211102555-phpapp02

Prévia do material em texto

Testes de Software
Os Primeiros Passos em busca da 
Qualidade de Software
Gestão de Testes de Software
Conceituação de Testes de Software
Metodologia de Testes de Software
1
2
3
4
Temas abordados
Planejamento de Testes5
Técnicas de Testes de Software
Porque ocorrem falhas?
TESTE DE SOFTWARE
 O teste do software é uma das fases do processo de engenharia de software que 
visa atingir um nível de qualidade de produto superior. 
 O objetivo é mesmo o de encontrar defeitos no produto, para que estes possam 
ser corrigidos pela equipe de programadores, antes da entrega final. 
 A maioria das pessoas pensa que o teste de software serve para demonstrar o 
correto funcionamento de um programa, quando na verdade ele é utilizado como 
um processo da engenharia de software para encontrar defeitos. 
Definindo Teste de Software
TESTE DE SOFTWARE
O conceito de teste de software pode ser compreendido através de uma visão 
intuitiva ou mesmo de uma maneira formal. Existem atualmente várias definições 
para esse conceito. 
De uma forma simples, testar um software significa verificar através de uma 
execução controlada se o seu comportamento ocorre de acordo com o 
especificado. 
 O objetivo principal desta tarefa é encontrar o número máximo de erros dispondo 
do mínimo de esforço, ou seja, mostrar aos que desenvolvem se os resultados 
estão ou não de acordo com os padrões estabelecidos.
Definindo Teste de Software
Em uma situação ideal, nós como programadores, partindo do princípio que 
somos bons no que fazemos, poderíamos garantir que todos os programas 
funcionariam corretamente. 
Infelizmente esta não é a realidade. Isso porque os programas possuem um 
grande número de estados com fórmulas complexas, atividades e algoritmos. 
O tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvidas 
no processo aumentam ainda mais a complexidade. Assim, a presença de falhas 
é inevitável. 
Mas o que significa dizer que um programa falhou? 
Definindo Teste de Software
Basicamente significa que o funcionamento do programa não está de acordo com 
o esperado pelo usuário. 
Por exemplo, quando um usuário da linha de produção efetua consultas no 
sistema das quais só a gerência deveria ter acesso isto é uma falha. Esse tipo de 
falha pode ser originado por diversos motivos, como os listados abaixo:
• A especificação pode estar errada ou incompleta. 
• A especificação pode conter requisitos impossíveis de serem 
implementados, devido à limitações de hardware ou software. 
• Talvez a base de dados esteja organizada de forma que não seja 
permitido distinguir os tipos de usuário. 
• Pode ser que haja um erro no algoritmo de controle dos usuários 
• Pode ser que haja erros no código, o algoritmo pode estar implementado 
de forma errada ou incompleta. 
Por que ocorrem falhas?
Portanto, uma falha é o resultado de um ou mais defeitos em algum aspecto do 
sistema. 
O teste de software pode ser visto como uma parcela do processo de qualidade 
de software. 
A qualidade da aplicação pode, e normalmente varia, significativamente de 
sistema para sistema mas os atributos qualitativos comuns incluem 
• Fiabilidade
• Estabilidade
• Portabilidade
• Manutenção
• Flexibilidade 
• Usabilidade 
Por que ocorrem falhas?
Atualmente existem muitas maneiras de se testar um software. 
Mesmo assim, existem as técnicas que sempre foram muito utilizadas em 
sistemas desenvolvidos sobre técnicas estruturadas que ainda hoje tem grande 
valia para os sistemas orientados a objeto. 
Apesar de os paradigmas de desenvolvimento serem completamente diferentes, o 
objetivo principal destas técnicas continua a ser o mesmo que é: encontrar falhas 
no software. 
5.Caixa-Branca
7.Caixa-Preta
9.Caixa-Cinza
Técnicas de Teste de Software
CAIXA PRETA - Neste tipo 
de teste de software o 
desenvolvedor dos 
testes não possui 
acesso algum ao código 
fonte do programa. 
CAIXA BRANCA - Dentro 
desta categoria de teste 
de software o 
desenvolvedor tem acesso 
ao código fonte da 
aplicação e pode construir 
códigos para efetuar 
LINKER de componentes.
Técnicas 
popularizadas pelo 
mercado de software
Caixa Preta
Abaixo estão as três técnicas mais conhecidas
CAIXA CINZA - Uma 
definição deste tipo de 
teste seria um ponto de 
equilíbrio virtual entre o 
teste de caixa-branca e o 
caixa-preta. .
Técnicas de Teste de Software
Caixa-Branca (White Box)
Este tipo de teste é desenvolvido analisando-se o código fonte e elaborando-se 
casos de teste que cubram todas as possibilidades do programa. 
Dessa maneira, todas as variações originadas por estruturas de condições são 
testadas. Um exemplo bem prático deste teste é o JUnit para desenvolvimento com 
a linguagem Java e para a linguagem .NET o Project Analyzer.
Técnicas de Teste de Software
Caixa-Preta (Black Box)
O objetivo é efetuar operações sobre as diversas funcionalidades e verificar se o 
resultado gerado por estas está de acordo com o esperado.
Para esta categoria podem ser levados em consideração todos os eventos que 
podem ser disparados pelo usuário, como por exemplo, cada clique de mouse a ser 
realizado em uma interface.
Exemplos de teste caixa preta: 
•Teste de Valor Limite, 
•Teste de Classe de Equivalência
Técnicas de Teste de Software
Caixa-Cinza (Gray Box)
Esta técnica aparece com muitas interpretações na literatura de testes.
De uma maneira mais clara, o desenvolvedor dos testes não tem acesso ao 
código fonte da aplicação, porém tem conhecimento dos algoritmos que foram 
implementados, como também pode efetuar manipulações em arquivos de 
entrada e saída do tipo XML ou mesmo acessos ao banco de dados da aplicação 
para simples conferência de dados ou alteração de parâmetros considerados nos 
casos de teste.
Outros autores definem caixa-cinza como o teste de integração, onde você vê o 
sistema até o nível de módulo, mas não pode ver no interior dos módulos. 
Ainda é possível encontrar a definição de caixa-cinza como um teste onde 
algumas partes estão disponíveis como caixa-branca e outras como caixa-preta.
Técnicas de Teste de Software
Testes Alpha
(Alpha Test) 
 
No processo de desenvolvimento, os testes preferencialmente devem ser 
executados antes do produto ser disponibilizado aos usuários. 
Esse período entre o término do desenvolvimento e da entrega é conhecido 
como fase alpha e os testes executados nesse período como testes alpha. 
No início dos testes da fase alpha são utilizadas técnicas de caixa-branca. 
Posteriormente, os desenvolvedores dos testes aplicam técnicas de caixa-preta 
como complemento da primeira parte de testes. 
Fases de Teste de Software
Testes Beta
(Beta Test) 
Completada a fase alpha de testes, são lançadas a grupos restritos de usuários 
versões de teste do sistema, denominadas versões beta.
Conseqüentemente este período fica denominado como Fase Beta
Fases de Teste de Software
Testes Beta
(Beta Test) 
Através deste tipo de teste os usuários finais do produto podem encontrar 
defeitos peculiares de tarefas costumeiramente executadas por eles. 
Visando um maior retorno de informações sobre o mau funcionamento do 
sistema algumas empresas distribuem as versões betas para todo o 
universo de utilizadores. 
Paralelamente podem ser executados testes de caixa-preta durante essa 
fase, dando assim maior eficiência no processo.
Fases de Teste de Software
Versões Candidatas 
(Release Candidates)
Ultimamente, e principalmente na comunidade de software livre, é comum 
utilizar o termo release candidate para indicar uma versão que é candidata a 
ser a versão final, em função da quantidade de erros encontradas.
As RC, como são chamadas, são um passoalém do teste beta, sendo 
divulgadas para toda a comunidade.
Fases de Teste de Software
Categorias de Teste de Software
Teste de Unidade
Também conhecido como teste unitário. 
É um tipo de atividade que visa testar pequenas partes ou unidades do 
sistema. 
O universo alvo desse tipo de teste são os métodos dos objetos ou mesmo 
pequenos trechos de código. 
Assim, o objetivo é o de encontrar falhas de funcionamento dentro de uma 
pequena parte do sistema funcionando independentemente do todo.
Categorias de Teste de Software
Teste de Componente
 
 Este tipo de teste possui um universo um pouco maior do que o teste unitário. 
Seu propósito é testar o componente como um todo e não apenas as suas 
funções ou métodos. 
 Mesmo assim, o teste continua a ser executado sem considerar a interação com 
outras partes do sistema, ou seja, leva-se apenas em consideração o 
componente a ser testado e nenhuma outra entidade do sistema.
Categorias de Teste de Software
 
Teste de Integração
 O teste de integração, como o próprio nome já diz, visa encontrar falhas 
provenientes da integração dos componentes do sistema. 
Geralmente os tipos de falhas encontradas são de envio e recebimento de 
dados. 
Por exemplo, um objeto A pode estar esperando o retorno de um valor x ao 
executar um método do objeto B, porém este objeto B pode retornar um valor 
y, ou seja, diferente do esperado.
Categorias de Teste de Software
Teste de Sistema
Este é um teste de grande importância. 
Sua principal filosofia é varrer o sistema em busca de falhas através da utilização 
do mesmo, como se fosse um usuário final. 
Dessa maneira, os testes são executados nos mesmos ambientes, com as 
mesmas condições e com os mesmos dados de entrada que um usuário 
utilizaria no seu dia-a-dia de manipulação do sistema.
Categorias de Teste de Software
 
Teste de Aceitação
São realizados geralmente por um restrito grupo de usuários finais do sistema. 
Esses simulam operações de rotina do sistema de modo a verificar se seu 
comportamento está de acordo com o solicitado. 
Teste formal conduzido para determinar se um sistema satisfaz ou não seus 
critérios de aceitação e para permitir ao cliente determinar se aceita ou não o 
sistema. 
Validação de um software pelo comprador, pelo usuário ou por terceira parte, 
com o uso de dados ou cenários especificados ou reais. 
Pode incluir testes funcionais, de configuração, de recuperação de falhas, de 
segurança e de desempenho.
Categorias de Teste de Software
Equipe de Testes
4.Líder do Projeto de Testes
Técnico responsável pela liderança de um projeto de teste 
específico,normalmente relacionado a um sistema de 
desenvolvimento, seja um projeto novo ou uma manutenção.
6.Arquiteto de Teste
É o técnico responsável pela montagem da infraestrutura de 
teste, montando o ambiente de teste, escolhendo as 
ferramentas de teste e capacitando a equipe para executar o 
seu trabalho nesse ambiente.
Equipe de Testes de Software
Equipe de Testes
4.Analista de Teste
É o técnico reponsável pela modelagem e elaboração dos 
Casos de Teste e pelos Scripts de Teste.
Pode ser que em alguns casos os Scripts de Teste sejam 
elaborados pelos testadores.
6.Testador
Técnico responsável pela execução dos Casos de Teste e Script de 
Teste.
Equipe de Testes de Software
Por que Testamos Software?
 As empresas dependem muito dos seus softwares e um erro pode 
gerar grandes prejuízos financeiros ou de vidas humanas.
 A conseqüência é uma exigência muito maior por SQA em Qualidade 
de Software, uma das principais demandas a ser atendidas pelo 
mercado de desenvolvimento de software. 
Por que Testamos Software?
Estudos realizados pelo 
National Institute of Standards and Technology - em 2002, 
apontam que os prejuízos anuais com falhas de Softwares são 
de aproximadamente US$ 59,5 bilhões.
Esses estudos apontam que tal prejuízo poderia ser amenizado 
em 37% se houvesse maior investimento em infra-estrutura de 
teste de Sistemas, ou seja, US$ 22,0 bilhões
http://www.nist.gov
Por que Testamos Software?
Para ilustrar, uma taxa de 15% à 30% de defeitos a cada mil linhas de código é 
considerada aceitável para a indústria de TI, ou seja, todos os softwares têm 
defeitos, entretanto, os softwares realmente bons têm poucos defeitos críticos não 
corrigidos; promovendo assim um ambiente mais estável no ponto de vista do 
usuário final. 
O processo de desenvolvimento de software, por mais maduro que seja, ajuda 
apenas a reduzir a introdução de defeitos; contudo os processos também não são 
perfeitos. 
Mesmo os bons softwares, são repletos de defeitos. 
“Porque não existe software perfeito”
Por que Testamos Software?
A arquitetura e o desenvolvimento de software são atividades tão peculiares, tão 
dependentes da criatividade e da natureza imprevisível dos seres humanos que, às 
vezes, o processo aplicado com sucesso em certo projeto, provavelmente será um 
completo fracasso em outro projeto. 
Quem nunca viveu essa situação tão comum? 
“Porque não existe software perfeito”
Por que Testamos Software?
BUG é uma palavra genérica para representar qualquer classe de 
defeito. 
Esse termo foi introduzido quando os primeiros computadores, que 
eram feitos de válvulas, apresentavam algum tipo de problema 
inexplicável. 
Os engenheiros vasculhavam o interior do computador e, às vezes, 
descobriam que a origem dos problemas eram causados por insetos 
de verdade.
O Bad Boy dos testes
Algumas causas de bugs
d.Falta de comunicação entre os membros da equipe. 
e. A complexidade do software. 
f. Erros de programação. 
g. Mudança de requerimentos no meio do projeto.
h. Requerimentos ambíguos. 
i. Pressão da gerência sobre o prazo do projeto. 
O Bad Boy dos testes

Bottom-up Testing

Black Box Testing

Branch Testing

Boundary Value Analysis

Bug

Configuration Testing

COQ - Cost of Quality

Debug

End-to-End Testing

Integration Testing

Load Testing 

Pass/Fail Criteria 

Recovery Test 

Regression Test 

Test Case 

Test Plan
Entenda o significado
Bottom-up Testing 
Nesse tipo de teste cada módulo ou componente é testado individualmente e, 
pouco a pouco, os demais componentes são combinados e testados. Em 
alguns casos simuladores são utilizados no lugar dos componentes reais para 
substituírem alguns componentes que são necessários, porém não estão 
disponíveis ainda. 
Black Box Testing
Nessa estratégia, os testes são executados por meio do fornecimento de dados 
de entrada ao componente sendo testado e pela análise do resultado 
produzido, no entanto, sem entender ou verificar o processo que produziu o 
resultado. 
Entenda o significado
Configuration Testing
Nessa categoria de testes, os testes são executados contra todos os ambientes 
(hardware e software) suportados. A idéia é manter uma matriz contendo as 
plataformas/ambientes suportadas e o status da execução dos testes contra 
essas plataformas/ambientes. 
COQ - Cost of Quality
Custo gasto em atividades relacionadas ao processo de garantia de qualidade. 
O COQ inclui o custo de prevenção, medição, correção, materiais, 
equipamentos, etc. 
Debug
Processo onde o desenvolvedor depura o programa a fim identificar a causa de 
um defeito. Veja Também Bug. 
Entenda o significado
End-to-End Testing
Nessa categoria de teste, os testes contemplam cenários onde a aplicação ou 
determinado módulo da aplicação é testado do começo ao fim. 
Veja também Integration Test e Top-Down Testing. 
Integration Testing
Neste cenário os diversos sistemas que compõem uma solução de software são 
combinados e configuradosnum ambiente semelhante ao ambiente onde serão 
usados na vida real Dessa forma conseguimos testar o fluxo das operações do 
começo ao fim do ponto de vista do usuário final. Também conhecido como 
System Test. . 
Entenda o significado
Load Testing
Essa categoria de teste tem a função de aplicar uma carga de operações ou transações 
simultâneas contra a aplicação a fim de conferir se a aplicação atende os requisitos de 
performance ou resposta. Esse tipo de teste também é conhecido como Performance 
Testing. 
Pass/Fail Criteria
Comparação com o resultado esperado de um Test Case a fim de determinar se o teste 
passou ou falhou. 
Recovery Test
Classe de testes cuja principal função é avaliar como a aplicação lida com problemas 
inesperados e desastres. 
Entenda o significado
Regression Test
Essa abordagem tem a função de garantir que os módulos ou componentes da aplicação 
que não foram modificadas ainda funcionam corretamente após o programador modificar 
alguma outra parte da aplicação. 
Test Case
Conjunto de passos que descrevem um cenário de teste bem definido cuja principal 
função é comparar as respostas dos estímulos gerados pelos passos com um resultado 
esperado. 
Test Plan
Indica um documento que descreve o escopo das atividades de teste, a abordagem, os 
recursos humanos envolvidos, os módulos que serão testados, o schedule, riscos, etc. 
Entenda o significado
Test Suite
Indica um conjunto de Teste Cases que são agrupados por algum tipo de 
atributo em comum. 
Test Automation
Categoria de teste onde os testes são automatizados por meio da utilização de 
ferramentas e frameworks especializados para esse tipo de função. 
Test Coverage
Indica o percentual de tudo o que pode ser testado em relação ao que foi 
testado até agora. 
Top-Down Testing
Nessa categoria de teste, a aplicação é testada como um todo do início ao fim 
do ponto de vista do usuário final. Ou seja, o sistema é compilado 
completamente e o testador executa os Test Cases simulando situações de uso 
reais. 
Entenda o significado
UAT - User Acceptance Test ou Integration Testing
Conjunto de testes conduzido de forma garanta que o software atinge as 
necessidades do usuário final por meio da execução de cenários e dados de 
testes reais. 
Verification
Em resumo, o processo de Verification garante que o software está sendo 
desenvolvido conforme os padrões e processos definidos pela organização. 
Validation
Basicamente, o processo de Validation garante que o sistema está sendo 
escrito conforme o que está definido nos requisitos a fim de garantir que o 
software está sendo desenvolvido para atender as necessidades do cliente. 
Entenda o significado
II.Teste de Unidade
Codificação pequenas partes ou unidades do sistema como funções e métodos.
IV.Teste de Componente
Codificação do componente como um todo e não apenas as suas funções ou 
métodos.
VI.Teste de Integração
integração dos componentes do sistema.
VIII.Teste de Sistema
Atendimento dos requisitos funcionais e não funcionais do sistema testando 
como se fosse o usuário final.
X.Teste de Aceitação
para permitir ao cliente determinar se aceita ou não o sistema.
XII.Teste de Regressão
Aplicado na fase de manutenção do sistema, após sua implantação.
Fixando Categorias de Teste
As Técnicas de Teste mais populares são?
TESTE ESTRUTURAL (Caixa Branca)
Técnica de teste que adota critérios para a geração dos casos de teste com a 
finalidade de identificar defeitos nas estruturas internas do software, através de 
situações que exercitem adequadamente todas as estruturas utilizadas na 
codificação
TESTE FUNCIONAL (Caixa Preta)
Técnica de teste que adota critérios para a geração dos casos de teste com a 
finalidade de garantir os requisitos funcionais do software que foi construído 
sejam plenamente atendidos.
Fixando a Técnica de Teste
Ao se adotar uma técnica de teste seja ela FUNCIONAL ou ESTRUTURAL, é 
necessário escolher um critério para a elaboração dos casos de teste com a 
finalidade de testar os elementos do software.
Normalmente os elementos de um software, portanto ESTRUTURAL, que 
podem ser testados são: 
• as linhas de comando 
• as funções implementadas
• as variáveis definidas no software
• os loops existentes no software como: 
FOR, LOOP, WHILE, DO WHILE
• todos os ramos de uma decisão como:
IF (aninhado), CASE
 e os requisitos de software.
Fixando escolha do Critério
O critério de teste serve para orientar o testador na geração dos Casos de 
Teste.
Os elementos requeridos de um critério de teste são os elementos ou as 
características do software que deverão ser exercitados quando o software for 
testado. 
Os Casos de Teste gerados devem exercitar os elementos ou as 
características do software definidos por aquele critério.
• Testes de Funcionalidade
• Testes de Interface (Navegabilidade)
• Testes de Desempenho (Performance)
• Testes de Carga (Stress Test and Workload Test)
• Testes de Volume (Capacity Planning)
• Testes de Segurança
Onde aplicamos o Critério?
O QUE TESTAR?
Tipo de Teste
• Funcionalidade
• Interface
• Desempenho
• Carga (Stress e Workload)
• Usabilidade (Navegabilidade)
• Volume (Capacity Plan)
• Segurança
QUANDO TESTAR?
Fase do 
Desenvolvimento de 
Software
• Teste de Unidade
• Teste de Integração
• Teste de Sistema
• Teste de Aceitação
• Teste Regressão
Categorias ou Níveis 
de Teste
COMO TESTAR?
Técnica de Teste
Teste Funcional
• Particionamento de Equivalência
• Análise de Valores Limites
• Baseado em Casos de Uso
Teste Estrutural
• Testes de Caminhos
• Testes de Comandos
• Testes de Ramos
• Testes de Condições
• Testes de Condições Múltiplas
1
3
2
Critérios
Categorias ou Níveis, Tipos e Técnicas de Teste
Processos de testes requisitam recursos financeiros bastante altos, entretanto, 
sem testes não há como garantir a qualidade de software
Os custos de software também são extremamente altos, deste modo Softwares 
Livres sob Licença GPL podem reduzir drasticamente esses custos.
A desvantagem é que não são integrados, o que dificulta a implantação de um 
processo mais complexo. Portanto:
VII.Teste cedo,
VIII.Teste sempre,
IX.Teste o suficiente
Software Livre para Testes
TRABALHO DE PESQUISA
IV.Garantindo a Qualidade de Software com 
Ferramentas GPL
VI.Garantindo a Qualidade de Software para .NET
MODELOS TRADICIONAIS 
PARA
 TESTE DE SOFTWARE
Os 7 Conceitos Mágicos de Teste
I. Planejamento de Testes
II. Plano de Testes
III. Requerimento de Testes
IV. Procedimento de Testes
V. Script de Testes
VI. Ponto de Verificação
ORGANIZANDO-SE PARA OS 
TESTES 
Problemas, cuidados e desafios
Organizando-se para Execução de Testes
I. Problemas com Testes
II. Planejamento de Testes
III. Plano de Testes
IV. Testes X CMM
V. Metodologia de Testes
VI. Conclusão
PROBLEMAS COM TESTES
Problemas com os Testes 
- Teste de software não recebem a importância devida
- Teste de software não tem o foco adequado
- Preparação para os testes e ambiente de testes é 
inadequada
- Recursos são insuficientes ou inadequados
A equipe de testes é insuficiente
Resultados dos testes não são sempre analisados
Atividades e produtos de teste não seguem padrões 
Casos de testes com critérios inadequados
Problemas com os Testes 
 Planejamento é difícil porque não há base de históricos de teste
 Não há métricas disponíveis para estimativas de tempo, esforço 
etc.
 É diretamente dependente do processo de desenvolvimento de 
software
 Critério de parada é decisão difícil
Problemas com os Testes 
PLANEJAMENTO 
DE TESTES 
Problemas indicam necessidadede tratamento do 
processo de testes para:
• Planejar a capacidade
• Padronizar entradas e saídas
• Definir atividades e métodos 
• Estabelecer e coletar métricas
• Verificar o processo
Planejamento de Testes
eve ser tratado como um subprojeto ou um “path” 
dentro do projeto e passa a conter
Planejamento de Testes
1. Ambiente,
2. Preparação,
3. Estimativas,
4. Histórico,
5. Análise,
6. Realimentação,
1. Planos, 
2. Acompanhamento, 
3. Riscos, 
4. Recursos
5. Cronograma, 
6. Objetivos, 
Testes devem se integrar no processo de 
desenvolvimento de forma transversal
a) Testes têm de se sincronizar com gestão de configuração
b) Testes têm de agregar valor ao produto final dentro dos 
limites de custo, prazo e esforço do projeto.
Planejamento de Testes
Critérios de parada de testes
- fundamentalmente é decisão gerencial, porque diz respeito a recursos, 
alocação de pessoal .
- obrigatoriamente é decisão comercial porque influencia o custo, prazo.
- necessariamente é decisão do cliente quando identifica o nível de qualidade 
necessária para o produto.
Planejamento de Testes
PLANOS DE TESTES
O quê devem conter? 
II.Plano de testes operacional 
III.Plano de testes de regressão
IV.Plano de testes de desempenho
V.Testes de sistema
VI.Testes de aceitação
Planos de Teste
A - Visão Geral
- Escopo, métodos, padrões
B - Requisitos do ambiente de testes
- Hardware, Software, Pessoal
C - Gerenciamento dos testes 
- Equipe, Cronograma, Entradas, Produtos, Mecanismos de 
Análise, Relato e Acompanhamento, Procedimento de 
Controle e Ferramentas
Planos de Teste
Testes Estruturais
- Introdução ou Descrição,
- Objetivos,
- Métodos,
- ObjetosObjetos a serem testados,
- Eventos a serem testados,
- Ferramentas de teste
- Execução do teste,
- Verificação do teste.
Testes Funcionais
- Introdução ou Descrição
- Objetivos,
- Métodos,
- Funcionalidades a serem testadas,
- Projeto de dados para testes,
- Construção dos dados de teste,
- Ferramentas de teste
- Execução do teste,
- Verificação do teste.
Planos de Teste
RELAÇÃO ENTRE 
OS TESTES E O CMM
 Capacity Maturity Model envolve níveis de aperfeiçoamento 
(otimização) constante.
 Cerca de 92% das organizações desejam melhorar o seu 
processo de teste
 Testes são um dos 3 pontos mais votados para melhoria nas 
empresas de software
 Processo de teste de software é ineficiente é inadequado
Testes e CMM 
 Como o planejamento se encaixa no desenrolar das atividades 
de teste e do projeto?
 Metodologia Test-Rx oferece uma recomendação de processo 
de teste maduro (baseada no CMM) para resolver os problemas 
apresentados
Testes e CMM 
METODOLOGIA DE TESTES
 Definir Método 
 Obter recursos e pessoal
 Executar análise de riscos
 Estabelecer os objetivos dos testes
 Elaborar os planos de teste
 Projetar os casos de teste
 Executar testes operacionais
Metodologia de Testes 
 Executar testes de sistema e aceitação
 Analisar e relatar os resultados dos testes
 Executar testes de regressão
 Analisar e relatar os resultados dos testes de regressão
Metodologia de Testes 
Modelo X Metodologia
 Metodologia: conjunto de técnicas, métodos e estratégias voltadas 
para criação e/ou execução de algo, que em geral pode ser um ou 
mais produtos e/ou serviços.
 Modelo: Conjunto de técnicas que representa, ou que tenta 
representar, algo da realidade ou algum conceito.
MODELOS TRADICIONAIS
PARA TESTES DE SOFTWARE
MODELO WATERFALL
 Este foi um dos primeiros modelos de desenvolvimento de software 
que se autodenominava “Waterfall” ou Modelo em Cascata.
Verificação e Validação
Análise de Requerimentos
Verificação e Validação
Projeto
Verificação e Validação
Implementação
Verificação e Validação
Testes
Verificação e Validação
Manutenção
 As fases individuais ou atividades foram 
definidas assim de modo a representar a 
linha de desenvolvimento vigente na 
época. 
 Cada conjunto de atividades deveria ser 
completado como um todo antes de 
passar para o próximo conjunto de 
atividades. 
 O retorno a uma fase qualquer implicava 
em passar por todas as outras 
anteriores.
 No caso em questão, as atividades de 
teste somente começariam após a fase 
de implementação. 
 Fragilidade do Modelo
 A grande desvantagem para a qualidade 
do produto é que os testes eram a última 
fase do release do produto. Na prática, 
com isso os testes se tornavam de certa 
forma uma fase pela qual todos queriam 
passar rapidamente, acarretando um 
encurtamento natural dela.
MODELO WATERFALL
MODELO SAWTOOTH
 Esse modelo mostra uma interação entre o usuário e o 
desenvolvedor. 
Especificação dos 
Requerimentos
Protótipo 
Demonstração 1
Protótipo 
Demonstração 2
Análise de 
Requerimentos
Projeto de Sistema
Projeto de Objetos
Implementação
Teste de Unidade
Integridade & Teste
Integridade de 
Sistema & Teste
Aceitação do Cliente
Cliente
Desenvolvedor
Entendimento do Cliente
Entendimento do Desenvolvedor
 O desenvolvedor tem aqui um enfoque 
simples, semelhante ao de um pedreiro 
que faz uma obra numa casa
 Faz por encomenda, isto é, faz o que foi 
pedido. Poderíamos chamá-lo Modelo de 
Serra ou Visão Dentária
 Lembra a parte inferior de uma arcada 
dentária cujos dentes são pontiagudos.
 Fragilidade do Modelo
 Como o desenvolvedor está 
sobrecarregado de tarefas que não 
seriam somente dele, acaba que vários 
pontos de qualidade do projeto ficam a 
desejar.
MODELO SAWTOOTH
MODELO SHARKTOOTH
 Esse modelo é semelhante ao SawTooth Model, porém possui agora 
uma participação de um “gerente” que entra como um revisor do 
processo, de modo a tentar minimizar o “gap” de padrões de 
desenvolvimento e qualidade do produto junto ao desenvolvimento. 
Especificação dos 
Requerimentos
Protótipo 
Demonstração 1
Protótipo 
Demonstração 2
Análise de 
Requerimentos
Projeto de Sistema
Projeto de Objetos
Implementação
Teste de Unidade
Integridade & Teste
Integridade de 
Sistema & Teste
Aceitação do Cliente
Cliente
Desenvolvedor
Revisão de Projeto
Entendimento do Cliente
Entendimento do Gerente
Entendimento do Desenvolvedor
MODELO SHARKTOOTH
 A diferença entre este e o anterior é que 
quem fará a integração do sistema e seu 
respectivo teste é o gerente. 
 Alguém mais experiente. Dependendo do 
caso, passa a ser mais um complicador. 
 Esse modelo pode também ser chamado 
de Boca de Tubarão ou Testes de 
Tubarão porque parece com o sorriso de 
um tubarão. 
 Fragilidade do Modelo
 Ele apresenta muita característica 
política, pois o gerente se envolve em 
nível operacional para mostrar ao cliente 
que as coisas sairão do jeito que ele 
imagina, pois o gerente está participando 
de forma direta.
MODELO ESPIRAL
 O modelo em espiral na verdade é cíclico e faz uso da prototipação.
MODELO ESPIRAL
 Nesse modelo, os testes estão 
devidamente explicitados (análise de 
risco, validação de requerimentos e 
desenvolvimento, testes) e está dividido 
em estágios: modular, integração e 
testes de aceitação. 
 O detalhe é que nesse modelo os testes 
seguem a linha de codificação. 
 A exceção é que o plano de teste deve 
ser construído depois do projeto do 
sistema. 
 Fragilidade do Modelo 
 O modelo em espiral não identifica 
atividades associadas com a remoção de 
defeitos.
MODELO V
 Hoje podemos dizer que a maioria dos modelos de processo 
conecta-se graficamente a esse modelo, que se tornou um dos mais 
populares. 
 Ele descreve graficamente as fases individualmenteem forma de V. 
 Neste caso V vem de verificação e validação.
 Esse modelo é simples e fácil de ser 
entendido. 
 As atividades são ordenadas de forma 
seqüencial em níveis de abstrações de 
modo que as conexões com as fases de 
desenvolvimento ficam extremamente 
claras.
 Não devemos esquecer que se este 
modelo se tornou o modelo padrão de 
testes, foi devido a sua simplicidade que 
aponta claramente o que devemos fazer 
em linhas gerais.
 Fragilidade do Modelo
 A principal desvantagem é que do lado 
esquerdo temos fases mais construtivas 
enquanto no lado direito do V, temos 
fases mais destrutivas. 
 Isto faz com que exista uma competição 
ou concorrência entre equipes de 
desenvolvimento x equipes de testes. 
Quem é mais rápido? Quem constrói ou 
quem destrói?
 Uma desvantagem adicional é que não 
há um planejamento de remoção de 
defeitos e testes dos defeitos 
encontrados. 
 Os testes de regressão não são 
aplicados em lugar nenhum neste 
modelo.
MODELO V
MODELO W
 Hoje podemos dizer que esse modelo baseia-se no tão conhecido 
modelo V. 
 A diferença é que para cada etapa do modelo V teríamos uma etapa 
de testes que correspondesse a cada fase, de maneira que fosse 
possível eliminar os bugs desde o início. 
 No lado esquerdo teríamos um 
planejamento de cada fase, no lado 
direito do teríamos um teste de cada 
fase.
 O fato é que esse modelo visa de forma 
radical diminuir custos, partindo do 
princípio de que quanto mais se 
testasse, mais cedo se encontrariam os 
problemas. 
 A vantagem do modelo em W está onde 
cada atividade de teste trona-se mais 
clara.
 Fragilidade do modelo 
 Os problemas ficam minimizados, porém 
não resolvidos, tais como: cada lado 
possui uma parte construtiva e outra 
destrutiva.
MODELO W
MODELO BUTTERFLY
 Esse modelo também se baseia no modelo V e parte do pressuposto 
de que o modelo V tenta linearizar uma tarefa não linear. 
 Desta forma, uma vez que o desenvolvimento de software não é uma 
tarefa linear, os modelos baseados nesta premissa tendem a 
apresentar limitações e falhas. 
MODELO BUTTERFLY
 Um exemplo típico seria a fase de projeto ou design no modelo V, na 
qual poderiam existir micro-feedbacks que foram simplificados 
quanto a sua relevância, mas são de extrema importância. 
 Cada pequena atividade possui, na prática, pequenas fases de 
análise, projeto e execução (todas relativas a testes).
MODELO BUTTERFLY
 Na visão do Modelo Butterfly, cada pequena atividade (subfase) 
representaria um componente de um único ser que é mutável e tem 
vida curta. Neste caso, uma borboleta.
 A asa esquerda da borboleta seria a etapa de análise, a parte direita 
seria a própria análise e a parte central seria a execução dos testes 
propriamente ditos.
MODELO BUTTERFLY
 Se fizéssemos uma superposição das “micro etapas” no modelo V, 
teríamos algo semelhante ao gráfico abaixo
MODELO BUTTERFLY
 Da mesma forma, se usássemos a borboleta na imagem anterior, 
teríamos um modelo evolutivo, cujas subfases mostrariam que tudo 
que possui está em movimento e constante evolução.
CONCLUSÃO
 O processo de testes deve ser tratado como mais um processo 
de software
 Deve estar integrado ao desenvolvimento
 Deve iniciar juntamente com o projeto para propiciar 
realimentação 
 Fortemente baseado em lições aprendidas
Conclusão
	Slide 1
	Slide 2
	Slide 3
	Slide 4
	Slide 5
	Slide 6
	Slide 7
	Slide 8
	Slide 9
	Slide 10
	Slide 11
	Slide 12
	Slide 13
	Slide 14
	Slide 15
	Slide 16
	Slide 17
	Slide 18
	Slide 19
	Slide 20
	Slide 21
	Slide 22
	Slide 23
	Slide 24
	Slide 25
	Slide 26
	Slide 27
	Slide 28
	Slide 29
	Slide 30
	Slide 31
	Slide 32
	Slide 33
	Slide 34
	Slide 35
	Slide 36
	Slide 37
	Slide 38
	Slide 39
	Slide 40
	Slide 41
	Slide 42
	Slide 43
	Slide 44
	Slide 45
	Slide 46
	Slide 47
	Slide 48
	Slide 49
	Slide 50
	Slide 51
	Slide 52
	Slide 53
	Slide 54
	Slide 55
	Slide 56
	Slide 57
	Slide 58
	Slide 59
	Slide 60
	Slide 61
	Slide 62
	Slide 63
	Slide 64
	Slide 65
	Slide 66
	Slide 67
	Slide 68
	Slide 69
	Slide 70
	Slide 71
	Slide 72
	Slide 73
	Slide 74
	Slide 75
	Slide 76
	Slide 77
	Slide 78
	Slide 79
	Slide 80
	Slide 81
	Slide 82
	Slide 83
	Slide 84
	Slide 85
	Slide 86
	Slide 87
	Slide 88
	Slide 89
	Slide 90