Kiểm tra bản địa hóa là gì? Các trường hợp kiểm thử mẫu & danh sách kiểm tra

Kiểm tra bản địa hóa

Kiểm tra bản địa hóa là một kỹ thuật kiểm thử phần mềm trong đó hoạt động của phần mềm được kiểm tra cho một khu vực, địa phương hoặc văn hóa cụ thể. Mục đích của việc thực hiện kiểm tra bản địa hóa cho một phần mềm là kiểm tra các khía cạnh ngôn ngữ và văn hóa phù hợp cho một địa phương cụ thể. Đó là quá trình tùy chỉnh phần mềm theo ngôn ngữ và quốc gia được nhắm mục tiêu.

Lĩnh vực chính bị ảnh hưởng bởi thử nghiệm bản địa hóa bao gồm nội dung và giao diện người dùng.

Đây là quá trình thử nghiệm một ứng dụng toàn cầu hóa có giao diện người dùng, ngôn ngữ mặc định, tiền tệ, định dạng ngày, giờ và tài liệu được thiết kế theo quốc gia hoặc khu vực được nhắm mục tiêu. Nó đảm bảo rằng ứng dụng có đủ khả năng để sử dụng ở quốc gia cụ thể đó.

Ví dụ:

1. Nếu dự án được thiết kế cho Bang Tamil Nadu ở Ấn Độ thì Dự án được thiết kế phải sử dụng ngôn ngữ Tamil, bàn phím ảo Tamil phải có, v.v.

2. Nếu dự án được thiết kế cho Hoa Kỳ thì định dạng thời gian phải được thay đổi theo giờ Tiêu chuẩn Hoa Kỳ. Ngoài ra, định dạng ngôn ngữ và tiền tệ phải tuân theo các tiêu chuẩn của Hoa Kỳ.

Hình minh họa bên dưới cho thấy cùng một sản phẩm được điều chỉnh cho các khu vực khác nhau, với ngôn ngữ, tiền tệ và quy tắc định dạng thay đổi trong khi cấu trúc cơ bản vẫn giữ nguyên.

Tại sao phải kiểm tra bản địa hóa?

Mục đích của việc thực hiện kiểm tra bản địa hóa là để kiểm tra các khía cạnh ngôn ngữ và văn hóa phù hợp cho một địa phương cụ thể. Nó bao gồm sự thay đổi trong giao diện người dùng hoặc thậm chí các cài đặt ban đầu theo yêu cầu.

Trong loại thử nghiệm này, nhiều người thử nghiệm khác nhau sẽ lặp lại các chức năng giống nhau. Họ xác minh nhiều thứ khác nhau như lỗi đánh máy, sự phù hợp về mặt văn hóa của giao diện người dùng, lỗi ngôn ngữ, v.v.

Nó còn được gọi là “L10N” vì có 10 ký tự nằm giữa chữ L và N trong từ “localization”.

Ngoài ra còn có lý do thương mại đằng sau nỗ lực này. Một nhãn mác dịch sai hoặc ngày tháng ghi 03/04 là tháng Ba thay vì tháng Tư sẽ làm xói mòn lòng tin vào thị trường mà nhóm đã bỏ tiền ra để thâm nhập, và những lỗi đó sẽ được phát hiện bởi người kiểm thử ở khu vực mục tiêu chứ không phải bởi chính nhóm phát triển. Kiểm tra GUI Được trình bày bằng tiếng Anh.

Kiểm thử bản địa hóa so với kiểm thử quốc tế hóa

Hai hoạt động này diễn ra tuần tự chứ không cạnh tranh nhau. Kiểm thử quốc tế hóa (I18N) xác nhận rằng cơ sở mã có thể chấp nhận bất kỳ ngôn ngữ địa phương nào; sau đó, kiểm thử bản địa hóa (L10N) xác nhận rằng một ngôn ngữ địa phương cụ thể là chính xác.

