Referência Bibliográfica

Engenharia de Software: Uma abordagem Profissional

8ª Edição – Roger Pressman / Bruce Maxim

Testes de software e gerência de configuração

GONÇALVES, Priscila de Fátima.; BARRETO, Jeanine dos Santos

• Planejamento: elaboração e revisão da estratégia e do plano de teste.

• Preparação: preparação do ambiente de testes, incluindo equipamentos, softwares,
rede, pessoal e ferramentas.
• Procedimentos iniciais: elaboração de um documento que estabelece o acordo entre
as partes envolvidas nos testes (objetivo, pessoal, res-ponsabilidades, etc.).
• Especificação: elaboração e revisão dos casos de teste manuais (roteiros de testes) e
automáticos (scripts).
• Execução: execução dos testes planejados conforme os casos de teste elaborados e
geração dos registros de resultados (relatórios de testes).
• Entrega: conclusão do processo de testes com a entrega da parte ou do todo do
sistema.

CLASSIFICAÇÃO PROBLEMAS SOFTWARE

Um produto de software pode apresentar problemas. A seguir, veja como esses problemas
podem ser classificados.

• Erro: é qualquer erro humano que resulta em algo incorreto. Um erro acontece
quando existe uma diferença entre o valor obtido em uma operação matemática e o
valor que era esperado.
• Defeito: é qualquer inconsistência do software, evidenciando algo que foi
implementado ou programado de maneira incorreta. Um exemplo acontece quando
existem incorreções nas linhas de código-fonte. Todo defeito é causa de erros, mas,
 por outro lado, se a linha que estiver incorreta jamais for executada, o erro não vai
acontecer.
• Falha: é qualquer comportamento inesperado realizado pelo software. Uma falha
pode ter sido gerada por vários erros, mas alguns erros podem nunca gerar uma falha.
É o caso de uma operação aritmética que é programada e não é usada.

TIPOS DE TESTES DE SOFTWARE

• Teste unitário
Normalmente é realizado pelos próprios desenvolvedores, nas porções menores do
software que estão sendo desenvolvidas no momento, de maneira individualizada. Ele
serve para verificar se as partes do software funcionam de maneira isolada das demais
partes do sistema.

• Teste de caixa branca

Avalia a parte interna do software, seu código--fonte. Ele serve para identificar
problemas na lógica de programação e também na estrutura do programa,
observando elementos como as condições usadas, os laços de repetição e o fluxo
tomado pelos dados. O testador deve lembrar-se de verificar se o nível de segurança e
confiança exigido está sendo implementado.

• Teste de caixa preta

Avalia a parte externa do software, o seu modo de funcionamento. Esse tipo de teste
serve para identificar se o software está funcionando como deveria, se os dados
informados resultam nas informações pretendidas e se, de maneira geral, o sistema
faz o que ele deveria fazer.

• Teste de caixa cinza

É uma combinação dos testes de caixa branca e de caixa preta, pois ele avalia os
aspectos internos e também os aspectos externos do software, as suas entradas, o
fluxo dos dados e as saídas.

• Teste de regressão
Tem a função de testar cada nova versão do software toda vez que uma
funcionalidade for modificada. Ou seja, toda a parte pronta do software será testada
novamente para verificar se alguma novidade resultou em problema. Esse tipo de
teste é muito importante para indicar se erros que já haviam sido corrigidos não
voltaram a se manifestar.

• Teste de integração
Tem como propósito verificar se as porções menores, testadas anteriormente pelos
testes unitários, têm condições de funcionar em conjunto, formando um sistema. Esse
teste é muito importante, pois funcionalidades que operam perfeitamente de maneira
isolada podem apresentar problemas quando tentam, por exemplo, realizar o fluxo de
dados de uma parte do sistema para outra.

• Teste de volume
 Esse teste tem como objetivo avaliar até que limites um software pode ser utilizado,
ou seja, qual é o seu limite de suporte a informações ou tráfego sem que apresente
nenhum problema.

• Teste de performance
Divide-se em outros três tipos, listados a seguir.

