Fiziksel cihaz olmadan AI mobil uygulama testi nasıl çalışır?

Fiziksel cihaz olmadan AI mobil uygulama testi, CI hattınızın içinde Android emülatörlerine ve iOS simülatörlerine karşı çalışan bir AI test ajanı ile çalışır: ajan uygulamayı analiz eder, arayüz ve regresyon testleri üretir, her çalıştırmada temiz bir emülatörde bunları çalıştırır, bozulan bulucuları (locator) onarır, arayüz sapmasını işaretler ve her pull request'te bir rapor yayımlar. Çoğu ekip için bu, cihaz laboratuvarı ve bulut cihaz çiftliği çalıştırmalarının büyük kısmını, bunların kuyruklanması, kararsızlığı (flakiness) ve betik bakımıyla birlikte ortadan kaldırır. Donanım, OEM ve performans kontrolleri için küçük bir gerçek cihaz duman (smoke) paketi tutun ve geri kalan her şeyi yerel emülatörlerdeki ajana bırakın.

Cihaz laboratuvarları ve bulut cihaz çiftlikleri ekipleri neden yavaşlatır

Fiziksel bir cihaz laboratuvarı, USB hub'ları üzerinde bir raf dolusu telefon artı bunları ayakta tutan insanlardır: işletim sistemi güncellemeleri, her yeniden başlatmadan sonra geliştirici modu, provizyon profilleri, piller ve kablolar. Bunların hiçbiri test işi değildir, ama yükü mobil ekip taşır.

Bulut cihaz çiftlikleri donanımı ofisinizden çıkarır ama kısıtlamaları çıkarmaz. 2026 itibarıyla erişim tipik olarak cihaz-dakikası veya eşzamanlı cihaz yuvası başına fiyatlandırılır; bu yüzden hızlı geri bildirim için ihtiyaç duyduğunuz tek şey olan paralellik, faturayı katlayan şeydir; güncel fiyatlandırmayı satıcınızla doğrulayın. Popüler modeller yoğun saatlerde kuyruğa girer, bu yüzden on dakikalık bir paket çok daha uzun bekleyebilir.

Kararsızlık (flakiness) gizli vergidir: uzak bir cihaz yeniden başlar, bir sistem iletişim kutusu belirir, önceki kiracı bir durum bırakır ya da oturum düşer. Mühendisler yeniden çalıştırmayı, ardından görmezden gelmeyi öğrenir ve paket bir birleştirme (merge) kapısı olarak otoritesini kaybeder.

Bakım son maliyettir: tam kaynak kimliklerine bağlı paketler bir tasarımcı bir düğmeyi her taşıdığında bozulur ve bulucuları (locator) düzeltmek otomasyon işinin en büyük kalemi haline gelir.

Mobil testin pahalı kısmı telefonlar değildir. Onların etrafını saran kuyruklama, kararsızlık ve betik bakımıdır.

AI test ajanları fiziksel cihaz olmadan nasıl çalışır

Bir AI test ajanı; ekranları okuyan bir modeli (bir görsel-dil modeli artı erişilebilirlik ağacı), niyeti adımlara dönüştüren bir planlayıcıyı ve bunları adb ve Android emülatörü veya iOS Simülatöründe simctl ve XCTest üzerinden yürüten bir sürücüyü birleştirir. Altı aşamada çalışır.

1. Uygulama analizi

Ajan, bir hata ayıklama APK'sı veya bir simülatör .app paketi olan derleme çıktısından başlar. Statik analiz manifesti veya Info.plist'i, ekranları, derin bağlantıları ve izinleri okur; dinamik analiz derlemeyi bir emülatöre kurar ve onu tarayarak erişilebilirlik hiyerarşisini, bir ekran görüntüsünü ve her geçişi bir ekran grafiğine kaydeder.

2. Arayüz ve regresyon akışları için test üretimi

Girdiler kullanıcı hikayeleri, kabul kriterleri, mevcut test senaryoları ve ekran grafiğidir. Arayüz testleri tek ekranları hedefler: form doğrulama, hata ve boş durumlar, döndürme, karanlık mod. Regresyon akışları, ekranları kayıt olma, ödeme veya şifre sıfırlama gibi yolculuklara zincirler. İyi ajanlar, deponuzda yaşayan okunabilir Espresso veya XCUITest kodu ya da Appium betikleri üretir; tescilli bir kara kutu formatı paketinizi tek bir satıcıya kilitler.

3. Android emülatörlerinde ve iOS simülatörlerinde çalıştırma

