Manual Teste

Prévia do material em texto

Desenvolvido para apoiar você, analista de teste Atech que tem a missão, juntamente com os demais 
membros da equipe, garantir a qualidade de nossos produtos. 
 
 
 
 
 
 
 
1 
Manual do 
Analista de 
Testes 
Desenvolvido para apoiar você, 
analista de teste Atech que tem a 
missão, juntamente com os demais 
membros da equipe, garantir a 
qualidade de nossos produtos. 
 
Você encontrará: 
 
 Objetivo 
 
 Motivações 
 Processo de teste 
 
 Testlink 
 
 Boas práticas 
 
Estamos abertos a receber sua contribuição para que 
possamos construir juntos a Célula de teste que 
queremos: ágil, conectada, proativa e comprometida. 
Boa leitura! 
Suporte ao Negócio 
Introdução 
 
 
 
 
 
 
 
 
 
 
M
an
ua
l d
o 
An
al
is
ta
 d
e 
Te
st
es
 
2 
REGISTRO DE REVISÕES 
REVISÃO DATA RESPONSÁVEIS SEÇÕES ATINGIDAS / DESCRIÇÃO 
A 01/04/17 elaborado 
Cássia Regina Talarico Grigoleto 
Ana Tereza Zabini 
verificado 
Aline Ferreira Mendonça 
liberado para emissão 
Fábio Cochi 
Emissão Inicial. 
B 04/12/2018 elaborado 
Aline Ferreira Mendonça 
verificado 
Marcelo Rodrigues 
liberado para emissão 
Aline Ferreira Mendonça 
Alteração dos itens: 
 4 – Definições; e 
 10 – Boas práticas. 
 
Inclusão do item: 
11 - Certificações 
 
 
 
 
Aprovação Assinatura Data 
 
 
Testes 
 
 
 
 
 
 
 
 
 
 
3 
 
Introdução ................................................................. 1 
Sumário ...................................................................... 3 
1. .......................................... Objetivo do documento
 ................................................................................... 5 
2. ........................................... Documentos aplicáveis
 ................................................................................... 5 
3. ............................................................... Motivação
 ................................................................................... 5 
4. ............................................................... Definições
 ................................................................................... 5 
5. ................................. Processo de Teste e modelo v
 ................................................................................. 10 
Modelo V e Eventos de Teste 11 
Modelo V e Documentos de Teste 14 
Modelo V e Pontos de Revisão de Teste 17 
6. ................... Processo de Desenvolvimento e Testes
 ................................................................................. 18 
Processo de Codificação 18 
Processo de Integração de Software 19 
Processo de Integração de Sistemas 19 
Processo de Qualificação do Sistema 20 
Processo de Validação do Sistema 21 
7. ................. Fases e Atividades do Processo de Teste
 ................................................................................. 23 
Preparação de Teste 24 
Planejamento de Teste 24 
Projeto de Teste (Análise e Modelagem) 24 
Implementação e Execução de Teste 25 
8. ........................................................ Níveis de teste
 ................................................................................. 26 
Modelos Iterativos de Desenvolvimento 26 
9. .................................................... Técnicas de Teste
 ................................................................................. 27 
Técnicas Estáticas 27 
Processo de Revisão 27 
Análise Estática por Ferramenta 27 
Técnica de Modelagem de Teste 28 
Sumário 
 
 
 
 
 
 
 
 
M
an
ua
l d
o 
An
al
is
ta
 d
e 
Te
st
es
 
4 
Técnicas Baseadas em Especificação ou Caixa-Preta 30 
Técnicas Baseadas em Estrutura ou Caixa-Branca 31 
Técnicas Baseadas em Experiência 32 
10. Boas práticas ................................................................................... 34 
Suíte de teste 34 
Casos de teste 34 
Execução de caso de teste 35 
11. Certificações ................................................................................... 36 
 
 
 
 
 
 
 
 
5 
 
 
. Objetivo do documento 
 
 
 
 
 
 
 
 
. Documentos aplicáveis 
[ES-H] ATECH.21.04.00094 
SE Handbook (System Engineering 
Handbook) 
[SPR] ATECH.21.04.00025 
SPR (Registro de problemas no 
fornecimento) 
[ISO/IEC] ISO/IEC-12207 
Systems and Software Engineering-
Software Life Cycle Processes 
[TESTLINK] ATECH.21.04.10019 Manual do Testlink 
[MANUAL USABILIDADE] ATECH.21.04.10007 Manual de padrões de usabilidade 
 
. Motivação 
No processo de desenvolvimento de software, todos os defeitos são humanos e, apesar do uso 
dos melhores métodos de desenvolvimento, ferramentas ou profissionais, permanecem 
presentes nos produtos, o que torna a atividade de teste fundamental durante o 
desenvolvimento de um software. 
 
. Definições 
Análise estática ou análise estática de código 
Método de depuração de programas de computador feito por meio de análise do código sem 
que o programa seja executado. O objetivo da análise estática é encontrar defeitos no código 
Este documento tem por objetivo descrever conceitos, boas práticas relacionadas às 
atividades de verificação e validação de sistemas e softwares e como essas atividades 
estão distribuídas nos estágios do ciclo de vida de projetos descritos no documento 
ATECH.21.04.00094-SE Handbook, além de disponibilizar o tutorial da ferramenta 
utilizada para registro das execuções de validação e verificação. O processo de registro de 
defeito e ou falhas durante a execução de testes ou validação de artefatos estão descritos 
no documento ATECH.21.04.00025-SPR (Registro de problemas no fornecimento). 
 
 
 
 
 
 
 
M
an
ua
l d
o 
An
al
is
ta
 d
e 
Te
st
es
 
6 
fonte do software e na modelagem. Análise estática pode localizar defeitos que não são ou 
raramente seriam encontrados em testes. Como as revisões, a análise estática encontra 
defeitos e não falhas (veja adiante definição de defeitos e falhas). Ferramentas de análise 
estática analisam o código do programa conforme padrões e regras estabelecidos ([JAVA] 
ATECH.21.04.01001 – Padrão de Desenvolvimento Java/ [LING C] ATECH.21.04.01002 – Padrão 
de Desenvolvimento Linguagem C). 
Cobertura de Teste 
Cobertura é a extensão que uma estrutura foi exercitada por um conjunto de testes, expresso 
como uma porcentagem de itens cobertos. Se a cobertura não atinge 100%, então mais testes 
devem ser construídos, a fim de testar aqueles itens que não foram contemplados com o 
propósito de aumentar a cobertura. 
Compiladores 
Programa de computador (ou um grupo de programas) que, a partir de um código fonte escrito 
em uma linguagem de programação, cria um programa semanticamente equivalente, porém 
escrito em outra linguagem, código objeto (nome dado ao código resultante da compilação do 
código fonte). Tipicamente um compilador traduz um programa de uma linguagem textual 
facilmente entendida por um ser humano para uma linguagem de máquina, específica para um 
processador e sistema operacional. 
Defeito ou Bug 
É tudo o que é introduzido por um indivíduo durante o processo de desenvolvimento ou 
fabricação ao tentar gerar uma determinada informação ou produto, resolver um problema ou 
utilizar um método ou uma ferramenta. Por exemplo, uma instrução ou comando incorreto. 
Erro 
É uma manifestação concreta de um defeito num artefato demonstrando que não atende o 
requisito ou critérios de validação e verificação. Por exemplo, diferença entre o valor obtido e 
o valor esperado, ou seja, qualquer estado intermediário incorreto ou resultado inesperado na 
execução de um programa constitui um erro. 
Falha 
É o comportamento operacional do software ou hardware diferente do esperado pelo usuário. 
Uma falha pode ter sido causada por diversos erros e alguns erros podem nunca causar uma 
única falha. 
“Manutenibilidade”É uma característica inerente a um projeto de sistema ou produto, e se refere à facilidade com 
que o software pode ser entendido, corrigido, adaptado e ou aumentado, refere-se ainda à 
precisão, segurança e economia na execução de ações de manutenção nesse sistema ou 
produto. 
“Testabilidade” 
Grau em que o software cumpre ou deve cumprir um conjunto e / ou características (por 
exemplo: a complexidade do software, avaliação de risco, o nível de segurança, desempenho, 
confiabilidade ou custo) que são definidos para refletir a importância do software para seus 
stakeholders. 
 
 
 
 
 
7 
Testes 
Passo no processo de engenharia de software que tem como objetivo encontrar defeitos por 
meio da ocorrência de erros, pode ser traduzida como uma atividade que procura desconstruir 
o software com o objetivo de provocar falhas. 
Testes de Caixa Cinza 
Técnica de teste que utiliza ambas as técnicas, caixa preta e caixa branca. Envolve ter acesso à 
estrutura de dados, funcionalidades e algoritmos do componente, com objetivo de desenvolver 
casos de teste. 
Teste de Caixa Preta ou Teste Funcional 
Teste baseado nos requisitos funcionais do software. A técnica não leva em consideração o 
comportamento interno do sistema durante a execução do teste, mas com a saída esperada 
após a entrada dos dados, avalia o comportamento externo do componente de software, avalia 
as funções que um sistema, subsistema ou componente devem realizar e que podem ser 
descritas nos seguintes artefatos: 
 Especificação de requisitos; 
 Histórias de usuário; 
 Especificação funcional; 
 Casos de uso; 
 Podem não estar documentados. 
