❶ 产品质量检验所依据的标准是如何界定的
品质检验的依据是：根据合同和有关检验标准规定或申请人的要求，对商品的使用价值所变现出来的各种特性，运用人的感官或化学、物理等各种手段进行测试、鉴别。
其目的就是判别、确定该商品的质量是否符合合同中规定的商品质量条件。品质检验包括外观品质和内在品质的检验。
外观品质检验，指对商品外观尺寸、造型、结构、款式、表面色彩、表面精度、软硬度、光泽度、新鲜度、成熟度、气味等的检验。内在品质检验，指对商品的化学组成、性质和等级等技术指标的检验。
范围：
品质检验的范围很广，大体上包括外观质量检验与内在质量检验两个方面：外观质量检验主要是对商品的外形、结构、花样、色泽、气味、触感、疵点、表面加工质量、表面缺陷等的检验；内在质量检验一般指有效成分的种类含量、有害物质的限量、商品的化学成分、物理性能、机械性能、工艺质量、使用效果等的检验。
同一种商品 根据不同的外形、尺寸、大小、造型、式样、定量、密度、包装类型等而有各种不同的规格。
❷ 产品验收
一、产品验收定义
产品验收就是对产品进行检验，看开发出来的产品与设计、需求是否存在偏差。产品验收的目标在于保证产品质量，达到设计预期。验敬桥老收时不仅需要验收功能，同时需要考虑使用场景，进行可用性测试，把自己当做用户，看看产品在真实使用场景下能否跑通。
二、产品验收内容
对互联网产品而言，验收的内容需要包括以下方面：
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的方式，因此不必一定按照文档的形式出这份验收报告，还是要结合对应公司或团队的工作习惯。
没有什么规则是一成不变的，符合自己的，才是最好的。