Parte 2 - CCT0077 - Testes de SW - Uma visão

Prévia do material em texto

TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 1 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
CCT0077 – PDS 
Testes de SW 
- Uma visão geral - 
 
 
Autor: José Geraldo Silva 
 
 
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 2 
 
 
 
 
1 - INTRODUÇÃO 
 
1.1 - Motivação para testes 
 
SOFTWARE: Provedor necessário para desenvolvimento e operacionalização de 
um produto (programa/sistema) num ambiente computacional. 
 
CVSW = { CDSW + CPSW } 
 
CVSW : Ciclo de Vida do Software ; 
CDSW : Ciclo de Desenvolvimento do Software 
CPSW : Ciclo de Produção do Software 
 
Software = [ Básico / Aplicativo ] 
Software Básico = [ Sistema Operacional / Linguagem de Programação / SGBD / 
Sw de Rede / etc ] 
Software Aplicativo = [Software Produto/Software Aplicação] 
Software Produto = [ Editor/Planilha/Apresentação/etc] 
Software Aplicação = [ Sistema Comercial qualquer] 
 
Normalmente , se o CVSW = 10 T , o CDSW = 2T e o CPSW = 8T. 
 
As fases do CDSW são : Definição / Análise / Projeto / Construção / Testes 
 do CPSW é : Manutenção 
 
 
 % Dedicação 
 
 
 
 
 
 
 
 
 
 
 
 
 
 D A P C T Mnt (CVSW-Ciclo de Vida do SW) 
 
 
D = 5%, A = 10%, P = 15%, C = 20%, T = 2% Mnt = 48% 
 
 
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 3 
 
USUÁRIO/CLIENTE
TESTE DE INSTALAÇÃO
TESTE DE ACEITAÇÃO
TESTE DE SISTEMA
(*)
TESTE FUNCIONAL
TESTE DE INTEGRAÇÃO
TESTE DE MÓDULO
IMPLANTAÇÃO
ESTRUTURA DOS TESTES
P.C.
P.C.
P.C.
P.C.
P.C.
I
M
P
L
E
M
E
N
T
A
Ç
Ã
O
- VISÃO GERAL
REQUISITOS/
OBJETIVOS
ESPECIFICAÇÃO
LÓGICA /
CONCEITUAL
ESPECIFICAÇÃO
FÍSICA
PROJETO DE 
PROGRAMA 
ESPECIFICAÇÕES
DOS INTERFACES
DE MÓDULOS
CÓDIGO GERADO
P.C.
F1
F2
F3
F4
F5
(PRODUÇÃO/SUPORTE)
(USUÁRIO/CLIENTE)
(ANALISTA/USUÁRIO)
(ANALISTA)
(ANALISTA/PROJETISTA)
(PROGRAMADOR)
P.C. = Ponto de Controle
(tstswjg.ppt)
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 4 
 
 
 
PROPÓSITOS DOS TESTES 
 
A) TESTE DE MÓDULO E DE INTEGRAÇÃO 
 
Encontrar discrepâncias entre os módulos / programas e suas especificações de 
interface. 
 
B) TESTE FUNCIONAL 
 
Verificar se o sistema (software) atende às especificações de suas funções. 
 
C) TESTE DE SISTEMA 
 
Mostrar que o produto final é (ou não) consistente com os seus OBJETIVOS iniciais. 
Compreende verificar se há discrepâncias entre os conjuntos integrados dos TESTES 
das funções, à luz das especificações Lógica/Conceitual versus os OBJETIVOS 
estabelecidos. 
 
D) TESTE DE ACEITAÇÃO 
 
Comparar o sistema aos seus REQUISITOS iniciais e às necessidades atuais de seus 
usuários finais. 
 
E) TESTE DE INSTALAÇÃO 
 
Mostrar que o sistema (sw) é (ou não) adequado ao ambiente operacional. 
Seu objetivo não é o de encontrar erros de software, e sim de instalação, ou seja, onde 
o sw será instalado. 
 
Exemplos de problemas de instalação: 
 
 - Todos os arquivos de biblioteca estão carregados? 
 - Todas as tabelas foram criadas? 
 - Configuração de hardware é válida e adequada? 
 - Todos os programas estão devidamente interconectados? 
 - etc. 
 
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 5 
 
 
 
2 - TESTES E SEU SIGNIFICADO 
 
Perguntas chaves : 
 
 - “O que é” TESTAR? 
 - “Por quê” TESTAR? 
 - “Quando” (começar a) TESTAR? 
 - “Quem” deve realizar os TESTES? 
 - “Quais”os tipos de TESTES? 
 - “O que é”um bom TESTE de Sw? 
 - “Como”determinar objetivos e critérios de teste”? 
 - “Como”desenvolver e validar um Plano de TESTES? 
 - “Como” selecionar e preparar Casos de TESTES? 
 - “Onde”os TESTES são excessivos ou insuficientes? 
 - “Como”e “Quando” usar métodos e téscnicas de TESTES? 
 - “O que” TESTAR depois de alterações / manutenções / aperfeiçoamentos? 
 - “Como”avaliar o suceso de um TESTE? 
 
TESTAR: “É submeter o produto (SW) a todas as exigências do seu projeto, sob 
condições críticas de operação e desempenho”. 
 
 
 
 
 
