系統軟件測試方案

LL1.1總體測試任務安排

針對本項目的測試工作，我公司將按《計算機軟件質量保

證計劃規范》（GB/T-90）、GB/T-2008《計算機軟件測試規

范》和GB/T9386-2008《計算機軟件測試文檔編制規范》進

行軟件檢查、測試、文檔整理報送。我公司保證對測試錯誤和

缺陷進行及時修正、補充。

我公司將在本項目中全面實施標準和規范化的測試工作。

我公司將完成全部業務功能、技術功能、各種性能測試的測試

案例編寫工作和實際數據采集工作。我公司將對所有測試采用

客觀的測試案例和測試數據為驗證標準。

在本項目的軟件測試過程中，我公司將針對測試所發現的

典型性問題、常見性問題、重要性問題，建立相應的軟件測試

知識庫。

當項目甲方委托第三方測試機構進行測試時，我公司將予

以積極配合。

此外，在本項目的軟件測試過程中，我公司將提供

測試所需的工具，免費用于項目甲方在本項目中所建

平臺的測試過程。

1.1.1.2測試準備方案

4.8.10.2.1測試計劃

對于本項目的應用軟件測試工作，我公司將提前制定測試

計劃，主要包括：測試階段劃分、測試方法、工作流程、人員

分工、進度安排等內容。在測試計劃經項目甲方確認后，我公

司將按照該計劃，嚴格執行項目測試工作。

針對本項目應用軟件開發的單元測試、集成測試、系統測

試，我公司將制定切實可行的測試計劃，合理安排各階段的軟

件測試工作的任務、方法、人員安排、時間進度等，從而有效

檢驗軟件的功能、性能等方面的技術指標對項目需求的滿足程

度。在本項目中，分三個階段進行測試計劃。

（1）第一階段測試計劃（基于平臺2.0的預算綜合管理

和門戶）

第一階段測試計劃的主要內容如下：

測試階段的序列號測試內容（對象）

1單元測試所開發軟件的各

單元模塊

測試方法

白盒測試

投入人員

軟件開發

工程師

量

4個人

時間周期

7天

2集成測試所開發軟件的各

子系統

黑盒測試軟件開發

工程師、

軟件測試

工程師

軟件測試

工程師

同“3”

同“3”

同“3”

兩個人住5天

3

4

5

6

系統測試所開發軟件的整

個平臺

系統集成

試驗

階段初驗

測試

階段驗收

測試

系統集成完成的

軟件系統

系統初驗完成的

軟件系統

階段驗收完成的

軟件系統

同“2”

與“2”相同

同"2”

與“2”相同

2人

2人

2人

2人

7天

4天

2天

3天

（2）第二階段測試計劃（國庫集中支付接入）

第二階段測試計劃的主要內容如下：

序號測試階段測試內容（對象）

1

2

單元測試所開發軟件的各

單元模塊

集成測試所開發軟件的各

子系統

測試方法

白盒測試

黑盒測試

投資人員

軟件開發

工程師

軟件開發

工程師、

軟件測試

工程師

軟件測試

工程師

同“3”

同“3”

同"3”

數量

2人

1人

時間周期

15天

15天

3

4

5

6

測試系統開發的軟件的完整性

一個平臺

系統集成

測試

階段初驗

測試

階段驗收

測試

系統集成完成的

軟件系統

系統初驗完成的

軟件系統

竣工階段驗收

軟件系統

與“2”相同

同"2”

同"2”

與“2”相同

2人

4人

4人

4個人

15天

3天

2天

3天

(3)項目最終驗收測試計劃

項目最終驗收測試計劃的主要內容如下:

序號測試階段測試內容(對象)

1項目最終整體試運行正常

驗收測試的軟件系統

檢測方法

黑盒測試

投資人員

軟件測試

工程師

數量

4人

時間周期

5天

4.8.10.2.2測試組織

我公司為本項目成立了專門的測試團隊，并設置了

明確的工作崗位，主要包括高級測試經理、具有實際

軟件測試經驗的專業軟件測試工程師。

我公司對測試小組成員的工作職責做了明確的規定。所有

測試人員將負責根據測試計劃編寫測試計劃和測試用例，執行

系統測試（功能、性能、安全等。），并準備測試報告。他們還

將向項目甲方做出必要的系統缺陷回應。

4.8.10.2.3測試方案

我公司針對每類測試制定了單獨的測試計劃，包括：測試

內容、測試環境、數據要求、測試范圍和主要內容、測試工具

和測試方法、完成標準等。測試計劃經項目甲方確認后，我公

司將嚴格執行。

4.8.10.2.4測試環境

我公司將為本項目的各類測試工作搭建所需的性能測試環

境，安裝并配置性能測試工具。

4.8.10.2.5測試用例

我公司將為本項目的各類測試工作提供所需的測試用例，

并保證測試用例滿足以下要求：

1）測試用例的目標清楚，并可滿足軟件質量管理的各方

面要求。

2）測試用例的組織和分類設計思路正確，層次清晰，結構

合理。

3）測試用例覆蓋所有測試點、所有路徑、所有已

知用戶使用場景。

4）有足夠的負面測試用例來測試各種異常和異常。

5）可根據測試階段和情況的變化，及時更新維護測試用

例。

4.8.10.2.6測試數據

我公司將提供滿足本工程要求的各種試驗數據:

1）我公司將準備模擬測試數據，能夠滿足測試要求，覆蓋

被測業務和測試邊界，滿足完整性和一致性要求。

2）我公司將按項目甲方指定的范圍，采集測試所需實際

數據，并進行整理，以滿足測試需要。我公司將按照項目保密

要求，對相關數據進行保密。

1.1.1.3測試方法

基本測試策略

測試將從軟件功能、接口規范、業務處理邏輯、運行結果、

運行環境適應性等方面進行。驗證軟件功能點的滿意度、界面

布局和人機交互的規范性、業務處理邏輯的正確性和業務運行

結果的合理性。

1）測試軟件功能，驗證每個功能點對合同約定需求的滿

足程度。

2）根據界面規范的要求，對系統中各業務模塊的輸入、列

表、提示息等頁面進行測試，驗證其樣式和布局的統一性。

3）測試系統的業務處理邏輯，驗證采集和查詢結果的正確

性。

4)采用白盒法執行內部邏輯測試，驗證程序業務處理邏

輯的正確性。

5)測試模擬業務環境中系統的運行結果，驗證模擬結果

的合理性，以及系統對運行環境的適應性。

4.8.10.3.2測試執行方法

(1)功能測試

測試軟件的功能，驗證各功能點是否滿足要求。用測試用

例測試用戶需求對應的軟件功能，找出軟件功能實現與用戶功

能需求的不一致之處。通過功能測試，檢查軟件功能是否滿足

用戶對管理的要求，從而找出軟件存在的功能問題。

(2)性能測試