Testes funcionais são baseados em funções (representam “o que” o sistema faz) e mesmo não 
documentadas devem ser compreendidas pelos analistas de teste. Devem ser realizados em 
todos os níveis de teste (ex.: teste de componente) e pode ser aplicada em todas as etapas de 
teste (unidade, integração, sistema e aceitação). 
Por questões de tempo e recurso, uma dificuldade dessa técnica, é testar todas as entradas 
possíveis. Ele se apresenta como necessária durante o desenvolvimento de um sistema, 
contudo, por sua natureza, mostra-se insuficiente para identificar certos riscos num projeto de 
software. 
Teste de Carga 
O teste de carga é uma técnica usada para avaliar os limites operacionais do software. 
Geralmente, as medições são tomadas com base na taxa de transferência de dados, da carga 
de trabalho/dados e no tempo de resposta da transação. As variações na carga de trabalho 
normalmente incluem a emulação das cargas de trabalho médias e máximas que ocorrem 
dentro de tolerâncias operacionais normais. A aplicação dessa técnica é indicada durante as 
etapas de testes de integração e de sistema. 
Teste estrutural/arquitetura ou Testes de caixa branca 
Tipo de teste com o objetivo de cobrir as funcionalidades do componente de software e suas 
integrações. Pode ser aplicado em todos os níveis e apoiados por ferramentas que meçam a 
cobertura do código, bem como declarações ou decisões. O teste estrutural é baseado na 
arquitetura do sistema. 
Recomenda-se utilizar as técnicas estruturais após as técnicas funcionais, já que ela auxilia a 
medição da eficiência do teste por meio da avaliação da cobertura de um tipo de estrutura. 
 
 
 
 
 
 
M
an
ua
l d
o 
An
al
is
ta
 d
e 
Te
st
es
 
8 
 
Testes não funcionais 
Teste de características do produto de software, é o teste de “como o sistema trabalha”. 
Testes não funcionais podem ser realizados em todos os níveis de teste. O termo teste não 
funcional descreve que ele é executado para medir as características que podem ser 
quantificadas em uma escala variável, como o tempo de resposta em um teste de performance. 
Estes testes podem ser referenciados a um modelo de qualidade, como definido na norma ISSO 
9126 - Engenharia de Software – Qualidade de Produto de Software. 
Testes não funcionais incluem, mas não se limitam aos tipos descritos na lista abaixo: 
 Teste de performance – carga; 
 Teste de performance – tempo de resposta; 
 Teste de performance – stress; 
 Teste de performance – disponibilidade; 
 Teste de performance – robustez (endurance); 
 Teste de usabilidade; 
 Teste de interoperabilidade; 
 Teste de confiabilidade; 
 Teste de portabilidade. 
Tipos ou técnicas de teste 
Técnicas de teste são as maneiras utilizadas para testar um software e são classificadas de 
acordo com a origem das informações utilizadas para estabelecer os requisitos de teste. Elas 
contemplam diferentes perspectivas do software e impõe-se a necessidade de se estabelecer 
uma estratégia de teste que contemple as vantagens e os aspectos complementares dessas 
técnicas. As técnicas existentes são: técnica funcional e estrutural/arquitetura. 
Teste de Estresse 
O teste de estresse é destinado a avaliar como o sistema responde em condições anormais. 
Basicamente, é um teste de carga abrangendo cargas de trabalho extremas, memória 
insuficiente, hardware e serviços indisponíveis ou recursos compartilhados limitados. 
Normalmente, esses testes são executados para compreender melhor como e em quais áreas 
o sistema será dividido, para que os planos de contingência e a manutenção de atualização 
possam ser planejados com bastante antecedência. A utilização dessa técnica é imprescindível 
para projetos que desenvolvam sistemas críticos, que necessitem de alta eficiência e 
disponibilidade. A aplicação dessa técnica é indicada durante a etapa de teste de sistema. 
Teste de Regressão 
Teste de regressão é a repetição de testes de um software ou sistema após sua modificação 
(nova versão do software), quer seja decorrente de remoção de um ou mais defeitos detectados 
ou de uma alteração decorrente de evolução do software. Tem o objetivo de descobrir a 
existência de algum defeito introduzido ou não coberto originalmente após a modificação. A 
quantidade de testes de regressão é baseada no risco de inserção de defeitos durante as 
alterações. 
 
 
 
 
9 
Testes de regressão podem ser realizados em todos os níveis de teste, e se aplicam aos testes 
funcionais, não funcionais e estruturais, normalmente consomem muito tempo, por essa razão 
são fortes candidatos à automação. 
Observação: Depurar (resolver defeitos) é uma atividade do desenvolvimento, e não uma 
atividade do teste. 
Teste de Segurança 
Essa técnica de teste deve validar os requisitos de segurança, visando identificar 
vulnerabilidades do sistema. Os objetivos desses testes são: prevenir ataques, detectar 
vulnerabilidades e preparar medidas de contingência para casos de falhas. A aplicação dessa 
técnica é indicada durante as etapas de testes de integração e de sistema. 
Teste de Usabilidade 
O teste de usabilidade é uma técnica que visa avaliar o sistema do ponto de vista do usuário 
final. Nesse teste vários fatores são levados em consideração, dentre eles: os fatores humanos, 
a estética, os manuais, a facilidade de uso, etc. Esses testes permitem identificar problemas de 
usabilidade e observar o comportamento dos usuários durante a utilização do sistema, por isso 
são testes realizados na etapa de testes de aceitação, vide Manual de Usabilidade. 
Validação 
Processo executado com o objetivo de confirmar que o produto de software atende os 
requisitos definidos para aquela finalidade (ISO/IEC 12207). 
Verificação 
Processo executado com o objetivo de confirmar que cada produto de software e/ou serviço 
de um processo ou projeto refletem os requisitos especificados (ISO/IEC 12207). 
A Figura 4-1 ilustra a diferença entre os conceitos defeito x erro x falha. 
 
 
 
 
 
 
 
M
an
ua
l d
o 
An
al
is
ta
 d
e 
Te
st
es
 
10 
FIGURA 4-1 CONCEITOS DEFEITO X ERRO X FALHA 
 
 
. Processo de Teste e modelo v 
O processo de teste tem o objetivo de planejar, preparar, escrever e executar os testes com 
base dos artefatos de desenvolvimento para atender a verificação e validação dos requisitos doprojeto. 
O processo de teste é demonstrado no Modelo V apresentando a associação entre: 
 Os tipos de testes (caixa branca, cinza e preta). 
 As fases de teste (Preparação e Planejamento de Teste, Projeto de Teste e Execução 
de Teste). 
 Os entregáveis de desenvolvimento. 
A Figura 5-1 abaixo apresenta o Processo de Teste e o Modelo V. 
 
 
 
 
 
11 
FIGURA 5-1 PROCESSO DE TESTE E O MODELO V
 
 
 
 
Modelo V e Eventos de Teste 
No Processo de Teste, os Eventos de Teste acontecem seguindo o Modelo V conforme 
apresenta a Figura 5-2 e a Tabela 5-1 abaixo. 
 
Exemplos de eventos de Teste: 
 IQT - Teste de Qualificação Interna 
 FQT - Formal Qualification Test 
 SQE Dry Run (SQE=Systems Quality Engineering) - Pré-testes Área da Qualidade, 
 HIAT - Qualificação Final de Hardware 
 FAT - Factory Acceptance Test 
 SAT - Site Acceptance Test 
 
 
 
 
 
 
 
M
an
ua
l d
o 
An
al
is
ta
 d
e 
Te
st
es
 
12 
FIGURA 5-2 EVENTOS DE TESTE E O MODELO V
 
 
TABELA 5-1 EVENTOS DE TESTE 
Evento Teste Classificação de teste Artefatos 
Teste de 
Qualificação 
Interna 
(IQT) 
 
Testes 
internos 
- Testes Unitários 
- Revisão de Código 
-Teste de desenvolvedores 
 
- Caderno de teste. 
- Relatório de métrica. 
- Registro de SPRs na ferramenta 
JIRA. 
 
Teste Formal 
de Qualificação 
(FQT) 
 
Testes 
formais 
 
- Testes Funcionais (testes 
de funcionalidades. 
Ex.casos de uso) 
 
-Resultado dos Pré-testes do 
Sistema (STPR-FQT). 
-Certificação de Conformidade. 
-Revisão de Preparação para os 
Testes (TRR-FQT). 
-Procedimento de Teste do Sistema 
(STD-FQT). 
-Relatório de Resultado dos Testes 
(STR-FQT). 
-Registro de SPRs na ferramenta 
JIRA. 
 
 
 
 
 
