কিভাবে প্রতিদিন মোবাইল ডিভাইসে 5000+ পরীক্ষা চালাবেন; ইনড্রাইভের প্লেবুক থেকে (পর্ব 2)

এই নিবন্ধের প্রথম অংশে , আমরা বর্ণনা করেছি কিভাবে দ্রুত এবং সহজে অ্যাপিয়াম এবং সেলেনয়েড ব্যবহার করে অ্যান্ড্রয়েডে UI পরীক্ষা চালানোর জন্য একটি পরিকাঠামো তৈরি করা যায়। আমরা কীভাবে iOS-এ UI পরীক্ষা চালু করার প্রক্রিয়াকে অন্তর্ভুক্ত করেছি তা ব্যাখ্যা করার জন্য আমরা আমাদের গল্প চালিয়ে যাচ্ছি।

GGR দিয়ে স্কেলিং

একটি হোস্টের মধ্যে সমান্তরাল কর্মপ্রবাহের সর্বাধিক সংখ্যা তার সংস্থান দ্বারা সীমাবদ্ধ। সুতরাং, আমাদের একাধিক হোস্টকে একটি ক্লাস্টারে একত্রিত করার জন্য একটি সরঞ্জামের প্রয়োজন ছিল। এর জন্য, আমরা Aerokube-এর লোকদের থেকে Go Grid Router (GGR) ব্যবহার করি। ডকুমেন্টেশনের বর্ণনার উপর ভিত্তি করে, GGR হল একটি লোড ব্যালেন্সার যা মাপযোগ্য এবং অত্যন্ত উপলব্ধ সেলেনিয়াম ক্লাস্টার তৈরি করতে ব্যবহৃত হয়।

পরীক্ষা সহ প্রকল্পটি ব্যবহৃত প্রক্রিয়ার অংশ হিসাবে GGR-এ একটি প্রশ্ন চালায়। এটি তার কনফিগারেশনে নির্দিষ্ট করা সেলেনয়েড প্যারামিটারগুলি পোল করে এবং ব্যবহৃত প্ল্যাটফর্ম, বিনামূল্যে প্রবাহের প্রাপ্যতা এবং প্রতিটি সেলেনয়েডের পূর্বনির্ধারিত নির্দিষ্ট ওজনের উপর ভিত্তি করে তাদের মধ্যে লোড বিতরণ করে।

GGR এবং GGR UI স্থাপন করা সহজ:

• ডকার ইনস্টল করুন।
• GGR কনফিগারেশন ফাইলের জন্য একটি ডিরেক্টরি তৈরি করুন mkdir -p /etc/grid-router/quota ।
• একটি user.htpasswd ফাইল তৈরি করুন $ htpasswd -bc /etc/grid-router/users.htpasswd test test-password ।
• একটি কোটা ফাইল তৈরি করুন যেখানে আপনি হোস্ট হিসাবে নিয়োজিত সেলেনয়েডের ঠিকানা নির্দিষ্ট করুন:

 $ 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 কন্টেইনার চালান:

  
  

 docker run -d \ --name ggr \ -v /etc/grid-router/:/etc/grid-router:ro \ --net host aerokube/ggr:latest-release \ -listen=:4445 -guests-allowed

• পরীক্ষামূলক প্রকল্পে, অ্যাপিয়াম পোর্টকে চলমান GGR-এর পোর্টে পরিবর্তন করুন:

  
  

 val driver = AndroidDriver(URL("http://localhost:4445/wd/hub"), capabilities)

• GGR UI কন্টেইনার চালান:

  
  

 docker run -d \ --name ggr_ui \ -p 8888:8888 \ -v /etc/grid-router/quota:/etc/grid-router/quota:ro \ aerokube/ggr-ui:latest-release

• Selenoid UI কন্টেইনার চালান যেখানে আমরা selenoid-uri মাধ্যমে GGR UI পোর্ট পাস করি:

  
  

 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 UI এখন GGR-এর সাথে সংযুক্ত সমস্ত Selenoid ক্লাস্টারের স্থিতি প্রদর্শন করবে।

