WebDriver BiDi là gì?

Trình duyệt tác nhân Scrapeless cung cấp các phiên duyệt web được quản lý thông qua các giao diện kết nối được ghi chép dành cho các khách hàng tự động hóa trình duyệt.

WebDriver BiDi là một giao thức hai chiều để điều khiển trình duyệt từ xa và nhận các sự kiện từ trình duyệt. “BiDi” đề cập đến việc giao tiếp theo cả hai hướng: một client tự động hóa gửi các lệnh, và trình duyệt có thể gửi các thông điệp sự kiện khi các hoạt động đã đăng ký xảy ra. Mô hình hướng sự kiện này hỗ trợ các quan sát vốn khó diễn đạt nếu chỉ dùng những truy vấn yêu cầu–phản hồi lặp đi lặp lại.

WebDriver BiDi là một giao thức, không phải trình duyệt, trình chạy kiểm thử, hay dịch vụ lưu trữ. Bản đặc tả W3C vẫn đang trong quá trình hoàn thiện, và các bản triển khai có thể khác nhau về các mô-đun và lệnh được hỗ trợ. Vì vậy, một quá trình đánh giá cần xem xét trình duyệt thực tế, thư viện phía client, khả năng của giao thức và thao tác được yêu cầu bởi tác vụ, thay vì một khẳng định chung rằng một stack “hỗ trợ BiDi.”

Những Gì Giao Tiếp Hai Chiều Mang Lại

Truyền thông hai chiều cho phép trình duyệt báo cáo hoạt động liên quan mà không cần đợi phía khách yêu cầu cho từng sự kiện riêng lẻ. Giao thức WebDriver BiDi định nghĩa các lệnh, phản hồi, sự kiện, truyền tải và mô-đun để điều khiển và quan sát trình duyệt.

Một tương tác yêu cầu–phản hồi truyền thống là đủ cho nhiều thao tác. Khách hàng yêu cầu điều hướng và nhận được kết quả. Quan sát dựa trên sự kiện trở nên hữu ích khi trình duyệt có thể tạo ra hoạt động giữa những lệnh đó, chẳng hạn như tài liệu thay đổi ngữ cảnh hoặc một script tạo ra mục ghi log.

Cải tiến quan trọng nằm ở mô hình quan sát, chứ không phải là lời hứa rằng mọi tác vụ trình duyệt đều sẽ nhanh hơn. Nếu một tác vụ chỉ cần tiêu đề trang cuối cùng, luồng sự kiện có thể không mang lại nhiều lợi ích. Nếu một tác vụ phải liên kết hoạt động console với một lần điều hướng cụ thể, các đăng ký có thể cung cấp thông tin phù hợp hơn so với việc định kỳ yêu cầu một ảnh chụp nhanh.

Các sự kiện cũng tạo ra trách nhiệm. Khách hàng phải quyết định cần đăng ký những gì, cách liên kết các thông điệp, những sự kiện nào quan trọng đối với việc hoàn thành, và khi nào nên hủy đăng ký. Một tập hợp quan sát không giới hạn có thể trở thành vấn đề về lưu trữ và diễn giải thay vì là chẩn đoán hữu ích.

Các lệnh, Phản hồi và Sự kiện Có Vai Trò Khác Nhau

Các lệnh yêu cầu một thao tác, các phản hồi báo cáo kết quả của thao tác đó, và các sự kiện mô tả hoạt động trình duyệt đã được đăng ký. Các loại thông điệp này nên được xử lý theo vai trò của chúng thay vì được xem như một danh sách tuần tự các hành động đã hoàn tất.

Phản hồi lệnh có thể xác nhận rằng một thao tác giao thức được hỗ trợ đã hoàn tất. Một sự kiện có thể đến do hoạt động của trình duyệt được khởi tạo bởi trang hoặc một thao tác khác. Client cần đủ ngữ cảnh để liên kết quan sát với tài liệu, tác vụ và điều hướng liên quan.

Không coi việc tồn tại một sự kiện là bằng chứng rằng ứng dụng đã đạt được mục tiêu kinh doanh của nó. Một sự kiện điều hướng chỉ nói lên điều gì đó về việc điều hướng. Tác vụ vẫn có thể cần một vùng kết quả xuất hiện, một biểu mẫu được kích hoạt, hoặc một mục cụ thể được chọn.

Xác định một hợp đồng quan sát nhỏ cho tác vụ. Xác định lệnh bắt đầu công việc, các sự kiện cung cấp bằng chứng hữu ích, điều kiện trang xác lập thành công và bước dọn dẹp kết thúc quá trình quan sát. Điều này khiến quy trình làm việc theo hướng sự kiện có thể được rà soát mà không cần phải lưu giữ mọi thông điệp thô mãi mãi.

