Appium برای خودکارسازی تست اپلیکیشن‌های موبایل به کار می‌رود؛ یعنی می‌توانید بازکردن برنامه، لمس دکمه‌ها، واردکردن متن و بررسی نتیجه را به اسکریپت بسپارید. این ابزار از اپلیکیشن‌های بومی، هیبریدی و وب موبایل پشتیبانی می‌کند، اما راه‌اندازی و شیوه تعامل با هرکدام یکسان نیست.
برای شروع، بهتر است یک سناریوی کوچک را روی یک پلتفرم اجرا کنید: برنامه باز شود، یک عنصر پیدا شود و نتیجه‌ای مشخص بررسی شود. پس از موفقیت این مسیر، افزودن iOS یا اندروید و گسترش مجموعه تست‌ها ساده‌تر خواهد بود.
Appium چیست و چگونه کار می‌کند؟
Appium یک چارچوب متن‌باز برای اتوماسیون رابط کاربری است. تست‌ها می‌توانند با زبان‌هایی مانند پایتون، جاوا یا جاوااسکریپت نوشته شوند و از طریق پروتکل WebDriver با سرور Appium ارتباط برقرار کنند.
معماری آن سه جزء اصلی دارد:
- کد تست و کتابخانه کلاینت: دستورهایی مانند یافتن عنصر یا لمس دکمه را ارسال می‌کنند.
- سرور Appium: درخواست‌ها را دریافت و به درایور مناسب منتقل می‌کند.
- درایور پلتفرم: با ابزارهای اتوماسیون اندروید یا iOS ارتباط برقرار می‌کند.
برای اندروید معمولاً از درایور UiAutomator2 و برای iOS از XCUITest استفاده می‌شود. در معماری ماژولار Appium، نصب سرور به‌تنهایی کافی نیست؛ درایور موردنیاز را نیز باید جداگانه نصب کنید.
Appium جایگزین تمام انواع تست نیست. تست‌های واحد و API برای بررسی منطق و سرویس‌ها معمولاً سریع‌تر و کم‌هزینه‌ترند. ارزش اصلی Appium، بررسی مسیرهای مهم از دید کاربر و اطمینان از اتصال درست اجزای برنامه است.
پیش‌نیازهای تست اندروید و iOS
پیش از نوشتن تست، محیط اجرا باید بتواند دستگاه را شناسایی کند و ابزارهای پلتفرم بدون خطا کار کنند.
| پیش‌نیاز | اندروید | iOS |
|---|---|---|
| سیستم‌عامل میزبان | ویندوز، لینوکس یا macOS، با ابزارهای سازگار | برای اجرای محلی XCUITest، macOS |
| ابزار توسعه | Android SDK و ابزارهای خط فرمان | Xcode و ابزارهای خط فرمان آن |
| محیط اجرا | شبیه‌ساز یا دستگاه واقعی | شبیه‌ساز یا دستگاه واقعی |
| درایور رایج | UiAutomator2 | XCUITest |
| نکته دستگاه واقعی | فعال‌سازی USB debugging و تأیید اتصال | اعتماد به رایانه و تنظیم امضای WebDriverAgent |
نسخه سازگار Node.js، Java، Android SDK، Xcode و درایورها به نسخه Appium و محیط شما وابسته است. پیش‌نیازهای نسخه انتخابی را بررسی کنید؛ ترکیب تصادفی جدیدترین نسخه همه ابزارها لزوماً بهترین نقطه شروع نیست.
آماده‌سازی اندروید
Android Studio راه مناسبی برای نصب SDK و ساخت شبیه‌ساز است. ابزارهای Platform Tools، از جمله adb، باید نصب و در مسیر اجرایی سیستم قابل دسترس باشند. متغیرهای محیطی SDK و Java را نیز مطابق نیاز ابزارها تنظیم کنید.
پس از روشن‌کردن شبیه‌ساز یا اتصال گوشی، دستور adb devices باید دستگاه را نمایش دهد. اگر وضعیت دستگاه unauthorized باشد، پیام تأیید دسترسی را روی گوشی بررسی کنید.
برای تست برنامه خودتان، فایل APK سازگار با دستگاه یا شبیه‌ساز را آماده کنید. در مسیر معمول نصب با Appium، فایل AAB جایگزین مستقیم APK نیست و ابتدا باید خروجی قابل نصب مناسبی تهیه شود.
آماده‌سازی iOS
برای اجرای محلی تست‌های XCUITest به مک و Xcode نیاز دارید. ابتدا مطمئن شوید شبیه‌ساز موردنظر از داخل Xcode اجرا می‌شود.
خروجی برنامه باید با مقصد اجرا سازگار باشد: بیلد مخصوص دستگاه واقعی معمولاً روی شبیه‌ساز قابل اجرا نیست. برای شبیه‌ساز معمولاً از خروجی .app مناسب استفاده می‌شود؛ برای دستگاه واقعی نیز بیلد باید شرایط نصب و امضای لازم را داشته باشد.
Appium در این مسیر از WebDriverAgent برای ارتباط با رابط کاربری استفاده می‌کند. روی دستگاه واقعی، تنظیم تیم توسعه، امضای کد و مجوزهای دستگاه ممکن است ضروری باشد. فعال‌کردن Developer Mode نیز به نسخه سیستم‌عامل و شیوه اجرا بستگی دارد.
نصب سرور و درایورهای Appium
پس از نصب نسخه سازگار Node.js و npm، می‌توانید سرور و درایورها را نصب کنید:
npm install -g appium
appium driver install uiautomator2
# برای محیط اجرای iOS روی macOS
appium driver install xcuitest
appium driver list --installed
appium
برای شروع فقط درایور پلتفرم موردنظر را نصب کنید. فرمان آخر سرور را اجرا می‌کند؛ آدرس و پورت واقعی را از خروجی آن بخوانید. در راه‌اندازی معمول، کلاینت به http://127.0.0.1:4723 متصل می‌شود.
اگر از آموزش‌های قدیمی استفاده می‌کنید، مراقب مسیر /wd/hub باشید. این مسیر در تنظیمات پیش‌فرض نسل‌های جدید Appium الزاماً وجود ندارد و باید با تنظیم سرور هماهنگ باشد.
سرور را برای آزمایش محلی در دسترس شبکه عمومی قرار ندهید. Appium می‌تواند روی دستگاه عملیات اجرایی انجام دهد؛ دسترسی شبکه و قابلیت‌های امنیتی آن باید آگاهانه تنظیم شوند.
تعریف نشست با Capabilities
هر اجرای تست با ساخت یک نشست یا Session آغاز می‌شود. هنگام ساخت نشست، مشخص می‌کنید چه پلتفرمی، چه درایوری، کدام دستگاه و چه برنامه‌ای استفاده شود.
تنظیمات اصلی عبارت‌اند از:
platformName: پلتفرم هدف، مانندAndroidیاiOS.appium:automationName: نام درایور، مانندUiAutomator2یاXCUITest.appium:udid: شناسه دستگاه یا شبیه‌ساز هدف.appium:app: مسیر فایل برنامه قابل نصب.appium:deviceName: نام دستگاه؛ به‌تنهایی همیشه انتخاب دقیق دستگاه را تضمین نمی‌کند.
در استاندارد W3C، تنظیمات اختصاصی Appium پیشوند appium: دارند. کلاس‌های Options در کلاینت‌های رسمی معمولاً این قالب را مدیریت می‌کنند.
اگر برنامه از قبل نصب شده است، می‌توانید به‌جای فایل نصب، شناسه آن را معرفی کنید. در اندروید، بسته به مسیر راه‌اندازی، appPackage و appActivity اهمیت دارند؛ در iOS معمولاً bundleId استفاده می‌شود. این مقادیر باید از پروژه یا خروجی واقعی برنامه استخراج شوند.
اجرای اولین تست اندروید با پایتون
برای نمونه، از کلاینت پایتون Appium و pytest استفاده می‌کنیم. بهتر است وابستگی‌ها را در محیط مجازی پروژه نصب کنید:
python -m pip install Appium-Python-Client pytest
نمونه زیر فرض می‌کند برنامه یک عنصر با Accessibility ID برابر login_button دارد. مسیر فایل، شناسه دستگاه و شناسه عنصر نمونه‌اند و باید جایگزین شوند.
from appium import webdriver
from appium.options.android import UiAutomator2Options
from appium.webdriver.common.appiumby import AppiumBy
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
def test_login_button_is_visible():
options = UiAutomator2Options()
options.platform_name = "Android"
options.automation_name = "UiAutomator2"
options.udid = "emulator-5554"
options.app = "/absolute/path/to/app.apk"
driver = webdriver.Remote(
"http://127.0.0.1:4723",
options=options,
)
try:
button = WebDriverWait(driver, 15).until(
EC.visibility_of_element_located(
(AppiumBy.ACCESSIBILITY_ID, "login_button")
)
)
assert button.is_displayed()
finally:
driver.quit()
فایل را مثلاً با نام test_smoke.py ذخیره کنید و با pytest test_smoke.py اجرا کنید. پیش از اجرا، سرور Appium و دستگاه باید آماده باشند.
این تست فقط نمایش یک عنصر را بررسی می‌کند؛ تست کامل ورود نیست. برای سناریوی ورود باید داده آزمون، ورود اطلاعات، اقدام کاربر و نشانه معتبر موفقیت را نیز تعریف کنید.
در نمونه از انتظار صریح استفاده شده است. به‌جای توقف ثابت با sleep، تست تا آماده‌شدن عنصر منتظر می‌ماند. مقدار مهلت انتظار هم باید متناسب با محیط تنظیم شود.
انتقال همین مسیر به iOS
منطق تست می‌تواند مشابه بماند، اما تنظیمات نشست و بعضی Locatorها تغییر می‌کنند. برای iOS از کلاس XCUITestOptions استفاده کنید و این مقادیر را متناسب با محیط قرار دهید:
| تنظیم | مقدار موردنیاز |
|---|---|
platformName |
iOS |
automationName |
XCUITest |
udid |
شناسه شبیه‌ساز یا دستگاه واقعی |
platformVersion |
در صورت نیاز، نسخه سیستم‌عامل هدف |
app |
مسیر بیلد سازگار با مقصد |
bundleId |
برای سناریوی اجرای برنامه نصب‌شده |
اشتراک کد بین پلتفرم‌ها به معنی یکسان‌بودن کامل تست‌ها نیست. ساختار صفحه، دیالوگ مجوزها، صفحه‌کلید و شیوه پیمایش ممکن است متفاوت باشند.
بهتر است مراحل کسب‌وکاری، مانند «ورود با حساب معتبر»، مشترک باشند؛ اما جزئیات تعامل با صفحه در لایه جداگانه هر پلتفرم قرار بگیرند.
پیدا کردن عناصر با Appium Inspector
Appium Inspector ابزاری برای مشاهده درخت عناصر، بررسی ویژگی‌ها و امتحان Locatorهاست. با معرفی آدرس سرور و تنظیمات نشست، می‌توانید رابط برنامه را بررسی کنید. برای جلوگیری از تداخل، نشست Inspector و اجرای تست را آگاهانه مدیریت کنید.
برای انتخاب Locator، این ترتیب معمولاً نقطه شروع مناسبی است:
- Accessibility ID پایدار: مناسب برای قرارداد مشترک میان توسعه و تست.
- شناسه منبع در اندروید: در صورت وجود شناسه ثابت و متمایز.
- Locatorهای اختصاصی پلتفرم: مانند Android UIAutomator یا iOS Predicate.
- XPath: زمانی که گزینه ساده‌تر و پایدارتری ندارید.
XPath همیشه اشتباه نیست، اما مسیرهای طولانی وابسته به ساختار صفحه با تغییر رابط کاربری شکننده می‌شوند. متن نمایشی نیز ممکن است با ترجمه یا ویرایش محتوا تغییر کند.
از تیم توسعه بخواهید شناسه‌های تست را پایدار نگه دارد، بدون اینکه اطلاعات دسترس‌پذیری موردنیاز کاربران مخدوش شود.
برنامه‌های هیبریدی و WebView
در برنامه هیبریدی ممکن است برای تعامل با محتوای وب، از Context بومی به WebView تغییر مسیر دهید. نمایش Context قابل استفاده به تنظیمات برنامه و قابلیت بازرسی محتوای وب وابسته است.
در اندروید، سازگاری ابزار اتوماسیون مرورگر با نسخه WebView یا Chrome اهمیت دارد. بنابراین، موفقیت تست عناصر بومی به معنی آماده‌بودن خودکار بخش وب نیست.
خطاهای رایج و مسیر عیب‌یابی
عیب‌یابی را از پایین‌ترین لایه شروع کنید: دستگاه، درایور، نشست و سپس عناصر صفحه.
| نشانه خطا | نخستین بررسی |
|---|---|
| دستگاه پیدا نمی‌شود | خروجی adb devices یا فهرست شبیه‌سازهای Xcode |
| نشست ساخته نمی‌شود | نصب درایور، سازگاری نسخه‌ها و تنظیمات نشست |
| برنامه نصب یا باز نمی‌شود | مسیر فایل، نوع بیلد، امضا و شناسه برنامه |
| عنصر پیدا نمی‌شود | صفحه فعلی، Locator، Context و زمان انتظار |
| WebDriverAgent اجرا نمی‌شود | لاگ Xcode، امضا و دسترسی دستگاه |
| اتصال به سرور شکست می‌خورد | فعال‌بودن سرور، آدرس، پورت و مسیر اتصال |
لاگ سرور Appium معمولاً نشان می‌دهد شکست پیش از بازشدن برنامه رخ داده یا هنگام تعامل با آن. هنگام خطا، تصویر صفحه و در صورت نیاز درخت عناصر را ذخیره کنید؛ اما مراقب داده‌های شخصی و اطلاعات حساب‌ها باشید.
چگونه تست‌های پایدار بسازیم؟
با چند مسیر مهم مانند بازشدن برنامه، ورود و ثبت یک عملیات اصلی شروع کنید. اتوماسیون همه صفحات در ابتدای کار، هزینه نگهداری را پیش از روشن‌شدن الگوی درست افزایش می‌دهد.
برای پایداری بیشتر:
- هر تست را با وضعیت مشخص و داده کنترل‌شده آغاز کنید.
- وابستگی تست‌ها به ترتیب اجرا را حذف کنید.
- اطلاعات حساب و رمز را در کد یا مخزن عمومی قرار ندهید.
- رفتار پاک‌سازی داده و نصب مجدد برنامه را صریح تعیین کنید؛ گزینه‌هایی مانند
noResetرا بدون شناخت اثرشان فعال نکنید. - Locatorها و تعاملات صفحه را از منطق سناریو جدا کنید.
- اجرای مجدد تست شکست‌خورده را جایگزین بررسی علت نکنید.
شبیه‌ساز برای توسعه سریع مفید است، اما برای قابلیت‌های وابسته به سخت‌افزار و رفتار واقعی سیستم، تست روی دستگاه واقعی نیز لازم می‌شود. Appium به‌تنهایی ابزار سنجش جامع کارایی نیست؛ سرعت اجرای اسکریپت را با سرعت تجربه کاربر یکسان ندانید.
سوالات متداول
آیا برای تست با Appium باید کد برنامه را تغییر داد؟
همیشه نه؛ بسیاری از برنامه‌ها با خروجی قابل نصب تست می‌شوند. بااین‌حال، شناسه‌های پایدار و تنظیمات مناسب WebView می‌توانند قابلیت تست و پایداری را بهتر کنند.
آیا می‌توان تست iOS را روی ویندوز اجرا کرد؟
کلاینت تست می‌تواند روی ویندوز باشد، اما اجرای XCUITest به میزبان macOS مجهز به Xcode نیاز دارد. اتصال به مک راه‌دور یا سرویس دستگاه ابری، این محدودیت زیرساختی را برطرف می‌کند.
آیا یک اسکریپت برای اندروید و iOS کافی است؟
بخش‌هایی از منطق قابل اشتراک‌اند، اما تنظیمات دستگاه، Locatorها و تعاملات اختصاصی معمولاً متفاوت‌اند. جداسازی لایه صفحه از سناریو، اشتراک کد را عملی‌تر می‌کند.
برای شروع، شبیه‌ساز بهتر است یا گوشی واقعی؟
برای یادگیری و رفع خطاهای اولیه، شبیه‌ساز معمولاً ساده‌تر است. سپس مسیرهای مهم را روی دستگاه واقعی بررسی کنید، به‌ویژه اگر برنامه به قابلیت‌های سخت‌افزاری وابسته است.
قدم بعدی
اولین هدف را کوچک نگه دارید: یک دستگاه قابل شناسایی، یک نشست موفق و یک بررسی معتبر روی صفحه. وقتی این مسیر پایدار شد، تنظیمات و وابستگی‌ها را ثبت کنید و سناریوی بعدی را بیفزایید. مجموعه‌ای کوچک از تست‌های قابل اعتماد، از تعداد زیادی تست شکننده ارزشمندتر است.
