Upload
malkadark
View
44
Download
0
Embed Size (px)
Citation preview
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
Incio
Processo de Software
Processo de Software
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.
Nveis de Maturidade de Teste Nvel 1
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
Nveis de Maturidade de Teste Nvel 2
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
Nveis de Maturidade de Teste Nvel 3
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.
Nveis de Maturidade de Teste Nvel 4
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
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