เคล็ดลับการทดสอบที่เหนือชั้นสำหรับปี 2019: บทช่วยสอนการทดสอบ Java Automation

เผยแพร่แล้ว: 2022-03-11

ทุกปี วิศวกรทดสอบระบบอัตโนมัติจากทั่วโลกจะวิจัยเครื่องมือและเทคนิคล่าสุด เพื่อทำให้กรอบการทดสอบระบบอัตโนมัติมีเสถียรภาพมากขึ้น เร็วขึ้น และง่ายต่อการใช้งานและบำรุงรักษา นี่เป็นสิ่งสำคัญในการสร้างความมั่นใจว่าการนำกรอบงานของตนไปใช้อย่างแพร่หลายภายในบริษัทอย่างต่อเนื่อง โดยทั่วไป เฟรมเวิร์กที่ป่องและล้าสมัยจะหลุดจากแฟชั่นอย่างรวดเร็ว

ในบทความนี้ เราจะมาดูวิธีที่คุณสามารถอัปเดตกรอบงานสำหรับปี 2019 และวิธีเตรียมพร้อมสำหรับปี 2020 ได้ เพื่อที่จะปรับปรุงกรอบงานของฉัน ฉันมักจะเน้นที่ “จุดปวด” เสมอ เหล่านี้เป็นพื้นที่ที่ซับซ้อนในการตั้งค่าหรือทำให้เกิดความล้มเหลวมากที่สุด ฉันได้ระบุประเด็นหลักสามประการที่ฉันต้องการลดความซับซ้อนหรือปรับปรุง:

  1. ซีลีเนียมกริด
  2. รอ
  3. Chrome DevTools

Selenium Grid นั้นยากในการตั้งค่าและอาจล้มเหลวโดยไม่มีการเตือนล่วงหน้า ฉันต้องการที่จะดูว่ามีอะไรดีขึ้นที่นี่ ฉันยังต้องการตรวจสอบว่ามีการเพิ่มการ waits ใหม่ใน Selenium API หรือไม่ เพื่อปรับปรุงความเสถียรของการทดสอบใดๆ ที่ฉันสร้างขึ้น สุดท้ายนี้ ฉันต้องการดูว่าฉันสามารถเริ่มโต้ตอบกับ Chrome DevTools ผ่าน Selenium ได้หรือไม่ ซึ่งได้กลายเป็นส่วนสำคัญของชุดเครื่องมือของผู้ทดสอบ

เคล็ดลับ #1: เชื่อมต่อ Selenium Grid ของคุณ

Selenium Grid นั้นยากต่อการตั้งค่า ไม่เสถียร และยากต่อการปรับใช้หรือการควบคุมเวอร์ชันบนไปป์ไลน์ CI วิธีที่ง่ายกว่า เสถียร และบำรุงรักษาได้มากคือการใช้อิมเมจ Selenium Docker ที่สร้างไว้ล่วงหน้า

หมายเหตุ: ข้อเสียอย่างหนึ่งของวิธีนี้คือไม่รองรับ IE (Internet Explorer) เนื่องจากยังไม่สามารถบรรจุระบบปฏิบัติการ Windows ได้

กำลังตั้งค่า

ในการเริ่มต้นใช้งาน ก่อนอื่นคุณต้องติดตั้ง Docker และ Docker Compose บนเครื่องของคุณ หากคุณใช้ Windows 10 หรือ Mac ทั้งคู่จะถูกติดตั้งผ่าน Docker Desktop

การเริ่มต้นกริดของคุณ

ที่เก็บ Selenium อย่างเป็นทางการบน Docker Hub มีอิมเมจ Docker ที่สร้างไว้ล่วงหน้าสำหรับ Selenium Hub และ Firefox และ Chrome Nodes

วิธีที่ง่ายที่สุดในการใช้สิ่งเหล่านี้ใน Selenium Grid ในพื้นที่คือการสร้างไฟล์ Docker Compose ภายในไดเร็กทอรีรากของโครงการของคุณ ตั้งชื่อไฟล์ docker-compose.yml เพื่อให้ทุกอย่างง่ายขึ้น

ฉันได้รวมตัวอย่างไว้ด้านล่างซึ่งสร้าง Grid ต่อไปนี้:

  • Selenium Hub ตัวเดียว
  • โหนด Chrome หนึ่งตัว
  • โหนด Firefox หนึ่งอัน
 #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 อธิบายการตั้งค่า Grid ของคุณ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการสร้างไฟล์ Docker Compose โปรดดูเอกสารอย่างเป็นทางการ

