VALIDAÇÃO, VERIFICAÇÃO E TESTES

Aluno: Robson de Souza MeloDisciplina: Engenharia de softwareProfessora: Monalessa Perini Barcellos

HISTÓRICO As fases

Até 1956 – Orientada a depuraçãoNão existia diferença entre depuração e teste;

1957-1978 – Orientada a demonstraçõesFoco era mostrar o comportamento esperado

1979-1982 – Orientada a “destruição”Foco era achar problemas

1983-1987 – Orientada a avaliaçãoFoco no processo e em garantia de qualidade

1988-2000 – Orientada a prevençãoFoco em detectar e prevenir problemas

HISTÓRICO As fases

2000-atual – Fusão: Foco em fundir os processos de desenvolvimento e testes;

Bug do ano 2000 (Y2K Bug)Testes começaram a ser levados a sério por conta daameaça do Y2K;

Como garantir que após as correções de datas, tudoficaria funcionando corretamente;

O novo bug do milênio: o bug de 2038;

DEFINIÇÕES Validação:

“Estamos construindo o produto certo?”

Verificação: “Estamos construindo corretamente o produto? ”

Teste: Examina o comportamento do produto através

de sua execução.

DEFINIÇÕES Defeito:

deficiência mecânica ou algorítmica que se ativada pode levar a uma falha.

Erro: item de informação ou estado de execução

inconsistente.

Falha: evento notável onde o sistema viola suas

especificações.

BUG

DEFINIÇÕES

OBJETIVO DAS TÉCNICAS VV&T O objetivo é garantir que tanto o processo de

desenvolvimento quanto o produto de software atinjam altos níveis de qualidade;

Objetivos da verificação e validação Mostrar que o software atende a sua especificação; Mostrar que o software atende as necessidades do

cliente;

Teste é a principal técnica de V&V;

Técnicas de inspeção e revisão também são usadas;

ANÁLISE ESTÁTICA E ANÁLISE DINÂMICA Estática

Compreende métodos usados para determinar ou estimar qualidade de software, que não envolvem a execução do produto;

Dinâmica Compreende métodos que envolvem execução

do produto com dados reais e ambiente real ou simulado;

QUANDO TESTAR? Deve-se testar o software somente quando

se tem código executável;

Mito!!! Testar é muito mais do que apenas “ver o que

vai acontecer”;

Documentos de requisitos podem e devem ser testados em relação aos objetivos do negócio ou projeto para assegurar completude e correção;

MODELO EM V

MODELO EM V

EVOLUÇÃO DO BUG

CRITÉRIOS DE VERIFICAÇÃO Consistência

Os requisitos estão consistentes? Clareza

Os requisitos estão claramente detalhados? Testabilidade

Os requisitos são testáveis? Segurança

Os requisitos de segurança estão especificados?

VERIFICAÇÃO – SEGUNDO CMMI E MPSBR Verificação – Práticas Específicas:

SG1 – Preparação para Verificação SP1.1-1 Seleção de produtos; SP1.2-2 Estabelecer ambiente; SP1.3-3 Estabelecer procedimentos e critérios;

SG2 – Executar revisões. SP2.1-1 Preparar revisões; SP2.2-1 Conduzir revisões; SP2.3-2 Analisar dados da revisão;

SG3 – Verificação de artefatos selecionados. SP3.1-1 Executar verificação; SP3.2-2 Analisar resultados e identificar ação corretiva;

VERIFICAÇÃO – SEGUNDO CMMI E MPSBR Verificação – Práticas Genéricas:

GG 3 Institucionalizar um Processo Definido GP 2.1 Estabelecer uma política organizacional; GP 2.2 Planejar processos; GP 2.3 Providenciar recursos; GP 2.4 Definir responsabilidades; GP 2.5 Treinar pessoas; GP 2.6 Gerenciar configurações; GP 2.7 Identificar e envolver stakeholders; GP 2.8 Monitorar e controlar processos; GP 2.9 Avaliação objetiva da adesão; GP 2.10 Revisar status com alta gerência; GP 3.1 Estabelecer um processo definido; GP 3.2 Coletar informações de melhorias;

