Fehlerbehebung

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

Anleitung zur Lösung von Problemen, die bei der Nutzung des Axe Developer Hub auftreten können

Not for use with personal data

Ein Projekt öffnen zeigt „Keine Scan-Daten verfügbar“

Wenn Sie bereits Barrierefreiheit-Scans durchgeführt haben und Ergebnisse erwarten, sollten Sie die Projektkonfiguration überprüfen.

Überprüfen Sie Ihren API-Schlüssel

Ihr persönlicher API-Schlüssel sollte mit Ihrem Projekttyp kompatibel sein. Für Projekte, die Axe Watcher, Web-APIs oder CLI integrieren, müssen Sie einen Axe Developer Hub API-Schlüssel verwenden. Für mobile Projekte müssen Sie einen Axe DevTools für Mobile API-Schlüssel verwenden. Um einen API-Schlüssel zu erstellen, benötigen Sie eine aktive Lizenz für Axe Developer Hub und/oder Axe DevTools für Mobile. Sobald Sie Zugriff haben, besuchen Sie API-Schlüssel, um einen neuen Schlüssel hinzuzufügen.

  1. Klicken Sie auf die Schaltfläche + NEUEN API-SCHLÜSSEL HINZUFÜGEN, und es erscheint ein Popup-Fenster wie das unten abgebildete: Ein NEUEN API-SCHLÜSSEL hinzufügen-Modul, das das Produkt als „Axe DevTools for Mobile“ anzeigt
  2. Wählen Sie Axe Developer Hub oder Axe DevTools für Mobile im Produkt Dropdown-Menü aus.
  3. Geben Sie dem API-Schlüssel einen Namen.
  4. Klicken Sie auf Speichern.

Nach ein paar Sekunden wird die aktualisierte Seite zum Verwalten von API-Schlüsseln angezeigt, zusammen mit einer Nachricht, dass der API-Schlüssel erfolgreich hinzugefügt wurde.

Klicken Sie in der Aktionen-Spalte für Ihre API-Schlüssel, um einen API-Schlüssel in die Zwischenablage zu kopieren. Sie sollten dann eine Nachricht sehen, dass der API-Schlüssel erfolgreich kopiert wurde.

Wenn Sie eingerichtet haben festlegen, haben Sie möglicherweise Code in Ihre End-to-End-Tests kopiert und eingefügt. Überprüfen Sie diesen Code und stellen Sie sicher, dass Sie API_KEY durch den entsprechenden API-Schlüssel ersetzt haben.

Überprüfen Sie Ihre Projekt-ID

Um Ihre Projekt-ID zu finden, navigieren Sie zu den Installationsanweisungen von der Projektseite. Öffnen Sie das Einstellungs-Dropdown für Ihr Projekt und wählen Sie Projekt konfigurieren. Sie sehen die Projekt-ID, die Sie anklicken und in die Zwischenablage kopieren können. Überprüfen Sie den Code, den Sie während Projekteinrichtung in Ihre End-to-End-Tests kopiert und eingefügt haben, und stellen Sie sicher, dass Sie alle Instanzen von PROJECT_ID durch die entsprechende Projekt-ID ersetzt haben.

Überprüfen Sie, dass der Scan-Ausgabe keine Fehler anzeigt

Im Fenster, in dem Ihr Test ausgeführt wird, können Fehler aufgetreten sein, die verhindert haben, dass die Ergebnisse an den Axe Developer Hub gesendet wurden. Überprüfen Sie diese Fehler sorgfältig und beheben Sie sie.

Überprüfen Sie, ob der Test erfolgreich abgeschlossen wurde

Wenn Ihr Test noch läuft, wurden Ihre Ergebnisse möglicherweise noch nicht an den Developer Hub gesendet. Warten Sie, bis Ihr Test erfolgreich abgeschlossen ist, und aktualisieren Sie dann die Seite, um Ihre Ergebnisse zu sehen.

Es werden nicht alle Scan-Ergebnisse angezeigt

Wenn Sie mehrfach den gleichen Commit scannen (gleicher Commit-SHA), können die Ergebnisse „überschrieben“ werden, sodass nur die neuesten angezeigt werden. Wenn Git-Daten verwendet werden, müssen Sie einen neuen Commit erstellen, um neue Scans zu sehen. Wenn Sie nicht bei jedem Testdurchlauf einen neuen Commit erstellen möchten und dieses Projekt noch nicht Git-gesperrt ist, vermeidet das Testen ohne Git dieses Problem.

