Şablonları test et

AOSP, ana makine tarafı Python dışındaki test modülleri için test şablonları içerir alt sınıfını oluşturur.

Şekil 1. Şablon mimarisini test edin.

Geliştiriciler bu şablonları kullanarak, uygulamanızın entegre etmesidir. Bu bölümde, testin yapılandırılması ve kullanılması ele alınmaktadır şablonları (VTS'de bulunur) test senaryoları/şablonu dizini) ve yaygın olarak kullanılan şablonlara ilişkin örnekler sunar.

BinaryTest şablonu

Şunu kullanın: İkili Test şablonunu VTS'de hedef cihazda yürütülen testleri entegre edin. Hedef taraf testleri şunları içerir:

  • C++ tabanlı testler derlenip cihaza aktarılır
  • İkili programlar olarak derlenen hedef taraf Python testleri
  • Cihazlarda yürütülebilir kabuk komut dosyaları

Bu testler, BinaryTest ile veya bu olmadan VTS'ye entegre edilebilir tıklayın.

Hedef taraf testlerini BinaryTest şablonu

BinaryTest şablonu, geliştiricilerin kolayca entegre olması için tasarlanmıştır. test edilmesine yardımcı olur. Çoğu durumda, toplu taşıma notlarına birkaç basit satır AndroidTest.xml ürününde yapılandırma. Şuradan örnek yapılandırma: VtsDeviceTreePreviousMountTest:

<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 özgüdür.
  • Test ikili kaynağının göreli ana makine yolunu belirtmek, şablonun dosya aktarma, test yürütme, sonuç ayrıştırma ve temizle'ye dokunun.
  • Şablonda, üst sınıfların sınıflandırılması gereken alt sınıfların test edilmesi geçersiz kılmayı deneyin.
  • Şablon, her test ikili modülü başına bir test durumu ve kaynak dosya adı varsayılan olarak test durumu adı olarak kullanılır.

Yapılandırma seçenekleri

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

Seçenek adı Değer türü Açıklama
ikili-test-kaynağı dizeler adresindeki vts test durumu dizinine göre ikili program testi kaynak yolları ana bilgisayar.
. Örnek: DATA/nativetest/test
ikili-test-çalışma-dizini dizeler Çalışma dizinleri (cihaz tarafı yol).
. Örnek: /data/local/tmp/testing/
ikili-test-ortamı dizeler İkili program için ortam değişkenleri.
. Örnek: PATH=/new:$PATH
ikili-test-bağımsız değişkenleri dizeler Bağımsız değişkenleri veya işaretleri test edin.
. Örnek: --gtest_filter=test1
ikili-test-ld-library-path dizeler LD_LIBRARY_PATH ortam değişkeni.
. Örnek: /data/local/tmp/lib
ikili-test-devre dışı-bırakma-çerçevesi Boole Testten önce adb stop komutunu çalıştırarak Android Çerçevesi'ni devre dışı bırakın. Örnek: true
ikili-test-durdurma-yerel-sunucular Boole Test sırasında düzgün şekilde yapılandırılmış tüm yerel sunucuları durdurun. Örnek: true.
ikili test türü dize Şablon türü. Diğer şablon türleri bu şablonun kapsamındadır, ancak bu şablon için bu seçeneği belirtmeniz gerekmez. Zaten belirtilen binary-test-source.

strings değer türündeki seçenekler için birden çok değer ekleyebilirsiniz bunu yapılandırabilirsiniz. Örneğin, İki kez binary-test-source VtsDeviceTreeEarlyMountTest örneği).

Test etiketleri

Test etiketlerini strings ile seçeneklerin önüne ekleyerek ekleyebilirsiniz değerlerini ve ayırıcı olarak ::'ı kullanabilirsiniz. Test etiketleri özellikle Aynı ada sahip ancak farklı olan ikili kaynaklar eklenirken bitlik veya üst dizin olabilir. Örneğin, dosya aktarımını veya sonuç adını önlemek için aynı ada sahip ancak farklı kaynak dizinlere sahip kaynaklarda çakışma bu kaynaklar için farklı etiketler belirtebilirsiniz.

