我入职当前公司已经快 5 年时间了, 头 4 年其实都是一边做业务测试, 一边开发工具和写自动化测试的。 这种情况避免不了吧, 对于大部分团队来说还没奢侈到专门能养一批只开发工具不做测试的专职人员。 所以很多人包括我自己都会遇到楼主这种情况, 业务太忙,没有多少时间来做自动化测试和工具开发。
所以我建议楼主跟我当时一样, 就集中加班一段时间, 把自动化测试补上, 这段时间虽然你会很痛苦, 很累。 但是如果熬过去了, 你的自动化测试能节省你很多的时间了。 那么你就进入了良性循环了, 可以有更多的时间去做技术相关的东西, 同时技术相关的东西又给你带来更多的效率提升节省更多的时间。 这样你就越来越有时间去做测试开发的东西。 其实我当时就是这样的。 当然如果你极其的忙,天天忙业务都要加班到很晚,周末也加班,根本没得休息时间。。。。。那当我没说吧。。。。那就没什么办法。。。
我们的业务没有录制回放的需求, 所以没太研究, 你能分享一下么? PS: 创建这个期望的代码能贴一下么
还有这个坑呢。 我还没碰见
应该是配置错了吧,我这是可以路由的
是这个 mock server 直接具备的功能,不用二次开发, 它启动的时候可以设置 proxy 模式, 填写真实服务的 ip 地址和端口号。 我 go 的代码只是把 mock server 注入到了我们 k8s 集群里了,只做了这一个事而已。
看你的描述我觉得它的能力是符合你的需求的。 不过你们是什么场景需要这个能力的?
都行,看场景需要
你搜标题就行了吧
emmmmm .... 怎么说呢, 因为是存在很多复杂场景的接口测试的, 它不是能用简单的方式解决的。 也许你面对的场景就是发一个请求然后验证返回的 response 就行了。 但是很多人面对的场景比这个复杂多了。 比如我们这里的接口会调用 k8s 去动态的起一个 job 或者 service。 这个光验证返回的 json 是不行的, 我们需要调用 client 去访问 k8s 查询这个 job 或者 service 是不是正常的运行了。 同理还有各种其他的中间件需要查询验证。 所以 postman 怎么能搞这个呢?
好机会~~ 我觉得可以去。 大数据学好了可以进大厂拿一个不错的职级。 现在懂大数据的测试人员还是满少的。
既然点进来了就不能当没看见~~ 来吧~~ 我来承受第一波火力
前几天还有人说我现在算是网红了
就感觉前景挺好的呗, 现在企业都是数据量越来越大, 随着 AI 的落地,大数据技术也越来越重要。 不过一般的互联网公司还是没有这种岗位的。 现在看在测试领域里还是小众一点
后面还有 UI 自动化里常用的设计模式, 你也可以看看
其实~~ 在线上压测是正常的~~ 别说线上压测了~~ 我连直接拉线上环境的机房的电闸这种事都干过
你可以翻翻我以前写的 UI 自自动化军规和设计模式
其实最好你搜索控件的时候,用 id, name 或者 className 这种一看就知道是什么的方式定位。 但如果你们研发根本不写 id, name 这些属性的话, 那就只能用注释了. 或者你写个简单易懂的变量名
还有的是跨页面的业务流程的封装。 就是在 page 这一层上面还会有一层。 比如有一个比较长的业务流程是涉及到好几个页面的, 偏偏这个业务流程还非常常用, 很多 case 都要用。 所以就专门封装一个业务层。
现在的 page object 都是封装业务逻辑了, 不再只封装元素了。 也就是比如你这个登录页面, 就有一个 login 方法, 你 case 是调用这个 login 方法, 并不直接跟元素交互。
慢慢磨吧~~ 加油
我不建议普通的测试人员学 AI, AI 是只有大厂才有成本玩的东西。 普通测试学了基本没什么用。
翻译链接失效了
据说好像是测试开发做的, 我还跟作者聊过。不过我倒是没问过他到底是开发序列还是测试序列的。 但是这个东西是测试开发的我觉得也挺正常的, 因为难度也不高。
楼主和评论中的很多同学质疑的假大空也好,KPI 工程也好我觉得都质疑的挺合理的, 有这种质疑很正常。 就像我前两天还在质疑就目前看精准测试和 AI 测试的实际用处到底能有多少,我还真跑去跟人家讲师说去了 (虽然我自己就是测 AI 产品的,但不妨碍我目前对于 AI 在测试领域中的应用表示悲观的态度)。 我质疑的点其实主要就是成本大于收益。 我相信好多同学也是觉得这些高大上的东西真落地后到底还能有多少效果, 尤其是 AI 这种这么玄学的东西。 虽然我对于 AI 在目前的测试领域用的应用处于悲观状态, 但是这不妨碍我支持大家去研究这个方向。 我记得我们公司的 CEO 曾经说过, 科学的发展都是一开始不计成本的先把事情做出来,然后再是想尽一切方法把成本降下来。 这就好像手机一样, 我小的时候有几个家庭能买的起大哥大的? 当时大哥大成本太高了,很难能普及开来。 但是到了今天我们已经人手一台智能机了。 这个就是科学发展的规律。 所以如果以后 AI 发展的随便用个工具人人都能建模的时候, 我们再来看这些 AI 的测试方案, 也许就不会这么想了。 我们现在仍然是处于探索阶段, 我们需要的是更多的可能性,而探索阶段付出的成本就是很高的,就像制药业一样, 砸了几个亿研发了 10 几年的药最后还失败了的大有人在。 但这不能阻碍我们探索更多的可能性的脚步。 科技的进步就是这样一步步探索出来的。 附一个我之前跟我这边的同学的聊天记录吧,当时他担心搞的方案会做砸了, 所以我在开导他。
我认为做测开就是这样的, 去探索所有的可能性, 就算最后是失败的也不能停止脚步。 正因为我们之前尝试了, 所以现在才有那么多有用的测试技术, 但是这些测试技术在一开始探索的时候,可能都是饱受争议的。 所以我质疑归质疑,但是我一直保持开放的态度。
最后虽然测试行业里关于这些东西的争议一直就没断过, 但是总体来看我觉得这一行已经是对大家很友好了, 喜欢技术,有野心的同学可以在各个名企发光发热。 不喜欢写代码也没有那么大野心的同学也可以在这行里活的不错,因为不管再怎么强调测试技术的重要性但还是有大把的中小企业,外包公司和事业单位都是需要普通的业务测试的。 我媳妇在 29 岁的时候也能找个 18K 的纯手工测试的工作呢, 前几天我一个朋友也找了一个 20 来 K 的纯手工测试工作 (他已经 32 岁了,坐标北京), 我觉得这样也挺好的。 测试行业能兼容不同人群的需求, 大家根据自己的情况进行选择就好了。
拿当前时间戳作为随机种子再加上随机字符串, 怎么会撞车呢。。。。
啥意思?
我们这的规范是同一个环境, 自动化测试跑 n 遍,要求每一次必须互不影响,互相不依赖。 所以我们所有的数据都是在代码里创建的。创建的时候名称,标题,id 啥的生成必须是随机字符串。 所以我们基本不考虑删数据的事。