آشنایی با دستورات سفارشی و پیشرفته موبایل در WebdriverIO

تست اپلیکیشن‌های موبایل و برنامه‌های وب موبایل چالش‌های خاص خود را دارد، به‌ویژه هنگام مواجهه با تفاوت‌های خاص پلتفرم بین اندروید و iOS. در حالی که Appium انعطاف‌پذیری لازم برای مدیریت این تفاوت‌ها را فراهم می‌کند، اما اغلب نیاز دارید که عمیقاً وارد مستندات پیچیده و وابسته به پلتفرم (اندروید، iOS) و دستورات شوید. این می‌تواند نوشتن اسکریپت‌های تست را زمان‌بر، مستعد خطا و دشوار برای نگهداری کند.

برای ساده‌سازی این فرآیند، WebdriverIO دستورات سفارشی و پیشرفته موبایل را معرفی می‌کند که مخصوصاً برای تست وب موبایل و برنامه‌های بومی طراحی شده‌اند. این دستورات پیچیدگی‌های API‌های اساسی Appium را انتزاع می‌کنند و به شما امکان می‌دهند اسکریپت‌های تست مختصر، بدیهی و مستقل از پلتفرم بنویسید. با تمرکز بر سهولت استفاده، ما هدف داریم بار اضافی را هنگام توسعه اسکریپت‌های Appium کاهش دهیم و به شما امکان دهیم به راحتی برنامه‌های موبایل را خودکارسازی کنید.

چرا دستورات سفارشی موبایل؟

۱. ساده‌سازی API‌های پیچیده

برخی از دستورات Appium، مانند حرکات یا تعاملات عناصر، شامل نحو طولانی و پیچیده هستند. برای مثال، اجرای یک عمل فشار طولانی با API اصلی Appium نیاز به ساخت دستی یک زنجیره action دارد:

const element = $('~Contacts')

await browser
    .action( 'pointer', { parameters: { pointerType: 'touch' } })
    .move({ origin: element })
    .down()
    .pause(1500)
    .up()
    .perform()

با دستورات سفارشی WebdriverIO، همان عمل می‌تواند با یک خط کد بیانگر انجام شود:

await $('~Contacts').longPress();

این به طور چشمگیری کد بویلرپلیت را کاهش می‌دهد و اسکریپت‌های شما را تمیزتر و قابل فهم‌تر می‌کند.

۲. انتزاع بین پلتفرمی

برنامه‌های موبایل اغلب نیاز به مدیریت خاص پلتفرم دارند. به عنوان مثال، اسکرول در برنامه‌های بومی بین اندروید و iOS تفاوت قابل توجهی دارد. WebdriverIO این شکاف را با ارائه دستورات یکپارچه مانند scrollIntoView() که بدون توجه به پیاده‌سازی زیربنایی، به طور یکپارچه در سراسر پلتفرم‌ها کار می‌کنند، از بین می‌برد.

await $('~element').scrollIntoView();

این انتزاع اطمینان می‌دهد که تست‌های شما قابل حمل هستند و نیازی به شاخه‌بندی مداوم یا منطق شرطی برای حساب کردن تفاوت‌های سیستم عامل ندارند.

۳. افزایش بهره‌وری

با کاهش نیاز به درک و پیاده‌سازی دستورات سطح پایین Appium، دستورات موبایل WebdriverIO به شما امکان می‌دهد به جای مبارزه با نکات ظریف خاص پلتفرم، بر روی تست عملکرد برنامه خود تمرکز کنید. این به ویژه برای تیم‌هایی با تجربه محدود در خودکارسازی موبایل یا کسانی که به دنبال تسریع چرخه توسعه خود هستند، مفید است.

۴. سازگاری و قابلیت نگهداری

دستورات سفارشی یکنواختی را به اسکریپت‌های تست شما می‌آورند. به جای داشتن پیاده‌سازی‌های متفاوت برای اقدامات مشابه، تیم شما می‌تواند بر دستورات استاندارد و قابل استفاده مجدد تکیه کند. این نه تنها کدبیس را قابل نگهداری‌تر می‌کند، بلکه موانع را برای آموزش اعضای جدید تیم کاهش می‌دهد.

چرا برخی دستورات موبایل را بهبود می‌دهیم؟

۱. افزودن انعطاف‌پذیری

برخی دستورات موبایل برای ارائه گزینه‌ها و پارامترهای اضافی که در API‌های پیش‌فرض Appium در دسترس نیستند، بهبود یافته‌اند. به عنوان مثال، WebdriverIO منطق تلاش مجدد، زمان‌بندی و توانایی فیلتر کردن webview‌ها با معیارهای خاص را اضافه می‌کند که کنترل بیشتری بر سناریوهای پیچیده را امکان‌پذیر می‌سازد.

// مثال: سفارشی‌سازی فواصل تلاش مجدد و زمان‌بندی برای تشخیص webview
await driver.getContexts({
  returnDetailedContexts: true,
  androidWebviewConnectionRetryTime: 1000, // تلاش مجدد هر ۱ ثانیه
  androidWebviewConnectTimeout: 10000,    // زمان‌بندی پس از ۱۰ ثانیه
});