VtsDeviceTreeEarlyMountTest örneğinde gösterildiği gibi iki dt_early_mount_test kaynağı varsa, test etiketleri _32bit:: ve _64bit:: ön ekleri açık binary-test-source. 32bit veya 64bit, testleri otomatik bir şekilde tek bir ABI bitliği için kullanılabilir olarak işaretler; Yani _32bit etiketli testler, 64 bit ABI'da yürütülmez. Değil bir etiket belirtmek, boş dizeye sahip bir etiket kullanmakla aynı şeydir.

Aynı etiketlere sahip seçenekler gruplanır ve diğer etiketlerden izole edilir. Örneğin, örneğin, _32bit etiketli binary-test-args yalnızca aynı etiketle binary-test-source için uygulandı ve yürütüldü binary-test-working-directory içinde aynı etikete sahip. İlgili içeriği oluşturmak için kullanılan binary-test-working-directory seçeneği ikili testler için isteğe bağlıdır. Böylece etiket için tek bir çalışma dizini belirtebilirsiniz. binary-test-working-directory seçeneği varsayılan olarak belirtilmemiş dizinleri her etiket için kullanılır.

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

Hedef taraf testlerini BinaryTest şablonu

VTS'de varsayılan test biçimi, VTS koşucusundaki BaseTest. Hedef taraf testlerini entegre etmek için önce test etmek, kabuk komutlarını kullanarak testleri çalıştırmak ve ardından sonuçları elde etmenizi sağlar.

Push testi ikili programları

Dosyaları VtsFilePusher hedef hazırlayıcıyı 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 aktarır.
  4. Testler tamamlandıktan sonra dosyaları siler.

Alternatif olarak, ana makine taraflı Python testi kullanarak dosyaları manuel olarak aktarabilirsiniz komut dosyası oluşturun.

Testler yapın

Dosyaları cihaza aktardıktan sonra ana makine taraflı Python test komut dosyasıdır. Ö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

İlgili içeriği oluşturmak için kullanılan GtestBinary Testi şablonu, GTest ikili programlarını barındırır. Bu ikili programların her biri genellikle test durumu olabilir. Bu şablon, geçersiz kılınarak BinaryTest şablonunu genişletir test durumu oluşturma, sonuç ayrıştırma yöntemleri ve bu nedenle tüm BinaryTest devralınır.

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

Seçenek adı Değer türü Açıklama
ikili test türü dize Şablon türü. gtest değerini kullanır.
gtest-toplu-modu Boole Gtest ikili programlarını toplu modda çalıştırın. Örnek: true

Genel olarak, gtest-batch-mode ayarı true olarak ayarlanıyor performansı biraz artırırken güvenilirliği de biraz azaltır. VTS uygunluğunda birçok modül, performansı artırmak için toplu modu kullanır. Güvenilirlik için Bununla birlikte, mod belirtilmemişse varsayılan olarak toplu olmayan mod kullanılır.

Toplu olmayan mod

Toplu olmayan mod, her test durumu için GTest ikili programına ayrı çağrılar yapar. Örneğin, Örneğin, GTest ikili programı 10 test durumu içeriyorsa (ana makineye göre filtrelendikten sonra) tarafı yapılandırma) kullanıyorsa ikili program, her seferinde cihaz kabuğunda 10 kez çağrılır kullanabilirsiniz. Her test durumu için benzersiz bir GTest sonucu çıkışı XML, şablon tarafından oluşturulur ve ayrıştırılır.

Şekil 2. Toplu olmayan mod.

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

  • Test durumu izolasyonu. Kilitlenme veya test durumunda askıda kalma diğer test durumlarını etkilemez.
  • Ayrıntı düzeyi. Her test durumu için daha kolay profil oluşturma/kapsama alma systrace, errorreport, logcat vb. test sonuçları ve günlükleri her test durumu bittikten hemen sonra alınır.

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

  • Gereksiz 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 ek yükü. Test tamamlandıktan sonra ana makine ve hedef cihaz, sonuç ayrıştırma ve sonraki komutlar için iletişim kurar (gelecekteki optimizasyon yapabilirsiniz).

