Android cihaz laboratuvarı otomasyonu: cihazlar ve emülatörler

Küçük bir Android telefon ve emülatör havuzunu, açık başlangıç durumları, gözlemlenebilir kontroller, sınırlı beklemeler, arıza kanıtları ve net bir oluştur-satın al kuralıyla tekrarlanabilir bir cihaz laboratuvarına dönüştürün.

Kısa cevap: Rafı değil, çalışma döngüsünü otomatikleştirin

Bir Android cihaz laboratuvarı, her çalıştırma adlandırılmış bir durumdan başladığında, sınırlı bir kontrol gerçekleştirdiğinde, bir sonkoşulu doğruladığında ve başka bir kişinin inceleyebileceği kanıt bıraktığında kullanışlı hale gelir. Telefonlar, USB hub'ları, standlar ve etiketler yalnızca fiziksel katmandır. Android cihaz laboratuvarı otomasyonu, bu cihazları tekrarlanabilir sürüm, destek ve yerelleştirme kontrollerine dönüştüren işletim katmanıdır.

Hala telefon, kablo, güç veya depolamayı seçiyorsanızdüşük maliyetli Android cihaz laboratuvarı kurulum kılavuzuile başlayın. Bu makale, donanım mevcut olduktan sonra başlar. Gerçek cihazların ve emülatörlerin nasıl birleştirileceğini, küçük bir test matrisinin nasıl tanımlanacağını, bir cihaz çalıştırma kartının nasıl oluşturulacağını, gözlemlenebilir durumda senkronizasyonun nasıl yapılacağını, ekran görüntüleri ve günlüklerin nasıl yakalanacağını ve barındırılan bir cihaz bulutunun ne zaman daha iyi bir seçim olduğuna nasıl karar verileceğini açıklar.

Amaç birim testlerinin, Compose testlerinin, Espresso, UI Automator, Appium, Gradle Managed Devices veya Firebase Test Lab'ın yerini almak değildir. Bu araçların farklı sınırları vardır. BirAI Android otomasyon aracı, operatörlerin, QA incelemecilerinin ve destek ekiplerinin anlaması gereken gerçek cihaz kontrolleri için görünür bir iş akışı katmanı olarak burada en kullanışlıdır.

Gerçek cihazlara ve emülatörlere farklı işler verin

Bir cihaz laboratuvarının her cihazda her teste ihtiyacı yoktur. Emülatörlerin paralel olarak oluşturulması, sıfırlanması, parametreleştirilmesi ve çalıştırılması hızlıdır. Gerçek telefonlar, satıcı donanım yazılımını, fiziksel kameraları, Bluetooth'u, biyometrik istemleri, termal davranışı, arka plan kısıtlamalarını, bildirim dağıtımını, USB durumunu ve sanal bir cihazın aslına sadık kalarak üretemeyeceği giriş yüzeylerini açığa çıkarır. Tek bir evrensel platformu savunmak yerine bu farklılıkları sorumluluğu bölmek için kullanın.

Pratik bir başlangıç modeli, geniş bir sanal katman ve dar bir fiziksel katmandır. Sanal yapılandırmalarda hızlı deterministik kontroller gerçekleştirin, ardından küçük bir kritik paketi gerçek müşteri riski için seçilen iki veya üç gerçek telefona yönlendirin. Yalnızca hata verileri başka bir modelin, Android sürümünün, yerel ayarın veya satıcı davranışının sonucu değiştirdiğini gösterdiğinde genişletin.

Satır başına bir neden içeren bir cihaz matrisi tanımlayın

Firebase Test Lab, bir test matrisini seçilen cihazların ve test yapılandırmalarının birleşimi olarak tanımlar. Bu fikir aynı zamanda yerel bir laboratuvar için de işe yarar, ancak matrisin kapsamlı olmaktan ziyade risk bazlı olması gerekir. Her satırın bir nedene, bir sahibine ve beklenen bir karara ihtiyacı vardır. Yalnızca mevcut olduğu için var olan bir telefon, serbest bırakma güvenini artırmadan şarj etme, sıfırlama ve bakım süresini sessizce tüketecektir.

• Ana sürüm yolu için güncel bir Android temel çizgisini koruyun.
• Uyumluluk ve yükseltme davranışı için desteklenen eski bir API düzeyini koruyun.
• Satıcıya özel bir gerçek telefonu yalnızca ürün yazılımı, izinleri, pil politikası veya müşteri paylaşımı belirgin bir risk oluşturduğunda ekleyin.
• Düzen ve erişilebilirlik önemli olduğunda küçük ekranlı veya yüksek yazı tipi ölçeğinde bir yapılandırma ekleyin.
• Yalnızca bu koşul altında sonuçları değişebilecek kontrollere yerel ayar, tema, yönlendirme, ağ veya hesap durumu ekleyin.
• Artık belirgin kusurlar bulmayan veya mevcut müşteri segmentini desteklemeyen matris satırlarını kullanımdan kaldırın.

Her satırın desteklediği kararı adlandırın: bir sürümü engelleyin, inceleme kanıtlarını toplayın, bir destek vakasını yeniden oluşturun veya cihaza özgü olduğundan şüphelenilen bir arızayı araştırın. Bu karar, satırın ne kadar güvenilirliğe, izolasyona ve raporlamaya ihtiyaç duyduğunu kontrol eder. Bir sürüm engelleyici, denetimli bir keşif kontrolünden daha güçlü sıfırlama ve onaylama kuralları gerektirir.

Otomasyon yazmadan önce bir çalıştırma kartı oluşturun

Laboratuvar kontrolü için en küçük kullanışlı özellik çalışma kartıdır. Gizli varsayımların bir operatörün hafızasında yaşamasını engeller ve otomasyona istikrarlı bir sözleşme kazandırır. Düğümleri, seçicileri veya çerçeve kodunu seçmeden önce kartı gözlemlenebilir terimlerle yazın.

Başarıyı bir dizi dokunuş olarak tanımlamayın. Sıradan sonra bulunması gereken görünür veya yapılandırılmış durumu tanımlayın. Kullanıcı arayüzü düzenleri değişir; iş koşulları daha dayanıklıdır. Oturum açma kontrolü, otomasyonun eskiden bir düğmenin bulunduğu koordinatlara dokunması nedeniyle değil, beklenen hesap durumu ve ana yüzey mevcut olduğu için başarılı olur.

Kanıtları silmeden durumu sıfırla

Paylaşılan cihazlar, uygulama kusurları gibi görünen şekillerde başarısız oluyor: eski hesaplar, önbelleğe alınmış izinler, bekleyen güncellemeler, değişen izinler, düşük depolama alanı, beklenmeyen bir klavye, açık sistem iletişim kutusu, bildirim katmanı veya ödeme işleminin yarısında kalan bir önceki çalıştırma. Yalnızca çalıştırma kartı tarafından adlandırılan durumu sıfırlayın ve kurtarma işlemi değiştirmeden önce arızayı yakalayın.

1. Duruma dokunmadan önce cihazı tanımlayın ve oluşturun.
2. Önceki çalıştırma beklenmedik bir şekilde sona erdiğinde mevcut ekranı yakalayın.
3. Yeterli olan en az yıkıcı sıfırlamayı kullanarak uygulamayı belirtilen başlangıç durumuna döndürün.
4. Ağı, zamanı, depolamayı, yönlendirmeyi, yerel ayarı, yazı tipi ölçeğini ve gerekli izinleri onaylayın.
5. İlk iş eyleminden önce başlangıç durumu işaretçisini doğrulayın.
6. Sıfırlama işlemi sürekli başarısız olursa cihazı karantinaya alın; Altyapı hatasını ürün hatasına dönüştürmeyin.

Tam silme otomatik olarak daha güvenli değildir. Bir kusuru yeniden oluşturmak için gereken durumu tam olarak ortadan kaldırabilir ve ekipleri kontrolleri atlamaya teşvik eden kurulum süresi ekler. Yeni yükleme, yükseltilmiş yükleme, oturum açma, oturum kapatma ve geri yüklenen hesap yolları için, bu durumlar farklı riskler taşıdığında ayrı profiller tutun.

Daha uzun süre uyumak yerine durumu senkronize edin

Android'in test kararlılığı kılavuzu, cihaz performansı ve eşzamansız çalışma farklılık gösterdiğinden rastgele uykulara karşı uyarıda bulunur. Sabit bir gecikme, meşgul bir telefonda hem çok kısa hem de hızlı bir telefonda gereksiz derecede yavaş olabilir. Anlamlı bir koşul için, bu koşul hiçbir zaman görünmediğinde zaman aşımı ve hata yapısıyla birlikte açık bir beklemeyi tercih edin.

