产品在迭代更新之际，每个迭代周期发布的时候，都会有个“验收”的过程，那么要如何㊣做好这个验收环节呢？本文总结了相关思路以及问题处理的步骤，希望对你有所帮助。

　　产品的每个迭代周期发布之前，都会有㊣一个“验收”环节，针对不同的产品管理/项目管理㊣模式，产品验收的过程会略有差异。

　　作为测试入行的我，这些年也经历㊣了很多验收测试，如果团队真的能够重视验收测试，并将其标准✅化□□、规范化，能识别很多潜在风险，也能让原本80分的系统快速提升为90分。

　　从标准的项目管理过程来看，一个项目自立项开始，基本可以分为：需求阶段□□、设计阶段□□、开发阶段□□□□、测试阶段□□、上线及试运行阶段。

　　而测试阶段可以分为：单元测试（有些团队会归到开发阶段）□□□□、冒烟测试□□、SIT测㊣试（系统集成测试）□□、UAT测试（用户/产品验收测试）。

　　自研类产品，验收测试一般会由产品团队主导，而项目制的产品，验收测试一般由甲方的业务方□□、需求提出方主导，或者由甲方委派第三方测试团队开展验收测试工作。

　　一个标准的测试管理流程中，每一个阶段都需要建立“准入”条件，否则一方面浪费测试人员的时间，另一方面也会降低上一阶段人员的执行标准。

　　比如为什么开发人员交㊣付的功能，测试人员在正式开始测试时要进行冒烟测试？一个连主流程都有问题的功能，异常控制能做到什么程度呢？

　　因此，去年为了提升产品团队的验收效率，我也制定了一些准入标准，各位同行可以结合自身㊣团队情况维护一套自己的“验收准入条件”。

　　其实我们需要的并非“报告”这个形式，而是其中的关键结果：测试通过率。并且关注一下未通过□□□□、遗留的缺陷是什么情况，是否会阻碍验收进度，影响用户的场景闭环。

　　当然，一个正常的团队，各个角色之间的沟通应该是很通畅的，大多数问题在准入前，测试和产品之间应该会有多次的讨论，只不过在真正要启动验收时，还需要重点关注一下。

　　在测试环境下，测试账号是一个非常重要，但又经常被大家忽略的问题。如果能有一个合适的测试账号，维护一套合理的测试数据，将会为测试阶段的提效带来质的改变。

　　因此，在正式开始验收测试之前，我们需要基于测试用例围绕的场景，提前准备好测试账号，并且最好能掌握一些基础的数据库操作，能够自己维护□□、设计测试账号，而不是每次找测试人员或开✅发人员。

　　一个新的测试阶段开始时，大多数系统都要清理测试数据，尽量让系统与刚上线时的状态一致。然而，想必很多人也㊣体㊣会过，数据清一次，系统崩一次。

　　所以关于测试数据的问题，需要协调技术负责人整理一份健壮的数据清理脚本，并在系统集成测试阶段经受住考验。

　　而测试用例的准备及评审，可以放在项目设计阶段，或者集成测试中期。具体时间大家可以结合实际情况确定。

　　我的习惯是在需求评审阶段引入测试用例的宏观设计，设计评审阶段开始进行测试用例的编写，设计评审结束后，进行测试用例的评审（系统集成测试），集成测试用例评审结束后，进行验收用例的评审。

　　另一方面也能够将“敏捷迭代”的管理思路融入各阶✅段协作过程中，以降低交接□□□□、单线程工作等待的资源消耗。

　　按照上述的思路，产品验收虽然是最后一个环节，但它的启动阶段可以前置到“设计阶段末期”或“开发阶段初期”，提前将验㊣收的目标□□□□、用例□□□、评审几个环节达成一致，等到正式进入验收测试后，直接做执行即可。

　　当然在此过程大概率会涉及UI或UE方面的调整，根据公司的团队组成不同而略有差异质量检测很随意，在此我将这✅些分工都纳入产品团队。

　　比如在✅页面上输入A，经过处㊣理输出B，我们只需要确认A□□、B的结㊣果没有问题即可。至于是A-C-D-E-B，还是A-F-B，大多数验收测试不✅会㊣关注。后台的处理过程应该在设计阶段□□、集成测试阶段进行验证。

　　比如报表查询的等待时间是3秒还是3.5秒，对于业务人员也不会关注，只要不超过一定的“阈值”即可。而真正的性能测试□□□、安全测试等，都有相应的测试阶段“专项攻克”。

　　另外，验收㊣测试的重点是用户体验测试。这里㊣包含了平台体验一致性□□、易用性□□□、交互效率□□□□、合理性等，根据不同的产品类型，还包含创新性□□、趣味性等。

　　很多产品在前期并不重视用户体验，最终呈现了一个看似什么问题都能解决，但没有用户使用的“残次品”，很多问题也是出现在了验收测试阶段。

　　这里着重强调一✅个“用户思维”。无论是哪类人员进行验收测试，都要站在目标用户群体的画像上，试着以他们的角度□□□□、认知□□□、习惯来审视当下的产品功能，而非利用自己的习惯进行评判。

　　举个不恰当的例子：假设这款产品是为视力较差且不戴眼镜的用户设计的，字体就要放大，布局就要稀松。而验收测试的人即便视力正常，也要遵循目标用户的操作习惯。

　　而且，本身验收测试人员对互联网软件工程的理解比较浅，因此更要发挥自己的优势，以用户□□、场景产品㊣质㊣量检测□□、业务为导向，在此阶段中㊣发现潜在的操作问题。

　　验收测试的结束，意味着产品达到上线标准。但达到上线标准并不代表没有缺陷，所以我认为验收测试的准出原则主要有以下几个：

　　我最㊣初的想法，是让团队内的人员进行“交叉验收测试”，即张三负责的需求，验收测试由李四做；李四负责的需求，验收测试由王五做。

　　这样交叉验收的好处是：一方面组内同学都可以相互了解产品的业务全貌，避免形成思维壁垒；另一方面也是做了一层保障，让新同学测试，更容易找到用户视角。

　　但有时会遇到不太好改的问题，或者随着时间推移导致政策变动□□、用户预期及偏好变动□□□□、市场变动等情况，让业务人员发现本版并不能满足业务要求。

　　若需求变更程度小于10%且工作量在1周内的本版本解决，可以进行需求变更；若需求变更范围影响涉及比例超过原需求10%则延至下一版本，并确定延期交付的时间。

　　但我也遇到过验收测试做了多轮的情况，大多是因为前期流程控制和交接的问题，在本阶段出现了需求变更□□、需求蔓延✅等，导致后续的过程异常艰难。

　　其实每个测试阶段要进行几轮，并没有一个明确的规范，我们可以结合当下版本的大小□□□□、风险的高低□□、资源配置情况等，制定不同的要求。

　　但千万要注意，每当新一轮测试伊始，经常会出现一些㊣稀奇古怪的问题，这些问题一定要引起团队的重视，因为在软件层面，任何一个问题的出现都不是偶然。

　　今天的分享，基本框架是去年我在团队中构建的产品验收流程，然而随着我的离开，也没有✅机会验证此流程的效果，这不得不说是一种遗憾。

　　一份流程的建立不仅需要对现状和目标的考量，更需要牵头人的督导和推动，在面对多重阻碍时适度调㊣整，最终经过几个周期的迭代，让各个角色都形成一种习惯。

　　而这个周期，大概率要以“季”或“年”为单位衡量，确实很难，但我相信一定有团队在做，或已经做出了成果。