Toplu mod

GTest toplu modunda, test ikili programı uzun bir testle yalnızca bir kez çağrılır ana makine tarafı yapılandırması tarafından filtrelenen tüm test durumlarını içeren filtre değeri (bu toplu olmayan modda gereksiz yükleme sorununu önler). Ayrıca, tüm dünya genelinde geçerli olan çıkış.xml veya terminal çıkışı kullanarak GTest için sonuç.

Çıkış.xml (varsayılan) kullanırken:

Şekil 3. Toplu mod, çıkış.xml.

Toplu olmayan modda olduğu gibi, test sonucu GTest çıkış XML dosyası üzerinden ayrıştırılır dosyası olarak kaydedebilirsiniz. Ancak xml çıkışı, tüm testler tamamlandıktan sonra oluşturulduğu için bir test durumu ikili programın veya cihazın kilitlenmesine neden olduysa sonuç yok xml dosyası elde edilir.

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

Şekil 4. Toplu mod, terminal çıkışı.

GTest çalışırken, test günlüğünü ve ilerleme durumunu terminale yazdırır ve test durumu, sonuçlar ve raporlama çerçevesiyle ayrıştırılabilir bir biçimde günlükler.

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

  • Test durumu izolasyonu. Aynı düzeyde test sağlar çerçeve, ikili programı/cihazı yeniden başlatırsa büyük/küçük harf izolasyonu azaltılmış test filtresiyle yaşanan bir kilitlenmeden sonra (tamamlanmış ve çökmüş test hariç) durumlarda).
  • Ayrıntı düzeyi. Şununla aynı test durumu ayrıntı düzeyini sağlar: toplu olmayan moddur.

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

  • Bakım maliyeti. GTest günlük kaydı biçimi değişirse başarısız olur.
  • Karışıklık. Bir test durumu, GTest'e benzer bir çıktı yazdırabilir biçimi bozulabilir.

Bu dezavantajlar nedeniyle, komut satırı çıkışı. Gelecekte bu seçeneği, güvenilirliğini artırır.

HostBinaryTest şablonu

HostBinaryTest şablonu, ana makine tarafında mevcut olmayan yürütülebilir dosyaları içeriyor diğer dizinlerde veya Python komut dosyalarında saklar. Bu testler şunlardır:

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

Bir örnek olarak GD Güvenlik 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 bir test kullanır test yapılandırmalarına sahip olur. Yukarıdaki örnekte, binary-test-source seçeneği, test yürütülebilir dosyasının ana makine tarafı göreli yolunu belirtir ve binary-test-type host_binary_test. Şuna benzer: BinaryTest şablonunun ikili dosya adı, varsayılandır.

Mevcut şablonları genişlet

Python olmayan testleri dahil etmek için şablonları doğrudan test yapılandırmasında kullanabilirsiniz veya belirli test gereksinimlerini karşılayacak şekilde bunları alt sınıflara dağıtabilirler. Şablonlar VTS deposu aşağıdaki uzantılara sahiptir:

Şekil 5. VTS'deki mevcut şablonların kapsamını genişletme kod deposudur.

Geliştiricilerin mevcut şablonları belirli bir şablon için genişletmesi test gereksinimleri. Şablonların kapsamını genişletmenin yaygın nedenleri şunlardır:

  • Özel test kurulumuyla bir cihazı hazırlamak gibi, komutlarının ikisine katlanır.
  • Farklı test durumları ve test adları oluşturma
  • Komut çıkışını okuyarak veya diğer koşulları kullanarak sonuçları ayrıştırma.

Mevcut şablonların kapsamını genişletmeyi kolaylaştırmak için şablonlar, çeşitli yöntemler içerir. her işlev için özel hale getirilmiştir. Mevcut web sitesi için daha iyi tasarımlar VTS kod tabanına katkıda bulunmanızı öneririz.