ในการเริ่มต้น Grid ของคุณ เพียงใช้หน้าต่างเทอร์มินัล (หน้าต่าง powershell หรือ cmd ใน Windows) เพื่อเรียกใช้คำสั่งต่อไปนี้จากไดเร็กทอรีรากของโครงการของคุณ:

 docker-compose up

การเชื่อมต่อกับกริด

คุณสามารถเชื่อมต่อกับ Selenium Grid ในลักษณะเดียวกับที่คุณทำตามปกติ เนื่องจาก Hub กำลังฟังพอร์ต 4444 ของเครื่องในพื้นที่ของคุณ นี่คือตัวอย่างที่เราตั้งค่าไดรเวอร์เพื่อใช้ Chrome Node ของเรา

 // 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 เพื่อให้คุณสามารถสร้างภาพของคุณเองได้หากต้องการติดตั้งซอฟต์แวร์เพิ่มเติม

ในการสร้าง Grid เวอร์ชันเสถียรสำหรับไปป์ไลน์ CI ของคุณ คุณยังสามารถปรับใช้ Grid ของคุณบน Kubernetes หรือ Swarm ได้อีกด้วย สิ่งนี้ทำให้มั่นใจได้ว่า Dockers ใด ๆ จะได้รับการกู้คืนหรือเปลี่ยนอย่างรวดเร็วหากล้มเหลว

เคล็ดลับ #2: การรอคอยอย่างชาญฉลาด

ตามที่วิศวกรทดสอบระบบอัตโนมัติทุกคนทราบ การ waits มีความสำคัญต่อความเสถียรของเฟรมเวิร์กการทดสอบระบบอัตโนมัติของคุณ พวกเขายังสามารถเร่งการทดสอบของคุณโดยแสดงผลการ sleeps เครื่องหรือ pauses ซ้ำซ้อน และเอาชนะปัญหาเครือข่ายที่ช้าและปัญหาข้ามเบราว์เซอร์ ด้านล่างนี้คือเคล็ดลับบางประการที่จะช่วยให้คุณ waits ได้อย่างยืดหยุ่นยิ่งขึ้น

บทช่วยสอนการทดสอบ Java Automation #2: Logical Operators in Waits: Be Specific with Your Waits

คลาส 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 นี้ยังมีประโยชน์ในการค้นหาองค์ประกอบเดียวเมื่อคุณจัดการกับส่วนหน้าที่ใช้งานไม่ได้กับซีลีเนียม (เช่น เว็บไซต์เชิงมุม) การสร้างวิธีการเช่นนี้จะช่วยปกป้องการทดสอบของคุณ ทำให้การทดสอบมีความเสถียรมากขึ้น

 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) );

วิธีการทั้งหมดที่อธิบายไว้ข้างต้นและอื่น ๆ มีการระบุไว้ในเอกสารอย่างเป็นทางการ นับว่าคุ้มค่าที่จะใช้เวลาสิบนาทีในการอ่านความเป็นไปได้ทั้งหมดและปรับปรุงความเสถียรของกรอบงานของคุณ

บทช่วยสอนการทดสอบ Java Automation #2: ตัวดำเนินการเชิงตรรกะใน Waits

วิธีที่ดีในการสร้างความยืดหยุ่นในการ 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 ของคุณมีความยืดหยุ่นมากขึ้นและส่งผลให้การทดสอบมีความเปราะบางน้อยลง

เคล็ดลับ #3: Chrome DevTools: การจำลองเงื่อนไขเครือข่าย

การเรียกใช้เว็บแอปของคุณบน localhost หรือบนเครือข่ายท้องถิ่นสามารถให้การแสดงผลที่ผิดพลาดเกี่ยวกับประสิทธิภาพของมันเมื่อทำงานในไวด์ ความสามารถในการควบคุมความเร็วการอัปโหลดและดาวน์โหลดต่างๆ จะช่วยให้คุณเห็นภาพได้ดีขึ้นว่าแอปพลิเคชันของคุณทำงานบนอินเทอร์เน็ตอย่างไร ซึ่งการหมดเวลาอาจทำให้การดำเนินการต่างๆ ล้มเหลว เราสามารถเริ่มจำลองสิ่งนี้ได้โดยใช้พลังของ 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! } }
ที่เกี่ยวข้อง: สร้างด้วยความมั่นใจ: คู่มือการทดสอบ JUnit

