回归测试测全了吗？
这一点其实是我们不愿意去质疑的，这是测试人员的责任问题。但我们在验收时常常忍不住想：测试真的有测过吗？
比如说这个页面的字段少了，这种最基本的问题，测试都看不出来吗？
比如这期上线内容和某些模块没有关系，页面查看和点击页面上按钮时也都是正常的，但当你去保存或者修改时报错了，这难道不属于回归测试范围内的？
可能测试把注意力放在了新增功能上，主观觉得某些功能不会有问题，就没有执行完整的测试用例。
不过这一点还是要承认的，测试时间一般都是比较紧的，有时候人手还不够，测试压力很大，有所侧重的测试，理论是没问题的，有时就看运气好不好了，出现问题的概率和严重程度有多大。
回归测试是指重复以前的全部或部分的相同测试。新加入测试的模组，可能对其他模组产生副作用，故须进行某些程度的回归测试。
只关心流程，不关心体验
遇到过一些测试，觉得样式和体验是和他们无关的事情。从公司责任划分来看，这也没什么问题，谁都不想给自己拦很多活，况且一些是偏主观，不能定量的。
但从项目经理角度来说，希望大家可以齐心协力，奔着把产品做好的同一个目标去。 固需要向测试传达清楚这一目标。后面责任划分时可以要求他们样式对照 UI 稿测，记录前端 bug，体验问题只能说尽量提出，给我们一些建议。
没从现实场景出发
这个问题我们也经常会遇到，哪怕我们按照我们的要求验收通过了产品，领导或者客户点的时候，还是一堆 bug。 因为每个人在使用产品时，场景不一样，使用方法也不一样，就会出现很多预料之外的问题。主要还是下面2点原因。
数据过于测试化 大部分的测试数据都是“111,222”，测试“产品 1”这种，按照测试用例来测试时是没问题，但一旦把数据换成用户的真实数据，问题就很多了。
最常见的是字符长度问题，一般字段长度限制是 32,64,128 这种，测试数据长度太短时显示没有问题，一旦长一点，页面可能都乱了。比如药品名称，测试数据是“芬必得”，真实名称是“芬必得布洛芬缓释胶囊”。 我们经常让测试做边缘测试，但事实上不可能所有字段都做，那怎么区分哪些要做，哪些不要做呢？最好的方法就是拿一家典型客户的数据来做测试，尽量避免写 111 这种。
没模拟用户使用路径
简单来说，没有站在用户的角度去测试产品。这个点或许对测试来说要求是有点高，绝大部分人能按测试思维，把产品测完就已经不错了。 这和上面一个点也是有非常大的关系的，我在测试环境测的时候，也常常发现不了问题，为什么？因为看着一些过于测试化的数据时，我都想不出下一步该去操作什么。所以一般产品经理都会建一些相对比较真实的自己的数据，而不是用测试数据。
最关键的还是这个点：对产品业务的理解太浅，甚至是不理解，特别是 B 端产品。大部分的开发和测试，没有接触过客户，没有去过实地，单靠文档的讲述，很难建立三维的感观。这就需要在文档编写时候尽可能的描述业务场景。
总结
发现有 bug，先不要想这个锅应该谁来背。项目经理会说：测试没有测到位；测试会说：开发水平太差，bug 太多；开发会说：你的产品文档没写清。 还是要强调这个事：产品不是一个人的事，是大家的事。我们把甩锅的时间用在分析问题、制定解决方案上，会更加有效。
————————————————
版权声明：本文为CSDN博主「自强不息的小芦同学」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/ch1209498273/article/details/118512522