Kernpunkte
- Electron rendert Webinhalte in einem Desktop-Shell, was bedeutet, dass Ihre Anwendung alle visuellen Web-Bugs erbt — plus die Desktop-Besonderheiten
- Variable Fenstergrößen, native Menüs, Multi-Monitor-Unterstützung und Rendering-Unterschiede zwischen Betriebssystemen schaffen Bug-Kategorien, die es im klassischen Web nicht gibt
- Eine Electron-App wie eine einfache Website zu testen ist ein Fehler: Der Desktop-Kontext verändert die visuelle Erfahrung grundlegend
- Automatisiertes visuelles Testen ist der einzige gangbare Ansatz, um die Kombinatorik OS x Auflösung x DPI x Fenstergröße abzudecken
Electron wird in seiner offiziellen Dokumentation als "ein Framework zur Erstellung nativer Desktop-Anwendungen mit Webtechnologien (HTML, CSS, JavaScript), das Chromium für das Rendering und Node.js für den Zugriff auf Systemfunktionen in einer einzigen plattformübergreifenden Runtime kombiniert" definiert (Electron Documentation, electronjs.org).
Hinter dieser eleganten Definition verbirgt sich eine Realität, die jeder Electron-Entwickler kennt: Sie erhalten das Beste des Web (Ökosystem, Produktivität, reichhaltige UI-Komponenten) und das Schlechteste des Web (CSS-Inkonsistenzen, Renderingprobleme, variable Performance). Das Ganze, garniert mit einer zusätzlichen Schicht Komplexität durch die Desktop-Umgebung.
Wenn Sie eine Electron-Anwendung entwickeln — und es ist sehr wahrscheinlich, dass Sie mehrere verwenden (VS Code, Slack, Discord, Figma, Notion, Obsidian) — wird Ihnen dieser Artikel zeigen, warum das visuelle Testen Ihrer Desktop-Anwendung besondere Aufmerksamkeit verdient und warum es nicht ausreicht, sie "wie Web" zu behandeln, obwohl es der richtige Ausgangspunkt bleibt.
Electron erbt alle visuellen Web-Probleme
CSS ist immer noch CSS
Ihre Electron-Anwendung verwendet dieselbe Rendering-Engine wie Chrome (Chromium, über das Electron-Projekt, das eine bestimmte Chromium-Version einbettet). Das bedeutet, dass alle visuellen Webprobleme gelten: CSS-Regressionen nach einem Abhängigkeitsupdate, Textüberläufe, z-index-Probleme, falsch dimensionierte Bilder, ruckelnde Animationen, Schriften die nicht laden.
Wenn Sie bereits visuelles Testen für Web gemacht haben, kennen Sie diese Probleme. Und sie sind in Electron genauso präsent.
Aber hier ist die Falle: Viele Teams, die Electron-Anwendungen entwickeln, kommen nicht aus dem Web. Sie kommen vom nativen Desktop (C++, C#, Java Swing), wo CSS-Renderingprobleme nicht existieren. Sie entdecken diese Probleme zum ersten Mal, ohne die Erfahrung und die Tools, um damit umzugehen.
Chromium-Updates: das stille Risiko
Jedes Major-Update von Electron beinhaltet eine neue Chromium-Version. Und jede neue Chromium-Version kann das Rendering subtil verändern. Eine Änderung des Subpixel-Antialiasing, eine Änderung in der Berechnung von Abrundungen, eine Entwicklung in der Schriftverwaltung — diese Änderungen werden selten als Breaking Changes dokumentiert, aber sie können messbare visuelle Regressionen verursachen.
Das Electron-Team veröffentlicht etwa alle acht Wochen eine neue Majorversion. Laut dem offiziellen Electron-Blog integriert jedes Major-Release eine Chromium-Version, eine Node.js-Version und eine V8-Version. Das sind viele potenzielle Änderungsflächen.
Wenn Sie nicht vor und nach jedem Electron-Update visuell testen, akzeptieren Sie ein stilles Regressionsrisiko für Ihre gesamte Oberfläche.
Die Desktop-Besonderheiten, die alles ändern
Das veränderbare Fenster: Responsive auf Steroiden
Im Web besteht Responsive Design darin, das Layout an einige vordefinierte Breakpoints anzupassen (Mobil, Tablet, Desktop). Die möglichen Viewports sind zahlreich, aber durch die bestehenden Bildschirmgrößen begrenzt.
Auf dem Desktop kann das Fenster Ihrer Electron-Anwendung buchstäblich jede Größe annehmen, von 400 mal 300 Pixel bis 3840 mal 2160 Pixel, einschließlich aller Zwischengrößen. Der Benutzer kann frei die Größe ändern, und er tut es.
Das erzeugt ein kontinuierliches Spektrum möglicher Layouts, nicht eine diskrete Menge von Breakpoints. Ihre Anwendung muss in jeder Größe visuell korrekt sein — und die Zwischengrößen (zwischen Ihren Breakpoints) sind oft diejenigen, bei denen Probleme auftreten.
Einige typische Fehler beim Fenster-Resize:
Eine Sidebar, die sich über den Hauptinhalt legt, wenn das Fenster zu schmal für beides ist, aber zu breit, um den "collapsed"-Modus auszulösen.
Eine Tabelle, die aus ihrem Container überläuft und ein unerwartetes horizontales Scrollen bei bestimmten Breiten erzeugt.
Action-Buttons in einem Header, die sich überlappen, wenn der horizontale Platz unzureichend ist, aber der mobile Breakpoint noch nicht erreicht wurde.
Ein schwebendes Panel (Inspector, Terminal, Befehlspalette), das aus dem sichtbaren Bereich herausragt, wenn das Fenster zu klein ist.
Native Menüs: die Oberfläche, die Sie nicht kontrollieren
Electron-Anwendungen können die nativen OS-Menüs verwenden (Menüzeile auf macOS, Fenstermenü auf Windows und Linux). Diese Menüs werden vom Betriebssystem gerendert, nicht von Ihrem CSS-Code. Ihr Erscheinungsbild variiert je nach OS, OS-Version und dem Systemtheme des Benutzers.
Visuell ist die Übergangszone zwischen dem nativen Menü und Ihrem Webinhalt eine häufige Problemquelle. Auf macOS werden die Titelleiste und das Menü vom System verwaltet. Auf Windows verwenden viele Electron-Anwendungen eine benutzerdefinierte Titelleiste (Frameless Window mit in CSS nachgebauten Steuerelementen) für einen moderneren Look.
Diese benutzerdefinierte Titelleiste ist eine visuell kritische Komponente. Die Schließen-, Minimieren- und Maximieren-Buttons müssen an der richtigen Stelle, in der richtigen Größe, in der richtigen Farbe sein und sich beim Hover korrekt verhalten. Und all das variiert zwischen den Plattformen: Auf macOS sind die Buttons links und rund; auf Windows sind sie rechts und eckig; auf Linux hängt es vom Window Manager ab.
Wenn Ihre Anwendung eine benutzerdefinierte Titelleiste verwendet, muss visuelles Testen sie auf jedem Ziel-OS abdecken. Es ist eine Komponente, die Benutzer ständig sehen und verwenden, und ein visueller Bug hier ist sofort wahrnehmbar.
Multi-Monitor und variables DPI
Die moderne Desktop-Umgebung besteht oft aus einem Laptop mit einem Retina-Display (2x DPI), verbunden mit einem externen Monitor in 1080p (1x DPI). Der Benutzer verschiebt Ihre Anwendung von einem Bildschirm zum anderen. Und wenn die Anwendung von einem 2x-Bildschirm zu einem 1x-Bildschirm wechselt, muss alles korrekt neu gerendert werden.
Visuelle Probleme im Zusammenhang mit DPI sind besonders tückisch:
Bitmap-Bilder (PNG, JPG), die für ein einziges DPI erstellt wurden, erscheinen auf hochauflösenden Bildschirmen unscharf oder auf niedrigauflösenden Bildschirmen pixelig. Icons und Illustrationen müssen in mehreren Auflösungen oder im Vektorformat (SVG) bereitgestellt werden.
1-Pixel-Ränder werden in 1x und 2x nicht gleich angezeigt. Auf einem 2x-Bildschirm macht ein 1-Pixel-CSS-Rand 0,5 physische Pixel, was ihn je nach Rendering-Engine unsichtbar oder inkonsistent machen kann.
Schatten, Farbverläufe und Unschärfeeffekte ändern subtil ihr Rendering zwischen den Auflösungen. Was auf einem 1x-Bildschirm eine leichte Unschärfe ist, wird auf einem 2x-Bildschirm eine ausgeprägt Unschärfe, oder umgekehrt.
Texte unterliegen einem unterschiedlichen Antialiasing. Die Lesbarkeit einer dünnen Schrift kann in 2x exzellent und in 1x mäßig sein. Die typografische Wahl, die auf Ihrem Entwicklerbildschirm funktioniert (wahrscheinlich ein MacBook Retina), kann auf dem externen Monitor Ihres Benutzers katastrophal sein.
Taskleiste, Dock und System Tray
Ihre Anwendung interagiert mit der Desktop-Umgebung über das Taskleistensymbol (Windows/Linux), das Dock (macOS) und das System Tray. Diese winzigen Icons (16x16 bis 48x48 Pixel) müssen einwandfrei sein. Benachrichtigungsabzeichen, Statusoverlays, Kontextmenüs — das sind visuelle Elemente, die Ihre Benutzer ständig sehen, auch wenn Ihre Anwendung nicht im Vordergrund ist.
Die drei Betriebssysteme: drei Renderings, drei Problemfelder
macOS: die anspruchsvolle Referenz
macOS ist oft die primäre Entwicklungsplattform. Die visuellen Besonderheiten umfassen die Ampel-Buttons (rot, gelb, grün) links, das Schrift-Rendering durch Core Text (visuell "fetter" beim gleichen Gewicht als auf Windows) und die native Unterstützung des Dark Mode, der mit dem Theme Ihrer Anwendung harmonieren muss.
Windows: die Vielfalt der Konfigurationen
Windows bietet die größte Vielfalt an Konfigurationen. Die Auflösungen reichen von 1366x768 (laut StatCounter in 2025 noch 20 % der Bildschirme) bis 3840x2160. Die Skalierungsfaktoren (100 % bis 200 %) fügen eine auf macOS nicht vorhandene Komplexität hinzu.
Das Schrift-Rendering durch DirectWrite erzeugt spürbar andere Ergebnisse als Core Text: dünnere, schärfere Schriften, manchmal weniger lesbar in kleinen Größen. Der "hoher Kontrast"-Modus für Barrierefreiheit kann das Erscheinungsbild Ihrer Anwendung drastisch verändern, wenn Ihre CSS-Styles ihn nicht unterstützen.
Linux: der Sonderfall
Die Fragmentierung der Desktop-Umgebungen (GNOME, KDE, XFCE) macht die Standardisierung schwierig. Aber laut der Stack Overflow Developer Survey 2024 nutzen etwa 27 % der Entwickler Linux. Wenn Ihre Anwendung Entwickler anspricht, verdient Linux Abdeckung. Das Minimum: Ubuntu mit GNOME.
Visuelle Teststrategie für Electron
Ihre Testmatrix definieren
Der erste Schritt ist die explizite Definition der Kombinationen, die Sie testen werden. Mindestens sollte Ihre Matrix enthalten:
Die Ziel-Betriebssysteme. macOS (neueste und vorletzte Version), Windows 10, Windows 11. Linux Ubuntu LTS, wenn Ihre Zielgruppe es rechtfertigt.
Die priorisierten Bildschirmauflösungen. Für jedes OS die zwei oder drei von Ihren Benutzern am häufigsten verwendeten Auflösungen. Auf macOS: 1440x900 und 2560x1600 (Retina). Auf Windows: 1920x1080 und 1366x768. Passen Sie anhand Ihrer tatsächlichen Analytics-Daten an.
Die DPI-Faktoren. Mindestens 1x und 2x. Auf Windows fügen Sie 1,5x (150 %) hinzu, eine sehr verbreitete Einstellung.
Die Fenstergrößen. Vollbild, halber Bildschirm (Split Screen) und eine reduzierte "minimal funktionale" Größe. Diese drei Größen decken die realen Nutzungsszenarien ab.
Erfassung auf mehreren OS automatisieren
Die technische Hauptherausforderung des visuellen Testens von Electron ist die Erfassung von Screenshots auf mehreren Betriebssystemen. Sie haben mehrere Optionen.
Der Multi-Plattform-CI-Ansatz. GitHub Actions, GitLab CI und Azure Pipelines unterstützen Jobs auf macOS, Windows und Linux. Konfigurieren Sie einen visuellen Test-Job pro OS, der Ihre App startet, zu den zu testenden Bildschirmen navigiert und Screenshots erfasst.
Der Playwright-Ansatz. Playwright unterstützt seit Version 1.20 nativ die Automatisierung von Electron: App-Start, Interaktionen, Screenshot-Erfassung, alles plattformübergreifend.
Der Delta-QA-Ansatz. Für Teams, die keine Skripte pflegen wollen, bietet Delta-QA einen No-Code-Ansatz zur visuellen Erfassung und zum Vergleich der Bildschirme Ihrer Anwendung.
Die vorrangig zu überwachenden Bereiche
In einer Electron-Anwendung sind bestimmte Bereiche anfälliger für visuelle Regressionen als andere. Konzentrieren Sie Ihre visuellen Tests auf diese Bereiche:
Die Titelleiste und Fenstersteuerung. Wenn Sie eine benutzerdefinierte Titelleiste verwenden (Frameless Window), testen Sie sie auf jedem OS. Die Schließen-/Minimieren-/Maximieren-Buttons, der Drag-Bereich, der Anwendungstitel — alles muss pixelgenau und konform mit den Plattformkonventionen sein.
Veränderbare Panels. Wenn Ihre Anwendung Panels (Sidebar, Bottom Panel, Inspector) hat, die der Benutzer in der Größe ändern kann, testen Sie das Rendering in verschiedenen Panelgrößen. Die Resize-Handles, die Minimal- und Maximalgrößen, der sich anpassende Inhalt — alles muss visuell korrekt sein.
Kontextmenüs. Native Kontextmenüs haben auf jedem OS ein anderes Rendering. Benutzerdefinierte Kontextmenüs (in CSS) müssen in Bezug auf Positionierung (nicht aus dem Fenster überquellen), Lesbarkeit und Konsistenz mit dem Anwendungstheme getestet werden.
Modale Dialoge. Systemdialoge (Datei öffnen, speichern, drucken) sind nativ und erfordern kein visuelles Testen Ihrerseits. Aber die benutzerdefinierten Modals Ihrer Anwendung müssen getestet werden, insbesondere ihre Zentrierung, ihr Overlay und ihr Verhalten bei kleinem Fenster.
Ladezustände und Übergänge. Der Start einer Electron-Anwendung kann einige Sekunden dauern. Was der Benutzer während dieser Zeit sieht (Splash Screen, Ladebildschirm, leeres Fenster) ist Teil der Erfahrung und verdient einen visuellen Test.
Die häufigsten Fehler
Nur auf einem OS testen
Das ist der häufigste und teuerste Fehler. Wenn Ihr Team auf macOS entwickelt und auf macOS testet, gelangen Windows- und Linux-spezifische visuelle Bugs ungefiltert in die Produktion. Und Windows stellt in der Regel die Mehrheit Ihrer Electron-Benutzerbasis dar (laut Daten von Electron Fiddle und vielen populären Electron-Anwendungen macht Windows oft 60 bis 70 % der Installationen aus).
DPI-Faktoren ignorieren
Nur in 1x zu testen, wenn ein erheblicher Anteil Ihrer Benutzer in 2x ist (oder umgekehrt), ist ein Rezept für Überraschungen. DPI-Probleme sind subtil — leicht unscharfe Texte, verschwundene Ränder, pixelige Icons — aber sie hinterlassen einen Eindruck von mangelnder Feinheit, der das Vertrauen untergräbt.
Electron wie einen Webbrowser behandeln
Ihre Electron-Anwendung ist kein Browser-Tab. Es ist eine Desktop-Anwendung, die der Benutzer installiert hat, die ihren eigenen Platz in der Taskleiste hat und nach den Standards nativer Anwendungen beurteilt wird. Benutzer tolerieren eine Website mit einem etwas kaputten Layout. Sie tolerieren keine installierte Desktop-Anwendung mit offensichtlichen visuellen Problemen.
Zwischen-Fenstergrößen vernachlässigen
Wenn Sie nur im Vollbildmodus testen, verpassen Sie alle Bugs, die auftreten, wenn der Benutzer Ihre Anwendung im halben Bildschirm verwendet (Split Screen mit einer anderen Anwendung). Das ist ein extrem gängiger Anwendungsfall auf dem Desktop, besonders für Produktivitätstools.
FAQ
Electron verwendet Chromium, also reichen klassische Web-Tests, oder?
Nein. Electron verwendet Chromium für das Rendering, das stimmt. Aber die Umgebung ist grundlegend anders: unbegrenzt veränderbares Fenster, keine Adressleiste, native OS-Menüs, Taskleisten-Integration, Multi-Monitor-Unterstützung, variables DPI. Ihre klassischen Web-Tests decken das Chromium-Rendering in einem Browser ab. Sie decken nicht die Besonderheiten der Electron-Desktop-Umgebung ab. Beide Ebenen sind notwendig.
Wie geht man mit Schrift-Rendering-Unterschieden zwischen macOS und Windows um?
Das Schrift-Rendering unterscheidet sich strukturell zwischen Core Text (macOS) und DirectWrite (Windows). Der einzig zuverlässige Weg, diese Unterschiede zu handhaben, ist die Pflege separater visueller Baselines pro OS. Vergleichen Sie keinen macOS-Screenshot mit einem Windows-Screenshot — sie werden immer unterschiedlich sein, und diese Unterschiede sind normal. Vergleichen Sie macOS mit macOS, Windows mit Windows.
Muss jedes Electron-Versionsupdate getestet werden?
Ja, und das ist nicht verhandelbar. Jedes Major-Update von Electron beinhaltet eine neue Chromium-Version, die das Rendering verändern kann. Die Best Practice ist, Ihre vollständige visuelle Testsuite vor und nach dem Update durchzuführen, die Ergebnisse zu vergleichen und die Unterschiede zu validieren. Einige Unterschiede werden Verbesserungen der Rendering-Engine sein (die Sie durch Aktualisierung der Baselines akzeptieren können), andere werden Regressionen sein (die Sie beheben oder melden müssen).
Wie testet man den Modus "Hoher Kontrast" von Windows?
Der Modus "Hoher Kontrast" (High Contrast Mode) von Windows ist eine Barrierefreiheitseinstellung, die die Farben Ihrer Anwendung durch ein Farbschema mit hohem Kontrast ersetzt. Sie können ihn programmatisch in Ihrer CI-Testumgebung aktivieren (über Systemeinstellungen oder Automatisierungstools). Erfassen Sie Screenshots in diesem Modus und pflegen Sie eine dedizierte Baseline. Das ist besonders wichtig, wenn Ihre Anwendung professionelle Umgebungen anspricht, in denen strenge Barrierefreiheitsrichtlinien gelten.
Meine Electron-App zielt nur auf macOS. Ist Multi-OS-Testing trotzdem notwendig?
Wenn Ihre Anwendung wirklich nur ein OS unterstützt, ist Multi-OS-Testing offensichtlich nicht notwendig. Aber überprüfen Sie diese Annahme: Viele "nur macOS"-Anwendungen stellen fest, dass ein Teil ihrer Benutzer die Anwendung unter Windows über inoffizielle Installationen oder Unternehmensanforderungen ausführt. Wenn Sie zukünftigen Windows-Support in Betracht ziehen, wird eine frühe Investition in Multi-OS-Testing den Übergang erheblich erleichtern.
Was ist die ideale Frequenz für visuelles Testen einer Electron-App?
Bei jedem Commit, der die Oberfläche berührt, und bei jedem Electron-Versionsupdate oder UI-Abhängigkeitsupdate. In der Praxis integrieren Sie visuelles Testen in Ihre CI/CD-Pipeline, damit es bei jedem Pull Request automatisch ausgeführt wird. Die Kosten eines gelegentlichen falsch-positiven Ergebnisses sind unendlich geringer als die Kosten einer an Tausende Desktop-Benutzer ausgelieferten visuellen Regression.
Weiterführende Lektüre
- Visuelles Testen und Web-Typografie: Schriften sind das unsichtbare Detail, das Ihre Nutzererfahrung ruiniert
- Visuelles Testen für EdTech-Plattformen: Fehlerfreie Erfahrung vom Hörsaal bis zum Smartphone
Electron gibt Ihnen die Macht, Desktop-Anwendungen mit Webtechnologien zu erstellen. Das ist eine Superkraft. Aber diese Superkraft bringt eine Verantwortung mit sich: Die visuellen Bugs des Web folgen Ihnen auf den Desktop, und sie werden von einer Kohorte desktop-spezifischer Probleme begleitet.
Die gute Nachricht ist: Wenn Sie bereits wissen, wie man Web visuell testet, haben Sie 80 % der notwendigen Fähigkeiten. Die restlichen 20 % — die Multi-OS-Matrix, die DPI-Faktoren, die veränderbaren Fenster, die nativen Menüs — sind eine natürliche Erweiterung Ihres bestehenden Ansatzes.
Electron erbt alle Probleme des Web. Testen Sie es wie Web, dann gehen Sie weiter.