AndroidTest.xml yapısı

Modül konfigürasyonunun genel yapısı, normal Tradefed XML konfigürasyonuna benzer bir modeli takip eder ancak bir paketin parçası olarak çalıştıkları gerçeğinden dolayı bazı kısıtlamalara sahiptir.

İzin verilen etiketlerin listesi

AndroidTest.xml veya daha geniş anlamda modül yapılandırması yalnızca şu XML etiketlerini içerebilir: target_preparer , multi_target_preparer , test ve metrics_collector .

Bu liste kısıtlayıcı görünse de, test modülü kurulum ihtiyaçlarını ve çalıştırılacak testi tam olarak tanımlamanıza olanak tanır.

NOT: Farklı etiketler hakkında bilgi tazelemeye ihtiyacınız varsa Tradefed XML yapılandırmasına bakın.

build_provider veya result_reporter gibi nesneler, bir modül yapılandırmasının içinden çalıştırılmaya çalışılırsa bir ConfigurationException oluşturacaktır. Bunun amacı, bu nesnelerin aslında bir modül içerisinde bazı görevleri yerine getirmesi beklentisini ortadan kaldırmaktır.

Örnek modül konfigürasyonu

<configuration description="Config for CTS Gesture test cases">
    <option name="test-suite-tag" value="cts" />
    <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>

Bu yapılandırma, CtsGestureTestCases.apk yüklenmesini gerektiren ve android.gesture.cts paketine karşı bir enstrümantasyon çalıştıracak bir testi açıklar.

Dahil etme etiketleri <include> ve <template-include>

Modül yapılandırmalarında <include> ve <template-include> öğelerinin kullanılması önerilmez. Beklendiği gibi çalışacakları garanti edilmez.

metrics_collector etiketi için özel durum

Modül için çekilecek ve günlüğe kaydedilecek belirli bir dosya veya dizini belirtmek amacıyla metrics_collector izin verilir ancak FilePullerLogCollector sınıfıyla sınırlıdır. Günlükleri belirli bir konumda bırakıyorsanız ve bunları otomatik olarak kurtarmak istiyorsanız bu kullanışlıdır.

Örnek konfigürasyon:

<configuration description="Config for CTS UI Rendering test cases">
    <target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
        <option name="cleanup-apks" value="true" />
        <option name="test-file-name" value="CtsUiRenderingTestCases.apk" />
    </target_preparer>
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="android.uirendering.cts" />
        <option name="runtime-hint" value="11m55s" />
        <option name="runner" value="android.uirendering.cts.runner.UiRenderingRunner" />
        <option name="isolated-storage" value="false" />
    </test>

    <!-- Collect the files in the dump directory for debugging -->
    <metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
        <option name="directory-keys" value="/sdcard/UiRenderingCaptures" />
        <option name="collect-on-run-ended-only" value="true" />
    </metrics_collector>
</configuration>

Yapı bilgileri veya indirmeler ne olacak?

İzin verilen etiketlerin tanımı, bir modülün herhangi bir yapı bilgisi alamayacağı yönünde yanlış bir izlenim verebilir. Bu doğru değil .

Yapı bilgileri paket düzeyindeki kurulumdan sağlanır ve paketin tüm modülleri tarafından paylaşılır. Bu, paketin tüm modüllerini çalıştırmak için paketin tek bir üst düzey kurulumuna olanak tanır.

Örneğin, her Uyumluluk Test Paketi (CTS) modülünün cihaz bilgilerini, türlerini vb. ayrı ayrı sorgulaması yerine, CTS paketi düzeyindeki kurulum ( cts.xml ) bunu bir kez yapar ve her modül, talep etmesi halinde bu bilgiyi alır.

Bir modüldeki nesnelerin yapı bilgilerini alabilmesi için, normal Tradefed yapılandırmasındakiyle aynı şeyi yapmaları gerekir: IBuildInfo almak için IBuildReceiver arayüzünü uygulamak. Daha fazla ayrıntı için cihazla test etme konusuna bakın.

Meta veri alanları

Çok sayıda test modülü, her birinin benzersiz bir hedefi olan bazı metadata spesifikasyonlarını içerir.

Örnek:

  <option name="config-descriptor:metadata" key="component" value="framework" />
  <option name="config-descriptor:metadata" key="parameter" value="instant_app" />
  <option name="config-descriptor:metadata" key="parameter" value="multi_abi" />
  <option name="config-descriptor:metadata" key="parameter" value="secondary_user" />

Bileşen

component meta verileri, modülün test etmeyi planladığı genel Android bileşenini açıklar. Testin yürütülmesi üzerinde doğrudan bir etkisi yoktur; öncelikle organizasyonel amaçlar için kullanılır.

CTS için izin verilen bileşenlerin güncel listesi CtsConfigLoadingTest'te mevcuttur. Bir CTS modülüne mevcut olmayan bir bileşen eklenirse bu test ön gönderimde başarısız olur.

module-metadata-include-filter ve module-metadata-exclude-filter kullanarak bileşenlere dayalı olarak çalıştırılan bir paketi filtreleyebilirsiniz.

Örnek:

  --module-metadata-include-filter component framework

Bu örnek yalnızca framework bileşeniyle açıklamalı test modülünü çalıştırır.

Parametre

parameter meta verileri bilgi amaçlıdır ve testin yürütülmesini etkiler. Test modülünün hangi Android moduna uygulanacağını belirtir. Bu durumda modlar , instant apps , secondary users veya different abis gibi üst düzey Android modlarıyla sınırlıdır.

Paket çalıştırması sırasında, modun test için geçerli olması durumunda, moda bağlı olarak test modülünün çeşitli varyasyonları oluşturulur. Her varyasyon benzer testleri farklı modlarda yürütür.

  • instant_app : APK'ları hazır uygulama olarak yükleyen testlerin bir varyasyonunu oluşturun.
  • multi_abi : Cihaz tarafından desteklenen her ABI için testlerin bir varyasyonunu oluşturun.
  • secondary_user : APK'ları yükleyen ve testleri ikincil kullanıcı olarak çalıştıran testlerin bir varyasyonunu oluşturun.

Performans testi modülleri için metrik toplama ve son işleme

Performans testi modülleri için, performans testleri için gerekli olduklarından modül düzeyindeki metrics_collector ve metric_post_processor izin verilir. Modül düzeyinde metrik toplayıcılar ve son işlemciler modüle özel olabilir. Son işlemcilerin hem üst düzey hem de modül düzeyinde belirtilmesi önerilmez.

Bir performans test modülü yapılandırması, performance değerine sahip test-type meta verilerini içermelidir, örneğin: xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> Bu olmadan, eğer bir test config, FilePullerLogCollector dışında metric_collector veya herhangi bir metric_post_processor içeriyorsa, test ön gönderimde başarısız olur.

Örnek performans testi modülü konfigürasyonu:

<configuration description="Runs sample performance test.">
    <!-- Declare as a performance test module -->
    <option name="config-descriptor:metadata" key="test-type" value="performance" />
    <option name="test-tag" value="hello-world-performance-test" />
    <test class="com.android.tradefed.testtype.HostTest" >
        <option name="class" value="android.test.example.helloworldperformance.HelloWorldPerformanceTest" />
    </test>
    <!-- Add module-level post processor MetricFilePostProcessor -->
    <metric_post_processor class="com.android.tradefed.postprocessor.MetricFilePostProcessor">
        <option name="aggregate-similar-tests" value="true" />
        <option name="enable-per-test-log" value="false" />
    </metric_post_processor>
</configuration>