2024年軟件項(xiàng)目驗(yàn)收流程及方案篇

2024年軟件項(xiàng)目驗(yàn)收流程及方案篇

篇一：軟件項(xiàng)目驗(yàn)收流程及方案

項(xiàng)目驗(yàn)收過程

驗(yàn)收作為項(xiàng)目執(zhí)行過程中的一個(gè)重要的里程碑，對公司和客戶具有重要的意義。

一、驗(yàn)收申請

二、驗(yàn)收準(zhǔn)備

2.1開發(fā)商資料收集

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

編號

123456789101112131415161718192024

名稱

形式介質(zhì)

項(xiàng)目開發(fā)計(jì)劃

文檔電子、紙質(zhì)

軟件需求說明書

文檔電子、紙質(zhì)

系統(tǒng)概要設(shè)計(jì)說明書

文檔電子、紙質(zhì)

總體設(shè)計(jì)說明書

文檔電子、紙質(zhì)

數(shù)據(jù)庫設(shè)計(jì)說明書

文檔電子、紙質(zhì)

詳細(xì)設(shè)計(jì)文檔

文檔電子、紙質(zhì)

為本項(xiàng)目開發(fā)的軟件源代碼

文檔電子、紙質(zhì)

FATSAT報(bào)告

文檔電子、紙質(zhì)

試運(yùn)行報(bào)告

文檔電子、紙質(zhì)

性能測試報(bào)告、功能測試報(bào)告

文檔電子、紙質(zhì)

項(xiàng)目實(shí)施報(bào)告

文檔電子、紙質(zhì)

培訓(xùn)計(jì)劃

文檔電子、紙質(zhì)

服務(wù)計(jì)劃

文檔電子、紙質(zhì)

維護(hù)手冊

文檔電子、紙質(zhì)

用戶手冊

文檔電子、紙質(zhì)

應(yīng)用軟件清單

文檔電子、紙質(zhì)

系統(tǒng)參數(shù)配置說明

文檔電子、紙質(zhì)

所提供的第三方產(chǎn)品的技術(shù)說明和操作、維護(hù)資料文檔電子、紙質(zhì)

系統(tǒng)崩潰與恢復(fù)步驟文檔

文檔電子、紙質(zhì)

技術(shù)服務(wù)和技術(shù)培訓(xùn)等相關(guān)資料

文檔電子、紙質(zhì)

項(xiàng)目總結(jié)報(bào)告

文檔電子、紙質(zhì)

除上述文檔外，還應(yīng)單獨(dú)收集、保存各應(yīng)用軟件源程序代碼與開發(fā)商所用第三方資源信息。

開發(fā)商所使用的第三方控件，除已經(jīng)得到審計(jì)署的許可之外，必次提供控件的源代碼，并擁有授

權(quán)使用的證明或保證〔由開發(fā)商提供無爭議承諾書）；對于原始程序代碼，要求能夠在本地不經(jīng)

過任何特殊設(shè)置，即可編譯并正常運(yùn)行。源程序清單中列舉的項(xiàng)目應(yīng)該和源程序一對應(yīng)。

2.2最終用戶資料收集

依據(jù)軟件開發(fā)需求說明書和概要設(shè)計(jì)說明書，編寫相關(guān)軟件的用戶滿意度調(diào)有表，該調(diào)查表

應(yīng)該涵蓋軟件在需求說明書中列舉的所有模塊，包含軟件在不同操作系統(tǒng)下的運(yùn)行情況等。最終

用戶或甲方項(xiàng)目組按照實(shí)際情況填寫該調(diào)查表。

三、驗(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í)行程序測試，其JII酹

可分為：文檔審核、源代碼審核、配置腳本審核、測試程序、平臺API測試、集成測試、驗(yàn)收

測試等。文檔代碼一致性審核、軟件配置審核是軟件部署和實(shí)施全面驗(yàn)收測試的基礎(chǔ)，由各應(yīng)用

軟件驗(yàn)收責(zé)任人檢查它們的完整性；由于工程開發(fā)的各軟件運(yùn)行環(huán)境均基于審計(jì)管理系統(tǒng)、審計(jì)

實(shí)施系統(tǒng)平臺，最終的集成測試、驗(yàn)收測試由德華工貿(mào)員工、驗(yàn)收專家所有參與驗(yàn)收工作的人員

一起完成。

3.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ī)X程度：是否很好地符合甲方要求的規(guī)X、標(biāo)準(zhǔn)；

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

計(jì)中沒有涉與的情況；

(8)文字明確性：不使用"可能.、"也許/、"待定〃等語義含糊不清的語句；

(9〕易讀性：能夠在一篇文檔中說明清楚的內(nèi)容，盡量不要拆分成若干文檔，不要循環(huán)引用，

文檔目錄一目了然，結(jié)構(gòu)清晰。

3.2源代碼審核

源代碼審核的主要要求是確保開發(fā)商將全部源程序交付甲方，并確保交付的代碼沒有問題

〔由開發(fā)商提供無爭議承諾書〕對源代碼審核的具體要求如下：

3.2.1明晰

(1)提交的代碼中注釋的地方均應(yīng)去掉聲明，或聲明為審計(jì)署所有.

(2)得到甲方允許，可以使用的控件，由開發(fā)商提供無爭議承諾書。使用其他的具有源代

碼的控件，均需要當(dāng)作提交代碼的一部分，直接置于編譯環(huán)境的工程文件中，在編譯發(fā)布時(shí)無需

額外設(shè)置。

3.2.2代碼完整

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

(2)除非已經(jīng)得到甲方的允許，使用的控件也必須有源代碼，并得到授權(quán)使用證明；由開

發(fā)商提供無爭議承諾書。

〔3〕包含開發(fā)工具的程序文件；要求能夠在甲方計(jì)算機(jī)中正常編譯、運(yùn)行；除非得到甲方

允許，在甲方計(jì)算機(jī)中編譯的時(shí)候無需額外安裝開發(fā)工具的插件或控件。

3.2.3可讀性強(qiáng)

注釋是軟件可讀性的具體體現(xiàn)。程序注釋量不少于程序編碼量的30%。程序注釋不能用抽

象的語言〔如"處理"、"循環(huán).等)，要精確表達(dá)出程序的處理說B月。為避免每行程序都使用

注釋，可以在一段程序的前面加一段注釋，有明確的處理邏輯。

3.3配置文件審核

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

要。對配置文件的審核要求與源代碼的審核要求完全一致。

3.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ù)使用。

⑵測試規(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)收測試。

篇二：軟件項(xiàng)目驗(yàn)收流程及方案

軟件項(xiàng)目驗(yàn)收方案

驗(yàn)收：按照一定標(biāo)準(zhǔn)進(jìn)行檢驗(yàn)而后收下或認(rèn)可逐項(xiàng)驗(yàn)收軟件項(xiàng)目驗(yàn)收方案

良好的軟件測試方法可以確保軟件項(xiàng)目正確運(yùn)作，然而，除了軟件之外，還有一個(gè)重要的卻

往往被忽視的角色客戶。在軟件項(xiàng)目開發(fā)的每個(gè)階段考慮客戶需求是系統(tǒng)獲得成功非常重要的一