• Uygulama başlatıldıktan sonra, tahmin edilen birkaç saniye yerine kararlı bir kullanıcı arayüzü öğesi veya ekran durumu bekleyin.
• Dokunduktan sonra bir sonraki girişi göndermeden önce bir sonkoşulu doğrulayın.
• Gerçekten oylamaya ihtiyaç duyan durumlar için sınırlı tekrarı kullanın; Zaman aşımında son gözlemi kaydedin.
• Sistem izin diyaloglarını, güncelleme istemlerini ve OEM katmanlarını rastgele gürültü olarak değil, adlandırılmış dallar olarak değerlendirin.
• Görünür durum, özellikle ödeme, silme, izin veya hesap değişikliği öncesinde, onaylanan kümenin dışında olduğunda durun.

Mevcut LaiCai Flow sözleşmesi şu görünür modeli takip ediyor: Kullanıcı arayüzü gözlemleri, OCR, şablon eşleştirme ve ekran yakalama gözlem durumu; giriş ve işaretçi düğümleri bir işlem gerçekleştirir; akış düğümleri beklemeleri, dalları, sınırlı döngüleri, alt akışları, dönüşleri ve durakları yönetir. Gözlem, karar ve eylemi ayrı tutmak, iş akışının gözden geçirilmesini kolaylaştırır ve sürdürülmesini daha güvenli hale getirir.

Laboratuvar kontrolleri için okunabilir bir LaiCai Flow oluşturun

LaiCai Flow, LaiCai Screen Mirroring içindeki bir otomasyon özelliğidir. Cihaz laboratuvarı çalışması için ana Akışı, QA incelemecisinin okuyabileceği düzeyde tutun: cihazı hazırlayın, hedefi açın, kritik kontrolü çalıştırın, kanıt toplayın ve bitirin. Uzun bir eşleşme, seçim, dokunma ve bekleme zincirini ortaya çıkarmak yerine çok adımlı teknik ayrıntıları küçük alt akışlara yerleştirin.LaiCai Flow kılavuzu, Profillerin ve Akışların nasıl organize edildiğini açıklar.

1. Bağlı cihazın içeriğini okuyun ve amaçlanan seri takma adı seçin; İlk cihazın doğru olduğunu varsaymayın.
2. Uygulamayı açmadan veya değiştirmeden önce paketi ve mevcut kullanıcı arayüzü durumunu doğrulayın.
3. Erişilebilirlik bilgileri sabit olduğunda kullanıcı arayüzü durumunu, görünür metin kanıt olduğunda OCR'yi ve yalnızca doğrulanmış bir görüntü hedefi için şablon eşleştirmeyi kullanın.
4. Eylemler ve daha sonraki ekrana bağlı gözlemler arasına açık beklemeler yerleştirin.
5. Ekranı veya uygulama durumunu değiştiren her aşamadan sonra bir son koşulu kontrol edin.
6. Yalnızca adlandırılmış bir inceleme kararını desteklediğinde ekran görüntüsü alın veya kaydedin.
7. Net bir aşama sonucu döndürün; Bir sonraki eylem mevcut gözlemle gerekçelendirilmediğinde çalışmayı durdurun.

Bu kılavuzun hazırlanması sırasında, salt okunur LaiCai bağlamı 73 kullanılabilir düğüm türünü ve bağlı bir Samsung Android 16 telefonu bildirdi. Bu, mevcut sözleşmeyi ve cihaz farkındalığı yolunu doğrulamaktadır; bu bir performans ölçütü değildir. Bir Profili yayın altyapısı olarak değerlendirmeden önce kendi uygulamanızı, cihazlarınızı, varlıklarınızı ve çalışma zamanı desteğinizi doğrulayın.

Kırmızı nokta değil, arıza paketi toplayın

Başarısız bir kontrol neyin çalıştırıldığını, nerede çalıştığını, sistemin neyi gözlemlediğini ve çalışmanın neden durduğunu yanıtlamalıdır. Firebase Test Lab, mümkün olduğu durumlarda günlükler, ekran görüntüleri ve videoların yanı sıra test durumunu da döndürerek kullanışlı bir model ortaya çıkarır. Yerel bir cihaz laboratuvarının depolaması daha basit olsa bile aynı disipline ihtiyacı vardır.

