本文讨论了产品经理在保证产品质量方面所起的关键作用，特别是在测试流程中作为测试人员的补充和最终验收者。文章强调了产品经理需要在项目多个阶段如静态页面验收、测试环境版本验收以及上线后整体体验等环节参与质量把控，以提前发现并解决问题，从而提高项目的可控性和优化资源分配。
测试是整个产品线的最终守护神，所有上线可商用的产品都需要经过测试完整地做过多轮测试，并达到上线标准后，才可以最终上线，一般上线后还要做一遍主业务流程的全量回归后，才可以正式宣布发布成功。
整个项目过程中，产品经理在保证产品质量这件事上扮演着什么角色呢？
角色和作用
产品经理在整个项目的质量把控过程中，作为“测试人员之外的补充”和“最终验收”的角色存在。
为什么需要补充？
一般测试人员的测试用例是基于产品的需求（详细原型）书写的。
从需求原型—>测试用例的转换，这其中难免会因为需求理解不透彻、测试用例遗漏、测试用例的颗粒度过大、产品需求本身就有问题等各种原因，而导致测试环节并不能发现全部问题，即测试不充分。
高端测试还会基于接口文档、开发的设计文档、第三方接口文档等综合来写测试用例，从底层的服务维度去设计用例，让用例更接近本质，而不是停留再表象。
此外，优秀的测试会从功能、接口、业务、数据、性能、安全、数据多维度去考虑问题，并会做check review，即按照用例模版再核对一遍写的用例，看是否有遗漏。
从整体来把控整个版本的测试质量。
但是往往我们无法保证测试一定按照上述高要求书写测试用例，并按高标准完成整个测试过程。
因此为需要避免测试不充分的问题，产品需要在项目多节点上进行辅助和补充。
在哪些环节做补充？
（1）静态页面验收：
在我们团队，我们要求产品经理在前端写完静态页面的时候，就开始介入Mock测试，主要就是验收UI层面，期间UI设计师会和产品经理一起参与检查，并统一由UI设计师将问题提交前端，进行修改后，再由产品经理和UI设计师进行一遍验收，最终由Ui设计师确定通过验收。
注意事项：任何节点的负责人只能是一个人、或一个角色，多人多角色拍板会出现“打架”问题，导致协同出现问题
为什么要做这步验收？作用是什么？
因为我们在项目推进过程中发现，在最后上线前的测试环节，或是产品测试环节，发现的页面结构、排版、颜色、字段名称和显示位置、组件控件样式等问题，再让开发进行修改就会导致来不及的情况，因为这个时候大家都在忙着修高危bug，这些所谓的“轻量级问题”自然被延后处理了。
这样就很尴尬了，虽然从产品和UI角度来看，上线前这些也算是问题，和UI设计不符，需要被改掉才能上线，但是上线时间是确定的，而且最后测试环境下的测试时间就那么几天，修复高危问题优先级肯定更高，这些小问题自然被遗留到了线上等待下期修改。
相反，前期在前端完成静态页面开发，在等后端接口的时候其实是相对空余的，这个时候完全可以提前对页面与设计不符的部分进行修改。
因此这一步其实是将问题提前发现，提前解决，而不将其遗留到最后最忙碌的环节，提高了项目的可控性，降低了风险，优化了阶段性资源配置，对整个项目有非常大的好处。这其实就是项目管理的思路。
（2）测试环境下提交的版本符合验收标准后，产品验收
这时产品需要验收的内容包括如下：
1、业务主流程、分支流程等功能流程是否正确
2、页面跳转、控件响应等交互是否正确
3、不同条件下页面的字段、文案等是否正常显示
4、数据的是否准确
5、功能闭环的业务逻辑是否正确等等
6、产品的整体的使用体验
这次验收的目的：
1、对测试的补充，因为测试关注的更多是基于用例的错误之处，而会弱化对产品整体的使用和细节使用的评测，站在客户的角度去体验产品。因此产品再从用户角度和产品角度验收，有利于弥补一些之前没发现的隐形问题，有可能它们并没有用例之中
2、其次也是让产品发现问题，原型和最后的demo，在演练用户具体使用时的情景下，是完全不同的感觉，原型看着很ok，demo出来后会发现这个功能设计的好像有点问题，那个好像也有点问题，这是很正常的，特别对于一些复杂的功能，会在真正产品做出来后对自己之前的设计产生质疑，甚至推翻自己的设计，发现问题，并在后期迭代中进行解决
（3）上线后再整体体验一遍
当产品从预发布环境上线到生产环境时，测试一遍需要全量回归一遍用例。
基本上这个环节整个版本已经没有高危bug（1、2级bug），且3级bug（不影响产品的运行、不会成为故障的起因、但对产品外观和下道工序影响较大的缺陷）也基本没有，可能会因为来不及改、或者并不重要仅存一些4级bug（程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误）
通过线上回归后，产品可以再对产品进行功能、交互、流程的体验，验证一遍上线后是否出现异常问题，因为环境的不同，可能会导致一些预发环境下是正常的功能，到线上就出现了异常。
没有回复内容