capitulo 1 - introdução testes

Ncleo Ps-graduaoNcleo Ps-graduao

BEIZER, B. Software Testing Techniques. New York, NY, USA: Van NostrandReinhold, 1990

COPELAND, L. A Practitioners Guide to Software Test Design. Norwood, MA, USA: Artech House Publishers, 2007

DELAMARO, M. E.; MALDONADO, J. C.; JINO, M. Introduo ao Teste de Software. Rio de Janeiro, RJ: Editora Campus, 2007

CRISPIN, Lisa; GREGORY, Janet Agile Testing. New York, NY: Addison-Wesley, 2009

JALOTE, P. An Integrated Approach to software engineering, 2 ed., 1997, cap9.2.3 PRESSMANN, R. S.. Engenharia de Software, 3 edio, 1995, cap. 18.5.3. MYERS, G.J.. The Art of Software Testing, 1979, cap.4. SEPIN. Qualidade dos produtos de software. Disponvel em: http://www.mct.gov.br/Temas/info/Dsi/Quali2001/QualiProutosSW2001.htm

BINDER, Robert V. Testing object-oriented systems: models, patterns and tools. Addison-Wesley, 2000.

HEUMANN, Jim. Generating test cases from use cases. Disponvel emhttp://therationaledge.com/content/jun_01/m_cases_jh.html

SOMMERVILLE, Ian. Engenharia de software. 6. ed. So Paulo: Addison Wesley, 2003. H.Robinson. Graph Theory in Model-based Testing. Disponvel em http://www.harryrobinson.net/ http://www.geocities.com/harry_robinson_testing/graph_theory.htm

Bibliografia Bsica

Processo de teste Tcnicas de Caixa Preta (Funcionais) Teste de Classe de Equivalncia Teste de Valor Fronteira Teste de Tabela de Deciso Pairwise Testing Teste de Mudana de Estado Casos de Teste

Tcnicas de Caixa Branca (Estruturais) Teste de Controle de Fluxo Teste de Data Flow

Paradigmas de Teste Script de Teste(IEEE 829) Teste Exploratrio

Contedo

Familiarizao com os Conceitos Bsicos de Teste de Software (TS) Compreenso da utilizao adequada de mtodos, tcnicas e ferramentas para o Teste de Software Familiarizao com o Gerenciamento de TS Compreenso do Desenvolvimento de Sistemas e seus Testes

Objetivos de disciplina

Software Hoje Extremamente complexo Uso em diversas plataformas (e.g. web, cloud) Necessitam de qualidade, confiabilidade e segurana (safety e security) Precisam ser exaustivamente testados, em muitos casos, por meios automatizados. Testes so muito caros e muitas empresas testam o mnimo possvel (muitas vezes menos do que o mnimo!)

Introduo

Cabine EMB-190

Cockpit Space Shuttle

A atividade de teste de software um elemento crtico da garantia

de qualidade de software.

Atualmente, investimentos em testes chega 50% do esforo de projeto.

Testes tem grande importncia, mas so pouco praticados pelas

instituies e programadores.

Os testes nunca oferecem garantia de 100% da correo do software,

mas devem ser realizados para ampliar e garantir a qualidade.

Em determinados sistemas (sistemas crticos segurana), o teste

indispensvel.

Introduo

Beizer [BEI90, p. 1] descreve: Se realmente fossemos bons para programar no haveriam bugs. Se existem bugs, porque somos ruins naquilo que fazemos, e , se somos ruins nisso, devemos sentir-nos culpados por isso. Assim, a atividade de teste e o projeto de casos de teste so uma admisso de falha, o que promove uma boa dose de culpa. O tdio de testar apenas uma punio por nossos erros.

Fundamento

Beizer [BEI90, p. 1] ainda comenta:

... Se pudssemos realmente nos concentrar, se todos

usassem programao estruturada, projeto top-down,

tabelas de deciso ... Ento no haveriam bugs

Fundamento

Objetivos do Teste podem ser expressos, de forma

mais clara atravs de 3 regras (Myers, 1979):

Encontrar erros durante a execuo dos programas;

Um bom teste aquele em que a probabilidade de

encontrar um erro elevada;

Um teste bem sucedido aquele que revela um erro que

ainda no havia sido descoberto;

Fundamento

As 3 regras expressam o objetivo primordial do teste

que o de encontrar erro, contrariando a falsa ideia

de que uma atividade de teste bem sucedida aquela

em que nenhum erro foi encontrado;

Um teste bem planejado e aplicado resulta em

encontrar o maior nmero de erros possveis

em menos tempo e esforo;

