Teste de Software

CEDESC Curso de Especializao em Desenvolvimento de Software PETROBRAS
Verificao, Validao e Testes: Teste de Software

Guilherme Horta Travassos
www.cos.ufrj.br/~ght
Grupo de Engenharia de Software Experimental
http://ese.cos.ufrj.br
Roteiro
Mdulo I: Conceitos e Definies de Teste de Software Mdulo II:Tcnicas de Teste de Software Mdulo III: Estratgias para Projeto e Execuo dos Testes Mdulo IV: Planejamento e Controle de Testes de Software
Copyright G.H. Travassos 2010
Mdulo I
Conceitos e Definies de Teste de Software
Mdulo I: Roteiro
Conceitos Bsicos de Teste de Software em Geral Elementos do Teste de Software Mitos associados s Atividades de Teste de Software Nveis de Teste Desenvolvimento x Teste de Software Testes de Software em Normas e Modelos de Maturidade de Processo
Definies
Garantia de Qualidade de Software
Verificao:
Assegurar consistncia, completude e corretude do produto em cada fase e entre fases consecutivas do ciclo de vida do software.
Estamos construindo corretamente o produto?.
Validao:
Assegurar que o produto requisitos do software. final corresponde aos
Estamos construindo o produto correto?.
Teste:
Examina o comportamento do produto atravs de sua execuo.
Definies
Falta (Fault):
inserida no software quando um desenvolvedor comete algum equvoco. Um equvoco pode causar vrias faltas ao mesmo tempo que vrios enganos pode causar uma falta idntica.
Falha (Failure):
Representa um comportamento incorreto apresentado por um software em conseqncia de uma falta.
Erro (Error):
Representa o quanto um resultado incorreto.
Defeito (Defect):
Termo genrico para falta, falha ou erro..
IEEE 610.12, 1990. A Glossary of Software Engineering Terminology in Schach, S.R. (2008). Introduction to Object-Oriented Software Engineering. McGraw-Hill
Teste e Depurao
Teste:
Processo de executar um software ou sistema com o objetivo de revelar a presena de falhas; ou, falhando nesse objetivo, aumentar a confiana sobre o software
Depurao:
uma conseqncia no previsvel do teste. Aps revelada a presena do erro, o defeito deve ser encontrado e corrigido
Depurao no teste!
Elementos do Teste de Software

Caso de Teste:
Descreve uma condio particular a ser testada.
Composto por valores de entrada, restries para a sua execuo e um resultado ou comportamento esperado.
Procedimento (Roteiro) de Teste:

Descreve os passos necessrios para a execuo de um ou um grupo de casos de teste
Critrios de Cobertura dos Testes:

Permitem a identificao de partes do programa que devem ser executadas para garantir a qualidade do software e indicar quando o mesmo foi suficientemente testado.
A Cobertura dos Testes determina o percentual de elementos testados em um programa.
Elementos do Teste de Software

Rodada (Bateria) de Teste:
Consiste na execuo de todos os procedimentos de teste para uma verso do produto em um determinado ambiente de teste
Uma nova rodada de teste deve ser executada caso o critrio de aceitao do produto no tenha sido atingido
Incidentes de Teste:
Qualquer evento ou comportamento diferenciado que ocorra durante a execuo dos testes que requer futura investigao
No h garantia que todo incidente seja uma falha, pois ainda precisa ser analisado
Defeitos no Desenvolvimento de Software

Quanto antes a presena do defeito for revelada, menor o custo de correo do defeito e maior a probabilidade de corrigi-lo corretamente Principal causa:
Traduo incorreta de informaes
Soluo:
Introduzir atividades de VV&T ao longo de todo o ciclo de desenvolvimento
Mitos Associados a Testes e Requisitos (1)

Mito:
No possvel testar at que o sistema exista...
Fatos:
Testar muito mais do que apenas ver o que vai acontecer E muito mais que apenas executar casos de teste! Documentos de requisitos podem e devem ser testados em relao aos objetivos do negcio ou projeto para assegurar completude e correo

Mito:
Desenvolvedores devem pensar nos requisitos apenas no incio do desenvolvimento, e se preocupar com testes apenas no final...
Fatos:
Ter os testadores envolvidos durante a anlise de requisitos uma das melhores formas de se assegurar requisitos de boa qualidade Trocas tardias nos requisitos causam impacto nos testes Ter os usurios envolvidos nos requisitos e nos testes fundamental!

Mito:
Requisitos so contrrio... utilizados no teste, mas no o
Fatos:
Voc no testa requisitos, mas testa a partir deles! fcil escrever requisitos pouco vagos ou ambguos, que parecem estar ok. Quando bons testadores observam a especificao de requisitos, eles aconselham casos de teste especficos para acertar os requisitos vagos, ambguos ou no muito explcitos. Boa engenharia de requisitos produz melhores testes; boa anlise de testes melhora os requisitos!

Mito:
Se escrever testes difcil, isto somente um problema dos testadores...
Fatos:
Nem todos os requisitos so criados de acordo com a mesma perspectiva do testador. Para alguns dos requisitos fica fcil definir o teste, para outros um verdadeiro pesadelo! Especificar requisitos no funcionais testveis tais como usabilidade ou desempenho difcil Frases como fcil de usar, interface amigvel, muito confivel ou desempenho aceitvel no representam especificao de requisitos!

Mito:
No se preocupe, pequenas requisitos no afetaro os testes modificaes nos
Fatos:
Uma modificao aparentemente pequena nos requisitos pode trazer grande impacto para os testes Voc deve testar todas as modificaes para confirmar que o sistema est executando corretamente. possvel que testes de regresso sejam necessrios O esforo do teste face a modificao vai depender dos riscos associados modificao e dos impactos conhecidos (e desconhecidos!) no sistema

Mito:
Os testadores no precisam dos requisitos
Fatos:
O sistema deve apoiar o negcio a atingir um objetivo, ento o que o sistema realmente faz deve ser comparado com este objetivo Uma especificao de requisitos representa o orculo para o teste! Sim, testadores precisam dos requisitos, caso contrrio, voc poderia argumentar que o que vem sendo executado no realmente um teste!

Mito:
Os testadores no podem testar sem os requisitos
Fatos:
Este tambm um mal entendido comum Algumas vezes modificaes so realizadas nos sistemas onde requisitos so inadequados ou no existentes. Isto faz o teste ser mais difcil, mas no possvel dizer que no pode ser feito
Aplicar teste exploratrio pode ser uma sada
Objetivo dos Testes de Software

Refutar a assertiva de que o produto est correto
Determinar entradas que faam as sadas obtidas diferirem das sadas esperadas de acordo com a especificao (busca de um contra-exemplo) um processo destrutivo, sob o ponto de vista psicolgico, contrariamente s demais fases da Engenharia de Software, onde constri-se um produto
Caracter Caractersticas dos Testes de Software

Uma das atividades mais desenvolvimento de software onerosas do
ltimo recurso para avaliao do produto antes de sua entrega ao usurio final Atividade essencial para ascenso ao nvel 3 do CMMI e Nvel D do MPS Atividade relevante para avaliao de produtos de software (ISO 9126, ISO 14598-5)
Princ Princpios de Teste de Software

Os testes devem ser rastreveis aos requisitos do usurio
devem ser realizados para testar os requisitos do usurio
Devem ser completamente planejados antes de seu incio.

