نصائح حول اختبار الشحن الفائق لعام 2019: برنامج تعليمي لاختبار أتمتة Java

في كل عام ، سيقوم مهندسو أتمتة الاختبار من جميع أنحاء العالم بالبحث عن أحدث الأدوات والتقنيات من أجل جعل إطار أتمتة الاختبار الخاص بهم أكثر استقرارًا وأسرع وأسهل في الاستخدام والصيانة. هذا أمر حيوي لضمان استمرار اعتماد إطار عملهم على نطاق واسع داخل شركتهم. بشكل عام ، الأطر المتضخمة والقديمة تسقط من الموضة بسرعة.

في هذه المقالة ، سنلقي نظرة على بعض الطرق التي يمكنك من خلالها تحديث إطار العمل الخاص بك لعام 2019 وكيفية الاستعداد لعام 2020. من أجل تحسين إطار العمل الخاص بي ، أركز دائمًا على "نقاط الضعف". هذه هي المجالات التي يصعب إنشاؤها أو تسبب معظم حالات الفشل. حددت ثلاثة مجالات رئيسية أردت تبسيطها أو تحسينها:

1. شبكة السيلينيوم
2. ينتظر
3. Chrome DevTools

من المعروف أن شبكة السيلينيوم صعبة الإعداد ويمكن أن تفشل دون سابق إنذار. أردت أن أرى ما الذي تحسن هنا ، إذا كان هناك أي شيء. أردت أيضًا التحقق مما إذا تمت إضافة أي waits جديدة إلى واجهة برمجة تطبيقات السيلينيوم لتحسين استقرار أي اختبارات قمت بإنشائها. أخيرًا ، أردت معرفة ما إذا كان بإمكاني البدء في التفاعل مع Chrome DevTools من خلال السيلينيوم ، والتي أصبحت جزءًا أساسيًا من مجموعة أدوات أي مختبِر.

نصيحة رقم 1: ارساء شبكة السيلينيوم الخاصة بك

من المعروف أن شبكة السيلينيوم يصعب إعدادها ، وغير مستقرة ، ويصعب نشرها ، أو التحكم في الإصدار ، على خط أنابيب CI. هناك طريقة أسهل بكثير ومستقرة وقابلة للصيانة وهي استخدام صور Selenium Docker المبنية مسبقًا.

ملاحظة: الجانب السلبي لهذه الطريقة هو أن IE (Internet Explorer) غير مدعوم ، حيث لا يمكن حتى الآن وضع نظام تشغيل Windows في حاوية.

التجهيز

للتشغيل والتشغيل ، تحتاج أولاً إلى تثبيت Docker و Docker Compose على جهازك. إذا كنت تقوم بتشغيل Windows 10 أو Mac ، فسيتم تثبيتهما من خلال Docker Desktop.

بدء الشبكة الخاصة بك

يحتوي مستودع السيلينيوم الرسمي على Docker Hub على صور Docker سابقة البناء لعقد Selenium Hub و Firefox و Chrome.

أسهل طريقة لاستخدامها في شبكة سيلينيوم محلية هي إنشاء ملف Docker Compose داخل الدليل الجذر لمشروعك. قم بتسمية الملف docker-compose.yml الأمور.

لقد قمت بتضمين مثال أدناه والذي ينشئ الشبكة التالية:

• محور واحد من السيلينيوم
• عقدة كروم واحدة
• عقدة واحدة في فايرفوكس

 #docker-compose.yml version: "3" services: selenium-hub: image: selenium/hub:3.141.59-neon container_name: selenium-hub ports: - "4444:4444" chrome: image: selenium/node-chrome:3.141.59-neon volumes: - /dev/shm:/dev/shm depends_on: - selenium-hub environment: - HUB_HOST=selenium-hub - HUB_PORT=4444 firefox: image: selenium/node-firefox:3.141.59-neon volumes: - /dev/shm:/dev/shm depends_on: - selenium-hub environment: - HUB_HOST=selenium-hub - HUB_PORT=4444

يصف ملف Docker Compose إعداد الشبكة الخاصة بك. لمزيد من المعلومات حول إنشاء ملفات Docker Compose ، يرجى الاطلاع على الوثائق الرسمية.

لبدء تشغيل شبكتك ، ما عليك سوى استخدام أي نافذة طرفية (نافذة powershell أو نافذة cmd في Windows) لتشغيل الأمر التالي من الدليل الجذر لمشروعك:

 docker-compose up

التوصيل بالشبكة

