為了規範測試工作、減少開發與測試之前的溝通成本、保證專案進度、提高軟體質量，測試組起草了這份軟體測試工作規範。
軟體程式開發需要遵守編碼規範，一是可以減少**的維護成本，提高開發工作效率；二是有利於開發工作的延續、傳承，減小專案風險。
好的**應該是自描述的，讓人費解的地方加上注釋。
規範很多，要讓別人和乙個月的自己看得懂。詞窮的話參考codelf:
單元測試一定要做。深入理解「 test driven development」思想，有條件的話，先寫測試**，後寫開發**。綜合使用各種覆蓋方法，例如：路徑、函式、條件、語句，code coverage確保高於80%。
統一提供單元測試報告。
整合測試也一定要做。測試工作要覆蓋所有模組和介面。
統一提供整合測試報告。
單元和整合通過後，專案提測並進入系統測試階段。
系統測試範圍依據專案不同可分為功能和非功能測試。
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.1. 需求定義
需求確定後以文件和原型方式提供給測試方。應包含術語解釋，功能描述，精確的資料限制等等。
對開發和測試人員開展統一培訓。
1.3.1.2. 基線
《產品需求文件》確認、穩定後，應建立基線，它是進一步開發、測試的基礎。當基線形成後，專案負責軟體配置管理的人需要通知相關人員基線已經形成，並且哪兒可以找到這基線了的版本。這個過程可被認為內部的發布。至於對外的正式發布，更是應當從基線了的版本中發布。
1.3.1.3. 變更管理
軟體工程過程中變更無法避免，這種變更必須嚴格加以控制和管理，保持修改資訊，並把精確、清晰的資訊傳遞到軟體工程過程的下一步驟。軟體變更管理包括建立控制點和建立報告與審查制度。
變更管理的主要任務包括：
1、 分析變更的必要性和合理性，確定是否實施變更；
2、 記錄變更資訊，填寫變更控制單；
3、 修改相應的軟體配置項（基線），確立新的版本；
4、 評審後發布新版本。
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. 修復時間
缺陷處理應該有一定的時效性。
優先順序
說明
1-緊急
必須在乙個工作日內修復
2-較高
必須在三個工作日內修復
3-一般
必須在五個工作日內修復
4-不急
有時間再修復
1.4.1.1. 需求評審
對於產品需求的評估可以分為三個維度：
價值認同- 對使用者有沒有價值，投入產出比怎樣；
需求質量- 需求是否易於理解，細節有沒有說清楚，邏輯是否成立；
技術可行性- 能不能做，成本多大規模，有多大風險。
1.4.1.2. 設計方案評審
由開發團隊自行組織，從流程上，必須要進行的。
1.4.1.3. 用例評審
參與方：產品、測試、開發和專案負責人；
目的：
1） 減少測試人員執行階段做無效工作；
2） 避免三方的需求理解不一致；
3） 每個測試人員的質量標準與專案要求標準達成一致。
1、每乙個測試人員有自己思維的侷限性，一種思維測試過之後，軟體會對這種測試思維產生抗性，很難再發現新的問題，通過交叉測試，可以把新的測試思維帶進來，測試出未發現的bug。
2、防止測試人員工作粗心導致漏測。
首先達成共識，在共同監督執行的基礎上，並安排專人主持監督工作。
該文件羅列，定義了一系列的軟體測試規範，主要目的還是為了保證專案進度、提高軟體質量。在該方案執行的過程中，我們本著簡潔、高效的原則，不斷優化改進，以期拿出最適用藥聚匯的軟體測試工作規範。
1） 需求階段測試開始進入專案；
2） 進行單元測試-**靜態分析；
3） 持續整合-每日構建、自動反饋。
軟體測試工作體會
快過年了，畢業也有半年了。在公司從事了半年的軟體測試工作，總容易被說到對測試的理解高度還不夠，於是仔細地思考了目前工作的情況和收穫，做個紀念吧。現在在推進什麼？兩個字 敏捷！其實不止部門，整個公司的技術部都在推行敏捷！敏捷是什麼？概念有很多，我理解簡言之就是有效的人與人溝通勝過流程與文件，快速交付版...
軟體測試部門工作規範
該規範作為測試部各項工作的指導與部門成員工作的參照執行標準。確保測試工作流程的控制，明確軟體工程的各階段測試團隊應完成的工作。軟體測試部門工作規範 1 目的 規範專用測試組工作內容和工作流程，通過規範化的工作模式，提高專用測試組的整體工作效率。2 產品測試工作要求 2.1 測試工作流程 測試工作流程...
再談軟體測試 工作感悟
軟體測試，乙個即將要崛起的行業，卻也是乙個充滿著爭議性的行業。談到崛起，是因為我們發現，我們身邊的客戶開始越來越關注軟體的體驗性了，如果你的軟體還有功能問題，他們可就不那麼待見你了。同樣，在國內的公司也是越來越開始重視軟體測試，這幾年，測試的職位需求量越來越多了，各種外包 培訓機構，爭先恐後而至 說...