SlideShare uma empresa Scribd logo
Disciplina Engenharia de Software Processos de verificação e validação(V&V) - Métodos para Estimativas - Testes de Software 
Prof. Esp. Rafael H Mauro 
rafaelherman@yahoo.com.br
Processos de 
verificação e validação 
(V&V)
Verificação e Validação (V&V) Segundo (Sommerville, 2003) é o nome dado aos processos de verificação e análise, a fim de assegurar que o software cumpra com suas especificações e atenda às necessidades dos clientes que estão pagando por ele. Incluem as tarefas: 
 revisões dos requisitos; 
 revisões de projeto; 
 inspeções de código; 
 testes de produto.
Para (Boehm, 1979), a diferença entre verificação e validação pode ser assim definida: 
 Validação: “estamos construindo o produto correto?”. 
 Verificação: “estamos construindo o produto corretamente?”. Verificação: checar se o software cumpre com suas especificações, ou seja, se o sistema cumpre com seus requisitos funcionais e não funcionais. Validação: assegurar que o software atenda às expectativas do cliente, garantindo que ele faça o que o cliente espera que faça.
V & V: estabelecer a confiança de que o software está adequado ao seu propósito. Nível de confiabilidade depende de: Função do software: o quão crítico o software é para a organização (objetivo para o qual ele foi desenvolvido). Expectativas do usuário: usuário vem se tornando mais exigente e, hoje, é menos aceitável entregar sistemas não confiáveis, o que implica em maior dedicação aos processos de V&V. Ambiente de mercado: o esforço a ser empregado no processo de V&V depende de vários fatores, tais como: concorrência, preço que o cliente está disposto a pagar, cronograma.
Abordagens para a verificação e análise de sistemas do processo de V&V 
 Inspeções de software ou revisões por pares: analisam e verificam as representações do sistema (documento de requisitos, diagramas de projeto, código-fonte do programa). Podem ser aplicadas em todos os estágios do processo. São técnicas estáticas, pois não requerem que o sistema seja executado. 
Testes de software: executam uma implementação do software com os dados de teste, a fim de examinar as saídas e o comportamento operacional, verificando-se, assim, se o sistema se comporta conforme o esperado. São técnicas dinâmicas.
As revisões de requisitos e revisões de projeto são as principais técnicas usadas para detecção de erros na especificação e no projeto. Técnicas de inspeção (estáticas) podem apenas verificar a correspondência entre um programa e sua especificação, ou seja, elas não podem demonstrar que o software é útil operacionalmente, nem verificar desempenho e confiabilidade.
Formal 
specification 
High-level 
design 
Requirements 
specification 
Detailed 
design 
Program 
Prototype 
Dynamic 
validation 
Static 
verification 
Figura 1: Verificação e Validação estática e dinâmica (SOMMERVILLE, 2003)
Quanto às técnicas estáticas: 
 Incluem: inspeções de programa, análises automatizadas de código-fonte, verificação formal. 
 Podem apenas verificar a correspondência entre um programa e sua especificação. 
 Não podem: demonstrar que o software é operacionalmente útil ou checar suas características não funcionais (desempenho, confiabilidade). Quanto aos testes de software: 
 São mais utilizados, pois utilizam dados processados pelo programa (descoberta de defeitos ou inadequações, pelo exame das saídas geradas). 
 Podem ser realizados durante e após a fase de implementação. 
 Normalmente, são utilizados para validar um software, mesmo após a aplicação das inspeções.
Tipos de testes utilizados nos estágios do processo de software: 
 Teste de validação: mostrar que o software atende aos requisitos do cliente. São usados os testes estatísticos, que visam testar o desempenho e a confiabilidade do programa, além de checar como ele trabalha sob condições operacionais. Observa-se o número de falhas no sistema. O desempenho do programa é medido pelo tempo de execução e o tempo de resposta do sistema. 
 Teste de defeitos: o objetivo é revelar defeitos no sistema, encontrando inconsistências entre o programa e sua especificação. Processos de V&V: estabelecem a existência de defeitos em um sistema de software. Debbugging: é um processo que localiza e corrige esses defeitos.
Planejamento de verificação e validação V&V: processo dispendioso. É necessário planejamento cuidadoso para controlar os custos do processo de V&V e obter o máximo de inspeções e testes. Equilíbrio entre as abordagens estáticas e dinâmicas para a verificação e validação. Especificação de padrões e procedimentos para as inspeções e os testes de software. Estabelecimento de checklists para orientar as inspeções de programa. Definição do plano de teste de software.
• Tipo de sistema e a habilidade com inspeções de programas determinam o esforço dedicado às inspeções e aos testes. 
• Quanto mais crítico o sistema, mais esforço deve ser dedicado às técnicas de verificação estática.
Plano de testes Destinado aos engenheiros de software envolvidos em projetar e realizar os testes. Estabelecimento do cronograma e dos procedimentos de teste. Define os recursos de hardware e software necessários. Planejamento do processo de testes. Em processos ágeis (por exemplo, XP), o teste é inseparável do desenvolvimento. Planos de teste não são documentos estáveis, mas evoluem durante o processo de desenvolvimento (atrasos nos estágios do processo).
Estrutura do plano de testes 
1. Processo de teste: descrição das fases principais do processo de teste. 
2.Rastreabilidade de requisitos: todos os requisitos devem ser individualmente testados. 
3.Itens testados: especificação dos produtos do processo de software. 
4.Cronograma de testes: apresentar um cronograma geral de testes e alocação de recursos para ele. 
5.Procedimentos de registro de testes: trata-se do registro dos resultados dos testes. O processo de teste deve ser auditado para verificar que foi conduzido corretamente.
Estrutura do plano de testes 
6. Requisitos de hardware e de software: ferramentas de software necessárias e a utilização estimada de hardware. 
7.Restrições: o que afeta o processo de teste (por exemplo: falta de pessoal, falta de recursos).
Inspeções de software Processo de V&V estático, onde o sistema é revisto para se encontrar erros, omissões e anomalias. Objeto: código-fonte, requisitos, modelo de projeto. Principais vantagens da inspeção em relação aos testes: 
1.Basta uma sessão de inspeção para se descobrir erros em um sistema. Os testes podem levar um erro a ocultar outro e, após sua correção, caso novo erro aconteça, não se sabe se é um efeito sobre a correção, ou um erro novo. 
2.Inspeções podem acontecer em versões incompletas de um sistema, enquanto que os testes não (mais caros).
Inspeções de software 
3.Além de procurar por defeitos de programas, é possível considerar os atributos de qualidade em um programa (conformidade com padrões, portabilidade, facilidade de manutenção), ineficiências, algoritmos inapropriados, estilo de programação pobre (tais características dificultam a manutenção e a atualização de sistemas). Inspeções: idéia antiga, mas comprovadamente mais eficientes para descobrir defeitos do que os testes (+ 60% dos erros em um programa podem ser detectados por inspeções informais de programa). Revisão estática de código é mais eficiente e menos dispendiosa do que teste de defeitos no descobrimento de defeitos de programa.
Inspeções de software Revisões: uma boa aplicação é na revisão dos casos de testes para um sistema. Revisões e testes devem ser usadas em conjunto no processo de verificação e validação. Inspeções podem ser usadas no processo de desenvolvimento e, quando o sistema estiver integrado, aplica-se os testes para verificação da sua funcionalidade. Difícil a introdução de inspeções formais dentro de muitas organizações de desenvolvimento de software. Dificuldade para convencer engenheiros de software e gerentes.
Inspeções de software As inspeções de programas são revisões com o objetivo de detectar defeitos. Idéia nascida na IBM (década de 70). Inspeção: método de verificação de programa amplamente usado, especialmente na engenharia de sistemas críticos. Diversas abordagens de inspeção, porém, todas incluem equipes com diferentes experiências para reverem, linha por linha, o código-fonte do programa.
Processo formal, realizado por uma equipe de, pelo menos, quatro pessoas (podendo variar de uma inspeção para outra). Base: uma equipe com membros que apresentam diferentes experiências deve fazer uma revisão cuidadosa do código-fonte do programa.
Antes de uma inspeções de programa é necessário: 
 ter uma especificação precisa do código a ser inspecionado; 
 familiarização da equipe de inspeção com os padrões organizacionais; 
 versão atualizada do código disponível; o código deve estar completo. A inspeção deve ser um processo relativamente curto (não mais de duas horas). O responsável pelo planejamento da inspeção (moderador) seleciona a equipe de inspeção e prepara o ambiente (local e o material da inspeção). Deve identificar defeitos, anomalias e não-conformidades com padrões.
