Gerçek Cihaz Test Stratejisi: Hangi Cihazlar, Kaç Tane?

Mobil ekibin CI'ı yeşil, tüm testler simülatörde geçiyor ama App Store yorumlarında "uygulama donuyor" şikayetleri artıyorsa sorun testlerinde değil, test ettiğin donanımda. Simülatör ve emülatör CPU/GPU'yu ana makinenin gücüyle taklit eder; gerçek cihazın termal kısılması, düşük RAM'i ve zayıf ağ anteni bu taklidin dışında kalır. Bu yazıda hangi cihazları alman gerektiğine karar verirken kullanacağın somut bir çerçeve var: kullanıcı verinden matris türetme, alt sınır cihazını seçme mantığı, kendi park mı bulut mu sorusu ve CI'da gerçek cihaz koşusunun süre bütçesi.

💡 Pro Tip: Cihaz matrisini "elimde ne var"a göre değil, Firebase/Play Console'daki kendi kullanıcı analitiğinin cihaz+OS dağılımına göre kur — aksi halde en çok şikayet gelen segmenti hiç test etmemiş olursun.

İçindekiler

• Simülatörün yakalayamadığı beş hata sınıfı
• Cihaz matrisini kullanıcı verinizden türetmek
• Kendi analitiğini kaynak olarak kullan
• Alt sınır cihazı seçmek: neden en önemli cihaz o
• Kendi cihaz parkı vs cihaz bulutu: hangisi hangi işe
• CI'da gerçek cihaz koşusu ve süre bütçesi
• Sürüm öncesi manuel duman testi listesi
• Cihaz parkını yıllık yenileme kuralı
• SSS
• Test için hangi cihazları almalıyım?
• Simülatör hangi hataları kaçırır?
• Cihaz bulutu mu kendi cihazlarım mı?
• Gradle Managed Devices hangi Android sürümlerini destekler?
• CI'da gerçek/managed cihaz testi ne kadar sürebilir?
• Güncelleme (Eylül 2026)
• Sonuç
• Kaynaklar

Simülatörün yakalayamadığı beş hata sınıfı

Simülatör/emülatör testleri mantık hatalarını mükemmel yakalar ama beş hata sınıfı sistematik olarak kaçar:

• Termal kısılma (thermal throttling): Masaüstünün soğutması cihazın küçük gövdesindeki gibi kısılmaz; 10 dakikalık kamera/AR oturumunda CPU frekansının düşmesiyle ortaya çıkan yavaşlama simülatörde hiç oluşmaz.
• Düşük RAM'de arka plana atılma: İşletim sistemi bellek baskısı altında uygulamanı öldürüp state'i sıfırlayabilir; bu davranış cihazın fiziksel RAM'ine bağlıdır, simülatörün ana makine RAM'ine değil.
• Zayıf/aralıklı ağ + gerçek anten: Simülatör ağ katmanını host makinenin bağlantısından geçirir; cihazın kendi Wi-Fi/hücresel anteninin zayıf sinyalde paket kaybı, yeniden bağlanma gecikmesi gibi davranışları taklit edilmez.
• Eski GPU sürücü/render tuhaflıkları: Metal/OpenGL/Vulkan'ın gerçek GPU'daki sürücü uyumsuzlukları (özellikle üç-dört yıllık orta segment cihazlarda) simülatörün masaüstü GPU'sunda görünmez.
• Donanım-render ekran görüntüsü testleri: Google'ın kendi belgelediği üzere Automated Test Device (ATD) donanım hızlandırmalı render gerektiren ekran görüntüsü (screenshot) testlerini desteklemez — bu sınıf test için gerçek veya "managed device" gerekir, ATD yeterli değildir.

Cihaz matrisini kullanıcı verinizden türetmek

Cihaz seçimi kişisel tercihle değil, gerçek dağılımla başlamalı. İki eksen var: OS sürümü ve cihaz segmenti.

