Login  |  繁體中文
感謝您對「自由軟體鑄造場」的支持與愛護,十多年來「自由軟體鑄造場」受中央研究院支持,並在資訊科學研究所以及資訊科技創新研究中心執行,現已完成階段性的任務。 原網站預計持續維運至 2021年底,網站內容基本上不會再更動。本網站由 Denny Huang 備份封存。
也紀念我們永遠的朋友 李士傑先生(Shih-Chieh Ilya Li)。
Previous Issue

軟體市場國際化 I18N、L10N QA 問題漸受重視

軟體品質保證(QA, Quality Assurance)是軟體開發中的重要課題,QA 的目的在於在產品釋出前,相關錯誤的排除是否到了令人滿意的地步。

當國際化、地域化能力逐漸成為現今軟體開發成熟度的重要指標之一,有關 QA 問題也應運而生。國際化、地域化是針對國際市場進行軟體開發時,將必然涉及的重要程序。國際化,簡稱 I18N,該程序要求將程式碼修改為與特定文化資訊無關的形式,這些資訊可儲存於外部資料檔案,並於執行時期再行載入。

 

相對的,簡稱為 L10N 的地域化,是將軟體針對希望支援的語言進行客製化的程序,其中包含了文件、使用者界面的翻譯工作。軟體開發程序中的 QA,希望透過規劃、技術檢視前的時間與金錢付出,減少開發時期中的錯誤與更動。某些軟體公司更會邀請國內甚至是國外用戶參與設計階段。然而,當軟體產品面對國際市場,QA 工程師不能夠只是局限於此。他們必須開始考慮超過其自身國內經驗、常識的功能與軟體特性。國際化的 QA,特別著重檢測軟體產品的語言兼容能力,包括了測試軟體辨識、預置語言環境的行為,以及針對該環境的自訂能力。其中的白箱測試(white box)一般包含測試程式碼是否遵循 i18n 兼容標準。黑箱測試問(black box)會在不同語言環境中,執行整體的功能檢測,並與原生語言字串檢視界面的運作。此外,也要查看文化特定資訊的處理,如日期、時間顯示等等。

 

E.Uren 等人以美國程式設計者在 i18n 為例,舉出涉及 i18n 程序時,一開始可能犯下的基本錯誤,因此必須特別地著重這些地方。這些錯誤包括:字串寫死在程式碼中而非置於資源檔、熱鍵是否在資源檔中、對話盒或訊息視窗是否可動態調整大小、擴充字元是否做為文字界符、所有字元匯入匯出是否正確、案例轉換是否適當、排序遵循地區習慣、基本數字日期時間與貨幣格式為何等等。測試人員必須確定這些基本項目是否無誤。當軟體最終的地域化與轉譯程序告一段落,地域化 QA 也應該宣告完成。功能性並非這個步驟的考量重點,軟體使用界面文字翻譯是否適切才是本階段的檢測要項。此外,使用界面的佈局也是重點之一。對於一位美國當地的測試人員,和測試美國本土的產品相比,經過地域化程序的產品測試,將包含兩項額外的程序。首先,由於已經有先經過測試且功能完善的產品可供比對,可以在其它的產品上檢驗可疑的異常部份。其次是來自不同地域的資源檔案可以相互交換,例如說將德、法與英文的資源檔互換,如此大大有助於找出有問題的程式碼部份。

 

E.Uren 等人認為,在實際的地域化程序啟動前,可以先行測驗軟體的基本英文版本是否具備國際化或者地域化能力的相關特性。即早發現錯誤,有助於簡化修正程序與降低其成本,這是 QA 的信條之一。針對完成地域化的軟體版本,測試人員有必要測試安裝程序,以了解由於地域化造成容量改變的資源檔案,是否會產生問題。最好安排海外的單位進行 beta 測試。在地域化目標當地進行測試,有助於在更多樣化的電腦環境中檢測產品功能。除此之外,產品 i18n 支援與作業系統本身的支援間可能的衝突,也是必要的考慮項目。測試人員應當嘗試將在作業系統的不同地區版本上,測試應用程式的功能。由於產品地域化版本時程的緊縮,給了進行軟體地域化的人員不小的壓力。這些人員多半在產品最終版本完成前,便要開始地域化程序。軟體版本的不同,在最後整合時可能會產生一些問題,例如資源編號衝突等等。為了防止翻譯錯誤,翻譯程序必須任用該語言的當地人才(Native Speakers)。再者,該翻譯人員應該相當了解應用程式的用辭。翻譯檢驗的傳統方式是由編輯或校稿人,校閱翻譯結果。另外也可以由另一位翻譯人員將一部份翻譯文字譯回英文,以確知翻譯是否適當。超文字的使用為翻譯增添了一項測試項目。翻譯過程中錯誤的縮排與留白是較不易為人注意的部份,此外,熱鍵與引號也可能有誤置的情況發生。

相關網址:

1.國際化(I18N)與地域化(L10N)中的品質問題 https://www.tgpconsulting.com/articles/quality.html

2.軟體國際化簡介 > 之於軟體 QA 工程師 https://www.i18nfaq.com/qa.html




OSSF Newsletter : 第 5 期 中文化

Category: FOSS News