Parametri utente

In Android Comms Test Suite (ACTS) , è possibile specificare ulteriori informazioni o parametri di test dalla 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 posizioni in cui è possibile specificare i parametri utente:

  • Al livello root del config

    {
        "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 root e all'interno del testbed, viene utilizzato il valore specifico del testbed.

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

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 che hanno proprietà speciali in ACTS:

  • consecutive_failure_limit : numero di test falliti 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 banco di prova è configurato in modo errato, 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 . Ogni caso di test in questo elenco non avrà alcun artefatto di errore del test generato (ad esempio, segnalazioni di bug, log qxdm). Se il nome di una classe di test viene specificato senza un test case, tutti i test case nella classe data verranno impostati per ignorare le segnalazioni di bug. Questo flag può essere utilizzato per sopprimere l'output per casi di test problematici che si prevede falliscano.

  • 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 caso di test in questo elenco, se un test fallisce, viene ritentato una volta. Se il test fallisce una seconda volta, viene contrassegnato come un fallimento.