Kiểm Tra Web Di Động: Hướng Dẫn Thực Tế Cho Các Nhóm Hiện Đại

Một chiến dịch có thể hoạt động hoàn hảo trên Chrome máy tính để bàn nhưng vẫn có thể thất bại vào thời điểm khách hàng cần nhất. Một lớp phủ thanh toán có thể từ chối mở trên Safari di động của Pháp qua kết nối 4G bị hạn chế, trong khi cùng một quy trình vượt qua mọi kiểm tra bố cục đáp ứng trong một phòng thí nghiệm máy tính để bàn. Sự thất bại không phải là điều bất thường. Môi trường thử nghiệm không giống như môi trường của người dùng.

Kiểm tra web di động cần tính đến toàn bộ con đường giữa một người và một trang: phần cứng thiết bị, động cơ trình duyệt, đầu vào cảm ứng, hành vi viewport, mạng di động, vị trí, cookie, DNS, định tuyến CDN và hiệu suất dưới áp lực. Lưu lượng truy cập di động chiếm 58,7% tổng lưu lượng truy cập web vào tháng 7 năm 2019, và đến năm 2022, các thiết bị di động đã tạo ra nhiều lưu lượng hơn máy tính để bàn trên 88% trong số 1.000 trang web hàng đầu và 89% trong số 10.000 trang web hàng đầu, theo HTTP Archive Web Almanac. Tuy nhiên, chỉ có 39% trang web cung cấp trải nghiệm Core Web Vitals tốt trên di động, và chỉ 23% trang web di động có độ tương phản màu sắc đầy đủ trong báo cáo đó.

Bài học thực tiễn rất đơn giản. QA máy tính để bàn và một lần kiểm tra nhanh trên trình giả lập bao quát những điều hữu ích, nhưng chúng không đại diện cho các điều kiện mà các chiến dịch xã hội, cửa hàng địa phương, quy trình xác minh quảng cáo, công việc thu thập dữ liệu và hành trình tài khoản gặp phải trong sản xuất.

Tại sao Kiểm Tra Web Di Động Xứng Đáng Có Chiến Lược Riêng

QA máy tính để bàn chỉ thấy một phần của web. Một người dùng điện thoại có thể có CPU bị hạn chế, GPU khác, điều hướng bằng cảm ứng, viewport có notch, chính sách lưu trữ cụ thể cho trình duyệt và mạng di động thay đổi định tuyến trước khi yêu cầu đến máy chủ của bạn.

Ví dụ thanh toán của Pháp phơi bày nhiều khoảng trống cùng một lúc. Một kiểm tra CSS đáp ứng có thể xác nhận rằng lớp phủ vừa với viewport, nhưng lại bỏ qua hành vi cookie cụ thể của Safari ngăn trạng thái thanh toán duy trì. Một trình duyệt máy tính để bàn có thể hoàn tất quy trình thanh toán trong khi một Android WebView, phiên bản trình duyệt của nó thay đổi giữa các thiết bị và nhà sản xuất, lại hiển thị một đường dẫn kịch bản khác. Một trình giả lập có thể bắt chước kích thước màn hình mà không tái tạo được mạng di động chỉ IPv6, sự không ổn định của radio, hoặc phần mềm trung gian phía nhà mạng.

Một lần kiểm tra bố cục không phải là hành trình của người dùng

Kiểm tra thiết kế đáp ứng trả lời một câu hỏi quan trọng: giao diện có thích ứng với viewport này không? Nó không trả lời liệu người dùng có thể hoàn thành nhiệm vụ hay không.

Kiểm tra các hành động mang lại giá trị kinh doanh:

• Mở lớp phủ: Xác nhận rằng một sự kiện chạm đến điều khiển dự định và lớp phủ xuất hiện trên ngữ cảnh xếp chồng đúng.
• Giữ trạng thái phiên: Xác minh cookie, lưu trữ cục bộ, trạng thái đồng ý và nội dung giỏ hàng qua các chuyển hướng và tải lại.
• Hoàn tất việc chuyển giao: Kiểm tra các bảng thanh toán, liên kết sâu ứng dụng, chuyển hướng danh tính và đường dẫn trở lại trên mỗi trình duyệt mục tiêu.
• Khôi phục sau gián đoạn: Đưa trình duyệt vào nền, xoay thiết bị, mất kết nối và tiếp tục hành trình.

