小白必看：測試人有必要參考的軟體測試工作規範
為了規範測試工作、減少開發與測試之前的溝通成本、保證專案進度、提高軟體質量，測試人員有必要參考這份軟體測試工作規範。
1.1. 編碼規範
軟體程式開發需要遵守編碼規範，一是可以減少程式碼的維護成本，提高開發工作效率；二是有利於開發工作的延續、傳承，減小專案風險。
1.1.1. 合理的註釋量
好的程式碼應該是自描述的，讓人費解的地方加上註釋。
1.1.2. 規範的命名格式
規範很多，要讓別人和一個月的自己看得懂。
1.2. 測試與測試結果
1.2.1. 單元測試與報告
單元測試一定要做。深入理解“ test driven development”思想，有條件的話，先寫測試程式碼，後寫開發程式碼。綜合使用各種覆蓋方法，例如：路徑、函式、條件、語句，Code Coverage確保高於80%。
統一提供單元測試報告。
1.2.2. 整合測試與報告
整合測試也一定要做。測試工作要覆蓋所有模組和介面。
統一提供整合測試報告。
1.2.3. 系統測試
單元和整合通過後，專案提測並進入系統測試階段。
系統測試範圍依據專案不同可分為功能和非功能測試。
1.2.3.1. 模式
依照Alpha1-到Alpha1n的模式。
提測版本1冒煙測試通過後即進入第一輪測試（記做Alpha1），執行全用例。測試和開發，不斷提交和修復BUG，直至用例執行完成；
開發修復完所有缺陷，打包釋出版本2；
提測版本2冒煙測試通過後即進入第二輪測試（記做Alpha2），驗證缺陷，執行部分用例。測試和開發，不斷提交和修復BUG，直至用例執行完成；
開發修復完所有缺陷，打包釋出版本3；
提測版本3冒煙測試通過後即進入第三輪測試（記做Alpha3），驗證缺陷，執行部分用例。測試和開發，不斷提交和修復BUG，直至用例執行完成；
……
如此，迴圈往復，直至缺陷收斂，達到測試退出標準，系統測試完成。
出具系統測試報告。
1.2.3.2. 進入標準
1） 需求說明書規定的功能均已實現；
2） 主要流程可以走通。
3） 介面上的功能均已實現，符合設計文件規定的功能。
1.2.3.3. 暫停標準
1） 一級錯誤數大於1、二級錯誤數大於2；
2） 軟體專案需暫停以進行調整時。
1.2.3.4. 退出標準
1） 按照測試計劃完成了系統測試；
2） 達到了測試計劃中關於系統測試所規定的覆蓋率要求；
3） 在系統測試中發現的錯誤已經得到修改，各缺陷修復率達到要求。
1.3. 工作流程
1.3.1. 需求與變更
1.3.1.1. 需求定義
需求確定後以文件和原型方式提供給測試方。應包含術語解釋，功能描述，精確的資料限制等等。
對開發和測試人員開展統一培訓。
1.3.1.2. 基線
《產品需求文件》確認、穩定後，應建立基線，它是進一步開發、測試的基礎。當基線形成後，專案負責軟體配置管理的人需要通知相關人員基線已經形成，並且哪兒可以找到這基線了的版本。這個過程可被認為內部的釋出。至於對外的正式釋出，更是應當從基線了的版本中釋出。
1.3.1.3. 變更管理
軟體工程過程中變更無法避免，這種變更必須嚴格加以控制和管理，保持修改資訊，並把精確、清晰的資訊傳遞到軟體工程過程的下一步驟。軟體變更管理包括建立控制點和建立報告與審查制度。
變更管理的主要任務包括：
1、 分析變更的必要性和合理性，確定是否實施變更；
2、 記錄變更資訊，填寫變更控制單；
3、 修改相應的軟體配置項（基線），確立新的版本；
4、 評審後釋出新版本。
1.3.2. 專案提測
1.3.2.1. 提測時間
專案提測時間應安排在開發完成，已通過單元和整合測試之後。開發人員有時間，應過一遍冒煙測試用例，以提高冒煙測試通過的成功率。
1.3.2.2. 提測交付物
《單元測試報告》
《整合測試報告》
《測試環境搭建部署手冊》
“部署程式包”
“資料庫初始化指令碼”
1.3.2.3. 版本控制
1） 開發團隊制定並遵循一定的軟體系統版本命名格式，例如：
“軟體系統的版本號由3部分構成，即主版本號+次版本號+修改號。主版本號1位，只有當系統在結構和功能上有重大突破改進後才發生變化；次版本號有2位；修改號8位，採用提交時的日期，當系統進行任何修改後，包括資料庫結構發生變化，修改號都要隨之改變。例如：Ver3.31.19990317”；
2） 各子系統的版本號獨立；
3）軟體系統，產生新的版本後，老版本的軟體系統是否繼續儲存，取決於以下條件：
a、老版本的系統如果有客戶還在使用，在客戶升級以前，必須繼續儲存。
b、老版本的系統已經沒有客戶使用了，並且新版本的系統已經把老系統的文件完整地升級過來，這樣可以刪除或覆蓋老版本的系統資源。
c、對於要刪除或覆蓋的老版本系統，可以統一備份起來。
1.3.2.4. 提測間隔
專案第一次提測後，後續提測應該安排在軟體測試工作一輪完成後，並且已盡力修復完大部分缺陷之後。
在系統測試期間嚴重杜絕一個版本只為了修復一個缺陷。
1.3.2.5. 測試環境
1.3.2.5.1. 環境分類
為了保證工作質量、優化工作流程，軟體環境最少應該有以下三套：
開發環境：開發部門開發、除錯、整合軟體使用。
系統測試環境：測試部門系統測試使用。
生產環境：使用者使用，運維部門管理。
為了進一步提高使用者體驗、提高缺陷修復效率，根據條件也可以增設以下兩套環境：
Beta環境：系統測試通過後，Beta測試使用，運維部門管理。
線上映象環境：緊急復現、除錯、解決線上問題。
1.3.2.5.2. 環境管理
分權
生產環境對開發和測試只開放查詢許可權。（需要修改許可權時需要經過一定的機制來控制記錄，一般只在除錯程式時開放修改許可權）；
測試環境對開發只開放查詢許可權。（需要修改許可權時要經過確認， 一般只在除錯程式時開放修改許可權）；
開發環境對測試人員只開放查詢許可權；
以上三個環境，都由專人負責升級、維護。
定期比對
取生產環境資料庫作為標準，對比測試環境。
提取差異部分（表結構、過程、觸發器等）進行分析。若差異部分不是計劃內的升級版本所致，則應該刪除。這樣在下一個計劃版本升版後，下下個計劃版本沒有在測試環境上升版前，測試環境和生產環境就實現了結構上的一致了。
開發環境，同樣與生產環境對比，差異部分先去除最近一次要釋出生產的指令碼影響，再將剩下的，在開發組內部溝通確認，將沒有人負責的刪除。這樣，可得到相對統一的環境。
由於開發環境，一般只有一個，所以在多個版本並行開發過程中，資料庫管理是相對比較混亂的。在這種情況下，儘量保證測試環境與生產環境的資料庫結構的統一。對保證釋出質量有較大意義。
1.3.2.6. 冒煙測試
冒煙測試出現的場景有兩個，一個是在內部提測時；一個是在生產環境上線時。
冒煙測試通過驗證主要功能是否已經實現，有利於粗略的驗證提測物是否具有可測性、上線部署後的系統有無重大問題。
1.3.3. 缺陷處理
1.3.3.1. 修復時間
缺陷處理應該有一定的時效性。
優先順序
說明
1-緊急
必須在一個工作日內修復
2-較高
必須在三個工作日內修復
3-一般
必須在五個工作日內修復
4-不急
有時間再修復
1.4.1. 評審
1.4.1.1. 需求評審
對於產品需求的評估可以分為三個維度：
價值認同 - 對使用者有沒有價值，投入產出比怎樣；
需求質量 - 需求是否易於理解，細節有沒有說清楚，邏輯是否成立；
技術可行性 - 能不能做，成本多大規模，有多大風險。
1.4.1.2. 設計方案評審
由開發團隊自行組織，從流程上，必須要進行的。
1.4.1.3. 用例評審
參與方：產品、測試、開發和專案負責人；
目的：
1） 減少測試人員執行階段做無效工作；
2） 避免三方的需求理解不一致；
3） 每個測試人員的質量標準與專案要求標準達成一致。
1.4.2. 交叉測試 1.交叉測試
每一個測試人員有自己思維的侷限性，一種思維測試過之後，軟體會對這種測試思維產生抗性，很難再發現新的問題，通過交叉測試，可以把新的測試思維帶進來，測試出未發現的bug。防止測試人員工作粗心導致漏測。
2. 執行監督
首先達成共識，在共同監督執行的基礎上，並安排專人主持監督工作。
3. 優化改進
該文件羅列，定義了一系列的軟體測試規範，主要目的還是為了保證專案進度、提高軟體質量。在該方案執行的過程中，我們本著簡潔、高效的原則，不斷優化改進，以期拿出最適用藥聚匯的軟體測試工作規範。
3.1. 測試演進
3.2. 缺陷預防
1） 需求階段測試開始進入專案；
2） 進行單元測試-程式碼靜態分析；
3） 持續整合-每日構建、自動反饋。