使用測試用例測試用戶提出的軟件性能需求所對應的軟件

的性能和效率指標。在一定的工作負載和配置條件下，測試軟

件的響應時間、處理速度、資源占用率、并發性、準確性、適

應性、可靠性、安全性等特性。驗證軟件的各項性能指標是否

滿足用戶提出的性能指標要求，從而找出軟件性能實現與性能

要求的差距。

(3)文檔測試

對安裝手冊、配置手冊、操作手冊、維護手冊等軟件文檔

進行測試，找出軟件文檔資料與使用要求之間的不一致之處，

從而檢查文檔的正確性、完備性和可理解性。

(4)環境接口測試

測試軟件界面與環境的兼容性和可用性。接口測試內容包

括：聯網

(5)安全性測試

評價軟件的安全性，檢驗軟件的安全訪問控制體系是否能

起到應有的作用。安全性測試將從訪問控制、日志記錄是否完

善，以及用戶誤操作、非法數據能否引起數據破壞等方面，對

軟件的安全性進行嚴格測試。

(6)可安裝性測試

通過安裝程序或按照安裝規程，來測試軟件的安裝過程中

是否存在錯誤，以便驗證軟件的可安裝性。

(7)邊界測試

在輸入域、輸出域、狀態轉移、功能邊界和性能邊

界等邊界或端點測試軟件的臨界運行狀態。

(8)余量測試

測試軟件的容差能力(容差指標如總存儲量、輸入/輸出通

道、處理時間等。)滿足用戶提出的技術指標要求。

(9)容量測試(負載測試)

對所測試的軟件加載大量數據進行應用處理，驗證軟件能

否按照其技術規格說明來處理大批量數據。

(10)強度試驗

在負載情況不確定的情況下，通過測試軟件的各項壓力指

標是否符合要求，來檢驗軟件的穩定性。在規定時段和強度的

測試條件下，通過運行軟件的所有功能，來驗證軟件是否存在

嚴重錯誤，以及一般錯誤是否超過規定范圍。

(11)可靠性測試

在有代表性的應用環境中，為了評估軟件的可靠性，根據

其穩定性來測試其功能。具體來說，可靠性測試將從合理使用

資源(防止內存泄露)、數據備份和恢復、用戶誤操作或非法數

據是否會導致系統異常退出/程序損壞/數據破壞等方面測試軟

件的可靠性指標。

(12)恢復性測試

當軟件出現故障并需要重新工作時，測試軟件重建其性能

水平和恢復直接受影響的數據的能力。

4.8.10.3.3測試用例設計方法

測試用例設計方法如下所述:

1）確定測試用例的角色、場景;

2）確定測試用例的主事件流、分支事件流和異常事件流;

3）確定測試用例的約束條件，包括：角色、不可空性、存

在性、可重復性、相關性、數據格式、處理狀態、接口處理限

制運行條件等。

4）確定測試用例的邊界條件，包括輸入數據格式、數據

存取錯誤檢測點、最小/最大值、處理量邊界（一條、多條數

據）、處理順序邊界（首條、末條）；

5）確定測試用例的并發條件，包括并發讀寫處理和并發控

制。

測試結果記錄方案

按照子系統、業務模塊、功能點，分別記錄以下測試結果:

1）記錄任務類型，包括：公共處理、基本數據處

理、業務邏輯處理、界面操作處理四類任務;

2）記錄測試日期、測試人、測試迭代次數、測試狀態;

3）記錄測試輸入數據、測試步驟、預期結果;

4）記錄測試輸出結果;

5）記錄測試問題分析。

4.8.10.3.5測試工具選型

在本項目的軟件測試過程中，我公司將提供測試所需的工

具（如測試管理工具、測試結果分析工具等）。），將免費用于甲

方在本項目中搭建的平臺的測試過程。主要包括以下測試工具:

1）測試環境工具；

2）預測試自動化工具；

3）測試結果提煉工具；

4）測試結果分析工具；

5）測試結果比較工具；

6）性能測試數據庫服務器。

1.1.1.4測試管理

我公司將在軟件開發過程中，組織專職軟件測試工程師進

行軟件測試工作。通過對上述定制開發軟件進行單元測試、集

成測試、系統測試，來驗證本項目所建系統的功能、性能等技

術指標是否滿足應用要求。在軟件通過各階段測試后，項目組

將軟件的測試計劃、測試用例、測試問題描述、測試報告等測

試文檔一起交付紿項目甲方。

在上述軟件測試過程中，我公司將采取嚴格而有效測試過

程管理，對軟件的功能、性能、文檔等方面的指標進行全面測

試，具體測試管理方案如下所述。

1.1.1.4.1制定軟件測試計劃。

根據項目進度計劃，由軟件測試小組的各成員共同

協商具體的測試計劃。測試組長按照指定的模板起草

《測試計劃》，其內容包括：測試目的、測試對象、

測試范圍、測試環境要求、測試任務、測試方法、測

試接收準則、測試人員安排、測試進度計劃、記錄與

報告管理機制等。

項目經理對《測試計劃》審核批準后，執行下一步驟。

1.1.1.4.2設計軟件測試用例

根據《計算機軟件質量保證計劃規范》，測試團隊的每個

成員根據指定的模板設計待測軟件的《計算機軟件測試規范》，

重點是軟件各子系統的功能、性能、接口的整體測試用例設計。

測試組長邀請開發人員和相關專家，對《測試用例》進行

技術評審，通過評審后方可執行下一步驟。

1.1.1.4.3執行軟件功能和性能測試

我公司將在本項目中全面實施標準和規范化的測試工作,

完成全部業務功能、技術功能、各種性能測試的測試案例編寫

工作和實際數據采集工作。對所有類型的測試，我公司將采用

客觀的測試案例和測試數據為驗證標準，而不以個人主觀判斷

作為測試標準。

我公司的項目測試小組將按GB/T-2008《計算機軟件測

試規范》進行軟件檢查、測試。

軟件測試小組各成員依據《測試計劃》、《測試用例》執

行軟件測試，重點測試軟件運行過程中的整體功能、性能、接

口聯接關系等技術指標，并形成測試問題記錄與報告。

對于測試過程中所發現的問題，采用我公司的自有“缺陷

管理工具”進行溝通和管理，以便將測試結果及時通報給產品

原廠商或我公司的技術人員。

測試結束后，將測試結果和統計息記錄在書名號123中。

1.1.1.4.4缺陷管理與改錯

在本項目的軟件測試過程中，我公司將針對測試所發現的

典型性問題、常見性問題、重要性問題，建立相應的軟件測試

知識庫。在制定軟件測試計劃、設計軟件測試用例、執行軟件

測試、記錄和報告測試問題的過程中，對于測試人員所發現的

缺陷使用“缺陷管理工具“，來記錄相關缺陷的狀態息，并形成

《缺陷管理報告》。

