第7章_驗收測試

1、 第7章 驗收測試 7.1 驗收測試的主要內(nèi)容 7.2 驗收測試過程 7.3 驗收測試的常用策略 7.4 驗收測試報告 7.5 用戶驗收測試實例 7.1 驗收測試的主要內(nèi)容 驗收測試是部署軟件之前的最后一個測 試操作。 驗收測試的目的是：確保軟件準(zhǔn)備就緒， 并且可以讓最終用戶將其用于執(zhí)行軟件 的既定功能和任務(wù)。 驗收測試的任務(wù) 驗收測試是向未來的用戶表明系統(tǒng)能夠 像預(yù)定要求那樣工作。也就是驗證軟件 的有效性。 驗收測試的任務(wù)，即驗證軟件的功能和 性能如同用戶所合理期待的那樣。 驗收測試的主要內(nèi)容 驗收測試的主要內(nèi)容有以下幾個方面: 制定驗收測試標(biāo)準(zhǔn)制定驗收測試標(biāo)準(zhǔn) 配置項復(fù)審配置項復(fù)審 1.1

2、. 實施驗收測試實施驗收測試 驗收測試主要內(nèi)容制定驗收標(biāo)準(zhǔn) 實現(xiàn)軟件確認(rèn)要通過一系列測試。驗收測試同 樣需要制訂測試計劃和過程。 測試計劃應(yīng)規(guī)定測試的種類和測試進(jìn)度，測試 過程則定義一些特殊的測試用例，為的是在說 明軟件與合同要求是否一致。 無論是計劃還是過程，都應(yīng)該著重考慮以下幾 個方面： 軟件是否滿足合同規(guī)定的所有功能和性能軟件是否滿足合同規(guī)定的所有功能和性能 文檔資料是否完整文檔資料是否完整 準(zhǔn)確人機界面準(zhǔn)確人機界面 1.1. 其他方面（例如，可移植性、兼容性、錯誤恢復(fù)能其他方面（例如，可移植性、兼容性、錯誤恢復(fù)能 力和可維護(hù)性等）是否令用戶滿意。力和可維護(hù)性等）是否令用戶滿意。 驗收測

3、試主要內(nèi)容實施驗收測試 驗收測試的準(zhǔn)備工作做好之后，就要進(jìn) 入驗收測試的實施階段。 在此階段里，需要采用一些常用的驗收 測試策略進(jìn)行，例如：測試，測試等。 實施驗收測試是整個驗收測試過程中的 核心部分。 alpha測試和beta測試的區(qū)別 定義：alpha測試是在用戶組織模擬軟件系統(tǒng) 的運行環(huán)境下的一種驗收測試，由用戶或第三 方測試公司進(jìn)行的測試，模擬各類用戶行為對 即將面市的軟件產(chǎn)品進(jìn)行測試，試圖發(fā)現(xiàn)并修 改錯誤。 Beta測試是用戶公司組織各方面的典型終端用 戶在日常工作中實際使用beta版本，并要求用 戶報告異常情況，提出批評意見。 驗收測試主要內(nèi)容配置項復(fù)審 驗收測試的另一個重要環(huán)節(jié)是

4、配置項復(fù) 審。在進(jìn)行驗收測試之前，必須保證所 有軟件配置項都能進(jìn)入驗收測試，只有 這樣才能保證最終交付給用戶的軟件產(chǎn) 品完整性和有效性。 復(fù)審的目的：保證軟件配置齊全、分類 有序，并且包括軟件維護(hù)所必須的細(xì)節(jié)。 第7章 驗收測試 7.1 驗收測試的主要內(nèi)容 7.2 驗收測試過程 7.3 驗收測試的常用策略 7.4 驗收測試報告 7.5 用戶驗收測試實施 7.2 驗收測試過程 進(jìn)行驗收測試，必須要了解驗收測試的 過程。只有按照驗收過程的步驟進(jìn)行， 才能保證驗收測試的順利實施。 驗收測試過程的主要內(nèi)容 軟件需求分析：軟件需求分析：了解軟件功能和性能要求、軟硬 件環(huán)境要求等，并特別要了解軟件的質(zhì)量要