• Çalıştırma kimliği, zaman damgası, iş akışı sürümü, derleme sürümü ve ortam.
• Cihaz modeli, Android sürümü, kararlı seri takma adı, ekran boyutu, yerel ayar, tema ve yönlendirme.
• Başlangıç durumu, giriş fikstür tanımlayıcısı ve tamamlanan son iş aşaması.
• Beklenen sonkoşul ve seçilen gerçek kullanıcı arayüzü, OCR, görüntü veya çerçeve sonucu.
• Kurtarma işleminden önceki ekran görüntüsü, yalnızca hareket önemli olduğunda kısa kayıt ve sınırlı bir ilgili günlük alıntısı.
• Sınıflandırma: ürün hatası, test hatası, cihaz altyapısı, veriler, ortam veya insan tarafından incelenmesi gerekiyor.

Yapılandırılmamış bir ekran görüntüsü klasörü yerine sabit dosya adları ve bir bildirim kullanın. Paylaşmadan önce kişisel veya gizli verileri çıkarın. Arıza etrafında kısa bir arındırılmış aralık yeterli olduğunda cihaz günlüklerinin tamamını yüklemeyin. Kanıtlar, yeni bir mahremiyet veya saklama sorunu yaratmadan bir sonraki kişinin işini azaltmalıdır.

Cihazlarına zaman kazandıracak çekleri seçin

Cihazların şarj edilmesi, temizlenmesi, güncellenmesi ve insan erişimine ihtiyaç duyması nedeniyle gerçek cihaz dakikaları azdır. Bunları görünür veya fiziksel davranışları önemli olan iş akışlarına verin. İlk iyi adaylar, dağıtım sonrası duman kontrolleri, izin ve sistem kullanıcı arayüzü yolları, kamera veya Bluetooth kurulumu, bildirim akışları, yerelleştirme kanıtları, satıcıya özel regresyonlar ve tam destek çoğaltımlarıdır.

Koda yakın daha hızlı testlerde iş mantığını, ayrıştırmayı, biçimlendirmeyi ve bileşen davranışını koruyun. Bu testlerin yapamayacağı sınırları kanıtlamak için gerçek cihazı kullanın: kurulu yapı, işletim sistemi, harici uygulama, giriş yüzeyi, ağ geçişi veya insanın görebileceği kompozisyon.Android otomasyon test araçları karşılaştırması, her gereksinimin uygun bir katmana atanmasına yardımcı olur.

Beş güvenilir yolculuktan oluşan kritik bir paket, kimsenin güvenmediği elli akıştan daha değerlidir. Temsili bir yolla başlayın, sıfırlama ve önceliklendirme maliyetini ölçün, ardından yalnızca yeni bir kontrol belirli bir sürümü, müşteriyi veya operasyonel kararı koruduğunda kapsamı ekleyin.

Laboratuvarı ölçeklendirmeden önce ölçün

Kendi kendine barındırılan cihaz gruplarını tartışan ekipler sürekli olarak aynı oluşturma ve satın alma girdilerine geri dönüyor: kuyruk davranışı, en yüksek eşzamanlılık, bekleme süresi, önyükleme veya sıfırlama hatası, bakım çalışması ve yalnızca fiziksel cihazlarda görülen kusurlar. Daha fazla donanım satın almadan veya her şeyi buluta taşımadan önce bu sinyalleri birkaç sürüm döngüsü boyunca izleyin.

• Günün saatine ve iş akışı önceliğine göre kuyruk bekleme.
• Şarj etme, güncelleme veya onarım için cihaz kullanımı ve zamanı kullanılamıyor.
• Cihaza göre başlatma durumu veya sıfırlama arıza oranı.
• Tekrar çalıştırmalar ürün değişikliklerinden ziyade otomasyondaki aksaklıklardan kaynaklanmaktadır.
• Başarısızlıktan yararlı bir sınıflandırmaya kadar geçen ortalama süre.
• Yalnızca gerçek cihazlarda, belirli satıcılarda veya belirli Android sürümlerinde bulunan belirgin kusurlar.
• Başarılı çalıştırma ve sürdürülen iş akışı başına operatör dakikaları.

