Aulas01a10_AvaliaçãodeSistemas

Prévia do material em texto

Aula 01: A Busca pela Qualidade 
 
Introdução 
 
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. 
 
 
 
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, elaborado pelo SEI . 
 
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). 
 
 
A realidade dos projetos de software 
 
Apesar de Sistemas de software tornam­se cada vez mais parte do nosso dia­a­dia e de serem 
um dos aspectos mais estratégicos para se viabilizar o aprimoramento e a inovação dos 
produtos e serviços nas organizações, o que acontece de fato, é que as indústrias de software 
estão despreparadas para atender às rápidas necessidades dos mercados porque não 
investiram em seus processos internos. 
 
Não existe garantia de que a solução tecnologia contratada será entregue no prazo e nos 
custos negociados. Estudo americano demonstra o quanto imaturas ainda estão as indústrias 
de software:  
 
● 30% dos projetos são cancelados. 
● 70% dos projetos falham nas funcionalidades. 
● Os custos extrapolam em 180% a previsão. 
● Os orçamentos extrapolam 200% os cronogramas iniciais. 
 
 
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 de 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 testes chamados de 
testes de software ou testes de validação ou ainda testes dinâmicos. 
 
 
O conceito de testes 
 
De uma maneira geral os testes são vistos como forma de provar que tudo está bem e 
funcionando conforme o estabelecido. Existem várias definições para o conceito de testes:  
 
1. Teste é o processo de demonstrar que os defeitos não estão presentes. 
2. Teste é o processo de demonstrar que algo funciona corretamente. 
3. Teste é o processo de provar que determinadas coisas (funções) fazem o que devem 
fazer. 
 
Todas estas definições dão uma dimensão positiva sobre o problema, ou seja, se está tudo 
funcionando adequadamente. Porém oobjetivo real do teste de software é mostrar que um 
software está de acordo com suas especificações e que ele atende as expectativas do cliente.  
 
Desta forma o software é testado para revelar erros cometidos inadvertidamente quando o 
software foi produzido e construído. Em uma definição ampliada de testes teremos:  
 
"processo sistemático e planejado que tem por finalidade única a identificação de erros.” 
Fonte: Bartié, 2002 
 
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 forma 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 
 
Para compreender melhor o processo de qualidade de software e sua implementação, segundo 
Bartié (2002), podemos fazer uma referência ao processo de gerenciamento de qualidade do 
PMBOK que estrutura o processo de qualidade em três subprocessos complementares: 
 
 
 
● Planejamento de Qualidade ­ Identifica quais padrões de qualidade são relevantes para o 
projeto.  
● Garantia de Qualidade ­ Tem como objetivo garantir o adequado desempenho de cada 
etapa do desenvolvimento, satisfazendo os padrões qualidade definidos no processo.  
● Controle de Qualidade ­ Avaliará sistematicamente a qualidade do processo em 
execução e a qualidade do produto tecnológico que está sendo desenvolvido. 
 
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 
 
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. 
Aula 02: Verificação e validação 
 
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. 
 
 
 
 
Objetivo da Qualidade de Software 
 
Devemos garantir a qualidade de todas as etapas do processo de desenvolvimento, não sendo 
possível um processo de qualidade que não seja integrado ao processo de desenvolvimento. 
 
Objetivos do processo de qualidade de software (Bartié. 2002): 
 
● Garantir que todos os produtos previstos na metodologia empregada estejam em 
conformidade com o requisitos implementados. 
● Qualidade não uma fase do ciclo de desenvolvimento de software é parte de todas as 
fases. 
 
 
Processo de qualidade de software 
 
Pode ser decomposto em fases que se organizam em um formato de “U” e consequentemente 
deve existir uma relação de “um para um” entre as fases de desenvolvimento e as atividades a 
serem desempenhadas pela equipe de qualidade, conforme mostra a figura: 
 
 
 
Momentos do processo de desenvolvimento de software 
 
O processo de desenvolvimento de software é divido em dois momentos que possuem 
caracaterí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 desenvolvimento do software. Não envolve o processamento de software, 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 e Modelagem 
4. Implementação ­ Verificação da Implementação 
 
 
 
 
 
 
 
 
 
 
 
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.  
 
 
Estágios de desenvolvimento 
 