Kiểm thử bản địa hóa (L10N)	Kiểm tra quốc tế hóa (I18N)
Xác minh rằng sản phẩm mang lại trải nghiệm tự nhiên tại một khu vực mục tiêu cụ thể.	Xác minh rằng sản phẩm có thể hỗ trợ nhiều khu vực mà không cần phát triển lại.
Kiểm tra văn bản đã dịch, tiền tệ, ngày tháng, thời gian và sự phù hợp về văn hóa.	Kiểm tra mã hóa ký tự, việc tách chuỗi và mã nhận biết ngôn ngữ địa phương.
Chương trình này sẽ chạy một lần khi bản dựng đã được dịch cho thị trường đó đã tồn tại.	Chương trình này chạy trước khi bất kỳ văn bản nào được gửi đi để dịch.
Cần một người thử nghiệm hoặc người đánh giá biết ngôn ngữ địa phương.	Việc này có thể được thực hiện bởi nhóm nòng cốt bằng cách sử dụng các bản dựng được dịch giả.

Kiểm tra hướng dẫn này để sự khác biệt giữa kiểm thử bản địa hóa và kiểm thử toàn cầu hóa.

Cách thực hiện kiểm tra bản địa hóa

Đối với thử nghiệm bản địa hóa điển hình, chúng tôi thiết lập thử nghiệm xác minh bản dựng, Thử nghiệm chức năng, Kiểm tra hồi quyvà đăng xuất cuối cùng.

1. Thử nghiệm xác minh bản dựng là một tập hợp con của thử nghiệm chức năng, được thực hiện trước khi bộ phận QA bắt đầu bất kỳ hoạt động kiểm thử chi tiết nào. Về bản chất, nó gần giống với thử khóiBản dựng đã được bản địa hóa sẽ bị từ chối nhanh chóng nếu gói ngôn ngữ không tải được.

2. Kiểm tra thông thường là bước chạy các trường hợp kiểm thử thông thường và tìm ra lỗi nhật ký trong quá trình thực thi.

3. Kiểm tra hồi quy là Khiếm khuyết quá trình hồi quy để đảm bảo rằng khuyết tật được khắc phục trong khi không có tác động của khuyết tật cố định đến các khu vực xung quanh.

4. Phê duyệt cuối cùng là thực hiện kiểm tra lần cuối đối với bản dựng trước khi giao cho khách hàng.

Mỗi giai đoạn được lặp lại cho từng khu vực, chứ không phải chỉ một lần cho toàn bộ sản phẩm. Một lỗi được sửa trong bản dựng tiếng Pháp cũng sẽ tái diễn trong các bản dựng tiếng Đức và tiếng Nhật, vì cùng một tài nguyên chuỗi thường được chia sẻ giữa các bản dựng này.

Tự động hóa trong kiểm thử bản địa hóa

Nếu dự án lớn và cần kiểm tra thường xuyên thì chúng tôi sẽ thực hiện Kiểm tra tự động hóa.

• Chọn công cụ tự động hóa để viết script.
• Lấy kịch bản này làm thử nghiệm cho chiến lược bản địa hóa.
• Viết kịch bản theo đó.
• Thu thập kết quả và cập nhật kịch bản thành Đạt/Không đạt.

Lưu ý: Selenium là một trong những công cụ tiên phong trong lĩnh vực này. Nó rất giàu tính năng, tuy nhiên, nó đòi hỏi nhiều kiến ​​thức kỹ thuật hơn để sử dụng.

Tự động hóa có những hạn chế cần được nêu rõ. Một đoạn mã có thể chứng minh rằng ký hiệu tiền tệ đã thay đổi và không có chuỗi ký tự nào bị cắt ngắn, nhưng nó không thể đánh giá liệu bản dịch có tự nhiên hay không hoặc liệu một biểu tượng có gây khó chịu hay không. Việc kiểm tra bằng máy móc xử lý lớp kỹ thuật; người đánh giá bản ngữ vẫn xử lý lớp ngôn ngữ.

