AWS Device Farm: הגדרת בדיקות על מכשירים אמיתיים

בדיקות רגרסיה של אפליקציית מובייל על עשרה מכשירים הן כאב ראש ללא חוות מכשירי ענן. יצרנים שונים, גרסאות מערכת הפעלה, רזולוציות מסך — כל בדיקה חייבת להתבצע מקומית או על מכשירים פיזיים במשרד. AWS Device Farm פותר זאת באמצעות מערכת האקוסיסטם של AWS: אותם תפקידי IAM, CLI, ומדיניות גישה. הניסיון שלנו מראה ש-80% מהבעיות בהשקה ראשונה נובעות מאריזה לא נכונה של הבדיקות או מתצורת מאגר מכשירים שגויה. מאמר זה יעזור לכם להימנע מטעויות אלה. הגדרנו את Device Farm עבור יותר מ-30 פרויקטים, וההפחתה הממוצעת בזמן בדיקות הרגרסיה הייתה 70% — מה שאיפשר ללקוחות להפסיק לקנות מכשירים פיזיים ולהתמקד באיכות הקוד.

כיצד להגדיר בדיקות ב-AWS Device Farm?

למה AWS Device Farm במקום BrowserStack או Sauce Labs?

אם הפרויקט שלכם כבר על AWS (CodePipeline, CodeBuild, S3), Device Farm משתלב בצורה חלקה: אין צורך בהתחברות נפרדת, חיוב דרך AWS, ומדיניות IAM מרכזית. עבור חברות עם דרישות שהות נתונים, זה יתרון — המכשירים נמצאים באותם אזורים כמו שאר התשתית. Device Farm תומך ב-APK/IPA ובבדיקות Instrumentation (Espresso) ללא שכבות נוספות. בהשוואה ל-BrowserStack, Device Farm נותן יותר שליטה על מאגר המכשירים, אם כי הממשק פחות אינטואיטיבי.

מה כלול בהגדרה?

סוגי בדיקות: השוואה

כיצד לארוז בדיקות Appium עבור Device Farm?

אריזת בדיקות Appium היא גורם שכיח לכשלים. Device Farm דורש ZIP עם package.json, node_modules, ובדיקות. מבנה עבור WebdriverIO:

tests.zip/ ├── package.json ├── package-lock.json ├── node_modules/ └── test/ └── specs/ └── login.test.js 

תצורת WebdriverIO:

// wdio.conf.devicefarm.js
exports.config = {
  runner: 'local',
  specs: ['./test/specs/**/*.js'],
  capabilities: [{
    platformName: process.env.DEVICEFARM_DEVICE_PLATFORM_NAME,
    'appium:deviceName': process.env.DEVICEFARM_DEVICE_NAME,
    'appium:platformVersion': process.env.DEVICEFARM_DEVICE_OS_VERSION,
    'appium:app': process.env.DEVICEFARM_APP_PATH,
    'appium:automationName': process.env.DEVICEFARM_DEVICE_PLATFORM_NAME === 'iOS' ? 'XCUITest' : 'UiAutomator2',
  }],
  hostname: 'localhost',
  port: 4723,
};

Device Farm מפעיל את שרת ה-Appium אוטומטית; משתנים מועברים אוטומטית.

בדיקות Native: Espresso ו-XCUITest

Espresso רץ מהר יותר מ-Appium מכיוון שהוא פועל באותו תהליך כמו האפליקציה. העלו APK ו-APK לבדיקות דרך AWS CLI:

PROJECT_ARN=$(aws devicefarm create-project --name "MyApp" --query 'project.arn' --output text)
APP_UPLOAD=$(aws devicefarm create-upload --project-arn $PROJECT_ARN --name "app-debug.apk" --type ANDROID_APP --query 'upload.{arn:arn,url:url}' --output json)
APP_URL=$(echo $APP_UPLOAD | jq -r '.url')
APP_ARN=$(echo $APP_UPLOAD | jq -r '.arn')
curl -T app/build/outputs/apk/debug/app-debug.apk "$APP_URL"
TEST_UPLOAD=$(aws devicefarm create-upload --project-arn $PROJECT_ARN --name "app-debug-androidTest.apk" --type INSTRUMENTATION_TEST_PACKAGE --query 'upload.{arn:arn,url:url}' --output json)
TEST_ARN=$(echo $TEST_UPLOAD | jq -r '.arn')
curl -T app/build/outputs/apk/androidTest/debug/app-debug-androidTest.apk "$(echo $TEST_UPLOAD | jq -r '.url')"
aws devicefarm schedule-run --project-arn $PROJECT_ARN --app-arn $APP_ARN --device-pool-arn $POOL_ARN --name "Espresso Run" --test type=INSTRUMENTATION,testPackageArn=$TEST_ARN,filter="com.example.LoginTest"