O menor erro encontrado pode gerar uma hora, um

dia, ou at semanas para ser corrigido, podendo aps

sua alterao/correo gerar novos erros.

Fundamento

Ariane 5 (vdeo Capitulo 1a) Relatrio Completo (pdf Capitulo 1b)

At 36.7 seconds after H0 (approx. 30 seconds after lift-off) the computer within the back-up inertial reference system, which was working on stand-by for guidance and attitude control, became inoperative. This was caused by an internal variable related to the horizontal velocity of the launcher exceeding a limit which existed in the software of this computer. (pag 8, item 3.1.e)

Bugs

Disneys Lion King ( 1994-1995)

A Disney, em 1994 lanou seu primeiro jogo de multimdia para crianas Lion King Animated Stories.

A Disney fez uma enorme campanha de marketing nos EUA.

Vendas foram absurdamente fantsticas (vendas de natal).

Porm , no dia seguinte , 26 de dezembro de 1994 o departamento de atendimento ao cliente da Disney recebeu uma enxurrada de ligaes de clientes indignados e nervosos.

O CD no funcionava em muitas das plataformas de PC existentes no mercado.

Razo: O software foi desenvolvido em uma nica plataforma (que no refletia as mais comuns do mercado!).

Faltou um simples teste de multiplataforma....

Bugs

Patriot Missile Defense System , 1991

Um programa de defesa americano chamado de star wars inclua o chamado U.S. Patriot missile.

O primeiro uso foi na guerra do Golfo em 1991 para defender dos msseis Scuds do Iraque.

Porm , este sistema falhou inmeras vezes contra vriosmsseis , incluindo um mssil iraquiano que matou 28 soldados americanos em Dhahran, na Arbia Saudita.

Numa anlise , encontraram a causa : um bug no sistemade contagem (timing error) culminando num erro de 14 horas de diferena entre os relgios, deixando o sistema de contagem defasado.

Custo: No mnimo, 28 vidas.

Bugs

Limite de endereos de computador na WWW

Quando o TCP/IP (protocolo de transmisso de pacotes da Internet) foi criado por Vint Cerf e Bob Kahn, eles acharam que 4.3 bilhes de endereos eramsuficientes.

Parece muito, mas com o crescimento exponencial de transaes nessa plataforma, pode-se atingir o limiteantes do previsto.

Um consrcio de organizaes governamentaisampliou este nmero para mais de 200 trilhes de endereos possveis.

Qual o impacto da mudana nos computadores do planeta todo?

Bugs

Bug do Milnio.

Vdeo [Capitulo 1e - Bug do milnio]

Bugs

Grace Hooper Pioneira de teste de software

1943 Alistou-se na Marinha (admisso especial: pesava somente 105 lb e precisava pesar 120 lb, mnimo)

1944 Primeiro lugar -> Harvard (computador Mark I) 1946 Recusada na ativa da marinha (muito velha:38 anos) fica na reserva da Marinha

1946 - 1949 Harvard 1950s Compilador A > FLOW-MATIC -> COBOL 1970s Padres para testar sistemas de computador e seus componentes, principalmente software

1966 Reformou-se como Ten. Cel. (Commander) 1972 Reconvocada! 1973 Promovida a Coronel (Captain)! 1983 Promovida a Commodore 1985 Promovida a Contra-Almirante (Rear Admiral) 1986 Finalmente reformou-se, mas continuou a usar seu uniforme de Almirante nas palestras e seminrios.

1992 Faleceu

Incio

Grace Hooper Pioneira de teste de software

Incio

Registro do 1 bug

In 1946, when Rear Admiral Grace Hopper was released from active duty, she joined the Harvard Faculty at the Computation Laboratory, where she continued her work on the Mark II and Mark III. Operators traced an error in the Mark II to a moth trapped in a relay, coining the term bug. This bug was carefully removed and taped to the log book

Incio

Processo de Software



muito bem definido

pessoas

procedimentos

ferramentas Req usurios

Req. desenvolvedor

Req. organizao

Gerncia eficaz e controle das

atividades

Mtodos de Produo

23

Slide: 23

Na Engenharia de Software, existem vrias metodologias de produo ...

Focaliza o quFocaliza o qu

Anlise do sistemaAnlise do sistema

Fase planejamentoFase planejamentoAnlise de requisitosAnlise de requisitos

Focaliza o comoFocaliza o comoProjeto da ArquiteturaProjeto da Arquitetura

CodificaoCodificaoTestesTestes

Focaliza as mudanasFocaliza as mudanas

Manutenes A.C.E.Manutenes A.C.E.

DefinioDefinio

