軟件測試培訓(xùn)講義-9特定類型的軟件測試.ppt

1、軟件測試培訓(xùn)講義,深圳市軟件行業(yè)協(xié)會培訓(xùn)中心,課程目的,了解軟件工程的基本概念和過程 了解軟件質(zhì)量定義和軟件質(zhì)量保證過程 深入掌握軟件測試原理、方法、過程 通過實戰(zhàn)掌握測試策略、技術(shù),第二部分 軟件測試的技術(shù)第九章 特定類型的軟件測試,面向?qū)ο筌浖臏y試,目的與內(nèi)容,理解什么是驗收測試 了解驗收測試的目標(biāo)和任務(wù) 了解驗收測試的過程,傳統(tǒng)的開發(fā)與測試（瀑布模型),需求描述 系統(tǒng)測試 總體設(shè)計 集成測試TESTING 功能性 分解 詳細(xì)設(shè)計 單元測試,傳統(tǒng)測試,系統(tǒng) 驗證系統(tǒng)滿足需求 集成 基于設(shè)計的結(jié)構(gòu) 自頂向下或者自下而上方法 單元測試 封裝的功能,OO 開發(fā) & 測試,基于行為的開發(fā) 由片段

2、復(fù)合成整體 經(jīng)常采用快速原型法 聯(lián)合使用增量化開發(fā)方法 沒有傳統(tǒng)的清晰的測試層次,面向?qū)ο蟮臏y試,系統(tǒng)層測試 與傳統(tǒng)方法相同 依舊基于需求描述 單元測試 采用兩個一般性的結(jié)構(gòu) 方法* 類 與傳統(tǒng)的方法（驅(qū)動與樁）相同,METHOD 2,METHOD 1,METHOD,METHOD,METHOD,METHOD,METHOD,OBJECT CLASS A,B,C,D,E,F,METHOD 2,METHOD 1,METHOD,METHOD,METHOD,METHOD,METHOD,OBJECT CLASS A,B,C,D,E,F,OO 集成測試,主程序最小化，所以沒有指導(dǎo)信息 OO測試中最復(fù)雜的部分

3、 基于自底向上復(fù)合的方法進(jìn)行測試 采用集群方法進(jìn)行測試 對象關(guān)系圖ORD 類的依賴關(guān)系 分支塊圖BBD 或者 有向圖顯示方法的依賴關(guān)系,meth1,meth3,meth2,Class 1,A,B,OUTPUT PORT EVENT,A,meth1,meth3,meth2,meth2,meth1,B,OUTPUT PORT EVENT,Class 2,Class 3,MM-Path,Message,1,2,3,OO概念/對測試的影響,封裝 多態(tài) 繼承,封裝,類的結(jié)構(gòu) 由公共方法定義接口 由作用在實例數(shù)據(jù)上的方法定義行為 信息隱藏,封裝對測試的影響,對變化后引起的連貫影響最小化 (在單元層次) 高

4、度非本地化 某一變化將導(dǎo)致相關(guān)的多個類進(jìn)行重新測試 測試的順序非常重要 (能夠減少測試工作量),METHOD,METHOD,CLASS A,CLASS B,CLASS C,METHOD,USES,USES,多態(tài),某一屬性可以有多個值 一個操作可以有多個方法來實現(xiàn) ( 如圖形方面) 重載 (type or number of variables) 動態(tài)綁定,OO 測試內(nèi)容,多態(tài) 是否你只需要測試一個變種 ? 你是否需要測試所有變種 ? 如果是，你是否需要測試所有層次 單元 “集成” 或 系統(tǒng)層次 驅(qū)動程序和樁程序可以重用,繼承結(jié)構(gòu),BASE,SUBCLASS,SINGLE,BASE,BASE,S

5、UBCLASS,SUBCLASS,SUBCLASS,BASE,MULTIPLE,MULTIPLE LEVELS,繼承,PARENT CLASS,MODIFIER,+,RESULT CLASS,繼承,A,B,C,M2,+,A,M1,+,B,C,A,M1,B,+,B,M2,+,C,繼承修改,沒有 (只有繼承的屬性) 添加新的屬性 重定義父親的屬性 虛擬屬性,對OO測試的影響,繼承 你是否完整地測試了所有的基類和派生類 ? 你是否測試了所有的基類并測試了所有子類重的修改 ? 在什么層次進(jìn)行測試? 測試的順序?,繼承測試,OO測試方法學(xué),JORGENSEN 和 ERICKSEN提出了5個層次 方法：單