Ngữ cảnh và Danh tính Có Vai trò Quan trọng trong Tự động hóa Dựa trên Sự kiện

Danh tính ngữ cảnh xác định trang hoặc tài liệu nhúng mà một sự kiện liên quan đến. Một trình duyệt có thể chứa nhiều trang cấp cao và tài liệu con, vì vậy một kết nối không ngụ ý chỉ có một tài liệu được quan tâm.

The Mô hình bối cảnh duyệt HTML cung cấp sự phân biệt cơ bản giữa các tài liệu của trình duyệt và mối quan hệ giữa chúng. Một cửa sổ bật lên, một khung lồng nhau và một thao tác điều hướng mỗi cái đều có thể ảnh hưởng đến tài liệu nào nên được quan sát hoặc kiểm soát.

Một ví dụ thực tế là một ứng dụng mở hóa đơn trên một trang riêng. Lần nhấp khởi tạo thuộc về trang gốc, nhưng điều kiện sẵn sàng của hóa đơn lại thuộc về ngữ cảnh mới. Một tác vụ tiếp tục đọc tài liệu gốc có thể kết luận rằng không có hóa đơn nào tồn tại ngay cả khi trình duyệt đã mở nó thành công.

Nhận dạng khung yêu cầu mức độ cẩn trọng tương tự. Một thông báo nhật ký từ một tiện ích nhúng không nên tự động được gán cho ứng dụng cha. Giữ nguyên danh tính ngữ cảnh trong các bản ghi chẩn đoán để các quan sát có thể được liên kết với tài liệu đã tạo ra chúng.

Các đăng ký cần Phạm vi và Vòng đời

Một đăng ký nên bao quát các sự kiện và ngữ cảnh cần thiết cho một tác vụ, chỉ trong khoảng thời gian mà tác vụ cần đến chúng. Điều này giới hạn cả nhiễu chẩn đoán và khả năng lưu giữ thông tin trang không liên quan.

Thiết lập quan sát trước hoạt động mà bạn cần bằng chứng. Nếu một trang có thể tạo ra sự kiện liên quan ngay sau một hành động, việc gắn một bộ quan sát sau đó có thể tạo ra khoảng trống. Kiểm tra hành vi vòng đời của ràng buộc client thực tế thay vì giả định rằng thứ tự được xử lý tự động.

Chọn nội dung cần lưu trữ sau khi thu thập. Một bản ghi súc tích về loại sự kiện, định danh ngữ cảnh và kết quả liên quan có thể là đủ cho bản tóm tắt công việc. Các thông điệp nhật ký đầy đủ hoặc chi tiết mạng có thể chứa dữ liệu ứng dụng nhạy cảm, vì vậy bản ghi được giữ lại phải phù hợp với yêu cầu khắc phục sự cố.

Đóng các đăng ký khi chủ sở hữu của chúng kết thúc. Một client sống lâu điều khiển nhiều tác vụ không nên vô tình gắn bộ quan sát của tác vụ trước vào một tác vụ sau. Việc sở hữu một cách rõ ràng giúp dễ giải thích cả những quan sát bị thiếu và những quan sát xuất hiện trong công việc không đúng.

WebDriver BiDi, WebDriver cổ điển và CDP

WebDriver BiDi, WebDriver cổ điển và Chrome DevTools Protocol là các giao diện điều khiển khác nhau. Việc cùng sử dụng tự động hóa trình duyệt hoặc truyền tải WebSocket không khiến chúng có thể thay thế cho nhau.

Phần mô hình lệnh WebDriver cổ điển định nghĩa các thao tác trình duyệt từ xa thông qua giao diện tiêu chuẩn hóa của nó. BiDi bổ sung một mô hình giao thức hai chiều. CDP có bề mặt lệnh và sự kiện riêng gắn liền với công cụ Chromium. Hãy lựa chọn dựa trên phạm vi hỗ trợ trình duyệt thực tế và các thao tác mà ứng dụng của bạn cần.

Việc chuyển đổi không bắt buộc phải thay thế tất cả thao tác cùng lúc. Xác định quan sát cần BiDi, rồi kiểm tra cách client đã chọn kết hợp nó với điều khiển trình duyệt hiện có. Tránh viết lại toàn bộ giao thức khi nhu cầu chỉ là một khả năng chẩn đoán hẹp.

Hỗ Trợ Trình Duyệt Phải Được Đánh Giá Theo Từng Thao Tác