DesenvolvimentoDesenvolvimento

ManutenoManuteno

Informaes processadas

Funo e desempenho desejados

Riscos mapeados

Interfaces estabelecidas

Arquitetura da soluo

Estrutura de dados

Padres de codificao

Planejamento dos Testes

Contramedidas para a gerncia da produo

Padres de Qualidade

Existem vrios modelos e padres de qualidade:Existem vrios modelos e padres de qualidade:

No Brasil, fala-se muito e faz-se pouco (SEPIN, 2004)

Padres de Qualidade

Modelo de Produo

26ProcessoProcesso ProdutoProduto

Requerimentos

Anlise

Desenho

Codificao Testes de Unidade

Testes de Sistema

Testes de Aceitao

Testes de Integrao

teste

teste

teste

teste

doc

doc

doc

doc

[SQUARE ISO 25000] (DEF)

Engano* Ao humana que produz o defeito

Defeito Imperfeio ou anomalia que pode causar uma inadequao ou falha no SW Erro Manifestao de um Defeito (D) Falha Manifestao de um Defeito (D), que causa uma operao defeituosa no SW

* pouco usado

Defeitos e Falhas em Software

Padro para Documentao do Teste de Software Tem por objetivo descrever os documentos necessrios para apoiar a atividade de teste de software. Os documentos descritos neste padro abrangem o planejamento, especificao e a gerao de relatrios de testes.

IEEE 829

composto pelos documentos de: Especificao do plano de teste Prescreve o escopo, o plano de ao, os recursos e o cronograma das atividades de teste;

Especificao do projeto de teste Refina o que foi definido no plano de teste e identifica as caractersticas que sero testadas;

Especificao do caso de teste Detalha cada caracterstica que ser testada;

Especificao do procedimento de teste Especifica os passos para execuo do caso de teste;

(cont.)

IEEE 829

composto pelos documentos de (cont): Relatrio de transio de item de teste Identifica os itens que esto sendo enviados para a equipe de testes;

Log dos testes (dirio de bordo) Prov um histrico cronolgico dos detalhes relevantes da execuo dos testes;

Relatrio de incidente Documenta qualquer evento que ocorreu durante o processo de teste e que requer investigao;

Relatrio com resumo dos testes Sumariza os resultados dos testes projetados.

IEEE 829

Testar o processo de comparar o que com o

que deveria ser (Copeland, 2007)

De acordo com o IEEE Standard Glossary of

Software Engineering Terminology (610.12 - 1990)

testar :

O processo de operar um sistema ou componente sob

condies especificadas, observando e/ou

registrando os resultados, enquanto avalia o

sistema ou componente sob algum aspecto.

Processo de Teste

Processo de Teste

Especificao do software

Orculo Sucesso ou Falha

Entradas Processamento

Especificao de Software

Requisito (Aurlio) Condio que deve ser satisfeita para que uma coisa fique legal e regular;

Exigncia imprescindvel para a consecuo de certo fim;

Qualidade, dotes, predicados exigidos para um produto;

Requerimento Ato ou efeito de requerer (pedir /solicitar).

Processo de Teste

Especificao de Software

Para o Analista Um requisito algo que o produto deve fazer ou alguma qualidade que deve apresentar.

Para um Testador Um requisito algo (verificvel) que o produto deve fazer ou alguma qualidade (mensurvel) que deve apresentar e que (pelo seu risco de comprometer o sucesso do projeto, compen$a) deve ser testado.

Processo de Teste

Viso sobre a qualidade de um software

Processo de Teste

Usurio Desenvolvedor Testador Organizao

Facilidade de uso, desempenho,

confiabilidade dos resultados, etc.

Facilidade de manuteno e

conformidade em relao aos requisitos de usurios, etc.

Software com boa qualidade aquele que cumpre com os requisitos negociais com o mnimo de falhas possvel.

Cumprimento de prazo, boa previso de custo, boa

produtividade e rentabilidade.

Em projetos de Casos de Teste, determinar as sadas esperadas funo do ORCULO.

Um orculo qualquer programa, processo ou dados (tabela) que propicie ao testador a sada esperada resultante de um teste.

Processo de Teste

Tipos de Oraclos:1. Kiddie: roda e v o que d2. Teste de regresso: roda e compara com verso

anterior3. Dados validados: roda e compara com padres

(tabelas)4. Sutes de Teste padro: checa contra

resultados validados (em geral dados comprados de empresas especializadas em testes)

5. Programa existente: roda e compara com outra verso

Processo de Teste

Testador

Processo de Teste

Viso Restrita Viso Abrangente Um bom testador um bomprogramador;