• Teste de carga
Verifica o software como um todo, em condições normais de uso, avaliando o tempo
de resposta das operações, quantas operações podem ser executadas em
determinado período de tempo, quantos usuários simultâneos gravando dados podem
existir, entre outros aspectos.

• Teste de estresse
Identificados os limites do software por meio dos testes de volume, esse teste serve
para levar o software aos seus limites. A ideia é verificar em que ponto ele para de
funcionar corretamente.

• Teste de estabilidade
Verifica se o software se mantém funcionando de maneira adequada depois de ser
utilizado por um longo período de tempo.

• Teste funcional ou de funcionalidade

Verifica se o software como um todo, bem como cada parte dele, faz exatamente o
que deveria fazer, ou seja, se os casos de uso foram corretamente descritos e
desenvolvidos.

• Teste de segurança
Verifica se o software permite que os dados sejam acessados somente pelos perfis
determinados para cada parte específica do sistema ou para cada funcionalidade.

• Teste de usabilidade
É realizado por usuários e não por analistas. O seu propósito é verificar se o software
satisfaz as necessidades do usuário. Esse teste serve para identificar a forma como o
usuário utiliza as funcionalidades do software, na tentativa de apontar partes do
sistema em que ele apresenta maior dificuldade de interação. Como esse teste é feito
pelos clientes, é importante o acompanhamento de analistas para documentar
comentários, sugestões e reclamações.

• Teste de aceitação
Serve para verificar se o produto de software está pronto para ser entregue ao cliente,
ou seja, se ele está pronto para entrar em produção. Geralmente, esse teste é
realizado por alguém indicado pelo cliente, ou ainda por um testador especializado
que não tenha participado do projeto, mas que tenha grande conhecimento acerca
dos requisitos do software.

• Teste de instalação
 Tem como propósito verificar se o software é passível de ser instalado de maneira
correta, em diferentes hardwares, com diferentes sistemas operacionais e diferentes
disposições de memória, rede, entre outros aspectos.

• Teste de configuração
Serve para identificar se o software funciona de maneira adequada no hardware para
o qual foi planejado e no qual será instalado.

• Teste de manutenção
Avalia se determinada mudança em algum aspecto do software resultou em falhas no
seu funcionamento como um todo.

O TESTE DE CAIXA-BRANCA

• O teste de software é uma atividade em que um software (ou uma parte dele) é
executado para se verificar se está em conformidade com as suas especificações e se
funciona corretamente dentro do ambiente para o qual foi projetado.
• Para que o teste de caixa-branca seja realizado, são escolhidos dados de entrada que
servirão para testar e verificar a lógica utilizada na programação do software
• Teste de caixa-branca serve para verificar se o código-fonte está bem escrito e se os
caminhos lógicos realizados pelo software são adequados. Ele coloca em xeque todos
os conjuntos específicos de condições ou laços de repetição, bem como toda e
qualquer estrutura do programa, como chamadas de função, decisões lógicas de
verdadeiro ou falso, cálculos, acesso a dados, acesso à interface, chamadas de
relatórios, entre outras.
• Principais testes
o Teste de unidade: Identificar Problemas como
▪ Comparação incorreta de tipos de dados;
▪ Término de laço inadequado
▪ Elaboração de estruturas lógicas incorretas;
▪ Cálculos mal elaborados;
▪ Estruturas não utilizadas ou duplicadas;
▪ Erros, defeitos e falhas não tratados;
▪ Falta de mensagem de retorno;
▪ Descrição de problema incompreensível;
▪ Descrição de problema que não fornece informações suficientes para
que o usuário entenda o que deve ser feito;
▪ Informação de problema divergente do que realmente aconteceu.
o Teste do caminho básico
▪ Ele é realizado com caminhos mais básicos, até que todos os caminhos
passíveis de serem percorridos pelo software sejam avaliados. Um
bom exemplo disso seria o testador incluir um registro no banco de
dados, alterar esse registro utilizando outra parte da interface,
executar um relatório em que esse registro apareça e ainda tentar
excluí-lo — tudo isso sem utilizar a interface do software, apenas
seguindo os passos dentro da estrutura interna.
o Teste de estrutura de controle
 ▪ Nesse tipo de teste, o testador precisa analisar todas as estruturas de