13 
Evento Teste Classificação de teste Artefatos 
Teste de 
Qualificação 
Final de 
Hardware 
(HIAT) 
Testes 
formais 
 
- Testes de Instalação, 
Performance 
(disponibilidade,endurance, 
etc) 
Procedimento de Teste de 
Qualificação de Hardware (STD-
HIAT). 
-Relatório de Resultado dos Testes 
de Qualificação de Hardware (STR-
HIAT). 
 
Pré-Testes da 
Qualidade 
(SQE Dry-Run) 
Testes 
formais 
 
- Pré-Testes Funcionais 
Integrados 
- Pré-Testes Funcionais – 
Cenários Operacionais 
-Procedimento de Teste do Sistema 
-Relatório de Resultado dos Pré-
testes 
-Registro de SPRs na ferramenta 
JIRA. 
 
Teste de 
Aceitação em 
Fábrica 
Testes 
formais 
 
- Testes Funcionais 
Integrados 
-Resultado dos Pré-testes do 
Sistema 
-Certificação de Conformidade. 
-Revisão de Preparação para os 
Testes 
-Procedimento de Teste do Sistema 
-Relatório de Resultado dos Testes 
-Registro de SPRs na ferramenta 
JIRA. 
 
Teste de 
Aceitação em 
Campo (SAT) 
Testes 
formais 
 
- Testes Funcionais – 
Cenários Operacionais 
-Resultado dos Pré-testes do 
Sistema 
-Certificação de Conformidade. 
-Revisão de Preparação para os 
Testes 
-Procedimento de Teste do Sistema 
-Relatório de Resultado dos Testes 
-Registro de SPRs na ferramenta 
JIRA. 
 
 
 
 
 
 
 
 
 
M
an
ua
l d
o 
An
al
is
ta
 d
e 
Te
st
es
 
14 
Modelo V e Documentos de Teste 
 
No Processo de Teste, os Documentos de Teste previstos para antes, durante e depois de cada 
Evento de Teste, de acordo com o Modelo V são ilustrados na Figura 5-3 e Tabela 5-2 abaixo. 
Documentos: 
- Antes do Evento: Planos de Teste, Estimativas de Teste, Procedimentos de Teste. 
- Durante o Evento: Ata de Abertura e Fechamento do Evento. 
- Depois do Evento: Registro de Problemas e Relatório de Resultados. 
 
FIGURA 5-3 DOCUMENTOS DE TESTE E O MODELO V 
 
 
 
TABELA 5-2 EVENTOS E DOCUMENTOS DE TESTES 
Evento 
Documentos Antes do 
Evento 
Documentos Durante o 
Evento (imediatamente 
antes e após o evento) 
Documentos Depois do 
Evento 
Teste de 
Qualificação 
Interna 
(IQT) 
Plano de Teste Interno 
Caderno de Teste. 
 
Ata de Abertura do 
Evento IQT 
Ata do Fechamento do 
Evento IQT 
Relatório de Resultado 
de Teste 
Relatório de métrica. 
 
 
 
 
15 
Evento 
Documentos Antes do 
Evento 
Documentos Durante o 
Evento (imediatamente 
antes e após o evento) 
Documentos Depois do 
Evento 
 Registro de SPRs na 
ferramenta JIRA. 
 
Teste Formal 
de 
Qualificação 
 
Resultado dos Pré-testes 
do Sistema 
Certificação de 
Conformidade. 
Revisão de Preparação 
para os Testes. 
Procedimento de Teste 
do Sistema. 
 
Ata de Abertura do 
Evento 
Ata do Fechamento do 
Evento 
Relatório de Resultado 
dos Testes. 
Registro de SPRs na 
ferramenta JIRA. 
 
Teste de 
Qualificação 
Final de 
Hardware 
Procedimento de Teste 
de Qualificação de 
Hardware. 
 
Ata do Abertura do 
Evento. 
Ata do Fechamento do 
Evento 
Relatório de Resultado 
dos Testes de 
Qualificação de 
Hardware. 
 
Pré-Testes 
da Qualidade 
(SQE Dry-
Run) 
Procedimento de Teste 
do Sistema (STD-FAT , 
STD-SAT). 
 
Ata de Abertura do 
Evento do Dry-Run-FAT 
ou Dry-Run-SAT. 
Ata do Fechamento do 
Evento do Dry-Run-FAT 
ou Dry-Run-SAT 
Relatório de Resultado 
dos Pré-testes (STPR-
FAT, STPR-SAT). 
Registro de SPRs na 
ferramenta JIRA. 
 
Teste de 
Aceitação 
em Fábrica 
(FAT) 
Resultado dos Pré-testes 
do Sistema (STPR-FAT). 
Certificação de 
Conformidade. 
Revisão de Preparação 
para os Testes (TRR-
FAT). 
Procedimento de Teste 
do Sistema (STD-FAT). 
 
Ata de Abertura do 
Evento FAT. 
Ata do Fechamento do 
Evento FAT 
Relatório de Resultado 
dos Testes (STR-FAT). 
Registro de SPRs na 
ferramenta JIRA. 
 
Teste de 
Aceitação 
Resultado dos Pré-testes 
do Sistema (STPR-SAT). 
Ata de Abertura do 
Evento SAT 
Relatório de Resultado 
dos Testes (STR-SAT). 
 
 
 
 
 
 
M
an
ua
l d
o 
An
al
is
ta
 d
e 
Te
st
es
 
16 
Evento 
Documentos Antes do 
Evento 
Documentos Durante o 
Evento (imediatamente 
antes e após o evento) 
Documentos Depois do 
Evento 
em Campo 
(SAT) 
Certificação de 
Conformidade. 
Revisão de Preparação 
para os Testes (TRR-
SAT). 
Procedimento de Teste 
do Sistema (STD-SAT). 
 
Ata do Fechamento do 
Evento SAT 
Registro de SPRs na 
ferramenta JIRA. 
 
 
 
 
 
 
 
17 
Modelo V e Pontos de Revisão de Teste 
No Processo de Teste, os Pontos de Revisão de Teste previstos para cada Evento de Teste, de 
acordo com o Modelo V são ilustrados na Figura 5-4 abaixo. 
Tipos de Revisão: 
 Revisão Par 
 Revisão Impar 
 Test Readiness Review - TRR 
 
FIGURA 5-4 PONTOS DE REVISÃO DE TESTE E O MODELO V 
 
 
 
 
 
 
 
 
 
 
M
an
ua
l d
o 
An
al
is
ta
 d
e 
Te
st
es
 
18 
. Processo de Desenvolvimento e Testes 
 
Os itens abaixo indicam as características para um bom teste para qualquer modelo de ciclo de 
vida: 
 Para todas as atividades do desenvolvimento há uma atividade de teste 
correspondente; 
 Cada nível de teste tem um objetivo específico daquele nível; 
 A análise e modelagem do teste para um dado nível de teste devem começar durante 
a atividade de desenvolvimento correspondente; 
 Analistas de testes devem se envolver na revisão de documentos o mais cedo possível, 
utilizando as primeiras versões disponíveis ao longo do ciclo de desenvolvimento. 
 O documento de procedimento de teste deve ser conhecido por todos envolvidos nas 
atividades de teste. 
Processo de Codificação 
O processo de Codificação consiste no desenvolvimento e teste dos componentes de software 
(CSCI). O processo de codificação ocorre de forma iterativa obedecendo à definição do projeto. 
O processo iterativo é executado em diferentes fases que possuem os seguintes níveis de teste: 
 Inspeção do software COTS 
 Inspeção dos componentes de software. 
 Teste independente do componente de software (CSCI). 
Os níveis de teste dos componentes de software devem verificar os requisitos de software e 
sua cobertura deve ser verificada por meio da execução dos testes unitários. Os testes unitários 
devem verificar a implementação do requisito, a cobertura dos testes e a utilização dos padrões 
definidosno código. 
A estratégia dos testes unitários no processo de codificação, e consequentemente no 
desenvolvimento do software, deve ser descrita no documento Plano de Desenvolvimento do 
Sistema (SDP). 
A Tabela 6-1 contém as entradas e saídas do Processo de Codificação: 
Tabela 6-1: Processo de Codificação 
Processo Entradas (Input) Atividades Saídas (Output) 
Codificação/ 
Desenvolvimento 
de Software 
Especificação de 
Software 
Projeto de Software 
Padrões de 
codificação 
COTS 
Hardware 
Codificação de Software Código 
Elaboração e execução 
dos Testes Unitários 
Plano de Teste do 
Sistema (STP). 
Relatórios de Testes - 
Métricas e Resultados 
de Execução (STR) 
 
 
 
 
 
