【百天计划051】产品测试：产品上线前的验收把关

产品研发出来之后，产品经理要参与到测试当中，这一点相信大家都是明白的。但要在什么时候开始参与测试，以什么样的角度去测呢？毕竟产品经理不是专业的测试人员。

产品测试一般都是围绕需求为主的产品需求设计说明书PRD文档来展开测试的，测试人员针对每个功能点编写测试用例，去验证功能的正确性和完整性。这种方式在正常的开发上线进度下都不会有问题，相反是一种很好的验证功能需求实现结果的方式。

以用户为中心的产品设计已经深入人心，产品主体题功能要能满足用户的某种诉求或者解决用户的某个痛点，也有说成是以用户痛点为中心的产品设计。基于此，产品开发完成后，要首先保证产品在用户使用的场景下没有问题，也就是说优先保证用户使用产品的整个流程当中不会出现问题。

产品经理参与测试验证的时机

一般来说，产品研发的过程中，会有开发环境、测试环境、预发布环境、正式环境四套，也可能有些规模不大的项目没有预发布环境，那也至少有三套环境。把产品功能丢到正式环境上去测试是逼不得已的情况下才会采用的，因为可能有些功能只能在线上验证。

开发环境主要是开发人员进行自测和Code Review用的，在开发完成之后，需要有一轮自测，以降低代码风险和功能缺陷，减少后续测试验证和改BUG的时间。自测的过程当中，功能实现部分需要与产品需求相结合，以实现第一轮的功能验证，一旦出现问题及时解决。

如果产品经理每天都在跟进研发进度的话，在开发人员自测的过程当中，就可以参与进去。不一定要去操作，因为开发环境的配置一般比较麻烦，可以在旁边看实现的效果是否符合预期，如果这时候就能发现问题，就可以避免到了测试环节发现问题而来不及改的情况。

测试环境主要是测试人员进行功能测试、性能测试用的，基于测试用例，对产品功能的实现结果进行验证。测试用例思考的角度会比较全面，很多场景都是用穷举的方式排列出来的，所以经常能看到测试出来一些之前没想到的规则、逻辑漏洞。

在测试环节，产品经理是需要深度参与的。可以在测试人员验证过一轮，开发人员也改过一轮bug之后再参与进去。基于产品功能需求进行测试验收，不一定按照测试用例的要求来。这就涉及到了测试角度的问题。

基于用户使用场景的测试验证

在实际的测试过程当中，最常见的还是基于产品功能的测试，那和基于用户使用场景的产品测试两者之间有什么区别呢？

一是后者的测试范围更小，忽略了一部分产品后台功能的测试或隐性的功能测试，即只是测试了表面操作性的过程，没有测试底层的功能；

二是后者的测试是把产品功能转化成实际用户使用场景下来测试，这就要求测试人员要从普通用户的操作角度出发，而不能受技术实现和开发人员的影响，以一个初次使用产品的用户角度，来验证产品的功能是否可以在使用过程中提供正常的服务。

这种测试方法因为测试的不够全面，有一定的风险性在里面，对产品而言不一定是好的，所以只适合两种情况下使用：一是测试时间紧，来不及进行完整测试的情况下；二是测试的人是产品经理，而非专业测试人员。

基于用户使用场景的测试可以保证产品在用户使用过程当中没有问题，这就要求测试时必须从用户的角度出发，真正按用户的操作流程去操作测试产品的功能。从用户的使用场景出发去测试需要测试人员对用户使用产品的方式有一定的了解。

比如说财务系统和普通的业务系统在操作的时候差异就比较大，原因是财务系统受政策或会计准则的影响比较大。这需要测试人员去更多的了解用户的使用，当然这个过程也还是要基于产品自身的功能结构设计，不排除有一些需要培养用户使用习惯的功能，这种功能就需要产品经理做一些特别的说明，以使测试人员理解产品设计的意图，最好可以提供一份产品操作使用手册。

基于傻瓜用户角度的测试验证

周鸿祎曾说过，产品经理要像小白用户一样去思考，像白痴用户一样去体验。基于这种方式的测试，测试人员就必须从用户的角度出发，而不是从开发人员或者产品经理的角度，也即测试人员必须保持相对的纯粹性。

在保证理解产品功能需求的基础上，尽量从普通用户的使用场景出发，找出使用过程的问题，以便开发人员优先解决，这时候测试人员也不需要和开发人员去讨论问题，只需告诉问题发生的场景即可，以便尽可能的不受外界信息的影响。

另外还要抛开自己的计算机专业素养，把自己当成一个大众化的用户，以使测试的结果更接近真实的使用场景。这一点相对来说确实有点难，在条件允许的情况下，可以用一下可用性测试的方法，找公司里面和项目完全不搭边的人员来进行操作验证，观察过程中会出现哪些问题。

保证用户在使用产品的时候不出问题，使产品在用户手上没有问题，这是产品经理必须要做到的，是责任心的体现，也是发布产品的一个目的。

产品经理一定要重视产品上线前的验收把关，不要轻易的让用户来发现bug，很多用户就是在使用时不顺畅，就这么默默的流失掉了。