1.
https://www.facebook.com/alvarofpinheiroaulas/
br.linkedin.com/in/alvarofpinheiro/
TESTES DE SOFTWARE
http://www.alvarofpinheiro.eti.br

2.
“O objetivo do Teste de Software
é encontrar bugs,
encontrá-los o mais cedo possível
e
garantir que os bugs sejam
corrigidos” (Patton, 2005)
http://www.alvarofpinheiro.eti.br

3.
TESTES DE SOFTWARE
INTRODUÇÃO
http://www.alvarofpinheiro.eti.br

4.
O que é um bug?
 Várias definições existem em cada empresa
 Um bug é: um defeito, falta, problema, incidente, anomalia, CR, etc.
 Empresas usualmente perdem um bom tempo discutindo isso
 Mas normalmente a conclusão é que um bug é apenas um bug
 Uma definição mais formal de bug pode ser feita se pensando
quando um bug ocorre [Patton, 2005]
 Um bug ocorre quando uma ou mais das opções abaixo for
verdadeira:
 O software NÃO faz algo que a especificação diz que ele deveria fazer
 O software FAZ algo que a especificação diz que ele NÃO deveria fazer
 O software faz algo que a especificação não menciona
 O software NÃO faz algo que a especificação NÃO menciona, mas
deveria mencionar
 O software é difícil de usar, entender, ou na visão do testador pode ser
visto pelo usuário final como não estando correto
http://www.alvarofpinheiro.eti.br

5.
Bugs clássicos:
 CD-ROM Rei Leão da Disney
 Lançado em 1994
 Primeiro CD-ROM da Disney (muita propaganda e grandes vendas)
 Lançado antes no natal
 Não foi testado em diferentes configurações de PCs e não informava a
configuração mínima
 Bug do ano 2000
 Computadores não estavam preparados para o ano 2000
 Sistema de Telefones de AT&T nos EUA
 Toda a rede caiu por causa de um switch case errado
 Sistema de Foguetes em Nara e Agência Européia
 O foguete explodiu no lançamento pois o código feito na Nasa estavam
no sistema métrico inglês e o da agência Européia no sistema
internacional
http://www.alvarofpinheiro.eti.br

6.
Qual o custo de um bug?
 O custo de um bug está diretamente associado a fase
do ciclo de desenvolvimento em que o bug é
encontrado
 Um bug encontrado durante a especificação
pode custar 1 dolar. O mesmo bug encontrado
no release pode custar 100x mais
http://www.alvarofpinheiro.eti.br

7.
Por que bugs ocorrem?
 Usualmente a razão de um bug ocorrer, depende do tamanho e
do tipo do sistema
Sistemas de Média e
Grande Porte
Sistemas de Pequeno Porte
http://www.alvarofpinheiro.eti.br

8.
Por que bugs ocorrem?
 Problemas de especificação são a principal causa de bugs
 Mais de 50%
 Em Sistemas Pequenos
 Problemas no código são a principal causa de bugs: 75%
 Erros durante a construção (low level design + code + unit tests +
integração) correspondem por pelo menos 35% dos erros
 Quanto maior o projeto menor o número de erros na construção é maior
o número na especificação
 Problemas se especificação são em geral o maior causador de bugs em
um software
 Quanto maior o software, maior o número de erros na arquitetura e
design de alto níve
http://www.alvarofpinheiro.eti.br

9.
Tipos de Bug
 Vários estudos buscaram definir tipos de bug e suas
porcentagens de ocorrência
 Nenhum dos estudos foi muito conclusivo, mas vários
pontos importantes foram levantados
 O escopo dos erros é limitado: 85% dos erros podem ser
corrigidos modificando apenas 1 rotina (classe) [Endres, 1975]
 Maioria dos erros não está no código, mas no domínio da
aplicação e não são problema do código em si
 Vários erros são simples erros de digitação: 35% dos erros de
código são erros de digitação [Weiss, 1975].
http://www.alvarofpinheiro.eti.br

10.
Tipos de Bug
 Maioria dos erros são simples de corrigir
 85% dos erros podem ser corrigidos em menos de 1 hora
 Apenas 1% dos erros levam mais que alguns dias para corrigir
 80% do esforço de manutenção é gasto em apenas 20% dos erros
 Os erros são concentrados em partes específicas do código
 80% dos erros está em apenas 20% do código [Endres, 1975]
 50% dos erros pode ser encontrado em 5% do código [Jones, 2000]
 Os testes que buscam identificar quais são essas partes
específicas do código podem reduzir em muito o custo de
manutenção
 Algumas vezes é melhor reescrever as rotinas nos quais os erros estão
concentrados
http://www.alvarofpinheiro.eti.br

11.
Por que testes precisam se realizados?
 Existem várias técnicas de encontrar bugs
 Nenhuma técnica consegue garantir que TODOS os bugs sejam
encontrado
 Testes de software é uma das possíveis técnicas que podem ser
aplicadas
 Nenhuma técnica consegue encontrar mais de 85% dos bugs
 Testes unitários + testes de componente + testes de sistemas
atingem no máximo 60% dos bugs
http://www.alvarofpinheiro.eti.br

12.
Por que testes precisam se realizados?
 Testes precisam ser realizados, mas não são suficientes para
garantir que todos os bugs sejam encontrados
 O ideal é combinar diferentes técnicas para garantir que a maioria
dos bugs sejam encontrados o mais cedo possível
 Algumas organizações chegam a atingir 95% de bugs encontrados
combinando diferentes técnicas
 Vários estudos comparam eficiência de técnicas de encontrar
bugs
 Grupo de programadores com média de 11 anos de experiência
 Avaliou um código com 15 erros conhecidos
 3 técnicas foram usadas
 Testes contra a especificação
 Execução de testes unitários e de sistemas
 Inspeções da especificação e dos testes unitários
 Em média apenas 5 erros foram encontrados
 Testes usualmente atingem no máximo 50-60% de cobertura
[Johnson 1994]
http://www.alvarofpinheiro.eti.br

13.
O que testar?
 Definir o que testar no software é uma decisão fundamental
 Essa definição deve levar em conta a “qualidade final” do
software
 Qualidade do produto  “satisfação final do usuário”
 Satisfação do usuário  “experiência de uso” do software
 Caso a “experiência de uso” seja boa a satisfação final do usuário
será boa, mesmo que o software ainda apresente bugs
Todas as funcionalidades que apresentam
riscos para a qualidade do software DEVEM ser testadas
http://www.alvarofpinheiro.eti.br

14.
Riscos
 É importante identificar quais os possíveis problemas que podem
causar dificuldades na realização das atividades de teste?
 Cada possível problema é chamado de “risco”
 Para cada risco deve-se avaliar pelo menos
 Probabilidade de ocorrer
 Plano de contingência caso o risco de torne um fato
 Prioridade do risco
 Outros aspectos podem ser avaliados para cada risco de acordo
com o processo de gerenciamento de risco da organização
http://www.alvarofpinheiro.eti.br

15.
O que testar?
Experiência de uso
Software Usuário
Testes
Testes
Software Usuário
Os testes estão cobrindo
As áreas com riscos para
qualidade
http://www.alvarofpinheiro.eti.br

16.
Conceitos em Testes de Software
 Processos de Testes
 Estágios de Teste
 Tipos de Teste
 Abordagens de Teste
 Procedimentos de Teste
 Projetos de Testes
 Técnicas de Testes
 Ferramentas de Testes
http://www.alvarofpinheiro.eti.br

17.
Foco de Teste
 O foco dos testes muda de acordo com o estágio de testes sendo
realizado, assim como o testador realizando a atividade
 Este foco varia de
 Testes de estruturais
 Testes comportamentais
 Testes reais
Desenvolvedor Engenheiro de Testes Usuário
Testes
Estruturais
Testes
Comportamentais
Testes
Reais
http://www.alvarofpinheiro.eti.br

18.
Foco de Teste – Testes Estruturais
 Buscam encontrar erros internos no software.
 Focam diretamente no código
 Encontram erros como
 Um método pode estar recebendo um inteiro de 24 bits e tentando
guardá-lo em 16 bits
 Um algoritmo específico pode não estar tratando todos os possíveis
fluxos de execução
 Testes estruturais estão associados ao estágios de teste unitários
e de componente
 Eles são realizados então pelo desenvolvedor de software ou por
um desenvolvedor de software em testes (testes de componente)
http://www.alvarofpinheiro.eti.br

19.
Foco de Teste – Testes Comportamentais
 Encontram erros de mais alto nível no domínio da aplicação e
não mais no código
 Focam nas funcionalidades do sistema como um todo
 Encontram erros como
 Um usuário sem permissão conseguem realizadas operações sensíveis
do sistemas
 O sistema não implementa uma determinada regra de negócio como
deveria
 Testes comportamentais estão associados aos testes de sistema
 Eles são realizados usualmente por engenheiros de teste
http://www.alvarofpinheiro.eti.br

20.
Foco de Teste – Testes Reais
 Encontram erros no sistema como um todo, mas agora focando nas
necessidades finais do usuário
 Usuários reais tendem a encontrar problemas que não são vistos pelos
engenheiros de teste
 Os tipos de erros encontrados podem ser parecidos com os
encontrados nos testes comportamentais
 Também podem ser encontrados erros como
 Uma funcionalidade bem importante pode estar escondida em um sub-menu em
vez de estar exposta mais claramente
 A forma como o sistema foi implementado não está resolvendo o problema do
usuário
 Estes testes usualmente são realizados por usuários finais
 Os testes reais estão associados a um teste de aceitação
http://www.alvarofpinheiro.eti.br

21.
Procedimento de Teste
 O procedimento de testes está diretamente relacionado ao
conceito de caso de teste
 Cada caso de teste está associado a um diferente “cenário” a
ser testado
 Para cada requisito existem diferentes cenários a serem testados
 Para validar um caso de testes é necessário
 Definir o ambiente no qual o teste será realizado
 Definir a entrada deste caso de teste
 Definir a saída esperada para cada entrada
 Definir os passos a serem realizados para executar os testes
 O conjunto de passos acima determina o que um procedimento
de testes
http://www.alvarofpinheiro.eti.br

22.
Resultado de Testes
 Quando cada caso de teste é executado, o seu resultado deve
ser coletado
 Existem diferentes abordagens para definir o resultado de um
caso de teste especifico
 A mais comum define as seguintes opções
 Passou  todos os passos do caso de testes foram executados com
sucesso para todas as entradas
 Falhou  nem todos os passos foram executados com sucesso para
uma ou mais entradas
 Bloqueado  o teste não pode ser executado, pois o seu ambiente não
pode ser configurado, ou pode alguma dependência externa
http://www.alvarofpinheiro.eti.br

23.
Testes: Cerificações
O maior problema das certificações são a falta de padronização
em seus conteúdos. Por isso, é indicado se que escolha o
programa que mais se adéqua as necessidades da empresa e se
incentive as pessoas a tirá-la e a experiência é insubstituível.
American Society for Quality’s (ASQ)
Certified Software Quality Engineer (CSQE);
Quality Assurance Institute’s (QAI)
Certified Software Test Engineer (CSTE)
International Institute for Software Testing’s (IIST)
Certified Software Test Professional (CSTP)
Institute of Electrical and Electronic Engineers’ (IEEE)
Certified Software Development Professional (CSDP)
British Computer Society’s (BCS)
Information Systems Examination Board (ISEB)
http://www.alvarofpinheiro.eti.br