এখন, আমরা iOS এ পরীক্ষা চালানোর দিকে এগিয়ে যাই

iOS-এ UI পরীক্ষা চালানোর জন্য আমরা আমাদের নিজস্ব ম্যাক মিনি ফার্ম ব্যবহার করি। খামারটিকে একইভাবে ডিকমিশন করা কিন্তু কার্যকরী ম্যাকবুক থেকে একত্রিত করা যেতে পারে। বিকল্পভাবে, তারা ভাড়া করা যেতে পারে. প্রতিটি হোস্টে নিম্নলিখিতগুলি ইনস্টল করা দরকার:

• Appium (Appium 2.x ব্যবহার করা আবশ্যক যখন কেউ iOS≥16 এর সাথে কাজ করে)।
• এক্সকোড।

কিছু প্রাথমিক সমস্যা

আমরা অ্যান্ড্রয়েড পরীক্ষা চালানোর জন্য ব্যবহৃত কাঠামোর প্রতিলিপি করতে পারিনি কারণ আমরা ডকার পাত্রে iOS সিমুলেটর চালানোর উপায় খুঁজে পাইনি। একটি বিকল্প যা আমরা বিবেচনা করেছি তা হল Docker-OSX চালানো, কিন্তু আমরা OS X নিরাপত্তা গবেষণার সাথে সম্পর্কহীন কোনো উদ্দেশ্যে এটির ব্যবহারের বৈধতা নিয়ে সন্দেহের মধ্যে পড়েছিলাম। তাই, আমরা অন্য পথে যাওয়ার সিদ্ধান্ত নিয়েছি।

পুনরাবৃত্তি #1: GGR→Appium

আমরা পূর্বে তৈরি করা GGR কনফিগারেশন ফাইলে iOS পরীক্ষার জন্য Selenoid হোস্ট হিসাবে Appium (পোর্ট 4723) যোগ করেছি:

 <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>

এই ধরনের ক্ষেত্রে, iOS স্কিম এই মত দেখায়:

এই পুনরাবৃত্তিতে ব্যবহৃত কাঠামোটি কার্যকর। সমস্যাটি হল, এই ক্ষেত্রে, আমরা প্রতিটি ম্যাক মিনিতে শুধুমাত্র একটি ওয়ার্কফ্লোতে পরীক্ষা চালাতে পারি, যা অযথা। এছাড়াও, ক্লাস্টারটি Selenoid UI এ প্রদর্শিত হবে না।

পুনরাবৃত্তি #2: GGR→Selenoid→Appium

সেলেনয়েড আপনাকে কেবল পাত্রের চেয়ে বেশি কাজ করতে দেয়। উপরের সমস্যাগুলি আইওএস পরীক্ষা চালানোর সময় সেলেনয়েড ব্যবহার করার সিদ্ধান্তকে জানিয়েছিল, যদিও একটি এক্সিকিউটেবল ফাইল হিসাবে:

• সেলেনয়েড ডাউনলোড করুন ( amd64 / arm64 )।

• একটি browsers.json কনফিগারেশন ফাইল তৈরি করুন।

• কনফিগারেশন ফাইলে অ্যাপিয়াম এবং স্টার্টআপ সেটিংস নির্দিষ্ট করতে ভুলবেন না:

  
  

 { "iPhone 14": { "default": "16.2", "versions": { "16.2": { "image": ["appium", "--log-timestamp", "--log-no-colors", ...] } } } }

• সেলেনয়েড ফাইলটি চালানোর অনুমতি দিন। আমাদের ক্ষেত্রে, আমরা chmod 755 ব্যবহার করেছি।