Android emülatörü, donanım hızlandırmasıyla (Linux'ta KVM, macOS'ta Hypervisor.framework) tam bir sistem imajını önyükler ve -no-window ile başsız (headless) çalışır. iOS Simülatörü yalnızca Xcode ile macOS'ta çalışır, bu yüzden iOS işleri bir Mac runner'a ihtiyaç duyar. Ajan, genellikle bir anlık görüntüden (snapshot), çalıştırma başına temiz bir örnek önyükler, uygulamayı kurar, veri tohumlar ve her eylemden sonra erişilebilirlik ağacını ve bir ekran görüntüsünü gözlemleyerek her adımı yürütür.

4. Kendi kendini onaran bulucular (self-healing locators)

Bir eleman tanımlayıcısı değiştiğinde, betiklenmiş bir test basitçe başarısız olur. Bir ajan, elemanı görünür metne, role, hiyerarşi konumuna, komşularına ve son onaylanmış ekran görüntüsüne görsel benzerliğe göre yeniden çözer, çalıştırmaya devam eder ve bulucu güncellemesini incelenmek üzere bir diff olarak önerir.

5. Arayüz sapması (UI-drift) tespiti

Her çalıştırma, her ekranı onaylanmış referansıyla karşılaştırır: hiyerarşi, metin ve bir toleransla piksel farkı. Ajan, yeni bir referans olarak onayladığınız kasıtlı yeniden tasarımı; yerelleştirme sonrası kısaltılmış dizeler veya çakışan elemanlar gibi regresyonlardan ayırır ve her onaylama geçse bile sapmayı raporlar.

6. Raporlama

Her adım bir ekran görüntüsü, bir hiyerarşi dökümü, cihaz kayıtları (logcat, os_log) ve zamanlama saklar. Çıktı, CI için JUnit XML, insanlar için bir HTML raporu ve isteğe bağlı video ile, başarısızlıkta sade bir dille teşhistir.

Örnek: Nanobase AI'ın AI Mobil Test Lab'ı

Nanobase AI'ın AI Mobil Test Lab'ı bu deseni uygular: yapay zeka ajanları, fiziksel cihaz olmadan yerel emülatör ve simülatörlerde Android ve iOS testlerini üretir, çalıştırır ve doğrular. Üretilen testler XCUITest ve Espresso uyumlu kod olarak dışa aktarılır, laboratuvar GitHub Actions, GitLab CI ve Jenkins ile entegre olur ve /demo adresinde canlı bir demo bulunur.

Bir AI test ajanı daha akıllı bir betik kaydedicisi değildir. Tek kullanımlık emülatör örnekleri üzerinde gözlemleme, karar verme, eyleme geçme ve doğrulamadan oluşan bir döngüdür; hattınızın zaten anladığı formatlarda rapor verir.

Manuel QA ile betikli otomasyon, cihaz çiftlikleri ve AI ajanları karşılaştırması

Manuel QA hâlâ kimsenin betiklemediği şeyleri bulur ve cihaz çiftlikleri geniş bir donanım matrisi için tek seçenek olmaya devam eder; yerel emülatörlerdeki AI ajanları ise geri bildirim hızının ve bakım maliyetinin baskın olduğu yerde, yani günlük pull request döngüsünde kazanır.

Pull request döngüsü için yerel emülatörlerdeki AI ajanlarını, bunların kalıcı çıktısı olarak betikli testleri, donanım kontrolleri için küçük bir gerçek cihaz matrisini ve keşif için manuel QA'yı kullanın.

CI/CD entegrasyon deseni

Desen GitHub Actions, GitLab CI ve Jenkins'te aynıdır: uygulamayı derle, bir emülatör veya simülatör önyükle, kontrolü ajana devret, raporları topla.

1. Her pull request'te ve main'e birleştirmede tetikleyin; daha geniş bir gece çalıştırması planlayın.
2. Hata ayıklama ve androidTest APK'lerini, iOS için de bir simülatör .app derlemesini oluşturun.
3. Bir Linux runner'da KVM ile başsız bir emülatörü ya da bir macOS runner'da bir anlık görüntüden xcrun simctl boot ile bir simülatörü önyükleyin.
4. Derlemeyi kurun, uygulama verisini sıfırlayın, onu staging veya sahte bir sunucuya yönlendirin ve test verilerini (fixture) tohumlayın.
5. Ajanı çalıştırın: önce kayıtlı regresyon paketi, ardından değişiklikten etkilenen ekranlar için yeni testler.
6. JUnit XML'i ve yapıtları yayımlayın, onarılmış bulucu önerilerini ve sapma bulgularını inceleme yorumları olarak gönderin.
7. Birleştirmeyi yalnızca kritik akışlara göre kapılayın; kararsızlık geçmişi olan testleri karantinaya alın.

