對產品的驗收主要是對產品數量的清點和對質量的查驗。產品的驗收條款必須寫清：.驗收標準。如果質量標準有國家標準、行業（部）標準、企業標準的，那麼就分別按國家標準、行業（部）標準、企業標準驗收；如果質量標準是供需方約定的，按約定的標準驗收。供方必須對產品的質基和包裝質量負責，提供據以驗收的必要的技術資料或實樣；如果質量標準是按樣品的，雙方要共同封存樣品，分別保管，按封存的樣品進行驗收。其他專案的驗收標準，則以合同為準。.驗收方式。要寫明是全面驗收還是抽樣驗收；是感官驗收，還是理化驗收、安裝執行後驗收、破壞性驗收等。如果是抽樣驗收，還要明確押樣的比例（如百分之幾、千分之幾、萬分之幾）和時間。.驗收期限。驗收一定要有時間限制，如果不及時驗收一旦發生質量缺陷，就難以區分責任。認定責任的一般原則為：在驗收期限內發生貨物質量、數量等問題，就由供方或承運方負責；驗收期限過後發現問題，則由需方自負。某些產品主管部門有驗收期限的，按規定執行。一般產品，如果是需方自提的則在提貨時當面點清，即時驗收；如果是供方送貨或代運，則到貨後10天內驗收完畢。當然，也可以在合同中明確規定驗收時間。有些產品需要安裝執行後才能發現質量缺陷的，則要確定安裝執行後多長時間作為驗收期限。此外，驗收期限不要籠統寫“貨到驗貨”，必須寫清具體日期。.驗收地點。必須在合同中寫明是在供方所在地。還是在需方的所在地或其他地方驗收。一般供方送貨，以需方所在地為驗收地；需方自提，則以供方所在地為驗收地。此外，在必要時，還要寫明產品由誰檢驗和複驗。

產品功能用例化後，用例執行符合預期與需求吻合，正向操作的使用者體驗良好設計和前端UI符合評審的標準第一層應該是測試人員應該重點關注的，但在小公司或創業公司，開發/產品本身就是測試，驗收幾乎等同於最後一次測試。但是無論是否有“測試工程師”這個崗位，產品需求的用例化都是十分必要的，即便通過了專門的測試，產品或領導在驗收時，潛意識也是在執行相關的用例；

第二層說的是普遍意義上的驗收，產品透過test平臺測試，部署到了DEMO平臺，由產品需求人員進行需求驗收，當然，內部成員、相關領導都可以進行驗收體驗。對DEMO的驗收，是“裝成使用者”後對產品的使用，通常是正向操作，同時除了邏輯和流程，驗收人員會更加關注使用者體驗；

關於前端UI的驗收，實際上是對“使用者體驗”的一部分標準化，而驗收的內容應該與“設計評審”透過的內容相吻合。如果沒有設計評審，那麼標準就是公說公有理了。為了避免這種情況，需要在需求和設計評審前，界定清楚一些基本的準則和規範，比如符合公司的VI體系、符合W3C頁面標準、符合XXX，最直觀的還是所見即所得的“需求設計互動頁面”

這個問題其實很好，好在專門提出了UI的驗收。本質上是因為開發對UI或者對前端、相容性等很容易忽略，因為這是個“簡單但很花時間”的活兒，做起來沒有成就感。當然，如果你們有一套自己的UI庫或前端框架，那麼能夠規避很多前端上的扯皮，但如果沒有，開發和前端至少需要50%的精力去搞頁面。提前考慮標準、儘量使用框架、讓程式碼公用並易於維護，這是前端和攻城師的硬功夫，否則就沉浸在無盡的BUG中，更不用說驗收了。