● Validação da unidade ­ É a primeira etapa do processo de validação que tem por objetivo 
testar componentes individuais de uma aplicação. 
● Validação da integração ­ É uma continuação natural dos testes unitários. Estes testestêm por objetivo validar a compatibilidade entre componentes de um software. 
● Validação do sistema ­ Seu objetivo é validar a solução como um todo. Ao atingir este 
estágio a maior parte das falhas de funcionalidade deve ter sido detectada pelos testes 
unitários e pelos testes de integração. 
● Validação do aceite ­ Último estágio do processo de validação. Último processo formal 
de detecção de erros no sistema, antes da disponibilização no ambiente de produção. 
Nesta etapa o software é disponibilizado para clientes e usuários com o objetivo de 
estes validarem todas as funcionalidades requisitadas no início do projeto. 
 
 
Fatores de insucesso dos processos de qualidade 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
   
Aula 03: Métodos de validação de Qualidade de Software 
 
Teste 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ão 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. 
 
São técnicas mais efetivas e bem estruturadas. Baseiam­se em reuniões com um grupo de 
profissionais responsáveis em identificar falhas presentes em documentos gerados nas 
diversas etapas do desenvolvimento. Esta técnica apresenta regras próprias que devem ser 
respeitadas e que visam à identificação do maior número possível de erros nas 
documentações. 
 
O autor do documento estará presente somente para responder às dúvidas e eventuais 
questões levantadas pelos revisores, não podendo conduzir a reunião. Com a participação 
limitada do autor, o documento poderá ser analisado de uma perspectiva diferente. Desta forma 
todos os participantes devem ter estudado o documento e os assuntos tratados por ele. 
 
Normalmente em um processo de revisão podemos ter as seguintes fases: 
 
● Planejamento ­ Selecionar a equipe, alocar as funções, definir os critérios de entrada e 
de saída para os diversos tipos de revisão, e selecionar quais as partes dos 
documentos serão vistos. 
● Kick­off ­ Distribuir os documentos, explicar os objetivos, processos e documentos para 
os participantes; e checar os critérios de entrada (para os diversos tipos de revisão). 
● Preparação individual ­ Trabalho feito por cada participante antes da reunião de revisão, 
tomando nota dos defeitos em potenciais, questões e comentários. 
● Re­trabalho ­ Resolver defeitos encontrados. Atividade  tipicamente realizada pelo autor.  
● Acompanhamento ­ Checar se os defeitos foram encaminhados, obtendo métricas e 
checando o critério de saída (para tipos de revisões formais). 
 
 
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: 
 
1. Planejar mão de obra e tarefas de cada um. 
2. Preparar o pessoal de forma que recebam o máximo de material sobre o tema em 
questão. 
3. Verificar os documentos. 
4. Aplicar check­list nas verificações.  
 
 
 
A figura apresentada mostra um modelo de referência, onde são identificadas 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 formalidadeapropriado 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. 
 
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 mais verificar nessa 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.   
 
 
 
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). 
 
 
 
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.   
 
 
● Glossário com termos de teste de software: 
http://www.testingstandards.co.uk/living_glossary.htm 
 
