Bu makalenin   Appium ve Selenoid kullanarak Android'de UI testlerini çalıştırmak için hızlı ve kolay bir altyapının nasıl oluşturulacağını anlattık. iOS'ta UI testlerinin başlatılmasını sürece nasıl dahil ettiğimizi anlatmak için hikayemize devam ediyoruz. ilk bölümünde   GGR ile ölçeklendirme  Bir ana bilgisayardaki maksimum paralel iş akışı sayısı, kaynaklarıyla sınırlıdır. Bu nedenle birden fazla ana bilgisayarı tek bir kümede birleştirmek için bir araca ihtiyacımız vardı. Bunun için Aerokube'dekilerin   (GGR) kullanıyoruz. Belgelerdeki açıklamaya göre GGR, ölçeklenebilir ve yüksek oranda kullanılabilir Selenyum kümeleri oluşturmak için kullanılan bir yük dengeleyicidir.  Go Grid Router'ını  Testleri içeren proje, kullanılan sürecin bir parçası olarak GGR'de bir sorgu çalıştırır. Konfigürasyonunda belirtilen Selenoid parametrelerini yoklar ve kullanılan platforma, serbest akışların mevcudiyetine ve her Selenoid'in önceden tanımlanmış özgül ağırlığına göre yükü bunlar arasında dağıtır.   GGR ve GGR kullanıcı arayüzünü dağıtmak kolaydır:    yükleyin. Docker'ı  GGR yapılandırma dosyaları için bir dizin oluşturun   . mkdir -p /etc/grid-router/quota  Bir   dosyası oluşturun   . user.htpasswd $ htpasswd -bc /etc/grid-router/users.htpasswd test test-password  Ana bilgisayar olarak dağıtılan Selenoid'in adresini belirttiğiniz bir kota dosyası oluşturun:   $ cat /etc/grid-router/quota/test.xml <qa:browsers xmlns:qa="urn:config.gridrouter.qatools.ru"> <browser name="android" defaultVersion="10.0" defaultPlatform="android"> <version number="10.0"> <region name="1"> <host name="0.0.0.0" port="4444" count="1"/> </region> </version> </browser> </qa:browsers>  GGR kapsayıcısını çalıştırın:   docker run -d \ --name ggr \ -v /etc/grid-router/:/etc/grid-router:ro \ --net host aerokube/ggr:latest-release \ -listen=:4445 -guests-allowed  Test projesinde Appium bağlantı noktasını çalışan GGR'nin bağlantı noktasıyla değiştirin:   val driver = AndroidDriver(URL("http://localhost:4445/wd/hub"), capabilities)  GGR UI kapsayıcısını çalıştırın:   docker run -d \ --name ggr_ui \ -p 8888:8888 \ -v /etc/grid-router/quota:/etc/grid-router/quota:ro \ aerokube/ggr-ui:latest-release  GGR UI portunu   aracılığıyla ilettiğimiz Selenoid UI konteynerini çalıştırın: selenoid-uri   docker run -d \ --name selenoid-ui \ -p 4446:4446 \ --link selenoid:selenoid \ aerokube/selenoid-ui:1.10.4 \ --selenoid-uri "<http://ggr-ui:8888>"  Selenoid kullanıcı arayüzümüz artık GGR'ye bağlı tüm Selenoid kümelerinin durumunu göstermelidir.  Şimdi iOS'ta testlerin yürütülmesine geçiyoruz  İOS'ta kullanıcı arayüzü testleri yürütmek için kendi Mac mini grubumuzu kullanıyoruz. Çiftlik benzer şekilde hizmet dışı bırakılmış ancak çalışır durumdaki MacBook'lardan monte edilebilir. Alternatif olarak   . Her ana bilgisayara aşağıdakilerin yüklenmesi gerekir: kiralanabilirler  Appium (iOS≥16 ile çalışırken Appium 2.x kullanılmalıdır).  Xcode.  Bazı erken problemler  Docker kapsayıcılarında iOS simülatörlerini çalıştırmanın bir yolunu bulamadığımız için Android testlerini çalıştırırken kullanılan yapıyı kopyalayamadık. Göz önünde bulundurduğumuz seçeneklerden biri   çalıştırmaktı, ancak bunun   ile ilgisi olmayan herhangi bir amaç için kullanımının yasallığı konusunda şüphelerle karşılaştık. Bu yüzden farklı bir yola gitmeye karar verdik.  Docker-OSX'i OS X Güvenlik Araştırması  Yineleme #1: GGR→Appium  Daha önce oluşturulan GGR yapılandırma dosyasına iOS testleri için Appium'u (port 4723) Selenoid ana bilgisayarı olarak ekledik:   <qa:browsers xmlns:qa="urn:config.gridrouter.qatools.ru"> <browser name="android" defaultVersion="10.0" defaultPlatform="android"> <version number="10.0"> <region name="1"> <host name="0.0.0.0" port="4444" count="1"/> </region> </version> </browser> <browser name="iPhone 14" defaultVersion="16.2" defaultPlatform="iOS"> <version number="16.2"> <region name="1"> <host name="0.0.0.0" port="4723" count="1"/> </region> </version> </browser> </qa:browsers>  Böyle bir durumda iOS şeması şöyle görünür:   Bu yinelemede kullanılan yapı işlevseldir. Sorun şu ki, bu durumda testleri her Mac mini'de yalnızca tek bir iş akışında çalıştırabiliyoruz ve bu da israf anlamına geliyor. Ayrıca küme Selenoid kullanıcı arayüzünde görüntülenmez.  Yineleme #2: GGR→Selenoid→Appium  Selenoid,   çalışmanıza olanak tanır. Yukarıdaki sorunlar, iOS testlerini çalıştırırken de yürütülebilir bir dosya olarak Selenoid kullanma kararımızı etkiledi: kaplardan daha fazlasıyla  Selenoid'i indirin (   /   ). amd64 arm64  Bir   yapılandırma dosyası oluşturun. tarayıcılar.json  Yapılandırma dosyasında Appium ve başlangıç ayarlarını belirttiğinizden emin olun:   { "iPhone 14": { "default": "16.2", "versions": { "16.2": { "image": ["appium", "--log-timestamp", "--log-no-colors", ...] } } } }  Selenoid dosyasının yürütülmesine izin verin. Bizim durumumuzda   kullandık. chmod 755  Selenoid'i terminal aracılığıyla çalıştırın. Aşağıdaki parametreleri kullandık:   . selenoid -conf ~/browsers.json -disable-docker -capture-driver-logs -service-startup-timeout 4m -session-attempt-timeout 4m -timeout 6m -limit 2  Belirtilen zaman aşımları gereklidir çünkü standart zaman aşımları, uygulamanın bulut depolama alanından indirilmesi ve simülatörün başlatılması için yeterli olmayabilir.  Maksimum çalışan simülatör sayısını ayarlamak için   parametresi kullanıldı. Bu, gelecekte GGR tarafından kullanılacak referans değerdir. Ana bilgisayarın performansı, parametreyi ayarlamak için bir kılavuz olarak kullanılır. -limit  Başlangıç ayarları hakkında daha fazla bilgiyi Selenoid   okuyabilirsiniz. belgelerinde  Gerekirse, sistemin ani bir şekilde yeniden başlatılması durumunda Selenoid'i otomatik olarak çalıştırmak için her Mac mini'de bir PLIST dosyası oluşturulabilir.  Artık kümenin süreci şuna benzer:   Bu yaklaşımla Selenoid UI işlevselliğini ve aynı ana bilgisayardaki birden fazla akışta testler yürütme yeteneğini kısmen elde ediyoruz.   Dezavantajı ise, her Mac mini'de bir simülatör oluşturmak ve bunu UUID ve bağlantı noktası atamasını belirterek Appium'a bağlamak için çok sayıda rutin görevi manuel olarak gerçekleştirmeniz gerektiğidir. Daha sonra yeni bir iOS sürümüne yükseltmeniz gerekirse bu bir sorun olabilir.  Yineleme #3: GGR→Selenoid→Bash→Appium  Zaman geçtikçe büyümeye devam edecek büyük bir Mac mini çiftliğimiz var. Bunu aklımızda tutarak, simülatörleri elle oluşturup bunları Appium'a bağlamak zorunda kalmamak için ölçeklendirmeyi kolaylaştırmanın bir yolunu arıyorduk. Önceki şema yürürlükte olsaydı, Appium ve simülatörlerin kullanım ömrü uzun olacaktı ve bu da öngörülemeyen sonuçlara yol açabilirdi.  Çözüm ararken Selenoid yapılandırma dosyasında bir bash betiğinin ana bilgisayar olarak belirtilebileceğini keşfettik:   { "iPhone 14": { "default": "16.2", "versions": { "16.2": { "image": ["~/bin/config/start_appium.sh", "iPhone 14"] } } } }  Bizimki şöyle görünüyor:   #!/bin/bash set -ex DEVICE_NAME=$1 APPIUM_PORT=$(echo $2 | cut -d '=' -f 2) function clean() { if [ -n "$APPIUM_PID" ]; then kill -TERM "$APPIUM_PID" fi if [ -n "$DEVICE_UDID" ]; then xcrun simctl delete $DEVICE_UDID fi } trap clean SIGINT SIGTERM # Each simulator has a udid, so to run the same devices in parallel - clone and run # only clones. You cannot clone a running device. After closing the session, delete the clone. cloned_device_name="[APPIUM] ${DEVICE_NAME} ($(date +%Y%m%d%H%M%S))" DEVICE_UDID=$(xcrun simctl clone "$DEVICE_NAME" "$cloned_device_name") # https://github.com/appium/appium-xcuitest-driver#important-simulator-capabilities WDA_LOCAL_PORT=$(($APPIUM_PORT+1000)) MJPEG_SERVER_PORT=$(($WDA_LOCAL_PORT+1000)) DEFAULT_CAPABILITIES='"appium:udid":"'$DEVICE_UDID'","appium:automationName":"'XCUITest'","appium:wdaLocalPort":"'$WDA_LOCAL_PORT'","appium:mjpegServerPort":"'$MJPEG_SERVER_PORT'"' appium --base-path=/wd/hub --port=$APPIUM_PORT --log-timestamp --log-no-colors --allow-insecure=get_server_logs,adb_shell \ --allow-cors --log-timestamp --log {choose_directory_for_logs} \ --default-capabilities "{$DEFAULT_CAPABILITIES}" & APPIUM_PID=$! wait   Komut dosyası kullanılıyorsa belirtilen yeteneklere ve Appium başlangıç ayarlarına çok dikkat edin. Bunlar, çalıştırma için Appium 2.x'in kullanıldığı varsayılarak burada ayarlanmıştır - Appium 1.x, satıcının yeteneklerde belirtilmesini gerektirmez ve --base-pat belirtme seçeneği yoktur.  Komut dosyası paralel çalışan simülatörlerin sorununu çözüyor:  Birden fazla Appium bir Mac mini'den GGR'ye doğrudan bağlandığında   çünkü aynı emülatörü aynı UDID'lerle çalıştıramazsınız. UDID'yi her seferinde manuel olarak çoğaltmanız ve sabit kodlamanız gerekir. (Örneğin iOS sürümünü veya simülatör modelini değiştirmeniz gerekiyorsa.) emülatörlerde bir sorun ortaya çıkar    . Appium'u her seferinde manuel olarak çalıştırmak ve bağlantı noktaları ve simülatörlerle çakışma olup olmadığını düzenli olarak kontrol etmek gerekir. Zayıf ölçeklenebilirlik  Selenoid kullanımı, tek bir ana bilgisayardaki birden fazla Appium + Simulator çifti arasında çakışma yaratmayan tek bir komut dosyasına kadar bu süreci basitleştirmeyi mümkün kılar. Appium'u başlatır ve Selenoid'den karşılık gelen bir sinyal aldığında onu öldürür ve başlangıçta simülatörleri dinamik olarak klonlar ve oturum sona erdiğinde bunları siler.  Geliştirdiğimiz süreç şuna benziyor:   Daha sonra, Android ve iOS yapılarını birleştirerek her Mac mini'nin Selenoid adreslerini konuşlandırılan GGR'nin yapılandırma dosyasına ekliyoruz:   Sonuç olarak özet  Birleştirilmiş altyapı, her iki platformda da 36 iş akışında saatte toplam yaklaşık 500 kullanıcı arayüzü testi çalıştırmamıza olanak tanıyor. Android testleri için yeni bir ana bilgisayarın eklenmesi, GitHub Eylemleri'ndeki iş akışı kullanılarak tamamen otomatik hale getirilebilir ve yaklaşık iki dakika sürer. Çok yakın gelecekte Selenoid kümesinin dağıtımını Mac mini'de de otomatikleştirmeyi planlıyoruz.   İlerleyen süreçte, tüm süreçleri birleştirmek ve herhangi bir MacOS kullanım kuralını ihlal etmeden bunlara dağıtımı kolaylaştırmak için   konteynerlerini Mac mini'de Linux ile çalıştırmayı denemek istiyoruz. Bu konuyla ilgili herhangi bir deneyiminiz varsa, bunu yorumlarda paylaşmanızı çok isteriz. Docker-OSX    tarafından gönderildi. Ivan Grigoriev

