【软件测试】6年资深测试总结的,测试人常常犯的9大误区,背锅不存在的......

224 篇文章 12 订阅
102 篇文章 16 订阅


前言

1、把原型设计、UI效果图作为软件测试的标准,只要软件与其保持一致就没有问题

近几年,把原型设计、UI效果图作为测试的唯二参考标准越来越普遍,但实际上原型、UI效果图一样存在问题,也是静态测试的重要内容。

静态测试,大家忘了吗?静态地检查程序代码、界面或文档中可能存在的错误,借以发现编写的程序的不足之处,减少错误出现的概率。

2、既然是敏捷开发模式,那测试用例也不用写,或者随便写点应付了事

测试用例必须要有,可以不是标准式的用例(如必须包含 标题、前置条件、操作、期望结果、测试数据等),可以用思维导图、测试检查点代替,需求覆盖率要满足测试要求。

3、自动化测试一定能提高测试效率

自动化测试提高测试效率是有前提的,如项目周期长,迭代次数多,已完成的功能模块较稳定。否则,投入大量的人力在维护自动化脚本上,得不偿失!

4、搭建测试环境不是测试员必须会的技能

搭建测试环境还真就是测试员必须会的技能,也许有docker这样的技术让测试员忘记了这一点。

但不要去否认。搭建测试环境,不仅仅是考验我们的linux、SQL等指令,更让我们清楚里面的配置参数,日志路径等,不管后续做性能测试,还是定位bug,都非常有帮助,且“部署测试”本就是测试的内容之一。

5、体验性问题不是bug,不用记录bug

体验性问题也是bug,一定要记录。不要忘记测试的初衷,从"用户的角度"去发掘软件中的问题,这里的问题,可以是代码问题、也可以是体验问题。

6、产品经理(或者项目经理)说XXX问题不用管,就不用记录bug

除非我们理解有问题,否则只要不能否认它是问题,没有人能阻止测试记录bug。至于是否被修复,那才是产品经理(或项目经理)可以决定的。

7、bug填写规范?只要开发能看懂就行了,其他无所谓

bug描述应该简洁、明了。这里的简洁是文字上的精炼,明了是通过文字、截图信息让开发能快速复现bug。你认为开发能看懂,说不定开发每次看懂你的bug都得多花几分钟,从而拉低了大家整体的工作效率。

8、测试用例就是我写的,所以测试时没必要看着执行

虽然用例是你写的,但人都是健忘的,执行没执行,可能自己有时都搞不清楚了。所以,不管采用边看边执行,还是执行完后做标记的方式,都得保证用例真的被执行完了。

9、测试结束,让写测试报告,那结论只有:测试通过

测试结论是项目决策人决定软件是否发布上线的重要参考依据。测试结论应该客观、真实,否则失真的信息会让项目决策人做出错误的决定,无法及时规避风险,那这锅,测试得背。所以,测试结论可以是通过,也可以是不通过!

时常被各种错误的风向带偏,陷入各种各样的误区,不妨定期抽出时间做个梳理哪些是我们随波逐流而应该坚持的。

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

一、Python编程入门到精通

请添加图片描述

二、接口自动化项目实战

请添加图片描述

三、Web自动化项目实战

请添加图片描述

四、App自动化项目实战

请添加图片描述

五、一线大厂简历

请添加图片描述

六、测试开发DevOps体系

请添加图片描述

七、常用自动化测试工具

请添加图片描述

八、JMeter性能测试

请添加图片描述

九、总结(尾部小惊喜)

很多事情当你再回忆时会发现其实没什么。所以,不管你当时多么生气愤怒或者别的,都告诉自己不必这样,你会发现其实真的不必。

紫气东来,喜气西来,财气南来,福气北来,四面八方,鸿运通天!
天道酬勤,鲲鹏展翅,为你道贺,把你恭喜,祝你升职步步高!

每个人的心里,都藏着一个了不起的自己,只要你不颓废,不消极,一直悄悄酝酿着乐观,培养着豁达,坚持着善良,只要在路上,就没有到达不了的远方!

  • 2
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值