Khắc phục sự cố & Câu hỏi thường gặp

Tại sao thử nghiệm của tôi mất 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 bài kiểm tra có thể bắt đầu nhanh hơn. Khi thiết bị có dung lượng thấp, quá trình kiểm tra có thể mất nhiều thời gian hơn để chạy. Nếu số lần kiểm tra được thực hiện lớn hơn nhiều so với dung lượng của thiết bị đã chọn thì việc kiểm tra 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 cấp độ dung lượng 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 tính khả dụng của thiết bị và tốc độ kiểm tra.
• 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 xem có cơ sở hạ tầng được báo cáo cho Test Lab hay không, hãy xem bảng thông tin 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 dung lượng thiết bị dành cho Android và iOS .

Tại sao tôi nhận được kết quả xét nghiệm không thuyết phục?

Kết quả kiểm tra không có kết luận thường xảy ra do các lần chạy thử bị hủy hoặc do lỗi cơ sở hạ tầng.

Lỗi cơ sở hạ tầng xảy ra do các sự cố nội bộ của Test Lab, như lỗi mạng hoặc các hành vi không mong muốn của thiết bị. Test Lab dừng 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 thuyết phục; tuy nhiên, bạn có thể vô hiệu hóa những lần thử lại này bằng cách sử dụng failedFast .

Để 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ố ngừng hoạt động đã biết trong trang tổng quan trạng thái Firebase .

2. Hãy thử lại bài kiểm tra trong Test Lab để xác minh rằng nó có thể tái tạo được.

3. 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 trên Firebase Slack.

Tại sao sharding lại khiến thử nghiệm của tôi chạy lâu hơn?

Phân đoạn có thể khiến các thử nghiệm 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ó sẵn để 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 thiết bị khác, hãy xemDung lượng thiết bị .

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

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

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

Tại sao phải mất một thời gian dài để bài kiểm tra của tôi kết thúc?

Sau khi quá trình thực hiện thử nghiệm kết thúc, các tạo phẩm thử nghiệm sẽ được tải xuống từ thiết bị, được 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 hiện vật.

Hạn ngạch miễn phí cho Test Lab là bao nhiêu? Tôi nên làm gì nếu hết?

Phòng thí nghiệm kiểm tra Firebase cung cấp hạn ngạch miễn phí để thử nghiệm trên thiết bị và sử dụng API đám mây. Lưu ý rằng hạn ngạch thử nghiệm sử dụng gói giá Firebase tiêu chuẩn, trong khi hạn ngạch API đám mây thì không.

• Hạn ngạch kiểm tra

  Hạn ngạch kiểm tra được xác định bởi số lượng thiết bị được sử dụng để chạy thử nghiệm. Gói Firebase Spark có hạn mức thử nghiệm cố định mà người dùng không mất phí. Đối với gói Blaze, hạn ngạch của bạn có thể tăng 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 thử nghiệm của mình, 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 sử dụng gói Spark. Nếu bạn đã sử dụng gói Blaze, bạn có thể yêu cầu tăng hạn ngạch. Để biết thêm thông tin, hãy xem Hạn ngạch kiểm tra .

  Bạn có thể theo dõi việc sử dụng hạn ngạch thử nghiệm của mình trong Google Cloud Console .

• Hạn ngạch API thử nghiệm đám mây

  API kiểm tra đám mây đi kèm với hai giới hạn hạn ngạch: yêu cầu mỗi ngày cho mỗi dự án và yêu cầu mỗi 100 giây cho mỗi dự án. Bạn có thể theo dõi việc sử dụng của mình trong Google Cloud Console .

• Hạn ngạch API kết quả của Công cụ đám mây

  API kết quả của Công cụ đám mây đi kèm với hai giới hạn hạn ngạch: 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 việc sử dụng của mình trong Google Cloud Console .

  Tham khảo hạn ngạch Cloud API dành cho Test Lab để biết thêm thông tin về giới hạn API. Nếu bạn đã đạt đến hạn ngạch API:

  • Gửi yêu cầu về hạn ngạch cao hơn bằng cách chỉnh sửa hạn ngạch của bạn trực tiếp trong Google Cloud Console (lưu ý rằng hầu hết các giới hạn được đặt ở mức tối đa theo mặc định) hoặc

  • Yêu cầu hạn ngạch API cao hơn bằng cách điền vào biểu mẫu yêu cầu trong Google Cloud Console 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 liệu lưu lượng truy cập vào phần phụ trợ của tôi có đến từ Test Lab hay không?

Từ chương trình phụ trợ của mình, 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 được lưu trữ trên Firebase hay không bằng cách kiểm tra địa chỉ IP nguồn so 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 tạo phẩm thử nghiệm khác giữa bộ nhớ trong của Test Lab và nhóm kết quả của người dùng.

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

Để phát hiện hành vi không ổn định trong các thử nghiệm của bạn, chúng tôi khuyên bạn nên sử dụng tùy chọn--num-flaky-test-attempts. Số lần chạy lại làm giảm tốc độ được tính phí hoặc tính vào hạn ngạch hàng ngày của bạn giống như các lần thực hiện kiểm tra thông thường.

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

• Toàn bộ quá trình thực hiện kiểm thử sẽ chạy lại khi phát hiện thấy lỗi. Không có hỗ trợ cho việc thử lại chỉ những trường hợp thử nghiệm thất bại.
• Các lần chạy thử lại Delake đượ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.

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ể đưa ra cam kết hỗ trợ các nền tảng phát triển ứng dụng và thử nghiệm này.

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

Thông tin chi tiết về thiết bị có sẵn thông qua API và có thể được truy cập từ ứng dụng khách gcloud bằng lệnh mô tả :

gcloud firebase test ios models describe MODEL

Tôi có thể sử dụng sharding với thử nghiệm iOS không?

Sharding vốn không được hỗ trợ trong Test Lab dành cho iOS. Tuy nhiên, bạn có thể sử dụng ứng dụng khách Flank để phân chia các trường hợp kiểm thử iOS.

Điều này hoạt động bằng cách đặt khóa và giá trị OnlyTestIdentifiers trong tệp .xctestrun . Xem trang man về xcodebuild.xctestrun để biết thêm chi tiết.

Captcha đăng nhập

Kiểm tra robot không thể bỏ qua 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 xác thực để đăng nhập, chẳng hạn như hoàn thành CAPTCHA.

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

Thử nghiệm Robo hoạt động tốt 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 thử nghiệm Robo để thực hiện các ứng dụng sử dụ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ì thử nghiệm có thể thoát mà không cần khám phá ngoài màn hình đầu tiên.