Güvenli bir Android iş akışı, bir şey olana kadar tıklamayı durdurmaz. Mevcut ekranı tanımlar, tekrar denemeleri sınırlar, bir sonraki durumu doğrular ve sonuç belirsiz olduğunda kanıtlarla durur.
Kısa cevap: bir sonraki eylem artık haklı görülmediğinde durun
Bir Android otomasyon durdurma koşulu, mevcut ekran, sonuç veya zamanlama bir sonraki eylemi artık desteklemediğinde iş akışının devam etmesini engelleyen bir kuraldır. Çalışmayı sonlandırabilir, kontrollü bir sonuç döndürebilir, kanıt toplayabilir veya davayı bir kişiye gönderebilir. Nokta her sürprizde durmamaktır. Nokta belirsizliği başka bir dokunuşa dönüştürmekten kaçınmaktır.
Güvenilir iş akışları, her önemli eylemden önce dört soruyu yanıtlar: Telefonun hangi durumda olması gerekir? Bu durumu hangi gözlem kanıtlar? Kaç kurtarma denemesi kabul edilebilir? Durum hiç ortaya çıkmazsa hangi kanıt korunmalıdır? Android UI Automator koşulsel beklemeler ve stabilite kontrollerini içerirken, WorkManager iptal ve durdurulmuş iş işlemeyi belgelemektedir. Ortak tasarım dersi basittir: beklemek, tekrar denemek ve durdurmak açık sınırlara ihtiyaç duyar.
- Sadece beklenen durum pozitif olarak tanımlandığında devam edin.
- Tekrar deneme yalnızca başarısızlık geçici olduğunda ve tekrar denemede net bir sınır olduğunda gerçekleştirin.
- Ekran bilinmediğinde, bir eylem hassas olduğunda veya son koşul başarısız olduğunda durun veya inceleme isteyin.
Devam et, bekle, tekrar deney, dur veya gözden geçirin?
| karar | Ne zaman kullanın | Gerekli sınır | Saklanacak kanıtlar |
|---|---|---|---|
| devam etmek | Mevcut durum ve sonraki eylem ikisi de beklenmektedir. | Bir geçiş gözden geçirildi | Gözlenen durum ve sonraki koşul |
| beklemek | Uygulama hala yükleniyor veya ayarlanıyor | Bekleme süresi dolmuş veya adlandırılmış hazır durum | Geçen süre ve son ekran |
| Tekrar deneyin | Geçici bir durum, iş anlamını değiştirmeden çözülebilir. | Maksimum denemeler artı aralık | Her gözlemdeki deneme sayısı ve sonucu |
| durma | Durum bilinmiyor, geçersiz, güvenli değil veya onaylanmış yoldan dışarıdadır. | Anında fesih | Nedeni durdur, ekran görüntüsü, yapılandırılmış sonuç |
| İnsan incelemesi | İş akışı güvenli bir şekilde karar veremez veya sonraki eylem maddi sonuçlara sahiptir. | Açık geçiş son tarihi ve sahibi | Tam kanıt paketleri ve önerilen sonraki adım |
Bu seçimler birbirinin yerine geçemez. Bir bekleme, aynı durumun yerleşmesi için aynı süreyi verir. Bir tekrar, sınırlandırılmış bir gözlem veya kurtarma eylemini tekrar eder. Bir dal, bilinen sonuçlar arasında seçim yapar. Bir durdurma, gözden geçirilen yolu sonlandırır. Otomasyonun güvenli bir şekilde seçmek için yeterli kanıt içermediğinde insan gözetimi uygundur.
Adım 1: eylemleri seçmeden önce eyaletleri adlandırın
Bu adımın sonunda, her önemli ekranın bir adı ve gözlemlenebilir küçük bir dizi gerçekine sahip olacaktır. Bir test sürümünü açmak, ayarlar sayfasına yönlenmek, hassas olmayan bir seçeneği değiştirmek ve yeni durumu doğrulamak gibi dar bir iş akışı ile başlayın. Uzun bir koordinat dizisi ile başlamayın.
- Başlangıç durumunu, beklenen sonraki durumu ve kabul edilebilir alternatif durumları yazın.
- Her durum için en dar yararlı sinyali seçin: UI özelliği, görünür metin, bilinen görüntü, algılanan nesne veya odaklanmış ekran görüntüsü.
- Beklenmeyen bir hesap, izin, satın alma, silme veya üretim verileri ekranı gibi asla otomatik bir eylem almaması gereken herhangi bir ekranı işaretleyin.
Doğrulama basittir: başka bir inceleyici durum tanımına bakabilmeli ve neden sonraki eylemin izin verildiğini açıklamalıdır. -ıresim tanıma otomatik tıklama kılavuzugörsel bir hedef bulmanın neden yeterli olmadığını gösterir. İş akışı hala dokunmadan önce bir ön koşul ve sonrasında bir son koşul gerektirmektedir.
Adım 2: her durumu kanıtlayan bir gözlem seçin
Bu adımın sonunda, her devlet bir temel gözlemi ve bir geri çağırma kanıtı kaynağına sahiptir. Bir etiket, seçilen devlet, etkinleştirilmiş kontrol veya öğe sayısı gibi semantik gerçekler için kullanıcı arayüzü yapısını kullanın. Görünür metin önemli olsa da kullanıcı arayüzü ağacı bunu güvenilir bir şekilde ortaya çıkarmıyorsa OCR kullanın. Konumu veya boyutu değişen doğrulanmış bir sınıf için şablon eşleştirme ve konum algılama için nesne algılama kullanın.
Birkaç zayıf sinyalin üst üste yığılmasını ve kombinasyonun kesinliğini ilan etmeyi önleyin. Geniş bir ekran görüntüsü, doğrulanmamış bir şablon ve kısmi bir OCR sonucu otomatik olarak güvenilir bir karar vermeyecektir. Bunun yerine, bir taşıyıcı gözlem tanımlayın ve diğer sinyalleri destekleyici kanıt olarak kaydedin. -ıAndroid görsel test karşılaştırmasıUI durumunun, OCR'nin, ekran görüntülerinin, şablonların ve tespitin her birinin nerede uyduğunu açıklar.
Doğrulama, hem pozitif hem de negatif örnekleri test etmek anlamına gelir. Durum, istenen ekranda geçerken görsel olarak benzer ancak yanlış bir ekranda başarısız olmalıdır. Bu durumları ayırt edemezse, bölgeyi daraltın, sinyali değiştirin veya eylemden önce iş akışını durdurun.
Adım 3: Her bekleme ve tekrar denemeye bir bütçe koyun
Bu adımın sonunda, hiçbir döngü sonsuza kadar çalışamaz. Her bekleme süresi ya zaman aşımı gerektirir ya da adlandırılmış bir hazırlık koşulu gerektirir. Her tekrar denemesi için maksimum deneme sayısı, makul bir aralık ve durumu daha da kötüleştirmeden tekrar denemelerin başarılı olmasının nedeninin olması gerekir.
| Başarısızlık kalıbı | Neden başka bir girişim yardımcı olabilir | Güvenli sınır | Nedeni durdur |
|---|---|---|---|
| Ekran hala yükleniyor | Aynı durum hazır hale gelebilir | Stabilleşene veya zaman aşımına kadar bekleyin | Hazır durum ulaşılamadı |
| Ölçek geçici olarak yok | İçerik kısa bir gecikme sonrasında ulaşabilir | Belirli sayıda denemeden sonra tekrar gözlemleyin. | Beklenen unsur hiç ortaya çıkmadı |
| Tıklamada geçiş üretilmedi | Girdi bir kez kaçırılmış olabilir | Ekranı kontrol ettikten sonra bir tekrar gözden geçirildi | Son koşul hala yok |
| Bilinmeyen diyalog veya hesap görünüyor | Başka bir girişim belirsizliği azaltmaz | Tekrar deneyilmeyecek | Beklenmeyen durum gözden geçirilmeye ihtiyaç duyar |
| Eylem silme, satın alma, gönderme veya yayınlama yapabilir | Göz ardı edilen tekrarlama sonuçları çoğaltabilir. | İdempotans kanıtlanmadıkça otomatik tekrar denemesi yoktur | Hassas eylem sonucu belirsizdir |
Android otomasyonu hakkındaki topluluk soruları genellikle sonsuza kadar bekleyen döngüleri veya takılı gibi görünen görevleri tanımlar. Maksimum deneme kuralı yararlı olsa da sayı işlemi takip etmelidir. Sadece okunabilir bir kontrol, durum değiştirme eyleminin aksine daha fazla deneme tolere edebilir. Doğru sayı, normal gecikmeyi kapsayan en küçük gözden geçirilmiş bütçe olacaktır.
Adım 4: Başarı ilan etmeden önce son koşulu doğrulayın
Bu adımın sonunda, teslim edilen bir tıklamaya artık tamamlanmış bir görev olarak bakılmamaktadır. Her durum değişikliği eyleminin ardından, arayüzün toparlanmasını bekleyin ve beklenen sonucu gözlemleyin. Son koşul eksikse, iş akışı sessizce bir sonraki eyleme devam etmemelidir.
- Eylemi yetkilendiren eyaleti kaydedin.
- Tek onaylanmış eylemi gerçekleştirin.
- İsimlendirilmiş bir son koşul veya sınırlandırılmış zaman aşımı bekleyin.
- Yolculuk, bir sonraki eyalete başarılı bir şekilde ulaşırsa ve kanıt yakalama, gözden geçirilmiş bir kurtarma veya durma başarısız olur.
Bu, üst üste yerleştirme, gecikmiş gezinme, kaçırılan giriş, eski koordinatlar ve benzer ekranlardan korunur. Ayrıca daha iyi bir hata raporu üretir: inceleyici beklenenin ne olduğunu, hangi eylemin gerçekleştiğini ve hangi sonraki durumun görünmediğini görür.
Adım 5: Bir kişinin karar vermesi için yeterli kanıt saklayın
Bu adımın sonunda, her durak belirsiz bir başarısız etiket yerine kompakt bir kanıt paketleri üretir. Geri yükleme ekranı değiştirmeden önce kanıtları yakalayın. Sadece teşhis için gerekli olanları saklayın ve ekran görüntülerini veya günlükleri test edilen uygulamanın veri politikasına göre işleyin.
- İş akışı ve adım adı, uygulama oluşturma, cihaz, Android sürümü, bölge ve yönlendirme.
- Beklenen durum, gözlemlenen durum, durum sonucu, girişim sayısı ve geçen süre.
- Odaklı bir ekran görüntüsü veya kesme, ayrıca OCR metni, eşleşme puanı, kullanıcı arayüzü özellikleri veya ilgili olduğunda tespit sonucu.
- Son başarılı durum, deneme edilen eylem, eksik son koşul ve açık durdurma nedeni.
- Önerilen bir inceleme seçimi: bilinen bir düzeltme sonrası tekrar deneyin, kabul edilen durumu güncelleyin veya ürünü inceleyin.
Faydalı bir devir, birinin tüm çalışmayı önce tekrar etmeden sonraki kararı vermesine olanak tanır. -ıAndroid otomasyon QA duman testi kılavuzugerçek cihaz kontrollerini dar ve tekrar edilebilir tutmanın daha geniş bir örneğini verir.
NasılLaiCai Flowgüvenli sınırları modelleyenler
LaiCai Flowiçindeki bir otomasyon özelliğidirLaiCai Screen Mirroring. Bir Akış, kullanıcı arayüzü yapısını veya görsel durumunu gözlemleyebilir, bilinen sonuçlar arasında dalgalanabilir, görünür bir şekilde bekleyebilir, sınırsız sayıda kez tekrarlayabilir, başarılı olana veya bir sınırına kadar bir çocuk Akış çağırabilir ve açık geri dönüş veya durma davranışı yoluyla sona erer. Bu yapı taşları, güvenlik kararını bir inceleyicinin görünür kılar.
Tipik bir modelde, bir kullanıcı arayüzü, OCR, şablon veya tespit düğümü telefonu bir kez gözlemler. Bir dal bilinen bir başarıyı veya başarısızlığı yönlendirir. Bir bekleme gerçek bir iş gecikmesini temsil eder. Bir sınırlandırılmış döngü geçici bir durumu ele alır. Kurtarma kenarı olmayan başarısız bir gözlem, aynı eylemi sonsuza dek beslemek yerine mevcut Akışı sonlandırabilir.
LaiCai Flow Insideuyumlu bir Profil'i çalıştırabilirLaiCai Android AgentGörevlendirmeden sonra telefonla. Uyumluluk hala o Profilde kullanılan her düğüm, varlık, model ve ağ bağımlılığına bağlıdır. Cihazda çalışmak, sınırlar, kanıt veya inceleme ihtiyacını ortadan kaldırmaz.
Dönüşüm öncesi pratik bir inceleme kontrol listesi
- Her eylem için bir adlandırılmış ön koşul ve doğrulanabilir bir son koşul vardır.
- Her bekleme bir zaman aşımı veya hazırlık koşulu içerir ve her yeniden deneme bir maksimum deneme sayısına sahiptir.
- Bilinmeyen durumlar durur veya gözden geçirilmiş bir kurtarma yoluna gider.
- Sonuçları belirsiz olduğunda hassas eylemler asla körü körüne tekrarlanmaz.
- Başarısızlık kanıtı, ekran tekrar değişmeden önce yakalanır.
- Olumlu, olumsuz, yavaş, kesintili ve beklenmedik ekran vakaları yetkili cihazlarda test edilmiştir.
Bu ifadelerden birinin yanlış olması durumunda, iş akışı bakımsız çalışma için hazır değildir. Hala denetimli modda yararlı olabilirAI Android otomasyonuBir kişinin cihazı izleyebileceği, durum koşullarını iyileştirebileceği ve arıza kanıtlarını inceleyebileceği bir yer.
Android otomasyon durdurma koşulu SSS
Sabit bir gecikme bir durma koşulu mu?
Hayır. Sabit bir gecikme yalnızca iş akışını duraklatır. Uygulamanın beklenen duruma ulaştığını kanıtlamaz. Herhangi bir gecikmeyi bir durum gözlemi ve zaman aşımı ile eşleştirin.
Her başarısızlık tüm iş akışını durdurmalı mı?
Hayır. Bilinen, geçici bir başarısızlık, gözden geçirilmiş ve sınırlandırılmış bir kurtarma yoluna bağlı kalabilir. Bilinmeyen bir durum, eksik bir son koşul veya belirsiz hassas bir eylem normalde durmalı veya gözden geçirilmesini talep etmelidir.
Ne kadar sayıda tekrar denemesi güvenli?
Evrensel bir sayı yoktur. Ölçülmüş normal gecikmeyi kapsayan en küçük sınırı kullanın ve durumu değiştiren eylemler için sınırı azaltın. Eylemi tekrarlamanın bir sonucu kopyalayabileceğini doğrulayın veya otomatik olarak tekrar deneymeyin.
Yapay zeka durma kurallarının ihtiyacını ortadan kaldırır mı?
Hayır. Yapay zeka bir ekranı yorumlamaya veya bir iş akışı önermeye yardımcı olabilir, ancak yürütme hala açıkça izin verilen durumlar, bütçeler, son koşullar ve inceleme sınırları gerektirir. Belirsizlik, kanıt toplamaya bir neden değil, devam etmeye izin verme değildir.
Belirsizliği otomatikleştirerek değil, onun üzerinden görünür hale getirin.
Güvenilir bir Android iş akışı en uzun süre çalışan iş akışı değildir. Her eylemin neden izin verildiğini, ne sonucu beklediğini ve kanıtlar değiştiğinde neden durduğunu açıklayabilen iş akışıdır.
Devletleri adlandırın, bir taşıyıcı gözlemi seçin, her beklemeyi ve yeniden denemeyi sınırlayın, her son koşulu doğrulayın ve yararlı bir devretmeyi koruyun. Bu tasarım durma koşullarını savunma kodundan iş akışının çalışma politikasına dönüştürür.