軟體專案的使用者驗收測試(轉)
隨著當今技術和市場環境的變化,越來越多的企業選擇將軟體專案外包,同時也有更多成熟的大型軟體企業加入到軟體專案的承包隊伍中。外包的軟體專案越來越多,如何對這些外包的專案進行驗收測試日益成為企業的一個關鍵問題。
使用者驗收測試的總體思路
使用者驗收測試是軟體開發結束後,使用者對軟體產品投入實際應用以前進行的最後一次質量檢驗活動。它要回答開發的軟體產品是否符合預期的各項要求,以及使用者能否接受的問題。由於它不只是檢驗軟體某個方面的質量,而是要進行全面的質量檢驗,並且要決定軟體是否合格,因此驗收測試是一項嚴格的正式測試活動。需要根據事先制訂的計劃,進行軟體配置評審、功能測試、效能測試等多方面檢測。
使用者驗收測試可以分為兩個大的部分:軟體配置稽核和可執行程式測試,其大致順序可分為:文件稽核、原始碼稽核、配置指令碼稽核、測試程式或指令碼稽核、可執行程式測試。
要注意的是,在開發方將軟體提交使用者方進行驗收測試之前,必須保證開發方本身已經對軟體的各方面進行了足夠的正式測試(當然,這裡的“足夠”,本身是很難準確定量的)。
使用者在按照合同接收並清點開發方的提交物時(包括以前已經提交的),要檢視開發方提供的各種稽核報告和測試報告內容是否齊全,再加上平時對開發方工作情況的瞭解,基本可以初步判斷開發方是否已經進行了足夠的正式測試。
使用者驗收測試的每一個相對獨立的部分,都應該有目標(本步驟的目的)、啟動標準(著手本步驟必須滿足的條件)、活動(構成本步驟的具體活動)、完成標準(完成本步驟要滿足的條件)和度量(應該收集的產品與過程資料)。在實際驗收測試過程中,收集度量資料,不是一件容易的事情。
軟體配置稽核
對於一個外包的軟體專案而言,軟體承包方通常要提供如下相關的軟體配置內容:
● 可執行程式、源程式、配置指令碼、測試程式或指令碼。
● 主要的開發類文件:《需求分析說明書》、《概要設計說明書》、《詳細設計說明書》、《資料庫設計說明書》、《測試計劃》、《測試報告》、《程式維護手冊》、《程式設計師開發手冊》、《使用者操作手冊》、《專案總結報告》。
● 主要的管理類文件:《專案計劃書》、《質量控制計劃》、《配置管理計劃》、《使用者培訓計劃》、《質量總結報告》、《評審報告》、《會議記錄》、《開發進度月報》。
在開發類文件中,容易被忽視的文件有《程式維護手冊》和《程式設計師開發手冊》。
《程式維護手冊》的主要內容包括:系統說明(包括程式說明)、操作環境、維護過程、原始碼清單等,編寫目的是為將來的維護、修改和再次開發工作提供有用的技術資訊。
《程式設計師開發手冊》的主要內容包括:系統目標、開發環境使用說明、測試環境使用說明、編碼規範及相應的流程等,實際上就是程式設計師的培訓手冊。
不同大小的專案,都必須具備上述的文件內容,只是可以根據實際情況進行重新組織。
對上述的提交物,最好在合同中規定階段提交的時機,以免發生糾紛。
通常,正式的稽核過程分為5個步驟:計劃、預備會議(可選)、準備階段、稽核會議和問題追蹤。預備會議是對稽核內容進行介紹並討論。準備階段就是各責任人事先稽核並記錄發現的問題。稽核會議是最終確定工作產品中包含的錯誤和缺陷。
稽核要達到的基本目標是:根據共同制定的稽核表,儘可能地發現被稽核內容中存在的問題,並最終得到解決。在根據相應的稽核表進行文件稽核和原始碼稽核時,還要注意文件與原始碼的一致性。
在實際的驗收測試執行過程中,常常會發現文件稽核是最難的工作,一方面由於市場需求等方面的壓力使這項工作常常被弱化或推遲,造成持續時間變長,加大文件稽核的難度;另一方面,文件稽核中不易把握的地方非常多,每個專案都有一些特別的地方,而且也很難找到可用的參考資料。
可執行程式的測試
在文件稽核、原始碼稽核、配置指令碼稽核、測試程式或指令碼稽核都順利完成,就可以進行驗收測試的最後一個步驟——可執行程式的測試,它包括功能、效能等方面的測試,每種測試也都包括目標、啟動標準、活動、完成標準和度量等五部分。
要注意的是不能直接使用開發方提供的可執行程式用於測試,而要按照開發方提供的編譯步驟,從原始碼重新生成可執行程式。
在真正進行使用者驗收測試之前一般應該已經完成了以下工作(也可以根據實際情況有選擇地採用或增加):
● 軟體開發已經完成,並全部解決了已知的軟體缺陷。
● 驗收測試計劃已經過評審並批准,並且置於文件控制之下。
● 對軟體需求說明書的審查已經完成。
● 對概要設計、詳細設計的審查已經完成。
● 對所有關鍵模組的程式碼審查已經完成。
● 對單元、整合、系統測試計劃和報告的審查已經完成。
● 所有的測試指令碼已完成,並至少執行過一次,且透過評審。
● 使用配置管理工具且程式碼置於配置控制之下。
● 軟體問題處理流程已經就緒。
● 已經制定、評審並批准驗收測試完成標準。
具體的測試內容通常可以包括:安裝(升級)、啟動與關機、功能測試(正例、重要演算法、邊界、時序、反例、錯誤處理)、效能測試(正常的負載、容量變化)、壓力測試(臨界的負載、容量變化)、配置測試、平臺測試、安全性測試、恢復測試(在出現掉電、硬體故障或切換、網路故障等情況時,系統是否能夠正常執行)、可靠性測試等。
效能測試和壓力測試一般情況下是在一起進行,通常還需要輔助工具的支援。在進行效能測試和壓力測試時,測試範圍必須限定在那些使用頻度高的和時間要求苛刻的軟體功能子集中。由於開發方已經事先進行過效能測試和壓力測試,因此可以直接使用開發方的輔助工具。也可以透過購買或自己開發來獲得輔助工具。具體的測試方法可以參考相關的軟體工程書籍。
如果執行了所有的測試案例、測試程式或指令碼,使用者驗收測試中發現的所有軟體問題都已解決,而且所有的軟體配置均已更新和稽核,可以反映出軟體在使用者驗收測試中所發生的變化,使用者驗收測試就完成了。
[@more@]
使用者驗收測試的總體思路
使用者驗收測試是軟體開發結束後,使用者對軟體產品投入實際應用以前進行的最後一次質量檢驗活動。它要回答開發的軟體產品是否符合預期的各項要求,以及使用者能否接受的問題。由於它不只是檢驗軟體某個方面的質量,而是要進行全面的質量檢驗,並且要決定軟體是否合格,因此驗收測試是一項嚴格的正式測試活動。需要根據事先制訂的計劃,進行軟體配置評審、功能測試、效能測試等多方面檢測。
使用者驗收測試可以分為兩個大的部分:軟體配置稽核和可執行程式測試,其大致順序可分為:文件稽核、原始碼稽核、配置指令碼稽核、測試程式或指令碼稽核、可執行程式測試。
要注意的是,在開發方將軟體提交使用者方進行驗收測試之前,必須保證開發方本身已經對軟體的各方面進行了足夠的正式測試(當然,這裡的“足夠”,本身是很難準確定量的)。
使用者在按照合同接收並清點開發方的提交物時(包括以前已經提交的),要檢視開發方提供的各種稽核報告和測試報告內容是否齊全,再加上平時對開發方工作情況的瞭解,基本可以初步判斷開發方是否已經進行了足夠的正式測試。
使用者驗收測試的每一個相對獨立的部分,都應該有目標(本步驟的目的)、啟動標準(著手本步驟必須滿足的條件)、活動(構成本步驟的具體活動)、完成標準(完成本步驟要滿足的條件)和度量(應該收集的產品與過程資料)。在實際驗收測試過程中,收集度量資料,不是一件容易的事情。
軟體配置稽核
對於一個外包的軟體專案而言,軟體承包方通常要提供如下相關的軟體配置內容:
● 可執行程式、源程式、配置指令碼、測試程式或指令碼。
● 主要的開發類文件:《需求分析說明書》、《概要設計說明書》、《詳細設計說明書》、《資料庫設計說明書》、《測試計劃》、《測試報告》、《程式維護手冊》、《程式設計師開發手冊》、《使用者操作手冊》、《專案總結報告》。
● 主要的管理類文件:《專案計劃書》、《質量控制計劃》、《配置管理計劃》、《使用者培訓計劃》、《質量總結報告》、《評審報告》、《會議記錄》、《開發進度月報》。
在開發類文件中,容易被忽視的文件有《程式維護手冊》和《程式設計師開發手冊》。
《程式維護手冊》的主要內容包括:系統說明(包括程式說明)、操作環境、維護過程、原始碼清單等,編寫目的是為將來的維護、修改和再次開發工作提供有用的技術資訊。
《程式設計師開發手冊》的主要內容包括:系統目標、開發環境使用說明、測試環境使用說明、編碼規範及相應的流程等,實際上就是程式設計師的培訓手冊。
不同大小的專案,都必須具備上述的文件內容,只是可以根據實際情況進行重新組織。
對上述的提交物,最好在合同中規定階段提交的時機,以免發生糾紛。
通常,正式的稽核過程分為5個步驟:計劃、預備會議(可選)、準備階段、稽核會議和問題追蹤。預備會議是對稽核內容進行介紹並討論。準備階段就是各責任人事先稽核並記錄發現的問題。稽核會議是最終確定工作產品中包含的錯誤和缺陷。
稽核要達到的基本目標是:根據共同制定的稽核表,儘可能地發現被稽核內容中存在的問題,並最終得到解決。在根據相應的稽核表進行文件稽核和原始碼稽核時,還要注意文件與原始碼的一致性。
在實際的驗收測試執行過程中,常常會發現文件稽核是最難的工作,一方面由於市場需求等方面的壓力使這項工作常常被弱化或推遲,造成持續時間變長,加大文件稽核的難度;另一方面,文件稽核中不易把握的地方非常多,每個專案都有一些特別的地方,而且也很難找到可用的參考資料。
可執行程式的測試
在文件稽核、原始碼稽核、配置指令碼稽核、測試程式或指令碼稽核都順利完成,就可以進行驗收測試的最後一個步驟——可執行程式的測試,它包括功能、效能等方面的測試,每種測試也都包括目標、啟動標準、活動、完成標準和度量等五部分。
要注意的是不能直接使用開發方提供的可執行程式用於測試,而要按照開發方提供的編譯步驟,從原始碼重新生成可執行程式。
在真正進行使用者驗收測試之前一般應該已經完成了以下工作(也可以根據實際情況有選擇地採用或增加):
● 軟體開發已經完成,並全部解決了已知的軟體缺陷。
● 驗收測試計劃已經過評審並批准,並且置於文件控制之下。
● 對軟體需求說明書的審查已經完成。
● 對概要設計、詳細設計的審查已經完成。
● 對所有關鍵模組的程式碼審查已經完成。
● 對單元、整合、系統測試計劃和報告的審查已經完成。
● 所有的測試指令碼已完成,並至少執行過一次,且透過評審。
● 使用配置管理工具且程式碼置於配置控制之下。
● 軟體問題處理流程已經就緒。
● 已經制定、評審並批准驗收測試完成標準。
具體的測試內容通常可以包括:安裝(升級)、啟動與關機、功能測試(正例、重要演算法、邊界、時序、反例、錯誤處理)、效能測試(正常的負載、容量變化)、壓力測試(臨界的負載、容量變化)、配置測試、平臺測試、安全性測試、恢復測試(在出現掉電、硬體故障或切換、網路故障等情況時,系統是否能夠正常執行)、可靠性測試等。
效能測試和壓力測試一般情況下是在一起進行,通常還需要輔助工具的支援。在進行效能測試和壓力測試時,測試範圍必須限定在那些使用頻度高的和時間要求苛刻的軟體功能子集中。由於開發方已經事先進行過效能測試和壓力測試,因此可以直接使用開發方的輔助工具。也可以透過購買或自己開發來獲得輔助工具。具體的測試方法可以參考相關的軟體工程書籍。
如果執行了所有的測試案例、測試程式或指令碼,使用者驗收測試中發現的所有軟體問題都已解決,而且所有的軟體配置均已更新和稽核,可以反映出軟體在使用者驗收測試中所發生的變化,使用者驗收測試就完成了。
[@more@]
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7839396/viewspace-953322/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 軟體測試外包專案經驗分享:歷經7個月的OA系統專案驗收測試情況
- 軟體產品驗收測試流程有哪些?如何獲取軟體驗收測試報告測試報告
- 軟體驗收測試 第三方軟體測試 軟體功能測試 軟體資訊保安測試
- 軟體專案驗收測試範圍和流程,這些你都知道嗎?
- 軟體驗收測試包括哪些內容和流程?專業的軟體測評中心推薦
- 軟體測試---單元、整合、系統、驗收測試
- 軟體驗收測試和系統測試的區別點
- 軟體驗收測試 常見測試報告的型別測試報告型別
- 軟體驗收測試是什麼?第三方軟體驗收測試有什麼意義?
- 軟體驗收測試之α測試和β測試,如何選擇權威的軟體檢測機構
- 軟體驗收測試和系統測試有什麼聯絡和區別?專業軟體測試公司安利
- 軟體驗收測試有哪些測試方法?北京權威軟體測試機構安利
- 專業軟體測評中心分享:科技成果驗收測試報告的作用測試報告
- 軟體功能測試包含了哪些測試專案?功能測試報告收費標準測試報告
- 軟體系統測試和驗收測試有什麼聯絡與區別?專業軟體測試方案推薦
- 軟體驗收測試之α測試和β測試分別是什麼?
- 軟體驗收測試該怎麼進行?驗收測試報告需要多少費用?測試報告
- 軟體測評中心▏軟體驗收正式測試和非正式測試優缺點有哪些?
- 業主方資訊化專案驗收測試要求
- 科技專案進行驗收測試有什麼注意事項?驗收測試報告費用標準測試報告
- 軟體驗收測試有什麼注意事項?出具權威測試報告的軟體檢測機構安利測試報告
- 軟體驗收測試的測試過程和內容有哪些?權威的軟體檢測機構哪家比較好?
- 軟體測試團隊對產品驗收的三步驟
- 軟體安全測試有哪些測試手段?軟體測試報告收費貴嗎?測試報告
- 軟體測試實戰專案,問題答疑
- 實驗三——軟體測試
- 實驗三:軟體測試
- 實驗3:軟體測試
- 實驗三 軟體測試
- 實驗3——軟體測試
- 實驗三-軟體測試
- 軟體確認測試、系統測試和驗收測試有什麼區別和關係?
- 軟體測試人員如何去分析及提高使用者體驗?
- 軟體壓力測試有哪些測試流程?軟體測試報告收費情況測試報告
- 軟體測試實驗三單元測試
- 軟體測試實驗二 | 白盒測試
- 資訊化專案驗收確認測試的內容和流程有哪些?
- 軟體測試專案該如何規避風險?
- 軟體測試之Web測試知識分享,權威的軟體測評機構如何收費?Web