Resumo_TesteSoftware

Prévia do material em texto

AULA 1 
 
Teste De Software – Conceito: 
Operação técnica que consiste em determinar se uma ou mais características de um dado produto, processo ou 
serviço estão de acordo com um procedimento especificado (ISO/IEC 1991). 
Agora, vamos definir o conceito de teste de software. Existem diversas definições para testes de software: 
 Avaliar se o software está fazendo o que deveria fazer, de acordo com os seus requisitos, e não está 
fazendo o que não deveria fazer; 
 Processo de executar um programa ou um sistema com a intenção de encontrar defeitos (teste negativo) 
(Glen Myers – 1979); 
 Qualquer atividade que, a partir da avaliação de um atributo ou capacidade de um programa ou sistema 
seja possível determinar se ele alcança os resultados desejados. (Bill Hetzel – 1988). 
 
Importância do teste de software 
Segundo Pressman, o teste de software é um conjunto de atividades que podem ser planejadas com antecedência e 
executadas sistematicamente. Por esta razão devera ser definido um processo de teste de software e um modelo 
(template) para o teste. Uma estratégia de teste de software deve acomodar teste de baixo nível, necessários para 
verificar se um pequeno segmento de código fonte foi implementado corretamente, bem como testes de alto nível, 
que validam as funções principais do sistema de acordo com os requisitos do cliente. Existem muitas estratégias 
de teste de software propostas e todas fornecem um modelo para o teste e tem basicamente as seguintes 
características genéricas: 
 Para executar um teste bem eficaz, proceder as revisões técnicas eficazes. Fazendo isso, muitos erros 
serão eliminados antes do começo do teste. 
 O teste começa no nível do componente e progride em direção a integração do sistema operacional como 
um todo. 
 Diferentes técnicas de teste são apropriadas para diferentes abordagens de engenharia de software e em 
diferentes pontos no tempo. 
 O teste é feito pelo desenvolvedor do software e (para grandes projetos) por um grupo independente de 
teste. 
 O teste e a depuração são atividades diferentes, mas a depuração deve ser associada a alguma estratégia 
de teste. 
 
Uma estratégia de software deverá fornecer diretrizes para o profissional de teste e uma série de metas para o 
gerente. 
Emerson Rios nos dá uma visão histórica da execução dos testes de software: 
 Demonstração – década 70: Garantir que o produto funcione; testes feitos pelos desenvolvedores. 
 Detecção – década de 80/90: Garantir que o produto atenda aos requisitos; testes feitos pelos desenvolvedores e 
usuários; 
 Prevenção – década 90/00: Garantir que o produto funcione, atenda aos requisitos e não tenha defeitos; testes 
executados através de processos de teste; testes feitos pelos desenvolvedores, usurários e testadores. 
 
 
O Processo De Teste De Software 
O processo de teste de software deve se basear em uma metodologia aderente ao processo de desenvolvimento, com 
pessoal técnico qualificado, ambiente e ferramentas adequadas. Esta metodologia de teste deve ser o documento básico 
para organizar a atividade de testar aplicações no contexto da empresa. Assim como o processo de desenvolvimento de 
software, o teste de software também possui um ciclo de vida: 
 
Planejamento 
Procedimentos Iniciais> Especificação>>>> Execução>>>>>>>>> Entrega 
Preparação 
 
Planejamento – Elaboração e revisão da estratégia de teste e do plano de teste 
Procedimentos Iniciais – Consiste na elaboração de documento com o estabelecimento de um acordo entre as 
partes envolvidas no projeto de teste (usuários e técnicos): 
 Objetivo do projeto de teste, 
 Pessoal a ser envolvido, 
 As responsabilidades de cada um; 
 O plano preliminar de trabalho; 
 Avaliação dos riscos; 
 Os níveis de serviços acordados e etc. 
Especificação: Elaboração e revisão dos casos de teste , “scripts” ( no caso de ferramentas de automação de testes) e 
dos roteiros de Teste e execução dos testes de verificação da documentação do sistema (testes estáticos). 
 Execução: Execução dos testes planejados conforme os Casos de Teste, “scripts” e dos roteiros de Teste com os 
correspondentes registros dos resultados obtidos. 
 Entrega: conclusão do processo de testes com a entrega do sistema para o ambiente de produção. 
 Preparação - Preparação do ambiente de teste, incluindo equipamentos, rede, pessoal, software e ferramentas. 
 
Processo de teste 
 
 Verificação: Nesta etapa são realizadas inspeções/revisões sobre os produtos gerados. 
 
 Testes Unitários: São realizados no estágio mais baixo da escala de testes e são aplicados nas menores 
componentes de códigos criados, visando garantir que estes atendem as especificações, em termos de garantia e 
de funcionalidade. Verificam o funcionamento de um pedaço do sistema ou software isoladamente ou que possam 
ser testado separadamente. Normalmente é feito pelos desenvolvedores. 
 
 Testes de integração: São executados em uma combinação de componentes para verificar se ele funcionam 
corretamente juntos, conforme as especificações. Componentes podem ser pedaços de código, módulos, aplicações 
distintas, clientes servidores. Normalmente é feito pelos desenvolvedores. 
 
 Teste de sistema: São realizados pela equipe de testes, visando a execução do sistema como um todo ou um 
subsistema (parte de um sistema), dentro de um ambiente operacional controlado, para validar a exatidão e 
perfeição na execução de suas funções. Neste estágio de teste deve ser simulada a operação normal do sistema, 
sendo testadas todas as suas funções de forma mais próxima possível do que irá ocorrer no ambiente de 
produção. Esses testes são feitos pela equipe de teste de software. 
 
 Teste de aceitação: São os testes finais de execução do sistema, realizados pelos usuários, visando verificar se a 
solução atende aos objetivos do negócio e aos seus requisitos, no que diz respeito À funcionalidade e usabilidade, 
antes da sua utilização no ambinete de produção. 
 
Ao tratar os testes como um processo organizado e muitas vezes paralelo e integrado ao processo de 
desenvolvimento, os custos de manutenção serão reduzidos. Segundo Myers, o custo de correção de defeitos tende a 
aumentar quanto mais tarde o defeito é detectado. Defeitos encontrados durante a produção tendem a custar muito mais 
que defeitos encontrados em modelos de dados e em outros documentos do projeto do software. 
 
 Os testes unitários podem remover entre 30% e 50 % dos defeitos dos programas; 
 Os testes de sistemas podem remover entre 30% e 50% dos defeitos remanescentes. 
 Desse modo, os sistemas podem ir para produção ainda com aproximadamente 49% de defeitos. 
 Por últimos, as revisões de códigos podem reduzir entre 20% e 30% desses defeitos. 
 
AULA 2 
 
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. 
Por que são importantes? 
 Ao se descobrir um erro logo no início do processo, fica menos caro corrigi-lo. Temos que levar em consideração também 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 devido à redução do número de reformulações que serão necessárias ao longo do projeto. 
 
Impacto Dos Defeitos De Software Nos Custos 
 
No contexto de gestão de qualidade, os termos defeito e falha são sinônimos. Ambos implicam em um problema de qualidade que é 
descoberto depois de o software ter sido liberado para os usuários finais. muitas vezes o termo erro é utilizado para indicar um 
problema de qualidade que é descoberto antes do software ser liberado ao usuário final. Utilizamos as revisões técnicas paraencontrar 
erros durante o processo de desenvolvimento, de modo a não se tornarem defeitos depois da liberação do software. A descoberta 
precoce de erros, evita que sejam propagados para a próxima etapa na gestão da qualidade. Segundo Pressman, diversos estudos e 
análise sobre o tema indicam que as atividades de projeto introduzem de 50 a 60% de todos os erros durante a gestão da qualidade. 
Entretanto, técnicas de rescisão demonstraram ser até 75% eficazes na descoberta de falhas no projeto. 
ATENÇÃO 
Detectando e eliminando uni grande percentual desses erros, o processo de revisão reduz substancialmente o custo de atividades 
subsequentes na gestão de qualidade. 
 
 
 
 
Revisões Técnicas Formais (RTF) 
 
