1.1. 編碼規(guī)范

軟件程序開發(fā)需要遵守編碼規(guī)范，一是可以減少代碼的維護成本，提高開發(fā)工作效率；二是有利于開發(fā)工作的延續(xù)、傳承，減小項目風險。

　1.1.1. 合理的注釋量

　　好的代碼應該是自描述的，讓人費解的地方加上注釋。

　1.1.2. 規(guī)范的命名格式

　　規(guī)范很多，要讓別人和一個月的自己看得懂。

1.2. 測試與測試結果

??1.2.1. 單元測試與報告

單元測試一定要做。深入理解“ test driven development”思想，有條件的話，先寫測試代碼，后寫開發(fā)代碼。綜合使用各種覆蓋方法，例如：路徑、函數(shù)、條件、語句，Code Coverage確保高于80%。

　　統(tǒng)一提供單元測試報告。

　1.2.2. 集成測試與報告

　　集成測試也一定要做。測試工作要覆蓋所有模塊和接口。

　　統(tǒng)一提供集成測試報告。

　1.2.3. 系統(tǒng)測試

　　單元和集成通過后，項目提測并進入系統(tǒng)測試階段。

　　系統(tǒng)測試范圍依據(jù)項目不同可分為功能和非功能測試。

1.2.3.1. 模式

　　依照Alpha1-到Alpha1n的模式。

　　提測版本1冒煙測試通過后即進入第一輪測試（記作Alpha1），執(zhí)行全用例。測試和開發(fā)，不斷提交和修復BUG，直至用例執(zhí)行完成；

　　開發(fā)修復完所有缺陷，打包發(fā)布版本2；

　　提測版本2冒煙測試通過后即進入第二輪測試（記做Alpha2），驗證缺陷，執(zhí)行部分用例。測試和開發(fā)，不斷提交和修復BUG，直至用例執(zhí)行完成；

　　開發(fā)修復完所有缺陷，打包發(fā)布版本3；

　　提測版本3冒煙測試通過后即進入第三輪測試（記做Alpha3），驗證缺陷，執(zhí)行部分用例。測試和開發(fā)，不斷提交和修復BUG，直至用例執(zhí)行完成；

　　……

　　如此，循環(huán)往復，直至缺陷收斂，達到測試退出標準，系統(tǒng)測試完成。

　　出具系統(tǒng)測試報告。

1.2.3.2. 進入標準

　　1） 需求說明書規(guī)定的功能均已實現(xiàn)；

　　2） 主要流程可以走通。

　　3） 界面上的功能均已實現(xiàn)，符合設計文檔規(guī)定的功能。

　1.2.3.3. 暫停標準

　　1） 一級錯誤數(shù)大于1、二級錯誤數(shù)大于2；

　　2） 軟件項目需暫停以進行調(diào)整時。

1.2.3.4. 退出標準

　　1） 按照測試計劃完成了系統(tǒng)測試；

　　2） 達到了測試計劃中關于系統(tǒng)測試所規(guī)定的覆蓋率要求；

　　3） 在系統(tǒng)測試中發(fā)現(xiàn)的錯誤已經(jīng)得到修改，各缺陷修復率達到要求。

1.3. 工作流程

1.3.1. 需求與變更

1.3.1.1. 需求定義

　　需求確定后以文檔和原型方式提供給測試方。應包含術語解釋，功能描述，精確的數(shù)據(jù)限制等等。

　　對開發(fā)和測試人員開展統(tǒng)一培訓。

　1.3.1.2. 基線

　　《產(chǎn)品需求文檔》確認、穩(wěn)定后，應建立基線，它是進一步開發(fā)、測試的基礎。當基線形成后，項目負責軟件配置管理的人需要通知相關人員基線已經(jīng)形成，并且哪兒可以找到這基線了的版本。這個過程可被認為內(nèi)部的發(fā)布。至于對外的正式發(fā)布，更是應當從基線了的版本中發(fā)布。

　　1.3.1.3. 變更管理

