Kiểm duyệt ngày càng nghiêm ngặt, làm thế nào để tiếp tục thực hiện kiểm thử xám?

Tuần trước, tôi đã thấy một lời phàn nàn trong một cộng đồng công nghệ kiểm thử: “Bị từ chối kiểm duyệt ba lần, kiểm thử xám bị kéo dài đến hai tuần, sếp hối thúc phát hành mỗi ngày.” Câu nói này phản ánh tình trạng phổ biến của các đội kiểm thử hiện nay.

Với việc các cửa hàng ứng dụng chính trong nước đang tăng cường chi tiết hóa quy trình kiểm tra tuân thủ thuật toán, thời gian cho việc mở rộng kiểm thử xám đang bị thu hẹp đáng kể. Quá khứ với “mở rộng trong 48 giờ” đã trở thành lịch sử, và hiện nay “ít nhất 7 ngày” gần như là tiêu chuẩn ngành. Thách thức hơn nữa, lý do từ chối kiểm duyệt đã mở rộng từ những vấn đề chức năng đơn giản đến những chi tiết như “văn bản thông báo quyền động”, và việc từ chối trung bình làm mất 3 ngày trở thành điều thường xuyên.

Trong bối cảnh này, mâu thuẫn cốt lõi mà các đội kiểm thử phải đối mặt là: sự mất cân đối giữa tài nguyên thiết bị hạn chế và nhu cầu kiểm thử ngày càng tăng.

Điểm nghẽn kiểm thử xám: Kiểm duyệt nghiêm ngặt, ít thiết bị thật, và hàng đợi dài

1. Chi phí thời gian do tiêu chuẩn kiểm duyệt chi tiết hóa

Các tiêu chí kiểm duyệt của cửa hàng ứng dụng đã mở rộng từ chức năng cơ bản sang tuân thủ quyền riêng tư, đăng ký thuật toán, tính hợp lý trong việc sử dụng quyền, v.v. Một sự từ chối nhỏ - như yêu cầu bổ sung “Video xác nhận quyền riêng tư của người dùng” hoặc sửa đổi văn bản giải thích quyền ở đâu đó - có nghĩa là đội kiểm thử cần phải đi qua lại quá trình kiểm thử xám. Điều này trực tiếp dẫn đến chu kỳ phát hành kéo dài từ 5-7 ngày lên 10-14 ngày.

2. Mâu thuẫn giữa tài nguyên thiết bị và độ phủ kiểm thử

Để giảm tỷ lệ Crash trực tuyến, đội kiểm thử thường cần phải kiểm tra trên Top 200 mẫu máy. Tuy nhiên, hầu hết các công ty vừa và nhỏ chỉ có khoảng 60-80 thiết bị thật, và việc chờ đợi trở thành điều bình thường. Thêm vào đó, khi các nhân viên kiểm thử đang chờ đợi để kiểm tra khả năng tương thích, các nhà phát triển đã tích hợp phiên bản mới, khiến đội kiểm thử luôn phải chạy theo phiên bản.

3. Vòng lặp không hiệu quả trong việc tái tạo lỗi

Khi gặp phải sự cố khó tái tạo liên quan đến thư viện So, quy trình xử lý truyền thống là: lấy log → cài đặt lại hệ điều hành → cài đặt lại → tái tạo. Vòng lặp này thường mất 30 phút hoặc lâu hơn, và sự cố thực sự có thể cần nhiều lần thử nghiệm để bắt được.

Xu hướng ngành: Kiểm thử song song trên đám mây đang trở thành điểm đột phá

Đối mặt với những thách thức trên, nhận thức chung trong ngành là: chỉ dựa vào việc tăng số lượng thiết bị thật không còn phù hợp với tốc độ kiểm duyệt của cửa hàng, giải pháp song song trên đám mây mới là lựa chọn khả thi.

Hiện nay, trên thị trường đã xuất hiện nhiều giải pháp điện thoại đám mây, có thể cung cấp khả năng kết nối ADB over IP, hỗ trợ điều phối đồng thời hàng chục hoặc thậm chí hàng trăm thiết bị đám mây. Giá trị cốt lõi của các giải pháp này nằm ở:

• Nhận thiết bị trong vài giây: Không cần chờ đợi phân bổ thiết bị vật lý, về lý thuyết có thể mở rộng số lượng thiết bị vô hạn
• Trực tuyến 7×24 giờ: Điện thoại đám mây không tắt nguồn, không khóa màn hình, có thể treo Monkey test vào ban đêm
• Khả năng khôi phục snapshot: Khôi phục nhanh chóng về trạng thái ban đầu trước khi kiểm thử, tăng đáng kể hiệu suất tái tạo lỗi