As revisões técnicas 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 de revisão é relacionada a fatores como a maturidade 
do processo de desenvolvimento, requisitos legais e reguladores ou a necessidade de acompanhamento de auditoria. O modo como uma 
revisão é conduzida depende do seu objetivo (ex: encontrar defeitos, obter compreensão, discussão ou decisões por um consenso). A 
imagem apresenta um modelo de referência para revisões técnicas, onde são identificadas quatro características que contribuem para a 
formalidade na qual uma revisão é conduzida. 
As revisões técnicas formais (RTF) são realizadas por engenheiros de software e outros profissionais e tem como objetivo: 
- Descobrir erros na função, lógica ou implementação para qualquer representação de soft+,vare; - verificar se o software que está 
sendo revisado atende aos requisitos; - Garantir que o software foi representado de acordo com os padrões predefinidos: - Obter 
software que seja desenvolvido de maneira uniforme; - Tornar os projetos mais gerenciáveis. 
Servem ainda como base de treinamento, possibilitando que engenheiros mais novos observem diferentes abordagens para análise, 
projeto e implementação de software. 
Fases principais: 
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 
formal (ex: inspeçã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 antecipadamente por cada participante da reunião de revisão, tomando nota dos defeitos 
em potenciais, questões e comentários. 
Reunião de revisão 
Retrabalho: 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 certos tipos 
de revisões formais). 
Restrições: 
 Entre 3 e 5 pessoas; 
 Uma preparação antecipada deve ocorrer, mas ela não deve exigir mais de 2h de cada pessoa; 
 A duração da reunião deve ser inferior a 2h. 
 
Uma RTF concentra-se numa parte específica e pequena do software, pois ao estreitar o foco, tem-se a probabilidade maior de 
revelar erros. 
Tipicamente uma reunião é programada para o dia seguinte ao da preparação, e conta com o produtor e os revisores. 
Durante a RTF, um revisor registra ativamente todos os problemas levantados. Estes são sintetizados no final da reunião de revisão 
e é produzida uma lista de problemas de revisão, além do relatório sintetizado da revisão técnica formal. Normalmente o relatório 
sintetizado é um formulário de uma página, cujo anexo é a lista de problemas de revisão. 
O processo de depuração frequentemente ocorre em consequência de um teste. Quando um caso de teste descobre um erro, a 
depuração será o processo que irá resultar na remoção deste erro. 
 O Processo de depuração tenta combinar o sintoma com a causa, levando assim à correção do erro. Normalmente apresentará um 
dentre dois resultados: 
 A causa será encontrada e corrigida; 
 A causa não será encontrada; 
 Independente da abordagem adotada, a depuração tem um objetivo primordial, que é encontrar e corrigir a causa de erro 
ou defeito. 
 Um dos modelos existentes é o modelo genérico de depuração chamado de Hipóteses-Validação. O modelo define a atividade 
de depuração como um processo interativo de síntese, verificação e refinamento de hipótese. 
 
O responsável pela depuração estabelece hipóteses com relação à localização do defeito e à modificação para corrigi-lo. O 
processo de depuração é guiado pela certificação/refutação das hipóteses levantadas, bem como pela geração de novas hipóteses e 
refinamentos das já existentes. Segundo Pressman, o objetivo da depuração é alcançado por uma combinação de avaliação 
sistemática, intuição e sorte, sendo definido basicamente três estratégias (Myers): 
1. Força bruta 
 Método mais comum e menos eficiente; 
 Usado quando os outros métodos falham; 
 Faz-se imensa quantidade de teste, mas sem planejamento. 
2. Rastreamento (backtracking) 
 A partir do local do sintoma descoberto, rastreia-se para trás até encontrar a causa; 
 Bastante comum, porém restrita a programas pequenos, pois o número de caminhos retroativos 
potenciais pode ser muito alto; 
 Em sistemas/programas médios/grandes é ineficiente; 
3. Eliminação da causa 
 Os dados relacionados à ocorrência de erros são organizados para isolar causas em potencial; 
 Uma “hipótese de causa” é imaginada e dados acima são usados para provar ou reprovar a 
hipótese; 
 Uma lista de todas as causas possíveis é desenvolvida e testes são realizados para eliminar cada 
uma. 
 Efetuar testes e depuração é um traço humano inato; 
 Certas pessoas são boas para fazer isso, outras não; 
 A depuração é uma das partes mais frustrantes da programação. Ela indica o reconhecimento de 
que erramos; 
 A elevada ansiedade, a pressão, o tempo curto, a pouca disposição para aceitar a possibilidade de 
erro, aumenta a dificuldade da tarefa; 
 Quando um erro é enfim corrigido, vem um grande suspiro de alívio e uma diminuição da tensão. 
 
Segundo Pressman, uma vez encontrado o erro, ele precisa ser corrigido. A correção de um defeito pode introduzir outros erros e, 
portanto, causar mais danos do que trazer benefícios. Segundo Van Vleck, três perguntas devem ser feitas antes de fazer a “correção” 
que remove a causa de um defeito. 
 
AULA 3 
Testes de Caixa branca e preta 
Os produtos de software podem ser testados através de duas visões: 
 Conhecendo-se a função específica para o qual o produto foi projetado para realizar; 
 Conhecendo-se como é o trabalho interno de um produto; 
 Quando conhecemos a função específica de um software e realizamos teste que demonstrem que cada função está plenamente 
operacional, e ao mesmo tempo, procurem erros em cada função, dizemos que estamos realizando teste de caixa preta. Este tipo de teste 
é conduzido na interface do software e examina aspectos fundamentais do sistema, pouco se preocupando com a estrutura interna do 
software.Quando sabemos como é o trabalho interno do software e realizamos testes para garantir que as operações internas foram 
adequadamente exercitadas, estamos realizando teste de caixa-branca. Este tipo de teste é baseado em um exame rigoroso do detalhe 
procedimental e dos caminhos lógicos internos do software. 
 
Teste De Caixa-branca 
 
O teste de caixa branca, segundo pressman também chamado de teste de caixa-de-vidro, utiliza a estrutura de controle descrita no 
programa para derivar o casos teste. São baseados nos elementos internos de um trecho de programa. O objetivo é encontrar o menor 
número de casos de teste que permita que todos os comandos de um programa sejam executados pelo menos uma vez. Os casos de teste 
são determinados a partir das estruturas de controle do programa e desta forma forçar que todos os caminhos possíveis do fluxo de 
controle do programa sejam percorridosdurante os testes. Desta forma é 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 falso; 
3. Executam todos os ciclos em seus limites e dentro de suas fronteira operacionais; 
4. Exercitam estruturas de dados internas para assegurar sua validade. 
 
Existem diferentes tipos de testes de caixa branca que podem ser subdivididos em: 
 
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. O passo inicial é determinar 
todos os caminhos possíveis. Normalmente utiliza-se um grafo de fluxo de controle do programa. O gráfico permite identificar os 
caminhos possíveis para que se possa elaborar os casos de uso. Como cada caminho é definido pelas expressões condicionais das 
estruturas de controle, devem-se determinar os casos de teste escolhendo valores de variáveis para os casos nos quais cada uma das 
expressões sejam verdadeiras ou não. Os seguintes passos podem ser aplicados: 
1. Usando o projeto ou o código como base, desenhar o grafo de fluxo correspondente; 
2. Determinar a complexidade ciclomática do diagrama de fluxo resultante. 
3. Determinar um conjunto base de caminhos linearmente independentes. 
4. Preparar casos de teste que vão forçar a execução de cada caminho do conjunto base. 
5. 
A Complexidade Ciclomática é uma métrica de software que proporciona uma medida quantitativa da complexidade lógica de um 
programa. Quando usado no contexto do método de teste do caminho básico, o valor computado da complexidade ciclomática define o 
número de caminhos independentes do conjunto básico de um programa e oferece-nos um limite máximo para o número de testes que deve 
ser executado para garantir que todas as instruções são, executadas pelo menos uma vez 
 
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 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. 
 
 
Teste De Ciclos 
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: 
 Laços Simples: deve ser aplicado o seguinte conjunto de teste: 
 Pule o laço inteiramente; 
 Somente uma passagem através do laço; 
 Duas passagens através do laço; 
 m passagens através do laço, onde m < n; 
 n-1, n, n+1 passagens através do laço. 
 Laços Aninhados: 
 Inicie pelo laço mais interno. Fixe os outros laços para valores mínimos. 
 Realize testes de laços simples para o laço mais interno. 
 Trabalhe para fora, realizando testes para o laço seguinte, mas mantendo todos os ciclos externos nos valores 