此外，我公司保證對測試錯誤和缺陷進行及時修正、補充。

我公司技術人員將根據缺陷記錄，及時消除已經發現的缺陷，

并進行相應的回歸測試，以確保在后續測試和使用過程中不再

引入新的缺陷。

對于定制開發軟件，修改其測試問題的軟件版本變更控制

流程如下圖所示：

1.1.1.5測試實施計劃

1.1.1.5.1功能測試

對于用戶功能需求說明中定義的功能需求，按照不同階段

的測試用例，對本項目系統與相關外部系統的應用集成接口進

行測試。通過驗證系統功能是否滿足需求說明書中描述的功能

需求，來發現系統目前存在的問題。功能測試工作覆蓋系統全

部源代碼。測試'內容除對代碼正確進行驗證外。還包括測試是

否滿足界面設計要求、是否滿足軟件功能需求要求等各方面要

求。

（1）測試內容

對測試對象的功能測試應側重于所有可直接跟蹤到的用例

或業務功能和業務規則的測試需求。

功能測試主要是為了發現以下幾類錯誤：

1）是否有不正確或缺失的功能？

2）功能實現是否滿足用戶需求和系統設計的隱藏需求

3）能否正確地接受輸入；能否正確的輸出結果。

功能測試要求測試設計人員熟悉產品規格、需求文檔、產

品業務功能，對測試用例設計方法有一定的掌握，從而設計出

良好的測試計劃和測試用例，高效地進行功能測試。

（2）測試規范

進行功能測試時，應遵循以下規范：

1）為每個清晰的功能需求設計至少一個基本用例，兩個異

常測試用例；

2）對每個隱含的功能需求至少設計一個基本用例和兩個

異常測試用例；

3）為每個可能的功能異常設計1到2個測試用例；

4）關鍵用例或優先級高的用例要保證有效得到執行；

5）功能測試發現的缺陷要全部得到處理。

（3）測試方法

在進行功能測試時，首先需要對需求規格進行分析，因為

這是功能測試的基本輸入。

1.需求和規范的測試和分析步驟

1）對每個明確的功能需求進行標號（對于在需求規格文

檔中已經有標號的可以直接飲用）；

2）標注每個可能隱含的功能需求；

3）對于可能出現的功能異常進行分類分析，并標號；

4）對于前面3個步驟獲得的功能需求進行分級；由于我

們不可能測試任何東西，因此可以根據風險來決定對每個功能

投入多少關注。一般來說，可以把功能劃分為關鍵功能和非關

鍵功能。其中關鍵功能是指那些對用戶來說必不可少的功能，

這類功能的喪失將導致用戶拒絕產品。

5）對每個功能進行測試分析，分析是否可以測試，如何測

試，可能的輸入，可能的輸出等。

6）腳本化和自動化。

2、常用功能測試用例設計方法

1）等價類劃分法；2）邊界值法；3）因果圖；4）判定表;

5）正交實驗設計；6）基于風險的測試；7）錯誤猜測法。

（4）風險分析

功能測試時存在的主要風險有：

1)遺漏重要的功能點的測試；

2)系統功能改變后，自動化測試腳本沒有更新，導致執行

腳本時出現虛警或腳本失敗。

(5)測試組織

功能測試主要由測試團隊完成。測試組長負責編寫功能測

試計劃、方案和測試總結報告。團隊成員負責編譯和執行功能

測試用例，編輯、調試和執行測試腳本，填寫測試日志和問題

報告。功能測試的基本工作過程如下：

(6)效果評估

由測試組長撰寫測試分析報告，對功能測試過程中的工作

組織、測試進度、缺陷分布、嚴重性、數量、人員效率、項目

質量等方面進行綜合評估。

1.1.1.5.2界面測試

(1)測試內容

用戶界面測試用于核實用戶與軟件之間的交互。目標是確

保用戶界面會通過測試對象的功能來為用戶提供相應的訪問和

瀏覽操作。另外，用戶界面測試還可確保用戶界面中的對象按

照預期的方式運行，并符合公司或行業的標準。

用戶界面測試的測試內容包括:

1、用戶界面適合于軟件的功能（合適性）

用戶界面合適性是指界面與軟件功能相融洽的程度。軟件

的功能需要通過用戶界面來展現。毫無疑問，用戶界面一定要

適合軟件的功能，這是最基本的要求。如果用戶無法通過這個

界面來使用軟件，“易用性”根本就無從談起。合適性差的界面

會混淆軟件功能意圖，即使它不損害軟件功能與性能，也會給

用戶不該有的麻煩（費解、難用、氣惱）。

2、容易理解

如果用戶很難理解界面的意圖，那么他使用起來肯定費勁。

所以“容易理解”是“容易使用”的前提條件。

3、及時反饋息

當用戶進行某項操作后，如果過了一會兒（幾秒鐘）用戶

界面一點反應都沒有，這將使用戶感到迷茫和不安，因為他不

知道是自己操作錯了還是軟件死機了。所以及時反饋息很重要,

至少要讓用戶心里有數，知道該任務處理得怎么樣了，有什么

樣的結果。

4、防錯處理

在使用軟件的過程中，難免會出現一些錯誤的操作。如果

用戶不小心輸入了錯誤的數據或者刪除了有用的數據，軟件被

愚蠢地執行了，那么用戶會非常生氣，以后也不敢放心使用軟

件。

5、合理的布局

界面的整體布局要符合邏輯，最好和工作流程保持一致。

窗口（或頁面）上界面元素的布局應該整潔、清新。

6.合理的顏色

界面色彩要合理，使用顏色的時候要保持一致，同時根據

對象的重要性來選擇顏色，但是又不能過分依賴顏色，因為有

些用戶可能是色盲或色弱。

7、風格一致和必要的個性化

風格一致的最大好處就是能夠減少用戶的記憶量、減少出

錯幾率，并且迅速積累操作經驗。而個性化界面設計又能吸引

用戶眼球培養用戶對軟件的興趣。所以要求用戶界面在具備必

要的“一致性”的前提下，突出該軟件的“個性”。不僅讓用戶使

用起來方便，而且對軟件留下深刻的向象。

8、適應用戶群體和國際化

軟件設計要適應多種類型的用戶，比如對計算機比較外行

的、計算機專家等，努力使用戶在操作軟件的時候感覺不到差

異和麻煩。為了達到這個目標，一般需要提供多種操作途徑以

適應各種水平的用戶。

為了能夠更好地適應國內和國際市場，在用戶界面應當充

分考慮語言和文化的差異。使用標準的圖解方式和國際通行的

語言，要求簡單易懂，易于翻譯，方便不同母語的用戶。

9、最少操作步驟(最高效率)

用戶界面應當盡可能地替用戶著想，用戶應當用最少的操

作步驟完成某項操作任務，獲得最高的使用效率。

10、可復用

