工作以來，大大小小參與的專案也有十幾個了，涵蓋財務類、保險類、oa辦公類軟體。
從測試流程上看，基本也都大同小異，這裡將常見的測試流程做一些梳理，
產品、開發、測試、需求提出人、其它相關人員
對需求文件進行評審，對於有疑問或者有錯誤的地方，進行討論溝通，來保證對需求理解的準確性和一致性。
需求文件中最好有業務流程圖，能夠較好的幫助相關人員快速的了解業務需求。
通過此次會議了解到各模組對應開發人員，以此來確定測試時間
需求評審通過後，測試根據定版的需求或ue構造測試腦圖。
通過腦圖列出測試點以及測試方法，然後再根據腦圖整理測試方案。
xmind、mindmanager等
測試環境，測試資料，測試模組，測試點，測試方法，測試風險等
這個環節，輸出測試點和測試方案，指導接下來的測試工作。
測試任務緊急來不及寫用例的情況下，一定要列測試點並進行review。
避免無序測試，思路混亂，丟三拉四。
根據開發計畫制定測試計畫
測試範圍、測試目標、測試出入口、通過標準、測試人力安排（角色及職責）、測試進度安排
（用例設計評審開始結束時間、用例執行開始及結束時間、回歸測試時間計畫、測試交付時間等）、測試交付物、測試風險。
輸出測試計畫
測試工作最重要的環節就是設計產出測試用例，一定要嚴謹專業。
用例的可讀性要強，不僅僅是寫給自己看的，要做到任何人拿起來都可以執行。
用例設計完以後，要開展用例評審，查漏補缺，不斷完善用例；也可以採取用例結對編寫的方式，提高用例設計質量。
編寫人、用例編號、用例名稱、前提條件、測試資料、優先順序、操作步驟、預期結果、實際結果、測試人等
ui測試、許可權測試、功能測試、資料測試、流程測試（包括正常流程與異常流程）、介面測試、相容性測試、效能測試、安全測試等
一般邊界值和等價類常用，其次場景法、因果圖、錯誤推測。
針對不同的需求，測試點的選擇或側重點可能不一樣。
通過用例設計、評審，輸出較為完備的測試用例。
開發提測後，正式測試前，先驗證一下主流程或主要實現功能是否存在問題。
沒有問題後再進行系統的測試，避免測試相關工作已經準備開展，而核心業務卻執行不下去的情況。
冒煙測試結束後，按照測試計畫開展測試。
這個階段也可採取交叉測試的方法，即：a寫的用例b執行，b寫的用例c執行。
過程中如遇到不可控因素或問題，影響到測試計畫落地的，一定要盡早報備。
根據測試需求的具體情況，發布測試**（一般郵件形式較多，也有在看板或需求平台上備註的）。
用例總數、執行用例數、未通過數、發現bug的數量、關閉bug的數量、遺留bug的數量、問題等級、影響程度、bug趨勢以及其它建議等。
相關產品、開發、測試或需求人員。
在整個需求或版本測試完成後的總結。
主要反應測試過程中的問題以及對應版本的質量情況，是否滿足發布標準、遺留的問題的情況、是否影響相關使用、特殊的注意事項等。
之前寫過一篇如何進行版本總結的文章，可以參考【如何編寫測試總結】
分享 軟體測試流程
一 測試主要的四個階段 1.測試計畫設計階段 產品立項之後，進行需求分析，需求評審，業務需求評級，繪製業務流程圖。確定測試負責人，開始制定測試計畫 2.測試準備階段 各成員編寫測試用例 先小組內評審 後會議評審，測試樣機和配件，測試工具。3.測試執行階段 負責人對測試任務分工，按計畫執行測試過程，提...
常見的軟體測試流程
2020 6 22 地點 杭州 天氣 陰 1 需求評審 主要內容 對本批需求進行評審，通過溝通和提問明確需求內容，修改有錯誤的地方，保證產品 開發 測試及其他相關人員對需求理解的準備性和一致性。測試目的 明確需求內容以及各模組對應開發人員，以此評估確定測試時間。2 制定測試計畫 一般是測試組的組長 ...
測試經驗分享
測試經驗分享 做測試快兩年半的時間了，在測試過程中接觸到了不少的事情，總結下自己測試工作中的一些經驗吧 1 充分理解需求，找出需求缺陷。測試人員拿到需求 設計文件後，應積極地與需求 設計人員進行溝通確認，並及時地提出自己對相關文件的疑問，這樣做的好處一方面在於幫助測試人員充分理解需求，以保證設計全面...