qileilove

精通軟件性能測試與LoadRunner最佳實戰(zhàn) 連載八

　9.5.4  驗收測試方案索引目錄結構

　　也許，有很多測試同行非常關心測試方案的編寫內容，這里以我的方案為樣本，給大家做一些介紹。

　　以下內容為某項目的驗收測試方案索引目錄結構。

　　1. 引言

　　1.1 編寫目的

　　1.2 項目背景

　　1.3 預期讀者

　　1.4 參考文檔

　　1.5 名詞定義

　　1.5.1 驗收測試

　　1.5.2 管理方

　　1.5.3 用戶方

　　1.5.4 開發(fā)方

　　1.5.5 應用系統(tǒng)

　　2. 系統(tǒng)簡介

　　2.1 某系統(tǒng)說明

　　3. 測試目標和標準

　　3.1 測試目標

　　3.2 測試重點

　　3.3 項目進入標準

　　3.4 項目完成標準

　　4. 測試需求分析

　　4.1 某系統(tǒng)的功能測試范圍

　　4.1.1 ……功能

　　…… ……功能

　　4.2 某系統(tǒng)的文檔測試范圍

　　4.3 某系統(tǒng)的性能測試范圍

　　5. 測試策略

　　5.1 策略說明

　　5.2 性能測試

　　5.2.1 測試內容

　　5.2.2 測試方法

　　5.2.3 性能驗證指標

　　5.2.4 性能測試前提條件

　　5.2.5 性能測試通過標準

　　5.3 功能測試

　　5.3.1 測試內容

　　5.3.2 測試方法

　　5.3.3 功能指標

　　5.3.4 功能測試問題級別定義

　　5.3.5 功能測試通過標準

　　5.3.6 功能測試中止條件

　　5.4 文檔驗收

　　5.4.1 驗收文檔內容

　　5.4.2 驗收文檔要求

　　5.4.3 文檔測試問題級別定義

　　5.4.4 文檔測試通過標準

　　5.4.5 文檔測試中止條件

　　6. 項目實施階段

　　6.1 項目實施階段描述

　　6.1.1 測試計劃階段

　　6.1.2 測試需求階段

　　6.1.3 測試設計階段

　　6.1.4 測試環(huán)境部署

　　6.1.5 第一輪測試執(zhí)行階段

　　6.1.6 第二輪測試執(zhí)行階段

　　6.1.7 測試總結階段

　　6.2 測試里程碑

　　6.2.1 進入標準測試

　　6.2.2 測試環(huán)境的搭建

　　6.2.3 業(yè)務培訓

　　6.2.4 制定測試計劃、測試需求準備

　　6.2.5 測試設計

　　6.2.6 必要測試工具的開發(fā)

　　6.2.7 用例評審

　　6.2.8 測試執(zhí)行

　　6.2.9 測試總結

　　7. 測試實施安排

　　7.1 工作流程

　　7.2 人員組織

　　7.3 人員配置

　　8. 測試計劃

　　8.1 測試工作量估算

　　8.2 測試時間進度表

　　9. 質量保證

　　9.1 需求與變更管理

　　9.2 配置管理

　　9.2.1 主要配置項

　　9.2.2 配置管理員的職責

　　9.2.3 配置庫結構

　　9.2.4 需提交的文檔名稱

　　9.2.5 文檔編碼規(guī)范

　　9.2.6 賬號管理

　　9.2.7 權限管理

　　9.2.8 備份計劃

　　9.3 項目變更管理

　　9.4 風險管理

　　9.4.1 風險類型

　　9.4.2 發(fā)生概率

　　9.4.3 風險影響

　　9.4.4 項目風險

　　10. 缺陷管理

　　10.1 管理權限

　　10.2 缺陷問題級別

　　10.2.1 功能測試問題級別定義

　　10.2.2 文檔測試問題級別定義

　　10.2.3 性能測試問題級別定義

　　10.3 缺陷的跟蹤與記錄

　　10.4 缺陷狀態(tài)定義

　　10.5 缺陷管理的流程

　　11. 項目溝通

　　11.1 例會

　　11.2 周報

　　12. 工作產品

　9.5.5  驗收測試方案的“引言”部分

　　下面針對該索引目錄結構的12個索引段落進行介紹。

　　“引言”主要包含了編寫目的、項目背景、預期讀者、參考文檔、名詞定義5部分內容。該索引段內容主要是介紹該方案的基本信息，明確相關需求的來源文檔（這些文檔的來源主要是3部分：甲方、系統(tǒng)研發(fā)單位和根據(jù)溝通后由我方編寫被確認的文檔），同時這部分內容闡述了項目的背景明確了預期的讀者、相關專業(yè)術語，使得相關讀者都能夠通過閱讀該文檔掌握整體方案的內容。