點(diǎn)。

L軟件項(xiàng)目驗(yàn)收測試概梯收測試一直以來被用于不同的技術(shù)和方法中,有期旨的是同一

個(gè)概念，有時(shí)也可能指不同的測試形式。所以必須給本文探討的驗(yàn)收測試相關(guān)概念一個(gè)明確的定

義：①驗(yàn)收測試：包括客戶驗(yàn)收測試、用戶驗(yàn)收測試和功能測試;②可執(zhí)行規(guī)范：即驗(yàn)收測試規(guī)

范，可運(yùn)行測試來驗(yàn)證項(xiàng)目實(shí)現(xiàn)是否與所定義的規(guī)范相匹配;③客戶：系統(tǒng)的最終用戶;④系統(tǒng)：

所開發(fā)的軟件項(xiàng)目;⑤驗(yàn)收滿足功能和非功能需求;⑥功能需求該系統(tǒng)必須執(zhí)行的功能和動(dòng)作，

如顯示條目、用戶身份驗(yàn)證等;⑦非功能需求：系統(tǒng)的相關(guān)因素，如性能、可擴(kuò)展性和安全性;⑧

黑盒：不依賴于系統(tǒng)內(nèi)部細(xì)節(jié)的測試過程，如輸入數(shù)據(jù)、檢測

輸出結(jié)果。這些術(shù)語并不足以對如何將驗(yàn)收測試應(yīng)用于軟件項(xiàng)目開發(fā)生命

周期進(jìn)行一個(gè)準(zhǔn)確的描述。驗(yàn)收測試并不是新概念，但它像測試驅(qū)動(dòng)開發(fā)TDD一樣，近幾

年來才得到關(guān)注和廣泛使用，并出現(xiàn)了一些相關(guān)的測試工具和架構(gòu)。接下來看一下驗(yàn)收測試是如

何應(yīng)用于軟件開發(fā)生命周期的。

驗(yàn)收測試往往被用于由極限編程、敏捷原則和Scrum迭代模型指導(dǎo)開發(fā)的軟件項(xiàng)目中。出

現(xiàn)這樣的情況主要有兩個(gè)原因。一是驗(yàn)收測試側(cè)重于客戶和軟件所實(shí)現(xiàn)的功能向客戶提供的價(jià)值，

這與敏捷開發(fā)原則相一致，后者也是側(cè)重于交付實(shí)際滿足客戶需求的軟件。二是通過一套自動(dòng)化

驗(yàn)收測試就可以確保該軟件能夠滿足客戶需求、確保在實(shí)現(xiàn)新功能的時(shí)候沒有破壞任何舊功能。

這意味著，可以將重點(diǎn)放在確保正在開發(fā)的功能是否與期望的相一致上面。

2、軟件項(xiàng)目驗(yàn)收測試方法驗(yàn)收測試的編寫和實(shí)現(xiàn)應(yīng)該貫穿在軟件項(xiàng)目開發(fā)的每個(gè)迭代過程

中在一個(gè)標(biāo)準(zhǔn)的Scrum迭ft過程開始的時(shí)候，開發(fā)團(tuán)隊(duì)接受了具有最高優(yōu)先級的待完成的產(chǎn)品

需求列表，該產(chǎn)品需求應(yīng)當(dāng)分解為多個(gè)用戶使用情景，每個(gè)用戶使用情景定義一個(gè)系統(tǒng)需求。一

個(gè)用戶使用情景通常由兩部分組成，用來描述用戶需要的系統(tǒng)部分。如一個(gè)典型的用戶使用情景

可以被描述為作為一名銷售管理員，我想要能夠查看信用卡信息，從而能夠在本地處理付款。這

個(gè)用戶使用情景描述了操作

和與操作相關(guān)的用戶，對要求實(shí)現(xiàn)的內(nèi)容給出清晰的說明。一旦選定一個(gè)用戶使用情景后，

開發(fā)團(tuán)隊(duì)就應(yīng)當(dāng)對他們要實(shí)現(xiàn)的

內(nèi)容有一個(gè)很好的認(rèn)識，這一階段應(yīng)該與客戶和產(chǎn)品所有者進(jìn)行交談，確定實(shí)際需要什么并

擴(kuò)展初始用戶使用情景，并基于這一信息和團(tuán)隊(duì)內(nèi)部的其他技術(shù)人員討論來創(chuàng)建任務(wù)，在這一階

段，就應(yīng)當(dāng)編寫驗(yàn)收測試了。了解試圖實(shí)現(xiàn)的用戶使用情景，就可以清楚地認(rèn)識到完成這些實(shí)現(xiàn)

所需的任務(wù)，也能夠知道如何驗(yàn)證這一應(yīng)用程序是否滿足客戶需求。驗(yàn)收測試并不是f氐層次的單

元測試，而是側(cè)重于驗(yàn)證基于用戶使用情景的客戶需求是否正確實(shí)現(xiàn)的高層次測試。確定了用戶

使用情景后，在將其分解為任務(wù)之前，定義驗(yàn)收測試是非常必要的。當(dāng)所有的驗(yàn)收測試都通過的

時(shí)候，就完成了系統(tǒng)。這使得任務(wù)分解更加側(cè)重于需要完成的事。在這一階段，客戶和產(chǎn)品所有

者應(yīng)當(dāng)協(xié)助開發(fā)團(tuán)隊(duì)定義驗(yàn)收測試，確保軟件需求滿足客戶的期望。

良好驗(yàn)收測試可以讓客戶在開始編碼之前清楚地知道當(dāng)前階段軟件項(xiàng)目將實(shí)現(xiàn)的功能?？蛻?/p>

清楚地定義了需求開發(fā)團(tuán)隊(duì)可以在實(shí)際編碼前提出任何與需求相關(guān)的問題并與客戶敲定細(xì)節(jié)。

使用驗(yàn)收測試指導(dǎo)和驗(yàn)證，可以使客戶清楚地知道他們想要什么，也可以使軟件項(xiàng)目開發(fā)團(tuán)隊(duì)清

楚地知道他們計(jì)劃交付什么。

軟件項(xiàng)目驗(yàn)收方案一、驗(yàn)收目的為使信息化項(xiàng)目建設(shè)按照標(biāo)準(zhǔn)要求進(jìn)行，確保項(xiàng)目唆工后達(dá)

到有關(guān)要求和標(biāo)準(zhǔn)，并能正常投入運(yùn)行，必須進(jìn)行項(xiàng)目驗(yàn)收。二、驗(yàn)收對象

參與項(xiàng)目建設(shè)的施工單位。三、項(xiàng)目驗(yàn)收的前提條件所有建設(shè)項(xiàng)目按照合同要求全部建成,

并滿足使用要求；各個(gè)分項(xiàng)工程全部驗(yàn)收合格；已通過軟件確認(rèn)測試評審；已通過軟件系統(tǒng)測試

評審；軟件已置于配置管理之下；各種技術(shù)文檔和驗(yàn)收資料完備，符合合同的內(nèi)容；系統(tǒng)建設(shè)和

數(shù)據(jù)處理符合信息安全的要求，涉密信息系統(tǒng)需提供主管部門驗(yàn)收的合格*書；外購的*作系統(tǒng)、

