个人看法：
1、从现象分析，这个列表数据大概率是从服务端获取的，而且不是只请求一次，挂在当前界面，也会实时请求，考虑抓包定位一下 ？ 更高效的方式是问一下客户端开发
2、从业务上考虑这个实时请求是否有必要？当然大概率是需要的
3、搞清楚了数据到底是如何获取的，然后抛开客户端，去测试一下数据获取是否有异常比如接口测试
4、数据来源测了之后，再考虑一下客户端是否需要更完善的异常处理，这个也要结合业务，比如这个列表数据实时获取失败的时候，能不能不刷新？

建议了解一下 base64

不打算二开，拿来就用的话，想找个比 Metersphere 好的并不好找，这个好歹是有个团队在维护的，要不看看商业的

追求灵活的，建议用测试框架，我理解无代码平台天然就会牺牲一部分灵活性

看了下楼主回复别人的帖子，发现就更有意思了，不得不反思一下，说别人都会，到自己呢？

个人看法，目前这个行业里稳定性普遍很差，除了一些比较老旧的公司或者国企之类，用人部门其实并不太关心你的稳定性，主要还是看能力，既然你自己觉得仅仅因为履历的好看而放弃这个 offer 是不甘心的，那就不考虑这个因素再问问自己要不要去，目前这个环境下一年换几家公司的都大有人在

gcc version 7.5.0

make 有编译错误咋回事呢，按照文档 git clone 然后直接 make 的，系统 Ubuntu

我这用的 wiki.js 当然也是自己找来的，大家一起分享自己用过的比较好用的，找一个去试一下不是太耗费精力

微信小程序有个云测服务可以试试，调用 wetest 的云真机去执行脚本，可以是 monkey 也可以自定义。我记得之前还可以免费测的，现在不太清楚，前提你要有你们小程序的开发者权限

先看这种比较靠谱

担心这个，实习经验可以不写，毕业后的工作没有太大的空窗期就好

还是没达到跟核心 API 一样的效果，自定义函数用这个装饰器，不能自定义报告里面 step 的名称吗，按目前这样实现，报告里面 step 名称中英混杂

倒是跟我这有点像，我这 TO B 的业务没办法都开始做这些了：
1、测试团队到客户现场驻场，一来维护客户关系，二来直接帮客户干测试相关的活（甚至有一些干开发），按工时算钱，直接产生效益；
2、把实施也纳入到了测试团队中，到客户现场安装部署演示这种必须有人做的事情也由测试团队做。

就测试本身的产出来说，在这个大环境下确实有点尴尬

很赞

所以服务自身的日志是个摆设吗

你看到的只是项目经理的工作中与你有交集的部分吧，仅仅是项目排期的内容，立项、结项、项目预算、成本控制这些都谁做的呢

我寻思他也没说是 itest 有问题啊，只不过说如果接口测试也用代码，那么就可以把前置处理这部分必须使用 UI 自动化的部分跟后面的接口测试整合在一起，当然一楼所说的两者解耦也是个很好思路；至于为什么非要用 UI 自动化来做前置处理，我觉得人家的业务场景，还是相信别人的判断比较好

首先，你这套东西叫平台不合适，你这叫一个自动化框架；
然后这个框架明显不适合你们团队，建议先找个开源平台或者工具去推广，做大部分场景的自动化落地，满足不了的再由你的脚本代码去实现；

有没有人觉得，通篇就是定义了一些奇奇怪怪的东西

我怎么感觉 Jenkins 就可以了

vars.get 是取，vars.put 是存，先取后存当然是取不到的

从截图里面看，状态，大小，时间，可以用来作断言

你说失败了状态码也是 200，但截图里却似乎不是，成功的是 200 失败的就显示的失败

我干过把大的音频文件切割成小的，用的 ffmpeg，python 有对应的库，合成跟转格式应该也可以处理

我试了下登录之后直接新建标签页访问一个子页面 url 是可以的，既然手动可以的话我认为你不需要去做什么特殊的操作，登录后直接新建标签页，注意等登录动作彻底完成再新建

ps：如果你手动操作时，第二个标签页也是要登录的，那我就理解错了，当我没说