Bu, Test Eşlemenin kısa bir tanıtımı ve Android Açık Kaynak Projesi'nde (AOSP) testleri kolayca yapılandırmaya nasıl başlayacağınızın açıklamasıdır.
Test Haritalama Nedir?
Test Mapping, geliştiricilerin doğrudan Android kaynak ağacında gönderme öncesi ve sonrası test kuralları oluşturmasına ve test edilecek dalların ve cihazların kararlarını test altyapısının kendisine bırakmasına olanak tanıyan Gerrit tabanlı bir yaklaşımdır. Test Eşleme tanımları, herhangi bir kaynak dizine yerleştirilebilen TEST_MAPPING adlı JSON dosyalarıdır.
Atest , ilişkili dizinlerde ön gönderim testleri çalıştırmak için TEST_MAPPING dosyalarını kullanabilir. Test Eşleme ile, Android kaynak ağacında basit bir değişiklikle kontrolleri önceden göndermek için aynı test setini ekleyebilirsiniz.
Şu örneklere bakın:
Services.core için TEST_MAPPING'e ön gönderim testleri ekleyin
İçe aktarma kullanan araçlar/dexter için TEST_MAPPING'e ön gönderme testleri ekleyin
Test Eşleme, testlerin yürütülmesi ve sonuçların raporlanması için Ticaret Federasyonu (TF) Test Donanımına dayanır.
Test gruplarını tanımlama
Test Haritalama grupları testleri, bir test grubu aracılığıyla yapılır. Bir test grubunun adı herhangi bir dize olabilir. Örneğin, önceden gönderme , değişiklikleri doğrularken çalıştırılacak bir grup test için olabilir. Gönderim sonrası testler, değişiklikler birleştirildikten sonra yapıları doğrulamak için kullanılabilir.
Paketleme oluşturma komut dosyası kuralları
Trade Federation Test Harness'in belirli bir yapı için Test Mapping'in test modüllerini çalıştırabilmesi için, bu modüllerin Soong için test_suite setine veya Make için LOCAL_COMPATIBILITY_SUITE setinin şu iki süitten birine sahip olması gerekir:
- genel testler - cihaza özel işlevselliğe bağlı olmayan testler (çoğu cihazda bulunmayan satıcıya özel donanım gibi). Çoğu test, bir ABI'ye veya bitliğe veya HWASan gibi donanım özelliklerine özgü olsalar bile (her ABI için ayrı bir test_suites hedefi vardır) ve bir cihazda çalıştırılmaları gerekse bile, genel testler paketinde olmalıdır.
- cihaz testleri - cihaza özel işlevselliğe bağlı testler. Tipik olarak bu testler
vendor/
altında bulunur. "Cihaza özel", diğer cihazların sahip olabileceği veya olmayabileceği ABI veya SoC işlevselliğine değil, yalnızca bir cihaza özgü işlevselliğe atıfta bulunduğundan, bu, JUnit testleri için GTest yerel testleri kadar geçerlidir (genellikle olması gerekir). ABI'ye özgü olsalar bilegeneral-tests
olun).
Örnekler:
Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests
Testleri bir test paketinde çalışacak şekilde yapılandırma
Bir test paketinin içinde çalıştırılacak bir test için test:
- herhangi bir yapı sağlayıcısı olmamalıdır.
- örneğin test sırasında oluşturulan tüm geçici dosyaları silerek, tamamlandıktan sonra temizlemesi gerekir.
- sistem ayarlarını varsayılan veya orijinal değere değiştirin.
- belirli bir durumda bir cihaz varsaymamalıdır, örneğin, root hazır. Çoğu testin çalışması için kök ayrıcalığı gerekmez. Bir testin kök gerektirmesi gerekiyorsa, aşağıdaki örnekte olduğu gibi
AndroidTest.xml
RootTargetPreparer
ile bunu belirtmelidir:
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
Test Eşleme dosyaları oluşturma
Test kapsamı gerektiren dizin için aşağıdaki örneğe benzeyen bir TEST_MAPPING JSON dosyası eklemeniz yeterlidir. Bu kurallar, o dizinde veya alt dizinlerinden herhangi birinde herhangi bir dosyaya dokunulduğunda testlerin ön gönderme kontrollerinde çalışmasını sağlayacaktır.
Örnek takip
İşte örnek bir TEST_MAPPING
dosyası (JSON biçimindedir ancak yorumlar desteklenir):
{
"presubmit": [
// JUnit test with options and file patterns.
{
"name": "CtsWindowManagerDeviceTestCases",
"options": [
{
"include-annotation": "android.platform.test.annotations.RequiresDevice"
}
],
"file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
},
// Device-side GTest with options.
{
"name" : "hello_world_test",
"options": [
{
"native-test-flag": "\"servicename1 servicename2\""
},
{
"native-test-timeout": "6000"
}
]
}
// Host-side GTest.
{
"name" : "net_test_avrcp",
"host" : true
}
],
"postsubmit": [
{
"name": "CtsWindowManagerDeviceTestCases"
}
],
"imports": [
{
"path": "frameworks/base/services/core/java/com/android/server/am"
}
]
}
Nitelikleri ayarlama
Yukarıdaki örnekte, presubmit
ve postsubmit
, her bir test grubunun adıdır. Test grupları hakkında daha fazla bilgi için Test gruplarını tanımlama bölümüne bakın.
Test modülünün adı veya Trade Federation entegrasyon test adı (test XML dosyasına giden kaynak yolu, örneğin uiautomator/uiautomator-demo ) name
özniteliğinin değerinde ayarlanabilir. Ad alanının sınıf name
veya test yöntemi name
kullanamayacağını unutmayın. Çalıştırılacak testleri daraltmak için burada include-filter
gibi seçenekleri kullanabilirsiniz. Bakınız ( dahil etme filtresi örnek kullanımı ).
Bir testin ana bilgisayar ayarı, testin ana bilgisayar üzerinde çalışan cihazsız bir test olup olmadığını gösterir. Varsayılan değer false , yani testin çalışması için bir cihaz gerekir. Desteklenen test türleri, GTest ikili dosyaları için HostGTest ve JUnit testleri için HostTest'tir.
file_patterns özniteliği, herhangi bir kaynak kod dosyasının (TEST_MAPPING dosyasını içeren dizine göre) göreli yolunu eşleştirmek için normal ifade dizelerinin bir listesini ayarlamanıza olanak tanır. Yukarıdaki örnekte, CtsWindowManagerDeviceTestCases
testi, yalnızca herhangi bir Java dosyası, TEST_MAPPING dosyasının veya alt dizinlerinin aynı dizininde bulunan Window veya Activity ile başladığında, ön gönderimde çalışır. Bir JSON dosyasında oldukları için ters eğik çizgilerden \ kaçınılması gerekir.
imports özelliği, içeriği kopyalamadan testleri diğer TEST_MAPPING dosyalarına dahil etmenize olanak tanır. İçe aktarılan yolun üst dizinlerindeki TEST_MAPPING dosyalarının da dahil edileceğini unutmayın. Test Eşleme, iç içe içe aktarmalara izin verir; bu, iki TEST_MAPPING dosyasının birbirini içe aktarabileceği ve Test Eşleme'nin dahil edilen testleri uygun şekilde birleştirebileceği anlamına gelir.
options özelliği, ek TradeFed komut satırı seçeneklerini içerir.
Belirli bir test için mevcut seçeneklerin tam listesini almak için şunu çalıştırın:
tradefed.sh run commandAndExit [test_module] --help
Opsiyonların nasıl çalıştığı hakkında daha fazla ayrıntı için TradeFed Opsiyon İşleme bölümüne bakın.
Atest ile test çalıştırma
Ön gönderim test kurallarını yerel olarak yürütmek için:
- TEST_MAPPING dosyasını içeren dizine gidin.
- Komutu çalıştırın:
atest
Geçerli dizinin ve üst dizinlerinin TEST_MAPPING dosyalarında yapılandırılan tüm ön gönderme testleri çalıştırılır. Atest, ön gönderim (A ve B) için iki testi belirleyecek ve çalıştıracaktır.
Bu, geçerli çalışma dizinindeki (CWD) ve üst dizinlerdeki TEST_MAPPING dosyalarında ön gönderim testleri çalıştırmanın en basit yoludur. Atest, CWD ve tüm üst dizinlerindeki TEST_MAPPING dosyasını bulur ve kullanır.
Kaynak kodunu yapılandırma
Aşağıdaki örnek, TEST_MAPPING dosyalarının kaynak ağaçta nasıl yapılandırılabileceğini gösterir.
src
├── project_1
│ └── TEST_MAPPING
├── project_2
│ └── TEST_MAPPING
└── TEST_MAPPING
src/TEST_MAPPING
:
{
"presubmit": [
{
"name": "A"
}
]
}
src/project_1/TEST_MAPPING
:
{
"presubmit": [
{
"name": "B"
}
],
"postsubmit": [
{
"name": "C"
}
],
"other_group": [
{
"name": "X"
}
]}
src/project_2/TEST_MAPPING
:
{
"presubmit": [
{
"name": "D"
}
],
"import": [
{
"path": "src/project_1"
}
]}
Hedef dizinleri belirtme
Bu dizindeki TEST_MAPPING dosyalarında testleri çalıştırmak için bir hedef dizin belirleyebilirsiniz. Aşağıdaki komut iki testi (A, B) çalıştıracaktır.
atest --test-mapping src/project_1
Gönderim sonrası test kurallarını çalıştırma
Bu komutu, src_path
(varsayılan olarak CWD'dir) ve üst dizinlerinde TEST_MAPPING içinde tanımlanan gönderme sonrası test kurallarını çalıştırmak için de kullanabilirsiniz:
atest [--test-mapping] [src_path]:postsubmit
Yalnızca cihaz gerektirmeyen testleri çalıştırma
Yalnızca hiçbir cihaz gerektirmeyen ana bilgisayara karşı yapılandırılmış testleri çalıştırmak için Atest için --host seçeneğini kullanabilirsiniz. Bu seçenek olmadan Atest, cihaz gerektirenler ve ana bilgisayar üzerinde çalışan ve cihaz gerektirmeyen testler olmak üzere her iki testi de çalıştırır. Testler iki ayrı süitte yürütülecektir.
atest [--test-mapping] --host
test gruplarını belirleme
Sen ATEST komuta test gruplarını belirtebilirsiniz. Aşağıdaki komut yalnızca bir testi (C) içeren dizin src / project_1, dosyalara ilişkin tüm postsubmit testler yapar.
Yoksa kullanabilirsiniz : Tüm bağımsız grubun tüm testler. Aşağıdaki komut dört deney (A, B, C, X) çalışır:
atest --test-mapping src/project_1:all
alt dizinleri dahil
Varsayılan olarak, ATEST ile TEST_MAPPING testler yürütmek sadece presubmit CWD'sindeki (veya verilen dizin) TEST_MAPPING dosyasında yapılandırılmış testler ve üst dizinleri çalışacaktır. Eğer alt dizinleri tüm TEST_MAPPING dosyalarında testlerini çalıştırmak istiyorsanız, opsiyon kullanma --include-subdir
çok O testleri dahil etmek ATEST zorlamak için.
atest --include-subdir
Olmadan --include-subdir
seçeneğiyle, ATEST ile tek bir test A. çalışacaktır --include-subdir
ATEST iki testleri (A, B) çalışır, opsiyon.
Hat düzeyinde açıklama desteklenmektedir
Bir çizgi düzeyinde ekleyebilir //
aşağıdaki ayarın açıklaması ile TEST_MAPPING dosyasını ayrıntılı hale getirmeye -Format yorumunu. ATest ve Ticaret Federasyonu Yorum içermeyen geçerli bir JSON biçimine TEST_MAPPING ön işlemeden edecektir. Sadece hat düzey, temiz ve kolay okunur JSON dosyasını tutmak için //
-Format açıklama desteklenmektedir.
Misal:
{
// For presubmit test group.
"presubmit": [
{
// Run test on module A.
"name": "A"
}
]
}