A equipe de inspeção não sugere como os defeitos devem ser corrigidos, assim como não recomenda modificações em outros componentes. O programa, após a inspeção, deve ser modificado pelo seu autor, para correção dos problemas identificados. O processo de inspeção deve ser dirigido por uma checklist de erros comuns dos programadores (específicas para cada linguagem de programação). Uma análise dos defeitos encontrados pode ser feita, após a inspeção. A quantidade de software a ser inspecionado em determinado tempo depende da experiência da equipe de inspeção, da linguagem de programação e do domínio da aplicação.
Análise estática automatizada Analisadores estáticos de programa são ferramentas de software que analisam o código-fonte de um programa e detectam possíveis defeitos e anomalias. Não requerem que o programa seja executado. Percorrem o texto do programa e reconhecem os diferentes tipos de declarações. Detecção de anomalias no programa (variáveis sem iniciação, varáveis não utilizadas, dados com valores excedidos, etc.), podendo resultar em erros de programação e de omissões). Análise estática automatizada é mais bem utilizada com as inspeções de software.
Os estágios envolvidos incluem: 
 Análise do fluxo de controle: destaca loops com múltiplos pontos de saída ou de entrada e código inacessível. 
 Análise da utilização de dados: detecta variáveis que são utilizadas sem prévia iniciação, variáveis declaradas mas nunca utilizadas, etc. 
 Análise de interface: verifica a consistência das declarações de rotinas e procedimentos e seu uso; funções e procedimentos que são declarados e nunca chamados ou resultados de funções que nunca são utilizados. 
 Análise do fluxo de informações: identifica as dependências entre as variáveis de entrada e as de saída. 
 Análise de caminho: identifica todos os caminhos possíveis no programa, e exibe as declarações executadas nesse caminho.
Desenvolvimento de software Cleanroom Filosofia de desenvolvimento de software que tem como base evitar defeitos de software pelo uso de um rigoroso processo de inspeção. Objetivo dessa abordagem: conseguir um software sem nenhum defeito. Baseia-se nas seguintes características: 
 Especificação formal: software a ser desenvolvido é formalmente especificado (modelo de transição de estado). 
 Desenvolvimento incremental: o software é decomposto em incrementos desenvolvidos e validados separadamente. 
 Programação estruturada: poucas construções abstratas de controle e de dados. Processo de refinamento da especificação.
Desenvolvimento de software Cleanroom 
 Verificação estática: utiliza rigorosas inspeções de software. 
 Teste estatístico do sistema: o incremento de software é testado estatisticamente, para determinação da sua confiabilidade. Desenvolvimento incremental no processo Cleanroom: fornecer a importante funcionalidade para o cliente nos incrementos iniciais. Processo Cleanroom é projetado para aceitar uma rigorosa inspeção do programa. O uso da abordagem tem resultado em softwares com muito pouco erros, sem parecer mais cara do que as convencionais.
A verificação estática é eficaz em termos de custo, pois os erros são descobertos antes da execução e não são introduzidos no software desenvolvido. Seu uso tem sido restrito à organizações tecnologicamente avançadas e sua adoção é relativamente pequena. Três equipes trabalham no desenvolvimento de sistema, na abordagem Cleanroom: 
 Equipe de especificação: desenvolve e mantém a especificação do sistema. 
 Equipe de desenvolvimento: desenvolve e verifica o software. 
 Equipe de certificação: desenvolve um conjunto de testes estatísticos, para testar o software depois que ele foi desenvolvido, baseados em especificação formal.
Referências SOMMERVILLE, I. Engenharia de Software. 6ª ed. São Paulo: Addison Wesley, 2003. 592p. 
SOMMERVILLE, I. Engenharia de Software. 8ª ed. São Paulo: Addison Wesley, 2007. 549p.

Mais conteúdo relacionado

Mais procurados

Testes De Software - Uma Visão Geral
Testes De Software - Uma Visão GeralTestes De Software - Uma Visão Geral
Testes De Software - Uma Visão Geral
paulo peres
 
Introdução ao Teste de Software - Uma abordagem prática
Introdução ao Teste de Software - Uma abordagem práticaIntrodução ao Teste de Software - Uma abordagem prática
Introdução ao Teste de Software - Uma abordagem prática
Fabrício Campos
 
Fundamentos de Testes de Software
Fundamentos de Testes de SoftwareFundamentos de Testes de Software
Fundamentos de Testes de Software
Álvaro Farias Pinheiro
 
Papéis em Teste e Qualidade de Software
Papéis em Teste e Qualidade de SoftwarePapéis em Teste e Qualidade de Software
Papéis em Teste e Qualidade de Software
Camilo Ribeiro
 
Introdução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade IIntrodução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade I
João Lourenço
 
Validação e Testes de software
Validação e Testes de softwareValidação e Testes de software
Validação e Testes de software
Rondinelli Mesquita
 
Uma Metodologia Para Teste De Software No Contexto Da Melhoria De Processo
Uma Metodologia Para Teste De Software No Contexto Da Melhoria De ProcessoUma Metodologia Para Teste De Software No Contexto Da Melhoria De Processo
Uma Metodologia Para Teste De Software No Contexto Da Melhoria De Processo
crc1404
 
Teste de Aceitação: problemas, desafios e abordagens
Teste de Aceitação: problemas, desafios e abordagensTeste de Aceitação: problemas, desafios e abordagens
Teste de Aceitação: problemas, desafios e abordagens
Synergia - Engenharia de Software e Sistemas
 
Gerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptxGerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptx
Roberto Nunes
 
Conceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidadeConceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidade
rzauza
 
Introdução a Automação de Teste de Software
Introdução a Automação de Teste de SoftwareIntrodução a Automação de Teste de Software
Introdução a Automação de Teste de Software
Camilo Ribeiro
 
Planejamento de Testes
Planejamento de TestesPlanejamento de Testes
Planejamento de Testes
elliando dias
 
Testes de software
Testes de softwareTestes de software
Testes de software
teste
 
Gerenciamento da Qualidade de Software 1.pptx
Gerenciamento da Qualidade de Software 1.pptxGerenciamento da Qualidade de Software 1.pptx
Gerenciamento da Qualidade de Software 1.pptx
Roberto Nunes
 
Gerenciamento da Qualidade de Software 3.pptx
Gerenciamento da Qualidade de Software 3.pptxGerenciamento da Qualidade de Software 3.pptx
Gerenciamento da Qualidade de Software 3.pptx
Roberto Nunes
 
Artigo - OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE D...
Artigo - OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE D...Artigo - OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE D...
Artigo - OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE D...
Luiz Ladeira
 
Teste de Software Introdução à Qualidade
Teste de Software Introdução à Qualidade Teste de Software Introdução à Qualidade
Teste de Software Introdução à Qualidade
Camilo Ribeiro
 
Aula - Teste de Software
Aula - Teste de SoftwareAula - Teste de Software
Aula - Teste de Software
Mauricio Cesar Santos da Purificação
 
4 engenharia de software
4   engenharia de software4   engenharia de software
4 engenharia de software
Felipe Bugov
 
Testes de Software
Testes de SoftwareTestes de Software
Testes de Software
Capgemini
 

Mais procurados (20)

Testes De Software - Uma Visão Geral
Testes De Software - Uma Visão GeralTestes De Software - Uma Visão Geral
Testes De Software - Uma Visão Geral
 
Introdução ao Teste de Software - Uma abordagem prática
Introdução ao Teste de Software - Uma abordagem práticaIntrodução ao Teste de Software - Uma abordagem prática
Introdução ao Teste de Software - Uma abordagem prática
 
Fundamentos de Testes de Software
Fundamentos de Testes de SoftwareFundamentos de Testes de Software
Fundamentos de Testes de Software
 
Papéis em Teste e Qualidade de Software
Papéis em Teste e Qualidade de SoftwarePapéis em Teste e Qualidade de Software
Papéis em Teste e Qualidade de Software
 
Introdução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade IIntrodução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade I
 
Validação e Testes de software
Validação e Testes de softwareValidação e Testes de software
Validação e Testes de software
 
Uma Metodologia Para Teste De Software No Contexto Da Melhoria De Processo
Uma Metodologia Para Teste De Software No Contexto Da Melhoria De ProcessoUma Metodologia Para Teste De Software No Contexto Da Melhoria De Processo
Uma Metodologia Para Teste De Software No Contexto Da Melhoria De Processo
 
Teste de Aceitação: problemas, desafios e abordagens
Teste de Aceitação: problemas, desafios e abordagensTeste de Aceitação: problemas, desafios e abordagens
Teste de Aceitação: problemas, desafios e abordagens
 
Gerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptxGerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptx
 
Conceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidadeConceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidade
 
Introdução a Automação de Teste de Software
Introdução a Automação de Teste de SoftwareIntrodução a Automação de Teste de Software
Introdução a Automação de Teste de Software
 
Planejamento de Testes
Planejamento de TestesPlanejamento de Testes
Planejamento de Testes
 
Testes de software
Testes de softwareTestes de software
Testes de software
 
Gerenciamento da Qualidade de Software 1.pptx
Gerenciamento da Qualidade de Software 1.pptxGerenciamento da Qualidade de Software 1.pptx
Gerenciamento da Qualidade de Software 1.pptx
 
Gerenciamento da Qualidade de Software 3.pptx
Gerenciamento da Qualidade de Software 3.pptxGerenciamento da Qualidade de Software 3.pptx
Gerenciamento da Qualidade de Software 3.pptx
 
Artigo - OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE D...
Artigo - OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE D...Artigo - OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE D...
Artigo - OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE D...
 
Teste de Software Introdução à Qualidade
Teste de Software Introdução à Qualidade Teste de Software Introdução à Qualidade
Teste de Software Introdução à Qualidade
 
Aula - Teste de Software
Aula - Teste de SoftwareAula - Teste de Software
Aula - Teste de Software
 
4 engenharia de software
4   engenharia de software4   engenharia de software
4 engenharia de software
 
Testes de Software
Testes de SoftwareTestes de Software
Testes de Software
 

Semelhante a 3 engenharia de software

Visão de Testes de Software segundo o SWEBOK
Visão de Testes de Software segundo o SWEBOKVisão de Testes de Software segundo o SWEBOK
Visão de Testes de Software segundo o SWEBOK
Mário Pravato Junior
 
Teste de software - Processo de Verificação e Validação
Teste de software - Processo de Verificação e ValidaçãoTeste de software - Processo de Verificação e Validação
Teste de software - Processo de Verificação e Validação
Joeldson Costa Damasceno
 
Aula18_V&VTesteSoftware.pdf
Aula18_V&VTesteSoftware.pdfAula18_V&VTesteSoftware.pdf
Aula18_V&VTesteSoftware.pdf
MichaelArrais1
 
Teste de Software - Introdução
Teste de Software - IntroduçãoTeste de Software - Introdução
Teste de Software - Introdução
Joeldson Costa Damasceno
 
Aula 8 - Plano de Teste.pptx
Aula 8 - Plano de Teste.pptxAula 8 - Plano de Teste.pptx
Aula 8 - Plano de Teste.pptx
AlexandreLisboadaSil
 
Eng de testes
Eng de testesEng de testes
Eng de testes
GrupoAlves - professor
 
Teste de software
Teste de softwareTeste de software
Teste de software
Claudio Eckert
 
Introdução Qualidade de Software
Introdução Qualidade de SoftwareIntrodução Qualidade de Software
Introdução Qualidade de Software
Wellington Oliveira
 
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane FidelixIntrodução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
Cris Fidelix
 
Aula09_TesteSoftware_Parte1_apremdeeghku
Aula09_TesteSoftware_Parte1_apremdeeghkuAula09_TesteSoftware_Parte1_apremdeeghku
Aula09_TesteSoftware_Parte1_apremdeeghku
MoniqueEstevo2
 
Introdução a testes de sofwtare
Introdução a testes de sofwtareIntrodução a testes de sofwtare
Introdução a testes de sofwtare
Fernando Palma
 
Palestra Teste de Software: princípios, ferramentas e carreira
Palestra Teste de Software: princípios, ferramentas e carreiraPalestra Teste de Software: princípios, ferramentas e carreira
Palestra Teste de Software: princípios, ferramentas e carreira
Taís Dall'Oca
 
SLIDEPRELIMINAR.pptx
SLIDEPRELIMINAR.pptxSLIDEPRELIMINAR.pptx
SLIDEPRELIMINAR.pptx
GustavoRondini
 
