Modelagem de cenários CRUD para usuários e pedidos

O que significa modelar cenários CRUD para usuários e pedidos

Modelar cenários CRUD é transformar regras de negócio e fluxos de uso da API em um conjunto organizado de requisições e verificações que cubram Create, Read, Update e Delete. Em APIs que lidam com usuários e pedidos, o CRUD raramente é “reto”: pedidos dependem de usuários, existem estados (rascunho, pago, cancelado), e há validações (campos obrigatórios, permissões, consistência de dados). A modelagem serve para garantir que os testes não sejam apenas uma lista de chamadas, mas sim uma sequência coerente que cria dados, reutiliza identificadores, valida regras e limpa o ambiente ao final.

Na prática, você vai desenhar cenários que respondem a perguntas como: “Consigo criar um usuário válido?”, “Consigo buscar esse usuário?”, “Consigo atualizar apenas parte dos dados?”, “O que acontece se eu tentar criar um pedido para um usuário inexistente?”, “Posso cancelar um pedido pago?”, “Ao deletar um usuário, o que acontece com seus pedidos?”. A partir dessas perguntas, você define coleções, pastas, variáveis e scripts no Postman para automatizar o ciclo completo.

Entidades, relacionamentos e pré-condições

Antes de escrever requisições, defina as entidades e como elas se relacionam. Um modelo comum é: Usuário (id, nome, email, status) e Pedido (id, userId, itens, total, status). O relacionamento típico é 1:N: um usuário pode ter vários pedidos. Isso cria uma pré-condição importante: para testar pedidos, você quase sempre precisa de um usuário existente, ou precisa simular o caso de erro quando o usuário não existe.

Na modelagem, separe cenários em três grupos: caminho feliz (operações válidas), validações (campos obrigatórios, formatos, limites) e regras de estado (transições permitidas e proibidas). Para pedidos, regras de estado costumam ser o coração do teste: por exemplo, “pedido cancelado não pode ser pago”, “pedido pago não pode ser alterado em itens”, “pedido entregue não pode ser cancelado”.

Estrutura recomendada de coleção no Postman

Uma forma prática de organizar é criar uma coleção com pastas que reflitam o domínio e o ciclo de vida dos dados. Exemplo de estrutura:

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

• 00 - Setup: criar usuário base, autenticar (se aplicável), preparar dados.
• 10 - Users CRUD: criar, listar, buscar por id, atualizar, deletar.
• 20 - Orders CRUD: criar pedido, listar, buscar por id, atualizar, cancelar/deletar.
• 30 - Negative & Validation: casos inválidos para usuários e pedidos.
• 99 - Teardown: limpeza (deletar pedido e usuário criados).

Essa estrutura facilita rodar a coleção inteira no Collection Runner e também executar apenas uma parte quando estiver depurando um fluxo específico. O “Setup” e o “Teardown” ajudam a manter o ambiente limpo e reduzem flakiness (testes que falham por dados antigos).

Definindo variáveis para encadear o CRUD

Para modelar cenários encadeados, você precisa capturar IDs e reutilizá-los. Em vez de “hardcode” (colocar valores fixos), use variáveis. Um conjunto mínimo para este capítulo:

• {{baseUrl}}: URL base da API.
• {{userId}}: id do usuário criado no cenário.
• {{orderId}}: id do pedido criado no cenário.
• {{userEmail}}: email usado para criar o usuário (útil para buscas e validações).
• {{authToken}}: token de autenticação, se a API exigir.

Na modelagem, pense em variáveis como “pontes” entre requisições. O Create gera um id; o Read usa esse id; o Update valida mudanças; o Delete remove o registro. Para pedidos, o Create também depende do userId. Esse encadeamento é o que transforma um conjunto de requisições em um cenário CRUD completo.

Cenário CRUD de Usuários: caminho feliz

1) Create User (criar usuário)

