A arquitetura cliente–servidor é um modelo em que uma parte do sistema solicita dados ou uma ação e outra parte os fornece. O cliente inicia uma requisição; o servidor a processa e retorna um resultado.
Parece simples, mas é um dos modelos fundamentais para QA. Quando você passa a enxergar o produto dessa forma, muitos bugs deixam de parecer “comportamentos estranhos da interface” e se tornam pontos de falha identificáveis: cliente, rede, servidor, banco de dados, integração externa, cache, fila ou autorização.
Como funciona
Em um produto web ou móvel típico, o cliente é um navegador, aplicativo móvel ou outro serviço. O usuário clica em um botão, e o cliente coleta dados e envia uma requisição. O servidor a recebe, verifica permissões, valida a entrada, executa a lógica de negócio e, se necessário, acessa um banco de dados ou sistemas externos.
- →Um cliente pode ser um navegador, aplicativo móvel, outro serviço ou parceiro externo.
- →O servidor nem sempre é um único processo ou um monólito.
- →Gateways, balanceadores de carga, caches, filas, bancos de dados e integrações externas frequentemente ficam no caminho entre cliente e servidor.
Assim, um único clique do usuário pode disparar toda uma sequência de ações, em vez de uma única operação.
Um exemplo simples
Um usuário clica em “Pagar pedido”. O cliente envia uma requisição com ID do pedido, valor e dados do usuário. O servidor verifica se o pedido existe, se o usuário pode pagá-lo e se o status atual permite o pagamento. Depois, chama o provedor de pagamento, salva o resultado e retorna uma resposta ao cliente.
O usuário vê apenas o botão e a mensagem final. QA precisa enxergar toda a sequência. Caso contrário, é fácil identificar incorretamente a causa de um defeito.
O que QA precisa verificar
- →Se uma requisição foi realmente enviada.
- →Exatamente qual requisição foi enviada.
- →O que o servidor retornou.
- →Como o cliente interpretou a resposta.
- →Se os dados mudaram em todos os lugares onde deveriam mudar.
- →Se há um serviço externo ou um ambiente instável envolvido.
Se a interface mostra um valor incorreto, há várias causas possíveis: o servidor retornou o valor errado, o banco contém dados incorretos, um serviço externo retornou uma resposta inesperada ou o cliente exibiu incorretamente uma resposta correta. O sintoma visível é o mesmo, mas os pontos de falha são diferentes.
As camadas mais frequentemente testadas
- →Camada do cliente: se a requisição foi enviada, os parâmetros foram montados corretamente e o resultado foi exibido corretamente.
- →Camada do servidor: se validação, controle de acesso e lógica de negócio funcionaram corretamente.
- →Camada de dados: se os dados foram criados, atualizados ou excluídos conforme esperado.
- →Camada de integração: como o sistema trata falhas, timeouts e respostas inesperadas de serviços externos.
Onde isso ajuda na prática
Primeiro, na investigação de defeitos. Um testador que vê apenas a tela escreve “não funciona”. Quem entende a arquitetura escreve: a requisição continha um parâmetro incorreto; o servidor retornou 403 embora o papel devesse ter acesso; o banco de dados não foi atualizado. É um padrão de relato muito melhor.
Segundo, no projeto de testes. Entender as camadas envolvidas em um cenário ajuda a criar verificações melhores: caminho feliz da interface, erros de rede, requisições repetidas, falhas parciais, dados inconsistentes e problemas de integração.
Terceiro, na comunicação da equipe. Esse modelo ajuda a ser específico: o problema está no cliente, servidor, dados ou provedor externo. Isso economiza tempo e facilita a triagem.
Principais conclusões para QA
- →Uma ação do usuário frequentemente envolve várias etapas técnicas.
- →O mesmo bug visível na interface pode se originar em diferentes camadas do sistema.
- →Para isolar um problema, examine requisição, resposta, dados e dependências, além da tela.
- →Entender a arquitetura cliente–servidor torna relatos de bugs mais precisos e acelera investigações.
Leitura adicional
- →Nesta base de conhecimento: O que é uma API? — uma introdução à interface usada na comunicação.
- →Nesta base de conhecimento: HTTP e HTTPS — para compreender melhor a camada de transporte de requisições e respostas.
- →Nesta base de conhecimento: Métodos, códigos de status e cabeçalhos — para interpretar sinais técnicos de APIs com mais confiança.
Acompanhe uma ação do navegador ao armazenamento
Cenário fictício: um estudante salva o nome de exibição do perfil. O resultado esperado é que uma consulta posterior mostre o novo nome para a mesma conta autorizada. Um toast de sucesso comprova apenas que o cliente mostrou uma mensagem; não estabelece o estado armazenado.
Camada Observação O que pode comprovar
Navegador Ação, entrada, payload e tempo da requisição O que o cliente realmente enviou
Rede/API Método, URL, status, corpo, ID de correlação A resposta observada da API
Logs do serviço Mesmo ID de correlação e resultado de validação Qual caminho do servidor tratou a requisição, se houver logs disponíveis
Armazenamento Leitura de teste autorizada do registro-alvo Valor persistido no momento observado
Consulta posterior à API Resposta GET para a mesma conta Se o caminho de leitura expõe o valor salvoUse uma leitura de teste autorizada ou uma massa de dados preparada, em vez de presumir que há acesso ao banco. Em sistemas assíncronos, a consistência imediata pode não ser garantida: combine primeiro o sinal de conclusão e a janela de tempo. Se o navegador tiver timeout após enviar uma gravação, inspecione o resultado antes de repetir. O servidor pode já tê-la confirmado.
Para isolar uma falha, compare observações adjacentes. Dados incorretos na requisição apontam para a preparação no cliente; uma requisição correta com erro de validação documentado aponta para a interpretação do contrato ou da entrada; uma resposta de sucesso com dados ausentes exige investigar o caminho de gravação ou um fluxo assíncrono. Essas são direções de investigação, não causas comprovadas. Preserve horários e IDs de correlação e remova segredos das evidências.