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