Configurando testes ACTS

Esta página descreve como configurar testes ACTS.

Fontes de configuração

O Android Comms Test Suite (ACTS) tem três fontes principais de configuração:

  • A interface de linha de comando (CLI)
  • O arquivo de configuração ACTS
  • Variáveis ​​ambientais

Os valores dessas fontes são combinados em uma única configuração usada para executar um teste ACTS. Se os valores forem especificados em vários locais, os valores serão substituídos com base na ordem acima (onde a CLI tem precedência).

Uma observação sobre variáveis ​​de ambiente

Tenha cuidado ao usar variáveis ​​de ambiente para testes ACTS. Esses valores são os menos visíveis para o usuário e não são recomendados para uso fora da estação de trabalho de um desenvolvedor. As variáveis ​​de ambiente são desativadas durante os testes automatizados do ACTS para evitar envenenamento do ambiente.

Variáveis ​​de configuração necessárias

Cada teste ACTS requer que as seguintes variáveis ​​sejam definidas.

Caminhos de teste ACTS

O ACTS é executado a partir de um único local de entrada principal. Como resultado, a localização do caminho de teste é desconhecida para o executor.

Defina o local do caminho de teste usando a variável de ambiente ACTS_TESTPATH ​​ou com o sinalizador -tp / --testpaths na linha de comando. O valor pode ser uma lista de diretórios.

Aulas de teste ACTS

ACTS deve saber quais classes de teste executar. Pode ser uma regex ou uma lista de nomes de classes de teste.

Para definir esse valor, use o sinalizador -tc / --test_class na linha de comando. Observe que este sinalizador também aceita uma lista de nomes de classes. Os nomes das classes devem corresponder aos nomes dos arquivos correspondentes, por exemplo, SampleTest deve ser encontrado em SampleTest.py .

Caminho de registro ACTS

ACTS deve ter um local para gravar logs diferente de STDOUT. O ACTS grava logs de depuração completos contendo dados que podem ajudar a determinar por que alguns testes estão falhando. Para evitar confusão, o ACTS não grava esses logs em STDOUT.

Para definir o caminho do log, use a variável de ambiente ACTS_LOGPATH ou o sinalizador -lp / --logpath na linha de comando.

Caminho de configuração do ACTS

Para executar o teste, o ACTS deve saber qual ambiente de teste existe. A configuração do ACTS contém todos os dispositivos no ambiente de teste e quaisquer testes especiais ou parâmetros de ambiente que possam ser necessários. Defina esse valor na linha de comando usando -c / --config .

Se houver vários testbeds na configuração, o ACTS executa os testes para cada testbed. Para executar o teste apenas para um único testbed na lista, use o argumento de linha de comando -tb/--testbed <NAME> .

Um exemplo de estação de trabalho local

A maioria dos usuários do ACTS desenvolve em um único branch de repositório Android e tem uma configuração semelhante a esta:

# in ~/.bashrc
ACTS_LOGPATH='/tmp/acts_logpath'
ACTS_TESTPATH='~/android/<REPO_BRANCH>/tools/test/connectivity/acts_tests/'

# On cmdline
$ act.py -c ~/acts_configs/local_config.json -tc SampleTest -tb marlin

Se os usuários do ACTS executam em diversas ramificações, eles geralmente executam o ACTS a partir do diretório acts/framework e usam um caminho relativo para ACTS_TESTPATH ​​:

# in ~/.bashrc
ACTS_LOGPATH='/tmp/acts_logpath'
ACTS_TESTPATH='../acts_tests/'

# On cmdline
$ cd ~/android/main/tools/test/connectivity/acts_tests/acts_contrib/
$ act.py -c ~/acts_configs/local_config.json -tc SampleTest -tb marlin

Configurando seus testbeds

O arquivo de configuração ACTS fornece todas as informações necessárias para executar testes em dispositivos de hardware:

{
  "testbed": {
    "my_testbed": {
      "my_testbed_value": "value"
    },
    "another_testbed": {
      "AndroidDevice": [
        "53R147"
      ]
    }
  },
  "user_parameter_1": "special environment value",
  "user_parameter_2": "other special value"
}

A unidade base desta configuração é o testbed. Na configuração de exemplo acima, o testbed my_testbed é criado com um único valor testbed. O segundo testbed, another_testbed , possui uma configuração de controlador especial que contém as informações de uma lista de dispositivos Android. Esses dispositivos são armazenados em uma lista de dispositivos em self.android_devices . Observe que se um testbed não especificar um objeto AndroidDevice , uma classe de teste que espera um objeto AndroidDevice gerará uma exceção. Para obter uma lista completa de configurações de controlador suportadas que acompanham o ACTS, consulte a lista em /acts/framework/acts/controllers/ .

Todos os outros valores (que não são valores especiais mencionados na seção acima) são armazenados em self.user_params como um dicionário. Este é um bom lugar para armazenar informações ambientais ou de teste, como se os telefones estão em um ambiente de dados medidos ou por quanto tempo serão coletados dados para um teste.

Casos especiais para dispositivos Android

Para maior comodidade de desenvolvimento quando você deseja ter vários dispositivos com propriedades diferentes disponíveis, AndroidDevice tem alguns casos especiais.

Formato de configuração JSON

Todos os pares chave/valor no JSON abaixo são definidos para o objeto AndroidDevice correspondente. Se a configuração tentar substituir um parâmetro definido no atributo AndroidDevice , ControllerError será lançado.

  "AndroidDevice": [{"serial": "XXXXXX", "label": "publisher"},
                    {"serial": "YYYYYY", "label": "subscriber", "user_parameter_1": "anything"}]

Então, no script de teste, você pode usar uma função de filtro para recuperar o dispositivo correto e acessar parâmetros extras do objeto de dispositivo:

  def setup_class(self):
      self.pub = next(filter(lambda ad: ad.label == 'publisher',
                             self.android_devices))
      self.sub = next(filter(lambda ad: ad.label == 'user_parameter_1',
                             self.android_devices))

Parâmetro opcional

O seguinte é um parâmetro opcional:

  • adb_logcat_param : uma string anexada ao comando adb logcat para coletar logs do adb. Por padrão, adb logcat -v threadtime -b all é usado. Se adb_logcat_param estiver definido, a seção -b all será substituída. Por exemplo, definir adb_logcat_param como -b radio altera o comando para adb logcat -v threadtime -b radio .