2016
Testes
Teste de software, conceitos
1/
67
Testes em poucas palavras
“Teste somente sinaliza a presença de faltas, nunca a
sua ausência.”
E.W. Dijkstra
2016
Testes
2 / 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. Independentemente 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
3 / 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
4 / 67
Testes em poucas palavras
Manutenção:
–desenvolve sistema
–testa tudo o que existe até agora
–. . .
–desenvolve i-ésima alteração
–testa tudo o que existe até agora
–repete para o próxima alteração
(pelo menos deveria!!!)
(pelo menos deveria!!!)
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
5 / 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
6 / 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
7 / 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
8 / 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
9 / 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
10 / 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
11 / 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
12 / 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
13 / 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
14 / 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
15 / 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
IDENTIFICADOR DO CASO DE TESTE: RF012
DESCRIÇÃO: Para fazer o Upload do Resumo o usuário deve
clicar...
PRE-CONDICOES:
Usuário está cadastrado no sistema e
usuário fez login no
sistema
2016
POS-CONDICOES:
Um link para o
Resumo submetido é
mostrado na tela de
Upload.
Testes
CRITÉRIO DE
SUCESSO:
Sistema realiza
upload em menos de
30 seg.
16 / 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
17 / 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
18 / 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
19 / 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
20 / 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
21 / 67
Processo de seleção
2016
Testes
22 / 67
Exemplo de estrutura
2016
Testes
23 / 67
Exemplo de modelo físico
2016
Testes
24 / 67
Exemplo de interface
typedef enum {
ARV_CondRetOK
ARV_CondRetNaoCriouRaiz
ARV_CondRetErroEstrutura
ARV_CondRetNaoEhFolha
ARV_CondRetArvoreNaoExiste
ARV_CondRetArvoreVazia
ARV_CondRetNohEhRaiz
ARV_CondRetNaoPossuiFilho
ARV_CondRetFaltouMemoria
} ARV_tpCondRet ;
=0,
=1,
=2,
=3,
=4,
=5,
=6,
=7,
=8
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
25 / 67
Casos abstratos
2016
Testes
26 / 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
27 / 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
28 / 67
Processo de teste
2016
Testes
29 / 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
30 / 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
31 / 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
32 / 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
33 / 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
34 / 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
35 / 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
36 / 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
37 / 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
38 / 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
39 / 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
40 / 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
41 / 67
Depuração
2016
Testes
42 / 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
AQUI
–massas de teste
–logs de execução dos casos de teste
–relatórios de medição
–relatórios de falhas (laudo)
–relatório resumido
2016
Testes
43 / 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
44 / 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
45 / 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
46 / 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
47 / 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
48 / 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
49 / 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
50 / 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
51 / 67
Projeto de teste,
diagrama de transição
2016
Testes
52 / 67
Projeto de casos de teste
story
function
input
current
memory
output
updated
memory
1
click (customer)
click customer
button
1
enter( customer)
customer details entered
current customer database
confirmation
details screen
-
1
confirm( customer)
customer confirm button
clicked
current customer database
OK message
and start
screen button
updated customer
database
3
click( order)
orders button
clicked
-
new orders
screen
-
3
enter( order)
new order
details entered
current orders
database
confirmation
orders screen
3
confirm( order)
orders confirm
button clicked
current orders
database
Ok message
and start
screen button
updated orders database
3
quit()
click on return to start button
start screen
-
2016
new customer
screen
Testes
change risk
low
medium (nature of details
liable to
change)
low
low
high (nature of
details of orders liable to
change)
low
low
53 / 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
54 / 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
55 / 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
56 / 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
57 / 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
58 / 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
59 / 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
60 / 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
61 / 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
62 / 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
63 / 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
64 / 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
65 / 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
2016
Testes
66 / 67