controle contidas no código-fonte da aplicação, tais como as
condicionais, os fluxos de dados, os laços de repetição, as chamadas
de função, entre outras.
o Teste de contexto em orientação a objetos
▪ Testador analisa todas as chamadas a estruturas de orientação a
objetos, como classes e métodos, e sua implementação. Esse tipo de
teste deve levar em consideração todos os níveis de hierarquia
previstos, quando houver classes com herança. Isso porque um
método que funcione corretamente para uma classe pode não
funcionar da mesma maneira com uma classe que seja sua herdeira.
• O teste de caixa-branca é uma técnica também conhecida como teste estrutural. Esse
teste é utilizado para testar módulos juntamente aos seus componentes elementares,
de modo a verificar seu nível de qualidade. Segundo Pressman e Maxim (2016), o teste
de caixa-branca usa a visão interna do sistema, então necessita do conhecimento
acerca do seu funcionamento interno. Em síntese, essa técnica tem como fundamento
examinar os detalhes procedimentais e os caminhos lógicos do software.

• Notação de grafo de fluxo

o A notação de grafo de fluxo é uma ferramenta usada para representar o fluxo
de controle lógico. Dessa forma, é possível representar um fluxograma de
controle do programa em um grafo de fluxo correspondente (Figura 2).

o Caminho básico
▪ Os caminhos básicos aplicados na Figura 2(b), ou seja, o grafo de fluxo,
são o 1 e o 4. Isso significa que um teste projetado para forçar a
execução desses caminhos base terá como resultado um teste que
executará com certeza pelo menos uma vez cada comando. Além
disso, cada condição terá seus testes de verdadeiro e falso testados.

o Caminho independente
▪ Pressman e Maxim (2016) afirma que um caminho independente pode
ser iden-tificado na Figura 2(b), ou seja, no grafo de fluxo, ao se
considerar a seguinte sequência de passos.
 a) 1 – 11.
b) 1 – 2 – 3 – 4 – 5 – 10 – 1 – 11.
c) 1 – 2 – 3 – 6 – 8 – 9 – 10 – 1 – 11.
d) 1 – 2 – 3 – 6 – 7 – 9 – 10 – 1 – 11.
o Teste de condição
▪ erros de operador booleano;
▪ erros de variáveis booleanas;
▪ erros de parêntese booleano;
▪ erros de operador relacional;
▪ erros de expressão aritmética.

• Complexidade ciclomática
o No critério de complexidade ciclomática, pode ser aplicado o cálculo
ciclomático com o exemplo da Figura 2(b), ou seja, o grafo de fluxo.
Acompanhe os itens a seguir.
▪ A complexidade ciclomática corresponde exatamente ao número de
regiões do grafo. Nesse exemplo, o grafo de fluxo tem quatro regiões.
▪ A complexidade ciclomática V(G) para o grafo de fluxo é definida como
V(G) = E – N + 2. “E” é o número de arestas e “N” é o número de nós
do grafo. Nesse exemplo, a fórmula assume V(G) = 11 arestas – 9 nós +
2 = 4.
▪ A complexidade ciclomática V(G) para o grafo de fluxo é definida como
V(G) = P +1. “P” é o número de nós predicados no grafo. Nesse
exemplo, a fórmula é V(G) = 3 nós predicados + 1 = 4.
• Teste de fluxo de dado
o Para realizar os testes de fluxo de dados, é preciso estabelecer que as variáveis
assumem:
o Definição — acontece quando uma variável recebe a atribuição de um valor;
o Uso computacional — acontece quando uma variável é utilizada para
computar;
o Uso predicativo — acontece quando uma variável é usada em uma estrutura
condicional.