　　示范性文檔編寫內容介紹如下。

　　1.1 編寫目的

　　《甲方公司某系統(tǒng)驗收測試方案》（以下簡稱測試方案）闡述了乙方公司對本項目的理解，是測試工作實施的基本依據(jù)，提供測試方案文檔有助于使客戶了解如下內容：

　　明確的測試需求；

　　可采用的測試策略；

　　所需的資源及測試的工作量；

　　測試工作最終應達到的目的；

　　測試工作的風險及規(guī)避方法；

　　測試項目的可交付內容；

　　這里將甲方單位名稱以“甲方公司”進行替代，系統(tǒng)名稱也以“某”進行替代。而本單位名稱則以“乙方公司”進行替代，后續(xù)均以該處理方式進行，不再贅述。

　　1.2 項目背景

　　該部分內容主要對被測試的系統(tǒng)進行介紹，以及甲方為什么進行該系統(tǒng)進行測試進行描述，鑒于安全性等方面考慮，這里不再詳細贅述，讀者朋友依據(jù)項目實際情況進行編寫該部分內容。

　　1.3 預期讀者

　　甲方項目管理人員

　　甲方項目實施人員

　　乙方項目管理人員

　　乙方項目實施人員

　　項目開發(fā)方項目相關人員

　　1.4 參考文檔

　　參考文檔主要來源于甲方、系統(tǒng)研發(fā)單位和根據(jù)溝通后由我方編寫被確認的文檔，需要特別指出的是，您在列舉參考文檔時，需要明確文檔的作者、文檔文件最后修改的時間、文件存放的位置等，以便想讀者可以快速得到正確的文檔，進行閱讀。

　　1.5 名詞定義

　　1.5.1　驗收測試

　　驗收測試是系統(tǒng)開發(fā)生命周期方法論的一個階段，這時相關的用戶和/或獨立測試人員根據(jù)測試計劃和結果對系統(tǒng)進行測試和接收。它讓系統(tǒng)用戶決定是否接收系統(tǒng)。它是一項確定產品是否能夠滿足合同或用戶所規(guī)定需求的測試。通常驗收測試是由具有計算機應用系統(tǒng)測試評估能力具有法人資格的、獨立于用戶單位及開發(fā)單位的第三方來進行，一般對應用系統(tǒng)的需求分析、設計方案以及相關應用軟件和硬件設備的功能、性能、安全性等方面進行科學、公正和相對獨立的綜合測試評估。

　　1.5.2　管理方

　　管理方在這里是指負責組織和管理執(zhí)行驗收測試的單位。

　　1.5.3　用戶方

　　用戶方在這里是指應用系統(tǒng)的最終使用單位和運行維護單位。

　　1.5.4　開發(fā)方

　　開發(fā)方在這里是指承擔被測試的應用系統(tǒng)開發(fā)的單位。

　　1.5.5　應用系統(tǒng)

　　應用系統(tǒng)在這里是指由相關的軟、硬件構成，能夠為企業(yè)解決流程或工作中特定問題的系統(tǒng)，在本方案中指被測試的某系統(tǒng)。

　9.5.6  驗收測試方案的“系統(tǒng)介紹”部分

　　“系統(tǒng)簡介”索引段落內容主要是對被測試應用系統(tǒng)的功能、性能、文檔特性進行概括性的介紹。

　　9.5.7  驗收測試方案的“測試目標和標準”部分

　　“測試目標和標準”索引段落內容主要包括4部分內容：測試目標、測試重點、項目進入標準、項目完成標準。

　　示范性文檔編寫內容介紹如下。

　　3.1 測試目標

　　某單位某系統(tǒng)驗收測試的目標是：以《某單位某系統(tǒng)需求規(guī)格說明書》、《某單位某系統(tǒng)程序設計說明書》及所有經某單位確認的需求為基準，在規(guī)定的時間范圍內，從應用系統(tǒng)的功能性開展驗收測試，以驗證系統(tǒng)功能、文檔、性能是否符合用戶要求，按約定期限提交被測系統(tǒng)是否可以進入生產運行的評估報告，為用戶是否接受系統(tǒng)提供決策依據(jù)。

　　3.2 測試重點

　　該部分內容您可以依據(jù)驗收測試的用戶實際需求，進行描述，這里不再贅述。