يمكنك الاتصال بشبكة السيلينيوم الخاصة بك بالطريقة نفسها تمامًا كما تفعل عادةً ، حيث يستمع Hub على المنفذ 4444 من جهازك المحلي. إليك مثال حيث قمنا بإعداد برنامج التشغيل الخاص بنا لاستخدام عقدة Chrome الخاصة بنا.

 // Driver.java protected static RemoteWebDriver browser; DesiredCapabilities cap = new DesiredCapabilities(); ChromeOptions chromeOptions = new ChromeOptions(); cap.setCapability(ChromeOptions.CAPABILITY, chromeOptions); cap.setBrowserName("chrome"); driver = new RemoteWebDriver(cap);

يمكنك بعد ذلك استخدام مكتبة TestNG لإجراء اختباراتك على عدة عقد بالتوازي كالمعتاد.

تجدر الإشارة إلى أنه من الممكن تشغيل عدة متصفحات على كل عقدة. ومع ذلك ، لا يُنصح بذلك ، ويعتبر استخدام متصفح واحد لكل عقدة من أفضل الممارسات لتحقيق الأداء الأمثل.

نصائح وحيل إضافية

إذا كنت تريد أن ترى ما يحدث على المتصفح حتى تتمكن من تصحيح أخطاء اختباراتك ، فمن المفيد أن يكون لديك إصدار debug من ملف docker-compose.yml الذي يقوم بتنزيل عُقد متصفح debug . تحتوي على خادم VNC حتى تتمكن من مشاهدة المتصفح أثناء تشغيل الاختبار.

من الممكن أيضًا تشغيل المتصفحات بدون رأس لزيادة السرعة (بالطريقة المعتادة) كما يوفر Selenium أيضًا إصدارات base من الصور حتى تتمكن من إنشاء صورك الخاصة إذا كنت بحاجة إلى تثبيت برنامج إضافي.

لإنشاء إصدار ثابت من الشبكة لخط أنابيب CI الخاص بك ، من الممكن أيضًا نشر شبكتك على Kubernetes أو Swarm. هذا يضمن استعادة أي Dockers أو استبدالها بسرعة في حالة فشلها.

النصيحة الثانية: الانتظار الذكي

كما يعلم أي مهندس أتمتة اختبار ، فإن waits ضرورية لاستقرار إطار أتمتة الاختبار الخاص بك. يمكنهم أيضًا تسريع اختبارك عن طريق جعل أي فترات sleeps أو pauses زائدة عن الحاجة والتغلب على مشكلات الشبكة البطيئة وعبر المستعرضات. فيما يلي بعض النصائح لجعل waits أكثر مرونة.

البرنامج التعليمي رقم 2 لاختبار أتمتة Java: المشغلون المنطقيون في الانتظار: كن محددًا في فترات انتظارك

نمت فئة ExpectedConditions بمرور الوقت وهي تشمل الآن تقريبًا كل موقف يمكن تخيله. على الرغم من أن ExpectedConditions.presenceOfElementLocated(locator) غالبًا ما تكون كافية ، فمن الأفضل استخدام الطرق داخل فئة ExpectedCondition لتغطية كل إجراء للمستخدم من خلال تضمينها في فئة Actions.java . سيؤدي ذلك إلى حماية اختباراتك ضد معظم مشكلات المستعرضات أو مشكلات موقع الويب البطيئة.

على سبيل المثال ، إذا أدى النقر فوق ارتباط إلى فتح علامة تبويب جديدة ، فاستخدم ExpectedConditions.numberOfWindowsToBe(2) . سيضمن ذلك وجود علامة التبويب قبل محاولة التبديل إليها.

يمكنك أيضًا استخدام فترة wait للتأكد من التقاط جميع العناصر الموجودة على الصفحة عند استخدام findElements . يمكن أن يكون هذا مفيدًا بشكل خاص إذا كانت صفحة search تستغرق وقتًا لإرجاع نتائجها. على سبيل المثال ، هذا الخط:

 List<WebElement> results = driver.findElements(locators.RESULTS);

قد ينتج عن ذلك مصفوفة List فارغة إذا لم يتم تحميل نتائج البحث الخاصة بك حتى الآن. بدلاً من ذلك ، من الأفضل استخدام numberOfElementsToBeMoreThan المتوقع لانتظار النتائج لتكون أكثر من الصفر. علي سبيل المثال:

 WebElement searchButton = driver.findElement(locators.SEARCH_BUTTON); searchButton.click(); new WebDriverWait(driver, 30) .until(ExpectedConditions .numberOfElementsToBeMoreThan(locators.RESULTS, 0)); List<WebElement> results = driver.findElements(locators.RESULTS); results.get(0).click();

