Test şablonları

AOSP, VTS çalıştırıcısının BaseTest'inin ana bilgisayar tarafı Python alt sınıfı olmayan test modülleri için test şablonları içerir.

Geliştiriciler bu tür testlerin entegrasyonunda harcanan çabayı en aza indirmek için bu şablonları kullanabilir. Bu bölüm, test şablonlarının (VTS test senaryoları/şablon dizininde bulunur) yapılandırılmasını ve kullanılmasını kapsar ve yaygın olarak kullanılan şablonlar için örnekler sağlar.

İkili Test şablonu

Hedef cihazda yürütülen testleri VTS'ye entegre etmek için BinaryTest şablonunu kullanın. Hedef tarafı testleri şunları içerir:

• C++ tabanlı testler derlendi ve cihaza aktarıldı
• İkili dosyalar olarak derlenen hedef tarafı Python testleri
• Cihazlarda çalıştırılabilir kabuk komut dosyaları

Bu testler BinaryTest şablonu olsun veya olmasın VTS'ye entegre edilebilir.

Hedef tarafı testlerini BinaryTest şablonuyla entegre edin

BinaryTest şablonu, geliştiricilerin hedef taraf testlerini kolayca entegre etmelerine yardımcı olmak için tasarlanmıştır. Çoğu durumda AndroidTest.xml dosyasına birkaç basit yapılandırma satırı ekleyebilirsiniz. VtsDeviceTreeEarlyMountTest'ten örnek yapılandırma:

<configuration description="Config for VTS VtsDeviceTreeEarlyMountTest.">
  ...
<test class="com.android.tradefed.testtype.VtsMultiDeviceTest">
<option name="test-module-name" value="VtsDeviceTreeEarlyMountTest"/>
<option name="binary-test-source" value="_32bit::DATA/nativetest/dt_early_mount_test/dt_early_mount_test" />
<option name="binary-test-source" value="_64bit::DATA/nativetest64/dt_early_mount_test/dt_early_mount_test" />
<option name="test-timeout" value="5m"/>
</test>
</configuration>

Bu konfigürasyonda:

• binary-test-source ve binary-test-type şablona özeldir.
• Test ikili kaynağının ilgili ana bilgisayar yolunun belirtilmesi, şablonun hazırlık, dosya gönderme, test yürütme, sonuç ayrıştırma ve temizleme işlemlerini gerçekleştirmesine olanak tanır.
• Şablon, alt sınıfların geçersiz kılınması için test senaryosu oluşturmaya ilişkin yöntemleri içerir.
• Şablon, test ikili modülü başına bir test senaryosunu varsayar ve ikili kaynak dosya adı, varsayılan olarak test senaryosu adı olarak kullanılır.

Yapılandırma seçenekleri

BinaryTest şablonu aşağıdaki yapılandırma seçeneklerini destekler:

Değer türü strings sahip seçenekler için, yapılandırmadaki seçenekleri tekrarlayarak birden çok değer ekleyebilirsiniz. Örneğin, binary-test-source iki kez ayarlayın ( VtsDeviceTreeEarlyMountTest örneğinde gösterildiği gibi).

Etiketleri test edin

Test etiketlerini, strings değerlerine sahip seçeneklere önek ekleyerek ve sınırlayıcı olarak :: kullanarak ekleyebilirsiniz. Test etiketleri özellikle aynı ada sahip ancak farklı bit değerlerine veya ana dizinlere sahip ikili kaynaklar dahil edildiğinde kullanışlıdır. Örneğin, aynı ada sahip ancak farklı kaynak dizinlerinden gelen kaynaklar için dosya gönderme veya sonuç adı çakışmasını önlemek amacıyla, bu kaynaklar için farklı etiketler belirleyebilirsiniz.

İki dt_early_mount_test kaynağıyla VtsDeviceTreeEarlyMountTest örneğinde gösterildiği gibi, test etiketleri binary-test-source üzerindeki _32bit:: ve _64bit:: önekleridir. 32bit veya 64bit ile biten etiketler, testleri otomatik olarak bir ABI biti için uygun olarak işaretler; yani _32bit etiketli testler 64 bit ABI'de yürütülmez. Etiket belirtmemek, boş dizeye sahip bir etiket kullanmaya eşittir.

Aynı etiketlere sahip seçenekler gruplandırılır ve diğer etiketlerden ayrılır. Örneğin, _32bit etiketli binary-test-args yalnızca aynı etiketli binary-test-source uygulanır ve aynı etiketli binary-test-working-directory yürütülür. binary-test-working-directory seçeneği ikili testler için isteğe bağlıdır ve bir etiket için tek bir çalışma dizini belirtmenize olanak tanır. binary-test-working-directory seçeneği belirtilmeden bırakıldığında her etiket için varsayılan dizinler kullanılır.