O planejamento primordial para sua execuo
O princpio de Paretto se aplica:

80% de todos os erros encontrados a partir das falhas reveladas estaro concentrados em 20% dos componentes do software
Princ Princpios de Teste de Software

Devem ser aplicados inicialmente em pequena escala e depois expandidos
No possvel aplic-los exaustivamente
Para aumentar sua eficcia, deve ser executado por equipes independentes (quem no desenvolveu o software) Para evitar vis na execuo, os testadores devem ser diferentes daqueles que planejaram os testes
Teste de Software
O que identifica um bom teste ?
Possui alta probabilidade de revelar falhas No redundante abrangente o suficiente Possui um nvel adequado de complexidade
Testabilidade de Software
Simplesmente tenta mostrar a facilidade com que um software pode ser testado Operao
quanto melhor funciona, mais eficientemente pode ser testado
Observao
o que voc v o que voc testa
Controle
quanto melhor podemos controlar o software, mais podemos automatizar e melhorar o teste
Testabilidade de Software
Decomposio
Controlando o escopo do teste, podemos mais rapidamente isolar os problemas e executar re-teste adequado
Simplicidade
Quanto menos existe para se testar, mais rapidamente podemos testar o software
Estabilidade
Quanto menos modificaes, menos problemas para testar
Compreenso
quanto mais informao tivermos, mais adequado ser o teste
Teste de Software No ocorrncia de falha:

Software de alta Qualidade?
OU
Teste de baixa Qualidade?
Teste de Software
Defeitos e erros "emboscados" no software e no revelados
Falhas a se manifestarem na utilizao pelos usurios e defeitos corrigidos durante a manuteno.
CUSTOS ALTSSIMOS!
Teste de Software
Custos resultantes de testes insuficientes:
US$ 22.2 a 59.5 bi

(NIST, National Institute of Standards and Technology ,Maio 2002)
Atividade que tipicamente envolve:

Execuo do software com entradas representativas para as futuras condies de operao Comparao entre sadas produzidas e esperadas Comparao entre estados resultantes e esperados Mensurao de caractersticas de execuo (memria e tempo consumidos,etc.)
Teste de Software
Se falhas graves se manifestam torna-se necessria a modificao do projeto, se erros so encontrados com regularidade colocam Qualidade e confiabilidade sob suspeita revelando a necessidade de NOVOS TESTES!
Teste de Software
Defeitos de fcil correo indicam que as funes aparentemente funcionam bem.
Qualidade e confiabilidade aceitveis, ou testes inadequados para revelar a ocorrncia de falhas graves?
Teste de Software
Estratgias para Teste
Unidade Integrao Sistema Re-Teste
Regresso Fumaa
Requisitos Alta ordem
Projeto
Integra Integrao
Aceitao Instalao
cdigo Unidade
Teste de Software
Unidade Integrao Funcional
No-Funcional
Perspectiva dos projetistas/desenvolvedores
Perspectiva do Cliente/Usurio Aceitao Instalao
Infra-Estrutura para Teste

Driver
Interface Estruturas de Dados Locais Condies Limites Caminhos Independentes Caminhos de tratamento de erros
Componente a ser testado
Casos de Teste
Stub
Stub
Resultados
Teste de Unidade
a fase do processo de teste em que se testam as menores unidades de software desenvolvidas
O universo alvo desse tipo de teste so os mtodos dos objetos ou mesmo pequenos trechos de cdigo
Objetivo:
encontrar falhas de funcionamento dentro de uma pequena parte do sistema funcionando independentemente do todo
Existem situaes em que voc no ter os recursos para realizar o teste completo das unidades.
Selecione os mdulos crticos e aqueles complexidade e apenas teste estes mdulos Utilize inspees de cdigo com alta
Teste de Integrao
"Se todos os mdulos funcionam individualmente (analisado atravs do teste de unidade), por que se tem dvida de que eles funcionaro quando colocados juntos? O problema exatamente "coloc-los juntos" tendo uma interface. Teste de Integrao
Fase destinada construo da estrutura do programa, realizandose, ao mesmo tempo, testes para descobrir erros associados a interface A partir dos mdulos testados no nvel de unidade, construir a estrutura de programa que foi determinada pelo projeto Alm disso, encontrar falhas provenientes da integrao interna dos componentes de um sistema Tipos de falhas: envio e recebimento de dados
Ex: Por exemplo, um objeto A pode estar aguardando o retorno de um valor X ao executar um mtodo do objeto B, porm este objeto B pode retornar um valor Y, desta forma gerando uma falha
Teste de Integrao
Aplicar a abordagem big bang para integrao uma estratgia ingnua que est fadada ao fracasso.
Teste de integrao deve ser conduzido de forma incremental e organizada!
Top-Down
Quando voc desenvolve um cronograma detalhado para o projeto voc tem que considerar a maneira na qual a integrao de componentes ocorrer de forma que os componentes estejam disponveis quando necessrios
Bottom-up
Integrao bottom-up elimina a necessidade de stubs complexos
Teste de Sistema
Objetivo:
executar o sistema sob ponto de vista de seu usurio final, varrendo as funcionalidades em busca de falhas
Testes executados em condies similares (de ambiente, interfaces sistmicas e massa de dados) quelas que um usurio utilizar no seu dia-a-dia Um sistema divide-se em caractersticas Funcionais e NoFuncionais:
Funcional:
Ignora a estrutura do sistema Foco na funcionalidade
No-Funcional
Considera as caractersticas de qualidade do sistema: Portabilidade, Recuperabilidade, Segurana, Eficincia, ... Usabilidade,
Sistema = Funcional + No-Funcional
Teste de Sistema
Tipos especficos de Teste de Sistema:
Recuperao
fora o software a falhar numa variedade de situaes e verifica a capacidade de recuperao do produto
Segurana
verifica se os mecanismos de proteo construdos para o sistema iro de fato proteg-lo de alguma utilizao ou intruso imprpria.
Stress
executa o sistema de forma a exigir recursos em quantidade, freqncia ou volume anormais
Desempenho
avalia o desempenho do software quando integrado ao sistema. Normalmente est associado ao teste de stress
Estratgias para Re-Teste

Podem ocorrer para qualquer estratgia de teste, em caso de mudanas no software no planejamento dos testes Dois tipos:
Regresso
Teste de regresso uma estratgia importante para reduo de efeitos colaterais. Consiste em se aplicar, a cada nova verso do software ou a cada ciclo, todos os testes que j foram aplicados nas verses ou ciclos de teste anteriores do sistema.
Execute testes de regresso toda vez que uma modificao maior realizada no software (incluindo a integrao de novos mdulos) Efetue a gerncia de configurao
Fumaa (smoke testing)