VERIFICAÇÃO FORMAL Utiliza especificação formal;

utilização de linguagem matemática para descrever precisamente o comportamento de um software;

Técnicas de Verificação formal Verificação de modelos (Model Checking); Prova por teorema (Theorem Proving);

MÉTODOS PARA ESPECIFICAÇÃO FORMAL ASM;

B-Method;

Linguagem Z;

ASM - ABSTRACT STATE MACHINE Especificação executável baseada em

modelo; Utiliza os conceitos de estados, transições e

suas regras; O estado é composto por vocabulário que

consiste em um conjunto de nomes de funções e relações;

transição, é controlada por uma regra que altera o estado;

Na execução da máquina de estado, a regra de transição é executada diversas vezes, modificando o estado atual a cada iteração;

ASM – EXEMPLO

ASM - VANTAGENS Utilização de estruturas matemáticas para

gera especificações precisas;

Fácil aprendizado, aplicação e interpretação;

Aplicabilidade em diversos domínios como sistemas sequenciais e de tempo real;

B-METHOD transforma o Documento de Especificação de

Software em código executável; a verificação dos artefatos é realizada por

meio de provas matemáticas; invariant preservation proof; proof of correct refinement;

Possui 3 fases: Detalhes são extraídos da especificação e

transformados em um Modelo Abstrato; Construção do Modelo Concreto; O Modelo Concreto é traduzido para Código

Executável

B-METHOD – FASES

B-METHOD – EXEMPLO

LINGUAGEM Z tem como bases teóricas:

O axioma da teoria de conjuntos; Cálculus lambda; Lógica de predicado de primeira ordem;

A notação modulariza a especificação em esquemas (scheme);

módulos descrevem aspectos estáticos e dinâmicos do sistema;

scheme consiste em duas partes: superior, onde são declaradas as variáveis; inferior, onde são definidas as relações entre os

valores das variáveis;

LINGUAGEM Z - NOTAÇÕES operação’: indica o resultado da operação

sobre o estado inicial, ou seja, o estado final. Δ Esquema: Indica mudança no estado. Ξ Esquema: Indica que o estado não muda. variável?: Indica que “variável” receberá

entrada. variável!: Indica que “variável” gerará saída. “ᴖ” que indica concatenação de dois objetos; Apóstrofo (’) representando o estado

seguinte do componente; “#” representando a contagem de

elementos.

LINGUAGEM Z - EXEMPLO

VERIFICAÇÃO POR MODELO (MODEL CHECKING) Técnica automática de verificação Formal;

Verifica se um modelo formal satisfaz a sua especificação;

O modelo de sistema e a especificação devem ser formulado em uma linguagem formal precisa;

VERIFICADOR DE MODELO Instrumento que executa uma tarefa de

controle dado ao sistema para verificar sua especificação;

Tipos: Modelos que exigem linguagens de entrada

dedicados para esta tarefa; Extraem o modelo diretamente do código fonte;

A verificação é feita de forma totalmente automática;

VERIFICAÇÃO POR MODELO modelagem:

constrói uma abstração do sistema sendo analisado;

Possivelmente executa simulações para validar o modelo;

especificação: especifica as propriedades desejadas do modelo

em um formalismo adequado; verificação com um verificador de modelo:

executa exploração exaustiva de todos os possíveis comportamentos;

um contraexemplo é produzido sempre que o modelo não satisfaz a especificação;

VERIFICADOR DE MODELO

VERIFICAÇÃO POR MODELO - VANTAGENS processo completamente automático;

pode ser usado para executar verificação parcial;

termina com uma resposta sim/não;

traces do erro são informativos;