數(shù)據(jù)庫、中間件、應(yīng)用軟件和開發(fā)工具符合知識產(chǎn)權(quán)相關(guān)政策法規(guī)的要求；各種設(shè)備經(jīng)加電試運(yùn)

行，狀態(tài)正常;經(jīng)過監(jiān)理方同意;經(jīng)過相關(guān)主管部門和項(xiàng)目業(yè)主同意;合同或合同附件規(guī)定的其

他驗(yàn)收條件；四、驗(yàn)收方法項(xiàng)目驗(yàn)收是項(xiàng)目開發(fā)建設(shè)中有組織的主動(dòng)性行為，它是對項(xiàng)目建設(shè)高

度負(fù)責(zé)的體現(xiàn)，也是項(xiàng)目建設(shè)成功的重要保，切實(shí)做好項(xiàng)目建設(shè)中的驗(yàn)收工作至關(guān)重要，應(yīng)當(dāng)

采取有效措施，實(shí)實(shí)在在做好。為保

*項(xiàng)目驗(yàn)收質(zhì)量，針對不同的驗(yàn)收內(nèi)容，在實(shí)施驗(yàn)收*作中，可以采取以下不同的方法：

登記法對項(xiàng)目中所設(shè)計(jì)的所有硬件、軟件和應(yīng)用程序——登記，特別是硬件使用手冊、軟件

使用手冊、應(yīng)用程序各種技術(shù)文檔等一定要登記造冊，不可遺漏，并妥善保管。對項(xiàng)目建設(shè)中根

據(jù)實(shí)際進(jìn)展情況雙方同意后修訂的合同條款、協(xié)調(diào)發(fā)展建設(shè)中的問題進(jìn)行登記。對照法對照檢查

項(xiàng)目各項(xiàng)建設(shè)內(nèi)容的結(jié)果是否與合同條款及工程施工方案一致?！弊鞣ㄟ@是項(xiàng)目建設(shè)最主要的驗(yàn)

收方法。首先，最項(xiàng)目系統(tǒng)硬件——實(shí)際加電*作，驗(yàn)*是否與硬件提供的技術(shù)性能相一致;其次,

運(yùn)行項(xiàng)目軟件系統(tǒng)，檢瞼其管理硬件及應(yīng)用軟件的實(shí)際能力是否與合同規(guī)定的一致；第三，運(yùn)行

應(yīng)用軟件，實(shí)際*作，處理業(yè)務(wù)，檢查是否與合同規(guī)定的一致，達(dá)到了預(yù)期的目的。測試法對能

使用檢測儀器進(jìn)行檢測的設(shè)備，實(shí)施應(yīng)當(dāng)一進(jìn)行實(shí)際測試，檢查是否和設(shè)備、實(shí)施的規(guī)格、性

能要求相一致。五、驗(yàn)收步驟需求分析項(xiàng)目監(jiān)理單位組織人員對項(xiàng)目進(jìn)行驗(yàn)收需求分析，針對項(xiàng)

目驗(yàn)

收，監(jiān)理單位需配備2名有經(jīng)驗(yàn)的工程帥和一名行業(yè)專家來組成項(xiàng)目團(tuán)隊(duì)，負(fù)責(zé)具體工作。

編寫驗(yàn)收方案項(xiàng)目監(jiān)理單位在對項(xiàng)目進(jìn)行深入的需求分析的基礎(chǔ)上編寫驗(yàn)收方案提交業(yè)主

單位審定。成立項(xiàng)目險(xiǎn)收小組實(shí)施測試驗(yàn)收工作時(shí)應(yīng)當(dāng)成立項(xiàng)目驗(yàn)收小組具體負(fù)責(zé)驗(yàn)收事宜。

項(xiàng)目驗(yàn)收的實(shí)施嚴(yán)格按照驗(yàn)收方案對項(xiàng)目應(yīng)用軟件、網(wǎng)絡(luò)集成效果、系統(tǒng)文檔資料等進(jìn)行全面的

測試和驗(yàn)收。提交驗(yàn)收報(bào)告項(xiàng)目驗(yàn)收完畢，對項(xiàng)目系統(tǒng)設(shè)計(jì)、建設(shè)質(zhì)量、設(shè)備治療、軟件運(yùn)行情

況等做出全面的評價(jià)，得出結(jié)論性意見，對不合格的項(xiàng)目不予驗(yàn)收，對一流問題提出具體的解決

意見。召開項(xiàng)目驗(yàn)收評審會(huì)召開由驗(yàn)收委員會(huì)全體成員參加的項(xiàng)目驗(yàn)收評審會(huì)，全面細(xì)致的審核

項(xiàng)目銷售小組所提交的驗(yàn)收報(bào)告，給出最終的驗(yàn)收意見，形成驗(yàn)收評審報(bào)告提交項(xiàng)目業(yè)主存檔。

六、驗(yàn)收程序初驗(yàn)1、申請：項(xiàng)目竣工后經(jīng)測試和試運(yùn)行合格，施工單位根據(jù)合同、

篇三：軟件項(xiàng)目驗(yàn)收流程及方案

軟件項(xiàng)目驗(yàn)收流程各步驟內(nèi)容

集團(tuán)標(biāo)準(zhǔn)化工作小組#Q8QGGQT-GX8G08Q8-GNQGJ8-MHHGN#

項(xiàng)目驗(yàn)收過程

驗(yàn)收作為項(xiàng)目執(zhí)行過程中的一個(gè)重要的里程碑，對公司和客戶具有重要的意義。

一、驗(yàn)收申請

二、驗(yàn)收準(zhǔn)備

2.1開發(fā)商資料收集

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

編號1234567891011121314151617

名稱項(xiàng)目開發(fā)計(jì)劃軟件需求說明書系統(tǒng)概要設(shè)計(jì)說明書總體設(shè)計(jì)說明書數(shù)據(jù)庫設(shè)計(jì)說明書

詳細(xì)設(shè)計(jì)文檔為本項(xiàng)目開發(fā)的軟件源代碼FATSAT報(bào)告試運(yùn)行報(bào)告性能測試報(bào)告、功能測試報(bào)

告項(xiàng)目實(shí)施報(bào)告培訓(xùn)計(jì)劃服務(wù)計(jì)劃維護(hù)手冊用戶手冊應(yīng)用軟件清單系統(tǒng)參數(shù)配置說明

形式介質(zhì)文檔電子、紙質(zhì)文檔電子、紙質(zhì)文檔電子、紙質(zhì)文欄電子、紙質(zhì)文檔電子、紙質(zhì)文

檔電子、紙質(zhì)文檔電子、紙質(zhì)文檔電子、紙質(zhì)文檔電子、紙質(zhì)文檔電子、紙質(zhì)文檔電子、名田貢文

檔電子、紙質(zhì)文檔電子、名噴文檔電子、紙質(zhì)文檔電子、紙質(zhì)文檔電子、紙質(zhì)文檔電子、名賑

18

所提供的第三方產(chǎn)品的技術(shù)說明和操作、維護(hù)資料

文檔電子、紙質(zhì)

