写好用例,做好用例评审,等上了线万一有问题大家一起背锅
测试框架 + jupyter,直接在 ide 上写,jupyter 上跑完事,产品研发测试都可用
那么多开源的弄一个用起来不就完事了,metersphere 都不会,那就用 postman、apifox,安装软件你总会吧?
不喜欢引用就用代码咯,只是个样式问题,或者写个油猴替换样式
嗑药、头悬梁锥刺股、督战队、洗脑喊口号 “提高个人能动性,带动他人积极性”
VirtualXposed
道理大家都懂,给点实战案例、用例模板
看起来是三方提供的授信接口,直接自己 mock,做好异常场景有多离谱的返回都可以,线上只会更离谱
arthas 确实是神器,用火焰图也可以很方便的找到问题
你确定是接口没问题 UI 有问题?这种项目一般都比较垃圾,内部系统 UI 还要处理数据?
我觉着如果是上面这种情况,你应该考虑下给研发提改进需求
TDD 只是个思维模式没啥适不适合的说法,只有推不推的动,要是有不换思想就换人的能耐,啥都合适
卧槽,这也是一种本事
还是乘早跑路,你一个人肯定干不过他的,除非你能拉动其他人一起搞他,不然无解
只用 httprunner 本身提供的功能,那测试平台的缺点他都有,用例结构固定不灵活所以做不了复杂的逻辑判断也就做不了复杂的测试场景。
但是要是二开 httprunner,学习它的模型结构就能和 pytest 互相取长补短,而且 httprunner 提供了非常多现成的工具用
这种分开,先找瓶和盒之间异常,再找盒和箱之间异常,挺不错的题,只能说现实场景比这个复杂得多。
这种异常就可以拿来做告警,有了告警再去反查日志。
测试开发很简单的,只用做到比后端懂前端,比前端懂后端,比开发懂运维,比运维懂代码就够了,遇到啥学啥就对了
airtest 直接 xy 轴定位然后图像识别,大力出奇迹
这种写着玩还可以,复杂的业务场景根本维护不了,还是不要造轮子,用现成的轮子不香吗。
改造下 httprunner 就可以用的很爽
现在不都直接甩给 gpt 吗,三方对接花一天,扔给 gpt 翻译成 python 30 分钟调试完
session: scoped_session = g.hr_db_session
那就定义变量类型
根据实际业务场景来判断啊,有需求成本合适值得做就可以做,比如 openapi、协议开发那测得就是这些玩意肯定得做。
管理用例最好用的肯定是 pycharm
最好写深入一点,都是些水贴
我们公司测试不光看,还在阿里云平台上开发告警规则,配置各种配置。
那你该想想为啥你没权限看
是的,先跟老板确认清楚,有可能你根本没得选,那就不用纠结了。。
我觉着这篇文章字里行间立都是在输出焦虑。
这老哥看起来已经做的很不错了,但是奈何公司不景气了走下坡路,那个人也只能是时代的一粒沙。但是以那个老哥的能力出去再找一份工作怕是也不难,个人觉得现在的环境只是对新人和高薪低能的人不友好。
从文章里面看老哥和领导沟通没到位,除开工作汇报以外,日常和领导处理好关系了,怎么都不至于公开场合说出让一个来两个月的新人接替你的工作这种话,这话说出来了那确实没什么可干的了。但也不是裸辞吧。。。不得找个工资更高的证明自己?
说到底故事罢了。