軟體測試learning——測試流程
關於測試流程的思考
瞭解測試流程意味著什麼
造飛機不造發動機
不考慮整體的流程而去盲目的測試，就等於是本應該通過了解飛機架構去造飛機，你卻一個勁埋頭在造發動機一樣。
讓測試價值最大化
一個專案中，要讓測試價值最大化，不是找幾個測試大牛，也不是引入好的測試技術就萬事大吉，而是四個字——滲透，流程。
測試技術在實際專案中的滲透和測試流程的優化和改進。
ps：從測試人員角度上說，就是將測試方法應用到實際專案中
市場上有許多公司，越來越多的公司引入測試過程去確保輸出後或服務或產品的質量。不同規模和性質的公司，其所需要和採用的測試流程各有不同，也各有優劣。
適合小團隊的簡單測試流程
對測試經理要求高。可以利用缺陷管理工具，如禪道，去管理bug狀態，但最好的狀態是測試與開發直接溝通。
優勢在於能快速發現問題並修復，但缺點也很多，最明顯的就是此時沒有需求文件，需求不明確，測試文件和用例都是可有可無的產物。
比較依賴測試人員的經驗，通過一些“通用型”用例，比如登入、檔案上傳下載、輸入框驗證、搜尋、列表翻頁、日期選擇等去鍛鍊自己測試功能的思路。
適合質量要求高的測試流程
屬於瀑布模型，將測試和QA分開。二者角色區別在於，測試主要關注功能實現，QA看重產品整體質量和流程的規範性。測試在這一流程中每一環節都有參與，測試的重要性較為突出。
但太過強化各種文件報告先輸出，真正留給測試的時間很短，但測試人員的價值就在測試環節
關於敏捷測試
瀑布模型中，人員責任的傳遞：產品需求分析完之後交給開發，產品完事兒；開發程式碼實現好之後交給測試，開發完事兒。但在敏捷測試流程中，每個階段各種人員都有任務安排，核心是迭代。
優點是弱化了文件，加強了各人員之間的溝通，加快了專案的完成時間。缺點是一旦有新需求加入，因為是迭代漸進過程，所以也不能再變，只能一步錯，步步錯。
對於敏捷測試，國外是比較流行的，國內真正採用的很少，但我們依舊需要伸出自己的觸角去了解。
只有站在一個整體的角度去看待測試，才能不被固有和區域性的思維侷限。