Test Case Management
QAWiederverwendbare Testfälle, Suiten und Bundles — verknüpft mit jedem Ticket und jeder CI-Pipeline, mit lückenloser Rückverfolgbarkeit von der Anforderung bis zum Fehler.
Mehrere Server: $399
- Redmine
- 5.0 und neuer, 6.x, 7.x
- Berichte
- 12, mit CSV und Excel
- Berechtigungen
- 18, je Projektrolle
- CI/CD
- REST API, Anmeldung per API-Schlüssel
- Sprachen
- 50 Sprachdateien
- Ticket-Tracker
- Ihre, unverändert
Wiederverwendbare Testfälle
Suiten & Bundles
Unveränderliche Ausführungen
Automatisierungs-Zuordnung
CI/CD-REST-API
Dashboards & Berichte
Eine Kette von der Anforderung bis zum Fehler, der daraus entstand
Nichts in dieser Kette ist eine Kopie. Ein Ticket verweist auf die Testfälle, die es belegen, jeder Durchlauf fügt eine Ausführung hinzu, und eine fehlgeschlagene Ausführung verweist auf den Bug, den sie ausgelöst hat. Folgen Sie den Verknüpfungen in beide Richtungen, und Sie landen immer bei echten Redmine-Datensätzen.
1. Ticket
Ein Feature, eine Story oder eine Anforderung in dem Tracker, den Sie ohnehin nutzen. Das Plugin bringt keinen eigenen Tracker mit.
2. Testfall
Einzeln zugeordnet oder über ein Bundle. Derselbe Fall, etwa TC-41, kann beliebig vielen Tickets dienen.
3. Plan und Lauf
Ein Plan (TP-2) legt den Umfang für ein Release fest; ein Lauf (TR-5) ist eine Sitzung gegen einen Build.
4. Ausführung
Bestanden, fehlgeschlagen, blockiert oder übersprungen, mit Build, Commit, Umgebung, Schrittergebnissen und Screenshots. Wird nachträglich nie bearbeitet.
5. Fehler
Ein normales Redmine-Ticket, verknüpft mit dem Fehlschlag, von Hand angelegt oder automatisch, sobald ein Test fehlschlägt.
Regeln, die die Kette zusammenhalten
Referenzen mit TC-, TB-, TP-, TR- und DS- und frei wählbaren Präfixen, Ausführungen, die fest an die ausgeführte Fallversion gebunden sind, und eine optionale Regel, nach der ein Ticket erst geschlossen werden kann, wenn seine Tests bestanden sind.
Der gesamte Ablauf, aufgenommen in einem laufenden Redmine 6.1
Das sind echte Ansichten des Plugins im Standard-Theme von Redmine. Projekt, Personen und Ergebnisse sind Demodaten eines fiktiven Onlineshops namens Harbor Storefront.
Schreiben: eine Bibliothek wiederverwendbarer Testfälle
Suchen und filtern Sie nach Modul, Status, Automatisierung und Tags. Jeder Fall hat strukturierte Schritte, einen Review-Verlauf und eine eigene Versionshistorie.
Planen: Bundles, Release-Pläne und Testdaten
Bundles sammeln Fälle zur Wiederverwendung. Ein Plan verbindet Bundles, Tickets, Tester und eine Redmine-Version. Datensets versorgen einen Fall mit vielen Zeilen.
Ausführen: Getestet wird am Ticket und im Testlauf
Entwickler und Tester arbeiten dort, wo sie ohnehin sind. Jedes Ergebnis ist eine neue Ausführung, der Verlauf ist also zugleich der Prüfpfad.
Entscheiden: Berichte, die die Frage „Können wir ausliefern?“ beantworten
Zwölf Berichte, jeder mit CSV, Excel und Druckansicht. Zwei davon sind für das Release-Gespräch gemacht.
Nach Ihren Regeln: Import, Benachrichtigungen und Einstellungen
So sehen dreißig Tage Testen in den Berichten aus
Die folgenden Zahlen stammen direkt aus dem Demoprojekt der Screenshots, abgelesen aus den Berichten des Plugins selbst: 70 Testfälle und 1.242 Ausführungen zwischen dem 9. September und dem 8. Oktober 2026. Sie zeigen, was das Plugin misst. Es sind weder Benchmarks noch Kundenergebnisse.
| Kennzahl | Wert | Detail |
|---|---|---|
| Testfälle | 70 | 61 freigegeben, 5 im Review |
| Ausführungen | 1,242 | 856 automatisiert, 386 manuell |
| Erfolgsquote | 87.8% | Ziel 90 % |
| Automatisierungsabdeckung | 60% | 42 von 70 Fällen |
| Fehler aus Fehlschlägen | 5 | Mit der fehlgeschlagenen Ausführung verknüpft |
| Umgebung | Ausführungen | Bestanden | Fehlgeschlagen | Blockiert | Übersprungen | Erfolgsquote |
|---|---|---|---|---|---|---|
| QA | 700 | 610 | 47 | 29 | 14 | 87.1% |
| Staging | 344 | 307 | 20 | 10 | 7 | 89.2% |
| DEV | 162 | 142 | 12 | 5 | 3 | 87.7% |
| UAT | 36 | 31 | 3 | 1 | 1 | 86.1% |
| Modul | Fälle | Ausführungen | Bestanden | Erfolgsquote |
|---|---|---|---|---|
| API | 5 | 129 | 123 | 95.3% |
| Katalog | 8 | 118 | 112 | 94.9% |
| Benachrichtigungen | 5 | 99 | 93 | 93.9% |
| Admin | 6 | 62 | 56 | 90.3% |
| Suche | 6 | 143 | 128 | 89.5% |
| Authentifizierung | 10 | 193 | 172 | 89.1% |
| Checkout | 8 | 131 | 114 | 87.0% |
| Bestellungen | 6 | 89 | 73 | 82.0% |
| Warenkorb | 8 | 143 | 116 | 81.1% |
| Zahlungen | 8 | 135 | 103 | 76.3% |
In Redmine erscheinen dieselben Zahlen auf dem Dashboard (Erfolgsquoten-Ring, Ergebnisverteilung, 14-Tage-Trend, Modul- und Komponentenabdeckung) und in den tabellarischen Berichten, jeweils mit CSV- und Excel-Export.
Gebaut um eine einzige Regel: Ein Testfall wird nie dupliziert
Wiederverwendbare Testfälle
Titel, Vorbedingungen, strukturierte Schritte mit erwarteten Ergebnissen, Modul, Komponente, Priorität, Schweregrad, Typ und Tags. Klonen, gesammelt bearbeiten, importieren und exportieren.
Versionen, die die Historie schützen
Wer einen bereits ausgeführten Fall bearbeitet, erzeugt eine neue Version. Alte Ausführungen verweisen weiter auf die Schritte, die tatsächlich durchlaufen wurden.
Review und Freigabe
Entwurf, im Review, freigegeben, veraltet. Jede Entscheidung wird mit Reviewer, Datum und Kommentar festgehalten, und der Autor wird benachrichtigt.
Bundles, Pläne und Läufe
Bundles bündeln Fälle zur Wiederverwendung. Pläne stecken ein Release oder einen Sprint gegen eine Redmine-Version ab. Läufe halten eine Sitzung auf einem Build fest.
Ein Test-Panel an jedem Ticket
Zugeordnete Fälle, letzte Ergebnisse, Erfolgsquote, verknüpfte Fehler und Erfassen per Klick, in den Trackern Ihrer Wahl.
Ausführungen, die sich prüfen lassen
Jeder Durchlauf fügt einen Datensatz mit Ergebnis, Modus, Umgebung, Build, Commit, Dauer, Schrittergebnissen, Log und Screenshots hinzu. Nichts wird überschrieben.
Datengetriebenes Testen
Wiederverwendbare Datensets mit benannten Spalten. Ordnen Sie sie einzelnen Fällen oder ganzen Bundles zu und halten Sie fest, welche Zeile jede Ausführung verwendet hat.
Automatisierungs-Zuordnung und CI/CD
Bilden Sie einen Fall auf ein Framework und eine ID ab, die Ihr Runner versteht, und lassen Sie die Pipeline dann abholen, was auszuführen ist, und die Ergebnisse hochladen.
Dashboard und zwölf Berichte
Ein Dashboard, das sich jeder Benutzer aus acht Widgets zusammenstellt, dazu Berichte für Release-Reife, Abdeckung, Trend, Umgebungen, Fehler und Monitoring.
Vier kleine Lebenszyklen, alle auf der Seite sichtbar
| Datensatz | Hauptpfad | Weitere Zustände |
|---|---|---|
| Testfall | Entwurf → Im Review → Freigegeben | Änderungen angefordert, Veraltet |
| Testplan | Entwurf → Aktiv → Abgeschlossen | Archiviert |
| Testlauf | Geplant → In Arbeit → Abgeschlossen | Abgebrochen |
| Ausführungsergebnis | Bestanden, Fehlgeschlagen, Blockiert oder Übersprungen | Nicht ausgeführt. Jedes Ergebnis wird als manuell oder automatisiert erfasst. |
Ihre Pipeline fragt, was auszuführen ist, und meldet dann zurück
Die REST API liegt unter /testcases/api/v1 und authentifiziert sich mit einem normalen Redmine-API-Schlüssel. Alles, was eine HTTP-Anfrage senden kann, kann sie nutzen. Eine Anleitung im Plugin führt durch die Einrichtung — mit Ihren eigenen URLs bereits eingetragen.
| Methode | Endpunkt | Zweck |
|---|---|---|
| GET | /issues/:id/testing | Was für ein Ticket auszuführen ist |
| POST | /executions/upload | Ergebnisse eines Builds für ein Ticket |
| POST | /executions/bulk_upload | Ergebnisse für viele Tickets oder Builds |
| POST | /test_runs | Einen Lauf für diesen Build anlegen |
| POST | /test_runs/:id/results | Ergebnisse in einen Lauf schreiben |
| GET | /test_cases | Fälle auflisten, anlegen und ändern |
| GET | /test_plans | Pläne auflisten, anlegen und ändern |
| GET | /issues/:id/coverage | Testabdeckung eines Tickets |
| GET | /reports/:name | Jeder Bericht als JSON |
| GET | /dashboard | Aggregierte Kennzahlen |
Die Ergebnisse eines Builds hochladen
Senden Sie per POST die Ticket-ID, die Build-Nummer, den Commit-SHA, die Umgebung und eine Ergebnisliste an /executions/upload. Die Ergebnisse werden über Automatisierungs-ID, Fall-ID oder Referenz den Fällen zugeordnet, und aus jedem wird eine neue Ausführung. Ergebnisnamen werden normalisiert, sodass passed, failure und ignored aus Ihrem Runner alle richtig ankommen, und ein fehlgeschlagenes Ergebnis mit create_defect legt einen verknüpften Bug an.
Achtzehn Berechtigungen in einem Projektmodul
Das Testen ist ein gewöhnliches Redmine-Projektmodul. Aktivieren Sie es dort, wo Sie testen, und geben Sie jeder Rolle nur das, was sie braucht. Die Menü-Tabs richten sich nach den Berechtigungen.
| Rolle | Typische Berechtigungen | Was sie tun |
|---|---|---|
| QA-Leitung | manage_test_cases, approve_test_cases, manage_test_bundles, manage_test_plans, assign_test_bundles | Verantwortet die Bibliothek, gibt Fälle frei, baut Bundles und Release-Pläne |
| Tester | view_test_cases, execute_tests, manage_test_runs, manage_test_data | Führt Tests aus, erfasst Ergebnisse, pflegt Testdaten |
| Automatisierungsingenieur | manage_test_automation, view_test_executions | Bildet Fälle auf Frameworks und IDs ab |
| Entwickler | view_test_cases, view_test_executions, view_test_runs | Sieht, was an einem Ticket getestet wird und warum es fehlschlug |
| Projektleitung | view_test_reports, view_test_plans | Liest Berichte zu Release-Reife, Abdeckung und Monitoring |
| CI-Servicekonto | upload_test_results | Lädt Ergebnisse mit seinem API-Schlüssel hoch, sonst nichts |
| Administrator | admin_testing_settings, manage_test_environments | Präfixe, Umgebungen, Zielwerte und die Schließregel |
Läuft dort, wo Ihr Redmine bereits läuft
| Umgebung | Status | Hinweise |
|---|---|---|
| Redmine 7.x | Unterstützt | |
| Redmine 6.1 | Unterstützt | Entwicklungsziel, auf Rails 7.2 und Ruby 3.4. Die Screenshots auf dieser Seite stammen aus 6.1.2. |
| Redmine 6.0 | Unterstützt | |
| Redmine 5.x | Unterstützt | 5.0 ist die Mindestversion, die das Plugin angibt |
| MySQL 8 | Unterstützt | Für die Entwicklung und die Demo auf dieser Seite verwendet |
| Ticket-Tracker | Ihre | Funktioniert mit jeder Tracker-Konfiguration. Beschränken Sie das Test-Panel auf ausgewählte Tracker oder lassen Sie es für alle aktiv. |
| Zusätzliche Gems | Eines, optional | roo, nur für den Import von .xlsx- und .xls-Dateien |
In drei Schritten installiert
Erfordert Shell-Zugriff und die Möglichkeit, Rake-Tasks auszuführen. Sichern Sie vor jeder Plugin-Installation Ihre Daten.
cd /opt/redmine # unpack so the folder is plugins/redmine_testcases bundle install
RAILS_ENV=production bin/rails redmine:plugins:migrate NAME=redmine_testcases
# Project → Settings → Modules → Test Case Management # Administration → Roles and permissions → grant the testing permissions # Testing → Settings → environments, pass-rate target, trackers
RAILS_ENV=production bin/rails redmine:plugins:migrate NAME=redmine_testcases VERSION=0
Bringt das Plugin eigene Tracker für Anforderungen, Storys oder Bugs mit?
Was passiert mit alten Ergebnissen, wenn jemand einen Testfall bearbeitet?
Kann ein fehlgeschlagener Test verhindern, dass ein Ticket geschlossen wird?
Mit welchen CI-Systemen funktioniert es?
Können Fehlschläge automatisch Bugs anlegen?
Können wir Testfälle aus einer Tabelle übernehmen?
Sind die Zahlen auf dieser Seite echt?
Preise
Ein Server
Eine Redmine-Instanz · unbegrenzt viele Benutzer · 12 Monate Updates.
Mehrere Server
Unbegrenzt viele Redmine-Server · unbegrenzt viele Benutzer · 12 Monate Updates.
Sie brauchen eine individuelle Redmine-Lösung?
Sie suchen eine Funktion, die unsere Plugins noch nicht bieten?
RedmineKit entwickelt individuelle Redmine-Plugins, passt bestehende Plugins an, automatisiert Workflows, bindet Drittsysteme an und erstellt maßgeschneiderte Lösungen für Ihr Unternehmen.
Beschreiben Sie, was Sie brauchen. Wir prüfen Ihre Anforderungen und schlagen eine passende Lösung mit geschätzten Kosten und Zeitrahmen vor.