Rensa webbläsarens cache på Mac för QA-testning: återställningsstegen
Rensa webbläsarens cache på Mac för QA-testning: återställningsstegen
Kort svar: För att rensa webbläsarens cache på Mac i QA-arbete tar du dig uppför stegen från den lättaste till den tyngsta återställningen: hård omladdning, “Disable cache” i DevTools, rensning av webbplatsdata (cookies, lagring, service workers) och till sist en ny engångsprofil. Att radera cachemappar på disken löser bara föråldrade filer. Inloggningar och appens tillstånd återställs inte.
Du rapporterar en bugg. Utvecklaren svarar: “Det funkar hos mig.” Du testar igen och plötsligt funkar det hos dig också. Ingenting har ändrats, förutom att webbläsaren i tysthet hämtat en ny kopia av en fil som den suttit och hållit i.
QA-arbete på Mac har ett särskilt problem med cacher: du måste veta exakt vilket lager av lagrat tillstånd du testar mot. “Rensa cachen” är för grovt för det. Den här guiden delar upp webbläsarens lagrade tillstånd i lager och ger den minsta återställning som fungerar för vart och ett.
Vad är det som faktiskt har fastnat? Matcha symptomet mot rätt lager
Webbläsare lagrar flera sorters tillstånd, och “cachen” är bara en av dem.
Symptom Troligt lager Lättaste åtgärd Gammal CSS/JS efter en deploy HTTP-cache Hård omladdning Ändringarna saknas, men bara i ett vanligt fönster HTTP-cache eller service worker DevTools med avstängd cache, sedan avregistrera service workern Du är fortfarande inloggad som fel användare Cookies / lagring Rensa webbplatsdata för den originen Feature flag eller onboarding-status går inte att återställa localStorage / IndexedDB Rensa webbplatsdata Appen fungerar offline när den inte borde Service worker + Cache Storage Avregistrera service workern, rensa webbplatsdata Buggen går inte att återskapa på en kollegas dator Ackumulerat profiltillstånd Ny profil
Börja högst upp på stegen och gå bara nedåt om problemet kvarstår. Varje extra steg kastar bort mer tillstånd som du kanske behöver för att återskapa buggen.
Steg 1: Hård omladdning (sekunder, ingen data förloras)
En hård omladdning går förbi cachen för den aktuella sidladdningen.
Chrome, Edge, Firefox: ??R Safari: ??R (“Ladda om från ursprung”)
Det löser den vanligaste klagomålet om en “gammal build”. Cookies, lagring och service workers berörs inte, och effekten gäller bara just den laddningen, så resurser som hämtas senare kan fortfarande komma från cachen.
Steg 2: Låt DevTools gå förbi cachen medan du testar
Om du ska ladda om hela eftermiddagen: sluta göra det för hand.
Chrome/Edge: öppna DevTools ? fliken Network ? bocka i Disable cache. Gäller bara så länge DevTools är öppet. Firefox: DevTools ? Nätverk ? Inaktivera HTTP-cache (med verktygslådan öppen). Safari: aktivera först menyn Utveckla (Safari ? Inställningar ? Avancerat ? “Visa funktioner för webbutvecklare”, formuleringen varierar mellan versioner) och använd sedan Utveckla ? Inaktivera cacheminnen.
Chrome har också en smidig genväg: med DevTools öppet, högerklicka på omladdningsknappen och välj “Töm cache och hård omladdning”.
En fälla som många går i: “Disable cache” avregistrerar inte service workers. En service worker kan fortsätta leverera sina egna lagrade svar. Hjälper inte steg 2, gå vidare till steg 3.
Steg 3: Rensa webbplatsdata för en enda origin
Att rensa allt är sällan vad du vill. Begränsar du återställningen till webbplatsen du testar bevaras dina andra sessioner (och ditt förstånd).
Chrome/Edge: DevTools ? Application ? Storage ? Clear site data. Kontrollera innan du klickar vad som är ikryssat: cookies, lokal lagring och sessionslagring, IndexedDB, Cache Storage och service workers kan var och en tas med eller lämnas utanför. Panelen Service Workers låter dig också avregistrera en worker direkt och har alternativet Update on reload.
Firefox: Inställningar ? Integritet och säkerhet ? Cookies och webbplatsdata ? Hantera data, ta sedan bort just den webbplatsen. Alternativt kan du använda fliken Lagring i DevTools.
Safari: Inställningar ? Integritet ? Hantera webbplatsdata, sök efter domänen och ta bort den.
Det här är rätt återställning för “fast som fel användare”, föråldrade feature flags och offline-buggar. Det är också steget där du bör anteckna vad du har rensat, eftersom “jag rensade webbplatsdata” och “jag tömde bara HTTP-cachen” kan ge olika testresultat.
Steg 4: En engångsprofil (den reproducerbara återställningen)
När du måste bevisa att en bugg inte beror på ditt eget ackumulerade tillstånd ska du inte skrubba den gamla profilen. Börja med en ren.
Snabba alternativ:
Ett privat fönster/inkognitofönster (inget bestående tillstånd, men tillägg är ofta avstängda, vilket ändrar testet). En tillfällig Chrome-profil från Terminal: ? bash open -na « Google Chrome » –args –user-data-dir=/tmp/qa-profile-01
Varje ny sökväg ger en alldeles ny profil utan cookies, utan cache och utan tillägg. Radera mappen när du är klar, eller behåll den som en namngiven baslinje för en viss testplan.
Det är det renaste svaret på “är det appen eller min webbläsare?”. Och det är det bästa sättet att lämna över återskapningssteg som utgår från ett känt tillstånd.
Var cachen ligger på disken (och varför du vill städa den)
Allt ovan verkar på tillstånd som webbläsaren själv hanterar. Separat från det samlas cachemappar på disken, vilket spelar roll om du kör flera webbläsare och testbuilds hela dagen. Vanliga platser i din användarmapp Library:
Chrome: ~/Library/Caches/Google/Chrome/ Edge: ~/Library/Caches/Microsoft Edge/ Firefox: ~/Library/Caches/Firefox/Profiles/