復用有利于提高質量、提高生產率和降低成本。因此用戶

界面也應該做到能夠被復用。

(2)測試規范

用戶界面設計規范如下表：

設計要素重要性規范描述

用戶界面是否與軟件的功能相融洽？用戶界面是否適合用

戶

的應用環境？

非常重要

說明：如果是否定的，說明用戶不能有效地使用這個軟件。

是不可原諒的缺陷。這個缺陷是需求分析錯誤造成的。

界面元素有錯別字，或者措詞含糊、邏輯混亂。

解釋：如果出現如此低級的缺陷，說明開發人員根本沒有

把用

非常重要

用戶把界面放在心上，用戶對這種不專業的態度很反感。

不可原諒。

的缺陷。

容易理解

重要

對于常用的功能，用戶能否不必閱讀手冊就使用？

是否所有界面元素提供了充分而必要的提示？

界面結構和工作流程匹配嗎？

你提供在線幫助嗎？

解釋：如果實現上述要求，說明界面細節做得很好。

是進度條，動畫等。以反映正在進行的耗時過程？

重要操作是否返回必要的結果息？

解釋：如果否定的話，說明用戶界面不夠專業。

合適性

及時反饋

息

重要的

錯誤預防處理

在執行破壞性操作之前，是否得到用戶的確認？

輸入數據或遞交數據時，是否進行相應的數據校驗（檢查

數據

合法嗎）

非常重要

是否根據用戶的權限自動隱藏或者禁用某些功能？

解釋：如果是否定的，說明開發者沒有防誤常識，是的

不可原諒的缺陷。

可選擇的

是否提供撤銷功能來撤銷意外操作？

解釋：如果實現該要求，說明界面細節做得很好。

設計要素

一致性

重要性

重要的

規范描述

相似的界面元素是否有相同的視覺感，相同的操作方式？

是否符合廣大用戶使用同類軟件的習慣？

解釋：如果否定的話，說明用戶界面不夠專業

是否在具備必要的“一致性”的前提下，設計了與眾不同的、

一個讓用戶記憶深刻的界面？

解釋：如果實現這個要求，說明界面很有創意。

界面的布局符合軟件的功能邏輯嗎？

界面元素是水平對齊還是垂直對齊？

界面元素的尺寸是否合理？

行距一致嗎？

是否恰當地利用窗體和控件的空白，以及分割線條？

窗口切換、移動、改變大小時，界面正常嗎？

解釋：如果否定的話，說明用戶界面不夠專業。

界面的色調是否讓人感到和諧、滿意？

重要的對象是否用醒目的色彩表示？

顏色的使用是否符合行業習慣？

是否可以讓色盲、色弱的人員使用？

說明：如果實現了這個要求，界面細節非常好。

有沒有適合初學者和專家操作這個界面的方法？

色盲或者色弱的用戶能正常使用該界面？

解釋：如果實現該要求，說明界面細節很好。

度量單位、日期格式、人的名字是否讓用戶誤解？

翻譯文字是否地道，是否符合讀者習慣？

你是否使用合理的最少步驟來實現常見操作并實現高效率?

解釋：如果實現該要求，說明界面細節和好。

用戶界面的原型、代碼、文檔可以重用嗎？

解釋：如果實現該要求，說明軟件的需求分析、設計、實

現做

干得好。

個性化可選

合理布局可選

合理的顏色很重要。

用戶可選擇的適應

國際化

最少步驟

高效率

可復用

重要的

重要

重要

(3)測試方法

界面測試應當盡早進行，測試方法有：對界面原型采用場

景測試方法，由測試人員扮演場景中的角色，模擬各種可能的

操作以及可能的操作序列，并且由用戶來判斷是否合理，是否

有功能的遺漏。

界面原型確定后，開始設計界面測試用例，用例設計的思

路如下：

1、劃分界面元素，并根據界面的復雜性進行分層

一般分為三個層次：第一個層次是界面原子，即不可再分

的界面元素，例如：一個菜單項、一個按鈕、一個列表等。第

二個層次是界面組合元素，是由多個具有相同屬性的界面原子

或者彼此協助的一組界面原子組合而形成的一類界面元素。例

如：工具欄、組合框等；第三個層次是一個完整的窗口，一個

完整的窗口是由一系列界面組合元素組成的能夠完成一個完整

的輸入輸出功能的界面屬性組合，并且它具有自己的視圖。

2、在不同的界面層次確定不同的測試策略

一般在界面原子層，主要考慮界面原子的顯示屬性、觸發

機制、功能行為、可能的狀態集等內容。對于界面原子可能接

受的輸入可以從等價類劃分，邊界值分析等角度考慮，觸發機

制可以從規范導出的方法分析，功能行為可以使用因果圖或判

定表，可能的狀態集可以使用錯誤猜測法或基于錯誤的測試方

法等。對于界面組合元素，主要考慮界面原子組合順序、排列

組合、整體外觀、組合后功能行為的多個角度測試。對于一個

完整的窗口，主要考慮窗口的整體外觀、窗口元素的排列組合、

窗口屬性值、窗口可能的各種組合行為等。

3.分析測試數據并提取測試用例。

對于界面元素的外觀，可以從以下幾個角度獲取測試數據:

1）界面元素尺寸；

2）界面元素的形狀；

3）界面元素的顏色、對比度、亮度；

4）界面元素中包含的文本屬性（如字體、排序方式、大小

等。）.

對界面元素的布局，可以從以下幾個角度獲取測試數據：

1）各界面元素的位置；

2）各界面元素的對齊方式；

3）各界面元素間間隔；

4）Tab順序；

5）所有界面元素的配色。

對于界面元素的行為，可以從以下角度獲取測試數據：

1）回聲功能；2）輸入限制和輸入檢查；3）輸入提醒；

4）聯機幫助；5）默認值；6）激活或取消激活；

7）焦點狀態；8）功能鍵或快捷鍵；

9）操作路徑；10）行為回退。

4、使用自動測試工具進行腳本化工作。

(4)風險分析

界面測試存在的主要風險有：

1)在測試后期，界面發生重大改變，導致測試工

作被動。

2)受整個測試進度影響，界面測試用例未能完全執行。

(5)測試組織

用戶界面測試主要由測試團隊完成。測試組長負責編寫用

戶界面測試計劃、方案和測試總結報告。團隊成員負責編寫和

執行用戶界面測試用例，編輯、調試和執行測試腳本，填寫測

試日志和問題報告等。用戶界面測試與功能測試相同，通常與

功能測試同時進行。具體流程如圖。

(6)效果評估

由測試組長撰寫用戶界面測試報告，對用戶界面測試階段

的工作組織、測試進度、缺陷分布、嚴重性、數量、人員效率

等方面進行綜合評估。

1.1.153負載測試(壓力測試)

(1)測試內容

負載測試也是一種性能測試。在這種測試中，將使測試對

