Kiểm thử phần mềm: Chiến lược phủ thiết bị khi kiểm thử ứng dụng di động dựa trên rủi ro

Một chiến lược kiểm thử phần mềm thực tế không cố gắng bao quát mọi chiếc điện thoại trên thị trường. Nó tập trung nguồn lực vào nơi lỗi có khả năng xảy ra cao nhất, khó phát hiện nhất hoặc gây thiệt hại lớn nhất cho người dùng. Một chiến lược phủ thiết bị khi kiểm thử ứng dụng di động dựa trên rủi ro bắt đầu từ rủi ro sản phẩm và làm việc ngược lại để xác định các thiết bị, hệ điều hành, mạng và điều kiện môi trường cần được chú ý.

Mục tiêu không phải là số lượng thiết bị tối đa. Mục tiêu là sự bao phủ có ý nghĩa: đủ đa dạng để phơi bày các chế độ lỗi thực tế mà không lãng phí thời gian cho các tổ hợp ít mang lại thông tin.

Bắt đầu từ rủi ro sản phẩm, không phải sự phổ biến của thiết bị

Trước khi chọn danh sách thiết bị, hãy xác định những gì ứng dụng phải thực hiện một cách đáng tin cậy. Các luồng thanh toán, xác thực, hoạt động ngoại tuyến, thu thập phương tiện, thông báo và khả năng truy cập là những lĩnh vực rủi ro cao thường gặp. Hậu quả của lỗi quan trọng không kém xác suất xảy ra. Một vấn đề về hình thức trên điện thoại cũ có thể chấp nhận được; nhưng lỗi thanh toán trên thiết bị phổ thông thì không.

Xây dựng một mô hình rủi ro đơn giản xoay quanh ba câu hỏi:

• Khả năng xảy ra: Người dùng sẽ gặp luồng này bao nhiêu lần?
• Tác động: Nếu nó gặp sự cố, điều gì sẽ xảy ra về mặt tài chính, vận hành hoặc pháp lý?
• Khả năng phát hiện: Các kiểm tra tự động có bắt được vấn đề không, hay nó cần sự quan sát của con người trên thiết bị thực?

Các luồng có khả năng xảy ra cao và tác động lớn xứng đáng được bao phủ rộng nhất. Các trường hợp biên có tác động thấp có thể được lấy mẫu, tự động hóa hoặc tạm hoãn. Điều này ngăn ma trận thiết bị trở thành một danh sách mua sắm tùy tiện.

Phân khúc thiết bị theo mức độ tiếp xúc của người dùng và doanh nghiệp

Lựa chọn thiết bị trở nên rõ ràng hơn khi bạn phân khúc đối tượng. Các phân khúc hữu ích bao gồm thị phần, hồ sơ khách hàng, đóng góp doanh thu, nhu cầu truy cập và gánh nặng hỗ trợ. Một ứng dụng doanh nghiệp chủ yếu được sử dụng trên các điện thoại công ty mới có hồ sơ khác với ứng dụng tiêu dùng có lượng lớn thiết bị Android cũ.

Một bộ bao phủ cân bằng thường bao gồm:

• Thiết bị iOS hiện tại trên phiên bản hỗ trợ mới nhất
• Thế hệ iOS trước vẫn phổ biến trong dữ liệu phân tích
• Thiết bị Android hiện tại từ nhà cung cấp lớn
• Thiết bị Android tầm trung hoặc giá rẻ với bộ nhớ hoặc dung lượng lưu trữ hạn chế
• Phiên bản Android cũ vẫn còn trong cơ sở người dùng
• Thiết bị có hình dạng màn hình, mật độ像素 hoặc tùy chỉnh của nhà cung cấp bất thường

Những danh mục này có gi�� trị hơn việc thu thập nhiều điện thoại hoạt động gần như giống hệt nhau. Hãy bao gồm ít nhất một thiết bị có tài nguyên hạn chế, vì áp lực bộ nhớ, giới hạn nhiệt và giới hạn quy trình nền thường tiết lộ các vấn đề mà phần cứng hàng đầu che giấu.

Xem hệ điều hành như một chiều kích rủi ro

Việc bao phủ hệ điều hành nên phản ánh chính sách hỗ trợ và hành vi phát hành. Hãy kiểm tra phiên bản mới nhất trước khi triển khai công khai khi có thể, vì các thay đổi về quyền, giới hạn thực thi nền và chính sách bảo mật có thể làm hỏng các luồng hiện có. Cũng nên giữ lại một phiên bản cũ được hỗ trợ để bắt các vấn đề tương thích.

Theo dõi ba lớp hệ điều hành riêng biệt:

• Nền tảng cơ bản: hệ điều hành tối thiểu được hỗ trợ cho ứng dụng của bạn
• Tỷ lệ áp dụng hiện tại: các phiên bản mà hầu hết người dùng thực sự chạy
• Phơi nhiễm tương lai: các phiên bản beta hoặc vừa phát hành có thể ảnh hưởng đến bản cập nhật tiếp theo

Đừng giả định rằng chỉ riêng phiên bản hệ điều hành mới dự đoán được hành vi. Giao diện của nhà cung cấp, chính sách doanh nghiệp và nhà sản xuất thiết bị có thể thay đổi quyền, quản lý pin, hành vi camera và mạng. Khi dữ liệu phân tích của bạn cho thấy một nhóm nhà cung cấp đáng kể, hãy đưa nhà cung cấp đó vào bộ kiểm thử.

Một số điều kiện có thể được mô phỏng đáng tin cậy trong tự động hóa. Những điều kiện khác, như hành vi camera, nhắc nhở sinh tr học, giao tiếp đẩy hoặc tác động nhiệt, cần được kiểm chứng vật lý. Sự phân biệt này nên được nêu rõ trong kế hoạch kiểm thử.