6、元測試 消息：集成測試 事件：集成測試 線程測試：系統(tǒng)測試 線程交互測試：系統(tǒng)測試,定義,MM-PATH (METHOD MESSAGE - PATH) MESSAGE QUIESCENCE 由消息連接的執(zhí)行順序 由一條方法開始，并以一條不產(chǎn)生消息的方法結(jié)束,定義,ASF (ATOMIC SYSTEM FUNCTION) EVENT QUIESCENCE 代表一個輸入事件 跟隨MM-PATHS集合 由一個終止事件結(jié)束,meth1,meth3,meth2,Class 1,INPUT PORT EVENT,A,B,ASF INPUT PORT EVENT,OUTPUT PORT EVENT,A,m

7、eth1,meth3,meth2,meth2,meth1,B,ASF OUTPUT PORT EVENT,Class 2,Class 3,MM-Path,Message,1,2,3,ATM PIN ENTRY,CUSTOMER ENTERS CARD(EVENT) SCREEN REQUESTING PIN ENTRY IS DISPLAYED AN INTERLEAVED SEQUENCE OF DIGIT KEY TOUCHES WITH AUDIBLE AND VISUAL FEEDBACK POSSIBILITY OF CANCELLATION BY CUSTOMER SYSTEM D

8、ISPOSITION(VALID PIN OR CARD RETAINED),BANK,CARDSLOT,SECURITY,SCREEN,Keypad,SpecialKeypad,NumKeypad,getKeyEvents,parseKeyEvent,showMessage,pinForPan,checkPin,Screen,memberCard,ValidateCard,CardSlot,Bank,NumKeypad,Security,Customer inserts card,ASF Starts here,Message is displayed,ASF ends here,Key p

9、ushers,9.5.8面向?qū)ο髮崿F(xiàn)與面向?qū)ο鬁y試,一. OO程序設(shè)計語言和工具 將OOD結(jié)果 面向?qū)ο蟪绦?傳統(tǒng)OO語言和工具:Smalltalk C+ Object Pascal Java 高級OO語言和工具:Visual Basic (OO-4GL) PowerBuilder Delphi Power Objects Developer/2000,二. 面向?qū)ο鬁y試,四個層次 測試內(nèi)容 相當(dāng)與傳統(tǒng) 測試的階段,算法層,類層,類中每個方法,單元測試,類中方法和屬性的相互作用,主題層,一組協(xié)同工作的類的相互作用,系統(tǒng)層,完整系統(tǒng),組裝測試,子系統(tǒng)測試,單元測試,類的測試技術(shù)：可使用傳統(tǒng)技術(shù)

10、面向?qū)ο鬁y試的特殊問題 (1)測試類的實現(xiàn) 應(yīng)從各種可能的啟動操作的次序 組合中選出最可能發(fā)現(xiàn)屬性的操作 錯誤的若干中情況進(jìn)行測試。,(2)對子類展開測試 例：父類中定義:屬性 s 方法 f1，f2，f3 子類中定義:屬性 r 方法 f1，f4，f5 測試子類的內(nèi)容： 屬性 s, r 方法 f1，f2，f3 f4，f5,第二部分 軟件測試的技術(shù)第九章 特定類型的軟件測試,基于應(yīng)用服務(wù)器的測試,應(yīng)用服務(wù)器分類,從用途方面對服務(wù)器進(jìn)行分類： 應(yīng)用服務(wù)器 應(yīng)用服務(wù)器按具體的應(yīng)用再細(xì)分為WEB服務(wù)器、mail服務(wù)器、Telnet服務(wù)器、FTP服務(wù)器、光盤鏡像服務(wù)器、安全認(rèn)證服務(wù)器等等 數(shù)據(jù)庫服務(wù)器,應(yīng)