Công cụ kiểm thử bản địa hóa

Công việc bản địa hóa sử dụng ba loại công cụ khác nhau, và hầu hết các nhóm đều sử dụng cả ba loại.

• Các khung tự động hóa chức năng: Selenium, Appium và các khung công tác tương tự sẽ chạy lại cùng một bộ kiểm thử đối với từng bản dựng ngôn ngữ, đây là nơi diễn ra phần lớn quá trình xác minh lặp đi lặp lại.
• Hệ thống quản lý dịch thuật: Các nền tảng lưu trữ tài nguyên chuỗi ký tự giúp người dịch, nhà phát triển và người kiểm thử làm việc dựa trên một bảng thuật ngữ duy nhất, nhờ đó một thuật ngữ sẽ không bị dịch theo hai cách khác nhau trên hai màn hình khác nhau.
• Các tiện ích định vị giả: Những đoạn mã này thay thế các chuỗi tiếng Anh bằng các ký tự giữ chỗ có dấu và được kéo dài trước khi quá trình dịch thực sự bắt đầu, làm lộ ra văn bản và bố cục được mã hóa cứng không thể xử lý các từ dài hơn.

Khả năng tương thích với thiết bị và trình duyệt cũng quan trọng không kém công cụ. Phông chữ, phương thức nhập liệu và ngôn ngữ mặc định khác nhau giữa các nền tảng, vì vậy bản dựng được bản địa hóa cần được kiểm tra trên các thiết bị mục tiêu thực tế. thử nghiệm di động và trên toàn bộ trình duyệt được xác định cho kiểm tra ứng dụng web.

Danh sách kiểm tra các thực tiễn tốt nhất cho việc kiểm thử bản địa hóa

• Hãy thuê một công ty chuyên về bản địa hóa có kinh nghiệm trong lĩnh vực kỹ thuật i18n.
• Đảm bảo chiến lược thử nghiệm bản địa hóa của bạn dành nhiều thời gian hơn cho các ngôn ngữ byte kép.
• Hãy đảm bảo bạn đã quốc tế hóa mã của mình đúng cách cho hệ thống DBCS trước khi xuất khẩu.tracNhập bất kỳ văn bản nào để gửi đi dịch
• Trước tiên, hãy tách từng chuỗi ký tự ra thành các tệp tài nguyên riêng biệt, để không còn văn bản nào hiển thị cho người dùng bị mã hóa cứng trong mã nguồn.
• Hãy chạy bản dựng giả định bản địa hóa sớm, vì nó sẽ phát hiện ra hiện tượng cắt bớt văn bản và văn bản được mã hóa cứng trước khi chi tiền cho việc dịch thuật.
• Hãy chừa khoảng trống trên bố cục để mở rộng văn bản, vì các bản dịch từ tiếng Anh thường dài hơn nhãn gốc.
• Hãy thử nghiệm các ngôn ngữ viết từ phải sang trái như tiếng Ả Rập và tiếng Do Thái trên màn hình thực tế, nơi bố cục đảo ngược và văn bản viết theo hướng hỗn hợp thường gây lỗi.
• Hãy duy trì một bộ quy tắc định dạng riêng cho từng vùng miền, bao gồm thứ tự ngày tháng, dấu phân cách thập phân, định dạng địa chỉ, kính ngữ và giọng điệu.
• Hãy nhờ người bản ngữ xem lại các bản dựng cuối cùng, vì sự phù hợp về văn hóa không thể được khẳng định chỉ bằng kịch bản.

Hai trong số các mục đó phụ thuộc vào nền tảng chứ không phải ngôn ngữ, đó là lý do tại sao các bản dựng được bản địa hóa thường được lên lịch song song. kiểm tra tính tương thích và kiểm tra cấu hình thay vì theo đuổi họ.

Các trường hợp thử nghiệm mẫu để thử nghiệm bản địa hóa

