Avaliação de Software: Histórico e Importância

Prévia do material em texto

www.professormarco.com.br 
Avaliação de Software 
Professora: SHEILA DE GOES MONTEIRO 
Nos dias de hoje, onde a tecnologia avança rapidamente e as empresas precisam mudar numa velocidade nunca 
dantes imaginada é fundamental que o software tenha qualidade de forma que possa evoluir, ser alterado mas sem 
comprometer a sua estrutura e funcionamento. Soma-se a isso a complexidade e atuais níveis de integração das 
funções dos softwares. 
Esse cenário levou as empresas a buscarem alternativas para melhorar a qualidade do software que produzem. Uma 
dessas alternativas foi o aprimoramento dos processos de desenvolvimento de software, onde foram inseridos 
procedimentos de avaliação, o que inclui, por exemplo, procedimentos de teste de software. 
Uma das premissas para que o software possa ser mantido e alterado ao longo do tempo é a qualidade com que foi 
desenvolvido. desta forma temos que atestar a qualidade não só do software mas principalmente de seu processo 
de desenvolvimento de todos os artefatos gerados. 
A disciplina visa apresentar os métodos e técnicas usados pelos profissionais de TI, para avaliar a eficácia e eficiencia 
de um software, através de metodologias de avaliação e validação de software. 
1 - Compreender o histórico das atividades de testes no processo de desenvolvimento de software desde 1960 até os dias atuais. 
2 - Entender a importância do processo de software contemplar atividades de testes. 
3 - Compreender o conceito de qualidade de software em seu sentido mais amplo. 
4 - Compreender a importância na realização de teses por todas as fases do processo de desenvolvimento. 
No início do desenvolvimento, quando só existia a função de programador e que era exercida por poucos, não 
haviam atividades de testes. Na verdade não havia nem processo definido de desenvolvimento de software. 
Na medida em que os erros ocorriam, após o software estar pronto, o próprio programador percorria o código para 
solução dos erros. 
Os testes aconteciam com o próprio usuário. 
Somente na década de 70, quando os conceitos de engenharia de software emergiram sendo adotados como 
modelo para as universidades é que os primeiros procedimentos de testes, muito tímidos, começaram a ser usados, 
porém havia pouco consenso sobre o que viria a ser teste. 
Regra de 10 de Myers 
Por volta de 1979, Myers produziu um dos primeiros trabalhos mais completos e profundos trabalho sobre um 
processo de teste de software. Myers é o autor do livro "The Art of Software Testing", considerado por muitos 
como a primeira obra de real valor sobre teste de software e a criadora de termos muito usados como 'Caixa Branca 
e Caixa Preta" e "Caso de Teste". Myers também ficou conhecido pela regra 10 de Myers.
 
A Regra 10 de Myers mostra que quanto mais tarde os defeitos forem encontrados tanto mais caro será corrigi-los. 
Nos anos 80 começou a surgir o conceito de Qualidade de software, onde o processo de desenvolvimento já estava 
sendo estruturado em fases e os testes aconteciam desde o inicio. Muitas organizações e padrões surgiram nesta 
época, mas o que ganhou maior dimensão e importância para as organizações de software foi o modelo 
CMM(Compability Maturity Model), elaborado pelo SEI(Software Engeneering Institute) . 
Nos anos 90 as ferramentas de teste começaram a ser produzidas e determinados tipos de testes que antes não 
eram possíveis de serem executados, tornaram-se uma realidade e trazendo alta produtividade e qualidade no 
processo de teste. 
Cenário Atual do Desenvolvimento de Software 
Sistemas de software tornam-se cada vez mais parte do nosso dia-a-dia, desde aplicações comerciais (ex: bancos) até 
produtos de consumo (ex: carros). Com a globalização a integração entre matriz-filiais, fornecedores e clientes torna-
se uma realidade e os sistemas além de complexos demandam grande integração entre suas diversas 
funcionalidades que devem atender a toda a empresa, de forma unificada. 
Neste contexto, a maioria das pessoas já teve alguma experiência com um software que não funcionou como 
esperado. Softwares que não funcionam corretamente podem levar a muitos problemas, incluindo financeiro, 
tempo e reputação das empresas. Podem inclusive, chegar a influenciar na integridade das pessoas. 
Consequentemente o conceito de teste ganha complexidade, pois os riscos dos softwares não funcionarem a 
contento, cresce de forma exponencial. Ainda assim poucas empresas percebem que a implantação de um processo 
de garantia de qualidade de software é uma questão de estratégia de sobrevivência em um mercado cada vez mais 
exigente e competitivo. 
Apresentamos ao lado a evolução do processo de qualidade e de teste de software (Bartié, 2002) 
 
 
Qualidade do software e processo 
Todas as decisões tomadas durante o processo de desenvolvimento do software pode comprometer sua qualidade 
final. 
Se desejarmos produzir software com qualidade, é necessário investir em qualidade em todos os pontos do 
processo. 
A qualidade de software é um processo sistemático que focaliza todas as etapas e artefatos gerados com objetivo de 
garantir a conformidade e uniformidade de processos e produtos, prevenindo e eliminado defeitos. 
A partir de processos uniformes e consistentes a tendência é que o produto final gerado, ou seja, o software seja 
eficiente. Softwares mal testados geram prejuízos as empresas, como: 
• Re-trabalho, aumentando o custo do projeto. 
• Informações erradas que podem originar decisões equivocadas. 
• Insatisfação dos usuários. 
Assim, podemos concluir que é impossível obter um software com qualidade com processos de desenvolvimento 
ineficientes. Não é possível estabelecer um processo de garantia de qualidade que não enfoque simultaneamente o 
produto tecnológico e o processo de desenvolvimento desse software. Desta forma podemos estabelecer duas 
dimensões para obtenção da qualidade: 
Qualidade do processo=Na dimensão da qualidade do processo, a qualidade deve existir desde o início, ou seja, já 
na fase de análise de requisitos, quando acontece o levantamento de requisitos. O quanto antes detectarmos 
problemas, mas facilmente e com menos custo eles serão resolvidos. Entretanto poucas empresas percebem com 
clareza e implementam atividades para essa dimensão. É importante salientar que a qualidade nos processos é 
primordial e será aplicada em documentos e modelos gerados por cada fase que compõe o processo de 
desenvolvimento usado pela empresa. Este é o desafio, garantir a qualidade de um software, ou seja, estabelecendo 
uma cultura de não tolerância a erros através de processos estruturados por mecanismos de inibição e 
impedimentos de falhas. Desta forma os diversos artefatos gerados durante o ciclo de desenvolvimento tenham 
procedimentos que avaliam sua qualidade, possibilitando a identificação prematura de defeitos nesses artefatos. 
Nesta dimensão de qualidade, ou seja a qualidade do processo pode ser medida através de testes aplicados nos 
documentos gerados em cada fase do ciclo de desenvolvimento do software através de testes chamados de testes 
de verificação ou testes estáticos. 
Garantia da qualidade do processo = Garantia da qualidade dos documentos produzidos em cada etapa do 
desenvolvimento 
Qualidade do Produto=Nesta dimensão o objetivo principal é a garantia da qualidade do produto tecnológico 
gerado durante o ciclo de desenvolvimento. Esta dimensão é muitas vezes negligenciada por parte das empresas 
devido a problemas de cronogramas com o cliente. Apesar de empregada nas organizações, o grau de eficiência das 
atividades relacionadas a esta dimensão ainda é baixa. Para o teste do produto, obviamente, existe a necessidade de 
uma instância do sistema implementada, em parte ou na totalidade. Assim a qualidade do produto é garantida com 
a aplicação de testes sistemáticos nos vários estágios de desenvolvimento. Nesta dimensão a qualidade pode ser 
medida através da aplicação de testeschamados de testes de software ou testes de validação ou ainda testes 
dinâmicos. 
 
o software é testado para revelar erros cometidos inadvertidamente quando o software foi produzido e construído. 
"processo sistemático e planejado que tem por finalidade única a identificação de erros.” 
O conceito de testes 
Por conta desta definição de teste é importante ressaltar que a equipe de qualidade, ou de testes, deve ser o mais 
independente possível da equipe de desenvolvimento de forma a não estar envolvida emocionalmente nem 
politicamente com o projeto, tendo um comportamento mais objetivo e direto. Esta equipe terá mais facilidade em 
focar nos pontos que inicialmente o projeto deveria atender e por motivos desconhecidos foram abandonados ou 
não atendidos corretamente. Devemos levar em consideração que os testes podem ser usados para mostrar a 
presença de erros, porém não conseguirá cobrir todas as infinitas combinações existentes em um ambiente de 
execução real. 
A qualidade de um software é definida pelo número de requisitos que foram adequadamente testados e estão em 
conformidade com o especificado. 
Consequentemente é fundamental que haja documentação e modelos, conforme definido no processo de 
desenvolvimento adotado pela empresa. Sem documentação não pode haver testes de verificação e o teste de 
validação fica comprometido, pois como os testadores poderão conhecer os requisitos e o funcionamento previsto 
do software? 
Myers concluiu que zero-defeito é algo inatingível? Ou seja, pela complexidade envolvida e pelo número altíssimo de 
situações existentes, torna-se impossível imaginar um produto de software “livre de erros”. Sempre existirão erros a 
serem descobertos. 
A qualidade de software trabalha com o conceito de zero-defeito, ou seja, representa a não tolerância a erros. O 
objetivo é definir um processo que contenha mecanismos de inibição de defeitos, impedimento de que falhas sejam 
criadas e propagadas para as fases seguintes. Todo o processo é desenhado para minimizar a incidência de 
problemas. 
 
 
Os Pilares da qualidade de software 
Todo erro custa dinheiro. Podemos entender que o custo da qualidade é todo o investimento realizado com a 
finalidade de um produto ou serviço atingir a qualidade desejada. Estes custos estão relacionado aos: 
Custos da Conformidade = Significa o esforço para garantir a qualidade. São todos os investimentos realizados para 
planejar e manter toda uma infra-estrutra de pessoas, processos e ferramentas cujo objetivo seja prevenir e 
detectar. 
Custos da não-conformidade = Está relacionado aos defeitos e suas correções. São todos os custos de atividades 
ligadas ao esforço de reparar falhas de produtos originados no decorrer do processo de desenvolvimento. 
A implantação de um processo de qualidade tanto no processo, como no produto tem um custo, porém é vantajosa, 
pois quanto mais tardiamente os erros forem descobertos, mais cara custa a solução. 
Para Myers quanto mais tardiamente descobrimos os erros, mais caros eles ficam. Segundo a regra 10 de Myers, 
significa que quando um erro não é identificado, os custos de sua correção multiplicam-se por 10 para cada fase do 
processo de desenvolvimento de software em que o erro migra, conforme podemos observar no gráfico ao lado. 
Por isso os testes de verificação, ao longo do processo de desenvolvimento tornam-se uma ajuda na redução dos 
custos de qualidade: detectam o problema antes de ser implementado. 
 
