Chọn một công cụ kiểm tra tự động hóa Android dựa trên ranh giới bạn cần kiểm soát: giao diện người dùng thuộc sở hữu ứng dụng, hành vi hệ thống và giữa các ứng dụng, các bài kiểm tra WebDriver trên nhiều nền tảng hoặc quy trình làm việc thực tế trên điện thoại có thể quan sát được.

Câu trả lời ngắn gọn: hãy chọn theo giới hạn của bài kiểm tra, chứ không phải theo độ phổ biến
Không có công cụ kiểm tra tự động hóa Android nào tốt nhất. Chọn kiểm tra Compose hoặc Espresso khi nhóm của bạn sở hữu ứng dụng và cần các khẳng định gần với mã giao diện người dùng của nó. Chọn UI Automator khi một bài kiểm tra phải vượt qua ranh giới ứng dụng hoặc tương tác với giao diện người dùng hệ thống Android. Chọn Appium khi một khách hàng kiểu WebDriver, một số ngôn ngữ lập trình hoặc một lớp tự động hóa Android và iOS được chia sẻ quan trọng. Thêm luồng trực quan có thể quan sát được khi một người đánh giá phải theo dõi một chiếc điện thoại thực, nhận dạng trạng thái có thể nhìn thấy, thu thập ảnh chụp màn hình hoặc mô hình hóa quy trình làm việc hoạt động bên ngoài mã kiểm tra của ứng dụng.
Những công cụ này giải quyết các lớp khác nhau của cùng một vấn đề chất lượng.Hướng dẫn kiểm tra giao diện người dùng chính thức của Androidxác định các bài kiểm tra UI là khởi chạy một ứng dụng, mô phỏng các tương tác và kiểm tra xem nó đã phản ứng đúng cách hay chưa. Do đó, việc lựa chọn công cụ hữu ích bắt đầu từ bằng chứng mà bài kiểm tra phải tạo ra, ranh giới phần mềm mà nó phải vượt qua và ai sẽ duy trì nó. Đây là một so sánh dựa trên nghiên cứu về tài liệu chính thức hiện tại, không phải là một tiêu chuẩn tuyên bố rằng một khuôn khổ nào đó nhanh hơn hoặc đáng tin cậy hơn một cách phổ quát.
- View UI thuộc sở hữu của ứng dụng: bắt đầu với Espresso.
- Jetpack Compose UI thuộc sở hữu của ứng dụng: bắt đầu với việc thử nghiệm các API Compose.
- Hệ thống UI, quyền truy cập, đa cửa sổ hoặc hành vi giữa các ứng dụng: bắt đầu với UI Automator.
- Tự động hóa WebDriver đa nền tảng và tính linh hoạt của ngôn ngữ khách hàng: đánh giá Appium.
- Quy trình làm việc hộp đen có thể nhìn thấy, OCR, trạng thái hình ảnh và bằng chứng thân thiện với người xem xét: thêm lớp luồng trực quan.
So sánh các công cụ kiểm tra tự động hóa Android
| Công cụ hoặc phương pháp tiếp cận | phù hợp nhất | Ranh giới thực thi | Các trình chọn hoặc bằng chứng chính | Thỏa thuận thương mại chính |
|---|---|---|---|---|
| Kiểm tra cấu trúc | Các ứng dụng được xây dựng bằng Jetpack Compose | Ứng dụng hoặc thành phần đang được kiểm tra | Từ vựng, thuộc tính, hành động, khẳng định | Yêu cầu mã Compose có nhận biết thử nghiệm và cài đặt thử nghiệm Android |
| cà phê đậm đặc | Các bài kiểm tra hành vi ứng dụng dựa trên giao diện người dùng | Ứng dụng đang được thử nghiệm | Xem các đối thủ, hành động, khẳng định | Không được thiết kế như công cụ chính cho các chuyến đi đa ứng dụng rộng rãi |
| Trình tự tự động hóa UI | Hệ thống UI, đa ứng dụng, đa cửa sổ, đường dẫn Android từ đầu đến cuối | Giao diện người dùng của thiết bị và các ứng dụng đã cài đặt | Các nút truy cập, mệnh đề, ảnh chụp màn hình, trạng thái ứng dụng | Đặc biệt dành cho Android và thường được duy trì trong chuỗi công cụ thử nghiệm Android |
| Appium với UiAutomator2 | Tự động hóa di động theo kiểu WebDriver trên nhiều nền tảng | Khách hàng đến máy chủ Appium và trình điều khiển Android | Các trình tìm kiếm WebDriver, khả năng, lệnh điều khiển trình điều khiển | Nhiều bộ phận chuyển động hơn: máy chủ, trình điều khiển, SDK, JDK và cấu hình thiết bị |
| Dòng chảy trực quan | Kiểm tra điện thoại thực tế có thể quan sát được và quy trình làm việc vận hành | Trạng thái thiết bị có thể nhìn thấy từ bên ngoài mã ứng dụng | Cây giao diện người dùng, OCR, mẫu, hình ảnh, ảnh chụp màn hình, nhánh | Không thay thế các khẳng định về đơn vị, thành phần hoặc thiết bị đo lường |
Bảng là bản đồ ranh giới, không phải bảng chiến thắng. Các đội trưởng thành thường kết hợp nhiều hàng. Màn hình Compose có thể có các bài kiểm tra hành vi thành phần nhanh chóng, đường dẫn UI Automator cho quyền truy cập và chuyển đổi hệ thống, bộ Appium được chia sẻ với iOS và một luồng điện thoại thực tế được giám sát nhỏ để thu thập bằng chứng sau khi triển khai. Việc sao chép chỉ trở thành một vấn đề khi hai bộ được chứng minh là đáp ứng cùng một yêu cầu với cùng một chi phí thiết bị.
Sử dụng các bài kiểm tra Compose hoặc Espresso để kiểm tra hành vi của ứng dụng.
Compose testing và Espresso là những điểm khởi đầu mạnh mẽ nhất khi nhóm kiểm soát mã ứng dụng và yêu cầu là hành vi ngữ nghĩa bên trong ứng dụng đó.Viết các API kiểm tratìm kiếm các yếu tố thông qua ngữ nghĩa, xác minh thuộc tính, thực hiện các hành động và đồng bộ hóa với giao diện người dùng.Espresso sử dụng các đối chiếu view, hành động và khẳng địnhcho các giao diện dựa trên View trong khi ngăn chặn việc truy cập trực tiếp không an toàn vào các hoạt động và View từ luồng sai.
Sự gần gũi này với ứng dụng là hữu ích. Các bài kiểm tra có thể tiêm dữ liệu xác định, cô lập một thành phần, khẳng định trạng thái đã bật hoặc được chọn và thất bại với một lý do ngữ nghĩa cụ thể. Điều đó cũng có nghĩa là bộ phần mềm được kết nối với kiến trúc và xây dựng thử nghiệm của ứng dụng. Sự kết nối đó là phù hợp khi yêu cầu thuộc về ứng dụng: một thông báo xác thực xuất hiện, điều hướng chọn đích đúng hoặc một nút vẫn bị vô hiệu hóa cho đến khi có đầu vào hợp lệ.
Chọn Kiểm tra Viết khi nào
- Giao diện chủ yếu là Jetpack Compose và hiển thị ngữ nghĩa hữu ích.
- Bạn muốn các bài kiểm tra ở cấp thành phần với trạng thái được kiểm soát cũng như các bài kiểm tra ở cấp hoạt động.
- Đồng bộ hóa không hoạt động và kiểm soát thời gian cụ thể cho Compose giúp làm cho các khẳng định trở nên xác định.
Chọn Espresso khi nào
- Ứng dụng dựa trên View hoặc có các màn hình View cần kiểm tra hành vi.
- Bài kiểm tra có thể xác định một chế độ xem bằng ID tài nguyên hoặc một trình khớp tập trung.
- Yêu cầu là một tương tác và khẳng định bên trong ứng dụng thay vì một hành trình trên toàn bộ thiết bị.
Sử dụng UI Automator cho hệ thống Android và các đường dẫn giữa các ứng dụng
UI Automator chiến thắng khi chính thiết bị Android là một phần của giới hạn kiểm tra.API Automator UI hiện đạicó thể khởi chạy các ứng dụng, tìm kiếm các yếu tố có điều kiện, xử lý các hộp thoại quyền, chờ cho ứng dụng hiển thị hoặc một cây truy cập ổn định, kiểm tra nhiều cửa sổ và chụp ảnh màn hình. Những khả năng đó phù hợp với các thông báo quyền, màn hình Cài đặt, thông báo, ảnh trong ảnh, màn hình chia đôi, hành vi của trình khởi chạy và các chuyến đi di chuyển giữa các ứng dụng đã cài đặt.
Sự khác biệt quan trọng không phải là UI Automator đơn giản là 'mạnh mẽ hơn' Espresso. Nó quan sát UI từ một vị trí khác nhau. Vị trí bên ngoài đó nhìn thấy bề mặt hệ thống và giữa các ứng dụng, nhưng nó có ít quyền truy cập trực tiếp hơn vào nội bộ ứng dụng và bản sao kiểm tra. Sử dụng nó cho các đường dẫn từ đầu đến cuối mỏng manh thực sự cần ranh giới thiết bị; giữ hầu hết logic ứng dụng trong các bài kiểm tra nhanh hơn, tập trung hơn.
CáiTài liệu hiện tại của Trình tự tự động hóa UIcũng bao gồm thời gian chờ đợi các yếu tố điều kiện tích hợp sẵn, chờ đợi ổn định rõ ràng, ảnh chụp màn hình và báo cáo kết quả. Những tính năng đó giảm bớt cám dỗ dựa vào việc ngủ cố định. Tài liệu lưu ý rằng sự ổn định của cây truy cập không chứng minh rằng mọi tác vụ nền đều đang ở trạng thái chờ, vì vậy thời gian chờ tốt nhất vẫn là điều kiện ứng dụng được đặt tên bất cứ khi nào có sẵn.
Sử dụng Appium khi lớp di động kiểu WebDriver quan trọng
Appium là ứng cử viên mạnh mẽ khi tổ chức muốn tự động hóa di động từ JavaScript, Java, Python, Ruby hoặc .NET, đã sử dụng các khái niệm WebDriver hoặc muốn các bộ ứng dụng Android và iOS liên quan được thực hiện đằng sau một mô hình máy chủ tự động hóa. Trên Android,bắt đầu nhanh chính thức của UiAutomator2cài đặt trình điều khiển, chọn nó bằng tên tự động hóa UiAutomator2 và kết nối với trình giả lập hoặc thiết bị gỡ lỗi USB thông qua chuỗi công cụ Android.
Sự linh hoạt đó có một chi phí vận hành. cáicài đặt được ghi lạibao gồm một máy chủ Appium, trình điều khiển nền tảng, Android SDK và các công cụ nền tảng, JDK tương thích, chuẩn bị thiết bị, khả năng và các phụ thuộc của khách hàng. Lời khuyên biên tập của chúng tôi là sở hữu các phiên bản đó một cách rõ ràng và xác thực cài đặt bằng lệnh bác sĩ của trình điều khiển thay vì duy trì một công thức máy tính xách tay không được ghi chú.
Appium không nhất thiết là lựa chọn tốt nhất chỉ vì một bộ phần mềm iOS tương lai là khả thi. Nếu yêu cầu hiện tại là một mã nguồn nhỏ chỉ dành cho Android với quyền truy cập sâu vào trạng thái ứng dụng, các bài kiểm tra Android gốc có thể vẫn đơn giản hơn. Nếu nền tảng QA đã chuẩn hóa các phiên thiết bị, khách hàng ngôn ngữ, báo cáo và đối tượng trang đa nền tảng, mô hình chia sẻ của Appium có thể chứng minh được các lớp bổ sung.
Thêm một luồng trực quan cho các quy trình làm việc hộp đen có thể quan sát được
Một luồng trực quan là hữu ích khi yêu cầu tồn tại trong những gì một người có thể quan sát được trên điện thoại thực tế và quy trình làm việc phải dễ hiểu bên ngoài kho lưu trữ ứng dụng. Các ví dụ bao gồm kiểm tra khói sau khi triển khai, sao chép hỗ trợ, đường dẫn hoạt động trên các ứng dụng của bên thứ ba, kiểm tra văn bản hiển thị được địa phương hóa hoặc nhiệm vụ thiết bị được giám sát phải dừng lại bằng ảnh chụp màn hình khi trạng thái không được biết.
LaiCai Flowcó thể kết hợp phân tích giao diện người dùng, tìm kiếm các yếu tố, nhấn vào, nhập văn bản, chờ đợi, các nhánh, lặp lại giới hạn, chụp màn hình, OCR, khớp mẫu, phát hiện đối tượng, luồng con và hành vi trả về hoặc dừng rõ ràng. Điều đó làm cho đường dẫn quyết định trở nên rõ ràng: quan sát trạng thái được đặt tên, cho phép một hành động, xác minh điều kiện hậu cần và lưu giữ bằng chứng trong trường hợp lỗi.LaiCai Flow Insidecó thể chạy một Hồ sơ tương thích thông quaLaiCai Android Agentsau khi triển khai, nhưng tính tương thích phụ thuộc vào từng nút và tài sản được sử dụng bởi Hồ sơ đó.
Lớp này nên bổ sung - không thay thế - các khẳng định gốc ứng dụng. OCR là phù hợp khi văn bản có thể nhìn thấy là bằng chứng nhưng cây giao diện người dùng không hiển thị nó một cách đáng tin cậy. Việc khớp mẫu là phù hợp cho mục tiêu trực quan đã được xác thực. Bản chụp màn hình có ích cho việc sắp xếp hoặc xem xét lỗi. Không có cái nào trong số chúng thay thế cho bài kiểm tra đơn vị về logic kinh doanh hoặc khẳng định Compose chính xác khi mã nguồn có sẵn. cáiHướng dẫn kiểm tra trực quan Androidgiải thích cách chọn giữa các loại bằng chứng đó.
Xây dựng chiến lược kiểm tra Android nhiều lớp
- Viết yêu cầu dưới dạng kết quả có thể quan sát được, chứ không phải là một chuỗi các cú chạm.
- Đặt logic kinh doanh trong các bài kiểm tra cục bộ hoặc thành phần nơi mà giao diện người dùng của thiết bị không cần thiết.
- Sử dụng Compose testing hoặc Espresso để kiểm tra hành vi và khẳng định ngữ nghĩa thuộc sở hữu ứng dụng.
- Chỉ thêm UI Automator cho hệ thống, nhiều cửa sổ, quyền truy cập hoặc ranh giới giữa các ứng dụng.
- Sử dụng Appium khi máy chủ, khách hàng, báo cáo hoặc mô hình đa nền tảng của nó mang lại giá trị tổ chức cụ thể.
- Thêm một luồng điện thoại thực tế trực quan để chứng minh rằng các bộ phần mềm cấp độ mã không thể tạo ra một cách rõ ràng.
- Giữ cho mỗi đường dẫn từ đầu đến cuối hẹp, xác định trạng thái bắt đầu, ràng buộc mọi lần chờ đợi và thử lại, và ghi lại trạng thái lỗi trước khi quá trình khôi phục thay đổi nó.
Một yêu cầu nên có một chủ sở hữu chính. Ví dụ: xác thực biểu mẫu thuộc về các bài kiểm tra cấp ứng dụng; việc chuyển giao quyền truy cập thuộc về một đường dẫn UI Automator; một hợp đồng thanh toán Android và iOS được chia sẻ có thể thuộc về Appium; và một chạy bằng bằng chứng điện thoại thực tế sau khi phát hành có thể thuộc về một luồng trực quan. Các lớp có thể tham chiếu cùng một hành trình người dùng mà không cần sao chép mọi khẳng định vào mọi khuôn khổ.
CáiHướng dẫn thử nghiệm khói QA điện thoại thực tếhiển thị cách giữ cho bản kiểm tra được triển khai nhỏ gọn và có thể tái tạo được. cáiHướng dẫn điều kiện dừng tự động hóabao gồm thời gian chờ, thử lại giới hạn, điều kiện sau và xem xét của con người khi màn hình hiện tại không còn hợp lý cho hành động tiếp theo.
Một danh sách kiểm tra lựa chọn thực tế
| câu hỏi | Nếu có, hãy bắt đầu với |
|---|---|
| Bạn có sở hữu một Compose UI và cần các thành phần ngữ nghĩa hoặc các khẳng định màn hình không? | Kiểm tra cấu trúc |
| Bạn có sở hữu một giao diện người dùng dựa trên View và cần các bài kiểm tra hành vi trong ứng dụng tập trung không? | cà phê đậm đặc |
| Đường dẫn phải vượt qua Cài đặt, quyền truy cập, trình khởi chạy, cửa sổ hoặc ứng dụng khác không? | Trình tự tự động hóa UI |
| Nhóm có yêu cầu các khách hàng WebDriver hay một kiến trúc tự động hóa Android và iOS được chia sẻ không? | Ứng dụng Appium |
| Có phải một người không phải là nhà phát triển phải xem xét trạng thái hiển thị, OCR, hình ảnh hoặc ảnh chụp màn hình trên điện thoại thực tế không? | Dòng chảy trực quan |
| Yêu cầu chủ yếu là logic kinh doanh mà không phụ thuộc vào giao diện người dùng của thiết bị? | Không có: sử dụng một đơn vị cục bộ hoặc bài kiểm tra tích hợp |
Trước khi áp dụng một khung mới, hãy tạo ra một đường dẫn đại diện cho mô hình nguyên mẫu và ghi lại toàn bộ bề mặt bảo trì: mã kiểm tra, các hàm ứng dụng, phiên bản máy chủ hoặc trình điều khiển, đặt lại thiết bị, dữ liệu kiểm tra, quyền truy cập, ảnh chụp màn hình, nhật ký và quyền sở hữu CI. Công cụ tốt nhất là công cụ tạo ra bằng chứng đáng tin cậy với chi phí bảo trì mà nhóm thực sự sẽ trả.
Câu hỏi thường gặp về các công cụ kiểm tra tự động hóa Android
UI Automator có giống với Appium UiAutomator2 không?
Không.UI Automator là một thư viện kiểm thử Android và API.Bộ điều khiển UiAutomator2 của Appium là bộ điều khiển nền tảng Appiumsau một lớp hướng đến Appium/WebDriver. Cài đặt, mô hình khách hàng và ranh giới bảo trì của chúng khác nhau mặc dù tên có liên quan.
Appium có thể thay thế các bài kiểm tra Espresso hoặc Compose không?
Nó có thể tự động hóa nhiều hành trình giống nhau có thể nhìn thấy, nhưng đề xuất của chúng tôi là không nên thay thế mọi bài kiểm tra ở cấp ứng dụng.Kiểm tra cấu trúcvàcà phê đậm đặcgần hơn với trạng thái ứng dụng và hành vi giao diện người dùng ngữ nghĩa. Appium có giá trị nhất khi khách hàng bên ngoài, kiến trúc trình điều khiển hoặc tính nhất quán trên nhiều nền tảng của nó là một phần của yêu cầu.
Công cụ nào tốt nhất để kiểm tra các ứng dụng của bên thứ ba?
UI Automator, Appium hoặc luồng trực quan hộp đen đã được xem xét là phù hợp hơn các khung nội bộ ứng dụng khi bạn không sở hữu mã ứng dụng mục tiêu. Xác nhận rằng quá trình tự động hóa đã được ủy quyền, sử dụng các trình chọn có thể quan sát được ổn định, tránh các hành động nhạy cảm hoặc phá hoại và mong đợi các thay đổi UI của bên thứ ba yêu cầu bảo trì.
Các luồng trực quan có hoạt động trong tích hợp liên tục không?
Họ có thể tham gia vào một đường ống tự động hóa nếu phiên thiết bị, tài sản, đầu vào, hiện vật lỗi và giao diện kết quả được kiểm soát. Tuy nhiên, quy trình làm việc thực tế trên điện thoại được giám sát và khung công cụ khẳng định CI phục vụ các mô hình hoạt động khác nhau. Đầu tiên hãy quyết định xem việc chạy có phải chặn quá trình xây dựng, tạo bằng chứng đánh giá hoặc hỗ trợ một người hay không.
Chọn ranh giới công cụ nhỏ nhất chứng minh yêu cầu
Bắt đầu gần với mã và mở rộng ra bên ngoài chỉ khi yêu cầu yêu cầu điều đó. Viết thử nghiệm và ứng dụng Espresso chứng minh hành vi thuộc sở hữu của ứng dụng. UI Automator chứng minh hệ thống Android và các đường dẫn giữa các ứng dụng. Appium cung cấp một lớp tự động hóa di động theo kiểu WebDriver. Một luồng trực quan thêm trạng thái điện thoại thực tế có thể nhìn thấy, OCR, bằng chứng hình ảnh và việc chuyển giao hoạt động mà những người không phải là nhà phát triển có thể xem xét.
Do đó, chiến lược tự động hóa Android mạnh nhất không phải là tiêu chuẩn một công cụ duy nhất. Đó là một sự phân chia trách nhiệm được ghi lại: một chủ sở hữu tuyên bố chính cho mỗi yêu cầu, phạm vi phủ sóng từ đầu đến cuối mỏng manh ở các biên giới đắt đỏ, các điều kiện dừng rõ ràng và bằng chứng về sự cố cho biết người tiếp theo đã xảy ra gì. thăm dòTự động hóa AI Android vớiLaiCai Flowkhi lớp quy trình làm việc có thể quan sát được đó khớp với trường hợp sử dụng của bạn.
Ghi chú biên tập:Công ty TNHH BeePOS, công ty đứng sauLaiCai Screen Mirroring, đã nghiên cứu so sánh này từ tài liệu chính thức của Android và Appium được liên kết bên cạnh các tuyên bố liên quan bên dưới. Phần sản phẩm được dán nhãn riêng biệt để người đọc có thể phân biệt các khả năng của khung công cụ được ghi lại với các đề xuất quy trình làm việc của riêng chúng tôi. Các câu hỏi hoặc sự sửa chữa có thể được gửi đến support@laicaiapp.com.
- Các nhà phát triển Android: Tự động hóa các bài kiểm tra giao diện người dùng
- Các nhà phát triển Android: Kiểm tra bố cục Compose của bạn
- Các nhà phát triển Android: Những điều cơ bản về Espresso
- Các nhà phát triển Android: Viết các bài kiểm tra tự động bằng UI Automator
- Appium: Cài đặt trình điều khiển UiAutomator2
- Appium: Trình điều khiển