Aula07_TesteSoftware_Parte1_semResposta.pdf
Aula07_TesteSoftware_Parte1_semResposta.pdfAula07_TesteSoftware_Parte1_semResposta.pdf
Aula07_TesteSoftware_Parte1_semResposta.pdf
HoctairBernardino
 
O que é Teste de Software?
O que é Teste de Software?O que é Teste de Software?
O que é Teste de Software?
testedesoftwarepe
 
X-Zone - Garantia da Qualidade de Software
X-Zone - Garantia da Qualidade de SoftwareX-Zone - Garantia da Qualidade de Software
X-Zone - Garantia da Qualidade de Software
AlexandreBartie
 
T@rget trust curso de introdução ao processo de teste de software
T@rget trust   curso de introdução ao processo de teste de softwareT@rget trust   curso de introdução ao processo de teste de software
T@rget trust curso de introdução ao processo de teste de software
Targettrust
 
T@rget trust curso de introdução ao processo de teste de software
T@rget trust   curso de introdução ao processo de teste de softwareT@rget trust   curso de introdução ao processo de teste de software
T@rget trust curso de introdução ao processo de teste de software
Targettrust
 
Noções em teste de software e introdução a automação
Noções em teste de software e introdução a automaçãoNoções em teste de software e introdução a automação
Noções em teste de software e introdução a automação
Sandy Maciel
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
Sérgio Souza Costa
 

Semelhante a 3 engenharia de software (20)

Visão de Testes de Software segundo o SWEBOK
Visão de Testes de Software segundo o SWEBOKVisão de Testes de Software segundo o SWEBOK
Visão de Testes de Software segundo o SWEBOK
 
Teste de software - Processo de Verificação e Validação
Teste de software - Processo de Verificação e ValidaçãoTeste de software - Processo de Verificação e Validação
Teste de software - Processo de Verificação e Validação
 
Aula18_V&VTesteSoftware.pdf
Aula18_V&VTesteSoftware.pdfAula18_V&VTesteSoftware.pdf
Aula18_V&VTesteSoftware.pdf
 
Teste de Software - Introdução
Teste de Software - IntroduçãoTeste de Software - Introdução
Teste de Software - Introdução
 
Aula 8 - Plano de Teste.pptx
Aula 8 - Plano de Teste.pptxAula 8 - Plano de Teste.pptx
Aula 8 - Plano de Teste.pptx
 
Eng de testes
Eng de testesEng de testes
Eng de testes
 
Teste de software
Teste de softwareTeste de software
Teste de software
 
Introdução Qualidade de Software
Introdução Qualidade de SoftwareIntrodução Qualidade de Software
Introdução Qualidade de Software
 
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane FidelixIntrodução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
 
Aula09_TesteSoftware_Parte1_apremdeeghku
Aula09_TesteSoftware_Parte1_apremdeeghkuAula09_TesteSoftware_Parte1_apremdeeghku
Aula09_TesteSoftware_Parte1_apremdeeghku
 
Introdução a testes de sofwtare
Introdução a testes de sofwtareIntrodução a testes de sofwtare
Introdução a testes de sofwtare
 
Palestra Teste de Software: princípios, ferramentas e carreira
Palestra Teste de Software: princípios, ferramentas e carreiraPalestra Teste de Software: princípios, ferramentas e carreira
Palestra Teste de Software: princípios, ferramentas e carreira
 
SLIDEPRELIMINAR.pptx
SLIDEPRELIMINAR.pptxSLIDEPRELIMINAR.pptx
SLIDEPRELIMINAR.pptx
 
Aula07_TesteSoftware_Parte1_semResposta.pdf
Aula07_TesteSoftware_Parte1_semResposta.pdfAula07_TesteSoftware_Parte1_semResposta.pdf
Aula07_TesteSoftware_Parte1_semResposta.pdf
 
O que é Teste de Software?
O que é Teste de Software?O que é Teste de Software?
O que é Teste de Software?
 
X-Zone - Garantia da Qualidade de Software
X-Zone - Garantia da Qualidade de SoftwareX-Zone - Garantia da Qualidade de Software
X-Zone - Garantia da Qualidade de Software
 
T@rget trust curso de introdução ao processo de teste de software
T@rget trust   curso de introdução ao processo de teste de softwareT@rget trust   curso de introdução ao processo de teste de software
T@rget trust curso de introdução ao processo de teste de software
 
T@rget trust curso de introdução ao processo de teste de software
T@rget trust   curso de introdução ao processo de teste de softwareT@rget trust   curso de introdução ao processo de teste de software
T@rget trust curso de introdução ao processo de teste de software
 
Noções em teste de software e introdução a automação
Noções em teste de software e introdução a automaçãoNoções em teste de software e introdução a automação
Noções em teste de software e introdução a automação
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
 

Mais de Felipe Bugov

Conjuntos relacoes funcoes
Conjuntos relacoes funcoesConjuntos relacoes funcoes
Conjuntos relacoes funcoes
Felipe Bugov
 
Conjuntos 1
Conjuntos 1Conjuntos 1
Conjuntos 1
Felipe Bugov
 
Diagrama de venn1
Diagrama de venn1Diagrama de venn1
Diagrama de venn1
Felipe Bugov
 
Exercícios diagrama de venn
Exercícios diagrama de vennExercícios diagrama de venn
Exercícios diagrama de venn
Felipe Bugov
 
Aula de-funcao
Aula de-funcaoAula de-funcao
Aula de-funcao
Felipe Bugov
 
1 produtos notáveis
1 produtos notáveis1 produtos notáveis
1 produtos notáveis
Felipe Bugov
 
Calendário de provas 2014 Semestre 1 UNIP
Calendário de provas 2014 Semestre 1 UNIPCalendário de provas 2014 Semestre 1 UNIP
Calendário de provas 2014 Semestre 1 UNIP
Felipe Bugov
 
5 engenharia de software projetos
5   engenharia de software  projetos5   engenharia de software  projetos
5 engenharia de software projetos
Felipe Bugov
 
2 engenharia de software
2   engenharia de software2   engenharia de software
2 engenharia de software
Felipe Bugov
 
1 engenharia de software
1   engenharia de software1   engenharia de software
1 engenharia de software
Felipe Bugov
 
9 manual do sistema aps pim - versão estudantes (2012.1)
9 manual do sistema aps pim - versão estudantes (2012.1)9 manual do sistema aps pim - versão estudantes (2012.1)
9 manual do sistema aps pim - versão estudantes (2012.1)
Felipe Bugov
 
Manual de atividades_complementares_cst_v2014
Manual de atividades_complementares_cst_v2014Manual de atividades_complementares_cst_v2014
Manual de atividades_complementares_cst_v2014
Felipe Bugov
 
Manual de normalizacao
Manual de normalizacaoManual de normalizacao
Manual de normalizacao
Felipe Bugov
 
Sistema de nivelamento
Sistema de nivelamentoSistema de nivelamento
Sistema de nivelamento
Felipe Bugov
 