Nesta aula, você: 
 Compreendeu o histórico das atividades de testes no processo de desenvolvimento de software desde 1960 
até os dias atuais. 
 Entendeu a importância do processo de software contemplar atividades de testes. 
 Compreendeu o conceito de qualidade de software em seu sentido mais amplo. 
 Estudou a importância na realização de teses por todas as fases do processo de desenvolvimento, 
garantindo que cada etapa esta sendo efetivada com eficiência. 
 
• Histórico das atividades de testes no processo de desenvolvimento de software 
• Cenário Atual do Desenvolvimento de Software 
• Regra 10 de Meyers 
• A realidade dos projetos atuais 
• O conceito de qualidade de software 
• Incidência de ocorrência de defeitos 
• Qualidade do software e do processo 
• O conceito de teste 
• Os pilares da qualidade de software 
• Os custos da Qualidade ( conformidade e não conformidade) 
• A implantação 
• Nesta aula, você irá: 
 
1 - Identificar e reconhecer testes de verificação e testes de validação. 
• 2 - Relacionar as etapas dos testes de verificação e as etapas nos testes de validação. 
• 3 - Identificar os principais problemas que derivam da implantação inadequada de processos de desenvolvimento de 
software. 
Como já vimos na aula anterior o controle da qualidade é um processo contínuo e sistêmico de acompanhamento da 
eficiência do desenvolvimento do software em relação aos requisitos propostos. 
Normalmente temos uma tendência a pensar o desenvolvimento de software como uma linha de tempo na qual 
todas as etapas serão cumpridas e que existe uma etapa específica para a realização dos testes. 
Modelo de negócios  Requisitos  Análise e modelagem  Implementação  Testes de Software  
Disponibilização 
 
 
 
 
Momentos do processo de desenvolvimento de software 
O processo de desenvolvimento de software é dividido em dois momentos que possuem características diferentes e 
consequentemente necessitam de métodos de avaliação também diferentes: 
Teste de Verificação: É a coleta de informações de negócios e o planejamento da arquitetura do software. Nesta 
fase a principal preocupação é o entendimento e a coerência entre o negócio a ser atendido e o software a ser 
construído. Nesta fase não existem componentes tecnológicos, mas documentos que especificam o comportamento 
a ser seguido pelo software a ser desenvolvido. 
Teste de validação: Esta fase caracteriza-se pela existência de um componente computacional (seja em parte ou um 
todo da solução). 
Os testes de verificação e validação são complementares, não devendo ser encarados como atividades redundantes. 
Cada um possui natureza e objetivo distinto, fortalecendo desta forma o processo de detecção de erros e 
aumentando a qualidade final do produto. 
 
Testes de Verificação 
Processo de auditoria de atividades e avaliação de documentos gerados em todas as fases do processo de 
desenvolvimentos do software. Não envolve o processamento de softwares, pois não existe uma encarnação deste 
ainda. Os testes de verificação serão aplicados respeitando os estágios do desenvolvimento: 
1. Modelo de Negócios = Verificação de Negócios 
2. Especificação de Requisitos = Verificação de Requisitos 
3. Análise e Modelagem = Verificação, Análise de Modelagem 
4. Implementação = Verificação da Implementação. 
 
 
Testes de Validação 
O que é? Processo formal de avaliação de produtos tecnológicos que podem ser aplicado em componentes isolados, 
módulos existentes ou mesmo a totalidade do sistema. 
Objetivo - O objetivo é avaliar a conformidade do software com os requisitos e especificações analisadas e 
revisadas nas etapas iniciais do projeto. 
Característica - Caracteriza-se pela presença física do software e de seu processamento em um ambiente 
tecnicamente preparado. As validações serão aplicadas respeitando os estágios de desenvolvimento. 
Os testes são baseados no comportamento do software através de simulações de diversas condições baseadas e 
comparadas com as especificações levantadas pela área de negócio. 
Durante o desenvolvimento do software serão aplicadas diferentes categorias de testes utilizando ferramentas, 
técnicas e abordagens diferentes. 
As atividades de teste (planejamento, modelagem, execução e conferência) deverão ocorrer em paralelo às 
atividades de construção de componentes executáveis e respeitando os estágios de desenvolvimento. 
 
Validação da unidade 
A validação de unidade éa primeira etapa do processo de validação que tem por objetivo testar componentes 
individuais de um aplicação. 
Validade da Integração 
A validade da integração é uma continuação natural dos testes unitários. Estes têm por objetivo validar a 
compatibilidade entre componentes de um software. 
Validação do sistema 
A validação do sistema tem como objetivo validar a solução como um todo. Quando este estágio é atingido a maior 
parte das falhas de funcionalidade deve ter sido detectada pelos testes unitários e pelos testes de integrações. 
Validação do aceite 
A validação do aceite é o último estágio do processo de validação. Trata-se do último processo formal de detecção 
de erros no sistema, antes de sua disponibilização no ambiente de produção. Nesta etapa o software é 
disponibilizado para o clientes e usuários com o objetivo de estes validarem todas as funcionalidades requisitadas no 
inicio do projeto. 
 
 
 
 
 
 
 
 
 
 
 
Nesta aula, você: 
 Identificou e reconheceu testes de verificação e testes de validação. 
 Relacionou as etapas dos testes de verificação e as etapas nos testes de validação. 
 Identificou os principais problemas que derivam da implantação inadequada de processos de desenvolvimento de 
software. 
 
1. 
 O objetivo desta fase é garantir que os diversos documentos produzidos tenham total aderência às necessidades 
apontadas pelos clientes. Estamos nos referindo à fase de: 
 1) Verificação de negócio 
 2) Validação de requisitos 
 3) Verificação da implementação 
 4) Validação da análise e modelagem 
 5) Verificação da unidade 
 1 
 2. 
 Trata-se do último processo formal de detecção de erros no sistema, antes de sua disponibilização no ambiente de 
produção. Estamos nos referindo à fase de: 
 1) Validação do aceite 
 2) Validação de requisitos 
 3) Verificação da implementação 
 4) Validação integração 
 5) Verificação da unidade 
 1 
 3. 
 A fase que trata da avaliação da aderência da solução tecnológica aos requisitos funcionais e não funcionais 
estabelecidos pelo cliente, chama-se: 
 1) Verificação da análise e modelagem 
 2) Validação de requisitos 
 3) Verificação da implementação 
 4) Validação integração 
 5) Verificação da unidade 
 1 
 
Nesta aula, você irá: 
 
1 - Diferenciar os principais métodos de testes de verificação. 
2 - Conhecer a aplicação e funcionamento das revisões e suas modalidades. 
3 - Entender a aplicação e funcionamento das auditorias. 
4 - Compreender a aplicação e funcionamento do Processo de verificação. 
5 - Aprender a aplicação e funcionamento do check list na verificação . 
 
 
Testes de Verificação 
Como já estudamos na aula anterior e ainda segundo Bartié (2002), os testes de verificação devem garantir a 
qualidade de todas as etapas do desenvolvimento de sistemas. Neste sentido a qualidade será obtida através da 
correta construção de documentos e a adequada realização das atividades previstas no processo corporativo de 
engenharia de software. Desta forma os testes de verificação devem concentra-se em dois aspectos bem distintos: 
 
Revisões Técnicas 
À medida que os softwares são desenvolvidos é possível que ocorram erros. AS revisões técnicas são o mecanismo 
mais efetivo para descobrir erros antes que sejam passados para os usuários finais. Por isso são utilizadas logo no 
início do processo de gestão de qualidade. 
É um processo "humano" de análise de determinado documento e consequentemente um processo subjetivo e 
passível de falhas. Este processo requer pessoas adequadamente treinadas para desempenhar seus papéis durante a 
condução das atividades de verificação. 
Por que são importantes? 
Ao se descobrir um erro logo no início do processo, fica menos caro corrigi-lo. Nós já estudamos isso através da regra 
10 de Myers, lembra? Assim devemos levar em consideração que os erros podem aumentar à medida que o 
processo continua. Um erro relativamente insignificante, sem tratamento no início do processo, pode ser ampliado 
e se transformar em um conjunto de erros graves para a sequência do projeto. As revisões minimizam o tempo de 
desenvolvimento do software devido à redução do número de reformulações que serão necessárias ao longo do 
projeto. 
Existem diferentes técnicas de revisão e cada uma delas apresenta características e um tipo de aplicação. Para cada 
fase do processo de criação de documentos, conforme a figura abaixo, podemos aplicar um tipo de revisão 
diferente: 
 
