编辑简介：项目完成后，产品经理仍会发现一堆bug，产品经理在遇到这个问题时应该怎么做？首先，不要对谁负责。


我们应该回顾哪个环节存在问题，共同分析和解决；作者分享了产品验收中的发现bug我们来看看后面的解决方案。


为什么要写清楚？ 1000 多个测试用例，回到测试几个小时，当产品经理验收时，仍然是一堆 bug？ 产品经理最终对产品的交付效果负责。


当客户有问题时，他不能说：这不是我的问题，我的产品设计没有问题，测试人员没有测量；所以除了产品规划，我们还花了很多精力进行测试和验收。


以前，我们的产品经理参与了许多环节：静态页面验收、开发环境验收、测试环境验收、产品验收。


对于产品经理来说，一个强大的测试至少可以减少 50% 工作量；我们都希望最后一次验收，一次。


当我们的愿望无法实现时，我们必须回顾测试问题，看看它是否能得到改善。


一、回归测试全部测试吗？ 事实上，我们不想质疑这一点。


这是测试人员的责任。


但我们经常忍不住想：测试真的测试过吗？ 比如这个页面的字段少了，测试看不到最基本的问题吗？ 例如，在线内容与某些模块无关，页面查看和点击页面上的按钮是正常的，但当您保存或修改错误的时间报告时，这不是在测试范围内吗？ 也许测试专注于新功能，主观上认为某些功能没有问题，所以没有完整的测试用例。


然而，我们仍然需要承认，测试时间一般相对较紧，有时人力不足，测试压力很大，重点测试；理论没有问题，有时取决于运气问题的可能性和严重性。


二、只关心流程，不关心体验 有时候我会去面试测试人员。


我关心的一个问题是:你考试的时候会看风格吗？体验不好的时候会提吗？ 也许这些年来有一些心理阴影——我遇到了一些测试，认为风格和经验与他们无关；从公司责任划分的角度来看，没有问题。


没有人想阻止自己做很多工作。


此外，有些是主观的，不能定量的。


从产品经理的角度来看，我希望团队中的每个人都是产品经理。


我们可以共同努力，实现产品的同一目标。


也许我们的期望太高了，没有明确地传达给测试；然后，在以后的责任任时，可以要求他们比较风格 UI 测量稿件，记录前端 bug，只能问题只能尽量提出，给我们一些建议。


三、没有从现实场景出发 我们经常遇到这个问题，即使我们按照我们的要求验收产品，领导或客户点，或者一堆 bug。


因为每个人在使用产品时，场景不同，使用方法也不同，会有很多意想不到的问题。


主要原因如下： 1. 数据过于测试化 大部分测试数据为111、222，按测试用例测试产品1没有问题；但一旦数据被用户的真实数据取代，就会有很多问题。


最常见的问题是字符长度般来说，字段长度的限制是 32,64,128 这样，当测试数据长度过短时，显示没有问题。


一旦更长，页面可能会混乱；例如，药品名称、测试数据为芬必得，真实名称为芬必得布洛芬缓释胶囊。


我们经常让测试做边缘测试，但事实上，不可能做所有的字段，那么如何区分哪些要做，哪些不做呢？最好的方法是测试一个典型的客户数据，并尽量避免写作 111 这种。


2. 用户使用路径没有模拟 简单地说，没有从用户的角度来测试产品；这一点可能对测试有点高，绝大多数人可以根据测试思维来测试产品。


这也与上述点有很大关系。


当我测试环境测试时，我经常找不到问题。


为什么？因为当我看一些过于测试化的数据时，我想不出下一步该操作什么；因此，一般产品经理会建立一些相对真实的数据，而不是使用测试数据。


最重要的是这一点:互联网人对产品业务的理解太浅，甚至不理解，尤其是 B 端产品；大部分的开发和测试都没有接触过客户，也没有去过现场。


单靠产品经理的叙述，很难建立三维感。


像医疗、工业这样的门槛相对较高，也许我们也去过医院，因为医生的诊断过程也经历过；但工业离我们很远，真的从来没有去过工厂，很难理解为什么有些产品不看数字，看数字，为什么存储产品包装没有条形码，为什么钢也关心炉批号。


如果公司允许，可以带着开发和测试到现场，对产品开发有很大的帮助。


四、总结 产品有 bug，先别想谁来背这个锅。


产品经理会说:测试不到位； 测试会说：开发水平太差，bug 太多； 开发会议说：你的产品文档没有写清楚。


或者强调这一点：产品不是一个人的事，而是每个人的事；我们花时间分析问题，制定解决方案，会更有效。


特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。


本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。


如有侵权行为，请联系网站管理员删除，。