Sorunun geçmişi
Tizen, WebOS ve Android TV platformlarının yaygınlaşması, web teknolojilerinin sınırlı gömülü ortamlar içinde çalıştığı benzersiz bir test nişi oluşturdu. Bu soru, masaüstü web testinden on ayaklık kullanıcı arayüzü deneyimlerine geçişi ele alıyor; burada geleneksel fare/klavye varsayımları geçersiz hale geliyor ve donanım kısıtlamaları (512MB RAM, tek çekirdekli CPU'lar) üretim istasyonlarında görünmeyen hata modlarına yol açıyor. Erken dönem Akıllı TV uygulamaları, masaüstü benzeri kaynaklara dayanarak tasarlandı ve bu da özel manuel test protokollerini gerektiren yaygın üretim çökmelerine neden oldu.
Problem
Zorluk, odak tuzakları ve sonsuz döngülerle başa çıkması gereken mekansal navigasyon algoritmalarını (2D ızgaralar içinde odak hareketi) test etmek, güçlü tarayıcı profilleme araçları olmayan ortamlarda JavaScript yığın büyümesini izlemek ve kaynak rekabeti altında WebView JavaScript ve yerel JNI/Obj-C kodu arasındaki eşzamansız iletişim köprülerini doğrulamaktır. Giriş gecikmesi ve bellek baskısı senaryoları, gömülü sistemler için özgündür ve masaüstü Chrome’da doğru şekilde yeniden üretilemezken, IR uzaktan kumanda sinyalleri dokunmatik veya klavye girişlerinde mevcut olmayan debouncing sorunları getirir.
Çözüm
Fiziksel cihaz testini otomatik telemetri enjeksiyonu ve "soak testing" ile birleştiren hibrit bir metodoloji. Bu, IR uzaktan kumanda anahtar kodlarını sistematik navigasyon yollarına (programlanabilir uzaktan kumandalar kullanarak uçtan uca geçiş) haritalamayı, bellek profilleme yokken ADB shell komutlarıyla RSS'yi (Resident Set Size) izlemeyi ve yerel thread engellemesini simüle etmek için JavaScript köprüsüne yapay gecikmeler enjekte etmeyi içerir. Yaklaşım, CSS Spatial Navigation spesifikasyonları veya polyfill davranışı ile karşılaştırma yaparak mekansal navigasyonu doğrulamaya vurgu yapar.
Bir tıbbi eğitim şirketi, gelişmekte olan bölgelerde dağıtılan düşük maliyetli eğitim Akıllı TV'leri için bir WebView tabanlı anatomi görselleştirme uygulaması geliştirdi. Uygulama, D-pad navigasyonu ile kontrol edilen Tizen 4.0 WebView içinde Three.js kullanarak 3D döndürülebilir modeller gösteriyordu ve video dersleri modellerin üzerine örtülüyordu.
Problem tanımı
Saha raporları, sürekli kullanımdan sonra (tipik bir çalışma oturumu için) TV'nin uygulamayı hata mesajı vermeden zorla kapattığını belirtmiştir. Öğrenciler ayrıca, organ seçim ızgarasında hızlıca gezinirken "vurgunun kaybolduğunu" bildirdi ve gizli menü katmanlarında sıkışıp kaldı. Ayrıca, TV'nin yerel bildirim bannerı belirdiğinde (WebView thread'inde duraklamaya neden olarak), uygulamanın devam mantığı JavaScript köprüsünü donduruyordu ve tam bir yeniden başlatma gerektiriyordu.
Değerlendirilen farklı çözümler
Çözüm 1: Tizen Studio ile emulator tabanlı test
Artıları: Fiziksel donanım lojistiği olmadan otomatik UI test script'leri ve kolay bellek profilleme bağlantıları sağlar.
Eksileri: Emülatörler, bol RAM ve GPU hızlandırması olan x86 mimarilerinde çalışır ve gerçek üretim sızıntılarına neden olan ARM yonga seti bellek kısıtlamalarını, yazılım render yollarını ve WebView uygulama farklılıklarını yeniden üretemez.
Çözüm 2: Öğrenci beta grupları ile kullanıcı kabul testi
Artıları: Otantik kullanım örüntülerini ve termal kısıtlamayı etkileyen kötü havalandırma gibi gerçek dünya çevresel faktörleri yakalar.
Eksileri: 2 saatlik bellek birikimini veya belirli yarış koşullarını sistematik olarak yeniden üretmek imkansızdır; geribildirim anekdot niteliğindedir, teknik telemetri eksiktir ve kök nedenin belirlenmesi spekülatif hale gelir.
Çözüm 3: Fiziksel donanımda telemetri enstrümantasyonu ile kontrollü sistematik manuel test
Artıları: Gerçek cihaz kısıtlamalarını (256MB yığın sınırları) sistematik test vakaları ile birleştirir (örneğin, "ızgarayı 1000 kez ziyaret et", "4 saat akış oynatırken performance.memory'yi uzaktan hata ayıklama ile sorgula"). Uygulama yaşam döngüsündeki belirli anlarda sistem kesintilerinin (yerel bildirimleri simüle ederek) hassas bir şekilde enjekte edilmesine imkan tanır.
Eksileri: Belirli düşük maliyetli TV modelleri ile bir donanım laboratuvarı sürdürmeyi gerektirir; uzun süreli testleri izlemek zaman alıcıdır; bellek izleme için Linux konsol komutları bilgisi gerektirir.
Seçilen çözüm
Seçenek 3, çökmelerin donanım spesifik ve bellek bozulması ile ilişkili olması nedeniyle seçildi; bu da üretimdeki tam Tizen WebView koşulumunu (sürüm 2.4) gerektiriyordu. Testçiler, logcat izlemesi için SDB üzerinden bağlanan fiziksel bütçe TV modelleri kullandı ve JavaScript yığın anlık görüntülerini her 15 dakikada bir çekerek sistematik gezinme maratonları gerçekleştirdi. Ayrıca, video akışını belirli 30 saniyelik aralıklarla kesintiye uğratmak için sistem bildirimlerini programatik olarak tetiklediler.
Sonuç
Test, Three.js geometri verisinin anatomik sistemler arasında geçiş yaparken temizlenmediğini gösterdi ve bu da GPU sürecinin dokuları birikmesine neden oldu ve WebView sistemin OOM killer'ı tarafından öldürüldü (bu, malzemeler ve geometriler için açık dispose() çağrıları uygulayarak düzeltildi). Odak tuzağı, mekansal navigasyon kütüphanesinin React yeniden çizimlerinden sonra bayat DOM koordinatlarına dayalı olarak mesafeleri hesaplamasından kaynaklandı ve bu da odakları ayrılmış parçalara hapsetti (her yeniden çizim döngüsünden sonra bir odak yeniden hesaplaması yaparak düzeltildi). Köprü donması, uygulamanın Tizen yaşam döngüsünden gelen visibilitychange olaylarını ele almadığı için meydana geldi ve köprüyü tekrar başlattığında duraksayan sözler bıraktı (bu, bir duraklama durumu kuyruğu ve timeout sarmalayıcıları uygulayarak düzeltildi).
Donanım hızlandırması olmayan bir WebView'de, translate3d dönüşümlerine sahip görünümler arasında gezinirken CSS animasyon bellek birikimini nasıl test edersiniz?
Adaylar genellikle yalnızca görsel onayı esas alır ve yazılım renderlayıcısının kompozitör katmanlarını sızdırma eğilimini gözden kaçırır. Ayrıntılı cevap, GPU süreci belleğini izlemek için Chrome Remote Debugging kullanmayı veya Android ps komutunu kullanarak RSS bellek büyümesini gözlemlemeyi gerektirir. Testçiler, 500 kez yoğun animasyonlar ile iki ekran arasında gezinme döngüsü yaratarak, ardından bir çöp toplama işlemi zorlayarak (window.gc() eğer etkinleştirilmişse) yığın değişimini ölçmelidir. Anahtar, ana belleği tüketen her katmanın temizlenmediği "yetim" animasyon katmanlarını kontrol etmektir; bu durum, sınırlı WebView'lerde yaygındır.
Dinamik olarak değişen DOM yapısı (örneğin, tembel yüklenen satırlar) varken, kullanıcı navigasyon düğmesine basılı tuttuğunda mekansal navigasyon (D-pad) algoritmalarını doğrulamak için hangi metodoloji geçerlidir?
Çoğu testçi, tek tıklamalarla statik ızgaraları kontrol eder. Ayrıntılı metodoloji, "stres navigasyonu" ile ilgilidir; kullanıcı, 30 saniye boyunca aşağı ok tuşunu tutarken ızgara her 500ms'de yeni öğeleri tembel bir biçimde yüklemektedir. Testçi, odak algoritmasının yüklenmemiş alanlara "aşırı gitmemesini" veya önceki render'dan bayat koordinatlar kullanarak odak hedeflerini hesaplamasını doğrulamalıdır. Bu, JavaScript mekansal navigasyon polyfill'i ve sanal kaydırma kütüphanesi (örneğin, React Window) arasındaki entegrasyonu test etmeyi gerektirir.
Yerel depolama/IndexedDB verilerinin, arka plan süreçlerini agresif bir şekilde sona erdiren gömülü platformlarda OOM (Out of Memory) kesilmesinden sonra doğru bir şekilde sürdüğünü nasıl doğrularsınız?
Adaylar genellikle web depolamanın dayanıklı ve atomik olduğunu varsayarlar. Ayrıntılı cevap, aktif yazma işlemi sırasında platforma özgü komutlar (örneğin, Android TV'de am force-stop veya sistemi öldürmek için belleği doldurmak) kullanarak OOM kesilmesini simüle etmeyi içerir. Yeniden başlatıldıktan sonra, testçi veri bütünlüğünü doğrulamalıdır: Kısmî yazımların LocalStorage'ı bozup bozmadığını (bu eksik işlemler) veya IndexedDB geri dönüşünün düzgün yapılıp yapılmadığını kontrol etmelidir.