در این مقاله به معرفی Selenium می پردازیم و نحوه ی استفاده از آن را در انجام تست های مبتنی بر وب بررسی می کنیم.در پایان مقاله مزایا و معایب این روش نیز مورد بررسی قرار می گیرد.

حدودا ده سال از معرفی Selenium می گذرد و امروزه به جرات می توان گفت که Selenium محبوب ترین ابزار open source  برای تست پروژه ها است. دلایل محکمی برای میزان بالای محبوبیت آن وجود دارد.

Selenium علاوه بر رایگان و  open source   بودن، دارای قابلیت های گسترده و قوی و همچنین سازگار با انواع مرورگر ها است . اگر یک متغیر را در کد تغییر بدهید، همان کدی که یک بار آن را ویرایش می کنید، برای همه مرورگرها قابل استفاده است . اگر قصد اجرای برنامه در Mac و تغییر یکی از متغیرها را داشته باشید ، کد نهایی به سادگی در Safari برای شما اجرا خواهد شد. جامعه ی برنامه نویسان و توسعه دهندگان Selenium اغلب آنلاین هستند و شما نیازی به login کردن برای ارتباط با آن ها ندارید، بنابراین  با یک جستجوی ساده در Google به راحتی می توانید پاسخ پرسش هایتان را دریافت کنید. همچنین هر سال دو کنفرانس در دو منطقه ی مختلف برگزار می شود. اگر سوال و یا مشکلی در استفاده از Selenium دارید، ممکن است شخص دیگری نیز به دنبال همین سوال و یا مشکل باشد، بنابراین سوال ها و مشکلات خودتان را بنویسید و پاسخ هایتان را دریافت کنید.

شروع کار با Selenium ساده است، و همچنین این ابزار در حال توسعه ی قابلیت هایش در حوزه ی hard-to-click object ها است . این ابزار یک موفقیت طولانی و پایدار را با استفاده از ابزارو الگوها در حوزه ی مدیریت و نحوه کار با نتایج آزمایش ها(test results) برای خودش ایجاد کرده است. اما هنوز چالش های زیادی بر سر راه این تکنولوژی وجود دارد.

SmartBear Sofware به تازگی یک کتاب الکترونیکی جدید منتشر کرده است که بر روی تست وب و Selenium در سال 2016 تمرکز دارد. اگر به تازگی کار با Selenium را شروع کرده اید، می توانید در این کتاب راهکار های مفیدی پیدا کنید.

پایدار باشید

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

اگر از زاویه ی دیگری به این موضوع نگاه کنیم: این تست ها در آغاز نامناسب هستند و با گذشت زمان نامناسب تر نیز می شوند. اگر ما از این نامناسب بودن آن ها چشم پوشی کنیم و آن را به عنوان یک موضوع فرعی در نظر بگیریم و بر روی نتایج روزانه و تست های جدید تمرکز کنیم، مواردی را خواهیم دید که چندان مرتب و سازماندهی شده نیستند. یک روز یک ایمیل دریافت می کنید که ادعا می کند همه ی تست های مهم با موفقیت انجام شده اند و همه چیز مرتب است. روز بعد ، می فهمید که دو سوم از تست ها با شکست مواجه شده اند و اینطور به نظر می رسد که محصول به کلی نابود شده است .  وقتی از پایه نگاه می کنیم می بینیم که برخی اختلال ها در codebase وجود دارد و این اختلال ها به طور کلی ناهنجاری هایی را ایجاد کرده است.

این نتایج به هم ریخته موجب کاهش اعتماد به نفس و کارآیی در سیستم ها (مرورگر) و همچنین افراد می شود.

دو نکته ی مهم برای سودمندی بررسی های UI وجود دارند: طراحی تست های خوب و پایداری .

بیایید در مورد گرفتن نتایج منسجم از Test Suite با هم صحبت کنیم

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

زمان بندی

