Paramètres utilisateur

Dans la suite de test de communication Android (ACTS), vous pouvez spécifier des informations ou des paramètres de test supplémentaires à partir de la configuration ACTS. Les paramètres utilisateur peuvent être dans n'importe quel format compatible avec JSON et sont décodés dans le type approprié en Python (par exemple, dict, list et str). Les paramètres utilisateur peuvent être spécifiés à deux endroits:

  • Au niveau racine de la configuration

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

  • Dans un environnement de test

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

Si un paramètre utilisateur est détecté au niveau racine et dans testbed, la valeur spécifique à testbed est utilisée.

Dans une classe de test ACTS, les utilisateurs peuvent lire ces informations à l'aide des éléments suivants:

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={})

Paramètres utilisateur spéciaux

Voici une liste de paramètres utilisateur facultatifs utiles ayant des propriétés spéciales dans ACTS:

  • consecutive_failure_limit: nombre d'échecs de test consécutifs à autoriser avant de bloquer les tests restants dans la même classe de test. Si aucune valeur n'est spécifiée, le comportement par défaut consiste à exécuter tous les tests, indépendamment des échecs. Ce paramètre est utile dans les cas où le testbed est mal configuré, ce qui entraîne l'échec de tous les tests.

  • quiet_tests: liste des classes ou des scénarios de test spécifiés au format test_class ou test_class.test_name, par exemple BleScanApiTest ou BleScanApiTest.test_start_ble_scan_with_default_settings. Aucun artefact d'échec de test n'est généré pour chaque scénario de cette liste (par exemple, des rapports de bugs ou des journaux qxdm). Si un nom de classe de test est spécifié sans scénario de test, tous les scénarios de test de la classe donnée sont définis pour ignorer les rapports de bug. Cette option peut être utilisée pour supprimer la sortie des scénarios de test problématiques susceptibles d'échouer.

  • retry_tests: liste des classes ou des scénarios de test spécifiés au format test_class ou test_class.test_name, par exemple BleScanApiTest ou BleScanApiTest.test_start_ble_scan_with_default_settings. Pour chaque scénario de cette liste, si un test échoue, il est relancé une fois. Si le test échoue une deuxième fois, il est marqué comme ayant échoué.