This story contains new, firsthand information uncovered by the writer.

The writer was physically present in relevant location(s) to this story. The location is also a prevalent aspect of this story be it news or otherwise.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

inDrive.Tech

Bu ses hikayenin orijinal dilinde üretilmiştir!

Her Gün Mobil Cihazlarda 5000'den Fazla Test Nasıl Çalıştırılır; inDrive'ın Başucu Kitabı'ndan (Bölüm 2)

About Author

YORUMLAR

ETİKETLERİ ASIN

BU YAZI

Related Stories

Sulara Yelken Açmak: Data Lakes ile Üretim Sınıfında RAG Uygulamaları Geliştirme

HackerNoon Kendi Ana Dilinizde 🆕 ‼️ Teknoloji Blog Yazıları için 77 Dil Ana Sayfası

Benzersiz Bir Ekosistemi Güçlendiren Bitcoin UTXO Modeli

Yapay Zekanın Gücünü Ortaya Çıkarıyoruz. En Son Tekniklerin Sistematik Bir İncelemesi: Özet ve Giriş

Sulara Yelken Açmak: Data Lakes ile Üretim Sınıfında RAG Uygulamaları Geliştirme

HackerNoon Kendi Ana Dilinizde 🆕 ‼️ Teknoloji Blog Yazıları için 77 Dil Ana Sayfası

Benzersiz Bir Ekosistemi Güçlendiren Bitcoin UTXO Modeli

Yapay Zekanın Gücünü Ortaya Çıkarıyoruz. En Son Tekniklerin Sistematik Bir İncelemesi: Özet ve Giriş

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps