❶ 產品質量檢驗所依據的標準是如何界定的
品質檢驗的依據是：根據合同和有關檢驗標准規定或申請人的要求，對商品的使用價值所變現出來的各種特性，運用人的感官或化學、物理等各種手段進行測試、鑒別。
其目的就是判別、確定該商品的質量是否符合合同中規定的商品質量條件。品質檢驗包括外觀品質和內在品質的檢驗。
外觀品質檢驗，指對商品外觀尺寸、造型、結構、款式、表面色彩、表面精度、軟硬度、光澤度、新鮮度、成熟度、氣味等的檢驗。內在品質檢驗，指對商品的化學組成、性質和等級等技術指標的檢驗。
范圍：
品質檢驗的范圍很廣，大體上包括外觀質量檢驗與內在質量檢驗兩個方面：外觀質量檢驗主要是對商品的外形、結構、花樣、色澤、氣味、觸感、疵點、表面加工質量、表面缺陷等的檢驗；內在質量檢驗一般指有效成分的種類含量、有害物質的限量、商品的化學成分、物理性能、機械性能、工藝質量、使用效果等的檢驗。
同一種商品 根據不同的外形、尺寸、大小、造型、式樣、定量、密度、包裝類型等而有各種不同的規格。
❷ 產品驗收
一、產品驗收定義
產品驗收就是對產品進行檢驗，看開發出來的產品與設計、需求是否存在偏差。產品驗收的目標在於保證產品質量，達到設計預期。驗敬橋老收時不僅需要驗收功能，同時需要考慮使用場景，進行可用性測試，把自己當做用戶，看看產品在真實使用場景下能否跑通。
二、產品驗收內容
對互聯網產品而言，驗收的內容需要包括以下方面：
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的方式，因此不必一定按照文檔的形式出這份驗收報告，還是要結合對應公司或團隊的工作習慣。
沒有什麼規則是一成不變的，符合自己的，才是最好的。