　　軟件工程過程中變更無法避免，這種變更必須嚴格加以控制和管理，保持修改信息，并把精確、清晰的信息傳遞到軟件工程過程的下一步驟。軟件變更管理包括建立控制點和建立報告與審查制度。

　　變更管理的主要任務包括：

　　1、 分析變更的必要性和合理性，確定是否實施變更；

　　2、 記錄變更信息，填寫變更控制單；

　　3、 修改相應的軟件配置項（基線），確立新的版本；

　　4、 評審后發(fā)布新版本。

　1.3.2. 項目提測

　　1.3.2.1. 提測時間

　　項目提測時間應安排在開發(fā)完成，已通過單元和集成測試之后。開發(fā)人員有時間，過一遍冒煙測試用例，以提高冒煙測試通過的成功率。

　1.3.2.2. 提測交付物

　　《單元測試報告》

　　《集成測試報告》

　　《測試環(huán)境搭建部署手冊》

　　“部署程序包”

　　“數(shù)據(jù)庫初始化腳本”

　1.3.2.3. 版本控制

　　1） 開發(fā)團隊制定并遵循一定的軟件系統(tǒng)版本命名格式，例如：

　　“軟件系統(tǒng)的版本號由3部分構成，即主版本號+次版本號+修改號。主版本號1位，只有當系統(tǒng)在結構和功能上有重大突破改進后才發(fā)生變化；次版本號有2位；修改號8位，采用提交時的日期，當系統(tǒng)進行任何修改后，包括數(shù)據(jù)庫結構發(fā)生變化，修改號都要隨之改變。例如：Ver3.31.19990317”；

　　2） 各子系統(tǒng)的版本號獨立；

　　3）軟件系統(tǒng)，產(chǎn)生新的版本后，老版本的軟件系統(tǒng)是否繼續(xù)保存，取決于以下條件：

　　a、老版本的系統(tǒng)如果有客戶還在使用，在客戶升級以前，必須繼續(xù)保存。

　　b、老版本的系統(tǒng)已經(jīng)沒有客戶使用了，并且新版本的系統(tǒng)已經(jīng)把老系統(tǒng)的文檔完整地升級過來，這樣可以刪除或覆蓋老版本的系統(tǒng)資源。

　　c、對于要刪除或覆蓋的老版本系統(tǒng)，可以統(tǒng)一備份起來。

　1.3.2.4. 提測間隔

　　項目第一次提測后，后續(xù)提測應該安排在軟件測試工作一輪完成后，并且已盡力修復完大部分缺陷之后。

　　在系統(tǒng)測試期間嚴重杜絕一個版本只為了修復一個缺陷。

　1.3.2.5. 測試環(huán)境

　　1.3.2.5.1. 環(huán)境分類

　　為了保證工作質(zhì)量、優(yōu)化工作流程，軟件環(huán)境最少應該有以下三套：

　　開發(fā)環(huán)境：開發(fā)部門開發(fā)、調(diào)試、集成軟件使用。

　　系統(tǒng)測試環(huán)境：測試部門系統(tǒng)測試使用。

　　生產(chǎn)環(huán)境：用戶使用，運維部門管理。

　　為了進一步提高用戶體驗、提高缺陷修復效率，根據(jù)條件也可以增設以下兩套環(huán)境：

　　Beta環(huán)境：系統(tǒng)測試通過后，Beta測試使用，運維部門管理。

　　線上鏡像環(huán)境：緊急復現(xiàn)、調(diào)試、解決線上問題。

　1.3.2.5.2. 環(huán)境管理

　　分權

　　生產(chǎn)環(huán)境對開發(fā)和測試只開放查詢權限。（需要修改權限時需要經(jīng)過一定的機制來控制記錄，一般只在調(diào)試程序時開放修改權限）；

　　測試環(huán)境對開發(fā)開放查詢權限。（需要修改權限時要經(jīng)過確認， 一般只在調(diào)試程序時開放修改權限）；

　　開發(fā)環(huán)境對測試人員只開放查詢權限；

　　以上三個環(huán)境，都由專人負責升級、維護。

　　定期比對

