Einrichtung des VTS-Dashboards

Das VTS-Dashboard bietet ein Benutzer-Backend und eine Benutzeroberfläche (UI) zum Anzeigen von Testergebnissen aus dem VTS-Continuous-Integration-System. Es unterstützt die testgetriebene Entwicklung mit Tools wie Teststatusbenachrichtigungen, die Entwicklern helfen, Regressionsbereiche während des Entwicklungszyklus zu lokalisieren und zu verhindern (einschließlich Testüberwachung und Triaging-Unterstützung).

Die Benutzeroberfläche des VTS-Dashboards unterstützt Funktionen (z. B. native Codeabdeckung), die von der VTS-Infrastruktur bereitgestellt werden, und bietet eine kontinuierliche Leistungsüberwachung, um die Entwicklung optimierter und gut charakterisierter Leistungstools zu ermöglichen.

Anforderungen

Die folgenden Dienste sind erforderlich, um das VTS-Dashboard zu verwenden:

Anzeigen von Testabdeckung beruht auf einer REST API auf einen Quellcode - Server (zB Gerrit), die den Web - Service ermöglicht ursprünglichen Quellcode holt nach den bestehenden Zugriffskontrolllisten.

Die Architektur

Das VTS-Dashboard verwendet die folgende Architektur:

Abbildung 1. Architektur des VTS-Dashboards.

Teststatusergebnisse werden kontinuierlich über eine REST-Schnittstelle in die Cloud Datastore-Datenbank hochgeladen. Der VTS-Runner verarbeitet die Ergebnisse automatisch und serialisiert sie im Protobuf-Format.

Web-Servlets bilden den primären Zugangspunkt für Benutzer, die Daten aus der Datastore-Datenbank bereitstellen und verarbeiten. Die Servlets umfassen: ein Haupt-Servlet zum Bereitstellen aller Tests, ein Preferences-Servlet zum Verwalten von Benutzerfavoriten, ein Ergebnis-Servlet zum Auffüllen einer Testtabelle, ein Graph-Servlet zum Vorbereiten von Profiling-Daten und ein Coverage-Servlet zum Vorbereiten von Coverage-Daten für den Client .

Jedes Testmodul hat seinen eigenen Datastore-Vorfahrenbaum und die Testergebnisse werden mit dem Unix-Zeitstempel der Teststartzeit indiziert. Abdeckungsdaten in der Datenbank werden mit den Testergebnissen als Vektor von Zählungen (dh für jede Zeile in der ursprünglichen Quelldatei) und Identifizierungsinformationen zum Abrufen des Quellcodes von einem Quellcodeserver gespeichert.

Der Benachrichtigungsdienst wird unter Verwendung von Aufgabenwarteschlangen ausgeführt, identifiziert Statusänderungen von Testfällen und benachrichtigt Abonnenten. Zustandsbehaftete Informationen werden in einer Statustabelle gespeichert, um die Aktualität der Daten und vorhandene Fehler zu verfolgen. Dadurch kann der Benachrichtigungsdienst umfassende Informationen zu einzelnen Testfallfehlern und -korrekturen bereitstellen.

Codestruktur

