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)

Bu makalenin ilk bölümünde 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.

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 Go Grid Router'ını (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.

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:

• Docker'ı yükleyin.
• GGR yapılandırma dosyaları için bir dizin oluşturun mkdir -p /etc/grid-router/quota .
• Bir user.htpasswd dosyası oluşturun $ 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 selenoid-uri aracılığıyla ilettiğimiz Selenoid UI konteynerini çalıştırın:

  
  

 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 kiralanabilirler . Her ana bilgisayara aşağıdakilerin yüklenmesi gerekir:

• 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 Docker-OSX'i çalıştırmaktı, ancak bunun OS X Güvenlik Araştırması 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.

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, kaplardan daha fazlasıyla ç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:

• Selenoid'i indirin ( amd64 / arm64 ).

• Bir tarayıcılar.json yapılandırma dosyası oluşturun.

• 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 chmod 755 kullandık.

• 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 -limit 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.
  • Başlangıç ayarları hakkında daha fazla bilgiyi Selenoid belgelerinde okuyabilirsiniz.

• 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 emülatörlerde bir sorun ortaya çıkar çü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.)

• Zayıf ölçeklenebilirlik . 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.

  
  

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 Docker-OSX 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.

Ivan Grigoriev tarafından gönderildi.