Objetivo: criar um usuário com dados válidos e capturar o id retornado para uso nas próximas etapas. Exemplo de endpoint: POST {{baseUrl}}/users. Corpo (exemplo):

{  "name": "{{randomName}}",  "email": "{{userEmail}}",  "status": "active"}

Passo a passo prático no Postman: (1) Antes de enviar, gere um email único para evitar conflito de duplicidade. (2) Envie a requisição. (3) No script de testes, valide que o id veio preenchido e salve em variável.

pm.test("Status esperado", function () {  pm.response.to.have.status(201);});const body = pm.response.json();pm.test("Retorna id", function () {  pm.expect(body.id).to.exist;});pm.collectionVariables.set("userId", body.id);pm.collectionVariables.set("userEmail", body.email);

Observação de modelagem: se a API retorna o usuário completo, valide também campos importantes (email, status). Se retorna apenas o id, ajuste o teste para o contrato real.

2) Read User (buscar usuário por id)

Objetivo: garantir que o usuário criado pode ser recuperado e que os dados persistiram. Endpoint: GET {{baseUrl}}/users/{{userId}}. No teste, valide que o id do retorno é o mesmo e que o email bate com a variável.

pm.test("Status esperado", function () {  pm.response.to.have.status(200);});const body = pm.response.json();pm.test("Id consistente", function () {  pm.expect(body.id).to.eql(pm.collectionVariables.get("userId"));});pm.test("Email consistente", function () {  pm.expect(body.email).to.eql(pm.collectionVariables.get("userEmail"));});

Na modelagem, esse passo também serve para detectar problemas de consistência eventual. Se a API for assíncrona e o dado demorar a aparecer, você pode precisar de retry controlado, mas só implemente isso se o comportamento for conhecido e justificável.

3) Update User (atualizar usuário)

Objetivo: alterar um campo e validar que a mudança foi aplicada. Endpoint típico: PUT ou PATCH {{baseUrl}}/users/{{userId}}. Exemplo de atualização parcial (PATCH):

{  "name": "{{randomNameUpdated}}"}

Passo a passo prático: (1) Defina um novo nome em variável. (2) Envie o PATCH. (3) Valide status e, se a resposta trouxer o recurso, valide o campo. (4) Faça um GET novamente para confirmar persistência.

pm.test("Status esperado", function () {  pm.response.to.have.status(200);});const body = pm.response.json();if (body.name) {  pm.test("Nome atualizado", function () {    pm.expect(body.name).to.eql(pm.collectionVariables.get("randomNameUpdated"));  });}

Na modelagem, prefira atualizar um campo por vez quando estiver validando regras específicas. Para testes de regressão mais amplos, você pode ter um caso adicional que atualiza múltiplos campos.

4) Delete User (deletar usuário)

Objetivo: remover o usuário e validar que ele não é mais acessível. Endpoint: DELETE {{baseUrl}}/users/{{userId}}. Após deletar, execute um GET e espere “não encontrado”.

pm.test("Status esperado ao deletar", function () {  pm.expect([200, 202, 204]).to.include(pm.response.code);});

Teste do “read after delete” (em uma requisição separada):

pm.test("Usuário não encontrado", function () {  pm.expect([404, 410]).to.include(pm.response.code);});

Na modelagem, registre quais códigos a API usa (404 vs 410) e padronize a expectativa. Se a API usa soft delete (marca como inativo), o cenário muda: em vez de esperar 404, você valida status “inactive” e regras de acesso.

Cenário CRUD de Pedidos: dependência de usuário e regras de estado

1) Create Order (criar pedido para um usuário)

Objetivo: criar um pedido associado ao usuário criado no Setup ou no CRUD de usuários. Endpoint: POST {{baseUrl}}/orders. Exemplo de corpo:

{  "userId": "{{userId}}",  "items": [    { "sku": "SKU-001", "quantity": 2, "unitPrice": 10.5 },    { "sku": "SKU-002", "quantity": 1, "unitPrice": 25.0 }  ],  "currency": "BRL"}