الآن ، لن يتم تشغيل الأمر findElements إلا بعد إرجاع نتائج البحث.

يعد هذا wait مفيدًا أيضًا للعثور على عنصر واحد عندما تتعامل مع واجهة أمامية لا تلعب بشكل جيد مع السيلينيوم (على سبيل المثال ، مواقع Angular). سيؤدي إنشاء طريقة كهذه إلى حماية اختباراتك ، مما يجعلها أكثر استقرارًا.

 protected static WebElement waitForElement(By locator){ try { new WebDriverWait(browser, 30) .until(ExpectedConditions .numberOfElementsToBeMoreThan(locator, 0)); } catch (TimeoutException e){ e.printStackTrace(); Assert.fail("Timeout: The element couldn't be found in " + WAIT + " seconds!"); } catch (Exception e){ e.printStackTrace(); Assert.fail("Something went wrong!"); } return browser.findElement(locator); }

بل إنه من الممكن انتظار عدم ظهور العناصر بعد الآن. يكون هذا مفيدًا بشكل خاص إذا كنت تنتظر اختفاء نافذة منبثقة بعد النقر فوق الزر " OK " أو " Save " قبل متابعة الاختبار.

 WebElement okButton = driver.findElement(locators.OK_BUTTON); okButton.click(); new WebDriverWait(driver, 30) .until( ExpectedConditions .invisibilityOfElementLocated(locators.POPUP_TITLE) );

جميع الطرق المذكورة أعلاه وأكثر مذكورة في الوثائق الرسمية. من الجدير قضاء عشر دقائق في قراءة جميع الاحتمالات وتحسين استقرار إطار العمل الخاص بك.

البرنامج التعليمي رقم 2 لاختبار أتمتة Java: المشغلون المنطقيون في الانتظار

من الطرق الجيدة لبناء المرونة في waits استخدام عوامل التشغيل المنطقية. على سبيل المثال ، إذا أردت التحقق من تحديد موقع عنصر وأنه قابل للنقر عليه ، يمكنك استخدام الكود التالي (يرجى ملاحظة أن هذه الأمثلة ترجع قيمة منطقية):

 wait.until(ExpectedConditions.and( ExpectedConditions.presenceOfElementLocated(locator), ExpectedConditions.elementToBeClickable(locator) ) );

سيكون عامل التشغيل OR مناسبًا إذا لم تكن متأكدًا مما إذا كان عنوان الصفحة قد يتغير أم لا. بعد ذلك ، يمكنك تضمين التحقق من عنوان URL في حالة فشل الشرط الأول ، لتأكيد أنك بالتأكيد في الصفحة الصحيحة.

 wait.until(ExpectedConditions.or( ExpectedConditions.titleIs(expectedTitle), ExpectedConditions.urlToBe(expectedUrl) ) );

أو إذا أردت التأكد من أن مربع الاختيار لم يعد ممكّنًا بعد تنفيذ إجراء على الصفحة ، فعندئذٍ يكون عامل التشغيل NOT مناسبًا.

 wait.until(ExpectedConditions.not( ExpectedConditions.elementToBeClickable(locator) ) );

يمكن أن يؤدي استخدام عوامل التشغيل إلى جعل waits أكثر مرونة ويؤدي إلى اختبارات أقل هشاشة.

النصيحة الثالثة: Chrome DevTools: محاكاة ظروف الشبكة

يمكن أن يؤدي تشغيل تطبيق الويب الخاص بك على المضيف المحلي أو على شبكة محلية إلى إعطاء انطباع خاطئ عن أدائه عند تشغيله في البرية. ستمنحك القدرة على خنق سرعات التحميل والتنزيل المختلفة تمثيلاً أفضل لكيفية تشغيل تطبيقك عبر الإنترنت ، حيث يمكن أن تتسبب المهلات في فشل الإجراءات. يمكننا البدء في محاكاة هذا باستخدام قوة DevTools في Chrome.

