为什么明明写了 1000 多条测试用例，回归测试测了几个小时，等产品经理验收时，还是一堆 bug？
产品经理最终对产品的交付效果负责，客户有问题时，他不能说：这不是我的问题，我产品设计是没问题的，是测试人员没测出来。所以我们除了产品规划外，还花了很多的精力在测试验收上。
之前我们产品经理参与验收的环节有很多：静态页面验收，开发环境验收，测试环境验收，上线后产品验收。
对于产品经理来说，一个给力的测试至少能减少 50% 的工作量。我们都希望只最后验收一遍，而且是一遍过。
当我们的愿望达不成时，我们就得回过头去看看测试的问题，看是否可以改善。
01
回归测试测全了吗？
这一点其实是我们不愿意去质疑的，这是测试人员的责任问题。但我们在验收时常常忍不住想：测试真的有测过吗？
比如说这个页面的字段少了，这种最基本的问题，测试都看不出来吗？
比如这期上线内容和某些模块没有关系，页面查看和点击页面上按钮时也都是正常的，但当你去保存或者修改时报错了，这难道不属于回归测试范围内的？
可能测试把注意力放在了新增功能上，主观觉得某些功能不会有问题，就没有执行完整的测试用例。
不过这一点还是要承认的，测试时间一般都是比较紧的，有时候人手还不够，测试压力很大，有所侧重的测试，理论是没问题的，有时就看运气好不好了，出现问题的概率和严重程度有多大。
02
只关心流程，不关心体验
有时候我也会去参加测试人员的面试，我比较关心的一个问题是：你们测试时会看样式吗？体验感觉不好时会提吗？
可能是这些年有些心理阴影了吧。遇到过一些测试，觉得样式和体验是和他们无关的事情。从公司责任划分来看，这也没什么问题，谁都不想给自己拦很多活，况且一些是偏主观，不能定量的。
从产品经理角度来说，希望团队中人人都是产品经理，大家可以齐心协力，奔着把产品做好的同一个目标去。
可能是我们的期望太高，也没有向测试传达清楚。那后面责任划分时可以要求他们样式对照 UI 稿测，记录前端 bug，体验问题只能说尽量提出，给我们一些建议。
03
没从现实场景出发
这个问题我们也经常会遇到，哪怕我们按照我们的要求验收通过了产品，领导或者客户点的时候，还是一堆 bug。
因为每个人在使用产品时，场景不一样，使用方法也不一样，就会出现很多预料之外的问题。主要还是下面2点原因。
数据过于测试化
大部分的测试数据都是“111,222”，测试“产品 1”这种，按照测试用例来测试时是没问题，但一旦把数据换成用户的真实数据，问题就很多了。
最常见的是字符长度问题，一般字段长度限制是 32,64,128 这种，测试数据长度太短时显示没有问题，一旦长一点，页面可能都乱了。比如药品名称，测试数据是“芬必得”，真实名称是“芬必得布洛芬缓释胶囊”。
我们经常让测试做边缘测试，但事实上不可能所有字段都做，那怎么区分哪些要做，哪些不要做呢？最好的方法就是拿一家典型客户的数据来做测试，尽量避免写 111 这种。
没模拟用户使用路径
简单来说，没有站在用户的角度去测试产品。这个点或许对测试来说要求是有点高，绝大部分人能按测试思维，把产品测完就已经不错了。
这和上面一个点也是有非常大的关系的，我在测试环境测的时候，也常常发现不了问题，为什么？因为看着一些过于测试化的数据时，我都想不出下一步该去操作什么。所以一般产品经理都会建一些相对比较真实的自己的数据，而不是用测试数据。
最关键的还是这个点：互联网人对产品业务的理解太浅，甚至是不理解，特别是 B 端产品。大部分的开发和测试，没有接触过客户，没有去过实地，单靠产品经理的讲述，很难建立三维的感观。
像医疗、工业这种都是门槛比较高的，可能医院我们还去过，对于医生的看诊流程还体会得到。但工业就离我们比较遥远了，真的是从来没有去过工厂，很难理解为什么有些产品不看编号、看图号。入库产品包装上为什么没有条码，为什么钢材还要关心炉批号。
如果公司允许，能带着开发和测试去实地看看，对产品开发是有很大帮助的。
04
总结
产品有 bug，先不要想这个锅应该谁来背。产品经理会说：测试没有测到位；测试会说：开发水平太差，bug 太多；开发会说：你的产品文档没写清。
还是要强调这个事：产品不是一个人的事，是大家的事。我们把甩锅的时间用在分析问题、制定解决方案上，会更加有效。
源自公众号 司马特小分队