Mở đầu — vì sao bài này quan trọng
Nếu bạn mới bước vào nghề Mobile QA, sẽ có một buổi sáng nào đó bạn đứng trước câu hỏi tưởng chừng đơn giản nhưng lại quyết định chất lượng của cả sản phẩm: "Tôi nên chạy test này trên simulator/emulator hay trên máy thật?". Đây không phải câu hỏi kỹ thuật vụn vặt. Nó liên quan trực tiếp đến chi phí (một tủ máy thật 20 chiếc có thể ngốn hàng trăm triệu đồng), tốc độ (mỗi vòng CI chạy nhanh hay chậm), và quan trọng nhất là niềm tin: liệu kết quả test xanh trên simulator có phản ánh đúng trải nghiệm của người dùng cầm chiếc điện thoại thật trong tay hay không.
Rất nhiều đội QA ở Việt Nam mắc một trong hai cực đoan. Cực đoan thứ nhất: tin tưởng tuyệt đối vào simulator vì nó nhanh, miễn phí, chạy được trên máy dev — rồi để lọt bug camera, bug pin, bug sóng yếu ra production. Cực đoan thứ hai: chỉ tin máy thật, dựng cả một "device lab" đắt đỏ, test thủ công chậm chạp, không thể chạy song song hàng trăm test trong CI. Bài học hôm nay giúp bạn thoát khỏi cả hai cái bẫy đó bằng cách hiểu rõ bản chất từng công cụ, biết chúng dối bạn ở chỗ nào, và xây dựng một chiến lược phân tầng hợp lý cho từng loại kiểm thử.
Khái niệm cốt lõi
Trước hết cần phân biệt ba thuật ngữ mà nhiều người dùng lẫn lộn: simulator, emulator và real device (máy thật). Chúng khác nhau về bản chất kỹ thuật, và sự khác biệt này chính là lý do vì sao chúng đáng tin hoặc không đáng tin ở những khía cạnh khác nhau.
iOS Simulator — "mô phỏng" chứ không "giả lập"
iOS Simulator là công cụ trong bộ Xcode, chỉ chạy được trên máy Mac. Điểm mấu chốt: nó mô phỏng (simulate) chứ không giả lập (emulate) phần cứng iPhone. Nghĩa là app của bạn được biên dịch cho kiến trúc của con chip trên máy Mac (x86 với Mac Intel đời cũ, hoặc ARM với Mac Apple Silicon M1/M2/M3), rồi chạy trực tiếp bằng CPU của máy Mac. App không hề chạy trên một môi trường iPhone thực thụ.
Hệ quả là gì? Simulator dùng chung CPU, RAM và ổ đĩa của máy Mac — vốn mạnh hơn iPhone rất nhiều. Vì thế app luôn "cảm giác" mượt hơn thực tế. Simulator không có phần cứng thật của điện thoại: không camera thật, không cảm biến gia tốc/con quay hồi chuyển thật, không GPU di động thật, không module sóng di động, không pin. Những gì bạn thấy là do macOS "diễn" lại.
Android Emulator — giả lập cả một máy ảo
Android Emulator (đi kèm Android Studio, dựa trên QEMU) là emulator đúng nghĩa: nó tạo ra một máy ảo mô phỏng cả phần cứng của thiết bị Android, chạy một bản Android OS đầy đủ bên trong. Nó nặng hơn iOS Simulator vì phải giả lập tầng phần cứng, nhưng bù lại "giống máy thật" hơn ở một số khía cạnh — bạn thực sự có một Android OS đang chạy, có thể cài file APK như máy thật, mô phỏng được GPS, cuộc gọi đến, tin nhắn, thậm chí điều kiện mạng.
Tuy vậy emulator vẫn không phải máy thật. Nó thường chạy image x86/x86_64 để tận dụng CPU máy tính cho nhanh, trong khi hầu hết điện thoại Android thật dùng chip ARM. Điều này thỉnh thoảng lộ ra bug ở các thư viện native (NDK) chỉ build cho ARM.
Real Device — sự thật trần trụi
Máy thật là chiếc điện thoại người dùng cầm trên tay: đúng con chip, đúng dung lượng RAM khiêm tốn, đúng GPU di động, có pin thật cạn dần, có camera thật, cảm biến thật, sóng thật với độ trễ thật, và — quan trọng ở thị trường Việt Nam — có lớp tùy biến ROM của hãng như Samsung One UI, Xiaomi MIUI/HyperOS, OPPO ColorOS. Chính những lớp ROM tùy biến này là nơi sinh ra vô số bug mà không simulator/emulator nào tái hiện được.
Bảng đối chiếu tư duy
Cách dễ nhớ nhất: simulator/emulator trả lời câu hỏi "logic app có đúng không?", còn máy thật trả lời câu hỏi "trải nghiệm thật có ổn không?". Những thứ thuộc về logic — luồng màn hình, validate form, điều hướng, hiển thị dữ liệu — kiểm trên môi trường ảo là đủ và nhanh. Những thứ thuộc về vật lý và trải nghiệm — hiệu năng, pin, nhiệt độ, camera, cảm biến, sóng, độ mượt animation, tương tác ROM hãng — bắt buộc phải có máy thật.
Tình huống thực tế
Tình huống 1 — App gọi xe "mượt trên simulator, giật trên đường phố Sài Gòn"
Một startup gọi xe giả định tên GoRide ở TP.HCM phát triển tính năng bản đồ theo dõi tài xế real-time. Trên iOS Simulator của máy MacBook Pro M2, bản đồ cuộn cực mượt, marker di chuyển trơn tru, đội dev tự tin ship. Nhưng khi tester cầm chiếc iPhone SE 2020 (chip A13, RAM chỉ 3GB) chạy thử ngoài đường, bản đồ giật khựng mỗi khi có 15–20 marker tài xế cùng cập nhật vị trí, FPS tụt xuống còn khoảng 20.
Nguyên nhân: MacBook M2 có GPU và RAM mạnh gấp nhiều lần iPhone SE, nên gánh nặng vẽ marker và tính toán đường đi bị "giấu đi" trên simulator. Bài học rút ra: mọi bài test liên quan đến hiệu năng đồ họa, số lượng phần tử lớn, hay cuộn danh sách dài không bao giờ được nghiệm thu chỉ trên simulator. Đội GoRide sau đó lập quy định: mọi màn hình bản đồ và danh sách phải pass trên ít nhất một máy thật đời thấp (iPhone SE, và một Android tầm trung như Samsung A-series) trước khi release.
Tình huống 2 — Ngân hàng số và cú lừa của camera "quét CCCD"
Một ứng dụng ngân hàng số giả định (đặt tên TienBank) triển khai eKYC — người dùng dùng camera quét căn cước công dân gắn chip và chụp khuôn mặt để đối chiếu. Trong suốt sprint, đội QA test luồng này trên iOS Simulator. Simulator không có camera thật, nên khi app mở camera, nó hiển thị một khung hình mẫu giả lập (hình động vuông xoay xoay của Apple). Test case "mở màn hình camera" luôn pass, đội yên tâm.
Ra production, hàng loạt người dùng ở các dòng máy Android khác nhau báo lỗi: camera bị xoay 90 độ, ảnh CCCD bị mờ do không lấy nét được, trên vài máy Xiaomi thì app crash ngay khi xin quyền camera. Không một lỗi nào trong số này có thể xuất hiện trên simulator vì đơn giản là không có camera thật để mà lỗi. Bài học: bất cứ tính năng nào chạm đến phần cứng — camera, micro, NFC (đọc chip CCCD), cảm biến vân tay, GPS — đều phải test trên máy thật đa dạng hãng, đặc biệt ở Việt Nam nơi thị phần Samsung, Xiaomi, OPPO rất lớn và mỗi hãng xử lý quyền và camera API hơi khác nhau.
Tình huống 3 — Sàn TMĐT tối ưu chi phí bằng chiến lược phân tầng
Một sàn thương mại điện tử khu vực Đông Nam Á (giả định, kiểu Shopee/Lazada thu nhỏ) có 4.000 test case tự động. Ban đầu họ muốn chạy tất cả trên một device farm máy thật thuê ngoài, nhưng chi phí lên tới hàng nghìn USD mỗi tháng và mỗi lần chạy CI mất gần 2 tiếng. Đội QA lead quyết định phân tầng: khoảng 3.500 test case thuần logic (thêm giỏ hàng, áp mã giảm giá, luồng thanh toán mock, validate địa chỉ) chạy trên Android Emulator và iOS Simulator song song trong CI — chỉ mất khoảng 25 phút và gần như miễn phí. Chỉ khoảng 500 test case "nhạy cảm phần cứng và trải nghiệm" (thanh toán thật qua ví, hiệu năng cuộn feed sản phẩm, thông báo đẩy, camera quét mã QR) mới chạy trên máy thật.
Kết quả: chi phí device farm giảm hơn 80%, thời gian CI trung bình giảm mạnh, mà độ phủ bug quan trọng gần như không đổi. Bài học: máy thật không phải để chạy mọi thứ, mà để chạy đúng thứ cần máy thật. Đây chính là nghệ thuật của Mobile QA giỏi.
Hướng dẫn từng bước
Dưới đây là quy trình ra quyết định "test cái này ở đâu" bạn có thể áp dụng ngay.
Bước 1 — Phân loại test case theo bản chất. Với mỗi test case, tự hỏi: nó kiểm tra logic phần mềm hay trải nghiệm/phần cứng? Nếu chỉ kiểm điều hướng, hiển thị, validate, tính toán — đó là ứng viên cho môi trường ảo. Nếu chạm camera, GPS, pin, hiệu năng, sóng, cảm biến, ROM hãng — đánh dấu "cần máy thật".
Bước 2 — Chạy vòng phát triển hằng ngày trên simulator/emulator. Trong lúc code và debug, dev và QA nên dùng môi trường ảo vì nó khởi động nhanh, reset trạng thái dễ (xóa app, đổi độ phân giải, đổi phiên bản OS chỉ vài cú click), và không tốn thiết bị vật lý. Đây là nơi bạn chạy phần lớn smoke test và regression logic.
Bước 3 — Thiết lập một "device matrix" máy thật tối thiểu. Bạn không cần 50 máy. Hãy chọn theo dữ liệu thị trường của chính sản phẩm: 1 iPhone đời thấp còn hỗ trợ (ví dụ iPhone SE hoặc iPhone 11), 1 iPhone đời mới, và 2–3 Android phủ Samsung + Xiaomi/OPPO ở phân khúc phổ thông (nơi phần lớn người Việt dùng). Ưu tiên máy tầm trung và đời thấp — vì bug hiệu năng luôn lộ ra ở máy yếu trước.
Bước 4 — Đưa các test "cần máy thật" lên device farm hoặc lab. Với những test đã đánh dấu ở Bước 1, chạy chúng trên máy thật — hoặc lab nội bộ, hoặc dịch vụ đám mây (chủ đề device farm như BrowserStack, Sauce Labs sẽ học kỹ ở bài sau). Trong CI, cấu hình để nhánh test này chạy trước mỗi lần release, không nhất thiết mỗi commit.
Bước 5 — Luôn nghiệm thu cuối cùng (release sign-off) trên máy thật. Dù test tự động xanh đến đâu, trước khi bấm nút phát hành, hãy có một buổi kiểm thử thủ công ngắn trên máy thật cho các luồng quan trọng nhất: đăng nhập, thanh toán, tính năng cốt lõi. Đây là "hàng rào cuối cùng" bắt những bug mà không môi trường ảo nào chạm tới.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm "test pass trên simulator" là "app hoạt động tốt". Simulator che giấu vấn đề hiệu năng vì dùng phần cứng máy tính mạnh. Mẹo: đừng bao giờ đánh giá FPS, thời gian tải, hay độ mượt animation trên simulator — những con số đó vô nghĩa.
Lỗi 2 — Quên rằng simulator/emulator không có nhiều thứ. Danh sách "không có" cần thuộc lòng: iOS Simulator không có camera, không có cuộc gọi thật, không mua hàng App Store thật, không có push notification qua APNs thật (một số trường hợp), không có Face ID/Touch ID phần cứng (chỉ giả lập bằng menu). Android Emulator khá hơn nhưng vẫn không có camera vật lý chuẩn, pin thật, hay các API độc quyền của hãng. Mẹo: khi một test đụng bất kỳ thứ nào trong danh sách này, tự động chuyển sang máy thật.
Lỗi 3 — Bỏ qua ROM tùy biến của hãng. Ở Việt Nam, Samsung One UI và Xiaomi HyperOS/MIUI có cách quản lý quyền, pin nền, thông báo và cử chỉ điều hướng rất riêng. Emulator dùng Android gốc (AOSP) nên không bao giờ tái hiện được. Mẹo: device matrix của bạn bắt buộc có ít nhất một máy Samsung và một máy Xiaomi/OPPO thật.
Lỗi 4 — Emulator kiến trúc x86 giấu bug thư viện ARM native. Nếu app dùng thư viện native (C/C++ qua NDK, một số SDK AI, xử lý ảnh), bug có thể chỉ xuất hiện trên chip ARM thật. Mẹo: nếu app có thành phần native, chạy ít nhất một vòng test trên emulator image ARM hoặc thẳng lên máy thật ARM.
Mẹo tối ưu chi phí: dùng snapshot của emulator để khôi phục trạng thái nhanh, chạy nhiều emulator song song trên một máy CI mạnh, và giữ máy thật cho phần "đắt giá" nhất. Song song hóa tốt trên môi trường ảo giúp bạn tiết kiệm cả tiền lẫn thời gian.
Bài tập thực hành
- Phân loại test case. Lấy 10 test case bất kỳ từ một app bạn đang biết (ví dụ app ngân hàng, app đặt đồ ăn). Với mỗi cái, ghi rõ: chạy được trên simulator/emulator hay bắt buộc máy thật, kèm một câu lý do. Mục tiêu là bạn phân biệt được "logic" và "phần cứng/trải nghiệm" một cách phản xạ.
- Tự tay chứng minh sự khác biệt. Nếu có máy Mac, mở một app đơn giản trên iOS Simulator và thử mở màn hình camera — quan sát nó hiển thị gì (khung giả lập). Sau đó chạy đúng app đó trên iPhone thật và so sánh. Ghi lại 3 điểm khác biệt bạn quan sát được.
- Thiết kế device matrix. Giả sử bạn là QA lead cho một app fintech nhắm người dùng Việt Nam với ngân sách chỉ mua được 5 máy thật. Hãy liệt kê 5 model cụ thể (tên máy, hãng, phân khúc, lý do chọn) và giải thích chiến lược phủ thị trường của bạn.
- Ước tính chi phí/thời gian. Giả sử bạn có 2.000 test case, trong đó 300 cần máy thật. Nếu chạy tất cả trên device farm mất 90 phút, còn chạy 1.700 test logic trên emulator song song mất 20 phút và 300 test còn lại trên máy thật mất 25 phút — hãy tính xem chiến lược phân tầng tiết kiệm bao nhiêu phần trăm thời gian.
Tóm tắt
Simulator (iOS), emulator (Android) và máy thật không phải để thay thế nhau mà để bổ trợ nhau. Simulator/emulator kiểm tra logic — nhanh, rẻ, song song hóa tốt, lý tưởng cho vòng phát triển hằng ngày và regression logic. Máy thật kiểm tra trải nghiệm và phần cứng — hiệu năng, camera, cảm biến, pin, sóng, và đặc biệt là ROM tùy biến của Samsung/Xiaomi/OPPO rất phổ biến ở Việt Nam.
Ba điều cần khắc cốt ghi tâm: (1) simulator dùng phần cứng máy tính mạnh nên luôn che giấu vấn đề hiệu năng — đừng tin nó về tốc độ và độ mượt; (2) mọi thứ chạm phần cứng đều bắt buộc test trên máy thật đa dạng hãng; (3) chiến lược phân tầng — logic chạy môi trường ảo, phần cứng/trải nghiệm chạy máy thật, nghiệm thu cuối cùng luôn trên máy thật — vừa tiết kiệm chi phí vừa giữ chất lượng. Một Mobile QA giỏi không phải người dùng nhiều máy thật nhất, mà là người biết chính xác nên dùng công cụ nào cho từng loại kiểm thử.