Paramètres utilisateur

Dans la suite de tests 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 au format JSON et sont décodés au 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 le banc d'essais, la valeur spécifique au banc d'essais 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 qui présentent 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 de la même classe de test. Si ce paramètre n'est pas spécifié, le comportement par défaut consiste à exécuter tous les tests, quel que soit le nombre d'échecs. Ce paramètre est utile lorsque le banc d'essais est mal configuré, ce qui entraîne l'échec de tous les tests.

  • quiet_tests: liste des classes de test ou des cas 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 ne sera généré pour chaque scénario de test de cette liste (par exemple, rapports de bugs, 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. Cet indicateur peut être utilisé pour supprimer la sortie des cas de test problématiques qui devraient échouer.

  • retry_tests: liste des classes de test ou des cas 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 échec.