Eşlemeyi test et

Bu, test eşleştirmenin kısa bir tanıtımıdır ve teste katlanmak , Android Açık Kaynak Projesi'nde (AOSP) testleri yapılandırmaya başladı.

Test eşleme hakkında

Test eşleme, Gerrit tabanlı bir yaklaşımdır ve geliştiricilerin önceden ve gönderme sonrası test kurallarını doğrudan Android kaynak ağacında şube ve cihazlarla ilgili kararları test etmek için kullanırlar. Test eşleme tanımları, TEST_MAPPING isimli JSON dosyalarıdır, yer alır.

Atest, TEST_MAPPING dosyalarını kullanarak ilişkilendirilmiş dizinler. Test eşleme ile aynı test grubunu Android kaynak ağacında çok küçük bir değişiklikle birlikte gönderme öncesi kontrolleri.

Aşağıdaki örneklere bakın:

• Şunun için TEST_MAPPING bölümüne gönderme öncesi testleri ekleyin: services.core

• tools/dexter için TEST_MAPPING uygulamasına gönderme öncesi testleri eklemek için şunu kullanın: içe aktarmalar

Test eşleme Ticari Federasyon (TF) test bandı ve sonuçların raporlanmasını içerir.

Test gruplarını tanımlayın

Eşleme grubu testlerini bir test grubuyla test edin. Bir test grubunun adı şöyle olabilir: tüm dizeler için geçerlidir. Örneğin, presubmit (gönderme öncesi) terimi, çalıştırmanız gerekir. postsubmit de değişiklikler birleştirildikten sonra derlemeler

Paket derleme komut dosyası kuralları

Ticaret Federasyonu test cihazı test modüllerini çalıştırabilmeniz için bu modüllerin Soong veya LOCAL_COMPATIBILITY_SUITE seti için test_suites ayarlandı Marka için aşağıdaki iki paketten birine dokunun:

• general-tests, cihaza özgü olmayan testler içindir özellikleri (ör. çoğu cihazda bulunmayan, satıcıya özgü donanım dikkat edin. Şunu bile olsa çoğu test general-tests paketinde olmalıdır: belirli bir ABI'ya veya bit hızına ya da HWASan gibi donanım özelliklerine her ABI için ayrı bir test_suites hedefi) ayarlamalıdır ve elde edersiniz.
• device-tests, cihaza özgü özelliklere bağlı testler içindir. Genellikle bu testler vendor/ altında bulunur. Cihaza özel Yalnızca bir cihaza özgü özellikleri belirtir. Dolayısıyla bu, ve GTest testlerine (genellikle general-tests (ABI'ye özel olsalar bile).

Örnekler:

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

Testleri bir test paketinde çalıştırılacak şekilde yapılandırma

Test paketi içinde bir testin çalıştırılması için test:

• Derleme sağlayıcısı olmamalıdır.
• Tamamlandıktan sonra temizlenmelidir (örneğin, geçici mevcut tüm öğeleri silerek) dosyalar test sırasında oluşturulmuştu.
• Sistem ayarları, varsayılan veya orijinal değerle değiştirilmeli.

• Cihazın belirli bir durumda (ör. root hazır) olduğunu varsaymamalısınız. Çoğu testin çalışması için kök ayrıcalığı gerekmez. Bir testin, rootlanmışsa, bunu RootTargetPreparer ile belirtmelidir AndroidTest.xml, aşağıdaki örnekte olduğu gibi:

  <target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
  

Test eşleme dosyaları oluşturma

Test kapsamı gerektiren dizin için bir TEST_MAPPING JSON dosyası ekleyin. örneğe benzer. Bu kurallar, testlerin presubmit, söz konusu dizinde veya dizinde herhangi bir dosyaya dokunulup dokunmadığını kontrol eder. alt dizinleridir.

Bir örneği takip edin

Aşağıda örnek bir TEST_MAPPING dosyası verilmiştir (bu dosya JSON biçimindedir ancak yorumlara sahiptir). 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": "CtsDeqpTestCases",
      "options": [
        {
          // Use regex in include-filter which is supported in AndroidJUnitTest
          "include-filter": "dEQP-EGL.functional.color_clears.*"
        }
      ]
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

Özellikleri belirleyin

Örnekte, presubmit ve postsubmit her birinin adıdır test grubu. Daha fazla bilgi için Test gruplarını tanımlama bölümüne bakın. test gruplarıyla ilgili bilgi edineceksiniz.

Test modülünün veya Ticaret Federasyonu entegrasyon testinin adını ayarlayabilirsiniz name (örneğin, test XML dosyasının kaynak yolu, uiautomator/uiautomator-demo) name özelliğinin değerinde olur. name alanının name sınıfını veya name test yöntemini kullanın. Yapılacak testleri daraltmak için include-filter gibi seçenekleri kullanabilirsiniz. Görüntüleyin (include-filter örnek kullanımı).

Bir testin host ayarı, testin cihazsız test olup olmadığını gösterir çalışmadığından emin olun. Varsayılan değer false, yani testin değeri çalışması için cihaz gerekir. Desteklenen test türleri şunlardır: Şunun için HostGTest: JUnit için GTest ikili programları ve HostTest testler.

file_patterns özelliği, normal ifade dizelerinden oluşan bir liste ayarlamanıza olanak tanır. göreli yolunu eşleştirmek için ( TEST_MAPPING dosyasını içeren dizin). Örnekte, CtsWindowManagerDeviceTestCases testi yalnızca bir Java dosyası olduğunda ön gönderimde çalışıyor ile aynı dizinde bulunan Window veya Activity ile başlar TEST_MAPPING dosyası veya alt dizinlerinden herhangi biri değiştirilir. JSON dosyasında olduğu için, ters eğik çizgiler "`" kod dışına alınmalıdır.

imports özelliği, diğer TEST_MAPPING dosyalarına test eklemenize olanak tanır. en iyi yöntemin ne olduğunu öğreneceğiz. Üst öğedeki TEST_MAPPING dosyaları içe aktarılan yolun dizinleri de dahil edilir. Test eşleme iç içe aktarmalar; Bu, iki TEST_MAPPING dosyasının birbirini içe aktarabileceği ve test eşlemesi dahil edilen testleri birleştirebilirsiniz.

options özelliği, ek Tradefed komut satırı seçenekleri içerir.

Belirli bir testte mevcut seçeneklerin tam listesini almak için şu komutu çalıştırın:

tradefed.sh run commandAndExit [test_module] --help

Referans Tradefed'de opsiyon işleme başlıklı bölüme bakın.

Atest ile test çalıştırma

Gönderme öncesi test kurallarını yerel olarak yürütmek için:

1. TEST_MAPPING dosyasını içeren dizine gidin.

2. Şu komutu çalıştırın:

   atest
   

MevcutTEST_MAPPING ve üst dizinleri çalıştırılır. Atest, iki testi bulup çalıştırır için geçerli olacaktır (A ve B).

Bu, TEST_MAPPING aracında gönderme öncesi testleri çalıştırmanın en basit yoludur mevcut çalışma dizinindeki (CWD) ve üst dizindeki dosyaları içermelidir. Onayla CWD ve tüm üst öğelerindeki TEST_MAPPING dosyasını bulup kullanır dizin oluşturabilirsiniz.

Kaynak kodunu yapılandırın

Bu örnekte, TEST_MAPPING dosyalarını kaynak ağacı:

src
├── project_1
│   └── TEST_MAPPING
├── project_2
│   └── TEST_MAPPING
└── TEST_MAPPING

src/TEST_MAPPING içeriği:

{
  "presubmit": [
    {
      "name": "A"
    }
  ]
}

src/project_1/TEST_MAPPING içeriği:

{
  "presubmit": [
    {
      "name": "B"
    }
  ],
  "postsubmit": [
    {
      "name": "C"
    }
  ],
  "other_group": [
    {
      "name": "X"
    }
  ]}

src/project_2/TEST_MAPPING içeriği:

{
  "presubmit": [
    {
      "name": "D"
    }
  ],
  "import": [
    {
      "path": "src/project_1"
    }
  ]}

Hedef dizinleri belirtin

Şu dizindeki TEST_MAPPING dosyalarında test çalıştırmak üzere bir hedef dizin belirtebilirsiniz: dizin. Aşağıdaki komut iki test çalıştırır (A, B):

atest --test-mapping src/project_1

Gönderme sonrası test kurallarını çalıştır

Bu komutu, şurada tanımlanan gönderim sonrası test kurallarını çalıştırmak için de kullanabilirsiniz: src_path ürününde TEST_MAPPING (varsayılan olarak CWD kullanılır) ve bunun üst dizinleri:

atest [--test-mapping] [src_path]:postsubmit

Yalnızca cihaz gerektirmeyen testleri çalıştırma

Yalnızca şuna göre yapılandırılmış testleri çalıştırmak üzere Atest için --host seçeneğini kullanabilirsiniz hiçbir cihaz gerektirmeyen ana makineye uygulanır. Bu seçenek kullanılmadığında, Atest her iki testi de hem de ana makinede çalışan ve cihaz gerektirmeyenler. İlgili içeriği oluşturmak için kullanılan testler iki ayrı pakette yürütülür:

atest [--test-mapping] --host

Test gruplarını tanımlama

Atest komutunda test gruplarını belirtebilirsiniz. Aşağıdaki komut, içindeki dosyalarla ilgili tüm postsubmit testleri src/project_1 ve yalnızca bir test (C) içerir.

Alternatif olarak, gruptan bağımsız olarak tüm testleri çalıştırmak için :all kullanabilirsiniz. Aşağıdakiler komutu dört test çalıştırır (A, B, C, X):

atest --test-mapping src/project_1:all

Alt dizinleri dahil et

Varsayılan olarak, Atest ile TEST_MAPPING ürününde test çalıştırma işlemi yalnızca gönderim öncesinde çalıştırılır CWD'deki TEST_MAPPING dosyasında yapılandırılmış testleri (veya CWD'de) verilen dizin) ve üst dizinlerini içermelidir. Tüm testlerde TEST_MAPPING dosyalarını kullanarak dosya yüklemek istemiyorsanız --include-subdir seçeneğini kullanarak Atest'i bu testleri de içermeye zorlayın.

atest --include-subdir

--include-subdir seçeneği olmadan, Atest yalnızca A testini çalıştırır. Şununla --include-subdir seçeneğinde, Atest iki test çalıştırır (A, B).

Satır düzeyinde yorum desteklenir

TEST_MAPPING detayını geliştirmek için satır düzeyinde // biçiminde bir yorum ekleyebilirsiniz. dosyasını seçin. ATest ve Ticaret Federasyonu TEST_MAPPING öğesini yorum içermeyen geçerli bir JSON biçiminde ön işlemden geçirin. Saklamak için JSON dosyası temiz, yalnızca satır düzeyinde // biçiminde yorum desteklenir.

Örnek:

{
  // For presubmit test group.
  "presubmit": [
    {
      // Run test on module A.
      "name": "A"
    }
  ]
}