Şablonları test et

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

Geliştiriciler, bu tür testleri entegre etmeyle ilgili çabayı en aza indirmek için bu şablonları kullanabilir. Bu bölümde, test şablonlarının (VTS testcases/template dizininde bulunur) yapılandırılması ve kullanılması ele alınmakta, yaygın olarak kullanılan şablonlar için örnekler verilmektedir.

BinaryTest şablonu

Hedef cihazda çalıştırılan testleri VTS'ye entegre etmek için BinaryTest şablonunu kullanın. Hedef taraflı testler şunları içerir:

• Derlenen ve cihaza gönderilen C++ tabanlı testler
• Hedef taraflı Python testleri ikili olarak derlenmiştir.
• Cihazlarda çalıştırılabilir kabuk komut dosyaları

Bu testler, BinaryTest şablonu kullanılarak veya kullanılmadan VTS'ye entegre edilebilir.

Hedef tarafı testleri BinaryTest şablonuyla entegre etme

BinaryTest şablonu, geliştiricilerin hedef taraf testlerini kolayca entegre etmesine 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 yapılandırmada:

• binary-test-source ve binary-test-type, şablona özeldir.
• Test ikili kaynağının göreli ana makine yolunu belirtmek, şablonun hazırlık, dosya yayınlama, test yürütme, sonuç ayrıştırma ve temizleme işlemlerini yapmasını sağlar.
• Şablon, alt sınıfların geçersiz kılabileceği test kaydı oluşturmayla ilgili yöntemler içerir.
• Şablonda, test ikili modülü başına bir test durumu varsayılır ve varsayılan olarak test durumu adı olarak ikili kaynak dosya adı kullanılır.

Yapılandırma seçenekleri

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

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

Test etiketleri

strings değerlerine sahip seçeneklere ön ek ekleyerek ve ayırıcı olarak :: kullanarak test etiketleri ekleyebilirsiniz. Test etiketleri, özellikle aynı ada ancak farklı bit sayısına veya üst dizinlere sahip ikili kaynaklar dahil edilirken kullanışlıdır. Örneğin, aynı ada sahip ancak farklı kaynak dizinlerinden gelen kaynaklarda dosya itme veya sonuç adı çakışmasını önlemek için bu kaynaklar için farklı etiketler belirtebilirsiniz.

İki dt_early_mount_test kaynağı içeren VtsDeviceTreeEarlyMountTest örneğinde gösterildiği gibi, test etiketleri binary-test-source'teki _32bit:: ve _64bit:: ön ekleridir. 32bit veya 64bit ile biten etiketler, testleri otomatik olarak bir ABI bitliği için kullanılabilir olarak işaretler. Yani _32bit etiketine sahip testler 64 bit ABI'de yürütülmez. Etiket belirtmemek, boş bir dize içeren bir etiket kullanmakla aynıdır.

Aynı etiketlere sahip seçenekler gruplandırılır ve diğer etiketlerden ayrılır. Örneğin, _32bit etiketine sahip binary-test-args yalnızca aynı etikete sahip binary-test-source'e uygulanır ve aynı etiketle binary-test-working-directory'te 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 belirtilmediğinde her etiket için varsayılan dizinler kullanılır.

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

BinaryTest şablonu olmadan hedef tarafı testleri entegre etme

VTS'de varsayılan test biçimi, VTS çalıştırıcısındaki BaseTest'ten genişletilen ana makine taraflı Python testleridir. Hedef taraf testlerini entegre etmek için önce test dosyalarını cihaza göndermeniz, testleri kabuk komutlarını kullanarak çalıştırmanız ve ardından sonuçları ana makine tarafında Python komut dosyalarını kullanarak ayrıştırmanız gerekir.

Test ikili programlarını yayınlama

Dosyaları VtsFilePusher hedef hazırlayıcıyı kullanarak göndermenizi ö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 şu işlemleri yapar:

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

Alternatif olarak, benzer bir prosedür izleyen ana makine tarafında bir Python test komut dosyası kullanarak dosyaları manuel olarak da yayınlayabilirsiniz.

Test çalıştırma