Revisões Isoladas 
Esse método de verificação é muito eficiente apesar de pouco explorado, na detecção prematura de erros de 
definições e soluções registradas. Seu objetivo principal é antecipar a revisão de documento com entregas de 
versões ainda não acabadas para que possam ser analisados os tópicos já abordados, são realizadas validações 
parciais do documento. Desta forma possibilita correções nos documentos durante sua fase de concepção. 
Neste caso, a ação dos revisores é isolada, sendo normalmente utilizado um único revisor que proporá as 
modificações necessárias. O grande problema desta técnica é que o autor pode ter uma visão de conjunto mais 
apurada que o revisor já que a utilização de único revisor poderá propor mudanças que prejudiquem uma visão 
integrada do problema. 
Revisões Formais 
 
As revisões formais exigem uma equipe multidisciplinar de profissionais de forma que as decisões sejam analisadas 
por diversos ângulos. É fundamental documentar tudo o que foi discutido, os principais problemas detectados, suas 
correções e as sugestões de melhoria. Esta documentação é produzida pela equipe de qualidade e posteriormente 
apresentada aos autores do documento para realização das modificações e posteriormente submetido a uma nova 
revisão. Normalmente em um processo de revisão podemos ter as seguintes fases: 
 
 
 
Reunião de Acompanhamento 
As reuniões de acompanhamento é a forma de verificação menor formal do que as reuniões de revisão, já que não 
necessita de uma adequada preparação por parte dos participantes. Neste caso somente o apresentador que 
normalmente é o autor do documento prepara-se para a reunião enquanto o demais participantes simplesmente 
comparecem. 
O Objetivo desta reunião não é a detecção de erros e sim democratizar as informações entre todos os participantes, 
o que permite envolver um número maior de pessoas que podem colaborar no processo de desenvolvimento do 
software. A dinâmica normalmente utilizada é a distribuição do material a todos os participantes para que possam 
realizar a análise antecipada dos documentos e que posteriormente em reunião pré-agendada todos poderão 
debater dúvidas e divergências existentes. 
Auditorias 
Segundo Bartié( 2002), a auditorias concentram-se nas atividades críticas de um processo de engenharia de 
software. Seu objetivo de uma auditoria de qualidade é avaliar se: 
1. Um determinado projeto e as diversas equipes estão respeitando o processo de desenvolvimento; 
2. Se estão registrando os defeitos encontrados 
3. Se estão produzindo as atas de reuniões 
4. Se estão realizando as reuniões de revisões, 
5. Se estão realizando as documentações obrigatórias 
6. Se estão atualizando o mapa de riscos dos projetos 
7. E se estão envolvendo clientes e usuários nos processos 
Enfim eles verificam todo o processo e devem estar atentos caso alguma atividade previamente definida não esteja 
sendo respeitada. 
Aplicação do processo de verificação 
O processo de validação requer um conjunto de procedimentos e regras, dentre várias possibilidades, que auxiliarão 
as equipes de qualidade na verificação: Planejar mão de obra e tarefas de cada um; Preparar o pessoal de forma que 
recebam o máximo de material sobre o tema em questão; Verificar os documentos; Aplicar check-list nas 
verificações. 
 
Aplicação do processo de verificação 
A figura apresentada mostra um modelo de referência, onde sãoidentificadas quatro características que contribuem 
para a formalidade na qual o processo de verificação deve ser conduzido: 
As verificações devem ser aplicadas com um nível de formalidade apropriado para o produto a ser construído, a 
cronologia do projeto e as pessoas que estão realizando o trabalho. 
A formalidade do processo está relacionada a fatores como a maturidade do processo de desenvolvimento, 
requisitos legais e reguladores ou a necessidade de acompanhamento de auditoria. O modo como o processo é 
conduzido depende do seu objetivo (ex: encontrar defeitos, obter compreensão, discussão ou decisões por um 
consenso) e do tipo de verificação a ser realizada: reuniões isoladas, reuniões formais, reuniões de 
acompanhamento e auditorias. 
 
As fases dos Testes de Verificação 
Cada etapa do processo de desenvolvimento cumpre uma etapa e produz documentos e/ou modelos pertinentes a 
finalidade da fase. A etapa de verificação é fundamental no processo, pois desde as fases iniciais pode-se aferir a 
qualidade do processo e não deixar que problemas sejam migrados para as fases seguintes. Nesta aula estudaremos 
como proceder as verificações pertinentes para cada fase do processo de desenvolvimento de software: 
 
Fase de Negócio 
Nesta fase estabelecemos o primeiro contato com as necessidades, expectativas e exigências dos clientes. Através 
da modelagem de negócios poderemos criar uma macro visão da extensão do projeto e os seus principais objetivos . 
Recursos humanos, físicos e financeiros. 
 
O objetivo da verificação nesta fase é garantir que os documentos produzidos tenham aderência às necessidades 
apontadas pelos clientes. É importante o exercício de revisão destes documentos com o próprio cliente. 
 
O que verificar nesta fase? 
- Avaliar se todas as necessidades, metas e exigências foram listadas; 
- Verificar se a modelagem de negócios cobre todas as necessidades; 
- Conferir se as projeções realizadas são baseadas em métricas e indicadores confiáveis; 
- Avaliar a existência de alternativas a essa solução; 
- Avaliar o retorno sobre o investimento em cada alternativa existente (ROI); 
- Validar as opções de investimento (árvore de decisão). 
Checklist 
Como já visto anteriormente, o checklist é um importante instrumento que auxilia revisores e auditores no processo 
de verificação. Na figura abaixo um exemplo de Checklist do Modelo de Negócios. 
 
Fase de Requisitos 
Esta fase tem a missão de detalhar todos os aspectos funcionais e não funcionais relativos à solução a ser construída. 
O conjunto de especificações de negócio serão, nesta fase, detalhados em seu nível máximo, deverão ser apontados 
todos os aspectos a serem implementados. Vale lembrar aqui, que o sucesso de qualquer projeto de software 
depende desta fase, pois esta fase direcionará todas as fases posteriores do desenvolvimento de software e 
estabelecem um escopo para o produto final. 
 
Nesta fase os revisores deverão concentrar-se na identificação de todos os requisitos funcionais e não funcionais 
definidos nesta fase. Cabe aos revisores verificar os requisitos e garantir a adequada definição de cada um. Clique 
aqui e saiba o que verificar nessa fase. 
Fase de análise e modelagem 
Nesta etapa o objetivo é definir uma solução tecnológica que suporte além dos requisitos estabelecidos pelo cliente, 
os requisitos de qualidade que deverão ser atendidos pela arquitetura do software a ser modelada. Flexibilidade, 
escalabilidade e ser reutilizável. 
 
Nesta fase as revisões possibilitam validar os aspectos críticos da solução proposta, através da revisão da arquitetura 
proposta. Clique aqui e saiba o que verificar nessa fase. 
Fase de implementação 
Nesta fase toda a documentação produzida nas fases anteriores serão transformadas em código de uma 
determinada linguagem de desenvolvimento. O objetivo da verificação nesta fase é garantir que a qualidade do 
código-fonte gerado pela equipe de desenvolvimento, o que pode ser verificado através das “boas práticas de 
programação” garantidas através da adoção de normas e padrões corporativos seguidos pela equipe de 
desenvolvimento. 
 
Nesta aula, você aprendeu: 
 Os principais métodos de testes de verificação. 
 A aplicação e funcionamento das revisões e suas modalidades. 
 A aplicação e funcionamento das auditorias. 
 A aplicação e funcionamento do Processo de verificação. 
 A aplicação e funcionamento do check list na verificação. 
Na próxima aula, abordaremos o tema: Conceituação dos Testes de Validação 
 Assunto1. Compreender o conceito de teste de validação e quando aplicar. 
 Assunto 2. Compreender as estratégias de testes e caixa branca e caixa preta. 
 Assunto 3. Relacionar as abordagens existentes para testes: baseados na estrutura interna e nos requisitos. 
 Assunto 4. Identificar os conceitos de progressividade e regressividade dos testes. 
 
1. 
 Quais as fases onde o teste de verificação normalmente é aplicado? 
 1) Especificação do negócio, análise dos requisitos, Modelagem, implementação e teste 
 2) Especificação dos requisitos, arquitetura do sistema, implementação e Homologação 
 3) Modelagem do negócio, Especificação de Requisitos, Análise e modelagem e implementação 
 4) Análise do negócio, análise de requisitos, modelagem e implementação 
 5) Modelagem do negócio, modelagem de requisitos, Análise e implementação 
 3 
 2. 
 Qual a fase do processo de desenvolvimento de software em que toda a documentação produzida 
nas fases anteriores serão transformadas em código de uma determinada linguagem de 
desenvolvimento? 
 1) Implementação 
 2) Verificação 
 3) Modelagem 
 4) Documentação 
 5) Validação 
 1 
 3. 
 Sobre a técnica de Reunião Formal é correto afirmar que: 
 1) Forma de verificação menos formal, já que não necessita de uma adequada preparação por parte dos 
participantes 
 2) Normalmente nesta técnica é utilizado um único revisor que proporá as modificações necessárias 
 3) Baseiam-se em reuniões com um grupo de profissionais responsáveis em identificar falhas presentes em 