19系統(tǒng)崩潰及恢復(fù)步驟文檔

文檔電子、紙質(zhì)

20技術(shù)服務(wù)和技術(shù)培訓(xùn)等相關(guān)資料

文檔電子、紙質(zhì)

21項(xiàng)目總結(jié)報(bào)告

文檔電子、紙質(zhì)

除上述文檔外，還應(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)。

2.2最終用戶資料收集

依據(jù)軟件開發(fā)需求說明書和概要設(shè)計(jì)說明書，編寫相關(guān)軟件的用戶滿意度調(diào)查表，該調(diào)查表

應(yīng)該涵蓋軟件在需求說明書中列舉的所有模塊，包含軟件在不同操作系統(tǒng)下的運(yùn)行情況等。最終

用戶或甲方項(xiàng)目組按照實(shí)際情況填寫該調(diào)查表。

三、驗(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í)行程序測試，其JII賠

可分為：文檔審核、源代碼審核、配置腳本審核、測試程序、平臺API測試、集成測試、驗(yàn)收

測試等。文檔代碼一致性審核、軟件配置審核是軟件部署和實(shí)施全面驗(yàn)收測試的基礎(chǔ)，由各應(yīng)用

軟件驗(yàn)收責(zé)任人檢查它們的完整性；由于工程開發(fā)的各軟件運(yùn)行環(huán)境均基于審計(jì)管理系統(tǒng)、審計(jì)

實(shí)施系統(tǒng)平臺，最終的集成測試、驗(yàn)收測試由德華工貿(mào)員工、驗(yàn)收專家所有參與驗(yàn)收工作的人員

一起完成。

3.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)清晰。3.2源代碼審核源代碼審核的主要要求是確保開發(fā)商將全部源程序交付甲

方，并確保交付的代碼沒有版權(quán)問題（由開發(fā)商提供無版權(quán)爭議承諾書）對源代碼審核的具體要

求如下：3.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è)置.3.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ā)工具的插件或控件。

3.2.3可讀性強(qiáng)

注釋是軟件可讀性的具體體現(xiàn)。程序注釋量不少于程序編碼量的30%,程序注釋不能用抽

象的語言（如"處理"、"循環(huán)"等），要精確表達(dá)出程序的處理說明。為避免每行程序都使用

注釋，可以在一段程序的前面加一段注釋,有明確的處理邏輯。

3.3配置文件審核

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

要。對配置文件的審核要求與源代碼的審核要求完全一致。

3.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í)采用。

3.5平臺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ì)測試用例。

3.6集成測試/壓力測試常見的黑盒測試包括：集成測試，條充測試。集成測試是在單元測

試的基礎(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á)到功能要求。3.7

驗(yàn)收測試目的是檢驗(yàn)待驗(yàn)收軟件是否對平臺和其它軟件保持良好的兼容性。四、驗(yàn)收結(jié)論(成績

評定標(biāo)準(zhǔn)）驗(yàn)收結(jié)束時(shí)，根據(jù)以上文檔，填寫驗(yàn)收結(jié)論，對軟件的質(zhì)量做出評價(jià)1.優(yōu)秀1）材料

完整2）軟件可正常運(yùn)行3）實(shí)現(xiàn)項(xiàng)目軟件需求說明書要求的各項(xiàng)功能需求4）軟件界面友好，易于

交互5）軟件功能新穎，有較強(qiáng)創(chuàng)新

2.合格1）本標(biāo)準(zhǔn)第條要求的材料完整2）可正常運(yùn)行實(shí)現(xiàn)功能達(dá)到軟件需求說明書要求的三

分之二以上3.不合格1）標(biāo)準(zhǔn)第條要求的材料不完整2）軟件不能運(yùn)行3）軟件需求說明書要求的

主要功能。

篇四：軟件項(xiàng)目驗(yàn)收流程及方案

軟件項(xiàng)目驗(yàn)收

驗(yàn)收作為項(xiàng)目執(zhí)行過程中的一個(gè)重要的里程碑，對公司和客戶具有重要的意義。

一、驗(yàn)收申請

二、驗(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)系方式。

2.1開發(fā)商資料收集

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

編號

123456789101112131415

名稱

項(xiàng)目開發(fā)計(jì)劃軟件需求說明書系統(tǒng)概要設(shè)計(jì)說明書總體設(shè)計(jì)說明書數(shù)據(jù)庫設(shè)計(jì)說明書詳細(xì)

設(shè)計(jì)文檔為本項(xiàng)目開發(fā)的軟件源代碼FATSAT報(bào)告試運(yùn)行報(bào)告性能測試報(bào)告、功能測試報(bào)告項(xiàng)

目實(shí)施報(bào)告培訓(xùn)計(jì)劃服務(wù)計(jì)劃維護(hù)手冊用戶手冊

形式介質(zhì)

文檔電子、紙質(zhì)文檔電子、紙質(zhì)文檔電子、紙質(zhì)文檔電子、紙質(zhì)文檔電子、紙質(zhì)文檔電子、

紙質(zhì)文檔電子、紙質(zhì)文檔電子、紙質(zhì)文檔電子、紙質(zhì)文檔電子、紙質(zhì)文檔電子、紙質(zhì)文檔電子、

紙質(zhì)文檔電子、紙質(zhì)文檔電子、名氏質(zhì)文檔電子、紙質(zhì)

16

應(yīng)用軟件清單

文檔電子、紙質(zhì)

17

系統(tǒng)參數(shù)配置說明

文檔電子、紙質(zhì)

18

所提供的第三方產(chǎn)品的技術(shù)說明和操作、維護(hù)資料文檔電子、紙質(zhì)

19

系統(tǒng)崩潰及恢復(fù)步驟文檔

文檔電子、紙質(zhì)

20

技術(shù)服務(wù)和技術(shù)培訓(xùn)等相關(guān)資料

文檔電子、紙質(zhì)

21

項(xiàng)目總結(jié)報(bào)告

文檔電子、紙質(zhì)

除上述文檔外，還應(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)。

2.2最終用戶資料收集

依據(jù)軟件開發(fā)需求說明書和概要設(shè)計(jì)說明書，編寫相關(guān)軟件的用戶滿意度調(diào)查表，該調(diào)杳表

應(yīng)該涵蓋軟件在需求說明書中列舉的所有模塊，包含軟件在不同操作系統(tǒng)下的運(yùn)行情況等.最終

用戶或甲方項(xiàng)目組按照實(shí)際情況填寫該調(diào)查表。

三、驗(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í)行程序測試，其II酹

可分為：文檔審核、源代碼審核、配置腳本審核、測試程序、平臺API測試、集成測試、驗(yàn)收

測試等。文檔代碼一致性審核、軟件配置審核是軟件部署和實(shí)施全面驗(yàn)收測試的基礎(chǔ)，由各應(yīng)用

軟件驗(yàn)收責(zé)任人檢有它們的完整性;由于工程升友的各軟件運(yùn)行環(huán)竟均基于審計(jì)管理系統(tǒng)、審計(jì)

實(shí)施系統(tǒng)平臺，最終的集成測試、驗(yàn)收測試由德華工貿(mào)員工、驗(yàn)收專家所有參與驗(yàn)收工作的人員

一起完成。

3.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)容一致性：是否存在前后矛盾;是否存在需求說明中微IJ的功能在概要設(shè)計(jì)、詳細(xì)設(shè)

