fundamentos de testes de software
Post on 09-Jul-2015
581 Views
Preview:
DESCRIPTION
TRANSCRIPT
TESTES DE SOFTWARE
https://www.facebook.com/alvarofpinheiroaulas/br.linkedin.com/in/alvarofpinheiro/
http://www.alvarofpinheiro.eti.br
“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
TESTES DE SOFTWARE
INTRODUÇÃO
http://www.alvarofpinheiro.eti.br
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
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
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
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
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
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
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
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
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
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
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
O que testar?
Software Usuário
Experiência de uso
Testes
Software Usuário
Testes
Os testes estão cobrindo
As áreas com riscos para
qualidade
http://www.alvarofpinheiro.eti.br
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
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
Testes
Estruturais
Testes
Comportamentais
Testes
Reais
Desenvolvedor Engenheiro de Testes Usuário
http://www.alvarofpinheiro.eti.br
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
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
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
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
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
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
Testes: Modelo de DocumentoMissã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
TESTES DE SOFTWARE
EQUIPES
http://www.alvarofpinheiro.eti.br
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
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
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
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
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
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
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
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
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
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
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
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
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
TESTES DE SOFTWARE
CICLO DE VIDA
DE UM BUG
http://www.alvarofpinheiro.eti.br
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
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
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
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
Ciclo de Vida
Revisado
Rejeitado
Aberto Atribuído Trabalho Fechado
Reaberto Adiado
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE
MODELOS
http://www.alvarofpinheiro.eti.br
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
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
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
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
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
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
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
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
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
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
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
TESTES DE SOFTWARE
PROCESSO
http://www.alvarofpinheiro.eti.br
Processo de teste
Análise
Projeto
Implementação
Testes
Produto Final
Processo de
Desenvolvimento
http://www.alvarofpinheiro.eti.br
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
TESTES DE SOFTWARE
PROJETO
http://www.alvarofpinheiro.eti.br
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
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
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
TESTES DE SOFTWARE
ABORDAGENS
http://www.alvarofpinheiro.eti.br
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
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
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
TESTES DE SOFTWARE
TÉCNICAS
http://www.alvarofpinheiro.eti.br
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
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
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
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
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
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
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
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
TESTES DE SOFTWARE
ESTÁGIOS
http://www.alvarofpinheiro.eti.br
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
TESTES DE SOFTWARE
TIPOS
http://www.alvarofpinheiro.eti.br
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
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
Tipos de Testes: Test Driver 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
Tipos de Testes: Test Driver 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
TESTES DE SOFTWARE
AUTOMAÇÃO
http://www.alvarofpinheiro.eti.br
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
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
slide 163 de 99
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.
Automação
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.
http://www.alvarofpinheiro.eti.br
slide 164 de 99
Gerenciamento de Automação de testes Uma suíte de testes automatizados é, em essência, um sistema computacional e possui os mesmos
problemas que o sistema que se pretende testar
Quando se está testando qualquer sistema com scripts de testes automáticos, em verdade se precisa
lidar com dois sistemas os quais precisam de manutenção
Em alguns casos os problemas com a manutenção dos testes chegam a ser maior que a manutenção do
próprio sistemas sob teste
Com linhas de produtos, ainda existe o problema de ter que portar os testes para os diferentes tipos
de produto existentes
Automação
A manutenção das suítes de testes automáticos pode se transformar em uma atividade de tempo
integral.
Isto é particularmente verdade quando um simples módulo de interface pode ter centenas de scripts
de teste.
A manutenção começa muito cedo no processo de automação de testes. É sempre desejável começar a
pensar no projeto e na implementação dos scripts de testes assim que se tenha algum informação que
já se possa automatizar.
Por outro lado, o problema que isso acarreta é que scripts de testes assim como os casos de testes
devem ser revisados sempre que os desenvolvedores alterarem o software.
http://www.alvarofpinheiro.eti.br
slide 165 de 99
Gerenciamento de Automação de testes Se houver pouco ou nenhum controle sobre como os desenvolvedores inserem mudanças nas fases de
análise e projeto dos processos, a atividade de automação de scripts pode tornar-se inviável.
Uma solução para isso é começar o projeto e não a construção o mais cedo possível.
Dessa forma, pode-se reduzir pela metade a sobre-carga de manutenção, pois apenas o projeto
necessita ser atualizado, já que os scripts ainda não forma codificados.
Claro que em algum ponto, quando a data dos testes reais se aproxima será necessária a construção
dos scripts. Entretanto é bom ter em mente que quanto mais postergar a implementação, menos
manutenção nos pré testes será necessária.
Automação
Esta abordagem pode causar um outro problema, o qual acontece freqüentemente, já que os
desenvolvedores costumam entregar os módulos funcionais do software apenas pouco tempo antes de
começar a execução propriamente dita.
Como é possível, assim, construir scripts automáticos de testes sem um protótipo executável do
software?
Tendo os casos de teste projetados e atualizados o quanto for possível, é mais fácil construir a
implementação dos scripts a tempo.
http://www.alvarofpinheiro.eti.br
Model-Based Testing
Geração automática de
casos de teste
Geração de Casos de Teste Funcional
para Aplicações de CelularesEmanuela Cartaxo
Dissertação de mestrado, UFCG, 2006
Automação
http://www.alvarofpinheiro.eti.br
Especificação de Entrada
Usualmente em notações formais, como UML
http://www.alvarofpinheiro.eti.br
Especificação de Entrada
Mais recentemente, também em linguagem natural
http://www.alvarofpinheiro.eti.br
Modelo Formal
Vários tipos de modelo podem ser utilizados
Por exemplo, Labeled Transition Systems (LTS):
http://www.alvarofpinheiro.eti.br
Model-Based Testing
Critérios de teste Guiam a geração de testes
Auxiliam a verificar a suficiência da suite de testes gerada
Geralmente derivados a partir de quatro técnicas conhecidas Funcional
Estrutural
Baseado em defeitos
Baseado em estados
http://www.alvarofpinheiro.eti.br
Critérios de Teste
Funcional Caixa preta
Objetiva determinar se o programa satisfaz aos requisitos funcionais e não-funcionais
Estrutural Caixa branca
Não se pode confiar em um programa P se existem certos caminhos que ainda não foram percorridos
Uma opção é percorrer grafos de fluxos de controle
Outra forma é percorrer grafos de fluxos de dados Informações sobre uso de variáveis: definição, uso
computacional, uso em predicado, etc.
http://www.alvarofpinheiro.eti.br
Grafo de Fluxo de Controle
Automação
http://www.alvarofpinheiro.eti.br
Formas de Percorrer o Grafo de Fluxo de Controle
Todos-Nós: Cada comando do programa é executado ao menos uma
vez, ou seja, é suficiente cobrir cada nó do grafo
Critério tido como fraco
Na prática pode não revelar nem mesmo a existência de defeitos mais simples Alguns caminhos não são cobertos
Todas-Arestas Cada desvio do fluxo de controle do programa é exercitado
pelo menos uma vez, ou seja, cada aresta do grafo é coberta
Todos-Caminhos Todos os caminhos possíveis do grafo de fluxo de controle
são executados
Número de testes gerados é demasiadamente grande (talvez infinito, devido a loops no grafo)
http://www.alvarofpinheiro.eti.br
Fonte: Teste de Software Orientado a Objetos e a Aspectos: Teoria e Prática
Paulo Cesar Masiero, Otávio Augusto Lazzarini Lemos, Fabiano Cutigi Ferrari e José Carlos Maldonado
Grafo de Fluxo de Dados
http://www.alvarofpinheiro.eti.br
Formas de Percorrer o Grafo de Fluxo de Dados
Todas-Definições Cada definição de variável é exercitada pelo menos uma
vez, não importa se por um c-uso ou por um p-uso
Todos-Usos Todas as associações entre uma definição de variável e
seus subseqüentes usos (c-usos e p-usos) sejam exercitadas pelos casos de teste, através de pelo menos um caminho livre de definição
Todos-Potenciais-Usos Pelo menos um caminho livre de definição de uma variável
definida em um nó i para todo nó e todo arco possível de ser alcançado a partir de i é exercitado
http://www.alvarofpinheiro.eti.br
Ferramenta Jabuti Apresentando o Grafo de um Programa
http://www.alvarofpinheiro.eti.br
Critérios de Teste
Baseada em defeitos
Utiliza informações sobre os tipos de erros freqüentemente cometidos no desenvolvimento para derivar os requisitos de teste
Normalmente temos modelos de defeitos característicos à tecnologia de implementação
Modelos criados baseado na experiência e resultados experimentais ou observacionais
Baseada em estados
Utiliza uma representação baseada em estados
Modela o comportamento do sistema ou unidade que será testada
http://www.alvarofpinheiro.eti.br
Teste de Mutação
Técnica baseada em defeitos
Gerar várias versões do programa original ligeiramente modificado
Tem o objetivo de revelar os defeitos mais comumente introduzidos
Conjunto de casos de teste também é avaliado quanto à sua capacidade de revelar esses defeitos
Se as saídas obtidas na execução de um mutante são iguais às saídas do programa original, cabe ao testador determinar se Mutante é equivalente ao programa original
É preciso novos casos de teste que resultem em uma saída diferente para o mutante em questão
http://www.alvarofpinheiro.eti.br
Geração de Mutantes
Algumas formas podem reduzir a quantidade de mutantes gerados sem perda de eficiência
Mutação Aleatória Gerar apenas uma porcentagem de mutantes para cada
operador
Mutação Restrita Subconjunto de operadores de mutação é selecionado e
aplicado
Mutação Seletiva Operadores responsáveis pela geração do maior número de
mutantes não são utilizados
Pode ser possível reduzir expressivamente o custo de aplicação do critério (até 80%) sem alterações significativas no escore de mutação
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE
FERRAMENTAS
http://www.alvarofpinheiro.eti.br
Ferramentas Testes
Testes é uma parte do processo de software que demanda muito
trabalho e possui um custo financeiro elevado. Por isso,
ferramentas de testes estão entre as primeiras desenvolvidas,
desde os primórdios do desenvolvimento de software. O benefício
e o sucesso de uma automação pode depender sobremaneira da
escolha correta de uma ferramenta. Os critérios para uma
ferramenta são: Habilidade: será que a ferramenta tem todas as
características essenciais; Fidelidade: a ferramenta trabalhar
durante longos períodos sem falha; Capacidade: além de
exemplos triviais e demonstrações, a ferramenta
funcionar sem falha em um ambiente industrial; Aprendizagem: a
ferramenta pode ser dominada em um curto espaço de
Tempo; Operabilidade: os recursos da ferramenta são fácies de
usar; Performance: a ferramenta é rápida o suficiente para
permitir economia na execução; Compatibilidade: a ferramenta
funciona apropriadamente com a tecnologia desejada.http://www.alvarofpinheiro.eti.br
Ferramentas Testes: para Gerenciamento
Pode prover apenas o gerenciamento dos casos de testes ou
podem dá suporte a todo o gerenciamento do processo de testes.
Os gerentes assim como os testadores, freqüentemente utilizam
esse tipo de ferramenta para verificar o progresso dos mapas de
testes em relação aos testes planejados e executados. Em outras
palavras, ela mostra o quanto já se avançou no cronograma de
execução de testes. Algumas ferramentas de gerenciamento de
testes pode rastrear individualmente as tarefas planejadas e pode
identificar quais forma completadas. Outras ainda possuem
mecanismos para registrar a identificação do defeito registrado
em uma ferramenta de gerenciamento de problema relacionado a
algum testes que esteja falhando. Desta forma é possível
monitorar o status do defeito através da interface entre as duas
ferramentas. Finalmente, esse tipo de ferramenta apresentam
uma série de relatórios e gráficos bem elaborados que podem
ser consultados a medida que os testes vão sendo executados.http://www.alvarofpinheiro.eti.br
Ferramentas Testes: para Problemas
Seu principal objetivo da verificação é descobrir defeitos no
software. Quando um defeito é encontrado, precisa-se de uma
ferramenta para ajudar na documentação e no rastreamento do
problema enquanto ele é debugado, sua correção é liberada e
finalmente verificada. Esse tipo de ferramenta também é
conhecido como ferramentas de rastreamento de defeitos e seu
principal propósito é prover um repositório centralizado onde os
defeitos não descritos e mantidos. Ela deve identificar o status
atual do defeito, se a sua causa raiz foi identificada, se seu
conserto já está liberado ou a previsão de sua liberação. Esse
tipo de ferramenta pode ser útil tanto para os testadores quanto
para os desenvolvedores. Uma boa ferramenta de gerenciamento
de problemas fornecerá direta ou indiretamente uma amarração
com uma ferramenta de controle código fonte.
http://www.alvarofpinheiro.eti.br
Ferramentas Testes: para Código Fonte
Esse tipo de ferramenta é considerada como o coração do
desenvolvimento de software, pois ela não só guarda os códigos
fontes do software, mas também deve prover mecanismos para a
serialização das partes do software produzidos simultaneamente
por múltiplos desenvolvedores. Os Testadores utilizam seus
recursos para controlar o desenvolvimento dos testes cases ou
dos scripts automáticos.
http://www.alvarofpinheiro.eti.br
Ferramentas Testes: para Planejamento
Desde software de editor de texto usados na confecção do
documento do plano de testes até ferramentas que auxiliam na
revisão do processo de teste, permitindo que revisores registrem
seus comentários diretamente no documento de plano de testes,
notificando automaticamente seu responsável.
http://www.alvarofpinheiro.eti.br
Ferramentas Testes: Cobertura de Código
São usadas para monitorar quais partes do código fonte foram
executada depois que os testes são rodados. Desta forma pode-
se obter qual parte do código ainda não foi executada.
Tipicamente, estas ferramentas fornecem estatísticas sobre o
número de vezes que cada expressão foi executada e a
porcentagem do código executado. Desenvolvidas para o uso em
testes de unidade, alguns testadores têm usadas também em
testes funcionais e mesmo testes de sistema com o objetivo de se
obter uma visão da cobertura alcançada do código. Algumas
destas ferramentas requerem que o código seja compilado
novamente ou até mesmo chegue a modificar o código afim de
habilitar a extração de informações pertinentes do caminho da
execução. Este fato deve ser levando em conta para avaliar o
custo de execução dos testes.
http://www.alvarofpinheiro.eti.br
Ferramentas Testes: Análise de Código
Servem para rastrear o código fonte e identificam erros de
codificação comuns. Elas são chamadas de estáticas, por que
não é necessário que se execute o código em análise pra ela
efetuar sua tarefa. Os erros de codificação mais comuns
encontrados por estas ferramentas são o uso de variáveis não
inicializadas, vazamento de memória (memory leaks) e o acesso
de uma posição alem do limite de um vetor (out-of-bounds array
access). Alguns erros encontrados por esse tipo de ferramenta
pode também ser identificado especificando algumas opções em
alguns compiladores. Novamente, esse é um tipo de ferramenta
que é usada mais pelos desenvolvedores, entretanto testadores
podem se valer dos relatórios gerados para identificar quais
áreas apresentam maiores tendência de apresentar problemas.
http://www.alvarofpinheiro.eti.br
Ferramentas Testes: Simuladores
Desde de automação de interface gráfica (GUI) até carga e stress
de grandes sistemas, estas ferramentas fornecem uma maneira
de automatizar grande parte do trabalho de entrada de dados dos
sistemas de uma forma muito próxima da situação real de uso
das aplicações. Imagine que o .feijão com arroz. de muitos times
de testadores de sistemas é exatamente testar como o sistema
suporta, simultaneamente, a entrada de milhares transações de
usuários. Estas ferramentas podem direcionar os testes por
várias aplicações robustas de uma maneira simples e natural. Por
exemplo, uma ferramenta desta categoria pode realizar nada
mais que simular entradas pelo teclado ou cliques de mouse para
testar um sistema baseado em web. Estas simulações de cliques
e digitações solicita transações reais, as quais realizam
chamadas à aplicações reais que por sua vez acessam dados
reais. Simulando milhares desses usuários, a ferramenta pode
encher as pilhas do sistema alvo com dados significativos.http://www.alvarofpinheiro.eti.br
Ferramentas Testes: Frameworks
Eles provêem serviços, encapsulamento ou funções que podem
invocar os casos ou scripts de testes. Eles eliminam muito do
trabalho enfadonho da automação de testes para que os
testadores possam se concentrar na criação apenas do código
necessário para exercitar os item a que se deseja testar.
Framework fornece a fundação para a criação dos testes
automáticos, oferecendo serviços que reduzem a complexidade
da implantação de certos ambientes. Vários deles são facilmente
extensíveis através de plug-ins. Esta é uma das razões por que
os frameworks são tão poderosos e ter uma vida, potencialmente,
longa. Permitem ainda que os seus usuários possam evoluí-lo
com o tempo e assim estar sempre atualizados com novas
tecnologias.
http://www.alvarofpinheiro.eti.br
Ferramentas Testes: Exemplos
http://www.alvarofpinheiro.eti.br
Ferramenta de Testes
Existem 2 tipos principais de ferramentas Ferramentas de apóio a execução dos testes
Ferramentas apóio ao planejamento e documentação de Testes
As ferramentas de execução focam em Automatização do procedimento de testes através de scripts de testes
Automatização da execução
Automatização do resultado de testes
As ferramentas de planejamento focam em Gerenciamento dos casos de teste e dos ciclos de execução de testes
Atribuição de recursos para execução dos testes
Coleta de métricas
Vários outros requisitos podem ser considerados em outras diferentes ferramentas
http://www.alvarofpinheiro.eti.br
slide 192 de 99
Motivação Testes é uma parte do processo de software que demanda muito
trabalho e possui um custo financeiro elevado.
A seleção de uma ferramenta inadequada pode acarretar
investimentos desnecessários de treinamentos, tempo e dinheiro.
Diversas atividades podem ser suportadas por ferramentas de
software, reduzindo significantemente o custo do processo de
teste.
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
slide 193 de 99
Potenciais Benefícios Redução do tempo gasto em trabalhos repetitivos .
Avaliação objetivas dos resultados esperados.
Fácilita o acesso a informações relativas aos testes e ao processo de
verificação.
Aumenta a consistência nos trabalhos enfadonhos ou muito difíceis para humanos;
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
slide 194 de 99
Tipos de Ferramentas
1. Ferramentas de suporteEstas ferramentas podem não estão diretamente envolvidas na
execução do testes, entretanto ajudam os testes e seus times a
gerenciarem suas atividades. Dentre as ferramentas deste grupo,
temos:
1.1 Ferramentas para gerenciamento de testes
Esse tipo de ferramenta pode prover suporte desde o
gerenciamento de casos de testes até o processo de
testes como um todo.
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
slide 195 de 99
Tipos de Ferramentas
1. Ferramentas de suporte
1.2 Ferramentas para gerenciamento de problemas
também conhecida como ferramentas de rastreamento
de defeitos e seu principal propósito é prover um
repositório centralizado onde os defeitos não descritos e
mantidos.
Ela deve identificar o status atual do defeito, se a sua
causa raiz foi identificada, se seu conserto já está
liberado ou a previsão de sua liberação.
Uma boa ferramenta de gerenciamento de problemas
fornecerá direta ou indiretamente uma amarração com
uma ferramenta de controle código fonte.
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
slide 196 de 99
Tipos de Ferramentas
1. Ferramentas de suporte
1.3 Ferramentas de controle de código fonte
Tradicionalmente esse tipo de ferramenta é considerada
como o coração do desenvolvimento de software, pois
ela não só guarda os códigos fontes do software, mas
também deve prover mecanismos para a serialização das
partes do software produzidos simultaneamente por
múltiplos desenvolvedores.
Os Testadores utilizam seus recursos para controlar o
desenvolvimento dos testes cases ou dos scripts
Automáticos.
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
slide 197 de 99
Tipos de Ferramentas
1. Ferramentas de suporte
1.4 Ferramentas para planejamento de testes
Esta categoria possui um leque vasto de opções. Desde
software de editor de texto usados na confecção do
documento do plano de testes até ferramentas que
auxiliam na revisão do processo de teste, permitindo
que revisores registrem seus comentários diretamente
no documento de plano de testes, notificando
automaticamente seu responsável.
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
slide 198 de 99
Tipos de Ferramentas
2. Ferramentas de análise de código fonte
2.1 Ferramenta de cobertura de código
esta categoria de ferramentas é usada para monitorar
quais partes do código fonte foram executada depois
que os testes são rodados. Desta forma pode-se obter
qual parte do código ainda não foi executada.
fornecem estatísticas sobre o número de vezes que cada
expressão foi executada e a porcentagem do código
executado.
Desenvolvidas para o uso em testes de unidade, alguns
testadores têm usado-as também em testes funcionais e
mesmo testes de sistema com o objetivo de se obter
uma visão da cobertura alcançada do código.
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
slide 199 de 99
Tipos de Ferramentas 2. Ferramentas de análise de código fonte
2.2 Ferramentas para análise estática de código
estas ferramentas rastreiam o código fonte e
identificam erros de codificação comuns. Elas são
chamadas de estáticas, por que não é necessário que se
execute o código em análise pra ela efetuar sua tarefa.
Os erros de codificação mais comuns encontrados por
estas ferramentas são o uso de variáveis não
inicializadas, vazamento de memória (memory leaks) e o
acesso de uma posição alem do limite de um vetor (out-
of-bounds array access). .
Alguns erros encontrados por esse tipo de ferramenta
pode também ser identificado especificando algumas
opções em alguns compiladores.
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
slide 200 de 99
Tipos de Ferramentas 3. Ferramentas de de apoio a execução de testesesse é o grupo que sem dúvidas possui o maior número de
ferramentas. São essas ferramentas que vão atuar na real
execução dos testes cases, além de poder diminuir a sobrecarga
da criação de testes automáticos:
3.1 Simuladores para usuários finais
Desde de automação de interface gráfica (GUI) até carga
e stress de grandes sistemas, estas ferramentas fornecem uma
maneira de automatizar grande parte do trabalho de entrada de
dados dos sistemas de uma forma muito próxima da situação real
de uso das aplicações.
Estas simulações de cliques e digitações solicita transações
reais, as quais realizam chamadas à aplicações reais que por
sua vez acessam dados reais. Simulando milhares desses
usuários, a ferramenta pode encher as pilhas do sistema alvo
com dados significativos.
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
slide 201 de 99
Tipos de Ferramentas
3. Ferramentas de apoio a execução de testes
3.2 Frameworks
algumas das mais eficientes ferramentas não fazem nada. Claro
que esta é uma caracterização injusta, mas ilustra muito bem a
natureza dos frameworks.
Eles provêem serviços, encapsulamento ou funções que podem
invocar os casos ou scripts de testes.
Eles eliminam muito do trabalho enfadonho da automação de
testes para que os testadores possam se concentrar na criação
apenas do código necessário para exercitar os item a que se
deseja testar.
Framework fornece a fundação para a criação dos testes
automáticos, oferecendo serviços que reduzem a
complexidade da implantação de certos ambientes.
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Gerenciamento de revisões e inspeções
Facilita a comunicação
Automatiza parte do processo de revisão ou inspeção
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Rastreamento de defeitos
Gerencia o ciclo de vida dos defeitos
Bugzilla
Mantis
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Visualização de Bugs
http://www.alvarofpinheiro.eti.br
Planejamento da atividade de teste Projetos de teste
Planos de testes
Versão/build do produto a ser testado
Casos de teste
Planejamento de execução Atribuição de tarefas aos testadores
Resultados de execução
Relatórios Acompanhamento da execução dos testes
Rastreabilidade dos testes com os requisitos
Etc.
Testopia
TestLink
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Testopia
Extensão do bugzilla
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
TestLink
Visão do administrador
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Criação de projetos
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Criação de papeis Projeto
Plano de teste
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Personalização de campos
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Documentos de requisitos
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Criação de requisitos
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Visão do líder
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Planos de teste
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Palavras chave
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Criação de builds
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Milestones
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Criando suites para um projeto
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Manipulando uma suite de teste
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Criando casos de teste
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Associando casos de teste a requisitos
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Incluindo testes em um plano de teste
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Atribuíndo testes a testadores
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Execução de testes
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Re-execução de testes
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Relatórios
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Demo disponível em http://testlink.org/demo
admin user: admin/testlink
leader user: leader/leader
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Suporte aos Requisitos
Verificadores de requisitos
Verificação da sintax, semântica, testabilidade
Requirements
(MSC or SDL)
Result from the
consistency and
completeness checker
OK!
Test cases from the
trace generator
Result from the
annotation checker
Not OK! Trace: …
VRS
http://www.alvarofpinheiro.eti.br
Propriedades verificadas
Consistency: Two basic transitions cannot be applied at the same time.
Completeness: For each state there must be at least one transition
applicable.
Completeness + Consistency: For all states, there exists exactly one
basic transition applicable.
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Caso os requisitos estejam consistentes e completos
PRE
POST
PRE
POST
PRE
POST
Ferramenta de Testes
http://www.alvarofpinheiro.eti.br
Suporte a Implementação
Debuggers
Syntax checker
Ferramentas de detecção de memory leak e erros de runtime
http://www.alvarofpinheiro.eti.br
Outras Ferramentas de Suporte
Geração automática de builds
Possibilitam automatizar tarefas, inclusive:
Disparar a execução de testes diariamente
Gerar relatórios e enviar por e-mail
Ant
CruiseControl
http://www.alvarofpinheiro.eti.br
Ant
Scripts escritos em XML
Exemplo de atividade automatizada Testa (fazendo antes o build)
Faz o backup
Pega atualizações de outras pessoas
Testa (fazendo antes o build)
Dá o commit das alterações
Checkout pra deixar ambiente limpo
http://www.alvarofpinheiro.eti.br
Ant
Definição de projeto e variáveis de ambiente:
http://www.alvarofpinheiro.eti.br
Ant
Definindo classpath e tipo de “tarefa” chamada junit
http://www.alvarofpinheiro.eti.br
Ant
Definindo tarefas para: Realizar backup
Atualização do código de acordo com o sistema de controlede versão (CVS)
http://www.alvarofpinheiro.eti.br
Ant
Definindo tarefa de build do projeto: Compilar código fonte do sistema
Compilar código dos testes unitários
http://www.alvarofpinheiro.eti.br
Ant
Definindo tarefa de execução dos testes Possui dependência com a tarefa de build do projeto
http://www.alvarofpinheiro.eti.br
Ant
Definindo tarefas de commit e checkout do projeto
http://www.alvarofpinheiro.eti.br
Ant
Definindo a tarefa principal do projeto Ant Testa (fazendo antes o build)
Faz o backup
Pega atualizações de outras pessoas
Testa (fazendo antes o build)
Dá o commit das alterações
Checkout pra deixar ambiente limpo
Qualquer falha interrompe o processo
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE
EXERCÍCIOS
http://www.alvarofpinheiro.eti.br
1) Marca V ou F nas razões pelas quais a especificação do software é a principal causa de bugs:
( ) A grande maioria dos software não tem uma especificação detalhada.
( ) Mudanças na especificação não são informadas para toda a equipe.
( ) A equipe de testes não tem capacidade de entender a especificação.
( ) O cliente não tem obrigação de fornecer e ajudar no detalhamento da especificação.
( ) A equipe que faz a especificação não precisa se preocupar com os testes.
( ) A equipe de testes só é alocada no final do projeto.
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE
2) Marque V para as opções verdadeiras: Qual o
objetivo de um testador.
( ) Corrigir bugs.
( ) Encontrar bugs.
( ) Garantir a qualidade do software.
( ) Garantir que o software seja perfeito.
( ) Encontrar bugs o mais rápido possível.
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE
3) Seleciona as tarefas que precisam ser
executadas antes que a primeira linha de código
seja escrita:
( ) a) Os testes automáticos estão implementados.
( ) b) O design da aplicação está fechado.
( ) c) Os requisitos estão claramente especificado.
( ) d) O manual de usuário está escrito.
( ) e) Existe um cronograma que determina as
atividades e atribuições do projeto.
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE
4) Seleciona as tarefas que precisam ser
executadas antes que qualquer atividade de
testes seja realizada:
( ) a) Implementar a primeira versão da aplicação.
( ) b) Definir o processo de testes.
( ) c) A especificação inicial dos requisitos está
fechada.
( ) d) A arquitetura do software está definida.
( ) e) Existe um cronograma que determina as
atividades e atribuições do projeto.
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE
5) Marca V ou F para o que é processo de testes:
( ) O processo de testes determinar os estágios de
teste.
( ) O processo determina as ações relacionadas a
atividade de testes.
( ) O processo de testes defini que recurso do
projeto vai executar os testes.
( ) O processo de testes defini quanto tempo dura a
execução dos testes.
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE
6) Marca V ou F para as razões que vão determinar
quais os estágios de teste que serão realizados
durante o desenvolvimento:
( ) Os estágios são determinados pelo ciclo de vida.
( ) Os estágios estão associados a equipe de
desenvolvimento. Caso a equipe tenha condições
de executar um estágio especifico isso será feito.
( ) Os estágios estão associados ao domínio da
aplicação e a tecnologia do projeto.
( ) Os estágios são determinados pelo processo de
testes.
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE
7) Marca V ou F para as afirmações relacionadas a
estágios de testes:
( ) Testes unitários são obrigatoriamente
executados por uma equipe de testes separada.
( ) Testes unitários são obrigatoriamente executados
pelo próprio desenvolvedor.
( ) Teste de sistema são obrigatoriamente
executados por uma equipe de testes separada.
( ) Testes de componente sempre são
automatizados.
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE
8) O que é testes de regressão e quando eles são executados?
( ) São testes que validam se o software atinge a expectativa do usuário, eles são executados no final do projeto.
( ) São testes realizados pelo desenvolvedor toda vez que ele faz uma modificação no código para garantir que o código está correto
( ) São testes executados quando uma primeira versão do software é fechada para verificar se o software está indo na direção correta
( ) São testes executados após uma manutenção do software para garantir que as funcionalidades principais ainda funcionam
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE
9) Marca V ou F para as afirmações relacionadas a
tipos de testes:
( ) Testes de carga só são aplicados para sistema
de banco de dados.
( ) Não existe um número de tipos de testes fixo e
as suas definições também podem variar.
( ) Teste de usabilidade são obrigatoriamente
executados por uma equipe de testes separada.
( ) Testes de performance sempre são
automatizados.
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE
10) Marca V ou F para as afirmações relacionadas a
abordagem de testes:
( ) Testes caixa preta são sempre realizados pelo
desenvolvedor.
( ) Testes caixa preta só podem ser testes de
sistema.
( ) Testes unitários são sempre caixa branca.
( ) Testes caixa preta são mais adequados para
encontrar problemas de especificação que testes
caixa branca.
http://www.alvarofpinheiro.eti.br
TESTES DE SOFTWARE
top related