WebDriver BiDi là gì? Lệnh, Sự kiện và Kiểm soát Trình duyệt

WebDriver BiDi là gì?

Trình duyệt Tác nhân Scrapeless cung cấp một kết nối CDP cho việc tự động hóa trình duyệt được quản lý và tương tác trang động.

WebDriver BiDi là một giao thức tự động hóa trình duyệt hỗ trợ các lệnh từ phía khách và các sự kiện từ trình duyệt thông qua một kết nối hai chiều. Tên gọi BiDi có nghĩa là hai chiều. Giao thức này cho phép phần mềm điều khiển quan sát hoạt động của trình duyệt khi nó diễn ra, thay vì phải biểu đạt mỗi lần quan sát dưới dạng một yêu cầu riêng biệt để lấy trạng thái hiện tại của trình duyệt.

WebDriver BiDi là một đặc tả W3C đang được phát triển, với mức độ hỗ trợ triển khai khác nhau tùy theo trình duyệt, thư viện khách và tính năng. Hãy coi giao thức này như một giao diện tự động hóa đã được xác định, sau đó xác minh các thao tác cụ thể mà dự án của bạn cần. Một kết nối trình duyệt sử dụng WebSocket không phải là bằng chứng đủ để khẳng định kết nối đó sử dụng BiDi.

Tại Sao Tự Động Hóa Trình Duyệt Cần Các Sự Kiện

Các sự kiện trình duyệt cho phép tự động hóa quan sát hoạt động không được khởi tạo bởi lệnh tiếp theo của client. Một trang có thể ghi một thông báo bảng điều khiển, mở một ngữ cảnh duyệt web khác hoặc bắt đầu một yêu cầu mạng trong khi client đang thực hiện các công việc khác.

Trong một tương tác dạng lệnh-và-phản hồi, phía khách yêu cầu một hành động hoặc trạng thái và nhận lại một kết quả. Mô hình đó vẫn hữu ích cho việc điều hướng và tương tác với các phần tử. Nó kém trực tiếp hơn khi phía khách cần một luồng các quan sát được trình duyệt tạo ra một cách độc lập.

The Đặc tả WebDriver BiDi định nghĩa cơ chế hai chiều và các lệnh cùng sự kiện của nó. Mô hình sự kiện giúp diễn đạt các tác vụ như thu thập nhật ký liên quan trong suốt một quy trình làm việc, thay vì chỉ kiểm tra sau khi một hành động đã hoàn tất.

Các sự kiện không loại bỏ nhu cầu về một quy tắc hoàn tất. Một thông báo bảng điều khiển có thể là bằng chứng chẩn đoán hữu ích mà không chứng minh rằng một ứng dụng đã sẵn sàng. Hãy quyết định sự kiện hoặc điều kiện trang nào tương ứng với trạng thái dự định của tác vụ.

Lệnh, Kết quả và Sự kiện Có Vai Trò Khác Nhau

Các lệnh BiDi yêu cầu các thao tác của trình duyệt, phản hồi lệnh báo cáo kết quả của chúng, và các sự kiện mô tả hoạt động của trình duyệt được gửi tới các client đã đăng ký. Giữ các vai trò đó tách biệt giúp ngăn ngừa những giả định sai về thứ tự thông điệp.

Một client có thể gửi một thao tác trong khi các hoạt động trình duyệt khác đang diễn ra. Kết nối có thể truyền một sự kiện trước hoặc sau phản hồi lệnh, tùy thuộc vào việc trình duyệt đang làm gì. Hãy đối chiếu các phản hồi lệnh với các yêu cầu tương ứng của chúng và diễn giải các sự kiện trong bối cảnh và đăng ký liên quan.

Không coi việc nhận được bất kỳ tin nhắn nào là quyền tự động được phép tiếp tục. Một sự kiện liên quan đến điều hướng, kết quả của một script và một bản ghi nhật ký trả lời các câu hỏi khác nhau. Khách hàng của bạn cần liên kết các quan sát với trang và hành động mà chúng liên quan.