Teste fumaa pode ser caracterizado como estratgia de integrao incremental. O software reconstrudo (com novos componentes incorporados) e exercitado diariamente.
Teste de Aceitao
Assim como os outros tipos de teste, validao tenta descobrir erros, mas o foco est nos requisitos - nas caractersticas que estaro imediatamente aparentes para o usurio final Os testes so realizados, geralmente, por um grupo restrito de usurios finais do sistema Teste formal conduzido para determinar se um sistema satisfaz ou no seus critrios de aceitao e para permitir ao cliente determinar se aceita ou no o sistema.
Critrios para Teste de Aceitao
1. 2. A funcionalidade (caso de uso) ou caractersticas de desempenho esto de acordo com o especificado e so aceitas Uma variao da especificao descoberta e uma lista de discrepncias (deficincias) criada
Teste de Aceitao
Reviso da Configurao Assegura que todos os elementos da configurao de software foram propriamente desenvolvidos, esto catalogados e possuem o nvel de detalhe suficiente para serem utilizados durante o ciclo de vida do software
Algumas vezes identificada como auditoria.
Teste Alfa e Beta Alfa: executado na instalao do desenvolvedor pelo cliente Beta: executado na instalao de um ou mais clientes pelo usurio final do software
Teste de Instalao
Consiste em instalar o sistema nos locais em que esto os usurios Dispensado no caso do teste de aceitao ter sido executado no ambiente do usurio Focam: A integridade do sistema instalado; e A verificao quanto a se alguma caracterstica funcional ou no funcional foi afetada pelas condies do local de operao
Desenvolvimento x Testes
Requisitos do Sistema
Teste de Aceitao
Requisitos do Software
Teste de Sistema
Modelo de Projeto
Teste de Integrao
Cdigo
Teste de Unidade Execuo dos testes
Projeto dos Testes
Teste de Software em Normas e Modelos de Maturidade de Processos

ISO 12207
Norma para definio de processos de ciclo de vida de software
Objetivo auxiliar na definio de processos de software organizacionais
ISO 15504 SPICE

Padro internacional para Avaliao de Processo de Software inspirada pelo Software CMM e ISO 9001
Objetivo de harmonizar diferentes modelos (Software CMM, CMMI, ISO 9001, ISO 12207 e Bootstrap)
CMMI e MPS
Modelos para estabelecimento de padro de qualidade para processos de software
Teste de Software
Recomendaes:
Convide os testadores a participar das revises dos requisitos e inspees Comece o planejamento do teste em paralelo com a anlise de requisitos Inclua sugestes de condies de teste e casos de teste para utilizar como exemplos na especificao de requisitos Inclua no documento de requisitos qualquer caso especfico que vier a mente quando estiver analisando os requisitos Utilize cenrios de negcios e casos de uso para dar exemplos especficos de como o sistema deveria funcionar Identifique critrios mensurveis para ambos os tipos de requisitos (funcionais e no funcionais) ...
Mdulo II
Tcnicas de Teste de Software
Mdulo II: Roteiro

Projeto de Casos de Teste Critrios de Teste Tcnicas de Teste:
Funcional x Estrutural x Baseada em Erros
Exerccios de Fixao
Projeto de Casos de Teste

Projeto de teste pode ser to difcil quanto o projeto do prprio produto a ser testado Poucos programadores/analistas gostam de teste; menos ainda de projeto de casos de teste Projeto de teste um dos melhores mecanismos para preveno de defeitos O projeto de casos de teste to eficaz em identificar erros quanto a execuo dos casos de teste projetados
Funciona como uma forma de reviso!
Projeto de Casos de Teste

Esteja certo que voc projeta testes para executar todo caminho de tratamento de erro
Seno, o caminho pode falhar quando ativado, revelando uma situao nem sempre agradvel do sistema
Existem algumas situaes nas quais voc no ter todos os recursos para realizar um teste completo das unidades
Selecione os componentes mais crticos e aqueles com alta complexidade ciclomtica e teste inicialmente estes
Critrios de Teste
Dados um programa P e um conjunto de casos de teste T, definem-se:
Critrio de Seleo de Casos de Teste:
procedimento para escolher casos de teste para o teste de P.
Critrio de Adequao de Casos de Teste:

predicado para avaliar T no teste de P;
Existe uma forte correspondncia entre critrios de seleo e de adequao de casos de teste
Dado um critrio de adequao C, existe um critrio de seleo CS que estabelece: selecione T tal que T seja adequado a C Dado um critrio de seleo CS, existe um critrio de adequao C que estabelece: T adequado se foi selecionado de acordo com CS
Critrio de Seleo de Casos de Teste

um mtodo de escolha de casos de teste
se obedecido, gera um conjunto de casos de teste capaz de identificar falhas causadas por uma determinada categoria de erros
Um critrio de seleo de casos de teste deve ser

vlido:
acusa falhas sempre que existam erros no artefato sendo testado
confivel:
as falhas encontradas so indiferentes escolha dos dados e das aes desde que satisfaam as condies dos casos de teste
completo:
segundo um padro de completude
vivel:
Deve possuir um custo de aplicao razovel
Critrio de Adequao de Casos de Testes

Define quais propriedades precisam ser testadas para garantir inexistncia de erros Como impossvel garantir inexistncia de erros, o conceito utilizado, na prtica, para definir uma qualidade mnima que ser validada pelo teste Objetivo:
... obter, de maneira sistemtica um conjunto T de casos de teste efetivo quanto meta principal de teste revelar falhas no programa
Propriedades:
i) incluir todos os desvios de fluxo de execuo ii) incluir pelo menos um uso de todo computacional iii) T mnimo e finito resultado
T C-adequado todo elemento requerido por C exercitado por pelo menos um t, t T

Tcnicas para Teste de Software

Tcnicas:
Funcional (ou caixa preta/caixa fechada) Estrutural (ou caixa branca/caixa aberta) Baseada em erros A questo no est em qual delas utilizar e sim como combin-las de forma a maximizar os benefcios das atividades de teste!
Tcnica Funcional
Baseia-se na especificao do software para derivar os requisitos de teste Aborda o software macroscpico de um ponto de vista
Envolve dois passos principais:

identificar as funes que o software (especificao dos requisitos, casos de uso) deve realizar
criar casos de teste capazes de verificar se essas funes esto sendo executadas corretamente
Tcnica Funcional
Problema:
Dificuldade em quantificar a atividade de teste - no se pode garantir que partes essenciais ou crticas do software foram executadas
Critrios da Tcnica Funcional:

Particionamento em Classes de Equivalncia Anlise do Valor Limite Grafo de Causa-Efeito
Tcnica Funcional
Particionamento em Classes de Equivalncia
Divide o domnio de entrada do programa em classes de dados (classes de equivalncias)
os dados de teste so derivados a partir das classes de equivalncia Eventualmente, pode se considerar o domnio de sada como referncia (ex. relatrios)
Tcnica Funcional
Dois Passos:
Identificar classes de equivalncia condio de entrada vlidas e invlidas
( um processo heurstico)
Definir os casos de teste enumeram-se as classes de equivalncia casos de teste para as classes vlidas casos de teste para as classes invlidas
Tcnica Funcional
Mtodo caixa-preta que divide o domnio de entrada de um sistema em classes (categorias) de dados das quais casos de teste podem ser derivados Fora a definio de um caso de teste que revela categorias de erros, desta forma reduzindo o nmero total de casos de teste que devem ser desenvolvidos Baseado na avaliao de classes de equivalncia para uma condio de entrada Se um conjunto de objetos podem ser ligados por relacionamentos que so simtricos, transitivos e reflexivos, uma classe de equivalncia est presente.
Tcnica Funcional
Uma classe de equivalncia representa um conjunto de estados vlidos e invlidos para uma condio de entrada. Tipicamente uma condio de entrada pode ser um valor numrico especfico, uma faixa de valores, um conjunto de valores relacionados, ou uma condio lgica. Diretrizes:
Se uma condio de entrada especifica uma faixa de valores ou requer um valor especfico, uma classe de equivalncia vlida e duas invlidas so definidas; Se uma condio de entrada especifica um membro de um conjunto ou lgica, uma classe de equivalncia vlida e uma invlida so definidas
Classe de Equivalncia: Exemplo

