Tìm hiểu khi nào tự động hóa Android nên sử dụng bộ chọn giao diện người dùng, OCR, so khớp mẫu hoặc phát hiện đối tượng—và cách dừng an toàn khi bằng chứng trực quan không chắc chắn. LaiCai Screen Mirroring.
Tự động hóa trực quan bắt đầu bằng một quyết định chứ không phải một cú nhấn
Tự động hóa Android trở nên mong manh khi quy trình làm việc giả định rằng nút tiếp theo luôn ở cùng tọa độ. Màn hình thiết bị di động thay đổi theo kích thước thiết bị, ngôn ngữ, tỷ lệ phông chữ, trạng thái bàn phím, quyền, thời gian mạng và cập nhật ứng dụng. Quy trình làm việc an toàn hơn trước tiên sẽ quan sát màn hình hiện tại, chọn bằng chứng, kiểm tra xem kết quả có đủ tốt hay không và chỉ sau đó mới thực hiện một hành động. Mẫu quan sát-chọn-hành động này là nền tảng của tự động hóa giao diện người dùng trực quan.
Trong LaiCai Flow, các nút quan sát như phân tích giao diện người dùng, tìm giao diện người dùng, OCR, khớp mẫu và phát hiện đối tượng không tự nhấp vào. Họ trả về kết quả có cấu trúc. Một bước dữ liệu riêng biệt có thể chọn mục tốt nhất và một bước con trỏ có thể chạm vào tâm của nó. Sự tách biệt này làm cho biểu đồ có thể xem lại được và ngăn kết quả nhận dạng âm thầm trở thành một hành động.
Đối với tính năng Phản chiếu màn hình LaiCai, lời hứa hữu ích không phải là khả năng nhận dạng hoàn hảo. Đây là quy trình tự động hóa Android trực quan, trong đó các nhóm có thể kiểm tra ảnh chụp màn hình, đầu ra nhận dạng, ngưỡng, nhật ký, nhánh và điều kiện dừng trước khi lặp lại tác vụ trên các thiết bị hoặc trình mô phỏng được ủy quyền.
Chọn bộ chọn giao diện người dùng trước OCR khi cấu trúc đáng tin cậy
Khả năng truy cập và phân cấp giao diện người dùng của Android có thể hiển thị văn bản, mô tả nội dung, giới hạn, tên lớp và các thuộc tính có cấu trúc khác. Khi mục tiêu xuất hiện một cách đáng tin cậy trong hệ thống phân cấp đó, bộ chọn giao diện người dùng thường dễ duy trì hơn so với OCR hoặc khớp hình ảnh. Nó có thể vẫn hữu ích trong các chủ đề, những thay đổi nhỏ về màu sắc và mật độ pixel khác nhau.
Bắt đầu bằng cách kiểm tra cây giao diện người dùng hiện tại. Tìm kiếm văn bản ổn định hoặc mô tả nội dung, sau đó lọc hoặc chọn kết quả trước khi nhấn. Đừng cho rằng cụm từ như “tìm văn bản hiển thị” phải luôn có nghĩa là OCR; bằng chứng màn hình nên quyết định. Bộ chọn có cấu trúc sẽ thích hợp hơn khi ứng dụng hiển thị cấu trúc có ý nghĩa. Bộ chọn
vẫn có giới hạn. Chế độ xem canvas, trò chơi, bề mặt được truyền trực tuyến, kết xuất tùy chỉnh và một số WebView có thể hiển thị ít thứ bậc hữu ích. Nhãn dịch cũng thay đổi. Khi mục tiêu hiển thị với một người nhưng không có trong cây giao diện người dùng, OCR hoặc nhận dạng hình ảnh sẽ trở thành một phương án dự phòng hợp lý thay vì công cụ mặc định đầu tiên.
Sử dụng OCR khi văn bản hiển thị nhưng không có bộ chọn
OCR hữu ích khi ý nghĩa kinh doanh được thể hiện bằng các từ hiển thị: trạng thái đơn hàng, nhãn được bản địa hóa, thông báo xác nhận, biểu ngữ lỗi, giá, tên tài khoản kiểm tra hoặc kết quả tìm kiếm. Luồng có thể chụp màn hình, đọc vùng giới hạn hoặc toàn khung hình, chuẩn hóa kết quả và so sánh kết quả với văn bản dự kiến trước khi tiếp tục.
OCR mang tính xác suất. Phông chữ nhỏ, nén, chuyển màu, hoạt ảnh, tập lệnh bất thường, độ tương phản thấp và các điều khiển chồng chéo có thể làm giảm độ chính xác. Một vùng cố định cũng có thể bỏ lỡ mục tiêu khi bố cục, hướng, bàn phím hoặc ngôn ngữ thay đổi. Do đó LaiCai coi các vùng OCR có thể tái sử dụng là tài sản rõ ràng; việc tạo một vùng cố định đòi hỏi người dùng phải hiểu giả định vị trí đó.
Kiểm tra đáng tin cậy ghi lại cả văn bản được nhận dạng và ảnh chụp màn hình được sử dụng để tạo ra văn bản đó. Sử dụng quy tắc độ tin cậy tối thiểu nếu có, chấp nhận một nhóm nhỏ các biến thể hợp lệ và dừng lại với lý do có thể đọc được khi thiếu văn bản bắt buộc. Không bao giờ chuyển đổi trực tiếp kết quả OCR có độ tin cậy thấp thành một thao tác nhấn phá hoại.
Sử dụng đối sánh mẫu cho các mục tiêu trực quan ổn định
Đối sánh mẫu phù hợp khi mục tiêu trực quan ổn định không có văn bản hoặc bộ chọn giao diện người dùng đáng tin cậy: biểu tượng đặc biệt, huy hiệu, điều khiển trò chơi, đồ họa xác nhận tùy chỉnh hoặc nút chỉ hình ảnh. Mẫu phải đến từ màn hình được chụp thực và Luồng phải tham chiếu nội dung hiện có thay vì phát minh ra tệp hoặc mục tiêu.
Chất lượng so khớp phụ thuộc vào chất lượng cắt, tỷ lệ, chủ đề, chế độ màu, hoạt ảnh và vùng tìm kiếm. Một khuôn mẫu chặt chẽ có thể đặc biệt nhưng dễ vỡ; một loại cây trồng rộng có thể bao gồm việc thay đổi nội dung. Các đội nên kiểm tra nhiều trạng thái thiết bị thực tế và giữ ngưỡng đủ cao để tránh các trận đấu không liên quan mà không khiến cho biến thể thông thường không thể thực hiện được.
Bối cảnh nội dung LaiCai hiện tại xác nhận rằng các mẫu là nội dung được đặt tên có thể tái sử dụng và việc so khớp hỗ trợ điểm số, chế độ và khu vực tìm kiếm tỷ lệ màn hình. Bài viết không khẳng định rằng một mẫu có thể hoạt động ở mọi nơi. Chế độ tối, bản địa hóa, bố cục đáp ứng hoặc thiết kế lại có thể yêu cầu bộ chọn, mẫu khác hoặc điểm dừng có chủ ý.
Phát hiện đối tượng giải quyết một vấn đề khác
Phát hiện đối tượng không phải là phiên bản mạnh hơn của OCR. Nó trả lời một câu hỏi khác: một thể hiện của một lớp được đào tạo như người, phương tiện hoặc đối tượng dành riêng cho sản phẩm ở đâu? OCR trích xuất văn bản; khớp mẫu trông giống nhau về mặt hình ảnh; phát hiện tìm thấy các lớp được xác định bởi một mô hình.
Chỉ sử dụng tính năng phát hiện khi mô hình có sẵn chứa lớp mà quy trình công việc cần. Luồng phải đọc siêu dữ liệu mô hình và danh sách lớp thay vì đoán nhãn. Đầu ra phát hiện vẫn cần logic lựa chọn—ví dụ: độ tin cậy cao nhất, trung tâm gần nhất hoặc tất cả các mục trên ngưỡng—trước bất kỳ hành động con trỏ nào.
Đối với các nút ứng dụng thông thường, bộ chọn giao diện người dùng, OCR hoặc mẫu thường đơn giản hơn. Việc phát hiện trở nên hữu ích đối với các đối tượng có thể thay đổi về hình dáng hoặc vị trí. Nó vẫn phải để lại bằng chứng và dừng lại khi độ tin cậy, đẳng cấp hoặc số lượng không đáp ứng được kỳ vọng của quy trình làm việc.
Xây dựng quy trình quan sát-chọn-hành động an toàn
Quy trình an toàn có thể được biểu thị dưới dạng sáu giai đoạn hiển thị: nắm bắt trạng thái, kiểm tra cấu trúc giao diện người dùng, chọn phương pháp nhận dạng phù hợp, chọn kết quả, xác minh độ tin cậy hoặc ý nghĩa kinh doanh và hành động. Sau hành động, hãy đợi rõ ràng để màn hình ổn định và quan sát lại.
Xem xét kiểm tra QA bản địa hóa. Mở bản dựng dàn dựng, đợi màn hình chính, điều hướng bằng bộ chọn ổn định, chụp màn hình đã dịch, chạy OCR trên tiêu đề, lưu ảnh chụp màn hình và dừng nếu không có cụm từ bản địa hóa dự kiến. Flow tạo ra bằng chứng mà không thay đổi dữ liệu sản xuất.
Duy trì việc xử lý lỗi ở mức thận trọng. Nếu giao diện người dùng tìm thấy không trả về mục nào, OCR bỏ lỡ văn bản bắt buộc, điểm mẫu quá thấp hoặc phát hiện tìm thấy số lượng không mong muốn, hãy để Luồng không thành công hoặc phân nhánh đến đường dẫn bằng chứng và điểm dừng rõ ràng. Không gửi lỗi trở lại hành động tương tự trong vòng lặp thử lại vô hình.
Khắc phục sự cố nhận dạng mà không che giấu sự không chắc chắn
Khi nhận dạng không thành công, trước tiên hãy kiểm tra ảnh chụp màn hình và kết quả thô thay vì hạ thấp mọi ngưỡng. Xác nhận rằng ứng dụng nằm trên trang dự kiến, bàn phím hoặc hộp thoại cấp phép không bao gồm mục tiêu, thời gian chờ đủ lâu và vùng tìm kiếm có chứa phần tử.
Đối với OCR, so sánh các tập lệnh, khoảng cách, dấu câu, viết hoa và khả năng thay thế ký tự. Đối với các mẫu, hãy kiểm tra tỷ lệ, chủ đề, cắt xén và các trận đấu cạnh tranh. Để tìm giao diện người dùng, hãy kiểm tra xem mục tiêu ở ngoài màn hình hay bị ẩn khỏi hệ thống phân cấp. Để phát hiện, hãy xác minh mô hình đã chọn và danh sách lớp thực tế của nó.
Thay đổi từng biến một và chạy lại thăm dò chỉ đọc khi có thể. Ngưỡng thấp hơn có thể làm tăng khả năng thu hồi nhưng cũng có thể gây ra kết quả dương tính giả. Một khu vực lớn hơn có thể tìm thấy mục tiêu nhưng gây ra sự xao lãng. Kết quả đúng không phải là “nút đã được thông qua”; đó là bằng chứng đủ mạnh cho hành động được phê duyệt tiếp theo.
Quy trình làm việc thực tế cho QA, bản địa hóa và hỗ trợ Các nhóm QA của
có thể sử dụng tính năng kiểm tra trực quan cho đường dẫn khói, biểu ngữ lỗi, hộp thoại đồng ý, ảnh chụp màn hình và bằng chứng phát hành. Nhóm bản địa hóa có thể so sánh các tiêu đề, nhãn bị cắt bớt, bản dịch bị thiếu và văn bản dự phòng không mong muốn trên các thiết bị và ngôn ngữ. Các nhóm hỗ trợ có thể tạo lại đường dẫn được báo cáo và ảnh chụp màn hình cùng với nhật ký cho nhà phát triển.
Các quy trình công việc này bổ sung cho các thử nghiệm đơn vị, thiết bị đo lường và tích hợp cấp mã; họ không thay thế chúng. Kiểm tra trực quan đặc biệt hữu ích đối với trạng thái được hiển thị mà một người nhìn thấy, trong khi kiểm tra cấp mã vẫn tốt hơn đối với các xác nhận xác định và logic nội bộ.
Sử dụng tổng quan về Công cụ tự động hóa AI Android, Hướng dẫn LaiCai Flow, hướng dẫn phản chiếu màn hình Android và quy trình kiểm thử ứng dụng dành cho thiết bị di động làm lộ trình đọc tiếp theo.
Danh sách kiểm tra đánh giá trước lần chạy thực đầu tiên
Trước lần chạy thực đầu tiên, hãy xác nhận thiết bị và ứng dụng được cấp phép, trạng thái bắt đầu rõ ràng và quy trình làm việc không đoán các gói, nội dung, tọa độ hoặc lớp mô hình. Kiểm tra để chắc chắn rằng mọi kết quả nhận dạng đều được lựa chọn có chủ ý và các hành động nhạy cảm cần có điều kiện mạnh mẽ hoặc sự xem xét của con người.
Xác minh rằng ảnh chụp màn hình và nhật ký không làm lộ dữ liệu riêng tư của khách hàng. Thêm ranh giới dừng rõ ràng trước khi thanh toán, xóa, cài đặt tài khoản, tin nhắn gửi đi hoặc các thay đổi sản xuất không thể đảo ngược. Tránh tương tác giả mạo, spam, lạm dụng tài khoản, trốn tránh quy tắc, thu thập dữ liệu riêng tư và gian lận trong trò chơi.
Cuối cùng, hãy xem lần chạy đầu tiên qua màn hình Android được phản chiếu. Xem lại biểu đồ, trạng thái giao diện người dùng, văn bản OCR, điểm trận đấu, giới hạn đã chọn, ảnh chụp màn hình và lý do dừng cùng nhau. Tính năng tự động hóa nhận dạng hình ảnh và OCR đáng tin cậy của Android xuất phát từ bằng chứng có thể kiểm tra được chứ không phải từ sân khấu đáng tin cậy.