Đối với một quy trình chẩn đoán, hãy xác định khoảng thời gian quan sát. Đăng ký trước hoạt động bạn muốn quan sát, giữ lại thông tin cần thiết để giải thích hoạt động đó, và hủy đăng ký khi tác vụ không còn cần đến nữa. Nếu không, một client tồn tại lâu dài có thể tích lũy các quan sát từ những công việc không liên quan.

Ngữ cảnh duyệt web mang đến cho sự kiện một vị trí

Ngữ cảnh duyệt web xác định nơi diễn ra hoạt động của trình duyệt, chẳng hạn như một trang cấp cao nhất hoặc một khung nhúng. Danh tính của ngữ cảnh trở nên quan trọng khi có nhiều trang có thể phát ra các sự kiện tương tự nhau.

Một cửa sổ popup có thể thuộc về một ngữ cảnh cấp cao khác với trang đã mở nó. Một iframe có thể điều hướng độc lập bên trong trang cha. Nếu client của bạn cho rằng mọi sự kiện đều thuộc về tài liệu được mở ban đầu, nó có thể gắn nhầm bằng chứng vào một tiến trình trích xuất hoặc bài kiểm thử.

Theo dõi ngữ cảnh cần thiết cho tác vụ thay vì chỉ dựa vào tiêu đề hiển thị. Tiêu đề và URL có thể thay đổi, và các ngữ cảnh riêng biệt đôi khi có thể tạm thời hiển thị cùng một địa chỉ. Một định danh ngữ cảnh cung cấp một tham chiếu ở cấp độ giao thức, trong khi URL và tiêu đề cung cấp ngữ cảnh dễ đọc cho con người.

Điều hướng cũng ảnh hưởng đến môi trường tập lệnh. Một giá trị thu được từ một tài liệu không nên được cho là mô tả một tài liệu sau đó trong cùng một thẻ. Hãy xây dựng quy trình làm việc xung quanh vòng đời của ngữ cảnh và tài liệu hiện tại của nó.

WebDriver cổ điển, BiDi và CDP là các giao diện khác nhau

WebDriver cổ điển, WebDriver BiDi và Chrome DevTools Protocol cung cấp các giao diện điều khiển trình duyệt khác nhau. Một thư viện có thể hỗ trợ nhiều hơn một giao diện, nhưng cần phải thiết lập hỗ trợ cụ thể cho từng trình duyệt và thao tác.

Giao diệnPrimary ModelCâu hỏi về khả năng tương thích
WebDriver cổ điểnLệnh và phản hồi từ xaĐầu bên kia từ xa có triển khai các lệnh bắt buộc không?
WebDriver BiDiCác lệnh hai chiều và sự kiện trình duyệtCác mô-đun và sự kiện cần thiết đã được triển khai chưa?
CDPCác lệnh và sự kiện hướng đến DevToolsĐiểm cuối trình duyệt này có hỗ trợ các miền đã chọn không?

The Giao diện từ xa WebDriver vẫn là cơ sở để hiểu các phiên cổ điển và các lệnh. BiDi bổ sung một giao thức song hướng tiêu chuẩn hóa thay vì làm cho mọi tên lệnh hoặc phương thức truyền tải hiện có có thể hoán đổi cho nhau.

WebSocket là một giao thức truyền tải, không phải là một đảm bảo về khả năng tương thích. Một endpoint CDP và một endpoint BiDi đều có thể sử dụng kết nối lâu dài trong khi chấp nhận các thông điệp khác nhau. Gửi các lệnh của một giao thức sang giao thức kia không phải là một chiến lược di chuyển.

Cách Phạm Vi Đăng Ký Thuê Bao Thay Đổi Khả Năng Quan Sát

Các đăng ký xác định những sự kiện trình duyệt mà client nhận được theo các quy tắc sự kiện của giao thức. Một đăng ký hữu ích bao gồm các quan sát cần thiết cho quy trình làm việc và loại trừ hoạt động không cần thiết.