Manual de normalizacao
Manual de normalizacaoManual de normalizacao
Manual de normalizacao
Felipe Bugov
 
Manual de atividades_complementares_cst_v2014
Manual de atividades_complementares_cst_v2014Manual de atividades_complementares_cst_v2014
Manual de atividades_complementares_cst_v2014
Felipe Bugov
 
9 manual do sistema aps pim - versão estudantes (2012.1)
9 manual do sistema aps pim - versão estudantes (2012.1)9 manual do sistema aps pim - versão estudantes (2012.1)
9 manual do sistema aps pim - versão estudantes (2012.1)
Felipe Bugov
 

Mais de Felipe Bugov (17)

Conjuntos relacoes funcoes
Conjuntos relacoes funcoesConjuntos relacoes funcoes
Conjuntos relacoes funcoes
 
Conjuntos 1
Conjuntos 1Conjuntos 1
Conjuntos 1
 
Diagrama de venn1
Diagrama de venn1Diagrama de venn1
Diagrama de venn1
 
Exercícios diagrama de venn
Exercícios diagrama de vennExercícios diagrama de venn
Exercícios diagrama de venn
 
Aula de-funcao
Aula de-funcaoAula de-funcao
Aula de-funcao
 
1 produtos notáveis
1 produtos notáveis1 produtos notáveis
1 produtos notáveis
 
Calendário de provas 2014 Semestre 1 UNIP
Calendário de provas 2014 Semestre 1 UNIPCalendário de provas 2014 Semestre 1 UNIP
Calendário de provas 2014 Semestre 1 UNIP
 
5 engenharia de software projetos
5   engenharia de software  projetos5   engenharia de software  projetos
5 engenharia de software projetos
 
2 engenharia de software
2   engenharia de software2   engenharia de software
2 engenharia de software
 
1 engenharia de software
1   engenharia de software1   engenharia de software
1 engenharia de software
 
9 manual do sistema aps pim - versão estudantes (2012.1)
9 manual do sistema aps pim - versão estudantes (2012.1)9 manual do sistema aps pim - versão estudantes (2012.1)
9 manual do sistema aps pim - versão estudantes (2012.1)
 
Manual de atividades_complementares_cst_v2014
Manual de atividades_complementares_cst_v2014Manual de atividades_complementares_cst_v2014
Manual de atividades_complementares_cst_v2014
 
Manual de normalizacao
Manual de normalizacaoManual de normalizacao
Manual de normalizacao
 
Sistema de nivelamento
Sistema de nivelamentoSistema de nivelamento
Sistema de nivelamento
 
Manual de normalizacao
Manual de normalizacaoManual de normalizacao
Manual de normalizacao
 
Manual de atividades_complementares_cst_v2014
Manual de atividades_complementares_cst_v2014Manual de atividades_complementares_cst_v2014
Manual de atividades_complementares_cst_v2014
 
9 manual do sistema aps pim - versão estudantes (2012.1)
9 manual do sistema aps pim - versão estudantes (2012.1)9 manual do sistema aps pim - versão estudantes (2012.1)
9 manual do sistema aps pim - versão estudantes (2012.1)
 

Último

UFCD_10145_Enquadramento do setor farmacêutico_indice.pdf
UFCD_10145_Enquadramento do setor farmacêutico_indice.pdfUFCD_10145_Enquadramento do setor farmacêutico_indice.pdf
UFCD_10145_Enquadramento do setor farmacêutico_indice.pdf
Manuais Formação
 
Atividade de reforço de matemática 2º ano
Atividade de reforço de matemática 2º anoAtividade de reforço de matemática 2º ano
Atividade de reforço de matemática 2º ano
fernandacosta37763
 
UFCD_10949_Lojas e-commerce no-code_índice.pdf
UFCD_10949_Lojas e-commerce no-code_índice.pdfUFCD_10949_Lojas e-commerce no-code_índice.pdf
UFCD_10949_Lojas e-commerce no-code_índice.pdf
Manuais Formação
 
Cartinhas de solidariedade e esperança.pptx
Cartinhas de solidariedade e esperança.pptxCartinhas de solidariedade e esperança.pptx
Cartinhas de solidariedade e esperança.pptx
Zenir Carmen Bez Trombeta
 
Treinamento NR 38 - CORPO PRINCIPAL da NORMA.pptx
Treinamento NR 38 - CORPO PRINCIPAL da NORMA.pptxTreinamento NR 38 - CORPO PRINCIPAL da NORMA.pptx
Treinamento NR 38 - CORPO PRINCIPAL da NORMA.pptx
MarcosPaulo777883
 
PP Slides Lição 11, Betel, Ordenança para exercer a fé, 2Tr24.pptx
PP Slides Lição 11, Betel, Ordenança para exercer a fé, 2Tr24.pptxPP Slides Lição 11, Betel, Ordenança para exercer a fé, 2Tr24.pptx
PP Slides Lição 11, Betel, Ordenança para exercer a fé, 2Tr24.pptx
LuizHenriquedeAlmeid6
 
Aula Contrato Individual de Trabalho .pdf
Aula Contrato Individual de Trabalho .pdfAula Contrato Individual de Trabalho .pdf
Aula Contrato Individual de Trabalho .pdf
Pedro Luis Moraes
 
UFCD_4667_Preparação e confeção de molhos e fundos de cozinha_índice.pdf
UFCD_4667_Preparação e confeção de molhos e fundos de cozinha_índice.pdfUFCD_4667_Preparação e confeção de molhos e fundos de cozinha_índice.pdf
UFCD_4667_Preparação e confeção de molhos e fundos de cozinha_índice.pdf
Manuais Formação
 
epidemias endemia-pandemia-e-epidemia (1).ppt
epidemias endemia-pandemia-e-epidemia (1).pptepidemias endemia-pandemia-e-epidemia (1).ppt
epidemias endemia-pandemia-e-epidemia (1).ppt
MarceloMonteiro213738
 
A festa junina é uma tradicional festividade popular que acontece durante o m...
A festa junina é uma tradicional festividade popular que acontece durante o m...A festa junina é uma tradicional festividade popular que acontece durante o m...
A festa junina é uma tradicional festividade popular que acontece durante o m...
ANDRÉA FERREIRA
 
As sequências didáticas: práticas educativas
As sequências didáticas: práticas educativasAs sequências didáticas: práticas educativas
As sequências didáticas: práticas educativas
rloureiro1
 
497417426-conheca-os-principais-graficos-da-radiestesia-e-da-radionica.pdf
497417426-conheca-os-principais-graficos-da-radiestesia-e-da-radionica.pdf497417426-conheca-os-principais-graficos-da-radiestesia-e-da-radionica.pdf
497417426-conheca-os-principais-graficos-da-radiestesia-e-da-radionica.pdf
JoanaFigueira11
 
1ª LEI DE OHN, CARACTERISTICAS IMPORTANTES.
1ª LEI DE OHN, CARACTERISTICAS IMPORTANTES.1ª LEI DE OHN, CARACTERISTICAS IMPORTANTES.
1ª LEI DE OHN, CARACTERISTICAS IMPORTANTES.
LeticiaRochaCupaiol
 
