AOSP, ana makine tarafı Python dışındaki test modülleri için test şablonları içerir alt sınıfını oluşturur.
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
vebinary-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:
- Cihaz bağlantısını kontrol eder.
- Mutlak kaynak dosya yolunu belirler.
- Dosyaları
adb push
komutunu kullanarak aktarır. - 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.
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:
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:
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:
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.