Aprender / Glossário
Glossário de testes de software
Definições em linguagem simples dos termos que QAs e SDETs usam todos os dias, cada uma com um exemplo e links para as aulas, labs e perguntas de entrevista sobre o assunto.
77 termos · Fundamentos de testes 26 · Projeto de testes 5 · Automação de UI 18 · Testes de API 8 · CI/CD e DevOps 5 · Performance 5 · Segurança 4 · IA em testes 6
Fundamentos de testes
- Caso de teste Test case Conjunto de pré-condições, dados de entrada, passos e resultados esperados que verifica um comportamento do sistema e gera um veredito claro de aprovado ou reprovado.
- Cenário de teste Test scenario Declaração de alto nível de um objetivo do usuário ou funcionalidade a testar, como "verificar checkout com cartão salvo", que depois é desdobrada em casos de teste.
- Cobertura de código Code coverage O percentual do código-fonte (linhas, instruções, branches ou funções) executado durante os testes. Mostra o que não foi testado, não o que foi bem testado.
- Critérios de aceitação Acceptance criteria As condições específicas e testáveis que uma história de usuário ou funcionalidade precisa cumprir para ser aceita como concluída pelo product owner.
- Matriz de rastreabilidade de requisitos Requirements traceability matrix Tabela que relaciona cada requisito aos casos de teste que o verificam e aos seus resultados, deixando visíveis as lacunas de cobertura e o impacto das mudanças.
- Oráculo de teste Test oracle A fonte de verdade que um teste usa para decidir se uma saída está correta, como uma especificação, uma versão anterior, um modelo de referência ou uma regra.
- Pirâmide de testes Test pyramid Modelo para equilibrar uma suíte automatizada, com muitos testes unitários rápidos na base, menos testes de integração no meio e poucos testes end-to-end no topo.
- Plano de teste Test plan Documento que define escopo, abordagem, recursos, cronograma, ambientes, riscos e critérios de entrada e saída para testar um release ou projeto.
- Prioridade de bug Bug priority O quão urgente é corrigir um defeito em relação ao restante do trabalho, decidido pela necessidade do negócio; geralmente definida pelo product owner ou na triagem de bugs.
- Severidade de bug Bug severity O tamanho do impacto de um defeito no sistema ou nos usuários, de um crash completo ou perda de dados até um problema apenas cosmético; geralmente definida pelo QA.
- Shift-left testing Trazer as atividades de teste e qualidade para mais cedo no ciclo de entrega, para que os defeitos sejam evitados ou encontrados quando são mais baratos de corrigir.
- Smoke test Smoke testing Verificação rápida e superficial das funções mais críticas de um novo build para decidir se ele está estável o suficiente para receber testes mais profundos.
- Test double (dublê de teste) Test double Qualquer objeto que substitui uma dependência real em um teste, como dummy, stub, fake, spy ou mock, para que o código sob teste rode de forma rápida e previsível.
- Teste baseado em risco Risk-based testing Abordagem que prioriza o esforço de teste pelo risco (probabilidade de falha vezes impacto), para que as áreas mais arriscadas sejam testadas primeiro e mais a fundo.
- Teste caixa-preta Black-box testing Testar um sistema pelas suas entradas e saídas, comparando com os requisitos, sem olhar nem depender do código ou do design interno.
- Teste de aceitação do usuário (UAT) User acceptance testing A fase final de testes, na qual usuários reais ou representantes do negócio confirmam que o sistema atende às suas necessidades e está pronto para ser aceito para o release.
- Teste de caixa branca White-box testing Teste projetado a partir do conhecimento do código interno, como seus branches, condições e caminhos, para garantir que a implementação se comporta corretamente.
- Teste de integração Integration test Um teste que verifica se dois ou mais componentes, como um serviço e seu banco de dados ou duas APIs, funcionam corretamente juntos pelas suas interfaces reais.
- Teste de mutação Mutation testing Técnica que injeta pequenos bugs deliberados (mutantes) no código e roda os testes de novo para medir se a suíte realmente detecta falhas.
- Teste de regressão Regression testing Reexecutar testes existentes após uma mudança para confirmar que o comportamento que já funcionava continua funcionando e que a correção ou feature não quebrou mais nada.
- Teste de sanidade Sanity testing Verificação estreita e focada após uma pequena mudança ou correção de bug para confirmar que a área afetada funciona como esperado antes de seguir com testes mais amplos.
- Teste end-to-end (E2E) End-to-end test Um teste que executa uma jornada completa do usuário no sistema real e totalmente implantado, da UI ou da API pública até o banco de dados e de volta.
- Teste exploratório Exploratory testing Teste em que o tester projeta e executa os testes ao mesmo tempo, usando o que cada resultado revela para decidir o que tentar em seguida.
- Teste flaky (teste instável) Flaky test Um teste que passa e falha no mesmo código sem nenhuma mudança, geralmente por causa de timing, estado compartilhado, ordem dos testes ou um ambiente instável.
- Teste unitário Unit test Teste automatizado que verifica uma pequena parte do código, como uma função ou uma classe, isolada de bancos de dados, rede e outros serviços.
- Verificação e validação Verification and validation A verificação pergunta "estamos construindo o produto corretamente?" contra a especificação. A validação pergunta "estamos construindo o produto certo?" para o usuário.
Projeto de testes
- Análise de valor limite Boundary value analysis Técnica de projeto de teste caixa-preta que escolhe entradas exatamente nas bordas das faixas válidas e logo ao redor delas, onde se concentram os erros de off-by-one.
- Particionamento de equivalência Equivalence partitioning Técnica de projeto de teste que divide as entradas em grupos que o sistema deve tratar da mesma forma e testa um valor representativo de cada grupo.
- Teste de tabela de decisão Decision table testing Técnica de projeto de teste que lista as combinações de condições e a ação que cada uma deve disparar, para que toda regra de negócio tenha um teste.
- Teste de transição de estados State transition testing Técnica de design de testes que modela o sistema como estados e eventos que o levam de um estado a outro, e então testa as transições válidas e inválidas.
- Teste pairwise Pairwise testing Técnica combinatória que seleciona um pequeno conjunto de casos de teste no qual cada par de valores de parâmetros aparece junto pelo menos uma vez.
Automação de UI
- Auto-waiting (espera automática) Auto-waiting Recurso do framework que espera o elemento ficar pronto (visível, estável e habilitado) antes de interagir com ele, em vez de depender de sleeps fixos.
- BDD (Desenvolvimento Orientado a Comportamento) Behavior-Driven Development Prática colaborativa em que negócio, desenvolvimento e teste combinam o comportamento por meio de exemplos concretos, muitas vezes escritos em Gherkin e automatizados.
- Espera explícita (explicit wait) Explicit wait Uma espera que verifica repetidamente uma condição específica, como um elemento ficar clicável, até um timeout. No Selenium ela é escrita com WebDriverWait.
- Espera implícita (implicit wait) Implicit wait Uma configuração global do Selenium que faz toda chamada de findElement continuar procurando por até um tempo definido antes de lançar NoSuchElementException.
- Gherkin A sintaxe em texto simples Given-When-Then (Dado-Quando-Então) usada para escrever cenários BDD em arquivos .feature, executados como testes por ferramentas como o Cucumber.
- Isolamento de testes Test isolation Propriedade de cada teste preparar o próprio estado e conseguir passar sozinho, em qualquer ordem e em paralelo, sem depender de outros testes nem afetá-los.
- Locator A consulta que um teste de UI usa para encontrar um elemento na página, como role e nome, test id, seletor CSS ou expressão XPath.
- Navegador headless Headless browser Um motor de navegador real rodando sem janela visível, usado para executar testes de UI em servidores de CI e em outras máquinas que não têm tela.
- Page Object Model (POM) Page Object Model Padrão de projeto que encapsula cada página ou componente da UI em uma classe, para que os testes chamem métodos de intenção em vez de repetir locators.
- Selenium Grid Servidor do Selenium que direciona sessões WebDriver para nós de navegador remotos, permitindo rodar testes em paralelo em vários navegadores, versões e máquinas.
- Seletor CSS CSS selector Um padrão da linguagem CSS que encontra elementos por tag, id, classe, atributo ou posição, muito usado como locator rápido e legível em testes de UI.
- Sharding de testes Test sharding Dividir uma suíte de testes em fatias, chamadas shards, que rodam em máquinas separadas ao mesmo tempo, para que uma suíte longa termine em uma fração do tempo.
- StaleElementReferenceException Erro do Selenium lançado quando um teste usa um WebElement cujo nó no DOM foi removido ou substituído depois de encontrado, normalmente após uma nova renderização.
- Test fixture A preparação fixa de que um teste precisa antes de rodar, como uma página do navegador, um usuário criado ou um banco de dados, mais o teardown que limpa tudo depois.
- Teste de regressão visual Visual regression testing Comparar screenshots da UI com imagens de referência aprovadas para pegar mudanças visuais não intencionais, como deslocamentos de layout, estilos ausentes ou sobreposições.
- Teste orientado a dados Data-driven testing Executar a mesma lógica de teste com vários conjuntos de entradas e saídas esperadas, mantidos em uma tabela, arquivo ou fonte de dados em vez de copiados em cada teste.
- Web-first assertion Assertion do Playwright que recebe um locator e tenta de novo até a condição esperada ser atendida ou o timeout expirar, em vez de verificar um valor uma única vez.
- XPath Linguagem de consulta para selecionar nós em um documento XML ou HTML, usada na automação de UI para localizar elementos por estrutura, atributos ou texto.
Testes de API
- API REST REST API API HTTP organizada em torno de recursos identificados por URLs, manipulados com métodos padrão como GET, POST, PUT, PATCH e DELETE, com requisições stateless.
- Código de status HTTP HTTP status code O número de três dígitos presente em toda resposta HTTP que indica se a requisição deu certo, foi redirecionada ou falhou por causa do cliente ou do servidor.
- Idempotência Idempotency A propriedade de que enviar a mesma requisição uma ou várias vezes deixa o servidor no mesmo estado. GET, PUT e DELETE são idempotentes; POST não é.
- JSON Schema Um vocabulário JSON para descrever a estrutura esperada de dados JSON, incluindo tipos, campos obrigatórios e formatos, usado para validar respostas de API.
- JWT (JSON Web Token) JWT Um JSON Web Token é um token compacto e assinado no formato header.payload.signature que carrega claims como id do usuário, expiração e audiência.
- OAuth 2.0 Framework de autorização que permite a uma aplicação obter um access token limitado para chamar uma API em nome de um usuário ou de si mesma, sem lidar com senhas.
- Rate limiting Limitar quantas requisições um cliente pode fazer a uma API em uma janela de tempo, rejeitando o excesso, normalmente com 429 Too Many Requests e um header Retry-After.
- Teste de contrato Contract testing Verificar que um provedor de API e seus consumidores concordam sobre as requisições e respostas que trocam, sem precisar subir os dois juntos para um teste end-to-end.
CI/CD e DevOps
- Container Docker Docker container Uma instância isolada e em execução de uma imagem Docker, que empacota uma aplicação ou serviço com suas dependências para se comportar igual no notebook e na CI.
- Feature flag Um interruptor em tempo de execução que liga ou desliga um trecho de código sem deploy, permitindo publicar trabalho inacabado desligado, liberar aos poucos e reverter rápido.
- Integração contínua (CI) Continuous integration A prática de integrar pequenas mudanças a uma branch compartilhada com frequência, com build e testes automáticos a cada push para que as quebras apareçam em minutos.
- Quality gate Verificação automática de aprovado/reprovado em um pipeline, como testes passando ou cobertura acima de um limite, que precisa ser atendida antes do merge ou do release.
- Testcontainers Biblioteca que sobe dependências reais, como bancos de dados, brokers ou navegadores, em containers Docker descartáveis a partir do código de teste e depois os remove.
Performance
- Latência por percentil Percentile latency Medida de tempo de resposta, como p95 ou p99, que mostra em quanto tempo essa fração das requisições terminou e revela a cauda lenta que as médias escondem.
- Soak test (teste de resistência) Soak testing Teste de performance que mantém uma carga normal e realista por muitas horas para expor problemas que só se acumulam com o tempo, como vazamentos de memória.
- Teste de carga Load testing Teste de performance que submete o sistema ao tráfego real esperado para verificar tempos de resposta, taxa de erros e throughput contra metas acordadas.
- Teste de estresse Stress testing Teste de performance que leva a carga além do esperado para encontrar o ponto de ruptura, ver como o sistema falha e verificar se ele se recupera depois.
- Throughput (vazão) Throughput A quantidade de trabalho que um sistema conclui por unidade de tempo, normalmente requisições ou transações por segundo, medida junto com a latência e a taxa de erros.
Segurança
- Cross-site scripting (XSS) Cross-site scripting XSS é uma vulnerabilidade em que uma entrada não confiável é renderizada como script executável no navegador de outro usuário, permitindo que o atacante aja como ele.
- IDOR Insecure Direct Object Reference, falha de controle de acesso em que trocar um ID na requisição permite ler ou alterar os dados de outro usuário.
- OWASP Top 10 Lista de conscientização da OWASP com as dez categorias de risco de segurança mais críticas em aplicações web, muito usada para definir o escopo de testes de segurança.
- SQL injection Vulnerabilidade em que a entrada do usuário é concatenada em uma query SQL, permitindo que um atacante mude a lógica da query para ler, alterar ou apagar dados.
IA em testes
- Avaliação de LLM (LLM evals) LLM evaluation Medir sistematicamente a qualidade de uma funcionalidade com LLM em um conjunto fixo de entradas e critérios, já que as saídas variam e asserções exatas raramente servem.
- Golden dataset (conjunto de referência) Golden dataset Um conjunto curado e versionado de entradas com saídas esperadas verificadas, usado como benchmark fixo para testes de regressão de modelos, prompts ou pipelines.
- LLM-as-judge (LLM como juiz) LLM-as-judge Usar um modelo de linguagem com uma rubrica escrita para avaliar as saídas de outro modelo, um substituto escalável, porém enviesado, da revisão humana em avaliação de LLMs.
- Model Context Protocol (MCP) Model Context Protocol O MCP é um protocolo aberto para conectar assistentes e agentes de IA a ferramentas e dados externos, como um navegador, um repositório ou um sistema de gestão de testes.
- Prompt injection Ataque em que um texto fornecido a um LLM, diretamente pelo usuário ou escondido em conteúdo que ele lê, sobrepõe as instruções do desenvolvedor e muda seu comportamento.
- Self-healing locator Locator que, ao deixar de encontrar o elemento, faz a ferramenta escolher um substituto provável a partir de atributos salvos ou de um modelo e seguir com o teste.