FINALIDADES DOS TESTES 
 
 Adquirir confiança no fato que um sistema pode ser usado com uma margem 
de risco aceitável 
 Fornecer informações que impeçam o surgimento de erros 
 Fornecer informações que auxiliem a deteção de erros antes dos mesmos se 
manifestarem 
 Descobrir erros e deficiências de um SW 
 Determinar quais as limitações / recursos de um SW 
 Fornecer informações sobre a qualidade do SW 
 
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 6 
 
 
FATORES DE QUALIDADE DO SW 
 
 
 
 A B 
 
 
 C 
 
 
A - Fatores Intrínsecos (Revisão) 
São aqueles que tem a ver com a parte de engenharia de construção do SW. 
“Coisas”embutidas no próprio Sw. 
 
B - Fatores extrínsecos ( Operação) 
São aqueles que tem a ver com os aspectos de funcionamento do SW. As 
exigências vem externamente. 
 
C - Fatores de Adaptabilidade (Transição) 
São aqueles relativos aos aspectos de condicionamento do SW às 
exigências tecnológicas. 
 
A - FATORES INTRÍNSECOS 
 
 Testabilidade, Manutenibilidade, Flexibilidade. 
 
B - FATORES EXTRÍNSECOS 
 
 Correção, Confiabilidade, Eficiência, Integridade, Usabilidade. 
 
C - FATORES DE ADAPTABILIDADE 
 
 Portabilidade, Reusabilidade, Interoperabilidade. 
 
 
A - FATORES INTRÍNSECOS 
 
. TESTABILIDADE 
 É o esforço exigido para testar o produto. 
 
. MANUTENIBILIDADE 
 É o esforço exigido para localizar e corrigir um erro. 
 
. FLEXIBILIDADE 
 É o esforço exigido para executar as modificações do Sw. 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 7 
 
 
 B - FATORES EXTRÍNSECOS 
 
. CORREÇÃO 
É o grau de atendimento às especificações e aos objetivos do projeto do 
Sw, até o ponto onde ele esteja isento de erros, ou seja, quando o Sw 
atende às necessidades do usuário. 
. CONFIABILIDADE 
É a precisão com que o software executa suas funções. 
. EFICIÊNCIA 
É o grau de suficiência de recursos computacionais necessários para que 
o software execute a função. 
. INTEGRIDADE 
 É o grau de segurança que o sw deve possuir. 
. USABILIDADE 
 É o esforço que é requerido para operar e usar o sw. 
 
C - FATORES DE ADAPTABILIDADE 
 
 Quando um Software é considerado adaptável? 
 
 - Quando ele é capaz de ajustar-se às alterações do ambiente. 
 
. PORTABILIDADE 
É o esforço exigido para transferir um software de uma plataforma para 
outra. 
 
Exemplo: 
 
CASO HW BASE DE DADOS LINGUAGEM PORTABILIDADE 
1 IBM VSAM (Seq.Ind.) COBOL Pequena 
 VAX RDB (random) COBOL 
2 IBM ADABAS NATURAL Grande 
 VAX ADABAS NATURAL 
 
. INTEROPERABILIDADE 
 
 É o esforço exigido para interligar um sistema (ou Sw) a outro. 
 
** Para melhorcompreensão, veja o ANEXO no final da apostila ** 
 
. REUSABILIDADE” 
 
É a capacidade do software (programa, instrução, conjunto de instruções, 
rotinas, etc) ser utilizado por outro Sw. 
Exemplo: 
 Teste do CPF em vários cadastros 
 Teste de valor por extenso 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 8 
 
 
FATORES DE QUALIDADE SUPLEMENTARES 
 
A) ESTABILIDADE 
Esforço exigido para tornar o Sw tolerante a variações do ambiente, sem 
alterar a sua funcionalidade, no sentido de seu funcionamento/ operação. 
 
Exemplos: 
1. Troca de versões do Sistema Operacional; 
2. Rotinas articuladoras independentes que irào fazer acoplamento entre 
sistemas distintos, ou partes de sistemas; 
3. Sistemas parametrizados com extensivo uso de tabelas, que suportem 
alterações de modo transparente. 
 
+++ Analogia com outras atividades: 
 
1 - Construção Civil 
1.1. Um edificio de 50 andares que possui tolerância a abalos sísmicos; 
1.2. Ponte Rio-Niterói (Balança, e como!) 
2 - Indústria Aeronáutica : Asa de avião! 
 
 
B) ACESSIBILIDADE 
 
É a característica de clareza de ser acessível, isto é, de se “investigar”sua 
estrutura interna. OBS. : As famosas caixas-pretas estimulam a 
insegurança e as dúvidas quanto à qualidade; Produtos de Sw herméticos 
(fechados) provocam baixa confiabilidade e exigem exaustivos testes 
adicionais. 
 
Exemplo de uma Planilha de Avaliação de Software no Apêndice - anexo 1 : 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 9 
 
 
 
GARANTIA DE QUALIDADE DE SOFTWARE (GQS) 
 
Compreende uma variedade de tarefas relacionadas com 7 (sete) atividades 
principais: 
 
 
1 - Utilização de métodos e ferramentas; 
2 - Realização de revisões formais; 
3 - Testes do Software; 
4 - Fixação de padrões; 
5 - Controle de mudanças; 
6 - Medição/ Aferição; 
7 - Coleta e disseminação de dados sobre qualidade. 
 