OS sürümü tarafında pazar hâlâ ciddi parçalı: ne Android ne de iOS kullanıcı tabanı tek bir sürümde toplanmış değil — birden fazla majör sürüm aynı anda anlamlı pay taşıyor, hatta iOS'ta bile "herkes güncel sürümde" varsayımı geçerli değil. Bu tür yüzdeler hızla eskidiği için burada tarih etiketli somut bir tablo vermek yerine, bir sonraki bölümdeki üç adımlı yöntemle güncel dağılımı kendi analitiğinden türetmeni öneriyorum.

Kendi analitiğini kaynak olarak kullan

Play Console'un "Cihazlar" sekmesi ve Firebase Analytics'in cihaz modeli/OS boyutu, App Store Connect'in "Cihazlar" raporu — bunlar senin kullanıcı tabanının gerçek dağılımı. Matris kurarken sırayla:

1. Son 90 günün oturum sayısına göre cihaz modeli + OS sürümü çiftlerini sırala.
2. Kümülatif kapsamı %80'e getiren en küçük cihaz+OS listesini çıkar (uzun kuyruk genelde tek tek düşük paylı ama toplamda önemli).
3. Bu listeye, aşağıdaki bölümde anlatılan "alt sınır cihazı" her zaman elle ekle — analitikte az görünse bile.

Örnek bir 6 cihazlık başlangıç matrisi şöyle görünür (kendi analitiğinle değiştir):

Alt sınır cihazı seçmek: neden en önemli cihaz o

Matristeki altı cihazdan biri diğerlerinden daha çok bug yakalar: en düşük RAM'e ve en zayıf CPU'ya sahip olan. Nedeni basit — üst segment cihazlar senin kod hatalarını donanım gücüyle örter; alt sınır cihaz örtemez. Bellek baskısı altında arka plana atılma, GC duraklamaları, animasyon frame drop'ları, soğuk başlatma (cold start) süresi — hepsi alt sınır cihazda büyütülmüş halde görünür.

Pratik kural: alt sınır cihazı analitikte "en düşük paylı segment" diye eleme, tam tersi bilerek tut. Kendi tecrübeme göre bu cihazda geçen bir sürüm, ortadaki tüm segmentlerde de sorunsuz çalışır; ama tersi doğru değildir — sadece amiral gemisinde test edilmiş bir sürüm alt sınırda hiç açılmayabilir.