11、用服務(wù)器分類,從結(jié)構(gòu)對服務(wù)器進(jìn)行分類： C/S兩層 C/S三層 B/S兩層 B/S三層,C/S應(yīng)用服務(wù)器測試,客戶/服務(wù)器系統(tǒng)的分布性質(zhì)對軟件測試者帶來了一些獨特的問題： 客戶端GUI的考慮。 目標(biāo)環(huán)境及平臺多樣性的考慮。 分布數(shù)據(jù)庫的考慮(包括復(fù)制的數(shù)據(jù))。 分布處理的考慮(包括復(fù)制的處理)。 非魯棒的目標(biāo)環(huán)境。 非線性的性能關(guān)系。 必須以允許強(qiáng)調(diào)上面的每個問題的方式設(shè)計和C/S測試關(guān)聯(lián)的策略和戰(zhàn)術(shù),整體C/S測試策略,通常，客戶/服務(wù)器軟件的測試發(fā)生在三個不同的層次：(1)個體的客戶端應(yīng)用以“分離的”模式被測試不考慮服務(wù)器和底層網(wǎng)絡(luò)的運行；(2)客戶端軟件和關(guān)聯(lián)的服務(wù)器端應(yīng)用被一起測試，但

12、網(wǎng)絡(luò)運行不被明顯的考慮；(3)完整的C/S體系結(jié)構(gòu)，包括網(wǎng)絡(luò)運行和性能，被測試,整體C/S測試策略,雖然在上面的每個層次有很多不同類型的測試被進(jìn)行，下面的測試方法是C/S應(yīng)用中經(jīng)常遇到的： 應(yīng)用功能測試 服務(wù)器測試 數(shù)據(jù)庫測試 事務(wù)測試 網(wǎng)絡(luò)通信測試,整體C/S測試策略,應(yīng)用功能測試：用本書中前面討論的方法測試客戶端應(yīng)用的功能。在本質(zhì)上，應(yīng)用被獨立的測試，以揭示在其運行中的錯誤。 服務(wù)器測試：測試服務(wù)器的協(xié)調(diào)和數(shù)據(jù)管理功能，也考慮服務(wù)器性能(整體反應(yīng)時間和數(shù)據(jù)吞吐量)。 數(shù)據(jù)庫測試：測試服務(wù)器存儲的數(shù)據(jù)的精確性和完整性，檢查客戶端應(yīng)用提交的事務(wù)，以保證數(shù)據(jù)被適當(dāng)?shù)卮鎯?、更新和檢索。也測試歸檔功

13、能。,整體C/S測試策略,事務(wù)測試：創(chuàng)建一系列的測試以保證每類事務(wù)被按照需求處理。測試著重于處理的正確性，也關(guān)注性能問題(如，事務(wù)處理時間和事務(wù)量測試)。 網(wǎng)絡(luò)通信測試：這些測試驗證網(wǎng)絡(luò)節(jié)點間的通信正確地發(fā)生，并且消息傳遞、事務(wù)和相關(guān)的網(wǎng)絡(luò)交通無錯地發(fā)生。網(wǎng)絡(luò)安全性測試也可能作為此測試的一部分,C/S測試策略,即使C/S系統(tǒng)沒有采用面向?qū)ο蠹夹g(shù)實現(xiàn)，面向?qū)ο鬁y試技術(shù)還是有意義的，因為復(fù)制的數(shù)據(jù)和處理可以被組織到共享同一組性質(zhì)的對象類中。一旦為某對象類(或它們在用傳統(tǒng)方法開發(fā)的系統(tǒng)中的等價體)已經(jīng)導(dǎo)出測試用例，那些測試用例應(yīng)該可廣泛地用于該類的所有實例。 當(dāng)考慮現(xiàn)代C/S系統(tǒng)的圖形用戶界面時，O

14、O觀點是特別有價值的。GUI是天生面向?qū)ο蟮?，并且不同于傳統(tǒng)的界面，因為它必須運行于多個平臺上。此外，測試必須探索大量的邏輯路徑，因為GUI創(chuàng)建、操縱和修改大量的圖形對象。因為對象可能存在或不存在，它們可能存在一個較長的時間段，已及它們可能出現(xiàn)在桌面的任何地方，這使得測試更加復(fù)雜。,C/S測試策略,這意味著測試傳統(tǒng)的基于字符的界面的傳統(tǒng)的捕獲/回放技術(shù)必須被修改，以便于處理GUI環(huán)境的復(fù)雜性。捕獲/回放范型的一種功能變體稱為結(jié)構(gòu)化捕獲/回放，是針對GUI測試的演化。 傳統(tǒng)的捕獲/回放將輸入記錄為擊鍵、輸出記錄為屏幕圖像，它們被存放以和后續(xù)測試的輸入和輸出圖象進(jìn)行比較。結(jié)構(gòu)化捕獲/回放是基于對外

