用商业的云真机平台? 你的痛点在于写的脚本要适配不同的设备才能跑,这一点云真机平台应该可以解决才对
没覆盖是一方面,而且从申请加班的页面看是没有搜索词和分页的,接口有这两个参数比较奇怪。猜测这个接口不只是申请加班用,加班列表页可能也是调这个接口,接口设计本身就不太合理,不过这种内部系统质量要求本身就不高。按场景设计接口用例我觉得是可以的,要增加一下列表页查询场景的测试用例
如果你可以把执行人工测试的那台被远程控制的电脑作为自动化执行机器,那么跟一般的自动化没有任何区别; 能远程桌面但不能传文件?也不能连外网搭环境?
如果你想着用你眼前的电脑作为执行机,我觉得你说的方案都不行
注意你的 docker 容器处在一个比较特殊的状态 removal in progress,按这个关键字搜到了很多相似案例,比如:
https://blog.csdn.net/weixin_44602651/article/details/118103297
个人看法:
1、从现象分析,这个列表数据大概率是从服务端获取的,而且不是只请求一次,挂在当前界面,也会实时请求,考虑抓包定位一下 ? 更高效的方式是问一下客户端开发
2、从业务上考虑这个实时请求是否有必要?当然大概率是需要的
3、搞清楚了数据到底是如何获取的,然后抛开客户端,去测试一下数据获取是否有异常比如接口测试
4、数据来源测了之后,再考虑一下客户端是否需要更完善的异常处理,这个也要结合业务,比如这个列表数据实时获取失败的时候,能不能不刷新?
建议了解一下 base64
不打算二开,拿来就用的话,想找个比 Metersphere 好的并不好找,这个好歹是有个团队在维护的,要不看看商业的
追求灵活的,建议用测试框架,我理解无代码平台天然就会牺牲一部分灵活性
看了下楼主回复别人的帖子,发现就更有意思了,不得不反思一下,说别人都会,到自己呢?
个人看法,目前这个行业里稳定性普遍很差,除了一些比较老旧的公司或者国企之类,用人部门其实并不太关心你的稳定性,主要还是看能力,既然你自己觉得仅仅因为履历的好看而放弃这个 offer 是不甘心的,那就不考虑这个因素再问问自己要不要去,目前这个环境下一年换几家公司的都大有人在