APRESENTAÇÃO PARA AULA DE URGÊNCIA E EMERGÊNCIA
APRESENTAÇÃO PARA AULA DE URGÊNCIA E EMERGÊNCIAAPRESENTAÇÃO PARA AULA DE URGÊNCIA E EMERGÊNCIA
APRESENTAÇÃO PARA AULA DE URGÊNCIA E EMERGÊNCIA
karinenobre2033
 
Educação trabalho HQ em sala de aula uma excelente ideia
Educação  trabalho HQ em sala de aula uma excelente  ideiaEducação  trabalho HQ em sala de aula uma excelente  ideia
Educação trabalho HQ em sala de aula uma excelente ideia
joseanesouza36
 
Slides Lição 11, Central Gospel, Os Mortos Em CRISTO, 2Tr24.pptx
Slides Lição 11, Central Gospel, Os Mortos Em CRISTO, 2Tr24.pptxSlides Lição 11, Central Gospel, Os Mortos Em CRISTO, 2Tr24.pptx
Slides Lição 11, Central Gospel, Os Mortos Em CRISTO, 2Tr24.pptx
LuizHenriquedeAlmeid6
 
TUTORIAL PARA LANÇAMENTOGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
TUTORIAL PARA LANÇAMENTOGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGTUTORIAL PARA LANÇAMENTOGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
TUTORIAL PARA LANÇAMENTOGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
ProfessoraTatianaT
 
A SOCIOLOGIA E O TRABALHO: ANÁLISES E VIVÊNCIAS
A SOCIOLOGIA E O TRABALHO: ANÁLISES E VIVÊNCIASA SOCIOLOGIA E O TRABALHO: ANÁLISES E VIVÊNCIAS
A SOCIOLOGIA E O TRABALHO: ANÁLISES E VIVÊNCIAS
HisrelBlog
 
A QUESTÃO ANTROPOLÓGICA: O QUE SOMOS OU QUEM SOMOS.pdf
A QUESTÃO ANTROPOLÓGICA: O QUE SOMOS OU QUEM SOMOS.pdfA QUESTÃO ANTROPOLÓGICA: O QUE SOMOS OU QUEM SOMOS.pdf
A QUESTÃO ANTROPOLÓGICA: O QUE SOMOS OU QUEM SOMOS.pdf
AurelianoFerreirades2
 
OS elementos de uma boa Redação para o ENEM.pdf
OS elementos de uma boa Redação para o ENEM.pdfOS elementos de uma boa Redação para o ENEM.pdf
OS elementos de uma boa Redação para o ENEM.pdf
AmiltonAparecido1
 

Último (20)

UFCD_10145_Enquadramento do setor farmacêutico_indice.pdf
UFCD_10145_Enquadramento do setor farmacêutico_indice.pdfUFCD_10145_Enquadramento do setor farmacêutico_indice.pdf
UFCD_10145_Enquadramento do setor farmacêutico_indice.pdf
 
Atividade de reforço de matemática 2º ano
Atividade de reforço de matemática 2º anoAtividade de reforço de matemática 2º ano
Atividade de reforço de matemática 2º ano
 
UFCD_10949_Lojas e-commerce no-code_índice.pdf
UFCD_10949_Lojas e-commerce no-code_índice.pdfUFCD_10949_Lojas e-commerce no-code_índice.pdf
UFCD_10949_Lojas e-commerce no-code_índice.pdf
 
Cartinhas de solidariedade e esperança.pptx
Cartinhas de solidariedade e esperança.pptxCartinhas de solidariedade e esperança.pptx
Cartinhas de solidariedade e esperança.pptx
 
Treinamento NR 38 - CORPO PRINCIPAL da NORMA.pptx
Treinamento NR 38 - CORPO PRINCIPAL da NORMA.pptxTreinamento NR 38 - CORPO PRINCIPAL da NORMA.pptx
Treinamento NR 38 - CORPO PRINCIPAL da NORMA.pptx
 
PP Slides Lição 11, Betel, Ordenança para exercer a fé, 2Tr24.pptx
PP Slides Lição 11, Betel, Ordenança para exercer a fé, 2Tr24.pptxPP Slides Lição 11, Betel, Ordenança para exercer a fé, 2Tr24.pptx
PP Slides Lição 11, Betel, Ordenança para exercer a fé, 2Tr24.pptx
 
Aula Contrato Individual de Trabalho .pdf
Aula Contrato Individual de Trabalho .pdfAula Contrato Individual de Trabalho .pdf
Aula Contrato Individual de Trabalho .pdf
 
UFCD_4667_Preparação e confeção de molhos e fundos de cozinha_índice.pdf
UFCD_4667_Preparação e confeção de molhos e fundos de cozinha_índice.pdfUFCD_4667_Preparação e confeção de molhos e fundos de cozinha_índice.pdf
UFCD_4667_Preparação e confeção de molhos e fundos de cozinha_índice.pdf
 
epidemias endemia-pandemia-e-epidemia (1).ppt
epidemias endemia-pandemia-e-epidemia (1).pptepidemias endemia-pandemia-e-epidemia (1).ppt
epidemias endemia-pandemia-e-epidemia (1).ppt
 
A festa junina é uma tradicional festividade popular que acontece durante o m...
A festa junina é uma tradicional festividade popular que acontece durante o m...A festa junina é uma tradicional festividade popular que acontece durante o m...
A festa junina é uma tradicional festividade popular que acontece durante o m...
 
As sequências didáticas: práticas educativas
As sequências didáticas: práticas educativasAs sequências didáticas: práticas educativas
As sequências didáticas: práticas educativas
 
497417426-conheca-os-principais-graficos-da-radiestesia-e-da-radionica.pdf
497417426-conheca-os-principais-graficos-da-radiestesia-e-da-radionica.pdf497417426-conheca-os-principais-graficos-da-radiestesia-e-da-radionica.pdf
497417426-conheca-os-principais-graficos-da-radiestesia-e-da-radionica.pdf
 
1ª LEI DE OHN, CARACTERISTICAS IMPORTANTES.
1ª LEI DE OHN, CARACTERISTICAS IMPORTANTES.1ª LEI DE OHN, CARACTERISTICAS IMPORTANTES.
1ª LEI DE OHN, CARACTERISTICAS IMPORTANTES.
 
APRESENTAÇÃO PARA AULA DE URGÊNCIA E EMERGÊNCIA
APRESENTAÇÃO PARA AULA DE URGÊNCIA E EMERGÊNCIAAPRESENTAÇÃO PARA AULA DE URGÊNCIA E EMERGÊNCIA
APRESENTAÇÃO PARA AULA DE URGÊNCIA E EMERGÊNCIA
 
Educação trabalho HQ em sala de aula uma excelente ideia
Educação  trabalho HQ em sala de aula uma excelente  ideiaEducação  trabalho HQ em sala de aula uma excelente  ideia
Educação trabalho HQ em sala de aula uma excelente ideia
 