24.
Testes: Modelo de Documento
Missão: <uma breve sentença sobre a missão dessa sessão>
Áreas: <area1 do requisito1> <area2 do requisito2> <...etc>
Início: <data e hora de início>
Testador: <nome do testador>
Tarefas: <descrição das atividades>
Duração: <os valores são "curta", "normal", ou "longa”>
Preparação da Sessão: <% da duração da sessão gasta na preparação, entre 0-100>
Projeto e Execução de Testes: <% da duração da sessão gasta procurando bugs, entre 0-100>
Investigação e Reportagem dos Bugs: <% da duração da sessão gasta investigando problemas, 0-100>
Descrição x Oportunidade: <descrição da duração da sessão que foi gasta na missão de investigação>
Arquivos de Dados: <a sintaxe é o formato do aquivo ex.: "foo.bat“ e se não houver arquivos de dados, #N/A>
Notas dos Testes: <formato de texto livre>
Bugs: <listar os bugs com uma tag #BUG, o formato do texto é livre e se não houverem bugs, usar #N/A>
Exemplo para Bugs encontratos:
#BUG Título do bug
Passos para reprodução:
1 - …
2 - …
Resultado: ...
Esperado: ...
Issues: <o mesmo formato da sessão de BUG acima, se não houverem ISSUES, use #N/A>
http://www.alvarofpinheiro.eti.br

25.
TESTES DE SOFTWARE
EQUIPES
http://www.alvarofpinheiro.eti.br

26.
Equipes de Testes
Existem várias maneiras de se organizar testes, porém
a forma que se mostra mais adequada é a criação de
um grupo independente de teste.E independência
significa reconhecer os engenheiros de teste como
especialistas, ou seja, não são desenvolvedores e
respondem a uma gerência independente da gerência
de desenvolvimento. É importante salientar, que
engenheiros de teste possuem responsabilidades
diferentes e, consequentemente, evoluem
diferentemente, e que devem ser imparciais e não se
influenciarem pela pressão do desenvolvimento.
http://www.alvarofpinheiro.eti.br

27.
Equipes de Testes: Times Independentes
A funcão principal desse time é fazer testes, seja para um ou
vários produtos. Ele não deve estar subordinado a mesma
gerência de desenvolvimento, o que faz com que esse time não
sofra as pressões internas de prazo de entrega do produto. Essa
maneira tem uma grande
vantagem de ter profissionais especializados em testes e a
garantia de que os testes podem ser realizados tão bem quanto o
desenvolvimento do sistema. Sua desvantagem é que, por
passarem a existir dois times onde um tem a missão de encontrar
problemas no que o outro desenvolveu, pode começar a haver
desentendimentos entre esses eles. Entretanto, isso pode ser
minimizado a nível gerencial, lembrando sempre que ambos
estão contribuindo para a qualidade do produto final que é parte
do esforço de ambos; estimulando a comunicação entre os times;
inicializando o processo de teste o quanto antes.
http://www.alvarofpinheiro.eti.br

28.
Equipes de Testes: Times Integrados
Os engenheiros de teste e os engenheiros de sistemas
fazem parte de um mesmo time. Normalmente, é o que acontece
em empresas projetizadas. Como todos fazem parte de um
mesmo time, é mais fácil fazer com que os testes sejam iniciados
cedo. Contudo, pelo mesmo motivo, é difícil captar bons recursos,
pois, geralmente eles já estão em outras equipes. Um outro
problema que ocorre com frequência é que, pelo fato do
gerente ser encarregado tanto do desenvolvimento quanto do
teste, ele pode se sentir mais tentado a entregar o produto no
prazo acordado para não ferir seu cronograma, fazendo com que
o serviço de teste seja comprometido por encurtar o tempo
anteriormente planejado para o teste.
http://www.alvarofpinheiro.eti.br

29.
Equipes: Desenvolvedores
São responsáveis por desenvolver e testar os sistema os
problemas de comunicação são eliminados; a priorização da
correção de bugs torna-se mais fácil; o bom conhecimento do
design e do código faz com que seja mais fácil de encontrar qual
a razão do bug. Porém, outros problemas vêm à tona, como: a
falta de um conhecimento mais aprofundado do negócio limita o
nível de teste a ser feito; a falta de conhecimento técnico de tipos,
estratégias, métodos, processos de teste dificulta à realização do
serviço de teste; a experiência com programação faz com que
eles fiquem tentados, e às vezes limitados, a testar apenas o que
o sistema deve fazer, não criando cenários de teste onde se tem
de fato a maior probabilidade de encontrar bugs.
http://www.alvarofpinheiro.eti.br

30.
Equipes: Coordenadores de Testes
Quando não existe grupo de testes, um coordenador de teste
Deve ser escolhido para formar e liderar um time temporário de
teste que poderá ser composto por desenvolvedores,
engenheiros de qualidade, vendedores, usuários, etc. O
coordenador escolhido deve ter um perfil pré-estabelecido para
que se tenha sucesso nesse modelo, como por exemplo:
experiência, credibilidade, boa comunicação e habilidades de
gestão. Ainda assim, ele irá enfrentar problemas com a captação
de recursos, pois como o time é temporário, os melhores recursos
não serão facilmente cedidos por seus gerentes definitivos. A
falta de pessoas experientes, de um ambiente de teste, de casos
de teste já existentes, são outros problemas que o coordenador
terá de encarar. Um dos motivos de se usar essa estratégia é
quando se tem a necessidade emergente de se fazer teste e não
se tem tempo, dinheiro e conhecimento para se formar um time
de testes.
http://www.alvarofpinheiro.eti.br

31.
Equipes: Time de Qualidade
Em algumas organizações o time de qualidade é responsável
também pelos testes. O fato das habilidades necessárias serem
bastante parecidas, ajuda os engenheiros de qualidade a terem
uma maior empatia pelas atividades de teste e,
consequentemente, desempenhá-las com sucesso. Um fator
preocupante nessa estratégia é que testes seria uma
responsabilidade a mais para o time o que pode dificultar
fazer com que os testes sejam realizados com eficiência.
http://www.alvarofpinheiro.eti.br

32.
Equipes: Terceirização
Terceirizar testes pode ser uma boa solução quando há falta de
verba pra fazer teste internamente, falta de conhecimento técnico
em testes ou falta de um ambiente propício. É importante
salientar que apesar de estar contratando um serviço bem melhor
do que o que possa ser oferecido de forma rápida internamente, o
contratado possivelmente não terá o entendimento do negócio tão
bem quanto o contratante. Além disso, o fato de se terceirizar os
testes não elimina a responsabilidade da qualidade do produto
que está sendo desenvolvido. Por isso, é importante que haja um
acompanhamento do serviço que está sendo prestado. Para se
ter sucesso nessa estratégia é recomendável que se tenha um
bom contrato, contratar as pessoas certas, estabelecer entregas
bem definidas, ter padrões de qualidade e ter uma boa visão do
serviço do contratado.
http://www.alvarofpinheiro.eti.br

33.
Equipes: Empresa de V&V
Normalmente, são realizados por um contratante independente e
ao final do desenvolvimento, o que reduz maiores riscos de ter
um produto funcionando com defeitos mas também pode elevar
consideravelmente os custos. Por ser extremamente caro
contratar uma empresa de Validade e Verificação (V&V), elas são
geralmente contratadas quando se tem projetos do governo,
quando se corre risco de vida no uso do sistema, em projetos de
prestígio nacional, etc.
http://www.alvarofpinheiro.eti.br

34.
Papeis: Gerente de Testes
São pessoas que precisam lidar com organizações que
processam muitas linhas de comunicação formal e informal. Eles
precisam lidar com recursos com vários níveis de habilidades,
ferramentas, orçamentos e estimativas. O gerente é quem está à
frente do time os representando nas mais diversas situações
dentro e fora da empresa, o que pode afetar a percepção que as
pessoas que estão fora do time de teste têm sobre este time.
Deve atuar como provedor de informações, servindo de canal de
comunicação de informações entre o trabalho realizado pela
equipe e os stakeholders do projeto. Algumas informações
importantes, por exemplo, seriam: status reports, planos,
estimativas, relatórios de eficiência.
http://www.alvarofpinheiro.eti.br

35.
Papeis: Engenheiro de Testes
Os requisitos para essa função são: Conhecimento do negócio da
aplicação; Conhecimento técnico de testes; e Habilidades
específicas. E as habilidades são: Dinamismo; Pensamento
crítico; Comunicativo; Criatividade; Curiosidade; Maturidade;
Trabalho em equipe; Facilidade de relacionamento interpessoal;
Auto-motivação; Iniciativa; e Atenção aos detalhes. Fontes são:
Desenvolvedores, excelentes para testes unitários, integração. E
testes automáticos;Usuários, pois possuem um bom
conhecimento do negócio do sistema, mas possuem pouco
conhecimento técnico; Suporte, estão acostumados a descobrir
problemas normalmente enfrentados pelos colaboradores da
Empresa; Techinical Writers, produzem documentos técnicos e
prestam bem atenção aos detalhes, podendo serem ótimos em
reportar bugs, criar e organizar suites e ciclos de teste, elaborar o
plano de testes; Engenheiros de Qualidade, dão importância a
qualidade do software e da utilização do processo.
http://www.alvarofpinheiro.eti.br

36.
Quem é o testador?
 O testador está diretamente associado a definição de teste
de software
 O testador
 Encontra o bug
 Busca encontrá-lo o mais cedo possível
 Garante que o bug está corrigido
 Um bug corrigido não necessariamente implementa em
mudança no código
 Correção de um manual
 Correção de treinamento
 Etc.
 O testador deve ser responsável por verificar realmente se
o bug foi corrigido
http://www.alvarofpinheiro.eti.br

37.
Quem é o testador?
 Por que o testador é necessário?
 Os testes feitos por desenvolvedores
 Tendem a verificar apenas o “caminho feliz”
 Normalmente são otimistas
 Não são sofisticados
 Organizações iniciais tem usualmente 5 testes de “caminho
feliz” para cada teste de “caminho alternativo”
 Organizações maduras usualmente tem o oposto - 5 de caminho
alternativo para cada um de caminho feliz
 Desenvolvedores normalmente só conseguem enxergar 50-60%
dos casos de teste do seu código
 O Testador tem um perfil diferente do desenvolvedor
 São exploradores
 Gostam de encontrar problemas
 Criativos no uso do software
 Visão das diferentes situações em que o software pode ser
usado
http://www.alvarofpinheiro.eti.br

38.
Principais Papéis em Testes
 Pode-se identificar 4 papéis principais para as atividades
de testes
 Gerente de Testes  Monta o plano de testes e faz o
acompanhamento de todas as atividades relativas aos testes
 Projetista de Testes  Identifica os casos de teste e escreve os
procedimentos para cada um deles
 Desenvolvedor de Testes  Implementa os casos de teste
automático que foram projetados pelo projetista
 Testador  Executa os casos de teste e preenche o resultado
de testes
 Estes papéis podem ou não ser realizados pela mesma
pessoa
 Isso depende de cada organização ou do tamanho / escopo do
projeto
 Existem outros termos que podem ser usados para
descrever os papéis em atividades de teste
 Durante o restante do módulo serão usados os termos definidos
