Equipes costumam dizer que “usam automação” como se isso definisse como os testes são organizados. Não define. Duas suítes podem ser automatizadas e, ainda assim, ter estruturas completamente diferentes, com custos de manutenção muito diferentes. Essa estrutura é o framework: ele determina como os testes crescem, quem consegue contribuir e quanto uma mudança pequena na UI ou na API afeta o restante da suíte.
Este guia apresenta seis tipos clássicos de frameworks de automação de testes: linear, modular, baseado em dados (data-driven), baseado em palavras-chave (keyword-driven), híbrido e baseado em comportamento (behavior-driven, ou BDD). A ideia é ajudar você a escolher uma estrutura de acordo com sua equipe, seu produto e seu custo de manutenção — não apenas herdar o que alguém configurou antes.
O que é um framework de automação de testes
Um framework de automação de testes é o conjunto de convenções, componentes reutilizáveis e decisões arquiteturais que define como os testes são escritos, organizados, executados e mantidos.
Ele responde perguntas como:
- Onde ficam os dados de teste?
- Como reutilizar passos comuns, como login ou criação de usuário?
- Como separar lógica de teste de dados de entrada?
- Quem pode criar testes: apenas desenvolvedores ou também QA e produto?
- Como os resultados são reportados?
- Como evitar que uma mudança pequena quebre centenas de testes?
Se você está começando, esta visão geral sobre o que é teste automatizado ajuda a contextualizar os conceitos antes de comparar os tipos de framework.
A manutenção é o ponto central. Criar os primeiros testes automatizados costuma ser simples. Manter centenas ou milhares de testes enquanto a aplicação muda toda semana é o desafio real.
Exemplo prático: uma tela de login muda o rótulo de Email para E-mail corporativo.
- Em uma suíte bem modularizada, você atualiza um seletor ou uma função.
- Em uma suíte linear, talvez precise editar dezenas ou centenas de scripts repetidos.
A aplicação é a mesma. O custo muda por causa da estrutura do framework.
Os seis tipos de framework
1. Linear: gravação e reprodução
Um framework linear registra ações e as reproduz como um script. Cada teste é uma sequência plana de passos, sem funções compartilhadas e sem separação entre lógica e dados.
Exemplo conceitual:
test('login válido', async ({ page }) => {
await page.goto('/login')
await page.fill('#email', 'user@example.com')
await page.fill('#password', '123456')
await page.click('button[type="submit"]')
await expect(page).toHaveURL('/dashboard')
})
Esse formato funciona bem para:
- protótipos;
- demonstrações rápidas;
- smoke checks pontuais;
- testes descartáveis.
O problema aparece quando a suíte cresce. Se o login está copiado em cinquenta testes, qualquer mudança no formulário exige cinquenta edições.
Use linear apenas quando o teste for realmente temporário. Se a suíte vai durar mais do que algumas semanas, extraia funções reutilizáveis cedo.
2. Modular
Um framework modular divide a aplicação em módulos reutilizáveis. Em vez de repetir os passos em cada teste, você cria funções ou objetos que representam partes estáveis do sistema.
Exemplo:
async function login(page, email, password) {
await page.goto('/login')
await page.fill('#email', email)
await page.fill('#password', password)
await page.click('button[type="submit"]')
}
test('usuário acessa o dashboard após login', async ({ page }) => {
await login(page, 'user@example.com', '123456')
await expect(page).toHaveURL('/dashboard')
})
Agora, se a tela de login mudar, você ajusta a função login() uma vez.
Esse tipo é indicado quando:
- a suíte será mantida por mais tempo;
- há vários fluxos compartilhando os mesmos passos;
- desenvolvedores ou QAs técnicos escrevem testes;
- você quer reduzir duplicação.
A desvantagem é o investimento inicial. Alguém precisa definir os módulos, as funções reutilizáveis e os limites de abstração. Para a maioria das equipes de engenharia, porém, essa é a base mais segura. Ela combina bem com as práticas descritas em como escrever scripts de teste automatizados.
3. Baseado em dados (data-driven)
Um framework data-driven separa a lógica do teste dos dados de entrada. O mesmo teste roda várias vezes usando dados vindos de CSV, JSON, planilhas ou banco de dados.
Exemplo com uma lista de credenciais:
const casos = [
{ email: 'user@example.com', password: '123456', esperado: 'sucesso' },
{ email: 'user@example.com', password: 'errada', esperado: 'erro' },
{ email: '', password: '123456', esperado: 'erro' },
]
for (const caso of casos) {
test(`login com ${caso.email || 'email vazio'} deve retornar ${caso.esperado}`, async ({ page }) => {
await login(page, caso.email, caso.password)
if (caso.esperado === 'sucesso') {
await expect(page).toHaveURL('/dashboard')
} else {
await expect(page.locator('.error')).toBeVisible()
}
})
}
Também é comum carregar os dados de um arquivo JSON:
[
{
"email": "user@example.com",
"password": "123456",
"esperado": "sucesso"
},
{
"email": "user@example.com",
"password": "errada",
"esperado": "erro"
}
]
Esse modelo é útil quando você precisa testar muitas combinações de entrada contra o mesmo fluxo:
- logins válidos e inválidos;
- limites numéricos;
- variações de localidade;
- diferentes perfis de usuário;
- payloads de API.
Para APIs, uma abordagem de teste baseada em dados com CSV e JSON permite transformar uma requisição em muitos casos de teste.
A limitação: o comportamento do teste permanece fixo. Você aumenta a cobertura variando os dados, não criando fluxos completamente diferentes.
4. Baseado em palavras-chave (keyword-driven)
Um framework keyword-driven representa ações como palavras-chave: Login, SearchProduct, AddToCart, VerifyTotal.
Os testes podem ser descritos em uma tabela:
| Ação | Argumento 1 | Argumento 2 |
|---|---|---|
| Login | user@example.com | 123456 |
| SearchProduct | notebook | |
| AddToCart | notebook | |
| VerifyTotal | 3500.00 |
Por trás da tabela, cada palavra-chave tem uma implementação:
const keywords = {
Login: async (page, email, password) => {
await login(page, email, password)
},
SearchProduct: async (page, term) => {
await page.fill('#search', term)
await page.press('#search', 'Enter')
},
VerifyTotal: async (page, expectedTotal) => {
await expect(page.locator('#total')).toHaveText(expectedTotal)
}
}
Esse tipo é útil quando:
- analistas de QA ou pessoas de negócio precisam montar testes;
- a equipe técnica quer controlar a implementação;
- os fluxos são compostos por ações de alto nível;
- a legibilidade para não-programadores é importante.
O custo está na biblioteca de palavras-chave. Se ela for mal desenhada, vira outro sistema para manter. Palavras-chave muito genéricas perdem clareza; palavras-chave muito específicas geram duplicação.
5. Híbrido
Um framework híbrido combina dois ou mais modelos. Na prática, muitas suítes maduras acabam assim:
- modular para reutilizar fluxos;
- data-driven para variar entradas;
- keyword-driven para permitir composição por não-programadores;
- BDD para cenários que exigem alinhamento com produto.
Exemplo de combinação modular + data-driven:
import casosLogin from './casos-login.json'
for (const caso of casosLogin) {
test(`login: ${caso.nome}`, async ({ page }) => {
await login(page, caso.email, caso.password)
await validarResultadoLogin(page, caso.esperado)
})
}
O híbrido funciona bem quando a mistura é intencional. O risco é acumular camadas sem padrão claro.
Evite isso documentando decisões como:
- quando usar teste modular puro;
- quando usar dados externos;
- quando criar uma nova palavra-chave;
- quando escrever cenários BDD;
- onde ficam fixtures, helpers e dados.
Um framework híbrido deve reduzir complexidade operacional, não apenas adicionar abstrações.
6. Baseado em comportamento: BDD
Um framework BDD expressa testes em linguagem próxima da natural usando o padrão Dado-Quando-Então (Given-When-Then), geralmente em Gherkin.
Exemplo:
Funcionalidade: Login
Cenário: Usuário acessa o painel com credenciais válidas
Dado que existe um usuário registrado
Quando ele envia credenciais válidas
Então ele deve acessar o painel
Cada passo precisa de uma implementação:
Given('que existe um usuário registrado', async function () {
// criar ou buscar usuário de teste
})
When('ele envia credenciais válidas', async function () {
// executar login
})
Then('ele deve acessar o painel', async function () {
// validar resultado
})
O principal benefício do BDD é criar entendimento compartilhado entre produto, QA e engenharia. A especificação vira algo que todos conseguem ler.
Use BDD quando:
- requisitos são frequentemente mal interpretados;
- produto ou negócio realmente revisam os cenários;
- os testes também servem como documentação executável;
- a clareza do comportamento importa mais do que a velocidade de escrita.
Evite BDD quando apenas desenvolvedores leem os testes. Nesse caso, você paga o custo de manter Gherkin e definições de passo sem capturar o principal benefício. Para APIs, este guia Gherkin para testes de API BDD mostra o padrão aplicado na prática.
Comparando os tipos de framework
| Tipo de framework | Reutilização | Não-programadores podem criar | Custo de configuração | Escalabilidade |
|---|---|---|---|---|
| Linear | Nenhuma | Sim, via gravação | Muito baixo | Ruim |
| Modular | Alta | Não | Médio | Boa |
| Baseado em dados | Média | Parcialmente | Médio | Boa para entradas |
| Baseado em palavras-chave | Alta | Sim | Alto | Boa |
| Híbrido | Alta | Às vezes | Alto | Muito boa |
| BDD | Alta | Sim, para ler e criar | Alto | Boa |
O padrão é simples: quanto menor o custo inicial, pior tende a ser a escalabilidade. E quanto mais você quer incluir não-programadores na criação dos testes, mais investimento técnico será necessário na infraestrutura.
Erros comuns ao escolher um framework
1. Abstrair cedo demais
Criar um framework keyword-driven ou híbrido para uma suíte com quinze testes pode ser exagero. A camada de abstração pode custar mais do que os testes que ela deveria simplificar.
Sinal de alerta:
- muitos helpers criados antes de haver duplicação real;
- palavras-chave que são usadas uma única vez;
- documentação do framework maior que a suíte.
Regra prática: deixe a duplicação real justificar a próxima camada de abstração.
2. Permanecer linear por tempo demais
O erro oposto também é comum. Uma suíte começa com vinte scripts gravados e continua linear quando chega a quatrocentos testes.
Sinal de alerta:
- uma mudança de produto exige editar muitos arquivos;
- os mesmos passos aparecem copiados em vários testes;
- correções simples levam horas;
- ninguém quer mexer nos testes antigos.
Quando isso acontecer, extraia funções reutilizáveis e migre para uma estrutura modular antes que a manutenção vire rotina.
3. Escolher um tipo para um público que não participa
BDD só compensa se pessoas fora da engenharia realmente leem ou escrevem os cenários.
Keyword-driven só compensa se analistas ou usuários técnicos realmente montam testes com palavras-chave.
Se apenas desenvolvedores mantêm a suíte, uma estrutura modular ou híbrida simples pode ser mais eficiente.
Como escolher um tipo de framework
Use critérios práticos.
1. Tamanho e vida útil da suíte
- Teste descartável: linear pode bastar.
- Suíte mantida por meses: modular, no mínimo.
- Suíte grande e crítica: híbrido provavelmente será necessário.
2. Quem escreve os testes
- Apenas engenharia: modular ou híbrido.
- QA técnico + engenharia: modular com dados externos.
- QA não-programador ou negócio: keyword-driven ou BDD.
3. Variação de dados
Se o fluxo é estável, mas os dados variam muito, use data-driven.
Exemplos:
- cálculo de frete;
- regras de desconto;
- permissões por perfil;
- validação de payloads;
- limites de campos.
4. Problemas de comunicação
Se produto, QA e engenharia interpretam requisitos de formas diferentes, BDD pode ajudar porque força uma especificação compartilhada.
5. Habilidades da equipe
O melhor framework é aquele que sua equipe consegue manter. Uma arquitetura sofisticada que ninguém entende falha mais rápido do que uma estrutura simples e bem aplicada.
Na prática, muitas equipes terminam com um híbrido:
- modular como base;
- data-driven para casos com muitas combinações;
- BDD onde a colaboração com produto é importante;
- palavras-chave quando não-programadores precisam montar testes.
Comece simples. Adicione estrutura quando a dor real aparecer. Para estratégias além do tipo de framework, a distinção entre cenário de teste versus caso de teste ajuda a definir o escopo correto de cada teste.
Onde uma plataforma ajuda
Escolher o tipo de framework é uma decisão de arquitetura. Executá-lo bem depende das ferramentas.
Para testes de API, o Apidog oferece suporte à reutilização modular por meio de requisições compartilhadas e parametrizadas, execuções data-driven com CSV e JSON, e um construtor visual de testes que permite a não-programadores montar testes. Isso representa o espírito de uma estrutura keyword-driven sem exigir que a equipe crie manualmente uma biblioteca própria de palavras-chave.
Isso importa porque um framework só funciona se a equipe consegue segui-lo de forma consistente. Uma plataforma que já incorpora padrões de organização ajuda a manter a suíte coerente conforme os testes crescem e pessoas entram ou saem do projeto.
Você pode baixar o Apidog para ver esses padrões em uso e decidir quanto código de framework personalizado ainda faz sentido para sua equipe. Em muitos casos, menos do que parece, porque o Apidog já cobre camadas de requisição, dados e relatórios que um framework manual precisaria reimplementar.
Perguntas frequentes
Qual a diferença entre uma ferramenta de automação e um framework de automação de testes?
Uma ferramenta executa testes, como um driver de navegador ou um cliente HTTP. Um framework define a estrutura ao redor dessas ferramentas: organização dos testes, reutilização de lógica, dados, execução e relatórios.
Você pode usar uma ferramenta sem um framework, mas a manutenção tende a ficar difícil conforme a suíte cresce.
Qual o melhor tipo de framework de automação de testes?
Não existe um melhor universal.
- Linear: bom para scripts descartáveis.
- Modular: boa base para a maioria das equipes técnicas.
- Data-driven: ideal para muitas variações de entrada.
- Keyword-driven: útil quando não-programadores criam testes.
- BDD: útil quando produto, QA e engenharia precisam compartilhar especificações.
- Híbrido: comum em suítes grandes e maduras.
Escolha com base na equipe, no tempo de vida da suíte e no custo de manutenção esperado.
O BDD é apenas para testes de API ou apenas para testes de UI?
Não. BDD é um padrão estrutural, não uma camada de teste. O formato Dado-Quando-Então pode ser usado em testes unitários, de API ou de UI.
O requisito principal é o público: BDD faz mais sentido quando pessoas fora da engenharia leem ou escrevem os cenários.
Posso mudar o tipo de framework depois que a suíte já existe?
Sim, mas o custo aumenta com o tamanho da suíte.
Migrar de linear para modular significa extrair funções reutilizáveis de scripts repetidos. Migrar para data-driven exige separar dados da lógica. Migrar para BDD exige criar cenários e definições de passo.
Por isso, vale escolher uma estrutura mínima que consiga escalar desde o início.
Projetos pequenos precisam de um framework?
Um projeto realmente curto pode usar um script linear sem grande estrutura. Mas projetos pequenos frequentemente crescem.
Se a suíte vai durar mais do que algumas semanas ou será mantida por mais de uma pessoa, uma estrutura modular leve geralmente já compensa.
Top comments (0)