　　3.3 項目進入標準

　　項目進入標準是接收被測系統(tǒng)進入測試的必要條件和基礎，項目進入標準的主要內容如下：

　　合同簽署完畢，并開始執(zhí)行合同；

　　管理方已認可測試方的項目測試計劃（包括時間計劃）；

　　管理方準備好測試方要求的技術文檔、用戶文檔及相關說明書；

　　管理方及管理方協(xié)調的有關支持人員和相關業(yè)務人員已明確并到位；

　　管理方提供被測試的應用系統(tǒng)軟件的測試環(huán)境（包括軟件和硬件）；

　　管理方提交開發(fā)方的測試計劃、測試用例和測試報告；

　　管理方成立測試領導小組，指明專門負責人；

　　測試方相關人員到位。

　　3.4 項目完成標準

　　符合以下全部條件時，驗收測試工作視同結束：

　　系統(tǒng)不存在致命性錯誤和嚴重性錯誤；

　　告警性錯誤在測試用例數(shù)的1%以內；

　　系統(tǒng)重要功能模塊不再含有告警性錯誤；

　　通過管理方的驗收工作。

　　9.5.8  驗收測試方案的“測試需求分析”部分

　　“測試需求分析”索引段落內容，結合此次驗收測試的內容主要包括3部分內容，即：功能測試、文檔測試和性能測試。通常在這部分我們要明確測試的功能點、測試的文檔和性能測試需求范圍，以表格的形式列出相關內容（請參見表9-2、表9-3和表9-4），特別是在做性能測試相關內容時，因為很多用戶甚至是系統(tǒng)的研發(fā)方都沒有一個清晰明確的性能需求描述，這是就需要項目經理或者相應的技術人員明確該部分內容，以避免驗收測試完成后，產生不必要的分歧或者矛盾情況。

表9-2 功能測試范圍表

表9-3 測試文檔范圍表

注：在沒有特殊說明的情況下，所有文檔均從配置管理工具中獲取，請參考相關獲取路徑。

表9-4 性能測試范圍表

　　9.5.9  驗收測試方案的“測試策略”部分

　　“測試策略” 索引段落內容主要針對功能、文檔和性能測試的內容、測試方法、缺陷級別定義、測試前提條件和測試通過標準等內容進行了較詳細的描述。

　　示范性文檔編寫內容介紹如下。

　　5.1 策略說明

　　根據(jù)國家標準《GB/T16260—2006軟件工程產品質量》，軟件質量主要考察功能、效率、可靠、易用、移植、可維護等六個方面。同時結合本次測試的性質、系統(tǒng)特點和時間要求，以及對測試需求的分析，本次我方計劃針對某單位某系統(tǒng)從性能、文檔、功能三方面進行驗收測試工作。

　　5.2 性能測試

　　5.2.1 測試內容

　　根據(jù)需求分析報告和設計文檔提出的各項性能指標及某單位某系統(tǒng)一般性要求，檢測系統(tǒng)在各種負載情況下的響應、處理時間，及在業(yè)務量高峰期的承受能力等指標是否符合需求。性能測試分為性能測試、負載測試、壓力測試、配置測試、并發(fā)測試、容量測試、可靠性測試、失敗測試八種類型。

　　（1）性能測試是一種“正常”的測試，主要是測試正常使用時，系統(tǒng)是否滿足要求，同時可能為了保留系統(tǒng)的擴展空間進行一些稍稍超出“正常”范圍的測試。

　　（2）負載測試：通過逐步增加系統(tǒng)負載，測試系統(tǒng)性能的變化，并最終確定在滿足系統(tǒng)的性能指標情況下，系統(tǒng)所能夠承受的最大負載量。簡而言之，負載測試是通過逐步加壓的方式來確定系統(tǒng)的處理能力，確定系統(tǒng)能夠承受的各項閾值。例如，逐步加壓，從而得到“響應時間不超過10秒”，“服務器平均CPU利用率低于85%”等指標的閾值。

　　（3）壓力測試：通過逐步增加系統(tǒng)負載，測試系統(tǒng)性能的變化，并最終確定在什么負載條件下系統(tǒng)性能處于失效狀態(tài)，并獲得系統(tǒng)能提供的最大服務級別。壓力測試是逐步增加負載，使系統(tǒng)某些資源達到飽和甚至失效的測試。

　　其他的性能測試分類為。

　　（4）配置測試：主要是通過對被測試軟件的軟、硬件配置的測試，找到系統(tǒng)各項資源的最優(yōu)分配原則。