19 
Processo de Integração de Software 
O processo de Integração de Software consiste na integração entre os componentes de 
software (CISI) desenvolvidos nas etapas anteriores com componentes existentes e/ou 
externos. 
Esta etapa do projeto possui múltiplas iterações de integração de software onde cada uma 
agrupa mais componentes até obter-se o conjunto completo de componentes de software do 
sistema. Este processo pode ocorrer de forma transparente durante a codificação 
disponibilizando através do build contínuo os componentes de software. 
O processo de integração de software deve ser verificado no nível de teste integrado de 
componentes de software. Este nível de teste tem o objetivo de atender a verificação dos 
requisitos de interface interna de software com a cobertura verificada na execução dos testes 
unitários. Similar ao processo de codificação, os testes unitários além de verificar componentes 
individuais exercitam a sua integração. 
A Tabela 6-2 contém as entradas e saídas do Processo de Integração de Software: 
Tabela 6-2: Processo de Integração de Software 
Processo Entradas (Input) Atividades Saídas (Output) 
Integração 
de 
Software 
Source Code 
existentes, externos 
e/ou desenvolvidos. 
COTS 
Hardware 
Integração dos 
componentes de software 
(novos, existentes e 
externos). 
Builds (código integrado) 
Elaboração e execução dos 
Testes Unitários 
Plano de Teste do Sistema (STP). 
Relatórios de Testes - Métricas 
e Resultados de Execução (STR). 
 
Processo de Integração de Sistemas 
O processo de Integração de Sistemas busca a integração final do sistema, englobando o 
hardware e software. Este processo, normalmente progressivo, é uma característica dos 
sistemas complexos onde a validação da integração, hardware e software, não é trivial ou 
imediata. 
Tipicamente nesses sistemas deve-se buscar obter evoluções incrementais dos testes de 
integração com a adição consecutiva de hardware in-the-loop, de forma que a integração final 
não seja na forma de sprint final (“bang”). Com esta abordagem, a execução dos testes que 
dependem de um hardware específico é reduzida à medida que se aproxima o final deste 
processo de integração. Modelos (ou simuladores) de hardware são utilizados permitindo os 
testes de compatibilidade. 
Cada componente de software (CSCI) é integrado com os componentes de hardware (HWCIs) e 
com outros componentes externos de software (CSCIs) como, por exemplo, dispositivos ou 
sistemas externos. O sistema resultado desse processo de integração será preliminarmente 
testado contra os requisitos definidos nos Requisitos de Sistema (SSS) usando os casos de teste 
descritos no Procedimento de Teste do Sistema (STD). 
Os testes do sistema totalmente integrado envolvem as seguintes atividades: 
 Elaboração dos testes atendendo a cenários operacionais do sistema; 
 Geração do Caderno de Procedimentos de Teste (STD); 
 Organização do ambiente e plataforma de integração; 
 
 
 
 
 
 
M
an
ua
l d
o 
An
al
is
ta
 d
e 
Te
st
es
 
20 
 Geração de massa de dados para atender aos testes e seus cenários; 
 Geração da versão do software integrado para os testes; 
 Execução dos testes usando os procedimentos pré-definidos; 
 Geração e emissão de relatórios dos testes, controle de execuçãocorreção dos 
problemas levantados. 
A entrega dos arquivos de código (fontes) e dos executáveis deve ser feita por meio da 
Especificação do Produto de Software (SPS – Software Product Specification), como um 
produto. A SPS detalha os entregáveis: software executável, arquivos-fontes, e outras 
informações pertinentes necessárias para que a organização de suporte possa manter o 
software. 
A SPS deve indicar em que mídia os arquivos fontes devem ser entregues. Listagens de código 
fonte (impressões de papel) não são necessárias, a menos que especificado pelo cliente. A 
identificação do software deve ser parte do documento SVD. 
A Tabela 6-3 contém as entradas e saídas do Processo de Projeto de Sistema: 
Tabela 6-3: Processo de Projeto de Sistema 
Processo Entradas (Input) Atividades Saídas (Output) 
Integração de 
Sistemas 
Versões de Software 
Protótipos/Modelos 
de Hardware 
Integração de 
Hardware e Software 
Código executável (builds) 
Testes de qualificação 
de engenharia 
Plano de Teste do Sistema (STP). 
Procedimento de Teste do 
Sistema (STD). 
Resultados dos Testes (Métricas 
e Resultados de Execução). (STR) 
Rastreabilidade entre testes, CSCI 
e requisitos. 
 
Processo de Qualificação do Sistema 
O processo de qualificação consiste em verificar que os requisitos de software especificados 
para o projeto são atendidos completamente pelo sistema. Este processo de verificação ocorre 
em todas as etapas do seu desenvolvimento desde a especificação até a validação final. 
Os casos de testes são usados para verificar os requisitos de sistema por meio do resultado 
esperado consequentemente atendendo a expectativa de cobertura de requisitos de software 
e sistema e operação do sistema. 
Os pré-testes, também chamados de dry-run de engenharia, são realizadas com a intenção de 
validar o documento de descrição de teste de sistema e eliminar os defeitos de software 
restantes. Um conjunto de providências deverá ser tomado para incorporar as correções ao 
documento de descrição de teste e todas as ações corretivas ao sistema. Essas correções serão 
apresentadas em uma TRR interna (ITRR – Internal Test Readiness Review). 
As dry-runs de SQE (Systems Quality Engineering) são realizados após a execução dos pré-
testes, com a intenção de validar o STD e obter a qualificação interna do sistema. Providências 
devem ser tomadas para incorporar as correções ao STD (System Test Description) e todas as 
ações corretivas ao sistema. O cliente pode acompanhar os testes de dry-runs de SQE. 
A Tabela 6-4 contém as entradas e saídas do Processo de Verificação do Sistema: 
 
 
 
 
21 
 
 
 
Tabela 6-4: Processo de Verificação do Sistema 
Processo Entradas (Input) Atividades Saídas (Output) 
Qualificação 
de Sistema 
Versões de 
Software interno 
Hardware de teste 
Formal Qualification 
Test (FQT). 
Preparação para Factory 
Acceptance Test 
(FAT) – Testes de 
Aceitação em Fábrica 
Pré-testes do FAT. 
Dry-run do FAT. 
Internal Test Readiness 
Review (ITRR) 
Plano de Teste do Sistema 
(STP). 
Procedimento de Teste do 
Sistema (STD). 
Resultados dos Testes 
(Métricas e Resultados de 
Execução). (STR) 
Rastreabilidade entre testes, 
CSCI e requisitos. 
 
Processo de Validação do Sistema 
O processo de Validação do Sistema tem o propósito de prover evidências objetivas de que o 
sistema está de acordo com os requisitos e atinge o uso pretendido no ambiente operacional. 
O processo de validação do sistema e consequentemente a transição do sistema para o cliente 
depende dos resultados da "Qualificação do Sistema" e da "Preparação do Software para Uso". 
Este processo é constituído de uma implantação integrada de hardware e software, da 
qualificação do sistema on site por meio dos testes de aceitação do cliente, do treinamento dos 
usuários do sistema e da operação assistida. No final dessa fase, o cliente deve ser capaz de 
utilizar e manter o sistema. 
 O processo é ilustrado na Figura 6-1 apresentada a seguir:FIGURA 6-1 PROCESSO DE VALIDAÇÃO DO SISTEMA 
 
 
 
 
 
 
M
an
ua
l d
o 
An
al
is
ta
 d
e 
Te
st
es
 
22 
A validação do sistema é preparada a partir dos resultados das dry-runs SQE realizados on site, 
constituídos por casos de teste de validação formal contra os requisitos definidos no SSS 
descritos no STD (System Test Description). 
As atividades da preparação e realização dos testes formais de aceitação são executadas em 
duas etapas: a realização do Factory Acceptance Test (FAT) e do Site Acceptance Test (SAT). 
O escopo e objetivo do FAT e SAT são descritas em detalhe no STP (System Test Plan) e STD 
(System Test Description) e envolvem: 
 Relatórios, controle e correção de relatórios de problemas levantados durante o teste 
(SPR); 
 Realização e aprovação dos testes de aceitação; 
 Relatórios de execução dos testes com apresentação das métricas da execução (SPR); 
 Endereçamento ação / questões resultantes dos testes de aceitação. Realização da 
reunião de Test Readiness Review (TRR). 
 
A Tabela 6-5 contém as entradas e saídas do Processo de Validação do Sistema: 
Tabela 6-5: Processo de Validação do Sistema 
Processo Entradas (Input) Atividades Saídas (Output) 
Validação do 
Sistema 
Versões de 
Software 
Hardware 
Execução de Teste FAT - Teste 
de aceitação em Fábrica. 
Internal Test Readiness Review 
(TRR). 
Plano de Teste do Sistema (STP). 
Procedimento de Teste do 
Sistema (STD). 
Resultados dos Testes (Métricas e 
Resultados de Execução). (STR) 
Rastreabilidade entre testes, CSCI 
e requisitos. 
Execução de Teste SAT – Testes 
de Aceitação no Sítio. 
Internal Test Readiness Review 
(TRR). 
Plano de Teste do Sistema (STP). 
Procedimento de Teste do 
Sistema (STD). 
Resultados dos Testes (Métricas e 
Resultados de Execução). (STR) 
Rastreabilidade entre testes, CSCI 
e requisitos. 
Qualificação Final de Hardware 
- HIAT. 
Procedimentos de Teste HIAT. 
Resultados de Teste HIAT. 
 
 
 
 
 
 
23 
. Fases e Atividades do Processo de Teste 
Para cada etapa de teste correspondente ao ciclo de desenvolvimento (Modelo V) pode estar 
associada, quando aplicável, as fases/atividades do processo de testes. 
De forma geral podemos identificar as seguintes fases no Processo de Teste: 
 Preparação de Teste 
 Planejamento de Teste 
 Projeto de Teste 
 Execução de Teste 