mínimos 
 Continue até que todos os laços tenham sido testados. 
 Laços Concatenados: 
1. Se laços independentes dos demais: 
 - usar abordagem de laços simples. 
2. Se contador de laços para o laço 1 for usado como valor inicial para o laço 2: 
 - usar abordagem de laços aninhados. 
 Laços não estruturados: 
Sempre que possível, esta classe deve ser reprojetada para refletir o uso das construções de programação estruturada. 
 
Embora o teste de caminho básico seja simples e altamente eficaz, ele sozinho não é suficiente. Normalmente utiliza-se uma combinação 
com os outros testes para ampliar a abrangência do teste e melhorar a qualidade dos teste de caixa branca. 
 
Teste De Caixa-preta 
O teste da caixa preta, também conhecido como teste comportamental, focaliza os requisitos funcionais do software. Este tipo de teste 
complementa o teste da caixa branca, pois permite descobrir uma classe de erros diferentes daquela obtida com métodos da caixa-
branca. 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? 
 Desta forma o teste de caixa-preta tenta 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. 
 
Existem diferentes métodos de testes de caixa-preta que podem ser subdivididos em: 
 Baseado 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. A 
representação simbólica é mostrada na imagem. Existe uma série de métodos de testes comportamental que utilizam grafos: 
 Modelagem de fluxo de transação: O nós representam passos em alguma transação, e as ligações representam a 
conexão lógica entre os passos. 
 Modelagem de Estado Finito: Os nós representam diferentes estados observáveis pelo usuário do software e as 
ligações representam as transições que ocorrem para mover de um estado para outro. 
 Modelagem de Fluxo de Dados: Os nós são objetos de dados e as ligações são as transformações que ocorrem para 
traduzir um objeto dados em outro. 
 Modelagem de Tempo: são objetos de programa, e as ligações são conexões sequenciais entre aqueles objetos. Pesos 
de ligação são usados para especificar os tempos de execução necessários enquanto o programa é executado 
 
AULA 4 
 
A qualidade, segundo Pressman (2011) é incorporada a uma aplicação Web como consequência de um bom projeto. “Não se pode 
testar a qualidade. Se ela não estiver lá antes de você começar a testar, não estará lá quando você tiver terminado de testar.” 
(Pressman).A qualidade é incorporada ao software em todo o processo de engenharia de software. 
 Conteúdo: é avaliado no nível semântico e sintático. No nível sintático examina-se a ortografia, pontuação e gramática. No 
nível semântico são verificadas a exatidão, consistência e ausência de ambiguidade das informações. 
 Função: é testada para descobrir erros que indicam falta de conformidade com os requisitos do cliente. 
 Estrutura: É avaliada para assegurar o fornecimento apropriado do conteúdo e função da aplicação. Que seja extensível e 
possa ser mantida à medida que novo conteúdo ou funcionalidade é adicionado 
 Usabilidade: é testada para garantir que cada categoria de usuário seja suportada pela interface. 
 Navegabilidade:é testada para assegurar que toda a sintaxe e semântica de navegação sejam experimentadas para descobrir 
quaisquer erros de navegação. 
 Desempenho: é testado sob uma variedade de condições de operação, configuração e carga para assegurar que o sistema 
responda à interação com o usuário e suporte cargas extremas sem degradação inaceitável de operação. 
 Compatibilidade: é testada executando-se a aplicação em uma variedade de diferentes configurações hospedeiras tanto no 
lado cliente quanto no lado servidor. 
 Interoperabilidade: é testada para garantir que a aplicação tenha uma interface adequada com outras aplicações e/ou bases 
de dados. 
 Segurança: é testada para investigar vulnerabilidades potenciais e tentar explorar cada uma delas. Qualquer tentativa bem-
sucedida de invasão é considerada falha de segurança. 
 
Processo de teste na web 
O processo de teste da aplicação web começa com testes que verificam o conteúdo e a funcionalidade da interface, posteriormente são 
verificados aspectos da arquitetura do projeto e da navegação da aplicação e finaliza com os testes que examinam os recursos 
tecnológicos. Podemos observar melhor o processo de teste na web através da figura abaixo, representado através de uma pirâmide, os 
elementos que são visíveis ao usuário, são testados em primeiro lugar. O fluxo do nosso processo de teste começa da esquerda para a 
direita e de cima para baixo, começando pelo teste de conteúdo, teste de interface, teste de navegação, de componente....e • finalizando 
com os testes de configuração, desempenho e seguranca. 
1. O modelo de conteúdo é revisto para descobrir erros; 
2. O modelo de interface é revisto para garantir que todos os casos de uso possam ser acomodados; 
3. O modelo de projeto da aplicação é revisto para descobrir erros de navegação; 
4. A interface com o usuário é testada para descobrir erros nos mecanismos de apresentação e/ou navegação; 
5. Os componentes funcionais são submetidos a testes de unidade; 
6. É testada a navegação por toda a arquitetura; 
7. A aplicação Web é implementada em uma variedade de configurações ambientais diferentes e testada quanto à 
compatibilidade com cada configuração; 
8. São executados testes de segurança na tentativa de explorar vulnerabilidades na Aplicação ou em seu ambiente; 
9. São realizados testes de desempenho; 
10. A aplicação é testada por uma população de usuários finais controlados e monitorados e os resultados de suas interações com 
o sistema são avaliados quanto a erros de conteúdo e navegação, usabilidade, compatibilidade, segurança, confiabilidade e 
desempenho. 
 
Teste De Conteúdo 
O teste de conteúdo tenta descobrir erros antes que sejam encontrados pelos usuários. Ele combina tanto as revisões, já estudadas nas 
aulas anteriores, quanto a geração de casos de tese executáveis. Os testes de conteúdo têm três importantes objetivos: 
 Descobrir erros de sintaxe 
 Descobrir erros de semântica; 
 Encontrar erros na organização ou estrutura do conteúdo apresentado ao usuário final. 
Normalmente são usados verificadores automáticos de ortografia e gramática, porém, como muitos erros fogem à detecção pelas 
ferramentas, utiliza-se também um revisor humano. O revisor deverá responder as seguintes perguntas: 
 As informações são precisas? 
 As informações são concisas e direcionadas ao assunto? 
 É fácil para o usuário entender o layout do objeto do conteúdo? 
 As informações apresentadas são consistentes internamente e consistentes com as informações apresentadas em outros 
objetos de conteúdo? 
 Foram fornecidas referências apropriadas para todas as informações derivadas de outras fontes? 
 O conteúdo é ofensivo, confuso ou dá margem a litígio? 
 O conteúdo desrespeita os direitos autorais existentes ou de marcas registradas? 
 O conteúdo contém links que complementam o conteúdo existente? Os links estão corretos? 
 O estilo estético do conteúdo está em conflito com o estilo estético da interface? 
 
Teste de interface com o usuário 
A verificação e a validação de uma interface de usuário ocorrem em três pontos distintos: 
Durante a análise - garantir que esteja de acordo com os requisitos do cliente; 
Durante o projeto - garantir que critérios genéricos de qualidade e que tópicos específicos foram tratados; 
Durante o teste - execução de tópicos específicos relativos à interação como usuário e fornece uma avaliação final da 
usabilidade. 
Tem como objetivo descobrir erros relacionados com os mecanismos específicos da interface e descobrir erros na maneira 
como a interface implementa as semânticas de navegação, as funcionalidades da aplicação ou ainda na exibição do conteúdo. Desta 
forma podemos distinguir basicamente quatro tipos de testes: 
Testes de mecanismos de interface: Avalia a interação de cada mecanismos oferecido ao usuário através da interface: link, 
formulários, script executado pelo cliente, janelas pop up e etc. 
Teste de semântica da interface: Avalia como o projeto se preocupa com os usuários. 
Teste de usabilidade: determina o grau com o qual a interface da aplicação facilita a vida do usuário. 
Teste de compatibilidade: Diferentes computadores, dispositivos de imagem, sistemas operacionais, navegadores e 
velocidades de conexão de rede pode ter influência significativa na operação da aplicação Web. 
O teste de componente, também conhecido como teste de função, tem como objetivo tentar descobrir erros nas funções da 
aplicação Web. Cada uma destas funções é um componente de software que pode ser implementados através de diferentes linguagens e 
testados através de teste de caixa-preta ou ainda de caixa-branca, ambos já estudados. Cada caso de teste de componente especifica 
todos os valores de entrada e saída esperada a ser fornecida pelo componente. Em muitas situações, a execução correta de uma função 
da aplicação está ligada ao interfaceamento correto com um banco de dados que pode ser externo a aplicação, desta forma, o teste 
de banco de dados torna-se parte importante do teste de componente. 
 