این گزینه‌ها به سازگاری اسکریپت‌های خودکارسازی با رفتار پویای برنامه بدون کد بویلرپلیت اضافی کمک می‌کنند.

۲. بهبود قابلیت استفاده

دستورات پیشرفته، پیچیدگی‌ها و الگوهای تکراری موجود در API‌های اصلی را انتزاع می‌کنند. آنها به شما اجازه می‌دهند اقدامات بیشتری را با خطوط کد کمتری انجام دهید، که منحنی یادگیری را برای کاربران جدید کاهش می‌دهد و اسکریپت‌ها را برای خواندن و نگهداری آسان‌تر می‌کند.

// مثال: دستور پیشرفته برای تغییر زمینه با عنوان
await driver.switchContext({
  title: 'My Webview Title',
});

در مقایسه با روش‌های پیش‌فرض Appium، دستورات پیشرفته نیاز به مراحل اضافی مانند بازیابی دستی زمینه‌های موجود و فیلتر کردن آنها را حذف می‌کنند.

۳. استانداردسازی رفتار

WebdriverIO اطمینان می‌دهد که دستورات پیشرفته در سراسر پلتفرم‌هایی مانند اندروید و iOS به طور سازگار رفتار می‌کنند. این انتزاع بین پلتفرمی نیاز به منطق شاخه‌بندی شرطی بر اساس سیستم‌عامل را کاهش می‌دهد و منجر به اسکریپت‌های تست قابل نگهداری‌تر می‌شود.

// مثال: دستور اسکرول یکپارچه برای هر دو پلتفرم
await $('~element').scrollIntoView();

این استانداردسازی کدبیس‌ها را ساده می‌کند، به ویژه برای تیم‌هایی که تست‌ها را در چندین پلتفرم خودکار می‌کنند.

۴. افزایش قابلیت اطمینان

با ترکیب مکانیسم‌های تلاش مجدد، پیش‌فرض‌های هوشمند و پیام‌های خطای دقیق، دستورات پیشرفته احتمال تست‌های متزلزل را کاهش می‌دهند. این بهبودها اطمینان می‌دهند که تست‌های شما در برابر مسائلی مانند تأخیر در راه‌اندازی webview یا حالت‌های گذرای برنامه مقاوم هستند.

// مثال: تعویض webview پیشرفته با منطق تطبیق قوی
await driver.switchContext({
  url: /.*my-app\/dashboard/,
  androidWebviewConnectionRetryTime: 500,
  androidWebviewConnectTimeout: 7000,
});

این اجرای تست را قابل پیش‌بینی‌تر و کمتر مستعد شکست ناشی از عوامل محیطی می‌کند.

۵. افزایش قابلیت‌های اشکال‌زدایی

دستورات پیشرفته اغلب متادیتای غنی‌تری را بازمی‌گردانند که اشکال‌زدایی سناریوهای پیچیده را آسان‌تر می‌کند، به ویژه در برنامه‌های هیبریدی. به عنوان مثال، دستوراتی مانند getContext و getContexts می‌توانند اطلاعات دقیقی درباره webview‌ها برگردانند، از جمله عنوان، URL و وضعیت قابل مشاهده بودن.

// مثال: بازیابی متادیتای دقیق برای اشکال‌زدایی
const contexts = await driver.getContexts({ returnDetailedContexts: true });
console.log(contexts);

این متادیتا به شناسایی و حل مشکلات سریع‌تر کمک می‌کند و تجربه اشکال‌زدایی کلی را بهبود می‌بخشد.

با بهبود دستورات موبایل، WebdriverIO نه تنها خودکارسازی را آسان‌تر می‌کند، بلکه با ماموریت خود برای ارائه ابزارهایی به توسعه‌دهندگان که قدرتمند، قابل اعتماد و بدیهی برای استفاده هستند، همسو می‌شود.

---

برنامه‌های هیبریدی

برنامه‌های هیبریدی محتوای وب را با عملکرد بومی ترکیب می‌کنند و نیاز به مدیریت تخصصی در طول خودکارسازی دارند. این برنامه‌ها از webview برای رندر کردن محتوای وب در یک برنامه بومی استفاده می‌کنند. WebdriverIO روش‌های پیشرفته‌ای برای کار موثر با برنامه‌های هیبریدی ارائه می‌دهد.

درک Webview‌ها

یک webview یک مؤلفه شبیه مرورگر است که در یک برنامه بومی جاسازی شده است:

• اندروید: Webview‌ها بر اساس Chrome/System Webview هستند و ممکن است شامل چندین صفحه (مشابه تب‌های مرورگر) باشند. این webview‌ها برای خودکارسازی تعاملات به ChromeDriver نیاز دارند. Appium می‌تواند به طور خودکار نسخه مورد نیاز ChromeDriver را بر اساس نسخه System WebView یا Chrome نصب شده روی دستگاه تعیین کند و اگر هنوز در دسترس نباشد، به طور خودکار آن را دانلود کند. این رویکرد سازگاری بی‌درنگ را تضمین می‌کند و تنظیم دستی را به حداقل می‌رساند. به مستندات Appium UIAutomator2 مراجعه کنید تا بدانید چگونه Appium به طور خودکار نسخه صحیح ChromeDriver را دانلود می‌کند.
• iOS: Webview‌ها توسط Safari (WebKit) پشتیبانی می‌شوند و با شناسه‌های عمومی مانند WEBVIEW_{id} شناسایی می‌شوند.

چالش‌های برنامه‌های هیبریدی

1. شناسایی webview صحیح در میان گزینه‌های متعدد.
2. بازیابی متادیتای اضافی مانند عنوان، URL یا نام بسته برای بهتر شدن زمینه.
3. مدیریت تفاوت‌های خاص پلتفرم بین اندروید و iOS.
4. تغییر به زمینه صحیح در یک برنامه هیبریدی به صورت قابل اعتماد.

دستورات کلیدی برای برنامه‌های هیبریدی

1. getContext

زمینه فعلی جلسه را بازیابی می‌کند. به طور پیش‌فرض، مانند روش getContext در Appium رفتار می‌کند اما می‌تواند هنگامی که returnDetailedContext فعال است، اطلاعات زمینه دقیقی ارائه دهد. برای اطلاعات بیشتر به getContext مراجعه کنید.

2. getContexts

لیست دقیقی از زمینه‌های موجود را برمی‌گرداند و روش contexts در Appium را بهبود می‌بخشد. این کار شناسایی webview صحیح برای تعامل را بدون فراخوانی دستورات اضافی برای تعیین عنوان، url یا bundleId|packageName فعال آسان‌تر می‌کند. برای اطلاعات بیشتر به getContexts مراجعه کنید.

3. switchContext

به یک webview خاص بر اساس نام، عنوان یا url تغییر می‌دهد. انعطاف‌پذیری بیشتری را فراهم می‌کند، مانند استفاده از عبارات منظم برای تطبیق. برای اطلاعات بیشتر به switchContext مراجعه کنید.

ویژگی‌های کلیدی برای برنامه‌های هیبریدی

1. متادیتای دقیق: بازیابی جزئیات جامع برای اشکال‌زدایی و تغییر زمینه قابل اعتماد.
2. سازگاری بین پلتفرمی: رفتار یکپارچه برای اندروید و iOS، مدیریت بی‌درنگ نکات ظریف خاص پلتفرم.
3. منطق تلاش مجدد سفارشی (اندروید): تنظیم فاصله‌های تلاش مجدد و زمان‌بندی برای تشخیص webview.

نکات و محدودیت‌ها

• اندروید متادیتای اضافی مانند packageName و webviewPageId را ارائه می‌دهد، در حالی که iOS بر روی bundleId تمرکز دارد.
• منطق تلاش مجدد برای اندروید قابل سفارشی‌سازی است اما برای iOS قابل اجرا نیست.
• چندین مورد وجود دارد که iOS نمی‌تواند Webview را پیدا کند. Appium قابلیت‌های اضافی مختلفی برای appium-xcuitest-driver برای یافتن Webview ارائه می‌دهد. اگر فکر می‌کنید که Webview پیدا نشده است، می‌توانید یکی از قابلیت‌های زیر را تنظیم کنید:
  • appium:includeSafariInWebviews: زمینه‌های وب Safari را به لیست زمینه‌های موجود در طول تست برنامه بومی/webview اضافه می‌کند. این مفید است اگر تست Safari را باز کند و نیاز به تعامل با آن داشته باشد. پیش‌فرض false است.
  • appium:webviewConnectRetries: حداکثر تعداد تلاش‌های مجدد قبل از تسلیم شدن در تشخیص صفحات webview. تأخیر بین هر تلاش مجدد 500 میلی‌ثانیه است، پیش‌فرض 10 تلاش است.
  • appium:webviewConnectTimeout: حداکثر مقدار زمان به میلی‌ثانیه برای انتظار برای تشخیص یک صفحه webview. پیش‌فرض 5000 میلی‌ثانیه است.

برای مثال‌های پیشرفته و جزئیات، به مستندات API موبایل WebdriverIO مراجعه کنید.

---

مجموعه در حال رشد دستورات ما نشان‌دهنده تعهد ما به دسترس‌پذیر و ظریف کردن خودکارسازی موبایل است. چه در حال انجام حرکات پیچیده باشید یا با عناصر برنامه بومی کار کنید، این دستورات با فلسفه WebdriverIO برای ایجاد یک تجربه خودکارسازی بی‌درنگ همسو هستند. و ما اینجا متوقف نمی‌شویم—اگر ویژگی‌ای وجود دارد که مایلید ببینید، از بازخورد شما استقبال می‌کنیم. لطفاً درخواست‌های خود را از طریق این لینک ارسال کنید.