Para cada fase é prevista uma lista de atividades ilustradas na Figura 7-1 abaixo. 
 
FIGURA 7-1 FASES E ATIVIDADES DO PROCESSO DE TESTE
 
 
Obs.: Acompanhamento, revisões técnicas e inspeções podem ser executados dentro de um 
grupo de pessoas no mesmo nível organizacional. Este tipo de revisão é chamado de “revisão 
por pares”, ou por pessoas que não atuam nas mesmas atividades porém utilizam os artefatos 
gerados para realização de outra etapa do processo, este tipo de revisão é chamado de “revisão 
por ímpares”, ex.: analistas de testes revisando artefatos de análise de software tais como 
documentos de SRS ou casos de uso. 
 
Quando 
aplicável 
 
 
 
 
 
 
M
an
ua
l d
o 
An
al
is
ta
 d
e 
Te
st
es
 
24 
As atividades do processo de teste envolvem alguns elementos essenciais que auxiliam na 
formalização desta atividade. Esses elementos são os seguintes: 
• Caso de Teste: descreve uma condição particular a ser testada e é composto por valores de 
entrada, restrições para a sua execução e um resultado ou comportamento esperado (CRAIG e 
JASKIEL, 2002). 
• Procedimento de Teste: é uma descrição dos passos necessários para executar um caso (ou 
um grupo de casos) de teste (CRAIG e JASKIEL, 2002). 
• Critério de Teste: serve para selecionar e avaliar casos de teste de forma a aumentar as 
possibilidades de provocar falhas ou, quando isso não ocorre, estabelecer um nível elevado de 
confiança na correção do produto (ROCHA et al., 2001). Os critérios de teste podem ser 
utilizados como: 
• Critério de Cobertura dos Testes: permite a identificação de partes do programa que devem 
ser executadas para garantir a qualidade do software e indicar quando o mesmo foi 
suficientemente testado (RAPPS e WEYUKER, 1982). Ou seja, determinar o percentual de 
elementos necessários por um critério de teste que foram executados pelo conjunto de casos 
de teste. Não existe teste isolado, pois a atividade de teste está intimamente relacionada com 
as atividades de desenvolvimento do software. Modelos de ciclo de vida de desenvolvimento 
diferentes necessitam de abordagens diferentes para testar. 
Preparação de Teste 
A fase de preparação de testes consiste basicamente na revisão dos artefatos correspondentes 
ao momento do ciclo de desenvolvimento. Por exemplo: no momento do Teste Unitário, 
revisão dos padrões de desenvolvimento; no momento do Teste de Projeto, revisão do Projeto 
de IHM, etc. 
Planejamento de Teste 
O planejamento de teste é a atividade que consiste em definir os objetivos e especificar as 
atividades de forma a alcançá-los. Envolve revisão de estimativas, elaboração do plano e 
cenários de teste e a modelagem do teste de projeto. 
O controle do teste é a constante atividade que consiste em comparar o progresso atual contra 
o que foi planejado, reportando o status e os desvios do plano. Ele envolve ainda a tomada de 
ações necessárias para alcançar a missão e objetivos do projeto. Para um controle efetivo, o 
teste deverá ser monitorado durante todo o projeto. O planejamento do teste leva em 
consideração o retorno de informações das atividades de monitoração e controle. 
Projeto de Teste (Análise e Modelagem) 
A análise e a modelagem de teste envolve atividades onde os objetivos gerais do teste são 
transformados em condições e modelos de teste tangíveis. Podemos destacar as seguintes 
atividades principais: 
 Revisar a base de testes (como requisitos, nível de integridade do software (nível de 
risco), arquitetura, modelagem, interfaces); 
 Avaliar a testabilidade dos requisitos e do sistema; 
 Identificar e priorizar as condições ou requisitos de testes e dados de testes baseados 
na análise dos itens de teste, na especificação, no comportamento e na estrutura; 
 Projetar e priorizar os casos de testes de alto nível; 
 Identificar as necessidades de dados para teste (criação de massa) suportando as 
condições e casos de teste; 
 
 
 
 
25 
 Planejar a preparação do ambiente de teste e identificar a infraestrutura e ferramentas 
necessárias; 
 Criar uma rastreabilidade bidirecional entre os requisitos e os casos de teste. 
Implementação e Execução de Teste 
A implementação e execução do teste é a fase onde os procedimentos ou os scripts de teste 
são especificados pela combinação dos casos de teste em uma ordem particular, incluindo 
todas as outras informações necessárias para a execução do teste, o ambiente é preparado e 
os testes são executados. É composta das seguintes atividades principais: 
 Finalizar, implementar e priorizar os casos de teste (incluindo a identificação dos dados 
para teste). 
 Desenvolver e priorizar os procedimentos de teste, criar dados de teste e, 
opcionalmente, preparar o ambiente para teste e os scripts de testes automatizados. 
 Rastrear o caso de teste com a demanda solicitada pelo cliente. Exemplo de demandas: 
Requisitos de sistemas, Requisito de software, Ata de Reunião, Requisito de proposta 
técnica e História de usuário. 
 Criar suítes de teste a partir dos casos de teste para uma execução de teste eficiente. 
 Verificar se o ambiente está preparado corretamente. (checklist de plataforma) 
 Verificar e atualizar a rastreabilidade bidirecional entre a base de teste e os casos de 
teste. 
 Executar os casos de teste manualmente ou utilizando ferramentas de acordo com a 
sequência planejada. 
 Registrar os resultados da execução do teste e anotar as características e versões do 
software em teste, ferramenta de teste e testware. 
 Comparar resultados obtidos com os resultados esperados. 
 Reportar as discrepâncias como incidentes conformeprocedimento 
Atech.21.04.00025 — Problemas no Fornecimento, e analisá-los a fim de estabelecer 
suas causas (por exemplo, defeito no código, em algum dado específico de teste, na 
documentação de teste ou uma execução de inadequada do teste). 
 Repetir os testes como resultado de ações tomadas para cada discrepância. Por 
exemplo, re-execução de um teste que falhou previamente quando da confirmação de 
uma correção (teste de confirmação), execução de um teste corrigido e/ou execução 
de testes a fim de certificar que os defeitos não foram introduzidos em áreas do 
software que não foram modificadas, ou que a correção do defeito não desvendou 
outros defeitos (teste de regressão). 
 
 
 
 
 
 
 
M
an
ua
l d
o 
An
al
is
ta
 d
e 
Te
st
es
 
26 
. Nı́veis de teste 
De acordo com o modelo V usado no processo (ciclo de vida) Atech, temos 3 níveis de teste: 
 Teste de Componente (unidade) - também conhecido como testes unitários. Tem por 
objetivo explorar a menor unidade do projeto, procurando provocar falhas 
ocasionadas por defeitos de lógica e de implementação em cada módulo, 
separadamente. O universo alvo desse tipo de teste são os métodos dos objetos ou 
mesmo pequenos trechos de código. 
 Teste de Integração/Sistema - visa provocar falhas associadas às interfaces entre os 
módulos quando esses são integrados para construir a estrutura do software que foi 
estabelecida na etapa de projeto, além disso avalia o software em busca de falhas por 
meio da utilização do mesmo, como se fosse um usuário final. Dessa maneira, os testes 
são executados nos mesmos ambientes, com as mesmas condições e com os mesmos 
dados de entrada que um usuário utilizaria no seu dia-a-dia de manipulação do 
software. Verifica se o produto satisfaz seus requisitos. 
 Teste de Aceitação - são testes que simulam operações de rotina do sistema de modo 