15、部活動的內(nèi)部(邏輯)視圖，應(yīng)用程序和GUI的交互被記錄為內(nèi)部事件，它們可以存放為用微軟的Visual Basic、某種C變體、或廠商自己的語言書寫的“腳本”。一系列有用的工具已經(jīng)被開發(fā)出來以支持這種測試方法。 測試GUI的工具沒有強(qiáng)調(diào)傳統(tǒng)的數(shù)據(jù)確認(rèn)或路徑測試需求，在討論的黑盒和白盒測試方法可用于很多情形，在討論的特殊的面向?qū)ο蟛呗詫蛻舳撕头?wù)器端都是適用的。,小結(jié),雖然客戶/服務(wù)器系統(tǒng)可以采用一個或多個軟件過程模型以及很多在本書前面部分討論的分析、設(shè)計和測試技術(shù)，但C/S的特殊的體系結(jié)構(gòu)特征需要對這些軟件工程方法進(jìn)行定制調(diào)態(tài)。通常，應(yīng)用于C/S系統(tǒng)的軟件過程模型在本質(zhì)上是演化型的，并且技術(shù)方

16、法經(jīng)常傾向面向?qū)ο蟮姆椒āｉ_發(fā)者必須描述對象，以得到用戶交互/表示、數(shù)據(jù)庫和應(yīng)用構(gòu)件的實現(xiàn)。為這些構(gòu)件定義的對象必須被分配在客戶端或服務(wù)器端，并且可以通過對象請求代理來連接。 對象請求代理體系結(jié)構(gòu)支持C/S設(shè)計，其中客戶端對象向服務(wù)器端對象發(fā)送消息。CORBA標(biāo)準(zhǔn)使用接口定義語言，接口池管理對象的請求而不管它們在網(wǎng)絡(luò)上的位置。 對客戶/服務(wù)器系統(tǒng)的分析和設(shè)計使用數(shù)據(jù)流圖和實體關(guān)系圖、修改的結(jié)構(gòu)圖、以及其他在傳統(tǒng)應(yīng)用開發(fā)中遇到的符號體系。測試策略必須被修改以適應(yīng)對網(wǎng)絡(luò)通信及對駐留在客戶和服務(wù)器端的軟件間的相互作用的測試,B/S應(yīng)用服務(wù)器測試,即所謂的B/S（瀏覽器/服務(wù)器） 結(jié)構(gòu)、瘦客戶機(jī)模式。

17、為了方便的開發(fā)、部署、運行和管理基于三層、多層結(jié)構(gòu)的應(yīng)用，需要 以Web的低層技術(shù)為基礎(chǔ)，規(guī)劃一個整體的應(yīng)用框架，提供相應(yīng)的支撐平臺，這一支撐平臺實 際上是基于Internet的中間件，即應(yīng)用服務(wù)器。 應(yīng)用服務(wù)器通過把用戶接口、商業(yè)邏輯和后臺服務(wù)分割開來，向開發(fā)者提供一種創(chuàng)建、部 署和維護(hù)企業(yè)規(guī)模的Web應(yīng)用的模塊化方式，從而對要轉(zhuǎn)向Web的用戶提供了高性能多線程的環(huán) 境。 考慮到web應(yīng)用服務(wù)器的以上應(yīng)用背景和產(chǎn)品特點，把為功能度、性能、兼容性、安全可 靠性作為重點測試方向，并且引用SUN Mircrosystems公司的J2EE標(biāo)準(zhǔn)作為參考標(biāo)準(zhǔn),B/S應(yīng)用服務(wù)器測試功能測試,功能測試的主要

