Geliştirici Tarafından Güçlendirilmiş CTS

Bu sayfada, geliştirici destekli CTS'nin (CTS-D) kullanım yönergeleri açıklanmaktadır.

Test kapsamı

CTS-D, CTS ve CTS Verifier gibi yalnızca aşağıdakileri zorunlu kılabilir:

  • Belirli bir API düzeyi için geliştirici SDK'sında (developer.android.com) açıklanan tüm herkese açık API'ler.
  • Belirli bir API düzeyi için Android Uyumluluk Tanımı Belgesi'nde (CDD) yer alan tüm ZORUNLU (MUST) koşullar.

KESİNLİKLE GEREKLİ OLMAYAN (STRONGLY RECOMMENDED), GEREKLİ (SHOULD), OLABİLİR (MAY) gibi şartlar isteğe bağlıdır ve CTS kullanılarak test edilemez.

Tüm API'ler ve CDD koşulları belirli bir API düzeyine bağlı olduğundan tüm CTS testleri (CTS, CTS-D ve CTS Doğrulayıcı), ilişkili API'leri veya koşullarıyla aynı API düzeyine bağlıdır. Belirli bir API kullanımdan kaldırılırsa veya değiştirilirse ilgili testi de kullanımdan kaldırmanız ya da güncellemeniz gerekir.

CTS testi oluşturma kuralları

  • Bir test, aynı hedef sonucu tutarlı bir şekilde vermelidir.
  • Bir test, cihazı kutudan çıkarıp bir kez test ederek cihazın testi geçip geçmediğini belirlemelidir.
  • Testi oluşturanlar, test sonuçlarını etkileyebilecek tüm olası faktörleri kaldırmalıdır.
  • Bir cihazın belirli bir donanım koşuluna/ortama/kuruluma ihtiyacı varsa bu kurulum, commit mesajında net bir şekilde tanımlanmalıdır. Örneğin kurulum talimatları için CTS'yi ayarlama başlıklı makaleyi inceleyin.
  • Test, tek seferde 6 saatten uzun sürmemelidir. Daha uzun süre çalışması gerekiyorsa lütfen inceleyebilmemiz için test önerinize gerekçeyi ekleyin.

Aşağıda, bir uygulama kısıtlamasını test etmek için örnek bir test koşulları grubu verilmiştir:

  • Kablosuz bağlantı kararlı olmalıdır (kablosuz bağlantıya dayalı bir test için).
  • Cihaz, test sırasında sabit kalır (veya teste bağlı olarak sabit kalmaz).
  • Cihaz, pil seviyesi X iken herhangi bir güç kaynağından çıkarıldı.
  • CTS dışında hiçbir uygulama, ön plan hizmeti veya arka plan hizmeti çalışmıyor.
  • CTS çalışırken ekran kapalıdır.
  • Cihaz isLowRamDevice değil.
  • Pil tasarrufu / uygulama kısıtlamaları, "kullanıma hazır" durumundan değiştirilmemiştir.

Test uygunluğu

Mevcut CTS, CTS Verifier veya CTS-D testleri tarafından test edilmeyen bir davranışı zorunlu kılan yeni testleri kabul ederiz. Test kapsamımızın dışındaki bir davranışı kontrol eden tüm testler reddedilir.

CTS gönderim süreci

  1. Test önerisi yazma: Bir uygulama geliştirici, Google Sorun İzleyici'yi kullanarak bir test önerisi gönderir. Bu öneride, belirlenen sorun açıklanır ve sorunun kontrol edilmesi için bir test önerilir. Teklif, ilişkili CDD koşulu kimliğini içermelidir. Android ekibi öneriyi inceler.
  2. CTS testi geliştirme: Bir öneri onaylandıktan sonra göndereni, Android'in en son sürüm dalında (android16-release) AOSP'de bir CTS testi oluşturur. Android ekibi kodu inceler ve kabul edilirse değişikliği seçerek dahili geliştirme dalıyla birleştirir. Ayrıntılı bilgi için AOSP'de değişiklik önermek için nereyi kullanmalıyım? başlıklı makaleyi inceleyin.

CTS-D test yazma yönergeleri

  • Java Code Style Guide'ı (Java Kod Stili Rehberi) uygulayın.
  • CTS Geliştirme başlıklı makalede açıklanan tüm adımları uygulayın.
  • Testlerinizi uygun test planına ekleyin:
    • Yeni testlerinizi CTS-D test planına eklemek için include-filters simgesini kullanın: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml.
    • Yeni testlerinizi ana CTS test planından hariç tutmak için exclude-filters kullanın: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
  • build_error.log içindeki tüm errorprone uyarılarını ve önerilerini ele alın.
  • Değişikliklerinizi head'ya yeniden temellendirin. cts-developer.xml ve cts-developer-exclude.xml test planları bu kapsamdadır.
  • Test senaryonuzun mevcut bir CTS modülüne dahil edilip edilemeyeceğini belirlemek için Google mühendislik temsilcinizle birlikte çalışın. Bu mümkün değilse yeni bir modül oluşturmanıza yardımcı olurlar.
  • Oluşturulan her yeni test modülü için yeni test modülü dizininde bir OWNERS dosyası oluşturun.
    • OWNERS dosyanız, birlikte çalıştığınız Google test sahibinden alınan aşağıdaki bilgileri içermelidir:
    • # Bug component: xxx
    • Google test sahibi ldap
  • AndroidTest.xml bölümünde aşağıdaki parametreleri belirtin. Örnekler için örnek dosyalara (1, 2) bakın:
    • Instant_app veya not_instant_app
    • secondary_user veya not_secondary_user
    • all_foldable_states veya no_foldable_states
  • Doğru minSDK'yı belirtmek için <uses-sdk> dokümanlarına bakın.
  • Yeni test yöntemlerini, sınıflarını veya modüllerini kontrol ederken bunları CTS-D test planına ekleyin ve yeni testlerde olduğu gibi ana CTS test planından hariç tutun.

CTS-D testinizi çalıştırma

run cts --plan cts-developer kullanarak CTS-D test planını komut satırından çalıştırın.

Belirli bir test senaryosunu çalıştırmak için run cts --include-filter "test_module_name test_name" kullanın.

CTS'nin tamamını çalıştırma hakkında bilgi edinmek için CTS testlerini çalıştırma başlıklı makaleyi inceleyin.

Kabul ve yayınlama

Test isteği gönderildikten sonra dahili bir ekip, isteği inceleyerek bir CDD koşulunu veya belgelenmiş bir API davranışını test ettiğinden emin olur. Testin geçerli bir koşul veya davranış kontrolü yaptığı belirlenirse ekip, bu test senaryosunu daha ayrıntılı inceleme için bir Google mühendisine iletir. Google mühendisi, testin CTS'ye kabul edilebilmesi için nasıl iyileştirilebileceğine dair geri bildirimde bulunmak üzere sizinle iletişime geçecektir.

CTS yayın planıyla ilgili ayrıntılar için Yayın planı ve dal bilgileri başlıklı makaleyi inceleyin.