Todas as Aulas

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Teste de Software 
Aula 1: Importância do teste de software 
 
Antes de definirmos o que é teste de software vamos definir o conceito de 
teste: 
 
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 deverá ser definido um processo de teste de software e um 
modelo (template) para o teste. 
Uma estratégia de teste de software deve acomodar testes 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 têm basicamente as seguintes características 
genéricas: 
 Para executar um teste eficaz, proceder a 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 à 
integração do sistema computacional 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 de 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 petos desenvolvedores e usuários; 
Prevenção – década de 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, usuários e testadores. 
 
ATENÇÃO 
Segundo Hallpern e Santhanam, os planejadores de projetos de 
desenvolvimento de sistemas devem considerar de 50 % a 75% do custo de 
desenvolvimento para as atividades de garantir que os programas 
funcionarão satisfatoriamente nos termos de suas especificações funcionais e 
não funcionais e dentro do ambiente estabelecido na entrega, através do 
processo apropriado de depuração, testes e atividades de verificação. 
 
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 
 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ário, 
representantes do desenvolvimento, testes e produção) para a 
definição dos seguintes assuntos: 
 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 qualquer item considerado 
irrelevante. 
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. 
 
Revisão das Etapas de Desenvolvimento de um Software 
Segundo Pressman, um modelo genérico de desenvolvimento de software 
estabelece cinco atividades metodológicas: 
 
Comunicação 
 Início do projeto; 
 Levantamento das necessidades; 
Planejamento 
 Estimativas; 
 Cronograma; 
 Acompanhamento; 
Modelagem 
 Análise; 
 Projeto; 
Construção 
 Entrega; 
 Suporte; 
 Feedback; 
Entrega 
 Entrega; 
 Suporte; 
 Feedback; 
 
Estas atividades podem estar caracterizadas por diferentes fluxos de 
processo
1
. 
 
1
 Como são organizadas as atividades metodológicas, bem como as ações e 
tarefas que ocorrem dentro de cada atividade em relação à sequência e ao 
tempo. (Pressman) 
 
 
Como já falamos anteriormente, o processo de teste de software deve se 
basear em uma metodologia aderente ao processo de desenvolvimento. A 
imagem abaixo mostra como o ciclo de vida do projeto de teste deve interagir 
com o ciclo de vida do projeto de desenvolvimento. 
 
 
 
Verificação 
 Nesta etapa são realizadas inspeções/revisões dos produtos gerados. 
Teste Unitário 
 São realizados no estágio mais baixo da escala de testes e aplicados nos 
menores componentes de códigos criados, visando garantir que estes 
atendam às 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 testados separadamente. 
Normalmente é feito pelos desenvolvedores. 
Teste de Integração 
 São executados em uma combinação de componentes para verificar se 
eles funcionam corretamente juntos, conforme as especificações. 
Componentes podem ser pedaços de código, módulos, aplicações 
distintas e 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 a 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 da 
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 ambiente de produção. 
 
Há muitas estratégias que podem ser utilizadas para testar um software. Uma 
das estratégias de teste, a preferida pela maioria das equipes, é a visão 
incremental do teste, começando com o teste das unidades individuais de 
programa, passando para os testes
destinados a facilitar a integração de 
unidades e culminando com testes que usam o sistema concluído. 
 
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 do que defeitos encontrados em 
modelos de dados e em outros documentos do projeto do software. 
Myers afirma ainda que: 
 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 a produção ainda com 
aproximadamente 49% de defeitos; 
 Por últimos, as revisões de códigos podem reduzir entre 20% e 30% desses 
defeitos. 
 
Tipos de testes de software 
 Apresentamos abaixo uma relação de testes, com suas respectivas 
definições. Nas próximas aulas iremos estudar alguns testes descritos aqui em 
detalhes. Vocês irão perceber que alguns tipos de testes se sobrepõem, sendo 
as próprias definições abrangentes ou específicas, conforme a sua execução: 
 
Teste Funcional 
 Verifica a aceitação das funcionalidades (dados, processamento e 
respostas) e a implementação apropriada das regras de negócio. 
 Este tipo de teste é baseado nas técnicas de caixa-preta. 
Teste de Volume 
 Submete grandes quantidades de dados ao sistema para determinar 
quais limites que causam a falha do software são alcançados. 
 Este tipo de teste também identifica a carga ou volume máximo 
persistente que o sistema pode suportar por um dado período. 
Teste de Segurança 
 Verifica as restrições de acesso em nível de aplicação e sistema. 
Teste de Acessibilidade 
 Verifica se a interface do usuário fornece o acesso apropriado às 
funções do sistema e a navegação adequada. 
 Este teste garante que os objetos dentro da interface do usuário 
funcionem de acordo com os padrões definidos pelos requisitos. 
Teste de Usabilidade 
 Verifica a facilidade que o software possui de ser claramente entendido 
e facilmente operado pelos usuários. 
Teste de Estresse 
 Verifica o comportamento do sistema durante condições limite ou fora 
da tolerância esperada. 
 Tipicamente envolve a escassez de recursos ou a concorrência por 
recursos. 
Teste de Regressão 
 Verifica se alterações efetuadas em um software geraram alguma 
inconsistência no aplicativo ou em outros sistemas que se relacionam 
com ele. 
Teste de Integridade 
 Avalia a robustez dos componentes do software (resistência a falhas) e 
a compatibilidade técnica em relação à linguagem, à sintaxe e à 
utilização de recursos. 
 Esse teste é implementado e executado em vários componentes do 
software, individualmente e de forma integrada. 
Teste de Estrutura 
 Avalia a adequação dos componentes do software em relação ao seu 
design e à sua formação. 
 Em geral, esse teste é realizado em aplicativos habilitados para a Web, 
garantindo que todos os links estejam conectados, que o conteúdo 
apropriado seja exibido e que não haja conteúdo órfão. 
Teste de Desempenho 
 Mede e avalia o tempo de resposta, o número de transações e outros 
requisitos sensíveis ao tempo, com carga normal e carga limite de 
trabalho. 
Teste de Carga 
 Mede e avalia as variações de desempenho e a sua habilidade de 
continuar funcionando apropriadamente sob cargas de trabalho 
diferentes. 
Teste de Contenção 
 Verifica a habilidade de um componente de software em suportar 
demanda múltipla por um recurso (registros de dados, memória etc.). 
Teste de Perfil de Desempenho 
 Verifica o perfil de desempenho dos componentes de software, a fim de 
identificar gargalos de desempenho e processos ineficientes. 
 São monitorados o fluxo de execução, o acesso a dados e as chamadas 
de função. 
Teste de Configuração 
 Verifica a operação do sistema em diferentes configurações de 
software e hardware. 
 As especificações de hardware e software podem mudar e esta 
mudança pode afetar o sistema. 
 
Teste de Instalação 
 Possui dois propósitos: 
 Garantir que o software possa ser instalado (completamente, de 
forma personalizada ou atualizado) sob condições apropriadas; 
 Verificar que, uma vez instalado, o software funciona 
corretamente. 
 
Plano de Teste 
Dependendo do tamanho do projeto de desenvolvimento, poderemos ter 
diversos planos de teste para um mesmo projeto de teste de software. Esses 
planos podem ser separados por módulos, funcionalidades ou por requisitos, 
ou por um grupo de cada um destes elementos. Podem ser também 
classificados por nível de teste: unitário, integração, sistema e aceitação. 
 
Segundo a IEEE829, o Plano de teste deve ter os seguintes campos: 
1. Introdução 
1.1. Identificador do plano de teste 
1.2. Escopo 
1.3. Referências 
1.4. Nível na sequência de teste 
1.5. Classe de teste e visão das condições de teste 
2. Detalhes para este nível do plano de teste 
2.1. Itens de teste e seus identificadores 
2.2. Matriz de rastreabilidade do teste 
2.3. Funcionalidades a serem testadas 
2.4. Funcionalidades que não serão testadas 
2.5. Abordagem do teste 
2.6. Critérios de liberação/falha dos itens 
2.7. Requisitos de suspensão e retomada 
2.8. Entregas do teste 
3. Gerência de teste 
3.1. Tarefas do teste 
3.2. Necessidades de ambientes 
3.3. Responsabilidades 
3.4. Integração entre as partes envolvidas 
3.5. Recursos e sua alocação 
3.6. Treinamento 
3.7. Cronograma, estimativas e custos 
3.8. Riscos e contingências 
4. Geral 
4.1. Procedimentos de garantia de qualidade 
4.2. Métricas 
4.3. Cobertura do teste 
4.4. Glossário 
4.5. Procedimentos de alteração do documento e histórico 
 