5、求和 驗收要求。 編制編制驗收測試計劃驗收測試計劃和和項目驗收準(zhǔn)則項目驗收準(zhǔn)則：根 據(jù)軟件需求和驗收要求編制測試計劃，制定需測 試的測試項，制定測試策略及驗收通過準(zhǔn)則，并 經(jīng)過客戶參與的計劃評審。 測試設(shè)計和測試用例設(shè)計：測試設(shè)計和測試用例設(shè)計：根據(jù)驗收測試計劃 和項目驗收準(zhǔn)則編制測試用例，并經(jīng)過評審。 驗收測試過程的主要內(nèi)容（續(xù)） 測試環(huán)境搭建：測試環(huán)境搭建：建立測試的硬件環(huán)境、軟件環(huán)境 等。（可在委托客戶提供的環(huán)境中進(jìn)行測試） 測試實施：測試實施：測試并記錄測試結(jié)果。 測試結(jié)果分析：測試結(jié)果分析：根據(jù)驗收通過準(zhǔn)則分析測試結(jié)果， 作出驗收是否通過及測試評價。 測試報告：測試報告：根據(jù)測試結(jié)果

6、編制缺陷報告和驗收測 試報告，并提交給客戶。 驗收測試過程流程圖 圖 7-1 驗收測試過程流程圖 驗收測試步驟 步驟步驟1 1：驗收測試業(yè)務(wù)恰談：驗收測試業(yè)務(wù)恰談 雙方就測試項目及合同進(jìn)行洽談 步驟步驟2 2：簽訂測試合同：簽訂測試合同 步驟步驟3 3：開發(fā)方提交測試樣品及相關(guān)資料：開發(fā)方提交測試樣品及相關(guān)資料 開發(fā)方需提交的文檔有： 基本文檔：（驗收測試必需的文檔），用戶手冊，安裝手 冊，操作手冊，維護(hù)手冊，軟件開發(fā)合同，需求規(guī)格說明 書，軟件設(shè)計說明，軟件樣品（可刻錄在光盤） 特殊文檔：（根據(jù)測試內(nèi)容不同，委托方所需提交下列相 應(yīng)的文檔），軟件產(chǎn)品開發(fā)過程中的測試記錄，軟件產(chǎn)品 源代碼。

7、驗收測試步驟（續(xù)） 步驟步驟4 4：開發(fā)方提交測試樣品及相關(guān)資料：開發(fā)方提交測試樣品及相關(guān)資料 步驟步驟5 5：編制測試計劃并通過評審：編制測試計劃并通過評審 步驟步驟6 6：進(jìn)行項目相關(guān)知識培訓(xùn)：進(jìn)行項目相關(guān)知識培訓(xùn) 步驟步驟7 7：測試設(shè)計：測試設(shè)計 評測中心編制測試方案和設(shè)計測試用例集。 步驟步驟8 8：方案評審：方案評審 評測中心測試組成員、委托方代表一起對測 試方案進(jìn)行評審。 驗收測試步驟（續(xù)） 步驟步驟9 9：實施測試：實施測試 評測中心對測試方案進(jìn)行整改，并實施測試。在測 試過程中每日提交測試事件報告給委托方。 步驟步驟1010：編制驗收測試報告并組織評審：編制驗收測試報告并組織

8、評審 評測中心編制驗收測試報告，并組織內(nèi)部評審。 步驟步驟1111：提交驗收測試報告：提交驗收測試報告 評測中心提交驗收測試報告。 第7章 驗收測試 7.1 驗收測試的主要內(nèi)容 7.2 驗收測試過程 7.3 驗收測試的常用策略 7.4 驗收測試報告 7.5 用戶驗收測試實施 7.3 驗收測試的常用策略 施驗收測試的常用策略有三種，它們分 別是： 正式驗收測試正式驗收測試 非正式驗收或非正式驗收或 測試測試 測試測試 選擇的策略通常建立在合同需求、組織 和公司標(biāo)準(zhǔn)以及應(yīng)用領(lǐng)域的基礎(chǔ)上。 正式驗收測試 正式驗收測試是一項管理嚴(yán)格的過程，它通常 是系統(tǒng)測試的延續(xù)。計劃和設(shè)計這些測試的周 密和詳細(xì)程度