เคล็ดลับโบนัส: วิธีจัดการคุกกี้ของคุณ

คุกกี้ของเบราว์เซอร์อาจทำให้เกิดพฤติกรรมที่แตกต่างกันในแอปพลิเคชันของคุณ ขึ้นอยู่กับว่าคุกกี้เหล่านั้นได้รับการบันทึกจากเซสชันก่อนหน้าหรือไม่ (เช่น แอปพลิเคชันอาจโหลดโดยที่ผู้ใช้ลงชื่อเข้าใช้แล้ว) แนวทางปฏิบัติที่ดีในการล้างคุกกี้ของคุณก่อนทำการทดสอบแต่ละครั้ง เพื่อให้แน่ใจว่าจะไม่ก่อให้เกิดปัญหา

รหัสด้านล่างช่วยให้คุณสามารถลบคุกกี้ทั้งหมดของคุณ:

 driver.manage().deleteAllCookies();

คุณยังสามารถลบคุกกี้ตามชื่อ:

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

หรือรับเนื้อหาของคุกกี้:

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

หรือรับคุกกี้ทั้งหมด:

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

ทดสอบระบบอัตโนมัติในปี 2020: มองไปสู่อนาคต

Selenium 4 จะออกในอีกไม่กี่เดือนข้างหน้า มันยังอยู่ระหว่างการพัฒนา แต่เมื่อเวอร์ชันอัลฟ่าออกวางจำหน่ายแล้ว ก็ควรค่าแก่การพิจารณาว่าจะมีการปรับปรุงใดบ้าง

หมายเหตุ: คุณสามารถติดตามความคืบหน้าได้โดยดูที่แผนงาน

มาตรฐาน W3C WebDriver

Selenium ไม่จำเป็นต้องสื่อสารกับเบราว์เซอร์ผ่านโปรโตคอลสาย JSON อีกต่อไป การทดสอบอัตโนมัติจะสื่อสารโดยตรงกับเบราว์เซอร์แทน สิ่งนี้ควรแก้ไขลักษณะที่ไม่สม่ำเสมอของการทดสอบ Selenium ที่มีชื่อเสียง รวมถึงการป้องกันการอัปเกรดเบราว์เซอร์ หวังว่าความเร็วในการทดสอบจะเพิ่มขึ้นด้วย

กริดซีลีเนียมที่เรียบง่ายกว่า

Selenium Grid จะมีเสถียรภาพมากขึ้นและง่ายต่อการตั้งค่าและจัดการใน Selenium 4 ผู้ใช้จะไม่ต้องตั้งค่าและเริ่มต้นฮับและโหนดแยกต่างหากอีกต่อไป เนื่องจากกริดจะทำหน้าที่เป็นโหนดและฮับที่รวมกัน นอกจากนี้ จะมีการรองรับ Docker ที่ดีขึ้น การทดสอบแบบขนานจะถูกรวมไว้โดยกำเนิด และจะให้ UI ที่ให้ข้อมูลมากขึ้น ขอการติดตามด้วย Hooks จะช่วยให้คุณดีบักกริดของคุณ

เอกสาร

เอกสาร Selenium จะได้รับการยกเครื่องที่จำเป็นมาก ไม่ได้รับการอัปเดตตั้งแต่เปิดตัว Selenium 2.0

การเปลี่ยนแปลงของ API

การสนับสนุนเบราว์เซอร์ Opera และ PhantomJS จะถูกลบออก การทำงานแบบ Headless สามารถทำได้ด้วย Chrome หรือ Firefox และ Opera สร้างขึ้นบน Chromium ดังนั้นการทดสอบ Chromium จึงถือว่าเพียงพอสำหรับเบราว์เซอร์นี้

WebElement.getSize() และ WebElement.getLocation() ถูกแทนที่ด้วยวิธีการเดียว WebElement.getRect() อย่างไรก็ตาม เนื่องจากมักใช้เพื่อสร้างภาพหน้าจอขององค์ประกอบเดียว จึงควรรู้ว่าจะมีคำสั่ง API เพื่อจับภาพหน้าจอขององค์ประกอบใน Selenium 4

สำหรับ WebDriver Window getPosition และ getSize จะถูกแทนที่ด้วยเมธอด getRect และเมธอด setPosition และ setSize จะถูกแทนที่ด้วยเมธอด setRect จะมีวิธี fullscreen และ minimize ดังนั้นการดำเนินการเหล่านี้จึงสามารถทำได้ภายในการทดสอบของคุณ