CUSTO DE QUALIDADE DE SOFTWARE 
 
Alguns conceitos: 
 
a) DEFEITO : 
 
É um desvio entre o resultado esperado ou desejado (RE ou RD) e o resultado 
obtido (RO). 
 
O DEFEITO é obtido pela fórmula: D = RD - RO 
 Se D = 0 ; então a qualidade é total (100% de qualidade) 
 D > 0 ; então a qualidade (acima/abaixo) do esperado 
 D < 0 ; então a qualidade (acima/abaixo) do esperado. 
 
B) DESPERDÍCIO 
 
 Esforço dedicado ao diagnóstico e remoção de erros (defeitos). 
 
 QUALIDADE DO SOFTWARE ESTÁ NA AUSÊNCIA DO 
DESPERDÍCIO”. 
 
**** Quando ocorre a remoção de Defeitos? 
 
 a) Em projetos sem GQS ? (Manutenção) 
 b) Em projetos com GQS ? (Desenvolvimento) 
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 10 
 
 
 
 
VISÃO DOS TESTES 
 
 
 
 
**** Como os profissionais veem o TESTE de SW !? 
 
 
 
 
 
 
 Comparar os programas com as especificações 
 Encontrar “bugs” nos programas 
 Determinar o nível de aceitação pelo usuário 
 Garantir que o sistema esteja pronto para ser usado 
 Adquirir confiança no seu desempenho 
 Mostrar que o SW (programa ou sistema) funciona corretamente 
 Demonstrar que não há erros / defeitos 
 Saber o que o Sw não tem condições de fazer 
 Avaliar os recursos de software 
 Verificar a documentação 
 Conhecer os limites da performance/ desempenho do Sw. 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 11 
 
OBJETIVA O ALCANCE DO EMPREENDIMENTO. ATINGIR A QUEM,
O QUE, ATÉ QUE PONTO. SERVE DE BASE PARA ORIENTAR AS 
NECESSIDADES A NÍVEL OPERACIONAL
CARACTERÍSTICAS DE 
“ESPECIFICAÇÕES”
NIVEL DE NECESSIDADE
 “CONCEITUAL”
ANALISTA USUÁRIO
DE LIMITES
DEVE FAZER PARTE DOS OBJETIVOS DO SW, E QUE SERVIRÃO
DE BASE PARA ORIENTAR AS NECESSIDADES A NÍVEL LÓGICO
DE FORMA DEVE FAZER PARTE DOS REQUISITOS DO SW, E QUE SERVIRÃO
DE BASE PARA ORIENTAR AS NECESSIDADES A NÍVEL FÍSICO
DE DIMENSÃO
INPUT
RESPONSÁVEIS
 
 
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 12 
 
CARACTERÍSTICAS DE 
“FUNÇÕES + DADOS ”
NIVEL DE NECESSIDADE
 “LÓGICA”
ANALISTA
PROJETISTA
RESPONSÁVEL
INPUT
“ESPECIFICAÇÕES”
* Representações e interligações, com base na declaração dos OBJETIVOS
 e das Necessidades de Infor’mação
* Identificação dos dados e principais funções
 (Pode ser usada a abordagem por processos ou por eventos)
* Relacionamento entre estes elementos
* Descrição dos dados e funções 
 
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 13 
 
CARACTERÍSTICAS
“QUALITATIVA”
NIVEL DE NECESSIDADE
 “FÍSICA/IMPLEMENTAÇÃO”
PROGRAMADOR
PROJETISTA
RESPONSÁVEL
INPUT
FUNÇÕES + DADOS”
* Interface dos dados / funções com o ambiente operacional
* Estruturação dos componentes
* Produtos a oferecer
* Bases de Dados constituidas
* Linguagens a utilizar
* Alternativas de implementação (batch, on-line,etc)
 
 
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 14 
 
CARACTERÍSTICAS
“QUANTITATIVA”
NIVEL DE NECESSIDADE
 “OPERACIONAL”
RESPONSÁVEL
INPUT
QUALITATIVA”
* Eficiência
* Desempenho
* Volume
* Frequência de uso
* Pressão / stress
* Capacidade de execução
USUÁRIO,
ANALISTA,
PROJETISTA,
PROGRAMADOR
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 15 
 
 
“ESTUDO DE CASO” 
 
Seja resolver o problema de construir um software (programa ou sistema) 
que atenda às exigências de uma empresa aérea para “Controle de 
Passagens”. 
 
Suponhamos, por hipótese, que as seguintes condições fossem 
estabelecidas: 
 
I - Características de “Especificações” 
 
a) Quanto aos LIMITES (Objetivos): 
 
- O sw visa atender passagens domésticas no eixo da região sul do país; 
- Atendimento a ser dado a passageiros de variadas classes econômicas; 
- Controlar percursos de tráfego aéreo; 
- Atender agências de viagem e turismo; 
- Facilitar aquisição e reserva de passagens 
 
b) Quanto à FORMA (Requisitos): 
 
- Disponibilizar acesso diário às informações pelas agências de viagem e 
turismo, localizadas nas principais cidades da região sul, que possuam mais 
de 50.000 habitantes; 
- Atendimento à consulta e reservas, em tempo real, com no máximo 10 
segundos de tempo de resposta; 
- Estatística diária do tráfego aéreo; 
- Posicionamento horário da situação do tráfego e das reservas de passagens. 
 
