fundamentos de testes de software

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)


TESTES DE SOFTWARE

INTRODUÇÃO


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


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


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


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


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


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].


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


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


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]


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


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


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


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


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


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)


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


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


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


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


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)


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>


TESTES DE SOFTWARE

EQUIPES


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.


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.


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.


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.


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.


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.


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.


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.


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


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


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


TESTES DE SOFTWARE

CICLO DE VIDA

DE UM BUG


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



O ciclo de vida também pode ser bem complexo Aberto

Resolvido como não corrigir

Resolvido como corrigido

Fechado como corrigido



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



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


Ciclo de Vida

Revisado

Rejeitado

Aberto Atribuído Trabalho Fechado

Reaberto Adiado


TESTES DE SOFTWARE

MODELOS


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


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


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


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


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


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


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


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


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


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


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


TESTES DE SOFTWARE

PROCESSO


Processo de teste

Análise

Projeto

Implementação

Testes

Produto Final

Processo de

Desenvolvimento


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


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


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


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


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


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


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


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?



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?



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


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


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


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


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



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



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


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


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



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



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



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



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


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


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


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



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



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


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


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


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


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


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?


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?


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.


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


TESTES DE SOFTWARE

PROJETO


Projeto de Teste

Entradas e Saídas

Planejamento

de Testes

Plano de Projeto

Cronograma do Projeto

Informações sobre

o sistema

Plano de teste


Projeto de Teste

Atividades do Projeto de Teste

Análise dos

requisitos

Especificação dos

casos de teste

Seleção de

casos de teste


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


TESTES DE SOFTWARE

ABORDAGENS


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


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


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


TESTES DE SOFTWARE

TÉCNICAS


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


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



Técnicas de Teste


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





Técnicas de Teste



Cobertura e Teste baseado em instruções

Cobertura e Teste baseado em laços de decisões




Técnicas de Teste




Error guessing

Testes Exploratórios


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


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


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


TESTES DE SOFTWARE

ESTÁGIOS


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


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


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


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


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


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



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



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)



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



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


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


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



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



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


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


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


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


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


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


Sequência de Estágios de Testes

Unitário

Componente

Integração

Sistema

Aceitação

Desenvolvedores Engenheiro

de Testes

Cliente

ou Usuário


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?


TESTES DE SOFTWARE

TIPOS


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.


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


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


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


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


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


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


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


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


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


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


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


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



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?



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”



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.


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


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


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


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


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


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


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


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


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


TESTES DE SOFTWARE

AUTOMAÇÃO


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.


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.


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.


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.


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.


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


Especificação de Entrada

Usualmente em notações formais, como UML


Especificação de Entrada

Mais recentemente, também em linguagem natural


Modelo Formal

Vários tipos de modelo podem ser utilizados

Por exemplo, Labeled Transition Systems (LTS):


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


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.


Grafo de Fluxo de Controle

Automação


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)


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


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


Ferramenta Jabuti Apresentando o Grafo de um Programa


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


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


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


TESTES DE SOFTWARE

FERRAMENTAS


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.


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.


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.


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.


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.


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.


Ferramentas Testes: Exemplos


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


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.



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;



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.



de 99


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.



de 99



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.



de 99



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.



de 99


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.



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.



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.



de 99


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.



Gerenciamento de revisões e inspeções

Facilita a comunicação

Automatiza parte do processo de revisão ou inspeção



Rastreamento de defeitos

Gerencia o ciclo de vida dos defeitos

Bugzilla

Mantis



Visualização de Bugs


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



Testopia

Extensão do bugzilla



TestLink

Visão do administrador



Criação de projetos



Criação de papeis Projeto

Plano de teste



Personalização de campos



Documentos de requisitos



Criação de requisitos



Visão do líder



Planos de teste



Palavras chave



Criação de builds



Milestones



Criando suites para um projeto



Manipulando uma suite de teste



Criando casos de teste



Associando casos de teste a requisitos



Incluindo testes em um plano de teste



Atribuíndo testes a testadores



Execução de testes



Re-execução de testes



Relatórios



Demo disponível em http://testlink.org/demo

admin user: admin/testlink

leader user: leader/leader



http://testlink.org/demo

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


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.



Caso os requisitos estejam consistentes e completos

PRE

POST

PRE

POST

PRE

POST



Suporte a Implementação

Debuggers

Syntax checker

Ferramentas de detecção de memory leak e erros de runtime


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


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


Ant

Definição de projeto e variáveis de ambiente:


Ant

Definindo classpath e tipo de “tarefa” chamada junit


Ant

Definindo tarefas para: Realizar backup

Atualização do código de acordo com o sistema de controlede versão (CVS)


Ant

Definindo tarefa de build do projeto: Compilar código fonte do sistema

Compilar código dos testes unitários


Ant

Definindo tarefa de execução dos testes Possui dependência com a tarefa de build do projeto


Ant

Definindo tarefas de commit e checkout do projeto


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


TESTES DE SOFTWARE

EXERCÍCIOS


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.


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.


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.


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.


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.


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.


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


( ) Testes de componente sempre são

automatizados.


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


TESTES DE SOFTWARE


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


( ) Testes de performance sempre são

automatizados.


TESTES DE SOFTWARE


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.


TESTES DE SOFTWARE

fundamentos de testes de software

Technology