這是一篇從測試人員角度介紹對於整個專案流程理解，主要重點介紹需求評審階段至產品上線後維護階段。
在需求評審之前的階段，即產品設計階段，測試一般不參與，主要由產品經理基於市場調研及使用者需求，產出產品原型，後續由ui設計師輸出主要介面ui設計規範。
1、ui設計文件及需求互動文件
ui稿明確業務實現細節，消除對最終成果理解的不一致，需求互動文件概要設計功能實現的視覺化，有助於理清思路，減少技術盲區和低階缺陷，實現並行開發，提高效率研發工程師。測試人員最終驗收以ui稿及需求互動稿為準。
2、功能實現難點
需求文件列出要實現的功能，並不是所有的功能都可以實現，有些功能可能存在難點，需要前端、後台、技術主管共同討論實現方案及所需時間，確定該功能本期是否可以實現，或者下期實現
3、環境支援
開發編碼過程中，功能實現需要前後端聯調，確定雙方大致開發完成時間並聯調；除了粗腰後台支援外，可能還需要其他環境的支援，也一併確認環境是否可以提供，何時提供；
4、專案時間評估
需求評審完成，專案經理梳理各階段、各埠的開發計畫，任務分解表將分配到團隊研發，開發反饋開發時間
5、需求評審結果
需求評審後，需郵件通知所有人評審結果
在需求評審中，測試主要關注需要實現哪些功能，任務提測時間及上線時間，按照該計畫協調自己的任務安排
開發編碼和測試用例編寫同時進行,測試用例是根據需求文件編寫，完成後可進行測試用例評審。
1、參與人員
產品、ui設計師、開發、專案經理、測試人員
2、評審內容
3、測試用例評審結果反饋
1、環境確認及自測文件
提測之前，開發應確認環境是否可以正常測試後，並提供自測文件；自測文件包含兩部分：公升級說明，自測說明。
公升級說明記錄本次即將公升級內容，自測說明保證開發自測通過才提測，該自測文件後續測試完成後需備份儲存。
2、測試注意點
3、測試流程
1、生產包驗證
在上線之前，開發提供乙個生產包，驗證生產包需確認：
2、線上客戶端維護
關注客戶反饋問題，及時確認並反饋開發人員
開篇 從開發人員的角度理解產品經理
首先需要宣告的是，我只是乙個普通的開發人員，但是我希望自己的目標是成為乙個擁有暫時軟體工程功底的，能夠駕馭創新產品，引領團隊的產品經理。本文只是個人的一點隨想，以及閱讀他人著作的一些感悟，尚不成熟，僅在這裡做個記錄而已，牛人不要見笑。從我做研發的經歷來探索產品經理的特質 1 解決方案而不是功能模組。...
從開發人員角度看待效能基準測試
對乙個開發人員來說，除了保質保量按時完成功能需求外，非功能也不可忽視。決定乙個軟體的成敗往往是非功能性需求比如效能，若是使用者體驗不好那麼必定是個失敗的作品。那麼乙個開發人員如何去做關於自己模組又或者整體的基準效能測試呢？以下將從測試的切入點和具體測試的指標來說明。切入點 通常，基準效能測試有兩個切...
從招聘人員的角度看簡歷撰寫
這些年招人，每年看的簡歷不下千份。所謂 熟讀唐詩三百首，不會作詩也會吟 對怎麼評價簡歷有了些自己的看法，一家之言，僅供參考。在下筆之前首先要搞清楚，寫簡歷的目的是什麼？簡歷的目的是告訴招聘單位，你能夠適應他們的公司文化，勝任他們提供的職位。同時你必須認識到乙個負責招聘簡歷篩選的人，無論是專職的 hr...