Bunlar gösterişli kontrol panelleri değil, yönetim ölçümleridir. Kuyrukta bekleme süresi düşük ancak bakım ağırlıklıysa, barındırılan bir hizmet sahip olma maliyetini azaltabilir. Gizlilik, yerel çevre birimleri, hızlı etkileşimli hata ayıklama veya tekrarlanan destek çoğaltımı, geniş model kapsamından daha önemliyse, küçük bir yerel laboratuvar ağırlık merkezi olarak kalabilir.

Hibrit bir yap-satın al kuralı kullanın

Yerel ve barındırılan laboratuvarlar tamamlayıcı niteliktedir. Gradle Yönetilen Cihazlar, yapıdaki sanal cihazları tanımlayabilir ve test yürütmesi için bunları gruplayabilir. Firebase Test Lab, bir matrisi barındırılan sanal ve fiziksel cihazlara genişletebilir ve yönetilen yapıları döndürebilir. Yerel bir havuz, tekrarlanan operasyonel kontroller için anında erişim, özel çevre birimleri, denetimli hata ayıklama ve kararlı cihazlar sağlar.

Mantıklı bir hibrit, yönetilen sanal altyapı üzerinde çerçeve testlerini hızlı tutar, seçilen uyumluluk kontrollerini barındırılan gerçek cihazlara gönderir ve yüksek değerli fiziksel veya denetlenen akışlar için küçük bir yerel tezgahı korur. Eşzamanlılık, gizlilik ve müşteri-cihaz kanıtları değiştikçe doğru bölünme değişebilir.

Android cihaz laboratuvarı otomasyon kontrol listesi

1. Her cihaz matrisi satırına bir amaç ve karar atayın.
2. Ayrı emülatör, yerel gerçek cihaz, barındırılan, çerçeve testi ve görsel akış sorumlulukları.
3. Derleme, cihaz, başlangıç durumu, girişler, sonkoşullar, duraklar ve kanıtları içeren bir çalıştırma kartı oluşturun.
4. İlk iş eyleminden önce başlangıç durumunu doğrulayın.
5. Daha uzun kör uykular eklemek yerine gözlemlenebilir koşulları bekleyin.
6. Gözlemleri, kararları ve cihaz eylemlerini ayrı incelenebilir adımlar olarak tutun.
7. Sıfırlamadan veya kurtarma işlemi arızayı değiştirmeden önce kanıtları yakalayın.
8. Altyapı, veri, test, ortam ve ürün arızalarını ayrı ayrı sınıflandırın.
9. Kuyruğu, kullanımı, sıfırlama güvenilirliğini, kesintili yeniden çalıştırmaları, önceliklendirme süresini ve yalnızca fiziksel kusurları takip edin.
10. Kanıtlar desteklediğinde hibrit bir yerel ve barındırılan strateji kullanın.

Bir gerçek telefon, bir emülatör yapılandırması ve iş açısından kritik bir çalıştırma kartıyla başlayın. Başka bir cihaz veya iş akışı eklemeden önce bu döngüyü güvenilir ve incelenebilir hale getirin. Gözlemlenebilir bir cihaz laboratuvarı katmanı ekibinize uygun olduğunda, LaiCai FlowileAI Android otomasyonunu keşfedin ve uygulama ayrıntılarınıYerel duyarlı Akış kılavuzundasaklayın.

Editör notu: LaiCai Screen Mirroring'nin arkasındaki şirket olanBeePOS LLC, bu kılavuzu aşağıda bağlantısı verilen resmi Android ve Firebase belgelerini, mevcut salt okunur LaiCai ürün sözleşmelerini ve halka açık QA tartışmalarını kullanarak araştırdı. Ürün yetenekleri, tarafsız iş akışı rehberliğinden ayrı olarak tanımlanır. Sorularınız veya düzeltmeleriniz support@laicaiapp.com adresine gönderilebilir.

• Android Geliştiricileri: Testlerinizi Gradle Yönetilen Cihazlarla ölçeklendirin
• Android Geliştiricileri: Kararlılığı test edin
• Firebase Test Lab: Android testine başlayın
• Reddit r/QualityAssurance: Android emülatör altyapısının bakımı
• Android Developers: UI Automator