Hỗ trợ trình duyệt cho WebDriver BiDi nên được đánh giá theo từng thao tác và môi trường. Một kết nối thành công sẽ thiết lập truyền tải, trong khi một đăng ký hoặc lệnh được hỗ trợ sẽ thiết lập một khả năng hẹp hơn.

Phần bề mặt client Selenium BiDi cung cấp ngữ cảnh triển khai cho các ứng dụng sử dụng Selenium. Nó không loại bỏ nhu cầu kiểm tra tổ hợp ràng buộc ngôn ngữ và trình duyệt thực tế. Một tính năng được minh họa bằng một ngôn ngữ có thể có giao diện hoặc trạng thái hỗ trợ khác ở ngôn ngữ khác.

Tạo một danh sách kiểm tra khả năng gắn với công việc. Với mỗi thao tác bắt buộc, hãy chỉ rõ môi trường trình duyệt, phương thức client, hành vi giao thức mong đợi, và điều kiện chứng minh nó hoạt động. Ghi lại rõ ràng các khả năng không được hỗ trợ để một sự kiện vắng mặt không bị chẩn đoán nhầm là kết quả rỗng của ứng dụng.

Tránh sao chép các cờ thử nghiệm cũ hoặc ví dụ kết nối mà không kiểm tra tài liệu hiện tại. Công việc với giao thức luôn phát triển, và cấu hình từng kích hoạt một tính năng dùng thử có thể không còn mô tả đường dẫn được hỗ trợ. Bảng thuật ngữ này cố ý không cung cấp mã kết nối chưa được thực thi hoặc bảng hỗ trợ phổ quát nào.

Một Kịch Bản Chấp Nhận BiDi Hữu Ích

Một kịch bản chấp nhận hữu ích liên kết một sự kiện với kết quả hiển thị trên trang. Trên một ứng dụng thử nghiệm được kiểm soát, hãy sắp xếp để một thao tác trên trang mở một tài liệu đã biết và phát ra một thông điệp chẩn đoán có thể nhận diện.

Đăng ký phạm vi và hạng mục sự kiện cần thiết trước khi bắt đầu thao tác. Thực hiện thao tác, xác định ngữ cảnh tài liệu mới, và kiểm tra điều kiện trang đích. Bài kiểm tra chỉ đạt khi quan sát mong đợi thuộc về đúng ngữ cảnh mong đợi và kết quả ứng dụng là chính xác.

Đồng thời kiểm tra cả việc dọn dẹp. Kết thúc quan sát, thực hiện công việc không liên quan, và xác nhận rằng tác vụ cũ không tiếp tục tích lũy bằng chứng. Điều này kiểm tra quyền sở hữu đăng ký, điều mà một ví dụ hành trình suôn sẻ thường bỏ qua.

Giữ tách biệt kết quả giao thức và kết quả nghiệp vụ trong báo cáo. Một đăng ký thất bại, một ngữ cảnh bị đóng và một bản ghi trang bị thiếu cần các lời giải thích khác nhau. Sự phân biệt đó đặc biệt hữu ích trong thực thi từ xa, nơi nhiều lớp hạ tầng và ứng dụng có thể lỗi độc lập.

Sử Dụng Các Khái Niệm BiDi Với Scrapeless

Các khái niệm BiDi giúp giải thích tự động hóa hướng sự kiện, nhưng một endpoint Scrapeless phải được sử dụng thông qua giao thức được tài liệu hóa của nó. Phần bề mặt Agent Browser CDP tài liệu hóa các thao tác CDP; nó không phải là bằng chứng về một endpoint WebDriver BiDi.

Nền tảng Agent Browser cung cấp các tính năng thực thi và quan sát trình duyệt được quản lý. Phần thảo luận về bảng điều khiển trình duyệt và chẩn đoán phiên mang đến bối cảnh vận hành liên quan, trong khi giá Scrapeless hỗ trợ việc lập kế hoạch khối lượng công việc. Hãy xác minh giao diện bắt buộc trước khi chuyển một khái niệm giao thức thành tích hợp sản phẩm.

Kết luận

WebDriver BiDi biến các sự kiện trình duyệt thành một phần của cuộc trao đổi điều khiển. Hãy sử dụng nó khi quan sát dựa trên sự kiện giải quyết một yêu cầu đã được xác định, và thiết kế nhận dạng ngữ cảnh, phạm vi đăng ký, điều kiện hoàn thành và quy trình dọn dẹp cùng nhau. Khả năng tương thích được xác lập bởi những thao tác mà trình duyệt và client thực của bạn có thể thực hiện, chứ không phải chỉ bởi tên giao thức.