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.

Bu ses hikayenin orijinal dilinde üretilmiştir!

Çok uzun; Okumak

Making security fun one episode at a time

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)

Çok uzun; Okumak

People Mentioned

inDrive.Tech

STORY’S CREDIBILITY

Original Reporting

On the Ground

Opinion piece / Thought Leadership

Code License

About Author

ETİKETLERİ ASIN

Languages

BU YAZI...

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)

Çok uzun; Okumak

People Mentioned

inDrive.Tech

STORY’S CREDIBILITY

Original Reporting

On the Ground

Opinion piece / Thought Leadership

Code License

About Author

ETİKETLERİ ASIN

Languages

BU YAZI...

İLGİLİ ÖYKÜLER