Testar significa mais gastos de recursos e tempo do projeto;

O testador s deve acharerros.

Um bom testador aquele quedomina as regras negociais do SUT (System Under Testing);

Testar significa investir paragastar menos;

Alm de ach-los, o testadordeve indicar como evit-los e preveni-los.

Frases para o Testador Fique preparado: tudo vai bem at o seu relatrio apontar o primeiro problema; Voc apenas um inspetor ! A garantia da qualidade no a sua responsabilidade. Bugs so altamente relevantes ao ciclo de produo; Mantenha seu senso de humor e aceitao. No se irrite por estar testando uma bxxxx Faa seu trabalho e tenha vida normal aps o expediente de trabalho. Voc s pode testar aquilo que se pode observar;

Processo de Teste

Frases para o Testador Algum aqui j testou um sistema de bilhetagem ???? Use a disciplina a seu favor: torne-se amiguinho de padres e processos; Fique esperto: nunca se ter tempo suficiente para se testar um SUT; No se iluda: no existe Software Zero-Defect ! Desenvolvedores no so inimigos !!! Sobre o SUT: simplicidade no sinnimo de facilidade.

Processo de Teste

Papis e Responsabilidades

Processo de Teste

Papel ResponsabilidadesGerente, Coordenador ouLder de testes

Viabiliza os recursos necessrios para um esforo detestes; conduz as atividades e as monitora emconformidade com o planejamento; Realoca recursosao longo do ciclo.

Analistas de Testes Planeja a estratgia e elabora casos de testes,baseando-se nos requisitos de negcio do SUT.

Arquiteto de Testes Prepara toda infra estrutura necessria para seexecutar a estratgia de testes. Instala ferramentas,gera massa de dados, mede performance, etc.

Executor de Testes Executa tudo o que est planejado. Figura-chave dociclo de testes pois as ocorrncias encontradas por eleso os indicadores da qualidade do produtoinspecionado.

Premissas dos Testes

Processo de Teste

Registrar/monitorar erros

Analisar todos os requisitos

Produzir mtricas

Formular indicadoresde qualidade

Todos os testes devem ser rastreveis at a sua

origem.

Planeje sempre. Mas seja comedido!

Crie casos de testes genricos;

Testes no tm fim. Eles apenas provocam um

ponto de corte!

Antes de executar um esforo de testes defina

bem os papis e responsabilidades;

Processo de Teste

Aproximadamente 60% das falhas ocorrem naconcepo do produto (Especificao)

Processo de Teste

Artefatos

Processo de Teste

Requisitos

Plano/ Estratgia

Cenrios/ Roteiros

Casos de Testes

Etapas

Requisitos: lista contendo todas as necessidades negociais do SUT (funcionais/no funcionais);

Plano ou estratgia: documento com o conjunto das atividades do esforo de teste. Aqui se definem os tipos de testes, cronograma, papis, responsabilidades e infra necessria;

Cenrio ou roteiro: conjunto de casosde testes que sero executados paracobrir um ou mais processos negociais;

Casos de teste: um conjunto de procedimentos que valida/verifica um oumais requisitos negociais;

Etapas: aes de validao/verificaode um caso de teste.

Ciclo de Teste

Levantamento de

Necessidades

Anlise dos Requisitos e Artefatos

Especificao/Desenho

Inspeo e Validao

Corrigir e solucionar dvidas

Esclarecimento

Reescrever

Revalidar

EnviarDefeito

Fornecedor

Abrir Defeito

Retestar Defeito

Cancelar Defeito

EncerrarDefeito

Defeito ?

BUGFix ?

Ciclo de Reparo de Defeitos

Gerenciamento de Testes e Defeitos

Gerenciamento do ciclo de produo do software

Neste nvel, no h diferena entre testar e debugar. O teste no tem propsito determinado

Nveis de Maturidade de Teste Nvel 0

O propsito do Teste mostrar que o software (SW) funciona (no falha). O conjunto de dados de teste pode ser escolhido de tal forma que o SW funciona para ele, mas pode falhar para outro conjunto. Este tipo de teste (muito comum quando se quer vender algo!) pode no propiciar a descoberta de Defeitos.


O propsito mostrar que o SW no funciona, para algum conjunto de dados. Normalmente o conjunto de dados de teste escolhido procura checar o envelope do sistema. O sistema pode funcionar para algum conjunto menos exigente de dados


O propsito do Teste no mostrar que o SW funciona ou no funciona, mas reduzir o risco percebido, caso ele no funcione para algum conjunto de valores.

Deve ser notado que embora o caso ideal seja testar todas as possibilidades, isto no fisicamente possvel.