　　取生產(chǎn)環(huán)境數(shù)據(jù)庫作為標準，對比測試環(huán)境。

　　提取差異部分（表結構、過程、觸發(fā)器等）進行分析。若差異部分不是計劃內(nèi)的升級版本所致，則應該刪除。這樣在下一個計劃版本升版后，下下個計劃版本沒有在測試環(huán)境上升版前，測試環(huán)境和生產(chǎn)環(huán)境就實現(xiàn)了結構上的一致了。

　　開發(fā)環(huán)境，同樣與生產(chǎn)環(huán)境對比，差異部分先去除最近一次要發(fā)布生產(chǎn)的腳本影響，再將剩下的，在開發(fā)組內(nèi)部溝通確認，將沒有人負責的刪除。這樣，可得到相對統(tǒng)一的環(huán)境。

　　由于開發(fā)環(huán)境，一般只有一個，所以在多個版本并行開發(fā)過程中，數(shù)據(jù)庫管理是相對比較混亂的。在這種情況下，盡量保證測試環(huán)境與生產(chǎn)環(huán)境的數(shù)據(jù)庫結構的統(tǒng)一。對保證發(fā)布質(zhì)量有較大意義。

　1.3.2.6. 冒煙測試

　　冒煙測試出現(xiàn)的場景有兩個，一個是在內(nèi)部測試時；一個是在生產(chǎn)環(huán)境上線時。

　　冒煙測試通過驗證主要功能是否已經(jīng)實現(xiàn)，有利于粗略的驗證提測物是否具有可測性、上線部署后的系統(tǒng)有無重大問題。

1.3.3. 缺陷處理

　　1.3.3.1. 修復時間

　　缺陷處理應該有一定的時效性。

　　優(yōu)先級

　　說明

　　1-緊急

　　必須在一個工作日內(nèi)修復

　　2-較高

　　必須在三個工作日內(nèi)修復

　　3-一般

　　必須在五個工作日內(nèi)修復

　　4-不急

　　有時間再修復

1.4. 質(zhì)量保證

? ?　1.4.1. 評審

　1.4.1.1. 需求評審

　　對于產(chǎn)品需求的評估可以分為三個維度：

　　價值認同 - 對用戶有沒有價值，投入產(chǎn)出比怎樣；

　　需求質(zhì)量 - 需求是否易于理解，細節(jié)有沒有說清楚，邏輯是否成立；

　　技術可行性 - 能不能做，成本多大規(guī)模，有多大風險。

　1.4.1.2. 設計方案評審

　　由開發(fā)團隊自行組織，從流程上，必須要進行的。

1.4.1.3. 用例評審

　　參與方：產(chǎn)品、測試、開發(fā)和項目負責人；

　　目的：

　　1） 減少測試人員執(zhí)行階段做無效工作；

　　2） 避免三方的需求理解不一致；

　　3） 每個測試人員的質(zhì)量標準與項目要求標準達成一致。

1.4.2. 交叉測試

　　1、每一個測試人員有自己思維的局限性，一種思維測試過之后，軟件會對這種測試思維產(chǎn)生抗性，很難再發(fā)現(xiàn)新的問題，通過交叉測試，可以把新的測試思維帶進來，測試出未發(fā)現(xiàn)的bug。

　　2、防止測試人員工作粗心導致漏測。

　　2. 執(zhí)行監(jiān)督

　　首先達成共識，在共同監(jiān)督執(zhí)行的基礎上，并安排專人主持監(jiān)督工作。

　　3. 優(yōu)化改進

　　該文檔羅列，定義了一系列的軟件測試規(guī)范，主要目的還是為了保證項目進度、提高軟件質(zhì)量。在該方案執(zhí)行的過程中，我們本著簡潔、高效的原則，不斷優(yōu)化改進，以期拿出最適用藥聚匯的軟件測試工作規(guī)范。

　　3.1. 測試演進

　　3.2. 缺陷預防

　　1） 需求階段測試開始進入項目；

　　2） 進行單元測試-代碼靜態(tài)分析；

　　3） 持續(xù)集成-每日構建、自動反饋。