Especificao do programa Identifier:
O programa deve determinar se um identificador vlido ou no em Silly Pascal (uma estranha variante do Pascal). Um identificador vlido deve comear com uma letra e conter apenas letras ou dgitos. Alm disso, deve ter no mnimo 1 caractere e no mximo 6 caracteres de comprimento.
Exemplo:
abc12 (vlido); cont*1 (invlido); 1soma (invlido); a123456 (invlido)
BARBOSA, E.; MALDONADO, J.C.; VINCENZI, A.M.R.; DELAMARO, M.E; SOUZA, S.R.S. e JINO, M.. Introduo ao Teste de Software. XIV Simpsio Brasileiro de Engenharia de Software. 2000 (disponivel em http://safedevel.icmc.usp.br/coweb/checkout.php?wikipage_id=72.4&filename=transp-Ellen.pdf, ltimo acesso em 07/03/2007)
Classe de Equivalncia: Exemplo

Classes de equivalncia
Condies de Entrada Tamanho t do identificador Primeiro caractere c uma letra S contm caracteres vlidos Classes Vlidas 1t6
(1)
Classes Invlidas t>6

(2)
Sim
(3)
No
(4)
Sim
(5)
No
(6)
Exemplo de Conjunto de Casos de Teste

T0 = {(a1,Vlido), (2B3, Invlido), (Z-12, Invlido), (A1b2C3d, Invlido)}
Tcnica Funcional
Anlise do Valor Limite
Por razes no completamente identificadas, um grande nmero de erros tende a ocorrer nos limites do domnio de entrada invs de no centro Anlise do Valor Limite uma tcnica de teste que explora os limites dos valores para preparar os casos de teste Est tcnica complementa o particionamento em
classes de equivalncia
Tcnica Funcional
Anlise do Valor Limite - Diretrizes
Se uma condio de entrada especifica uma faixa de valores limitadas em a e b, casos de teste devem ser projetados com valores a e b e imediatamente acima e abaixo de a e b; Se uma condio especifica um nmero de valores, casos de teste deveriam ser desenvolvidos para exercitar os nmeros mnimo e mximo. Valores imediatamente acima e abaixo do mnimo e mximo so tambm testados
Ex: A={1..10}; Casos de Teste => {1, 10, 0,11}
Aplique as diretrizes 1 e 2 para as condies de sada. Por exemplo, assuma que uma tabela de temperatura x presso necessria como sada de um programa de anlise de engenharia. Casos de teste deveriam ser projetados para criar um relatrio de sada que produza o mximo (e mnimo) nmero possvel de entradas na tabela; Se uma estrutura de dados interna do programa tem identificados seus limites (ex. Um vetor com 100 posies), esteja certo de projetar um caso de teste para exercitar a estrutura de dados em seu limite
Anlise do Valor Limite: Exemplo

Consideremos a seguinte situao:
"... o clculo do desconto por dependente feito da seguinte forma: a entrada a idade do dependente que deve estar restrita ao intervalo [0..24]. Para dependentes at 12 anos (inclusive) o desconto de 15%. Entre 13 e 18 (inclusive) o desconto de 12%. Dos 19 aos 21 (inclusive) o desconto de 5% e dos 22 aos 24 de 3%..."
Aplicando o teste de valor limite convencional sero obtidos casos de teste semelhantes a este:
{-1,0,12,13,18,19,21,22,24,25} incluindo valores fora da faixa.
Tcnica Funcional
Grafo de Causa-Efeito
Tcnica para identificao de casos de teste que explora as condies lgicas e as aes correspondentes. Basicamente, 4 passos devem ser executados:
Para cada mdulo, Causas (condies de entrada) e efeitos (aes realizadas s diferentes condies de entrada) so relacionados, atribuindo-se um identificador para cada um. Em seguida, um grafo de causa-efeito (rvore de deciso) desenhado. Neste ponto, transforma-se o grafo numa tabela de deciso. As regras da tabela de deciso so, ento, convertidas em casos de teste.
Grafo Causa-Efeito: Exemplo

Causa: valor compra > 80 ^ #produtos < 3 Efeito: frete grtis
<3 >80 Valor compra <=80 Cobrar Frete #produtos >=3 Frete Grtis rvore de Deciso
Causa Tabela de Deciso Efeito
Valor Compra >80 #Produtos Cobrar Frete Frete Grtis V <3
>80 >=3 V
<=80 -V
Tcnica Estrutural
baseada no conhecimento da estrutura interna da implementao Teste dos detalhes procedimentais A maioria dos critrios dessa tcnica utiliza uma representao de programa conhecida como grafo de programa ou grafo de fluxo de controle
Programa Identifier.c
/* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* 01 01 01 01 01 01 01 01 01 02 03 04 05 05 06 07 07 07 08 09 10 10 11 */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ { char achar; int length, valid_id; length = 0; printf ("Digite um possvel identificador\n"); printf ("seguido por <ENTER>: "); achar = fgetc (stdin); valid_id = valid_starter (achar); if (valid_id) length = 1; achar = fgetc (stdin); while (achar != '\n') { if (!(valid_follower (achar))) valid_id = 0; length++; achar = fgetc (stdin); } if (valid_id && (length >= 1) && (length < 6) ) printf ("Valido\n"); else printf ("Invalido\n"); }
BARBOSA, E.; MALDONADO, J.C.; VINCENZI, A.M.R.; DELAMARO, M.E; SOUZA, S.R.S. e JINO, M.. Introduo ao Teste de Software. XIV Simpsio Brasileiro de Engenharia de Software. 2000 (disponivel em http://safedevel.icmc.usp.br/coweb/checkout.php?wikipage_id=72.4&filename=transp-Ellen.pdf, ltimo acesso em 07/03/2007)
Tcnica Estrutural (Grafo de Programa)
Detalhes considerados:
n arco caminho:
simples completo livre de lao
fluxo de controle
Grafo de Programa do identifier.c Gerado pela View-Graph (USP-SC)
Tcnica Estrutural (Grafo de Programa)
Ns:
blocos indivisveis
no existe desvio para o meio do bloco uma vez que o primeiro comando do bloco executado, os demais comandos so executados seqencialmente
Arestas ou Arcos:
representam o fluxo de controle entre os ns
Tcnica Estrutural
Critrios da Tcnica Estrutural:
Engenharia de Software: Teoria e Prtica Shari Lawrence Pfleeger - Prentice Hall- Cap. 08
Tcnica Estrutural
Critrios de Fluxo de Controle
Todos-Ns: 1,2,3,4,5,6,7,8,9,10,11 Todos-Arcos: arcos primitivos: <1,2>,<1,3>,<5,6>,<5,7>, <8,9>,<8,10> Todos-Caminhos
Grafo de Programa do identifier.c Gerado pela View-Graph (USP-SC)
Tcnica Baseada em Erros

Os requisitos de teste so derivados a partir dos erros mais freqentes cometidos durante o processo de desenvolvimento do software Critrios da Tcnica Baseada em Erros:
Semeadura de Erros Anlise de Mutantes (teste de unidade) Mutao de Interface (teste de integrao)
Anlise de Mutantes
Garantir a ausncia de determinados tipos de defeitos Considerando todos os programas Q, possvel provar a correo de P
T P P(t) Q(t) Q
tT
impraticvel executar e comparar todos os programas Q Estabelece-se ento uma vizinhana (P) que contm apenas um conjunto finito de programas Esses programas contm pequenos desvios sintticos que representam defeitos simples
Anlise de Mutantes
Hiptese do Programador Competente Programadores experientes escrevem programas corretos ou muito prximos do correto
Efeito de Acoplamento Casos de teste capazes de revelar erros simples so to sensveis que, implicitamente, tambm so capazes de revelar erros mais complexos
Anlise de Mutantes
Os operadores de mutao determinam o tipo de alterao sinttica que deve ser feita para a criao dos mutantes
Introduzir pequenas alteraes semnticas atravs de pequenas alteraes sintticas que representam defeitos tpicos Ex: FORTRAN (22 operadores), C (71 operadores)
Operadores dependem da linguagem alvo
X=4 Y=2 Z=1
read x, y, z m := x if m < y m := y if m < z m := z print m
read x, y, z m := x if m y m := y if m < z m := z print m
2
Aplicao de Critrios
Estudos Tericos e Experimentais avaliam:
Custo
esforo necessrio para que o critrio seja utilizado # de casos de teste para satisfazer o critrio
Strength
Dificuldade de satisfao Dificuldade de satisfazer um critrio, tendo satisfeito outro.
Eficcia
Capacidade que um critrio possui de detectar erros
Estratgia Incremental de Teste

Custo benefcio da combinao de critrios
Ambiente de Teste, Depurao e Manuteno de Software

Facilitam a aplicao de diferentes critrios para o teste
Exerccios de Fixao
1. Utilizao da Equivalncia Tcnica de Particionamento por
Programa para verificao de tipos de tringulo
2. Utilizao da Anlise do Valor Limite

Programa para verificao de temperatura e presso crticas em indstria qumica
3. Utilizao do Grafo de Causa Efeito

Programa para clculo de valor de ligao em um programa de uma companhia telefnica
Mdulo II Concluses
As tcnicas de teste atualmente existente complementares e podem ser utilizadas em conjunto so
Deve ser feita uma anlise de custo-benefcio na empresa a respeito da aplicao de vrias tcnicas em conjunto.
Diferente tipos de aplicaes (ex: 00, aplicaes web, software embarcados) possuem caractersticas especficas
Isso impacta nas atividades desenvolvimento e testes
Tcnicas diferenciadas para desenvolvimento e testes
Apoio Ferramental essencial para a aplicao dessas tcnicas como meio para reduzir o esforo e custo de sua implantao
Mdulos III/IV
Estratgias de Projeto, Execuo e Controle dos Testes
Mdulos III/IV: Roteiro

Estratgias de Teste Explorando Casos de Uso para o Teste Projetando Testes a partir de Caso de Uso Definindo e Configurando um Ambiente de Teste Executando os Testes Apoiando a Depurao das Falhas Critrio de Parada dos Testes Mtricas para avaliao dos testes Concluses
Estratgias de Teste
Baseada na implementao:
Tenta-se testar cada linha de cdigo Muito caro Muito difcil quando se tem vrios caminhos
Em OO, s vezes no faz sentido!
Baseada na especificao:
Cobrir as imposies e restries feitas pelos desenvolvedores a partir dos requisitos estabelecidos para o sistema Pode apoiar o desenvolvimento do software (teste de integrao)
Estratgias de Teste
A freqncia com que cada tipo de usurio utiliza o sistema refletir a importncia relativa das caractersticas do sistema.
Esta freqncia de uso pode ser representada por um perfil operacional
Ter um perfil operacional qualificado representa uma estratgia eficiente para descobrir defeitos que os usurios mais encontrariam.
Este perfil difcil de se obter antes do lanamento do produto
Extenses ao modelo de casos de uso podem ser feitas para se considerar este perfil operacional
Explorando Casos de Uso para o Teste

Provem uma representao para os requisitos funcionais de um sistema. Identificam todos os atores que disparam as funcionalidades do sistema.
Ator: representa um usurio do sistema ou um estmulo de um outro sistema.
Extenso ao modelo de Casos de Uso para apoiar teste

Casos de uso criticalidade:
Freqncia:
define quantas vezes um determinado uso do sistema realizado num perodo de tempo. mais difcil de ser obtida, porm possvel de ser estimada
devem
considerar
freqncia
Criticalidade:
define a importncia de um uso do sistema em relao ao contexto geral de utilizao facilmente obtida a partir do julgamento de um especialista do domnio.
Combinando-se estes dois critrios pode-se priorizar os casos de uso mais importantes e mais freqentes.
Extenso ao modelo de Casos de Uso para apoiar teste

A freqncia de utilizao do sistema deve ser registrada para cada Ator O perfil pode ser identificado a partir da anlise da responsabilidade do ator (consideraes sobre o domnio).
Esta caracterstica utilizada para ordenar os atores face a sua freqncia de utilizao individual do sistema. Pode-se considerar ordenaes relativas (primeiro, segundo,...), implcitas (alto, mdio, baixo) ou at percentuais.
Esta tcnica no altera o processo bsico de escolha de tipos de teste e de dados de entrada:
a modificao ocorre em como sistematicamente distribuir os casos de teste pelos casos de uso com uma prioridade calculada.
Extenso ao modelo de Casos de Uso para apoiar testes: Exemplo

Modelagem de um sistema bancrio simples onde os correntistas podem acessar suas contas atravs de terminais ATM. Os funcionrios acessaro estas contas atravs do sistema a ser desenvolvido. Correntistas podem realizar operaes de crdito, dbito e verificao de saldo. Os atores deste exemplo so correntista, caixa, gerente e sistema eletrnico de transferncia de fundos.
Trans E letFundos Realiz arDeps ito
Correntis ta
Reali z arSaque Caix a
G erente
Realiz arAjus tes
Processo
1. Definir o conjunto completo de atores. 2. Definir o conjunto completo de casos de uso incluindo as associaes com os atores. 3. Construir o perfil de uso para cada ator. 4. Calcular a freqncia para cada caso de uso a partir dos perfis dos atores. 5. Combinar as avaliaes de freqncia e criticalidade num valor que represente a prioridade de teste. 6. Alocar casos de teste com base na prioridade de teste dos casos de uso.
Template - Caso de Uso

ID Caso de Uso: RealizarDepsito Nvel UC: Sistema Cenrio: Atores: Transf. Eletrnica de Fundos, Gerente e Correntista Pr-Condies: Conta deve estar aberta e ativa Descrio: Trigger: Ator inicia um depsito numa conta. Sistema solicita a conta destino e o valor do depsito. Ator informa o nmero da conta e valor do depsito. Sistema responde adicionando o valor depositado. Sistema atualiza contadores de atividade na conta. Sistema verifica se valor depositado necessita de notificao e caso necessrio, gera a notificao. Requisitos Relevantes: Capacidade de aumentar valor em conta. Ps-Condies: Saldo da conta foi incrementado pelo valor depositado. Seqncias Alternativas: Se a conta no estiver ativa, ativ-la primeiro e depois Realizar o depsito. Regra de Negcio: (1) o valor do depsito deve ser maior que R$ 10,00 (2) caso o valor do depsito seja maior que R$10000,00, notificar cliente por e-mail (3) ambos os campos so obrigatrios Excees: Nmero de Conta invlida, Conta inativa e Valor Invlido. Usos concorrentes: RealizarSaque Casos de Uso relacionados: RealizarSaque Freqncia: Criticalidade: Risco:
Perfil dos Atores

Nome: Funcionrio Abstrato: S/n Descrio (Papel): Tem acesso s contas bancrias Nvel Conhecimento: Variado Perfil de Uso: Caso de Uso RealizarSaque RealizarDepsito RealizarAjustes Freqncia Relativa Alta Mdia Baixa
Nome: Caixa Abstrato: N/s Descrio (Papel): Lida diretamente com os correntistas. Nvel Conhecimento: Treinados, mas com nveis de experincia diversos. Perfil de Uso: Caso de Uso RealizarSaque RealizarDepsito RealizarAjustes Freqncia Relativa Mdia Alta __
Perfil dos Atores

Nome: Gerente Abstrato: N/s Descrio (Papel): Supervisiona os caixas e gerencia as contas. Nvel Conhecimento: Especialista. Perfil de Uso: Caso de Uso RealizarSaque RealizarDepsito RealizarAjustes Freqncia Relativa Alta Mdia Mdia
Nome: Correntista Abstrato: N/s Descrio (Papel): Dono de uma conta, pode disparar atividades na mesma. Nvel Conhecimento: Novato. Perfil de Uso: Caso de Uso RealizarSaque RealizarDepsito RealizarAjustes Freqncia Relativa Alta Mdia __
Perfil dos Atores
Nome: Transferncia Eletrnica de Fundos Abstrato: N/s Descrio (Papel): Inicia atividades na conta, com algumas restries. Nvel Conhecimento: Especialista. Perfil de Uso: Caso de Uso RealizarSaque RealizarDepsito RealizarAjustes Freqncia Relativa Mdia Mdia __
Avaliao de Freqncia e Criticalidade

Caso de Uso Freqncia Criticalidade Prioridade de Teste Alta
RealizarDepsito
Mdia
Alta
RealizarSaque
Alta
Alta
Mdia
RealizarAjustes
Mdia
Baixa
Baixa
Avaliao de Freqncia e Criticalidade

Realizar Depsito de $1000
TransEletFundos RealizarDepsito
Correntista
Realizar Depsito de $10000
Caixa
RealizarSaque
Realziar Depsito c om n de c onta invlido
Gerente
RealizarAjustes
Projeto dos Testes a partir de Casos de Uso

Um caso de uso formado por:
Atores: perfis de usurios que executam o caso de uso Pr-condies: restries para a execuo de um caso de uso Seqncia de Aes (Fluxo principal): passos ordenados para execuo de um caso de uso Ps-condies: condio final a ser estabelecida ao final da execuo do caso de uso Seqncias Alternativas: fluxos de aes que ocorrem paralelamente ao fluxo principal, dada uma ao especfica Regras de negcio: restries (regras) para execuo de um mais passos do fluxo principal ou alternativo Excees: estados invlidos para o sistema
Projeto dos Testes a partir dos casos de uso

A partir desse conjunto de informaes, os testes podem ser gerados, iniciando pelos casos de teste Passos a serem seguidos para gerao dos testes
(seguiremos o exemplo do caso de uso Realizar Depsito para o Ator CORRENTISTA, sem maiores regras):
1. Identifique os elementos presentes no caso de uso (ex.

itens de menu, campos de formulrios, botes, aes alternativas, etc.)
Itens de Menu: Depsito e Saque Campo: conta de destino e valor do depsito.
2. Identifique a dependncia entre esses elementos (ex. um

campo s pode ser preenchido caso uma opo do caso de uso tenha sido previamente escolhida)
Os campos conta de destino e valor do depsito s aparecem caso o item de menu Depsito tenha sido escolhido anteriormente

Passos a serem seguidos para gerao dos testes:
3. Defina os casos de teste individuais para cada elemento do caso de uso usando uma das tcnicas de teste apresentadas (ex. particionamento por equivalncia, anlise do valor
limite, etc.)
Nmero de equivalncia):
Conta
(usando
particionamento
por
Tcon ={(12345-6, invlida), (, invlido), (24567-2, vlido), (36265-1,invlido inativa)}
Valor do Depsito (usando anlise do valor limite):

Tval = {nulo(em branco), 9.99; 10; 10000; 10000.01}

4. Defina os casos de teste elementos de um caso de uso
CT01: CT02: CT03: CT04: CT05: CT06: CT07:
agrupando
os
diferentes
Um caso de teste ser uma tupla <(conta,valor), resultado>

<(,nulo), invlido> <(12345-6, 10),invlido> <(36265-1, 10000),invlido> <(24567-2, 9.99),invlido> <(24567-2, 10),vlido> <(24567-2, 10000),vlido> <(24567-2, 10000.01),vlido gerar notificao>

5. Represente as seqncias de aes para o caso de uso, incluindo o fluxo principal e fluxos alternativos. Alm disso, deve ser considerada a ordem de preenchimento dos elementos do caso de uso (ex. elementos que dependem de
outro)
No diagrama a seguir, estamos considerando que o sistema no finaliza a operao, caso os dados de conta de destino e valor de depsito invlidos sejam informados
Correntista
Sistema
1.O ator escolhe a opo REALIZAR DEPSITO
2. O sistema exibe a tela de depsito
3. O ator informa o valor do depsito e um telefone de contato
4. Apresenta mensagem de dados invlidos (valor < 10) ou (conta invlida) ou (conta inativa)
valor >= 10 5. O Sistema responde adicionando o valor depositado
6. Sistema atualiza contadores de atividade na conta
7. Sistema verifica se valor depositado necessita de notificao
valor <= 10000 valor > 10000 8. O sistema envia notificao or e-mail
9. O sistema finaliza o depsito e retorna tela inicial

6. A partir do diagrama definido no passo anterior, alm dos casos de teste definidos individualmente para cada elemento do caso de uso, definida o(s) procedimento(s) de teste para avaliar um cenrio do caso de uso

Os procedimentos de teste visam a definio dos passos e a ordem para executar os casos de teste definidos para os elementos do caso de uso O nmero de procedimentos de teste depende da quantidade de fluxos que podem ser extrados do diagrama construdo
Esse nmero tambm influenciado pela quantidade de casos de teste definidos para cada evento que compe o grafo
Cada evento est associado a um ou mais casos de teste

Definio dos procedimentos de teste:
7. Extraia os diferentes caminhos do diagrama, considerando que todas as aes devam ser executadas ao menos uma vez.
A deciso de qual algoritmo de grafo de programa usar depende de quem esta projetando os testes.
Ex. Caminhos diferentes em caso de ciclos podem ser extrados ou no, alm de outros problemas conhecidos de grafos.
No caso do nosso exemplo, dois caminhos foram extrados:

CAMINHO 1: 1, 2, 3, 4, 2, 3, 5, 6, 7, 9 CAMINHO 2: 1, 2, 3, 4, 2, 3, 5, 6, 7, 8, 9

Definio dos procedimentos de teste:
7. Por fim, gere procedimentos de teste que executem todos os casos de teste definidos no passo, combinando os casos de teste de diferentes elementos Procedimentos:
PT01: Teste de valores invlidos (CT01, CT02, CT03, CT04) + Teste de valor de depsito = 10 (CT05 limite inferior)
CAMINHO 1
PT02: Teste de valor de depsito = 10000 (CT06 limite superior sem a gerao de notificao)
CAMINHO 1
PT03: Teste de valor de depsito = 10000.01 (CT07 limite superior com a gerao de notificao)
CAMINHO 2
Exemplo de Procedimento de Teste

Procedimento de Teste 01:
Passo
1. 2. 3. 4. 5. 6. 7. 8. 9. Ator inicia um depsito numa conta. Sistema solicita o valor do depsito e um telefone para contato. Ator informa a conta destino e o valor do depsito. Sistema apresenta uma mensagem de dados invlidos Ator informa a conta destino e o valor do depsito. Sistema apresenta uma mensagem de dados invlidos Ator informa a conta destino e o valor do depsito. Sistema apresenta uma mensagem de valor de depsito invlido Ator informa a conta destino e o valor do depsito. CT01 CT01 CT02 CT02 CT03 CT03 CT04 CT04 CT05 CT05 CT05 CT05
Caso de Teste
10. Sistema apresenta uma mensagem de valor de depsito invlido 11. Ator informa a conta destino e o valor do depsito. 12. Sistema atualiza contadores de atividade na conta. 13. Sistema verifica se valor depositado necessita de notificao. e caso necessrio, gera a notificao 14. O sistema finaliza o caso de uso
Prioriza Priorizao de Procedimentos de Teste

Devemos supor que existam casos e procedimentos de teste para os outros casos de uso. Sendo assim, em que ordem os procedimentos de teste devem ser executados?
Normalmente, aplicaes possuem um fluxo de atividades definido Esse fluxo pode ser seguido durante a execuo dos testes Assim, resultados da execuo de um procedimento de teste pode ser aproveitado em procedimentos seguintes
Ex: primeiramente executar um cadastro, e depois uma alterao (ou excluso do item que foi includo, ou sua consulta)
Prioriza Priorizao de Procedimentos de Teste

No exemplo do sistema bancrio, podemos supor a existncia de casos e procedimentos de teste para o caso de uso LOGAR NO SISTEMA
Assim, todos os casos de teste para REALIZAR DEPSITO dependem dos casos de teste para LOGAR NO SISTEMA, pois isso uma pr-condio do caso de uso Assim, procedimentos de teste para REALIZAR DEPSITOS devem ser executados aps os procedimentos de teste para LOGAR NO SISTEMA
Uma outra opo seria unir os procedimentos de teste para o caso de uso LOGAR NO SISTEMA com os procedimentos de teste para REALIZAR DEPSITO

Note que nesses exemplos, casos e procedimentos de teste foram apenas citados, no especificados!
A especificao consiste na documentao dos casos e procedimentos de acordo com o que foi apresentado no mdulo I
Especificar as dependncias entre os casos de teste, Especificar as restries do procedimento de teste, Requisitos computacionais para execuo, ... Exemplos que no foram especificados para o sistema bancrio:
Restrio: Para todos os procedimentos de teste definidos, o correntista j deve estar autenticado no sistema) Comportamento a ser observado: atualizao do contador de atividade da conta
Definindo e Configurando um Ambiente de Teste

Antes do incio da execuo dos testes, deve ocorrer a configurao do ambiente em que os testes sero executados Isso inclui:
Espao fsico para execuo dos testes
Testes podem requerer a alocao de um espao especfico
Equipamentos
Testes podem requerer a alocao de um equipamento diferenciado (ex. servidor, um simulador, etc.)
Banco de dados e servidores

Testes requerem uma base de dados independente da base de desenvolvimento para evitar dados sem integridade (normais durante o desenvolvimento), garantindo que esses dados no interfiram nos resultados dos testes
Ferramentas
A execuo dos testes pode necessitar de ferramentas especficas para os testes, como simuladores ou capture-replay
Material de apoio, treinamento

Pode haver a necessidade de materiais adicionais de apoio ou treinamentos especficos para a execuo dos testes em um projeto. Ex. treinamento sobre o uso de um simulador de vo
Definindo e Configurando um Ambiente de Teste

O ambiente de teste deve ser configurado de acordo com o nvel de teste e com o tipo de software a ser realizado
Nvel de teste (exemplos):
Um ambiente para teste de stress deve prover uma simulao em que os recursos da infra-estrutura so sobrecarregados ou mltiplos acessos devem se providos Teste de segurana deve tentar revelar vulnerabilidades da infraestrutura onde o sistema ficar disponvel Teste alfa deve prever uma infra-estrutura similar quela em que o sistema ir funcionar aps a entrega ...
Tipo de software (exemplo):

Um ambiente de teste para sistema embarcado deve prover simuladores especficos para o hardware Alguns tipos de software requerem habilidades para execuo dos testes. Ex. um simulador de vo ...
Executando os Testes
Testador:
Seguir o que foi definido durante o planejamento Registrar todas as atividades que ocorrem
Normalmente, no conseguimos prever as falhas, e podemos perder a seqncia de eventos que a ocasionou Tentar explicar com detalhes o que levou ocorrncia da falha, utilizando telas capturas
Analisar a possibilidade de executar testes em paralelo

Alguns procedimentos de teste podem ser executados em paralelo. Ex. testes para itens diferentes
Controlando os Testes
Gerente de Teste:
Garantir que os testes planejados estejam sendo executados e verificar os resultados dos testes Analisar o grau de impacto dos incidentes relatados Repassar os incidentes de teste equipe de desenvolvimento
Utilizar ferramentas de bug tracking (ex. BugZilla)
Facilita a documentao e possibilita o acompanhamento de um incidente de teste at a sua correo pelos desenvolvedores
Definir um momento adequado para finalizar os testes

Chega um ponto onde os custos de continuar os testes so maiores que os benefcios dos testes
Apoiando a Depurao das Falhas

(Rastreabilidade) Incidente de Teste (Falha)
Observado atravs de um
Caso/Procedimento de Teste
Associado a um
Item de Teste
Que possui
Defeito
Que dever ser corrigido
Apoiando a Depurao das Falhas

(Rastreabilidade) Criar nveis na matriz de rastreabilidade para casos e procedimentos de teste
Link dos casos e procedimentos de teste com os itens do projeto
(classes componentes casos de uso requisitos)
A matriz deve ser atualizada constantemente em caso de mudanas nos itens do projeto
Facilita a evoluo dos testes, e conseqentemente testes de regresso
Indicao explcita dos casos ou procedimentos de teste a serem atualizados ou que no fazem mais parte dos testes de um software
Mtricas para Avalia Avaliao dos Testes Objetivo:

Caracterizar estatisticamente as atividades de teste de um projeto Medir, avaliar e sugerir melhorias nas atividades de teste ou de desenvolvimento para projetos futuros Permitir realizao de estudos a respeito de decises tomadas ao longo dos testes No mea s para colecionar medies! Mea para identificar ou resolver um problema.
Exemplos de M Mtricas de Teste (1) complexidade ciclomtica (McCabe) quantidade de falhas tempo gasto com teste (por fase) esforo gasto com teste (por fase) natureza das causas de falhas
ex: artefato do processo de desenvolvimento
distribuio das causas no tempo modos de observao das falhas

ex. durante os testes ou aps a entrega
Exemplos de M Mtricas de Teste (2) categoria das falhas

ex. gravssima, grave, normal, leve
distribuio de falhas por item de teste distribuio de falhas no tempo tempo para corrigir o defeito que originou uma falha esforo para corrigir o defeito que originou uma falha cobertura de teste
Mtricas para Avalia Avaliao de Testes: Exemplo de Estrat Estratgia

Objetivos da medio:
reduzir o nmero de falhas em programas entregues reduzir o esforo gasto em re-trabalho desnecessrio
Quais as perguntas que se relacionam com os objetivos:

quantas falhas por item de teste x categorias foram detectadas em produtos j entregues quanto tempo gasto em alterao de artefatos j desenvolvidos qual o percentual deste tempo que seria desnecessrio caso fossem adotados princpios mais eficazes
Mtricas a serem coletadas:

quantidade de falhas relatadas aps a aceitao # itens de teste categoria das falhas
Critrios de Parada dos Testes

Questes fundamentais:
independente da quantidade de falhas reveladas, os testes tem um perodo pr-definido de acordo com o cronograma do projeto Garantir a inexistncia de defeitos uma atividade impraticvel e custosa ao processo Definir critrios viveis para aceitao de um produto!!!
O Gerente de Teste deve tomar a deciso sobre quando parar os testes

Diferentes categorias de software possuem diferentes graus de criticalidade, alguns muito elevados
Ex: Aplicao mdica, aplicao financeira, software para avies, dentre outros.

Como chegar a deciso de parar os testes?
Os resultados dos testes direcionam essa tomada de deciso
Vamos seguir dois cenrios:

Cenrio 1:
o critrio de aceitao do produto foi atingido dentro do perodo para os testes
Cenrio 2:
O perodo para testes se encerrou e o critrio de aceitao no foi 100% atingido

Cenrio 1: o critrio de aceitao foi atingido
O nmero de falhas foi diminuindo ao longo das rodadas de teste Na rodada final, no foram reveladas falhas graves (no necessitando novos testes) Portanto, o sistema pode j se encontrar em um estado confivel.
Resultados por Rodada de Teste
100 90 80
Incidentes ou Falhas
70 60 50 40 30 20 10 0 Rodada 1 Rodada 2 Rodada 3 Rodada 4
FIM DOS TESTES!!!
Rodadas
Incidentes Falhas confirmadas

Cenrio 2: O perodo para testes se encerrou e o critrio de aceitao no foi 100% atingido
Quanto mais rodadas de teste, menor o nmero de falhas?
No necessariamente! Pode haver uma rodada que revele mais falhas que outra anterior
Fazer uma anlise custo-benefcio sobre a continuidade de executar os testes

Resultados por Rodada de Teste
40 35
Incidentes ou Falhas
30 25 20 15 10 5 0 Rodada 1 Rodada 2 Rodada 3 Rodada 4
Qual o % atingido para o critrio de aceitao do produto?
Rodadas
Incidentes Falhas confirmadas
Automao dos Testes

A qualidade e produtividade dos testes so dependentes do critrio de teste utilizado e da existncia de ferramentas de teste para apoio
Com a ausncia de ferramentas automatizadas a aplicao de um critrio torna-se uma atividade propensa a erros e limitada a projetos simples
Ferramentas apiam Teste de Regresso:

Casos de teste podem ser facilmente obtidos para reavaliao do software aps uma modificao Benefcios:
Possibilidade de verificar se a funcionalidade do software foi alterada, comparando os resultados obtidos nos testes de regresso com os resultados do teste original Reduo dos custos para a execuo de novos testes
Automao dos Testes

Ferramentas de Teste
Seleo de Ferramentas
que atividades de teste esto previstas no processo do software?
Contribuem para reduzir as falhas produzidas pela interveno humana

aumento da qualidade e produtividade da atividade de teste aumento da confiabilidade do software
Facilitam a conduo de estudos experimentais e observao de oportunidades de melhoria do processo
Automao dos Testes

Ferramentas de Teste
Possibilidades:
Gerao Execuo Gerenciamento de testes
Razes:
Testes so altamente repetitivos Tempo destinado aos testes curto
Uma execuo automtica completa pressupe:

Fornecer as entradas Executar os casos de teste Coletar e verificar os resultados
Website com diversas ferramentas de teste gratuitas:

www.opensourcetesting.org
O uso de ferramentas, embora importante, pode no ser trivial!

Concluso
A atividade de Teste no auto-contida
Ela depende de artefatos gerados em outras fases Esses artefatos devem ser construdos de forma adequada facilitando os testes
Diversas estratgias de teste podem ser adotadas. Foram apresentadas:

Heursticas para ordenao de classes OO Projeto dos testes a partir de casos de uso
Outras questes devem realizao dos testes
ser
consideradas
durante
Configurao do ambiente para teste Registro dos incidentes de teste Envio dos incidentes equipe de desenvolvimento para identificao dos defeitos Apoio depurao dos testes Automao de diferentes atividades relacionadas aos testes
CEDESC Curso de Especializao em Desenvolvimento de Software PETROBRAS
Verificao, Validao e Testes: Teste de Software

Guilherme Horta Travassos
www.cos.ufrj.br/~ght
Grupo de Engenharia de Software Experimental

Teste de Software

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Teste de Software

Hochgeladen von

Copyright:

Verfügbare Formate

CEDESC Curso de Especializao em Desenvolvimento de Software PETROBRAS

Verificao, Validao e Testes: Teste de Software

Grupo de Engenharia de Software Experimental

Copyright G.H. Travassos 2010

Copyright G.H. Travassos 2010

Copyright G.H. Travassos 2010

Estamos construindo o produto correto?.

Copyright G.H. Travassos 2010

Elementos do Teste de Software

Procedimento (Roteiro) de Teste:

Critrios de Cobertura dos Testes:

Elementos do Teste de Software

Copyright G.H. Travassos 2010

Defeitos no Desenvolvimento de Software

Copyright G.H. Travassos 2010

Mitos Associados a Testes e Requisitos (1)

Copyright G.H. Travassos 2010

Mitos Associados a Testes e Requisitos (2)

Copyright G.H. Travassos 2010

Mitos Associados a Testes e Requisitos (3)

Copyright G.H. Travassos 2010

Mitos Associados a Testes e Requisitos (4)

Copyright G.H. Travassos 2010

Mitos Associados a Testes e Requisitos (5)

Copyright G.H. Travassos 2010

Mitos Associados a Testes e Requisitos (6)

Copyright G.H. Travassos 2010

Mitos Associados a Testes e Requisitos (7)

Copyright G.H. Travassos 2010

Objetivo dos Testes de Software

Copyright G.H. Travassos 2010

Caracter Caractersticas dos Testes de Software

Princ Princpios de Teste de Software

Devem ser completamente planejados antes de seu incio.

O princpio de Paretto se aplica:

Copyright G.H. Travassos 2010

Princ Princpios de Teste de Software

No possvel aplic-los exaustivamente

Copyright G.H. Travassos 2010

Copyright G.H. Travassos 2010

Copyright G.H. Travassos 2010