1、代碼管理制度1 總那么 22 源代碼完整性保障 23 源代碼的授權(quán)訪問 24 代碼版本管理 35 源代碼復(fù)制和傳播 46 系統(tǒng)測試驗收流程 5系統(tǒng)初驗 . 5試運行 . 5系統(tǒng)終驗 . 5系統(tǒng)驗收標(biāo)準(zhǔn) . 6文檔評審?fù)ㄟ^標(biāo)準(zhǔn). 7確認(rèn)測試通過標(biāo)準(zhǔn). 7系統(tǒng)試運行通過標(biāo)準(zhǔn) . 71 總那么1、為保障公司源代碼和開發(fā)文檔平安不至于泄露，保證源代碼的完整，明確源代碼控 制管理流程，特制定此管理方法。2、本方法適用于所有涉及接觸源代碼的各部門各崗位。所涉及部門都必須嚴(yán)格執(zhí)行本 管理方法。3、源代碼直接控制管理部門為技術(shù)開發(fā)部。4、本方法管理重點在于控制管理源代碼的完整性，不被非授權(quán)獲取，不被非授權(quán)復(fù)制

2、 和傳播。5、本方法所指源代碼不僅限于公司開發(fā)人員自行編寫實現(xiàn)功能的程序代碼，而且還包 括相應(yīng)的開發(fā)設(shè)計文檔及用于支撐整個系統(tǒng)運行所必須具備的第三方軟件、 控件和其它支撐 庫等文件。2 源代碼完整性保障1、所有軟件的源代碼文件及相應(yīng)的開發(fā)設(shè)計文檔均必須及時參加到指定的源代碼效勞 器中的指定庫中。2、我們研發(fā)的產(chǎn)品軟件運行所必須的第三方軟件、控件和其它支撐庫等文件也必須及 時參加源代碼效勞器中指定的庫中。3、軟件開始編寫或者調(diào)整代碼之前，其相應(yīng)的設(shè)計文檔和代碼必須先從相應(yīng)的SVN庫進行 SVNUpdate 操作。軟件編碼或功能調(diào)整結(jié)束測試正確無誤后，相應(yīng)的源代碼必須進行 SVNCommit操作，

3、在最終進行 SVNCommi操作之前需要再進行 SVNUpdate操作，查看是否有 沖突產(chǎn)生，如果有沖突產(chǎn)生需要和沖突相關(guān)人一并解決沖突。3 源代碼的授權(quán)訪問1、源代碼效勞器對于共享的 SVN庫的訪問建立操作系統(tǒng)級的，基于身份和口令的訪問 授權(quán)。第十條 在SVN庫中設(shè)置用戶，并為不同用戶分配不同的，適合工作的最小訪問權(quán)限。要求連接SVN庫時必須校驗 SVN中用戶身份及其口令。在SVN庫中要求區(qū)別對待不同用戶的可訪問權(quán)、可讀權(quán)、可寫權(quán)。2、曾經(jīng)涉及、觸及源代碼的電腦在轉(zhuǎn)作它用，或者離開研發(fā)部門之前必須由網(wǎng)絡(luò)管理 人員全面去除電腦硬盤中存儲的源代碼。 如果不能確定， 必須對電腦中所有硬盤進行全面格

4、 式化前方可以轉(zhuǎn)做它用或離開研發(fā)部門。4 代碼版本管理1、終端軟件的版本標(biāo)識管理終端軟件版本由終端型號、版本號和內(nèi)部修訂號來進行標(biāo)識。 終端型號：終端型號是硬件標(biāo)識號，也唯一的標(biāo)識了我們的工程。版本號：由“V主版本號 V次版本號 V修訂號三段組成，中間是點號分開。版本號的目的主要是管理終端軟件的對外發(fā)布，終端軟件的BUG的記錄和統(tǒng)計，主要是針對于版本號的，測試部、工程部、客戶等會記錄某個版本號的終端軟件存在哪些BUG,B UG會在哪個版本號中得到修正；終端軟件一個新的版本號出來后，我們會統(tǒng)計新的版本號解決了上一個版本號中的哪些BUG，以及增加了哪些新功能，等等。內(nèi)部修訂號：也就是“應(yīng)用程序的源

5、代碼的 svn 修訂號，主要是由軟件部和測試部內(nèi) 部來使用， 內(nèi)部修訂號唯一標(biāo)識我們的終端軟件， 即：通過內(nèi)部修訂號能夠唯一的找出我們 發(fā)布的終端軟件所對應(yīng)的全部軟件源代碼，目的是為了軟件排錯使用。另外，終端軟件在發(fā)布時，還會給出發(fā)布日期，以便開發(fā)、測試、工程、客戶等相關(guān)人2、終端軟件版本發(fā)布管理 終端軟件主要是以版本號為基準(zhǔn)， 對外發(fā)布， 目前采用不定時發(fā)布策略， 發(fā)布的時間由 軟件部、工程部和客戶方根據(jù)情況，共同商量決定。由于目前工程時間緊， 終端軟件無法得到完整的測試就要發(fā)布， 在發(fā)布之后， 有一些需要緊急需要修復(fù)的 BUG軟件部需要緊急修復(fù)后就要發(fā)布更新包， 以便用戶能夠使用，所以,在