c) Quanto à DIMENSÃO : 
 
- A quem atingir : CLIENTES, AGENTES DE VIAGEM, GERENTES DA 
EMPRESA AÉREA; 
- O que atingir: Os diversos processos de “Controle de Passagens”; 
- Até que ponto atingir: No mínimo 100 Clientes/dia. 
 
II - Características de “Funções e Dados” 
 
a) Dados: 
 
- CLIENTE (Nome, Endereço, Telefone, CPF, etc) 
- AERONAVE : (Prefixo, Empresa, Numero-vôo,etc) 
 
b) Funções: 
 
- Reservar lugares 
- Emitir passagens 
- Verificar disponibilidade de vôoTESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 16 
 
Se num sistema de “Pagamento de pessoal” : 
 FUNÇÕES :. Calcular descontos / Emitir contra-cheque 
 DADOS : Empregado (Matricula, Nome, Salário,...) 
 
III - Características “Qualitativa” 
 
a) Funções 
 
>>> “Reservar lugares” 
 
- Alternativa de implementação : On-Line 
- Produtos gerados : Tela de verificação de reserva de passagem 
 
>>>“Verificar disponibilidade de vôo” 
 
- Alternativa de implementação : Batch 
- Produtos gerados: Estatística do tráfego, com impressão de gráficos 
 
>>>“Emitir passagem” 
 
- Alternativa de implementação : Batch e/ou on-line 
- Produtos gerados: Bilhete de passagem 
 
b) Recursos a utilizar 
 
HW : PC em rede, conectado ao Servidor 
 
SW : SGBD Oracle, DB2 ou ADABAS; 
 Sistema Operacional DOS e UNIX 
 Linguagem de Programação : SQL, C++l, COBOL 
 
c) Bases de Dados: CLIENTES, TABELA DE VÔOS, etc. 
 
d) Comunicação com o ambiente: 
 
Dados sobre os VÔOS gerados no Oracle; 
Dados do CLIENTE gravados no ADABAS. 
 
 
IV - Características “Quantitativa” 
 
. Software é capaz de suportar 20 acessos simultâneos (pressão) 
. Executa dentro das restrições impostas : < 10 segundos (desempenho) 
. Processa até 400 bilhetes/dia (volume) 
 
 
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 17 
 
 
TESTE SISTEMÁTICO 
 
Requer: 
 
a) Instrumentação de teste; 
b) Projeto de casos de testes baseados em critérios de seleção suficientemente 
eficazes; 
c) Análise rigorosa dos resultados; 
d) Identificação e eliminação cuidadosa das falhas do SW (programa ou sistema) 
 
 
Algumas definições importantes: 
 
F A L H A 
 
É um defeito ou incorreção latente no Sw, ou em seu ambiente, sobre os quais 
temos controle. 
Incluem-se nesta categoria os erros de uso ( coleta; preparação, transcrição e 
transmissão de dados; interpretação dos resultados). 
 
A C I D E N T E 
 
É uma inadequação do ambiente do sistema de computação, que pode impedir, 
temporária ou definitivamente, o correto funcionamento do Software. 
Exemplos: Falta de energia; incêndio; arquivos com data check, etc. 
 
E R R O 
 
É uma consequência do exercício de uma falha do SW ou da ocorrência de um 
acidente, ou seja, um erro é um sintoma de que algo foi mal, enquanto que falhas 
e acidentes são as causas deste mal funcionamento. 
 
PROVENIÊNCIA DOS ERROS: 
 
 1 - EXTERNA 
 
 Defeitos de HW, erros de operação, dados errados, etc. 
 
 2 - INTERNA 
 
 Erro na lógica, etc. 
 
D A N O 
 
É o prejuizo provocado pelo erro. 
 
Exemplo: Deturpação do Banco de Dados; destruição de arquivos ou programas 
por vírus. 
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 18 
 
 
OBSERVAÇÕES: 
 
A) É objetivo da segurança prevenir FALHAS e ACIDENTES; 
B) É objetivo do controle (auditoria) monitorar o funcionamento e uso do Sw. 
C) Problemas com o SW podem ser da seguinte natureza: 
 
1 - De especificação : 
 . Não faz o que é esperado; 
2 - De implementação : 
 . Não atende ao especificado; 
3 - De utilização: 
 3.1 - Voluntários: Fraude, sabotagem, indisciplina de uso, etc. 
 3.2 - Involuntários: Acidentes, erros de operação, etc. 
4 - De sincronização : 
. Atualização simultânea em Banco de Dados , causando “Deadlocks”, que 
são várias transações on-line por múltiplos usuários. 
 
D) Algumas recomendações para evitar/minimizar problemas com o SW: 
 
O Software deve conter redundâncias do tipo: 
 testes de domínio de índices; 
 testes de domínios de referências (acessar objetos existentes e 
semânticamente corretos ; 
 controles estatísticos; 
 registros de ocorrências (log’s); 
 comparação de resultados entre algorítmos diferentes que computam a 
mesma função. 
 
E) Aborto de programas: Em que situações evitar? 
 
 - Em controle de processos (Robôs,...); 
 - Na supervisão e controle (radar, ...); 
 - Em sistemas operacionais; 
 - Na atualização de arquivos particionados, diretos ou randômicos, etc. 
 