9、不亞于系統(tǒng)測試。選擇的測試用 例應(yīng)該是系統(tǒng)測試中所執(zhí)行測試用例的子集 正式驗收測試的兩種方式兩種方式： 在某些組織中，開發(fā)組織（或其獨立的測試小組）在某些組織中，開發(fā)組織（或其獨立的測試小組） 與最終用戶組織的代表一起執(zhí)行驗收測試。與最終用戶組織的代表一起執(zhí)行驗收測試。 在其他組織中，驗收測試則完全由最終用戶組織執(zhí)在其他組織中，驗收測試則完全由最終用戶組織執(zhí) 行，或者由最終用戶組織選擇人員組成一個客觀公行，或者由最終用戶組織選擇人員組成一個客觀公 正的小組來執(zhí)行。正的小組來執(zhí)行。 正式驗收測試（續(xù)） 正式驗收測試形式的優(yōu)點優(yōu)點包括： 要測試的功能和特性都是已知的。 測試的細(xì)節(jié)是已知的并且可以對

10、其進(jìn)行評測。 這種測試可以自動執(zhí)行，支持回歸測試。 可以對測試過程進(jìn)行評測和監(jiān)測。 可接受性標(biāo)準(zhǔn)是已知的。 正式驗收測試形式的缺點缺點包括： 要求大量的資源和計劃。 這些測試可能是系統(tǒng)測試的再次實施。 1. 可能無法發(fā)現(xiàn)軟件中由于主觀原因造成的缺陷， 這是因為您只查找預(yù)期要發(fā)現(xiàn)的缺陷。 非正式驗收或 測試 在非正式驗收測試中，執(zhí)行測試過程的限定不 象正式驗收測試中那樣嚴(yán)格。在此測試中，確 定并記錄要研究的功能和業(yè)務(wù)任務(wù)，但沒有可 以遵循的特定測試用例。測試內(nèi)容由各測試員測試內(nèi)容由各測試員 決定。決定。 這種驗收測試方法不象正式驗收測試那樣組織 有序，而且更為主觀。 大多數(shù)情況下，非正式驗收測試

11、是由最終用戶 組織執(zhí)行的。 非正式驗收或 測試（續(xù)） 非正式驗收或 測試的優(yōu)點優(yōu)點包括： 要測試的功能和特性都是已知的。 可以對測試過程進(jìn)行評測和監(jiān)測。 可接受性標(biāo)準(zhǔn)是已知的。 與正式驗收測試相比，可以發(fā)現(xiàn)更多由于主觀原因造成的缺 陷。 非正式驗收或 測試的缺點缺點包括： 要求資源、計劃和管理資源。 無法控制所使用的測試用例。 最終用戶可能沿用系統(tǒng)工作的方式，并可能無法發(fā)現(xiàn)缺陷。 最終用戶可能專注于比較新系統(tǒng)與遺留系統(tǒng)，而不是專注于 查找缺陷。 1. 用于驗收測試的資源不受項目的控制，并且可能受到壓縮。 測試 在上述三種驗收測試策略中， 測試需要的控 制是最少的。在 測試中，采用的細(xì)節(jié)多少、

