Aula 01 - Testes de Software

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

*
*
*
Engenharia 
de Software II
Testes de Software
Prof. Ulisses Sperle Graça
*
*
*
 Justificativa
	O desenvolvimento de sistemas envolve uma série de
atividades em que as oportunidades de injeção de falhas são muito grandes. Estes erros podem começar a aparecer logo no início do processo, onde os objetivos podem estar erroneamente especificados, além de erros que venham a ocorrer em fases de projeto e desenvolvimento posteriores. 		Como a tolerância a software com erros /problemas é praticamente inexistente, o desenvolvimento de software é acompanhado por uma atividade de garantia de qualidade.
	A atividade de teste de software é um elemento crítico da garantia de qualidade de software e representa a última revisão de especificação, projeto e codificação.
*
*
*
 Custo do Reparo
*
*
*
 Curva de falhas para o hardware
 
*
*
*
 Curva de falhas para o software
*
*
*
 Conteúdo Programático
UNIDADE 1: Garantia de Qualidade de Software
1.1	– Qualidade e garantia de qualidade de software
1.2	– Revisões de software
1.3	– Métricas de qualidade
1.4	– Confiabilidade de software
UNIDADE 2: Técnicas de Teste de Software
2.1	– Fundamentos de teste de software
2.2	– Teste de caixa branca
2.3	– Teste de caminho básico
2.4	– Teste de estrutura de controle
2.5	– Teste de caixa preta
*
*
*
 Conteúdo Programático (cont.)
UNIDADE 3: Estratégias de Teste de Software
3.1	– Uma abordagem estratégica
3.2	– Teste de unidade
3.3	– Teste de integração
3.4	– Teste de validação
3.5	– Teste de sistema
3.6	– Depuração
UNIDADE 4: Manutenção de Software
4.1	– Características de manutenção
4.2	– Manutenibilidade
4.3	– Tarefas de manutenção
4.4	– Efeitos colaterais
*
*
*
 Bibliografia
PRESSMAN, R. S. Engenharia de Software. São Paulo: Makron, 1997.
PETERS, James F; PEDRYCZ, Witold. Engenharia de Software: teoria e prática. Rio de Janeiro: Campus, 2001.
*
*
*
Garantia de Qualidade de Software
Unidade 1
*
*
*
1. Garantia da Qualidade de Software
 Nossa Meta  Produzir software de alta qualidade.
A garantia de qualidade de software (Software Quality Assurance) não é algo com a qual começamos a nos preocupar depois que o código foi gerado, e sim, ao longo de todo o processo de engenharia de software. A GQS abrange:
1. Métodos e ferramentas de análise, projeto, codificação e teste.
2. Revisões técnicas formais, aplicadas a cada fase de eng. de soft.
3. Uma estratégia de teste de múltiplas fases.
4. Controle de documentação de software e das mudanças efetuadas.
5. Procedimento para garantir a adequação aos padrões de desenvol-
 vimento de software.
6. Mecanismos de medição e divulgação.
*
*
*
1.1. Qualidade e Garantia da Qualidade
	Qualidade  Adequação ao uso.
 
	Qualidade de Software  Conformidade a requisitos funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implí- citas que são esperadas de todo software profissionalmente desenvol vido. É ainda, uma combinação complexa de fatores que variarão de acordo com diferentes aplicações e clientes que as solicitam.
	Devemos enfatizar 3 pontos importantes:
*
*
*
 Os requisitos de software são a base a partir da qual a qualidade é medida. A falta de conformidade aos requisitos significa falta de qualidade.
 Padrões especificados definem um conjunto de critérios de desenvolvimento que orientam a maneira segundo a qual o software passa pelo trabalho de engenharia. Se os critérios não forem seguidos, o resultado quase que seguramente será a falta de qualidade.
 Há um conjunto de requisitos implícitos que frequentemente não são mencionados (ex.: boa manutenibilidade). Se o software se adequar aos requisitos explícitos, mas não aos implícitos, sua qualidade será suspeita.
