我們公司的測試流程是這樣子的： 1. 我們的產品經理會提前1天把需求文件發下來，給我們看，熟悉熟悉。一般第二天會開一個需求澄清會議，要對需求的理解達成一致，以及弄清楚模組與模組之間的關聯，產品經理還會講解一下測試的重點。澄清會議之後，我們測試就會開個小會，主要是進行人員的分配和測試模組的初步分工。 2. 接下來就是編寫測試計劃，這個是我們經理寫的。我們測試人員，會根據經理分派的模組仔細研究和評估測試需要多少時間。然後會開一個測試計劃評審會議。主要是明確分工，確定時間進度安排，明確測試策略，測試風險分析。 3. 下一步就是需求分析。我們一般會用xmind羅列測試點。然後一般會開一到兩次評審，主要是為了集思廣益，確保更全面的羅列出測試點。 4. 然後就是寫測試用例。根據羅列的測試點，寫測試用例。一般都會有兩輪的測試用例評審。第一輪評審完，修改完成之後，還再做第二輪評審。有時候還要根據第二輪的情況，決定還做不做第三輪的評審。目的是為了查漏補缺，讓測試用例更好的覆蓋測試點。 5. 接下來，下一步就是執行測試用例了。當然，開發要給到我們一個UT（user test）報告，我們才會開始測試的。先做一個冒煙，把主體業務流程跑一遍，做個評估，沒問題的話，就開始執行測試用例：發現bug，提交bug，迴歸測試，以及寫測試報告。我們是用禪道這個工具來對bug進行管理的。對bug的管理也比較簡單。一般我們的bug是直接提交給開發的，他們修復完成之後，直接重新指派給我們，我們就做迴歸測試，通過的話就關閉，不通過就繼續修復。 6. 然後就是寫測試報告。我們測試人員，就是自己把自己的測試情況做總結。把留檔的證據截圖、自己模組的測試情況（發現了多少bug，修復了多bug，還有哪些沒修復的等等）發給經理，他會做一個彙總。等bug修復完成了，經理就會把報告出出來。 7. 產品上線：一般會在半夜一兩點的時候進行。因為這樣的話就不會對客戶的使用造成影響了。 8. 最後，我們會做一個測試總結。總結一下這個專案測試的情況，有沒有遇到什麼問題，下次應該如何避免，怎麼解決等等。