Motivo: Perda de referência do ponto de aborto. 
 
- Como se deve proceder? 
 
 - Emitir mensagem clara sobre o que provocou o erro e o ponto do erro! 
 - Reiniciar a recuperação do erro (restart) 
 
 
 
 
 
 
 
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 19 
 
 
 
I N S T R U M E N T A Ç Ã O 
 
 
 
 
 
Os instrumentos (técnicas) mais comuns no auxílio e deteção de erros e falhas 
são através do estabelecimento de: 
 
a) controles: totais de controle, validação de parâmetros inter-módulos,etc. 
b) Exibição : displays, ready trace, dumps de memória, etc. 
 
Obs. A instrumentação pode ou não ser apoiada por ferramentas automatizadas. 
 
 
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 20 
 
 
TIPOS DE TESTES 
 
. CAIXA-PRETA 
A lógica interna do sw é desconhecida e os testes só serão efetuados por 
exaustão. Se baseiam somente nas especificações existentes e nos dados de 
entrada. 
 
. CAIXA-BRANCA 
A estrutura lógica é conhecida, podendo ser valida por testes não exaustivos. 
 
>>> Premissa falsa (anos 60) : 
“A única maneira de testar um programa é pela sua sua execução na máquina”. 
 - São os famosos testes no computador - 
Comentários: - Na época, as soluções eram estritamente operacionais; 
- Perfil do profissional era o Programador..... 
 
>>>Início dos anos 70... (G.M. Weimberg) 
(The psychology of Computer Programming) 
“Se programas são lidos (ou podem ser lidos) por pessoas, este seria um 
processo efetivo de deteção de erros” 
 - São os famosos testes humanos - 
 
MÉTODOS DE TESTES: 
 
1 - Teste entre o tempo que o programa é codificado e o tempo que inicia os 
testes de máquina; 
2 - Aplicar os testes ao final de cada estágio do projeto. 
 
4 - PRINCÍPIOS BÁSICOS DOS TESTES: 
 
P1 : “Testar tudo é (quase) impossível; 
 Por limitações práticas : Imagine testar todos os contribuintes do IR !!! 
Deve-se testar o necessário, para que o mínimo suficiente seja 
atendido. 
 Por impossibilidades teóricas: Prova matemática de correção de 
programas. 
 
P2 : “Testar é uma atividade trabalhosa, difícil e que exige criatividade” 
 
P3 : “Testar é uma forma de prevenção quanto a erros” 
 
P4 : “Os testes têm que ser planejados” 
 
P5 : “Testar exige independência (mental ou física)” 
 
 Testes contribuem para aumento da produtividade e confiança 
 Custos de correção de erros são mais baratos se encontrados mais cedo 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 21 
 
 
PLANEJAMENTO DE TESTES 
 
Uma execução eficaz de testes exige: 
 
a) Plano de Testes 
b) Descrição dos testes 
c) Procedimentos de testes 
 
a) Plano de testes 
 
É um documento organizado que descreve alguma atividade de teste. 
 
a.1) Conteudo do plano 
 
- Objetivo dos testes 
- Ambiente dos testes (incluindo local de realização) 
- Cronograma de execução dos testes 
- Responsáveis pelos testes 
 
b) Descrição dos testes 
 
Informar quais os elementos de entrada que serão introduzidos e que saidas são 
esperadas.c) Procedimentos dos testes 
 
- Como os dados devem ser preparados e submetidos; 
- Como os resultados devem ser colhidos e analisados. 
 
 
 
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 22 
 
 
5 - WALKTHROUGH, REVISÃO e INSPEÇÃO 
 
WALKTHROUGH: 
 
“É a revisão de qualquer produto (em elaboração), visando a identificação ( e não 
a solução) de problemas (erros, omissões, imprevisões, inconsistências,etc.) ou 
a confirmação da ausência deles.” 
 
DIFERENÇA BÁSICA ENTRE WALKTHROUGH e REVISÃO 
 
WALKTHROUGH REVISÃO 
Dinâmico Estático 
Exige total iteração Exige pouca ou nenhuma iteração 
 
OBJETIVOS DO WALKTHROUGH 
 
 Identificação de erros visando assegurar que o produto esteja correto à 
primeira vista; 
 Aumento da produtividade no desenvolvimento do software (programa ou 
sistema); 
 Garantia de que os padrões estão sendo obedecidos; 
 Auxilio no desenvolvimento de novos padrões; 
 Aumentar o nivel de segurança do que está sendo feito; 
 Ampliar o conhecimento 
 
- QUANDO APLICAR O “WALKTHROUGH”? 
 
 Em cada ponto de revisão técnica exigida na metodologia de desenvolvimento de Sw. 
 
Exemplos: 
 Validação do modelo conceitual / lógico do sistema; dos projetos de 
arquivos, telas, relatórios propostos; das soluções alternativas para 
construção do SW; 
 Aprovação de fases do projeto do Sw, etc. 
 
- QUEM DEVE PARTICIPAR DO WALKTHROUGH? 
 
 Equipe responsável pelo desenvolvimento, mais o usuário (conceitual), mais equipes 
