Câu hỏi thường gặp và khắc phục sự cố trong Phòng thử nghiệm
Trang này cung cấp thông tin 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 Phòng thử nghiệm Firebase. 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 Slack của Firebase hoặc liên hệ với nhóm hỗ trợ của Firebase.
Khắc phục sự cố
Tại sao thử nghiệm của tôi mất nhiều thời gian để chạy như vậy?
Khi bạn chọn một thiết bị có mức dung lượng cao trong danh mục của Phòng thử nghiệm, 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ì việc kiểm thử
có thể mất nhiều thời gian hơn để hoàn tất.
Quá trình kiểm thử chạy trên mọi mức dung lượng của thiết bị có thể mất nhiều thời gian hơn do những yếu tố sau:
Lưu lượng truy cập, ảnh hưởng đến khả năng sử dụng của thiết bị và tốc độ kiểm thử.
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 Phòng thử nghiệm 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 của thiết bị trong Phòng thử nghiệm, 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 xác định thường xảy ra do các lượt 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 đề trong Phòng thử nghiệm nội bộ gây ra, chẳng hạn như lỗi mạng hoặc hành vi ngoài dự kiến của thiết bị. Phòng thử nghiệm 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:
Thử kiểm tra lại trong Phòng thử nghiệm để xác minh rằng nó có thể tái tạo.
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 Phòng thử nghiệm trong kênh#test-lab trên Slack của Firebase.
Tại sao tính năng phân đoạn khiến kiểm thử của tôi chạy lâu hơn?
Việc phân đoạn có thể khiến 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ó sẵn để sử dụng trong Phòng thử nghiệm. Để 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 thiết bị khác, hãy xem bài viết
Dung lượng của thiết bị.
Tại sao mất nhiều thời gian để
thử nghiệm 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ì quá trình này hoàn tất sau chưa đầy vài giây, nhưng có thể còn chịu ảnh hưởng của 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ượt thực thi kiểm thử sẽ được lên lịch và ở 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 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).
Tại sao mất nhiều thời gian để
thử nghiệm kết thúc?
Sau khi phiên 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à hiển thị trực tiếp vào bảng điều khiển của 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, 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ì 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 Phòng thử nghiệm. Bộ chứa kết quả mặc định được thiết lập để 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ử được 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, có thể bạn sẽ thấy lỗi kiểm thử cho biết một phần kết quả 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à Phòng thử nghiệm không thể phân tích cú pháp logcat cho đ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 gây ra 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 kiểm thử dài hơn thời gian chờ bạn đã chỉ định hoặc lâu 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 thử nghiệm đề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 sẽ 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.
Trường hợp kiểm thử không hoàn tất được do thoát sớm hoặc bị lỗi.
Trường hợp kiểm thử có thể thoát sớm do lỗi chưa nắm bắt được hoặc lỗi câu nhận định. Các trường hợp kiểm thử có thể bị mắc 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 để điều tra xem thử nghiệm
đã dừng ở đâu.
Một 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 đ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ử của bạn.
Các nhật ký quá nhiều đã được ghi vào logcat, việc này gây quá tải cho bộ đệm
hoặc gây ra sự cố cho quy trình logcat.
Giảm số lượt ghi vào 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
Hạn mức miễn phí của Phòng thử nghiệm là bao nhiêu? Tôi nên làm gì nếu dùng hết?
Phòng thử nghiệm Firebase cung cấp các hạn mức miễn phí cho việc kiểm thử trên các thiết bị và việc sử dụng API Google Cloud. 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 API Cloud 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 thử nghiệm cố định mà người dùng không phải trả phí. Đối với gói linh hoạt, 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 linh hoạt nếu bạn đang dùng gói Spark.
Nếu đang dùng Gói linh hoạt, bạn có thể yêu cầu tăng hạn mức.
Để biết thêm thông tin, vui lòng xem bài viết Hạn mức kiểm thử.
Cloud Testing API có hai giới hạn 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ủa Cloud Tool
Cloud Tool Results API có 2 giới hạn hạn mức: truy vấn mỗi ngày cho mỗi dự án và 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.
Gửi yêu cầu tăng hạn mức bằng cách chỉnh sửa hạn mức của bạn 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 thành tối đa theo mặc định), hoặc
Yêu cầu hạn mức API cao hơn 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ợ 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ó bắt nguồn từ Phòng thử nghiệm 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 lưu trữ trên Firebase 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.
Phòng thử nghiệm có hoạt động với VPC-SC không?
Phòng thử nghiệm không hoạt động với VPC-SC. Tính năng này chặn hoạt động 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 Phòng thử nghiệm 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 Phòng thử nghiệm?
Để phát hiện hành vi không ổn định trong các kiểm thử, bạn nên sử dụng tuỳ chọn
--num-flaky-test-trials
. Các lần chạy lại của 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ượt chạy kiểm thử thông thường.
Hãy ghi nhớ những điều sau:
Toàn bộ quá trình chạy kiểm thử sẽ chạy lại khi phát hiện thấy lỗi. Không hỗ trợ tính năng 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 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.
Phòng thử nghiệm có hỗ trợ thiết bị đeo không?
Có! Phòng thử nghiệm 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ị trong Phòng thử nghiệm, hãy xem nội dung Kiểm thử trên các thiết bị có sẵn.
Phòng thử nghiệm 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ị trong Phòng thử nghiệm, hãy xem nội dung Kiểm thử trên các thiết bị có sẵn.
Làm thế nào để phát hiện một thử nghiệm đang chạy trong Phòng thử nghiệm?
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ể biết được liệu kiểm thử có đang chạy 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.
Phòng thử nghiệm 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 đ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ột kiểm thử đo lường bằng Espresso rồi chạy kiểm thử trong Phòng thử nghiệm.
Phòng thử nghiệm có hỗ trợ kiểm thử các ứng dụng bị làm rối mã nguồn, chẳng hạn như ProGuard hoặc R8) không?
Phòng thử nghiệm không hỗ trợ rõ ràng cho tính năng 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 đã làm rối mã nguồ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?
Thiết bị có thể gập lại có nhiều trạng thái gập, chẳng hạn như FLAT (mở hoàn toàn) hoặc HALF_OPENED (mở hoàn toàn và đóng hoàn toàn).
Mặt khác, các tư thế bao gồm hướng cụ thể của thiết bị và trạng thái gập lại được. 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ế sách (là trạng thái HALF_OPENED theo hướng dọc).
Tôi có thể dùng thử Phòng thử nghiệm 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 SDK Firebase để sử dụng Phòng thử nghiệm. Nếu chưa có ứng dụng, bạn có thể tải 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ữ GitHub 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, còn 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 bài viết Kiểm thử được đo lường.
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. Trên một số loại thiết bị, các phép kiểm thử này có thể khó khăn 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 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 việc kiểm thử ảnh chụp màn hình trở nên hiệu quả hơn khi có các thay đổi dự kiến.
Phòng thử nghiệm có cập nhật các thiết bị ảo không?
Có! Các thiết bị ảo được cập nhật khi bạn thực hiện các thay đổi sau:
Cập nhật hình ảnh hiện có
Ngừng sử dụng các cấp độ API trước đó
Đã 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 độ 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 độ sử dụng:
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 cách sử dụ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 đă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 quy trình kiểm thử Robo để thực hiện các ứng dụng dùng các khung giao diện người dùng khác, bao gồm cả ứng dụng 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 cần khám phá ngoài màn hình đầu tiên.