Parametri utente

In Android Comms Test Suite (ACTS), è possibile specificare ulteriori informazioni o parametri di test dall'interno della configurazione di ACTS. I parametri utente possono essere in qualsiasi formato compatibile con JSON e vengono decodificati nel tipo appropriato in Python (ad esempio, dict, list e str). Esistono due modi in cui è possibile specificare i parametri utente:

  • A livello di radice della configurazione

    {
        "testbed": {
            ...
        },
        "my_user_param1": "my_value",
        "my_user_param2": {"another": ["value"]}
    }
    
  • All'interno di un banco di prova

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

Se un parametro utente viene trovato all'interno del livello principale e all'interno del testbed, viene utilizzato il valore specifico del banco di test.

In una classe di test ACTS, gli utenti possono leggere queste informazioni utilizzando:

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

Parametri utente speciali

Di seguito è riportato un elenco di parametri utente facoltativi utili che hanno proprietà speciali in ACTS:

  • consecutive_failure_limit: numero di errori di test consecutivi da consentire prima di bloccare i test rimanenti nella stessa classe di test. Se non specificato, il comportamento predefinito prevede l'esecuzione di tutti i test, indipendentemente dagli errori. Questo parametro è utile nei casi in cui la piattaforma di test sia configurata in modo improprio, causando il fallimento di tutti i test.

  • quiet_tests: elenco di classi di test o casi di test specificati con il formato test_class o test_class.test_name, ad esempio BleScanApiTest o BleScanApiTest.test_start_ble_scan_with_default_settings. Per ogni scenario di test in questo elenco non verranno generati artefatti di errore dei test (ad esempio, segnalazioni di bug, log qxdm). Se viene specificato il nome di una classe di test senza uno scenario di test, tutti gli scenari di test nella classe specificata sono impostati per saltare i report di bug. Questo flag può essere utilizzato per eliminare l'output per i casi di test problematici che dovrebbero non riuscire.

  • retry_tests: elenco di classi di test o casi di test specificati con il formato test_class o test_class.test_name, ad esempio BleScanApiTest o BleScanApiTest.test_start_ble_scan_with_default_settings. Per ogni scenario di test in questo elenco, se un test non va a buon fine, viene ripetuto una volta sola. Se il test non va a buon fine per la seconda volta, viene contrassegnato come non riuscito.