● Base comunitária de conhecimento em teste de Software (este site possui lista sobre os 
principais site nacionais e internacionais sobre teste e uma lista das certificações 
possíveis na área de teste de software: 
http://www.testexpert.com.br/?q=book/export/html/4 
 
   
Aula 04: Conceituação dos Testes de Validação 
 
Teste 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: 
 
● Teste de 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. 
 
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: 
 
1. Garantam que todos os caminhos independentes de um módulo foram 
exercitados pelo menos uma vez; 
2. Exercitam todas as decisões lógicas nos seus estados verdadeiros e falsos; 
3. Executam todos os ciclos em seus limites e dentro de suas fronteiras 
operacionais; 
4. 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 requisitosda 
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 de dados é 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: 
 
 
 
 
Abordagens dos Testes 
 
Há várias formas (Bartié, 2002) de identificar e planejar os casos de testes a serem aplicados 
nos testes de validação, porém, o direcionamento dos testes baseia­se exclusivamente em 
requisitos da solução tecnológica a ser desenvolvida ou na estrutura interna do código­fonte a 
ser implementado. 
 
 
 
 
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: 
 
1. Teste de Fluxo 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.  
 
2. 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. 
3. 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: 
 
● Simples 
O seguinte conjunto de testes pode ser aplicado a ciclos simples, onde n é o 
número máximo de passadas permitidas através do ciclo. 
 
 
● Aninhados 
Esta abordagem testa se os ciclos mais internos que são aplicados à 
abordagem de ciclos simples e os outros ciclos externos permanecem com o 
valor mínimo. 
 
 
● Ciclos Concatenados 
Pode ser testado usando a abordagem definida para ciclos simples se cada ciclo 
for independente do outro. No entanto, se dois ciclos forem concatenados e a 
contagem para o ciclo 1 for usado valor individual para o ciclo 2, então os ciclos 
não são independentes. Quando os ciclos não são independentes, é 
recomendada a abordagem aplicada a ciclos aninhados. 
 
 
● Não estruturados 
Segundo Pressman, sempre que possível essa classe de ciclos deverá ser 
redesenhada para refletir o uso das construções de programação estruturada. 
 
 
 
4. 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: 
 
● Base 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. 
 
● Análise de Valor Limite 
A análise do valor limite (boundary value 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. 
 
● Teste de Matriz Ortagonal 
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 regressivosnas 
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: 
 
1. A empresa XPTO possui um sistema Alfa atendido por vários clientes, vamos 
considerar a seguinte situação: 
 
 
2. O sistema Alfa atende a duas categorias de clientes, o cliente Regular e o cliente 
Vip. O cliente VIP responde por 75% do faturamento. A necessidade de políticas 
de negociação para clientes ocasionais gera demanda para uma nova 
funcionalidade. 
 
 
 
3. Por conta disso foi gerada uma nova versão e somente foram aplicados testes 
progressivos. Desta forma, não foi percebido que a política de negociação do 
cliente Vip foi afetada com esta mudança, ocasionando reduções nos preços das 
linhas inteiras de produtos. 
 
 
4. Essas reduções de preços aumentaram repentinamente a requisição de 
pedidos. O erro foi identificado e a solução foi disponibilizada rapidamente. 
Foram seis horas para a solução completa do problema. 
Atualmente, a maior parte dos esforços dos testes aplicados nas empresas está 
concentrada nas funcionalidades recém­construídas ou modificadas. Como não 
existe mecanismo que avalie as mudanças que provocam problemas em outras 
funcionalidades existentes, os riscos de uma pequena mudança gerar problemas 
no ambiente de produção aumenta consideravelmente. Para redução dos riscos, 
é aconselhável a utilização dos testes progressivo e regressivo. 
 
   
Aula 05: Categorias de Testes de Software 
 
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 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. 
 
 
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. 
 
A tabela abaixo mostra o levantamento dos cenários aplicando­se os conceitos de 
categorização. Se compararmos à figura anterior verificaremos a vantagem nesta 
categorização. 
 
Funcional  Segurança 
• Simular saques acima do saldo disponível; 
• Simular saque na conta­poupança; 
• Simular saque acima do limite do valor da 
conta; 
• Simular saques com o cartão vencido; 
• Avaliar se a senha do cartão está sendo 
avaliada antes e depois da transação; 
• Simular saque com valores não multiplos 
das notas. 
• Avaliar se a senha adicional ou randômica 
está sendo requisitada no início da operação; 
• Simular saque noturno acima do valor 
permitido. 
Usabilidade  Performance 
 
• Avaliar se todas as telas possuem ajuda; 
• Avaliar se as mensagens são claras e 
objetivas; 
• avaliar se o padrão visual é mantido em 
todos os momentos; 
• Avaliar se todas as operações possuem 
caminhos de fuga. 
• Avaliar se a duração do saque dura mais do 
que 30 seg. num universo de 5 milhões de 
correntistas e 100 milhões de 
movimentações bancárias. 
 
Carga e Concorrência  Configuração 
• Simular 2 saques simultâneos na mesma 
conta­corrente; 
• Simular 10.000 saques simultâneos. 
• Simular saque com impressora do 
fornacedor A, B, e C; 
• Simular saques no Windows 95, 98, NT e 
2000; 
• Simular saque com impressora do 
fornacedor X, Y, e Z. 
Recuperação  Contingência 
• Simular saque com defeito no 
"cash­dispenser"; 
• Simular saque com defeito na impressoara; 
• Simular saque com falha de conexão com a 
central; 
• Simular saque com queda de energia. 
• Disparar processo de instalação inicial. 
 
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. 
 
Porque categorizamos os testes? Para aumentar a eficiência da detecção do maior número 
possível de cenários de testes! 
 
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. 
 
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, 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. Ele consiste nas seguintes categorias:  
 
1. Suportabilidade:  
● Teste de configuração; 
● Teste de instalação. 
2. Desempenho: 
● Teste de avaliação de desempenho ou benchmark; 
● Teste de contenção; 
● Teste de carga; 
● Perfil de desempenho. 
3. Confiabilidade: 
● Teste de integridade; 
● Teste de estrutura; 
● Teste de estresse; 
● Smoke test. 
4. Usabilidade: 
● Teste de interface; 
● Teste de usabilidade. 
5. Funcionalidade: 
● Teste funcional; 
● Teste de regressão; 
● Teste de volume; 
● Teste de segurança. 
6. FURPS: É um acrônimo que representa um modelo de classificação dos atributos de 
qualidade de software (requisitos funcionais e não funcionais). 
 
Já a ISO/IEC 9126­1 apresenta a seguinte categorização: 
 
1. Conectividade: Integração entre componentes (hardware e software); 
2. Continuidade: Capacidade de operar ininterruptamente (Ex.: 24 x 7); 
3. Segurança: A certeza de que o dado somente pode ser alterado por aqueles 
autorizados; 
4. Eficiência: A relação entre os níveis de desempenho do sistema e os recursos; 
5. Funcionalidade: Estar de acordo com a especificação Funcional; 
6. Usabilidade: Facilidade de uso do sistema pelos Usuários; 
7. Performance: Velocidade de processamento da informação; 
8. Portabilidade: Capacidade do programa processar em diversos AmbientesPrincipais Categorias de Teste de Validação 
 
 
 
1 ­ 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. 
 
2 ­ 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 
 
3 ­ 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. 
 
4 ­ 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 
 
5 ­ 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. 
 
6 ­ 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. 
 
7 ­ Teste de Segurança 
 
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. 
 
8 ­ 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 
 
9 ­ 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. 
 
10 ­ 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) 
• Identificar todas as interrupções do ambiente (confiabilidade) 
• Identificar o tempo de interrupção do ambiente (disponibilidade) 
 
11 ­ 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. 
 
12 ­ 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. 
 
Aula 06: Métodos Estruturados de Teste 
 
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 trabalhocom o 
objetivo de identificar o maior 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. 
 
 
Abordagens de Casos de Testes 
 
Os casos de testes são categorizados ou classificados pelo tipo ou requesito de teste ao qual 
estão associados e devemos considerar sempre em desenvolver pelo menos dois casos de 
teste para cada requisito de teste: 
 
● Um caso de teste para demonstrar que o requisito foi atendido, conhecido como caso de 
teste positivo. 
● Um caso de teste, conhecido como negativo, refletindo condições inaceitáveis, anormais 
ou inesperadas demonstrando  que  requisito será atendido sob a condição desejada. 
 
Caso de teste representa um cenário de teste, ou seja, uma situação diferenciada e única de 
comportamento do software. Os casos de testes possuem duas abordagens clássicas de 
testes por: 
 
● Requistos (teste de caixa Preta) 
 
 
 
● Estrutura interna (teste de caixa Branca) 
 
 
 
 
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. 
 
 
 
 
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, 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 essenciais para 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: 
Diagrams de estados e Diagramas de atividades. 
 
● 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 atender 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 
 
Cobertura de desvios condicionais objetiva detectar errosnas 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. 
 
 
 
Conheça os  três níveis de refinamentos para cobrir o maior número de condições 
possíveis. 
 
● Cobertura de decisões ­ Avalia se todas as decisões existentes no código­fonte 
são exercitadas durante a execução dos testes de caixa branca. Em cada 
IF...THEN...ELSE...ENDIF, ou comando similar encontramos fontes, terão casos 
de testes que assumirão valores verdadeiro ou falso, isso garante que toda 
decisão de processamento tenha seus possíveis caminhos exercitados 
adequadamente.  
 
● Cobertura de condições – Focaliza a expressão que representa a condução de 
desvio existente no código­fonte, levando em consideração apenas os comandos 
que executam desvios de processamento.  
 
Por exemplo: uma condição de desvio do tipo:  
 IF idade >= 18 and sexo=”M” then....  
 
Os casos de teste deverão cobrir individualmente todas as condições possíveis. 
Neste caso precisaríamos de três casos de testes para atendermos a todos os 
cenários de execução possíveis:  
 
Caso teste 1= [i=17, s=”M”]  
Caso teste 2= [i=18, s=”F”]  
Caso teste 3= [i=19, s=”F”]  
● Cobertura de Múltiplas Condições – Emprega o mesmo critério do tópico de 
cobertura de condições, diferenciando­se apenas pelo fato de que os casos de 
teste devem contemplar todas as múltiplas combinações possíveis.  
  
Neste modelo caso utilizássemos o exemplo anterior, idade >= 18 and sexo=”M”, 
serão necessários seis casos de testes para atender as múltiplas condições de 
testes:  
  
Caso teste 1= [i=17, s=”M”]  
Caso teste 2= [i=17, s=”F”]  
Caso teste 3= [i=18, s=”M”]  
Caso teste 4= [i=18, s=”F”]  
Caso teste 5= [i=19, s=”M”]  
Caso teste 6= [i=19, s=”F”]  
 
 
 
● 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. 
 
 
 
 
   
Aula 07: Teste de validação e suas fases 
 
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:  
 
1. 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 
● Integração 
 
 
Teste de unidade (Baixo Nível) ­ 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. 
 
● 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ão usados 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. 
 
 
 
 
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.  
 
 
 
 
Teste de Integração (Baixo Nível) ­ 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 ­ 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 ­ Os módulos são integrados 
movendo­se de cima para baixo na hierarquia de controle. Começa­se 
pelo módulode controle principal e os módulos subordinados são 
incorporados à estrutura de uma de duas maneiras:  
 
★ Primeiro­em­profundidade (depth­first): Integra todos os 
componentes em um caminho de controle principal da 
estrutura do controle. A seleção do caminho é arbitrária. 
Por exemplo, poderíamos escolher o caminho da esquerda 
e neste caso, os componentes M1, M2 e M5 seriam 
integrados primeiro, posteriormente M8 ou M6.  
 
 
 
★ Primeiro­em­largura (breadth­first): Incorpora todos os 
componentes diretamente subordinados em cada nível, 
movendo­se através da estrutura horizontalmente. Neste 
caso, no exemplo abaixo os módulos M2, M3 e M4 seriam 
integrados primeiro e em seguida o próximo nível de 
controle M5, M6 e M7. Por último seria integrado o módulo 
M8.  
 
 
 
 
O funcionamento da integração Descendente ocorre da seguinte forma:  
 
★ O módulo de controle principal é usado como pseudocontrolador 
do teste e os pseudocontroladores substituem todos os 
componentes diretamente subordinados ao módulo de controle 
principal.  
★ Dependo da abordagem de integração selecionada os 
pseudocontrolados são substituídos, um de cada vez, pelos 
componentes reais.  
★ Os testes são conduzidos à medida que cada componente é 
integrado.  
★ Ao término de cada conjunto de testes, outro pseudocontrolado é 
substituído pelo componente real.  
★ Ao término de cada conjunto de testes, outro pseudocontrolado é 
substituído pelo componente real.  
★ O teste de regressão pode ser conduzido para garantir que novos 
erros não tenham sido introduzidos.  
 
➔ Integração ascendente ou Botton­up ­ A integração do sistema começa a 
partir do nível mais baixo do software, ou seja, o módulo. O módulo é  
dito como o mais baixo nível se ele não depende de outro módulo. Neste 
tipo de teste assume­se que previamente todos os módulos foram 
individualmente testados. Os módulos são integrados movendo­se  
de baixo para cima na hierarquia de controle.  
  
O funcionamento da integração Ascendente ocorre da seguinte forma:  
★ O teste de regressão pode ser conduzido para garantir que novos 
erros não tenham sido introduzidos.  
★ Um pseudocontrolador é escrito para coordenar a entrada e a 
saída do caso de teste.  
★ O agregado é testado.  
★ Pseudocontroladores são removidos e agregados são 
combinados movendo­se para cima na estrutura.  
  
Neste tipo de abordagem os componentes são combinados para formar 
os agregados (clusters) 1, 2 e 3, conforme a ilustração abaixo. Cada um 
dos agregados é testado usando um pseudocontrolador, que no  
exemplo abaixo é demonstrado com linhas tracejadas.  
 
 
Neste exemplo os agregados 1 e 2 são subordinados a Ma. Após os 
testes dos agregados 1 e 2 os pseudocontroladores D1 e D2 são 
removidos e os agregados interfaceados diretamente com Ma. Os testes  
continuam e os pseucontroladores são removidos a cada integração. A 
medida que a integração se move para cima a necessidade de 
pseudocontroladores de testes separados diminui.  
 
➔ Teste de regressão ­ Os testes de regressão 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.  
  
Toda vez que um novo módulo é adicionado como parte do teste de 
integração, o software se modifica e assim novos caminhos de fluxos de 
dados são estabelecidos, nova E/S pode ocorrer ou ainda nova lógica de  
controle pode ser adicionadas. Essas modificações podem causar 
problemas em funções que previamente funcionavam corretamente.  
  
Os casos de testes de regressão podem ser de três tipos:  
 
★ Casos de teste que abrangem todas as funcionalidades do 
sistema.  
★ Casos de teste apenas para as funcionalidades que foram 
modificadas.  
★ Novos casos de teste para as funcionalidades que provavelmente 
foram afetadas pela mudança.  
 
O teste de regressão é a re­execução de algum subconjunto de testes 
que já foi conduzido para garantir que as modificações não introduzam 
efeitos colaterais indesejáveis. Ele pode ser conduzido manualmente  
ou usando alguma ferramenta automatizada de captação/reexecução e 
que iremos estudar posteriormente.  
 
➔ Teste fumaça ­ Neste tipo de teste o software é reconstruído e testado 
diariamente para dar aos gerentes e desenvolvedores uma avaliação 
realística do progresso.  
  
O funcionamento do Teste Fumaça ocorre da seguinte forma:  
 
★ Os componentes de software são integrados em uma 
“construção”. Esta construção inclui todos os dados, bibliotecas, 
módulos reusáveis e componentes que são necessários para 
implementar uma função do produto.  
★ Uma série de testes é projetada para expor erros que impeçam a 
construção de desempenhar adequadamente a sua função. A 
finalidade deverá ser descobrir erros “bloqueadores” que tem a 
maior chance de atrasar o cronograma.  
★ A construção é integrada com outras construções e o produto 
inteiro é testado diariamente. A abordagem pode ser descendente 
ou ascendente.  
 
2. Teste de Alto Nível 
 
Os testes de alto nível compreendem os testes: 
 
● Sistema 
● Aceitação 
 
 
 
Teste de Sistemas (Alto Nível) ­ 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 ­ O teste de recuperação é um teste de sistema que 
força o software a falhar de várias formas e verifica se a recuperação é 
executada corretamente.  
 
Se a recuperação for automática, a reinicialização, os mecanismos de 
verificação, recuperação de dados e reinício são avaliados quanto à correção. 
Caso a recuperação requeira a intervenção humana , é avaliado o tempo médio 
de reparo (mean­time­to repair – MTTR) para determinar se está dentro dos 
limites aceitáveis.  
 
 
• Teste de segurança ­ O teste de segurança tenta verificar se os mecanismos 
de proteção incorporados ao sistema vão de fato protegê­lo contra acesso 
indevido. A principal meta do teste de segurança é garantir que os dados ou  
funções de um sistema possam ser acessados apenas por atores autorizados a 
acessá­las. Durante o teste de segurança, o testador faz o papel do indivíduo 
que quer invadir o sistema o sistema e desta forma tentará, por exemplo, obter 
senhas por meios externos, sobrecarregar o sistema ou ainda causar erros  
propositadamente. Todas as formas de ataque de acesso indevido devem ser 
simuladas.  
 
Os principais objetivos a serem alcançados com este tipo de teste são:  
 
❏ Assegurar que os mecanismos de controle