Pakiet w Tradefed odnosi się do konfiguracji, w której kilka testów jest uruchamianych w ramach wspólnego modułu uruchamiającego testy, który steruje ogólnym wykonaniem.
W Tradefed pakiety są obsługiwane przez klasę ITestSuite , która umożliwia dodawanie i usuwanie testów niezależnie od sposobu ich uruchamiania.
Definicje
- Pakiet: zestaw modułów testowych skonfigurowanych do działania w podobnej konfiguracji najwyższego poziomu w celu raportowania wyników w ramach jednego wywołania.
- Konfiguracja najwyższego poziomu: konfiguracja zastosowana na urządzeniach przed uruchomieniem któregokolwiek z modułów testowych.
- Konfiguracja główna: Konfiguracja Tradefed XML na poziomie pakietu, która opisuje, które moduły powinny działać i jaką konfigurację najwyższego poziomu należy zastosować.
- Konfiguracja na poziomie modułu: konfiguracja zastosowana na urządzeniach tuż przed uruchomieniem modułu. Są one również znane jako konfiguracje specyficzne dla modułu .
- Konfiguracja modułu: odnosi się do konfiguracji XML
AndroidTest.xmlTradefed, która opisuje moduły i konfigurację na poziomie modułu, którą należy przeprowadzić. - Moduł: Jednostka testowa składająca się z etapu konfiguracji ( konfiguracja na poziomie modułu ), etapu wykonania testu i etapu demontażu.
- Ponowna próba wewnątrz modułu: automatyczna ponowna próba wykonywana przez wiązkę przewodów wewnątrz modułu.
- Ponowna próba pakietu: pełne powtórzenie wcześniej nieudanych testów pakietu.
Struktura ITestSuite
ITestSuite w Tradefed odnosi się do wspólnej klasy bazowej sterującej wykonaniem pakietu. Jest współdzielony przez wszystkie główne zestawy testów, w szczególności pakiet testów zgodności systemu Android (CTS) i zestaw testów dostawcy systemu Android (VTS) , i zapewnia spójne środowisko wykonywania we wszystkich pakietach.
Czasami nazywamy ITestSuite narzędziem uruchamiającym pakiet .
Biegacz pakietu wykonuje następujące kroki podczas wykonywania:
- Załaduj konfigurację modułu i określ, który zestaw powinien zostać uruchomiony.
Uruchom każdy moduł:
- Uruchom konfigurację na poziomie modułu.
- Uruchom testy modułów.
- Uruchom rozbiórkę na poziomie modułu.
Zgłoś wyniki.
Konfiguracja na najwyższym poziomie
Z punktu widzenia Tradefed ITestSuite to po prostu kolejny test. Jest to złożony problem, ale nadal jest tylko testem, jak każdy inny IRemoteTest . Zatem określając moduł uruchamiający pakiet w konfiguracji Tradefed, Tradefed postępuje zgodnie ze zwykłym wzorcem konfiguracji: uruchamiając build_provider , target_preparer , test (w tym przypadku nasz pakiet) i target_cleaner .
Ta sekwencja w konfiguracji Tradefed zawierającej ITestSuite to konfiguracja najwyższego poziomu.
Przykład:
<configuration description="Common config for Compatibility suites">
<build_provider class="com.android.compatibility.common.tradefed.build.CompatibilityBuildProvider" />
<!-- Setup applied before the suite: so everything running in the suite will
have this setup beforehand -->
<target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
<option name="run-command" value="settings put global package_verifier_enable 0" />
<option name="teardown-command" value="settings put global package_verifier_enable 1"/>
</target_preparer>
<!-- Our ITestSuite implementation -->
<test class="com.android.compatibility.common.tradefed.testtype.suite.CompatibilityTestSuite" />
<result_reporter class="com.android.compatibility.common.tradefed.result.ConsoleReporter" />
</configuration>
Metadane modułu
Metadane modułu nazywamy dodatkowymi informacjami określonymi w module testowym AndroidTest.xml . Te metadane umożliwiają określenie dodatkowych informacji o module, a moduły można filtrować za pomocą metadanych.
Przykładowe metadane:
<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
Przykładowy filtr na metadanych:
--module-metadata-include-filter component=framework
Powyższe uruchomiłoby wszystkie moduły ze strukturą jako metadanymi komponentów .
Pełny przykład AndroidTest.xml :
<configuration description="Config for CTS Gesture test cases">
<option name="test-suite-tag" value="cts" />
<!-- Metadata -->
<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
<!-- End: metadata -->
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsGestureTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.gesture.cts" />
<option name="runtime-hint" value="10m50s" />
</test>
</configuration>
Moduł parametryczny
Specjalnym typem metadanych jest parameter .
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
Te metadane określają, że moduł musi zostać wykonany w innym trybie , na przykład jako aplikacja błyskawiczna, a nie w trybie aplikacji standardowej.
Wszystkie możliwe tryby lub parametry są opisane przez ModuleParameters i mają powiązaną procedurę obsługi w ModuleParametersHelper , która umożliwia zmianę konfiguracji modułu w celu wykonania w określonym trybie.
Na przykład tryb aplikacji błyskawicznej wymusza instalację pakietu APK w trybie natychmiastowym.
Aby parametryzacja mogła nastąpić, linia poleceń musi ją włączyć za pomocą:
--enable-parameterized-modules
Możliwe jest również uruchomienie pojedynczego danego trybu za pomocą:
--enable-parameterized-modules --module-parameter <Mode>
--enable-parameterized-modules --module-parameter INSTANT_APP
Po uruchomieniu sparametryzowanej wersji modułu raportuje swoje wyniki pod sparametryzowaną nazwą modułu, na przykład CtsGestureTestCases[instant] w porównaniu do podstawowego CtsGestureTestCases .