Chức năng Ngăn chặn Theo dõi Thông minh của Safari có thể thay đổi hành vi cookie và lưu trữ. Sự phân mảnh Android WebView có thể phơi bày sự khác biệt về JavaScript và kết xuất mà một động cơ máy tính để bàn đơn lẻ sẽ không hiển thị. Đây không phải là lỗi về kiểu dáng, vì vậy chỉ so sánh ảnh chụp màn hình sẽ không phát hiện ra chúng.

Mạng di động là một phần của môi trường thử nghiệm

Mạng di động có thể ảnh hưởng đến việc giải quyết DNS, danh tiếng IP, tín hiệu định vị, định tuyến và lựa chọn CDN. NAT cấp nhà mạng cũng có nghĩa là các thuê bao không liên quan có thể chia sẻ một địa chỉ IPv4 công cộng, điều này làm cho việc chặn IP một cách quyết liệt trở nên rủi ro cho các dịch vụ cố gắng tách biệt tự động hóa nghi ngờ khỏi người dùng di động hợp pháp. RFC 6598 dự trữ không gian địa chỉ chia sẻ được sử dụng cho NAT cấp nhà mạng, trong khi phân tích proxy di động thực tiễn giải thích lý do tại sao các địa chỉ nhà mạng chia sẻ làm phức tạp quyết định chặn.

Quy tắc thực tiễn: Nếu một yêu cầu phụ thuộc vào vị trí, nhà mạng, sự đồng ý, giao hàng hoặc tính liên tục của tài khoản, hãy thêm điều kiện mạng vào trường hợp thử nghiệm. Đừng để nó là một giả định.

Phần còn lại của một chương trình kiểm tra web di động hợp lý do đó nên coi các điều kiện thực tế là đầu vào hàng đầu. Phạm vi thiết bị, phạm vi trình duyệt, mô phỏng mạng, hiệu suất thực địa và hành vi IP được kiểm soát thuộc về cùng một kế hoạch, không phải trong một danh sách kiểm tra tương thích vào phút cuối.

Các Khái Niệm Cơ Bản Mà Mỗi Người Kiểm Tra Di Động Nên Biết

Bắt đầu với từ vựng, vì mô hình tâm lý sai sẽ tạo ra bài kiểm tra sai. Một chiếc điện thoại không phải là một màn hình máy tính để bàn nhỏ. Nó có những hạn chế về kết xuất riêng, mô hình đầu vào, chính sách trình duyệt và danh tính mạng.

Viewport và mật độ pixel

Hãy nghĩ về viewport như kích thước của một bàn ăn và tỷ lệ pixel thiết bị như số lượng gạch vật lý phủ lên bàn đó. Pixel CSS mô tả bề mặt bố cục, trong khi một màn hình có độ phân giải cao sử dụng nhiều pixel vật lý để vẽ mỗi pixel CSS. Một hình ảnh một lần có thể trông mềm mại trên màn hình ba lần ngay cả khi kích thước CSS của nó là chính xác.

Kiểm tra thẻ meta viewport trước tiên. Nếu không có khai báo viewport thích hợp, các trình duyệt di động có thể bố trí trang chống lại một bức tranh ảo rộng hơn và sau đó thu nhỏ nó, tạo ra văn bản nhỏ, điểm gãy không chính xác hoặc thu phóng bằng cách kẹp không mong muốn. Sau đó, kiểm tra các hướng dọc và ngang, thay đổi chrome trình duyệt, các vùng an toàn và thanh địa chỉ động.

User agents không kể toàn bộ câu chuyện

Một chuỗi user agent xác định danh tính đã khai báo của trình duyệt, nhưng nó không chứng minh hành vi kết xuất hoặc API. Giả mạo một user agent Safari trên trình duyệt máy tính để bàn sẽ không tái tạo động cơ JavaScript, quy tắc lưu trữ, triển khai cảm ứng hoặc hành vi viewport của Safari trên iOS. Tương tự, Chrome trên Android có thể khác nhau giữa các phiên bản hệ điều hành và ngữ cảnh nhúng.

Sử dụng kiểm tra user agent chỉ như một đầu vào. Kết hợp chúng với các phiên trình duyệt thực tế, phát hiện tính năng và các bài kiểm tra mà hành trình của bạn phụ thuộc vào các API. Hướng dẫn kiểm tra tính tương thích trình duyệt rất hữu ích khi một quy trình cũng phụ thuộc vào địa lý, điều kiện nhà mạng, giao hàng quảng cáo hoặc nội dung khu vực.

Mục tiêu chạm và cử chỉ