Teste De Navegação 
O objetivo do teste de navegação é garantir que os mecanismos que permitem ao usuário navegar através da aplicação Web 
estejam todos em funcionamento e que, cada unidade semântica de navegação (NSU – navigation semantic unit) possa ser alcançada 
pela categoria apropriada de usuário. Desta forma, este tipo de teste abrange: 
Links de navegação: Cada link deverá ser testado para assegurar que o conteúdo ou funcionalidade apropriada sejam 
alcançados quando o link é escolhido. 
Redirecionamentos: Quando um usuário solicita uma URL não existente ou seleciona um link cujo conteúdo foi removido, é 
exibida uma mensagem para o usuário e a navegação é redirecionada para outra página. 
 Mapas do site: Como o mapa do site fornece uma tabela completa de conteúdo para todas as páginas da web, cada entrada 
deverá ser testada. 
 Dispositivos de busca interna: Muitas aplicações, devido a quantidade de informações existentes, implementam mecanismos 
de busca. Deverá ser testado o teste destes mecanismos para validar a precisão e a totalidade da busca. 
Marcadores de páginas (Booksmarks): Apesar de ser uma função do navegador, deverá ser testado para assegurar que 
possa ser extraído um título de página com significado quando o marcador for criado. 
Molduras e conjunto de molduras: Cada moldura tem o conteúdo de uma página web específica. Um conjunto de moldura 
permite que várias páginas sejam exibidas ao mesmo tempo. O conjunto de molduras deverá ser testado quanto ao correto conteúdo, 
layout, dimensionamento apropriados e quanto a compatibilidade com o navegador. 
A unidade semântica de navegação (NSU) pode ser exemplificada por um conjunto de caminhos de navegação que conectam 
nós de navegação (por exemplo, páginas Web, objetos de conteúdo ou funcionalidade) que permite ao usuário satisfazer requisitos 
específicos definidos por um ou mais casos de uso para uma categoria de usuário. Neste caso o teste semânticodeverá responder as 
seguintes perguntas: 
 A NSU é atendida sem erro? 
 Cada nó de navegação é acessível no contexto dos caminhos de navegação definidos para a NSU? 
 Todos os caminhos relevantes foram testados? 
 Se forem fornecidas instruções pela interface de usuário para ajudar na navegação as instruções são corretas e inteligíveis à 
medida que a navegação ocorre? 
 Existe algum mecanismo para voltar a um nó de navegação anterior e ao início do caminho de navegação? 
 Se uma função é executada em um nó e ocorre um erro no processamento da função, a NSU pode ser completada? 
 Todos os nós podem ser acessados do mapa do site? Os nomes dos nós têm significado para os usuários finais? 
Os testes de navegação, bem com o teste de interface e de usabilidade, devem ser feitos além dos testadores, também por diferentes 
clientes, sempre que possível! 
 
Teste de Configuração 
O objetivo do teste de configuração (Pressman, 2011) é testar um conjunto de prováveis configurações do cliente e do servidor 
para assegurar que a experiência do usuário seja a mesma em todos os casos e isolar erros que podem ser específicos a uma 
determinada configuração. 
 Servidor - No lado Servidor, os casos de teste de configuração são projetados para verificar se a configuração do 
servidor pode suportar a aplicação sem erro. Devem ser respondidas as seguintes perguntas: 
1. A aplicação é totalmente compatível com o sistema operacional do servidor? 
2. Os arquivos de sistema, diretórios e dados de sistema relacionados são criados corretamente quando a 
aplicação está operacional? 
3. As medidas de segurança permitem que a aplicação seja executada sem a interferência ou degradação do 
desempenho? 
4. A aplicação está adequadamente integrada com o software de banco de dados? 
5. Os scripts utilizados pela aplicação executam corretamente? 
 Cliente - No lado cliente, o teste de configuração foca a compatibilidade da aplicação com configurações dos seguintes 
componentes: 
1. Hardware: CPU, memória, armazenamento e dispositivo de impressão; 
2. Sistemas operacionais: Linux, Macintosh OS, Microsoft; 
3. Software Navegador: Firefox, Safari, Internet Explorer, Opera, Chrome; 
4. Componentes de interface de usuário: Active X, java Applets; 
5. Plug-ins: QuickTime, RealPlayer; 
6. Conectividade: Cabo, DSL, modem, WI-FI. 
Os testes de configuração do cliente devem ser projetados onde cada categoria de usuário será avaliada, para 
determinar as prováveis configurações que serão encontradas. 
 
 
Teste de Desempenho 
À medida que aumenta o número de usuários nas aplicações webApp, ocorre um aumento do número de transações online 
ou na quantidade de dados através das operações de download ou upload. É muito frustrante para um usuário quando uma aplicação 
leva muitos minutos para carregar o conteúdo ou quando recebe do servidor uma mensagem do tipo “servidor ocupado”. O teste de 
desempenho é usado para descobrir problemas de desempenho que podem resultar, por exemplo, da falta de recursos no lado do 
servidor, da largura da banda ou dos recursos de banco de dados inadequados. A intenção é entender como os sistemas respondem 
quando a carga aumenta e ainda reunir métricas que conduzirão a modificações de projeto para melhorar o desempenho. Número de 
usuários, número de transações ou volume geral de dados. 
O teste de desempenho irá ajudar, neste caso, a responder as seguintes questões: 
 O tempo de resposta do servidor degrada de forma a tornar-se inaceitável? 
 Em que ponto, sob o ponto de vista dos usuários, transações ou cargas de dados, o desempenho se torna inaceitável? 
 Quais componentes do sistema são responsáveis pela degradação do desempenho? 
 Qual o tempo médio de resposta para usuários sob diferentes condições de carga? 
 A degradação do desempenho tem um impacto sobre a segurança do sistema? 
 A confiabilidade ou precisão da Aplicação é afetada quando a carga no sistema aumenta? 
 O que acontece quando são aplicadas cargas maiores do que a capacidade máxima do servidor? 
 A degradação de desempenho tem impacto sobre os lucros da empresa? 
 
AULA 5 
 
As estratégias de teste de software fornecem um roteiro que descreve os passos a serem executados corno parte do teste, 
define também quando esses passos serão planejados e então executados, quanto esforço de trabalho, tempo e recursos serão 
necessários. Desta forma, qualquer estratégia de teste deve incorporar planejamento dos testes, projeto de casos de teste, execução dos 
testes, coleta e avaliação dos dados resultantes. 
 
Estratégias para teste de software 
Ao desenvolvermos uma estratégia de teste de software desejamos responder as seguintes perguntas: 
1. Como conduzir os testes de software? 
2. Devemos estabelecer um plano formal para os testes? 
3. Devemos testar o programa como um todo ou executar testes somente em urna parte dele? 
4. Devemos refazer os testes quando acrescentamos novos componentes ao sistema? 
5. Quando devemos envolver o cliente? 
 
