Probleme exportieren
This page is not available in the language you requested. You have been redirected to the English version of the page.
Link to this page copied to clipboard
Not for use with personal data
Der Bildschirm mit der Problemliste bietet Ihnen eine Exportfunktion, die durch das Aktivieren der Exportieren-Schaltfläche im Dropdown-Menü „Aktionen“ oben in der Problemtabelle gestartet wird. Probleme können exportiert werden, auch wenn Sie nicht alle als abgeschlossen markiert haben.
Um Probleme zu exportieren:
- Wählen Sie in der linken Spalte alle Probleme aus, die Sie exportieren möchten. Aktivieren Sie das leere Kontrollkästchen, um ein Häkchen darin zu setzen und Ihre Auswahl für alle gewünschten Problemzeilen anzuzeigen. Oben links in der Tabelle wird eine Nachricht angezeigt, um die Anzahl der ausgewählten Probleme anzuzeigen.
-
Wählen Sie die Option im Dropdown-Menü „Aktionen“ und aktivieren Sie die Export -Schaltfläche.
Das Dialogfeld „Probleme exportieren“ wird angezeigt. -
Wählen Sie eine Exporttyp-Option.
- CSV (compatible with Microsoft Excel): Kommagetrenntes Werteformat, das nützlich zum Import in Tabellenkalkulationen oder Datenbanken ist.
- CSV: Standard-Kommagetrenntes Werteformat, das nützlich zum Import in Tabellenkalkulationen oder Datenbanken ist.
- JSON: JavaScript-Objektformat, das nützlich für den Import in Issue-Tracking-Systeme wie JIRA ist.
- JSON (with axe universal format): JSON-Format im Einklang mit einem universellen Exportformat, das von allen axe-Produkten geteilt wird. Nützlich zum Extrahieren von Daten über mehrere axe-Tools hinweg für Business-Analytics-Plattformen.
-
Aktivieren Sie die Next -Schaltfläche.
Die Anzahl der zu exportierenden Probleme wird angezeigt. -
Klicken Sie auf die Export -Schaltfläche.
Tip: Die Datei wird entsprechend als ‚export.json‘ oder ‚export.csv‘ benannt, daher sollten Sie sie in etwas Bedeutenderes umbenennen für zukünftige Verweise, insbesondere wenn weitere Exporte geplant sind.
Export-Dateiformate und Beschreibungen:
Der folgende Abschnitt beschreibt die am häufigsten verwendeten Exportformat-Optionen mit ihren Spaltennamen und Beschreibungen.
JSON (Mit axe-Universalformat) (Empfohlen):
| Spaltenname | Beschreibung |
|---|---|
| productName | Name des Produkts. axe-auditor, axe-monitor etc. |
| productComponentName | Produktquelle des heruntergeladenen JSON. z. B. axe-auditor, extension-chrome, api-cli etc. |
| productVersion | Version des Produkts. z. B.: 2.18. |
| testId | UUID des Testdurchlaufs |
| engine | Basisengine zur Durchführung der Tests. z. B. axe-core, axe-pdf, axe-linter etc. |
| bestPracticesEnabled | Ein boolescher Wert zur Konfiguration von Best-Practice-Problemen während des Testens. |
| experimentalEnabled | Ein boolescher Wert zur Konfiguration von experimentellen Problemen während des Testens. |
| product | Benutzerdefinierter Wert zur Beschreibung des Produkts, das der Benutzer während des Testens bewertet. Dies gibt den Benutzern die Flexibilität, Details zu dem Produkt hinzuzufügen, auf dem die Tests durchgeführt wurden. |
| release | Veröffentlichungsversion des Auditors, die zur Erstellung des Problems verwendet wurde. |
| platform | Benutzerdefinierte Werte zur Nachverfolgung der Plattform, auf der das Problem erstellt wurde. Historisch gesehen haben Benutzer Werte wie „Mac“, „Windows“, „Chrome“, „Android“, „Firefox“ verwendet. |
| Environment | Datenbankumgebung, aus der die Daten stammen. Einträge sind alle benutzerdefiniert. Historisch gesehen haben Benutzer Werte wie „Dev“, „QA“, „UAT“, „Production“ verwendet. |
| digitalAssetType | Digital Asset-Typ, gegen den der Test ausgeführt wurde. Zum Beispiel: „Desktop Web“, „Mobile Web“, „Native Mobile Android“, „Native Mobile iOS“, „Kiosk“, „MS Excel Documents“, „MS Powerpoint Documents“, „MS Word Documents“, „PDF“, „Desktop Software“. |
| assistiveTechnology | Benutzerdefinierte Werte zur Nachverfolgung der Software, die zum Testen verwendet wurde: „NVDA“, „VoiceOver“. |
| axeVersion | Verwendete axe-core Version. Zum Beispiel: „4.9.0“. |
| testfallName | Name des Testfalls, der die Definition eines Testszenarios in axe Auditor ist. |
| testlaufName | Name des Testlaufs. |
| startDatum | Erstellungsdatum des Testlaufs. |
| endDatum | Abschlussdatum des Testlaufs. |
| standard | Teststandards, die auf diesen Testlauf anwendbar sind. |
| fehlerquelle | Quelle des Fehlers. Benutzer können Fehler aus mehreren Quellen importieren, und diese Spalte hilft, die Herkunftsquelle des Fehlers zu verfolgen. Mögliche Werte sind „axe Auditor“, „axe Dev Tools Extension“ und „axe Dev Tools Mobile“. |
| fehlerId | Eindeutige ID für jeden Fehler in der Auditor-Datenbank. |
| regelId | Fehler-Regelset. Zum Beispiel Farbkontrast. |
| beschreibung | Beschreibung des Fehlers aus der Dequeway-Bibliothek, nur über das Dropdown auswählbar. |
| hilfe | Vorschlag oder Beschreibung der Abhilfe. |
| hilfeUrl | Vorschlags- oder Abhilfe-URL. |
| auswirkung | Spalte zur Definition der Schwere des Fehlers. Verfügbare Werte sind „Blocker“, „Kritisch“, „Schwerwiegend“, „Moderat“ oder „Geringfügig“. |
| zusammenfassung | Ein Wert, der manuell eingegeben oder aus einem Dropdown ausgewählt wird. |
| quelle | Quellcode des Fehlers. |
| typ | Barrierefreiheit, Best Practice, Funktionalität, Benutzerfreundlichkeit oder Benutzer-Agent. |
| methode | Methodik, die zur Protokollierung des Fehlers verwendet wird. Mögliche Werte sind: „Automatisiert“, „IGT“ oder „Manuell“. |
| status | Aktueller Status des Fehlers zum Zeitpunkt des Exports. Mögliche Werte sind „Offen“, „Behoben“ oder „Geschlossen“. |
| tags | Verwendung zur Kategorisierung der Fehler. |
| erstelltAm | Datum und Uhrzeit, wann der Fehler erstellt wurde. |
| einheitsName | Die Seite oder Komponente, die mit dem Fehler verbunden ist. |
| testUrl | URL der getesteten Seite. |
| einheitsTyp | Typ der Einheit - Seite oder Komponente. |
| gruppenName | Der Name der Gruppe, zu der der Fehler gehört. Wenn der Fehler keiner Gruppe zugeordnet ist, bleibt dieses Feld leer. |
| gefundenVon | Autor des Fehlers. |
| kontrollpunkt | Checkpoints sind eine bewährte Methode zum Testen von Barrierefreiheitsanforderungen, entwickelt vom Expertenteam für Barrierefreiheit (a11y) von Deque. Sie tragen zur Erhöhung der Konsistenz und Genauigkeit der Testergebnisse bei. Kontrollpunkte Übersicht |
| needsReview | Ein boolescher Wert, der angibt, ob das Problem in die Kategorie „Muss überprüft werden“ fällt. |
| isExperimental | Ein boolescher Wert, der angibt, ob das Problem in die Kategorie „Experimentell“ fällt. |
| isManual | Ein boolescher Wert, der angibt, ob das Problem während manueller Tests erstellt wurde. |
| screenshotUrl | Die URL des mit dem Problem verknüpften 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 einem Dropdown ausgewählt wird. |
| Beschreibung | Beschreibung des Fehlers aus der Dequeway-Bibliothek, nur über das Dropdown auswählbar. |
| Auswirkung | Kolumne, die die Schwere des Problems definiert. Verfügbare Werte sind „Blocker“, „Kritisch“, „Ernst“, „Moderat“ oder „Gering“. |
| Checkpoint-Gruppe | Dequeway-Terminologie zur Gruppierung der Checkpoints. Zum Beispiel wird „1.4 Unterscheidbar“ alle darin enthaltenen Checkpoints gruppieren, wie „1.4.1.a“, „1.4.2.b“. Die Checkpoints sind in der folgenden GitHub-Bibliothek aufgelistet: https://github.com/dequelabs/dequeway/tree/develop/content/checkpoints |
| Problemart | Barrierefreiheit, Best Practice, Funktionalität, Benutzerfreundlichkeit oder Benutzer-Agent. |
| Testeinheit | Die Seite oder Komponente, zu der das Problem gehört. |
| Empfehlung zur Behebung | Empfehlung zur Behebung des Problems. Details stammen aus der Dequeway-Bibliothek oder Benutzer geben manuelle Empfehlungen ein. |
| Benutzer | Benutzer, der das Problem protokolliert hat. |
| Gruppenname | Der Name der Gruppe, zu der das Problem gehört. Es bleibt leer, wenn das Problem keiner Gruppe zugewiesen ist. |
| Gruppenbeschreibung | Beschreibung, die beim Erstellen oder Bearbeiten des Problems zur Gruppe hinzugefügt wurde. |
| Gruppenstatus | Status, der beim Erstellen oder Bearbeiten des Problems zur Gruppe hinzugefügt wurde. |
| Zuweisen an | Benutzer, dem die Gruppe zugewiesen ist. |
| Erstellungsdatum | Erstellungsdatum des Problems. |
| Typ des digitalen Assets | Typ des digitalen Assets, gegen den der Test ausgeführt wurde. Zum Beispiel: „Desktop Web“, „Mobile Web“, „Native Mobile Android“, „Native Mobile iOS“, „Kiosk“, „MS Excel-Dokumente“, „MS Powerpoint-Dokumente“, "MS Word-Dokumente", "PDF", „Desktop-Software“. |
| Version | Axe Auditor-Version, die zur Erstellung des Problems verwendet wurde. |
| Environment | Datenbankumgebung, aus der die Daten kommen. Historisch gesehen haben Benutzer Werte wie „Dev“, „QA“, „UAT“, „Production“ verwendet. |
| Plattform | Benutzerdefinierte Werte zur Nachverfolgung der Plattform, auf der das Problem erstellt wurde. Historisch gesehen haben Benutzer Werte wie „Mac“, „Windows“, „Chrome“, „Android“, „Firefox“ verwendet. |
| Unterstützende Technologie | Vom Benutzer definierte Werte zur Nachverfolgung der Software, die zum Testen verwendet wird, wie „NVDA“, „VoiceOver“. |
| Quellcode | Quellcode des Problems. |
| Checkpoint | Checkpoints sind eine bewährte Methode zum Testen von Barrierefreiheitsanforderungen, entwickelt vom Expertenteam für Barrierefreiheit (a11y) von Deque. Sie tragen zur Erhöhung der Konsistenz und Genauigkeit der Testergebnisse bei. Kontrollpunkte Übersicht |
| Methode | Methodik, die zur Erfassung des Problems verwendet wurde. Mögliche Werte sind "Automatisiert", "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, verfolgt die Spalte die ursprüngliche Quelle des Problems. Mögliche Werte sind „axe Auditor“, „axe Dev Tools Extension“ und „axe Dev Tools Mobile“. |
| Testfallname | Name des Testfalls. Ein Testfall ist die Definition eines Testszenarios im axe Auditor. Testfälle verstehen |
| Standards | Teststandards, die auf dieses Problem anwendbar sind. |
| Produkt | Vom Benutzer definierter Wert, um zu beschreiben, welches Produkt der Benutzer beim Testen bewertet. Dies gibt den Benutzern die Flexibilität, Details über das getestete Produkt hinzuzufügen. |
| URL | URL der getesteten Seite. |
| Anhänge | Vom Benutzer hinzugefügte Anhänge, um zusätzliche Details zum Problem bereitzustellen. |
| Markiert | Ob das Problem markiert wurde und eine zusätzliche Überprüfung oder Klärung benötigt. |
| Markierungsgrund | Grund, warum das Problem markiert wurde. |
| Markiert von | Autor, der das jeweilige Problem markiert hat. |
| Einheitstyp | Seite oder Komponente. |
| Weitere Informationen | Referenz der Deque University, bereitgestellt von Dequeway zum Zeitpunkt der Problemerstellung. |
| Problemkommentare | Kommentare von Benutzern, die im Kommentarteil des Problems interagieren. |
| Gruppennotizen | Notizen, die während der Erstellung oder Bearbeitung zur Gruppe hinzugefügt wurden. |
| Screenshot der Testeinheit | Screenshots, die während des Tests der Testeinheit gemacht wurden. |
| Testlaufname | Name des Testlaufs. |
| Erfolgskriterien | Teststandardkriterien. Dies ist ein abhängiger Wert der Standardsäule. Zum Beispiel bezieht sich „1.4.3“ auf den WCAG-Standard 1.4.3. |
| Problem-URL | URL der Auditor-Problemdetailseite. |