سيفتح الكود التالي صفحة Toptal الرئيسية باستخدام سرعات تنزيل وتحميل مختلفة. أولاً ، سنقوم بتخزين سرعاتنا في مزود بيانات TestNG باستخدام الكود التالي:

 import org.testng.annotations.DataProvider; public class ExcelDataProvider { @DataProvider(name = "networkConditions") public static Object[][] networkConditions() throws Exception { return new Object[][] { // Upload Speed, Dowload Speed in kb/s and latency in ms. { 5000 , 5000, 5 }, { 10000, 7000, 5 }, { 15000, 9000, 5 }, { 20000, 10000, 5 }, { 0, 0 }, }; } }

ملاحظة: يتم تقييد التحميل والتنزيل بالكيلو kb/s ووقت الاستجابة ms .

بعد ذلك ، يمكننا استخدام هذه البيانات لإجراء اختبارنا في ظل ظروف شبكة مختلفة. ضمن الاختبار ، سيقوم CommandExecutor بتنفيذ الأمر في جلسة المتصفح الحالية. سيؤدي هذا بدوره إلى تنشيط الإعدادات الضرورية في وظيفة أدوات المطور في Chrome لمحاكاة شبكتنا البطيئة. يمكن تضمين الكود الموجود في عبارة if في طريقة @BeforeClass عند تشغيل مجموعة من الاختبارات.

 import org.testng.annotations.Test; import com.google.common.collect.ImmutableMap; import java.io.IOException; import java.util.HashMap; import java.util.Map; import org.openqa.selenium.remote.Command; import org.openqa.selenium.remote.CommandExecutor; import org.openqa.selenium.remote.Response; public class TestClass { // load our data provider @Test(dataProvider = "networkConditions") public void test(int download, int upload, int latency) throws IOException { // only run if the network is throttled if (download > 0 && upload > 0) { CommandExecutor executor = driver.getCommandExecutor(); // create a hashmap of the required network conditions Map map = new HashMap(); // you can even test 'offline' behaviour map.put("offline", false); map.put("latency", latency); map.put("download_throughput", downloadThroughput); map.put("upload_throughput", uploadThroughput); // execute our code Response response = executor.execute( new Command(driver.getSessionId(), "setNetworkConditions", ImmutableMap.of("network_conditions", ImmutableMap.copyOf(map)))); } // Open the website driver.get("https://www.toptal.com/"); // You can then check that elements are loaded etc. // Don't forget to use waits! } }

نصيحة إضافية: كيفية إدارة ملفات تعريف الارتباط الخاصة بك

يمكن أن تتسبب ملفات تعريف الارتباط في المتصفح في سلوكيات مختلفة في تطبيقك ، اعتمادًا على ما إذا تم حفظها من جلسة سابقة أم لا (على سبيل المثال ، قد يتم تحميل التطبيق مع مستخدم قام بتسجيل الدخول بالفعل). من الممارسات الجيدة مسح ملفات تعريف الارتباط قبل كل اختبار تشغيل للتأكد من أنها لا تسبب مشاكل.

يسمح لك الرمز أدناه بحذف جميع ملفات تعريف الارتباط الخاصة بك:

 driver.manage().deleteAllCookies();

يمكنك أيضًا حذف ملف تعريف الارتباط بالاسم:

 driver.manage().deleteCookieNamed("CookieName");

أو احصل على محتويات ملف تعريف الارتباط:

 String myCookie = driver.manage().getCookieNamed("CookieName").getValue();

أو احصل على جميع ملفات تعريف الارتباط:

 List<Cookie> cookies = driver.manage().getCookies();

أتمتة الاختبارات في 2020: التطلع إلى المستقبل

سيتم إطلاق السيلينيوم 4 خلال الأشهر القليلة المقبلة. لا يزال قيد التطوير ، ولكن نظرًا لإصدار إصدار ألفا بالفعل ، فمن الجدير إلقاء نظرة على التحسينات التي سيقدمها.

ملاحظة: يمكنك تتبع تقدمهم من خلال النظر في خارطة الطريق.

توحيد W3C WebDriver

لم يعد السيلينيوم بحاجة إلى التواصل مع المتصفح من خلال بروتوكول الأسلاك JSON ؛ بدلاً من ذلك ، ستتواصل الاختبارات الآلية مباشرة مع المتصفح. يجب أن يعالج هذا الطبيعة غير المستقرة الشهيرة لاختبارات السيلينيوم ، بما في ذلك الحماية من ترقيات المتصفح. نأمل أن تزداد سرعة الاختبار أيضًا.

شبكة سيلينيوم أبسط

ستكون شبكة السيلينيوم أكثر استقرارًا وأسهل في الإعداد والإدارة في السيلينيوم 4. لن يحتاج المستخدمون بعد الآن إلى إعداد وبدء المحاور والعقد بشكل منفصل حيث ستعمل الشبكة كعقدة ومحور مدمجين. بالإضافة إلى ذلك ، سيكون هناك دعم أفضل لـ Docker ، وسيتم تضمين الاختبار الموازي محليًا ، وسيوفر واجهة مستخدم أكثر إفادة. سيساعدك طلب التتبع باستخدام الخطافات أيضًا على تصحيح أخطاء الشبكة.

توثيق

ستحصل وثائق السيلينيوم على إصلاح شامل ، حيث لم يتم تحديثه منذ إصدار السيلينيوم 2.0.

التغييرات على API

ستتم إزالة دعم متصفحي Opera و PhantomJS. يمكن إجراء التشغيل بدون رأس باستخدام Chrome أو Firefox ، كما أن Opera مبني على Chromium ، وبالتالي يُنظر إلى اختبار Chromium على أنه كافٍ لهذا المتصفح.

يتم الآن استبدال WebElement.getSize() و WebElement.getLocation() بطريقة واحدة WebElement.getRect() . ومع ذلك ، نظرًا لأنها تُستخدم غالبًا لإنشاء لقطات شاشة لعنصر واحد ، فمن الجدير معرفة أنه سيكون هناك أيضًا أمر واجهة برمجة التطبيقات لالتقاط لقطة شاشة لعنصر في السيلينيوم 4.

بالنسبة إلى WebDriver Window ، سيتم استبدال أساليب getPosition و getSize بطريقة setSize getRect setPosition بالطريقة setRect . minimize طرق fullscreen ، بحيث يمكن تنفيذ هذه الإجراءات في اختبارك.

تغييرات ملحوظة أخرى:

• ستعمل فئة Options لكل متصفح الآن على توسيع فئة Capabilities .
• تمت إضافة طريقة driver.switchTo().parentFrame() لتسهيل التنقل داخل الإطار.
• سيتم تضمين محددات موقع nice تعمل على مستوى أعلى من المستويات الحالية. سيكونون فئة فرعية من By .
• سيكون هناك تنفيذ لواجهة برمجة تطبيقات DevTools ، مما يسمح للمستخدمين بالاستفادة من الميزات التي يوفرها استخدام بروتوكول تصحيح أخطاء Chrome (وما يعادله في المتصفحات الأخرى). وتشمل هذه:
  • لقطات شاشة لصفحة كاملة (بما في ذلك العناصر الموجودة خارج الشاشة).
  • سجلات التدفق.
  • في انتظار أحداث الطفرة على الصفحة.
• سيتم أيضًا حذف العديد من الأساليب والفئات المهملة.

ملاحظة: يمكنك الحصول على نسخة ألفا من السيلينيوم 4 من مستودع مافن. يوصى بشدة بتجربة ذلك مقابل إطار العمل الحالي الخاص بك (من الناحية المثالية على فرع الحماية) ، حتى تكون جاهزًا للتغيير.

خاتمة

في هذه المقالة ، قمت بتغطية بعض المجالات حيث قمت بتحسين إطار أتمتة الاختبار الخاص بي للأفضل. أصبح الآن أكثر استقرارًا وقابلية للاستخدام من ذي قبل ، مما سيكون له تأثير إيجابي على كل من يشارك في دورة حياة تسليم البرنامج.

يعد إجراء التغييرات التي أشرت إليها أعلاه بداية جيدة ، ومع ذلك ، فإنني أوصي بشدة بمراجعة إطار العمل الخاص بك بالكامل لـ "نقاط الألم" ، حيث قد تكون هناك تحسينات يمكنك إجراؤها لم أقم بتغطيتها. على سبيل المثال ، هل تستخدم WebDriver Manager لإدارة برامج التشغيل الخاصة بك أم أنك لا تزال تقوم بتحديثها يدويًا؟

أوصي أيضًا بتحديد موعد للقيام بذلك مرة واحدة على الأقل سنويًا ، على الرغم من أنه من الأفضل أن يكون كل ستة أشهر. في المقالة ، قمت بتضمين التغييرات القادمة في السيلينيوم 4.0. يرجى مراجعة إصدارات alpha من السيلينيوم بنفسك. ستكون التغييرات دراماتيكية وستحتاج إلى الاستعداد. أتمنى أن تكون قد وجدت هذا مفيدًا. إذا اكتشفت أي طرق أو تقنيات جديدة أثناء القيام ببعض التنظيف الربيعي في إطار العمل الخاص بك ، فيرجى مشاركتها مع القراء الآخرين لهذه المدونة عن طريق إضافتها إلى قسم التعليقات أدناه.

أيضًا ، إذا كنت تريد إلقاء نظرة على الاختبارات الآلية في السيلينيوم ، وكيف يمكنك استخدام نماذج كائن الصفحة لكتابة إجراءات اختبار قابلة للصيانة وإعادة الاستخدام ، تحقق من التشغيل الآلي في السيلينيوم: نموذج كائن الصفحة ومصنع الصفحة .