Dosyaları cihaza yükledikten sonra, ana makine tarafında bir Python test komut dosyasında shell 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 ikililerini barındırır. Bu şablon, kurulum, test kaydı 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 değerini true olarak ayarlamak performansı artırırken güvenilirliği biraz azaltır. VTS uygunluk testlerinde birçok modül, performansı artırmak için toplu modu kullanır. Ancak güvenilirlik için mod belirtilmezse varsayılan olarak toplu olmayan ayar kullanılır.

Toplu olmayan mod

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

Toplu olmayan modu kullanmanın avantajları arasında şunlar vardır:

• Test kaydı izolasyonu. Bir test durumundaki kilitlenme veya donma, diğer test durumlarını etkilemez.
• Ayrıntı düzeyi. Test başına profil oluşturma/kapsama ölçümü, systrace, hata raporu, logcat vb. elde etmek daha kolaydır. Test sonuçları ve günlükler, her test durumu sona erdikten hemen sonra alınır.

Toplu olmayan modun dezavantajları arasında şunlar vardır:

• Yedek yükleme. GTest ikili programı her çağrıldığında ilgili kitaplıkları yükler ve ilk sınıf kurulumlarını gerçekleştirir.
• İletişim yükü. Bir test tamamlandıktan sonra ana makine ve hedef cihaz, sonuç ayrıştırma ve sonraki komutlar için iletişim kurar (gelecekte optimizasyonlar yapılabilir).

Toplu mod

GTest toplu modunda, test ikilisi yalnızca bir kez çağrılır ve bu çağrıda, ana makine tarafı yapılandırmaya göre filtrelenen tüm test örneklerini içeren uzun bir test filtresi değeri kullanılır (bu, toplu olmayan modda gereksiz yükleme sorununu önler). GTest için test sonuçlarını output.xml dosyasını veya terminal çıkışını kullanarak ayrıştırabilirsiniz.

output.xml kullanılırken (varsayılan):

Toplu olmayan modda olduğu gibi, test sonucu GTest çıkış xml dosyası aracılığıyla ayrıştırılır. Ancak çıkış XML'i tüm testler tamamlandıktan sonra oluşturulduğundan, bir test durumu ikili dosyayı veya cihazı çökerttiyse 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ılabilen bir biçimde terminale yazdırır.

Toplu modu kullanmanın avantajları arasında şunlar vardır:

• Test kaydı izolasyonu. Çerçeve, bir kilitlenmeden sonra azaltılmış test filtresiyle (bitmiş ve kilitlenen test durumları hariç) ikili dosyayı/cihazı yeniden başlatırsa toplu olmayan modla aynı düzeyde test durumu izolasyonu sağlar.
• Ayrıntı düzeyi. Toplu olmayan modla aynı test kaydı ayrıntı düzeyini sağlar.

Toplu modu kullanmanın dezavantajları arasında şunlar vardır:

• Bakım maliyeti. GTest günlük kaydı biçimi değişirse tüm testler bozulur.
• Kafa karışıklığı. Bir test durumu, GTest ilerleme biçimine benzer bir şey yazdırabilir ve bu da biçimin kafanızı karıştırmasına neden olabilir.

Bu dezavantajlar nedeniyle, komut satırı çıkışı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 tekrar gözden geçireceğiz.

HostBinaryTest şablonu

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

• Ana makinede yürütülebilir derlenmiş test ikili dosyaları
• Kabuk, Python veya diğer dillerde yürütülebilir komut dosyaları

Örneğin, VTS Security SELinux politikası ana makine tarafı testi:

<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ının ana makine tarafında göreli bir yolunu belirtir ve binary-test-type, host_binary_test olur. BinaryTest şablonuna benzer şekilde, varsayılan olarak test kaydı adı olarak ikili dosya adı kullanılır.

Mevcut şablonları genişletme

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

Geliştiricilerin, mevcut şablonları belirli test şartlarına göre genişletmeleri önerilir. Şablonları uzatma nedenlerinden bazıları şunlardır:

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

Mevcut şablonları genişletmeyi kolaylaştırmak için şablonlar her işleve özel yöntemler içerir. Mevcut şablonların tasarımlarını iyileştirdiyseniz VTS kod tabanına katkıda bulunmanızı öneririz.