小白必看：測試人有必要參考的軟件測試工做規範

小白必看：測試人有必要參考的軟件測試工做規範

       爲了規範測試工做、減小開發與測試以前的溝通成本、保證項目進度、提升軟件質量，測試人員有必要參考這份軟件測試工做規範。

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） 一級錯誤數大於一、二級錯誤數大於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.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.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） 持續集成-每日構建、自動反饋。