Một cú nhấp chuột bằng chuột là chính xác. Một ngón tay bao phủ một khu vực, có thể bắt đầu di chuyển trước khi thả ra, và có thể kích hoạt một cử chỉ thay vì một cú nhấp đơn giản. Kiểm tra vùng chạm dự định, sự lan truyền sự kiện, khóa cuộn, hành vi vuốt, nhấn lâu, thu phóng bằng cách kẹp và sự xuất hiện của bàn phím.

Một biểu tượng được căn giữa về mặt thị giác vẫn có thể có một khu vực nhấn bị dịch chuyển bởi một phần tử cha đã biến đổi. Một carousel cuộn ngang có thể chặn một cú vuốt trang dọc. Một modal có thể ngăn cuộn nền trên một trình duyệt và cho phép nó trên trình duyệt khác. Xác minh đường dẫn sự kiện thực tế, không chỉ vị trí thị giác.

WebViews và chính sách lưu trữ

Một WebView nhúng là một bề mặt trình duyệt bên trong một ứng dụng, nhưng nó không tự động tương đương với trình duyệt độc lập của thiết bị. Android WebViews có thể theo các con đường cập nhật khác nhau giữa các nhà sản xuất, và ứng dụng chủ có thể thay đổi quyền, điều hướng, lưu trữ hoặc xử lý liên kết sâu.

Trên iOS, Chức năng Ngăn chặn Theo dõi Thông minh có thể hạn chế theo dõi giữa các trang và thay đổi cách cookie hỗ trợ xác thực hoặc phân bổ. Kiểm tra các chuyển hướng từ bên thứ nhất và bên thứ ba, biểu ngữ đồng ý, tính liên tục đăng nhập và URL trở lại trong ngữ cảnh trình duyệt hoặc WebView chính xác được sử dụng bởi sản phẩm. Một bài kiểm tra vượt qua trong một trình duyệt đầy đủ có thể vẫn thất bại bên trong một quy trình nhúng.

So sánh Các Phương Pháp Kiểm Tra Thủ Công và Tự Động

Không có một con đường thực thi nào cung cấp độ phủ di động đáng tin cậy. Kiểm tra thủ công phát hiện chất lượng tương tác và sự mơ hồ, tự động hóa cung cấp khả năng lặp lại, và cơ sở hạ tầng thiết bị thực cung cấp các điều kiện mà mô phỏng không thể tái tạo hoàn toàn.

Kiểm tra thực tế có vị trí của nó khi câu hỏi là chủ quan hoặc rất cụ thể. Một người kiểm tra có thể cảm nhận xem một cú vuốt có tự nhiên hay không, nhận thấy rằng việc hướng dẫn yêu cầu quá nhiều thông tin, xác định một cú nhảy hình ảnh trong quá trình nhập bàn phím, và điều tra một sự suy giảm một lần mà không cần mã hóa trước mọi trạng thái có thể có.

Tự động hóa tốt hơn cho hành vi đã biết. Một bộ trình duyệt di động có thể mở trang chủ, tìm kiếm, thêm một mục, gửi một biểu mẫu và xác nhận trạng thái kết quả trên một ma trận trình duyệt. Các khung như Appium và Playwright là những loại phù hợp cho việc bao phủ kịch bản, với sự lựa chọn phụ thuộc vào việc nhóm cần tự động hóa trình duyệt, kiểm soát WebView, hay tương tác hệ thống rộng hơn.

Nơi mỗi phương pháp kiếm được giá trị của nó

Phiên thực tế thủ công mạnh nhất cho cảm giác cử chỉ, thay đổi hướng, hành vi bàn phím, suy giảm hình ảnh, khám phá khả năng tiếp cận, và những gián đoạn bất thường. Chúng mất nhiều thời gian hơn để lặp lại và khó mở rộng trên mọi trình duyệt và địa phương.

Kiểm tra UI tự động mạnh nhất cho các kiểm tra khói, các đường đi hồi quy, các biểu mẫu dựa trên dữ liệu, và các xác nhận trình duyệt có thể lặp lại. Chúng có thể trở nên mong manh khi các bộ chọn phụ thuộc vào bố cục thay đổi, khi thời gian không được kiểm soát, hoặc khi các bài kiểm tra giả vờ rằng một trình giả lập là một điện thoại vật lý.