que possuam interface de seu SW. 
 
 
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 23 
 
 
I N S P E Ç Ã O 
 
“Conjunto de procedimentos e técnicas de deteção de erros, por grupo de 
leitores de código ou através de modelos de representação”. 
 
Um retrospecto: Teste de Mesa 
 
“O mais antigo processo de verificação de programas” Lembram-se ??? 
 
. Improdutivo? 
. Indisciplinado? 
. Inefetivo? Do teste de um só? 
 
 “Há mais sinergia ao se fazer um Walkthrough ou mesmo uma Inspeção”!!! 
 
QUEM DEVE REALIZAR A INSPEÇÃO? 
 
 
O próprio desenvolvedor do software, juntamente com um programador mais 
experiente, mediado por um coordenador-moderador. 
 
Normalmente, o grupo de inspeção é organizado da seguinte forma: 
 
a) Moderador : Programador mais experiente 
b) Autor : Programador que construiu o programa 
c) Pelo menos 2 outros programadores: 
 - Um especialista em testes; 
 - Um de outra equipe 
A postura dos integrantes deve ser não defensiva; o espírito deve ser altruista! 
 
 Funções/atividades dos membros da inspeção 
 
a) Moderador: 
 - Conduzir imparcialmente a inspeção 
 - Controlar a qualidade 
 - Distribuir o material a ser inspecionado 
 - Registrar a inspeção: apontar erros, propor correções. 
 
b) Autor: 
 - Esclarecer dúvidas relativas ao trabalho por ele realizado. 
 
c) Dois (2) outros programadores: 
 - Realizar a inspeção! 
 
 
QUAL A SIMILARIDADE COM O 
WALKTHROUGH? 
 
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 24 
 
 
Ambos fazem exame da situação do software. 
 
QUAL A DIFERENÇA COM RELAÇÃO AO 
WALKTHROUGH? 
 
 WALKTHROUGH : . Os resultados são obtidos por consenso. 
 INSPEÇÃO : Os resultados são obtidos pelo exame físico do software. 
 
PRINCIPAIS OBJETIVOS DA INSPEÇÃO 
 
 Detetar erros , antes de implementar o software. 
 Analisar o software através de um “Checklist de Inspeção”. 
 
 
 
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 25 
 
 
 
T E S T E S 
 
 Testes variam : 
 de pessoa para pessoa 
 de projeto para projeto 
 de empresa para empresa 
 
 Natureza dos testes 
 Formal 
 Informal 
 
Testes formais: 
 Exigem plano organizado de testes (ver Planejamento de testes) 
 
Testes informais: 
 
 Não possuem nenhum plano! É uma extensão natural do processo de 
codificação! 
 
Prática muito comum: 
 
 “Bolar” os testes no terminal . 
 
 **** Programadores de ambiente “on-line” tendem a fundir as atividades 
de desenvolvimento da lógica (codificação), depuração (eliminação de erros), e 
teste (medição de qualidade e correção). 
 
 Nestes casos, se é determinado um erro e corrigido, o caso de teste 
terá que ser re-inventado. 
 
 Ao ser re-inventado, teremos: 
 
 - Mais trabalho 
 - Falta de registro do teste anterior 
 - Re-teste menos rigoroso que o anterior 
 
Um retrospecto: Teste de Mesa 
 
“O mais antigo processo de verificação de programas” Lembram-se ??? 
 
. Improdutivo? 
. Indisciplinado? 
. Inefetivo? Do teste de um só? 
 
 
 
 
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 26 
 
 
 
TESTES EM ESCALA 
 
 
 TESTES EM PEQUENA ESCALA (TPE) 
 TESTES EM GRANDE ESCALA (TGE) 
 
 
 TESTES EM PEQUENA ESCALA (TPE) 
 
 Compreende os testes de instruções, conjunto ou segmento de instruções, 
rotina; módulo; até o nível máximo de PROGRAMA. 
 
 Programa 
 
 
 Módulo 1 ......... Módulo N 
 
 
 
 Segmento A ....... Segmento N 
 
 
 
 Instrução 1 ........ Instrução N 
 
 
 TESTES EM GRANDE ESCALA (TGE) 
 
 Compreende os testes de grupos de módulos, programas, conjunto de 
programas, subsistema, até o nível máximo de SISTEMA. 
 
 
 Sistema 
 
 
 
 Subsistema 1 ..... Subsistema N 
 
 
 Programa 1 ......... Programa N 
 
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 27 
 
 
 
8 - TESTES EM GRANDE ESCALA 
 
 
TESTES DE SISTEMA 
 
 
 
Categorias de testes de sistemas: 
 
 
 
1 - FACILIDADE 
2 - VOLUME 
3 - PRESSÃO (STRESS) 
4 - USABILIDADE 
5 - SEGURANÇA 
6 - DESEMPENHO 
7 - ARMAZENAGEM 
8 - CONFIGURAÇÃO 
9 - CONVERSÃO/COMPATIBILIDADE 
10 - INSTALABILIDADE 
11 - GARANTIA 
12 - RECUPERAÇÃO 
13 - UTILIDADE 
14 - DOCUMENTAÇÃO 
15 - PROCEDIMENTOS 
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 28 
 
 
1. TESTES DE FACILIDADE 
 
Determina se cada facilidade (ou função) mencionada nos objetivos foi 
implementada. 
 