Para detalhamento do Plano de teste proposto pelo IEEE acesse: Plano de 
teste detalhado. 
 
Bugs, Erros e Defeitos. 
Segundo Pressman, o objetivo geral do controle de qualidade de software e 
da gestão da qualidade é eliminar problemas de qualidade no software. Tais 
problemas são conhecidos por diversos nomes: bugs, falhas, erros ou 
defeitos. 
Neste contexto, um erro é definido como um problema de qualidade 
encontrado antes do software ser liberado aos usuários finais. O defeito é um 
problema de qualidade encontrado depois de o software ter sido liberado aos 
usuários finais. Porém, na maioria das vezes os termos são utilizados como 
sinônimos devido à dificuldade de classificação dos termos. 
 
A Associação Latino Americana de Testes de Software (ALATS) é uma 
associação sem fins lucrativos, que busca divulgar as boas práticas em Teste 
de Software. Temos como propósito suportar a comunidade de testes, 
valorizando o desenvolvimento técnico e científico de novos métodos e 
processos, visando aumento na produtividade e a melhoria da qualidade dos 
produtos desenvolvidos. Buscamos uma maior integração entre as 
universidades, empresas e profissionais de TI, facilitando o desenvolvimento e 
aplicação de técnicas para atender a atual demanda e necessidades do 
mercado de Testes de Software. Com as constantes mudanças que vivemos no 
mundo atual, devemos ser ágeis, com baixo custo e efetivos em nossos 
resultados. 
 
Visão do ISTQB 
Continuamente melhorar e avançar a profissão de testes de software 
definindo e mantendo um corpo de conhecimento que permite que os 
testadores a serem certificados possuam uma base nas melhores práticas, que 
une a comunidade de teste de software internacionalmente, e incentivar a 
pesquisa. 
Qual é o objetivo do teste de estresse? 
Verificar o comportamento do sistema durante condições limite ou 
fora da tolerância esperada. 
Qual é o objetivo do teste de integração?
Verificar se todos os componentes do sistema funcionam 
corretamente juntos. 
Qual é o objetivo do teste de regressão? 
Verificar se alterações efetuadas em um software geraram alguma 
inconsistência no aplicativo ou em outros sistemas que se 
relacionem com ele. 
 
Aula 2: Teste no projeto de sistema e Teste no 
programa – Depuração 
 
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 para encontrar 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 software; 
 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. 
 
Regras das Revisões Técnicas Formais 
Uma revisão formal normalmente tem as seguintes 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. 
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). 
 
Diretrizes das Revisões Técnicas Formais 
Devem ser estabelecidas previamente diretrizes para a realização das revisões 
técnicas formais e distribuídas a todos os revisores. Uma revisão não 
controlada pode ser pior do que não fazer nenhuma revisão. 
 Revisar o produto, não o produtor; 
 Estabelecer uma agenda e mantê-la; 
 Limitar debates e refutação; 
 Enunciar as áreas do problema, mas não tentar resolver todo o problema 
registrado; 
 Tomar notas; 
 Limitar o número de participantes e insistir na preparação antecipada; 
 Desenvolver uma lista de verificação para cada artefato que 
provavelmente será revisado; 
 Alocar os recursos e programar o tempo para as RTFs; 
 Realizar treinamento significativo para todos os revisores; 
 Revisar revisões iniciais. 
 
Diferentes tipos de revisão podem ser utilizados em um único tipo de 
documento. Seja uma revisão de acompanhamento (walkthrough), uma 
revisão técnica ou uma inspeção, cada RTF é realizada como uma reunião e 
apenas será bem-sucedida se for apropriadamente planejada, controlada e 
tiver a participação de todos os envolvidos. 
Cada reunião de revisão deve ser preparada antecipadamente, porém não 
deve tomar mais que duas horas de trabalho de cada pessoa. Devem estar 
envolvidas de 3 a 5 pessoas em uma revisão e cada reunião de revisão deve 
ser pelo menos de duas horas. 
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 relatório sintetizado de revisão deve responder a três questões: 
 
 
 
Teste No Programa: Processo De Depuração 
Como já vimos anteriormente, teste de software é um processo que pode ser 
sistematicamente planejado e especificado. Podem ser projetados casos de 
tese, uma estratégia pode ser definida e os resultados podem ser avaliados de 
acordo com as expectativas prescritas. 
Neste contexto, 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 do erro. 
 
 
A depuração começa com a execução de um caso de teste. 
Os resultados são avaliados e uma falta de correspondência entre o 
desempenho esperado e o desempenho real é encontrada. Em muitos casos, 
os dados não correspondentes são um sintoma de uma causa subjacente, 
embora oculta. 
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. 
 
Abordagens de Depuração 
Independente da abordagem adotada, a depuração tem um objetivo 
primordial, que é encontrar e corrigir a causa de erro ou defeito, Segundo 
Delamaro, Maldonado e Gino, vários experimentos foram desenvolvidos com 
o objetivo de entender o processo de depuração de software e estabelecer 
um modelo de depuração. 
Um destes modelos é 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. 
Neste modelo o responsável pela depuração do software estabelece 
hipóteses com relação à localização do defeito e à modificação para corrigir o 
programa. 
O processo de depuração é guiado pela cerificação e pela refutação das 
hipóteses levantadas, bem como pela geração de novas hipóteses e 
refinamentos das já existentes. 
 
 
Já segundo Pressman, o objetivo da depuração é alcançado por uma 
combinação de avaliação sistemática, intuição e sorte, sendo definidas 
basicamente três estratégias de depuração: 
Força bruta 
 É o método mais comum e menos eficiente para isolar a causa de um 
erro de software. 
 Usamos este método quando todas as outras técnicas falharam. A ideia 
é utilizarmos diferentes ações como, por exemplo, rastreamentos em 
tempo de execução, para que, com as informações obtidas, consigamos 
encontrar um indicio que possa levar à causa do erro. 
Rastreamento (backtracking) 
 Começa no ponto onde o sintoma foi descoberto, o código fonte é 
investigado retroativamente (manualmente) até que a causa seja 
encontrada. O problema desta abordagem está no fato de que, à 
medida que o número de linhas do código fonte aumenta, o número de 
caminhos retroativos potenciais pode se tornar demasiadamente 
grande. 
Eliminação da causa 
 Esta estratégia é realizada através da indução ou dedução e introduz o 
conceito de particionamento binário. Os dados relacionados com a 
ocorrência do erro são organizados para isolar as causa em potenciais. 
E imaginada uma “hipótese de causa” e os dados são usados para 
provar ou negar a hipótese. Alternativamente é preparada uma lista de 
todas as causas possíveis e são conduzidos os testes para eliminar cada 
uma delas. 
 
As três estratégias de depuração utilizadas podem ser conduzidas 
manualmente, mas existem ferramentas de depuração automatizadas que 
podem tornar o processo muito mais eficaz? 
Essas ferramentas proporcionam auxilio automático para aqueles que devem 
depurar problemas de software. O objetivo é fornecer informações que podem 
ser difíceis de obter se o processo de depuração for abordado manualmente. 
Muitas ferramentas são específicas quanto à Linguagem de programação e 
quanto ao ambiente: 
 Borland Gauntlet, www.borland.com ; 
 GNATS, www.gnu.org/software/gnats ; 
 C++Test, www.parasoft.com ; 
 Coverty Prevent SQS,www.coverty.com (java e C++). 
 
Considerações Psicológicas 
É possível observar uma grande variação na habilidade de depuração entre 
programadores com o mesmo nível de formação e experiência. Parece haver 
certa evidência de que a destreza na depuração é uma peculiaridade humana 
inata. O que nos leva a crer que algumas pessoas são boas em depuração e 
outras não, já que muitas vezes o processo é intuitivo e já que trabalha com 
hipóteses. Além do aspecto humano, algumas características dos erros 
também ajudam a dar complexidade ao processo: 
 O sintoma e a causa do defeito podem ser geograficamente remotos. Isto 
é, o sintoma pode aparecer em uma parte do programa, enquanto a 
causa pode realmente estar localizada em um ponto muito afastado; 
 O sintoma pode desaparecer (temporariamente) quando outro erro for 
corrigido; 
 O sintoma pode ser na realidade, causado por não erros (por exemplo, 
imprecisões de arredondamento); 
 O sintoma pode ser causado por erro humano, que não é facilmente 