Bảng dưới đây cung cấp một tập hợp các bước kiểm tra ban đầu. Mỗi hàng sẽ trở thành một bước kiểm tra hoàn chỉnh. trường hợp thử nghiệm sau khi đã điền đầy đủ kết quả mong muốn cho khu vực cụ thể đó.

S.No	Trường hợp thử nghiệm Description
1	Bảng thuật ngữ có sẵn để tham khảo và kiểm tra.
2	Ngày và giờ được định dạng chính xác cho vùng mục tiêu.
3	Định dạng số điện thoại phù hợp với khu vực mục tiêu.
4	Đơn vị tiền tệ cho khu vực mục tiêu.
5	Giấy phép và Quy tắc có tuân theo trang web (khu vực) hiện tại không.
6	Bố cục nội dung văn bản trong các trang không có lỗi, độc lập về phông chữ và căn chỉnh dòng.
7	Các ký tự đặc biệt, siêu liên kết và chức năng phím nóng.
8	Thông báo xác thực cho các trường đầu vào.
9	Bản dựng được tạo bao gồm tất cả các tệp cần thiết.
10	Màn hình được bản địa hóa có cùng loại phần tử và số như màn hình của sản phẩm nguồn.
11	Đảm bảo giao diện người dùng bản địa hóa của phần mềm hoặc ứng dụng web tương thích với giao diện người dùng nguồn trong hệ điều hành và môi trường người dùng đích.
12	Việc sắp xếp và theo thứ tự bảng chữ cái tuân theo quy tắc của ngôn ngữ đích, chứ không phải ngôn ngữ nguồn.
13	Các ngôn ngữ viết từ phải sang trái hiển thị bố cục chính xác, bao gồm cả thanh điều hướng, biểu tượng và chuỗi ký tự viết theo cả hai hướng.
14	Nhập liệu bằng bàn phím, kiểm tra chính tả và tìm kiếm chấp nhận các ký tự có dấu và ký tự đa byte.

Ưu điểm của thử nghiệm bản địa hóa

Sau đây là những lợi ích của thử nghiệm bản địa hóa

• Giảm chi phí thử nghiệm tổng thể
• Giảm chi phí hỗ trợ tổng thể
• Giúp giảm thời gian kiểm tra.
• Nó có tính linh hoạt và khả năng mở rộng hơn.

Những khoản tiết kiệm đó đến từ việc phát hiện các lỗi cục bộ một lần duy nhất, tập trung, thay vì một lần cho mỗi hàng đợi hỗ trợ thị trường. Khả năng truy cập thường được cải thiện theo sau, bởi vì cùng một nguyên tắc giúp giữ nguyên bố cục với các chuỗi tiếng Đức dài hơn cũng giúp giữ nguyên bố cục với văn bản được phóng to. kiểm tra khả năng tiếp cận.

Nhược điểm của thử nghiệm bản địa hóa

Sau đây là những thách thức của thử nghiệm bản địa hóa

• Yêu cầu một chuyên gia tên miền
• Thuê dịch giả địa phương thường làm cho quá trình này tốn kém
• Việc lưu trữ các ký tự DBCS khác nhau ở các quốc gia khác nhau
• Người thử nghiệm có thể phải đối mặt với những thách thức về lịch trình

Áp lực về tiến độ là điều mà hầu hết các nhóm đều đánh giá thấp. Việc dịch thuật thường diễn ra muộn trong chu kỳ, vì vậy các lỗi bản địa hóa thường xuất hiện gần thời điểm phát hành, chính xác là khi việc thay đổi bố cục tốn kém nhất. Việc lập kế hoạch bản địa hóa được đưa vào kế hoạch tổng thể rộng hơn được mô tả trong các loại kiểm thử phần mềm giúp kiểm soát được tình trạng khó khăn đó, và nhìn chung kiểm thử phần mềm Phần giới thiệu đề cập đến vị trí tổng thể của giai đoạn này.

Câu Hỏi Thường Gặp