Exemplo: Se um dos objetivos é “Calcular o IR do empregado”, verificar se o 
software (programa ou sistema) satisfaz este objetivo). 
 
2. TESTE DE VOLUME 
 
Submeter o software a enormes volumes de dados. 
 
Exemplos: 
 
 Um compilador (que é um programa) seria alimentado por um programa fonte 
extremamente grande; 
 Um programa “Linkage Editor” poderia ser alimentado por um programa aplicativo 
contendo milhares de módulos; 
 Uma fila de serviço (job queue) seria preenchida totalmente para testar a 
capacidade do Sistema Operacional; 
 Se um programa manipula arquivos envolvendo múltiplos volumes, ele seria 
checado para ver se ele muda de um arquivo para o outro; 
 
 O propósito do Teste de Volume é mostrar que o programa (não) consegue 
manipular o volume de dados especificado em seus objetivos. 
 
3. TESTE DE PRESSÃO (STRESS) 
 
Envolve submeter o software a pesadas cargas ou pressões.(Não confundir com teste de volume, pois o teste de stress envolve o elemento 
TEMPO!) 
 
 
Uma analogia com o datilógrafo: 
 
 Capacidade de copiar um relatório contendo 500 folhas, de 300 palavras por 
folha 
 (VOLUME) 
 Capacidade de datilografar 180 palavras por minuto 
 (PRESSÃO) 
Aplicabilidade: 
Em software de 
 - controle de processo 
 - iterativo 
 - tempo real 
 
Exemplos: 
 
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 29 
 
 Sistema de controle de tráfego aéreo 
 controla até 200 aviões por setor 
 qual a sua reação para mais de 200 ? 
 Um Sistema Operacional que suporta 15 JOBs multiprogramados 
 qual a sua reação para executar os 15 JOBs simultâneamente? 
 Um sistema de tempo compartilhado (time-sharing) que suporta até 64 terminais 
 o que ocorreria se 64 usuários de terminal tentassem dar “sign on” ao mesmo 
tempo? 
 (normalmente há um colapso, e a saida é colocar o sistema no ar novamente) 
 
 Simulador de vôo para treinamento de piloto (manipular vários instrumentos ao 
mesmo tempo) 
 Sistema de controle de processos de geração de sinais (lembram-se do filme 
SINDROME DA CHINA?) 
 Um sistema telefônico roteando chamadas simultâneas 
 
4. TESTE DE USABILIDADE 
 
Leva em consideração os problemas relacionados a fatores humanos , tais como: 
 
a) as saidas dos programas são desprovidas de jargão “computês” 
b) as mensagens de erros são significativas ou necessita um PhD para decifrá-las? 
 
“IEK022A OPEN ERROR ON FILE YSYIN ABEND CODE = 102 “ ?!?!?! 
c) onde o cuidado e precisão são fatores vitais (ex.: sistemas bancários on-line) é a 
redundância suficiente na entrada? 
 
Exemplo: NÚMERO CONTA (e SENHA) e NOME CLIENTE 
d) o sistema contem um número excessivo de opções , ou as opções existentes são 
improváveis de serem usadas? 
e) os comandos “on-line”permitem facilidade de uso? ou requerem inúmeras 
navegações e repetidas “teclagens”? 
 
5. TESTE DE SEGURANÇA 
 
É o processo que objetiva tentar projetar casos de testes que subvertam os checks 
de segurança do software. 
 
Exemplos: 
 
 formular casos que subvertam o mecanismo de proteção de memória do sistema 
operacional. 
 formular casos que subvertam o mecanismo de segurança de dados de um 
SGBD 
 
6. TESTE DE DESEMPENHO 
 
O objetivo é demonstrar que o sistema (pode, não pode; consegue, não consegue) 
manipular o volume de dados e transações recebidas especificadas no modelo de 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 30 
 
implementação do usuário, bem como se ele (apresenta, não apresenta) o tempo de 
resposta necessário. 
 
7. TESTE DE ARMAZENAGEM 
 
O objetivo é mostrar que as quantidades de armazenagem requeridas de memória , 
principal e secundária , usadas pelo programa e os tamanhos dos arquivos 
temporários são insuficientes , ou estouram. 
 
8. TESTE DE CONFIGURAÇÃO 
 
Consiste em submeter o programa a um determinado tipo de dispositivo de 
hardware e com a configuração mínima e máxima deste hardware. 
 
Incluem-se nestes casos para testes, os programas de: 
 
- sistemas operacionais 
- DBMS (ou SGBD) 
- Message-Switching (troca de mensagens) 
 
9. TESTE DE COMPATIBILIDADE/CONVERSÃO 
 
O objetivo é testar a capacidade do software em atender aos procedimentos de 
conversão, seja de origem de um sistema deficiente proveniente de um sistema 
manual ou de processamento de dados. 
 
10. TESTE DE INSTALABILIDADE 
 
Alguns tipos de SW têm procedimentos complicados para instalação. 
 
Exemplo: 
 
- O SYSGEN (System Generator) do OS/IBM 
 
11. TESTE DE GARANTIA 
 
O objetivo é verificar a fidedignidade do programa em atender as características de 
garantia do mesmo. 
 
Exemplos: 
 
 Um programa de transmissão de arquivo: é permitido um erro a cada 30 minutos 