計(jì)中沒有涉及的情況；

(8)文字明確性:不使用"可能"、"也許"、"待定"等語義含糊不清的語句；

(9)易讀性：能夠在一篇文檔中說明清楚的內(nèi)容,盡量不要拆分成若干文檔，不要循環(huán)引

用，文檔目錄一目了然，結(jié)構(gòu)清晰。

3.2源代碼審核

源代碼審核的主要要求是確保開發(fā)商將全部源程序交付甲方，并確保交付的代碼沒有版權(quán)問

題(由開發(fā)商提供無版權(quán)爭議承諾書)對源代碼審核的具體要求如下：

3.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è)置。

3.2.2代碼完整

(1)開發(fā)商必須把所有弟見用戶需求的代碼交付甲方。

(2)除非已經(jīng)得到甲方的允許,使用的控件也必須有源代碼并得到授權(quán)使用證明;由開發(fā)

商提供無版權(quán)爭議承諾書.

(3)包含開發(fā)工具的程序文件；要求能夠在甲方計(jì)算機(jī)中正常編譯、運(yùn)行；除非得到甲方允

許，在甲方計(jì)算機(jī)中編譯的時(shí)候無需額外安裝開發(fā)工具的插件或控件。

3.2.3可讀性強(qiáng)

注釋是軟件可讀性的具體體現(xiàn)。程序注釋量不少于程序編碼量的30%,程序注釋不能用抽

象的語言(如"處理"、"循環(huán)"等)，要精確表達(dá)出程序的處理說明。為避免每行程序都使用注

釋，可以在一段程序的前面加一段注釋，有明確的處理邏輯。

3.3配置文件審核

對于B/S程序，部署維護(hù)是軟件生存周期中最長的一個(gè)過程,配置文件的審核顯得尤為重要.

對配置文件的審核要求與源代碼的審核要求完仝一致。

3.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í)采用.

3.5平臺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ì)測試用例。

3.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)行所有功能。

3.7驗(yàn)收測試

目的是檢驗(yàn)待驗(yàn)收軟件是否對平臺和其它軟件保持良好的兼容性。

四、驗(yàn)收結(jié)論（成績評定標(biāo)準(zhǔn)）

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

1.優(yōu)秀

1）材料完整

2）軟件可正常運(yùn)行

3）實(shí)現(xiàn)項(xiàng)目軟件需求說明書要求的各項(xiàng)功能需求4）軟件界面友好，易于交互5）軟件功能新

穎，有較強(qiáng)創(chuàng)新2.合格1）本標(biāo)準(zhǔn)第2。1條要求的材料完整2）可正常運(yùn)行實(shí)現(xiàn)功能達(dá)到軟件

需求說明書要求的三分之二以上3.不合格1）標(biāo)準(zhǔn)第2.1條要求的材料不完整2）軟件不能運(yùn)行

3）軟件需求說明書要求的主要功能.

篇五：軟件項(xiàng)目驗(yàn)收流程及方案

一、驗(yàn)收目的為使信息化項(xiàng)目建設(shè)按照標(biāo)準(zhǔn)要求進(jìn)行確保項(xiàng)目竣工后達(dá)到有關(guān)要求和標(biāo)準(zhǔn)，

并能正

常投入運(yùn)行，必須進(jìn)行項(xiàng)目驗(yàn)收。二、驗(yàn)收對象參與項(xiàng)目建設(shè)的施工單位。三、項(xiàng)目驗(yàn)收的

前提條件：

（1）所有建設(shè)項(xiàng)目按照合同要求全部建成，并滿足使用要求；（2）各個(gè)分項(xiàng)工程全吾隨

收合格；（3）已通過軟件確認(rèn)測試評審；（4）已通過軟件系統(tǒng)測試評審；（5）軟件已置于配

置管理之下；（6）各種技術(shù)文檔和驗(yàn)收資料完備，符合合同的內(nèi)容；（7）系統(tǒng)建設(shè)和數(shù)據(jù)處

理符合信息安全的要求，涉密信息系統(tǒng)需提供主管部門驗(yàn)收

的合格證書；（8）外購的操作系統(tǒng)、數(shù)據(jù)庫、中間件、應(yīng)用軟件和開發(fā)工具符合知識產(chǎn)權(quán)

相關(guān)政

策法規(guī)的要求；（9）各種設(shè)備經(jīng)加電試運(yùn)行，狀態(tài)正常；（10）經(jīng)過監(jiān)理方同意；（11）

經(jīng)過相關(guān)主管部門和項(xiàng)目業(yè)主同意；（12）合同或合同附件規(guī)定的其他險(xiǎn)收條件；

四、驗(yàn)收方法項(xiàng)目驗(yàn)收是項(xiàng)目開發(fā)建設(shè)中有組織的主動(dòng)性行為，它是對項(xiàng)目建設(shè)高度負(fù)責(zé)的

體現(xiàn)，也是項(xiàng)目建設(shè)成功的重要保證。切實(shí)做好項(xiàng)目建設(shè)中的驗(yàn)收工作至關(guān)重要，應(yīng)當(dāng)采取有效

措施,實(shí)實(shí)在在做好。為保證項(xiàng)目驗(yàn)收質(zhì)量，針對不同的驗(yàn)收內(nèi)容，在實(shí)施驗(yàn)收操作中，可以采

取以下不同的方法：（一）登記法對項(xiàng)目中所設(shè)計(jì)的所有硬件、軟件和應(yīng)用程序——登記，特別

是硬件使用手冊、軟件使用手冊、應(yīng)用程序各種技術(shù)文檔等一定要登記造冊,不可遺漏，并妥善

保管。對項(xiàng)目建設(shè)中根據(jù)實(shí)際進(jìn)展情況雙方同意后修訂的合同條款、協(xié)調(diào)發(fā)展建設(shè)中的問題進(jìn)行

登記。（二時(shí)照法對照檢查項(xiàng)目各項(xiàng)建設(shè)內(nèi)容的結(jié)果是否與合同條款及工程施工方案一致其三）

操作法這是項(xiàng)目建設(shè)最主要的驗(yàn)收方法。首先，最項(xiàng)目系統(tǒng)硬件——實(shí)際加電操作，驗(yàn)證是否與

硬件提供的技術(shù)性能相一致；其次，運(yùn)行項(xiàng)目軟件系統(tǒng)，檢驗(yàn)其管理硬件及應(yīng)用軟件的實(shí)際能力

是否與合同規(guī)定的一致；第三，運(yùn)行應(yīng)用軟件，實(shí)際操作，處理業(yè)務(wù)，檢餐是否與合同規(guī)定的一

致，達(dá)到了預(yù)期的目的。（四）測試法對能使用檢測儀器進(jìn)行檢測的設(shè)備，實(shí)施應(yīng)當(dāng)一進(jìn)行實(shí)際

測試，檢查是否和設(shè)備、實(shí)施的規(guī)格、性能要求相一致。五、臉收步驟（一）需求分析