象承擔不同的工作量，以評測和評估測試對象在不同的工作量

條件下的性能行為，以及持續正常工作的能力。負載測試的目

標是確定并確保系統在超出最大預期工作量的情況下仍能正常

運行。此外，負載測試還要評估性能特征，例如相應時間、事

物處理速率和其他與時間相關的方面。

（2）測試規范

測試規格：

1）負載測試應考慮虛擬用戶數量的增加幅度和方式；

2）負載測試使用組裝點模擬數據集中提交；

3）負載測試的負載增加方式要模擬系統的實際需求和用

戶真實的負載產生情況。

（3）測試方法

負載測試使用loadrunner控制器模擬生成特定數量的

vuser來運行實際程序，從而逐步增加負載。運行漸增vuser時,

吞吐量、響應時間、cpu負載、內存使用等關鍵性能指標。可

以根據業務需求進行監控。

（4）風險分析

負載測試存在的主要風險為對負載測試工具使用不熟練，

導致測試效率低下；場景規劃不合適，導致負載模擬沒有體現

真實的系統負載。

（5）測試組織

負載測試主要由測試小組來完成，測試組長負責負載測試

計劃、方案和測試總結報告的編寫，組員負責負載測試用例的

編寫、執行、測試腳本的編輯、調試和執行并填寫測試日志和

問題報告等。負載測試的基本工作過程如下：

（6）效果評估

由測試組長撰寫負載測試報告，對負載測試階段的工作組

織、測試進度、缺陷分布、嚴重性、數量、人員效率等方面進

行綜合評估。壓力測試需保證系統滿足平臺建設性能要求。測

試結果形成《壓力測試報告》提交用戶方。

性能測試

在一定工作負荷和配置條件下，測試系統的各項性能指標,

驗證其對合同約定的性能需求的滿足程度（確保測試結果高于

性能指標要求）。

性能測試前，設置模擬運行環境、訪問用戶數等性能測試

的基本條件，編寫單用戶和并發用戶環境下的系統訪問腳本。

在測試過程中，測試主測試系統的響應能力指標、處理能

力指標、可用性、可靠性、穩定性、適應性、可操作性和可擴

展性。

（1）測試內容

性能測試是對響應時間、事務處理速率和其他與時間相關

的需求進行評測和評估。性能測試的目標是核實性能需求是否

都已滿足。根據本項目實際情況要求如下：

1）操作界面響應時間：在穩定的網絡環境下，簡單系統查

詢響應時間小于5秒，復雜系統響應時間小于30秒；

2）息發布響應時間，單個管理氏戶登錄后臺頁面的平均

時間3秒內；

3）前端并發要求，系統應能支持50個用戶同時在線使用。

測試內容包括：

1）應用在客戶端性能的測試：比如并發性能測試、疲勞

強度測試、大數據量測試、速度測試等。

2）網絡性能測試：如網絡模擬、網絡應用性能分析、網絡

應用性能監控、網絡預測等。

3）應用在服務器上性能的測試：對主機和操作系統的監

控、對數據庫及應用系統的監控、對中間件服務器的監控。

（2）測試規范

性能測試需遵循如下規范：

1）需考慮測試工具的硬件和軟件配置要求。

2）定義測試類型以及與該類型相關的測試環境需求。

3）性能測試不僅要評估系統當前的性能，還要預測未來的

性能

4）性能測試的關鍵是尋找系統瓶頸所在。

性能測試的基本方法：

性能測試基本方法：

1、明確測試需求和測試內容

通過綜合分析系統的業務需求說明，結合系統運行的實際

環境，列出明確的性能測試需求。對關鍵業務進行重點性能分

析。

2、制定測試案例

按照公司性能測試規范，編寫性能測試案例。

3、測試環境準備

搭建性能測試環境，安裝并配置性能測試工具。

4、測試腳本錄制、編寫和調試

依照性能測試案例，錄制自動化測試腳木，通過編輯調試

保證腳本的正確運行。

1）制定腳本分配、回放配置和加載策略：根據前面分析

的性能測試需求，確定腳本的分配、配置和加載策略。

2）測試執行跟蹤：在測試工具中運行預定腳本，跟蹤性

能測試過程。

3）結果分析與測試評估：使用專門的結果分析軟件對性

能測試結果進行分析匯總，確定系統瓶頸所在。明確關鍵業務

交易時間并預測未來趨勢。

（4）風險分析

性能測試存在的主要風險為：

1）無法構建獨立的完善的性能測試環境

2）性能測試結果不準確；

（5）測試組織

性能測試主要由測試小組來完成，測試組長負責性能測試

計劃、方案和測試總結報告的編寫，組員負責性能測試用例的

編寫、執行、測試腳本的編輯、調試和執行并填寫測試日志和

問題報告等。性能測試的基本工作過程如下：

（6）效果評估

由測試組長撰寫性能測試報告，對性能測試階段的工作組

織、測試進度、缺陷分布、嚴重性、數量、人員效率等方面進

行綜合評估。

1.1.1.5.5強度測試

（1）測試內容

強度測試是一種功能測試，實施和執行此類測試的目的是

找出因資源不足或資源爭用而導致的錯誤。如果內存或磁盤空

間不足，測試對象就可能會表現出一些再正常條件下并不明顯

的缺陷。而其他缺陷則可能由于爭用共享資源（如數據庫或網

絡帶寬）而造成的。強度測試還可用于確定測試對象能夠處理

的最大工作量。

強度測試的目的在于：

1）獲得系統總用戶負荷增加時單個用戶真實的個人體驗

2）確定運行該應用程序硬件的最大負荷，從而決定在將

應用程序推廣到實際應用中去前，是否有必要對硬件進行升級。

3）根據平均頁面響應時間，為程序的使用者確定可接受

的運行性能的閾值。

4）確保系統在預期的最大并行比戶負荷時，性能的閾值

仍然處于可接受的水平。

（2）測試規范

強度測試規范為：

1)強度的設置需考慮業務系統的實際情況，避免過多或

過少地增加系統強度；

2)需對強度測試結果進行分析確定哪部分硬件設備或軟

件模塊影響了系統的性能。

(3)測試方法

強度測試首先是使用LoadRunner工具對業務系統進行強

度測試，測定Web服務器每秒種所能處理的最大請求數，這

是定量的測量。第二步確定CPU、內存或終端設備中哪一項

限制了每秒請求數達到更高的水平：

(4)風險分析

強度測試存在的主要風險有：

1)用戶強度負荷設置不合理；

2)沒有合適的強度測試工具。

(5)測試組織

強度測試主要由測試小組來完成，測試組長負責強度測試

計劃、方案和測試總結報告的編寫，組員負責強度測試用例的

編寫、執行、測試腳本的編輯、調試和執行并填寫測試日志和

問題報告等。強度測試的基本工作過程如下：

(6)效果評估