de transmissão (MTTF = Mean-time-to-failure) 
 O sistema TSPS (comutação telefônica) da Bell System pode sofrer uma 
interrupção de até 2 horas em 40 anos de operação. 
 
12. TESTE DE RECUPERAÇÃO 
 
O objetivo é verificar se o software (pode, não pode) recuperar-se adequadamente 
de vários tipos de falhas (checkpoint restart). 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 31 
 
 
Falhas: 
 
 erro de programação 
 falhas de hardware (erros de paridade de memória; de I/O;...) 
 erros de dados (ruídos numa linha de comunicação; um ponteiro inválido num 
SGBD) 
 
13. TESTE DE UTILIDADE 
 
O objetivo é verificar o nível de atendimento dos serviços auxiliares (*) prestados 
pelo software; o tempo médio para depuração de um problema; os procedimentos 
de manutenção; e a qualidade da documentação da lógica interna. 
 
Este tipo de teste é muito utilizado em BENCHMARK !!! 
 
(*) Serviços Auxiliares: 
 
 - programas de DUMPs de memória; 
 - programas de diagnóstico de erros (Ready Trace) 
 
14. TESTE DE DOCUMENTAÇÃO 
 
O objetivo é verificar quanto à clareza e precisão de documentação. 
 
15. TESTE DE PROCEDIMENTOS 
 
O objetivo é verificar se os procedimentos automatizados estão adequados aos não-
automatizados e vice-versa. 
 
Exemplos: 
 
Procedimentos do controlador da produção; do operador do Sistema; do AD e ABD; 
usuário do terminal. 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 32 
 
 
 
 
 
 
 
 
 
 
 
 
 
(ANEXO : Ilustração de “Interoperabilidade”) 
 
Extraido de um artigo da DEC – Digital Equipment Corporation 
 
 
 
OBS. Nas figuras abaixo: 
 
 RDB – significa Relational Data Base
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 33 
 
 
21
Primeiro, resolvi
apresentar uma planilha
com os índices atuais de
produtividade da empresa.
Os dados estavam no RDB
corporativo. Bastava
passá-los para o VAX e,
através do SW EXCEL,
portá-los p/ o meu micro.
Essa até que foi fácil!
R
D
B
PLANILHA
INTEROPERABILIDADE
Você sabe o que é
INTEROPERABILIDADE? Pois é,
eu também não sabia. Até que o
chefe me encomendou um estudo
sobre a produtividade de nossa
empresa, para ser entregue em 24
horas. E eu quase entrei em pânico.
Mas aí comecei a raciocinar ....
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 34 
 
4
5
6
Agora, o problema. O meu estudo exigia
um gráfico imenso, com o faturamento
de todas as nossas filiais ao redor do
mundo. E esse gráfico estava em
mainframe parisiense...Mas, eu achei o
caminho: via rede, trouxe o gráfico do
mainframe para o VAX. Deste, levei
para um Mac com Sw DECQuery, que
também roda em PC. Assim,passei tudo
para o meu micro. “Touché”.
GRÁFICO 2
R
D
B
OK !
Depois, pensei em acrescentar
ao estudo um gráfico com os
lucros dos últimos 5 anos.
Este gráfico estava à minha
disposição... em um
Macintosh na filial de
Londres! Sem problema:
instalei no meu PC o Sw
WPS-Plus, e trouxe o gráfico
via Rede. Mais fácil,
impossível !!!
3
GRÁFICO 1
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor:José Geraldo Silva (TSTSWJG.doc/) Página: 35 
 
8
Foi aí que eu
lembrei de uma
ilustração
belíssima, feita
por um técnico
da filial de
Tóquio, que
valorizaria muito
meu trabalho. A
ilustração tinha
sido criada em
uma VAXstation
e digitalizada no
SW Express.
Entrei na rede,
acessei o Sw
Excursion no
PC, e trouxe o
arquivo para o
meu PC.
“Arigatô”!
ILUSTRAÇÃO
7
DESENHO TÉCNICO
Por fim, faltava um desenho
técnico do produto vendido por
nossa empresa, para que eu
pudesse apontar os componentes
OEM mais caros. Este arquivo
tinha sido feito no UNIX Cad do
VAX da matriz, em
Massachussets. Muito simples:
importei-o para uma DecStation
e, com o DecWrite, tirei uma
prova a laser. Conferi se estava
tudo bem e levei o arquivo para
o meu PC.
 
TESTES de SOFTWARE – uma visão 
 
 
_____________________________________________________________________ 
Autor: José Geraldo Silva (TSTSWJG.doc/) Página: 36 
 
Pois bem: dados do RDB local,
um gráfico de Londres, outro de
Paris, uma ilustração japonesa e
um diagrama técnico de
Massachussets. Dei a volta ao
mundo, mas consegui terminar
tudo a tempo... E o trabalho ainda
ficou com um certo ar
internacional!
9 10
Parece milagre? Concordo.
Mas o nome é outro:
INTEROPERABILIDADE.
Ou seja, todos os dados que v.
precisa à sua disposição, não
importando onde estejam ou
em que plataforma. Para o
mundo informatizado, isso é
quase uma utopia. Mas para
mim, foi um pouquinho mais:
muitos elogios, uma promoção
e alguns dias de licença, que
ninguém é de ferro ...
FIM