Trang này cung cấp trợ giúp khắc phục sự cố và câu trả lời cho các câu hỏi thường gặp về việc chạy thử nghiệm với Phòng thí nghiệm kiểm tra Firebase. Các vấn đề đã biết cũng được ghi lại. Nếu bạn không tìm thấy những gì mình đang tìm kiếm hoặc cần trợ giúp thêm, hãy tham gia kênh #test-lab trên Firebase Slack hoặc liên hệ với bộ phận hỗ trợ của Firebase .
Xử lý sự cố
Khi bạn chọn một thiết bị có mức dung lượng cao trong danh mục Test Lab, các bài kiểm tra có thể bắt đầu nhanh hơn. Khi thiết bị có dung lượng thấp, quá trình kiểm tra có thể mất nhiều thời gian hơn để chạy. Nếu số lần kiểm tra được thực hiện lớn hơn nhiều so với dung lượng của thiết bị đã chọn thì việc kiểm tra có thể mất nhiều thời gian hơn để hoàn thành.
Các thử nghiệm chạy trên mọi cấp độ dung lượng thiết bị có thể mất nhiều thời gian hơn do các yếu tố sau:
- Lưu lượng truy cập, ảnh hưởng đến tính khả dụng của thiết bị và tốc độ kiểm tra.
- Lỗi thiết bị hoặc cơ sở hạ tầng, có thể xảy ra bất cứ lúc nào. Để kiểm tra xem có cơ sở hạ tầng được báo cáo cho Test Lab hay không, hãy xem bảng thông tin trạng thái Firebase .
Để tìm hiểu thêm về dung lượng thiết bị trong Test Lab, hãy xem thông tin dung lượng thiết bị dành cho Android và iOS .
Kết quả kiểm tra không có kết luận thường xảy ra do các lần chạy thử bị hủy hoặc do lỗi cơ sở hạ tầng.
Lỗi cơ sở hạ tầng xảy ra do các sự cố nội bộ của Test Lab, như lỗi mạng hoặc các hành vi không mong muốn của thiết bị. Test Lab dừng nội bộ các lần chạy thử nghiệm gây ra lỗi cơ sở hạ tầng nhiều lần trước khi báo cáo kết quả không thuyết phục; tuy nhiên, bạn có thể vô hiệu hóa những lần thử lại này bằng cách sử dụng failedFast .
Để xác định nguyên nhân gây ra lỗi, hãy làm theo các bước sau:
- Kiểm tra các sự cố ngừng hoạt động đã biết trong trang tổng quan trạng thái Firebase .
Hãy thử lại bài kiểm tra trong Test Lab để xác minh rằng nó có thể tái tạo được.
Hãy thử chạy thử nghiệm trên một thiết bị hoặc loại thiết bị khác, nếu có.
Nếu sự cố vẫn tiếp diễn, hãy liên hệ với nhóm Test Lab trong kênh #test-lab trên Firebase Slack.
Phân đoạn có thể khiến các thử nghiệm của bạn chạy lâu hơn khi số lượng phân đoạn bạn chỉ định vượt quá số lượng thiết bị có sẵn để sử dụng trong Test Lab. Để tránh tình trạng này, hãy thử chuyển sang một thiết bị khác. Để biết thêm thông tin về cách chọn thiết bị khác, hãy xemDung lượng thiết bị .
Khi bạn gửi yêu cầu thử nghiệm, ứng dụng của bạn trước tiên sẽ được xác thực, ký lại, v.v. để chuẩn bị cho việc chạy thử nghiệm trên thiết bị. Thông thường, quá trình này hoàn thành trong chưa đầy vài giây nhưng nó có thể bị ảnh hưởng bởi các yếu tố như kích thước ứng dụng của bạn.
Sau khi ứng dụng của bạn được chuẩn bị, các hoạt động thực thi thử nghiệm sẽ được lên lịch và duy trì trong hàng đợi cho đến khi thiết bị sẵn sàng chạy ứng dụng đó. Cho đến khi tất cả các hoạt động thực thi kiểm thử chạy xong, trạng thái ma trận sẽ là "Đang chờ xử lý" (bất kể các hoạt động thực thi kiểm thử đang ở trong hàng đợi hay đang chạy).
Sau khi quá trình thực hiện thử nghiệm kết thúc, các tạo phẩm thử nghiệm sẽ được tải xuống từ thiết bị, được xử lý và tải lên Cloud Storage. Thời lượng của bước này có thể bị ảnh hưởng bởi số lượng và kích thước của hiện vật.
Các cấu phần phần mềm thực thi thử nghiệm (chẳng hạn như ảnh chụp màn hình và tệp nhật ký) được lưu trữ trong Google Cloud Storage và hiển thị trực tiếp vào bảng điều khiển Firebase. Nếu quá trình thực hiện thử nghiệm của bạn được thực hiện trong vòng 90 ngày qua, hãy kiểm tra xem bạn đã chỉ định các vai trò cấp dự án (chủ sở hữu dự án, người chỉnh sửa dự án hoặc người xem dự án) hay chưa. Ngoài ra, vui lòng đảm bảo rằng Ghi nhật ký kiểm tra đám mây không được bật cho dự án hoặc tổ chức của bạn.
Nếu quá trình thực thi được thực hiện cách đây hơn 90 ngày thì rất có thể các tạo phẩm thử nghiệm đã tự động bị xóa. Bạn có thể kiểm tra cấu hình nhóm kết quả bằng cách nhấp vào tab Kết quả kiểm tra trong bảng thông tin Test Lab. Nhóm kết quả mặc định được định cấu hình để giữ lại các đối tượng trong 90 ngày.
Để giữ lại các thành phần thử nghiệm của bạn lâu hơn, hãy chạy lệnh gcloud firebase test android run
với cờ --results-bucket
và chuyển vào tên của nhóm kết quả. Để biết thêm thông tin, hãy truy cập tài liệu tham khảo gcloud firebase test android run
.
Khi chạy thử nghiệm đo lường, bạn có thể thấy các lỗi kiểm tra cho biết một phần kết quả có chứa thông báo như Test run failed to complete. Expected x tests, received y
(trong đó y
nhỏ hơn x
). Lỗi này có nghĩa là Test Lab không thể phân tích cú pháp logcat cho các điểm đánh dấu bắt đầu hoặc kết thúc trường hợp kiểm thử thường được tạo bởi AndroidJUnitRunner .
Sau đây là những nguyên nhân phổ biến của vấn đề này:
Mô tả vấn đề | Độ phân giải có thể |
---|---|
Trường hợp thử nghiệm không chạy do hết thời gian chờ. Nếu tổng thời lượng của các bài kiểm tra dài hơn thời gian chờ bạn đã chỉ định hoặc dài hơn thời gian chờ tối đa , Test Lab sẽ hủy các trường hợp kiểm thử còn lại. |
|
Trường hợp thử nghiệm không thể hoàn thành vì nó thoát sớm hoặc bị kẹt. Trường hợp thử nghiệm có thể thoát sớm do lỗi xác nhận hoặc ngoại lệ chưa được phát hiện. Các trường hợp thử nghiệm có thể bị mắc kẹt trong một vòng lặp vô hạn hoặc có thể không thể tiếp tục, chẳng hạn như nếu ứng dụng không hiển thị chế độ xem chính xác và trường hợp thử nghiệm không thể thực hiện hành động trên giao diện người dùng. | Kiểm tra video và logcat để điều tra xem thử nghiệm đã dừng ở đâu. |
Trình chạy thử nghiệm tùy chỉnh (bao gồm cả việc mở rộng AndroidJUnitRunner) bị lỗi bất ngờ hoặc ghi điểm bắt đầu hoặc kết thúc trường hợp thử nghiệm không mong muốn vào logcat . | Kiểm tra mã chạy thử nghiệm của bạn. |
Nhật ký quá mức được ghi vào logcat , làm tràn bộ đệm hoặc làm hỏng quá trình logcat . | Giảm ghi vào logcat . |
Ứng dụng đang được thử nghiệm bị lỗi. | Gỡ lỗi ứng dụng của bạn. |
Các câu hỏi thường gặp
Phòng thí nghiệm kiểm tra Firebase cung cấp hạn ngạch miễn phí để thử nghiệm trên thiết bị và sử dụng API đám mây. Lưu ý rằng hạn ngạch thử nghiệm sử dụng gói giá Firebase tiêu chuẩn, trong khi hạn ngạch API đám mây thì không.
Hạn ngạch kiểm tra
Hạn ngạch kiểm tra được xác định bởi số lượng thiết bị được sử dụng để chạy thử nghiệm. Gói Firebase Spark có hạn mức thử nghiệm cố định mà người dùng không mất phí. Đối với gói Blaze, hạn ngạch của bạn có thể tăng nếu mức sử dụng Google Cloud của bạn tăng theo thời gian. Nếu bạn đạt đến hạn mức thử nghiệm của mình, hãy đợi đến ngày hôm sau hoặc nâng cấp lên gói Blaze nếu bạn hiện đang sử dụng gói Spark. Nếu bạn đã sử dụng gói Blaze, bạn có thể yêu cầu tăng hạn ngạch. Để biết thêm thông tin, hãy xem Hạn ngạch kiểm tra .
Bạn có thể theo dõi việc sử dụng hạn ngạch thử nghiệm của mình trong bảng điều khiển Google Cloud .
Hạn ngạch API thử nghiệm đám mây
API kiểm tra đám mây đi kèm với hai giới hạn hạn ngạch: yêu cầu mỗi ngày cho mỗi dự án và yêu cầu mỗi 100 giây cho mỗi dự án. Bạn có thể theo dõi việc sử dụng của mình trong bảng điều khiển Google Cloud .
Hạn ngạch API kết quả của Công cụ đám mây
API kết quả của Công cụ đám mây đi kèm với hai giới hạn hạn ngạch: số truy vấn mỗi ngày cho mỗi dự án và số truy vấn mỗi 100 giây cho mỗi dự án. Bạn có thể theo dõi việc sử dụng của mình trong bảng điều khiển Google Cloud .
Tham khảo hạn ngạch Cloud API dành cho Test Lab để biết thêm thông tin về giới hạn API. Nếu bạn đã đạt đến hạn ngạch API:
Gửi yêu cầu về hạn ngạch cao hơn bằng cách chỉnh sửa hạn ngạch của bạn trực tiếp trong bảng điều khiển Google Cloud (lưu ý rằng hầu hết các giới hạn được đặt ở mức tối đa theo mặc định) hoặc
Yêu cầu hạn ngạch API cao hơn bằng cách điền vào biểu mẫu yêu cầu trong bảng điều khiển Google Cloud hoặc bằng cách liên hệ với bộ phận hỗ trợ của Firebase .
Từ chương trình phụ trợ của mình, bạn có thể xác định xem lưu lượng truy cập có đến từ các thiết bị thử nghiệm được lưu trữ trên Firebase hay không bằng cách kiểm tra địa chỉ IP nguồn dựa trên dải IP của chúng tôi.
Test Lab không hoạt động với VPC-SC, tính năng này chặn việc sao chép ứng dụng và các tạo phẩm thử nghiệm khác giữa bộ nhớ trong của Test Lab và nhóm kết quả của người dùng.
Để phát hiện hành vi không ổn định trong các thử nghiệm của bạn, chúng tôi khuyên bạn nên sử dụng tùy chọn--num-flaky-test-attempts. Số lần chạy lại làm giảm tốc độ được tính phí hoặc tính vào hạn ngạch hàng ngày của bạn giống như các lần thực hiện kiểm tra thông thường.
Hãy ghi nhớ những điều sau:
- Toàn bộ quá trình thực hiện kiểm thử sẽ chạy lại khi phát hiện thấy lỗi. Không có hỗ trợ cho việc thử lại chỉ những trường hợp thử nghiệm thất bại.
- Các lần chạy thử lại Delake được lên lịch để chạy cùng lúc nhưng không đảm bảo chạy song song, chẳng hạn như khi lưu lượng truy cập vượt quá số lượng thiết bị có sẵn.
Đúng! Test Lab hỗ trợ Google Pixel Watch. Giờ đây, bạn có thể chạy thử nghiệm trên ứng dụng Wear độc lập của mình trên Đồng hồ Google Pixel. Để tìm hiểu thêm về các thiết bị của Test Lab, hãy xem Thử nghiệm trên các thiết bị có sẵn .
Đúng! Test Lab hỗ trợ Google Pixel Tablet và Google Pixel Fold. Bạn có thể chạy thử nghiệm trên các thiết bị vật lý độc lập của mình. Để tìm hiểu thêm về các thiết bị của Test Lab, hãy xem Thử nghiệm trên các thiết bị có sẵn .
Nếu đang thử nghiệm ứng dụng của mình trong Firebase hoặc chạy thử nghiệm cho báo cáo trước khi ra mắt trong Play Console, bạn có thể phát hiện xem thử nghiệm có đang chạy trên thiết bị được lưu trữ trên Firebase hay không bằng cách kiểm tra thuộc tính hệ thống firebase.test.lab
trong tập tin MainActivity
của bạn. Sau đó, bạn có thể thực thi các câu lệnh bổ sung dựa trên giá trị boolean cho testLabSetting
. Để biết thêm thông tin, hãy xem Hành vi kiểm tra đã sửa đổi .
Mặc dù một số mục này nằm trong lộ trình của chúng tôi nhưng hiện tại chúng tôi không thể đưa ra cam kết hỗ trợ các nền tảng phát triển ứng dụng và thử nghiệm này. Tuy nhiên, nếu bạn xây dựng ứng dụng của mình bằng một khung hỗ trợ Espresso (ví dụ: Flutter), bạn có thể viết một bài kiểm thử đo lường bằng cách sử dụng Espresso rồi chạy thử nghiệm trong Test Lab.
Test Lab không hỗ trợ rõ ràng việc che giấu hoặc giải mã. Mặc dù ứng dụng có thể sẽ chạy nhưng mọi dữ liệu ứng dụng bị xáo trộn, chẳng hạn như dấu vết ngăn xếp, sẽ xuất hiện dưới dạng bị xáo trộn trong nhật ký.
Đúng! Bạn có thể kiểm tra thiết bị có thể gập lại của mình ở trạng thái và tư thế có thể gập lại .
Các thiết bị có thể gập lại có thể ở nhiều trạng thái gập khác nhau, chẳng hạn như FLAT
(mở hoàn toàn) hoặc HALF_OPENED
(giữa mở hoàn toàn và đóng hoàn toàn).
Mặt khác, các tư thế bao gồm hướng thiết bị cụ thể và trạng thái có thể gập lại. Ví dụ: tư thế đặt trên mặt bàn là trạng thái HALF_OPENED
theo hướng ngang hoặc tư thế cuốn sách là trạng thái HALF_OPENED
theo hướng dọc.
Nếu đang chạy thử nghiệm thiết bị đo lường, bạn có thể sử dụng thư viện Jetpack WindowManager và thực hiện thử nghiệm ứng dụng của mình trên tài liệu có thể gập lại để thử nghiệm ở các trạng thái và tư thế khác nhau.
Ngoài ra, các trạng thái khả dụng là dành riêng cho thiết bị và có thể được tương tác bằng cách sử dụng adb shell command cmd device_state
.
- Để liệt kê trạng thái hiện tại, hãy chạy
adb shell cmd device_state state
. - Để đặt hoặc ghi đè trạng thái hiện tại, hãy chạy
adb shell cmd device_state state <IDENTIFIER>
. - Để đặt lại trạng thái, hãy chạy
adb shell cmd device_state state reset
. - Để kiểm tra các trạng thái có sẵn, hãy chạy lệnh
adb shell cmd device_state print-states
trên thiết bị có thể gập lại.
Google Pixel Fold (ID mẫu felix
)
$ adb shell cmd device_state print-states Supported states: [ DeviceState{identifier=0, name='CLOSED', app_accessible=true}, DeviceState{identifier=1, name='HALF_OPENED', app_accessible=true}, DeviceState{identifier=2, name='OPENED', app_accessible=true}, DeviceState{identifier=3, name='REAR_DISPLAY_STATE', app_accessible=true}, ]
Samsung Galaxy Z Fold4 (ID mẫu q4q
)
$ adb shell cmd device_state print-states Supported states: [ DeviceState{identifier=0, name='CLOSE', app_accessible=true}, DeviceState{identifier=1, name='TENT', app_accessible=true}, DeviceState{identifier=2, name='HALF_FOLDED', app_accessible=true}, DeviceState{identifier=3, name='OPEN', app_accessible=true}, ]
Không giống như các sản phẩm Firebase khác, bạn không cần thêm SDK Firebase để sử dụng Test Lab. Nếu chưa có ứng dụng, bạn có thể tải xuống APK trực tuyến hoặc xây dựng ứng dụng và APK thử nghiệm từ một trong các mẫu trong kho lưu trữ AndroidX GitHub . Lưu ý rằng bạn chỉ cần tệp APK của ứng dụng để chạy thử nghiệm Robo, trong khi thử nghiệm thiết bị yêu cầu cả ứng dụng và APK thử nghiệm được tạo từ mã nguồn. Để biết thêm thông tin, hãy đọc về Kiểm tra thiết bị .
Để tìm hiểu thêm về các tính năng của Test Lab, hãy xem Bắt đầu thử nghiệm cho Android với Firebase Test Lab .
Kiểm tra sự khác biệt của ảnh chụp màn hình là nơi các xác nhận kiểm tra dựa trên việc so sánh hình ảnh màn hình thu được khi chạy thử nghiệm với hình ảnh vàng thể hiện hành vi dự kiến. Các thử nghiệm như vậy có thể dễ vỡ hơn trên một số loại thiết bị so với các loại khác. Chúng tôi khuyên bạn nên nhắm mục tiêu các thiết bị mô phỏng Arm ( *.arm
) cho các loại thử nghiệm này. Các thiết bị giả lập cánh tay sử dụng hình ảnh rất giống hoặc giống hệt với trình giả lập 'chung' của Android Studio.
Chúng tôi cũng khuyên bạn nên điều tra các thư viện kiểm tra có thể giúp thực hiện kiểm tra ảnh chụp màn hình mạnh mẽ hơn khi có những thay đổi dự kiến.
Đúng! Các thiết bị ảo được cập nhật khi thực hiện những thay đổi sau:
- Cập nhật cho hình ảnh hiện có
- Ngừng sử dụng các cấp độ API trước đó
- Các cấp độ API Android mới được thêm vào
Để bật báo cáo mức độ phù hợp, hãy thêm coverage=true
vào trường environmentVariables
. Nếu đang sử dụng Android Test Orchestrator, bạn sẽ cần cung cấp một thư mục để lưu trữ kết quả kiểm tra:
--environment-variables coverage=true,coverageFilePath=/sdcard/Download/
Nếu bạn không sử dụng Orchestrator, bạn có thể chỉ định đường dẫn tệp:
--environment-variables coverage=true,coverageFile=/sdcard/Download/coverage.ec
Thông tin chi tiết về thiết bị có sẵn thông qua API và có thể được truy cập từ ứng dụng khách gcloud bằng lệnh mô tả :
gcloud firebase test android models describe MODEL
Các vấn đề đã biết
Kiểm tra robot không thể bỏ qua màn hình đăng nhập yêu cầu hành động bổ sung của người dùng ngoài việc nhập thông tin xác thực để đăng nhập, chẳng hạn như hoàn thành CAPTCHA.
Thử nghiệm Robo hoạt động tốt nhất với các ứng dụng sử dụng các thành phần giao diện người dùng từ khung giao diện người dùng Android (bao gồm các đối tượng View
, ViewGroup
và WebView
). Nếu bạn sử dụng thử nghiệm Robo để thực hiện các ứng dụng sử dụng khung giao diện người dùng khác, bao gồm cả các ứng dụng sử dụng công cụ trò chơi Unity, thì thử nghiệm có thể thoát mà không cần khám phá ngoài màn hình đầu tiên.