Como limpar o cache do navegador no Mac para testes de QA: a escada de reset
Como limpar o cache do navegador no Mac para testes de QA: a escada de reset
Resposta rápida: Para limpar o cache do navegador no Mac em testes de QA, suba a escada do reset mais leve ao mais pesado: recarregamento forçado, «Disable cache» nas DevTools, exclusão dos dados do site (cookies, armazenamento, service workers) e, por fim, um perfil descartável novinho. Apagar as pastas de cache no disco só resolve arquivos desatualizados. Isso não zera logins nem o estado do app.
Você abre um bug. O desenvolvedor responde: «Na minha máquina funciona.» Você testa de novo e, de repente, funciona na sua também. Nada mudou, exceto que o navegador entregou, sem avisar, uma cópia nova de um arquivo que estava guardando.
O trabalho de QA no Mac tem um problema específico com caches: você precisa saber exatamente contra qual camada de estado armazenado está testando. «Limpe o cache» é uma instrução grosseira demais para isso. Este guia divide o estado armazenado do navegador em camadas e indica, para cada uma, o menor reset que funciona.
O que está realmente travado? Relacione o sintoma à camada certa
Os navegadores guardam vários tipos de estado, e «o cache» é só um deles.
Sintoma Camada provável Correção mais leve CSS/JS antigos depois de um deploy Cache HTTP Recarregamento forçado As alterações não aparecem, mas só na janela normal Cache HTTP ou service worker DevTools com cache desativado e, depois, cancelar o registro do service worker Você continua logado como o usuário errado Cookies / armazenamento Limpar os dados do site daquela origem Feature flag ou estado de onboarding não reseta localStorage / IndexedDB Limpar os dados do site O app funciona offline quando não deveria Service worker + Cache Storage Cancelar o registro do service worker e limpar os dados do site O bug não reproduz na máquina de um colega Estado acumulado no perfil Perfil novo
Comece pelo topo da escada e só desça se o problema persistir. Cada degrau a mais joga fora mais estado que talvez você precise para reproduzir o bug.
Degrau 1: recarregamento forçado (segundos, sem perda de dados)
Um recarregamento forçado ignora o cache no carregamento atual da página.
Chrome, Edge, Firefox: ??R Safari: ??R («Recarregar a partir da origem»)
Isso resolve a reclamação mais comum de «build antigo». Não mexe em cookies, armazenamento nem service workers, e vale só para aquele carregamento, então recursos pedidos depois ainda podem vir do cache.
Degrau 2: faça as DevTools ignorarem o cache enquanto você testa
Se você vai recarregar a tarde inteira, pare de fazer isso na mão.
Chrome/Edge: abra as DevTools ? aba Network ? marque Disable cache. Só vale enquanto as DevTools estiverem abertas. Firefox: DevTools ? Rede ? Desativar cache HTTP (com a caixa de ferramentas aberta). Safari: ative primeiro o menu Desenvolver (Safari ? Ajustes ? Avançado ? «Mostrar recursos para desenvolvedores web»; o texto varia conforme a versão) e depois use Desenvolver ? Desativar caches.
O Chrome também tem um atalho útil: com as DevTools abertas, clique com o botão direito no botão de recarregar e escolha «Esvaziar cache e recarregar à força».
Uma pegadinha em que muita gente cai: «Disable cache» não cancela o registro de service workers. Um service worker pode continuar entregando as próprias respostas armazenadas. Se o degrau 2 não resolver, vá para o 3.
Degrau 3: limpe os dados do site de uma única origem
Apagar tudo raramente é o que você quer. Limitar o reset ao site em teste preserva suas outras sessões (e a sua sanidade).
Chrome/Edge: DevTools ? Application ? Storage ? Clear site data. Antes de clicar, confira o que está marcado: cookies, armazenamento local e de sessão, IndexedDB, Cache Storage e service workers podem ser incluídos ou excluídos individualmente. O painel Service Workers também permite cancelar o registro de um worker diretamente e oferece a opção Update on reload.
Firefox: Ajustes ? Privacidade e Segurança ? Cookies e dados de sites ? Gerenciar dados, e remova o site específico. Como alternativa, use a aba Armazenamento das DevTools.
Safari: Ajustes ? Privacidade ? Gerenciar dados de sites, procure o domínio e remova.
Esse é o reset certo para «preso no usuário errado», feature flags desatualizadas e bugs de modo offline. É também o degrau em que vale anotar o que você limpou, porque «limpei os dados do site» e «limpei só o cache HTTP» podem gerar resultados de teste diferentes.
Degrau 4: perfil descartável (o reset reproduzível)
Quando você precisa provar que um bug não vem do seu próprio estado acumulado, não esfregue o perfil antigo: comece com um limpo.
Opções rápidas:
Uma janela privada/anônima (sem estado persistente, mas as extensões costumam ficar desativadas, o que altera o teste). Um perfil temporário do Chrome pelo Terminal: ? bash open -na « Google Chrome » –args –user-data-dir=/tmp/qa-profile-01
Cada novo caminho gera um perfil zerado, sem cookies, sem cache e sem extensões. Apague a pasta quando terminar ou guarde-a como baseline nomeada para um plano de testes específico.
É a resposta mais limpa para «é o app ou é o meu navegador?». E é a melhor forma de passar a outra pessoa passos de reprodução que partem de um estado conhecido.
Onde o cache fica no disco (e por que vale limpá-lo)
Tudo o que vimos até aqui atua sobre estado gerenciado pelo próprio navegador. À parte disso, as pastas de cache vão se acumulando no disco, o que pesa se você usa vários navegadores e builds de teste o dia todo. Locais típicos dentro da sua pasta Biblioteca de usuário:
Chrome: ~/Library/Caches/Google/Chrome/ Edge: ~/Library/Caches/Microsoft Edge/ Firefox: ~/Library/Caches/Firefox/Profiles/