产品在迭代更新之际，每个迭代周期发布的时候，都会有个“验收”的过程，那么要如何做好这个验收环节呢？本文总结了相关思路以及问题处理的步骤，希望对你有所帮助。
产品的每个迭代周期发布之前，都会有一个“验收”环节，针对不同的产品管理/项目管理模式，产品验收的过程会略有差异。
但作为一个从“设计”到看见“实物”的时刻，仍然需要产品团队把好最后一关。
作为测试入行的我，这些年也经历了很多验收测试，如果团队真的能够重视验收测试，并将其标准化、规范化，能识别很多潜在风险，也能让原本80分的系统快速提升为90分。
所以，今天就来聊一聊我理解的产品验收测试。
从标准的项目管理过程来看，一个项目自立项开始，基本可以分为：需求阶段、设计阶段、开发阶段、测试阶段、上线及试运行阶段。
而测试阶段可以分为：单元测试（有些团队会归到开发阶段）、冒烟测试、SIT测试（系统集成测试）、UAT测试（用户/产品验收测试）。
自研类产品，验收测试一般会由产品团队主导，而项目制的产品，验收测试一般由甲方的业务方、需求提出方主导，或者由甲方委派第三方测试团队开展验收测试工作。
这里就会存在一个问题：验收测试人员，并非用户的实际使用者。这个问题下文再展开。
一个标准的测试管理流程中，每一个阶段都需要建立“准入”条件，否则一方面浪费测试人员的时间，另一方面也会降低上一阶段人员的执行标准。
比如为什么开发人员交付的功能，测试人员在正式开始测试时要进行冒烟测试？一个连主流程都有问题的功能，异常控制能做到什么程度呢？
因此，去年为了提升产品团队的验收效率，我也制定了一些准入标准，各位同行可以结合自身团队情况维护一套自己的“验收准入条件”。
上一个阶段大多是系统集成测试，测试完成后的测试报告将作为一个基础的条件。
而这份报告重点关注什么？或者说从测试完成到出具报告可能存在几天的延迟，这时我们就干等着吗？
其实我们需要的并非“报告”这个形式，而是其中的关键结果：测试通过率。并且关注一下未通过、遗留的缺陷是什么情况，是否会阻碍验收进度，影响用户的场景闭环。
当然，一个正常的团队，各个角色之间的沟通应该是很通畅的，大多数问题在准入前，测试和产品之间应该会有多次的讨论，只不过在真正要启动验收时，还需要重点关注一下。
在测试环境下，测试账号是一个非常重要，但又经常被大家忽略的问题。如果能有一个合适的测试账号，维护一套合理的测试数据，将会为测试阶段的提效带来质的改变。
因此，在正式开始验收测试之前，我们需要基于测试用例围绕的场景，提前准备好测试账号，并且最好能掌握一些基础的数据库操作，能够自己维护、设计测试账号，而不是每次找测试人员或开发人员。
时间久了，不仅会浪费对方的时间，也会让对方觉得你，很不专业。
一个新的测试阶段开始时，大多数系统都要清理测试数据，尽量让系统与刚上线时的状态一致。然而，想必很多人也体会过，数据清一次，系统崩一次。
所以关于测试数据的问题，需要协调技术负责人整理一份健壮的数据清理脚本，并在系统集成测试阶段经受住考验。
上一条提到，验收测试开始前需要设计好测试用例，准入条件满足之后即可开始验收。
而测试用例的准备及评审，可以放在项目设计阶段，或者集成测试中期。具体时间大家可以结合实际情况确定。
我的习惯是在需求评审阶段引入测试用例的宏观设计，设计评审阶段开始进行测试用例的编写，设计评审结束后，进行测试用例的评审（系统集成测试），集成测试用例评审结束后，进行验收用例的评审。
这样做的好处，一方面可以使后置阶段提前介入，从而保证业务由粗到细的顺序拆解。
另一方面也能够将“敏捷迭代”的管理思路融入各阶段协作过程中，以降低交接、单线程工作等待的资源消耗。
按照上述的思路，产品验收虽然是最后一个环节，但它的启动阶段可以前置到“设计阶段末期”或“开发阶段初期”，提前将验收的目标、用例、评审几个环节达成一致，等到正式进入验收测试后，直接做执行即可。
其实就是以敏捷的思维交叉协同。
验收阶段主要涉及三类角色：产品（业务）、测试、开发。
产品：是本阶段的主导人，负责具体执行、决策、协调、结果产出等相关事项。
当然在此过程大概率会涉及UI或UE方面的调整，根据公司的团队组成不同而略有差异，在此我将这些分工都纳入产品团队。
测试：协助产品维护测试环境和测试数据、定位问题、分析问题、协调开发资源等。
开发：负责缺陷修复工作，以及对复杂问题的分析、设计工作。
验收测试的目标与集成测试有很多区别，所以侧重点也有很多不同。
另外，基于参与验收测试的人员特性，在测试过程中看待问题的角度和决策方向都有较大差异。
本阶段的测试重点在核心业务流程和用户体验层面，对后台处理逻辑的合理性、性能等不会过度关注。
比如在页面上输入A，经过处理输出B，我们只需要确认A、B的结果没有问题即可。至于是A->C->D->E->B，还是A->F->B，大多数验收测试不会关注。后台的处理过程应该在设计阶段、集成测试阶段进行验证。
比如报表查询的等待时间是3秒还是3.5秒，对于业务人员也不会关注，只要不超过一定的“阈值”即可。而真正的性能测试、安全测试等，都有相应的测试阶段“专项攻克”。
所以本阶段最关键的内容，依然是核心业务流程，即主干+分支，或者是核心场景+辅助场景。
我们需要从用户的角度来评估，这些功能是否能够解决预期问题，是否能够为原有流程带来效率提升。
术业有专攻，如是而已。
另外，验收测试的重点是用户体验测试。这里包含了平台体验一致性、易用性、交互效率、合理性等，根据不同的产品类型，还包含创新性、趣味性等。
很多产品在前期并不重视用户体验，最终呈现了一个看似什么问题都能解决，但没有用户使用的“残次品”，很多问题也是出现在了验收测试阶段。
这里着重强调一个“用户思维”。无论是哪类人员进行验收测试，都要站在目标用户群体的画像上，试着以他们的角度、认知、习惯来审视当下的产品功能，而非利用自己的习惯进行评判。
举个不恰当的例子：假设这款产品是为视力较差且不戴眼镜的用户设计的，字体就要放大，布局就要稀松。而验收测试的人即便视力正常，也要遵循目标用户的操作习惯。
或者产品是为年轻女性提供的，验收人是中年男性，则更需要站在目标用户的习惯下审视这些功能。
而且，本身验收测试人员对互联网软件工程的理解比较浅，因此更要发挥自己的优势，以用户、场景、业务为导向，在此阶段中发现潜在的操作问题。
验收测试的结束，意味着产品达到上线标准。但达到上线标准并不代表没有缺陷，所以我认为验收测试的准出原则主要有以下几个：
（1）新一轮验收测试中，主流程+辅助流程的缺陷修复率达到100%；
（2）遗留缺陷在不影响系统正常运行前提下，多方达成一致确认可后续迭代优化；
（3）产品整体的视觉体验验证通过；
（4）对于升级类产品，对于原有功能的影响度测试完成；
最后，形成验收测试报告，将本次测试的结果写清楚。
我最初的想法，是让团队内的人员进行“交叉验收测试”，即张三负责的需求，验收测试由李四做；李四负责的需求，验收测试由王五做。
这样交叉验收的好处是：一方面组内同学都可以相互了解产品的业务全貌，避免形成思维壁垒；另一方面也是做了一层保障，让新同学测试，更容易找到用户视角。
但前提都要以团队内的资源情况和工程进度为基准，适度调整。
大部分缺陷，直接找到测试人员或开发人员进行验证、修复即可。
但有时会遇到不太好改的问题，或者随着时间推移导致政策变动、用户预期及偏好变动、市场变动等情况，让业务人员发现本版并不能满足业务要求。
此时，如何做决策？
每个团队的决策影响因素都不一样，在此我仅分享两个曾经使用的原则：
（1）少量极端场景下存在等级为高级的缺陷要进行需求变更
若需求变更程度小于10%且工作量在1周内的本版本解决，可以进行需求变更；若需求变更范围影响涉及比例超过原需求10%则延至下一版本，并确定延期交付的时间。
（2）经过产品评审会讨论，此功能不再验收（忽略）。
有些问题虽然存在，但为特殊场景下的低频偶发情况，经过评审会讨论后，将其忽略。
正常来讲，产品验收测试做两轮即可，如果遇到交付质量较高的版本，一次测试直接通过也可以。
但我也遇到过验收测试做了多轮的情况，大多是因为前期流程控制和交接的问题，在本阶段出现了需求变更、需求蔓延等，导致后续的过程异常艰难。
也有一些集成测试质量较差的，导致验收测试一直在关注细节。
其实每个测试阶段要进行几轮，并没有一个明确的规范，我们可以结合当下版本的大小、风险的高低、资源配置情况等，制定不同的要求。
但千万要注意，每当新一轮测试伊始，经常会出现一些稀奇古怪的问题，这些问题一定要引起团队的重视，因为在软件层面，任何一个问题的出现都不是偶然。
很多稀奇古怪的问题，恰恰反映了当下团队的项目过程管理体系的缺失。
今天的分享，基本框架是去年我在团队中构建的产品验收流程，然而随着我的离开，也没有机会验证此流程的效果，这不得不说是一种遗憾。
一份流程的建立不仅需要对现状和目标的考量，更需要牵头人的督导和推动，在面对多重阻碍时适度调整，最终经过几个周期的迭代，让各个角色都形成一种习惯。
而这个周期，大概率要以“季”或“年”为单位衡量，确实很难，但我相信一定有团队在做，或已经做出了成果。
最后总结一句：
产品团队要站好最后一班岗，既要为自己的设计方案负责，更要为自己的交付结果负责。
专栏作家
不想延期，公众号：不想延期，人人都是产品经理专栏作家。半路转行的B端泛金融产品，坚持“以实践验证理论，以输出倒逼成长”的目标。点滴珍贵，重在积累
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。