Ví dụ, Hive Cloud Box cung cấp dịch vụ điện thoại đám mây hỗ trợ kết nối ADB gốc, có thể kết nối trực tiếp với thiết bị đám mây thông qua adb connect từ máy cục bộ, độ trễ ổn định dưới 30ms. Quan trọng hơn, nó hỗ trợ chức năng sao chép một lần – sau khi điều chỉnh một “máy mẹ”, có thể sao chép hàng loạt 100 điện thoại đám mây có cấu hình hoàn toàn giống nhau, điều này đặc biệt hữu ích cho các đội cần kiểm tra khả năng tương thích lớn.

So sánh hiệu suất: Dữ liệu nói lên điều gì

Hãy xem xét một ví dụ thực tế: Một sản phẩm mạng xã hội hàng đầu đã thêm 6 quyền động trong bản cập nhật 3.7.0, và cửa hàng yêu cầu bổ sung “Video xác nhận quyền riêng tư của người dùng”.

Chỉ số	Cách truyền thống	Giải pháp điện thoại đám mây
Chi phí thiết bị	100 thiết bị thật khoảng 300.000 NDT	Thuê 7 ngày khoảng 700 NDT
Chu kỳ kiểm tra khả năng tương thích	3 ngày	7 giờ
Chu kỳ phát hành tổng	10 ngày làm việc	8 ngày làm việc
Tỷ lệ thông qua mẫu máy	-	98,7%

Trong ví dụ này, đội sử dụng 100 điện thoại đám mây để thực hiện song song Monkey test, 5 triệu sự kiện được hoàn thành vào ban đêm, và báo cáo khả năng tương thích được lấy vào sáng hôm sau. Nhờ khả năng khôi phục snapshot, 3 trường hợp sập GPU đã được tái tạo và xác định vị trí cùng ngày, và sau khi đội phát triển sửa chữa, họ đã vượt qua vòng kiểm duyệt thứ hai vào ngày hôm sau.

Thực hiện kỹ thuật: Ví dụ về pipeline Jenkins

Đối với các đội đã có khả năng CI/CD, giải pháp điện thoại đám mây có thể được tích hợp liền mạch vào quy trình hiện tại. Dưới đây là một ý tưởng pipeline đơn giản:

stage('Cài đặt song song') {
    parallel (0..99).collect { i ->
        sh "adb connect phone${i}.nestbox.top:5555"
        sh "adb -s phone${i}.nestbox.top:5555 install -r app.apk"
    }
}

stage('Kiểm thử Monkey') {
    parallel (0..99).collect { i ->
        sh "adb -s phone${i}.nestbox.top:5555 shell monkey -p com.xxx.app --throttle 200 -v 50000"
    }
}

Sau khi xây dựng, 100 điện thoại đám mây sẽ cài đặt và thực hiện kiểm thử Monkey đồng thời, 7 giờ để hoàn thành việc kiểm tra khả năng tương thích mà trước đây mất 3 ngày. Log Crash/ANR tự động gửi về, các trường hợp thất bại được đánh dấu nổi bật.

Khôi phục snapshot: Từ 30 phút xuống 30 giây

Trong các trường hợp tái tạo lỗi, giá trị của giải pháp điện thoại đám mây trở nên rõ ràng hơn. Trong quy trình truyền thống, nhân viên kiểm thử cần phải cài đặt lại hệ điều hành, cài đặt lại, và tái tạo vấn đề, cả quá trình có thể mất hơn 30 phút. Trong môi trường điện thoại đám mây, một snapshot tự động được tạo trước khi kiểm thử, và khi bắt được lỗi, có thể khôi phục toàn bộ máy trong 30 giây thông qua bảng điều khiển.

Điều này có nghĩa là các nhà phát triển có thể debug từ xa: adb shell gdbserver attach tiến trình, nâng cao hiệu suất xác định vị trí đáng kể.

Kết luận

Khi quy trình kiểm duyệt ngày càng giống như “mở hộp bí mật,” điều duy nhất mà đội kiểm thử có thể kiểm soát là hiệu suất thiết bị. Giải pháp điện thoại đám mây, với kết nối ADB trong vài giây, điều khiển nhóm bằng một cú nhấp và khôi phục snapshot, giúp đưa lại nhịp độ kiểm thử xám vào tay mình.

Tuy nhiên, giải pháp điện thoại đám mây không phải là hoàn hảo - đối với các trường hợp cần kiểm tra môi trường mạng thực tế, tín hiệu cơ sở, vẫn cần sử dụng thiết bị thật. Nhưng đối với các trường hợp kiểm tra khả năng tương thích, kiểm thử Monkey, kiểm thử hồi quy, nó đã là lựa chọn có tỷ lệ giá/công suất rất cao.

Để biết thêm thông tin, hãy truy cập trang web chính thức của Hive Cloud Box: https://nestbox.top

Vậy câu hỏi đặt ra là: Đội của bạn hiện đang giải quyết vấn đề hiệu suất kiểm thử xám như thế nào? Bạn đã thử nghiệm giải pháp điện thoại đám mây chưa? Hãy chia sẻ kinh nghiệm và trải nghiệm của bạn trong phần bình luận.