1. 制定規則

為了規范測試工作、減少開發與測試之前的溝通成本、保證項目進度、提高軟件質量，測試組起草了這份軟件測試工作規范。

1.1. 編碼規范

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

1.1.1. 合理的注釋量

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

1.1.2. 規范的命名格式

規范很多，要讓別人和一個月的自己看得懂。詞窮的話參考CODELF:

http://unbug.github.io/codelf/#%E8%8D%AF%E8%81%9A%E6%B1%87

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.4.1. 評審

1.4.1.1. 需求評審

對于產品需求的評估可以分為三個維度：

價值認同 - 對用戶有沒有價值，投入產出比怎樣；

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

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

1.4.1.2. 設計方案評審

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

1.4.1.3. 用例評審

參與方：產品、測試、開發和項目負責人；

目的：

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

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

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

1.4.2. 交叉測試

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

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

2. 執行監督

首先達成共識，在共同監督執行的基礎上，并安排專人主持監督工作。

3. 優化改進

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

3.1. 測試演進

?

?

3.2. 缺陷預防

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

2） 進行單元測試-代碼靜態分析；

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

轉載于:https://www.cnblogs.com/seulki/p/9596708.html

總結

以上是生活随笔為你收集整理的软件测试工作规范的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。