嘗試偽本地化測試以阻止常見的國際化缺陷。這是創建一個使用與英語相同的人工語言的本地化產品的過程。除了一點：各個字符是由一個不同的視覺上類似英文字符的字符寫入的。這應該完全由機器生成以便節省時間，偽本地化應該用與建本地化完全一樣的方法去建。甚至單語英語軟件開發者和測試員都可以讀取偽本地化文本，事實證明這是在開發早期發現國際化問題的一個很好的方法。開發早期，通過重點關注包括英語在內的五種語言優先找出國際化缺陷。經驗表明我們有可能找到以下語言的特定缺陷：
（1.）德語：它含有很長的單詞，比起其他語言，可以更好地揭示對話長短和對齊方式的缺陷。
（2.）日語：數萬字符，多個非拉丁腳本，非正統的輸入方法引擎以及一個相當復雜的拼字法。日語是一種很好的找出影響許多東亞語言的缺陷的方法
（3.）阿拉伯語：它是從右寫到左的，是上下文成型法，是一個字符的成形依賴于相鄰字符。
（4.）印度語：該語言可以幫助找到遺留的，非統一字符編碼的會影響所有語言的缺陷。
12.如果你知道用來開發產品的庫，那對他們的論壇和bug追蹤系統做些調查以找出限制和問題。這些是設計測試創意想法的良好來源。
13.找出有分類功能的區域。使用網絡瀏覽器來分類往往成問題。
14.測試自動化是你的朋友。盡可能使用數據驅動的測試自動化，但要注意：測試自動化框架能支持的內容或許會有限制。
管理缺陷
如果根據（現在已被代替的ISO/IEC 25010）ISO/IEC 9126-1和ISO/IEC 9126-2，按質量特點類別來記錄缺陷，那么國際化可能會歸類到輕便，而本地化可能會歸類到實用。將缺陷分類為質量保證（QA）團隊提供了有價值的統計資料以幫助他們評價整個軟件開發生命周期中現有流程的成功，并根據所學在將來建立項目。同時，確保團隊使用的缺陷追蹤系統支持所有其他系統支持的語言。開發到一半切換到電子表格只能增加不必要的手動管理和困難。此外，還建議讓所有支持的語言使用單一的管理系統，因為這樣可以簡化并提升報告效率。一旦各種語言的測試報告蜂擁而入，要有效管理這個相當困難了。別嘗試通過檢測單個bug并使用手動流程處理多語言bug報告，接著由擁有受影響組件的功能團隊手動一個接一個地翻譯，實時跟進。這是一個耗時且容易出錯的事兒，不適合大型且多變的項目。為缺陷追蹤工具創建一種（如其報告的一樣）能夠自動檢測用戶缺陷語言的語言檢測API。或只要讓報告者可以選擇語言行。如果缺陷追蹤工具能夠讓一個特定的團隊或個人根據特定領域的特定值提前提出缺陷，這樣的話這也能有所幫助。必須要存在并明確規定缺陷影響（嚴重性）來幫助快速優先處理缺陷。一般，項目使用四種嚴重級別。明確規定嚴重等級的例子可以很簡單，如下表中闡明地一樣。
總結
如你所見，一個瞄準國際受眾的產品并不總像一些人認為的那么簡單和便宜。犯錯的話會嚴重影響品牌，使你們在接下來的幾年成為一個笑柄。我們作為測試員要試著盡早參與其中，并說服利益相關者仔細規劃和分配充足的資金使之順利成功。
版權聲明：本文出自 SPASVO澤眾軟件測試網：http://www.eqie.com.cn/news/html/2015121145338.html
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。