Slides Lição 11, Central Gospel, Os Mortos Em CRISTO, 2Tr24.pptx
Slides Lição 11, Central Gospel, Os Mortos Em CRISTO, 2Tr24.pptxSlides Lição 11, Central Gospel, Os Mortos Em CRISTO, 2Tr24.pptx
Slides Lição 11, Central Gospel, Os Mortos Em CRISTO, 2Tr24.pptx
 
TUTORIAL PARA LANÇAMENTOGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
TUTORIAL PARA LANÇAMENTOGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGTUTORIAL PARA LANÇAMENTOGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
TUTORIAL PARA LANÇAMENTOGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
 
A SOCIOLOGIA E O TRABALHO: ANÁLISES E VIVÊNCIAS
A SOCIOLOGIA E O TRABALHO: ANÁLISES E VIVÊNCIASA SOCIOLOGIA E O TRABALHO: ANÁLISES E VIVÊNCIAS
A SOCIOLOGIA E O TRABALHO: ANÁLISES E VIVÊNCIAS
 
A QUESTÃO ANTROPOLÓGICA: O QUE SOMOS OU QUEM SOMOS.pdf
A QUESTÃO ANTROPOLÓGICA: O QUE SOMOS OU QUEM SOMOS.pdfA QUESTÃO ANTROPOLÓGICA: O QUE SOMOS OU QUEM SOMOS.pdf
A QUESTÃO ANTROPOLÓGICA: O QUE SOMOS OU QUEM SOMOS.pdf
 
OS elementos de uma boa Redação para o ENEM.pdf
OS elementos de uma boa Redação para o ENEM.pdfOS elementos de uma boa Redação para o ENEM.pdf
OS elementos de uma boa Redação para o ENEM.pdf
 