　　（5）并發(fā)測試：測試多個用戶同時訪問同一個應用、同一個模塊或者數(shù)據(jù)記錄時是否存在死鎖或者其他性能問題，幾乎所有的性能測試都會涉及一些并發(fā)測試。

　　（6）容量測試：測試系統(tǒng)能夠處理的最大會話能力，確定系統(tǒng)可處理同時在線的最大用戶數(shù)，通常和數(shù)據(jù)庫有關。

　　（7）可靠性測試：通過給系統(tǒng)加載一定的業(yè)務壓力（如CPU資源在70%～90%的使用率）的情況下，運行一段時間，檢查系統(tǒng)是否穩(wěn)定。因為運行時間較長，通常可以測試出系統(tǒng)是否有內存泄漏等問題。

　　（8）失敗測試：對于有冗余備份和負載均衡的系統(tǒng)，通過這樣的測試來檢驗如果系統(tǒng)局部發(fā)生故障，用戶是否能夠繼續(xù)使用系統(tǒng)，用戶受到多大的影響，如幾臺機器做均衡負載，測試一臺或幾臺機器垮掉后，系統(tǒng)能夠承受的壓力。

　　5.2.2 測試方法

　　分析、調研階段統(tǒng)計用戶使用習慣，編寫性能測試計劃；

　　結合業(yè)務分析、調研情況，設計系統(tǒng)性能模型；

　　設計階段將性能模型轉化為測試場景，使用壓力測試工具錄制并調試測試腳本，或自行編制壓力測試程序，同時準備測試數(shù)據(jù)；

　　實施階段運行測試場景，按照實際運行中統(tǒng)計的用戶并發(fā)量，設定每項壓力測試的起始業(yè)務并發(fā)數(shù)量，以及并發(fā)量遞增的梯度；參照系統(tǒng)的峰值設計需求，逐步對系統(tǒng)加壓至性能拐點；

　　針對性能測試執(zhí)行結果，進行分析，定位問題，對系統(tǒng)調優(yōu)，同環(huán)境回歸測試（可能進行多次，根據(jù)實際情況需要確定）；

　　編寫性能測試總結報告。

　　5.2.3 性能驗證指標

　　本次性能測試驗證如下指標：

　　系統(tǒng)業(yè)務處理容量（TPS）；

　　業(yè)務響應時間（秒）；

　　系統(tǒng)CPU占用率；

　　系統(tǒng)內存占用率；

　　系統(tǒng)I/O使用率。

　　5.2.4　性能測試前提條件

　　測試環(huán)境準備就緒（最好為生產環(huán)境或近似環(huán)境）；

　　應用系統(tǒng)開發(fā)完成，發(fā)布正式版本；

　　已經完成安裝配置測試，且系統(tǒng)可用；

　　應用系統(tǒng)經過軟、硬件配置調優(yōu)工作。

　　5.2.5　性能測試通過標準

　　在指定測試環(huán)境下，軟件性能等與業(yè)務需求一致；

　　沒有嚴重影響系統(tǒng)運行的性能問題。

5.3 功能測試

　　5.3.1 測試內容

　　功能測試分GUI測試、業(yè)務測試、異常測試、易用性測試四部分進行。

　　GUI測試檢驗用戶界面是否滿足用戶需求，是否符合軟件界面的通用設計原則。

　　業(yè)務測試檢驗軟件業(yè)務功能和業(yè)務流程是否滿足用戶需求，此項測試依據(jù)用戶需求說明進行。

　　異常測試檢驗在多用戶同時使用系統(tǒng)的情況下，業(yè)務功能是否可以正常執(zhí)行，是否會產生資源競爭、互斥等現(xiàn)象。

　　易用性測試從以下三個方面考慮：易操作性、易理解性、易學性。根據(jù)以上三個原則對系統(tǒng)進行測試。

　　易操作性的測試目的在于增加軟件操作的簡易性，讓用戶容易接受軟件，也方便用戶的日常使用；易理解性測試目的在于讓用戶能迅速了解軟件的操作流程；易學性測試目的在于讓用戶迅速學會操作軟件。

　　5.3.2 測試方法

