Một quy trình làm việc Android an toàn không liên tục nhấn vào cho đến khi có điều gì đó xảy ra. Nó xác định màn hình hiện tại, giới hạn số lần thử lại, xác minh trạng thái tiếp theo và dừng lại với bằng chứng khi kết quả không chắc chắn.
Câu trả lời ngắn gọn: dừng lại khi hành động tiếp theo không còn hợp lý nữa.
Điều kiện dừng tự động hóa Android là một quy tắc ngăn chặn quy trình làm việc tiếp tục khi màn hình, kết quả hoặc thời gian hiện tại không còn hỗ trợ hành động tiếp theo. Nó có thể kết thúc quá trình chạy, trả về kết quả được kiểm soát, thu thập bằng chứng hoặc gửi trường hợp cho một người. Điểm quan trọng không phải là dừng lại ở mọi bất ngờ. Điểm quan trọng là tránh biến sự không chắc chắn thành một cú chạm khác.
Các quy trình làm việc đáng tin cậy trả lời bốn câu hỏi trước mỗi hành động quan trọng: Điện thoại nên ở trạng thái nào? Quan sát nào chứng minh trạng thái đó? Có bao nhiêu lần thử khôi phục là chấp nhận được? Những bằng chứng nào nên được lưu giữ nếu trạng thái đó không bao giờ xuất hiện? Android UI Automator bao gồm chờ đợi có điều kiện và kiểm tra độ ổn định, trong khi WorkManager ghi lại các tài liệu về việc hủy bỏ và xử lý công việc bị dừng lại. Bài học thiết kế phổ biến là đơn giản: chờ đợi, thử lại và dừng lại cần có giới hạn rõ ràng.
- Chỉ tiếp tục khi trạng thái mong đợi được xác định một cách tích cực.
- Chỉ thử lại khi sự cố thất bại là tạm thời và thử lại có giới hạn rõ ràng.
- Dừng lại hoặc yêu cầu xem xét khi màn hình không rõ ràng, hành động nhạy cảm hoặc điều kiện sau không thành công.
Tiếp tục, chờ đợi, thử lại, dừng lại hoặc xem xét?
| quyết định | Sử dụng nó khi nào | Giới hạn yêu cầu | Bằng chứng cần lưu giữ |
|---|---|---|---|
| tiếp tục | Tình trạng hiện tại và hành động tiếp theo đều được mong đợi | Một quá trình chuyển đổi đã được xem xét | Trạng thái được quan sát và hậu điều kiện |
| đợi | Ứng dụng vẫn đang tải hoặc đang ổn định | Thời gian chờ hoặc trạng thái sẵn sàng được đặt tên | Thời gian trôi qua và màn hình cuối cùng |
| làm lại | Một tình trạng tạm thời có thể được giải quyết mà không thay đổi ý nghĩa kinh doanh | Số lần thử tối đa cộng với khoảng thời gian giữa các | Số lần thử và kết quả của mỗi lần quan sát |
| dừng lại | Trạng thái không được xác định, không hợp lệ, không an toàn hoặc nằm ngoài đường dẫn đã được phê duyệt. | Giải lao ngay lập tức | Dừng lý do, chụp màn hình, kết quả có cấu trúc |
| Đánh giá của con người | Quy trình làm việc không thể quyết định một cách an toàn hoặc hành động tiếp theo có hậu quả quan trọng | Đặt rõ thời hạn chuyển giao và chủ sở hữu | Gói bằng chứng đầy đủ và bước tiếp theo được đề xuất |
Những lựa chọn này không thể thay thế cho nhau. Việc chờ đợi cho phép trạng thái tương tự thời gian để ổn định. Việc thử lại lặp lại hành động quan sát hoặc khôi phục bị giới hạn. Một nhánh chọn giữa các kết quả đã biết. Việc dừng kết thúc đường dẫn đã xem xét. Việc xem xét của con người là phù hợp khi tự động hóa thiếu đủ bằng chứng để lựa chọn một cách an toàn.
Bước 1: đặt tên cho các tiểu bang trước khi chọn các hành động
Đến cuối bước này, mỗi màn hình quan trọng đều có tên và một bộ nhỏ các sự kiện có thể quan sát được. Bắt đầu với một quy trình làm việc hẹp như mở một phiên bản thử nghiệm, điều hướng đến trang cài đặt, thay đổi một tùy chọn không nhạy cảm và xác nhận trạng thái mới. Đừng bắt đầu với một chuỗi tọa độ dài.
- Viết trạng thái bắt đầu, trạng thái tiếp theo dự kiến và các trạng thái thay thế có thể chấp nhận được.
- Đối với mỗi trạng thái, hãy chọn tín hiệu hữu ích hẹp nhất: thuộc tính UI, văn bản có thể nhìn thấy, hình ảnh đã biết, đối tượng được phát hiện hoặc ảnh chụp màn hình được tập trung.
- Đánh dấu bất kỳ màn hình nào không bao giờ được thực hiện hành động tự động, chẳng hạn như tài khoản, quyền truy cập, mua hàng, xóa hoặc màn hình dữ liệu sản xuất không mong muốn.
Việc xác minh rất đơn giản: một người đánh giá khác nên có thể xem xét định nghĩa trạng thái và giải thích tại sao hành động tiếp theo được phép. cáiHướng dẫn nhấp chuột tự động nhận dạng hình ảnhcho thấy tại sao việc tìm kiếm mục tiêu trực quan không đủ. Quy trình làm việc vẫn cần một điều kiện tiên quyết trước khi nhấn và một điều kiện hậu quả sau đó.
Bước 2: chọn một quan sát chứng minh từng trạng thái
Đến cuối bước này, mỗi trạng thái có một quan sát chính và một nguồn bằng chứng dự phòng. Sử dụng cấu trúc UI cho các sự kiện ngữ nghĩa như nhãn, trạng thái được chọn, điều khiển được bật hoặc số lượng mục. Sử dụng OCR khi văn bản có thể nhìn thấy nhưng cây UI không hiển thị nó một cách đáng tin cậy. Sử dụng khớp mẫu cho mục tiêu trực quan đã biết và phát hiện đối tượng cho một lớp đã được xác thực có vị trí hoặc kích thước thay đổi.
Tránh chồng chéo nhiều tín hiệu yếu và gọi kết quả chắc chắn của sự kết hợp. Một ảnh chụp màn hình rộng, một mẫu chưa được xác thực và một kết quả OCR một phần không tự động đưa ra quyết định đáng tin cậy. Thay vào đó, xác định một quan sát chịu tải và ghi lại các tín hiệu khác làm bằng chứng hỗ trợ. cáiSo sánh kiểm tra trực quan của Androidgiải thích nơi trạng thái UI, OCR, ảnh chụp màn hình, mẫu và nhận dạng phù hợp với từng mục.
Xác minh có nghĩa là kiểm tra cả mẫu dương và mẫu âm. Điều kiện phải vượt qua màn hình dự định và thất bại trên một màn hình tương tự về mặt hình ảnh nhưng không chính xác. Nếu nó không thể phân biệt được các trạng thái đó, hãy thu hẹp vùng, thay đổi tín hiệu hoặc dừng quy trình làm việc trước khi thực hiện hành động.
Bước 3: đặt ngân sách xung quanh mỗi lần chờ đợi và thử lại
Đến cuối bước này, không có vòng lặp nào có thể chạy mãi mãi. Mỗi lần chờ đợi đều cần phải có thời gian chờ hoặc một điều kiện sẵn sàng được đặt tên. Mỗi lần thử lại đều cần có số lần thử tối đa, khoảng thời gian hợp lý và lý do tại sao việc thử lại có thể thành công mà không làm tình hình tồi tệ hơn.
| Mô hình thất bại | Tại sao một nỗ lực khác có thể giúp ích | Vùng biên giới an toàn | Dừng lý do |
|---|---|---|---|
| Màn hình vẫn đang tải | Tình trạng tương tự có thể sẵn sàng | Chờ cho đến khi ổn định hoặc hết thời gian chờ đợi | Tình trạng sẵn sàng chưa đạt được |
| Nguyên tố tạm thời không có mặt | Nội dung có thể đến sau một khoảng thời gian trì hoãn ngắn. | Quan sát lại một lần nữa trong một số lần thử cố định | Nguyên tố dự kiến chưa bao giờ xuất hiện |
| Nhấn không tạo ra sự chuyển tiếp nào | Đầu vào có thể đã bị bỏ lỡ một lần | Một lần lặp lại đã được xem xét sau khi kiểm tra màn hình | Điều kiện hậu kỳ vẫn chưa có |
| Hiển thị hộp thoại hoặc tài khoản không xác định | Một nỗ lực khác không làm giảm sự không chắc chắn | Không thử lại | Tình trạng không mong muốn yêu cầu xem xét lại |
| Hành động có thể xóa, mua, gửi hoặc xuất bản | Việc lặp lại mù quáng có thể sao chép hậu quả | Không tự động thử lại trừ khi tính idempotency được chứng minh | Kết quả hành động nhạy cảm là không chắc chắn |
Các câu hỏi của cộng đồng về tự động hóa Android thường mô tả các vòng lặp chờ mãi mãi hoặc các tác vụ xuất hiện bị kẹt. Quy tắc số lần thử tối đa là hữu ích, nhưng số lần đếm nên tuân theo thao tác. Kiểm tra chỉ đọc có thể dung thứ nhiều lần thử hơn một hành động thay đổi trạng thái. Số chính xác là ngân sách được xem xét nhỏ nhất bao gồm độ trễ bình thường.
Bước 4: xác minh điều kiện sau trước khi tuyên bố thành công
Đến cuối bước này, một thao tác nhấn được thực hiện sẽ không còn được coi là một nhiệm vụ hoàn thành. Sau mỗi hành động thay đổi trạng thái, hãy đợi giao diện ổn định và quan sát kết quả mong đợi. Nếu điều kiện sau thiếu, quy trình làm việc không được tiếp tục lặng lẽ vào hành động tiếp theo.
- Ghi lại trạng thái đã ủy quyền hành động.
- Thực hiện hành động duy nhất đã được phê duyệt.
- Chờ cho đến khi có điều kiện sau được đặt tên hoặc thời gian chờ bị giới hạn hết.
- Đường dẫn thành công đến tiểu bang tiếp theo và thất bại trong việc thu thập bằng chứng, khôi phục đã được xem xét hoặc dừng lại.
Điều này bảo vệ chống lại các lớp phủ, điều hướng bị trì hoãn, đầu vào bị bỏ lỡ, tọa độ đã hết hạn và màn hình giống nhau. Nó cũng tạo ra báo cáo lỗi tốt hơn: người đánh giá thấy những gì được mong đợi, những hành động nào đã xảy ra và trạng thái tiếp theo nào không xuất hiện.
Bước 5: bảo tồn đủ bằng chứng để một người có thể đưa ra quyết định
Đến cuối bước này, mỗi lần dừng lại sẽ tạo ra một gói bằng chứng gọn gàng thay vì một nhãn thất bại mơ hồ. Thu thập bằng chứng trước khi khôi phục thay đổi màn hình. Chỉ giữ lại những gì cần thiết cho chẩn đoán và xử lý ảnh chụp màn hình hoặc nhật ký theo chính sách dữ liệu cho ứng dụng đang được thử nghiệm.
- Quy trình làm việc và tên bước, xây dựng ứng dụng, thiết bị, phiên bản Android, vùng địa phương và định hướng.
- Trạng thái mong đợi, trạng thái quan sát được, kết quả điều kiện, số lần thử và thời gian trôi qua.
- Ảnh chụp màn hình hoặc cắt tỉa tập trung, cộng với văn bản OCR, điểm tương ứng, thuộc tính UI hoặc kết quả phát hiện khi có liên quan.
- Tình trạng thành công cuối cùng, hành động đã cố gắng, điều kiện hậu xử lý bị thiếu và lý do dừng rõ ràng.
- Một lựa chọn người đánh giá được đề xuất: thử lại sau khi khắc phục được biết đến, cập nhật trạng thái đã chấp nhận hoặc điều tra sản phẩm.
Một giao tiếp hiệu quả cho phép ai đó đưa ra quyết định tiếp theo mà không cần phải tái tạo toàn bộ quá trình chạy trước đó. cáiHướng dẫn thử nghiệm khói QA tự động hóa Androidcho một ví dụ rộng hơn về việc giữ cho các kiểm tra thiết bị thực tế hẹp và có thể tái tạo được.
Làm thế nàoLaiCai Flowcác mô hình giới hạn an toàn
LaiCai Flowlà một tính năng tự động hóa bên trongLaiCai Screen Mirroring. Một Flow có thể quan sát cấu trúc UI hoặc trạng thái trực quan, phân nhánh giữa các kết quả đã biết, chờ đợi rõ ràng, lặp lại một số lần giới hạn, gọi Flow con cho đến khi thành công hoặc đạt giới hạn, và kết thúc thông qua hành vi trả về rõ ràng hoặc dừng. Những khối xây dựng này làm cho quyết định an toàn trở nên rõ ràng đối với người đánh giá.
Trong một mẫu điển hình, một UI, OCR, mẫu hoặc nút phát hiện quan sát điện thoại một lần. Một nhánh định tuyến một thành công hoặc thất bại đã biết. Một chờ biểu thị một sự chậm trễ thực tế trong kinh doanh. Một vòng lặp bị giới hạn xử lý một điều kiện tạm thời. Một quan sát thất bại mà không có cạnh phục hồi có thể kết thúc luồng hiện tại thay vì tiếp tục thực hiện cùng một hành động mãi mãi.
LaiCai Flow Insidecó thể chạy một Hồ sơ tương thích thông quaLaiCai Android Agentqua điện thoại sau khi triển khai. Tính tương thích vẫn phụ thuộc vào từng nút, tài sản, mô hình và sự phụ thuộc vào mạng được sử dụng bởi Hồ sơ đó. Việc chạy trên thiết bị không loại bỏ nhu cầu về giới hạn, bằng chứng hoặc xem xét.
Một danh sách kiểm tra đánh giá thực tế trước khi triển khai
- Mỗi hành động đều có một điều kiện tiên quyết được đặt tên và một điều kiện hậu quả có thể xác minh được.
- Mỗi lần chờ đợi đều có thời gian chờ hoặc điều kiện sẵn sàng, và mỗi lần thử lại đều có số lần thử tối đa.
- Các trạng thái không xác định dừng lại hoặc chuyển đến đường dẫn khôi phục đã được xem xét.
- Những hành động nhạy cảm sẽ không bao giờ bị lặp lại một cách mù quáng khi kết quả của chúng không chắc chắn.
- Bằng chứng về sự thất bại được ghi lại trước khi màn hình thay đổi lại.
- Các trường hợp màn hình dương tính, âm tính, chậm, bị gián đoạn và không mong muốn đã được thử nghiệm trên các thiết bị được ủy quyền.
Nếu một trong những tuyên bố này là sai, quy trình làm việc sẽ không sẵn sàng cho hoạt động không giám sát. Nó vẫn có thể hữu ích ở chế độ giám sát thông quaTự động hóa AI Android, nơi một người có thể xem thiết bị, tinh chỉnh các điều kiện trạng thái và xem xét bằng chứng về sự cố.
Câu hỏi thường gặp về điều kiện dừng tự động hóa Android
Sự chậm trễ cố định có phải là điều kiện dừng không?
Không. Sự chậm trễ cố định chỉ tạm dừng quy trình làm việc. Nó không chứng minh rằng ứng dụng đã đạt trạng thái mong đợi. Kết hợp bất kỳ sự chậm trễ nào với việc quan sát trạng thái và thời gian chờ.
Mọi sự cố lỗi phải dừng toàn bộ quy trình làm việc không?
Không. Một sự cố tạm thời đã biết có thể theo sau một đường dẫn khôi phục đã được xem xét và giới hạn. Một trạng thái không xác định, điều kiện hậu xử lý bị thiếu hoặc hành động nhạy cảm không chắc chắn thường nên dừng lại hoặc yêu cầu xem xét lại.
Có bao nhiêu lần thử lại là an toàn?
Không có số nào là phổ quát. Sử dụng giới hạn nhỏ nhất bao gồm độ trễ bình thường được đo lường và giảm giới hạn cho các hành động thay đổi trạng thái. Nếu lặp lại hành động có thể sao chép hậu quả, hãy xác minh tính vô hiệu hóa hoặc không tự động thử lại nó.
AI có loại bỏ nhu cầu về các quy tắc dừng không?
Không. AI có thể giúp giải thích màn hình hoặc đề xuất quy trình làm việc, nhưng việc thực thi vẫn cần các trạng thái, ngân sách, điều kiện sau và ranh giới xem xét được phép rõ ràng. Sự không chắc chắn là một lý do để thu thập bằng chứng, chứ không phải là sự cho phép tiếp tục.
Làm cho sự không chắc chắn trở nên rõ ràng thay vì tự động hóa thông qua nó
Một quy trình làm việc Android đáng tin cậy không phải là quy trình chạy lâu nhất. Đó là quy trình có thể giải thích tại sao mỗi hành động được phép, kết quả mà nó mong đợi và tại sao nó dừng lại khi bằng chứng thay đổi.
Tên các tiểu bang, chọn một quan sát chịu tải, ràng buộc mọi chờ đợi và thử lại, xác minh mọi điều kiện hậu xử lý và lưu giữ một giao tiếp chuyển tiếp hữu ích. Thiết kế đó biến các điều kiện dừng từ mã phòng thủ thành chính sách hoạt động của quy trình làm việc.
- Các nhà phát triển Android: Trình tự tự động hóa giao diện người dùng
- Các nhà phát triển Android: Chờ đợi di sản của UI Automator
- Các nhà phát triển Android: Quản lý công việc của WorkManager
- Các nhà phát triển Android: Công việc bền bỉ và các ràng buộc
- Appium: Các khả năng phiên
- Cuộc thảo luận về Tasker: các nỗ lực chờ đợi bị giới hạn