产品验收

2023年12月21日
项目自立项开始，基本可以分为：需求阶段、设计阶段、开发阶段、测试阶段、上线及试运行阶段。
测试阶段可以分为：单元测试（有些团队会归到开发阶段）、冒烟测试、SIT测试（系统集成测试）、UAT测试（用户/产品验收测试）。
产品内部验收测试往往是由产品经理来主导

意义

1. 第一、通过对测试结果的复核，能够形成流程闭环，有利于产品质量和效率的双保障。
2. 第二、产品内部验收后，对于接下来的外部验收操作、试运营及正式上线，具有更好的借鉴、指导意义和培训价值。
3. 第三、从产品角度进行验收测试，既可以更好地复核主要功能与核心业务流程的符合性，也可以提前发现并记录需要迭代的需求。
4. 第四、通过规范的产品验收工作流程，可以统一工作目标和行动指南，节约沟通成本，避免不必要的工作偏差。

验收测试的准入条件

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

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

验收准入条件

1. 上一阶段的测试报告

   关键指标：测试通过率。

   并且关注一下未通过、遗留的缺陷是什么情况，是否会阻碍验收进度，影响用户的场景闭环。

2. 验收账号
3. 验收测试用例
   验收测试开始前需要设计好测试用例，准入条件满足之后即可开始验收。
4. 什么时候开始启动？
   产品验收虽然是最后一个环节，但它的启动阶段可以前置到“设计阶段末期”或“开发阶段初期”，提前将验收的目标、用例、评审几个环节达成一致，等到正式进入验收测试后，直接做执行即可。

准备工作

1. 先写个产品验收测试方案，包括产品验收的流程，以及对测试情况的复盘与沟通。
2. 写一个产品验收测试标准，做一个表格，并且组织大家一起评审。
3. 验收阶段主要涉及三类角色：产品（业务）、UI、测试、开发。

这么做的原因也很简单，一是，要明确现阶段工作的状态，要知道测试的情况，哪些已经测试了，哪些还没有测试，这样才能针对性地验收。有些功能测试都没有测试结束，怎么能验收呢。
二来，这可能也是一个隐性的坑，产品在测试评审之后，又进行了验收，如果线上有什么问题的话。。。

怎么写好产品验收测试方案

首先，要明确产品验收方案的定义，是对产品验收工作的指导性文件。
从内容来说，产品验收测试方案，主要包括几个部分：

1. 验收测试流程；
2. 测试团队的测试评审；
3. 验收规划；
4. 验收思想；
5. 验收标准表。

验收流程

验收流程一般为：

1. 验收准备，编制产品验收方案。
2. 组织验收方案评审会。
3. 正式启动执行产品验收工作。
4. 制定验收测试标准并组织评审。
5. 执行验收测试。
6. 验收结果评审。
7. 验收通过。

制定验收测试标准并组织评审

在评审验收流程时，一定要提前或者同步评审测试的结果，因为，严格意义上说，评审是对测试结果的复核。

那么在评审测试时，重点要注意几个方面：

1. 测试完成后，已完成的全部测试并达到测试标准的功能模块。
2. 测试完成后，已完成主要业务流程测试，但未完成完整用例测试，仍需继续执行测试的功能模块。
3. 测试完成后，仍有未进行主要业务流程测试、用例测试的需求功能。
4. 补充内容，上线前仍存在个别功能或内容，需要执行完整测试方可允许上线的功能。
5. 根据测试情况，制定测试策略，确认进度安排，协调开发工作、产品验收工作。
6. 测试内部评估产品质量，反馈上线各岗位工作建议。
7. 如有需要，可以提出需要各岗位支撑工作。

验收规划

接下来就是对验收过程的规划管理，主要包括人员安排、工作协同安排、进度规划管理以及结果评审的规划。

验收思想

要站在产品角度去验收和测试。
本阶段的测试重点在核心业务流程和用户体验层面，对后台处理逻辑的合理性、性能等不会过度关注。
重点把控主要业务流程，切勿执行详细地用例测试，这样既对产品验收工作无益，也有碍于测试的正常进行。

比如在页面上输入A，经过处理输出B，我们只需要确认A、B的结果没有问题即可。至于是A->C->D->E->B，还是A->F->B，大多数验收测试不会关注。后台的处理过程应该在设计阶段、集成测试阶段进行验证。
比如报表查询的等待时间是3秒还是3.5秒，对于业务人员也不会关注，只要不超过一定的“阈值”即可。而真正的性能测试、安全测试等，都有相应的测试阶段“专项攻克”。

1. 产品验收测试主要是针对核心业务的流程测试，应包括主要业务流程。
2. 产品验收测试不必执行详细用例测试，但需要针对个别核心功能的逻辑完整性、功能符合性、数据准确性等进行抽样测试，具体依据功能测试标准表而定。
3. 产品验收测试过程中，同样需要对系统界面予以整体把关，依据产品需求评审沟通情况，提出反馈建议（抓大放小，分步迭代）。
4. 产品验收测试应从产品视角，尽力发现需要迭代更新的功能，以便更好地提升产品功能丰富度和用户体验。
5. 验收过程中，应保持沟通通畅，应根据工作实际情况，随时调整验收测试的应对策略。

验收标准

在梳理好流程，明确了验收的思想、目的之后，在执行验收测试之前，还需要制定测试标准。这个标准是验收测试工作的依据，制定验收标准要注意两点：

1. 不需要太关注细节，但要明确主要流程，并且要记录测试等级、结果以及应对策略；
2. 一定要组织评审，让项目各岗位成员都参加。

准出原则：
（1）新一轮验收测试中，主流程+辅助流程的缺陷修复率达到100%；
（2）遗留缺陷在不影响系统正常运行前提下，多方达成一致确认可后续迭代优化；
（3）产品整体的视觉体验验证通过；
（4）对于升级类产品，对于原有功能的影响度测试完成；

最后，形成验收测试报告，将本次测试的结果写清楚。

验收测试的问题处理

1、交叉验收

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

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

2、缺陷处理机制

大部分缺陷，直接找到测试人员或开发人员进行验证、修复即可。

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

1. 少量极端场景下存在等级为高级的缺陷要进行需求变更

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

2. 经过产品评审会讨论，此功能不再验收（忽略）。

   1. 有些问题虽然存在，但为特殊场景下的低频偶发情况，经过评审会讨论后，将其忽略。

验收轮次

正常来讲，产品验收测试做两轮即可，如果遇到交付质量较高的版本，一次测试直接通过也可以。