軟體測試流程是什麼？這題我不會啊
轉載請註明出處❤️
作者：測試蔡坨坨
原文鏈接：caituotuo.top/ae4fff18.html
你好，我是測試蔡坨坨。
最近收到不少準備轉行軟體測試的小夥伴私信問真實企業裡面軟體測試流程是什麼樣子的？
對於這個問題，在面試的時候也是經常會被問到。
關於測試流程，100家公司可能有100套測試流程，但是基本上都是大同小異，完全可以將測試流程形成一套可復用的SOP。
所以，今天我們就來聊聊軟體測試的流程。
測試流程
需求分析
產品經理根據用戶需求，梳理出需求文檔，文檔內容包括用戶背景、用戶需求、產品方案、需求原型、UI設計圖（UI設計師填寫）、技術方案（開發經理填寫）、介面文檔（開發人員填寫）等資訊。
我們需要提前閱讀相關文檔，深刻理解需求，對於有疑問的點提前進行標註，以便於在之後的需求評審會議上拋出疑問點。
閱讀需求文檔的時候，除了關注功能要求之外，還需要關注用戶背景，站在用戶的角度思考問題，以判斷需求是否真正符合用戶需求，避免交付到用戶手上時發現不是用戶想要的效果，還需要關注數據類型、介面定義、性能要求、安全性等，根據具體業務進行評估即可，同時還需要考慮一些隱性需求。
需求評審
產品經理給到需求文檔後，會召集一個需求評審會議，參加評審的一般有產品經理、開發人員、測試leader或對應需求的測試人員。
在需求評審時不僅要了解需求，還要評估需求的品質，分析需求的完整性以及合理性，及時發現需求和設計中的問題，拋出疑問給產品經理，並得到相應的解決。
思考需求中的測試點、測試場景等，便於之後測試用例的設計和編寫。
測試人員如何在需求評審中發揮價值，參考往期文章「需求評審，測試人員應該發揮怎樣的價值？兩分鐘讓你不再懵逼」
測試計劃
需求評審完成之後，大家都沒什麼問題了，測試Leader會給出測試計劃，測試計劃主要敘述了預定的測試活動範圍（哪些模組）、測試人員、測試資源（軟體、硬體）、進度安排（預計提測時間、測試用例所需工作日、一輪測試所需時間、二輪測試所需時間、預計測試完成時間）以及風險時間（提測品質低或其他因素引起測試時間增加）等。
測試用例設計
測試人員根據需求文檔和原型圖等進行測試用例的設計和編寫，用例格式有很多種，比如：Excel、XMind、Testlink等。有的要求完整的測試用例，有的只需要列出測試點即可，根據公司實際要求進行即可。
測試用例評審
測試用例編寫完成之後，會進行用例的評審，主要是檢查裡面有沒有什麼問題，或者跟需求文檔有誤的點，以及是否有未考慮到的測試點。
整個到這個階段，開發人員也差不多開發完成了。
開發自測
讓開發加強單元測試，測試人員通過提供測試用例或自動化測試腳本的方式給開發，讓開發在設計時考慮更全面，同時方便開發自測，有助於提高產品品質，避免在收到提測包時冒煙測試主流程都沒通過，導致測試效率低下。
開發自測其實是屬於測試左移的部分，關於什麼是測試左移可參考往期文章「測試左移和測試右移，我們為何要 「上下求索」？」。
提測
開發自測完成後正式提測，由開發人員將程式碼推到相應的Git分支。
測試環境部署
測試環境部署可能是運維人員、開發人員、或測試人員。
作業系統一般是Linux或Windows；用到的一些容器技術，例如：Docker、Kubernetes；資料庫可能是MySQL、SqlServer、Oracle、人大金倉資料庫、達夢資料庫、神通資料庫、Redis快取等，其中可能還有用到一些中間件，例如：Web中間件Nginx、消息隊列MQ、Kafka等。
不過現在很多公司都有一套持續集成和持續部署平台，只需開發人員將程式碼提交到相應的分支，就能觸發其自動部署更新。
冒煙測試
測試環境部署完成之後，需要先進行冒煙測試。
冒煙測試就是針對每次版本或每次需求變更之後，在正式測試之前，對產品或系統的一次簡單驗證性測試。驗證產品或系統的基本功能、主流程是否正常。可以將冒煙測試理解為是在執行正式測試之前的「預測試」，目的是確認軟體的基本功能正常，可以進行後續的測試工作。如果這個版本的冒煙測試都沒通過，後面就不用繼續測試了，直接打回給開發人員，待冒煙能通過後再提測。
需關注的點：
- 系統的基本功能可以正常使用，避免新功能導致系統原本功能無法使用
- 本次迭代需求的主流程可以跑通
前面開發自測是目的也是為了更快地通過冒煙測試，有了開發自測，提測的品質會大大提高，原本可能需要花費一天時間冒煙的功能很快就能通過。
執行測試
按照之前編寫的測試用例進行測試，測試過程中可能會發現之前遺漏的場景，這時需要補充完善測試點。還可能發現一些實際效果與產品原型不一致的地方，這時就需要跟開發、產品等人員進行溝通。
提交Bug並跟蹤
測試過程中發現軟體的缺陷，提交到相應的缺陷管理平台並指派給對應的開發人員，例如：Jira、禪道等。
對Bug進行跟進，若開發人員未及時修復，應適當催促，避免項目都要上線了，還有很多Bug未修復，影響交付，甚至延期。
待開發修復完Bug並提交新程式碼後，對Bug進行回歸驗證，若測試通過則將Bug關閉，若測試未通過則重新打開。
二輪測試、N輪測試
對新功能進行多輪測試。
回歸測試
對舊功能進行回歸測試，保證舊功能不被新功能影響而出現嚴重的Bug。
這個階段就可以用到自動化測試，實現快速回歸。
例如：結合公司業務實現一套覆蓋公司系統絕大部分介面的介面自動化測試框架，在上線前跑一遍，以便於測試人員第一時間發現問題，並提交給開發人員進行修復解決，減少線上Bug率；對於有些功能是在前端做校驗，無法通過介面進行回歸，又是主功能，就可以將其實現UI自動化。
介面自動化框架和UI自動化框架框架搭建可參考往期文章：
測試報告
輸出測試報告，測試報告內容包括測試範圍、測試人員、時間、功能、測試環境（服務端硬體環境、客戶端軟體環境）；測試過程評估，測試總體評估、用例統計、測試用例執行情況分析、測試對象品質評估；項目測試總結及建議。
產品經理驗收
產品經理對測試完成的軟體系統進行驗收。
項目上線
發布上線。
上線之後可能需要對線上環境進行跟蹤，屬於測試右移的內容，關於什麼是測試右移參考往期文章「測試左移和測試右移，我們為何要 「上下求索」？」。
以上，就是整個測試流程。
