Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa test xong một app thương mại điện tử trên chiếc điện thoại của mình — một Samsung Galaxy S24 màn hình 6.2 inch. Mọi thứ đẹp hoàn hảo: nút "Thanh toán" nằm gọn dưới cùng, hình sản phẩm sắc nét, chữ đọc rõ ràng. Bạn tự tin đóng ticket, ghi "Pass". Ba ngày sau, bộ phận chăm sóc khách hàng chuyển lên một loạt ảnh chụp màn hình từ người dùng: nút "Thanh toán" bị đẩy khuất khỏi màn hình trên chiếc Oppo A15 giá rẻ, chữ tràn ra ngoài khung trên iPhone SE nhỏ xíu, còn trên chiếc Samsung Z Fold khi mở ra thì cả layout vỡ tan, ảnh sản phẩm co lại thành một ô vuông bé tí giữa khoảng trắng mênh mông.
Đây chính là Screen Fragmentation (sự phân mảnh màn hình) — cơn ác mộng kinh điển nhất của Mobile QA. Khác với web trên desktop, nơi bạn chỉ cần lo vài kích thước cửa sổ trình duyệt, thế giới di động có hàng chục nghìn tổ hợp kích thước màn hình, mật độ điểm ảnh (density), tỉ lệ khung hình (aspect ratio), và giờ đây thêm cả màn hình gập. Một bug không xuất hiện trên thiết bị của bạn không có nghĩa là nó không tồn tại — nó chỉ đang chờ một người dùng có thiết bị khác gặp phải.
Bài học này tập trung riêng vào Cross-Device Testing ở khía cạnh kích thước và mật độ màn hình: làm sao chọn tập thiết bị đại diện, hiểu các đơn vị đo (dp, sp, pt, ppi), và test hiệu quả trên phone nhỏ, tablet lớn, lẫn foldable. Đây là kỹ năng giúp bạn bắt bug layout trước khi người dùng bắt nó cho bạn.
Khái niệm cốt lõi
Vì sao "màn hình" không chỉ là một con số inch
Khi nói "màn hình 6 inch", con số đó chỉ mô tả đường chéo vật lý — hoàn toàn không đủ để QA làm việc. Ba yếu tố thực sự quyết định app hiển thị thế nào:
- Độ phân giải (resolution): số pixel vật lý, ví dụ 1080×2340. Đây là số pixel thật của phần cứng.
- Mật độ điểm ảnh (density / DPI): số pixel trên mỗi inch. Cùng một tấm ảnh 100px, trên màn hình mật độ cao sẽ trông nhỏ và sắc hơn, trên màn hình mật độ thấp sẽ to và mờ hơn.
- Tỉ lệ khung hình (aspect ratio): 16:9, 18:9, 20:9, hay gần vuông như foldable khi mở. Tỉ lệ này quyết định layout co giãn theo chiều dọc/ngang ra sao.
Đơn vị độc lập với mật độ: dp, sp, pt
Để lập trình viên không phải viết layout riêng cho từng màn hình, cả hai nền tảng đều dùng đơn vị "ảo" độc lập với pixel vật lý:
- Android — dp (density-independent pixel): 1 dp = 1 px trên màn hình mật độ chuẩn 160 DPI (gọi là mdpi). Công thức:
px = dp × (dpi / 160). Ví dụ trên màn hình xhdpi (320 DPI), 1 dp = 2 px. Nhờ đó một nút khai báo 48dp sẽ có kích thước vật lý tương đương trên mọi máy. - Android — sp (scale-independent pixel): giống dp nhưng dành cho cỡ chữ, và còn nhân thêm hệ số cỡ chữ mà người dùng chỉnh trong Cài đặt. Đây là chỗ QA hay bỏ sót: một layout đẹp ở cỡ chữ mặc định có thể vỡ toác khi người dùng để cỡ chữ "Rất lớn".
- iOS — pt (point): tương tự khái niệm dp. iPhone dùng hệ số @1x, @2x, @3x. Ví dụ iPhone 15 Pro là màn hình @3x, nghĩa là 1 pt = 3 px.
Các "bucket" mật độ Android bạn nên nhớ
Android nhóm các máy vào các nhóm mật độ (density bucket): ldpi (~120), mdpi (160, chuẩn), hdpi (240), xhdpi (320), xxhdpi (480), xxxhdpi (640). Đa số máy tại Việt Nam hiện nằm ở xhdpi đến xxhdpi. Bug hình ảnh mờ/vỡ thường lộ ra khi so sánh một máy mật độ thấp (máy giá rẻ) với một máy mật độ rất cao (flagship).
Ba nhóm form factor cần phủ
- Phone: từ khoảng 4.7 inch (iPhone SE) đến gần 7 inch (các phablet Android). Đây là 90% lưu lượng, nhưng khoảng biến thiên kích thước lớn.
- Tablet: 8 inch đến 12–13 inch (iPad Pro). Vấn đề chính là layout bị "kéo giãn" — nội dung thiết kế cho điện thoại trông loãng, nút bấm quá to, hoặc lãng phí không gian ngang.
- Foldable: đây là mảnh ghép mới và khó nhất. Samsung Z Fold khi gập là màn hình hẹp ~6.2 inch, khi mở ra thành ~7.6 inch gần vuông (tỉ lệ ~1:1). Z Flip lại gập ngang, có màn hình phụ nhỏ bên ngoài. Điểm chết người: sự kiện fold/unfold xảy ra ngay lúc app đang chạy, buộc app phải xử lý cấu hình thay đổi (configuration change) mà không mất dữ liệu.
Tình huống thực tế
Tình huống 1 — Nút thanh toán "biến mất" trên máy giá rẻ (sàn TMĐT Việt Nam)
Một sàn thương mại điện tử lớn ở Việt Nam (tạm gọi là ShopViet) chạy chương trình sale 12/12. Đội QA test trên tập thiết bị "chuẩn công ty" gồm iPhone 14, Samsung S23 và Xiaomi 13 — toàn máy đời cao, màn hình lớn. Layout trang giỏ hàng dùng một khối tổng tiền chiếm chiều cao cố định, và nút "Đặt hàng" đặt bên dưới.
Đêm sale, tỉ lệ chuyển đổi (conversion) tụt bất thường ở nhóm người dùng Android giá rẻ. Điều tra ra: trên các máy màn hình nhỏ và thấp như Samsung Galaxy A03 (màn ~6.5 inch nhưng độ phân giải thấp, cộng thanh điều hướng hệ thống chiếm chỗ), nút "Đặt hàng" bị đẩy xuống dưới vùng nhìn thấy (below the fold), người dùng phải cuộn mới thấy — nhưng vùng danh sách lại "bắt" cử chỉ cuộn nên nhiều người tưởng không đặt được.
Bài học: đừng chỉ test trên flagship. Ở Việt Nam, một tỉ lệ rất lớn người dùng thật đang dùng máy tầm trung và giá rẻ (Samsung dòng A, Oppo A-series, Xiaomi Redmi). Luôn có ít nhất một "máy sàn" (nhỏ, độ phân giải thấp, RAM thấp) trong tập test — và với luồng quan trọng như thanh toán, phải kiểm tra element quan trọng có nằm trong vùng nhìn thấy ban đầu không.
Tình huống 2 — App ngân hàng "mất trắng" form khi mở Galaxy Z Fold
Một ngân hàng số tại Đông Nam Á tung app mới. Một khách hàng dùng Samsung Z Fold đang điền form chuyển khoản: nhập xong số tiền, ghi chú, rồi mở máy ra để nhìn cho rõ khi nhập số tài khoản dài. Ngay khoảnh khắc mở gập, app tự khởi động lại Activity (vì đây là configuration change) và toàn bộ dữ liệu đã nhập biến mất. Khách hàng phải nhập lại từ đầu — trải nghiệm tệ với một app tài chính.
QA ban đầu bỏ sót vì họ chỉ test Z Fold ở trạng thái đã mở sẵn, không test hành động gập/mở giữa chừng. Sau sự cố, đội bổ sung kịch bản: bắt đầu thao tác ở màn gập → mở ra giữa chừng → kiểm tra state được giữ nguyên; và ngược lại. Họ cũng thêm test cho trạng thái "chuyển tiếp" khi màn hình gần vuông (tỉ lệ ~1:1) khiến layout hai cột của họ bị đè lên nhau.
Bài học: với foldable, bug nguy hiểm nhất không phải ở layout tĩnh mà ở quá trình chuyển đổi trạng thái (fold ↔ unfold) diễn ra trong lúc dùng. Luôn test giữ nguyên dữ liệu và tính liên tục màn hình (Continuity) qua thao tác gập/mở.
Tình huống 3 — App đọc tin tức trông "loãng" và vỡ ảnh trên iPad
Một startup nội dung ra app đọc báo, thiết kế đẹp trên iPhone. Khi có người dùng cài trên iPad, app chỉ đơn thuần phóng to layout điện thoại: một cột chữ chạy dài hết chiều ngang 11 inch khiến mắt mỏi, ảnh thumbnail thiết kế cho @2x bị kéo lên màn iPad Pro độ phân giải cao thành mờ nhòe, và khoảng trắng hai bên mênh mông trông rất nghiệp dư.
Đội QA phát hiện thêm: khi xoay iPad ngang (landscape), header cố định chiều cao che mất nội dung đầu trang. Họ đề xuất dev dùng layout thích ứng (adaptive layout) cho tablet — chia hai cột, giới hạn độ rộng dòng chữ — và cung cấp asset @3x/vector cho ảnh.
Bài học: tablet không phải là "điện thoại phóng to". Kích thước lớn cần layout riêng, và độ phân giải cao đòi hỏi asset chất lượng cao hơn. QA cần chủ động soi cả tính thẩm mỹ (dòng chữ quá dài, khoảng trắng thừa), không chỉ soi "có vỡ hay không".
Hướng dẫn từng bước
Dưới đây là quy trình thực dụng để làm Cross-Device Testing về kích thước và mật độ mà không cần sở hữu hàng trăm máy.
Bước 1 — Xây ma trận thiết bị dựa trên dữ liệu người dùng thật. Đừng chọn máy theo cảm tính. Lấy số liệu từ analytics (Firebase, App Store Connect) hoặc dữ liệu thị trường về máy phổ biến ở phân khúc người dùng của bạn. Tại Việt Nam, ma trận tối thiểu nên gồm: một iPhone nhỏ (SE / iPhone 13 mini), một iPhone lớn (Pro Max), một Android giá rẻ độ phân giải thấp (Samsung A-series / Redmi), một Android flagship mật độ cao, một tablet (iPad), và nếu app quan trọng thì thêm một foldable.
Bước 2 — Phủ theo "biên", không phủ theo số lượng. Bạn không cần 50 máy; bạn cần các điểm cực trị (boundary): màn nhỏ nhất, màn lớn nhất, mật độ thấp nhất, mật độ cao nhất, tỉ lệ khung hình dài nhất và vuông nhất. Bug layout hầu như luôn lộ ra ở biên.
Bước 3 — Test nhanh bằng simulator/emulator để bắt lỗi layout rõ ràng. Dùng iOS Simulator và Android Emulator với các cấu hình màn hình khác nhau để duyệt sơ bộ toàn bộ ma trận. (Lưu ý: simulator không thay thế được real device cho vấn đề mật độ vật lý và chạm — nội dung này thuộc bài riêng — nhưng rất tốt để bắt lỗi layout tràn/khuất.)
Bước 4 — Kiểm tra từng màn hình theo checklist hình học: nội dung có bị cắt (clipping) không; có bị tràn ra ngoài khung (overflow) không; có element chồng lên nhau (overlap) không; nút quan trọng có nằm trong vùng nhìn thấy ban đầu không; ảnh có sắc nét ở mật độ cao không.
Bước 5 — Test biến đổi động, không chỉ trạng thái tĩnh. Xoay ngang/dọc (rotation), gập/mở foldable, và đặc biệt là chỉnh cỡ chữ hệ thống lên mức lớn nhất rồi kiểm tra lại toàn bộ màn hình quan trọng. Đây là nhóm bug bị bỏ sót nhiều nhất.
Bước 6 — Đối chiếu với thiết kế và ghi nhận bằng ảnh. Chụp lại cùng một màn hình trên các thiết bị biên, đặt cạnh nhau để lộ khác biệt. Đây cũng là bằng chứng thuyết phục nhất khi báo bug cho dev.
Bước 7 — Bổ sung real device cho các thiết bị rủi ro cao. Với foldable và máy giá rẻ đặc thù thị trường, hãy thuê qua device farm (dịch vụ cho thuê máy thật từ xa) hoặc mượn máy thật để xác nhận — vì đây là nơi simulator hay đánh lừa bạn nhất.
Lỗi thường gặp & mẹo
- Chỉ test trên máy của chính mình. Đây là cái bẫy số một. Máy bạn thường là flagship đời mới — hoàn toàn không đại diện cho người dùng phổ thông Việt Nam. Mẹo: luôn giữ ít nhất một "máy sàn" giá rẻ trong tay để thử những gì quan trọng.
- Quên test cỡ chữ lớn (accessibility font scaling). Rất nhiều người lớn tuổi để cỡ chữ to. Layout dùng chiều cao cố định sẽ vỡ. Mẹo: đưa "cỡ chữ hệ thống lớn nhất" thành một bước bắt buộc cho mọi màn hình có nhiều chữ.
- Nhầm lẫn resolution với density. Hai máy cùng độ phân giải 1080×2340 nhưng khác kích thước vật lý sẽ có mật độ khác nhau, khiến mọi thứ trông to/nhỏ khác nhau. Đừng giả định "cùng số pixel là hiển thị giống nhau".
- Bỏ qua vùng an toàn (safe area) và notch/camera đục lỗ. Nội dung có thể bị tai thỏ, camera đục lỗ, hoặc thanh cử chỉ dưới đáy che mất. Mẹo: luôn có ít nhất một máy có notch và một máy có nút home vật lý (hoặc thanh gesture) trong ma trận.
- Test foldable chỉ ở một trạng thái. Như tình huống ngân hàng: bug nằm ở lúc chuyển trạng thái. Mẹo: kịch bản foldable phải luôn gồm thao tác gập/mở giữa chừng và kiểm tra giữ nguyên dữ liệu.
- Coi tablet là điện thoại phóng to. Mẹo: với tablet, soi thêm tính thẩm mỹ — dòng chữ quá dài, khoảng trắng thừa, nút to bất thường — chứ không chỉ soi lỗi vỡ.
- Quên xoay màn hình (rotation). Nếu app cho phép landscape, mỗi lần xoay là một configuration change tiềm ẩn mất dữ liệu — hãy test như một sự kiện động.
Bài tập thực hành
- Dựng ma trận thiết bị cho app của bạn. Chọn một app di động bất kỳ bạn đang test (hoặc một app phổ biến ở Việt Nam như một ví điện tử). Lập bảng 6 thiết bị theo nguyên tắc "phủ biên": nhỏ nhất, lớn nhất, mật độ thấp, mật độ cao, một tablet, một foldable. Với mỗi máy, ghi rõ: kích thước inch, độ phân giải, density bucket / hệ số @x, và lý do bạn chọn nó.
- Săn bug tràn/khuất bằng emulator. Mở iOS Simulator hoặc Android Emulator, tạo hai cấu hình: một màn nhỏ (ví dụ iPhone SE / màn hình ~5 inch mật độ thấp) và một màn lớn. Chạy một luồng có form (đăng nhập hoặc thanh toán) và chụp màn hình cả hai. Chỉ ra ít nhất một khác biệt về clipping, overflow, hoặc vị trí nút.
- Bài test cỡ chữ. Vào Cài đặt hệ thống, đẩy cỡ chữ lên mức lớn nhất, rồi mở lại một màn hình nhiều chữ. Ghi nhận mọi chỗ chữ bị cắt, tràn, hoặc chồng lên nút. Viết một bug report ngắn cho một lỗi bạn tìm được.
- Kịch bản foldable (giả lập được). Dùng Android Emulator có preset "Resizable" hoặc foldable. Bắt đầu điền một form ở trạng thái gập, chuyển sang trạng thái mở giữa chừng, và kiểm tra dữ liệu đã nhập còn được giữ không. Ghi lại kết quả PASS/FAIL kèm mô tả.
Tóm tắt
Cross-Device Testing về kích thước và mật độ là kỹ năng bắt bug layout trước khi người dùng gặp phải. Điều cốt lõi cần nhớ:
- "Màn hình" gồm ba yếu tố: độ phân giải, mật độ (density/DPI), và tỉ lệ khung hình — không chỉ là số inch.
- Hiểu đơn vị độc lập mật độ: dp/sp (Android), pt và hệ số @1x/@2x/@3x (iOS). Ảnh mờ thường do thiếu asset mật độ cao; layout vỡ khi cỡ chữ lớn thường do bỏ qua sp.
- Ba nhóm form factor cần phủ: phone (nhỏ đến phablet), tablet (cần layout riêng, không phóng to), và foldable (nguy hiểm nhất ở lúc chuyển trạng thái gập/mở).
- Chọn thiết bị theo dữ liệu người dùng thật và phủ theo biên, không theo số lượng. Ở Việt Nam, đừng bao giờ thiếu một máy Android giá rẻ độ phân giải thấp.
- Đừng chỉ test trạng thái tĩnh: xoay màn hình, gập/mở, và tăng cỡ chữ là ba biến đổi động hay bị bỏ sót nhất và gây ra nhiều bug nghiêm trọng nhất.