Khắc phục sự cố trong Phòng thử nghiệm & Câu hỏi thường gặp
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ề cách chạy kiểm thử với Firebase Test Lab. Các vấn đề đã biết cũng
được ghi lại. Nếu bạn không thể tìm thấy
bạn đang tìm kiếm hoặc cần được trợ giúp thêm, hãy tham gia #test-lab
kênh của bạn trên
Firebase Slack hoặc liên hệ với Firebase
hỗ trợ.
Khắc phục sự cố
Tại sao thử nghiệm của tôi mất nhiều thời gian để chạy như vậy?
Khi bạn chọn một thiết bị có mức dung lượng cao trong Test Lab
thì việc thử nghiệm có thể bắt đầu nhanh hơn. Khi một
thiết bị có dung lượng thấp, nên thử nghiệm có thể mất nhiều thời gian hơn để chạy. Nếu số lượng
các lượt kiểm thử đã gọi lớn hơn nhiều so với dung lượng của các thiết bị đã chọn, các lượt kiểm thử
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 mức dung lượng của 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 khả năng sử dụng của thiết bị và tốc độ kiểm thử.
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
nếu có cơ sở hạ tầng được báo cáo cho Test Lab, hãy xem
Trang tổng quan về trạng thái của Firebase.
Để tìm hiểu thêm về dung lượng của thiết bị ở Test Lab, hãy xem dung lượng của thiết bị
dành cho Android và iOS.
Vì sao tôi nhận được kết quả thử nghiệm không xác định được?
Kết quả thử nghiệm không thể đưa ra kết luận thường xảy ra do các lượt chạy thử nghiệm bị huỷ
hoặc lỗi cơ sở hạ tầng.
Lỗi cơ sở hạ tầng do các vấn đề nội bộ của Test Lab gây ra, chẳng hạn như mạng
lỗi hoặc hành vi không mong muốn của thiết bị. Test Lab ngừng chạy kiểm thử trong nội bộ
gây ra lỗi cơ sở hạ tầng nhiều lần trước khi báo cáo
kết quả chưa rõ; tuy nhiên, bạn có thể tắt các lần thử lại này bằng cách sử dụng
thất bại nhanh.
Để xác định nguyên nhân gây ra lỗi, hãy làm theo các bước sau:
Thử kiểm thử lại trong Test Lab để xác minh rằng mã này có thể tái tạo.
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 đang bật
Slack của Firebase.
Tại sao tính năng phân đoạn khiến kiểm thử của tôi chạy
lâu hơn?
Việc phân đoạn có thể khiến chương trình kiểm thử chạy lâu hơn khi bạn nhận được số lượng phân đoạn
đã chỉ định vượt quá số lượng thiết bị có thể sử dụng trong Test Lab. Người nhận
để tránh trường hợp này, hãy thử chuyển sang một thiết bị khác. Thông tin khác
về cách chọn một thiết bị khác, hãy xem
Dung lượng của thiết bị.
Tại sao lại mất nhiều thời gian để
thử nghiệm để bắt đầu không?
Khi bạn gửi một yêu cầu kiểm thử, lần đầu tiên ứng dụng của bạn được xác thực, ký lại, v.v. trong
để chuẩn bị cho việc chạy kiểm thử trên một thiết bị. Thông thường, quá trình này hoàn tất sau
ít hơn một vài giây, nhưng nó có thể bị ảnh hưởng bởi các yếu tố như quy mô của trang web
.
Sau khi ứng dụng của bạn được chuẩn bị, các phiên chạy thử nghiệm sẽ được lên lịch và vẫn nằm trong hàng đợi
cho đến khi thiết bị sẵn sàng chạy chiến dịch. Cho đến khi tất cả các phiên chạy thử nghiệm chạy xong,
trạng thái ma trận sẽ là "Đang chờ xử lý" (bất kể các lần chạy thử nghiệm
trong hàng đợi hoặc đang chạy).
Tại sao lại mất nhiều thời gian để
thử nghiệm đến khi nào?
Sau khi phiên chạy kiểm thử hoàn tất, các cấu phần phần mềm kiểm thử sẽ được tải xuống từ
thiết bị, đã 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 cấu phần phần mềm.
Ứng dụng không trả về dữ liệu và không tìm được ảnh chụp màn hình
Các cấu phần phần mềm thực thi kiểm thử (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
phiên bả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 để đảm bảo rằng
các vai trò ở cấp dự án được chỉ định (chủ sở hữu dự án, người chỉnh sửa dự án hoặc người xem dự án).
Vui lòng đảm bảo rằng bạn đã bật tính năng Ghi nhật ký kiểm tra trên đám mây cho dự án của mình
hoặc tổ chức của bạn.
Nếu việc thực thi được thực hiện hơn 90 ngày trước, hầu hết
có thể các cấu phần phần mềm kiểm thử đã bị xoá tự động. Bạn có thể xem
cấu hình nhóm kết quả bằng cách nhấp vào thẻ Kết quả kiểm tra trong
Trang tổng quan của Test Lab. Kết quả mặc định
nhóm được định cấu hình để giữ lại các đối tượng trong 90 ngày.
Để giữ lại các cấu phần phần mềm kiểm thử lâu hơn, hãy chạy lệnh
gcloud firebase test android run với cờ --results-bucket và truyền vào
tên của nhóm kết quả. Để biết thêm thông tin, hãy truy cập vào
Tài liệu tham khảo về gcloud firebase test android run.
Tại sao tôi nhận được kết quả kiểm thử đo lường một phần hoặc không có kết quả?
Khi chạy kiểm thử đo lường, bạn có thể thấy các lỗi kiểm thử cho biết một phần
kết quả 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 để bắt đầu trường hợp kiểm thử
hoặc điểm đánh dấu kết thúc thường được tạo bởi
AndroidJUnitRunner.
Sau đây là những nguyên nhân phổ biến gây ra vấn đề này:
Mô tả vấn đề
Giải pháp có thể áp dụng
Trường hợp kiểm thử không chạy do hết thời gian chờ. Nếu tổng thời lượng của
dài hơn thời gian chờ bạn đã chỉ định hoặc lâu hơn
thời gian chờ tối đa,
Test Lab sẽ huỷ các trường hợp kiểm thử còn lại.
Tăng thời gian chờ cho ma trận để đảm bảo tất cả các thử nghiệm đều có thể hoàn tất.
Phân đoạn các chương trình kiểm thử nếu bạn chưa thực hiện việc này, để mỗi phân đoạn chạy một
tập hợp con bài kiểm thử và hoàn thành trong khoảng thời gian ngắn hơn.
Nếu bạn đã bật tính năng phân đoạn, hãy tăng số lượng phân đoạn.
Trường hợp kiểm thử không hoàn tất được do thoát sớm hoặc bị lỗi.
Trường hợp kiểm thử có thể thoát sớm do có ngoại lệ chưa nắm bắt được hoặc
lỗi xác nhận. Các trường hợp kiểm thử 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, ví dụ: nếu ứng dụng không hiển thị chế độ xem chính xác và
trường hợp kiểm thử không thể thực hiện thao tác trên giao diện người dùng.
Kiểm tra video và logcat để tìm hiểu nơi tiến hành xét nghiệm
đã dừng.
Một trình chạy kiểm thử tuỳ chỉnh (bao gồm cả việc mở rộng AndroidJUnitRunner) đã gặp sự cố
bất ngờ hoặc đã ghi điểm đánh dấu bắt đầu hoặc kết thúc trường hợp kiểm thử không mong muốn vào
logcat.
Kiểm tra mã trình chạy kiểm thử của bạn.
Quá nhiều nhật ký đã được ghi vào logcat, gây quá tải cho bộ đệm
hoặc đã gặp sự cố đối với quy trình logcat.
Giảm số lượt ghi vào logcat.
Ứng dụng đang được kiểm thử đã gặp sự cố.
Gỡ lỗi ứng dụng.
Câu hỏi thường gặp
Hạn mức không mất phí là gì
cho Test Lab? Tôi nên làm gì nếu dùng hết?
Firebase Test Lab cung cấp hạn mức miễn phí cho việc thử nghiệm trên các thiết bị và để sử dụng
Cloud API. Xin lưu ý rằng hạn mức thử nghiệm sử dụng gói giá Firebase chuẩn,
còn hạn mức Cloud API thì không.
Hạn mức thử nghiệm
Hạn mức kiểm thử được xác định theo số lượng thiết bị dùng để chạy kiểm thử.
Gói Firebase Spark có hạn mức thử nghiệm cố định mà người dùng không phải trả phí. Cho
gói linh hoạt, hạn mức của bạn có thể tăng lên nếu bạn sử dụng Google Cloud
sẽ tăng theo thời gian. Nếu bạn đạt đến hạn mức thử nghiệm, hãy đợi đến
ngày hoặc nâng cấp lên gói linh hoạt nếu bạn hiện đang dùng gói Spark.
Nếu đang dùng Gói linh hoạt, bạn có thể yêu cầu tăng hạn mức.
Để biết thêm thông tin, hãy xem
Hạn mức thử nghiệm.
Cloud Testing API có hai giới hạn hạn mức: số yêu cầu mỗi ngày mỗi ngày
dự án và số yêu cầu cứ 100 giây trong mỗi dự án. Bạn có thể theo dõi
mức sử dụng trong
Bảng điều khiển Google Cloud.
Hạn mức API Kết quả của Cloud Tool
Cloud Tool Results API có hai giới hạn hạn mức: truy vấn mỗi ngày mỗi ngày
dự án và truy vấn mỗi 100 giây trong mỗi dự án. Bạn có thể theo dõi
mức sử dụng trong
Bảng điều khiển Google Cloud.
Gửi yêu cầu nâng hạn mức muộn nhất vào
chỉnh sửa hạn mức
ngay trong bảng điều khiển Google Cloud (lưu ý rằng hầu hết các giới hạn đều được đặt thành
tối đa theo mặc định) hoặc
Yêu cầu hạn mức 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 của Google Cloud hoặc bằng cách liên hệ
Hỗ trợ của Firebase.
Làm cách nào để biết liệu
lưu lượng truy cập đến phần phụ trợ của tôi có đến từ Test Lab không?
Từ phần phụ trợ, bạn có thể xác định xem lưu lượng truy cập có đến từ dịch vụ lưu trữ của Firebase hay không
kiểm tra thiết bị bằng cách kiểm tra địa chỉ IP nguồn so với
Dải IP.
Test Lab có hoạt động với
VPC-SC?
Test Lab không hoạt động với VPC-SC. Tính năng này chặn
sao chép ứng dụng và các cấu phần phần mềm kiểm thử khác giữa các thành phần nội bộ của Test Lab
bộ nhớ và dữ liệu của người dùng nhóm kết quả.
Làm cách nào để phát hiện kiểm tra không ổn định trong
Test Lab?
Để phát hiện hành vi không ổn định trong các kiểm thử của mình, bạn nên sử dụng
--num-flaky-tests
. Các lượt chạy lại của Deflake được tính phí hoặc tính vào hạn mức hằng ngày của bạn giống như
các lần thực thi kiểm thử thông thường.
Hãy ghi nhớ những điều sau:
Toàn bộ quá trình chạy kiểm thử sẽ chạy lại khi phát hiện thấy lỗi. Không có
hỗ trợ chỉ thử lại các trường hợp kiểm thử không thành công.
Các lần chạy thử lại Deflake được lên lịch để chạy cùng lúc, nhưng không được
được đảm bảo chạy song song, ví dụ: khi lưu lượng truy cập vượt quá số lần
thiết bị có sẵn.
Test Lab có hỗ trợ
thiết bị đeo?
Có! 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 bạn trên Google Pixel Watch. Để tìm hiểu thêm về
Test Lab thiết bị, hãy xem phần Kiểm thử trên
thiết bị có sẵn.
Test Lab có hỗ trợ
thiết bị mới nhất của Google?
Có! Test Lab hỗ trợ Google Pixel Tablet và Google Pixel Fold. Bạn có thể
bạn có thể chạy bài kiểm thử trên các thiết bị thực độc lập.
Để tìm hiểu thêm về
Test Lab thiết bị, hãy xem phần Kiểm thử trên
thiết bị có sẵn.
Cách phát hiện một thử nghiệm đang chạy
trong Test Lab?
Nếu bạn đang thử nghiệm ứng dụng trong Firebase hoặc chạy thử nghiệm cho một
báo cáo trước khi ra mắt
trong Play Console, bạn có thể xác định xem thử nghiệm có đang
chạy trên thiết bị được lưu trữ trên Firebase bằng cách kiểm tra thuộc tính hệ thống
firebase.test.lab trong tệp MainActivity. Sau đó, bạn có thể thực thi thêm
dựa trên giá trị boolean cho testLabSetting. Để biết thêm
thông tin, xem
Sửa đổi hành vi kiểm thử.
Có phải Test Lab
hỗ trợ Appium, Flutter/FlutterDriver, ReactNative/Jest hoặc Cucumber?
Mặc dù một số mục trong số này đang trong lộ trình phát triển, nhưng chúng tôi hiện chưa thể cung cấp
cam kết hỗ trợ các nền tảng thử nghiệm và phát triển ứng dụng này. Tuy nhiên,
nếu bạn xây dựng ứng dụng bằng khung hỗ trợ Espresso (ví dụ:
Flutter), bạn có thể viết một kiểm thử đo lường bằng
Espresso
rồi chạy kiểm thử trong Test Lab.
Có phải Test Lab
hỗ trợ kiểm thử các ứng dụng bị làm rối mã nguồn, chẳng hạn như với ProGuard hoặc R8)?
Test Lab không hỗ trợ rõ ràng tính năng làm rối mã nguồn hoặc gỡ rối mã nguồn. Trong khi
ứng dụng có thể sẽ chạy, bất kỳ dữ liệu ứng dụng nào bị làm rối mã nguồn (như dấu vết ngăn xếp),
sẽ xuất hiện dưới dạng bị làm rối mã nguồn trong nhật ký.
Tôi có thể dùng thiết bị có thể gập lại ở
có nhiều trạng thái và tư thế của thiết bị có thể gập lại khi kiểm thử trên Test Lab?
Thiết bị có thể gập lại có nhiều trạng thái gập, chẳng hạn như FLAT (mở hoàn toàn) hoặc HALF_OPENED (mở hoàn toàn và đóng hoàn toàn).
Mặt khác, các tư thế bao gồm hướng cụ thể của thiết bị và thiết bị có thể gập lại
trạng thái. Ví dụ: tư thế trên mặt bàn (là trạng thái HALF_OPENED theo hướng ngang) hoặc tư thế sách (là trạng thái HALF_OPENED theo hướng dọc).
Tôi có thể dùng thử Test Lab nếu chưa có
một ứng dụng?
Không giống như các sản phẩm Firebase khác, bạn không cần thêm Firebase
SDK để sử dụng Test Lab. Nếu chưa có ứng dụng, bạn có thể
tải APK trực tuyến xuống hoặc tạo ứng dụng và APK kiểm thử từ một trong
các mẫu trong kho lưu trữ GitHub AndroidX.
Xin 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 kiểm thử đo lường yêu cầu cả hai
một ứng dụng và một APK kiểm thử được tạo từ mã nguồn. Để biết thêm thông tin,
hãy đọc bài viết về Kiểm thử đo lường.
Những thiết bị phù hợp nhất
kiểm thử sự khác biệt về ảnh chụp màn hình?
Kiểm thử sự khác biệt về ảnh chụp màn hình là nơi xác nhận thử nghiệm được dựa trên việc so sánh màn hình
hình ảnh thu được trong khi chạy thử nghiệm hình ảnh vàng
hành vi. Trên một số loại thiết bị, các thử nghiệm như vậy có thể khó khăn hơn so với các loại thiết bị khác. Bạn nên nhắm mục tiêu
Arm (*.arm) thiết bị trình mô phỏng cho các loại kiểm thử này. Bật chuông báo động mà thiết bị trình mô phỏng sử dụng
hình ảnh rất giống hoặc giống hệt với trình mô phỏng "chung" của Android Studio.
Bạn cũng nên điều tra các thư viện kiểm thử có thể giúp
ảnh chụp màn hình thử nghiệm mạnh mẽ hơn khi có những thay đổi dự kiến.
Test Lab có cập nhật các thiết bị ảo không?
Có! Các thiết bị ảo được cập nhật khi bạn thực hiện các thay đổi sau:
Cập nhật hình ảnh hiện có
Ngừng sử dụng các cấp độ API trước đó
Đã thêm các cấp độ API Android mới
Làm cách nào để bật báo cáo mức độ phù hợp?
Để 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 cần cung cấp một thư mục để
lưu trữ kết quả mức độ phù hợp:
Tôi có thể tìm thông tin về thiết bị ở đâu, chẳng hạn như
độ phân giải, ABI được hỗ trợ, v.v.?
Thông tin chi tiết về thiết bị được cung cấp thông qua API và có thể truy cập được
từ ứng dụng gcloud bằng
lệnh mô tả:
gcloud firebase test android models describe MODEL
Các vấn đề đã biết
Hình ảnh xác thực đăng nhập
Thử nghiệm Robo không thể bỏ qua các 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 đăng nhập để đăng nhập. Ví dụ:
hoàn tất một CAPTCHA.
Hỗ trợ khung giao diện người dùng
Thử nghiệm Robo hoạt động hiệu quả nhất với các ứng dụng sử dụng các phần tử trên giao diện người dùng của Android
khung (bao gồm View, ViewGroup và WebView
đối tượng). Nếu bạn sử dụng thử nghiệm Robo để tập thể dục các ứng dụng sử dụng giao diện người dùng khác
khung (bao gồm cả các ứng dụng sử dụng công cụ phát triển trò chơi Unity) thì quy trình kiểm thử có thể thoát
mà không cần khám phá ngoài màn hình đầu tiên.