建议了解一下 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：如果你手动操作时，第二个标签页也是要登录的，那我就理解错了，当我没说

感觉是直接点击就行，不用管展开不展开，不要定位到 span

如果你的负载机性能足够好，那么单位时间内，10000 个请求，你可以用 100 个线程执行 100 次，也可以用 1000 个线程执行 10 次。这完全是负载机的问题，虽然达到服务端的时间会有微小的差异，但基本上可以忽略。

压力机用 1000 个线程还是 100 个线程，服务端的线程数也不同啊，并不是没有区别的，占用的资源自然也会不同

不要过于纠结并发数，这个指标更多的是体现负载机的性能，通过 TPS 结合响应时间，才能更好地反馈系统的性能问题

TPS 和响应时间都是随着并发数变化，没有了并发数，这两个值怎么确定，或许你想说的是 最大 TPS 和 对应的响应时间