Zu den wesentlichen Komponenten von VTS Dashboard gehören die in Java implementierten Servlets, die Front-End-JSPs, CSS-Stylesheets und Konfigurationsdateien. In der folgenden Liste werden die Standorte und Beschreibungen dieser Komponenten (alle Pfade relativ zum test/vts/web/dashboard ):

  • pom.xml
    Einstellungsdatei, in der Umgebungsvariablen und Abhängigkeiten definiert werden.
  • src/main/java/com/android/vts/api/
    Enthält Endpunkte für die Interaktion mit den Daten über REST.
  • src/main/java/com/android/vts/entity/
    Enthält Java-Modelle der Datastore-Entitäten.
  • src/main/java/com/android/vts/proto/
    Enthält Java - Dateien für Protobuf, einschließlich VtsReportMessage.java , die eine Java - Implementierung von Protobuf Typ verwendet , um VTS Testergebnisse zu beschreiben.
  • src/main/java/com/android/vts/servlet/
    Enthält Java-Dateien für Servlets.
  • src/main/java/com/android/vts/util/
    Enthält Java-Dateien für Dienstprogrammfunktionen und -klassen, die von den Servlets verwendet werden.
  • src/test/java/com/android/vts/
    Enthält UI-Tests für die Servlets und Utils.
  • src/main/webapp/
    Enthält Dateien im Zusammenhang mit der Benutzeroberfläche (JSP, CSS, XML):
    • js/ . Enthält Javascript-Dateien, die von den Webseiten verwendet werden.
    • WEB-INF/ . Enthält Konfigurations- und UI-Dateien.
    • jsp/ . Enthält die JSP-Dateien für jede Webseite.
  • appengine-web.xml
    Einstellungsdatei, in der Umgebungsvariablen in Variablen geladen werden.
  • web.xml
    Einstellungsdatei, in der Servlet-Zuordnungen und Sicherheitseinschränkungen definiert sind.
  • cron.xml
    Einstellungsdatei, die geplante Aufgaben definiert (dh den Benachrichtigungsdienst).

Einrichten des Dashboards

So richten Sie das VTS-Dashboard ein:

  1. Erstellen Sie ein Google Cloud App Engine-Projekt und richten Sie den Bereitstellungshost ein, indem Sie Folgendes installieren:
    • Java 8
    • Google App Engine-SDK
    • Maven
  2. Generieren Sie eine OAuth 2.0-Client-ID im Google Cloud API Manager.
  3. Erstellen Sie ein Dienstkonto und erstellen Sie eine Schlüsseldatei.
  4. Fügen Sie der Liste der autorisierten Absender der App Engine Email API eine E-Mail-Adresse hinzu.
  5. Richten Sie ein Google Analytics-Konto ein.
  6. Geben Sie Umgebungsvariablen im Dashboard pom.xml :
    • Legen Sie die Client-ID mit der OAuth 2.0-ID fest (aus Schritt 2).
    • Legen Sie die Service-Client-ID mit der in der Schlüsseldatei enthaltenen Kennung fest (aus Schritt 3).
    • Geben Sie die Absender-E-Mail-Adresse für Warnungen an (ab Schritt 4).
    • Geben Sie eine E-Mail-Domäne an, an die alle E-Mails gesendet werden.
    • Geben Sie die Adresse des Gerrit REST-Servers an.
    • Geben Sie den OAuth 2.0-Bereich an, der für den Gerrit-REST-Server verwendet werden soll.
    • Geben Sie die Google Analytics-ID an (aus Schritt 5).
    • Erstellen Sie das Projekt und stellen Sie es bereit.
  7. In einem Terminal laufen mvn clean appengine:update .

Sicherheitsüberlegungen

Robuste Abdeckungsinformationen erfordern den Zugriff auf den ursprünglichen Quellcode. Einige Codes können jedoch sensibel sein und ein zusätzliches Gateway dazu kann die Ausnutzung vorhandener Zugriffskontrolllisten ermöglichen.

Um diese Bedrohung zu vermeiden, verarbeitet das Dashboard, anstatt den Quellcode mit den Abdeckungsinformationen zu versorgen, direkt einen Abdeckungsvektor (dh ein Ausführungsvektor zählt die Zuordnung zu Zeilen in einer Quelldatei). Zusammen mit dem Abdeckungsvektor erhält das Dashboard einen Git-Projektnamen und -pfad, damit der Client den Code von einer externen Quellcode-API abrufen kann. Der Clientbrowser empfängt diese Informationen und verwendet Cross-Origin Resource Sharing (CORS) in Javascript, um den Quellcodeserver nach dem ursprünglichen Quellcode abzufragen; der resultierende Code wird mit dem Abdeckungsvektor kombiniert, um eine Anzeige zu erzeugen.

Dieser direkte Ansatz erweitert die Angriffsfläche nicht, da das Dashboard die Cookies des Benutzers verwendet, um sich bei einem externen Dienst zu authentifizieren (was bedeutet, dass ein Benutzer, der nicht direkt auf den Quellcode zugreifen kann, das Dashboard nicht ausnutzen kann, um vertrauliche Informationen anzuzeigen).