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

Sự ra đời của tính năng tự động hoá kiểm thử

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

Hai dự án này đã hợp nhất vào năm 2011 dưới dạng Selenium WebDriver và trở thành chuẩn W3C vào năm 2018. Chúng tôi thường gọi là WebDriver hoặc WebDriver "Cổ điển".

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 tự động hoá kiểm thử trước WebDriver "Cổ điển" khá phức tạp. Khả năng tự động hoá quy trình kiểm thử 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ự trỗi dậy của JavaScript

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

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

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ác công cụ thực thi JavaScript trong trình duyệt. Ví dụ: CypressTestCafe tận dụng các API web và Node.js để chạy kiểm thử ngay trong trình duyệt. Một điều 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ác 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 nữa, chẳng hạn như mở nhiều thẻ hoặc mô phỏng chế độ thiết bị, đó là lúc các công cụ cần thực thi các lệnh từ xa để kiểm soát trình duyệt thông qua các giao thức. Hai giao thức tự động hoá chính là WebDriver "Cổ điển"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 Chrome DevTools (CDP)

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

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

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

Ví dụ: hãy tưởng tượng bạn có một tập lệnh kiểm thử nhấp vào một phần tử await coffee.click();. URL này được dịch thành một loạt 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, Giao thức Công cụ phát triển Chrome (CDP) ban đầu được thiết kế cho Công cụ phát triển Chrome và gỡ lỗi, 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 các kết nối WebSocket, mang lại hiệu suất nhanh hơn và khả năng kiểm soát cấp thấp.

Tuy nhiên, API 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ở. Ngoài ra, 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 phù hợp với người dùng. Ví dụ: bạn sẽ mất nhiều công sức khi làm việc với các iframe ngoài quy trình.

CDP.
Giao thức Chrome DevTools

Ví dụ: thao tác nhấp vào một phần tử await coffee.click(); sẽ được dịch 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ác chế độ kiểm soát cấp thấp là gì?

Trước đây, khi WebDriver "Cổ điển" được phát triển, bạn không cần kiểm soát cấp thấp. Nhưng thời thế đã thay đổi, web hiện có nhiều chức năng hơn và việc kiểm thử ngày nay đòi hỏi nhiều hành động chi tiết hơn.

Vì CDP được thiết kế để đáp ứng mọi nhu cầu gỡ lỗi, nên CDP hỗ trợ nhiều chế độ kiểm soát cấp thấp hơn so với WebDriver "Cổ điển". CDP có thể 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 yêu cầu kết nối mạng
  • Mô phỏng chế độ thiết bị
  • Mô phỏng tính năng định vị địa lý
  • Và nhiều tính năng khác!

Bạn không thể thực hiện những việc này trong WebDriver "Cổ điển" do cấu trúc khác nhau – WebDriver "Cổ điển" dựa trên HTTP, khiến việc đăng ký và nghe các sự kiện trình duyệt trở nên khó khăn. Mặt khác, CDP dựa trên WebSocket, hỗ trợ nhắn tin hai chiều theo mặc định.

Bước tiếp theo: WebDriver BiDi

Sau đây là thông tin tóm tắt về các điểm mạnh của cả WebDriver "Cổ điển" và CDP:

WebDriver "Cổ điển" Giao thức Chrome DevTools (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 chức năng kiểm soát cấp thấp
Được xây dựng để kiểm thử

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ổ điển" và CDP. Đây là một giao thức tự động hoá trình duyệt chuẩn mới đang được phát triển.

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