TESTE DE SOFTWARE — Guia Completo Documento Técnico
TESTE DE SOFTWARE
Guia Completo de Fundamentos, Técnicas e Boas Práticas
Documento Técnico • 2026
Este documento aborda os principais conceitos de Teste de Software, desde fundamentos teóricos até
técnicas avançadas aplicadas no dia a dia do desenvolvimento profissional. Ideal para desenvolvedores
.NET e analistas de sistemas que buscam qualidade e confiabilidade em seus projetos.
© 2026 — Teste de Software Página 1
TESTE DE SOFTWARE — Guia Completo Documento Técnico
1. Introdução ao Teste de Software
Teste de software é o processo de avaliação e verificação de que um produto ou aplicação faz o que
deveria fazer. Os benefícios do teste incluem prevenção de bugs, redução de custos de desenvolvimento
e melhoria do desempenho do software.
De acordo com o ISTQB (International Software Testing Qualifications Board), teste é uma atividade
realizada para avaliar a qualidade de um produto e para melhorá-la, identificando defeitos e problemas.
Não se trata apenas de encontrar falhas, mas de fornecer informações sobre o nível de qualidade do
produto.
Por que Testar?
• Redução de custos: Defeitos encontrados cedo custam até 100x menos para corrigir.
• Segurança: Garante que dados sensíveis sejam protegidos adequadamente.
• Qualidade do produto: Entrega experiências positivas ao usuário final.
• Conformidade: Assegura aderência a normas e regulamentações (LGPD, ISO 25010).
• Confiança: Aumenta a credibilidade da equipe de desenvolvimento perante o cliente.
Princípios Fundamentais do Teste (ISTQB)
# Princípio Descrição
1 Teste revela defeitos Testes reduzem a probabilidade de defeitos ocultos, mas não provam ausência de bugs.
2 Teste exaustivo é impossível Testar todas as combinações é inviável; use análise de risco para priorizar.
3 Teste antecipado Testes devem começar o mais cedo possível no ciclo de vida.
4 Agrupamento de defeitos Defeitos tendem a se concentrar em módulos específicos do sistema.
5 Paradoxo do pesticida Casos de teste repetidos perdem eficácia; devem ser revisados periodicamente.
6 Teste depende de contexto Abordagens diferentes para tipos distintos de software.
7 Ilusão da ausência de erros Software sem bugs não significa software de qualidade.
© 2026 — Teste de Software Página 2
TESTE DE SOFTWARE — Guia Completo Documento Técnico
2. Níveis de Teste
Os níveis de teste definem onde no ciclo de desenvolvimento cada tipo de verificação é realizado. Cada
nível tem objetivos específicos e é executado por diferentes stakeholders.
Teste de Unidade (Unit Testing)
Verifica unidades individuais de código (métodos, classes) de forma isolada. Em .NET, utiliza-se xUnit,
NUnit ou MSTest com mocks via Moq ou NSubstitute.
Teste de Integração (Integration Testing)
Verifica a interação entre módulos ou serviços. Testa contratos de APIs, acesso a banco de dados e
comunicação entre componentes.
Teste de Sistema (System Testing)
Avalia o sistema como um todo em relação aos requisitos especificados. Inclui testes funcionais e não
funcionais completos.
Teste de Aceitação (Acceptance Testing (UAT))
Valida se o sistema atende às necessidades do negócio. Executado pelo cliente ou usuário final antes
da entrega.
Pirâmide de Testes
A pirâmide de testes, conceito popularizado por Mike Cohn, sugere que uma suíte de testes saudável
deve ter: muitos testes de unidade na base (rápidos e baratos), uma quantidade moderada de testes de
integração no meio, e poucos testes de sistema/E2E no topo (lentos e caros). Uma proporção típica é
70% unidade / 20% integração / 10% E2E.
© 2026 — Teste de Software Página 3
TESTE DE SOFTWARE — Guia Completo Documento Técnico
3. Tipos de Teste
Tipo Objetivo Ferramenta (.NET)
Funcional Verificar funcionalidades contra requisitos xUnit, Selenium
Regressão Garantir que mudanças não quebraram o existente
xUnit + CI/CD
Performance Medir tempo de resposta e throughput k6, NBomber, JMeter
Segurança Identificar vulnerabilidades e brechas OWASP ZAP, SonarQube
Usabilidade Avaliar facilidade de uso pelo usuário UserTesting, Maze
Carga Comportamento sob carga elevada esperada
k6, NBomber
Estresse Comportamento além dos limites normais k6, Artillery
Smoke Verificação rápida das funções críticas xUnit, Postman
Sanidade Confirmar que uma área específica funciona
xUnit, REST Assured
Teste Caixa-Branca vs Caixa-Preta vs Caixa-Cinza
Aspecto Caixa-Branca Caixa-Preta Caixa-Cinza
Visibilidade Código interno visível Sem acesso ao código Acesso parcial
Quem executa Desenvolvedor QA / Cliente QA com conhecimento técnico
Foco Lógica interna Funcionalidade externa Combinação de ambos
Técnicas Cobertura de código, fluxo Partição equivalência, BVA Testes de integração
Vantagem Alta cobertura de código Perspectiva real do usuário Equilíbrio entre os dois
© 2026 — Teste de Software Página 4
TESTE DE SOFTWARE — Guia Completo Documento Técnico
4. Técnicas de Teste
Técnicas de teste são métodos sistemáticos para derivar casos de teste eficazes. Cada técnica é
adequada para diferentes cenários e tipos de defeito.
4.1 Partição de Equivalência
Divide os dados de entrada em classes onde todos os valores se comportam da mesma forma. Testa um
representante de cada classe, reduzindo drasticamente o número de casos de teste necessários.
Exemplo: campo Idade (18–120): classes válidas [18–120], inválidas [<18] e [>120]. Testar 25, 17 e 130
cobre todas as classes.
4.2 Análise de Valor Limite (BVA)
Complementa a partição de equivalência focando nos limites entre classes. Defeitos tendem a se
concentrar nos extremos. Para o campo Idade: testar 17, 18, 19, 119, 120 e 121.
4.3 Tabela de Decisão
Útil quando há múltiplas condições combinadas. Cada coluna representa uma regra de negócio com suas
condições e ações resultantes.
Condição / Ação Regra 1 Regra 2 Regra 3 Regra 4
Usuário autenticado Sim Sim Não Não
Assinatura ativa Sim Não Sim Não
→ Acesso Premium ✓ ✗ ✗ ✗
→ Acesso Básico ✗ ✓ ✗ ✗
→ Tela de Login ✗ ✗ ✓ ✓
4.4 Testes Baseados em Estado (State Transition)
Modela o comportamento do sistema como uma máquina de estados. Ideal para fluxos com estados bem
definidos, como um pedido de e-commerce: Rascunho → Confirmado → Em Separação → Despachado
→ Entregue → Cancelado.
© 2026 — Teste de Software Página 5
TESTE DE SOFTWARE — Guia Completo Documento Técnico
5. TDD, BDD e ATDD
5.1 Test-Driven Development (TDD)
TDD é uma metodologia onde os testes são escritos antes do código de produção. O ciclo clássico é
chamado de Red → Green → Refactor:
• ■ Red: Escrever um teste que falha (o código ainda não existe).
• ■ Green: Escrever o mínimo de código para o teste passar.
• ■ Refactor: Melhorar o código sem quebrar os testes existentes.
Exemplo TDD em C# com xUnit:
[Test] // Etapa Red — teste escrito primeiro
public void Calcular_Desconto_ClienteVIP_Retorna20Porcento()
{
var servico = new DescontoService();
var resultado = [Link](100m, [Link]);
[Link](20m, resultado);
}
5.2 Behavior-Driven Development (BDD)
BDD estende o TDD utilizando linguagem natural para descrever comportamentos do sistema. Usa a
sintaxe Gherkin (Given / When / Then) para criar especificações executáveis que são compreensíveis por
todas as partes.
Funcionalidade: Desconto para clientes VIP
Cenário: Cliente VIP recebe 20% de desconto
Dado que o cliente é do tipo VIP
E o valor do pedido é R$ 100,00
Quando o desconto é calculado
Então o desconto deve ser R$ 20,00
Em .NET, o framework SpecFlow implementa BDD com Gherkin, integrando-se ao xUnit ou NUnit para a
execução dos cenários.
5.3 ATDD — Acceptance Test-Driven Development
O ATDD envolve clientes, desenvolvedores e testadores na definição de critérios de aceitação antes do
desenvolvimento. Os testes de aceitação guiam toda a implementação, garantindo alinhamento com os
requisitos de negócio desde o início.
© 2026 — Teste de Software Página 6
TESTE DE SOFTWARE — Guia Completo Documento Técnico
6. Automação de Testes em .NET
A automação de testes é fundamental para projetos modernos com CI/CD. O ecossistema .NET oferece
ferramentas maduras para todos os níveis da pirâmide de testes.
Principais Frameworks e Ferramentas
Ferramenta Categoria Uso Principal
xUnit Unit Testing Framework padrão para testes unitários e de integração
NUnit Unit Testing Framework maduro com rico conjunto de asserts
MSTest Unit Testing Framework nativo da Microsoft integrado ao VS
Moq Mocking Criação de objetos mock/stub para isolamento
FluentAssertions Assertions Asserções legíveis em linguagem natural
Selenium WebDriver UI/E2E Automação de browsers para testes E2E
Playwright (.NET) UI/E2E Automação moderna de browsers, multi-browser
SpecFlow BDD Implementação de BDD com Gherkin em .NET
NBomber Performance Testes de carga e performance para .NET
[Link] API Mocking Mock de APIs HTTP para testes de integração
Exemplo: Teste de Integração com WebApplicationFactory
public class PedidoApiTests : IClassFixture<WebApplicationFactory<Program>>
{
private readonly HttpClient _client;
public PedidoApiTests(WebApplicationFactory<Program> factory)
=> _client = [Link]();
[Fact]
public async Task POST_Pedido_Retorna201Created()
{
var payload = new { ProdutoId = 1, Quantidade = 2 };
var response = await _client.PostAsJsonAsync("/api/pedidos", payload);
[Link]().Be([Link]);
}
}
© 2026 — Teste de Software Página 7
TESTE DE SOFTWARE — Guia Completo Documento Técnico
7. CI/CD e Cobertura de Código
7.1 Integração de Testes no Pipeline CI/CD
Integrar testes ao pipeline de CI/CD garante que nenhum defeito chegue à produção sem ser detectado.
O GitHub Actions é amplamente usado em projetos .NET:
name: .NET Tests
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-dotnet@v3
with: { dotnet-version: "8.0.x" }
- run: dotnet restore
- run: dotnet build --no-restore
- run: dotnet test --collect:"XPlat Code Coverage"
7.2 Cobertura de Código (Code Coverage)
A cobertura mede quais partes do código são exercitadas pelos testes. Ferramentas como Coverlet
(open source) e dotCover (JetBrains) geram relatórios detalhados. O ReportGenerator converte os
resultados para formatos HTML e Badges.
Métrica Descrição Meta Recomendada
Line Coverage % de linhas executadas > 80%
Branch Coverage % de branches (if/else) cobertas > 70%
Method Coverage % de métodos chamados > 85%
Class Coverage % de classes instanciadas > 80%
Nota: Cobertura alta não garante qualidade dos testes. Um teste que executa código sem fazer asserções
aumenta a cobertura, mas não agrega valor real. Priorize a qualidade e significado dos testes.
© 2026 — Teste de Software Página 8
TESTE DE SOFTWARE — Guia Completo Documento Técnico
8. Gestão de Defeitos e Métricas de Qualidade
8.1 Ciclo de Vida de um Defeito
Um defeito (bug) passa por estados bem definidos desde sua descoberta até o fechamento. Gerenciá-los
adequadamente é essencial para rastrear a qualidade do projeto:
• Novo: Defeito registrado pelo testador com evidências.
• Atribuído: Responsável designado para análise e correção.
• Em andamento: Desenvolvedor trabalhando na correção.
• Corrigido: Correção aplicada, aguardando reteste.
• Reteste: Testador verifica se a correção resolveu o problema.
• Fechado: Defeito resolvido e verificado com sucesso.
• Reaberto: Problema persiste; ciclo reiniciado.
• Recusado: Comportamento é esperado; não é um defeito.
8.2 Classificação de Severidade vs Prioridade
Severidade Definição Exemplo
Crítica Sistema inutilizável, perda de dados Aplicação não inicia, dados corrompidos
Alta Funcionalidade principal quebrada Login não funciona, pagamento falha
Média Funcionalidade secundária afetada Relatório com dados incorretos
Baixa Problema cosmético ou mínimo impactoTexto mal alinhado, erro de digitação
8.3 Métricas de Qualidade Essenciais
• Defect Density: Número de defeitos por KLOC (mil linhas de código). Meta: < 1.
• Defect Leakage: % de defeitos encontrados em produção vs. total. Meta: < 5%.
• Test Pass Rate: % de casos de teste que passaram. Meta: > 95% na entrega.
• MTTR: Mean Time to Repair — tempo médio para corrigir defeitos críticos.
• Escaped Defects: Defeitos reportados por usuários após o release.
© 2026 — Teste de Software Página 9
TESTE DE SOFTWARE — Guia Completo Documento Técnico
9. Boas Práticas e Conclusão
9.1 Princípios FIRST para Testes de Unidade
Letra Princípio Significado
F Fast Testes devem executar em milissegundos.
I Independent Sem dependência entre testes; ordem não importa.
R Repeatable Mesmo resultado em qualquer ambiente.
S Self-Validating Resultado claro: passa ou falha. Sem análise manual.
T Timely Escritos junto com (ou antes de) o código de produção.
9.2 Padrão AAA — Arrange, Act, Assert
Estrutura recomendada para organizar casos de teste de forma clara e legível:
[Fact]
public void Somar_DoisNumeros_RetornaSomaCorreta()
{
// Arrange — preparar dados e dependências
var calculadora = new Calculadora();
// Act — executar a ação sob teste
var resultado = [Link](3, 7);
// Assert — verificar o resultado esperado
[Link](10, resultado);
}
9.3 Checklist de Qualidade para Times .NET
■ Todo pull request deve ter testes cobrindo os novos comportamentos.
■ Pipeline de CI deve executar todos os testes automaticamente.
■ Cobertura de código monitorada e com threshold mínimo configurado.
■ Testes de regressão executados a cada build para evitar quebras.
■ Defeitos críticos têm testes de regressão criados antes da correção.
■ Revisão de código inclui revisão da qualidade dos testes escritos.
■ Ambientes de teste isolados com dados de teste controlados.
■ Métricas de qualidade revisadas em cada sprint review.
Conclusão: Teste de software não é uma etapa opcional — é parte integrante do desenvolvimento
profissional. Adotar uma cultura de qualidade, investir em automação e aplicar as técnicas certas
para cada contexto são os pilares que diferenciam equipes de alta performance. Em projetos .NET,
o ecossistema moderno oferece todas as ferramentas necessárias para construir software confiável,
seguro e de fácil manutenção.
© 2026 — Teste de Software Página 10