rastreável; 
 O sintoma pode ser um resultado de problemas de temporização e não de 
problemas de processamento; 
 Pode ser difícil reproduzir com precisão as condições de entrada (por 
exemplo, uma aplicação em tempo real na qual a ordem das entradas é 
indeterminada); 
 O sintoma pode ser intermitente. Isso é particularmente comum em 
sistemas embutidos que acoplam hardware e software 
inextricavelmente
2
; 
 O sintoma pode ocorrer devido às causas distribuídas por várias tarefas, 
executando em diferentes processadores. 
 
2
 Que não se pode desenredar ou desemaranhar ou de que não é possível 
desembaraçar. Fonte: http://www.dicio.com.br 
 
Correção do Erro 
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: 
 
A causa do defeito é reproduzida em alguma outra parte do programa? 
 Em muitas situações o defeito de um programa é causado por um 
padrão incorreto de lógica que pode ser reproduzido em qualquer outro 
ponto. 
Qual é o próximo defeito que pode ser introduzido pelo reparo que estou 
prestes a fazer? 
 Em muitas situações o defeito de um programa é causado por um 
padrão incorreto de lógica antes de fazer a correção, o código-fonte 
deverá ser avaliado para verificar acoplamento de lógica e estruturas 
de dados. Se a correção tem que ser feita em uma parte do programa 
altamente acoplada, deve ser tomado cuidado especial ao fazer 
qualquer alteração. 
A causa do defeito é reproduzida em alguma outra parte do programa? 
 Se você corrige o processo juntamente com o produto, o erro será 
removido do programa em questão e pode ser eliminado em todos os 
programas futuros. 
Qual o objetivo do processo de depuração de software? 
Localização e remoção de defeitos. 
Segundo Pressman, quais são as três estratégicas normalmente utilizadas 
na depuração? 
Força Bruta, rastreamento e eliminação da causa. 
Quais as fases do ciclo de vida do software a depuração pode ocorrer? 
Durante a codificação, depois do teste e durante a manutenção. 
 
Aula 3: Teste no programa: Teste de caixa branca e 
teste da caixa-preta 
 
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 os 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 percorridos durante os testes. Desta forma é 
possível criar casos de teste que: 
 Garantam que todos os caminhos independentes de um módulo foram 
exercitados pelo menos uma vez; 
 Exercitam todas as decisões lógicas nos seus estados verdadeiros e falsos; 
 Executam todos os ciclos em seus limites e dentro de suas fronteiras 
operacionais; 
 Exercitam estruturas de dados internas para assegurar sua validade. 
 
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: 
 Usando o projeto ou o código como base, desenhar o grafo de 
fluxo correspondente; 
 Determinar a complexidade ciclomática do diagrama de fluxo 
resultante; 
 Determinar um conjunto base de caminhos linearmente 
independentes; 
 Preparar casos de teste que vão forçar a execução de cada 
caminho do conjunto base. 
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: 
 
 
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: 
 Pular o ciclo completamente; 
 Uma passagem pelo ciclo; 
 Duas passagens pelo ciclo; 
 m passagens pelo ciclo em que m < n; 
 n -1, n , n +1 passagens pelo ciclo. 
Ciclos 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. Para evitar que o número de testes cresça 
geometricamente, deve-se seguir a seguinte abordagem: (PRESSMAN, 
2006; BEIZER, 1990). 
 Começar testando o ciclo mais interno, ajustando os outros ciclos 
para valores mínimos; 
 Trabalhar em direção ao exterior, conduzindo testes para o ciclo 
seguinte, mas mantendo todos os ciclos externos nos valores 
mínimos e os internos nos valores “típicos”; 
 Continuar até que todos os ciclos sejam testados. 
Ciclos Concatenados 
 Ciclos concatenados podem ser testados 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. (Pressman, 2011). 
Ciclos Desestruturados 
 Segundo Pressman, sempre que possível essa classe de ciclos deverá ser 
redesenhada 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 
testes 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 são testados? 
 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 são isoladas? 
 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. 
 
 
 
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: 
 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. 
 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álidas. 
 Se uma condição de entrada especifica de 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 classe inválida. 
 
EXEMPLO: 
Um programa valida um campo numérico onde valores inferiores ou iguais a 
zero são rejeitados, valores entre 1 a 130 são aceitos, e valores maiores ou 
iguais a 131 são rejeitados. 
 
Neste caso: 
Partição inválida: 
 Os valores abaixo do valor mínimo, ou seja, valores menores ou iguais a 
zero. 
Partição válida: 
 Valores entre 1 a 130; 
Partição inválida: 
 Valores acima do valor máximo, ou seja, valores maiores ou igual a 
131; 
 
