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 chạy thử nghiệm của tô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 Test Lab danh mục, 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 kiểm thử có thể mất nhiều thời gian hơn để chạy. Nếu số lượng chương trình 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ì các chương 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 thiết bị có dung lượng ở bất kỳ cấp độ nào đều 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ố về 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 rõ ràng 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 đề nội bộ của Test Lab, 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ẽ thử lại 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 rõ ràng; 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 bài kiểm thử trong Test Lab để xác minh rằng bài kiểm thử đó có thể tái hiện được.

3. 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 thử nghiệm của tôi chạy lâu hơn?

Việc phân đoạn có thể khiến các chương trình kiểm thử 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 tình huố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 một thiết bị khác, hãy xem phần Dung lượng thiết bị.

Tại sao thử nghiệm của tôi mất nhiều thời gian mới 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 thiết bị. Thông thường, quá trình này hoàn tất trong chưa đầy vài giây, nhưng có thể bị ảnh hưởng bởi các yếu tố như kích thước của ứng dụng.

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à nằm trong hàng đợi cho đến khi có thiết bị sẵn sàng chạy. Cho đến khi tất cả các phiên chạy thử nghiệm hoàn tất, trạng thái của ma trận sẽ là "Đang chờ xử lý" (bất kể phiên chạy thử nghiệm đang ở trong hàng đợi hay đang chạy).

Tại sao thử nghiệm của tôi mất nhiều thời gian mới hoàn tất?

Sau khi phiên chạy thử nghiệm hoàn tất, các cấu phần phần mềm thử nghiệm 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 của phiên chạy 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 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 để đảm bảo rằng bạn đã gán 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). Vui lòng đả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ì 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ẻ Test results (Kết quả kiểm thử) trong trang tổng quan 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 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 bằng cờ --results-bucket và truyền tên của bộ chứa kết quả. Để biết thêm thông tin, hãy xem tài liệu tham khảo về gcloud firebase test android run.

Tại sao tôi nhận được kết quả trường hợp kiểm thử đo lường không đầy đủ hoặc 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 kết quả một phần 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 gây ra vấn đề này:

Hạn mức miễn phí cho Test Lab là bao nhiêu? Tôi nên làm gì nếu dùng hết giấy phép?

Firebase Test Lab cung cấp hạn mức miễn phí để thử nghiệm trên 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á tiêu chuẩn của Firebase, trong khi hạn mức Cloud APIs 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 kiểm thử cố định mà không tính phí cho người dùng. Đố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 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 sử dụng gói Spark. Nếu đã 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 Hạn mức kiểm thử.

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

• Hạn mức Cloud Testing API

  Cloud Testing API có hai giới hạn về 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 của mình trong bảng điều khiển Google Cloud.

• Hạn mức Cloud Tool Results API

  Cloud Tool Results API có hai giới hạn về 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 của mình trong bảng điều khiển Google Cloud.

  Tham khảo Hạn mức API đám mây cho Test Lab để biết thêm thông tin về 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 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 ở mức 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 bằng cách liên hệ với bộ phận hỗ trợ của 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ó phải 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 dựa trên 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, điều 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ớ trong của Test Lab và 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 các thử nghiệm, bạn nên sử dụng tuỳ chọn --num-flaky-test-attempts . Các lần chạy lại để loại bỏ lỗi không ổn định 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 phiên chạy thử nghiệm thông thường.

Hãy ghi nhớ những điều sau:

• Toàn bộ phiên chạy thử nghiệm sẽ chạy lại khi phát hiện thấy lỗi. Không có tính năng hỗ trợ thử lại chỉ cho các trường hợp kiểm thử không thành công.
• Các lần chạy thử lại để loại bỏ lỗi không ổn định đượ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ị hiện có.

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

Mặc dù một số mục trong số 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ể cam kết hỗ trợ các nền tảng thử nghiệm và phát triển ứng dụng này.

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, v.v. ở đâu?

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 ios models describe MODEL

Tôi có thể sử dụng tính năng phân đoạn với các thử nghiệm trên iOS không?

Tính năng phân đoạn không được hỗ trợ sẵn trong Test Lab cho iOS. Tuy nhiên, bạn có thể sử dụng ứng dụng Flank để phân đoạn các trường hợp kiểm thử iOS.

Cách này hoạt động bằng cách đặt khoá và giá trị OnlyTestIdentifiers trong tệp .xctestrun. Hãy xem trang man về xcodebuild.xctestrun để biết thêm thông tin.

Tại sao kết quả thử nghiệm trên iOS của tôi lại thiếu video?

Đối với iOS 18 trở lên, chúng tôi không thể hỗ trợ video trong kết quả.

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 thử nghiệm trên ứng dụng Wear độc lập của mình 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 bài viết Kiểm thử trên các thiết bị hiện có.

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 xem 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 hoặc Cucumber không?

Mặc dù một số mục trong số 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ể 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 một 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.

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

Test Lab không hỗ trợ rõ ràng cho 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ể sẽ 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 ở các trạng thái và tư thế gập khác nhau khi thử nghiệm trên Test Lab không?

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

Thiết bị gập 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 (các trạng thái khác 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 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.

$ 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 khác của Firebase, 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 tệp APK xuống trên mạng hoặc tạo một ứng dụng và tệp 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ả ứng dụng và tệp APK thử nghiệm đượ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ử ảnh chụp màn hình?

Kiểm thử sự khác biệt về ảnh chụp màn hình là khi các câu nhận định kiểm thử 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 chuẩn thể hiện hành vi dự kiến. Những thử nghiệm như vậy có thể dễ hỏng trên một số loại thiết bị hơn 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 hệt với trình mô phỏng "chung" của Android Studio.

Bạn cũng nên tìm hiểu các thư viện kiểm thử có thể giúp kiểm thử ảnh chụp màn hình hiệu quả 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 sẽ được cập nhật khi có 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ấ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ả về mức độ phù hợp:

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

Nếu 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

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?

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

Làm cách nào để đăng nhập vào ứng dụng Wear mà không cần điện thoại?

Nếu ứng dụng của bạn hỗ trợ tính năng Đăng nhập bằng Google, thì tính năng này sẽ tự động hoạt động với tài khoản thử nghiệm. Nếu không, nếu ứng dụng của bạn thường yêu cầu điện thoại để đăng nhập, bạn có thể tạo một biến thể bản dựng bỏ qua bước đăng nhập và sử dụng mã thông báo được nhúng trong bản dựng thử nghiệm hoặc đọc từ các tệp trên ổ đĩa thường được đẩy bằng --other-files option. Để tìm hiểu thêm, hãy xem bài viết Đăng nhập tuỳ chỉnh và nhập văn bản bằng thử nghiệm Robo.

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

Thử nghiệm Robo không thể bỏ qua 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, chẳng hạn như hoàn tất CAPTCHA.

Tự động đăng nhập

Tính năng tự động đăng nhập bằng Tài khoản Google không được hỗ trợ trong thử nghiệm Robo cho iOS+ (Thử nghiệm).

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 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 thử nghiệm Robo để thực hiện các ứng dụng dùng khung giao diện người dùng khác, bao gồm cả các ứng dụng dùng công cụ phát triển trò chơi Unity, thì thử nghiệm có thể thoát mà không khám phá ngoài màn hình đầu tiên.