18、目的是驗證一款產(chǎn)品是否是一個符合J2EE標(biāo)準(zhǔn)的企業(yè)級web應(yīng)用服務(wù)器。 測試前，應(yīng)針對J2EE標(biāo)準(zhǔn)中的JSP、SERVLET、JDBC、EJB等主要功能編寫測試用例。測試 用例應(yīng)盡量覆蓋典型的應(yīng)用和操作，以此來證明一款產(chǎn)品符合J2EE標(biāo)準(zhǔn)中提到的功能。特別是 功能度測試項目，應(yīng)遵循開發(fā)廠商提供的用戶手冊或程序員手冊中有關(guān)功能部分的描述作為依 據(jù)具體制定,B/S應(yīng)用服務(wù)器測試性能測試,性能測試的主要目的是考查在大壓力和大數(shù)據(jù)量情況下，應(yīng)用服務(wù)器最大處理能力和系統(tǒng) 響應(yīng)時間，同時考查不同壓力情況下應(yīng)用服務(wù)器處理能力和系統(tǒng)響應(yīng)時間。 測試過程中，首先通過JDBC接口與數(shù)據(jù)庫進(jìn)行連接，根據(jù)被測系統(tǒng)的應(yīng)

19、用環(huán)境和實際情況 制定與之相適應(yīng)的案例數(shù)據(jù)庫。然后使用功能測試中用到的JSP、Servlet和EJB測試程序，通 過Web Application Stress Tool1.1錄制相應(yīng)的測試腳本，模擬在多用戶并發(fā)情況下數(shù)據(jù)庫的 插入、更新、查詢，并記錄成功點擊次數(shù)、點擊率等相關(guān)參數(shù)。最后通過遠(yuǎn)程監(jiān)控系統(tǒng)對Web 應(yīng)用服務(wù)器的CPU占有率、內(nèi)存進(jìn)行實時監(jiān)控，通過對上述數(shù)據(jù)的匯總分析，得出功能服務(wù)器 的性能。,B/S應(yīng)用服務(wù)器測試兼容性測試,兼容性部分的測試應(yīng)分成兩部分來考察： 即硬件兼容性和軟件兼容性。 硬件兼容性主要驗證Web應(yīng)用服務(wù)器的硬件配置要求。測試中，可以根據(jù)廠商提供的安裝 手冊承諾的

20、配置信息，來驗證功能服務(wù)器的硬件兼容性。 軟件兼容性考察的方面較多，主要包括：系統(tǒng)兼容性、數(shù)據(jù)庫兼容性、Web服務(wù)器兼容 性、開發(fā)工具兼容性、與其它中間件產(chǎn)品的兼容性、J2EE組件的兼容性等多個方面,B/S系統(tǒng)測試安全可靠性測試,安全可靠性測試除了要考察用戶權(quán)限限制、輸入數(shù)據(jù)有效性檢查等基本內(nèi)容，還應(yīng)著重考 察在大壓力和大數(shù)據(jù)量情況下系統(tǒng)的穩(wěn)定性，以及驗證系統(tǒng)的SSL認(rèn)證加密機(jī)制是否有效等多 個方面,第二部分：軟件測試的原理第九章 特定類型的軟件測試,軟件本地化測試,軟件本地化測試,軟件本地化測試是在本地化的操作系統(tǒng)上對本地化的軟件版本進(jìn)行的測試。根據(jù)軟件本地化項目的規(guī)模、測試階段以及測試方法

21、，本地化測試分為多種類型，每種類型都對軟件本地化的質(zhì)量進(jìn)行檢測和保證。為了提高測試的質(zhì)量，保證測試的效率，不同類型的本地化測試需要使用不同的方法，掌握必要的測試技巧。本文主要選取本地化測試中具有代表性的測試類型進(jìn)行分析，結(jié)合軟件本地化項目的測試經(jīng)驗對其測試要領(lǐng)進(jìn)行剖析,軟件本地化測試類型解析,軟件本地化測試主要從事以下類別的測試： 導(dǎo)航測試 導(dǎo)航測試（Pilot Testing）是為了降低軟件本地化的風(fēng)險而進(jìn)行的一種本地化測試。大型的全球化軟件在完成國際化設(shè)計后，通常選擇少量的典型語言進(jìn)行軟件的本地化，以此測試軟件的可本地化能力，降低多種語言同時本地化的風(fēng)險 可接受性測試 本地化軟件的可接受性