　　采用黑盒測試技術，手工模式執(zhí)行測試，著眼于系統(tǒng)的功能，不考慮內部邏輯結構，針對軟件界面和業(yè)務功能進行測試。在充分了解系統(tǒng)架構和業(yè)務邏輯的基礎上，從不同的運行與控制條件等角度組合不同的輸入條件和預定結果，測試功能的執(zhí)行情況、業(yè)務流程執(zhí)行情況和信息反饋情況等，以找出軟件中可能存在的缺陷。按照系統(tǒng)功能說明，逐一設計正常測試用例和錯誤操作測試用例并執(zhí)行，測試中發(fā)現(xiàn)的問題及時提交到缺陷管理系統(tǒng)。

　　5.3.3 功能指標

　　本次功能測試驗證如下指標。

　　功能完整性：軟件產品完全滿足用戶要求的業(yè)務處理實現(xiàn)。

　　適合性：軟件產品為指定的任務和用戶要求提供了合適功能的實現(xiàn)。

　　準確性：軟件產品提供具有所需要精度的正確或相符的結果或效果的能力，特別是在多用戶使用情況下功能和業(yè)務流程是否能正常和準確執(zhí)行。

　　互操作性：軟件產品與相關系統(tǒng)進行交互的能力。

　　易用性：軟件產品易操作性、易理解性、易學性方面的能力。

　　可維護性：軟件產品可測試性、可修改性、可使用性。

　　5.3.4　功能測試問題級別定義

表9-5 功能測試問題級別定義

　　5.3.5 功能測試通過標準

　　軟件功能與業(yè)務需求要求一致；

　　沒有P1（致命性）問題與P2（嚴重性）問題，且P3（告警性）問題和P4（建議性）問題數(shù)量不高于測試方與用戶的預先協(xié)商值。

　　5.3.6 功能測試中止條件

　　功能測試過程中，如發(fā)生以下情況，則中止測試活動：

　　發(fā)現(xiàn)程序不是最新版本；

　　正確安裝后，發(fā)現(xiàn)主要模塊功能不能正常運行，且影響其他模塊的功能測試；

　　發(fā)現(xiàn)大量致命性問題，需要開發(fā)方立即修改。

　　測試中止后，開發(fā)方修改時間由某單位、測試方和開發(fā)方共同商定，修改完成后繼續(xù)實施功能測試。

　　5.4 文檔驗收

　　5.4.1　審查內容

　　文檔審查針項目立項、實施、運營維護等各環(huán)節(jié)中的關鍵文檔進行，受審查的文檔類型如表9-6所示，具體實施內容需與客戶協(xié)商后決定。

表9-6 受審查的文檔類型

　　目前已知需要驗收測試的文檔如表9-7所示。

表9-7 測試文檔范圍表

　　5.4.2　文檔要求

　　文檔完備性；

　　文檔內容充分性；

　　文字明確性；

　　文檔描述的正確性，聯(lián)機幫助文檔中鏈接的正確性；

　　易讀性；

　　檢查文檔間的一致性；

　　檢查程序和文檔的一致性；

　　檢查文檔間的可追溯性；

　　檢查文檔是否符合指定的相應模板和規(guī)范。

　　5.4.3 文檔測試問題級別定義

表9-8 文檔測試問題級別定義

　　5.4.4　文檔測試通過標準

　　文檔測試通過標準為，文檔測試關閉時不允許存在1、2級問題，3、4級問題的出現(xiàn)頻率為平均每6頁3個以內。

　　5.4.5 文檔測試中止條件

　　如任何一個被測試文檔在一頁當中出現(xiàn)超過16個任何等級的問題，該文檔即被視為不可用，立刻停止對該文檔的測試，交由文檔作者修改后再重新測試。

　　（未完待續(xù)）

版權聲明：51Testing軟件測試網及相關內容提供者擁有51testing.com內容的全部版權，未經明確的書面許可，任何人或單位不得對本網站內容復制、轉載或進行鏡像。51testing軟件測試網歡迎與業(yè)內同行進行有益的合作和交流，如果有任何有關內容方面的合作事宜，請聯(lián)系我們。

相關鏈接：

精通軟件性能測試與LoadRunner最佳實戰(zhàn) 連載一

精通軟件性能測試與LoadRunner最佳實戰(zhàn) 連載二

精通軟件性能測試與LoadRunner最佳實戰(zhàn) 連載三

精通軟件性能測試與LoadRunner最佳實戰(zhàn) 連載四

精通軟件性能測試與LoadRunner最佳實戰(zhàn) 連載五

精通軟件性能測試與LoadRunner最佳實戰(zhàn) 連載六

精通軟件性能測試與LoadRunner最佳實戰(zhàn) 連載七

posted on 2013-07-05 10:49 順其自然EVO 閱讀(370) 評論(0)  編輯  收藏 所屬分類: loadrunner