Hãy xem xét một bài kiểm tra mở trang ứng dụng đã được ủy quyền và kiểm tra một bản ghi bắt buộc. Nhật ký trình duyệt có thể giúp chẩn đoán lý do tại sao bản ghi không xuất hiện. Thu thập các nhật ký đó xung quanh hành động có thể giữ lại chuỗi liên quan mà không cần lưu toàn bộ lịch sử duyệt web của một phiên dùng chung.

Các quan sát mạng có thể chứa thông tin nhạy cảm, bao gồm URL hoặc siêu dữ liệu liên quan đến tài khoản. Giới hạn việc thu thập trong phạm vi nhiệm vụ, loại bỏ bí mật khỏi các hiện vật được giữ lại, và chọn chính sách lưu giữ phù hợp với nhu cầu chẩn đoán.

Dọn dẹp đăng ký là một phần của tính đúng đắn phía client. Nếu một phiên được tái sử dụng tiếp tục gửi các sự kiện từ một nhiệm vụ đã hoàn thành, các nhiệm vụ sau có thể hiểu sai chúng. Duy trì quyền sở hữu rõ ràng đối với các đăng ký và ánh xạ ngữ cảnh thay vì dựa vào một bộ thu thập sự kiện toàn cục không có ranh giới công việc.

Hỗ Trợ Triển Khai Phải Được Kiểm Tra Theo Từng Tính Năng

Hỗ trợ BiDi là một câu hỏi tương thích ở cấp độ tính năng, không phải một nhãn có/không đơn lẻ cho toàn bộ ngăn xếp tự động hóa. Phiên bản trình duyệt, môi trường từ xa và ràng buộc ngôn ngữ đều có thể ảnh hưởng đến những thao tác nào khả dụng.

Mô hình tự động hóa hai chiều của Selenium cho thấy cách hệ sinh thái client cung cấp các khả năng này. Hãy kiểm tra API cho ngôn ngữ và bản phát hành bạn sử dụng thay vì đoán và dịch một ví dụ từ ràng buộc khác.

Tạo một bảng kiểm kê tương thích ngắn cho quy trình làm việc. Bao gồm các nhóm sự kiện bắt buộc, thao tác script, xử lý ngữ cảnh và bất kỳ chức năng mạng nào. Đánh dấu đâu là thiết yếu và đâu là công cụ chẩn đoán tùy chọn. Sau đó kiểm tra bảng kiểm kê đó với môi trường thực tế.

Một trình duyệt quảng cáo kết nối BiDi không chứng minh rằng một mô-đun cụ thể đã hoàn chỉnh hoặc rằng một nhà cung cấp từ xa cung cấp nó. Bài kiểm tra có ý nghĩa là thực hiện thao tác cần thiết và quan sát phản hồi hoặc sự kiện mong đợi trong các điều kiện đại diện.

Giữ việc hỗ trợ giao thức tách biệt với tính đúng đắn của dữ liệu. Một luồng sự kiện hợp lệ có thể cùng tồn tại với một quy tắc trích xuất không chính xác. Hãy xác minh cả giao diện tự động hóa và kết quả ở cấp độ trang trước khi áp dụng quy trình làm việc.

Lập Kế Hoạch Áp Dụng BiDi Mà Không Phải Viết Lại Mọi Thứ

Việc áp dụng BiDi có thể bắt đầu với một yêu cầu quan sát có giới hạn bên cạnh tự động hóa hiện có. Chọn một tính năng có lợi ích rõ ràng và hành vi có thể được kiểm tra độc lập.

Ví dụ, một nhóm có thể cần thu thập nhật ký trình duyệt trong một luồng ứng dụng bị lỗi. Xác định ngữ cảnh liên quan, đăng ký trước hành động, và xác nhận rằng các mục chẩn đoán mong đợi được gắn với đúng trang. Giữ các kiểm tra điều hướng và trích xuất đã được thiết lập trong khi đánh giá đường quan sát mới.

Tránh coi việc di chuyển giao thức là bằng chứng về hiệu suất hoặc độ tin cậy được cải thiện. Những kết quả đó phụ thuộc vào triển khai phía client và khối lượng công việc. Đo lường công việc đại diện nếu tốc độ hoặc việc sử dụng tài nguyên là một phần của quyết định.

