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

Bu sayfada, geliştirici destekli CTS'nin (CTS-D) kullanım kuralları özetlenmektedir.

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ımlama Belgesi'nde (CDD) yer alan tüm ZORUNLU gereksinimler.

KESİNLİKLE GEREKLİ OLMAYAN (STRONGLY RECOMMENDED), GEREKLİ (SHOULD), OLABİLİR (MAY) gibi koşullar 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 Verifier) 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şulu/ortam/kurulum gerektirmesi durumunda bu kurulum, commit mesajında net bir şekilde tanımlanmalıdır. Örnek kurulum talimatları için CTS'yi ayarlama başlıklı makaleyi inceleyin.
  • Test, tek seferde altı saatten uzun sürmemelidir. Daha uzun süre çalışması gerekiyorsa inceleyebilmemiz için lütfen gerekçeyi test önerinize 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 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 ve uygulama kısıtlamaları, kutudan çıktığı durumdan 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ışında kalan bir davranışı kontrol eden tüm testler reddedilir.

CTS gönderim süreci

  1. Test önerisi yazma: Bir uygulama geliştirici, Google Issue Tracker'ı kullanarak bir test önerisi gönderir. Bu öneride, tespit edilen 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önderen, Android'in en son sürüm dalında (android17-release) AOSP'de bir CTS testi oluşturur. Android ekibi kodu inceler ve kabul edilirse değişikliği seçip dahili geliştirme dalıyla birleştirir. Ayrıntılı bilgi için AOSP'de hangi değişiklikleri önermeliyim? 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ı buna dahildir.
  • 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 owner 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> belgelerine bakın.
  • Yeni test yöntemleri, sınıflar veya modüller eklerken 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, bir dahili ekip isteği inceleyerek bir CDD şartını veya belgelenmiş bir API davranışını test ettiğinden emin olur. Testin geçerli bir şartı veya davranışı kontrol ettiği belirlenirse ekip, bu test senaryosunu daha ayrıntılı inceleme için bir Google mühendisine iletir. Google mühendisi, CTS'ye kabul edilmeden önce testin nasıl iyileştirilebileceğiyle ilgili geri bildirimde bulunmak için sizinle iletişime geçer.

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