Thêm các điều kiện thực tế một cách có chủ đích

Các thiết bị trong phòng thí nghiệm với Wi-Fi lý tưởng hiếm khi đại diện cho việc sử dụng hàng ngày. Các điều kiện thực tế thường tạo ra các lỗi mà người dùng báo cáo: tín hiệu yếu, chuyển mạng, dung lượng thấp, pin thấp, hạn chế chạy nền và quyền bị gián đoạn. Những điều kiện này nên được chọn dựa trên rủi ro, không phải thêm vào ngẫu nhiên.

Xem xét một ma trận điều kiện cho các hành trình quan trọng:

• Wi-Fi nhanh, Wi-Fi yếu và dữ liệu di động có độ trễ cao
• Mất mạng trong quá trình tải lên, thanh toán hoặc đồng bộ
• Dung lượng thấp khi tải phương tiện hoặc cập nhật nội dung
• Chế độ chạy nền khi có thông báo hoặc tác vụ vị trí đang chờ xử lý
• Trình đọc màn hình, chữ lớn, giảm chuyển động và cài đặt độ tương phản thay thế
• Biến thể ngôn ngữ, múi giờ, bàn phím và bố cục từ phải sang trái

Một số điều kiện có thể được mô phỏng đáng tin cậy trong tự động hóa. Những điều kiện khác, như hành vi camera, nhắc nhở sinh tr học, giao tiếp đẩy hoặc tác động nhiệt, cần được kiểm chứng vật lý. Sự phân biệt này nên được nêu rõ trong kế hoạch kiểm thử.

Sử dụng ma trận bao phủ để hiển thị các đánh đổi

Một ma trận bao phủ liên kết rủi ro sản phẩm với các lựa chọn về thiết bị, hệ điều hành và điều kiện. Mỗi hàng có thể mô tả một kịch bản người dùng, rủi ro mà nó giải quyết, môi trường cần thiết và phương thức xác minh. Điều này giúp các thiếu sót trở nên rõ ràng. Nếu luồng thanh toán không có kiểm thử trên thiết bị Android giá rẻ với kết nối không ổn định, khoảng trống này dễ được thảo luận hơn một lời phàn nàn trừu tượng về việc bao phủ không đủ.

Ưu tiên ma trận bằng phương pháp chấm điểm đơn giản. Gán ưu tiên cao hơn cho các kịch bản kết hợp tác động doanh thu, tần suất sử dụng cao, khả năng tự động hóa yếu và độ nhạy nền tảng đã biết. Xem lại điểm số sau các sự cố và phát hành để chiến lược tiến hóa dựa trên bằng chứng.

Kết hợp tự động hóa, giả lập và thiết bị vật lý

Tự động hóa tuyệt vời cho các kiểm tra có thể lặp lại trên nhiều cấu hình, nhưng nó không thay thế việc quan sát. Trình giả lập hữu ích cho độ rộng hệ điều hành và các lần chạy hồi quy nhanh, nhưng chúng có thể không tái tạo chất lượng camera, hành vi cảm biến, giới hạn bộ nhớ, điều kiện radio hoặc xử lý dành riêng cho nhà cung cấp.

Sử dụng cách tiếp cận nhiều lớp:

• Tự động hóa các kiểm tra chức năng ổn định trên một ma trận ảo rộng lớn
• Chạy các buổi khám phá trên các thiết bị vật lý đại diện
• Dành riêng kiểm thử mạng thực và thực địa cho các luồng có nguy cơ kết nối cao
• Thực hiện các kiểm tra tập trung trên các phiên bản beta hệ điều hành mới và các bản cập nhật lớn của nhà cung cấp

Cấu trúc này giúp phản hồi nhanh chóng trong khi vẫn duy trì độ trung thực cần thiết cho các luồng rủi ro cao.

Đo lường xem việc bao phủ có đang hoạt động không

Việc bao phủ nên được đánh giá dựa trên kết quả, không phải dựa trên số lượng thiết bị trong phòng thí nghiệm. Theo dõi các lỗi lọt ra theo loại thiết bị, phiên bản hệ điều hành, điều kiện mạng và lĩnh vực tính năng. So sánh sự c��� sản xuất với kế hoạch bao phủ kiểm thử. Nếu lỗi liên tục xuất hiện bên ngoài ma trận, hãy cập nhật tiêu chí lựa chọn thay vì chỉ thêm nhiều điện thoại hơn.

Xem lại chiến lược theo định kỳ thường xuyên và sau các bản phát hành nền tảng lớn. Dân số thiết bị thay đổi, chính sách hỗ trợ thay đổi và rủi ro sản phẩm thay đổi với các tính năng mới. Một cuộc xem xét kỷ luật giúp chiến lược bao phủ kiểm thử ứng dụng di động luôn phù hợp với mức độ tiếp xúc thực tế của người dùng.

Kết luận: chọn bao phủ để giải thích rủi ro

Chiến lược thiết bị mạnh mẽ nhất là có thể giải thích được. Mọi thiết bị, phiên bản hệ điều hành và điều kiện được đưa vào đều phải gắn liền với một nhóm người dùng, một chế độ lỗi hoặc một hậu quả kinh doanh. Bằng cách bắt đầu từ rủi ro, phân khúc đối tượng, kiểm tra các điều kiện thực tế và đo lường các lỗi lọt ra, các nhóm có thể xây dựng bao phủ vừa nhỏ hơn vừa hiệu quả hơn một ma trận thiết bị bừa bãi.