項(xiàng)目監(jiān)理單位組織人員對項(xiàng)目進(jìn)行驗(yàn)收需求分析，針對項(xiàng)目驗(yàn)收，監(jiān)理單位需配備2名有

經(jīng)驗(yàn)的工程師和一名行業(yè)專家來組成項(xiàng)目團(tuán)隊(duì)，負(fù)責(zé)具體工作。

（二）編寫驗(yàn)收方案（計(jì)劃書）項(xiàng)目監(jiān)理單位在對項(xiàng)目進(jìn)行深入的需求分析的基礎(chǔ)上編寫驗(yàn)

收方案（計(jì)劃書），提交業(yè)主單

位審定。（三）成立項(xiàng)目蛇收小組實(shí)施測試驗(yàn)收工作時(shí)，應(yīng)當(dāng)成立項(xiàng)目驗(yàn)收小組，具體負(fù)責(zé)

驗(yàn)收事宜。（四）項(xiàng)目驗(yàn)收的實(shí)施嚴(yán)格按照驗(yàn)收方案對項(xiàng)目應(yīng)用軟件、網(wǎng)絡(luò)集成效果、系統(tǒng)文檔

資料等進(jìn)行全面的測試和驗(yàn)收。（五）提交驗(yàn)收報(bào)告項(xiàng)目驗(yàn)收完畢,對項(xiàng)目系統(tǒng)設(shè)計(jì)、建設(shè)質(zhì)量、

設(shè)備治療、軟件運(yùn)行情況等做出全面的評價(jià)，得出結(jié)論性意見，對不合格的項(xiàng)目不予驗(yàn)收，對一

流問題提出具體的解決意見。（六）召開項(xiàng)目驗(yàn)收評審會(huì)召開由驗(yàn)收委員會(huì)全體成員參加的項(xiàng)目

驗(yàn)收評審會(huì)，全面細(xì)致的審核項(xiàng)目銷售小組所提交的驗(yàn)收報(bào)告，給出最終的驗(yàn)收意見，形成驗(yàn)收

評審報(bào)告提交項(xiàng)目業(yè)主存檔。六、驗(yàn)收程序

（一）初驗(yàn)1、申請：項(xiàng)目竣工后經(jīng)測試和試運(yùn)行合格，施工單位根據(jù)合同、招標(biāo)書、計(jì)劃

任務(wù)書,檢直、總結(jié)項(xiàng)目完成情況后向業(yè)主提出初驗(yàn)申請。2、方式:項(xiàng)目業(yè)主組織監(jiān)理和施工

單位進(jìn)行初驗(yàn)。3、施工單位提供材料：初驗(yàn)申請書、完工報(bào)告、項(xiàng)目總結(jié)、一級要求的驗(yàn)收評

審資料。（二）終驗(yàn)1、申請：初驗(yàn)合格后，項(xiàng)目業(yè)主根據(jù)合同、招標(biāo)書、任務(wù)書，檢直、總結(jié)

項(xiàng)目實(shí)施和完成情況后向主管部門提出驗(yàn)收申請。

2、經(jīng)過審核，材料齊全則由主管部門組織驗(yàn)收。驗(yàn)收工作有由主管部門和項(xiàng)目業(yè)主、監(jiān)理

等單位和專家組組成驗(yàn)收小組進(jìn)行驗(yàn)收。驗(yàn)收

工作分為兩個(gè)步驟：驗(yàn)收小組和驗(yàn)收評委會(huì)評審，由驗(yàn)收小組共同確定驗(yàn)收時(shí)間、評審時(shí)間

及其他安排。（1）驗(yàn)收小組驗(yàn)收

驗(yàn)收小組一般由5-8人組成，成員由主管部門和項(xiàng)目業(yè)主的管理人員、監(jiān)理單位專業(yè)技術(shù)

人員共同完成。驗(yàn)收時(shí)參照相關(guān)險(xiǎn)收內(nèi)容及標(biāo)準(zhǔn)進(jìn)行，驗(yàn)收后必須提交瞼收報(bào)告。（2）驗(yàn)收委

員會(huì)評審

驗(yàn)收委員會(huì)一般由8-15人組成成員由驗(yàn)收小組及主管部門、項(xiàng)目業(yè)主和監(jiān)理單位的領(lǐng)導(dǎo)、

專家等組成。驗(yàn)收委員會(huì)評審一般采取會(huì)議評議方式進(jìn)行，聽取驗(yàn)收總結(jié)報(bào)告說明、驗(yàn)收小組驗(yàn)

收結(jié)果及意見，通過評審提交驗(yàn)收評審報(bào)告。（3）項(xiàng)目業(yè)主提供材料：驗(yàn)收申請、項(xiàng)目建設(shè)總

結(jié)性評價(jià)報(bào)告（組織與實(shí)施協(xié)調(diào)）、項(xiàng)目實(shí)施報(bào)告（技術(shù)、項(xiàng)目管理、質(zhì)量控制）、相關(guān)文檔資

料、驗(yàn)收安排計(jì)劃、驗(yàn)收小組及委員會(huì)名單、驗(yàn)收計(jì)劃書（由監(jiān)理單位負(fù)責(zé)）

3、驗(yàn)收簽字經(jīng)過驗(yàn)收、評審形成的驗(yàn)收報(bào)告和評審報(bào)告，驗(yàn)收委員會(huì)成員簽字。七、驗(yàn)收

依據(jù)作為項(xiàng)目驗(yàn)收的依據(jù)，一般選用項(xiàng)目合同書、國標(biāo)、行業(yè)標(biāo)準(zhǔn)和相關(guān)政策法規(guī)、國際慣例等。

（一）項(xiàng)目合同書簽定的項(xiàng)目有關(guān)合同（二）國家標(biāo)準(zhǔn)硬件、軟件、布線、安全等（三）新疆省

信息化項(xiàng)目建設(shè)管理暫行辦;在四其他具體驗(yàn)收標(biāo)準(zhǔn)和一句由監(jiān)理單位根據(jù)具體項(xiàng)目情況提出，

主管部門和項(xiàng)目業(yè)主審定。八、驗(yàn)收內(nèi)容和標(biāo)準(zhǔn)根據(jù)具體項(xiàng)目實(shí)際制定，由項(xiàng)目監(jiān)理單位負(fù)責(zé)編

寫，主管部門和項(xiàng)目業(yè)主審定。項(xiàng)目驗(yàn)收標(biāo)準(zhǔn)是判斷項(xiàng)目成果是否達(dá)到要求的一句，因而應(yīng)具有

科學(xué)性和權(quán)威性，只有制定科學(xué)的標(biāo)準(zhǔn)，才能有效的驗(yàn)收項(xiàng)目結(jié)果。驗(yàn)收內(nèi)容一般包括測試（復(fù)

核）、資料評審、質(zhì)量鑒定三部分。

驗(yàn)收的內(nèi)容包括以下幾個(gè)部分:（一）驗(yàn)收內(nèi)容一般包括軟件驗(yàn)收（按功能要求的可執(zhí)行軟

件、開發(fā)計(jì)劃文檔、