زمان بندی یکی از مواردی است که ما به صورت معمول به آن توجه نمی کنیم، مگر این که اوضاع، واقعا نامناسب پیش رود. به عنوان مثال فرض کنید در سایت Amazon.com هستیم و می خواهیم تعدادی کتاب بخریم و کارها کند پیش می روند ،ممکن است کمی غرولند کنیم، و یا این که از کمبود سرعت اینترنت شکایت کنیم ، ولی در نهایت کتاب هایی که لازم داریم را خواهیم خرید. Script های مربوط به WebDriver ها این مشکل را نادیده نخواهند گرفت و به محض این که صفحه در زمان مشخص آماده بارگزاری نباشد، با شکست مواجه خواهند شد.

یک تست WebDriver معمولی ، خیلی روال گرا است :

-به Amazon می رود

-در کادر مربوط به جستجو رشته ی مورد نظر را وارد می کند

-کلید جستجو را فشار می دهد

-بر روی book link کلیک می کند

Add to cart را کلیک می کند.

تست ها در این مرحله معمولا دچار مشکل می شوند زیرا همه ی رخدادها در فاصله بین action ها (اتفاقات) روی می دهند.-به عنوان مثال داده ها و اطلاعات بین کامپیوتر و سرور در حال جابجایی هستند، تصاویر بارگذاری می شوند، المان های صفحه اجرا شده و به نمایش درمی آیند. اگر WebDriver ما یک کتاب را انتخاب کند و سپس به سرعت سعی کند تا بر روی دکمه ی Add to Cart کلیک کند، عملیات با شکست مواجه خواهد شد. Script نمی داند که یک دکمه آماده برای کلیک شدن است و یا این که یک فیلد می تواند تایپ شود، بنابراین ما مجبور هستیم تا صبر کنیم.

WebDriver روش های کمی برای متوقف کردن موقت script در وسط اجرا دارد. آسان ترین و البته بدترین راه ، استفاده از explicit wait( وقفه آشکار) است.این وقفه زمانی اتفاق می افتد که شما به script می گویید که برای مدتی از زمان مثلا 15 ثانیه متوقف بماند.  explicit wait ها مشکلات آشکار را پنهان می کنند. بسیاری از اوقات وقفه ها با مشکل مواجه می شوند و زمان بیشتری به برنامه داده می شود به امید این که برنامه در تلاش بعدی ، با موفقیت انجام شود. در نهایت ما زمان کافی را برای بارگزاری کامل صفحه بر روی script  ها صرف کرده ایم . اما تا چه زمانی باید صبر کنیم؟ اگر مراقب این وقفه های آشکار نباشیم،  می توانند باعث مشکلات اجرایی و پایین آمدن راندمان برنامه شوند.

راهکار هوشمندانه تر در استفاده از وقفه ها این است که آن ها را بر روی المانی قرار بدهیم که می خواهیم در مرحله بعد استفاده کنیم. WebDriver این وقفه های آشکار را فراخوانی می کند. با ذخیره سازی این وقفه ها در یک پشته می توانیم شانس خودمان را برای بالابردن پایداری صفحه افزایش بدهیم. بعد از این که به صفحه مورد نظر هدایت شدیم، (از طریق جستجوی یک کتاب خاص و یا کلیک کردن بر روی یک لینک) اصولا برای ظاهر شدن لینک add to cart صبر می کنیم. ممکن است این کار کمی خسته کننده و افراطی به نظر برسد ولی حتی وقتی این کار ها را انجام می دهیم، باز هم بررسی ها به دلیل مشکل نرم افزاری با شکست مواجه می شوند. دلیل این شکست حاضر نبودن صفحه نیست.

شی ها

شی ها بخش دیگری از پایداری صفحه به شمار می آیند که ممکن است کمی شما را فریب بدهند. اغلب افراد می دانند که یک پیشرفت چشمگیری در انطباق و سازگاری متدهای یافتن شی وجود دارد. کلیک کردن و یا نوشتن بر اساس موقعیت پیکسلی (pixel location) خیلی بد است ، اگر شما هم کارتان را اینگونه انجام می دهید، بهتر است کمی صبر کنید و روش بهتری برای تست کردن نرم افزارتان پیدا کنید. بعد از این روش ، ما XPath را داریم که شما به WebDriver اعلام می کنید که دقیقا در چه نقطه ای از صفحه DOM بر اساس path (مسیر ) باید کلیک اتفاق بیفتد. این روش، کمی بهتر است، تست شما شکست نخواهد خورد زیرا مرورگر حالا می تواند تغییر اندازه بدهد که این رویداد برای ما بسیار مناسب است، ولی حرکت دادن یک دکمه در یک فریم جدید ما را با مشکل مواجه خواهد کرد. برنده ی حقیقی و آشکار بین این روش ها جستجو با استفاده از یک المان تغییر ناپذیر ID است . جستجو با استفاده از ID که مثل driver.findElement(By.id(“myButton”)).click() خواهد بود ، تمامی نقاط صفحه ی وب را برای یافتن آن المان می گردد.

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

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