lógicas usadas para especificação podem expressar várias propriedades dos sistemas;

VERIFICAÇÃO POR MODELO - DESVANTAGENS problema da explosão do espaço de estado;

quando o sistema sendo verificado tem vários componentes de interação, ou estruturas de dados com vários possíveis valores;

tradicionalmente somente funciona para sistemas de estado finito;

PROVA POR TEOREMA - THEOREM PROVING Utiliza inferências lógicas para verificar o

grau de correção do sistema;

Pode ser realizada na totalidade do sistema ou limitada às partes mais críticas;

São realizados testes exaustivos em todos os estados possíveis do sistema, geralmente verificando propriedades não funcionais;

PROVA POR TEOREMA - THEOREM PROVING Os Provadores de Teoremas Automáticos

Utilizam lógica de primeira ordem e relativamente pouca interferência humana

Assistentes de Provas utilizam lógicas de ordem superior e necessitam

de maior interferência do usuário; Usuário fornece de forma manual as fórmulas

(hipóteses e axiomas) e o código ou modelo executável para que o algoritmo realize a verificação;

Necessita de usuários experientes;

PROVA POR TEOREMA - THEOREM PROVING A aplicação do método vai desde a prova de

teoremas matemáticos até a verificação de software;

Realiza a validação de algoritmos de criptografia e protocolos de comunicação;

Porém, a maior utilização da prova por teorema se dá na verificação de projetos de hardware;

PROVA POR TEOREMA - THEOREM PROVING Provadores automáticos:

Otter, SETHEO, Vampire e SPASS,

Assistêntes de prova: ACL2, Coq, Isabelle e JAPE

VERIFICAÇÃO INFORMAL Conjunto de técnicas estáticas que visam

analisar os artefatos gerados durante o desenvolvimento;

Inspeção de software;

Leitura de software: Perspective-Based Reading (PBR); Object-Oriented Reading Techniques (OORT); Usage-Based Reading (UBR); Metric-Based Reading (MBR);

INSPEÇÃO DE SOFTWARE Características

Técnica preventiva - permite a V & V antes do software ser codificado;

Mais barata; Baseada na experiência do inspetor; Mais aplicada a fatores de revisão e transição; Pouco eficaz para fatores operacionais;

APLICAÇÕES MAIS COMUM DA INSPEÇÃO DE SOFTWARE Inspeção de programa fonte (estática e

dinâmica);

Inspeção de documentos e modelos;

Desenvolvimento Cleanroom;

Walkthrough;

INSPEÇÃO

Ian Sommerville, 2007

INSPEÇÃO

DESENVOLVIMENTO CLEANROOM Filosofia de desenvolvimento que tem como

base evitar defeitos pelo uso de um rigoroso processo de inspeção;

Objetivo: Conseguir um software sem nenhum defeito;

Processo de desenvolvimento baseado em: Especificação formal. Desenvolvimento incremental. Programação estruturada. Verificação estática usando rigorosas inspeções

de software. Teste estatístico do sistema.

PROCESSO DESENVOLVIMENTO CLEANROOM

WALKTHROUGH Reuniões informais para avaliação dos

produtos;

Pouca ou nenhuma preparação requerida;

O desenvolvedor guia os presentes através do produto;

O objetivo é comunicar ou receber aprovação;

São úteis principalmente para requisitos e modelos.

WALKTHROUGH

VANTAGENS DA INSPEÇÃO Muitos defeitos diferentes podem ser

descobertos em uma única inspeção; Um teste revela um defeito, mas pode ocultar

vários;

Versões incompletas do sistema podem ser inspecionadas;

Permite encontrar problemas em outros atributos de qualidade do software; Uso de um algoritmos mais eficiente, padrão de

projeto, etc.;

LIMITAÇÕES DE INSPEÇÃO Inspeção não é adequada;

Para demonstrar se o software é útil; Para verificar requisitos não funcionais, como