• Demonstração
o Passo 1: extrair o grafo de fluxo correspondente do código-fonte
 o Passo 2: calcular a complexidade ciclomática do diagrama de fluxo resultante
▪ V(G) = 4 regiões.
▪ V(G) =
▪ V(G) = 14 nós. N
▪ Cálculo: V(G) = E – N + 2, ou seja, V(G) = (16 – 14) + 2 = 4
▪ O resultado do cálculo são 4 caminhos linearmente independentes.
o Passo 3: determinar um conjunto base de caminhos independentes
▪ Caminho 1: 1, 2, 12, 13, 14.
▪ Caminho 2: 1, 2, 3, 4, 10, 11, 13, 14 (impossível).
▪ Caminho 3: 1, 2, 3, 4, 5, 6, 7, 9, 4, 10, 11, 12, 14.
▪ Caminho 4: 1, 2, 3, 4, 5, 6, 8, 9, 4, 10, 11, 13, 14.
o Passo 4: criar caso de teste que obrigue a execução de cada caminho do
conjunto base

O TESTE DE CAIXA-PRETA

• Essa é a técnica de teste em que o componente interno do software, que é a sua

estrutura, é abordado como se fosse uma caixa-preta. Ou seja, ele é desconhecido,
não se sabe o seu conteúdo. No teste de caixa-preta, o testador não tem acesso a
nenhuma parte do código-fonte do software e também não conhece nada da estrutura
 interna dos programas (PEZZÈ; YOUNG, 2008). O teste de caixa-preta consiste em
averiguar se todas as funcionalidades estão
• Operando de maneira adequada por meio da utilização da interface do software. O
comportamento do software como um todo é, então, determinado durante a
avaliação da inclusão das entradas e da produção das saídas do sistema.
• Detecta problemas de vários tipos:
o Aceita que o usuário informe uma data futura como a data de seu nascimento;
o Permite que o usuário deixe campos obrigatórios em branco;
o Não executa as ações que os botões estão destinados a realizar;
o Permite que o usuário informe um período de datas, sendo que a data final é
menor do que a data inicial.
• Principais testes
o Particionamento da equivalência
Nesse tipo de teste, os dados de entrada são divididos em categorias, para que
os casos de teste possam ser derivados. Isso permite que os casos de teste
sejam capazes de identificar tipos ou categorias diferentes de erro, como a
falta de mensagem de confirmação de exclusão de registro. Normalmente, os
dados de entrada são separados também entre válidos e inválidos para o
sistema, para assim se verificar a resposta que produzem.

o Análise do valor limite

Nesse tipo de teste, o principal objetivo é testar os limites do software, o que
se chama de extremidades do sistema. Além de testar os dados de entrada e
as saídas produzidas, é preciso também analisar as saídas produzidas quando
um dado inserido excede os limites impostos, como datas, valores para
cálculos, etc. Dessa maneira, é possível averiguar se as condições de entrada
estão sendo validadas de alguma forma e se esses limites estão sendo
trabalhados de maneira adequada. Um bom exemplo é o fato de o sistema
esperar que um intervalo entre datas seja de 01/01 a 31/01 e o testador
inserir a data final como 31/03 para verificar a resposta recebida. Outro teste
seria dar entrada em valores negativos quando o sistema espera que seja
digitado um valor entre 0 e 5

• É comum que os testes de caixa-preta sejam projetados com informações extraídas a

partir da própria base de especificação do sistema, como
o Manuais do sistema;
o Diagramas de caso de uso;
o Documento de requisitos funcionais e não funcionais.
• O teste de caixa-preta é mais comumente aplicado em nível de sistema, mas pode ser
utilizado também em outros níveis, como unidade, integração e sistema

• Os testes de caixa-preta utilizam critérios para determinar quais casos de teste são
necessários. Esses critérios são:
1. Partição de equivalência;
2. Análise de valor limite;
3. Tabela de decisão;
4. Grafo de causa e efeito;
5. Teste de caso de uso.