a verificar se seu comportamento está de acordo com o solicitado. 
Obs.: Teste de Regressão não corresponde a um nível de teste, mas é uma estratégia 
importante para redução de “efeitos colaterais”. Consiste em se aplicar, a cada nova versão do 
software ou a cada ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste 
anteriores do sistema. Pode ser aplicado em qualquer nível de teste. 
Na prática, um Modelo V pode ter diferentes níveis de desenvolvimento e testes, dependendo 
do projeto e do produto. Por exemplo, pode haver teste de integração de componentes após o 
teste de um componente, e teste de integração de sistemas após o teste de sistemas, cabendo 
ao gerente técnico esta definição. 
Fazendo um paralelo dos níveis com as etapas do desenvolvimento, o teste unitário verifica o 
resultado do processo de codificação do software, o teste de integração verifica o projeto 
detalhado (arquitetura de SW), o teste de sistema verifica o projeto de alto nível (arquitetura 
de sistema) e finalmente o teste de aceitação que tem por objetivo a validação dos requisitos 
do sistema. 
Artefatos de software (como cenário de negócios ou casos de uso, especificação de requisitos, 
documentos de modelagem e código) produzidos durante o desenvolvimento muitas vezes são 
a base do teste em um ou mais níveis de teste. Alguns exemplos de referências para produtos 
de trabalho genéricos: CMMI (Capability Maturity Model Integration) ou os “Software life cycle 
processes” IEEE/IEC 12207. Verificação e Validação (e modelagem antecipada de teste) podem 
ser executadas durante a elaboração destes produtos de trabalho. 
 
Modelos Iterativos de Desenvolvimento 
Desenvolvimento iterativo é o processo que estabelece os requisitos, modelagem, construção 
e teste de um sistema, realizada como uma série de desenvolvimentos menores. 
Exemplos desenvolvimento iterativo: Prototipagem, desenvolvimento rápido de aplicação 
(RAD), Rational Unified Process (RUP) e modelos ágeis de desenvolvimento. 
O produto resultante de uma iteração pode ser testado em vários níveis como parte do seu 
desenvolvimento. Um incremento, adicionado a outros desenvolvidos previamente, forma um 
sistema parcial em crescimento, que também deve ser testado. Teste de regressão tem sua 
 
 
 
 
27 
importância aumentada a cada iteração. Verificação e Validação podem ser efetuadas a cada 
incremento. 
. Técnicas de Teste 
Técnicas Estáticas 
Ao contrário dos testes dinâmicos, as técnicas de teste estático não pressupõem a execução do 
software que está sendo testado. Elas são manuais (revisão) ou automatizadas (análise 
estática). 
Revisão é uma maneira de testar o produto de software (incluindo o código) e pode ser 
realizada bem antes da execução do teste dinâmico. Defeitos detectados e removidos durante 
as revisões o mais cedo possível no ciclo de vida do software são muitas vezes mais baratos do 
que aqueles detectados e removidos durante os testes (ex.: defeitos encontrados nos 
requisitos). 
Revisões, análises estáticas e testes dinâmicos têm os mesmos objetivos – identificar defeitos. 
Eles são complementares: as diferentes técnicas podem encontrar diferentes tipos de defeitos 
eficazmente e eficientemente. Em contraste com o teste dinâmico, revisões encontram 
defeitos ao invés de falhas. 
Os defeitos mais facilmente encontrados durante revisões do que em testes dinâmicos são: 
desvios de padrões, defeitos de requisitos, defeitos de modelagem, manutenibilidade 
insuficientemente e especificação incorreta de interfaces. 
 
Processo de Revisão 
Uma revisão pode ser feita inteiramente como uma atividade manual, mas há também 
ferramentas de suporte. 
A principal atividade manual é examinar o produto de trabalho e fazer os comentários sobre 
ele. Qualquer software pode ser revisado, incluindo a especificação de requisitos, diagramas, 
código, plano de teste, especificação de teste, casos de teste, script de teste, manual do usuário 
ou páginas web. 
Os benefícios das revisões incluem a detecção e correção antecipada de defeitos, ganho no 
desenvolvimento em termos de produtividade, redução do tempo no desenvolvimento, 
redução do custo e tempo de teste, menos defeitos e melhoria na comunicação. A revisão pode 
encontrar omissões, por exemplo, nos requisitos, que não são normalmente encontrados no 
teste dinâmico. 
 
Análise Estática por Ferramenta 
Os benefícios da análise estática são: 
 Detecção de defeitos antes da execução do teste. 
 Conhecimento antecipado sobre aspectos suspeitos no código ou programa pelo uso 
de métricas, por exemplo, na obtenção de uma medida da alta complexidade. 
 Identificação de defeitos dificilmente encontrados por testes dinâmicos. 
 Detecção de dependências e inconsistências em modelos de software, como links 
perdidos. 
 
 
 
 
 
 
M
an
ua
l d
o 
An
al
is
ta
 d
e 
Te
st
es
 
28 
 Aprimoramento da manutenibilidade do código e construção. 
 Prevenção de defeitos, se as lições forem aprendidas pelo desenvolvimento. 
Defeitos mais comuns descobertos por ferramentas de análise estática incluem: 
 Referência a uma variável com valor indefinido. 
 Inconsistências entre as interfaces dos módulos e componentes. 
 Variáveis que nunca são usadas ou impropriamente declaradas. 
 Código morto. 
 Falta de lógica ou lógica errada (loops infinitos). 
 Construções excessivamente complicadas. 
 Violação de padrões de programação. 
 Vulnerabilidade na segurança. 
 Violação de sintaxe e de modelos. 