documentos gerados nas diversas etapas do desenvolvimento 
 4) Verificam todo o processo de desenvolvimento de software com o objetivo de verificar se alguma atividade 
previamente definida não esteja sendo respeitada 
 5) Forma de verificação para medir se o cliente ficou satisfeito com o produto produzido 
 3 
 
 
Aula 04: Conceituação dos Testes de Validação 
Nesta aula, você irá: 
 
1 - Compreender o conceito de teste de validação e quando aplicar; 
2 - Compreender as estratégias de testes e caixa branca e caixa preta; 
3 - Relacionar as abordagens existentes para testes: baseados na estrutura interna e nos requisitos; 
4 - Identificar os conceitos de progressividade e regressividade dos testes. 
Testes de Validação 
Na aula passada estudamos os testes de verificação que avaliavam as documentações, nesta aula iremos estudar os 
testes de validação. Este tipo de teste está focado na aplicação, pois neste momento do processo de 
desenvolvimento já temos um produto computacional. Seu principal objetivo é identificar o maior número possível 
de erros tanto nos componentes isolados quanto na solução como um todo e por isso o sucesso do teste de 
validação está apoiado no forte planejamento de todas as atividades de testes. 
Estratégias de Testes – Caixa Branca e Caixa Preta 
A estratégia de teste de software fornece um conjunto de etapas a serem executadas como parte do teste. Deve 
incorporar o planejamento dos testes, projeto de casos de teste, coleta e avaliação dos dados resultantes, ou seja, 
deve fornecer diretrizes para o profissional de teste e uma série de metas para o cliente, deve possibilitar medir o 
progresso no desenvolvimento e revelar os problemas o mais breve possível. 
Existem basicamente duas estratégias utilizadas para conduzir o processo de validação de software: 
Testede CAIXA BRANCA 
O teste da caixa-branca, também conhecido como teste da caixa-de-vidro, é baseado na arquitetura interna do 
software e utiliza a estrutura de controle descrita no programa para derivar casos teste. São empregadas técnicas 
que avaliam as estrutura de sequência, decisão e repetição, através da simulação de situações que exercitem todas 
as estruturas utilizadas na codificação adequadamente. 
Para a realização dos testes de caixa-branca, é necessário que o profissional de teste conheça toda a tecnologia 
empregada pelo software (linguagem de programação, arquitetura do software, banco de dados), pois são testes 
altamente eficientes na detecção dos erros, porém são difíceis de serem empregados. 
A finalidade dos testes de caixa-branca é encontrar o menor número de casos de teste que permita que todos os 
comandos de um programa sejam executados pelo menos uma vez. 
Dica 
Você sabe o que é caso de teste? É o documento que registra todo o planejamento dos testes e o que será testado. 
Deve identificar o maior número cenários e variações possíveis, assim como os resultados esperados. 
Os casos de teste no teste de caixa branca são determinados a partir das estruturas de controle do programa, 
conforme a figura abaixo, com o objetivo de forçar que todos os caminhos possíveis do fluxo de controle do 
programa sejam percorridos durante os testes. A idéia é que o profissional de teste consiga identificar o maior 
número possível de cenários de testes que atendam ao maior número possível de situações. 
 
É possível criar casos de teste que: 
Garantam que todos os caminhos independentes de um módulo foram exercitados pelo menos uma vez; 
Exercitam todas as decisões lógicas nos seus estados verdadeiros e falsos; 
Executam todos os ciclos em seus limites e dentro de suas fronteiras operacionais; 
Exercitam estruturas de dados internas para assegurar sua validade. 
Teste de CAIXA PRETA 
O teste da caixa preta, também conhecido como teste comportamental, focaliza os requisitos funcionais do software 
e utiliza técnicas para garantir que os requisitos do sistema sejam amplamente atendidos pelo software construído. 
Este tipo de teste complementa o teste da caixa branca permitindo descobrir uma classe de erros diferentes daquela 
obtida com métodos da caixa-branca. Diferentemente aos testes da caixa-branca, o teste da caixa-preta não requer 
o conhecimento da tecnologia empregada e dos conceitos de implementação do software. 
 
É necessário que o profissional de testes conheça os requisitos, suas características e comportamentos esperados, 
para que o software seja avaliado através dos resultados gerados pela aplicação. Neste caso quanto maior a 
variedade de cenários, maior será o conjunto de simulações que serão avaliadas e comparadas com os requisitos da 
aplicação, implementados através da construção de casos de testes. 
 Os testes de caixa preta são realizados para responder as seguintes perguntas: 
• Como a validade funcional é testada? 
• Como o comportamento e o desempenho do sistema é testado? 
• Que classes de entrada farão bons casos de teste? 
• O sistema é particularmente sensível a certos valores de entrada? 
• Como as fronteiras de uma classe dedados é isolada? 
• Que taxas e volumes de dados o sistema pode tolerar? 
• Que efeito combinações específicas de dados terão sobre a operação do sistema? 
E tentam encontrar erros nas seguintes categorias: Funções incorretas ou faltando; Erros de interface; Erros em 
estruturas de dados ou acesso a bases de dados externas; Erros de comportamento ou de desempenho; Erros de 
inicialização e término. 
Estas estratégias não são excludentes, muito pelo contrário, são complementares. 
Abordagens dos Testes 
 
Testes baseados na estrutura interna 
Nessa abordagem, os testes requerem conhecimento profundo da tecnologia empregada e do projeto desenvolvido, 
de forma a exercitarem adequadamente todas as estruturas internas do projeto. Este tipo de teste requer que o 
testador tenha um amplo conhecimento interno do software e subdivide-se em: 
Teste de fluxos de Dados: Este método seleciona caminhos de teste de um programa de acordo com as localizações 
de definições e usos de variáveis no programa. São úteis para selecionar caminhos de teste de um programa que 
contenha instruções de laços e if aninhadas. Uma vez que as instruções de um programa relacionam-se entre si de 
acordo com as definições e usos de variáveis, a abordagem de teste de fluxo de dados é eficiente para a proteção 
contra erros. 
Teste de Condição: O teste de condição, segundo Pressman, é um método de projeto de caso de teste que exercita 
as condições lógicas contidas em um módulo de programa: 
• Uma condição simples é uma variável booleana ou uma expressão relacional, possivelmente precedida por um 
operador NOT. 
• Uma condição composta é formada por duas ou mais condições simples, operadores booleanos e parênteses. 
• Este tipo de teste foca o teste de cada condição no programa para garantir que ele não contenha erros. 
Teste de Ciclo: Este tipo de teste focaliza exclusivamente a validade das construções de ciclo, já que são em sua 
grande maioria a base da maioria dos algoritmos implementados. Podem ser definidos quatro tipos diferentes de 
classes de ciclos: 
 
 
Teste de Caminho Básico: O teste de caminho básico permite ao projetista de casos de teste derivar uma medida da 
complexidade lógica de um projeto procedimental e usar essa medida como guia para definir um conjunto de base 
de caminhos de execução. 
Testes baseados em Requisitos 
Nessa abordagem, os testes são baseados nos documentos de requisitos e modelados através de especificações 
funcionais e suplementares, os requisitos devem ser decompostos em casos de testes de forma a avaliarem todos os 
cenários existentes e validarem todas as variações. Existem diferentes métodos de testes de caixa-preta que podem 
ser subdivididos em: 
Baseados em Grafo: O método de teste com base em grafos, leva em consideração os objetos modelados no 
software e as relações que unem estes objetos. A ideia é definir uma série de testes que verificam se os objetos têm 
a relação esperada uns com outros. Um grafo é uma coleção de nós que representam objetos, ligações que 
representam as relações entre objetos, peso de nó que descrevem as propriedades de um nó e pesos de ligação que 
descrevem alguma característica de uma ligação. 
Particionamento de Equivalência: Neste método o domínio de entrada de um programa é divido em classes de 
dados a partir das quais podem ser criados casos de teste. Um caso de teste ideal descobre sozinho uma classe de 
erros (por exemplo, processamento incorreto de todos os dados de caracteres) que poderia de outro modo requerer 
que fossem executados muitos casos de teste até que o erro geral aparecesse. 
Classes de equivalência podem ser definidas de acordo com as seguintes regras: 
1) Se uma condição de entrada especifica um intervalo, são definidas uma classe de equivalência válida e duas 
classes de equivalência inválidas. 
2) Se uma condição de entrada requer um valor específico, são definidas uma classe de equivalência válida e duas 
classes de equivalência inválida. 
3) Se uma condição de entrada especifica um membro de um conjunto, são definidas uma classe de equivalência 
válida e uma classe de equivalência inválida. 
Se uma condição de entrada for booleana, são definidas uma classe válida e uma inválida. 
Exemplo: Um programa valida um campo numérico onde valores inferiores ou iguais a zero são rejeitados, 
valores entre 1 a 130 são aceitos, e valores maiores ou iguais a 131 são rejeitados. Neste caso 
• Partição inválida: os valores abaixo do valor mínimo, ou seja, valores menores ou iguais a zero. 
• Partição válida: valores entre 1 a 130; 
• Partição inválida: valores acima do valor máximo, ou seja, valores maiores ou igual a 131; 
Análise de Valor-Limite: A análise do valor limite (boundaryvalue analisys – BVA) é uma técnica que complementa o 
particionamento de equivalência, levando em consideração na construção dos casos de teste os valores limites das 
condições de entrada e saída. As diretrizes para o teste de análise de valor-limite , são muito similares a técnica de 
particionamento de equivalência: 
1. Se uma condição de entrada especifica um intervalo limitado por valores a e b, deverão ser projetados casos de 
teste com valores a e b imediatamente acima e abaixo de a e b. 
2. Se uma condição de entrada especifica um conjunto de valores, deverão ser desenvolvidos casos de teste que 
usam os números mínimo e máximo. São testados também valores imediatamente acima e abaixo dos valores 
mínimos e máximo. 
3. Aplicar as diretrizes 1 e 2 às condições de saída. 
4. Se as estruturas de dados internas do programa prescreverem fronteiras, não esquecer de criar caso de teste para 
exercitar a estrutura de dados na fronteira. Por exemplo, uma tabela que tem um limite definido de 100 entradas. 
 