Análise De Valor-limite 
A análise do valor limite (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: 
 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. 
 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áximos. 
 Aplicar as diretrizes 1 e 2 às condições de saída. 
 Se as estruturas de dados internas do programa prescreverem fronteiras, 
não esquecer de criar caso de teste para exercitar a estrutura de dados na 
fronteira. Por exemplo, uma tabela que tem um limite definido de 100 
entradas. 
 
EXEMPLO: 
Um campo de entrada (imput field) referente a data do nascimento e que 
aceita como valores de 1900 até 2011, terá como valores limites: 
 Valor limite mínimo inválido: 1899; 
 Valor limite mínimo válido: 1900; 
 Valor limite máximo válido:2011; 
 Valor limite máximo inválido: 2012. 
 
Teste De Matriz Ortogonal 
O teste de matriz ortogonal pode ser aplicado a problemas nos quais o 
domínio de entrada é relativamente pequeno, mas muito grande para 
acomodar um teste exaustivo. O objetivo do teste é a construção de caso 
de teste com uma visualização geométrica associada aos valores de entrada 
de uma aplicação. 
 
Para ilustrar (Pressman, 2011) vamos considerar a função envie para uma 
aplicação de fax. Neste exemplo, são passados quatro parâmetros: P1, P2, P3 
e P4. Cada parâmetro assume três valores discretos. 
P1 assume, por exemplo, os 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 assumiriam valores, 1, 2 e 3, significando outras funções 
de envio. 
 
Uma matriz ortogonal para a função envie da aplicação de fax está ilustrada 
ao lado. 
 
 
 
Qual é o conceito de teste de caixa-branca? 
Tem uma visão interna do software, isto é, conhecendo o 
funcionamento interno do produto. 
São métodos de teste de caixa-preta: 
Baseado em Grafo, particionamento de equivalência, análise do 
valor limite e análise ortogonal. 
O teste de condição é um teste que: 
Exercita as condições lógicas contidas em um módulo do programa 
e é considerado um teste de caixa-branca. 
 
Aula 4: Teste no programa: Teste de ambiente 
Web 
 
Conceito de Teste na Web 
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 
segurança. 
 
 
 A estratégia para o teste de aplicações Web deve adotar os seguintes 
passos: 
 O modelo de conteúdo é revisto para descobrir erros; 
 O modelo de interface é revisto para garantir que todos os casos de uso 
possam ser acomodados; 
 O modelo de projeto da aplicação é revisto para descobrir erros de 
navegação; 
 A interface com o usuário é testada para descobrir erros nos mecanismos 
de apresentação e/ou navegação; 
 Os componentes funcionais são submetidos a testes de unidade; 
 É testada a navegação por toda a arquitetura; 
 A aplicação Web é implementada em uma variedade de configurações 
ambientais diferentes e testada quanto à compatibilidade com cada 
configuração; 
 São executados testes de segurança na tentativa de explorar 
vulnerabilidades na Aplicação ou em seu ambiente; 
 São realizados testes de desempenho; 
 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 à 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 mecanismo oferecido ao usuário através da 
interface: Link, formulários, script executado pelo cliente, HTML 
dinâmico, janelas pop up, scripts CGI, conteúdo encadeado (streaming), 
cookies e mecanismos de interface específicos de aplicativos. 
Teste de semântica da interface: 
 Avalia como o projeto se preocupa com os usuários, se oferece 
diretrizes claras, se fornece realimentação e se a aplicação mantém 
consistência de linguagem e abordagem através da interface. 
Teste de usabilidade: 
 Avalia o grau com o qual os usuários podem interagir efetivamente com 
a aplicação e o grau em que a aplicação dirige as ações do usuário, ou 
seja, determina o grau com o qual a interface da aplicação facilita a 
vida do usuário. A imagem mostra um conjunto possível de “graus” de 
avaliação que podem ser selecionados. 
Teste de compatibilidade: 
 Diferentes computadores, dispositivos de imagem, sistemas 
operacionais, navegadores e velocidades de conexão de rede podem ter 
influência significativa na operação da aplicação Web. Cada 
configuração de computador pode resultar em diferença nas 
velocidades de processamento no lado cliente, resoluções de tela e 
velocidades de conexão. Este tipo de teste procura descobrir possíveis 
problemas na utilização de diferentes configurações pelos usuários. 
Normalmente, procura-se utilizar as configurações mais usuais, já que 
seria muito complexo o teste de todas as configurações possíveis. 
 
 
Teste de Componente 
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: 
Teste de sintaxe 
 Segundo Pressman, neste tipo de teste os mecanismos de navegação 
são verificados para garantir que cada um execute sua função 
planejada e garantir que os erros sejam encontrados antes que a 
aplicação entre no ar: 
 Links de navegação 
 Cada link deverá ser testado para assegurar que o conteúdo 
ou a funcionalidade apropriada seja alcançado quando o 
Link for 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. Os redirecionamentos deverão ser 
testados através de solicitações de Links externos incorretos 
e avaliando como a aplicação lida com estas solicitações. 
 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 molduras 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 à 
compatibilidade com o navegador. 
 
Teste de semântica 
 A unidade semântica de navegação (NSU) é definida como uma série de 
informações e estruturas de navegação relacionadas que colabora no 
atendimento a um subconjunto de requisitos de usuários relacionados. 
 Desta forma, cada 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ântico 
deverá 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? 
 Se a NSU pode ser atendida usando mais de um caminho de 
navegação, 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? 
DICA 
Os testes de navegação, bem com o teste de interface e de usabilidade, devem 
ser feitos além dos testados, 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: 
 A aplicação é totalmente compatível com o sistema operacional 
do servidor? 
 Os arquivos de sistema, diretórios e dados de sistema 
relacionados são criados corretamente quando a aplicação está 
operacional? 
 As medidas de segurança permitem que a aplicação seja 
executada sem a interferência ou degradação do desempenho? 
 A aplicação está adequadamente integrada com o software de 
banco de dados? 
 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: 
 Hardware: CPU, memória, armazenamento e dispositivo de 
impressão; 
 Sistemas operacionais: Linux, Macintosh OS, Microsoft; 
 Software Navegador: Firefox, Safari, Internet Explorer, Opera, 
Chrome; 
 Componentes de interface de usuário: Active X, java Applets; 
 Plug-ins: QuickTime, RealPlayer; 
 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? 
 
ATENÇÃO 
Para obter respostas para essas perguntas, são feitos dois testes diferentes de 
desempenho: 
 Teste de carga 
 Teste de esforço (stress) 
 
Teste de Carga 
A finalidade do teste de carga é determinar como a webApp e seu ambiente 
do lado do servidor responderá a várias condições de carga. 
Neste tipo de teste são utilizadas como condições de teste as seguintes 
variáveis: 
 Número de usuários concorrentes (N); 
 Número de transações on-line por usuários por unidade de tempo (T); 
 Carga de dados processados pelo servidor por transação (D). 
À medida que o teste é feito, são realizadas permutações nas variáveis de 
acordo com os limites de operação normal do sistema e coletas uma ou mais 
das seguintes medidas: 
 Resposta média do usuário; 
 Tempo médio para o download de uma unidade padronizada de dados; 
 Tempo médio para processar uma transação 
 
O teste de carga também pode ser usado para avaliar a velocidade de 
conexão recomendada para usuários através da seguinte fórmula: 
P = N x T X D 
Por exemplo, (Pressman, 2011) vamos considerar um site de notícias popular. 
Em um momento, 20 mil usuários concorrentes enviam uma solicitação (uma 
transação, T) a cada 2 minutos em média. 
Cada transação requer que a aplicação faça o download de um novo artigo 
que na média tem um tamanho de 3k bytes: 
 
P = [ 20.000 x 0,5 x 3 kb] / 60 = 500 kbytes/segundo = 4 megabits/segundo 
 
Desta forma a conexão de rede do servidor teria, portanto, de suportar essa 
taxa de transferência de dados e deveria ser testada para assegurar que fosse 
capaz disso. 
 
Teste de Esforço (stress) 
O teste de esforço é uma continuação do teste de carga, e desta forma 
utilizam as mesmas variáveis: T, N, D, porém com seus limites operacionais 
excedidos. 
A finalidade deste teste é responder as seguintes questões: 
 O sistema degrada ou o servidor desliga quando é excedida a capacidade 
normal de operação? 
 O software servidor gera mensagens “servidor não disponível”? De uma 
maneira geral os usuários ficam cientes de que não podem acessar o 
servidor? 
 O servidor coloca as requisições por recursos em fila e esvazia a fila 
quando a demanda de capacidade diminui? 
 São perdidas transações quando a capacidade é excedida? 
 A integridade dos dados é afetada quando a capacidade é excedida? 
 Quais valores de N, T e D forçam o ambiente servidor a falhar? Como a 
falha se manifesta? São mandadas notificações automáticas para o 
pessoal de suporte técnico no local do servidor? 
 Se o sistema falha, quanto tempo demora até que volte a ficar on-line? 
 
O objetivo do teste de configuração é testar um conjunto de prováveis 
configurações ____________ e __________________ para assegurar que a 
experiência do usuário será a mesma em todos os casos e isolar erros que 
podem ser específicos a uma determinada configuração. 
Do cliente - do servidor 
Para responder a pergunta “O sistema degrada ou o servidor desliga 
quando é excedida a capacidade normal de operação?” utilizamos que tipo 
de teste? 
Teste de esforço (stress). 
Quais são os quatro tipos de testes aplicados no teste de interface de 
usuário? 
Mecanismos de interface, semântica, usabilidade e 
compatibilidade. 
 
Aula 5: Teste na Implantação do Sistema: Teste de 
Unidade 
 
Estratégias para teste de software 
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. 
 
 
 
Ao desenvolvermos uma estratégia de teste de software desejamos 
responder as seguintes perguntas: 
 Como conduzir os testes de software? 
 Devemos estabelecer um plano formal para os testes? 
 Devemos testar o programa como um todo ou executar testes somente 
em urna parte dele? 
 Devemos refazer os testes quando acrescentamos novos componentes ao 
sistema? 
 Quando devemos envolver o cliente? 
 
Quem os realiza? 
Normalmente, para que o processo de teste transcorra de forma íntegra é 
comum à 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. 
 
Existem várias responsabilidades e papéis dentro da equipe de teste: 
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. 
 
A criação, pelas equipes de teste, de um ambiente isolado, organizado, 
representativo e mensurável garante a descoberta de erros reais, que 
ocorreriam em um ambiente em produção e que não foram descobertos 
durante o desenvolvimento. Além disso, permite liberar a equipe de 
desenvolvimento para a produção de novos códigos, e este ambiente ainda 
possibilita a realização de testes de iteração e de sistema. É preciso que a 
preparação do ambiente seja discutida o quanto antes, e suas necessidades 
básicas devem ser identificadas no momento inicial do projeto. 
 
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ção com 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. 
 
 
 
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. 
 
 
 
 Casos de testes deverão ser projetados para descobrir erros devido a 
computações errôneas, comparações incorretas ou fluxo controle 
inadequados. 
 Todos os caminhos de manipulação de erro são testados. 
 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. 
 As condições limite são testadas para garantir que o módulo opere 
adequadamente nas fronteiras estabelecidas para restringir ou limitar o 
processamento. 
 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. 
 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. 
 
Procedimentos de teste de unidade 
O teste de unidade é considerado um auxiliar para a etapa de codificação. 
Podem ocorrer antes de começar a codificação ou depois que o código-fonte 
tiver sido gerado. Como cada componente não é um programa independente 
deve ser construído um pseudocontrolador (driver) e/ou um 
pseudocontrolado (stub) 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 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. 
 
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. 
 
Qual a principal diferença entre o teste unitário de software convencional e 
o teste unitário de software OO? 
Nos testes para software OO não podemos mais testar uma única 
operação isoladamente como no desenvolvimento convencional, 
mas como parte de uma classe. 
Dizemos que o teste unitário é o teste de mais baixo nível que podemos 
aplicar. O que isso quer dizer? 
Que 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. 
Qual o objetivo
da definição de uma estratégia de teste? 
Fornecem um roteiro que descreve os passos a serem executados, 
quando serão executados e quanto esforço de trabalho, tempo e 
recursos serão necessários. 
 
Aula 6: Teste na Implantação do Sistema: Teste de 
Integração e Teste de Validação 
 
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 Incremental (Big-Bang) 
 Neste tipo de abordagem todos os componentes são combinados com 
antecedência e o programa inteiro é testado de uma vez. Segundo 
Pressman, usualmente, o resultado desta abordagem é o caos, pois 
normalmente são encontrados muitos erros, tornando a correção difícil, 
pois, fica complicado isolar as causas dos erros. Uma vez corrigidos os 
erros, novos erros aparecem e o processo parece não ter fim. 
Incremental 
 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: 
 Integração descendente ou Top-down. 
 Integração ascendente ou Botton-up. 
 Teste de regressã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 
 (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. Nesse 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. 
 
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. 
 
ATENÇÃO 
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: 
 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/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 re-execuçã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, ainda nã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: 
 A característica de função ou desempenho está de acordo com a 
especificação e é aceita. 
 Descobre-se um desvio da especificação e é criada uma lista de 
deficiência. 
 
Os testes alfa e beta são classificados como: 
Teste de validação. 
Esse tipo de teste normalmente é executado após a correção de algum 
defeito ou após a adição de uma nova funcionalidade. A qual tipo de teste 
estamos nos referindo? 
Teste de regressão. 
Esse tipo de teste focaliza o pacote de software completo e trata da 
verificação do programa como um todo. Estamos nos referindo a que tipo de 
teste? 
Teste de integração. 
Aula 7: Teste na Implantação do Sistema: Teste de 
Migração 
 
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
3
 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. 
 
3
 O papel de um grupo independente de teste é remover os problemas 
associados ao fato de deixar o desenvolvedor testar o software que ele mesmo 
criou. O teste
independente remove o conflito de interesses que, de outra 
forma, poderia estar presente. 
A equipe independente de teste faz parte da equipe de desenvolvimento de 
software no sentido de que ela se envolve durante a análise, e o projeto e 
permanece envolvido (planejando e especificando procedimentos de teste) 
durante o projeto inteiro. É comum em muitos casos a equipe de teste 
responder a organização de garantia de qualidade de software para, desta 
forma, obter um grau de independência que poderia não ser possível se fizesse 
parte da organização de engenharia de software. Existem diferentes possíveis 
papéis com diferentes reponsabilidade dentro de uma equipe de teste 
independente: 
 Líder ou Gerente de Teste (LT ou GP) 
 Responsável pela liderança de um projeto de teste específico. 
 Arquiteto de Teste (AT) 
 Responsável pela montagem do ambiente de teste (infraestrutura) e 
escolha das ferramentas. 
 Analista de Teste (NA) 
 Responsável pela modelagem e elaboração dos casos de testes e 
scripts de teste. 
 Testador (TE) 
 Responsável pela execução dos casos de teste e scripts 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 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 
reparo (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. 
Qual é o teste que também é também conhecido como Teste de 
Configuração e que exercita o software em cada ambiente no qual deve 
operar? 
Teste de disponibilidade. 
A principal meta deste teste é entender o comportamento do sistema, 
durante condições-limite de execução ou fora da tolerância esperada. 
Teste de estresse ou de esforço. 
Esse tipo de teste mede e avalia o tempo de resposta, o número de 
transações e outros requisitos sensíveis ao tempo de resposta do sistema. 
Teste de desempenho. 
 
Aula 8: Teste na implantação do sistema: Teste de 
Migração 
 
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. 
 
DICA 
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 de recursos 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
4
 para 
garantir o que o projeto seja bem sucedido. 
 
4 
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; 
 
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 de 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: 
 Fusões e aquisições de empresas. 
 Otimização dos processos de negócio. 
 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: 
 Onde o layout da origem e o destino layout são os mesmos. 
 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 
às 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. 
 
ATENÇÃO 
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 
Uma importante 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. 
 
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. 
 
Equipes de teste 
As equipes de teste de aceitação e operacional irão realizar o teste de 
concepção e execução em paralelo em duas plataformas completamente 
diferentes e com objetivos e propósitos diferentes. Já a equipe de teste de 
legado irá trabalhar com cada um dos outros grupos separadamente. 
 
Equipe de teste de aceitação 
A principal tarefa do grupo de teste de aceitação é a definição, execução e 
análise dos resultados de todos os casos de teste de negócio possíveis. 
Embora possa parece uma tarefa trivial, ela não é, pois existe um grande 
desafio na elaboração dos testes de migração, já que os cenários de negócio 
são novos para os testadores e será a primeira vez que irão utilizá-los. 
 Uma vez que os resultados dos cenários de negócio são muito importantes e 
devem ser exatos, quase não existe tolerância a ocorrência de um erro. 
A equipe de teste de legado deverá trabalhar em estreita colaboração com a 
equipe de aceitação. Na prática a equipe de legado deverá aprovar ou não 
cada resultado de caso de teste que a equipe de aceitação irá executar e 
produzir. Sem estas aprovações o sistema será considerado como não 
migrado. 
As equipes de aceitação e legado irão verificar os resultados dos cenários de 
negócios a nível de bits e bytes, ou seja, quanto a exatidão dos valores, dados, 
relatórios, cálculos, estruturas de arquivos, botões de trabalho, arquivos de 
entrada e etc. 
 
Equipe de teste operacional 
É composta de usuários que irão utilizar o sistema. O grupo operacional irá 
realizar testes em paralelo com a equipe de aceitação mas com um objetivo 
completamente diferente. Este grupo irá trabalhar na futura plataforma e no 
ambiente sob todos os aspectos que não sejam sob o ponto de vista do 
negócio, ou seja, de conectividade e interoperabilidade. Irá testar interfaces, 
desempenho, sistema de back-ups e demais elementos da nova plataforma. 
Uma vez que a equipe de legado tem o conhecimento das características 
internas e externas e o comportamento geral do sistema antigo, eles poderão 
comparar e aprovar os resultados produzidos pela equipe operacional. 
 
 Equipe de teste de legado 
É composta por pessoas da área de negócio que estão familiarizadas com o 
sistema antigo. 
Esta equipe irá trabalhar com cada um dos outros grupos separadamente, ou 
seja, 50% com a equipe de teste de aceitação e 50% com a equipe 
Operacional. 
 
Você sabia? 
Nesta etapa a equipe de testes dependendo da situação deverá escolher e 
aplicar os tipos de testes já estudados nas aulas anteriores. 
O grau de validação requerido depende do quão críticos são os dados a serem 
convertidos. 
Teste de migração de uma plataforma a outra pode incluir testes operacionais 
do novo ambiente tanto quanto a mudança de software. 
 
 
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: 
 As correções requeridas nos dados de origem e a execução novamente da 
conversão. 
 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. 
 A observação dos erros de dados para a correção manual no novo 
sistema. 
 
Quais as fases do processo de migração de dados? 
Design, extração, limpeza, carga, e verificação. 
Em que consiste a migração dos dados: 
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. 
O que a equipe deve fazer após a etapa de carga dos dados? 
Os resultados deverão ser submetidos a uma etapa de verificação. 
 
Aula 9: Teste de software: Sistema em produção 
 
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 
 Baseia-se na execução do sistema em determinada unidade de tempo 
sem falhas. 
Disponibilidade 
 Baseia-se 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. 
 
Teste de Regressão 
 O teste de regressão é um teste seletivo, de um software que foi modificado 
ou já passou por iterações anteriores. Tem como propósito garantir que as 
falhas tenham sido reparadas e que as operações que funcionavam 
anteriormente não apresentem falhas após os reparos, ou seja, que as novas 
características adicionadas não tenham criado problemas ou 
incompatibilidades em relação as versões anteriores ou com outros sistemas. 
 
O objetivo desse tipo de teste é verificar se as alterações realizadas geraram 
alguma inconsistência no aplicativo ou em outros sistemas. Nesse caso, 
aplicam-se as mesmas técnicas de testes já utilizados em testes, 
anteriormente, e que são executados, progressivamente, para verificar se 
alguma falha foi introduzida após as mudanças. 
 
Teste em manutenção de software 
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. 
 
ATENÇÃO 
Os testes de manutenção podem se tornar uma tarefa complicada, se as 
especificações do software estiverem desatualizadas ou incompletas. 
 
Teste em manutenção de software 
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 ou falhas no aplicativo que esta sendo usado na 
empresa. Vale ressaltar que esse tipo de teste não é muito usual. 
 
Confiabilidade e disponibilidade de software 
Com o constante desenvolvimento da tecnologia, os sistemas computacionais 
têm sido requisitados em quase todas as áreas da atividade humana. Essa 
crescente dependência em relação ao software tem conscientizado os 
usuários, que cada vez mais exigem softwares confiáveis. 
Por conta disso, o software constitui a parte mais dispendiosa para a solução 
de um problema que envolve um computador. Consequentemente, 
desenvolver um software com qualidade tem exigido um enorme esforço na 
atividade de teste. 
Os problemas de confiabilidade e disponibilidade podem, quase sempre, ser 
associados a defeitos de projeto ou de implementação. 
Antes de estudarmos sobre a confiabilidade e disponibilidade de um software, 
precisamos compreender o conceito de falha. 
 
Mais o que é falha? Segundo Pressman (2011), falha é a falta de 
conformidade com os requisitos de software. 
 
Vamos relembrar o que são requisitos de software? 
Existem diferentes tipos de falhas que podem ser problemáticas ou 
catastróficas. Enquanto uma determinada falha pode ser corrigida em 
segundos, outras necessitarão de horas ou até mesmo meses para serem 
corrigidas. 
É importante considerar, também, que, às vezes, a correção de uma falha 
pode resultar na introdução de outros erros que resultarão em outras falhas. 
Hardware 
 Erros de fabricação. 
 Final de sua vida útil. 
Software 
 Enganos na especificação, projeto ou implementação. 
 Operadores humanos. 
 Falha ao operar o sistema. 
 
Requisitos de um software 
Os requisitos de um software são sentenças que expressam as necessidades 
dos clientes e que condicionam a qualidade do software. Podem ser 
classificados em: 
Requisitos Funcionais: 
 Estão diretamente ligados a funcionalidade do software. 
Requisitos Não Funcionais: 
 Expressam restrições que o software deve atender ou qualidades 
específicas que o software deve ter. 
Requisitos Inversos: 
 Estabelecem condições que nunca podem ocorrer. 
 
 Requisitos Não funcionais 
 
 
 
Dimensões da confiança de um software 
A confiança de um sistema, segundo Sommerville (2003) , é uma propriedade 
do sistema que equivale a sua integridade, ou seja, é o grau de confiança dos 
usuários de que o sistema operará como eles esperam e não “falhará” em uso 
normal. Existem quatro dimensões principais de confiança: 
 
Disponibilidade 
A disponibilidade de um software 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. Disponibilidade de software 
é a probabilidade de um sistema, em determinado instante, ser operacional e 
fornecer os serviços requeridos. 
 
A disponibilidade não depende do sistema em si, mas do tempo necessário 
para reparar os defeitos que tornam o sistema indisponível. 
 
Confiabilidade de Software 
O conceito de confiabilidade de software se baseia na execução do sistema 
em determinar unidade de tempo, sem falhas. A confiabilidade do produto de 
software é influenciada pelo processo de software utilizado para desenvolver 
o produto. Um processo orientado no sentido de evitar defeitos poderá 
desenvolver um sistema confiável. Você sabia que diferentemente de outros 
fatores a qualidade a: 
 
Em termos estatísticos, a confiabilidade de software é definida como: 
“...a probabilidade de operação livre de falhas de um programa de 
computador num ambiente específico durante determinado tempo” (Musa et 
al, 1987, in Pressman (1995). 
 
Segurança 
A segurança de um sistema é um atributo que reflete a capacidade do sistema 
de operar normal e anormalmente, sem ameaçar as pessoas ou o ambiente. 
 
Proteção 
A proteção de um sistema é uma avaliação do ponto em que o sistema 
protege a si mesmo de ataques externos. Erros no desenvolvimento
de um 
sistema podem levar a falhas de proteção. 
Sem um nível razoável de proteção, a disponibilidade, a confiabilidade e a 
segurança do sistema poderão ser comprometidas, se ataques externos 
provocarem algum dado ao sistema. 
 
Medida de confiabilidade de software 
Um meio simples de se medir a confiabilidade de um software é observar o 
tempo para a ocorrência da próxima falha. 
 
Métricas que podem ser utilizadas para medir a confiabilidade de um 
software: 
 
 
 
O tempo médio entre falhas, MTBF (mean time between failure), representa 
o tempo esperado para a ocorrência da próxima falha, ou seja, é o tempo 
durante o qual o software funciona sem falhas (Delamare&Maldonado&Jino, 
2007). 
O tempo médio é calculado, considerando-se a soma de duas medidas 
diretas: 
 MTTF (mean time to failure) 
 Tempo médio de uso até a falha do software e 
 MTTR (mean time to repair) 
 Tempo médio de reparo da falha no software. 
 
Portanto, quanto maior for o MTBF e o MTTF em relação ao MTTR, mais 
tempo o sistema ficou operativo. 
 
Medida de disponibilidade de software 
 
 
 
Através de exemplo, mostrar que a medida de disponibilidade de software 
considera as medidas MTTF e MTTR, sendo mais sensível ao MTTR ou seja, 
tempo de correção da falha, pois, a disponibilidade é obtida através de: 
 
 
 
Quanto mais próximo de 1 for a disponibilidade, mais produtivo foi o software 
no período. 
 
Engenharia de confiabilidade de software 
 Software tem sido companheiro meu, seu e de quase todas as pessoas em 
uma gama enorme de produtos. Em nosso cotidiano, podemos encontrar 
software embutido em forno micro-ondas, nos jogos de computador bem 
como no controle de aeronaves e sistemas de telecomunicações, só para citar 
alguns exemplos. 
Associado ao software, há um atributo de qualidade de suma importância 
para qualquer produto: confiabilidade. A confiabilidade de software é, 
geralmente, definida como a probabilidade do software operar sem 
ocorrência de falhas durante um período especificado de tempo em um 
determinado ambiente. 
Num contexto mais amplo, a qualidade de software é uma propriedade 
multidimensional que inclui, além da confiabilidade, outros fatores de 
satisfação do cliente como funcionalidade, usabilidade, desempenho, 
habilidade de prestação de serviço, manutenibilidade e documentação. 
Todavia, a confiabilidade de software é, comumente, aceita como um fator 
chave da qualidade de software, uma vez que a confiabilidade de software 
pode quantificar as falhas de software. 
Disponibilidade é um outro atributo importante de sistemas que têm 
software como componente. Disponibilidade é a probabilidade, em qualquer 
instante de tempo, de um sistema funcionar satisfatoriamente em um 
determinado ambiente. Em outras palavras, é a probabilidade de um sistema 
está disponível quando necessário. Disponibilidade pode ser determinada 
pela relação: 
 
Disponibilidade = ((MTTF)/(MTTF + MTTR)).100% 
 
onde: 
MTTF (Mean Time to Failure) é o tempo médio até a ocorrência de falha. 
MTTR (Mean Time to Repair) é o tempo médio de reparo. 
 
Esses dois atributos, confiabilidade e disponibilidade compreendem a base da 
engenharia de confiabilidade de software (ECS) que é definida como o estudo 
quantitativo do comportamento operacional de sistemas de software com 
base nos requisitos de usuários relativo a confiabilidade. Engenharia de 
confiabilidade de software inclui: 
 
Medição de confiabilidade de software, a qual inclui estimação e previsão 
com o uso de modelos de confiabilidade de software. 
Atributos e métricas de projeto de produtos, processo de desenvolvimento, 
arquitetura de sistema, ambiente operacional do software e suas implicações 
sobre a confiabilidade. 
 
Aplicação deste conhecimento na especificação e projeto da arquitetura de 
software do sistema, desenvolvimento, testes, uso e manutenção. 
Para tanto, torna-se necessário a coleta de dados de falhas. Esses dados são 
coletados para se fazer a medição da confiabilidade de software. Essa coleta 
compreende: (a) contagem de falhas – esse tipo de dado faz o rastreamento 
da quantidade de falhas detectadas por unidade de tempo; (b) tempo médio 
entre falhas. 
 
Esse tipo de dado faz o rastreamento dos intervalos entre falhas consecutivas. 
Além disso, ECS requer a medição de confiabilidade de software que envolve 
duas atividades: estimação e previsão de confiabilidade. 
A atividade de estimação determina a confiabilidade de software atual 
aplicando técnicas estatísticas de inferência aos dados de falhas obtidos 
durante o teste do sistema ou durante a operação do sistema. Esta é uma 
medida que considera a confiabilidade obtida desde um instante passado até 
o instante atual. Seu principal objetivo é avaliar a confiabilidade atual e 
determinar se o modelo de confiabilidade está bem calibrado. 
Já a atividade de previsão determina a confiabilidade de software futura 
baseada em métricas de software e medidas disponíveis. Dependendo do 
estágio de desenvolvimento, a previsão pode envolver diferentes técnicas 
como: 
 Quando os dados de falhas estão disponíveis – Por exemplo, o software 
encontra-se em testes ou no estágio operacional. Neste caso, as técnicas 
de estimação podem ser usadas para parametrizar e verificar os modelos 
de confiabilidade de software, os quais realizam previsão de 
confiabilidade de software futura. 
 Quando os dados de falhas não estão disponíveis – Por exemplo, quando 
o software ainda encontra-se na fase de projeto ou implementação. Neste 
caso, as métricas obtidas do processo de desenvolvimento de software e 
as características do produto resultante podem ser utilizadas para 
determinar a confiabilidade de software durante testes. 
 
As dimensões de confiança de um software são classificadas em: 
Confiabilidade, disponibilidade, segurança, proteção. 
A manutenção adaptativa irá: 
Adaptar o software a novas tecnologias (TI/SI), metodologias, 
modelos de gestão, legislação. 
A probabilidade de um sistema, em determinado instante, ser operacional e 
fornecer os serviços requeridos, refere-se ao conceito de: 
Disponibilidade. 
 
Aula 10: Ferramentas de Teste de Software 
 
Automação de teste de Software 
A diferença entre testes e automação de testes, é que no primeiro você 
realiza a tarefa de testar, e no segundo você usa um software que imita a 
interação com a aplicação no que se refere ao teste tal qual um ser humano 
faria (Graham e Fewster,1999). 
 
Basicamente os testes de software podem ocorrer de duas formas, através de 
testes manuais ou testes automatizados. 
 
O conceito de testes manuais é a utilização de recursos humanos para 
realizar todos os procedimentos de testes especificados. Este tipo de teste 
requer um número muito grande de profissionais e um controle eficiente de 
documentos em circulação. O risco inerente a esse tipo de teste é a grande 
incidência de erros humanos no processo devido a: 
 Não-execução dos procedimentos na ordem estabelecida 
 A valores digitados erradamente. 
 
Os testes automatizados utilizam ferramentas de testes que possibilitem 
simular usuários ou atividades humanas de forma a não requere 
procedimentos manuais no processo de execução dos testes. 
Entretanto requerem profissionais especializados e tempo no 
desenvolvimento da automação dos testes. 
 
Tipos de Testes Automatizados (Progressivos e Regressivos) 
 
A automação de teste deve ser vista: 
 
 
 
Técnicas de teste automatizado 
Para agilizar e automatizar o processo de teste a maioria das ferramentas de 
automação de testes apresentam como principais características: 
Gravador ou Recorde 
 Quase todas as ferramentas possuem de alguma forma um gravador 
que, uma vez acionado, grava, na forma de uma linguagem interna 
(seja visual ou não) tudo que o usuário fizer, ficando armazenado no 
script de teste.
Script de teste 
 Uma vez acionado pelo executor de testes, o script entra em execução, 
pois o que foi gravado vai sendo repetido. 
Executor de teste e playback 
 Recurso da ferramenta que executa o que foi gravado ou registrado no 
script de teste. Cada ferramenta implementa este recurso de uma 
forma, porém todas fazem a mesma coisa. 
Data-driven teste ou teste dirigido a dados 
 Consiste em criar um script e depois fazer isso de uma massa de dados 
que será executada no script, dirigindo a forma como será executado 
assim como a quantidade de vezes que ele será executado. 
 
Segundo Graham e Fewster (1999), existem diferentes estratégias 
consideradas ao se projetar e escrever scripts de testes: 
 
Scripts Lineares 
 É uma técnica que faz gravação ou replicação direta das ações do teste 
sem nada acrescentar. 
 Esta técnica consiste em gravar as ações executadas por um usuário 
sobre a interface gráfica de uma aplicação e converter estas ações em 
scripts de teste que podem ser executadas quantas vezes for necessário. 
Scripts estruturados ou scripts compartilhados 
 A técnica de script estruturado aciona mais de um comando simulando 
a execução em paralelo de diversas ações. Já na técnica de scripts 
compartilhados os scripts podem ser utilizados em mais de uma caso de 
teste e tendem a ser scripts genéricos como login e logout, por 
exemplo. Ambas as técnicas são uma extensão da técnica de scripts 
lineares possibilitando que os scripts de teste gravados sejam, alterados 
para que desempenhem um comportamento diferente. 
Data-driven scripts (técnica orientada a dados) 
 É uma técnica que separa os dados usados pelo script do script em si. 
Consiste em extrair dos scripts de teste os dados de teste e armazená-
los em arquivos separados da lógica de execução devido ao alto volume 
de dados. Uma das vantagens na utilização desta técnica é a 
possibilidade da utilização do mesmo script com diferentes arquivos de 
dados, em diferentes formatos. 
Keyword-driven scripts (técnica orientada a palavras chave) 
 Técnica muito semelhante ao data-driven script, porém neste caso 
utiliza palavras-chaves ou ações específicas que são usadas 
constantemente em mais de um script. Consiste em extrair dos scripts 
de teste, o procedimento de teste que representa a lógica de execução. 
 
Ferramentas de teste automatizado de software 
As revisões e testes são instrumentos de controle de qualidade de um 
projeto. Existem diversas ferramentas de apoio a tais atividades, que variam 
tanto quanto a parâmetros como técnicas implementadas e linguagens 
suportadas:. 
Para um bom desempenho do processo de automatização estas ferramentas 
devem ser integradas entre si: 
 
 
 
Ferramentas de Modelagem e Automação 
As ferramentas de modelagem auxiliam no processo de construção e 
documentação de como serão testados todos os requisitos de negócio, 
possibilitando registrar todos os procedimentos de teste a cada cenário 
estabelecido e ainda o processo de conferência dos dados. 
Estas ferramentas possibilitam o desenvolvimento de scripts automatizados. 
As principais características destas ferramentas são a modelagem de testes, 
gerador de massa de dados e automatizados de scripts. 
 
 
A modelagem de testes auxilia nos processos de planejamento e construção 
dos testes, identificado os diversos cenários estabelecidos para cada requisito 
a ser testado. Determina as informações que devem ser empregadas em cada 
procedimento de teste, atingindo o menor nível de detalhamento. 
Vale ressaltar que a modelagem dos testes é um processo mental, assim 
nenhuma ferramenta substituirá a experiência e abstração de um bom 
analista de testes, porém estas ferramentas auxiliam na estruturação das 
ideias. 
A geração de massa de dados possibilita a geração automática de massa de 
dados baseada no planejamento dos testes e critérios estabelecidos de forma 
a garantir uma massa diferenciada e nas circunstâncias desejadas. 
A automação de scripts possibilita a interação entre as rotinas automatizadas 
e os softwares a serem testados através da captura de valores em telas, 
arquivos, relatórios ou mesmo em banco de dados. Permitem automatizar 
não somente as atividades de entrada de informações, como o processo de 
conferência (análise da saída das informações). 
 
Ferramentas de execução e Conferência 
As ferramentas de execução e conferência possibilitam o gerenciamento e o 
controle do processo de execução, re-execução e medição dos testes 
planejados. Possibilitam integração entre as demais fases, de forma a 
executar os testes selecionados no planejamento. As principais características 
destas ferramentas são a: análise de cobertura, executor de scripts, 
simuladores de performance e testadores de memória. 
 
 
Executor de scripts: Como as ferramentas de execução e conferência são 
normalmente integradas aos softwares de planejamento de testes e 
desenvolvimento de scripts, o executor de scripts permite executar os 
procedimentos na ordem e frequências preestabelecidas. Permite também a 
gestão do ciclo de testes como um todo, com o controle de execução de cada 
caso de testes, o controle da re-execução dos testes e os desvios de testes 
provocados por erros inesperados. 
Simuladores e medidores de performance: Estão diretamente ligadas aos 
testes de sistema, como os testes de carga, volume e performance, já que 
nessa categoria é impossível conceber a ideia de realizar testes sem empregar 
ferramentas específicas. 
Testadores de memória: Auxiliam no processo de detecção de problemas em 
relação ao uso e alocação de memória pela aplicação. Sendo assim devem ser 
específicas para cada linguagem e ambiente. 
Análise de cobertura: possibilita estabelecer uma métrica de cobertura do 
teste através do monitoramento das linhas de código executadas. Os testes 
de caixa branca requerem esse tipo de ferramenta, pois possibilita visualizar 
áreas do código não cobertas pelos testes em execução. 
 
Ferramentas de Revisões e Inspeções 
Estas ferramentas auxiliam nas revisões de documentos e inspeções técnicas 
que podem ser aplicadas em todas as etapas do processo de 
desenvolvimento. Suas principais características são a análise de 
complexidade, a compreensão do código e a análise sintática de semântica. 
 
 
 
A análise de complexidade auxilia a identificar onde estão as áreas mais 
complexas e quais possuem maior risco de introduzir novos erros, além de 
quantificar o esforço e os custos dos testes a serem empregados. 
A compreensão de código auxilia a inspecionar os códigos-fontes, 
possibilitando avaliar a aderência a padrões de programação estabelecidos 
pela organização, como por exemplo: 
 Padrão de nome, 
 Utilização de rotinas corporativas, 
 Variáveis não utilizadas, 
 sub-rotinas internas não acionadas, 
 APIs incompatíveis com determinados sistemas operacionais. 
A análise sintática e de semântica localiza erros na sintaxe e na semântica 
dos comandos empregados no código, os quais o compilador não acusaria, 
sendo possível detectar defeitos antes de os testes formais serem iniciados. 
 
Ferramentas de Planejamento de Testes 
Esta categoria de ferramenta apoia o processo de planejamento dos trabalhos 
de testes, definindo escopos, abordagens, agendando reuniões e 
programando atividades. Auxiliam no processo de documentação inicial, 
possibilitando gerar planejamentos padronizados e na elaboração de 
estimativas de tempo e custo, além de dimensionar as equipes de acordo com 
o tempo disponível. Estas informações são geradas a partir da coleta inicial 
de requisitos de software que irão possibilitar dimensionar o esforço e 
complexidade envolvida no processo de desenvolvimento. As principais 
características destas ferramentas são a análise de criticidade e a geração de 
documentos. 
 
A análise de criticidade permite direcionar
esforços de forma eficiente, 
através da priorização dos sistemas, indicando quais sistemas devem ser 
testados inicialmente. Permite também estimar tempo, custos e equipes 
através da análise da complexidade de cada software, baseando-se nos 
requisitos a serem cumpridos. 
A geração de documentos facilita o processo de documentação, através da 
utilização de parametrizações e modelos de documentos. Permitem também 
gerenciar as versões dos modelos e ainda possibilitam organizar work-flow de 
preparação, elaboração, inspeção e aceite dos documentos. 
 
Ferramentas de suporte aos testes 
Estas ferramentas apoiam atividades que não estão diretamente ligadas ao 
processo de testes, porém garantem que determinados itens fundamentais 
desse processo estão sendo bem gerenciados. As principais características 
destas ferramentas são: Gerenciamento de defeitos e gerenciamento de 
configurações. 
 
 
O gerenciamento de defeitos tem como objetivo acompanhar e controlar os 
defeitos identificados durante o ciclo de vida do software e monitorá-los até a 
sua solução final, através da produção de um grande número de indicadores 
de qualidade. Permite parametrizações de forma a customizar um workflow 
de resolução de problemas, para melhor adapta-se a estrutura da empresa. 
Também é conhecido por: 
 Gerenciamento de erros, gerenciamento de problemas, 
 Registro de ocorrências, controle de incidências. 
O gerenciamento de configurações permite controlar e coordenar as 
mudanças efetuadas em documentações, fontes e ambientes físicos. 
Estabelece a relação entre os artefatos de software e identifica-los através de 
um único controle de versão enquanto ocorrem modificações de fontes de 
uma versão anterior. 
 
Qual ferramenta utilizar? Nesta aula iremos conhecer de uma forma resumida 
alguma das principais ferramentas utilizadas no mercado para testes 
automáticos de software: 
 
JUnit 
 Framework de código aberto que tem o objetivo de facilitar a 
automatização de testes unitários em aplicações que utilizam a 
linguagem Java e possui integração com várias IDES. 
 Para acessar maiores informações: http:// www.junit.org/index.htm 
 
A IDE (Integrated Development Environment ou Ambiente Integrado de 
Desenvolvimento), é um programa de computador que reúne uma série de 
características e ferramentas de apoio ao desenvolvimento de software com o 
objetivo de agilizar este processo. As IDE s disponíveis para desenvolvimento 
em Java são: 
 Código aberto: Eclipse, NetBeans, VIM, jEdit, BlueJ 
 Código proprietário: JCreator, Borland JBuiLder, lntellij Idea, Sun Studio 
Creator, OracleJdeveloper. 
JMeter 
 Ferramenta de código aberto para aplicações Java projetada 
inicialmente para testes funcionais e de performance para aplicações 
web. 
RFT (IBM Rational Functional Tester) 
 Ferramenta de propriedade da empresa IBM para automação de teste 
de regressão, funcional, de interface gráfica (GUI) e data driven. 
Mercury Quality Center 
 Conjunto de ferramentas de propriedade da empresa HP que abrange 
diferentes tipos de testes, linguagens e arquitetura. Possui uma 
interface integrada baseada na Web para teste e gerenciamento de 
qualidade de software em diversos ambientes de aplicação. 
JaBUTi (Java Bytecode Understanding na Testing) 
 Ferramenta de suporte ao teste estrutural para programas Java, 
desenvolvida pela USP. O seu diferencial entre as outras ferramentas 
existentes com a mesma função de teste é que toda a análise estática 
necessária para a realização do teste é feita sobre o programa objeto, 
ou seja, sobre o bytecode Java e não sobre o programa fonte. 
 
Projeto de automação de teste 
Um projeto de automação de teste é um investimento alto e de longa 
duração, e por isso mesmo os dirigentes das organizações obviamente tem 
expectativas em relação a custos e aos benefícios trazidos pela sua 
implementação. Por isso um projeto de automação de testes deve ser 
cercado de alguns cuidados: 
 
 
 
Ferramenta: Seleção da ferramenta certa, adequada à tecnologia usada e que 
possa integrar com as metodologias de desenvolvimento e teste. 
Metodologia: Existência de metodologias de desenvolvimento e testes 
consolidadas e usadas, que possam se integrar com a ferramenta escolhida. 
Infraestrutura: Disponibilidade de máquina e seus recursos, um projeto em 
desenvolvimento (em fase de testes) dedicado para o projeto de automação 
de testes. 
Recursos: Garantia por parte dos dirigentes da organização quanto à 
disponibilidade de recursos humanos capacitados e financeiros para o 
projeto, apoio para as mudanças requeridas nos processos de 
desenvolvimento e testes, assim como nas ferramentas de desenvolvimento. 
 
Quais casos de testes são candidatos a automatização? 
A cada nova versão de um software torna-se necessário realizar um novo 
conjunto de teste, visando ampliar as melhorias implementadas. Desta forma 
também é necessário reexecutar um conjunto de casos de testes (todos ou 
partes) de forma a avaliar se as mudanças realizadas danificaram outras 
partes do software que já funcionava. 
 
 
 
Os custos relativos à execução dos testes de progressão não são importantes. 
Porém são importantes os custos de execução dos testes de regressão, pois 
estes devem ser reexecutados ao longo do ciclo de vida do software. 
 
Desta forma devemos considerar que os testes automatizados visam a 
otimização da execução dos testes, mas deve ser feito, preventivamente, um 
estudo de viabilidade técnica e um estudo de custo beneficio para sua 
utilização ou não. Os testes automatizados não substituem os testes 
manuais, eles são complementares e para isso devemos levar em 
consideração que todo caso de teste é naturalmente candidato à automação, 
mas naturalmente nem todos são recomendáveis para automação: 
 
 Se o caso de teste for algo pontual e específico de alguma versão do 
software e não se espera que seja testado em versões futuras, não é 
candidato à automação. 
 Se o caso de teste tiver características de uso de uma grande massa de 
dados, indica ser um data-driven test que precisará provavelmente ser 
automatizado. 
 Não existe tempo hábil para automatizar o teste desejado devido ao 
cronograma, então ele não será momentaneamente um teste a ser 
automatizado. 
 
O termo automação de teste de software significa a utilização: 
De um software que imita a interação com a aplicação no que se 
refere ao teste tal qual um ser humano faria. 
Para a implementação de um projeto de automatização de teste precisamos 
de: 
Recurso, infraestrutura, ferramenta e metodologia. 
O gerenciamento de defeitos e o gerenciamento de configuração são 
características de qual tipo de ferramenta? 
Ferramentas de Suporte aos Testes.