• Partição de Equivalência
o A partição de equivalência consiste em dividir as entradas de dados para o
sistema em grupos ou classes de dados similares que podem ser tratados da
mesma forma.
o Isso possibilita a redução do número de testes a serem escritos, já que um
único teste nesse grupo de dados permite descobrir se o processamento está
correto ou incorreto para todo o restante.
o Como exemplo, considere uma entrada de valor para informação do mês,
sendo que a faixa permitida é de 1 até 12. Veja a seguir.
▪ Partição válida:
• Valores maiores que 0;
• Valor 1;
• Valor 12.
▪ Partição inválida:
• Valores menores que 1.
• Valores maiores que 12.
▪ Partição inválida:
• Números reais.
• Caracteres não numéricos.
o Para identificar as classes de equivalência, considere o seguinte:
▪ Exigência de uma entrada por intervalo de valores — definir uma
classe de equivalência válida e duas inválidas;
▪ Exigência de uma entrada específica de valor — definir uma classe de
equivalência válida e duas inválidas;
 ▪ Exigência de uma entrada de um membro de um conjunto — definir
uma classe de equivalência válida e uma inválida;
▪ Exigência de uma entrada booleana — definir uma classe de
equivalência válida e uma inválida
o Demonstração

• Análise de Valor Limite

o A técnica de análise de valor limite para os projetos de testes complementa a
técnica de partição de equivalência. Ela conduz o teste selecionando dados nos
limites de um intervalo da partição de equivalência.

o Como exemplo, considere uma entrada de valor no sistema, sendo que a faixa
permitida é de 1 até 12. Veja a seguir.
▪ Entradas válidas:
• 1 até 12.
▪ Fronteiras válidas:
• 1 como menor número e 12 como maior.
▪ Fronteiras não válidas:
• 0 no limite inferior e 13 no limite superior.

o Existe ainda uma variação da técnica que testa três valores na fronteira
definida. No exemplo que você acabou de ver, essa busca seria para o limite
inferior 0, 1, 2 e para o limite superior 11, 12, 13
o Demonstração
• Tabela de decisão
o O critério por tabela de decisão é uma boa alternativa para avaliar requisitos
de sistema que trabalham com condições lógicas em regras de negócio mais
complexas. As condições de entrada e saída são determinadas na tabela de
decisão, que dispara a combinação de verdadeira ou falsa para obter o
resultado da ação. Cada coluna da tabela pode representar uma regra de
negócio diferente. Observe o Quadro 1, a seguir.

• Demonstração

• Transição de estados
o O critério de teste por transição de estados é utilizado para validar as
transições que acontecem dentro de um sistema ao se aplicar uma ação
 que depende do estado atual ou do estado anterior. Os testes podem ser
elaborados para validar se uma sequência típica de estados está ocorrendo
de forma correta ou se alguma transição inválida pode acontecer no fluxo
o Um exemplo muito comum é a transição de estados quando um sistemade
banco é acessado por um usuário que realiza uma compra e deseja pagar
com um cartão de crédito. Na Figura 4, a seguir, veja um fluxo simples que
demonstra as transições de estado

o Demonstração

• Teste de caso de uso

o Os testes que utilizam o critério caso de uso são geralmente especificados a
partir de casos de uso e/ou cenários de negócio. Os casos de uso, por
exemplo, representam a interação do ator com o sistema. O resultado é
bastante relevante para o usuário. Dessa forma, os testes derivados de
casos de uso são muito importantes na descoberta de defeitos no fluxo de
utilização do sistema no mundo real. Eles podem contribuir para o aceite do
produto pelo usuário final e, em casos de integração, revelar problemas por
interferência de outros componentes que um teste individual de
componente não detectou.
o Demonstração
 • Teste Caixa Preta
o Selenium

PLANEJAMENTO DE TESTES

• O planejamento de testes tem alguns objetivos principais

o Identificar quais funcionalidades e componentes do software deverão ser
testados em cada momento;
o Apontar os recursos necessários para que os testes sejam executados de
maneira adequada, o que envolve recursos humanos, tecnológicos e inclusive
de ambiente;
o Recomendar e descrever as técnicas e estratégias que serão utilizadas ao
longo da realização das atividades de teste;
o Descrever a maneira como os testes serão realizados, para que os testadores
possam seguir esse procedimento;
 o Indicar o tipo de relatório que o ciclo de testes deverá produzir e o que ele