Teste de Matriz Ortogonal: O teste de matriz ortogonal pode ser aplicado a problemas nos quais o domínio de 
entrada é relativamente pequeno, mas muito grande para acomodar um teste exaustivo. O objetivo do teste é a 
construção de caso de teste com uma visualização geométrica associada aos valores de entrada de uma aplicação. 
Na função enviar para uma aplicação de fax, por exemplo (Pressman,2010): São passados quatro parâmetros: P1, P2, 
P3 e P4, onde cada parâmetro assume três valores discretos. 
P1 assume os seguintes valores: 
P1=1, enviar agora; 
P1=2, enviar após 1 hora; 
P1=3, enviar depois da meia-noite; 
P2, P3 e P4 também assumem valores, 1, 2 e 3, significando outras funções de envio. 
 
 
Testes Progressivos e Regressivos 
É muito comum na maioria das empresas, que após o software entrar em produção, ocorra a necessidade de 
manutenções para correção de algum defeito ou para a adição de uma nova funcionalidade. Toda vez que um novo 
módulo é adicionado ou corrigido, o software se modifica e novos caminhos de fluxos de dados podem 
ser estabelecidos, novas E/S podem ocorrer ou ainda novas lógicas de controle podem ser adicionadas. 
Essas modificações podem causar problemas em funções que previamente funcionavam corretamente, daí a 
necessidade de utilizarmos os testes progressivos e/ou regressivos nas validações. 
Testes progressivos 
São elaborados de acordo com a evolução do produto. Á medida que o software recebe novas funcionalidades, um 
novo conjunto de testes deve ser criado. Desta forma, os testes de progressão testam somente as inovações do 
software (novas funções implementadas), assumindo que nenhum erro foi introduzido após seu processo de 
desenvolvimento. 
Testes Regressivos 
Trata-se de reexecutar um subconjunto (total ou parcial) de testes previamente executados. Seu objetivo é garantir 
que as alterações e inserções não prejudicarão o funcionamento do software. As novas versões do produto devem 
ser submetidas a uma nova sessão de testes para detectar eventuais impactos em outras funcionalidades, Vamos 
imaginar o seguinte cenário: 
 
 
 
 
Nesta aula, você: 
 Compreendeu o conceito de teste de validação e quando aplicar 
 Compreendeu as estratégias de testes e caixa branca e caixa preta 
 Relacionou as abordagens existentes para testes: baseados na estrutura interna e nos requisitos 
 Identificou os conceitos de progressividade e regressividade dos testes 
O que vem na próxima aula: 
Tema: - Categorias de testes de software 
 Assunto 1. Identificar as categorias dos testes de validação 
 Assunto 2. Classificar cada tipo de teste dentro da respectiva categoria. 
 Assunto 3. Distinguir e descrever os principais tipos de testes que devem ser realizados. 
 
 
 
 
1. 
 São métodos de testes que tem como objetivo testar a estrutura do programa: 
 1) Teste baseado em rafo, teste de fluxo de dados, análise do valor limite e análise ortogonal. 
 2) Particionamento de equivalência, teste de fluxo de dados, teste de ciclo e análise ortogonal. 
 3) Análise ortogonal, teste de fluxo de dados, teste de ciclo e teste de condição. 
 4) Teste de caminho Básico, teste de fluxo de dados, teste de ciclo e teste de condição. 
 5) Teste de fluxo de dados, teste de ciclo, teste de condição e matriz de grafo 
 4 
 2. 
 Qual é o conceito de teste de caixa-branca? 
 1) Tem uma visão interna do software, isto é, conhecendo o funcionamento interno do produto; 
 2) Tem uma visão externa, isto é, conhecendo a função para o qual um software foi projetado para realizar. 
 3) Tem uma visão interna do software, isto é, conhecendo a função para o qual um software foi projetado para 
realizar. 
 4) Tem uma visão externa, isto é, conhecendo o funcionamento interno do produto; 
 5) Tem uma visão interna e externa do produto. 
 1 
 3. 
 São métodos de teste de caixa-preta: 
 
 
 1) Teste de fluxo de dados, teste de ciclo, teste de condição e matriz de grafo 
 2) Análise ortogonal, teste de fluxo de dados, teste de ciclo e teste de condição. 
 3) Particionamento de equivalência, teste de fluxo de dados, teste de ciclo e análise ortogonal. 
 4) Baseado em Grafo, teste de fluxo de dados, análise do valor limite e análise ortogonal. 
 5) Baseado em Grafo, particionamento de equivalência, análise do valor limite e análise ortogonal. 
 5 
 
Aula 05: Categorias de Testes de Software 
Nesta aula, você irá: 
 
1. Identificar as principais categorias dos testes de validação. 
2. Classificar cada tipo de teste dentro da respectiva categoria. 
3. Distinguir e descrever os principais tipos de testes que devem ser realizados. 
Categorias dos testes de validação 
Normalmente, verificamos que empresas que diversificam suas ações em relação aos testes de software, 
demonstram falhas relacionadas ao conceito de categorização aplicado, tornando inferior a qualidade do 
planejamento da validação do software. Este fato ocorre devido os profissionais de testes planejarem trabalhos de 
naturezas diversas em uma única abordagem e levantamento. 
 
A combinação de várias categorias de testes diferentes(Usabilidade, funcionalidade, carga, performance e 
contingência) faz com que as atividades de levantamento dos cenários sejam insuficientes, incompletos e 
superficiais, reduzindo a amplitude e a eficiência na detecção do maior número de cenários de testes. 
Usabilidade, funcionalidade, carga, performance e contingência. 
Aplicação de testes em categorias 
A categorização dos cenários proporciona o melhor planejamento dos testes, facilitando o entendimento e 
reduzindo os esforços de validação do software. O agrupamento em categorias permite o refinamento dos cenários 
de software, ampliando a cobertura dos testes. É necessário observar que cada categoria possui seu ciclo de teste 
independente e naturezas conflitantes, por diversas vezes, não possibilitando sua coexistência. Suportar atividades 
simultaneamente significa conciliar interesses opostos. 
 
 
 
 
Desta forma podemos concluir que: 
Cada categoria de teste possui um determinado objetivo a ser alcançado, definindo o propósito da realização dos 
testes, estabelecendo um escopo das ações e planejamentos destes trabalhos. Sem este escopo, existiria uma 
dispersão natural no esforço de criação dos testes de um determinado sistema. 
Forma de classificação do conteúdo utilizado em cada teste. 
 
Testes sem Categorização (Sem Foco) 
• Levantamentos Unificados. 
• Superficialidade do Levantamento. 
• Única documentação dos testes. 
• Visão única dos Testes 
• Falta de priorização das categorias. 
• Aplicação de todas as categorias sem avaliação 
• Dificuldade em segregar a execução dos testes. 
Testes com Categorização (Com Foco) 
•Levantamentos Categorizados. 
• Profundidade dos Levantamentos. 
• Documentações Categorizadas 
• Visão categorizada dos Testes. 
• Priorizaçãodas Categorias. 
• Métricas de esforço e eficiência das categorias 
• Somente categorias relevantes são aplicadas. 
• Execuções separadas de testes, flexibilizando a operação. 
Durante o planejamento dos testes devemos estudar quais as categorias de testes serão aplicadas ao processo de 
validação de software. Após esta categorização estaremos aptos a identificar todos os cenários existentes para cada 
transação a ser testada. 
Visão Categorizada dos testes de software 
Existem diversas visões a cerca de categorizações dos testes de software. Uma das visões é o modelo 
FURPS(Functionality, Usability, Reliability, Performance e Supportability), que representa as categorias que podem 
ser usadas na definição de requisitos e testes de validação de software, assim como os atributos de Qualidade de 
Software. 
Este modelo é parte do Rational Unified Process(RUP). Ele consiste nas seguintes categorias: 
SUPORTABILIDADE 
• Teste de configuração. 
• Teste de instalação 
DESEMPENHO 
• Teste de avaliação de desempenho 
 ou benchmark. 
• Teste de contenção. 
• Teste de carga. 
• Perfil de desempenho. 
CONFIABILIDADE 
• Teste de integridade. 
• Teste de estrutura. 
• Teste de estresse. 
• Smoke test. 
USABILIDADE 
• Teste de interface. 
• Teste de usabilidade. 
FUNCIONALIDADE 
• Teste funcional. 
• Teste de regressão. 
• Teste de volume. 
• Teste de segurança 
FURPS 
Já a ISO/IEC 9126-1 apresenta a seguinte categorização: 
Conectividade: Integração entre componentes (hardware e software); 
Continuidade: Capacidade de operar ininterruptamente (Ex.: 24 x 7); 
Segurança: A certeza de que o dado somente pode ser alterado por aqueles autorizados; 
Eficiência: A relação entre os níveis de desempenho do sistema e os recursos; 
Funcionalidade: Estar de acordo com a especificação Funcional; 
Usabilidade: Facilidade de uso do sistema pelos Usuários; 
Performance: Velocidade de processamento da informação; 
Portabilidade: Capacidade do programa processar em diversos Ambientes 
 