desempenho, segurança, etc.;

Não permite validar com o cliente; Somente verifica a correspondência entre a

especificação e o software;

TÉCNICAS DE LEITURA Surgiram como forma de melhorar o desempenho da

inspeção de software;

É uma série de passos para a análise individual de um artefato permitindo a extração de informações;

Requisitos para uma técnica de leitura: Estar associada a um tipo de artefato e a notação pela qual o

artefato é descrito Ser adaptável as características da organização e do

desenvolvimento; ser detalhada, provendo ao desenvolvedor um processo bem

definido. Ser avaliada experimentalmente para determinar sua

viabilidade e seu grau de efetividade na detecção de defeitos.

TÉCNICAS DE LEITURA – TIPOS DE DEFEITOS ENCONTRADOS Omissão:

Algum requisito importante não foi incluído; Não está definida a resposta para todas as possíveis

entradas de dados; Faltam seções no documento de requisitos; Faltam referências de figuras, tabelas, e diagramas; Falta definição de termos e unidades de medidas.

Ambigüidade: Um requisito tem várias interpretações dependendo

do contexto; Inconsistência:

Requisitos são conflitantes e não se consegue identificar qual requisito é verdadeiro;

TÉCNICAS DE LEITURA – TIPOS DE DEFEITOS ENCONTRADOS Fato Incorreto:

Um requisito descreve um fato que não é verdadeiro;

Informação Estranha: As informações fornecidas no requisito não são

necessárias ou mesmo usadas;

Outros defeitos como a inclusão de um requisito numa seção errada do documento.

PBR (PERSPECTIVE-BASED READING) Elaborada inicialmente para a detecção de

defeitos em documentos de requisitos escritos em linguagem natural;

Estendida para inspeções de projeto e código-fonte;

Auxilia a detecção de defeitos observando quais informações possuem maior relevância para as diferentes formas de utilização do documento;

PBR (PERSPECTIVE-BASED READING) Em um modelo de ciclo de vida de software,

podemos esperar que o documento de requisitos tenha três usos principais: Base para a construção do modelo de projeto; Base para a elaboração do plano de teste do

sistema; Descrição das funcionalidades do sistema;

PBR (PERSPECTIVE-BASED READING) Fornece um procedimento para que cada

revisor avalie segundo uma dessas perspectivas;

Orienta o revisor a criar um modelo físico com base nos requisitos;

Fornece um conjunto de questões ajustadas para cada passo do procedimento de criação do modelo;

Se os requisitos não fornecem informações suficientes para responder às questões significa não são suficientes para apoiar o usuário dos requisitos;

PBR (PERSPECTIVE-BASED READING)

Massa e Travassos, 2006

Utiliza duas dimensões: Leitura horizontal e vertical;

Leitura horizontal: Diferentes diagramas de projeto são verificados

para assegurar que estejam consistentes entre si.

Leitura vertical: É necessária a validação dos modelos de projeto,

para assegurar que o projeto do sistema está correto com relação aos requisitos.

OORT’S - (OBJECT-ORIENTED READING TECHNIQUES)

OORT’S - (OBJECT-ORIENTED READING TECHNIQUES)

Mafra e Travassos, 2005

UBR (USAGE-BASED READING) Detecta defeitos severos do ponto de vista do

usuário;

Leitura orientada por casos ordenados pela importância para o usuário do sistema;

A premissa básica é permitir que as expectativas do usuário governem a inspeção;

os revisores leriam o documento executando manualmente os casos de uso e tentando detectar defeitos;

PBR X UBR PBR UBR

Na PBR os revisores desenvolvem casos de uso baseados no documento de requisitos de forma a detectarem defeitos.

Em UBR os casos de uso são utilizados como guias para os artefatos inspecionados;

PBR tem como objetivo melhorar a efetividade da inspeção ao minimizar a sobreposição entre os defeitos encontrados pelos diferentes revisores;

