驗收測試的主要內容
驗收測試過程
驗收測試的常用策略
驗收測試報告
用戶驗收測試實例
1、驗收測試的主要內容
● 驗收測試是部署軟件之前的最后一個測試操作。
● 驗收測試的目的是：確保軟件準備就緒，并且可以讓最終用戶將其用于執行軟件的既定功能和任務。
驗收測試的任務
● 驗收測試是向未來的用戶表明系統能夠像預定要求那樣工作。也就是驗證軟件的有效性。
● 驗收測試的任務，即驗證軟件的功能和性能如同用戶所合理期待的那樣。
驗收測試的主要內容
● 驗收測試的主要內容有以下幾個方面：
1.制定驗收測試標準
2.配置項復審
3.實施驗收測試
驗收測試主要內容——制定驗收標準
● 實現軟件確認要通過一系列測試。驗收測試同樣需要制訂測試計劃和過程。
● 測試計劃應規定測試的種類和測試進度，測試過程則定義一些特殊的測試用例，為的是在說明軟件與合同要求是否一致。
● 無論是計劃還是過程，都應該著重考慮以下幾個方面：
1.軟件是否滿足合同規定的所有功能和性能
2.文檔資料是否完整
3.準確人機界面
4.其他方面（例如，可移植性、兼容性、錯誤恢復能力和可維護性等）是否令用戶滿意。
● 驗收測試主要內容——實施驗收測試
● 驗收測試的準備工作做好之后，就要進入驗收測試的實施階段。
● 在此階段里，需要采用一些常用的驗收測試策略進行，例如：α測試，β測試等。
● 實施驗收測試是整個驗收測試過程中的核心部分。
驗收測試主要內容——配置項復審
● 驗收測試的另一個重要環節是配置項復審。在進行驗收測試之前，必須保證所有軟件配置項都能進入驗收測試，只有這樣才能保證最終交付給用戶的軟件產品完整性和有效性。
● 復審的目的：保證軟件配置齊全、分類有序，并且包括軟件維護所必須的細節。
2、驗收測試過程
● 進行驗收測試，必須要了解驗收測試的過程。只有按照驗收過程的步驟進行，才能保證驗收測試的順利實施。
驗收測試過程的主要內容
1.軟件需求分析：了解軟件功能和性能要求、軟硬件環境要求等，并特別要了解軟件的質量要求和驗收要求。
2.編制《驗收測試計劃》和《項目驗收準則》：根據軟件需求和驗收要求編制測試計劃，制定需測試的測試項，制定測3.試策略及驗收通過準則，并經過客戶參與的計劃評審。
3.測試設計和測試用例設計：根據《驗收測試計劃》和《項目驗收準則》編制測試用例，并經過評審。
4.測試環境搭建：建立測試的硬件環境、軟件環境等。（可在委托客戶提供的環境中進行測試）
5.測試實施：測試并記錄測試結果。
6.測試結果分析：根據驗收通過準則分析測試結果，作出驗收是否通過及測試評價。
7.測試報告：根據測試結果編制缺陷報告和驗收測試報告，并提交給客戶。
驗收測試過程流程圖
驗收測試步驟
步驟1：驗收測試業務恰談
雙方就測試項目及合同進行洽談
步驟2：簽訂測試合同
步驟3：開發方提交測試樣品及相關資料
開發方需提交的文檔有：
基本文檔：（驗收測試必需的文檔），用戶手冊，安裝手冊，操作手冊，維護手冊，軟件開發合同，需求規格說明書，軟件設計說明，軟件樣品（可刻錄在光盤）
特殊文檔：（根據測試內容不同，委托方所需提交下列相應的文檔），軟件產品開發過程中的測試記錄，軟件產品源代碼。
步驟4：開發方提交測試樣品及相關資料
步驟5：編制測試計劃并通過評審
步驟6：進行項目相關知識培訓
步驟7：測試設計
評測中心編制測試方案和設計測試用例集。
步驟8：方案評審
評測中心測試組成員、委托方代表一起對測試方案進行評審。
步驟9：實施測試
評測中心對測試方案進行整改，并實施測試。在測試過程中每日提交測試事件報告給委托方。
步驟10：編制驗收測試報告并組織評審
評測中心編制驗收測試報告，并組織內部評審。
步驟11：提交驗收測試報告
評測中心提交驗收測試報告。
3、驗收測試的常用策略
● 施驗收測試的常用策略有三種，它們分別是：
1.正式驗收測試
2.非正式驗收或 α 測試
3.β 測試
● 選擇的策略通常建立在合同需求、組織和公司標準以及應用領域的基礎上。
正式驗收測試
● 正式驗收測試是一項管理嚴格的過程，它通常是系統測試的延續。計劃和設計這些測試的周密和詳細程度不亞于系統測試。選擇的測試用例應該是系統測試中所執行測試用例的子集
1.正式驗收測試的兩種方式：
2.在某些組織中，開發組織（或其獨立的測試小組）與最終用戶組織的代表一起執行驗收測試。
在其他組織中，驗收測試則完全由最終用戶組織執行，或者由最終用戶組織選擇人員組成一個客觀公正的小組來執行。
● 正式驗收測試形式的優點包括：
1.要測試的功能和特性都是已知的。
2.測試的細節是已知的并且可以對其進行評測。
3.這種測試可以自動執行，支持回歸測試。
4.可以對測試過程進行評測和監測。
5.可接受性標準是已知的。
● 正式驗收測試形式的缺點包括：
1.要求大量的資源和計劃。
2.這些測試可能是系統測試的再次實施。
3.可能無法發現軟件中由于主觀原因造成的缺陷，這是因為您只查找預期要發現的缺陷。
非正式驗收或 α 測試
● 在非正式驗收測試中，執行測試過程的限定不象正式驗收測試中那樣嚴格。在此測試中，確定并記錄要研究的功能和業務任務，但沒有可以遵循的特定測試用例。測試內容由各測試員決定。
● 這種驗收測試方法不象正式驗收測試那樣組織有序，而且更為主觀。
● 大多數情況下，非正式驗收測試是由最終用戶組織執行的。
● 非正式驗收或 α 測試的優點包括：
1.要測試的功能和特性都是已知的。
2.可以對測試過程進行評測和監測。
3.可接受性標準是已知的。
4.與正式驗收測試相比，可以發現更多由于主觀原因造成的缺陷。
● 非正式驗收或 α 測試的缺點包括：
1.要求資源、計劃和管理資源。
2.無法控制所使用的測試用例。
3.最終用戶可能沿用系統工作的方式，并可能無法發現缺陷。
4.最終用戶可能專注于比較新系統與遺留系統，而不是專注于查找缺陷。
5.用于驗收測試的資源不受項目的控制，并且可能受到壓縮。
● β 測試
在上述三種驗收測試策略中， β 測試需要的控制是最少的。在 β測試中，采用的細節多少、數據和方法完全由各測試員決定。各測試員負責創建自己的環境、選擇數據，并決定要研究的功能、特性或任務。各測試員負責確定自己對于系統當前狀態的接受標準。
● β 測試由最終用戶實施，通常開發（或其他非最終用戶）組織對其的管理很少或不進行管理。
● β測試是所有驗收測試策略中最主觀的。
● β 測試的優點是：
1.測試由最終用戶實施。
2.大量的潛在測試資源。
3.提高客戶對參與人員的滿意程度。
4.與正式或非正式驗收測試相比，可以發現更多由于主觀原因造成的缺陷。
● β 測試的缺點是：
1.未對所有功能和/或特性進行測試。
2.測試流程難以評測。
3.最終用戶可能沿用系統工作的方式，并可能沒有發現或沒有報告缺陷。
4.最終用戶可能專注于比較新系統與遺留系統，而不是專注于查找缺陷。
5.用于驗收測試的資源不受項目的控制，并且可能受到壓縮。
6.可接受性標準是未知的。
7.需要更多輔助性資源來管理β 測試員。
4、驗收測試報告
● 做為測試的結果，需要給出測試報告。驗收測試也不例外。
● 在驗收測試的結束部分，需要以文檔的形式提供“驗收測試報告”做為對驗收測試結果的一個書面說明。
驗收報告的模板
● 驗收報告一般分為三個部分：頭部，主體，尾部
● 驗收報告的頭部應該標明項目的一些基本信息，參考格式如下：
項目驗收報告
項目名稱：
產品名稱：
產品版本：
客戶名稱：
供應方：
驗收日期：
● 驗收報告主體內容可以參考以下的模板格式：
目錄
....
1 前言
1.1 編寫目的
...
1.2 項目背景
...
2 功能驗收
驗收項類別 驗收項名稱 說明 是否通過驗收 備注
3 性能驗收
驗收項類別 驗收項名稱 說明 是否通過驗收 備注
4 交付物驗收
驗收項類別 驗收項名稱 說明 是否通過驗收 備注
硬 件
軟 件(安裝光盤)
文 檔
......
5 驗收結論
......
● 在驗收報告的尾部，需要注明驗收報告的時間，驗收單位（個人）等驗收測試相關信息。參考格式如下：
驗收方： 提供方：
項目負責人簽字： 項目負責人簽字：
日期： 日期：
5、用戶驗收測試實施
用戶驗收測試可以分為兩個大的部分：軟件配置審核和可執行程序測試，其大致順序可分為：
1.文檔審核
2.源代碼審核
3.配置腳本審核
4.測試程序或腳本審核
5.可執行程序測試。
軟件配置審核：
對于一個外包的軟件項目而言，軟件承包方通常要提供如下相關的軟件配置內容：
―可執行程序
―源程序
―配置腳本
―測試程序或腳本。
● 主要的開發類文檔：
《需求分析說明書》
《概要設計說明書》
《詳細設計說明書》
《數據庫設計說明書》
《測試計劃》
《測試報告》
《程序維護手冊》
《程序員開發手冊》
《用戶操作手冊》
《項目總結報告》
● 主要的管理類文檔：
《項目計劃書》
《質量控制計劃》
《配置管理計劃》
《用戶培訓計劃》
《質量總結報告》
《評審報告》
《會議記錄》
《開發進度月報》
● 在開發類文檔中，容易被忽視的文檔有《程序維護手冊》和《程序員開發手冊》。
《程序維護手冊》的主要內容包括：系統說明（包括程序說明）、操作環境、維護過程、源代碼清單等，編寫目的是為將來的維護、修改和再次開發工作提供有用的技術信息。
《程序員開發手冊》的主要內容包括：系統目標、開發環境使用說明、測試環境使用說明、編碼規范及相應的流程等，實際上就是程序員的培訓手冊。
● 通常，正式的審核過程分為5個步驟：
計劃
預備會議（可選）：對審核內容進行介紹并討論
準備階段：各責任人事先審核并記錄發現的問題
審核會議：最終確定工作產品中包含的錯誤和缺陷
問題追蹤
審核要達到的基本目標是：
根據共同制定的審核表，盡可能地發現被審核內容中存在的問題，并最終得到解決。
在根據相應的審核表進行文檔審核和源代碼審核時，還要注意文檔與源代碼的一致性。
在文檔審核、源代碼審核、配置腳本審核、測試程序或腳本審核都順利完成后，就可以進行驗收測試的最后一個步驟—可執行程序的測試。
可執行程序的測試包括功能、性能等方面的測試，每種測試也都包括目標、啟動標準、活動、完成標準和度量等五部分。
要注意的是不能直接使用開發方提供的可執行程序用于測試，而要按照開發方提供的編譯步驟，從源代碼重新生成可執行程序。
在真正進行用戶驗收測試之前一般應該已經完成了以下工作（也可以根據實際情況有選擇地采用或增加）：
軟件開發已經完成，并全部解決了已知的軟件缺陷。
驗收測試計劃已經過評審并批準，并且置于文檔控制之下。
對軟件需求說明書的審查已經完成。
對概要設計、詳細設計的審查已經完成。
對所有關鍵模塊的代碼審查已經完成。
對單元、集成、系統測試計劃和報告的審查已經完成。
所有的測試腳本已完成，并至少執行過一次，且通過評審。
使用配置管理工具且代碼置于配置控制之下。
軟件問題處理流程已經就緒。
已經制定、評審并批準驗收測試完成標準。
具體的測試內容通常可以包括：
● 安裝（升級）
● 啟動與關機
● 功能測試（正例、重要算法、邊界、時序、反例、錯誤處理）
● 性能測試（正常的負載、容量變化）
● 壓力測試（臨界的負載、容量變化）
● 配置測試、平臺測試、安全性測試、恢復測試（在出現掉電、硬件故障或切換、網絡故障等情況時，系統是否能夠正常運行）、可靠性測試等。
如果執行了所有的測試案例、測試程序或腳本，用戶驗收測試中發現的所有軟件問題都已解決，而且所有的軟件配置均已更新和審核，可以反映出軟件在用戶驗收測試中所發生的變化，用戶驗收測試就完成了。