由測試組長撰寫強度測試報告，對強度測試階段的工作組

織、測試進度、缺陷分布、嚴重性、數量、人員效率等方面進

行綜合評估。

LL1.5.6容量測試

能力測試的內容包括：

容量測試使測試對象處理大量數據，以確定是否達到了使

軟件發生故障的極限。容量測試還將確定測試對象在給定的時

間內容能夠持續處理的最大負載或工作量。例如，如果測試對

象正在為生成一份報表而處理一組數據庫記錄，那么容量測試

就會使用一個大型測試數據庫，檢驗該軟件是否正常運行并生

成了正確的報表。

容量測試分為兩種，一是獨立的容量測試：針對某些存儲、

傳輸、統計、查詢等業務進行容量測試；二是綜合容量測試：

和壓力性能測試、負載性能測試、強度性能測試相結合的綜合

測試方案。

容量測試的內容包括：

1）當使用敏感操作時進行的相關數據比較；

2）對包含大量數據的記錄進行模糊查詢操作；

3）對大量數據進行批量修改操作；

4）對大量數據記錄的計算、分析操作；

5）在網絡上大量發送郵件息。

（2）測試規范

進行容量測試時須遵守如下規范：

1）測試數據需充分考慮實際業務需求；

2）測試數據要有有效的管理手段，以方便數據轉換、編

輯、數據瀏覽、數據比較、數據遷移等。

（3）測試方法

進行容量測試關鍵是能產生符合業務要求的大量數據記錄,

可以使用測試數據生成工具TestBytes或DataFactory確定需要

生成的數據類型，通過與數據庫的連接來自動生成百萬行的正

確的測試數據。

在該項目的測試中共我們將使用DataFactory結合

LoadRunner來完成測試數據的生成和綜合容量測試。

進行容量測試一般可以通過以下幾個步驟來完成：

1）分析系統的外部數據源，并進行分類；

2）對每類數據源分析可能的容量限制，對于記錄類型數

據需要分析記錄長度限制、記錄中每個域長度限制和記錄數量

限制；

3）對每個類型數據源，構造大容量數據對系統進行測試;

4）分析測試結果，并與期望值比較，確定目前系統的容

量瓶頸；

5）對系統進行優化并重復（1）?（4）步驟，直到系統

達到期望的容量處理能力。

（4）風險分析

容量測試存在的主要風險為：

1）進行容量測試所使用的測試數據的數量和實際業務系

統未來的數據量存在明顯偏差而導致容量測試不能發現真正的

容量隱患。

2）對測試數據生成工具不熟悉，無法快速生成大量有效

的測試數據。

（5）測試組織

容量測試主要由測試小組來完成，測試組長負責容量測試

計劃、方案和測試總結報告的編寫，組員負責容量測試用例的

編寫、執行、測試腳本的編輯、調試和執行并填寫測試日志和

問題報告等。容量測試的基本工作過程如下：

（6）效果評估

由測試組長撰寫容量測試報告，對容量測試階段的工作組

織、測試進度、缺陷分布、嚴重性、數量、人員效率等方面進

行綜合評估。

1.1.1.5.7安全性和訪問控制測試

(1)測試內容

安全性和訪問控制測試側重于安全性的兩個關鍵方面：應

用程序級別的安全性，包括對數據或業務功能的訪問；系統級

別的安全性，包括對系統的登錄或遠程訪問。

1、應用程序級別的安全性

可確保在預期的安全性情況下，主角只能訪問特定的功能

或用例，或者只能訪問有限的數據。例如，可能會允許所有人

輸入數據，創建新賬戶，但只有管理員才能刪除這些數據或賬

戶。如果具有數據級別的安全性，測試就可確保“用戶一“能夠

看到所有客戶消息(包括財務數據)，而“用戶二”只能看見同

一客戶的統計數據。比如B/S系統，不通過登入頁面，直接輸

入URL,看其是否能夠進入系統？

2、系統級別的安全性

可確保只有具備系統訪問權限的用戶才能訪問應用程序，

而且只能通過相應的網關來訪問。

安全性是一種保護系統，它不僅對于保證機密數據的安全

性是必需的，而且出于競爭目的而保護第三方數據這一點來說

它也是必要的。安全性測試用于評價保護性程序以及安全對策

的充分性。

安全性測試分為物理安全性測試和邏輯安全性測試。物理

安全性主要針對利用物理方法收集息的手段，而邏輯安全性主

要針對使用計算機處理或通能力進行非法獲取息的手段。另外,

訪問控制也可根據訪問身份不同而區分。

安全性測試主要驗證隱私是否受到保護、數據是否加密、

數據是否防篡改，以及應用程序是否能夠承受各種類型的惡意

攻擊。

測試內容如下：

1）系統的登錄；

2）用戶管理；

3）防火墻；

4）系統數據；

5）WEB安全性，如WEB的加密，解密，數字簽名等；

6）數據庫的安全性；

7）內部通協議；

8）系統防病毒測試；

9）測試未經許可的訪問，保證系統可以識別和防止資源

的未授權訪問。

（2）測試規范

1）確定對識別安全風險足夠重視。

2）確定對系統的現實定義及其加強措施已經實施。

3）確定由足夠的專家執行充分的安全性測試。

4）執行合理的測試來確保安全性保護措施的正確執行。

（3）測試工具

安全性測試使用的工具主要為DOS模擬攻擊工具、網絡

探測工具。

（4）測試方法

1）借助安全性測試工具對系統漏洞進行攻擊發現潛在安

全漏洞；

2）訪問控制測試用例質量不高，無法發現訪問控制中存在

的問題。

（5）風險分析

安全性和訪問控制測試存在的主要風險為：

1）使用安全性測試工具并不能全部暴露系統安全隱患；

2）訪問控制測試用例質量不高，不能發現訪問控制中存

在的問題。

（6）測試組織

安全性和訪問控制測試主要由測試小組來完成，測試組長

負責安全性和訪問控制測試計劃、方案和測試總結報告的編寫,

組員負責安全性和訪問控制測試環境的搭建、測試用例的編寫、

執行并填寫測試日志和問題報告等。安全性和訪問控制測試的

基本工作過程如下：

（7）效果評估

由測試組長撰寫安全性和訪問控制測試報告，對安全性和

訪問控制測試過程的工作組織、測試進度、缺陷分布、嚴重性、

數量、人員效率等方面進行綜合評估。

1.1.158故障轉移測試（災備與恢復測試）

（1）測試內容

故障轉移可確保測試對象能成功完成故障轉移，并能從導

致意外數據損失或數據完整性破壞的各種硬件、軟件或網絡故

障中恢復。故障轉移測試可確保：對于需持續運行的系統，一

旦發生故障，備用系統就將不失時機地“頂替”發生故障的系統,

以避免丟失任何數據或事務。

