Nutzerparameter

In der Android Comms Test Suite (ACTS) können zusätzliche Testinformationen oder Parameter in der ACTS-Konfiguration angegeben werden. Nutzerparameter können ein beliebiges JSON-konformes Format haben und in Python in den entsprechenden Typ decodiert werden, z. B. dict, list und str. Nutzerparameter können an zwei Stellen angegeben werden:

  • Auf der Stammebene der Konfiguration

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

  • Innerhalb eines Testbeds

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

Wenn ein Nutzerparameter auf der Stammebene und im Testbed gefunden wird, wird der Testbed-spezifische Wert verwendet.

In einer ACTS-Testklasse können Nutzer diese Informationen auf folgende Weise lesen:

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

Spezielle Nutzerparameter

Hier finden Sie eine Liste nützlicher optionaler Nutzerparameter mit speziellen Eigenschaften in ACTS:

  • consecutive_failure_limit: Anzahl der zulässigen aufeinanderfolgenden Testfehler, bevor die verbleibenden Tests in derselben Testklasse blockiert werden. Wenn nichts angegeben ist, werden standardmäßig alle Tests unabhängig von Fehlern ausgeführt. Dieser Parameter ist nützlich, wenn der Testbed nicht richtig konfiguriert ist, wodurch alle Tests fehlschlagen.

  • quiet_tests: Liste von Testklassen oder Testfällen, die im Format test_class oder test_class.test_name angegeben sind, z. B. BleScanApiTest oder BleScanApiTest.test_start_ble_scan_with_default_settings. Für jeden Testlauf in dieser Liste werden keine Artefakte für Testfehler generiert (z. B. Fehlerbericht, qxdm-Logs). Wenn ein Testklassenname ohne Testfall angegeben wird, werden alle Testfälle in der gegebenen Klasse so eingestellt, dass Fehlerberichte übersprungen werden. Mit diesem Flag können Sie die Ausgabe für problematische Testfälle unterdrücken, die voraussichtlich fehlschlagen.

  • retry_tests: Liste der Testklassen oder Testfälle im Format test_class oder test_class.test_name, z. B. BleScanApiTest oder BleScanApiTest.test_start_ble_scan_with_default_settings. Wenn ein Test in dieser Liste fehlschlägt, wird er einmal wiederholt. Wenn der Test ein zweites Mal fehlschlägt, wird er als fehlgeschlagen markiert.