Parámetros de usuario

En el Conjunto de pruebas de comunicaciones (ACTS) de Android, se pueden especificar información o parámetros de prueba adicionales desde la configuración de ACTS. Los parámetros de usuario pueden estar en cualquier formato que cumpla con JSON y se decodifican en el tipo adecuado en Python (por ejemplo, dict, list y str). Hay dos lugares en los que se pueden especificar los parámetros del usuario:

  • En el nivel raíz de la configuración

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

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

Si se encuentra un parámetro de usuario dentro del nivel raíz y en el testbed, se usa el valor específico de testbed.

En una clase de prueba de ACTS, los usuarios pueden leer esta información de la siguiente manera:

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

Parámetros especiales de usuario

A continuación, se incluye una lista de parámetros de usuario opcionales útiles que tienen propiedades especiales en ACTS:

  • consecutive_failure_limit: Cantidad de pruebas fallidas consecutivas que se deben permitir antes de bloquear las pruebas restantes en la misma clase de prueba. Si no se especifica, el comportamiento predeterminado es ejecutar todas las pruebas, sin importar las fallas. Este parámetro es útil en casos en los que el testbed está configurado de forma incorrecta, lo que provoca que todas las pruebas fallen.

  • quiet_tests: Es la lista de clases de prueba o casos de prueba especificados con el formato test_class o test_class.test_name, por ejemplo, BleScanApiTest o BleScanApiTest.test_start_ble_scan_with_default_settings. Cada caso de prueba de esta lista no tendrá generados ningún artefacto de falla de prueba (por ejemplo, informes de errores, registros qxdm). Si se especifica un nombre de clase de prueba sin un caso de prueba, todos los casos de prueba de la clase determinada se configuran para omitir los informes de errores. Esta marca se puede usar para suprimir el resultado de casos de prueba problemáticos que se espera que fallen.

  • retry_tests: Es la lista de clases de prueba o casos de prueba especificados con el formato test_class o test_class.test_name, por ejemplo, BleScanApiTest o BleScanApiTest.test_start_ble_scan_with_default_settings. Para cada caso de prueba de esta lista, si una prueba falla, se vuelve a intentar una vez. Si la prueba falla por segunda vez, se marcará como fallida.