Quem os realiza? 
Normalmente, para que o processo de teste transcorra de forma íntegra é comum a utilização de um grupo independente de 
teste, já que as pessoas que criaram o software não devem ser as que irão realizar os testes. Seria um conflito de interesses, pois foram 
elas que o desenvolveram. Normalmente este grupo trabalha de forma conjunta e existem testes que somente são conduzidos pelos 
desenvolvedores, como o teste de unidade que iremos estudar mais adiante. Uma estratégia de teste de software é desenvolvida pelo 
gerente de projeto, pelos engenheiros de software e pelos especialistas em testes. 
Líder do projeto de testes - Responsável pela liderança de um projeto de teste, geralmente relacionado a um sistema em 
desenvolvimento, seja um projeto novo ou manutenção. 
Arquiteto - Responsável pela montagem da infraestrutura de teste, monta o ambiente de teste, escolhe as ferramentas de teste 
e capacita a equipe para executar seu trabalho neste ambiente. 
Analista de Teste - Responsável pela modelagem e elaboração dos casos de teste e pelos scripts de teste. Em alguns casos, os 
scripts podem ser elaborados pelos testadores. 
Testador - Responsável pela execução dos casos de teste e scripts. 
Por que é importante? 
Muitas vezes o teste requer mais trabalho de projeto do que qualquer outra ação da engenharia de software. 
Consequentemente caso seja feito casualmente, erros podem passar sem ser detectados. Lembra do teste de software para ambientes 
críticos? (ex.: controle de voo, monitoramento de reatores nucleares, etc.) ele pode custar de três a cinco vezes mais do que todos os 
outros passos de engenharia de software combinados. A especificação do teste documenta a abordagem da equipe de software para o 
teste, que descreve uma estratégia global e um procedimento designando etapas específicas de teste e os tipos de testes que serão feitos. 
Após a definição da estratégia de testes é necessário criar o ambiente de teste, que não é apenas uma configuração de hardware, mas 
toda uma estrutura a ser considerada onde o teste será executado. 
 Pessoal: Usuários; Desenvolvedores; Testadores. 
 Hardware: Plataforma; Impressoras; Scanners; 
 Software: Software a ser testado; Sistema operacional; Software de teste, procedimentos. 
 Suprimentos: Papel; Formulários; Cartuchos de Tinta. 
 Rede: Protocolos; Autorizações; Usuários. 
 Documentação: Requisitos; Design; Cartuchos de Tinta. 
 Ambiente físico: Local; Segurança; Estrutura. 
 
Quais são as etapas envolvidas? 
 Conforme a imagem, os testes iniciais, também conhecidos como teste de unidade, focalizam um único componente e se 
aplicam para descobrir erros nos dados e na lógica de processamento destes componentes. Posteriormente, cada componente testado 
deve ser integrado. Neste momento ocorre o teste de integração, cuja preocupação é verificar problemas associados à construção do 
programa. Após esta fase, ocorrem testes de ordem superior, como por exemplo, o teste de validaçãocom o objetivo de garantir que o 
software satisfaça a todos os requisitos informativos, funcionais, comportamentais e de desempenho. A última etapa de teste de ordem 
superior é o teste de sistema, que verifica se todos os elementos se combinam corretamente e se a função/desempenho global do 
sistema é conseguida. 
 
Quais são as etapas envolvidas? 
 Assim como o processo de software, uma estratégia de teste de software também pode ser vista como uma espiral. O processo 
de software começa com a análise dos requisitos de software, evolui para o projeto e, finalmente, a codificação do software. Já uma 
estratégia de teste de software percorre a espiral de forma inversa. Começa com o teste de unidade implementado no código fonte, 
passa pelo teste de integração, em que o foco está no projeto e construção da arquitetura de software, passa pelo teste de validação cujo 
objetivo é validar os requisitos estabelecidos em relação ao software criado e, finalmente, o teste de sistema, no qual o software e outros 
elementos são testados como um todo. 
 
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. Este tipo de teste é aplicado nos menores componentes de código criado, visando garantir que estes 
atendam 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 imagem. 
 
Procedimentos de teste de unidade 
1. 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 (driver) e/ou um pseudocontrolado (stub) para cada teste de unidade. 
2. 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 e 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. 
3. 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 unidade no contexto de Software orientado a objeto 
 Quando consideramos o software orientado a objeto, o conceito de unidade se modifica. Não podemos mais testar uma única 
operação isoladamente como no desenvolvimento convencional, mas como parte de uma classe. Neste caso, uma classe encapsulada é 
usualmente o foco do teste de unidade e as operações (métodos) dentro da classe são as menores unidades testáveis. Uma classe pode 
conter um conjunto de diferentes operações, e uma operação em particular pode existir como parte de um conjunto de diferentes 
classes. Assim, o teste de classe para software OO é o equivalente ao teste de unidade para software convencional e foca nas operações 
encapsuladas na classe e pelo estado de comportamento da classe. 
 
Verificação e Validação 
 A atividade de teste de software é uma parte de um tema mais amplo que é chamado de Verificação e Validação. 
 Verificação - conjunto de atividades que garante que o software implemente corretamente uma função específica. 
 Validação - conjunto de atividades que garante que o software que foi construído é adequado às exigências do cliente. 
Segundo Boehm: 
 Verificação - “Estamos construindo certo o produto?” 
Validação - “Estamos construindo o produto certo?” 
 
“Não se pode testar a qualidade. Se ela não estiver lá antes de você começar a testar, não estará lá quando você tiver terminado de 
testar.” (Pressman). A qualidade é incorporada ao software em todo o processo de engenharia de software. A aplicação adequada de 
métodos e ferramentas, RTFs e um gerenciamento e medição sólidos, todos levam à qualidade que é confirmada durante o teste. 
 
AULA 6 
 