استراتژی استفاده

بررسی های WebDriver  بر خلاف unit test ها و تست هایی که بر روی API اجرا می شوند، فضای کمی اشغال می کنند. مگر این که شما بدون سرور اقدام به اجرای آن ها کنید ، در این حالت به محض این که بر روی دکمه ی اجرا کلیک کنید یک نمونه جدید از مرورگر برای شما باز می شود و script ها کنترل صفحه کلید و ماوس شما را به دست خواهند گرفت. این روش می تواند برای اجرای script های شخصی مفید باشد ، زیرا شاید شما بخواهید بدانید دقیقا در کدام نقطه از برنامه با شکست مواجه می شوید و یا به دنبال نکاتی باشید که در حوزه ی وظایف کاری script نیست، ولی داشتن یک استراتژی برای اموری فراتر از این حرف ها لازم است.

ساده ترین روش، اجرای تمامی بررسی ها در آخرین نسخه در دسترس برنامه است که این کار و قت و  توجه های مورد نیاز خودش را می طلبد.

روش دیگر این است که شاید شما نیاز به اجرای همه ی بررسی ها در یک مدت زمان کوتاه نداشته باشید. در این مورد به تست های بازگشتی فکر می کنیم که می توانند بر اساس نیاز شما فعالیت کنند. برخی اوقات نیز تنها چیزی که نیاز داریم یک سری تست است تا بتواند اطلاعات سریع و دقیقی از روند کار برنامه و تغییرات آن را به ما بدهد.

 مجموعه های تست بزرگتر زمان زیاد تری نیاز دارند و از سرعت بالاتری نیز برخوردار هستند. موازی سازی (Parallelization) بر روی چندین ماشین در یک زمان واحد اجرا می شوند و همه ی امور را سرعت می بخشند. اگر این کار Headless انجام شود، دو برابر به افزایش سرعت کمک می کند.  این سرعت اضافی بخاطر trade off ناشی از این روش است. تست های Headless بدون بازکردن مرورگر اجرا می شوند. اجرا کننده ی تست (test runner) به صورت مخفی این تست را در پس زمینه ی کار اجرا می کند، در همین زمان WebDriver در حال شبیه سازی کلیک ها است و دکمه دقیقا به صورتی فشرده می شود که شما در ساختار script نوشته اید. ریسکی که در این زمینه وجود دارد این است که شما از برخی ویژگی هایی که استفاده از یک مرورگر واقعی به ما می دهد، بی بهره می مانید.

یک تست headless ممکن است یک کلیک را بر روی یک date picker شبیه سازی کند و مقداری را بدون هیچ گونه مشکلی برگرداند، در همین زمان یک script که مسئول انجام کلیک بر روی مرورگر است ممکن است به دلیل تداخل با قبلی، یک خطای javascript بدهد. افزایش سرعت که حاصل به کارگیری این روش است، می تواند باعث کاهش قدرت و ضعف توانایی پیدا کردن bug ها شود.

خطر های موجود

Selenium می تواند برای کاربران وسوسه کننده باشد زیرا به افزایش سرعت کمک زیادی می کند. مشکلات زمانی پدید می آیند که دو، شش و یا نه ماه می گذرد و نتایج تست ها پایدار نیستند و معماری پایه نامناسب است.

افراد زیادی سعی می کنند استراتژی های مربوط به تست ها را با خودکارسازی و WebDriver  توسعه بدهند ولی در طولانی مدت با شکست مواجه می شوند. 

به عبارت دیگر کار کردن با Selenium می تواند تا حدودی مبهم باشد. اگر به قواعد و استراتژی های این تکنولوژی توجه کنیم و آن ها را به کار بگیریم می تواند تا میزان زیادی کار را برای ما آسان کند .