deve conter, como as atividades de teste realizadas, a data, a hora de início e
fim do teste, o nome do testador responsável, os resultados obtidos e os
problemas identificados.
• Documentos fundamentais para o planejamento de testes
o Plano de teste: esse documento deve ser o fundamento para o início das
atividades de teste de software. Nele, devem constar todas as atividades de
teste que serão realizadas, o seu escopo, a cobertura dos testes, as
funcionalidades ou as partes do software que serão testadas e as que não o
serão (incluindo o motivo), as restrições, os requisitos de ambiente, os
critérios de validação e os responsáveis por cada uma das atividades.
o Caso de teste: é o documento que descreve detalhadamente o teste de uma
parte específica. Ele deve apresentar os valores de entrada que serão
utilizados, as restrições para a sua realização, o resultado obtido e ainda o
comportamento esperado.
o Roteiro de teste: esse é o documento que descreve o procedimento, ou passo
a passo, necessário para que sejam realizados os casos de teste ou um
conjunto de casos de teste.

• Plano de Testes
o De forma geral, é importante que o documento de plano de testes contenha:
▪ O escopo dos testes
▪ Os recursos humanos e tecnológicos
▪ Abordagem utilizada (atividades, técnicas e ferramentas usadas)
▪ O tempo disponível para cada atividade de teste
▪ Os itens e funcionalidades que serão testados
▪ Os riscos envolvidos
▪ Os responsáveis pelos testes
▪ A versão testada
▪ Os motivos de testar ou não cada um dos itens e funcionalidades
▪ Os critérios de aceitação para cada item testado
▪ Os critérios de suspensão para as atividades de teste
▪ Os artefatos produzidos quando terminados os testes (relatórios,
memorandos, logs)
▪ O ambiente necessário para a realização dos testes, a data de início e
fim dos testes, bem como as aprovações dos testes (nomes e cargos
dos responsáveis pela aprovação do plano de testes, com assinatura e
data)
• Especificação de testes
o Especificação do projeto de teste: traz uma identificação de todas as
funcionalidades e as características do projeto que precisam ser testadas em
cada momento
o Especificação de casos de teste: define quais casos de teste serão realizados e,
para cada um deles, quais serão os dados de entrada, quais serão as saídas ou
resultados desejados, bem como as ações e todas as condições gerais
necessárias para a execução dos testes.
 o Especificação dos procedimentos de teste: envolve a especificação dos
procedimentos e o passo a passo para a execução de um conjunto específico
de casos de teste.
• Relatórios
o Diário de teste: apresenta apontamentos e registros dos detalhes mais
importantes que foram identificados durante a realização dos testes. Os
registros devem ser feitos de maneira cronológica, por isso o nome “diário”. O
diário é importante também pelo fato de guardar um histórico das falhas
encontradas, permitindo que, após o final do projeto de desenvolvimento do
software, sejam feitos estudos e haja um aprendizado acerca dos erros
cometidos.
o Relatório de incidentes de teste: traz uma documentação detalhada de todo e
qualquer evento que aconteça durante a realização das atividades de teste,
principalmente aqueles que vão precisar de uma avaliação posterior. Os erros
que forem encontrados durante a realização dos testes precisam ser
documentados de maneira detalhada, para que possam auxiliar os
desenvolvedores e demais integrantes da equipe na reprodução do erro, o que
serve para facilitar a solução do problema encontrado. É muito importante
que sejam registrados todos os incidentes ou eventos que aconteceram
durante as atividades de teste em um relatório único, para que sirvam de base
para quem for efetuar ajustes na codificação e no projeto como um todo.
o Relatório de resumo de testes: esse documento deve apresentar, de forma
resumida, todos os resultados obtidos com as atividades de teste. Ainda deve
indicar a qual funcionalidade ou especificação do projeto ele está vinculado,
para que se possam fazer avaliações e análises de acordo com esses
resultados.
o Relatório de encaminhamento de itens de teste: esse documento serve
especificamente para o caso em que existem equipes distintas para testar as
diferentes partes do software. Ele apresenta os itens que foram encaminhados
para teste e indica para qual equipe foram designados.
• O plano de testes segundo a norma IEEE 829
• O Project Management Institute (PMI — Instituto de Gerenciamento de Projetos)