• টার্মিনালের মাধ্যমে সেলেনয়েড চালান। আমরা নিম্নলিখিত পরামিতিগুলি ব্যবহার করেছি selenoid -conf ~/browsers.json -disable-docker -capture-driver-logs -service-startup-timeout 4m -session-attempt-timeout 4m -timeout 6m -limit 2

  • নির্দিষ্ট টাইমআউটগুলি প্রয়োজনীয় কারণ ক্লাউড স্টোরেজ থেকে অ্যাপটি ডাউনলোড করার এবং সিমুলেটর চালু করার জন্য স্ট্যান্ডার্ড টাইমআউট যথেষ্ট নাও হতে পারে।
  • সর্বাধিক সংখ্যক চলমান সিমুলেটর সেট করতে -limit প্যারামিটার ব্যবহার করা হয়েছিল। এটি ভবিষ্যতে GGR দ্বারা ব্যবহৃত রেফারেন্স মান। হোস্টের কর্মক্ষমতা প্যারামিটার সেট করার জন্য একটি গাইড হিসাবে ব্যবহৃত হয়।
  • আপনি Selenoid ডকুমেন্টেশনে স্টার্টআপ সেটিংস সম্পর্কে আরও পড়তে পারেন।

• যদি প্রয়োজন হয়, হঠাৎ সিস্টেম পুনরায় চালু হওয়ার ক্ষেত্রে সেলেনয়েড অটোরান করতে প্রতিটি ম্যাক মিনিতে একটি PLIST ফাইল তৈরি করা যেতে পারে।

  
  

এখন, ক্লাস্টারের প্রক্রিয়াটি এইরকম দেখাচ্ছে:

এই পদ্ধতির সাহায্যে, আমরা আংশিকভাবে Selenoid UI কার্যকারিতা এবং একই হোস্টে একাধিক প্রবাহ জুড়ে পরীক্ষা চালানোর ক্ষমতা অর্জন করি।

নেতিবাচক দিকটি হল, প্রতিটি ম্যাক মিনিতে, আপনাকে একটি সিমুলেটর তৈরি করতে এবং UUID এবং পোর্ট অ্যাসাইনমেন্ট নির্দিষ্ট করে অ্যাপিয়ামের সাথে লিঙ্ক করতে ম্যানুয়ালি অনেকগুলি রুটিন কাজ সম্পাদন করতে হবে। আপনি যদি পরে একটি নতুন iOS সংস্করণে আপগ্রেড করতে চান তবে এটি একটি সমস্যা হয়ে উঠতে পারে।

পুনরাবৃত্তি #3: GGR→Selenoid→Bash→Appium

আমাদের একটি বড় ম্যাক মিনি ফার্ম রয়েছে যা সময়ের সাথে সাথে বাড়তে থাকবে। এটি মাথায় রেখে, আমরা স্কেলিং সহজ করার উপায় খুঁজছিলাম যাতে আমাদের হাতে সিমুলেটর তৈরি করতে না হয় এবং তারপরে সেগুলিকে অ্যাপিয়ামের সাথে সংযুক্ত করতে হয়। পূর্ববর্তী স্কিমা স্থানান্তরিত হলে, অ্যাপিয়াম এবং সিমুলেটরগুলির দীর্ঘ জীবনকাল থাকতে পারে, যা অপ্রত্যাশিত পরিণতির দিকে নিয়ে যেতে পারে।

একটি সমাধানের জন্য অনুসন্ধান করে, আমরা আবিষ্কার করেছি যে একটি ব্যাশ স্ক্রিপ্ট সেলেনয়েড কনফিগারেশন ফাইলে হোস্ট হিসাবে নির্দিষ্ট করা যেতে পারে:

 { "iPhone 14": { "default": "16.2", "versions": { "16.2": { "image": ["~/bin/config/start_appium.sh", "iPhone 14"] } } } }

এটি আমাদের মত দেখাচ্ছে:

 #!/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

যদি স্ক্রিপ্টটি ব্যবহার করা হয়, উল্লিখিত ক্ষমতা এবং অ্যাপিয়াম স্টার্টআপ সেটিংসের প্রতি গভীর মনোযোগ দিন। এগুলি এখানে সেট আপ করা হয়েছে অনুমান করে যে Appium 2.x চালানোর জন্য ব্যবহৃত হয় - Appium 1.x-এর জন্য বিক্রেতাকে সক্ষমতার মধ্যে নির্দিষ্ট করার প্রয়োজন নেই এবং --base-pat নির্দিষ্ট করার কোনো বিকল্প নেই।