acima
http://www.alvarofpinheiro.eti.br

39.
TESTES DE SOFTWARE
CICLO DE VIDA
DE UM BUG
http://www.alvarofpinheiro.eti.br

40.
Ciclo de Vida de um Bug
 O ciclo de vida de um bug determina os vários estágios pelos
quais o bug passa durante o desenvolvimento do software
 Este ciclo de vida precisa ser definido nas organizações
 O processo de controle de mudanças é responsável pode definir o ciclo
de vida
 O ciclo de vida pode ser bem simples
 Aberto: bug identificado no teste
 Resolvido: bug resolvido
 Fechado: solução verificada
http://www.alvarofpinheiro.eti.br

41.
Ciclo de Vida de um Bug
 O ciclo de vida também pode ser bem complexo
 Aberto
 Resolvido como não corrigir
 Resolvido como corrigido
 Fechado como corrigido
http://www.alvarofpinheiro.eti.br

42.
Ciclo de Vida de um Bug
 Algumas organizações adotam para o bug um ciclo de vida
similar ao de desenvolvimento de um software
 Iniciado: bug descrito
 Análise: bug analisado e especificado
 Implementação: bug implementado
 Testes: bug testado
 Fechado: bug fechado de o teste for correto
http://www.alvarofpinheiro.eti.br

43.
Ciclo de Vida de um Bug
 O ciclo de vida genérico para um bug pode ser como o
apresentado abaixo
 O estado importante a ressaltar e o de análise
 Nele o bug é avaliado para identificar se é ou não para ser corrigido
 Esse papel é executado por um CCB
http://www.alvarofpinheiro.eti.br

44.
Ciclo de Vida
Revisado
Rejeitado
Aberto Atribuído Trabalho Fechado
Reaberto Adiado
http://www.alvarofpinheiro.eti.br

45.
TESTES DE SOFTWARE
MODELOS
http://www.alvarofpinheiro.eti.br

46.
Engenharia de Software
 As atividades de testes são inseridas no contexto das atividades
de engenharia de software
 TODO software segue um ciclo de vida
 Existem vários modelos de ciclo de vida que podem ser adotados
durante o desenvolvimento
 O modelo de ciclo de vida usualmente direciona
 Quais testes serão rodados
 Quando os testes serão rodados
 Os seguintes modelos serão discutidos
 Cascata
 V
 Incremental
 Codificar e testar
http://www.alvarofpinheiro.eti.br

47.
Modelo Cascata
 Fases seqüências que produzem o software
 Ao final de cada fase uma revisão interna deve validar se é
possível passar a fase seguinte
 A princípio só se deve passar a fase seguinte com a anterior
finalizada
 Foco principal é garantir que a especificação é bem feita antes de
iniciar as fases seguintes
http://www.alvarofpinheiro.eti.br

48.
Modelo Cascata
 O modelo em cascata é ideal para softwares bem conhecidos
 Sem grandes surpresas durante a especificação
 Tecnologia bem conhecida da equipe
 A fase de testes é bem natural e é executada após toda a
codificação
 Principal vantagem para os testes
 A especificação normalmente é bem feita e detalhada
 Principal problema
 Os testes só são executados no final
 O custo de corrigir um problema é mais alto
http://www.alvarofpinheiro.eti.br

49.
Modelo V
 Variação do modelo em cascata
 Associa diferentes tipos de teste de acordo com a fase do ciclo
de vida
 Testes de aceitação usualmente estão associados aos requisitos
 Testes de Integração usualmente estão associados ao design
 Testes de componente usualmente estão associados ao código
http://www.alvarofpinheiro.eti.br

50.
Modelo V
 O modelo V define diferentes estágios de testes para
serem executados
 Pode ser visto como uma extensão do modelo em cascata
 Ainda existe a ênfase na especificação
 Cada fase precisa ser finalizada antes do início da fase seguinte
 Também é ideal para softwares com requisitos conhecidos
 A grande vantagem do modelo é:
 Identificar os diferentes estágios de teste que validam aspectos
do ciclo de vida do software
 Permite um melhor planejamento dos testes que precisam ser
executados
 “Quebra” os testes em diferentes focos
 A principal desvantagem é:
 Os testes ainda são rodados apenas após o código estar pronto
http://www.alvarofpinheiro.eti.br

51.
Modelo Incremental
 Desenvolvimento é “quebrado” em várias iterações
 Cada interação pode ser vista como uma pequena cascata
 Cada interação passa por todas as fases do ciclo
 Em maior ou menor escala
 Requisitos são adicionados ao software em cada iteração
http://www.alvarofpinheiro.eti.br

52.
Modelo Incremental
 O modelo incremental busca usar as vantagens do cascata
 Focar em ter uma boa especificação
 Mas sendo realista
 Nem toda a especificação pode estar pronta no início do
desenvolvimento
 As iterações podem ser repetidas até que o software esteja
estável
 Ao final cada iteração é necessário
 Determinar os objetivos da próxima iteração
 Avaliar os riscos
 Avaliar os testes
 Avaliar os requisitos que já estão implementados
 Planejar a iteração seguinte
http://www.alvarofpinheiro.eti.br

53.
Modelo Incremental
 A principal vantagem para os testes é
 Os testes são rodados várias vezes (ao final de cada iteração)
 Os bugs podem ser antecipados
 Os testadores usualmente podem (e devem ser) envolvidos no projeto
desde o início
 A principal desvantagem para os testes é
 Algumas vezes não fica claro que testes devem ser rodados ao final de
cada iteração
 O esforço de planejamento de testes é maior
 Mas esse esforço normalmente é compensado
 É necessária uma equipe de testes mais experiente para planejar e
executar testes neste modelo
http://www.alvarofpinheiro.eti.br

54.
Modelo Codificar e Testas
 Parte de uma especificação informal
 Ênfase em codificação
 Não existe ênfase em outras fases do desenvolvimento
 Como a especificação não é clara os testes também não são
 Mas os testes são executados várias vezes
 É ideal para projetos pequenos e com equipe pequena
 Principal vantagem para os testes
 Vários ciclos de testes
 Custo de correção não é alto
 Principal desvantagem para os testes
 Planejamento e qualidade dos testes normalmente não é boa
http://www.alvarofpinheiro.eti.br

55.
Modelo Ágeis
 Muito parecido com o codificar e testar
 Foco em fechar várias versões do software
 Integração continua
 Especificação de requisitos informal
 Mas o cliente final DEVE ficar próximo a equipe de desenvolvimento
para validar os requisitos
 Mas os testes
 São mais formais
 Devem ser automatizados
 Garantir que sempre serão rodados
 São executados a cada integração
 Cliente pode participar da validação
 Principal vantagem para os testes
 Automatização
 Sai a figura do testador e entra a do desenvolvedor de testes
 Principal desvantagem
 É necessário o uso de uma ferramenta para automatização
http://www.alvarofpinheiro.eti.br

56.
Modelo Ágeis: TDD
 Test Driven Development
 Modelo de Desenvolvimento Orientado a Testes
 É uma das principais técnicas associadas a modelos ágeis
 A idéia é que os testes sejam desenvolvidos antes do código
 TFD: Test First Design
 O passos para usar TDD são:
 Escreve um caso de teste e executa um caso de teste
 Falhando, implementa o código para passar no teste
 Passando, continua o desenvolvimento e escreve um novo caso de
testes
 TODA a fase de implementação de um modelo ágil pode ser feita
com TDD
http://www.alvarofpinheiro.eti.br

57.
TESTES DE SOFTWARE
PROCESSO
http://www.alvarofpinheiro.eti.br

58.
Processo de teste
Processo de
Desenvolvimento
Análise
Projeto
Implementação
Testes
Produto Final
http://www.alvarofpinheiro.eti.br

59.
Processo de Testes
 Os processos de teste são seqüências de ações,
operações que são executadas com o objetivo de
 Encontrar problemas no software
 Encontrá-los o mais cedo possível
 Aumentar a percepção de qualidade geral do software
 Garantir que o usuário final tenha um software que atende as
suas necessidades
 De forma geral, o processo de teste pode ser separado
em 4 grandes ações
 Planejar  entender o que precisa ser testado e definir como
 Preparar  selecionar e montar todo o ambiente para execução
 Executar  executar os testes e coletar o resultado
 Avaliar  verificar os resultados e métricas para melhorar os
testes
http://www.alvarofpinheiro.eti.br

60.
Processo de Testes
 O primeiro passo para realizar as atividades relacionadas
a testes em uma organização é definir um processo de
testes
 Este processo deve:
 Definir as principais atividades que precisam ser seguidas
durante os testes
 Definir papéis e responsabilidades das atividades de teste
 Definir as ações associadas a cada atividade
 Definir as entradas e saída de cada um das atividades
 Associar possíveis templates de documento a cada uma das
atividades
 As principais atividades que podem ser identificadas em
um processo de testes são:
 Planejar Testes
 Projetar Testes
 Implementar Testes Automáticos
 Executar Testes
 Avaliar Resultados
http://www.alvarofpinheiro.eti.br

61.
Planejar Testes
 Objetivo da Atividade
 Planejar as atividades de testes que serão realizadas durante o ciclo de
vida do software
 Responsável pela atividades
 Gerente de Testes com apóio do gerente de projetos
 Principais Passo
 Definir estágios de testes que serão executados
 Definir tipos de teste que serão necessários em cada estágio
 Entender os requisitos que precisarão ser testados
 Definir se algum teste será ou não automatizado
 Estimar o esforço necessário para projetar e implementar os testes
 Estimar o esforço necessário para executar os testes
 Definir que recursos de hardware e software serão necessário para a
execução dos testes (definir ambiente de testes)
 Definir riscos, dependências e premissas dos testes
 Montar cronograma das atividades de testes
 Associar este cronograma com o cronograma principal do projeto
 Artefato Gerado
 Plano de Testes
http://www.alvarofpinheiro.eti.br

62.
Planejar Testes
 É importante notar que as atividades podem mudar de acordo
com o tipo de projeto
 O planejamento de testes DEVE ser executado
 Após ou em paralelo com as atividades de requisitos
 O gerente de testes deveria ser alocado junto com o gerente de
projetos
 Assim como o projetista de testes DEVE ser alocado no projeto junto
com o analista de requisitos
 Determinar que estágios e tipos de teste serão realizados é uma
das principais atividades
 A atividade mais difícil de executar é a estimativa
 Durante o módulo seguinte a atividade de planejamento de testes
será mais detalhada
http://www.alvarofpinheiro.eti.br

63.
Planejar Testes: Possível Estrutura de um Plano de Testes
 Introdução
 Estágios de Testes
 Critérios de Entrada
 Critérios de Saída
 Tipos de Testes
 Critérios de Entrada
 Critérios de Saída
 Ambiente de Testes
 Recursos de Hardware
 Recursos de Software
 Riscos, Dependências e Premissas
 Cronograma
http://www.alvarofpinheiro.eti.br

64.
Projetar Testes de Sistema
 Objetivo
 Identificar os casos de teste e escrever o procedimento de testes para
cada um deles
 Definir qual dos casos de teste vai ser automatizado
 Responsável pela atividade
 Projetista de Testes
 Principais Passos
 Avaliar os requisitos funcionais e não funcionais
 Verificar quais os tipos de testes precisarão ser executados
 De acordo com isso outros passos precisarão ser realizados
 Para cada requisito definir os cenários de testes associados a eles
 Para cada cenário definir um caso de teste
 Para cada caso de testes definir
 Entradas e saídas
 Pré e pós condições
 Passos para execução do caso de teste
 Artefato de Saída
 Projeto de Testes
http://www.alvarofpinheiro.eti.br

65.
Projetar Testes de Sistema: avaliar especificação
 Primeiro passo para projetar os testes de sistema é avaliar a
especificação do software
 Essa avaliação pode ser feita
 Durante uma revisão formal da especificação
 Após os requisitos serem fechados e antes de se projetar os testes
 O ideal é que o projetista de teste participe da revisão dos testes
 Requisitos NÃO devem ser fechados sem a avaliação pela equipe de
testes
 Cada requisito funcional precisa ser verificado para garantir
 Completude
 Corretude
 Precisão
 Consistência
 Relevância
 Viabilidade
 Testabilidade
http://www.alvarofpinheiro.eti.br

66.
Projetar Testes de Sistema : avaliar especificação
 Completude
 Existe algo faltando no requisito? Ele contém todas as informações
necessários para o seu entendimento
 Corretude
 O requisito apresentado realmente resolve o problema que ele se
propõe?
 Precisão
 A descrição do requisito está clara? Existe alguma parte que pode
interpretada erradamente?
 Consistência
 Os requisitos são consistentes entre si? Alguma requisito é contraditório
com outro?
 Relevância
 O requisito realmente é um requisito? Ou é algum aspecto de design
que deveria ser tratado posteriormente?
http://www.alvarofpinheiro.eti.br

67.
Projetar Testes de Sistema : avaliar especificação
 Viabilidade
 É possível implementar esse requisito ? A tecnologia atual
permite que ele seja implementado?
 Testabilidade
 O requisito pode ser testado ? É possível gerar um procedimento
de testes que valide se o requisito está implementado
corretamente?
 Os requisitos funcionais NÃO devem ser esquecidos
 É necessário garantir que estes estão claramente
especificados
 Qual o requisito de segurança?
 Existe requisito de performance? Qual é?
 Existe alguma restrição de ambiente? Qual o banco de dados e o
servidor de aplicação que deve usado?
 Existem alguma restrição de tecnologia?
http://www.alvarofpinheiro.eti.br

68.
Projetar Testes de Sistema : avaliar especificação
 Outros aspecto importante a avaliar são os termos
usados na descrição dos requisitos
 Termos como
 Sempre ou nunca: é necessário verificar se eles
realmente significam isso no requisito
 Bom, rápido, pequeno, estável: palavras assim não
denotam requisitos testáveis e devem ser evitadas
 Se .. Então ..: sempre que um Se.. Então for entrado e
importante especificar o que ocorre no senão
 Etc. : TODOS os etc. devem ser removidos da
especificação
http://www.alvarofpinheiro.eti.br

69.
Projetar Testes de Sistema
 Os casos de teste de sistema são caixa preta e são
executados sobre todo o sistema
 A avaliação dos requisitos é a atividade principal
 O ideal é que o projetista de testes participe da revisão
dos requisitos para garantir que
 Cada requisito está claramente especificado
 Cada requisito é testável
 Os cenários de cada requisito são claramente definidos
 Os requisitos funcionais estão corretamente especificados
 Sem as informações acima não é possível projetar os
casos de teste corretamente
 A baixa qualidade dos testes está diretamente associada a baixa
qualidade dos requisitos
 A atividade de projetar testes será melhor detalhada no
módulo seguinte
http://www.alvarofpinheiro.eti.br

70.
Projeto de Testes Unitário
 Objetivo
 Avaliar uma unidade de código antes que esta seja integrada ao
restante do sistema
 Responsável pela atividade
 Desenvolvedor
 Principais passos
 Determinar abordagem de testes: caixa branca ou preta
 Am ambos os casos é necessário
 Avaliar o código
 Identificar que stubs precisam ser implementados
 Identificar que fluxos de execução precisam ser testados
 Avaliar a interface da unidade a testar
 Baseado nas informações acima, definir os casos de testes e
definir o procedimento de testes
 Artefato de Saída
 Procedimentos de testes unitários
http://www.alvarofpinheiro.eti.br

71.
Projeto de Testes Unitário
 Os stubs vão garantir o isolamento da unidade
 Os testes unitários usualmente são definidos em código
 Os casos de teste e procedimentos podem ser
documentos em um projeto de testes unitários
 Ou podem ficar apenas no código sob controle do desenvolvedor
 Projetos de testes unitários são de difícil manutenção
 Os testes unitários podem ser automatizados para facilitar a
manutenção e a execução posterior
 Quanto melhor os testes unitários menor o número de
problema que serão encontrados durante a integração
 Testes unitários fazem parte do processo de
desenvolvimento e normalmente NÃO são tratados como
parte do processo de testes
http://www.alvarofpinheiro.eti.br

72.
Projeto de Testes de Componente
 Objetivo
 Mesmo dos testes unitários, mas agora considerando o componente
como unidade
 Responsável pela atividade
 Projetista de Testes
 Principais passos
 Mesmos dos testes unitários, com exceção de verificar a abordagem
 Testes de componente usualmente são caixa preta
 Artefato de Saída
 Projeto de testes de componente
 Como a interface do componente é bem definida e controlada, o
projeto de testes de componente usualmente é feito e
documentado
 Testes de componente são usualmente definidos em código e
podem ser automatizados
http://www.alvarofpinheiro.eti.br

73.
Projeto de Testes de Componente
 O projeto de testes está altamente associado ao tipo
de interface do componente
 Este tipo pode ser
 Web service
 Interface de uma classe
 HTTP ou Socket
 Serial
 Objeto remoto (CORBA, COM, RMI)
 Um protocolo de comunicação é implementado em
cima de uma dessas interfaces
 Este protocolo é que precisa ser testado
 Quando a interface é programática o teste se terna
mais similar a um teste unitário de uma classe
 Web service e objetos remotos
http://www.alvarofpinheiro.eti.br

74.
Projeto de Testes de Componente
 Alguns Exemplos de componentes testáveis
 Software POS que ler cartões de crédito
 Um software que POS se comunica com um leitor de cartão de
crédito via serial
 O leitor de cartão tem um protocolo bem definido
 Esse protocolo é implementado pelo software do POS
 O POS precisa ser testado para suportar todos os possíveis
dados que podem ser enviados pelo leitor
 Software de atendimento médico. Componente que
implementa regras de negócio para aceitar um paciente
 Esse componente encapsula todas as regras para aceitar ou não
um paciente
 Ele é disponibilizado através de uma interface Java
 TODAS as possíveis situações em que um paciente pode ser
aceitou ou não precisam ser validadas
 Dessa validação vai depender uma grande parte da
funcionalidade do software
http://www.alvarofpinheiro.eti.br

75.
Projeto de Testes: Possível Estrutura do Projeto
 Introdução
 Ambiente de Testes
 Requisito 1
 Caso de Teste 1
 Pre-condição
 Pós-condição
 Cenário
 Procedimento
 Entradas / Saídas
 Caso de Teste N
 Requisito M
http://www.alvarofpinheiro.eti.br

76.
Implementar Testes de Sistema e/ou Componente
 Objetivo
 Caso alguns dos procedimento de testes possa ser
automatizados, eles devem ser implementados segundo o
procedimento
 Responsável pela atividade
 Desenvolvedor de testes
 Principais passos
 Configurar a ferramenta de automação de testes
 Determinar os dados de entrada e saída de cada caso de teste
 Determinar o procedimento a ser executado em cada caso de
teste
 Implementar os scripts de teste na linguagem determinada pela
ferramenta
 Validar os scripts de teste unitariamente
 Artefato de Saída
 Scripts de teste implementados
http://www.alvarofpinheiro.eti.br

77.
Implementar Testes de Sistema e/ou Componente
 A implementação dos testes é totalmente direcionada
pela ferramenta de testes
 É importante que cada organização defina uma ferramenta de
testes padrão
 Testes de componente são mais fáceis de automatizar
 Cada componente tem uma interface bem definida
 Essa interface é sempre programática
 Testes de sistema são mais complexos
 Em geral envolvem interação com o usuário
 Existem ferramentas que permitem a automatização de
testes com interfaces gráficas, mas
 Mudanças de interface são mais comuns que mudanças
 Isso torna a manutenção dos testes complicada
 É necessário avaliar o custo benefício de automatizar os
testes de sistemas
 Não necessariamente todos os testes devem ser automatizados
 Alguns testes são melhor e mais rapidamente executados por
testadores
http://www.alvarofpinheiro.eti.br

78.
Implementar Testes de Sistema e/ou Componente
 Existem várias vantagens de automatizar os testes
 Velocidade de execução: testes automáticos são mais rápidos de
executar
 Eficiência: enquanto os testes estão sendo executados, os
testadores podem ser alocados em outras atividades
 Corretude: casos de testes automáticos nunca comentem erros
durante a execução. Os passos sempre são repetidos da mesma
forma
 Simulação / emulação: ferramentas de testes podem ser usadas
como stubs ou test drivers
 Simplificação: alguns testes seriam tão complexos que rodar
manualmente que a automação acaba sendo a única forma de
executá-los
 A corretude é uma das principais vantagens, mas também
é uma limitação
 Os testadores conseguem enxergar problemas que os testes
automáticos não identificam
 Os passos executados por um testador podem variar de uma
execução para outra http://www.alvarofpinheiro.eti.br

79.
Implementar Testes de Sistema e/ou Componente
 Alguns fatos importantes em relação a automação
 Mudanças no software
 Os software muda e isso torna os testes falhos
 É necessário atualizar os casos de testes automáticos da mesma forma
que os manuais
 Testes se sistema automatizados são complexos de implementar
 Testes de sistema validam especialmente interação com o usuário
 Existem ferramentas para validar essa UI, mas são complexas de usar
 Vários bugs de UI podem escapar
 Não se pode confiar apenas na automação
 O olho do testador vai conseguir encontrar problemas que a ferramenta
não
 Algumas ferramentas são “invasivas”
 Modificam o código sendo testado
 O código final pode não ser correto devido a isso
http://www.alvarofpinheiro.eti.br

80.
Implementar Testes de Sistema e/ou Componente
 Conclusões
 Automatizar testes é uma excelente prática, mas deve
ser feita com cuidado
 A ferramenta de automatização deve ser bem escolhida
 Deve se avaliar quais testes valem a pena serem
automatizados
 Avaliar o custo-benefício da automatização
 Não se deve confiar apenas nos testes automáticos
http://www.alvarofpinheiro.eti.br

81.
Executar Testes
 Objetivo
 Executar os testes planejados e coletar os resultados
 Responsável pela atividade
 Testador
 Principais passos
 Os testes a executar devem ser definidos pelo projetista /
gerente de testes
 Para testes manuais, o testador deve seguir o procedimento
de testes aplicando todas as entradas e verificando as
saídas
 Para testes automáticos e testados deve configurar a
ferramenta de testes e colocar os scripts de teste para rodar
 Os resultados de testes devem coletados
 Artefato de Saída
 Resultado de testes
http://www.alvarofpinheiro.eti.br

82.
Executar Testes
 O setup para a execução de testes automáticos pode ser
