Upload
vubao
View
227
Download
0
Embed Size (px)
Citation preview
20
16
Te
stes
1 / 67
Teste de software, conceitos
2016 Testes 2 / 67
Testes em poucas palavras
“Teste somente sinaliza a presença de faltas, nunca a
sua ausência.” E.W. Dijkstra
2016 Testes 3 / 67
Testes em poucas palavras
“O planejamento de testes é governado pela
necessidade de selecionar alguns poucos casos de teste
de um gigantesco conjunto de possíveis casos. Indepen-
dentemente de quão cuidadoso você seja, você deixará
de incluir alguns casos relevantes. Independentemente
da perfeição e esmero do seu trabalho, você nunca
encontrará a última falta, e se encontrar, jamais o
saberá.” Kaner, C.; Falk, J.; Nguyen, H.Q.;
2016 Testes 4 / 67
Testes em poucas palavras
Desenvolvimento incremental:
–desenvolve 1a. versão
–testa tudo o que existe até agora
–. . .
–desenvolve i-ésimo incremento
–testa tudo o que existe até agora
–repete para o próximo incremento
–Ah! Bobagem, não desenvolvo software de forma incremental
2016 Testes 5 / 67
Testes em poucas palavras
Manutenção:
–desenvolve sistema
–testa tudo o que existe até agora (pelo menos deveria!!!)
–. . .
–desenvolve i-ésima alteração
–testa tudo o que existe até agora (pelo menos deveria!!!)
–repete para o próxima alteração
Causas de alteração: •25% correção de problemas encontrados
•05% melhorias de desempenho, interface, embelezamentos
•20% adaptação a novas leis, procedimentos, plataformas, …
•50% evolução -> mudanças na funcionalidade
2016 Testes 6 / 67
Testes em poucas palavras –Os critérios de seleção de casos de teste
•são rigorosos?
•têm por base alguma regra bem definida?
–Os casos de teste selecionados vão realmente ser realizados?
•Todos eles?
•Vão ser testadas condições especiais?
–Rede lenta?
–Demanda muito grande?
–Pré condições ilegais?
–Interrupção antes de concluir?
–Dados, comandos e protocolos (seqüências de dados / comandos) errados?
–. . .
Sempre de novo, no caso de uma alteração?
Papai Noel existe?
2016 Testes 7 / 67
Testes em poucas palavras
Quantas faltas permanecerão desconhecidas?
–1 para cada 100 linhas
–1 para cada 1.000 linhas
–1 para cada 10.000 linhas,
•a melhor estatística é 0,8 / 10.000 linhas
Por falar nisso, pode-se falar em faltas por linha de
código?
–mais de 70% são faltas de especificação!
•estas são as mais caras de se corrigir
•variações de estimativas de custo: 1 x 5 (pequena); 1 x 100 (grande); já vi 1
x 1.000
–vai daí, vamos ter que modificar o que foi desenvolvido e testado...
2016 Testes 8 / 67
Testes em poucas palavras
Errare humanum est
–nós humanos somos falíveis mesmo quando procuramos fazer o
melhor que podemos
•o software conterá faltas
•as especificações conterão faltas
•as máquinas conterão faltas
•os operadores errarão
•o software de que dependemos conterá faltas
"If a problem has no solution, it may not be a problem, but
a fact - not to be solved, but to be coped with over time." Shimon Peres
2016 Testes 9 / 67
Testes em poucas palavras –Qual é o modelo de desenvolvimento, teste e manutenção que
melhor explica o mundo real?
•o conhecimento relativo à aplicação vai aumentar continuamente?
–o processo de desenvolvimento é um processo de crescimento, no sentido
de ocupação de espaço (domínio do problema)
–quando novos patamares de conhecimento são atingidos são geradas
solicitações de evolução
•o processo de desenvolvimento é um processo de aproximações
sucessivas?
–cometem-se erros que depois são corrigidos
•o processo de desenvolvimento é um processo evolucionário (ou de
maturação), no sentido Darwiniano do termo?
–sistemas persistem caso evoluam de modo que continuem atendendo às
necessidades crescentes ou cambiantes de seus usuários
–sistema que é usado é um que satisfaz o usuário
2016 Testes 10 / 67
Princípios básicos
Teste é um experimento controlado visando a
identificação de problemas.
–como conduzir os experimentos?
–como selecionar os dados?
–como identificar os resultados esperados?
–como confrontar resultados esperados com os resultados
observados?
–como replicar os experimentos?
•durante e após alterações
•durante e após evoluções ou incrementos
–como replicar, a partir dos relatos, as falhas ocorridas em
produção?
2016 Testes 11 / 67
Princípios básicos
–Para cada caso de teste é necessário comparar-se os resultados
obtidos com os resultados esperados
•oráculo: resultado esperado é calculado a partir da especificação usando
os dados selecionados para o caso de teste
•inversa: comparação pode ser indireta, exemplos
–[M]*[M]-1=[1]
–guarda espaço ocupado antes, [{insere , exclui}]* => mesmo espaço
ocupado que antes
•assertiva: o resultado obtido precisa satisfazer um conjunto de assertivas
•visual: o resultado obtido é examinado pelo testador para ver se está
satisfatório
–Deve ser registrada uma falha se forem diferentes em mais do
que o tolerado
•tolerância => vírgula flutuante
2016 Testes 12 / 67
Princípios básicos
Testes são
–caros e demorados
–pouco eficientes
•encontram poucas falhas a cada execução
–pouco eficazes
•estatísticas mostram que de maneira geral encontram somente cerca de
65% de todos os problemas identificados
–decorrente dos testes terem sido mal feitos?
–ou é uma propriedade intrínseca?
–devem ser projetados cuidadosamente
•visando assegurar eficiência e eficácia
2016 Testes 13 / 67
Princípios básicos Se desenvolvemos módulos (programas, sistemas) corretos por
construção, por que testar?
–Nenhuma técnica de controle da qualidade assegura que um artefato
nunca gerará problemas.
–Técnicas
•inspeção
•teste
•argumentação
•prova formal
•certificação
–Modos
•verificação
•validação
•aprovação
It takes more time than you have to prove less than you would like.
2016 Testes 14 / 67
Princípios básicos Atitude destrutiva ao testar
O objetivo do teste é encontrar problemas relevantes –um teste que encontrou um problema, valeu a pena
•depois de eliminar o problema temos que retestar o artefato e esperamos não encontrar outros problemas relacionados ou decorrentes do que foi eliminado
–um teste que não encontrou um problema foi perda de tempo
•bem, não sejamos tão radicais!
•você tem certeza que não vai encontrar problemas? Tem como demonstrar isso cabalmente?
•melhor: um teste que não encontrou problema acrescenta muito pouca informação, já se encontrou problema, acrescenta muita
–Gerhart, S.L.; Yelowitz, L.; "Observations of fallibility in applications of modern programming methodologies"; IEEE Transactions on Software Engineering 2(9); Los Alamitos, CA: IEEE Computer Society; 1976; pags 195-207
2016 Testes 15 / 67
Princípios básicos
O objetivo de encontrar problemas é poder removê-los
de forma completa
–é a remoção da falta que gerou o problema que constitui a
melhoria da qualidade
Precisamos de um laudo adequado e que ajude a
responder:
–como replicar a falha?
–o que ocorreu e o que deveria ter acontecido?
–onde ocorreu?
–qual a causa real?
–como sei que foi removida completamente?
–quais os testes que não foram capazes de identificar a existência
do problema?
2016 Testes 16 / 67
Conceito chave: caso de teste
Texto associado a um requisito a ser testado, que
descreve:
–pré-condições de execução
–passos específicos do teste a ser executado
–resultados esperados e/ou pós-condições de execução
CRITÉRIO DE
SUCESSO:
Sistema realiza
upload em menos de
30 seg.
POS-CONDICOES:
Um link para o
Resumo submetido é
mostrado na tela de
Upload.
PRE-CONDICOES:
Usuário está cadas-
trado no sistema e
usuário fez login no
sistema
DESCRIÇÃO: Para fazer o Upload do Resumo o usuário deve
clicar...
IDENTIFICADOR DO CASO DE TESTE: RF012
2016 Testes 17 / 67
O que é um teste?
–O teste é realizado através de uma série de casos de
teste
•a massa de teste é o conjunto de casos de teste
–A confiabilidade do teste depende do critério de
seleção dos casos de teste
–Existem diversos critérios de seleção de casos de teste
•cada um tem um domínio de efetividade
2016 Testes 18 / 67
O que é um teste?
Controvérsia
–gerar um número grande de pequenos casos de teste?
–gerar um número pequeno de grandes casos de teste?
2016 Testes 19 / 67
Critério básico
Ao testar um módulo ou componente deve-se verificar
–para cada item da interface
•função: se este item se comporta conforme especificado
•dado global: se este item contém valores conforme especificado
–considerando as diversas categorias de estados que podem ser
assumidos pelo artefato
São quantos testes?
2016 Testes 20 / 67
Critério básico
–São itens da interface:
•funções globais exportadas
•dados globais exportados
•métodos públicos (protegidos?)
•dados públicos (protegidos?)
•arquivos criados, alterados, lidos
•interfaces com o usuário exibidas e obtidas
–comandos nas diversas réguas
–dados fornecidos pelo usuário
–mensagens enviadas ao usuário
–resultados apresentados ao usuário
–diálogos, menus, . . .
2016 Testes 21 / 67
Critério de seleção
É um método de escolha de casos de teste
–se obedecido gera um conjunto de casos de teste capaz de
identificar falhas causadas por uma determinada classe de faltas
Um critério de seleção de casos de teste deve ser
–válido:
•acusa falhas sempre que existam faltas no artefato sendo testado
–confiável:
•as falhas encontradas são indiferentes à escolha dos dados e das ações
desde que satisfaçam as condições dos casos de teste
–completo:
•segundo um padrão de completeza
2016 Testes 22 / 67
Processo de seleção
2016 Testes 23 / 67
Exemplo de estrutura
2016 Testes 24 / 67
Exemplo de modelo físico
2016 Testes 25 / 67
Exemplo de interface typedef enum {
ARV_CondRetOK = 0 ,
ARV_CondRetNaoCriouRaiz = 1 ,
ARV_CondRetErroEstrutura = 2 ,
ARV_CondRetNaoEhFolha = 3 ,
ARV_CondRetArvoreNaoExiste = 4 ,
ARV_CondRetArvoreVazia = 5 ,
ARV_CondRetNohEhRaiz = 6 ,
ARV_CondRetNaoPossuiFilho = 7 ,
ARV_CondRetFaltouMemoria = 8
} ARV_tpCondRet ;
ARV_tpCondRet ARV_CriarArvore( void ** refArvore ) ;
void ARV_DestruirArvore( void ** refArvore ) ;
ARV_tpCondRet ARV_InserirEsquerda( void * refArvore , char * ValorParm ) ;
ARV_tpCondRet ARV_InserirDireita( void * refArvore , char * ValorParm ) ;
ARV_tpCondRet ARV_ObterValor( void * refArvore , char ** ValorParm ) ;
ARV_tpCondRet ARV_IrPai( void * refArvore ) ;
ARV_tpCondRet ARV_IrNoEsquerda( void * refArvore ) ;
ARV_tpCondRet ARV_IrNoDireita( void * refArvore ) ;
2016 Testes 26 / 67
Casos abstratos
2016 Testes 27 / 67
Casos semânticos
== Árvore inexistente
== Árvore vazia
== Árvore com raiz somente
== Destruição da raiz
== Raiz com um filho à esquerda somente
== Destruição de filho à esquerda
== Raiz com um filho à direita somente
== Destruição de filho à direita
== Raiz com dois filhos somente
== Destruição dos dois filhos
. . .
2016 Testes 28 / 67
Casos valorados + esperados
== Árvore inexistente
=IrDireita NaoExisteArvore
== Árvore vazia
=CriarArvore
=IrDireita ArvoreVazia
== Árvore com raiz somente, raiz == a
=InserirDireita a OK
=ObterValor a OK
=IrDireita NaoPossuiFilhoDireita
=IrEsquerda NaoPossuiFilhoEsquerda
=IrPai NaoPossuiPai
== . . .
2016 Testes 29 / 67
Processo de teste
2016 Testes 30 / 67
Relato de falhas –The point of testing is to find bugs.
–Bug reports are your primary work product. This is what people
outside of the testing group will most notice and most remember of
your work.
–The best tester isn’t the one who finds the most bugs or who
embarrasses the most programmers. The best tester is the one who
gets the most bugs fixed.
–Programmers operate under time constraints and competing
priorities. For example, outside of the 8-hour workday, some
programmers prefer sleeping and watching Star Wars to fixing bugs.
–A bug report is a tool that you use to sell the programmer on the
idea of spending his o her time and energy to fix a bug.
–Kaner, C.; Bug Advocacy: How to Win Friends and Stomp BUGs; 2000; Buscado em: 2003; URL:
www.kaner.com
2016 Testes 31 / 67
Tipos de teste Teste de unidade
–Teste independente de uma unidade
•componente, módulo, classe, função?
–Foco: exame minucioso do código e da interface disponibilizada pela
unidade
–Exemplos de unidades
•classes
•widgets
•agentes
•páginas Web
•módulos
•componentes
•applets
•servlets
•aglets
2016 Testes 32 / 67
Tipos de teste
Teste de integração
–Testa a composição de unidades previamente testadas.
–Foco 1: exame minucioso do uso das interfaces entre os
componentes integrados
•parâmetros
•variáveis globais
•mensagens
•estados
–corotinas
•sincronização
•protocolos
•recuperação (roll back)
–Foco 2: testar o composto como se fosse uma unidade
2016 Testes 33 / 67
Tipos de teste –teste da corretude procura encontrar diferenças entre o
especificado e o implementado
–teste da interface (funcional) verifica se a interface do componente
ou módulo permite a construção de programas que utilizem estes
artefatos sem requerer quaisquer alterações, adaptações ou
interfaces de conversão (wrappers)
–teste da adequação verifica se o construto resolve os problemas
que o usuário espera ver resolvidos
–teste da utilizabilidade (interface humana) verifica se o construto é
fácil de usar e de aprender a utilizar
2016 Testes 34 / 67
Tipos de teste –teste da robustez verifica se o construto resiste a agressões
intencionais ou fortuitas
•“fail safe”, “graceful degradation”
–teste da segurança procura encontrar brechas de segurança que
permitam pessoas azaradas ou mal intencionadas a causar danos
–teste de invasão similar a teste de segurança, mas praticado para
invadir mesmo, usando uma postura de hacker
•“pen test”
2016 Testes 35 / 67
Tipos de teste –teste da instalação verifica se o programa de instalação opera
corretamente
–teste da implantação verifica se o construto pode ser colocado em
correto funcionamento nas plataformas do usuário.
–teste da capacidade verifica se o construto é capaz de atender à
demanda esperada
–teste de exaustão (“stress test”) procura determinar os limites de
capacidade a partir dos quais o programa entra em colapso por
excesso de demanda, verifica também o comportamento quando
recursos exaurirem (ex. falta memória, ultrapassa o volume)
–teste de longa vida verifica se o construto pode ser utilizado
intensivamente por longos períodos (ex. 24 x 7) sem se deteriorar
2016 Testes 36 / 67
Tipos de teste –Teste de desempenho
–Teste de escalabilidade
–Teste de compatibilidade com outros sistemas
–Teste de conversão
–Teste da documentação
–Teste do backup
–Teste da recuperação
–Teste do macaco :)
–. . .
2016 Testes 37 / 67
Modos de teste Teste funcional
–teste caixa preta
–teste de aceitação
Teste estrutural
–teste caixa branca
–teste caixa cinza
Teste de regressão
Teste de desempenho
Teste de integridade
Teste de liberação
2016 Testes 38 / 67
Teste exploratório
É uma maneira de aprender a utilizar um novo sistema
através do uso
–cenários
–casos de uso
–transações
Realizado com essa intenção na realidade não é um
teste
2016 Testes 39 / 67
Rapid testing
Uma forma de teste exploratório
–especificação inexistente ou não confiável
Missão
–encontrar os principais problemas rapidamente
Capacitação
–testador em geral tem experiência e conhece a aplicação, sabe
então onde mais provavelmente se encontram os problemas
Risco
–não é um teste sistemático, portanto não serve como indicador da
qualidade do artefato
Colaboração
–procure usar pair testing
Não serve para atestar qualidade
2016 Testes 40 / 67
Teste ao utilizar
Foco
–na utilidade
•preciso disso?
•resolve de fato o meu problema?
•completamente?
–na utilizabilidade
•sem entraves
•ágil
•fácil de aprender a usar corretamente
•aspecto “bonito”
–no processo de trabalho do usuário
•dados precisam estar disponíveis na ordem que o usuário deseja e não na
ordem que o sistema espera
2016 Testes 41 / 67
Teste ao documentar
Ao redigir a documentação ou o help
–verificar se o documento corresponde exatamente a o que o
programa efetivamente faz
–ajustar um dos dois, ou ambos, caso haja discrepância
–melhor ainda: sempre que possível fazer a documentação exercitar
o artefato
–exatamente quer dizer: nem mais, nem menos
2016 Testes 42 / 67
Depuração
2016 Testes 43 / 67
Plano de teste Identificação dos produtos do teste a serem entregues (deliverables)
–histórico de problemas registrados
•falhas, adaptações, evoluções, melhorias
–o próprio plano de teste
–projeto dos casos de teste
•objetivos específicos do teste
•evidência que os objetivos foram alcançados
•ex. cenários de teste
•ex. método de seleção utilizados
•ex. diagramas de cause e efeito
–massas de teste
–logs de execução dos casos de teste
–relatórios de medição
–relatórios de falhas (laudo)
–relatório resumido
AQUI
2016 Testes 44 / 67
Plano de teste Introdução
–foco nos objetivos que motivaram o desenvolvimento
•melhoria da imagem
•redução de falhas operacionais
•aceleração do processo
•maior acuidade dos resultados
Definição dos requisitos de alto nível
–ex. sistema de registro e acompanhamento
–ex. sistema usando GUI
Identificação dos tipos de teste
–onde será utilizado o teste manual
–onde será utilizado o teste automatizado
–como será realizado o teste automatizado
2016 Testes 45 / 67
Plano de teste Identificação dos critérios de conclusão dos testes
–ex. falhas por determinada unidade de tempo abaixo de X
–ex. esgotamento de recursos para o teste
–ex. todos testes automatizados são baseados em critérios de seleção
rigorosos e concluem corretamente
Estratégia de teste de regressão
–quais os testes que serão efetuados de novo
–matriz de reteste
–make de reteste
2016 Testes 46 / 67
Plano de teste Organização da equipe de teste
–nível das pessoas
–habilitações, treinamento
–papéis, responsabilidades
–quem são as pessoas e quais os papéis que desempenham
Ambiente de teste
–espaço físico para o trabalho
–equipamentos
–ferramentas
–tecnologias
–material de apoio, treinamento
2016 Testes 47 / 67
Plano de teste Identificação das precedências
•código
•projeto
•componentes precedentes
•disponibilidade de pessoas
•disponibilidade de ferramentas
Cronograma de teste
•coleta de informações
•planejamento
•projeto dos roteiros de teste
•desenvolvimento dos casos de teste
•execução dos testes
•integração
•teste de sistema
•teste de aceitação
•produção do resumo
2016 Testes 48 / 67
Plano de teste Ferramentas de apoio aos testes
–quais são, inclusive a versão
–onde estão
–material de treinamento
Gerência de configuração
–inicialização, e.g. solicitação de alteração
–avaliação técnica
–avaliação do impacto sobre o negócio
–avaliação do impacto sobre a gestão do desenvolvimento
–acompanhamento dos testes
–procedimento de instalação ou divulgação
2016 Testes 49 / 67
Plano de teste Sistema de registro e acompanhamento de problemas
–especialmente voltado para a etapa de teste
Procedimentos de composição de construto versionado
–ferramenta de controle de versão utilizada
Processo de decisão com relação a problemas registrados
–máquina de estados de evolução de uma FAP amarrada às ferramentas
Procedimentos de relato
–evolução do estado de progresso dos testes
–resumos dos testes
Procedimentos de aprovação
–quem aprova o que
–para cada produto do teste (deliverable)
2016 Testes 50 / 67
Plano de teste Métricas a serem coletadas (GQM)
–objetivos da medição
•ex. reduzir o número de falhas em programas entregues
•ex. reduzir o esforço gasto em retrabalho desnecessário
–quais as perguntas que se relacionam com os objetivos
•ex. quantas falhas por dimensão x complexidade percebida foram detectadas em
produtos já entregues
•ex. quanto tempo é gasto em alteração de artefatos já desenvolvidos
•ex. qual o percentual deste tempo que seria desnecessário caso fossem adotados
princípios mais eficazes
–medições a realizar
•número de falhas reportadas após a aceitação
•dimensão do artefato
•complexidade percebida
Não meça só para colecionar medições!
Meça para identificar ou resolver um problema.
2016 Testes 51 / 67
Plano de teste Exemplos de métricas
–natureza das causas de falhas
–distribuição das causas no tempo
–modos de observação das falhas
•ex. teste
•ex. uso
–classe das falhas, ex. desastre, grave, normal, aborrecimento
–distribuição de falhas por artefato
–tempo para eliminar completamente o problema
–esforço para eliminar completamente o problema
–volume de automação dos testes
–distribuição do esforço para diagnosticar problemas encontrados
–distribuição de uso dos recursos de apoio aos testes
–cobertura de código
–cobertura de seqüências de ativação
2016 Testes 52 / 67
Projeto de teste,
diagrama de transição
2016 Testes 53 / 67
Projeto de casos de teste story function input current
memoryoutput updated
memorychange risk
1 click (cus-tomer)
click customerbutton
new customerscreen
low
1 enter( cus-tomer)
customer de-tails entered
current cus-tomer data-base
confirmationdetails screen
- medium (na-ture of detailsliable tochange)
1 confirm( cus-tomer)
customer con-firm buttonclicked
current cus-tomer data-base
OK messageand startscreen button
updated cus-tomerdatabase
low
3 click( order) orders buttonclicked
- new ordersscreen
- low
3 enter( order) new orderdetails en-tered
current ordersdatabase
confirmationorders screen
high (nature ofdetails of or-ders liable tochange)
3 confirm( or-der)
orders confirmbutton clicked
current ordersdatabase
Ok messageand startscreen button
updated or-ders database
low
3 quit() click on returnto start button
- start screen - low
2016 Testes 54 / 67
Projeto dos testes
Cada item de menu deve ser testado
–diagrama estado transição
•estados são condições estáticas
•transição são comandos, seleções, mensagens
•transições condicionais devem ser examinadas quanto à sua exibição
•cada caso de check box deve ser tratado
•list boxes devem ser tratados para 0, 1, 3 ou mais itens
2016 Testes 55 / 67
Projeto dos testes
Cada diálogo deve ser testado
–diagrama estado transição
•estados são condições estáticas
•transição são comandos, seleções, mensagens
•transições condicionais devem ser examinadas quanto à sua exibição
–testes típicos
•cada caso de check box deve ser tratado
•list boxes devem ser tratados para 0, 1 e 3 (ou mais) itens
•verificar a corretude dos controladores de integridade dos dados
•verificar a corretude de campos inicializados
•verificar a corretude de campos calculados
•verificar a compreensibilidade do diálogo
•verificar a agregação dos elementos
2016 Testes 56 / 67
Teste de programas OO
Teste em aplicações desenvolvidas usando OO
requerem muito esforço
–herança e amarração dinâmica são fontes de muitas falhas
–o elevado volume (número de itens) e a complexidade das
interfaces contribuem para dificultar os testes
–a esperada redução do esforço de teste devido ao reúso em
sistemas OO tem-se mostrado ilusória [Binder 1996]
–na realidade OO introduz muitas questões conduzindo a técnicas
de teste mais abrangentes e elaboradas
2016 Testes 57 / 67
Teste aplicações Web Verifique a corretude dos instaladores
–todas as variáveis de ambientes e registry estão corretamente inicializadas
–examinar para cada variável de ambiente ou condição do ambiente (ex.
ODBC)
Verifique se as mensagens de erro informam corretamente o
problema observado
–devem ser evitados códigos tipo Ox81234
Verifique se o sistema operacional cliente, versão e service packs,
estão corretos
Verifique se a versão do browser instalada é a correta
Verifique se o browser está completamente instalado (e.g.
interpretador JavaScript, Java Applets)
. . .
2016 Testes 58 / 67
Teste aplicações Web Verifique os parâmetros do browser
Verifique o comportamento com vários browsers
Verifique o comportamento com várias versões de um browser
Verifique o comportamento com vários tipos de periféricos
Verifique se todos os servidores estão operando
Verifique se todos os serviços requeridos estão operando
2016 Testes 59 / 67
Teste aplicações Web Verifique os privilégios de acesso
Verifique completeza e corretude da versão de componentes, ex.
DLL
Verifique correto registro de componentes (COM, Java)
Verifique a corretude do DNS
Verifique a adequação da proteção estabelecida pelo firewall
Verifique problemas causados por linhas de transmissão lentas
Verifique a corretude dos processos executados em diferentes
máquinas
2016 Testes 60 / 67
Teste aplicações Web Verifique as conseqüências de máquina servidora temporariamente
desconectada ou inoperante
Verifique versão e service packs dos sistemas operacionais dos
servidores
Verifique versão e service packs dos componentes servidores
Verifique a corretude dos parâmetros dos servidores
2016 Testes 61 / 67
Manutenção
Causas para a manutenção
–Melhoria (evolutiva)
•modifica a funcionalidade do artefato
•50%
–Perfectiva
•remove deficiências
•5%
–Adaptativa
•modifica o artefato sem afetar a sua funcionalidade
•20%
–Corretiva
•remove faltas
•25%
2016 Testes 62 / 67
Manutenção
Ações de manutenção
–adiciona artefato
–exclui artefato
–adiciona, altera, exclui elementos de artefato
•declaração e manipulação (acesso) de dados
•lógica e estrutura (refactoring?)
•processamento (cálculo, fórmulas)
•inicialização
•interface humano-computador
•interface de módulo
•documentação papel
•documentação help
•documentação tutoriais
•outros
2016 Testes 63 / 67
Níveis das propriedades
Nível Freqüência Risco Prioridade
0 Nunca Não tem Nenhuma
1 Muito raro Muito baixo Muito baixa
2 Raro Baixo Baixa
3 Algumas vezes Médio Média
4 Freqüente Alto Alta
5 Muito freqüente Muito alto Muito alta
2016 Testes 64 / 67
Manutenção
Severidade do problema
–desastre
•provoca a quebra de equipamento, morte,
•destrói dados persistentes irrecuperáveis
•causa falhas graves em outros sistemas
–problema grave
•o resultado compromete o uso do artefato
•as funcionalidades afetadas são imprescindíveis
–problema
•o resultado compromete o uso do artefato
•as funcionalidades afetadas não são imprescindíveis
–podem ser temporariamente desativadas
–o problema pode ser contornado
–inconveniência
•o resultado não compromete o uso do artefato
2016 Testes 65 / 67
Bibliografia 1 –Holcombe, M.; Bogdanov, K.; Gheorghe, M.; "Functional Test Generation
for Extreme Programming"; Proceedings of the XP2001 Second
International Conference on Extreme Programming and Flexible Processes
in Software Engineering, Sardinia, Italy, 2001; pags 109-113; Buscado em:
19/08/2004; URL: http://www.dcs.shef.ac.uk/~wmlh/XPtest.pdf
–Kaner, C.; Falk, J.; Nguyen, H.Q.; Testing Computer Software;
International Thompson Computer Press; 1993
–Kaner, C.; Bug Advocacy: How to Win Friends and Stomp BUGs; 2000;
www.kaner.com (testing website) www.badsoftware.com (legal website)
–Kemerer, C.F.; Slaugther, S.; “An Empirical Approach to Studying Software
Evolution”; IEEE Transactions on Software Engineering 28(4); 1999; pags
493-509
–Lewis, W.E.; Software Testing and Continuous Quality Improvement; Boca
Raton: Auerbach; 2000
2016 Testes 66 / 67
Bibliografia 2 –Nguyen, H.Q.; “Testing Web-based Applications”; Software Testing &
Quality Engineering; 2000; pags 23-29; www.stqemagazine.com;
–Rätzmann, M.; Young, C.d.; Software Testing and Internationalization; Salt
Lake City, Utah: Lemoine International; 2003; Buscado em: 09/2003; URL:
www.lemoine-international.com
–Whittaker, J.A.; “What is software testing? And why is it so hard?”; IEEE
Software 17(1); Jan 2000; pags 70-79