Phiên lai mang lại cho một nhóm nhỏ một sự cân bằng hợp lý. Chạy các luồng khói kịch bản trên mọi bản dựng, dành các thiết bị thực cho các ứng viên phát hành và các thay đổi có rủi ro cao, sau đó để một người kiểm tra khám phá cùng một con đường thủ công dưới các trình duyệt, mạng và sự kết hợp địa phương quan trọng nhất.

Các trình giả lập là một bộ lọc, không phải là quyền lực cuối cùng

Các trình giả lập và mô phỏng cục bộ nhanh, dễ tiếp cận và hữu ích trong quá trình phát triển. Chúng giúp phát hiện lỗi viewport, các bộ chọn bị hỏng, nhãn bị thiếu, lỗi điều hướng, và sự khác biệt rõ ràng giữa các trình duyệt trước khi một bản dựng đến phòng thí nghiệm thiết bị.

Chúng không tái tạo hoàn toàn hành vi radio, giới hạn pin, áp lực nhiệt, các quirk DNS bên nhà mạng, hoặc cảm giác vật lý của việc chạm. Sử dụng chúng sớm, sau đó chuyển các con đường quan trọng đến các thiết bị thực hoặc một đám mây thiết bị thực trước khi phát hành.

Một cách chia sprint thực tế là tự động hóa bao phủ khói ổn định trước, khám phá các hành trình có rủi ro cao nhất thủ công trên các thiết bị vật lý, và chỉ chạy toàn bộ ma trận thiết bị thực cho các ứng viên phát hành hoặc các thay đổi liên quan đến thanh toán, xác thực, định vị địa lý, quảng cáo, hoặc lưu trữ trình duyệt.

Hiệu suất và Core Web Vitals trên Di động

Kiểm tra hiệu suất di động nên bắt đầu với dữ liệu thực địa, không phải điểm số trên máy tính để bàn. Google Search Console nhóm các phép đo người dùng thực theo Largest Contentful Paint, Interaction to Next Paint, và Cumulative Layout Shift, cung cấp cho các nhóm cái nhìn về cách các trang hoạt động ngoài một phòng thí nghiệm được kiểm soát. Tài liệu Core Web Vitals định nghĩa LCP tốt là 2.5 giây hoặc ít hơn, cần cải thiện từ 2.5 đến 4 giây, và kém trên 4 giây. Đối với INP, 200 mili giây hoặc ít hơn là tốt, trong khi trên 500 mili giây là kém.

Bức tranh thực địa di động đã được xác minh là đáng lo ngại. HTTP Archive phát hiện trải nghiệm Core Web Vitals tốt chỉ trên 39% các trang web di động trong báo cáo năm 2022 của nó. Điều đó khiến dữ liệu thực địa di động trở thành một tín hiệu phát hành, không phải là một trang trí báo cáo.

Xây dựng một trường hợp phòng thí nghiệm có thể tái tạo

Sử dụng một hồ sơ di động nhất quán cho việc tái tạo cục bộ. Một mẫu hữu ích là Slow 4G với giảm tốc độ CPU 4x, sau đó kiểm tra LCP, thực thi kịch bản, và luồng chính. Việc giảm tốc độ theo kiểu Lighthouse và chạy trình duyệt có kiểm soát giúp xác định xem trang có đang chờ đợi việc cung cấp tài nguyên hay mất quá nhiều thời gian để thực thi JavaScript.

Một nghiên cứu về hiệu suất di động lịch sử đã đo thời gian tải trang trung vị ở mức 23.4 giây vào năm 2015 và 6.4 giây vào năm 2018, cho thấy việc tối ưu hóa và xác minh có thể thay đổi kết quả theo thời gian như thế nào. Cách tiếp cận có thể tái tạo, nhận thức thiết bị của nghiên cứu này có giá trị hơn so với việc coi trình duyệt máy tính để bàn như một proxy cho điện thoại. Để có một giải thích thực tế về việc đo độ trễ, xem cách đo độ trễ.

Bảng này cố ý tách biệt các ngưỡng thực địa khỏi các chỉ báo hỗ trợ. TTFB và Tổng Thời gian Chặn giúp chẩn đoán một vấn đề, nhưng chúng không thay thế các Core Web Vitals thực địa.

Đọc thác nước, sau đó xác nhận trên phần cứng

Một thác nước phơi bày thứ tự và thời gian của các yêu cầu. Tìm kiếm JavaScript chặn render trước nội dung chính, hình ảnh hero quá lớn đến sau khi bố cục bắt đầu, và phông chữ làm chậm văn bản có thể sử dụng. Trên phần cứng Android tầm trung, cùng một gói có thể tạo ra nhiều công việc luồng chính hơn so với trên bộ xử lý máy tính để bàn.

