第一次做产品验收，该从何下手？文章分析了产品验收过程中所需的准备步骤及注意事项，一起来看看吧。

开发人员完成开发后，不仅需要测试同学对产品进行测试，产品经理也需要对其进行验收。开发完的产品不可避免的会与产品定义出现偏差，因为程序员爸爸们有的时候不会特别仔细的看文档，或者会偷偷的改需求，或者失恋了很伤心代码随便写写算了，这个时候验收工作就显得尤为重要了。

一、产品验收是什么

那么产品验收到底是啥？产品验收就是对产品进行检验，看产品与需求是否存在偏差。对着你的产品点点点，发现它的问题，然后提给测试或者直接提给开发人员，让他们改改改，这就是全部了。

产品验收的目标在于保证产品质量，达到设计预期。

跟测试不同的是，我们在验收时不仅需要验收产品功能，同时需要考虑使用场景，把自己当成用户，看看产品在真实的使用场景下能否跑通。所以，产品验收有时不仅会涉及到bug修改，有时可能需要进行需求调整。

二、产品验收怎么做

验收前期准备

验收前期准备包括：

• 需求清单：需求清单一般在产品文档中都有写，如果没有，可以对照原型自己列一个。
• 产品原型：产品清单往往不够详细，具体的功能可以对照原型进行验收。
• 测试用例：如果有测试用例，那就最棒棒哒，如果没有的话，可以自己列一个。

注意，如果不是自己的需求，首先需要把需求搞懂再进行验收。如果对需求一知半解，验收时往往不能发现问题，或者本来不是问题自己却当成了问题。

在进行产品验收之前或者产品验收的同时，可以找设计同学进行UI验收，检查最终的产品与设计图是否相符合。

验收环境

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

• 测试环境：开发完成后会提测到测试环境，测试环境中的数据都是可以随意瞎编的，在测试同学测得差不多的时候，产品经理就可以介入验收了。测得差不多的标准就是：所剩的bug优先级不高，对产品功能没有大的影响。有时可能因为信息不对称，产品经理会在发布到预发布时再进行验收，但是在预发布发现需要需求修改或者发现比较严重的问题时再让开发修改就会比较紧张。所以及时关注测试报告和JIRA，及时跟进测试进度是非常必要的。
• 预发布环境（预上线环境）：测试环境发现没问题了，就会发布到预发布环境，预发布环境的数据跟线上环境相同，所以在验收的时候要注意按照规范进行测试验收，不要把数据库搞得乱七八糟。有些问题在测试环境中发现不了，在预发布环境进行验收和回归是很有必要的，验收完成，没有问题，就可以申请上线了。
• 生产环境（线上环境）：产品上线后需要进行最后一轮验收，如果发到线上发现比较严重的问题就需要回滚或者hotfix，可怜，摸头，祝好。

验收的过程

需要我们对照我们准备的材料，对每一个功能进行使用。不断点击，不断和系统交互，至少要对照需求清单、原型和测试用例过个两遍，千万不能凭记忆，即使自己设计的也可能有细节会漏掉；

如果有些功能没有办法测试或者不懂怎么测试，比如埋点或者需要调用接口的功能，可以搬着小凳子去测试同学那里看他们测试，了解测试结果，如果有什么情况他们没有考虑到，需要随时指出来并进行确认。

三、需要注意的点

UI验收

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

功能验收

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

真实场景：验收把自己想象成小白用户，在真实场景下整个流程是否能跑通。最懂需求的我们可能觉得设计得很合理，但是小白用户可能并不知道如何使用，这时需要考虑增加使用帮助或使用引导。也可以找几个没有接触过该产品的同事用一下，看看有什么问题。

另外，我们可以把自己验收时经常遇到的问题汇总起来，建立自己的验收checklist，比如我的checklist中记录有：

1. 有列表的时候就需要排序，排序规则；
2. 文本框考虑空格；
3. 选择：全选、全不选、单选、多选；
4. 当有跨页选择或显示时需要考虑跨页；
5. 数据异常：数据过长，数据为空时的展示；

…….

balabala巴啦啦小魔仙咒语一呼喊就开展正义的一战~

…….

四、产品验收报告怎么写

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

• 基本信息：项目名称、版本号、验收人员、验收时间、设备、系统版本……
• 优先级：不管是ABCD还是高中低，优先级都是必须要注明的，重要紧急的问题本期必须修改，而问题不太重要时间又比较紧张可以放在后续的迭代中修改；
• 功能所属部分：是服务端还是客户端；
• 功能所属模块：比较大的模块，方便定位，比如是首页还是个人中心；
• 功能名称：具体是哪个功能，功能名称是什么；
• 问题描述：具体描述问题是什么，可以附上截图；
• 时间：发现问题的时间需要注明；
• 处理情况：回归的时候可以标记一下处理情况。

本文由 @Alex是谁 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash ，基于 CC0 协议