Giới thiệu về kiểm tra trình duyệt chéo

Bài viết này bắt đầu bằng cách cung cấp tổng quan về chủ đề kiểm thử trình duyệt (chéo), trả lời các câu hỏi như "kiểm thử trình duyệt chéo là gì?", "Loại sự cố phổ biến nhất bạn gặp phải là gì?" Và "các phương pháp chính để thử nghiệm, xác định và khắc phục sự cố là gì?"

Điều kiện tiên quyết: Quen thuộc với các các khái niệm cốt lõi của các ngôn ngữ HTML, CSSJavaScript.
Mục tiêu: Để hiểu được các khái niệm cấp cao liên quan đến kiểm tra trình duyệt chéo.

Kiểm thử trình duyệt chéo là gì?

Kiểm thử trình duyệt chéo là hoạt động đảm bảo trang web hoặc ứng dụng web của bạn chạy ổn trên một lượng trình duyệt chấp nhận được. Là một nhà phát triển web, bạn không chỉ có trách nhiệm đảm bảo dự án của mình chạy được, mà còn phải chạy được trên mọi trình duyệt, thiết bị hoặc thiết bị hỗ trợ mà người dùng của bạn sử dụng. Bạn cần tính đến các phương án như sau:

  • Trình duyệt khác một hoặc hai loại mà bạn thường dùng trên thiết bị của mình, bao gồm cả những trình duyệt hơi cũ một chút - không hỗ trợ tính năng "xịn xò" hoặc mới nhất của CSS hoặc JavaScript - mà một vài người vẫn còn dùng.
  • Thiết bị khác nhau có khả năng khác nhau, từ những dòng tablet và điện thoại thông minh đời mới nhất, hay tivi thông minh, đến những dòng rẻ tiền và cũ kỹ mà chỉ có thể chạy được những trình duyệt có tính năng giới hạn.
  • Người khuyết tật, những người dùng Web với công nghệ hỗ trợ như screenreader (trình đọc màn hình), hoặc không dùng chuột (vài người chỉ dùng bàn phím).

Hãy nhớ bạn không phải người dùng trang web của bạn — web của bạn có thể chạy ngon lành trên Macbook Pro hay dòng Galaxy Nexus cao cấp không có nghĩa là nó sẽ chạy được cho mọi người dùng — bạn còn phải kiểm thử nhiều lắm!

Ghi chú: Make the web work for everyone đưa ra nhiều góc nhìn dựa trên trình duyệt mà mọi người dùng, thị phần của các trình duyệt, và sự cố tương thích trình duyệt chéo.

Ta nên xem xét vài thuật ngữ đã. Trước hết, khi nhắc tới trang web "chạy ổn trên trình duyệt chéo", tức là chúng phải đạt được một lượng trải nghiệm người dùng chấp nhận được trên nhiều trình duyệt khác nhau. Một trang web được xếp vào dạng OK không có nghĩa trải nghiệm đều như nhau trên mọi trình duyệt, mà chỉ cần cho phép truy cập được các chức năng cốt lõi. Trên trình duyệt hiện đại, bạn có thể có đạt được hoạt hoạ (anmiation), 3D và các hiệu ứng chuyên nghiệp, trong khi trên trình duyệt cũ hơn, bạn sẽ chỉ có các mảng tĩnh chứa đầy đủ thông tin cần thiết. Chỉ cần chủ của trang web vui là bạn làm được việc rồi.

Mặt khác, sẽ chẳng OK tẹo nào nếu một trang chỉ chạy ổn với những người bình thường, còn người khuyết tật thì hoàn toàn không thể truy cập được bởi vì trình screen reader của họ không thể đọc được nội dung trên trang web.