O objetivo de UBR é melhorar a eficiência e a efetividade ao direcionar os esforços de inspeção para os casos de uso mais importantes;

Os cenários de PBR são genéricos, ou seja, os cenários desenvolvidos para um tipo de artefato podem ser utilizados para todos os artefatos do mesmo tipo.

Os cenários UBR são específicos para cada projeto. Entretanto, poderiam ser utilizados para inspeções de requisitos, projeto e código e apoiar a especificação de teste;

MBR (METRIC-BASED READING) Técnica de leitura para detecção de defeitos

em modelos de casos de uso; MBR adota um conjunto de heurísticas para

orientar os revisores a detectarem defeitos em modelos de casos de uso;

A premissa por trás das heurísticas é que os valores de certas métricas de casos de uso podem ser vistos como potenciais indicadores de defeitos;

Cada heurística apresenta uma faixa de valores onde, valores fora dessa faixa, seriam indícios de prováveis defeitos nos modelos de caso de uso;

CRITÉRIOS DE VALIDAÇÃO Usabilidade

O produto está intuitivo? Tempo de resposta

O produto executa a tarefa em menos de 1s? Desempenho

O sistema sobrecarrega o computador? Portabilidade

O produto executa em mais de um SO?

VALIDAÇÃO SEGUNDO CMMI E MPSBR Práticas Específicas:

SG1 – Preparação para Validação; SP1.1-1 Seleção de produtos; SP1.2-2 Estabelecer ambiente; SP1.3-3 Estabelecer procedimentos e critérios;

SG2 – Validação dos produtos ou componentes SP2.1-1 Execução da validação; SP2.2-1 Analise dos resultados;

VALIDAÇÃO SEGUNDO CMMI E MPSBR Validação – Práticas Genéricas:

GG 3 Institucionalizar um Processo Definido; GP 2.1 Estabelecer uma política organizacional; GP 2.2 Planejar processos; GP 2.3 Providenciar recursos; GP 2.4 Definir responsabilidades; GP 2.5 Treinar pessoas; GP 2.6 Gerenciar configurações; GP 2.7 Identificar e envolver stakeholders; GP 2.8 Monitorar e controlar processos; GP 2.9 Avaliação objetiva da adesão; GP 2.10 Revisar status com alta gerência; GP 3.1 Estabelecer um processo definido; GP 3.2 Coletar informações de melhorias;

TESTE X DEPURAÇÃO Teste:

Processo de executar um software ou sistema com o objetivo de revelar a presença de falhas;

Depuração: É uma consequência não previsível do teste.

Após revelada a presença do erro, o defeito deve ser encontrado e corrigido;

PROCESSO DE DEPURAÇÃO

PROCESSO DE TESTE Planejamento: São definidos os tipos de teste

realizados e as expectativas com relação aos testes;

Especificação: São gerados os modelos de teste dos quais são derivados os casos de teste;

Construção: Os artefatos necessários para execução do teste são criados: Os casos de teste e os oráculos identificados na

etapa anterior são implementados utilizando-se alguma linguagem de programação.

PROCESSO DE TESTE Execução: São executados os casos de teste

desenvolvidos para o sistema na etapa anterior, sendo fornecidos os dados selecionados na etapa de especificação;

Análise dos Resultados: Os oráculos gerados na construção são utilizados para analisar se o programa testado falhou ou não no teste;

TESTES

TESTES

PADRÃO DE TESTES

ITENS DE UM PLANO DE TESTESItens de um Plano de

TesteConteúdo

1. Introdução Identifica o projeto, descreve os objetivos do documento, o público destino e escopo do projeto, termos e abreviações usadas, e como o plano deve evoluir.

2. Requisitos a serem testados

descreve o conjunto de requisitos a serem testados e o que deve ser verificado.

3. Estratégias e ferramentas de teste