1.1. Qualidade e Garantia da Qualidade
*
*
*
Características Operacionais:
Corretitude  À medida que um programa satisfaz sua especificação e cumpre os objetivos visados pelo cliente. Ele faz aquilo que eu quero? 
Confiabilidade  À medida que se pode esperar que um programa execute sua função pretendida com a precisão exigida. Ele se comporta com precisão o tempo todo? 
Eficiência  À quantidade de recursos de computação e de código exigida para que um programa execute sua função. Ele rodará em meu hardware tão bem quanto possível?
1.1.1. Fatores de Qualidade de Software
*
*
*
Características Operacionais: (cont.)
Integridade  À medida que o acesso ao software ou a dados por pessoas não autorizadas pode ser controlado. Ele é seguro?
Usabilidade  O esforço para aprender, operar, preparar a entrada e interpretar a saída de um programa. Ele foi projetado para o usuário?
1.1.1. Fatores de Qualidade de Software
*
*
*
Características de Manutenção:
Manutenibilidade  O esforço exigido para localizar e raparar erros num programa. Posso consertá-lo?
Flexibilidade  O esforço exigido para modificar um programa. Posso mudá-lo?
Testabilidade  O esforço exigido para testar um programa a fim de garantir que ele execute sua função pretendida. Posso testá-lo?
1.1.1. Fatores de Qualidade de Software
*
*
*
Características de Adaptação a novos ambientes:
Portabilidade  O esforço exigido para transferir o programa de um ambiente para outro. Serei capaz de usá-lo em outra máquina?
Reusabilidade  à medida que um programa, ou partes, pode ser reusado em outras aplicações. Serei capaz de reutilizar parte do software?
Interoperabilidade  O esforço exigido para se acoplar um sistema a outro. Serei capaz de compor uma interface com outro sistema?
1.1.1. Fatores de Qualidade de Software
*
*
*
	É difícil, e em certos casos impossível, desenvolver medidas diretas dos fatores de qualidade discutidos. Portanto, faz-se necessária a definição de um conjunto de métricas que afetam o fator de qualidade, que são usadas para desenvolver expressões para cada um dos fatores, de acordo com a seguinte relação:
Fq = c1 x m1 + c2 x m2 + ... + cn x mn
	Fq=Fator qualidade Software, Cn=coeficiente de regressão Mn=métricas que afetam Fq
	A seguir, apresentaremos algumas métricas:
1.1.1. Fatores de Qualidade de Software
*
*
*
	Exemplos de Métricas:
	
Auditabilidade - Facilidade com que se pode checar a conformidade aos padrões.
Tolerância a erros - O dano que ocorre quando o programa encontra um erro.
Eficiência de execução - o desempenho de run-time do programa.
Independência de hardware - O quanto o software é desvinculado do hardware em que opera.
Instrumentação - O quanto o programa monitora sua própria opera-ção e identifica erros que venham a ocorrer.
Modularidade - A idenpendência funcional dos componentes do programa
1.1.1. Fatores de Qualidade de Software
*
*
*
	Exemplos de Métricas:
 
Operabilidade - A facilidade de operação de um programa
Segurança - A disponibilidade de mecanismos que controlem ou protejam programas e dados.
Autodocumentação - O quanto o código-fonte apresenta documentação significativa.
Simplicidade - O quanto um programa pode ser entendido sem dificuldade.
Independência do software básico - O quanto um programa é independente de particularidades não-padronizadas de linguagens de programação nonstandard, das características de S.O. e outras restrições de ambiente.
Treinamento - O quanto o software auxilia no sentido de ajudar novos usuários a aplicarem o sistema.
1.1.1. Fatores de Qualidade de Software
*
*
*
	“Padrão sistemático e planejado de ações que são exigidas para garantir a qualidade do software”
	Muitos participantes diferentes de uma organização são responsáveis pela GQS. Este grupo, serve como representante in-house do cliente. Ou seja, devem olhar o software a partir do ponto de vista do cliente.
 Atende adequadamente aos fatores de qualidade?
 Seu desenvolvimento foi conduzido de acordo com padrões?
 As disciplinas técnicas cumpriram adequadamente seus papéis como parte da atividade de GQS?
1.1.2. O que é a GQS?
*
*
*
 Aplicações de métodos técnicos;
 Realização de revisões técnicas formais;
 Atividades de teste de software;
 Aplicação de padrões;
 Controle de mudanças;
 Medição;
 Manutenção de registros e reportagens.