詳細(xì)設(shè)計(jì)文檔、質(zhì)量保證計(jì)劃、設(shè)備相應(yīng)附件、設(shè)備運(yùn)行、網(wǎng)絡(luò)運(yùn)行等）（二）驗(yàn)收評測工

作主要包括：文檔分析、方案制定、現(xiàn)場測試、問題單提交、

測試報(bào)告；（三）驗(yàn)收測試內(nèi)容主要包括：功能度、安全可靠性、易用性、可擴(kuò)充性、兼容

性、效率、資源占用率、用戶文檔。（四）文檔驗(yàn)收標(biāo)準(zhǔn)一般包括：文檔完備性、內(nèi)容針對

性、內(nèi)容充分性、內(nèi)容一

致性、文字明確性、圖表許文性、易讀性、文檔價(jià)值等。（五）軟件、硬件驗(yàn)收標(biāo);住要符合

國家和相關(guān)標(biāo)準(zhǔn)。需要評審的資料包括以下幾個(gè)部分:（-）基砒資料：招標(biāo)書、投標(biāo)書、有關(guān)

合同、有關(guān)批復(fù)文件、系統(tǒng)設(shè)計(jì)說明書、系

統(tǒng)功能說明書、系統(tǒng)結(jié)構(gòu)圖、項(xiàng)目i錨實(shí)施方案。（二）項(xiàng)目竣工資料：項(xiàng)目開工報(bào)告、項(xiàng)

目實(shí)施報(bào)告、項(xiàng)目質(zhì)量測試報(bào)告、項(xiàng)目檢查

報(bào)告、測試報(bào)告、材料清單、項(xiàng)目實(shí)施質(zhì)量與安全檢查記錄、操作使用說明書、

售后服務(wù)保證文件、培訓(xùn)文檔、其他文件。（三）軟件開發(fā)文檔：需求說明書、、概要設(shè)計(jì)

說明書、詳細(xì)設(shè)計(jì)說明書、數(shù)據(jù)庫設(shè)計(jì)

說明書、測試計(jì)劃、測試報(bào)告、程序維護(hù)手冊、程序員開發(fā)手冊、用戶操作手冊。（四）軟

件開發(fā)管理文檔：項(xiàng)目計(jì)劃書、質(zhì)量控制計(jì)劃、配置管理計(jì)劃、用戶培訓(xùn)計(jì)劃、質(zhì)量總結(jié)報(bào)告、

會(huì)議記錄和開發(fā)進(jìn)度月報(bào)。九、險(xiǎn)收結(jié)論驗(yàn)收結(jié)果分為:驗(yàn)收合格、需要復(fù)議和驗(yàn)收不合格三種。

符合信息化項(xiàng)目建設(shè)標(biāo)準(zhǔn)、系統(tǒng)運(yùn)行安全可靠、任務(wù)按期保質(zhì)完成、經(jīng)費(fèi)使用合理的，視為驗(yàn)收

合格；由于提供材料不詳難以判斷，或目標(biāo)任務(wù)完成不足80%而又難以確定其原因等導(dǎo)致驗(yàn)收

結(jié)論爭議較大的，視為需要復(fù)議.1、項(xiàng)目凡具有下列情況之一的，按驗(yàn)收不合格處理：（一）

未按項(xiàng)目考核指標(biāo)或合同要求達(dá)到所預(yù)定的主要技術(shù)指標(biāo)的；（二）所提供材料不齊全或不真實(shí)

的；（三）項(xiàng)目的內(nèi)容、目標(biāo)或技術(shù)路線等已進(jìn)行了較大調(diào)整，但未曾得到相關(guān)單位認(rèn)可的；（四）

實(shí)施過程中出現(xiàn)重大問題，尚未解決和作出說明或項(xiàng)目實(shí)施過程及結(jié)果等存在糾紛尚未解決的；

（五）沒有對系統(tǒng)或設(shè)備進(jìn)行試運(yùn)行，或者運(yùn)行不合格；（六）項(xiàng)目經(jīng)費(fèi)使用情況審計(jì)發(fā)現(xiàn)問題

的；（七）違犯法律、法規(guī)的其他行為；2、驗(yàn)收結(jié)論確認(rèn)和處理由主管單位同相關(guān)部門根據(jù)驗(yàn)

收已經(jīng)和相關(guān)資料得出結(jié)論，并進(jìn)行確認(rèn)。3、項(xiàng)目驗(yàn)收結(jié)論的處理（一）驗(yàn)收結(jié)論為驗(yàn)收合格

的，項(xiàng)目業(yè)主將全部驗(yàn)收材料同意裝訂成冊并連同相

應(yīng)的電子文檔分別報(bào)主管部門及相關(guān)部門備案。（二）驗(yàn)收結(jié)論需要復(fù)議的，主管部門以書

面形式通知建設(shè)單位在三個(gè)月內(nèi)補(bǔ)充

有關(guān)材料或者進(jìn)行相關(guān)說明。（三）驗(yàn)收結(jié)論為驗(yàn)收不合格的，主管部門以書面形式通知項(xiàng)

目業(yè)主和設(shè)計(jì)、施

工單位，限期整改，整改后試運(yùn)行合格的，項(xiàng)目業(yè)主重新申請驗(yàn)收。（四）未通過驗(yàn)收的信

息化項(xiàng)目，和導(dǎo)交付使用。十、項(xiàng)目交接項(xiàng)目竣工驗(yàn)收合格后，應(yīng)班里項(xiàng)目交接手續(xù)。項(xiàng)目的移

交包括實(shí)體移交和項(xiàng)目文件移交部分。十一、各項(xiàng)目業(yè)主和監(jiān)理單位要嚴(yán)格參照此方案開展項(xiàng)目

驗(yàn)收工作。

篇六：軟件項(xiàng)目驗(yàn)收流程及方案

工程驗(yàn)收過程

驗(yàn)收作為工程執(zhí)行過程中一個(gè)重要里程碑，對公司與客戶具有重要意義。

一、驗(yàn)收申請

二、驗(yàn)收準(zhǔn)備

2.1開發(fā)商資料收集

根據(jù)軟件工程特點(diǎn)，在驗(yàn)收時(shí)應(yīng)收集以下文檔：

編號

名稱

1工程開發(fā)方案

2軟件需求說明書

3系統(tǒng)概要設(shè)計(jì)說明書

4總體設(shè)計(jì)說明書

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

形介質(zhì)

式

文電子、紙質(zhì)

檔

文電子、紙質(zhì)

檔

文電子、紙質(zhì)

檔

文電子、紙質(zhì)

檔

文電子、紙質(zhì)

檔

第1頁

6詳細(xì)設(shè)計(jì)文檔

7為本工程開發(fā)軟件源代碼

8FATSAT報(bào)告

9試運(yùn)行報(bào)告

10性能測試報(bào)告、功能測試報(bào)告

11工程實(shí)施報(bào)告

12培訓(xùn)方案

13效勞方案

14維護(hù)手冊

15用戶手冊

16應(yīng)用軟件清單

第2頁

文電子、紙質(zhì)

檔

文電子、紙質(zhì)

檔

文電子、紙質(zhì)

檔

文電子、紙質(zhì)

檔

文電子、紙質(zhì)

檔

文電子、紙質(zhì)