Conjunto de tipos de testes a serem realizados. Técnicas empregadas. Critério de finalização de teste. Conjunto de ferramentas utilizadas.

ITENS DE UM PLANO DE TESTESItens de um Plano de

TesteConteúdo

4. Equipe e infra-estrutura

Descrição da equipe e da infra-estrutura utilizada incluindo: pessoal, equipamentos, software de apoio, materiais, dentre outros.

5. Cronograma de atividades

Descreve os marcos importantes das atividades. Por exemplo: projeto de testes, execução de testes ou avaliação de testes.

6. Documentação complementar

Apresenta-se uma relação dos documentos pertinentes ao projeto.

CASOS DE TESTES Especificação de uma entrada para o

programa e a correspondente saída esperada Entrada: conjunto de dados necessários para

uma execução do programa; Saída esperada: resultado de uma execução do

programa;

Um bom caso de teste tem alta probabilidade de revelar um erro ainda não descoberto;

CASOS DE TESTES Heumann propôs uma metodologia de

geração de casos de teste a partir dos casos de uso;

O processo é composto por três passos: geração de cenários; Identificação dos casos de teste; Identificação dos valores que serão usados nos

casos de teste;

GERAÇÃO DE CENÁRIOS Apartir da leitura da descrição do caso de

uso, cria-se uma tabela com todos os cenários possíveis para a execução do caso de uso;

GERAÇÃO DE CENÁRIOS

PARTICIONAMENTO DE EQUIVALÊNCIA A ideia é particionar as entradas em grupos

com comportamento similar;

É necessário testar apenas uma condição de cada partição;

Partições válidas e inválidas são consideradas;

Decompor o programa em funções;

PARTICIONAMENTO DE EQUIVALÊNCIA Identificar as variáveis que determinam o

comportamento de cada função

Particionar os valores de cada variável em classes de equivalência (válidas e inválidas);

Especificar os casos de teste: eliminar as classes impossíveis ou os casos

desinteressantes; selecionar casos de testes cobrindo as classes

válidas das diferentes variáveis; para cada classe inválida escolha um caso de teste

que cubra 1 e somente 1 de cada vez;

PARTICIONAMENTO DE EQUIVALÊNCIA

ANÁLISE DE VALOR LIMITE Limites são áreas onde os testes estão mais

propensos a indicar defeitos;

Os valores limites de uma partição são seu máximo e seu mínimo;

PARTICIONAMENTO EM CLASSES DE EQUIVALÊNCIA Divide-se o domínio de entrada de um

programa em classes de equivalência válidas e inválidas;

Seleciona-se o menor número de testes possível que seja capaz de representar todas as classes;

O particionamento permite examinar os requisitos e restringir o número de casos de teste existentes;

CASOS DE TESTE - COMPOSIÇÃO Entradas:

Condição Inicial: assegura a condição inicial para que o caso de teste possa ser executado;

Passos: passos a serem executados, identificados pelos métodos de teste.

Saídas: Resultados esperados: respostas esperadas

do sistema, para a entrada atual; Pós-condição: representa o estado final do

sistema.

CASOS DE TESTE Pode ser feito:

Analisando os cenários; revendo a descrição textual dos casos de uso;

Deve existir pelo menos um caso de teste para cada cenário, mas provavelmente existirão mais;

Construir uma matriz identificando os cenários e a validade dos dados, também incluindo a resposta esperada;

CASOS DE TESTE

Tipo de Teste Descrição

Teste de Unidade

Teste em um nível de componente ou classe. É o teste cujo objetivo é um “pedaço do código”.

Teste de Integração

Garante que um ou mais componentes combinados (ou unidades) funcionam. Podemos dizer que um teste de integração é composto por diversos testes de unidade.

Teste Operacional

Garante que a aplicação pode rodar muito tempo sem falhar.

Teste Positivo-negativo

Garante que a aplicação vai funcionar no “caminho feliz” de sua execução e vai funcionar no seu fluxo de exceção.

