Este documento fornece instruções passo a passo sobre como criar módulos de vários dispositivos e chama as limitações atuais quando conhecidas.
A amostra
Um módulo multi-dispositivo CTS com reconhecimento de wifi é fornecido. Ele envia uma mensagem de um dispositivo por Wi-Fi e verifica se o outro dispositivo a recebe.
A fonte do módulo está em cts/hostsidetests/multidevices/wifi_aware .
Anotamos o exemplo com o máximo de comentários que consideramos úteis.
Etapa 1: criar a pasta do módulo
Recomenda-se criar uma pasta para o seu módulo multi-dispositivos no projeto da suíte ao qual ele pertence. Por exemplo: cts/hostsidetests/multidevices/ . Recomendamos isso para que todos os módulos de vários dispositivos permaneçam colocados pelo menos no início, o que facilitará a descoberta de exemplos.
Todos os arquivos para este módulo devem ser colocados em sua própria pasta de módulo. Por exemplo: wifi_aware .
Normalmente, é necessário um arquivo OWNERS para o módulo e o componente do bug deve ser especificado nele. Consulte cts/hostsidetests/multidevices/wifi_aware/OWNERS para obter um exemplo.
Etapa 2: criar o teste
É aqui que você implementa sua lógica de teste. É altamente dependente do que está sendo testado.
Crie a fonte de teste Mobly, como: wifi_aware_test.py .
Etapa 3: crie o arquivo de compilação: Android.bp
Adicione um arquivo Android.bp como cts/hostsidetests/multidevices/wifi_aware/Android.bp . Defina um módulo python_test_host, semelhante a:
python_test_host {
name: "CtsWifiAwareTestCases",
main: "wifi_aware_test.py",
srcs: ["wifi_aware_test.py"],
test_suites: [
"cts",
"general-tests",
],
test_options: {
unit_test: false,
},
data: [
// Package the snippet with the mobly test
":wifi_aware_snippet",
],
}
Especifique os trechos para o teste com o campo de dados, que serão compactados com o binário e podem ser localizados e instalados no teste pelo ATest ou em execução Contínua.
Mobly Bundled Snippets estão disponíveis no Android em external/mobly-bundled-snippets/ .
Opcional: crie snippets personalizados
Alguns módulos de vários dispositivos podem exigir snippets personalizados do Mobly. O teste de amostra inclui um snippet com reconhecimento de wifi em cts/hostsidetests/multidevices/wifi_aware/snippet/ , que é construído com o Mobly Snippet Lib, disponível no Android em: external/mobly-snippet-lib/ .
O snippet deve ser definido com a regra android_test em Android.bp como instrumentação padrão:
android_test {
name: "wifi_aware_snippet",
sdk_version: "current",
srcs: [
"CallbackUtils.java",
"WifiAwareSnippet.java",
],
manifest: "AndroidManifest.xml",
static_libs: [
"androidx.test.runner",
"guava",
"mobly-snippet-lib",
],
}
Etapa 4: crie a configuração do módulo: AndroidTest.xml
Adicione um arquivo AndroidTest.xml como cts/hostsidetests/multidevices/wifi_aware/AndroidTest.xml . Nesta configuração de teste, você precisa especificar dois dispositivos para o teste, semelhante a:
<configuration description="Config for CTS Wifi Aware test cases">
<option name="test-suite-tag" value="cts" />
<option name="config-descriptor:metadata" key="component" value="wifi" />
<option name="config-descriptor:metadata" key="parameter" value="not_instant_app" />
<option name="config-descriptor:metadata" key="parameter" value="not_multi_abi" />
<option name="config-descriptor:metadata" key="parameter" value="not_secondary_user" />
<device name="device1">
<!-- For coverage to work, the APK should not be uninstalled until after coverage is pulled.
So it's a lot easier to install APKs outside the python code.
-->
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="test-file-name" value="wifi_aware_snippet.apk" />
</target_preparer>
<target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
<option name="run-command" value="input keyevent KEYCODE_WAKEUP" />
<option name="run-command" value="wm dismiss-keyguard" />
</target_preparer>
<target_preparer class="com.android.tradefed.targetprep.PythonVirtualenvPreparer">
<!-- Any python dependencies can be specified and will be installed with pip -->
<option name="dep-module" value="mobly" />
</target_preparer>
</device>
<device name="device2">
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="test-file-name" value="wifi_aware_snippet.apk" />
</target_preparer>
<target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
<option name="run-command" value="input keyevent KEYCODE_WAKEUP" />
<option name="run-command" value="wm dismiss-keyguard" />
</target_preparer>
</device>
<test class="com.android.tradefed.testtype.mobly.MoblyBinaryHostTest">
<!-- The mobly-par-file-name should match the module name -->
<option name="mobly-par-file-name" value="CtsWifiAwareTestCases" />
<!-- Timeout limit in milliseconds for all test cases of the python binary -->
<option name="mobly-test-timeout" value="60000" />
</test>
</configuration>
Observe que:
- Este teste de amostra depende do Mobly. Qualquer dependência pode ser especificada para
PythonVirtualenvPreparere será instalada com pip. - O
mobly-par-file-nameparaMoblyBinaryHostTestdeve corresponder ao nome do módulo como em Android.bp. - Especifique um
mobly-test-timeoutpara o teste. É em milissegundos e se aplica à execução binária completa do python (todos os casos de teste juntos). Isso é necessário para evitar casos de teste suspensos para sempre em caso de alguns problemas. - Cada tag de
devicepode conter uma configuração distinta em cada dispositivo, a configuração do Mobly os receberá na mesma ordem especificada no XML.
Relacionado à instalação do apk do snippet:
- O POC inicial foi atualizado para instalar apks de snippet por meio de target_preparer devido a uma conversa com a equipe de cobertura: para garantir que as medições de cobertura não sejam excluídas muito cedo, a desinstalação por Harness em vez de código de teste em binários Python oferece melhores garantias em termos de tempo.
Etapa 5: execute o teste localmente: atest
Atualmente, os testes em vários dispositivos são executados apenas em dispositivos físicos. Antes de executar o teste, verifique se os dispositivos de teste estão no estado adequado. O comando adb devices deve relatar a lista de seus dispositivos conectados. Se a lista contiver dispositivos não destinados ao teste, especifique os dispositivos para o teste usando o sinalizador -s.
Para testes de wifi, verifique se o wifi está ativado para os dispositivos (após a redefinição de fábrica).
Você pode executar o teste localmente com atest:
$ atest CtsWifiAwareTestCases
Você deve ver o número de dispositivos usados no cabeçalho de resumo em uma saída de teste, algo como Test executed with 2 device(s) .
Solução de problemas
Se o teste falhar durante a execução local devido a:
Erro Virtualenv
java.io.IOException: Cannot run program
"virtualenv": error=2, No such file or directory
Certifique-se de que virtualenv esteja em seu PATH. Adicionar "~/.local/bin" ao PATH deve corrigi-lo. se o virtualenv não estiver instalado, siga: https://virtualenv.pypa.io/en/latest/installation.html
Espera-se obter pelo menos 2 objetos de controlador, obteve 1
Os módulos de teste são multidispositivos ou dispositivos únicos, não há módulos mistos. Se você tentar executar um módulo de vários dispositivos sem vários dispositivos, verá este erro:
Expected to get at least 2 controller objects, got 1
A execução do módulo no modo multidispositivos resolverá o problema.
Para CTS: Você pode usar sharding para acioná-lo (por exemplo: --shard-count 2) ou run cts-multidevces .