Android için minimal bir GitHub Actions işi şöyle görünür; ajan komutunu kendi aracınızın CLI'ıyla değiştirin.

name: mobile-ui-tests
on: [pull_request]
jobs:
  android-ai-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build debug and test APKs
        run: ./gradlew assembleDebug assembleDebugAndroidTest
      - name: Boot headless emulator
        run: |
          echo "y" | sdkmanager "system-images;android-35;google_apis;x86_64"
          avdmanager create avd -n ci -k "system-images;android-35;google_apis;x86_64" --force
          emulator -avd ci -no-window -no-audio -no-boot-anim -gpu swiftshader_indirect &
          adb wait-for-device shell 'while [ "$(getprop sys.boot_completed)" != "1" ]; do sleep 2; done'
      - name: Run AI test agent
        run: ai-test-agent run --platform android --app app/build/outputs/apk/debug/app-debug.apk --suite regression --report junit
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: android-test-report
          path: reports/

iOS işi, bir iOS Simulator hedefine karşı xcodebuild build-for-testing ile bir macos runner'da bunu yansıtır; GitHub Actions dokümantasyonu runner ayrıntılarını kapsar. Ekran görüntüleri müşteri verisi içeriyorsa, modelleri şirket içi LLM dağıtım rehberinde açıklandığı gibi kendi GPU'larınızda özel olarak çalıştırın.

Ajanı, "emülatör önyüklendi" ile "raporlar yayımlandı" arasında tek bir hat aşaması olarak ele alın ve birleştirme kapısını insanların güveneceği kadar dar tutun.

Neyi ölçmeli: kapsama, kararsızlık oranı ve geri bildirim süresi

Üç metrik, programın işe yarayıp yaramadığını gösterir; hepsi ajanın kendi raporlarından gelir.

Destekleyici metrikler olarak bir testi onarmak için ortalama süreyi ve kaçırılan hata oranını ekleyin ve eğilimlerin görünür olması için sürüm başına raporlayın.

İlk iki ayda hem kararsızlık oranı hem de geri bildirim süresi düşmüyorsa, ajan daha yavaş bir betik kaydedicisi olarak kullanılıyor demektir ve kuruluma dikkat gerekir.

Gerçek cihazların hâlâ gerekli olduğu yerler ve diğer sınırlamalar

2026 itibarıyla iki sınırlama kategorisi devam ediyor.

Emülatörlerin ve simülatörlerin yetersiz kaldığı yerler

• Sadık bir sanal karşılığı olmayan donanım: kamera hatları, NFC, Bluetooth LE çevre birimleri, hücresel modemler, biyometrik sensörler.
• Performans, termal kısıtlama, bellek baskısı ve pil tüketimi; bunlar yalnızca gerçek donanımda bir anlam ifade eder.
• OEM Android çeşitleri: üretici arayüzleri (skin), agresif arka plan süreç öldürme ve satıcıya özgü hatalar.
• GPU davranışı ve APNs ile FCM üzerinden uçtan uca push teslimi; simüle edilmiş bir push, işlemeyi kanıtlar, teslimi değil.

Pratik cevap hibrittir: her pull request'te emülatörlerdeki ajan, artı gece veya sürüm öncesi çalıştırılan, kurum içinde veya bir çiftlik üzerinden birkaç temsili gerçek telefon.

AI ajanının kendi sınırları

• Üretilen testler yanlış şeyi doğrulayabilir; her akışın ilk üretimini bir yüklenicinin kodu gibi inceleyin.
• Üretim deterministik değildir; üretilen testleri commit edin ve yeniden üretmeyi bilinçli yapın, her çalıştırmada değil.
• Kendi kendini onarma bir regresyonu maskeleyebilir; örneğin ekran dışına itilmiş ama metinle bulunan bir düğme gibi; onarılmış bulucular için inceleme zorunlu tutun.
• Flutter, Unity veya canvas görünümlerinde özel işlenen arayüzler ince bir erişilebilirlik ağacı sunar, bu yüzden güvenilirlik düşer.
• Ekran görüntüleri ve kayıtlar kişisel veri içerebilir; AB Yapay Zeka Yasası, GDPR ve KVKK kontrol listesi, bunlar çevrenizden çıkmadan önce nelere karar verileceğini kapsar.

Emülatörler artı bir AI ajanı, mobil testin maliyetinin çoğunu ortadan kaldırır; sürüm öncesi kısa, bilinçli bir gerçek cihaz geçişine olan ihtiyacı ortadan kaldırmaz.

Sık sorulan sorular

AI test ajanları mobil uygulama testinde fiziksel cihazların tamamen yerini alabilir mi?

