Configuração do painel VTS

O painel VTS fornece um back-end e uma interface de usuário (IU) para visualizar os resultados dos testes do sistema de integração contínua VTS. Ele oferece suporte ao desenvolvimento orientado a testes com ferramentas como notificações de status de teste para ajudar os desenvolvedores a localizar e prevenir áreas de regressão durante o ciclo de desenvolvimento (inclui monitoramento de teste e suporte de triagem).

A UI do painel VTS oferece suporte a recursos (como cobertura de código nativo) fornecidos pela infraestrutura VTS e oferece monitoramento contínuo de desempenho para permitir o desenvolvimento de ferramentas de desempenho otimizadas e bem caracterizadas.

Requisitos

Os seguintes serviços são necessários para usar o Painel VTS:

A visualização da cobertura do teste depende de uma API REST para um servidor de código-fonte (por exemplo, Gerrit), que permite ao serviço web buscar o código-fonte original de acordo com as listas de controle de acesso existentes.

Arquitetura

O Dashboard VTS usa a seguinte arquitetura:

Figura 1 . Arquitetura do painel VTS.

Os resultados do status do teste são carregados continuamente no banco de dados do Cloud Datastore por meio de uma interface REST. O executor VTS processa automaticamente os resultados e os serializa usando o formato Protobuf.

Os servlets da Web formam o principal ponto de acesso dos usuários, entregando e processando dados do banco de dados Datastore. Os servlets incluem: um servlet principal para entregar todos os testes, um servlet de preferências para gerenciar os favoritos do usuário, um servlet de resultados para preencher uma tabela de teste, um servlet gráfico para preparar dados de criação de perfil e um servlet de cobertura para preparar dados de cobertura para o cliente. .

Cada módulo de teste tem sua própria árvore de ancestralidade do Datastore e os resultados dos testes são indexados com o carimbo de data/hora Unix do horário de início do teste. Os dados de cobertura no banco de dados são armazenados com os resultados do teste como um vetor de contagens (ou seja, para cada linha no arquivo fonte original) e informações de identificação para buscar o código-fonte de um servidor de código-fonte.

O serviço de notificação é executado usando filas de tarefas, identificando alterações no status do caso de teste e notificando os assinantes. As informações com estado são armazenadas em uma tabela de status para acompanhar a atualização dos dados e as falhas existentes. Isso permite que o serviço de notificação forneça informações valiosas sobre falhas e correções de casos de teste individuais.

Estrutura de código

Os componentes essenciais do VTS Dashboard incluem os servlets implementados em Java, os JSPs front-end, folhas de estilo CSS e arquivos de configuração. A lista a seguir detalha os locais e descrições desses componentes (todos os caminhos relativos a test/vts/web/dashboard ):

  • pom.xml
    Arquivo de configurações onde as variáveis ​​de ambiente e dependências são definidas.
  • src/main/java/com/android/vts/api/
    Contém endpoints para interagir com os dados via REST.
  • src/main/java/com/android/vts/entity/
    Contém modelos Java das entidades do Datastore.
  • src/main/java/com/android/vts/proto/
    Contém arquivos Java para Protobuf, incluindo VtsReportMessage.java , que é uma implementação Java do tipo Protobuf usada para descrever resultados de testes VTS.
  • src/main/java/com/android/vts/servlet/
    Contém arquivos Java para servlets.
  • src/main/java/com/android/vts/util/
    Contém arquivos Java para funções utilitárias e classes usadas pelos servlets.
  • src/test/java/com/android/vts/
    Contém testes de UI para servlets e utilitários.
  • src/main/webapp/
    Contém arquivos relacionados à UI (JSP, CSS, XML):
    • js/ . Contém arquivos Javascript usados ​​pelas páginas da web.
    • WEB-INF/ . Contém arquivos de configuração e UI.
    • jsp/ . Contém os arquivos JSP de cada página da web.
  • appengine-web.xml
    Arquivo de configurações onde as variáveis ​​de ambiente são carregadas em variáveis.
  • web.xml
    Arquivo de configurações onde os mapeamentos de servlet e restrições de segurança são definidos.
  • cron.xml
    Arquivo de configurações que define tarefas agendadas (ou seja, o serviço de notificações).

Configurar o painel

Para configurar o Painel VTS:

  1. Crie um projeto do Google Cloud App Engine e configure o host de implantação instalando:
    • Java 8
    • SDK do Google App Engine
    • Maven
  2. Gere um ID de cliente OAuth 2.0 no Google Cloud API Manager.
  3. Crie uma conta de serviço e crie um arquivo-chave.
  4. Adicione um endereço de e-mail à lista de remetentes autorizados da API de e-mail do App Engine.
  5. Configure uma conta do Google Analytics.
  6. Especifique variáveis ​​de ambiente no Dashboard pom.xml :
    • Defina o ID do cliente com o ID do OAuth 2.0 (da etapa 2).
    • Configure o ID do cliente de serviço com o identificador incluído no arquivo-chave (da etapa 3).
    • Especifique o endereço de e-mail do remetente para alertas (da etapa 4).
    • Especifique um domínio de email para o qual todos os emails serão enviados.
    • Especifique o endereço para o servidor REST Gerrit.
    • Especifique o escopo do OAuth 2.0 a ser usado para o servidor REST Gerrit.
    • Especifique o ID do Google Analytics (da etapa 5).
    • Construa e implante o projeto.
  7. Em um terminal, execute mvn clean appengine:update .

Considerações de segurança

Informações robustas de cobertura requerem acesso ao código-fonte original. No entanto, alguns códigos podem ser sensíveis e um gateway adicional para eles pode permitir a exploração de listas de controle de acesso existentes.

Para evitar essa ameaça, em vez de servir o código-fonte com as informações de cobertura, o Dashboard trata diretamente um vetor de cobertura (ou seja, um vetor de contagem de execução mapeado para linhas em um arquivo de origem). Junto com o vetor de cobertura, o Dashboard recebe o nome e o caminho do projeto Git para que o cliente possa buscar o código de uma API de código-fonte externa. O navegador cliente recebe essas informações e usa o compartilhamento de recursos de origem cruzada (CORS) em Javascript para consultar o servidor de código-fonte em busca do código-fonte original; o código resultante é combinado com o vetor de cobertura para produzir uma exibição.

Essa abordagem direta não amplia a superfície de ataque porque o Dashboard usa os cookies do usuário para se autenticar com um serviço externo (o que significa que um usuário que não consegue acessar o código-fonte diretamente não pode explorar o Dashboard para visualizar informações confidenciais).