Teste de integração 
 O teste de integração focaliza o pacote de software completo e trata da verificação do programa como um todo. Esse 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 Incrimental (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. 
 Incrimental - Incremental: Esse 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. 
Nesse contexto, existem várias estratégias incrementais de integração: 
o Integração descendente ou Top-down. 
o Integração ascendente ou Botton-up. 
o Teste de regressão. 
o Teste fumaça. 
 
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ódulo de controle principal 
e os módulos subordinados são incorporados à estrutura de uma de duas maneiras: 
 Primeiro em profundidade 
 
 Primeiro em largura 
 
 
 
 
 
Como funciona a integração Descendente? 
 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 
 O teste de regressão pode ser conduzido para garantir que novos erros não tenham sido introduzidos. 
 
Desvantagem da Integração Descendente 
 
O processamento nos níveis baixos da hierarquia pode ser necessário para testar adequadamente os níveis superiores porém, como são 
usados pseudocontrolados, nenhum dado significativo flui para cima na estrutura do programa. Para resolver esse tipo de questão, três 
soluções são possíveis: 
 
 Adiar alguns testes. 
 Desenvolver pseudocontrolados mais complexos. 
 Integrar o software de baixo para cima: integração ascendente. 
 
Integração Ascendente ou Bottom-up 
 Na técnica 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. Nesse 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. 
 
Como funciona a integração Ascendente? 
 Componentes de baixo nível são combinados em agregados (clusters) que realizam uma subfunção específica 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 
 
Nesse 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. 
 Nesse exemplo, os agregados 1 e 2sã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: 
1. Casos de teste que abrangem todas as funcionalidades do sistema. 
2. Casos de teste apenas para as funcionalidades que foram modificadas. 
3. 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/re-
execução e que iremos estudar posteriormente. 
A utilização de ferramentas automatizadas irá permitir ao engenheiro de software captar casos de teste e resultados para 
reexecução e comparação, pois, à medida que o teste de integração prossegue, o número de testes de regressão pode crescer 
significativamente. Assim, a suíte de testes de integração deve ser projetada para incluir apenas testes que cuidam das principais funções do 
programa. 
 
Teste fumaça 
Nesse tipo de teste o software é reconstruído e testado diariamente, para dar aos gerentes e desenvolvedores uma avaliação 
realística do progresso. Como funciona o Teste Fumaça 
 Os componentes de software são integrados em uma “construção”. Essa 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 têm 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. 
 
Benefícios do Teste Fumaça 
O risco de integração é minimizado já que incompatibilidades e outros erros de bloqueio são descobertos logo no início, evitando 
impactos no cronograma. 
• A qualidade do produto final é aperfeiçoada, pois, tanto erros funcionais quanto defeitos de projeto arquitetural podem ser 
descobertos. 
• Diagnóstico e correção de erros são simplificados, pois, o software que acabou de ser adicionado às construções é uma causa 
provável do erro recém-descoberto. 
• O progresso é fácil de avaliar, pois como a cada dia que passa, o teste está mais integrado ao software, demonstrando como ele 
funciona. 
 
Documentação do Teste de Integração 
 O documento de especificação de teste é um produto de trabalho e torna-se parte da configuração de software. Ele especifica os 
seguintes documentos: 
• Plano de teste global para integração do software. 
• Descrição dos testes específicos. 
O teste é dividido em fases e construções que tratam de características funcionais e comportamentais específicas do software e está 
relacionada a um domínio específico dentro da arquitetura do software: 
• Integridade da interface: as interfaces interna e externa são testadas à medida que cada módulo é incorporada a estrutura. 
• Validade funcional: São executados testes destinados a descobrir erros funcionais 
• Conteúdo de informação: São executados testes para descobrir erros associados com estruturais de dados globais ou locais 
• Desempenho: São executados testes destinados a verificar os limites de desempenho estabelecidos durante o projeto do software 
 
O plano de teste deve conter: 
• Um cronograma para a integração; 
• Breve descrição do software de uso geral (pseudocontroladores e pseudocontrolados); 
• Descrição do ambiente e recursos do teste; 
• Procedimento detalhado de teste que é necessário para realizar o plano de teste; 
• A ordem de integração e os testes correspondentes em cada etapa de integração; 
• Lista de todos os casos de testes e dos resultados esperados; 
 
Teste de integração no contexto de Software Orientado a Objeto 
 
No contexto de software orientado a objeto, o teste de integração não apresenta uma estrutura óbvia hierárquica. As estratégias de 
integração ascendente e descendente perdem o significado, porém há duas estratégias existentes para o contexto OO: 
 
• Teste baseado no caminho de execução: Integra o conjunto de classes necessárias para responder a uma entrada ou evento do 
sistema. 
• Teste baseado no uso: Começa a construção do sistema testando as classes que usam poucas (ou nenhuma) classes servidoras. 
 
O uso de pseudocontroladores e pseudocontrolados também muda quando é executado o teste de integração de sistemas OO: 
 
• Pseudocontroladores podem ser usados para testar operações no mais baixo nível e testar grupos inteiros de classes e para 
substituir a interface com o usuário. 
• Pseudocontrolados podem ser usados em situações nas quais a colaboração entre classes é necessária. 
 
Teste de Validação 
O teste de validação começa quando termina o teste de integração, quando o software está complementarmente montado como um 
pacote e os erros de interface já foram descobertos e corrigidos. Nesse tipo de teste, a distinção entre software convencional e software 
orientado a objeto desaparece. Ele focaliza ações visíveis ao usuário e saídas do sistema reconhecíveis pelo usuário, o foco está no nível de 
requisitos e podem ser divididos em: 
• Teste Alfa - Como é praticamente impossível para um desenvolvedor de software prever como o cliente usará um 
programa de forma que as instruções de uso do programa não sejam mal interpretadas, nem tampouco, que possam 
ocorrer combinações estranhas de dados que poderão ser usadas regularmente ou ainda que resultados que pareciam 
claros para o testador e sejam confusos para um usuário, é aplicado o teste alfa. Esse tipo de teste é 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. Esse 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, nesse 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, aindanão foi 
lançado oficialmente. 
 
Critério de teste de validação 
A validação de software é conseguida através de uma série de testes que demonstram conformidade com os requisitos. Dessa forma, 
o plano de teste descreve as classes de testes a serem conduzidas e um procedimento de teste define casos de teste específicos destinados a: 
 
garantir que todos os requisitos funcionais sejam satisfeitos; 
todas as características comportamentais seja obtidas; 
todo o conteúdo seja preciso e adequadamente apresentado; 
todos os requisitos de desempenham sejam atendidos; 
a documentação esteja correta. 
 
Após cada caso de teste de validação ter sido conduzido, existe uma entre duas possibilidades: 
1. A característica de função ou desempenho está de acordo com a especificação e é aceita 
2. Descobre-se um desvio da especificação e é criada uma lista de deficiência 
 
AULA 7 
 
Teste 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. 
“Não é apenas uma configuração de hardware, mas toda estrutura onde o teste será executado”. 
 Ambiente de desenvolvimento – Testes: Unitário e Integração 
 Ambiente de testes – Testes: Integração, Sistema, Regressão, Aceitação 
 Ambiente de produção – Testes, Estresse, Performance 
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: 
Especificação de riscos e/ou de requisitos >>>> Processos de negócios >>>> Casos de uso 
 
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 > Teste de Desempenho > Teste de Disponibilização 
Teste de recuperação 
 O teste de recuperação é um teste de sistema que força o software a falhar de varias formas e verifica se a recuperação é executa 
corretamente. Se a recuperação for automática, a reinicialização, os mecanismos de verificação, recuperação de dados e reinicio são avaliados 
quanto a correção. Caso a recuperação requeira a intervenção humana, é avaliado o tempo médio de repado (mean-time to repair – MTTR) 
para determinar se esta 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 protege-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 contra acessos indevidos foram corretamente implementados 
 Analisar as ameaças e vulnerabilidades, tanto físicas quanto lógicas 
 Garantir que os dados do sistema estão protegidos adequadamente 
 Assegurar que todos os riscos que envolvem os acessos indevidos foram identificados 
 
Teste de desempenho 
 O teste de desempenho ou performance, como também é conhecido, mede e avalia o tempo de resposta, o número de transações e 
outros requisitos sensíveis ao tempo de resposta do sistema. Este tipo de teste é feito em todas as etapas no processo de teste, inclusive em 
nível de unidade, já que o desempenho de um módulo individual pode ser avaliado durante o teste. Entretanto o desempenho de um sistema 
só pode ser avaliado depois que todos os elementos do sistema estiverem totalmente integrado. Os principais objetivos a serem alcançados 
com este tipo de teste são: 
 Determinar o tempo de resposta das transações 
 Verificar se os critérios de desempenho estabelecidos estão sendo atendidos 
 Identificar pontos de gargalo no sistema 
 Verificar o nível de utilização do hardware e software 
Normalmente este tipo de teste requer instrumentação de hardware e software, tendo em vista a necessidade da medição dos recursos 
utilizados de forma precisa. Nas próximas aulas estudaremos sobre estas ferramentas automatizadas de teste. 
Teste de disponibilização 
 O teste de disponibilização também conhecido como teste de configuração, exercita o software em cada ambiente no qual deve 
operar, tendo em vista que muitos softwares operam em uma variedade de plataformas e sob mais de um ambiente de sistema operacional. 
Este tipo de teste examina todos os procedimentos de instalação e software de instalação que serão utilizados pelos clientes e toda a 
documentação que será usada para fornecer o software para os usuários finais. Pode inclusive abranger combinações de navegadores com 
vários sistemas operacionais diferentes. 
Teste de esforço 
 O teste de esforço também conhecido como teste de estresse colocam os programas em situações anormais 
“Até onde podemos forçar o sistema até que falhe?” 
A principal meta do teste de esforço é entender o comportamento do sistema durante condições-limite de execução ou fora da tolerância 
esperada. Tipicamente envolve a execução do sistema com baixos recursos de hardware e software, ou a concorrência por estes recursos. 
Os principais objetivos a serem alcançados neste tipo de teste são: 
 Determinar a que condições-limite de recursos o software é capaz de ser executado 
 Determinar quais volumes de transação, normais e acima dos normais, podem ser processados num período de tempo esperado 
 Verificar se o sistema é capaz de garantir tempos adequados de resposta sendo executado em condições-limite 
 Verificar se há restrições quanto ao ambiente em que o software vai operar 
 
AULA 8 
 
Teste de migração 
 Independentemente do domínio da aplicação, tamanho ou complexidade, o software continuará a evoluir com o tempo. Após seu 
desenvolvimento um sistema pode ficar operacional, ou seja, em produção por anos ou até mesmo décadas. Porém durante este período o 
próprio sistema ou seu ambiente operacional podem ser corrigidos, modificados ou completados. Desta forma os caso de teste de migração 
de uma plataforma a outra, podem incluir testes operacionais do novo ambiente tanto quanto a mudança de software. Já os testes de 
migração para retirada de um sistema pode incluir testes de migração de Dados. 
Processo de migração pode ser fracassado se não for bem planejado e orquestrado. 
 
Migração de Dados 
Migração de Dados é o processo de transferência de Dados entre diferentes tipos ou formato de armazenamento, ou ainda de 
diferentes sistemas computacionais. É normalmente realizada através de um processo de migração automatizado, consequência de uma 
troca de sistemas computacionais ou upgrade para novos sistemas. 
 A maioria dos projetos de migração são demorados, requerem o envolvimento de muitos recursos e tem um custo muito elevado. 
Além de necessitar derecursos eficientes e de um ótimo planejamento é muito importante o uso inteligente de ferramentas de apoio ao 
projeto e acima de tudo a adoção de um conjunto de testes completo e complexos para garantir o que o projeto seja bem sucedido. 
 
Categoria Tipos de Teste Requisitos 
Funcionalidade Teste Funcional 
Teste de Volume 
Teste de Segurança 
Teste de Acessibilidade 
Conjunto de Características; 
Capacidade; 
Segurança; 
Usabilidade Teste de Usabilidade Fator humano estético; 
Consistência da Interface do usuário; 
Help online e assistente. 
Confiabilidade Teste de Estresse 
Teste de Regressão 
Teste de Integridade 
Teste de Estrutura 
Frequência e severidade de falhas; 
Confiança nos resultados; 
Recuperação de falhas; 
Tempo entre falhas (MTBF); 
Desempenho Teste de Desempenho 
Teste de Carga 
Vazão; 
Eficiência; 
Teste de Contenção 
Teste de Perfil de Desempenho 
Tempo de resposta; 
Consumo de Recursos; 
Suportabilidade Teste de Instalação 
Teste de Configuração 
Facilidade de instalação; 
Requisitos de configuração; 
Requisitos de adaptabilidade; 
Requisitos de compatibilidade; 
 
Os Dados são armazenados em diferentes mídias, normalmente através de arquivos ou bases de Dados. Estes Dados são gerados ou 
consumidos por aplicações de software que, por sua vez apoiam os processos de negócios das organizações. A necessidade de transferir e/ou 
converter os Dados normalmente é impulsionado por um requisito de negócio ou uma evolução tecnológica. Existem basicamente quatro 
tipos possíveis de migração: 
 Migração de mídias de armazenamento - Normalmente é motivada pela racionalização dos meios físicos e pela possibilidade de 
maior vantagem e eficiência da utilização de modernas tecnologias de armazenamento. O que irá resultar no deslocamento blocos 
físicos de Dados de uma fita ou disco para outra, muitas vezes usando técnicas de virtualização. O formato de Dados e conteúdo 
geralmente não são alterados neste processo e pode, normalmente, ser alcançado com um mínimo ou nenhum impacto para a 
camadas acima. 
 Migração de base da dados - Em alguns casos pode ser necessário adotar uma nova versão, ou atualização do software de banco de 
Dados utilizado e até mesmo a mudança de fornecedor de software. Normalmente na atualização do software praticamente não 
existe migração de Dados, porém podendo ocorrer em grandes atualizações (quando o software está em uma versão muito antiga e 
troca-se para uma atual). No caso de adoção de uma nova plataforma de banco de Dados pode ser necessária a migração física dos 
Dados uma vez que o formato da base de Dados podem mudar significativamente. Esta migração pode ou não afetar o 
comportamento da camada de aplicação, dependendo em grande parte se ocorrerá mudança na linguagem ou protocolo de 
manipulação de Dados. Vale ressaltar que as aplicações modernas normalmente são desenvolvidas de formas a serem 
agnósticas(Não saber, ignorar (fonte: Dicionário Houaiss da Língua Portuguesa).) à tecnologia de banco de Dados (Sybase, Mysql, 
DB2, SQL Server ou Oracle ) para que a mudança de bases de Dados, só exijam um ciclo de teste para validar o aspecto de 
desempenho dos requisitos funcionais e não- funcionais. 
 Migração de aplicação - Ocorre quando a organização decide implementar uma nova aplicação ou mesmo alterar de fornecedor 
uma aplicação já existente, como por exemplo, uma nova plataforma CRM ou ERP, implica necessariamente em uma transformação 
substancial de toda aplicação ou conjunto de operações no modelo de Dados do software do novo fornecedor. Com o objetivo de 
permitir a utilização de seus produtos por um número maior de empresas, normalmente estes pacotes de produtos são configurados 
para cada cliente utilizando metadados. 
 Migração de processo de negocio - Processos de Negócios operam através de uma combinação de ações humanas e de sistemas de 
aplicação, sendo normalmente orquestrada por ferramentas de gestão de processos de negócios. Neste caso as alterações podem 
exigir a transferência de Dados de um meio de armazenamento, base de Dados ou aplicação a fim de refletir as alterações da 
organização e informações sobre os clientes, produtos e as operações. São exemplos deste tipo de migração: 
o Fusões e aquisições de empresas. 
o Otimização dos processos de negócio. 
o A reorganização dos processos como forma de atacar novos mercados ou responder a alguma ameaça competitiva. 
 
Fases da migração de Dados 
Migração de Dados é geralmente o termo utilizado para descrever um projeto em que os Dados serão transferidos ou copiados de 
um ambiente para outro, e removidos ou desativados na origem. Durante a migração (que podem realizar-se ao longo de meses ou mesmo 
anos), os Dados podem ser migrados em múltipla direções e lugares simultaneamente. O projeto de migração é normalmente dividido nas 
seguintes etapas ou fases: 
 Projeto/Design - Nesta etapa são levantadas as funcionalidades de software e hardware, se for o caso, e identificados os 
Dados que serão migrados. Neste momento podemos ter duas situações de mapeamento dos Dados: 
o Onde o layout da origem e o destino layout são os mesmos. 
o Onde os layouts da origem e o destino são diferentes. 
Embora o mapeamento de mesmo layout na origem e destino apresente uma migração mais simples, é muito comum as 
equipes responsáveis enxergarem este momento como uma ótima oportunidade para consolidar e/ou otimizar o 
desempenho e/ou a capacidade de utilização dos Dados. Quando o mapeamento é realizado com layouts diferentes está 
cenário já é o comum. 
 Extração - Esta fase envolve a extração dos Dados dos diferentes sistemas de origem. Cada sistema separadamente pode 
utilizar um formato e organização diferente de Dados. O objetivo desta fase é converter os Dados em um formato único 
adequado para o processo de transformação. Uma parte intrínseca na envolve a análise de Dados extraídos, resultando na 
verificação se os Dados satisfazem um padrão esperado ou estrutura. Caso não satisfaçam devem ser rejeitado totalmente 
ou em parte. 
 Limpeza - Um processo de limpeza de Dados manual ou automatizada é comumente realizada na migração para melhorar a 
qualidade dos Dados, eliminar informações redundantes ou obsoletas, e a adaptação as exigências do novo sistema. 
 Carga - A fase de carga carrega os Dados para um destino específico. Em função dos requisitos da organização, este 
processo varia muito. Em alguns casos os Dados podem sobrepor os Dados existentes com informações acumulativas, 
frequentemente a atualização de extração de Dados é realizada diariamente, semanal ou mensal. Em outros caso poderá 
ser necessário acrescentar novos Dados. O escopo e a periodicidade para substituí-la ou inclusão dependem do tempo 
disponível e da necessidade do negócio. Outra opção é a utilização de uma fase de pré-carga, através do estabelecimento 
de um conjunto mínimo de Dados com os requisitos necessários para a carga no sistema novo. Este processo de validação 
é aplicado quando deseja-se garantir que o destino realmente possui os critérios de ambiente e as especificações de 
arquivo pré-definidos e antes do processo de carga total. Uma estratégia alternativa pode ser também a utilização de uma 
validação denominada de on-the-fly, utilizada com o objetivo de reportar os erros de rejeição enquanto a carga avança. 
 Verificação - Após o carregamento para o novo sistema, os resultados são submetidos a uma etapa de verificação dos 
Dados para determinar se os Dados foram corretamente migrados, se ocorreu de forma está completa. Durante a 
verificação pode ser necessário um execução de processo de execução em paralelo de ambos os sistemas para identificar 
áreas de disparidade e evitar erros perda de Dados. 
Para aplicações de moderada ou alta complexidade as fase de migração de Dados são normalmente repetidas várias vezes antes do novo 
sistema ser implantado. 
 
Verificação dos procedimentos operacionais e legais para a migração 
 Umaimportante etapa no processo de migração é a preparação prévia dos procedimentos operacionais a serem adotados. Esta 
etapa deve considerar a simulação e a verificação dos procedimentos operacionais, financeiros e legais usados no sistema antigo e seu 
rebatimento no novo sistema. Um outro aspecto importante a considerarmos nesta etapa é a concordância do usuário gestor, face a questão 
básica da manutenção do negócio, ou seja, mudar para melhor dentro dos requisitos de negócio estabelecido. 
 
Validação do novo formato dos Dados 
Para alcançar um efetivo processo de migração de Dados, os Dados sobre o sistema antigo devem ser mapeados para o novo sistema 
através do levantamento dos requerimentos e formatos dos Dados antigos para o novo sistema, sendo realizado através de dois momentos: 
 Extração de Dados, onde os Dados são lidos a partir do sistema antigo. 
 Carga dos Dados, onde os Dados são escritos no novo sistema. 
Nesta fase procedimentos de controle devem ser definidos para garantir que todos os Dados de entrada sejam completa e 
precisamente convertidos. Esses procedimentos podem consistir em uma verificação manual de todos ou de uma amostra dos Dados antes e 
depois da conversão ou ainda através da verificação manual dos relatórios criados a partir dos Dados. 
 
Exatidão dos Dados 
Após a migração dos Dados, os Dados resultantes podem nem sempre precisar ser completamente exatos, uma vez que a exatidão 
completa pode ser pouco econômica ou impossível. Desta forma é necessário definir o nível de exatidão aceitável no contexto organizacional. 
 
Teste de migração dos Dados 
É importante observarmos a importância de se elaborar o novo formato do banco de dados para o novo sistema com base no 
formato do banco de dados do antigo sistema de forma a facilitar a migração dos dados. Para os novos campos de dados no sistema novo que 
não existem no banco de dados antigo, deverá ser elaborada uma estratégia de povoamento desses campos. 
É recomendável a utilização de equipes de teste com perfis distintos para elaboração, execução e validação das etapas de migração: 
 Equipe de teste de aceitação 
 Equipe de teste operacional 
 Equipe de teste de legado 
 
Simulação do novo sistema em substituição ao sistema antigo 
Nesta etapa do processo deverá realizada um simulado do novo sistema em condições reais de funcionamento em paralelo ao antigo 
sistema de forma que o usuário gestor possa avaliar possíveis necessidades de ajustes do fluxo operacional e computacional de forma a trazer 
benefícios com a instalação do novo sistema. Deve ser dada uma atenção especial aos dados migrados automaticamente para garantir que não 
haja erros no software de migração. Os dados migrados devem ser verificados para garantir que um nível de exatidão apropriado tenha sido 
alcançado. 
Quando os resultados ultrapassarem o limite de exatidão aceitável, devem ser identificadas as causas e aplicado procedimentos 
corretivos, como por exemplo: 
1. As correções requeridas nos dados de origem e a execução novamente da conversão. 
2. Identificação das correções para o software de conversão de dados automatizado (normalmente através da criação de um 
Controle de Mudança), e a execução novamente da conversão, tendo em vista a correção do software. 
3. A observação dos erros de dados para a correção manual no novo sistema. 
 
AULA 9 
 
 
Introdução 
A partir deste texto introdutório, você será capaz de entender melhor os conceitos estudados nesta aula, sendo capaz de relacionar o 
conteúdo que será aprendido ao contexto em que está inserido. Nesta aula iremos estudar os testes de manutenção (corretiva, perfectiva, 
adaptativa e preventiva) que um sistema em produção poderá sofrer. É importante ressaltar que estes tipos de testes de software aplicados na 
manutenção de sistemas em produção, demandam cuidados adicionais, notadamente quanto à corretitude e ao tempo reduzido para realizar 
os testes, depurar os erros e validar os resultados - uma vez que os sistemas são ativos da empresa e suas interrupções possam causar danos e 
prejuízos à ela. Iremos aprender também sobre a importância da medida de confiabilidade e da disponibilidade de um software. Veremos o 
conceito de confiabilidade, fazendo uma comparação ao conceito de disponibilidade. Estudaremos a medida de confiabilidade de software. 
Confiabilidade - Se baseia na execução do sistema em determinada unidade de tempo sem falhas. 
Disponibilidade - Se baseia na oferta do software em determinada unidade de tempo, considerando-se, proporcionalmente, o tempo 
útil de uso e o tempo de reparo de falhas. 
 
Tipos de manutenção 
Independentemente do domínio da aplicação, tamanho ou complexidade, o software continuará a evoluir com o tempo. Após seu 
desenvolvimento um sistema pode ficar operacional, ou seja, em produção por anos ou até mesmo décadas. Porém durante este período o 
próprio sistema ou seu ambiente operacional podem ser corrigidos, modificados ou completados. Diferentes causas geram manutenções de 
tipos diferentes em um software em produção, e podem ser classificadas em: 
 Manutenção Corretiva - Irá identificar e corrigir defeitos (erros latentes). 
 Manutenção Adaptativa - Irá adaptar o software a novas tecnologias, metodologias, modelos de gestão, legislação. 
 Manutenção Perfectiva - Irá incluir novas funções no software em produção, como: atender pedidos do usuário para 
modificar funções existentes e efetuar melhoramentos gerais. 
 Manutenção Preventiva - Irá melhorar a manutenibilidade ou a confiabilidade futura. 
 
Teste em manutenção de software 
O teste de manutenção (Sylabbus,2007) é iniciado por: 
 Modificações no software 
 Migrações 
 Retiradas de software ou sistemas 
Como já estudamos, essas modificações podem ser inclusões de melhorias planejadas, ou seja, uma nova versão do software, podem 
ser mudanças corretivas e emergenciais ou, ainda, mudanças de ambiente, como atualização em sistema operacional ou banco de dados e 
correções (“patches”) para expor e encontrar vulnerabilidades do sistema operacional.Além de testar o que foi alterado, o teste de 
manutenção inclui também um teste de regressão massivo para as partes do sistema que não foram testadas. 
O escopo do teste de manutenção está relacionado ao risco da mudança, o tamanho do sistema existente e o tamanho da mudança. 
Dependendo da mudança, o teste de manutenção pode ser feito em todos ou apenas em alguns módulos do sistema e podem ser aplicados 
em todos ou alguns tipos de testes. 
A determinação de como um sistema pode ser afetado por mudanças é chamada de análise de impacto e pode ser usada para ajudar 
a decidir quantos testes de regressão serão realizados. 
Os testes de manutenção podem se tornar uma tarefa complicada, se as especificações do software estiverem desatualizadas ou 
incompletas. 
Dependendo do tipo de manutenção podemos ter os seguintes tipos de teste: 
 Teste em manutenção corretiva - Os testes de manutenção corretiva de um software em produção são os mais exigidos, 
uma vez que se trabalha sobre um produto com vícios de construção, o que pode demandar esforço significativo para 
identificação e correção adequada do erro. Nesse caso, é indispensável a aplicação dos testes de validação de forma a 
evitar possível propagação ou derivação de erro pela correção realizada e levando em consideração que tudo isso deverá 
ocorrer em diminuto espaço de tempo. 
 Teste em manutenção perfectiva – Se assemelham ao teste na construção do software, pois, testam-se novas funções, 
incluídas pelo usuário, que serão iniciadas nos sistemas, podendo ser planejadas. 
 Teste em manutenção adaptativa – Por validar impositivas, quer legais, quer tecnologias, mesmo com tempo limitado, são 
previsíveis, podendo assim, como a perfectiva e a preventiva, ser planejado, o que facilita a atividade de teste de software, 
 Teste em manutenção preventiva - São os mais previsíveis, pois, buscam identificar, antecipadamente, possíveis erros