CASOS DE TESTE

• Objetivos
o Interpretar casos de teste por meio da UML.
o Analisar casos de teste.
o Elaborar casos de teste com o uso da UML.
• Diagrama de Casos de Uso:
o Partes de um diagrama de caso de uso
▪ Cenário: é toda sequência de ações realizadas sempre que o usuário
interage de alguma forma com o sistema.
▪ Ator: é o próprio usuário do sistema e, se for o caso, pode demonstrar
também o perfil de cada usuário dentro do sistema.
 ▪ Caso de uso: é uma funcionalidade ou uma atividade realizada pelo
ator. Comunicação: é aquilo que faz a ligação entre o ator e o caso
de uso
o Exemplo:
▪ Ator Paciente:
• Agenda uma consulta;
• Consulta com o médico;
• Cancela uma consulta.
▪ Ator Atendente
• Procura disponibilidade de data e horário na agenda;
• Marca consulta para o paciente;
• Cancela consulta a pedido do paciente.
▪ Ator Médico:
• Realiza uma consulta;
• Receita medicamentos.

• Documentos Casos de Teste

o Plano de teste
▪ É o documento em que se baseia o início das atividades de teste de
software. Ele deve trazer todas as atividades de teste a serem
realizadas, o escopo dos testes, as funcionalidades ou as partes do
software que vão ser testadas e as que não serão, a justificativa para
que as funcionalidades sejam ou não testadas, as restrições para os
testes, os critérios de validação e os responsáveis por cada uma das
atividades.
o Roteiro de teste
▪ É o documento que detalha o procedimento, cada passo necessário
para que os casos de teste aconteçam.
 o Caso de teste
▪ É o documento que descreve detalhadamente o teste de uma parte
específica, indicando todas as condições necessárias para os testes de
um software. Normalmente, ele é elaborado com a intenção de
identificar falhas, defeitos e erros em uma parte de um sistema. Isso
ocorre por meio de ações e situações impostas pelo testador. A ideia é
exercitar todas as funcionalidades construídas, além de indicar se os
requisitos do software foram elaborados de maneira coerente com o
que foi pedido.

• Estrutura documento de caso de teste

o Resumo
▪ Contém uma descrição sem muitos detalhes do caso de teste como
um todo, descrevendo a finalidade do caso de teste, o objetivo da sua
realização e ainda o escopo do teste, ou seja, qual parte específica do
software deve ser testada.
o Pré-condições
▪ Consistem em uma descrição do que deve ser feito antes que o teste
se inicie, por exemplo, indicam que o usuário deve estar logado no
sistema.
o Entradas
▪ Consistem em uma lista de todas as entradas que devem ser inseridas
no sistema pelo testador ao longo da execução do caso de teste.
Indicam os objetos ou campos das telas e os valores, válidos e
inválidos, que devem ser informados.
o Ação
▪ Descreve de maneira detalhada tudo o que o testador deve realizar
dentro da funcionalidade para que o sistema tenha condições de
cumprir aquilo que foi estabelecido para cada teste.
o Resultados esperados:
▪ Indicam os estados e ações que o sistema deve realizar para que o
resultado do teste seja considerado um sucesso. Estabelecem também
cada resposta positiva e negativa que pode surgir, dependendo de
cada atitude do testador.
o Pós-condições
▪ Descrevem com detalhes para qual estado ou condição o sistema deve
retornar quando o teste for finalizado.

• Depois que os caminhos do caso de uso são identificados, é possível distinguir os

