Khắc phục sự cố trong Phòng thử nghiệm & Câu hỏi thường gặp

iOS Android

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 kiểm thử bằng Firebase Test Lab. Các vấn đề đã biết cũng được ghi lại. Nếu bạn không tìm thấy nội dung mình cần hoặc cần được trợ giúp thêm, hãy tham gia kênh #test-lab trên Firebase Slack hoặc liên hệ với nhóm hỗ trợ Firebase.

Khắc phục sự cố

Tại sao quá trình kiểm thử của tôi lại mất nhiều thời gian như vậy?

Khi bạn chọn một thiết bị có mức dung lượng cao trong danh mục Test Lab, quá trình kiểm thử có thể bắt đầu nhanh hơn. Khi thiết bị có dung lượng thấp, quá trình kiểm thử có thể mất nhiều thời gian hơn. Nếu số lượng kiểm thử được gọi lớn hơn nhiều so với dung lượng của các thiết bị đã chọn, thì quá trình kiểm thử có thể mất nhiều thời gian hơn để hoàn tất.

Các chương trình kiểm thử chạy trên bất kỳ cấp độ dung lượng thiết bị nào cũng 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 thiết bị và tốc độ kiểm thử.
• Sự cố 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 nào được báo cáo cho Test Lab hay không, hãy xem trang tổng quan về trạng thái Firebase.

Để tìm hiểu thêm về dung lượng của thiết bị trong Test Lab, hãy xem thông tin về dung lượng 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ả kiểm thử không kết luận được thường xảy ra do các lần chạy kiểm thử bị huỷ hoặc lỗi cơ sở hạ tầng.

Lỗi cơ sở hạ tầng là do các vấn đề Test Lab nội bộ gây ra, chẳng hạn như lỗi mạng hoặc hành vi không mong muốn của thiết bị. Test Lab gỡ bỏ nội bộ các lần chạy kiểm thử 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 xác định. Tuy nhiên, bạn có thể tắt các lần thử lại này bằng failFast.

Để xác định nguyên nhân gây ra lỗi, hãy làm theo các bước sau:

1. Kiểm tra các sự cố đã biết trong trang tổng quan về trạng thái Firebase.

2. Thử lại kiểm thử trong Test Lab để xác minh rằng kiểm thử đó có thể tái hiện.

   Lưu ý: Test Lab không tính phí bạn đối với các lỗi về cơ sở hạ tầng.

3. Hãy thử chạy kiểm thử trên một thiết bị hoặc loại thiết bị khác (nếu có).

Nếu vấn đề 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.

Tại sao việc phân đoạn khiến các chương trình kiểm thử của tôi chạy lâu hơn?

Tính năng phân đoạn có thể khiến các chương trình kiểm thử 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ó thể sử dụng trong Test Lab. Để tránh trường hợp 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 một thiết bị khác, hãy xem phầnDung lượng thiết bị.

Tại sao quá trình kiểm thử của tôi mất nhiều thời gian để bắt đầu?

Khi bạn gửi một yêu cầu kiểm thử, trước tiên, ứng dụng của bạn sẽ được xác thực, ký lại, v.v. để chuẩn bị chạy kiểm thử trên một thiết bị. Thông thường, quá trình này sẽ hoàn tất trong chưa đến vài giây, nhưng có thể chịu ảnh hưởng của các yếu tố như kích thước ứng dụng.

Sau khi ứng dụng của bạn được chuẩn bị, các lần thực thi kiểm thử 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 ứng dụng. Cho đến khi tất cả các lượt chạy kiểm thử chạy xong, trạng thái ma trận sẽ là "Đang chờ xử lý" (bất kể các lượt thực thi kiểm thử nằm trong hàng đợi hay đang hoạt động).

Lưu ý: Thời gian chờ thiết bị có sẵn để kiểm thử không được tính vào thời gian thanh toán.