Paradoxo do Teste de SW: No possvel testar todas as possibilidades


Testar, neste nvel, no um simples ato. uma disciplina mental que resulta em SW de baixo risco, com pouco esforo de teste. Neste nvel de maturidade o SW testado desde sua concepo. A gerao do cdigo feita de tal forma que facilite a tarefa de testar e de preparar o teste. Este tipo de teste (deveria) utilizado nos mtodos geis de desenvolvimento de software, como o SCRUM.


Caixa preta (funcionais) Baseado nos requisitos e especificaes. Uma boa especificao fundamental neste caso.

Caixa branca (estruturais) Baseado na estrutura interna do programa. O testador precisa ter grande habilidade em programao

Caixa Cinza combinao dos anteriores

Tipos de Teste

Testes Estticos: Utiliza projeto e principalmente o cdigo-fonte para obter resultados; Permitem encontrar uma quantidade relativamente satisfatria de erros, mas no so definitivos; A busca de erros neste teste pode ser feita por inspeo, onde uma equipe designada analisa o cdigo luz de um questionrio especialmente concebido check list;

Modalidade de Testes

Testes Dinmicos: Baseiam-se na execuo do programa atravs de casos de teste; Escolha do subconjunto de dados uma tarefa complexa, devendo ser baseada no conhecimento dos requisitos e dados sobre o projeto;

Modalidade de Testes

Teste de Unidade Teste de Integrao Teste de Sistema Teste de Aceitao: Quem define o nvel para a aceitao? Quem cria os scripts para o teste? Quem executa o teste? Qual o critrio de passar/falhar? liberado o acesso ao ambiente da Nuvem? Quando e como o produtor pago?

Nveis (fases) de Teste

Realizados sobre as unidades (mdulos/classes); Deve-se basear no projeto detalhado com guia; O que testar?

Interface: erros de passagem de dados; Estruturas de dados locais: integridade; Condies limite: mximos e mnimos; Caminhos independentes: execuo das instrues; Tratamento de excees: teste de robustez;

O teste de unidade baseado no teste de caixa branca;

Teste de Unidade

Baseado em casos de teste, como mostra a figura:

Teste de Unidade

Casos de Teste

Mdulo Interface Estrutura de dados locais Condies de limite Caminhos independentes Caminho de tratamento de erros

Myers (1979) prope uma lista de conferncia para os

testes de interfaces:

O nmero de parmetros de entrada igual ao nmero de

argumentos?

Os atributos de parmetro e de argumento so compatveis?

Os sistemas de unidade de argumentos e de parmetros

so compatveis?

Vdeo [Capitulo 1f Mars Climate Orbiter (MCO)]

O nmero de argumentos transmitidos aos mdulos

chamados igual ao nmero de parmetros?

Teste de Unidade

Myers (1979) ... testes de interfaces:

Os atributos dos argumentos transmitidos aos mdulos

chamados so iguais aos atributos dos parmetros?

Os atributos numricos e a ordem dos argumentos para

funes embutidas esto corretos?

Existem quaisquer referncias a parmetros no

associados ao ponto de entrada atual?

Definies de variveis globais consistentes ao longo dos

mdulos?

Teste de Unidade

Objetiva a busca de erros surgidos quanto a integrao

das diferentes unidades dos componentes do software;

Testes de unidades no garantem que os mdulos

consigam trabalhar sem erros em conjunto com outros

mdulos;

A grande maioria dos erros encontrados so quanto a

erros de interface, devido, principalmente, s

incompatibilidades de interface entre mdulos que

trabalham em conjunto;

Teste de Integrao

Top-down: A integrao top-down uma abordagem incremental construo da estrutura de programa; Os mdulos so integrados movimentando-se de cima para baixo atravs de sua hierarquia; Os mdulos subordinados ao mdulo de controle principal so incorporados estrutura de uma maneira depth-first (primeiramente pela profundidade) ou breadth-first (primeiramente pela largura);

Teste de Integrao

Top-down:

O processo de integrao executado em 5 passos:

O mdulo de controle principal usado como um driver de

teste e os stubs so substitudos para todos os mdulos

diretamente subordinados ao mdulo de controle principal;

Dependendo da abordagem de integrao escolhida (depth-

first ou breadth-first), os stubs subordinados so substitudos,

um de cada vez, por mdulos reais;

Testes so realizados medida que cada mdulo integrado;

Teste de Integrao

Top-down:

O processo de integrao executado numa

srie de 5 passos (cont.)

Durante a concluso de cada conjunto de testes,

outro stub substitudo pelo mdulo real;