cenários desse caso de uso fazendo combinações entre os caminhos. É o que você
pode ver a seguir.
 o Cenário 1: fluxo básico.
o Cenário 2: fluxo básico + fluxo alternado 1.
o Cenário 3: fluxo básico + fluxo alternado 1 + fluxo alternado 2.
o Cenário 4: fluxo básico + fluxo alternado 3.
o Cenário 5: fluxo básico + fluxo alternado 3 + fluxo alternado 1.
o Cenário 6: fluxo básico + fluxo alternado 3 + fluxo alternado 1 + fluxo alternado 2.
o Cenário 7: fluxo básico + fluxo alternado 4.
o Cenário 8: fluxo básico + fluxo alternado 3 + fluxo alternado 4

• Cenários identificados para Clínica de odontologia que necessita de um sistema de

agendamento
o Cenário 1: fluxo básico, em que o paciente agenda uma consulta, o
atendente encontra disponibilidade, o paciente consulta com o médico e o
médico receita medicamentos a ele.
o Cenário 2: fluxo básico, incluindo a possibilidade de o paciente entrar em
contato cancelando a consulta três ou mais dias antes do horário
agendado.
o Cenário 3: fluxo básico, incluindo a possibilidade de o paciente entrar em
contato cancelando a consulta menos de três dias antes do horário
agendado.

Níveis de teste

• Objetivos
o Definir os níveis de teste e o teste de sistema.
o Diferenciar os níveis de teste de unidade e de integração.
o Descrever os níveis de teste de aceitação e de regressão.

• Níveis de Teste
o Teste de unidade;
 o Teste de integração;
o Teste de sistema;
o Teste de aceitação;
o Teste de regressão.

• Teste de Sistema
o No nível de teste de sistema, os analistas de teste, ou testadores, têm o
propósito de executar o sistema como um todo, levando em consideração
a visão do usuário final. Todas as funcionalidades do sistema são colocadas
em operação.

• Teste de Unidade
o Nesse nível de teste, são testadas as menores partes em que um software
pode ser dividido.
o O propósito principal desse tipo de teste é realizar a validação de
chamadas de métodos, classes, funções, sub-rotinas e partes de código
fonte que possam ser testadas de maneira isolada.
o Teste de Unidade utiliza os seguintes documentos
▪ Documento de especificação de requisitos do software;
▪ Documento de caso de uso;
▪ Documento de arquitetura do software (DAS).
• Teste de Integração
o O nível do teste de integração tem como diferença principal do teste de
unidade o fato de o seu propósito ser o de encontrar problemas gerados
pela integração interna entre os componentes ou partes do software. É
normal que, por meio do teste de integração, sejam encontrados
problemas de transmissão de dados
o Medidas para os testes serem bem sucedidos
▪ Preparar previamente um ambiente para que o teste aconteça;
▪ Preparar previamente um banco de dados para servir de teste;
▪ Registrar formalmente todos os resultados obtidos com os testes;
▪ Avaliar todos os resultados obtidos por meio dos testes;
▪ Relatar ao gerente de projeto toda ocorrência de problema mais
grave que possa impactar negativamente o andamento do
restante do projeto de desenvolvimento do software.

• Teste de aceitação
o Nesse nível de teste de software, normalmente os testes são realizados
por um grupo de amostra, com representantes dos usuários finais do
sistema. Por esse motivo, esse nível de teste também pode ser chamado
de teste de aceitação do usuário
• Teste de regressão
o Normalmente, no nível do teste de regressão, ainda estão sendo
desenvolvidas versões do software, ele ainda está sendo codificado. Esse é
um tipo de teste aplicado sempre que uma nova versão da aplicação fica
pronta. Ele também é aplicado quando é necessário realizar um novo ciclo
de testes em toda a aplicação para verificar se elementos novos que foram
 desenvolvidos não afetaram de maneira negativa o restante das partes
que já haviam sido codificadas.
o O objetivo é verificar se partes novas de codificação não afetaram ou
alteraram o comportamento do sistema dependendo das entradas que ele
recebe.