前几个月还在修 bug ,怎么没更新了 多注意下 commit
有没有可能你想要 xx 精灵?之前工作中用来做窗口嵌 H5 内容的自动化还可以,只是通用性不是很好,裁图不做杂色过滤的话在其他机器上不太灵,分辨率也要统一,想要批量得上虚拟机;用什么工具来做识别不难,难在前期处理,通过对截图的判断裁剪相对位置等情况来让工具做识别,这里面有很多技巧,可以逛逛做游戏脚本的外挂论坛,暂时还没遇到什么客户端比游戏界面复杂的,总有办法解决
用例还是要写,避免甩锅的比较好的方式
测试用例应该简单易懂。每个测试用例应仅包括必要且相关的步骤和预期结果,像那种写天书形式的个人认为大可不必
测试用例应该要日常维护
有用例可以防突发情况,临时借调人手帮忙测试的时候,对功能无从下手
P0 P1 级别的操作最好开测之前都写上,并且让产品开发过目,简单评审一下用不了几分钟,时间紧的话,优先级不高的操作可以先记录一下后面再补充进去
遗漏没覆盖全面是很难避免的,又不是神仙哪能顾虑到那么多,多一个脑袋多一种思路,测前有用例方便交流思考,尽量减少遗漏
养成习惯 无论多小的功能都会写测试点(完成任务后花一点点时间转成用例)输出报告时对同事负责也是对自己负责
有写脑图的时间 用例也应该能写完了,有脑图转 excel 的工具,也就没有区分用啥写了,我还试过临时 txt 写了发给领导看的
ui 方面可以玩玩按键精灵(认真
芜湖 恭喜再次起飞
直接上 16G ,大部分测试用的工具和库都兼容,最好查查日常工具的是否能在 M1 上用,被 pyqt5 坑了两天 最终放弃 gui 的开发 tk 太简陋了,只做命令行工具
点个赞
只看返回码和必要的业务字段,其他的返回信息那么多,逐个验证太耗时间了吧,一般都是拉着开发确认哪些字段有改动
用 22 端口传或者用 flask 写个接口?
支持探讨学习