Chạy trang quan trọng trên một thiết bị vật lý và ghi lại các dấu hiệu API Hiệu suất xung quanh điều hướng, tương tác, và hoàn thành. Mẫu hành vi khung trong quá trình cuộn và hoạt ảnh, và ghi lại các thay đổi về pin hoặc nhiệt độ như các tín hiệu thứ cấp. Những quan sát này sẽ không thay thế dữ liệu thực địa, nhưng chúng có thể giải thích lý do tại sao điểm số phòng thí nghiệm xấu đi sau một thay đổi kịch bản dường như nhỏ.

Sử dụng một vòng lặp có kỷ luật:

1. Cơ sở: Ghi lại cùng một lộ trình, hồ sơ, loại thiết bị, và trạng thái kiểm tra.
2. Thay đổi một biến: Xóa một kịch bản, thay đổi kích thước một hình ảnh, thay đổi việc tải phông chữ, hoặc thay đổi bộ nhớ đệm.
3. Lặp lại nhất quán: Giữ hồ sơ mạng và CPU cố định.
4. So sánh trung vị: Sử dụng các lần chạy lặp lại và so sánh trung vị thay vì trung bình, vì các ngoại lệ thỉnh thoảng có thể làm sai lệch một mẫu nhỏ.
5. Xác nhận trong thực địa: Kiểm tra xem dữ liệu người dùng di động có di chuyển theo cùng một hướng không.

Kiểm tra phụ thuộc vào Địa lý, Mạng và IP với Proxy Di động

Một bài kiểm tra địa lý trên máy tính để bàn có thể chỉ thay đổi vị trí IP rõ ràng. Một hành trình di động cũng có thể phụ thuộc vào ASN nhà mạng, hành vi NAT chia sẻ, bộ giải DNS, CDN edge, đường đi IPv4 hoặc IPv6, và quốc gia hoặc nhà mạng được chọn. Kiểm tra những điều kiện đó cùng nhau khi câu hỏi kinh doanh liên quan đến địa phương hóa, kiểm soát truy cập, giao hàng, hoặc hành vi cụ thể của mạng.

Một ASN, hay Số Hệ Thống Tự Động, xác định nhà điều hành kiểm soát một khối IP. Một proxy di động thoát qua một kết nối di động, vì vậy đích đến có thể thấy một ASN nhà mạng di động thay vì một ASN đám mây hoặc lưu trữ. NAT cấp nhà mạng, hay CGNAT, đặt nhiều người đăng ký không liên quan phía sau các địa chỉ IPv4 công cộng chia sẻ. Một khối nhắm vào một phiên đáng ngờ có thể do đó ảnh hưởng đến người dùng điện thoại thực trên cùng một nhà mạng. Giải thích CGNAT và tổng quan về fingerprinting di động giải thích vấn đề địa chỉ chia sẻ này theo cách thực tế.

Sử dụng một quy trình làm việc mạng có kiểm soát

Lặp lại cùng một thiết lập trước mỗi lần chạy:

1. Chọn vị trí mục tiêu: Xác định quốc gia và, khi cần, ASN của nhà mạng.
2. Chọn điểm cuối di động: Sử dụng điểm cuối di động 4G hoặc 5G phù hợp với ngữ cảnh nhà mạng mong muốn. Evoproxy là một lựa chọn cho việc kiểm tra mạng di động tại Pháp khi một luồng yêu cầu một đường dẫn nhà mạng Pháp.
3. Đặt điều kiện trình duyệt: Áp dụng tác nhân người dùng, viewport, ngôn ngữ, múi giờ và cấu hình cảm ứng mong muốn.
4. Ngăn chặn rò rỉ: Vô hiệu hóa các đường dẫn WebRTC có thể tiết lộ địa chỉ cục bộ khác, sau đó xác minh rằng mọi yêu cầu đều sử dụng proxy mong muốn.
5. Xác thực đầu ra: Ghi lại IP hiển thị, ASN, quốc gia và bộ giải DNS trước khi bắt đầu kịch bản.
6. Chọn hành vi phiên: Giữ phiên cố định cho các quy trình đăng nhập, thanh toán, đồng ý hoặc xem xét quảng cáo. Sử dụng luân phiên có kiểm soát cho các tác vụ giám sát yêu cầu các phiên riêng biệt.

