Probleme exportieren
Link to Probleme exportieren copied to clipboard
Der Bildschirm „Fehlerliste“ bietet Ihnen eine Exportfunktion, die durch Aktivieren der Schaltfläche Exportieren in der Dropdown-Option „Aktionen“ oben in der Fehlertabelle gestartet wird. Probleme können exportiert werden, auch wenn Sie nicht alle als erledigt markiert haben.
So exportieren Sie Probleme:
- Wählen Sie in der linken Spalte alle Probleme aus, die Sie exportieren möchten. Aktivieren Sie das Kontrollkästchen, um in das leere Kästchen ein Häkchen zu setzen und so Ihre Auswahl für alle gewünschten Fehlerzeilen anzuzeigen. Oben links in der Tabelle wird eine Meldung mit der Anzahl der ausgewählten Probleme angezeigt.
- Wählen Sie die Dropdown-Menüoption „Aktionen“ und aktivieren Sie die Schaltfläche Exportieren .
Das Dialogfeld „Ausgabe exportieren“ wird angezeigt.- Wählen Sie eine Option für den Exporttyp aus.
- CSV (kompatibel mit Microsoft Excel): Komma-getrennte Werte (kompatibel mit Microsoft Excel) ist nützlich für den Import in Tabellenkalkulationsanwendungen oder Datenbanken.
- CSV: Komma-getrennte Werte sind nützlich für den Import in Tabellenkalkulationsanwendungen oder Datenbanken.
- JSON: JavaScript-Objekt ist nützlich für den Import in Issue-Tracking-Systeme wie JIRA.
- JSON (mit universellem Axe-Format): JSON-Format, das mit einem universellen Exportformat übereinstimmt, das von verschiedenen Axe-Produkten gemeinsam genutzt wird. Dies ist insbesondere dann nützlich, wenn Kunden Daten aus mehreren Axe-Produkten extrahieren müssen, um sie weiter zu verarbeiten, beispielsweise für die Verwendung in gängigen Business-Analytics-Plattformen.
-
Aktivieren Sie die Weiter Schaltfläche.
Es wird die Anzahl der zu exportierenden Probleme angezeigt.
-
Klicken Sie auf die Schaltfläche Exportieren .
Tipp: Die Datei erhält den entsprechenden Namen „export.json“ oder „export.csv“. Sie sollten sie daher für künftige Bezugnahme in einen aussagekräftigeren Namen umbenennen, insbesondere um Verwirrung zu vermeiden, wenn weitere Exporte geplant sind.
Exportdateiformate und -beschreibungen:
Der folgende Abschnitt beschreibt die am häufigsten verwendeten Exportformatoptionen mit ihren Spaltennamen und Beschreibungen.
JSON (mit axe Universal Format) (empfohlen):
| Spaltenname | Beschreibung |
|---|---|
| Produktname | Name des Produkts. axe-auditor, axe-monitor usw. |
| Produktkomponentenname | Produktquelle des heruntergeladenen JSON. z. B. axe-auditor, Extension-Chrome, API-CLI usw. |
| Produktversion | Version des Produkts. Beispiel: 2.18. |
| Test-ID | UUID des Testlaufs |
| Engine | Basis-Engine zum Ausführen der Tests. Z.B. axe-core, axe-pdf, axe-linter usw. |
| Best-Practices-Aktiviert | Ein Boolescher Wert zum Konfigurieren von Best-Practice-Problemen während des Tests. |
| Experimentell-Aktiviert | Ein Boolescher Wert zum Konfigurieren experimenteller Funktionen während des Tests. |
| Produkt | Benutzerdefinierter Wert zur Beschreibung des Produkts, das der Benutzer während des Tests bewertet. Dies gibt Benutzern die Flexibilität, Details zu dem Produkt hinzuzufügen, an dem der Test durchgeführt wurde. |
| Release | Zum Erstellen der Problemstellung verwendete Auditor-Release-Version. |
| Plattform | Benutzerdefinierte Werte, um die Plattform zu verfolgen, auf der das Problem erstellt wurde. In der Vergangenheit haben Benutzer Werte wie „Mac“, „Windows“, „Chrome“, „Android“, „Firefox“ verwendet. |
| Umgebung | Datenbankumgebung, aus der die Daten stammen. Die Einträge sind alle benutzerdefiniert. In der Vergangenheit haben Benutzer Werte wie „Dev“, „QA“, „UAT“, „Production“ verwendet. |
| digitalerAssetTyp | Digitaler Asset-Typ, für den der Test ausgeführt wurde. Zum Beispiel „Desktop-Web“, „Mobiles Web“, „Native Mobile Android“, „Native Mobile iOS“, „Kiosk“, „MS Excel-Dokumente“, „MS Powerpoint-Dokumente“, „MS Word-Dokumente“, „PDF“, „Desktop-Software“. |
| assistive Technologie | Benutzerdefinierte Werte zur Verfolgung der zum Testen verwendeten Software: „NVDA“, „VoiceOver“. |
| axeVersion | Verwendete Axe-Core-Version. Beispielsweise „4.9.0“. |
| testCaseName | Name des Testfalls, der die Definition eines Testszenarios im axe Auditor darstellt. |
| testRunName | Name des Testlaufs. |
| Startdatum | Erstellungsdatum des Testlaufs. |
| Enddatum | Datum der Beendigung des Testlaufs. |
| Standard | Für diesen Testlauf geltende Prüfnormen. |
| issue_source | Quelle des Problems. Benutzer können Probleme aus mehreren Quellen importieren und mithilfe dieser Spalte können Sie den Überblick über die Ursprungsquelle des Problems behalten. Mögliche Werte sind „axe Auditor“, „axe Dev Tools Extension“ und „axe Dev Tools Mobile“. |
| issueId | Eindeutige ID für jedes Problem in der Auditor-Datenbank. |
| Regel-ID | Regelsatz des Problems. Beispielsweise Farbkontrast. |
| Beschreibung | Beschreibung des Problems aus der Dequeway library, nur über die Dropdown-Liste auswählbar. |
| Hilfe | Beschreibung des Vorschlags oder der Abhilfemaßnahme. |
| helpUrl | URL für Vorschläge oder Abhilfemaßnahmen. |
| Einfluss | Spalte, die die Schwere des Problems definiert. Verfügbare Werte sind „Blocker“, „Kritisch“, „Schwerwiegend“, „Mittelschwer“ und „Geringfügig“. |
| Zusammenfassung | Ein Wert, der manuell eingegeben oder aus einer Dropdown-Liste ausgewählt wird. |
| Quelle | Quellcode des Problems. |
| Art | Zugänglichkeit, Best Practice, Funktionalität, Benutzerfreundlichkeit oder User-Agent. |
| Methode | Zum Protokollieren des Problems verwendete Methodik. Mögliche Werte sind: „Automatisiert“, „IGT“ oder „Manuell“. |
| Status | Aktueller Status des Problems zum Zeitpunkt des Exports. Mögliche Werte sind „Offen“, „Behoben“ oder „Geschlossen“. |
| Tags | Wird verwendet, um die Probleme zu kategorisieren. |
| Erstellt am | Datum und Uhrzeit der Erstellung des Problems. |
| Einheitenname | Die mit dem Problem verknüpfte Seite oder Komponente. |
| TESTURL | URL der getesteten Seite. |
| Einheitentyp | Einheitentyp – Seite oder Komponente. |
| Gruppenname | Der Name der Gruppe, zu der das Problem gehört. Wenn das Problem keiner Gruppe zugewiesen ist, ist dieses Feld leer. |
| Entdeckt von | Autor des Problems. |
| Kontrollpunkt | Checkpoints sind eine bewährte Methode zum Testen von Zugänglichkeitsanforderungen, die vom Barrierefreiheitsexpertenteam (a11y) von Deque entwickelt wurde. Sie tragen dazu bei, die Konsistenz und Genauigkeit der Testergebnisse zu erhöhen. Checkpoints Übersicht |
| benötigtÜberprüfung | Ein Boolescher Wert, der angibt, ob das Problem in die Kategorie „Benötigt Überprüfung“ fällt. |
| istExperimentell | Ein Boolescher Wert, der angibt, ob das Problem in die Kategorie „Experimentell“ fällt. |
| istManuell | Ein Boolescher Wert, der angibt, ob das Problem während eines manuellen Tests entstanden ist. |
| screenshoturl | Die URL des dem Problem beigefügten Screenshots. |
CSV (kompatibel mit Microsoft Excel)
| Spaltenname | Beschreibung |
|---|---|
| Problem-ID | Die eindeutige ID, die jedem Problem in der Auditor-Datenbank zugewiesen wird. |
| Zusammenfassung | Ein Wert, der manuell eingegeben oder aus einer Dropdown-Liste ausgewählt wird. |
| Beschreibung | Beschreibung des Problems aus der Dequeway library, nur über die Dropdown-Liste auswählbar. |
| Auswirkung | Spalte, die die Schwere des Problems definiert. Verfügbare Werte sind „Blocker“, „Kritisch“, „Schwerwiegend“, „Mittelschwer“ und „Geringfügig“. |
| Checkpoint-Gruppe | Dequeway terminology zum Gruppieren der Prüfpunkte. Beispielsweise wird „1.4 Unterscheidbar“ alle darin enthaltenen Prüfpunkte, wie etwa „1.4.1.a“, „1.4.2.b“ gruppiert. Prüfpunkte sind in der folgenden GitHub-Bibliothek aufgeführt: https://github.com/dequelabs/dequeway/tree/develop/content/checkpoints |
| Art des Problems | Zugänglichkeit, Best Practice, Funktionalität, Benutzerfreundlichkeit oder User-Agent. |
| Testeinheit | Die Seite oder Komponente, zu der das Problem gehört. |
| Behebung empfohlen | Empfehlung zur Behebung des Problems. Details stammen aus der Deque-Bibliothek, oder Benutzer geben manuelle Empfehlungen ein. |
| Benutzer | Benutzer, der das Problem protokolliert hat. |
| Name der Gruppe | Der Name der Gruppe, zu der das Problem gehört. Es bleibt leer, wenn das Problem keiner Gruppe zugewiesen ist. |
| Gruppenbeschreibung | Beschreibung, die dem Problem beim Erstellen oder Bearbeiten hinzugefügt wurde. |
| Gruppenstatus | Beim Erstellen oder Bearbeiten des Problems wurde dem Problem Status hinzugefügt. |
| Zuweisen an | Benutzer, dem die Gruppe zugewiesen ist. |
| Erstellungsdatum | Datum der Erstellung des Problems. |
| Digitaler Asset-Typ | Digitaler Asset-Typ, für den der Test ausgeführt wurde. Zum Beispiel: „Desktop-Web“, „Mobiles Web“, „Native Mobile Android“, „Native Mobile iOS“, „Kiosk“, „MS Excel-Dokumente“, „MS Powerpoint-Dokumente“, „MS Word-Dokumente“, „PDF“, „Desktop-Software“. |
| Version | Version von Axe Auditor, die zur Erstellung des Problems verwendet wurde. |
| Umgebung | Datenbankumgebung, aus der die Daten stammen. In der Vergangenheit haben Benutzer Werte wie „Dev“, „QA“, „UAT“, „Production“ verwendet. |
| Plattform | Benutzerdefinierte Werte, um die Plattform zu verfolgen, auf der das Problem erstellt wurde. In der Vergangenheit haben Benutzer Werte wie „Mac“, „Windows“, „Chrome“, „Android“, „Firefox“ verwendet. |
| Unterstützende Technologie | Benutzerdefinierte Werte zum Verfolgen der zum Testen von „NVDA“ und „VoiceOver“ verwendeten Software. |
| Quellcode | Quellcode des Problems. |
| Kontrollpunkt | Checkpoints sind eine bewährte Methode zum Testen von Zugänglichkeitsanforderungen, die vom Barrierefreiheitsexpertenteam (a11y) von Deque entwickelt wurde. Sie tragen dazu bei, die Konsistenz und Genauigkeit der Testergebnisse zu erhöhen. Checkpoints Overview |
| Verfahren | Zum Protokollieren des Problems verwendete Methodik. Mögliche Werte sind „Automatisch“, „IGT“ oder „Manuell“. |
| Problemstatus | Aktueller Status des Problems zum Zeitpunkt des Exports. Mögliche Werte sind „Offen“, „Behoben“ und „Geschlossen“. |
| Problemquelle | Quelle des Problems. Da Benutzer Probleme auch aus mehreren Quellen importieren können, wird in der Spalte die Ursprungsquelle des Problems verfolgt. Mögliche Werte sind „axe Auditor“, „axe Dev Tools Extension“ und „axe Dev Tools Mobile“. |
| Name des Testfalls | Name des Testfalls. Ein Testfall ist die Definition eines Testszenarios im axe Auditor. Testfälle verstehen |
| Normen | Auf dieses Problem anwendbare Prüfnormen. |
| Produkt | Benutzerdefinierter Wert zur Beschreibung, welches Produkt der Benutzer beim Testen bewertet. Dies gibt den Benutzern die Flexibilität, Details zum Produkt hinzuzufügen, an dem der Test durchgeführt wurde. |
| URL | URL der getesteten Seite. |
| Screenshots | Vom Benutzer hinzugefügte Screenshots liefern weitere Einzelheiten zum Problem. |
| Markiert | Wenn das Problem gekennzeichnet wurde und zusätzliche Überprüfung oder Klärung benötigt. |
| Aus einem bestimmten Grund markiert | Grund, warum das Problem markiert wurde. |
| Markiert von | Autor, der das jeweilige Problem markiert hat. |
| Einheitentyp | Seite oder Komponente. |
| Weitere Infos | Referenz von Deque University, bereitgestellt von Dequeway zum Zeitpunkt der Problemstellung. |
| Kommentare zum Problem | Kommentare von Benutzern, die im Kommentarbereich der Aufgabe interagieren. |
| Gruppennotizen | Notizen, die der Gruppe während der Erstellung oder Bearbeitung hinzugefügt wurden. |
| Screenshot der Testeinheit | Während des Unit-Tests aufgenommene Screenshots. |
| Name des Testlaufs | Name des Testlaufs. |
| Erfolgskriterien | Kriterien der Testrichtlinien. Dies ist ein abhängiger Wert der Spalte „Standard“. Beispielsweise bezieht sich „1.4.3“ auf den WCAG-Standard 1.4.3. |
| Fehler-URL | URL der Detailseite des Auditor-Problems. |