Xác định phần tử, chờ đến khi có thể tương tác, kích hoạt hành động và kiểm tra kết quả: mỗi hành động tự động hóa gồm bốn bước này. Hiểu selector, tải động, iframe và shadow DOM giúp script hoạt động ổn định lâu hơn.
Tự động hóa web thường được hiểu là để chương trình bấm nút thay bạn. Nhưng khi thực sự triển khai, bạn sẽ thấy một hành động gồm bốn bước, và chỉ cần một bước làm sai thì biểu hiện có thể giống như chẳng có gì xảy ra.
Trước hết cần phân biệt hai khái niệm dễ bị nhầm. Tự động hóa web có phạm vi rộng hơn: dùng chương trình để làm những việc vốn cần con người thao tác trên trang web, bao gồm cả lấy dữ liệu trực tiếp bằng request. Tự động hóa trình duyệt là một nhánh cụ thể hơn: chương trình điều khiển trình duyệt thật để mở trang, chạy JavaScript và mô phỏng thao tác nhấp hoặc nhập liệu. Với các tình huống có nhiều nội dung động hoặc tương tác phức tạp, thường phải dùng cách thứ hai.
Bốn bước của một hành động
- Xác định phần tử: Dùng id, name, class, CSS selector hoặc XPath để khóa mục tiêu. Ưu tiên thuộc tính có ý nghĩa; chỉ quay lại cấu trúc hoặc chỉ số khi thật sự cần.
- Chờ đến khi có thể tương tác: Phần tử xuất hiện trong DOM không có nghĩa là đã bấm được. Hãy chờ đến khi nó hiển thị, có thể nhấp, hoặc chờ một request cụ thể trả về. Thứ cần chờ là điều kiện, không phải số giây.
- Kích hoạt hành động: Nhấp, nhập hoặc cuộn. Component tùy chỉnh thường phải tái hiện đúng trình tự của người dùng: mở trước, chờ danh sách render, rồi chọn theo văn bản.
- Kiểm tra kết quả: Sau khi thao tác, phải xác nhận kết quả có đúng không. Kiểm tra link có đổi không, nội dung trên trang có đổi không, hoặc API trả về gì. Thiếu bước này, lỗi có thể bị coi là thành công và các lần retry hay cảnh báo sau đó sẽ không có cơ sở đáng tin cậy.
Trong bốn bước, bước thứ hai và thứ tư thường tốn nhiều thời gian debug nhất. Không phải vì chúng khó, mà vì chúng thường không báo lỗi và chỉ âm thầm tạo ra kết quả sai.
Độ ổn định của selector quyết định script chạy được bao lâu
Khi trang thay đổi, locator viết cứng sẽ dễ mất hiệu lực. Xác định theo nội dung, vị trí hoặc chỉ số là cách kém bền nhất trước thay đổi: chỉ cần thêm một nút hoặc đổi một câu nhắc là mọi thứ có thể sai lệch.
Nếu có thể, hãy ưu tiên id, name hoặc thuộc tính data. Nếu buộc phải dùng locator theo cấu trúc, hãy gom chúng vào một chỗ để khi thay đổi chỉ sửa một nơi thay vì hàng chục dòng. Cũng đừng kỳ vọng viết xong là không cần bảo trì nữa; website cập nhật là chuyện bình thường và phần lớn chi phí bảo trì thường nằm ở đây.
Tải động: chờ điều gì quan trọng hơn chờ bao lâu
Ngày nay rất ít trang có mọi thứ sẵn sàng ngay sau khi tải ban đầu xong. Dữ liệu được render bằng request bất đồng bộ, vì vậy phần tử thường xuất hiện muộn hơn bạn nghĩ.
Chờ cố định là cách phổ biến nhưng cũng rất dễ hỏng: sleep 3 giây có thể không đủ trên máy chậm và chỉ lãng phí thời gian trên máy nhanh. Cách đúng là chờ một điều kiện được thỏa mãn rồi mới thao tác khi phần tử thực sự có thể nhấp.
Không tìm thấy phần tử thì kiểm tra iframe và shadow DOM trước
Khi phần tử rõ ràng có trên trang nhưng script vẫn không tìm thấy, nguyên nhân thường không phải selector mà là phạm vi tìm kiếm.
iframe là một document độc lập. Cần chuyển vào frame tương ứng trước khi tìm phần tử và chuyển ra sau khi thao tác xong; nếu không, các lần tìm tiếp theo sẽ diễn ra trong context sai. Node bên trong shadow DOM không thể được CSS selector bên ngoài bắt trực tiếp. Phải lấy shadow root trước rồi tìm bên trong nó. Hai trường hợp này thường bị hiểu nhầm là trang đã đổi giao diện và làm mất nhiều thời gian debug.
Còn hai việc dễ bị bỏ sót
Thứ nhất là session. Với tác vụ cần đăng nhập, phải nghĩ cách lưu và tái sử dụng trạng thái đã xác thực. Nếu không, mỗi lần chạy đều phải đăng nhập lại và còn có thể mắc ở bước verification.
Thứ hai là environment. Khi mọi tác vụ dùng chung một browser environment, session và cache có thể làm ảnh hưởng lẫn nhau. Những tác vụ chạy riêng vẫn ổn có thể bắt đầu xung đột khi chạy chung. Khi chuyển từ một tác vụ sang nhiều tác vụ, tách environment isolation thành một lớp riêng sẽ giúp giảm nhiều rắc rối. Công cụ như PurpleMark cung cấp fingerprint độc lập và proxy độc lập cho từng environment, còn automation framework chỉ tập trung thực thi hành động.
Có một ranh giới nên xác nhận trước khi bắt đầu
Automation có thể thay thế thao tác lặp lại, nhưng không thể thay thế các bước cần người thật tham gia. Nếu target workflow có xác minh khuôn mặt theo thời gian thực hoặc kiểm duyệt thủ công, quy trình đó không thể tự động hóa 100%.
Vì vậy, trước tiên hãy kiểm tra theo cách đơn giản nhất: tự đi thủ công toàn bộ workflow từ đầu đến cuối, ghi lại từng bước và xác nhận có bước nào không thể vượt qua hay không. Sau đó mới quyết định nên đầu tư bao nhiêu công sức phát triển. Khả thi về kỹ thuật và được quy định cho phép cũng là hai chuyện khác nhau, vì vậy cần xem trước điều khoản dịch vụ của target platform.
