Browser-Cache am Mac für QA-Tests leeren: Die Reset-Leiter
Browser-Cache am Mac für QA-Tests leeren: Die Reset-Leiter
Kurzantwort: Um den Browser-Cache am Mac für QA-Zwecke zu leeren, arbeitest du dich vom leichtesten zum schwersten Reset vor: Hard Reload, „Disable cache“ in den DevTools, Website-Daten löschen (Cookies, Storage, Service Worker) und zuletzt ein frisches Wegwerf-Profil. Cache-Ordner auf der Platte zu löschen behebt nur veraltete Dateien. Logins und App-Zustand setzt es nicht zurück.
Du meldest einen Bug. Der Entwickler antwortet: „Bei mir läuft’s.“ Du testest erneut, und plötzlich läuft es bei dir auch. Geändert hat sich nichts, außer dass dein Browser stillschweigend eine frische Kopie einer Datei geholt hat, die er bis dahin festgehalten hatte.
Caches sind für QA-Arbeit am Mac ein besonderes Problem: Du musst genau wissen, gegen welche Schicht gespeicherten Zustands du gerade testest. „Cache leeren“ ist dafür zu grob. Dieser Guide teilt den gespeicherten Browser-Zustand in Schichten auf und nennt für jede den kleinsten Reset, der funktioniert.
Was klemmt eigentlich? Symptom der richtigen Schicht zuordnen
Browser speichern mehrere Arten von Zustand, und „der Cache“ ist nur eine davon.
Symptom Wahrscheinliche Schicht Leichtester Fix Altes CSS/JS nach einem Deploy HTTP-Cache Hard Reload Änderungen fehlen, aber nur im normalen Fenster HTTP-Cache oder Service Worker DevTools mit deaktiviertem Cache, danach Service Worker abmelden Du bist weiterhin als falscher Nutzer eingeloggt Cookies / Storage Website-Daten für diese Origin löschen Feature-Flag oder Onboarding-Status lässt sich nicht zurücksetzen localStorage / IndexedDB Website-Daten löschen App funktioniert offline, obwohl sie es nicht sollte Service Worker + Cache Storage Service Worker abmelden, Website-Daten löschen Bug lässt sich auf dem Rechner eines Kollegen nicht reproduzieren Angesammelter Profilzustand Frisches Profil
Fang oben in der Leiter an und geh nur weiter nach unten, wenn das Problem bleibt. Jede weitere Sprosse wirft mehr Zustand weg, den du für die Reproduktion vielleicht brauchst.
Sprosse 1: Hard Reload (Sekunden, nichts geht verloren)
Ein Hard Reload umgeht den Cache für den aktuellen Seitenaufruf.
Chrome, Edge, Firefox: ??R Safari: ??R („Von Ursprung neu laden“)
Das löst die häufigste „altes Build“-Beschwerde. Cookies, Storage und Service Worker bleiben unangetastet, und der Effekt gilt nur für diesen einen Ladevorgang. Ressourcen, die später nachgeladen werden, können weiterhin aus dem Cache kommen.
Sprosse 2: DevTools den Cache umgehen lassen
Wenn du den ganzen Nachmittag neu lädst, mach das nicht von Hand.
Chrome/Edge: DevTools öffnen ? Tab Network ? Häkchen bei Disable cache. Gilt nur, solange die DevTools geöffnet sind. Firefox: DevTools ? Netzwerk ? HTTP-Cache deaktivieren (bei geöffneter Toolbox). Safari: Zuerst das Entwickler-Menü aktivieren (Safari ? Einstellungen ? Erweitert ? „Funktionen für Webentwickler anzeigen“, Wortlaut je nach Version unterschiedlich), dann Entwickler ? Caches deaktivieren.
Chrome hat außerdem einen praktischen Shortcut: Bei geöffneten DevTools mit Rechtsklick auf den Reload-Button „Cache leeren und hart neu laden“ wählen.
Eine Falle, in die viele tappen: „Disable cache“ meldet keine Service Worker ab. Ein Service Worker kann weiterhin eigene gespeicherte Antworten ausliefern. Hilft Sprosse 2 nicht, geht es mit Sprosse 3 weiter.
Sprosse 3: Website-Daten nur für eine Origin löschen
Alles zu löschen ist selten das, was du willst. Beschränkst du den Reset auf die getestete Seite, bleiben deine anderen Sessions (und deine Nerven) erhalten.
Chrome/Edge: DevTools ? Application ? Storage ? Clear site data. Prüf vor dem Klick, was angehakt ist: Cookies, Local und Session Storage, IndexedDB, Cache Storage und Service Worker lassen sich einzeln ein- oder ausschließen. Im Bereich Service Workers kannst du einen Worker außerdem direkt abmelden und die Option Update on reload nutzen.
Firefox: Einstellungen ? Datenschutz & Sicherheit ? Cookies und Website-Daten ? Daten verwalten, dann die jeweilige Seite entfernen. Alternativ den Tab Speicher in den DevTools verwenden.
Safari: Einstellungen ? Datenschutz ? Websitedaten verwalten, nach der Domain suchen und entfernen.
Das ist der richtige Reset für „als falscher Nutzer eingeloggt“, veraltete Feature-Flags und Offline-Bugs. Hier solltest du auch notieren, was du gelöscht hast, denn „Website-Daten gelöscht“ und „nur den HTTP-Cache geleert“ können zu unterschiedlichen Testergebnissen führen.
Sprosse 4: Wegwerf-Profil (der reproduzierbare Reset)
Willst du beweisen, dass ein Bug nicht von deinem eigenen angesammelten Zustand stammt, schrubbst du das alte Profil nicht, sondern startest mit einem sauberen.
Schnelle Optionen:
Ein privates Fenster bzw. Inkognito-Fenster (kein persistenter Zustand, aber Erweiterungen sind oft deaktiviert, was den Test verändert). Ein temporäres Chrome-Profil über das Terminal: ? bash open -na « Google Chrome » –args –user-data-dir=/tmp/qa-profile-01
Jeder neue Pfad ergibt ein frisches Profil ohne Cookies, ohne Cache und ohne Erweiterungen. Lösch den Ordner nach dem Test oder behalte ihn als benannte Baseline für einen bestimmten Testplan.
Das ist die sauberste Antwort auf „liegt es an der App oder an meinem Browser?“ Und es ist der beste Weg, Reproduktionsschritte weiterzugeben, die von einem definierten Ausgangszustand starten.
Wo der Cache auf der Platte liegt (und warum du ihn aufräumen willst)
Alles bisher betrifft Zustand, den der Browser selbst verwaltet. Unabhängig davon sammeln sich Cache-Ordner auf der Festplatte an, was ins Gewicht fällt, wenn du den ganzen Tag mehrere Browser und Test-Builds nutzt. Typische Speicherorte in deinem Benutzer-Library-Ordner:
Chrome: ~/Library/Caches/Google/Chrome/ Edge: ~/Library/Caches/Microsoft Edge/ Firefox: ~/Library/Caches/Firefox/Profiles/