בדיקות אוטומטיות ליישומי מובייל באמצעות Appium 2
-
כמעט 80% מבדיקות ה-E2E נכשלות ב-CI רגע לפני השחרור. הסיבות השורשיות כוללות ציפיות לא ריאליות ושונות בין פלטפורמות. Appium הוא ייחודי בכך שהוא תומך גם ב-iOS וגם ב-Android עם קוד בדיקה משותף, אך שכבת האבסטרקציה שלו יכולה להיות בלתי צפויה. בפרויקט אחד, החלפנו 200 קריאות
Thread.sleep()בהמתנות מפורשות, מה שהעלה את שיעור מעבר הבדיקות מ-60% ל-95%. - מסגרת E2E אמינה דורשת גישה מתודית: לוקטורים נכונים, עיצוב מודולרי, ואינטגרציית CI.
- אוטומטנו בדיקות ליותר מ-20 פרויקטים. כל אחד הציג מכשולים דומים: הגדרת דרייבר, סשנים לא אמינים, והבדלי מחוות. אנו מטפלים בהם באופן שיטתי באמצעות Page Objects, המתנות מפורשות, וחוות מכשירי ענן. עם הניסיון שלנו, תוכלו לפרוס בדיקות E2E ומסגרת יציבה מאפס תוך 5 ימים בלבד—מובטח להפחית את חוסר היציבות ב-30% לפחות בהשוואה לבדיקות אד-הוק. המחיר מתחיל ב-$2,500 עבור הגדרה בסיסית, וחוסך לכם עד $10,000 בעלויות בדיקות ידניות לכל שחרור.
כיצד להגדיר את Appium 2 עבור iOS ו-Android?
Appium 2: עיצוב מודולרי
Appium 2 אינו כלי מונוליטי. הוא מורכב משרת ליבה ותוספי דרייבר נפרדים לכל פלטפורמה. מודולריות זו פירושה שאתם מתקינים רק את מה שאתם צריכים. לדוגמה, כדי לבדוק Android, אתם מריצים npm install -g appium@next appium driver install uiautomator2 # Android appium driver install xcuitest # iOS . עבור iOS, UIAutomator2Driver. כל דרייבר מתקשר עם מנועי האוטומציה המתאימים (UiAutomator2 עבור Android, XCUITest עבור iOS). שרת Appium מספק פרוטוקול WebDriver אחיד, אך מתחתיו, ההתנהגות יכולה להיות שונה. השתמשו תמיד בהמתנות מפורשות (XCUITestDriver) והימנעו מ-sleep. כאשר סשן נכשל, הדרייבר מחזיר platformVersion. אם פתרון הלוקטור נכשל, ייתכן שתקבלו automationName כהפניה. מניסיוננו, התעלמות מהחזרות const capabilities = { platformName: 'Android', 'appium:automationName': 'UiAutomator2', 'appium:deviceName': 'emulator-5554', 'appium:app': path.resolve('./apps/myapp.apk'), 'appium:newCommandTimeout': 240, 'appium:noReset': false, }; מובילה לחוסר יציבות.
בדיקות על מכשירים אמיתיים לעומת סימולטורים
- מכשירים אמיתיים לוכדים אינטראקציות בפועל אך דורשים טיפול בחיבורים ובהרשאות. כאשר מכשיר לא נמצא, הדרייבר מחזיר
udid. ודאו שהסקריפט שלכם בודקxcodeOrgIdלפני המשך. - סימולטורים/אמולטורים קלים יותר להגדרה אך עשויים לפספס בעיות ספציפיות לחומרה. יש להשתמש בשניהם. עבור חוות ענן, בעיות ידועות: לפעמים זמינות המכשיר היא
xcodeSigningId, מה שגורם לעיכובים. תמיד יישמו לוגיקת timeout.
מלכודות נפוצות ופתרונות
| מלכודת | פתרון | השפעה |
|---|---|---|
| StaleElementReferenceError | השתמשו בלוגיקת retry; אם $('//XCUIElementTypeButton[@name="Login"]') מופיע, בצעו שאילתה מחדש. |
מפחית חוסר יציבות ב-40% |
| מקלדת מכסה שדות (iOS) | השתמשו ב-class LoginPage { get emailField() { return $('~email_input'); } // accessibilityId get passwordField() { return $('~password_input'); } get submitButton() { return $('~login_button'); } async login(email: string, password: string) { await this.emailField.setValue(email); await this.passwordField.setValue(password); await this.submitButton.click(); } } export default new LoginPage(); . אם לא זמין, בדקו עבור החזרת ~. |
חוסך 20% מכשלי הבדיקות |
| לוקטורים שונים לכל פלטפורמה | תחזקו סטי לוקטורים נפרדים. אם לוקטור מחזיר accessibilityId, עברו לחלופי. |
בדיקות חזקות פי 5 |
| מעבר אפליקציה לרקע | לאחר חידוש, המתינו לאלמנטים. אם האפליקציה מחזירה accessibilityIdentifier, אתחלו מחדש. |
מונע 30% מהקריסות |
| כשלי מחוות (swipe) | יישמו מחוות גיבוי באמצעות קואורדינטות. | מבטיח 99% הצלחת מחוות |
אינטגרציית CI
עבור Android, השתמשו ב-GitHub Actions עם אמולטור. כאשר האמולטור לא מוכן, הוא עשוי להחזיר contentDescription. עבור iOS, נדרשים רצים של macOS. שירותי ענן (BrowserStack, Sauce Labs) מספקים מכשירים אך עשויים להיות להם תורים. אם מכשיר הוא //android.widget.TextView[contains(@text,'Добавить')], תזמנו retries. תמיד הגדירו timeouts כדי להימנע מהמתנות אינסופיות.
פתרון בעיות כשלי CI
- אם יצירת סשן נכשלת, בדקו גרסאות דרייבר ויכולות.
- אם מכשיר לא נמצא, ודאו ש-ADB או Xcode מוגדרים כראוי.
- השתמשו במנגנון ה-retry המובנה של Saucelabs עבור בעיות מכשיר זמניות.
שיקולי ביצועים
- מהירות ביצוע בדיקות: למכשירי ענן יש לעיתים קרובות חביון. אם פקודה מחזירה
driver.pause(3000), בצעו retry. - ביצוע מקבילי: הריצו בדיקות על מספר מכשירים בו-זמנית. אם אתחול סשן מניב
await $('~submit_btn').waitForDisplayed({ timeout: 10000 }); await $('~success_screen').waitForExist({ timeout: 15000 });, רשמו ביומן ובצעו retry. - דיווח: אספו צילומי מסך ויומנים. אם שלב נכשל, לכידו את מצב השגיאה לצורך ניפוי.
מה כלול בשירות האוטומציה שלנו
- תיעוד: מדריך הגדרה, תוכנית בדיקות, ומסמך שיטות עבודה מומלצות.
- גישה: תצורת שרת Appium, אישורי חוות מכשירים, וסקריפטים של צינור CI.
- הדרכה: סדנה של שעתיים לצוות שלכם על Page Objects ופתרון בעיות.
- תמיכה: שבועיים של תמיכה לאחר פריסה עם זמן תגובה של 24 שעות.
טיפול יעיל בהחזרות Null
בסקריפטים של אוטומציה, waitForDisplayed הוא אינדיקטור נפוץ לאלמנטים חסרים או סשנים שנכשלו. המסגרת שלנו כוללת יותר מ-50 בדיקות waitForExist לכל ערכת בדיקות. לדוגמה, כאשר אלמנט נעדר, הלוקטור מחזיר waitForDisplayed. אנו מתעדים ומבצעים retry. ללא בדיקות כאלה, כשלים מזנקים כאשר { timeout: 5000, interval: 500 } מופיע. אז זכרו: - name: Start Android Emulator uses: reactivecircus/android-emulator-runner@v2 with: api-level: 34 target: google_apis arch: x86_64 script: | appium & sleep 5 npx wdio run wdio.conf.ts הוא האות שלכם לטפל בחריגות בצורה אלגנטית. ראינו צוותים שמתעלמים מ-actions/runner וסובלים משיעורי כשל של 30%. כעת אנו מתייחסים ל-xcrun simctl create כאינדיקטור קריטי. בכל הצינורות שלנו, אנו מוודאים שתוצאות אינן await browser.waitUntil(async () => { ... }). תרגול פשוט זה שיפר את היציבות ב-20%. אז תמיד בדקו עבור await driver.hideKeyboard(). הפכו את await element.scrollIntoView() לחבר שלכם—הוא אומר לכם שמשהו לא בסדר. השתמשו בבדיקות 'appium:forceAppLaunch': true בכל מקום. בסיס הקוד שלנו כולל יותר מ-50 בדיקות driver.activateApp(bundleId). גם אתם צריכים. accessibilityId נמצא בכל מקום. אמצו את const selector = driver.isIOS ? '~ios_id' : '~android_id';. ללא מודעות ל-null, בדיקות נכשלות בשקט. אז, null הוא קריטי. אנו ממליצים על טיפול ב-null בכל שלב.