Ferramentas de análises estáticas são tipicamente usadas por desenvolvedores (checando 
regras pré-definidas ou padrões de programação conforme documentos [JAVA] 
ATECH.21.04.01001 – Padrão de Desenvolvimento Java e ATECH.21.04.01002 – [LING C] Padrão 
de Desenvolvimento Linguagem C, antes e durante o teste de componente e de integração e 
por projetistas durante a modelagem do software. Ferramenta de análise estática pode 
produzir um grande número de mensagens de advertências que precisam ser gerenciadas para 
permitir o uso mais efetivo da ferramenta. 
Compiladores podemoferecer algum suporte para a análise estática, incluindo o cálculo de 
métricas. 
Técnica de Modelagem de Teste 
A escolha de qual técnica utilizar dependerá de uma série de fatores, incluindo o tipo de 
sistema, padrões, clientes, requisitos contratuais, nível do risco, tipos de riscos, objetivos do 
teste, documentação disponível, conhecimento dos analistas de teste, tempo, dinheiro, ciclo 
de desenvolvimento, modelo de caso de uso e uma experiência prévia do tipo de defeitos 
encontrados. 
Algumas técnicas são mais facilmente aplicadas em certas situações e níveis de teste, já outras 
são aplicáveis a todos os níveis. 
Ao criar casos de teste, os analistas de teste geralmente usam uma combinação de técnicas de 
teste, incluindo regras de processo e técnicas de data-driven para garantir uma cobertura 
adequada do objeto em teste. 
Identificando as condições de testes e projetando os casos de testes 
O processo pode ser realizado de diferentes maneiras, desde informalmente sem muitos dados 
ou documentação, até um processo muito formal (como o que será descrito ainda nesta seção). 
O nível de formalidade depende do contexto do teste, o que inclui a organização, exigências 
normativas, maturidade do processo de teste e desenvolvimento, restrições de tempo e as 
pessoas envolvidas. 
Durante a análise de teste, a documentação base de teste é analisada de maneira a determinar 
o que testar (ex.: identificar as condições de teste). A condição do teste é definida como um 
item ou evento que pode ser verificado por um ou mais casos de testes (ex.: uma função, 
transação, característica de qualidade ou elemento estrutural). 
 
 
 
 
29 
Estabelecer a rastreabilidade das condições de testes de volta até as especificações e requisitos 
permitem analisar o impacto quando os requisitos mudam e, a cobertura de requisitos a ser 
determinada por um conjunto de testes. Durante a modelagem do teste, o detalhamento da 
abordagem de teste será implementado com base, entre outras considerações, nos riscos 
identificados. 
Durante a modelagem de teste, os casos de teste e os dados de teste são especificados e 
criados. Um caso de teste consiste de um conjunto de valores de entrada, pré-condições de 
execução, resultados esperados e pós-condições de execução, desenvolvidos para cobrir certas 
condições de teste. O “Standard for Software Test Documentation” (IEEE 829-1998) descreve o 
conteúdo da especificação da modelagem de teste (contendo as condições de teste) e a 
especificação de caso de teste. 
Resultados esperados devem ser produzidos como parte da especificação de um caso de teste 
e inclui as saídas, mudança de dados e status, e qualquer outra consequência do teste. Se o 
resultado esperado não for definido, um resultado plausível, porém errado, pode ser 
interpretado como correto. O resultado esperado deve ser definido antes da execução do teste. 
Durante a implementação do teste os casos de teste são desenvolvidos, implementados, 
priorizados e organizados na especificação de procedimento de teste (STD). O procedimento 
de teste especifica a sequência de ações para a uma execução de teste. Se os testes são 
executados por uma ferramenta, a sequência de ações é especificada por um script 
automatizado (que é um procedimento de teste automatizado). 
 
Categorias de técnicas de modelagem de teste 
Técnicas caixa-preta, técnicas baseadas em experiência, técnicas de modelagem de teste, 
técnicas caixa-branca. 
O propósito da técnica de modelagem de teste é identificar as condições e os casos de testes. 
Classificar testes como caixa-preta ou caixa-branca é uma diferenciação clássica. Técnicas caixa- 
preta, (também chamadas de técnicas baseadas em especificação) são uma forma de derivar e 
selecionar as condições e casos de testes baseados na análise da documentação. Isto inclui 
testes funcionais e não funcionais, para um componente ou sistema sem levar em consideração 
a sua estrutura interna. Técnicas de caixa branca (também chamadas de técnicas estruturais ou 
baseadas em estrutura) são baseadas na estrutura interna de um componente ou sistema. 
Algumas técnicas se encaixam claramente em uma única categoria; outras têm elementos de 
mais de uma categoria. 
Características comuns das técnicas baseadas em especificação: 
 Modelos, formais ou informais, são utilizados para especificação de um problema a ser 
resolvido, o software ou seu componente. 
 Os casos de testes podem ser derivados sistematicamente destes modelos. 
Características comuns das técnicas baseadas em estrutura: 
 Informações sobre como o software é construído é utilizada para derivar os casos de 
testes. Por exemplo, código e informações detalhadas de modelagem. 
 A extensão da cobertura do software pode ser medida pelos casos de testes. Além 
disto, os casos de testes podem ser derivados sistematicamente para aumentar a 
cobertura. 
 
 
 
 
 
 
M
an
ua
l d
o 
An
al
is
ta
 d
e 
Te
st
es
 
30 
Características comuns de técnicas baseada em experiência: 
 Conhecimento e experiência de pessoas são utilizados para derivar os casos de testes. 
 Conhecimento de analistas de testes, desenvolvedores, usuários, outros interessados 
(stakeholders) responsáveis pelo software, seu uso e ambiente. 
 Conhecimento sobre defeitos prováveis e sua distribuição. 
Técnicas Baseadas em Especificação ou Caixa-Preta 
Partição de Equivalência 
Pode ser aplicada em qualquer nível de teste, é uma boa técnica para ser aplicada antes das 
demais. Nessa técnica, as entradas do software ou sistema são divididas em grupos que tenham 
um comportamento similar, podendo ser tratados da mesma forma. Partições (ou classes) de 
equivalência podem ser encontradas em dados válidos e inválidos (por exemplo, valores que 
deveriam ser rejeitados). Partições podem também ser identificadas para valores de saídas, 
valores internos e valores relacionados a tempo, (antes e após um evento) e para parâmetros 
de interface (durante teste de integração). Testes podem ser elaborados para cobrir as 
partições. Partição de Equivalência é aplicável a todos os níveis de testes. 
A Partição de Equivalência pode ser usada para atingir a cobertura dos valores de entrada e 
saída. Pode ser aplicada em uma entrada manual, interface entrada de sistema ou como 
parâmetro de interface num teste de integração. 
Passos: 
 Decompor o programa de software em funções (partições ou classes); 
 Identificar as variáveis que determinam o comportamento de cada função; 
 Particionar o valor de cada variável em classes de equivalência (válidas e inválidas); 
 Especificar casos de teste: 
o Eliminar classes impossíveis ou casos desinteressantes; 
o Selecionar casos de testes cobrindo as classes válidas das diferentes variáveis; 
o Para cada classe inválida escolha um caso de teste que cubra somente uma 
classe de cada vez. 
Análise do Valor Limite 
Esta técnica é muitas vezes considerada uma extensão da partição de equivalência pois é 
utilizada avaliando o comportamento nos limites de uma partição, onde existe maior 
probabilidade de estar incorreto, são áreas onde testes estão mais propensos a indicar defeitos 
e que pode ser aplicada em todos os níveis de teste. Os valores limites de uma partição são seu 
máximo e seu mínimo. Um valor limite para uma partição válida é um valor limite válido. O 
limite de partição inválida é um valor limite inválido. Testes podem ser projetados para cobrir 
tanto os valores válidos com valores inválidos. 
Valores limites podem também ser usados para selecionar dados de testes. 
Tabela de Decisão 
A tabela de decisão é uma técnica que tem como alvo as regras de negócio, também chamada 
de causa e efeito. É considerada uma boa alternativa para capturar requisitos de sistemas que 
contém condições lógicas e para documentar o comportamento interno do sistema, podem 
também ser utilizadas para registrar regras de negócio complexas a serem implementadas. A 
 
 
 
 
31 
especificaçãoé analisada e as condições e ações do sistema são identificadas. As condições de 
entrada e ações são declaradas de uma forma que possam ser entendidas, como verdadeiras 
ou falsas (Booleano). Cada coluna da tabela corresponde a uma regra de negócio que define 
uma única combinação de condições que resulta na execução de ações associadas com aquela 
regra. A cobertura padrão comumente usada em uma tabela de decisão é ter no mínimo um 
teste por coluna cobrindo todas as combinações de condições apresentadas. 
O grande ganho na utilização da tabela de decisão é que ela cria combinações de condições que 
geralmente não foram exercitadas durante os testes. Pode ser aplicada a todas as situações 
quando a execução do software depende de muitas decisões lógicas. 
Teste de Transição de Estados 
É utilizado quando um sistema exibir respostas diferentes dependendo da sua condição atual 
ou de estado anterior. Neste caso, o comportamento do sistema pode ser representado como 
um diagrama de transição de estados. Permite ao analista de teste visualizar o software em 
termos de estados, transições entre estados, as entradas ou eventos que disparam as mudanças 
de estado (transição) e as ações que podem resultar daquelas transições. 
Os estados do sistema, ou objetos em teste, são isolados, identificáveis e finitos. Uma tabela de 
estado exibe a relação entre estados e entradas, e pode destacar possíveis transições inválidas. 
Os testes podem ser construídos para cobrir uma sequência típica de status, cobrir todos os 
estados, exercitar todas as transições, exercitar uma sequência específica de transições ou 
testar transições inválidas. 
Teste de transição de status é muito utilizada em softwares industriais embarcados e 
automações técnicas em geral. No entanto, a técnica é também adequada para modelar um 
objeto de negócio tendo estado específico ou para testar fluxos de telas de diálogos (exemplo: 
aplicação de internet e cenários de negócios). 
Teste de Caso de Uso 
Testes podem ser especificados a partir de casos de uso ou cenários de negócios. Casos de uso 
descrevem o fluxo do processo de um sistema baseado nas suas possibilidades de utilização, 
interações entre os atores (usuários e o sistema) que produz um resultado relevante para um 
usuário do sistema. Cada caso de uso tem pré-condições, que precisam ser garantidas para que 
o caso de uso funcione com sucesso. Cada caso de uso é finalizado com uma pós-condição que 
representa os resultados observados e o estado final do sistema após o término do caso de uso. 
Um caso de uso normalmente tem um cenário mais comum (mais provável), e algumas vezes 
ramificações. 
Os casos de testes derivados de casos de uso são muito úteis na descoberta de defeitos no fluxo 
do processo durante a utilização do sistema no mundo real. Casos de uso muitas vezes são 
tratados como cenários e são úteis para construir testes de aceite com a participação do usuário 
final. Eles podem ajudar a descobrir defeitos de integração causados pela interação e 
interferência de diferentes componentes, que podem não ter sido detectados durante os testes 
individuais de componentes. 
Técnicas Baseadas em Estrutura ou Caixa-Branca 
Teste de estrutura ou caixa-branca é baseado na estrutura do software ou sistema, como 
veremos nos exemplos que seguem abaixo: 
 Nível de Componente: a estrutura é o próprio código, ex.: comandos, decisões e 
desvios. 
 Nível de Integração: a estrutura pode ser uma árvore de chamadas (um diagrama em 
que um módulo chama outros módulos). 
 
 
 
 
 
 
M
an
ua
l d
o 
An
al
is
ta
 d
e 
Te
st
es
 
32 
 Nível de Sistema: A estrutura pode ser uma estrutura de menu, processos de negócios 
ou estruturas das páginas Web. 
Nesta seção basicamente duas técnicas de cobertura de código baseados em comandos e 
decisões serão discutidas. Para teste de decisão, um diagrama de controle de fluxo pode ser 
utilizado para visualizar as alternativas de cada decisão. 
Teste e Cobertura de Sentença 
No teste de componente, cobertura de sentença é avaliada pela porcentagem de sentenças 
executáveis que foram exercitadas por um conjunto de casos de testes. No teste de sentenças 
derivam-se casos de teste para executar sentenças específicas, normalmente para se aumentar 
a cobertura. 
Teste e Cobertura de Decisão 
Cobertura de decisão, também chamada de teste de ramificação, é avaliada pela porcentagem 
dos resultados da decisão (por exemplo, as opções de “Verdadeiro” ou “Falso” de uma 
expressão condicional - IF) que foram exercitados em um conjunto de casos de teste. No teste 
de decisão derivam-se os casos de testes para executar decisões específicas, normalmente para 
se aumentar a cobertura. 
Teste de decisão é uma forma de teste de controle de fluxo, já que ele gera um fluxo específico 
pelos pontos de decisões. A cobertura de decisão é mais eficiente que a cobertura de sentenças: 
100% da cobertura de decisão garante 100% da cobertura de sentença, mas não vice-versa. 
Outras Técnicas Baseadas na Estrutura 
Existem formas mais detalhadas de cobertura estrutural além da cobertura de decisão, por 
exemplo, cobertura de condições e cobertura de múltiplas condições. 
O conceito de cobertura também pode ser aplicado a outros níveis de teste (teste de 
integração) no qual, as porcentagens de módulos, componentes ou classes são exercitadas por 
um conjunto de casos de teste. Por exemplo, poderia expressá-las como cobertura de módulos, 
componentes ou classes. 
Normalmente é utilizada uma ferramenta para dar o suporte de teste de estrutura do código. 
Técnicas Baseadas em Experiência 
 Teste exploratório, ataque (de falha). 
Os testes baseados na experiência são testes derivados da intuição e conhecimento dos 
analistas de teste por experiência em aplicações e tecnologia similares. Quando usado para 
aumentar a técnica sistemática, testes intuitivos podem ser úteis para identificar testes 
específicos que não são facilmente identificados pelas técnicas formais, especialmente quando 
aplicado após ter estabelecido o processo mais formal. No entanto esta técnica pode produzir 
amplas variedades e graus de eficiência, dependendo da experiência do analista de testes. 
Possivelmente a técnica mais amplamente aplicada é a de supor (adivinhar) onde estão os 
erros. Uma abordagem estruturada da técnica de dedução de erros é enumerar uma lista de 
possíveis erros e construir testes com objetivo de atacar/cobrir estes erros. Esta abordagem 
sistemática é chamada de ataque de falha. 
Estas listas de defeitos e falhas podem ser construídas com base na experiência, dados de 
defeitos/falhas disponíveis e do conhecimento comum de como o software falha. 
Teste exploratório ocorre simultaneamente à modelagem, execução e registro de teste, e 
baseia-se nos objetivos de teste, onde é realizado em um tempo predefinido. É uma abordagem 
muito usual, em locais onde a especificação é rara ou inadequada e existe grande pressão por 
 
 
 
 
33 
conta de prazo, ou para aprimorar/complementar um teste mais formal. Pode servir como uma 
checagem do processo de teste, assegurando que os defeitos mais importantes sejam 
encontrados. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
M
an
ua
l d
o 
An
al
is
ta
 d
e 
Te
st
es
 
34 
 
 
. Boas práticas 
Suíte de teste 
As suítes de teste podem possuir os seguintes nomes: 
 Nome + número do Caso de Uso 
 Funcionalidade Macro 
 Ideia de negócio 
Não deve ser colocado como nome da suíte de teste qualquer tipo de evento ou ponto marco 
do projeto, exemplo: FAT, SAT, Manutenção e etc, como boa prática a ser seguida a utilização 
de palavra chave para que facilite a busca. 
Casos de teste 
Os casos de testes além de cobrir os requisitos contratuais, devem também contemplar 
cenários relacionados ao dia a dia do usuário do sistema. Para que isso seja possível, se 
aproximar do cliente é algo que ajudará e ter uma comunicaçãoefetiva com os analistas de 
requisitos do projeto/produto para que eles também contribuam. 
Dicas para uma boa elaboração do caso de teste: 
 O caso de teste deve ser iniciado com um verbo no infinitivo, exemplo: 
o Incluir Plano de Voo; 
o Alterar rota; 
o Gerar gráfico 
o Visualizar relatório 
 Deve ser escrito de forma clara, para que um executor de teste consiga reproduzi-lo, 
mesmo que muitos casos são necessários um entendimento prévio do negócio 
envolvido. 
 Sempre se atentar qual o objetivo do teste e descrever os passos de forma que o 
objetivo seja atendido. 
o Para testes funcionais não deve entrar no detalhe técnico, como por exemplo: 
Clicar no botão. 
 O objetivo deve ser atendido no máximo entre 5 a 7 passos de teste, caso ultrapasse 
tente quebra-lo em outros casos de testes. Casos de testes com muitos passos 
perdem o foco e muitas vezes significa que o objetivo não está definido 
 Para não ser perder na cobertura dos casos de testes, comece elaborando conforme 
requisitos. 
 Para uma boa cobertura de casos de testes, deve ser levado em conta a quantidade de 
testes extraídos de um único requisito. Exemplo: 
 
 
 
 
35 
o Requisito01: O sistema deve permitir incluir um plano de voo com as 
informações x e y 
o Teste01: Incluir plano de voo com todas as informações 
o Teste02: Incluir plano de voo com informação x 
o Teste03: Incluir plano de voo com informação z 
o Teste03: Tentar incluir plano de voo sem informação 
o Teste04: Incluir plano de voo com informação x maior que o permitido 
o Teste05: Incluir plano de voo com informação y maior que o permitido 
o Teste06: Incluir plano de voo com informação x menor que o permitido 
o Teste07: Incluir plano de voo com informação y menor que o permitido 
o Teste08: Incluir plano de voo com informação x com apenas letras 
o Teste09: Incluir plano de voo com informação y com apenas letras 
o Teste10: Incluir plano de voo com informação x com apenas números 
o Teste11: Incluir plano de voo com informação y com apenas números 
Nesse exemplo existem casos de testes onde o requisito não menciona informações suficientes, 
portanto isso não impede a criação do caso de teste. Nesse caso o analista de teste está 
também realizando a revisão dos requisitos e deve informar o analista de requisitos/sistemas 
do projeto. Essa revisão é vem vinda e necessário, devendo ser registrada na ferramenta de 
gestão do projeto (Exemplo: JIRA) 
Ainda vale lembrar que possivelmente apenas o exemplo de caso de teste (Teste01) deve ser 
inserido no caderno de teste para ser apresentado ao cliente, os demais devem sim ser 
executados internamente. 
O documento de procedimento de teste deve sempre que possível deve ser revisado pelo par, 
com o objetivo de ter um olhar diferente para o passo a passo de teste. 
Todo caso de teste deve ter como base uma solicitação do cliente, seja ele um requisito de 
sistema, requisito de software, Ata de Reunião, Requisito de proposta técnica e História de 
usuário. 
Execução de caso de teste 
Durante a execução dos casos de testes no período considerado “testes interno” ou seja, teste 
com ausência do cliente, devemos reportar qualquer tipo de problema encontrado na 
execução, mesmo que o problema encontrado não impeça o objetivo do caso de teste. Esse 
período de execução tem como objetivo varrer o sistema e alertar sobre a qualidade do 
produto. O executor deve ser rígido ao registrar a falha, pois qualquer problema encontrado 
deve falhar o caso de teste. 
Vale lembrar que essa rigidez na execução não é tão considerada no momento do dry run onde 
o foco é atender o objetivo do caso de teste. 
Para os casos de testes que possuem registro de Falha deve obrigatoriamente ter um registro 
do problema na ferramenta de gestão de bug tracking adotado no projeto (exemplo: JIRA). 
 
 
 
 
 
 
M
an
ua
l d
o 
An
al
is
ta
 d
e 
Te
st
es
 
36 
Todos os insumos utilizados durante a execução dos testes devem ser versionados. Exemplo: 
Script de teste e massa de dados. 
A execução dos testes deve ser executada por pessoas diferentes, para que seja evitado o vício 
no passo a passo e assim não seja perdido o olhar crítico. 
Smoke teste 
É uma ótima prática a ser seguida antes do fechamento da versão, podendo ser executada pelo 
desenvolvedor ou analista de teste. 
. Certificações 
No mercado existe certificações que contribuem na expansão do conhecimento relacionado a 
testes, como por exemplo: 
 Usar uma linguagem comum para a comunicação eficiente e eficaz com outros 
testadores e participantes de um projeto de teste. 
 Compreender os conceitos de testes estabelecidos, o processo fundamental de teste, 
abordagens de teste, e princípios para apoiar os objetivos do teste. 
 Projetar e priorizar testes usando técnicas estabelecidas; analisar ambas as 
especificações funcionais e não-funcionais (como desempenho e usabilidade) em 
todos os níveis de teste para sistemas com um nível baixo a médio de complexidade. 
 Executar testes de acordo com os planos de teste aprovados, e analisar e informar 
sobre os resultados dos testes. 
 Escrever relatórios de incidentes claros e compreensíveis. 
 Efetivamente participar de revisões de projetos de pequeno e médio porte. 
 Estar familiarizado com diferentes tipos de ferramentas de teste e seus usos; auxiliar 
no processo de seleção e implementação. 
 Testar em Projetos Ágeis. 
 Atuar como um testador em Projetos Ágeis 
 Conhecer técnicas e métodos de testes Ágeis 
 Avaliar os riscos de qualidade do produto dentro de um projeto Ágil 
 Estimar o esforço de teste com base no conteúdo de iteração e nos riscos de qualidade 
 Conhecer Ferramentas em Projetos Ágeis 
 
Para maiores informações acessar http://www.bstqb.org.br/.