Parâmetros do usuário

No Android Comms Test Suite (ACTS), é possível especificar outras informações ou parâmetros de teste na configuração do ACTS. Os parâmetros do usuário podem estar em qualquer formato compatível com JSON e são decodificados no tipo adequado em Python (por exemplo, dict, list e str). Há dois lugares em que os parâmetros do usuário podem ser especificados:

  • No nível raiz da configuração

    {
    "testbed": {
        ...
    },
    "my_user_param1": "my_value",
    "my_user_param2": {"another": ["value"]}
}

  • Em um ambiente de teste

    {
    "testbed": {
        "my_testbed": {
            "AndroidDevice": [...],
            ...,
            "my_user_param1": "my_value",
            "my_user_param2": {"another": ["value"]}
        }
    },
}

Se um parâmetro do usuário for encontrado no nível raiz e no ambiente de teste, o valor específico do ambiente de teste será usado.

Em uma classe de teste ACTS, os usuários podem ler essas informações usando:

class MyActsTest
    def setup_class(self):
        self.my_param_1 = self.user_params['my_user_param1']

        # Get the parameter with a default value if not found within config.
        self.my_param_2 = self.user_params.get('my_user_param2', default={})

Parâmetros de usuário especiais

Confira uma lista de parâmetros de usuário opcionais úteis que têm propriedades especiais no ACTS:

  • consecutive_failure_limit: número de falhas de teste consecutivas permitidas antes de bloquear os testes restantes na mesma classe. Se não for especificado, o comportamento padrão será executar todos os testes, independentemente das falhas. Esse parâmetro é útil nos casos em que o testbed não está configurado incorretamente, fazendo com que todos os testes falhem.

  • quiet_tests: lista de classes de teste ou casos de teste especificados com o formato test_class ou test_class.test_name, por exemplo, BleScanApiTest ou BleScanApiTest.test_start_ble_scan_with_default_settings. Cada caso de teste dessa lista não terá artefatos de falha de teste gerados (por exemplo, relatórios de bugs, registros do qxdm). Se o nome de uma classe de teste for especificado sem um caso de teste, todos os casos de teste na classe serão configurados para pular relatórios de bugs. Essa sinalização pode ser usada para suprimir a saída para casos de teste problemáticos que podem falhar.

  • retry_tests: lista de classes de teste ou casos de teste especificados com o formato test_class ou test_class.test_name, por exemplo, BleScanApiTest ou BleScanApiTest.test_start_ble_scan_with_default_settings. Para cada caso de teste nesta lista, se um teste falhar, ele será tentado novamente uma vez. Se o teste falhar pela segunda vez, ele será marcado como uma falha.