---

前言

为什么明明写了 1000 多条测试用例，回归测试测了几个小时，等产品经理验收时，还是一堆 bug？

产品经理最终对产品的交付效果负责，客户有问题时，他不能说：这不是我的问题，我产品设计是没问题的，是测试人员没测出来。所以我们除了产品规划外，还花了很多的精力在测试验收上。

对于产品经理来说，一个给力的测试至少能减少 50% 的工作量。我们都希望只最后验收一遍，而且是一遍过。

当我们的愿望达不成时，我们就得回过头去看看测试的问题，看是否可以改善。

回归测试测全了吗？
这一点其实是我们不愿意去质疑的，这是测试人员的责任问题。但我们在验收时常常忍不住想：测试真的有测过吗？

比如说这个页面的字段少了，这种最基本的问题，测试都看不出来吗？
比如这期上线内容和某些模块没有关系，页面查看和点击页面上按钮时也都是正常的，但当你去保存或者修改时报错了，这难道不属于回归测试范围内的？

可能测试把注意力放在了新增功能上，主观觉得某些功能不会有问题，就没有执行完整的测试用例。

不过这一点还是要承认的，测试时间一般都是比较紧的，有时候人手还不够，测试压力很大，有所侧重的测试，理论是没问题的，有时就看运气好不好了，出现问题的概率和严重程度有多大。

只关心流程，不关心体验
有时候我也会去参加测试人员的面试，我比较关心的一个问题是：你们测试时会看样式吗？体验感觉不好时会提吗？

可能是这些年有些心理阴影了吧。遇到过一些测试，觉得样式和体验是和他们无关的事情。从公司责任划分来看，这也没什么问题，谁都不想给自己拦很多活，况且一些是偏主观，不能定量的。

没从现实场景出发
这个问题我们也经常会遇到，哪怕我们按照我们的要求验收通过了产品，领导或者客户点的时候，还是一堆 bug。

因为每个人在使用产品时，场景不一样，使用方法也不一样，就会出现很多预料之外的问题。主要还是下面2点原因。

数据过于测试化
大部分的测试数据都是“111,222”，测试“产品 1”这种，按照测试用例来测试时是没问题，但一旦把数据换成用户的真实数据，问题就很多了。

最常见的是字符长度问题，一般字段长度限制是 32,64,128 这种，测试数据长度太短时显示没有问题，一旦长一点，页面可能都乱了。比如药品名称，测试数据是“芬必得”，真实名称是“芬必得布洛芬缓释胶囊”。

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

没模拟用户使用路径
简单来说，没有站在用户的角度去测试产品。这个点或许对测试来说要求是有点高，绝大部分人能按测试思维，把产品测完就已经不错了。

这和上面一个点也是有非常大的关系的，我在测试环境测的时候，也常常发现不了问题，为什么？因为看着一些过于测试化的数据时，我都想不出下一步该去操作什么。所以一般产品经理都会建一些相对比较真实的自己的数据，而不是用测试数据。

最关键的还是这个点：互联网人对产品业务的理解太浅，甚至是不理解，特别是 B 端产品。大部分的开发和测试，没有接触过客户，没有去过实地，单靠产品经理的讲述，很难建立三维的感观。

像医疗、工业这种都是门槛比较高的，可能医院我们还去过，对于医生的看诊流程还体会得到。但工业就离我们比较遥远了，真的是从来没有去过工厂，很难理解为什么有些产品不看编号、看图号。入库产品包装上为什么没有条码，为什么钢材还要关心炉批号。

如果公司允许，能带着开发和测试去实地看看，对产品开发是有很大帮助的。

产品有 bug，先不要想这个锅应该谁来背。产品经理会说：测试没有测到位；测试会说：开发水平太差，bug 太多；开发会说：你的产品文档没写清。

还是要强调这个事：产品不是一个人的事，是大家的事。我们把甩锅的时间用在分析问题、制定解决方案上，会更加有效。

下面是我整理的2022年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

每个人真正强大起来都要度过一段没人帮忙，没人支持的日子。所有事情都是自己一个人撑，所有情绪都是只有自己知道。但只要咬牙撑过去，一切都不一样了。

当你打算放弃梦想时，告诉自己，再多撑一天一个星期一个月，再多撑一年吧。你会发现，拒绝退场的结果令人惊讶。

如果你要想成功、要想追求所企望的美梦，就千万不可有这样的信念，因为那会扼杀你的潜能，毁掉你的希望。