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 thông tin trợ giúp khắc phục sự cố và giải đáp các câu hỏi thường gặp về việc chạy thử nghiệm 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 thử nghiệm của tôi mất quá nhiều thời gian để chạ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 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 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 kiểm thử có thể mất nhiều thời gian hơn để hoàn tất.

Các kiểm thử chạy ở bất kỳ cấp độ nào về dung lượng thiết bị đề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 truy cập vào thiết bị và tốc độ kiểm thử.
• Thiết bị hoặc cơ sở hạ tầng gặp sự cố, 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 của 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 thể đưa ra kết luận?

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 đề nội bộ Test Lab 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ẽ tự động huỷ các lần chạy thử nghiệm 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 xác định; 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 để xem có sự cố ngừng dịch vụ nào đã biết trong trang tổng quan về trạng thái của Firebase hay không.

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

   Lưu ý: Test Lab không tính phí cho 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 lại khiến các kiểm thử của tôi chạy lâu hơn?

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 mà 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 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 một thiết bị khác, hãy xem phần Dung lượng thiết bị.

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

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

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

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ác cấu phần phần mềm.

Ứng dụng không trả về dữ liệu và không 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à được kết xuất trực tiếp vào bảng điều khiển Firebase. Nếu bạn đã thực hiện kiểm thử trong vòng 90 ngày qua, hãy kiểm tra để đảm bảo bạn đã chỉ định 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 không bật tính năng Cloud Audit Logging cho dự án hoặc tổ chức của mình.

Nếu quá trình thực thi diễn ra 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 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 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 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 bị thiếu?

Khi chạy các kiểm thử đo lường, bạn có thể thấy các 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 do AndroidJUnitRunner tạo.

Sau đây là những 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 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 kiểm thử đều có thể hoàn tất. Phân đoạn các 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ủa các kiểm thử và hoàn thành trong 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 hoàn tất được trường hợp kiểm thử do thoát quá sớm hoặc bị kẹt. 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 khẳng định. 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 không thể tiếp tục, chẳng hạn như nếu ứng dụng không hiển thị đúng khung hiển thị 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 xem thử nghiệm dừng ở đâu.
Trình chạy kiểm thử tuỳ chỉnh (bao gồm cả việc mở rộng AndroidJUnitRunner) gặp sự cố ngoài dự kiến hoặc ghi các dấu hiệu bắt đầu hoặc kết thúc kịch bản kiểm thử ngoài dự kiến vào logcat.	Kiểm tra mã trình chạy kiểm thử.
Đã ghi quá nhiều nhật ký vào logcat, khiến vùng đệm bị tràn hoặc quy trình logcat gặp sự cố.	Giảm số lượt ghi xuống 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

Test Lab có những hạn mức miễn phí nào? Tôi nên làm gì nếu hết giấy phép?

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 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 API thì không.

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

  Hạn mức kiểm thử được xác định bằng số lượng thiết bị dùng để chạy kiểm thử. Gói Spark của Firebase 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 theo thời gian. Nếu bạn đạt đến hạn mức kiểm thử, 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 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 hạn mức sử dụng kiểm thử trong bảng điều khiển Google Cloud.

• Hạn mức Cloud Testing API

  Cloud Testing API có 2 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 Cloud Tool Results API

  Cloud Tool Results API có 2 hạn mức: số lượng truy vấn mỗi ngày cho mỗi dự án và số lượng 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 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 theo mặc định, hầu hết các hạn mức đều được đặt ở mức tối đa), hoặc

  • Yêu cầu tăng hạn mức sử dụng 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 Nhóm 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 đế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ị kiểm thử 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. VPC-SC sẽ 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à các nhóm 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 kiểm thử, bạn nên sử dụng lựa chọn --num-flaky-test-attempts . Các lần chạy lại để loại bỏ lỗi 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 thấy lỗi. Không có tính năng hỗ trợ thử lại chỉ 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 đượ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.

Lưu ý: Lỗi cơ sở hạ tầng không phụ thuộc vào tính năng deflake và không kích hoạt các lần chạy lại deflake.

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 các kiểm thử 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ị hiện có.

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 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ị hiện có.

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

Nếu đang kiểm thử ứng dụng trong Firebase hoặc chạy các 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 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 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ộ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ã (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 ở các trạng thái và chế độ gập khác nhau 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 trạng thái mở hoàn toàn và đóng 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 gập. Ví dụ: tư thế trên mặt bàn là trạng thái HALF_OPENED ở hướng ngang hoặc tư thế trang sách là trạng thái HALF_OPENED ở hướng dọc.

Nếu đang chạy các 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.

Google Pixel Fold (mã nhận dạng kiểu máy 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ã nhận dạng mô hình 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},
]

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

Kiểm thử so sánh ảnh chụp màn hình là nơi các câu lệ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 một quy trình kiểm thử với hình ảnh tham chiếu thể hiện hành vi dự kiến. Những 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 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ị mô phỏng Arm sử dụng nhữ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 các kiểm thử ảnh chụp màn hình trở nên mạnh mẽ hơn khi có những thay đổi dự kiến.

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

Có! Các thiết bị ảo sẽ đượ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 về mức độ phù hợp?

Để bật báo cáo về 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 một đườ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, các ABI được hỗ trợ, v.v. ở đâu?

Thông tin chi tiết về thiết bị có trong API và có thể truy cập 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 bằng rô bô không thể bỏ qua những 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 để đăng nhập, ví dụ: hoàn tấ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 những ứng dụng sử dụng các phần tử giao diện người dùng trong 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ử bằng Robo để thực thi các ứng dụng sử dụng nhữ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ì quy trình kiểm thử có thể thoát mà không khám phá thêm ngoài màn hình đầu tiên.