隨著當今技術和市場環(huán)境的變化，越來越多的企業(yè)選擇將軟件項目外包，同時也有更多成熟的大型軟件企業(yè)加入到軟件項目的承包隊伍中。外包的軟件項目越來越多，如何對這些外包的項目進行驗收測試日益成為企業(yè)的一個關鍵問題。

用戶驗收測試的總體思路

用戶驗收測試是軟件開發(fā)結(jié)束后，用戶對軟件產(chǎn)品投入實際應用以前進行的最后一次質(zhì)量檢驗活動。它要回答開發(fā)的軟件產(chǎn)品是否符合預期的各項要求，以及用戶能否接受的問題。由于它不只是檢驗軟件某個方面的質(zhì)量，而是要進行全面的質(zhì)量檢驗，并且要決定軟件是否合格，因此驗收測試是一項嚴格的正式測試活動。需要根據(jù)事先制訂的計劃，進行軟件配置評審、功能測試、性能測試等多方面檢測。

用戶驗收測試可以分為兩個大的部分：軟件配置審核和可執(zhí)行程序測試，其大致順序可分為：文檔審核、源代碼審核、配置腳本審核、測試程序或腳本審核、可執(zhí)行程序測試。

要注意的是，在開發(fā)方將軟件提交用戶方進行驗收測試之前，必須保證開發(fā)方本身已經(jīng)對軟件的各方面進行了足夠的正式測試（當然，這里的“足夠”，本身是很難準確定量的）。

用戶在按照合同接收并清點開發(fā)方的提交物時（包括以前已經(jīng)提交的），要查看開發(fā)方提供的各種審核報告和測試報告內(nèi)容是否齊全，再加上平時對開發(fā)方工作情況的了解，基本可以初步判斷開發(fā)方是否已經(jīng)進行了足夠的正式測試。

用戶驗收測試的每一個相對獨立的部分，都應該有目標（本步驟的目的）、啟動標準（著手本步驟必須滿足的條件）、活動（構(gòu)成本步驟的具體活動）、完成標準（完成本步驟要滿足的條件）和度量（應該收集的產(chǎn)品與過程數(shù)據(jù)）。在實際驗收測試過程中，收集度量數(shù)據(jù)，不是一件容易的事情。

軟件配置審核

對于一個外包的軟件項目而言，軟件承包方通常要提供如下相關的軟件配置內(nèi)容：

● 可執(zhí)行程序、源程序、配置腳本、測試程序或腳本。

● 主要的開發(fā)類文檔：《需求分析說明書》、《概要設計說明書》、《詳細設計說明書》、《數(shù)據(jù)庫設計說明書》、《測試計劃》、《測試報告》、《程序維護手冊》、《程序員開發(fā)手冊》、《用戶操作手冊》、《項目總結(jié)報告》。

● 主要的管理類文檔：《項目計劃書》、《質(zhì)量控制計劃》、《配置管理計劃》、《用戶培訓計劃》、《質(zhì)量總結(jié)報告》、《評審報告》、《會議記錄》、《開發(fā)進度月報》。

在開發(fā)類文檔中，容易被忽視的文檔有《程序維護手冊》和《程序員開發(fā)手冊》。

《程序維護手冊》的主要內(nèi)容包括：系統(tǒng)說明（包括程序說明）、操作環(huán)境、維護過程、源代碼清單等，編寫目的是為將來的維護、修改和再次開發(fā)工作提供有用的技術信息。

《程序員開發(fā)手冊》的主要內(nèi)容包括：系統(tǒng)目標、開發(fā)環(huán)境使用說明、測試環(huán)境使用說明、編碼規(guī)范及相應的流程等，實際上就是程序員的培訓手冊。

不同大小的項目，都必須具備上述的文檔內(nèi)容，只是可以根據(jù)實際情況進行重新組織。

對上述的提交物，最好在合同中規(guī)定階段提交的時機，以免發(fā)生糾紛。

通常，正式的審核過程分為5個步驟：計劃、預備會議（可選）、準備階段、審核會議和問題追蹤。預備會議是對審核內(nèi)容進行介紹并討論。準備階段就是各責任人事先審核并記錄發(fā)現(xiàn)的問題。審核會議是最終確定工作產(chǎn)品中包含的錯誤和缺陷。

審核要達到的基本目標是：根據(jù)共同制定的審核表，盡可能地發(fā)現(xiàn)被審核內(nèi)容中存在的問題，并最終得到解決。在根據(jù)相應的審核表進行文檔審核和源代碼審核時，還要注意文檔與源代碼的一致性。

在實際的驗收測試執(zhí)行過程中，常常會發(fā)現(xiàn)文檔審核是最難的工作，一方面由于市場需求等方面的壓力使這項工作常常被弱化或推遲，造成持續(xù)時間變長，加大文檔審核的難度；另一方面，文檔審核中不易把握的地方非常多，每個項目都有一些特別的地方，而且也很難找到可用的參考資料。

可執(zhí)行程序的測試

在文檔審核、源代碼審核、配置腳本審核、測試程序或腳本審核都順利完成，就可以進行驗收測試的最后一個步驟——可執(zhí)行程序的測試，它包括功能、性能等方面的測試，每種測試也都包括目標、啟動標準、活動、完成標準和度量等五部分。

要注意的是不能直接使用開發(fā)方提供的可執(zhí)行程序用于測試，而要按照開發(fā)方提供的編譯步驟，從源代碼重新生成可執(zhí)行程序。

在真正進行用戶驗收測試之前一般應該已經(jīng)完成了以下工作（也可以根據(jù)實際情況有選擇地采用或增加）：

● 軟件開發(fā)已經(jīng)完成，并全部解決了已知的軟件缺陷。

● 驗收測試計劃已經(jīng)過評審并批準，并且置于文檔控制之下。

● 對軟件需求說明書的審查已經(jīng)完成。

● 對概要設計、詳細設計的審查已經(jīng)完成。

● 對所有關鍵模塊的代碼審查已經(jīng)完成。

● 對單元、集成、系統(tǒng)測試計劃和報告的審查已經(jīng)完成。

● 所有的測試腳本已完成，并至少執(zhí)行過一次，且通過評審。

● 使用配置管理工具且代碼置于配置控制之下。

● 軟件問題處理流程已經(jīng)就緒。

● 已經(jīng)制定、評審并批準驗收測試完成標準。

具體的測試內(nèi)容通?？梢园ǎ喊惭b（升級）、啟動與關機、功能測試（正例、重要算法、邊界、時序、反例、錯誤處理）、性能測試（正常的負載、容量變化）、壓力測試（臨界的負載、容量變化）、配置測試、平臺測試、安全性測試、恢復測試（在出現(xiàn)掉電、硬件故障或切換、網(wǎng)絡故障等情況時，系統(tǒng)是否能夠正常運行）、可靠性測試等。

性能測試和壓力測試一般情況下是在一起進行，通常還需要輔助工具的支持。在進行性能測試和壓力測試時，測試范圍必須限定在那些使用頻度高的和時間要求苛刻的軟件功能子集中。由于開發(fā)方已經(jīng)事先進行過性能測試和壓力測試，因此可以直接使用開發(fā)方的輔助工具。也可以通過購買或自己開發(fā)來獲得輔助工具。具體的測試方法可以參考相關的軟件工程書籍。

如果執(zhí)行了所有的測試案例、測試程序或腳本，用戶驗收測試中發(fā)現(xiàn)的所有軟件問題都已解決，而且所有的軟件配置均已更新和審核，可以反映出軟件在用戶驗收測試中所發(fā)生的變化，用戶驗收測試就完成了。

【?發(fā)表評論?0條?】