故障測試內容包括：當主機系統發生故障時，能否順利切

換到備機系統，切換的時間有多長？在主備機切換的過程中業

務處理過程會不會中斷，未存盤的業務數據會不會丟失。

(2)測試規范

故障轉移測試規范為：進行故障轉移測試時需測試業務數

據是否丟失、業務操作過程是否中斷；需保證主備機的切換操

作時間滿足系統業務需求。

(3)測試工具

靠手工干預主機操作來觸發故障轉移動作，不需要額外的

測試工具。

故障轉移測試方法包括：

故障轉移測試方法有：

1)制定故障轉移測試計劃，列出進行測試的時間、環境、

觸發動作等；

2)編寫故障轉移測試用例，按尺例執行既定的操作，需

要多人配合完成一次故障轉移的執行、監督和查看。

(5)風險分析

故障轉移測試存在的主要風險為故障的不可預見性和破壞

力，模擬測試很難完全實現全部的故障類型和故障強度的模擬,

存在發生某些故障后主備機無法完成切換的問題；

1)主備機切換的時間過長不能滿足業務需求；

2)主備機切換中出現數據丟失、流程中斷等錯誤。

(6)測試組織

故障轉移測試主要由測試小組來完成，測試組長負

責故障轉移測試計劃、方案和測試總結報告的編寫，

組員負責故障轉移測試環境的搭建、測試用例的編寫、

執行并填寫測試日志和問題報告等。故障轉移測試的

基本工作過程如下：

（7）效果評估

由測試組長撰寫故障轉移測試報告，對故障轉移測試過程

的工作組織、測試進度、缺陷分布、嚴重性、數量、人員效率

等方面進行綜合評估。

1.1.1.5.9恢復測試

（1）測試內容

恢復測試是一種對抗性的測試過程。在這種測試中，將把

應用程序或系統置于極端的條件下（或者是模擬的極端條件

下），以產生故障（例如設備輸入/輸出（I/O）故障或無效的數

據庫指針和關健字）。然后，調用恢復進程并監測和檢查應用

程序和系統，核實應用程序或系統和數據已得到了正確的恢復。

恢復測試包括：在應用程序人工干預、輸入能力丟失、通

線路失效、硬件或操作系統失效、數據庫完整性遭到破壞、操

作錯誤以及應用系統崩潰等情況下的恢復操作。

（2）測試規范

恢復測試規范如下：

1）如果系統本身能夠自動地進行恢復，則應檢驗重新初

始化、檢驗點設置機構、數據恢復以及重新啟動是否正確。

2）如果這一恢復需要人為干預，則應考慮平均修復時間

是否在限定的范圍以內。

（3）測試工具

恢復測試需要人為的置入故障來測試，例如：在系統運行

過程中突然中斷電源或切斷網絡連接等。基本上不需要特定的

測試工具。

（4）測試方法

對該項目的恢復測試應該使用為功能和業務周期測試創建

的測試來創建一系列的事務。一旦達到預期的測試起點，就應

該分別執行或模擬以下操作：

1）客戶機斷電：關閉PC的電源。

2）服務器斷電：模擬或啟動服務器的斷電過程。

3）通過網絡服務器產生的中斷：模擬或啟動網絡的通中

斷（實際斷開通線路的連接或關閉網絡服務器或路由器的電

源）。

4）DASD和DASD控制器被中斷、斷電或與DASD和

DASD控制器的通中斷：模擬與一個或多個DASD控制器或

設備的通，或實際取消這種通。

一旦實現了上述情況（或模擬情況），就應該執行其他事

務。而且一旦達到第二個測試點狀態，就應調用恢復過程。

在測試不完整的周期時，所使用的方法與上述方法相同，

只不過應異常終止或提前終止數據庫進程本身。

對以下情況的測試需要達到一個已知的數據庫狀態。當破

壞若干個數據庫字段、指針和關鍵字時，應該以手工方式在數

據庫中（通過數據庫工具）直接進行。其他事務應該通過使用

”應用程序功能測試”和“業務周期測試”中的測試來執行，并且

應執行完整的周期。

（5）風險分析

恢復測試存在的主要風險為故障的不可預見性和破壞力，

模擬測試很難完全實現全部的故障類型和故障強度的模擬。

（6）測試組織

恢復測試主要由測試小組來完成，測試組長負責恢復性測

試計劃、方案和測試總結報告的編寫，組員負責恢復性測試環

境的搭建、測試用例的編寫、執行并填寫測試日志和問題報告

等。恢復性測試的基本工作過程如下：

(7)效果評估

由測試組長撰寫恢復測試報告，對恢復測試過程的工作組

織、測試進度、缺陷分布、嚴重性、數量、人員效率等方面進

行綜合評估。

LLL5.10配置測試

(1)測試內容

配置測試核實測試對象在不同的軟件和硬件配置中的運行

情況。在大多數的生產環境中，客戶機工作站、網絡連接和數

據庫服務器的具體硬件規格會有所不同。客戶機工作站可能會

安裝不同的軟件。例如，應用程序、驅動程序等，而且在任何

時候，都可能運行許多不同的軟件組合，從而占用不同的資源。

配置測試的內容有：

1、硬件配置測試

測試系統在不同的CPU、內存、顯示器分辨率下的運行

狀況。例如：該軟件是燒在并口設備中的，測試同時使用其他

并口設備，系統是否可以正確使用。比如在INTER,

AMDCPU芯片下系統是否能夠正常運行？這樣的測試需建立

測試實驗室，在各種環境下進行測試。

2、軟件配置測試

測試系統在不同的操作系統、不同的瀏覽器版本下的運行

狀況。測試軟件在不同廠商的瀏覽器下是否能夠正確顯示與運

行，例如：測試IE,Natscape瀏覽器下是否可以運行這套軟

件？測試WINDOWS98,WINDOWS

2000,WINDOWSXP,LINUX,UNIX下是否可以運行這套軟件？

3、網絡配置測試

測試系統在不同的網絡環境和網絡速率下的運行狀況。

(2)測試規范

配置測試要規范如下：

1)搭建配置測試環境要充分考慮系統需求，避免測試環

境過少而遺漏測試，同時也不能模擬過多的環境來增加測試的

負擔和成本，通常配置測試需要考慮到當前流行的硬件配置、

操作系統版本和瀏覽器版本。

2)對于不同屏幕大小的測試取決于系統設計規格的定義，

如果系統只能運行在1024*768的環境下，則就沒有必要考慮

系統在800*600環境下的表現。前提是這種設計規格要經過客

戶的簽字確認。

(3)測試工具

在實施配置測試時，可使用VMWare來生成虛擬的各種

軟硬件環境來實現。

（4）測試方法

配置測試有兩個工作量最大的操作，分別是搭建不同的配

置環境和在不同的配置環境下運行測試。進行此類測試需要的

設備資源和人力資源相對較多，要實現完全的配置測試需要下

