如果发生线上问题,不第一时间找 QA,这样对你的现状会更好么?不会更好吧
BUG 没防住,就追根因,出报告,做预防。
有没有可能是普遍都是 crud 的内容,不需要讨论了,超出一点的内容都有自己的小圈子
得看你们产品的实现方式,设备是只做消息收发,执行动作,还是要做业务处理。
正常情况下业务逻辑全在后台,app 和设备只是做消息收发而已,这样的话固件测试一个人,app 和后台可以并在一起测试。
如果设备端也做业务处理,那具体情况具体分析了
reqable,试试看
试用过影刀,定位很强大,能降低定位的成本。单从定位来说,playwright 也够用的。
但是测试的业务逻辑,用例维护成本等,该那么多还是那么多的,看自己取舍。
官网,或者是 github 项目里的讨论,尤其是项目里的讨论,有很多有意思的场景和用法
第三方文档系统,然后上面做套壳
自动化框架有人用?测试平台有人用?代码覆盖率有项目落地?
分析数据的时候需要用,结果留存总是没错的。
自动化测试执行并不是结束,时候量化测试工作,年终汇报等场景都需要拿数据演示的。极客时间有一门自动化测试高手课,讲理论方面,挺开拓思维的,可以试一试
同意文档的看法。
但是在招聘,日常 KPI,年终总结面前,上面的工作怎么量化展示呢?毕竟对社畜来说涨工资的事是首位。
去年深圳站的电子票因为疫情没去成,可以转今年的上海站么?
看项目大小呗,团队人多的话,就按第二种照流程走;
小团队的话,三五个人这种,提测之后,测一天大概就 20/30 个 bug 了,后面的研发上午改好一版,下午接着改测试上午测的呗;
事无绝对,找到适合团队的节奏就行。
长江后浪推前浪,厉害啊!!!
妥妥的小说里的男主啊
个人理解的是,协议的学习技巧最直接的是看报文结构。
不需要全部理解报文结构内全部字段的意思,但是要知道报文结构内常用的字段。
例如:HTTP 协议的请求和响应报文结构,
大概记住报文结构之后,这样不管是写 Python,JAVA,还是使用工具,HTTP 的开始都是 client.method,之后就是报文结构的其他字段。
可以大概看一下 httpclient 的方法,基础的方法都是模拟的 HTTP 头部字段。
第一天打卡
READ 证书有必要考么?
十年树木,百年树人,祝愿小破站守好这片【净土】!!!
录制回放,并且录制之后包含接口信息,可以抽离出来做接口自动化,做双重断言
有 CAN 分析仪么?搞个脚本看分析结果
回复测试