产品验收报告单模板

一、产品验收定义

产品验收就是对产品进行检验，看开发出来的产品与设计、需求是否存在偏差。产品验收的目标在于保证产品质量，达到设计预期。验收时不仅需要验收功能，同时需要考虑使用场景，进行可用性测试，把自己当做用户，看看产品在真实使用场景下能否跑通。

二、产品验收内容

对互联网产品而言，验收的内容需要包括以下方面：

1.功能验收：产品功能用例化后，用例执行是否符合预期设计，以及是否与客户需求吻合

2.交互验收：操作习惯是否符合大众，正向操作的用户体验是否良好

3.UI验收：设计和前端UI是否符合评审的标准

三、产品验收前期准备

一般公司通过UAT环境或Demo环境进行功能的验收，主要由产品设计或需求人员进行，当然，内部成员、相关领导都可以进行验收体验。

在验收过程中需要与一些文档进行比对，包括：

1.产品需求文档：用于验收过程中的功能比对。

2.产品原型：产品文档往往不够直观，具体的功能跳转，甚至简单的交互都可以对照原型进行验收。

3.设计图/前端UI规范

四、产品验收环境

产品验收和测试一样，是需要分阶段做的，一般验收需要在UAT环境中进行：

测试环境发现没问题了，就会发布到UAT环境，UAT环境的数据跟线上环境相同，所以在验收的时候需要按照规范进行测试验收，验收完成，没有问题，就可以移入到生产环境了。

产品的四种环境：

开发环境：开发环境是开发人员专门用于开发的服务器，配置可以比较随意，为了开发调试方便，一般打开全部错误报告。

测试环境：一般是克隆一份生产环境的配置，一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。

UAT环境：UserAcceptanceTest，用户接受度测试，即验收测试，所以UAT环境主要是用来作为用户体验的环境。介于测试环境和生产环境之间，本质还是测试环境。

生产环境：是指正式提供对外服务的，一般会关掉错误报告，打开错误日志。

五、产品验收过程

对照准备的材料，对每一个功能进行使用。不断点击，不断和系统交互，不能凭记忆或盲目的自信进行验收，毕竟即使是自己设计的功能也可能有细节会漏掉。

功能&交互验收

异常情况：虽然测试会测，但是我们验收时也需要注意异常情况，比如网络异常、输入异常等。

真实场景：验收把自己想象成小白用户，一秒变成“傻子”，千万不要基于任何对产品的了解而想当然。尽量模拟验证在初次使用产品时整个流程是否能合理跑通。最懂需求的我们可能觉得设计得很合理，但是小白用户可能并不知道如何使用，这时需要考虑增加使用帮助或使用引导。也可以找几个没有接触过该产品的同事用一下，看看有什么问题。

UI验收

适配问题：对app进行验收时，需要多找几个手机看看，检查每一个页面的适配问题。对网页进行验收时，由于开发、测试、设计一般都用大屏，需要在小屏幕笔记本上看一下是否存在适配问题，窗口拉大缩小看看UI是否存在问题。

经过几个版本的验收，可以积累一些经验和规律了，把验收时经常遇到的问题汇总起来，建立一份验收自检清单，比如：

1.列表：数据产生的时间，排序规则，检索条件，不同状态对应的操作等；

2.筛选条件：默认值是什么；

3.字段显示问题：文本域的文字过长，录入和显示时是否会有问题等；

六、产品验收报告

每轮产品验收完成后整理一份验收报告，同步给测试和研发，验收报告中需要注明：

基本信息：项目名称、版本号、验收人员、验收时间、设备、系统版本……

功能所属模块：比较大的模块，方便定位，比如是首页还是个人中心；

功能名称：具体是哪个功能，功能名称是什么；

问题描述：具体描述问题是什么，可以附上截图；

时间：发现问题的时间需要注明；

优先级：项目或产品开发的进度是需要把控的，因此当某个版本有问题时也不一定会立即进行修复和改进。产品人员在验收时将问题的优先级排出来之后，有利于开发进行工作安排。重要紧急的问题本期必须修改，不太重要时间又比较紧张可以放在后续的迭代中修改，细节问题比如UI上的一些问题可在整个项目开发完成后再做改进更新。

处理情况：回归的时候可以标记一下处理情况。

一般的项目管理软件都会有专门记录改进任务或Bug的方式，因此不必一定按照文档的形式出这份验收报告，还是要结合对应公司或团队的工作习惯。

没有什么规则是一成不变的，符合自己的，才是最好的。