تیستن جامعه مهندسین تست نرم‌افزار ایران
نوشته های مرتبط
چکیده: در این پست، ما در مورد تعدادی از Best Practiceهای سلنیوم برای اتوماسیون تست سلنیومی بحث می‌کنیم که ممکن است به شما در توسعه Test Suiteها یا Test Caseهای خوش طرح و البته مقیاس پذیر کمک کنند.
در طول کار خود در تست اتوماتیک با استفاده سلنیوم، با افراد زیادی روبرو شده‌ام که از پایداری و اطمینان اتوماسیون تست خود شکایت دارند. در بیشتر موارد، منطق مورد استفاده در اجرای Test Caseها مناسب بود، اما شیوه طراحی و Scalability(مقیاس‌پذیری) نگران کننده می‌نمود.
پس از مدتها کار با چارچوب سلنیوم، فهمیدم که رویکرد “یک سایز برای همه” در مورد اتوماسیون تست سلنیومی صدق نمی‌کند. اگرچه هیچ قاعده سرانگشتی برای طراحی و توسعه تست‌های اتوماتیک مقیاس‌پذیر وجود ندارد، اما اصول خاصی وجود دارد که باید هنگام نوشتن تست‌ها با استفاده از چارچوب سلنیوم رعایت کنید. این اصول می‌توانند ” Best Practiceهای سلنیوم” باشند.
در این پست، ما در مورد تعدادی از Best Practiceهای سلنیوم برای اتوماسیون تست سلنیومی بحث می‌کنیم که ممکن است به شما در توسعه Test Suiteها یا Test Caseهای خوش طرح و البته مقیاس پذیر کمک کنند.
صرف نظر از زبانی که برای اتوماسیون تست با سلنیوم استفاده می‌کنید، این موارد Best Practiceهای ارزشمند سلنیوم هستند.
- استفاده از Design Patternها و اصولی مانند Page Object Model(POM)
هنگام نوشتن اسکریپت‌های تست اتوماتیک در سلنیوم، باید نگهداشت‌پذیری(Maintainability) و مقیاس‌پذیری(Scalability) را در نظر بگیرید. این دو موضوع در صورتی ممکن خواهند شد که تغییرات در UI صفحه وب، به حداقل تغییر(یا حتی عدم تغییر) در Test Script منجر شود. فرض کنید اسکریپت‌ها به درستی نگهداری نمی‌شوند، مثلا اسکریپت‌های مختلف از یک Web Element یکسان در کد خود استفاده می‌کنند، در این حالت، هر زمان که تغییری در آن Web Element ایجاد شود، شما مجبور به تغییر در چند Test Script خواهید بود.
اینجاست که Page Objectها، به عنوان یک الگوی محبوب در اتوماسیون UI وب، وارد عمل می‌شوند. استفاده از POM باعث افزایش نگهداشت‌پذیری و کاهش تکرار کدنویسی می‌شود. در POM، یک مخزن متمرکزِ Object برای کنترل در یک صفحه وب ایجاد شده است. صفحه وب به عنوان یک کلاس جداگانه اجرا می‌شود. از این رو، هر صفحه وبی که تحت تست قرار می‌گیرد، و یا به نوعی در تست باید به آن سر بزنیم، یک کلاس مربوط به خود را خواهد داشت.
این امر منجر به سهولت نگهداشت می‌شود، زیرا اسکریپت‌های اتوماسیون سلنیومی شما، دیگر مستقیماً با عناصر وب موجود در صفحه ارتباط برقرار نمی‌کنند. در عوض، یک لایه جدید یا عنوان Page Object بین کد تست و Web Elementهای عمل کننده در صفحه وب، قرار می‌گیرد.
علاوه بر افزایش نگهداشت‌پذیری، استفاده از POM، در اتوماسیون تست سلنیومی به کاهش اندازه کد نیز کمک می‌کند. زیرا از این پس شما می‌توانید از متدهای Page Object که خود یک کلاس است، در چندین اسکریپت اتوماتیک تست سلنیوم مجدداً استفاده نمایید.
بهره‌گیری از POM یکی از Best Practiceهای سلنیوم است که می‌تواند مزایای زیر را برای شما به ارمغان آورد:
- بهبود نگهداشت تست.
- به حداقل رساندن تغییرات کد به دلیل بروزرسانی در UI محصول.
- افزایش بازاستفاده‌پذیری(Reusability) در کد.
- تسهیل مدلسازی و تجسم صفحه وبِ تحت تست.
- استفاده از BDD Framework به همراه Selenium
Behavior Driven Development، که به BDD معروف است، یک رویکرد توسعه رایج است که به نوشتن Test Caseهای به زبان انگلیسی ساده (Gherkin) کمک می‌کند. این بدان معناست که همراه با توسعه دهندگان و تسترها، هر شخصی با حداقل دانش فنی(یا بدون آن)، می‌تواند در توسعه تست‌ها شرکت کند.
چارچوب‌های BDD در پر کردن خلا میان افراد Businessای و افراد فنی کمک می‌کند. زیرا همه آنها فرصت کار برای افزایش تست‌ها و تولید تست‌های جدید را دارند، و این باعث می‌شود، که تولید تست انحصارا در اختیار تعداد معدودی از نیروهای فنی نماند. فایل‌های Gherkin ایجاد شده برای تست BDD شامل ترکیبی از Featureها، Stepها و سناریوها به همراه Keywordهای مربوط به Gherkin مانند Given, When, Then و غیره است. فرمت Feature Fileها و Keywordهای مورد استفاده بدون توجه به چارچوب BDD استفاده شده، یکسان است. این امر باعث می‌شود که انتقال از یک چارچوب BDD به چارچوب دیگر آسان‌تر باشد. چرا که منحنی یادگیری در این وضعیت بسیار کم است.
از آنجا که افراد Businessای و فنی در یک صفحه هستند، به بهبود کیفیت محصول کمک می‌شود، آنچنانکه تست‌ها بر توصیه‌های فنی و Businessای تکیه می‌کنند. تست‌های BDD در مقایسه با تست‌های TDD بیشتر قابل استفاده هستند، زیرا تغییر در مشخصات Business یا مشخصات Feature، شامل حداقل تغییرات در Featureها و سناریوهای مربوط به BDD می‌شود. زمانیکه با TDD مقایسه می‌کنیم، تست‌های BDD ماندگاری بیشتری دارند، چرا که این تست‌ها با استفاده از مشخصات Feature و Business ساخته می‌شوند. این یکی از ضروری‌ترین Best Practiceهای سلنیوم است که در آن وجود دارد. برخی از چارچوب‌های محبوب BDD عبارتند از:Cucumber ، Behave ، SpecFlow .
- پیروی از ساختارِ دایرکتوریِ واحد
هنگام کار بر روی تست‌هایی که از چارچوب سلنیوم استفاده می‌کنند، تمرکز بر نگهداشت‌پذیری کد تست ضروریست. یک پروژه استاندارد می‌تواند از پوشه های Src و Test تشکیل شود. پوشه Src می‌تواند شامل زیر شاخه‌های فرعی باشد که حاوی Page Objectها، توابع Helper و فایل(های) حاوی اطلاعات مکان یاب(Locator) وب است که در سناریوهای تست استفاده می‌شود. پوشه Test می‌تواند شامل پیاده‌سازی تست(Test Implementation) واقعی باشد.
در مورد ساختار دایرکتوری برای اتوماسیون تست سلنیوم، ما قاعده استانداردی نداریم. با این حال، Best Practiceهای سلنیوم به ما توصیه می‌کنند که یک ساختار دایرکتوری داشته باشیم که اجرای تست را از چارچوب اتوماسیون تست جدا می‌کند. این امر به سازماندهی بهتر کد تست کمک خواهد کرد.
- برای پارامتریزه کردن از Data Driven Testing
یک وب سایت(یا برنامه وب) باید در برابر ترکیبات مختلف مرورگرها، دستگاه‌ها و ترکیبات سیستم عامل(همه این موارد یعنی چندین Data Set) تست شود. Hard Code کردن مقادیر تستی در اسکریپت‌های تست اتوماتیک یک راهکار مقیاس پذیر نیست.
راهکار بهتر برای استفاده از پارامترها، دستیابی به اتوماسیون تست Data Driven با سلنیوم است. پارامتریزه کردن، به اجرای Test Caseها در برابر ترکیبات مختلف ورودی(یا Data Setها) کمک می‌کند. Data Setهای گسترده‌تر، برای موضوع Test Coverage(پوشش تست) بهتر هستند. این امر، به نوبه خود، به بهبود کیفیت محصول و اجرای روش‌های مناسب در تست سلنیوم کمک می‌کند.
برای این کار می‌توانید از TestNG، Junit، PyTest و … استفاده نمایید.
و این مقاله ان شا ا… ادامه خواهد داشت…