22、測試（Build Acceptable Testing）也稱作冒煙測試（Smoke Testing），是指對編譯的軟件本地化版本的主要特征進(jìn)行基本測試，從而確定版本是否滿足詳細(xì)測試的條件。理論上，每個編譯的本地化新版本在進(jìn)行詳細(xì)測試之前，都需要進(jìn)行可接受性測試，以便早期發(fā)現(xiàn)軟件版本的可測試性，避免不必要的時間浪費,軟件本地化測試類型解析,軟件本地化測試主要從事以下類別的測試： 語言質(zhì)量測試 語言質(zhì)量測試是軟件本地化測試的重要組成部分，貫穿于本地化項目的各個階段。語言質(zhì)量測試的主要內(nèi)容是軟件界面和聯(lián)機(jī)幫助等文檔的翻譯質(zhì)量，包括正確性、完整性、專業(yè)性和一致性 用戶界面測試 本地化軟件的用戶界面測試

23、（UI Testing），也稱作外觀測試（Cosmetic Testing）主要對軟件的界面文字和控件布局（大小和位置）進(jìn)行測試。用戶界面至少包括軟件的安裝和卸載界面、軟件的運行界面和軟件的聯(lián)機(jī)幫助界面。軟件界面的主要組成元素包括窗口、對話框、菜單、工具欄、狀態(tài)欄、屏幕提示文字等內(nèi)容,軟件本地化測試類型解析,軟件本地化測試主要從事以下類別的測試： 功能測試 原始語言開發(fā)的軟件的功能測試主要測試軟件的各項功能是否實現(xiàn)以及是否正確，而本地化軟件的功能測試主要測試軟件經(jīng)過本地化后，軟件的功能是否與源軟件一致，是否存在因軟件本地化而產(chǎn)生的功能錯誤，例如，某些功能失效或功能錯誤,導(dǎo)航測試,導(dǎo)航測試尤其是

24、用于數(shù)十種語言本地化的新開發(fā)的軟件，導(dǎo)航測試版本的語言主要由語言市場的重要性和規(guī)模確定，也要考慮語言編碼等的代表性。例如，德語市場是歐洲的重要市場，通常作為導(dǎo)航測試的首要單字節(jié)字符集語言。日語是亞洲重要的市場，可以作為雙字節(jié)字符集語言代表。隨著中國國內(nèi)軟件市場規(guī)模的增加，國際軟件開發(fā)商逐漸對簡體中文本地化提高重視程度，簡體中文有望更多成為導(dǎo)航測試的首選語言,導(dǎo)航測試,導(dǎo)航測試是軟件本地化項目早期進(jìn)行的探索性測試，需要在本地化操作系統(tǒng)上進(jìn)行，測試的重點是軟件的國際化能力和可本地化能力，包括與區(qū)域相關(guān)的特性的處理能力，也包括測試是否可以容易地進(jìn)行本地化，減少硬編碼等缺陷。由于導(dǎo)航測試在整個軟件本地

25、化過程中意義重大，而且導(dǎo)航測試的持續(xù)時間通常較短，另外由于是新開發(fā)的軟件的本地化測試，測試人員對軟件的功能和使用操作了解不多，因此，本地化公司通常需要在正是測試之前進(jìn)行搜集和學(xué)習(xí)軟件的相關(guān)資料，做好測試環(huán)境和人員的配備，配置具有豐富測試經(jīng)驗的工程師執(zhí)行測試,可接受性測試,軟件本地化版本的可接受性測試與軟件公司為特定客戶定制開發(fā)的原始語言軟件在交付客戶前的驗收測試完全不同，驗收測試主要確定軟件的功能和性能是否達(dá)到了客戶的需求，如果一切順利，只進(jìn)行一次驗收測試就可以結(jié)束。 本地化軟件在編譯后，編譯工程師通常需要執(zhí)行版本健全性檢查（Build Sanity Check），確定本地化版本的內(nèi)容和主要功