Passo a passo prático: (1) Garanta que {{userId}} existe. (2) Envie o POST. (3) Capture {{orderId}}. (4) Valide total e status inicial, se fizer parte do contrato (por exemplo, “created” ou “pending”).

pm.test("Status esperado", function () {  pm.response.to.have.status(201);});const body = pm.response.json();pm.collectionVariables.set("orderId", body.id);pm.test("Pedido associado ao usuário", function () {  pm.expect(body.userId).to.eql(pm.collectionVariables.get("userId"));});

Se a API calcula o total, valide a regra: soma de quantity * unitPrice. Se o total não vier na resposta, valide via GET do pedido.

2) Read Order (buscar pedido por id)

Objetivo: confirmar persistência e integridade dos itens. Endpoint: GET {{baseUrl}}/orders/{{orderId}}. Valide id, userId, itens e status.

pm.test("Status esperado", function () {  pm.response.to.have.status(200);});const body = pm.response.json();pm.test("Id do pedido consistente", function () {  pm.expect(body.id).to.eql(pm.collectionVariables.get("orderId"));});pm.test("userId consistente", function () {  pm.expect(body.userId).to.eql(pm.collectionVariables.get("userId"));});pm.test("Itens não vazios", function () {  pm.expect(body.items).to.be.an("array");  pm.expect(body.items.length).to.be.above(0);});

Na modelagem, esse passo também é onde você valida “contrato mínimo”: campos obrigatórios presentes, tipos coerentes e ausência de dados sensíveis indevidos (por exemplo, não retornar senha no usuário, não retornar dados de pagamento completos no pedido).

3) Update Order (atualizar pedido)

Objetivo: validar o que pode e o que não pode ser alterado. Aqui a modelagem precisa refletir regras reais. Exemplos comuns: permitir atualizar endereço de entrega enquanto o pedido está “pending”, permitir alterar itens apenas antes do pagamento, proibir alterações após “paid”. Supondo que o pedido esteja em “pending”, um PATCH poderia atualizar itens:

{  "items": [    { "sku": "SKU-001", "quantity": 1, "unitPrice": 10.5 },    { "sku": "SKU-003", "quantity": 2, "unitPrice": 7.0 }  ]}

Passo a passo prático: (1) Faça GET do pedido e guarde o status atual em variável, se necessário. (2) Envie PATCH. (3) Valide resposta e faça GET novamente para confirmar persistência. (4) Se houver regra de recalcular total, valide o novo total.

pm.test("Status esperado", function () {  pm.expect([200, 204]).to.include(pm.response.code);});

Se a API retornar 409 (conflito) ou 422 (regra de negócio) quando a alteração não é permitida, isso vira um cenário negativo separado, não um erro do teste.

4) Delete/Cancel Order (remover ou cancelar pedido)

Pedidos nem sempre são deletados; muitas APIs usam cancelamento para manter histórico. Na modelagem, trate “Delete” como “encerrar o ciclo” do pedido, seja via DELETE, seja via endpoint de cancelamento. Exemplo: POST {{baseUrl}}/orders/{{orderId}}/cancel ou PATCH alterando status para “canceled”.

Passo a passo prático: (1) Cancele o pedido. (2) Faça GET e valide status “canceled”. (3) Tente atualizar itens e espere falha (regra de estado).

pm.test("Cancelamento aplicado", function () {  pm.expect([200, 204]).to.include(pm.response.code);});

Em seguida, no GET:

const body = pm.response.json();pm.test("Status cancelado", function () {  pm.expect(body.status).to.eql("canceled");});

Modelando cenários negativos e de validação (usuários e pedidos)

Além do caminho feliz, a qualidade do CRUD depende de cobrir entradas inválidas e regras de integridade. Em vez de misturar com o fluxo principal, crie uma pasta “Negative & Validation” com casos independentes e dados controlados. Alguns exemplos essenciais:

• Criar usuário com email inválido: esperar erro de validação (400/422) e mensagem de campo.
• Criar usuário com email duplicado: esperar conflito (409) ou validação (422), conforme contrato.
• Buscar usuário inexistente: GET /users/{id} com id aleatório e esperar 404.
• Criar pedido com userId inexistente: esperar 404 (recurso relacionado não encontrado) ou 422 (regra de negócio).
• Criar pedido sem itens: esperar 400/422.
• Atualizar pedido em status proibido: por exemplo, tentar alterar itens após “paid” e esperar 409/422.

Para ids inexistentes, evite usar “999” fixo se a API pode ter esse id. Prefira gerar um UUID ou um número grande aleatório e armazenar em variável apenas para aquele teste.

Passo a passo: encadeando o fluxo completo Users + Orders no Runner

1) Preparar dados dinâmicos no Pre-request Script

Para evitar colisões e tornar o cenário repetível, gere dados dinâmicos. Exemplo: gerar email único e nomes aleatórios simples. No nível da requisição “Create User” ou no nível da coleção:

function randomString(prefix) {  return prefix + Math.random().toString(16).slice(2);}const email = randomString("user_") + "@example.com";pm.collectionVariables.set("userEmail", email);pm.collectionVariables.set("randomName", randomString("Name_"));pm.collectionVariables.set("randomNameUpdated", randomString("NameUpd_"));

Na modelagem, mantenha a geração de dados previsível o suficiente para depuração (prefixos ajudam a identificar registros criados pelo teste no backend).

2) Capturar IDs e propagar para as próximas requisições

Após criar usuário e pedido, salve os ids em variáveis de coleção. Isso permite rodar o fluxo no Runner sem intervenção manual. Garanta que cada captura tenha um teste que falhe claramente se o id não vier, para evitar cascata de falhas em requisições seguintes.

const body = pm.response.json();pm.test("id retornado", function () {  pm.expect(body.id, "id ausente na resposta").to.exist;});pm.collectionVariables.set("userId", body.id);

3) Validar consistência com GET após UPDATE

Um padrão robusto de modelagem é: após qualquer atualização, faça um GET e valide a persistência. Isso separa “resposta do endpoint de update” de “estado real do recurso”. Para reduzir tempo de execução, você pode aplicar esse padrão apenas em cenários críticos, mas para um CRUD base ele é bastante útil.

4) Limpeza (Teardown) para manter o ambiente estável

Ao final, remova os dados criados. A ordem importa: se pedidos dependem do usuário, delete/cancele pedidos antes de deletar o usuário. Se a API impede deletar usuário com pedidos ativos, isso também vira um cenário de regra de negócio: tentar deletar e esperar erro, depois cancelar pedidos e tentar novamente.

Exemplo de ordem de teardown:

• Cancelar/deletar pedido (se existir {{orderId}}).
• Deletar usuário (se existir {{userId}}).

No Postman, você pode colocar lógica simples para não falhar caso a variável esteja vazia (por exemplo, se um teste anterior falhou e não criou o recurso). Em vez de “pular” requisições automaticamente, prefira tornar o teardown tolerante a 404, pois o objetivo é limpar.

Checklist de modelagem para CRUD de usuários e pedidos

Use este checklist para avaliar se seu conjunto de cenários está bem modelado:

• Encadeamento: Create salva id; Read/Update/Delete usam o id via variável.
• Independência dos negativos: cenários inválidos não dependem do caminho feliz.
• Regras de estado: pedidos têm testes explícitos para transições permitidas e proibidas.
• Validação de contrato: campos obrigatórios, tipos e consistência (userId do pedido existe e bate).
• Repetibilidade: dados dinâmicos evitam duplicidade e permitem reexecução.
• Limpeza: teardown remove ou cancela recursos criados, respeitando dependências.