產品驗收
一、產品驗收定義
產品驗收就是對產品進行檢驗，看開發出來的產品與設計、需求是否存在偏差。產品驗收的目標在於保證產品質量，達到設計預期。驗收時不僅需要驗收功能，同時需要考慮使用場景，進行可用性測試，把自己當做使用者，看看產品在真實使用場景下能否跑通。
二、產品驗收內容
對網際網路產品而言，驗收的內容需要包括以下方面：
1.功能驗收：產品功能用例化後，用例執行是否符合預期設計，以及是否與客戶需求吻合
2.互動驗收：操作習慣是否符合大眾，正向操作的使用者體驗是否良好
3.UI 驗收：設計和前端UI是否符合評審的標準
三、產品驗收前期準備
一般公司通過UAT環境或Demo環境進行功能的驗收，主要由產品設計或需求人員進行，當然，內部成員、相關領導都可以進行驗收體驗。
在驗收過程中需要與一些文件進行比對，包括：
1.產品需求文件：用於驗收過程中的功能比對。
2.產品原型：產品文件往往不夠直觀，具體的功能跳轉，甚至簡單的互動都可以對照原型進行驗收。
3.設計圖/前端UI規範
四、產品驗收環境
產品驗收和測試一樣，是需要分階段做的，一般驗收需要在UAT環境中進行：
測試環境發現沒問題了，就會發布到UAT環境，UAT環境的資料跟線上環境相同，所以在驗收的時候需要按照規範進行測試驗收，驗收完成，沒有問題，就可以移入到生產環境了。
產品的四種環境：
開發環境：開發環境是開發人員專門用於開發的伺服器，配置可以比較隨意， 為了開發除錯方便，一般開啟全部錯誤報告。
測試環境：一般是克隆一份生產環境的配置，一個程式在測試環境工作不正常，那麼肯定不能把它釋出到生產機上。
UAT環境：User Acceptance Test，使用者接受度測試，即驗收測試，所以UAT環境主要是用來作為使用者體驗的環境。介於測試環境和生產環境之間，本質還是測試環境。
生產環境：是指正式提供對外服務的，一般會關掉錯誤報告，開啟錯誤日誌。
五、產品驗收過程
對照準備的材料，對每一個功能進行使用。不斷點選，不斷和系統互動，不能憑記憶或盲目的自信進行驗收，畢竟即使是自己設計的功能也可能有細節會漏掉。
功能&互動驗收
異常情況：雖然測試會測，但是我們驗收時也需要注意異常情況，比如網路異常、輸入異常等。
真實場景：驗收把自己想象成小白使用者，一秒變成“傻子”，千萬不要基於任何對產品的瞭解而想當然。儘量模擬驗證在初次使用產品時整個流程是否能合理跑通。最懂需求的我們可能覺得設計得很合理，但是小白使用者可能並不知道如何使用，這時需要考慮增加使用幫助或使用引導。也可以找幾個沒有接觸過該產品的同事用一下，看看有什麼問題。
UI驗收
適配問題：對app進行驗收時，需要多找幾個手機看看，檢查每一個頁面的適配問題。對網頁進行驗收時，由於開發、測試、設計一般都用大屏，需要在小螢幕筆記本上看一下是否存在適配問題，視窗拉大縮小看看UI是否存在問題。
經過幾個版本的驗收，可以積累一些經驗和規律了，把驗收時經常遇到的問題彙總起來，建立一份驗收自檢清單，比如：
1.列表：資料產生的時間，排序規則，檢索條件，不同狀態對應的操作等；
2.篩選條件：預設值是什麼；
3.欄位顯示問題：文字域的文字過長，錄入和顯示時是否會有問題等；
……
六、產品驗收報告
每輪產品驗收完成後整理一份驗收報告，同步給測試和研發，驗收報告中需要註明：
基本資訊：專案名稱、版本號、驗收人員、驗收時間、裝置、系統版本……
功能所屬模組：比較大的模組，方便定位，比如是首頁還是個人中心；
功能名稱：具體是哪個功能，功能名稱是什麼；
問題描述：具體描述問題是什麼，可以附上截圖；
時間：發現問題的時間需要註明；
優先順序：專案或產品開發的進度是需要把控的，因此當某個版本有問題時也不一定會立即進行修復和改進。產品人員在驗收時將問題的優先順序排出來之後，有利於開發進行工作安排。重要緊急的問題本期必須修改，不太重要時間又比較緊張可以放在後續的迭代中修改，細節問題比如UI上的一些問題可在整個專案開發完成後再做改進更新。
處理情況：迴歸的時候可以標記一下處理情況。
一般的專案管理軟體都會有專門記錄改進任務或Bug的方式，因此不必一定按照文件的形式出這份驗收報告，還是要結合對應公司或團隊的工作習慣。
沒有什麼規則是一成不變的，符合自己的，才是最好的。