首页 > 其他 > 详细

为什么会有生产bug?

时间:2021-09-15 20:42:49      阅读:2      评论:0      收藏:0      [点我收藏+]

技术分享图片

 

 回归测试测全了吗?

这一点其实是我们不愿意去质疑的,这是测试人员的责任问题。但我们在验收时常常忍不住想:测试真的有测过吗?
比如说这个页面的字段少了,这种最基本的问题,测试都看不出来吗?

比如这期上线内容和某些模块没有关系,页面查看和点击页面上按钮时也都是正常的,但当你去保存或者修改时报错了,这难道不属于回归测试范围内的?
可能测试把注意力放在了新增功能上,主观觉得某些功能不会有问题,就没有执行完整的测试用例。
不过这一点还是要承认的,测试时间一般都是比较紧的,有时候人手还不够,测试压力很大,有所侧重的测试,理论是没问题的,有时就看运气好不好了,出现问题的概率和严重程度有多大。

回归测试是指重复以前的全部或部分的相同测试。新加入测试的模组,可能对其他模组产生副作用,故须进行某些程度的回归测试。

只关心流程,不关心体验
遇到过一些测试,觉得样式和体验是和他们无关的事情。从公司责任划分来看,这也没什么问题,谁都不想给自己拦很多活,况且一些是偏主观,不能定量的。
但从项目经理角度来说,希望大家可以齐心协力,奔着把产品做好的同一个目标去。 固需要向测试传达清楚这一目标。后面责任划分时可以要求他们样式对照 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

为什么会有生产bug?

原文:https://www.cnblogs.com/lottche/p/15268992.html

(0)
(0)
   
举报
评论 一句话评论(0
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!