การเปลี่ยนแปลงที่โดดเด่นอื่นๆ:

  • คลาส Options สำหรับทุกเบราว์เซอร์จะขยายคลาส Capabilities
  • เพิ่มวิธีการ driver.switchTo().parentFrame() เพื่อทำให้การนำทางเฟรมง่ายขึ้น
  • ตัวระบุตำแหน่งที่ nice จะถูกรวมไว้ซึ่งทำงานในระดับที่สูงกว่าปัจจุบัน พวกเขาจะเป็นคลาสย่อยของ By
  • จะมีการใช้งาน DevTools API ซึ่งช่วยให้ผู้ใช้สามารถใช้ประโยชน์จากคุณลักษณะที่มีให้โดยใช้ Chrome Debugging Protocol (และเทียบเท่าในเบราว์เซอร์อื่นๆ) ซึ่งรวมถึง:
    • ภาพหน้าจอแบบเต็มหน้า (รวมถึงองค์ประกอบนอกหน้าจอ)
    • บันทึกการสตรีม
    • รอกิจกรรมการกลายพันธุ์ในเพจ
  • เมธอดและคลาสที่เลิกใช้แล้วจำนวนมากจะถูกลบออกด้วย

หมายเหตุ: คุณสามารถรับ Selenium 4 เวอร์ชันอัลฟ่าได้จากที่เก็บ Maven ขอแนะนำอย่างยิ่งให้ลองใช้กับเฟรมเวิร์กปัจจุบันของคุณ (ควรเป็นสาขาแซนด์บ็อกซ์) เพื่อให้คุณพร้อมสำหรับการเปลี่ยนแปลง

บทสรุป

ในบทความนี้ ฉันได้กล่าวถึงบางประเด็นที่ฉันได้ปรับปรุงเฟรมเวิร์กการทดสอบระบบอัตโนมัติให้ดียิ่งขึ้น ขณะนี้มีความเสถียรและใช้งานได้มากกว่าเดิม ซึ่งจะส่งผลดีกับทุกคนที่เกี่ยวข้องกับวงจรชีวิตการจัดส่งซอฟต์แวร์

การเปลี่ยนแปลงที่ฉันได้สรุปไว้ข้างต้นเป็นการเริ่มต้นที่ดี อย่างไรก็ตาม เราขอแนะนำให้คุณตรวจสอบกรอบงานทั้งหมดของคุณเพื่อหา "จุดที่มีปัญหา" เนื่องจากอาจมีการปรับปรุงที่คุณทำได้โดยที่ฉันไม่ได้กล่าวถึง ตัวอย่างเช่น คุณใช้ WebDriver Manager เพื่อจัดการไดรเวอร์หรือคุณยังคงอัปเดตไดรเวอร์ด้วยตนเองอยู่หรือไม่

นอกจากนี้ ฉันยังแนะนำให้กำหนดวันที่ทำเช่นนี้อย่างน้อยปีละครั้ง แม้ว่าตามหลักแล้วควรจะเป็นทุกๆ หกเดือน ในบทความ ฉันได้รวมการเปลี่ยนแปลงที่จะเกิดขึ้นใน Selenium 4.0 โปรดตรวจสอบซีลีเนียมเวอร์ชัน alpha ด้วยตัวคุณเอง การเปลี่ยนแปลงจะเป็นเรื่องที่น่าทึ่งและคุณจะต้องเตรียมพร้อม ฉันหวังว่าคุณจะพบว่าสิ่งนี้มีประโยชน์ หากคุณค้นพบวิธีการหรือเทคนิคใหม่ ๆ ในขณะที่ทำความสะอาดกรอบงานของคุณ โปรดแบ่งปันกับผู้อ่านบล็อกนี้โดยเพิ่มลงในส่วนความคิดเห็นด้านล่าง

นอกจากนี้ หากคุณต้องการดูการทดสอบอัตโนมัติใน Selenium และวิธีที่คุณสามารถใช้แบบจำลอง Page Object เพื่อเขียนรูทีนการทดสอบที่บำรุงรักษาและนำกลับมาใช้ใหม่ได้ ให้ลองดูการ ทำงานอัตโนมัติใน Selenium: Page Object Model และ Page Factory

ที่เกี่ยวข้อง: The Dart Language: เมื่อ Java และ C # ไม่คมชัดเพียงพอ