12、數(shù)據(jù)和方法完全由各測試員決定。各測試員負(fù)各測試員負(fù) 責(zé)創(chuàng)建自己的環(huán)境、選擇數(shù)據(jù)，并決定要研究責(zé)創(chuàng)建自己的環(huán)境、選擇數(shù)據(jù)，并決定要研究 的功能、特性或任務(wù)的功能、特性或任務(wù)。各測試員負(fù)責(zé)確定自己各測試員負(fù)責(zé)確定自己 對于系統(tǒng)當(dāng)前狀態(tài)的接受標(biāo)準(zhǔn)。對于系統(tǒng)當(dāng)前狀態(tài)的接受標(biāo)準(zhǔn)。 測試由最終用戶實施，通常開發(fā)（或其他非 最終用戶）組織對其的管理很少或不進(jìn)行管理。 測試是所有驗收測試策略中最主觀的。 測試（續(xù)） 測試的優(yōu)點優(yōu)點是： 測試由最終用戶實施。 大量的潛在測試資源。 提高客戶對參與人員的滿意程度。 與正式或非正式驗收測試相比，可以發(fā)現(xiàn)更多由于主觀原因 造成的缺陷。 測試的缺點缺點是： 未對所有功能

13、和/或特性進(jìn)行測試。 測試流程難以評測。 最終用戶可能沿用系統(tǒng)工作的方式，并可能沒有發(fā)現(xiàn)或沒有 報告缺陷。 最終用戶可能專注于比較新系統(tǒng)與遺留系統(tǒng)，而不是專注于 查找缺陷。 用于驗收測試的資源不受項目的控制，并且可能受到壓縮。 可接受性標(biāo)準(zhǔn)是未知的。 1. 需要更多輔助性資源來管理 測試員。 第7章 驗收測試 7.1 驗收測試的主要內(nèi)容 7.2 驗收測試過程 7.3 驗收測試的常用策略 7.4 驗收測試報告 7.5 用戶驗收測試實施 7.4 驗收測試報告 做為測試的結(jié)果，需要給出測試報告。 驗收測試也不例外。 在驗收測試的結(jié)束部分，需要以文檔的 形式提供“驗收測試報告”做為對驗收 測試結(jié)果的一

14、個書面說明。 驗收報告的模板 驗收報告一般分為三個部分：頭部，主體，尾部 驗收報告的頭部應(yīng)該標(biāo)明項目的一些基本信息，參考 格式如下： 項目驗收報告 項目名稱： 產(chǎn)品名稱： 產(chǎn)品版本： 客戶名稱： 供應(yīng)方： 驗收日期： 驗收報告的模板（續(xù)） 驗收報告主體內(nèi)容可以 參考以下的模板格式： 目錄 . 1 前言 1.1 編寫目的 . 1.2 項目背景 . 2 功能驗收 驗收項類別 驗收項名 稱 說明 是否通過驗收 備注 3 性能驗收 驗收項類別 驗收項名 稱 說明 是否通過驗收 備注 4 交付物驗收 驗收項類別 驗收項名 稱 說明 是否通過驗收 備注 硬 件 軟 件(安裝光盤) 文 檔 . 5 驗收結(jié)論

15、 . 驗收報告模板（續(xù)） 在驗收報告的尾部，需要注明驗收報告 的時間，驗收單位（個人）等驗收測試 相關(guān)信息。參考格式如下： 驗收方： 提供方： 項目負(fù)責(zé)人簽字： 項目負(fù)責(zé)人簽字： 日期： 日期： 第7章 驗收測試 7.1 驗收測試的主要內(nèi)容 7.2 驗收測試過程 7.3 驗收測試的常用策略 7.4 驗收測試報告 7.5 用戶驗收測試實施 7.5 用戶驗收測試實施 用戶驗收測試可以分為兩個大的部分： 軟件配置審核和可執(zhí)行程序測試，其大 致順序可分為： 文檔審核 源代碼審核 配置腳本審核 測試程序或腳本審核 可執(zhí)行程序測試。 軟件配置審核： 對于一個外包的軟件項目而言，軟件承 包方通常要提供如下相