26、能可以用于測試。而編譯的本地化版本是否真的滿足測試條件則還要通過獨立的測試人員進(jìn)行可接受性測試，它要求測試人員在較短的時間內(nèi)完成，確定本地化的軟件版本是否滿足全面測試的要求，是否正確包含了應(yīng)該本地化的部分。,可接受性測試,如果版本通過了可接受性測試，則可以進(jìn)入軟件全面詳細(xì)測試階段，反之，則需要重新編譯本地化軟件版本，直到通過可接受性測試。 在進(jìn)行本地化軟件版本的可接受性測試時，需要配置正確的測試環(huán)境（軟件和硬件），在本地化的操作系統(tǒng)上安裝軟件，確定是否可以正確安裝。軟件運行軟件，確定軟件包含了應(yīng)該本地化的全部內(nèi)容，并且主要功能正確。然后，卸載軟件，保證軟件可以徹底卸載。軟件的完整性是需要注意的

27、一個方面，通過使用文件和文件夾的比較工具軟件，對比安裝后的本地化軟件和英文軟件內(nèi)容的異同，確定本地化的完整性,語言質(zhì)量測試,為了保證語言測試的質(zhì)量，應(yīng)該安排本地化語言作為母語的軟件測試工程師進(jìn)行測試，同時請本地化翻譯工程師提供必要的幫助。在測試之前，必須閱讀和熟悉軟件開發(fā)商提供的軟件術(shù)語表（Glossary），了解軟件翻譯風(fēng)格（Translation Style）的語言表達(dá)要求。 由于軟件的用戶界面總是首先進(jìn)行本地化，因此，本地化測試的初期的軟件版本的語言質(zhì)量測試主要以用戶界面的語言質(zhì)量為主，重點測試是否存在未翻譯的內(nèi)容，翻譯的內(nèi)容是否正確，是否符合軟件術(shù)語表和翻譯風(fēng)格要求，是否符合母語表達(dá)方

28、式，是否符合專業(yè)和行業(yè)的習(xí)慣用法。,語言質(zhì)量測試,本地化項目后期要對聯(lián)機(jī)幫助和相關(guān)文檔（各種用戶使用手冊等）進(jìn)行本地化，這個階段的語言質(zhì)量測試，除了對翻譯的表達(dá)正確性和專業(yè)性進(jìn)行測試之外，還有注意聯(lián)機(jī)幫助文件和軟件用戶界面的一致性。如果對于某些軟件專業(yè)術(shù)語的翻譯存在疑問，需要報告一個翻譯問題，請軟件開發(fā)商審閱，如果確認(rèn)是翻譯錯誤，需要修改術(shù)語表和軟件的翻譯。 關(guān)于本地化軟件的語言質(zhì)量測試，一個值得注意的問題是“過翻譯”，就是軟件中不應(yīng)該翻譯的內(nèi)容（例如軟件的名稱等）如果進(jìn)行了翻譯，應(yīng)該報告軟件“過翻譯”錯誤,用戶界面測試,用戶界面的布局測試是本地化界面測試的重要內(nèi)容，由于本地化的文字通常比原始

29、開發(fā)語言長度增長，所以一類常見的本地化錯誤是軟件界面上的文字顯示不完整，例如，按鈕文字只顯示一部分。另一類常見的界面錯誤是對話框中的控件位置排列不整齊，大小不一致。 相對于其他類型的本地化測試，用戶界面測試可能是最簡單的測試類型，軟件測試工程師不需要過多的語言翻譯知識和測試工具，但是由于軟件的界面眾多，而且某些對話框可能隱藏的比較深入，因此，軟件測試工程師必須盡可能地熟悉被測試軟件的使用方法，這樣才能找出那些較為隱蔽的界面錯誤。另外，某個界面錯誤可能是一類錯誤，需要報告一個綜合的錯誤，例如，軟件安裝界面的“上一步”或“下一步”按鈕顯示不完整，則可能所有安裝對話框的同類按鈕都存在相同的錯誤,功能測試,本地化軟件的功能測試相對于其他測試類型具有較大難度，由于大型軟件的功能眾多，而且有些功能不經(jīng)常使用，可能需要多步組合操作才能完成，因此本地化軟件的功能測試需要測試工程師熟悉軟件的使用操作，對于容易產(chǎn)生本地化錯誤之處能夠預(yù)測，以便減少軟件測試的工作量，這就要求測試工程師具有豐富的本地化測試經(jīng)驗。 除