Tipo de Teste Descrição

Teste de regressão

Toda vez que algo for mudado, deve ser testada toda a aplicação novamente.

Teste de caixa-preta

Testar todas as entradas e saídas desejadas. Não se está preocupado com o código, cada saída indesejada é visto como um erro.

Teste caixa-branca

O objetivo é testar o código. Às vezes, existem partes do código que nunca foram testadas.

Tipo de Teste DescriçãoTeste Funcional Testar as funcionalidades, requerimentos,

regras de negócio presentes na documentação. Validar as funcionalidades descritas na documentação.

Teste de Interface

Verifica se a navegabilidade e os objetivos da tela funcionam como especificados e se atendem da melhor forma ao usuário.

Teste de Performance

Verifica se o tempo de resposta é o desejado para o momento de utilização da aplicação.

Teste de carga Verifica o funcionamento da aplicação com a utilização de uma quantidade grande de usuários simultâneos.

Tipo de Teste Descrição

Teste de aceitação do usuário

Testa se a solução será bem vista pelo usuário. Ex: caso exista um botão pequeno demais para executar uma função, isso deve ser criticado em fase de testes;

Teste de Volume

Testar a quantidade de dados envolvidos;

Testes de stressTestar a aplicação sem situações inesperadas. Testar caminhos, às vezes, antes não previstos no desenvolvimento/documentação.

Testes de Configuração

Testar se a aplicação funciona corretamente em diferentes ambientes de hardware ou de software.

Tipo de Teste Descrição

Testes de Instalação

Testar se a instalação da aplicação foi OK.

Testes de Segurança

Testar a segurança da aplicação das mais diversas formas. Utilizar os diversos papéis, perfis, permissões, para navegar no sistema.

CONCLUSÕES As atividades de VV&T quando aplicadas

corretamente colaboram consideravelmente com a qualidade e confiabilidade do software;

VV&T devem ser aplicadas desde o início do desenvolvimento do software;

Existem uma gama muito grande de técnicas de VV&T, a escolha da melhor técnica vai depender do ambiente e do tipo do projeto;

CONCLUSÕES Quanto antes um defeito for encontrado

menos custoso será a remoção deste defeito;

Deve-se equilibrar os testes de software para que não seja gasto tempo desnecessário com testes, porém sem deixar de garantir que os testes tenha grande cobertura;

REFERENCIAS ALMEIDA, G. T. De; NETO, M. M. F.; RAMOS, B. a; CARVALHO, J. S.; BARCELOS,

M. R. S.; SILVA, S. V; VASCONCELOS, A. P. V. De. Apoio aos Processos de Gerência de Requisitos e Verificação e Validação em um Ambiente Integrado. Workshop Anual do MPS (WAMPS), n. 2003, p. 176–183, 2011.

ANAND, S.; BURKE, E. K.; CHEN, T. Y.; CLARK, J.; COHEN, M. B.; GRIESKAMP, W.; HARMAN, M.; HARROLD, M. J.; MCMINN, P. An orchestrated survey of methodologies for automated software test case generation. Journal of Systems and Software, v. 86, n. 8, p. 1978–2001, 2013.

ANDERSSON, C.; RUNESON, P. Verification and validation in industry — A qualitative survey on the state of practiceInternational Symposium Empirical Software Engineering, 2002. .

BARBOSA, D. L. Um Método Automático de Teste Funcional para a Verificação de Componentes Daniel Lima Barbosa. 2005.

BARBOSA, E. F.; VINCENZI, A. M. R.; DELAMARO, M. E.; MALDONADO, J. C. Teste Estrutural e de Muta��o no Contexto de Programas {OO}. IV Escola Regional de Informática de Minas Gerais, p. 313–362, 2005.

REFERENCIAS BARROS, R. P. Evolução , Avaliação e Validação do Software RoboEduc Evolução ,