6、一個版本號發(fā)布后，需要進行屢次修訂，對于這些修訂的版本，其版本號保持不變， 內(nèi)部修訂發(fā)生變化。軟件BUG記錄、管理和統(tǒng)計軟件BUG的記錄、 管理和統(tǒng)計主要以版本號為基準(zhǔn)，但為了軟件開發(fā)人員能夠找到BUG的出處，需要用戶、測試人員在報告和驗證BUG時，輸入內(nèi)部修訂號。3、軟件配置組對版本的記錄軟件版本記錄的目標(biāo)有兩個：記錄軟件版本的發(fā)布歷史；發(fā)布的每一個版本，都要能夠唯一的從源代碼庫SVN中找到對應(yīng)的全部源代碼。測試方案： 作為軟件開發(fā)的重要環(huán)節(jié)， 作為交付成功的優(yōu)質(zhì)的產(chǎn)品的重要保證手段和方 法，軟件測試越來越受到工程的重視。要做好測試首先要做好測試的組織、管理、計設(shè)、實 施等工作。系統(tǒng)測試方案

7、概述： 測試是指在軟件投入運行前， 對軟件需求分析、 設(shè)計規(guī)格說明和編 碼的最終復(fù)審，是軟件質(zhì)量保證的關(guān)鍵步驟。測試的目標(biāo)： 以較少的用例、 時間和人力找出軟件中潛在的各種錯誤和缺陷， 以確保系 統(tǒng)的質(zhì)量。在實際工程中， 測試作為軟件開發(fā)生命周期中的一個重要過程， 但從其具體工作的前后 過程來看， 它又是由一系列的不同測試所組成，這些測試的步驟分為： 單元測試、 集成測試 又稱組裝測試 、確認(rèn)測試和系統(tǒng)測試。 軟件開發(fā)的過程是自頂向下的， 測試那么正好相反， 以上這些過程就是自底向上， 逐步集成的。 在工程過程中， 我們按以上的測試步驟完成系統(tǒng) 的測試。5 源代碼復(fù)制和傳播1、源代碼向研發(fā)部門

8、以外復(fù)制必須獲得總經(jīng)理的書面授權(quán)。并必需記錄復(fù)制人、批準(zhǔn) 人、復(fù)制時間、復(fù)制目的、文件流向、文件版本或內(nèi)容。2、源代碼以任何介質(zhì)形式進行存儲的備份，必須由專人負(fù)責(zé)保管。對于這些介質(zhì)地借 閱，用于研發(fā)部內(nèi)部使用的必須獲得研發(fā)部經(jīng)理的授權(quán)， 對于用于研發(fā)部以外使用的必須獲 得總經(jīng)理的書面授權(quán)。3、源代碼的借閱、復(fù)制必須進行詳細的登記，必需記錄借閱人、批準(zhǔn)人、借閱時間、 借閱目的、文件流向、文件版本或內(nèi)容、歸還時間。4、任何紙質(zhì)材料的借閱都必需記錄借閱人、批準(zhǔn)人、借閱時間、借閱目的、文件流向、 文件版本或內(nèi)容、歸還時間。5、對于因合作需要，需要向外復(fù)制、傳播、分發(fā)源代碼的，不管是全部還是局部代碼 和

9、資料， 均必需和對方簽訂技術(shù)、 源碼的保密協(xié)定， 明確對方應(yīng)當(dāng)承當(dāng)?shù)膶υ创a保密的責(zé)任 和義務(wù)。6 系統(tǒng)測試驗收流程嚴(yán)格執(zhí)行代碼管理流程。對于開發(fā)完成的系統(tǒng)進行測試發(fā)布。測試發(fā)布流程如下：6.1 系統(tǒng)初驗系統(tǒng)初驗由技術(shù)開發(fā)部進行單項測試， 系統(tǒng)進行聯(lián)調(diào)測試無誤后， 由開發(fā)部編制工程測 試報告，提交測試報告給匯測試部審核，完成系統(tǒng)初驗。6.2 試運行本系統(tǒng)集成后上線運行三個月為試運行期。由公司技術(shù)人員現(xiàn)場排除系統(tǒng)試運行過程中出現(xiàn)的硬件故障及軟件故障， 對于易出現(xiàn)問 題的設(shè)備提供備用件。技術(shù)人員隨時解答業(yè)務(wù)人員在使用過程中出現(xiàn)的問題并進行解決。6.3 系統(tǒng)終驗正式驗收主要圍繞設(shè)備的配置、 功能、 性