Principais Categorias de Teste de Validação 
Teste de Funcionalidade 
Categoria de teste que tem por objetivo avaliar e garantir que todos os requisitos especificados sejam 
implementados, geralmente servindo como base de um processo de verificação automática. Os testes funcionais 
estão relacionados as regras de negócio para que se obtenha ampla cobertura dos cenários de negócio. Sua melhor 
descrição está em um modelo de casos de uso e em casos de uso. 
Os testes podem ser executados validando as seguintes condições: 
• Pré-condições de uma transação de negócios. 
• Fluxo de dados de uma transação de negócios. 
• Cenários primário, alternativos e de execução de uma transação de negócios. 
• Pós-condições de uma transação de negócios. 
Teste de Usabilidade 
Categoria de teste que enfatiza o nível de facilidade de uso da aplicação por seus clientes ou usuários. Os testes de 
usabilidade focalizam o nível de facilidade de navegação entre as telas da aplicação e as telas de ajuda devem ser 
avaliadas quanto a clareza do seu conteúdo e linguagem, bem como as mensagens de erro. 
Os testes podem ser executados da seguinte forma: 
• Pré Entra em cada tela e avaliar a facilidade de navegação entre as mesmas. 
• Realizar n operações e depois desfazê-las. 
• Realizar procedimentos críticos e avaliar mensagens de alerta. 
• Avaliar número de passos para realizar as principais operações. 
• Avaliar a existência de ajuda em todas as telas. 
• Realizar n buscas no manual de ajuda e validar os procedimentos sugeridos 
Teste de Carga (Stress) 
Categoria de teste destinado a avaliar como o sistema responde em condição anormais, provocando aumentos e 
reduções consecutivas de operações. O teste de carga no sistema abrange cargas de trabalho extremas, hardware e 
serviços indisponíveis, memória insuficiente ou recursos compartilhados limitados. 
Os testes podem ser executados da seguinte forma: 
• Elevando e reduzindo sucessivamente o número de transações simultâneas 
• Aumentando e reduzindo o tráfego de rede 
• Aumentando o número de usuários simultâneos 
• Combinando todos estes elementos. 
Teste de Volume 
 
Categoria de teste que submete a aplicação a ser testada a grandes quantidades de dados para determinar os limites 
de processamento e carga do aplicativo, e toda a infra-estrutura da solução. O teste de volume é executado através 
de incrementos sucessivos das operações realizadas com o sistema, até atingir o limite máximo de processamento 
da infra-estrutura do software. 
Os testes podem ser executados da seguinte forma: 
• Aumentando sucessivamente o volume de transações. 
• Aumentando sucessivamente o volume de consultas. 
• Aumentando sucessivamente o tamanho de arquivos a serem processados 
Teste de Configuração (Ambiente) 
Categoria de teste que verifica se o software está apto a rodar em diferentes configurações de software e hardware, 
o objetivo é garantir que o aplicativo seja executado sobre os mais variados ambientes de produção. 
Os testes podem ser executados da seguinte forma: 
• Variando os sistemas operacionais (incluído versões). 
• Variando os browsers. 
• Variando os hardwares que irão interagir com a solução. 
• Combinando todos esses elementos. 
Teste de Compatibilidade (Versionamento) 
Categoria de teste destinado a validar a capacidade do software em interagir com outras aplicações, versões 
anteriores e dispositivos físicos. O objetivo é garantir que novas versões suportem as antigas interfaces. 
Os testes podem ser executados da seguinte forma: 
• Importando-se os dados gerados pela solução anterior. 
• Comunicando-se com todas as versões anteriores e atuais. 
Teste de Segurança(ISO 15408 desenvolvimento de software seguro) 
Categoria de teste que tem por objetivo detectar as falhas de segurança que podem comprometer o sigilo e a 
fidelidade das informações, bem como provocar perdas de dados ou interrupções de processamento. 
Os testes podem ser executados da seguinte forma: 
• Validando todos os requisitos de segurança identificados 
• Tentar acessar funcionalidades e informações que requerem perfil avançado. 
• Tentar invadir/derrubar o servidor de dados/internet. 
• Tentar extrair backups de informações sigilosas 
• Tentar descobrir senhas e quebrar protocolos de segurança 
• Tentar processar transações geradas de fontes inexistentes 
• Tentar simular comportamento/infecção por vírus. 
Teste de Performance (Desempenho) 
Categoria de teste destinado a determinar se o desempenho nas situações previstas de pico máximo de acesso e 
concorrência está consistente com os requisitos definidos. 
Os testes podem ser executados da seguinte forma: 
• Validar todos os requisitos de desempenho identificados 
• Simular n usuários acessando a mesma informação, de forma simultânea 
• Simular n usuários processando a mesma transação, de forma simultânea 
• Simular n% de tráfego de rede 
• Combinar todos esses elementos 
Teste de instalação 
Categoria de teste destinado a determinar se os procedimentos de instalação de uma aplicação, assim como avaliar 
se estes possibilitam as várias alternativas previstas nos requisitos identificados. 
Os testes podem ser executados da seguinte forma: 
• Pré. Efetuar a primeira instalação do software. 
• Realizar a instalação de um software já instalado. 
• Realizar a instalação de atualização de um software. 
• Efetuar todas as alternativas de instalação. 
• Validar pré-requisitos de instalação do software. 
Teste de Confiabilidade e Disponibilidade 
Categoria de teste destinado a monitorar o software por um determinado período de tempo e avaliar o nível de 
confiabilidade da arquitetura da solução. Já que as interrupções provenientes de defeitos de software prejudicariam 
os índices de confiabilidade e disponibilidade da aplicação. 
Os testes podem ser executados da seguinte forma: 
• Monitorar permanentemente o ambiente de aceite (alpha-teste) 
• Identificartodas as interrupções do ambiente (confiabilidade) 
• Identificar o tempo de interrupção do ambiente (disponibilidade) 
Teste de Recuperação 
Categoria de teste destinado a avaliar o comportamento do software após a ocorrência de um erro ou de 
determinadas condições anormais. Devem também contemplar os procedimentos de recuperação do estado inicial 
da transação interrompida, impedindo que determinados processamentos sejam realizados pela metade e sejam 
interpretados como completos. 
Os testes podem ser executados da seguinte forma: 
• Interrupção do acesso à rede: por alguns instantes ou por um longo período 
• Interrupção do processamento: através do desligamento do micro e através do desligamento do servidor 
• Geração de arquivos, cancelamento do processamento e avaliação dos arquivos gerados. 
Teste de Contigência 
Categoria de teste destinado a validar os procedimentos de contingência a serem aplicados à determinada situação 
prevista no planejamento do software. O objetivo é simular os cenários de contingências e avaliar a precisão dos 
procedimentos. 
Os testes podem ser executados da seguinte forma: 
Instalação emergencial de uma aplicação 
Recuperação da perda de conexão da filial com a matriz. 
Nesta aula, você: 
 Identificou as principais categorias dos testes de validação. 
 Classificou cada tipo de teste dentro da respectiva categoria. 
 Distinguiu e descreveu os principais tipos de testes que devem ser realizados. 
 
1. 
 Categoria de teste que tem por objetivo avaliar e garantir que todos os requisitos especificados sejam 
implementados, geralmente servindo como base de um processo de verificação automática: 
 1) Funcional 
 2) Usabilidade 
 3) Compatibilidade 
 4) Volume 
 5) Recuperação 
 1 
 2. 
 Categoria de teste destinado a avaliar como o sistema responde em condição anormais, provocando aumentos e 
reduções consecutivas de operações do sistema. 
 1) Desempenho 
 2) Carga 
 3) Contingência 
 4) Funcionalidade 
 5) Compatibilidade 
 2 
 3. 
 Categoria de teste que enfatiza o nível de facilidade de uso da aplicação por seus clientes ou usuários: 
 
 1) Contingência 
 2) Desempenho 
 3) Funcionalidade 
 4) Usabilidade 
 5) Configuração 
 4 
Aula 06: Métodos Estruturados de Teste 
Nesta aula, você irá: 
 
1. Descrever o conceito de casos de teste. 
2. Descrever como obter casos de testes pelos métodos da Caixa Preta. 
3. Entender como refinar casos de testes 
Nós vimos nas aulas anteriores que os métodos de verificação utilizam técnicas de testes estáticos pra avaliar a 
qualidade dos documentos gerados durante todas as etapas do desenvolvimento do software. 
 Porém para avaliarmos a qualidade de um sistema, os testes não podem ser estáticos precisam ser dinâmicos, pois 
devemos submeter o software a determinadas condições de uso de forma a avaliar se o comportamento está de 
acordo com o esperado. 
 Desta forma torna-se necessário a utilização de uma forma sistémica de trabalho com o objetivo de identificar o 
maio número possível de situações de testes. 
Isto é possível através da utilização de algumas técnicas para auxiliar na identificação dos diversos cenários de teste. 
O que é um caso de teste? 
Os casos de testes são um conjunto de entradas de teste, condições de execução e resultados esperados 
desenvolvidos para testar o caminho de um programa ou verificar o cumprimento de um requisito específico. Os 
casos de teste refletem os requisitos que devem ser averiguados. A verificação pode ser realizada de forma variada e 
por profissionais distintos. Torna-se fundamental para o sucesso do projeto selecionar os requisitos mais 
importantes e adequados para o teste, pois: 
• Os casos de teste constituem a base do design e do desenvolvimento dos Scripts de Teste. 
• Cada caso de teste reflete um cenário. 
• A "profundidade" do teste é proporcional ao número de casos de testes, gerando maior confiança no processo de 
teste e na qualidade do produto. 
• A escala do esforço de teste é proporcional ao número de casos de teste, é possível estimar com mais precisão a 
duração dos estágios subsequentes do ciclo de teste. 
 
 
 