Etiket adı, sonuç raporunda doğrudan test senaryosu adına eklenir. Örneğin, _32bit etiketli test senaryosu testcase1 , sonuç raporunda testcase1_32bit olarak görünür.

BinaryTest şablonu olmadan hedef tarafı testlerini entegre edin

VTS'de varsayılan test formatı, VTS çalıştırıcısındaki BaseTest'ten genişletilen ana bilgisayar tarafı Python testleridir. Hedef taraf testlerini entegre etmek için önce test dosyalarını cihaza göndermeli, testleri kabuk komutlarını kullanarak yürütmeli, ardından sonuçları ana bilgisayar tarafındaki Python komut dosyalarını kullanarak ayrıştırmalısınız.

Test ikili dosyalarını itin

Dosyaları VtsFilePusher hedef hazırlayıcısını kullanarak aktarmanızı öneririz. Örnek:

<target_preparer class="com.android.compatibility.common.tradefed.targetprep.VtsFilePusher">
        <option name="push" value="DATA/test->/data/local/tmp/test"/>
    </target_preparer>

VtsFilePusher şunları yapar:

1. Cihaz bağlantısını kontrol eder.
2. Mutlak kaynak dosya yolunu belirler.
3. Dosyaları adb push komutunu kullanarak iter.
4. Testler tamamlandıktan sonra dosyaları siler.

Alternatif olarak, benzer bir prosedürü izleyen ana bilgisayar tarafındaki Python test komut dosyasını kullanarak dosyaları manuel olarak gönderebilirsiniz.

Testleri çalıştır

Dosyaları cihaza gönderdikten sonra, ana bilgisayar tarafındaki Python test komut dosyasındaki kabuk komutlarını kullanarak testi çalıştırın. Örnek:

device = self.android_devices[0]
res = device.shell.Execute(["chmod a+x /data/local/tmp/test", "/data/local/tmp/test"])
asserts.AssertFalse(any(res[return_codes]))

GtestBinaryTest şablonu

GtestBinaryTest şablonu , her biri genellikle birden fazla test senaryosu içeren GTest test ikili dosyalarını barındırır. Bu şablon, kurulum, test senaryosu oluşturma ve sonuç ayrıştırma yöntemlerini geçersiz kılarak BinaryTest şablonunu genişletir, böylece tüm BinaryTest yapılandırmaları devralınır.

GtestBinaryTest, gtest-batch-mode seçeneğini ekler:

Genel olarak, gtest-batch-mode true olarak ayarlanması performansı artırırken güvenilirliği biraz azaltır. VTS uyumluluk testlerinde birçok modül, performansı artırmak için toplu modu kullanır. Ancak güvenilirlik açısından mod belirtilmezse varsayılan olarak toplu olmayan mod kullanılır.

Toplu olmayan mod

Toplu olmayan mod, her test durumu için GTest ikili dosyasına bireysel çağrılar yapar. Örneğin, GTest ikili dosyası 10 test senaryosu içeriyorsa (ana bilgisayar tarafı yapılandırmasına göre filtrelendikten sonra), ikili dosya her seferinde farklı bir test filtresiyle cihaz kabuğunda 10 kez çağrılır. Her test durumu için benzersiz bir GTest sonuç çıktısı XML'i şablon tarafından oluşturulur ve ayrıştırılır.

Toplu olmayan modu kullanmanın avantajları şunlardır:

• Test senaryosu izolasyonu . Bir test senaryosundaki çökme veya takılma, diğer test senaryolarını etkilemez.
• Parçalılık . Test senaryosu başına profil oluşturma/kapsama ölçümü, systrace, hata raporu, logcat vb.'yi almak daha kolaydır. Test sonuçları ve günlükler, her test senaryosu tamamlandıktan hemen sonra alınır.

Toplu olmayan modu kullanmanın dezavantajları şunlardır:

• Yedekli yükleme . GTest ikilisi her çağrıldığında ilgili kütüphaneleri yükler ve başlangıç ​​sınıfı kurulumlarını gerçekleştirir.
• İletişim yükü . Test tamamlandıktan sonra ana bilgisayar ve hedef cihaz, sonuç ayrıştırma ve sonraki komutlar için iletişim kurar (gelecekteki optimizasyonlar mümkündür).

Toplu modu

