Sử dụng ảnh chụp màn hình để hiển thị toàn màn hình, OCR cho văn bản hiển thị và khớp hình ảnh cho mục tiêu hình ảnh đã biết. Các thử nghiệm trực quan mạnh mẽ nhất của Android kết hợp một khẳng định tập trung với bằng chứng về thời gian và lỗi ổn định.
Câu trả lời ngắn gọn: kiểm tra điều phải đúng
Sử dụng thử nghiệm ảnh chụp màn hình khi toàn bộ màn hình, thành phần, khoảng cách, màu sắc hoặc kiểu chữ phải nhất quán về mặt hình ảnh. Sử dụng OCR khi yêu cầu là về các từ mà một người có thể nhìn thấy, đặc biệt là văn bản được bản địa hóa hoặc được hiển thị động. Sử dụng tính năng so khớp hình ảnh khi một biểu tượng, nút, huy hiệu hoặc hình minh họa đã biết phải xuất hiện ngay cả khi biểu tượng, nút, huy hiệu hoặc hình minh họa đó không có mã nhận dạng giao diện người dùng đáng tin cậy.
Bắt đầu với bộ chọn giao diện người dùng hoặc trạng thái trợ năng khi yêu cầu mang tính ngữ nghĩa: một điều khiển tồn tại, được bật, được chọn hoặc hiển thị nhãn ổn định. Chỉ thêm tính năng phát hiện đối tượng khi mục tiêu thuộc về một lớp trực quan và có thể thay đổi kích thước hoặc vị trí quá nhiều đối với một mẫu. Các phương pháp này là các lớp chứ không phải các khung kiểm tra cạnh tranh.
- Hỏi bằng chứng nào sẽ thuyết phục người đánh giá rằng yêu cầu đã được thông qua.
- Chọn tín hiệu đáng tin cậy hẹp nhất thay vì so sánh từng pixel theo mặc định.
- Ổn định màn hình trước khi quan sát, sau đó lưu thành phần lạ khi xác nhận không thành công.
Các phương pháp kiểm tra trực quan của Android được so sánh
| phương pháp | Tốt nhất cho | Điểm yếu chính | Bằng chứng hữu ích |
|---|---|---|---|
| Giao diện người dùng hoặc trạng thái trợ năng | Điều khiển, nhãn, trạng thái kích hoạt, lựa chọn, cấu trúc điều hướng | Các phần tử được hiển thị tùy chỉnh hoặc không thể truy cập có thể ẩn với cây giao diện người dùng | Phân cấp giao diện người dùng, thuộc tính đã chọn, ảnh chụp màn hình |
| Ảnh chụp màn hình hoặc hình ảnh vàng | Bố cục, khoảng cách, màu sắc, kiểu chữ, hình thức thành phần | Dữ liệu động, hoạt ảnh, sự khác biệt về thiết bị và các thay đổi về kết xuất có thể tạo ra sự khác biệt lớn | Hình ảnh hiện tại, đường cơ sở được phê duyệt, sự khác biệt về hình ảnh |
| OCR | Văn bản hiển thị, bản địa hóa, biên nhận, thông báo trạng thái, giá trị được hiển thị dưới dạng pixel | Chất lượng nhận dạng phụ thuộc vào cắt, tỷ lệ, độ tương phản, dữ liệu ngôn ngữ, xoay và phân đoạn | Cắt nguồn, văn bản được công nhận, độ tin cậy hoặc danh sách kết quả |
| So khớp mẫu | Biểu tượng, nút, huy hiệu, hình thu nhỏ hoặc vùng ổn định nhỏ đã biết | Chủ đề, tỷ lệ, nén và thiết kế lại có thể làm mất hiệu lực mẫu | Mẫu, khu vực tìm kiếm, trận đấu hay nhất, tỷ số, ảnh chụp màn hình |
| Phát hiện đối tượng | Một đối tượng trực quan mà lớp của nó vẫn có ý nghĩa trong khi vị trí hoặc kích thước thay đổi | Yêu cầu một mô hình tương thích, các lớp được gắn nhãn, ngưỡng và xác thực mô hình | Phiên bản mẫu, lớp, hộp, điểm, ảnh chụp màn hình |
Hướng dẫn kiểm tra ảnh chụp màn hình chính thức của Android mô tả việc so sánh kết xuất hiện tại với hình ảnh tham chiếu đã được phê duyệt. Plugin hình ảnh của Appium hiển thị tính năng so khớp tính năng, so khớp mẫu và so sánh độ tương tự. OpenCV ghi lại cơ chế trượt mẫu trên hình ảnh, trong khi Tesseract ghi lại lý do tại sao việc xử lý trước OCR và phân đoạn trang lại quan trọng. Các công cụ khác nhau nhưng câu hỏi thiết kế bài kiểm tra vẫn giống nhau: quan sát nào chứng minh yêu cầu này?
Chọn khẳng định đúng với 4 câu hỏi
1. Yêu cầu đó có ngữ nghĩa hay hình ảnh?
Nếu quá trình kiểm tra cho biết “nút Gửi đã được bật”, trước tiên hãy kiểm tra trạng thái giao diện người dùng. Nếu thông báo “nút Gửi không bị cắt bớt sau khi thay đổi phông chữ”, hãy sử dụng ảnh chụp màn hình hoặc kiểm tra trực quan tập trung. Một truy vấn ngữ nghĩa thường dễ duy trì hơn nhưng nó không thể chứng minh được sự xuất hiện.
2. Văn bản chính xác có quan trọng không?
Sử dụng OCR khi chuỗi hướng tới người dùng là bắt buộc và văn bản không được hiển thị một cách đáng tin cậy thông qua cây giao diện người dùng. Hạn chế nhận dạng ở vùng có ý nghĩa nhỏ nhất, chọn ngôn ngữ chính xác và so sánh kết quả được chuẩn hóa. Giữ ảnh chụp màn hình vì chỉ một chuỗi OCR chính xác không thể hiển thị bị cắt bớt, chồng chéo hoặc độ tương phản kém.
3. Có một mục tiêu trực quan ổn định không?
Sử dụng tính năng khớp mẫu cho biểu tượng đã biết hoặc điều khiển nhỏ. Cắt chặt mẫu, tìm kiếm bên trong vùng quan tâm và đặt ngưỡng từ các mẫu dương và âm thực. Một ngưỡng chung hiếm khi có thể bảo vệ được đối với các chủ đề, độ phân giải và luồng nén từ xa.
4. Toàn bộ bố cục có nhất quán không?
Sử dụng so sánh ảnh chụp màn hình khi mối quan hệ giữa nhiều yếu tố quan trọng. Kiểm soát phông chữ, ngôn ngữ, cấu hình thiết bị, thanh hệ thống, thời gian, dữ liệu mạng, hình động và nội dung được gieo hạt. Nếu không thể kiểm soát được những đầu vào đó, hãy che hoặc cắt các vùng động thay vì chấp nhận thử nghiệm nhiễu vĩnh viễn.
Xây dựng một thử nghiệm trực quan thất bại một cách hữu ích
- Đưa ứng dụng về trạng thái bắt đầu được đặt tên trên thiết bị hoặc trình mô phỏng được ủy quyền.
- Chờ tình trạng ổn định chứ không phải chỉ là độ trễ cố định. UI Automator cung cấp khả năng chờ ổn định và tín hiệu sẵn sàng dành riêng cho ứng dụng thậm chí còn tốt hơn.
- Ghi lại vùng nguồn nhỏ nhất chứa bằng chứng cần thiết.
- Chạy một xác nhận chính: trạng thái giao diện người dùng, OCR, mẫu, phát hiện hoặc so sánh ảnh chụp màn hình.
- Lưu hình ảnh nguồn và kết quả có cấu trúc trước khi thực hiện hành động tiếp theo.
- Khi thất bại, hãy dừng hoặc đi theo đường dẫn khôi phục đã được xem xét. Không chạm vào một đối tượng tương tự ở gần đó chỉ để tiếp tục quá trình kiểm tra.
Kiểm tra trực quan trở nên an toàn hơn khi nó cho phép chuyển đổi. Quan sát trạng thái hiện tại, đưa ra xác nhận, chỉ thực hiện hành động được phép sau khi thành công và xác minh hậu điều kiện. Đây chính là nguyên tắc thiết kế được mô tả trong hướng dẫn tự động nhấp chuột nhận dạng hình ảnh: nhận dạng không phải là bằng chứng cho thấy quy trình công việc đã hoàn thành.
Đối với công việc trên thiết bị thực,Phản chiếu màn hình Android để thử nghiệm ứng dụng di độngcung cấp cho người đánh giá chế độ xem trực tiếp trong khi thử nghiệm đang được thiết kế. Hướng dẫn kiểm tra khói QA tự động hóagiải thích cách duy trì các hoạt động kiểm tra lặp lại ở phạm vi hẹp và có thể lặp lại.
Ba tình huống thử nghiệm hình ảnh thực tế của Android
QA bản địa hóa trên màn hình thanh toán
Sử dụng trạng thái giao diện người dùng để điều hướng đến màn hình thanh toán, OCR để xác nhận nhãn hành động và tổng số đã bản địa hóa cũng như ảnh chụp màn hình tập trung để hiển thị rằng các chuỗi không bị cắt hoặc chồng chéo. Chạy từng ngôn ngữ với dữ liệu thử nghiệm được kiểm soát. Chỉ so sánh pixel toàn màn hình sẽ quá nhạy cảm với độ dài chuỗi được dịch, trong khi chỉ riêng OCR sẽ bỏ qua hư hỏng về bố cục.
Kiểm tra biểu tượng thanh công cụ được thiết kế lại
Sử dụng mẫu cho biểu tượng được chấp nhận trong vùng thanh công cụ nhỏ. Giữ các mẫu riêng biệt khi cả chủ đề sáng và tối đều được hỗ trợ. Khi khớp không thành công, hãy đính kèm thanh công cụ cắt và điểm thí sinh tốt nhất. Nếu biểu tượng được cố ý thiết kế lại, hãy xem lại và thay thế mẫu thay vì hạ thấp ngưỡng cho đến khi bất kỳ hình dạng nào vượt qua.
Kiểm tra khói trên điện thoại thực sau khi triển khai
Bắt đầu từ trạng thái ứng dụng và tài khoản đã biết, đợi màn hình đích, xác nhận danh tính của tài khoản đó, thực hiện một hành động được phép và xác minh trạng thái được đặt tên tiếp theo. Chụp ảnh màn hình mỗi lần thất bại. Mật độ thiết bị, hộp thoại cấp quyền, bàn phím, thông báo và bản cập nhật hệ thống là một phần của môi trường điện thoại thực, vì vậy, quá trình kiểm tra sẽ báo cáo chúng thay vì ẩn chúng.
Những lỗi sai thường gặp và cách phòng tránh
| triệu chứng | Có khả năng gây ra | Phản hồi tốt hơn |
|---|---|---|
| Sự khác biệt của ảnh chụp màn hình thay đổi mỗi lần chạy | Đồng hồ, hoạt ảnh, quảng cáo, dữ liệu gốc, bàn phím, thanh hệ thống hoặc nội dung mạng | Cố định dữ liệu đầu vào, chờ màn hình ổn định, chỉ cắt hoặc che vùng động |
| OCR trả về văn bản hợp lý nhưng sai | Sai ngôn ngữ, độ tương phản thấp, vùng cắt quá nhỏ, xoay, nhiễu hoặc phân đoạn không phù hợp | Lưu phần cắt, cải thiện tỷ lệ và độ tương phản, chọn ngôn ngữ và phân đoạn một cách có chủ ý |
| Đối sánh mẫu chỉ hoạt động trên một điện thoại | Mật độ, chủ đề, tỷ lệ, tỷ lệ khung hình hoặc độ nén khác nhau | Sử dụng khu vực quan tâm và các mẫu đã được xác thực cho các biến thể hình ảnh được hỗ trợ |
| Đã tìm thấy hình ảnh phù hợp nhưng nhấn không thành công | Tọa độ khớp không được chuyển đổi sang màn hình hiện tại hoặc đầu vào khối lớp phủ | Tách biệt nhận dạng khỏi hành động và xác minh trạng thái tiếp theo |
| Kiểm tra tiếp tục trên màn hình sai | Không có hậu điều kiện hoặc cạnh lỗi | Đặt tên cho các trạng thái dự kiến và dừng khi màn hình hiện tại nằm ngoài đường dẫn đã xem xét |
| Trình phát hiện đối tượng tìm thấy lớp sai | Mô hình hoặc nhãn không phù hợp với miền ứng dụng, ngưỡng không được xác thực | Sử dụng model tương thích, ghi phiên bản và cho điểm, xét nghiệm mẫu âm tính |
Các cuộc thảo luận trong cộng đồng về thử nghiệm hồi quy của Android thường quay lại với cùng một chi phí bảo trì: ma trận thiết bị, thời gian không ổn định, đánh giá cơ bản và màn hình có nội dung thay đổi. Đó không phải là lý do để từ bỏ thử nghiệm trực quan. Chúng là lý do để làm cho môi trường thử nghiệm, phương sai được chấp nhận và các hiện tượng lỗi trở nên rõ ràng.
LaiCai Flow phù hợp với thử nghiệm trực quan như thế nào
LaiCai Flowlà một tính năng tự động hóa bên trong LaiCai Screen Mirroring. Luồng có thể kết hợp chụp ảnh màn hình, kiểm tra giao diện người dùng, OCR, khớp mẫu, phát hiện đối tượng, điều kiện, hành động và chuyển đổi thành công hoặc thất bại rõ ràng. Điều này cho phép người kiểm tra mô hình hóa màn hình ở trạng thái thay vì coi việc nhận dạng là một thủ thuật riêng biệt.
VớiLaiCai Flow Inside, Hồ sơ tương thích có thể chạy qua LaiCai Android Agent trên điện thoại sau khi triển khai. Khả năng tương thích vẫn phụ thuộc vào mọi nút và nội dung được Hồ sơ đó sử dụng. OCR cục bộ sử dụng Tesseract; khớp mẫu sử dụng nội dung hình ảnh đã chọn và điểm có thể định cấu hình; tính năng phát hiện cục bộ tương thích sử dụng mô hình được hỗ trợ. Một nút mạng hoặc mô hình từ xa vẫn cần có sự phụ thuộc mạng riêng.
Điều này không làm cho mọi bài kiểm tra trực quan tự động trở nên đáng tin cậy. Các nhóm vẫn cần đường cơ sở đại diện, mẫu, vùng OCR, mô hình, ngưỡng, trường hợp phủ định và hậu điều kiện. Giá trị là những quyết định và chuyển đổi đó có thể được xem xét trong một quy trình làm việc. Hướng dẫn tự động hóa AndroidAIcung cấp cái nhìn rộng hơn về tác giả và thực thi thiết bị thực.
Gói bằng chứng tối thiểu cho một bài kiểm tra trực quan không thành công
- Tên thử nghiệm, bản dựng ứng dụng, mẫu thiết bị, phiên bản Android, ngôn ngữ, chủ đề và hướng.
- Ảnh chụp màn hình nguồn hoặc vùng bị cắt được xác nhận sử dụng.
- Thuộc tính đường cơ sở, mẫu, văn bản, lớp hoặc giao diện người dùng dự kiến.
- Sự khác biệt được quan sát, kết quả OCR, khung giới hạn, điểm phù hợp hoặc giá trị giao diện người dùng.
- Trạng thái được đặt tên trước đó, hành động đã thử, trạng thái tiếp theo dự kiến và lý do dừng.
- Nội dung, mô hình hoặc phiên bản cơ sở để người đánh giá có thể đưa ra quyết định.
Nhãn đạt/không đạt mà không có ngữ cảnh này sẽ buộc người tiếp theo phải thực hiện lại toàn bộ lượt chạy. Gói bằng chứng nhỏ gọn biến lỗi thành quyết định có thể xem xét lại: sửa sản phẩm, ổn định thử nghiệm, cập nhật nội dung trực quan đã được phê duyệt hoặc từ chối cấu hình thiết bị không được hỗ trợ.
Câu hỏi thường gặp về kiểm tra hình ảnh Android
Mọi thử nghiệm giao diện người dùng Android có nên bao gồm ảnh chụp màn hình không?
Không. Sử dụng ảnh chụp màn hình khi hình thức có vấn đề hoặc khi một tạo phẩm lỗi sẽ giúp ích cho người đánh giá. Các xác nhận ngữ nghĩa thường tốt hơn cho hành vi mà cây giao diện người dùng hiển thị một cách đáng tin cậy.
OCR có tốt hơn so với kết hợp hình ảnh không?
OCR trả lời các câu hỏi về văn bản hiển thị. Kết hợp hình ảnh trả lời các câu hỏi về một mẫu hình ảnh đã biết. Nếu yêu cầu bao gồm cả nhãn và hình thức của nó, hãy sử dụng OCR cùng với ảnh chụp màn hình hoặc kiểm tra mẫu tập trung.
Kiểm tra ảnh chụp màn hình có thể chạy trên điện thoại Android thực không?
Có, nhưng các thiết bị thực có nhiều biến thể hơn trình kết xuất hoặc trình mô phỏng phía máy chủ được kiểm soát. Ghi lại cấu hình thiết bị, ổn định dữ liệu và giao diện người dùng hệ thống, đồng thời đặt kỳ vọng cho ma trận thiết bị mà bạn thực sự hỗ trợ.
Khi nào tôi nên sử dụng tính năng phát hiện đối tượng?
Sử dụng nó khi một lớp đối tượng có ý nghĩa di chuyển hoặc mở rộng quy mô vượt quá dung sai của mẫu ổn định và chỉ khi một mô hình tương thích đã được xác thực trên hình ảnh thực của ứng dụng. Đừng thêm máy dò chỉ vì nó nghe có vẻ cao cấp hơn.
Chọn bằng chứng trước khi chọn công nghệ
Kiểm tra hình ảnh Android đáng tin cậy bắt đầu bằng một câu: người đánh giá phải chứng minh được điều gì? Chọn trạng thái giao diện người dùng cho ngữ nghĩa, ảnh chụp màn hình cho bố cục, OCR cho văn bản, khớp mẫu cho mục tiêu trực quan đã biết và phát hiện đối tượng cho lớp đã xác thực có hình học thay đổi.
Sau đó thực hiện phần quan sát của quá trình chuyển đổi trạng thái: ổn định, nắm bắt, khẳng định, chỉ hành động sau khi thành công, xác minh hậu điều kiện và lưu giữ bằng chứng thất bại. Thiết kế đó dễ hiểu hơn một tập hợp các lệnh gọi tầm nhìn bị ngắt kết nối—và dễ bảo trì hơn nhiều khi ứng dụng hoặc thiết bị thay đổi.
- Nhà phát triển Android: Thử nghiệm ảnh chụp màn hình
- Nhà phát triển Android: Kiểm tra ảnh chụp màn hình xem trước của Compose
- Nhà phát triển Android: UI Automator
- Appium: Plugin hình ảnh và chế độ so sánh
- OpenCV: So khớp mẫu
- Tesseract: Cải thiện chất lượng OCR
- Thảo luận dành cho nhà phát triển Android: kiểm tra ảnh chụp màn hình