Estas abordagens são fundamentais para que a equipe de desenvolvimento possa rastrear a origem dos casos de 
testes e avaliar quais deles deverão ser aplicados quando ocorrerem mudanças nos requisitos ou estruturas internas. 
Importância dos Casos de testes 
Os métodos a serem utilizados mudam de acordo com a abordagem de testes a ser empregado, porém todas as 
formas básicas são fundamentais para garantir que o produto final seja adequado, cabe aos profissionais de testes 
produzirem um número suficiente de casos de testes para cada abordagem. 
Os desafios de um processo de garantia de qualidade 
Medir o grau de qualidade alcançado nos teste de software 
É necessário buscar todas as alternativas possíveis e adiciona-las no processo de teste de software, de forma a 
refinar e ampliar o nível de cobertura. 
Através dos casos de teste é possível monitorar os avanços da qualidade de software, avaliando os históricos de 
cobertura dos testes nos sucessivos ciclos de interação do desenvolvimento do software. 
Os casos de testes são elementos essenciais no processo de teste de software. 
A qualidade de sistema será determinada pela simulação do maior número de cenários possíveis de execução. 
O processo de validação será efetivo se a equipe de teste conhecer efetivamente as técnicas de obtenção de casos 
de testes. 
Métodos Caixa Preta para obtenção dos casos de Testes 
Não tem como obtermos um software de qualidade sem a existência de um processo de desenvolvimento que 
assegure o comportamento do software comparando-o com requisitos funcionais estabelecidos no projeto. 
 Os testes da caixa preta, já estudados na aula 4, são uma abordagem complementar aos testes de caixa branca, 
com a finalidade de identificar um conjunto de situações que serão empregadas em forma de testes para a 
identificação de erros. 
É importante perceber que a variedade de cenários permitirá o maior conjunto de simulações que serão avaliadas e 
comparadas com os requisitos contratados, sendo então fundamental a utilização de métodos que permitam 
identificar o maior número de casos de testes, garantindo ampla variedade de cenários para a execução do sistema. 
 Os principais métodos de testes de caixa-preta para obtenção dos casos de testes são: 
• Métodos de decomposição de requisitos. 
• Métodos de Análise de Documentos. 
Métodos de decomposição de requisitos 
Os requisitos do software são elementos fundamentais nos processo de testes uma vez que originam os cenários de 
testes que por sua vez dão origem aos casos de testes. Cada requisito carrega em si um conjunto de cenários dentro 
da realidade de cada sistema. 
A decomposição de um requisito em cenário é fundamental para descobrir todas as possibilidades envolvidas na 
dinâmica do software. É necessário explorar todos os cenários possíveis para cada requisito existente. 
Destacam-se os três tipos de cenários que podem estar contidos nos requisitos: 
Cenário Primário 
É a situação mais básica de compreensão de um requisito de software. Trata-se da representação de um cenário 
perfeito que será usada como linha mestra para o entendimento de outros cenários existentes. 
Cenário alternativo 
São variações possíveis dentro do cenário primário, isto é, os caminhos alternativos ou situações equivalentes que 
conduzirão ao mesmo objetivo. 
Cenário Exceção 
Trata-se de possíveis problemas e inconsistências que impedem a finalização de determinado requisito. São todas as 
condições impeditivas que podem ocorrer a qualquer requisito. 
 
Métodos de Análise de Documentos 
Uma outra forma de decomposição poderá ser através da utilização de documentos e modelos, dependendo da 
metodologia de desenvolvimento usada. Qualquer documento pode conter elementos essenciaispara auxiliar na 
localização de novos casos de testes e no refinamento e ampliação do esforço de planejamento dos testes. 
Se por exemplo estiver sendo usada a orientação a objeto juntamente com a linguagem UML como padrão de 
documentação, as principais fontes para extrair os casos de testes são os destacados ao lado, clique nas elipses e 
saiba mais sobre o assunto. 
Diagrama de estado – que representa um estado ou situação em que um objeto pode se encontrar no decorrer da 
execução de processos de um sistema. Com isso, o objeto pode passar de um estado inicial para um estado final 
através de uma transição. 
Podemos por exemplo, pensar no diagrama de estado do ciclo de vida de um livro. Cada transição de um estado para 
outro do livro deverá ser considerada um caso de teste (cenários positivos), enquanto que as transições “proibidas” 
deverão ser inseridas como cenários negativos, uma que também deverão ser testadas. 
 
Diagrama de atividades – Representa todo o fluxo de processamento de um determinado evento de negócio, 
revelando todos os caminhos alternativos (caminhos positivos) e as situações que impossibilitam a finalização desse 
evento (cenários negativos). 
Um bom diagrama de atividades deverá revelar o conjunto completo de casos de testes que deverão ser inseridos no 
planejamento de testes. 
 
Métodos Caixa Branca para obtenção dos casos de Testes 
Baseia-se num minucioso exame dos detalhes procedimentais do software, ou seja, a linha de código. São testados 
os caminhos lógicos através do software, fornecendo-se casos de teste que põem à prova conjuntos específicos de 
condições e laços. Esses cenários devem ser modelados de forma a atentar ao maior número de situações, exigindo 
o menor esforço possível para executá-los. 
Os principais métodos de testes de caixa-branca para obtenção dos casos de testes são: 
Cobertura de linha de código: Trata-se da forma mais simplificada de medição, os testes de cobertura são medidos 
pelo número de linhas que são “adicionais” sempre que determinado conjunto de casos de testes é executado. 
O objetivo dessa cobertura de teste é conseguir alcançar 100% da execução do código-fonte, ou seja, todas as linhas 
serão exercitadas ao menos uma vez durante a execução dos testes. 
 
Cobertura de caminhos: Foca nos fluxos alternativos. Busca-se identificar um conjunto de casos de teste que 
possibilitem exercitar todos os possíveis caminhos de execução e localizar falhas de iniciação de variáveis ou mesmo 
fluxos não previstos de processamento, que podem conduzir a erros de execução. 
Este modelo de cobertura analisa a estrutura interna de cada rotina existente no código-fonte e identifica todos os 
casos de testes que representam todos os fluxos internos de processamento, de maneira a exercitar todos os 
caminhos que o software suportará no ambiente de produção. 
 
Cobertura de desvios condicionais : Objetiva detectar erros nas condições lógicas aplicadas no código-fonte. Os 
casos de teste são construídos de forma a permitir variação dos valores que determinam a execução dos diversos 
fluxos alternativos existentes no código-fonte. O desenho interno do software é o principal elemento para a 
modelagem dos casos de testes. 
Clique aqui e conheça os três níveis de refinamentos para cobrir o maior número de condições possíveis. 
 
Cobertura de laços 
Normalmente os erros encontrados em laços de programação são de falta de iniciação de variáveis, quando as 
variáveis sofrem iniciações contínuas ou quando um laço atinge seu limite de execução. 
Clique aqui e saiba mais sobre o assunto. 
 
Nesta aula, você: 
 Descrever o conceito de casos de teste. 
 Descrever como obter casos de testes pelos métodos da Caixa Preta. 
 Entender como refinar casos de testes. 
Na próxima aula, abordaremos os seguintes assuntos: 
Tema: Testes de Validação e suas fases 
 Identificar os 2 níveis de testes e relacioná-los as fases da validação. 
 Relacionar as fases dos testes de validação. 
 Reconhecer as categorias de testes que são aplicados em cada fase. 
 Reconhecer as características de cada fase de validação. 
 
1. 
 No método do caso de teste através do Método de Análise de Documentos, caso estejamos utilizando a orientação a 
objeto em conjunto com a linguagem UML como padrão de documentação, quais as principais fontes para extrair os 
casos de testes? 
 1) Diagrama de atividades e diagrama de estado 
 2) Diagrama de estado e o código fonte 
 3) Somente o código fonte 
 4) Diagrama de atividades e o código fonte 
 5) Caso de uso e diagrama de condição 
 1 
 2. 
 As abordagens utilizadas para as derivações de casos de testes são: 
 1) Requisito e por estrutura interna 
 2) Positivo e negativo 
 3) Primário e Alternativo 
 4) Requisitos e laços 
 5) Diagrama de atividades e diagrama de estado 
 1 
 3. 
 Os laços possuem quatro configurações envolvendo procedimentos de testes diferenciados. Quais são estas 
configurações: 
 1) Simples, aninhados, concatenados e não estruturados 
 2) Primário, secundário, alternativo e exceção 
 3) Positivo, negativo, normal e neutro 
 4) Simples, composto, alternativo e concatenado 
 5) Interno, externo, intermediário e neutro 
 1 
Aula 07: Teste de validação e suas fases 
1. Identificar os dois níveis de testes e relacioná-los as fases da validação. 
2. Relacionar as fases dos testes de validação 
3. Reconhecer as categorias de testes que são aplicados em cada fase 
4. Reconhecer as características de cada fase de validação. 
Testes de Validação 
O teste de validação inicia-se no final do teste de integração, quando os components individuais foram executados, o 
software está completo e os erros de interface corrigidos. 
Na etapa de validação ou no nível de sistema, a distinção entre o software convencional e orientado a objetos 
desaparece, o teste focaliza ações visíveis e saídas do sistema reconhecida pelo usuário. 
A validação do software se torna bem-sucedida quando o software funciona de maneira adequadamente esperada 
pelo cliente, desta forma, é obtida por intermédio de uma série de testes que demonstram conformidade com os 
requisitos. O plano e o procedimento de teste são projetados para garantir que: 
 
 
 
 
 