16、關(guān)的軟件配置內(nèi)容： 可執(zhí)行程序 源程序 配置腳本 測試程序或腳本。 主要的開發(fā)類文檔： 需求分析說明書 概要設(shè)計說明書 詳細(xì)設(shè)計說明書 數(shù)據(jù)庫設(shè)計說明書 測試計劃 測試報告 程序維護(hù)手冊 程序員開發(fā)手冊 用戶操作手冊 項目總結(jié)報告。 主要的管理類文檔： 項目計劃書 質(zhì)量控制計劃 配置管理計劃 用戶培訓(xùn)計劃 質(zhì)量總結(jié)報告 評審報告 會議記錄 開發(fā)進(jìn)度月報 7.5 用戶驗收測試實施(續(xù)) 在開發(fā)類文檔中，容易被忽視的文檔有程序 維護(hù)手冊和程序員開發(fā)手冊。 程序維護(hù)手冊的主要內(nèi)容包括：系統(tǒng)說明 （包括程序說明）、操作環(huán)境、維護(hù)過程、源 代碼清單等，編寫目的是為將來的維護(hù)、修改 和再次開發(fā)工作提供有用

17、的技術(shù)信息。 程序員開發(fā)手冊的主要內(nèi)容包括：系統(tǒng)目標(biāo)、 開發(fā)環(huán)境使用說明、測試環(huán)境使用說明、編碼 規(guī)范及相應(yīng)的流程等，實際上就是程序員的培 訓(xùn)手冊。 7.5 用戶驗收測試實施(續(xù)) 通常，正式的審核過程分為5個步驟： 計劃 預(yù)備會議（可選）：對審核內(nèi)容進(jìn)行介紹并 討論 準(zhǔn)備階段：各責(zé)任人事先審核并記錄發(fā)現(xiàn)的 問題 審核會議：最終確定工作產(chǎn)品中包含的錯誤 和缺陷 問題追蹤 7.5 用戶驗收測試實施(續(xù)) 審核要達(dá)到的基本目標(biāo)是： 根據(jù)共同制定的審核表，盡可能地發(fā)現(xiàn) 被審核內(nèi)容中存在的問題，并最終得到 解決。 在根據(jù)相應(yīng)的審核表進(jìn)行文檔審核和源 代碼審核時，還要注意文檔與源代碼的 一致性。 7.5

18、 用戶驗收測試實施(續(xù)) 在文檔審核、源代碼審核、配置腳本審核、測 試程序或腳本審核都順利完成后，就可以進(jìn)行 驗收測試的最后一個步驟可執(zhí)行程序的測試。 可執(zhí)行程序的測試包括功能、性能等方面的測 試，每種測試也都包括目標(biāo)、啟動標(biāo)準(zhǔn)、活動、 完成標(biāo)準(zhǔn)和度量等五部分。 要注意的是不能直接使用開發(fā)方提供的可執(zhí)行 程序用于測試，而要按照開發(fā)方提供的編譯步 驟，從源代碼重新生成可執(zhí)行程序。 7.5 用戶驗收測試實施(續(xù)) 在真正進(jìn)行用戶驗收測試之前一般應(yīng)該已經(jīng)完成了以下 工作（也可以根據(jù)實際情況有選擇地采用或增加）： 軟件開發(fā)已經(jīng)完成，并全部解決了已知的軟件缺陷。 驗收測試計劃已經(jīng)過評審并批準(zhǔn)，并且置于文檔控制之下。 對軟件需求說明書的審查已經(jīng)完成。 對概要設(shè)計、詳細(xì)設(shè)計的審查已經(jīng)完成。 對所有關(guān)鍵模塊的代碼審查已經(jīng)完成。 對單元、集成、系統(tǒng)測試計劃和報告的審查已經(jīng)完成。 所有的測試腳本已完成，并至少執(zhí)行過一次，且通過評審。 使用配置管理工具且代碼置于配置控制之下。 軟件問題處理流程已經(jīng)就緒。 已經(jīng)制定、評審并批準(zhǔn)驗收測試完成標(biāo)準(zhǔn)。 具體的測試內(nèi)容通?？梢园ǎ?安裝（升級） 啟動與關(guān)機 功能測試（正例、重要算法、邊界、時序、反 例、錯誤處理） 性能測試（正常的負(fù)載、容量變化）