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

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, các chương trình kiểm thử có thể bắt đầu nhanh hơn. Khi thiết bị có dung lượng thấp, các chương trình kiểm thử có thể mất nhiều thời gian hơn để chạy. 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 thiết bị trong Test Lab, hãy xem thông tin về dung lượng thiết bị cho Android và iOS.

Tại sao tôi nhận được kết quả thử nghiệm không rõ ràng?

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 sẽ loại bỏ các lần chạy kiểm thử tạo ra lỗi cơ sở hạ tầng nhiều lần trước khi báo cáo kết quả không kết luận được; 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 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.

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ần Dung 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 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ần thực thi kiểm thử chạy xong, trạng thái của ma trận sẽ là "Đang chờ xử lý" (bất kể các lần thực thi kiểm thử có ở trong hàng đợi hay đang chạy hay không).

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

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 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 thể tìm thấy ả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 bạn thực hiện quá trình thực thi kiểm thử trong vòng 90 ngày qua, hãy kiểm tra để đảm bảo 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 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 cách đây hơn 90 ngày, thì rất có thể 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 bộ chứa kết quả bằng cách nhấp vào thẻ Kết quả kiểm thử trong trang tổng quan Test Lab. Bộ chứa 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 bị thiếu?

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:

Hạn mức không tính phí cho Test Lab là gì? Tôi nên làm gì nếu hết hạn?

Firebase Test Lab cung cấp hạn mức miễn phí để kiểm thử trên thiết bị và sử dụng API trên đám mây. Xin lưu ý rằng hạn mức thử nghiệm sử dụng gói giá Firebase tiêu chuẩn, còn hạn mức API trên đám mây 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 liệu lưu lượng truy cập đến phần phụ trợ của tôi có đế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 một lúc, nhưng không được đảm bảo chạy song song, ví dụ: khi lưu lượng truy cập vượt quá số lượng thiết bị có sẵn.

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 các chương trình kiểm thử trên 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, bạn có thể phát hiện liệu một kiểm thử có đang chạy trên thiết bị do Firebase lưu trữ 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 có trong lộ trình của chúng tôi, nhưng hiện tại, chúng tôi không thể cam kết hỗ trợ các nền tảng phát triển ứng dụng và kiểm thử 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 đã làm rối mã (ví dụ: bằng 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 kiểm thử ứng dụng trên thiết bị có thể gập lại để kiểm thử trên 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 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.

$ 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},
]

$ 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},
]

Tôi có thể dùng thử Test Lab nếu không có ứng dụng 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.

Thiết bị nào phù hợp nhất để kiểm thử sự khác biệt giữa ả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ác câu nhận định kiểm thử dựa trên việc so sánh ảnh chụp màn hình thu được trong khi chạy kiểm thử với ảnh vàng thể hiện 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 những loại kiểm thử này. Các thiết bị trình mô phỏng Arm 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 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. Nội dung cập nhật đối với 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 độ phù hợp:

--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

Hình ảnh xác thực khi đăng nhập

Kiểm thử Robo không thể bỏ qua các màn hình đăng nhập yêu cầu người dùng thực hiện thêm hành động ngoài việc nhập thông tin đăng nhập, ví dụ: hoàn tất CAPTCHA.

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

Kiểm thử Robo hoạt động hiệu quả 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 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.