Teste de regresso (isto , a realizao de todos ou de

alguns dos testes anteriores) pode ser realizado a fim

de garantir que novos erros no tenham sido

introduzidos;

Teste de Integrao

Integrao Top-down

Teste de Integrao

M1

M2 M3

M7

M4

M5 M6

M8

Bottom-up:

O teste de integrao bottom-up, inicia a construo e os

testes como mdulos atmicos (isto , mdulos

localizados nos nveis mais baixos da estrutura de

programa);

Uma vez que os mdulos so integrados de baixo para

cima (bottom-up), o processamento exigido para os

mdulos subordinados em determinado nvel est

sempre disponvel, e a necessidade de stubs eliminada;

Teste de Integrao

Bottom-up:

Uma estratgia de integrao bottom-up pode ser

implementada segundo:

Mdulos de baixo nvel so combinados em clusters (as

vezes chamados construes) que executam uma sub-

funo de software especfica;

Um driver (um programa de controle para teste) escrito

para coordenar as entradas e a sada do caso de teste;

O cluster testado;

Os drivers so removidos e os clusters so combinados ao

se dirigir para cima na estrutura de programa;

Teste de Integrao

Integrao Bottom-up:

Teste de Integrao

Mc

Ma Mb

D1 D2 D3

Cluster 1

Cluster 2

Cluster 3

Teste Alfa e Beta: O objetivo do teste Alfa e Beta testar o software na viso do cliente/usurio, ou seja, fazer com que o prprio cliente seja o responsvel por uma etapa de teste;

Testes de Validao

Conjunto de testes efetuados pelo produtor do software in-house. Deve ser efetuado pela equipe de desenvolvimento (de responsabilidade dos testadores, mas com ajuda dos clientes e dos desenvolvedores). Realizados pelo usurio, geralmente nas instalaes do desenvolvedor, que observa e registra erros e/ou problemas.

Teste

http://www.google.com/glass/start/how-it-feels/ Vdeo [Capitulo 1g - How it Feels [through Google Glass]]

Teste

Feito pelo usurio em operao normal, sem superviso do desenvolvedor. Muito popular por aparentemente baratear o custo para o produtor, mas no considerado srio por testadores profissionais, pois os usurios em geral no se utilizam de mtodos de testes sistemticos e muitas vezes recebem o software ainda no pronto. Os problemas e erros devem ser reportados ao desenvolvedor.

Teste

O teste de sistema baseado em teste global; Deve-se criar mtodos para evitar que o desenvolvedor ao encontrar um erro, no jogue a culpa pra frente; Problemas de integrao do software com outros elementos so factveis e devem ser testados; Testes de recuperao, segurana, estresse, e de desempenho, so abordados nesta etapa;

Teste de Sistema

Teste de Recuperao Neste tipo de teste, falhas so provocadas artificialmente (por uma tcnica denominada injeo de falhas), de modo a analisar a capacidade do sistema do ponto de vista da recuperao; Os valores de tempo exigidos para recuperao do sistema (seja automtico ou manual) devem ser registrados e confrontados aos valores especificados; Exemplo: Simulao de falha de energia eltrica Simulao de desligamento e religamento de servidor

Teste de Sistema

Teste de Segurana: Visa garantir que o sistema no ir provocar danos recuperveis ou irrecuperveis pela sua prpria ao;

No teste de segurana, o analista deve desempenhar um papel semelhante ao de um hacker, tentando contornar todos os mecanismos de segurana implementados, como: Derrubar o sistema como um todo; Acessar informaes confidenciais; Modificar informaes de bases de dados; Interferir no funcionamento do sistema; Introduzir vrus de computador no sistema; Sobrecarregar o sistema pela multiplicao de processos;

Teste de Sistema

Teste de Estresse : Consiste em verificar como o sistema vai se comportar em situaes limites; O limite pode ser verificado sob diferente pontos de vista: Limite em termos de quantidade de usurios conectados a um determinado sistema servidor;

Quantidade de utilizao de memria; Uso em diferentes verses de processadores; Quantidade de bloqueios encontrados num dado perodo de utilizao;

Teste de Sistema

Teste de Desempenho: Consiste em verificar se os requisitos de desempenho esto sendo atendidos para o sistema como um todo. Muito importante este teste em aplicaes multimdia. Em sistemas crticos ou de alta velocidade, esse teste indispensvel, e caso no passe por esse teste, todo o sistema pode correr o risco de ser remodelado. Exemplo: cmeras de alta taxa de amostragem.

Teste de Sistema

A atividade de teste de software um elemento de um tema mais amplo que freqentemente chamado de Verificao e Validao (V&V);

