一、需求
1、需求評審
為什么要需求評審？原因有下面幾點：
①、熟悉業務，由產品或者業務講解需求，好做到心中有數，不至於到開發測試階段暴露出由於業務不熟悉導致的問題；
②、多方協定，在正式進入開發階段之前，測試、開發、產品就某些需求的不確定點進行確認，達成一致，避免后續的問題；
③、評估工作量，實現難度，以及大概的資源投入；
④、明確開發測試邊界、目標和范圍，做什么不做什么；
2、需求文檔
①、盡可能的詳細，需要從需求中提取相應的功能點和測試點；
②、功能點和測試點選取適當的粒度，這樣可以較容易的觀察到測試結果和需求的偏離度；
③、一般來說，系統越大，業務越復雜，需求的偏離度判定比小系統更容易些；
二、系統架構
除了需求，了解熟悉整個系統的技術架構，也是必須的一點。比如整個系統的架構組成，各自的特點，采用了什么通信服務框架，數據庫類型，前后端框架等等，這樣可以更方便定位缺陷，
以及根據系統架構選擇合適的自動化測試框架、性能測試策略等。
特征：一般來說，系統的穩定性越好，那么它的可適應性就越差，其帶來的影響是每次架構變更的成本上升以及開發團隊重新建設抑或測試團隊整體方向上的變化。
這幾年開始流行和大規模應用的分布式架構、微服務等，都是從系統的可用性和伸縮擴展性來考慮，以降低各方面的變更帶來的成本。
三、流程管理
測試過程結果的記錄應該在一定程度上取決於流程的記錄完整程度。
如果涉及到流程更改，也應對不同的觀察對象（測試/開發）所產生的效果和結果進行記錄，以判斷其對質量的影響以及評估標准。
測試流程如下：
①、啟動階段
開發經理在開發計划中確定測試提交時間，測試主管得到當前最新的相關文檔資料后進行規模預估並成立測試小組，完成《測試計划》；
②、設計階段
包含測試計划、測試方案、測試用例等輸出文檔；
在需求分析文檔確立基線以后，測試組需要針對測試需求編寫測試用例，在實際的測試中，測試用例將是唯一實施標准。在用例的編寫過程中，具體的任務和責任人如下：
③、實施階段
執行測試用例將花費測試組絕大部分時間，這些工作都是建立在前期很多計划工作的基礎之上；
④、報告階段
在當天（或每個小的階段）的測試完成之后，測試工程師需要總結當天測試的結果，報告測試進度；
⑤、總結階段
在測試結束之后，測試主管編寫測試報告，對測試進行總結，並且提交，為產品的后續工作提供重要的信息支持；
⑥、驗收階段
在以上工作全部結束后，對測試的過程，結果進行驗收，宣布測試階段性結束；
⑦、歸檔階段
測試歸檔是在測試驗收結束宣布測試有效，結束測試后，對測試過程中涉及到各種標准文檔進行歸檔；
四、文檔管理
文檔對工作的幫助，是很有必要的。雖然現在很多企業提倡敏捷，但敏捷並非沒有文檔，而是輕文檔。文檔的重要性有如下幾個方面：
1、對歷史以及當前測試過程中的知識傳遞有很大幫助；
2、可以通過對比歷史和當前文檔的變更，較容易的觀察到整個需求變更過程中測試的質量；
3、涉及到人員變更或者缺陷的爭論時，有更快的知識傳遞速率和參考依據；
五、風險管理
項目的每個階段都存在風險，常見的缺陷有下面幾點：
1、需求不明確；
2、系統設計或測試設計不完善；
3、不安全規范的代碼編寫方式；
4、測試用例不充足，覆蓋率較低；
5、測試資源不足，回歸工作量預估不當；
7、項目進度安排不妥，其他項目對本項目的影響；
因此，風險管理和防范是必要且重要的一項工作，且測試工程師的職責，不就是提供交付軟件的質量么！！！
六、時間管理
有一定測試經驗的工程師基本都經歷過資源投入不足，時間不足的問題，測試時間被壓縮，導致的加班甚至生產事故！因此做好時間管理，就顯得如此重要。
會管理時間的人往往離成功更近一步，如何合理的利用時間解決緊急的項目問題、沖突問題、資源安排問題、優先級、測試用例的執行順序等，做好時間管理是保證質量的因素之一。
比如涉及到新增需求or需求變更都必須要有相應的文檔（可以為需求說明書或郵件說明）作為測試的依據；
這里推薦兩本書：《番茄工作法》、《高效能人士的七個習慣》
轉載：https://www.cnblogs.com/imyalost/default.html