10、能及各項技術(shù)參數(shù)指標(biāo)進行， 完成用戶整體的 系統(tǒng)驗收。當(dāng)整個系統(tǒng)進入試運行期， 技術(shù)開發(fā)部提供行之有效的技術(shù)支持以確保整個業(yè)務(wù)的穩(wěn)定 和有效地運營， 并確保整個業(yè)務(wù)能夠順利通過系統(tǒng)驗收。 在此同時， 技術(shù)開發(fā)部將通過具體 的技術(shù)支持幫助匯運維操作人員熟悉和掌握這些設(shè)備和維護技術(shù)。系統(tǒng)試運行期是一個非常重要的時期。 在此期間， 由于運維技術(shù)人員的技術(shù)水平、 設(shè)備 管理、 設(shè)備操作和具體設(shè)備維護之間的磨合， 將會出現(xiàn)許多意想不到的問題和人為故障。 因 此在系統(tǒng)試運行期， 技術(shù)開發(fā)人員需配合運維人員提出的要求提供必要的現(xiàn)場技術(shù)支持， 同 時通過定期維護以防止設(shè)備故障的發(fā)生。在通過系統(tǒng)試運行的情況下，

11、 技術(shù)開發(fā)的工程小組將和業(yè)務(wù)運營人員以及運維人員進行 系統(tǒng)終驗。系統(tǒng)調(diào)試、驗收程序：驗收采取過程中定期抽檢、 全檢，最后實行總體驗收的方法進行。 程序為報告申請驗收， 各有關(guān)單位會同驗收，最后會簽認(rèn)同。參見以下圖：系統(tǒng)驗收將由驗收小組進行，驗收時做好記錄，簽署驗收證書，并立檔、歸檔。當(dāng)驗收不合格時，技術(shù)人員需無條件進行返修。系統(tǒng)的安裝驗收主要有以下內(nèi)容：1系統(tǒng)設(shè)備器材清單明細以及隨設(shè)備包裝的各種附件、資料等是否齊全；2各主要設(shè)備器材的外觀評估與內(nèi)在技術(shù)指標(biāo)確認(rèn)；3系統(tǒng)安裝整體外觀效果評估；3各系統(tǒng)工程各相關(guān)技術(shù)文件、現(xiàn)場檢查驗收記錄等是否齊全；4系統(tǒng)的安裝客觀測試；5系統(tǒng)的工程安裝驗收將按用戶

12、需求進行。6.4系統(tǒng)驗收標(biāo)準(zhǔn)工程的驗收工作包括兩個方面的活動：文檔評審和軟件產(chǎn)品包的測試與試運行檢驗，對于不同的驗收活動制定不同的驗收通過標(biāo)準(zhǔn)。衡量被評審文檔或被測試軟件產(chǎn)品質(zhì)量的一個重要指標(biāo)是：評審或測試發(fā)現(xiàn)的缺陷數(shù)。為進一步明確文檔或軟件產(chǎn)品的質(zhì)量水平，需要對發(fā)現(xiàn)的缺陷按其嚴(yán)重程度進行分類，在本工程中，將對缺陷分為四個等級，如下表所示：嚴(yán)重等級分類的解釋嚴(yán)重的缺陷對進度的影響可能是非常致命的，或者可能是一個停止器一一 即終止用戶繼續(xù)使用系統(tǒng)主要的相冋類型的缺陷在很多程序或模塊中出現(xiàn)，需要改正每一個缺陷。例如，在任一程序中沒有遵守編程標(biāo)準(zhǔn)。或者，缺陷終止了用戶按正常方式繼續(xù)前進，但可以繞行次

13、要的這個缺陷是獨立的缺陷，或者不影響用戶繼續(xù)前進，但會帶來不便普通的缺陷并不影響軟件產(chǎn)品的性能，例如，美觀問題和消息中的語法錯 誤等6.5 文檔評審?fù)ㄟ^標(biāo)準(zhǔn)按照評審對象的規(guī)模頁數(shù)，根據(jù)評審?fù)度氲墓ぷ髁亢桶l(fā)現(xiàn)的缺陷數(shù)來確定是否通過 評審：評審?fù)度氲墓ぷ髁吭u審準(zhǔn)備和評審會議的時間：是否在一個合理的范圍內(nèi)，如果投入的評審時間過低，那么不管發(fā)現(xiàn)的缺陷數(shù)如何，都不能通過評審。發(fā)現(xiàn)的陷數(shù)：是否在一個合理的范圍內(nèi)，如果發(fā)現(xiàn)的缺陷數(shù)太多，那么不能通過評審。如果發(fā)現(xiàn)的缺陷數(shù)低于合理的水平，那么需要分析評審過程和評審人員，以便確定是否通過評審。6.6確認(rèn)測試通過標(biāo)準(zhǔn)對軟件產(chǎn)品包確實認(rèn)測試，根據(jù)測試用例質(zhì)量、執(zhí)行測試用例情況和發(fā)現(xiàn)的缺陷數(shù)來確 定是否通過確認(rèn)測試：測試用例質(zhì)量：是否通過評審，如果測試用例沒有通過評審，那么不能進入確認(rèn)測試過程。測試用例的執(zhí)行：確認(rèn)測試過程必須保證執(zhí)行了所有確實認(rèn)測試用例數(shù)據(jù)，測試結(jié)果得到真實記錄。發(fā)現(xiàn)的陷數(shù)：與以前階段成果評審、軟件產(chǎn)品的集成測試和系統(tǒng)測試所發(fā)現(xiàn)的缺陷數(shù)相