A verificao refere-se ao conjunto de atividades que garante que o software implemente corretamente uma funo especfica;

A validao refere-se a um conjunto diferente de atividades que garante que o software que foi construdo atende as exigncias do cliente;

Estratgia de Teste

Boehm [BOE81] avalia de outra maneira:

Verificao: Estamos construindo certo o produto?

Validao: Estamos construindo o produto certo?

Estratgia de Teste

Se um software no desempenhar a funo para a qual ele foi designado podem haver prejuzos materiais considerveis e at perda de vidas. O teste parte essencial das metodologias de desenvolvimento de software modernos (Agile) Por isso o teste, mais exaustivo possvel, essencial em praticamente todas as aplicaes, principalmente em: Nuclear e Espao Aeronutica Finanas

necessrio testar?

Aspectos Psicolgicos: O interesse do desenvolvedor demonstrar que o fruto do seu trabalho incrvel, inquestionvel, e esse pensamento provoca um abrandamento no sentido de descobrir erros ao longo do processo de testes;

O orgulho do ES grande demais para que ele mesmo tenha que descobrir seus prprios erros;

Testar seu prprio software demonstrar que sua capacidade de programador limitada, pois com certeza ele sabe que pode haver erros, e poder querer esconder tais erros;

Do ponto de vista do construtor de software, os testes podem servir como teste destrutivo;

Infelizmente se o erro no for descoberto antes da fase de manuteno, o cliente o descobrir;

O desenvolvedor deve testar?

O construtor de software deve tambm participar dos testes, principalmente dos testes internos do cdigo-fonte; Evitar que o construtor de software participe de testes externos como de interface e entrada e sada de dados devem ser evitadas; Contratar uma equipe terceirizada para a realizao dos testes de grande utilidade, pois nada melhor do que pagar para que outros achem defeitos; pimenta nos olhos dos outros refresco!;

O desenvolvedor deve testar?

A resposta, em geral, NO

No possvel testar, em tempo finito, dentro do oramento, todas as possibilidades de entrada de dados e todos os caminhos (trajetos) possveis que o processamento exige.

possvel testar exaustivamente um software?

Todo mundo entende caro complicado muito demorado Requer pessoal especializado Ambiente de teste difcil (Nuvem) Os desenvolvedores detestam ( em gil) No possvel testar de forma completa Por onde comear? Quando terminar o teste?

Dificuldades para testar software

Em geral, no possvel testar todas as possibilidades

Deve-se testar o mnimo necessrio e suficiente

Apesar das assertivas acima, o resultado deve conduzir ao menor risco possvel de se ter defeitos e/ou falhas no SW

Paradoxo de Teste

Pouco tempo para testar adequadamente Muitas combinaes de entrada Dificuldade de determinar a sada correta (orculo) Requisitos no existentes ou variveis Falta de ferramenta de teste Ambiente no controlado (e.g. Nuvem) Gerncia que no entende ou (aparentemente) no se importa com a qualidade do SW

Desafios

Requisito base do teste No se pode testar aquilo que no se sabe; Clientes sempre mudam os requisitos; Uso de prottipos no pode ser desculpa para nodocumentar requisitos;

Interfaces grficas abrangem unicamente requisitosfuncionais de alto nvel, sem detalhes, sem regrasde negcios;

Usurios no sabem o que querem at terem algopaupvel.

Melhores Prticas

Um bom software aquele que fcil de configurar: customizar uma funcionalidade conforme as necessidades do usurio deve ser uma tarefa fcil para ele;

Est em conformidade com os requisitos que o cliente pediu. eficiente: recursos de infraestrutura atendem a performance da funcionalidade (processador, memria, discos e linhas de comunicao);

Seja escalvel: recursos que permitam a utilizao de objetos e componentes de estrutura funcional para compor os novos requisitos de sistema (isso ideal para a perfeita manuteno do software);

Tenha flexibilidade: procedimento que permite a mudana do software em ambientes diferentes. Ex.: mudana de Banco de Dados;

Tenha integridade: que a habilidade do software proteger a ele mesmo atravs de nveis de acesso.

Melhores Prticas

Um bom software aquele que tenha/seja Interoperabilidade: capacidade de trocar dados com outros softwares;

Facilidade de manuteno: reutilizao de componentes, parametrizao, orientao a objetos, etc;

Segurana: capacidade do software executar uma funcionalidade sem causar condies inseguras;

Facilidade de uso: facilidade que o software pode ser aprendido e operado;

Verificvel: capacidade de verificar que o software est trabalhando corretamente.

Melhores Prticas