Tại sao mất nhiều thời gian để thử nghiệm kết thúc?

Sau khi quá trình thực thi 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 gian của bước này có thể chịu ảnh hưởng của số lượng và kích thước của các 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à trực tiếp hiển thị trong bảng điều khiển Firebase. Nếu phiên chạy thử nghiệm của bạn được thực hiện trong vòng 90 ngày qua, hãy kiểm tra để chắc chắn rằng 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). Ngoài ra, hãy đảm bảo rằng bạn chưa bật tính năng Ghi nhật ký kiểm tra trên đám mây cho dự án hoặc tổ chức của mình.

Nếu quá trình thực thi đã được thực hiện hơn 90 ngày trước, thì nhiều khả năng các cấu phần phần mềm kiểm thử đã tự động bị xoá. Bạn có thể kiểm tra cấu hình nhóm kết quả bằng cách nhấp vào thẻ Kết quả kiểm thử trong trang tổng quan của Test Lab. Thùng 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ấ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 bộ chứa 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 lỗi kiểm thử cho biết một số 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 cho điểm bắt đầu hoặc điểm kết thúc của trường hợp kiểm thử thường do AndroidJUnitRunner tạo.

Sau đây là các nguyên nhân phổ biến dẫn đến 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 các bài kiểm thử dài hơn thời gian chờ mà bạn chỉ định hoặc dài hơn thời gian chờ tối đa, thì 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 bài kiểm thử đều có thể hoàn tất. Hãy phân đoạn các chương trình kiểm thử nếu bạn chưa thực hiện, để mỗi phân đoạn chạy một tập hợp con các bài kiểm thử và hoàn tất 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.
Không thể hoàn tất trường hợp kiểm thử vì trường hợp này đã thoát sớm hoặc bị treo. Trường hợp kiểm thử có thể thoát sớm do một ngoại lệ chưa được phát hiện hoặc lỗi xác nhận. Các trường hợp kiểm thử có thể bị 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 hành động trên giao diện người dùng.	Kiểm tra video và logcat để tìm hiểu vị trí kiểm thử dừng lại.
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 các đ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ử.
Quá nhiều nhật ký đã được ghi vào logcat, khiến vùng đệm quá tải hoặc làm hỏng quy trình logcat.	Giảm số lần ghi vào logcat.
Ứng dụng đang 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 tính phí cho Test Lab là gì? Tôi nên làm gì nếu dùng hết?

Firebase Test Lab cung cấp các hạn mức không tính phí cho việc kiểm thử trên các thiết bị và việc sử dụng các API đám mây. Xin lưu ý rằng hạn mức kiểm thử sử dụng gói giá Firebase tiêu chuẩn, còn hạn mức Cloud API thì không.

• Hạn mức kiểm thử

  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 kiểm thử cố định mà người dùng không phải trả phí. Đối với gói Blaze, hạn mức của bạn có thể tăng lên nếu mức sử dụng Google Cloud của bạn tăng lên theo thời gian. Nếu bạn đạt đến hạn mức kiểm thử, hãy đợi đến ngày tiếp theo hoặc nâng cấp lên gói Blaze nếu bạn đang dùng gói Spark. Nếu đang sử dụng gói Blaze, bạn có thể yêu cầu tăng hạn mức. Để biết thêm thông tin, hãy xem phần Kiểm thử hạn mức.

  Bạn có thể theo dõi mức sử dụng hạn mức kiểm thử trong bảng điều khiển Google Cloud.

• Hạn mức API Kiểm thử trên đám mây

  Cloud Testing API có hai hạn mức: số yêu cầu mỗi ngày cho mỗi dự án và số yêu cầu mỗi 100 giây cho 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ông cụ trên đám mây

  API Kết quả công cụ trên đám mây có hai hạn mức: 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 mức sử dụng trong bảng điều khiển Google Cloud.

  Tham khảo phần Hạn mức API trên đám mây cho Test Lab để biết thêm thông tin về các giới hạn API. Nếu bạn đã đạt đến hạn mức API:

  • Gửi yêu cầu tăng hạn mức bằng cách chỉnh sửa hạn mức 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 đều được đặt thành tối đa theo mặc định) hoặc

  • Yêu cầu tăng hạn mức API 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 liên hệ với nhóm hỗ trợ Firebase.

