Trang chủ › Nghiệm thu website trên điện thoại: kiểm tra tràn ngang

Nghiệm thu website trên điện thoại: kiểm tra tràn ngang

Tên miền này đang được rao bán

Hotline: 0945 279 268 Email: tuvan@tenmienhay.vn Website: tenmienhay.vn

Để nghiệm thu website trên điện thoại, đừng chỉ xem một ảnh chụp trang chủ. Hãy mở các trang quan trọng, cuộn từ đầu đến cuối và hoàn thành một thao tác thật: mở menu, đọc bảng giá hoặc điền biểu mẫu bằng dữ liệu thử. Nội dung chính phải đọc được, nút cần dùng phải tiếp cận được và trang không bị kéo lệch sang bên vì một khối quá rộng.

Bài này là checklist dành cho người thuê thiết kế website, tập trung vào bố cục trên màn hình hẹp và cách giao lỗi cho đơn vị triển khai. Đây không phải chứng nhận khả năng tiếp cận hay cam kết rằng một lần kiểm tra sẽ bao phủ mọi thiết bị. Có thể đưa các đầu việc dưới đây vào checklist thuê dịch vụ thiết kế website ngay từ lúc chốt phạm vi.

1. Chốt trang và tình huống trước khi thử

Chọn các loại trang đại diện, không chỉ một URL đẹp nhất: trang chủ, trang dịch vụ, bài viết dài, trang có bảng hoặc ảnh lớn, trang liên hệ. Nếu có nhiều mẫu giao diện, mỗi mẫu cần được xem riêng. Dùng nội dung gần thực tế, gồm tiêu đề dài, tên dịch vụ nhiều chữ và ảnh theo đúng tỷ lệ dự kiến; vài dòng chữ ngắn có thể che mất lỗi bố cục.

Ghi rõ điện thoại, hệ điều hành, trình duyệt và chiều dọc/ngang khi thử. Trên máy tính, nhờ bên triển khai mở chế độ mô phỏng màn hình hẹp và thay đổi chiều rộng từ nhỏ lên lớn. Sau đó đối chiếu trên điện thoại thật nếu có. Hai cách bổ sung cho nhau: cửa sổ thu hẹp giúp tìm điểm vỡ bố cục, còn điện thoại thật giúp quan sát thao tác chạm và bàn phím ảo.

Theo hướng dẫn responsive của web.dev, bố cục nên thích ứng với nội dung và không buộc người đọc cuộn ngang để xem toàn trang. Điểm chuyển bố cục nên xuất phát từ nhu cầu của nội dung, không chỉ từ tên một dòng điện thoại.

2. Phân biệt tràn toàn trang với vùng cuộn có chủ đích

Dấu hiệu cần ghi lỗi

  • Đoạn văn bị cắt bên phải hoặc phải kéo trang sang ngang mới đọc hết.
  • Ảnh, video hay biểu mẫu rộng hơn phần nội dung, làm toàn trang lệch sang bên.
  • Tên dịch vụ dài đẩy nút liên hệ ra ngoài màn hình.
  • Menu mở ra nhưng mục cuối bị che hoặc nút đóng không còn thấy.
  • Khối nổi che nội dung và không có cách thuận tiện để đọc hoặc thao tác phần bị che.

Thử tại đầu trang, giữa trang và cuối trang. Nếu chỉ xem vùng đầu, bảng ở gần cuối có thể là nguyên nhân gây tràn mà chưa được phát hiện. Đừng đánh giá chỉ bằng việc trình duyệt có hiện thanh cuộn hay không: hãy trực tiếp kiểm tra nội dung có bị mất, lệch hoặc cần kéo ngang không.

Khi bảng được cuộn riêng

Một bảng so sánh nhiều cột có thể được đặt trong vùng cuộn ngang riêng để giữ quan hệ giữa các cột. Khi đó cần phân biệt rõ bảng cuộn trong khung với cả trang bị kéo ngang. Kiểm tra người đọc có nhận ra còn cột bên phải không, có xem được tiêu đề cột và có trở lại phần văn bản bình thường được không.

Không coi mọi thanh cuộn ngang là cùng một loại lỗi, nhưng cũng không chấp nhận câu trả lời “bảng nào cũng vậy”. Hãy yêu cầu bên thiết kế giải thích phương án: vùng cuộn riêng, chia bảng, hoặc cách trình bày phù hợp hơn với nhiệm vụ của người đọc. Không được làm mất thông tin quan trọng chỉ để trang trông gọn.

3. Thử thao tác, không chỉ nhìn bố cục

Menu và nút liên hệ

Mở menu, chọn một mục, quay lại rồi mở lần nữa. Thử cả chiều dọc và ngang. Quan sát nút gọi điện hoặc nút gửi yêu cầu khi cuộn: có che phần cần đọc hay đè lên nút khác không? Với nút gọi điện trên site thật, chỉ kiểm tra liên kết hoặc màn hình xác nhận; không gọi thử tới nhà cung cấp nếu chưa được phép.

Thiết bị nhỏ không đồng nghĩa với chỉ dùng cảm ứng, và màn hình lớn cũng không đồng nghĩa với chỉ dùng chuột. Tài liệu MDN về media queries phân biệt các đặc tính như chiều rộng, khả năng hover và loại con trỏ. Vì vậy, yêu cầu “hỗ trợ mobile” cần mô tả kết quả sử dụng, không chỉ có một ảnh giao diện thu nhỏ.

Biểu mẫu và bàn phím ảo