Ghi chép quyền sở hữu việc tạo kết nối, đăng ký sự kiện và kết thúc phiên. Các tính năng giao thức dễ bảo trì hơn khi ứng dụng có một nơi rõ ràng chịu trách nhiệm cho các quyết định vòng đời.

Vị Trí Của Scrapeless Agent Browser Trong Quyết Định Giao Thức

Scrapeless Agent Browser tài liệu hóa một kết nối trình duyệt dựa trên CDP và chức năng CDP tùy chỉnh. Một giao diện CDP được tài liệu hóa không thiết lập hỗ trợ WebDriver BiDi.

Nếu BiDi là bắt buộc cho ứng dụng của bạn, hãy xác minh yêu cầu đó một cách rõ ràng trước khi chọn phương án lưu trữ trình duyệt. Nếu quy trình làm việc yêu cầu đã sử dụng một client CDP được tài liệu hóa, hãy đánh giá con đường đó trên các tiêu chí riêng của nó. Lựa chọn phù hợp là theo các tính năng giao thức mà công việc thực sự cần.

Cuộc thảo luận về tự động hóa Selenium cung cấp bối cảnh liên quan về các quy trình làm việc do trình duyệt điều khiển. Chỉ xem lại kế hoạch Scrapeless sau khi các yêu cầu về kết nối và khả năng đã rõ ràng.

Kết luận

WebDriver BiDi đưa các lệnh và sự kiện do trình duyệt tạo ra vào một giao thức tự động hóa hai chiều. Giá trị của nó phụ thuộc vào việc theo dõi ngữ cảnh chính xác, đăng ký có phạm vi, và hỗ trợ tính năng đã được xác minh. Hãy chọn giao diện dựa trên các thao tác cụ thể, và giữ tính tương thích giao thức tách biệt với tính đúng đắn của dữ liệu mà trình duyệt tạo ra.

Khớp Quy Trình Làm Việc Của Bạn Với Một Giao Thức Được Tài Liệu Hóa

Khám phá giao diện CDP đã được tài liệu hóa trong Scrapeless Agent Browser và xác minh các yêu cầu giao thức trước khi chọn kết nối.

Đăng ký hôm nay và nhận $5 tín dụng miễn phí — không cần thẻ tín dụng.

Nhận $5 Tín Dụng Của Bạn →

Câu hỏi thường gặp

H: BiDi là viết tắt của gì?

BiDi là viết tắt của bidirectional (hai chiều). Client có thể gửi lệnh và nhận các sự kiện do trình duyệt tạo thông qua kết nối giao thức.

H: WebDriver BiDi có giống CDP không?

WebDriver BiDi và CDP là những giao thức khác nhau với các hợp đồng thông điệp khác nhau. Việc dùng chung truyền tải WebSocket không khiến các lệnh của chúng có thể thay thế cho nhau.

H: BiDi có thay thế mọi thao tác WebDriver cổ điển không?

Không nên giả định rằng BiDi sẽ thay thế mọi thao tác WebDriver cổ điển trong một ngăn xếp hiện có. Hãy đánh giá các tính năng bắt buộc và các giao diện được thư viện client hỗ trợ trước khi thay đổi một quy trình làm việc đang hoạt động.

H: Tại sao một sự kiện có thể đến trước phản hồi của lệnh?

Các sự kiện mô tả hoạt động của trình duyệt có thể xảy ra trong khi một lệnh đang được thực hiện. Hãy liên kết phản hồi với yêu cầu và diễn giải các sự kiện thông qua ngữ cảnh của chúng thay vì giả định một luồng thông điệp tuần tự duy nhất.

H: Tài liệu CDP của Scrapeless có chứng minh hỗ trợ BiDi không?

Tài liệu CDP của Scrapeless không chứng minh hỗ trợ BiDi. Một yêu cầu BiDi cần được xác minh riêng đối với endpoint, trình duyệt, client và các thao tác dự định.

Tài liệu tham khảo