GTest toplu modunda, test ikili dosyası, ana bilgisayar tarafı yapılandırması tarafından filtrelenen tüm test senaryolarını içeren uzun bir test filtresi değeriyle yalnızca bir kez çağrılır (bu, toplu olmayan modda yedekli yükleme sorununu önler). GTest için test sonuçlarını çıktı.xml veya terminal çıktısını kullanarak ayrıştırabilirsiniz.

Output.xml kullanırken (varsayılan):

Toplu olmayan modda olduğu gibi, test sonucu GTest çıktı xml dosyası aracılığıyla ayrıştırılır. Ancak çıktı xml'si tüm testler tamamlandıktan sonra oluşturulduğundan, bir test senaryosunun ikili dosyayı veya aygıtı çökertmesi durumunda sonuç xml dosyası oluşturulmaz.

Terminal çıkışını kullanırken:

GTest çalışırken test günlüğünü ve ilerleme durumunu, test durumu, sonuçlar ve günlükler için çerçeve tarafından ayrıştırılabilecek bir formatta terminale yazdırır.

Toplu modunu kullanmanın avantajları şunlardır:

• Test senaryosu izolasyonu . Çerçeve, bir kilitlenme sonrasında ikili dosyayı/aygıtı azaltılmış bir test filtresiyle yeniden başlatırsa (bitmiş ve çökmüş test senaryoları hariç), toplu olmayan modla aynı seviyede test senaryosu izolasyonu sağlar.
• Parçalılık . Toplu olmayan modla aynı test senaryosu ayrıntı düzeyini sağlar.

Toplu modunu kullanmanın dezavantajları şunlardır:

• Bakım maliyeti . GTest günlük kaydı formatı değişirse tüm testler bozulur.
• Bilinç bulanıklığı, konfüzyon . Bir test senaryosu GTest ilerleme formatına benzer bir şey yazdırabilir ve bu da formatın karışmasına neden olabilir.

Bu dezavantajlardan dolayı komut satırı çıktısını kullanma seçeneğini geçici olarak kaldırdık. Bu işlevin güvenilirliğini artırmak için gelecekte bu seçeneği yeniden ele alacağız.

HostBinaryTest şablonu

HostBinaryTest şablonu, diğer dizinlerde veya Python komut dosyalarında bulunmayan ana bilgisayar tarafında yürütülebilir dosyalar içerir. Bu testler şunları içerir:

• Ana bilgisayarda çalıştırılabilir derlenmiş test ikili dosyaları
• Shell, Python veya diğer dillerde çalıştırılabilir komut dosyaları

Bunun bir örneği , VTS Security SELinux ilkesi ana bilgisayar tarafı testidir :

<configuration description="Config for VTS  Security SELinux policy host-side test cases">
    ...
    <test class="com.android.tradefed.testtype.VtsMultiDeviceTest">
        <option name="test-module-name" value="VtsSecuritySelinuxPolicyHost"/>
        <option name="binary-test-source" value="out/host/linux-x86/bin/VtsSecuritySelinuxPolicyHostTest" />
        <option name="binary-test-type" value="host_binary_test"/>
    </test>
</configuration>

HostBinaryTest, BinaryTest şablonunu genişletmez ancak benzer test yapılandırmalarını kullanır. Yukarıdaki örnekte, binary-test-source seçeneği, test yürütülebilir dosyasına giden ana bilgisayar tarafı göreli yolunu belirtir ve binary-test-type host_binary_test . BinaryTest şablonuna benzer şekilde, ikili dosya adı varsayılan olarak test senaryosu adı olarak kullanılır.

Mevcut şablonları genişlet

Python dışı testleri dahil etmek için şablonları doğrudan test yapılandırmasında kullanabilir veya belirli test gereksinimlerini karşılamak için bunları bir alt sınıfa genişletebilirsiniz. VTS deposundaki şablonlar aşağıdaki uzantılara sahiptir:

Geliştiricilerin, herhangi bir özel test gereksinimi için mevcut herhangi bir şablonu genişletmeleri teşvik edilir. Şablonları genişletmenin yaygın nedenleri şunlardır:

• Özel komutlarla cihazın hazırlanması gibi özel test kurulum prosedürleri.
• Farklı test senaryoları ve test adları oluşturma.
• Komut çıktısını okuyarak veya diğer koşulları kullanarak sonuçları ayrıştırma.

Mevcut şablonların genişletilmesini kolaylaştırmak için şablonlar her işlevsellik için özelleştirilmiş yöntemler içerir. Mevcut şablonlar için geliştirilmiş tasarımlarınız varsa VTS kod tabanına katkıda bulunmanızı öneririz.