1.1.3. Atividades da GQS
*
*
*
	São um “filtro” para o processo de engenharia de software. As revisões são aplicadas em vários pontos durante o desenvolvimento do software e servem para descobrir defeitos que possam ser eliminados.
Lembre-se: Errar é humano e, embora algumas pessoas captem bem alguns de seus erros, outros tantos escapam mais facilmente a quem lhe deu origem do que a outras pessoas.
 Apontar melhorias necessárias ao produto;
 Confirmar as partes em que uma melhoria é desnecessária;
 Realizar um trabalho técnico com uma qualidade mais uniforme, de forma a tornar este trabalho técnico mais administrável.
1.2. Revisões de Software
*
*
*
	O benefício das revisões é a descoberta precoce dos defeitos de software, de forma que possam ser corrigidos antes do passo seguinte.
	Atividades de projeto introduzem entre 50 a 60% dos erros.
Técnicas de revisão têm-se mostrado até 75% efetivas na descoberta de falhas.
	Ao detectar e suprimir estes erros, o processo de revisão reduz substancialmente o custo dos passos subsequentes.
 Fase 	Custo de Correção
 Projeto	 	1,0
 Antes dos Testes	 	6,5
 Testes	 	15
Após Implantação	 	60 a 100 
1.2.1. Impacto do custo dos defeitos
*
*
*
	Durante o desenvolvimento, erros podem ser inadvertidamen te gerados. A revisão pode falhar ao tentar descobrir novos erros e erros das etapas anteriores, resultando em certos números de erros que são passados adiante. Em certos casos, os erros passados adiante de etapas anteriores são ampliados pelo trabalho atual.
	Para conduzir revisões, o desenvolvedor precisa gastar tempo, esforço e dinheiro. “Pague agora ou muito mais depois”.
 
		Erros ecncontrados Número Custo Unitário Total
C/ Revisão	Durante o projeto		22	1,5	 33
		Antes do teste		36	6,5		234
		Durante o teste		15	21		315
		Após o lançamento		 3	67		201  783
S/Revisão	Antes do teste		22	6,5		143
		Durante o teste		82	15	 1.230
		Após o lançamento		12	67	 804  2177
1.2.2. Ampliação e remoção de erros
*
*
*
	Uma RTF é uma atividade de garantia de qualidade de software executada por profissionais da engenharia de software. Cada RTF é realizada como um encontro e será bem sucedida somente se for adequadamente planejada, controlada e assessorada.
Objetivos:
 Descobrir erros de função, lógica ou implementação;
 Verificar se o software atende a seus requisitos;
 Garantir que ele tenha sido representado de acordo com os
 padrões;
 Obter um software que seja desenvolvido uniformemente;
 Tornar os projetos mais administráveis.
1.3. Revisões Técnicas Formais - RTF
*
*
*
1.3. RTF – Pontos de Revisão
*
*
*
Restrições:	 Entre 3 e 5 pessoas;
		 Uma preparação antecipada deve ocorrer, mas ela
		 não deve exigir mais de 2h de cada pessoa;
		 A duração da reunião deve ser inferior a 2h.
Uma RTF concentra-se numa parte específica e pequena do software, pois ao estreitar o foco, tem-se a probabilidade maior de revelar erros.
O foco da RTF está num produto - um componente de software (por ex.: uma parte da especificação de requisitos, um projeto modular datalhado, uma relação de códigos-fonte para um módulo).
 Produtor  Líder  Líder da Revisão  2 ou 3 Revisores
1.3.1. A Reunião de Revisão
*
*
*
	Tipicamente uma reunião é programada para o dia seguinte ao da preparação, e conta com o produtor e os revisores.
	Na reunião, o produtor passa então a “caminhar através” do produto, explicando o material, enquanto os revisores levantam questões baseadas na preparação antecipada que fizeram. Quando erros são são descobertos, um dos revisores (secretário) os anota.
	Ao final, os participantes devem decidir se:
 
	1. Aceitam o produto sem modificações adicionais;
	2. Rejeitam o produto devido a erros graves (uma vez
	corrigidos, outra revisão deve ser realizada);
	3. Aceitam o produto provisoriamente (erros menores foram 	encontrados e devem ser corrigidos, sem revisão adicional)