Luân phiên và tính cố định giải quyết các nhu cầu kiểm tra khác nhau. Luân phiên thay đổi IP đầu ra. Một phiên cố định giữ cùng một IP trong một khoảng thời gian hoặc định danh phiên xác định. Thay đổi IP trong quá trình đăng nhập hoặc thanh toán có thể giống như một phiên bị hỏng, trong khi một địa chỉ ổn định ít hữu ích hơn cho các công việc giám sát độc lập. Từ điển proxy bao gồm các phiên cố định và luân phiên giải thích các cơ chế này.

Khớp mạng với câu hỏi kinh doanh

Kiểm tra di động chính xác theo địa lý hỗ trợ giá cả địa phương, quy trình đồng ý khu vực, liên kết sâu trong cửa hàng ứng dụng, xác minh quảng cáo và theo dõi thứ hạng SEO. Nó cũng có thể tiết lộ hành vi CDN mà một kết nối máy tính để bàn trong văn phòng trung tâm sẽ không tái tạo. Đối với công việc hiệu suất, giữ lại thông tin về nhà mạng, lộ trình và chi tiết phiên để các lần chạy lặp lại so sánh cùng một điều kiện thực tế thay vì chỉ cùng một hồ sơ trình duyệt.

Sử dụng các điểm cuối HTTP hoặc SOCKS5 tùy theo trình duyệt hoặc lớp tự động hóa, và ghi lại lựa chọn đó trong kết quả kiểm tra. Các hệ thống proxy di động thường hỗ trợ cả hai tùy chọn vận chuyển. Định vị địa lý thường được chọn theo quốc gia và nhà mạng, đôi khi với kiểm soát ASN, như đã mô tả trong hướng dẫn proxy web di động và tài liệu điểm cuối proxy di động.

Giữ các rào cản rõ ràng. Tôn trọng giới hạn tỷ lệ của trang web, tránh sự thay đổi tài khoản đã đăng nhập không cần thiết, xin phép cho việc xác minh tự động, và giữ một nhật ký kiểm toán chứa IP đầu ra, nhà mạng, vị trí, hồ sơ trình duyệt và dấu thời gian kiểm tra. Khả năng tái tạo quan trọng như độ bao phủ. Nếu một lỗi không thể chạy lại với cùng một danh tính mạng và hành vi phiên, kết quả sẽ khó chẩn đoán.

Một Kế Hoạch Kiểm Tra Web Di Động Mẫu và Danh Sách Kiểm Tra Trước Khi Phát Hành

Một nhóm QA nhỏ có thể điều chỉnh kế hoạch sau trong một buổi chiều. Chìa khóa là xác định thiết bị, trình duyệt, mạng, ngôn ngữ và trạng thái phiên cho mỗi bài kiểm tra quan trọng, thay vì chỉ ghi lại “di động đã vượt qua.”

Bảy giai đoạn cho một ứng viên phát hành

Kiểm tra khói: Mở trang chính, xác thực nơi cho phép, tìm kiếm, thêm một mục, mở điều hướng chính và gửi một biểu mẫu rủi ro thấp trên các đường dẫn trình duyệt iOS và Android chính. Xác nhận rằng trang tải, các điều khiển cảm ứng phản hồi và lộ trình có ý nghĩa đầu tiên hoàn thành.

Chức năng: Thực hiện thanh toán, đồng ý, phục hồi tài khoản, tự động điền biểu mẫu, thay đổi hướng, hành vi khu vực an toàn trên các thiết bị có notch, nhắn tin ngoại tuyến và hành vi tiếp tục sau khi ở nền. Bao gồm việc hiển thị bảng thanh toán trên iOS Safari và Android Chrome, cộng với xử lý thông báo đẩy và liên kết sâu nơi sản phẩm sử dụng chúng.

Kiểm tra hồi quy: Chạy bộ kiểm tra trình duyệt tự động trên ma trận viewport và trình duyệt được hỗ trợ. Di chuyển các luồng rủi ro cao sang các thiết bị vật lý, đặc biệt sau khi có thay đổi về xác thực, lưu trữ, thanh toán, điều hướng hoặc tích hợp WebView.

Hiệu suất: Ghi lại trạng thái trường di động, tái tạo các lỗi dưới điều kiện mạng và CPU bị giới hạn, và kiểm tra LCP, INP, CLS, TTFB và Thời gian Chặn Tổng. Ghi lại loại thiết bị, lộ trình, trạng thái bộ nhớ đệm và hồ sơ kiểm tra với mỗi kết quả.