Làm cách nào để biết lưu lượng truy cập đến phần phụ trợ của tôi có bắt nguồn từ Test Lab hay 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ừ các thiết bị thử nghiệm do Firebase lưu trữ hay không bằng cách kiểm tra địa chỉ IP nguồn với dải IP của chúng tôi.

Test Lab có hoạt động với VPC-SC không?

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 cấu phần phần mềm kiểm thử khác giữa bộ nhớ nội bộ của Test Lab và các bộ chứa kết quả của người dùng.

Làm cách nào để phát hiện các kiểm thử không ổn định trong Test Lab?

Để phát hiện hành vi không ổn định trong kiểm thử, bạn nên sử dụng tuỳ chọn--num-flaky-test-attempts. Các lần chạy lại Deflake sẽ đượ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 thực thi kiểm thử sẽ chạy lại khi phát hiện lỗi. Không hỗ trợ việc 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 đảm bảo sẽ 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.

Lưu ý: Lỗi cơ sở hạ tầng độc lập với tính năng loại bỏ tệp trùng lặp và không kích hoạt quá trình chạy lại tính năng loại bỏ tệp trùng lặp.

Test Lab có hỗ trợ thiết bị đeo không?

Có! Test Lab hỗ trợ Google Pixel Watch. Giờ đây, bạn có thể chạy kiểm thử trên ứng dụng Wear độc lập trên Google Pixel Watch. Để tìm hiểu thêm về các thiết bị Test Lab, hãy xem phần Kiểm thử trên các thiết bị có sẵn.

Test Lab có hỗ trợ các thiết bị mới nhất của Google không?

Có! Test Lab hỗ trợ Google Pixel Tablet và Google Pixel Fold. Bạn có thể chạy kiểm thử trên các thiết bị thực độc lập. Để tìm hiểu thêm về các thiết bị Test Lab, hãy xem phần Kiểm thử trên các thiết bị có sẵn.

Làm cách nào để phát hiện một kiểm thử đang chạy trong Test Lab?

Nếu đang kiểm thử ứng dụng trong Firebase hoặc chạy kiểm thử cho báo cáo trước khi ra mắt trong Play Console, thì bạn có thể kiểm tra xem có đang chạy kiểm thử 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 MainActivity. 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 phần Hành vi kiểm thử đã sửa đổi.

Test Lab có hỗ trợ Appium, Flutter/FlutterDriver, ReactNative/Jest hay Cucumber không?

Mặc dù một số mục trong số này đang trong lộ trình, nhưng hiện tại chúng tôi chưa thể cam kết hỗ trợ các nền tảng kiểm thử và phát triển ứng dụng này. Tuy nhiên, nếu đã tạo ứng dụng bằng một khung hỗ trợ Espresso (ví dụ: Flutter), bạn có thể viết mã kiểm thử đo lường bằng Espresso rồi chạy kiểm thử trong Test Lab.

Test Lab có hỗ trợ kiểm thử các ứng dụng bị làm rối mã nguồn (ví dụ: với ProGuard hoặc R8) không?

Test Lab không hỗ trợ rõ ràng việc làm rối mã nguồn hoặc gỡ rối mã nguồn. Mặc dù ứng dụng có thể chạy, nhưng mọi dữ liệu ứng dụng bị làm rối mã nguồn, chẳng hạ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ể sử dụng thiết bị có thể gập lại ở nhiều trạng thái và tư thế gập lại trong khi kiểm thử trên Test Lab không?