Alt sınır cihazı seçerken tek bir sayıya (örneğin sadece RAM'e) bakmak yeterli değil; birlikte değerlendirmen gereken üç boyut var: fiziksel RAM (arka plana atılma davranışını belirler), CPU çekirdek sayısı/frekansı (soğuk başlatma ve animasyon frame süresini belirler) ve depolama hızı (uygulama ilk kurulum + ilk açılış deneyimini belirler). Bu üç boyutta da en zayıf olan, kendi analitiğinde hâlâ anlamlı bir kullanıcı payı taşıyan cihaz — aradığın alt sınır odur. Tek boyuta indirgeme hatası, örneğin RAM'i düşük ama CPU'su güçlü bir cihazı seçip depolama kaynaklı ilk açılış sorunlarını hiç görmemene yol açabilir.

Kendi cihaz parkı vs cihaz bulutu: hangisi hangi işe

Fiyat modelleri sağlayıcıya ve koşu süresine göre değişir; burada rakam yerine karar çerçevesi var:

• Kendi park: Sabit donanım maliyeti + saklama/şarj/güncelleme bakımı var, ama CI kuyruğunda "cihaz meşgul" beklemesi yok ve tamamen izole ağ ortamı kurabilirsin (banking/ödeme testleri için önemli).
• Cihaz bulutu (Firebase Test Lab benzeri): Firebase'in kendi tanımıyla "bulut tabanlı uygulama test altyapısı" — geniş bir Android/iOS cihaz kataloğuna erişim + Arm host'lu hızlı sanal cihazlar sunar, CI sistemleriyle entegre çalışır. Yeni cihaz nesli çıktığında bakım senin üzerinde değil.
• Kritik sınır: Firebase Test Lab dokümantasyonu açıkça "arka uç yük testi için tasarlanmadı" diyor — yani bulut cihaz testini fonksiyonel/UI testi için düşün, performans/yük testi için değil.

Ben genelde ikisini birlikte tercih ederim: en sık koşan smoke/regresyon testlerini bulutta geniş matriste çalıştırır, alt sınır cihazın derin profiling'ini (Instruments/Android Studio Profiler) ise elde tuttuğum fiziksel cihazda yaparım.

Karar için niteliksel karşılaştırma:

CI'da gerçek cihaz koşusu ve süre bütçesi

Android tarafında Gradle Managed Devices, build.gradle içinde tanımladığın cihaz profillerini CI'da otomatik ayağa kaldırıp testi koşturur. Google'ın dokümantasyonuna göre bu özellik API seviyesi 27 ve üzeri cihaz profilleri gerektirir; Automated Test Device (ATD) profili ise yalnızca API 30'u destekler ve donanım hızlandırmalı render gerektiren ekran görüntüsü testlerini çalıştıramaz.

1// build.gradle.kts — managed device profili örneği
2android {
3    testOptions {
4        managedDevices {
5            localDevices {
6                create("altSinirCihaz") {
7                    device = "Pixel 6a"
8                    apiLevel = 30
9                    systemImageSource = "aosp-atd"
10                }
11            }
12        }
13    }
14}

Süre bütçesi kaynaktan doğrudan geliyor — bu ayarlar Firebase Test Lab cihazları için tanımlanan firebaseTestLab { testOptions { ... } } bloğunda geçerli: timeoutMinutes için varsayılan 15 dakika; fiziksel cihazlarda azami 45 dakika, sanal cihazlarda azami 60 dakika ayarlanabiliyor. Yeniden deneme (maxTestReruns) varsayılanı 0, azami 10. Akıllı paralel dağıtım (smart sharding) için targetedShardDurationMinutes değeri timeoutMinutes değerinden en az 5 dakika düşük tutulmalı — aksi halde shard, zaman aşımına takılmadan bitiremeyebilir.

Firebase Test Lab tarafında matris cihaz + OS sürümü + dil (locale) + yön (orientation) kombinasyonlarıyla kurulur ve CI sistemlerine entegre edilebilir:

1# Firebase Test Lab — cihaz+OS+locale+yön matrisiyle CI koşusu
2gcloud firebase test android run \
3  --type instrumentation \
4  --app app-debug.apk \
5  --test app-debug-androidTest.apk \
6  --device model=alt-sinir-cihaz,version=30,locale=tr_TR,orientation=portrait \
7  --device model=amiral-gemisi,version=34,locale=en_US,orientation=portrait \
8  --timeout 20m

(Buradaki model= değerleri örnektir; gerçek model kimliklerini gcloud firebase test android models list çıktısından al.)

iOS tarafında xcodebuild test komutu (veya Xcode'da Product > Test) koşuyu başlatır; Apple'ın dokümantasyonuna göre bu komut, oturum sonuçlarını, coverage'ı (etkinse) ve diğer logları içeren bir Xcode Test Results (.xcresults) paketi üretir; üst-düzey özeti Report Navigator'dan okuyabilirsin. Xcode Cloud ise bunun ötesinde zamanlanmış, daha geniş kapsamlı test koşularını otomatikleştiriyor:

1xcodebuild test \
2  -scheme "UygulamaUITests" \
3  -destination "platform=iOS,name=Alt Sinir Cihaz" \
4  -resultBundlePath ./ci-sonuc.xcresult

Sürüm öncesi manuel duman testi listesi

Otomatik matris ne kadar genişse genişsin, yayına almadan hemen önce alt sınır cihazda elle bakılması gereken bir liste bulunmalı — otomasyon flaky olduğunda veya CI'ın kaçırdığı görsel/hissi (feel) sorunları bu listede yakalanır:

• Soğuk başlatma süresi: uygulamayı tamamen kapatıp alt sınır cihazda ilk açılışı kronometreyle ölç.
• Arka plana atıp geri dönme: birkaç ağır uygulama açtıktan sonra senin uygulamana dön, state kaybı var mı bak.
• Zayıf sinyal simülasyonu: cihazı uçak moduna alıp tekrar ağa bağla, yeniden bağlanma davranışını izle.
• Klavye + döndürme: form ekranında klavye açıkken cihazı yatay/dikey çevir, layout kırılması ara.
• Bildirim + derin bağlantı (deep link): push bildirimine dokunarak uygulamayı soğuktan aç.
• Düşük pil modu: cihazın pil tasarrufu modunu açıp arka plan görevlerinin (senkron, bildirim) davranışını kontrol et.

Bu listeyi elle takip etmek yerine bir kontrol dosyasına dökmek işini kolaylaştırır:

1# smoke-checklist.sh — sürüm öncesi alt sınır cihaz kontrolü
2echo "1) Soğuk başlatma süresi (sn):"
3echo "2) Arka plandan dönüş state kaybı: [ ]"
4echo "3) Zayıf sinyal yeniden bağlanma: [ ]"
5echo "4) Klavye + döndürme layout: [ ]"
6echo "5) Push -> derin bağlantı soğuk açılış: [ ]"
7echo "6) Düşük pil modu arka plan görevi: [ ]"

Cihaz parkını yıllık yenileme kuralı

Pratik bir yaklaşım: cihaz parkını komple değiştirmek yerine yılda bir kez matrisi kullanıcı analitiğine göre yeniden hesapla ve yalnızca "artık payı analitikte anlamsız küçülmüş" cihazları çıkar, yerine güncel alt sınır segmentinden bir cihaz ekle. Amiral gemisi cihazı her yıl yenilemene gerek yok — üst segment zaten kod hatalarını örtüyor, esas değişmesi gereken alt sınır ve orta segment temsilcisidir.

Yenileme takvimini sürüm takvimine değil, analitik takvimine bağla: platformların yıllık büyük sürüm duyuruları (yeni Android major sürümü, yeni iOS major sürümü) çıktığında hemen cihaz değiştirme refleksine kapılma — önce yeni sürümün kendi kullanıcı tabanında ne kadar hızlı yayıldığına bak. Yukarıdaki bölümde gördüğün gibi iOS tarafında bile birden fazla majör sürüm aynı anda anlamlı pay taşıyabiliyor; yani "yeni sürüm çıktı, eski cihazı emekli et" kararı veri olmadan verilirse alt sınır kullanıcı kitlesini test dışında bırakma riski taşır.

SSS

Test için hangi cihazları almalıyım?

Rastgele bütçe/amiral gemisi seçimi yerine kendi kullanıcı analitiğinden (Play Console/Firebase/App Store Connect cihaz raporları) son 90 günün oturum sayısına göre cihaz+OS çiftlerini sırala ve kümülatif payı %80'e getiren en küçük listeyi çıkar; buna en düşük RAM'li aktif segmenti alt sınır cihaz olarak elle ekle.

Simülatör hangi hataları kaçırır?

Termal kısılma, düşük RAM'de arka plana atılma, zayıf/aralıklı ağ + gerçek anten davranışı, eski GPU sürücü render tuhaflıkları ve donanım hızlandırmalı render gerektiren ekran görüntüsü testleri — bu beş sınıf simülatörün taklit ettiği ana makine kaynaklarının dışında kalır.

Cihaz bulutu mu kendi cihazlarım mı?

İkisi farklı problemi çözer: cihaz bulutu (Firebase Test Lab gibi) geniş bir cihaz/OS/locale/yön matrisinde fonksiyonel testi ölçeklendirir ama kendi dokümantasyonunda "arka uç yük testi için tasarlanmadı" diye belirtiliyor; kendi park ise izole ağ ortamı ve elde tutulan derin profiling gerektiren senaryolarda daha uygun.

Gradle Managed Devices hangi Android sürümlerini destekler?

Google'ın dokümantasyonuna göre managed device profilleri API seviyesi 27 ve üzeri gerektirir; Automated Test Device (ATD) profili ise yalnızca API 30'u destekler ve donanım hızlandırmalı render gerektiren ekran görüntüsü testlerini çalıştıramaz.

CI'da gerçek/managed cihaz testi ne kadar sürebilir?

Firebase Test Lab cihazlarında timeoutMinutes varsayılanı 15 dakikadır; fiziksel cihazlarda azami 45 dakikaya, sanal cihazlarda azami 60 dakikaya kadar yükseltilebilir. Yeniden deneme sayısı (maxTestReruns) varsayılan 0, azami 10'dur.

Güncelleme (Eylül 2026)

Bu yazı 2025-03-26 tarihindeki araçlarla yazıldı; 18 aylık aradan sonra Android Emulator ve Xcode/iOS toolchain'inde somut değişiklikler var, Gradle Managed Devices ve Firebase Test Lab dokümanlarında ise API/limit tanımları aynı kaldı, yalnızca sayfa damgaları güncellendi:

• Gradle Managed Devices dokümanı 16 Ocak 2026 damgalı: API 27+ şartı, ATD'nin yalnız API 30 desteği ve donanım-render ekran görüntüsü sınırı değişmedi.
• Android Emulator 36.5.10 (2 Nisan 2026): Pixel 10, 10 Pro, 10 Pro XL ve 10 Pro Fold AVD profilleri eklendi; ayrıca sıfır-konfigürasyonlu çoklu-cihaz ağ yığını geldi.
• Android Emulator 36.6.11 (2 Haziran 2026): API 37'den itibaren telefon AVD'leri için minimum RAM 4 GB'a çıkarıldı — bu, emülatörün düşük-RAM davranışını simüle etmesini daha da zorlaştırıyor ve gerçek eski/ucuz cihazda test ihtiyacını azaltmıyor, tersine güçlendiriyor.
• Android Emulator 37.1.11 (30 Temmuz 2026): Pixel 10a AVD profili eklendi.
• Xcode 27, 14 Eylül 2026'da iOS 27 ile eşzamanlı yayımlandı — bu yazının orijinal sürümünden bu yana toolchain iki majör sürüm ilerledi.
• Pazar payı (StatCounter, Ağustos 2026): Android tarafında altı sürüm de en az %8 pay taşıyor, parçalanma azalmadı; iOS tarafında 26.6+26.5 birlikte yaklaşık %67'ye ulaşırken iOS 18.7 hâlâ %10,36 ile üçüncü sırada.

Sonuç

Gerçek cihaz test stratejisi tek bir "doğru cihaz listesi" değil, sürekli güncellenen bir süreçtir: kullanıcı analitiğinden matris türet, alt sınır cihazı bilerek matriste tut, CI'da managed device/bulut ile ölçekle, sürüm öncesi manuel duman testini alt sınır cihazda çalıştır. Test yazımının kendisini derinlemesine ele almak istersen iOS'ta TDD rehberine bakabilirsin; CI hattını Flutter tarafında kurmak için Flutter CI/CD (GitHub Actions + Fastlane) yazısı iyi bir başlangıç. Alt sınır cihazda karşına çıkacak bellek sorunlarını derinlemesine incelemek için iOS bellek yönetimi rehberine, uygulama boyutunu küçültüp indirme/kurulum sürtünmesini azaltmak için iOS uygulama boyutu optimizasyonu yazısına göz atabilirsin. Cihaz matrisini kararlarını istatistiksel olarak da desteklemek istersen mobil A/B test altyapısı yazısı faydalı olur; çevrimdışı senaryoları test matrisine eklerken de Flutter offline-first veritabanı rehberi yol gösterici.

Kaynaklar

• Gradle Managed Devices — Android Developers — API seviyesi, ATD sınırları, timeout/rerun/sharding ayarları.
• Running Tests and Interpreting Results — Apple Developer — Report Navigator özeti, .xcresults paketi, Xcode Cloud.
• Test Lab — Firebase — bulut cihaz matrisi, CI entegrasyonu, yük testi sınırı.
• Android Version Market Share — StatCounter — Ağustos 2026 Android sürüm dağılımı.
• iOS Version Market Share — StatCounter — Ağustos 2026 iOS sürüm dağılımı.
• Android Studio Emulator Release Notes — AVD profil eklemeleri ve RAM/ağ değişiklikleri.
• Apple Newsroom — Releases — Xcode 27 ve iOS 27 yayın tarihi.