Test eşleme

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, geliştiricilerin yayın öncesi öğeler oluşturmalarına olanak tanıyan Gerrit tabanlı bir yaklaşımdır. ve yayın 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ı, herhangi bir kaynak dizine yerleştirebileceğiniz TEST_MAPPING adlı JSON dosyalarıdır.

Atest, ilişkili dizinlerde göndermeden önce testleri çalıştırmak için TEST_MAPPING dosyalarını kullanabilir. Test eşleştirme sayesinde, Android kaynak ağacında minimum düzeyde değişiklik yaparak aynı test grubunu göndermeden önce yapılan kontrollere ekleyebilirsiniz.

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

Test eşleme, test yürütme ve sonuç raporlama için Trade Federation (TF) test donanımından yararlanır.

Test gruplarını tanımlayın

Grup eşleme testlerini test grubuyla test edin. Bir test grubunun adı şöyle olabilir: tüm dizeler için geçerlidir. Örneğin, ön gönderme, değişiklikler doğrulanırken çalıştırılacak bir test grubunun adı olabilir. Gönderimden sonra, değişiklikler birleştirildikten sonra derlemeleri doğrulamak için kullanılan testler olabilir.

Paket oluşturma komut dosyası kuralları

Trade Federation test donanımının belirli bir derleme için test modüllerini çalıştırabilmesi için bu modüllerde Soong için bir test_suites veya Make için bu iki paketten birine ait bir LOCAL_COMPATIBILITY_SUITE ayarının olması gerekir:

  • general-tests, cihaza özgü olmayan testler içindir özellikleri (ör. çoğu cihazda bulunmayan, satıcıya özgü donanım dikkat edin. Bir ABI'ye, bit sayısına veya HWASan gibi donanım özelliklerine özel olsalar bile (her ABI için ayrı bir test_suites hedefi vardır) ve bir cihazda çalıştırılmaları gerekse bile çoğu test general-tests paketinde olmalıdır.
  • device-tests, cihaza özgü özelliklere bağlı testler içindir. Genellikle bu testler vendor/ altında bulunur. Cihaza özel, yalnızca bir cihaza özgü olan özellikleri ifade eder. Bu nedenle, JUnit testlerinin yanı sıra GTest testleri (ABI'ye özel olsalar bile genellikle general-tests olarak işaretlenmelidir) için de geçerlidir.

Ö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 testin test paketinde çalışabilmesi için:

  • 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ğere değiştirilmelidir.

  • Cihazın belirli bir durumda (ör. root hazır) olduğunu varsaymamalısınız. Çoğu testin çalıştırılması için root 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 adını veya Trade Federation entegrasyon testi adını (test XML dosyasının kaynak yolu, örneğin uiautomator/uiautomator-demo) name özelliğinin değerine ayarlayabilirsiniz. name alanının name sınıfını veya name test yöntemini kullanamayacağını unutmayın. Çalıştırılacağı testleri daraltmak için include-filter gibi seçenekleri kullanın. Görüntüleyin include-filter örnek kullanımı.

Bir testin host ayarı, testin ana makinede çalışan cihazsız bir test olup olmadığını belirtir. Varsayılan değer false'tür. Bu, testin çalıştırılması için bir cihaz gerektiği anlamına gelir. Desteklenen test türleri GTest ikili dosyaları için HostGTest ve JUnit testleri için HostTest'tir.

file_patterns özelliği, herhangi bir kaynak kod dosyasının göreli yolunu (TEST_MAPPING dosyasını içeren dizine göre) eşleştirmek için normal ifade dizelerinin bir listesini ayarlamanıza olanak tanır. Ö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. 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. İçe aktarılan yolun üst dizinlerindeki TEST_MAPPING dosyaları da dahildir. 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 test için kullanılabilen seçeneklerin tam listesini almak üzere ş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. Aşağıdaki komutu çalıştırın:

    atest

Mevcut dizinin ve üst dizinlerinin TEST_MAPPING dosyalarında yapılandırılan tüm göndermeden önce testleri çalıştırılır. Atest, göndermeden önce iki test (A ve B) bulup çalıştırır.

Bu, geçerli çalışma dizinindeki (CWD) ve üst dizinlerdeki TEST_MAPPINGdosyalarda göndermeden önce test çalıştırmanın en basit yoludur. Atest, CWD'deki ve tüm üst dizinlerindeki TEST_MAPPING dosyasını bulup kullanır.

Kaynak kodunu yapılandırın

Bu örnekte, kaynak ağacında TEST_MAPPING dosyalarını nasıl yapılandırabileceğiniz gösterilmektedir:

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

Belirli bir dizindeki TEST_MAPPING dosyalarında test çalıştırmak için hedef bir dizin belirtebilirsiniz. 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

TEST_MAPPING'te tanımlanan gönderim sonrası test kurallarını src_path (varsayılan olarak CWD) ve üst dizinlerinde çalıştırmak için de bu komutu kullanabilirsiniz:

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

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

Yalnızca yapılandırılmış testleri çalıştırmak üzere Atest için --host seçeneğini kullanabilirsiniz karşılaştırılması gerekir. Bu seçenek olmazsa Atest, gerektiren testler, cihaz gerektiren testler ve herhangi bir uygulama olanak tanır. Testler iki ayrı pakette çalıştırı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.

Dilerseniz gruptan bağımsız olarak tüm testleri çalıştırmak için :all simgesini de 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"
    }
  ]
}