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, um Entwicklern dabei zu helfen, Regressionsbereiche während des Entwicklungszyklus zu lokalisieren und zu verhindern (einschließlich Testüberwachung und Triaging-Unterstützung).
Die VTS-Dashboard-Benutzeroberfläche unterstützt von der VTS-Infrastruktur bereitgestellte Funktionen (z. B. native Codeabdeckung) und bietet eine kontinuierliche Leistungsüberwachung, um die Entwicklung optimierter und gut charakterisierter Leistungstools zu ermöglichen.
Anforderungen
Für die Nutzung des VTS-Dashboards sind folgende Dienste erforderlich:
- Apache Maven zum Erstellen und Bereitstellen
- Google Cloud App Engine für Webdienst-Hosting
- Google Cloud Datastore zur Speicherung
- Google Stackdriver zur Überwachung
Die Anzeige der Testabdeckung basiert auf einer REST-API zu einem Quellcodeserver (z. B. Gerrit), die es dem Webdienst ermöglicht, den Originalquellcode gemäß vorhandenen Zugriffskontrolllisten abzurufen.
Die Architektur
Das VTS-Dashboard verwendet die folgende Architektur:
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 und liefern und verarbeiten Daten aus der Datastore-Datenbank. Zu den Servlets gehören: ein Hauptservlet zum Bereitstellen aller Tests, ein Präferenzservlet zum Verwalten von Benutzerfavoriten, ein Ergebnisservlet zum Füllen einer Testtabelle, ein Diagrammservlet zum Vorbereiten von Profilierungsdaten und ein Abdeckungsservlet zum Vorbereiten von Abdeckungsdaten für den Client .
Jedes Testmodul verfügt über einen eigenen Datenspeicher-Abstammungsbaum und die Testergebnisse werden mit dem Unix-Zeitstempel der Teststartzeit indiziert. Die Abdeckungsdaten in der Datenbank werden zusammen mit den Testergebnissen als Zählvektor (dh für jede Zeile in der ursprünglichen Quelldatei) und identifizierenden Informationen zum Abrufen des Quellcodes von einem Quellcodeserver gespeichert.
Der Benachrichtigungsdienst wird mithilfe von Aufgabenwarteschlangen ausgeführt, identifiziert Statusänderungen von Testfällen und benachrichtigt Abonnenten. Zustandsbezogene Informationen werden in einer Statustabelle gespeichert, um den Überblick über die Aktualität der Daten und vorhandene Fehler zu behalten. Dadurch kann der Benachrichtigungsdienst umfassende Informationen zu einzelnen Testfallfehlern und -korrekturen bereitstellen.
Codestruktur
Zu den wesentlichen Komponenten des VTS-Dashboards gehören die in Java implementierten Servlets, die Front-End-JSPs, CSS-Stylesheets und Konfigurationsdateien. In der folgenden Liste sind die Speicherorte und Beschreibungen dieser Komponenten aufgeführt (alle Pfade relativ zu 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ßlichVtsReportMessage.java, einer Java-Implementierung des Protobuf-Typs, die zur Beschreibung von VTS-Testergebnissen verwendet wird. -
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 Dienstprogramme. -
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 die Umgebungsvariablen in Variablen geladen werden. -
web.xml
Einstellungsdatei, in der Servlet-Zuordnungen und Sicherheitseinschränkungen definiert werden. -
cron.xml
Einstellungsdatei, die geplante Aufgaben definiert (z. B. den Benachrichtigungsdienst).
Richten Sie das Dashboard ein
So richten Sie das VTS-Dashboard ein:
- 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
- Generieren Sie eine OAuth 2.0-Client-ID im Google Cloud API Manager.
- Erstellen Sie ein Dienstkonto und eine Schlüsseldatei.
- Fügen Sie eine E-Mail-Adresse zur Liste der autorisierten Absender der App Engine-E-Mail-API hinzu.
- Richten Sie ein Google Analytics-Konto ein.
- Geben Sie Umgebungsvariablen im Dashboard
pom.xmlan:- 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 E-Mail-Adresse des Absenders für Benachrichtigungen 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 (ab Schritt 5).
- Erstellen Sie das Projekt und stellen Sie es bereit.
- Führen Sie in einem Terminal
mvn clean appengine:updateaus.
Sicherheitsüberlegungen
Für zuverlässige Abdeckungsinformationen ist der Zugriff auf den Originalquellcode erforderlich. Allerdings kann es sein, dass ein Teil des Codes vertraulich ist und ein zusätzlicher Gateway dazu die Ausnutzung bestehender Zugriffskontrolllisten ermöglichen kann.
Um diese Bedrohung zu vermeiden, verarbeitet das Dashboard nicht den Quellcode mit den Abdeckungsinformationen, sondern direkt einen Abdeckungsvektor (d. h. einen Vektor der Ausführungszählungen, die Zeilen in einer Quelldatei zugeordnet werden). 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 Client-Browser empfängt diese Informationen und nutzt Cross-Origin Resource Sharing (CORS) in Javascript, um den Quellcode-Server 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 zur Authentifizierung bei einem externen Dienst verwendet (was bedeutet, dass ein Benutzer, der nicht direkt auf den Quellcode zugreifen kann, das Dashboard nicht zum Anzeigen vertraulicher Informationen nutzen kann).