Parametry użytkownika

W pakiecie Android Comms Test Suite (ACTS) można podać dodatkowe informacje o teście lub parametry z poziomu konfiguracji ACTS. Parametry użytkownika mogą mieć dowolny format zgodny z JSON i są dekodowane do odpowiedniego typu w Pythonie (np. dict, list i str). Parametry użytkownika można określić w 2 miejscach:

  • Na poziomie głównym konfiguracji

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

  • W pomieszczeniu testowym

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

Jeśli parametr użytkownika znajdzie się na poziomie głównym i w pomieszczeniu testowym, zostanie użyta wartość konkretnego pokoju testowego.

W klasie testowej ACTS użytkownicy mogą odczytać te informacje, korzystając z tych elementów:

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

Specjalne parametry użytkownika

Oto lista przydatnych opcjonalnych parametrów użytkownika, które mają specjalne właściwości w ACTS:

  • consecutive_failure_limit: liczba kolejnych niepowodzeń testów, na które należy zezwolić przed zablokowaniem pozostałych testów w tej samej klasie. Jeśli nie podasz żadnej wartości, domyślnym działaniem będzie uruchamianie wszystkich testów niezależnie od błędów. Ten parametr jest przydatny w nieprawidłowo skonfigurowanej konfiguracji stanowiska testowego, która powoduje niepowodzenie wszystkich testów.

  • quiet_tests: lista klas lub przypadków testowych określonych w formacie test_class lub test_class.test_name, na przykład BleScanApiTest lub BleScanApiTest.test_start_ble_scan_with_default_settings. W każdym przypadku testowego na tej liście nie zostaną wygenerowane żadne artefakty błędu testu (na przykład raporty o błędach czy logi qxdm). Jeśli nazwa klasy testowej zostanie określona bez przypadku testowego, wszystkie przypadki testowe w danej klasie będą pomijane. Tej flagi można używać do pomijania danych wyjściowych w problematycznych przypadkach testowych, w przypadku których zwykle nie występują błędy.

  • retry_tests: lista klas lub przypadków testowych określonych w formacie test_class lub test_class.test_name, na przykład BleScanApiTest lub BleScanApiTest.test_start_ble_scan_with_default_settings. Jeśli test nie powiedzie się, jest on powtarzany jeden raz w przypadku każdego przypadku testowego na tej liście. Jeśli test wystąpi ponownie po raz drugi, zostanie oznaczony jako nieudany.