Bảo mật: Kiểm tra HTTPS, nội dung hỗn hợp, hành vi HSTS, kỳ vọng chứng chỉ cho các ngữ cảnh nhúng, vô hiệu hóa phiên, chuyển hướng không an toàn và xử lý đầu vào. Liên kết các rủi ro web-view liên quan với hướng dẫn bảo mật ứng dụng di động OWASP, mà không coi kiểm tra trình duyệt như một sự thay thế cho đánh giá bảo mật hoàn chỉnh.

Khả năng tiếp cận: Kiểm tra độ tương phản màu, truy cập bàn phím và công tắc khi áp dụng, thứ tự tập trung dưới phóng to, tiêu điểm hiển thị, nhãn, thông điệp lỗi và các mốc cho trình đọc màn hình theo kỳ vọng WCAG 2.2. Phát hiện độ tương phản di động của HTTP Archive khiến điều này trở thành một mối quan tâm phát hành, không chỉ là một đánh giá thẩm mỹ.

Cổng phát hành: Chặn phát hành trên các lỗi hành trình quan trọng, các đường dẫn thanh toán hoặc xác thực bị hỏng, các hành động chính không thể truy cập, biến thể địa lý không giải thích được, hoặc một sự hồi quy hiệu suất vượt quá ngân sách đã thỏa thuận của nhóm. Giữ tiêu chí quay lại được viết trước khi bắt đầu chạy thử nghiệm.

Một danh sách kiểm tra phù hợp với vé

Chèn những mục có thể xác minh này vào Jira hoặc GitHub:

• Độ bao phủ thiết bị: Kiểm tra các loại thiết bị iOS và Android được hỗ trợ.
• Độ bao phủ trình duyệt: Chạy Safari di động và Chrome độc lập trên Android.
• Độ bao phủ WebView: Xác thực mọi đường dẫn trình duyệt nhúng được sử dụng bởi sản phẩm.
• Hành vi viewport: Xác nhận thẻ meta viewport và các điểm gãy phản hồi.
• Mật độ pixel: Kiểm tra độ sắc nét của hình ảnh và việc hiển thị văn bản trên các màn hình độ phân giải cao.
• Mục tiêu cảm ứng: Xác minh các điều khiển chính cung cấp ít nhất 44 x 44 pixel CSS.
• Động tác: Kiểm tra chạm, vuốt, khóa cuộn, hành vi bóp và nhấn lâu khi có liên quan.
• Hướng: Xoay trong quá trình tải, biểu mẫu, thanh toán và phát media.
• Khu vực an toàn: Kiểm tra các notch, góc bo tròn và các phần dưới của trình duyệt hoặc thiết bị.
• Bàn phím: Kiểm tra tiêu điểm, tự động điền, xác thực và đóng bàn phím.
• Trạng thái ngoại tuyến: Xác nhận thông điệp hữu ích và phục hồi an toàn sau khi kết nối lại.
• Liên kết sâu: Xác thực hành vi chuyển giao ứng dụng và trở lại.
• Đường dẫn đẩy: Kiểm tra quyền, xử lý giao hàng và định tuyến đích nơi sử dụng.
• Thanh toán: Hiển thị và hoàn tất bảng thanh toán trên các trình duyệt di động mục tiêu.
• Cookie: Xác minh trạng thái đồng ý, xác thực, giỏ hàng và chuyển hướng.
• Ngôn ngữ: Kiểm tra ngôn ngữ, tiền tệ, ngày tháng và nội dung khu vực.
• Mạng: Chạy các kịch bản mạng ổn định, bị giới hạn, bị gián đoạn và mạng nhà mạng.
• Địa lý: Xác thực hành vi quốc gia và nhà mạng thông qua một điểm cuối di động được phê duyệt.
• Trạng thái proxy: Ghi lại IP đầu ra, ASN, bộ giải DNS và chế độ phiên.
• Ngăn ngừa rò rỉ: Kiểm tra WebRTC và các đường dẫn khác để phát hiện rò rỉ mạng không mong muốn.
• LCP: Ghi lại trạng thái trường và tái tạo các lỗi di động trong phòng thí nghiệm.
• INP: Thực hiện gõ, lọc, menu và tương tác thanh toán.
• CLS: Tải lại với sự đồng ý, cá nhân hóa, banner và hình ảnh muộn.
• Khả năng tiếp cận: Xác minh độ tương phản, thứ tự tiêu điểm, phóng to, nhãn và các mốc.
• Quay lại: Xác nhận chủ sở hữu triển khai, kích hoạt quay lại và lộ trình phục hồi.

