In diesem Ratgeber
Dein Entwicklungs-PC ist der schlechteste Ort, um deinen Installer zu testen. Dort liegen Runtimes, Zertifikate, Ordner und Registry-Einträge schon bereit, die deine App braucht. Auf dem Rechner deiner Nutzer fehlen sie. Dieser Plan testet den ganzen Installationsablauf auf Rechnern, die so aussehen wie ihre.
Testrechner vorbereiten
- Eine saubere Windows-Installation in einer virtuellen Maschine, mit einem Snapshot vor der ersten Installation. Zwischen den Läufen setzt du darauf zurück.
- Ein zweiter Rechner in anderem Zustand: eine andere unterstützte Windows-Version, ein Benutzer ohne Adminrechte, eine andere Systemsprache, ein Benutzername mit Leerzeichen oder Umlauten.
- Ältere Builds deiner eigenen App zum Aktualisieren. Hebe jeden ausgelieferten Build auf.
Ob du MSIX, MSI oder ein klassisches Setup auslieferst: Die Szenarien unten bleiben gleich. Das Verhalten unterscheidet sich je nach Technik; Details stehen in der Dokumentation deines Installers.
Die Szenarien
| # | Szenario | Erwartetes Ergebnis |
|---|---|---|
| 1 | Neuinstallation auf sauberem Rechner | Läuft ohne Zusatzschritte; App startet; keine Fehler wegen fehlender Runtime |
| 2 | Installation als Standardbenutzer (ohne Admin) | Funktioniert wie geplant oder fragt mit klarer Meldung nach Rechten |
| 3 | Installation in eigenen Ordner (Leerzeichen, Umlaute) | App startet und kann ihre Daten schreiben |
| 4 | Start über Verknüpfung und ggf. Dateizuordnung | Beides öffnet die App richtig |
| 5 | Update über die letzte Version | Einstellungen und Nutzerdaten bleiben; Versionsnummer stimmt |
| 6 | Update über eine viel ältere Version | Datenmigration klappt oder scheitert mit klarer Meldung |
| 7 | Update bei laufender App | Installer erkennt sie und bittet um Schließen oder behandelt es sauber |
| 8 | Abgebrochene Installation (Abbruch, Stromausfall, Prozess beenden) | Kein halber Zustand; erneutes Ausführen funktioniert |
| 9 | Reparatur (falls vorhanden) | Fehlende oder beschädigte Dateien kommen zurück; Nutzerdaten bleiben |
| 10 | Deinstallation | App, Verknüpfungen und Startmenüeinträge sind weg; kein Prozess läuft weiter |
| 11 | Deinstallieren, dann neu installieren | Verhält sich wie Fall 1; ob Nutzerdaten bleiben, entscheidest du und sagst es |
| 12 | Sicherheitsabfragen | Notiere jede Warnung, die das System beim ersten Start des Installers zeigt |
So gehst du vor
- Snapshot zurücksetzen, ein Szenario durchführen, Ergebnis mit Build-Nummer notieren.
- Nach jeder Installation und Deinstallation Installationsordner, Datenordner und die Liste installierter Apps ansehen. Überreste sind Befunde.
- Das Log deines Installers prüfen, falls er eins schreibt, und dem Bericht anhängen.
- Szenarien 5 bis 7 bei jedem Release wiederholen, nicht nur beim ersten.
Was typischerweise schiefgeht
- Die App braucht eine Runtime, die auf dem sauberen Rechner nie vorhanden war.
- Eine neue Version liest Einstellungen der alten in einem anderen Format.
- Der Deinstaller löscht Nutzerdaten ungefragt oder lässt Dienste und Hintergrundaufgaben zurück.
- Ein Pfad mit Leerzeichen zerlegt ein Kommandozeilenargument.
Halte jeden Befund mit der Fehlerbericht-Vorlage für Desktop-Apps fest, damit er reproduzierbar ist.
Was AppReviewX abdeckt
AppReviewX nimmt Apps per Store-Link aus Google Play, Apple App Store, Mac App Store und Microsoft Store an. Windows- und Mac-Apps müssen bereits in ihrem Store veröffentlicht sein, und AppReviewX verteilt keine Builds oder Installer. Das Feedback ist privat und strukturiert, ein akzeptiertes Feedback = ein Credit, und Store-Bewertungen sind freiwillig, unbezahlt und nie Pflicht. Diese Seite ist allgemeine Hilfe.
Starte kostenlos und bekomme privates Feedback zu deiner App.
Mehr dazu: Leitfaden zum Testen von Windows- und Mac-Apps, Betatest für eine Windows-App, Betatest für eine Mac-App.