bem demorado
 Essa atividade NÃO deve ser sub-estimada
 Os testes manuais devem ser realizados com muito
cuidado pelo testador
 Alguns testes podem ser exploratórios
 O testados deve se prender ao procedimento
 Mas caso algum problema fora do procedimento seja encontrado,
ele tem obrigação de reportar o problema
 O testador também deve validar se o procedimento de testes está
correto
 Problemas no procedimento também devem ser reportados
 Na dúvida, o testador DEVE reportar como erro
 É melhor ter um falso positivo que deixar um bug passar
 O testador deve na medida do possível dominar os
requisitos que estão sendo testados
http://www.alvarofpinheiro.eti.br

83.
Executar Testes: passo-a-passo para executar testes
 Selecionar que casos de testes serão executados de acordo com
o planejamento
 Atribuir os casos de testes para os testadores
 Executar o caso de teste e reportar os bugs. Capturar
informações continuamente levando em conta as execuções
anteriores
 Fazer o setup do ambiente de testes de acordo com o procedimento
 Entrar os dados especificados e esperar pelas saídas determinadas
 Avaliar os resultados, comportamentos e estado final do software.
Pesquisar qualquer diferença com o resultado esperado
 Caso ocorra um problema no software, reportar
 Caso um problema seja encontrado no caso de teste, reportar
 Capturar as informações sobre o teste que foi executado
 Resolver possíveis issues que estejam bloqueando os testes
 Reportar os resultados periodicamente
http://www.alvarofpinheiro.eti.br

84.
Executar Testes: passo-a-passo para executar testes
 Durante a execução de um caso de teste, este pode
está em diferentes estados
 Em alguns software é importante identificar estes possíveis
estados
 Os estados algumas vezes estão associados aos resultados
dos testes
 Alguns possíveis estados genéricos
 Queued
 Block
 Skip
 In Progress
 Pass
 Warn
 Fail
 Closed
http://www.alvarofpinheiro.eti.br

85.
Executar Testes: passo-a-passo para executar testes
 Queued
 Caso de teste atribuído a um testador e esperando para ser executado
 Block
 Execução bloqueada por alguma razão
 Skip
 Execução não realizada por alguma razão
 In Progress
 Caso de teste sendo executado
 Pass
 Caso de teste passado
 Warn
 Algum comportamento não ocorreu como esperado, mas o problema
não parece grave
 Fail
 Algum comportamento grave ocorrer
 Closed
 Após um teste Fail ou de Warn, o software foi corrigido e o problema
fechado
http://www.alvarofpinheiro.eti.br

86.
Avaliar Resultados
 Objetivo
 Consolidar os dados gerados pela execução dos testes e avaliar os
resultados para poder tomar decisões em relação ao projeto
 Responsável pela atividade
 Gerente de Testes
 Principais passos
 Coletar toda a informação sobre os resultados dos diferentes estágios
 Avaliar se todos os testes que estavam planejados foram realmente
executados
 Caso algum problema tenha ocorrido durante a execução, isso deve ser
avaliado
 Reportar os resultados para o restante do projeto do software
 Avaliar se os critérios esperados de resultados de testes foram
atingidos.
 Caso não tenha sido buscar identificar se ocorreu algum problema
durante os testes
 Artefato de Saída
 Resultado dos testes
http://www.alvarofpinheiro.eti.br

87.
Avaliar Resultados
 A avaliação dos resultados é fundamental pois é a
conclusão de cada uma das execuções de teste
 Ela é a base para tomadas de decisões gerenciais de
todo o projeto
 Caso os testes estejam falhando mais que o esperado,
alguma ação precisará ser tomada
 Caso os testadores estejam com problema para executar os
testes alguma ação
 Caso o procedimento de testes esteja com muitos problema,
ele provavelmente deverá ser revisto
http://www.alvarofpinheiro.eti.br

88.
Avaliar Resultados: Informações Importantes de consolidar
 Várias informações podem ser consolidadas na avaliação da
execução dos testes
 Quantidade de Testes Planejados
 Número total de casos de testes que foram planejados para execução
 Quantidade de Testes Executados
 Número total de casos de testes que foram realmente executados
 Quantidade de Testes Passados
 Número total de casos de testes que passaram
 Quantidade de Testes Falhos
 Número total de casos de testes que falharam
 Quantidade de Testes Bloqueados
 Número total de casos de testes bloqueados
 Quantidade de Bugs Encontrados
 Número total de bugs encontrados durante os testes
 Tempo total de execução dos testes
 Tempo total de execução dos testes
http://www.alvarofpinheiro.eti.br

89.
Avaliar Resultados: Informações Importantes de consolidar
 As informações listadas anteriormente podem ser
combinadas em diferentes métricas
 Estas métricas são usadas para
 Acompanhar o processo de testes
 Avaliar a eficácia dos testes
 Avaliar a eficiência dos testes
 Avaliar o custo dos testes
 O módulo seguinte vai detalhar as possíveis
métricas em testes de software
http://www.alvarofpinheiro.eti.br

90.
Planejamento de Testes
Reflexão
 Foram encontrados defeitos? Quantos?
 Algum defeito foi corrigido?
 Houve alguma preocupação com a classificação dos defeitos?
 Quantos dos defeitos eram muito críticos?
 Como os defeitos foram reportados?
 Existe algum plano de correção dos defeitos?
 Todos os recursos necessários para realização dos testes
estavam presentes?
 O ambiente estava configurado?
 Quem participou da execução?
 Que versão da release era essa? Ela estava estável?
 Os testes acabaram?
 Quais os próximos passos?
http://www.alvarofpinheiro.eti.br

91.
Planejamento de teste
Planejamento:
 Quem executará os testes?
 Que partes serão testadas? (tempo/recurso)
 Quando serão executados os testes (cedo)
 Como serão realizados os testes? (especificação/implementação)
 Quanto devemos testar?
http://www.alvarofpinheiro.eti.br

92.
Planejamento de teste
Principais atividades do planejamento:
• Determinar o escopo e os riscos e identificar o objetivo dos testes;
• Determinar a abordagem de teste (caixa-preta/ caixa-branca);
• Determinar os recursos necessários (pessoas, máquinas, ambiente de teste);
• Determinar a estratégia de teste;
• Montar cronograma das tarefas
• Determinar critérios de entrada e saída.
http://www.alvarofpinheiro.eti.br

93.
Planejamento de Testes
 Planejar os testes significa
 Identificar que estágios de testes serão executados
(estratégia de testes)
 Identificar os ciclos de testes
 Identificar o que será testado
 Identificar os recursos necessários para os testes
 Identificar os riscos, dependências e premissas dos testes
 Definir um cronograma das atividades de testes
 O gerente de testes é o responsável principal por
realizar essas atividades
 A principal saída da atividade de planejamento de
testes é o
 Plano de Testes
http://www.alvarofpinheiro.eti.br

94.
TESTES DE SOFTWARE
PROJETO
http://www.alvarofpinheiro.eti.br

95.
Projeto de Teste
Entradas e Saídas
Planejamento
de Testes
Plano de Projeto
Cronograma do Projeto
Informações sobre
o sistema
Plano de teste
http://www.alvarofpinheiro.eti.br

96.
Projeto de Teste
Atividades do Projeto de Teste
Análise dos
requisitos
Especificação dos
casos de teste
Seleção de
casos de teste
http://www.alvarofpinheiro.eti.br

97.
Projeto de Teste
Entradas e Saídas
Projeto de Teste
Plano de Teste
Documento de requisitos
Base de teste
(plano de negócio,
documento de marketing,
plano de projeto, etc)
Casos de teste
http://www.alvarofpinheiro.eti.br

98.
TESTES DE SOFTWARE
ABORDAGENS
http://www.alvarofpinheiro.eti.br

99.
Abordagem de Teste
 Existem 2 abordagens principais na execução de
testes
 Caixa Preta
 Caixa Branca
 Testes caixa preta são aqueles nos quais o testador
não vê o “interior” do objeto que está sendo testado
 Usualmente executados por um testador que é diferente do
desenvolvedor
 Avalia todas as diferentes entradas e suas respectivas
saídas para garantir que o software se comporta como
especificado
 Associado a estágios de teste como sistema ou componente
http://www.alvarofpinheiro.eti.br

100.
Abordagem de Teste
 Testes caixa branca são aqueles nos quais o testador sabe como
funciona o “interior” do objeto sendo testado
 Usualmente são executados pelo próprio desenvolvedor
 São fortemente associados aos testes unitários
 Avalia TODOS os caminhos lógicos do código para garantir que TODOS
os fluxos são executados corretamente
 Busca encontrar bugs, mas bugs no código e não bugs na
especificação, por exemplo
 A grande maioria dos software realiza apenas testes caixa preta
 Quando testes caixa branca são executados, eles não são
formalizados
 Não existe procedimento bem definido
 Não existe resultado de testes documentado
 Caso um procedimento de testes caixa branca seja escrito, existe
grande chance dele ser descartado após a execução dos testes
http://www.alvarofpinheiro.eti.br

101.
Testes Positivos e Testes Negativos
 Testes positivos verificam se o caminho feliz é executado
corretamente
 Testes negativos verificam as exceções
 Testes positivos
 Garantem que o software funciona minimamente como esperado
 Garantem que o software não quebra para as suas operações principais
 Não levam o software aos seus limites para identificar possíveis falhas
 Testes negativos
 Buscam realmente quebrar o software
 Focam em identificar problemas
 Garantem que o software funciona em diversas situações diferentes
 Ambos os tipos de testes devem ser realizados
http://www.alvarofpinheiro.eti.br

102.
TESTES DE SOFTWARE
TÉCNICAS
http://www.alvarofpinheiro.eti.br

103.
Técnicas de Teste –Análise de requisitos
 Análise de requisitos
 Começar a pensar na matriz de rastreabildiade:
 Identificar quais testes serão impactados
quando determinado requisito for modificado
 Saber se existem teste para cada requisito
 Avaliar grau de cobertura
http://www.alvarofpinheiro.eti.br

104.
Técnicas de Teste – Seleção de casos de teste
Técnicas de Teste
 Baseada na especificação (caixa-preta)
 Baseada na estrutura (caixa-branca)
 Baseada na experiência
http://www.alvarofpinheiro.eti.br

105.
Técnicas de Teste – Seleção de casos de teste
 Técnicas de Teste
 Baseada na especificação (caixa-preta)
1. Partição por equivalência
2. Análise de valores limites
3. Tabelas de decisão / Tabela Causa-Efeito
4. Testes derivados de casos de uso
 Baseada na estrutura (caixa-branca)
 Baseada na experiência
http://www.alvarofpinheiro.eti.br

106.
Técnicas de Teste – Seleção de casos de teste
 Técnicas de Teste
 Baseada na especificação (caixa-preta)
 Baseada na estrutura (caixa-branca)
 Cobertura e Teste baseado em instruções
 Cobertura e Teste baseado em laços de decisões
 Baseada na experiência
http://www.alvarofpinheiro.eti.br

107.
Técnicas de Teste – Seleção de casos de teste
 Técnicas de Teste
 Baseada na especificação (caixa-preta)
 Baseada na estrutura (caixa-branca)
 Baseada na experiência
 Error guessing
 Testes Exploratórios
http://www.alvarofpinheiro.eti.br