Có! Bạn có thể kiểm thử thiết bị có thể gập lại ở các trạng thái và tư thế có thể gập lại.

Thiết bị có thể gập lại ở nhiều trạng thái, chẳng hạn như FLAT (mở hoàn toàn) hoặc HALF_OPENED (giữa mở ra và đóng lại hoàn toàn).

Mặt khá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ế trên mặt bàn là trạng thái HALF_OPENED theo hướng ngang hoặc tư thế trang sách là trạng thái HALF_OPENED theo hướng dọc.

Nếu đang chạy kiểm thử đo lường, bạn có thể sử dụng thư viện Jetpack WindowManager và làm theo tài liệu về kiểm thử ứng dụng trên thiết bị có thể gập lại để kiểm thử nhiều trạng thái và tư thế.

Ngoài ra, các trạng thái có sẵn là dành riêng cho thiết bị và có thể tương tác bằ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 hiện có, 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 (mã thiết bị 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 (mã 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},
]

Nếu không có ứng dụng, tôi có thể dùng thử Test Lab không?

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 tệp APK xuống trên mạng hoặc tạo ứng dụng và tệp APK kiểm thử từ một trong các mẫu trong kho lưu trữ GitHub của AndroidX. Xin lưu ý rằng bạn chỉ cần tệp APK của ứng dụng để chạy kiểm thử Robo, trong khi kiểm thử đo lường yêu cầu cả ứng dụng và tệp 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.

Để tìm hiểu thêm về các tính năng của Test Lab, hãy xem bài viết Bắt đầu kiểm thử cho Android bằng Firebase Test Lab.

Những thiết bị nào 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 câu nhận định kiểm thử được dựa trên việc so sánh hình ảnh màn hình thu được trong khi chạy kiểm thử với hình ảnh vàng đại diện cho hành vi dự kiến. Các chương trình kiểm thử như vậy có thể dễ bị lỗi hơn trên một số loại thiết bị so với các loại thiết bị khác. Bạn nên nhắm đến các thiết bị trình mô phỏng Arm (*.arm) cho các loại kiểm thử này. Thiết bị trình mô phỏng Arm sử dụng hình ảnh rất giống hoặc giống 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 kiểm thử ảnh chụp màn hình trở nên mạnh mẽ hơn khi có các thay đổi dự kiến.

Test Lab có cập nhật thiết bị ảo không?

Có! Thiết bị ảo được cập nhật khi bạn thực hiện những thay đổi sau:

1. Cập nhật hình ảnh hiện có
2. Ngừng sử dụng các cấp độ API cũ
3. 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 độ sử dụng, 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ả về mức độ sử dụng:

--environment-variables coverage=true,coverageFilePath=/sdcard/Download/

Nếu không sử dụng Trình điều phối, bạn có thể chỉ định đường dẫn tệp:

--environment-variables coverage=true,coverageFile=/sdcard/Download/coverage.ec

Tôi có thể tìm thông tin chi tiết về thiết bị, chẳng hạn như độ phân giải, ABI được hỗ trợ, v.v. ở đâu?

Bạn có thể xem thông tin chi tiết về thiết bị thông qua API và truy cập thông tin đó 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 khi đăng nhập

Thử nghiệm Robo không thể bỏ qua các màn hình đăng nhập đòi hỏi người dùng thực hiện thêm thao tác ngoài việc nhập thông tin đăng nhập, chẳng hạn như hoàn thành hình ảnh xác thực (CAPTCHA).

Hỗ trợ khung giao diện người dùng

Quy trình kiểm thử 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 trong khung giao diện người dùng Android (bao gồm cả các đối tượng View, ViewGroup và WebView). Nếu bạn sử dụng kiểm thử Robo để thực thi các ứng dụng sử dụng các 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ụ phát triển trò chơi Unity, thì quy trình kiểm thử có thể thoát mà không khám phá ra ngoài màn hình đầu tiên.