Hayır, ve buna ihtiyaçları da yok. Android emülatörlerindeki ve iOS simülatörlerindeki AI ajanları, maliyetin ve gecikmenin eskiden oturduğu yer olan her pull request'te arayüz ve regresyon testlerinin büyük çoğunluğunu çalıştırabilir. Kamera, NFC, Bluetooth, termal kısıtlama ve OEM'e özgü Android tuhaflıkları gibi donanıma bağlı davranışlar sürüm öncesi hâlâ küçük bir gerçek cihaz duman paketine ihtiyaç duyar.

Test için Android emülatörü ile iOS simülatörü arasındaki fark nedir?

Android emülatörü, donanım hızlandırmalı bir sanal makinede tam bir Android sistem imajı çalıştırır, bu yüzden işletim sistemi büyük ölçüde bir cihaz gibi davranır. iOS Simülatörü, uygulamanızın gerçek iOS çekirdeği değil, bir simülatör mimarisi derlemesini çalıştıran bir macOS sürecidir. İkisi de arayüz ve regresyon testlerine uygundur; hiçbiri performans, pil veya sensör ölçümlerine uygun değildir.

Yapay zeka tarafından üretilen testler Espresso, XCUITest ve Appium ile çalışır mı?

Çalışmalı ve bunda ısrar etmelisiniz. İyi tasarlanmış bir ajan, testleri Android için Espresso kodu, iOS için XCUITest kodu veya platformlar arası paketler için Appium betikleri olarak dışa aktarır; böylece testler deponuzda yaşar, ajan olmadan çalışır ve elle düzenlenebilir. Yalnızca satıcının çalıştırıcısının anladığı bir format bir kilitlenme riskidir.

Kendi kendini onaran bulucular gerçek hataları gizleyebilir mi?

Evet, ara sıra. Bir tanımlayıcı değiştiğinde, ajan elemanı metne, role, hiyerarşi konumuna ve görsel benzerliğe göre yeniden çözer, ardından düzeltmeyi bir diff olarak önerir. Bu, kullanıcıların bulamayacağı bir yere taşınmış bir kontrolü örtebilir. Her onarılmış bulucu için insan incelemesi zorunlu tutun ve bir ekranda tekrarlanan onarımı bir uyarı işareti olarak ele alın.

iOS simülatör testlerini Linux CI runner'larında çalıştırabilir miyim?

Hayır. iOS Simülatörü Xcode'un bir parçasıdır ve yalnızca macOS'ta çalışır, bu yüzden iOS test işleri, CI sağlayıcınız tarafından barındırılan veya kendi barındırdığınız bir macOS runner'a ihtiyaç duyar. Android emülatörleri, KVM hızlandırmalı Linux runner'larda iyi çalışır. Yaygın bir kurulum, maliyet için Android işlerini Linux'ta, iOS işlerini ise aynı ajan ve rapor formatına sahip daha küçük bir Mac runner havuzunda çalıştırır.

Uygulama ekran görüntülerini ve kayıtlarını bir yapay zeka modeline göndermek güvenli mi?

Ekranların ne içerdiğine ve modelin nerede çalıştığına bağlıdır. Tohumlanmış test verisi içeren ekranları barındırılan bir API'ye göndermek genellikle sorun değildir; üretim müşteri verisi veya yayımlanmamış bir ürün içeren ekranlar önce bir inceleme hak eder. Alternatif, görsel ve dil modellerini kendi GPU'larınızda özel olarak çalıştırmaktır; böylece ekran görüntüleri ve kayıtlar çevrenizden asla çıkmaz.

Nanobase AI nasıl yardımcı olabilir

Nanobase AI, AI Mobil Test Lab'ı uçtan uca teslim eder: uygulama analizi, arayüz ve regresyon testlerinin üretimi, yerel Android emülatörlerinde ve iOS simülatörlerinde çalıştırma, kendi kendini onaran bulucular, arayüz sapması tespiti ve GitHub Actions, GitLab CI veya Jenkins'e bağlanan raporlar. Üretilen testler, deponuzda kalan Espresso ve XCUITest uyumlu kod olarak dışa aktarılır. Ekran görüntülerinin ve test verisinin çevrenizin içinde kalması gerektiğinde, modelleri NVIDIA GPU'larında, şirket içinde veya kendi bulutunuzda özel olarak devreye alırız. Silikon Vadisi merkezli ve NVIDIA Inception Programı üyesi olarak, gerçek cihaz duman matrisini boyutlandırmaya da yardımcı oluruz. Canlı demoyu /demo adresinde görün veya çözümlerimize göz atın.

Projenizi konuşmaya hazır mısınız? Nanobase AI ile iletişime geçin veya hello@bumu.tech adresine e-posta gönderin.