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, ilişkili dizinlerde göndermeden önce testleri çalıştırmak için TEST_MAPPING dosyalarını kullanabilir. 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

• İçe aktarma işlemlerini kullanarak tools/dexter için TEST_MAPPING'e göndermeden önce test ekleme

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ü özelliklere (ör. çoğu cihazda bulunmayan tedarikçiye özgü donanım) bağlı olmayan testler içindir. Ş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 bir kontrol panelidir.
• 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 root gerektirmesi gerekiyorsa bunu AndroidTest.xml içinde RootTargetPreparer ile belirtmelidir. Aşağıdaki örnekte gösterildiği 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 ayarlama

Örnekte, presubmit ve postsubmit her birinin adıdır test grubu. Test grupları hakkında daha fazla bilgi için Test grupları tanımlama başlıklı makaleyi inceleyin.

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, TEST_MAPPING dosyasıyla veya alt dizinlerinden biriyle aynı dizinde bulunan ve Window veya Activity ile başlayan bir Java dosyası değiştirildiğinde CtsWindowManagerDeviceTestCases testi göndermeden önce çalıştırılır. JSON dosyasındaki ters eğik çizgiler `` için kaçış karakteri kullanılmalı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 yapma

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. Atest, CWD'deki ve tüm üst dizinlerindeki TEST_MAPPING dosyasını bulup kullanır.

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 edin

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"
    }
  ]
}