108.
Técnicas de Teste – Testes vs. Inspeções
 Inspeções dos artefatos buscam validar os artefatos antes que a
próxima fase do desenvolvimento seja iniciada
 Vários estudos indicam que o custo de encontrar um erro com
inspeção é menor que o custo de encontrar com testes [Kaplan
1995]
 3,5 horas de esforço para encontrar um erro com inspeção
 15-25 horas de esforço para encontrar um erro com testes
 Isso não significa que testes não são necessários
 Mas que outras técnicas também podem ser aplicadas
http://www.alvarofpinheiro.eti.br

109.
Técnicas de Teste – Encontrar Bugs
 Inspeção de Software
 Processo formal de verificação do software
 Pode ser aplicado para praticamente todos os artefatos gerados durante
o ciclo de desenvolvimento
 Tem o custo mais alto de aplicar, mas também é o que produz o melhor
resultado
 Combinação de inspeções na especificação, design e código podem
encontrar até 85% dos bugs de um software
 Como o processo é formal, ele é fácil de mensurar e de acompanhar
 Prototipação
 Ajuda no levantamento e definição dos requisitos
 Dá uma boa visão para o cliente do que vai ser o software final
 Reduz bastante as duvidas de usabilidade e de como as funções devem
ser implementadas
http://www.alvarofpinheiro.eti.br

110.
Técnicas de Teste – Encontrar Bugs
 Programação por pares
 Técnica definida em XP (Extreme Programming)
 2 desenvolvedores por computador
 1 programador digita
 1 programador procura por erros
 Possui várias vantagens
 Facilita mentoring de novos desenvolvedores
 Dissemina a cultura da empresa
 Pode chegar a encontrar a mesma quantidade de problemas da
inspeção
 É mais aplicável para a fase de codificação
 Walkthroughs e Code Reading
 Similar a inspeção, mas sem o formalismo de um processo
http://www.alvarofpinheiro.eti.br

111.
TESTES DE SOFTWARE
ESTÁGIOS
http://www.alvarofpinheiro.eti.br

112.
Unidade, Componente e Integração
 Um software em geral é quebrado em diferentes componentes
(ou módulos principais)
 Cada componente é quebrado em unidades (sub-componentes)
 Estes unidades precisam ser integradas em componentes
 Os componentes precisam ser integrados no software como um
todo
http://www.alvarofpinheiro.eti.br

113.
Unidade, Componente e Integração
 Testes precisam ser executados
 Na unidade para garantir que esta funciona separadamente
 No componente para garantir que quando as unidades foram integradas,
eles continuam funcionando
 No sistema como um todo para garantir que os componentes integrados
funcionam corretamente
 O escopo de cada um desses testes é bem diferente
 Todos buscam encontrar bugs
 Mas tipos diferentes de busca usualmente são encontrados
 Um teste não substitui o outro
http://www.alvarofpinheiro.eti.br

114.
Estágios de Teste
 O termos “Estágio de Teste” é usualmente aplicado ao teste que
está associado a uma determinada fase do ciclo de
desenvolvimento
 Relembrado o Modelo V, tem-se:
 Testes Unitários
 Testes de Componente
 Testes de Integração
 Testes de Sistema
 Testes de Aceitação
http://www.alvarofpinheiro.eti.br

115.
Estágios de Teste
 Testes Unitários
 Executados pelo desenvolvedor para validar a unidade que está sendo
implementada
 Testes de Componente
 Executado pelo testador para validar um componente específico do
software
 Testes de Integração
 Executado pelo testador para garantir que vários componentes
funcionam corretamente juntos
 Testes de Sistema
 Executados pelo testador para garantir que as funcionalidades do
software estão de acordo com a especificação
 Testes de Aceitação
 Executados pelo usuário para garantir que o software faz o que foi
inicialmente requisitos pelo usuário
 Cada um destes estágios será melhor detalhado posteriormente
http://www.alvarofpinheiro.eti.br

116.
Estágios e Tipos de Testes
 Anteriormente foi listado brevemente alguns estágios e diferentes
tipos de testes
 Os seguintes estágios e tipos serão abordados
 Estágios
 Testes Unitários
 Testes de Componente
 Testes de Sistema
 Testes de Aceitação
 Tipos de Teste
 Testes de Carga
 Testes de Performance
 Testes de Uso de Memória
 Testes de Usabilidade
 Teste de Configuração
 Testes de Compatibilidade
 Testes de Documentação
http://www.alvarofpinheiro.eti.br

117.
Estágios – Testes Unitários
 Testes unitários são testes isolados executados sobre uma rotina,
classe ou pequena arte do programa
 Esses testes são executados pelo próprio desenvolvedor para garantir
que a sua unidade pode ser integrada com o resto do software
 Dois aspectos fundamentais
 Os testes são isolados
 Os testes são implementados e executados pelo próprio desenvolvedor
 Testes isolados
 Stubs devem ser implementados para suprir alguma parte da
funcionalidade ou gerar valores errados para validar a unidade
 Os componentes externos a unidade em testes devem ser simuladas
 Testes executados pelo desenvolvedor
 Os testes são normalmente rodados no ambiente de desenvolvimento
 Os casos de testes focam apenas na unidade em testes sem se
preocupar com a interação com outras unidades
http://www.alvarofpinheiro.eti.br

118.
Estágios – Testes Unitários
 Testes unitários podem ter a abordagem caixa
branca ou caixa preta
 Testes caixa branca são bem importantes pois ajudam a
validar todos os fluxos de execução
 A formalização de casos de testes unitário
 É feita em algumas organizações
 Principal dificuldade é dá manutenção nos casos de testes
 Na maioria das vezes os casos de teste são jogados fora após
os testes (especialmente os caixa branca)
 O resultado do testes unitários algumas vezes também é
formalizado
 Mas a sua análise não tem tanto sentido em algumas situações
http://www.alvarofpinheiro.eti.br

119.
Estágios – Testes Unitários
 Automação de testes unitários
 É uma das principais formas de garantir que os casos de teste
não sejam “jogados fora”
 Existem várias ferramentas que focam na automação dos casos
de testes
 Gerar / implementar os scripts de testes
 Executar os scripts de testes
 Coletar os resultados da execução
 Estas ferramentas rodam os testes sem intervenção do
desenvolvedor
 Principal vantagem
 Facilita a manutenção dos testes
 Os Testes podem ser rodados automaticamente para garantir que as
unidades não quebraram
 Principal problema
 O custo de especificar e implementar os scripts é alto
 É necessário avaliar o custo / benefício para cada software (ou para
cada parte do software)
http://www.alvarofpinheiro.eti.br

120.
Estágios – Testes Unitários
 Processo de desenvolvimento orientado a testes unitários
 Atualmente existem processos de desenvolvimento orientados a testes
unitários
 TDD (Test Driven Development)
 O princípio fundamental é
 Desenvolver o teste antes do código
 Principal vantagem
 Casos de teste estão sempre atualizados
 O código é feito para passar nos testes
 O requisito é bem entendido antes de iniciar a implementação
 Os testes são pensados com muito cuidado
 Novos casos de testes podem ser facilmente adicionados
 Principal desvantagem
 Custo do desenvolvimento dos testes
 É necessário avaliar beneficio de acordo com o projeto
 A equipe precisa ter maturidade para entender a importância dos testes
e saber implementar os casos de teste
http://www.alvarofpinheiro.eti.br

121.
Estágios – Testes Unitários
 Passos para identificar casos de testes unitário caixa preta
 Avaliar a interface da rotina a testas
 Avaliar os parâmetros e seus possíveis valores
 Avaliar TODOS os possíveis retornos de acordo com cada possível
combinação de parâmetros
 Encontrar os limites dos parâmetros que vão fazer com que o retorno
mude
 Avaliar todos os possíveis erros que podem ser gerados
 Encontrar as combinações de parâmetros que devem gerar erro
 Passos para identificar casos de testes unitários caixa branca
 Avaliar todos os fluxos de execução da rotina
 Avaliar as funções que são usadas internamente e seus retornos
 Avaliar como vai se comportar a rotina caso as funções internas
retornem valores diferentes do esperado
 Avaliar se todos os possíveis fluxos de execução são tratados
 Avaliar se todos os fluxos codificados realmente podem ser atingidos
http://www.alvarofpinheiro.eti.br

122.
Estágios – Testes Unitários: Exemplo
 Considerando o código abaixo
/**
* Retorna a lista de contas bancarias de uma determinada pessoa
* @param id identificar de uma pessoa
*/
Vector getContas (IDPessoa id) {
Vector resultado = new Vector ();
for (int i = 0; i < contas.size(); i++) {
Conta c = contas.elementAt(i);
if (c.getIDPessoal().equals (id)) {
resultado.addElement(c);
}
}
return resultado;
}
Os seguintes casos de teste unitários caixa preta podem ser identificados:
 Passar como parâmetro um ID de pessoa nulo
 Passar como parâmetro um ID de pessoa inválido
 Passar como parâmetro um ID de pessoa que tem apenas uma conta
 Passar como parâmetro um ID de pessoa que não tem conta
http://www.alvarofpinheiro.eti.br

123.
Estágios – Testes de Componente
 Muito parecidos com os testes unitários. Definição quase igual:
 Esses testes são executados pelo próprio desenvolvedor para garantir
que a sua unidade pode ser integrada com o resto do software
 A principal diferença é que
 Testes de componente devem ser implementados por uma equipe
diferente da equipe de desenvolvimento
 A equipe de desenvolvimento executa os testes de componente, mas
uma equipe externa também pode executá-los
 Testes de componente são aplicáveis quando o software é
grande em vários componentes que interagem entre si
 Os componentes
 São compostos por diferentes unidades internas
 Tem uma interface bem definida que é utilizado por outros componentes
 Usam serviços providos por componentes externos
http://www.alvarofpinheiro.eti.br

124.
Estágios – Testes de Componente
 A equipe de testes separada pode
 Estudar a especificação do componente
 Desenvolver um conjunto de testes para o componente (que
podem ser ou não automatizados)
 Executar esses testes para cada versão do componente que
for fechada
 Os testes de componente garantem que
 Cada componente está funcionando conforme a sua
especificação individualmente
 Com isso os componentes podem ser integrados e o
software completo pode ser testado
http://www.alvarofpinheiro.eti.br

125.
Estágios – Testes de Componente
 A principal vantagem de se usar testes de componentes é
 Uma equipe diferente da desenvolvimento vai pensar nos casos de teste
 Isso garante uma melhor qualidade e cobertura dos testes (como foi
visto anteriormente)
 A principal desvantagem
 É necessário definir claramente os componentes do software
 O desenvolvimento também precisa ser “quebrado” em componentes
 Isso pode não ser simples de fazer em alguns projetos
 Quando testes de componente são realizados, usualmente é
definido um estágio chamado de Testes de Integração
 Todas as unidades são integradas e os problema de integração são
resolvidos antes do teste de sistemas
 Os testes de integração podem ser bem complexos de executar, casos o
software seja muito grande
http://www.alvarofpinheiro.eti.br

126.
Estágios – Testes de Componente: Exemplo
 Considerando uma interface de um componente HTTP que
