軟件驗(yàn)收指南 

第1章驗(yàn)收準(zhǔn)備

充分的驗(yàn)收準(zhǔn)備為驗(yàn)收測試結(jié)果的準(zhǔn)確性提供了保證。開發(fā)商提交的驗(yàn)收文檔應(yīng)保證軟件開發(fā)涉及的所有過程已經(jīng)全部置于文檔控制之下，文檔應(yīng)包括軟件開發(fā)中使用的輔助設(shè)計(jì)軟件的工程文件，例如數(shù)據(jù)庫設(shè)計(jì)軟件PowerDesigner，流程設(shè)計(jì)軟件Rose等等。在驗(yàn)收準(zhǔn)備期間廣泛聽取最終用戶的使用意見，可以為有針對性的檢查軟件的缺陷提供幫助。驗(yàn)收準(zhǔn)備階段的工作包括收集開發(fā)商編制的源碼、文檔、安裝程序、控件等，還包括向最終用戶（甲方）項(xiàng)目組征集滿意度調(diào)查表；期間應(yīng)確定開發(fā)商和最終用戶的固定聯(lián)系方式。

1．1開發(fā)商資料收集

根據(jù)工程軟件項(xiàng)目的特點(diǎn)，在驗(yàn)收時(shí)應(yīng)向開發(fā)商收集以下文檔：

（1）可行性研究報(bào)告；

（2）項(xiàng)目立項(xiàng)報(bào)告；

（3）軟件需求規(guī)格說明書；

（4）項(xiàng)目實(shí)施計(jì)劃；

（5）數(shù)據(jù)庫設(shè)計(jì)說明書；

（6）軟件設(shè)計(jì)說明書。對一些規(guī)模較大或復(fù)雜性較高的項(xiàng)目，應(yīng)該把本文檔分成概要設(shè)計(jì)說明書與詳細(xì)設(shè)計(jì)說明書兩個(gè)文檔；

（7）軟件測試計(jì)劃說明書；

（8）軟件測試結(jié)果分析說明書；

（9）用戶手冊，包括使用手冊與管理員維護(hù)手冊；

(10)源程序清單；

(11)項(xiàng)目開發(fā)總結(jié)。

除上述文檔外，還應(yīng)單獨(dú)收集、保存各應(yīng)用軟件源程序代碼及開發(fā)商所用第三方資源信息。開發(fā)商所使用的第三方控件，除已經(jīng)得到審計(jì)署的許可之外，必須提供控件的源代碼，并擁有授權(quán)使用的證明或保證（由開發(fā)商提供無版權(quán)爭議承諾書）；對于原始程序代碼，要求能夠在本地不經(jīng)過任何特殊設(shè)置，即可編譯并正常運(yùn)行。源程序清單中列舉的項(xiàng)目應(yīng)該和源程序一一對應(yīng)。

1．2最終用戶資料收集

依據(jù)軟件開發(fā)需求說明書和概要設(shè)計(jì)說明書，編寫相關(guān)軟件的用戶滿意度調(diào)查表，該調(diào)查表應(yīng)該涵蓋軟件在需求說明書中列舉的所有模塊，包含軟件在不同操作系統(tǒng)下的運(yùn)行情況等。最終用戶或甲方項(xiàng)目組按照實(shí)際情況填寫該調(diào)查表。

第2章驗(yàn)收測試

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

工程軟件驗(yàn)收測試分為三部分：文檔代碼一致性審核、軟件配置審核和可執(zhí)行程序測試，其順序可分為：文檔審核、源代碼審核、配置腳本審核、測試程序、平臺(tái)API測試、集成測試、驗(yàn)收測試等。文檔代碼一致性審核、軟件配置審核是軟件部署和實(shí)施全面驗(yàn)收測試的基礎(chǔ)，由各應(yīng)用軟件驗(yàn)收責(zé)任人檢查它們的完整性；由于工程開發(fā)的各軟件運(yùn)行環(huán)境均基于審計(jì)管理系統(tǒng)、審計(jì)實(shí)施系統(tǒng)平臺(tái)，最終的集成測試、驗(yàn)收測試由計(jì)算機(jī)技術(shù)中心所有參與驗(yàn)收工作的人員一起完成。

