Öğeyi bulmak, etkileşime hazır olmasını beklemek, işlemi tetiklemek ve sonucu doğrulamak: Her otomasyon işlemi bu dört adımdan oluşur. Seçicileri, dinamik yüklemeyi, iframe ve shadow DOM yapılarını anlamak daha uzun ömürlü betikler kurmaya yardımcı olur.
Web otomasyonu çoğu zaman bir programa sizin yerinize düğmelere tıklatmak olarak anlaşılır. Ancak gerçekten uygulamaya başladığınızda, tek bir işlemin dört adımdan oluştuğunu ve bu adımlardan herhangi biri yanlışsa sanki hiçbir şey olmamış gibi görünebildiğini fark edersiniz.
Önce kolayca karıştırılan iki kavramı ayıralım. Web otomasyonu daha geniş bir kapsama sahiptir: Normalde bir kişinin web sayfasında yapacağı işleri bir programla gerçekleştirmek, buna request üzerinden veriyi doğrudan almak da dahildir. Tarayıcı otomasyonu ise bunun daha özel bir koludur: Program gerçek bir tarayıcıyı kontrol ederek sayfaları açar, JavaScript çalıştırır ve tıklama ile yazma hareketlerini taklit eder. Dinamik içeriğin fazla veya etkileşimlerin karmaşık olduğu senaryolarda genellikle ikinci yöntem gerekir.
Bir işlemin dört adımı
- Öğeyi bul: Hedefi id, name, class, CSS seçicisi veya XPath ile belirle. Anlamlı nitelikleri önceliklendir; ancak gerektiğinde yapıya veya indekse geri dön.
- Etkileşime hazır olmasını bekle: Bir öğenin DOM içinde görünmesi, tıklanabilir olduğu anlamına gelmez. Görünür veya tıklanabilir olmasını ya da belirli bir request'in dönmesini bekle. Beklenen şey süre değil, koşuldur.
- İşlemi tetikle: Tıkla, yaz veya kaydır. Özel bileşenlerde çoğu zaman bir insanın izlediği sıra tekrar edilmelidir: Önce aç, listenin render edilmesini bekle, ardından metne göre seçim yap.
- Sonucu doğrula: İşlemden sonra sonucun doğru olup olmadığını kontrol et. Link değişti mi, sayfadaki metin değişti mi, API ne döndürdü bak. Bu adım olmazsa başarısızlık başarı sayılabilir ve sonraki retry ile uyarılar güvenilir bir temelden yoksun kalır.
Dört adım içinde en fazla hata ayıklama süresini genellikle ikinci ve dördüncü adımlar alır. Bunun nedeni zor olmaları değil, çoğu zaman hata vermeden sessizce yanlış sonuç üretmeleridir.
Seçicinin kararlılığı betiğin ne kadar yaşayacağını belirler
Sayfa değiştiğinde sabit yazılmış locator bozulabilir. Metne, konuma veya indekse göre bulma değişikliklere karşı en dayanıksız yöntemdir: Tek bir düğmenin eklenmesi ya da bir uyarı metninin değişmesi her şeyi kaydırabilir.
Mümkünse id, name veya data niteliklerini kullan. Yapısal locator gerekiyorsa hepsini tek yerde topla; böylece değişiklikte onlarca satır yerine yalnızca bir noktayı düzeltirsin. Betik yazıldıktan sonra hiç bakım gerektirmeyeceğini de varsayma. Web siteleri düzenli olarak güncellenir ve bakım maliyetinin büyük bölümü burada oluşur.
Dinamik yükleme: Ne kadar beklediğinden çok neyi beklediğin önemlidir
Günümüzde ilk yükleme biter bitmez her şeyi hazır olan sayfa sayısı azdır. Veriler asenkron request'lerle render edilir, bu nedenle öğeler beklenenden daha geç görünebilir.
Sabit bekleme yaygındır ama kolayca bozulur: 3 saniyelik sleep yavaş bir makinede yetersiz kalabilir, hızlı bir makinede ise yalnızca zaman kaybettirir. Doğru yaklaşım bir koşulun gerçekleşmesini beklemek ve yalnızca öğe gerçekten tıklanabilir olduğunda işlem yapmaktır.
Öğe bulunamıyorsa önce iframe ve shadow DOM'u kontrol et
Öğe sayfada açıkça görünmesine rağmen betik onu bulamıyorsa sorun çoğu zaman seçicide değil, kapsamda olur.
iframe ayrı bir belgedir. Öğeyi aramadan önce ilgili frame'e geçmek, işlemden sonra da geri çıkmak gerekir; aksi halde sonraki aramalar yanlış context içinde yapılır. shadow DOM içindeki node'lar dışarıdaki CSS seçicileriyle doğrudan eşleşmez. Önce shadow root alınmalı, sonra onun içinde arama yapılmalıdır. Bu iki durum sık sık sayfanın değiştiği sanılarak yanlış yorumlanır ve gereksiz hata ayıklama süresi harcanır.
Kolayca atlanan iki konu daha var
Birincisi session. Login gerektiren görevlerde oturum açılmış durumun nasıl saklanıp yeniden kullanılacağı düşünülmelidir. Aksi halde her çalıştırmada yeniden login gerekir ve süreç verification adımında takılabilir.
İkincisi environment. Tüm görevler aynı tarayıcı ortamını paylaşırsa session ve cache birbirini etkileyebilir. Ayrı ayrı sorunsuz çalışan görevler birlikte çalıştığında birbirine müdahale etmeye başlayabilir. Tek görevden çok sayıda göreve geçerken environment isolation için ayrı bir katman oluşturmak birçok sorunu azaltır. PurpleMark gibi araçlar her environment için bağımsız fingerprint ve bağımsız proxy sağlarken, otomasyon framework'ü yalnızca işlemleri yürütmeye odaklanır.
Başlamadan önce bir sınırı netleştirin
Otomasyon tekrarlanan işlemlerin yerini alabilir, ancak gerçek bir insanın katılımını gerektiren adımların yerini alamaz. Hedef workflow gerçek zamanlı yüz doğrulama veya manuel inceleme içeriyorsa bu akış %100 otomatik hale getirilemez.
Bu nedenle önce en basit yöntemle doğrulayın: Tüm workflow'u baştan sona manuel olarak kendiniz yürütün, her adımı not edin ve geçilemeyen bir aşama olup olmadığını kontrol edin. Ancak bundan sonra ne kadar geliştirme emeği yatıracağınıza karar verin. Teknik olarak mümkün olması ile kuralların izin vermesi de farklı konulardır; hedef platformun hizmet şartlarını önceden inceleyin.
