Parametri utente

In Android Comms Test Suite (ACTS), puoi specificare ulteriori informazioni o parametri di test all'interno della configurazione 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 principale 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 utili parametri utente facoltativi con 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 il database di test non sia configurato correttamente, con la conseguente esito negativo di tutti i test.

  • quiet_tests: elenco di classi di test o scenari di test specificati nel 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 saranno generati artefatti di errore dei test (ad esempio, segnalazioni di bug, log qxdm). Se il nome di una classe di test viene specificato senza uno scenario di test, tutti gli scenari di test nella classe specificata sono impostati in modo da ignorare le segnalazioni di bug. Questo flag può essere utilizzato per eliminare l'output per gli scenari di test problematici che si prevede non vadano a buon fine.

  • retry_tests: elenco di classi di test o scenari di test specificati nel 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 una seconda volta, viene contrassegnato come non riuscito.