A decisão deve constar das anotações, sendo assinada por todos.
1.3.1. A Reunião de Revisão (cont.)
*
*
*
 Relatório de revisão resumido:
	1. O que foi revisado?
	2. Quem fez a revisão?
	3. Quais foram as descobertas e conclusões?
 Lista de questões de revisão:
	1. Identificar as áreas problemáticas do produto.
	2. Servir como uma lista de conferência de itens de ação
	que oriente o produtor quando correções forem feitas.
 Follow-up que garanta que os itens da Lista foram corrigidos.
1.3.2. Registros da Revisão
*
*
*
1. Revise o produto, não o produtor.
2. Fixe e mantenha uma agenda.
3. Limite o debate e a refutação.
4. Enuncie as áreas problemáticas, mas não tente resolver cada problema anotado.
5. Faça anotações por escrito.
6. Limite o número de participantes e insista numa preparação antecipada.
7. Desenvolva uma lista de conferência para cada produto que será revisto.
8. Atribua recursos e uma programação de tempo para as RTFs.
9. Realize um treinamento significativo para todos os revisores.
10. Reveja suas antigas revisões.
1.3.3. Diretrizes da Revisão
*
*
*
	As RTF podem ser feitas durante cada etapa do processo de Engenharia de Software. Será apresentado a seguir, algumas listas de conferência, que podem ser usadas para avaliar produtos derivados do desenvolvimento do software. Estas listas não pretendem ser abrangentes, mas sim, oferecer um ponto de partida para cada revisão.
Especificação do Sistema
 As funções principais são definidas de uma forma delimitada e sem ambiguidades?
 As melhores alternativas foram selecionadas?
 A solução é tecnologicamente viável?
 Foi estabelecido um mecanismo de validação e verificação para o sistema?
1.3.4. Lista de Conferência
*
*
*
Planejamento do Projeto do Software
 O escopo do software é definido e delimitado sem ambiguidade?
 Os recursos estão prontamente disponíveis?
 Os riscos em todas as categorias importantes foram definidos?
 Um plano de gerenciamento dos riscos está em andamento?
 Os orçamentos e prazos finais predefinidos são realísticos?
Análise de Requisitos de Software
 O modelo de dados reflete adequadamente os objetos de dados, seus atributos e relações?
 O desempenho é atingível, dentro das restrições impostas por outro elementos do sistema?
 Os requisitos têm consistência com os prazos, recursos e orçamento?
 Os critérios de validação estão completos?
1.3.4. Lista de Conferência (cont.)
*
*
*
Projeto de Software - Projeto Preliminar
 É conseguida uma efetiva modularidade? Os módulos são funcionalmente independentes?
 A arquitetura do programa é fatorada?
 A manutenibilidade foi levada em consideração?
 Os fatores de qualidade foram explicitamente avaliados?
Projeto de Software - Walkthrough de Projeto
 O algorítmo executa a função desejada?
 O algorítmo está logicamente correto?
 Quais particularidades são usadas: de SO, SGBD ou linguagem?
 A manutenibilidade foi levada em consideração?
1.3.4. Lista de Conferência (cont.)
*
*
*
Codificação
 Há erros de ortografia ou tipográficos?
 Existe concordância em relação aos padrões de codificação quanto ao estilo da linguagem, comentários e cabeçalho módulo?
 Há comentários incorretos ou ambíguos?
Teste de Software - Plano de Testes
 As fases de teste importantes foram adequadamente identificadas e dispostas sequencialmente?
 Um cronograma de teste foi explicitamente definido?
 Os recursos e ferramentas de teste foram identificados e estão à disposição?
 O Plano e testes é consistente com o plano de projeto global?
1.3.4. Lista de Conferência (cont.)
*
*
*
Teste de Software - Procedimento de Teste
 Foram identificados e listados casos de teste com seus resultados esperados?
 O tratamento de erros será testado?
 Os valores-limites serão testados?
 Foi especificada uma variação aceitável dos resultados esperados?
Manutenção
 Foram considerados possíveis efeitos colaterais associados à mudança?
 A solicitação de mudança foi documentada, avaliada e aprovada?
 A mudança, uma vez feita, foi documentada e relatada a todas as partes interessadas?
 Uma revisão de aceitação final foi realizada para ter a garantia de que o software foi adequadamente atualizado testado e substituído?
1.3.4. Lista de Conferência (cont.)