2．1文檔審核

文檔審核的主要要求是確定軟件開發(fā)的所有過程都在提交文檔的控制下，對文檔的具體要求如下：

(1）文檔完備性：是否按照合同及其附件要求提交了全部文檔；

(2）內(nèi)容針對性：指文檔是否是甲方要求的文檔；文檔的內(nèi)容應(yīng)該按照功能模塊的重要性在論）上達(dá)到不同的詳細(xì)程度；

(3）內(nèi)容充分性：指該文檔全面、詳細(xì)的程度；

(4）文檔的價(jià)值：文檔應(yīng)該能夠反映軟件開發(fā)的整個(gè)過程，即需求中提到的功能在概要設(shè)計(jì)中體現(xiàn)，在詳細(xì)設(shè)計(jì)中實(shí)現(xiàn)，在測試計(jì)劃中檢驗(yàn)；

(5）圖表翔實(shí)性：是否包含了足夠的圖形和表格；

(6）符合甲方規(guī)范程度：是否很好地符合甲方要求的規(guī)范、標(biāo)準(zhǔn)；

(7）內(nèi)容一致性：是否存在前后矛盾；是否存在需求說明中提到的功能在概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)中沒有涉及的情況；

(8）文字明確性：不使用“可能”、“也許”、“待定”等語義含糊不清的語句；

(9）易讀性：能夠在一篇文檔中說明清楚的內(nèi)容，盡量不要拆分成若干文檔，不要循環(huán)引用，文檔目錄一目了然，結(jié)構(gòu)清晰。

2．2源代碼審核

源代碼審核的主要要求是確保開發(fā)商將全部源程序交付甲方，并確保交付的代碼沒有版權(quán)問題（由開發(fā)商提供無版權(quán)爭議承諾書）對源代碼審核的具體要求如下：

2．2．1版權(quán)明晰

（1）提交的代碼中注釋版權(quán)的地方均應(yīng)去掉版權(quán)聲明，或聲明版權(quán)為審計(jì)署所有。

（2）得到甲方允許，可以使用的控件，由開發(fā)商提供無版權(quán)爭議承諾書。使用其他的具有源代碼的控件，均需要當(dāng)作提交代碼的一部分，直接置于編譯環(huán)境的工程文件中，在編譯發(fā)布時(shí)無需額外設(shè)置。

2．2．2代碼完整

（1）開發(fā)商必須把所有實(shí)現(xiàn)用戶需求的代碼交付甲方。

（2）除非已經(jīng)得到甲方的允許，使用的控件也必須有源代碼，并得到授權(quán)使用證明；由開發(fā)商提供無版權(quán)爭議承諾書。

（3）包含開發(fā)工具的工程文件；要求能夠在甲方計(jì)算機(jī)中正常編譯、運(yùn)行；除非得到甲方允許，在甲方計(jì)算機(jī)中編譯的時(shí)候無需額外安裝開發(fā)工具的插件或控件。

2．2．3可讀性強(qiáng)

（1）注釋是軟件可讀性的具體體現(xiàn)。程序注釋量不少于程序編碼量的30%。程序注釋不能用抽象的語言（如“處理”、“循環(huán)”等），要精確表達(dá)出程序的處理說明。為避免每行程序都使用注釋，可以在一段程序的前面加一段注釋，有明確的處理邏輯。

（2）對于Java要求開發(fā)商能夠提供程序生成的JavaDoc。

2．3配置文件審核

對于B/S程序，部署維護(hù)是軟件生存周期中最長的一個(gè)過程，配置文件的審核顯得尤為重要。對配置文件的審核要求與源代碼的審核要求完全一致。

2．4測試用例編寫及測試程序、腳本審核

這個(gè)過程是在文檔審核和配置腳本審核后，為了檢驗(yàn)通過源代碼編譯后的程序是否滿足設(shè)計(jì)需求。檢驗(yàn)方式主要是API測試、集成測試、驗(yàn)收測試；這一階段應(yīng)該完成設(shè)計(jì)及其有關(guān)測試所包括的特性，還需要完成測試所需的測試用例和測試規(guī)程，并規(guī)定特性的通過準(zhǔn)則。

（1）測試用例說明：列出用于輸入的具體值以及預(yù)期的輸出結(jié)果，并規(guī)定在使用具體測試用例時(shí)，對測試規(guī)程的各種限制。要求將測試用例與測試設(shè)計(jì)分開，可以使它們用于多個(gè)設(shè)計(jì)并能在其它情形下重復(fù)使用。

（2）測試規(guī)程說明：規(guī)定對于運(yùn)行系統(tǒng)和執(zhí)行指定的測試用例來實(shí)現(xiàn)有關(guān)測試設(shè)計(jì)所要求的所有步驟。

測試方案

（1）針對性測試方案：從滿意度調(diào)查表中篩選出可能不符合需求設(shè)計(jì)的功能模塊，編寫針對具體模塊設(shè)計(jì)的測試方案。這種方案的實(shí)現(xiàn)耗時(shí)短，根據(jù)實(shí)際使用情況調(diào)查軟件的具體實(shí)現(xiàn)，適合在軟件得到較大面積試用后采取的驗(yàn)收測試。

（2）抽樣測試方案：在設(shè)計(jì)文檔中隨機(jī)選取，根據(jù)抽樣的樣本大小不同，最后得到的結(jié)論可能會(huì)出現(xiàn)差異。這種方案的實(shí)現(xiàn)耗時(shí)可長可短，適合軟件未得到大面積適用前驗(yàn)收時(shí)采用。

2．5平臺(tái)API測試

常見的白盒測試是單元測試。單元測試是測試中最小單位的測試。簡而言之，就是拿一個(gè)函數(shù)出來，加上驅(qū)動(dòng)模塊，讓它能夠運(yùn)行起來，然后設(shè)計(jì)一些用例測試其內(nèi)部的控制點(diǎn)（如：條件判斷點(diǎn)、循環(huán)點(diǎn)、選擇分支點(diǎn)等）。驅(qū)動(dòng)模塊是模擬調(diào)用被測函數(shù)的函數(shù)。

根據(jù)設(shè)計(jì)文檔選取關(guān)鍵函數(shù)和所有開放的API，設(shè)計(jì)測試用例。

2．6集成測試/壓力測試

常見的黑盒測試包括：集成測試，系統(tǒng)測試。集成測試是在單元測試的基礎(chǔ)上，將所有模塊按照設(shè)計(jì)要求（如根據(jù)結(jié)構(gòu)圖）組裝成為子系統(tǒng)或系統(tǒng)，進(jìn)行集成測試。實(shí)踐表明，一些模塊雖然能夠單獨(dú)地工作，但并不能保證連接起來也能正常的工作。程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實(shí)現(xiàn)。通過一個(gè)應(yīng)用系統(tǒng)的各個(gè)部件的聯(lián)合測試，以決定他們能否在一起共同工作，在協(xié)同工作時(shí)是否能夠達(dá)到功能要求。

對于B/S程序來說壓力測試主要是用戶數(shù)測試（需要使用專業(yè)測試軟件，如LoadRunner等），C/S程序主要是軟件承載數(shù)據(jù)量大小測試。

甲方需要根據(jù)操作手冊，將所有功能在發(fā)布后的軟件上設(shè)計(jì)并測試測試用例；能夠完整運(yùn)行需求列舉的所有功能即完成集成測試；壓力測試就是在高負(fù)載的情況下完整運(yùn)行所有功能。

2．7驗(yàn)收測試

目的是檢驗(yàn)待驗(yàn)收軟件集成在AO/OA平臺(tái)上是否對平臺(tái)和其它軟件保持良好的兼容性；這需要甲方所有人員將所測試軟件統(tǒng)一安裝到集成測試環(huán)境后一同實(shí)現(xiàn)。

2．8驗(yàn)收結(jié)論

驗(yàn)收結(jié)束時(shí)，根據(jù)以上文檔，填寫驗(yàn)收結(jié)論，對軟件的質(zhì)量做出評價(jià)。