recebe parâmetros via HTTP GET
/**
* HTTP GET htp://servername/getConta?pessoaID=<idNumber>
* Retorna: idConta1;idConta2;idConta3;..;idContaN
*/
Os seguintes casos de teste podem ser identificados:
 Tentar ter acesso a uma página diferente do servidor (getPessoa)
 Tentar ter acesso a página getConta, mas sem nenhum parâmetro
 Tentar ter acesso a página getConta, mas com um parâmetro diferente de pessoaID
 Tentar ter acesso a página getConta, mas com mais de um parâmetro
 Tentar ter acesso a página getConta com o parâmetro pessoaID como segundo parâmetro
 Tentar passar o parâmetro via HTTP POST
http://www.alvarofpinheiro.eti.br

127.
Estágios – Testes de Sistema
 Valida a funcionalidade principal do software
 Tem como objetivo garantir que o software está implementando
corretamente o que foi especificado
 É direcionado então para especificação do software
 Os casos de teste são definidos, especificados e executados por
uma equipe de testes separada
 Esta é equipe pode até ser uma organização separada da organização
que faz o desenvolvimento
 Aspectos subjetivos do software também devem ser avaliados
 Qualidade geral da UI do software
 Facilidade de uso do software
 Performance do software
 Facilidade instalação
 Clareza das mensagens
 etc
http://www.alvarofpinheiro.eti.br

128.
Estágios – Testes de Sistema: Exemplo
 Considerando o seguinte caso de uso
UC001: Listar contas
Precondição: usuário logado no sistema no menu principal
Fluxo Principal:
1. O usuário seleciona a opção listar contar. O sistema apresenta uma lista de pessoas
(pode executar fluxo alternativo 2 ou 3)
2. O usuário seleciona uma pessoa específica. O sistema retorna um formulário com a lista
de contas dessa pessoa (pode executar fluxo alternativo 1)
Fluxo alternativo
1. A pessoa não tem contas: uma mensagem é apresentando indicando que a pessoa selecionada
não tem contas
2. O usuário não tem permissão de acesso: uma mensagem de erro é apresentada indicando que
o usuário não tem permissão
3. Nenhuma pessoa cadastrada no sistemas: a lista é apresentada vazia
Os seguintes casos de teste podem ser identificados:
 Listar as contas de uma pessoa que não tem contas
 Listar as contas de uma pessoa que tem várias contas
 Entrar com um usuário que não tem permissão de listar pessoas e tentar listar pessoas
 Entrar no sistema sem nenhuma pessoa cadastrada
 Listar contas de uma pessoa e em seguida listar de outras pessoas
http://www.alvarofpinheiro.eti.br

129.
Estágios – Testes de Aceitação
 São os testes realizados pelo usuário que contratou o
desenvolvimento do sistema
 Valida que a necessidade inicial do cliente quando o
desenvolvimento do software foi contratada foi atendida
 Foco não é na especificação, mas na necessidade do cliente
 Por mais que especificações sejam escritas e aprovadas pelo
cliente
 É comum que alguma necessidade não seja totalmente atendida
 Algumas vezes a necessidade original foi implementada de outra forma
 Outros problemas como
 Usabilidade, performance ou estabilidade do software também podem
ser identificados
 A organização que desenvolveu o software não tem muito
controle sobre a aceitação
 Um processo de aceitação pode ser definido, mas o cliente também
pode ter seu processo interno
http://www.alvarofpinheiro.eti.br

130.
Estágios – Testes de Aceitação: Exemplo
 Considerando o caso de uso de listar contas de uma pessoa
 A necessidade do cliente é:
 Ter um cadastro de pessoas
 Ter um cadastro das contas de cada pessoa
 Poder visualizar em uma mesma tela as pessoas e suas respectivas
contas
 Os seguintes casos de teste podem ser identificados:
 Entrar no sistema e verificar se a tela de lista de pessoas apresenta
todas as pessoas cadastradas
 Verificar se é possível selecionar uma pessoa e ver suas contas na
mesma tela
 Verificar se todas as contas de uma determinada pessoa realmente são
apresentadas
http://www.alvarofpinheiro.eti.br

131.
Sequência de Estágios de Testes
Unitário
Componente
Integração
Sistema
Aceitação
Desenvolvedores Engenheiro
de Testes
Cliente
ou Usuário
http://www.alvarofpinheiro.eti.br

132.
Seqüência de Estágios de Testes
 Vantagens de quebrar os testes em diferentes estágios
 Cada estágio foca em problemas diferentes
 Os testes estruturais garantem a estabilidade do software, antes de se
buscar encontrar problemas comportamentais
 Os testes comportamentais são rodados em um software estável
 É mais fácil de fazer o acompanhamento do projeto
 Cada estágio deve ser iniciado o mais cedo possível
 Bugs devem ser encontrados o quanto antes
 O momento de iniciar cada estágio deve ser determinado no plano de
testes
O plano de testes deve focar em quais estágios
de teste?
Testes de aceitação fazem parte do planejamento
de testes?
http://www.alvarofpinheiro.eti.br

133.
TESTES DE SOFTWARE
TIPOS
http://www.alvarofpinheiro.eti.br

134.
Tipos de Testes: Unitários
É o processo de verificação de que o código faz o que a
especificações diz que ele deve fazer. Seu propósito é verificar se
toda lógica necessária está presente e que funciona
adequadamente de maneira automática. Testes unitários é uma
atividade tipicamente realizada por desenvolvedores. É de sua
responsabilidade provar que o software produzido faz exatamente
o que se supõe que ele deve fazer e que não há nenhuma
funcionalidade faltando. Testes de unitários são escritos a partir
da perspectiva do programador. Eles asseguram que um
determinado método de uma classe realiza com êxito a
um conjunto de tarefas específicas. Cada teste confirma que o
método produz os resultados esperados, quando recebe uma
entrada conhecida.
http://www.alvarofpinheiro.eti.br

135.
Tipos de Testes: Funcionais
Servem para dizer que o código deve fazer as coisas certas. São
escritos a partir da perspectiva do usuário. Estes testes
confirmam que o sistema deve fazer o que os usuários estão à
espera que faça. Muitas vezes o desenvolvimento de um sistema
computacional é relacionado à construção de uma casa. Embora
esta analogia não seja completamente apropriada, dado as
especificidades de cada projeto. Este modelo pode ser estendido
e utilizado na compreensão das diferenças entre testes de
unidade e testes funcionais. Teste de unidade se assemelha a um
inspetor de obras visitando uma casa em construção. Ele está
focado nos diversos sistemas internos da casa, a fundação, o
sistema hidráulico, rede elétrica, canalização, e assim por diante.
Por outro lado, testes funcionais neste cenário são análogos a
visitação do dono da casa a esta mesma construção. Ele assume
que os sistemas internos irão comportar-se adequadamente, já
que o inspetor de construção realizou bem sua tarefa.
http://www.alvarofpinheiro.eti.br

136.
Tipos de Testes: TestDriver e Stub de Testes
 Um test driver é um componente de software que simula as
entradas reais do software
 Por exemplo, um software de calculadora recebe números e operações
 Um test driver para este software pode entrar um grande combinação
diferente de números e combinações para validar a calculadora
http://www.alvarofpinheiro.eti.br

137.
Tipos de Testes: TestDriver e Stub de Testes
 O stub de test é utilizado para testar o software de baixo para
cima
 O stub simula resultados que são retornados por um determinado
componente que o software depende
http://www.alvarofpinheiro.eti.br

138.
Tipos de Teste
 Frequentemente confundidos com os estágios de teste
 “Tipos de Testes” identificam os diferentes testes que podem ser
realizados em cada um dos estágios
 Cada tipo pode estar associado a um estágio específico, ou pode ser
realizado a partir dos testes de componente
 Tipos também estão associados com cada domínio de aplicação
 No desenvolvimento de jogos são realidades testes de jogabilidade (só
aplicável a jogo)
 Em aplicações que usam banco de dados são realizados testes de
volume de carga no banco
 Alguns tipos de teste comuns
 Testes de carga
 Testes de configuração
 Testes de compatibilidade
 Testes de performance
 Testes de documentação
 Testes de internacionalização
 Testes de usabilidade
http://www.alvarofpinheiro.eti.br

139.
Tipos de Teste
 Testes de carga
 Foco em garantir um número específico de transações no banco de
dados (alto volume de dados e alto número de transações)
 É aplicável a partir dos testes de componente
 Testes de configuração
 Verifica se o software funciona com diferentes configurações de
hardware e software
 Está associado aos requisitos não-funcionais / restrições do software
 Usualmente é aplicável a partir dos testes de integração
 Testes de compatibilidade
 Verifica se um determinado software está aderente a um padrão que ele
deveria implementar
 Usualmente é executado durante o teste de sistema
http://www.alvarofpinheiro.eti.br

140.
Tipos de Teste
 Testes de performance
 Garantir que a velocidade de execução do sistema é adequada (tempo
para carregar uma página web por exemplo)
 Associado aos requisitos não funcionais
 Pode ser executado a partir dos testes de integração
 Testes de documentação
 Garantir que a documentação do software está do acordo com o que foi
realmente implementado
 Tem mais sentido ser executado durante os testes de sistema
 Testes de internacionalização
 Garantir que o software funciona em diferentes línguas e com
configurações dependentes de pais (meda, timezone, etc.)
 Testes de usabilidade
 Verifica se as funções do sistema realmente são “fáceis” de serem
realizadas
 Deve ser executado durante os testes de sistema
http://www.alvarofpinheiro.eti.br

141.
Testes de Regressão
 Considere o seguinte cenário
 Durante a execução dos testes de sistema de um software
encontra-se um erro após a execução de 70% dos testes
 Este erro é corrigido e uma nova versão é gerada
 Que testes devem ser executados após isso?
 Os 30% restantes
 E também pode-se regredir e executar todos os outros testes que
já foram executados
 A execução dos testes que já foram rodados é chamado de
Testes de Regressão
 Um testes de regressão completo significa que TODOS
os testes serão rodados novamente
http://www.alvarofpinheiro.eti.br

142.
Tipos – Testes de Carga
 Associado principalmente a softwares que usam bancos de
dados
 É um tipo de testes
 Caixa preta
 Principal objetivo é verificar como o software se comporta com
diferentes cargas de banco de dados
 Precisa de diferentes scripts para popular o banco
 Está associado aos requisitos, mas também ao modelo de dados do
software
 Algumas vezes a implementação assume alguns
comportamentos do modelo de dados
 Dados dependentes da implementação do código e vice-versa
 Isso pode causar bugs na aplicação, pois os dados do banco deveria
estar associados e serem dependentes apenas do modelo de dados
 Esses testes podem ser automatizados, mas o ideal é que sejam
manuais para identificar os comportamentos diferentes do
software
http://www.alvarofpinheiro.eti.br

143.
Tipos – Testes de Performance
 Verificar a performance da aplicação em diferentes cenários
 Esta diretamente associado aos requisitos não funcionais do
software
 Os requisitos devem especificar a performance esperada do software
 Caso isso não seja feito pode gerar frustração durante a aceitação do
software
 A performance também está associada ao número de usuário
utilizando o software
 Em sistemas Web, a performance tem que ser garantida até um número
X de usuários
 Existem ferramentas que ajudam a implementar scripts para
validar a performance
 Simular vários usuários conectados a aplicação
 Estes testes também estão associados ao ambiente de deploy do
software
 Este ambiente influencia diretamente no resultado dos testes
http://www.alvarofpinheiro.eti.br