3 engenharia de software

  • 1. Disciplina Engenharia de Software Processos de verificação e validação(V&V) - Métodos para Estimativas - Testes de Software Prof. Esp. Rafael H Mauro rafaelherman@yahoo.com.br
  • 2. Processos de verificação e validação (V&V)
  • 3. Verificação e Validação (V&V) Segundo (Sommerville, 2003) é o nome dado aos processos de verificação e análise, a fim de assegurar que o software cumpra com suas especificações e atenda às necessidades dos clientes que estão pagando por ele. Incluem as tarefas:  revisões dos requisitos;  revisões de projeto;  inspeções de código;  testes de produto.
  • 4. Para (Boehm, 1979), a diferença entre verificação e validação pode ser assim definida:  Validação: “estamos construindo o produto correto?”.  Verificação: “estamos construindo o produto corretamente?”. Verificação: checar se o software cumpre com suas especificações, ou seja, se o sistema cumpre com seus requisitos funcionais e não funcionais. Validação: assegurar que o software atenda às expectativas do cliente, garantindo que ele faça o que o cliente espera que faça.
  • 5. V & V: estabelecer a confiança de que o software está adequado ao seu propósito. Nível de confiabilidade depende de: Função do software: o quão crítico o software é para a organização (objetivo para o qual ele foi desenvolvido). Expectativas do usuário: usuário vem se tornando mais exigente e, hoje, é menos aceitável entregar sistemas não confiáveis, o que implica em maior dedicação aos processos de V&V. Ambiente de mercado: o esforço a ser empregado no processo de V&V depende de vários fatores, tais como: concorrência, preço que o cliente está disposto a pagar, cronograma.
  • 6. Abordagens para a verificação e análise de sistemas do processo de V&V  Inspeções de software ou revisões por pares: analisam e verificam as representações do sistema (documento de requisitos, diagramas de projeto, código-fonte do programa). Podem ser aplicadas em todos os estágios do processo. São técnicas estáticas, pois não requerem que o sistema seja executado. Testes de software: executam uma implementação do software com os dados de teste, a fim de examinar as saídas e o comportamento operacional, verificando-se, assim, se o sistema se comporta conforme o esperado. São técnicas dinâmicas.
  • 7. As revisões de requisitos e revisões de projeto são as principais técnicas usadas para detecção de erros na especificação e no projeto. Técnicas de inspeção (estáticas) podem apenas verificar a correspondência entre um programa e sua especificação, ou seja, elas não podem demonstrar que o software é útil operacionalmente, nem verificar desempenho e confiabilidade.
  • 8. Formal specification High-level design Requirements specification Detailed design Program Prototype Dynamic validation Static verification Figura 1: Verificação e Validação estática e dinâmica (SOMMERVILLE, 2003)
  • 9. Quanto às técnicas estáticas:  Incluem: inspeções de programa, análises automatizadas de código-fonte, verificação formal.  Podem apenas verificar a correspondência entre um programa e sua especificação.  Não podem: demonstrar que o software é operacionalmente útil ou checar suas características não funcionais (desempenho, confiabilidade). Quanto aos testes de software:  São mais utilizados, pois utilizam dados processados pelo programa (descoberta de defeitos ou inadequações, pelo exame das saídas geradas).  Podem ser realizados durante e após a fase de implementação.  Normalmente, são utilizados para validar um software, mesmo após a aplicação das inspeções.
  • 10. Tipos de testes utilizados nos estágios do processo de software:  Teste de validação: mostrar que o software atende aos requisitos do cliente. São usados os testes estatísticos, que visam testar o desempenho e a confiabilidade do programa, além de checar como ele trabalha sob condições operacionais. Observa-se o número de falhas no sistema. O desempenho do programa é medido pelo tempo de execução e o tempo de resposta do sistema.  Teste de defeitos: o objetivo é revelar defeitos no sistema, encontrando inconsistências entre o programa e sua especificação. Processos de V&V: estabelecem a existência de defeitos em um sistema de software. Debbugging: é um processo que localiza e corrige esses defeitos.
  • 11. Planejamento de verificação e validação V&V: processo dispendioso. É necessário planejamento cuidadoso para controlar os custos do processo de V&V e obter o máximo de inspeções e testes. Equilíbrio entre as abordagens estáticas e dinâmicas para a verificação e validação. Especificação de padrões e procedimentos para as inspeções e os testes de software. Estabelecimento de checklists para orientar as inspeções de programa. Definição do plano de teste de software.
  • 12. • Tipo de sistema e a habilidade com inspeções de programas determinam o esforço dedicado às inspeções e aos testes. • Quanto mais crítico o sistema, mais esforço deve ser dedicado às técnicas de verificação estática.
  • 13. Plano de testes Destinado aos engenheiros de software envolvidos em projetar e realizar os testes. Estabelecimento do cronograma e dos procedimentos de teste. Define os recursos de hardware e software necessários. Planejamento do processo de testes. Em processos ágeis (por exemplo, XP), o teste é inseparável do desenvolvimento. Planos de teste não são documentos estáveis, mas evoluem durante o processo de desenvolvimento (atrasos nos estágios do processo).
  • 14. Estrutura do plano de testes 1. Processo de teste: descrição das fases principais do processo de teste. 2.Rastreabilidade de requisitos: todos os requisitos devem ser individualmente testados. 3.Itens testados: especificação dos produtos do processo de software. 4.Cronograma de testes: apresentar um cronograma geral de testes e alocação de recursos para ele. 5.Procedimentos de registro de testes: trata-se do registro dos resultados dos testes. O processo de teste deve ser auditado para verificar que foi conduzido corretamente.
  • 15. Estrutura do plano de testes 6. Requisitos de hardware e de software: ferramentas de software necessárias e a utilização estimada de hardware. 7.Restrições: o que afeta o processo de teste (por exemplo: falta de pessoal, falta de recursos).
  • 16. Inspeções de software Processo de V&V estático, onde o sistema é revisto para se encontrar erros, omissões e anomalias. Objeto: código-fonte, requisitos, modelo de projeto. Principais vantagens da inspeção em relação aos testes: 1.Basta uma sessão de inspeção para se descobrir erros em um sistema. Os testes podem levar um erro a ocultar outro e, após sua correção, caso novo erro aconteça, não se sabe se é um efeito sobre a correção, ou um erro novo. 2.Inspeções podem acontecer em versões incompletas de um sistema, enquanto que os testes não (mais caros).
  • 17. Inspeções de software 3.Além de procurar por defeitos de programas, é possível considerar os atributos de qualidade em um programa (conformidade com padrões, portabilidade, facilidade de manutenção), ineficiências, algoritmos inapropriados, estilo de programação pobre (tais características dificultam a manutenção e a atualização de sistemas). Inspeções: idéia antiga, mas comprovadamente mais eficientes para descobrir defeitos do que os testes (+ 60% dos erros em um programa podem ser detectados por inspeções informais de programa). Revisão estática de código é mais eficiente e menos dispendiosa do que teste de defeitos no descobrimento de defeitos de programa.
  • 18. Inspeções de software Revisões: uma boa aplicação é na revisão dos casos de testes para um sistema. Revisões e testes devem ser usadas em conjunto no processo de verificação e validação. Inspeções podem ser usadas no processo de desenvolvimento e, quando o sistema estiver integrado, aplica-se os testes para verificação da sua funcionalidade. Difícil a introdução de inspeções formais dentro de muitas organizações de desenvolvimento de software. Dificuldade para convencer engenheiros de software e gerentes.
  • 19. Inspeções de software As inspeções de programas são revisões com o objetivo de detectar defeitos. Idéia nascida na IBM (década de 70). Inspeção: método de verificação de programa amplamente usado, especialmente na engenharia de sistemas críticos. Diversas abordagens de inspeção, porém, todas incluem equipes com diferentes experiências para reverem, linha por linha, o código-fonte do programa.
  • 20. Processo formal, realizado por uma equipe de, pelo menos, quatro pessoas (podendo variar de uma inspeção para outra). Base: uma equipe com membros que apresentam diferentes experiências deve fazer uma revisão cuidadosa do código-fonte do programa.
  • 21. Antes de uma inspeções de programa é necessário:  ter uma especificação precisa do código a ser inspecionado;  familiarização da equipe de inspeção com os padrões organizacionais;  versão atualizada do código disponível; o código deve estar completo. A inspeção deve ser um processo relativamente curto (não mais de duas horas). O responsável pelo planejamento da inspeção (moderador) seleciona a equipe de inspeção e prepara o ambiente (local e o material da inspeção). Deve identificar defeitos, anomalias e não-conformidades com padrões.
  • 22. A equipe de inspeção não sugere como os defeitos devem ser corrigidos, assim como não recomenda modificações em outros componentes. O programa, após a inspeção, deve ser modificado pelo seu autor, para correção dos problemas identificados. O processo de inspeção deve ser dirigido por uma checklist de erros comuns dos programadores (específicas para cada linguagem de programação). Uma análise dos defeitos encontrados pode ser feita, após a inspeção. A quantidade de software a ser inspecionado em determinado tempo depende da experiência da equipe de inspeção, da linguagem de programação e do domínio da aplicação.
  • 23. Análise estática automatizada Analisadores estáticos de programa são ferramentas de software que analisam o código-fonte de um programa e detectam possíveis defeitos e anomalias. Não requerem que o programa seja executado. Percorrem o texto do programa e reconhecem os diferentes tipos de declarações. Detecção de anomalias no programa (variáveis sem iniciação, varáveis não utilizadas, dados com valores excedidos, etc.), podendo resultar em erros de programação e de omissões). Análise estática automatizada é mais bem utilizada com as inspeções de software.
  • 24. Os estágios envolvidos incluem:  Análise do fluxo de controle: destaca loops com múltiplos pontos de saída ou de entrada e código inacessível.  Análise da utilização de dados: detecta variáveis que são utilizadas sem prévia iniciação, variáveis declaradas mas nunca utilizadas, etc.  Análise de interface: verifica a consistência das declarações de rotinas e procedimentos e seu uso; funções e procedimentos que são declarados e nunca chamados ou resultados de funções que nunca são utilizados.  Análise do fluxo de informações: identifica as dependências entre as variáveis de entrada e as de saída.  Análise de caminho: identifica todos os caminhos possíveis no programa, e exibe as declarações executadas nesse caminho.
  • 25. Desenvolvimento de software Cleanroom Filosofia de desenvolvimento de software que tem como base evitar defeitos de software pelo uso de um rigoroso processo de inspeção. Objetivo dessa abordagem: conseguir um software sem nenhum defeito. Baseia-se nas seguintes características:  Especificação formal: software a ser desenvolvido é formalmente especificado (modelo de transição de estado).  Desenvolvimento incremental: o software é decomposto em incrementos desenvolvidos e validados separadamente.  Programação estruturada: poucas construções abstratas de controle e de dados. Processo de refinamento da especificação.
  • 26. Desenvolvimento de software Cleanroom  Verificação estática: utiliza rigorosas inspeções de software.  Teste estatístico do sistema: o incremento de software é testado estatisticamente, para determinação da sua confiabilidade. Desenvolvimento incremental no processo Cleanroom: fornecer a importante funcionalidade para o cliente nos incrementos iniciais. Processo Cleanroom é projetado para aceitar uma rigorosa inspeção do programa. O uso da abordagem tem resultado em softwares com muito pouco erros, sem parecer mais cara do que as convencionais.
  • 27. A verificação estática é eficaz em termos de custo, pois os erros são descobertos antes da execução e não são introduzidos no software desenvolvido. Seu uso tem sido restrito à organizações tecnologicamente avançadas e sua adoção é relativamente pequena. Três equipes trabalham no desenvolvimento de sistema, na abordagem Cleanroom:  Equipe de especificação: desenvolve e mantém a especificação do sistema.  Equipe de desenvolvimento: desenvolve e verifica o software.  Equipe de certificação: desenvolve um conjunto de testes estatísticos, para testar o software depois que ele foi desenvolvido, baseados em especificação formal.
  • 28. Referências SOMMERVILLE, I. Engenharia de Software. 6ª ed. São Paulo: Addison Wesley, 2003. 592p. SOMMERVILLE, I. Engenharia de Software. 8ª ed. São Paulo: Addison Wesley, 2007. 549p.