面的方法：

1）分析系統業務需求，列出配置測試環境對照表格；

2）按表格條目要求使用虛擬軟件工具依次搭建所需的環

境；

3）在測試環境中運行系統的關鍵測試用例，報告并發現

問題所在。

（5）風險分析

配置測試中存在的主要風險有：

1）無法完整模擬客戶真實的工作環境，導致的測試不充

分問題；

2）測試所需資源多、工作量大，測試小組不能獲得足夠

的人力、物力資源來完成所有配置測試。

（6）測試組織

配置測試主要由測試小組來完成，測試組長負責配置測試

計劃、方案和測試總結報告的編寫，組員負責配置測試環境的

搭建、測試用例的編寫、執行并填寫測試日志和問題報告等。

配置測試的基本工作過程如下：

(7)效果評估

由測試組長撰寫配置測試報告，對配置測試過程的工作組

織、測試進度、缺陷分布、嚴重性、數量、人員效率等方面進

行綜合評估。

1.1.1.5.11安裝測試

(1)測試內容

安裝測試有兩個目的。第一個目的是確保該軟件在正常情

況和異常情況的不同條件下：例如，進行首次安裝、升級、完

整的或自定義的安裝都能進行安裝。異常情況包括磁盤空間不

足、缺少目錄創建權限等。第二個目的是核實軟件在安裝后可

立即正常運行。

安裝測試的步驟和內容包括：

編號

1

步驟名稱

啟動安裝程序

測試內容

如果安裝了CD-ROM,插入安裝盤后自動啟動安裝程序或

在CD盤中

突出顯示setup.exe文件，雙擊文件啟動安裝程序

“載入安裝程序”對話框出現后，檢查：內容是否正確；拼

寫是

否正確；在安裝過程中，隨著載入安裝程序界面的出現，

閃屏也

隨即出現。

彈出框出現時，檢查：內容是否正確；拼寫是否正確。

點擊右上角的X按鈕關閉時是否出現詢問退出的對話框,

如“您

確定要退出嗎？'選擇取消按鈕是否出現詢問退出的對

話框，

如“您確定要退出嗎？"；單擊"是”后出現提示應用系統沒

有被正確地安裝，用戶需重新安裝的息；單擊“否”后關閉

對

話框且返回到先前的界面；

安裝導航引導用戶到正確的屏幕，例如下一步（Next）,

返回

(Back),取消(Cancel)按鈕；焦點停留的按鈕能夠引

導到下2

3

閃屏

彈出框

4中途退出

5安裝導航

編號步驟名稱測試內容

一個合理的操作，例如standalone安裝類型將引導到

standalone

安裝中的下一個屏幕；使用鍵盤導航。

程序可以選擇“C：”以外的目錄；通過單擊按鈕可以

選

擇其他的安裝路徑；可以通過以下方法選擇路徑：焦點在

“確

定”按鈕上,按“Enter”鍵、焦點在“確定”按鈕上，點擊“確

定”按鈕、從瀏覽文件夾中雙擊選擇路徑、直接輸入路徑;

文本框中輸入的路徑不存在時，系統可以創建。

無異常出現；所有的文字可以正常顯示（無截斷）；界面

上的版

本息，公司息（圖標，時間，地址等）正確；許可證協議

息完整、正確。

有彈出窗口顯示安裝完畢；所有的文件都安裝在選擇的目

錄下；

要求的dl全部安裝；幫助文件安裝在指定的文件夾下；

檢查.exe

和dl文件的版本號是否正確；檢查Ini文件是否記載了

正確的

路徑和IP地址息；檢查需注冊息在注冊表中是否存在且

在正

確的地方；快捷方式創建在選擇的文件夾/啟動菜單中，

例如：

C:\WINNT\Profiles\xs564gb\StartMenu\Programs\Executive

Workbench；日志文件（Log）中的息完整、正確

可以通過以下方式啟動應用程序：雙擊目錄中的應用程序

圖標；

從開始菜單中選擇;焦點放在exe文件上，敲“Enter”鍵;

雙擊

exe文件；運行命令下啟動；雙擊桌面上的快捷方式

如果有對話框提示需重啟計算機才能完成安裝，重啟機器

再啟動

應用程序是否可以正常工作。

通過Uninstall程序或控制面板卸載應用程序；卸載后，

檢查安

裝的文件/文件夾/注冊表息是否被刪除

6目的地文件

7安裝過程

8安裝完畢

9啟動應用程序

重啟后啟動應用

程序

卸載

10

11

(2)測試規范

安裝測試應遵循的規范如下：

1)測試應用程序安裝、運行腳本時未出現錯誤，以及所

有主要功能都能通過測試。

2）測試安裝在客戶端計算機上的所有文件版本（包括代

碼和內容）都正確。

3）測試可以卸載應用程序并測試清理的驗證。

4）在安裝中驗證文件的命名標準。

5）驗證安裝程序在遇到錯誤情況（例如磁盤空間不足）

時可以正常退出。

6）在安裝過程中驗證注冊表項，以及在卸載過程中驗證

注冊表的清理。

7）執行全新的計算機安裝。這臺計算機帶有新安裝的操

作系統和少量必需的已安裝組件。

8）測試具有不同軟件配置的計算機上的安裝。

9）測試安裝程序創建了正確的Start菜單項。

10）測試安裝程序將文件置于正確的文件夾中。

11）測試程序集是否在部署服務器上進行加密和數字簽名,

并在客戶端下載時進行驗證。

（3）測試工具

安裝測試靠手工完成，不需要測試工具。

（4）測試方法

構建不同的操作平臺，然后在平臺上按安裝測試操作步驟

和內容執行安裝。

（5）風險分析

安裝測試存在的主要風險為：安裝測試操作平臺模擬不夠,

在個別平臺上可能會出現安裝問題。

（6）測試組織

安裝測試主要由測試小組來完成，測試組長負責安裝測試

計劃、方案和測試總結報告的編寫，組員負責安裝測試用例的

編寫、執行、測試腳本的編輯、調試和執行并填寫測試日志和

問題報告等。安裝測試的基本工作過程如下:

（7）效果評估

由測試組長撰寫安裝測試報告，對安裝測試階段的

工作組織、測試進度、缺陷分布、嚴重性、數量、人

員效率等方面進行綜合評估。

1.1.1512文檔測試

由測試人員按照用戶需求對用戶需求說明書、軟件需求規

格說明書、軟件設計說明書、數據庫設計說明書、接口設計說

明書、安裝配置手冊、用戶手冊、培訓手冊等文檔進行測試。

通過測試，檢查文檔的正確性、完備性和可理解性，并找出系

統實現與需求之間的不一致之處，并提交相應的測試報告。

在本項目的文檔測試中，各類文檔具有不同的測試優先等

級，如下所示：

序號

1

2

3

4

5

6

7