144.
Tipos – Testes de Performance: Exemplo
 Considerando o caso de uso listar contas de uma pessoas
 O software pode ter um requisito não funcional
 Mostrar as contas de um pessoa específica em no máximo 5 segundos
 Com uma base de até 10mil pessoas e 100mil contas
 Com até 100 usuários logados simultaneamente
 Os seguintes casos de teste podem ser identificados:
 Montar uma base com este número de usuários e buscar listar as contas
destes usuários repetidamente. Calcular a média de tempo para mostrar
as contas
http://www.alvarofpinheiro.eti.br

145.
Tipos – Testes de Uso de Memória
 Pode estar associado a diferentes tipos de software
 Alguns sistemas embarcados tem um milite de memória para uso
 Caso se passe deste limite o software não pode ser executado ou o
custo do hardware vai ser elevado
 O uso da memória física do hardware precisa ser acompanhado
nos projetos, caso este seja um recurso crítico
 Avaliar periodicamente quanta memória o software está usando
 Os procedimentos de testes de sistema podem ser utilizados
 Verificar quanta memória o software está usando em cada caso de uso
 Testes exploratórios também podem ser utilizados para verificar o uso
de memória
 Estes testes precisam ser realizados em alguns sistemas desde a
fase de codificação e testes unitários
 O uso de memória também pode estar associado a requisitos
funcionais
http://www.alvarofpinheiro.eti.br

146.
Tipos – Testes de Uso de Memória: Exemplo
 Um sistema embarcado pode estar limitado ao uso de 4 MB de
RAM
 As placas com essa memória já foram encomendadas e estão na
fábrica
 É necessário implementar no código um controle que verifique
quanto de memória RAM está sendo utilizada
 Semanalmente deve se acompanhar
 quando de memória usada vs. número de casos de uso implementados
http://www.alvarofpinheiro.eti.br

147.
Tipos – Testes de Usabilidade
 Que atributos definem uma boa interface com o usuário?
 Grande investimento é feito pelas empresas para responder essa
pergunta
 Com os atributos definidos, a UI do software pode ser definida
para atingi-los
 Algumas características de um boa UI
 Segue um padrão determinado
 Flexível
 Intuitiva
 Consistente
 Confortável
 Útil
http://www.alvarofpinheiro.eti.br

148.
Tipos – Testes de Usabilidade
 Segue um padrão determinado
 As empresas que fazem os sistemas operacionais definem padrões de
UI para serem seguidos pelas aplicações
 É importante identificar se estes estão ou não sendo seguidos
 Flexível
 Existem diferentes formas de executar a mesma função? Estas formas
são claras para o usuário?
 Intuitiva
 A interface é “limpa”? As funções do software são obvias e fáceis de
encontrar?
 Consistente
 Funções similares no software estão disponíveis da mesma forma?
 Confortável
 Mensagens de erro são mostradas no momento correto? A performance
das operações é ideal?
 Útil
 As funções realmente estão funcionando e podem ser usadas?
http://www.alvarofpinheiro.eti.br

149.
Tipos – Testes de Usabilidade
 Mesma mensagem de erro apresentada
de forma diferente
 Cada indicação passa um “mensagem”
diferente para o usuário
 O teste de usabilidade precisa garantir a
consistência entre as “mensagens”
http://www.alvarofpinheiro.eti.br

150.
Tipos – Testes de Usabilidade
 Um dos testes mais importantes realizados durante os testes de
sistema
 É um teste caixa preta que visa identificar se os casos de uso do
software são “fáceis” de executar pelo usuário final
 É realizado por um design de usabilidade
 Foca na facilidade de uso (número de passos para executar uma função
específica do software)
 Identificar se as opções apresentadas para o usuário são claras de
entender
 Os casos de teste de usabilidade são extraídos da especificação
e do modelo navegacional do software
 Existem diferentes técnicas para realizar esses testes
 Filmar usuários utilizado o software e avaliar o uso com psicólogos
 Colocar o software em um ambiente real e deixar um observador
tomando nota do uso do software
 Etc.
http://www.alvarofpinheiro.eti.br

151.
Tipos – Testes de Usabilidade: Exemplo
 Considerando o caso de uso lista contas
 O usuário pode esperar que as contas de uma determinada
pessoa sejam listadas
 Com no máximo 1 clique
 Na mesma tela que todas as pessoas
 Sejam apresentadas em uma lista com rolagem
 Um possível caso de teste deve verificar se essas condições são
atendidas no software
 Em relação ao número de cliques, pode-se filmar vários usuários
diferentes para verificar se eles conseguem realizar a operação
com apenas 1 clique
 Algumas vezes existe a opção de fazer com 1 clique, mas isso não é
claro para o usuário final
http://www.alvarofpinheiro.eti.br

152.
Tipos – Teste de Configuração
 Atualmente existem diferentes plataformas de hardware e
software nas quais um determinado software pode executar
 Além disso, o software desenvolvido também possui diferentes
configurações internas
 Resumindo, os testes de configuração buscam
 Identificar o comportamento do software em diferentes configurações de
hardware
 Identificar o comportamento do software em diferentes configurações de
software
 Identificar o comportamento do software em diferentes configurações
internas do software
 As possíveis plataformas de hardware e software nas quais o
software deve funcionar
 DEVEM ser mapeadas durante a especificação do software
 DEVEM ser aprovadas pelo cliente
 Partindo destas especificações os casos de teste precisam ser
levantados
http://www.alvarofpinheiro.eti.br

153.
Tipos – Teste de Configuração
 Os resultados desses testes devem ser acompanhados
periodicamente
 Estes testes precisam ser executados o mais cedo possível
 Especialmente se alguma das restrições fora essencial (ex. o software
precisa rodar com um monitor preto e branco)
 O planejamento dos testes precisa
 Incluir as diferentes configurações de hardware e software com
ambiente para execução dos testes
 Planejar em que momento estes testes devem ser realizados
http://www.alvarofpinheiro.eti.br

154.
Tipos – Teste de Configuração: Exemplo
 O software pode ter como restrição utilizar banco de dados
Oracle ou Posgresql
 O caso de teste então deve
 Configurar 2 ambientes de testes: 1 com cada banco de dados
 Executar as funcionalidades básicas do software em ambos os
ambientes
 Caso alguma não funciona corretamente, o teste é falho
 Em algumas situações TODOS os testes precisarão ser executados em
ambos os ambientes
http://www.alvarofpinheiro.eti.br

155.
Tipos – Testes de Compatibilidade
 Como garantir que um editor de testes realmente consegue abrir
um documento do padrão MS Word?
 Como garantir de controle bancário exporta suas contas
corretamente para uma planilha excel?
 Como garantir que um software bancário consegue se
comunicar com um servidor padrão do banco central?
 Estes problemas são testados através de um teste de
compatibilidade
http://www.alvarofpinheiro.eti.br

156.
Tipos – Testes de Compatibilidade
 É aplicável para software que
 Implementam algum padrão específico e que precisam estar
compatíveis com este
 Interagem com alguma aplicação que em a sua interface
padronizada
 No primeiro caso, o software precisa ser valido quando ao
padrão
 Usualmente os organismos de padronização definem conjuntos
de testes que validam as implementações
 A execução destes testes precisam então ser planejadas para
validar a implementação do software
 No segundo caso, o software precisa
 Garantir que está usando a interface padronizada corretamente
(por exemplo, usar um porta USB)
 Testes precisam ser especificados para as diferentes opções
definidas no padrão
http://www.alvarofpinheiro.eti.br

157.
Tipos – Testes de Compatibilidade: Exemplo
 O software de controle de contas pode ter como requisito não
funcional suportar um formato binário padrão para contas
 A organização que definiu o padrão binário para um arquivo de
várias contas possui um conjunto de testes que valida o suporte
ao formato
 Um caso de teste então é
 Executar o conjunto de testes no software em um caso de uso de
importar contas
 Para todos as diferentes entradas, o software deve se comportar
corretamente
http://www.alvarofpinheiro.eti.br

158.
Tipos – Testes de Documentação
 Diferentes documentações podem ser geradas para o software
 Documentação para o usuário (help)
 EULA
 Garantia
 Marketing
 É fundamental verificar se estas documentações estão corretas e
de acordo com o esperado
 Requisitos podem e devem ser definidos para a documentação
 Quem vai prover o texto do help? Em que língua? Se for escrito pela
equipe, quem vai revisá-lo?
 Quem vai fornecer o EULA? Quando ele será incluído no software
 Casos de testes podem e DEVEM ser definidos para validar
esses pontos
 Verificar a consistência do help
 Verificar de o material de marketing está consistente
http://www.alvarofpinheiro.eti.br

159.
Tipos – Testes de Documentação
 Frequentemente os casos de teste de documentação são
esquecidos
 Como não é código a sua importância é minimizada
 Dependências de documentação também são esquecidas
 Quando o texto do EULA vai ser entregue?
 Quem vai revisá-lo?
 Mudanças de última hora são freqüentes
 Erros encontrados de última hora também são muito freqüentes
 Especialmente no help
 Erros de documentação podem
 Gerar processos contra a empresa que fez o software
 Dá uma idéia de baixa qualidade do produto
http://www.alvarofpinheiro.eti.br

160.
TESTES DE SOFTWARE
AUTOMAÇÃO
http://www.alvarofpinheiro.eti.br

161.
Testes: Automação
Software que automatiza qualquer aspecto da verificação de um
sistema de aplicações. É possível incluir ainda nesta definição a
capacidade de gerar entradas e resultados esperados dos testes,
a execução das suítes de testes sem a intervenção manual e
finalmente a avaliação se o teste passou ou não.
Lista de situações onde é indicativo o teste automático:
Quando há uma grande quantidade de testes;
Suporte a várias GUIs, redes, sistemas operacionais ou banco;
Testes de performance;
Quando é necessário repetir uma complexa lista de ações; e
Avaliar uma grande quantidade de saída repetidamente.
http://www.alvarofpinheiro.eti.br

162.
Testes: Manuais
Quando os testes automáticos não são indicados:
Quando não se tem muito tempo;
Testadores necessitam ter ideia do comportamento da aplicação;
Situações que se necessita de criatividade;
Em relação a diminuição dos cursos;
Testar novos componentes.
http://www.alvarofpinheiro.eti.br

163.
Automação
 Como escrever testes funcionais automáticos
eficientemente
 existem algumas orientações para decidir se o determinado teste de unidade que está sendo escrito é
na verdade um teste funcional:
1. Se o de teste de unidade atravessa classe de fronteiras, ele pode ser um teste funcional.
2. Se o de teste de unidade ficar muito complexo, ele pode ser um teste funcional.
3. Se o de teste de unidade é frágil (ou seja, é um teste válido, mas é necessário atualizá-lo
continuamente para lidar com diferentes mudanças do usuário), ele pode ser um teste funcional.
4. Se o de teste de unidade é mais difícil de escrever do que o código que deverá ser testado, ele pode
ser um teste funcional.
 Existe uma sintonia entre o teste unitários e os testes funcionais, e decidir onde está a linha de
separação entre um e outro depende de caso a caso.
 Quanto mais confortável se estiver com os testes unitários, mais claro será perceber quando um
determinado teste está cruzando a linha de unidade para funcional.
slide 163 de 99
http://www.alvarofpinheiro.eti.br