From 95aca4b4d8fa62815d4bd412fff1a364f842814a Mon Sep 17 00:00:00 2001 From: Ryan Johnson Date: Thu, 29 Apr 2021 16:16:42 -0700 Subject: remove retired locales (#699) --- .../cross_browser_testing/index.html | 33 -- .../cross_browser_testing/introduction/index.html | 201 ------------ .../testing_strategies/index.html | 358 --------------------- files/vi/learn/tools_and_testing/index.html | 48 --- 4 files changed, 640 deletions(-) delete mode 100644 files/vi/learn/tools_and_testing/cross_browser_testing/index.html delete mode 100644 files/vi/learn/tools_and_testing/cross_browser_testing/introduction/index.html delete mode 100644 files/vi/learn/tools_and_testing/cross_browser_testing/testing_strategies/index.html delete mode 100644 files/vi/learn/tools_and_testing/index.html (limited to 'files/vi/learn/tools_and_testing') diff --git a/files/vi/learn/tools_and_testing/cross_browser_testing/index.html b/files/vi/learn/tools_and_testing/cross_browser_testing/index.html deleted file mode 100644 index b581a119f1..0000000000 --- a/files/vi/learn/tools_and_testing/cross_browser_testing/index.html +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: Kiểm tra trình duyệt chéo -slug: Learn/Tools_and_testing/Cross_browser_testing -translation_of: Learn/Tools_and_testing/Cross_browser_testing ---- -
{{LearnSidebar}}
- -

Mô-đun này tập trung vào kiểm thử các dự án web trên các trình duyệt khác nhau. Chúng tôi xem xét việc xác định đối tượng mục tiêu của bạn (ví dụ: người dùng, trình duyệt và thiết bị nào bạn cần quan tâm nhất?), Cách thực hiện kiểm thử, các vấn đề chính mà bạn sẽ phải đối mặt với các loại mã khác nhau và cách giảm thiểu chúng, những công cụ nào hữu ích nhất trong việc giúp bạn kiểm thử và khắc phục sự cố và cách sử dụng tự động hóa để tăng tốc độ kiểm thử.

- -

Điều kiện tiên quyết

- -

Bạn nên thành thạo cốt lõi của các ngôn ngữ HTML, CSS, và JavaScript trước khi sử dụng công cụ được liệt kê trong loạt bài viết này.

- -

Hướng dẫn

- -
-
Giới thiệu về kiểm thử trình duyệt chéo
-
Khởi đầu mô-đun bằng cách cung cấp khái quát về vấn đề kiểm thử trình duyệt chéo, trả lời các câu hỏi như là "kiểm thử trình duyệt chéo là gì?", "các sự cố thường gặp như thế nào?", và "các hướng tiếp cận chính để kiểm thử, xác định và sửa chữa các sự cố đó?"
-
Chiến lược kiểm thử
-
Tiếp theo, ta đào sâu vào chiến lược kiểm thử, xác định đối tượng mục tiêu (tức là trình duyệt, thiết bị, và những phân đoạn nào bạn nên kiểm thử kỹ lưỡng), chiến lược kiểm thử low fi (kiếm thật nhiều thiết bị và vài máy ảo, và kiểm thử ad hoc nếu cần), chiếc lược high tech (tự động hoá, sử dụng ứng dụng dành riêng cho việc kiểm thử), và kiểm thử với nhóm người dùng.
-
Xử lý sự cố HTML và CSS thường gặp
-
Sau khi đã nắm bắt được căn bản, ta sẽ đi vào tìm hiểu những sự cố tương thích trình duyệt thường gặp trong các đoạn mã HTML và CSS, và dùng công cụ nào để ngăn chặn sự cố xảy ra, hoặc sửa chữa lỗi lầm hiện hành. Điều này bao gồm phân tích mã nguồn (linting), xử lý tiền tố CSS, dùng công cụ dành cho nhà phát triển của trình duyệt để mò lỗi, dùng polyfill để hỗ trợ thêm cho trình duyệt, xác định vấn đề trong thiết kế linh hoạt, và nhiều hơn nữa.
-
Xử lý sự cố JavaScript thường gặp
-
Giờ ta sẽ xem xét tới sự cố tương thích trình duyệt của JavaScript và cách sửa chúng. Điều này bao gồm thông tin về cách dùng công cụ dành cho nhà phát triển của trình duyệt đề mò lỗi và cách sửa chúng, dùng polyfill và thư viện để dựng giải pháp dự phòng, dùng tính năng cao cấp của JavaScript trên các trình duyệt cổ, và hơn thế nữa.
-
Xử lý sự cố tiếp cận thường gặp
-
Tiếp đến ta dành tâm trí cho khả năng tiếp cận, cung cấp thông tin về các sự cố thường gặp, cách kiểm thử đơn giản, và cách dùng công cụ kiểm toán/ tự động hoá để tìm kiếm sự cố tiếp cận.
-
Hiện thực bộ nhận diện tính năng
-
Nhận diện tính năng liên quan tới kiểm tra xem trình duyệt này có hỗ trợ khối lệnh kia hay không, và chạy lệnh khác tuỳ thuộc vào câu trả lời là có hay không, để các trình duyệt luôn hoạt động thay vì oẳng hoặc báo lỗi. Bài viết này hướng dẫn chi tiết bạn cách viết bộ nhận diện tính năng một cách đơn giản, cách dùng thư viện để tăng tốc hiện thực nó, và các tính năng dựng sẵn dành dành cho bộ nhận diện tính năng như @supports.
-
Tự động hoá kiểm thử
-
Tiến hành kiểm thử bằng tay trên nhiều trình duyệt và thiết bị, liên tục nhiều ngày, có thể gây ra chán nản và tốn tohừi gian. Để gia tăng hiệu suất kiểm thử, bạn nên làm quen với một vài công cụ tự động. Trong bài viết này, ta sẽ nghiên cứu công cụ nào dùng được, cách chạy công việc, và cơ bản cách dùng ứng dụng kiểm thử tự động thương mại (tốn phí) như Sauce Labs và Browser Stack.
-
Cấu hình môi trường kiểm thử tự động của riêng mình
-
Trong bài viết này, chúng tôi sẽ dạy bạn cách cài đặt môi trường tự động cho riêng mình và chạy test trên Selenium/WebDriver và thư viện kiểm thử như selenium-webdriver cho Node. We will also look at how to integrate your local testing environment with commercial apps like the ones discussed in the previous article.
-
diff --git a/files/vi/learn/tools_and_testing/cross_browser_testing/introduction/index.html b/files/vi/learn/tools_and_testing/cross_browser_testing/introduction/index.html deleted file mode 100644 index aedc41104b..0000000000 --- a/files/vi/learn/tools_and_testing/cross_browser_testing/introduction/index.html +++ /dev/null @@ -1,201 +0,0 @@ ---- -title: Giới thiệu về kiểm tra trình duyệt chéo -slug: Learn/Tools_and_testing/Cross_browser_testing/Introduction -translation_of: Learn/Tools_and_testing/Cross_browser_testing/Introduction ---- -
{{LearnSidebar}}
- -
{{NextMenu("Learn/Tools_and_testing/Cross_browser_testing/Testing_strategies", "Learn/Tools_and_testing/Cross_browser_testing")}}
- -

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, CSS và JavaScript.
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:

- - - -

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ì:

- - - -

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:

- - - -

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. -
  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. -
  3. Kiểm thử trên thiết bị di động, như Android hoặc iOS.
    4. -
- -

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:

- - - -

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à:

- - - -

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 Labs và Browser 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 {{anch("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.

- -

{{NextMenu("Learn/Tools_and_testing/Cross_browser_testing/Testing_strategies", "Learn/Tools_and_testing/Cross_browser_testing")}}

- -

Trong loạt bài này

- - diff --git a/files/vi/learn/tools_and_testing/cross_browser_testing/testing_strategies/index.html b/files/vi/learn/tools_and_testing/cross_browser_testing/testing_strategies/index.html deleted file mode 100644 index 6fee4b39fa..0000000000 --- a/files/vi/learn/tools_and_testing/cross_browser_testing/testing_strategies/index.html +++ /dev/null @@ -1,358 +0,0 @@ ---- -title: Strategies for carrying out testing -slug: Learn/Tools_and_testing/Cross_browser_testing/Testing_strategies -translation_of: Learn/Tools_and_testing/Cross_browser_testing/Testing_strategies ---- -
{{LearnSidebar}}
- -
{{PreviousMenuNext("Learn/Tools_and_testing/Cross_browser_testing/Introduction","Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS", "Learn/Tools_and_testing/Cross_browser_testing")}}
- -

Bài viết này cung cấp khái quát về kiểm thử trình duyệt chéo, trả lời các câu hỏi như là "kiểm thử trình duyệt chéo là gì?", "các sự cố mà bạn sẽ thường gặp?", và "các hướng tiếp cận chính để kiểm thử, xác định và vá lỗi là gì?"

- - - - - - - - - - - - -
Điều kiện tiên quyết:Thành thạo ngôn ngữ HTML, CSS, và JavaScript; biết chút về lý thuyết kiểm thử trình duyệt chéo.
Mục tiêu:Hiểu được lý thuyết nâng cao về kiểm thử trình duyệt chéo.
- -

Có nên kiểm thử tất tần tật?

- -

Khi kiểm thử trình duyệt chéo, bạn cần lên một danh sách trình duyệt cần kiểm thử. Bạn sẽ không thể kiểm thử trên mọi trình duyệt và thiết bị mà người dùng sử dụng - bởi lẽ có vô vàn các loại trình duyệt và thiết bị, và phiên bản mới cũng như thiết bị mới được ra mắt liên tục.

- -

Thay vì thế, bạn nên cố gắng đảm bảo trang web của mình sẽ hoạt động trên các trình duyệt và thiết bị mục tiêu, và viết mã một cách phòng thủ để trang web của bạn đạt được sự tương thích mong muốn nhất.

- -

"Viết mã một cách phòng thủ" tức là dựng fallback thông minh để nếu có tính năng hoặc style nào đó không hoạt động trên trình duyệt này, trang web có thể dùng phương thức hoặc thuộc tính cấp thấp hơn để đạt được trải nghiệm người dùng chấp nhận được — chẳng hạn như các thông tin lõi vẫn truy cập được, mặc dù giao diện có thể không đẹp lắm.

- -

Mục đích của chúng ta là dựng biểu đồ thể hiện sự tương thích giữa các trình duyệt/ thiết bị trong lúc bạn kiểm thử. Bạn có thể làm nó phức tạp hay đơn giản tuỳ thích — chẳng hạn, bạn có thể đặt ra các cấp độ hỗ trợ khác nhau, như sau:

- -
    -
  1. Cấp A: Trình duyệt hiện đại/ phổ biến — Có khả năng. Kiểm thử tất cả và cung cấp đầy đủ tính năng.
    2. -
  2. Cấp B: Trình duyệt cũ/ ít sử dụng — Không đủ khả năng. Kiểm thử, và cung cấp trải nghiệm cơ bản bao gồm truy cập được các thông tin và dịch vụ cốt lõi.
    3. -
  3. Cấp C: Trình duyệt hiếm gặp/ không biết — không kiểm thử, nhưng cho là có khả năng. Chạy được cả trang, chí ít là được với giải pháp dự phòng (fallback) đã được cài trong lúc viết mã nguồn một cách phòng thủ.
    4. -
- -

Trong phần tiếp theo, ta sẽ dựng biểu đồ tương thích theo mẫu này.

- -
-

Ghi chú: Yahoo là đơn vị đầu tiên khiến phương pháp tiếp cận này nổi tiếng, với phương pháp Graded browser Support.

-
- -

Phán đoán có cơ sở

- -

Có thể gọi đây là "giả định", hoặc "linh cảm". Đây không phải hướng tiếp cận khoa học, chính xác, nhưng là một người có kinh nghiệm trong ngành ứng dụng web, bạn sẽ nắm được vài trình duyệt nên kiểm thử. Điều này có thể tạo thành nền tảng tốt cho biểu đồ tương thích.

- -

Chẳng hạn, nếu bạn sống ở Tây Âu hoặc Bắc Mĩ, bạn sẽ biết có khá nhiều người sử dụng máy bàn(desktop) và máy tính xách tay (laptop) chạy Windows hoặc Mac, với trình duyệt chính là Chrome, Firefox, Safari, IE, và Edge. Bạn nên kiểm thử trên phiên bản mới nhất của 3 trình duyệt đầu tiên, bởi chúng thường được cập nhật liên tục. Với Edge và IE, bạn nên kiểm thử vài phiên bản gần đây; gom tất cả đống trên lại ta sẽ được cấp A.

- -
-

Ghi chú: Bạn chỉ cài đặt được duy nhất một phiên bản của IE hoặc Edge trên mỗi máy tính, bởi vậy bạn sẽ phải dùng đến máy ảo, hoặc áp dụng chiến lược kiểm thử khác nếu cần. Phần {{anch("Virtual machines")}} tiếp theo sẽ giải thích cặn kẽ hơn.

-
- -

Kha khá nhiều người dùng iOS và Android, nên bạn cũng cần kiểm thử trên phiên bản mới nhất của iOS Safari, vài phiên bản gần đây của stock browser trên Android, và Chrome và Firefox cho iOS và Android. Nếu được, hãy kiểm thử trên cả điện thoại lẫn máy tính bảng (tablet), để đảm bảo thiết kế linh hoạt (responsive design) hoạt động OK.

- -

Bạn cũng nên biết rằng có nhiều người dùng IE 9. Trình duyệt này cũ và yếu đuối hơn, nên hãy xếp nó vào cấp B.

- -

Từ đây ta xây dựng được biểu đồ tương thích như sau:

- -
    -
  1. Cấp A: Chrome và Firefox cho Windows/Mac, Safari cho Mac, Edge và IE cho Windows (hai phiên bản gần đây nhất của mỗi loại), iOS Safari cho iPhone/iPad, stock browser cho điện thoại/ máy tính bảng chạy Android (hai phiên bản gần đây nhất) on phone/tablet, Chrome và Firefox cho điện thoại/ máy tính bảng chạy Android (hai phiên bản gần nhất)
    2. -
  2. Cấp B: IE 9 cho Windows
    3. -
  3. Cấp C: n/a
    4. -
- -

Nếu bạn sống ở vùng khác, hoặc đang xây dựng trang web để phục vụ vùng khác (như vùng lãnh thổ khác), thì trình duyệt phổ biến để kiểm thử sẽ khác đi ít nhiều.

- -
-

Ghi chú: "CEO của công ty tao xài Blackberry, nên bọn tao phải làm web chạy mượt trên đó" cũng là một ý tưởng thuyết phục.

-
- -

Chỉ số tương thích trình duyệt

- -

Một trong những tiêu chí để xem xét lựa chọn trình duyệt kiểm thử có thể đưa ra là chỉ số tương thích trình duyệt. Có nhiều trang cung cấp chỉ số này, chẳng hạn:

- - - -

Cả hai trang đều lấy dữ liệu ở trung tâm Bắc Mĩ, không hoàn toàn chính xác, nhưng chúng có thể cho bạn biết chút ít về xu hướng hiện hành.

- -

Chẳng hạn, hãy vào Netmarketshare. Như bạn có thể thấy, Opera được xếp trong danh sách ít nhưng vẫn có người sử dụng, ta nên xếp nó vào cấp C trong biểu đồ tương thích ở trên.

- -

IE8 cũng được xếp vào mục rất ít, nhưng nó cũ và không thể chạy nổi được mấy. Opera Mini cũng vậy, nhưng vẫn đủ khả năng thực thi mã nguồn JavaScript phức tạp trong lúc thời gian chạy, vân vân (xem Opera Mini and JavaScript để biết thêm chi tiết). Ta cũng nên sắp nó vào cấp B.

- -

Phân tích

- -

Nguồn dữ liệu chính xác hơn, nếu bạn có thể lấy được, thường tới từ các ứng dụng phân tích như Google Analytics. Đây là ứng dụng cung cấp cho bạn chỉ số chính xác về loại trình duyệt mà người dùng sử dụng để truy cập vào trang web của bạn. Tất nhiên, cách này chỉ áp dụng được khi bạn đã có sẵn một trang web đang hoạt động, nên hướng tiếp cận này sẽ không thích hợp với các trang web hoàn toàn mới.

- -

Nhưng lịch sử phân tích có thể cũng hữu dụng để tìm ra chỉ số tương thích cho một trang web mới hoàn toàn, hoặc cho một tính năng sắp sửa được thêm vào trang web đã tồn tại. Những dữ liệu này có độ chính xác cao hơn các chỉ số được tổng hợp toàn cầu như hai trang kể trên.

- -

Ngoài ra, bạn cũng có thể dùng các nền tảng phân tích dữ liệu mã nguồn mở như Open Web Analytics và Matomo. Để sử dụng được chúng, bạn phải tự dựng lên máy chủ của mình (self-host). 

- -

Thiết lập Google analytics

- -
    -
  1. Trước hết, bạn cần có tài khoản Google. Dùng tài khoản này để đăng nhập vào Google Analytics.
    2. -
  2. Chọn tuỳ chọn web Google Analytics, và nhấn vào nút Sign Up.
    3. -
  3. Nhập chi tiết trang web/ ứng dụng của bạn trên trang đăng ký. Form nhập liệu tại đây khá trực quan; trường thông tin quan trọng nhất phải điền đúng là URL của trang Web. Hãy đảm bảo lấy đúng URL gốc.
    4. -
  4. Ngay khi đã nhập xong mọi thứ, nhấn nút Get Tracking ID, rồi chọn tiếp chấp nhận điều khoản dịch vụ.
    5. -
  5. Trang tiếp theo cung cấp cho bạn vài đoạn mã nguồn kèm theo chú giải. Với trang web đơn giản, bạn chỉ cần sao chép đoạn mã nguồn Website tracking và dán nó vào mã nguồn của mọi trang bạn muốn theo dõi bằng Google Analytics. Bạn có thể đặt nó ngay dưới thẻ </body>, hoặc ở chỗ nào đó để tách biệt so với mã nguồn gốc trên ứng dụng của mình.
    6. -
  6. Tải những thay đổi trên lên kho mã nguồn phát triển của bạn, hoặc bất cứ nơi đâu tuỳ ý.
    7. -
- -

Vậy là xong! Trang web của bạn giờ đã sẵn sàng để báo cáo dữ liệu phân tích rồi.

- -

Nghiên cứu dữ liệu phân tích

- -

Giờ hãy quay lại trang chủ của Analytics Web, và bắt đầu theo dõi dữ liệu bạn vừa thu thập được trên trang Web của mình (tất nhiên bạn cần dành ra chút thời gian để thu thập dữ liệu.)

- -

Theo mặc định, bạn sẽ thấy một tab báo cáo như sau:

- -

- -

Như bạn thấy đó, có hàng tá dữ liệu khi dùng Google Analytics — thông báo tuỳ chỉnh theo từng đề mục, vân vân — và ta không có nhiều thời gian để bàn luận về tất cả. Getting started with Analytics cung cấp vài chỉ dẫn hữu ích cho người mới khi tương tác với những báo cáo này.

- -

Bạn cũng nên xem xét các tuỳ chọn khác nhau ở phía bên trái, và lọc ra dữ liệu cần dùng. Chẳng hạn, bạn có thể tìm trình duyệt và hệ điều hành mà người dùng sử dụng bằng cách tích chọn Audience > Technology > Browser & OS từ menu bên trái.

- -
-

Ghi chú: Khi sử dụng Google analytics, bạn cần cẩn trọng trước những dự đoán không rõ ý, chẳng hạn "Chúng ta không có người dùng trên Firefox Mobile" thường khiến bạn không hỗ trợ Firefox mobile nữa. Nhưng bạn sẽ không có người dùng nào trên Firefox Mobile nếu ngay từ đầu trang Web của bạn đã không hoạt động trên đó.

-
- -

Một vài đề xuất khác

- -

Bạn cũng nên xem xét một vài khía cách khác. Bạn nên đưa khả năng tiếp cận như là yêu cầu kiểm thử cấp A (chúng tôi sẽ viết rõ hơn về những thứ bạn cần kểm thử trong bài "Xử lý sự cố tiếp cận thường gặp")

- -

Vả lại bạn cũng cần xem xét thêm các yếu tố môi trường. Nếu bạn viết ứng dụng cho mạng Intranet của một công ty nào đó, nhằm dựng biểu đồ thống kê đơn bán lẻ cho quản lý, và tất cả các quản lý đều được phát cho một chiếc điện thoại cài hệ điều hành Windows, lúc này bạn sẽ phải đưa IE vào danh mục hỗ trợ hàng đầu.

- -

Biểu đồ tương thích bản cuối

- -

Sau tất cả, biểu đồ tương thích của chúng ta sẽ có dạng như sau:

- -
    -
  1. Cấp A: Chrome và Firefox cho Windows/Mac, Safari cho Mac, Edge và IE cho Windows (hai phiên bản gần đây nhất cho mỗi loại), iOS Safari cho iPhone/iPad, Android stock browser (hai phiên bản gần đây nhất) cho điện thoại/ máy tính bảng, Chrome và Firefox cho Android (hai phiên bản gần đây nhất) cho điện thoại/ máy tính bảng. Qua được kiểm thử khả năng tiếp cận thông thường.
    2. -
  2. Cấp B: IE 8 và 9 cho Windows, Opera Mini.
    3. -
  3. Cấp C: Opera, và một số trình duyệt hiện đại kém phổ biến khác.
    4. -
- -

Bạn định kiểm thử cái gì?

- -

Khi bạn muốn kiểm thử phần mã nguồn mới thêm vào, trước khi bắt đầu tiến hành, bạnn nên lập một danh sách yêu cầu kiểm thử mà buộc phải qua được thì mới được chấp nhận. Những yêu cầu này có thể thuộc chức năng hoặc thẩm mĩ - kết hợp hai yêu cầu này lại sẽ thành một chức năng khả dùng cho trang web của bạn.

- -

Hãy xem xét ví dụ sau (xem mã nguồn, và bản chạy trực tiếp):

- -

- -

Các hạng mục kiểm thử cho ví dụ này được trình bày như sau:

- -

Cấp A và B:

- - - -

Cấp A:

- - - -

Nếu để ý, bạn sẽ thấy văn bản trong ví dụ không chạy được trên IE8 — sự cố này đã được liệt kê trong bảng tương thích của chúng ta, mà bạn sẽ phải làm theo, có lẽ bạn sẽ phải dùng thư viện nhận diện tính năng để cài đặt lại tính năng đó sao cho phù hợp với các trình duyệt không hỗ trợ CSS transition (xem Hiện thực bộ nhận diện tính năng ở bài viết sau).

- -

Chắc bạn cũng ddể ý rằng nút bấm không dùng được nếu chỉ sử dụng bàn phím - điều này cũng phải xem xét lại. Có lẽ ta nên dùng vài dòng lệnh JavaScript để cho phép bàn phím kiểm soát hoạt động của nút đảo chiều, hoặc dùng phương thức khác thay thế luôn?

- -

Các thông số kiểm thử này rất hữu dụng, vì:

- - - -

Xây dựng phòng thí nghiệm kiểm thử

- -

Một trong các phương thức tiếp cận kiểm thử là tự kiểm thử bằng tay. Để làm được việc này, bạn sẽ phải kết hợp giữa kiểm thử trên một số thiết bị vật lý thực, và trên môi trường ảo hoá (dùng cả bộ giả lập cũng như máy ảo).

- -

Thiết bị vật lý

- -

Việc kiểm thử trên thiết bị thật chạy trình duyệt thường tốt hơn bao giờ hết, việc này cho ra kết quả chính xác nhất thoả mãn các hành vi cũng như trải nghiệm của người dùng. Để phục vụ một phòng thí nghiệm cỡ nhỏ, bạn sẽ cần những thiết bị sau đây:

- - - -

Nếu có thể thì bạn nên đầu tư thêm:

- - - -

Máy tính chính của bạn cũng có thể dùng làm chỗ cài đặt một số công cụ chuyên biệt, như công cụ kiểm toán khả năng tiếp cận, bộ đọc màn hình, và máy ảo/giả lập.

- -

Đối với các công ty lớn, phòng thí nghiệm của họ có nhiều loại thiết bị thuộc nhiều mẫu mã khác nhau, cho phép nhà phát triển tìm diệt lỗi trên các trình duyệt và thiết bị chuyên biệt. Các công ty nhỏ và các cá nhân thường không đủ vốn để đua theo nên họ thường sử dụng máy ảo, các bộ giả lập và các ứng dụng kiểm thử thương mại.

- -

Ta sẽ đi sơ qua từng lựa chọn này phía dưới.

- -
-

Ghi chú: Some efforts have been made to create publically accessible device labs — see Open Device Labs.

-
- -
-

Ghi chú: Ta cũng phải xem xét khả năng tiếp cận - có khá nhiều công cụ hữu dụng mà bạn có thể cài đặt lên máy của mình phục vụ cho quá trình kiểm thử khả năng tiếp cận, nhưng ta sẽ bàn về chúng trong bài viết "Xử lý sự cố tiếp cận thường gặp", trong loạt bài này.

-
- -

Giả lập

- -

Giả lập là phần mềm chạy trong máy tính của bạn và giả lập một thiết bị nào đó, cho phép bạn thoải mái kiểm thử thay vì phải tìm chính xác phần cứng/ phần mềm tương ứng.

- -

Giả lập thường dùng để kiểm thử trạng thái của thiết bị. Chẳng hạn, nếu bạn muốn kiểm tra nhanh chiều dài và bề rộng của thiết bị có phù hợp với thiết kế linh hoạt (responsive design) của mình hay không, bạn có thể dùng Responsive Design Mode của Firefox. Safari cũng có chế độ tương tự, mà ta có thể dùng tới bằng cách vào Safari > Preferences, và chọn Show Develop menu, rồi chọn Develop > Enter Responsive Design Mode. Chrome cũng có chế độ tương tự: Device mode (xem Simulate Mobile Devices with Device Mode). 

- -

Bạn sẽ phải cài đặt vài bộ giả lập. Các trình duyệt/ thiết bị bạn sẽ thường muốn kiểm thử như sau:

- - - -

Bạn cũng có thể dùng bộ giả lập cho môi trường thiết bị di động khác như:

- - - -
-

Ghi chú: Một số bộ giả lập đòi hỏi phải chạy máy ảo (xem bên dưới); thường sẽ có hướng dẫn đi kèm về cách cài đặt và sử dụng máy ảo để giả lập.

-
- -

Máy ảo

- -

Máy ảo là ứng dụng chạy trên máy tính cá nhân và cho phép bạn chạy giả lập của toàn bộ hệ điều hành, mỗi máy ảo được ngăn cách trên chính ổ cứng ảo của nó (thường biểu diễn dưới dạng một tệp tin lớn trên ổ cứng của máy thật). Có khá nhiều ứng dụng chạy máy ảo nổi tiếng, như là Parallels, VMWare, và Virtual Box; cá nhân người viết bài thích Virtual Box hơn vì nó miễn phí.

- -
-

Ghi chú: Bạn cần rất nhiều dung lượng ổ cứng để chạy máy ảo; mỗi hệ điều hành mà bạn giả lập lên đều ngốn khá nhiều bộ nhớ. Tất nhiên, bạn được chọn dung lượng ổ cứng cài đặt cho máy ảo; có thể chỉ giới hạn 10GB thôi, nhưng một số hệ điều hành đòi hỏi phải có ít nhất 50GB mới chạy ổn định được. Một trong những lựa chọn tối ưu cho hầu hết ứng dụng máy ảo là tạo ổ cứng cấp phát động tự tăng/giảm dung lượng khi cần.

-
- -

Để dùng Virtual Box, bạn cần:

- -
    -
  1. Kiếm bộ cài hoặc ảnh (tức là tệp ISO) chứa hệ điều hành bạn muốn giả lập. Virtual Box không tự cung cấp những tệp tin này; hầu hết các hệ điều hành, như Windows, là sản phẩm thương mại hoá nên không thể phân phối tự do.
    2. -
  2. Tải bộ cài đặt thích hợp cho hệ điều hành trên máy thật và cài đặt nó.
    3. -
  3. Mở ứng dụng lên; giao diện hiện ra như hình:
    4. -
  4. Để tạo máy ảo mới, nhấn nút New ở góc trên cùng bên trái.
    5. -
  5. Làm theo hướng dẫn và điền vào hộp thoại các thông tin như: -
      -
    1. Tên cho máy ảo mới
      2. -
    2. Chọn hệ điều hành và phiên bản muốn cài đặt
      3. -
    3. Đặt giới hạn RAM (chúng tôi đè nghị 2048MB, hoặc 2GB)
      4. -
    4. Tạo ổ cứng ảo (giữ nguyên lựa chọn mặc định trong hộp thoại chứa Create a virtual hard disk now, VDI (virtual disk image), và Dynamically allocated).
      5. -
    5. Chọn đường dẫn đến tệp tin và kích thước của ổ cứng ảo (chọn tên và nơi chứa dễ nhớ, nơi chứa nên có đủ không gian nhớ sao cho thích hợp với yêu cầu, ít nhất 50GB).
      6. -
    -
    6. -
- -

Lúc này, virtual box sẽ hiện ra trên thanh công cụ bên trái của giao diện Virtual Box. Giờ bạn có thể nhấp đúp chuột vào virtual box — nó sẽ khởi động máy ảo lên, nhưng chưa có hệ điều hành đâu nhé. Bạn phải chọn ảnh/bộ cài của hệ điều hành và virtual box sẽ chạy từng bước cài đặt lên máy ảo, như thể đang cài đặt trên máy thật.

- -

- -
-

Lưu ý: Bạn cần xác định rõ hệ điều hành bạn muốn cài lên máy ảo vào lúc này. Nếu bạn huỷ tiến trình vào lúc này, nó sẽ khiến máy ảo không dùng được, và bạn sẽ phải xoá máy ảo đi và tạo lại mới. Việc này tuy không ảnh hưởng gì nghiêm trọng nhưng gây ra khó chịu.

-
- -

Sau khi tiến trình chạy xong, bạn sẽ một máy ảo chạy hệ điều hành trên máy thật.

- -

- -

Hãy dùng hệ điều hành ảo như thể dùng hệ điều hành thực - ví dụ, cài đặt trình duyệt bạn muốn kiểm thử vào, cài đặt phần mềm diệt vi-rut để bảo vệ nó.

- -

Có nhiều máy ảo cùng lúc cũng cực kỳ tiện, chẳng hạn bạn muốn kiểm thử Windows IE/Edge — trên Windows, bạn không thể cài đặt cùng lúc nhiều phiên bản của trình duyệt này, nên bạn sẽ phải dựng một bộ máy ảo để thử nghiệm từng chức năng trên các phiên bản khác nhau, như là:

- - - -
-

Ghi chú: Một ưu điểm nữa của máy ảo là ổ cứng ảo khá là độc lập. Nếu bạn làm việc trong một đội, bạn có thể tạo ra một ổ cứng ảo, rồi sao chép nó đi khắp nơi. Nếu hệ điều hành cài trên máy ảo là sản phẩm có giấy phép thì bạn phải đảm bảo cung cấp đầy đủ giấy phép cho từng máy ảo.

-
- -

Ứng dụng tự động và thương mại hoá

- -

Như đã đề cập ở chương trước, bạn sẽ bớt lo ngại khi kiểm thử trình duyệt bằng cách dùng một số hệ thôgns tự động. Bạn có thể tự thiết lập chúng (một trong số những ứng dụng nổi tiếng nhất là Selenium), tuy cũng tốn chút công sức, nhưng kết quả đổi lại rất đáng.

- -

Ngoài ra, bạn có thể dùng các ứng dụng thương mại hoá như Sauce Labs, Browser Stack và LambdaTest sẽ thiết lập giúp bạn nếu bạn sẵn sàng chịu đầu tư để kiểm thử.

- -

Ta sẽ đi vào chi tiết cách dùng các công cụ này ở bài tương ứng.

- -

Kiểm thử phía người dùng

- -

Trước khi sang bài mới, ta sẽ tìm hiểu sơ qua về kiểm thử phía người dùng — đây có thể là lựa chọn tốt nếu bạn có một nhóm người dùng sẵn sàng kiểm thử tính năng mới cho mình. Việc lựa chọn người dùng tham gia kiểm thử hoàn toàn tuỳ theo ý bạn - có thể là một nhóm bạn, nhóm đồng nghiệp, hoặc nhóm tình nguyện viên có phí hoặc miễn phí, tuỳ theo lượng tiền bạn có thể chi trả.

- -

Thông thường bạn sẽ cho người dùng xem trang hoặc một đoạn chứa chức năng mới trên máy chủ phát triển, để thay đổi không tác động đến phiên bản ứng dụng chính của bạn. Bạn nên bắt họ kiểm thử theo từng bước và báo cáo lại kết quả họ nhận được. Sẽ tiện hơn nếu bạn có sẵn một tập các bước (đôi khi gọi là kịch bản) để kết quả kiểm thử gần hơn với cái bạn muốn kiểm thử. Ta vừa đề cập tới điều này ở mục {{anch("What are you going to test")}} phía trên. Chẳng hạn, các bước sau phù hợp với một người dùng có thị giác:

- - - -

Trong lúc kiểm thử, cũng nên làm (nếu điều kiện cho phép) các việc như:

- - - -

Việc thực hiện các bước trên nhằm đảm bảo sự "thuần khiết" cho trình duyệt, tức là không có bất cứ thứ gì ảnh hưởng tới kết quả của việc kiểm thử.

- -
-

Ghi chú: Nếu bạn có điều kiện về phần cứng, bạn nên thử chạy ứng dụng của mình trên các thiết bị di động tầm thấp — bởi vì khi ứng dụng càng phát triển, càng có nhiều tính năng và các hiệu ứng, thì khả năng ứng dụng bạn chạy chậm hơn trên các thiết bị này càng cao hơn, bởi vậy bạn cũng phải suy tính tới hiệu năng của ứng dụng nhiều hơn. Vả lại, nếu các tính năng của bạn chạy ổn trên thiết bị tầm thấp, thì trải nghiệm người dùng chắc chắn sẽ khá hơn trên các thiết bị cao cấp hơn.

-
- -
-

Ghí chú: Một số môi trường phát triển phía-máy-chủ cung cấp cơ chế thiết lập thay đổi cho một tập người dùng nhất định, đảm bảo tập người dùng đó có thể kiểm thử các tính năng mới mà không ảnh hưởng tới các máy chủ khác. Chẳng hạn như Django Waffle Flags.

-
- -

Tóm lại

- -

Sau khi đọc bài viết này, giờ bạn đã nắm chắc ý tưởng để xác định danh sách khách hàng mục tiêu/ trình duyệt mục tiêu, và tiến hành kiểm thử chéo trên danh sách này sao cho hiệu quả.

- -

Next we'll turn our attention to the actual code issues your testing might uncover, starting with HTML and CSS.

- -

{{PreviousMenuNext("Learn/Tools_and_testing/Cross_browser_testing/Introduction","Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS", "Learn/Tools_and_testing/Cross_browser_testing")}}

- -

Trong loạt bài viết này

- - diff --git a/files/vi/learn/tools_and_testing/index.html b/files/vi/learn/tools_and_testing/index.html deleted file mode 100644 index a032697166..0000000000 --- a/files/vi/learn/tools_and_testing/index.html +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: Tools and testing -slug: Learn/Tools_and_testing -tags: - - Accessibility - - Automation - - Beginner - - CSS - - CodingScripting - - HTML - - JavaScript - - Landing - - Learn - - NeedsTranslation - - Testing - - Tools - - Topic - - TopicStub - - cross browser - - user testing -translation_of: Learn/Tools_and_testing ---- -
{{LearnSidebar}}
- -

Once you've started to become comfortable programming with core web technologies (like HTML, CSS, and JavaScript), and you start to get more experience, read more resources, and learn more tips and tricks, you'll start to come across all kind of tools, from ready-rolled CSS and JavaScript, to testing and automation apps, and more besides. As your web projects become larger and more complex, you'll want to start taking advantage of some of these tools, and working out reliable testing plans for your code. This part of the learning area aims to give you what you need get started and make informed choices.

- -

The web industry is an exciting place to work, but it is not without its complications. The core technologies we use to build web sites are fairly stable now, but new features are being added all the time, and new tools — that facilitate working with, and are built on top of these technologies — are constantly appearing. On top of that, we still need to keep cross-browser support in the forefront of our minds, and make sure that our code follows best practices that allow our projects to work across different browsers and devices that our users are using to browse the Web, and be usable by people with disabilities.

- -

Working out what tools you should be using can be a difficult process, so we have written this set of articles to inform you of what types of tool are available, what they can do for you, and how to make use of the current industry favourites.

- -
-

Note: Because new tools appear and old ones go out of fashion all the time, we have deliberately written this material to be as neutral as possible — we want to focus first and foremost on the general types of tasks these tools will help you accomplish, and keep prescribing specific tools to a minimum. We obviously need to show tool usage to demonstrate specific techniques, but be clear that we do not necessarily recommend these tools as the best or only way to do things — in most cases there are other ways, but we want to provide you with a clear methodology that works.

-
- -

Learning pathway

- -

You should really learn the basics of the core HTML, CSS, and JavaScript languages first before attempting to use the tools detailed here. For example, you'll need to know the fundamentals of these languages before you start debugging problems in complex web code, or making effective use of JavaScript libraries, or writing tests and running them against your code using test runners, etc.

- -

You need a solid foundation first.

- -

Modules

- -
-
Real world web development tools (TBD)
-
In this module, we explore the different kinds of web development tools available. This includes reviewing the most common kinds of tasks you may be called on to solve, how they can fit together in a workflow, and the best tools currently avaiable for carrying out those tasks.
-
Cross browser testing
-
This module looks specifically at the area of testing web projects across different browsers. Here we look identifying your target audience (e.g. what users, browsers and devices do you most need to worry about?), how to go about doing testing, the main issues that you'll face with different types of code and how to fix/mitigate those, what tools are most useful in helping you test and fix problems, and how to use automation to speed up testing.
-
-- cgit v1.2.3-54-g00ecf