Avaliação e Validação do Software RoboEduc Renata Pitta Barros. 2011.

BOZKURT, M.; HARMAN, M. Testing & Verification In Service-Oriented Architecture : A Survey. v. 7, p. 1–7, 2009.

CRESPO, A. N.; SILVA, O. J. Da; BORGES, C. A.; SALVIANO, C. F.; TEIVE, M. De; JUNIOR, A.; JINO, M. Uma Metodologia para Teste de Software no Contexto da Melhoria de Processo. n. Simpósio Brasileiro de Qualidade de Software, p. 271–285, 2004.

DELAMARO, M. E.; MALDONADO, J. C.; JINO, M. Introdução Ao Teste De Software. p. 394, 2007.

FERREIRA, B.; MOITA, G. F.; ALMEIDA, P. E. M.; BORGES, H. E. UMA PROPOSTA DE TÉCNICA POR INSPEÇÃO PARA VALIDAÇÃO DE PROCESSO DE DESENVOLVIMENTO DE SOFTWAREX Encontro de Modelagem ComputacionalRio de Janeiro-RJ: IME, 2009.

FRANZEN, M. B.; BELLINI, C. G. P. Arte Ou Prática Em Teste De Software? Revista Eletrônica de Administração, v. 11, n. 3, p. 1–25, 2013.

REFERENCIAS GARCIA, R. E. exploratória para apoio a estudos experimentais em verificação

, validação e teste de software ViDA ESE : processo de visualização exploratória para apoio a estudos experimentais em verificação , validação e teste de software. p. 163, 2006.

LUNA, S.; LOPES, A.; TAO, H. Y. S.; ZAPATA, F.; PINEDA, R. Integration, verification, validation, test, and evaluation (IVVT&E) framework for system of systems (SoS). Procedia Computer Science, v. 20, n. 2005, p. 298–305, 2013.

MAFRA, S. N.; TRAVASSOS, G. H. Técnicas de Leitura de Software : Uma Revisão Sistemática. XIX Simpósio Brasileiro de Engenharia de Software, SBES, 5., 2005.

MARTIMIANO, L. A. F. Estudo de Técnicas de Teste de Regressão Baseado em

Mutação Seletiva. 1999.

MARUCCI, R. A.; FABBRI, S. C. P. F.; MALDONADO, J. C.; TRAVASSOS, G. H. OORTs / ProDeS : Definição de Técnicas de Leitura para um Processo de Software Orientado a Objetos. n. May, 2016.

REFERENCIAS MURRELL, S.; T. PLANT, R. A survey of tools for the validation and verification

of knowledge-based systems: 1985–1995. Decision Support Systems, v. 21, n. 4, p. 307–323, 1997. Disponível em: <http://www.sciencedirect.com/science/article/pii/S016792369700047X>.

NETO, A.; CLAUDIO, D. Introdução a teste de Software. Revista Engenharia de Software Edição …, p. 1–59, 2012

SILVA, A. C. Jogo educacional para apoiar o ensino de técnicas para elaboração de testes de unidade. 2010.

TERRA, R.; BIGONHA, R. S. Ferramentas para análise estática de códigos Java, 2008. .

THÜM, T.; APEL, S.; KÄSTNER, C.; SCHAEFER, I.; SAAKE, G. A Classification and Survey of Analysis Strategies for Software Product Lines. ACM Computing Surveys (CSUR), v. 47, n. 1, p. 1–45, 2014.

REFERENCIAS TROVÃO, J. D. C. Especificação de processos de apoio gerencial ao processo

de testes de software. v. 8, n. 2, p. 210, 2014.

http://www.methode-b.com/en/b-the-different-languages/

Mafra, Sômulo Nogueira, and Guilherme Horta Travassos. "Leitura Baseada em Perspectiva: A Visão do Projetista Orientada a Objetos." V Simpósio Brasileiro de Qualidade de Software, Vila Velha-ES (2006).