Appium vs چهارچوب بومی: یک مقایسه

توسط کوروش علی آبادی و روحان جانجووا

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

ابزارهای اتوماسیون جایگزین در خارج وجود دارد ، اما برای متن این پست وبلاگ خود را به این برنامه ها و ابزارهای بومی پیش فرض برای iOS و Android محدود می کنیم: به ترتیب XCUITests و Espresso.

Appium:

Appium در چند سال گذشته ابزاری defacto برای اتوماسیون موبایل بوده است و یک تجربه مانند سلنیوم را فراهم می کند. تاکنون این بنا به دلایل مختلف یکی از حرفه ای ترین انتخاب ها بوده است.

  1. اولا این زبان آگونیستیک است ، که با پشتیبانی از طیف گسترده ای از زبان های محبوب همراه است. اگر زبان مورد نظر شما دارای یک مشتری وب سرور است ، می توانید از Appium استفاده کنید. این پایین است به jsonWireProtocol مشترک. این یک راحتی عالی است زیرا به برنامه نویسان تست اجازه می دهد تا ابزار را به سرعت انتخاب کنند. زبانهای پشتیبانی شده شامل Java ، C # ، JavaScript ، Python و یاقوت محدود نمی شوند.
  2. انتخاب و شروع به راحتی بسیار ساده است. مشابه نکته قبلی ، Appium شباهت های زیادی با مدیر وب سلنیوم دارد. فایده این امر این است که اگر برنامه نویسان تست برای نوشتن تست های وب سلنر وب سلنیوم استفاده می کنند ، آنگاه Appium باید نسبتاً ساده باشد و بسیار شهودی باشد.
  3. Appium تست چندین سیستم عامل را از همان پایه کد تست مشابه امکان پذیر می کند. برای افرادی که در یک تیم آزمایش متمرکز یا تیمی فعالیت می کنند که در هر دو سیستم عامل iOS و Android کار می کند ، می تواند میزان کد boilerplate مورد نیاز برای کار با زیرساخت های آزمایش و شبیه ساز ها را کاهش دهد.
  4. علاوه بر این در تجربه برخی از مهندسین تست ما ، پشتیبانی از برنامه های بومی با استفاده از نمایشگرهای وب در Appium نسبت به سایر رقبا بهتر است. پشتیبانی خودکار ارائه شده توسط Appium در هنگام اتوماسیون برنامه های ترکیبی می تواند بسیار ارزشمند باشد.

همچنین استفاده از Appium معایبی نیز دارد:

  1. در تجربه ما ، تست های Appium بسیار کندتر از تست هایی که در XCUITests یا Espresso نوشته شده است
  2. کد آزمون با کد برنامه زندگی نمی کند. اکنون این ممکن است برای بحث برانگیز باشد ، اما ما قاطعانه احساس می کنیم که کد آزمایشی و کد های توسعه باید نزدیک یکدیگر باشند.
  3. برای آزمایش برنامه های متقابل پلت فرم همیشه پیچیدگی فنی درگیر با Appium خواهد بود. یا باید:
  4. 2 مجموعه PageObjects / ScreenObject را حفظ کنید که به یک قرارداد واحد پایبند باشند ، بنابراین می توان آنها را تنها از یک مجموعه آزمایش فراخوانی کرد.
  5. 2 مجموعه تست بنویسید
  6. اطمینان حاصل کنید که توسعه دهندگان از هر شناسه مشابه در هر دو برنامه استفاده می کنند

ابزار بومی:

دو سیستم عامل اصلی برای توسعه برنامه اکنون ابزارهای اتوماسیون UI بسیار رقابتی خود را دارند: XCUITest و Espresso. بلوغ این دو ابزار به طرز چشمگیری بهبود یافته است و در گفتگوی اخیر در WWDC 2017Apple این مسئله را روشن کرده است که آنها در کار روی بهبود ابزارهای UI اتوماسیون خود بسیار فعال هستند.

  1. یک مزیت اساسی برای استفاده از XCUITest و Espresso وجود دارد: آنها توسط ارائه دهندگان سیستم عامل ایجاد شده: Apple و Google. این ابزارها همیشه از منحنی تست های iOS و اندرویدی جلوتر هستند. هر ویژگی جدیدی از Appium در بیشتر موارد در بالای قابلیت های یک ابزار بومی موجود ساخته می شود.
  2. یکی دیگر از مزایای مهم ما این است که کد تست را با کد منبع پروژه خود درج خواهید کرد. شاید این کمی بحث باشد اما ما در پست آینده در مورد این موضوع بحث خواهیم کرد. در حال حاضر ما فقط اعلام خواهیم کرد که ما معتقدیم که شامل کد تست شما در همان پروژه و به همان زبانی که توسعه دهندگان شما استفاده می کنند دارای مزایای بسیار خوبی است. این انگیزه بیشتری برای همکاری در تیم ایجاد می کند و به همه امکان می دهد تا به راحتی در این جنبه توسعه نرم افزار مشارکت کنند.
  3. گاهی اوقات قرار است تجربه اندرویدی با تجربه iOS متفاوت باشد ، با نوشتن تست های خود برای هر سیستم عامل که نیازی نیست چارچوب آزمون خود را برای رسیدگی به این شرایط پیچیده کنید.
  4. بسیار کمتر پوسته پوسته. ابزارهای بومی فقط پوسته پوسته تر هستند. این ممکن است ارتباطی با تعداد کمتری از قطعات متحرک و لایه های ارتباط کمتری بین کد تست و ابزار دقیق داشته باشد ، اما به نظر می رسد تست های نوشته شده با ابزارهای بومی بسیار کمرنگ هستند.
  5. می توانید از یک ابزار بسیار بزرگتر از استفاده از ابزاری مانند Appium استفاده کنید. به عنوان مثال با Android شما هم به کتابخانه UiAutomator و هم به کتابخانه Espresso دسترسی دارید.

اسپرسو:

ابزار تست Android Espresso در گوگل دارای ویژگی های مرتب و خاص خود است که قابل ذکر است.

  1. اسپرسو خیلی سریع است ، ما هرگز اتوماسیون UI چیزی ندیده ایم. مانند Flash اتوماسیون UI است ، هیچ ابزار دیگری به سرعت آن نزدیک نمی شود.
  2. لازم نیست نگران انتظار باشید که اتفاقاتی بیفتد یا کد تست خود را تمام کنید ، زیرا اسپرسو این کار را برای شما انجام داده است ، به استثنای موارد استثنایی. این اساساً شکننده ترین چیز در مورد اتوماسیون UI را از معادله خارج می کند.
  3. اسپرسو رویکرد آزمایش "جعبه خاکستری" را در پیش گرفته است. نه کاملاً سیاه ، نه کاملاً سفید. تستر با داشتن اسپرسو از کنترل بیشتری بر روی برنامه استفاده می کند تا در ابزار جعبه سیاه مانند appium.
  4. Espresso به آزمایش کننده اجازه می دهد تا از ابزارهایی مانند Robolectric استفاده کند ، چارچوبی برای اجرای SDK Android بدون راه اندازی یک شبیه ساز یا وصل کردن یک دستگاه. این بدان معنی است که آزمایشات شما سریعتر شروع می شوند و سریعتر نیز اجرا می شوند.

چارچوبی مشابه Espresso ، همچنین توسط Google ایجاد شده است ، برای آزمایش iOS که ارزش ذکر این را دارد: EarlGrey. ما از آن استفاده نکرده ایم ، اما اگر برخی از مزایای Espresso را در iOS به ارمغان آورد ، به خوبی قابل بررسی است.

در استفاده از ابزارهای آزمایش بومی نیز مضراتی وجود دارد:

  1. اگر در حال تهیه یک برنامه سکوی متقاطع هستید ، در صورت استفاده از ابزاری مانند Appium ، باید دو برابر تعداد آزمایشات را حفظ کنید.
  2. اگر در حال تهیه یک برنامه platform cross هستید ، باید دو زبان را بدانید.
  3. در این روش پیچیدگی بیشتری می تواند دخیل باشد. این یک اثر جانبی از قدرت و دسترسی اضافی است که ابزاری مانند اسپرسو می تواند به آزمایشگر بدهد. به عنوان مثال Espresso بطور خودکار منتظر می ماند تا برنامه ها را با استفاده از IdlingResource در برنامه تحت آزمایش تکمیل کند. با این حال ، در بعضی موارد ، آزمایش کننده باید IdlingResource را به صورت دستی پیاده سازی کند.
  4. با داشتن ابزاری مانند Espresso ، آزمایش کننده می تواند برنامه را به وضعیتی تبدیل کند که شاید از دید کاربر نتواند به آن دسترسی پیدا کند. باز هم ، این طرف دیگر انرژی اضافی است که شما دریافت می کنید.