Đưa Tất Cả Vào Một Nơi và Tránh Những Sai Lầm Thường Gặp

Một nhịp độ đáng tin cậy bắt đầu với một ma trận thiết bị phản ánh các thị trường thực tế và rủi ro kinh doanh. Chạy các bài kiểm tra khói tự động trên các trình giả lập sớm, sử dụng các thiết bị vật lý cho các đường dẫn quan trọng trong phát hành, thêm các kiểm tra proxy di động cho hành vi phụ thuộc vào địa lý, và đánh giá Core Web Vitals dưới một hồ sơ 4G được kiểm soát trước khi ký duyệt.

Các lỗi phổ biến nhất đến từ việc coi di động như một mục tiêu máy tính để bàn nhỏ hơn. Kiểm tra chỉ trên điện thoại của nhóm QA sẽ che giấu sự biến đổi thiết bị. Tin tưởng vào kết quả Wi-Fi sẽ che giấu độ trễ và định tuyến của nhà mạng. Kiểm tra thông qua thanh công cụ thiết bị của trình duyệt máy tính để bàn sẽ bỏ lỡ hành vi thực tế của iOS Safari. Bỏ qua các kiểm tra mục tiêu cảm ứng và viewport sẽ để lại các lỗi mà người dùng phát hiện ngay lập tức.

Giữ ma trận liên kết với bằng chứng

Đừng mở rộng ma trận chỉ vì một danh sách kiểm tra phân mảnh chung nói rằng bạn nên. Thêm một thiết bị, trình duyệt, nhà mạng hoặc vị trí khi một bản phát hành có rủi ro liên quan, nghĩa vụ hỗ trợ hoặc lịch sử hồi quy.

Hãy chú ý đến những sai lầm cụ thể này:

• Bỏ qua CGNAT: Một địa chỉ nhà mạng chia sẻ có thể ảnh hưởng đến danh tiếng và hành vi chặn, trong khi một lỗ hổng IPv6 có thể vượt qua điều kiện mạng dự kiến.
• Thay đổi IP giữa dòng: Quá trình xoay vòng trong xác thực, thanh toán hoặc đồng ý có thể làm vô hiệu hóa một phiên và tạo ra một lỗi sản phẩm giả.
• Quá tin tưởng vào mô phỏng: Các trình mô phỏng rất tuyệt vời cho tốc độ, nhưng các radio vật lý, nhiệt độ và tích hợp trình duyệt vẫn cần được xác thực.
• Chỉ sử dụng trung bình: Các trung vị hiệu suất và trạng thái thực địa làm cho việc so sánh hữu ích hơn so với một lần chạy nhanh hoặc chậm bất thường.
• Bỏ qua hồi cứu: Nếu một hồi quy lần đầu tiên xuất hiện trên một trình duyệt, nhà mạng, địa phương hoặc loại thiết bị cụ thể, hãy ghi lại điều kiện đó và điều chỉnh ma trận tiếp theo.

Thói quen phát hành: Ghi lại điều kiện đầu tiên đã phơi bày lỗi, không chỉ tiêu đề lỗi. “Thanh toán thất bại” ít hữu ích hơn “thanh toán thất bại trên mobile Safari, tuyến nhà mạng Pháp, tiếp tục sau khi chuyển sang nền.”

Một chương trình kiểm tra web di động trưởng thành không phải là chương trình có danh sách thiết bị lớn nhất. Nó là chương trình có thể tái tạo một lỗi, giải thích lý do tại sao nó xảy ra, và quyết định xem bản phát hành tiếp theo có cần phạm vi rộng hơn hay không. Điều đó có nghĩa là kết hợp tự động hóa trình duyệt, khám phá thủ công, kiểm tra thiết bị thực, hiệu suất thực địa và xác thực địa lý nhận thức nhà mạng trong một vòng lặp có thể lặp lại.

Evoproxy cung cấp kết nối di động 4G/LTE với các tùy chọn định tuyến theo quốc gia và nhà mạng, kiểm soát phiên, và truy cập HTTP hoặc SOCKS5 cho QA dựa trên trình duyệt, xác minh quảng cáo, nghiên cứu địa phương hóa và các quy trình kiểm tra được ủy quyền khác. Truy cập Evoproxy để đánh giá một thiết lập proxy di động phù hợp với điều kiện mạng mục tiêu của bạn và thêm các kiểm tra địa lý có thể tái tạo vào quy trình kiểm tra web di động của bạn.