slave 资源问题可以通过 标签的方式 来表明每个节点 可以干点啥，一般不存在浪费
基于 k8s 的集群 应该是整个运维的整体方案，顺便帮 jenkins 解决节点问题， 不应该是只为 jenkins 存在 ，有点杀鸡用牛刀的感觉 ，不过测试是应该考虑运维和成本的问题了

appium 用来入门可以 落地 还差很多

以 stf 目前的架构，把 stf 的 ios provider 单独部署出来 然后使用你想用的各种框架（appium 或 xctest）来做执行层都是可以的，前提是不影响 stf 的稳定性。我们这边是使用 xctest 来实现并统一 android 和 ios 的实现，达到案例复用（然而并没有那么简单，ios 和 android 的对象属性都是有差异的实际落地有很多困难）
还有就是建议先把 android 落地了再说把。。。
appium 永远是 demo 一级棒，一说落地就没声音了 呵呵呵

我先不说 uiautomator2 可以使用 instrumented 进行单元测试来支持 webview。从 android 5.0 开始 uiautomator 对 webview 的元素探测机制已经支持的相当大了，能识别大部分的元素的情况下根本不需要上 webdriver。 而即使使用 webdriver 也不需要 appium 的支持，自己实现 webdriver 直接调度 webview 和你直接调度 appium 并没有差别。

什么日志都不贴 你让我怎么帮你

技术能力不是测试的业务能力体现？

任豚表示

目录需要绝对路径

你自己敲的命令？为什么不用我的脚本？

你把你启动命令参数 发出来看一看啊

shell 停起来也不麻烦，而且 对新手来说 越少的模块 越便于理解

yml 文件其实和 shell 差不多，我希望简单点给新手学习下

职业规划是 15K？ 那你为什么不转开发？ 明显开发到 15K 更简单啊

车轱辘话来回转

是测试工作 没做足，但是不一定是测试人员的问题

好事

一边削尖脑袋想进大厂，一边还 diss 人家 ，为了钱还真是搞笑

有必要在截图的地方处理吗？显示的时候再处理不就好了......

等怀旧服中

最简单的就是安全性上考虑 get 可以被别有用心的人利用 比如 超链接 图片 甚至 css 里调用，还有就是 通过 method 方法可以从路由层过滤请求 ，这个好处你只有写过接口才知道老人

你确实不懂

客户发送 - 服务器 接收- 服务器标记 需要传输的对象 - 数据批量传输，将复杂的业务进行分割后就能针对单个功能进行功能测试

如果数据库层面都限定死了 测这个没有什么意义。只要做一个异常校验就行了

你就算前后端分离你运行的时候前端也要依赖后端才能运行起来进行测试的啊

代码能力到底到什么程度？你这等于没说啊