Adote um modelo baseado em requisitos A linguagem escrita no um meio confivel de especificar requisitos. Podem aparecer requisitos: Vagos Ambguos Incompletos De difcil compreenso e entendimento No to fceis de se testar

DICA: Use alguns desses modelos para incrementar a linguagem escrita: Modelo de processos Tabelas de deciso Casos de uso

Melhores Prticas

Defina formalmente os Casos de Teste Para cada requisito, identifique os possveiscenrios;

Use tcnicas como: Classes de equivalncia; Grficos de causa e efeitos; Tabelas de deciso; rvores de deciso; Anlise da integridade relacional; Casos de uso.

Melhores Prticas

Execute casos de testes positivos e negativos Testes positivos: qualquer atividade que aponta a validao de um requisito. Supe-se que o dado entrado vlido e ele ser processado atravs dos caminhos normais;

Testes negativos: processo de execuo de um programa com a inteno de encontrar erros. Supe-se que o dado entrado invlido e ele ser processado atravs da manipulao errada dos caminhos funcionais;

Melhores Prticas

Execute testes de regresses mais abrangentes Baseie os cenrios de teste de regresso em: Anlise de impacto Quando um requisito modificado, quais so os componentes afetados com a mudana ?

Quando um componente modificado, quais os requisitos que devem ser retestados?

Este tipo de anlise comea no desenvolvimento com os programadores e continua durante a fase dos testes

Anlise de risco Ferramentas de Capture/Playback podem ser muito til (inclusive para automatizar os testes de regresso).

Melhores Prticas

Selecione ferramentas para suportar os testes Ferramenta de planejamento de testes Gerenciamento de testes Ferramentas de Case Design Ferramentas para testes de cobertura Ferramentas para execuo de testes e de capture/replay

Ferramentas para anlise esttica BugTrackers

Melhores Prticas

Capacite constantemente Teste de software uma disciplina contextual; A prtica a melhor maneira de aprimorar seus conhecimentos;

Procure se certificar profissionalmente: CSTE (QAI/USA) (produto): preparao do ambiente de testes; planejamento de testes; test design; execuo de testes; automao; ferramentas; elaborao de relatrios; etc.

CSQA (QAI/USA) (processo): estrutura de modelos de qualidade; definio de padres de prtica e controle de qualidade; construo, implementao e melhoria dos processos de qualidade; mtricas.

CBTS (ALATS/BRZ)

Melhores Prticas

Ambiente de Produo

Em desenvolvimentoEm teste

Em teste

Em homologao

Em homologaoEm produo

Ambiente de Produo

Ambiente de Produo

Toda a estrutura destinada aos analistas de sistema e programadores;

segmentado em produo e testes facultativo o uso das equipes

Ambiente de Produo

Toda a estrutura destinada equipe de testadores

Testa os requisitos de software Estrutura semelhante ao da produo

Ambiente de Produo

Pelos erros ocorridos e mtricas coletadas, novos casos sero confeccionados para garantir a qualidade de software

Beta testes somente para um grupo de usurios

Se me fosse dado seis horas para derrubar uma rvore, as quatro primeiras passaria afiando o machado. (Abraham Lincoln) Planeje sempre a sua medio. Uma mtrica a fotografia de uma situao em um dado momento; Por mais catico que seja a produo de software na corporao, sempre haver uma maneira de medir a sua eficincia;

Mtricas em Teste

Escolha mais de trs maneiras para medir a estabilidade do produto que ser liberado em produo: Padres de Codificao Fluxo de Falhas/Condio Estabilidade Performtica Qualidade dos Testes MNC (Mtricas No Cartesianas)

Mtricas em Teste

Em cada ciclo de testes, consegue-se coletar: As falhas por mdulos (local aonde a falha foi detectada); O progresso dos testes; A quantidade de falhas por status, severidade, testador, etc; O bugfix time; A quantidade de falhas em ambientes de pr e ps produo; A densidade de falhas ( #falhas/KLOC ) A distribuio de esforo por fases de produo; A evoluo da qualidade dos testes; A evoluo do tamanho de cada verso;

Mtricas Clssicas em Teste

So mtricas que dependem do contexto da anlise. Fatores que atrapalham a qualidade dos testes (falta de metodologia, tempo curto para execuo dos testes, documentao rudimentar, infraestrutura, etc.); Percentual de acertos do bugfix; ndice de satisfao do cliente; Evoluo dos requisitos por verso;

Mtricas No Cartesianas

Vdeo Windows Azure (Captulo 1c)

Como testar na Nuvem?

Questo

capitulo 1 - introdução testes

Documents