Dùng môi trường thử hoặc biểu mẫu đã được thống nhất cho phép gửi dữ liệu thử. Chạm vào ô cuối, mở bàn phím rồi xem nhãn, nội dung đang nhập và nút tiếp theo có còn tiếp cận được không. Sau khi đóng bàn phím, kiểm tra bố cục có trở lại bình thường không. Không dùng số điện thoại hay thông tin cá nhân của người khác để thử.

Phần thông báo sai định dạng hoặc thiếu dữ liệu cần kiểm tra riêng theo bài nghiệm thu lỗi nhập liệu biểu mẫu. Một biểu mẫu không tràn ngang vẫn có thể thông báo lỗi khó hiểu; đây là hai tiêu chí khác nhau.

Phóng to và nội dung dài

Thử tăng mức phóng to được trình duyệt hỗ trợ, rồi đọc đoạn dài và tìm nút hành động. Ghi lại mức đã thử cùng lỗi quan sát được; đừng ghi “đạt mọi mức zoom” khi chỉ thử một trường hợp. web.dev lưu ý việc hạn chế khả năng phóng to có thể gây vấn đề tiếp cận. Thu nhỏ chữ hoặc khóa zoom không phải cách nghiệm thu lỗi tràn nội dung.

4. Mẫu ghi lỗi có thể tái hiện

Một phản hồi như “mobile bị xấu” khiến bên sửa khó xác định điều kiện lỗi. Có thể dùng mẫu ghi nhận sau; đây là ví dụ giả định, không phải kết quả kiểm tra của một website cụ thể:

  • URL và khu vực: trang dịch vụ, bảng so sánh ba gói ở giữa bài.
  • Điều kiện: điện thoại và phiên bản trình duyệt được ghi trong biên bản; chiều dọc; mức phóng to mặc định.
  • Bước làm: mở trang, chờ ảnh tải, cuộn tới bảng, kéo ngang nhẹ.
  • Kết quả thực tế: cả trang lệch sang phải; chữ ở đoạn sau bảng nằm ngoài khung nhìn.
  • Kết quả mong muốn: văn bản vừa màn hình; nếu bảng cần cuộn, chỉ vùng bảng cuộn và vẫn đọc được thông tin cần so sánh.
  • Bằng chứng: ảnh hoặc video ngắn đã che dữ liệu riêng tư, kèm thời điểm và phiên bản trang.
  • Kiểm tra lại: ghi phiên bản đã sửa, lặp lại đúng bước cũ và kết quả mới.

Ưu tiên xử lý lỗi ngăn gửi yêu cầu hoặc làm mất thông tin quan trọng trước khác biệt trang trí. Đây là thứ tự kiểm tra đề xuất, không thay thế tiêu chí nghiệm thu và trách nhiệm đã thỏa thuận giữa hai bên.

5. Chốt nghiệm thu bằng danh sách có giới hạn rõ ràng

Sau khi sửa, mở lại URL từng lỗi và ít nhất một trang khác dùng cùng mẫu giao diện. Kiểm tra cả màn hình hẹp lẫn màn hình rộng để tránh sửa được một nơi nhưng làm hỏng nơi khác. Đối chiếu cùng nội dung thực tế; nếu thay bảng dài bằng bảng ngắn thì chưa chứng minh lỗi cũ đã hết.

Biên bản nên ghi: trang đã thử, thiết bị hoặc kích thước đã thử, thao tác đã hoàn thành, lỗi còn lại, người phụ trách và thời điểm kiểm tra lại. Mục chưa thử phải ghi “chưa kiểm tra”, không đánh dấu đạt. Phần kiểm tra website bằng bàn phím vẫn cần thực hiện riêng; trang vừa màn hình không tự chứng minh mọi người đều thao tác được.

Câu hỏi thường gặp

Xem được trên một điện thoại là đủ chưa?

Chưa đủ để suy ra tất cả thiết bị đều ổn. Ít nhất cần chốt phạm vi trang và điều kiện kiểm thử phù hợp dự án, có thử các chiều rộng khác nhau và ghi rõ phần chưa bao phủ. Không có một danh sách tên máy cố định bảo đảm bắt được mọi lỗi bố cục.

Chỉ cần yêu cầu lập trình viên ẩn phần tràn ngang?

Không nên nghiệm thu chỉ vì thanh cuộn biến mất. Nếu cách sửa che mất cột giá, chữ hay nút, nhiệm vụ đọc và thao tác vẫn chưa hoàn thành. Hãy kiểm tra nội dung sau sửa thay vì chỉ quan sát mép trang.

Ảnh chụp mô phỏng có thay thế thao tác thật không?

Ảnh giúp lưu bằng chứng, nhưng không chứng minh menu đóng mở được, biểu mẫu dùng được khi bàn phím xuất hiện hoặc liên kết dẫn đúng trang. Nếu chưa thử trên thiết bị thật, ghi đúng giới hạn đó trong biên bản.

Phát triển dự án nội dung với DichVuHay.vn

DichVuHay.vn phù hợp để phát triển nội dung hướng dẫn chọn nhà cung cấp, chuẩn bị yêu cầu và nghiệm thu dịch vụ. Website hiện cung cấp nội dung tham khảo và giới thiệu tên miền đang rao bán, không tự nhận là đơn vị thiết kế hay kiểm định website.

Nếu muốn trao đổi về việc mua tên miền DichVuHay.vn cho dự án phù hợp, liên hệ 0945 279 268. Đây là liên hệ mua bán tên miền, không phải nơi tiếp nhận yêu cầu sửa website; sở hữu tên miền không bảo đảm thứ hạng tìm kiếm, khách hàng hay doanh thu.

☎ Gọi điện Zalo