স্ক্রিপ্ট সমান্তরালভাবে চলমান সিমুলেটরগুলির সমস্যার সমাধান করে:

• যখন একাধিক অ্যাপিয়াম সরাসরি একটি ম্যাক মিনি থেকে GGR-এর সাথে সংযুক্ত থাকে, তখন এমুলেটরগুলির সাথে একটি সমস্যা দেখা দেয় , কারণ আপনি অভিন্ন UDID-এর সাথে একই এমুলেটর চালাতে পারবেন না। আপনাকে প্রতিবার ইউডিআইডি ম্যানুয়ালি ডুপ্লিকেট এবং হার্ডকোড করতে হবে। (উদাহরণস্বরূপ, যদি আপনার iOS সংস্করণ বা সিমুলেটর মডেল পরিবর্তন করতে হয়।)

• দুর্বল মাপযোগ্যতা । প্রতিবার অ্যাপিয়ামকে ম্যানুয়ালি চালানোর প্রয়োজন, এবং পোর্ট এবং সিমুলেটরগুলির সাথে দ্বন্দ্বের জন্য এটি নিয়মিত পরীক্ষা করুন।

  
  

সেলেনয়েডের ব্যবহার এই প্রক্রিয়াটিকে একটি একক স্ক্রিপ্টে সরল করা সম্ভব করে যা একটি একক হোস্টের মধ্যে একাধিক অ্যাপিয়াম + সিমুলেটর জোড়ার মধ্যে দ্বন্দ্ব তৈরি করে না। এটি অ্যাপিয়াম চালু করে এবং সেলেনয়েড থেকে একটি অনুরূপ সংকেত পাওয়ার সময় এটিকে হত্যা করে এবং এটি স্টার্টআপে সিমুলেটরগুলিকে গতিশীলভাবে ক্লোন করে এবং সেশন শেষ হওয়ার পরে সেগুলি মুছে দেয়।

আমরা যে প্রক্রিয়াটি তৈরি করেছি তা এইরকম দেখাচ্ছে:

এরপরে, আমরা অ্যান্ড্রয়েড এবং আইওএস স্ট্রাকচারগুলিকে একত্রিত করে, স্থাপন করা GGR-এর কনফিগারেশন ফাইলে প্রতিটি ম্যাক মিনির সেলেনয়েড ঠিকানাগুলি যুক্ত করি:

নীচের লাইন সারাংশ

একত্রিত পরিকাঠামো আমাদের উভয় প্ল্যাটফর্মে 36টি ওয়ার্কফ্লো জুড়ে প্রতি ঘন্টায় প্রায় 500টি UI পরীক্ষা চালানোর অনুমতি দেয়। GitHub অ্যাকশনে ওয়ার্কফ্লো ব্যবহার করে অ্যান্ড্রয়েড পরীক্ষার জন্য একটি নতুন হোস্টের সংযোজন সম্পূর্ণরূপে স্বয়ংক্রিয় হতে পারে এবং এতে প্রায় দুই মিনিট সময় লাগে। খুব অদূর ভবিষ্যতে, আমরা একটি ম্যাক মিনিতেও সেলেনয়েড ক্লাস্টারের স্থাপনার স্বয়ংক্রিয়তার পরিকল্পনা করছি।

রাস্তার আরও নিচে, আমরা সমস্ত প্রক্রিয়াকে একত্রিত করতে এবং কোনো MacOS ব্যবহারের নিয়ম ভঙ্গ না করেই তাদের মোতায়েন করা সহজ করতে Linux-এর সাথে Mac mini-এ Docker-OSX কন্টেইনার চালানোর চেষ্টা করতে চাই। আপনার যদি কোনো সম্পর্কিত অভিজ্ঞতা থাকে, তাহলে আমরা মন্তব্যে তা শেয়ার করতে চাই।

ইভান গ্রিগোরিয়েভ পোস্ট করেছেন।