檔

文電子、紙質(zhì)

檔

文電子、紙質(zhì)

檔

文電子、紙質(zhì)

檔

文電子、紙質(zhì)

檔

文電子、紙質(zhì)

檔

17系統(tǒng)參數(shù)配置說明

文電子、紙質(zhì)

檔

所提供第三方產(chǎn)品技術(shù)說明與操作、維文

18

電子、紙質(zhì)

護(hù)資料

檔

19系統(tǒng)崩潰及恢復(fù)步驟文檔

文電子、紙質(zhì)

檔

20技術(shù)效勞與技術(shù)培訓(xùn)等相關(guān)資料

文電子、紙質(zhì)

檔

21工程總結(jié)報(bào)告

文電子、紙質(zhì)

檔

除上述文檔外，還應(yīng)單獨(dú)收集、保存各應(yīng)用軟件源程序代碼及開發(fā)商所用第三方資源信息。

開發(fā)商所使用第三方控件，除已經(jīng)得到審計(jì)署許可之外，必須提供控件源代碼，并擁有授權(quán)使用

證明或保證〔由開發(fā)商提供無版權(quán)爭議承諾書）；對于原始程序代碼，要求能夠在本地不經(jīng)過任

何特殊設(shè)置，即可編譯并正常運(yùn)行.源程序清單中列舉工程應(yīng)該與源程序——對應(yīng).

2.2最終用戶資料收集

依據(jù)軟件開發(fā)需求說明書與概要設(shè)計(jì)說明書，編寫相關(guān)軟件用戶滿意度調(diào)查表，該調(diào)查表應(yīng)

該涵蓋軟件在需求說明書中列舉所有模塊，包含軟件在不同操作系統(tǒng)下運(yùn)行情況等。最終用戶或

甲方工程組按照實(shí)際情況填寫該調(diào)查表。

第3蟲

三、驗(yàn)收測試

驗(yàn)收測試是軟件開發(fā)完畢后用戶對軟件產(chǎn)品投入實(shí)際應(yīng)用以前進(jìn)展最后一次質(zhì)量檢驗(yàn)活^，

它要答復(fù)開發(fā)軟件產(chǎn)品是否符合預(yù)期各項(xiàng)要求，以及用戶能否承受問題。由于它不只是檢驗(yàn)軟件

某個(gè)方面質(zhì)量，而是要進(jìn)展全面質(zhì)量檢驗(yàn)，并且要決定軟件是否合格，因此驗(yàn)收測試是一項(xiàng)嚴(yán)格

正式測試活動(dòng).需要I艮據(jù)事先制訂方案，進(jìn)展軟件配置評審、功能測試、性能測試等多方面檢測。

軟件驗(yàn)收測試分為三局部：文檔代碼一致性審核、軟件配置審核與可執(zhí)行程序測試，其順序

可分為：文檔審核、源代碼審核、配置腳本審核、測試程序、平臺API測試、集成測試、驗(yàn)收

測試等。文檔代碼一致性審核、軟件配置審核是軟件吾儲與實(shí)施全面驗(yàn)收測試根底，由各應(yīng)用軟

件驗(yàn)收責(zé)任人檢查它們完整性；由于工程開發(fā)各軟件運(yùn)行環(huán)境均基于審計(jì)管理系統(tǒng)、審計(jì)實(shí)施系

統(tǒng)平臺，最終集成測試、驗(yàn)收測試由德華工貿(mào)員工、驗(yàn)收專家所有參與驗(yàn)收工作人員一起完成。

3.1文檔審核

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

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

第4頁

(2)內(nèi)容針對性力旨文檔是否是甲方要求文檔；文檔內(nèi)容應(yīng)雌照功能模塊重要性在論)上

到達(dá)不同詳細(xì)程度；

(3)內(nèi)容充分性:指該文檔仝面、許細(xì)程度；

(4)文檔價(jià)值文檔應(yīng)該能夠反映軟件開發(fā)整個(gè)過程，即需求中提到功能在概要設(shè)計(jì)中表達(dá),

在詳細(xì)設(shè)計(jì)中實(shí)現(xiàn)，在測試方案中檢驗(yàn)；

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

(6)符合甲方標(biāo)準(zhǔn)程度：是否很好地符合甲方要求標(biāo)準(zhǔn)、標(biāo)定；

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

中沒有涉及情況；

(8)文字明確性：不使用"可能"、"也許"、"待定”等語義模制不清語句；

(9〕易讀性:能夠在一篇文檔中說明清楚內(nèi)容，盡量不要拆分成假設(shè)干文檔，不要循環(huán)引用，

文檔目錄一目了然，構(gòu)造清晰。

3.2源代碼審核

源代碼審核主要要求是確保開發(fā)商將全部源程序交付甲方，并確保交付代碼沒有版權(quán)問題

〔由開發(fā)商提供無版權(quán)爭議承諾書)對源代碼審核具體要求如下：

3.2.1版權(quán)明晰

第5頁

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

(2)得到甲方允許，可以使用控件，由開發(fā)商提供無版權(quán)爭議承諾書。使用其他具有源代

碼控件，均需要當(dāng)作提交代碼一局部，直接置于編譯環(huán)境工程文件中，在編譯發(fā)布時(shí)無需額外設(shè)

置。

3.2.2代碼完整

(1)開發(fā)商必須把所有則用戶需求代碼交付甲方。

(2)除非已經(jīng)得到甲方允許,使用控件也必須有源代碼,并得到授權(quán)使用證明；由開發(fā)商

提供無版權(quán)爭議承諾書。

[3[包含開發(fā)工具程序文件；要求能夠在甲方計(jì)算機(jī)中正常編譯、運(yùn)行；除非得到甲方允

許，在甲方計(jì)算機(jī)中編譯時(shí)候無需額外安裝開發(fā)工具插件或控件。

3.2.3可讀性強(qiáng)

注釋是軟件可讀性具體表達(dá)。程序注釋量不少于程序編碼量30%。程序注釋不能用抽象語

言〔如"處理"、"循環(huán)"等〕，要準(zhǔn)確表達(dá)出程序處理說明。為防止每行程序都使用注釋，可

以在一段程序前面加一段注釋,有明確處理邏輯。

3.3配置文件審核

第6頁

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

對配置文件審核要求與源代碼審核要求完全一致。

3.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)收測試。

第7頁

(2)抽樣測試方案：在設(shè)計(jì)文檔中隨機(jī)選取，根據(jù)抽樣樣本大小不同，最后得到結(jié)論可能

會(huì)出現(xiàn)差異。這種方案實(shí)現(xiàn)耗時(shí)可長可短，適合軟件未得到大面積適用前驗(yàn)收時(shí)采用。

3.5平臺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ì)測試用例。

3.6集成測試/壓力測試

常見黑盒測試包括：集成測試，系統(tǒng)測試。集成測試是在單元?jiǎng)t試根底上,將所有模塊按照

設(shè)計(jì)要求〔如根據(jù)構(gòu)造圖〕組裝成為子系統(tǒng)或系統(tǒng)，進(jìn)展集成測試。實(shí)踐說明，一些模塊雖然能

夠單獨(dú)地工作，但并不能保證連