VTS Dashboard zapewnia zaplecze użytkownika i interfejs użytkownika (UI) do przeglądania wyników testów z systemu ciągłej integracji VTS. Obsługuje rozwój oparty na testach za pomocą narzędzi, takich jak powiadomienia o stanie testów, aby pomóc programistom lokalizować obszary regresji i zapobiegać im w trakcie cyklu programowania (w tym monitorowanie testów i obsługa segregacji).
Interfejs użytkownika VTS Dashboard obsługuje funkcje (takie jak pokrycie kodu natywnego) zapewniane przez infrastrukturę VTS i oferuje ciągłe monitorowanie wydajności, aby umożliwić rozwój zoptymalizowanych i dobrze scharakteryzowanych narzędzi wydajnościowych.
Wymagania
Do korzystania z Pulpitu VTS niezbędne są następujące usługi:
- Apache Maven do budowania i wdrażania
- Google Cloud App Engine do hostingu usług internetowych
- Google Cloud Datastore do przechowywania
- Google Stackdriver do monitorowania
Przeglądanie zasięgu testów opiera się na interfejsie API REST dla serwera kodu źródłowego (np. Gerrit), który umożliwia usłudze internetowej pobranie oryginalnego kodu źródłowego zgodnie z istniejącymi listami kontroli dostępu.
Architektura
Pulpit VTS Dashboard wykorzystuje następującą architekturę:
Wyniki stanu testów są na bieżąco przesyłane do bazy danych Cloud Datastore za pośrednictwem interfejsu REST. Moduł VTS automatycznie przetwarza wyniki i serializuje je w formacie Protobuf.
Serwlety sieciowe stanowią główny punkt dostępu dla użytkowników, dostarczający i przetwarzający dane z bazy danych Datastore. Serwlety obejmują: główny serwlet do dostarczania wszystkich testów, serwlet preferencji do zarządzania ulubionymi użytkownikami, serwlet wyników do wypełniania tabeli testowej, serwlet wykresu do przygotowywania danych profilowania oraz serwlet pokrycia do przygotowywania danych pokrycia dla klienta .
Każdy moduł testowy ma własne drzewo przodków Datastore, a wyniki testów są indeksowane za pomocą uniksowego znacznika czasu rozpoczęcia testu. Dane pokrycia w bazie danych są przechowywane wraz z wynikami testów jako wektor zliczeń (tj. dla każdej linii w oryginalnym pliku źródłowym) oraz informacje identyfikujące potrzebne do pobrania kodu źródłowego z serwera kodu źródłowego.
Usługa powiadomień działa przy użyciu kolejek zadań, identyfikując zmiany stanu przypadków testowych i powiadamiając subskrybentów. Informacje stanowe są przechowywane w tabeli stanu, aby śledzić aktualność danych i istniejące awarie. Dzięki temu usługa powiadomień może dostarczać szczegółowe informacje na temat błędów i poprawek poszczególnych przypadków testowych.
Struktura kodu
Podstawowe komponenty VTS Dashboard obejmują serwlety zaimplementowane w Javie, front-endowe strony JSP, arkusze stylów CSS i pliki konfiguracyjne. Poniższa lista zawiera szczegółowe informacje o lokalizacjach i opisach tych komponentów (wszystkie ścieżki względem test/vts/web/dashboard ):
-
pom.xml
Plik ustawień, w którym zdefiniowane są zmienne środowiskowe i zależności. -
src/main/java/com/android/vts/api/
Zawiera punkty końcowe umożliwiające interakcję z danymi za pośrednictwem protokołu REST. -
src/main/java/com/android/vts/entity/
Zawiera modele Java jednostek Datastore. -
src/main/java/com/android/vts/proto/
Zawiera pliki Java dla Protobuf, w tymVtsReportMessage.java, który jest implementacją Java typu Protobuf używaną do opisywania wyników testów VTS. -
src/main/java/com/android/vts/servlet/
Zawiera pliki Java dla serwletów. -
src/main/java/com/android/vts/util/
Zawiera pliki Java z funkcjami narzędziowymi i klasami używanymi przez serwlety. -
src/test/java/com/android/vts/
Zawiera testy interfejsu użytkownika dla serwletów i narzędzi. -
src/main/webapp/
Zawiera pliki związane z interfejsem użytkownika (JSP, CSS, XML):-
js/. Zawiera pliki JavaScript używane przez strony internetowe. -
WEB-INF/. Zawiera pliki konfiguracyjne i interfejsu użytkownika. -
jsp/. Zawiera pliki JSP dla każdej strony internetowej.
-
-
appengine-web.xml
Plik ustawień, w którym zmienne środowiskowe są ładowane do zmiennych. -
web.xml
Plik ustawień, w którym definiuje się mapowania serwletów i ograniczenia bezpieczeństwa. -
cron.xml
Plik ustawień definiujący zaplanowane zadania (tj. usługę powiadomień).
Skonfiguruj pulpit nawigacyjny
Aby skonfigurować Panel VTS:
- Utwórz projekt Google Cloud App Engine i skonfiguruj hosta wdrożenia, instalując:
- Java 8
- SDK Google App Engine
- Mavena
- Wygeneruj identyfikator klienta OAuth 2.0 w menedżerze Google Cloud API.
- Utwórz konto usługi i utwórz plik klucza.
- Dodaj adres e-mail do listy autoryzowanych nadawców poczty e-mail App Engine.
- Załóż konto Google Analytics.
- Określ zmienne środowiskowe w panelu kontrolnym
pom.xml:- Ustaw identyfikator klienta za pomocą identyfikatora OAuth 2.0 (z kroku 2).
- Ustaw identyfikator klienta usługi z identyfikatorem zawartym w pliku klucza (z kroku 3).
- Określ adres e-mail nadawcy alertów (od kroku 4).
- Określ domenę e-mail, na którą będą wysyłane wszystkie e-maile.
- Podaj adres serwera Gerrit REST.
- Określ zakres OAuth 2.0, który ma być używany dla serwera Gerrit REST.
- Podaj identyfikator Google Analytics (z kroku 5).
- Kompiluj i wdrażaj projekt.
- W terminalu uruchom
mvn clean appengine:update.
Względy bezpieczeństwa
Solidne informacje o zasięgu wymagają dostępu do oryginalnego kodu źródłowego. Jednakże część kodu może być poufna i dodatkowa brama do niego może pozwolić na wykorzystanie istniejących list kontroli dostępu.
Aby uniknąć tego zagrożenia, zamiast udostępniać kod źródłowy z informacjami o pokryciu, Dashboard bezpośrednio obsługuje wektor pokrycia (tj. wektor zliczeń wykonania mapowany na linie w pliku źródłowym). Wraz z wektorem pokrycia Dashboard otrzymuje nazwę i ścieżkę projektu Git, dzięki czemu klient może pobrać kod z zewnętrznego interfejsu API kodu źródłowego. Przeglądarka klienta otrzymuje te informacje i wykorzystuje współdzielenie zasobów między źródłami (CORS) w języku JavaScript w celu wysłania zapytania do serwera kodu źródłowego w celu uzyskania oryginalnego kodu źródłowego; wynikowy kod jest łączony z wektorem pokrycia w celu uzyskania obrazu.
To bezpośrednie podejście nie poszerza pola ataku, ponieważ Panel wykorzystuje pliki cookie użytkownika do uwierzytelniania w usłudze zewnętrznej (co oznacza, że użytkownik, który nie ma bezpośredniego dostępu do kodu źródłowego, nie może wykorzystać Panelu do przeglądania poufnych informacji).