עבור iOS, השתמשו ב-XCUITest; ארוזו דרך xcodebuild.

מדריך שלב-אחר-שלב להגדרת Device Farm

1. צרו פרויקט Device Farm והגדירו תפקידי IAM עם הרשאות מינימליות (devicefarm:* על הפרויקט).
2. בנו מאגר מכשירים: בחרו פלטפורמה, גרסאות מערכת הפעלה, יצרנים, וסננו לפי AVAILABILITY: HIGHLY_AVAILABLE כדי להימנע מתורים.
3. העלו את האפליקציה (APK/IPA) וחבילת הבדיקות דרך AWS CLI או הקונסולה. ודאו שהבדיקות ארוזות כראוי (ZIP עם תלויות).
4. התחילו ריצת בדיקה, ובחרו את המאגר וסוג הבדיקה (Appium, Espresso, XCUITest).
5. הגדירו אינטגרציית CI/CD (CodePipeline, GitHub Actions) והתראות (Slack, Telegram).

אינטגרציה עם CI/CD

הוסיפו שלב ב-buildspec.yml עבור CodePipeline:

---
phases:
  build:
    commands:
      - ./gradlew assembleDebug assembleAndroidTest
      - APP_ARN=$(aws devicefarm create-upload --project-arn $DEVICE_FARM_PROJECT_ARN --name "app.apk" --type ANDROID_APP --query 'upload.arn' --output text)
      # ... загрузка и запуск
      - aws devicefarm get-run --arn $RUN_ARN --query 'run.result'

תפקיד ה-IAM של CodeBuild חייב לכלול הרשאות devicefarm:* על הפרויקט.

למה בדיקות נכשלות בריצה הראשונה?

שגיאות נפוצות:

• אריזת בדיקות Appium לא נכונה — ZIP ללא node_modules.
• מאגר מכשירים ללא מסנן AVAILABILITY: HIGHLY_AVAILABLE — תורים של שעה.
• משתני סביבה שגויים — Device Farm מעביר את DEVICEFARM_DEVICE_PLATFORM_NAME ואחרים.
• חוסר הרשאות כתיבה ל-S3 עבור ארטיפקטים.

התיעוד הרשמי של AWS ממליץ להשתמש במאגרים זמינים מאוד כדי למזער זמני המתנה.

ניתוח תוצאות

ארטיפקטים נגישים דרך API:

aws devicefarm list-artifacts --arn $JOB_ARN --type FILE --query 'artifacts[*].{name:name,url:url}' --output table 

ארטיפקטים טיפוסיים: Logcat, צילומי מסך, וידאו, פלט מפרט בדיקה. המהנדסים שלנו הגדירו משלוח דוחות אוטומטי ל-Slack או Telegram.

מקרה בוחן: כיצד הגדרת Device Farm חסכה 40 שעות בחודש

לקוח אחד — סטארטאפ פינטק עם אפליקציית Android שנבדקה על 20 מכשירים מקומית. כל ריצת רגרסיה לקחה 8 שעות של עבודה ידנית. לאחר הגדרת Device Farm עם אינטגרציית GitLab CI, הזמן ירד ל-1.5 שעות באוטומציה מלאה. הגדרנו מאגר של 10 מכשירים מקבילים, חיברנו התראות Slack, וייאבנו דוחות ל-S3. העלות של חוות מכשירי הענן התבררה כנמוכה יותר מאשר תחזוקת צי מכשירים פנימי.

המהנדסים שלנו מחזיקים בהסמכות AWS ויש להם ניסיון של 10+ שנים בפיתוח מובייל. אנו מבטיחים שהריצה הראשונה שלכם תצליח תוך 3 ימים מתחילת העבודה.

צרו קשר להערכת פרויקט. הזמינו הגדרת AWS Device Farm וקבלו את הריצה המוצלחת הראשונה שלכם תוך 3 ימים. כל הסקריפטים והתיעוד נשארים אצלכם.

לפרטים נוספים על Device Farm, ראו את התיעוד הרשמי של AWS.