Nhìn lại quá khứ: sự phát triển của tự động thử nghiệm

Sự ra đời của thử nghiệm tự động

Hãy cùng nhìn lại những năm 1990 khi trình duyệt web ra đời. Thử nghiệm tự động đã không trở thành hiện thực cho đến những năm 2000, với sự xuất hiện của các dự án SeleniumWebDriver để giải quyết những thách thức thử nghiệm trên nhiều trình duyệt và nhiều thiết bị.

Hai dự án này hợp tác với nhau vào năm 2011 với tên gọi Selenium WebDriver và trở thành tiêu chuẩn W3C vào năm 2018. Chúng tôi thường gọi WebDriver hoặc WebDriver "Cũ".

Quá trình phát triển của dự án Selenium WebDriver.
Quá trình phát triển của dự án Selenium WebDriver

Việc kiểm thử tính năng tự động hoá trước WebDriver “Cũ” là một việc khá khó khăn. Khả năng tự động hóa thử nghiệm trình duyệt đã cải thiện đáng kể chất lượng cuộc sống của nhà phát triển và người kiểm thử.

Sự gia tăng của JavaScript

Khi hoạt động phát triển web dần dựa vào JavaScript nhiều hơn, các giải pháp tự động hoá mới như WebdriverIO, Appium, Nightwatch, Protractor (không dùng nữa), Testquán, Cypress, Puppeteer và Playwright xuất hiện.

Các công cụ tự động hoá JavaScript.
Công cụ tự động hoá JavaScript

Các phương pháp tự động hoá

Nhìn chung, các công cụ này có thể được sắp xếp thành hai nhóm chính dựa trên cách chúng tự động hoá trình duyệt:

  • Cấp cao: Công cụ thực thi JavaScript trong trình duyệt. Ví dụ: CypressTestCafe tận dụng API web và Node.js để chạy kiểm thử trực tiếp trong trình duyệt. Một sự thật thú vị là phiên bản đầu tiên của Selenium cũng sử dụng phương pháp tương tự.
  • Cấp thấp: Công cụ thực thi lệnh từ xa bên ngoài trình duyệt. Khi các công cụ yêu cầu quyền kiểm soát lớn hơn, chẳng hạn như mở nhiều thẻ hoặc mô phỏng chế độ thiết bị, thì đó là khi các công cụ cần thực thi các lệnh từ xa để điều khiển trình duyệt thông qua các giao thức. Hai giao thức tự động hoá chính là WebDriver “Cũ”Giao thức Công cụ của Chrome cho nhà phát triển (CDP).

Trong phần tiếp theo, chúng ta sẽ xem xét hai giao thức này để hiểu được điểm mạnh và hạn chế của chúng.

WebDriver Classic và CDP.

WebDriver "Cổ điển" so với Giao thức Công cụ của Chrome cho nhà phát triển (CDP)

WebDriver "Cũ" là một chuẩn web được tất cả các trình duyệt chính hỗ trợ. Các tập lệnh tự động hoá sẽ đưa ra lệnh qua yêu cầu HTTP tới máy chủ của trình điều khiển, sau đó máy chủ này sẽ giao tiếp với các trình duyệt thông qua giao thức nội bộ dành riêng cho trình duyệt.

Mặc dù công cụ này có hỗ trợ tuyệt vời trên nhiều trình duyệt và API được thiết kế để thử nghiệm, nhưng công cụ này có thể chậm và không hỗ trợ một số chế độ kiểm soát cấp thấp.

WebDriver "Cũ".
WebDriver "Cổ điển"

Ví dụ: giả sử bạn có một tập lệnh kiểm thử để nhấp vào một phần tử await coffee.click();. Yêu cầu này được chuyển đổi thành một loạt các yêu cầu HTTP.

# WebDriver: Click on a coffee element

curl -X POST http://127.0.0.1:4444/session/:element_id/element/click
   -H 'Content-Type: application/json'
   -d '{}'

Mặt khác, ban đầu Giao thức Công cụ của Chrome cho nhà phát triển (CDP) được thiết kế để gỡ lỗi và Công cụ của Chrome cho nhà phát triển, nhưng đã được Puppeteer áp dụng để tự động hoá. CDP giao tiếp trực tiếp với các trình duyệt dựa trên Chromium thông qua kết nối WebSocket, cung cấp hiệu suất nhanh hơn và khả năng kiểm soát cấp thấp.

Tuy nhiên, công cụ này chỉ hoạt động với các trình duyệt dựa trên Chromium và không phải là một tiêu chuẩn mở. Trên hết, các API CDP tương đối phức tạp. Trong một số trường hợp, việc làm việc với CDP không hiệu quả. Ví dụ: việc làm việc với các iframe ngoài quy trình sẽ mất nhiều công sức.

CDP.
Giao thức Công cụ của Chrome cho nhà phát triển

Ví dụ: thao tác nhấp vào một phần tử await coffee.click(); sẽ được chuyển đổi thành một loạt lệnh CDP.

// CDP: Click on a coffee element

// Mouse pressed
{ 
  command: 'Input.dispatchMouseEvent', 
  parameters: {
    type: 'mousePressed', x: 10.34, y: 27.1, clickCount: 1 }
}

// Mouse released
{ 
  command: 'Input.dispatchMouseEvent', 
  parameters: {
    type: 'mouseReleased', x: 10.34, y: 27.1, clickCount: 1 }
}

Có những chế độ kiểm soát cấp thấp nào?

Khi WebDriver "Cũ" được phát triển, WebDriver là chủ đề không cần đến khả năng kiểm soát cấp thấp. Tuy nhiên, thời gian đã thay đổi, web giờ đây đã hoạt động hiệu quả hơn nhiều và việc thử nghiệm ngày nay đòi hỏi các hành động chi tiết hơn.

Vì được thiết kế để đáp ứng mọi nhu cầu gỡ lỗi, nên CDP hỗ trợ nhiều chức năng kiểm soát cấp thấp hơn so với WebDriver “Cũ”. WebDriver này có khả năng xử lý các tính năng như:

  • Ghi lại thông báo trên bảng điều khiển
  • Chặn các yêu cầu mạng
  • Mô phỏng chế độ thiết bị
  • Mô phỏng vị trí định vị vị trí
  • Và nhiều kiến thức khác!

Những việc này là không khả thi trong WebDriver "Cũ" do có cấu trúc khác biệt. WebDriver "Cũ" hoạt động dựa trên giao thức HTTP, khiến việc đăng ký và nghe các sự kiện của trình duyệt trở nên khó khăn. Mặt khác, CDP dựa trên WebSocket, hỗ trợ thông báo hai chiều theo mặc định.

Bước tiếp theo: WebDriver BiDi

Dưới đây là phần tóm tắt về những điểm mạnh của cả WebDriver "Cũ" và CDP:

WebDriver "Cũ" Giao thức Công cụ của Chrome cho nhà phát triển (CDP)
Hỗ trợ tốt nhất trên nhiều trình duyệt Nhắn tin nhanh, hai chiều
Tiêu chuẩn W3C Cung cấp quyền kiểm soát cấp thấp
Được thiết kế để thử nghiệm

WebDriver BiDi hướng đến việc kết hợp những khía cạnh tốt nhất của WebDriver "Cũ" và CDP. Đây là một giao thức tự động hoá trình duyệt tiêu chuẩn mới hiện đang được phát triển.

Tìm hiểu thêm về dự án WebDriver BiDi – cách thức hoạt động, tầm nhìn và quy trình tiêu chuẩn hoá.