Thứ hai, khi nhắc tới "một lượng trình duyệt web chấp nhận được", không có nghĩa hoàn toàn 100% trình duyệt trên toàn thế giới — điều này là bất khả thi. Bạn nên dự đoán trước các trình duyệt và thiết bị mà người dùng trang web sẽ có thể dùng tới (ta sẽ bàn về vấn đề này trong phần thứ hai của loạt bài viết này — mời đọc Gotta test 'em all?), nhưng bạn không thể đảm bảo mọi thhws. Là nhà phát triển web, bạn cần ước lượng một khoảng nhất định trình duyệt và thiết bị chắc chắn chạy được mã bạn viết ra; còn ngoài khoảng đó, bạn phải viết làm sao để cho các trìnhh duyệt khác cũng có thheer sử dụng nội dung của mình. Đây là một trong những thách thức khó nhằn nhất với nhà phát triển web.

Ghi chú: Ta sẽ xem mã nguồn về phần này trong các bài viết sau.

Tại sao lại xảy ra sự cố tương thích trình duyệt chéo?

Có nhiều lý do khác nhau giải thích tại sao sự cố tương thích trình duyệt chéo lại xảy ra, trong bài viết này, chúng tôi chủ yếu đề cập những sự cố với hành vi khác nhau trên các trình duyệt / thiết bị / cài đặt duyệt web khác nhau. Before you even get to cross browser issues, you should have already fixed out bugs in your code (see Gỡ lỗi HTML, Gỡ lỗi CSS, và Sai ở đâu? Khắc phục sự cố JavaScript từ các chủ đề trước đây để nạp lại trí nhớ của bạn).

Sự cố trình duyệt chéo thường xảy ra vì:

  • thỉnh thoảng trình duyệt có lỗi, hoặc hiện thực hoá các tính năng theo cách riêng biệt. Trường hợp này giờ đỡ khiếp hơn ngày trước; vào thời kỳ IE4 và Netscape 4 tranh nhhau thị phần mảng trình duyệt trong thập niên 80, các công ty trình duyệt thời đó cố tình cài đặt mọi thứ theo cách riêng biệt để đạt được lợi thế cạnh tranh, điều đó khiến cho các nhà phát triển ứng dụng mệt lử. Trình duyệt hiện nay đã bớt đi các khía cạnh đó, nhưng thi thoảng sự khác biệt và lỗi vẫn phát sinh
  • một số trình duyệt có hỗ trợ tính năng công nghệ theo mức khác nhhau. Điều này là không thể tránh khỏi khi bạn sử dụng công nghệ quá tân tiến mà trình duyệt hiện đại đang chuẩn bị cài đặt chúng, hoặc bạn phải hỗ trợ các trình duyệt cũ kỹ mà chẳng ai thèm phát triển thêm nữa, hay còn gọi là đóng băng (tức là không có thêm cập nhật mới) khá lâu trước cả khi tính năng đó được tạo ra. Chẳng hạn, nếu bạn muốn dùng tính năng tân tiến của JavaScript trong trang web của mình, những tính năng đó có thể sẽ không hoạt động trên trình duyệt cũ. Nếu bạn muốn hỗ trợ các trình duyệt cũ hơn, có lẽ bạn phải dùng đoạn mã khác, hoặc tìm cách dịch ngược đoạn mã của mình thành mã mà trình duyệt đó có thể hiểu được (thông qua các trình biên dịch chéo).
  • một số thiết bị có thể có hạn chế khiến cho trang web chạy chậm, hoặc hiển thị tồi. Chẳng hạn, nếu một web được thiết kế thật đẹp trên PC, chắc chắn người dùng điện thoại sẽ thấy nó nhỏ xíu và khó đọc. Nếu trang của bạn có nhiều hoạt hoạ nặng, chắc hẳn nó sẽ chạy êm ru trên một chiếc tablet cấu hỉnh mạnh, nhưng sẽ chậm chạp và ì achhj trên một thiết bị yếu đuối hơn.

và còn nhiều lý do hơn nữa.

Trong các bài viết tiếp sau này, ta sẽ khám phá thêm các sự cố trình duyệt chéo thường gặp, và tìm giải pháp.

Quy trình kiểm thử trình duyệt chéo

Mới nghe qua về công việc kiểm thử trình duyệt chéo thì có vẻ đáng sợ vầ tốn thời gian thật, nhưng không hẳn là vậy đâu - bạn chỉ cần lên kế hoạch thật kỹ càng, và đảm bảo bạn thực hiện đủ và đúng chỗ để không bị lạc vào những sự cố khó lường. Nếu bạn làm việc với một dự án lớn, bạn nên kiểm thử định kỳ, để chắc chắn tính năng mới hoạt động với đối tượng mục tiêu của bạn, và những đoạn mã mới thêm không phá huỷ tính năng cũ mà trước đó hoạt động ngon nghẻ.

Nếu bạn để dành kiểm thử tới cuối dự án, lúc này mọi lỗi bạn phát hiện ra đều tốn kém chi phí và thời gian để sửa hơn trong lúc xây dựng.

Quy trình kiểm thử và sửa lỗi cho một dự án có thể được chia làm 4 pha (mỗi người có cách chia khác nhau):

Lên kế hoạchh > Phát triển > Kiểm thử/ khai phá > Sửa lỗi/ lặp lại

Từ bước 2 – 4 sẽ thường được lặp đi lặp lại cho tới khi đã cài đặt hết tất cả mọi thứ. Ta sẽ xem kỹ hơn về từng giai đoạn thuộc quy trình kiểm thử trong các bài viết sau, còn giờ cứ lướt qua từng bước nhé.

Lên kế hoạch

Trong pha lên kế hoạch, chắc hẳn bạn sẽ gặp mặt chủ của trang/ khách hàng (đây có thể là sếp của bạn, hoặc một người ở đơn vị ngoài thuê bận làm), tại đây bạn sẽ xác định chính xác xem trang web nên trông như thế nào - nội dung và tính năng của trang là gì, trông nó ra làm sao, vân vân. Ngoài ra, bạn sẽ còn muốn biết bạn có bao nhiêu thời gian để thực hiện trang web - hạn cuối của họ là bao giờ, và họ định bỏ bao nhiêu ra để trả cho bạn? Ta sẽ không đi quá chi tiết vào phần này, nhưng sự cố trình duyệt chéo thường có ảnh hưởng quan trọng tới bước lên kế hoạch.

Ngay khi có ý tưởng về các chức năng cần làm, và công nghệ để bạn dựng chúng lên, bạn nên bắt đầu tìm hiểu về đối tượng mục tiêu — trình duyệt hay thiết bị nào sẽ là đối tượng mục tiêu cho trang web của bạn? Có thể khách hàng của bạn đã có dữ liệu về những đối tượng này rồi, thông qua các nghiên cứu của riêng bên họ, như là từ các trang web mà họ đã sở hữu, hoặc từ chính phiên bản cũ của trang web mà bạn đang làm mới. Nếu không có dữ liệu về vấn đề này, bạn có thể dựa trên dữ liệu của một số nguồn khác, như là thông tin của phe đối thủ, hay là vùng đất mà trang web của bạn chuẩn bị hoạt động. Bạn cũng có thể dựa vào trực giác.

Chẳng hạn, bạn chuẩn bị xây dựng một trang thương mại điện tử phục vụ khách hàng ở Bắc Mĩ. Trang web đó nên chạy ổn định trên mọi trình duyệt nổi tiếng cho máy tính cá nhân cũng như thiết bị di động (iOS, Android, Windows phone) — nên bao gồm cả Chrome (và Opera bởi nó dùng cùng engine với Chrome), Firefox, IE/Edge, và Safari. Trang web đó cũng nên có trải nghiệm truy cập chấp nhận được trên IE 8 và 9, và tuân thủ WCAG AA.

Khi nắm được các nền tảng để kiểm thử, bạn nên dành thời gian kiểm tra lại các chức năng cũng như công nghệ bạn định dùng. Chẳng hạn, nếu chủ của trang thương mai điện tử đó muốn có 3D tour sử dụng WebGL cho từng sản phẩm trên trang chi tiết sản phẩm, họ buộc phải chấp nhận rằng tính năng này không thể hoạt động trên IE trước phiên bản 11. Bạn sẽ phải làm thêm phiên bản khác không có tính năng này để hỗ trợ người dùng dùng bản IE cũ hơn.

Bạn nên soạn ra danh sách khoanh vùng sự cố tiềm tàng.

Ghi chú: Bạn có tìm thấy thông tin về hỗ trợ tương thích trình duyệt đối với các công nghệ ngay trên trính trang này - MDN! Ngoài ra bạn cũng nên ghé qua caniuse.com, để kiếm thêm thông tin chi tiết hữu ích.

Khi đã có đủ thông tin chi tiết rồi, bạn có thể chuyển sang phát triển trang web.

Phát triển

Giớ đến pha phát triển trang web. Bạn nên chia nhỏ các phần khác nhau trong trang thành mô-đun, chẳng hạn, bạn nên chia nhỏ các vùng hiển thị trên trang thành - trang chủ, trang chi tiết sản phẩm, giỏ hàng, luồng thanh toán, vân vân. Sau đó bạn cũng có thể chia nhỏ hơn nữa - cài đặt đầu trang, cuối trang, chi tiết sản phẩm, vân vân.

Có nhiều chiến lược phát triển trên trình duyệt chéo, chẳng hạn:

  • Đảm bảo mọi chức năng đều hoạt động được trên mọi trình duyệt đối tượng. Để đạt được điều này, bạn có thể sẽ phải viết nhiều dòng mã khác nhau để tái hiện các chức năng đó cho các trình duyệt khác nhau, hoặc dùng Polyfill trên JavaScript hoặc công nghệ khác để hỗ trợ chúng, hoặc dùng thư viện có chức năng tự động hoá công cuộc đó (như Babel) tuỳ thuộc vào trình duyệt mà đối tượng mục tiêu của bạn sử dụng.
  • Chấp nhận rằng có một số thứ không thể hoạt động y hệt nhau trên mọi trình duyệt, và đưa ra giải pháp khác (chấp nhận được) cho trình duyệt không hỗ trợ mọi chức năng. Đôi khi ta không thể tránh khỏi điều này do hạn chế từ phía thiết bị — trải nghiệm thị giác trên màn ảnh rộng ở rạp chiếu phim không thể sánh được với chiếc điện thoại có kích thước màn 4 inch được, không kể cách bạn lập trình trang web của mình..
  • Chấp nhận rằng trang web của bạn sẽ không chạy được trên trình duyệt lâu đời, và bước tiếp. Điều này OK nếu khách hàng của bạn/ người dùng của bạn OK với điều đó.

Thông thường quá trình phát triển của bạn sẽ bao gồm sự kết hợp của cả ba hướng tiếp cận phía trên. Điều quan trọng nhất trong pha này là bạn phải kiểm thử từng phần nhỏ trước khi tải nó lên - đừng để dành kiểm thử đến cuối!

Kiểm thử/ Khai phá

Sau mỗi pha phát triển, bạn sẽ cần kiểm thử chức năng mới của mình. Trước hết, bạn nên đảm bảo không có lỗi lớn nào trong mã nguồn cản trở sự hoạt động của chắc năng đó:

  1. Kiểm thử nó với một vài trình duyệt ổn định nhất trên hệ thống của bạn, như là Firefox, Safari, Chrome, hay IE/Edge.
  2. Thử tiếp cận trang của bạn theo cách thủ công hơn, chẳng hạn như chỉ dùng bàn phím, hoặc screen reader để xem liệu nó có thể điều hướng được hay không.
  3. Kiểm thử trên thiết bị di động, như Android hoặc iOS.

Tới đây, hãy sửa mọi lỗi lầm mà bạn phát hiện trong đoạn mã nguồn mới.

Kế đến, bạn nên thử mở rộng danh sách trình duyệt cần kiểm thử hướng tới đối tượng mục tiêu của mình và tập trung phát hiện sự cố trình duyệt chéo (để biết thêm chi tiết, đọc trong bài tiếp theo xác định đối tượng trình duyệt được sử dụng). Chẳng hạn:

  • Kiểm thử thay đổi mới nhất đó trên nhiều trình duyệt hiện đại cho dòng máy tính cá nhân nhất có thể — bao gồm Firefox, Chrome, Opera, IE, Edge, và Safari trên các hệ điều hành máy tính cá nhân (lý tưởng nhất là Mac, Windows, và Linux).
  • Kiểm thử trên các dòng điện thoại thông minh và máy tính bảng thông dụng (tức là iOS Safari trên iPhone/iPad, Chrome và Firefox trên iPhone/iPad/Android),
  • Kiểm thử trên cả các trình duyệt có trong danh sách đối tượng của bạn nữa.

Cách chân tay nhất là tự tay kiểm thử mọi thứ (kéo thêm vài thành viên nữa nếu bạn làm việc trong nhóm). Nếu có thể, bạn nên kiểm thử trên thiết bị thật.

Nếu bạn không có đủ tư liệu để kiểm thử tất cả các trình duyệt, hệ điều hành hay thiết bị phần cứng, bạn cũng có thể thử dùng bộ mô phỏng (mô phỏng một thiết bị bằng phần mềm trên máy tính cá nhân của mình) và máy ảo (phần mềm cho phép bạn mô phỏng hệ điều hành/ phần mềm khác trên máy tính cá nhân của mình). Đây là một trong những quyết định khá là phổ biến, đặc biệt trong một số tình huống - chẳng hạn, Windows không cho phép bạn cài nhiều phiên bản của hệ điều hành trên cùng một máy, vậy thì chỉ còn dựng máy ảo lên thôi.

Ngoài cách đó ra, bạn có thể dùng nhóm người dùng - dùng một nhóm người nằm ngoài đội phát triển của bạn để kiểm thử trang web cho bạn. Nhóm người này có thể là bạn bè hoặc người thân trong gia đình, nhóm các đồng nghiệp khác, một lớp học ở các cơ sở giáo dục, hoặc một chuyên gia kiểm thử, bạn bỏ tiền ra để lấy được kết quả kiểm thử.

Sau cùng, bạn có thể kiểm thử thông minh hơn bằng cách sử dụng công cụ kiểm toán hoặc tự đống hoá; đây là một lựa chọn đáng để lưu tâm khi dự án của bạn phình to lên, do kiểm thử bằng tay thực sự mất kha khá nhiều thì giờ. Bạn có thể tự cấu hình hệ thống kiểm thử tự động (Selenium hiện đang là ứng dụng khá phổ biến phục vụ mục đích này) có thể kiểm thử hoạt động của trang bạn trên nhiều trình duyệt khác nhau, và:

  • kiểm tra xem nút bấm trên màn hình có trả về hành vi chuẩn hay không (chẳng hạn, nút bấm đăng nhập), hiển thị kết quả sau mỗi lần kiểm tra
  • chụp lại ảnh màn hình, cho phép bạn kiểm tra xem layout trang có đồng nhất trên mọi trình duyệt hay không.

Nếu muốn, còn nhiều thứ để bạn lựa hơn. Có vài công cụ mất phí như là Sauce LabsBrowser Stack giúp bạn đạt được mục đích của mình, mà không phải tốn thời gian cấu hình, nếu bạn sẵn sàng bỏ ra chút kinh phí vào công cuộc kiểm thử. Bạn cũng có thể cấu hình môi trường tự động kiểm thử cho mình, và chỉ cho phép kết hợp thay đổi của mình vào kho mã nguồn khi nó vượt qua được bài kiểm tra tương thích.

Kiểm thử trên trình duyệt mới ra mắt

Việc kiểm thử trên phiên bản mới ra mắt của trình duyệt thường là ý tưởng hay; xem trong đống link sau:

Bạn nên kiểm thử theo cách này nếu bạn dùng công nghệ mới tinh trong trang web của mình, và bạn muốn kiểm thử với phiên bản mới nhất, hoặc bạn muốn thử xem nhà phát triển của trình duyệt đã sửa cái lỗi bạn tìm thấy trên phiên bản đó hay không.

Sửa lỗi/ Lặp lại

Khi phát hiện được lỗi, bạn cần thử sửa nó.

Trước hết phải thu hẹp vùng có thể gây lỗi. Ghi lại thật nhiều thông tin từ người báo lỗi cho bạn — nền tảng, thiết bị, trình duyệt, vân vân. Hãy thử lỗi đó với cấu hình tương tự (tức là cùng phiên bản trình duyệt trên nhiều nền tảng khác nhau, hoặc nhiều phiên bản trình duyệt trên cùng một nền tảng) và đánh giá vùng gây lỗi.

Có thể đó không phải lỗi của bạn — nếu có lỗi trên trình duyệt, chỉ còn cách cầu mong nhà phát triển của trình duyệt đó mau chóng sửa lỗi. Lỗi đó cũng có thể đã được sửa rồi — chẳng hạn nếu có một lỗi tồn tại trên Firefox release 49, nhưng không còn gặp lại lỗi đó nữa trên Firefox Nightly (phiên bản 52), thì họ đã sửa nó rồi. Nếu nó vẫn chưa được sửa, bạn sẽ muốn báo lỗi (xem Reporting bugs, phía dưới).

Nếu đó là lỗi của bạn, bạn phải sửa nó! Dò nguyên nhân gây lỗi cũng áp dụng chiến lược y như mọi lỗi khi phát triển web (nhắc lại, hãy đọc Gỡ lỗi HTML, Gỡ lỗi CSS, và Sai ở đâu? Khắc phục sự cố JavaScript). Khi đã xác định được nguyên nhân gây ra lỗi, bạn cần quyết dịnh xem sẽ xử lý thế nào để nó hoạt động được với các trình duyệt sinh ra lỗi này — bạn không thể cứ thể đổi thẳng mã nguồn, bởi điều này có thể khiến nó không chạy được trên các trình duyệt khác. Hướng tiếp cận chung lúc này là sao chép lại mã nguồn và sửa cũng như kiểm thử trên phiên bản mã nguồn đó.

Khi đã sửa được lỗi, bạn nên lặp lại quy trình kiểm thử để đảm bảo chỗ bạn vừa sửa chạy OK, và không gây lỗi tới các phần khác hoặc trên các trình duyệt khác.

Báo lỗi

Nhắc lại phía trên, nếu bạn phát hiện lỗi trên trình duyệt, bạn nên báo cáo chúng cho nhà phát triển biết:

Tóm tắt

Bài viết này cung cấp cho bạn các lý thuyết quan trọng nhất về kiểm thử trình duyệt chéo. Với đống kiến thức này, giờ bạn đã sẵn sàng học tiếp các chiến lược Kiểm thử trình duyệt chéo.

Trong loạt bài này