Fases dos testes de Validação 
Nos testes de validação os mecanismos de testes estão segmentados em dois níveis de testes: 
 
Teste de baixo nível (Testes de baixo Nível : Caracterizados por exigirem dos profissionais de testes um profundo 
conhecimento da estrutura interna do produto.) 
Os testes de baixo nível compreendem os testes: 
 Unidade e integração 
Baixo Nível - Teste de unidade 
O teste de unidade é realizado no estágio mais baixo da escala de teste, isto é, no código do programa e 
normalmente é realizado pelo desenvolvedor. Concentra-se em cada unidade do software, de acordo com o que é 
implementado no código fonte. Utiliza as técnicas de teste de caixa branca e caixa preta. 
Este tipo de teste é aplicado nos menores componentes de código criado, visando garantir que estes atendem as 
especificações em termos de características e de funcionalidade. 
O teste de unidade foca na lógica interna de processamento e nas estruturas de dados dentro dos limites de um 
componente, conforme a figura ao lado. 
 
Interface de módulo: A interface de módulo é testada para assegurar que as informações fluam corretamente para 
dentro e para fora da unidade do programa que está sendo testada. 
Estrutura de dados local: A estrutura de dados local é examinada para garantir que os dados armazenados 
temporariamente mantenham sua integridade durante todos os passos na execução de um algoritmo. 
Condições limite: As condições limite são testadas para garantir que o módulo opere adequadamente nas fronteiras 
estabelecidas para restringir ou limitar o processamento. 
Caminhos independentes: Todos os caminhos independentes da estrutura de controle sãousados para assegurar 
que todas as instruções em um módulo tenham sido executadas pelo menos uma vez. 
Caminhos de manipulação de erro: Todos os caminhos de manipulação de erro são testados. 
Casos de testes: Casos de testes deverão ser projetados para descobrir erros devido a computações errôneas, 
comparações incorretas ou fluxo de controle inadequado. 
Procedimentos de teste de unidade 
O teste de unidade é considerado um auxiliar para a etapa de codificação. Podem ocorrer antes de começar a 
codificação ou depois que o código-fonte tiver sido gerado. Como cada componente não é um programa 
independente deve ser construído um pseudocontrolador e/ou um pseudocontrolado para cada teste de unidade. 
Eles irão auxiliar no teste unitário já que um pseudocontrolador representa o “programa principal” que aceita dados 
do caso de teste e passa esses dados para o componente a ser testado. Já o pseudocontrolado utiliza a interface dos 
módulos subordinados, pode fazer uma manipulação de dados mínima através de verificação de entrada e retorno 
do controle para o módulo que está sendo testado. 
Vale ressaltar que pseudocontroladores e pseudocontrolado representam despesas indiretas no projeto de 
desenvolvimento de software, pois são softwares que devem ser escritos e que não serão fornecidos com o produto 
final. 
 
Baixo Nível - Testes de Integração 
O teste de integração focaliza o pacote de software completo e trata da verificação do programa como um todo. 
Este tipo de teste faz uso de técnicas de projeto de casos de teste que enfocam as entradas e saídas, além de 
exercitar caminhos específicos. 
Mesmo que todos os módulos estejam funcionando individualmente, não se pode garantir que eles funcionarão em 
conjunto: 
Os dados podem ser perdidos na interface; 
A imprecisão aceitável individualmente de cada módulo pode ser amplificada no funcionamento em conjunto; 
As estruturas de dados globais podem apresentar problemas; 
Segundo Pressman, o teste de integração é uma técnica sistemática para construir a arquitetura do software 
enquanto se conduz testes para descobrir erros associados com as interfaces a partir dos componentes já testados 
através do teste de unidade. Existem basicamente duas abordagens que podem ser utilizadas: 
Não incremental (big-Bang) 
Neste tipo de abordagem todos os componentes são combinados com antecedência e o programa inteiro é testado 
de uma vez. Segundo Pressman, usualmente, o resultado desta abordagem é o caos, pois normalmente são 
encontrados muitos erros tornando a correção difícil, pois fica complicado isolar as causas dos erros. Uma vez 
corrigidos os erros, novos erros aparecem e o processo parece não ter fim. 
Incremental 
Este tipo de abordagem é a antítese da abordagem big-bang. O programa é construído e testado em pequenos 
incrementos. Os erros são mais fáceis de isolar e corrigir e pode ser aplicada uma interface sistemática de testes. 
Neste contexto existem várias estratégias incrementais de integração: 
 Integração descendente ou Top-down 
 Integração ascendente ou Botton-up 
 Teste de regressão 
 Teste fumaça 
Clique aqui e saiba mais sobre as estratégias incrementais de integração. 
Teste de alto nível 
Os testes de alto nível compreendem os testes: 
 Sistema e Aceitação 
 
 
Teste de Alto Nível - Testes de Sistema 
O teste de sistema se refere ao comportamento de todo o sistema / produto definido pelo escopo de um projeto ou 
programa de desenvolvimento. Neste tipo de teste o ambiente de teste deve corresponder o máximo possível ao 
objetivo final, ou o ambiente de produção, para minimizar que os riscos de falhas específicas de ambiente não serem 
encontradas durante o teste. 
 
O objetivo do teste de sistema é realizar a execução do sistema como um todo, dentro de um ambiente operacional 
controlado, para validar a exatidão e perfeição na execução de suas funções, acompanhando cenários sistêmicos 
elaborados pelo profissional de requisitos do projeto e devem retratar os requisitos funcionais e não-funcionais do 
sistema. Normalmente este tipo de teste é realizado por uma equipe de teste independente, onde o analista de 
teste irá elaborar os casos de testes, normalmente em conjunto com os desenvolvedores e executando os testes em 
um ambiente controlado, no caso o ambiente de teste. 
Os testes podem ser baseados em: 
 
O teste de sistema é na realidade uma série de diferentes testes cuja finalidade primária é exercitar totalmente o 
sistema e que apesar de terem finalidades diferentes, todos funcionam no sentido de verificar se os elementos do 
sistema foram integrados adequadamente e executam as suas funções corretamente: 
• Teste de recuperação 
• Teste de segurança 
• Teste de esforço (estresse) 
• Teste de desempenho 
• Teste de disponibilização 
Testes de Aceitação 
É impossível que se preveja como o cliente realmente usará um programa. As instruções de uso podem ser mal 
interpretadas, combinações estranhas de dados podem ser regularmente usadas, saídas que pareciam claras ao 
analista podem ser ininteligíveis para um usuário em campo. Desta forma o teste de aceitação é de responsabilidade 
do cliente. Dependendo da abrangência dos usuários podem ser aplicados de duas maneiras: 
Software customizado para um cliente; Software desenvolvido como produto para muitos clientes. 
Software customizado para um cliente 
São realizados testes de aceitação, realizados pelo usuário final para capacitá-lo e para validar todos os requisitos. 
Pode variar de um test drive informal a uma série de testes planejados. 
Software desenvolvido como produto para muitos clientes 
Teste Alfa 
É conduzido na instalação do desenvolvedor por um grupo representativo de usuários finais. O software é utilizado 
em um cenário natural e realizado em conjunto desenvolvedores e usuários, registrando os erros e os problemas de 
uso. Este tipo de teste normalmente é conduzido em um ambiente controlado. 
Teste Beta 
O teste Beta é conduzido nas instalações de um ou mais usuários finais e neste tipo de teste o desenvolvedor não 
deverá estar presente. O cliente registra todos os problemas encontrados durante o teste e vai relatando para o 
desenvolvedor em intervalos regulares. Com o resultado do teste beta, os desenvolvedores fazem as modificações 
necessárias e preparam a liberação do software para todos os clientes. 
Existem muitas empresas que colocam versões beta de seus softwares na internet para que os usuários possam 
fazer o teste com o novo produto que neste caso, ainda não foi lançado oficialmente. 
Nesta aula, você: 
 Identificou os dois níveis de testes e relacioná-los as fases da validação. 
 Relacionou as fases dos testes de validação. 
 Reconheceu as categorias de testes que são aplicados em cada fase. 
 Reconheceu as características de cada fase de validação. 
Na próxima aula, você estudará sobre os assuntos seguintes: 
Tema: - Gerenciamento do Testware 
 Discutir o conceito de Testware. 
 Constatar e reconhecer a diferença entre os ambientes de desenvolvimento, Teste e homologação e 
ambiente de produção. 
 
 
 
1. 
 __________________ geralmente são executados após a correção de algum defeito ou após a adição de uma nova 
funcionalidade. Seu objetivo é garantir que nenhum defeito foi acrescentado ao sistema após sua modificação. 
 1) Testes de regressão 
 2) Testes de estresse 
 3) Teste fumaça 
 4) Teste alfa 
 5) Teste Integração 
 1 
 
 2. 
 Nos testes de validação os mecanismos de testes estão segmentados em dois níveis de testes distintos testes de baixo 
nível e testes de alto nível. São considerados testes de alto nível: 
 1) Teste de sistema e teste de aceitação 
 2) Teste da caixa branca e teste da caixa preta 
 3) Teste de integração e teste de unidade 
 4) Teste de regressão e teste fumaça 
 5) Teste de sistema e teste de integração 
 1 
 3. 
 Teste conduzido nas instalações