目录:导读
前言
为什么明明写了 1000 多条测试用例,回归测试测了几个小时,等产品经理验收时,还是一堆 bug?
产品经理最终对产品的交付效果负责,客户有问题时,他不能说:这不是我的问题,我产品设计是没问题的,是测试人员没测出来。所以我们除了产品规划外,还花了很多的精力在测试验收上。
对于产品经理来说,一个给力的测试至少能减少 50% 的工作量。我们都希望只最后验收一遍,而且是一遍过。
当我们的愿望达不成时,我们就得回过头去看看测试的问题,看是否可以改善。
回归测试测全了吗?
这一点其实是我们不愿意去质疑的,这是测试人员的责任问题。但我们在验收时常常忍不住想:测试真的有测过吗?
比如说这个页面的字段少了,这种最基本的问题,测试都看不出来吗?
比如这期上线内容和某些模块没有关系,页面查看和点击页面上按钮时也都是正常的,但当你去保存或者修改时报错了,这难道不属于回归测试范围内的?
可能测试把注意力放在了新增功能上,主观觉得某些功能不会有问题,就没有执行完整的测试用例。
不过这一点还是要承认的,测试时间一般都是比较紧的,有时候人手还不够,测试压力很大,有所侧重的测试,理论是没问题的,有时就看运气好不好了,出现问题的概率和严重程度有多大。
只关心流程,不关心体验
有时候我也会去参加测试人员的面试,我比较关心的一个问题是:你们测试时会看样式吗?体验感觉不好时会提吗?
可能是这些年有些心理阴影了吧。遇到过一些测试,觉得样式和体验是和他们无关的事情。从公司责任划分来看,这也没什么问题,谁都不想给自己拦很多活,况且一些是偏主观,不能定量的。
没从现实场景出发
这个问题我们也经常会遇到,哪怕我们按照我们的要求验收通过了产品,领导或者客户点的时候,还是一堆 bug。
因为每个人在使用产品时,场景不一样,使用方法也不一样,就会出现很多预料之外的问题。主要还是下面2点原因。
数据过于测试化
大部分的测试数据都是“111,222”,测试“产品 1”这种,按照测试用例来测试时是没问题,但一旦把数据换成用户的真实数据,问题就很多了。
最常见的是字符长度问题,一般字段长度限制是 32,64,128 这种,测试数据长度太短时显示没有问题,一旦长一点,页面可能都乱了。比如药品名称,测试数据是“芬必得”,真实名称是“芬必得布洛芬缓释胶囊”。
我们经常做边缘测试,但事实上不可能所有字段都做,那怎么区分哪些要做,哪些不要做呢?最好的方法就是拿一家典型客户的数据来做测试,尽量避免写 111 这种。
没模拟用户使用路径
简单来说,没有站在用户的角度去测试产品。这个点或许对测试来说要求是有点高,绝大部分人能按测试思维,把产品测完就已经不错了。
这和上面一个点也是有非常大的关系的,我在测试环境测的时候,也常常发现不了问题,为什么?因为看着一些过于测试化的数据时,我都想不出下一步该去操作什么。所以一般产品经理都会建一些相对比较真实的自己的数据,而不是用测试数据。
最关键的还是这个点:互联网人对产品业务的理解太浅,甚至是不理解,特别是 B 端产品。大部分的开发和测试,没有接触过客户,没有去过实地,单靠产品经理的讲述,很难建立三维的感观。
像医疗、工业这种都是门槛比较高的,可能医院我们还去过,对于医生的看诊流程还体会得到。但工业就离我们比较遥远了,真的是从来没有去过工厂,很难理解为什么有些产品不看编号、看图号。入库产品包装上为什么没有条码,为什么钢材还要关心炉批号。
如果公司允许,能带着开发和测试去实地看看,对产品开发是有很大帮助的。
产品有 bug,先不要想这个锅应该谁来背。产品经理会说:测试没有测到位;测试会说:开发水平太差,bug 太多;开发会说:你的产品文档没写清。
还是要强调这个事:产品不是一个人的事,是大家的事。我们把甩锅的时间用在分析问题、制定解决方案上,会更加有效。
下面是我整理的2022年最全的软件测试工程师学习知识架构体系图 |
一、Python编程入门到精通
二、接口自动化项目实战
三、Web自动化项目实战
四、App自动化项目实战
五、一线大厂简历
六、测试开发DevOps体系
七、常用自动化测试工具
八、JMeter性能测试
九、总结(尾部小惊喜)
每个人真正强大起来都要度过一段没人帮忙,没人支持的日子。所有事情都是自己一个人撑,所有情绪都是只有自己知道。但只要咬牙撑过去,一切都不一样了。
当你打算放弃梦想时,告诉自己,再多撑一天一个星期一个月,再多撑一年吧。你会发现,拒绝退场的结果令人惊讶。
如果你要想成功、要想追求所企望的美梦,就千万不可有这样的信念,因为那会扼杀你的潜能,毁掉你的希望。