Um eine Gitlose Ansicht einer Testreihe zu erhalten, senden Sie deren Ergebnisse an ein separates, Gitlos gesperrtes Projekt, anstatt zu versuchen, die Datenstruktur eines bestehenden Projekts zu ändern. Sobald ein Projekt nach seiner ersten erfolgreichen Sitzung auf Git gesperrt ist, führt das Löschen des .git-Ordners oder das Abstellen der Git-Datenerfassung nicht mehr zu einer Gitlosen Sitzung: Der Lauf wird stattdessen abgelehnt. Siehe Lauf abgelehnt: Datenstruktur oder Repository stimmt nicht mit dem Projekt überein, um zu sehen, wie die Ablehnung aussieht und wie Sie sie beheben können.

Als bewährte Praxis sollten Sie die Testsuite jedes Mal ausführen, wenn ein neuer Commit erstellt wird.

Git-Daten stimmen nicht mit dem Code überein

Wenn End-to-End-Tests in einem separaten Repository von dem Code, den Sie testen, durchgeführt werden, werden die angezeigten Git-Daten für den Test und nicht den Code, den Sie testen, sein. Wenn dies zu Verwirrung führt und dieses Projekt noch nicht Git-gesperrt ist, vermeidet das Testen ohne Git dies.

Um eine Gitlose Ansicht einer Testreihe zu erhalten, senden Sie deren Ergebnisse an ein separates, Gitlos gesperrtes Projekt, anstatt zu versuchen, die Datenstruktur eines bestehenden Projekts zu ändern. Sobald ein Projekt nach seiner ersten erfolgreichen Sitzung auf Git gesperrt ist, führt das Löschen des .git-Ordners oder das Abstellen der Git-Datenerfassung nicht mehr zu einer Gitlosen Sitzung: Der Lauf wird stattdessen abgelehnt. Siehe Lauf abgelehnt: Datenstruktur oder Repository stimmt nicht mit dem Projekt überein, um zu sehen, wie die Ablehnung aussieht und wie Sie sie beheben können.

Als bewährte Praxis empfehlen wir, dass Sie die End-to-End-Tests im selben Repository wie den Code halten, den Sie testen.

Lauf abgelehnt: Datenform oder Repository stimmt nicht mit dem Projekt überein

Sobald ein Projekt seine erste erfolgreiche Sitzung aufgenommen hat, sind seine Datenform (Git oder Gitless) und, bei Git-Projekten, sein Repository gesperrt. Ein Lauf, der nicht mit der Sperrung übereinstimmt, wird bei der Aufnahme abgelehnt und die Ergebnisse werden nicht gespeichert. Die Ablehnungsnachricht benennt, was das Projekt erwartet, was der Lauf gesendet hat und was dagegen zu tun ist, zum Beispiel:

This project is locked to a different repository. Project expects {lockedRepo}; this run sent {incomingRepo}. The results were not ingested. Send this run to its own Axe Developer Hub project, or check that CI is providing git information for the locked repository.

Häufige Ursachen und wie man sie behebt:

  • Ein zweites Repository oder eine Testsuite ist auf dasselbe Projekt ausgerichtet. Senden Sie es stattdessen an sein eigenes Projekt, anstatt es an eines zu senden, das bereits auf ein anderes Repository gesperrt ist.
  • Ein flacher Klon, ein detachable HEAD-Zustand oder ein fehlender origin Remote entfernt die Repository-URL, den Branch oder den Commit-SHA aus dem CI, wodurch ein Git-Lauf wie ein Gitloser aussieht. Überprüfen Sie, ob Ihre CI-Konfiguration vollständige Git-Informationen bereitstellt. Siehe Axe Watcher in Continuous Integration (CI) Umgebungen für CI-spezifische Anleitungen.
  • Die Git-Datensammlung wurde bei einem bereits auf Git gesperrten Projekt ausgeschaltet. Das Senden eines Laufs mit git: false oder mit entferntem .git-Ordner wandelt das Projekt nicht mehr in Gitlos um; der Lauf wird abgelehnt. Senden Sie Gitlose Läufe stattdessen an ein separates, gitloses Projekt.

Hilfe

Besuchen Sie support.deque.com, um auf Artikel der Wissensdatenbank, Statusberichte zu Deques SaaS-Produkt und weiteren Produktsupport zuzugreifen. Wenn Sie Ihr Problem nicht lösen können, schicken Sie uns eine E-Mail Sie uns bitte, damit wir helfen können.