基于用户使用场景的产品测试

yixieshi.com

　　产品测试一般都是围绕需求为主的产品需求设计说明书PRD文档来展开测试的，针对每个功能点编写测试用例，去验证功能的正确性和完整性。这种方式在正常的开发上线进度下都不会有问题，相反是一种很好的验证功能需求实现的方式。但在敏捷开发模式或者因为赶进度的原因，造成产品测试时间非常紧的情况下，用这种方式就会有点捉襟见肘。 互联网的一些事

　　以用户为中心的产品设计已经逐渐的深入人心，产品主题功能要能满足用户的某种诉求或者解决用户的某个痛点，也有说成是以用户痛点为中心的产品设计。在这种大背景下，产品开发完成后，如果测试时间非常紧，在不能保证产品没有问题但却必须要按时上线的时候，就必须保证产品在用户使用的场景下没有问题，也就是说优先保证用户使用产品的整个流程当中不会出现问题，这就是基于用户使用场景的产品测试法。 互联网的一些事

　　在实际的测试过程当中，最常见的还是基于产品功能的测试，那基于用户使用场景的产品测试两者之间有什么区别呢?区别一是后者的测试范围更小，忽略了一部分产品后台功能的测试或隐性的功能测试，即只是测试了表面操作性的过程，没有测试底层的功能;区别二是后者的测试是把产品功能转化成实际用户使用场景下来测试，这就要求测试人员要从普通用户的操作角度出发，而不能受开发人员的影响，以一个初次使用产品的用户角度，来验证产品的功能是否可以在使用过程中提供正常的服务。 互联网的一些事

　　这里需要注意的一点是，在时间进度允许的情况下，还是要基于产品功能的测试，以求测试可以覆盖到产品的方方面面，确保产品可以提供完善的服务。本文所阐述的基于用户使用场景的产品测试都是建立在测试时间非常紧的前提下的，因为本身这种测试方法因为测试的不够全面，有一定的风险性在里面，对产品而言不一定是好的，只是为了保证产品的发布时间，而采取的一种较为折中的测试方法。这种测试方法的使用需要有以下两个要素，否则最好还是做全面的产品功能测试。 互联网的一些事

　　测试时间非常紧 互联网的一些事

　　其实这种场景非常的常见，项目进度安排了之后，往往因为需求分析的时间超长了，或者开发的时间延误了，导致最后留给测试人员的时间非常少，这时如果必须保证项目上线进度的话，就无法完成全面的产品功能测试，只能优先测试用户操作流程当中所需使用的各个产品的功能模块的流程。有的时候也是因为测试资源的不足所导致的测试时间紧迫，测试人员在这些情况下可以考虑基于用户使用场景的测试，但必须与项目经理或者主管领导说明清楚，是为了确保项目进度而采取的优先测试用户使用产品流程的功能。

yixieshi.com

　　从傻瓜用户的角度测试 互联网的一些事

　　基于这种方式的测试，测试人员就必须从用户的角度出发，而不是从开发人员或者产品经理的角度。也即测试人员必须保持相对的纯粹性，可以参加产品功能需求的review，但就不应该参加开发人员的系统设计review了，否则会受到开发人员实现方式的影响，而导致后续的测试不准确。应该是在保证理解产品功能需求的基础上，尽量从普通用户的使用场景出发，找出使用过程的问题，以便开发人员优先解决，这时候测试人员也不需要和开发人员去讨论问题，只需告诉问题发生的场景即可，以便尽可能的不受外界信息的影响。

yixieshi.com

　　在上述两个要素满足的条件下，测试人员还要抛开自己的计算机专业素养，把自己当成一个大众化的用户，以使测试的结果更接近真实的使用场景。由于该种测试方法并未覆盖产品的全部功能，会造成产品发布后有一定的风险性，既然知道有这样的风险，就需要去尽量的避免或者降低相应的风险，这就需要整个产品团队的配合，也需要测试人员自身有一套完整的测试体系。 互联网的一些事

　　开发人员的自测和Code Review 互联网的一些事

　　开发人员在开发完成之后，需要有一轮自测，以降低代码风险和功能缺陷，减少后续测试验证和改BUG的时间。自测的过程当中，需要与产品经理的需求相结合，以实现第一轮的功能验证，一旦出现问题及时解决。开发人员也是最熟悉底层结构的人员，一些底层的功能问题可以在自测过程当中去发现解决，尽可能保证没有大的问题遗留到测试阶段。自测也是开发人员自身能力水平提升的一个很好的机会，提升代码质量的同时，也是提高对自身编写代码责任度的一种方式。自测是需要基于开发人员自身的能力水平的，此外还可以借助团队的配合，如敏捷开发模式当中就很强调开发团队内部的Code Review，一个开发人员编写的代码，由另外两个经验较深的开发人员来共同把关，这样也可以在很大程度上减少代码缺陷，尽早的发现问题。

yixieshi.com

　　从用户使用的角度去测试 互联网的一些事

　　基于用户使用场景的测试不能保证产品没有问题，但必须保证产品在用户使用过程当中没有问题，这就要求测试人员必须从用户的角度出发，真正按用户的操作流程去操作测试产品的功能。再就是把编写测试用例的时间，留出来用于理解产品的功能需求，以便在测试的过程当中及时发现不满足需求的功能点，因为这类功能点在测试的时候并不会出错，但却不是需求说明书中所设计的那样，这就需要测试人员充分的理解需求。也不是说测试用例就不需要编写了，而是在测试的过程当中，依赖测试工具去记录测试的过程，后期再来整理这部分用例。因为这个测试阶段结束了之后，后续还是要继续验证产品的整体功能的，包括底层的功能，这时可以一起编写测试用例文档。

yixieshi.com

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

　　前面也都提到了这种测试方式是存在风险的，这就要求在发布上线之后要继续进行剩余功能的测试，而不是测试过程就终止了。在后续的测试过程当中，可以一并验证之前遗留的问题，并在接下来的一个快速迭代中上线解决掉，这样就可以将产品的功能风险降到最低，使产品提供稳定的服务。 yixieshi.com

　　基于用户使用场景的测试目前应用的还不是很多，在创业型产品的快速迭代中，或者敏捷开发模式下的敏捷测试当中，会有一些应用。这种方式虽然有一定的缺陷，但却是一种非常好的备选方案，可以在保证项目进度的情况下，也能保证用户在使用产品的时候不出问题，使产品在用户手上没有问题，这也是发布产品的一个目的，符合产品发布的要求。 互联网的一些事